Продолжение цикла статей о дизайне VDI. Предыдущие части доступны по ссылкам:
Часть 1. ВведениеЧасть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
5.1 Общие сведения
Подсистема виртуализации является основой инфраструктуры VDI. Требования к доступности, производительности, восстанавливаемости в первую очередь реализуются за счет технологических решений, применяемых на данном уровне. В общем случае к подсистеме виртуализации можно отнести:- Серверы виртуализации – физические серверы с установленным ПО гипервизора (VMware ESXi), которые обеспечивают запуск и работу виртуальных машин, и предоставляют им необходимые вычислительные ресурсы.
- Сервер(ы) управления (vCenter Server), который позволяет централизованно управлять группой серверов виртуализации.
- Виртуальные машины (служебные или клиентские ВМ), в которых установлены гостевые ОС и набор служебного и прикладного ПО, необходимого для функционирования VDI инфраструктуры.
5.2 Сервер управления vCenter Server
Сервер vCenter Server предназначен для централизованного управления серверами виртуализации, виртуальными машинами, образами ВМ, виртуальными сетями, хранилищами ВМ. Многие функции подсистемы виртуализации, такие как выполнение живой миграции vMotion, настройка High Availability, работа механизма балансирования DRS, возможны только при наличии сервера vCenter Server. Кроме этого, vCenter Server служит в качестве точки подключения, через которую настраивается интеграция подсистемы виртуализации со смежными системами (Horizon, СРК, системой мониторинга и т.д.).
vCenter Server состоит из двух компонентов – Platform Services Controller (PSC) и, собственно, служб vCenter.
PSC отвечает за аутентификацию и авторизацию пользователей, выдачу сертификатов для серверов виртуализации и служб vCenter, а также за выдачу лицензий для vSphere и сторонних продуктов, интегрирующихся с vSphere (vSAN, NSX, SRM и другие).
vCenter, в свою очередь, отвечает за работу основных служб, обеспечивающих управление виртуальной инфраструктурой (VirtualCenter, Inventory Service), предоставляет интерфейс для централизованного управления (vSphere Web Client, vSphere Client), а также обеспечивает работу вспомогательных служб: Syslog Collector, Dump Collector, Auto Deploy (а в vCenter 5.x и более ранних версиях и службы оркестрации vCenter Orchestrator). В небольших инсталляциях на сервере vCenter также могут быть установлены дополнительные компоненты – сервер обновления vSphere Update Manager, сервер, управляющий созданием и обслуживающим linked-clone десктопами View Composer.
Из сторонних сервисов, необходимых для работы vCenter Server, следует упомянуть DNS. Также крайне рекомендуется использование серверов NTP для синхронизации времени. Опционально, для аутентификации при помощи доменных учетных записей может потребоваться служба каталога, например, Active Directory.
vCenter Server может быть установлен на физическом сервере или ВМ с ОС Windows Server или развернут из шаблона в виде виртуального апплайнса с ОС Linux (в vCenter 6.5 в качестве гостевой ОС используется Photon OS). Долгое время версия vCenter под Windows обладала большими функциональными возможностями, однако, начиная с vCenter 6.5, можно смело говорить о том, что виртуальный апплайнс является более предпочтительным решением по следующим причинам:
Настройки vCenter Sever, события, метрики производительности компонентов виртуальной инфраструктуры хранятся в базе данных. vCenter Server поддерживает встроенную базу (Postgres), либо внешнюю СУБД Oracle Database (Windows инсталляция vCenter также поддерживает Microsoft SQL Server). Размер базы зависит от размера виртуальной инфраструктуры, которой управляет сервер vCenter, уровня логирования и длительности хранения метрик и событий. Более подробно о версиях и редакциях поддерживаемых СУБД можно узнать из матрицы совместимости Interoperability Matrix: http://www.vmware.com/resources/compatibility/sim/interop_matrix.php.
PSC может быть установлен вместе со службами vCenter на одном сервере (Embedded PSC режим), либо на разных (External PSC режим). VMware поддерживает различные топологии развертывания vCenter Server: https://kb.vmware.com/kb/2147672. Использование External PSC может потребоваться в следующих случаях:
- Возможность использования встроенной БД (Embedded database) в виртуальном апплайнсе для управления максимальным числом хостов и виртуальных машин. Для Windows встроенная база поддерживается не более чем для 20 серверов и 200 ВМ. При необходимости управлять большими виртуальными инфраструктурами для vCenter под Windows потребуется устанавливать сторонние СУБД – Microsoft SQL Server или Oracle Database, что увеличит затраты на лицензирование и усложнит обслуживание. Сюда же можно отнести экономию на покупке лицензий для Windows Server.
- Встроенный механизм резервного копирования и восстановления (появился в vCenter Server 6.5).
- Меньший размер ВМ, отсутствие необходимости устанавливать отдельные обновления на гостевую ОС, более простая и быстрая установка и настройка (не требуется отключать лишние сервисы в гостевой ОС).
- Возможность настройки кластера высокой доступности vCenter HA (появился в vCenter Server 6.5). Для Windows инсталляции (vCenter Server 5.5 U3, 6.0, 6.5) кластер может быть организован средствами Microsoft Failover Cluster, однако такой вариант сложнее в настройке и поддержке.
Аппаратная конфигурация vCenter зависит от количества хостов и виртуальных машин, которыми управляет сервер. Ссылки на основные материалы по системным требованиям и рекомендациям приведены в статье: https://kb.vmware.com/s/article/2107948.
PSC может быть установлен вместе со службами vCenter на одном сервере (Embedded PSC режим), либо на разных (External PSC режим). VMware поддерживает различные топологии развертывания vCenter Server: https://kb.vmware.com/kb/2147672. Использование External PSC может потребоваться в следующих случаях:
- Необходимо объединить несколько vCenter Server в Linked Mode режим для управления из единой консоли.
- Требуется обеспечить высокую доступность для PSC при установке vCenter на платформe Windows Server, т.к. Microsoft Failover Cluster не поддерживает кластеризацию PSC.
- Планируется разделить нагрузку на vCenter и PSC по разным ВМ для оптимизации производительности.
Повышение доступности vCenter Server является одной из основных задач, которую требуется решить при планировании архитектуры VDI. Вот неполный список функций, которые выполняет vCenter Server:
- Централизованное управление виртуальной инфраструктурой. Часть настроек может быть выполнена только через консоль vCenter Server (настройка кластеров vSphere, настройка распределенного коммутатора, настройка vSAN и др.).
- Работа механизмов резервного копирования и мониторинга зависит от vCenter, его недоступности может привести к нарушению показателей SLA по защите данных или реакции на возникновение других проблем в работе инфраструктуры.
- Создание, настройка, обновление (recompose), очистка (refresh), перенос (rebalance) виртуальных десктопов выполняется через vCenter. Особенно важно это для non-persistent и Instant Clone ВМ, которые регулярно пересоздаются и обновляются. В случае недоступности vCenter, сервер View Connection Server не сможет выполнять данные операции, что приведет к недоступности виртуальных десктопов для конечных пользователей.
- Включение и выключение виртуальных десктопов. В качестве компенсирующей меры, на время восстановления vCenter администратор может подключиться к серверам ESXi напрямую (если такая возможность есть), и включить ВМ вручную.
- Балансирование ВМ между серверами при помощи DRS (управление питанием при помощи DPM). Отсутствие балансирование может привести к возникновению перегрузки на отдельных серверах, что повлияет на производительность и отклик ВМ, работающих на них.
Для обеспечения доступности vCenter Server могут использоваться различные механизмы, например, VMware HA или FT, а также встроенные средства кластеризации (WSFC для Windows инсталляции или vCenter HA для апплайнса). В качестве дополнительных мер, направленных на повышение доступности, могут использоваться:
- Увеличение приоритета для ВМ с vCenter при запуске средствами VMware HA.
- Резервирование процессоров и памяти для снижения влияния на производительность ВМ при переподписке ресурсов.
- Вынесение vCenter и других служебных ВМ на отдельный служебный кластер vSphere.
- Постановка сервера vCenter на мониторинг, проведения регулярных проверок основных метрик производительности и доступности сервера vCenter и нижележащих аппаратных компонентов. Использование специализированных средств мониторинга, проверяющих статус служб vCenter и БД (например, vRealize Operations или встроенный VAMI для небольших инсталляций).
5.3 Использование Enhanced Linked Mode
Enhanced Linked Mode появился в vSphere 6.0 в качестве замены режима Linked Mode, позволяющий централизованно управлять несколькими инсталляциями vCenter Server из единой консоли vSphere Web Client. Начиная с версии 6.5 Update 1 в Enhanced Linked Mode может быть объединено до 15 серверов vCenter (или до 10 в более ранних). Помимо возможности централизованного управления виртуальной инфраструктурой Enhanced Linked Mode также позволяет выполнять миграцию ВМ между хостами ESXi, управляемых разными vCenter (Cross vCenter vMotion), а также является одним из требований для распределенной инсталляции NSX (Cross vCenter NSX Installation).
Сторонние службы, такие как системы резервного копирования или мониторинга, или тот же Horizon View имеют крайне ограниченную поддержку Enhanced Linked Mode или не имеют ее вовсе, поэтому для них потребуется выполнять настройку с каждым установленным экземпляром сервера vCenter в отдельности.
При планировании использования Enhanced Linked Mode следует учитывать следующие моменты.
Во-первых, Enhanced Linked Mode поддерживается только в vCenter Server Standard и не поддерживается для редакций Foundation и Essentials. Это может потребовать дополнительных затрат на приобретение лицензий в случае с децентрализованной VDI инфраструктурой, когда небольшие инсталляции VDI на 100-200 пользователей разворачиваются в каждом филиале.
Во-вторых, все серверы vCenter должны быть членами одного PSC домена. Домен PSC указывается на этапе установки сервера vCenter и в дальнейшем не может быть изменен. Поэтому, если в инфраструктуре уже развернуты несколько серверов vCenter, каждый из которых относится к отдельному PSC домену (и даже если имена этих доменов совпадают, например, vsphere.local), то для настройки Enhanced Linked Mode потребуется выполнить повторную установку одного из серверов vCenter, указав единый PSC домен.
В-третьих, требуется использовать External PSC серверы. В принципе, это не большая проблема, т.к. существует способ миграции с Embedded PSC серверов на External, однако это потребует дополнительных работ.
5.4 Серверы виртуализации
Выбор производителя, модели и конфигурации серверов для установки гипервизора определяется множеством различных факторов, будь то требования к производительности, надежности, требованиями организации по стандартизации и унификации оборудования, ограничениями со стороны инженерной инфраструктуры (энергопотребление, тепловыделение, масса-габаритные характеристики), и, конечно, экономическими факторами.
Что касается форм-фактора, то можно разделить серверы на следующие группы:
- серверы для установки в стойку (rackmount);
- блейд серверы;
- высокоплотные серверы, которые по аналогии с блейдами устанавливаются в общее шасси, однако имеют выведенные наружу порты для подключения к внешним коммутаторам.
Типовые 1U или 2U двухсокетные серверы способны обеспечить достаточную плотность размещения виртуальных десктопов и являются подходящим решением для большинства сценариев VDI. Кроме того, такие серверы могут быть интересны в связке с программно-конфигурируемым хранилищем или как составная часть гиперконвергентной платформы за счет возможности установки большого числа накопителей (для 1U серверов обычно 8-10 накопителей форма-фактора 2.5 дюйма, для 2U – 16-24).
Блейд серверы обеспечивают большую плотность размещения по сравнению с Rackmount серверами (при использовании типовых блейд-серверов половинной высоты, в среднем – 1.2 – 1.6 серверов на 1U, не считая экономии от размещения коммутаторов), а также проще в установке и обслуживании на больших масштабах. За счет использования коммутационных модулей, устанавливаемых в блейд-шасси, возможно упростить коммутацию и локализовать часть Ethernet трафика в пределах шасси.
Наконец, высокоплотные серверы (Dell Compute Sled, HPE Apollo, Nutanix NX и многие другие) могут обеспечивать плотность до 2 серверов на 1RU. Серверы в данном конструктивном исполнении также являются популярной платформой для организации программно-конфигурируемых хранилищ.
Однако далеко не всегда высокая плотность является неоспоримым преимуществом. При использовании 1U серверов с энергопотреблением в районе 250-300 Вт, для полностью занятой стойки потребуется обеспечить подвод 10-12 кВт и, что главное, обеспечить должное охлаждение. Для блейд или высокоплотных серверов этот показатель будет в 1.5-2 раза выше.
При использовании 1U rackmount серверов, блейд-серверов или высокоплотных серверов следует помнить об ограничениях по установке плат расширения (например, графических адаптеров). Это может ограничить список выбираемых моделей серверов; для блейд-серверов также могут потребоваться модули расширения - expansion blade, которые устанавливаются в свободные отсеки блейд-шасси и позволяют устанавливать полноразмерные PCIe платы расширения. Производители адаптеров также могут накладывать дополнительные ограничения при выборе серверов (по энергопотреблению и охлаждению), или по использованию сертифицированных моделей серверов (http://www.nvidia.com/object/grid-certified-servers.html).
Еще одна проблема, которая касается блейд-серверов – наличие единой точки отказа. Выход из строя шасси затрагивает все серверы. По этой причине важно резервировать компоненты, устанавливаемые в шасси – блоки питания, коммутационные модули, модули охлаждения. Если требуется переместить шасси из одной стойки в другую, то придется отключать все серверы.
Для снижения влияния данной проблемы в больших инсталляциях рекомендуется собирать кластеры VMware из хост-серверов, размещенных в разных шасси, и резервировать вычислительные ресурсы таким образом, чтобы выход из строя одного шасси не приводил к остановке сервисов. В качестве примера можно привести рисунок, на котором отображаются 48 блейд-серверов, размещенных в 6 блейд-шасси. Для обеспечения гарантированной доступности создано четыре 12 узловых кластера с резервированием по схеме N+2, в каждый кластер добавлено по 2 сервера из каждого шасси.
5.5 Кластеры vSphere
Несколько хостов могут быть объединены в кластер для обеспечения работы механизмов высокой доступности (vSphere High Availability), балансирования нагрузки (Dirstibuted Resource Scheduler) или распределенного хранилища vSAN.
Включение VMware HA позволяет кластеру самостоятельно выполнять перезапуск ВМ на работающих серверах в случае выхода из строя одного или нескольких хостов в кластере. В случае VDI данный механизм может использоваться как для повышения доступности виртуальных рабочих станций, так и для защиты служебных ВМ без необходимости их дублирования или кластеризации на уровне приложений.
При проектировании HA кластеров может потребоваться обеспечить запас вычислительных ресурсов (процессоров и оперативной памяти). В случае аппаратного сбоя или зависания сервера отсутствие запаса вычислительных ресурсов приведет к увеличению нагрузки на процессоры и включению механизмов экономии памяти на оставшихся хостах, что негативно скажется на производительности ВМ. В качестве компенсирующих мер могут использоваться различные технологии оптимизации, вроде лимитов (Limits) или резервирования (Reservation) или долевого выделения (Shares) ресурсов для того, чтобы гипервизор отдавал приоритет в выделении ресурсов для более критичных ВМ.
Другой вариант – это оставить в кластере часть свободных ресурсов на случай отказа. Одной из распространенных схем является N+1, при которой в кластере резервируются ресурсы в размере одного хоста, позволяющей пережить единичный отказ любого сервера или выполнять обслуживание одного хоста без влияния на производительность работающих ВМ.
Схема N+2 позволяет пережить одновременный отказ или обслуживание сразу двух хост-серверов.
Схемы N+N применяются в катастрофоустойчивых сценариях для создания территориально распределенного кластера, когда половина хостов размещается на одной площадке, половина – на другой. Таким образом, отказ одной из площадок позволит автоматически перезапустить ВМ на хостах второй площадки. Кроме того, в рамках одной площадки также могут быть выделены избыточные ресурсы, например, (N+1) + (N + 1) для того, чтобы не было деградации производительности ВМ и не требовалось переключаться на вторую площадку каждый раз, когда на основной площадке происходит отказ одного хоста.
Контроль резервирования вычислительных ресурсов может выполняться администратором "на глаз", исходя из конфигурации ВМ и хостов и показаний систем мониторинга, либо с помощью HA Admission Control. До версии vSphere 6.5 Admission Control при включении использовал механизм подсчета резервирования ресурсов на основе слотов (Slot Policy или Host Failures) для того, чтобы гарантировать, что все ВМ смогут быть автоматически перезапущены при отказе одного или нескольких хостов. В vSphere 6.5 в качестве алгоритма по умолчанию используется Cluster resource percentage, который теперь автоматически рассчитывает – какой объем вычислительных ресурсов требуется зарезервировать на каждом хосте, исходя из размера кластера и кол-во хостов, которые могут отказать. Например, в кластере из 5 серверов с возможностью отказа 1 хоста Admission Control зарезервирует 20% ресурсов, а при расширении кластера до 10 серверов – только 10%.
HA кластер позволяет настраивать для ВМ разные приоритеты: lowest, low, medium, high, highest определяющие порядок запуска ВМ. При сбое хосты в кластере первыми выполняют попытку запуска ВМ из списка highest, затем high, medium и т.д. Для многоуровневых сервисов, вроде View Connection Server, View Composer, vCenter Server требуется запускать ВМ в определенном порядке. Следует помнить, что приоритеты не гарантируют корректный порядок запуска ВМ, для этого используется другой механизм – HA Orchestrated Restart.
Еще один механизм, направленный на повышение доступности ВМ, в особенности виртуальных рабочих станций, VM Monitoring. При включении VM Monitoring отслеживает состояние гостевой ОС и автоматически перезагружает ВМ, если она зависла, или в гостевой ОС возник BSOD.
5.6 VMCP
Для ВМ, размещаемых на VMFS хранилищах, доступен Virtual Machine Component Protection (VMCP), защищающий от сбоев хранилища. VMCP позволяет отрабатывать следующие сбои на уровне СХД:- Permanent Device Lost (PDL).
- All Paths Down (APD).
В случае возникновения PDL, например, при удалении логического тома на дисковом массиве или изменении в настройках презентации тома хост-серверу, HA кластер может перезапустить ВМ на другом хосте.
При возникновении ситуации APD хост запускает таймер в течение которого пытается восстановить связь с хранилищем. По истечении интервала APD timeout (140 секунд), хост прекращает попытки восстановить связь с хранилищем и останавливает все операции ввода-вывода за исключением ввода-вывода с ВМ, и запускает второй таймер Delay for VM Failover for APD. Если связь с хранилищем восстанавливается до истечения второго таймаута, хост перезапускает ВМ для восстановления работы гостевой ОС. При превышении интервала Delay for VM Failover for APD механизм HA может выключить ВМ и попытаться перезапустить ее на другом хосте кластера.
При планировании VMCP следует помнить, что он работает только для VMFS хранилищ. NFS, VSAN хранилища и VVOLS не поддерживаются, также VMCP не применим для ВМ, защищаемых при помощи Fault Tolerance.
5.7 Изоляция хостов и Datastore Heartbeating
В случае, когда хост теряет связь с другими хостами (перестает получать heartbeat сигналы), он выполняет проверку изоляции, отправляя ICMP Echo запрос на адрес для проверки изоляции. По умолчанию в качестве такого адреса используется маршрутизатор по умолчанию, указанный в настройках хоста, но при необходимости может быть настроено несколько адресов. В случае, если ответ от узла для проверки изоляции не приходит, хост считает, что он изолирован от других хостов кластера, и выполняет действие в соответствии с настройками кластера:
- Не выполняет никаких действий.
- Выключает ВМ (Shutdown).
- Жестко выключает ВМ (Power off).
В большинстве инсталляций рекомендуется выключать ВМ при изоляции хоста, чтобы другие серверы в кластере, которые сохранили сетевую связность смогли перезапустить данную ВМ. Однако, в случае, когда хосты кластера подключаются к одному коммутатору или стеку коммутаторов, одновременный сбой сети на всех хостах может привести к тому, что все хосты кластера станут изолированными и выключат все ВМ.
Для определения доступности узлов один из хостов кластера назначается мастер хостом. Мастер хост отвечает за рассылку сигналов доступности (Heartbeats) остальным хостам кластера. Узлы кластера, соответственно, должны отвечать мастер хосту. В случае если мастер хост не получает сигнал доступности, он пытается отправить Echo запрос узлу. Если хост не отвечает на Echo запрос, мастер пытается проверить его доступность, используя механизм Datastore Heartbeating, используя сеть передачи данных.
В качестве хранилищ для Datastore Heartbeating могут использоваться VMFS или NFS хранилища, для VSAN данный механизм не поддерживается.
В случае, если хост не отвечает на Heartbeat и Echo запросы по сети, но доступен через Datastore Heartbeating, мастер хост считает хост изолированным от сети или находящимся в отдельном сетевом сегменте (партиции), и не предпринимает попыток перезапуска ВМ, зарегистрированных на данном хосте, но продолжает следить за состоянием хоста и ВМ. В случае, если ВМ выключаются или хост перестает отвечать на Datastore Heartbeating, мастер хост выполняет попытку перезапустить ВМ на оставшихся узлах кластера.
5.8 Distributed Resource Scheduler и пулы ресурсов
DRS позволяет выравнивать загрузку вычислительных ресурсов в кластере, выполняя автоматическую миграцию ВМ с более загруженных серверов на менее загруженные. В целом включение DRS не несет каких-либо негативных последствий, но из-за требования к доступности или лицензированию можется потребоваться дополнительная проработка вопроса размещения ВМ на определенных хостах или разнесения ВМ по разным хостам (что решается с помощью Affinity Rules).
Включение DRS позволяет использовать в кластере пулы ресурсов (Resource Pool). Основная задача пулов ресурсов – деление вычислительных ресурсов кластера (процессоров и памяти) для предоставления их определенной группе ВМ, расположенной внутри пула ресурсов, за счет использования механизмов резервирования, лимитов и долевого деления.
Некоторые администраторы используют пулы ресурсов как каталоги для группировки ВМ внутри кластера при работе с Hosts & Clusters для удобства поиска ВМ или назначения на пул ресурсов разрешений.
Использовать пулы ресурсов следует осторожно, т.к. потенциально это может привести к перекосу в производительности ВМ.
Для примера рассмотрим следующий сценарий. В VDI инфраструктуре администратор создает два пула View с десктопами – тестовый, включающий 10 десктопов и производственный, включающий 500 типовых виртуальных десктопов, с которыми работают пользователи. Для простоты администратор решил в настройках каждого пула View указать, чтобы для каждого типа десктопов использовались отдельные пулы в кластере, например, Test и Prod.
В случае нехватки вычислительных ресурсов, согласно настройкам shares, заданных в пулах ресурсов по умолчанию, каждый пул ресурсов получит одинаковое количество процессорных ресурсов несмотря на то, что в первом пуле размещается всего 10 ВМ, а во втором – 500 ВМ, что приведет к тому, что одной ВМ достанется больше ресурсов, чем одной производственной. Решить эту проблему можно отказавшись от пулов ресурсов, или настроив корректное соотношение Shares для пулов.
5.9 Affinity Rules
Одним из механизмов, позволяющим контролировать перемещение ВМ между хостами являются Affinity правила. Всего можно выделить три типа правил:
- VM Affinity rules.
- VM Anti-affinity rules.
- VM to Host affinity rules.
VM Affinity rules позволяют группировать ВМ на одном хосте, что полезно в тех случаях, когда вы хотите минимизировать сетевые задержки при взаимодействии ВМ или локализовать сетевой трафик между ВМ в пределах хоста. При размещении ВМ на одном хосте может потребоваться настроить корректный порядок запуска на случай отказа хоста, для этих целей можно использовать HA Orchestrated Restart.
Anti-affinity правила, наоборот позволяют DRS определить, что ВМ требуется разнести по разным хостам, для того, чтобы минимизировать риск недоступности сервиса из-за одновременного отказа нескольких однотипных ВМ. Как пример, разнесение узлов кластера SQL Server или серверов View Connection Server.
VM to Host Affinity правила позволяют привязать ВМ к какому то определенному хост серверу или группе хостов. VM to Host Affinity правила могут применяться для соблюдения требований по лицензированию ПО, в тех случаях, когда лицензии привязываются к физическим серверам. Ограничив перечень хостов, на которых будет запускаться ВМ, будет достаточно приобрести лицензии только на эти хосты, а не на весь кластер.
VM to Host Affinity правила делятся на Should и Must правила. Should работает по принципу best efforts, правила соблюдаются пока это возможно, однако могут нарушаться в нештатных ситуациях, например, при падении хоста и перезапуска ВМ средствами HA.
Must правила гарантируют, что ВМ всегда будет размещаться на тех хостах, к которым привязана. HA кластер учитывает must правила, и в случае невозможности соблюсти их, просто не запустит ВМ.
VM to Host Affinity правила также могут использоваться для упрощения администрирования. Вы можете создать Should правило, которое привяжет ВМ с vCenter Server или другие служебные ВМ к определенному хосту, и в случае недоступности vCenter вы сможете быстро отыскать нужную ВМ.
Наконец VM to Host Affinity могут использоваться в сценариях территориально распределенного кластера. Благодаря VM to Host Affinity правилам вы можете привязать группу ВМ к хостам на одной из площадок, что позволит локализовать ввод-вывод с дискового хранилища и меньше загружать межсайтовое соединение.
