Парсер для правил NSX Distributed Firewall

Update 05.08.2018: в новой версии появилась возможность подключения к NSX Manager для экспорта текущих правил.

VMware NSX позволяет экспортировать правила распределенного фаерволла в файл в XML формате. Данный формат не очень удобен для анализа и включения в документацию, поэтому я написал небольшой парсер, конвертирующий правила из XML формата в HTML или CSV.

Скрипт имеет следующий формат:
Parse-NSXRules.ps1 -FilePath <string> -ResultPath <string> [-Property <string>] [-Format <string>]

и использует следующие параметры:

• -ResultPath <string> - (обязательный) Указывает путь к файлу, в котором будут сохранены результаты.
• -FilePath <string> - (опциональный) Указывает путь к XML файлу с правилами.
• -Property <string> - (опциональный) Указывает перечень столбцов для отображения, разделенных запятыми. По умолчанию отображает все столбцы.
• -Format <string> - (опциональный) Указывает формат итогового файла. Поддерживает CSV, HTML или XML. По умолчанию используется HTML формат.
• -NSXManager <string> - (опциональный) Указывает IP адрес или DNS имя сервера NSX Manager для подключения.
• -Username <string> - (опциональный) Указывает имя пользователя для подключения к NSX Manager.
• -Password <string> - (опциональный) Указывает пароль пользователя для подключения к NSX Manager.

Примеры использования скрипта:

#Сохранить результат в HTML файле
.\Parse-NSXRules.ps1 -FilePath C:\Temp\NSX_rules.xml -Format HTML -ResultPath C:\Temp\parsed_rules.html

#Сохранить результат в CSV, отобразить только столбцы id,name,source и action
.\Parse-NSXRules.ps1 -FilePath C:\Temp\NSX_rules.xml -Format CSV -ResultPath C:\Temp\parsed_rules.csv -Property "id,name,source,action"

#Подключиться к NSX Manager и сохранить результат в формате XML
\parse-nsxrules.ps1 -Format XML -ResultPath C:\Temp\parsed_rules.csv -NSXManager 192.168.1.10 -Username admin -Password VMware1!

Пример получаемого HTML файла:

Загрузить скрипт можно по ссылке: https://github.com/omnimod/NSX-Firewall-Rules-Parser

Немного о дизайне VDI. Часть 9. Сетевая подсистема

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины
Часть 8. Подсистема хранения

9.1 Требования к производительности сети

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

При планировании VDI следует обратить внимание на то, какие требования предъявляют и какую нагрузку создают следующие типы трафика:

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

В сценариях VDI виртуальные десктопы и серверы приложений находятся достаточно "близко" друг от друга, трафик передается внутри ЦОД по высокоскоростной сети. В этом и заключается одно из главных отличий VDI от физических рабочих станций. Централизация позволяет снизить нагрузку на канал передачи данных от пользовательских рабочих места до ЦОД. Пользователи могут заметить повышение производительности в работе приложений, в качестве примера можно рассмотреть вариант с открытием и сохранением больших документов, которые раньше передавались по сети 100 Мбит/с или 1 Гбит/с на физическую рабочую станцию, а теперь передаются на виртуальный десктоп, подключенный к сети 10 Гбит/с. Однако, несмотря на локализацию внутри ЦОД, трафик приложений все-равно следует учитывать при сайзинге количества и типа сетевых интерфейсов серверов виртуализации.

Трафик протоколов удаленного доступа (PCoIP, Blast или RDP) также следует учитывать при планировании конфигурации серверов и коммутаторов, однако большее влияние он оказывает на WAN-каналы передачи данных при организации подключения пользователей из удаленных филиалов или из Интернет. Каналы с недостаточной пропускной способностью, большими потерями и высокими задержками будут напрямую влиять на качество изображения, скорость отрисовки и время отклика протоколов удаленного доступа, а следовательно, и на удовлетворенность пользователей от работы с виртуальным десктопом.

Нагрузка, создаваемая при подключении к виртуальным десктопам, зависит от используемого протокола, количества и разрешения мониторов, настроек качества изображения и частоты обновления. В среднем, для типового пользователя Knowledge Worker утилизация составляет 150-200 Кбит/с. Просмотр изображений и видео, работа с 3D графикой увеличивает требования к каналу.

При сайзинге требуемой полосы пропускания для протокола PCoIP следует воспользоваться рекомендациями из PCoIP Session Planning Administrators' Guide (https://www.teradici.com/web-help/TER1105004/Sess-Plan_Admn-Gd.pdf) и Horizon 7 Architecture Planning (https://docs.vmware.com/en/VMware-Horizon-7/7.5/horizon-architecture-planning.pdf).

В тестовой среде или пилотной инсталляции основные метрики производительности протокола удаленного доступа и утилизация канала могут быть получены при помощи счетчиков Perfmon, или из журналов PCoIP или Blast. Также можно воспользоваться ПО vRealize Operations for Horizon, позволяющим централизованно собирать статистику о работе протоколов удаленного доступа с виртуальных десктопов.

Служебный трафик может составлять значительную часть от всего сетевого трафика, генерируемого VDI инфраструктурой. К служебному трафику можно отнести трафик vSAN, трафик Fault Tolerance, трафик репликации данных в СУБД Microsoft SQL или файловых серверов DFS-R, vCenter Server, установленном в HA режиме, репликации ВМ средствами vSphere Replication, трафик системы резервного копирования. Fault Tolerance или All-Flash vSAN могут накладывать дополнительные ограничения на минимальную скорость подключения (не менее 10 Гбит/с).

9.2 Планирование адресного пространства

Разделение адресного пространства на несколько подсетей может быть продиктовано желанием уменьшить широковещательный домен или отделить трафик виртуальных десктопов от служебных ВМ из-за требований безопасности.

При необходимости размещения виртуальных десктопов в нескольких подсетях следует учитывать следующие моменты.

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

Решить эту проблему для Pooled ВМ можно, вручную перемещая ВМ в целевые группы портов, либо используя механизм Multiple Network Labels, позволяющий в настройках пула указать несколько виртуальных сетей (групп портов) и максимальное количество адресов, которые могут быть выделены в каждой сети.

9.3 Выбор виртуального коммутатора

В зависимости от версии гипервизора для организации сети поддерживаются следующие типы виртуальных коммутаторов:

• стандартный виртуальный коммутатор (vSS – vNetwork Standard Switch);
• распределенный виртуальный коммутатор (vDS – vNetwork Distributed Switch);
• сторонний виртуальных коммутатор (Third-party Switch).

Из-за прекращений поддержки сторонних коммутаторов в ESXi после версии 6.5 U1, на текущий момент имеет смысл рассматривать выбрить только между vSS и vDS. Различия в функциональных возможностях коммутаторов приведены в таблице.

Функции	vSS	vDS
Поддерживаемые редакции vSphere	Essentials или выше	Enterprise Plus Входит в состав лицензий NSX или VSAN
Требует наличие vCenter Server для настройки	Нет	Да
Шейпинг входящего трафика ВМ (Egress)	Да	Да
Шейпинг исходящего трафика ВМ (Ingress)	Нет	Да
Поддержка агрегации канала / NIC Teaming	Только статическая (для IP Hash)	Статическая и LACP
Варианты балансирования трафика	Port ID MAC Hash IP Hash Failover	Port ID MAC Hash IP Hash Failover Based on NIC Load LACP
Поддержка NetFlow	Нет	Да
Поддержка Port Mirroring (SPAN, RSPAN)	Нет	Да
Встроенный фильтр трафика	Нет	Да
Тегирование трафика QoS	Нет	Да
Поддержка NIOC	Нет	Да
Создание виртуальных логических сетей NSX	Нет	Да
Интеграция с распределенным брандмауэром NSX	Да	Да

Несмотря на зависимость vDS коммутатора от vCenter Server, он предоставляет гораздо больше функциональных возможностей по сравнению со стандартным коммутатором и рекомендуется к использованию в большинстве инсталляций VDI. vSS может использоваться для небольших/тестовых инсталляциях, а также в тех случаях, когда используется vSphere Standard, в которой отсутствует vDS.

ESXi поддерживает следующие алгоритмы балансирования и отказоустойчивости сетевых интерфейсов:

• Load based on Port ID;
• Load based on MAC Hash;
• Load based on IP Hash;
• Failover;
• Load based on NIC Load.

Failover – самый примитивный режим, не обеспечивает балансировку трафика и используется только для отказоустойчивости. Все сетевые интерфейсы ВМ подключаются к первому в списке активному физическому интерфейсу (аплинку), в случае его недоступности – ко второму, и т.д.

Port ID – является типовым режимом, работающим по принципу Round Robin. Сетевые интерфейсы ВМ и VMKernel равномерно распределяются между аплинками в режиме чередования, в зависимости от того, к какому порту виртуального коммутатора они подключены. Например, для двух аплинков первая ВМ будет подключена к первому аплинку, вторая – ко второму аплинку, третья – снова к первому, и т.д.

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

MAC Hash также распределяет виртуальные адаптеры по аплинкам, как и Port ID, однако выбор аплинка выполняется на основании хэша MAC адреса виртуального сетевого интерфейса.

IP Hash динамически выбирает аплинки для отправки пакета в зависимости от IP адреса источника и назначения. Данный алгоритм балансировки требует настройки агрегации сетевых интерфейсов со стороны сетевого коммутатора (Static EtherChannel в терминологии Cisco).

Load based on NIC Load распределяет сетевые адаптеры схожим с Port ID образом за исключением того, что гипервизор отслеживает нагрузку на аплинках, и если нагрузка между аплинками различается более, чем на 70%, то автоматически переключает сетевые интерфейсы ВМ с более загруженного на менее загруженный аплинк.

Отдельно следует сказать про балансирование трафика средствами LACP Aggregation Group (LAG). LAG не являются одним из алгоритмов балансировки, доступны только в связке с распределенным коммутатором, позволяют объединить до 8 физических интерфейсов в LAG и настроить на нем способ балансирования трафика. В vSphere доступно 22 алгоритма балансировки.

9.4 VMware NSX

VMware NSX может применяться в сценариях VDI для решения следующих задач:

• Микросегментация/фильтрация трафика между виртуальными десктопами и служебными ВМ.
• Обеспечения связности между подсетями/маршрутизация трафика средствами гипервизора.
• Интеграция с ПО антивирусной защиты.
• Организация L2 сетей для обеспечения катастрофоустойчивости или для виртуальных инфраструктур, охватывающих несколько площадок (Cross-vCenter NSX).

NSX Distributed Firewall – функция микросегментирования позволяет фильтровать любой трафик отправляемый или получаемый сетевыми интерфейсами ВМ, в том числе, передающийся между ВМ, расположенными в одной подсети и даже запущенные на одном физическом сервере. Данная возможность отличает NSX от классических межсетевых экранов, которые могут фильтровать трафик передаваемые только между разными подсетями. Это позволяет обеспечить передачу трафика, необходимого для работы VDI и приложений, и запретить все остальное сетевое взаимодействие. При создании правил в качестве источника или назначения трафика могут использоваться:

• MAC адрес.
• IP адрес.
• Конкретная ВМ или сетевой адаптер ВМ.
• Группа безопасности, в которую входят ВМ.
• Группа безопасности, в которую входит группа пользователей Active Directory.
• Логическая сеть, группа портов на стандартном или распределенном коммутаторе.
• Кластер или виртуальный ЦОД целиком.

Про группы безопасности следует упомянуть отдельно. Членство в группах может быть статическим – администратор вручную указывает, какие ВМ входят в группу, либо динамическим. NSX может включать ВМ в группу безопасности на основании операционной системы, установленной в ВМ (например, все ВМ, с ОС Windows, все ВМ с ОС Windows XP и т.д.), на основании тэга безопасности, присвоенной ВМ (можно создать тэг "Connection Servers" и назначить его соответствующим ВМ), на основании имени ВМ (все ВМ, имя которых начинается с vdi-desktop) и другие критерии.

Отдельного упоминания заслуживает возможность включить в группу безопасности доменные группы пользователей из Active Directory. В этом случае появится возможность создавать т.н. Identity Based правила, которые будут применяться к ВМ после того, как в них вошли доменные пользователи, которые являются членами определенной доменной группы.
NSX Distributed Logical Router позволяет перенести задачи по маршрутизации трафика виртуальной инфраструктуры с физических маршрутизаторов на гипервизоры.

Функция NSX Guest Introspection поддерживается многими современными антивирусными решениями, и позволяет полностью отказаться от необходимости установки и периодического обновления антивирусного агента внутрь ВМ, либо использовать облегченные версии антивирусных агентов.

Использование L2 логических сетей (Logical Network) на базе VXLAN позволяет связать две площадки и организовать катастрофоустойчивый территориально-распределенный кластер (stretched cluster), либо выполнить развертывание NSX в режиме Cross-vCenter и объединить несколько инсталляций vCenter на разных площадках и обеспечить L2 связность при помощи универсальных логических сетей и универсальных маршрутизаторов.

VMware NSX не входит в состав Horizon, поэтому его требуется приобретать отдельно. Для сценариев VDI возможно лицензирование NSX по физическим процессорам/сокетам серверов виртуализации, либо по количеству запущенных ВМ (NSX for Desktop, данный вариант лицензирования предназначен для сценариев VDI и имеет те же ограничения, что и vSphere for Desktop или vSAN for Desktop).

Из других функций, которые также могут найти применение в сценариях VDI следует отметить балансировщик нагрузки в NSX Edge Services Gateway, который может использоваться для балансировки нагрузки между View Connection Server или Unified Access Gateway, а также VPN (L2 Site-to-Site VPN для организации связности удаленных площадок и SSL VPN – для подключения пользователей).

VMware NSX доступен в нескольких редакциях, до версии 6.4 – это были Standard, Advanced и Enterprise, начиная с версии 6.4 основные редакции (не считая ROBO): Standard, Professional, Advanced и Enterprise Plus (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/nsx/vmware-nsx-datasheet.pdf).

При выборе редакции следует учесть – какие функции требуются от NSX. Так, например, NSX Distributed Firewall доступен в редакции Professional и выше, Identity Based правила и территориально-распределенные инсталляции Cross-vCenter NSX – в Advanced и выше.

Продолжение доступно по ссылкам:

Часть 10. Организация подключения и безопасность
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление

Немного о дизайне VDI. Часть 7. Виртуальные машины

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI

7.1 Служебные виртуальные машины

К служебным ВМ относятся серверы, обеспечивающие работу VDI инфраструктуры: vCenter Server, View Connection Server, Unified Access Gateway, View Composer и пр.

В официальной документации VMware приводится информация к требуемым аппаратным ресурсам и перечень совместимых ОС и СУБД для каждого компонента VDI инфраструктуры. Зачастую служебные ВМ поставляются производителем в виде готовых виртуальных апплайнсов с заранее определенной аппаратной конфигурацией.

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

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

7.2 Клиентские виртуальные машины

Сайзинг и требования к вычислительным ресурсам для клиентских ВМ зависят от различных факторов:

• Суммарное количество виртуальных десктопов.
• Способ создания и обновления ВМ, частота выполнения обновлений образом.
• Используемая ОС.
• Используемое прикладное и системное ПО, способ доставки ПО на виртуальные десктопы.
• Используемые протоколы, функции и устройства при подключении к виртуальным десктопам.
• Оптимизация виртуальных десктопов.

7.3 Сайзинг вычислительных ресурсов

В моей практике оценка необходимых процессорных ресурсов является наиболее трудоемкой частью сайзинга виртуальных десктопов. Нехватка процессорных ресурсов приводит к снижению производительности и увеличению времени отклика приложений, и как следствие – к недовольству пользователей, особенно в тех случаях, когда виртуальные рабочие станции заменяют собой достаточно производительные и современные ПК с мощными процессорами. Избыток процессорных ресурсов влечет за собой увеличение стоимости реализации проекта – высокопроизводительные процессоры (например Intel Xeon Platinum) с большей тактовой частотой и большим количеством ядер стоят ощутимо дороже процессоров среднего ценового диапазона, к тому же обладают более высоким энергопотреблением и тепловыделением, что также повышает требования к инженерной инфраструктуре ЦОД.

При планировании процессорных ресурсов следует учитывать не только нагрузку, создаваемую ОС и приложениями, но также нагрузку, создаваемую служебным ПО, в первую очередь Horizon Agent. При кодировании изображения в высоком разрешении с часто меняющейся картинкой (например, при воспроизведении видео), нагрузка на процессор может достигать 25-40% (в зависимости от частоты и кол-ва ядер, выделенных ВМ). Другим ресурсоемких служебным ПО являет ПО антивирусной защиты, также может приводить к росту загрузки процессорных ресурсов, особенно в случае Antivirus Storm – одновременной массовой проверки антивирусным ПО большого количества виртуальных десктопов.

Показатель консолидации (соотношение виртуальных ядер vCPU к физическим pCPU) зависит от многих факторов и должен определяться на этапе пилота. В среднем для VDI сценариев показатель консолидации составляет от 6 до 12 vCPU на один pCPU. Если возможность провести полноценный пилот отсутствует, то рекомендуется воспользоваться утилитами для проведения нагрузочного тестирования, эмулирующими работу пользователей с VDI, например, Login VSA или VMware View Planner.

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

vSphere предоставляет следующие технологии управления оперативной памятью:

vSphere предоставляет следующие технологии управления оперативной памятью: Transparent Page Sharing (TPS), Memory Ballooning, Memory Compression, VM Swap.

При проектировании VDI следует определиться с тем, планируете ли вы использовать overcommit по памяти или нет, т.е. возможны ли ситуации, когда ВМ будет выделено памяти больше, чем имеется на сервере/кластере или нет. В качестве примера такой ситуации – сбой одного или нескольких серверов, что приведет к нехватке вычислительных ресурсов до момента их починки или замены. Использование overcommit в разумных пределах позволяет снизить стоимость VDI, однако следует помнить, что overcommit негативно сказывается на производительности, приводя к повышенной загрузке процессора (при использовании TPS и Memory Compression) и дисковой подсистемы (при использовании Memory Ballooning и VM Swap).

TPS – технология дедупликации страниц оперативной памяти. За счет того, что в VDI инфраструктурах на каждом хосте работает большое количество однотипных ВМ, показатели экономии при использовании TPS могут достигать 30% и более. Однако следует помнить о  следующих нюансах, которые могут снизить эффектность работы TPS.

Современные гостевые ОС и сам гипервизор ESXi могут выделять оперативную память для ресурсоемких приложений большими страницами, что позволяет снизить накладные расходы на управление памятью. TPS отлично работает при дедупликации страниц памяти размером 4 КБ и практически не работает для больших страниц (2 МБ). Кроме того использование механизма безопасности Address space layout randomization (ASLR), по умолчанию включенного в современных ОС, также снижает  эффективность работы TPS.

Начиная с vSphere 5 появился механизм подсаливания (salting), который позволяет ограничивает область работы механизма дедупликации памятью одной виртуальной машиной или набором виртуальных машин, имеющих общий ключ. Это позволяет исключить вероятность неавторизованного доступа к содержимому памяти одной ВМ из другой ВМ, платой за это также является снижение эффективности работы TPS. Более подробно о работе механизма написано в статье: https://kb.vmware.com/kb/2097593.

Другой механизм экономии памяти – Memory Ballooning требует для работы использования файла подкачки в гостевой ОС, что увеличивает размер дискового пространства, которое занимают ВМ на хранилище.

Резервирование оперативной памяти позволяет задать гарантированый объем памяти, который будет выделен ВМ при запросе. Для ВМ возможно частичное или полное резервирование памяти.

Полное резервирование памяти требуется для включения Fault Tolerance, а также подключения к ВМ графических ускорителей в режиме vDGA или vGPU.

При резервировании памяти пропорционально уменьшается объем файла подкачки ВМ (.vswp), так что если вы не планируете использовать memory overcommit, то резервирование памяти позволит снизить объем дискового пространства, занимаемого ВМ.

Помимо памяти, выделяемой непосредственно ВМ, следует помнить и о накладных расходах (overhead). При включении ВМ гипервизор резервирует часть памяти для обеспечения работы ВМ – поддержку таблицы страниц памяти, работу виртуальных устройств и пр. Размер Overhead зависит от объема памяти и количества ядер, которые были выделены виртуальной машине. https://docs.vmware.com/en/VMware-vSphere/5.5/com.vmware.vsphere.resmgmt.doc/GUID-B42C72C1-F8D5-40DC-93D1-FB31849B1114.html. Современные версии ESXi используют файл подкачки VMX Swap для того, чтобы уменьшить объем резервируемой памяти.

7.4 Сайзинг дискового пространства 

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

• виртуальные диски ВМ, на которых размещается ОС, приложения, данные пользователей;
• файл конфигурации ВМ и журналы ВМ (.vmx и .log файлы);
• файл подкачки ВМ (.vswp файл).

VMware Horizon предоставляет различные механизмы, позволяющие оптимизировать использование дискового пространства виртуальными десктопами. К таким механизмам относятся:

• Thin Provisioning – позволяет создавать виртуальные диски без предварительной резервации дискового пространства, которые растут по мере их заполнения данными.
• Linked Clones – позволяет создавать разностные (дельта) диски, которые используют единый мастер образ для однократного хранения общего набора данных (ОС, базовый набор приложений) и дельта диски, в которые записываются все изменения, сделанные в конкретной ОС. В инфраструктуре VMware работа Linked Clones основана на механизме снапшотов. В зависимости от объема изменений и того, как часто выполняется Recompose или Refresh ВМ, показатель экономии варьируется от 50 до 95% (для постоянных Linked Clone ВМ средний показатель экономии составляет 70%).
• Space Reclamation – связан с технологиями Thin Provisioning и Linked Clones. По умолчанию, тонкие диски растут по мере заполнения их данными, однако, в случае удаления данных внутри гостевой ОС, размер тонкого диска автоматически не уменьшается и требует ручного запуска команды на стороне хоста. Space Reclamation позволяет проводить процедуру уменьшения тонкого диска созданного с использованием технологии Linked Clones по расписанию.
• Откат изменений (Refresh) / удаление ВМ. Для non-persistent floating виртуальных машин возможно настроить механизм, выполняющий очистку всех изменений, сделанных пользователем после завершения сеанса работы. Это позволяет держать размер виртуального диска Linked Clone ВМ на минимальном уровне. Другой механизм, который также может использоваться и для Full Clone VM является автоматическое удаление и пересоздание ВМ после завершения работы.
• Вынос временных файлов и файла подкачки гостевой ОС на временный (non-persistent) диск. Диски автоматически обнуляются при выключении ВМ, высвобождая место, уменьшая фрагментацию дельта дисков, их размер, скорость роста.

Помимо оптимизаций VMware, многие современные массивы поддерживают технологии оптимизации использования дискового пространства: Thin provisioning lun, дедупликация, компрессия, аппаратная поддержка linked clones (vSphere API for Composer Array Integration). 

Следует помнить, что далеко не все механизмы экономии хорошо сочетаются друг с другом. Например, экономия дискового пространства при использовании all-flash массивов с дедупликацией при создании full-clone десктопов достигает 10-кратной и более значений, тогда как для linked-clone десктопов показатели дедупликации редко превышают 1.5-2.

Важным шагом по уменьшению размера дисков ВМ является оптимизация дискового пространства внутри гостевой ОС.

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

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

Удаление встроенных приложений, вроде Metro приложений Windows, Internet Explorer или Windows Media Player (если они не требуются для работы) позволит уменьшить занимаемое дисковое пространство и не тратить ресурсы на обновление неиспользуемых компонентов. 

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

Другим распространенным вариантом является упаковка приложений, например, при помощи технологии ThinApp и потоковая доставка (streaming) приложения с файлового сервера. В этом случае приложение будет запускаться по сети, и не потребуется копировать целиком весь образ на виртуальный десктоп.

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

Наконец, одним из самых эффективных и быстрых вариантов доставки является использование механизма App Volumes, позволяющий распростарнять приложения на десятки и сотни ВМ одновременно без необходимости предварительной установки на каждый десктоп.

7.5 Графические адаптеры

В любой виртуальной машине присутствует виртуальный графический адаптер (VMware SVGA 3D), который используется для рендеринга изображения и в качестве фреймбуффера для вывода изображения в консоль MKS (Mouse, Keyboard, Screen) и на виртуальные дисплеи при подключении к десктопу по протоколам PCoIP или Blast. При сайзинге конфигурации ВМ важно правильно оценить объем памяти, который требуется зарезервировать для виртуального графического адаптера. При выставлении слишком большого разрешения, например, при подключении к десктопу с клиентского устройства оборудованного 4К монитором, в случае нехватки видеопамяти вместо изображения пользователи будут видеть черный экран.

Виртуальный графический адаптер не используется, когда пользователи подключаются к десктопу по протоколу RDP (т.к. за прорисовку экрана отвечает протокол RDP), или при использовании режимов ускорения vDGA или vGPU (в этом случае за прорисовку экрана будет отвечать физический графический адаптер, подключенный к ВМ). В этих случаях следует выделять виртуальному графическому адаптеру минимально возможный объем памяти для экономии ресурсов.

Помимо прорисовки экрана графический адаптер может брать на себя задачи связанные с рендерингом трехмерной графики. Для ВМ поддерживаются следующие режимы ускорения:

• Без ускорения (параметр Enable 3D Support отключен). Обработка графики выполняется центральным процессором сервера. Видеопамять виртуального выделяется целиком из оперативной памяти сервера. Максимальный объем памяти, выделяемой одной ВМ, составляет 128 МБ.
• Software 3D – при включении данного режима каждой ВМ выделяется дополнительная память (3D Memory) объемом от 32 до 512 МБ (которая также берется из оперативной памяти сервера), использующаяся для рендеринга графики. Для этих целей также используется центральный процессор. В данном режиме поддерживаются
• vSGA (Virtual Shared Graphics Acceleration) – ВМ использует виртуальный графический адаптер, однако функции по обработке графики перекладываются на совместимый графический адаптер, установленный в сервере. vSGA также поддерживает выделение видеопамяти от 32 до 512 МБ, однако только половина видеопамяти выделяется из оперативной памяти сервера, вторую половину памяти выделяет физический графический адаптер.
• vDGA (Virtual Dedicated Graphics Acceleration) – режим при котором графический адаптер монопольно выделяется одной ВМ при помощи технологии DirectPath I/O. В гостевой ОС устанавливается драйвер от производителя адаптера, вся обработка и вывод графики осуществляется физическим графическим адаптером.
• Virtual Shared Pass-Through Graphics Acceleration. В данном режиме графический адаптер разделяется на несколько частей/виртуальных GPU, каждый из которых выделяется своей ВМ. Реализация данного режима различается у NVIDIA и AMD. Для ускорителей NVIDIA технология носит название vGPU и предполагает деление графического адаптера на основании профилей, указанных в настройках ВМ в момент запуска ВМ. Для графических адаптеров AMD технология MxGPU предполагает предварительное разделение адаптера на части нужного размера, после чего отдельные виртуальные GPU презентуются ВМ. Данный режим обеспечивает меньшую производительность, но большую гибкость и лучшую консолидацию по сравнению с vDGA.

Следует помнить, что режимы vDGA и vGPU помимо ускорения трехмерной графики также могут использоваться для аппаратного декодирования видео с помощью встроенных кодеков, кодирования изображения для протокола VMware Blast, а также для выполнения математических расчетов и ускорения работы приложений (например, для приложений, которые поддерживают CUDA или OpenCL).

В таблице приведена сводная информация по режимам ускорения графики.

Режим	Без ускорения	Software 3D	vSGA	vDGA	vGPU	MxGPU
Поддерживаемые версии DirectX	11, 10, 9	10, 9	10, 9	Зависит от адаптера	Зависит от адаптера	Зависит от адаптера
Производительность	Очень низкая	Очень низкая	Низкая	Очень высокая	Высокая	Высокая
Тип графического адаптер / Драйвер	VMware SVGA 3D	VMware SVGA 3D	VMware SVGA 3D	AMD / Intel / NVIDIA	NVIDIA	AMD
Максимальный объем видеопамяти	128 МБ	512 МБ	512 МБ	Зависит от адаптера	Зависит от адаптера	Зависит от адаптера
Аппаратное ускорение графики	Нет	Нет	Да	Да	Да	Да
Монопольное использование графического ускорителя одной ВМ	-	-	Нет	Да	Нет	Нет
Требуется зарезервировать память (Memory Reservation)	Нет	Нет	Нет	Да	Да	Да
Поддержка High Availabilit	Да	Да	Да	Нет	Да	Нет
Поддержка vMotion / DRS	Да	Да	Да	Нет	Нет	Нет
Поддержка аппаратного кодирования Blast	Нет	Нет	Нет	Да, для NVIDIA	Да	Нет

7.6 Конфигураторы ВМ

Помимо сайзинга вычислительных ресурсов вручную могут использоваться специализированные утилиты.

Пожалуй, самым известным независимым инструментом является калькулятор VDI calculator (http://myvirtualcloud.net/vdi-calculators-2/) за авторством Andre Leibovici. Калькулятор может выполнять сайзинг для различных платформ, типов рабочих столов, типов хранилищ, предоставляет огромное количество параметров для настройки, и рекомендуется в качестве основного инструмента для сайзинга или самопроверки.

VSAN TCO and Sizing Calculator (https://vsantco.vmware.com/vsan/SI/SIEV) от VMware пригодится в тех случаях, когда вы планируете развернуть VDI на базе хранилища VSAN.  Калькулятор прост в освоении и позволяет получить на руки рекомендуемые аппаратные конфигурации серверов (из списка VSAN Ready Nodes).

7.7 Оптимизация образа

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

Пожалуй, самым популярным инструментом для оптимизации ОС является VMware OS Optimization Tool доступный для загрузки с сайта (https://labs.vmware.com/flings/vmware-os-optimization-tool). Помимо встроенных шаблонов вы также можете использовать шаблоны сторонних разработчиков, например, шаблон, подготовленный login vsi: https://www.loginvsi.com/blog/520-the-ultimate-windows-10-tuning-template-for-any-vdi-environment.

Продолжение доступно по ссылкам:

Часть 8. Подсистема хранения
Часть 9. Сетевая подсистема

Часть 10. Организация подключения и безопасность

Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление

Ошибка 1603 при установке Horizon View Composer 7.x

При установке VMware View Composer 7.x на Windows Server 2012 или 2016 может возникать ошибка с кодом 1603.

В журнале vmmsi.log в папке %ProgramData%\VMware\logs\ отображаются сообщения вида:

CustomAction InstallVstor2Driver.5ACA97E0_7C64_4970_A763_840E81DAAF0B returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 20:34:47: InstallFinalize. Return value 3.

Данная ошибка возникает, если ВМ использует EFI, и настроена загрузка с использованием Secure Boot. Отключить Secure Boot можно в свойствах ВМ: VM Options -> Boot Options -> Secure Boot.

После этого установка Composer должна пройти нормально.

Проблемы с подготовкой Linked Clone ВМ Windows 10 при использовании SysPrep

Недавно наткнулся на старый/новый баг Horizon 7.x в работе механизма кастомизации Linked Clone ВМ с гостевой ОС Windows 10 при использовании SysPrep.

В интерфейсе Horizon Administrator ВМ застревает в статусе Customizing. Сама ВМ в ходе кастомизации меняет имя, однако не вводится в целевой домен, оставаясь в рабочей группе. При этом создание Linked Clone ВМ через QuickPrep или Full Clone ВМ, а также Customization Specification из vCenter Server работают корректно.

Это происходит если в мастер образе, из которого создается ВМ, присутствует виртуальный CD-привод, которому назначена буква D. При первой загрузке новой ВМ Disposable диску назначается буква, которая изменяется при следующей загрузке. На данном диске располагается исполняемый файл для запуска кастомизации и вводу ОС в домен, однако из-за смены буквы диска путь к файлу изменяется.

Для решения данной проблемы можно воспользоваться одним из следующих методов.

Заранее изменить букву CD-привода в мастер образе, например, на F.

В настройках пула явно указать букву для Disposable диска (Disposable disk drive letter) и пересоздать Linked Clone ВМ.

Аналогичная проблема встречалась для Windows 7 еще в View 4.x, однако, я не припомню, чтобы сталкивался с ней в Horizon 6.x: https://kb.vmware.com/s/article/2006967

Немного о дизайне VDI. Часть 8. Подсистема хранения

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины

8.1 Масштабирование СХД

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

При использовании классических систем хранения существует два основных варианта планирования архитектуры.

Вариант первый – выбрать дисковый массив, который соответствует текущим требованиям по емкости и производительности. Это позволит снизить первоначальные затраты, однако может создать сложности при масштабировании решения. И если с дисковым пространством все относительно просто, требуется пространство – покупаете дополнительные диски/дисковые полки и подключаете к массиву, то с наращиванием производительности могут возникать проблемы. Рано или поздно производительность массива упрется в контроллеры или интерфейсы передачи данных. Это потребует либо апгрейда массива путем замены/добавления контроллеров (если такая возможность поддерживается), либо покупкой второго массива, что приведет к увеличению затрат на обслуживание.

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

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

8.2 Типы хранилищ

vSphere поддерживает следующие типы хранилищ:

• Блочные с файловой системой VMFS версии 3, 5 или 6 (локальные диски, тома, подключаемые по SAS, iSCSI, FC, FCoE).
• Файловые (NFS v3, NFS v4.1).
• Объектные (хранилище VMware VSAN, Dell EMC ScaleIO).
• Блочные или файловые с поддержкой Virtual Volumes (VVOL).

В таблице приведено сравнение типов хранилищ по ряду параметров. Некоторые модели СХД могут накладывать дополнительные ограничения, например, на максимальный размер LUN под хранилища, наличие или отсутствие поддержки VAAI, возможностям по репликации и т.д.

Функции	Блочное хранилище (VMFS)	Сетевой каталог (NFS)	Объектное хранилище (VSAN)
Среда передачи данных	SAS, Ethernet, Fibre Channel	Ethernet	Ethernet
Максимальный размер хранилища	64 ТБ	64 ТБ	64 ТБ
Максимальный размер VMDK	62 ТБ	62 ТБ	62 ТБ
Максимальное число хостов, которым может быть презентовано хранилище	64	n/a	64
Кол-во хранилищ на один хост	512	256	1
Кол-во ВМ на один хост	1024	1024	200
Включенных ВМ на одном хранилище	2048	n/a	6000
Поддержка составных хранилищ (extent)	Да	Нет	Нет
Поддержка многопутевого ввода-вывода (multipathing)	Да, для балансирования нагрузки и отказоустойчивости	Поддерживается в NFS v4 для обеспечения отказоустойчивости	Не применимо*
Поддержка SIOC	Да	Нет	Да
Поддержка Raw Device Mapping	Да	Нет	Да**
Поддержка VAAI	Да, зависит от массива	Да, зависит от массива	Не применимо
Поддержка VASA	Да, зависит от массива	Да, зависит от массива	Да
Поддержка VVOLS	Да	Да, кроме NFS v4.1	Нет
Поддержка шифрования VM Encryption	Да	Да	Да, также поддерживается VSAN Data at Rest Encryption
Поддержка Virtual Flash Read Cache (vFlash)	Да	Да	Нет
Поддержка Storage DRS	Да	Да, кроме NFS v4.1	Нет
Поддержка vSphere Replication	Да	Да	Да
Поддержка аппаратной репликации	Да	Да	Нет

* VSAN является распределенной системой хранения. Передача данных между узлами выполняется через VMKernel интерфейсы. Агрегация каналов средствами виртуального коммутатора и/или несколько VMKernel интерфейсов на одном хосте поддерживаются, но только для обеспечения отказоустойчивости.

** В VSAN 6.5 появилась функция Software iSCSI Target, позволяющая презентовать LUN, хранящиеся на VSAN клиентским устройствам по протоколу iSCSI, данные LUN могут быть презентованы как RDM диски виртуальным машинам. В vSAN 6.7 такие LUN могут использоваться в качестве общих дисков для кластеров Windows Server Failover Cluster.
При планировании хранения для VDI следует учитывать, что далеко не все технологии хранения, поддерживаемые в vSphere, поддерживаются и для Horizon. Так среди известных ограничений:

• Отсутствие поддержки vFlash для Automated Pool десктопов.
• Отсутствие поддержки Storage vMotion для Linked-Clone десктопов.
• Storage DRS кластеры поддерживаются только для пулов с Full-clone десктопами.
• Отсутствие поддержки vSphere Replication.

Пара слов о VVOLs. Как и в случае с VCAI, хранилище должно находится в списке совместимости для поддержки со стороны VMware. На текущий момент VVOLs поддерживаются только на хранилищах NetApp: https://www.vmware.com/resources/compatibility/pdf/vi_vvolh_guide.pdf

8.3 Сайзинг размера хранилищ

Несмотря на ограничение в максимальный размер хранилища VMFS в 64 ТБ на практике вы вряд ли будет использовать такие большие хранилища. Причин так делать может быть много:

• Ограничение на максимальные размер LUN со стороны СХД.
• Решение проблем с производительностью. На производительность блочного доступа большое влияние может оказывать глубина очереди команд (Queue Depth). Глубина очереди есть у накопителей, адаптеров ввода-вывода, портов массива, есть она и у LUN. При размещении большого количества ВМ на одном LUN, подключенного к большому числу хостов, вы можете упереться в размер очереди к логическому тому. Еще одна проблема с производительностью касается старых массивов, а также некоторых конфигураций на современных массивах. До появления VAAI ATS в vSphere 4.0 запуск ВМ, расширение thin диска, создание снапшота требовали временной блокировки всего LUN. При большом количестве ВМ подобные операции происходят достаточно часто, что может приводить к уменьшению производительности. Практически все современные массивы поддерживают VAAI, однако в некоторых случаях он может отключаться (например, при настройке репликации LUN на удаленный массив).
• Балансирование нагрузки на сеть хранения. При блочном доступе в один момент времени доступ к LUN со одного хоста осуществляется через один путь. Увеличив числов LUN, вы можете настроить доступ к ним, используя разные пути до массива.
• Использование разных LUN под хранение разных типов данных. Помимо очевидного преимущества в виде тиринга средствами Horizon, например, размещение linked-clone реплик на LUN на Flash накопителях, дельта дисков на LUN на SAS дисках, а persistent дисков на SATA, это также может пригодиться в случаях, когда вы планируете использовать репликацию средствами СХД для катастрофоустойчивых сценариев, чтобы, например, чтобы вынести файлы подкачки ВМ на отдельный LUN и не реплицировать его вместе с дисками виртуальных машин.
• Ограничения и рекомендации со стороны VMware. Согласно VMware Horizon 7 Sizing Limits and Recommendations на одном логическом томе рекомендуется размещать не более 500 ВМ.

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

В этом плане NAS хранилища гораздо площе, т.к. не имеют многих ограничений блочного доступа.

8.4 VMware vSAN

Одним из вариантов организации хранения ВМ для VDI является использование SDS на базе VMware vSAN.

К преимуществам vSAN можно отнести простоту развертывания, высокую производительности и экономию на внедрении за счет использования лицензий vSAN for Horizon Advanced, входящих в бандлы Horizon Advanced или Enterprise.
При выборе конфигурации сервера для vSAN можно приобрести предопределенные и протестированные вендорами конфигурации – vSAN Ready Nodes от различных производителей (HPE, Dell, Cisco, Huawei, Lenovo и другие), либо самостоятельно собирать серверы из совместимых компонентов (https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan).

К преимуществам vSAN (как и многих других программно-конфигурируемых хранилищ) относится возможность горизонтального масштабирования. vSAN поддерживает создание кластеров до 64 узлов для локального кластера или до 31 узла – для территориально распределенного (stretched) кластера.

vSAN можно запустить даже на одном сервере, т.н. bootstrap режим, который используется для установки и развертывания виртуальной инфраструктуры с нуля, когда нет работающего сервера vCenter. Однако следует помнить, что такая конфигурация официально не поддерживается VMware.

Минимальная поддерживая конфигурация - два хоста. Двухузловой кластер может использоваться в небольших инсталляциях в филиалах (Branch office). Важным требованием для развертывания двухузловой конфигурации является наличие узла-свидетеля на третьей площадке. Узел свидетель представляет собой виртуальную машину с установленным гипервизором ESXi, которые хранит witness компоненты и выступает арбитром для предотвращения возникновения split brain.

Если говорить о варианте развертывания без использования специализированных компонентов, то минимальное кол-во хостов – 3. В данной конфигурации каждый хост хранит данные ВМ и witness компоненты, которые автоматически распределяются по хостам. Для трехузлового кластера возможна настройка режима избыточного хранения – Fault to Tolerate = 1, при котором vSAN создает и поддерживает в синхронном состоянии две копии данных, так, что отказ одного любого компонента (жесткого диска, SSD, контроллера, либо хоста целиком) не приведет к потере данных.

Часто в официальных руководствах можно встретить рекомендацию по использованию в кластере vSAN не менее 4-х узлов. Откуда взялась данная рекомендация?

Это сделано для того, чтобы в случае отказа одного хоста, или переводе его в режим обслуживания, в кластере осталось 3 узла и была возможность восстановить избыточность данных. В случае 3-узлового кластера отказ одного хоста позволит сохранить доступ к данным (при FTT=1) однако двух оставшихся хостов будет недостаточно, чтобы хранить две копии данных и witness компоненты, такой кластер будет работать в деградировавшем режиме, пока третий хост не вернется в строй. По этой же причине VMware рекомендует резервировать в кластере часть дискового пространства (порядка 30%), которое будет использоваться для восстановления избыточности хранения в случае отказа хоста.

Еще одна причина для резервирования дискового пространства, когда на накопителе, хранящем данные (capacity device) остается менее 20% свободного пространства, vSAN запускает процедуру балансировки компонентов по другим хостам, что может создать дополнительную нагрузку на дисковую подсистему. Для этих целей VMware и рекомендует оставлять резерв порядка 30% для восстановления избыточности при отказе или переводе в режим обслуживания хоста в кластере.

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

• Накопитель для Performance Tier, который используется для кэширования операций ввода/вывода – это Flash накопитель с SATA, SAS или PCI-E (включая NVMe) интерфейсом. Для создания дисковой группы в ней обязательно должен присутствовать один (не более и не менее) Flash накопитель для Performance Tier.
• Накопители для Capacity Tier, которые используются для хранения данных ВМ. В качестве накопителя могут использоваться жесткие диски с интерфейсом SATA/SAS – такие конфигурации носят название гибридные (Hybrid), или Flash накопители – такие конфигурации называются All-Flash. В одной дисковой группе может присутствовать от 1 до 7 накопителей Capacity Tier. Смешивание hybrid и all-flash накопителей в рамках дисковой группы, хоста, или всего кластера не поддерживается. Единственное исключение – миграция с hybrid на all-flash конфигурации.

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

Следует помнить, что в vSAN отличается подход к работе с flash кэшем для гибридных и all-flash конфигураций.

Для гибридных конфигураций flash кэш делится в соотношении 70/30 на кэш для операций чтения и кэш для операций записи.

В all flash конфигурациях вся емкость Performance tier выделяется под кэш на запись. Чтение же выполняется напрямую с flash накопителей, относящихся к capacity tier.

При планировании конфигурации накопителей VSAN следует помнить, что максимальный размер кэша на запись для одной дисковой группы составляет 600 Гигабайт. Это не слишком критично для гибридных конфигураций, поскольку будет являться ограничением только при использовании SSD накопителей объемом более 2 ТБ под кэш. В all-flash конфигурациях накопители объемом более 600 ГБ на дисковую группу не будут полностью утилизироваться. С другой стороны, использование накопителей большей емкости позволит уменьшить износ и повысить ресурс SSD за счет использования технологий типа TRIM, обеспечивающих равномерную перезапись данных по всем ячейкам.

Управление настройками VSAN осуществляется гранулярно при помощи политик хранения (Storage Policies) для каждого объекта.
VSAN позволяет хранить следующие типы объектов

• Виртуальные диски (vmdk).
• Снапшоты виртуальных дисков (-delta.vmdk).
• Файл подкачки ВМ (vswp).
• Конфигурационный раздел, где хранится файл настроек (.vmx), файлы журналов (.log), файл настроек биоса (.nvram) и т.д.

Администратор может использовать политику по умолчанию или создать свою, чтобы задать уровень доступности данных, задать настройки резервирования дискового пространства и кэша, включить или отключить erasure coding или hardware checksum.
Перечень настроек VSAN:

Number of Failures To Tolerate - определяет кол-во копий объектов, которые размещаются на хранилище VSAN. Фактически, данная настройка определяет, какое число одновременных отказов в кластере объект может перенести с гарантированным сохранением доступа к данным. Копии объектов размещаются на разных хостах кластера, что позволяет переживать отказ любого аппаратного компонента сервера - жёсткого диска, flash накопителя, HBA адаптера, сервера целиком, а при использовании совместно с механизмом Fault Domain - стойки или всей площадки (при реализации распределенного кластера VSAN). Параметр может принимать значение от 0 до 3.

Минимальное значение FTT=0, означает, что на VSAN размещается всего одна копия данных без резервирования, что, эквивалентно JBOD или RAID-0 конфигурации дисковой подсистемы.
При FTT=1 в кластере хранятся две копии данных - аналог raid 10, что позволяет обеспечивать доступность при отказе любого одного компонента VSAN. Для данного режима также поддерживается режим erasure coding.

При FTT=2 в кластере хранятся три копии данных, что позволяет гарантированно пережить отказ одновременно любых двух компонентов. Для FTT=2 Vmware заявляет о доступности данных на уровне 99.9999%. Для данного режима такжеподдерживается erasure coding, о котором ниже.

Наконец, FTT=3 обеспечивает хранение четырёх копий данных и позволяет пережить отказ любых трёх компонентов.

В VSAN 6.6 данная политика были изменена из-за появления механизма Local Protection for Stretched Clusters. До этого при настройке Stretched VSAN Cluster поддерживался лишь режим FTT=1, при котором одна копия объекта хранилась на хостах на одной площадке, а вторая копия - на второй. Это означало, что при отказе площадки, доступной оставалась только одна копия данных для которой VSAN не восстанавливал избыточность и любой последующий отказ на второй площадке мог привести к потере данных.

В VSAN 6.6 появилась возможность дополнительно защищать данные на каждой из площадок.
Параметр Primary level of failures to tolerate определяет уровень защиты данных между площадками (хранить 1 или 2 копии).

Параметр Secondary level of failures to tolerate определяет уровень защиты данных внутри площадки и может принимать значение от 0 до 3.

В таблице приведена информация о требованиях к минимальному числу хостов в кластере и накладных расходах на хранения при разных уровнях PFTT и SFTT.

Режим	Мин. Кол-во хостов (локальный кластер PFTT=0)	Требование к дисковому пространству % (локальный кластер)	Мин. кол-во хостов (stretched кластер)	Требование к дисковому пространству % (stretched кластер PFTT=1)
SFTT=0	1	100%	2	200%
SFTT=1 (Mirroring)	2 + witness или 3	200%	4	400%
SFTT=1 + Erasure Coding	4	133%	8	266%
SFTT=2 (Mirroring)	5	300%	10	600%
SFTT=2 + Erasure Coding	6	150%	12	300%
SFTT=3 (Mirroring)	7	400%	14	800%

Number of Disk Stripes Per Object – управляет настройками страйпинга (размазыванием) копии объекта по накопителям Capacity Tier.

Параметр может принимать значение от 1 до 12. Параметр определяет – на каком минимальном числе накопителей Capacity Tier будет размещаться объект.
Каждая копия объекта состоит из одного или более компонентов, которые, в свою очередь, хранится на одном из накопителей capacity tier. Все компоненты, которые хранят данные объекта, объединяются в страйп (аналог RAID-0). Данные распределяеются по компонентам равномерно, блоками (chunk) размером по 1 МБ.

В каких случаях может происходить разделение копии объекта на несколько компонентов? Во-первых, размер компонента не может превышать 255 ГБ, поэтому если размер (копии) объекта больше 255 ГБ, то он разбивается на пропорциональное число компонентов. Например, виртуальный диск размером 1 ТБ, имеющий одну копию на VSAN, будет состоять минимум из 5 компонентов (без учета политики FTT).

Во-вторых, объект может разбиваться на компоненты, если на физическом накопителей capacity tier недостаточно свободного места. Например, если надо сохранить объект размером 100 ГБ, а на дисках осталось по чуть более 50 ГБ свободного пространства, то объект будет разделен на два компонента по 50 ГБ.

В-третьих, если для объекта задана настройка Number of Disk Stripes Per Object больше 1, то для соответствия требованиям политики VSAN разделит объект на нужное число компонентов. Следует помнить, что данная политика определяет только минимальное число дисков для размещения компонентов, поэтому вполне возможна ситуация, когда реальное число компонентов больше того, что указано в политике.

Object Space Reservation, по умолчанию все объекты на VSAN, кроме файла подкачки ВМ создаются тонкими, т.е. без резервирования дискового пространства (Space Reservation = 0) и растут по мере заполнения данными.

Данная политика позволяет регулировать какой объем дискового пространства будет резервироваться для объекта. В случае 100% резервации вы получите обычные thick диски, при 0% - тонкие, при любых значения между - что-то среднее.

Flash Read Cache Reservation - политика определяет какой объем кэш памяти на чтение резервируется для данного объекта. По умолчанию резко для объектов равен 0%, однако для обеспечения гарантированного уровня производительности вы можете зарезервировать часть пространства. Для вм horizon по умолчанию используется настройка которая для replica дисков резервирует 10% дискового пространства на чтение. Эта политика не применяется для all flash конфигураций.

Force Provisioning - политика, которая определяет - возможно ли создать объект на VSAN, в случае, когда не могут быть выполнены остальные политики, например, если недостаточно хостов или дискового пространства для создания нужного количества копий. Если политика не включена то объект не создастся, если не сможет удовлетворять всем требованиям политики.

Failure Tolerance Method - включает или отключает режим erasure coding для объекта для экономии дискового пространства. При отключенном EC VSAN хранит несколько полных копий объектов для обеспечения избыточности сетевой аналог raid1/10, при включенном ec для обеспечения избыточности используются хэш суммы, аналог raid5 для FTT=1 и raid6 - для FTT=2.

Использование EC позволяет существенно снизить требования к дисковому пространства. Цена за экономию - большая нагрузка на дисковую подсистему. Данная политика работает только для all-flash конфигураций VSAN.

Disable Object Checksum включает или отключает использование контрольных сумм для выявления и исправления одиночных ошибок при записи или чтении данных. Создает большую нагрузку на процессор.

IOPS limit for object – доступна только в редакции vSAN Enterprise. Ограничивает кол-во IOPS для объекта. В качестве размера блока для IO операции берется 32 КБ, таким образом, чтение или запись блока размером 64 КБ будет считаться уже за 2 IO операции.

Еще одна политика, которая не имеет прямого отношения к VSAN, но может использоваться совместно - это политики Storage I/O Control, позволяющие гарантировать определнный уровень производительности ввода вывода для виртуалтных машин, начиная с vSphere 6.6 настройки SIOC также задаются через механизм Storage Policies и позволяют задавать лимиты и резервирование IOPS.

SIOC может пригодиться как для решения проблем с boot или antivirus storm, когда несколько ВМ могут репетировать большое кол-во запросов вода вывода к дисковой подсистеме, так и для приоритизации операций ввода-вывода для ВМ в целях обеспечения лучшего уровня производительности для привилегированных пользователей.

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

Продолжение доступно по ссылкам:

Часть 9. Сетевая подсистема

Часть 10. Организация подключения и безопасность
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление

Дополнительные материалы:

1. VMware vSAN Design and Sizing Guide: https://storagehub.vmware.com/export_to_pdf/vmware-r-virtual-san-tm-design-and-sizing-guide
2. VMware Horizon 6 Storage Considerations (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-view-mirage-workspace-portal-app-volumes-storage.pdf).
3. VMware vSphere Storage DRS Interoperability (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vsphere-storage-drs-interoperability-white-paper.pdf).

Немного о дизайне VDI. Часть 5. Подсистема виртуализации

Продолжение цикла статей о дизайне 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, можно смело говорить о том, что виртуальный апплайнс является более предпочтительным решением по следующим причинам:

• Возможность использования встроенной БД (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.

Настройки 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 может потребоваться в следующих случаях:

• Необходимо объединить несколько 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 правилам вы можете привязать группу ВМ к хостам на одной из площадок, что позволит локализовать ввод-вывод с дискового хранилища и меньше загружать межсайтовое соединение.

Продолжение доступно по ссылкам:

Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины
Часть 8. Подсистема хранения
Часть 9. Сетевая подсистема

Часть 10. Организация подключения и безопасность
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление