Весной этого года компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Основные улучшения знает большинство администраторов, так как об этом писали достаточно подробно. Но есть и несколько небольших, но важных изменений, знать про которые было бы очень полезно. Давайте на них посмотрим:
1. Переезд Advanced Settings сервера VMware vCenter в configstore
Многие администраторы VMware vSphere 7 после выхода обновления Update 2 этой платформы были удивлены, что многие настройки пропали из основного конфигурационного файла esx.conf. Но, оказывается, не только оттуда. Например, раньше глобальные настройки FDM (он же HA - High Availability) хранились в файле /etc/opt/vmwware/fdm/fdm.cfg. Теперь их там тоже нет!
Все дело в том, что конфигурационные настройки из разных файлов переехали во внутреннее хранилище ConfigStore, работать с которым нужно с помощью утилиты командной строки configstorecli. Изменять настройки нужно путем импорта и экспорта json-файлов конфигурации. Например, вот табличка с изменениями параметров Advanced Settings в FDM после их переезда в configstore:
Например, выведем настройки FDM/HA в JSON-файл командой:
configstorecli config current get -g cluster -c ha -k fdm > test.json
Там можно поменять или добавить расширенные параметры, после чего залить получившийся JSON-файл конфигурации обратно в configstore:
configstorecli config current set -g cluster -c ha -k fdm -infile test.json
Пока информации о работе с этой утилитой очень мало, но скоро будут появляться заметки от сотрудников VMware о ее использовании. Вот так, например, можно экспортировать в JSON настройки виртуального коммутатора (эти настройки переехали из файла esx.conf):
configstorecli config current get -c esx -g network_vss -k switches > vswitch.json
2. Улучшения для нагрузок машинного обучения с картами NVIDIA
После выхода VMware vSphere 7 Update 2 появилось много интересных статей о разного рода улучшениях, на фоне которых как-то потерялись нововведения, касающиеся работы с большими нагрузками машинного обучения на базе карт NVIDIA, которые были сделаны в обновлении платформы.
А сделано тут было 3 важных вещи:
Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.
Оптимизации включают в себя не только средства разработки, но и развертывания и масштабирования, которые теперь удобно делать на виртуальной платформе. Все это привело к тому, что накладные расходы на виртуализацию у задач машинного обучения для карточек NVIDIA практически отсутствуют:
Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere
Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.
Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.
Теперь же для режима Multi-Instance GPU (MIG) виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).
В таком режиме виртуальные машины оказываются полностью изолированы на уровне аппаратного обеспечения. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.
Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA
Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.
Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.
3. Техника Precision Time for Windows
Не все знают, что в vSphere 7 Update 2 появилась поддержка нового механизма Precision Time for Windows. Раньше для почти всех задач в виртуальных машинах использовалась связка NTP+Active Directory, которая работает отлично в подавляющем большинстве случаев. NTP обеспечивает точность на уровне миллисекунд, а если нужна какая-то большая точность (например, финансовые приложения), то тут можно использовать специальное оборудование с поддержкой PTP (Precision Time Protocol).
VMware решила сделать еще одно улучшение для пользователей, которым требуется повышенная чувствительность служб точного времени. Теперь в vSphere 7 Update 2 есть поддержка Precision Time for Windows - механизма, который улучшает точность синхронизации времени в ОС Windows.
Сервис Windows Time Service (W32Time) - это служба, которая опирается на NTP и предоставляет клиентам ОС информацию о точном времени. В основном она нужна для синхронизации времени между хостами в Active Directory, но уже вышла за рамки этих задач и может быть использована приложениями. Архитектура W32Time построена на базе плагинов, что означает, что DLL-библиотека может быть зарегистрирована как провайдер служб точного времени. Это могут быть как чисто программные решения, так и комплексные системы со специальным оборудованием с поддержкой PTP-протокола.
API-интерфейсы для разработки таких плагинов находятся в открытом доступе, каждый может написать свой собственный. Вот и VMware разработала свой VMware Time Provider (vmwTimeProvider), который поставляется вместе с VMware Tools для ВМ на базе Windows. Он получает время от виртуального устройства Precision Clock (оно появилось еще в vSphere 7.0) и передает его на сторону W32Time по закрытому и быстрому каналу (на базе технологии паравиртуализации), минуя сетевой стек.
vmwTimeProvider - это плагин, работающий в пространстве user-space. По идее такое устройство требовало бы собственный драйвер, но у VMware есть собственный паравиртуализованный интерфейс, который использует преимущества технологии Memory-mapped I/O (MMIO), оптимизированной под операции чтения.
Устройство Precision Clock получает время от ядра гипервизора (VMkernel), одним из источников является устройство HyperClock, поставляющее в ядро системное время. Таким образом, если вы настроите VMkernel и HyperClock на получение времени через Precision Time Protocol (PTP), то устройство Precision Clock будет передавать его в виртуальные машины с большой точностью.
Ну и в завершение надо отметить, что vmwTimeProvider не выбран по умолчанию при установке, так как он не нужен системам без специальных требований к службам времени.
4. Служба vSphere Virtual Machine Service (VM Service) в vSphere 7 Update 2a
Эта возможность появилась в обновлении Update 2a, но заслуживает внимания пользователей администраторов, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu.
Служба Sphere Virtual Machine Service (она же VM Service) дает разработчикам и администраторам, работающим со средой контейнеров Kubernetes, возможности по развертыванию виртуальных машин.
Это позволяет командам DevOps управлять инфраструктурой виртуальных машин и контейнеров через стандартные Kubernetes API, обеспечивая единый процесс по развертыванию новых служб и доступности инфраструктуры.
Служба VM Service дополняет ранее анонсированные службы Network Service и Storage Service, которые дают возможности по управлению через API сетью и хранилищем, соответственно, в среде vSphere with Tanzu. Вот хороший обзор новых функций VM Service:
Со стороны vSphere служба встроена напрямую в vCenter, она позволяет управлять образами ВМ (VM Images / Content Libraries) и классами ВМ (VM Classes / VM sizing).
Со стороны Kubernetes компонент называется VM Operator, он создает и обслуживает ресурсы Kubernetes Custom Resources (CRs/CRDs), а также общается с компонентом на стороне vSphere.
VM Service даст компаниям следующие преимущества:
Разработчикам в среде Kubernetes больше не требуется создавать заявки на создание ВМ для администраторов.
Администратор может преконфигурировать заданные классы ВМ, доступные разработчикам, задав лимиты их ресурсов, а также обеспечив защиту и изоляцию от продуктивного окружения.
Некоторые приложения в контейнерах, например, могут использовать базу данных, размещенную в ВМ. В этом случае разработчик сможет создать спецификацию такого сервиса в YAML и обслуживать такую структуру самостоятельно.
Open Source природа сервиса позволит дорабатывать и создавать новые службы с учетом потребностей больших команд. Репозиторий компонента VM Operator находится тут.
5. Техника Suspend-to-Memory при обновлении хостов VMware ESXi
Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.
Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).
Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.
Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:
По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.
При использовании такого типа обновления vLCM будет пытаться сделать Suspend виртуальных машин в память, а если этого не получится (например, недостаточно памяти), то он просто не будет переходить в режим обслуживания.
Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.
Ну и вот небольшое демо того, как это работает:
А вы знали обо всех этих новых возможностях VMware vSphere 7 Update 2?