.

Общие файлы. vhdx

Большой интерес специалистов вызвала возможность использования общих файлов VHD (.vhdx) для кластеров Hyper V на базе гостевых систем, что означает устранение необходимости в присоединении фактического хранилища к гостевым виртуальным машинам. Общие файлы. vhdx должны находиться на локальных общих томах кластера (CSV) или на удаленном масштабируемом файловом сервере.

Создаваемый файл. vhdx для виртуальной машины теперь можно маркировать как общий. Для этого в диспетчере Hyper-V поставьте флажок Enable virtual hard disk sharing в разделе установки дополнительных функций (Advanced Features) окна настройки параметров виртуальной машины (см. экран 1).

 

Включение общего доступа к файлу .vhdx в?диспетчере Hyper-V
Экран 1. Включение общего доступа к файлу .vhdx в?диспетчере Hyper-V

Если используется диспетчер виртуальных машин VMM Microsoft System Center, то на странице настройки оборудования установите параметр Share the disk across the service tie (см. экран 2). Затем этот же файл.vhdx добавьте к каждой виртуальной машине и установите тот же флажок. Общие VHD, прикрепляемые к гостевым виртуальным машинам, выглядят как диски Serial Attached SCSI (SAS).

 

Включение общего доступа к файлу .vhdx в?диспетчере виртуальных машин
Экран 2. Включение общего доступа к файлу .vhdx в?диспетчере виртуальных машин

При необходимости для выполнения настройки файлов. vhdx можно воспользоваться средствами Windows PowerShell. В качестве примера предположим, что нам требуется создать файл. vhdx размером 30 Гбайт и назначить его общим VHD для двух виртуальных машин. Сначала создадим файл. vhdx с помощью следующей команды:

New-VHD -Path C:ClusterStorageVolume1Shared.VHDX `
-Fixed -SizeBytes 30GB

Затем назначим его общим файлом. vhdx для каждой из двух виртуальных машин:

Add-VMHardDiskDrive -VMName Node1 `
-Path C:ClusterStorageVolume1Shared.VHDX `
-ShareVirtualDisk
Add-VMHardDiskDrive -VMName Node2 `
-Path C:ClusterStorageVolume1Shared.VHDX `
-ShareVirtualDisk

Применение общих файлов. vhdx оптимально для:

  • файловых служб, работающих внутри виртуальных машин;
  • баз данных SQL Server;
  • файлов других баз данных, находящихся в кластерах из гостевых систем.

Более подробную информацию о настройках общих файлов. vhdx можно найти на веб-странице Virtual Hard Disk Sharing Overview (http://technet.microsoft.com/en-us/library/dn281956.aspx).

Новый процесс выключения узла

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

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

В Server 2012 R2 процесс выключения узла дополнен новой функцией: очисткой при выключении и размещением на наиболее доступном узле.

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

Переносимые виртуальные машины размещаются на «наиболее доступном узле». Это означает, что, прежде чем приступить к миграции виртуальных машин, кластер проверяет объем свободного пространства хранилища на остальных узлах. На основании полученной информации, виртуальные машины размещаются на оптимальном с точки зрения свободных ресурсов узле, как показано на рисунке. Это гарантирует бесперебойность процесса переноса, поскольку предотвращает размещение высокоприоритетных виртуальных машин на узле, не располагающем достаточным объемом свободного пространства.

 

Перенос виртуальных машин на наиболее доступный узел
Рисунок. Перенос виртуальных машин на наиболее доступный узел

Новый процесс включен по умолчанию. При необходимости администратор может его включать и выключать вручную с помощью общего свойства кластера DrainOnShutdown. Для включения введите следующую команду PowerShell:

(Get-Cluster).DrainOnShutdown = 1

Для выключения:

(Get-Cluster).DrainOnShutdown = 0

Определение состояния работоспособности для сетей виртуальных машин

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

Эта функция включена по умолчанию для всех сетей, доступных для виртуальных машин. При необходимости ее можно выключить для некоторых сетей с помощью диспетчера Hyper-V. Для этого достаточно снять флажок Protected network в разделе установки дополнительных функций Advanced Features окна настройки параметров виртуальных машин (см. экран 3).

 

Выключение функции определения работоспособного состояния сети
Экран 3. Выключение функции определения работоспособного состояния сети

Новая панель мониторинга кластеров

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

 

Панель мониторинга кластеров
Экран 4. Панель мониторинга кластеров

Новая панель облегчает управление средами с большим количеством кластеров, позволяя быстро проверять состояние ролей и узлов (включен, выключен, вышел из строя) и отслеживать события, требующие анализа. Все отображаемые элементы представляют собой гиперссылки, позволяющие щелчком открывать нужную информацию. Например, щелчком на Critical: 3, Error: 1, Warning: 2 (см. экран 4) открывается список отфильтрованных событий, которые можно проанализировать для выявления проблемы.

Усовершенствования для CSV

В Server 2012 R2 реализован ряд усовершенствований для общих томов кластера cluster shared volume (CSV), которые включают оптимизацию политики размещения CSV и добавление проверки зависимостей.

Политика размещения CSV теперь предусматривает равномерное распределение принадлежности дисков CSV между узлами. Для примера предположим, что в системе функционируют три узла и четыре диска CSV, каждый из которых используется пятью виртуальными машинами. Когда все узлы функционируют, два из них имеют один диск CSV и пять виртуальных машин. На третьем узле располагаются два диска CSV, каждый из которых используется пятью виртуальными машинами. В случае добавления четвертого узла кластер сразу же автоматически передает ему один из дисков CSV. При этом все виртуальные машины, использующие этот диск CSV, переносятся на новый узел в режиме динамической миграции. Таким образом, кластер реализует более равномерное распределение нагрузки между узлами.

Еще одним новшеством является добавление проверки зависимостей. Узел, не являющийся владельцем (или координатором) диска CSV, должен подключаться к координатору по протоколу Server Message Block (SMB) для пересылки обновлений метаданных, необходимых для данного диска. Для этой цели узел-координатор имеет внутренний общий ресурс, к которому подключаются другие узлы. Однако для работы такой модели нужно, чтобы функционировала служба сервера. Если служба по какой-либо причине не работает, узлы не могут устанавливать SMB-соединение с узлом-координатором. При этом все обновления метаданных кэшируются, но не отсылаются из-за отсутствия способа их передачи. Чтобы разрешить эту ситуацию, приходится вручную передавать владение диском CSV другому узлу.

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

Усовершенствование тестов для проверки сетевых настроек

В кластеризации с обходом отказа для всех видов информационного обмена (проверка работоспособности, передача данных о состоянии и т.д.) между узлами всегда использовался порт 3343. Однако проверка функционирования этого порта не проводилась никогда. Тесты для проверки работоспособности сети предусматривали только контроль функционирования основных сетевых соединений между узлами. Поскольку в рамках этих тестов проверка возможности установления связи через порт 3343 не проводилась, нельзя было узнать, выключен ли порт 3343 в соответствии с настройкой правила для брандмауэра Windows, или же он не был открыт по причине, связанной с использованием стороннего брандмауэра.

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

Усовершенствование динамического кворума

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

При включенной функции динамического свидетеля кластер динамически изменяет голос ресурса-свидетеля (диска или файлового ресурса общего доступа). При наличии большинства (то есть нечетного числа) узлов ресурс-свидетель лишается голоса. При отсутствии большинства (то есть в случае четного числа узлов) ресурс-свидетель динамически вновь обретает свой голос.

С появлением динамического свидетеля изменены рекомендации, касающиеся ресурса-свидетеля. Ранее эти рекомендации основывались на числе узлов. При наличии четного числа узлов рекомендовалось добавление ресурса-свидетеля для получения нечетного числа. Если число узлов было нечетным, то рекомендовалось не добавлять ресурс-свидетель.

В Server 2012 R2 добавление ресурса-свидетеля предпочтительно в любом случае. Благодаря новой функции динамического свидетеля кластер дает ресурсу-свидетелю голос или лишает его голоса в зависимости от конкретной ситуации.

Кластер также по мере необходимости динамически изменяет веса узлов при выходе их из строя или при добавлении в кластер. Диспетчер отказоустойчивого кластера позволяет сразу видеть эти изменения без необходимости выполнять специальные запросы к узлам. Чтобы увидеть веса, в диспетчере отказоустойчивости кластеров выберите элемент Nodes, как показано на экране 5. Заметим, что в настройках кворума по-прежнему существует возможность при желании лишить узел голоса.

 

Контроль весов кластерных узлов
Экран 5. Контроль весов кластерных узлов

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

В Server 2012 R2 введено общее свойство кластера, позволяющее определить, какой из сайтов продолжит работу. С помощью свойства LowerQuorumPriorityNodeID можно указать узел, который утратит голос в случае раскладки «50 на 50».

Для примера рассмотрим систему, в которой есть три узла на главном сайте и еще три узла во внешнем расположении. На внешних узлах можно выполнить установку свойства LowerQuorumPriorityNodeID, согласно которой в ситуации «50 на 50» они остановят свою службу кластеров до восстановления сетевого соединения. Однако для этого необходимо узнать ID внешних узлов. Это можно сделать с помощью приведенного ниже запроса PowerShell, вводимого для каждого внешнего узла:

(Get-ClusterNode –Name «Имя узла»).Id

Предположим, что в результате выполнения этих запросов выяснилось, что внешние узлы имеют идентификаторы 4, 5 и 6. Чтобы вывести эти узлы из работы при раскладе «50 на 50», введем следующие команды:

(Get-Cluster).LowerQuorumPriorityNodeID = 4
(Get-Cluster).LowerQuorumPriorityNodeID = 5
(Get-Cluster).LowerQuorumPriorityNodeID = 6

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

Другие изменения

Кластеризация с обходом отказа в Server 2012 R2 пополнилась многими полезными новшествами. В этой статье мы рассказали лишь о некоторых из них. Чтобы узнать больше, посетите веб-страницу What's New in Failover Clustering in Windows Server 2012 R2 (http://technet.microsoft.com/en-us/library/dn265972.aspx).