Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.

Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.

Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.

К сожалению, все это работает только на хранилищах Fibre Channel.

Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":

Далее нужно понимать следующие условия и ограничения:

• Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
• LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
• LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
• VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
• Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
• Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
• Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.

Максимумы конфигураций для таких кластеров WSFC следующие:

Надо помнить еще о следующих ограничениях (более подробно тут):

• Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
• Горячее расширение VMDK кластерной ВМ не поддерживается.
• Не поддерживается Storage vMotion и снапшоты.
• VMFS 5 и более ранние версии не поддерживаются.

Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.

Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:

Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).

Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:

PS> Get-VM MSCS-Node-1 | Get-HardDisk -DiskType RawPhysical | select scsicanonicalname
ScsiCanonicalName

  —————–

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbc

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbb

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacba

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbd

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb9

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb8

Далее для нужного id-устройства устанавливается статус Perennially reserved через esxcli:

esxcli storage core device setconfig -d naa.id –perennially-reserved=true

Но удобнее это же сделать и через PowerCLI (ищем диски у машин по шаблону MSCS-Node-*):

PS> Set-PerenniallyReserved -PerenniallyReserved $True -VMHost (Get-VMHost) -HardDisk (Get-VM MSCS-Node-* | Get-HardDisk -DiskType RawPhysical)

Ну а для тех, кто хочет использовать vSphere Client, недавно появилась опция "Mark as Perennially Reserved" в разделе Storage Devices клиента:

Главное - не ошибитесь в выборе LUN, если вы отметите не то - это может привести к весьма печальным последствиям.

Источник.

Коллеги рассказали про интересный случай: создали RDM-диск для двух виртуальных машин MSCS-кластера "across boxes", подцепили его к виртуальным машинам на двух хостах ESXi, а производительность на нем упала до 10 МБ/сек, хотя этот диск находится на быстром FC-хранилище EMC VNX и скорость должна измеряться сотнями МБ/сек. При этом в качестве хост-платформы используется VMware vSphere 5.1.

Ответ оказался простым - для хранилищ EMC VNX хост ESXi выставляет политику путей по умолчанию Round Robin (балансировка по двум путям). При использовании кластера MSCS на кворумном диске вызываются SCSI-3 резервации. SCSI-3 резервация (registration) посланная по одному пути позволяет производить дальнейшие резервации или SCSI-команды только по этому пути.

А при использовании политики Round Robin, когда плагин PSP_RR переключает на другой путь, кластер MSCS получает ошибку и пробует сделать SCSI-3 резервацию повторно или выполнить другие команды.

Поэтому вместо политики Round Robin для конкретного хранилища и для данного RDM-диска надо использовать следующие политики путей (плагины PSP_MRU или PSP_FIXED), в зависимости от типа хранища. Они приведены в KB 1010041 и в таблице ниже:

Для того, чтобы выставить политику путей, нужно в разеле Storage в vSphere Client выбрать нужный HBA-адаптер и устройство, для которого создан RDM-диск, и из его контекстного меню выбрать пункт Manage Paths (это также можно сделать в свойствах виртуальной машины для диска):

После выставления корректной политики путей скорость для кворумного диска MSCS вырастет в разы. Кстати, если вы используете VMware vSphere 5.5 и выше, то такого поведения там уже нет, и все работает корректно.

О новых возможностях VMware vSphere 5.5 по поддержке кластеров MSCS мы уже писали вот тут.

При каждом релизе платформы виртуализации VMware vSphere неизменно возникают вопросы о том, что же изменилось в плане поддержки гипервизором ESXi кластеров Microsoft Clustering Services (MSCS). Напомним, что базовая информация об этом находится здесь.

Вот какие варианты развертывания кластеров MSCS для различных приложений поддерживает VMware vSphere 5.5 (напомним, что о кластерах MSCS мы писали тут, тут и тут):

А вот какие версии и конфигурации кластеров Microsoft поддерживаются для различных верси гостевых ОС Windows Server и VMware vSphere:

А теперь перейдем к нововведениям, касающимся поддержки MSCS в VMware vSphere 5.5:

1. Во-первых, к общему хранилищу узлов кластера MSCS может быть организован доступ по нескольким путям посредством политики Round Robin (модуль PSP_RR). Ранее это сделать было нельзя ввиду проблем со SCSI reservations. Теперь эта проблема решена.

Однако тут есть ограничения:

• Поддерживается только для гостевых ОС Windows 2008 и Windows 2012.
• Поддерживаются только конфигурации Cluster Across Boxes (CAB) и N+1. Системы "Cluster in a box" (CIB) используют Virtual Reservations.
• Общий диск (Quorum или Data) должен быть развернут в режиме pass-through RDM.

2. Во-вторых, появилась поддержка протоколов FCoE & iSCSI. Ранее полноценно в качестве общего хранилища для кластеров MSCS поддерживались только  хранилища Fibre Channel, с оговорками iSCSI и как-то частично FCoE. Теперь же полноценно можно использовать iSCSI и FCoE хранилища.

А именно:

• Все конфигурации кластеров: CAB, CIB и N+1 поддерживаются iSCSI.
• Поддержка адаптеров iSCSI:
  
  • Software iSCSI;
  • Аппаратные адаптеры QLogic, Emulex и Broadcom.
• Поддержка режима Mixed mode для iSCSI-инициатора.
• До 5 узлов в кластере поддерживается для Windows 2008 SP2 и более поздних версий.

3. В-третьих, появилась поддержка кластеризации гостевых ОС Windows 2012 MSCS.

Если все это обобщить, то получится картинка, взятая отсюда:

Больше подробностей о поддержке MSCS в VMware vSphere 5.5 можно узнать из KB 2052238.

Многие из вас, кто использует кластеризацию MSCS в виртуальных машинах на платформе VMware vSphere, возможно, замечали, что когда используется кластер Across Boxes (т.е. между ВМ на разных хостах), то перезагрузка хоста VMware ESXi занимает весьма продолжительное время (иногда - до получаса).

При этом на экране консоли написано:

Loading module multiextent.

В логе VMkernel можно увидеть следующее:

Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.828 cpu0:4096)WARNING: ScsiCore: 1353:Power-on Reset occurred on naa.6006016045502500176a24d34fbbdf11
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.830 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:3:0 (naa.6006016045502500166a24d34fbbdf11)
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:02:37.842 cpu3:4099)ScsiDeviceIO: 1672:Command 0x1a to device "naa.6006016045502500176a24d34fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0

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

Избежать этого очень просто. Для этого:

• В ESX / ESXi 4.0 нужно выставить минимальное значение на число повторов операций при обнаружении конфликтов SCSI-резерваций (в Advanced Settings хостов):

Scsi.UWConflictRetries = 80

• Для ESXi 4.1 появилась дополнительная опция, которая уменьшает таймаут при загрузке в случае обнаружения конфликта. Это значение необходимо выставить в:

Scsi.CRTimeoutDuringBoot = 1

• Начиная с ESXi 5.0, опция Scsi.CRTimeoutDuringBoot больше не действует. Теперь нужно использовать команды множества esxcli storage. Для этого:

Сначала надо найти NAA-идентификатор устройства (физического LUN, на котором используется RDM). Для этого нужно зайти в управление путями до устройства (Manage Paths) и посмотреть на строчку, начинающуюся с naa...... - это и есть naa id.

Далее в консоли сервера ESXi нужно выполнить следующую команду (она пометит LUN как изначально зарезервированный):

esxcli storage core device setconfig -d naa.id --perennially-reserved=true

После этого хост ESXi, где были проведены данные манипуляции, будет загружаться быстро.

Более подробно о данной проблеме рассказано в KB 1016106.

На блоге для партнеров компании VMware появилось приглашение на вебинар, посвященный продукту VMware vCenter Server Heartbeat...
Таги: VMware, vCenter, Heartbeat, VirtualCenter, HA, MSCS

Использование MSCS для кластеризации VirtualCenter и виртуальных машин на VMware ESX. Часть 2 – Cluster in a box.

Первая часть статьи: Использование MSCS для кластеризации VirtualCenter и виртуальных машин на VMware ESX. Часть 1

Прежде чем перейти к пошаговой инструкции по настройке кластера VirtualCenter на основе MSCS по сценарию Cluster in a Box, приведем список основных конфигурационных файлов, VirtualCenter, которые так или иначе будут затронуты в ходе настройки кластера. Несмотря на то, что большая часть информации о состоянии VirtualCenter хранится в базе, часть настроек все же находится на самой машине с установленным VirtualCenter. В таблице 1 указаны конфигурационные файлы и за что они отвечают...

Таги: VMware, ESX, MSCS, vCenter, VirtualCenter

Использование MSCS для кластеризации VirtualCenter и виртуальных машин на VMware ESX. Часть 1 – Общие понятия.

Кластер Майкрософт представляет собой группу независимых серверов работающих совместно, на которых запущена служба Microsoft Cluster Service (MSCS). Тем самым обеспечивается высокая надежность, быстрое восстановление после сбоев и масштабируемость, упрощается управление ресурсами и приложениями. Кластер из нескольких серверов позволяет клиентам получить доступ к ресурсам и при выходе из строя одного из серверов или при необходимости планового выключения, ресурсы и приложения запускаются на другом доступном сервере из кластера, таким образом, достигается почти бесперебойная работа.

В данной статье рассказывается о применении кластеризации MSCS в среде VMware Virtual Infrastructure в виртуальных машинах, работающих под управлением VMware ESX.
Таги: VMware, ESX, MSCS