Дисковая подсистема для domino

[rinsk]

просто фриз для ВМ, снэпшот, анфриз, синк (синхронизация изменений), бэкап (разный бывает), удаления снэпшота.

Угу - для файлового сервера - самый раз. А для баз данных не подходит. Только через VDPA. И как ни странно - там те же агенты для каждой поддерживаемой базы
Ну а резюмируя - если есть кластер, то вполне можно жить без SSD Raid , если нет то сочувствую использовать SSD с мерами по обеспечению аппаратной надежности носителя (SSD Raid\ Write Cache SSD, и т.п..)

 

[lmike]

Только через VDPA

не вмтварью единой
ну а потом - я не совсем понял - зачем такие ухищрения если я описывал кусок из оффлайн миграции (ВМ на паузе), просто миграции не будет и даунтайм "минимальный"
пример

Ссылка скрыта от гостей

или

Ссылка скрыта от гостей

(вариант полного суспенда гостя) - икнет на ~полминтуты

если есть кластер, то вполне можно жить без SSD Raid

не смотря что "у меня" есть - я все-равно подстраховываюсь несколькими вариантами бэкапа (остановимся на варианте - у меня паранойя )

 

[ToxaRat]

вот я читаю и читаю
и так и не понял, почему же я не могу в свой сервер вставить один SSD вместо рейда?
у меня что на конкретно этом сервере есть терабайтные базы?
или я не умею раскидывать базки по серверам?

В чём прикол тратить уйму бабла на якобы диски, которые справятся с нагрузкой?

Что это вообще за нагрузка на домино такая аж в - "6гигабит/с"?

Вот честно, какие у вас максимальные показатели по домино?
Только плиз без "говнокода" - а то я и сам одним агентом могу все базы вывернуть за раз

 

[rinsk]

ну а потом - я не совсем понял - зачем такие ухищрения если я описывал кусок из оффлайн миграции (ВМ на паузе), просто миграции не будет и даунтайм "минимальный"

По теме конечно жуткий оффтоп - тем не менее. есть разница между ВМ на паузе и стабильным состоянием базы на диске. Перенос - ради бога, как перенос сервера на батарейках из комнаты в комнату. Цель - не хранить состояние ВМ вместе со всеми ее тараканами, а получить актуальную копию базы для последующего восстановления. В каком состоянии буду транслог, и т.п. на момент заморозки? Для разморозки - пожалуйста. а вот для восстановления - никак)

 

[rinsk]

И да - вспомнил как коллеги пытались поднять умершую базу на винде из shadow copy ... Больше так уже и не делали.)

 

[lmike]

один SSD вместо рейда

дорого и гарантированный выход из строя в течении 3-х лет. Да и потом - использовать железяку целиком для домины, если она не несет нагрузки - это как-то ну нерентабельно что ли

В чём прикол тратить уйму бабла на якобы диски, которые справятся с нагрузкой?

давай сравним цены 500Гб SATA и SSD - в 3-и раза разница
если захотим брэнд понадежней - в 10-ть (Интелы так стоят)
это про уйму бабла - твой выбор ССД
теперь про время простоя - сколько ты говорил будет подъем сервера? а выезд на место + возня в потрохах?

ну и про производительность - вот захотел я разместить 1Це на том же хосте что и домину (опять же - ты предлагал съэкономить на железе) и 1эсник запустил апдейт своих шняжек. Вопрос - что у нас будет а с очередью на диск - жопец будет полный

 

[lmike]

В каком состоянии буду транслог, и т.п. на момент заморозки?

пардоньте - мыжподнимать будет целиком ВМ (именно размораживать сделанный+скопированный снимок)
про VSS - ну оно понятно
если хотим отдельные файлы - то придется говорить с космосом домине сказать drop all/set config server_restricted=1/dbcache flush ...

 

[rinsk]

пардоньте - мыжподнимать будет целиком ВМ (именно размораживать сделанный+скопированный снимок)
про VSS - ну оно понятно
если хотим отдельные файлы - то придется говорить с космосом домине сказать drop all/set config server_restricted=1/dbcache flush ...

Целиком ВМ?? Ну на тестах\коленках вполне возможно. А вот на боевых - снимок в 0,5 TB? не рискнул бы. и в этом случае об инкрементале можно забыть - я просто не представляю, как в этому случае будут собираться состояние ВМ на конкретный момент времени).
- а еще сказать - tell updall quit\tell http quit и т.п. Все нормальные системы бэкапирования DBMS используют API целевой системы для гарантированного создания резервных копий. Все остальное - от лукавого...

 

[rinsk]

И вообще - данный разговор наглядно иллюстрирует ежедневное окружение каждого из авторов, каждодневные задачи, ограничения и возможности.
Я вот не представляю, как можно на APP сервере разместить гарант например, а на финансовом сервере MS SQL еще и базы 1С - ну и т.п.
По этому - есть разные подходы к решению тех или иных вопросов. Так что - каждый выбирает то, что ему подходит

 

[lmike]

Я вот не представляю, как можно на APP сервере разместить гарант например, а на финансовом сервере MS SQL еще и базы 1С - ну и т.п.

я тоже так не делаю, но разместить тестовую ВМ (с бОльшими ограничениями) вполне могу, и завести РСУБД, в кот. заливать данные из домины - вполне себе задача (нагружающая IO), балансирующий/проксирующий nginx, tomcat - до кучи
1Це прозвучал в срезе нагрузки

 

[lmike]

Целиком ВМ?? Ну на тестах\коленках вполне возможно. А вот на боевых - снимок в 0,5 TB?

и что в этом критичного, т.е. libvirt скрипты недостаточно зрелые, и РХ на коленках предлагает такие решения? И про 500Гб тоже недопонял - вся ВМ и только домино - мало отличаются, если ВМ под домину и создана
в любом раскладе - это наборы (скрипты миграции и снэпшотов ВМ) для широкого спектра задач, и их используют в продакшн компании предоставляющие "облака"

Все нормальные системы бэкапирования DBMS используют API целевой системы для гарантированного создания резервных копий. Все остальное - от лукавого...

если есть желание на это заморачиваться + вкладывать деньги (одно время меня TSM ну сильно достал - то либа не та, то система "устарела")

 

[rinsk]

в любом раскладе - это наборы (скрипты миграции и снэпшотов ВМ) для широкого спектра задач, и их используют в продакшн компании предоставляющие "облака"

Тема уже уходит совсем в другую сторону и не понятно при чем тут скрипты миграции и продакшен компании? речь идет о бэкапе баз данных. Конкретно о базах Домино, подчиняющийся банальным законам работы любой СУБД. Я сторонник подхода к этому вопросу - не так как получится, а так как надо. ну а если не получается, хотя бы признать - что вынужден делать так по тем или иным причинам. И такой подход считаю важным для тех. кто только встречается с суровой правдой жизни

если есть желание на это заморачиваться + вкладывать деньги (одно время меня TSM ну сильно достал - то либа не та, то система "устарела")

Ну и чем твое желание "не заморачиваться" отличается от моего "ну нафиг бэкап" ?)))

 

[lmike]

Тема уже уходит совсем в другую сторону

уж да уж

и не понятно при чем тут скрипты миграции и продакшен компании? речь идет о бэкапе баз данных.

если не разделять БД и ВМ как сущности, а ограничится только ВМ - меня смущение не охватывает

Ну и чем твое желание "не заморачиваться" отличается от моего "ну нафиг бэкап" ?)))

как сам понимаешь - контекстом применения - не заморачиваться с TSM (как твоеже упоминание про аналогичный софт ), но бэкап проводить др. ср-вами и по др. принципу (где это применимо)

Я сторонник подхода к этому вопросу - не так как получится, а так как надо. ну а если не получается, хотя бы признать - что вынужден делать так по тем или иным причинам. И такой подход считаю важным для тех. кто только встречается с суровой правдой жизни

ну собсно я сделал аналогичные выводы
PS: TSM, для меня, завершил жизненный цикл лет 5-ть назад, но от идеи держать образ ВМ + реплики + кластер я отказываться не собрался

 

[ToxaRat]

давай сравним цены 500Гб SATA и SSD - в 3-и раза разница
если захотим брэнд понадежней - в 10-ть (Интелы так стоят)
это про уйму бабла - твой выбор ССД

я SSD с рейдом сравнивал а не с одним диском

 

[Мыш]

Немного флуда.
1. Дважды был свидетелем разрушения 5-го RAID - без возможности восстановления данных.
2. С репликацией (обычной - не кластерной!) тоже были неприятные случаи - попадались пользователи, ограничивающие доступ к письмам в своих ящиках полями Readers, создающие приватные папки (ну тут, конечно, и косяк админов был). Соответственно, эти док-ты и папки в реплики не попадали.
Так что я за физические копии и ленты

 

[lmike]

я SSD с рейдом сравнивал а не с одним диском

я совсем запутался что ты хотел выразить...
давай так:
-SATA или SAS
-SSD какого ценового диапазона, если SATA (с SAS нет альтернативы)
-с рэйдом какого уровня ты сравнивал
-что ты планируешь размещать на SSD
-как планируется обеспечивать замену в случае поломки
-в какую пропускную способность ты хотел задействовать для SSD
[DOUBLEPOST=1427101512,1427101345][/DOUBLEPOST]

1. Дважды был свиделетем разрушения 5-го RAID - без возможности восстановления данных.

не использую эти рэйды уже лет 10-ть

Ссылка скрыта от гостей

(я читал и более ранние статьи, но нет под рукой)

 

[rinsk]

Так что я за физические копии и ленты

Я то же - ЗА честный бэкап. Если им пользуются. Ну и ленточег поболе ))