Изменения в работе с кворумом в Windows 2012 R2

В кластере под управлением Windows 2012 R2 появились новые возможности управления кворумным ресурсом, о которых и пойдет речь ниже.

Динамическое управление весом дискового кворумного ресурса (Dynamic Witness).

Кластер под управлением Windows 2012 R2 использует динамический дисковый кворумный ресурс (Система управления весом дискового кворума).

Суть динамического дискового кворумного ресурса состоит в том, что система автоматически активирует/деактивирует этот ресурс в зависимости от количества узлов к кластере. Таким образом вы можете всегда создавать такой ресурс не задумываясь о количестве узлов кластера. Такой подход улучшает управляемость кластера и устраняет возможность ошибок конфигурирования кластера.

Ниже приведен кластер состоящий из двух узлов и дискового кворумного ресурса.

Обратите внимание, что "вес" дискового кворума равен "1", поскольку в кластере два узла.

Как только мы добавляем в кластер еще один узел, .

Обратите внимание, что при этом "веса" узлов не изменились. И все узлы участвуют в голосовании.

Аварийное отключение одного из узлов привело к тому, что "вес" дискового кворума снова становиться равным "1" и он принимает участия в голосовании, при этом динамический "вес" этого узла стал равен "0".

 При нормальном выключении узла происходит тоже самое, что и при аварийном завершении.

Улучшение отображения кворумных свойств.

 Добавлено отображение "веса голоса" в консоль управления, что улучшило управляемость и мониторинг.

 Гибкое форсирование кворума

В новой версии кластера отпала необходимость использования ключа /PQ (Prevent Quorum) (https://technet.microsoft.com/en-us/library/jj612870.aspx). Суть этого ключа состоит в том, что при разделении кластера (особенно это характерная проблема для многосайтовых кластеров при потере коммуникации между сайтами) на две части (эффект "split brain"), этот ключ позволяет "сказать" узлам, что они присоединяются к существующему кластеру, clusvc сервис, которого стартован с ключом /FQ (Force Quorum).

Приведем пример.

• Кластер под управлением Windows Server 2012. Кластер состоит из 4 узлов, размещенных по два в разных сайтах и файлового кворума размещенного на SMB сервере.
• Происходит сбой в результате которого становиться недоступен кворум и рвется связь между сайтами.
• Количество голосов в каждом сайте становиться по 2, что не достаточно для формирования кворума.
• Службы CLUSSVC останавливаются на всех узлах кластера.
• Администратор стартует на одном из узлов с ключом /FQ, а на остальных стартует их CLUSSVC с ключом /PQ. заставляя их искать существующий кластер, к которому они были присоединены, а не пытаться формировать новый.

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

Автоматическое разрешение проблемы разделения кластера на две равные части.

Эта проблема наиболее остро может проявиться при развертывании геораспределенного кластера с четным количеством узлов на каждом сайте. Суть проблемы состоит в том, что при отключении кворума на обоих сайтах остается четное количество узлов и в случае разрыва межсайтовых связей каждая часть может воспринять себя как самостоятельная (Split Brain).

В кластере по управлением Windows 2012 (Windows 2008 со специальным hotfix) можно было изменить вес узла при его участии в голосовании, установив его в "0" и тем самым устранив узел из голосования. Проблема, однако заключалась в том, что данный подход был не достаточно гибким.

Обратите внимание, что общее количество голосов 5 (4 узла и кворумный ресурс).

Допустим, мы внезапно потерял и кворумный ресурс (в данном случае я его отсоединил на iSCSI Targeter).

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

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

Это связано с тем, что выбор узла, динамический "вес" которого будет установлен в "0" происходит произвольно.

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

В данном случае мы установили это свойство для четвертого узла.

Выключим еще раз кворумный диск и посмотрим как отработает система.

Как видно из рисунка ниже, динамический вес теперь понижен для узла номер 4.

 Как видно, из описанных выше примеров, все эти нововведения улучшают управляемость кластеров.

Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)