1. На данный момент он работает так, как написано в документации — если падает хоть один ресурс, то все ресурсы переезжают на запасную ноду.
Я в общем-то и не предоставляю сервис — я делаю высокодоступное хранилище для своего же vSphere кластера, не более того.
Я понимаю, что можно много чего навертеть и добавить еще пару девяток к доступности, но мне хватает и того, что есть :)
А предоставление сервиса и все прочие параметры (состояние дисков, массивов, DRBD, сети и т.п.) у меня мониторятся отдельно Zabbix-ом и если что-то происходит не предусмотренное конфигом кластера, то я буду реагировать уже сам.
Насчет STONITH я думал (на основе IPMI), но решил, что это избыточно.
А третью witness-ноду да, смысл сделать имеет, только вот в Pacemaker нет простого сбособа добавить просто ноду-свидетеля.
Можно сделать третьей ноде standby=on, но на ней должны быть все те же ресурсы (DRBD по крайней мере), т.к. кластер будет их пытаться мониторить. Второй способ — не запускать вообще Pacemaker, а оставить только Corosync, но я не уверен что это хорошая идея, нужно проверять. Но скорее всего этот способ самый оптимальный.
2. Что значит — отваливается? Глюк в софте? Тогда ядро уйдёт в резет сразу, это настраивается в sysctl (kernel.panic)
Во-вторых, даже если это так — это что же, тяжело нагруженная виртуалка 4 секунды будет висеть ожидая доступ к диску?
А в чем проблема? Во всех распространенных ОСях таймаут на I/O к диску гораздо выше (в линуксе минута, в винде тоже вроде) и его всегда можно задрать при необходимости.
Я специально делал виртуалку, которая во всю прыть писала на диск и убивал активную ноду по питанию — никакой ругани со стороны гостевой ОС не было, всё продолжало работать как надо.
DRBD добавили таки в ядро? Ну надо же. Клёво.
Да, добавили, но это ничего не меняет.
Модулем оно или в ядро интегрировано — разницы с точки зрения работы никакой.
Я, как видно, собираю его модулем т.к. в ядре более старая версия.
3.
Были ли за время использования подобной схемы в production сбои у вас, когда одна из нод по тем или иным причинам падала?
Стандартно ли отрабатывало переключение кластера и не было ли проблем на виртуалках в ESXi?
Нет, тьфу тьфу, всё работает пока чётко. Но перед продакшеном я, как писал выше, всякое симулировал и вело оно себя предсказуемо.
Поясню свой вопрос — подобные схемы способны жить годами пока, в какой-то момент не окажется, что они не работают.
Я согласен, что в моей конфигурации не всё предусмотрено, но для конкретно моих требований этого более чем достаточно.
И я постарался поведение кластера проверить во всех более или менее реальных ситуациях.
Чтобы иметь отказоустойчивое хранилище конечно, зачем же еще?
Клиенты подключаются к общим IP-адресам по iSCSI, которые в один момент времени подняты на одной из нод.
При отказе одной из нод всю работу берёт на себя вторая прозрачно для клиентов.
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 лет работы еще не пожалел об этом.
Может я старомоден, но люблю когда под боком своя серверная и своё железо.
Если бы это были какие-то высоконагруженные веб-проекты, то, наверное, тоже бы арендовал.
А так это просто компания средних размеров и почти весь ИТ (кроме хостинга сайтов) варится внутри.
Я в общем-то и не предоставляю сервис — я делаю высокодоступное хранилище для своего же vSphere кластера, не более того.
Я понимаю, что можно много чего навертеть и добавить еще пару девяток к доступности, но мне хватает и того, что есть :)
А предоставление сервиса и все прочие параметры (состояние дисков, массивов, DRBD, сети и т.п.) у меня мониторятся отдельно Zabbix-ом и если что-то происходит не предусмотренное конфигом кластера, то я буду реагировать уже сам.
Насчет STONITH я думал (на основе IPMI), но решил, что это избыточно.
А третью witness-ноду да, смысл сделать имеет, только вот в Pacemaker нет простого сбособа добавить просто ноду-свидетеля.
Можно сделать третьей ноде standby=on, но на ней должны быть все те же ресурсы (DRBD по крайней мере), т.к. кластер будет их пытаться мониторить. Второй способ — не запускать вообще Pacemaker, а оставить только Corosync, но я не уверен что это хорошая идея, нужно проверять. Но скорее всего этот способ самый оптимальный.
2. Что значит — отваливается? Глюк в софте? Тогда ядро уйдёт в резет сразу, это настраивается в sysctl (kernel.panic)
А в чем проблема? Во всех распространенных ОСях таймаут на I/O к диску гораздо выше (в линуксе минута, в винде тоже вроде) и его всегда можно задрать при необходимости.
Я специально делал виртуалку, которая во всю прыть писала на диск и убивал активную ноду по питанию — никакой ругани со стороны гостевой ОС не было, всё продолжало работать как надо.
Да, добавили, но это ничего не меняет.
Модулем оно или в ядро интегрировано — разницы с точки зрения работы никакой.
Я, как видно, собираю его модулем т.к. в ядре более старая версия.
3.
Нет, тьфу тьфу, всё работает пока чётко. Но перед продакшеном я, как писал выше, всякое симулировал и вело оно себя предсказуемо.
Я согласен, что в моей конфигурации не всё предусмотрено, но для конкретно моих требований этого более чем достаточно.
И я постарался поведение кластера проверить во всех более или менее реальных ситуациях.
Клиенты подключаются к общим IP-адресам по iSCSI, которые в один момент времени подняты на одной из нод.
При отказе одной из нод всю работу берёт на себя вторая прозрачно для клиентов.
Перед запуском кластера я систему очень долго мучал, и стабильность софтовой части меня более чем устроила, поэтому я пока не стал активировать этот режим — если кому-то это нужно, то делается это в два счета.
Вообще, у 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 лет работы еще не пожалел об этом.
Если бы это были какие-то высоконагруженные веб-проекты, то, наверное, тоже бы арендовал.
А так это просто компания средних размеров и почти весь ИТ (кроме хостинга сайтов) варится внутри.
Но из принципа захотелось его побороть :)