1. У каждого нормального ресурса есть API-команда Monitor, которую Pacemaker использует для проверки состояния ресурса. Ее вызов активируется параметров monitor у ресурса, можно задать действие при ошибке. По умолчанию кластер рестартует ресурс, но можно поставить режим standby, который вызовет миграцию всех ресурсов со сбоящей ноды. Можно указать количество ошибок перезапуска, после которых пройдёт миграция.
Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.
Вообще, у Pacemaker очень много возможностей — интересующиеся могут заглянуть в документацию, это не тема одной или даже нескольких статей.
Что такое «проверка по шатдауну» не понял. Да, и drbd живет в ядре, его kill -9 не возьмешь.
2. Какого рода тесты, например? Сеть выдёргивалась, питание одной из нод вырубалось, свитч один вырубался. Всё отрабатывало как надо.
И еще, так как практически весь рабочий софт находится в ядре (SCST, DRBD), то его сбой приведёт к краху ядра (особенно если включить дополнительно panic_on_oops) и нода, по сути, будет мертва, что обнаружит вторая нода.
Переброс IP-шника для ESXi проходит гладко, таймаут Corosync по умолчанию — 4 секунды, таймаут iSCSI в ESXi — 10 секунд.
Так что всё проходит очень быстро и практически незаметно для ВМ.
Если нет возможности что-то еще поднимать — то это системные проблемы в инфраструктуре.
«У меня в сети» много Powershell-скриптов, еще больше Bash- и Perl-скриптов и вообще чего только нет — для каждой задачи свое оптимальное решение. Я веду к тому, что проблемы нужно решать системно и если эта задача уже была давно кем-то решена, то лучше использовать готовое решение, а не писать костыли и велосипеды.
То есть, по-вашему, два собственноручно написаных скрипта являются более оттестированым решением, нежели очень давно и успешно используемый в продакшене продукт? Забавно
То, что бюджет заморозят — я могу представить.
А вот что мне может помешать вместо двух Win2008R2 поставить два Linux я представить не могу. Разве что самодурство начальства или отсутствие свободного железа. Учитывая что для DHCP сервера можно использовать абсолютной любой сервер или даже (свят-свят) десктоп, последнее видится маловероятным.
А можно не изобретать велосипед и установить пару виртуальных машин, а лучше — ВМ + физический сервер с каким-нибудь *nix и ISC DHCP Server, в котором уже встроен режим failover и отлично работает. Настраивается всё за полчаса вместе с установкой операционной системы. Дополнительный бонус — распределение нагрузки между нодами, они обе активны и обслуживают клиентов.
И хотя я начинал знакомство с UNIX-like системами именно с FreeBSD, сейчас я не вижу смысла его использовать в большинстве проектов.
Причин много, например — существенно меньший выбор проектов, разрабатываемых параллельно ядру или включенных в него.
Так, есть аналог(скорее даже клон) DRBD под названием HAST, но он, судя по всему, работает вообще в пространстве пользователя и вряд-ли сможет тягаться по скорости (если что — бенчмарков не видел и не делал). Да и вообще возможностей у него относительно DRBD мало крайне: нет каких-либо контрольных сумм, только один протокол синхронизации (синхронный), ну и так далее.
C iSCSI и FC таргетами там, судя по всему, тоже выбор не велик, только то, что в ядре. В Linux же есть LIO (который уже в ядре, поддерживает уже даже 16Гбит FC, FCoE и вообще много чего), SCST (тоже много протоколов), STGT и еще много всякого — есть из чего выбрать.
Ну и поддержка производителей железа идет в первую очередь линуксу, а BSD уже во вторую очередь.
Каждый сервер где-то 250т.р. (с дисками)
Коммутаторы по ~150т.р. Но от них для этой задачи вообще ничего кроме VLAN не требуется, так что подойдут любые гигабитные управляемые.
Я режим master-master не использую принципиально — производительности single-master мне более чем достаточно, а сохранность данных у меня на первом месте.
По поводу протокола B и dual-primary в доках DRBD чётко написано:
Dual-primary mode requires that the resource is configured to replicate synchronously (protocol C).
1. Я mdraid в продакшене не использую особо, только дома, так что видать чаша сия меня обошла. Баги то они везде бывают, тут вопросов нет, другое дело, что тобы они вылезли зачастую нужно чтобы звезды сошлись правильным образом. У меня система, подобная описаной в статье, работает уже пару лет под 24х7 нагрузкой (пусть и не стрессовой) — всё ровно.
2. Зачем ему partitioning в режиме single-primary? DRBD вообще до последнего времени не подразумевало более двух нод, так что кворум в принципе не был возможен. Да и теперь, когда появилась возможность строить трехнодовую репликацию, по сути ничего не изменилось. Сам по себе DRBD не будет же переводить ресурсы в primary режим при потере связи и прочих бедах, это забота менеджера кластера, а там вопрос split-brain решается избыточностью heartbeat-каналов, этого в 99.9% достаточно.
3. Тут ничего не скажу, не мерял этот вопрос. В любом случае, если проблема встает, то метаданные можно вынести на отдельный массив из SSD.
4. Насчет dd — тут в общем и целом да, только вот в случае с dm-crypt ситуация получается странная — скорость с oflag=direct получается ниже, а с iflag=direct (при, соответственно, чтении) — выше. Тут, я думаю, дело в том, что dm-crypt берёт блоки из кеша пачкой и разбрасывает их по worker-ам на разных ядрах. А при обходе кеша он этого делать не может, поэтому получается в разы медленнее.
5. Для этого в бондинге есть ARP-мониторинг, выбираем IP-адрес соседа для ARP-запросов и как только он перестал отвечать — бондинг будет считать что соответствуюший интерфейс упал. На свичах есть похожий протокол UDLD для определения что одно из волокон (передающее или принимающее, если это не WDM) помёрло.
С отключеным вещанием SSID бывают глюки у разных девайсов, да и батарейка, возможно, будет разряжаться быстрее т.к. телефон тот же будет периодически пытаться подключиться к невидимой сети.
Конечно, производитель должен был обеспечить нормальный образ восстановления, загрузившись с которого и нажав одну кнопку я бы получил работающий контроллер.
И у них это почти получилось :) Непонятно только зачем образ восстановления пытается шить в обычном режиме, а не в Mode0, ну и косяк с виртуальным приводом CDROM, который во всех остальных местах работает ОК.
Опция -a указывает какие контроллеры шить, например -a0,1 или -aALL, а вот уже в режиме восстановления (Mode0) этой опции вообще нет.
Ну, завод это еще нормально, у меня отец в ВТБ24 работает, там до сих пор очень большая часть бановского софта под DOS-ом крутится, еще на FoxPro или чем-то подобном писанного.
Да, лет 5-7 назад я покупал Адаптеки, но с ними у меня как-то не сложилось.
Один из контроллеров (52445, огромный такой, на 28 портов, бешеных денег стоил) у меня первые пару лет работы периодически глючил — то сам контроллер в резет уходит, то винты с него отваливаются с большим кол-вом I/O ошибок, хотя они здоровые (это решилось обновлением прошивки самих винтов, хотя с другими контроллерами они не глючили), то еще какая-то напасть. Он до сих пор трудится и после крайнего обновления прошивки вроде как успокоился глючить и работает ровно :)
А про Smart Array вообще лучше говорить не буду, один тот факт, что для настройки контроллера и создания массивов (кроме самых простых режимов) — то нужно загрузиться с HP Smart Start, нормальный BIOS компания HP не осилила.
Опять таки — это если changelog доступен, что бывает совсем не всегда, особенно с биосами и прошивками.
В опенсурсе с этим всё попроще, можно просто посмотреть коммиты в GIT :) и решить — ставить или нет — обычно просто.
Так что если ченджлога нет — я обычно обновляю, за 10 лет работы еще не пожалел об этом.
Может я старомоден, но люблю когда под боком своя серверная и своё железо.
Если бы это были какие-то высоконагруженные веб-проекты, то, наверное, тоже бы арендовал.
А так это просто компания средних размеров и почти весь ИТ (кроме хостинга сайтов) варится внутри.
Просто LSI, в отличии от многих других компаний, предоставляет достаточно подробные Changelog-и, где можно четко увидеть что было исправлено в очередной версии прошивки. И местами там такое встречается, что может в определенных обстоятельствах привести к потере данных. Так что я стараюсь себя обезопасить заранее купировав возможные проблемы.
Судя по моей практике ситуации подобные этой встречаются крайне редко и, как видно, решаются достаточно просто, если знаешь что делать :)
Те же BIOS-ы в материнках Supermicro можно аналогично восстановить после неудачного обновления используя простую флешку в FAT, файлом биоса на ней под именем SUPER.ROM и зажатых клавиш Ctrl+Home при запуске сервера. Мне пока делать этого не приходилось, но на заметке держу…
Так что я голосую за обновление, если есть возможность и особенно если есть список изменений.
Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.
Вообще, у Pacemaker очень много возможностей — интересующиеся могут заглянуть в документацию, это не тема одной или даже нескольких статей.
Что такое «проверка по шатдауну» не понял. Да, и drbd живет в ядре, его kill -9 не возьмешь.
2. Какого рода тесты, например? Сеть выдёргивалась, питание одной из нод вырубалось, свитч один вырубался. Всё отрабатывало как надо.
И еще, так как практически весь рабочий софт находится в ядре (SCST, DRBD), то его сбой приведёт к краху ядра (особенно если включить дополнительно panic_on_oops) и нода, по сути, будет мертва, что обнаружит вторая нода.
Переброс IP-шника для ESXi проходит гладко, таймаут Corosync по умолчанию — 4 секунды, таймаут iSCSI в ESXi — 10 секунд.
Так что всё проходит очень быстро и практически незаметно для ВМ.
«У меня в сети» много Powershell-скриптов, еще больше Bash- и Perl-скриптов и вообще чего только нет — для каждой задачи свое оптимальное решение. Я веду к тому, что проблемы нужно решать системно и если эта задача уже была давно кем-то решена, то лучше использовать готовое решение, а не писать костыли и велосипеды.
Если для общего развития — я только за.
А вот что мне может помешать вместо двух Win2008R2 поставить два Linux я представить не могу. Разве что самодурство начальства или отсутствие свободного железа. Учитывая что для DHCP сервера можно использовать абсолютной любой сервер или даже (свят-свят) десктоп, последнее видится маловероятным.
И хотя я начинал знакомство с UNIX-like системами именно с FreeBSD, сейчас я не вижу смысла его использовать в большинстве проектов.
Причин много, например — существенно меньший выбор проектов, разрабатываемых параллельно ядру или включенных в него.
Так, есть аналог(скорее даже клон) DRBD под названием HAST, но он, судя по всему, работает вообще в пространстве пользователя и вряд-ли сможет тягаться по скорости (если что — бенчмарков не видел и не делал). Да и вообще возможностей у него относительно DRBD мало крайне: нет каких-либо контрольных сумм, только один протокол синхронизации (синхронный), ну и так далее.
C iSCSI и FC таргетами там, судя по всему, тоже выбор не велик, только то, что в ядре. В Linux же есть LIO (который уже в ядре, поддерживает уже даже 16Гбит FC, FCoE и вообще много чего), SCST (тоже много протоколов), STGT и еще много всякого — есть из чего выбрать.
Ну и поддержка производителей железа идет в первую очередь линуксу, а BSD уже во вторую очередь.
Так что нет, для себя смысла не вижу.
Коммутаторы по ~150т.р. Но от них для этой задачи вообще ничего кроме VLAN не требуется, так что подойдут любые гигабитные управляемые.
По поводу протокола B и dual-primary в доках DRBD чётко написано:
2. Зачем ему partitioning в режиме single-primary? DRBD вообще до последнего времени не подразумевало более двух нод, так что кворум в принципе не был возможен. Да и теперь, когда появилась возможность строить трехнодовую репликацию, по сути ничего не изменилось. Сам по себе DRBD не будет же переводить ресурсы в primary режим при потере связи и прочих бедах, это забота менеджера кластера, а там вопрос split-brain решается избыточностью heartbeat-каналов, этого в 99.9% достаточно.
3. Тут ничего не скажу, не мерял этот вопрос. В любом случае, если проблема встает, то метаданные можно вынести на отдельный массив из SSD.
4. Насчет dd — тут в общем и целом да, только вот в случае с dm-crypt ситуация получается странная — скорость с oflag=direct получается ниже, а с iflag=direct (при, соответственно, чтении) — выше. Тут, я думаю, дело в том, что dm-crypt берёт блоки из кеша пачкой и разбрасывает их по worker-ам на разных ядрах. А при обходе кеша он этого делать не может, поэтому получается в разы медленнее.
5. Для этого в бондинге есть ARP-мониторинг, выбираем IP-адрес соседа для ARP-запросов и как только он перестал отвечать — бондинг будет считать что соответствуюший интерфейс упал. На свичах есть похожий протокол UDLD для определения что одно из волокон (передающее или принимающее, если это не WDM) помёрло.
И у них это почти получилось :) Непонятно только зачем образ восстановления пытается шить в обычном режиме, а не в Mode0, ну и косяк с виртуальным приводом CDROM, который во всех остальных местах работает ОК.
Опция -a указывает какие контроллеры шить, например -a0,1 или -aALL, а вот уже в режиме восстановления (Mode0) этой опции вообще нет.
Один из контроллеров (52445, огромный такой, на 28 портов, бешеных денег стоил) у меня первые пару лет работы периодически глючил — то сам контроллер в резет уходит, то винты с него отваливаются с большим кол-вом I/O ошибок, хотя они здоровые (это решилось обновлением прошивки самих винтов, хотя с другими контроллерами они не глючили), то еще какая-то напасть. Он до сих пор трудится и после крайнего обновления прошивки вроде как успокоился глючить и работает ровно :)
А про Smart Array вообще лучше говорить не буду, один тот факт, что для настройки контроллера и создания массивов (кроме самых простых режимов) — то нужно загрузиться с HP Smart Start, нормальный BIOS компания HP не осилила.
В опенсурсе с этим всё попроще, можно просто посмотреть коммиты в GIT :) и решить — ставить или нет — обычно просто.
Так что если ченджлога нет — я обычно обновляю, за 10 лет работы еще не пожалел об этом.
Если бы это были какие-то высоконагруженные веб-проекты, то, наверное, тоже бы арендовал.
А так это просто компания средних размеров и почти весь ИТ (кроме хостинга сайтов) варится внутри.
Но из принципа захотелось его побороть :)
Просто LSI, в отличии от многих других компаний, предоставляет достаточно подробные Changelog-и, где можно четко увидеть что было исправлено в очередной версии прошивки. И местами там такое встречается, что может в определенных обстоятельствах привести к потере данных. Так что я стараюсь себя обезопасить заранее купировав возможные проблемы.
Судя по моей практике ситуации подобные этой встречаются крайне редко и, как видно, решаются достаточно просто, если знаешь что делать :)
Те же BIOS-ы в материнках Supermicro можно аналогично восстановить после неудачного обновления используя простую флешку в FAT, файлом биоса на ней под именем SUPER.ROM и зажатых клавиш Ctrl+Home при запуске сервера. Мне пока делать этого не приходилось, но на заметке держу…
Так что я голосую за обновление, если есть возможность и особенно если есть список изменений.