Просмотрено
Рубрика: Huawei

Microsoft Cluster Services Across Hypervisors (vmware+huawei)

Microsoft Cluster Services Across Hypervisors (vmware+huawei)

В данной статье рассматривается режим работы Microsoft Cluster Services, при котором ВМ работают на гипервизорах разных вендоров.

Администрируя vSphere 5.5 я ни под какими предлогами не допускал в инфраструктуру Microsoft Cluster Services (MSCS). Поскольку развернув кластер MSCS прочувствовал на себе все ограничения данной технологии, после чего отказался от ее использования.
Виртуальные машины кластера MSCS  не мигрировали, висели на хосте, гордо заявляя: «Перезагрузка хоста ESXi только через наш труп!». Что сводило на нет многие плюсы виртуализации.

В vSphere 6 это ограничение было устранено — vMotion и MSCS подружились.
Что несомненно вдохнуло новую жизнь в использование технологии кластеризации Microsoft совместно с кластеризацией VMware.

В статье vMotion support for MSCS приводятся оставшиеся ограничения. Но как по мне — так ограничениями их считать нельзя.

Вообще существуют несколько реализаций кластера, которые описаны как в официальной документации — Setup for Failover Clustering and Microsoft Cluster Service, так и более понятно и компактно в статях, например MICROSOFT CLUSTERING WITH VMWARE VSPHERE DESIGN GUIDE.

В частности:
Cluster In A Box (CIB): виртуальные машины размещены на одном хосте. При сбое одной ВМ кластеризованая служба, например файловый сервер, продолжает функционировать. Однако при сбое хоста мы имеем сбой и кластера MSCS.

Cluster Across Boxes (CAB): ВМ размещены на двух хостах, — соответственно при сбое одного хоста кластерная служба, продолжает функционировать.

Virtual Machine + Physical. Один из сценариев использования — это миграция кластера с физических хостов в виртуальную инфраструктуру.

 

Сравнение различных реализаций приведено в таблице:

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

И тут у меня возник вопрос: а только ли из физической? Ведь в реализациях Cluster Across Boxes (CAB) и Virtual Machine + Physical используется Raw Device Mapping (RDM).

Режим работы виртуальных дисков Raw Device Mapping (RDM) позволяет напрямую использовать блочное устройство хранения без создания на нем файловой системы VMFS.

И этот режим поддерживает не только гипервизор ESXi…

Так что мешает реализовать Cluster Across Hypervisors?


Поискав информацию о данном режиме, я ее …. не нашел.
Поэтому решил проверить на практике, использовав в качестве альтернативного гипервизора платформу Huawei FusionSphere.

Создал на двух гипервизорах две ВМ, презентовал хостам VMware и Huawei два луна — т.е. сам диск свидетель и диск для использования в качестве файловой шары. Прокинул их в ВМ как RDM диски и … кластер заработал.

Т.е. Cluster Across Hypervisors вполне себе имеет право на существование.

И да, миграция кластеризованной ВМ работает, притом в обоих гипервизорах.
Правда в случае с Huawei наличие RDM диска увеличивает время миграции примерно в три раза.

Для VMware наличие RDM диска никак не изменяет время миграции.

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

При этом миграция виртуальных машин является стрессом для кластерной роли.  Поэтому в условиях рабочих нагрузок перед проведением миграции виртуальной машины роль с нее нужно переносить средствами Диспетчера отказоустойчивости кластеров. Либо для восстановления работоспособности роли это необходимо делать уже после миграции
Вариант использования, как я писал выше — это перенос сервиса между гипервизорами разных вендоров без прерывания его работы. Правда работает это только в случае кластеризованного сервиса. И усилий необходимо приложить гораздо больше, чем просто миграция между гипервизорами одного вендора. С другой стороны если вам необходимо протестировать работу боевого кластера SQL на разных платформах, то опять же нет ничего проще. Просто запускаете роль на альтернативном гипервизоре и смотрите как она себя ведет в реальной обстановке. И в случае очень неудовлетворительных результатах просто переносите роль на другой узел отказоустойчивого кластера.

 

Установка драйверов Huawei на хост ESXi

Установка драйверов Huawei на хост ESXi

После установки гипервизора ESXi на сервер Huawei RH2288H V2, описанной в прошлой статье, установим драйвера Huawei.

Открываем FusionServer iDriver-Vmware-Driver-VХХХ.zip (как скачивать описывалось ранее) и находим папку «vmware6.0″.  Драйвера из этой папки нам и нужно установить.
Для чего первым делом необходимо закачать папку на хост. Способов на самом деле много, я использую WinSCP. Для успешного подключения WinSCP к ESXi на последнем необходимо открыть порт SSH. Для чего в консоли сервера на который мы поставили ESXi жмем «Enable SSH» (меню — Troubleshooting Options).




Итак, порт открыли, запускаем WinSCP и подключаемся к ESXi. 

Затем в папку tmp копируем папку vmware6.0.
После чего с помощью например putty подключаемся к хосту и выполняем инструкцию из файла readme, т.е. выполняем команды:

 

 

cd /tmp/vmware6.0/
chmod +x install.sh
./install.sh

После чего жмем «1» для автоматической установки драйверов и перегружаемся.


На этом можно и остановиться, но у меня в сервере еще есть сетевая карта Intel(R) X540-AT2.
Актуальная версия драйвера — 4.5.2



Посмотрим установленную версию драйвера: 

 

 

ethtool -i vmnic0

Версия — 3.21.6.

Обновим.

Скачиваем драйвер с сайта, копируем файл net-ixgbe_4.5.2-1OEM.600.0.0.2494585.vib  на хост, переименовываем его, сокращая длинное имя до net-ixgbe.vib, запускаем установку

 

 

 

esxcli software vib install -v /tmp/net-ixgbe.vib

Установка прошла успешно, драйвер обновился.
Обращаем внимание на надпись: Reboot required: true

Перегружаемся.

 

 

reboot
По аналогии ставим и другие драйвера. Например я установил драйвер SSD карточки, без которого она не была видна ESXi, и обновил Embedded Host Client.



 














Установка ESXi (6.0) на сервер Huawei RH2288H V2

Установка ESXi (6.0) на сервер Huawei RH2288H V2

За время работы как с виртуализацией от компании Huawei, так и с серверами я усвоил главное правило: логика ничто, — инструкция все!!! Поэтому читаем инструкцию. 
Начинаем с Huawei Server Best Practice with VMware ESXi System. 
Прежде всего инструкция предлагает нам проверить совместимость сервера с ESXi на веб-станице по адресу: http://support.huawei.com/onlinetoolsweb/ftca/en 
Открываем, при необходимости заходим в iMana
Жмем Search 
Далее жмем на ссылки (link) и переходим на сайты VMWARE и HUAWEI.
На первом видим, что версия ESXi 6.0 на нашем сервере технологию FT не поддерживает (а 6.5 поддерживает)
На втором  видим список патчей, открываем самый свежий и видим список драйверов.
Скачиваем FusionServer iDriver-Vmware-Driver-VХХХ.zip, он нам пригодится.

Также читаем Note.

Если iMana или BIOS не обновлены, то обновляем их. Эти операции просты — скачиваются драйвера и подсовываются в iMana. Если iMana не обновляется, то перегружаем ее.
Устанавливаем настройки BIOS. Huawei рекомендует использовать дефолтные настройки.
Затем необходимо настроить RAID. И делать это нужно не через BIOS, а с помощью FusionServer Tools ServiceCD. 

Его можно скачать через http://support.huawei.com/enterprise/en/index.html раздел TaiShan — FusionServer Tools, Загрузки.
Имя файла — FusionServer Tools-ServiceCD2.0-VXXX.zip.
Также в будущем может понадобиться FusionServer Tools-Toolkit-VXXX.zip.
Итак скачиваем FusionServer Tools-ServiceCD, загружаемся с него, жмем START, переходим в RAID Config, создаем RAID. При необходимости читаем User Guide.
Перегружаемся, снова заходим в FusionServer Tools ServiceCD. На этот раз выбираем Install OS. И видим предупреждение:
Не игнорируем, обновляем прошивку.

Загружаемся с ранее скачанного FusionServer Tools-Toolkit, заходим в CLI (в главном меню набираем символ «C», логин: root; пароль: Huawei12#S).
Затем набираем: cd /home/Project/tools/upgrade/raid/tool/
И: ./FwUpgrade.py FwUpgrade.xml.

Контроллер обновился.
Снова загружаемся с FusionServer Tools ServiceCD, прошивка новая — 20.100.04.00
Следуем указаниям мастера.
Мастер попросит вставить образ ESXi, начнет загрузку, перезагрузится, после чего установка ESXi пойдет в обычном порядке. 
Если что-то не то с контроллером, например не находится загрузочный диск, то первая причина — это конфигурирование контроллера встроенными средствами (а не FusionServer Tools ServiceCD). Если же все сделано правильно — можно почитать Firmware Upgrade Guide.
В нем более подробно описываются действия с контроллером. В частности можно выбрать SAS Topology, выбрать RAID и проверить что он является загрузочным. При необходимости сделать его таковым (Alt-B)
Установка завершена.
Далее необходимо установить обновления.