Октябрь прошлого года отличился значимым и, без преувеличения, долгожданным событием: 11 октября VMware отчиталась о выходе в свет новой мажорной версии нашей vSphere. Еще больше сотрудничества с облачными технологиями, простая интеграция с Kubernetes, некоторые инновации для DevOps, рост оперативной эффективности и производительности рабочих нагрузок. В целом, новинок очень и очень много: на основных моментах остановимся ниже, как и на том, где достать актуальный билд, а всего, что касается подготовки к инсталляции, апгрейду и прочего, коснемся в соответствующих посвященных ей гайдах.
Актуальный билд
На данный момент никаких патчей к ESXi vSphere 8.0 еще не выходило, поэтому рабочим является билд 20513097:
а вот для vCenter Server предлагается уже версия 8.0.0а — 20519528:
Это для лицензий класса Standard, а другие образы можно найти по ссылке. Там же, кстати, и новые VMware Tools 12.1.5, а также другие связанные компоненты, но им попробуем в будущем посвятить отдельные материалы.
Подробности обновления
Прежде всего следует сказать о коренном изменении самого подхода к концепции новых релизов vSphere: эта модель IA/GA (Начальная доступность / Общая доступность) с этого момента лучше работает с согласованием выпусков облачных служб, являющихся составляющими vSphere+, а также дает время клиенту получить всю информацию о новой версии и подготовиться к ее дальнейшему использованию. На практике это будет выглядеть, как вначале поставка продуктива с отметкой IA (полностью сертифицирована, готовая к развертыванию и качественная) – этот период запланирован на 4-6 недель. За это время собирается вся информация о практическом использовании продукта на местах, отзывы клиентов, производятся улучшения при необходимости. Когда отметка версии сменится с IA на GA, это будет означать, что продукт приобрел достаточно широкого распространения и с этого момента обладает дополнительной гарантией качества. Благодаря этому более нет нужды ожидать обычного, едва ли не полугодичного масштабного обновления – продукт будет динамически улучшаться в процессе.
Это было общее замечание от производителя, чтобы мы теперь не пугались незнакомых букв в обозначениях продуктов. А среди прочих ключевых улучшений следует отметить такие.
vSphere Distributed Services Engine
- vSphere Distributed Services Engine. Механизм распределенных сервисов vSphere ранее назывался Project Monterey. Его обновление предлагает мощность блоков обработки данных (DPU) для ускоренной обработки данных на уровне hardware с целью улучшения производительности инфраструктуры, ее безопасности и упрощения управления жизненным циклом DPU. Дополнительный инстанс ESXi устанавливается непосредственно на блок обработки данных, что позволяет разгрузить службы ESXi на DPU. Поддержка новых инсталляций происходит с помощью NSX, а жизненный цикл vSphere Distributed Services Engine контролирует vSphere Lifecycle Manager. Когда происходит исправление хоста с инсталляцией DPU ESXi, версия DPU ESXi всегда исправляется согласно родительского хоста и сохраняется в режиме блокировки версии:
- Выход Data Processing Unit. Блоки обработки данных сегодня существуют на аппаратном уровне, также, как и устройства PCIe, вроде NIC или GPU. Сейчас службы сетей, хранилищ и управления хостами работают на инстансе ESXi, который виртуализирует уровень вычислений x86:
- Простая конфигурация для разгрузки сети. С помощью vSphere Distributed Switch 8.0 и NSX сетевые службы разгружаются на DPU, что позволяет нарастить производительность сети без перегрузок x86 CPU, улучшить видимость сетевого трафика и безопасности, изоляцию и защиту, которых ждем от NSX:
vSphere с Tanzu
- vSphere с Tanzu. Tanzu Kubernetes Grid на vSphere 8 консолидирует предложения Tanzu Kubernetes в единой унифицированной среде исполнения Kubernetes от VMware. Зоны доступности рабочей нагрузки (Workload Availability Zones) используются для изоляции рабочей нагрузки в кластерах vSphere. Кластеры супервайзера и кластеры Tanzu Kubernetes можно разворачивать в разных зонах для роста доступности кластеров, убедившись, что ноды не используют одинаковые кластеры vSphere. ClusterClass – это способ декларативно указать конфигурацию кластера с помощью проекта ClusterAPI с открытым кодом. Основные образы PhotonOS и Ubuntu можно настроить и сохранить в библиотеке контента для использования в кластерах Tanzu Kubernetes. Интеграция Pinniped доступна для кластеров супервайзера и кластеров Tanzu Kubernetes. Pinniped поддерживает LDAP и OIDC федеративную аутентификацию. Можно определить поставщиков данных идентификации, что используются для аутентификации пользователей в кластерах супервайзера и кластерах Tanzu Kubernetes.
- Улучшение стойкости рабочих нагрузок в современных приложениях. Зоны доступности рабочей нагрузки (Workload Availability Zone) позволяют кластерам супервайзера и кластерам Tanzu Kubernetes охватывать кластеры vSphere для увеличения доступности. Пространства имен (Namespace) vSphere охватывают зоны доступности рабочей нагрузки для поддержки развертывания кластеров Tanzu Kubernetes, развернутых для увеличения доступности в зонах:
Для доступности необходимы три Workload Availability Zone. При активации Workload Management предоставляется выбор между развертыванием в зонах доступности рабочей нагрузки и развертыванием в одном кластере. У vSphere 8 GA Workload Availability Zone имеет соотношение 1:1 с кластером vSphere.
- ClusterClass. ClusterClass предоставляет декларативный способ определения конфигурации кластера Tanzu Kubernetes, а также пакетов, установленных по умолчанию. Команда платформы может определить инфраструктурные пакеты, которые должны быть установлены во время создания кластера. Они могут включать в себя провайдеров сетей, механизмы аутентификации и сбора метрик. Спецификация кластера ссылается на ClusterClass:
ClusterClass – это open-source спецификация, являющаяся частью проекта ClusterAPI. ClusterAPI определяет декларативный способ управления жизненным циклом кластеров Kubernetes через существующий кластер управления Kubernetes. В vSphere with Tanzu этот кластер управления является кластером супервайзера.
- Гибкое управление пакетами. После развертывания кластера пользователи Developers или DevOps могут добавлять дополнительные пакеты с Tanzu Standard Package Repository. Эти пакеты должны включать Contour для входа в кластер, управление сертификатами, создание журналов логов, возможность наблюдения при помощи Prometheus или Grafana, либо внешнего DNS. Они управляются как аддоны через интерфейс Tanzu CLI:
- Использование собственного провайдера идентификации. В vSphere 7 аутентификация происходит через интеграцию с vCenter Single Sign-On. Эту практику можно продолжать и в vSphere 8, но с этого момента есть и альтернатива. Используя интеграцию Pinniped, кластер супервайзера и кластеры Tanzu Kubernetes могут иметь прямой доступ OIDC к провайдеру идентификационной информации (IDP), не полагаясь на vCenter Single Sign-On. Поды Pinniped автоматически разворачиваются в кластере супервайзера и кластерах Tanzu Kubernetes для облегчения интеграции:
А именно:
- Пользователь DevOps использует логин Tanzu CLI для аутентификации в Supervisor и/или TKC;
- Интеграция Pinniped объединяется с IDP;
- IDP возвращает ссылку для входа или окно;
- Пользователь DevOps вводит учетные данные IDP;
- Успешная аутентификация в IDP возвращается в Pinniped;
- Tanzu CLI создает файл kubeconfig, необходимый для доступа в Supervisor и/или TKC.
Управление жизненным циклом
- Lifecycle Management. vSphere 8 представляет поддержку DPU для vSphere Lifecycle Manager, чтобы автоматически исправлять инсталляцию ESXi на DPU в пошаговом режиме согласно версии хоста ESXi. Инсценирование полезных нагрузок апдейта/апгрейда, параллельное исправление и поддержка standalone хоста комбинируются для обеспечения паритета функций vLCM с Update Manager. Отдельными хостами можно управлять при помощи vSphere Lifecycle Manager через API. VMware Compatibility Guide детализирует, какие функции vLCM может поддерживать Hardware Support Manager. Технический предварительный просмотр профилей конфигурации vSphere представляет следующее поколение управления конфигурацией кластера как будущую замену профилей хоста.
- Ускорение исправления при помощи Stage Cluster Image Updates. vSphere Lifecycle Manager может передать обновление полезных нагрузок на хосты перед исправлением. Это может происходить не в режиме maintenance. Полезную нагрузку встроенного программного обеспечения также можно интегрировать с помощью поддерживаемого Hardware Support Manager:
- Ускоренное исправление кластера. vSphere Lifecycle Manager может исправлять несколько хостов параллельно, что значительно экономит время исправления всего кластера. Хосты в режиме техобслуживания могут исправляться параллельно (и только в таком состоянии!). Администратор vSphere может выбирать исправление всех хостов в режиме maintenance, или определить количество параллельных исправлений для выполнения в определенное время:
- Управление конфигурацией в масштабе. vSphere 8 представляет перевью профилей конфигурации vSphere (vSphere Configuration Profiles) нового поколения управления конфигурацией кластера:
Желаемая конфигурация определяется в объекте кластера и применяется ко всем хостам кластера. Все они обладают согласованной конфигурацией. Отслеживается девиация конфигурации, о чем тут же сообщается, благодаря чему администратор vSphere может исправить это отклонение. Напоминаем, vSphere Configuration Profiles сейчас еще активно разрабатываются, поэтому в следующих релизах продукта их поддержка будет расширена и улучшена. Не волнуйтесь, Host Profiles продолжают поддерживаться vSphere 8.
- Улучшенное восстановление vCenter. vCenter согласовывает состояние кластера после восстановления из бэкапа. Хосты ESXi в кластере содержат распределенное хранилище ключей состояния кластера:
Распределенное хранилище ключей является источником соответствия для состояния кластера. Если vCenter восстановлено из резервной копии, он согласует состояние и конфигурацию кластера с распределенным хранилищем ключей. В vSphere 8 GA членство в хост-кластере согласовано с дополнительной конфигурацией и состоянием, запланированным для поддержки в будущих релизах.
AI/ML
- Унифицированное управление аппаратными ускорителями AI/ML. Группы устройств (Device Groups) упрощают работу виртуальных машин с дополнительными аппаратными устройствами в vSphere 8. Устройства NIC и GPU поддерживают в vSphere 8 GA. Нужны совместимые драйверы устройств от вендоров. NVIDIA® будет первым партнером, который поддерживает Device Groups с ожидаемыми совместимыми драйверами:
Группы устройств могут состоять из двух или более аппаратных устройств с общим коммутатором PCIe, или устройств, которые напрямую объединяются между собой. Device Groups определяются на аппаратном уровне и представлены в vSphere как единый юнит, который представляет группу.
- Упрощенное употребление аппаратного оборудования с Device Groups. Группы устройств добавляются к виртуальным машинам при помощи существующих рабочих процессов «Add New PCI Device». vSphere DRS и vSphere HA проинформированы о группах устройств и размещают ВМ согласно им:
- Новое поколение виртуальных аппаратных устройств. Device Virtualization Extensions строится на Dynamic DirectPath I/O и представляет новый фреймворк и API для вендоров для создания виртуальных устройств с аппаратной поддержкой. Расширение виртуализации устройств обеспечивает большую поддержку функций виртуализации, в частности миграции наживую с vSphere vMotion, приостановку и восстановление ВМ, а также поддержку снэпшотов диска и памяти:
На хостах ESXi должен быть установлен совместимый драйвер с соответствующим драйвером гостевой ОС для эквивалента виртуального устройства. Виртуальную машину, которая использует виртуальное устройство расширения виртуализации устройства, можно перенести, используя vSphere vMotion, на другой хост, что поддерживает то же виртуальное устройство.
Гостевая ОС и рабочие нагрузки
- Версия 20 виртуального Hardware. Виртуальное оборудование версии 20 сейчас является самым свежим. Его тема предлагает инновации виртуального аппаратного обеспечения, улучшает гостевые сервисы для приложений, повышает производительность и масштабированость для определенных рабочих нагрузок.
- Масштабированное развертывание Windows 11. Речь о предоставлении политики TPM. Windows 11 требует устройства vTPM в виртуальных машинах. Клонирование ВМ с виртуальной машиной vTPM может нести угрозу безопасности, так как происходит клонирование секретов TPM:
В vSphere 8 устройства vTPM можно автоматически заменять во время операций клонирования или развертывания. Это позволяет придерживаться best practices в отношении того, что каждая виртуальная машина содержит уникальное устройство TPM, и улучшает поддержку vSphere для масштабированного развертывания Windows 11. vSphere 8.0 также содержит расширенную настройку vpxd.clone.tpmProvisionPolicy для создания дефолтного поведения клона для vTPM, которые замещаются.
- Уменьшение сбоев с помощью подготовки приложений для миграции. Некоторые приложения не выдерживают «оглушения», связанные с vSphere vMotion. Эти приложения можно написать с учетом миграции, чтобы улучшить их взаимодействие с vSphere vMotion. Приложения могут подготовиться к событию миграции или путем аккуратной остановки служб, или применением отказа на случай кластеризированного приложения. Приложение может отложить начало миграции до настроенного времени ожидания, но не может отклонить или предотвратить миграцию. Варианты использования включают:
- чувствительные ко времени приложения,
- VoIP приложения,
- кластеризированные приложения.
- Максимизация производительности для чувствительных к задержкам рабочих нагрузок. Новые рабочие нагрузки Telco требуют усиленной поддержки чувствительных к задержке приложений. Высокая чувствительность к задержке (High Latency Sensitivity) с Hyper-threading разработана для поддержки таких нагрузок и обеспечивает лучшую производительность. vCPU виртуальной машины внесен в расписание на одном физическом ядре с гиперпотоковым процессором:
Для High Latency Sensitivity с гиперпотоковостью необходимо аппаратное обеспечение ВМ версии 20, и ее можно задать в расширенных настройках виртуальной машины:
- Упрощение виртуальной конфигурации NUMA. vSphere 8 и аппаратное обеспечение версии 20 позволяют пользоваться клиентом vSphere для настройки топологии vNUMA для виртуальных машин:
Блок новой топологии CPU отображается на вкладке ВМ итоговой, где видим текущую топологию:
- vSphere на API и обмен данными между гостями. vSphere DataSets обеспечивает простой способ распределения небольших, не часто изменяемых данных между уровнем управления vSphere и гостевой операционной системой, запущенной на виртуальной машине с проинсталлированными VMware Tools. Варианты использования могут включать статус развертывания Guest, конфигурацию его агента или управление его инвентарем. vSphere DataSets существуют вместе с объектом ВМ и будут перемещаться с ней, ежели такое будет происходить, даже если речь об инстансах vCenter Server:
Управление ресурсами
- Улучшена производительность DRS. В vSphere 7.0U3 появилась новая функция vSphere Memory Monitoring and Remediation (vMMR), которая помогает в преодолении нужды в мониторинге, предоставляя текущую статистику как на уровне ВМ (пропускная способность), так и на уровне хоста (пропускная способность, пропуски). Она оповещает по умолчанию и можно настраивать специальные оповещения на основе рабочих нагрузок, запущенных на ВМ. Собирает данные и дает обзор статистических данных о производительности, что помогает обнаружить уменьшение рабочей нагрузки приложения через Memory Mode. В vSphere 8 производительность DRS может быть значительно улучшена при наличии PMEM путем использования статистики памяти, что помогает принимать оптимальные решения по размещению ВМ без влияния на производительность и употребление ресурсов:
- Мониторинг энергопотребления. vSphere Green Metrics представляет новые метрики употребления энергии для хостов и виртуальных машин. Они помогают администраторам контролировать энергопотрбление инфраструктуры vSphere и определять, является ли она энергоэффективной, с точки зрения каналов, которыми пользуется для своего питания ЦОД. Эти метрики отслеживают:
- capacity.usageSystem – энергопотребление деятельности системы хоста, сколько энергии потребляет хост, независимо от ВМ;
- capacity.usageIdle – энергопотребление холостой активности, сколько энергии потребляет хост в состоянии покоя, кроме включенного;
- capacity.usageVm – энергопотребление хоста через нагрузку ВМ, сколько энергии хост использует для выполнения рабочих нагрузок ВМ:
Безопасность и соответствие
- В vSphere 8 применены дополнительные меры для безопасности продукта по умолчанию. А именно:
Предотвращение исполнения ненадежных двоичных файлов. ESXi 8.0 по умолчанию включит опцию execInstalledOnly (по файлам, которые не установлены через VIB).
Автоматический таймаут SSH. Доступ по SSH дезактивируется по умолчанию, а в vSphere 8 теперь есть таймаут по умолчанию, чтобы предотвратить зависание неактивных сеансов SSH.
Демоны изолированной программной среды. Демоны и процессы ESXi 8.0 работают в собственном домене изолированной программной среды («песочнице»), где для работы доступны лишь минимально необходимые разрешения.
Хранилище
- NVMeoF vVols. Актуальна новая спецификация vVols, фреймворк VASA/VC — VASA 4.0/vVols 3.0. Среди преимуществ NVMeoF vVols – настройки. Во время развертывания при регистрации VASA базовая настройка проходит в фоновом режиме, а пользователю необходимо лишь создать хранилище данных. Все виртуальные конечные точки протокола (vPE) и соединения обрабатываются VASA, что упрощает настройку.
- Улучшение NVMeoF. Поддержка 256 пространств имен и 2К путей с NVMe-TCP и NVMe-FC. NVMe over Fabrics (NVMeoF) будет иметь более высокую пропускную VMDK способность и более высокую производительность, сравнительно с SCSI или NFS подключением. Расширение поддержки команд резервирования NVMe для включения таких решений, как WSFC, позволит клиентам использовать емкость кластеризированного VMDK для использования с Microsoft WSFC с хранилищами NVMeoF. Пока только FC.
Также внедрено автоматическое выявление поддержки NVMe Discovery в ESXi. ESXi будет использовать службу mDNS/DNS-SD для получения IP-адреса и номера порта активных служб выявления NVMe-oF в сети. ESXi посылает многоадресный запрос DNS (mDNS), требуя информацию от субъектов, которые предоставляют (NVMe) службу выявления (DNS-SD). Если такая сущность активна в сети, она ответит (одноадресно) хосту с запрашиваемой информацией.
- vVols. Произошло улучшение VM Swap благодаря ускорению включения/выключения питания, росту производительности vMotion, в результате изменений в том, как дается/уничтожается своп vVols. Кроме того, возможности настройки vVol помогают оставаться на связи, сокращая время запросов во время поиска информации ВМ. Также стоит отметить кеширование разных атрибутов vVol, таких как название, размер. config-vvol сохраняет домашние данные ВМ. (vmx, nvrams, логи) и, обычно, доступны только во время загрузки или изменения. Ранее использовалось то, что называется «ленивой отвязкой», отвязывая config-vvol, когда он не использовался. Но иногда потом некоторые приложения периодически обращаются к config-vvol и требуют новой операции привязки. С этого момента сохранение привязки уменьшает задержку во время доступа к домашним данным ВМ.
- Улучшение Unmap Space Reclamation. Минимальная скорость возвращения снизилась до 10 Мбит/с. Начиная с vSphere 6.7, добавленная функция, которая позволяет настраивать частоту отображения на уровне хранилища данных. С помощью этого усовершенствования клиенты могут изменять скорость отображения в соответствии с возможностями их массива и рекомендациями вендора. Более высокий уровень unmap способствовал многим вендорам массивов, которые быстро освобождали пространство. Но даже с самой маленькой скоростью unmap в 25 МБ/с, она могла быть разрушительной, когда несколько хостов посылали команды unmap одновременно. Сбой мог вырасти при масштабировании количества хостов в каждом хранилище данных. Пример потенциальной перегрузки: 25 МБ/с * 100 хранилищ данных * 40 хостов ~ 104 ГБ/с. Теперь же эта проблема исчезла:
Кроме того стоит отметить создание выделенной очереди планирования unmap (Unmap Scheduling Queue). Она позволяет отделять высокоприоритетные метаданные VMFS и обслуживать их с отдельных schedQueues, чтобы предотвратить их истощение из-за команды unmap.
- Контейнерное хранилище CNS/CSI. По VMFS и vSANDirect Disk Provisioning Storage Policy теперь можно выбирать EZT, LZT или Thin предоставление через политику для CNS/Tanzu. Цель состоит в том, чтобы дать возможность SPBM поддерживать создание/модификацию правил политики хранения, чтобы указать параметры распределения томов. Это также облегчит проверку соответствия в SPBM в отношении правил распределения томов в политике хранения. Для виртуальных дисков поддерживаются такие операции: создания, перенастройки, клонирования и перемещения. Для FCD поддерживаются такие операции: создания, обновления политики хранения, клонирования и перемещения:
- Улучшение NFS. С целью повышения устойчивости хранилищ в vSphere 8 добавлено усовершенствование NFS, которое состоит в росте стойкости, благодаря службам, проверкам и подтверждению разрешений. Например, предоставление возможности подключить NFS еще раз в случае ошибки, а также проверка монтирования NFS.
Другое
- Взаимная аутентификация смарт-карт переехала на порт 3128.
- VMDK только для чтения нельзя зарегистрировать как FCD.
Функции, компоненты, продукты и прочее, признанные устаревшими или такими, что не поддерживаются
Baseline lifecycle management (ранее известный как vSphere Update Manager) признан устаревшим (еще поддерживается, но в следующих релизах его окончательно отбросят).
Окончание поддержки Trusted Platform Module (TPM) 1.2. ESXi 8.0 покажет предупреждение во время установки или обновления, если наличествует устройство TPM 1.2. При этом инсталляция или обновление не будут запрещены.
Только TLS 1.2. vSphere 8 не поддерживает TLS 1.0 и TLS 1.1. В «семерке» они считались выключенными, а теперь вовсе удалены прочь.
Далее кратко перечислим, что еще утратило, или гарантированно вот-вот утратит актуальность:
- N-Port ID Virtualization (NPIV)
- Integrated Windows Authentication (IWA)
- Common Information Model (CIM)
- Patch Manager API
- Локальные плагины
- Поддержка 32-битних миров пользователей
- VMKAPI v2.4
- Драйвер nmlx4_en
- Незащищенные шифры (сертификаты X.509 с алгоритмом подписи SHA-1 и другие)
- Адаптеры ПО FCoE
- Поддержка устройств ввода/вывода, которые используются драйверами nmlx4_en и lpfc.
Совместимость
Поддерживаются виртуальные машины, совместимые с ESXi 3.0 и более поздними (версия аппаратного обеспечения — 4). Все остальные считаются такими, что утратили поддержку.
По операционным системам совместимость следует проверять, как всегда, в VMware Compatibility Guide. Теми, что считаются устаревшими или неиспользуемыми, являются системы:
- Windows Vista, Windows 2003 / R2, Windows XP
- Oracle Linux 5.x
- Oracle Linux 4.9
- CentOS 5.x
- Asianux 3.0
- SUSE Linux Enterprise Server 9 SP4
- SUSE Linux Enterprise Server 10 SP4
- SUSE Linux Enterprise Desktop 12
- Ubuntu 12.04, 18.10, 19.04 и 19.10
- Debian 7.x и 8.x
- Debian 6.0
- Photon OS 1.0
- Flatcar Container Linux non-LTS релизы
- Все релизы OS X и macOS
- FreeBSD 9.x и 10.x
- FreeBSD 7.x и 8.x.
- Solaris 10.x
- Все релизы eComStation
- Все релизы SCO
- Все релизы CoreOS.
Проверку совместимости устройств и аппаратного обеспечения вендор рекомендует, опять-таки, проверять в VMware Compatibility Guide, а разных версий ESXi и vCenter Server – в Product Interoperability Matrix. Всех вопросов совместимости в подробностях коснемся в запланированных будущих гайдах по инсталляции продукта и его обновления до самой свежей версии.
Локализация
vSphere 8.0 доступна на:
- английском,
- итальянском,
- французском,
- немецком,
- испанском,
- японском,
- корейском,
- упрощенном китайском,
- традиционном китайском.