Угу - для файлового сервера - самый раз. А для баз данных не подходит. Только через VDPA. И как ни странно - там те же агенты для каждой поддерживаемой базы
Ну а резюмируя - если есть кластер, то вполне можно жить без SSD Raid , если нет то
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Ну а резюмируя - если есть кластер, то вполне можно жить без SSD Raid , если нет то
не вмтварью единой
ну а потом - я не совсем понял - зачем такие ухищрения если я описывал кусок из оффлайн миграции (ВМ на паузе), просто миграции не будет и даунтайм "минимальный"
пример
Ссылка скрыта от гостей
или
Ссылка скрыта от гостей
(вариант полного суспенда гостя) - икнет на ~полминтутыне смотря что "у меня" есть - я все-равно подстраховываюсь несколькими вариантами бэкапа (остановимся на варианте - у меня паранойя
)
вот я читаю и читаю
и так и не понял, почему же я не могу в свой сервер вставить один SSD вместо рейда?
у меня что на конкретно этом сервере есть терабайтные базы?
или я не умею раскидывать базки по серверам?
В чём прикол тратить уйму бабла на якобы диски, которые справятся с нагрузкой?
Что это вообще за нагрузка на домино такая аж в - "6гигабит/с"?
Вот честно, какие у вас максимальные показатели по домино?
Только плиз без "говнокода" - а то я и сам одним агентом могу все базы вывернуть за раз
и так и не понял, почему же я не могу в свой сервер вставить один SSD вместо рейда?
у меня что на конкретно этом сервере есть терабайтные базы?
или я не умею раскидывать базки по серверам?
В чём прикол тратить уйму бабла на якобы диски, которые справятся с нагрузкой?
Что это вообще за нагрузка на домино такая аж в - "6гигабит/с"?
Вот честно, какие у вас максимальные показатели по домино?
Только плиз без "говнокода" - а то я и сам одним агентом могу все базы вывернуть за раз
По теме конечно жуткий оффтоп - тем не менее. есть разница между ВМ на паузе и стабильным состоянием базы на диске. Перенос - ради бога, как перенос сервера на батарейках из комнаты в комнату. Цель - не хранить состояние ВМ вместе со всеми ее тараканами, а получить актуальную копию базы для последующего восстановления. В каком состоянии буду транслог, и т.п. на момент заморозки? Для разморозки - пожалуйста. а вот для восстановления - никак)
И да - вспомнил как коллеги пытались поднять умершую базу на винде из shadow copy ... Больше так уже и не делали.)
дорого и гарантированный выход из строя в течении 3-х лет. Да и потом - использовать железяку целиком для домины, если она не несет нагрузки - это как-то ну нерентабельно что ли
давай сравним цены 500Гб SATA и SSD - в 3-и раза разница
если захотим брэнд понадежней - в 10-ть (Интелы так стоят)
это про уйму бабла - твой выбор ССД
теперь про время простоя - сколько ты говорил будет подъем сервера? а выезд на место + возня в потрохах?
ну и про производительность - вот захотел я разместить 1Це на том же хосте что и домину (опять же - ты предлагал съэкономить на железе) и 1эсник запустил апдейт своих шняжек. Вопрос - что у нас будет а с очередью на диск - жопец будет полный
пардоньте - мыжподнимать будет целиком ВМ (именно размораживать сделанный+скопированный снимок)
про VSS - ну оно понятно
если хотим отдельные файлы - то придется
Целиком ВМ?? Ну на тестах\коленках вполне возможно. А вот на боевых - снимок в 0,5 TB? не рискнул бы. и в этом случае об инкрементале можно забыть - я просто не представляю, как в этому случае будут собираться состояние ВМ на конкретный момент времени).
- а еще сказать - tell updall quit\tell http quit и т.п. Все нормальные системы бэкапирования DBMS используют API целевой системы для гарантированного создания резервных копий. Все остальное - от лукавого...
И вообще - данный разговор наглядно иллюстрирует ежедневное окружение каждого из авторов, каждодневные задачи, ограничения и возможности.
Я вот не представляю, как можно на APP сервере разместить гарант например, а на финансовом сервере MS SQL еще и базы 1С - ну и т.п.
По этому - есть разные подходы к решению тех или иных вопросов. Так что - каждый выбирает то, что ему подходит
Я вот не представляю, как можно на APP сервере разместить гарант например, а на финансовом сервере MS SQL еще и базы 1С - ну и т.п.
По этому - есть разные подходы к решению тех или иных вопросов. Так что - каждый выбирает то, что ему подходит
я тоже так не делаю, но разместить тестовую ВМ (с бОльшими ограничениями) вполне могу, и завести РСУБД, в кот. заливать данные из домины - вполне себе задача (нагружающая IO), балансирующий/проксирующий nginx, tomcat - до кучи
1Це прозвучал в срезе нагрузки
и что в этом критичного, т.е. libvirt скрипты недостаточно зрелые, и РХ на коленках предлагает такие решения? И про 500Гб тоже недопонял - вся ВМ и только домино - мало отличаются, если ВМ под домину и создана
в любом раскладе - это наборы (скрипты миграции и снэпшотов ВМ) для широкого спектра задач, и их используют в продакшн компании предоставляющие "облака"
если есть желание на это заморачиваться + вкладывать деньги (одно время меня TSM ну сильно достал - то либа не та, то система "устарела")
Тема уже уходит совсем в другую сторону и не понятно при чем тут скрипты миграции и продакшен компании? речь идет о бэкапе баз данных. Конкретно о базах Домино, подчиняющийся банальным законам работы любой СУБД. Я сторонник подхода к этому вопросу - не так как получится, а так как надо. ну а если не получается, хотя бы признать - что вынужден делать так по тем или иным причинам. И такой подход считаю важным для тех. кто только встречается с суровой правдой жизни
Ну и чем твое желание "не заморачиваться" отличается от моего "ну нафиг бэкап" ?
)))уж да уж
если не разделять БД и ВМ как сущности, а ограничится только ВМ - меня смущение не охватывает
как сам понимаешь - контекстом применения - не заморачиваться с TSM (как твоеже упоминание про аналогичный софтНу и чем твое желание "не заморачиваться" отличается от моего "ну нафиг бэкап" ?
), но бэкап проводить др. ср-вами и по др. принципу (где это применимо)ну собсно я сделал аналогичные выводыЯ сторонник подхода к этому вопросу - не так как получится, а так как надо. ну а если не получается, хотя бы признать - что вынужден делать так по тем или иным причинам. И такой подход считаю важным для тех. кто только встречается с суровой правдой жизни
PS: TSM, для меня, завершил жизненный цикл лет 5-ть назад, но от идеи держать образ ВМ + реплики + кластер я отказываться не собрался
Немного флуда.
1. Дважды был свидетелем разрушения 5-го RAID - без возможности восстановления данных.
2. С репликацией (обычной - не кластерной!) тоже были неприятные случаи - попадались пользователи, ограничивающие доступ к письмам в своих ящиках полями Readers, создающие приватные папки (ну тут, конечно, и косяк админов был). Соответственно, эти док-ты и папки в реплики не попадали.
Так что я за физические копии и ленты
1. Дважды был свидетелем разрушения 5-го RAID - без возможности восстановления данных.
2. С репликацией (обычной - не кластерной!) тоже были неприятные случаи - попадались пользователи, ограничивающие доступ к письмам в своих ящиках полями Readers, создающие приватные папки (ну тут, конечно, и косяк админов был). Соответственно, эти док-ты и папки в реплики не попадали.
Так что я за физические копии и ленты
Последнее редактирование модератором:
я совсем запутался что ты хотел выразить...я SSD с рейдом сравнивал а не с одним диском
давай так:
-SATA или SAS
-SSD какого ценового диапазона, если SATA (с SAS нет альтернативы)
-с рэйдом какого уровня ты сравнивал
-что ты планируешь размещать на SSD
-как планируется обеспечивать замену в случае поломки
-в какую пропускную способность ты хотел задействовать для SSD
[DOUBLEPOST=1427101512,1427101345][/DOUBLEPOST]
не использую эти рэйды уже лет 10-ть
Ссылка скрыта от гостей
(я читал и более ранние статьи, но нет под рукой)Я то же - ЗА честный бэкап. Если им пользуются. Ну и ленточег поболе
))Обучение наступательной кибербезопасности в игровой форме. Начать игру!