Современные кибератаки перестали быть точечными ударами по приложениям — теперь они нацелены на саму инфраструктуру. Целенаправленные постоянные угрозы, программы-вымогатели и атаки supply chain бьют именно по тем фундаментальным слоям, на которых работают рабочие нагрузки. Защита фундамента — это уже не опция, а обязательное условие для эксплуатации безопасной и устойчивой инфраструктуры частного облака в эпоху, когда кибератаки, ранее опиравшиеся на ручной хакинг, превратились в управляемые AI-кампании, способные к самоэволюции.

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

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

Безопасность платформы в VCF 9.1

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

Ключевые платформенные функции безопасности VCF 9.1 распределены по пяти категориям:

• Обнаружение и предотвращение угроз усиливает защиту гипервизора и ускоряет установку патчей без простоев.
• Устойчивость рабочих нагрузок обеспечивает непрерывную работу и восстановимость приложений за счёт аппаратной изоляции и кроссплатформенной репликации.
• Шифрование данных защищает данные в процессе обработки, при передаче и в покое на всём стеке.
• Аудит и мониторинг предоставляют единое управление журналами и централизованный аудиторский след для быстрого форензик-анализа.
• Идентификация и доступ обеспечивают принцип Zero Trust за счёт SSO уровня фабрики, политик паролей и управления сертификатами.

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

Обнаружение и предотвращение угроз

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

Live Patching для хостов с включённым TPM

В VCF 9.1 функция live patching в vSphere продолжает развиваться: обновления безопасности можно применять к кластерам без миграции рабочих нагрузок с целевых хостов и без перевода хостов в полный режим обслуживания. Релиз также закрывает пробел, который ранее не позволял хостам с включённым TPM на ESX участвовать в рабочем процессе live patching. Установка патчей без простоев особенно выгодна для бизнес-критичных приложений — таких как сервисы AI-инференса и агентные AI-приложения, для которых требуется непрерывная доступность ради соблюдения SLA.

Quick Patching для vCenter

Функция Quick Patch позволяет VMware vCenter получать патчи безопасности, оставаясь в работающем состоянии. Применение обновления vCenter теперь занимает приблизительно 5 минут без прерывания рабочих нагрузок — против примерно 20 минут простоя и до 40 минут общего времени операции в случае обычного патча. Снижение операционной стоимости патчинга vCenter устраняет одну из частых точек трения, из-за которой обновления одного из самых критичных управленческих компонентов инфраструктуры регулярно откладываются.

С возможностями Live Patching и Quick Patching VCF 9.1 расширяет способность применять исправления безопасности в большем масштабе и с большей скоростью — без обновлений всего стека и без прерывания работы нагрузок.

Интеграция EDR для ESX

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

Мониторинг целостности файлов

В VCF 9.1 появилась функция мониторинга целостности файлов (File Integrity Monitoring, FIM), соответствующая требованиям NIST и PCI DSS. Она выявляет изменения, внесённые вредоносным ПО или злоумышленниками, в статические файлы и бинарники, установленные vCenter. FIM включён по умолчанию и запускается каждые четыре часа, фиксируя злонамеренные, непреднамеренные изменения или повреждения установленных файлов. Администраторы VCF могут получить FIM-отчёт через API или передавать FIM-логи в VCF Operations for Logs через службу syslog.

User-Level Monitor

User-Level Monitor (ULM) поставляется в VCF 9.1 как монитор по умолчанию для всех виртуальных машин. ULM полностью переписывает виртуальный монитор машин (Virtual Machine Monitor, VMM) ESX — компонент, который управлял исполнением виртуальных машин на физическом железе с 1998 года. Ранее VMM работал с максимальными привилегиями ОС, а значит, любая уязвимость могла скомпрометировать весь хост и все ВМ на нём. ULM переносит монитор в пользовательский режим с пониженными привилегиями, ограничивая потенциальный ущерб от эксплойтов. Переработанный интерфейс ядра трактует все входные данные как недоверенные; адресное пространство исключает секреты хоста и память других ВМ; упрощённая архитектура значительно сокращает поверхность атаки и сложность гипервизора.

Устойчивость рабочих нагрузок

Усовершенствование vSphere Pod

Один из способов, которыми VCF обеспечивает изоляцию контейнерных нагрузок, — это vSphere Pods: контейнеры запускаются напрямую внутри управляемых ESX виртуальных машин, что сочетает скорость и плотность контейнеров с аппаратной изоляцией гипервизора. PodVM (vSphere Pods) используются для запуска одного или нескольких контейнерных инстансов без необходимости разворачивать кластер Kubernetes. На vSphere Pods построены сервисы Supervisor, и теперь они доступны через новый UI Container Service.

vSphere Pods используют Container Runtime Executive (CRX), обеспечивающий лёгкую и высокопроизводительную среду, которая загружается за секунды. Это делает их идеальным выбором для нагрузок с повышенными требованиями к безопасности, где необходима строгая изоляция ядер между приложениями, либо для ресурсоёмких микросервисов, которым нужны продвинутое планирование и предиктивные возможности DRS в ESX.

По мере увеличения числа сервисов Supervisor накладные расходы памяти PodVM могут стать узким местом. Благодаря оптимизации памяти PodVM внутренние тесты показывают, что накладные расходы памяти снижаются примерно на 75% по сравнению со стандартной ВМ — за счёт совместного использования образа загрузки между инстансами PodVM на одном хосте. Кроме того, внутренние тесты подтверждают, что PodVM загружается до 70% быстрее, чем типичная ВМ.

Новый сервис Container Service позволяет разворачивать отдельные контейнеры без необходимости управлять полноценным кластером Kubernetes. Используя изолированные runtime-среды внутри vSphere Pods, он даёт возможность запускать отдельные контейнеры, не разворачивая и не обслуживая Kubernetes-кластер целиком.

В этом релизе также добавлен потоковый вывод STDOUT/STDERR в реальном времени со всех контейнеров внутри PodVM на внешние syslog-серверы. Это применимо только к vSphere Pods и не распространяется на гостевые кластерные нагрузки VMware vSphere Kubernetes Service (VKS).

Multi-Source Replication для кластеров vSAN

В VCF 9.0 в vSAN была представлена репликация vSAN-to-vSAN, обеспечивающая защиту ВМ из одного vSAN-кластера в другой. В нынешнем релизе эта возможность расширена дальше. Теперь можно реплицировать или защищать ВМ из любого источника — например, из хранилища VMFS или NFS — на vSAN-цель. Это даёт большую гибкость в защите существующих сред VCF, где может присутствовать смешанный набор платформ хранения. Теперь возможно защищать все ВМ среды через единую цель репликации и единый рабочий процесс — независимо от того, на какой платформе хранения они в данный момент находятся, — с политиками снапшотов и репликацией, действующими на всю инфраструктуру.

Возможности репликации доступны через VMware Site Recovery Manager (SRM) или решение VMware Advanced Cyber Compliance.

Шифрование данных

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

Confidential Computing — теперь в общедоступной версии

Confidential Computing запускает чувствительные нагрузки внутри аппаратно зашифрованных областей памяти, которые остаются недоступными даже для гипервизора, защищая данные в процессе использования на разделяемой инфраструктуре частного облака. VCF поддерживал более ранние поколения этой технологии уже несколько лет; VCF 9.1 завершает работу над поддержкой текущих реализаций — Intel TDX и AMD SEV-SNP, — переводя их в категорию общедоступных (general availability). Одно из практических улучшений — повторное включение Quick Boot на хостах, где активен Confidential Computing: раньше хосты, использующие Intel TDX или AMD SEV-SNP, не могли воспользоваться Quick Boot — функцией, позволяющей ESX перезапускаться без полного цикла аппаратной инициализации и тем самым сокращающей окна обслуживания.

Дополнительно VCF Operations теперь автоматически профилирует ESX-хосты и определяет, какие из них способны выполнять конфиденциальные ВМ и контейнеры. Это снимает с архитекторов гадания при размещении чувствительных нагрузок на защищённом оборудовании. Операторы также могут видеть, активирован ли Confidential Computing на подходящем хосте.

Confidential Computing в VCF доступен через решение VMware Advanced Cyber Compliance.

Ускоренный шифрованный vMotion с технологией Intel QuickAssist (QAT)

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

QAT включён по умолчанию на поддерживаемом оборудовании, обеспечивая более плавный пользовательский опыт и упрощённое управление жизненным циклом.

Шифрование данных в покое для vSAN Global Deduplication

В связке с переводом vSAN Global Deduplication в общедоступную версию в VCF 9.1 кластеры vSAN, использующие глобальную дедупликацию, теперь поддерживают шифрование данных в покое (Data-at-Rest Encryption). Включить Data-at-Rest Encryption можно на уровне отдельного кластера, одновременно используя на том же кластере vSAN Global Deduplication — без каких-либо компромиссов между этими двумя функциями. Дедупликация работает как фоновая постобработка и совместима с шифрованием данных в покое; включение шифрования не влияет на коэффициенты дедупликации.

Аудит и мониторинг

Централизованное управление журналами

VCF 9.1 улучшает управление логами, полностью интегрируя возможности отдельного UI VCF Operations for Logs внутрь VCF Operations и предоставляя администраторам и операторам VCF единый интерфейс для всех задач управления журналами. В интеграцию входят правила обработки логов, администрирование логов, публичные API для логов, глобальные настройки управления кластером логов, а также улучшения страницы анализа логов.

Отдельный UI больше не требуется, поскольку все возможности встроены непосредственно в VCF Operations.

Аудиторский след (Audit Trail)

Форматы лог-записей и аудиторских записей теперь стандартизированы между компонентами VCF.

Новый Audit Trail в VCF Operations идёт дальше и предоставляет централизованное представление пользовательской активности с временными срезами по всем компонентам (включая VKS), упрощая разбор для форензики, выявление ключевых событий и сокращая время аудита. Когда меняются правила межсетевого экрана или фиксируются неудачные попытки входа, операторы могут проследить всю цепочку событий через весь стек.

Идентификация и доступ

VCF 9.1 расширяет возможности единого SSO, управления паролями и сертификатами, представленные в предыдущем релизе, — добавляя более широкое покрытие компонентов, средства управления на уровне фабрики и новые интеграции с хранилищами секретов и центрами сертификации.

Усовершенствование Identity Broker

VCF Identity Broker (VIDB) получил расширенные параметры конфигурации и улучшения развёртывания. VIDB обеспечивает SSO-связь между компонентами VCF и внешним поставщиком идентификации (Identity Provider, IDP) или службой каталогов. Identity Broker теперь устанавливается в момент развёртывания или обновления VCF и больше не требует отдельной загрузки в качестве предусловия для настройки единого входа.

Identity Broker можно настраивать в embedded-режиме или режиме appliance — через VCF Operations или API. Развёртывание Identity Broker в виде кластера из трёх узлов обеспечивает более высокую производительность, масштабируемость и высокую доступность; такой вариант рекомендован для промышленной эксплуатации. Узлы Identity Broker теперь могут разворачиваться за пределами management-кластера.

VCF 9.x также предоставляет скриптовый рабочий процесс для организаций, обновившихся с VCF 5.x, — позволяющий без прерывания работы мигрировать пользователей и группы из VMware Identity Manager (VIDM) в Identity Broker. В процессе обновления Identity Broker разворачивается автоматически. Скрипт запускается уже после завершения обновления. Далее Identity Broker можно интегрировать с выбранным поставщиком идентификации; существующие пользователи и группы при этом не затрагиваются.

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

VCF Operations 9.1 расширяет управление паролями, добавляя политики уровня фабрики, интеграцию с хранилищами секретов и покрытие дополнительных компонентов.

Теперь возможно задавать единые политики паролей между компонентами VCF и проводить проверки соответствия паролей с последующей коррекцией. Созданные политики применяются на уровне фабрики VCF или для отдельных компонентов VCF. Кроме того, администраторы могут управлять паролями для VCF Operations workload mobility (ранее известного как HCX) и балансировщиков Avi, развёрнутых или обновлённых до VCF 9.1.

Пароли break-glass-учётных записей больше не сохраняются — что устраняет одну из распространённых причин для процедур принудительной смены паролей. Дополнительно новые API для интеграции с корпоративными хранилищами паролей поддерживают сторонние инструменты — в частности, CyberArk. Корпоративные парольные хранилища, управляемые через API, потребуют плагина для VCF.

Усовершенствование управления сертификатами

В VCF 9.1 добавлены конфигурация центров сертификации на уровне фабрики, расширенная поддержка Microsoft CA и OpenSSL, а также массовые операции с сертификатами. Центр сертификации (Certificate Authority, CA) теперь настраивается на уровне фабрики VCF, а не отдельного инстанса, что позволяет управлять сертификатами на уровне всей фабрики.

Поддержка Microsoft CA и OpenSSL расширена и теперь охватывает как компоненты VCF instance, так и компоненты управления VCF. В предыдущем релизе Microsoft CA и OpenSSL поддерживались только для компонентов VCF instance (vCenter, NSX и ESX), тогда как компоненты управления можно было настраивать исключительно с использованием Microsoft CA.

В UI VCF Operations операторы теперь могут выполнять массовые операции с сертификатами. Запросы на подпись сертификатов, их обновление и импорт — всё это выполняется пакетно, сокращая время и дополнительно упрощая операции по управлению сертификатами. API VCF Operations можно использовать для интеграции со сторонними решениями и автоматизации управления сертификатами для всех компонентов VCF.

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

VCF 9.1 содержит последние достижения технологии виртуализации VMware. Релиз объединяет Zero Trust-безопасность и устойчивость на каждом уровне: vSphere, NSX, vSAN, VMware vSphere Kubernetes Service, VCF Private AI Services, VCF Operations и VCF Automation, помогая организациям защитить инфраструктуру частного облака от продвинутых, ускоренных AI-угроз.

Для технического разбора темы можно посмотреть видео «What's New in Platform Security in VCF 9.1» на YouTube:

Также материалы по усилению безопасности, соответствию требованиям и часто задаваемые вопросы по конкретным функциям доступны в репозитории GitHub: https://brcm.tech/vcf-security.

С момента запуска VMware Cloud on AWS компании VMware и AWS совместно расширяли портфель специализированных инстансов на базе bare-metal — от оригинальных i3.metal и i3en.metal до высокоплотного i4i.metal. Теперь для VMware Cloud on AWS объявлен запуск нового типа инстансов — i7i.metal-24xl. Оснащённый процессорами 5 поколения Intel Xeon Scalable (Emerald Rapids), SSD третьего поколения AWS Nitro и высокоскоростной памятью DDR5, новый инстанс обеспечивает значимый скачок в пропускной способности хранилища и вычислительной эффективности — при этом существующая операционная модель VMware не требует каких-либо изменений.

По мере того как всё больше заказчиков переносят в облако наиболее требовательные рабочие нагрузки, новый инстанс i7i обеспечивает наилучшую вычислительную производительность и производительность хранилища среди x86-инстансов Amazon EC2, оптимизированных для хранения данных. Пользователи VMware Cloud on AWS получают заметно более высокую пропускную способность ввода-вывода, меньшую задержку и улучшенное соотношение цены и производительности по сравнению с предыдущим поколением.

Ключевые характеристики

Инстанс i7i.metal-24xl представляет собой универсальный bare-metal-инстанс, разработанный для I/O-интенсивных корпоративных рабочих нагрузок, которым требуется максимально возможная производительность случайного ввода-вывода с предсказуемой субмиллисекундной задержкой.

Источник: Amazon EC2 I7i Instances — aws.amazon.com. Используемая ёмкость является оценочной. Для конфигураций с оптимизацией vSAN на кластере из 3 узлов фактическая ёмкость будет варьироваться в зависимости от профиля нагрузки, политики FTT/RAID и применяемых параметров сжатия и дедупликации vSAN.

Региональная доступность

Тип инстансов i7i.metal-24xl доступен для приобретения в следующих регионах AWS:

Подробнее — в разделе о доступных регионах и зонах доступности.

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

VMware vSAN работает непосредственно поверх локальных NVMe-дисков каждого хоста i7i.metal-24xl. При включённом сжатии vSAN кластер из 3 узлов обеспечивает значительную используемую ёмкость — конкретный результат зависит от характеристик нагрузки, политики FTT/RAID и показателей снижения объёма данных. Размер конфигурации рекомендуется валидировать применительно к конкретному профилю данных.

На i7i.metal-24xl по умолчанию включён гиперпоточный режим, что обеспечивает 96 логических ядер на хост — это хорошо подходит для приложений, выигрывающих от увеличенного параллелизма потоков CPU. Для заказчиков, которым важны показатели производительности приложений или условия программного лицензирования, VMware Cloud on AWS поддерживает опцию Custom CPU Core Count, позволяющую управлять количеством физических ядер, доступных на каждом хосте.

Для вторичных кластеров i7i.metal поддерживаются следующие конфигурации:

• Кластеры от 3 узлов: 8, 16, 24, 30 или 36 физических ядер на хост
• Кластеры из 2 узлов: 16, 24, 30 или 36 физических ядер на хост

Такая гибкость особенно ценна для ПО с лицензированием по числу ядер — например, Oracle Database и Microsoft SQL Server: сокращение числа активных ядер может существенно снизить лицензионные расходы без потери объёма памяти и хранилища хоста.

Кроме того, доступно развёртывание Stretched Cluster с охватом нескольких зон доступности для новых SDDC на базе i7i.metal-24xl — это обеспечивает высокую доступность рабочих нагрузок сразу в двух зонах доступности AWS в пределах одного региона. По умолчанию в Stretched Cluster SDDC используется vSAN OSA.

Приобретение подписок i7i.metal-24xl

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

Важно учитывать, что тип инстансов i7i требует предварительного обновления существующих развёртываний до версии SDDC 1.26v2 — для конвертации кластеров и развёртывания новых вторичных кластеров. Для запроса досрочного обновления необходимо открыть запрос в поддержку с указанием организации, данных SDDC и желаемой даты обновления — команда VMC поддержки скоординирует дальнейшие шаги.

Развёртывание и миграция на i7i.metal-24xl

Существует два сценария: развертывание нового SDDC с инстансами i7i.metal-24xl или миграция рабочих нагрузок с имеющихся узлов i3.metal, i3en.metal и/или i4i.metal на новый i7i.metal-24xl. Тип инстансов i7i доступен только для SDDC версии 1.26v2.

Создание нового SDDC

Все вновь развёртываемые SDDC будут работать на актуальной версии SDDC 1.26v2 и по умолчанию использовать vSAN ESA. Подробные инструкции доступны в разделе «Развёртывание SDDC из VMware Cloud Console».

1. Войдите в VMware Cloud Console по адресу vmc.broadcom.com.
2. Выберите Create SDDC и укажите тип хоста i7i.metal-24xl.
3. Задайте размер кластера (минимум 2 хоста) и выполните оставшиеся шаги.
4. Завершите развёртывание SDDC. VMware автоматически выполняет настройку ESXi, vSAN, vCenter и NSX.

Добавление вторичного кластера в существующий SDDC

К существующему SDDC (после обновления до версии 1.26v2) можно добавить новый кластер на базе i7i.metal-24xl без прерывания выполняющихся нагрузок. После подготовки кластера vSphere vMotion позволяет перенести виртуальные машины из имеющихся кластеров в новый i7i с минимальным воздействием. Новый кластер будет работать под управлением SDDC 1.26v2 и по умолчанию использовать vSAN ESA. Подробные инструкции — в разделе «Добавление кластера».

Конвертация кластеров с хостами i3 / i3en / i4i

Миграция с i3.metal, i4i.metal или i3en.metal на i7i.metal-24xl возможна с помощью vSphere vMotion. Для подходящих конфигураций VMware также предоставляет услугу конвертации кластера по запросу. Подробные инструкции — в разделе «Конвертация типов хостов в кластерах».

Следует учитывать, что кластеры, использующие аппаратную версию виртуальных машин 21, не подходят для конвертации с i4i на i7i из-за ограничений совместимости оборудования. Для получения помощи с расчётом размеров и планированием конвертации кластеров следует обращаться к команде Broadcom. Также доступен инструмент VMC Sizer — для оценок на основе хостов, нагрузок или конвертации кластеров.

Начало работы

Для обсуждения того, как i7i.metal-24xl может модернизировать среду VMware Cloud on AWS, рекомендуется связаться с представителем Broadcom. На vmc.broadcom.com доступны настройка нового SDDC, изучение вариантов расчёта размеров и запрос оценки рабочих нагрузок.

Frank Denneman написал отличную статью о разделении NVIDIA Multi-Instance GPU (MIG) с учетом геометрий размещения и потерянных ёмкостей ресурсов.

Архитектура инфраструктуры ИИ

Предыдущие статьи в этой серии объясняли, как работает совместное использование GPU с разделением по времени как в средах вида same-size, так и со смешанными размерами. Они показали, что такие выборы, как профили и порядок запуска рабочих нагрузок, могут напрямую влиять на использование GPU и на то, будут ли рабочие нагрузки успешно размещены. В этой части мы рассматриваем MIG и решения по проектированию, которые влияют на успешность размещения и общее использование ресурсов.

MIG использует другой подход к совместному использованию GPU. Вместо мультиплексирования вычислительных ресурсов между рабочими нагрузками MIG разделяет GPU на аппаратные экземпляры. Каждый экземпляр получает собственные выделенные вычислительные срезы (slices) и срезы памяти.

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

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

Модель ресурсов MIG

В предыдущих статьях этой серии было показано, что ёмкость GPU определяется не только объёмом свободной памяти. Ёмкость зависит от того, как ресурсы разделены и размещены. MIG добавляет ещё один уровень ограничений размещения.

Все архитектуры GPU NVIDIA, поддерживающие MIG, включая Ampere, Hopper и Blackwell, имеют одинаковую структуру. Каждый GPU предоставляет семь вычислительных срезов и восемь срезов памяти. Профили используют оба ресурса одновременно, поэтому каждый профиль представляет собой определённую комбинацию вычислительных срезов и срезов памяти, соответствующую физической структуре GPU.

В этой статье в качестве примера используется GPU H100 с объёмом памяти 80 гигабайт. В этой конфигурации каждый срез памяти представляет десять гигабайт framebuffer-памяти. Поскольку вычислительные срезы и срезы памяти выделяются вместе, один только объём свободной памяти не определяет, может ли быть запущен новый экземпляр. Требуемые вычислительные срезы также должны быть доступны и соответствовать правильной области памяти. Таблица показывает доступные профили MIG для GPU H100-80GB:

Эти профили показывают, что использование ресурсов MIG в большинстве случаев асимметрично. Некоторые профили предлагают одинаковый объём памяти, но отличаются вычислительной мощностью. Например, и 1g.20gb, и 2g.20gb предоставляют 20 GB памяти, но требуют разного количества вычислительных срезов.

То же относится и к профилям 40 GB: 3g.40gb и 4g.40gb оба используют 40 GB памяти, но требуют разные вычислительные ресурсы.

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

Потерянная ёмкость

Поскольку вычислительные и срезы памяти не всегда совпадают, некоторые ресурсы GPU могут оставаться неиспользованными, даже когда устройство выглядит полностью занятым. Возьмём самый маленький профиль MIG — 1g.10gb. Этот профиль потребляет один вычислительный срез и один срез памяти. На GPU с восемьюдесятью гигабайтами можно создать семь экземпляров, потому что GPU предоставляет семь вычислительных срезов.

GPU всё ещё имеет восемь срезов памяти. После размещения семи экземпляров 10 гигабайт памяти остаются неиспользованными, или, иначе говоря, это потерянная ёмкость. Вычислительных срезов больше не осталось, поэтому ни один другой экземпляр не может быть запущен. Такое поведение легко не заметить в диаграммах размещения MIG. Эти диаграммы показывают области размещения памяти, и семь экземпляров 1g.10gb выглядят так, будто полностью заполняют GPU. На самом деле ограничивающим фактором являются вычислительные срезы, а не память.

Геометрия размещения

Профили MIG должны соответствовать определённым областям размещения памяти внутри GPU. Профили, которые используют несколько срезов памяти, требуют непрерывной области.

Профиль 3g.40gb потребляет четыре среза памяти. На GPU с объёмом памяти 80 гигабайт это создаёт две допустимые области размещения: срезы памяти 0–3 или 4–7. nvidia-smi — это инструмент командной строки NVIDIA, устанавливаемый вместе с драйвером. Флаг mig -lgi выводит список всех активных экземпляров MIG на хосте — list GPU instances — включая профиль, из которого был создан каждый экземпляр, и его положение в схеме памяти GPU. Вывод содержит колонку placement в формате start:size, где start — это индекс первого среза памяти, который занимает экземпляр, а size — количество срезов, которые он использует.

Экземпляр 3g.40gb с размещением 4:4 начинается с среза памяти 4 и занимает четыре среза, размещаясь во второй области. Экземпляр 4g.40gb с размещением 0:4 занимает первую область — единственную область, где может быть удовлетворено его требование к вычислительным ресурсам. Однако по мере размещения на GPU двух профилей 3g.40gb один вычислительный экземпляр оказывается потерянным.

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

Хорошим примером этого является профиль 4g.40gb. Он может быть размещён только начиная с среза памяти 0 и, таким образом, напрямую выравнивается с вычислительным срезом 0. Фрэнк работал с системой Dell PowerEdge XE9680 HGX с восемью GPU H100 80 GB, семь из которых были пустыми.

Когда Фрэнк включил семь виртуальных машин с профилем 4g.40gb, каждая ВМ была размещена в первой области размещения (0–4) GPU H100. Последние четыре среза памяти каждого GPU всё ещё оставались свободными, но в этих областях есть только три вычислительных среза, поэтому разместить там ещё одну ВМ с профилем 4g.40gb невозможно.

Однако можно включить виртуальные машины с профилем vGPU 3g.40gb. Как показано на скриншоте, Фрэнк запустил две ВМ с этим профилем, и они были размещены на GPU 1 и 2.

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

Поведение размещения

Как описано в части 4, vSphere не использует политики размещения GPU на уровне хоста, когда GPU работают в режиме MIG. Размещение следует тому же подходу, который используется в средах со смешанными размерами: сначала заполняется один GPU, прежде чем переходить к следующему, при этом сохраняется как можно больше вариантов размещения для будущих рабочих нагрузок. Это поведение значительно улучшилось в архитектуре Hopper, но Ampere иногда испытывает трудности с размещением более крупных профилей, потому что не всегда учитывает будущие размещения 4g40gb. (Reddit).

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

Хороший пример — профиль 3g.40gb. В тестовом кластере Фрэнк очистил семь GPU (кроме GPU 0, на котором выполнялась рабочая нагрузка разработчика) и запустил пять ВМ, каждая с профилем vGPU 3g.40gb. Как показано на скриншоте, первая ВМ была размещена на GPU 0 с placement id 4, оставляя место для будущего профиля 4g.40gb. Когда следующая ВМ была размещена с профилем 3g.40gb, менеджер vGPU выбрал GPU 1, оставив другие GPU открытыми для возможного размещения самого большого профиля — 7g.80gb. При каждом новом размещении менеджер vGPU сначала размещает первый профиль vGPU в позиции placement 4, прежде чем заполнять остальное пространство.

Обратите внимание, что Фрэнк зарегистрировал все эти ВМ на этом хосте, чтобы ограничить область тестирования. В реальных сценариях DRS, вместе с Assignable Hardware, распределяет ВМ между совместимыми хостами ESX в кластере на основе баланса кластера по CPU и памяти и доступности совместимых GPU.

Проектирование каталога профилей

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

Профили 40 гигабайт хорошо демонстрируют этот компромисс. Один GPU может разместить два экземпляра 3g.40gb, но только один 4g.40gb, потому что второй потребовал бы восемь вычислительных срезов, тогда как GPU имеет только семь. Если вы предлагаете только 3g.40gb, один вычислительный срез всегда будет потерян на полностью загруженном GPU. Если вы предлагаете 4g.40gb вместе с более маленькими профилями, вы избегаете этих потерь, но рискуете получить ошибки размещения: профиль 4g.40gb может быть создан только в первой области памяти, поэтому если там уже есть другой экземпляр, размещение становится невозможным независимо от того, сколько памяти осталось.

Профили 20 гигабайт имеют ту же проблему, но в другой форме. Четыре экземпляра 2g.20gb не могут работать на одном GPU — снова требуется восемь вычислительных срезов, но доступно только семь. Если вы добавите профиль 1g.20gb как вариант, можно разместить четвёртую нагрузку на 20 гигабайт, но это увеличивает вероятность появления потерянной ёмкости по мере заполнения GPU экземплярами с небольшой вычислительной нагрузкой.

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

Если строгая изоляция не требуется, смешанный режим, описанный в части 6 и части 7, полностью избегает этих ограничений. Четыре рабочие нагрузки по 20 гигабайт и две рабочие нагрузки по 40 гигабайт могут полностью использовать один GPU в средах со смешанными размерами, не оставляя вычислительную ёмкость потерянной.

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

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

Кратко: что нового в VKS 3.6

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

• Открытая и расширяемая сетевая экосистема – поддерживаемый путь для партнерских сетевых дополнений позволяет плагинам Container Network Interface (CNI) нативно интегрироваться с VKS, оставаясь в рамках жизненного цикла и поддержки.
• Настройка производительности для ресурсоемких по данным и чувствительных к задержкам нагрузок – декларативные профили TuneD позволяют безопасно настраивать параметры ядра и sysctl для баз данных и высокопроизводительных приложений без неподдерживаемых изменений на хостах.
• Выбор корпоративной ОС с поддержкой RHEL – узлы на базе Red Hat Enterprise Linux (RHEL), включая кластеры со смешанными операционными системами.

Kubernetes 1.35, созданный для корпоративной эксплуатации

VKS 3.6 добавляет поддержку Kubernetes версии 1.35, продолжая обязательство Broadcom по предоставлению Kubernetes с сертификацией CNCF, предназначенного для корпоративного использования. Как и в предыдущих релизах, Broadcom предоставляет расширенную поддержку на 24 месяца для каждой версии Kubernetes с перекрывающейся поддержкой версий. Это позволяет крупным организациям переводить команды на новые версии в собственном темпе, не вынуждая выполнять массовые обновления всего парка или проводить сжатые окна обслуживания.

Некоторые заметные нововведения в выпуске Kubernetes 1.35 включают:

• Настраиваемая параллельность для поэтапных обновлений StatefulSet с параметром maxUnavailable – теперь платформенные команды могут одновременно выводить из работы несколько Pod’ов во время обновлений StatefulSet, контролируя уровень нарушения работы для stateful-нагрузок и сокращая время развертывания.
• Улучшенная осведомленность о топологии для нагрузок – приложения могут безопасно использовать информацию о топологии узлов, повышая понимание своего расположения в инфраструктуре, что полезно для чувствительных к задержкам и ресурсоемких по данным приложений.
• Модернизированные основы хранения данных – такие усовершенствования, как тома на основе OCI, делают потребление хранилища в Kubernetes более согласованным с контейнерно-ориентированными моделями поставки.

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

Более плавные обновления и более безопасные операции второго дня

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

Развивая ранее внедренные предварительные проверки PodDisruptionBudget, VKS 3.6 расширяет проверки готовности к обновлению, чтобы выявлять распространенные конфликты конфигурации до начала обновления. Вместо обнаружения блокирующих факторов в середине процесса обновления платформенные команды могут заранее выявить и устранить проблемы до окна обслуживания, снижая количество неудачных обновлений и незапланированных сбоев. Эти проверки выполняются непрерывно, выявляя риски обновления через условие SystemCheckSucceeded, а не только во время выполнения обновления.

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

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

Запуск баз данных и других stateful-платформ в Kubernetes часто требует настройки ядра и параметров узлов, выходящих за пределы стандартных значений. Во многих средах команды полагались на ручные изменения узлов или специально собранные образы для удовлетворения этих требований. В моделях управляемого Kubernetes такие изменения, как правило, должны быть выражены декларативно (например, через утвержденные механизмы конфигурации, привилегированные DaemonSet’ы или стандартизированные образы), чтобы сохраняться при обновлениях и замене узлов.

VKS 3.6 вводит поддерживаемые профили TuneD, позволяя разработчикам декларативно настраивать ядро Linux (включая параметры sysctl и sysfs) через ресурсы Kubernetes. Профили могут быть привязаны к определенным пулам узлов, обеспечивая оптимизацию под конкретные нагрузки в рамках одного кластера.

Это делает распространенные сценарии простыми и поддерживаемыми, например:

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

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

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

VKS 3.6 упрощает поддержку нормативных и требований безопасности без жесткой фиксации кластеров в универсальных схемах усиленной защиты. Расширенная конфигурация компонентов Kubernetes позволяет платформенным командам настраивать уровень соответствия требованиям для каждой нагрузки и среды. Команды могут применять более строгие меры там, где это требуется, ослаблять их при необходимости и постепенно развивать конфигурации вместо пересоздания кластеров для изменения политики.

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

VKS 3.6 также повышает операционную автономность. Владельцы workload-кластеров теперь могут генерировать пакеты поддержки VKS без учетных данных vCenter, устраняя необходимость повышенного инфраструктурного доступа при устранении неполадок. Это снижает трения между командами Kubernetes и инфраструктуры, сохраняя принцип наименьших привилегий.

Пользовательский опыт платформы и развитие экосистемы

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

Ваша сеть — ваш выбор

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

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

Ваш фаервол — ваш выбор

VKS 3.6 вводит централизованное управление правилами сетевого экрана на уровне узлов через API для всех поддерживаемых операционных систем. Теперь платформенные команды могут открывать необходимые порты для HostPorts и сервисов NodePort через конфигурацию кластера, вместо использования привилегированных init-контейнеров или DaemonSet’ов на каждом узле.

Перенос управления файрволом с отдельных нагрузок на уровень кластера упрощает конфигурацию, повышает аудируемость и снижает риски безопасности, связанные с привилегированными компонентами. Для Linux-узлов VKS 3.6 также добавляет поддержку backend nftables для kube-proxy, обеспечивая лучшую производительность и масштабируемость по сравнению с реализацией по умолчанию на основе iptables.

Ваша ОС — ваш выбор

Red Hat Enterprise Linux (RHEL) 9 присоединяется к Photon OS 5, Ubuntu 22.04 и 24.04, а также Windows Server 2022 в качестве поддерживаемых операционных систем для узлов кластера VKS. RHEL может использоваться как для узлов control plane, так и для рабочих узлов.

Для поддержки разнообразных требований приложений в рамках одного кластера VKS продолжает позволять различным пулам узлов работать на разных операционных системах. Пулы узлов RHEL могут существовать наряду с узлами Windows, Ubuntu и Photon, обеспечивая гетерогенные кластеры и постепенную миграцию ОС со временем.

VKS 3.6 также включает улучшенные инструменты для сборки пользовательских образов узлов для всех поддерживаемых операционных систем. Image Baker предназначен для сред с ограниченной сетевой связностью, работает независимо от vCenter для снижения инфраструктурных зависимостей и поставляется как плагин CLI VMware Cloud Foundation (VCF). Broadcom продолжает предоставлять готовые образы для Photon и Ubuntu.

Kubernetes — с меньшим количеством неожиданностей

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

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

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

Более подробно о VMware vSphere Kubernetes Service 3.6 можно узнать на странице продукта.

VMware недавно опубликовала обновлённый набор технических руководств, которые приводят рекомендации в соответствие с архитектурой эпохи VMware Cloud Foundation и с новыми возможностями приложений Microsoft, включая SQL Server 2025 и Windows Server 2025.

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

Руководство 1: Проектирование Microsoft SQL Server на VMware Cloud Foundation

Для многих команд решение о виртуализации SQL Server уже принято. Как говорится в руководстве: «вопрос больше не в том, виртуализировать ли SQL Server, а в том, как…». И это «как» существенно изменилось в мире VCF. Платформа стала более регламентированной, операционная модель — более стандартизированной, а поддерживающие возможности (хранилище, сеть, управление жизненным циклом, безопасность) эволюционировали с учётом развития аппаратных возможностей и операционных методик.

Обновлённое руководство предназначено для читателей, которые уже понимают как VCF, так и SQL Server. Оно ориентировано на несколько ролей: архитекторов, инженеров/администраторов и DBA.

Несколько моментов, на которые стоит обратить внимание:

• Современные рекомендации по CPU и NUMA теперь учитывают и новое поведение топологии в эпоху VCF. Руководство рассматривает «новые параметры конфигурации топологии vNUMA в VMware Cloud Foundation (VCF)» и объясняет, почему это поведение важно для крупных виртуальных машин SQL Server.
• Чёткая и обновлённая позиция по CPU hot plug в эпоху SQL Server 2025. В руководстве прямо указано: CPU Hot-Add больше не поддерживается в SQL Server 2025, и его не следует включать на таких виртуальных машинах.
• Рекомендации по хранилищу, соответствующие направлению развития VCF. Если вы оцениваете архитектурные варианты vSAN, руководство объясняет, почему vSAN Express Storage Architecture (ESA) привлекателен для заказчиков, переходящих на более современное оборудование, и подчёркивает возможности эффективности ESA, такие как глобальная дедупликация и преимущества сжатия для нагрузок баз данных.
• Пояснения по устаревающим функциям, влияющим на долгоживущие архитектуры. Если в вашей текущей архитектуре активно используются vVols, учтите, что Virtual Volumes объявлены устаревшими, начиная с VCF 9.0 и VMware vSphere Foundation 9.0 (полный отказ запланирован в будущих релизах).
• Операционная реалистичность для мобильности и обслуживания. Руководство рассматривает использование multi-NIC vMotion для снижения риска зависания (stun) при миграции крупных, потребляющих много памяти виртуальных машин SQL, а также отмечает, что VCF внедряет vMotion Notifications, чтобы помочь чувствительным к задержкам и кластер-осведомлённым приложениям безопаснее обрабатывать миграции.

Если вы принимаете решения - это тот документ, который снижает объём переработок, вызванных неожиданностями. Если вы технический специалист - это тот документ, который не позволит вам унаследовать архитектуру в стиле «it depends», которая позже приведёт к простою.

Руководство 2: Проектирование Microsoft SQL Server для высокой доступности на VMware Cloud Foundation

Второе руководство сосредоточено там, где ставки особенно высоки: корректное проектирование доступности SQL Server на VCF без смешивания устаревших предположений, неподдерживаемых конфигураций или подхода «потом исправим» в кластеризации.

Оно написано для смешанной аудитории, включая DBA, администраторов VMware, архитекторов и IT-руководителей. И в нём ясно указано, что «доступность» — это не функция, которую добавляют в конце; выбранная модель защиты должна определяться бизнес-требованиями.

Несколько особенно практичных обновлений:

• Реалии доступности SQL Server 2025, чётко сопоставленные с механизмами защиты. Руководство связывает уровни защиты с современными возможностями обеспечения доступности SQL Server, подчёркивает области, где SQL Server 2025 усиливает архитектуры на базе Availability Groups (AG), и отмечает, что Database Mirroring удалён в SQL Server 2025.
• Рекомендации по согласованию жизненного цикла, которые действительно важны для IT-руководства. Начиная с SQL Server 2025, отмечается, что более старые версии Windows Server вышли из основной поддержки, и рекомендуется использовать Windows Server 2025 или Windows Server 2022 при наличии совместимости — прямой переход к поддерживаемым и обоснованным платформам.
• Современные варианты кластеризации с общими дисками без навязывания устаревших архитектур. Руководство указывает, что в средах эпохи VCF 9 семантика общих дисков для FCI может быть реализована современными способами — подчёркивается использование Clustered VMDKs и явно обозначается движение в сторону отказа от устаревших зависимостей.
• Рекомендации по DRS anti-affinity, предотвращающие «самоорганизованные» события HA. Если узлы кластера SQL работают на одном и том же хосте ESXi «потому что так решил DRS», это не высокая доступность, а отложенный инцидент. Настройте соответствующие правила DRS, чтобы узлы кластера были физически разделены.
• Требования к vMotion Application Notification, изложенные подробно. Руководство описывает использование уведомлений приложений, включая требования, такие как актуальные VMware Tools и рекомендуемая настройка таймаутов — именно те детали, которые команды часто выясняют в условиях уже упавшей системы.
• Рекомендации по vSAN ESA, отражающие текущие возможности. Указывается направление политик ESA и отмечается глобальная дедупликация (впервые представленная в VCF 9.0) как рекомендуемая для определённых сценариев Availability Group SQL Server в пределах одного кластера vSAN.

Это то руководство, которое вы передаёте команде, когда бизнес говорит: «нам нужна более высокая доступность», — и вы хотите, чтобы ответом стало инженерно проработанное решение.

Руководство 3: Виртуализация служб домена Active Directory на VMware Cloud Foundation

Active Directory (AD) Domain Services (DS) — одна из тех служб, о которых не думают до тех пор, пока всё не перестанет работать. Обновлённое руководство по AD DS прямо признаёт это, указывая, что многие организации справедливо рассматривают AD DS как по-настоящему критичное для бизнеса приложение, поскольку аутентификация, доступ к ресурсам и бесчисленные рабочие процессы зависят от него.

Оно также напрямую обращается к сохраняющемуся рефлексу «физического контроллера домена». Благодаря развитию Windows Server и зрелым практикам VCF, в руководстве говорится, что эти улучшения теперь позволяют организациям «безопасно виртуализировать сто процентов своей инфраструктуры AD DS».

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

• В руководстве указано, что лишь несколько усовершенствований существенно изменяют прежние рекомендации, включая Virtualization-Based Security (VBS), Secure Boot, шифрование на уровне виртуальной машины и улучшенную синхронизацию времени в гостевых ВМ — и эти изменения учтены там, где это необходимо.
• Документ явно ориентирован на несколько аудиторий (архитекторов, инженеров/администраторов и руководителей/владельцев процессов), что важно для AD DS, поскольку проектирование и эксплуатация неразделимы.
• Подчёркиваются операционные меры защиты при восстановлении после сбоев. Например, рекомендуется использовать приоритет перезапуска ВМ в vSphere HA, чтобы ключевые инфраструктурные службы запускались раньше после аварийного восстановления.
• Подробно рассматриваются механизмы обеспечения целостности в эпоху виртуализации (например, поведение VM-Generation ID), созданные специально для устранения исторических опасений, связанных со снапшотами и откатами.

Если вы модернизируете инфраструктуру идентификации, консолидируете датацентры или строите частное облако на базе VCF с сильной позицией по безопасности, этот документ обязателен к прочтению. AD DS — это не просто ещё одна рабочая нагрузка. Это сущность, от которой зависит работа всего вашего стека.

Руководство 4: Запуск Microsoft SQL Server Failover Cluster Instance на VMware vSAN платформы VMware Cloud Foundation 9

Если ваша модель обеспечения доступности по-прежнему основана на кластеризации с общими дисками — будь то из-за ограничений приложений, операционных предпочтений или необходимости сохранить модель SQL Server FCI — это руководство является практическим дополнением «как это реально работает на VCF 9» к более общим рекомендациям по HA. Это эталонная архитектура для запуска Microsoft SQL Server Failover Cluster Instance (FCI) с использованием общих дисков на базе vSAN, валидированная как для стандартного кластера vSAN, так и для сценария растянутого кластера vSAN.

Несколько моментов, на которые стоит обратить внимание:

• Нативная поддержка WSFC + общих дисков на vSAN (с подробным описанием механики). В VCF 9 «vSAN обеспечивает нативную поддержку виртуализированных Windows Server Failover Clusters (WSFC)» и «поддерживает SCSI-3 Persistent Reservations (SCSI3PR) на уровне виртуального диска» — ключевое требование для арбитража общих дисков в WSFC.
• Две настройки конфигурации, от которых зависит работоспособность общих дисков. Указывается, что общие диски должны быть подключены к контроллеру с параметром SCSI Bus Sharing, установленным в Physical, и что «режим диска для всех дисков в кластере должен быть установлен в Independent – Persistent», чтобы избежать неподдерживаемой семантики снапшотов на общих дисках.
• Операционные особенности растянутого кластера: задержки, размещение и кворум являются частью архитектуры. Рекомендуется «менее четырёх миллисекунд межсайтовой (round trip) задержки» для SQL-баз данных уровня tier-1 в растянутых кластерах vSAN, а также подчёркивается необходимость правил DRS VM/Host для разделения узлов WSFC по разным хостам.
• Также рекомендуется использовать диск-свидетель кворума, чтобы растянутый кластер сохранял доступность witness-диска при отказе сайта без остановки службы кластера FCI.
• Практический путь миграции с SAN pRDM на общие VMDK vSAN. С самого начала подчёркивается: «перед миграцией настоятельно рекомендуется создать резервную копию», и отмечается, что миграция выполняется офлайн. Описываются шаги по остановке роли кластера, выключению узлов и использованию Storage Migration для преобразования pRDM в VMDK на vSAN ± с обходным решением через PowerCLI (включая пример кода) в случае, если выбор формата диска в мастере Migrate недоступен.

Это руководство, которое вы передаёте команде, когда требование звучит как «нам нужна семантика FCI», и вы хотите получить осознанную, поддерживаемую архитектуру.

Что дальше

Если вы активно проектируете, обновляете или мигрируете инфраструктуру, рассматривайте эти руководства в контексте команд:

• Команды платформы: сначала прочитайте руководство по SQL Server, чтобы согласовать значения по умолчанию вычислений/хранилища/сети с поведением SQL.
• DBA и инженеры инфраструктуры: прочитайте руководство по HA до того, как зафиксируете модель кластеризации, стратегию хранения и модель обслуживания.
• Команды по идентификации и безопасности: прочитайте руководство по AD DS, чтобы согласовать меры настройки, восстановления и операционные процессы с современными механизмами защиты виртуализации.
• Команды, использующие (или стандартизирующие) SQL Server FCI: прочитайте руководство по FCI на vSAN, чтобы зафиксировать требования к общим дискам, позицию по политике хранения и ограничения растянутого кластера до внедрения.

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

• Architecting Microsoft SQL Server on VMware Cloud Foundation:
  https://www.vmware.com/docs/architecting-mssql-vcf
• Virtualizing Active Directory Domain Services on VMware Cloud Foundation:
  https://www.vmware.com/docs/active-directory-domain-services-vcf
• Architecting Microsoft SQL Server for High Availability on VMware Cloud Foundation:
  https://www.vmware.com/docs/architecting-mssql-ha-vcf
• Running Microsoft SQL Server Failover Cluster Instance on VMware vSAN with VMware Cloud Foundation 9:
  https://www.vmware.com/docs/mssql-fci-vcf-9

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

Администраторы ИТ-инфраструктур и ИТ-менеджеры часто задают вопросы наподобие: «Какое отношение виртуализация имеет к Kubernetes?» Понимание этого крайне важно для ИТ-подразделений и организационных бюджетов. Вычисления революционизировали то, как мы взаимодействуем друг с другом, как работаем, и сформировали рамки возможного в промышленности. ИТ-нагрузки требуют вычислительных ресурсов, таких как CPU, память, хранилище, сеть и т. д., чтобы выполнять нужные функции — например, отправку электронного письма или обновление базы данных. Важная часть бизнес-операций заключается в том, чтобы ИТ-организации оптимизировали стратегию размещения своих нагрузок — будь то на мейнфрейме, в локальном дата-центре или в публичном облаке.

Виртуализация не исчезла с появлением Kubernetes — напротив, она помогает Kubernetes работать лучше в масштабе предприятия.

Виртуализация

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

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

VMware возглавила бум облачных вычислений благодаря виртуализации архитектуры x86 — самого распространённого набора инструкций для персональных компьютеров и серверов. Теперь физическое оборудование могло размещать несколько распределённых приложений, поддерживать многих пользователей и полностью использовать дорогостоящее «железо». Виртуализация — ключевая технология, которая делает возможными публичные облачные вычисления; ниже приведено резюме:

• Абстракция: виртуализация абстрагирует физическое оборудование, предоставляющее CPU, RAM и хранилище, в логические разделы, которыми можно управлять независимо.
• Гибкость, масштабируемость, эластичность: абстрагированные разделы теперь можно масштабировать под потребности бизнеса, выделять и отключать по требованию, а ресурсы - возвращать по мере необходимости.
• Консолидация ресурсов и эффективность: физическое оборудование теперь может запускать несколько логических разделов «правильного размера» с нужным объёмом CPU, RAM и хранилища — максимально используя оборудование и снижая постоянные затраты, такие как недвижимость и электроэнергия.
• Изоляция и безопасность: у каждой ВМ есть собственный «мир» с ОС, независимой от той, что запущена на физическом оборудовании, что обеспечивает глубокую безопасность и изоляцию для приложений, использующих общий хост.

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

Контейнеризация

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

Контейнеры Docker упаковывают приложения и их зависимости - такие как код, библиотеки и конфигурационные файлы - в единицы, которые могут стабильно работать на любой инфраструктуре: будь то ноутбук разработчика, сервер в датацентре предприятия или сервер в публичном облаке. Контейнеры получили своё название по аналогии с грузовыми контейнерами и дают многие из тех же преимуществ, что и их физические «тёзки», такие как стандартизация, переносимость и инкапсуляция. Ниже — краткий обзор ключевых преимуществ контейнеризации:

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

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

Контейнер позволяет легко развёртывать приложения - Kubernetes позволяет масштабировать число экземпляров приложения, он гарантирует, что каждый экземпляр остаётся запущенным, и работает одинаково у любого облачного провайдера или в любом датцентре. Это три «S»-столпа: самовосстановление (Self-Healing), масштабируемость (Scalability) и стандартизация (Standardization). Эти результаты ускорили рост Kubernetes до уровня отраслевого золотого стандарта, и он стал повсеместным в cloud native-вычислениях, обеспечивая операционную согласованность, снижение рисков и повышенную переносимость.

Виртуализация > Контейнеризация

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

• Эффективность: благодаря общей ОС контейнеры устраняют накладные расходы (CPU, память, хранилище), связанные с запуском нескольких одинаковых ОС для приложений.
• Скорость: меньший «вес» позволяет значительно быстрее запускать и останавливать.
• Переносимость: контейнеры лёгкие и могут выполняться на любом совместимом контейнерном рантайме.

Виртуализация улучшает Kubernetes

Виртуализация также стабилизирует и ускоряет Kubernetes. Большинство управляемых Kubernetes-сервисов, включая предложения гиперскейлеров (EKS на AWS, AKS на Azure, GKE на GCP), запускают Kubernetes-слой поверх виртуализованной ОС. Поскольку Kubernetes-среды обычно сложны, виртуализация значительно усиливает изоляцию, безопасность и надёжность, а также упрощает операции управления накладными процессами. Краткий обзор преимуществ:

• Изоляция и безопасность: без виртуализации все контейнеры, работающие в кластере Kubernetes на физическом хосте, используют один и тот же Kernel (ядро ОС). Если контейнер взломан, всё, что работает на физическом хосте, потенциально может быть скомпрометировано на уровне оборудования. Гипервизор препятствует распространению злоумышленников на другие узлы Kubernetes и контейнеры.
• Надёжность: Kubernetes может перезапускать контейнеры, если те падают, но бессилен, если проблемы возникают на уровне физического хоста. Виртуализация может перезапустить окружение Kubernetes за счёт высокой доступности (High Availability) на другом физическом сервере.
• Операции: без виртуализации весь физический хост обычно принадлежит одному Kubernetes-кластеру. Это означает, что среда привязана к одной версии Kubernetes, что снижает скорость развития и делает апгрейды и операции сложными.

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

Broadcom предоставляет лучшую платформу для размещения рабочих нагрузок

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

• Harbor
• Antrea
• Contour
• Pinniped

Инженерные команды Broadcom продолжают активно участвовать в upstream Kubernetes и вносят вклад в такие проекты, как Harbor, Cluster API и etcd.

С выпуском VCF 9 подразделение VCF компании Broadcom принесло в отрасль унифицированные операции, общую инфраструктуру и единые инструменты, независимые от форм-факторов рабочих нагрузок. Клиенты могут запускать ВМ и контейнеры/Kubernetes-нагрузки на одном и том же оборудовании и управлять ими одними и теми же инструментами, на которых миллионы специалистов построили свои навыки и карьеры. Предприятия и организации могут снизить капитальные и операционные расходы, стандартизировать операционную модель и модернизировать приложения и инфраструктуру, чтобы бизнес мог двигаться быстрее, защищать данные и повышать надёжность своих ключевых систем.

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

Возможности VDI (виртуализации рабочих мест)

Импортозамещение коснулось не только серверной виртуализации, но и инфраструктуры виртуальных рабочих столов (VDI). После ухода VMware Horizon (сейчас это решение Omnissa) и Citrix XenDesktop российские компании начали внедрять отечественные VDI-решения для обеспечения удалённой работы сотрудников и центрального управления рабочими станциями. К 2025 году сформировался пул новых продуктов, позволяющих развернуть полнофункциональную VDI-платформу на базе отечественных технологий.

Лидерами рынка VDI стали решения, созданные в тесной связке с платформами серверной виртуализации. Так, компания «ДАКОМ М» (бренд Space) помимо гипервизора SpaceVM предложила продукт Space VDI – систему управления виртуальными рабочими столами, интегрированную в их экосистему. Space VDI заняла 1-е место в рейтинге российских VDI-решений 2025 г., набрав 228 баллов по совокупности критериев.

Её сильные стороны – полностью собственная разработка брокера и агентов (не опирающаяся на чужие open-source) и наличие всех компонентов, аналогичных VMware Horizon: Space Dispatcher (диспетчер VDI, альтернатива Horizon Connection Server), Space Agent VDI (клиентский агент на виртуальной машине, аналог VMware Horizon Agent), Space Client для подключения с пользовательских устройств, и собственный протокол удалённых рабочих столов GLINT. Протокол GLINT разработан как замена зарубежных (RDP/PCoIP), оптимизирован для работы в российских сетях и обеспечивает сжатие/шифрование трафика. В частности, заявляется поддержка мультимедиа-ускорения и USB-перенаправления через модуль Mediapipe, который служит аналогом Citrix HDX. В результате Space VDI предоставляет высокую производительность графического интерфейса и мультимедиа, сравнимую с мировыми аналогами, при этом полностью вписывается в отечественный контур безопасности.

Вторым крупным игроком стала компания HOSTVM с продуктом HostVM VDI. Этот продукт изначально основыван на открытой платформе UDS (VirtualCable) и веб-интерфейсе на Angular, но адаптирован российским разработчиком. HostVM VDI поддерживает широкий набор протоколов – SPICE, RDP, VNC, NX, PCoIP, X2Go, HTML5 – фактически покрывая все популярные способы удалённого доступа. Такая всеядность упрощает миграцию с иностранных систем: например, если ранее использовался протокол PCoIP (как в VMware Horizon), HostVM VDI тоже его поддерживает. Решение заняло 2-е место в отраслевом рейтинге с 218 баллами, немного уступив Space VDI по глубине интеграции функций.

Своеобразный подход продемонстрировал РЕД СОФТ. Их продукт «РЕД Виртуализация» является, в первую очередь, серверной платформой (форком oVirt на KVM) для развертывания ВМ. Однако благодаря тесной интеграции с РЕД ОС и другим ПО компании, Red Виртуализация может использоваться и для VDI-сценариев. Она заняла 3-е место в рейтинге VDI-платформ. По сути, РЕД предлагает создать инфраструктуру на базе своего гипервизора и доставлять пользователям рабочие столы через стандартные протоколы (для Windows-ВМ – RDP, для Linux – SPICE или VNC). В частности, поддерживаются протоколы VNC, SPICE и RDP, что покрывает базовые потребности. Кроме того, заявлена возможность миграции виртуальных машин в РЕД Виртуализацию прямо из сред VMware vSphere и Microsoft Hyper-V, что упрощает переход на решение.

Далее, существуют специализированные отечественные VDI-продукты: ROSA VDI, Veil VDI, Termidesk и др.

• ROSA VDI (разработка НТЦ ИТ РОСА) базируется на том же oVirt и ориентирована на интеграцию с российскими ОС РОСА.
• Veil VDI – решение компаний «НИИ Масштаб»/Uveon – представляет собственную разработку брокера виртуальных рабочих столов; оно также попало в топ-5 рейтинга.
• Termidesk – ещё одна проприетарная система, замыкающая первую шестёрку лидеров. Каждая из них предлагает конкурентоспособные функции, хотя по некоторым пунктам уступает лидерам. Например, Veil VDI и Termidesk пока набрали меньше баллов (182 и 174 соответственно) и, вероятно, имеют более узкую специализацию или меньшую базу внедрений.
  

Общей чертой российских VDI-платформ является ориентация на безопасность и импортозамещение. Все они зарегистрированы как отечественное ПО и могут применяться вместо VMware Horizon, Citrix или Microsoft RDS. С точки зрения пользовательского опыта, основные функции реализованы: пользователи могут подключаться к своим виртуальным рабочим столам с любых устройств (ПК, тонкие клиенты, планшеты) через удобные клиенты или даже браузер. Администраторы получают централизованную консоль для создания образов ВМ, массового обновления ПО на виртуальных рабочих столах и мониторинга активности пользователей. Многие решения интегрируются с инфраструктурой виртуализации серверов – например, Space VDI напрямую работает поверх гипервизора SpaceVM, ROSA VDI – поверх ROSA Virtualization, что упрощает установку.

Отдельно стоит отметить поддержку мультимедийных протоколов и оптимизацию трафика. Поскольку качество работы VDI сильно зависит от протокола передачи картинки, разработчики добавляют собственные улучшения. Мы уже упомянули GLINT (Space) и широкий набор протоколов в HostVM. Также используется протокол Loudplay – это отечественная разработка в области облачного гейминга, адаптированная под VDI.

Некоторые платформы (например, Space VDI, ROSA VDI, Termidesk) заявляют поддержку Loudplay наряду со SPICE/RDP, чтобы обеспечить плавную передачу видео и 3D-графики даже в сетях с высокой задержкой. Терминальные протоколы оптимизированы под российские условия: так, Termidesk применяет собственный кодек TERA для сжатия видео и звука. В результате пользователи могут комфортно работать с графическими приложениями, CAD-системами и видео в своих виртуальных десктопах.

С точки зрения масштабируемости VDI, российские решения способны обслуживать от десятков до нескольких тысяч одновременных пользователей. Лабораторные испытания показывают, что Space VDI и HostVM VDI могут управлять тысячами виртуальных рабочих столов в распределенной инфраструктуре (с добавлением необходимых серверных мощностей). Важным моментом остаётся интеграция со средствами обеспечения безопасности: многие платформы поддерживают подключение СЗИ для контроля за пользователями (DLP-системы, антивирусы на виртуальных рабочих местах) и могут работать в замкнутых контурах без доступа в интернет.

Таким образом, к концу 2025 года отечественные VDI-платформы покрывают основные потребности удалённой работы. Они позволяют централизованно развертывать и обновлять рабочие места, сохранять данные в защищённом контуре датацентра и предоставлять сотрудникам доступ к нужным приложениям из любой точки. При этом особый акцент сделан на совместимость с российским стеком (ОС, ПО, требования регуляторов) и на возможность миграции с западных систем с минимальными затратами (поддержка разных протоколов, перенос ВМ из VMware/Hyper-V). Конечно, каждой организации предстоит выбрать оптимальный продукт под свои задачи – лидеры рынка (Space VDI, HostVM, Red/ROSA) уже имеют успешные внедрения, тогда как нишевые решения могут подойти под специальные сценарии.

Кластеризация, отказоустойчивость и управление ресурсами

Функциональность, связанная с обеспечением высокой доступности (HA) и отказоустойчивости, а также удобством управления ресурсами, является критичной при сравнении платформ виртуализации. Рассмотрим, как обстоят дела с этими возможностями у российских продуктов по сравнению с VMware vSphere.

Кластеризация и высокая доступность (HA)

Почти все отечественные системы поддерживают объединение хостов в кластеры и автоматический перезапуск ВМ на доступных узлах в случае сбоя одного из серверов – аналог функции VMware HA. Например, SpaceVM имеет встроенную поддержку High Availability для кластеров: при падении хоста его виртуальные машины автоматически запускаются на других узлах кластера.

Basis Dynamix, VMmanager, Red Virtualization – все они также включают механизмы мониторинга узлов и перезапуска ВМ при отказе, что отражено в их спецификациях (наличие HA подтверждалось анкетами рейтингов). По сути, обеспечение базовой отказоустойчивости сейчас является стандартной функцией для любых платформ виртуализации. Важно отметить, что для корректной работы HA требуется резерв мощности в кластере (чтобы были свободные ресурсы для поднятия упавших нагрузок), поэтому администраторы должны планировать кластеры с некоторым запасом хостов, аналогично VMware.

Fault Tolerance (FT)

Более продвинутый режим отказоустойчивости – Fault Tolerance, при котором одна ВМ дублируется на другом хосте в режиме реального времени (две копии работают синхронно, и при сбое одной – вторая продолжает работать без прерывания сервиса). В VMware FT реализован для критичных нагрузок, но накладывает ограничения (например, количество vCPU). В российских решениях прямая аналогия FT практически не встречается. Тем не менее, некоторые разработчики заявляют поддержку подобных механизмов. В частности, Basis Dynamix Enterprise в материалах указывал наличие функции Fault Tolerance. Однако широкого распространения FT не получила – эта технология сложна в реализации, а также требовательна к каналам связи. Обычно достаточен более простой подход (HA с быстрым перезапуском, кластерные приложения на уровне ОС и т.п.). В критических сценариях (банковские системы реального времени и др.) могут быть построены решения с FT на базе метрокластеров, но это скорее штучные проекты.

Снапшоты и резервное копирование

Снимки состояния ВМ (snapshots) – необходимая функция для безопасных изменений и откатов. Все современные платформы (zVirt, SpaceVM, Red и прочие) поддерживают создание мгновенных снапшотов ВМ в рабочем состоянии. Как правило, доступны возможности делать цепочки снимков, однако требования к хранению диктуют, что постоянно держать много снапшотов нежелательно (как и в VMware, где они влияют на производительность). Для резервного копирования обычно предлагается интеграция с внешними системами бэкапа либо встроенные средства экспорта ВМ.

Например, SpaceVM имеет встроенное резервное копирование ВМ с возможностью сохранения бэкапов на удалённое хранилище. VMmanager от ISPsystem также предоставляет модуль бэкапа. Тем не менее, организации часто используют сторонние системы резервирования – здесь важно, что у российских гипервизоров обычно открыт API для интеграции. Почти все продукты предоставляют REST API или SDK, позволяющий автоматизировать задачи бэкапа, мониторинга и пр. Отдельные вендоры (например, Basis) декларируют принцип API-first, что упрощает связку с оркестраторами резервного копирования и мониторинга.

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

Мы уже упоминали наличие аналогов DRS в некоторых платформах (автоматическое перераспределение ВМ). Кроме этого, важно, как реализовано ручное управление ресурсами: пулы CPU/памяти, приоритеты, квоты. В VMware vSphere есть ресурсные пулы и shares-приоритеты. В российских системах подобные механизмы тоже появляются. zVirt, например, позволяет объединять хосты в логические группы и задавать политику размещения ВМ, что помогает распределять нагрузку. Red Virtualization (oVirt) исторически поддерживает задание весов и ограничений на ЦП и ОЗУ для групп виртуальных машин. В Basis Dynamix управление ресурсами интегрировано с IaC-инструментами – можно через Terraform описывать необходимые ресурсы, а платформа сама их выделит.

Такое тесное сочетание с DevOps-подходами – одно из преимуществ новых продуктов: Basis и SpaceVM интегрируются с Ansible, Terraform для автоматического развертывания инфраструктуры как кода. Это позволяет компаниям гибко управлять ИТ-ресурсами и быстро масштабировать кластеры или развертывать новые ВМ по шаблонам.

Управление кластерами

Центральная консоль управления кластером – обязательный компонент. Аналог VMware vCenter в отечественных решениях присутствует везде, хотя может называться по-разному. Например, у Space – SpaceVM Controller (он же выполняет роль менеджера кластера, аналог vCenter). У zVirt – собственная веб-консоль, у Red Virtualization – знакомый интерфейс oVirt Engine, у VMmanager – веб-панель от ISPsystem. То есть любой выбранный продукт предоставляет единый интерфейс для управления всеми узлами, ВМ и ресурсами. Многие консоли русифицированы и достаточно дружелюбны. Однако по отзывам специалистов, удобство администрирования ещё требует улучшений: отмечается, что ряд операций в отечественных платформах более трудоёмкие или требуют «танцев с бубном» по сравнению с отлаженным UI VMware. Например, на Хабре приводился пример, что создание простой ВМ в некоторых системах превращается в квест с редактированием конфигурационных файлов и чтением документации, тогда как в VMware это несколько кликов мастера создания ВМ. Это как раз то направление, где нашим решениям ещё есть куда расти – UX и простота администрирования.

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

Продолжение следует...

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

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

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

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

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

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

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

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

VMware vCenter Converter – это классический инструмент VMware для перевода физических и виртуальных систем в формат виртуальных машин VMware. Его корни уходят к утилите VMware P2V Assistant, которая существовала в 2000-х годах для «Physical-to-Virtual» миграций. В 2007 году VMware выпустила первую версию Converter (3.0), заменив P2V Assistant...

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

В VMware Tanzu Platform 10.3 компания Broadcom представила набор обновлений наблюдаемости в Tanzu Hub, которые углубляют видимость, ускоряют адаптацию команд и помогают сократить время решения проблем. Независимо от того, отвечаете ли вы за надежность, инженерные аспекты платформы или опыт разработчиков, новые функции позволяют автоматически получать и видеть релевантные данные, чтобы действовать быстрее и с большим доверием к своей платформе. Эти усовершенствования обеспечивают централизованный, целостный опыт наблюдаемости в Tanzu Hub.

Ключевые новые улучшения наблюдаемости в Tanzu Hub

В этом выпуске представлены усовершенствованные топологии и наложения оповещений, значительно повышающие видимость взаимосвязей инфраструктуры и зависимостей между сущностями. Теперь оверлей оповещений предоставляет более богатый контекст, включая возможность прямой связи с инфраструктурными системами или событиями в слое VCF, что упрощает процесс устранения неполадок. Контекстные оповещения автоматически сопоставляются с соответствующей сущностью, а в Tanzu Platform 10.3 эта функциональность распространяется также на сервисы и приложения. Эти оповещения будут отображаться в различных представлениях, включая Home, Alerts, Foundations, Applications, Service Instance и Topology.

Этот выпуск также предлагает новый уровень наблюдаемости и включает значительные улучшения тщательно настроенных панелей мониторинга и оповещений, основанных на ключевых показателях (KPI), а также runbook-ов для сервисов Tanzu Data Tile. Это позволяет различным командам сосредоточиться на формализации операционной экспертизы, делая её более доступной и практичной как для инженеров платформ, так и для команд разработчиков любого уровня опыта.

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

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

Эти усовершенствованные представления приносят значительные бизнес-преимущества и могут быть настроены под нужды разных команд, включая инженеров платформы и команды разработчиков. Возможность создавать и управлять пользовательскими панелями мониторинга, а также гибко контролировать данные с помощью фильтров на уровне панели, позволяет командам точно адаптировать свой опыт наблюдения под свои задачи. Кроме того, настройка макетов, диаграмм и виджетов гарантирует, что критически важные данные всегда представлены в наиболее удобной и действенной форме. Это объединение направлено на покрытие большинства сценариев использования Healthwatch, обеспечивая действия на основе разрешений и расширенные возможности анализа метрик. Бесшовная миграция всех панелей Healthwatch, помеченных тегом “healthwatch”, обеспечивает преемственность и простоту поиска. В конечном итоге эти возможности приводят к снижению простоев, повышению операционной эффективности и более проактивному подходу к поддержанию оптимальной производительности приложений, напрямую влияя на удовлетворенность клиентов и непрерывность бизнеса.

Почему эти улучшения важны

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

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

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

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

NVIDIA Run:ai на VCF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Службы VMware vSphere Kubernetes Service (VKS) версии 3.5 появились в общем доступе. Этот новый выпуск обеспечивает 24-месячную поддержку для каждой минорной версии Kubernetes, начиная с vSphere Kubernetes release (VKr) 1.34. Ранее, в июне 2025 года, VMware объявила о 24-месячной поддержке выпуска vSphere Kubernetes (VKr) 1.33. Это изменение обеспечивает командам, управляющим платформой, большую стабильность и гибкость при планировании обновлений.

VKS 3.5 также включает ряд улучшений, направленных на повышение операционной согласованности и улучшение управления жизненным циклом, включая детализированные средства конфигурации основных компонентов Kubernetes, декларативную модель управления надстройками и встроенную генерацию пакетов поддержки напрямую из интерфейса командной строки VCF CLI. Кроме того, новые защитные механизмы при обновлениях — такие как проверка PodDisruptionBudget и проверки совместимости — помогают обеспечить более безопасные и предсказуемые обновления кластеров.

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

Выпуск vSphere Kubernetes (VKr) 1.34

VKS 3.5 добавляет поддержку VKr 1.34. Каждая минорная версия vSphere Kubernetes теперь поддерживается в течение 24 месяцев с момента выпуска. Это снижает давление, связанное с обновлениями, стабилизирует рабочие среды и позволяет командам сосредоточиться на создании ценности, а не на постоянном планировании апгрейдов. Команды, которым нужен быстрый доступ к последним возможностям Kubernetes, могут оперативно переходить на новые версии. Те, кто предпочитает стабильную среду на длительный срок, теперь могут работать в этом режиме с уверенностью. VKS 3.5 поддерживает оба подхода к эксплуатации.

Динамическое распределение ресурсов (Dynamic Resource Allocation, DRA)

Функция DRA получила статус «стабильной» в основной ветке Kubernetes 1.34. Эта возможность позволяет администраторам централизованно классифицировать аппаратные ресурсы, такие как GPU, с помощью объекта DeviceClass. Это обеспечивает надежное и предсказуемое размещение Pod'ов на узлах с требуемым классом оборудования.

DRA повышает эффективность использования устройств, позволяя делить ресурсы между приложениями по декларативному принципу, аналогично динамическому выделению томов (Dynamic Volume Provisioning). Механизм DRA решает проблемы случайного распределения и неполного использования ресурсов. Пользователи могут выполнять точную фильтрацию, запрашивая конкретные устройства с помощью ResourceClaimsTemplates и ResourceClaims при развертывании рабочих нагрузок.

DRA также позволяет совместно использовать GPU между несколькими Pod'ами или контейнерами. Рабочие нагрузки можно настроить так, чтобы выбирать GPU-устройство с помощью Common Expression Language (CEL) и запросов ResourceSlice, что обеспечивает более эффективное использование по сравнению с count-based запросами.

Расширенные возможности конфигурации компонентов кластера Kubernetes

VKS 3.5 предоставляет гибкость для управления более чем 35 параметрами конфигурации компонентов Kubernetes, таких как kubelet, apiserver и etcd. Эти настройки позволяют командам платформ оптимизировать различные аспекты работы кластеров в соответствии с требованиями их рабочих нагрузок. Полный список доступных параметров конфигурации приведён в документации к продукту. Ниже приведён краткий обзор областей конфигурации, которые предлагает VKS 3.5:

Cluster API v1beta2 для улучшенного управления кластерами Kubernetes

VKS 3.5 включает Cluster API v1beta2 (CAPI v1.11.1), который вносит ряд изменений и улучшений в версии API для ресурсов по сравнению с v1beta1. Полный список улучшений можно найти в Release Notes для CAPI.

Для обеспечения плавного перехода все новые и существующие кластеры, созданные с использованием прежнего API v1beta1, будут автоматически преобразованы в API v1beta2 обновлёнными контроллерами Cluster API. В дальнейшем рекомендуется использовать API v1beta2 для управления жизненным циклом (LCM) кластеров Kubernetes.

Версия API v1beta2 является важным шагом на пути к выпуску стабильной версии v1. Основные улучшения включают:

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

Предотвращение сбоев обновлений из-за неверно настроенного PodDisruptionBudget

Pod Disruption Budget (PDB) — это объект Kubernetes, который помогает поддерживать доступность приложения во время плановых операций (например, обслуживания узлов, обновлений или масштабирования). Он гарантирует, что минимальное количество Pod’ов останется активным во время таких событий. Однако неправильно настроенные PDB могут блокировать обновления кластера.

VKS 3.5 вводит механизмы защиты (guardrails) для выявления ошибок конфигурации PDB, которые могут привести к зависанию обновлений или других операций жизненного цикла. Система блокирует обновление кластера, если обнаруживает, что PDB не допускает никаких прерываний.

Для повышения надёжности и успешности обновлений введено новое условие SystemChecksSucceeded в объект Cluster. Оно позволяет пользователям видеть готовность кластера к обновлению, в частности относительно конфигураций PDB.

Ключевые преимущества новой проверки:

• Проактивная блокировка обновлений — система обнаруживает PDB, препятствующие выселению Pod’ов, и останавливает обновление до его начала.
• Более чёткая диагностика проблем — параметр SystemChecksSucceeded устанавливается в false, если у любого PDB значение allowedDisruptions меньше или равно 0, что указывает на риск простоев.
• Планирование обновлений — позволяет заранее устранить ошибки конфигурации PDB до начала обновления.

Примечание: любой PDB, не связанный с Pod’ами (например, из-за неправильного селектора), также будет иметь allowedDisruptions = 0 и, следовательно, заблокирует обновление.

Упрощённые операции: CLI, управление надстройками и инструменты поддержки

Управление надстройками (Add-On Management)

VKS 3.5 упрощает эксплуатационные операции, включая управление жизненным циклом надстроек (add-ons) и создание пакетов поддержки. Новая функция VKS Add-On Management объединяет установку, обновление и настройку стандартных пакетов, предлагая:

• Единый метод для всех операций с пакетами, декларативный API и предварительные проверки совместимости.
• Возможность управления стандартными пакетами VKS через Supervisor Namespace (установка, обновления, конфигурации) — доступно через VKS-M 9.0.1 или новый плагин ‘addon’ в VCF CLI.
• Упрощённую установку Cluster Autoscaler с возможностью автоматического обновления при апгрейде кластера.
• Управление установками и обновлениями через декларативные API (AddonInstall, AddonConfig) с помощью Argo CD или других GitOps-контроллеров. Это обеспечивает версионируемое и повторяемое развертывание надстроек с улучшенной трассируемостью и согласованностью.
• Возможность настройки Addon Repository во всех кластерах VKS с помощью API AddonRepository / AddonRepositoryInstall, включая случаи с приватными регистрами.
  По умолчанию встроенный репозиторий VKS Standard Package устанавливается из пакета VKS (версия v2025.10.22 для релиза VKS 3.5.0).
• Во время обновлений кластеров VKS выполняет предварительные проверки совместимости надстроек и обновляет их до последних поддерживаемых версий. Если проверка не пройдена — обновление блокируется. При установке или обновлении надстроек выполняются дополнительные проверки, включая проверку на дублирование пакетов и анализ зависимостей.
• Упрощённое обнаружение новых версий и метаданных совместимости для Add-on Releases.

Интегрированный сборщик пакетов поддержки (Support Bundler) в VCF CLI

VKS 3.5 включает VKS Cluster Support Bundler непосредственно в VCF CLI, что значительно упрощает процесс сбора диагностической информации о кластерах. Теперь пользователи могут собирать всю необходимую информацию с помощью команды vcf cluster support-bundle, без необходимости загружать отдельный инструмент.

Основные улучшения здесь:

• Существенное уменьшение размера выходного файла.
• Селективный сбор логов — только с узлов control plane, для более быстрой и точной диагностики.
• Интегрированный сбор сетевых логов, что помогает анализировать сетевые проблемы и получить целостную картину состояния кластера.

Полезные ссылки:

• VKS 3.5 Release Notes
• VKS 3.5 Documentation
• Kubernetes 1.34 Upstream Release Notes
• Support Bundler Documentation
• Cluster API Upstream Release Notes

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

Хотя VMware Cloud Foundation (VCF) может обеспечивать высокий уровень доступности данных и приложений простым способом, в этой статье рассматриваются различия между обеспечением высокой доступности приложений и данных с использованием технологий на уровне приложений и встроенных механизмов на уровне инфраструктуры в VCF. Мы также рассмотрим, как VMware Data Services Manager (DSM) может помочь упростить принятие подобных решений.

Учёт отказов

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

• Централизованные решения для хранения, такие как дисковые массивы
• Отдельные устройства хранения в распределённых системах
• Хосты
• Сетевые карты (NIC)
• Коммутационные сети, вызывающие разделение кластеров (partition)
• Сбои уровня сайта или зоны

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

Доступность и восстановление приложений и данных

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

Доступность приложения

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

Доступность данных

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

Надёжность данных

Хранить данные в нескольких местах недостаточно — они должны записываться синхронно и последовательно во все копии, чтобы при сбое данные из одного места совпадали с данными из другого. Корпоративные системы хранения данных реализуют принципы ACID (атомарность, согласованность, изолированность, долговечность) и протоколы, обеспечивающие надёжность данных.

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

• RPO (Recovery Point Objective) — целевая точка восстановления. Показывает, с каким интервалом данные защищаются устойчивым образом. RPO=0 означает, что система всегда выполняет запись в синхронном, согласованном состоянии. Как будет отмечено далее, не все решения способны обеспечивать настоящий RPO=0.
• RTO (Recovery Time Objective) — целевое время восстановления. Показывает минимальное время, необходимое для восстановления систем и/или данных до рабочего состояния. Например, RTO=10m означает, что восстановление займёт не менее 10 минут. RTO может относиться к восстановлению доступности данных или комбинации данных и приложения.

Эволюция решений для высокой доступности

Подходы к обеспечению доступности данных и приложений эволюционировали с развитием технологий и ростом требований. Некоторые приложения, такие как Microsoft SQL Server, MySQL, PostgreSQL и другие, включают собственные механизмы репликации, обеспечивающие избыточность данных и состояния приложения. Виртуализация, совместно с общим хранилищем, предоставляет простые способы обеспечения высокой доступности приложений и хранимых ими данных.

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

Высокая доступность на уровне приложений (Application-Level HA)

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

Высокая доступность на уровне инфраструктуры (Infrastructure-Level HA)

Этот подход использует vSphere HA для перезапуска одного экземпляра приложения на другом хосте кластера. Синхронное и устойчивое хранение данных обеспечивает VMware vSAN (в контексте данного сравнения). Такая комбинация гарантирует высокую доступность приложения и его данных.

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

В приведённых примерах предполагается, что данные должны сохраняться в нескольких местах (например, на уровне сайта или зоны), чтобы обеспечить доступность при сбое площадки. Также предполагается, что приложение может работать в тех же местах. Оба варианта обеспечивают автоматический отказоустойчивый переход и RPO=0, поскольку данные записываются синхронно в несколько мест.

Высокая доступность на уровне приложений для приложений и данных

Высокая доступность на уровне приложений, как в случае MS SQL Always On Availability Groups (AG), использует два или более работающих экземпляра базы данных и дополнительное местоположение для определения кворума при различных сценариях отказа.

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

Высокая доступность на уровне инфраструктуры для приложений и данных

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

vSAN может выдерживать отказы отдельных устройств хранения, сетевых карт (NIC), сетевых коммутаторов, хостов и даже целых географических площадок или зон, которые определяются как «домен отказа» (fault domain).

В приведённом ниже примере кластер vSAN растянут между двумя площадками, чтобы обеспечить устойчивое хранение данных на обеих. Растянутые кластеры vSAN (vSAN Stretched Clusters) также используют третью площадку, на которой размещается небольшой виртуальный модуль — witness host appliance (хост-свидетель), помогающий определить кворум при различных возможных сценариях отказа.

Одним из самых убедительных преимуществ высокой доступности на уровне инфраструктуры является то, что в VCF она является встроенной частью платформы. vSAN интегрирован прямо в гипервизор и обеспечивает отказоустойчивость данных в соответствии с вашими требованиями, всего лишь посредством настройки простой политики хранения (storage policy). Экземпляры приложений становятся высокодоступными благодаря проверенной технологии vSphere HA, которая позволяет перезапускать виртуальные машины на любом хосте в пределах кластера vSphere. Такой подход также отлично работает, когда приложения баз данных развертываются и управляются в вашей среде VCF с помощью DSM.

Разные подходы к обеспечению согласованности данных

Хотя оба подхода могут обеспечивать цель восстановления точки (RPO), равную нулю (RPO=0), за счёт синхронной репликации, способы достижения этого различаются. Оба используют специальные протоколы, помогающие обеспечить согласованность данных, записываемых в нескольких местах — что на практике значительно сложнее, чем кажется.

В случае MS SQL Server Always On Availability Groups согласованность достигается на уровне приложения, тогда как vSAN обеспечивает синхронную запись данных по своей сути — как часть распределённой архитектуры, изначально разработанной для обеспечения отказоустойчивости.

При репликации данных на уровне приложения такой высокий уровень доступности ограничен только этим конкретным приложением и его данными. Однако возможности на уровне приложений реализованы не одинаково. Например, MS SQL Server Always On AG могут обеспечивать RPO=0 при множестве сценариев отказа, тогда как MySQL InnoDB Cluster использует подход, при котором RPO=0 возможно только при отказе одного узла. Хотя данные при этом остаются согласованными, в некоторых сценариях отказа — например, при полном сбое кластера или незапланированной перезагрузке — могут быть потеряны последние зафиксированные транзакции. Это означает, что при определённых обстоятельствах обеспечить истинный RPO=0 невозможно.

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

Различия во времени восстановления (RTO)

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

Например, некоторые приложения, такие как SQL Server AG, используют лицензированные «резервные» виртуальные машины (standby VMs) в вашей инфраструктуре, чтобы обеспечить использование другого состояния приложения при отказе. Это позволяет достичь низкого RTO, но приводит к увеличению затрат из-за необходимости дополнительных лицензий и потребляемых ресурсов. Высокая доступность на уровне приложения — это специализированное решение, требующее экспертизы в конкретном приложении для достижения нужного результата. Однако DSM может значительно снизить сложность таких сценариев, поскольку автоматизирует эти процессы и снимает значительную часть административной нагрузки.

Высокая доступность на уровне инфраструктуры работает иначе. Используя механизмы виртуализации, такие как vSphere High Availability (HA), она обеспечивает перезапуск приложения в другом месте при сбое виртуальной машины. Перезапуск ВМ и самого приложения, а также процесс восстановления журналов обычно занимают больше времени, чем подход с резервной ВМ, используемый при высокой доступности на уровне приложений.

Приведённые выше значения времени восстановления являются оценочными. Фактическое время восстановления может значительно различаться в зависимости от условий среды, размера и активности экземпляра MS SQL.

Что выбрать именно вам?

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

• Требования к доступности
  Возможно, ваши требования предполагают, что приложение и его данные должны быть доступны за пределами определённой границы отказа — например, уровня сайта или зоны. Это поможет определить, нужна ли вообще доступность на уровне сайта или зоны.
• Требования к RTO
  Если требуемое время восстановления (RTO) допускает 2–5 минут, то высокая доступность на уровне инфраструктуры — отличный вариант, поскольку она встроена в платформу и работает для всех ваших нагрузок. Если же есть несколько отдельных приложений, для которых требуется меньшее RTO, и вас не смущают дополнительные затраты и сложность, связанные с этим решением, то подход на уровне приложения может быть оправдан.
• Технические ограничения
  В вашей организации могут быть инициативы по упрощению инструментов и рабочих процессов, что может ограничивать возможность или желание использовать дополнительные технологии, такие как высокая доступность на уровне приложений. Обычно предпочтение отдаётся универсальным инструментам, применимым ко всем системам, а не узкоспециализированным решениям. Другие технические факторы, например задержки (latency) между сайтами или зонами, также могут сделать тот или иной подход непрактичным.
• Финансовые ограничения
  Возможно, на вас оказывают давление с целью сократить постоянные расходы на программное обеспечение — например, на дополнительные лицензии или более дорогие уровни лицензирования, необходимые для обеспечения высокой доступности на уровне приложений. В этом случае более выгодным решением могут оказаться уже имеющиеся технологии.

Можно также использовать комбинацию обоих подходов.

Например, на первом рисунке в начале статьи показано, как высокая доступность на уровне приложений реализуется между сайтами или зонами с помощью MS SQL Always On Availability Groups, а высокая доступность на уровне инфраструктуры обеспечивается vSAN и vSphere HA внутри каждого сайта или зоны.

Этот вариант также может быть отличным примером использования VMware Data Services Manager (DSM). Вместо запуска и управления отдельными виртуальными машинами можно использовать базы данных, развёрнутые DSM, для обеспечения доступности приложений между сайтами или зонами. Такой подход обеспечивает низкое RTO, устраняет административную сложность, связанную с репликацией на уровне приложений, и при этом позволяет vSAN обеспечивать доступность данных внутри сайтов или зон.

Современная инфраструктура не прощает простоев. Любая потеря доступности данных — это не только бизнес-риск, но и вопрос репутации.
VMware vSAN, будучи ядром гиперконвергентной архитектуры VMware Cloud Foundation, всегда стремился обеспечивать высокую доступность и устойчивость хранения. Но с появлением Express Storage Architecture (ESA) подход к отказоустойчивости изменился фундаментально.

Документ vSAN Availability Technologies (часть VCF 9.0) описывает, как именно реализована устойчивость на уровне данных, сетей и устройств. Разберём, какие технологии стоят за доступностью vSAN, и почему переход к ESA меняет правила игры.

Архитектура отказоустойчивости: OSA против ESA

OSA — классика, но с ограничениями

Original Storage Architecture (OSA) — традиционный вариант vSAN, основанный на концепции дисковых групп (disk groups):

• Одно кэш-устройство (SSD)
• Несколько накопителей ёмкости (HDD/SSD)

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

ESA — новое поколение хранения

Express Storage Architecture (ESA) ломает эту модель:

• Нет больше disk groups — каждый накопитель независим.
• Используется кодирование erasure coding (RAID-5/RAID-6) как стандарт, без потери производительности.
• Архитектура разделена на performance leg и capacity leg — баланс скорости и надёжности.
• Встроен мониторинг NVMe-износа, зеркалирование метаданных и прогноз отказов устройств.

В результате ESA уменьшает "зону взрыва" при сбое и повышает эффективность хранения до 30–50 %, особенно при политике FTT=2.

Как vSAN обеспечивает доступность данных

Всё в vSAN строится вокруг объектов (диски ВМ, swap, конфигурации). Каждый объект состоит из компонентов, которые распределяются по узлам.
Доступность объекта определяется параметром FTT (Failures To Tolerate) — числом отказов, которые система выдержит без потери данных.

Например:

• FTT=1 (RAID-1) — один отказ хоста или диска.
• FTT=2 (RAID-6) — два отказа одновременно.
• RAID-5/6 обеспечивает ту же устойчивость, но с меньшими затратами ёмкости.

Механизм кворума

Каждый компонент имеет "голос". Объект считается доступным, если более 50 % голосов доступны. Это предотвращает split-brain-ситуации, когда две части кластера считают себя активными.

В сценариях 2-Node или stretched-cluster добавляется witness-компонент — виртуальный "свидетель", решающий, какая часть кластера останется активной.

Домены отказов и географическая устойчивость

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

В растянутом кластере (stretched cluster) домены соответствуют сайтам, а witness appliance располагается в третьей зоне для арбитража.

Рекомендация: проектируйте кластер не по минимуму (3–4 узла), а с запасом. Например, для FTT=2 нужно минимум 6 узлов, но VMware рекомендует 7, чтобы система могла восстановить избыточность без потери устойчивости.

Поведение при сбоях: состояния компонентов

vSAN отслеживает каждое состояние компонентов:

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

Сеть как основа устойчивости

vSAN — это распределённое хранилище, и его надёжность напрямую зависит от сети.

• Транспорт — TCP/unicast с внутренним протоколом Reliable Datagram Transport (RDT).
• Поддерживается RDMA (RoCE v2) для минимизации задержек.
• Рекомендуется:
  • 2 NIC на каждый хост;
  • Подключение к разным коммутаторам;
  • Active/Standby teaming для vSAN-трафика (предсказуемые пути).

Если часть сети теряет связность, vSAN формирует partition groups и использует кворум, чтобы определить, какая группа "основная". vSAN тесно интегрирован с vSphere HA, что обеспечивает синхронное понимание состояния сети и автоматический рестарт ВМ при отказах.

Ресинхронизация и обслуживание

Resync (восстановление)

Когда хост возвращается в строй или изменяется политика, vSAN ресинхронизирует данные для восстановления FTT-уровня. В ESA ресинхронизация стала интеллектуальной и возобновляемой (resumable) — меньше нагрузка на сеть и диски.

Maintenance Mode

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

1. Full Data Migration — полная миграция данных (долго, безопасно).
2. Ensure Accessibility — минимальный перенос для сохранения доступности (дефолт).
3. No Data Migration — без переноса (быстро, рискованно).

ESA использует durability components, чтобы временно сохранить данные и ускорить возврат в строй.

Предиктивное обслуживание и мониторинг

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

• Degraded Device Handling (DDH) — анализ деградации накопителей по задержкам и ошибкам до фактического отказа.
• NVMe Endurance Tracking — контроль износа NVMe с предупреждениями в vCenter.
• Low-Level Metadata Resilience — зеркалирование метаданных для защиты от URE-ошибок.
• Proactive Hardware Management — интеграция с OEM-телеметрией и предупреждения через Skyline Health.

Эти механизмы в ESA работают точнее и с меньшими ложными срабатываниями по сравнению с OSA.

Доступность не равно защита данных

VMware подчёркивает разницу между понятиями:

• Availability — локальная устойчивость (хост, диск, сеть).
• Disaster Recovery — восстановление после катастрофы (вторая площадка, репликация, резервное копирование).

vSAN отвечает за первое. Для второго используются VMware SRM, vSphere Replication и внешние DR-решения. Однако комбинация vSAN ESA + stretched cluster уже позволяет реализовать site-level resilience без отдельного DR-инструмента.

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

1. Используйте ESA при проектировании новых кластеров.
   Современные NVMe-узлы и сети 25 GbE позволяют реализовать отказоустойчивость без потери производительности.
2. Проектируйте с запасом по хостам.
   Один дополнительный узел обеспечит восстановление без снижения FTT-уровня.
3. Настройте отказоустойчивую сеть.
   Два интерфейса, разные коммутаторы, Route Based on Port ID — минимальные требования для надёжного vSAN-трафика.
4. Следите за здоровьем устройств.
   Активируйте DDH и NVMe Endurance Monitoring, используйте Skyline Health для предиктивного анализа.
5. Планируйте обслуживание грамотно.
   Режим Ensure Accessibility — оптимальный баланс между безопасностью и скоростью.

Заключение

VMware vSAN уже давно стал стандартом для гиперконвергентных систем, но именно с Express Storage Architecture он сделал шаг от "устойчивости" к "самоисцеляемости". ESA сочетает erasure coding, предиктивную аналитику и глубокую интеграцию с платформой vSphere, обеспечивая устойчивость, производительность и эффективность хранения. Для архитекторов и инженеров это значит одно: устойчивость теперь проектируется не как надстройка, а как неотъемлемая часть самой архитектуры хранения.

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vSphere Native Key Provider

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

Administration -> Network Settings -> Network Pool

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

Global Inventory List -> Hosts -> Network Pools

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

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

Inventory -> Hosts

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

Global Inventory List -> Hosts -> Unassigned Hosts

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

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

Inventory -> Workload Domains

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

Inventory -> VCF Instance

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

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

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

или

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

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

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

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

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

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

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

Administration -> Backup

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

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

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

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

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

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

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

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

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

Administration -> Network Settings

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

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

Настройки DNS:

Настройки NTP:

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

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

Security -> Certificate Authority

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

Fleet Management -> Certificates -> Configure CA

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

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

Inventory -> Workload Domains -> Workload -> Certificates

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

Fleet Management -> Certificates -> Management

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

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

Security -> Password Management

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

Fleet Management -> Passwords

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

Экземпляр VCF:

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

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

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

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

vCenter Network Object -> Network -> Network Connectivity

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

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

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

Недавно компания Orion soft анонсировала релизы платформы виртуализации - zVirt 4.5 и zVirt 5.0. Давайте посмотрим, что нового обещает разработчик отечественной платформы виртуализации.

zVirt 4.5: вектор на производительность и виртуализацию сетей

По словам Orion soft, релиз 4.5 сфокусирован на двух крупных направлениях:

1. Рост производительности (внутренние оптимизации стека),
2. Дальнейшее развитие сетевой виртуализации (SDN). Это не «косметика», а серия внутренних апгрейдов, которые готовят почву под 5.0. Подробный перечень фич компания не публиковала, акцент именно на эти векторы развития.

Что это означает на практике:

• Ускорение «горячих» путей данных. В реальной эксплуатации это обычно выражается в уменьшении задержек операций ввода-вывода ВМ, росте пропускной способности при миграциях и репликации, а также в снижении накладных расходов управляющих сервисов. В контексте последних релизов zVirt компания уже поднимала потолок репликации и улучшала экспорт метрик/логов — версия 4.5 логично продолжает эту линию, но уже как «внутренний» апгрейд ядра платформы.
• Упрочнение SDN-стека. С версии 4.0/4.2 zVirt продвигал микросегментацию и управляемые сети через UI; в 4.5 ожидаем дальнейшее выравнивание производительности и функциональности SDN под крупные инсталляции (много проектов/сетей, избыточные связи, тонкая политика East-West). Идея — дать базис для грядущей миграции сетевых конфигураций из vSphere/NSX-подобных сценариев, заявленных к 5.0.

Вывод для архитекторов: 4.5 — это «подкапотный» релиз, который не меняет ваши процессы, но подготавливает площадку: стабильнее SDN, выше пропускная способность, а значит — меньше рисков при масштабировании кластеров и при переходе на версию 5.0.

zVirt 5.0: крупные продуктовые сдвиги

Для zVirt 5.0 Orion soft публично называл ряд ключевых возможностей, которые заметно расширяют зону автоматизации и упрощают миграцию с VMware-ландшафтов:

1. Storage DRS (распределение нагрузки по хранилищам)

Идеология — объединить несколько доменов хранения в логический «кластер» и автоматически балансировать размещение/миграцию дисков/ВМ по политикам (запас по IOPS/latency/ёмкости, «горячие» тома и т. п.). Это сокращает ручные операции, снижает риск «перекоса» томов хранения (LUN) и ускоряет реакцию на всплески нагрузки. Orion soft ранее уже демонстрировал Storage DRS в линейке 4.x, ну а в 5.0 ожидается консолидация и развитие этого направления как «функции по умолчанию» для больших инсталляций.

Практический эффект:

• Более предсказуемые SLA на уровне хранилища для VMs/VDIs.
• Упрощение сценариев расширения емкости (add capacity -> автоматический ребаланс).
• Меньше ручных миграций хранилищ в пиковые часы.

2. Упрощённый инсталлятор (быстрое развертывание/апгрейды)

Цель — сократить TTV (time-to-value): меньше шагов, больше проверок совместимости и готовности (сети, CPU-фичи, хранилища, сертификаты), шаблоны для типовых топологий (Hosted Engine, Standalone, edge-кластера). Это критично для массовых миграций с VMware: когда десятки площадок поднимаются параллельно, выигрыш в часах на площадку умножается на десятки.

3. Управление аппаратной репликацией на СХД

Речь о DR на уровне массивов (например, YADRO TATLIN.UNIFIED, Huawei Dorado и др.) с оркестрацией из консоли zVirt. Преимущества аппаратной репликации — RPO до 0 сек при синхронных схемах и низкая нагрузка на гипервизоры/SAN. План аварийного переключения становится «кнопкой» в едином UI. В 4.x уже были интеграции и демонстрации такого подхода, а версия 5.0 укрепляет это как нативный сценарий с централизованным управлением планами DR.

Практический эффект:

• Единый контрольный контур для DR (агентская и аппаратная репликации)
• Меньше конфликтов за ресурсы между продуктивом и DR-задачами
• Формализованные RTO/RPO для аудита

4. Terraform-провайдер

Провайдер позволяет декларативно описывать кластера, ВМ, сети/SDN-объекты, политики, хранилища — и воспроизводить их через CI/CD. Это даёт привычную для DevOps-команд «инфраструктуру как код» поверх zVirt, ускоряя создание однотипных стендов, DR-сайтов и «blue/green» сред.

Практический эффект:

• Контроль версий для инфраструктуры (git-история ваших кластеров)
• Воспроизводимость площадок (dev -> stage -> prod)
• Быстрый откат/повторение конфигураций по слияниям (merges).

5. Миграция конфигураций с VMware vSphere на SDN zVirt

Отдельно заявлена возможность импорта сетевых конфигураций из VMware-ландшафтов в SDN-модель zVirt: перенос порт-групп, сегментации, ACL/микросегментации и прочее. Это важная часть «бесшовной» стратегии импортозамещения: раньше боль была не только «перенести ВМ», но и воссоздать сетевую политику («зашитую» в vSphere/NSX). Версия 5.0 обещает автоматизировать этот пласт работ.

Практический эффект:

• Сокращение ошибок при ручном переносе сетей
• Предсказуемость инфраструктуры безопасности после миграции
• Ускорение cut-over окон при переездах больших ферм ВМ.

Как готовиться к zVirt 4.5/5.0 в производственной среде

1. Проверить лимиты и совместимость (ядра, CPU-фичи, сетевые карты, Mellanox/Intel, fabric-параметры, NUMA-profile, лимиты по миграциям/сетям/ВМ) — чтобы апгрейды прошли «в стык», без регрессий. Актуальные лимиты и best practices доступны в вики Orion soft.
2. Нормализовать SDN-модель: привести именование сетей/проектов к единому стандарту, сверить микросегментацию и схему ACL — это упростит будущий импорт конфигураций и policy-driven-балансировку. В версии 4.2 уже был сделан большой шаг по SDN/микросегментации.
3. Обновить процессы DR: если у вас есть массивы с аппаратной репликацией — инвентаризовать пары массивов, RPO/RTO, каналы межплощадочной связи; продумать, какие сервисы уйдут на аппаратную репликацию, а какие останутся на агентской (уровень гипервизора).
4. Заложить IaC-подход: начать описывать парки ВМ, сети, хранилища в Terraform (как минимум — черновые манифесты), чтобы к моменту выхода провайдера под 5.0 ваш репозиторий уже отражал фактическую инфраструктуру.

Более подробно о новых возможностях zVirt 4.5 и zVirt 5.0 можно почитать вот тут.

В рамках обновления инфраструктуры VMware Cloud Foundation 9 компания VMware обновила и свое основное средство для миграции физических и виртуальных машин на платформу VCF - vCenter Converter Standalone 9.0, про долгое отсутствие обновлений которого мы писали вот тут.

Давайте посмотрим, что нового в Converter девятой версии:

1. Поддержка VMware Cloud Foundation 9.0 и нового виртуального оборудования

• Версия 9.0 добавляет полную совместимость с VMware Cloud Foundation 9.0, что позволяет интеграцию с последним стеком VMware.
• Добавлена поддержка виртуального аппаратного обеспечения (virtual hardware) версии 22, обеспечивающего более широкие возможности и улучшенную производительность виртуальных машин.

2. Поддержка SSL-сертификатов

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

3. Усовершенствования в области безопасности: TLS-протоколы

• По умолчанию Converter 9.0 поддерживает только TLS 1.2, что соответствует современным стандартам безопасности.
• При необходимости возможно включение устаревших протоколов TLS 1.0 и TLS 1.1, однако делать это рекомендуется только в исключительных ситуациях.

4. Поддержка IPv6 и различных типов источников

• Теперь поддерживается IPv6, что позволяет выполнять конвертацию в современных сетевых инфраструктурах.
• Расширена поддержка типов источников: можно конвертировать удалённые работающие машины, выключенные виртуальные машины VMware и виртуальные машины на Hyper-V Server.

5. Улучшения удалённого доступа и клиент-серверной архитектуры

• Благодаря remote access, доступно создание и управление задачами конвертации удалённо — с удалённого клиента через клиент-серверную установку. Это значительно упрощает работу в распределённых средах.

Рекомендации по использованию

1. Обновите vCenter Converter Standalone до версии 9.0, чтобы воспользоваться новыми возможностями безопасности и совместимости.
2. Настройте SSL-сертификаты для защиты SSH- и API-трафика.
3. Проверьте конфигурацию сети, особенно если используется IPv6.
4. Используйте только TLS 1.2, если нет веских причин активировать устаревшие протоколы.
5. Настройте архитектуру клиент-сервер для эффективного управления задачами конвертации удалённо.

Ограничения

• Поддержка аутентификации с использованием алгоритмов RSA SHA1 устарела. Вместо этого рекомендуется использовать более новые алгоритмы или перейти на аутентификацию по паролю.
• vCenter Converter Standalone поддерживает исходные и целевые дисковые накопители только с размером сектора 512B (512e и 512n). Диски с нативным размером сектора 4K (4Kn) не поддерживаются.
• Начиная с версии vCenter Converter Standalone 9.0, конвертация файловых систем ReiserFS больше не поддерживается.

Недавно компания 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 (VCF 9) стало улучшение пользовательского опыта при развертывании. VMware не только упростила процесс развертывания нового экземпляра VCF, но и расширила поддержку различных типов топологий и сценариев развертывания. В результате пользователи vSphere получают более простой, быстрый и воспроизводимый процесс перехода на VCF.

VMware Cloud Foundation 9 предлагает несколько вариантов развертывания для модернизации инфраструктуры:

• Развертывание нового экземпляра VCF
• Расширение существующего пула VCF (VCF Fleet)
• Конвертация существующего развертывания vCenter в VCF
• Импорт существующего развертывания vCenter в VCF

Начнём с того, как происходит развертывание и масштабирование VCF 9.

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

VCF Installer можно использовать для:

• Развертывания нового экземпляра VCF как части нового пула (Fleet)
• Если у заказчика уже есть несколько сред, он может развернуть дополнительные экземпляры VCF в существующем пуле.

Каждый экземпляр VCF развёртывается с использованием vSphere и сервера vCenter, NSX, VCF Operations и VCF Automation. Настройка VCF-среды с использованием vSAN обеспечивает полный стек SDDC (программно-определяемого датацентра).

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

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

И это ещё не всё, что умеет VCF Installer. Рабочий процесс установщика также предоставляет возможность конвертировать существующий экземпляр VCF Operations и/или VCF Automation. Виртуальный модуль VCF Installer обеспечивает более простой, быстрый и воспроизводимый процесс перехода к VMware Cloud Foundation для клиентов.

Подробнее о виртуальном модуле VCF Installer

Виртуальный модуль VCF Installer заменяет Cloud Builder, использовавшийся в предыдущих версиях VCF. Он предоставляет гибкий набор опций, ещё больше упрощающих развертывание полноценной частной облачной среды.

VCF Installer содержит интерфейс с пошаговым управлением (UI-driven workflow) и больше не требует использования файла Deployment Parameters Workbook (таблица Excel). Также в него встроены функции конвертации и импорта существующих инстанций vCenter, VCF Operations и VCF Automation — без необходимости использовать скрипты VCF Import.

В предыдущих версиях Cloud Foundation требовалось устанавливать Aria Operations и Aria Automation отдельно и управлять ими на этапе Day 2 (после начального развертывания). Начиная с VCF 9, VCF Installer используется для развертывания всего стека VCF, включая гипервизор vSphere, хранилище, сеть, управление и самообслуживание, а VCF Operations отвечает за полное управление жизненным циклом этого стека.

Как работает VCF Installer?

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

При подключении к порталу поддержки Broadcom пользователь загружает программные бинарные файлы, подключаясь к онлайн-репозиторию. В отличие от Cloud Builder, модуль VCF Installer не содержит бинарных файлов ПО.

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

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

Экземпляр VCF может быть развернут как часть нового пула (VCF Fleet) или добавлен к существующему пулу. VCF Fleet может включать в себя несколько развертываний VCF, использующих общие экземпляры VCF Operations и VCF Automation.

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

1. Развертывание новых компонентов, включая виртуальные машины для vCenter Server, NSX, VCF Operations и VCF Automation.

2. Использование уже существующих компонентов, например, существующих экземпляров vCenter Server, VCF Operations и VCF Automation.

При выборе конвертации (повторного использования) существующего vCenter Server, VCF Installer конвертирует существующий кластер vSphere или vSphere с vSAN в управляющий кластер VCF. В рамках этого процесса VCF Installer автоматически развёртывает NSX.

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

Виртуальные машины для новых экземпляров VCF Operations, VCF Automation и NSX можно развернуть в двух режимах:

• Простой режим (Simple Model) — одноузловые виртуальные модули.
• Режим высокой доступности (High Availability Model) — несколько модулей для отказоустойчивости.

После успешного развертывания VCF Installer предоставляет ссылку для запуска VCF Operations, который используется для управления.

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

Простой режим (Simple Model)

Минимум 7 виртуальных модулей:

• 1 для vCenter Server
• 1 для SDDC Manager
• 1 для NSX Manager
• 3 для VCF Operations: Operations Manager, Fleet Management, Operations Collector
• 1 для VCF Automation

Если выбрана опция Supervisor, разворачивается виртуальный модуль VKS. Дополнительно после установки можно развернуть:

• Поддержку логов в VCF Operations
• Безопасное подключение к NSX Edge кластеру
• Базу данных VIDB для управления доступом и идентификацией

Модель высокой доступности (High Availability Model)

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

• 3 NSX Manager
• 3 VCF Operations
• 3 VCF Automation
• 3 для логов и 1 для VKS

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

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

• VCF Operations for Networks
• HCX
• Другие дополнительные сервисы VCF Advanced (Add-ons)

Как управлять средой VCF 9?

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

Но и это ещё не всё - VCF Operations для VCF 9 также включает встроенные рабочие процессы, которые поддерживают ещё два дополнительных сценария развертывания VCF. С помощью VCF Operations можно:

• Создавать новые домены рабочих нагрузок (workload domains)
• Импортировать существующие развертывания vCenter в существующий экземпляр VMware Cloud Foundation

Оба варианта позволяют масштабировать частное облако и обеспечивают централизованное управление и эксплуатацию.

Импорт существующих развертываний vCenter в экземпляр VMware Cloud Foundation

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

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

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

Можно импортировать:

• Кластеры vSphere с или без vSAN
• Кластеры с или без NSX
• Любую комбинацию этих компонентов

Если NSX в кластере ещё не развернут, он будет установлен автоматически в процессе конвертации.

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

• Хосты с одним физическим сетевым адаптером (pNIC)
• Кластеры с включённым LACP
• Одноузловые кластеры и отдельные хосты (standalone)

• Кластеры vSAN из 2 узлов
• HCI Mesh
• Кластеры хранения vSAN
• Растянутые кластеры vSAN (stretched clusters)

Также можно импортировать кластеры, использующие внешние хранилища, например:

• NFS
• VMFS over Fibre Channel (FC)
• iSCSI

• Развертывания vCenter Server, как с NSX, так и без него, могут быть импортированы

Резюме

VMware Cloud Foundation 9 (VCF 9) предлагает несколько вариантов развертывания для модернизации вашей инфраструктуры:

• Для нового развертывания VCF 9 требуется минимум 4 хоста для управляющего кластера, который может быть развернут с использованием vSAN, NFS или VMFS по FC.
• Начиная с VCF 9, управляющий кластер можно настраивать с помощью узлов vSAN Ready Nodes (рекомендуется).
• Также поддерживается оборудование vSphere, сертифицированное для использования с топологиями хранения на NFS/VMFS over FC. Подробности — в руководстве по совместимости (Compatibility Guide).
• Управляющий домен нового экземпляра VCF настраивается с использованием NSX. Каждый рабочий домен (Workload Domain) также конфигурируется с NSX и готов к использованию виртуальной сети NSX (SDN).

• Развертывание нового экземпляра VCF как части уже существующего пула.
• Каждый VCF Fleet управляется общими экземплярами VCF Operations и VCF Automation.

• VMware поддерживает конвертацию (повторное использование) существующих кластеров vSphere в VCF.
• Такие среды могут быть развернуты с vSphere или vSphere с vSAN.
• Среды vCenter с уже установленным NSX пока не поддерживаются для конвертации в управляющий домен VCF. В процессе будет установлен новый экземпляр NSX.

Требуется минимум:

• 3 узла vSAN Ready.
• Или 2 хоста vSphere, настроенные с NFS или VMFS over FC (cм. VCF configmax для дополнительной информации).

Импорт развертывания vCenter в VCF:

Требуется минимум:

• 3 узла vSAN Ready.
• Или 2 хоста vSphere, настроенные с NFS или VMFS over FC (cм. VCF configmax для дополнительной информации).
• Существующие среды vCenter с установленным NSX могут быть импортированы как домены рабочей нагрузки.

• Новый экземпляр VCF развертывается в режиме оценки (evaluation mode).
• В этом режиме VCF полностью функционален и позволяет развертывать дополнительные хосты, домены рабочей нагрузки и кластеры.
• Экземпляр VCF 9 необходимо активировать лицензией в течение 90 дней с момента установки.
• VCF Operations направляет пользователя в Broadcom Business Services Console для завершения процесса лицензирования.

• Начиная с VCF 9, VCF Operations используется для управления одним или несколькими экземплярами VCF.
• SDDC Manager 9 устанавливается или обновляется как компонент любого экземпляра VCF 9.
• SDDC Manager будет выведен из эксплуатации в одном из будущих релизов.

В предыдущей статье мы рассмотрели, что производительность vSAN зависит не только от физической пропускной способности сети, соединяющей хосты vSAN, но и от архитектуры самого решения. При использовании vSAN ESA более высокоскоростные сети в сочетании с эффективным сетевым дизайном позволяют рабочим нагрузкам в полной мере использовать возможности современного серверного оборудования. Стремясь обеспечить наилучшие сетевые условия для вашей среды vSAN, вы, возможно, задаётесь вопросом: можно ли ещё как-то улучшить производительность vSAN за счёт сети? В этом посте мы обсудим использование vSAN поверх RDMA и разберёмся, подойдёт ли это решение вам и вашей инфраструктуре.

Обзор vSAN поверх RDMA

vSAN использует IP-сети на базе Ethernet для обмена данными между хостами. Ethernet-кадры (уровень 2) представляют собой логический транспортный слой, обеспечивающий TCP-соединение между хостами и передачу соответствующих данных. Полезная нагрузка vSAN размещается внутри этих пакетов так же, как и другие типы данных. На протяжении многих лет TCP поверх Ethernet обеспечивал исключительно надёжный и стабильный способ сетевого взаимодействия для широкого спектра типов трафика. Его надёжность не имеет аналогов — он может функционировать даже в условиях крайне неудачного проектирования сети и плохой связности.

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

Чтобы компенсировать особенности TCP-сетей на базе Ethernet, можно использовать vSAN поверх RDMA через конвергентный Ethernet (в частности, RoCE v2). Эта технология всё ещё использует Ethernet, но избавляется от части избыточной сложности TCP, переносит сетевые операции с CPU на аппаратный уровень и обеспечивает прямой доступ к памяти для процессов. Более простая сетевая модель высвобождает ресурсы CPU для гостевых рабочих нагрузок и снижает задержку при передаче данных. В случае с vSAN это улучшает не только абсолютную производительность, но и стабильность этой производительности.

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

Если в конфигурации RDMA возникает хотя бы одна проблема — например, один из хостов кластера теряет возможность связи по RDMA — весь кластер автоматически переключается обратно на TCP поверх Ethernet.

Рекомендация. Рассматривайте использование RDMA только в случае, если вы используете vSAN ESA. Хотя поддержка vSAN поверх RDMA появилась ещё в vSAN 7 U2, наибольшую пользу эта технология приносит в сочетании с высокой производительностью архитектуры ESA, начиная с vSAN 8 и выше.

Как указано в статье «Проектирование сети vSAN», использование RDMA с vSAN влечёт за собой дополнительные требования, ограничения и особенности. К ним относятся:

• ReadyNodes для vSAN должны использовать сетевые адаптеры, сертифицированные для RDMA.
• Коммутаторы должны быть совместимы с RDMA и настроены соответствующим образом (включая такие параметры, как DCB — Data Center Bridging и PFC — Priority Flow Control).
• Размер кластера не должен превышать 32 хоста.
• Поддерживаются только следующие политики объединения интерфейсов:
  • Route based on originating virtual port
  • Route based on source MAC hash
    Использование LACP или IP Hash не поддерживается с RDMA.

• Предпочтительно использовать отдельные порты сетевых адаптеров для RDMA, а не совмещать RDMA и TCP на одном uplink.
• RDMA не совместим со следующими конфигурациями:

• 2-узловые кластеры (2-Node)
• Растянутые кластеры (stretched clusters)
• Совместное использование хранилища vSAN
• Кластеры хранения vSAN (vSAN storage clusters)
• В VCF 5.2 использование vSAN поверх RDMA не поддерживается. Эта возможность не интегрирована в процессы SDDC Manager, и не предусмотрено никаких способов настройки RDMA для кластеров vSAN. Любые попытки настроить RDMA через vCenter в рамках VCF 5.2 также не поддерживаются.

Дополнительную информацию о настройке RDMA для vSAN можно найти в базе знаний KB 382163: Configuring RDMA for vSAN.

Прирост производительности при использовании vSAN поверх RDMA

При сравнении двух кластеров с одинаковым аппаратным обеспечением, vSAN с RDMA может показывать лучшую производительность по сравнению с vSAN, использующим TCP поверх Ethernet. В публикации Intel «Make the Move to 100GbE with RDMA on VMware vSAN with 4th Gen Intel Xeon Scalable Processors» были зафиксированы значительные улучшения производительности в зависимости от условий среды.

Рекомендация: используйте RDTBench для тестирования соединений RDMA и TCP между хостами. Это также отличный инструмент для проверки конфигурации перед развёртыванием производительного кластера в продакшене.

Fibre Channel — действительно ли это «золотой стандарт»?

Fibre Channel заслуженно считается надёжным решением в глазах администраторов хранилищ. Протокол Fibre Channel изначально разрабатывался с одной целью — передача трафика хранения данных. Он использует «тонкий стек» (thin stack), специально созданный для обеспечения стабильной и низколатентной передачи данных. Детеминированная сеть на базе Fibre Channel работает как единый механизм, где все компоненты заранее определены и согласованы.

Однако Fibre Channel и другие протоколы, рассчитанные на сети без потерь, тоже имеют свою цену — как в прямом, так и в переносном смысле. Это дорогая технология, и её внедрение часто «съедает» большую часть бюджета, уменьшая возможности инвестирования в другие сетевые направления. Кроме того, инфраструктуры на Fibre Channel менее гибкие по сравнению с Ethernet, особенно при необходимости поддержки разнообразных топологий.

Хотя Fibre Channel изначально ориентирован на физическую передачу данных без потерь, сбои в сети могут привести к непредвиденным последствиям. В спецификации 32GFC был добавлен механизм FEC (Forward Error Correction) для борьбы с кратковременными сбоями, но по мере роста масштаба фабрики растёт и её сложность, что делает реализацию сети без потерь всё более трудной задачей.

Преимущество Fibre Channel — не в абсолютной скорости, а в предсказуемости передачи данных от точки к точке. Как видно из сравнения, даже с учётом примерно 10% накладных расходов при передаче трафика vSAN через TCP поверх Ethernet, стандартный Ethernet легко может соответствовать или даже превосходить Fibre Channel по пропускной способности.

Обратите внимание, что такие обозначения, как «32GFC» и Ethernet 25 GbE, являются коммерческими названиями, а не точным отражением фактической пропускной способности. Каждый стандарт использует завышенную скорость передачи на уровне символов (baud rate), чтобы компенсировать накладные расходы протокола. В случае с Ethernet фактическая пропускная способность зависит от типа передаваемого трафика. Стандарт 40 GbE не упоминается, так как с 2017 года он считается в значительной степени устаревшим.

Тем временем Ethernet переживает новый виток развития благодаря инфраструктурам, ориентированным на AI, которым требуется высокая производительность без уязвимости традиционных «безубыточных» сетей. Ethernet изначально проектировался с учётом практических реалий дата-центров, где неизбежны изменения в условиях эксплуатации и отказы оборудования.

Благодаря доступным ценам на оборудование 100 GbE и появлению 400 GbE (а также приближению 800 GbE) Ethernet становится чрезвычайно привлекательным решением. Даже традиционные поставщики систем хранения данных в последнее время отмечают, что всё больше клиентов, ранее серьёзно инвестировавших в Fibre Channel, теперь рассматривают Ethernet как основу своей следующей сетевой архитектуры хранения. Объявление Broadcom о выпуске чипа Tomahawk 6, обеспечивающего 102,4 Тбит/с внутри одного кристалла, — яркий индикатор того, что будущее высокопроизводительных сетей связано с Ethernet.

С vSAN ESA большинство издержек TCP поверх Ethernet можно компенсировать за счёт грамотной архитектуры — без переподписки и с использованием сетевого оборудования, поддерживающего высокую пропускную способность. Это подтверждается в статье «vSAN ESA превосходит по производительности топовое хранилище у крупной финансовой компании», где vSAN ESA с TCP по Ethernet с лёгкостью обошёл по скорости систему хранения, использующую Fibre Channel.

Насколько хорош TCP поверх Ethernet?

Если у вас качественно спроектированная сеть с высокой пропускной способностью и без переподписки, то vSAN на TCP поверх Ethernet будет достаточно хорош для большинства сценариев и является наилучшей отправной точкой для развёртывания новых кластеров vSAN. Эта рекомендация особенно актуальна для клиентов, использующих vSAN в составе VMware Cloud Foundation 5.2, где на данный момент не поддерживается RDMA.

Хотя RDMA может обеспечить более высокую производительность, его требования и ограничения могут не подойти для вашей среды. Тем не менее, можно добиться от vSAN такой производительности и стабильности, которая будет приближена к детерминированной модели Fibre Channel. Для этого нужно:

• Грамотно спроектированная сеть. Хорошая архитектура Ethernet-сети обеспечит высокую пропускную способность и низкие задержки. Использование топологии spine-leaf без блокировки (non-blocking), которая обеспечивает линейную скорость передачи от хоста к хосту без переподписки, снижает потери пакетов и задержки. Также важно оптимально размещать хосты vSAN внутри кластера — это повышает сетевую эффективность и производительность.

• Повышенная пропускная способность. Устаревшие коммутаторы должны быть выведены из эксплуатации — им больше нет места в современных ЦОДах. Использование сетевых адаптеров и коммутаторов с высокой пропускной способностью позволяет рабочим нагрузкам свободно передавать команды на чтение/запись и данные без узких мест. Ключ к стабильной передаче данных по Ethernet — исключить ситуации, при которых кадры или пакеты TCP нуждаются в повторной отправке из-за нехватки ресурсов или ненадёжных каналов.

• Настройка NIC и коммутаторов. Сетевые адаптеры и коммутаторы часто имеют настройки по умолчанию, которые не оптимизированы для высокой производительности. Это может быть подходящим шагом, если вы хотите улучшить производительность без использования RDMA, и уже реализовали два предыдущих пункта. В документе «Рекомендации по производительности для VMware vSphere 8.0 U1» приведены примеры таких возможных настроек.

Дополнительную информацию по проектированию сетей для vSAN можно найти в vSAN Network Design Guide. Для сред на базе VMware Cloud Foundation см. «Network Design for vSAN for VMware Cloud Foundation».

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

Описанные здесь концепции основаны на предыдущих публикациях:

• «vSAN Networking – Сетевые топологии»
• «vSAN Networking – Переподписка сети (Oversubscription)»
• «vSAN Networking – Оптимальное размещение хостов в стойках»

Назначение объединения (Teaming)

Объединение сетевых портов NIC — это конфигурация vSphere, при которой используется более одного сетевого порта для выполнения одной или нескольких задач, таких как трафик ВМ или трафик VMkernel (например, vMotion или vSAN). Teaming позволяет достичь одной или обеих следующих целей:

• Резервирование: обеспечение отказоустойчивости в случае сбоя сетевого порта на хосте или коммутатора, подключенного к этому порту.

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

В этой статье мы сосредоточимся на объединении ради повышения производительности.

Распространённые варианты объединения

Выбор варианта teaming для vSAN зависит от среды и предпочтений, но есть важные компромиссы, особенно актуальные для vSAN. Начиная с vSAN 8 U3, платформа поддерживает один порт VMkernel на хост, помеченный для трафика vSAN. Вот три наиболее распространённые подхода при использовании одного порта VMkernel:

1. Один порт VMkernel для vSAN с конфигурацией Active/Standby

• Используются два и более аплинков (uplinks), один из которых активен, а остальные — в режиме ожидания.
• Это наиболее распространённая и рекомендуемая конфигурация для всех кластеров vSAN.
• Простая, надёжная, идеально подходит для трафика VMkernel (например, vSAN), так как обеспечивает предсказуемый маршрут, что особенно важно в топологиях spine-leaf (Clos).
• Такой подход обеспечивает надежную и стабильную передачу трафика, но не предоставляет агрегации полосы пропускания — трафик проходит только по одному активному интерфейсу.
• Обычно Standby-интерфейс используется для другого типа трафика, например, vMotion, для эффективной загрузки каналов.

2. Один порт VMkernel для vSAN с двумя активными аплинками (uplinks) и балансировкой Load Based Teaming (LBT)

• Используются два и более аплинков в режиме «Route based on physical NIC load».
• Это можно рассматривать как агрегацию на уровне гипервизора.
• Изначально предназначен для VM-портов, а не для трафика VMkernel.
• Преимущества для трафика хранилища невелики, могут вызывать проблемы из-за отсутствия предсказуемости маршрута.
• Несмотря на то, что это конфигурация по умолчанию в VCF, она не рекомендуется для портов VMkernel, помеченных как vSAN.
• В VCF можно вручную изменить эту конфигурацию на Active/Standby без проблем.

3. Один порт VMkernel для vSAN с использованием Link Aggregation (LACP)

• Использует два и более аплинков с расширенным хешированием для балансировки сетевых сессий.
• Может немного повысить пропускную способность, но требует дополнительной настройки на коммутаторах и хосте.
• Эффективность зависит от топологии и может увеличить нагрузку на spine-коммутаторы.
• Используется реже и ограниченно поддерживается в среде VCF.

Версия VCF по умолчанию может использовать Active/Active с LBT для трафика vSAN. Это универсальный режим, поддерживающий различные типы трафика, но неоптимален для VMkernel, особенно для vSAN.

Рекомендуемая конфигурация:

Active/Standby с маршрутизацией на основе виртуального порта (Route based on originating virtual port ID). Это поддерживается в VCF и может быть выбрано при использовании настраиваемого развертывания коммутатора VDS. Подробнее см. в «VMware Cloud Foundation Design Guide».

Можно ли использовать несколько портов VMkernel на хосте для трафика vSAN?

Теоретически да, но только в редком случае, когда пара коммутаторов полностью изолирована (подобно Fibre Channel fabric). Это не рекомендуемый и редко используемый вариант, даже в vSAN 8 U3.

Влияние объединения на spine-leaf-сети

Выбор конфигурации teaming на хостах vSAN может показаться несущественным, но на деле сильно влияет на производительность сети и vSAN. В топологии spine-leaf (Clos), как правило, нет прямой связи между leaf-коммутаторами. При использовании Active/Active LBT половина трафика может пойти через spine, вместо того чтобы оставаться на уровне leaf, что увеличивает задержки и снижает стабильность.

Аналогичная проблема у LACP — он предполагает наличие прямой связи между ToR-коммутаторами. Если её нет, трафик может либо пойти через spine, либо LACP-связь может полностью нарушиться.

На практике в некоторых конфигурациях spine-leaf коммутаторы уровня ToR (Top-of-Rack) соединены между собой через межкоммутаторное соединение, такое как MLAG (Multi-Chassis Link Aggregation) или VLTi (Virtual Link Trunking interconnect). Однако не стоит считать это обязательным или даже желательным в архитектуре spine-leaf, так как такие соединения часто требуют механизмов блокировки, например Spanning Tree (STP).

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

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

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

Агрегация каналов, основанная на алгоритмическом балансировании нагрузки (например, LACP), не дает линейного увеличения пропускной способности.
То есть 1+1 не равно 2. Такие механизмы лучше работают при большом количестве параллельных потоков данных, но малоэффективны для отдельных (дискретных) рабочих нагрузок.

Существует мнение, что старые 10GbE-коммутаторы более экономичны. На деле — это миф.

Более объективный показатель — это пропускная способность коммутатора, измеряемая в Гбит/с или Тбит/с. Хотя сам по себе 10Gb-коммутатор может стоить дешевле, более быстрые модели обеспечивают в 2–10 раз больше пропускной способности, что делает стоимость за 1 Гбит/с ниже. Кроме того, установка более быстрых сетевых адаптеров (NIC) на серверы обычно увеличивает стоимость менее чем на 1%, при этом может дать 2,5–10-кратный прирост производительности.

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

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

Именно по этим причинам VMware рекомендует выбирать более высокие нативные скорости соединения (25Gb или 100Gb), а не полагаться на агрегацию каналов — особенно в случае с 10GbE. Напомним, что когда 10GbE появился 23 года назад, серверные процессоры имели всего одно ядро, а объём оперативной памяти составлял в 20–40 раз меньше, чем сегодня. С учётом того, что 25GbE доступен уже почти десятилетие, актуальность 10GbE для дата-центров практически исчерпана.

Дополнительную информацию о сетевой архитектуре для vSAN можно найти в vSAN Network Design Guide. Для среды VMware Cloud Foundation (VCF) см. документ “Network Design for vSAN for VMware Cloud Foundation”.

Количество uplink-портов на хост

Объединение для повышения производительности и отказоустойчивости обычно предполагает использование нескольких физических сетевых карт (NIC), каждая из которых может иметь 2–4 порта. Сколько всего портов следует иметь на хостах vSAN? Это зависит от следующих факторов:

• Степень рабочих нагрузок: среда с относительно пассивными виртуальными машинами предъявляет гораздо меньшие требования, чем среда с тяжёлыми и ресурсоёмкими приложениями.
• Нативная пропускная способность uplink-соединений: более высокая скорость снижает вероятность конкуренции между сервисами (vMotion, порты ВМ и т.д.), работающими через одни и те же аплинки.
• Используемые сервисы хранения данных: выделение пары портов для хранения (например, vSAN) почти всегда даёт наилучшие результаты — это давно устоявшаяся практика, независимо от хранилища.
• Требования безопасности и изоляции: в некоторых средах может потребоваться, чтобы аплинки, используемые для хранения или других задач, были изолированы от остального трафика.
• Количество портов на ToR-коммутаторах: количество аплинков может быть ограничено самими коммутаторами ToR. Пример: пара ToR-коммутаторов с 2?32 портами даст 64 порта на стойку. Если в стойке размещено максимум 16 хостов по 2U, каждый хост может получить максимум 4 uplink-порта. А если коммутаторы имеют по 48 портов, то на 16 хостов можно выделить по 6 uplink-портов на каждый хост. Меньшее количество хостов в стойке также позволяет увеличить количество портов на один хост.

Рекомендация:

Даже если вы не используете все аплинки на хосте, рекомендуется собирать vSAN ReadyNode с двумя NIC, каждая из которых имеет по 4 uplink-порта. Это позволит без проблем выделить отдельную команду (team) портов только под vSAN, что настоятельно рекомендуется. Такой подход обеспечит гораздо большую гибкость как сейчас, так и в будущем, по сравнению с конфигурацией 2 NIC по 2 порта.

Итог

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

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

Основные улучшения охватывают следующие направления:

• Межсетевой экран vDefend представляет новый высокопроизводительный режим Turbo (SCRX), который повышает производительность распределённой IDS/IPS-системы и механизма обнаружения приложений уровня L7 для распределённого межсетевого экрана. Новый механизм инспекции использует детерминированное распределение ресурсов и расширенные конвейеры обработки пакетов в гипервизоре ESXi, обеспечивая прирост производительности при значительно меньшем потреблении ресурсов памяти и процессора.
• Enhanced Data Path (EDP) получил ряд улучшений, включая добавление скрипта, снижающего необходимость ручного вмешательства при включении EDP в кластере, а также улучшения стабильности, совместимости и снижение влияния на операции жизненного цикла.
• В этом выпуске VMware NSX включает улучшения платформы Edge, в том числе новую опцию повторного развертывания и улучшенную документацию по API мониторинга Edge.
• Скрипт Certificate Analyzer Resolver (CARR) теперь поддерживает проверку сертификатов Compute Manager (vCenter). Он выполняет проверку целостности и восстановление самоподписных сертификатов NSX, а также может заменять сертификаты, срок действия которых истёк или скоро истечёт.
• Среди новых улучшений безопасности платформы — предопределённая роль Cloud Admin Partner, увеличение числа поддерживаемых групп LDAP и Active Directory, а также поддержка стандарта FIPS 140-3.

Сетевые возможности

1. Сеть канального уровня (Layer 2 Networking)

Появился скрипт автоматизации включения режима коммутатора EDP для VCF 5.2.x (NSX 4.2.2). В состав NSX Manager добавлен скрипт enable_uens, предназначенный для сокращения ручных действий при включении режима Enhanced Data Path Standard на кластере. Скрипт последовательно выполняет следующие шаги на хостах:

• Переводит хост в режим обслуживания
• Обновляет режим коммутатора на EDP
• Выводит хост из режима обслуживания
• Синхронизирует изменения с Transport Node Profile кластера

Скрипт находится по пути:

/opt/vmware/migration-coordinator-tomcat/bin/uens-adoption/config

Он выполняется из той же директории и применяется к одному кластеру за раз, требуя входных данных из JSON-файла. Подробные инструкции приведены в файле readme скрипта.

Скрипт особенно полезен для релизов NSX 4.x, так как смена режима передачи данных на EDP Standard через настройки Transport Node Profile вызывает немедленные изменения на хостах ESXi, что может привести к сетевому простою на несколько секунд на каждом хосте. Метод "Enabling EDP Standard in Active Environments" снижает простой, но требует ручного вмешательства на каждом хосте, что при масштабных развертываниях становится крайне трудоёмким из-за шагов с режимом обслуживания.

NSX 4.2.2 рекомендуется как основная версия для использования Enhanced Data Path во всех развертываниях VMware Cloud Foundation и типах рабочих доменов, включая кластеры NSX Edge и общие вычислительные кластеры (VI Workload Domains).
EDP рекомендован для достижения максимальной производительности обработки сетевого трафика и минимизации затрат ресурсов на сетевую обработку. В этом релизе реализованы улучшения стабильности и совместимости, благодаря чему он рекомендован в качестве версии с долгосрочной поддержкой (LTS) для NSX 4.2.

Основные улучшения надёжности в NSX 4.2.2:

• Повышена производительность EDP при масштабных развертываниях.
• Улучшена работа EDP в средах на базе vSAN.
• Повышена производительность EDP при использовании распределённого межсетевого экрана.
• Расширена совместимость с сетевыми адаптерами через механизм driver shimming.
• Совместимость EDP с контейнерными платформами (NCP, Antrea).
• Повышена доступность (uptime) канала данных EDP Standard при операциях жизненного цикла — время переключения сокращено с десятков секунд до менее чем 3 секунд.

3. Платформа Edge

• Улучшение UI — кнопка повторного развертывания Edge

В пользовательском интерфейсе добавлена кнопка Redeploy Edge, позволяющая легко и быстро повторно развернуть узел Edge. Эта операция запускает соответствующий API, как указано в документации: NSX Edge VM Redeploy API.

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

Обновлённая документация по API мониторинга NSX Edge теперь предоставляет более понятные и подробные инструкции. В ней содержатся:

• Подробные объяснения всех соответствующих API-вызовов с примерами запросов и ответов.
• Полные описания возвращаемых мониторинговых данных, включая поэлементную расшифровку каждого поля.
• Глубокое разъяснение всех доступных метрик: что они обозначают, как рассчитываются и как их интерпретировать в реальных сценариях.

Безопасность

• Распределённый межсетевой экран (Distributed Firewall) использует новый высокопроизводительный режим Turbo (SCRX) для фильтрации приложений уровня L7.
• NSX Manager теперь поддерживает большее количество сервисов межсетевого экрана для экземпляров класса Extra Large. Подробности см. в разделе Configuration Maximums.
• Группировка в межсетевом экране поддерживает большее число активных участников как для конфигураций Large, так и Extra Large. Подробнее — в Configuration Maximums.

• Распределённая система IDS/IPS демонстрирует значительный прирост производительности благодаря новому высокопроизводительному движку Turbo (SCRX). При использовании нового движка возможно достичь скорости анализа трафика до 9 Гбит/с в зависимости от профиля трафика на хосте ESXi.
• Показатели производительности и другие операционные метрики Distributed IDS/IPS доступны в реальном времени через Security Services Platform (SSP).

Внимание: новый движок SCRX предъявляет строгие требования к совместимости с версией ESXi, а также имеет особые условия для установки/обновления. См. раздел Getting Started и выполните Turbo Mode Compatibility Pre-Check Script для проверки среды. Дополнительную информацию можно найти в базе знаний (KB) — статья 396277.

• Поддержка Security Services Platform (SSP): все функции Security Intelligence, доступные ранее на NSX Application Platform (NAPP), теперь доступны на SSP. NSX Application Platform считается устаревшей и будет выведена из эксплуатации к маю 2026 года.
  Подробнее об SSP — см. Security Services Platform 5.0 Release Notes.
  Подробнее о переходе с NAPP на SSP — см. Switchover Guide: NSX Application Platform to Security Services Platform.

Безопасность платформы

• Настоятельно рекомендуется запускать скрипт CARR перед обновлением NSX Manager. Цель — убедиться, что срок действия сертификатов Transport Node (TN) не истекает в течение 825 дней. Если срок действия сертификата TN меньше этого значения, скрипт можно повторно запустить для его замены. См. статью Broadcom KB 369034.

• Добавлена новая предопределённая роль Cloud Partner Admin — специально для облачных партнёров, которым необходим доступ к функциям сетей и безопасности, но при этом нужно исключить доступ к просмотру лицензий NSX.

• Увеличено максимальное число поддерживаемых групп LDAP и Active Directory — с 20 до 500.

• Поддержка стандарта FIPS 140-3: NSX 4.2.2 теперь использует криптографические модули, соответствующие требованиям FIPS 140-3 (Federal Information Processing Standards). NSX работает в режиме соответствия FIPS по умолчанию во всех развертываниях. Подтверждение соответствия стандарту FIPS 140-3 гарантирует, что NSX использует актуальные криптомодули для надёжной защиты рабочих нагрузок. Дополнительная информация о модулях доступна по ссылке в оригинальной документации.

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

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

Значимость ИТ-сертификатов на современном рынке

В современной реальности облачных технологий и виртуализации, чтобы выделиться, нужно не только иметь опыт, но и обладать признанными отраслевыми сертификатами. Сертификации VMware, такие как VMware Certified Professional – VMware vSphere Foundation Administrator (VCP-VVF Admin), VMware Certified Professional – VMware Cloud Foundation Administrator (VCP-VCF Admin) и VMware Certified Professional – VMware Cloud Foundation Architect (VCP-VCF Architect), являются весомым подтверждением вашей квалификации в области частных облачных решений VMware.

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

Как начать

Шаг 1: Сдайте один из следующих сертификационных экзаменов VCP, чтобы получить доступ к VMware vSphere Standard Edition на 32 ядра сроком на 1 год:

• VCP-VVF (Administrator)
• VCP-VCF (Administrator / Architect)

Шаг 2: Перейдите на портал лицензирования Broadcom Certification License Portal и войдите в систему, используя адрес электронной почты, указанный вами при сдаче экзамена.

Шаг 3: После входа вы увидите список доступных лицензий на продукты. Изначально будет отображаться статус, что лицензии пока не запрашивались. Чтобы запросить лицензию, просто нажмите на значок «Not Requested» («Не запрошено») в верхнем правом углу каждого продукта.

После нажатия значок изменится на «Pending» («Ожидает обработки»), и ваш запрос будет обработан. На ваш email придёт письмо с подтверждением покупки. После получения этого письма подождите 4–6 часов, прежде чем лицензия станет доступна для скачивания.

Шаг 4: Загрузите лицензионные ключи и образы продуктов. Когда переходный период завершится и вы получите письмо с подтверждением заказа, перейдите на портал. В нижнем правом углу каждого продукта расположены две иконки. Здесь вы найдёте свои лицензионные ключи и область для загрузки. Чтобы получить лицензионные ключи и скачать необходимые продукты, выберите соответствующие пункты.

Прокачайте свою виртуальную лабораторию с лицензией VCF

Ищете полнофункциональные лицензии VCF для личного использования, чтобы развить экспертизу в этой технологии и продвинуться в профессии? Присоединяйтесь к сообществу единомышленников и подумайте о вступлении в программу VMUG Advantage. Став участником, вы можете приобрести и поддерживать членство в VMUG Advantage, сдать экзамен VCP-VCF Administrator или Architect, и получить бесплатные лицензии VCF для личного использования сроком до трёх лет.

Преимущества VMUG Advantage включают:

• Доступ к эксклюзивным мероприятиям
• Технические материалы и живые вебинары
• Специальные скидки на обучение и участие в ивентах

Для действующих участников VMUG Advantage

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

Важно: Чтобы учётные записи VMUG Advantage и Broadcom Certification были связаны, проверьте, что в обеих используется одинаковый email. Если нужно изменить email в VMUG, напишите на: advantage@vmug.com.

Для обновления email в системе Broadcom — свяжитесь с поддержкой по вашему региону:

• AMER: americas.education@broadcom.com
• EMEA: emea.education@broadcom.com
• APJ: apj.education@broadcom.com

В индустрии виртуализации в последние годы наметилась заметная тенденция: крупные вендоры сворачивают бесплатные версии своих гипервизоров. Microsoft прекратила выпуск отдельного бесплатного Hyper-V Server, VMware (после поглощения Broadcom) закрыла свободный доступ к ESXi Free (vSphere Hypervisor), а Red Hat объявила о завершении поддержки платформы Red Hat Virtualization (RHV) к 2026 году. Ниже приводится детальный обзор этих новостей...

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

Блогер Эрик Слуф опубликовал интересные 30-секундные видео в формате Youtube Shorts, посвященные платформе VMware Cloud Foundation.

Ролики очень удобно смотреть с телефона:

• Workload Domain Types - Management
• Workload Domain Types - VI Workload
• Single Instance - Single Availability Zone
• Single Instance - Multiple Availability Zones
• Multiple Instances - Single Availability Zone per Instance
• Multiple Instances - Multiple Availability Zones per Instance

С выпуском VMware Cloud Foundation (VCF) 5.2 в июле 2024 года VMware представила инструмент VCF Import Tool — новый интерфейс командной строки (CLI), разработанный для упрощения перехода клиентов к частному облаку. Этот инструмент позволяет быстро расширить возможности управления инвентарем SDDC Manager, такие как управление сертификатами, паролями и жизненным циклом, на ваши существующие развертывания vSphere или vSphere с vSAN. Интеграция управления SDDC Manager с вашей текущей инфраструктурой проходит бесшовно, без влияния на работающие нагрузки, сервер vCenter, API vSphere или процессы управления.

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

Загрузка последних обновлений

Это обновление доступно в составе выпуска 5.2.1.1 для VCF 5.2.1. Чтобы загрузить обновление, войдите в портал Broadcom Software и в разделе «My Downloads» перейдите в «VMware Cloud Foundation», раскройте пункт «VMware Cloud Foundation 5.2» и выберите «5.2.1». Последняя версия инструмента VCF Import (5.2.1.1) доступна на вкладке «Drivers & Tools», как показано на изображении ниже.

Новые возможности VMware Cloud Foundation Import Tool

Возможность импорта кластеров vSphere с общими vSphere Distributed Switches (VDS)

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

Поддержка импорта кластеров с включенным LACP

Многие клиенты используют протокол управления агрегацией каналов (Link Aggregation Control Protocol, LACP) на своих физических коммутаторах для объединения каналов. Ранее использование LACP с VCF не поддерживалось. Это обновление добавляет поддержку LACP как для преобразованных, так и для импортированных доменов. Теперь использование LACP больше не является препятствием для переноса инфраструктуры vSphere в Cloud Foundation.

Импорт сред vSphere с использованием смешанных конфигураций vLCM Images и Baselines

При развертывании кластеров vSphere VCF предоставляет возможность выбора между использованием образов vSphere Lifecycle Manager (vLCM) и базовых конфигураций (Baselines). Образы vLCM представляют собой современный подход к обновлению программного обеспечения хостов vSphere, основанный на модели желаемого состояния. Базовые конфигурации следуют традиционному подходу, включающему создание базовых профилей и их привязку к кластерам.

Во время перехода клиентов от традиционного подхода с базовыми конфигурациями к новому подходу с образами vLCM многие используют смешанную конфигурацию, где одни кластеры применяют образы, а другие — базовые профили. Ранее VCF требовал, чтобы все кластеры в инвентаре vCenter использовали один тип vLCM. Последнее обновление устраняет это ограничение, добавляя поддержку смешанных сред, где одни кластеры используют vLCM Images, а другие — vLCM Baselines. Это упрощает переход клиентов на VCF, позволяя импортировать существующую инфраструктуру в частное облако Cloud Foundation без необходимости вносить изменения или модификации.

Ослабление ограничений для vSphere Standard Switches и автономных хостов

Помимо изменений, описанных выше, последнее обновление снимает несколько ограничений, ранее мешавших импортировать некоторые топологии. Это включает:

• Разрешение импорта сред vSphere с использованием стандартных коммутаторов vSphere Standard Switches.
• Поддержку сред vSphere с автономными хостами в инвентаре vCenter.
• Поддержку одноузловых кластеров.

При этом важно отметить, что, несмотря на ослабление ограничений для этих компонентов, каждый экземпляр vCenter должен иметь хотя бы один кластер vSphere, соответствующий минимальным требованиям, изложенным в руководстве по администрированию Cloud Foundation.

Интересный пост, касающийся использования виртуальных хранилищ NFS (в формате Virtual Appliance) на платформе vSphere и их производительности, опубликовал Marco Baaijen в своем блоге. До недавнего времени он использовал центральное хранилище Synology на основе NFSv3 и две локально подключенные PCI флэш-карты. Однако из-за ограничений драйверов он был вынужден использовать ESXi 6.7 на одном физическом хосте (HP DL380 Gen9). Желание перейти на vSphere 8.0 U3 для изучения mac-learning привело тому, что он больше не мог использовать флэш-накопители в качестве локального хранилища для размещения вложенных виртуальных машин. Поэтому Марко решил использовать эти флэш-накопители на отдельном физическом хосте на базе ESXi 6.7 (HP DL380 G7).

Теперь у нас есть хост ESXi 8 и и хост с версией ESXi 6.7, которые поддерживают работу с этими флэш-картами. Кроме того, мы будем использовать 10-гигабитные сетевые карты (NIC) на обоих хостах, подключив порты напрямую. Марко начал искать бесплатное, удобное и функциональное виртуальное NAS-решение. Рассматривал Unraid (не бесплатный), TrueNAS (нестабильный), OpenFiler/XigmaNAS (не тестировался) и в итоге остановился на OpenMediaVault (с некоторыми плагинами).

И вот тут начинается самое интересное. Как максимально эффективно использовать доступное физическое и виртуальное оборудование? По его мнению, чтение и запись должны происходить одновременно на всех дисках, а трафик — распределяться по всем доступным каналам. Он решил использовать несколько паравиртуальных SCSI-контроллеров и настроить прямой доступ (pass-thru) к портам 10-гигабитных NIC. Всё доступное пространство флэш-накопителей представляется виртуальной машине как жесткий диск и назначается по круговому принципу на доступные SCSI-контроллеры.

В OpenMediaVault мы используем плагин Multiple-device для создания страйпа (striped volume) на всех доступных дисках.

На основе этого мы можем создать файловую систему и общую папку, которые в конечном итоге будут представлены как экспорт NFS (v3/v4.1). После тестирования стало очевидно, что XFS лучше всего подходит для виртуальных нагрузок. Для NFS Марко решил использовать опции async и no_subtree_check, чтобы немного увеличить скорость работы.

Теперь переходим к сетевой части, где автор стремился использовать оба 10-гигабитных порта сетевых карт (X-соединённых между физическими хостами). Для этого он настроил следующее в OpenMediaVault:

С этими настройками серверная часть NFS уже работает. Что касается клиентской стороны, Марко хотел использовать несколько сетевых карт (NIC) и порты vmkernel, желательно на выделенных сетевых стэках (Netstacks). Однако, начиная с ESXi 8.0, VMware решила отказаться от возможности направлять трафик NFS через выделенные сетевые стэки. Ранее для этого необходимо было создать новые стэки и настроить SunRPC для их использования. В ESXi 8.0+ команды SunRPC больше не работают, так как новая реализация проверяет использование только Default Netstack.

Таким образом, остаётся использовать возможности NFS 4.1 для работы с несколькими соединениями (parallel NFS) и выделения трафика для портов vmkernel. Но сначала давайте посмотрим на конфигурацию виртуального коммутатора на стороне NFS-клиента. Как показано на рисунке ниже, мы создали два раздельных пути, каждый из которых использует выделенный vmkernel-порт и собственный физический uplink-NIC.

Первое, что нужно проверить, — это подключение между адресами клиента и сервера. Существуют три способа сделать это: от простого до более детального.

[root@mgmt01:~] esxcli network ip interface list
---
vmk1
   Name: vmk1
   MAC Address: 00:50:56:68:4c:f3
   Enabled: true
   Portset: vSwitch1
   Portgroup: vmk1-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 134217815

vmk2
   Name: vmk2
   MAC Address: 00:50:56:6f:d0:15
   Enabled: true
   Portset: vSwitch2
   Portgroup: vmk2-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 167772315

[root@mgmt01:~] esxcli network ip netstack list defaultTcpipStack
   Key: defaultTcpipStack
   Name: defaultTcpipStack
   State: 4660

[root@mgmt01:~] ping 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.219 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.173 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.174 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.173/0.189/0.219 ms

[root@mgmt01:~] ping 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.155 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.187 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.161/0.187 ms

root@mgmt01:~] vmkping -I vmk1 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.981 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.183 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.435/0.981 ms

[root@mgmt01:~] vmkping -I vmk2 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.131 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.187 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.190 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.131/0.169/0.190 ms

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk1 -H 10.10.10.62
   Trace: 
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 139 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 180 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 148 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 10.10.10.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 139 us
         Round-trip Avg: 155 us
         Round-trip Max: 180 us

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk2 -H 172.16.0.62
   Trace: 
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 182 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 136 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 213 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 172.16.0.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 136 us
         Round-trip Avg: 177 us
         Round-trip Max: 213 us

С этими положительными результатами мы теперь можем подключить NFS-ресурс, используя несколько подключений на основе vmk, и убедиться, что всё прошло успешно.

[root@mgmt01:~] esxcli storage nfs41 add --connections=8 --host-vmknic=10.10.10.62:vmk1,172.16.0.62:vmk2 --share=/fio-folder --volume-name=fio

[root@mgmt01:~] esxcli storage nfs41 list
Volume Name  Host(s)                  Share        Vmknics    Accessible  Mounted  Connections  Read-Only  Security   isPE  Hardware Acceleration
-----------  -----------------------  -----------  ---------  ----------  -------  -----------  ---------  --------  -----  ---------------------
fio          10.10.10.62,172.16.0.62  /fio-folder  vmk1,vmk2        true     true            8      false  AUTH_SYS  false  Not Supported

[root@mgmt01:~] esxcli storage nfs41 param get -v all
Volume Name  MaxQueueDepth  MaxReadTransferSize  MaxWriteTransferSize  Vmknics    Connections
-----------  -------------  -------------------  --------------------  ---------  -----------
fio             4294967295               261120                261120  vmk1,vmk2            8

Наконец, мы проверяем, что оба подключения действительно используются, доступ к дискам осуществляется равномерно, а производительность соответствует ожиданиям (в данном тесте использовалась миграция одной виртуальной машины с помощью SvMotion). На стороне NAS-сервера Марко установил net-tools и iptraf-ng для создания приведённых ниже скриншотов с данными в реальном времени. Для анализа производительности флэш-дисков на физическом хосте использовался esxtop.

root@openNAS:~# netstat | grep nfs
tcp        0    128 172.16.0.62:nfs         172.16.0.60:623         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:617         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:616         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:621         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:613         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:620         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:610         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:611         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:615         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:619         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:609         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:614         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:618         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:622         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:624         ESTABLISHED
tcp        0      0 10.10.10.62:nfs         10.10.10.60:612         ESTABLISHED

По итогам тестирования NFS на ESXi 8 Марко делает следующие выводы:

• NFSv4.1 превосходит NFSv3 по производительности в 2 раза.
• XFS превосходит EXT4 по производительности в 3 раза (ZFS также был протестирован на TrueNAS и показал отличные результаты при последовательных операциях ввода-вывода).
• Клиент NFSv4.1 в ESXi 8.0+ не может быть привязан к выделенному/отдельному сетевому стэку (Netstack).
• Использование нескольких подключений NFSv4.1 на основе выделенных портов vmkernel работает очень эффективно.
• Виртуальные NAS-устройства демонстрируют хорошую производительность, но не все из них стабильны (проблемы с потерей NFS-томов, сообщения об ухудшении производительности NFS, увеличении задержек ввода-вывода).

В ноябре этого года компания Broadcom объявила о продолжении эволюции портфолио в сфере серверной виртуализации, включающего в себя платформы VMware Cloud Foundation (VCF) и VMware vSphere Foundation (VVF).

VMware Cloud Foundation остаётся флагманским решением, предоставляя комплексную интегрированную платформу частного облака, которая обеспечивает масштаб и гибкость публичного облака вместе с локальной безопасностью, устойчивостью, производительностью и низкой общей стоимостью владения — как для локальной инфраструктуры, так и для периферии (edge locations), а также публичных и партнерских облаков провайдеров.

Чтобы предложить клиентам более мощное и ценное решение корпоративного класса для гиперконвергентной инфраструктуры (HCI), которое позволяет запускать виртуальные машины и контейнеры с оптимизацией ИТ-инфраструктуры, VMware увеличит объём предоставляемого дискового пространства vSAN в составе VMware vSphere Foundation в 2.5 раза — до 250 GiB на ядро (аналог гигабайт). А для завершения портфеля, для клиентов, сосредоточенных на виртуализации вычислений, теперь будет два издания платформы: VMware vSphere Enterprise Plus (раньше это издание отменили, а теперь возвращают снова) и VMware vSphere Standard. Весь портфель VCF доступен конечным пользователям через дистрибьюторскую сеть или напрямую от Broadcom.

Спасибо Сергею за новость.