Заметки о Windows и других программных продуктах Microsoft...

Кворумные модели в Windows Server 2012 R2

Кворумные модели в Windows Server 2012 R2

Кворум (Quorum) в переводе с латыни означает большинство, а кворумные модели используется в отказоустойчивых кластерах Windows для определения работоспособности кластера. При выходе из строя одного или нескольких узлов кластера среди оставшихся проводится голосование, и если они набирают большинство голосов (кворум), то кластер продолжает работу, если же не набирают — кластер останавливается.

Служба кластера (Failover Clustering) появилась еще в Windows NT 4.0. Тогда под кластером подразумевалось два узла (Node), объединенные вместе и имеющие доступ к общему хранилищу, на котором располагался кворумный диск, или диск-свидетель (Disk Witness). Голосования как такового не было, а работоспособность кластера определялась доступностью кворумного диска. При выходе из строя одного из узлов второй захватывал диск и продолжал работу.

модель кворума в Windows NT

Такая модель кворума сохранилась и до сих пор под названием Disk Only. При использовании этой модели кластер может пережить потерю всех узлов кластера кроме одного, который владеет кворумным диском. Как вы понимаете, здесь диск является единой точкой отказа и при его отказе весь кластер становится неработоспособным.

В Windows Server 2003 появились две новые модели кворума, основанные на голосовании:

Node Majority (большинство узлов) — каждому узлу кластера назначается голос, диск-свидетель голоса не имеет.
Node and Disk Majority (большинство узлов и диск) — каждый узел кластера и диск-свидетель имеет голос и участвует в голосовании.

Выбор модели напрямую зависел от количества узлов в кластере, так Node Majority удобнее использовать при нечетном количестве узлов, а Node and Disk Majority при четном. В любом случае для продолжения работы кластера необходимо набрать большинство голосов (>50%).

Для примера возьмем 5-ти узловой кластер с кворумной моделью Node Majority. У каждого узла 1 голос, соответственно все 5 голосов составляют 100%. Для того, чтобы набрать кворум, необходимо более 50% голосов, что в данном случае составляет 3 голоса из 5. Путем несложных подсчетов 🙂 получаем, что данный кластер может перенести выход из строя не более 2 узлов. При выходе из строя третьего узла оставшиеся узлы не смогут собрать большинство и кластер будет остановлен.

кворум в Windows Server 2003

Node Weight

В Windows Server 2003 R2 появилась еще одна модель кворума под названием Node and File Share Majority (большинство узлов и файловая шара) и стало возможным использовать в качестве свидетеля вместо диска файловую шару (Share Witness).

Затем все затихло, и следующие изменения появились только в Windows Server 2008 R2 SP1. Там после установки обновления KB 2494036 появилось понятие веса кластерного узла (Node Weight) и стало возможным его изменение.

Смысл изменения веса заключался в том, в том, чтобы исключить один или несколько узлов из процесса голосования, чтобы их падение не приводило к остановке кластера. При этом узел продолжает участвовать в работе кластера и обрабатывать клиентские подключения, но не участвует в голосовании. Исключение из голосования достигалось путем установки значения параметра NodeWeight равным 0. Изменение веса узла производилось вручную, с помощью PowerShell или через правку реестра.

Для примера возьмем мультисайтовый кластер, состоящий из 5 узлов и использующий кворумную модель с файловой шарой (Node and File Share Majority). Три узла кластера находятся в основном сайте, два в резервном, и где-то в третьем размещена файловая шара-свидетель. При обычном подходе выход трех узлов в основном сайте из строя (напр. отключение электричества) приведет к падению всего кластера, так как оставшиеся в резервном сайте 2 узла + файловая шара не наберут больше половины голосов (3 голоса из 6).

А вот если отобрать у одного из узлов в основном сайте голос, то мы получим 2 голоса в основном сайте и 2 в резервном. Соответственно при падении основного сайта оставшиеся узлы в резервном с помощью шары смогут набрать большинство (3 из 5) и стартовать кластер.

кворум в Windows Server 2008 R2

Dynamic Quorum

Все эти изменения потихоньку подвели нас к понятию динамического кворума (Dynamic Quorum), который появился в Windows Server 2012. Суть динамического кворума в том, что при выходе из строя узла служба кластера автоматически исключает этот узел из голосования, устанавливая его вес в 0, и пересчитывает общее количество голосов в кворуме. Проверка и пересчет голосов производится каждые 5 минут, либо при наступлении определенных событий (напр. добавление или удаление узла). Пересчет производится в зависимости от ситуации:

• При выходе из строя узла — узел с наименьшим номером (Node ID) из оставшихся приводит вес узла в 0;
• При штатном выключении узла — узел сам удаляет свой голос в процессе выключения сервера;
• При добавлении узла в кластер — узел добавляет свой голос в процессе добавления.

При использовании динамического кворума каждый узел имеет два параметра — динамический вес (DynamicWeight) и целевой вес (NodeWeight) узла. Динамический кворум работает только с динамическим весом, не изменяя целевой вес. Принцип такой: при отключении узла его динамический вес устанавливается в 0, а когда узел стартовал и работает, то его динамический вес повышается до целевого. Таким образом, динамический кворум позволяет кластеру выжить даже в том случае, если у него остался всего один узел. Единственное ограничение — узлы должны выходить из строя по очереди, чтобы было время на пересчет кворума. При одновременном выходе из строя более 50% узлов динамический кворум не сработает и кластер будет остановлен.

В качестве примера возьмем 5-ти узловой кластер с моделью Node Majority. Как вы помните из предыдущего примера, при использовании стандартной кворумной модели такой кластер переживает потерю максимум двух узлов. Но поскольку динамический кворум автоматически пересчитывает общее количество голосов, то теперь при выходе из строя 3 узлов мы получим не 2 голоса из 5, а 2 голоса из 2, что даст возможность кластеру продолжить работу при последовательной потере более половины узлов (3 из 5).

динамический кворум в Windows Server 2012

Примечание. Если в кластере остаются только 2 узла и нет диска-свидетеля, то возможна ситуация Split-Brain, когда при потере связи между узлами каждый из них посчитает себя самостоятельным. Для избежания этого кластерная служба снижает вес одного из оставшихся узлов до 0. Соответственно при потере связи служба кластера на одном узле будет остановлена, а на втором продолжит работать.

Dynamic Witness

И еще одно нововведение, появившееся в Windows Server 2012 R2 — динамический свидетель (Dynamic Witness). Как вы понимаете, для получения большинства голосов нужно нечетное их количество, именно поэтому при четном числе узлов используется модель с диском-свидетелем (Node and Disk Majority). Однако при использовании динамического кворума такой подход не очень хорошо работает, ведь при пересчете вместо нечетного мы получим четное число.

При использовании динамического свидетеля вес диска является величиной переменной и зависит от количества работающих узлов в кластере. Так например, в 5-ти узловом кластере с моделью Node and Disk Majority диск-свидетель имеет нулевой вес и не участвует в голосовании. При потере одного узла и пересчете кворума количество голосов становится четным, и чтобы этого избежать диск свидетель получает голос. И так вплоть до последнего узла, при нечетном количестве узлов в кластере вес диска равен 0, а при четном 1.

Dynamic Witness в Windows Server 2012 R2

Примечание. При наличии диска-свидетеля служба кластера никогда не понижает количество голосов ниже 2.

LowerQuorumPriorityNodeID

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

Для примера возьмем мультисайтовый 4-х узловой кластер с общим диском (Node and Disk Majority). Кластер разделен ровно пополам, два узла кластера находятся в основном сайте, два в резервном, всего 5 голосов (4 узла + диск). Вроде все красиво, при выходе из строя одного сайта сайта узлы в другом вместе со свидетелем смогут набрать кворум и продолжить работу.

А теперь предположим, что диск-свидетель выходит из строя и становится недоступен. Динамический кворум автоматически поддерживает нечетное количество голосов, поэтому у одного из узлов, выбранного произвольно, динамический вес понижается до 0. В результате мы имеем 3 голоса — 2 в одном сайте и 1 в другом. Если теперь связь между сайтами прервется, то кворум будет собран в том сайте, где осталось 2 голоса, и не факт что это будет основной сайт.

Для того, чтобы избежать подобной ситуации, в Window Server 2012 R2 можно использовать свойство кластера LowerQuorumPriorityNodeID. С помощью этого свойства можно указать номер конкретного узла, динамический вес которого должен быть понижен. И в случае разрыва связи кворум будет собран в основном сайте, как и планировалось.

LowerQuorumPriorityNodeID

Force quorum resiliency

В ситуации, когда кворум невозможно собрать автоматически, есть возможность принудительно запустить службу кластера на оставшихся узлах, использовав форсирование кворума (ForceQuorum). Для этого администратор должен выбрать один из доступных узлов и вручную запустить на нем службу кластера в форсированном режиме. Сделать это можно из командной строки, командой net start clussvc /fq либо с помощью PowerShell, командлетом Start-ClusterNode с ключом ForceQuorum.

После этого на всех остальных узлах служба кластера также должна быть запущена вручную, командой net start clussvc /pq или командлетом Start-ClusterNode с ключом PreventQuorum. Это не даст им собрать свой собственный кластер, а заставит искать существующий и присоединяться к нему.

Подобный подход не всегда возможен. Например возьмем ситуацию, когда у нас имеется мультисайтовый 5-ти узловой кластер, узлы которого разнесены на два сайта (основной и резервный). В основном сайте находятся 3 узла, в резервном соответствено 2. Связь с основным сайтом теряется, что означает одновременную потерю более 50% узлов. В этой ситуации динамический кворум не поможет, и для возобновления работы кластера в резервном сайте администратор должен будет вручную запустить службу кластера с ключом ForceQuorum.

А теперь предположим, что имели место проблемы с сетью, и в самом ЦОДе все продолжает работать. Соответственно, имея большинство, узлы в основном сайте соберут кворум и будут продолжать работу. А как только подключение будет восстановлено, мы получим Split-Brain, т.к. узлы кластера в основном и резервном сайтах, потеряв связь друг с другом, будут считать себя себя самостоятельным кластером.

Так было раньше, а в Windows Server 2012 R2 ситуация изменилась. Ключ PreventQuorum более не нужен, поскольку узлы кластера, запущенные с ключом ForceQuorum, считаются приоритетными. При восстановлении работы кластера остальные узлы проверяют состояние кластера, и если видят, что он был запущен с ключом ForceQuorum, то рестартуют службу кластера и присоединяются к нему.

А теперь для наглядности давайте рассмотрим несколько живых примеров.

Пример1. Настройка веса узла

Для примера возьмем 4-х узловой кластер с ″оригинальным″ именем Cluster1. Откроем оснастку Failover Cluster Manager, зайдем в раздел «Nodes» и посмотрим список его узлов. Здесь нас интересуют две колонки:
• Assigned Vote — голос, который назначен узлу в общем случае. Определяется целевым весом узла (NodeWeight);
• Current Vote — голос, который имеет узел в данный момент. Зависит от текущего значения динамического веса узла (DynamicWeight).

По умолчанию для работающих узлов эти параметры идентичны и ровны 1.

динамический кворум, все узлы имеют право голоса

 

Как вы помните, целевой вес узла может быть изменен вручную. Для этого кликаем правой клавишей на имени кластера и в контекстном меню переходим в раздел More Actions -> Configure Cluster Quorum Settings.

переход к настройкам кворума

 

И перейдя в расширенные настройки кворума (Advanced quorum configuration) выбираем те узлы кластера, которые будут иметь право голоса.

Примечание. Выбрав пункт No Nodes мы получим кворумную модель Disk Only, в которой право голоса есть только у кворумного ресурса.

выбор узлов кластера для голосования

 

Также понизить целевой вес выбранных узлов можно с помощью PowerShell, вот такой командой:

(Get-ClusterNode -Name SRV5).NodeWeight = 0
(Get-ClusterNode -Name SRV6).NodeWeight = 0

В результате узлы лишаются голоса и не участвуют в голосовании, хотя и продолжают работать в кластере. Обратите внимание, что теперь для выбранных узлов оба параметра имеют нулевое значение. Это связано с тем, динамический вес узла никогда не устанавливается в 1 при целевом весе равном 0.

динамический кворум, узлы без права голоса

Пример 2. Dynamic Quorum

В отличие от ручного понижения веса, динамический кворум не трогает целевой вес узла, а работает только с динамическим весом. Для наглядности остановим 2 узла кластера и посмотрим, что стало с их весами. Поскольку после остановки динамический вес их  стал равен о, то они больше не имеют голоса. Однако их целевой вес остался прежним, и как только узлы будут включены, механизм динамического кворума тут же повысит их динамический вес до целевого, они получат обратно свои голоса и смогут участвовать в голосовании.

динамический кворум, недоступные узлы лишены голоса

 

Примечание. Динамический кворум включен по умолчанию, но при желании его можно отключить, установив значение DynamicQuorum равным 0. В Windows Server 2012 R2 сделать это возможно только с помощью PowerShell, командой:

(Get-Cluster -Name Cluster1).DynamicQuorum = 0

Пример 3. Dynamic Witness

Перейдем к демонстрации работы динамического свидетеля. В качестве подопытного используем все тот же 4-х узловой кластер с диском-свидетелем. Откроем консоль PowerShell и проверим состояние и веса кластерных узлов командой:

Get-ClusterNode -Cluster Cluster1 | ft -a Name, State, NodeWeight, DynamicWeight

А для вывода веса диска-свидетеля выполним команду:

Get-Cluster -Name Cluster1 | fl WitnessDynamicWeight

Как видите, поскольку у нас четное число узлов (4 узла ), свидетель имеет вес равный 1.

динамический свидетель с правом голоса

 

Остановим один из узлов и еще раз проверим их состояние. Поскольку теперь количество активных узлов нечетное (3 узла), то вес свидетеля становится лишним и его значение автоматически устанавливается равным 0.

динамический свидетель без права голоса

 

Таким образом Dynamic Quorum и Dynamic Witness позволяют не заморачиваться количеством узлов в кластере и выбором кворумной модели. По сути в Windows Server 2012 R2 остается всего одна основная модель Node and Disk Majority. Эта модель рекомендуется к использованию в большинстве случаев и выбирается по умолчанию при создании кластера.

Пример 4. LowerQuorumPriorityNodeID

Берем 4-х узловой кластер и диск-свидетель. Проверяем его параметры — тип кворума Node and Disk Majority, веса всех узлов и диска ровны 1, всего в наличии 5 голосов.

исходное состояние кластера

 

Отключаем диск-свидетель, делая его вес равным 0. Еще раз проверяем параметры узлов, и видим, что динамический кворум пересчитал голоса и для сохранения нечетного их количества понизил динамический вес первого узла.

без использование LowerQuorumNodeID

 

Предположим нас не устраивает такое положение вещей, и мы хотим, чтобы в подобной ситуации всегда понижался вес четвертого узла. Для этого установим значение LowerQuorumPriorityNodeID равным 4, выполнив команду:

(Get-Cluster -Name Cluster1).LowerQuorumPriorityNodeID = 4

Примечание. Значение LowerQuorumPriorityNodeID это номер узла (ID), которому надо понизить вес. Одновременно можно указать только один узел.

Еще раз смоделируем ситуацию с отключением диска и посмотрим параметры узлов. Как видите, теперь вес понижен у узла с ID=4, который указан в свойстве LowerQuorumPriorityNodeID.

с использованием LowerQuorumNodeID

 

Таким образом, с помощью LowerQuorumPriorityNodeID мы можем более гибко управлять кластером и выбирать, какая из его частей в случае разрыва связи продолжит работу, а какая будет остановлена.

 
 
Комментарии

Спасибо за подробное разъяснение, очень всё лаконично. Единственное, чуть по больше и по подробнее примеров бы в статью добавить.

спасибо за статью, прочел с удовольствием

Супер! Спасибо за хорошее объяснение!

Спасибо!

Спасибо!

Благодарю за подробное объяснение.
У меня возник вопрос — если я презентую LUN от ISCSI-target для кластера Hyper-V как ClusterStorage.. Как лучше для отказоустойчивости создавать witness-disk : как отдельный LUN, как маленький раздел на том же LUN, который презентован для хранения вирт.машин кластера или вообще сделать просто общую папку SMB-Share на том же сервере, который назначен ISCSI-target ?

В качестве свидетеля вполне хватит обычной шары, желательно на отдельном сервере, не входящем в кластер.

Ответить