Механизм Failover Clustering (кластеризация с обходом отказа) претерпел огромное число изменений в последних версиях системы Windows Server. Система Windows Server 2008 отметилась значительными достижениями в работе по упрощению настройки кластеризации и управлении ею, новым процессом проверки конфигураций, поддержкой географически распределенных кластеров и другими нововведениями. В системе Windows Server 2008 R2 была реализована поддержка общих томов кластера Cluster Shared Volumes (CSV) и другие улучшения. Windows Server 2012 повысила масштабируемость кластеров до 64 узлов, впервые продемонстрировала поддержку масштабируемых файловых серверов, полностью изменила принцип работы кворума с вводом механизма динамического кворума, добавила возможность мониторинга процессов, запущенных на виртуальных машинах, а также другие возможности. .

Улучшения кворума

Мы привыкли к относительной сложности механизма кворума. Архитектор кластера должен решить, нужно ли использовать ресурс-свидетель, и если нужно, то какой ресурс выступит в роли свидетеля: общая файловая папка или диск. Если количество узлов меняется, данное решение должно быть пересмотрено, так как свидетель требуется только кластерам с четным количеством узлов. В системе Server 2012 впервые реализован механизм динамического кворума, который автоматически корректирует голоса, привязанные к узлам, по мере доступности последних. Хотя динамический кворум решил проблему, связанную с тем, что не в меру ретивые администраторы отключают слишком много узлов, что приводит к отключению всего кластера, данный механизм не отменяет необходимость вручную настраивать ресурс-свидетель при изменении количества узлов.

В систему Server 2012 R2 добавлен механизм динамического свидетеля, который динамически присваивает голос ресурсу-свидетелю, в зависимости от количества узлов в кластере. Если количество узлов четное — свидетель требуется, и ему предоставляется голос. Если количество узлов нечетное – свидетель не требуется, и его голос удаляется. Такой подход значительно упрощает процесс настройки кластера и является последним изменением на пути практически полного отказа от принятия решений относительно «режима кворума».

При создании кластера с обходом отказа версии Server 2012 R2 вы всегда настраиваете ресурс-свидетель. Механизм Failover Clustering определяет, когда свидетелю необходимо дать голос. Чтобы проверить, имеет ли свидетель голос в данный момент, можно использовать команду оболочки Windows PowerShell:

(Get-Cluster).WitnessDynamicWeight

Результат «1» означает, что у ресурса-свидетеля есть голос. Значение «0» означает, что голоса нет.

В системе Server 2012 R2 есть и другие улучшения механизма кворума. В версии Server 2012 динамический кворум позволял удалять и добавлять голоса узлов при изменении доступности серверов. Однако оставалась вероятность возникновения ситуации, при которой кластер делился пополам, и каждая половина получала 50% голосов. Это означает, что ни одна из сторон не может собрать кворум. Обычно ресурс-свидетель разрешает подобную ситуацию, делая количество узлов нечетным, тем самым гарантируя, что одна из частей всегда сможет получить более 50% голосов, но существуют сценарии, в которых механизм ресурса-свидетеля не срабатывает и количество узлов остается четным.

В системе Server 2012 R2 в технологию Failover Clustering добавлена новая функция, выступающая в качестве нарушителя равновесия в случае разделения узлов «50 на 50». При возникновении такой ситуации данный механизм, если количество узлов четное, случайным образом выбирает один из узлов кластера и убирает его голос. Таким образом в кластере снова будет нечетное количество голосов, и одна из частей кластера сможет собрать кворум в случае нарушения связи между площадками. Если текущий узел отключается, то узел, потерявший свой голос, должен получить его обратно, чтобы обеспечить нечетное количество голосов в кластере. Данный механизм работает до тех пор, пока в кластере не останется два узла.

Если вам претит мысль о том, что голос теряет случайно выбранный узел, вы можете сделать одну из площадок основной (то есть площадкой, на которой хотите собирать кворум). В дальнейшем вы сможете вручную выбрать узел, который должен потерять голос в сценарии, предусматривающем вмешательство нарушителя равновесия. Например, если вы хотите, чтобы узел на второстепенной площадке потерял голос, используйте команду:

(Get-Cluster).LowerQuorumPriorityNodeId = `
(Get-ClusterNode -Name «»).Id

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

Как показано на экране 1, вы можете проверить наличие голоса у каждого узла в кластере в окне Nodes диспетчера Failover Cluster Manager. Благодаря этому теперь гораздо проще узнать статус голоса внутри кластера, что очень полезно, учитывая все возможности динамического кворума.

 

Просмотр статуса голоса каждого узла
Экран 1. Просмотр  статуса голоса каждого узла

В действительности заставить кластер версии Server 2012 R2 не собирать кворум очень трудно, но могут возникать ситуации, в которых вам придется форсировать создание кворума на кластерном разделе, чтобы перевести его в рабочее состояние. Для этого используйте ключ /fq при запуске службы кластера:

net start clussvc /fq

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

Изменения технологии CSV

Механизм CSV появился в системе Server 2008 R2. Он позволяет всем узлам кластера одновременно использовать тома LUN с файловой системой NTFS, устраняя необходимость в перемещении томов LUN между узлами при миграции виртуальных машин. Механизм CSV позволяет виртуальным машинам работать на различных узлах, хранящихся на одном и том же томе CSV, что демонстрирует возможности технологии CSV в области предоставления одновременного доступа внутри кластера.

В системе Server 2008 R2 механизм CSV работал только с виртуальными машинами Hyper-V. В системе Server 2012 роль была расширена, так как она использовалась механизмом Server Message Block (SMB) для работы масштабируемых файловых служб, которые применяются для решения различных задач, таких как хранение виртуальных машин Hyper-V и баз данных SQL Server. Кроме того, механизм CSV очень хорошо работает с кластеризованными дисковыми пространствами Storage Spaces – еще одним новым механизмом системы Server 2012.

Система Server 2012 R2 улучшает поддержку технологии CSV сразу в нескольких областях:

  • При использовании технологии CSV с кластеризованными дисковыми пространствами владение томом CSV теперь динамически перераспределяется между узлами кластера. Перераспределение владения помогает лучше сбалансировать операции чтения/записи на диске между узлами. Если узел удаляется из кластера или повторно присоединяется к нему, баланс владения томом CSV динамически изменяется таким образом, чтобы обеспечить оптимальное распределение.
  • Отказоустойчивость механизма CSV была повышена, благодаря использованию нескольких экземпляров службы Server для каждого узла. Таким образом, разделяются различные типы трафика и минимизируется масштаб влияния в случае отказа службы.
  • Были усовершенствованы средства диагностики проблем механизма CSV. Теперь для каждого экземпляра CSV диспетчер Failover Cluster Manager показывает, включен ли на данном экземпляре режим ввода-вывода (I/O) и по какой причине, если да.

Технология CSV использует небуферизованный ввод/вывод данных в операциях чтения-записи, а значит кэширование на уровне диска не осуществляется. Однако в системе Server 2012 появилась возможность использовать часть системной памяти в качестве кэша чтения для механизма CSV на уровне операционной системы, благодаря чему повышается производительность операций чтения. В системе Server 2012 максимальное количество памяти, которое вы можете выделить под кэш CSV, равно 20% системной памяти. В системе Server 2012 R2 это количество было увеличено до 80% системной памяти.

Для активации механизма CSV в системе Server 2012 R2 требуется только один шаг. Необходимо просто указать количество памяти, которая может быть использована хост-сервером под кэш CSV. Например, следующая команда устанавливает размер кэша CSV равным 4 Гбайт:

(Get-Cluster).BlockCacheSize = 4096

В системе Server 2012 для активации механизма CSV требуется выполнить два действия. Во-первых, необходимо настроить количество памяти, которое хост-сервер может использовать под кэш CSV, с помощью такой команды, как:

(Get-Cluster).SharedVolumeBlockCacheSizeInMB = 4096

Во-вторых, нужно включить кэш CSV для каждого диска. Чтобы на диске включить кэш CSV, вы можете задействовать команду:

Get-ClusterSharedVolume «Cluster Disk 1» |
Set-ClusterParameter CsvEnableBlockCache 1

В системе Server 2012 R2 нет необходимости выполнять данную команду, поскольку кэш CSV включен по умолчанию. Если необходимо отключить кэш CSV для определенного диска, важно знать, что свойство CsvEnableBlockCache, существовавшее в системе Server 2012, получило имя EnableBlockCache в системе Server 2012 R2.

В Server 2012 R2 механизм CSV поддерживает и другие возможности операционной системы, в том числе:

  • Файловую систему Resilient File System (ReFS) — систему, предназначенную в первую очередь для работы с архивными данными. Не стоит использовать ее для запущенных виртуальных машин.
  • Дисковые пространства Storage Spaces, использующие многоуровневый кэш и кэш обратной записи.
  • Дисковые пространства Storage Spaces, использующие контроль четности (включая двойной контроль четности).
  • Дедупликацию данных.
  • Систему SQL Server 2014, установленную на томе CSV версии Server 2012 R2.

Изменения в виртуализации

В статье «Что нового в Windows Server 2012 R2 Hyper-V», части 1 и 2, я рассматриваю некоторые изменения в виртуализации, вызванные развитием технологии Failover Clustering. Однако я хочу подробно описать их здесь, так как гипервизор Hyper-V является самым главным потребителем возможностей кластеризации Failover Clustering.

Создание гостевых кластеров было возможным в системе Hyper-V на протяжении нескольких лет. Однако если гостевым кластерам требовалось общее хранилище, необходимо было задействовать такие технологии как протокол iSCSI и виртуальные подключения Fibre Channel. Хотя этот подход эффективен, он открывает для виртуальных машин информацию о физических хранилищах, а такое решение не является идеальным для многих окружений.

В системе Server 2012 R2 добавлена поддержка совместного использования виртуальных дисков, позволяющая одновременно подключить файл виртуального жесткого диска (файл VHDX) к нескольким виртуальным машинам через контроллер SCSI. Общий файл VHDX подключается к виртуальной машине как устройство Serial Attached SCSI (SAS) и соответственно может быть использован как общее хранилище кластера. Файл VHDX должен храниться на томе CSV, а, следовательно, хост-серверы Hyper-V могут напрямую обращаться к нему, либо на локальном томе CSV либо на масштабируемом файловом сервере посредством протокола SMB 3.0. Масштабируемые файловые серверы используют тома CSV в качестве серверного хранилища.

Для совместного использования файла VHDX необходимо выбрать параметр Enable virtual hard disk sharing в настройках диска. Данный параметр вы можете найти в окне Advanced Features диспетчера Hyper-V Manager, показанном на экране 2.

 

Включение общего доступа к файлу VHDX
Экран 2. Включение общего доступа к файлу VHDX

Для настройки совместного использования виртуального жесткого диска вы также можете задействовать оболочку PowerShell. Необходимо просто выполнить команду Add-VMHardDiskDrive с параметром –ShareVirtualDisk:

Add-VMHardDiskDrive -VMName savdalfc01 -Path `
C:\ClusterStorage\Volume1\SharedVHDX\Savdalfcshared1.vhdx `
-ShareVirtualDisk

Имейте в виду, что некоторые механизмы не работают с общим файлом VHDX, так как его задействуют несколько операционных систем. К примеру, совместно используемый файл VHDX:

  • не может быть частью реплицируемых данных Hyper-V Replica;
  • не может быть перемещен с помощью механизма динамического хранилища, необходимо отключить виртуальные машины, прежде чем перемещать совместно используемый файл VHDX;
  • не позволяет производить динамическое изменение размера;
  • не может быть частью резервных копий уровня хост-сервера; вы не можете делать резервную копию общего файла VHDX с хост-сервера Hyper-V.

Я надеюсь, что эти ограничения будут устранены в будущих версиях системы Windows Server, но пока о них важно помнить.

Когда в системе Windows Server вы переводите узел в режим обслуживания, рабочие нагрузки завершаются в определенном порядке. Если узел перед выключением переводится в режим обслуживания, то при выполнении динамической миграции виртуальных машин на другой узел в системах версии Server 2012 доступность виртуальной машины остается непрерывной. Если узел не переводится в режим обслуживания, то виртуальная машина будет некоторое время недоступна, так как системе необходимо сохранить состояния виртуальных машин, переместить виртуальные машины и повторно включить их после перемещения.

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

Последнее изменение, связанное с виртуализацией, также направлено на то, чтобы обеспечить максимально длительную доступность виртуальных окружений. Распространенная проблема с логическим механизмом Failover Clustering — обнаружение отказов. Если узел работает, и виртуальная машина тоже, кажется, что с виртуальным окружением все в порядке. Однако сетевой адаптер может быть неисправен или отключен, в результате чего виртуальные машины не смогут устанавливать внешние соединения с хост-сервером, что делает их бесполезными.

В системе Server 2012 R2 появился механизм «защищенная сеть», который позволяет присвоить важнейшим сетевым подключениям виртуальных машин статус требующих защиты. Как показано на экране 3, необходимо выбрать параметр Protected network. Его можно найти в окне Advanced Features диспетчера Hyper-V Manager.

 

Настройка защищенной сети
Экран 3. Настройка защищенной сети

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

Кластер, не присоединенный к каталогу AD

Последний механизм, о котором я хочу рассказать, предназначенный для крайне специфического сценария, — это кластер, не присоединенный к каталогу Active Directory. Услышав название «не присоединенный к каталогу Active Directory», вы можете подумать, что узлы кластера не должны быть присоединены к домену, но это не тот случай. Все узлы кластера должны быть присоединены к одному домену. Чтобы понять новшества, предлагаемые неприсоединенным кластером, потребуется немного дополнительной информации. При создании кластера в системе версии Server 2008 или выше в каталоге AD автоматически создается объект Cluster Name Object. Объект Cluster Name Object в основном используется для целей аутентификации Kerberos, но также может вызывать некоторые проблемы, так как для его применения необходимо создание объектов в каталоге AD.

Механизм не присоединенного к каталогу Active Directory кластера позволяет формировать кластер без создания объекта Cluster Name Object. Значение параметра, отвечающего за использование данного механизма, должно быть задано при создании кластера и не может быть изменено после. Чтобы задать значение, необходимо ввести команду New-Cluster с параметром -AdministrativeAccessPoint DNS. Информацию об использовании команды New-Cluster с данным параметром можно найти на веб-странице New-Cluster (http://technet.microsoft.com/en-us/library/hh847246.aspx) ресурса TechNet.

Единственная реальная рабочая нагрузка, для которой подходит данный механизм, — это кластеры SQL Server, не использующие авторизацию Kerberos. Для других рабочих нагрузок этот механизм по различным причинам подходит меньше:

  • Данный механизм мало подходит для кластеров, использующих аутентификацию Kerberos, так как аутентификация Kerberos необходима для выполнения динамической миграции в кластерах Hyper-V, а кластер Hyper-V, в котором невозможна динамическая миграция, бесполезен.
  • Данный механизм мало подходит для кластеров, состоящих из файловых серверов, так как протокол SMB чаще всего использует аутентификацию Kerberos.
  • Не стоит применять данный механизм, если вы хотите использовать технологию BitLocker для шифрования томов CSV, так как технологии BitLocker требуется объект Cluster Name Object.
  • Данный механизм не подходит, если вы используете службы Microsoft Message Queue Services (MSMQ), так как службы MSMQ выполняют запись в каталог AD.

Этот список действительно убеждает, что кластеры, не присоединенные к каталогу Active-Directory, предназначены исключительно для окружений SQL Server, использующих аутентификацию SQL Server Authentication, и не рекомендуются к применению в других средах. Однако данный механизм исключительно полезен для тех окружений SQL Server, которые используют аутентификацию SQL Server Authentication и не имеют прав на создание объектов в каталоге AD.

Технология Failover Clustering и гипервизор Hyper-V подверглись заметному изменению. Но еще большего внимания заслуживает тот факт, что с каждой новой версией системы Windows Server механизмы Hyper-V и Failover Clustering все теснее переплетаются друг с другом. При совместном использовании они образуют очень мощную платформу виртуализации. Кроме того, механизм Failover Clustering продолжает быть основой, обеспечивающий бесперебойную работу, для многих других служб.