Несмотря на своё название, VCF Installer способен разворачивать как VMware Cloud Foundation (VCF), так и VMware vSphere Foundation (VVF). Многие ошибочно полагают, что установщик жёстко привязан к конкретному продукту в зависимости от имеющихся лицензий: VVF — для VVF-лицензий, VCF — для VCF-лицензий. На самом деле это не так.

VCF Installer не проверяет и не учитывает имеющиеся лицензии в момент развёртывания. Как VVF-, так и VCF-установки по умолчанию запускаются в режиме 90-дневного пробного периода. Лицензирование компонентов выполняется пользователем уже после завершения развёртывания — через VCF Operations, который обращается к Broadcom Business Service Console (BSC) для получения и применения соответствующих прав.

Гибкое развёртывание под разные сценарии

В зависимости от требований может возникнуть необходимость развернуть полный VCF-стек в основном дата-центре, а в региональном или граничном узле — только подмножество инфраструктурных компонентов. Один из типичных сценариев — развёртывание только компонентов VVF (VCF Operations, vCenter и ESX) с последующим лицензированием через VCF-права. Это полностью поддерживаемый вариант использования.

Конечно, отдельные компоненты можно развернуть вручную — через OVA VCF Operations и ISO-установщик vCenter. Однако VCF Installer предоставляет единый сквозной рабочий процесс: он разворачивает все компоненты VVF и автоматически их связывает. Весь процесс можно полностью автоматизировать, передав готовую JSON-конфигурацию.

Лицензирование через Broadcom BSC

После завершения развёртывания VCF Operations регистрируется в Broadcom Business Service Console (BSC), откуда получает и применяет соответствующие права — будь то VVF или VCF. Таким образом, выбор продукта при установке и применение лицензий — это два независимых этапа, которые не следует путать.

Отложенное развёртывание VCF Operations и VCF Automation

VCF Installer предоставляет дополнительную возможность — отложить развёртывание VCF Operations и/или VCF Automation. Это полезно, если требуется подключить их к альтернативным сетям (DVPGs или NSX-сегментам), отличным от Management Network, выбранной при начальной установке.

Часть организаций предпочитает отложить внедрение VCF Automation до того момента, когда они будут готовы перейти к современным методам доставки рабочих нагрузок через портал самообслуживания. В таком случае можно развернуть VCF-стек без VCF Automation, а позже добавить его как операцию Day-N через VCF Operations Fleet Manager.

Ключевой вывод

VCF Installer — крайне гибкий инструмент. Главное — не смешивать два разных понятия: тип развёртывания (VCF или VVF) и имеющиеся лицензионные права. Это две независимые вещи.

• VCF Installer разворачивает как VCF, так и VVF вне зависимости от типа лицензий
• Оба варианта запускаются с 90-дневным пробным периодом — до применения лицензий
• Лицензии применяются через VCF Operations после развёртывания, через подключение к Broadcom BSC
• Развёртывание VVF-компонентов с VCF-правами является полностью поддерживаемым сценарием
• VCF Automation можно отложить и добавить позже как операцию Day-N
• Полная автоматизация возможна через JSON-конфигурацию

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

Многоуровневое кэширование памяти на NVMe

Первую сессию открыл Дейв Морера (Dave Morera), старший технический архитектор по маркетингу, с докладом о технологии Advanced NVMe Memory Tiering в VCF. Память является самым дорогостоящим и ограничивающим узким местом современных датацентров: она сдерживает плотность виртуальных машин и увеличивает совокупную стоимость владения.

Технология Advanced NVMe Memory Tiering решает эту задачу за счёт интеллектуальной интеграции на уровне гипервизора: она автоматически распределяет данные между высокопроизводительным и более экономичным уровнями памяти. Результаты говорят сами за себя: организации могут достичь снижения TCO более чем на 40%, одновременно повышая плотность виртуальных машин и эффективность потребления ресурсов. Ключевое преимущество VCF — бесшовная интеграция непосредственно на уровне гипервизора. Вместо того чтобы рассматривать память как фиксированное аппаратное ограничение, VCF превращает её в динамический стратегический ресурс, адаптирующийся к требованиям рабочих нагрузок в реальном времени.

База данных как услуга без узких мест

Эрик Грей (Eric Gray), главный архитектор по техническому маркетингу, показал, как VMware Data Services Manager (DSM) устраняет давнюю проблему — узкие места при выделении баз данных. Базы данных с открытым исходным кодом — PostgreSQL и MySQL — пользуются высоким спросом, однако традиционный процесс их предоставления порождает очереди заявок, пробелы в управлении и риски.

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

Сетевые сервисы с гибкостью облака

В завершающей сессии выступил Дмитрий Десмидт (Dimitri Desmidt), старший технический менеджер продукта NSX, с докладом о сетевых возможностях VCF. Цель доклада состояла в том, чтобы развеять распространённое заблуждение: будто возможности физических фабрик VXLAN устраняют необходимость в программно-определяемых сетях. Доклад «Почему VCF Networking (NSX) необходим — даже в мире VXLAN» обосновал, почему современные частные облака требуют большего, чем просто базовое оверлейное соединение.

VCF Networking (NSX) отделяет сеть от физической фабрики, обеспечивая автоматизированные сетевые сервисы, управляемые политиками, которые нативно интегрируются с vCenter и VCF Automation. Эта интеграция даёт операционную простоту, недостижимую только за счёт физических фабрик. Особого внимания заслуживают виртуальные частные облака (VPC): они позволяют разработчикам мгновенно выделять защищённые многопользовательские среды без глубоких знаний в области сетевых технологий. VCF Networking — это не просто оверлей, а базовый уровень, открывающий гибкость, операционную простоту и подлинные облачные операционные модели внутри современного датацентра.

Ценностное предложение VCF

Три сессии на Cloud Field Day 25 продемонстрировали единую тему: VMware Cloud Foundation предоставляет возможности, которые решают реальные корпоративные задачи с измеримыми бизнес-результатами. Снижение TCO на 40% и более за счёт интеллектуального многоуровневого кэширования памяти, устранение узких мест при выделении баз данных, обеспечение облачной гибкости в частной инфраструктуре — всё это делает VCF фундаментом современных корпоративных ИТ. Полные записи докладов доступны в плейлисте Cloud Field Day 25 на YouTube и предлагают техническую глубину по каждой из обсуждённых возможностей.

В какой-то момент требования к ресурсам для Witness VM в vSAN ESA исчезли из официальной документации. Между тем этот вопрос остаётся актуальным: сколько памяти выделяется виртуальной машине и сколько у неё vCPU? Ответ зависит от выбранного профиля — Witness VM доступна в трёх вариантах: M, L и XL.

Выбор профиля определяется количеством виртуальных машин, которые планируется развернуть. При этом рекомендуется закладывать запас на рост. Когда Witness VM разворачивается через мастер развёртывания, нужные цифры там не указаны — однако их можно узнать, заглянув в OVF-дескриптор.

Из OVF-файла vSAN ESA Witness получены следующие данные о ресурсах:

• vSAN ESA Witness XL — 8 vCPU, 64 ГБ памяти
• vSAN ESA Witness L — 4 vCPU, 32 ГБ памяти
• vSAN ESA Witness M — 4 vCPU, 16 ГБ памяти

Для тех, кто использует vSAN OSA, требования к ресурсам следующие:

• vSAN OSA Witness XL — 6 vCPU, 32 ГБ памяти
• vSAN OSA Witness L — 2 vCPU, 32 ГБ памяти
• vSAN OSA Witness Normal — 2 vCPU, 16 ГБ памяти
• vSAN OSA Witness Tiny — 2 vCPU, 8 ГБ памяти

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

Источник.

В сфере виртуализации и облачной инфраструктуры системные инженеры регулярно сталкиваются с задачами расчётов, проверки параметров конфигурации и подготовки инфраструктуры к развертыванию. Именно для таких задач создан сайт https://tools.virtualbytes.cloud/ — онлайн-площадка с полезными утилитами для специалистов по VMware-инфраструктуре и облачным платформам.

Что представляет собой сервис

Tools.VirtualBytes.Cloud — это коллекция веб-инструментов, предназначенных для работы с инфраструктурными компонентами VMware-экосистемы и сопутствующих технологий. Сервис позволяет использовать различные утилиты прямо в браузере без установки дополнительного программного обеспечения на локальную машину.

Основная идея платформы — предоставить инженерам быстрый доступ к вспомогательным инструментам, которые упрощают администрирование и проектирование виртуальной инфраструктуры.

Какие инструменты доступны онлайн

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

• Работа с платформой VMware Cloud Foundation (VCF)
• Инструменты для VMware NSX и сетевой виртуализации
• Вспомогательные утилиты для vSAN
• Сетевые и инфраструктурные калькуляторы
• Инструменты для анализа и подготовки конфигураций

Благодаря веб-формату инструменты можно использовать с любого устройства — достаточно открыть сайт в браузере.

Бесплатные онлайн-утилиты

• VCF Pre-Deployment Checklist
  Интерактивный чеклист, охватывающий все требования перед развертыванием VCF — DNS, NTP, сетевую инфраструктуру, оборудование, лицензии, сертификаты, порты файрвола и многое другое. Позволяет добавлять заметки и экспортировать результат в PDF.
• VCF Upgrade Path Advisor
  Визуальный планировщик путей обновления для VMware Cloud Foundation версий 4.0–9.0. Использует поиск оптимального пути (BFS) между поддерживаемыми этапами обновления и предупреждает о промежуточных версиях.
• VCF Host Sizing Calculator
  Калькулятор минимального количества хостов для доменов нагрузки VCF с учетом отказоустойчивости N+1 и N+2. Учитывает накладные расходы vSAN, резервации HA и нагрузку management-компонентов.
• IP Subnet Planner
  Калькулятор подсетей VLSM и планировщик диапазонов IP-адресов для сетей VCF: management, vMotion, vSAN и NSX TEP. Проверяет пересечения подсетей и позволяет экспортировать готовый IP-план для развертывания.
• MTU Path Calculator
  Калькулятор эффективного MTU для overlay-сетей GENEVE и VXLAN. Моделирует накладные расходы инкапсуляции на каждом уровне и проверяет требования к jumbo-фреймам для NSX-инфраструктуры.
• VLAN Allocation Planner
  Инструмент для проектирования полного диапазона VLAN с использованием 9 шаблонов VCF. Включает обнаружение конфликтов, автоматическое заполнение подсетей, контроль соглашений по именованию, заметки по L3-маршрутизации и экспорт конфигураций коммутаторов для Arista, Cisco NX-OS, IOS-XE и Juniper.
• VCF 9 Network Config Generator
  Генератор полной сетевой конфигурации для VCF 9, включая назначение VLAN, параметры MTU, политики teaming и конфигурацию пулов NSX TEP для развертываний с несколькими кластерами.
• vSAN Capacity Calculator
  Калькулятор полезной емкости vSAN для архитектур OSA и ESA с политиками RAID-1, RAID-5 и RAID-6. Учитывает slack space, отказ хостов и приблизительную эффективность дедупликации.
• NSX Firewall Rule Planner
  Инструмент для планирования и документирования правил распределенного файрвола NSX. Позволяет задавать группы источников и назначений, сервисы и область применения (Applied-To), проверяет логику правил и экспортирует их в структурированную таблицу.
• VCF Day 2 Operations Planner
  Набор пошаговых runbook-процедур для операций Day-2: расширение кластера, создание доменов нагрузки, ротация сертификатов, обновление компонентов, смена паролей, расширение vSAN и управление сегментами NSX.

Для кого предназначен сайт

Платформа будет полезна:

• Системным администраторам и инженерам виртуализации
• Архитекторам облачной инфраструктуры
• DevOps-специалистам
• Инженерам датацентров и лабораторий

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

Итог

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

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

Сегодня мы рассмотрим вопросы о неизменяемости (immutability) в Kubernetes. На фоне новой волны интереса особенно заметно, что сообщество Kubernetes рассматривает эту тему с иной точки зрения, чем раньше. Пользователи меньше сосредоточены на неизменяемости на уровне отдельного узла и больше интересуются тем, как принципы неизменяемости применяются при управлении целым парком кластеров. Именно это является фундаментальной причиной существования проекта Cluster API.

Почему неизменяемость важна

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

Скорость

В современной ИТ-среде скорость имеет первостепенное значение. Например, скорость необходима, когда нужно масштабировать инфраструктуру для обработки всплесков пользовательских запросов, она нужна при выполнении blue/green-развертываний или при масштабировании инфраструктуры вниз, чтобы держать под контролем стоимость приложений или освобождать ресурсы для других задач.

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

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

Операции в масштабе

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

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

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

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

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

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

Продолжая тот же пример, процесс обновления A/B, характерный для неизменяемых ОС, также может иметь достойную и, возможно, более надёжную альтернативу — когда изменения разворачиваются путём создания новых машин и удаления старых. Результат тот же, но используются простые примитивы создания и удаления — такие же, какие Kubernetes применяет для Pod’ов.

Стабильность

Инженеры-разработчики те, кто поддерживает open source-проекты, постоянно сталкиваются с тем, что у любого проекта или системы есть ограниченный «бюджет сложности», который она может выдержать за определённое время. Когда этот бюджет исчерпывается, начинаются проблемы. Снижается качество, и становится сложно своевременно исправлять ошибки и уязвимости (CVE).

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

Как добиться неизменяемости в Kubernetes

В своей основе неизменяемость — это концепция, философия. Чтобы сделать её реальностью, нужны технологии, которые поддерживают этот подход. Kubernetes - отличная отправная точка: он предоставляет такие примитивы, как неизменяемые Pod’ы, а также более высокоуровневые абстракции - например Deployments и StatefulSet - для управления ими.

Однако Kubernetes не управляет базовой инфраструктурой. Именно здесь появляется Cluster API, поскольку один из фундаментальных принципов проекта — «Kubernetes на всех уровнях». Cluster API позволяет рассматривать Machine (элемент инфраструктуры, например виртуальную машину, на которой работает узел Kubernetes) как неизменяемый компонент.

Когда требуется изменение, вместо модификации существующей машины Cluster API создаёт новую и удаляет старую — аналогично тому, как Kubernetes заменяет Pod’ы. Предоставляя абстракции для управления группами машин, такие как KubeadmControlPlane и MachineDeployment, Cluster API позволяет усиливать преимущества неизменяемости при управлении целым кластером или даже парком кластеров.

Если вы хорошо знакомы с Cluster API, вы можете заметить, что здесь есть серая зона — операционная система, установленная на машине, управляемой CAPI. Cluster API не занимает жёсткой позиции относительно операционной системы на машине, потому что, как показал опыт последних лет, именно здесь разные организации и продукты могут и должны применять разные подходы.

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

Ключом к работе с такими различными требованиями и технологиями являются многочисленные точки расширения Cluster API. Используя эти точки расширения, теперь можно выполнять тщательно проверенный набор операций обновления «на месте» безопасным и полностью автоматизированным способом.

Несколько примеров

Пошаговые обновления (rolling upgrades)

Вместо выполнения сложных процедур обновления существующих машин Cluster API проводит rollout, при котором создаются новые «чистые» машины для замены старых. Этот подход, основанный на принципах неизменяемости, позволяет не только выполнять обновления Kubernetes, но и вносить любые изменения в машины (инфраструктура, ОС и компоненты Kubernetes), используя два простых примитива: создание и удаление Machine.

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

Кроме того, Cluster API гарантирует соблюдение требований к доступности во время rollout. Он также поддерживает цепочные обновления Kubernetes через несколько минорных версий, а рабочие узлы могут пропускать промежуточные минорные версии, если это допускается политикой version skew Kubernetes.

Восстановление нездоровых машин

Как поступить с машинами, которые постоянно работают некорректно — например, когда узел Kubernetes, размещённый на машине, сообщает состояние Ready = false более пяти минут? Cluster API позволяет определить MachineHealthChecks для обработки таких случаев. Когда запускается автоматическое восстановление, система использует принцип неизменяемости для быстрого и эффективного решения проблемы: быстро создаётся новая «чистая» машина-замена, а старая удаляется — снова используя те же два простых примитива: создание и удаление Machine.

Избегание ненужных rollout’ов

Машины — сложные компоненты, и иногда требуется внести изменения, которые не требуют drain узла или перезапуска Pod’ов; например, изменение сертификата реестра образов.

Если по какой-то причине вы хотите выполнить такие изменения без полного rollout машины, Cluster API предоставляет точки расширения, позволяющие выполнить тщательно проверенный набор обновлений «на месте» безопасным и полностью автоматизированным способом. Даже в этих случаях конфигурационный дрейф предотвращается за счёт одинакового применения изменений ко всем машинам.

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

Итоги

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

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

В последнем выпуске подкаста Virtually Speaking Ли Ховард, руководитель IAM Product Management в Broadcom, рассказал, как Identity Security для VMware Cloud Foundation (VCF) обеспечивает безопасный, масштабируемый доступ с нулевым доверием в современных средах частного облака.

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

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

От статической аутентификации к Zero Trust

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

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

Архитектура нулевого доверия оценивает не только то, кто входит в систему, но и как, откуда и к чему именно пытается получить доступ. Безопасность идентификации становится динамической, адаптируясь к поведенческим сигналам, уровням привилегий и контексту среды. Именно здесь современные возможности IAM и PAM становятся критически важными.

IAM и PAM в VMware Cloud Foundation

Identity and Access Management (IAM) управляет аутентификацией, авторизацией и федерацией, используя такие стандарты, как SAML и OpenID Connect. В частном облаке, построенном на VMware Cloud Foundation, IAM должен быть управляемым через API и дружественным к DevOps, позволяя командам разработки интегрировать идентификацию в современные рабочие процессы без жёстких проприетарных ограничений.

Privileged Access Management (PAM) защищает наиболее чувствительный уровень среды: административный доступ и доступ уровня root. PAM обеспечивает доступ с минимально необходимыми привилегиями, хранит учётные данные в защищённых хранилищах, автоматически ротирует пароли и записывает привилегированные сессии. Это снижает риск внутренних угроз, злоупотребления учётными данными и горизонтального перемещения во время взлома.

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

Нативная для Kubernetes идентификация в частном облаке

Платформа Identity Security работает на Kubernetes внутри VMware Cloud Foundation. Такая облачно-нативная архитектура обеспечивает быстрое развертывание, автоматическое масштабирование при всплесках аутентификации и обновления без простоев.

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

Идентификация как ключевая возможность платформы

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

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

Что дальше в серии роликов?

Этот выпуск является частью продолжающейся серии Virtually Speaking, посвящённой Advanced Services, доступным в VMware Cloud Foundation. В каждом выпуске специалисты VMware подробнее рассматривают конкретный сервис и практические результаты, которые он обеспечивает, вместе с людьми, которые ежедневно создают и внедряют эти решения.

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

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

VMware Cloud Foundation (VCF) предлагает решение — VCF предоставляет единую платформу со встроенной средой выполнения Kubernetes, которая оркестрирует управление Kubernetes, позволяя предприятиям запускать современные приложения наряду с традиционными рабочими нагрузками, а также включает сертифицированный дистрибутив Kubernetes, соответствующий upstream-стандартам. С помощью vSphere Supervisor VCF предоставляет пользователям доступ к самообслуживанию для полного набора облачных сервисов «из коробки». Это работает в составе VMware vSphere Kubernetes Service (VKS), который используется для развертывания кластеров Kubernetes и включает совместимый выпуск Kubernetes, а также стандартный пакет ключевых компонентов OSS. VCF предоставляет облачным администраторам и платформенным инженерам выбор интерфейсов, включая GUI, CLI и API, что позволяет командам работать эффективно и продуктивно, вместо того чтобы тратить время на изучение новых наборов инструментов.

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

Единая платформа для виртуальных машин и контейнеров

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

• Единый API для развёртывания и управления виртуальными машинами и контейнерами: единый API позволяет пользователям создавать, развёртывать и управлять как виртуальными машинами, так и кластерами Kubernetes. Это упрощает автоматизацию, снижает сложности интеграции и обеспечивает единые политики и средства безопасности для всех рабочих нагрузок. Благодаря единому API платформенные инженеры могут взаимодействовать с вычислительными ресурсами единообразно, устраняя необходимость в отдельных инструментах и снижая затраты на обучение.
• Сертифицированный релиз Kubernetes, соответствующий upstream, с независимой возможностью обновления: VCF использует полностью соответствующий upstream-дистрибутив Kubernetes, сертифицированный Cloud Native Computing Foundation (CNCF). Эта сертификация подтверждает, что реализация Kubernetes в vSphere соответствует программе Kubernetes Conformance Program, которая проверяет upstream API Kubernetes, рабочие нагрузки и инструменты экосистемы. Например, после обновления до VKS 3.4 вы сможете создавать и управлять кластерами Kubernetes с использованием последнего релиза vSphere Kubernetes 1.33, синхронизированного с последним релизом сообщества.

• Поддержка N-2 версий Kubernetes для гибкого развертывания: VKS поддерживает текущий релиз Kubernetes и две предыдущие основные версии. Это означает, что VKS обеспечивает совместимость сразу с тремя версиями Kubernetes в любой момент времени, что позволяет различным корпоративным командам использовать ту версию, которая необходима их приложениям, а также иметь контроль и гибкость для обновления в собственном темпе.

Упрощённые и эффективные операции

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

• Самообслуживание для доступа к облачным сервисам с управлением и контролем: благодаря модели доступа на основе ролей платформенные инженеры могут использовать возможности самообслуживания для выделения инфраструктурных ресурсов (вычислительные, хранилища и сети) и набора расширенных облачных сервисов в vSphere Supervisor, таких как VM Service, Network Services и Image Registry, по требованию, в то время как облачные администраторы сохраняют управление и контроль с помощью политик и квот ресурсов. Доступ по модели самообслуживания также поддерживает multi-tenancy с изолированными средами для разных команд и проектов.

• Независимое обновление vSphere Supervisor: VMware Cloud Foundation 9.0 предоставляет облачным администраторам дополнительную гибкость, позволяя обновлять vSphere Supervisor независимо от обновления vCenter. Благодаря асинхронным обновлениям снижается операционная сложность и обеспечивается большая гибкость для ИТ-команд в поддержании актуальности сред Kubernetes при сохранении стабильности всей инфраструктуры.
• Автомасштабирование кластеров Kubernetes: улучшения автомасштабирования позволяют динамически изменять количество рабочих узлов на основе метрик в реальном времени, обеспечивая как производительность, так и эффективность. Благодаря поддержке возможностей scale-down-to-zero и scale-up-from-zero кластеры могут автоматически уменьшаться до нуля рабочих узлов в периоды простоя и бесшовно масштабироваться вверх при возобновлении нагрузки. Такая масштабируемость по требованию оптимизирует использование инфраструктуры, снижает операционные затраты и обеспечивает выделение ресурсов только тогда, когда это необходимо.
• Workload zones для оптимизации распределения ресурсов: VCF 9.0 вводит повышенную гибкость благодаря зонам рабочих нагрузок (workload zones), позволяя облачным администраторам определять и управлять ими независимо, чтобы лучше согласовывать инфраструктурные ресурсы с требованиями рабочих нагрузок. vSphere Namespaces поддерживают как однозонные, так и многозонные конфигурации, что упрощает удовлетворение различных требований высокой доступности и сценариев аварийного восстановления. Облачные администраторы также могут расширять инфраструктуру частного облака, добавляя специализированные зоны, например выделяя ресурсы для нагрузок с интенсивным использованием GPU, что обеспечивает больший контроль, оптимизированное использование ресурсов и повышенную гибкость для различных развертываний.
• Интеграция управления кластерами VKS: управление кластерами VKS позволяет облачным администраторам эффективно управлять кластерами и группами кластеров в различных средах. Благодаря встроенным возможностям, таким как управление несколькими кластерами на уровне всей инфраструктуры (fleet-wide multicluster management) и детализированный контроль доступа, команды могут ускорить развертывание, снизить операционную сложность и обеспечить единообразную конфигурацию. Такой унифицированный подход упрощает операции Day 2 и усиливает управление и контроль всей инфраструктуры Kubernetes.

Повышенная безопасность

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

• Встроенная высокая доступность и надежность: VCF обеспечивает встроенную высокую доступность и надежность не только для виртуальных машин, но и для современных рабочих нагрузок. Благодаря интеграции VKS, VCF гарантирует, что контейнеризированные приложения получают те же возможности корпоративного уровня по обеспечению отказоустойчивости, такие как vSphere HA. vSAN предоставляет политики постоянного хранения, адаптированные для stateful-нагрузок Kubernetes, а NSX обеспечивает сетевую доступность и безопасное соединение между кластерами. Благодаря унифицированному управлению жизненным циклом VCF поддерживает стабильное время безотказной работы и операционную устойчивость как для виртуальных машин, так и для контейнеров, работающих на надежной инфраструктуре.
• Интеграция Istio Service Mesh: предоставляет расширенные возможности, такие как обнаружение сервисов, безопасное взаимодействие сервисов друг с другом, маршрутизация трафика и балансировка нагрузки, а также применение политик через интегрированные инструменты наблюдаемости. Благодаря таким функциям, как ingress и egress шлюзы, внедрение сбоев (fault injection), ограничение скорости запросов (rate limiting) и поддержка архитектуры нулевого доверия (zero-trust), Istio Service Mesh позволяет платформенным командам управлять сложными средами микросервисов с прозрачностью, отказоустойчивостью и соответствием требованиям, одновременно упрощая операционные процессы между кластерами Kubernetes.

• Режим OS FIPS для соответствия требованиям: новая опция конфигурации добавляет поддержку включения режима FIPS на уровне операционной системы, обеспечивая использование только криптографических модулей, прошедших валидацию FIPS, для соответствия строгим требованиям безопасности и комплаенса. Это улучшение даёт облачным администраторам гибкость в применении режима FIPS как для Linux, так и для Windows кластеров рабочих нагрузок, приводя среды Kubernetes в соответствие с федеральными и отраслевыми стандартами безопасности при сохранении операционного контроля над уровнем безопасности.
• Расширенная поддержка: в дальнейшем VMware планирует предоставлять Extended Support для определённых версий релизов vSphere Kubernetes (VKr), делая поддержку доступной в течение 24 месяцев с момента GA. Это позволит клиентам VCF оставаться на одной минорной версии Kubernetes значительно дольше, если это необходимо. Первым релизом с расширенной поддержкой станет VKr 1.33.

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

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

Совместимость zVirt с системой доверенной загрузки «Соболь»

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

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

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

Sharx Base расширяет аппаратную совместимость через интеграцию с серверами Trinity

Другой важный сюжет марта связан с платформой Sharx Base и её совместимостью с серверами Trinity. Подобные новости на первый взгляд могут выглядеть как обычные интеграционные объявления, но для рынка импортозамещения они имеют стратегическое значение.

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

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

Реальные внедрения: использование Helius в крупной корпоративной инфраструктуре

Сильный информационный эффект в марте дали новости о практическом внедрении российских решений виртуализации в крупных инфраструктурных проектах. В этом контексте особое внимание привлекло использование Helius в составе геораспределённого вычислительного кластера у НМТП.

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

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

Новые серверные платформы как фундамент для роста виртуализации

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

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

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

Отраслевые конференции как индикатор зрелости рынка

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

Многие VMware-инфраструктуры сегодня находятся в переходной стадии: организации продолжают использовать vSphere-кластеры, но постепенно переходят к модели Software-Defined Data Center и частного облака на базе VMware Cloud Foundation (VCF). Полностью перестраивать инфраструктуру с нуля в производственной среде обычно невозможно. Там уже работают десятки или сотни виртуальных машин, поэтому перенос на новую платформу должен происходить максимально аккуратно. Именно для таких сценариев VMware предлагает механизм Brownfield-интеграции.

Этот подход позволяет смигрировать существующую инфраструктуру vSphere на VMware Cloud Foundation без переустановки среды и без миграции виртуальных машин. Подробно этот процесс рассмотрел Tarsio Moraes в своем видео:

Что такое Brownfield-апгрейд

Brownfield-подход означает интеграцию уже существующей инфраструктуры в новую платформу без полного развертывания новой среды. В VMware-экосистеме это означает, что существующий vCenter Server, кластеры ESX и запущенные виртуальные машины могут быть импортированы в VCF как отдельный Workload Domain.

Таким образом инфраструктура сохраняет текущие рабочие нагрузки, но получает централизованное управление, автоматизированное lifecycle-обновление и интеграцию сетевой платформы NSX.

Архитектура до и после интеграции

Исходная инфраструктура

Типичная среда включает vSphere 8, один или несколько кластеров ESXi, vCenter Server и систему хранения — например vSAN или внешние датасторы. Сетевая конфигурация обычно построена на распределенном коммутаторе Distributed Switch. В такой архитектуре управление вычислениями, сетью и мониторингом может осуществляться через разные инструменты.

После интеграции в VCF

После импорта инфраструктура становится частью платформы VMware Cloud Foundation. Появляется централизованное управление через компоненты VCF, а инфраструктура разделяется на management domain и workload domains. Также стоит учитывать изменения в продуктовой линейке VMware: многие функции бывшей линейки Aria теперь встроены непосредственно в VMware Cloud Foundation (как функционал модуля Operations).

Подготовка инфраструктуры

Перед запуском Brownfield-апгрейда необходимо убедиться, что инфраструктура соответствует требованиям совместимости. В первую очередь проверяются версии компонентов: vSphere, vCenter Server и ESXi (теперь он снова называется ESX). Кроме того, важно убедиться в совместимости оборудования через VMware Compatibility Guide.

Также необходимо проверить базовые инфраструктурные сервисы: DNS, NTP, доступность сетей управления и состояние датасторов. Особенно важно убедиться, что DNS корректно разрешает имена хостов ESX, vCenter и будущих узлов NSX Manager.

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

Перед импортом vSphere-среды необходимо подготовить управляющие компоненты VMware Cloud Foundation. К ним относятся VCF Fleet Management и VCF Operations. Эти сервисы отвечают за централизованное управление инфраструктурой, мониторинг и lifecycle-операции. На этом этапе стоит проверить доступность management-компонентов, валидность сертификатов и сетевую связность между сервисами управления и vCenter.

Использование VCF Import Tool

Для интеграции существующей среды используется специальный инструмент — VCF Import Tool. Он анализирует конфигурацию vSphere, выполняет проверку совместимости и подготавливает инфраструктуру к импорту. Перед запуском процесса выполняется серия pre-check проверок, которые анализируют сеть, лицензии, сертификаты, конфигурацию кластеров и параметры хранения.

Если обнаружены ошибки или предупреждения, их необходимо устранить до начала импорта.

Импорт vCenter как Workload Domain

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

С этого момента среда становится частью VMware Cloud Foundation.

Развертывание NSX

Следующий этап — интеграция сетевой платформы NSX. Если NSX ранее не использовался, VMware Cloud Foundation может автоматически развернуть NSX Manager cluster и подготовить хосты ESX. Если NSX уже установлен в инфраструктуре, он может быть импортирован вместе с workload domain.

Пост-апгрейд проверки

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

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

Итог

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

Компания VMware выпустила новый документ "VMware vSAN Frequently Asked Questions", представляющий собой подробное руководство с ответами на наиболее распространённые вопросы о технологии VMware vSAN — программно-определяемой системе хранения (Software-Defined Storage), встроенной в гипервизор VMware ESX и используемой в средах VMware vSphere.

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

FAQ-документ охватывает широкий спектр тем:

• Архитектуру vSAN (Original Storage Architecture и Express Storage Architecture)
• Требования к оборудованию и сети
• Варианты развертывания кластеров
• Масштабирование и отказоустойчивость
• Интеграцию с другими функциями VMware

Основные разделы FAQ

Вопросы распределены по большим тематическим блокам:

• General Information — общая информация о vSAN
• Express Storage Architecture (ESA)
• Availability — отказоустойчивость
• Cloud-Native Storage
• vSAN File Services
• vSAN Storage Clusters (disaggregated storage)
• Stretched clusters и 2-node clusters
• Networking
• Capacity и Space Efficiency
• Operations
• Performance
• Security
• vSAN Data Protection

Каждый из этих разделов содержит от нескольких до нескольких десятков вопросов (всего более 180 вопросов и ответов), поэтому документ на 56 страниц фактически представляет собой большой справочник по эксплуатации и архитектуре vSAN. Это один из самых подробных FAQ-документов VMware по продукту vSAN, он помогает понять архитектуру решения, требования к оборудованию и лучшие практики внедрения vSAN в корпоративных средах.

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 в средах со смешанными размерами, не оставляя вычислительную ёмкость потерянной.

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

Текущее состояние (февраль 2026)

• Bare Metal (прямо на «железе»): ~15%
• Виртуализованные (работают в виртуальных машинах): ~60%
• Контейнеры + Kubernetes: ~25%*

* До 85% контейнерных / Kubernetes-нагрузок работают поверх виртуальных машин — подробнее об этом можно прочитать в отчете IDC.

Будущее (2030+)

• Bare Metal (прямо на «железе»): ~5%
• Виртуализованные (работают в виртуальных машинах): ~30%
• Контейнеры + Kubernetes: ~65%*

* Ожидается, что более 85% контейнерных / Kubernetes-нагрузок в 2030+ будут работать поверх виртуальных машин. Цифры основаны на данных, представленных в том же отчете IDC.

Что движет этой тенденцией?

Существует множество подтверждений этой тенденции — модернизация приложений, рост зрелости DevOps-подходов в организациях и трансформация в сторону облачных моделей. Эти процессы продолжаются практически во всех компаниях. Кроме того, ожидается резкий рост общего числа новых рабочих нагрузок из-за влияния генеративного AI. Большинство таких приложений создаются по принципам cloud-native разработки и требуют современной инфраструктуры и операционной стратегии, чтобы их можно было надежно запускать и управлять ими в производственной среде.

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

Гиперскейлеры предложили и реализовали решение этой проблемы, взяв на себя значительную часть операций жизненного цикла инфраструктуры. Однако опасения, связанные со стоимостью, соответствием требованиям и суверенитетом данных, становятся ключевыми факторами так называемого “перезапуска частного облака” (Private Cloud Reset).

Отрасль находится в точке перелома

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

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

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

Kubernetes как полноценная часть частного облака

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

VMware vSphere Kubernetes Service (VKS) является нативной частью VCF и позволяет быстро разворачивать полностью соответствующие стандартам Kubernetes-кластеры по требованию.

VCF абстрагирует инфраструктуру и делает её доступной через API, предоставляя богатый набор cloud-native сервисов и пакетов вместе с долгосрочной корпоративной поддержкой (LTS). Все рабочие нагрузки — будь то на виртуальных машинах или в контейнерах — могут быстро разворачиваться, оптимизироваться, обновляться и мониториться с использованием одних и тех же инструментов и процессов.

Результаты

Результаты говорят сами за себя. На сегодняшний день более 90% из 10 000 крупнейших клиентов VMware приобрели VCF, включая 9 из 10 крупнейших компаний списка Fortune. Такие компании, как Audi, ING Bank, Lloyds Banking Group и Walmart, внедряют VCF и расширяют сотрудничество с Broadcom.

Собственные ИТ-команды Broadcom также внедрили эту технологию и облачную операционную модель, чтобы:

• Консолидировать дата-центры и инструментарий
• Повысить общую надежность систем
• Ускорить выделение инфраструктуры и приложений
• Снизить расходы

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

Что нужно современным предприятиям

Компаниям необходимо быстро развиваться, контролировать расходы и защищаться от угроз. Им нужна гибкость облака, но при этом важно использовать инструменты и навыки, на которых ИТ-команды строили свою карьеру.

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

Дункан Эппинг в своей статье ответил на этот вопрос. Он стал замечать, что этот вопрос возникает всё чаще: можно ли реплицировать или создавать снапшот виртуального модуля vSAN Stretched Cluster Witness для быстрого восстановления? Обычно люди задают его потому, что не могут соблюсти требование трёх площадок для vSAN Stretched Cluster. Поэтому, настроив какой-то механизм репликации с низким RPO, они пытаются снизить этот риск.

Возможно, этот вопрос возникает из-за недостаточного понимания того, какую роль выполняет Witness. Он обеспечивает механизм кворума, а этот механизм помогает определить, какая площадка получает доступ к данным в случае сетевого сбоя (ISL) между площадками хранения данных.

Так почему же виртуальное устройство Witness нельзя снапшотить или реплицировать? Дело в том, что для обеспечения механизма кворума Witness Appliance хранит witness-компонент для каждого объекта. Причём не для каждой площадки и не для каждой виртуальной машины, а для каждого объекта! То есть если у вас есть ВМ с несколькими VMDK, то для одной ВМ на Witness Appliance будет храниться несколько witness-объектов.

Этот witness-объект содержит метаданные и с помощью номера последовательности журнала (log sequence number) определяет, какой объект содержит самые актуальные данные. И вот здесь возникает проблема. Если вы откатите Witness Appliance к более раннему моменту времени, то witness-компоненты также откатятся назад и будут иметь другой номер последовательности журнала, чем ожидается. В результате vSAN не сможет сделать объект доступным для выжившей площадки или для той площадки, которая должна обладать кворумом.

Итак, краткий вывод: следует ли реплицировать или создавать снапшот Witness Appliance? Нет!

В видеоролике ниже демонстрируется процесс развертывания решения Private AI Foundation с NVIDIA с использованием мастера быстрой настройки.

Автор пошагово показывает, как запустить Foundation Quick Start, выбрать проект и соответствующее пространство имен (namespace), а также вставить клиентский конфигурационный токен, полученный от NVIDIA. В примере используется среда с подключением к интернету, поэтому дополнительные параметры, такие как офлайн-реестр или изменение расположения драйверов, настраивать не требуется.

Далее в видео подробно рассматриваются ключевые параметры развертывания:

• Выбор версии Kubernetes (или VKR).
• Указание образа виртуальной машины для задач глубокого обучения (Deep Learning VM), заранее загруженного в библиотеку контента.
• Выбор класса хранилища (storage class).
• Настройка GPU-совместимых классов ВМ (резервирование GPU).
• Выбор классов ВМ без поддержки GPU.

Также демонстрируется, что в рамках примера не активируются дополнительные сервисы VCF Data Services и не используется прокси-сервер.

После проверки всех параметров запускается процесс создания ресурсов каталога в выбранном пространстве имен. Через несколько минут новые элементы становятся доступны в разделе Build and Deploy -> Catalog, где можно увидеть созданные позиции Private AI Foundation с NVIDIA и при необходимости запросить их для дальнейшего использования.

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

Дункан Эппинг написал интересный пост на тему решения VMware vSAN и допустимых лимитов на компоненты. За последние несколько лет у него было не так много обсуждений по поводу лимитов, но в последнее время такие разговоры почему-то стали возникать всё чаще. Если спросить клиента, каков лимит компонентов у vSAN, кто-то скажет — 9000 на хост (OSA), другие — 27 000 на хост (ESA), а некоторые даже знают ограничение по количеству компонентов на кластер (в документации эти лимиты указаны здесь и здесь). Однако есть один критически важный аспект, о котором большинство обычно не задумывается. В этом посте мы сосредоточимся на vSAN ESA.

Как уже упоминалось, существует лимит на хост и на кластер, но также есть ограничение на устройство (диск). Частая ошибка заключается в том, что люди воспринимают кластерный и хостовый лимиты как самостоятельные и фиксированные значения. Однако здесь есть зависимость. Как было сказано, у устройства тоже есть свой предел. В vSAN ESA одно устройство может содержать максимум 3000 data-компонентов и 3000 metadata-компонентов. Именно такие ограничения поддерживаются в текущей версии (vSAN 9.0). Пока сосредоточимся на data-компонентах (уровень ёмкости).

Это означает, что если в хосте 8 устройств или меньше, то максимальное количество компонентов будет не 27 000, а «количество устройств x 3000». Другими словами, если в хосте один NVMe-накопитель для vSAN ESA, максимальное количество компонентов для этого хоста — 3000. Если два устройства — максимум 6000, и так далее.

Почему об этом стоит писать? Если учесть количество компонентов на один объект и умножить его на типичное количество объектов, быстро становится понятно почему. Предположим, вы используете RAID-5 с ESA в конфигурации 4+1 — это даст как минимум 5 компонентов. Если у виртуальной машины несколько дисков, легко можно получить 35–40 компонентов на одну ВМ. Если взять лимит 3000 и разделить его, скажем, на 40 компонентов, получаем всего 75–80 виртуальных машин. Конечно, у вас будет несколько хостов, и это число масштабируется по их количеству, но пример наглядно показывает, почему важно учитывать этот максимум.

Возникает вопрос: почему эта тема стала подниматься именно сейчас? Дело в том, что по мере того как заказчики всё увереннее используют vSAN ESA, мы видим всё более «экзотические» конфигурации. Всё чаще развёртываются системы с очень ёмкими накопителями, но в небольшом количестве. Если раньше обычно использовали 6–8 устройств на хост по 1–2 ТБ каждое, то теперь всё чаще спрашивают о конфигурациях с одним NVMe-накопителем на 15 ТБ или двумя устройствами по 7.x ТБ. Нетрудно представить, что при таких вводных лимит в 3000 data-компонентов достигается значительно быстрее, чем хостовый лимит в 27 000 компонентов.

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

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

Что такое VMmark 4, и зачем он нужен

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

• базы данных
• веб-серверы
• почтовые системы
• application-серверы
• файловые сервисы

Нагрузка масштабируется в единицах tiles — каждый tile представляет собой комплекс виртуальных машин с типовым профилем предприятия. Итоговый показатель (VMmark Score) отражает способность кластера обслуживать увеличивающееся число рабочих нагрузок при сохранении SLA по производительности.

Тестовая конфигурация: ключевые компоненты

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

• Программное обеспечение: VMware Cloud Foundation 9.0.1.0 .
• Система хранения: VMware vSAN 9.0 Express Storage Architecture (ESA) — all-flash кластер.
• Процессоры: AMD EPYC 9965 из серии 9005.
• Сетевые адаптеры: Broadcom NetXtreme-E Series BCM57508 200 GbE PCIe 4.0.
• NVMe-накопители: Micron 9550 SSD в составе vSAN.
• Тестирование: кластерный VMmark 4 с измерением масштаба до 15.4 tiles.

Программный стек VMware Cloud Foundation 9.0

VMware Cloud Foundation 9.0 — это интегрированная платформа, объединяющая ядро виртуализации, сетевые услуги и программно-определяемое хранилище:

• VMware vSphere 9: гипервизор корпоративного класса.
• vSAN 9 ESA: программное хранилище уровня предприятия с оптимизированной архитектурой Express Storage Architecture.
• NSX: сетевые сервисы и безопасность для виртуальной инфраструктуры.
• Operations: мониторинг, аналитика и автоматизация облачных ресурсов.

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

Результат тестирования

Для объективного сравнения использовалась идентичная вычислительная платформа (AMD EPYC 9965, суммарно 1536 физических ядер кластера), но две разные подсистемы хранения:

• vSAN 9.0 ESA (All-Flash, NVMe)
• Классический FC SAN (Dell PowerMax 8000)

Таблица результатов:

Интерпретация результатов:

• Tiles — это масштабируемые блоки нагрузки в VMmark 4. Каждый tile представляет набор типовых корпоративных рабочих нагрузок (Web, DB, Mail, Application Server и др.).
• Значение 15.4 tiles означает более высокий уровень масштабирования кластера.
• Итоговый показатель 12.42 — агрегированный производительный балл, учитывающий пропускную способность и latency.

Главный вывод - конфигурация с vSAN 9.0 ESA продемонстрировала:

• Большее число поддерживаемых tiles (15.4 против 14 для FC)
• Более высокий итоговый Score
• Лучшую масштабируемость без использования внешнего SAN-массива.

Это подтверждает, что современная архитектура vSAN ESA в составе VCF 9.0 способна не только конкурировать с традиционными FC-решениями, но и превосходить их при одинаковой вычислительной базе.

Заключение

Новый VMmark 4 результат, полученный на VMware Cloud Foundation 9.0 с vSAN, подтверждает:

• Высокую производительность и масштабируемость платформы.
• Превосходство программно-определяемого хранения (vSAN) над традиционными SAN в современных конфигурациях.
• Готовность VMware VCF 9.0 к использованию в масштабных частных облаках и корпоративных средах.

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

Компания VMware выпустила обновлённое официальное руководство vSAN Stretched Cluster Guide, предназначенное для архитекторов и администраторов, работающих с растянутыми кластерами vSAN в рамках платформы VMware Cloud Foundation (VCF) 9.0. Документ был выпущен 18 февраля 2026 года и отражает актуальные практики проектирования, развертывания и эксплуатации таких инфраструктур.

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

Что нового в версии для VCF 9.0

• Актуализация под VCF 9.0 и vSAN 9
  Документ ориентирован на использование растянутых кластеров именно в контексте VCF 9.0, в том числе с учётом последних архитектурных изменений и интеграции с инструментами автоматизации SDDC Manager.
• Расширенные рекомендации по сетевым требованиям
  В руководстве обновлены требования к сети между площадками — минимальные значения пропускной способности и задержек, оптимальные настройки MTU и рекомендации по сегментации трафика.
• Поддержка разных архитектур хранения
  Кроме классической архитектуры vSAN (OSA), руководство учитывает и vSAN Express Storage Architecture (ESA) — более современный вариант с улучшенной производительностью и эффективностью хранения.
• Процессы установки и конвертации
  Обозначены пошаговые процессы установки растянутого кластера, развёртывания и конфигурации vSAN Witness Host, а также инструкция по конвертации существующего кластера vSAN в растянутую конфигурацию без прерывания работы.
• Сценарии отказов и восстановление
  Отдельный раздел посвящён анализу отказов, поведения кластера в стрессовых ситуациях и практикам восстановления после отказов отдельных компонентов или целых площадок.

Практическая ценность для предприятий

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

Новый документ vSAN Stretched Cluster Guide служит исчерпывающим справочником для ИТ-специалистов, помогая спланировать архитектуру, соблюсти требования к оборудованию и сети, правильно настроить объектные политики хранения и обеспечить корректное поведение системы в случае сбоев.

По мере того как внедрение 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 можно узнать на странице продукта.

В 2026 году сообщество ESX получило сразу два важнейших обновления, которые расширяют возможности использования популярных сетевых устройств Realtek RTL8157 и RTL8156BG в виртуальной инфраструктуре VMware. Эти обновления особенно актуальны для лабораторных сред, мини-ПК и других систем с оборудованием, не поддерживаемым «из коробки» стандартным инсталлятором ESX.

Интеграция Realtek Network Driver Fling в бесплатный установочный ISO ESXi

Одной из ключевых проблем при установке ESXi 8 Update 3 на ПК с сетевыми адаптерами Realtek является отсутствие драйверов для этих сетевых контроллеров в стандартном установщике. Чтобы обойти это ограничение, было разработано решение для сообщества пользователей - Realtek Network Driver Fling (пока еще недоступно для ESX 9, но скоро будет).

Этот драйвер не является официальным продуктом Realtek, а представляет собой компонент Fling (экспериментальный инструмент для расширения ESXi), который обеспечивает базовую поддержку PCIe-сетевых адаптеров Realtek. Об этом недавно написал Вильям Лам.

Драйвер поддерживает ряд популярных моделей Realtek:

• RTL8111 — 1 GbE
• RTL8125 — 2,5 GbE
• RTL8126 — 5 GbE
• RTL8127 — 10 GbE

Проблема в том, что в бесплатных ISO-образах ESXi отсутствует пакет offline bundle (который можно было бы включить стандартным способом). Однако, как показано в одной из публикаций Вильяма Лама, можно вручную интегрировать драйвер в ISO-установщик ESXi 8.0 Update 3e.

Процесс включает:

• Загрузку ISO-образа ESXi и архива драйвера Realtek Network Driver Fling.

• Извлечение модуля драйвера и переименование в специальный файл (например, ifre.v00).

• Добавление этого модуля в загрузочный конфигурационный файл ISO (boot.cfg) для автоматической загрузки при старте установщика.

• Установку ESXi с загрузочного носителя и копирование модуля драйвера на установленную систему для постоянного использования.

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

Расширение USB-сетевого драйвера — поддержка новых чипов Realtek

Другая важная новость касается USB Native Network Driver для ESXi, ещё одного модуля Fling, который добавляет поддержку USB-сетевых адаптеров. Сегодня этот драйвер поддерживает уже более 25 различных чипсетов, а в свежем обновлении разработчики добавили поддержку USB-адаптеров Realtek RTL8157 (5 GbE) и RTL8156BG (2,5 GbE).

Это означает, что пользователи могут подключать к ESXi внешние USB-сетевые адаптеры и использовать их для сетевого трафика без необходимости установки PCIe-карты. Такие адаптеры, особенно в формате USB-C или USB-A, часто используются в компактных рабочих станциях и ноутбуках.

Примеры совместимых устройств (которые можно использовать для тестов и сборок лабораторных систем):

• USB-A - 2,5 GbE адаптер на базе RTL8156BG
• USB-C - 5 GbE адаптер на базе RTL8157

Установка обновлённого USB-сетевого драйвера производится как с помощью offline bundle (через команду esxcli software component apply), так и путём интеграции в ISO-образ ESXi аналогично описанному в статье Вильяма процессу.

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

До появления этих драйверов ESXi мог не видеть сетевые устройства Realtek, что делало невозможной установку гипервизора на недорогие системы или платформы с USB-адаптерами. Решения Fling активно развиваются сообществом и дают пользователям гибкие способы расширения функциональности ESXi без официальной поддержки от производителя.

Теперь вы можете:

• Интегрировать новейший Realtek PCIe-драйвер прямо в установщик ESXi.
• Использовать современные USB-сетевые адаптеры с высокими скоростями передачи (2,5 GbE и 5 GbE).
• Поддерживать широкий спектр оборудования в лабораторных или домашних средах.

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

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

Что такое Management Pack Builder

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Отличные новости для сетевых инженеров и архитекторов, работающих в экосистеме VMware. Компания представила новую сертификацию VMware Certified Advanced Professional – VCAP Administrator Networking (3V0-25.25). Этот экзамен продвинутого уровня (VCAP) предназначен для подтверждения глубоких знаний и практических навыков в проектировании, развертывании и администрировании сетевых решений VMware Cloud Foundation (VCF).

Новый стандарт профессиональной экспертизы в VCF Networking

Экзамен 3V0-25.25 ориентирован на опытных ИТ-специалистов, которые работают с современными корпоративными и мультиоблачными инфраструктурами. Получение данной сертификации демонстрирует способность кандидата эффективно решать сложные сетевые задачи в рамках архитектуры VMware Cloud Foundation.

Ключевые параметры экзамена:

• Код экзамена: 3V0-25.25
• Продолжительность: 135 минут
• Количество вопросов: 60
• Проходной балл: 300
• Стоимость: 250 USD
• Язык: английский

Кому подойдет эта сертификация

Экзамен рассчитан на специалистов с уверенным опытом в корпоративных сетях и экспертизой по решению VMware NSX. Рекомендуемый профиль кандидата включает:

• 1–2 года практического опыта проектирования и администрирования решений NSX
• Не менее 2 лет работы с Enterprise-сетями
• Уверенное владение UI-, CLI- и API-ориентированными рабочими процессами VCF
• Практический опыт работы с VCF Networking и vSphere

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

Что проверяет экзамен 3V0-25.25

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

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

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

Как подготовиться к экзамену

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

• VMware Cloud Foundation Networking Advanced Design
• VMware Cloud Foundation Networking Advanced Configuration
• VMware Cloud Foundation Networking Advanced Troubleshooting

Также крайне важно изучить официальную документацию VMware Cloud Foundation 9.0, актуальные release notes и технические материалы от Broadcom, чтобы быть в курсе всех возможностей и изменений платформы.

Будьте среди первых сертифицированных специалистов

Выход сертификации VMware Certified Advanced Professional – VCF Networking — значимое событие для профессионалов в области сетевых технологий. Этот статус подтверждает высокий уровень экспертизы и позволяет выделиться на фоне других специалистов, открывая новые карьерные возможности. Если вы хотите быть на передовой в индустрии и официально подтвердить свои знания в области VCF Networking — сейчас самое время сделать этот шаг.

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

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

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

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

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

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

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

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

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

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

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

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

Хотя значения по умолчанию в vSphere в составе VMware Cloud Foundation 9.0 разработаны так, чтобы «просто работать» в большинстве сред, для настоящей оптимизации требуется тонкая настройка. Независимо от того, используете ли вы виртуальные рабочие столы или базы данных, важно понимать, какие рычаги управления стоит задействовать.

Ниже описано, как освоить расширенные параметры для настройки соотношений памяти, шифрования на уровне хоста и отдельных ВМ, а также отключения технологии Memory Tiering на уровне отдельных машин.

Настройка соотношения DRAM:NVMe

По умолчанию при включении Memory Tiering ESX устанавливает соотношение DRAM к NVMe равным 1:1, то есть 100% дополнительной памяти за счёт NVMe. Это означает, что при наличии 512 ГБ DRAM хост получит ещё 512 ГБ NVMe-ёмкости в качестве памяти Tier 1, что в сумме даст 1 ТБ памяти.

Однако в зависимости от типа рабочих нагрузок вы можете захотеть изменить эту плотность. Например, в VDI-среде, где ключевым фактором является стоимость одного рабочего стола, может быть выгодно использовать более высокое соотношение (больше NVMe на каждый гигабайт DRAM). Напротив, для кластеров с высокими требованиями к производительности вы можете захотеть ограничить размер NVMe-яруса.

Управление этим параметром осуществляется через расширенную системную настройку хоста: Mem.TierNVMePct.

Параметр

• Где настраивается: Host Advanced System Settings
• Ключ: Mem.TierNVMePct
• Значение: процент DRAM, используемый в качестве NVMe-яруса

Возможные значения:

• 100 (по умолчанию): 100% от объёма DRAM (соотношение 1:1)
• 200: 200% от объёма DRAM (соотношение 1:2)
• 50: 50% от объёма DRAM — очень консервативный вариант (соотношение 2:1)

Примечание. Рекомендации и лучшие практики предполагают сохранение соотношения по умолчанию 1:1, так как оно подходит для большинства рабочих нагрузок. Если вы решите изменить это соотношение, необходимо предварительно тщательно проанализировать свои нагрузки и убедиться, что вся активная память может быть размещена в объёме DRAM хоста. Подробнее о расчёте ёмкости Memory Tiering см. вот тут.

Защита уровня: шифрование

Одним из архитектурных различий между DRAM и NVMe является постоянство хранения данных. В то время как обычная оперативная память теряет данные (практически) мгновенно при отключении питания, NVMe является энергонезависимой. Несмотря на то что VMware выполняет очистку страниц памяти, организации с повышенными требованиями к безопасности (особенно в регулируемых отраслях) часто требуют шифрование данных «на диске» (Data-at-Rest Encryption) для любых данных, записываемых на накопители, даже если эти накопители используются как память. Более подробное описание шифрования NVMe в контексте Memory Tiering приведено вот тут.

Здесь доступны два уровня управления: защита всего NVMe-уровня хоста целиком либо выборочное шифрование данных только для определённых виртуальных машин, вместо шифрования данных всех ВМ на хосте.

Вариант A: шифрование на уровне хоста

Это «универсальный» подход. Он гарантирует, что любая страница памяти, перемещаемая из DRAM в NVMe-уровень на данном хосте, будет зашифрована с использованием алгоритма AES-XTS.

• Где настраивается: Host Advanced Configuration Parameters
• Ключ: Mem.EncryptTierNvme
• Значение: 1 — включено, 0 — отключено

Вариант Б: шифрование на уровне виртуальной машины

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

Параметр

• Где настраивается: VM Advanced Configuration Parameters
• Ключ: sched.mem.EncryptTierNVMe
• Значение: TRUE

Отказ от использования: отключение Memory Tiering для критичных ВМ

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

Типичные сценарии использования:

• SAP HANA и другие in-memory базы данных
• Приложения для высокочастотной торговли (High-Frequency Trading)
• Виртуальные машины безопасности

Кроме того, существуют профили виртуальных машин, которые в настоящее время не поддерживают Memory Tiering, такие как ВМ с низкой задержкой, ВМ с Fault Tolerance (FT), ВМ с большими страницами памяти (large memory pages) и др. Для таких профилей Memory Tiering необходимо отключать на уровне виртуальной машины. Это принудительно размещает страницы памяти ВМ исключительно в Tier 0 (DRAM). Полный список профилей ВМ см. в официальной документации VMware.

Параметр

• Где настраивается: VM Advanced Configuration Parameters
• Ключ: sched.mem.enableTiering
• Значение: FALSE

Ну и в заключение - таблица расширенных параметров Memory Tiering:

Memory Tiering в VCF 9.0 представляет собой серьёзный сдвиг в подходе к плотности серверов и интеллектуальному потреблению ресурсов. Эта технология уводит нас от жёсткого «потолка по RAM» и предоставляет гибкий, экономически эффективный буфер памяти. Однако, как и в случае с любым мощным инструментом, значения по умолчанию — лишь отправная точка. Используя описанные выше параметры, вы можете настроить поведение системы в соответствии как с ограничениями бюджета, так и с требованиями SLA.

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

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

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

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

VMware Product Release Tracker (vTracker)

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

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

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

VMware ESXi Release and Build Number History

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

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

VMware vCenter Release and Build Number History

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

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

PowerShell OVF Helper

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

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

VMware ESXi SCSI Sense Code Decoder

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методы:

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

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

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

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

Включение Memory Tiering

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

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

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

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

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

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

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

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

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

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

В этой статье мы завершаем рассказывать об итогах 2025 года в сферах серверной и настольной виртуализации на базе российских решений. Сегодня мы поговорим о том, как их функционал соотносится с таковым от ведущего мирового производителя - VMware.

Первую часть статьи можно прочитать тут, вторая - доступна здесь.

Сравнение с VMware vSphere

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

Функциональность

Почти все базовые возможности VMware теперь доступны и в отечественных продуктах: от управления кластерами, миграции ВМ на лету и снапшотов до сетевой виртуализации и распределения нагрузки. Многие платформы прямо ориентируются на VMware при разработке. Например, SpaceVM позиционирует свои компоненты как аналоги VMware: SDN Flow = NSX, FreeGRID = NVIDIA vGPU (для Horizon), Space Dispatcher = Horizon Connection Server. ZVirt, Red, ROSA, SpaceVM – все поддерживают VMware-совместимые форматы виртуальных дисков (VMDK/OVA) и умеют импортировать ВМ из vSphere.

То есть миграция технически осуществима без кардинальной переделки ВМ. Live Migration, HA, кластеры, резервирование – эти функции стали стандартом де-факто, и российские продукты их предоставляют. Более того, появились и некоторые новые возможности, которых нет в базовом издании vSphere: например, интеграция с Kubernetes (KubeVirt) в решении Deckhouse от Flant позволяет управлять ВМ через Kubernetes API – VMware предлагает нечто подобное (vSphere with Tanzu), но это отдельно лицензируемый модуль.

Другой пример – поддержка облачных сервисов: некоторые отечественные платформы сразу рассчитаны на гибридное облако, тогда как VMware требует vCloud Suite (сейчас это часть платформы VMware Cloud Foundation, VCF). Тем не менее, зрелость функционала различается: если у VMware каждая возможность отполирована годами использования по всему миру, то у новых продуктов возможны баги или ограничения. Эксперты отмечают, что просто сравнить чекбоксы “есть функция X” – недостаточно, важна реализация. У VMware она, как правило, образцовая, а у российского аналога – может требовать ручных доработок. Например, та же миграция ВМ в российских системах работает, но иногда возникают нюансы с live migration при специфических нагрузках (что-то, что VMware давно решила).

Производительность и масштабирование

VMware vSphere славится стабильной работой кластеров до 64 узлов (в v7 – до 96 узлов) и тысяч ВМ. В принципе, и наши решения заявляют сопоставимый масштаб, но проверены они временем меньше. Как упоминалось, некоторые продукты испытывали сложности уже на 50+ хостах. Тем не менее, для 90% типовых инсталляций (до нескольких десятков серверов) разницы в масштабируемости не будет. По производительности ВМ – разница тоже минимальна: KVM и VMware ESXi показывают близкие результаты бенчмарков. А оптимизации вроде vStack с 2% overhead вообще делают накладные расходы незаметными. GPU-виртуализация – здесь VMware имела преимущество (технология vGPU), но сейчас SpaceVM и другие сократили отставание своим FreeGRID. Зато VMware до последнего времени обеспечивала более широкую поддержку оборудования (драйверы для любых RAID, сетевых карт) – российские ОС и гипервизоры поддерживают далеко не все модели железа, особенно новейшие. Однако ситуация улучшается за счет локализации драйверов и использования стандартных интерфейсов (VirtIO, NVMe и пр.).

Совместимость и экосистема

Ключевое различие – в экосистеме смежных решений. Окружение VMware – это огромный пласт интеграций: сотни backup-продуктов, мониторингов, готовых виртуальных апплаенсов, специальных плагинов и т.д. В российской экосистеме такого разнообразия пока нет. Многие специализированные плагины и appliance, рассчитанные на VMware, не будут работать на отечественных платформах.

Например, виртуальные апплаенсы от зарубежных вендоров (сетевые экраны, балансировщики), выпускались в OVF под vSphere – их можно включить и под KVM, но официальной поддержки может не быть. Приходится либо искать аналогичный российский софт, либо убеждаться, что в open-source есть совместимый образ. Интеграция с enterprise-системами – тоже вопрос: у VMware был vCenter API, поддерживаемый многими инструментами. Отечественным гипервизорам приходится писать собственные модули интеграции. Например, не все мониторинговые системы «из коробки» знают про zVirt или SpaceVM – нужно настраивать SNMP/API вручную.

Такая же ситуация с резервным копированием: знакомые всем Veeam и Veritas пока не имеют официальных агентов под наши платформы (хотя Veeam частично работает через стандартный SSH/VIX). В итоге на текущем этапе экосистема поддержки у VMware гораздо более развита, и это объективный минус для новых продуктов. Однако постепенно вокруг популярных российских гипервизоров формируется своё сообщество: появляются модули для Zabbix, адаптеры для Veeam через скрипты, свои решения backup (например, CyberProtect для Cyber Infrastructure, модуль бэкапа в VMmanager и т.п.).

Надёжность и поддержка

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

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

Стоимость и лицензирование

Ранее VMware имела понятную, хоть и недешёвую модель лицензирования (по процессорам, +опции за функции). После покупки Broadcom стоимость выросла в разы, а бессрочные лицензии отменены – только подписка. Это сделало VMware финансово тяжелее для многих. Отечественные же продукты зачастую предлагают более гибкие условия: кто-то лицензирует по ядрам, кто-то по узлам, у кого-то подписка с поддержкой. Но в целом ценовой порог для легального использования ниже, чем у VMware (тем более, что последняя официально недоступна, а «серыми» схемами пользоваться рискованно). Некоторые российские решения и вовсе доступны в рамках господдержки по льготным программам для госучреждений. Таким образом, с точки зрения совокупной стоимости владения (TCO) переход на отечественную виртуализацию может быть выгоден (но может и не быть), особенно с учётом локальной техподдержки и отсутствия валютных рисков.

Подведём коротко плюсы и минусы российских платформ относительно VMware.

Плюсы отечественных решений:

• Импортонезависимость и соответствие требованиям. Полное соблюдение требований законодательства РФ для госкомпаний и КИИ (реестр ПО, совместимость с ГОСТ, сертификация ФСТЭК у компонентов).
• Локальная поддержка и доработка. Возможность напрямую взаимодействовать с разработчиком, получать кастомные улучшения под свои задачи и быстро исправлять проблемы в сотрудничестве (что практически невозможно с глобальным вендором).
• Интеграция с отечественной экосистемой. Совместимость с российскими ОС (Astra, РЕД, ROSA), СУБД, средствами защиты (например, vGate) – упрощает внедрение единого импортозамещённого ландшафта.
• Новые технологии под свои нужды. Реализация специфичных возможностей: работа без лицензий NVIDIA (FreeGRID), поддержка гостевых Windows без обращения к зарубежным серверам активации, отсутствие жёсткого вендорлока по железу (любое x86 подходит).
• Стоимость и модель владения. Более низкая цена лицензий и поддержки по сравнению с VMware (особенно после удорожания VMware); оплата в рублях, отсутствие риска отключения при санкциях.

Минусы и вызовы:

• Меньшая зрелость и удобство. Интерфейсы и процессы менее отточены – администрирование требует больше времени и знаний, некоторые задачи реализованы не так элегантно, больше ручной работы.
• Ограниченная экосистема. Не все привычные внешние инструменты совместимы – придется пересматривать решения для бэкапа, мониторинга, а автоматизация требует дополнительных скриптов. Нет огромного сообщества интеграторов по всему миру, как у VMware.
• Риски масштабируемости и багов. На больших нагрузках или в сложных сценариях могут всплывать проблемы, которые VMware уже давно решила. Требуется тщательное пилотирование и возможно компромиссы (уменьшить размер кластера, разделить на несколько и др.).
• Обучение персонала. ИТ-специалистам, годами работавшим с VMware, нужно переучиваться. Нюансы каждой платформы свои, документация не всегда идеальна, на русском языке материалов меньше, чем англоязычных по VMware.
• Отсутствие некоторых enterprise-фишек. Например, у VMware есть многолетние наработки по гибридному облаку, экосистема готовых решений в VMware Marketplace. Российским аналогам предстоит путь создания таких же богатых экосистем.

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

Выводы и перспективы импортозамещения VMware

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

• SpaceVM + Space VDI (экоcистема Space) – комплексное решение от компании «ДАКОМ M», которое отличается максимальной полнотой функционала. SpaceVM обеспечивает производительную серверную виртуализацию с собственными технологиями (SDN, FreeGRID), а Space VDI дополняет её средствами виртуализации рабочих мест. Этот тандем особенно хорош для компаний, которым нужны все компоненты "как у VMware" под одним брендом – гипервизор, диспетчеры, клиенты, протоколы. Space активно набирает популярность: 1-е место в рейтингах, успешные внедрения, награды отрасли. Можно ожидать, что он станет одним из столпов корпоративной виртуализации РФ.
• Basis Dynamix – продукт компании «Базис», ставший лидером технических рейтингов. Basis привлекает госзаказчиков и большие корпорации, ценящие интегрированный подход: платформа тесно сопряжена с отечественным оборудованием, ОС и имеет собственный центр разработки. Ее козыри – высокая производительность, гибкость (поддержка и классической, и HCI-схем) и готовность к кастомизации под клиента. Basis – хороший выбор для тех, кто строит полностью отечественный программно-аппаратный комплекс, и кому нужна платформа с длительной перспективой развития в России.
• zVirt (Orion soft) – одна из самых распространённых на практике платформ, обладающая богатым набором функций и сильным акцентом на безопасность. За счет происхождения от oVirt, zVirt знаком многим по архитектуре, а доработки Orion soft сделали его удобнее и безопаснее (SDN, микросегментация, интеграция с vGate). Крупнейшая инсталляционная база говорит о доверии рынка. Хотя у zVirt есть ограничения по масштабированию, для средних размеров (десятки узлов) он отлично справляется. Это надежный вариант для постепенной миграции с VMware в тех организациях, где ценят проверенные решения и требуются сертификаты ФСТЭК по безопасности.
• Red Виртуализация – решение от РЕД СОФТ, важное для госсектора и компаний с экосистемой РЕД ОС. Его выбрал, к примеру, Россельхозбанк для одной из крупнейших миграций в финансовом секторе. Продукт относительно консервативный (форк известного проекта), что можно считать плюсом – меньше сюрпризов, более понятный функционал. Red Virtualization перспективна там, где нужна максимальная совместимость с отечественным ПО (ПО РЕД, СУБД РЕД и пр.) и официальная поддержка на уровне регуляторов.
• vStack HCP – хотя и более нишевое решение, но весьма перспективное для тех, кому нужна простота HCI и высочайшая производительность. Отсутствие зависимости от громоздких компонентов (ни Linux, ни Windows – гипервизор на FreeBSD) дает vStack определенные преимущества в легковесности. Его стоит рассматривать в том числе для задач на периферии, в распределенных офисах, где нужна автономная работа без сложной поддержки, или для быстрорастущих облачных сервисов, где горизонтальное масштабирование – ключевой фактор.
• HostVM VDI / Veil / Termidesk – в сфере VDI помимо Space VDI, внимания заслуживают и другие разработки. HostVM VDI – как универсальный брокер с множеством протоколов – может подойти интеграторам, строящим сервис VDI для разных платформ. Veil VDI и Termidesk – пока чуть менее известны на рынке, но имеют интересные технологии (например, Termidesk с собственным кодеком TERA). Для компаний, уже использующих решения этих вендоров, логично присмотреться к их VDI для совместимости.

В заключение, можно уверенно сказать: российские продукты виртуализации достигли уровня, при котором ими можно заменить VMware vSphere во многих сценариях. Да, переход потребует усилий – от тестирования до обучения персонала, – но выгоды в виде независимости от внешних факторов, соответствия требованиям законодательства и поддержки со стороны локальных вендоров зачастую перевешивают временные сложности. Российские разработчики продемонстрировали способность быстро закрыть функциональные пробелы и даже внедрить новые инновации под нужды рынка. В ближайшие годы можно ожидать дальнейшего роста качества этих продуктов: уже сейчас виртуализация перестает быть "экзотикой" и становится обыденным, надёжным инструментом в руках отечественных ИТ-специалистов. А значит, корпоративный сектор России получает реальную альтернативу VMware – собственный технологический базис для развития ИТ-инфраструктуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VMware Aria Operations -> VCF Operations

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

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

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

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

Aria Operations for Logs -> VCF Operations for Logs

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

Aria Operations for Network Insights -> VCF Operations for Network

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

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

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

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

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

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

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

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

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

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

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

VMware HCX -> VCF Operations HCX

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

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

Aria Automation -> VCF Automation

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

Aria Automation Orchestrator -> VCF Operations Orchestrator

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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