Установка VMware vCenter Server Appliance и создание кластера vSphere

26 min readNov 3, 2016

VMware vCenter Server — это платформа для централизованного управления VMware vSphere, помогающая автоматизировать управление виртуальной инфраструктурой. vCenter Server позволяет объединить хосты ESXi в кластер и получить “высокую доступность” и отказоустойчивость за счет “зеркалирования” и создания правил миграции виртуальных машин в случае отказа серверов.

Помимо установщика для операционных систем Windows существует готовый шаблон для развертывания vCenter Server в виде отдельной виртуальной машины — VMware vCenter Server Appliance (или vCSA), который построен на 64-битном SUSE Linux Enterprise Server.

Установка vCenter Server Appliance.

Установка vCSA будет производиться с ПК, где установлена ОС Windows. Начиная с шестой версии vCSA процесс установки перенесен в браузер. Установка так же возможна из командной строки (актуально для Linux и Mac OS) — подробности в Command-Line Deployment of VMware vCenter Server Appliance 6.0.

Допустим, сетевые настройки хоста ESXi, где будет размещаться vCSA следующие:

hostname: esxi00
domain: vdi.local
DNS: 192.168.3.241
Gateway: 192.168.3.1

vCSA не поддерживает TCP/IP v6 (для этого нужен vCenter Server установленный на ОС Windows), поэтому при конфигурации хостов TCP/IP v6 не использовался. 192.168.3.241 — это адрес виртуальной машины контроллера домена Active Directory, размещенной на данном хосте.

Обратите внимание, что домен vSphere должен быть отличным от домена Active Directory. Ввод vCenter Server Appliance будет введен в домен Active Directory и настройка True SSO будут произведены чуть ниже. Поэтому перед установкой создаем на DNS-сервере A-записи для vCenter Server Appliance и хоста, на котором он будет устанавливаться:

Если в качестве DNS-сервера используется Bind, в текстовый конфиг зоны vdi.local необходимо внести А-записи для esxi00 и VCSA-01:

# cat /var/named/vdi.local; Zone file for vdi.local
; ...esxi00.vdi.local.  IN A 192.168.3.240
VCSA-01.vdi.local. IN A 192.168.3.243

Если компьютер, с которого будет осуществляться установка vSCA настроен на другой DNS-сервер, то добавляем в файл hosts:

C:\Windows\system32\drivers\etc\hosts192.168.3.243          VCSA-01.vdi.local
192.168.3.240          esxi00.vdi.local

Теперь скачиваем ISO-образ vCenter Server Appliance с сайта VMware. На момент написания это файл:

VMware-VCSA-all-6.0.0–3634788.iso

Монтируем этот образ в вашу ОС Windows в виде виртуального CD/DVD-диска, заходим в папку vcsa и устанавливаем плагин:

После чего в корневой папке диска запускаем vcsa-setup.html:

и дальнейшая установка будет продолжена в браузере. Жмем “Запустить приложение” и появившуюся кнопку “Intall”.

Читаем лицензионное соглашение, указываем параметры хоста ESXi, где предполагается развернуть vCSA: IP-адрес, логин и пароль для управления хостом:

Указываем имя виртуальной машины, логин и пароль для доступа к консоли по SSH:

Создаем новый Single Side On домен и задаем пароль администратора домена:

Далее указываем масштаб инфраструктуры, где по мере выбора будут отображены необходимые ресурсы. Обратите внимание, что для управления более 5 хостами и 50 машин вместо встроенной vPostgres рекомендуется использовать внешнюю СУБД Oracle.

Указываем datastore, где будет располагаться виртуальная машина, настраиваем подключение к базе дынных (или используем встроенную) и переходим к сетевым настройкам. Обратите внимание, что во избежание ошибок при установке FQDN для vCSA нужно указывать вместе с SSO-доменом:

VCSA-01.vdi.local

Сверяем настройки и переходим к процессу развертывания:

Если все настройки указаны верно, то через некоторое время процесс развертывания завершится:

Можно переходить к следующему пункту “Создание инфраструктуры vSphere”.

Если в процессе развертывания появилось сообщение об ошибке:

Firstboot script execution Error.
The supplied System Name vCenter_Server_FQDN is not valid.

это означает, что указан неверный FQDN для vCSA. Но если перед установкой вы создали соответствующие A-записи на DNS-сервере (и исправили файл hosts), то проблем возникнуть не должно. В противном случае — для решения проблемы необходимо:

1. Открыть консоль vCenter Server Appliance, нажать CTRL+ALT+F3 и залогиниться под пользователем root.

2. Для того, чтобы сделать доступным shell ввести:

shell.set --enabled true

3. Ввести команду:

shell

4. Отправить ICMP-запрос на DNS-сервер:

ping dns.dns_server.com

5. Используем команду nslookup, чтобы определить “резолвится” ли vCenter Server Appliance по FQDN:

nslookup vCenter_Server_Appliance_FQDN

в нашем случае должно быть:

Command> nslookup VCSA-01.vdi.local
Server:         192.168.3.241
Address:        192.168.3.241#53Name:   VCSA-01.vdi.local
Address: 192.168.3.243

Внимательно ознакомьтесь с требованиями к настройке DNS в официальной инструкции и устраните проблему.

6. Далее повторите установку vSphere Center Appliance.

Обновление vCenter Server Appliance.

Периодически будут выходить патчи и обновления, которые желательно устанавливать. Переходим на страницу поиска обновлений, выбираем “VC” и актуальную в настоящий момент версию “6.0.0”. Собственно, здесь варианта два:

Third Party (TP) — обновление каких-то отдельных компонентов, Full Patch (FP) — обновление всех компонентов vCSA.

Качаем обновление, например:

VMware-vCenter-Server-Appliance-6.0.0.20100–4632154-patch-FP.iso

монтируем его как CD-привод виртуальной машины vCSA через vSphere Clinet, переходим в консоль vCSA (по нажатию Cntrl+Alt+F3) и, если вы желаете установить патчи прямо сейчас, то выполняем команду:

software-packages install --iso --acceptEulas

Как вариант, можно обновить компоненты, но пока не устанавливать (отправить в очередь, или “стэйджинг”):

software-packages stage --iso --acceptEulas

Просмотреть пакеты, отправляемые в “стэйджинг” можно командой:

software-packages list --staged

И, наконец, установить пакеты со “стейджинга” можно:

software-packages install --staged

и далее отправить ВМ в перезагрузку:

shutdown reboot -r "Install Update 2a"

После перезагрузки можно открыть веб-консоль по адресу:

https://<vCSA_FQDN_or_IP>:5480

Например:

https://vcsa-01.vdi.local:5480/
root
<password>

переходим во вкладку “Update”, где в нашем примере видим версию:

6.0.0.20100 Build Number 4632154

Как вариант, можно обновиться по URL прямо из веб-консоли, выбрав опцию “Check URL”.

Более подробную информацию по обновлению vCenter Server Appliance можно получить здесь.

Присоединение vCSA к Active Directory.

Вы можете прикрепить Platform Services Controller appliance, или vCenter Server Appliance к домену Active Directory, чтобы “привязать” пользователей и группы домена Active Directory к домену vCenter Single Sign-On. Обратите внимание, что присоединение к контроллеру домена в режиме “только для чтения” невозможно.

Если вы хотите управлять правами пользователей и групп, для доступа к компонентам vCenter Server вам необходимо присоединить Platform Services Controller к контроллеру домена Active Directory. Например, для того чтобы дать пользователю возможность входа в vCenter Server с использованием аутентификации Windows, необходимо присоединить vCenter Server Appliance к контроллеру домена Active Directory и ассоциативно назначить пользователю права администратора vCenter. Кроме того, развертывание таких платформ, как Horizon View Composer (и его последующее присоединение его к Horizon View Connection Server и vCenter Server) проблематично без присоединения vCenter Server Appliance к контроллеру домена Active Directory.

Прежде, чем присоединить vCSA к контроллеру домена Active Directory убедитесь:

Имя пользователя под которым осуществлен вход в vCenter Server принадлежит к группе группе SystemConfiguration.Administrators в vCenter Single Sign-On (в данном примере — это administrator@vdi.local)
Системное имя vCenter Server Appliance является FQDN. Присоединение к контроллеру домена Active Directory не возможно, если во время разворачивания vCSA вы указали IP-адрес.

За дополнительной информацией можно обратиться по этой ссылке.

Процесс присоединения vCSA к контроллеру домена может завершиться ошибкой — через веб-интерфейс:

Idm client exception: Error trying to join AD, error code [11]

или через консоль:

Error: ERROR_GEN_FAILURE [code 0x0000001f]

Для предотвращения необходимо:

Включить на контроллере домена Active Directory поддержку общего доступа к файлам SMB 1.0/CIFS через мастер “Добавления ролей и компонентов”:

Поменять значение ключа реестра DependOnService:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer

со значения “SamSS Srv” на значение “SamSS Srv2” (без кавычек) и перезагрузить сервер:

Теперь открываем браузер и входим в веб-интерфейс vSphere:

https://vcsa-01.vdi.local/vsphere-client/

или вместо FQDN используем IP-адрес vSCA. Вводим:

administrator@vdi.local
<your_vcenter_admin_password>

переходим:

Administration -> System Configuration -> Nodes -> VCSA-01.vdi.local -> Manage -> Active Directory

и в появившемся окне вводим домен (обратите внимание, что домен Active Directory должен быть отличным от домена vCenter Single Sign-On). Например:

domain.local
domain_admin@domain.local
<password>

Через некоторое время в оснастке “Active Directory — пользователи и компьютеры” появится vCSA:

vCenter Server Appliance можно так же присоединить к домену Active Directory с использованием консоли:

/opt/likewise/bin/domainjoin-cli join domain.com domain_admin password

Для завершения операции присоединения к домену Active Directory требуется перезагрузка. Далее снова логинимся в веб-интерфейс vCenter, открываем:

Home -> Administration -> Single Side-On -> Configuration -> Identity Sources -> Active Directory (Integrated Windows Authentication)

вводим имя домена (domain.local) и жмем “Ok”. Добавился новый “источник идентификации” (Identify Source):

Теперь сопоставим роль администратора vCenter Single Side-On учетной записи domain_admin домена domain.local. Переходим:

Home -> Administration -> Global Permissions -> Manage

и назначаем пользователя:

Теперь добавим пользователя domain_admin из домена domain.local в группу администраторов vdi.local — переходим:

Home -> Administration -> Single Side On -> Users and Groups -> Groups

и добавляем пользователя:

Теперь можно логиниться под пользователем domain_admin с правами администратора vdi.local:

Активация лицензии vCenter Server.

Для каждого vCenter Server (или vCenter Server Appliance) вы можете ассоциировать один из введенных ключей. Для этого в веб-консоли:

vCenrer Inventory List -> vCenter Servers -> vCenter Server -> Manage -> Licensing -> Assign License

Создание инфраструктуры vSphere.

Далее необходимо создать новую инфраструктуру (или в терминологии vSphere — “Datacenter”):

Actions -> New Datacenter

И создаем новый кластер:

В раскрывшемся окне задаем настройки для создаваемого кластера.

vSphere позволяет объединить несколько физических хостов и создать кластер на уровне виртуальных машин. Для организации кластера vSphere требуется, как минимум, два хоста. vSphere позволяет организовать отказоустойчивость за-счет двух типов кластеров: vSphere HA и vSphere DRS.

vSphere HA (High-availability) — технология создания кластера высокой доступности: при выходе хоста из строя виртуальная машина может запускаться на другом хосте. Фактически временем простоя является загрузка операционной системы виртуальной машины на другом хосте. Для того, чтобы избежать простоя во время работы виртуальной машины на одном из хостов на другом активируется её реплицированная копия, изолированная по вводу-выводу от общей инфраструктуры. В случае отказа первого хоста, на котором изначально запущена виртуальная машина происходит переключение ввода-вывода и активируется “призрак”.

Включение “Host monitoring” позволяет vSphere HA реагировать на сбои в работе хостов, или ВМ, а настройки “Admission control” позволяют контролировать обеспечение достаточного количества ресурсов для организации отказоустойчивости. Можно указать, как минимальное количество хостов для обеспечения отказоустойчивости (Host failure cluster tolerates), так и процентное соотношения ресурсов процессора и памяти.

vSphere DRS (Distributed Resource Scheduler) — технология кластеризации, которая применяется для балансировки нагрузки между хостами. Отличается от HA тем, что vCenter сам определяет, на каком хосте хранить виртуальным машины. DRS позволяет vCenter сбалансировать нагрузку гостевых операционных систем между хостами для обеспечения равной загруженности между всеми хостами. Можно настроить правила для распределения физических ресурсов между виртуальными машинами, а так же выбрать режим ручного контроля (Automation Level):

Manual — позволяет выбрать хосты вручную, vMotion не активируется. В этом режиме vCenter лишь подсказывает, какие виртуальные машины нужно переместить, а сам перенос ВМ осуществляется вручную.
Partially automated — DRS выбирает, где включить ВМ, но vMotion не активируется.
Fully automated — DRS выбирает, где включить ВМ, vMotion активируется автоматически и помещает ВМ в кластер vSphere.

Параметр Migration Threshold указывает, насколько принудительно будут мигрировать виртуальные машины в случае отказа хоста, на котором они размещены.

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

Virtual SAN — софтварное общее хранилище корпоративного класса. Фактически, это еще один продукт VMware.

После создания кластера можно приступить к добавлению хостов ESXi:

Lockdown mode — режим, предотвращающий прямое подключение к объединенным в кластер хостам, минуя централизованное управление.

Возможны три режима:

Disabled — хосты будут доступны для одновременного управления, как при прямом подключении, так и через vCenter Server.
Normal — хосты будут доступны, либо через vCenter Server, либо через прямое подключение к хосту.
Strict — хост доступен для управления только через vCenter Server. Сервис Direct Console UI будет отключен.

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

Хост(ы) добавлен(ы). Теперь можно создать шаблоны (templates) различных операционных систем и сконфигурированных виртуальных машин, чтобы по необходимости можно было создать новую, отредактировав её конфигурацию и настройки операционной системы, а так же клонировать виртуальные машины:

Home > Hosts and Clusters > Вкладка VM Templates in Folders

Создание vSphere Distributed Switch.

vSphere Distributed Switch (или vDS), доступный в vSphere редакции Enterprise plus, позволяет объединить хосты ESXi и создать единую управляемую сеть для всего кластера vSphere. VMware vDS дает возможность централизованного управления и мониторинга сети на различных уровнях, а так же резервного копирования и восстановления конфигурации сети в случае сбоев.

Основные преимущества vSphere Distributed Switch:

Возможность использования протокола NetFlow, позволяющий определить, какое устройство обменивается трафиком, а так же какой порт и протокол оно использует.
SPAN и LLDP (Link Layer Discovery Protocol), позволяющие “зеркалировать” порты (port mirroring) и анализировать трафик.
Network I/O control позволяет настроить пропускную способность и назначить приоритеты для каждого типа трафика. Network I/O Control дает возможность организовать отказоустойчивость и разделить трафик на предустановленный пул ресурсов (для iSCSI, vMotion, vSphere Replication (VR), NFS, трафика ВМ и Management Network).
VLAN trunking и Private VLANs, позволяющих обойти ограничения связанные с недостатком сетевых адресов и VLAN ID, а так же изолировать трафик по портам, используя Private VLANs.

Ознакомиться более подробно с возможностями vDS можно здесь:

Overview of vNetwork Distributed Switch concepts (1010555)

Для того, чтобы создать Distributed Switch необходимо в веб-консоли vSphere и переключиться режим обзора “Networking”. Далее открываем контекстное меню:

[Datacenter Name] -> Distributed Switch -> New Distributed Switch

В открывшемся мастере указываем имя свитча (DSswitch), версию, количество uplinks (4), оставляем включенным “Network I/O control” и чек-бокс на пункте “Create default port group”:

Теперь добавим хосты в созданный распределенный комутатор:

[Dswitch Name] -> Add and Manage Hosts...

В раскрывшемся мастере выбираем в качестве задания (Select task) выбираем “Add hosts”, выбираем хосты (Select hosts), которые необходимо объединить, а на вкладке “Select network adapter tasks” выбираем задачи:

Migrate virtual machine networking и vMotion лучше отделить в отдельную группу портов. На вкладке “Manage physical network adapters” назначаем uplinks для сетевых интерфейсов хостов:

и, перейдя на вкладку “Manage VMkerkel network adapters”, назначаем группу портов для сетевых адаптеров VMkernel. Выбранные сетевые адаптеры мигрируют на распределенный коммутатор:

Если все сконфигурировано верно на следующей вкладке будет статусы “No impact”:

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

Создадим новую группу портов:

[Dswitch name] -> Distributed Port Group -> New Distributed Port Group

Указываем настройки группы портов: количество портов — 8, Распределение портов — “Elastic” (в отличии от “Fixed”, позволяет автоматически менять необходимое количество портов), VLAN ID — 35:

По аналогии можно создать группу портов для только что созданной “Custom Network”:

Если в вашей инфраструктуре имеются хосты, использующие группы портов на стандартном коммутаторе (Standart vSwitch) и их необходимо перенести на распределенный коммутатор (Distributed Switch), то переключаемся в режим обзора “Hosts and clusters” и на необходимом хосте открываем:

Manage -> Virtual Switches -> [vSwitch Name] -> Manage Physical Network adapters connected to the selected switch

Выбираем необходимый сетевой адаптер и отключаем необходимый физический адаптер:

Теперь добавляем хост к распределенному коммутатору. Переходим:

Networking -> [Dswitch name] -> Add and manage hosts -> Add hosts

и выбираем хост, который нужно перенести:

Ставим чек-бокс на опции “Migrate virtual machine networking” для того, чтобы изменить конфигурацию и перенести необходимые интерфейсы ВМ на распределенный коммутатор:

Далее, аналогично рассмотренному выше процессу добавления хостов, назначаем физическому адаптеру uplink:

и назначаем интерфейс на группу портов распределенного коммутатора:

В следующей вкладке выбираем интерфейсы виртуальных машин, для которых необходимо осуществить миграцию:

сверяем все настройки на вкладке “Ready to complete” и ждем завершения всех операций, статус которых отображается в окне “Recent Tasks”.

На этом базовые настройки распределенного коммутатора закончены. За дополнительной информацией можно обратиться:

Расширенные настройки кластера vSphere.

Home > Hosts and Clusters > Вкладка Clusters > Settings (по правой кнопке мыши)

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

vSphere HA.

Параметры vSphere HA выглядят следующим образом:

Включение опции Host Monitoring позволяет главному хосту vSphere HA реагировать на сбои в работе хостов, или ВМ, а опция Protect against Storage Connectivity Loss позволяет предотвратить проблемы подключения к накопителям (Permanent Device Loss PDL, или All Paths Down).

Параметр Virtual Machine Monitoring позволяет перезапустить определенные ВМ, если их состояние не будет получено в течение определенного отрезка времени (heartbeat). При выборе “VM and Application Monitoring” потребуется установка VMware Tools. Далее предоставляется настройка отдельных параметров Failure Conditions and VM response:

VM restart priority — приоритет перезапуска, или восстановления виртуальных машин в случае отказа хоста. В случае отказа нескольких хостов служба HA сначала перезапустит виртуальные машины с хостов, отказавших раньше. Параметр приоритета перезапуска ВМ может быть установлен, как для всего кластера, так и для каждой виртуальной машины. Задается как значение из набора: High, Medium, Low, или Disabled.
Response for Host Isolation — параметр, определяющий перезапуск виртуальных машин в случае их изоляции от управляющей консоли vSphere. В случае изоляции служба отказоустойчивости HA расценивает это событие, как отказ и попытается восстановить машины на других хостах. Но при использовании Virtual SAN механизм блокировки VMFS не позволяет получить доступ к файлам этих виртуальных машин так, как они продолжают работать. Фактически, этот параметр определяет ответ на отказ ВМ и то, что нужно сделать перед её перезапуском: Shut down, или Power Off.
Response for Datastore with Permanent Device Loss (PDL) — параметр, определяющий действия в ответ на Permanent Device Loss для datastore, событие, когда хост-серверу ESXi удается выявить, что устройство недоступно по всем имеющимся путям, удалено, или неисправно. Возможны три варианта: отсутствие реакции (Disabled), журналирование события (Issue Event), или выключение и перезапуск ВМ (Power off and restart VM).
Response for Datastore with All Paths Down (APD) — параметр, определяющий действия в ответ на All Paths Down для datastore, событие, когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. Возможны четыре варианта: действие может быть отключено (Disabled), журналирование события (Issue Event), или выключение и перезапуск ВМ (Power off and restart VMs conservative, или Power off and restart VMs agressive). При включении консервативного режиме перезапуска (Power off and restart VMs conservative) служба vSphere HA не будет пытаться перезапустить ВМ до тех пор, пока есть другой хост, который может запустить ВМ. Подробней ознакомиться можно здесь.
Delay for VM failover for APD — пауза, определяющая промежуток времени после обнаружения All Paths Down (APD) (в течение APD Timeout, равного по умолчанию 140 секундам) до момента, когда начинается выполнение действия Response for a Datastore with All Paths Down (APD), а само хранилище помечается как утраченное (NO_Connect). По умолчанию значение Delay for VM Failover равно 3 минутам. Другими словами, VM Component Protection (VMCP) будет ждать 5 минут 40 секунд, прежде, чем будет применено действие Response for APD recovery after APD timeout (см. следующий пункт). Сумма APD Timeout и Delay for VM Failover называется VMCP Timeout, а сам процесс восстановления изображен ввиде VMCP Recovery Workflow на отрезке времени, называемом VMCP Recovery Timeline:

Response for APD recovery after APD timeout — параметр, определяющий действие при достижении APD timeout: отключено (Disabled), осуществить “жесткий сброс” (Hard reset) виртуальных машин (Reset VMs).
VM monitoring sensitivity — параметр, определяющий, насколько часто будет производиться опрос состояния ВМ.

Admission Control — политика управления, используемая vSphere HA, используемая для контроля достаточных количества ресурсов (Failover capacity) в кластере при обеспечении отказоустойчивости. При этом ресурсы исчисляются в виде “слотов”, а его размер задается в Slot size policy. Возможны четыре варианта Admission Control:

Define failover capacity by static number of hosts — задание фиксированного количества хостов для обеспечения отказоустойчивости. В качестве Slot size policy по умолчанию выбран вариант “Cover all powered-on machines”, при котором размер слота подсчитывается исходя из максимума потребляемых мощностей всеми виртуальными машинами. В качестве альтернативы можно задать фиксированный слот (Fixed slot size) и задать количество ресурсов вручную.
Define failover capacity by reserving a persantage of the cluster resources — задание ресурсов в процентном соотношении от ресурсов кластера.
Use dedicated failover hosts — назначить выделенные хосты для обеспечения отказоустойчивости.
Do not reserve failover capacity — вариант, при котором ресурсы резервироваться не будут. Можно запускать виртуальные машины, для которых не соблюдены требования по обеспечению доступности.

Datastore and heartbeating — раздел настроек, с помощью которых задаются резвервные datastore. vSphere HA может выявлять сбойные хосты и виртуальные машины, расположенные не сетевых носителях. Если такой носитель оказывается недоступным по причине сбоя сети, или в случае выхода из строя будет назначен резервный. Возможен, как автоматический выбор (Automatically acess datastores acessible from the host), так и задание списка (Use datastores only from the specified list), а так же — выбор по их необходимости (Use datastores from the specified list and complement automatically if needed). Дополнительную информацию можно получить здесь.

Advanced options задают дополнительные настройки HA:

das.isolationaddress[0…10] — задает адреса, которые пингуются для определения хостом его изоляции от сети сервисной консоли. Если ни один адрес не задан, то используется шлюз по умолчанию, используемый сетью сервисной консоли. По умолчанию не задан. Можно задать до десяти адресов для одного кластера (das.isolationaddressX, где X — от 0 до 10).
das.usedefaultisolationaddress — определяет использовать, или не использовать default gateway для console network при определении изоляции (true|false).
das.isolationshutdowntimeout — период времени, который будет ожидать хост при завершении работы ВМ (Shut down), прежде, чем она будет принудительно выключена (Power off). Значение по умолчанию — 300 секунд.
das.slotmeminmb — задает максимальное ограничение объема памяти для слота в мегабайтах. При выборе размера слота это значение сравнивается с наибольшим значением reservation + overhead между всеми включенными ВМ в данном кластере. Меньшее из двух этих значений и будет принято за размер слота. По лимит не задан.
das.slotcpuinmhz — задает максимальное ограничение ресурсов процессора для слота в мегагерцах. Выбор параметров аналогичен das.slotmeminmb.
das.vmmemoryminmb — значение в мегабайтах, используемое при определении размера слота под виртуальные машины. При увеличении значения механизм Admission Control резервирует больше памяти на хостах ESXi в случае сбоя. Если значение не указано, то дефолтное равно 0.
das.vmcpuminmhz — значение в мегагерцах, используемое при определении размера слота под виртуальные машины. При увеличении значения механизм Admission Control резервирует больше ресурсов процессора на хостах ESXi в случае сбоя. Если значение не указано, то дефолтное равно 32МГц.
das.iostatsinterval — интервал допустимой изоляции ВМ в секундах: если не получено heartbeat’ов от ВМ в течение этого промежутка времени, то выполняется политика рестарта ВМ, или приложения. По умолчанию значение равно 120 секундам. Обратите внимание, что установка значения ниже 50 секунд не рекомендуется: vSphere HA может неожиданно начать сбрасывать виртуальные машины.
das.ignoreinsufficienthbdatastore — значение для устранения при конфигурации HA ввиде сообщения: “HA Error: The number of heartbeat datastores for host is 1, which is less than required: 2”. Данное значение определяет, будет ли игнорировано сообщение о количестве имеющихся Heartbeat-хранилищ, которое меньше сконфигурированного в das.heartbeatdsperhost. Дефолтное значение: false.
das.heartbeatdsperhost — определяет количество требуемых hartbeat хранилищ (datastore). Допустимые значения: 2–5. По умолчанию равно 2.
das.config. fdm.isolationpolicydelaysec — количество секунд, которые выждет система прежде, чем применит политику Isolation Response в случае изоляции хоста. Дефолтное и одновременно минимальное значение — 30 секунд (если выставить меньше, то все равно будет 30 секунд).
das.respectvmvmantiaffinityrules — указывает, необходимо ли соблюдать заданные правила существования машин на хостах на уровне ВМ-ВМ (anti-affinity rules) при перезагрузке виртуальных машин (true). Значение по умолчанию выставляется в “false”, в результате чего правила не выполняются. Если будет выставлено в “true”, то правила будут соблюдаться (до тех пор, пока не включен vSphere DRS). В этом случае vSphere HA не переключится на виртуальную машину в случае отказа, если это нарушает правило, но зажурналирует событие (issue event) о том, что нет достаточных ресурсов, чтобы выполнить переход.
das.maxresets — количество попыток сброса ВМ, которые повторит VMPC в случае All Path Down.
das.maxterminates — количество попыток, которые произведет VMPC для презапуска (Power off and restart VMs) сбойной виртуальной машины.
das.terminateretryintervalsec — интервал времени в секундах, который VMCP выждет, прежде, чем повторит попытку перезапуска (Power off and restart VMs) сбойной ВМ.
das.config.fdm.reportfailoverfailevent — задает, создавать ли детализированное событие на каждую ВМ, если попытка vSphere HA перезапустить сбойную ВМ была безуспешной. Значение по умолчанию — 0. В более ранних, чем vSphere 6.0 версиях, событие создавалось по умолчанию.

Обратите внимание, что изменение параметров das.isolationaddress[…], das.usedefaultisolationaddress и das.isolationshutdowntimeout требуют выключение и повторное включение vSphere HA для того, чтобы внесенные изменения были применены. Более подробную информацию по дополнительным параметрам vSphere HA можно получить:

vSphere DRS.

Расширенные настройки vSphere DRS выглядят следующим образом:

Automation Level — режим автоматизации DRS, задающий распределение нагрузки: Manual (vCenter не перемещает ВМ, но подсказывает), Partially automated (vCenter будет подсказывать, а так же появится возможность выбрать, где включить ВМ) и Fully automated (vCenter будет автоматически перемещать ВМ для более эффективного распределения нагрузки).

Migration Threshold — коэффициент (от 1 до 5), указывающий насколько агрессивно будет осуществляться миграция ВМ:

Migration Threshold 1: Порог равный единице нужен только тогда, когда кластер не нуждается в балансировке нагрузки. Наглядным примером использования Migration Threshold=1 является ситуация, когда требуется техническое обслуживание какого-то хоста (host maintance), но при этом требуется соблюдение правил DRS. Например, необходимо установить на отдельный хост обновление ESXi, перед установкой которых все ВМ с обновляемого хоста мигрируют на другие. DRS оценивает производительность и выдает рекомендации по переносу ВМ. После того, как хост переведен в “Maintance mode” и установлены все обновления, необходимо вывести хост из “Maintance mode” и поменять Migration Threshold, для того, чтобы выровнять нагрузку на хосты и задействовать обновленный хост.

Migration Threshold 2–5: Чем выше порог, тем более принудительна миграция ВМ в случае отказа одного из хостов и более агрессивно распределение ВМ. С другой стороны, чем выше порог, тем больше перемещений ВМ и тем более сбалансирован кластер по нагрузке, даже если это не приносит никакой пользы по производительности. Таким образом, значение по умолчанию 3 — является наиболее подходящим для большинства случаев.

Virtual Machine Automation. Чек-бокс разрешает использовать разный Automation Level для отдельной ВМ (вкладка “VM Overrides”), а так же ряд индивидуальных настроек при включенном vSphere HA.

Power Management позволяет vSphere использовать Distributed Power Management (DPM) — расширения DRS, появившегося впервые в ESX 3.5. Суть DPM заключается в том, чтобы управлять питанием хостов с целью экономии электроэнергии. Например, можно отключать хосты на ночь, когда нагрузка небольшая, тогда как DRS переместит ВМ на другие хосты. DPM использует для включения Wake-on-LAN, IPMI, или iLO. При использовании IPMI, или iLO необходимо настроить управление питания для каждого из хостов (см. ниже — описание параметров вкладки Host Options).

По аналогии с Migration Threshold, для DPM так же можно выбрать порог — DPM Threshold: чем больше его значение, тем более агрессивно DPM будет выдавать рекомендации по управлению питанием и утилизации неиспользуемых ресурсов. При выборе режима “Manual” DPM будет отображать рекомендации в веб-консоли vSphere, а при выборе “Automatic” рекомендации применяются автоматически. В автоматическом режиме уровни DRS так же соблюдаются и ВМ мигрируют в соответствии с выбранными правилами, поскольку уровни Distributed Power Management не соответствуют и приравниваются к уровням DRS. Уровни DPM приравниваются ко всем узлам кластера, но так же могут быть выставлены отдельно для каждого хоста индивидуальными настройками.

Advanced Options. В дополнение к порогу миграции (Migration Threshold) предлагается задать дополнительные параметры для тюнинга алгоритма vSphere DRS. Рекомендуется не изменять эти значения, если нет веской на то причины: например, кластер с “тяжелой” формой конфликта ресурсов на некоторых хостах и простой (idle) на других. Вот некоторые из параметров, документированные для vSphere 5.1 и более поздних версий:

CostBenefit. Данная настройка позволяет включить и отключить использование метрики Сost Benefit, параметр определяющий затраты на перемещение ВМ при балансировке. vMotion считает сколько ресурсов потребуется для перемещения ВМ и как её перенос повлияет на загрузку на хосте. Очевидно, что ВМ, которая постоянно изменяет память, потребует больше сетевых ресурсов, чем та, которая простаивает. Если дословно, то Cost Benefit — стоимость (Cost) выгоды (Benefit), то есть Cost — это Migration Cost (количество ресурсов процессора для vMotion, количество памяти для переноса и тд.), а Benefit — максимальное количество освобожденных при переносе ресурсов (Higher Resource Availability). Кандидат, который не проходит необходимые критерии, фильтруется vMotion. Значение по умолчанию — 1, а наиболее агрессивное значение — 0 (не учитывать ConstBenefit).
MinGoodness. Минимальное требуемое улучшение для рекомендации по перемещению. Для определения, на какой хост перемещать ресурсы DRS использует нормализованное состояние хоста, как ключевой параметр и будет рассматривать хосты с меньшим нормализованным состоянием, чем у хоста-источника. Значение по умолчанию — адаптируемое, наиболее агрессивное — 0 (не учитывать MinGoodness, таким образом, все перемещения будут считаться “улучшающими”).

Кратковременная установка CostBenefit и MinGoodness в 0 могут внести некоторый результат, потому как vMotion смотрит на кластер как не сбалансированный, абсолютно не учитывая расходы на перемещение ВМ. Правда, такой операции в любом случае необходим достаточный запас ресурсов. Но постоянное использование нулевых значений может привести к циклическому перемещению ресурсов по хостам в ущерб производительности.

MinImbalance. Минимальное значение разбалансировки кластера, требуемое для рекомендации по перемещению. Дефолтное значение — 50, наиболее агрессивное значение — 0.
UseDownTime. Определяет, учитывать ли downtime при переносе для подсчета метрики CostBenefit. Значение по умолчанию — 1, наиболее агрессивное — 0 (не учитывать downtime при переносе).
IgnoreDownTimeLessThan. Пороговое значение в секундах для указания временных интервалов, которые следует игнорировать при подсчете UseDownTime. Значение по умолчанию —1, или большее значение — в качестве более агрессивного.
MaxMovesPerHost (для более поздних версий — IoLoadBalancingMaxMovesPerHost). Максимальное число переносов с(на) datastore за одну перебалансировку. Значение по умолчанию — адаптируемое, наиболее агрессивное — 0 (без ограничений).
DumpSpace. Изменяет максимальный объем логов для DRS-кластера. Лог-файлы расположены в %TMP%\vpx\drmdump\cluster#. Значение по умолчанию — 20 (Мб).

Это основные Advanced Options для тюнинга DRS-кластеров, доступные начиная с версии vSphere 5.1, которые применяются для “ослабления” правил в случае разбалансировки кластера.

Частоту, с которой алгоритм DRS вызывается для балансировки можно задать с помощью конфигурационного файла vpxd.cfg со следующей опцией:

<config>
 <drm>
 <pollPeriodSec>
 300
 </pollPeriodSec>
 </drm>
</config>

По умолчанию частота составляет 300 секунд, но интервал может быть произвольным от 60 до 3600 секунд. Рекомендуется оставлять значание по умолчанию за исключением случаев, когда требуется вызывать алгоритм реже и, тем самым уменьшить потери от работы DRS. Кроме того, существует набор скриптов, с помощью которых можно сделать балансировку кластера более активной, доступных на “Scripts for Proactive DRS” (VMware community page).

VM/Host Group и VM/Host Rules.

Во вкладке VM/Host Group для ВМ или хоста можно создать группу, которой, во вкладке VM/Host Rule, можно сопоставить правило. Например:

Keep virtual machines together — размещать выбранные ВМ вместе,
Separate virtual machines — размещать выбранные ВМ раздельно,

Virtual Machines to hosts — размещать заданную группу ВМ на группе хостов.

При выборе Virtual Machines to hosts допускается выбрать четыре режима:

Must run on host group (Mandatory),
Should run on host group (Preferential),
Must not run on host group,
Should not run on host group.

Принципиальная разница между “Must” и “Should” заключается в том, что принудительные правила (Mandatory), в отличие от предпочтительных (Preferential), “жестко” привязывают ВМ к определенной группе хостов. Если эти хосты выключены, то ВМ не могут быть запущены на другом хосте: в этом случае vSphere HA+vSphere DRS не перенесет их ни при vMotion, ни при Maintance Mode. При этом расположение ВМ будет сохраняться даже при отключении vSphere DRS.

И напротив, при задании предпочтительного правила vSphere HA в случае отказа запустит эти ВМ на других хостах и правило будет перекрыто алгоритмом Hight Availability ради того, чтобы эти ВМ оставались доступными.

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

VM Overrides.

VM Overrides дает позволяет задать индивидуальные параметры vSphere HA/DRS для определенных ВМ, минуя общие для всего кластера. Например, когда необходимо определить ответные действия на события All Path Down (APD), Permanent Device Loss (PDL), или требуется выставить различный приоритет для перезапуска ВМ (VM restart priority). Обратите внимание, что операции “shut down” и “restart” возможны только после установки VMware Tools.

Host Options.

Во вкладке Host Options задаются настройки для управления электропитанием хоста для Distributed Power Management (DPM). DPM — это функция vSphere DRS, задача которой снизить энергопотребление на основе анализа потребляемых ресурсов. DPM мониторит потребляемое количество ресурсов процессора и памяти, сравнивая с общим количеством ресурсов в кластере. Если будут найдено достаточно ресурсов для перемещения ВМ, то они будут перенесены, а хост переводится в режим ожидания. И наоборот, как только в кластере становится недостаточно ресурсов, хост выводится из режима ожидания.

DPM использует для управления три протокола: Intelligent Platform Management Interface (IPMI), Hewlett-Packard Integrated Lights-Out (iLO), или Wake-On-LAN (WOL). Если хост не поддерживает ни один из этих протоколов, то он не может быть переведен с помощью DPM, а если хост поддерживает несколько протоколов — они используются в следующем порядке: IPMI, ILO, WOL.

IPMI является аппаратной спецификацией, а iLO — встроенной технологией по управлению сервером. Обе технологии обеспечивают интерфейс для удаленного мониторинга и управления компьютером. IPMI и iLO требуют наличия Baseboard Management Controller (BMC), который обеспечивает шлюз для доступа к аппаратному управлению, позволяя управлять питанием удаленно через LAN-порт.

Если вы планируете использовать iLO, или IPMI для управления питанием хоста, вам необходимо настроить BMC. Шаги по настройке iLO различны в зависимости от выбранной модели, тогда как IMPI требует дополнительных настроек в BIOS (убедитесь, что BMC LAN включен, сконфигурирован и доступен для управления). VMware DPM поддерживает только IMPI c MD5- и plaintext-based аутентификацией. vCenter Server использует MD5, если BMC дает ответ, что MD5 поддерживается и доступна для роли оператора (Operator role). В противном случае, используется plaintext-based аутентификация, если, опять же, включена и доступна. Если MD5 и plaintext-based аутентификации отключены, то IPMI не может использоваться и vCenter Server попытается использовать Wake-on-LAN.

Для работы Wake-On-Lan необходимо выделить vMotion в отдельную IP-сеть и использовать гипервизоры ESX(i) 3.5, или выше. Каждый интерфейс сети vMotion должен поддерживать Wake-On-Lan. Проверить, поддерживают ли сетевые интерфейсы хоста Wake-on-LAN можно перейдя в vSphere Client к настройкам хоста:

Configuration -> Network Adapters

Порт коммутатора (switch) должен быть выставлен в автоматическое согласование скорости (Auto Negatiate), а не принудительное (например, 1Гб/с):

Некоторые сетевые интерфейсы поддерживают Wake-On-Lan только, если они могут переключаться на 100Мб/с (или менее), когда хост выключен.

Теперь для того, чтобы настроить BMC для каждого из хостов открываем в веб-клиенте vSphere:

Hosts and Clusters -> {Host} -> Manage -> Power Management

Вводим настройки BMC. Оставляем дефолтную схему менеджмента питания, или выбираем для подключаемого хоста один из трех вариантов: Disabled, Manual, или Automatic. Вводим логин и пароль для роли оператора BMC (Operator role), IP- и MAC-адрес интерфейса.

Теперь можно протестировать управление питанием хоста. В веб-клиенте vSphere, или vSphere Client открываем контекстное меню для выбранного хоста и переходим:

Power -> Enter Standby Mode

По окончании миграции ВМ хост будет выключен (точней, перейдет в “режим ожидания”, но при этом будет доступен для BMC). Аналогично можно проверить его включение, раскрыв контекстное меню хоста:

Power -> Power On

Питанием хостов можно так же управлять с помощью VMware vSphere PowerCLI. Для перевода в Standby Mode:

Get-VMHost -Name &lt;Hostname&gt; | Suspend-VMHost -Confirm:$false

Для Power On:

Get-VMHost -Name &lt;Hostname&gt; | Start-VMHost -Confirm:$false

После того, как BMC/WOL протестированы, можно приступить к настройке DPM для vSphere DRS (см. выше описание параметров vSphere DRS). Как только DPM будет активирован, вы можете просмотреть статус для каждого хоста в поле “Last Time Exited Standby”:

Это поле отображает время, когда vCenter Server пытался перевести хосты в режим “ожидания”, а так же статус успешного выполнения — Succeeded, Failed, или Never, если не было ни одной попытки.