В современных гибридных и частных облаках большое количество данных о состоянии систем поступает из самых разных источников: систем резервного копирования, хранилищ данных, SaaS-платформ и внешних сервисов. Однако интеграция этих данных в единую платформу мониторинга часто оказывается сложной задачей. Для решения этой проблемы в составе VMware Cloud Foundation был представлен инструмент Management Pack Builder (MPB), предназначенный для расширения наблюдаемости и видимости инфраструктуры. О его бета-версии мы писали еще в 2022 году, но сейчас он уже полноценно доступен в составе VCF.

Что такое Management Pack Builder

Management Pack Builder (MPB) — это функциональность VMware Cloud Foundation, представляющая собой no-code-решение для создания пакетов управления (management packs), которые позволяют импортировать данные наблюдения из внешних источников в систему мониторинга VCF Operations. MPB выполняет роль промежуточного слоя, преобразуя данные, полученные через REST API сторонних систем, в объекты, метрики, свойства и события, понятные и используемые в экосистеме VMware Cloud Foundation.

С помощью Management Pack Builder можно:

• Подключаться к REST API внешних систем
• Создавать собственные типы объектов мониторинга
• Сопоставлять данные API с метриками и свойствами в VCF Operations
• Формировать повторно используемые пакеты управления для развертывания в разных средах

Какие задачи решает Management Pack Builder

Заполнение пробелов в мониторинге

Во многих организациях используются системы, для которых не существует готовых адаптеров мониторинга VMware. MPB позволяет интегрировать такие источники данных и устранить «слепые зоны» в наблюдаемости инфраструктуры.

Упрощение интеграции сторонних решений

Традиционная разработка адаптеров требует значительных затрат времени и ресурсов. Management Pack Builder позволяет создавать интеграции без написания кода, что существенно ускоряет процесс и снижает операционные издержки.

Централизация данных наблюдаемости

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

Масштабируемость и повторное использование

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

Работа с нестандартными API

Management Pack Builder поддерживает гибкое сопоставление данных и может использоваться даже в случаях, когда REST API внешних систем не полностью соответствует стандартным спецификациям.

Преимущества использования MPB

Использование Management Pack Builder обеспечивает следующие преимущества:

• Быстрое подключение новых источников телеметрии
• Единая панель мониторинга в рамках VMware Cloud Foundation
• Снижение затрат на разработку и поддержку интеграций
• Возможность моделирования пользовательских объектов и метрик
• Простое распространение решений между средами

Типовой рабочий процесс в Management Pack Builder

Процесс создания пакета управления с помощью MPB включает следующие этапы:

1. Определение источника данных и необходимых конечных точек API
2. Проектирование объектной модели и связей между объектами
3. Настройка параметров сбора данных, включая аутентификацию и расписание
4. Сопоставление полей ответов API с метриками и свойствами
5. Тестирование корректности сбора и отображения данных
6. Экспорт и развертывание пакета управления в других средах

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

Предположим, что система резервного копирования предоставляет данные о заданиях через REST API, включая статус выполнения, продолжительность и объем обработанных данных. С помощью Management Pack Builder можно:

• Подключиться к API системы резервного копирования
• Создать новый тип объекта, представляющий задачу резервного копирования
• Определить метрики, отражающие состояние и эффективность выполнения
• Настроить дашборды и оповещения в VCF Operations
• Использовать созданный пакет управления в других кластерах

Данный процесс на примере решения Rubrik показан в видео ниже:

В результате информация о резервном копировании становится частью единой системы наблюдаемости VMware Cloud Foundation, и вам не потребуется никаких отдельных консолей для мониторинга этого процесса.

Рекомендации по эффективному использованию MPB

Для успешного применения Management Pack Builder рекомендуется:

• Начинать с минимального набора метрик и постепенно расширять модель
• Использовать стабильные и уникальные идентификаторы объектов
• Оптимизировать частоту опроса API, чтобы избежать избыточной нагрузки
• Использовать примеры и лучшие практики, опубликованные в сообществах VMware

Роль Management Pack Builder в экосистеме VMware Cloud Foundation

VMware Cloud Foundation ориентирован на обеспечение унифицированного управления, операций и наблюдаемости в гибридных и частных облаках. Management Pack Builder дополняет эту концепцию, позволяя включать в контур мониторинга любые внешние и пользовательские системы.

Это обеспечивает целостное представление о состоянии инфраструктуры и приложений, независимо от источника данных.

Заключение

Management Pack Builder является важным инструментом для расширения возможностей наблюдаемости в VMware Cloud Foundation. Он позволяет быстро и гибко интегрировать сторонние источники телеметрии, сократить затраты на разработку адаптеров и централизовать мониторинг.

Использование MPB помогает организациям получить полную и целостную картину состояния своей инфраструктуры, повышая надежность и управляемость IT-среды.

Недавно был выпущен пакет управления vCommunity Management Pack для VCF Operations (подробнее о нем - тут), который охватывает несколько сценариев использования, включая: расширенные системные настройки хоста ESX, его пакеты и лицензирование, статус сетевых интерфейсов (NIC), расширенные параметры виртуальных машин, параметры ВМ, типы контроллеров SCSI виртуальных машин, а также службы события Windows.

Ну а на днях стал доступен для скачивания проект Hardware vCommunity Management Pack для VCF Operations, разрабатываемый инженером Broadcom Онуром Ювсевеном. Начальная версия поддерживает серверы Dell EMC PowerEdge (с использованием Redfish API на iDRAC). Он собирает десятки метрик, свойств и событий. Пакет управления включает 5 дашбордов, 8 представлений, 14 алертов и 19 симптомов (symptoms). Дашборды выглядят следующим образом.

Сам Management Pack можно скачать здесь. После загрузки он устанавливается так же, как и любой другой Management Pack. Затем необходимо создать экземпляр адаптера (или несколько, если требуется), который будет выглядеть примерно следующим образом.

Существует несколько требований:

• Файл конфигурации физических серверов — список FQDN/IP-адресов серверов Dell EMC. Файлы конфигурации можно создать в разделе Operations > Configurations > Management Pack Configurations > User Defined. Формат должен быть вот таким.
• Учётные данные iDRAC Redfish API (только чтение), а также Dell TechDirect Client ID/Secret (если требуется информация о гарантии).
• Collector/Group — необходимо использовать Cloud Proxy.
• Dell iDRAC Log Monitoring — уровень событий iDRAC, которые вы хотите собирать (или Disabled, если сбор не нужен).
• Dell Warranty Checker — переключатель проверки гарантии (Enable/Disable).
• Dell TechDirect URL — URL Dell TechDirect, к которому экземпляр адаптера будет обращаться для получения информации о гарантии.
• Maximum worker threads for data collection — максимальное количество рабочих потоков для сбора данных (по умолчанию 200).
• Maximum worker threads for ping request — максимальное количество рабочих потоков для ping-запросов (по умолчанию 100).
• Adapter Mode — режим работы адаптера: Server Monitoring или PING Only.
• Adapter Memory Limit (MB) — максимальный объём памяти, который будет использовать экземпляр адаптера.

После установки назначьте Custom Group Dell EMC Servers политике Hardware vCommunity Policy. Это включит все определения оповещений. vCommunity Management Pack создаст новый тип объекта с именем Physical Server.

MP собирает десятки метрик и свойств не только по самому серверу, но также по батареям, блокам питания, вентиляторам и другим компонентам. Кроме того, был добавлен бонусный дашборд (Dell EMC Server Details), который при желании можно использовать в качестве страницы сводной информации по физическому серверу (Physical Server Summary Page).

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

vCommunity Hardware Management Pack также включает алерты, как показано ниже:

Два ключевых свойства, которые собираются и по которым формируются оповещения — это остаточный прогнозируемый срок службы физического диска (Physical Disk Predicted Media Life Remaining) и оставшийся срок гарантии (Warranty Remaining), что позволяет администраторам заблаговременно планировать обслуживание и предотвращать проблемы.

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

Наверняка не всем из вас знаком ресурс virten.net — технический портал, посвящённый информации, новостям, руководствам и инструментам для работы с продуктами VMware и виртуализацией. Сайт предлагает полезные ресурсы как для ИТ-специалистов, так и для энтузиастов виртуализации, включая обзоры версий, документацию, таблицы сравнений и практические руководства.

Там можно найти:

• Новости и статьи о продуктах VMware (релизы, обновления, сравнения версий, технические обзоры).
• Полезные разделы по VMware vSphere, ESX, vCenter и другим продуктам, включая истории релизов, конфигурационные лимиты и различия между версиями.
• Практические инструменты и утилиты, такие как декодеры SCSI-кодов, RSS-трекер релизов (vTracker), помощь по OVF/PowerShell, события vCenter и JSON-репозиторий полезных данных.

Давайте посмотрим, что на этом сайте есть полезного для администраторов инфраструктуры VMware Cloud Foundation.

VMware Product Release Tracker (vTracker)

Эта страница содержит список продуктов, выпущенных компанией VMware. vTracker автоматически обновляется, когда на сайте vmware.com становятся доступны для загрузки новые продукты (GA — общедоступный релиз). Если вы хотите получать уведомления о выходе новых продуктов VMware, подпишитесь на RSS-ленту. Вы также можете использовать экспорт в формате JSON для создания собственного инструмента. Не стесняйтесь оставлять там комментарии, если у вас есть предложения по новым функциям.

• vTracker RSS Feed
• vTracker JSON Export
• vTracker CSV Export
• vTracker Table

Если вы просто хотите узнать, какая версия того или иного продукта VMware сейчас актуальна, самый простой способ - это посмотреть вот эту таблицу с функцией поиска:

VMware ESXi Release and Build Number History

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

Если вы столкнулись с какими-либо проблемами при работе с этим сайтом или заметили отсутствие сборок, пожалуйста, свяжитесь с автором.

VMware vCenter Release and Build Number History

По аналогии с гипервизором ESX/ESXi, на этой странице доступны даты релизов и номера билдов для средства управления VMware vCenter:

Такой же список релизов есть на сайте и для VMware NSX.

PowerShell OVF Helper

Эта страница представляет собой коллекцию заранее настроенных фрагментов PowerShell-скриптов для развертывания OVF/OVA. Идея заключается в ускорении процесса развертывания, если вам необходимо устанавливать несколько виртуальных модулей, выполнять повторное развертывание из-за неверных входных данных или сохранить файл в качестве справочного примера для будущих установок.

Просто заполните подготовленные переменные так же, как вы обычно делаете это в клиенте vSphere, и запустите скрипт. Все шаблоны используют одинаковую последовательность действий и тексты подсказок из мастера развертывания. Необязательные параметры конфигурации можно закомментировать. Если у параметров есть значения по умолчанию, они уже заполнены.

VMware ESXi SCSI Sense Code Decoder

Ошибки или предупреждения SCSI в логах и интерфейсе ESX отображаются с использованием 6 кодов состояния. Эта страница преобразует эти коды, полученные от хостов ESX, в понятную для человека информацию о состоянии подсистемы хранения. В системном журнале vmkernel.log на хостах ESXi версии 5.x или 6.0 вы можете увидеть записи, подобные приведённым ниже. На странице декодера вы можете ввести нужные числа в форму и получить пояснения по сообщениям SCSI:

В этой части статей о технологии NVMe Memory Tiering (см. прошлые части тут, тут, тут, тут и тут) мы поговорим о настройке этой технологии на серверах VMware ESX инфраструктуры VCF.

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

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

Шаги настройки

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

Предварительные проверки

Плотники живут по правилу «семь раз отмерь — один раз отрежь», потому что после разреза нельзя прокрутить фарш обратно. Чтобы избежать критических ошибок при настройке, мы должны сначала убедиться, что приняли правильные архитектурные решения для нашей среды.

Убедитесь, что вы ознакомились со следующим:

• Классы износа и производительности NVMe
• Избыточность и RAID-контроллеры
• Подбор размера NVMe-устройств
• Совместимость с vSAN

После того как вы приняли все эти важные решения, этап предварительных проверок включает подтверждение того, что устройства корректно отображаются на всех ESX-хостах. Вам понадобится UID каждого устройства, чтобы создать раздел, который будет использоваться Memory Tiering.

Создание разделов

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

Методы:

• ESXCLI: выполните стандартную команду esxcli (подробности тут).
• PowerShell: создайте скрипт для автоматизации процесса. Пример скрипта доступен тут, он может быть изменён под среду вашего кластера.

Частые вопросы

Вопрос: Могу ли я настроить разделы на двух устройствах без RAID на одном и том же хосте для обеспечения избыточности?
Ответ: Нет. Хотя VCF 9.0 позволяет без ошибок создавать разделы Memory Tiering на нескольких устройствах на хост, система не объединяет их и не зеркалирует данные.

Результат: Memory Tiering смонтирует только один диск, выбранный недетерминированным образом в процессе загрузки. Второй диск будет проигнорирован и не даст ни избыточности, ни увеличения ёмкости (см. будущую информацию об обновлении VCF 9.1 - там что-то может поменяться).

Включение Memory Tiering

Этот шаг активирует функцию Memory Tiering. Вы можете выполнить эту настройку через ESXCLI, PowerShell или интерфейс vCenter UI, применяя её к отдельным хостам или ко всему кластеру одновременно.

Вопрос: Требуется ли настраивать Memory Tiering на всех хостах в кластере VCF 9.0?
Ответ: Нет. У вас есть возможность выбрать конкретные хосты для Memory Tiering.

Хотя идеально, чтобы все хосты имели одинаковую конфигурацию, все понимают, что определённые ограничения ВМ могут потребовать исключений (см. тут).

Самый эффективный способ настроить Memory Tiering — использовать профили конфигурации vSphere. Это позволяет включить функцию сразу на всех ваших хостах, одновременно используя переопределения хостов для тех хостов, где вы не хотите включать её. Подробнее — тут.

Финальный шаг

Последний шаг прост: перезагрузите все хосты и выполните проверку. В VCF/VVF 9.0 перезагрузка является обязательной, чтобы эта функция вступила в силу.

Если вы используете профили конфигурации (Configuration Profiles), система автоматизирует поочерёдные перезагрузки (одна за другой), одновременно мигрируя ВМ, чтобы они оставались в сети. И если вам интересно, обеспечивает ли этот метод также доступность данных vSAN - ответ: да.

После того как все хосты снова будут онлайн, вы увидите новые элементы в интерфейсе, расположенные в разделах Advanced System Settings, на вкладке Monitor, а также Configure > Hardware > Overview > Memory.

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

В заключение: включение Memory Tiering - очень простой и понятный процесс. В качестве бонуса добавляем ссылку на актуальную лабораторную работу (Hands-on Lab), посвящённую Memory Tiering. Там вы можете выполнить настройку «от начала до конца», включая расширенные параметры, которые будут рассмотрены в следующих постах.

В этой части статей о технологии NVMe Memory Tiering (см. прошлые части тут, тут, тут и тут) мы предоставим некоторую информацию о различиях при включении Memory Tiering в разных сценариях. Хотя основной процесс остаётся тем же, есть моменты, которые могут потребовать дополнительного внимания и планирования, чтобы сэкономить время и усилия. Когда мы говорим о сценариях greenfield, мы имеем в виду совершенно новые развертывания VMware Cloud Foundation (VCF), включая новое оборудование и новую конфигурацию для всего стека. Сценарии brownfield будут охватывать настройку Memory Tiering в существующей среде VCF. Наконец, мы рассмотрим и лабораторные сценарии, поскольку встречаются неоднозначные утверждения о том, что это не поддерживается, но мы рассмотрим это в конце данной статьи.

Greenfield-развертывания

Давайте начнём с процесса конфигурации сред greenfield. Ранее мы рассказали о том, как VMware vSAN и Memory Tiering совместимы и могут сосуществовать в одном и том же кластере. Мы также обращали внимание на кое-что важное, о чём вам следует помнить во время greenfield-развертываний VCF. Начиная с VCF 9.0, включение Memory Tiering — это операция «Day 2», то есть сначала вы настраиваете VCF, а затем можете настроить Memory Tiering, но в ходе рабочего процесса развертывания VCF вы заметите, что опции для включения Memory Tiering (пока) нет, зато можно включить vSAN. То, как вы поступите с вашим NVMe-устройством, выделенным для Memory Tiering, будет определять шаги, необходимые для того, чтобы это устройство было представлено для его конфигурации.

Если все NVMe-устройства и для vSAN, и для Memory Tiering присутствуют во время развертывания VCF, есть вероятность, что vSAN может автоматически занять все накопители (включая NVMe-устройство, которое вы выделили для Memory Tiering). В этом случае вам пришлось бы удалить накопитель из vSAN после конфигурации, стереть разделы, а затем начать настройку Memory Tiering. Этот шаг был рассмотрен тут.

Другой подход — извлечь или не устанавливать устройство Memory Tiering в сервер и добавить его обратно в сервер после развертывания VCF. Таким образом вы не будете рисковать тем, что vSAN автоматически займет NVMe для Memory Tiering. Хотя это и не является серьёзным препятствием, всё равно полезно знать, что произойдёт и почему, чтобы вы могли быстро выделить ресурсы, необходимые для настройки Memory Tiering.

Brownfield-развертывания

Сценарии brownfield немного проще, так как VVF/VCF уже настроен; однако vSAN мог быть включён или ещё нет.

Если vSAN не включён, вам нужно будет отключить функцию auto-claim, пройти через конфигурацию vSAN и вручную выбрать ваши устройства (кроме NVMe-устройств для Memory Tiering). Всё выполняется в интерфейсе UI и по процедуре, которая используется уже много лет. Это гарантирует, что NVMe-устройство Memory Tiering будет доступно для настройки. Подробный процесс задокументирован в TechDocs.

Если vSAN уже включён, мы предполагаем, что NVMe-устройство для Memory Tiering только что было приобретено и готово к установке. Значит, всё, что нам нужно сделать, — добавить его в хост и убедиться, что оно корректно отображается как NVMe-устройство и что на нём нет существующих разделов. Это, вероятно, самый простой сценарий и самый распространённый.

Развертывания в тестовой среде

Теперь давайте поговорим о давно ожидаемом лабораторном сценарии. Для лаборатории типа bare metal, где сервер ESX одноуровневый и нет вложенных сред, применяются те же принципы greenfield и brownfield. Что касается вложенной (nested) виртуализации, многие говорят о том, что вложенный Memory Tiering не поддерживается. Ну, это и так, и не так.

Когда мы говорим о вложенных средах, мы имеем в виду два уровня ESX. Внешний уровень — это ESX, установленный на оборудовании (обычная настройка), а внутренний уровень ESX состоит из виртуальных машин, запускающих ESX и выступающих в роли как бы физических хостов. Memory Tiering МОЖЕТ быть включён на внутреннем уровне (вложенном), и все параметры конфигурации работают нормально. Мы делаем следующее: берём datastore и создаём виртуальный Hard Disk типа NVMe, чтобы представить его виртуальной машине, которая выступает в роли вложенного хоста. Хотя мы видим NVMe-устройство на вложенном хосте и можем настроить Memory Tiering, базовое устройство хранения состоит из устройств, формирующих выбранный datastore. Вы можете настроить Memory Tiering, и вложенные хосты смогут видеть hot и active pages, но не ожидайте какого-либо уровня производительности, учитывая, что компоненты базового хранилища построены на традиционных накопителях. Работает ли это? ДА, но только в лабораторных средах.

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

А как насчёт внешнего уровня? Ну, это как раз то, что не поддерживается в VCF 9.0, поскольку внешний уровень ESX не имеет видимости внутреннего уровня и не может видеть активность памяти ВМ, по сути пытаясь «прозреть» сквозь вложенный уровень до виртуальной машины (inception). Это и есть главное отличие (не вдаваясь слишком глубоко в технические детали).

Так что если вам интересно протестировать Memory Tiering, а всё, что у вас есть — это вложенная среда, вы можете настроить Memory Tiering и любые расширенные параметры. Интересно наблюдать, как несколько шагов настройки могут добавить хостам 100% дополнительной памяти.

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

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

Есть некоторые переменные, которые вам нужно изменить, чтобы он работал в вашей среде:

$vCenter = “ваш vCenter FQDN или IP” (строка 27)

$clusterName = “имя вашего кластера” (строка 28)

Вот и сам скрипт:

function Update-NvmeMemoryTier {
    param (
        [Parameter(Mandatory=$true)]
        [VMware.VimAutomation.ViCore.Impl.V1.Inventory.VMHostImpl]$VMHost,
        [Parameter(Mandatory=$true)]
        [string]$DiskPath
    )

    try {
        # Verify ESXCLI connection
        $esxcli = Get-EsxCli -VMHost $VMHost -V2
        # Note: Verify the correct ESXCLI command for NVMe memory tiering; this is a placeholder
        # Replace with the actual command or API if available
        $esxcli.system.tierdevice.create.Invoke(@{ nvmedevice = $DiskPath }) # Hypothetical command
        Write-Output "NVMe Memory Tier created successfully on host $($VMHost.Name) with disk $DiskPath"
        return $true
    }
    catch {
        Write-Warning "Failed to create NVMe Memory Tier on host $($VMHost.Name) with disk $DiskPath. Error: $_"
        return $false
    }
}

# Securely prompt for credentials
$credential = Get-Credential -Message "Enter vCenter credentials"

$vCenter = "vcenter FQDN"
$clusterName = "cluster name"

try {
    # Connect to vCenter
    Connect-VIServer -Server $vCenter -Credential $credential -WarningAction SilentlyContinue
    Write-Output "Connected to vCenter Server successfully."

    # Get cluster and hosts
    $cluster = Get-Cluster -Name $clusterName -ErrorAction Stop
    $vmHosts = Get-VMHost -Location $cluster -ErrorAction Stop

    foreach ($vmHost in $vmHosts) {
        Write-Output "Fetching disks for host: $($vmHost.Name)"
        $disks = @($vmHost | Get-ScsiLun -LunType disk |
            Where-Object { $_.Model -like "*NVMe*" } | # Filter for NVMe disks
            Select-Object CanonicalName, Vendor, Model, MultipathPolicy,
                @{N='CapacityGB';E={[math]::Round($_.CapacityMB/1024,2)}} |
            Sort-Object CanonicalName) # Explicit sorting

        if (-not $disks) {
            Write-Warning "No NVMe disks found on host $($vmHost.Name)"
            continue
        }

        # Build disk selection table
        $diskWithIndex = @()
        $ctr = 1
        foreach ($disk in $disks) {
            $diskWithIndex += [PSCustomObject]@{
                Index          = $ctr
                CanonicalName  = $disk.CanonicalName
                Vendor         = $disk.Vendor
                Model          = $disk.Model
                MultipathPolicy = $disk.MultipathPolicy
                CapacityGB     = $disk.CapacityGB
            }
            $ctr++
        }

        # Display disk selection table
        $diskWithIndex | Format-Table -AutoSize | Out-String | Write-Output

        # Get user input with validation
        $maxRetries = 3
        $retryCount = 0
        do {
            $diskChoice = Read-Host -Prompt "Select disk for NVMe Memory Tier (1 to $($disks.Count))"
            if ($diskChoice -match '^\d+$' -and $diskChoice -ge 1 -and $diskChoice -le $disks.Count) {
                break
            }
            Write-Warning "Invalid input. Enter a number between 1 and $($disks.Count)."
            $retryCount++
        } while ($retryCount -lt $maxRetries)

        if ($retryCount -ge $maxRetries) {
            Write-Warning "Maximum retries exceeded. Skipping host $($vmHost.Name)."
            continue
        }

        # Get selected disk
        $selectedDisk = $disks[$diskChoice - 1]
        $devicePath = "/vmfs/devices/disks/$($selectedDisk.CanonicalName)"

        # Confirm action
        Write-Output "Selected disk: $($selectedDisk.CanonicalName) on host $($vmHost.Name)"
        $confirm = Read-Host -Prompt "Confirm NVMe Memory Tier configuration? This may erase data (Y/N)"
        if ($confirm -ne 'Y') {
            Write-Output "Configuration cancelled for host $($vmHost.Name)."
            continue
        }

        # Configure NVMe Memory Tier
        $result = Update-NvmeMemoryTier -VMHost $vmHost -DiskPath $devicePath
        if ($result) {
            Write-Output "Successfully configured NVMe Memory Tier on host $($vmHost.Name)."
        } else {
            Write-Warning "Failed to configure NVMe Memory Tier on host $($vmHost.Name)."
        }
    }
}
catch {
    Write-Warning "An error occurred: $_"
}
finally {
    # Disconnect from vCenter
    Disconnect-VIServer -Server $vCenter -Confirm:$false -ErrorAction SilentlyContinue
    Write-Output "Disconnected from vCenter Server."
}

Переход на VMware Cloud Foundation (VCF) 9 — это не просто обновление версии платформы. Он включает ребрендинг ключевых сервисов, перенос функций между компонентами, а также существенные улучшения управления жизненным циклом (Lifecycle Management). Для команд, планирующих миграцию с VCF 5.x, важно понимать, что именно изменилось: какие элементы остались прежними, какие переименованы, а какие были полностью заменены.

Об этом в общих чертах мы писали в прошлой статье, а сегодня разберём переход с VCF 5.x серии на версию VCF 9 через призму:

• Сравнения ключевых компонентов
• Архитектурных изменений
• Обновлений управления жизненным циклом
• Замены компонентов и блоков функционала

Обо всем этом рассказывается в видео ниже:

Базовая архитектура управления: что осталось неизменным

SDDC Manager — ядро VCF остаётся тем же

Один из наиболее важных выводов: SDDC Manager по-прежнему остаётся центральным движком управления VCF, и он:

• Присутствует как в VCF 5, так и в VCF 9
• Не меняет название (нет ребрендинга)
• Остаётся основным интерфейсом управления инфраструктурой

Однако отмечается, что в VCF 9 функциональность SDDC Manager расширена и улучшена по сравнению с 5-й серией.
Это важно, потому что SDDC Manager — "точка сборки" всей архитектуры VCF: он стабильный и развивается, миграции проще планировать и стандартизировать.

Изменения бренда и унификация: Aria -> VCF Operations

Одно из наиболее заметных изменений VCF 9 — это масштабный ребрендинг линейки VMware Aria в сторону единого зонтичного бренда VCF Operations.

VMware Aria Operations -> VCF Operations

Ранее компонент VMware Aria Operations выполнял роль:

• Централизованных дашбордов
• Мониторинга инфраструктуры
• Уведомлений и alerting
• SNMP-настроек
• Кастомной отчётности (например, oversizing виртуальных машин)
• Capacity planning

В VCF 9 этот же компонент переименован как часть стратегии VMware по движению к унифицированной "operations-платформе" в рамках VCF. Функционально компонент выполняет те же задачи, но позиционирование стало единым для всей платформы.

Operations-экосистема: логирование и сетевые инсайты

Aria Operations for Logs -> VCF Operations for Logs

Компонент логирования в VCF 5 назывался по-разному в средах заказчиков: Aria Operations for Logs и Log Insight. По сути — это централизованный syslog-агрегатор и анализатор, собирающий логи от всех компонентов VCF. В VCF 9 Aria Operations for Logs переименован VCF Operations for Logs. Функционально это тот же концепт, сбор логов остаётся централизованным и управляется как часть единого "Operations-стека".

Aria Operations for Network Insights -> VCF Operations for Network

Сетевой компонент прошёл длинный путь переименований: vRealize Network Insight, затем Aria Operations for Networks и, наконец, в VCF 9 он называется VCF Operations for Network.

Он обеспечивает:

• Централизованный мониторинг сети
• Диагностику
• Анализ сетевого трафика
• Возможности packet capture от источника до назначения

Главное архитектурное изменение: Lifecycle Management -> Fleet Management

VMware Aria Lifecycle Management (Aria LCM) -> VCF Operations Fleet Management

В VCF 5 жизненным циклом (апдейты/апгрейды) занимался компонент Aria Lifecycle Management (LCM), В VCF 9 сделан важный шаг - появился компонент VCF Operations Fleet Management. Это не просто переименование - продукт получил улучшенную функциональность, управление обновлениями и версиями стало более "streamlined", то есть рациональным и оптимизированным, а также появился акцент на fleet-подход: управление инфраструктурой как "парком платформ".

Fleet Management способен управлять несколькими инстансами VCF, что становится особенно важным для крупных организаций и распределённых инфраструктур. Именно тут виден "архитектурный сдвиг": VCF 9 проектируется не только как платформа для одного частного облака, а как унифицированная экосистема для гибридных и мультиинстанс-сценариев.

Feature transition: замена Workspace ONE Access

Workspace ONE Access удалён -> VCF Identity Broker

Одно из самых "жёстких" изменений — это не ребрендинг, а полная замена компонента. Workspace ONE Access полностью удалён (removed), вместо него введён новый компонент VCF Identity Broker. Это новый компонент для управления идентификацией (identity management), интеграции доступа, IAM-сценариев (identity access management), интеграции авторизации/аутентификации для экосистемы VCF.

Миграция и перемещение рабочих нагрузок: HCX теперь - часть Operations

VMware HCX -> VCF Operations HCX

HCX остаётся инструментом для пакетной миграции виртуальных машин (bulk migration) и миграций из одной локации в другую (в т.ч. удалённые площадки). Но в VCF 9 меняется позиционирование продукта: он теперь полностью интегрирован в VCF Operations и называется VCF Operations HCX. То есть HCX становится частью единого "операционного" контура VCF 9.

Автоматизация: упрощение названий и интеграция компонентов

Aria Automation -> VCF Automation

Это компонент автоматизации, отвечающий за сценарии и рабочие процессы частного облака, развертывание рабочих нагрузок и ежедневные операции. В VCF 9 это просто VCF Automation.

Aria Automation Orchestrator -> VCF Operations Orchestrator

Orchestrator используется для end-to-end рабочих процессов и автоматизации процессов создания ВМ и операций. В VCF 9 это теперь просто VCF Operations Orchestrator. Это важно: Orchestrator закрепляется как часть "operations-логики", а не просто автономный компонент автоматизации.

VMware Cloud Director: интеграция/поглощение в VCF Automation

Теперь VMware Cloud Director имеет новое позиционирование: продукт полностью интегрирован в VCF Automation. То есть Cloud Director как самостоятельное наименование уходит на второй план, а функции “переезжают” или связываются с модулем VCF Automation.

Слой Kubernetes: vSphere with Tanzu -> vSphere Supervisor

vSphere with Tanzu переименован в vSphere Supervisor

Это важное изменение, отражающее стратегию VCF по треку modern apps. Supervisor рассматривается как компонент для приложений новой волны, перехода monolith > microservices, контейнерного слоя и инфраструктуры enterprise-grade Kubernetes.

Платформа VCF при этом описывается как:

• Unified Cloud Platform
• Подходит для частного облака
• Интегрируется с hyperscalers (AWS, Azure, Google Cloud и т.д.)
• Поддерживает enterprise Kubernetes services

Итоги: что означает переход VCF 5 -> VCF 9 для архитектуры и миграции

Переход от VCF 5.x к VCF 9 — это комбинация трёх больших тенденций:

1) Унификация бренда и операционной модели

Aria-компоненты массово становятся частью семейства VCF Operations.

2) Улучшение управления жизненным циклом

LCM эволюционирует в Fleet Management, что отражает переход к управлению группами платформ и множественными VCF-инстансами.

Самое заметное — удаление Workspace ONE Access и введение VCF Identity Broker.

Cоответствие компонентов VCF 5.x и VCF 9

• SDDC Manager -> SDDC Manager (улучшен)
• Aria Operations -> VCF Operations
• Aria Operations for Logs -> VCF Operations for Logs
• Aria Operations for Network Insights -> VCF Operations for Network
• Aria LCM -> VCF Operations Fleet Management
• Workspace ONE Access -> VCF Identity Broker (замена продукта)
• HCX -> VCF Operations HCX
• Aria Automation -> VCF Automation
• Aria Automation Orchestrator -> VCF Operations Orchestrator
• Cloud Director -> интеграция в VCF Automation
• vSphere with Tanzu -> vSphere Supervisor

В новом видео на канале Gnan Cloud Garage подробно разобраны ключевые отличия между VMware Cloud Foundation (VCF) версии 5.2 и VCF 9.0, причем автор подчеркивает: речь идёт не о простом обновлении, а о кардинальной архитектурной переработке платформы.

VCF — это флагманская платформа частного облака от компании VMware, объединяющая вычисления, сеть, хранилище, безопасность, автоматизацию и управление жизненным циклом в едином программно-определяемом стеке. В версии 9.0 VMware делает шаг в сторону «облачного» подхода, ориентированного на масштаб, автоматизацию и гибкость.

Основные отличия VCF 5.2 и VCF 9.0

1. Модель развертывания

• VCF 5.2: установка строилась вокруг SDDC Manager и требовала загрузки Cloud Builder размером около 20 ГБ. Развёртывание компонентов происходило последовательно.
• VCF 9.0: представлен новый VCF Installer (~2 ГБ) и fleet-based модель. Это обеспечивает более быстрое развертывание, модульную архитектуру и гибкость с первого дня.

Результат: ускорение внедрения и переход от монолитного подхода к модульному.

2. Управление жизненным циклом (LCM)

• VCF 5.2: весь LCM был сосредоточен в SDDC Manager.
• VCF 9.0: управление разделено между Fleet Management Appliance и SDDC Manager.
  
  
• Fleet Management отвечает за операции, автоматизацию и управление идентификацией.
• SDDC Manager фокусируется на базовой инфраструктуре.

Результат: параллельные обновления, меньшее время простоя и более точный контроль.

3. Управление идентификацией

• VCF 5.2: использовались Enhanced Linked Mode и vCenter Identity.
• VCF 9.0: внедрены VCF Single Sign-On и VCF Identity Broker, обеспечивающие единую систему идентификации для всех компонентов.

Результат: действительно унифицированная и современная модель identity management.

4. Лицензирование

• VCF 5.2: традиционные лицензии — по продуктам и ключам (vSphere, NSX, vSAN, Aria).
• VCF 9.0: keyless subscription model — без ключей, с подпиской.

Результат: упрощённое соответствие требованиям, обновления и соответствие современным облачным моделям потребления.

5. Операции и мониторинг

• VCF 5.2: VMware Aria Operations — опциональный компонент.
• VCF 9.0: операции встроены по умолчанию, обеспечивая fleet-wide мониторинг и compliance «из коробки».

6. Автоматизация

• VCF 5.2: автоматизация была дополнительной опцией.
• VCF 9.0: решение VCF Automation встроено и оптимизировано для:

• AI-нагрузок
• Kubernetes
• виртуальных машин

Результат: платформа самообслуживания, полностью готовая для разработчиков.

• VCF 5.2: NSX — опциональный компонент.
• VCF 9.0: NSX становится обязательным для management и workload-доменов.

Результат: единая программно-определяемая сетевая архитектура во всей среде VCF.

8. Хранилище

• VCF 5.2: поддержка vSAN, NFS и Fibre Channel SAN.
• VCF 9.0: акцент на vSAN ESA (Express Storage Architecture) и Original Storage Architecture, с планами по расширению поддержки внешних хранилищ.

Результат: фундамент для более современной и производительной storage-архитектуры.

9. Безопасность и соответствие требованиям

• VCF 5.2: ручное управление сертификатами и патчами.
• VCF 9.0: встроенные средства управления:
  
  
  • унифицированное управление ключами
  • live patching
  • secure-by-default подход

Результат: серьёзная модернизация безопасности и Zero Trust по умолчанию.

10. Модель обновлений

• VCF 5.2: последовательные апгрейды.
• VCF 9.0: параллельные обновления с учётом fleet-aware LCM.

Результат: меньше простоев и лучшая предсказуемость обслуживания.

11. Kubernetes и контейнеры

• VCF 5.2: ограниченная поддержка Tanzu.
• VCF 9.0: нативный Kubernetes через VCF Automation.

Результат: единая платформа для VM и Kubernetes — полноценная application platform.

12. Импорт существующих сред

• VCF 5.2: импорт существующих vSphere/vCenter не поддерживался.
• VCF 9.0: можно импортировать существующие окружения как management или workload-домены.

Результат: упрощённая миграция legacy-нагрузок в современное частное облако.

Итог

VCF 5.2 — это классическая платформа частного облака с опциональными возможностями, ну а VCF 9.0 — это современное, cloud-like частное и гибридное облако, ориентированное на масштабирование, автоматизацию и управление флотом инфраструктуры.

Как подчёркивает автор видео, VCF 9.0 — это не апгрейд, а полноценный редизайн, нацеленный на лучший пользовательский опыт и соответствие требованиям современных enterprise и облачных сред.

Brock Peterson написал полезную статью о том, что в новой версии VMware VCF Operations 9 была представлена функция под названием Log Assist (ранее это было частью решения Slyline), которая позволяет загружать пакеты поддержки (Support Bundles) в службу поддержки Broadcom непосредственно из VCF Operations. Вот как это работает.

Во-первых, необходимо зарегистрировать и лицензировать ваш экземпляр VCF Operations. Документацию о том, как это сделать, можно найти здесь.

Во-вторых, в вашей среде должен быть развернут Unified Cloud Proxy. Ранее автор уже рассказывал о том, как его развернуть, здесь. Обязательно убедитесь, что функция Log Assist активирована на вашем Unified Cloud Proxy.

В-третьих, необходимо назначить компоненты Unified Cloud Proxy в разделе Infrastructure Operations > Configurations > Logs > Log Assist Assignment:

Вы можете видеть, что автор назначил свой vCenter и экземпляр VCF Operations. Перетащите компоненты с правой панели в левую:

После назначения они будут отображаться на вкладке Assigned Objects.

Теперь вы можете использовать функцию Log Assist, которая находится в разделе Infrastructure > Diagnostic Findings. Пользователи также могут найти эту функцию в разделе Administration > Control Panel > Log Assist.

Нажмите LOG ASSIST в правом верхнем углу:

Нажмите PREPARE A TRANSFER:

Теперь у вас есть возможность выбрать объект, для которого вы хотите собрать пакет поддержки (Support Bundle). В данном случае веберем vCenter и нажмем NEXT внизу:

Когда статус изменится на Connected, нажмите NEXT:

Введите идентификатор вашего обращения в службу поддержки и выберите TRANSFER:

Вы увидите вашу самую последнюю отправку (Transfer) вверху списка. Нажав на двойную стрелку слева, вы сможете просмотреть детали:

Как вы можете видеть, вместе с пакетом поддержки (Support Bundle) загружается диагностический отчет (Diagnostic Report). После завершения это будет выглядеть вот так:

Ваш пакет журналов поддержки (Support Bundle) теперь загружен в службу поддержки Broadcom для анализа. Также существует подробная статья базы знаний (KB) по этому процессу, вы можете найти её здесь.

VMware Cloud Foundation (VCF) 9.0 предоставляет быстрый и простой способ развертывания частного облака. Хотя обновление с VCF 5.x спроектировано как максимально упрощённое, оно вносит обязательные изменения в методы управления и требует аккуратного, поэтапного выполнения.

Недавно Джонатан Макдональд провёл насыщенный вебинар вместе с Брентом Дугласом, где они подробно разобрали процесс обновления с VCF 5.2 до VCF 9.0. Сотни участников и шквал вопросов ясно показали, что этот переход сейчас волнует многих клиентов VMware.

Джонатан отфильтровал повторяющиеся вопросы, объединив похожие в единые, комплексные темы. Ниже представлены 10 ключевых вопросов («must-know»), заданных аудиторией, вместе с подробными ответами, которые помогут вам уверенно пройти путь к VCF 9.0.

Вопрос 1: Как VMware SDDC Manager выполняет обновления? Есть ли значительные изменения в обновлениях версии 9.0?

Было много вопросов, связанных с SDDC Manager и процессом обновлений. Существенных изменений в том, как выполняются обновления, нет. Если вы знакомы с VCF 5.2, то асинхронный механизм патчинга встроен в консоль точно так же и в версии 9.0. Это позволяет планировать обновления и патчи по необходимости. Главное отличие заключается в том, что интерфейс SDDC Manager был интегрирован в консоль VCF Operations и теперь находится в разделе управления парком (Fleet Management). Многие рабочие процессы также были перенесены, что позволило консолидировать интерфейсы.

Вопрос 2: Есть ли особенности обновления кластеров VMware vSAN Original Storage Architecture (OSA)?

vSAN OSA не «уходит» и не объявлен устаревшим в VCF 9.0. Аппаратные требования для vSAN Express Storage Architecture (ESA) существенно отличаются и могут быть несовместимы с существующим оборудованием. vSAN OSA — отличный способ продолжать эффективно использовать имеющееся оборудование без необходимости покупать новое. Для самого обновления важно проверить совместимость аппаратного обеспечения и прошивок с версией 9.0. Если они поддерживаются, обновление пройдёт так же, как и в предыдущих релизах.

Вопрос 3: Как выполняется обновление VMware NSX?

При обновлении VCF все компоненты, включая NSX, обновляются последовательно. Обычно процесс начинается с компонентов VCF Operations. После этого управление передаётся рабочим процессам SDDC Manager: сначала обновляется сам SDDC Manager, затем NSX, потом VMware vCenter и в конце — хосты VMware ESX.

Вопрос 4: Если VMware Aria Suite развернут в режиме VCF-aware в версии 5.2, нужно ли отвязывать Aria Suite перед обновлением?

Нет. Вы можете сначала обновить компоненты Aria Suite до версии, совместимой с VCF 9, а затем продолжить обновление остальных компонентов.

Вопрос 5: Можно ли обновиться с VCF 5.2 без настроенных LCM и Aria Suite?

Да. Наличие компонентов Aria Suite до обновления на VCF 9.0 не требуется. Однако в рамках обновления будут развернуты Aria Lifecycle (в версии 9.0 — VCF Fleet Management) и VCF Operations, так как они являются обязательными компонентами в 9.0.

Вопрос 6: Сколько хостов допускается в консолидированном дизайне VCF 9.0?

Для нового консолидированного дизайна рекомендуется минимум четыре хоста. При конвергенции инфраструктуры с использованием vSAN требуется минимум три ESX-хоста (четыре рекомендуются для отказоустойчивости). При использовании внешних систем хранения достаточно минимум двух хостов. Что касается максимальных значений, документированных ограничений нет, кроме ограничений VMware vSphere: 96 хостов на кластер и 2500 хостов на один vCenter. В целом рекомендуется по мере роста добавлять дополнительные домены рабочих нагрузок или кластеры для логического разделения среды с точки зрения производительности, доступности и восстановления.

Вопрос 7: Как перейти с VMware Identity Manager (vIDM) на VCF Identity Broker (VIDB) в VCF 9?

Прямого пути обновления или миграции с vIDM на VIDB не существует. Требуется «чистое» (greenfield) развертывание VIDB. Это особенно актуально, если используется VCF Automation, так как в этом случае новое развертывание VIDB является обязательным.

Вопрос 8: Нужно ли загружать дистрибутивы для VCF Operations и куда их помещать?

Это зависит от используемого сценария. В общем случае, если вы выполняете обновление и компоненты Aria ещё не установлены, потребуется загрузить и развернуть виртуальные машины VCF Operations и VCF Operations Fleet Management. После их развертывания бинарные файлы загружаются в репозиторий (depot) VCF Operations Fleet Management для установки дополнительных компонентов. Если вы конвергируете vSphere в VCF, все недостающие компоненты будут развернуты установщиком VCF, и, соответственно, должны быть загружены в него заранее.

Вопрос 9: Существует ли путь отката (rollback), если во время обновления возникла ошибка?

В целом не существует «кнопки отката» для всего VCF сразу. Лучше рассматривать каждое последовательное обновление как контрольную точку. Например, перед обновлением SDDC Manager с 5.2 до 9.0 нужно всегда делать резервную копию. Если во время обновления возникает сбой, можно откатиться к состоянию до ошибки и продолжить диагностику. То же самое относится к другим компонентам. При сбоях в обновлении NSX, vCenter или ESX-хостов нужно оценить ситуацию и либо выполнить откат, либо обратиться в поддержку, если время окна обслуживания истекает и необходимо срочно восстановить работоспособность среды. Именно поэтому тщательное планирование имеет решающее значение при любом обновлении VCF.

Вопрос 10: Существует ли путь миграции с VMware Cloud Director (VCD) на VCF Automation?

На данный момент VCD не поддерживается в VCF 9.0, и официальных путей миграции не существует. Если у вас есть вопросы по этому поводу, обратитесь к вашему Account Director.

Диаграмма задержек VMware Cloud Foundation 9.0 теперь официально доступна на сайте Ports and Protocols в разделе Network Diagrams > VMware Cloud Foundation. Это официальный и авторитетный источник, который наглядно показывает сетевые взаимодействия и требования к задержкам в VCF 9.0.

Данное руководство настоятельно рекомендуется распечатать и разместить на рабочем месте каждого архитектора и администратора. Оно значительно упрощает проектирование, внедрение и сопровождение инфраструктуры, помогает быстрее выявлять узкие места, а также служит удобной шпаргалкой при обсуждении архитектурных решений, устранении неполадок и проверке соответствия требованиям. Фактически, это must-have материал для всех, кто работает с VMware Cloud Foundation в производственной среде.

Диаграмма демонстрирует, как различные элементы инфраструктуры VCF — управляющие домены, рабочие домены и центральные службы — взаимодействуют друг с другом в рамках распределённой частной облачной платформы, а также какие целевые значения Round-Trip Time (RTT) рекомендованы для стабильной и предсказуемой работы.

Что отражено на диаграмме:

• VCF Fleet Components: диаграмма охватывает два отдельных экземпляра VCF (Instance 1 и Instance 2), включая их управляющие домены (Management Domain) и рабочие домены (Workload Domain), а также центральные Fleet-сервисы — VCF Operations и VCF Automation.
• Целевые задержки: на диаграмме проставлены ориентировочные максимальные RTT-значения между компонентами, например между коллекторами VCF Operations и такими элементами, как vCenter, SDDC Manager, NSX Manager и ESX-хостами. Это служит практическим ориентиром для сетевых инженеров при планировании WAN- или LAN-связей между локациями.
• Линии связи разной направленности: взаимодействия выполняются по разным путям и цветам, отражая направление обмена данными и зависимости между сервисами. Это помогает визуализировать, какие службы должны быть ближе друг к другу с точки зрения сети, а какие могут находиться дальше.

Такой сетевой ориентир крайне полезен архитекторам и администраторам, которые проектируют либо оптимизируют VCF-окружения в распределённых инфраструктурах. Он служит чёткой справочной картой, позволяющей:

• Определить, какие связи нужно обеспечить минимально короткими с точки зрения задержки.
• Согласовать проектные требования к ширине канала и RTT в разных сегментах сети.
• Избежать узких мест в межкластерных коммуникациях, которые могут повлиять на производительность, управление или репликацию данных.

Диаграмма — это не просто техническая схема, а полноценный план качества сети, который должен учитываться при разворачивании VCF 9.0 на уровне предприятия.

Broadcom в сотрудничестве с Dell, Intel, NVIDIA и SuperMicro недавно продемонстрировала преимущества виртуализации, представив результаты MLPerf Inference v5.1. Платформа VMware Cloud Foundation (VCF) 9.0 показала производительность, сопоставимую с bare metal, по ключевым AI-бенчмаркам, включая Speech-to-Text (Whisper), Text-to-Video (Stable Diffusion XL), большие языковые модели (Llama 3.1-405B и Llama 2-70B), графовые нейронные сети (R-GAT) и компьютерное зрение (RetinaNet). Эти результаты были достигнуты как на GPU-, так и на CPU-решениях с использованием виртуализированных конфигураций NVIDIA с 8x H200 GPU, GPU 8x B200 в режиме passthrough/DirectPath I/O, а также виртуализированных двухсокетных процессоров Intel Xeon 6787P.

Для прямого сравнения соответствующих метрик смотрите официальные результаты MLCommons Inference 5.1. Этими результатами Broadcom вновь демонстрирует, что виртуализованные среды VCF обеспечивают производительность на уровне bare metal, позволяя заказчикам получать преимущества в виде повышенной гибкости, доступности и адаптивности, которые предоставляет VCF, при сохранении отличной производительности.

VMware Private AI — это архитектурный подход, который балансирует бизнес-выгоды от AI с требованиями организации к конфиденциальности и соответствию нормативам. Основанный на ведущей в отрасли платформе частного облака VMware Cloud Foundation (VCF), этот подход обеспечивает конфиденциальность и контроль данных, выбор между решениями с открытым исходным кодом и коммерческими AI-платформами, а также оптимальные затраты, производительность и соответствие требованиям.

Private AI позволяет предприятиям использовать широкий спектр AI-решений в своей среде — NVIDIA, AMD, Intel, проекты сообщества с открытым исходным кодом и независимых поставщиков программного обеспечения. С VMware Private AI компании могут развертывать решения с уверенностью, зная, что Broadcom выстроила партнерства с ведущими поставщиками AI-технологий. Broadcom добавляет мощь своих партнеров — Dell, Intel, NVIDIA и SuperMicro — в VCF, упрощая управление дата-центрами с AI-ускорением и обеспечивая эффективную разработку и выполнение приложений для ресурсоемких AI/ML-нагрузок.

В тестировании были показаны три конфигурации в VCF:

• SuperMicro GPU SuperServer AS-4126GS-NBR-LCC с NVLink-соединенными 8x B200 в режиме DirectPath I/O
• Dell PowerEdge XE9680 с NVLink-соединенными 8x H200 в режиме vGPU
• Конфигурация 1-node-2S-GNR_86C_ESXi_172VCPU-VM с процессорами Intel® Xeon® 6787P с 86 ядрами.

Производительность MLPerf Inference 5.1 с VCF на сервере SuperMicro с NVIDIA 8x B200

VCF поддерживает как DirectPath I/O, так и технологии NVIDIA Virtual GPU (vGPU) для использования GPU в задачах AI и других GPU-ориентированных нагрузках. Для демонстрации AI-производительности с GPU NVIDIA B200 был выбран DirectPath I/O для бенчмаркинга MLPerf Inference.

Инженеры запускали нагрузки MLPerf Inference на сервере SuperMicro SuperServer AS-4126GS-NBR-LCC с восемью GPU NVIDIA SXM B200 с 180 ГБ HBM3e при использовании VCF 9.0.0.

В таблице ниже показаны аппаратные конфигурации, использованные для выполнения нагрузок MLPerf Inference 5.1 на bare metal и виртуализированных системах. Бенчмарки были оптимизированы с помощью NVIDIA TensorRT-LLM. TensorRT-LLM включает в себя компилятор глубокого обучения TensorRT и содержит оптимизированные ядра, этапы пред- и пост-обработки, а также примитивы меж-GPU и межузлового взаимодействия, обеспечивая выдающуюся производительность на GPU NVIDIA.

Сравнение производительности виртуализованных и bare metal ML/AI-нагрузок на примере сервера SuperMicro SuperServer AS-4126GS-NBR-LCC:

Некоторые моменты:

• Результат сценария Llama 3.1 405B в интерактивном режиме не был верифицирован Ассоциацией MLCommons. Broadcom и SuperMicro не отправляли его на проверку, поскольку это не требовалось.
• Результаты Stable Diffusion XL, представленные Broadcom и SuperMicro, не могли быть напрямую сопоставлены с результатами SuperMicro на том же оборудовании, поскольку SuperMicro не отправляла результаты бенчмарка Stable Diffusion на платформе bare metal. Поэтому сравнение выполнено с другой заявкой, использующей сопоставимый хост с 8x NVIDIA B200-SXM-180GB.

Рисунок выше показывает, что AI/ML-нагрузки инференса из различных доменов — LLM (Llama 3.1 с 405 млрд параметров), Speech-to-Text (Whisper от OpenAI) и Text-to-Image (Stable Diffusion XL) — в VCF достигают производительности, сопоставимой с bare metal. При запуске AI/ML-нагрузок в VCF пользователи получают преимущества управления датацентром, предоставляемые VCF, при сохранении производительности на уровне bare metal.

Производительность MLPerf Inference 5.1 с VCF на сервере Dell с NVIDIA 8x H200

Broadcom поддерживает корпоративных заказчиков, использующих AI-инфраструктуру от различных аппаратных вендоров. В рамках раунда заявок для MLPerf Inference 5.1, VMware совместно с NVIDIA и Dell продемонстрировала VCF 9.0 как отличную платформу для AI-нагрузок, особенно для генеративного AI. Для бенчмаркинга был выбран режим vGPU, чтобы показать еще один вариант развертывания, доступный заказчикам в VCF 9.0.

Функциональность vGPU, интегрированная с VCF, предоставляет ряд преимуществ для развертывания и управления AI-инфраструктурой. Во-первых, VCF формирует группы устройств из 2, 4 или 8 GPU с использованием NVLink и NVSwitch. Эти группы могут выделяться различным виртуальным машинам, обеспечивая гибкость распределения GPU-ресурсов в соответствии с требованиями нагрузок и повышая утилизацию GPU.

Во-вторых, vGPU позволяет нескольким виртуальным машинам совместно использовать GPU-ресурсы на одном хосте. Каждой ВМ выделяется часть памяти GPU и/или вычислительных ресурсов GPU в соответствии с профилем vGPU. Это дает возможность нескольким небольшим нагрузкам совместно использовать один GPU, исходя из их требований к памяти и вычислениям, что повышает плотность консолидации, максимизирует использование ресурсов и снижает затраты на развертывание AI-инфраструктуры.

В-третьих, vGPU обеспечивает гибкое управление дата-центрами с GPU, поддерживая приостановку/возобновление работы виртуальных машин и VMware vMotion (примечание: vMotion поддерживается только в том случае, если AI-нагрузки не используют функцию Unified Virtual Memory GPU).

И наконец, vGPU позволяет различным GPU-ориентированным нагрузкам (таким как AI, графика или другие высокопроизводительные вычисления) совместно использовать одни и те же физические GPU, при этом каждая нагрузка может быть развернута в отдельной гостевой операционной системе и принадлежать разным арендаторам в мультиарендной среде.

VMware запускала нагрузки MLPerf Inference 5.1 на сервере Dell PowerEdge XE9680 с восемью GPU NVIDIA SXM H200 с 141 ГБ HBM3e при использовании VCF 9.0.0. Виртуальным машинам в тестах была выделена лишь часть ресурсов bare metal. В таблице ниже представлены аппаратные конфигурации, использованные для выполнения нагрузок MLPerf Inference 5.1 на системах bare metal и в виртуализированной среде.

Аппаратное и программное обеспечение для Dell PowerEdge XE9680:

Результаты MLPerf Inference 5.1, представленные в таблице, демонстрируют высокую производительность для больших языковых моделей (Llama 3.1 405B и Llama 2 70B), а также для задач генерации изображений (SDXL — Stable Diffusion).

Результаты MLPerf Inference 5.1 при использовании 8x vGPU в VCF 9.0 на аппаратной платформе Dell PowerEdge XE9680 с 8x GPU NVIDIA H200:

На рисунке ниже сравниваются результаты MLPerf Inference 5.1 в VCF с результатами Dell на bare metal на том же сервере Dell PowerEdge XE9680 с GPU H200. Результаты как Broadcom, так и Dell находятся в открытом доступе на сайте MLCommons. Поскольку Dell представила только результаты для Llama 2 70B, на рисунке 2 показано сравнение производительности MLPerf Inference 5.1 в VCF 9.0 и на bare metal именно для этих нагрузок. Диаграмма демонстрирует, что разница в производительности между VCF и bare metal составляет всего 1–2%.

Сравнение производительности виртуализированных и bare metal ML/AI-нагрузок на Dell XE9680 с 8x GPU H200 SXM 141 ГБ:

Производительность MLPerf Inference 5.1 в VCF с процессорами Intel Xeon 6-го поколения

Intel и Broadcom совместно продемонстрировали возможности VCF, ориентированные на заказчиков, использующих исключительно процессоры Intel Xeon со встроенным ускорением AMX для AI-нагрузок. В тестах запускали нагрузки MLPerf Inference 5.1, включая Llama 3.1 8B, DLRM-V2, R-GAT, Whisper и RetinaNet, на системе, представленной в таблице ниже.

Аппаратное и программное обеспечение для систем Intel

AI-нагрузки, особенно модели меньшего размера, могут эффективно выполняться на процессорах Intel Xeon с ускорением AMX в среде VCF, достигая производительности, близкой к bare metal, и одновременно получая преимущества управляемости и гибкости VCF. Это делает процессоры Intel Xeon отличной отправной точкой для организаций, начинающих свой путь в области AI, поскольку они могут использовать уже имеющуюся инфраструктуру.

Результаты MLPerf Inference 5.1 при использовании процессоров Intel Xeon в VCF показывают производительность на уровне bare metal. В сценариях, где в датацентре отсутствуют ускорители, такие как GPU, или когда AI-нагрузки менее вычислительно требовательны, в зависимости от задач заказчика, AI/ML-нагрузки могут быть развернуты на процессорах Intel Xeon в VCF с преимуществами виртуализации и при сохранении производительности на уровне bare metal, как показано на рисунке ниже:

Бенчмарки MLPerf Inference

Каждый бенчмарк определяется набором данных (Dataset) и целевым уровнем качества (Quality Target). В следующей таблице приведено краткое описание бенчмарков, входящих в данную версию набора тестов (официальные правила остаются первоисточником):

В сценарии Offline генератор нагрузки (LoadGen) отправляет все запросы в тестируемую систему (SUT) в самом начале прогона. В сценарии Server LoadGen отправляет новые запросы в SUT в соответствии с распределением Пуассона. Это показано в таблице ниже.

Сценарии тестирования MLPerf Inference:

Источник: MLPerf Inference: Datacenter Benchmark Suite Results, раздел «Scenarios and Metrics».

Заключение

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

При использовании GPU виртуализированные конфигурации виртуальных машин в наших бенчмарках задействуют лишь часть ресурсов CPU и памяти, при этом обеспечивая производительность MLPerf Inference 5.1 на уровне bare metal даже при пиковом использовании GPU — это одно из ключевых преимуществ виртуализации. Такой подход позволяет задействовать оставшиеся ресурсы CPU и памяти для выполнения других нагрузок с полной изоляцией, снизить стоимость AI/ML-инфраструктуры и использовать преимущества виртуализации VCF при управлении датацентрами.

Результаты бенчмарков показывают, что VCF 9.0 находится в «зоне Златовласки» для AI/ML-нагрузок, обеспечивая производительность, сопоставимую с bare metal. VCF также упрощает управление и быструю обработку нагрузок благодаря использованию vGPU, гибких NVLink-соединений между устройствами и технологий виртуализации, позволяющих применять AI/ML-инфраструктуру для графики, обучения и инференса. Виртуализация снижает совокупную стоимость владения (TCO) AI/ML-инфраструктурой, обеспечивая совместное использование дорогостоящих аппаратных ресурсов несколькими арендаторами.

Серверная платформа виртуализации VMware Cloud Foundation (VCF 9) обеспечивает непревзойдённые преимущества для инфраструктуры виртуальных рабочих столов (VDI). Даже после выделения бизнес-группы VMware End User Computing (EUC) в состав отдельной компании Omnissa основы этого комплексного решения остаются неизменными. Однако выпуск VCF 9.0 заслуживает повторного рассмотрения этих основ, чтобы показать, насколько устойчивой остаётся платформа.

VCF 9.0 объединяет основу частного облака (vSphere, vSAN, NSX) с облачной автоматизацией (VCF Automation), интегрированным Kubernetes (VMware vSphere Kubernetes Service / VKS) и другими передовыми сервисами для VCF, такими как VMware Private AI Services и VMware Data Services Manager (DSM). Эти и многие другие инновации работают совместно с решением Omnissa Horizon VDI, обеспечивая изначально безопасный, оптимизированный и масштабируемый фундамент для самых требовательных виртуальных рабочих столов.

Запуск Horizon на VCF 9.0 позволяет клиентам воспользоваться полным набором сервисов единой платформы частного облака. VCF предоставляет домены рабочих нагрузок, оркестрированные обновления, сетевую изоляцию на основе VPC и современный API потребления. Это платформа, которая рассматривает рабочие столы как полноправные рабочие нагрузки.

Безопасность и соответствие требованиям

Безопасность — это то, где VCF сразу проявляет свои сильные стороны. Используйте межсетевой экран NSX, чтобы применить политику наименьших привилегий к Horizon Connection Server, UAG и пулу рабочих столов без направляющего трафик hairpin-маршрута через внешние файрволы. Конструкции VPC в VCF 9.0 позволяют создавать воспроизводимый сетевой периметр для каждой функции Horizon:

• Edge (UAG)
• Brokering (Connection Servers)
• Рабочие столы
• Общие сервисы

Эти меры защиты масштабируются вместе с инфраструктурой, а не усложняют её. VCF 9.0 также представляет комплекс встроенных функций безопасности и соответствия требованиям, критически важных для VDI-сред:

• Централизованное управление сетевыми политиками с NSX усиливает защиту латерального трафика для чувствительных VDI-рабочих столов, соответствуя строгим регуляторным требованиям.
• Микросегментация и изоляция VPC позволяют привязывать политики к объектам, а не подсетям, что повышает устойчивость в продакшене и упрощает аудит.
• Неизменяемые (immutable) снапшоты, защита от вымогателей и интегрированное аварийное восстановление с vSAN ESA и VMware Live Recovery обеспечивают непрерывность бизнеса и быстрое восстановление после атак или сбоев, что критично для поддержания доступности рабочих столов и соответствия требованиям.

Для отраслей с жёсткими нормами (здравоохранение, финансы, госучреждения) сертификации безопасности VCF (TLS 1.3, FIPS 140-3, DISA STIG) позволяют рабочим средам соответствовать самым строгим стандартам.

Эффективность и оптимизация ресурсов

Благодаря дедупликации хранения, расширенным механизмам управления памятью и более высокой загрузке хостов, VCF 9.0 обеспечивает значительное снижение совокупной стоимости владения (TCO). Эффективность затрат в этом контексте — это не просто «купить меньше серверов». Речь идёт о том, чтобы преобразовать каждый ресурс — вычисления, хранение, сеть и операционные накладные расходы — в большее количество продуктивных пользователей без ущерба для их опыта.

• Улучшенные коэффициенты консолидации CPU и памяти позволяют размещать больше одновременных рабочих столов на сервере, что напрямую снижает инфраструктурные расходы и упрощает масштабирование крупных развертываний.
• vSAN ESA с глобальной дедупликацией может уменьшить затраты на хранение для постоянных VDI-пулов, а фоновые операции минимизируют влияние на производительность для пользователей.
• Политики хранения vSAN могут назначаться для каждого пула, чтобы образы для сотрудников с типовыми задачами не вызывали то же потребление ресурсов хранения, что и пулы, насыщенные данными или графикой. Такая точность направляет IOPS туда, где они нужнее всего, и устраняет практику чрезмерного резервирования ресурсов «на всякий случай».

Благодаря функции Memory Tiering в VCF vSphere постоянно держит горячие страницы в DRAM и перемещает холодные на локальные NVMe, фактически используя локальные NVMe как вторичный уровень памяти. В недавних тестах Login Enterprise это позволило добиться стабильного двукратного увеличения плотности ВМ на хост. Эта возможность значительно повышает эффективность использования оборудования, позволяя запускать больше виртуальных рабочих столов на меньшей инфраструктуре.

Высокая производительность

VCF 9.0 предоставляет основу, которая делает производительность Horizon предсказуемой. Это начинается с вычислительных ресурсов: распределённый планировщик vSphere (DRS) помогает гарантировать, что динамичные пулы рабочих столов распределяются с учётом локальности NUMA по физическому кластеру. Это обеспечивает попадание выделенных vCPU на один NUMA-узел, уменьшая межсокетные переходы, снижая задержки и повышая общую плавность работы. Особенно критично это во время «штормов загрузки» (boot storms) и всплесков активности приложений.

Память

Память часто является узким местом в VDI. Как отмечалось ранее, Memory Tiering в VCF 9 увеличивает плотность без обычного негативного влияния на производительность или пользовательский опыт. Особенно это заметно для пулов с низкими требованиями к «горячей» памяти (например, рабочих мест сотрудников с типовыми задачами). Практический эффект в периоды пиков (утренние входы, массовые запуски приложений и т.д.) выражается в меньшем количестве зависаний и снижении задержек ввода.

Хранение

Благодаря vSAN (особенно архитектуре Express Storage Architecture на NVMe) вы получаете адаптированный под записи метод хранения и возможность использовать политики хранения на уровне пула рабочих столов, оптимизированные под конкретную задачу:

• RAID-1 и повышенное количество страйпов для особо требовательных пользователей
• RAID-5/6 для сотрудников с типовыми задачами
• Object-space reservations для эталонных золотых образов рабочих столов, которые испытывают серьёзную нагрузку на чтение при использовании слоёв приложений

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

Сеть

Сетевые сервисы NSX выполняются в ядре гипервизора, что позволяет избегать прогона через физическую инфраструктуру, что забирает ресурсы хоста и увеличивает задержки. В сочетании с сегментацией VPC пулы рабочих столов получают детерминированные маршруты с меньшим количеством переходов. Результат — меньше накладных расходов и больше пропускной способности для действительно важного трафика. Кроме того, NSX Distributed Firewall (лицензируется отдельно как часть VMware vDefend) может применять политику межсетевого экрана для east-west трафика прямо на pNIC хоста, исключая маршрутизацию через внешние устройства и уменьшая колебания задержек.

Графика

Horizon с NVIDIA vGPU на VCF позволяет выбирать vGPU-профили для каждого пула, сохраняя при этом преимущества DRS для оптимального размещения рабочих столов. Это означает, что можно консолидировать требовательных 3D-пользователей и более лёгкие графические задачи на одних и тех же физических хостах, поддерживая высокую утилизацию GPU.

Операции второго дня

Управление жизненным циклом и парком инфраструктуры в VCF — это мгновенное преимущество для администраторов, которым приходилось балансировать обслуживание и доступность пулов рабочих столов. VCF 9.0 оркестрирует задачи жизненного цикла платформы по доменам рабочих нагрузок, что позволяет выполнять обновления в узкие временные окна без длительных простоев и без оставления кластеров в смешанном состоянии. Это поддерживает эффективность DRS и согласованность политик хранения, обеспечивая доступность и производительность пулов рабочих столов. VCF выполняет поэтапные обновления всего стека, по домену, с проверками работоспособности и операционными процессами.

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

Сценарий использования: Developer Workbench как сервис

С VKS и дополнительным сервисом DSM организации могут подключать лёгкие сервисы на базе Kubernetes и внутренние инструменты разработки непосредственно к пулам рабочих столов разработчиков. Это превращает VDI из «удалённого рабочего стола» в управляемую платформу рабочих пространств разработчика с сервисами по запросу.

• VKS — это полноценный независимый сервис с быстрым жизненным циклом и декларативными API потребления.
• Инженеры платформ и команды разработки могут быстро развертывать среды разработчиков на базе VKS, значительно сокращая время настройки dev/test.
• Разработчики могут самостоятельно создавать пространства имен (namespaces), VKS-кластеры и получать доступ к PostgreSQL/MySQL и другим сервисам, управляемым DSM. Всё маркируется на уровне платформы с учётом стоимости, политик и требований к суверенитету данных.

Дополнительные сценарии использования

Помимо традиционных постоянных и непостоянных рабочих столов, комбинация VCF 9.0 + Omnissa Horizon открывает ряд расширенных возможностей:

• Использование растянутых или мультисайтовых архитектур для расширения VDI-сервисов между облаками VCF, поддерживая гибкое масштабирование и сценарии аварийного восстановления.
• Инженеры платформ и команды разработки могут самостоятельно и быстро разворачивать среды разработчиков на базе VKS, резко сокращая время подготовки dev/test.
• Интегрированные VMware Private AI Services и поддержка vGPU как сервиса позволяют организациям легко развертывать виртуальные рабочие столы с поддержкой AI.

Также недавно был представлен документ VMware, описывающий эталонную архитектуру «Omnissa Horizon 8 на VMware Cloud Foundation».

Эта эталонная архитектура документирует проверенный, готовый к промышленной эксплуатации дизайн для запуска Omnissa Horizon 8 на VMware Cloud Foundation (VCF). Она создана, чтобы строго ответить на простой вопрос: как сегодня максимально быстро, безопасно и экономично доставлять корпоративные виртуальные рабочие столы? Эталонная архитектура подчёркивает практическую инженерную проработку, повторяемые шаблоны и измеримые результаты, формируя схему сервиса, которую организации могут уверенно применять - будь то модернизация существующей среды Horizon или создание новой платформы.

Итоги

Даже несмотря на то, что Omnissa теперь работает как независимая компания, фундаментальные требования к облачной инфраструктурной платформе для виртуальных рабочих столов остаются неизменными: согласованная сегментация и безопасность, производительность, масштабируемость, управление жизненным циклом и возможность добавлять полезные сервисы. Именно это и обеспечивает VCF 9.0 - поэтому он остаётся лучшей основой для Horizon Desktops.

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

Компания Broadcom объявила о продвижении «открытой, расширяемой экосистемы» для VMware Cloud Foundation (VCF), с тем чтобы пользователи могли строить, подключать, защищать и расширять свои приватные облака. Цель — дать заказчикам большую свободу выбора оборудования, сетевых архитектур и софтверных компонентов при развертывании приватного облака или облачной инфраструктуры на базе VCF.

Ключевые направления:

• Расширение аппаратной сертификации (OEM/ODM)
• Внедрение открытых сетевых конструкций (EVPN, BGP, SONiC)
• Вклад в open-source проекты (например, Kubernetes и связанные)
• Усиленные партнёрства с такими игроками как Cisco Systems, Intel Corporation, OVHcloud, Supermicro Inc., SNUC.
  

Архитектура и аппаратная сертификация

VCF AI ReadyNodes и ODM self-certification

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

• Появляются новые «VCF AI ReadyNodes» — предсертифицированные серверные конфигурации с CPU, GPU и другими ускорителями, пригодные для AI-обучения и вывода (inference).
• В программе сертификации ReadyNode для ODM-партнёров теперь предусмотрена самосертификация (ODM Partner Self-Certification) через технологическую альянс-программу Broadcom Technology Alliance Program (TAP). Вся сертифицированная система обеспечена полной совместимостью с VCF и единым жизненным циклом управления VCF.
• Поддержка edge-узлов: расширена поддержка компактных, «прочностных» (rugged) серверов для индустриальных, оборонных, розничных и удалённых площадок, что позволяет разворачивать современное приватное облако ближе к точкам генерации данных.

Технические следствия:

• Возможность применять новейшие аппаратные ускорители (GPU, FPGA и др.) под VCF, с гарантией совместимости.
• Упрощение цепочки выбора оборудования: благодаря self-certification ODM могут быстрее вывезти сертифицированные узлы, заказчик — выбрать из более широкого набора.
• Edge-варианты означают, что приватные облака не ограничены классическими ЦОД-конфигурациями, а могут быть размещены ближе к источнику данных (IoT, фабрики, розница), что важно для задержки, пропускной способности, регулирования данных.
• В совокупности это снижает TCO (Total Cost of Ownership) и ускоряет модернизацию инфраструктуры. Broadcom отмечает, что Intel, OVHcloud и др. подтверждают, что это даёт меньшее время time-to-market.

Почему это важно

Для организаций, которые строят приватные облака, часто возникает проблема «запертой» инфраструктуры: если узел не сертифицирован, риск несовместимости — обновления, жизненный цикл, поддержка. Открытая сертификация даёт больший выбор и снижает зависимость от одного производителя. При этом, с учётом AI-нагрузок и edge-инфраструктуры, требования к аппаратуре растут, и важна гарантия, что выбранный сервер будет работать под VCF без сюрпризов.

Сетевые инициативы: открытые сети и EVPN

Стратегия Broadcom в отношении сети

Broadcom объявляет стратегию объединения сетевых фабрик (network fabrics) и упрощения сетевых операций в приватном облаке через стандарты EVPN и BGP. Основные моменты:

• Поддержка сетевой интероперабельности между средами приложений и сетью: применение стандарта EVPN/BGP позволяет гибче и масштабируемее организовать сетевые фабрики.
• Цель — ускорить развертывание, дать мультивендорную гибкость, сохранить существующие сетевые инвестиции.
• Совместимость с продуктом NSX (в составе VCF) и сторонними сетевыми решениями на уровне VPC-защиты, единой сетевой операционной модели, маршрутизации и видимости.
• В рамках партнёрства с Cisco: VCF переходит к поддержке EVPN и совместимости с решением Cisco Nexus One fabric, что даёт клиентам архитектурную гибкость.
• VCF Networking (NSX) поддерживает открытый NOS (network operating system) SONiC — операционную систему для сетевых коммутаторов, основанную на Linux, на многосоставном и мультивендорном оборудовании.

Технические особенности EVPN / BGP в контексте VCF

• EVPN (Ethernet VPN) обеспечивает слой 2/3 виртуализации по IP/MPLS сетям, поддерживает VXLAN, MPLS-Over-EVPN и даёт нативную мультидоменную сегментацию.
• BGP служит как протокол контрольной плоскости для EVPN, позволяет сетям в разных локациях или доменах обмениваться маршрутами VXLAN/EVPN.
• В контексте VCF нужно, чтобы сеть поддерживала мультивендорность, работу с NSX, автоматизацию и процессы жизненного цикла. С открытым стандартом EVPN/BGP графику управления можно встроить в операции DevOps, IaC (Infrastructure as Code).
• Поддержка SONiC позволяет использовать коммутаторы «commodity» с открытым NOS, снижая затраты как CAPEX, так и OPEX: модульная архитектура, контейнеризация, возможность обновлений без простоя.

Значение для заказчика

• Возможность построить приватное облако, где сеть не является узким местом или «чёрным ящиком» вендора, а открытa и гибка по архитектуре.
• Снижение риска vendor-lock-in: можно выбирать разное сетевое оборудование, переключаться между вендорами и сохранять совместимость.
• Повышенная скорость развертывания: сертифицированные интеграции, открытые стандарты, меньше ручной настройки.
• Поддержка edge-сценариев и распределённых облаков: сетевые фабрики могут распространяться по ЦОД, филиалам, edge-узлам с единым контролем и видимостью.

Вклад в открытое программное обеспечение (Open Source)

Broadcom подчёркивает свою активность как участника сообщества облачных нативных технологий. Основные пункты:

• Компания является одним из пяти крупнейших долгосрочных контрибьюторов в Cloud Native Computing Foundation (CNCF) и вносит изменения/улучшения в проекты: Antrea, Cluster API, containerd, Contour, etcd, Harbor и другие.
• Важная веха: решение vSphere Kubernetes Service (VKS) от VMware теперь является Certified Kubernetes AI Conformant Platform — это означает, что платформа соответствует требованиям для AI-нагрузок и встроена в стандарты Kubernetes.

Техническое значение

• Совместимость с Kubernetes-экосистемой означает, что приватные облака на VCF могут использовать облачно-нативные модели: контейнеры, микро-сервисы, CI/CD, GitOps.
• AI Conformant сертификация даёт уверенность, что платформа поддерживает стандартизированную среду для AI-нагрузок (модели, фреймворки, инфраструктура).
• Работа с такими компонентами как containerd, etcd, Harbor облегчает создание, хранение, оркестрацию контейнеров и сбор образов, что важно для DevOps/DevSecOps практик.
• Интеграция с открытым стеком упрощает автоматизацию, ускоряет выход новых функций, увеличивает портируемость и мобильность рабочих нагрузок.

Пользовательские выгоды

• Организации получают возможность не просто виртуализировать нагрузки, но и расширяться в направлении «контейнеров + AI + edge».
• Более лёгкий перенос рабочих нагрузок между средами, снижение необходимости в проприетарных решениях.
• Возможность быстро реагировать на изменение требований бизнеса: добавление AI-сервиса, изменение инфраструктуры, использование микросервисов.

Практические сценарии применения

Приватное облако с AI-нагрузками

С сертифицированными AI ReadyNodes и поддержкой Kubernetes + AI Conformant платформой, заказчики могут:

• Развернуть приватное облако для обучения моделей машинного обучения/AI (CPU + GPU + ускорители) на базе VCF.
• Вывести inference-нагрузки ближе к источнику данных — например, на edge-узле в фабрике или розничном магазине.
• Использовать унифицированный стек: виртуальные машины + контейнеры + Kubernetes на одной платформе.
• Выполнить модернизацию инфраструктуры с меньшими затратами, за счёт сертификации и ПО с открытыми стандартами.

Развёртывание edge-инфраструктуры

С расширением поддержки edge-оптимизированных узлов:

• Приватное облако может распространяться за пределы ЦОД — например, на фабрики, сеть розничных точек, удалённые площадки.
• Сеть EVPN/BGP + SONiC позволяет обеспечить единое управление и видимость сетевой фабрики, даже если часть инфраструктуры находится далеко от центра.
• Заказчики в индустрии, госсекторе, рознице могут использовать эту архитектуру для низкой задержки, автономной работы, гибкой интеграции в основной ЦОД или облако.

Гетерогенная инфраструктура и мультивендорные сети

• Благодаря открытым стандартам и сертификации, заказчики не ограничены выбором одного поставщика оборудования или сети.
• Можно комбинировать разные серверные узлы (от разных OEM/ODM), разные коммутаторы и сетевой софт, и быть уверенным в интеграции с VCF.
• Это помогает снизить зависимость от единственного вендора, сделать инфраструктуру более гибкой и адаптивной к будущим изменениям.

Последствия и рекомендации

Последствия для рынка и архитектуры приватных облаков

• Увеличится конкуренция среди аппаратных и сетевых поставщиков, так как сертификация и сами архитектуры становятся более открытыми.
• Уменьшается риск «запирания» заказчиков в единой экосистеме производителя. Это способствует более быстрому внедрению инноваций: ускорители, AI-узлы, edge.
• Открытые сети и стандарты означают повышение скорости развертывания, уменьшение сложности и затрат.
• Часто частные облака превращаются в гибридные либо распределённые модели, где части инфраструктуры находятся в ЦОД, на edge, в филиалах — и такие архитектуры становятся проще благодаря инициативам Broadcom/VCF.

Что стоит учесть пользователям

• При выборе инфраструктуры приватного облака важно проверять сертифицированные конфигурации VCF ReadyNodes, чтобы быть уверенным в поддержке жизненного цикла, обновлений и совместимости.
• Если планируется AI-нагрузка — уделите внимание использованию AI ReadyNodes, поддержке GPU/ускорителей, сертификации.
• Если сеть критична (например, распределённые локации, филиалы, edge) — рассмотрите архитектуры EVPN/BGP, совместимые с NSX и мультивендорными решениями, а также возможности SONiC.
• Не забывайте об автоматизации и интеграции с облачно-нативными технологиями (Kubernetes, контейнеры, CI/CD): наличие поддержки этих технологий позволяет быстрее развивать платформу.
• Оцените TCO не только с точки зрения CAPEX (серверы, оборудование) но и OPEX (обслуживание, обновления, гибкость). Использование открытых стандартов и сертифицированных решений может снизить оба.

Заключение

Объявление Broadcom о «открытой экосистеме» для VMware Cloud Foundation — это важный шаг к тому, чтобы приватные облака стали более гибкими, адаптивными и ориентированными на будущее. Сертификация аппаратуры (в том числе для AI и edge), открытые сетевые стандарты и активный вклад в open-source проекты – всё это создаёт технологическую платформу, на которой организации могут строить современные инфраструктуры.

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

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

Недавно VMware объявила, что предприятия теперь могут развертывать NVIDIA Run:ai с встроенной службой VMware vSphere Kubernetes Services (VKS) — стандартной функцией в VMware Cloud Foundation (VCF). Это поможет предприятиям достичь оптимального использования GPU с NVIDIA Run:ai, упростить развертывание Kubernetes и поддерживать как контейнеризованные нагрузки, так и виртуальные машины на VCF. Таким образом, можно запускать AI- и традиционные рабочие нагрузки на единой платформе.

Давайте посмотрим, как клиенты Broadcom теперь могут развертывать NVIDIA Run:ai на VCF, используя VMware Private AI Foundation with NVIDIA, чтобы развертывать кластеры Kubernetes для AI, максимизировать использование GPU, упростить операции и разблокировать GenAI на своих приватных данных.

NVIDIA Run:ai на VCF

Хотя многие организации по умолчанию запускают Kubernetes на выделенных серверах, такой DIY-подход часто приводит к созданию изолированных инфраструктурных островков. Это заставляет ИТ-команды вручную создавать и управлять службами, которые VCF предоставляет из коробки, лишая их глубокой интеграции, автоматизированного управления жизненным циклом и устойчивых абстракций для вычислений, хранения и сетей, необходимых для промышленного AI. Именно здесь платформа VMware Cloud Foundation обеспечивает решающее преимущество.

vSphere Kubernetes Service — лучший способ развертывания Run:ai на VCF

Наиболее эффективный и интегрированный способ развертывания NVIDIA Run:ai на VCF — использование VKS, предоставляющего готовые к корпоративному использованию кластеры Kubernetes, сертифицированные Cloud Native Computing Foundation (CNCF), полностью управляемые и автоматизированные. Затем NVIDIA Run:ai развертывается на этих кластерах VKS, создавая единую, безопасную и устойчивую платформу от аппаратного уровня до уровня приложений AI.

Ценность заключается не только в запуске Kubernetes, но и в запуске его на платформе, решающей базовые корпоративные задачи:

• Снижение совокупной стоимости владения (TCO) с помощью VCF: уменьшение инфраструктурных изолятов, использование существующих инструментов и навыков без переобучения, единое управление жизненным циклом всех инфраструктурных компонентов.
• Единые операции: основаны на привычных инструментах, навыках и рабочих процессах с автоматическим развертыванием кластеров и GPU-операторов, обновлениями и управлением в большом масштабе.
• Запуск и управление Kubernetes для большой инфраструктуры: встроенный, сертифицированный CNCF Kubernetes runtime с полностью автоматизированным управлением жизненным циклом.
• Поддержка в течение 24 месяцев для каждой минорной версии vSphere Kubernetes (VKr) - это снижает нагрузку при обновлениях, стабилизирует окружения и освобождает команды для фокусировки на ценности, а не на постоянных апгрейдах.
• Лучшая конфиденциальность, безопасность и соответствие требованиям: безопасный запуск чувствительных и регулируемых AI/ML-нагрузок со встроенными средствами управления, приватности и гибкой безопасностью на уровне кластеров.

Сетевые возможности контейнеров с VCF

Сети Kubernetes на «железе» часто плоские, сложные для настройки и требующие ручного управления. В крупных централизованных кластерах обеспечение надежного соединения между приложениями с разными требованиями — сложная задача. VCF решает это с помощью Antrea, корпоративного интерфейса контейнерной сети (CNI), основанного на CNCF-проекте Antrea. Он используется по умолчанию при активации VKS и обеспечивает внутреннюю сетевую связность, реализацию политик сети Kubernetes, централизованное управление политиками и операции трассировки (traceflow) с уровня управления NSX. При необходимости можно выбрать Calico как альтернативу.

Расширенная безопасность с vDefend

Разные приложения в общем кластере требуют различных политик безопасности и контроля доступа, которые сложно реализовать последовательно и масштабируемо. Дополнение VMware vDefend для VCF расширяет возможности безопасности, позволяя применять сетевые политики Antrea и микросегментацию уровня «восток–запад» вплоть до контейнера. Это позволяет ИТ-отделам программно изолировать рабочие нагрузки AI, конвейеры данных и пространства имен арендаторов с помощью политик нулевого доверия. Эти функции необходимы для соответствия требованиям и предотвращения горизонтального перемещения в случае взлома — уровень детализации, крайне сложный для реализации на физических коммутаторах.

Высокая отказоустойчивость и автоматизация с VMware vSphere

Это не просто удобство, а основа устойчивости инфраструктуры. Сбой физического сервера, выполняющего многодневное обучение, может привести к значительным потерям времени. VCF, основанный на vSphere HA, автоматически перезапускает такие рабочие нагрузки на другом узле.

Благодаря vMotion возможно обслуживание оборудования без остановки AI-нагрузок, а Dynamic Resource Scheduler (DRS) динамически балансирует ресурсы, предотвращая перегрузки. Подобная автоматическая устойчивость отсутствует в статичных, выделенных средах.

Гибкое управление хранилищем с политиками через vSAN

AI-нагрузки требуют разнообразных типов хранения — от высокопроизводительного временного пространства для обучения до надежного объектного хранения для наборов данных. vSAN позволяет задавать эти требования (например, производительность, отказоустойчивость) индивидуально для каждой рабочей нагрузки. Это предотвращает появление новых изолированных инфраструктур и необходимость управлять несколькими хранилищами, как это часто бывает в средах на «голом железе».

Преимущества NVIDIA Run:ai

• Максимизация использования GPU: динамическое выделение, дробление GPU и приоритизация задач между командами обеспечивают максимально эффективное использование мощной инфраструктуры.
• Масштабируемые сервисы AI: поддержка развертывания больших языковых моделей (инференс) и других сложных AI-задач (распределённое обучение, тонкая настройка) с эффективным масштабированием ресурсов под изменяющуюся нагрузку.

Обзор архитектуры

Давайте посмотрим на высокоуровневую архитектуру решения:

• VCF: базовая инфраструктура с vSphere, сетями VCF (включая VMware NSX и VMware Antrea), VMware vSAN и системой управления VCF Operations.
• Кластер Kubernetes с поддержкой AI: управляемый VCF кластер VKS, обеспечивающий среду выполнения AI-нагрузок с доступом к GPU.
• Панель управления NVIDIA Run:ai: доступна как услуга (SaaS) или для локального развертывания внутри кластера Kubernetes для управления рабочими нагрузками AI, планирования заданий и мониторинга.
• Кластер NVIDIA Run:ai: развернут внутри Kubernetes для оркестрации GPU и выполнения рабочих нагрузок.
• Рабочие нагрузки data science: контейнеризированные приложения и модели, использующие GPU-ресурсы.

Эта архитектура представляет собой полностью интегрированный программно-определяемый стек. Вместо того чтобы тратить месяцы на интеграцию разрозненных серверов, коммутаторов и систем хранения, VCF предлагает единый, эластичный и автоматизированный облачный операционный подход, готовый к использованию.

Диаграмма архитектуры

Существует два варианта установки панели управления NVIDIA Run:ai:

• SaaS: панель управления размещена в облаке (см. https://run-ai-docs.nvidia.com/saas). Локальный кластер Run:ai устанавливает исходящее соединение с облачной панелью для выполнения рабочих нагрузок AI. Этот вариант требует исходящего сетевого соединения между кластером и облачным контроллером Run:ai.
• Самостоятельное размещение: панель управления Run:ai устанавливается локально (см. https://run-ai-docs.nvidia.com/self-hosted) на кластере VKS, который может быть совместно используемым или выделенным только для Run:ai. Также доступен вариант с изолированной установкой (без подключения к сети).

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

Сценарии развертывания

Сценарий 1: Установка NVIDIA Run:ai на экземпляре VCF с включенной службой vSphere Kubernetes Service

Предварительные требования:

• Среда VCF с узлами ESX, оснащёнными GPU
• Кластер VKS для AI, развернутый через VCF Automation
• GPU настроены как DirectPath I/O, vGPU с разделением по времени (time-sliced) или NVIDIA Multi-Instance GPU (MIG)

Если используется vGPU, NVIDIA GPU Operator автоматически устанавливается в рамках шаблона (blueprint) развертывания VCFA.

Основные шаги по настройке панели управления NVIDIA Run:ai:

1. Подготовьте ваш кластер VKS, назначенный для роли панели управления NVIDIA Run:ai, выполнив все необходимые предварительные условия.
2. Создайте секрет с токеном, полученным от NVIDIA Run:ai, для доступа к контейнерному реестру NVIDIA Run:ai.
3. Если используется VMware Data Services Manager, настройте базу данных Postgres для панели управления Run:ai; если нет — Run:ai будет использовать встроенную базу Postgres.
4. Добавьте репозиторий Helm и установите панель управления с помощью Helm.

Основные шаги по настройке кластера:

1. Подготовьте кластер VKS, назначенный для роли кластера, с выполнением всех предварительных условий, и запустите диагностический инструмент NVIDIA Run:ai cluster preinstall.
2. Установите дополнительные компоненты, такие как NVIDIA Network Operator, Knative и другие фреймворки в зависимости от ваших сценариев использования.
3. Войдите в веб-консоль NVIDIA Run:ai, перейдите в раздел Resources и нажмите "+New Cluster".
4. Следуйте инструкциям по установке и выполните команды, предоставленные для вашего кластера Kubernetes.

Преимущества:

• Полный контроль над инфраструктурой
• Бесшовная интеграция с экосистемой VCF
• Повышенная надежность благодаря автоматизации vSphere HA, обеспечивающей защиту длительных AI-тренировок и серверов инференса от сбоев аппаратного уровня — критического риска для сред на «голом железе».

Сценарий 2: Интеграция vSphere Kubernetes Service с существующими развертываниями NVIDIA Run:ai

Почему именно vSphere Kubernetes Service:

• Управляемый VMware Kubernetes упрощает операции с кластерами
• Тесная интеграция со стеком VCF, включая VCF Networking и VCF Storage
• Возможность выделить отдельный кластер VKS для конкретного приложения или этапа — разработка, тестирование, продакшн

Шаги:

1. Подключите кластер(ы) VKS к существующей панели управления NVIDIA Run:ai, установив кластер Run:ai и необходимые компоненты.
2. Настройте квоты GPU и политики рабочих нагрузок в пользовательском интерфейсе NVIDIA Run:ai.
3. Используйте возможности Run:ai, такие как автомасштабирование и разделение GPU, с полной интеграцией со стеком VCF.

Преимущества:

• Простота эксплуатации
• Расширенная наблюдаемость и контроль
• Упрощённое управление жизненным циклом

Операционные инсайты: преимущество "Day 2" с VCF

Наблюдаемость (Observability)

В средах на «железе» наблюдаемость часто достигается с помощью разрозненного набора инструментов (Prometheus, Grafana, node exporters и др.), которые оставляют «слепые зоны» в аппаратном и сетевом уровнях. VCF, интегрированный с VCF Operations (часть VCF Fleet Management), предоставляет единую панель мониторинга для наблюдения и корреляции производительности — от физического уровня до гипервизора vSphere и кластера Kubernetes.

Теперь в системе появились специализированные панели GPU для VCF Operations, предоставляющие критически важные данные о том, как GPU и vGPU используются приложениями. Этот глубокий AI-ориентированный анализ позволяет гораздо быстрее выявлять и устранять узкие места.

Резервное копирование и восстановление (Backup & Disaster Recovery)

Velero, интегрированный с vSphere Kubernetes Service через vSphere Supervisor, служит надежным инструментом резервного копирования и восстановления для кластеров VKS и pod’ов vSphere. Он использует Velero Plugin for vSphere для создания моментальных снапшотов томов и резервного копирования метаданных напрямую из хранилища Supervisor vSphere.

Это мощная стратегия резервирования, которая может быть интегрирована в планы аварийного восстановления всей AI-платформы (включая состояние панели управления Run:ai и данные), а не только бездисковых рабочих узлов.

Итог: Bare Metal против VCF для корпоративного AI

NVIDIA Run:ai на VCF ускоряет корпоративный ИИ

Развертывание NVIDIA Run:ai на платформе VCF позволяет предприятиям создавать масштабируемые, безопасные и эффективные AI-платформы. Независимо от того, начинается ли внедрение с нуля или совершенствуются уже существующие развертывания с использованием VKS, клиенты получают гибкость, высокую производительность и корпоративные функции, на которые они могут полагаться.

VCF позволяет компаниям сосредоточиться на ускорении разработки AI и повышении отдачи от инвестиций (ROI), а не на рискованной и трудоемкой задаче построения и управления инфраструктурой. Она предоставляет автоматизированную, устойчивую и безопасную основу, необходимую для промышленных AI-нагрузок, позволяя NVIDIA Run:ai выполнять свою главную задачу — максимизировать использование GPU.

В примере показано, как среда, использующая Aria Suite Lifecycle Manager и Aria Operations, переходит на новую версию платформы. Процесс начинается с обновления Aria Lifecycle Manager до версии 8.18 Patch 2 или выше. Затем с его помощью выполняется апгрейд Aria Operations до VCF Operations 9.0, что автоматически разворачивает новый компонент — VCF 9 Fleet Management Appliance.

После обновления сервисов Aria обновляется сама инфраструктура vSphere: выполняется переход на VLCM images, обновляются vCenter Server и хосты ESX до версии 9.0.

На следующем этапе используется установщик VMware Cloud Foundation, который скачивает необходимые бинарные файлы и проводит обновление среды до VCF 9.0. В ходе этого процесса выполняется консолидация существующих компонентов vCenter Server и VCF Operations в единый VCF Management Domain. Установщик также автоматически разворачивает Operations Collector, VMware NSX, настраивает SDDC Manager и при необходимости устанавливает модуль VCF Automation (его можно добавить позже через Fleet Management Appliance).

После завершения обновления выполняется повторное лицензирование среды под VCF 9.0, а также ряд действий после обновления: развёртывание VCF Logs, настройка внешнего vCenter Identity Broker, включение VCF SSO, связывание нескольких серверов vCenter и установка дополнительных модулей, включая Operations for Networks и HCX.

Видео демонстрирует комплексный процесс перехода на новую версию VMware Cloud Foundation и подчёркивает преимущества глубокой интеграции и автоматизации в экосистеме VMware.

Thomas Kopton написал интересный пост о получении паролей из VCF Fleet Manager на примере для прокси VMware VCF Operations Cloud.

Одно из преимуществ всеобъемлющего решения частного облака, такого как VMware Cloud Foundation (VCF), заключается в уровне автоматизации, который оно предоставляет. VCF стремится упростить ваши операции - от автоматической установки или обновления прокси-серверов VCF Operations Cloud до управления критически важными паролями, такими как пароль пользователя root в VCF Fleet Manager. Но что делать, если вам всё же нужен этот пароль root? Как его получить?

В этом посте рассказывается, как получить доступ к паролям, хранящимся в защищённом хранилище VCF Fleet Manager, на примере пользователя root для прокси-сервера VCF Operations Cloud.

Пароли VCF Fleet Manager

В VCF Fleet Manager раздел Fleet Management Passwords представляет собой решение VCF для автоматизированного и безопасного управления учётными данными. Он централизует, генерирует и управляет критически важными паролями (например, для прокси-серверов VCF Operations Cloud) в защищённом хранилище, снижая количество ручных операций и повышая безопасность в частном облаке.

Хотя Fleet Manager управляет паролями для критически важных компонентов в фоновом режиме, обычно вы не сможете напрямую «извлечь» существующие пароли в открытом виде через его интерфейс. Вместо этого функция Fleet Management Passwords предназначена для проактивного управления этими учётными данными. Это означает, что вы можете обновлять или восстанавливать пароли при необходимости. Если вам нужно восстановить доступ к системе, пароль которой управляется VCF, для этого используется определённый процесс на основе REST API — а не простое извлечение данных из хранилища.

Fleet Management API

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

На следующем скриншоте показано, как получить доступ к интерфейсу Swagger UI для VCF Fleet Management.

В API Explorer мы можем выбрать между публичным и приватным API, как показано на следующем скриншоте:

Получение пароля

Процесс извлечения пароля, хранящегося в защищённом хранилище VCF (в данном примере пароля пользователя root для прокси VCF Operations Cloud) включает три этапа:

1. Авторизация
2. Получение vmid сохранённых учётных данных
3. Извлечение расшифрованного пароля

Авторизация

Авторизация в Swagger UI выполняется быстро. При нажатии соответствующей кнопки открывается диалоговое окно, ожидающее ввода строки Basic Auth, закодированной в Base64. Необходимо закодировать комбинацию User:Password и ввести её в виде строки "Basic xxxxxxx", как показано в примере ниже.

Важно: здесь мы работаем с private-internal-api.

admin@local:VMware123!
Basic YWRtaW5AbG9jYWw6Vk13YXJlMTIzIQ==

На следующем скриншоте показан процесс авторизации в интерфейсе Swagger UI:

Получение списка паролей

Далее нам нужно получить список доступных учётных данных и найти в нём наш Cloud Proxy, чтобы получить vmid. Этот идентификатор необходим для завершающего шага.

Для тестов в рамках этой статьи используется инфраструктура VCF 9.0.1. REST-запрос, который мы будем использовать, находится в разделе v3 контроллера Locker Password Controller. На следующем изображении показан вызов типа GET.

Разумеется, для этого мы можем использовать Postman или просто curl, как показано здесь:

curl -X GET "https://flt-fm01.rainpole.io/lcm/locker/api/v3/passwords?limit=10" -H "accept: application/json" -H "Authorization: Basic YWxxxIQ=="

Теперь нам нужно просмотреть тело ответа JSON, чтобы найти наш Cloud Proxy. Параметр vmid будет одним из ключей в соответствующей записи.

{
      "vmid": "b4b63007-6e32-4462-9b0f-b9330e307eaf",
      "alias": "VCF-sfo-opsc01.sfo.rainpole.io-rootUserPassword",
      "userName": "root",
      "passwordDescription": null,
      "type": "node",
      "status": "active",
      "createdOn": 1753204380982,
      "lastUpdatedOn": 1753204380982,
      "lastValidatedOn": null,
      "reference": {
        "envId": "b5dcc1a4-8d66-4e83-be24-ef4180b7dd27",
        "envName": "b5dcc1a4-8d66-4e83-be24-ef4180b7dd27",
        "productId": "vrops",
        "hostName": "sfo-opsc01.sfo.rainpole.io",
        "ip": "10.11.10.38",
        "nodeType": "cloudproxy",
        "referenceId": "be49027a-16c8-469a-9285-3ad93f2d62ce"
      }

Расшифровка пароля

Заключительный шаг — выполнить запрос к эндпоинту /lcm/locker/api/v2/passwords/{vmid}/decrypted. Это POST-запрос, в котором параметр vmid передаётся в URL, а в теле JSON указывается root-пароль Fleet Manager. На следующем скриншоте показан этот запрос в интерфейсе Swagger.

И вот команда curl:

curl -X POST "https://flt-fm01.rainpole.io/lcm/locker/api/v2/passwords/b4b63007-6e32-4462-9b0f-b9330e307eaf/decrypted" -H "accept: application/json" -H "Authorization: Basic YWRtaW5AbG9jYWw6Vk13QHJlMSFWTXdAcmUxIQ==" -H "Content-Type: application/json" -d "{ \"rootPassword\": \"mysecretpw\"}"

В итоге мы получим наш root-пароль для Cloud Proxy в теле ответа JSON:

{
"passwordVmid": "b4b63007-6e32-4462-9b0f-b9330e307eaf",
"password": "i#M7rq0qqw234W@hz76456&g5VEKf3p"
}

Компания Broadcom объявляет о завершении общего периода поддержки (End of General Support, EOGS) для указанных ниже пакетов управления VCF Operations Management Packs, которые были доступны ранее через VCF Solutions Catalog (ранее VMware Marketplace).

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

Альтернативные способы интеграции этих технологий с VCF Operations приведены ниже (если применимо).

Дополнительная информация

Так как указанные пакеты управления переведены в статус EOGS, они больше недоступны для загрузки в каталоге решений VCF Solutions Catalog и на портале поддержки Broadcom.

Diagnostics for VMware Cloud Foundation — это централизованная платформа, которая отслеживает общее состояние работы программного стека VMware Cloud Foundation (VCF). Это платформа самообслуживания, помогающая анализировать и устранять неполадки компонентов VMware Cloud Foundation, включая vCenter, ESX, vSAN, а также возможностей, таких как vSphere vMotion, снапшоты, развертывание виртуальных машин (VM provisioning), и других аспектов, включая уведомления безопасности и сертификаты. Администратор инфраструктуры может использовать диагностические данные, чтобы контролировать текущее состояние своей среды.

Диагностические результаты (Findings)

Результаты диагностики, которые ранее предоставлялись через Skyline Advisor и Skyline Health Diagnostics, теперь доступны клиентам VCF и vSphere Foundation (VVF) в рамках продукта VCF Operations. Результаты приоритизируются по:

• Часто встречающимся проблемам, выявленным службой технической поддержки Broadcom.
• Вопросам, поднятым в рамках анализа эскалаций (post escalation review).
• Уязвимостям безопасности.
• Проблемам, выявленным инженерными командами Broadcom.
• Рекомендациям от клиентов.

В последнем релизе VCF Operations выпущено 114 новых диагностических результатов (Findings):

• 83 — основаны на часто встречающихся проблемах.
• 15 — по результатам анализа эскалаций.
• 14 — связаны с уязвимостями безопасности (VMSA).
• 2 — по запросам клиентов.

Из них:

• 62 результата состояния (Health Findings) — эквивалентны результатам Skyline Advisor и автоматически проверяются каждые 4 часа.
• 52 результата на основе логов (Log-based Findings) — эквивалентны Skyline Health Diagnostics и инициируются вручную через интерфейс конфигурации.

Эти новые находки включены в VCF Operations 9.0.1 (Release Notes). Давайте посмотрим на некоторые примеры этих результатов.

Уязвимости безопасности

В VMSA-2025-0010 описана уязвимость аутентифицированного выполнения команд в VMware vCenter Server (CVE-2025-41225) и уязвимость межсайтового скриптинга (XSS) в VMware ESXi и vCenter Server (CVE-2025-41228). Злоумышленник, обладающий привилегиями для создания или изменения тревог (alarms) и выполнения действий сценариев (script action), может воспользоваться данной уязвимостью для выполнения произвольных команд на сервере vCenter.

Злоумышленник, имеющий сетевой доступ к странице входа определённого хоста ESX или к путям URL сервера vCenter Server, может использовать эту уязвимость для кражи cookie-файлов или перенаправления пользователей на вредоносные веб-сайты. Эта уязвимость устранена в vCenter Server 8.0 Update 3e.

Анализ после эскалации (Post Escalation Review)

Техническая поддержка Broadcom внедрила процесс Post Escalation Review, в рамках которого критические обращения анализируются для предотвращения подобных инцидентов в будущем. Одним из результатов такого анализа является создание новых диагностических результатов.

Например, KB #370670:

Хосты ESX могут терять подключение к vCenter из-за чрезмерной скорости логирования, что приводит к потере сообщений syslog и невозможности записи сервисных логов. Часто проблема наблюдается при включении дополнительного логирования NSX, когда файл dfwpktlogs.log превышает допустимую скорость записи syslog. Однако причиной может быть и любая другая служба, создающая чрезмерный объём логов. Данный результат отображается при появлении соответствующих сообщений в vmkernel.log на хосте ESX.

Часто встречающиеся проблемы (Trending Issues)

KB 383273:

На хостах ESXi 8.0.2 и 8.0.3 фиксируются предупреждения “Miss counters detected” для драйверов Mellanox с ошибкой

nmlx5_QueryNicVportContext:188 command failed: IO was aborted.

Это известная ошибка в механизме проверки состояния драйвера, при которой NIC ошибочно определяется как неисправный. Исправлено в ESX 8.0 Update 3e (драйвер nmlx5 версии 4.23.6.5).

KB 318712:

Во время выполнения VCF Operations for Logs Query хост ESX сообщает о состоянии Permanent Device Loss (PDL). В Storage View хранилище отображается как недоступное, а адаптер сообщает об утере связи с устройством (Lost Communication). Все пути к устройству помечаются как «мертвые» (All Paths Down, APD). В результате невозможно подключиться к хосту через vSphere Client, и хост отображается как Disconnected в vCenter. Данный результат фиксируется при обнаружении соответствующих сообщений в vmkernel.log.

Находки, предложенные клиентами (Findings Nominated)

Главная цель команды Diagnostics — удовлетворённость клиентов. VMware стремится защитить их инфраструктуру, предоставляя результаты, основанные на опыте работы службы поддержки Broadcom, также принимаются предложения и от пользователей.

Так, например, появилась KB #385443:

На узлах vSAN происходит PSOD (Purple Screen of Death) из-за «зависших» операций ввода-вывода после сбоя диска. Команда ввода-вывода помечается как «застрявшая», а когда она завершается, соответствующие объекты уже освобождены, что вызывает сбой. Исправлено в ESX 8.0 Update 3e.

Чтобы ознакомиться со всеми диагностическими результатами в Diagnostics for VMware Cloud Foundation, откройте Findings Catalog в разделе Diagnostics Findings интерфейса VCF Operations. Для получения актуальных обновлений подпишитесь на Diagnostics for VMware Cloud Foundation Findings KB — он обновляется при каждом выпуске нового пакета или обновлении встроенных диагностических данных.

Команда поддержки VMware в Broadcom полностью привержена тому, чтобы помочь клиентам в процессе обновлений. Поскольку дата окончания общего срока поддержки VMware vSphere 7 наступила 2 октября 2025 года, многие пользователи обращаются к вендору в поисках лучших практик и пошаговых руководств по обновлению. И на этот раз речь идет не только об обновлениях с VMware vSphere 7 до VMware vSphere 8. Наблюдается активный рост подготовки клиентов к миграции с vSphere 7 на VMware Cloud Foundation (VCF) 9.0.

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

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

• Подготовка к обновлению
• Последовательность и порядок выполнения апгрейда
• Необходимые действия после переезда и миграции

Ниже приведен набор статей базы знаний об обновлениях, с которым настоятельно рекомендуется ознакомиться до проведения обновления инфраструктуры vSphere и других компонентов платформы VCF.

• Обновление VMware Cloud Foundation (VCF) 4.x и 5.x
• Обновление ESXi 7.x до 8.x или установка ESXi
• Обновление vCenter Server 7.0 до 8.0
• Обновление до VMware vSAN 8
• Обновление до VMware Live Site Recovery 9.0
• Обновление до vSphere Replication 9.0
• Обновление до Aria Automation 8.18.x
• Обновление до Aria Suite Lifecycle 8.18
• Обновление до Aria Operations for Logs 8.18.x
• Обновление до Aria Operations 8.18.x
• Обновление Aria Operations for Network через графический интерфейс
• Обновление до VMware Cloud Director 10.6
• Обновление HCX
• Обновление NSX

В VMware Cloud Foundation (VCF) 9.0 был представлен ряд новых и интересных функций и возможностей, которые помогают клиентам создавать гибкое, производительное и безопасное самообслуживаемое частное облако. В рамках стратегии частного облака крайне важно обеспечить способ потребления базовых инфраструктурных сервисов и быструю доставку приложений при одновременном управлении политиками и контролем.

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

Ниже представлен обзор некоторых основных сервисов, таких как сервисы виртуальных машин и Kubernetes, а также применение к ним политик ресурсов IaaS. Политики ресурсов помогают обеспечивать соответствие конфигураций, например размеров кластеров. Настройки безопасности, такие как применение базового уровня безопасности подов или запрет на развертывание определённых ресурсов, — лишь несколько таких примеров использования политик ресурсов.

Выбор моделей потребления

С VCF администраторы организаций могут выбирать, как изолировать пользователей и ресурсы, используя такие конструкции, как организации (тенанты), проекты, пространства имён и т. д. Потребители, такие как разработчики и команды приложений, также могут выбирать способ потребления. На графике ниже показаны два основных метода: каталог самообслуживания и UI/CLI.

Единая платформа для создания и управления приложениями

VMware Cloud Foundation — это единая платформа для создания и управления приложениями и сервисами для всей организации (тенантов). ИТ-команды могут запускать и управлять разнообразными рабочими нагрузками, включая AI/ML и облачные нативные приложения. Команды могут использовать современный интерфейс (UI + код) для упрощения развертывания таких сервисов, как базы данных и виртуальные машины. Сервисы каталога предоставляют способ формировать набор приложений, которые пользователи могут запрашивать.

Администраторы могут расширять набор сервисов VCF дополнительными службами, которые могут понадобиться пользователям для их рабочих нагрузок. vSphere Supervisor создаёт управляющую точку Kubernetes на гипервизоре, что позволяет развертывать виртуальные машины и кластеры на базе Kubernetes, а также другие сервисы. Типы сервисов варьируются в зависимости от реестра образов, сервисов резервного копирования, сервисов баз данных, кластеров Kubernetes и многого другого!

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

• vSphere Kubernetes Service: позволяет пользователям легко использовать стандартизированные, соответствующие требованиям кластеры Kubernetes, обеспечивая единообразие во всех контейнеризированных средах.
• VM Service: даёт пользователям возможность самостоятельно создавать виртуальные машины без необходимости прямого доступа к vSphere Client, упрощая создание ВМ наряду с рабочими процессами Kubernetes.

Развёртывание ВМ и кластеров VKS

Начнём с VM Service, который предоставляет современный метод потребления виртуальных машин. Используя декларативные манифесты Kubernetes YAML, пользователи могут развертывать и управлять виртуальными машинами вместе с кластерами Kubernetes. Команды разработчиков приложений, например, могут захотеть запускать виртуальные машины рядом с подами Kubernetes. Это также обеспечивает единообразный способ предоставления ресурсов для команд приложений во всём парке VCF.

Виртуальная машина разворачивается с помощью vmoperator, который представляет собой определение CRD: VM Operator. Например, для развертывания виртуальной машины может использоваться такой манифест Kubernetes:

apiVersion: vmoperator.vmware.com/v1alpha4
metadata:
kind: VirtualMachine
  name: my-vm
spec:
  className:    my-vm-class
  imageName:    vmi-0a0044d7c690bcbea
  storageClass: my-storage-class
  bootstrap:
    cloudInit:
      cloudConfig: {}

Приведённый выше манифест Kubernetes может быть создан с нуля и, например, использован в качестве шаблона, либо пользователи могут создать его с помощью интуитивно понятного интерфейса Services UI, который также развернёт для них виртуальную машину. YAML-файл для развертывания ВМ затем можно редактировать через UI или CLI.

При использовании Services UI для развертывания кластеров VKS доступны два типа конфигурации: Default Configuration, которая автоматически заполняет ряд параметров, и Custom Configuration, позволяющая выполнить более детальную настройку. В приведённом ниже примере была выбрана Default Configuration.

Потребление и развертывание через каталог

Ранее мы упоминали, что пользователи должны иметь выбор в том, как они хотят использовать инфраструктуру и развертывать приложения. До этого мы рассмотрели метод с использованием UI, где пользователь может через интуитивно понятную форму создавать виртуальные машины, кластеры VKS и вспомогательные объекты, такие как балансировщики нагрузки.

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

• Потребление базовых IaaS-компонентов и развертывание приложений и сервисов
• Запуск ad-hoc рабочих процессов и скриптов для XaaS

Далее мы сосредоточимся на первом случае. При создании элементов каталога мы можем сначала подготовить шаблоны (blueprints). VCF 9.0 предлагает простой в использовании сервис каталога. После завершения подготовки шаблона его можно опубликовать в каталог.

Теперь, когда элемент каталога для нашего приложения доступен пользователям, администраторы организации могут захотеть применить политики к развертываниям сервисов.

Тип политики для ресурсов Kubernetes

В VCF Automation 9.0 был представлен новый тип политики ресурсов: IaaS Resource Policy. Этот тип политики обеспечивает подход policy-as-code, используя Kubernetes Validation Admission Control Policy с языком CEL.

Нажав на политику ресурсов IaaS, администраторы могут настроить политики, которые будут применяться к развертываемым объектам Kubernetes, таким как виртуальные машины VM Service и кластеры Kubernetes. В примере ниже показана политика, которая ограничивает максимум одним узлом управления/рабочим узлом в кластере Kubernetes. Существует ряд готовых шаблонов, и это один из них.

Когда пользователь пытается развернуть кластер VKS с тремя управляющими узлами, при развертывании возникает ошибка, указывающая на нарушение политики.

Политика управления доступом предотвратила развертывание из-за того, что пользователь запросил больше одного управляющего узла. Это лишь один из примеров использования нового механизма policy-as-code для ресурсов Kubernetes.

Применение и настройка политик с VCF стали намного проще. Администраторы могут предоставлять конечным пользователям гибкость и скорость в потреблении инфраструктуры без ущерба для безопасности, соответствия требованиям и организационных политик.

Введение

В современных ИТ-системах шифрование данных стало обязательным элементом защиты информации. Цель шифрования — гарантировать, что данные могут прочитать только системы, обладающие нужными криптографическими ключами. Любой, не имеющий ключей доступа, увидит лишь бессмысленный набор символов, поскольку информация надёжно зашифрована устойчивым алгоритмом AES-256. VMware vSAN поддерживает два уровня шифрования для повышения безопасности кластерного хранения данных: шифрование данных на носителях (Data-at-Rest Encryption) и шифрование данных при передаче (Data-in-Transit Encryption). Эти механизмы позволяют защитить данные как в состоянии покоя (на дисках), так и в движении (между узлами кластера). В результате vSAN помогает организациям соответствовать требованиям регуляторов и предотвращать несанкционированный доступ к данным, например, при краже носителей или перехвате сетевого трафика.

Сегодня мы расскажем о шифровании данных в платформе VMware vSAN, если вы хотите получить больше подробностей, то обратитесь к документу "vSAN Encryption Services: Understanding Encryption Offerings with vSAN using VMware Cloud Foundation 9.0".

Архитектура и компоненты vSAN Encryption Services

Компоненты решения

Архитектура шифрования vSAN включает несколько ключевых элементов: внешний или встроенный сервер управления ключами (KMS), сервер VMware vCenter, гипервизоры ESXi в составе vSAN-кластера и собственно криптографические модули в ядре гипервизора. Внешний KMS-сервер (совместимый с протоколом KMIP), либо встроенный поставщик ключей vSphere NKP, обеспечивает генерацию и хранение мастер-ключей шифрования. vCenter Server отвечает за интеграцию с KMS: именно vCenter устанавливает доверенные отношения (обмен сертификатами) с сервером ключей и координирует выдачу ключей хостам ESXi. Каждый узел ESXi, входящий в шифрованный кластер vSAN, содержит встроенный криптомодуль VMkernel (сертифицированный по требованиям FIPS), который выполняет операции шифрования и дешифрования данных на стороне гипервизора.

Распределение ключей

При включении шифрования vSAN на кластере vCenter запрашивает у KMS два ключа для данного кластера: ключ шифрования ключей (Key Encryption Key, KEK) и ключ хоста (Host Key). KEK играет роль мастер-ключа: с его помощью будут шифроваться все остальные ключи (например, ключи данных). Host Key предназначен для защиты дампов памяти (core dumps) и других служебных данных хоста. После получения этих ключей vCenter передаёт информацию о KMS и идентификаторы ключей (ID) всем хостам кластера. Каждый узел ESXi устанавливает прямое соединение с KMS (по протоколу KMIP) и получает актуальные копии KEK и Host Key, помещая их в защищённый кэш памяти.

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

Ключи данных (DEK)

Помимо вышеупомянутых кластерных ключей, каждый диск или объект данных получает свой собственный ключ шифрования данных (Data Encryption Key, DEK). В оригинальной архитектуре хранения vSAN (OSA) гипервизор генерирует уникальный DEK (алгоритм XTS-AES-256) для каждого физического диска в дисковой группе. Эти ключи оборачиваются (wrap) с помощью кластерного KEK и сохраняются в метаданных, что позволяет безопасно хранить ключи на дисках: получить «сырой» DEK можно только расшифровав его при помощи KEK. В более новой архитектуре vSAN ESA подход несколько отличается: используется единый ключ шифрования кластера, но при этом для различных объектов данных применяются уникальные производные ключи. Благодаря этому данные каждой виртуальной машины шифруются своим ключом, даже если в основе лежит общий кластерный ключ. В обоих случаях vSAN обеспечивает надёжную защиту: компрометация одного ключа не даст злоумышленнику доступа ко всему массиву данных.

Роль гипервизора и производительность

Шифрование в vSAN реализовано на уровне ядра ESXi, то есть прозрачно для виртуальных машин. Гипервизор использует сертифицированный криптографический модуль VMkernel, прошедший все необходимые проверки по стандарту FIPS 140-2 (а в новых версиях — и FIPS 140-3). Все операции шифрования выполняются с использованием аппаратного ускорения AES-NI, что минимизирует влияние на производительность системы. Опыт показывает, что нагрузка на CPU и задержки ввода-вывода при включении шифрования vSAN обычно незначительны и хорошо масштабируются с ростом числа ядер и современных процессоров. В свежей архитектуре ESA эффективность ещё выше: благодаря более оптимальному расположению слоя шифрования в стеке vSAN, для той же нагрузки требуется меньше CPU-циклов и операций, чем в классической архитектуре OSA.

Управление доступом

Стоит упомянуть, что управление шифрованием в vSAN встроено в систему ролей и привилегий vCenter. Только пользователи с особыми правами (Cryptographic administrator) могут настраивать KMS и включать/отключать шифрование на кластере. Это добавляет дополнительный уровень безопасности: случайный администратор без соответствующих привилегий даже не увидит опцию включения шифрования в интерфейсе. Разграничение доступа гарантирует, что ключи шифрования и связанные операции контролируются ограниченным кругом доверенных администраторов.

Поддерживаемые типы шифрования

Шифрование данных на носителях (vSAN Data-at-Rest Encryption)

Этот тип шифрования обеспечивает защиту всех данных, хранящихся в vSAN-датасторе. Включение функции означает, что вся информация, записываемая на диски кластера, автоматически шифруется на последнем этапе ввода-вывода перед сохранением на устройство. При чтении данные расшифровываются гипервизором прозрачно для виртуальных машин – приложения и ОС внутри ВМ не осведомлены о том, что данные шифруются. Главное назначение Data-at-Rest Encryption – обезопасить данные на случай, если накопитель будет изъят из системы (например, при краже или некорректной утилизации дисков).

Без соответствующих ключей злоумышленник не сможет прочитать информацию с отключенного от кластера диска. Шифрование «на покое» не требует специальных самошифрующихся дисков – vSAN осуществляет его программно, используя собственные криптомодули, и совместимо как с гибридными, так и полностью флэш-конфигурациями хранилища.

Принцип работы: в оригинальной реализации OSA шифрование данных происходит после всех операций дедупликации и сжатия, то есть уже на «выходе» перед записью на носитель. Такой подход позволяет сохранить эффективность экономии места: данные сначала сжимаются и устраняются дубликаты, и лишь затем шифруются, благодаря чему коэффициенты дедупликации/сжатия не страдают. В архитектуре ESA шифрование интегрировано выше по стеку – на уровне кэша – но всё равно после выполнения компрессии данных.

То есть в ESA шифрование также не препятствует сжатию. Однако особенностью ESA является то, что все данные, покидающие узел, уже зашифрованы высокоуровневым ключом кластера (что частично перекрывает и трафик между узлами – см. ниже). Тем не менее для обеспечения максимальной криптостойкости vSAN ESA по-прежнему поддерживает отдельный механизм Data-in-Transit Encryption для уникального шифрования каждого сетевого пакета.

Включение и поддержка: шифрование данных на носителях включается на уровне всего кластера vSAN – достаточно установить флажок «Data-at-Rest Encryption» в настройках служб vSAN для выбранного кластера. Данная возможность доступна только при наличии лицензии vSAN Enterprise или выше.

В традиционной архитектуре OSA шифрование можно включать как при создании нового кластера, так и на уже работающем кластере. В последнем случае vSAN выполнит поочерёдное перевоспроизведение данных с каждого диска (evacuation) и форматирование дисковых групп в зашифрованном виде, что потребует определённых затрат ресурсов и времени. В архитектуре ESA, напротив, решение о шифровании принимается только на этапе создания кластера и не может быть изменено позднее без полной перестройки хранилища. Это связано с тем, что в ESA шифрование глубоко интегрировано в работу кластера, обеспечивая максимальную производительность, но и требуя фиксации режима на старте. В обоих случаях, после включения, сервис шифрования прозрачно работает со всеми остальными функциями vSAN (в том числе со снапшотами, клонированием, vMotion и т.д.) и практически не влияет на операционную деятельность кластера.

Шифрование данных при передаче (vSAN Data-in-Transit Encryption)

Второй компонент системы безопасности vSAN – это шифрование сетевого трафика между узлами хранения. Функция Data-in-Transit Encryption гарантирует, что все данные, пересылаемые по сети между хостами vSAN, будут зашифрованы средствами гипервизора.

Это особенно важно, если сеть хранения не полностью изолирована или если требуется соответствовать строгим стандартам по защите данных в транзите. Механизм шифрования трафика не требует KMS: при включении этой опции хосты vSAN самостоятельно генерируют и обмениваются симметричными ключами для установления защищённых каналов. Процесс полностью автоматизирован и не требует участия администратора – достаточно активировать настройку в параметрах кластера.

Data-in-Transit Encryption впервые появилась в vSAN 7 Update 1 и доступна для кластеров как с OSA, так и с ESA. В случае OSA администратор может независимо включить шифрование трафика (оно не зависит от шифрования на дисках, но для полноты защиты желательно задействовать оба механизма). В случае ESA отдельного переключателя может не потребоваться: при создании кластера с шифрованием данные «на лету» фактически уже будут выходить из узлов зашифрованными единым высокоуровневым ключом. Однако, чтобы каждый сетевой пакет имел уникальный криптографический отпечаток, ESA по-прежнему предусматривает опцию Data-in-Transit (она остаётся активной в интерфейсе и при включении обеспечит дополнительную уникализацию шифрования каждого пакета). Следует учесть, что на момент выпуска vSAN 9.0 в составе VCF 9.0 шифрование трафика поддерживается только для обычных (HCI) кластеров vSAN и недоступно для т. н. disaggregated (выделенных storage-only) кластеров.

С технической точки зрения, Data-in-Transit Encryption использует те же проверенные криптомодули, сертифицированные по FIPS 140-2/3, что и шифрование данных на дисках. При активации этой функции vSAN автоматически выполняет взаимную аутентификацию хостов и устанавливает между ними защищённые сессии с помощью динамически создаваемых ключей. Когда новый узел присоединяется к шифрованному кластеру, для него генерируются необходимые ключи и он аутентифицируется существующими участниками; при исключении узла его ключи отзываются, и трафик больше не шифруется для него. Всё это происходит «под капотом», не требуя ручной настройки. В результате даже при потенциальном перехвате пакетов vSAN-трафика на уровне сети, извлечь из них полезные данные не представляется возможным.

Интеграция с KMS

Требование наличия KMS

Для использования шифрования данных на vSAN необходим сервер управления ключами (Key Management Server, KMS), совместимый со стандартом KMIP 1.1+. Исключение составляет вариант применения встроенного поставщика ключей vSphere (Native Key Provider, NKP), который появился начиная с vSphere 7.0 U2. Внешний KMS может быть программным или аппаратным (множество сторонних решений сертифицировано для работы с vSAN), но в любом случае требуется лицензия не ниже vSAN Enterprise.

Перед включением шифрования администратор должен зарегистрировать KMS в настройках vCenter: добавить информацию о сервере и установить доверие между vCenter и KMS. Обычно настройка доверия реализуется через обмен сертификатами: vCenter либо получает от KMS корневой сертификат (Root CA) для проверки подлинности, либо отправляет на KMS сгенерированный им запрос на сертификат (CSR) для подписи. В результате KMS и vCenter обмениваются удостоверяющими сертификатами и устанавливают защищённый канал. После этого vCenter может выступать клиентом KMS и запрашивать ключи.

В конфигурации с Native Key Provider процесс ещё проще: NKP разворачивается непосредственно в vCenter, генерируя мастер-ключ локально, поэтому внешний сервер не нужен. Однако даже в этом случае рекомендуется экспортировать (зарезервировать) копию ключа NKP во внешнее безопасное место, чтобы избежать потери ключей в случае сбоя vCenter.

Запрос и кэширование ключей

Как только доверие (trust) между vCenter и KMS установлено, можно активировать шифрование vSAN на уровне кластера. При этом vCenter от имени кластера делает запрос в KMS на выдачу необходимых ключей (KEK и Host Key) и распределяет их идентификаторы хостам, как описано выше. Каждый ESXi узел соединяется с KMS напрямую для получения своих ключей. На период нормальной работы vSAN-хосты обмениваются ключами с KMS напрямую, без участия vCenter.

Это означает, что после первоначальной настройки для ежедневной работы кластера шифрования доступность vCenter не критична – даже если vCenter временно выключен, хосты будут продолжать шифровать/расшифровывать данные, используя ранее полученные ключи. Однако vCenter нужен для проведения операций управления ключами (например, генерации новых ключей, смены KMS и пр.). Полученные ключи хранятся на хостах в памяти, а при наличии TPM-модуля – ещё и в его защищённом хранилище, что позволяет пережить перезагрузку хоста без немедленного запроса к KMS.

VMware настоятельно рекомендует оснащать все узлы vSAN доверенными платформенными модулями TPM 2.0, чтобы обеспечить устойчивость к отказу KMS: если KMS временно недоступен, хосты с TPM смогут перезапускаться и монтировать зашифрованное хранилище, используя кешированные в TPM ключи.

Лучшие практики KMS

В контексте vSAN есть важное правило: не размещать сам KMS на том же зашифрованном vSAN-хранилище, которое он обслуживает. Иначе возникает круговая зависимость: при отключении кластера или перезагрузке узлов KMS сам окажется недоступен (ведь он работал как ВМ на этом хранилище), и хосты не смогут получить ключи для расшифровки датасторов.

Лучше всего развернуть кластер KMS вне шифруемого кластера (например, на отдельной инфраструктуре или как облачный сервис) либо воспользоваться внешним NKP от другого vCenter. Также желательно настроить кластер из нескольких узлов KMS (для отказоустойчивости) либо, в случае NKP, надёжно сохранить резервную копию ключа (через функцию экспорта в UI vCenter).

При интеграции с KMS крайне важна корректная сетевая настройка: все хосты vSAN-кластера должны иметь прямой доступ к серверу KMS (обычно по протоколу TLS на порт 5696). В связке с KMS задействуйте DNS-имя для обращения (вместо IP) – это упростит перенастройку в случае смены адресов KMS и снизит риск проблем с подключением.

vSphere Native Key Provider

Этот встроенный механизм управления ключами в vCenter заслуживает отдельного упоминания. NKP позволяет обойтись без развертывания отдельного KMS-сервера, что особенно привлекательно для небольших компаний или филиалов. VMware поддерживает использование NKP для шифрования vSAN начиная с версии 7.0 U2. По сути, NKP хранит мастер-ключ в базе данных vCenter (в зашифрованном виде) и обеспечивает необходимые функции выдачи ключей гипервизорам. При включении шифрования vSAN с NKP процесс выдачи ключей аналогичен: vCenter генерирует KEK и распределяет его на хосты. Разница в том, что здесь нет внешнего сервера – все операции выполняются средствами самого vCenter.

Несмотря на удобство, у NKP есть ограничения (например, отсутствие поддержки внешних интерфейсов KMIP для сторонних приложений), поэтому для крупных сред на долгосрочной основе часто выбирают полноценный внешний KMS. Тем не менее, NKP – это простой способ быстро задействовать шифрование без дополнительных затрат, и он идеально подходит для многих случаев использования.

Процесс шифрования и дешифрования

Запись данных (шифрование)

После того как кластер vSAN сконфигурирован для шифрования и получены необходимые ключи, каждая операция записи данных проходит через этап шифрования в гипервизоре. Рассмотрим упрощённо этот процесс на примере OSA (Original Storage Architecture):

• Получение блока данных. Виртуальная машина записывает данные на диск vSAN, которые через виртуальный контроллер поступают на слой vSAN внутри ESXi. Там данные сначала обрабатываются сервисами оптимизации – например, вычисляются хеши для дедупликации и выполняется сжатие (если эти функции включены на кластере).
• Шифрование блока. Когда очередь дошла до фактической записи блока на устройство, гипервизор обращается к ключу данных (DEK), связанному с целевым диском, и шифрует блок по алгоритму AES-256 (режим XTS) с помощью этого DEK. Как упоминалось, в OSA у каждого диска свой DEK, поэтому даже два диска одного узла шифруют данные разными ключами. Шифрование происходит на уровне VMkernel, используя AES-NI, и добавляет минимальную задержку.
• Запись на устройство. Зашифрованный блок записывается в кеш или напрямую на SSD в составе дисковой группы. На носитель попадают только зашифрованные данные; никакой незашифрованной копии информации на диске не сохраняется. Метаданные vSAN также могут быть зашифрованы или содержать ссылки на ключ (например, KEK_ID), но без владения самим ключом извлечь полезную информацию из зашифрованного блока невозможно.

В архитектуре ESA процесс схож, с тем отличием, что шифрование происходит сразу после сжатия, ещё на высокоуровневом слое ввода-вывода. Это означает, что данные выходят из узла уже шифрованными кластерным ключом. При наличии Data-in-Transit Encryption vSAN накладывает дополнительное пакетное шифрование: каждый сетевой пакет между хостами шифруется с использованием симметрических ключей сеанса, которые регулярно обновляются. Таким образом, данные остаются зашифрованы как при хранении, так и при передаче по сети, что создаёт многослойную защиту (end-to-end encryption).

Чтение данных (дешифрование)

Обратный процесс столь же прозрачен. Когда виртуальная машина запрашивает данные из vSAN, гипервизор на каждом затронутом хосте находит нужные зашифрованные блоки на дисках и считывает их. Прежде чем передать данные наверх VM, гипервизор с помощью соответствующего DEK выполняет расшифровку каждого блока в памяти. Расшифрованная информация проходит через механизмы пост-обработки (восстановление сжатых данных, сборка из дедуплицированных сегментов) и отправляется виртуальной машине. Для ВМ этот процесс невидим – она получает привычный для себя блок данных, не зная, что на физическом носителе он хранится в зашифрованном виде. Если задействовано шифрование трафика, то данные могут передаваться между узлами в зашифрованном виде и расшифровываются только на том хосте, который читает их для виртуальной машины-потребителя.

Устойчивость к сбоям

При нормальной работе все операции шифрования/дешифрования происходят мгновенно для пользователя. Но стоит рассмотреть ситуацию с потенциальным сбоем KMS или перезагрузкой узла. Как отмечалось ранее, хосты кэшируют полученные ключи (KEK, Host Key и необходимые DEK) в памяти или TPM, поэтому кратковременное отключение KMS не влияет на работающий кластер.

Виртуальные машины продолжат и читать, и записывать данные, пользуясь уже загруженными ключами. Проблемы могут возникнуть, если перезагрузить хост при недоступном KMS: после перезапуска узел не сможет получить свои ключи для монтирования дисковых групп, и его локальные компоненты хранилища останутся офлайн до восстановления связи с KMS. Именно поэтому, как уже упоминалось, рекомендуется иметь резервный KMS (или NKP) и TPM-модули на узлах, чтобы повысить отказоустойчивость системы шифрования.

Управление ключами и ротация

Замена ключей (Rekey)

Безопасность криптосистемы во многом зависит от регулярной смены ключей. VMware vSAN предоставляет администраторам возможность проводить плановую ротацию ключей шифрования без простоя и с минимальным влиянием на работу кластера. Поддерживаются два режима: «мелкая» ротация (Shallow Rekey) и «глубокая» ротация (Deep Rekey). При shallow rekey генерируется новый мастер-ключ KEK, после чего все ключи данных (DEK) перешифровываются этим новым KEK (старый KEK уничтожается). Важно, что сами DEK при этом не меняются, поэтому операция выполняется относительно быстро: vSAN просто обновляет ключи в памяти хостов и в метаданных, не перестраивая все данные на дисках. Shallow rekey обычно используют для регулярной смены ключей в целях комплаенса (например, раз в квартал или при смене ответственного администратора).

Deep rekey, напротив, предполагает полную замену всех ключей: генерируются новые DEK для каждого объекта/диска, и все данные кластера постепенно перераспределяются и шифруются уже под новыми ключами. Такая операция более ресурсоёмка, фактически аналогична повторному шифрованию всего объёма данных, и может занять продолжительное время на крупных массивах. Глубокую ротацию имеет смысл выполнять редко – например, при подозрении на компрометацию старых ключей или после аварийного восстановления системы, когда есть риск утечки ключевой информации. Оба типа рекея можно инициировать через интерфейс vCenter (в настройках кластера vSAN есть опция «Generate new encryption keys») или с помощью PowerCLI-скриптов. При этом для shallow rekey виртуальные машины могут продолжать работать без простоев, а deep rekey обычно тоже выполняется онлайн, хотя и создаёт повышенную нагрузку на подсистему хранения.

Смена KMS и экспорт ключей

Если возникает необходимость поменять используемый KMS (например, миграция на другого вендора или переход от внешнего KMS к встроенному NKP), vSAN упрощает эту процедуру. Администратор добавляет новый KMS в vCenter и обозначает его активным для данного кластера. vSAN автоматически выполнит shallow rekey: запросит новый KEK у уже доверенного нового KMS и переведёт кластер на использование этого ключа, перешифровав им все старые DEK. Благодаря этому переключение ключевого сервиса происходит прозрачно, без остановки работы хранилища. Тем не менее, после замены KMS настоятельно рекомендуется удостовериться, что старый KMS более недоступен хостам (во избежание путаницы) и сделать резервную копию конфигурации нового KMS/NKP.

При использовании vSphere Native Key Provider важно регулярно экспортировать зашифрованную копию ключа NKP (через интерфейс vCenter) и хранить её в безопасном месте. Это позволит восстановить доступ к зашифрованному vSAN, если vCenter выйдет из строя и потребуется его переустановка. В случае же аппаратного KMS, как правило, достаточно держать под рукой актуальные резервные копии самого сервера KMS (или использовать кластер KMS из нескольких узлов для отказоустойчивости).

Безопасное удаление данных

Одним из побочных преимуществ внедрения шифрования является упрощение процедуры безопасной утилизации носителей. vSAN предлагает опцию Secure Disk Wipe для случаев, когда необходимо вывести диск из эксплуатации или изъять узел из кластера. При включенной функции шифрования проще всего выполнить «очистку» диска путем сброса ключей: как только DEK данного носителя уничтожен (либо кластерный KEK перегенерирован), все данные на диске навсегда остаются в зашифрованном виде, то есть фактически считаются стёртыми (так называемая криптографическая санация).

Кроме того, начиная с vSAN 8.0, доступна встроенная функция стирания данных в соответствии со стандартами NIST (например, перезапись нулями или генерация случайных шаблонов). Администратор может запустить безопасное стирание при выведении диска из кластера – vSAN приведёт накопитель в состояние, удовлетворяющее требованиям безопасной утилизации, удалив все остаточные данные. Комбинация шифрования и корректного удаления обеспечивает максимальную степень защиты: даже физически завладев снятым накопителем, злоумышленник не сможет извлечь конфиденциальные данные.

Поддержка FIPS и совместимость

Соответствие стандартам (FIPS)

VMware vSAN Encryption Services были разработаны с учётом строгих требований отраслевых стандартов безопасности. Криптографический модуль VMkernel, на котором основано шифрование vSAN, прошёл валидацию FIPS 140-2 (Cryptographic Module Validation Program) ещё в 2017 году. Это означает, что реализация шифрования в гипервизоре проверена независимыми экспертами и отвечает критериям, предъявляемым правительственными организациями США и Канады.

Более того, в 2024 году VMware успешно завершила сертификацию модуля по новому стандарту FIPS 140-3, обеспечив преемственность соответствия более современным требованиям. Для заказчиков из сфер, где необходима сертификация (государственный сектор, финансы, медицина и т.д.), это даёт уверенность, что vSAN может использоваться для хранения чувствительных данных. Отдельно отметим, что vSAN включена в руководства по безопасности DISA STIG для Министерства обороны США, а также поддерживает механизмы двухфакторной аутентификации администраторов (RSA SecurID, CAC) при работе с vCenter — всё это подчёркивает серьёзное внимание VMware к безопасности решения.

Совместимость с функционалом vSAN

Шифрование в vSAN спроектировано так, чтобы быть максимально прозрачным для остальных возможностей хранения. Дедупликация и сжатие полностью совместимы с Data-at-Rest Encryption: благодаря порядку выполнения (сначала дедупликация/сжатие, потом шифрование) эффективность экономии места практически не снижается. Исключение составляет экспериментальная функция глобальной дедупликации в новой архитектуре ESA — на момент запуска vSAN 9.0 одновременное включение глобальной дедупликации и шифрования не поддерживается (ожидается снятие этого ограничения в будущих обновлениях).

Снапшоты и клоны виртуальных машин на зашифрованном vSAN работают штатно: все мгновенные копии хранятся в том же шифрованном виде, и при чтении/записи гипервизор так же прозрачно шифрует их содержимое. vMotion и другие механизмы миграции ВМ также поддерживаются – сама ВМ при миграции может передаваться с шифрованием (функция Encrypted vMotion, независимая от vSAN) или без него, но это не влияет на состояние ее дисков, которые на принимающей стороне всё равно будут записаны на vSAN уже в зашифрованном виде.

Резервное копирование и репликация

vSAN Encryption не накладывает ограничений на работу средств резервного копирования, использующих стандартные API vSphere (такие как VMware VADP) или репликации на уровне ВМ. Данные читаются гипервизором в расшифрованном виде выше уровня хранения, поэтому бэкап-приложения получают их так же, как и с обычного хранилища. При восстановлении или репликации на целевой кластер vSAN, естественно, данные будут записаны с повторным шифрованием под ключи того кластера. Таким образом, процессы защиты и восстановления данных (VDP, SRM, vSphere Replication и пр.) полностью совместимы с зашифрованными датасторами vSAN.

Ограничения и особенности

Поскольку vSAN реализует программное шифрование, аппаратные самошифрующиеся диски (SED) не требуются и официально не поддерживаются в роли средства шифрования на уровне vSAN. Если в серверы установлены SED-накопители, они могут использоваться, но без включения режимов аппаратного шифрования – vSAN в любом случае выполнит шифрование средствами гипервизора. Ещё один момент: при включении vSAN Encryption отключается возможность рентген-просмотра (в веб-клиенте vSAN) содержимого дисков, так как данные на них хранятся в зашифрованном виде. Однако на функциональность управления размещением объектов (Storage Policy) это не влияет. Наконец, стоит учитывать, что шифрование данных несколько повышает требования к процессорным ресурсам на хостах. Практика показывает, что современные CPU справляются с этим отлично, но при проектировании больших нагрузок (вроде VDI или баз данных на all-flash) закладывать небольшой запас по CPU будет не лишним.

Заключение

VMware vSAN Encryption Services предоставляют мощные средства защиты данных для гиперконвергентной инфраструктуры. Реализовав сквозное шифрование (от диска до сети) на уровне хранения, vSAN позволяет организациям выполнить требования по безопасности без сложных доработок приложений. Среди ключевых преимуществ решения можно отметить:

• Всесторонняя защита данных. Даже если злоумышленник получит физический доступ к носителям или перехватит трафик, конфиденциальная информация останется недоступной благодаря сильному шифрованию (AES-256) и раздельным ключам для разных объектов. Это особенно важно для соблюдения стандартов GDPR, PCI-DSS, HIPAA и других.
• Прозрачность и совместимость. Шифрование vSAN работает под управлением гипервизора и не требует изменений в виртуальных машинах. Все основные функции vSphere (кластеризация, миграция, бэкап) полностью поддерживаются. Решение не привязано к специфическому оборудованию, а опирается на открытые стандарты (KMIP, TLS), что облегчает интеграцию.
• Удобство централизованного управления. Администратор может включить шифрование для всего кластера несколькими кликами – без необходимости настраивать каждую ВМ по отдельности (в отличие от VMcrypt). vCenter предоставляет единый интерфейс для управления ключами, а встроенный NKP ещё больше упрощает старт. При этом разграничение прав доступа гарантирует, что только уполномоченные лица смогут внести изменения в политику шифрования.
• Минимальное влияние на производительность. Благодаря оптимизациям (использование AES-NI, эффективные алгоритмы) накладные расходы на шифрование невелики. Особенно в архитектуре ESA шифрование реализовано с учётом высокопроизводительных сценариев и практически не сказывается на IOPS и задержках. Отсутствуют и накладные расходы по ёмкости: включение шифрования не уменьшает полезный объём хранилища и не создаёт дублирования данных.
• Гибкость в выборе подхода. vSAN поддерживает как внешние KMS от разных поставщиков (для предприятий с уже выстроенными процессами управления ключами), так и встроенный vSphere Native Key Provider (для простоты и экономии). Администраторы могут ротировать ключи по своему графику, комбинировать или отключать сервисы при необходимости (например, включить только шифрование трафика для удалённого филиала с общим хранилищем).

При внедрении шифрования в vSAN следует учесть несколько моментов: обеспечить высокую доступность сервера KMS (или надёжно сохранить ключ NKP), активировать TPM на хостах для хранения ключей, а также не сочетать шифрование vSAN с шифрованием на уровне ВМ (VM Encryption) без крайней необходимости. Двойное шифрование не повышает безопасность, зато усложняет управление и снижает эффективность дедупликации и сжатия.

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

Компания VMware недавно объявила о первом результате теста VMmark 4 с использованием последнего релиза платформы виртуализации VMware Cloud Foundation (VCF) 9.0. Метрики, показанные системой Lenovo, также стали первым результатом тестирования новейшей 4-сокетной системы на базе процессора Intel Xeon серии 6700 с технологией Performance-cores, который обеспечивает большее количество ядер и более высокую пропускную способность памяти. Итоговый результат доступен на странице VMmark 4 Results.

В следующей таблице приведено сравнение нового результата Lenovo с системой предыдущего поколения ThinkSystem под управлением vSphere 8.0 Update 3:

График показывает рост общего количества ядер на 43% между этими двумя результатами:

С точки зрения очков производительности, показатель VMmark 4 вырос на 49%:

Ключевые моменты:

• Сочетание VCF 9.0 и нового серверного оборудования позволило запустить на 50% больше виртуальных машин / рабочих нагрузок (132) по сравнению с результатом предыдущего поколения (88 ВМ).
• Процессоры Intel Xeon 6788P в Lenovo ThinkSystem SR860 V4 имеют на 43% больше ядер, чем процессоры предыдущего поколения Intel Xeon Platinum 8490H в ThinkSystem SR860 V3
• Показатель VMmark на 49% выше, чем результат VMmark 4 для предыдущего поколения.

VMmark — это бесплатный инструмент тестирования, который используется партнёрами и клиентами для оценки производительности, масштабируемости и энергопотребления платформ виртуализации. Посетите страницу продукта VMmark и сообщество VMmark Community, чтобы узнать больше. Также вы можете попробовать VMmark 4 прямо сейчас через VMware Hands-on Labs Catalog, выполнив поиск по запросу «VMmark».

В частных облаках часто встречается несколько экземпляров vCenter Server. Это особенно характерно для сред VMware Cloud Foundation (VCF), поскольку подход к масштабированию емкостей заключается в развертывании дополнительных доменов рабочих нагрузок, включающих набор ресурсов vCenter Server, VMware ESX и VMware NSX. Администраторам облака, которым необходимо управлять рабочими нагрузками vSphere, гораздо удобнее, если они могут получать доступ к нескольким средам через единый экземпляр vSphere Client, и в прошлом для этого существовало несколько архитектурных решений.

До недавнего времени стандартным способом объединения нескольких сред vSphere был Enhanced Linked Mode (ELM), но VCF 9 представляет новый метод.

Режим Enhanced Linked Mode (ELM) всё ещё поддерживается в vSphere 9.0, но будет полностью упразднен в будущих релизах vSphere.

Новая возможность: группы vCenter

VCF 9 приносит значительные изменения в управление частным облаком, и одним из ключевых улучшений является полностью новая архитектура Single Sign-On (SSO) для бесшовного доступа к VCF Operations, vSphere Client, NSX Manager и другим компонентам. Теперь интеграция со стандартным провайдером идентификации стала проще, чем когда-либо, что позволяет предоставлять доступ отдельным администраторам VCF и, наконец, отказаться от совместного использования пароля пользователя «admin». Эта новая возможность SSO не поддерживает Enhanced Linked Mode, но, что ещё важнее, в ней и нет необходимости для обеспечения доступа к нескольким средам в одном vSphere Client.

Вместо этого в VCF Operations появилась новая упрощённая функция, позволяющая администраторам создавать группы серверов vCenter, которые автоматически связываются друг с другом. В сочетании с VCF SSO это обеспечивает плавный и бесшовный опыт управления vSphere.

Связывание vCenter Server

Чтобы связать ваши vCenter Server, в VCF Operations 9 перейдите в Infrastructure Operations > Configurations и выберите плитку vCenter Linking.

Оттуда нажмите Create Group и используйте простой мастер, чтобы выбрать серверы vCenter, которые вы хотите связать вместе.

Вход с использованием VCF SSO

После установления связи необходимо войти с помощью VCF SSO, чтобы видеть несколько сред в едином интерфейсе vSphere Client. Имейте в виду: если войти с использованием локальной учётной записи, например administrator@vsphere.local, то будет отображаться только инвентарь конкретной системы.

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

Управление средой vSphere

Когда несколько сред vSphere связаны между собой с помощью vCenter Linking, вы можете заметить, что для выполнения некоторых операций требуется выбрать конкретный сервер vCenter — имейте это в виду, чтобы избежать неожиданных сюрпризов!

Итоги

Экземпляры VMware Cloud Foundation обычно включают несколько сред vSphere. Теперь вы можете использовать новый vCenter Linking с vCenter Groups, чтобы упростить управление всей инфраструктурой — бесшовно и без использования общих паролей администратора.

Одной из новых возможностей Fleet Management, представленных в VMware Cloud Foundation (VCF) 9.0, является полностью обновлённый опыт единого входа (SSO), обеспечивающий доступ администраторов ко всем основным интерфейсам управления, таким как: VCF Operations, vSphere Client, NSX Manager и другие. Новый компонент VCF Identity Broker (VIDB) поддерживает множество современных провайдеров идентификации, а также традиционные службы каталогов. В этой статье вы узнаете, как включить и настроить SSO в среде VCF 9.

Режимы развертывания – встроенный или внешний (appliance)

Первым шагом при включении VCF SSO является выбор режима развертывания брокера идентификации. Существует два варианта: встроенный или appliance.

• Встроенный вариант интегрирован с vCenter Server в домене управления и идеально подходит для небольших сред VCF, которым не требуется масштабирование до целого пула экземпляров VCF.
• Для большей масштабируемости можно выбрать вариант appliance, который работает на небольшом кластере из трёх узлов VIDB для обеспечения отказоустойчивости. Внешний вариант может предоставлять службы идентификации для всего пула экземпляров VCF и рекомендуется для инфраструктур до пяти экземпляров VCF.

Поддержка провайдеров идентификации

После выбора режима развертывания необходимо выбрать провайдера идентификации. В VCF 9 добавлена поддержка Ping Identity и универсальных провайдеров SAML 2.0 в дополнение к Okta, Entra ID, Active Directory, OpenLDAP и другим. В зависимости от выбранного провайдера будут доступны различные варианты определения групп, которым предоставляется доступ для входа в компоненты VCF. Для уточнения конкретных требований следует обратиться к документации продукта.

Ещё одним улучшением стали методы предоставления пользователей и групп: теперь, помимо SCIM с современными провайдерами идентификации, можно использовать JIT или AD/LDAP.

Конфигурация компонентов

После настройки провайдера идентификации остаётся всего один шаг, чтобы включить VCF SSO для каждого компонента в развертывании. Настройка основных инфраструктурных компонентов — vCenter Server и NSX Manager — сводится к простому выбору опции, при этом несколько сервисов можно активировать одновременно, и процесс занимает всего несколько минут.

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

Назначение ролей

После завершения настройки VCF SSO остаётся административная задача — назначить необходимые роли для каждого компонента. Эта одноразовая операция должна выполняться с использованием локальных учётных записей администратора (например, “admin” или “administrator@vsphere.local” в случае с vCenter Server). Необходимо предоставить доступ пользователям и группам, созданным через настроенного провайдера идентификации, и назначить им соответствующие права для управления компонентами.

Процесс может отличаться в зависимости от компонента. Например, вы можете назначить группе роль Enterprise Admin, чтобы она могла управлять NSX.

Чтобы увидеть весь процесс включения доступа в полном развертывании VCF 9, посмотрите демо ниже.

Пользовательский интерфейс SDDC Manager

Особое примечание о SDDC Manager в VCF 9: этот пользовательский интерфейс считается устаревшим, но остаётся доступным, а само backend-приложение по-прежнему необходимо для выполнения некоторых задач управления инфраструктурой. В связи с этим войти в интерфейс SDDC Manager с использованием учётных данных VCF SSO невозможно — продолжайте использовать локальную учётную запись администратора, обычно administrator@vsphere.local.

Однако у SDDC Manager всё же есть конфигурация SSO, и её следует настроить для удалённого доступа к API. Это связано с тем, что после входа в vCenter Server некоторые действия, инициированные в vSphere Client, фактически выполняются SDDC Manager в фоновом режиме, и для этого потребуется аутентификация. Поэтому назначьте группе SSO, которую вы используете в vCenter Server, права администратора в SDDC Manager, чтобы обеспечить плавный и бесшовный доступ.

Практическая демонстрация

Если вы хотите увидеть полный процесс настройки VCF SSO, ознакомьтесь с этим короткой практической лабораторной работой (HOL), которая пошагово проводит через весь процесс: https://labs.hol.vmware.com/HOL/catalog/lab/26724.

Итоги

Новый релиз VMware Cloud Foundation привносит значительные изменения в рабочие процессы администраторов, особенно за счёт объединения множества административных и управленческих задач в новый интерфейс VCF Operations. Однако по-прежнему существуют специализированные консоли управления, к которым администраторам необходимо получать доступ. Теперь, благодаря VCF SSO и VIDB, переход к выполнению определённых действий в NSX Manager или vSphere Client стал значительно проще. Настройка VCF SSO лёгкая, а безопасность при этом не страдает благодаря интеграции с проверенными и надёжными провайдерами идентификации.

По мере того как организации готовятся к апгрейду на VMware Cloud Foundation (VCF) 9.0, понимание изменений в эксплуатационных процессах второго этапа (Day-2 Operations) становится критически важным для успешного перехода.

В предыдущих версиях, таких как VCF 5.2, многие административные задачи — например, создание пулов сетей, ввод хостов в эксплуатацию и развертывание доменов рабочих нагрузок — были жёстко связаны с SDDC Manager, и выполнение их за его пределами часто приводило к проблемам. VCF 9.0 вводит значительные улучшения в эксплуатационных операциях, предоставляя больше гибкости за счёт переноса многих из этих задач в более привычные инструменты, такие как VMware vCenter и VCF Operations.

Эта эволюция не только упрощает рабочие процессы, но и даёт администраторам больше прямого контроля. В этой статье мы рассмотрим 10 ключевых изменений в эксплуатации, которые организациям стоит учитывать при планировании и выполнении обновления до VCF 9.0. Хотя это не исчерпывающий список, данные рекомендации основаны на повторяющихся темах в разговорах с клиентами и опыте реальных апгрейдов.

Улучшение 1: создание, расширение и удаление сетевых пулов

В VCF 5.2 создание, расширение и удаление сетевых пулов выполнялось в SDDC Manager:

Administration -> Network Settings -> Network Pool

В VCF 9.0 эти задачи выполняются через vCenter. Для работы с сетями домена управления не требуется дополнительная конфигурация, однако необходимо использовать VCF SSO и связывание vCenter Server для доменов рабочих нагрузок.

Global Inventory List -> Hosts -> Network Pools

Улучшение 2: ввод и вывод хостов из эксплуатации для существующих или новых доменов рабочих нагрузок

В VCF 5.2 ввод/вывод хостов в эксплуатацию для существующих или новых доменов рабочих нагрузок выполнялся в SDDC Manager:

Inventory -> Hosts

В VCF 9.0 эти задачи выполняются через vCenter:

Global Inventory List -> Hosts -> Unassigned Hosts

Улучшение 3: развертывание домена рабочих нагрузок

В VCF 5.2 развертывание домена рабочих нагрузок выполнялось в SDDC Manager:

Inventory -> Workload Domains

В VCF 9.0 новые домены рабочих нагрузок развертываются через VCF Operations:

Inventory -> VCF Instance

Улучшение 4: создание и расширение кластера

В VCF 5.2 создание и расширение кластера выполнялось в SDDC Manager:

Inventory -> Workload Domains -> Clusters -> Add Cluster

или

Inventory -> Workload Domains -> Clusters -> Add Hosts -> Add Unassigned Hosts

В VCF 9.0 создание и расширение кластеров выполняется через vCenter:

Hosts and Clusters -> Datacenter Object -> New Cluster -> New SDDC Cluster

Для работы с vCenter домена управления не требуется дополнительная конфигурация, однако необходимо использовать VCF SSO и связывание vCenter Server для доменов рабочих нагрузок.

Создание кластера:

Улучшение 5: конфигурация резервного копирования VCF

В VCF 5.2 настройка резервного копирования компонентов VCF выполнялась в SDDC Manager:

Administration -> Backup

В VCF 9.0 резервное копирование настраивается через VCF Operations. Резервные копии уровня Fleet Management охватывают управляющие узлы, VCF Automation и VCF Identity Broker:

Fleet Management -> Lifecycle -> Settings -> SFTP Settings / Backup Settings

Резервные копии экземпляров VCF могут настраиваться отдельно для каждого экземпляра:

Inventory -> VCF Instance -> Actions -> Manage VCF Instance Settings -> Backup Settings

Настройки уровня парка инфраструктуры (Fleet):

Настройки инстанса VCF:

Резервное копирование SDDC Manager:

Улучшение 6: конфигурация сетевых настроек (DNS/NTP)

В VCF 5.2 настройка DNS и NTP выполнялась в SDDC Manager:

Administration -> Network Settings

В VCF 9.0 DNS и NTP настраиваются через VCF Operations:

Inventory -> VCF Instance -> Actions -> Manage VCF Instance Settings -> Network Settings

Настройки DNS:

Настройки NTP:

Улучшение 7: конфигурация центра сертификации (CA)

В VCF 5.2 настройка центра сертификации выполнялась в SDDC Manager:

Security -> Certificate Authority

В VCF 9.0 конфигурация центра сертификации выполняется в VCF Operations:

Fleet Management -> Certificates -> Configure CA

Улучшение 8: управление сертификатами

В VCF 5.2 управление сертификатами выполнялось в SDDC Manager:

Inventory -> Workload Domains -> Workload -> Certificates

В VCF 9.0 управление сертификатами (включая новую функцию автоматического продления) выполняется в VCF Operations:

Fleet Management -> Certificates -> Management

Улучшение 9: управление паролями

В VCF 5.2 управление паролями выполнялось в SDDC Manager:

Security -> Password Management

В VCF 9.0 управление паролями выполняется в VCF Operations:

Fleet Management -> Passwords

Управление VCF:

Экземпляр VCF:

Улучшение 10: развертывание кластера NSX Edge

В VCF 5.2 развертывание кластера NSX Edge выполнялось в SDDC Manager:

Inventory -> Workload Domains -> Actions -> Add Edge Cluster

В VCF 9.0 развертывание кластера NSX Edge инициируется через vCenter:

vCenter Network Object -> Network -> Network Connectivity

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

Эволюция VCF 9.0 продолжается

По мере дальнейшего развития VCF 9.0 компания Broadcom сохраняет приверженность внедрению инноваций и повышению эффективности эксплуатации во всём технологическом стеке VMware. Последний релиз подтверждает постоянные инвестиции в упрощение операций второго этапа (Day-2 Operations) за счёт более глубокой автоматизации, улучшенного управления жизненным циклом и более тесной интеграции компонентов стека.

На выступлении в рамках конференции Explore 2025 Крис Вулф объявил о поддержке DirectPath для GPU в VMware Private AI, что стало важным шагом в упрощении управления и масштабировании корпоративной AI-инфраструктуры. DirectPath предоставляет виртуальным машинам эксклюзивный высокопроизводительный доступ к GPU NVIDIA, позволяя организациям в полной мере использовать возможности графических ускорителей без дополнительной лицензионной сложности. Это упрощает эксперименты, прототипирование и перевод AI-проектов в производственную среду. Кроме того, VMware Private AI размещает модели ближе к корпоративным данным, обеспечивая безопасные, эффективные и экономичные развертывания. Совместно разработанное Broadcom и NVIDIA решение помогает компаниям ускорять инновации при снижении совокупной стоимости владения (TCO).

Эти достижения появляются в критически важный момент. Обслуживание передовых LLM-моделей (Large Language Models) — таких как DeepSeek-R1, Meta Llama-3.1-405B-Instruct и Qwen3-235B-A22B-thinking — на полной длине контекста зачастую превышает возможности одного сервера с 8 GPU и картой H100, что делает распределённый инференс необходимым. Агрегирование ресурсов нескольких GPU-узлов позволяет эффективно запускать такие модели, но при этом создаёт новые вызовы в управлении инфраструктурой, оптимизации межсерверных соединений и планировании рабочих нагрузок.

Именно здесь ключевую роль играет решение VMware Cloud Foundation (VCF). Это первая в отрасли платформа частного облака, которая сочетает масштаб и гибкость публичного облака с безопасностью, отказоустойчивостью и производительностью on-premises — и всё это с меньшей стоимостью владения. Используя такие технологии, как NVIDIA NVLink, NVSwitch и GPUDirect RDMA, VCF обеспечивает высокую пропускную способность и низкую задержку коммуникаций между узлами. Также гарантируется эффективное использование сетевых соединений, таких как InfiniBand (IB) и RoCEv2 (RDMA over Converged Ethernet), снижая издержки на коммуникацию, которые могут ограничивать производительность распределённого инференса. С VCF предприятия могут развернуть продуктивный распределённый инференс, добиваясь стабильной работы даже самых крупных reasoning-моделей с предсказуемыми характеристиками.

Этот пост о новом документе «Deploy Distributed LLM inference with GPUDirect RDMA over Infiniband in VMware Private AI», где приведены архитектурные рекомендации, детальные шаги развертывания и технические best practices для распределённого инференса LLM на нескольких GPU-узлах с использованием VCF и серверов NVIDIA HGX с GPUDirect RDMA по InfiniBand.

Основные моменты и технические детали

Использование серверов HGX для максимальной производительности

Серверы NVIDIA HGX играют центральную роль. Их внутренняя топология — PCIe-коммутаторы, GPU NVIDIA H100/H200 и адаптеры ConnectX-7 IB HCA — подробно описана. Критически важным условием для оптимальной производительности GPUDirect RDMA является соотношение GPU-к-NIC 1:1, что обеспечивает каждому ускорителю выделенный высокоскоростной канал.

Внутриузловая и межузловая коммуникация

NVLink и NVSwitch обеспечивают сверхбыструю связь внутри одного HGX-узла (до 8 GPU), тогда как InfiniBand или RoCEv2 дают необходимую пропускную способность и низкую задержку для масштабирования инференса на несколько серверов HGX.

GPUDirect RDMA в VCF

Включение GPUDirect RDMA в VCF требует особых настроек, таких как активация Access Control Services (ACS) в ESX и Address Translation Services (ATS) на сетевых адаптерах ConnectX-7. ATS позволяет выполнять прямые транзакции DMA между PCIe-устройствами, обходя Root Complex и возвращая производительность, близкую к bare metal, в виртуализированных средах.

Определение требований к серверам

В документ включена практическая методика для расчёта минимального количества серверов HGX, необходимых для инференса LLM. Учитываются такие факторы, как num_attention_heads и длина контекста, а также приведена справочная таблица с требованиями к аппаратному обеспечению для популярных моделей LLM (например, Llama-3.1-405B, DeepSeek-R1, Llama-4-Series, Kimi-K2 и др.). Так, для DeepSeek-R1 и Llama-3.1-405B при полной длине контекста требуется как минимум два сервера H00-HGX.

Обзор архитектуры

Архитектура решения разделена на кластер VKS, кластер Supervisor и критически важные Service VM, на которых работает NVIDIA Fabric Manager. Подчёркивается использование Dynamic DirectPath I/O, которое обеспечивает прямой доступ GPU и сетевых адаптеров (NIC) к рабочим узлам кластера VKS, в то время как NVSwitch передаётся в режиме passthrough к Service VM.

Рабочий процесс развертывания и лучшие практики

В документе рассмотрен 8-шаговый рабочий процесс развертывания, включающий:

• Подготовку аппаратного обеспечения и прошивок (включая обновления BIOS и firmware)
• Конфигурацию ESX для включения GPUDirect RDMA
• Развертывание Service VM
• Настройку кластера VKS
• Установку операторов (NVIDIA Network и GPU Operators)
• Процедуры загрузки хранилища и моделей
• Развертывание LLM с использованием SGLang и Leader-Worker Sets (LWS)
• Проверку после развертывания

Практические примеры и конфигурации

Приведены конкретные примеры, такие как:

• YAML-манифесты для развертывания кластера VKS с узлами-воркерами, поддерживающими GPU.
• Конфигурация LeaderWorkerSet для запуска моделей DeepSeek-R1-0528, Llama-3.1-405B-Instruct и Qwen3-235B-A22B-thinking на двух узлах HGX
• Индивидуально настроенные файлы топологии NCCL для максимизации производительности в виртуализированных средах

Проверка производительности

Приведены шаги для проверки работы RDMA, GPUDirect RDMA и NCCL в многосерверных конфигурациях. Также включены результаты тестов производительности для моделей DeepSeek-R1-0528 и Llama-3.1-405B-Instruct на 2 узлах HGX с использованием стресс-тестового инструмента GenAI-Perf.

Больше подробностей вы можете узнать из документа «Deploy Distributed LLM inference with GPUDirect RDMA over Infiniband in VMware Private AI».

Во время конференции VMware Explore 2025 к блогеру Вильяму Ламу, много пишущему о технологиях виртуализации по существу, обратился один из участников, которого заинтересовала его физическая сетевая инфраструктура и то, как всё подключено в его лабораторной среде VMware Cloud Foundation (VCF) 9.0. Сетевая схема ниже основана на вот этой спецификации оборудования (Hardware BOM — Build-of-Material) для VCF 9.0:

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

Примечание: все зелёные линии на схеме выше обозначают сетевые подключения 10 GbE, а все синие линии обозначают подключения 2.5 GbE.

Порты:

• Роутер MikroTik (слева направо): порты 1–5
• Роутер Sodola (слева направо): порты 1–6

Подключения портов:

• Порт 1 на MikroTik подключен к интернет-аплинку
  Это необходимо, если вам требуется исходящее подключение для установки/загрузки пакетов в вашу среду.
• Порты 2–4 на MikroTik подключены к 3 x MS-A2 через первый порт 10GbE SFP+
  ESXi определит первый SFP+ порт как vmnic1.
• Порт 5 на MikroTik подключен к порту 6 (10GbE SFP+) на коммутаторе Sodola
  Настроен как транковый VLAN (802.1Q), который будет передавать все VLAN’ы, определённые на MikroTik.
• Порт 1 на Sodola подключен к настольному iMac
  Настроен как нетегированный VLAN, и конкретно для сети Management, чтобы можно было получить доступ ко всем системам.
• Порт 2 на Sodola подключен к ASUS NUC 14
  Настроен как транковый VLAN (802.1Q) для дополнительного хоста с рабочими нагрузками VCF Workload Domain.
• Порт 5 на Sodola подключен к Synology NAS
  Настроен как тегированный VLAN для доступа к VCF Offline Depot.
• Порты 3–4 на Sodola не используются и доступны для расширения системы.

Более подробно о тестовой лаборатории Вильяма можно почитать вот тут.

На конференции VMware Explore 2025 компания Broadcom объявила, что службы VMware Private AI Services теперь входят в стандартную поставку VMware Cloud Foundation 9.0 (VCF 9.0). То есть VCF превращается в полноценную AI-native платформу частного облака: из коробки доступны (или будут доступны) сервисы для работы с моделями, наблюдаемость за GPU, среда исполнения для моделей и агент-фреймворк, плюс дорожная карта с MCP, multi-accelerator и AI-ассистентом для VCF.

Платформа VCF 9.0 уже находится в статусе General Availability и доступна с июня 2025, а выход служб Private AI Services в составе подписки планируется к началу первого квартала 2026 финансового года Broadcom.

Давайте посмотрим на состав и функции VMware Private AI Services:

Слой AI-сервисов в VCF 9.0

Что «входит по умолчанию» в Private AI Services (становится частью подписки VCF 9.0):

• GPU Monitoring — телеметрия и наблюдаемость графических карт.
• Model Store — репозиторий и версионирование моделей.
• Model Runtime — сервисный слой для развертывания/экспонирования моделей (endpoints).
• Agent Builder — сборка/оркестрация «агентов» поверх LLM.
• Vector Database & Data Indexing/Retrieval — индексация корпоративных данных и RAG-потоки.
  

Эти возможности поставляются как native services платформы, а не «надстройка» — и это важная архитектурная деталь: AI становится частью инфраструктуры, живущей в тех же сущностных/безопасностных доменах, что и виртуальные машины и контейнеры.

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

• Intelligent Assist for VCF — LLM-ассистент для диагностики и самопомощи в VCF (пока как tech preview для on-prem/air-gapped и cloud-моделей).
• Model Context Protocol (MCP) — стандартная, управляемая интеграция ассистентов с инструментами и БД (Oracle, MSSQL, ServiceNow, GitHub, Slack, PostgreSQL и др.).
• Multi-accelerator Model Runtime — единая среда исполнения для AMD и NVIDIA GPU без переработки приложений; поддержка NVIDIA Blackwell, B200, ConnectX-7/BlueField-3 с технологией Enhanced DirectPath I/O.
• Multi-tenant Models-as-a-Service — безопасное шаринг-использование моделей между пространствами имен/линиями бизнеса.

Ядро VCF 9.0: что поменялось в самой платформе

Единая операционная плоскость

VCF 9.0 переносит фокус на «One interface to operate» (VCF Operations) и «One interface to consume» (VCF Automation): единая модель политик, API и общий движок жизненного цикла. Это снижает расхождение инструментов и обучаемость. На практике это дает унифицированное управление инфраструктурой, health/patch/compliance из одной консоли, централизованные функции IAM/SSO/сертификатов, анализ корреляции логов и другие возможности.

Примеры экранов и функций, доступных в VCF Operations: обзор по всем инстансам, геокарта, статус сертификатов с автообновлением, NetOps-дэшборды (NSX health, VPC, flows), интеграция Live Recovery и LogAssist.

Слой потребления (для разработчиков/проектных команд)

• GitOps (Argo CD) как встроенная модель доставки, Istio Service Mesh для zero-trust/observability трафика, единый контроль политик по проектам.
• vSphere Kubernetes Service (VKS) — функции enterprise-K8s, доступные прямо из VCF.
• Native vSAN S3 Object Store — S3-совместимый API хранилища объектов на vSAN, без внешних лицензий/модулей.

Все это — официальные «новые в 9.0» элементы, влияющие на скорость доставки сервисов и безопасность.

Производительность и эффективность

• NVMe Memory Tiering — расширение оперативной памяти за счет NVMe для высокочастотных/in-memory нагрузок.
• vSAN Global Deduplication (ESA) — постпроцессинговая глобальная дедупликация на уровне кластера.
• Улучшенные data paths + опциональный DPU offload — снижение задержек в east-west контуре, предсказуемость отклика.

• Security Operations Dashboard - непрерывный compliance-сканер (CIS/NIST/кастомные baselines), identity & cert management, «drift»-контроль.
• Встроенные chargeback/showback и cost dashboards (TCO-прозрачность, прогнозирование, возврат/reclaim неиспользуемых ресурсов).

Аппаратные улучшения/сетевой стек для AI

VCF 9.0 выравнивает работу «больших» AI-нагрузок на частной инфраструктуре:

• Поддержка NVIDIA Blackwell (включая RTX PRO 6000 Blackwell Server Edition, B200, HGX с NVSwitch), GPUDirect RDMA/Storage, Enhanced DirectPath I/O - при этом сохраняются «классические» возможности vSphere (vMotion, HA, DRS, Live Patching).
• Совместная работа с AMD: ROCm Enterprise AI и Instinct MI350 для задач fine-tuning/RAG/inference. Это не «плагин», а интегрированная часть VCF и экосистемы VMware Private AI Foundation with NVIDIA.

Как это интегрируется в вашм бизнес-процессы

Типовые сценарии, которые теперь проще закрывать «из коробки»:

• Models-as-a-Service: реестр -> развертывание -> публикация endpoint-ов -> контроль версий/квот -> многоарендность.
• Агенты поверх LLM: ускоренный старт с Agent Builder + подключение к корпоративным данным через индексирование/вектора.
• RAG-потоки с политиками и аудитом: источники данных под управлением VCF, контроль доступа на уровне платформы, видимость (observability).
• Доставка сервисов K8s: GitOps (Argo CD), сервис-меш (Istio), S3-объекты на vSAN для артефактов/данных.

Лицензирование/доставка и пути обновления

• GA: VCF 9.0 доступен с 17 июня 2025.
• Службы Private AI Services обещаны как часть подписки VCF 9.0 в Q1 FY26 от Broadcom.
• Официальный документ с фичами и путями миграции VCF <-> VVF 9.0 доступен тут.

Вывод

VCF 9.0 — это не просто «еще одна» версия с оптимизациями. За счет включения Private AI Services в базовую платформу и сдвига на «one interface to operate/consume», VCF превращает AI-нагрузки в основу частного облака, сохраняя корпоративные политики, комплаенс и привычные SRE-процессы — от GPU до GitOps.

Введение глобальной дедупликации в vSAN для VMware Cloud Foundation (VCF) 9.0 открывает новую эру эффективности использования пространства в vSAN. Применение современных технологий оптимизации хранения позволяет разместить больше данных, чем это физически возможно при традиционных способах хранения, помогая извлечь максимум из уже имеющихся ресурсов.

Однако дедупликация в vSAN для VCF 9.0 — это не просто долгожданная функция в поиске идеального решения для хранения данных. Новый подход использует распределённую архитектуру vSAN и повышает её способность к дедупликации данных по мере роста размера кластера. Кроме того, эта технология отлично сочетается с моделью лицензирования VCF, которая включает хранилище vSAN в состав вашей лицензии.

Благодаря этому глобальная дедупликация vSAN становится более эффективной с точки зрения экономии пространства и значительно доступнее, чем использование VCF с другими решениями для хранения данных. Если рассматривать совокупную стоимость владения (TCO), как описано далее, то использование VCF с vSAN обходится до 34% дешевле, чем VCF с конкурирующим хранилищем в инфраструктуре с 10 000 ядрами. По внутренним оценкам VMware, в этой же модели одна только глобальная дедупликация vSAN может снизить общую стоимость VCF до 4% — что примерно соответствует 10 миллионам долларов! Давайте посмотрим, как особенности глобальной дедупликации vSAN могут помочь сократить расходы на ваше виртуальное частное облако с использованием VCF.

Измерение эффективности

Чтобы правильно понять преимущества дедупликации, необходимо иметь метод оценки её эффективности. Эффективность дедупликации обычно выражается в виде коэффициента, показывающего объём данных до дедупликации и после неё. Чем выше коэффициент, тем больше экономия ёмкости. Такой коэффициент также может отображаться без «:1» — например, вместо «4:1» будет показано «4x».

Хотя коэффициент дедупликации легко понять, к сожалению, системы хранения могут измерять его по-разному. Некоторые показывают эффективность дедупликации только как общий коэффициент «сжатия данных», включая в него такие методы, как сжатие данных, клонирование и выделение пространства под тонкие (thin) тома. Другие могут отображать коэффициенты дедупликации, исключая метаданные и другие накладные расходы, которые не учитываются в измерении. Это важно понимать, если вы сравниваете эффективность дедупликации между системами хранения.

На эффективность дедупликации в системе хранения влияет несколько факторов, включая, но не ограничиваясь:

• Архитектурой системы дедупликации. Системы хранения часто проектируются с учётом компромиссов между эффективностью и затратами, что и определяет разные подходы к дедупликации.
• Размером/гранулярностью дедупликации. Это единица данных, по которой осуществляется поиск дубликатов. Чем меньше гранулярность, тем выше вероятность нахождения совпадений.
• Объёмом данных в пределах домена дедупликации. Обычно, чем больше объём данных, тем выше вероятность, что они будут дедуплицированы с другими данными.
• Сходством данных. Единица данных должна полностью совпадать с другой единицей, прежде чем дедупликация принесёт пользу. Иногда приложения могут использовать шифрование или другие методы, которые снижают возможность дедупликации данных.
• Характеристиками данных и рабочих нагрузок. Данные, создаваемые приложением, могут быть более или менее благоприятны для дедупликации. Например, структурированные данные, такие как OLTP-базы, обычно содержат меньше потенциальных дубликатов, чем неструктурированные данные.

Последние два пункта относятся к рабочим нагрузкам и наборам данных, уникальным для клиента. Именно они часто объясняют, почему одни данные лучше поддаются дедупликации, чем другие. Но при этом архитектура системы хранения играет ключевую роль в эффективности дедупликации. Может ли она выполнять дедупликацию с минимальным вмешательством в рабочие нагрузки? Может ли выполнять её с высокой степенью детализации и в широком домене дедупликации для максимальной эффективности? Глобальная дедупликация vSAN была разработана для обеспечения лучших результатов при минимальном влиянии на рабочие процессы.

Простой внутренний тест продемонстрировал превосходство архитектуры vSAN. На массиве конкурента было создано 50 полных клонов, и столько же — на vSAN. С учётом возможностей дедупликации и сжатия массив показал общий коэффициент сжатия данных 41.3 к 1. vSAN достиг коэффициента 45.27 к 1. Это наглядно демонстрирует впечатляющую эффективность дедупликации vSAN, усиленную сжатием данных для ещё большей экономии. Хотя этот пример не является репрезентативным для показателей дедупликации на произвольных наборах данных, он демонстрирует эффективность дедупликации в vSAN.

Масштабирование ради повышения эффективности

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

Традиционные модульные массивы хранения, как правило, не были изначально спроектированы как распределённые масштабируемые решения. Их домен дедупликации обычно ограничен одним массивом. Когда клиенту необходимо масштабироваться путём добавления ещё одного массива, домен дедупликации разделяется. Это означает, что идентичные данные могут находиться на двух разных массивах, но не могут быть дедуплицированы между ними, поскольку домен дедупликации не увеличивается при добавлении нового хранилища.

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

На рисунке ниже показан этот пример:

• Слева изображён традиционный модульный массив хранения, обеспечивающий коэффициент дедупликации 6:1. Если добавить ещё один массив, каждый из них по отдельности может обеспечить тот же коэффициент 6:1, но система теряет возможность дедуплицировать данные между массивами.
• Справа показан кластер vSAN из 6 хостов, обеспечивающий коэффициент дедупликации 6:1. По мере добавления новых хостов любые данные, размещённые на этих хостах, входят в тот же домен дедупликации, что и исходные 6 хостов. Это означает, что коэффициент дедупликации будет увеличиваться по мере добавления хостов и роста общего объёма данных.

Использование того, что уже есть

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

Модель лицензирования vSAN в составе VCF в сочетании с глобальной дедупликацией vSAN образует выигрышную комбинацию. Каждая лицензия на ядро VCF включает 1 TiB «сырой» ёмкости vSAN. Но благодаря глобальной дедупликации весь объём, который удалось освободить, напрямую работает в вашу пользу!

Например, кластер vSAN из 6 хостов, каждый из которых содержит по 32 ядра, предоставит 192 TiB хранилища vSAN в рамках лицензирования VCF. Если этот кластер обеспечивает коэффициент дедупликации 6:1, то можно хранить почти 1.2 PiB данных, используя только имеющуюся лицензию.

Реальная экономия затрат

Когда хранилище предоставляется как часть лицензии VCF, логично, что затраты на хранение снижаются, поскольку требуется меньше дополнительных покупок. В примере ниже мы сравниваем эффективную цену за 1 ТБ при использовании VCF с конкурентным массивом хранения с дедупликацией для обслуживания рабочих нагрузок уровня Tier-1 и при использовании vSAN с VCF 9.0.

Так как наборы данных представляли собой структурированные данные (SQL), коэффициенты сжатия были весьма скромными. Однако, исходя из модели с 10 000 ядер VCF при предполагаемом уровне загрузки CPU и стоимости лицензирования:

• Эффективная цена за ТБ уже на 14% ниже при использовании только сжатия данных в vSAN.
• А при использовании дедупликации и сжатия в vSAN стоимость хранения (цена за ТБ) становится ниже на 29%.

По собственным оценкам VMware, совокупная стоимость владения (TCO) для VCF может быть снижена до 34%.

Для этого сравнения также рассматривалась среда с 10 000 ядер VCF при предполагаемом уровне загрузки CPU и стоимости лицензирования. Даже с учётом дополнительных расходов на стороннее решение для резервного копирования, стоимость хранения в vSAN оказалась на 13% ниже за каждый терабайт.

Если вы заинтересованы попробовать эту функцию в релизе P01 VCF 9.0, вы можете связаться с Broadcom для получения подробной информации через эту форму. В первую очередь внимание будет уделяться клиентам, которые хотят включить её на односайтовых vSAN HCI или кластерах хранения vSAN размером от 3 до 16 хостов с использованием сетей 25GbE или быстрее. На начальном этапе некоторые топологии, такие как растянутые кластеры, а также некоторые сервисы данных, например, шифрование данных at rest, не будут поддерживаться при использовании этой функции.

Итоги

VMware считает, что глобальная дедупликация для vSAN в VCF 9.0 будет не хуже, а скорее всего лучше, чем решения по дедупликации у других поставщиков систем хранения. Учитывая, что клиенты VCF получают 1 TiB сырой ёмкости vSAN на каждое лицензированное ядро VCF, это открывает огромный потенциал: вы можете обеспечить всю необходимую ёмкость хранения, используя только существующее лицензирование, и при этом снизить затраты до минимума.

VMware недавно объявила о выпуске пяти новых экзаменов для профессиональной сертификации, основанных на версии 9 их платформы Cloud Foundation. Эти сертификаты представляют собой значительную эволюцию в портфеле сертификаций VMware, отражая продолжающееся новаторство компании в области технологий Cloud Foundation и виртуализации под руководством Broadcom.

Новый пакет сертификаций включает специализированные направления как для VMware Cloud Foundation (VCF), так и для VMware vSphere Foundation (VVF), охватывая ключевые роли — от администрирования и поддержки до архитектуры. Каждая сертификация предназначена для подтверждения навыков, необходимых для управления современной облачной инфраструктурой, устранения неполадок и проектирования в корпоративной среде.

Обзор нового портфеля сертификаций

Итак, появилось пять новых сертификаций уровня VMware Certified Professional (VCP):

• VMware Certified Professional - VMware vSphere Foundation Support (2V0-18.25)
• VMware Certified Professional - VMware Cloud Foundation Administrator (2V0-17.25)
• VMware Certified Professional - VMware Cloud Foundation Support (2V0-15.25)
• VMware Certified Professional - VMware Cloud Foundation Architect (2V0-13.25)
• VMware Certified Professional - VMware vSphere Foundation Administrator (2V0-16.25)

Эти сертификации отвечают растущему спросу на квалифицированных специалистов, которые могут эффективно внедрять, администрировать, поддерживать и проектировать частные облака с использованием новейших технологий VMware. Каждый экзамен проводится в едином формате: 60 вопросов с несколькими вариантами ответов, продолжительность — 135 минут, проходной балл — 300, стоимость попытки — 250 долларов.

Подробное рассмотрение каждой сертификации

1. VMware Certified Professional - VMware vSphere Foundation Support (2V0-18.25)

Эта сертификация является важной стартовой точкой для ИТ-специалистов, стремящихся углубиться в поддержку и устранение неполадок в средах VMware vSphere Foundation (VVF). Она подтверждает владение стандартными методиками диагностики и устранения проблем, возникающих при развертывании и эксплуатации VVF. Экзамен охватывает архитектуру VVF, включая основные функции, компоненты и модели работы.

Ключевые технические области:

• Операции с VCF
• Администрирование vCenter Server
• Управление гипервизором VMware ESX
• Работа с хранилищами VMware vSAN
• VMware Operations для централизованного логирования и мониторинга

Эта сертификация ценна для специалистов, переходящих от традиционной поддержки инфраструктуры к поддержке облачных виртуализированных систем. Подготовка возможна по Exam Study Guide, регистрация — через портал Broadcom.

2. VMware Certified Professional - VMware Cloud Foundation Administrator (2V0-17.25)

Эта сертификация предназначена для ИТ-специалистов, ответственных за ежедневное администрирование и управление средами VMware Cloud Foundation (VCF). Она подтверждает навыки по развертыванию, управлению и поддержке частных облаков на базе VCF. Адресована системным администраторам, облачным администраторам и специалистам по инфраструктуре, переходящим от традиционных ролей к обязанностям в области облачных технологий.

Основные темы: развертывание, администрирование, оптимизация производительности, настройка безопасности и устранение неполадок. Рекомендуемые курсы:

• VMware Cloud Foundation: Build, Manage, and Secure
• VMware Cloud Foundation: Automate and Operate

Подготовка — через Exam Study Guide, регистрация — в официальном портале Broadcom.

3. VMware Certified Professional - VMware Cloud Foundation Support (2V0-15.25)

Эта сертификация фокусируется на специалистах поддержки VMware Cloud Foundation. Она подтверждает умение диагностировать и устранять проблемы в частных облаках на базе VCF. Подходит для тех, кто переходит от традиционной поддержки инфраструктуры к ролям Cloud support или Site Reliability Engineer (SRE).

Сертификация охватывает:

• Продвинутые методики диагностики
• Инструменты анализа производительности
• Стратегии устранения сложных инцидентов

Рекомендуемый курс: "VMware Cloud Foundation: Troubleshooting". Доступны Exam Study Guide и регистрация через портал Broadcom.

4. VMware Certified Professional - VMware Cloud Foundation Architect (2V0-13.25)

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

Основные темы:

• Методологии проектирования
• Планирование ёмкости
• Высокодоступные и отказоустойчивые архитектуры
• Безопасность и интеграция с существующей инфраструктурой.

Рекомендуемый курс: "VMware Cloud Foundation: Solution Architecture and Design". Подготовка — по Exam Study Guide, регистрация — через портал Broadcom.

5. VMware Certified Professional - VMware vSphere Foundation Administrator (2V0-16.25)

Эта сертификация подтверждает компетенции специалистов, администрирующих среды VMware vSphere Foundation (VVF). Она охватывает:

• Развертывание и конфигурацию
• Администрирование виртуальных машин
• Распределение ресурсов
• Мониторинг производительности
• Настройку безопасности и устранение неполадок

Сертификация ориентирована на администраторов виртуальных сред. Рекомендуемый курс: "vSphere Foundation: Build, Manage and Secure". Подготовка — через Exam Study Guide, регистрация — на портале Broadcom.

Заключение

Запуск пяти новых сертификаций отражает стремление VMware укреплять лидерство в области облачных технологий. Они позволяют ИТ-специалистам строить карьеру в направлениях поддержки, администрирования и архитектуры. В версии 9 сертификации учитывают последние возможности и лучшие практики, что особенно важно в условиях быстрого развития технологий. Каждая сертификация обеспечивает уникальный путь профессионального развития и подтверждает как технические навыки, так и стремление к постоянному обучению.