На VMware Explore 2025 в Лас-Вегасе было сделано множество анонсов, а также проведены подробные обзоры новых функций и усовершенствований, включённых в VMware Cloud Foundation (VCF) 9, включая популярную функцию NVMe Memory Tiering. Хотя эта функция доступна на уровне вычислительного компонента VCF (платформа vSphere), мы рассматриваем её в контексте всей платформы VCF, учитывая её глубокую интеграцию с другими компонентами, такими как VCF Operations, к которым мы обратимся в дальнейшем.

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

Предварительные требования и совместимость оборудования

Оценка рабочих нагрузок

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

Чтобы рабочие нагрузки подходили для Memory Tiering, общий объём активной памяти должен составлять не более 50% от ёмкости DRAM. Почему именно 50%?
По умолчанию Memory Tiering предоставляет на 100% больше памяти, то есть удваивает доступный объём. После включения функции половина памяти будет использовать DRAM (Tier 0), а другая половина — NVMe (Tier 1). Таким образом, мы стремимся, чтобы активная память умещалась в DRAM, так как именно он является самым быстрым источником памяти и обеспечивает минимальное время отклика при обращении виртуальных машин к страницам памяти. По сути, это предварительное условие, гарантирующее, что производительность при работе с активной памятью останется стабильной.

Важный момент: при оценке анализируется активность памяти приложений, а не хоста, поскольку в Memory Tiering страницы памяти ВМ переносятся (demote) на NVMe-устройство, когда становятся «холодными» или неактивными, но страницы vmkernel хоста не затрагиваются.

Как узнать объём активной памяти?

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

Это можно сделать через интерфейс vCenter в vSphere Client, перейдя в:

VM > Monitor > Performance > Advanced

Затем измените тип отображения на Memory, и вы увидите метрику Active Memory. Если она не отображается, нажмите Chart Options и выберите Active для отображения.

Обратите внимание, что метрика Active доступна только при выборе периода Real-Time, так как это показатель уровня 1 (Level 1 stat). Активная память измеряется в килобайтах (KB).

Если вы хотите собирать данные об активной памяти за более длительный период, можно сделать следующее: в vCenter Server перейдите в раздел Configure > Edit > Statistics. Затем измените уровень статистики (Statistics Level) с Level 1 на Level 2 для нужных интервалов.

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

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

Примечания и ограничения

Для VCF 9.0 технология Memory Tiering пока не подходит для виртуальных машин, чувствительных к задержкам (latency-sensitive VMs), включая:

• Высокопроизводительные ВМ (High-performance VMs)
• Защищённые ВМ, использующие SEV / SGX / TDX
• ВМ с включенным механизмом непрерывной доступности Fault Tolerance
• Так называемые "Monster VMs" с объёмом памяти более 1 ТБ.

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

Программные предварительные требования

С точки зрения программного обеспечения, Memory Tiering требует новой версии vSphere, входящей в состав VCF/VVF 9.0. И vCenter, и ESX-хосты должны быть версии 9.0 или выше. Это обеспечивает готовность среды к промышленной эксплуатации, включая улучшения в области надёжности, безопасности (включая шифрование на уровне ВМ и хоста) и осведомлённости о vMotion.

Настройку Memory Tiering можно выполнить:

• На уровне хоста или кластера
• Через интерфейс vCenter UI
• С помощью ESXCLI или PowerCLI
• А также с использованием Desired State Configuration для автоматизации и последовательных перезагрузок (rolling reboots).

В VVF и VCF 9.0 необходимо создать раздел (partition) на NVMe-устройстве, который будет использоваться Memory Tiering. На данный момент эта операция выполняется через ESXCLI или PowerCLI (да, это можно автоматизировать с помощью скрипта). Для этого потребуется доступ к терминалу и включённый SSH. Позже мы подробно рассмотрим оба варианта и даже приведём готовый скрипт для автоматического создания разделов на нескольких серверах.

Совместимость NVMe

Аппаратная часть — это основа производительности Memory Tiering. Так как NVMe-накопители используются как один из уровней оперативной памяти, совместимость оборудования критически важна.

VMware рекомендует использовать накопители со следующими характеристиками:

• Выносливость (Endurance): класс D или выше (больше или равно 7300 TBW) — для высокой долговечности при множественных циклах записи.
• Производительность (Performance): класс F (100 000–349 999 операций записи/сек) или G (350 000+ операций записи/сек) — для эффективной работы механизма tiering.

Некоторые OEM-производители не указывают класс напрямую в спецификациях, а обозначают накопители как read-intensive (чтение) или mixed-use (смешанные нагрузки).
В таких случаях рекомендуется использовать Enterprise Mixed Drives с показателем не менее 3 DWPD (Drive Writes Per Day).

Если вы не знакомы с этим термином: DWPD отражает выносливость SSD и показывает, сколько раз в день накопитель может быть полностью перезаписан на протяжении гарантийного срока (обычно 3–5 лет) без отказов. Например, SSD объёмом 1 ТБ с 1 DWPD способен выдерживать 1 ТБ записей в день на протяжении гарантийного периода.
Чем выше DWPD, тем долговечнее накопитель — что критически важно для таких сценариев, как VMware Memory Tiering, где выполняется большое количество операций записи.

Также рекомендуется воспользоваться Broadcom Compatibility Guide, чтобы проверить, какие накопители соответствуют рекомендованным классам и как они обозначены у конкретных OEM-производителей. Этот шаг настоятельно рекомендуется, так как Memory Tiering может производить большие объёмы чтения и записи на NVMe, и накопители должны быть высокопроизводительными и надёжными.

Хотя Memory Tiering позволяет снизить совокупную стоимость владения (TCO), экономить на накопителях для этой функции категорически не рекомендуется.

Что касается форм-факторов, поддерживается широкий выбор вариантов. Вы можете использовать:

• Устройства формата 2.5", если в сервере есть свободные слоты.
• Вставляемые модули E3.S.
• Или даже устройства формата M.2, если все 2.5" слоты уже заняты.

Наилучший подход — воспользоваться Broadcom Compatibility Guide. После выбора нужных параметров выносливости (Endurance, класс D) и производительности (Performance, класс F или G), вы сможете дополнительно указать форм-фактор и даже параметр DWPD.

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

Вильям Лам описал способ развертывания виртуального модуля OVF/OVA напрямую с сервера с Basic Authentication.

Он делал эксперименты с использованием OVFTool и доработал свой скрипт deploy_data_services_manager.sh, чтобы он ссылался на URL, где был размещён Data Services Manager (DSM) в формате OVA. В этом случае базовую аутентификацию (имя пользователя и пароль) можно включить прямым текстом в URL. Хотя это не самый безопасный способ, он позволяет удобно использовать этот метод развертывания.

Можно просто вставить в скрипт следующую строчку:

DSM_OVA='http://vcf:vcf123!@192.168.30.29/PROD/COMP/DSM/dsm-va-9.0.1.0.24930659.ova'

vcf - это имя пользователя, а vcf123! - пароль.

Также эту строчку можно указать прямо в интерфейсе VMware vSphere Client в качестве URL:

И это будет работать с любым шаблоном. Нужно просто потом дальше принять сертификат от хранилища и продолжить развертывание шаблона из OVF или OVA:

Команда поддержки 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

Введение

В современных ИТ-системах шифрование данных стало обязательным элементом защиты информации. Цель шифрования — гарантировать, что данные могут прочитать только системы, обладающие нужными криптографическими ключами. Любой, не имеющий ключей доступа, увидит лишь бессмысленный набор символов, поскольку информация надёжно зашифрована устойчивым алгоритмом 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.

Supervisor Control Plane — это управляющий уровень встроенного Kubernetes (Supervisor Cluster) в решении VMware vSphere with Tanzu (ранее vSphere with Kubernetes). Он развёрнут как три виртуальные машины (Supervisor Control Plane VMs), которые выполняют контроль над кластером Kubernetes, включая etcd, API-сервер, контроллеры и планировщик. Важнейшие функции этих виртуальных машин:

• Интеграция с инфраструктурой vSphere: Supervisor Control Plane взаимодействует с ресурсами ESX-хостов — CPU, память, сеть, хранилище — и позволяет запускать контейнеры напрямую на гипервизоре (vSphere Pods).
• API-доступ: администраторы управляют кластерами через интерфейс vSphere Client и API vSphere with Tanzu, а разработчики — через kubectl.
• Высокая доступность: обеспечивается трёхкомпонентной архитектурой. Если один узел выходит из строя, другие продолжают работу.

Полезный трюк — как получить SSH-пароль для Supervisor Control Plane VM

Есть простой способ получить доступ по SSH для виртуальных машин, входящих в состав Supervisor Control Plane:

1. Подключитесь по SSH к виртуальному модулю сервера vCenter под пользователем root.
2. Выполните скрипт:

Скрипт выведет IP-адрес (обычно FIP, то есть "floating IP") и автоматически сгенерированный пароль. После этого вы можете подключиться по SSH к Supervisor Control Plane VM как root@<FIP> с полученным паролем.

Важно! Доступ к этим ВМ следует использовать только для диагностики и устранения проблем — любые изменения в них (особенно без одобрения от поддержки VMware) могут привести к нарушению работоспособности Supervisor-кластера, и поддержка может потребовать его полного развертывания заново.

Полезные рекомендации и предосторожения

• Скрипт /usr/lib/vmware-wcp/decryptK8Pwd.py извлекает пароль из базы данных vCenter. Он удобен для быстрого доступа, особенно при отладке сетевых или других проблем с Supervisor VM.
• Убедитесь, что FIP действительно доступен и корректно маршрутизируется. При сбое etcd FIP не назначится, и придётся использовать реальный IP-адрес интерфейса (например, eth0). Также при смене FIP удалите старую запись из known_hosts — сертификаты могут изменяться при «плавании» IP.
• Используйте доступ только для анализа, чтения логов и выполнения команд kubectl logs/get/describe.

Весной этого года вышел новый релиз бесплатной утилиты SexiGraf (Overwatch Nexus), предназначенной для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали об этом средстве в октябре прошлого года. Этот продукт был сделан энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным решениям для мониторинга серверов ESX и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.

Что нового

• VMware vSAN Inventory — расширенная инвентаризация объектов vSAN.
• PowerShell Core 7.4.6 LTS — обновление среды скриптов.
• Ubuntu 22.04.5 LTS — современная версия операционной системы.
• Apache 2.4.63 — обновлённый веб-сервер.

Улучшения и исправления

• Возможность добавления SSH-ключа при деплое — повышает безопасность и удобство разграничения доступа.
• Добавлен сбор события DrsSoftRuleViolationEvent в event-коллектор — расширение мониторинга нарушений правил DRS.
• Исправлено неконсистентное значение GuestId в инвентаре VM (различие между vmx и vmtools) — повышение точности данных.
• Различные багфиксы — общее улучшение стабильности и надежности.

Миграция и формат поставки

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

1. Экспортировать данные из текущего SexiGraf-модуля.
2. Импортировать данные в новый OVA-модуль через функционал Export/Import.

Виртуальный модуль SexiGraf 0.99l уже доступен для загрузки и развёртывания. Установка происходит стандартным способом через OVA (например, через vSphere, OVF Tool и т.п.). Версия поддерживает переопределение root-пароля и SSH-ключа на этапе деплоя, что упрощает настройку и повышает безопасность.

Недавно компания VMware опубликовала полезный для администраторов документ «vSphere 9.0 Performance Best Practices» с указанием ключевых рекомендаций по обеспечению максимальной производительности гипервизора ESX и инфраструктуры управления vCenter.

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

• Аппаратное обеспечение: CPU, память, дисковая подсистема, безопасность.
• Настройки BIOS: рекомендуется включить AES-NI, правильно сконфигурировать энергосбережение (например, «OS Controlled Mode»), при необходимости отключить некоторые C-states в особо чувствительных к задержкам приложениях.
• vCenter и Content Library: советуют минимизировать автоматические скриптовые входы, использовать группировку vCenter для повышения синхронизации, хранить библиотеку контента на хранилищах с VAAI и ограничивать сетевую нагрузку через глобальный throttling.
• Тонкое администрирование: правила доступа, лимиты, управление задачами, патчинг и обновления (включая рекомендации по BIOS и live scripts) и прочие глубокие настройки.

Отличия от версии для vSphere 8 (ESX и vCenter)

Аппаратные рекомендации

• vSphere 8 предоставляет рекомендации по оборудованию: совместимость, минимальные требования, использование PMem (Optane, NVDIMM-N), vPMEM/vPMEMDisk, VAAI, NVMe, сетевые настройки, BIOS-опции и оптимизации I/O и памяти.
• vSphere 9 добавляет новые аппаратные темы: фокус на AES-NI, snoop-режимах, NUMA-настройках, более гибком управлении энергопотреблением и безопасности на уровне BIOS.

vMotion и миграции

• vSphere 8: введение «Unified Data Transport» (UDT) для ускорения холодных миграций и клонирования (при поддержке обеих сторон). Также рекомендации для связки encrypted vMotion и vSAN.
• vSphere 9: больше внимания уделяется безопасности и производительности на стороне vCenter и BIOS, но UDT остаётся ключевым механизмом. В анонсах vSphere 9 в рамках Cloud Foundation акцент сделан на улучшенном управлении жизненным циклом и live patching.

Управление инфраструктурой

• vSphere 8: рекомендации по vSphere Lifecycle Manager, UDT, обновлению vCenter и ESXi, GPU профили (в 8.0 Update 3) — включая поддержку разных vGPU, GPU Media Engine, dual DPU и live patch FSR.
• vSphere 9 / VMware Cloud Foundation 9.0: новый подход к управлению жизненным циклом – поддержка live patch для vmkernel, NSX компонентов, более мощные «монстр-ВМ» (до 960 vCPU), direct upgrade с 8-й версии, image-based lifecycle management.

Работа с памятью

• vSphere 8: рекомендации для Optane PMem, vPMEM/vPMEMDisk, управление памятью через ESXi.
• vSphere 9 (через Cloud Foundation 9.0): внедрён memory tiering, позволяющий увеличить плотность ВМ в 2 раза при минимальной потере производительности (5%) и снижении TCO до 40%, без изменений в гостевой ОС.

Документ vSphere 9.0 Performance Best Practices содержит обновлённые и расширенные рекомендации для платформы vSphere 9, уделяющие внимание аппаратному уровню (BIOS-настройки, безопасность), инфраструктурному управлению, а также новым подходам к памяти (главный из них - memory tiering).

VMware vSphere 7 достигнет конца основного срока поддержки (End of General Support) 2 октября 2025 года. Если вы в настоящее время используете vSphere 7, вам необходимо перейти на vSphere 8, чтобы продолжать получать поддержку продукта, обновления безопасности и патчи. Это также подготовит вас к переходу на VCF 9, когда вы будете к этому готовы.

Существует два варианта обновления:

1. Вы можете напрямую обновить vSphere 7 до vSphere 8

2. Либо можно импортировать vSphere 7 в VMware Cloud Foundation (VCF) версии 5.2 и выполнить обновление домена рабочих нагрузок до версии 8 через VMware SDDC Manager.

Выбор подходящего пути зависит от ряда факторов, таких как готовность бизнеса, поддержка сторонних продуктов и конфигурация среды. Ниже описано, как команда VCF Professional Services подходит к каждому из этих вариантов.

Вариант 1: Обновление с использованием vSphere Lifecycle Manager

Этот вариант представляет собой традиционный способ обновления vSphere. Вы можете использовать vSphere Lifecycle Manager Images или vSphere Lifecycle Manager Baselines для выполнения задачи обновления.

Преимущества этого подхода:

• Используются уже существующие операционные процессы обновления.
• В большинстве случаев требуется минимальное изменение текущей среды.
• Нет необходимости в дополнительных виртуальных модулях (appliances).

Недостатки этого подхода:

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

Шаги по обновлению с использованием vSphere Lifecycle Manager

Многие организации сначала выполняют обновление на тестовой (staging) среде перед тем, как переходить к рабочей (production). Шаги, как правило, одинаковы для любых сред.

Шаг 1: Планирование, предварительная проверка и подготовка среды к обновлению.

На этом этапе необходимо вручную подтвердить, что ваша среда поддерживает новые версии. Начните с изучения Release Notes для vSphere 8 и проверьте, поддерживают ли ваши интеграции с другими продуктами VMware или сторонними приложениями vSphere 8. Также потребуется подготовка к обновлению vCenter и понимание изменений, связанных с обновлением хостов VMware ESX.

Шаг 2: Загрузка бинарных файлов (если необходимо).

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

Шаг 3: Обновление vCenter.

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

• Обновление с сокращённым временем простоя (Reduced Downtime Upgrade) - при этом способе разворачивается вторичный виртуальный модуль, и конфигурационные данные переносятся на него. Это наиболее предпочтительный метод, поскольку он обеспечивает минимальные простои по сравнению с другими способами обновления.

• Установщик vCenter (vCenter Installer) – установщик vCenter включает опцию обновления, которая позволяет обновить существующий виртуальный модуль. Этот метод может быть использован в случае, если недостаточно ресурсов для развертывания второго модуля.

• Обновление через интерфейс управления виртуальным модулем (Virtual Appliance Management Interface Upgrade) – этот метод позволяет автоматически загрузить и установить бинарные файлы напрямую из интерфейса управления виртуальным модулем vCenter. Мы также можем использовать этот способ, если недостаточно ресурсов для развертывания второго модуля.

Шаг 4: Обновление хостов ESX.

После обновления vCenter можно переходить к обновлению хостов ESX. Существует несколько способов обновления хостов ESX. VMware использует два основных подхода:

• vSphere Lifecycle Manager - это предпочтительный метод, так как он позволяет обновлять целые кластеры одновременно, вместо обновления каждого хоста по отдельности. Это самый простой способ выполнения обновлений.

• Сценарные обновления (Scripted Upgrades) – этот метод рекомендуется, когда необходимо обновить большое количество хостов. Существует несколько способов автоматизации обновления с помощью сценариев, что позволяет адаптировать процесс под конкретные операционные процедуры и используемые языки скриптов.

Шаг 5: Обновление VMware vSAN.

После обновления хостов следующим шагом является обновление формата дисков vSAN. Этот шаг рекомендуется, но не является обязательным. Обновление vSAN позволяет воспользоваться новыми функциями.

Шаг 6: Обновление версии vSphere Distributed Switch.

Версию vSphere Distributed Switch также можно обновить. Этот шаг также является необязательным, однако рекомендуется его выполнить, чтобы получить доступ к новым возможностям.

Шаг 7: Проверка после обновления (Post-Upgrade Validation).

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

На этом процесс обновления среды vSphere с использованием vSphere Lifecycle Manager завершается.

Вариант 2: Импорт vSphere в экземпляр VCF и обновление через SDDC Manager

Второй вариант — это импорт среды vSphere в VCF 5.2 с последующим обновлением через консоль SDDC Manager. Для этого у вас уже должен быть развернут экземпляр VCF.

Преимущества импорта vSphere в VCF и обновления через SDDC Manager:

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

Недостатки:

• Требуются дополнительные виртуальные модули. VCF представляет собой полноценный программно-определяемый датацентр, и такие компоненты, как VMware NSX, являются обязательными. Это требует выделения дополнительных ресурсов.
• Как упомянуто в разделе с преимуществами, приведение среды к стандарту VCF может потребовать выполнения определённых исправлений.

Шаги по импорту vSphere в VCF и обновлению через SDDC Manager

Шаг 1: Импорт существующей среды vSphere в конфигурацию VCF.

Используйте VCF Import Tool для проверки предварительных условий и выполнения импорта в уже существующий экземпляр VCF.

Шаг 2: Обновление vSphere через SDDC Manager.

После того как в среде доступен SDDC Manager, вы можете использовать его для выполнения следующих задач:

• Загрузка пакетов обновлений (Download Update Bundles) – скачайте необходимые пакеты, чтобы иметь возможность выполнить обновление.

• Выполнение предварительных проверок (prechecks) – выполните проверку предварительных условий, чтобы выявить проблемы, которые могут привести к сбою обновления. Если будут обнаружены какие-либо ошибки или проблемы, их необходимо устранить перед продолжением процесса.

• Обновление компонентов (Upgrade Components) – обновите все компоненты vSphere (vCenter и ESX). SDDC Manager выполнит обновление в правильной последовательности, чтобы обеспечить совместимость с перечнем компонентов (Bill of Materials) VCF 5.2.

Шаг 3: Проверка после обновления (Post-Upgrade Validation).

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

Как уже упоминалось, данный вариант требует наличия развернутого экземпляра VCF. Если его нет, вы можете сначала обновить хотя бы один экземпляр vCenter 7 до vSphere 8, используя Вариант 1, а затем преобразовать этот экземпляр vSphere в VCF.

VMware представила унифицированный фреймворк разработки VCF SDK 9.0 для Python и Java.

Улучшение опыта разработчиков (Developer Experience) — один из главных приоритетов в дальнейшем развитии платформы VMware Cloud Foundation (VCF). Если рассматривать автоматизацию в целом, то можно выделить две чёткие категории пользователей: администраторы и разработчики.

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

Разработчики, напротив, ориентированы на интеграцию возможностей VCF в пользовательские приложения и решения. Им необходимы API и SDK, обеспечивающие программный доступ к сервисам и данным VCF, позволяя разрабатывать собственные инструменты, сервисы и расширения. Потребности в автоматизации у этих двух групп значительно различаются и соответствуют их уникальным ролям в экосистеме VCF. Понимая эти различия, Broadcom предлагает набор интерфейсов прикладного программирования (API), средств разработки (SDK) и разнообразных инструментов автоматизации, таких как PowerCLI, Terraform и Ansible.

Оглядываясь назад, можно сказать, что VMware хорошо обслуживала сообщество администраторов, предоставляя им различные инструменты. Однако API и SDK требовали улучшения в области документации, лучшей интеграции с VCF-стеком в целом и упрощения процесса для разработчиков. До выхода VCF 9.0 разработчики использовали отдельные SDK решений, сталкиваясь с трудностями, связанными с их интеграцией — такими как совместимость, аутентификация и сложность API. С выходом VCF 9.0 VMware рада объявить о доступности Unified VCF SDK 9.0. Давайте подробнее рассмотрим, что это такое.

Unified VCF SDK

Unified VCF SDK доступен с привязками к двум языкам — Java и Python. Это объединённый SDK, который включает в себя все основные SDK решений VCF в единый, упрощённый пакет. В своей первой версии Unified VCF SDK объединяет существующие SDK и добавляет новые библиотеки для установщика VCF и менеджера SDDC.

Список компонентов VCF, включённых в первую версию Unified VCF SDK:

• VMware vSphere
• VMware vSAN
• VMware Cloud Foundation SDDC Manager (новый)
• VMware Cloud Foundation Installer (новый)
• VMware vSAN Data Protection

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

Для краткости в этом тексте Unified VCF SDK будет обозначаться как VCF SDK.

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

VCF SDK обеспечивает простой, расширяемый и единообразный опыт для разработчиков на протяжении всего жизненного цикла разработки.

Упрощённый жизненный цикл разработчика

С этим релизом были стандартизированы методы доставки и распространения, чтобы поддерживать различные сценарии развертывания:

• Онлайн-установка через PyPI (Python) и Maven (Java) — для прямого доступа и лёгкой установки/обновлений.
• Офлайн-установка через портал разработчиков Broadcom — идеально для сред с ограниченным доступом в интернет.
• Готовность к CI/CD — интеграции через пакеты и инструкции, размещённые на GitHub, для бесшовного включения в автоматизированные пайплайны при установке и обновлении.

Улучшенная документация и онбординг

VMware переработала документацию, чтобы упростить старт:

• Руководства по началу работы для Python и Java.
• Примеры кода для быстрого освоения.

OpenAPI-спецификация

OpenAPI-спецификация описывает API в стандартизированном машинно-читаемом формате (YAML/JSON). С выходом VCF SDK были также публикованы OpenAPI-спецификации для API-эндпоинтов. Это не просто документация — это шаг к философии API-first и ориентированности на разработчиков.

С помощью OpenAPI-спецификаций разработчики могут:

• Автоматически генерировать клиентские библиотеки на предпочитаемых языках с помощью инструментов вроде Swagger Codegen, Kiota или OpenAPI Generator.
• Загружать спецификации в такие инструменты, как Swagger UI, Redoc или Postman, чтобы визуально исследовать доступные эндпоинты, параметры, схемы ответов и сообщения об ошибках.
• Понимать структуру API и его поведение.

Скачать OpenAPI-спецификацию можно с портала разработчиков Broadcom или из репозитория GitHub.

VCF Python SDK

VCF Python SDK включает в себя следующие модули:

Каналы распространения

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

Портал разработчиков Broadcom

VCF Python SDK доступен для загрузки на портале разработчиков Broadcom. Вы можете распаковать содержимое ZIP-архива vcf-python-sdk-9.0.0.0-24798170.zip, чтобы ознакомиться с библиотеками SDK, утилитами и примерами. Однако сторонние зависимости не входят в состав архива — они перечислены в файле requirements-third-party.txt, находящемся внутри vcf-python-sdk-9.0.0.0-24798170.zip.

Файлы .whl компонентов VCF SDK находятся в папках ../pypi/*, а примеры кода для компонентов расположены в директориях вида /<имя_компонента>-samples/.

PyPI

VCF SDK доступен в PyPI, что позволяет разработчикам устанавливать и обновлять модуль онлайн. Это самый быстрый способ начать работу с VCF SDK.

Чтобы установить VCF SDK, выполните следующую команду:

Пакеты, установленные через pip, можно автоматически обновлять. Чтобы обновить VCF SDK, используйте команду:

Чтобы установить конкретную библиотеку из состава VCF SDK, выполните:

Примеры:

$ pip install pyvmomi
$ pip install vcf-installer

GitHub

Разработчики также могут скачать пакет VCF SDK из репозитория VMware на GitHub.

VCF Java SDK

VCF Java SDK включает в себя следующие артефакты:

Каналы распространения

Аналогично Python SDK, JAVA SDK также доступен через различные каналы распространения, что позволяет использовать его в самых разных средах.

Портал разработчиков Broadcom

VCF Java SDK доступен для загрузки на портале разработчиков Broadcom. Вы можете распаковать содержимое ZIP-архива vcf-java-sdk-9.0.0.0-24798170.zip, чтобы ознакомиться с библиотеками SDK, утилитами и примерами.

Файлы привязок SDK .jar, утилит .jar, а также BOM-файлы находятся в папке:

Maven

Артефакты VCF SDK доступны в Maven Central под groupId: com.vmware.sdk. В таблице ниже указаны данные об артефактах VCF SDK для версии 9.0.0.0.

Чтобы начать работу с VCF SDK, добавьте зависимость в файл pom.xml вашего проекта:

<dependencies>
<dependency>
<groupId>com.vmware.sdk</groupId>
<artifactId>vcf-sdk</artifactId>
<version>9.0.0.0</version>
</dependency>
</dependencies>

GitHub

Разработчики также могут скачать пакет VCF SDK из репозитория VMware на GitHub.

Журнал изменений API

С выходом VCF 9.0 VMware начала публиковать журнал изменений API. В нём отражаются все изменения: новые API, обновления существующих и уведомления об устаревании. Ознакомиться с журналом изменений можно здесь.

Ресурсы

• Release Notes
• API Change Log
• Broadcom Developer Portal
• VCF Python SDK on PyPI 
• VCF Java SDK on Maven 

Репозитории Github:

• VCF Python SDK 
• VCF JAVA SDK
• VCF OpenAPI Specifications

Страницы Getting Started:

• Getting Started with VCF Python SDK
• Getting Started with VCF JAVA SDK 
• Getting Started with VCF OpenAPI Specification

Заключение

С выпуском VMware Cloud Foundation 9.0 объединение различных библиотек в один SDK с улучшенной документацией, примерами кода и спецификацией OpenAPI — это важный шаг к простому, расширяемому и согласованному опыту для разработчиков.

Следующий шаг за вами — попробуйте Unified VCF SDK 9.0 и поделитесь с нами своими отзывами.

В платформе VMware vSphere 9 в рамках инфраструктуры VMware Cloud Foundation (VCF) 9.0 была значительно расширена область компонентов ESX, которые можно обновлять с помощью технологии Live Patch. Теперь это включает в себя vmkernel, пользовательские демоны, компоненты NSX, а также уже ранее поддерживаемое выполнение виртуальных машин (vmx), которое было адаптировано к Live Patch.

Используйте Live Patch уже сегодня

Недавно выпущенное обновление ESX 9.0.0.0100 уже полноценно поддерживает Live Patch (см. Release Notes). Вы можете применить это обновление к кластерам ESX 9.0.0 (24755229) с помощью Live Patch, заодно и протестируете работу этой технологии.

Если коротко: Live Patch позволяет применять некоторые обновления ESX без прерывания работы, то есть без необходимости эвакуации виртуальных машин с хоста.

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

Напоминание: чтобы определить, поддерживает ли обновление Live Patch, проверьте Release Notes — в них будет указано, если такая возможность есть. Интерфейсы консолей VCF и vSphere Lifecycle Manager также будут отображать эту информацию:

При обновлении пользовательских демонов (user-space daemons) с помощью Live Patch может потребоваться перезапуск соответствующего демона. В зависимости от того, какой демон обновляется и перезапускается, ESX-хост может на короткое время потерять связь с vCenter. Например, обновление демона hostd может потребовать его перезапуска. Это может привести к кратковременному отображению хоста как отключённого от vCenter — это ожидаемое поведение и не влияет на работу виртуальных машин.

Если Live Patch затрагивает среду исполнения виртуальных машин (vmx), то в процессе обновления выполняется операция быстрой приостановки и возобновления (Fast Suspend-Resume, FSR) виртуальных машин. Не каждое обновление требует выполнения FSR. Подробнее об FSR можно прочитать вот тут. В vSphere с VCF 9.0 операция FSR выполняется значительно быстрее для виртуальных машин с включённым vGPU, что позволяет выполнять Live Patch на кластерах с такими ВМ без прерывания работы AI/ML-приложений.

Перед выполнением задачи Live Patch, vSphere Lifecycle Manager проводит предварительную проверку (precheck), чтобы убедиться, что на хостах достаточно доступных ресурсов. Если ресурсов недостаточно, может потребоваться снизить нагрузку на хосты перед тем, как приступить к обновлению.

Ограничения Live Patch, имевшиеся в vSphere 8, сохраняются и в VCF 9.0. Среди них:

• Отсутствие поддержки Live Patch на системах с включёнными устройствами TPM 2.0
• Использование DPU в составе vSphere Distributed Services Engine
• Невозможность совмещать параллельный апдейт (parallel remediation) с Live Patch.

Дополнительную информацию см. в документации vSphere: Configuring vSphere Lifecycle Manager for Live Patches.

Недавно компания VMware выпустила полезный документ "VMware Cloud Foundation 9.0 and VMware vSphere Foundation 9.0 Feature Comparison & Upgrade Paths", в котором приводится сравнении функциональности VMware Cloud Foundation и vSphere Foundation, а также рассказывается о существующих вариантах апгрейда.

Издания платформы: Cloud Foundation vs vSphere Foundation

VMware Cloud Foundation (VCF) 9.0

Полноценная IaaS-платформа, предоставляющая Enterprise-возможности:

• vSphere (ESX и vCenter), vSAN, NSX и HCX
• Автоматизация управления жизненным циклом с помощью SDDC Manager, операции Fleet Management и VCF Operations
• Aria Automation в рамках портала самообслуживания, Terraform, GitOps, blueprints
• Оперативный мониторинг, комплаенс, chargeback через Aria Operations Enterprise
• Kubernetes как сервис, включая Supervisor Services, ArgoCD, Data / AI Services
• Поддержка больших объемов хранения (до 1 TiB/core), глобальной дедупликации, растянутых кластеров, QoS, снапшотов и многого другого

VMware vSphere Foundation (VVF) 9.0

Базовая, но мощная платформа виртуализации:

• Включает vSphere Kubernetes Service, vSAN, vCenter Standard, VCF Operations (включая базовый мониторинг и жизненный цикл)
• Не включает NSX, HCX, Aria Automation или Aria Operations Enterprise
• Поддерживает основное управление платформой виртуализации и контейнерами, но не полноценную автоматизацию и изоляцию тенантов

Сравнение ключевых возможностей

Пути обновления (Upgrade Paths)

В документе VMware четко описывает возможности перехода с предыдущих продуктов:

• Старые версии: vSphere Enterprise Plus, vSphere Standard, vCloud Suite, Aria Suite и другие можно мигрировать либо в vSphere Foundation 9.0 (если нужны базовые функции), либо сразу в VCF 9.0 для полной автоматизации и сетевых возможностей.

• Лицензирование:

  • Подписка VCF 9 или VVF 9 включает лицензию версии 9.0, а также ключи для версий 8.x, которые можно использовать или понижать (downgrade) при необходимости.

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

Последовательность обновления при переходе на VCF 9.0

Broadcom рекомендует следующую схему для обновления компонентов в среде с несколькими доменами нагрузки (workload domains):

1. Aria Suite Lifecycle (до версии 8.18 Patch 2)
2. VCF Operations и Fleet Management
3. VCF Automation, VCF Operations – Networks, Logs (новый лог-менеджмент вместо Aria Logs)
4. SDDC Manager
5. HCX, NSX, затем vCenter
6. Identity Broker / VIDB
7. Supervisor, vSAN Witness, хосты ESX
8. vSAN, файловый сервис, VMware Tools, Virtual Hardware.

Важно: компонент Aria Operations for Logs 8.x не обновляется напрямую — миграция исторических данных происходит через Day-N операции в новом VCF Operations Logs.

Что выбрать?

• vSphere Foundation 9.0 — если нужна стабильная виртуализация с контейнерами и vSAN, но без сложной сетевой и автоматизационной логики.

• Cloud Foundation 9.0 — если требуется:

  • Автоматическая настройка облака (IaaS) под клиентов
  • Полнофункциональные сети и безопасность
  • Глобальное управление через единую платформу
  • Поддержка Kubernetes, AI, Data services
  • Полная интеграция Operations / Automation

Выводы

• VMware предложила две SKU-конфигурации, одна — мощная, полностью автоматизированная платформа IaaS (VCF), другая — компактная и эффективная инфраструктурная база ( vSphere Foundation).
• Лицензирование и upgrade гибкие — подписка VCF/VVF 9 позволяет использовать версию 9.0 или откатиться на 8.x в рамках лицензии.
• Обновление требует чёткого порядка, особенно при переходе с существующих систем – важна последовательность компонентов, миграция логов и identity.
• Выбор зависит от ваших нужд: простота и контейнеризация или полный спектр управления частным облаком с IaaS, безопасностью и DevOps-интерфейсами.

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

Memory Tiering с NVMe была представлена в составе VCF 9.0, и важно подчеркнуть её ценность для компаний, стремящихся сократить расходы, особенно при закупке оборудования, так как стоимость оперативной памяти составляет значительную часть спецификации аппаратного обеспечения (Bill of Materials, BOM). Функция, позволяющая масштабировать память за счёт использования недорогого оборудования, может существенно повлиять на распределение ИТ-бюджета и приоритетность проектов.

Memory Tiering с NVMe можно настроить через привычный вам интерфейс vCenter UI, с помощью командной строки через ESXCLI, а также через скрипты в PowerCLI. Можно использовать любую из этих опций или их комбинацию для настройки многоуровневой памяти как на уровне хоста, так и на уровне кластера.

Аппаратное обеспечение имеет значение

Перед настройкой функции Memory Tiering крайне важно обратить внимание на рекомендуемое оборудование. И это не просто совет, а настоятельная рекомендация. Поскольку в роли памяти будут использоваться устройства NVMe, важно, чтобы они были не только надёжными, но и демонстрировали высокую производительность при интенсивной нагрузке. Аналогично тому, как вы определяли рекомендуемые устройства для vSAN, здесь также есть требования: NVMe-устройства должны соответствовать классу выносливости D (не менее 7300 TBW) и классу производительности F или выше (не менее 100 000 операций записи в секунду) для использования в составе многоуровневой памяти. VMware рекомендует воспользоваться руководством по совместимости с vSAN, чтобы убедиться, что выбранные устройства соответствуют этим требованиям.

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

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

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

Максимальный размер раздела в текущей версии составляет 4 ТБ, однако вы можете использовать и более ёмкое устройство — это позволит «циклически использовать ячейки» и потенциально продлить срок службы NVMe-накопителя. Хотя размер раздела зависит от ёмкости устройства (до 4 ТБ), фактический объём NVMe, задействованный в качестве памяти, рассчитывается на основе объёма DRAM на хосте и заданного соотношения. По умолчанию в VCF 9.0 применяется соотношение DRAM:NVMe как 1:1 — это в четыре раза больше, чем в технологическом превью на vSphere 8.0 Update 3.

Например, если у вас есть хост с 1 ТБ DRAM и NVMe-устройство на 4 ТБ, то будет создан раздел размером 4 ТБ, но использоваться в рамках Memory Tiering будет только 1 ТБ — если, конечно, вы не измените соотношение. Это соотношение настраивается пользователем, однако стоит проявить осторожность: изменение параметра может негативно повлиять на производительность и сильно зависит от характера и активности рабочих нагрузок. Подробнее об этом — далее.

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

Пример:

Конфигурация хоста или кластера

После создания раздела tierdevice остаётся последний шаг — настроить хост или кластер. Да, вы можете гибко подойти к конфигурации: настроить один, несколько хостов или весь кластер целиком. В идеале рекомендуется настраивать кластер гомогенно; однако стоит учитывать, что некоторые типы виртуальных машин пока не поддерживаются в режиме NVMe Memory Tiering. К ним относятся:

• ВМ с высокими требованиями к производительности и низкой задержке
• Защищённые ВМ (SEV, SGX, TDX),
• ВМ с непрерывной доступностью (FT)
• "Монстр-машины" (1 ТБ памяти, 128 vCPU)
• Вложенные ВМ (nested VMs).

Если в одном кластере у вас сочетаются такие ВМ с обычными рабочими нагрузками, которые могут использовать Memory Tiering, вы можете либо выделить отдельные хосты для «особых» ВМ, либо отключить Memory Tiering на уровне конкретных виртуальных машин.

Для включения Memory Tiering на хосте вы можете воспользоваться ESXCLI, PowerCLI или интерфейсом vCenter UI. В ESXCLI команда очень простая:

В vCenter UI это делается путём изменения параметра VMkernel.Boot.memoryTiering на значение TRUE. Обратите внимание на слово BOOT — для применения параметра хост необходимо перезагрузить. Также перед внесением изменений хост нужно перевести в режим обслуживания.

А если вы хотите настроить весь кластер? Что ж, это даже проще. Вы можете воспользоваться функцией Desired State Configuration в vCenter. Всё, что нужно — создать новый черновик с включённой настройкой memory_tiering в разделе vmkernel > options, установив её в значение true. После этого остаётся просто применить этот драфт ко всем хостам в кластере (или только к выбранным хостам).

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

• Лучшего коэффициента консолидации ВМ
• Сниженной совокупной стоимости владения
• Простой масштабируемости памяти — по значительно более низкой цене

После завершения настройки вы увидите как минимум двукратное увеличение доступной памяти, а также визуальное отображение уровней памяти (memory tiers) в интерфейсе vCenter UI.

Затраты на память по-прежнему остаются одной из самых крупных статей расходов на серверную инфраструктуру, и при этом большая часть дорогой оперативной памяти (DRAM) используется неэффективно. А что, если вы могли бы удвоить плотность виртуальных машин и сократить совокупную стоимость владения до 40%?

С выходом VMware Cloud Foundation 9.0 технология Memory Tiering (многоуровневая организация памяти) делает это возможным. Команда инженеров VMware недавно представила результаты тестирования производительности, которые демонстрируют, как эта технология меняет экономику датацентров. Подробности — в новом исследовании: Memory Tiering Performance in VMware Cloud Foundation 9.0.

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

Как Memory Tiering улучшает производительность датацентров и снижает затраты

В VMware Cloud Foundation 9.0 технология Memory Tiering предоставляет виртуальным машинам единое логическое адресное пространство памяти. Однако «под капотом» она управляет двумя уровнями памяти: Tier 0 (DRAM) и Tier 1 (Memory Tiering), в зависимости от активности памяти виртуальной машины. Фактически, система старается держать «горячую» (активную) память в DRAM, а «холодную» (неактивную) — на NVMe.

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

VMware провела тестирование на различных корпоративных нагрузках, чтобы подтвердить эффективность Memory Tiering. Были использованы серверы на базе процессоров Intel и AMD с различными конфигурациями DRAM. В VMware Cloud Foundation 9.0 по умолчанию используется соотношение DRAM к NVMe 1:1, и во всех тестах применялось именно оно.

Login Enterprise: Производительность виртуальных рабочих столов

Команда VMware использовала Login Enterprise для тестирования производительности VDI (виртуальных рабочих столов) в различных сценариях. Во всех тестах удалось удвоить количество виртуальных машин на хосте ESX при минимальном снижении производительности. Например, в конфигурации из трёх узлов vSAN:

• Удвоили количество VDI-сессий, которые могли выполняться на трёхузловом кластере vSAN — с 300 (только DRAM) до 600 (с использованием Memory Tiering).
• При этом не было зафиксировано потери производительности по сравнению с аналогичной конфигурацией, использующей только DRAM.

VMmark 3.1: производительность корпоративных приложений

Тест VMmark 3.1, включающий несколько нагрузок, имитирующих работу корпоративных приложений, показал отличные результаты:

• Конфигурация с Memory Tiering достигла 6 тайлов против 3 тайлов в конфигурации, использующей только DRAM. Это в 2 раза лучше.
• При сравнении конфигураций с 1 ТБ DRAM и с 1 ТБ Memory Tiering, снижение производительности составило всего 5%, несмотря на использование более медленной памяти NVMe в режиме Memory Tiering.

HammerDB и DVD Store: производительность баз данных

Производительность баз данных — один из самых ресурсоёмких тестов для любой инфраструктуры. VMware использовала HammerDB и DVD Store в качестве нагрузок для тестирования SQL Server, Oracle Database и MySQL. С помощью Memory Tiering удалось удвоить количество виртуальных машин при минимальном влиянии на производительность. Например, в тесте Oracle Database с нагрузкой DVD Store были получены следующие результаты:

• На хосте ESX с Memory Tiering удалось запустить 8 виртуальных машин против 4 в конфигурации, использующей только DRAM — плотность удвоилась.
• При сравнении конфигураций с 1 ТБ DRAM и с 1 ТБ Memory Tiering снижение производительности составило менее 5%.

Мониторинг Memory Tiering на хостах ESX

Для обеспечения высокой производительности при использовании Memory Tiering следует отслеживать два ключевых показателя:

• Поддерживайте активную память на уровне 50% или меньше от объёма DRAM — это обеспечит оптимальную производительность.

• Следите за задержкой чтения с NVMe-устройства. Наилучшая производительность достигается при задержке менее 200 микросекунд.

Преобразите экономику вашего датацентра

Memory Tiering предлагает новый подход к организации памяти:

• До 40% экономии совокупной стоимости владения (TCO) за счёт снижения требований к DRAM.
• Прозрачная работа — не требует изменений в приложениях или гостевых операционных системах.
• До 2-кратного увеличения плотности виртуальных машин для различных типов нагрузок.
• Гибкая инфраструктура, адаптирующаяся к изменяющимся требованиям рабочих нагрузок.

Memory Tiering уже доступна в VMware Cloud Foundation 9. Скачайте полное исследование производительности, чтобы подробнее ознакомиться с методологией тестирования, результатами и рекомендациями по внедрению.

Хотите попробовать Memory Tiering на практике?

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

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

VMware предлагает решение — vSphere Foundation 9, современную платформу для рабочих нагрузок, которая предоставляет инфраструктуру корпоративного уровня на базе гиперконвергентной архитектуры (HCI).

Платформа объединяет:

• vSphere — проверенный гипервизор для запуска виртуальных машин
• Встроенную инфраструктуру Kubernetes для запуска контейнеризованных приложений
• VSAN — хранилище корпоративного уровня
• Интегрированные средства управления и безопасности

С помощью vSphere Foundation 9 вы можете:

• Управлять виртуальными машинами, Kubernetes-кластерами и AI-нагрузками средствами единой платформы
• Повысить эффективность операций до 77%
• Увеличить плотность серверов до 40% благодаря NVMe-кешированию
• Ускорить миграцию AI-нагрузок с GPU до 6 раз
• Сократить простои в 5 раз и уменьшить время решения проблем на 20%
• Усилить защиту с помощью Live-патчинга ESX и репликации между VSAN-кластерами для восстановления после сбоев

Платформа легко масштабируется: можно начать с малого и наращивать мощность по мере роста бизнеса. Это делает vSphere Foundation 9 идеальным решением для компаний, стремящихся модернизировать ИТ-инфраструктуру, ускорить инновации и обеспечить безопасность критичных нагрузок.

Новая версия платформы VMware Cloud Foundation 9.0, включающая компоненты виртуализации серверов и хранилищ VMware vSphere 9.0, а также виртуализации сетей VMware NSX 9, привносит не только множество улучшений, но и устраняет ряд устаревших технологий и функций. Многие возможности, присутствовавшие в предыдущих релизах ESX (ранее ESXi), vCenter и NSX, в VCF 9 объявлены устаревшими (deprecated) или полностью удалены (removed). Это сделано для упрощения архитектуры, повышения безопасности и перехода на новые подходы к архитектуре частных и публичных облаков. Ниже мы подробно рассмотрим, каких функций больше нет во vSphere 9 (в компонентах ESX и vCenter) и NSX 9, и какие альтернативы или рекомендации по миграции существуют для администраторов и архитекторов.

Почему важно знать об удалённых функциях?

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

VMware vSphere 9: удалённые и устаревшие функции ESX и vCenter

В VMware vSphere 9.0 (гипервизор ESX 9.0 и сервер управления vCenter Server 9.0) прекращена поддержка ряда старых средств администрирования и внедрены новые подходы. Ниже перечислены основные функции, устаревшие (подлежащие удалению в будущих версиях) или удалённые уже в версии 9, а также рекомендации по переходу на современные альтернативы:

• vSphere Auto Deploy (устарела) – сервис автоматического развертывания ESXi-хостов по сети (PXE-boot) объявлен устаревшим. В ESX 9.0 возможность Auto Deploy (в связке с Host Profiles) будет удалена в одном из следующих выпусков линейки 9.x.
  
  Рекомендация: если вы использовали Auto Deploy для бездискового развёртывания хостов, начните планировать переход на установку ESXi на локальные диски либо использование скриптов для автоматизации установки. В дальнейшем управление конфигурацией хостов следует осуществлять через образы vLCM и vSphere Configuration Profiles, а не через загрузку по сети.

• vSphere Host Profiles (устарела) – механизм профилей хоста, позволявший применять единые настройки ко многим ESXi, будет заменён новой системой конфигураций. Начиная с vCenter 9.0, функциональность Host Profiles объявлена устаревшей и будет полностью удалена в будущих версиях.
  
  Рекомендация: вместо Host Profiles используйте vSphere Configuration Profiles, позволяющие управлять настройками на уровне кластера. Новый подход интегрирован с жизненным циклом vLCM и обеспечит более надежную и простую поддержку конфигураций.

• vSphere ESX Image Builder (устарела) – инструмент для создания кастомных образов ESXi (добавления драйверов и VIB-пакетов) больше не развивается. Функциональность Image Builder фактически поглощена возможностями vSphere Lifecycle Manager (vLCM): в vSphere 9 вы можете создавать библиотеку образов ESX на уровне vCenter и собирать желаемый образ из компонентов (драйверов, надстроек от вендоров и т.д.) прямо в vCenter.
  
  Рекомендация: для формирования образов ESXi используйте vLCM Desired State Images и новую функцию ESX Image Library в vCenter 9, которая позволит единообразно управлять образами для кластеров вместо ручной сборки ISO-файлов.

• vSphere Virtual Volumes (vVols, устарела) – технология виртуальных томов хранения объявлена устаревшей с выпуском VCF 9.0 / vSphere 9.0. Поддержка vVols отныне будет осуществляться только для критических исправлений в vSphere 8.x (VCF 5.x) до конца их поддержки. В VCF/VVF 9.1 функциональность vVols планируется полностью удалить.
  
  Рекомендация: если в вашей инфраструктуре используются хранилища на основе vVols, следует подготовиться к миграции виртуальных машин на альтернативные хранилища. Предпочтительно задействовать VMFS или vSAN, либо проверить у вашего поставщика СХД доступность поддержки vVols в VCF 9.0 (в индивидуальном порядке возможна ограниченная поддержка, по согласованию с Broadcom). В долгосрочной перспективе стратегия VMware явно смещается в сторону vSAN и NVMe, поэтому использование vVols нужно минимизировать.

• vCenter Enhanced Linked Mode (устарела) – расширенный связанный режим vCenter (ELM), позволявший объединять несколько vCenter Server в единый домен SSO с общей консолью, более не используется во VCF 9. В vCenter 9.0 ELM объявлен устаревшим и будет удалён в будущих версиях. Хотя поддержка ELM сохраняется в версии 9 для возможности обновления существующих инфраструктур, сама архитектура VCF 9 переходит на иной подход: единое управление несколькими vCenter осуществляется средствами VCF Operations вместо связанного режима.
  
  Рекомендация: при планировании VCF 9 откажитесь от развёртывания новых связанных групп vCenter. После обновления до версии 9 рассмотрите перевод существующих vCenter из ELM в раздельный режим с группированием через VCF Operations (который обеспечивает центральное управление без традиционного ELM). Функции, ранее обеспечивавшиеся ELM (единый SSO, объединённые роли, синхронизация тегов, общая точка API и пр.), теперь достигаются за счёт возможностей VCF Operations и связанных сервисов.

• vSphere Clustering Service (vCLS, устарела) – встроенный сервис кластеризации, который с vSphere 7 U1 запускал небольшие служебные ВМ (vCLS VMs) для поддержки DRS и HA, в vSphere 9 более не нужен. В vCenter 9.0 сервис vCLS помечен устаревшим и подлежит удалению в будущем. Кластеры vSphere 9 могут работать без этих вспомогательных ВМ: после обновления появится возможность включить Retreat Mode и отключить развёртывание vCLS-агентов без какого-либо ущерба для функциональности DRS/HA.
  
  Рекомендация: отключите vCLS на кластерах vSphere 9 (включив режим Retreat Mode в настройках кластера) – деактивация vCLS никак не влияет на работу DRS и HA. Внутри ESX 9 реализовано распределенное хранилище состояния кластера (embedded key-value store) непосредственно на хостах, благодаря чему кластер может сохранять и восстанавливать свою конфигурацию без внешних вспомогательных ВМ. В результате вы упростите окружение (больше никаких «мусорных» служебных ВМ) и избавитесь от связанных с ними накладных расходов.

• ESX Host Cache (устарела) - в версии ESX 9.0 использование кэша на уровне хоста (SSD) в качестве кэша с обратной записью (write-back) для файлов подкачки виртуальных машин (swap) объявлено устаревшим и будет удалено в одной из будущих версий. В качестве альтернативы предлагается использовать механизм многоуровневой памяти (Memory Tiering) на базе NVMe. Memory Tiering с NVMe позволяет увеличить объём доступной оперативной памяти на хосте и интеллектуально распределять память виртуальной машины между быстрой динамической оперативной памятью (DRAM) и NVMe-накопителем на хосте.
  
  Рекомендация: используйте функции Advanced Memory Tiering на базе NVMe-устройств в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогого оборудования.
  
  
• Память Intel Optane Persistent Memory (удалена) - в версии ESX 9.0 прекращена поддержка технологии Intel Optane Persistent Memory (PMEM). Для выбора альтернативных решений обратитесь к представителям вашего OEM-поставщика серверного оборудования.
  
  Рекомендация: в качестве альтернативы вы можете использовать функционал многоуровневой памяти (Memory Tiering), официально представленный в ESX 9.0. Эта технология позволяет добавлять локальные NVMe-устройства на хост ESX в качестве дополнительного уровня памяти. Дополнительные подробности смотрите в статье базы знаний VMware KB 326910.
  
  
• Технология Storage I/O Control (SIOC) и балансировщик нагрузки Storage DRS (удалены) - в версии vCenter 9.0 прекращена поддержка балансировщика нагрузки Storage DRS (SDRS) на основе ввода-вывода (I/O Load Balancer), балансировщика SDRS на основе резервирования ввода-вывода (SDRS I/O Reservations-based load balancer), а также компонента vSphere Storage I/O Control (SIOC). Эти функции продолжают поддерживаться в текущих релизах 8.x и 7.x. Удаление указанных компонентов затрагивает балансировку нагрузки на основе задержек ввода-вывода (I/O latency-based load balancing) и балансировку на основе резервирования ввода-вывода (I/O reservations-based load balancing) между хранилищами данных (datastores), входящими в кластер хранилищ Storage DRS. Кроме того, прекращена поддержка активации функции Storage I/O Control (SIOC) на отдельном хранилище и настройки резервирования (Reservations) и долей (Shares) с помощью политик хранения SPBM Storage Policy. При этом первоначальное размещение виртуальных машин с помощью Storage DRS (initial placement), а также балансировка нагрузки на основе свободного пространства и политик SPBM Storage Policy (для лимитов) не затронуты и продолжают работать в vCenter 9.0.
  
  Рекомендация: администраторам рекомендуется нужно перейти на балансировку нагрузки на основе свободного пространства и политик SPBM. Настройки резервирований и долей ввода-вывода (Reservations, Shares) через SPBM следует заменить альтернативными механизмами контроля производительности со стороны используемых систем хранения (например, встроенными функциями QoS). После миграции необходимо обеспечить мониторинг производительности, чтобы своевременно устранять возможные проблемы.
  
  
• vSphere Lifecycle Manager Baselines (удалена) – классический режим управления патчами через базовые уровни (baselines) в vSphere 9 не поддерживается. Начиная с vCenter 9.0 полностью удалён функционал VUM/vLCM Baselines – все кластеры и хосты должны использовать только рабочий процесс управления жизненным циклом на базе образов (image-based lifecycle). При обновлении с vSphere 8 имеющиеся кластеры на baselines придётся перевести на работу с образами, прежде чем поднять их до ESX 9.
  
  Рекомендация: перейдите от использования устаревших базовых уровней к vLCM images – желаемым образам кластера. vSphere 9 позволяет применять один образ к нескольким кластерам или хостам сразу, управлять соответствием (compliance) и обновлениями на глобальном уровне. Это упростит администрирование и устранит необходимость в ручном создании и применении множества baseline-профилей.
  
  
• Integrated Windows Authentication (IWA, удалена) – в vCenter 9.0 прекращена поддержка интегрированной Windows-аутентификации (прямого добавления vCenter в домен AD). Вместо IWA следует использовать LDAP(S) или федерацию. VMware официально заявляет, что vCenter 9.0 более не поддерживает IWA, и для обеспечения безопасного доступа необходимо мигрировать учетные записи на Active Directory over LDAPS или настроить федерацию (например, через ADFS) с многофакторной аутентификацией.
  
  Рекомендация: до обновления vCenter отключите IWA, переведите интеграцию с AD на LDAP(S), либо настройте VMware Identity Federation с MFA (эта возможность появилась начиная с vSphere 7). Это позволит сохранить доменную интеграцию vCenter в безопасном режиме после перехода на версию 9.
  
  
• Локализации интерфейса (сокращены) – В vSphere 9 уменьшено число поддерживаемых языков веб-интерфейса. Если ранее vCenter поддерживал множество языковых пакетов, то в версии 9 оставлены лишь английский (US) и три локали: японский, испанский и французский. Все остальные языки (включая русский) более недоступны.
  
  Рекомендация: администраторы, использующие интерфейс vSphere Client на других языках, должны быть готовы работать на английском либо на одной из трёх оставшихся локалей. Учебные материалы и документацию стоит ориентировать на английскую версию интерфейса, чтобы избежать недопонимания.

Общий совет по миграции для vSphere: заранее инвентаризуйте использование перечисленных функций в вашей инфраструктуре. Переход на vSphere 9 – удобный повод внедрить новые подходы: заменить Host Profiles на Configuration Profiles, перейти от VUM-бейзлайнов к образам, отказаться от ELM в пользу новых средств управления и т.д. Благодаря этому обновление пройдет более гладко, а ваша платформа будет соответствовать современным рекомендациям VMware.

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

VMware NSX 9: Устаревшие и неподдерживаемые функции

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

• Подключение физических серверов через NSX-Agent (удалено) – В NSX 9.0 больше не поддерживается развёртывание NSX bare-metal agent на физических серверах для включения их в оверлей NSX. Ранее такие агенты позволяли физическим узлам участвовать в логических сегментах NSX (оверлейных сетях). Начиная с версии 9, оверлейная взаимосвязь с физическими серверами не поддерживается – безопасность для физических серверов (DFW) остаётся, а вот L2-overlay connectivity убрана.
  
  Рекомендация: для подключения физических нагрузок к виртуальным сетям NSX теперь следует использовать L2-мосты (bridge) на NSX Edge. VMware прямо рекомендует для новых подключений физических серверов задействовать NSX Edge bridging для обеспечения L2-связности с оверлеем, вместо установки агентов на сами серверы. То есть физические серверы подключаются в VLAN, который бриджится в логический сегмент NSX через Edge Node. Это позволяет интегрировать физическую инфраструктуру с виртуальной без установки NSX компонентов на сами серверы. Если у вас были реализованы bare-metal transport node в старых версиях NSX-T 3.x, их придётся переработать на схему с Edge-бриджами перед обновлением до NSX 9. Примечание: распределённый мост Distributed TGW, появившийся в VCF 9, также может обеспечить выход ВМ напрямую на ToR без Edge-узла, что актуально для продвинутых случаев, но базовый подход – через Edge L2 bridge.

• Виртуальный коммутатор N-VDS на ESXi (удалён) – исторически NSX-T использовала собственный виртуальный коммутатор N-VDS для хостов ESXi и KVM. В NSX 9 эта технология более не применяется для ESX-хостов. Поддержка NSX N-VDS на хостах ESX удалена, начиная с NSX 4.0.0.1 (соответствует VCF 9). Теперь NSX интегрируется только с родным vSphere Distributed Switch (VDS) версии 7.0 и выше. Это означает, что все среды на ESX должны использовать конвергентный коммутатор VDS для работы NSX. N-VDS остаётся лишь в некоторых случаях: на Edge-нодах и для агентов в публичных облаках или на bare-metal Linux (где нет vSphere), но на гипервизорах ESX – больше нет.
  
  Рекомендация: перед обновлением до NSX 9 мигрируйте все транспортные узлы ESXi с N-VDS на VDS. VMware предоставила инструменты миграции host switch (начиная с NSX 3.2) – ими следует воспользоваться, чтобы перевести существующие NSX-T 3.x host transport nodes на использование VDS. После перехода на NSX 9 вы получите более тесную интеграцию сети с vCenter и упростите управление, так как сетевые политики NSX привязываются к стандартному vSphere VDS. Учтите, что NSX 9 требует наличия vCenter для настройки сетей (фактически NSX теперь не работает автономно от vSphere), поэтому планируйте инфраструктуру исходя из этого.

• Поддержка гипервизоров KVM и стороннего OpenStack (удалена) – NSX-T изначально позиционировался как мультигипервизорное решение, поддерживая кроме vSphere также KVM (Linux) и интеграцию с opensource OpenStack. Однако с выходом NSX 4.0 (и NSX 9) стратегия изменилась. NSX 9.0 больше не поддерживает гипервизоры KVM и дистрибутивы OpenStack от сторонних производителей. Поддерживается лишь VMware Integrated OpenStack (VIO) как исключение. Проще говоря, NSX сейчас нацелен исключительно на экосистему VMware.
  
  Рекомендация: если у вас были развёрнуты политики NSX на KVM-хостах или вы использовали NSX-T совместно с не-VMware OpenStack, переход на NSX 9 невозможен без изменения архитектуры. Вам следует либо остаться на старых версиях NSX-T 3.x для таких сценариев, либо заменить сетевую виртуализацию в этих средах на альтернативные решения. В рамках же VCF 9 такая ситуация маловероятна, так как VCF подразумевает vSphere-стек. Таким образом, основное действие – убедиться, что все рабочие нагрузки NSX переведены на vSphere, либо изолировать NSX-T 3.x для специфичных нужд вне VCF. В будущем VMware будет развивать NSX как часть единой платформы, поэтому мультиплатформенные возможности урезаны в пользу оптимизации под vSphere.

• NSX for vSphere (NSX-V) 6.x – не применяется – отдельно стоит упомянуть, что устаревшая платформа NSX-V (NSX 6.x для vSphere) полностью вышла из обращения и не входит в состав VCF 9. Её поддержка VMware прекращена еще в начале 2022 года, и миграция на NSX-T (NSX 4.x) стала обязательной. В VMware Cloud Foundation 4.x и выше NSX-V отсутствует, поэтому для обновления окружения старше VCF 3 потребуется заранее выполнить миграцию сетевой виртуализации на NSX-T.
  
  Рекомендация: если вы ещё используете NSX-V в старых сегментах, необходимо развернуть параллельно NSX 4.x (NSX-T) и перенести сетевые политики и сервисы (можно с помощью утилиты Migration Coordinator, если поддерживается ваша версия). Только после перехода на NSX-T вы сможете обновиться до VCF 9. В новой архитектуре все сетевые функции будут обеспечиваться NSX 9, а NSX-V останется в прошлом.

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

Итоги

Большинство приведённых выше изменений официально перечислены в документации Product Support Notes к VMware Cloud Foundation 9.0 для vSphere и NSX. Перед обновлением настоятельно рекомендуется внимательно изучить примечания к выпуску и убедиться, что ни одна из устаревших функций, на которых зависит ваша инфраструктура, не окажется критичной после перехода. Следуя рекомендациям по переходу на новые инструменты (vLCM, Configuration Profiles, Edge Bridge и т.д.), вы обеспечите своей инфраструктуре поддерживаемость и готовность к будущим обновлениям в экосистеме VMware Cloud Foundation.

Итак, наконец-то начинаем рассказывать о новых возможностях платформы виртуализации VMware vSphere 9, которая является основой пакета решений VMware Cloud Foundation 9, о релизе которого компания Broadcom объявила несколько дней назад. Самое интересное - гипервизор теперь опять называется ESX, а не ESXi, который также стал последователем ESX в свое время :)

Управление жизненным циклом

Путь обновления vSphere

vSphere 9.0 поддерживает прямое обновление только с версии vSphere 8.0. Прямое обновление с vSphere 7.0 не поддерживается. vCenter 9.0 не поддерживает управление ESX 7.0 и более ранними версиями. Минимально поддерживаемая версия ESX, которую может обслуживать vCenter 9.0, — это ESX 8.0. Кластеры и отдельные хосты, управляемые на основе baseline-конфигураций (VMware Update Manager, VUM), не поддерживаются в vSphere 9. Кластеры и хосты должны использовать управление жизненным циклом только на основе образов.

Live Patch для большего числа компонентов ESX

Функция Live Patch теперь охватывает больше компонентов образа ESX, включая vmkernel и компоненты NSX. Это увеличивает частоту применения обновлений без перезагрузки. Компоненты NSX, теперь входящие в базовый образ ESX, можно обновлять через Live Patch без перевода хостов в режим обслуживания и без необходимости эвакуировать виртуальные машины.

Компоненты vmkernel, пользовательское пространство, vmx (исполнение виртуальных машин) и NSX теперь могут использовать Live Patch. Службы ESX (например, hostd) могут потребовать перезапуска во время применения Live Patch, что может привести к кратковременному отключению хостов ESX от vCenter. Это ожидаемое поведение и не влияет на работу запущенных виртуальных машин. vSphere Lifecycle Manager сообщает, какие службы или демоны будут перезапущены в рамках устранения уязвимостей через Live Patch. Если Live Patch применяется к среде vmx (исполнение виртуальных машин), запущенные ВМ выполнят быструю приостановку и восстановление (Fast-Suspend-Resume, FSR).

Live Patch совместим с кластерами vSAN. Однако узлы-свидетели vSAN (witness nodes) не поддерживают Live Patch и будут полностью перезагружаться при обновлении. Хосты, использующие TPM и/или DPU-устройства, в настоящее время не совместимы с Live Patch.

Создавайте кластеры по-своему с разным оборудованием

vSphere Lifecycle Manager поддерживает кластеры с оборудованием от разных производителей, а также работу с несколькими менеджерами поддержки оборудования (hardware support managers) в рамках одного кластера. vSAN также поддерживает кластеры с различным оборудованием.

Базовая версия ESX является неизменной для всех дополнительных образов и не может быть настроена. Однако надстройки от производителей (vendor addon), прошивка и компоненты в определении каждого образа могут быть настроены индивидуально для поддержки кластеров с разнородным оборудованием. Каждое дополнительное определение образа может быть связано с уникальным менеджером поддержки оборудования (HSM).

Дополнительные образы можно назначать вручную для подмножества хостов в кластере или автоматически — на основе информации из BIOS, включая значения Vendor, Model, OEM String и Family. Например, можно создать кластер, состоящий из 5 хостов Dell и 5 хостов HPE: хостам Dell можно назначить одно определение образа с надстройкой от Dell и менеджером Dell HSM, а хостам HPE — другое определение образа с надстройкой от HPE и HSM от HPE.

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

Образами vSphere Lifecycle Manager и их привязками к кластерам или хостам можно управлять на глобальном уровне — через vCenter, датацентр или папку. Одно определение образа может применяться к нескольким кластерам и/или отдельным хостам из единого централизованного интерфейса. Проверка на соответствие (Compliance), предварительная проверка (Pre-check), подготовка (Stage) и устранение (Remediation) также могут выполняться на этом же глобальном уровне.

Существующие кластеры и хосты с управлением на основе базовых конфигураций (VUM)

Существующие кластеры и отдельные хосты, работающие на ESX 8.x и использующие управление на основе базовых конфигураций (VUM), могут по-прежнему управляться через vSphere Lifecycle Manager, но для обновления до ESX 9 их необходимо перевести на управление на основе образов. Новые кластеры и хосты не могут использовать управление на основе baseline-конфигураций, даже если они работают на ESX 8. Новые кластеры и хосты автоматически используют управление жизненным циклом на основе образов.

Больше контроля над операциями жизненного цикла кластера

При устранении проблем (remediation) в кластерах теперь доступна новая возможность — применять исправления к подмножеству хостов в виде пакета. Это дополняет уже существующие варианты — обновление всего кластера целиком или одного хоста за раз.

Гибкость при выборе хостов для обновления

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

Больше никакой неопределённости при обновлениях и патчах

Механизм рекомендаций vSphere Lifecycle Manager учитывает версию vCenter. Версия vCenter должна быть равной или выше целевой версии ESX. Например, если vCenter работает на версии 9.1, механизм рекомендаций не предложит обновление хостов ESX до 9.2, так как это приведёт к ситуации, где хосты будут иметь более новую версию, чем vCenter — что не поддерживается. vSphere Lifecycle Manager использует матрицу совместимости продуктов Broadcom VMware (Product Interoperability Matrix), чтобы убедиться, что целевой образ ESX совместим с текущей средой и поддерживается.

Упрощённые определения образов кластера

Компоненты vSphere HA и NSX теперь встроены в базовый образ ESX. Это делает управление их жизненным циклом и обеспечением совместимости более прозрачным и надёжным. Компоненты vSphere HA и NSX автоматически обновляются вместе с установкой патчей или обновлений базового образа ESX. Это ускоряет активацию NSX на кластерах vSphere, поскольку VIB-пакеты больше не требуется отдельно загружать и устанавливать через ESX Agent Manager (EAM).

Определение и применение конфигурации NSX для кластеров vSphere с помощью vSphere Configuration Profiles

Теперь появилась интеграция NSX с кластерами, управляемыми через vSphere Configuration Profiles. Профили транспортных узлов NSX (TNP — Transport Node Profiles) применяются с использованием vSphere Configuration Profiles. vSphere Configuration Profiles позволяют применять TNP к кластеру одновременно с другими изменениями конфигурации.

Применение TNP через NSX Manager отключено для кластеров с vSphere Configuration Profiles

Для кластеров, использующих vSphere Configuration Profiles, возможность применять TNP (Transport Node Profile) через NSX Manager отключена. Чтобы применить TNP с помощью vSphere Configuration Profiles, необходимо также задать:

• набор правил брандмауэра с параметром DVFilter=true
• настройку Syslog с параметром remote_host_max_msg_len=4096

Снижение рисков и простоев при обновлении vCenter

Функция Reduced Downtime Update (RDU) поддерживается при использовании установщика на базе CLI. Также доступны RDU API для автоматизации. RDU поддерживает как вручную настроенные топологии vCenter HA, так и любые другие топологии vCenter. RDU является рекомендуемым способом обновления, апгрейда или установки патчей для vCenter 9.0.

Обновление vCenter с использованием RDU можно выполнять через vSphere Client, CLI или API. Интерфейс управления виртуальным устройством (VAMI) и соответствующие API для патчинга также могут использоваться для обновлений без переустановки или миграции, однако при этом потребуется значительное время простоя.

Сетевые настройки целевой виртуальной машины vCenter поддерживают автоматическую конфигурацию, упрощающую передачу данных с исходного vCenter. Эта сеть автоматически настраивается на целевой и исходной виртуальных машинах vCenter с использованием адреса из диапазона Link-Local RFC3927 169.254.0.0/16. Это означает, что не требуется указывать статический IP-адрес или использовать DHCP для временной сети.

Этап переключения (switchover) может выполняться вручную, автоматически или теперь может быть запланирован на конкретную дату и время в будущем.

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

Масштабирование объема памяти с более низкой стоимостью владения благодаря Memory Tiering с использованием NVMe

Memory Tiering использует устройства NVMe на шине PCIe как второй уровень оперативной памяти, что увеличивает доступный объем памяти на хосте ESX. Memory Tiering на базе NVMe снижает общую стоимость владения (TCO) и повышает плотность размещения виртуальных машин, направляя память ВМ либо на устройства NVMe, либо на более быструю оперативную память DRAM.

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

Функция Memory Tiering теперь доступна в производственной среде. В vSphere 8.0 Update 3 функция Memory Tiering была представлена в режиме технологического превью. Теперь же она стала доступна в режиме GA (General Availability) с выпуском VCF 9.0. Это позволяет использовать локально установленные устройства NVMe на хостах ESX как часть многоуровневой (tiered) памяти.

Повышенное время безотказной работы для AI/ML-нагрузок

Механизм Fast-Suspend-Resume (FSR) теперь работает значительно быстрее для виртуальных машин с поддержкой vGPU. Ранее при использовании двух видеокарт NVIDIA L40 с 48 ГБ памяти каждая, операция FSR занимала около 42 секунд. Теперь — всего около 2 секунд. FSR позволяет использовать Live Patch в кластерах, обрабатывающих задачи генеративного AI (Gen AI), без прерывания работы виртуальных машин.

Передача данных vGPU с высокой пропускной способностью

Канал передачи данных vGPU разработан для перемещения больших объемов данных и построен с использованием нескольких параллельных TCP-соединений и автоматического масштабирования до максимально доступной пропускной способности канала, обеспечивая прирост скорости до 3 раз (с 10 Гбит/с до 30 Гбит/с).

Благодаря использованию концепции "zero copy" количество операций копирования данных сокращается вдвое, устраняя узкое место, связанное с копированием, и дополнительно увеличивая пропускную способность при передаче.

vMotion с предкопированием (pre-copy) — это технология передачи памяти виртуальной машины на другой хост с минимальным временем простоя. Память виртуальной машины (как "холодная", так и "горячая") копируется в несколько проходов пока ВМ ещё работает, что устраняет необходимость полного чекпойнта и передачи всей памяти во время паузы, во время которой случается простой сервисов.

Улучшения в предкопировании холодных данных могут зависеть от характера нагрузки. Например, для задачи генеративного AI с большим объёмом статических данных ожидаемое время приостановки (stun-time) будет примерно:

• ~1 секунда для GPU-нагрузки объёмом 24 ГБ
• ~2 секунды для 48 ГБ
• ~22 секунды для крупной 640 ГБ GPU-нагрузки

Отображение профилей vGPU в vSphere DRS

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

Отслеживание использования vGPU-профилей позволяет администраторам просматривать все vGPU во всей инфраструктуре GPU через удобный интерфейс в vCenter, устраняя необходимость ручного учёта vGPU. Это существенно сокращает время, затрачиваемое администраторами на управление ресурсами.

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

Администраторы теперь могут перемещать существующие библиотеки контента на новые хранилища данных (datastore) - OVF/OVA-шаблоны, образы и другие элементы могут быть перенесены. Элементы, хранящиеся в формате VM Template (VMTX), не переносятся в целевой каталог библиотеки контента. Шаблоны виртуальных машин (VM Templates) всегда остаются в своем назначенном хранилище, а в библиотеке контента хранятся только ссылки на них.

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

Служба виртуальных машин (VM Service) теперь может импортировать виртуальные машины, находящиеся за пределами Supervisor-кластера, и взять их под своё управление.

В vSphere 8 был представлен протокол Unified Data Transport (UDT) для "холодной" миграции дисков, ранее выполнявшейся с использованием NFC. UDT значительно ускоряет холодную миграцию, но вместе с повышенной эффективностью увеличивается и нагрузка на сеть предоставления ресурсов (provisioning network), которая в текущей архитектуре использует общий канал с критически важным трафиком управления.

Чтобы предотвратить деградацию трафика управления, необходимо использовать Network I/O Control (NIOC) — он позволяет гарантировать приоритет управления даже при высокой сетевой нагрузке.

vSphere Distributed Switch 9 добавляет отдельную категорию системного трафика для provisioning, что позволяет применять настройки NIOC и обеспечить баланс между производительностью и стабильностью.

Provisioning/NFC-трафик (включая Network File Copy) является тяжеловесным и низкоприоритетным, но при этом использует ту же категорию трафика, что и управляющий (management), который должен быть легковесным и высокоприоритетным. С учетом того, что трафик provisioning/NFC стал ещё более агрессивным с внедрением NFC SOV (Streaming Over vMotion), вопрос времени, когда критически важный трафик управления начнёт страдать.

Существует договоренность с VCF: как только NIOC для provisioning/NFC будет реализован, можно будет включать NFC SOV в развёртываниях VCF. Это ускорит внедрение NFC SOV в продуктивных средах.

Устройства, которые не могут быть приостановлены (non-stunnable devices), теперь поддерживают Storage vMotion (но не обычный vMotion), а также горячее добавление виртуальных устройств, таких как:

• vCPU
• Память (Memory)
• Сетевые адаптеры (NIC)

Примеры non-stunnable устройств:

• Intel DLB (Dynamic Load Balancer)
• AMD MI200 GPU

Гостевые ОС и рабочие нагрузки

Виртуальное оборудование версии 22 (Virtual Hardware Version 22)

• Увеличен лимит vCPU до 960 на одну виртуальную машину
• Поддержка новейших моделей процессоров от AMD и Intel
• Поддержка новых версий гостевых ОС для развертывания ВМ (см. Guest OS Support в VCF 9.0)

Виртуальный модуль доверенной платформы (vTPM)

• vTPM теперь поддерживает спецификацию TPM 2.0, версия 1.59.
• ESX 9.0 соответствует TPM 2.0 Rev 1.59.
• Это повышает уровень кибербезопасности, когда вы добавляете vTPM-устройство в виртуальную машину с версией 22 виртуального железа.

Новые vAPI для настройки гостевых систем (Guest Customization)

Представлен новый интерфейс CustomizationLive API, который позволяет применять спецификацию настройки (customization spec) к виртуальной машине в работающем состоянии (без выключения). Подробности — в последней документации по vSphere Automation API для VCF 9.0. Также добавлен новый API для настройки гостевых систем, который позволяет определить, можно ли применить настройку к конкретной ВМ, ещё до её применения.

• Namespace Write Protection - позволяет горячее добавление независимых непостоянных (non-persistent) дисков в виртуальную машину без создания дополнительных delta-дисков. Эта функция особенно полезна для рабочих нагрузок, которым требуется быстрое развёртывание приложений.
• Write Zeros - для виртуальных NVMe-дисков улучшает производительность, эффективность хранения данных и дает возможности управления данными для различных типов нагрузок.

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

Одним из частых запросов в последние годы была возможность использовать собственные сертификаты Secure Boot для ВМ. Обычно виртуальные машины работают "из коробки" с коммерческими ОС, но некоторые организации используют собственные ядра Linux и внутреннюю PKI-инфраструктуру для их подписи.

Теперь появилась прямая и удобная поддержка такой конфигурации — vSphere предоставляет механизм для загрузки виртуальных машин с кастомными сертификатами Secure Boot.

Обновлён список отозванных сертификатов Secure Boot

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

Виртуальный USB — отличная функция, но VMware внесла ряд улучшений на основе отчётов исследователей по безопасности. Это ещё один веский аргумент в пользу того, чтобы поддерживать актуальность VMware Tools и версий виртуального оборудования.

Обычно мы стремимся к тому, чтобы снапшот ВМ можно было запустить повторно и обеспечить согласованность при сбое (crash-consistency), то есть чтобы система выглядела как будто питание отключилось. Большинство ОС, СУБД и приложений умеют с этим справляться.

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

Теперь вы можете создавать собственный профиль EVC (Enhanced vMotion Compatibility), определяя набор CPU- и графических инструкций, общих для всех выбранных хостов. Это решение более гибкое и динамичное, чем стандартные предустановленные профили EVC.

Custom EVC позволяет:

• Указать хосты и/или кластеры, для которых vCenter сам рассчитает максимально возможный общий набор инструкций
• Применять полученный профиль к кластерам или отдельным ВМ

Для работы требуется vCenter 9.0 и поддержка кластеров, содержащих хосты ESX 9.0 или 8.0. Теперь доступно более эффективное использование возможностей CPU при различиях между моделями - можно полнее использовать функции процессоров, даже если модели немного отличаются. Пример: два процессора одного поколения, но разных вариантов:

• CPU-1 содержит функции A, B, D, E, F
• CPU-2 содержит функции B, C, D, E, F
• То есть: CPU-1 поддерживает FEATURE-A, но не FEATURE-C, CPU-2 — наоборот.

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

В vSphere 9 появилась новая политика вычислений: «Limit VM placement span plus one host for maintenance» («ограничить размещение ВМ числом хостов плюс один для обслуживания»).

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

Больше не нужно вручную закреплять ВМ за хостами или создавать отдельные кластеры/хосты. Теперь администратору нужно просто:

1. Знать, сколько лицензий куплено.
2. Знать, на скольких хостах они могут применяться.
3. Создать политику с указанием числа хостов, без выбора конкретных.
4. Применить эту политику к ВМ с нужным тегом.

vSphere сама гарантирует, что такие ВМ смогут запускаться только на разрешённом числе хостов. Всегда учитывается N+1 хост в запас для обслуживания. Ограничение динамическое — не привязано к конкретным хостам.

Полный список новых возможностей VMware vSphere 9 также приведен в Release Notes.

Хорошая новость для энтузиастов облачных технологий! Готовы значительно прокачать свои навыки? С выходом VMware Cloud Foundation 9.0 появились новые интерактивные лабораторные работы (Hands-on Labs, HoL), доступные для самостоятельного изучения! Они специально созданы для того, чтобы быстро и эффективно освоить VCF 9.0 и входящие в ее состав новые версии продуктов.

Вот список новых лабораторий, доступных прямо сейчас:

• Что нового в VMware Cloud Foundation 9.0 – платформа (HOL-2610-01-VCF-L)
  Изучите VCF 9.0! Узнайте основные концепции VCF, развертывание с помощью VCF Installer и увеличьте продуктивность с виртуальными частными облаками (VPC) и транзитными шлюзами.
• Что нового в VMware Cloud Foundation 9.0 – автоматизация (HOL-2610-02-VCF-L)
  Эта лаба поможет освоить автоматизацию VMware Cloud Foundation, начиная с быстрой настройки организаций арендаторов. Изучите портал провайдера (инфраструктура, доступ, идентификация) и управление организацией (библиотеки контента, политики IaaS). Получите практический опыт развёртывания виртуальных машин и кластеров Kubernetes.
• Что нового в VMware Cloud Foundation 9.0 – операции (HOL-2610-03-VCF-L)
  Эта лаба охватывает мониторинг состояния частного облака, анализ сетевого трафика, управление хранилищами и vSAN, операции безопасности и реализацию подсчёта затрат. Получите практические навыки единого мониторинга, устранения неполадок и внедрения лучших практик для эффективного управления, защиты и оптимизации вашего частного облака.
• Объединённое управление виртуальными машинами и Kubernetes с помощью vSphere Supervisor в VMware Cloud Foundation 9.0 (HOL-2633-01-VCF-L)
  Эта лаба научит объединённому управлению виртуальными машинами и кластерами Kubernetes с помощью vSphere Supervisor. Изучите концепции и компоненты vSphere Supervisor, включая взаимодействие с vCenter и vSphere. Включите и настройте vSphere Supervisor и разверните кластеры Kubernetes и vSphere POD вместе с виртуальными машинами.
• Что нового в vSphere на платформе VMware Cloud Foundation 9.0 (HOL-2630-01-VCF-L)
  Лаба охватывает упрощённое единое лицензирование, улучшенное многоуровневое использование памяти, онлайн-обновление без простоев, управление мультивендорными кластерами и улучшения Lifecycle Manager, сокращающие административную нагрузку благодаря образам уровня кластера.

Hands-on Labs зарекомендовали себя как ценный ресурс для обучения:

• Доступны и бесплатны: изучайте передовые облачные технологии совершенно бесплатно.
• Гибкость в обучении: выбирайте свой темп и график.
• Онлайн-доступ 24/7: пользуйтесь лабораториями в любое время и из любого места.
• Без необходимости установки: сразу приступайте к обучению, не тратя время на установку или настройку программного обеспечения.
• Повторяемость лабораторий: закрепляйте полученные знания, повторяя лаборатории столько раз, сколько пожелаете.
• Изучайте в собственном темпе: проходите материалы в удобном для вас ритме для лучшего усвоения информации.
• Практический опыт: получайте реальные навыки в интерактивных условиях с использованием VMware Cloud Foundation 9.0 и других продуктов VMware.

Нажмите сюда, чтобы получить доступ к каталогу лабораторий VMware Cloud Foundation 9.0 и начать своё обучение.

Многоуровневая память (Memory Tiering) снижает затраты и повышает эффективность использования ресурсов. Эта функция была впервые представлена в виде технологического превью в vSphere 8.0 Update 3 и получила очень положительные отзывы от клиентов. Обратная связь от пользователей касалась в основном устойчивости данных, безопасности и гибкости в конфигурациях хостов и виртуальных машин. С выходом платформы VCF 9.0 все эти вопросы были решены.

Теперь многоуровневая память — это готовое к использованию в производственной среде решение, включающее поддержку DRS и vMotion, повышенную производительность, улучшенное соотношение DRAM:NVMe по умолчанию (1:1), а также множество других улучшений, направленных на повышение надёжности этой функции.

В компании Broadcom было проведено масштабное внутреннее тестирование, которое показало, что использование многоуровневой памяти позволяет сократить совокупную стоимость владения (TCO) до 40% для большинства рабочих нагрузок, а также обеспечивает рост загрузки CPU, позволяя использовать на 25–30% больше ядер под задачи. Меньше затрат — больше ресурсов. Кроме того, лучшая консолидация ВМ может означать меньше серверов или больше ВМ на каждом сервере.

Многоуровневая память обеспечивает все эти и многие другие преимущества, используя NVMe-устройства в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогих устройств, таких как NVMe. Между предварительной технической версией и готовым к промышленному использованию выпуском с VCF 9.0 существует множество важных отличий. Давайте рассмотрим эти улучшения.

Новые возможности Advanced Memory Tiering

Смешанный кластер

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

Резервирование

Резервирование всегда является приоритетом при проектировании архитектуры. Как вы знаете, не бывает серьезной производственной среды с одной единственной сетевой картой на сервер. Что касается накопителей, то обеспечить отказоустойчивость можно с помощью конфигурации RAID — именно это и было реализовано. Многоуровневая память может использовать два и более NVMe-устройств в аппаратной RAID-конфигурации для защиты от отказов устройств.

Поддержка DRS

Технология DRS (Distributed Resource Scheduler) существует уже довольно давно, это одна из функций, без которой большинство клиентов уже не могут обходиться. VMware вложила много усилий в то, чтобы сделать алгоритм Memory Tiering «умным» — чтобы он не только анализировал состояние страниц памяти, но и эффективно управлял ими в пределах кластера.

DRAM:NVMe — новое соотношение

В vSphere 8.0 U3 функция Memory Tiering была представлена как технологическое превью. Тогда использовалось соотношение 4:1, то есть на 4 части DRAM приходилась 1 часть NVMe. Это дало увеличение объёма памяти на 25%. Хотя это может показаться незначительным, при сравнении стоимости увеличения объёма памяти на 25% с использованием DRAM и NVMe становится очевидно, насколько это выгодно.

В VCF 9.0, после всех улучшений производительности, изменили соотношение по умолчанию: теперь оно 1:1 — то есть увеличение объема памяти в 2 раза по умолчанию. И это значение можно настраивать в зависимости от нагрузки и потребностей. То есть, если у вас есть хост ESX с 1 ТБ DRAM и вы включаете Memory Tiering, вы можете получить 2 ТБ доступной памяти. Для некоторых сценариев, таких как VDI, возможно соотношение до 1:4 — это позволяет вчетверо увеличить объём памяти при минимальных затратах.

Другие улучшения

В VCF 9.0 было реализовано множество других улучшений функции Memory Tiering. Общие улучшения производительности сделали решение более надёжным, гибким, отказоустойчивым и безопасным. С точки зрения безопасности добавлено шифрование: как на уровне виртуальных машин, так и на уровне хоста. Страницы памяти ВМ теперь могут быть зашифрованы индивидуально для каждой ВМ или сразу для всех машин на хосте — с помощью простой и удобной настройки.

Как начать использовать Advanced Memory Tiering

С чего начать? Как понять, подходят ли ваши рабочие нагрузки для Memory Tiering? Клиентам стоит учитывать следующие факторы при принятии решения о внедрении Memory Tiering:

Активная память

Memory Tiering особенно подходит для клиентов с высоким потреблением (выделено под ВМ более 50%) и низким уровнем активного использования памяти (фактически используемая нагрузками — менее 50% от общего объема DRAM).

Скриншот ниже показывает, как можно отслеживать активную память и объём DRAM с помощью vCenter:

NVMe-устройства

Существуют рекомендации по производительности и ресурсу для поддерживаемых накопителей — в руководстве по совместимости Broadcom (VMware) указано более 1500 одобренных моделей. NVMe-накопители, такие как E3.S, являются модульными и зачастую могут быть установлены в свободные слоты серверов, например, как в Dell PowerEdge, показанном ниже. VMware настоятельно рекомендует клиентам обращаться к руководству по совместимости Broadcom, чтобы обеспечить нужный уровень производительности своих рабочих нагрузок за счёт выбора рекомендованных устройств.

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

Дункан Эппинг рассказал о том, как можно убедиться, что ваши диски VMware vSAN зашифрованы.

Если у вас включена техника шифрования "vSAN Encryption – Data At Rest", то вы можете проверить, что действительно данные на этих дисках зашифрованы в разделе настроек vSAN в клиенте vSphere Client. Однако вы можете сделать это и на уровне хоста ESXi, выполнив команду:

esxcli vsan storage list

Как вы можете увидеть из вывода команды, для шифрования указан параметр Encryption: true.

Второй момент - вам надо убедиться, что служба управления ключами шифрования Key Management System доступна и работает как положено. Это вы можете увидеть в разделе vSAN Skyline Health клиента vSphere:

Дункан также обращает внимание, что если вы используете Native Key Server и получаете ошибку "not available on host", проверьте, опцию "Use key provider only with TPM". Если она включена, то вы должны иметь модуль TPM для корректной работы механизмов шифрования. Если у вас модуля такого нет - просто снимите эту галочку.

Есть вопрос, который администраторы платформы виртуализации VMware vSphere задают регулярно:

Какие идеальные соотношения vCPU к pCPU я должен планировать и поддерживать для максимальной производительности? Как учитывать многопоточность Hyper-Threading и Simultaneous Multithreading в этом соотношении?

Ответ?

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

Раньше мы пользовались рекомендациями вроде 4 vCPU на 1 pCPU (4:1) или даже 10:1, но этот подход основывался на негласной предпосылке — рабочие нагрузки в основном были в простое. Многие организации начинали свою виртуализацию с консолидации наименее нагруженных систем, и в таких случаях высокое соотношение vCPU:pCPU было вполне обычным явлением.

Так появилась концепция коэффициента консолидации, ставшая основой для планирования ресурсов в виртуальных средах. Даже возникала конкуренция: кто сможет добиться более высокого уровня консолидации. Позже появились технологии вроде Intel Hyper-Threading и AMD SMT (Simultaneous Multithreading), которые позволяли достичь ещё большей консолидации. Тогда расчёт стал сложнее: нужно было учитывать не только физические ядра, но и логические потоки. Огромные Excel-таблицы превратились в операционные панели мониторинга ресурсов.

Но этот подход к планированию и эксплуатации устарел. Высокая динамика изменений в инфраструктуре заказчиков и рост потребления ресурсов со стороны виртуальных машин сделали модель статического соотношения нежизнеспособной. К тому же, с переходом к политике virtual-first, многие компании больше не тестируют приложения на "голом железе" до виртуализации.

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

Вместо этого нужно "управлять по конкуренции" (drive by contention)

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

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

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

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

• Логические CPU не равно физические CPU/ядра (в случае гиперпоточности)
• Важность точного подбора размеров виртуальных машин (right-sizing)

Ключевым фактором снижения рисков становится время вашей реакции на проблемы с производительностью или ёмкостью.

Если обеспечить быструю реакцию пока невозможно — начните с консервативного соотношения 1:1 vCPU:pCPU, не учитывая гиперпоточность. Это безопасный старт. По мере роста зрелости вашей инфраструктуры, процессов и инструментов, соотношение будет естественно улучшаться.

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

Вкратце:

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

По умолчанию скорость соединения (link speed) адаптера vmxnet3 виртуальной машины устанавливается как 10 Гбит/с. Это применяемое по умолчанию отображаемое значение в гостевой ОС для соединений с любой скоростью. Реальная скорость будет зависеть от используемого вами оборудования (сетевой карты).

VMXNET 3 — это паравиртуализированный сетевой адаптер, разработанный для обеспечения высокой производительности. Он включает в себя все функции, доступные в VMXNET 2, и добавляет несколько новых возможностей, таких как поддержка нескольких очередей (также известная как Receive Side Scaling в Windows), аппаратное ускорение IPv6 и доставка прерываний с использованием MSI/MSI-X. VMXNET 3 не связан с VMXNET или VMXNET 2.

Если вы выведите свойства соединения на адаптере, то получите вот такую картину:

В статье Broadcom KB 368812 рассказывается о том, как с помощью расширенных настроек виртуальной машины можно установить корректную скорость соединения. Для этого выключаем ВМ, идем в Edit Settings и на вкладке Advanced Parameters добавляем нужное значение:

ethernet0.linkspeed    20000

Также вы можете сделать то же самое, просто добавив в vmx-файл виртуальной машины строчку ethernetX.linkspeed = "ХХХ".

При этом учитывайте следующие моменты:

• Начиная с vSphere 8.0.2 и выше, vmxnet3 поддерживает скорость соединения в диапазоне от 10 Гбит/с до 65 Гбит/с.
• Значение скорости по умолчанию — 10 Гбит/с.
• Если вами указано значение скорости меньше 10000, то оно автоматически устанавливается в 10 Гбит/с.
• Если вами указано значение больше 65000, скорость также будет установлена по умолчанию — 10 Гбит/с.

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

Это изменение предназначено для обхода ограничений на уровне операционной системы или приложений, которые могут возникать из-за того, что адаптер vmxnet3 по умолчанию определяется со скоростью 10 Гбит/с.

Интеграция VMware vCenter Server с Active Directory (AD) позволяет централизовать управление учетными записями и упростить администрирование доступа. Вместо локальной базы пользователей vCenter можно использовать доменную инфраструктуру AD или другой LDAP-сервис как единый источник аутентификации. Это означает, что администраторы vSphere смогут применять те же учетные записи и группы, что и для остальных ресурсов сети, для доступа к объектам vSphere.

VMware/Broadcom представили новую сертификацию — VMware Certified Professional – Private Cloud Security Administrator (VCP-PCS), которая подтверждает квалификацию специалистов по обеспечению безопасности в среде VMware Cloud Foundation (VCF) с использованием решений VMware vDefend. Это важный шаг в направлении усиления защиты частных облаков, особенно в условиях растущего спроса на модели Zero Trust и комплексные меры кибербезопасности.

Что представляет собой VCP-PCS?

Сертификация VCP-PCS предназначена для специалистов, отвечающих за безопасность VCF, включая:

• Архитекторов и инженеров облачной инфраструктуры
• Администраторов виртуальной инфраструктуры
• Системных администраторов
• Специалистов по поддержке и внедрению решений

VCP-PCS подтверждает способность кандидата:

• Настраивать и управлять распределёнными и шлюзовыми межсетевыми экранами
• Реализовывать защиту от продвинутых угроз
• Внедрять архитектуру Zero Trust с использованием VMware vDefend
• Использовать аналитические инструменты и средства безопасности для мониторинга и реагирования на инциденты

Подготовка и экзамен

Для получения сертификации необходимо:

• Курс: VMware vDefend Security for VCF 5.x Administrator
• Темы: архитектура vDefend, управление политиками безопасности, практическое применение в VCF

• Название: VMware vDefend Security for VCF 5.x Administrator (6V0-21.25)
• Формат: 75 вопросов (множественный выбор и множественные ответы)
• Продолжительность: 90 минут
• Проходной балл: 70%
• Язык: английский
• Стоимость: $250
• Регистрация: через портал сертификации VMware

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

Сертификация VCP-PCS демонстрирует вашу способность:

• Обеспечивать безопасность в современных частных облаках
• Внедрять и поддерживать архитектуру Zero Trust
• Использовать инструменты VMware vDefend для защиты инфраструктуры

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

Недавно мы писали о программном доступе к спискам совместимости Broadcom Compatibility Guide (BCG), а на днях стало известно, что ключевой компонент платформы VMware Cloud Foundation 9 - платформа VMware vSphere 9 - уже присутствует в BCG, так что можно проверять свои серверы и хранилища на предмет совместимости с VMware ESXi 9.0 и VMware vSAN 9.0:

Кстати в списках совместимости с vVols не указан VMware ESXi 9, так как эта технология будет признана deprecated в следующей версии платформы (и окончательно перестанет поддерживаться в vSphere 9.1).

Имейте в виду, что список совместимости еще может поменяться к моменту финального релиза VMware vSphere 9, но ориентироваться на это для планирования закупок можно уже сейчас.

Возможно, вас смутило выражение «ВМ на голом железе» в заголовке. Но это не опечатка: в этом посте мы расскажем о двух ключевых вещах, а основная тема, которую мы рассмотрим — это запуск виртуальных машин (ВМ) как контейнеров в среде Kubernetes. Поэтому в этой статье будет две основные цели:

1. Раскрыть преимущества запуска ВМ и контейнеров на единой платформе. Да, этой единой платформой является служба vSphere Kubernetes Service в VMware Cloud Foundation.

2. Объяснить, почему запуск ВМ и контейнеров на «голом железе» имеет реальные недостатки для предприятий, чтобы вы могли сделать собственные выводы. Мы приведем факты, которые вы сможете проверить независимо от каких-либо поставщиков.

Начнём с того, что разберёмся, что такое служба vSphere Kubernetes Service (далее — VKS) и что она предлагает.

Что такое VKS?

VKS — это промышленный Kubernetes-рантайм от VMware, сертифицированный и совместимый с CNCF (Cloud Native Computing Foundation). Он включён в состав VMware Cloud Foundation (то есть доплачивать за него не нужно), поддерживается и уже доступен.

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

Это даёт клиентам беспрецедентные возможности запускать промышленный Kubernetes у себя на площадке — в более удобной и масштабируемой форме.

Кроме того, для приверженцев философии FOSS (свободного и открытого ПО) есть над чем задуматься:

• За последнее десятилетие VMware входила в тройку крупнейших участников по объёму вклада в исходный код Kubernetes.
• Соответствие стандарту CNCF означает, что VMware придерживается открытых стандартов. Это важно, поскольку вы получаете гибкость и можете рассчитывать на определённый набор компонентов в платформе, не попадая в ловушку специфических для конкретного вендора решений и ограничений.
• VKS развивался с тех пор, как VMware приобрела компанию Pivotal в 2019 году, так что это далеко не «версия 1.0».

Несколько слов о vSphere Supervisor

Чтобы начать использовать VKS, вам нужно установить vSphere Supervisor. Он предоставляет, помимо прочего, возможность использовать все преимущества VMware, а также предлагает компоненты, совместимые с Kubernetes.

Один из примеров: как только vSphere Supervisor будет запущен, вы создаёте пространство имен Kubernetes Namespace, которое будет сопоставлено с пулом ресурсов vSphere. Внутри кластера Kubernetes Namespace будет вести себя так, как и положено, но при этом его ресурсами можно также управлять через интерфейс vSphere для пулов ресурсов.

Другой пример: управляющие и рабочие узлы Kubernetes в буквальном смысле являются виртуальными машинами (ВМ). Это важно для следующего момента, который будет раскрыт далее.

Обратите внимание: «традиционные» виртуальные машины продолжают работать бок о бок с вашими кластерами Kubernetes. Именно такую возможность даёт VKS в составе VMware Cloud Foundation (VCF).

Если вы запомните только одну вещь из этого поста, пусть это будет следующее:

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

Развенчиваем миф о запуске ВМ и контейнеров на «голом железе»

Интересный факт: когда вы разворачиваете кластер Kubernetes у гиперскейлера (большой публичный облачный провайдер), этот кластер на самом деле работает на наборе виртуальных машин под управлением гипервизора. Это справедливо для всех гиперскейлеров на момент написания статьи. Контейнеры, в итоге, не работают напрямую на голом железе — такого просто не существует. VMware подчеркивает это, потому что они видели, как и C-level руководители, и разработчики, и даже инженеры платформ (которые вроде бы должны это знать) были поражены этим фактом.

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

В результате организации начинают задумываться о:

• запуске контейнеров напрямую на голом железе;
• запуске традиционных ВМ в виде контейнеров на голом железе.

Начнём с первого: запуск контейнеров на голом железе мог бы быть темой горячих споров… если бы сейчас был 2017 год. Эта дискуссия в индустрии уже была, и виртуализированная платформа с Kubernetes одержала убедительную победу.

Почему? В числе причин: более простое управление, масштабируемость, гибкость, меньшая стоимость и практически полное отсутствие потерь в производительности. Не сказать, что у контейнеров на железе совсем нет применения, но для 98% организаций запуск контейнеров на гипервизоре оказался более выгодным решением.

Простой пример: вспомните, какие возможности даёт вам архитектура отказоустойчивости vSphere HA — ваши контейнеры в виде ВМ отлично вписываются в эту архитектуру уже на этом одном примере.

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

А как насчёт запуска ВМ как контейнеров? Во-первых, у VMware есть доказательства того, что их платформа обеспечивает лучшую производительность и масштабируемость. Например, при создании ВМ через VM Service, инженеру не нужно разбираться в деталях и компонентах Kubernetes. Обычно это лучшее решение, потому что командам не нужно проходить дорогостоящее переобучение или нанимать более дорогих специалистов, чтобы запускать ВМ внутри кластера Kubernetes.

Когда вы увидите, насколько просто получить низкую совокупную стоимость владения (TCO) с промышленной виртуализацией, которую легко внедрить (и снова напомним про vSphere HA, которая настраивается буквально двумя кликами), становится очевидно: запуск VKS в составе VCF — разумное и эффективное решение.

Источник.

Разбор сложного HTML — это, безусловно, непростая задача, даже с PowerShell. Вильям Лам недавно пытался использовать бесплатную версию ChatGPT и новую модель 4o, чтобы сделать функцию на PowerShell для парсинга HTML, но он постоянно сталкивался с системными ограничениями, а AI часто неправильно понимал, чего от него хотят.

По запросу одного из пользователей он пытался расширить свою статью в блоге за 2017 год об автоматизации глобальных прав vSphere и добавить поддержку их вывода через PowerCLI.

Оказалось, что получить список всех текущих глобальных прав окружения VMware vSphere через приватный API vSphere Global Permissions с помощью vSphere MOB крайне трудно из-за сложного HTML, который рендерит этот интерфейс. На самом деле, Вильяму понадобилось 25 итераций, прежде чем он нашёл рабочее решение с помощью модели ChatGPT 4o. В нескольких попытках прогресс даже откатывался назад — и это было довольно раздражающе.

В итоге, теперь есть файл GlobalPermissions.ps1, который содержит новую функцию Get-GlobalPermission. Эта функция извлекает все глобальные права vSphere, включая имя субъекта (principal), назначенную роль vSphere и то, где именно эта роль определена (глобальное право или право в рамках inventory сервера vCenter).

Ниже приведён пример использования новой функции — перед этим потребуется выполнить Connect-VIServer, чтобы можно было сопоставить ID роли vSphere, полученный из функции, с её реальным именем, которое возвращается встроенным командлетом PowerCLI.

$vc_server = "vc03.williamlam.local"
$vc_username = "*protected email*"
$vc_password = "VMware1!"

$server = Connect-VIServer -Server $vc_server -User $vc_username -Password $vc_password

Get-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password

Disconnect-viserver $server -confirm:$false

Ниже приведен результат работы этой функции:

Начиная с ноября 2024 года, VMware vSphere Foundation (VVF) начала включать 0,25 ТиБ ёмкости vSAN на одно ядро для всех новых лицензий VVF. С выходом обновления vSphere 8.0 U3e это преимущество распространяется и на существующих клиентов — теперь им также доступна ёмкость vSAN из расчёта 0,25 ТиБ (аналог терабайта) на ядро. Это новое право на использование включает дополнительные преимущества, которые повышают ценность vSAN в составе VVF.

Вот как это работает:

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

Новые преимущества для текущих клиентов:

• Больше никаких ограничений пробной версии: включённые 0,25 ТиБ на ядро теперь полностью предоставлены по лицензии, а не в рамках пробного периода.
• Агрегация ёмкости: объединяйте хранилище между кластерами и используйте его там, где это нужнее всего.
• Упрощённое масштабирование: если требуется больше хранилища, чем предусмотрено по включённой норме — достаточно просто докупить нужный объём сверх этой квоты.

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

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

Дополнительная ёмкость vSAN в составе VMware vSphere Foundation значительно повышает ценность платформы — будь то оптимизация частного облака, повышение гибкости разработки или упрощение ИТ-операций. Это даёт больше контроля и гибкости над инфраструктурой, снижая совокупную стоимость владения и минимизируя операционные издержки.

Чтобы начать пользоваться бесплатной лицензией VMware vSAN загрузите патч vSphere 8.0 Update 3e по этой ссылке.

В последнее время в индустрии виртуализации наблюдалась тревожная тенденция — крупнейшие игроки начали отказываться от бесплатных версий своих гипервизоров. После покупки VMware компанией Broadcom одной из первых резонансных новостей стало прекращение распространения бесплатного гипервизора VMware ESXi (ранее известного как vSphere Hypervisor). Это решение вызвало волну недовольства в сообществе, особенно среди ИТ-специалистов и малых компаний, использующих ESXi в тестовых или домашних лабораториях.

Однако 11 апреля 2025 года ситуация неожиданно изменилась. В официальных Release Notes к обновлению VMware ESXi 8.0 Update 3e появилось упоминание о новой бесплатной редакции гипервизора, которая теперь снова доступна для скачивания и установки.

Что произошло?

• Ранее: Broadcom, завершив поглощение VMware, прекратила предоставление бесплатной версии vSphere Hypervisor. Это вызвало резкую критику и обеспокоенность среди пользователей, привыкших использовать ESXi в учебных, тестовых или малобюджетных инфраструктурах.

• Теперь: В составе релиза ESXi 8.0 Update 3e появилась entry-level редакция гипервизора, которая предоставляется бесплатно, как указано в разделе "What's New" официальной документации Broadcom. Хотя точных технических ограничений этой редакции пока не раскрыто в деталях, уже ясно, что она рассчитана на начальный уровень использования и доступна без подписки.

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

Возвращение бесплатной версии гипервизора от Broadcom означает, что:

• Независимые администраторы и энтузиасты снова могут использовать ESXi в личных или образовательных целях.
• Организации с ограниченным бюджетом могут рассматривать VMware как вариант для пилотных проектов.
• Broadcom, вероятно, отреагировала на давление сообщества и рынка.

Новые возможности VMware 8.0 Update 3e:

Начиная с версии ESXi 8.0 Update 3e, USB-драйвер ESXi поддерживает протокол CDC-NCM для обеспечения совместимости с виртуальным сетевым адаптером HPE Gen12 iLO (iLO Virtual NIC) и взаимодействия с такими инструментами, как HPE Agentless Management (AMS), Integrated Smart Update Tools (iSUT), iLORest (инструмент настройки), Intelligent Provisioning, а также DPU.

• Intel vRAN Baseband Driver
• Intel Platform Monitoring Technology Driver
• Intel Data Center Graphics Driver
• Драйвер серии AMD Instinct MI

Вывод

Хотя отказ от бесплатной версии ESXi вызвал разочарование и обеспокоенность, возвращение entry-level редакции в составе ESXi 8.0 Update 3e — это шаг в сторону компромисса. Broadcom, похоже, услышала голос сообщества и нашла способ вернуть гипервизор в открытый доступ, пусть и с оговорками. Теперь остаётся дождаться подробностей о лицензировании и технических возможностях этой редакции.

Компания VMware недавно пригласила пользователей подать заявку на участие в бета-программе VMware vSphere Foundation 9.0. Это шанс опробовать новые функции и возможности версии vSphere и ESXi 9.0 до их официального релиза, а также повлиять на развитие продукта, предоставив обратную связь. Если вы будете выбраны в число участников, вы окажетесь в авангарде новейших технологий VMware.

Зачем участвовать в бета-программе VMware vSphere Foundation 9.0?

• Ранний доступ: тестируйте и оценивайте новые функции и улучшения до их выхода в общий доступ.
• Прямая обратная связь: повлияйте на продукт, делясь своими мыслями о функциональности, удобстве и производительности.
• Формирование будущих возможностей: участвуйте в разработке будущих функций, учебных материалов, документации и многого другого.
• Сотрудничество с коллегами: общайтесь с другими техническими специалистами в закрытом онлайн-пространстве.

Как подать заявку

1. Ознакомьтесь с документацией бета-версии VMware vSphere Foundation 9.0, чтобы узнать об основных функциях и известных проблемах.

2. Отправьте запрос на участие в бета-программе по этой ссылке. Подтверждённые участники получат уведомление по электронной почте.

   Примечание: Партнёры по технологическому альянсу получают доступ к бета-версии vSphere Foundation 9.0 в рамках членства в программе Technology Alliance Program (TAP).

   

3. Если вас одобрят как участника, скачайте предварительную версию ПО и начните знакомство с новыми возможностями.

4. Следуйте рекомендуемым сценариям использования и заполняйте опросы по функциям, чтобы помочь нам в улучшении продукта.

5. Найдите решения распространённых проблем на портале Beta Communities или при необходимости откройте заявку в службу поддержки.

Важно: VMware может одобрить только заявки, поданные с корпоративных адресов электронной почты. Личные адреса (например, Gmail, Yahoo! и др.) приниматься не будут.

В видеоролике ниже рассматривается то, как включить Virtualization-Based Security (VBS) в гостевых операционных системах Windows, работающих в среде VMware Cloud Foundation и vSphere:

Что такое Virtualization-Based Security (VBS)?

VBS — это технология безопасности от Microsoft, использующая возможности аппаратной виртуализации и изоляции для создания защищённой области памяти. Она используется для защиты критически важных компонентов операционной системы, таких как Credential Guard и Device Guard.

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

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

1. Active Directory Domain Controller
   Необходим для настройки групповой политики. В демонстрации он уже создан, но пока выключен.

2. Загрузка через UEFI (EFI)
   Виртуальная машина должна использовать загрузку через UEFI, а не через BIOS (legacy mode).

3. Secure Boot
   Желательно включить Secure Boot — это обеспечивает дополнительную защиту от вредоносных программ на стадии загрузки.

4. Модуль TPM (Trusted Platform Module)
   Не обязателен, но настоятельно рекомендуется. Большинство руководств по безопасности требуют его наличия.

Настройка VBS в VMware

1. Перейдите к параметрам виртуальной машины в Edit Settings.

2. Убедитесь, что:

   • Используется UEFI и включен Secure Boot.
   • Включена опция "Virtualization-based security" в VM Options.
   • Виртуализация ввода-вывода (IO MMU) и аппаратная виртуализация будут активированы после перезагрузки.

Важно: Если переключаться с legacy BIOS на EFI, ОС может перестать загружаться — будьте осторожны.

Настройка VBS внутри Windows

После включения параметров на уровне гипервизора нужно активировать VBS в самой Windows:

1. Запустите gpedit.msc (Редактор локальной групповой политики).

2. Перейдите по пути:

   Administrative Templates > System > Device Guard 

3. Включите следующие параметры:
   • Turn on Virtualization Based Security – активировать.
   • Secure Boot and DMA Protection – да.
   • Virtualization-based protection of Code Integrity – включить с UEFI Lock.
   • Credential Guard – включить.
   • Secure Launch Configuration – включить.

Примечание: Если вы настраиваете контроллер домена, обратите внимание, что Credential Guard не защищает базу данных AD, но защищает остальную ОС.

4. Перезагрузите виртуальную машину.

Проверка работоспособности VBS

После перезагрузки:

1. Откройте System Information и убедитесь, что:

• Virtualization Based Security включена.
• MA Protection работает.
• redential Guard активен.

2. В Windows Security проверьте:

• Включена ли Memory Integrity.
• Активна ли защита от вмешательства (Tamper Protection).

Заключение

Теперь у вас есть полностью защищённая Windows-гостевая ОС с включённой Virtualization-Based Security, Credential Guard и другими функциями. Это отличный способ повысить уровень безопасности в вашей инфраструктуре VMware.

Для получения дополнительной информации смотрите ссылки под видео.