Привет, Хабр! Представляю вашему вниманию перевод статьи «Two Nodes — The Devil is in the Details» автора Andrew Beekhof.
Многие люди предпочитают кластеры состоящие из двух узлов, потому что они кажутся концептуально более простыми, кроме того еще и на 33% более дешевыми чем их трех-узловые собратья. Хотя вполне реально собрать хороший кластер из двух узлов, в большинстве случаев, из-за неучтенных сценариев, такая конфигурация создаст множество неочевидных проблем.
Первым шагом к созданию любой системы высокой доступности является поиск и попытка устранения отдельных точек отказа, часто сокращенно называемыми SPoF (single point of failure).
Стоит иметь в виду, что в любой системе невозможно устранить все возможные риски простоя. Это вытекает хотя бы из того факта, что типичной защитой от риска является ввод некоторой избыточности, что приводит к увеличению сложности системы и появлению новых точек отказа. Потому мы изначально идем на компромисс и сосредотачиваемся на событиях связанных с отдельными точками отказа, а не на цепочках связанных и, следовательно, все менее вероятных событий.
Учитывая компромиссы, мы не только ищем SPoF, но также подводим баланс рисков и последствий, в результате вывод что является критичным, а что нет может отличаться для каждого развертывания.
Естественной отправной точкой является наличие в системе более одного узла. Однако, прежде чем система сможет переместить сервисы на оставшийся в живых после сбоя узел, в общем случае, необходимо убедиться, что перемещаемые сервисы не активны в каком-то другом месте.
У двухузлового кластера нет недостатков, если в результате сбоя оба узла обслуживают один и тот же статический веб-сайт. Однако все меняется, если в результате обе стороны независимо управляют общей очередью заданий или предоставляют нескоординированный доступ на запись к реплицированной базе данных или общей файловой системе.
Поэтому, чтобы предотвратить повреждение данных в результате отказа одного узла – мы полагаемся на то, что называется «отмежевание» (fencing).
В основе принципа отмежевания лежит вопрос: может ли конкурирующий узел вызвать повреждение данных? В случае, если повреждение данных является вероятным сценарием – хорошим решением будет изоляция узла как от входящих запросов, так и от постоянного хранилища. Наиболее распространенный подход к отмежеванию — отключение неисправных узлов.
Есть две категории методов отмежевания, которые я назову прямыми и косвенными, но в равной степени их можно назвать активными и пассивными. Прямые методы включают в себя действия со стороны выживших одноранговых узлов, такие как взаимодействие с устройством IPMI (Intelligent Platform Management Interface — интерфейс для удаленного мониторинга и управления физическим состоянием сервера) или iLO (механизм управления серверами в условиях отсутствия физического доступа к ним), в то время как косвенные методы полагаются на отказавший узел, чтобы каким-то образом распознать, что он находится в нездоровом состоянии (или, по крайней мере, мешает остальным членам восстанавливаться) и сигнализировать hardware watchdog о необходимости отключения отказавшего узла.
Кворум, помогает в случае использования как прямых так и косвенных методов.
В случае прямого отмежевания мы можем использовать кворум для предотвращения гонок отмежевания в случае сбоя сети.
Располагая концепцией кворума, в системе достаточно информации (даже без подключения к своим партнерам), чтобы узлы автоматически знали, следует ли им инициировать отмежевание и / или восстановление.
Без кворума обе стороны сетевого разделения справедливо предполагают, что другая сторона мертва, и будут стремиться отмежевать другого. В худшем случае обеим сторонам удается отключить весь кластер. Альтернативный сценарий — deathmatch, бесконечный цикл узлов, появляющихся, не видящих своих пиров, перезагружающих их и инициирующих восстановление только для перезагрузки, когда их пир проходит по той же логике.
Проблема с отмежеванием состоит в том, что наиболее часто используемые устройства становятся недоступными из-за тех же событий отказа, на которые мы хотим ориентироваться для восстановления. Большинство карт IPMI и iLO установлены на хостах, которые они контролируют, и, по умолчанию, используют одну и ту же сеть, из-за которой целевые узлы полагают, что остальные узлы находятся в оффлайне.
К сожалению, особенности работы устройств IPMI и iLo редко рассматриваются в момент покупки оборудования.
Кворум также важен для управления косвенным отмежеваниями, если все сделано правильно, кворум может позволить выжившим предположить, что потерянные узлы через определенный период времени перейдут в безопасное состояние.
При такой настройке таймер hardware watchdog сбрасывается каждые N секунд, если кворум не потерян. Если таймер (обычно несколько кратных N) истекает, то устройство выполняет ungraceful отключение питания (не shutdown).
Данный подход является очень эффективным, но без кворума для его управления недостаточно информации внутри кластера. Нелегко определить разницу между отключением сети и отказом узла-партнера. Причина, по которой это имеет значение, заключается в том, что без возможности различать два случая вы вынуждены выбирать одинаковый режим поведения в обоих случаях.
Проблема с выбором одного режима заключается в том, что не существует способа действий, который бы максимально увеличивал доступность и предотвращал потерю данных.
Независимо от того, какую эвристику вы используете, тривиально создать сбой, который либо заставит обе стороны работать, либо заставит кластер отключить выжившие узлы. Неиспользование кворума действительно лишает кластер одного из самых мощных инструментов в его арсенале.
Если нет другой альтернативы, лучшим подходом будет пожертвовать доступностью (тут автор отсылает к CAP-теореме). Высокая доступность поврежденных данных никому не помогает, и выверка вручную различных наборов данных также не доставляет удовольствия.
Кворум звучит здорово, правда?
Единственный недостаток состоит в том, что для того, чтобы иметь его в кластере с N членами, вам нужно чтобы оставалось соединение между N / 2 + 1 ваших узлов. Что невозможно в кластере с двумя узлами после сбоя одного узла.
Что в конечном итоге подводит нас к фундаментальной проблеме с двумя узлами:
кворум не имеет смысла в двух узловых кластерах, и без этого невозможно надежно определить курс действий, который максимально увеличивает доступность и предотвращает потерю данных
Даже в системе из двух узлов, соединенных кросс-кабелем, невозможно окончательно провести различие между отключением сети и отказом другого узла. Отключения одного конца (вероятность которого, безусловно, пропорциональна расстоянию между узлами) будет достаточно, чтобы опровергнуть любое предположение о том, что работоспособность канала равна здоровью узла-партнера.
Иногда клиент не может или не желает докупать третий узел, и мы вынуждены искать альтернативу.
Устройство iLO или IPMI узла представляет собой точку отказа, поскольку, в случае сбоя, оставшиеся в живых не могут использовать его для перевода узла в безопасное состояние. В кластере из 3 или более узлов мы можем смягчить это вычислением кворума и использованием hardware watchdog (механизм косвенного отмежевания, как обсуждалось ранее). В случае с двумя узлами мы должны вместо этого использовать сетевые переключатели питания (power distribution units или PDUs).
После сбоя выживший сначала пытается связаться с основным устройством отмежевания (встроенным iLO или IPMI). Если это удалось, восстановление продолжается как обычно. Только в случае сбоя устройства iLO / IPMI происходит обращение к PDU, если обращение успешно, восстановление может продолжаться.
Обязательно поместите PDU в сеть, отличную от трафика кластера, в противном случае одиночный сбой в сети заблокирует доступ как к устройствам отмежевания, так и заблокирует восстановление служб.
Тут Вы можете спросить – не является ли устройство PDU единой точкой отказа? На что ответ — конечно является.
Если этот риск значим для вас — вы не одиноки: подключите оба узла к двум PDU и укажите кластерному программному обеспечению использовать оба при включении и выключении узлов. Теперь кластер остается активным, если один PDU умирает, и для блокировки восстановления потребуется второй сбой либо другого PDU, либо устройства IPMI.
В некоторых сценариях, хотя технически возможен метод дублирующего отмежевания, он политически сложен. Многим компаниям нравится иметь определенное разделение между администраторами и владельцами приложений, и заботящиеся о безопасности сетевые администраторы не всегда с энтузиазмом относятся к передаче кому бы то ни было параметров доступа к PDU.
В этом случае рекомендуемой альтернативой является создание нейтральной третьей стороны, которая может дополнить расчет кворума.
В случае сбоя узел должен иметь возможность видеть эфир своего партнера или арбитра, чтобы восстановить сервисы. Арбитр также включает в себя функцию разрыва связи, если оба узла могут видеть арбитра, но не видят друг друга.
Эта опция должна использоваться в паре с косвенным методом отмежевания, таким как hardware watchdog таймер, который настроен на гашение машины, если она теряет соединение со своим узлом-партнером и арбитром. Таким образом, выживший может с достаточной уверенностью предположить, что его узел–партнер будет в безопасном состоянии после истечения срока действия hardware watchdog таймера.
Практическое различие между арбитром и третьим узлом состоит в том, что арбитр требует гораздо меньше ресурсов для своей работы и, потенциально, может обслуживать более одного кластера.
Последний подход заключается в том, чтобы выжившие продолжали выполнять любые службы, которые они уже выполняли, но не запускать новые, пока либо проблема не решится сама (восстановление сети, перезагрузка узла), либо человек не возьмет на себя ответственность за ручное подтверждение того, что другая сторона мертва.
Я уже говорил, что вы можете добавить третий узел?
Ради аргумента, давайте представим, что я убедил вас в достоинствах третьего узла, теперь мы должны рассмотреть физическое расположение узлов. Если они размещены (и получают питание) в той же стойке, это также представляет собой SPoF, и такую, которая не может быть решена путем добавления второй стойки.
Если это удивительно, подумайте, что произойдет, если стойка с двумя узлами выйдет из строя, и как выживший узел будет различать этот случай и сбой сети.
Короткий ответ: это невозможно, и мы снова имеем дело со всеми проблемами в случае с двумя узлами. Либо выживший:
В любом случае, две стойки не лучше одной, и узлы должны либо получать независимые источники питания, либо распределяться по трем (или более, в зависимости от того, сколько у вас узлов) стойкам.
К этому моменту читатели, которые больше не склонны к риску, могут подумать о восстановлении после аварии. Что происходит, когда астероид попадает в один центр обработки данных с нашими тремя узлами, распределенными по трем различным стойкам? Очевидно, что Bad Things, но в зависимости от ваших потребностей, добавление второго дата-центра может быть недостаточно.
Если все сделано правильно, второй дата-центр предоставляет вам (и это разумно) актуальную и согласованную копию ваших сервисов и их данных. Однако, как и в сценариях с двумя узлами и двумя стойками, в системе недостаточно информации для обеспечения максимальной доступности и предотвращения повреждения (или расхождения наборов данных). Даже при наличии трех узлов (или стоек) их распределение только по двум центрам обработки данных оставляет систему неспособной надежно принять правильное решение в случае (теперь гораздо более вероятного) события, которое обе стороны не могут связать.
Это не означает, что решение с двумя дата-центрами никогда не подходит. Компании нередко хотят, чтобы человек был в курсе, прежде чем предпринять исключительный шаг при переходе на резервный дата-центр. Просто имейте в виду, что если вы хотите автоматизировать сбой, вам понадобится либо третий дата-центр, чтобы кворум имел смысл (напрямую или через арбитра), либо вы найдете способ надежно отключить весь дата-центр.
Многие люди предпочитают кластеры состоящие из двух узлов, потому что они кажутся концептуально более простыми, кроме того еще и на 33% более дешевыми чем их трех-узловые собратья. Хотя вполне реально собрать хороший кластер из двух узлов, в большинстве случаев, из-за неучтенных сценариев, такая конфигурация создаст множество неочевидных проблем.
Первым шагом к созданию любой системы высокой доступности является поиск и попытка устранения отдельных точек отказа, часто сокращенно называемыми SPoF (single point of failure).
Стоит иметь в виду, что в любой системе невозможно устранить все возможные риски простоя. Это вытекает хотя бы из того факта, что типичной защитой от риска является ввод некоторой избыточности, что приводит к увеличению сложности системы и появлению новых точек отказа. Потому мы изначально идем на компромисс и сосредотачиваемся на событиях связанных с отдельными точками отказа, а не на цепочках связанных и, следовательно, все менее вероятных событий.
Учитывая компромиссы, мы не только ищем SPoF, но также подводим баланс рисков и последствий, в результате вывод что является критичным, а что нет может отличаться для каждого развертывания.
Не всем нужны альтернативные поставщики электроэнергии с независимыми линиями электропередачи. Хотя паранойя окупилась по крайней мере для одного клиента, когда их мониторинг обнаружил неисправный трансформатор. Заказчик звонил по телефону, пытаясь предупредить энергетическую компанию, до тех пор пока неисправный трансформатор не взорвался.
Естественной отправной точкой является наличие в системе более одного узла. Однако, прежде чем система сможет переместить сервисы на оставшийся в живых после сбоя узел, в общем случае, необходимо убедиться, что перемещаемые сервисы не активны в каком-то другом месте.
У двухузлового кластера нет недостатков, если в результате сбоя оба узла обслуживают один и тот же статический веб-сайт. Однако все меняется, если в результате обе стороны независимо управляют общей очередью заданий или предоставляют нескоординированный доступ на запись к реплицированной базе данных или общей файловой системе.
Поэтому, чтобы предотвратить повреждение данных в результате отказа одного узла – мы полагаемся на то, что называется «отмежевание» (fencing).
Принцип отмежевания
В основе принципа отмежевания лежит вопрос: может ли конкурирующий узел вызвать повреждение данных? В случае, если повреждение данных является вероятным сценарием – хорошим решением будет изоляция узла как от входящих запросов, так и от постоянного хранилища. Наиболее распространенный подход к отмежеванию — отключение неисправных узлов.
Есть две категории методов отмежевания, которые я назову прямыми и косвенными, но в равной степени их можно назвать активными и пассивными. Прямые методы включают в себя действия со стороны выживших одноранговых узлов, такие как взаимодействие с устройством IPMI (Intelligent Platform Management Interface — интерфейс для удаленного мониторинга и управления физическим состоянием сервера) или iLO (механизм управления серверами в условиях отсутствия физического доступа к ним), в то время как косвенные методы полагаются на отказавший узел, чтобы каким-то образом распознать, что он находится в нездоровом состоянии (или, по крайней мере, мешает остальным членам восстанавливаться) и сигнализировать hardware watchdog о необходимости отключения отказавшего узла.
Кворум, помогает в случае использования как прямых так и косвенных методов.
Прямое отмежевание
В случае прямого отмежевания мы можем использовать кворум для предотвращения гонок отмежевания в случае сбоя сети.
Располагая концепцией кворума, в системе достаточно информации (даже без подключения к своим партнерам), чтобы узлы автоматически знали, следует ли им инициировать отмежевание и / или восстановление.
Без кворума обе стороны сетевого разделения справедливо предполагают, что другая сторона мертва, и будут стремиться отмежевать другого. В худшем случае обеим сторонам удается отключить весь кластер. Альтернативный сценарий — deathmatch, бесконечный цикл узлов, появляющихся, не видящих своих пиров, перезагружающих их и инициирующих восстановление только для перезагрузки, когда их пир проходит по той же логике.
Проблема с отмежеванием состоит в том, что наиболее часто используемые устройства становятся недоступными из-за тех же событий отказа, на которые мы хотим ориентироваться для восстановления. Большинство карт IPMI и iLO установлены на хостах, которые они контролируют, и, по умолчанию, используют одну и ту же сеть, из-за которой целевые узлы полагают, что остальные узлы находятся в оффлайне.
К сожалению, особенности работы устройств IPMI и iLo редко рассматриваются в момент покупки оборудования.
Косвенное отмежевание
Кворум также важен для управления косвенным отмежеваниями, если все сделано правильно, кворум может позволить выжившим предположить, что потерянные узлы через определенный период времени перейдут в безопасное состояние.
При такой настройке таймер hardware watchdog сбрасывается каждые N секунд, если кворум не потерян. Если таймер (обычно несколько кратных N) истекает, то устройство выполняет ungraceful отключение питания (не shutdown).
Данный подход является очень эффективным, но без кворума для его управления недостаточно информации внутри кластера. Нелегко определить разницу между отключением сети и отказом узла-партнера. Причина, по которой это имеет значение, заключается в том, что без возможности различать два случая вы вынуждены выбирать одинаковый режим поведения в обоих случаях.
Проблема с выбором одного режима заключается в том, что не существует способа действий, который бы максимально увеличивал доступность и предотвращал потерю данных.
- Если вы решите предположить, что узел-партнер активен, но на самом деле произошел сбой, кластер излишне остановит службы, которые должны были бы работать для компенсации потери служб упавшего узла-партнера.
- Если вы решите предположить, что узел не работает, но это был просто сбой сети и на самом деле удаленный узел функционирует, то, в лучшем случае, вы подписываетесь на некоторую будущую ручную сверку результирующих наборов данных.
Независимо от того, какую эвристику вы используете, тривиально создать сбой, который либо заставит обе стороны работать, либо заставит кластер отключить выжившие узлы. Неиспользование кворума действительно лишает кластер одного из самых мощных инструментов в его арсенале.
Если нет другой альтернативы, лучшим подходом будет пожертвовать доступностью (тут автор отсылает к CAP-теореме). Высокая доступность поврежденных данных никому не помогает, и выверка вручную различных наборов данных также не доставляет удовольствия.
Кворум
Кворум звучит здорово, правда?
Единственный недостаток состоит в том, что для того, чтобы иметь его в кластере с N членами, вам нужно чтобы оставалось соединение между N / 2 + 1 ваших узлов. Что невозможно в кластере с двумя узлами после сбоя одного узла.
Что в конечном итоге подводит нас к фундаментальной проблеме с двумя узлами:
кворум не имеет смысла в двух узловых кластерах, и без этого невозможно надежно определить курс действий, который максимально увеличивает доступность и предотвращает потерю данных
Даже в системе из двух узлов, соединенных кросс-кабелем, невозможно окончательно провести различие между отключением сети и отказом другого узла. Отключения одного конца (вероятность которого, безусловно, пропорциональна расстоянию между узлами) будет достаточно, чтобы опровергнуть любое предположение о том, что работоспособность канала равна здоровью узла-партнера.
Заставляем работать кластер из двух узлов
Иногда клиент не может или не желает докупать третий узел, и мы вынуждены искать альтернативу.
Вариант 1 — Дублирующий метод отмежевания
Устройство iLO или IPMI узла представляет собой точку отказа, поскольку, в случае сбоя, оставшиеся в живых не могут использовать его для перевода узла в безопасное состояние. В кластере из 3 или более узлов мы можем смягчить это вычислением кворума и использованием hardware watchdog (механизм косвенного отмежевания, как обсуждалось ранее). В случае с двумя узлами мы должны вместо этого использовать сетевые переключатели питания (power distribution units или PDUs).
После сбоя выживший сначала пытается связаться с основным устройством отмежевания (встроенным iLO или IPMI). Если это удалось, восстановление продолжается как обычно. Только в случае сбоя устройства iLO / IPMI происходит обращение к PDU, если обращение успешно, восстановление может продолжаться.
Обязательно поместите PDU в сеть, отличную от трафика кластера, в противном случае одиночный сбой в сети заблокирует доступ как к устройствам отмежевания, так и заблокирует восстановление служб.
Тут Вы можете спросить – не является ли устройство PDU единой точкой отказа? На что ответ — конечно является.
Если этот риск значим для вас — вы не одиноки: подключите оба узла к двум PDU и укажите кластерному программному обеспечению использовать оба при включении и выключении узлов. Теперь кластер остается активным, если один PDU умирает, и для блокировки восстановления потребуется второй сбой либо другого PDU, либо устройства IPMI.
Вариант 2 — Добавление арбитра
В некоторых сценариях, хотя технически возможен метод дублирующего отмежевания, он политически сложен. Многим компаниям нравится иметь определенное разделение между администраторами и владельцами приложений, и заботящиеся о безопасности сетевые администраторы не всегда с энтузиазмом относятся к передаче кому бы то ни было параметров доступа к PDU.
В этом случае рекомендуемой альтернативой является создание нейтральной третьей стороны, которая может дополнить расчет кворума.
В случае сбоя узел должен иметь возможность видеть эфир своего партнера или арбитра, чтобы восстановить сервисы. Арбитр также включает в себя функцию разрыва связи, если оба узла могут видеть арбитра, но не видят друг друга.
Эта опция должна использоваться в паре с косвенным методом отмежевания, таким как hardware watchdog таймер, который настроен на гашение машины, если она теряет соединение со своим узлом-партнером и арбитром. Таким образом, выживший может с достаточной уверенностью предположить, что его узел–партнер будет в безопасном состоянии после истечения срока действия hardware watchdog таймера.
Практическое различие между арбитром и третьим узлом состоит в том, что арбитр требует гораздо меньше ресурсов для своей работы и, потенциально, может обслуживать более одного кластера.
Вариант 3 — Человеческий фактор
Последний подход заключается в том, чтобы выжившие продолжали выполнять любые службы, которые они уже выполняли, но не запускать новые, пока либо проблема не решится сама (восстановление сети, перезагрузка узла), либо человек не возьмет на себя ответственность за ручное подтверждение того, что другая сторона мертва.
Бонусная опция
Я уже говорил, что вы можете добавить третий узел?
Две стойки
Ради аргумента, давайте представим, что я убедил вас в достоинствах третьего узла, теперь мы должны рассмотреть физическое расположение узлов. Если они размещены (и получают питание) в той же стойке, это также представляет собой SPoF, и такую, которая не может быть решена путем добавления второй стойки.
Если это удивительно, подумайте, что произойдет, если стойка с двумя узлами выйдет из строя, и как выживший узел будет различать этот случай и сбой сети.
Короткий ответ: это невозможно, и мы снова имеем дело со всеми проблемами в случае с двумя узлами. Либо выживший:
- игнорирует кворум и неправильно пытается инициировать восстановление во время перебоев в работе сети (возможность завершения отмежевания — это отдельная история и зависит от того, задействован ли PDU и разделяют ли они мощность с какой-либо из стоек), или
- уважает кворум и преждевременно отключает себя, когда его узел-партнер терпит неудачу
В любом случае, две стойки не лучше одной, и узлы должны либо получать независимые источники питания, либо распределяться по трем (или более, в зависимости от того, сколько у вас узлов) стойкам.
Два дата-центра
К этому моменту читатели, которые больше не склонны к риску, могут подумать о восстановлении после аварии. Что происходит, когда астероид попадает в один центр обработки данных с нашими тремя узлами, распределенными по трем различным стойкам? Очевидно, что Bad Things, но в зависимости от ваших потребностей, добавление второго дата-центра может быть недостаточно.
Если все сделано правильно, второй дата-центр предоставляет вам (и это разумно) актуальную и согласованную копию ваших сервисов и их данных. Однако, как и в сценариях с двумя узлами и двумя стойками, в системе недостаточно информации для обеспечения максимальной доступности и предотвращения повреждения (или расхождения наборов данных). Даже при наличии трех узлов (или стоек) их распределение только по двум центрам обработки данных оставляет систему неспособной надежно принять правильное решение в случае (теперь гораздо более вероятного) события, которое обе стороны не могут связать.
Это не означает, что решение с двумя дата-центрами никогда не подходит. Компании нередко хотят, чтобы человек был в курсе, прежде чем предпринять исключительный шаг при переходе на резервный дата-центр. Просто имейте в виду, что если вы хотите автоматизировать сбой, вам понадобится либо третий дата-центр, чтобы кворум имел смысл (напрямую или через арбитра), либо вы найдете способ надежно отключить весь дата-центр.
