Новое в кластеризации серверов: ассиметричные хранилища и не голосующие узлы

Я верю, что всем кто интересуется виртуализацией Hyper-V, интересна тема кластеризации для повышения доступности сервисов и виртуальных машин в частности. В то же время я часто вижу заказчиков, которые имеют какой-то подсознательный страх перед службой кластеризации, - наверное, после сложностей с кластерами на базе Windows 2000 Server или Windows Server 2003. К выходу Windows Server 2008 сама кластеризация стала существенно проще и стабильнее. Были сняты искусственные ограничения поддержки конфигураций, теперь достаточно лишь пройти мастер валидации на вашем сервере. С появлением Windows Server 2008 R2 публика воодушевлённо приняла технологию Cluster Shared Volumes, делающую возможным использование единого тома для хранения виртуальных машин, доступного одновременно на чтение и запись со всех узлов кластера.

Технология не стоит на месте. Первый пакет обновления принёс поддержку ассиметричных хранилищ, а обновление KB2494036 возможность выбора, какие узлы кластера являются голосующими, а какие нет. Рассмотрим это немного подробнее?

Windows Server 2008 R2 Service Pack 1: Asymmetrical Storage

С выходом первого пакета обновления для Windows Server 2008 R2 и Hyper-V Server 2008 R2 у вас появилась возможность использовать общие дисковые массивы, которые доступны лишь некоторым узлам кластера. Ранее для того чтобы вы смогли добавить диск в кластер, он должен был быть доступен на чтение и запись на всех узлах кластера. Это вполне нормальное требование, если рассматривать кластер, узлы которого расположены на одной площадке. Что же делать в случае построения территориально распределённого кластера (термин «геокластер», часто используемый для этого понятия принадлежит некой компании, которая возражает против использования её трейдмарка в обозначении общей технологии)? Если я хочу помимо реплицируемого (дорогого) хранилища, доступного всем узлам, использовать в каждом сайте своё локальное хранилище для ресурсов, кластеризуемых исключительно в этом сайте? С выходом Service Pack 1 вы можете добавить в кластер общий диск, если он доступен хотя бы двум узлам кластера. Очевидно, что возможными владельцами этого диска, а также всех ресурсов, зависящих от этого диска, должны являться лишь узлы, имеющие прямой доступ к диску. Так что не удивляйтесь, если у вас, вдруг, получится добавить в кластер LUN, презентованный лишь некоторым узлам. Технологически ничего нового в этом нет. Просто для будущей версии SQL Server такая возможность кластера понадобилась, вот её и разрешили в консоли.

KB2494036: Возможность выбора, голосует ли узел за формирование большинства или нет

В кластерах Windows Server 2008 и Windows Server 2008 R2 важно понятие «большинства». «Большинство» формируется при наличии более половины узлов, которые могут общаться друг с другом. Ровно половина большинства не формирует. При чётном количестве узлов используется дополнительный голос – диск или сетевой ресурс. Рассмотрим сценарий территориально распределённого кластера: несколько узлов в основном датацентре, несколько в резервном. Очевидно, что если количество узлов не равное, то при проблемах с связью между двумя площадками, все узлы того ЦОД, где узлом меньше половины исключат себя из кластера, так как не будут иметь большинства голосов. Если количество узлов равное… то мы имеем по сути ту же ситуацию, - ни один из ЦОД не имеет большинства, при проблемах с сетью между площадками все узлы кластера остановят себя. Для такого сценария сейчас мы, как правило, используем некий сетевой ресурс, как дополнительный голос. В терминологии кластеризации этот голос называется witness. Disk witness или file share witness. В сценарии территориально распределённого кластера дисковый ресурс требует синхронной репликации, что, как правило, не осуществимо, а сетевой ресурс должен располагаться на некой третьей площадке. Большую гибкость, как раз, и даёт обновление 2494036. Что же оно приносит?

Параметр NodeWeight

После установки обновления 2494036 на сервер с Windows Server 2008 R2 Service Pack 1 или Windows Server 2008 Service Pack 2 в свойствах узлах кластера появляется новый параметр NodeWeight. Этот параметр может принимать значения 1 или 0. Значение 1 задаётся по умолчанию, и все узлы без этого обновления ведут себя, как будто, имеют NodeWeight = 1. Вы можете вручную для некого узла задать значение NodeWeight = 0 командой Cluster.exe . node <NodeName> /prop NodeWeight=0 или командой PowerShell: (Get-ClusterNode "NodeName").NodeWeight = 0

Посмотреть состояние NodeWeight для данного узла кластера можно командой PowerShell: Get-ClusterNode "NodeName" | fl *

Значение NodeWeight можно задавать и через WMI класс MSCluster_Node.

Ключ PreventQuorum (PQ)

В дополнение к самому параметру веса узла появляется возможность запуска службы кластера с ключом PreventQuorum, чтобы служба при старте не пробовала сформировать кворум для захвата роли кластера.

Сценарии

Рассмотрим сценарий, когда это нововведение может быть полезным. Продолжим развивать идею нашего кластера на две площадки. Пусть мы имеем пять узлов в основном ЦОД и пять в резервном. Для традиционного кластера мне необходимо иметь сетевой ресурс на некой третьей площадке, который будет судить, какой из площадок иметь большинство, в случае проблемы со связью между ними. Допустим, один из ЦОД имеет доступ к этому сетевому ресурсу, он сформирует большинство, набрав 6 голосов из 11. Что произойдёт в случае перезагрузки любого из узлов в ЦОД? Верно! Останется лишь 5 узлов из 11, это не большинство, кластер остановит себя.

Очевидно, что я бы не хотел создавать резервный ЦОД, проблемы в котором могут уменьшить уровень доступности серверов в основном ЦОД. Теперь у нас есть вариант другого сценария. Вы можете для всех узлов резервного ЦОД указать параметр NodeWeight равным 0. При этом теперь вам не нужен сетевой ресурс на третьей площадке. Если резервный ЦОД будет недоступен, то это не повлияет на работу сервисов в основном ЦОД. Даже если один или два сервера в основном ЦОД будут недоступны при недоступности всего резервного ЦОД, кластер продолжит работы: ведь три узла из голосующих пяти формируют большинство!

Что делать, если основной ЦОД стал недоступен, например, в виду проблем с электропитанием? В резервном ЦОД у нас есть пять узлов, которые при недоступности основного ЦОД остановят себя. Один из узлов нужно запустить с ключом ForceQuorum. Этот ключ изначально есть в Windows Server 2008 R2, и появляется в Windows Server 2008 SP2 после установки обновления 2494036. Узел, запущенный с ForceQuorum сформирует большинство, остальные узлы присоединятся к нему, несмотря на то, что они на самом деле не имеют большинства голосов в кластере. Как теперь убедиться в стабильной работе кластера, и не бояться потери данных после нормализации работы основного ЦОД?

Если узлы основного ЦОД будут включаться, когда кластер в резервном ЦОД уже сформирован и доступен, они присоединятся к нему без проблем. Что делать, если электричество восстановлено, но пока нет связи, - в основном ЦОД мы имеем пять узлов, которые могут сформировать большинство пока кластер у нас работает в резервном ЦОД? Как предотвратить потерю данных? Узлы в основном ЦОД следует запустить с ключом PreventQuorum. Служба кластера на них стартует, но они не будут пробовать сформировать большинства, будут лишь готовы соединиться с рабочим кластером. В нашем случае, когда восстановится канал связи между площадками, они присоединятся к кластеру, образованному нами вручную в резервном ЦОД, и реплицируют на себя все изменения.

Обновление уже можно загрузить с сайта поддержки.

Надеюсь, я достаточно подробно описал два нововведения, и это добавит вам уверенности в работе с службой кластеризации в Windows Server 2008 R2 Service Pack 1.