Документация DRBD (в разделе Интеграция DRBD с кластерами Pacemaker) рекомендует отключить DRBD в кластере Pacemaker:
Если вы используете агент ресурсов DRBD OCF, рекомендуется отложить запуск, завершение работы, повышение и понижение роли DRBD исключительно агенту ресурсов OCF. Это означает, что вы должны отключить сценарий инициализации DRBD:
chkconfig drbd off.
Под systemd это составит systemctl disable drbd.service.
Есть ли вред от включения DRBD, несмотря на эту рекомендацию? Идея состоит в том, чтобы включить DRBD, но отключить Corosync и Pacemaker, чтобы после отказа узла кластера и перезагрузки он продолжал получать данные, синхронизированные с DRBD, но в противном случае оставался «пассивным». Это должно позволить проанализировать отказавший узел, прежде чем он сможет повторно войти в кластер, но тем временем текущие данные все еще сохраняются на обоих узлах кластера. В чем причина рекомендации, которая перевесит это обоснование?
Намерение отключить службу DRBD на уровне ОС состоит в том, что все управляется кардиостимулятором. Если две службы (например, PCMK и ваша ОС) пытаются запустить / остановить / повысить / понизить роль и т. Д., Вы рискуете раздвоиться. Для контролируемой кластерной среды все должно обрабатываться вашим диспетчером ресурсов кластера, в данном случае регулятором ритма, чтобы избежать путаницы между узлами кластера. В случае разделения мозга или подобного вам CRM будет либо STONITH, либо ограждать, либо использовать настроенный кворум на других узлах для решения этой проблемы.
Уже есть два ответа, в которых четко указано, что это плохая идея и почему, но, возможно, некоторые подробности о том, как это может пойти не так для вас и как вы можете использовать Pacemaker для решения этих проблем, помогут убедить вас и / или других не делай так.
Во-первых, Pacemaker регистрирует и учитывает сбои ресурсов. Счетчик сбоев по умолчанию для ресурса до того, как он будет «забанен» узлом, равен трем в пределах окна тайм-аута сбоя ресурса, которое по умолчанию никогда не истекает. Таким образом, если ваш ресурс DRBD (или любой другой ресурс, если на то пошло) выходит из строя три раза подряд, он блокируется на своем текущем активном узле с помощью сильного (бесконечного) «ограничения отрицательного местоположения», что означает, что ресурс может работать где угодно, НО его текущий активный узел. Как только это правило действует, ресурс либо перемещается в другое место, если это возможно, либо останавливается до тех пор, пока его сбои не будут устранены.
Как видите, Pacemaker можно заставить самостоятельно справляться с этими сбоями.
Вам необходимо понять, что такое Pacemaker и как он себя ведет, чтобы понять, почему управление ресурсами, которые он обеспечивает за пределами Pacemaker, - это плохо. Кардиостимулятор - это система с конечным числом состояний. Это зависит от полного контроля над ресурсами, которыми он управляет, чтобы он мог корректно восстанавливаться после сбоев и гарантировать, что ресурсы либо остановлены, либо запущены там, где они должны быть.
Рассмотрим простой ресурс, который должен запускаться только на одном узле за раз, чтобы он не стал «разделенным мозгом» и не создал расходящийся набор данных - это самое худшее, что может случиться, поскольку это почти наверняка вызовет потерю данных или потребует большое внимание оператора для предотвращения потери данных.
Pacemaker управляет этим ресурсом и запускает экземпляр программного обеспечения на узле «Able». Администратор из лучших побуждений обнаруживает, что служба запущена на Able, но ее файл модуля systemd "отключен". Этот администратор включает файл модуля, чтобы служба "возвращалась" после перезагрузки, не зная, что Pacemaker уже обрабатывает это. Юнит-файл systemd настроен на перезапуск ресурса в случае сбоя, как и многие другие.
Как только Pacemaker пытается перенести этот ресурс с Able на второй узел в кластере «Baker», ресурс сталкивается с ошибкой остановки, так как служба была остановлена, но каким-то образом она все еще жива, и мы находимся в середине зомби-апокалипсиса. Поскольку ресурс не может быть остановлен, он не может быть запущен в Бейкере, не вызывая состояния раздвоения мозга. Ресурсы колеблются между остановкой и запуском, поскольку systemd и Pacemaker сражаются за контроль. В конце концов, Pacemaker «отказывается» от ресурса и переводит его в «неуправляемый режим», что означает, что для этого ресурса не будут выполняться операции запуска или остановки.
Таким образом, в этом сценарии Systemd победил, потому что был «глупее и настойчивее», чем Pacemaker. Это чрезвычайно сложно понять администратору, который не знаком с поведением Pacemaker и Systemd, так как это будет просто выглядеть так, как будто Pacemaker дает сбой повсюду - тогда как на самом деле он делает именно то, что должен делать в данных условиях. под рукой.
Также учтите, что у приведенного выше сценария был наилучший возможный финал для этого условия. При малейшем сбое инфраструктуры кластер стал бы разделенным мозгом с активным ресурсом на обоих узлах.
Кроме того, ограждение через STONTIH предотвратит превращение кластера в разделение мозга в этом сценарии, но STONITH - это последнее средство стабильности кластера, в то время как вышеуказанное условие делает его почти первым средством. И, как всегда, вам НУЖЕН STONITH, чтобы подготовить кластер к работе.
При использовании менеджер ресурсов кластера, любой ресурс должен контролироваться, ну, менеджером ресурсов. Любой ресурс, включенный / отключенный извне диспетчера ресурсов кластера, является потенциальным источником путаницы как для администратора, так и для самого диспетчера ресурсов.