VMGU.ru - технологии виртуализации и виртуальные машины

Обновление серверов в существующем кластере VMware vSAN

Thu, 06 Aug 2026 08:45:02 UTC

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

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

Варианты обновления серверов внутри кластера vSAN

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

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

Под выводом из эксплуатации здесь понимается перевод одного из старых хостов в режим обслуживания с принудительным пересозданием данных в другом месте, чтобы восстановить заданный уровень отказоустойчивости. После завершения этой операции хост удаляется из кластера нажатием «Remove from inventory» в vSphere Client.

Какой подход оптимален? Ответ зависит от особенностей конкретной среды, поэтому стоит рассмотреть каждый из вариантов подробнее.

Как vSAN распределяет данные по кластеру

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

Менеджер объектов vSAN определяет размещение данных при развёртывании, эвакуации и ребалансировке, опираясь на следующие критерии:

Хосты, пригодные для размещения данных. vSAN применяет логику anti-affinity для избыточных данных, гарантируя, что компоненты объекта, обеспечивающие отказоустойчивость (зеркалированные данные или данные чётности при использовании кода коррекции ошибок), никогда не окажутся на одном и том же хосте.
Доступная ёмкость хоста внутри кластера vSAN. vSAN отдаёт предпочтение хостам с большим объёмом свободного пространства перед хостами, где его меньше.

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

Рисунок 1. Принцип перераспределения данных в vSAN при выводе хоста из эксплуатации.

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

Вариант 1: массовое добавление и поэтапный вывод

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

Преимущества. Такой подход работает при наличии свободных физических ресурсов. Правила размещения данных vSAN обрабатывают эту ситуацию максимально просто. При окончательном выводе хоста данные будут пересозданы на одном из новых хостов, поскольку: 1) новые хосты подходят для приёма мигрирующих данных, так как это не нарушает правил анти-аффинности и сохраняет отказоустойчивость и доступность; 2) новые хосты обладают большим объёмом свободной ёмкости, чем старые. Это снижает вероятность повторного перемещения уже перенесённых данных при выводе следующих хостов.

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

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

Вариант 2: поэтапное добавление и поэтапный вывод

В этом сценарии после добавления в кластер одного нового хоста из него выводится один старый. Цикл повторяется до завершения обновления.

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

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

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

Вариант 3: групповое добавление и поэтапный вывод

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

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

Недостатки. Потребуется больше физических ресурсов (места в стойках, электропитания и сетевых портов), чем при варианте 2, но существенно меньше, чем при варианте 1.

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

Заключение

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

Развёртывание NVIDIA Run:ai на VMware Cloud Foundation - часть 2

Tue, 04 Aug 2026 09:03:13 UTC

После установки плоскости управления, кластерного компонента и Knative Serving стек готов принимать нагрузки. Приведённые ниже тесты сквозным образом проверяют три типа нагрузок (инференс, рабочая среда, обучение) с помощью CLI runai версии 2 и подтверждают, что планирование GPU, автомасштабирование Knative и внешняя связность работают. Каждый тест содержит явные шаги проверки, чтобы оператор понимал, что тест пройден. Все три теста самодостаточны и после проверки могут быть свёрнуты.

Развёртывание NVIDIA Run:ai на VMware Cloud Foundation - часть 1

Tue, 04 Aug 2026 08:54:24 UTC

Предприятиям, которые запускают AI в собственных дата-центрах, нужно частное облако, где под единой панелью управления живут и традиционные приложения, и нагрузки с GPU-ускорением. Таким частным облаком выступает VMware Cloud Foundation (VCF), а в связке с VMware vSphere Kubernetes Service (VKS) как штатной средой исполнения Kubernetes и с VMware Private AI Foundation with NVIDIA он превращается в готовую к работе с GPU платформу для AI. Поверх этого фундамента располагается NVIDIA Run:ai — слой оркестрации..

Восстановление SQL Server на момент времени в VMware Data Services Manager 9.1

Fri, 31 Jul 2026 13:35:52 UTC

В версии VMware Data Services Manager 9.1 поддержка Microsoft SQL Server переведена в статус общей доступности на платформе VCF — продукт полностью поддерживается и готов к промышленным нагрузкам.

В демонстрации, подготовленной Эриком Греем (Eric Gray) из подразделения технического маркетинга VCF, показан полный цикл восстановления базы данных на произвольный момент времени. В стенде уже развёрнут промышленный кластер Always On availability group из трёх узлов, на котором работают базы данных. Задача — восстановить одну из этих баз на конкретный момент времени для отладки, не изменяя и не затрагивая работающий кластер.

Исходное состояние стенда

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

Основное внимание в демонстрации уделяется SQL Server. В окружении уже работает один экземпляр SQL Server, и его можно рассмотреть подробнее.

Одна из особенностей, отличающих SQL Server от СУБД с открытым исходным кодом в DSM, — намеренно проведённое разделение между базовым экземпляром (instance) и пользовательской базой данных. На скриншоте видно, что базовый экземпляр состоит из трёх узлов и представляет собой кластер Always On availability group. Он интегрирован с Active Directory, работает под управлением SQL Server 2022 с накопительным обновлением и находится в использовании.

На этом экземпляре размещены две пользовательские базы данных, названные в честь деревьев — spruce и pine. В рамках операции демонстрируется восстановление базы pine на момент времени с размещением копии на новом базовом экземпляре, предназначенном для отладки.

Создание нового экземпляра SQL Server

Первым шагом создаётся новый экземпляр SQL Server — так не придётся вмешиваться в существующий трёхузловой HA-кластер. Экземпляру задаётся имя (в демонстрации используются названия штатов), после чего выбирается редакция. Для решаемой задачи достаточно редакции Developer, однако DSM предлагает и другие варианты — на случай, если требуются возможности уровня Enterprise.

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

Интеграция с Active Directory

Здесь проявляется одно из ключевых преимуществ связки DSM и Microsoft SQL Server — работа с Active Directory. В качестве подготовительного шага интеграция с AD в DSM уже настроена: указаны имя домена и учётные данные. Поэтому при создании нового экземпляра достаточно выбрать опцию присоединения к домену.

Для этого указывается заранее созданная на стороне AD учётная запись с необходимыми правами и включается запись DNS-имён. Задаётся IP-адрес сервера AD, выполняющего роль DNS-сервера, и вводится полное доменное имя (FQDN). DSM самостоятельно создаст прямую и обратную записи для этого FQDN, благодаря чему к экземпляру можно будет обращаться по имени, а не по IP-адресу.

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

Топология развёртывания и инфраструктурные политики

Рассмотренный ранее экземпляр использовал трёхузловую конфигурацию Always On availability group — кластер для обеспечения высокой доступности и отработки отказов. Для текущего проекта, связанного только с восстановлением ради отладки, высокая доступность не нужна, поэтому создаётся одиночный виртуальный экземпляр SQL Server.

В DSM существует понятие инфраструктурных политик — это ресурсы, на которых выполняются сами базы данных. Доступны два варианта: пространство имён vSphere либо политика, создаваемая в клиенте vSphere, — так называемая DSM managed policy. Она представляет собой набор ресурсов: кластер, пул IP-адресов, набор классов виртуальных машин. Эти ресурсы создаёт администратор vSphere, и они становятся местом размещения базы данных.

Пространство имён vSphere в данном стенде было создано в VCF Automation для другого проекта, поэтому оно не используется — выбор делается в пользу политики DSM. Соответствующая политика хранения подставляется автоматически, остаётся выбрать класс виртуальной машины. Произвольные значения CPU и памяти задать нельзя: выбор ограничен классами, подготовленными администраторами. В данном случае четырёх vCPU и 8 ГБ оперативной памяти более чем достаточно.

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

После итогового просмотра всех параметров запускается создание экземпляра. Процесс занимает несколько минут: в фоновом режиме на инфраструктуре vSphere разворачивается новая виртуальная машина, внутри неё устанавливается Microsoft SQL Server, после чего экземпляр вводится в работу.

Настройка политики сервиса данных

Следующий шаг — получить доступ к новому экземпляру баз данных в DSM. Доступ полностью управляется через концепцию политик сервисов данных (data service policies). В рассматриваемом окружении политика для SQL Server уже существует, поэтому вместо создания новой достаточно отредактировать имеющуюся. Эта политика определяет, кто, что и где может запускать.

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

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

Новый одноузловой SQL Server будет использоваться временно и, скорее всего, впоследствии удалён, поэтому резервное копирование для него делать необязательно. Политика меняется с режима «требовать резервные копии», который необходим при использовании варианта с HA-кластером, на режим «разрешать резервные копии». В результате базы данных на HA-кластере продолжают резервироваться, а для одиночного экземпляра резервное копирование можно не задействовать.

Типы аутентификации остаются без изменений — разрешены оба: Windows Active Directory и связка «имя пользователя и пароль SQL Server». Второй вариант считается менее безопасным, но зачастую более удобным, поэтому пока допускаются оба. После краткой проверки настроек политика сохраняется и готова к использованию.

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

Далее выполняется возврат к разделу SQL Server и переход на вкладку баз данных, где видны две работающие пользовательские базы. Из существующей базы данных запускается восстановление на определённый момент времени.

Это востребованная возможность. Например, произошло повреждение данных или кто-то внёс изменения, и требуется вернуться назад, чтобы понять, как база выглядела в определённый момент, — ради отладки. В мастере выбирается вариант Custom Time вместо восстановления на последнюю доступную точку, после чего указываются нужные дата и время.

Копия разворачивается не поверх существующего экземпляра, где работает «живая» база, а на новом экземпляре arizona, созданном ранее. База при этом переименовывается — так её проще запомнить.

Имя пользователя не меняется: используется аутентификация Windows и учётная запись Active Directory с именем DBA. Резервные копии для этой базы отключаются, чтобы не засорять корзину S3, — база всё равно будет удалена через день-два. После итогового просмотра параметров запускается восстановление. В результате в среде появляется третья база данных SQL Server, размещённая на другом сервере SQL Server и готовая к работе.

Подключение через SQL Server Management Studio

Дальнейшая работа переносится на рабочий стол Windows, где выполнен вход под той самой доменной учётной записью DBA. Заранее открыта SQL Server Management Studio, в которой уже указано полное доменное имя только что созданного экземпляра базы данных. Соответствующая запись в DNS присутствует — её автоматически создал DSM.

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

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

Итог

Показанный сценарий представляет собой восстановление базы данных SQL Server на момент времени с размещением на полностью изолированном экземпляре. Промышленный кластер при этом не был затронут.

DSM самостоятельно подготовил целевой экземпляр, присоединил его к Active Directory, автоматически зарегистрировал DNS-запись и восстановил базу данных на точно указанную метку времени. Администратор базы данных подключился с использованием аутентификации Windows — без необходимости управлять паролями. Ручных операций с инфраструктурой и заявок в поддержку не потребовалось.

Именно так выглядит управление жизненным циклом SQL Server на платформе VCF в DSM 9.1: автоматизированно, управляемо и с готовностью к промышленной эксплуатации.

VCF Inspector — автономный инструмент диагностики для VMware Cloud Foundation 9.1

Thu, 30 Jul 2026 09:09:00 UTC

Состоялся анонс средства VMware VCF Inspector — нового автономного средства диагностики, проверки состояния и устранения неполадок, созданного специально для VMware Cloud Foundation (VCF) 9.1 и служб управления VCF (VCF management services).

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

Модуль VCF Inspector уже доступен для бесплатной загрузки на портале Broadcom Support Portal в разделе VMware Flings.

Зачем понадобился VCF Inspector

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

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

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

Проактивная проверка готовности к обновлению: автоматизированный способ в один клик убедиться в соответствии парольных политик требованиям, готовности хостов, доступности сети и валидности сертификатов до запуска обновления до VCF 9.1
Прозрачность развёртывания и обновления: сводная временная шкала хода установок и обновлений VCF в реальном времени, дающая командам ясное представление о выполнении подзадач и автоматические подсказки по первопричинам сбоев без ручного поиска по журналам на узлах управляющей плоскости
Мгновенная диагностика режима day-2: структурированная проверка состояния всех служб платформы, позволяющая отслеживать состояния сервисов, динамику перезапусков и релевантные рекомендации из базы знаний в едином интерфейсе

Все три возможности флинг VCF Inspector реализует в одном исполняемом файле, рассчитанном на запуск с рабочей станции администратора или с jumpbox-хоста.

Ключевые возможности и сценарии применения

VCF Inspector поддерживает три основных сценария «из коробки»:

1. Оценка готовности к обновлению VCF 9.1

Теперь не требуется быть экспертом по документации VCF или разбираться в каждой статье базы знаний (KB). Инструмент выполняет набор автоматизированных предварительных проверок в отношении SDDC Manager и vCenter до запуска обновления VCF. Проверяются:

Соответствие парольным политикам и сроки истечения учётных записей
Состояние хостов и готовность кластеров vSphere
Доступность необходимых сетевых портов (SSH 22, HTTPS 443, Platform API 5480, Cluster API 6443)
Статус активных задач управления жизненным циклом и пороговые значения истечения сертификатов
Выдача конкретных рекомендаций по устранению для непройденных проверок

2. Мониторинг развёртывания и обновления в реальном времени

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

Временная шкала подзадач SDDC Manager и стадий Bootstrap в реальном времени
Автоматическое обнаружение зависших задач и извлечение первопричины ошибок
Прямые ссылки на статьи базы знаний Broadcom по известным проблемам развёртывания
Расчёт длительности стадий и фильтрация по стадиям
Расширенный мониторинг задач развёртывания служб управления VCF

3. Диагностика и контроль состояния служб управления VCF в режиме day-2

Проверка состояния всех работающих служб платформы выполняется без какой-либо настройки:

Мгновенная проверка состояния сервисов: сгруппированное представление служб управления VCF (управление журналами, управление жизненным циклом флота, VCF Automation, брокер идентификации, компоненты VMware Salt for VCF, телеметрия) с индикаторами состояния.
Обнаружение пулов IP и FQDN платформы: развёрнутая таблица соответствий VIP-адресов управляющей плоскости, IP-адресов рабочих узлов, канонических FQDN и служб LoadBalancer.
Схема топологии узлов: визуальная матрица узлов управляющей плоскости и рабочих узлов с отображением размещения компонентов и их статуса.
Анализатор журналов и диагностика компонентов: выявление недавних шаблонов ошибок и предупреждений в журналах служб платформы с мгновенной диагностикой компонентов и журналами выполнения в отдельном окне с деталями.
Административные действия по устранению неполадок: обновление сертификатов cert-manager, поочерёдный перезапуск DNS, уплотнение системной базы данных и проверка сетевой доступности — всё в один клик и под защитой интерактивной блокировки с подтверждением.
Безопасная консоль терминала: консоль для продвинутых пользователей со строгой проверкой команд только на чтение, что разрешает безопасные запросы статуса и блокирует деструктивные операции.

Обзор служб управления VCF:

Действия по устранению неполадок и контролируемая консоль:

Расширенное устранение неполадок:

Как начать работу

Запуск VCF Inspector занимает считанные минуты:

Загрузка бинарного файла: нужно перейти на портал Broadcom Support Portal, раздел Free Downloads / VMware Flings и скачать единственный бинарный файл для своей операционной системы (vcf-inspector-darwin-arm64-native, vcf-inspector-windows-amd64-native.exe или vcf-inspector-linux-amd64).
Выдача прав на выполнение и запуск:
- macOS/Linux: в терминале выполнить chmod +x ./vcf-inspector-darwin-arm64-native, затем запустить ./vcf-inspector-darwin-arm64-native.
- Windows: дважды кликнуть по vcf-inspector-windows-amd64-native.exe.
Подключение к среде:
- Ввести IP-адрес или FQDN любого узла управляющей плоскости VCF (либо SDDC Manager).
- Указать учётные данные vmware-system-user (или администратора SDDC Manager).
- VCF Inspector установит защищённую сессию и автоматически заполнит все панели состояния.

Итоги и обратная связь

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

Что нового в VMware HCX 9.1: ключевые возможности

Mon, 27 Jul 2026 01:03:29 UTC

Решение VMware Cloud Foundation Operations HCX 9.1 включено в состав платформы VCF 9.1 и развивает линейку инструментов мобильности рабочих нагрузок. В новой версии переработана архитектура транспортных устройств, управление жизненным циклом полностью переведено в VCF Operations, усилены механизмы безопасности и соответствия требованиям, а также расширены возможности миграции и поддержка гостевых операционных систем. Ниже разобраны основные нововведения. Полное описание доступно в официальной документации по мобильности рабочих нагрузок.

Оптимизированная архитектура устройств IX и NE

Ключевое нововведение версии — новая оптимизированная (enhanced) архитектура устройств HCX Interconnect (IX) и Network Extension (NE), обеспечивающая более высокую производительность передачи данных между площадками.

Начиная с версии 9.1, все вновь создаваемые сервисные сети (Service Mesh) автоматически разворачиваются на базе оптимизированной архитектуры. Устройства, развёрнутые в предыдущих версиях, продолжают работать на прежней (legacy) архитектуре до тех пор, пока не будут переведены на новую через процедуру миграции расширений сети (Migrating Network Extensions).

Дополнительно версия отказывается от самоуправляемых устройств на базе PhotonOS в пользу стека NSX Edge, который обеспечивает более высокую производительность и устраняет избыточность поддержки двух функционально эквивалентных сетевых стеков. Для перевода устройств PhotonOS на архитектуру NSX Edge в HCX 9.1 предусмотрен автоматизированный сценарий миграции. Поддержка PhotonOS-устройств объявлена устаревшей, полное удаление запланировано на VCF 10.0.0.

Развёртывание и управление жизненным циклом через VCF Operations

HCX 9.1 становится неотъемлемой частью платформы VCF: развёртывание, управление и обновление HCX Manager теперь выполняются непосредственно из VCF Operations. Установочные дистрибутивы загружаются в экземпляр VCF, после чего устройство разворачивается через централизованный интерфейс без ручных операций с OVA на целевой стороне.

Загрузка дистрибутивов VMware Cloud Foundation Operations HCX из консоли VCF Operations:

Установка HCX Manager как дополнительного компонента домена прямо из интерфейса VCF Operations:

Экземпляры HCX Manager, развёрнутые вручную (например, в устаревшей исходной среде за пределами VCF), можно подключить (onboard) и в дальнейшем управлять ими из VCF Operations. Основные возможности блока управления жизненным циклом:

Управление жизненным циклом (LCM): развёртывание, обслуживание и обновление HCX Manager выполняются через VCF Operations.
Пакет управления VCF Operations HCX Management Pack: новый пакет для установки в VCF Operations, обеспечивающий критически важные сервисы — ротацию паролей локальных пользователей, ротацию сертификатов и сбор диагностических журналов. Пакет несовместим с прежним пакетом управления HCX для vRealize Operations.
Идентификация и доступ: поддержка единого входа VCF Single Sign-On (SSO) и ролей VCF для унифицированной аутентификации и авторизации в веб-интерфейсе и API HCX Manager.

Завершение мастера развёртывания HCX Manager, запускающего автоматизированную установку:

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

Сертификация FIPS 140-3: HCX теперь сертифицирован по стандарту FIPS 140-3, что соответствует строгим требованиям к безопасности.
Неразрывное управление сертификатами (NDC): новые REST API HCX Manager позволяют управлять сертификатами HCX без нарушения доверия со стороны клиентов.
Сетевая безопасность: порты HCX добавлены в список исключений распределённого межсетевого экрана (DFW); между оптимизированными устройствами IX и NE используется стандартный трафик IPsec.

Улучшения миграции и Interconnect

Оптимизация WAN: возвращена функция эффективной оптимизации WAN, встроенная непосредственно в конфигурацию сервисной сети HCX Interconnect. Возможность доступна исключительно для оптимизированных сервисных сетей и не поддерживается для миграций OSAM и HAV.
Локальные миграции в пределах площадки: поддержка миграций без развёртывания устройств внутри одного экземпляра vCenter с помощью HCX Assisted vMotion (HAV) — источник и приёмник могут быть одним и тем же экземпляром.
Расширенная поддержка хранилищ и правил: поддержка нестандартных политик хранения при «холодных» (Cold) миграциях, а также возможность выбирать несколько целевых хранилищ данных для одной виртуальной машины (кроме OSAM).
Расширения VLAN-сетей: поддержка расширения VLAN-сетей на нативные распределённые группы портов (DVPG) на целевой площадке.
Обновлённый веб-интерфейс: переработанный и дополненный пользовательский интерфейс.

Расширенная поддержка гостевых ОС

Список поддерживаемых операционных систем для кастомизации гостевой ОС и миграции с помощью агента (OS Assisted Migration, OSAM) расширен:

Кастомизация гостевой ОС и массовая (Bulk) миграция теперь поддерживают Windows Server 2022.
Миграция OSAM теперь поддерживает Windows Server 2022 и Windows Server 2025.

Устаревшие функции

В рамках упрощения продукта в версии 9.1 объявлен отказ от ряда возможностей:

Устройства на базе PhotonOS: поддержка самоуправляемых устройств PhotonOS объявлена устаревшей с версии 9.1.0, полное удаление намечено на VCF 10.0.0. Предусмотрен автоматизированный переход на архитектуру NSX Edge.
VMware Cloud Director (VCD): поддержка VCD в VCF Operations HCX объявлена устаревшей с версии 9.1.0. Поскольку VCD не поддерживается в VCF 9, для переноса рабочих нагрузок в VCF Automation 9 внедряется новый инструмент импорта. Полное удаление запланировано на VCF 9.2.0.

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

Ускоренное устранение уязвимостей в VCF 9.1 с минимумом простоев

Fri, 24 Jul 2026 14:37:44 UTC

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

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

Трёхуровневая архитектура, рассчитанная на скорость и стабильность

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

Уровень управления — VCF Management Services, VCF Operations, VCF Automation, Cloud Proxy, VCF Operations for Networks.
Уровень плоскости управления — vCenter, NSX Manager, vSphere Supervisor и VMware vSphere Kubernetes Service (VKS).
Уровень плоскости данных — ESX, vSAN, NSX Edge и прочее.

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

Стратегия обновления под каждый уровень

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

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

Уровень плоскости управления остаётся доступным во время обновлений, так что vCenter, NSX и управление Kubernetes продолжают работать. Поскольку от этого уровня зависит каждая операция, простой сводится к минимуму механизмами, подобранными под тип патча: vCenter Quick Patch для исправлений безопасности и мелких доработок, Reduced Downtime Upgrade для перехода между версиями, а также плавающие обновления для кластеров vSphere Supervisor и VKS. Управление NSX сохраняет доступность на всём протяжении процесса за счёт того, что как минимум два узла остаются активными.

Уровень плоскости данных — это среда исполнения рабочих нагрузок, и к нему предъявляются самые жёсткие требования. Задача состоит в том, чтобы обновить хосты, не нарушив работу этих нагрузок. Технология ESX Live Patch применяет исправления непосредственно в памяти — без окна обслуживания, без эвакуации виртуальных машин и без перезагрузки, а в VCF 9.1 её действие распространено и на хосты с включённым TPM. Когда перезагрузки избежать не удаётся, влияние минимизируют Quick Boot, предварительная подготовка образов и эвакуация нагрузок через живую миграцию vMotion.

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

Скачать новый технический документ о быстрой установке патчей безопасности в VCF 9.1 без прерывания работы.

Декларативное управление жизненным циклом

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

Итог

Необновлённая инфраструктура — это обязательство, объём которого теперь растёт с каждым часом. VCF 9.1 помогает снять многие операционные препятствия, которые прежде вынуждали выбирать между реакцией на угрозу и доступностью рабочих нагрузок. Благодаря специализированному инструментарию для плоскостей управления, контроля и данных программное обеспечение VMware предлагает целостную интегрированную архитектуру обновления всего программно-определяемого центра обработки данных — быстро, единообразно и без прерывания работы.

Вопрос для инфраструктурных команд больше не в том, стоит ли обновляться быстро. Вопрос в том, зачем ждать. Подробности изложены в документе "Rapid Non-Disruptive Security Patching - VMware Cloud Foundation 9.1".

Мобильность рабочих нагрузок с VCF Operations HCX 9.1: развёртывание (часть 1)

Fri, 24 Jul 2026 08:57:25 UTC

p>Это пошаговое руководство описывает, как развернуть HCX Manager в среде VCF 9.1, а также в устаревшей (legacy) инфраструктуре. Материал содержит полное описание всех этапов процесса и сопровождается видеозаписью, охватывающей каждый шаг. Для администратора эффективная и безопасная миграция рабочих нагрузок внутри центров обработки данных и между ними является фундаментальной частью стратегии частного облака.

Каталог контента VMware Explore 2026 уже доступен

Mon, 20 Jul 2026 18:12:35 UTC

Недавно VMware сделала доступным каталог контента VMware Explore 2026 - пора приступать к формированию персональной программы конференции. Мероприятие пройдет с 31 августа по 3 сентября 2026 года в Лас-Вегасе, в конференц-центре The Venetian. Независимо от того, интересует ли вас тематика частного AI или модернизация инфраструктуры частного облака, в каталоге найдется контент для любого ИТ-специалиста — и его действительно много.

Четыре трека — одна облачная стратегия

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

Cloud Infrastructure - модернизация инфраструктуры, операционных моделей и приложений.
App Modernization - ускорение разработки и доставки приложений.
Security - безопасная работа приложений за счет интеллектуальной автоматизации сети.
Innovation - свежие идеи для инноваций и карьерного роста.

Как эффективно работать с каталогом

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

Трек — Cloud Infrastructure, Modern Apps, Innovation или объединенный Networking, Security & Load Balancing.
Тип сессии — доклады (Breakouts), туториалы, короткие выступления (Quick Talks) и другие форматы.
Технический уровень — от вводного бизнес-уровня (Business 100) до экспертного (Technical 300).
Продукты — как хорошо знакомые, так и новые решения.

Полезное: у любой сессии в каталоге можно нажать значок сердечка и добавить ее в избранное, собрав собственную программу (потребуется вход в учетную запись). Когда 21 июля откроется запись на сессии, ваш план уже будет готов.

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

Дополнительные возможности

Параллельно с открытием каталога проходило голосование People's Choice Awards: участники выбирали по одной сессии в каждом треке, помогая организаторам заполнить оставшиеся слоты программы с учетом интересов аудитории. Прием голосов завершился 10 июля 2026 года.

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

Наконец, открытый каталог с техническими сессиями — весомый аргумент для согласования поездки с руководством. Набор материалов Convince Your Manager поможет связать контент Explore с бизнес-целями команды и получить одобрение на участие.

Вышел документ Performance Best Practices for VMware vSphere 9.1

Fri, 17 Jul 2026 10:09:25 UTC

Компания VMware объявила о доступности документа Performance Best Practices for VMware vSphere 9.1. Это подробное руководство, призванное помочь системным администраторам добиться максимальной производительности своих развёртываний платформы vSphere 9.1.

В документе (а лучше сказать - книге) рассматриваются новые возможности платформы, а также обновляются и расширяются темы, освещавшиеся в предыдущих версиях Performance Best Practices for VMware vSphere.

Основные темы документа

Расширенные рекомендации по управлению питанием, включая C-states и технологию Intel Hardware P-States (HWP)
Расширенные рекомендации для конкретных семейств процессоров, включая Intel Granite Rapids и AMD EPYC
Новый раздел об использовании Intel QAT для снижения нагрузки на CPU при шифрованном vMotion
Новое обсуждение аппаратной локальности в NUMA-системах
Расширенное описание многоуровневой памяти (memory tiering)
Расширенные рекомендации по производительности NVMe
Дополнительные подробности о технологии Receive Side Scaling (RSS)
Расширенные рекомендации по vSAN Express Storage Architecture (ESA)
Расширенное описание VCF Single Sign-On
Рекомендации по выбору оборудования для хранилищ
Рекомендации по выбору сетевого оборудования
Технология Hyper-Threading
NUMA и vNUMA
Определение объёма памяти, переподписка (overcommit), разделение страниц (page sharing) и оптимизации свопинга
Производительность хранилищ VMware vSAN, SAN, iSCSI, NFS, NVMe и NVMe over Fabrics
Рекомендации по шифрованию виртуальных машин
Производительность сети
Работа с нагрузками, чувствительными к задержкам хранилища
Работа с нагрузками, чувствительными к сетевым задержкам
Network I/O Control (NetIOC)
DirectPath I/O
Microsoft Virtualization-Based Security (VBS)
Выбор виртуальных сетевых адаптеров
Производительность базы данных vCenter
Производительность vSphere Client
vMotion, Storage vMotion и Cross-Host Storage vMotion
Distributed Resource Scheduler (DRS) и Distributed Power Management (DPM)
vSphere High Availability и Fault Tolerance
VMware vSphere Lifecycle Manager
VMware VCF Single Sign-On
vSphere Content Library
vSphere Kubernetes Service (VKS)

Полная версия документа доступна по этой ссылке.

Балансировка нагрузки в vSphere 9.0 и VMware Cloud Foundation 9.0

Tue, 14 Jul 2026 17:28:23 UTC

Если вы управляете Kubernetes вместе с традиционными виртуальными машинами, vSphere Supervisor в vSphere 9.0 и VMware Cloud Foundation (VCF) 9.0 служит единой плоскостью управления. Но когда дело доходит до настройки инфраструктуры, у команд, проектирующих такие среды, всегда возникает один и тот же вопрос:

«Какие балансировщики нагрузки поддерживаются и как выбрать правильный для моего vSphere Supervisor?»

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

Основные варианты организации платформенного балансировщика нагрузки

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

1. Foundation Load Balancer и NSX Load Balancer: связность L4 из коробки

Если вам нужна интегрированная балансировка нагрузки на уровне Layer 4 (IP:порт) сразу после установки, основными вариантами платформенного балансировщика являются Foundation Load Balancer (FLB) и NSX Load Balancer (NSX-LB). Оба обеспечивают нативную связность L4 для рабочих нагрузок, управляемых Supervisor.

Какой из них использовать — зависит от вашего окружения:

FLB: включён из коробки и доступен как с лицензией VMware vSphere Foundation (VVF), так и с VCF.
NSX-LB: включён в состав VCF для сред, использующих сети NSX.

Оба платформенных балансировщика обеспечивают связность L4 для рабочих нагрузок под управлением Supervisor, включая:

Виртуальные машины VM Service: ВМ, развёрнутые через VM Service в пространство имён vSphere Namespace.
vSphere Pods: контейнерные нагрузки, работающие непосредственно на гипервизоре ESX.
Кластеры vSphere Kubernetes Service (VKS): CNCF-совместимые кластеры Kubernetes и приложения, работающие внутри них.

А что насчёт маршрутизации Layer 7 (уровень приложений)?

FLB и NSX-LB предоставляют сервисы L4 на уровне платформы, но команды приложений по-прежнему могут использовать Kubernetes-нативные решения для ingress и управления трафиком, такие как Contour, Istio и Gateway API, внутри кластеров VKS. Это открывает возможности Layer 7, включая маршрутизацию HTTP, маршрутизацию по путям и терминацию TLS с помощью привычных инструментов Kubernetes.

2. Avi Load Balancer: продвинутое управление трафиком корпоративного класса

Для организаций, которым нужны развитые контроллеры доставки приложений (ADC) во всей облачной инфраструктуре, Avi Load Balancer (Enterprise Edition) расширяет платформу возможностями управления трафиком на уровне L7, безопасности и аналитики.

Когда Avi Enterprise выбран в качестве платформенного балансировщика для vSphere Supervisor, он добавляет продвинутые сервисы доставки приложений на уровне платформы, включая:

Управление трафиком Layer 7: продвинутая маршрутизация HTTP/HTTPS, переключение контента и управление трафиком на основе политик.
Web Application Firewall (WAF): интеллектуальная распределённая защита от уязвимостей и веб-эксплойтов на границе.
Расширенный мониторинг и аналитика: видимость производительности приложений, сквозных задержек и паттернов пользовательского трафика в реальном времени.
Интегрированный DNS и Global Server Load Balancing (GSLB): доступность на нескольких площадках и распределение трафика между географически разнесёнными локациями.

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

Выбор платформенного балансировщика по типу сети рабочих нагрузок

Архитектура сети рабочих нагрузок определяет, какие варианты платформенного балансировщика доступны при развёртывании vSphere Supervisor. Сетевые модели соотносятся с поддерживаемыми балансировщиками следующим образом:

vSphere Distributed Switch (VDS): поддерживает Foundation Load Balancer (FLB) или Avi Load Balancer — для сред с традиционными сетями vSphere.
Сегмент NSX: поддерживает NSX Load Balancer или Avi Load Balancer — для сред с сетями NSX.
NSX Virtual Private Cloud (VPC): поддерживает Avi Load Balancer и предназначен для cloud-native сред, использующих сети NSX VPC.

Гибкость на уровне кластеров VKS

Одна из сильных сторон VKS заключается в том, что выбор платформенного балансировщика для Supervisor не ограничивает варианты балансировки, доступные рабочим нагрузкам внутри кластеров VKS.

Поскольку кластеры VKS — это upstream-совместимые кластеры Kubernetes, они поддерживают стандартные ingress-контроллеры Kubernetes, реализации балансировщиков и другие Kubernetes-нативные решения доставки приложений.

Это позволяет инфраструктурным командам стандартизироваться на FLB, NSX-LB или Avi на уровне платформы, оставляя командам приложений свободу выбирать решение доставки приложений, которое лучше всего подходит их нагрузкам.

Краткое сравнение платформенных балансировщиков

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

Функция / возможность	Foundation Load Balancer (FLB)	NSX Load Balancer (NSX-LB)	Avi Load Balancer (Enterprise)
Поддерживаемые типы сетей	VDS	Сегмент NSX или NSX VPC	VDS, сегмент NSX или NSX VPC
Основной уровень маршрутизации	Layer 4 (IP:порт)	Layer 4 (IP:порт)	Layer 4 и Layer 7
Требуемая лицензия	VVF или VCF	VCF	Лицензия Avi Enterprise
Ingress / WAF из коробки	Нет (используется VKS Ingress)	Нет (используется VKS Ingress)	Да (нативные функции платформы)
Расширенная аналитика и GSLB	Нет	Нет	Да
Переопределение на уровне VKS	Да	Да	Да

Заключение

Выбор правильного платформенного балансировщика в конечном счёте сводится к архитектуре сети рабочих нагрузок и операционным требованиям. Нужна ли вам интегрированная связность L4 с FLB или NSX-LB, либо продвинутая доставка приложений на уровне L7 с Avi — vSphere Supervisor предлагает поддерживаемый путь для каждой модели развёртывания.

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

Пошаговые инструкции по развёртыванию и предварительные требования для конкретного типа сети приведены в полном руководстве vSphere Supervisor Installation and Configuration Guide.

Большие страницы памяти и VMware Advanced Memory Tiering

Fri, 10 Jul 2026 16:46:06 UTC

Те, кто уже настраивает VMware Memory Tiering или только присматривается к этой технологии, наверняка задавались вопросом: что происходит с большими страницами памяти (Memory Large Pages)? Вопрос действительно важный, поскольку ответ на него влияет на планирование ёмкости и настройку виртуальных машин. Разберём эту тему подробно.

Немного контекста

Прежде чем переходить к особенностям поведения при многоуровневом хранении памяти, стоит кратко вспомнить, что такое большие страницы (Large Pages) и почему они важны. Архитектура x86 поддерживает три размера страниц: 4 КБ (малые страницы), 2 МБ и 1 ГБ. Два последних размера в совокупности называют «большими страницами». Размер страницы можно сравнить с номиналом купюр в кошельке: крупные купюры удобнее носить с собой, но с них сложнее давать сдачу. Большие страницы работают так же: они снижают нагрузку на TLB (Translation Lookaside Buffer) и уменьшают стоимость обхода таблиц страниц, что даёт потенциальный прирост производительности для нагрузок, интенсивно работающих с памятью. По умолчанию ESX использует страницы размером 2 МБ для виртуальной оперативной памяти гостевых систем, и не случайно: выигрыш в производительности хорошо подтверждён.

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

Memory Tiering меняет правила игры

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

Алгоритм тиринга, встроенный в уровень управления памятью ESX, отслеживает «горячесть» и «холодность» каждой страницы. Активные страницы — рабочий набор виртуальной машины — остаются в Tier 0 (DRAM) для максимальной производительности. Холодные страницы при росте давления на память мигрируют в Tier 1 (NVMe). Всё это происходит интеллектуально, автоматически и не требует ручного вмешательства. Но есть нюанс: для качественной работы алгоритму необходим детальный контроль на уровне мелких блоков.

Как это влияет на большие страницы? Большая страница размером 2 МБ является атомарной единицей — переместить её половину на NVMe невозможно. Весь блок в 2 МБ перемещается целиком либо не перемещается вовсе. Это как пытаться точно регулировать температуру термостатом, который меняет её только с шагом в 10 градусов: работать будет, но без точности. При гранулярности 4 КБ движок тиринга способен принимать хирургически точные решения о том, какие именно страницы горячие, а какие холодные. Именно эта точность обеспечивает высокую эффективность Memory Tiering, поэтому по умолчанию используются малые страницы.

Три сценария размеров страниц

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

Малые страницы 4 КБ: полная оптимизация

Это оптимальный вариант. Производительность специально оптимизирована для страниц 4 КБ при активном Memory Tiering. Алгоритм тиринга работает с максимальной точностью: горячие страницы остаются в DRAM, а холодные плавно выгружаются на NVMe. ESX намеренно отключает большие страницы на уровне хоста, когда настроен Memory Tiering. Чтобы точно отслеживать и перемещать память без огромных накладных расходов на производительность, ESX возвращается к использованию стандартных базовых страниц 4 КБ для гостевой памяти. Работая на уровне 4 КБ с самого начала, движок тиринга ESX избавлен от необходимости постоянно разбивать крупные страницы, чтобы выяснить, какие данные реально используются.

Большие страницы 2 МБ: включение вручную, с оговоркой

Стандартная конфигурация vSphere предполагает включённые большие страницы 2 МБ (параметр Mem.AllocGuestLargePage установлен в 1), однако при активном Memory Tiering страницы 2 МБ по умолчанию не участвуют в тиринге.

Страница 2 МБ состоит из 512 отдельных страниц по 4 КБ. Допустим, 400 из них горячие и активно используются. В идеале такая большая страница должна целиком остаться в DRAM. Но это означает, что оставшиеся 112 холодных страниц тоже застревают в DRAM, хотя могли бы быть выгружены на NVMe. Эти 112 страниц представляют собой заблокированную ёмкость — и это лишь одна большая страница. Умножьте это на любое количество, и станет ясно, что тысячи холодных страниц могут остаться в DRAM вместо выгрузки на NVMe. При гранулярности 4 КБ движок тиринга освободил бы их, а при гранулярности 2 МБ — не может, поскольку перемещение половины большой страницы невозможно.

Чтобы использовать большие страницы 2 МБ вместе с Memory Tiering, необходимо явно задать VMX-параметр виртуальной машины: monitor_control.disable_mmu_largepages = "FALSE". После установки параметра машина попадает в общий пул многоуровневой памяти, и здесь начинается самое любопытное. Когда большие страницы включены, алгоритм тиринга проактивно разбивает часть больших страниц на основе определённых эвристик и либо выгружает холодные страницы из 2-мегабайтного региона, либо собирает его обратно в большую страницу.

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

Страницы 1 ГБ: только DRAM, без исключений

Здесь действует жёсткое правило. Виртуальные машины, настроенные на использование страниц 1 ГБ, автоматически закрепляются за Tier 0 (DRAM) и никогда не будут использовать ёмкость NVMe Tier 1. Memory Tiering применяет это ограничение автоматически, поэтому никакой специальной настройки не требуется. Однако это необходимо учитывать при планировании ёмкости: такие машины следует рассчитывать исходя из доступного объёма DRAM, а не из общей ёмкости многоуровневой памяти. Их стоит выявить заранее.

Аспект TPS

Есть и вторичный эффект, который стоит понимать, особенно если для экономии памяти используется механизм Transparent Page Sharing (TPS). Как включение больших страниц в среде с тирингом влияет на TPS? Как выясняется, плохо.

TPS не дедуплицирует большие страницы напрямую. На современном оборудовании с Intel EPT или AMD RVI, использующем страницы 2 МБ, TPS и так малоэффективен: вероятность найти два идентичных региона по 2 МБ крайне низка, а их сравнение несёт существенные накладные расходы. Прежде чем TPS сможет дедуплицировать большие страницы, их нужно разбить на малые страницы 4 КБ, а это происходит только при определённых состояниях давления на память.

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

Итог

Memory Tiering идёт на осознанный компромисс: жертвует эффективностью TLB, которую дают большие страницы, в обмен на операционную точность, необходимую для интеллектуального размещения данных по уровням. Для большинства нагрузок этот обмен оправдан, тем более что задержки NVMe в Tier 1 продолжают снижаться.

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

Используйте страницы 4 КБ по умолчанию для виртуальных машин, которые должны получать выгоду от тиринга.
Выявляйте машины со страницами 1 ГБ на раннем этапе планирования ёмкости — они потребляют только DRAM.
Тщательно оценивайте машины с большими страницами 2 МБ: сначала тестируйте и не рассчитывайте на те же характеристики производительности, что в среде без тиринга.

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

Новый Container Service в VMware Cloud Foundation 9.1

Wed, 08 Jul 2026 01:57:50 UTC

Введение

Новый сервис Container Service в VMware Cloud Foundation (VCF) представляет собой простую отправную точку для использования Kubernetes (K8s) в компании, не требующую экспертизы в этой области. Многие организации сообщают, что им порой «просто нужно запустить контейнер», что они не могут нанять специалистов для работы с нагрузками в Kubernetes или что они только начинают путь модернизации приложений — берут старые приложения на .Net Framework, рефакторят их на .Net Core и приступают к контейнеризации.

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

Подготовить хостовую ОС
Установить и настроить среду выполнения контейнеров
Настроить аутентификацию в реестре образов
Загрузить и запустить образ контейнера

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

Какова бы ни была причина, заказчики ясно дали понять, что им нужен простой управляемый сервис, позволяющий получить преимущества Kubernetes без рутины и внутренней экспертизы. Поэтому новый Container Service был встроен в VCF Automation (а также в Local Consumption Interface, если VCF Automation не используется), чтобы можно было легко запускать готовые контейнеры. Рассмотрим, как это работает, что умеет сервис и как его можно применять уже сегодня.

Демонстрация

Технический обзор

VCF Container Service — это удобная обёртка вокруг концепции vSphere Pods в кластере Supervisor. vSphere Pods позволяют запускать контейнеры как виртуальные машины, что полезно в целом ряде случаев: когда требуется жёсткая граница ядра между контейнерами, когда не хочется нести накладные расходы на выделенные управляющие плоскости K8s или когда нет желания управлять кластерами K8s и их жизненным циклом.

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

Развернуть контейнер ещё никогда не было так просто

Начать работу очень легко: достаточно передать Container Service образ, совместимый с OCI, и сервис запустит его самостоятельно. При этом конфигурацию можно усложнять по мере необходимости: определять, в какие зоны (Zones) должна быть развёрнута нагрузка, какие ресурсы требуются для её эффективного планирования, а также сколько реплик нужно для этой нагрузки. Сервис даже берёт на себя аутентификацию в OCI-реестре. В результате пользователь получает конечную точку (endpoint), по которой доступно работающее приложение.

Обратите внимание на скриншот ниже: любые настройки, сделанные через UI, автоматически преобразуются в валидный K8s YAML в правой части экрана. Его можно скачать или скопировать и добавить в любую другую систему для воспроизводимых развёртываний. Так же устроены и другие сервисы в интерфейсе VCF, например «Виртуальные машины» или «Кластеры Kubernetes».

Всё, что нужно для старта:

Имя контейнера
URL образа контейнера (например: ghcr.io/nginxinc/nginx-unprivileged)
Заданные запросы CPU и памяти (значения по умолчанию уже установлены)

Всё остальное, описанное ниже, опционально и предназначено для более специфических сценариев.

Расширенные настройки

Если к работе приложения предъявляются особые требования — это не проблема: Container Service отнюдь не ограничен базовыми сценариями. Через сервис доступно практически всё, что может понадобиться контейнерной нагрузке: хранилище, балансировка нагрузки, управление конфигурациями и секретами, настройки среды выполнения вроде переменных окружения и даже sidecar-контейнеры для более продвинутых случаев.

Хранилище

Большинство (полезных) приложений так или иначе хранят состояние. Это не значит, что не бывает полезных приложений без него, но почти каждое приложение как минимум обрабатывает данные, если не хранит их. Поэтому одной из фундаментальных возможностей, которую нужно было представить в понятной форме, стали тома PersistentVolume. В Kubernetes тома PersistentVolume могут вести себя не так, как ожидают пользователи, в зависимости от их политики reclaimPolicy: по умолчанию том удаляется.

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

Возьмём пример StatefulSet с двумя репликами. Если удалить этот StatefulSet, тома сохранятся, и впоследствии, когда пользователь создаст другой экземпляр Container Service с двумя репликами и томами PersistentVolume, ему будет предложен выбор: создать новые тома или примонтировать существующие. Аналогично при уменьшении масштаба тома сохраняются и повторно монтируются при последующем увеличении.

Балансировка нагрузки

Следующий важный компонент любого приложения — то, как оно открывается сети, другим приложениям и пользователям. В K8s это делается с помощью объектов Service и Ingress/Gateway, при этом самый распространённый способ публикации нагрузки — LoadBalancer. Container Service позволяет создать LoadBalancer, выбрать протокол (TCP/UDP), внешний порт и внутренний порт контейнера, если выполняется трансляция портов. Такой Service распределяется по всем репликам данного экземпляра Container Service, обеспечивая доступность и отказоустойчивость при сбое экземпляра или нижележащего узла.

Конфигурация

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

Можно выбрать один из существующих в окружении объектов ConfigMap или создать новый. При создании нового достаточно вставить конфигурационный файл как текст через UI и выбрать способ монтирования — как том (Volume) или как переменные окружения.

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

Секреты

Секреты — API-ключи, токены, пароли и т.п. — критичны для многих приложений. Как и объекты ConfigMap, они передаются в контейнер практически теми же способами: как том или как переменные окружения, причём второй вариант наиболее распространён, поскольку данные никогда не оказываются «на диске» внутри контейнера. Отличие от раздела ConfigMap в том, что под капотом эти данные хранятся как объекты Kubernetes Secret.

Конфигурация среды выполнения

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

Кроме того, если контейнеру или приложению требуется указание, какую команду выполнить при запуске или какие аргументы передать приложению на старте, их можно задать в разделе Command and Arguments, следуя приведённому примеру.

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

Дополнительные контейнеры

Значительно более продвинутая опция — использование sidecar-контейнеров, которые работают рядом с основной нагрузкой в том же поде Kubernetes. Это означает, что под капотом они разделяют некоторые технические характеристики (например, сетевое пространство имён), что позволяет им получать доступ к информации друг друга. Типичные сценарии применения sidecar-контейнеров — сбор логов или метрик, добавление контейнера в сервисную сетку (service mesh) и т.д.

Ещё один пример sidecar-контейнера — InitContainers. Допустим, стек приложения включает базу данных, и при первом запуске нужно выполнить скрипт, который наполнит пустую базу схемой, чтобы приложение могло использовать её при старте. Полезная особенность InitContainers — последовательность выполнения (они блокируют запуск основного контейнера до своего успешного завершения), что помогает гарантировать, например, что база данных запустится раньше основного контейнера.

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

Масштабирование рабочих нагрузок

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

Заключение

Чтобы начать работу с новым Container Service в VCF, попробуйте VCF 9.1, доступный на сайте Broadcom. Техническая документация доступна здесь.

Установка экспресс-патчей в VMware Cloud Foundation 9.1

Mon, 06 Jul 2026 23:09:05 UTC

Риски безопасности, которые создают передовые AI-модели, делают оперативное реагирование на новые угрозы крайне важным. Broadcom предпринимает шаги, чтобы обеспечить готовность VMware Cloud Foundation (VCF) к немедленному патчингу, позволяя организациям быстро реагировать на возникающие угрозы. Это означает, что для VCF 9.1 будут выпускаться более частые ежемесячные Express Patches. В этой статье описывается, как выглядит процесс их накатывания, и показано, как убедиться, что установлены самые последние патчи.

Прежде чем начать, необходимо обновиться до VCF 9.1, поскольку Express-патчи выпускаются именно для этой версии.

Шаг 1: Проверка наличия и загрузка патчей

Первый шаг — проверить наличие новых доступных патчей. Это можно сделать, перейдя в раздел Build > Lifecycle в VMware Cloud Foundation Operations.

При переходе в разделы Patch Binaries или Install Binaries отображаются патчи для всех продуктов, в которых были устранены уязвимости безопасности. В приведённом примере это патч от 4 июня версии 9.1.0.0100.

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

Шаг 2: Обновление управляющих компонентов VCF

После загрузки патчей их можно развернуть сначала для управляющих компонентов VCF, начиная с Fleet Lifecycle. Перейдите в VCF Operations и выберите Build > Lifecycle > VCF Management > Upgrade — на этой странице можно выбрать целевую версию для обновления.

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

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

После выбора версии можно применить патчи. Рекомендуется сначала запустить предварительную проверку (precheck) для всех компонентов, нажав Run Prechecks. Обычно проверка запускается сразу для всех компонентов, после чего исправляются найденные проблемы. Когда все предварительные проверки пройдены успешно, можно нажать Upgrade для обновления компонентов. Обычно выбираются все компоненты сразу, чтобы обновление завершилось максимально быстро.

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

Шаг 3: Обновление основных компонентов VCF

Как и в предыдущих релизах, обновление VMware SDDC Manager, VMware vSphere и VMware NSX происходит по схожему с прошлыми версиями сценарию. В VCF для ускорения развёртывания патчей безопасности используются Live Patching для хостов VMware ESX и Quick Patching для VMware vCenter.

Чтобы применить патчи 9.1.0.0100, снова перейдите в VCF Operations и выберите Build > Lifecycle Management > VCF Instance > Upgrades. Здесь можно нажать кнопку Plan Component Upgrade, чтобы выбрать целевую версию патча и сформировать план обновления.

После того как план создан, можно приступать к обновлению каждого из компонентов.

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

Новые возможности AI-инфраструктуры в VMware Cloud Foundation 9.1

Mon, 29 Jun 2026 10:51:46 UTC

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

Представлена новая версия VMware Cloud Foundation 9.1 Upgrade Planning Tool

Thu, 25 Jun 2026 08:35:15 UTC

Одно из главных преимуществ VMware Cloud Foundation (VCF) 9.1 — гибкость и широкая поддержка уже существующих клиентских сред, что позволяет встретить заказчиков ровно на той точке, где они находятся на пути к частному облаку. Это охватывает самые разные сценарии: от отдельных развёртываний vSphere с VCF Operations до сред с различными комбинациями vSAN, NSX и Aria Automation, вплоть до полнофункционального развёртывания всего стека VCF.

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

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

Объявлено о выпуске инструмента планирования обновлений VCF 9.1, который обеспечивает индивидуально подобранный сценарий планирования и помогает заказчикам уверенно пройти путь обновления VCF.

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

Как только целевой вариант выбран, инструмент планирования обновления VCF формирует исчерпывающий план обновления, который включает:

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

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

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

VMware vSphere Foundation 9.1: обзор новинок и доступные ресурсы

Mon, 22 Jun 2026 14:40:35 UTC

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

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

Если это первое знакомство с vSphere Foundation 9.1, начать стоит с обзорной публикации о выпуске VMware vSphere Foundation 9.1 — в ней подробно описана каждая новая возможность. Настоящий материал является продолжением: это краткая ориентация по трём ключевым областям возможностей вместе с подборкой ресурсов, которые помогут команде перейти от первичного знакомства к этапам оценки и планирования.

Что нового: краткий обзор

Рисунок 1: VMware vSphere Foundation 9.1 переосмысливает экономику инфраструктуры, резко сокращая эксплуатационные простои и обеспечивая более высокую производительность рабочих нагрузок.

VMware vSphere Foundation 9.1 приносит усовершенствования по трём стратегическим направлениям. В обзорной публикации каждое из них рассмотрено детально; ниже приводится краткое резюме для ориентации и для указания на наиболее релевантные ресурсы из перечисленных далее.

Повышение операционной эффективности и снижение TCO. Встроенная высокоточная наблюдаемость и функция Proactive Diagnostic Insights теперь располагаются непосредственно в основной консоли эксплуатации, объединяя то, что прежде требовало нескольких разрозненных инструментов. Усовершенствованное многоуровневое размещение памяти на NVMe (NVMe Memory Tiering) добавляет высокопроизводительный второй уровень памяти, который интеллектуально берёт на себя от 20 до 25 процентов обращений к памяти, снижая TCO сервера и повышая плотность размещения виртуальных машин без ущерба для отзывчивости приложений.
Кардинальный рост производительности рабочих нагрузок. Планирование с учётом топологии (vSphere Topology-Aware Scheduling) применяет логику, учитывающую устройство процессора, для оптимизации размещения NUMA на процессорах высокой плотности, удерживая ресурсоёмкие приложения на пике производительности. Параллельная обработка миграций DRS vMotion устраняет последовательное узкое место при балансировке кластера, обеспечивая более быструю и непрерывную мобильность рабочих нагрузок. Расширенное сокращение данных vSAN (vSAN Data Reduction) даёт снижение TCO хранения до 39 процентов за счёт дедупликации и сжатия, оптимизированных по производительности.
Усиление безопасности, отказоустойчивости и соответствия требованиям. Оперативное применение исправлений (live patching) для хостов с поддержкой TPM позволяет устанавливать до 80 процентов критических обновлений безопасности без простоя, полностью выводя обслуживание безопасности за рамки запланированного окна технических работ. Расширенная репликация виртуальных машин с внешних массивов напрямую в кластер vSAN упрощает архитектуру восстановления и даёт реальную экономию по сравнению с устаревшими конфигурациями.

Ресурсы по VMware vSphere Foundation 9.1

Рисунок 2: Раздел ресурсов и вопросов-ответов по VMware vSphere Foundation 9.1 в нижней части страницы продукта VMware vSphere Foundation.

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

Инфографика: VMware vSphere Foundation 9.1 с первого взгляда. С неё стоит начать ради быстрого визуального обзора. Инфографика показывает, как NVMe Memory Tiering снижает TCO сервера, как устраняются узкие места последовательной миграции, и как оперативное применение исправлений выводит обслуживание безопасности за пределы производственного календаря — всё в формате, удобном для распространения среди заинтересованных сторон.
Техническое описание (Datasheet): Возможности и преимущества продукта. Структурированный справочник для ИТ-специалистов, проводящих формальную оценку. Он охватывает возможности платформы, поддерживаемые аппаратные новшества и целевые сценарии использования, давая всё необходимое для оценки того, как vSphere Foundation 9.1 вписывается в стратегию ЦОД.
Краткое описание решения (Solution Brief): Новая экономика инфраструктуры. Подготовлено для руководителей в сфере инфраструктуры и бизнеса, следящих за предсказуемостью бюджета и окупаемостью оборудования. Документ обосновывает, как vSphere Foundation 9.1 справляется с волатильностью цен на DRAM и с постоянными издержками устаревших циклов обслуживания. Это хороший материал для выстраивания внутреннего согласия вокруг модернизации.
Сравнение возможностей: VMware Cloud Foundation и VMware vSphere Foundation 9.1. Понятный разбор двух основных платформ VMware. Если команда выбирает между модернизацией имеющейся инфраструктуры на базе vSphere Foundation и переходом к полнофункциональному частному облаку на VMware Cloud Foundation, этот документ наглядно излагает различия.
FAQ: Ответы на частые вопросы клиентов. Охватывает вопросы, которые обычно возникают вокруг развёртывания, аппаратной совместимости и новых возможностей централизованного управления. Практичный спутник для команд на этапе планирования и подготовки.

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

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

Изучите полную библиотеку ресурсов и начните знакомство с vSphere Foundation 9.1 уже сегодня:

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

Вышел Basis Workplace 3.3: свой протокол, единый стек и меньше зависимостей

Fri, 19 Jun 2026 16:43:30 UTC

Один из ключевых сдвигов в развитии VDI-платформы Basis Workplace — постепенный уход от зависимостей: сначала от middleware-слоя при подключении к гипервизорам, теперь от сторонних протоколов доставки. Версия 3.3, вышедшая в конце мая 2026 года, закрепляет эту логику: в состав платформы включён собственный протокол Basis Connect, а интеграция с Basis SDN превращает линейку «Базис» в замкнутый отечественный стек — от гипервизора до сетевого уровня.

Зачем VDI нужен собственный протокол

Протокол доставки — это то, что пользователь ощущает напрямую: задержки, качество картинки, работа веб-камеры и периферии. До версии 3.3 Basis Workplace предлагал два варианта: проприетарные протоколы с отдельными лицензиями (RX, Loudplay) либо open-source-решения, требующие самостоятельной доработки. Оба подхода создают либо финансовую, либо операционную зависимость.

Basis Connect разрабатывался как третий путь — нативный протокол без внешних лицензий, сразу встроенный в платформу. В первом публичном релизе он поддерживает передачу видео и звука, буфер обмена (текст, файлы, папки, изображения), клавиатуру, мышь, принтеры, сканеры и USB-устройства, включая аппаратные токены с сертификатами. Поддержка RX и Loudplay при этом сохраняется.

Замкнутый стек на продуктах «Базис»

Версия 3.2 убрала промежуточный слой vControl при подключении к Basis Dynamix Enterprise и OpenStack. Версия 3.3 идёт дальше: Basis Dynamix Enterprise теперь работает в связке с Basis SDN — собственным решением компании для управления программно-определяемой сетью. Заказчик, использующий эту конфигурацию, получает VDI-инфраструктуру полностью на продуктах одного вендора: серверная виртуализация, сетевой уровень и управление рабочими столами — без иностранных компонентов.

Устойчивость к сбоям в крупных и распределённых инсталляциях

Для организаций с разветвлённой инфраструктурой в версии 3.3 реализован ряд механизмов повышения надёжности. Появился резервный бэкенд с автоматическим переключением при отказе основного. Брокерный слой получил балансировку через Global Server Load Balancing (GSLB). В настройках службы каталогов теперь можно задавать список контроллеров домена — система перебирает их по очереди, если текущий недоступен.

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

Мониторинг, аудит и управление доступом

В версии 3.3 появилась сводная информационная страница (dashboard) с общим состоянием инфраструктуры, обновлены метрики подключений к пулам и суперпулам, а историю загрузки виртуальных машин теперь можно анализировать ретроспективно за любой выбранный период. Ряд операций с ВМ пользователей, ранее выполнявшихся только поодиночке, стал доступен в массовом режиме. Управление сервисами и удаление объектов системы — организаций, проектов, служб каталога, ролей — перенесено в панель управления. Возможности аудита расширились: отчёты теперь охватывают не только действия пользователей и администраторов, но и устройства доступа, за любой выбранный период.

Безопасность и корпоративные интеграции

Список поддерживаемых служб каталогов и SSO-провайдеров расширен: добавлена поддержка Avanpost DS и SSO-аутентификации через Blitz Identity Provider по протоколу OpenID Connect. В логинах для доменов Microsoft Active Directory теперь поддерживается кириллица. Для встраивания в корпоративный контур информационной безопасности реализована передача событий во внешние SIEM-системы в формате CEF.

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

Периферия и подключение к виртуальным машинам

В версии 3.3 реализован проброс сканеров между клиентом и виртуальным рабочим местом, доработан проброс устройств при работе с протоколом Loudplay. Для отдельных категорий пользователей добавлена возможность подключаться к виртуальным машинам пула напрямую по протоколу RDP — без установки клиентского приложения Basis Workplace, используя любой совместимый RDP-клиент.

«При создании Basis Connect мы ориентировались на запросы заказчиков на нативный протокол передачи данных в составе Basis Workplace. Он позволяет обеспечивать высокое качество работы в виртуальной среде, не требует отдельных лицензий на проприетарные протоколы и упрощает эксплуатацию платформы. Что касается интеграции с Basis SDN, то здесь мы считаем принципиально важным, чтобы возможности нашего программно-определяемого решения были доступны в других продуктах экосистемы. Для заказчиков это означает более удобное управление сетевой частью виртуальной инфраструктуры, более быстрое развёртывание рабочих мест и более высокий уровень контроля над безопасностью и сегментацией среды» — Дмитрий Сорокин, технический директор компании «Базис».

VMware Cloud Foundation 9.1 и vSphere Foundation 9.1: сравнение функций и пути обновления

Wed, 17 Jun 2026 08:32:05 UTC

Компания VMware выпустила документ "VMware Cloud Foundation 9.1 and VMware vSphere Foundation 9.1 - Feature Comparison & Upgrade Paths". Этот документ описывает ключевые различия между двумя основными платформами Broadcom — VMware Cloud Foundation и VMware vSphere Foundation.

VMware VCF — платформа частного облака, которая сочетает масштаб и гибкость публичного облака с безопасностью и производительностью локальной инфраструктуры, повышая продуктивность и снижая совокупную стоимость владения (TCO).

Полнофункциональная платформа Infrastructure as a Service (IaaS), предоставляющая программно-определяемые вычисления, хранение, сеть, Kubernetes, безопасность и средства управления.
Встроенная автоматизация формирует платформу самообслуживания для быстрого развёртывания виртуальных машин и контейнеров и повышения скорости разработки.
Закалённая платформа со встроенной отказоустойчивостью, масштабированием и кластеризацией для непрерывной работы.
Облачная гибкость позволяет наращивать инфраструктуру без увеличения штата, перенося облачную модель потребления в локальную среду.
Автоматизация и оркестрация упрощают задачи нулевого, первого и второго дня.
Поставляется единым SKU, что упрощает развёртывание всего стека.

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

Единая платформа для совместного запуска виртуальных машин и контейнеров с нативной средой выполнения Kubernetes.
Интеллектуальное управление эксплуатацией обеспечивает расширенную видимость и оптимизацию инфраструктуры.
Гиперконвергентная инфраструктура объединяет виртуализацию вычислений и хранения для эффективного управления ресурсами.
Упрощённое развёртывание и масштабируемость с единым SKU ускоряют доставку приложений и готовят инфраструктуру к будущему.

На рисунке ниже показан упрощённый портфель VMware by Broadcom и три варианта поставки.

Детальное сравнение функций

В сравнении участвуют три варианта поставки.

VMware Cloud Foundation — ПО частного облака с интегрированными компонентами: vSphere, vSphere Kubernetes Service, VCF Operations, VCF Operations for Networks, VCF Operations fleet management, VCF Automation, vSAN и NSX.
VMware vSphere Foundation — ПО, предоставляющее часть возможностей VCF или их ограниченные версии: vSphere, vSphere Kubernetes Service, VCF Operations и vSAN.
VMware Cloud Foundation Edge — оптимизированная конфигурация VMware Cloud Foundation для периферийных сценариев.

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

Вычисления (Compute)

Включённые сервисы:

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
vSphere Kubernetes Service (VKS)	•	•	•
VM Service	•	•	•
Storage Service	•[2]	•	•
Network Service	•[2]	•	•
Container Registry Service	•	•	•
Harbor Image Registry Service	•	•	•
vSphere Pod Service	•	•	•
VKS Load Balancing	•	•	•
Service Mesh	•	•	•
External DNS	•	•	•
ArgoCD Operator	—	•	•
Secret Store Service	—	•	•
IaaS Policy Service	—	•	•
Data Services	•	•	•
Workload Availability Zones	•	•	•
Упрощённое управление жизненным циклом кластеров VKS	—	•	•
Build Your Own Image (BYOI)	•	•	•
Supervisor Independent Updates	•	•	•
Custom Zone Optimization	•	•	•

Управление эксплуатацией:

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
vSphere Lifecycle Manager	•	•	•
Live Patching for ESX	•	•	•
vCenter Quick Patching	•	•	•
vCenter Server Profiles	•	•	•
vCenter Update Planner	•	•	•
Content Library	•	•	•
vSphere Configuration Profiles	•	•	•
Host Profiles	•	[3]	[3]
Auto Deploy	•	[3]	[3]
Эластичное предоставление vSphere (ZTP)	•	•	•
Green Metrics	•	•	•

Встроенная безопасность:

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
Identity Federation	•	•	•
Аппаратный TPM 2.0	•	•	•
Virtual TPM 2.0	•	•	•
Сертификация FIPS 140-2 и Common Criteria	•	•	•
TLS 1.2	•	•	•
TLS 1.3	•[4]	•[4]	•[4]
Шифрование виртуальных машин	•	•	•
Standard Key Provider (внешний KMS)	•	•	•
Native Key Provider	•	•	•
File Integrity Monitoring	•	•	•
Confidential Computing	[15]	•	•
Интеграция EDR для ESX	•	•	•

Производительность приложений:

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
Per-VM Enhanced vMotion Compatibility (EVC)	•	•	•
Instant Clone	•	•	•
Distributed Resource Scheduler (DRS)	•	•	•
Storage DRS	•	•	•
Distributed Power Management (DPM)	•	•	•
Storage Policy-Based Management	•	•	•
I/O Controls (хранилище)	•	•	•
SR-IOV	•	•	•
vSphere Persistent Memory	•	•	•
Memory Tiering	•	•	•
NVIDIA GRID vGPU	•	•	•
Accelerated Graphics for VMs	•	•	•
Dynamic DirectPath IO	•	•	•
Enhanced DirectPath I/O	•	•	•
Vendor Device Group	•	•	•
Разные профили vGPU на одном GPU	•	•	•
Автоматизация DRS для vGPU-нагрузок	•	•	•
Поддержка DPU и Dual DPU	—	•	•

Непрерывность бизнеса:

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
vMotion	•	•	•
Cross-vCenter vMotion	•	•	•
Encrypted vMotion	•	•	•
vCenter Enhanced Linked Mode	•	•	•
vSMP	•	•	•
vSphere High Availability (HA)	•	•	•
Proactive HA	•	•	•
Storage vMotion	•	•	•
Fault Tolerance	•	•	•
vSphere Replication	•	•	•
Поддержка 4k Native Storage	•	•	•
vSphere Quick Boot	•	•	•
Файловое резервное копирование и восстановление vCenter	•	•	•
Cross vCenter Mixed Version Provisioning	•	•	•
Горячая и холодная миграция в облако	•	•	•
Управление на основе политик (Policy-based Governance)	•	•	•
Kubernetes Automation	•	•	•
Workload Lifecycle Management	•	•	•
vCenter Orchestration & Extensibility	•	•	•

Хранение (Storage)

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
vSAN Express Storage Architecture (ESA)	•	•	•
vSAN Original Storage Architecture (OSA)	•	•	•
All-Flash оборудование	•	•	•
Базовые компрессия и дедупликация	• (только OSA)	• (только OSA)	• (только OSA)
Продвинутое сжатие и глобальная дедупликация	• (только ESA)	• (только ESA)	• (только ESA)
Шифрование данных «в покое»	•	•	•
Шифрование данных «в движении»	•	•[3]	•[3]
Storage Policy-Based Management	•	•	•
Программная контрольная сумма	•	•	•
vSAN over RDMA	•	•[3]	•[3]
QoS — ограничение IOPS	•	•	•
Auto-Managed RAID	•	•	•
Кластеры хранения vSAN	•	•	•
Кластеры кибервосстановления vSAN	—	•[15]	•[15]
Удалённые хранилища (Remote Datastores)	•	•	•
Растянутый кластер (Stretched Cluster)	•	•	•
Двухузловой кластер (2-Node Cluster)	•	•[3]	•[3]
File Services	•	•	•
Object Storage	—	•[17]	•[17]
iSCSI Target Service	•	•[3]	•[3]
Cloud Native Storage (CNS) Control Plane	•	•	•
vSphere Container Storage Interface (CSI) Driver	•	•	•
Rack Awareness (Fault Domains)	•	•[3]	•[3]
Snapshot Manager с гибким расписанием	•	•	•
Неизменяемые снимки (Immutable Snapshots)	•	•	•
Репликация Any-to-vSAN	•[14]	•[14]	•[14]

Внешние хранилища:

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
VMFS — Fibre Channel	•	• (Principal, Supplemental)	• (Principal, Supplemental)
VMFS — iSCSI	•	• (Supplemental)	• (Supplemental)
VMFS — FCoE	•	• (Supplemental)	• (Supplemental)
VMFS — NVMe/FC	•	• (Supplemental)	• (Supplemental)
VMFS — NVMe/TCP	•	• (Supplemental)	• (Supplemental)
VMFS — NVMe/RDMA	•	• (Supplemental)	• (Supplemental)
NFS — v3	•	• (Principal, Supplemental)	• (Principal, Supplemental)
NFS — v4.1	•	• (Supplemental)	• (Supplemental)
Storage I/O QoS Controls (SIOC)	•	•	•
VAAI для блочного хранилища	•	•	•
VAAI для NFS-хранилища	•	•	•
Кластеризация нагрузок (VMDK Clustering)	•	•	•
Автонастройка с NFS	•	•	•
Сторонние плагины хранения	•	•	•
Ввод хостов и управление кластером	•	•	•

Сеть (Networking)

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
vSphere Distributed Switch	•	•	•
Link Aggregation Control Protocol (LACP)	•	•[3]	•[3]
Load-Based Teaming	•	•	•
Network I/O QoS Control (NIOC)	•	•	•
Private VLAN	•	•	•
MAC Learning	•	•	•
BPDU Guard	•	•	•
Guest VLAN Tagging	•	•	•
VLAN Backed Networking	•	•	•
Virtual Networking	—	•	•
Spoofguard	—	•	•
L2 Multicast	•	•	•
L3 Multicast	—	•	•
Enhanced Datapath	—	•	•
Enhanced Datapath для DPU	—	•	•
Маршрутизация IPv4 и IPv6	—	•	•
Динамическая маршрутизация (OSPFv2/BGP/BFD)	—	•	•
VRF	—	•	•
EVPN	—	•	•
NAT	—	•	•
L2 и L3 VPN	—	•	•
Quality of Service (QoS)	• (NIOC)	• (NIOC и NSX)	• (NIOC и NSX)
NSX Edge Bridge для сети	—	•	•
DNS, DHCP и IPAM	—	•	•
Container Networking с NCP	—	•[16]	•[16]
Container Networking с Antrea	•[16]	•[16]	•[16]
Политики, теги и группировка	—	•	•
Мультиарендность через проекты	—	•	•
Virtual Private Cloud (VPC)	—	•	•
Балансировка для компонентов VCF [12]	—	•	•
Балансировка L4 для vSphere Supervisor [11],[12]	•	•	•
Кластеризация менеджеров / контроллеров	—	•	•
Federation	—	•	•
NSX Edge в форм-факторе ВМ и bare-metal	—	•	•
Автоматическое и ручное развёртывание менеджера и Edge	—	•	•
Автоматическая подготовка хостов	—	•	•
Port Mirroring	•	•	•
Netflow/IPFIX	•	•	•
Traceflow	—	•	•
Live Traffic Analysis	—	•	•
Packet Capture	•	•	•

vSphere Kubernetes Services (VKS) и облачные сервисы VCF

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
VKS: улучшенная масштабируемость, быстрое развёртывание, размещение пулов узлов с учётом аффинити	•	•	•
VM Service: импорт ВМ без смены сети	•	•	•
Storage and Data Services	—	•	•
Network Services: двусетевая поддержка VKS, развёртывание Supervisor через DGTW	—	•	•
Private AI Services	—	•	•
Harbor Image Registry Service	—	•	•
Container Service	•	•	•
GitOps Integration	—	•	•
Supervisor Services: мультикластерные зоны и вывод кластеров из эксплуатации	—	•	•
Secret Service: упрощённая инъекция секретов, политики и роли доступа	—	•	•
External DNS	—	•	•
Cert Manager	—	•	•

Облачное управление: VCF Automation

Весь слой автоматизации доступен только в VMware Cloud Foundation и VCF Edge; в vSphere Foundation он отсутствует.

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
Self-Service Catalog [5]	—	•	•
Self-Service IaaS [6]	—	•	•
UI / CLI / Unified APIs (декларативные K8s API [6], REST API [5])	—	•	•
Видимость производительности и стоимости нагрузок (с VCF Operations) [6]	—	•	•
Core Services: VM, VKS, Container, Network, Volume, VM Image [6]	—	•	•
Extensible Services (ArgoCD, Contour, Harbor, Service Mesh, Velero и др.)	—	•	•
Services Framework (Harbor, DSM, Secret Store, BYOK, Multi-tenant DR и др.)	—	•	•
Private AI Services [6],[10]	—	•	•
GPU-capable DL VM и GPU-capable VKS Cluster provisioning	—	•	•
Интеграция DSM для RAG-нагрузок	—	•	•
Vector DBs, Data Indexing & Retrieval, AI Agent Builder, MCP	—	•	•
Visual Canvas Template Designer с декларативным YAML [5]	—	•	•
Blueprints (YAML [5], K8s-манифест в YAML [6])	—	•	•
Интеграция с Git (GitHub, GitLab, Bitbucket) [5]	—	•	•
VCF Automation Terraform Provider [5]	—	•	•
Автоматическое развёртывание и настройка облачных сервисов [6]	—	•	•
Автоматическое развёртывание объектов SDDC [7] (NSX, Security Groups, Firewalls [8], Avi LB [9])	—	•	•
App Stack Formation [6]	—	•	•
Централизованная видимость парка кластеров VKS	—	•	•
VKS Policy Management	—	•	•
Data Protection	—	•	•
Add-on Management [18]	—	•	•
Governance: Zones, Regions, Organization, Project, IAM [5]	—	•	•
Namespace Classes, Namespaces, VPC [6]	—	•	•
Политики (approval, lease, day 2) [5]	—	•	•
Resource Policies (IaaS, VKS) с Policy as Code [6]	—	•	•
Infrastructure Placement Policies [6]	—	•	•
Tenant Identity Management и RBAC [6]	—	•	•
Custom Naming Policy [5]	—	•	•
Cost Visibility, Pricing [1], Notifications (с VCF Operations)	—	•	•
Tenant Management [6] (ресурсы, изоляция сети, операции, брендинг, дашборды)	—	•	•
Certificate Management	—	•	•
Content Management [6] (Content Hub, публикация в каталог, общий доступ)	—	•	•
Network & Security Automation [6] (VPN, NAT, GW Firewall [8], DTW для VPC, IPAM, Shared Subnets, DFW)	—	•	•
Workflow Orchestration (VCF Operations orchestrator) [5]	—	•	•
Event Subscription, Custom Resources/Custom Day 2, XaaS [5]	—	•	•
Action-Based Extensibility (ABX/FaaS) [7]	—	•	•
Интеграции (Ansible, Puppet, VMware Salt, ServiceNow, Infoblox, AD)	—	•	•
Workload discovery and onboarding [7]	—	•	•
Day 2 Actions и Custom Actions [5]	—	•	•
Advanced Workload Placement (с VCF Operations) [7]	—	•	•
Right-sizing и реклейминг ресурсов (с VCF Operations) [7]	—	•	•

VCF Operations

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
Install	•	•	•
Lifecycle Management (клиенты VVF используют vLCM)	—	•	•
License Management	•	•	•
Certificate Management	—	•	•
Password Management	—	•	•
Интеграция со сторонним хранилищем паролей через OIDC	—	•	•
Centralized Tag Management	—	•	•
Global inventory	•	•	•
IAM и Single Sign-on (интерфейс vSphere)	•	N/A	N/A
IAM и Single Sign-on (интерфейс VCF Operations)	—	•	•
Мониторинг GPU и vGPU	•	•	•
Аудит событий vCenter, vSphere, vSAN и NSX	•	•	•
Log Management	•	•	•
VCF Health and Diagnostics	•	•	•
Storage Operations (vSAN)	•	•	•
Визуализация (алерты, дашборды, отчёты, тепловые карты, супер-метрики)	•	•	•
Визуализация метрик через PromQL	•	•	•
Мониторинг и аналитика производительности	•	•	•
Мониторинг в реальном времени	•	•	•
Предиктивное управление ёмкостью (What-If, right-sizing, оптимизация)	•	•	•
Troubleshooting с управляемым устранением проблем	•	•	•
Cost Management и оптимизация с тонкой аналитикой стоимости	•	•	•
Custom Profiles для ВМ	•	•	•
Data Protection and Recovery (Live Cyber Recovery, Live Site Recovery)	•	•	•
Service Discovery и Application Dependency Mapping	•	•	•
Discovery/Monitoring/Troubleshooting для пакетных приложений	—	•	•
Расширяемость через инфраструктурные Management Packs	•	•	•
Расширяемость через App & Management Packs (БД, middleware)	—	•	•
Application Monitoring (Telegraf Agent)	—	•	•
Prometheus Management Pack Builder, PromQL API	—	•	•
Logs Alerting / Query API / Scheduled reports / Partitioning / Content Pack	•	•	•
Security Operations (SecOps)	—	•	•
Мониторинг Supervisor Cluster (метрики и дашборды)	•	•	•
Мониторинг кластеров vSphere Kubernetes Service	•	•	•

Соответствие нормативным требованиям с устранением отклонений (Security baseline, PCI, закалка vSphere) и управление дрейфом конфигурации требуют надстройки Advanced Cyber Compliance.

VCF Operations for Networks

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
Видимость и диагностика сети для vSphere и NSX	—	•	•
Отчёт по оценке и оптимизации сети	—	•	•
Виртуальные потоки (VDS IPFIX, VM-to-VM, VM-to-Physical, Antrea IPFIX)	—	•	•
Физические потоки (NetFlow v7/v9, sFlow)	—	•	•
Поддержка IPv6-потоков для vSphere и NSX	—	•	•
Аналитика потоков (Thresholds, Outliers)	—	•	•
Обнаружение приложений (авто и ручное)	—	•	•
Здоровье, мониторинг и аналитика приложений	—	•	•
DNS-маппинг (импорт bind-файла)	—	•	•
Видимость виртуальной и физической сетевой фабрики NSX	—	•	•
Интеграция с физическими устройствами (Cisco, Arista, Juniper, Infoblox)	—	•	•
Автообнаружение сетевых устройств	—	•	•
Видимость NSX Federation	—	•	•
План миграции и мобильность нагрузок между ЦОД	—	•	•
Видимость сети для VKS и Red Hat OpenShift через NSX container plugin	—	•	•
Интеграция Avi Load Balancer (нужна отдельная надстройка)	—	•	•
Планирование сегментации NSX Firewall (нужна надстройка vDefend)	—	•	•
Соответствие FIPS 140-2 платформы сетевых операций	N/A	•	•
Анализ Crown Jewels для безопасности	—	•	•
Видимость незавершённых TCP-сессий для мониторинга DDoS	—	•	•
Удобный поиск/запросы	—	•	•
Управляемая диагностика сети	—	•	•
Видимость путей для виртуальной и физической сети	—	•	•
Визуализация топологии (Network Map) по VCF и underlay	—	•	•
Network assurance и верификация (Intents) для VCF и underlay	—	•	•

Private AI

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
Data Indexing and Retrieval Service	—	•	•
Agent Builder Service	—	•	•
Model Context Protocol	—	•	•
AI Metrics Observability	—	•	•
Model Store	—	•	•
Model Runtime	—	•	•
AI-нагрузки только на CPU	—	•	•
AI Blueprints Quick Start	—	•	•
Deep Learning VM Templates	—	•	•
Видимость профилей vGPU	—	•	•
Векторные базы данных для RAG	—	•	•

Дополнительные сервисы (надстройки) [13]

Функция	vSphere Foundation	VCF Edge	VMware Cloud Foundation
Дополнительная ёмкость vSAN	•	•	•
Advanced Cyber Compliance (ACC)	—	•	•
ACC — контроль соответствия для нагрузок и стека VCF	—	•	•
ACC — локальное кибер- и аварийное восстановление	—	•	•
ACC — Policy-Based VPC Connectivity	—	•	•
ACC — Confidential Computing	—	•	•
Site Recovery Manager	•	•	•
Live Recovery Cloud	•	•	•
Load Balancing	•	•	•
Advanced Security	—	•	•
Application Services	—	•	•
Data Services	—	•	•
Network Observability	—	•	•
Business Operations	—	•	•
Identity Security	—	•	•

Примечания

Org for VM Apps включает возможность наценки по тарифной карте (rate card).
Обозначает функции, ограниченные поддержкой VM Service и VKS.
Функции совместимы с VCF, но не интегрированы с VCF Operations fleet management.
Подробности об использовании TLS 1.3 с требованиями FIPS 140-3 — в документации продукта.
Доступно как в Org for All Apps, так и в VM Apps.
Доступно в Org for All Apps.
Доступно в Org for VM Apps.
Требует надстройку Firewall.
Требует надстройку Avi LB.
Требует надстройку PAIF-N.
Ingress / Gateway API предоставляется Contour Ingress Controller / Supervisor Service.
Клиентам, которым нужна универсальная или продвинутая балансировка, рекомендуется приобрести Avi Load Balancer. Тем, кому требуется время на миграцию с существующей балансировки VCF на Avi, разрешено продолжать пользоваться полной балансировкой VCF до 30 мая 2027 года при наличии необходимых лицензий Avi. Подробности об лицензировании и вариантах миграции — в статье базы знаний № 439411.
Дополнительные сервисы приобретаются отдельно и не входят в базовые поставки VMware Cloud Foundation и VMware vSphere Foundation.
Требует лицензию VMware Site Recovery Manager (SRM).
Требует VCF Advanced Cyber Compliance (надстройка Advanced Services).
Поддержка Antrea предоставляется только для VMware VKS. Поддержка NCP — только для VMware vSphere Supervisor и Tanzu Elastic Runtime.
Tech Preview.
Функция доступна начиная с VKS 3.5+.

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

Графики ниже показывают маршруты перехода с прежних продуктов на новые предложения.

Пути для вычислений (Compute). Прежние издания vSphere Foundation, vSphere Enterprise Plus, vSphere Enterprise, vSphere for Desktop, vSphere Scale-Out и vSphere Standard рекомендуется переводить на vSphere Foundation.
Пути для хранения (Storage). Связка vSphere + vSAN + NSX + Aria и vSphere + vSAN + Aria ведут к VMware Cloud Foundation; vSphere + vSAN и vSphere + vSAN + NSX — к vSphere Foundation вместе с надстройкой vSAN.
Пути для сети и безопасности (Networking/Security). Конфигурации vSphere + vSAN + NSX + Aria и vSphere + NSX + Aria переходят на VMware Cloud Foundation с межсетевым экраном Firewall; vSphere + vSAN + NSX и vSphere + NSX — также на VCF с Firewall.
Путь управления (Management). vSphere с Aria Suite Enterprise или vRCU Enterprise переходит на VMware Cloud Foundation; vSphere с vROPs + vRA, Aria Suite Advanced или vRCU Advanced — на vSphere Foundation; vSphere с vROPs, Aria Suite Standard или vRCU Standard — также на vSphere Foundation.
Пути vCloud Suite. vCloud Suite Enterprise консолидируется в VMware Cloud Foundation с Aria Suite Enterprise и vSphere Enterprise Plus; vCloud Suite Advanced — в vSphere Foundation с Aria Suite Advanced и vSphere Enterprise Plus; vCloud Suite Standard — в Aria Suite Standard с vSphere Enterprise Plus.
Пути VCF. VCF Enterprise, VCF Advanced, VCF Standard и VCF Starter переходят на VMware Cloud Foundation с межсетевым экраном Firewall.

За дополнительными деталями Broadcom предлагает обращаться к сотрудникам VMware и официальным партнерам.

Критическая RCE-уязвимость в Veeam Backup & Replication: что нужно знать

Mon, 15 Jun 2026 09:01:07 UTC

Компания Veeam выпустила обновления безопасности, закрывающие критическую уязвимость в продукте Veeam Backup & Replication. Брешь, получившая идентификатор CVE-2026-44963, позволяет аутентифицированному пользователю домена удалённо выполнить произвольный код на сервере резервного копирования. Сведения об уязвимости были опубликованы 9 июня 2026 года, одновременно с выходом исправленной сборки.

Уязвимость затрагивает Veeam Backup & Replication сборки 12.3.2.4465 и все более ранние выпуски ветки 12. При этом сборки версии 13.x не подвержены проблеме — это связано с изменениями в архитектуре продукта, появившимися начиная с тринадцатой версии. Veeam также отмечает, что версии продукта, снятые с поддержки, не тестировались, однако с высокой вероятностью уязвимы и должны рассматриваться как подверженные риску.

Детали уязвимости

CVE-2026-44963 относится к классу уязвимостей удалённого выполнения кода (RCE). По шкале CVSS v4.0 ей присвоен балл 9.4 из 10.0, что соответствует критическому уровню опасности. Полный вектор оценки выглядит так:

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Из вектора следует, что атака проводится по сети (AV:N), не требует особых условий и взаимодействия с пользователем, а для эксплуатации достаточно низких привилегий (PR:L). Успешная атака приводит к полному нарушению конфиденциальности, целостности и доступности как самой системы, так и связанных с ней компонентов. Уязвимость была обнаружена и ответственно раскрыта исследователем Sina Kheirkhah (@SinSinology) из компании WatchTowr.

Кто находится под угрозой

Ключевая особенность CVE-2026-44963 состоит в том, что она затрагивает только те серверы Veeam Backup & Replication, которые включены в домен Active Directory. Для эксплуатации злоумышленнику достаточно обычной доменной учётной записи с низкими привилегиями — права администратора не требуются. Это существенно расширяет круг потенциальных атакующих: получить рядовую учётную запись в домене заметно проще, чем административную.

Veeam уже давно рекомендует не вводить серверы резервного копирования в домен, а размещать их в изолированной рабочей группе. Этому посвящён отдельный раздел руководства по безопасности — Veeam Backup & Replication Security Best Practice Guide. Тем не менее на практике многие организации игнорируют эту рекомендацию и подключают серверы Veeam к домену Windows, тем самым оставляя себя открытыми для подобных атак.

Позиция вендора и риск обратной разработки патча

Veeam придерживается политики прозрачного раскрытия уязвимостей: в компании действует программа Vulnerability Disclosure Program (VDP), а код продуктов проходит регулярный внутренний аудит. После обнаружения уязвимости команда оперативно выпускает исправление, а затем публично раскрывает информацию о проблеме и мерах по её устранению. Такой подход позволяет всем затронутым клиентам быстро принять необходимые меры.

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

Veeam как излюбленная цель программ-вымогателей

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

В последние годы Агентство по кибербезопасности и защите инфраструктуры США (CISA) внесло четыре уязвимости Veeam Backup & Replication в каталог активно эксплуатируемых брешей — все они использовались группировками вымогателей. Так, в ноябре 2024 года специалисты Sophos X-Ops сообщили, что несколько группировок, включая Akira, Fog и Frag, взяли на вооружение другую критическую RCE-уязвимость VBR — CVE-2024-40711. С атаками на уязвимости Veeam также связывали финансово мотивированную группу FIN7, сотрудничавшую с операторами Maze, Egregor, Conti, REvil и BlackBasta, и вымогателей Cuba, атаковавших критически важные организации в США.

Масштаб потенциальных последствий усиливается широтой распространения продукта: решениями Veeam пользуются более 550 000 клиентов по всему миру, среди которых 82% компаний из списка Fortune 500 и 74% организаций из Global 2000. Стоит также напомнить, что в марте 2026 года Veeam уже устраняла несколько критических уязвимостей в Backup & Replication, способных приводить к удалённому выполнению кода.

Что делать

Уязвимость устранена начиная со сборки Veeam Backup & Replication 12.3.2.4854. Всем пользователям ветки 12 рекомендуется как можно скорее обновиться до этой или более новой версии. Дополнительно стоит привести конфигурацию в соответствие с рекомендациями вендора: вывести сервер резервного копирования из домена Active Directory в изолированную рабочую группу, использовать отдельные локальные учётные записи, включить многофакторную аутентификацию и ограничить сетевой доступ к серверу. Подробности об исправлении доступны в официальном бюллетене Veeam KB4869.

VMware vSAN в VCF 9.1: оптимизация, защита и снижение затрат

Thu, 11 Jun 2026 07:38:44 UTC

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

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

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

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

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

Гибкая и эффективная платформа хранения

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

Глобальная дедупликация

В VCF 9.1 глобальная дедупликация vSAN переходит в статус общедоступной. Глобальная дедупликация vSAN позволяет сократить используемую ёмкость до 8 раз — это критически важная возможность в условиях быстро растущей стоимости хранения и увеличивающихся сроков поставок оборудования. Дедупликация в vSAN спроектирована с минимальным влиянием на процессор и может применяться ко всем данным в кластере. Это дедупликация с постобработкой: она выполняется в фоновом режиме при низкой нагрузке на процессор. В отличие от традиционных систем хранения, где дедупликация ограничена хранилищем за парой I/O-контроллеров, домен дедупликации vSAN масштабируется вместе с кластером, потенциально обеспечивая более высокую эффективность.

Улучшенное сжатие

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

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

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

Узлы ReadyNode для киберрезервного копирования с устройствами QLC

Сценарии резервного копирования — аварийное, операционное и киберрезервное — предъявляют к инфраструктуре иные требования, чем основное хранилище: меньше ресурсов процессора и памяти, но более высокая ёмкость. Хотя исторически ИТ при инвестициях в инфраструктуру резервного копирования ориентировались прежде всего на стоимость, изменившийся характер бизнеса потребовал повышенного внимания к производительности и времени восстановления. VCF 9.1 представляет узлы ReadyNode, оптимизированные для киберрезервного копирования с устройствами QLC (Quad-Level Cell), обеспечивающими оптимальный баланс плотности, производительности, выносливости и стоимости для данного сценария.

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

Расширенная гибкость для кластеров хранения vSAN

Многие пользователи vSAN последовательно развивают свою инфраструктуру хранения, поэтому нередко используют сочетание vSAN Express Storage Architecture (ESA) и Original Storage Architecture (OSA). Клиенты хотят иметь возможность инвестировать в новую инфраструктуру, одновременно эксплуатируя старые кластеры vSAN до конца срока их службы. VCF 9.1 снимает прежние ограничения, позволяя монтировать новые хранилища ESA к кластерам OSA и давая вычислительным кластерам без хранения возможность монтировать как OSA, так и ESA. Клиенты могут расширять инфраструктуру для приложений на кластерах OSA без необходимости инвестировать в технологии предыдущих поколений.

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

Ускорение разработки современных приложений

Современные ИТ-команды поддерживают всё — от традиционных баз данных до контейнерных приложений и современных практик DevOps, — строго соблюдая соглашения об уровне обслуживания. vSAN в VCF 9.1 расширяет гибкость для удовлетворения этих разнообразных требований.

Нативное объектное хранилище S3 в vSAN (Technical Preview)

Впервые vSAN предоставляет нативное объектное хранилище, совместимое с S3, добавляя третий тип хранения — наряду с блочным и файловым — непосредственно в VCF. Данная версия Technical Preview ориентирована на сценарии использования в DevOps и конвейерах CI/CD, где разработчикам необходим быстрый самостоятельный доступ к масштабируемому объектному хранилищу.

Реализация включает мультитенантность, S3-бакеты как услугу и базовые функции безопасности и соответствия требованиям — всё это доступно через VCF Automation. В результате разработчики получают необходимую гибкость, а ИТ сохраняет управление и контроль. При этом решение включено в лицензии VCF, обеспечивая снижение совокупной стоимости владения на 34% по сравнению с автономными локальными продуктами объектного хранения.

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

Значительное увеличение масштаба для постоянных томов

vSAN в VCF 9.1 существенно увеличивает масштаб контейнерных томов для сред VCF. Максимальное количество постоянных томов Read Write Once (RWO) на Supervisor возрастает с 7 500 до 25 000 — рост на 233%. На уровне vCenter лимит увеличивается с 30 000 до 50 000 постоянных томов, что составляет рост на 66%. Расширенные лимиты устраняют ограничения масштабирования для крупных развёртываний Kubernetes и мультитенантных сред.

Эффективное выделение ресурсов с помощью связанных клонов

Полные клоны слишком интенсивно используют хранилище и неэффективны для большинства сценариев. VCF 9.1 вводит поддержку связанных клонов для постоянных томов с First Class Disks, что существенно сокращает время выделения ресурсов и повышает операционную гибкость. Связанные клоны совместно используют общие базовые данные, что делает их идеальными для сред разработки, тестирования и сценариев, где необходимо быстро запустить несколько аналогичных рабочих нагрузок без затрат хранилища на полные клоны.

Поддержка Read Write Many (RWX) для виртуальных машин VM Service

Хотя файловые тома RWX могли использоваться в отдельных сценариях, они были недоступны для рабочих нагрузок — например, vSphere Pods и VM Service VMs — в пространстве имён Supervisor. VCF 9.1 устраняет этот пробел, позволяя виртуальным машинам VM Service монтировать и использовать тома RWX. Это открывает новые возможности для рабочих нагрузок, которым требуется совместный доступ к хранилищу сразу нескольких подов или виртуальных машин.

Единый подход к снимкам и операциям восстановления

Виртуальные машины VM Service теперь могут использовать простые операции восстановления по снимку VM, что приводит их в соответствие с традиционными виртуальными машинами. Такая согласованность упрощает рабочие процессы резервного копирования и восстановления вне зависимости от того, используются ли стандартные ВМ или машины VM Service — единый подход для всех рабочих нагрузок.

Соответствующие требованиям Kubernetes имена политик хранения

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

Мультитенантное аварийное восстановление для машин VM Service

Облачные среды нередко обслуживают несколько команд или клиентов, каждый из которых требует независимых возможностей защиты и восстановления. VCF 9.1 вводит базовое мультитенантное аварийное восстановление (MTDR) для машин VM Service, предоставляя администраторам провайдеров и арендаторов возможность защищать виртуальные машины на базе Supervisor для сценариев защиты VCF-to-VCF.

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

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

Гибкое расписание снимков

В одном из предыдущих релизов нативные снапшоты vSAN получили возможность неизменяемости, а их производительность при масштабных и глубоких цепочках снапшотов — до 200 на ВМ — всегда оставалась высокой. vSAN в VCF 9.1 вводит гибкое расписание — широко известное как «дед–отец–сын» (GFS), — позволяющее расширить историю снимков для долгосрочного хранения в сценариях киберрезервного копирования.

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

Репликация из нескольких источников

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

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

Шифрование для глобальной дедупликации vSAN

Безопасность данных теперь распространяется на глобальную дедупликацию vSAN, гарантируя, что данные получают выгоду от экономии места без ущерба для защиты. Независимо от того, хранятся данные или передаются, они защищены шифрованием, валидированным по стандарту FIPS 140-3, от несанкционированного доступа.

Расширенные возможности растянутых кластеров

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

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

Упрощённые операции, масштабируемые с ростом инфраструктуры

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

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

Диагностика проблем производительности в программно-определяемой инфраструктуре может быть непростой задачей. Где узкое место — в хранилище, вычислительных ресурсах или сети? VCF 9.1 применяет проактивный подход: постоянный мониторинг шаблонов производительности хранилища, установка базовых линий и оповещение об отклонениях.

При отклонении производительности от базовой линии VCF Operations использует расширенную аналитику для выявления корневых причин и предоставляет конкретные шаги по устранению — всё это доступно прямо в интерфейсе Performance Service. Алгоритмический подход к диагностике коррелирует точки данных, выявляет закономерности и предоставляет инсайты, поиск которых вручную занял бы часы.

Автоматизированное управление политиками хранения

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

Расширенная диагностика хранилища vSAN

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

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

VMware Cloud Foundation 9.1: масштабирование, упрощение и защита частного облака средствами VCF Operations

Mon, 08 Jun 2026 10:06:21 UTC

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

С выходом VMware Cloud Foundation (VCF) 9.1 компания Broadcom обеспечивает организациям эффективное управление крупномасштабными средами частного облака. VCF Operations поможет снизить корпоративные риски за счёт упрощения процессов усиления защиты — благодаря более простым рабочим процессам исправлений. Предоставляя данные о состоянии и диагностике с централизованной видимостью VMware Security Advisories (VMSAs) и Common Vulnerabilities and Exposures (CVEs), VCF 9.1 обеспечит оперативное устранение уязвимостей, упростит управление жизненным циклом и предоставит ИТ-командам возможность проактивно укреплять общий уровень безопасности.

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

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

Опираясь на унифицированное управление флотом для контроля в масштабе, упрощённые Day-2 операции для наблюдения и диагностики проблем в режиме реального времени, а также на расширенный уровень безопасности для непрерывного соответствия требованиям, организации превратят инфраструктуру из центра затрат в отказоустойчивый высокопроизводительный механизм. Расширенный уровень безопасности потребует дополнения VMware Advanced Cyber Compliance.

Рисунок 1 - Новое в VCF 9.1 для VCF Operations. VCF Operations обеспечивает эффективную инфраструктуру и операции в масштабе.

Данные опроса клиентов

Опрос Broadcom среди клиентов VCF 9 (n=44), проведённый в марте 2026 года, показывает, что модернизация частного облака связана с возвращением наиболее ценного ресурса команды — времени. Данные опроса свидетельствуют о том, что клиенты могут достичь следующих результатов в среднем:

Рисунок 2 - Средние результаты по данным опроса Broadcom среди клиентов VCF 9 (n=44) в марте 2026 года.

Опрос показал, что клиенты достигают в среднем 51% сокращения времени на управление инфраструктурой при использовании VCF 9, что позволяет командам переключиться с ручного обслуживания на эффективные операции. Объединив метрики, журналы и потоки в единой консоли, платформа сокращает среднее время мониторинга на 46%. Расширенная видимость обеспечивает среднее сокращение требуемой ёмкости на 47% по сравнению с предыдущими прогнозами. Даже при возникновении инцидентов VCF 9 ускоряет их устранение на 39% по показателям MTTR/MTTI благодаря интегрированным диагностическим панелям и возможностям анализа первопричин.

Быстрое развёртывание и масштабирование

С помощью VCF Installer клиенты смогут объединить существующую среду vCenter/ESX vSphere 8.0 Update 3 и выше с доменом управления VCF. С помощью VCF Operations клиенты смогут импортировать среды VMware vCenter 8.0 Update 3a (и выше) или VMware ESX 8.0 Update 3 (и выше) в рабочий домен VCF (VI). Оба подхода позволяют использовать существующую инфраструктуру и не требуют простоя или миграции приложений и данных.

Используя VCF Operations, организации с vSphere 8.0 Update 3 или выше смогут легко интегрировать существующий vCenter в качестве рабочего домена в VCF 9.1, обеспечивая непрерывность бизнеса и получая возможности корпоративного управления. Среда VCF будет работать под управлением VCF 9.1, а VCF Operations сможет управлять более старой средой vSphere 8.0 Update 3 или выше для управления жизненным циклом, обеспечивая бесперебойную работу бизнес-приложений.

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

VCF 9.1 предложит 4-кратное увеличение параллельной ёмкости обновлений с поддержкой до 256 кластеров одновременно. Это существенно сократит время простоя и позволит операторам выполнять задачи обслуживания значительно быстрее в рамках запланированных окон.

Рисунок 3 - VCF Operations упрощает обновление и исправление инфраструктуры частного облака.

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

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

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

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

Управление флотом в масштабе

Рисунок 4 - Панель VCF Operations в VCF 9.1 обеспечивает глобальный обзор.

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

Для лицензирования VCF 9.1 в режиме подключения не потребуется ручных действий. В подключённом режиме администраторы VCF 9.0 ранее должны были вручную подтверждать обновлённые файлы лицензий каждые 180 дней или менее. VCF 9.1 реализует автоматическую загрузку файлов лицензий каждые 24 часа в подключённом режиме. После выбора подключённого режима автоматизация становится поведением по умолчанию. Данные об использовании лицензий передаются в Broadcom, а обновлённый файл лицензии загружается и применяется автоматически — без вмешательства администратора.

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

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

Для сред VxRail ключевые возможности Days 0, 1 и 2, ранее обрабатывавшиеся Dell VxRail Manager, теперь можно будет управлять с помощью VCF Operations на узлах vSAN ReadyNodes.

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

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

Рисунок 5 - VCF 9.1 предоставит детализацию затрат VMware vSphere Kubernetes Service (VKS), что улучшит возможности анализа, выставления счетов, учёта расходов и распределения затрат для современных рабочих нагрузок.

Интеллектуальная оптимизация ёмкости и затрат предоставит практические рекомендации. Рекомендации по распределению памяти на кластерах NVMe позволят количественно оценить экономию и повышение плотности виртуальных машин. В этом выпуске также появится поддержка анализа What-If для распределения памяти NVMe. Расширенное управление затратами VKS предоставит учёт расходов, распределение затрат и оценку цен в режиме реального времени — финансовую видимость, которую требует современная ИТ-служба. VCF следует операционной методологии FinOps Open Cost and Usage Specification (FOCUS) для частного облака, обеспечивающей стандартизированный формат данных о счетах для улучшенного распределения затрат и ускоренного анализа.

Упрощение операций второго дня

Глубокая наблюдаемость станет основой надёжных операций. VCF 9.1 обеспечит ИТ-команды видимостью в режиме реального времени и интеграциями, готовыми к использованию с AI, необходимыми для более быстрого устранения неполадок и поддержания работоспособности критически важных приложений.

Наблюдаемость в реальном времени теперь будет собирать метрики в секундах с настраиваемым интервалом сбора до 2 секунд для хостов ESX. Для критических рабочих нагрузок своевременные данные позволят проактивно улучшить работу бизнес-приложений.

Централизованное управление журналами объединит агрегацию журналов с расширенными панелями и бесшовной пересылкой в сторонние решения. Интерфейс журналов будет полностью интегрирован в VCF Operations. Поиск проблем в разных интерфейсах станет ненужным — всё будет доступно в одном месте для всех компонентов VCF.

Проактивная диагностика поможет предупреждать проблемы вместо реагирования на сбои. VCF 9.1 позволит использовать улучшенные панели работоспособности VCF и расширенную диагностику vSAN для выявления потенциальных проблем производительности. Диагностика будет выделять ключевые проблемы для vCenter, хостов ESX, vSAN и VCF Networking в NSX Manager и узлах Edge: проблемы с подключением, работоспособностью сервисов, использованием ресурсов и другие.

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

В VCF 9.1 Operations представляет собой платформу, готовую к интеграции с AI, через API для подключения к пайплайнам Retrieval-Augmented Generation (RAG) и фреймворкам Model Context Protocol (MCP). Это позволит клиентам экспортировать аналитику из дата-лейка инфраструктуры в другие AI-системы, например, в AIOps-движки для прогностического анализа. Встроенный мониторинг и управление журналами для кластеров VMware vSphere Kubernetes Service (VKS) обеспечат операционную видимость современных Kubernetes-рабочих нагрузок на том же уровне, что и существующие виртуальные машины.

Безопасные операции

Управление уровнем безопасности выполнит комплексные оценки соответствия по всему флоту VCF с простыми средствами устранения несоответствий для приведения инфраструктуры к требуемым эталонным показателям. Поддерживается соответствие стандартам Payment Card Industry (PCI) и Security Baseline. Управление уровнем безопасности потребует дополнительной услуги Advanced Service надстройки VMware Advanced Cyber Compliance.

Распределённые рабочие нагрузки и расширение ИИ-инициатив создают растущую поверхность атаки. VCF 9.1 интегрирует расширенную услугу надстройки VMware Advanced Cyber Compliance в пользовательский интерфейс VCF Operations. С её помощью автоматическое отслеживание соответствия требованиям станет частью операционных рабочих процессов.

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

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

От реактивных задач к проактивным операциям

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

VMware VCF 9.1 и стандарт FOCUS: финансовая прозрачность гибридного облака

Thu, 04 Jun 2026 08:44:57 UTC

Управление облачными расходами исторически представляло собой фрагментированный процесс: каждый провайдер использует собственный формат, схему и терминологию. Это создаёт своеобразный «налог на перевод» — организации тратят значительную часть времени на очистку и нормализацию данных вместо их анализа и оптимизации. FinOps-командам приходится вручную согласовывать данные из публичных облаков, SaaS-сервисов и внутренних систем, прежде чем возможен какой-либо полноценный анализ. Для решения этой проблемы был разработан стандарт FOCUS — единая спецификация учёта затрат и потребления.

В Broadcom убеждены, что финансовая прозрачность должна быть стратегическим преимуществом, а не источником ручной работы. Именно поэтому VCF 9.1 реализует поддержку FinOps Open Cost & Usage Specification (FOCUS) — глобального стандарта, позволяющего привести разрозненные данные о затратах к единому виду для сопоставимого анализа.

Что такое FOCUS?

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

Как работает FOCUS

FOCUS нормализует биллинговые данные из различных источников, сокращая объём работы, необходимой для начала FinOps-анализа, и позволяя переключить усилия на более стратегические задачи. Стандарт упрощает FinOps-цикл, приводя разрозненные данные о выставлении счетов из облачных, SaaS- и внутренних источников к согласованному, удобному для работы формату — как для генераторов данных, так и для их потребителей. Упрощение процесса получения данных позволяет организациям перейти от ручной обработки к стратегическим результатам: оптимизации затрат и оценке бизнес-ценности.

Кто использует FOCUS

FOCUS формирует общий словарь, устраняющий разрыв между генераторами биллинговых данных (облачными и SaaS-провайдерами) и их потребителями (FinOps-специалистами).

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

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

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

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

Актуальность в 2026 году

Финансовая прозрачность перестала быть опцией — наступила точка перелома. По данным исследования The Linux Foundation, конкурентная среда к 2026 году кардинально изменилась:

98% команд теперь управляют расходами на AI - резкий рост по сравнению с 31% в 2024 году.
78% FinOps-специалистов подчиняются напрямую CTO или CIO, что свидетельствует о стратегическом повышении роли управления затратами.
Более $83 млрд облачных расходов отслеживается с использованием стандартизированных практик.

Бизнес-ценность FOCUS

FOCUS создаёт значительную бизнес-ценность, обеспечивая отслеживание затрат на AI и GPU-нагрузки в реальном времени, автоматизированное устранение избыточных расходов и формирование стратегических дашбордов для руководства в рамках VMware Cloud Foundation.

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

VCF + FOCUS = 100% покрытие сценариев использования

VCF Operations обеспечивает 100-процентное покрытие стандартных FinOps-сценариев, определённых спецификацией FOCUS. Восемь возможностей доступны «из коробки», ещё четыре легко настраиваются — таким образом, инфраструктура частного облака на базе VCF Operations полностью соответствует глобальным стандартам.

Заключение: финансовая ясность как конкурентное преимущество

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

Подробности доступны на странице VMware Cloud Foundation Operations.

Демо VMware VCF 9.1 Protection and Recovery, показывающее, как восстановиться после атаки ransomware

Tue, 02 Jun 2026 17:18:07 UTC

Дункан Эппинг записал новое демо-видео для решения VMware VCF 9.1 Protection and Recovery, ранее известного как VMware Live Recovery. В этом демо он показывет процесс восстановления после атаки ransomware. Дункан в деталях делится тем, насколько просто это делается на этой платформе, а также то, что она включает интеграцию как с Carbon Black, так и с CrowdStrike.

VMware VCF 9.1: ускорение, упрощение и контроль самообслуживания в частном облаке

Fri, 29 May 2026 12:07:59 UTC

Платформа VMware Cloud Foundation (VCF) заметно прогрессирует от выпуска к выпуску. Версия 9.1 продолжит развитие возможностей, заложенных в VCF 9.0, и предложит более совершенный опыт потребления в рамках модели самообслуживания (self-service) частного облака.

По данным опроса заказчиков Broadcom, проведённого в марте 2026 года и посвящённого оценке VCF 9, компании, применяющие VCF Automation, добились двух существенных результатов. Во-первых, промежуток времени от запроса до готовой к использованию прикладной среды сократился на 49%. Во-вторых, ручные усилия по сопровождению жизненного цикла приложений — от разворачивания и обновления до установки патчей и изменения конфигурации — уменьшились ещё на 49%.

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

1. Ускоренное развёртывание благодаря расширенным сервисам

Container as a Service

В VCF 9.1 ускорение развёртывания контейнеров достигается за счёт чёткого разделения трёх вариантов исполнения — VM Service, Container Service и VMware vSphere Kubernetes Service (VKS). Такое разграничение позволяет подобрать подходящий runtime под конкретную нагрузку без излишних сложностей.

VCF Automation обеспечит доступ к Container Service с полным управлением жизненным циклом. Разворачивать, настраивать, отслеживать, обновлять и удалять контейнеры можно будет прямо через интерфейс — без команд kubectl, без YAML-файлов и без необходимости разбираться в Kubernetes API. Контейнеры станут полноценными runtime-сущностями наряду с виртуальными машинами и кластерами VKS.

Такой упрощённый контейнерный runtime обеспечит высокую гибкость без операционных издержек, связанных с инфраструктурой Kubernetes. Он будет работать непосредственно на ESX без накладных расходов на кластер, предоставляя изоляцию нагрузок и эффективное использование ресурсов в управляемом, по сути serverless-режиме. Платформа VCF полностью автоматизирует планирование, изоляцию, оптимизацию производительности и обновления. Когда архитектура приложения будет развиваться, интерфейс сформирует согласованный YAML, обеспечивающий плавный переход к кластерам VKS — мягкий путь от простых развёртываний контейнеров к полноценным возможностям Kubernetes.

VCF Automation: интерфейс развёртывания Container Service

Fast Deploy для VKS и виртуальных машин

В VCF 9.1 появится механизм Fast Deploy, существенно ускоряющий выделение виртуальных машин и кластеров VKS. После обновления функция автоматически активируется для каждой ВМ, разворачиваемой из blueprint, и не требует настройки в интерфейсе. Работая прозрачно через YAML, она ускорит все жизненные операции на базе виртуальных машин, в том числе развёртывания VM Service и инициализацию кластеров VKS.

Fast Deploy получит два режима под разные сценарии. Linked-Mode использует цепочку связанных клонов с delta-disk и обеспечит мгновенное включение виртуальной машины, при этом полный диск формируется асинхронно в фоне — это сокращает и время развёртывания, и расход хранилища. Direct-Mode ускоряет выделение в зависимости от размера образа ВМ и числа параллельных операций, давая более быстрое развёртывание в масштабе с сохранением полной целостности диска с самого начала.

Развёртывание кластеров VKS заметно ускорится — с 37 минут до 11 минут, то есть на 69%. Обновления кластеров будут выполняться на 75% быстрее: 1,7 часа вместо 6,9 часа, что экономит более 5 часов на каждый цикл обновления. Команды разработки приложений смогут применять Fast Deploy, чтобы по запросу поднимать среды разработки, динамически масштабировать нагрузки, оперативно создавать тестовые окружения, повторяющие промышленные среды, а также быстро разворачивать многоуровневые приложения.

VCF Automation: рабочий процесс Fast Deploy

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

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

Вместе с релизом будут поставляться десять предустановленных сервисов, автоматически синхронизируемых в составе базовой конфигурации платформы. Они отображаются в интерфейсе в виде отдельных плиток: Harbor, VMware Data Services Manager, Secret Store Service, сервис автоподключения для управления кластерами VKS (Auto-Attach Service), Encryption Management (BYOK) и другие.

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

VCF Automation: интерфейс управления сервисами

Расширенный Day-2 жизненный цикл виртуальных машин

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

Сетевые улучшения

Расширенное управление IP для провайдеров и арендаторов

Арендаторы смогут самостоятельно резервировать IP-адреса и управлять ими с поддержкой нескольких CIDR и интеграцией с Infoblox. Это позволит реализовывать сложные сетевые конфигурации, например NAT «один к одному», без зависимости от рабочих нагрузок.

Гибкие Transit Gateway для сложных топологий маршрутизации

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

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

В VCF 9.1 будет доступно сетевое самообслуживание, предоставляющее прямой доступ к ЦОД, выведение частных сетей, развертывание VPN и Gateway Firewall. Это расширит возможности арендаторов и позволит им самостоятельно управлять сетевой безопасностью.

Общие подсети и VLAN-расширения

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

Подключение к существующим VLAN через распределённые Transit Gateway

VCF 9.1 представит распределённые Transit Gateway, которые подключают VPC напрямую с хостов ESX с использованием только идентификатора VLAN, без Edge-кластеров и динамической маршрутизации. Это упростит эксплуатацию для унаследованных VLAN-окружений и обеспечит прямую коммуникацию между виртуальными машинами VCF и не-NSX ВМ.

Упрощённые межсетевые экраны и автоматизированная безопасность между VPC

VCF 9.1 позволит реализовать модель Zero Trust с автоматизированной микросегментацией, правилами межсетевого экрана и метками соответствия с использованием vDefend. Это даст автоматизированную безопасность с первого дня, исключая ручную настройку и обеспечивая единообразное применение политик.

Подробности доступны в release notes.

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

App Stack Formation

В VCF 9.1 будет реализован сценарий формирования прикладного стека (App Stack Formation) — принципиально новый подход к созданию blueprint. Он позволит пользователям зафиксировать работающую топологию — группу ВМ, их сетевую конфигурацию и диски — в виде единого blueprint. Эта возможность превратит живые среды приложений в переиспользуемые шаблоны, обеспечивая мгновенную, идентичную и масштабируемую доставку сервисов.

Вместо повторной сборки среды с нуля платформенные инженеры смогут фиксировать работающие ВМ вместе с их сетевыми настройками (VPC, подсети), дисками хранения (PVC), параметрами гостевой ОС и зависимостями между ВМ. Также можно будет задать последовательности запуска и остановки виртуальных машин внутри стека, чтобы многоуровневые приложения запускались в правильном порядке. Многоуровневые приложения будут собираться в единый переносимый пакет OVF/OVA, что устранит расхождения между средами Dev, Test и Prod. Управление всем прикладным стеком как одним объектом упростит операции старта/остановки и снапшотов с поддержкой заданного порядка включения. Провайдеры смогут предлагать готовые прикладные стеки через каталоги, развивая самообслуживание для арендаторов и сокращая время вывода новых сервисов на рынок.

VCF Automation: рабочий процесс App Stack Formation

Автоматизация доставки образов ОС Canonical Ubuntu

В VCF 9.1 появится встроенная интеграция с библиотеками контента Canonical, обеспечивающая поставку оптимизированных под VCF образов Ubuntu LTS. В эти образы включены пакеты — драйверы ВМ и инструменты, необходимые для успешного развёртывания и работы поверх VCF; они входят в базовую лицензию VCF для клиентов с активной подпиской.

Интерфейс обеспечит удобный поиск и выбор образов Ubuntu непосредственно в VCF Automation, избавляя пользователей от необходимости переходить на внешние сайты для поиска и импорта этих образов. Корпоративные ИТ-администраторы смогут подписаться на сопровождаемые Canonical библиотеки контента и автоматически синхронизировать официальные образы Ubuntu (например, 24.04 LTS) прямо в окружение, пополняя VM Images без ручных загрузок. Это обеспечит стабильность развёртываний, повышенный уровень безопасности и операционную эффективность за счёт эффективного управления патчами для критических уязвимостей и уязвимостей высокого уровня. Broadcom будет включать актуальные патчи в полные образы и размещать их в каталоге решений, гарантируя автоматическую поставку официального и проверенного контента. Клиенты получат упрощённый доступ к доверенным образам Ubuntu через защищённое нативное подключение.

VCF Automation: библиотека контента Canonical

Библиотеки контента на уровне проектов для автономии команд

В VCF 9.1 будут реализованы Project-level Content Libraries: администраторы организации смогут создавать отдельные библиотеки контента и явно привязывать их к одному или нескольким выбранным проектам внутри организации. После создания система предоставит право записи администраторам проектов и продвинутым пользователям проектов, позволяя им непосредственно публиковать, писать и управлять образами (например, ISO и OVA) в рамках выделенной библиотеки.

Это обеспечит автономию, снизив зависимость команд проектов от администраторов организации в части курирования и сопровождения библиотек контента, специфичных для проектов и приложений. Также появится возможность расширения: можно будет применять процессы Packer, в которых участники проектов публикуют собственные образы ВМ. Дополнительно VI-администраторы смогут использовать существующие шаблоны ВМ для построения библиотек контента VCF Automation без необходимости создавать новые образы. Это устранит операционное узкое место, при котором команды проектов прежде не могли управлять собственными библиотеками или напрямую загружать необходимые файлы вроде ISO и OVA, что в итоге шло вразрез с идеей потребительского самообслуживания и тормозило гибкую разработку.

VCF Automation: управление библиотекой контента проекта

Дополнительные возможности

Делегирование пространств имён и управление

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

Расширения Terraform Provider для арендаторов в политике и управлении контентом

В VCF 9.1 будет расширен Terraform Provider с поддержкой полного развёртывания окружений, управления жизненным циклом образов ВМ и реализацией политик как кода, Day-2-операций и IaaS. Это позволит программно применять политики и реализовывать сценарий App Stack Formation через подход infrastructure-as-code.

Подробности доступны в release notes.

3. Усиленное управление, безопасность и прозрачность затрат

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

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

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

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

VCF Automation: конфигурация политики размещения

Прозрачность затрат, тарификация, уведомления (оповещения, отчёты, счета)

VCF 9.1 будет выводить данные о затратах прямо в панелях управления Org и Project, позволяя администраторам видеть совокупные затраты на этих уровнях и переходить к детализации по конкретным затратам и инвентарю для отдельных проектов и пространств имён. VCF Automation предложит предварительную тарификацию (оценку стоимости по rate card VCF Operations) в рамках процесса развёртывания, давая администраторам возможность назначать цены сервисам частного облака, таким как VM Service и VKS Service. VCF Automation поддержит оповещения и отчёты по электронной почте. Администраторы смогут указывать конкретные адреса для получения уведомлений по биллингу, отчётам о затратах и критическим оповещениям — в частности, по квотам или доступности сервисов — с возможностью формирования и прямой загрузки отчётов и счетов.

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

VCF Automation: панель прозрачности затрат

Полностью выделенные региональные квоты для организаций-арендаторов

В VCF 9.1 появится механизм полностью выделенной региональной квоты, позволяющий корпоративным ИТ-администраторам выделять всю ёмкость региона (квоту 100%) одной организации-арендатору без привязки к конкретным зонам. Администраторы смогут применять одинаковые лимиты и резервации CPU и памяти ко всем доступным зонам, отвязывая регион от единственного Supervisor и допуская наличие нескольких Supervisor и vCenter в рамках одной региональной квоты. Эти возможности упростят выделение ресурсов и облегчат управление инфраструктурой для предприятий, которым не требуется строгое исполнение квот.

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

VCF Automation: распределение региональных квот

Единый API управления кластерами VKS

VCF 9.1 стандартизирует API управления кластерами VKS, приведя его к шаблону VCF API и объединив управление ВМ, контейнерами и VKS. Это обеспечит согласованное взаимодействие со всеми сервисами и упростит управление ресурсами через VCF CLI, Terraform или kubectl.

Подробности доступны в release notes.

Самообслуживание в частном облаке от Broadcom

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

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

Новые возможности VMware Workstation 2026 H1 и VMware Fusion 2026 H1

Thu, 28 May 2026 07:48:37 UTC

Недавно компания VMware объявила о доступности для загрузки новых версий настольных платформ виртуализации - VMware Workstation 26H1 и VMware Fusion 26H1. Эти обновления продолжают эволюцию наших настольных гипервизоров, обеспечивая критически важные архитектурные переходы для пользователей Windows, расширенную видимость для управления виртуальными машинами и расширенную поддержку новейшего оборудования и операционных систем.

Новый релиз развивает фундаментальные изменения, представленные в предыдущем обновлении 25H2, где был осуществлен переход на календарное версионирование и представлены мощные инструменты автоматизации, такие как dictTool. В 2026 году сохраняется фокус на том, чтобы среда виртуализации оставалась современной, эффективной и соответствующей отраслевым стандартам.

Современное архитектурное соответствие: 64-битная VMware Workstation Pro

С релизом 26H1 VMware Workstation Pro для Windows теперь является 64-битным приложением. Этот переход гарантирует, что большинство бинарных файлов, библиотек и компонентов установщика выполняются как 64-битные процессы. Приводя гипервизор в соответствие с современными аппаратными и программными стандартами, VMware предоставляет более стабильную и производительную основу для самых требовательных виртуализированных рабочих нагрузок.

Расширенная видимость и упрощенное управление

Управление сложной библиотекой виртуальных машин требует быстрого доступа к информации. Развивая организационные улучшения, появившиеся в последних релизах, релиз 26H1 представляет новые функции «качества жизни», которые помогут вам поддерживать порядок:

Метки времени жизненного цикла (VMware Workstation и Fusion): мгновенно идентифицируйте виртуальные машины по времени их создания и последнего включения. Это упрощает отслеживание долгосрочных проектов и очистку временных тестовых сред.
Интегрированные заметки к папкам (VMware Workstation): заметки виртуальных машин перенесли непосредственно во вкладки папок в VMware Workstation. Это обеспечивает немедленный доступ к критически важным метаданным и документации без необходимости переходить через отдельные меню настроек.
Повышенная ясность Credential Manager (VMware Workstation): формат сохраненных учетных данных для зашифрованных виртуальных машин и удаленных серверов был модернизирован для VMware Workstation. Это помогает обеспечить простую идентификацию записей, относящихся к VMware, во встроенном менеджере учетных данных вашей хостовой платформы.

Расширение удаленного подключения к серверам ESXi ARM

По мере диверсификации сред разработки кросс-архитектурное подключение становится необходимым. Этот релиз добавляет возможность подключения к удаленным ARM-based ESXi, позволяя пользователям управлять виртуальными машинами на удаленных ARM-серверах напрямую из VMware Workstation или Fusion на любой поддерживаемой платформе. На данный момент ESXi ARM Server находится в режиме Tech Preview.

Поддержка ведущих ОС и оборудования

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

Поддержка новых гостевых ОС (VMware Workstation и Fusion):

Ubuntu 26.04 LTS
Fedora 43 и 44
SUSE Linux Enterprise 16 и openSUSE 16.0
FreeBSD 15.0

Поддержка новых хостовых ОС (VMware Workstation):

Ubuntu 26.04 LTS
Fedora 43 и 44
SUSE Linux Enterprise 16 и openSUSE 16.0

Стабильность и надежность

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

Ресурсы для клиентов и доступность

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

Workstation Pro и Fusion Pro 26H1 доступны уже сегодня через Broadcom Support Portal. Напоминаем, что оба продукта остаются бесплатными для коммерческого, образовательного и личного использования, предоставляя каждому профессионалу доступ к ведущему настольному гипервизору в отрасли.

Загрузки продуктов и примечания к релизу

Взгляд в будущее

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

Обновление аппаратного обеспечения виртуальной машины vCenter в vSphere с VCF 9.1

Tue, 26 May 2026 01:00:00 UTC

Аппаратная версия виртуальной машины vCenter оставалась на уровне версии 10 (совместима с VMware ESX 5.5 и более поздними) со времён VMware vSphere 5.5. С выходом vSphere в составе VMware Cloud Foundation 9.1 она обновлена до версии 17.

Примечание: в зависимости от интерфейса, статьи базы знаний или технической документации могут использоваться взаимозаменяемые термины «совместимость виртуальной машины», «совместима с ESX версии» или «версия аппаратного обеспечения виртуальной машины». Для ясности: виртуальное аппаратное обеспечение версии 17 в интерфейсе vSphere Client обозначается как «Compatible with ESXi 7.0 and later».

Об обновлении аппаратной версии виртуальной машины vCenter

При выполнении мажорных апгрейдов (с 8.x до 9.1.0) или минорных обновлений (с 9.0.x до 9.1.0) методом Reduced Downtime Upgrade аппаратная версия виртуальной машины vCenter обновляется автоматически с версии 10 до версии 17, поскольку создаётся новая ВМ vCenter.

После выполнения in-place обновления vCenter (с 9.0.x до 9.1.0) аппаратную версию ВМ vCenter необходимо обновить вручную. Эта процедура требует выключения виртуальной машины vCenter.

Если виртуальная машина vCenter является «самоуправляемой», её необходимо выключить и выполнить обновление аппаратного обеспечения ВМ до версии 17 через ESX Host Client. Подробности — в документации Upgrade Virtual Machine Compatibility by Using the VMware Host Client.

Если виртуальная машина vCenter управляется другим экземпляром vCenter, её необходимо выключить и выполнить обновление аппаратного обеспечения ВМ до версии 17 через vSphere Client. Подробности — в документации Upgrade the Compatibility of a Virtual Machine Manually.

Обновление аппаратного обеспечения ВМ необратимо — откатить версию назад невозможно. Перед обновлением аппаратной версии ВМ vCenter рекомендуется создать снапшот виртуальной машины или выполнить её резервное копирование.

Важно: необходимо выбирать именно Compatible with ESXi 7.0 and later (версия 17). Если выбрана более поздняя версия, vCenter окажется в неподдерживаемом состоянии — потребуется восстановление из снапшота или из более ранней резервной копии vCenter.

Также доступна возможность запланировать обновление аппаратной версии при следующей перезагрузке.

Подробности — в документации Schedule a Compatibility Upgrade for a Virtual Machine.

Совет: рекомендуется включить запланированное обновление аппаратной версии до начала in-place обновления vCenter до версии 9.1. Поскольку обновление требует перезагрузки, можно совместить обновление vCenter до 9.1 и обновление аппаратной версии ВМ в рамках одного цикла перезагрузки.

Почему именно версия 17?

Краткий ответ: обратная совместимость. Виртуальное аппаратное обеспечение версии 17 поддерживается на хостах ESX 7.0 и более поздних. Инфраструктурные обновления нередко выполняются постепенно, а устаревшее и даже не поддерживаемое оборудование продолжает использоваться в производственных средах. Возможность запускать vCenter версии 9.1 на более старых хостах ESX предоставляет клиентам гибкость: они могут перейти на vCenter 9.1, не торопясь с миграцией на новые аппаратные платформы. Миграция между управляющими серверами (Cross-vCenter migration) позволит перенести ВМ vCenter на новую инфраструктуру в удобный момент.

Будет ли аппаратная версия vCenter обновляться снова?

Да. Цель — поддерживать аппаратную версию ВМ vCenter по модели N-1 относительно мажорных версий ESX. Например, текущая мажорная версия ESX — 9.x, следовательно, версия N-1 — это 8.x.

Необходимо также учитывать, что vCenter всегда обновляется раньше ESX. Аппаратная версия ВМ vCenter не может быть повышена до уровня, который ещё не обновлённый ESX не в состоянии обеспечить.

Полный список версий аппаратного обеспечения виртуальных машин доступен по ссылке: Virtual Machine Hardware Versions.

Что нового в VMware vSphere в новой версии VMware Cloud Foundation 9.1

Mon, 25 May 2026 01:00:00 UTC

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

Быстрое развёртывание патчей безопасности vCenter

Функция быстрого патчинга vCenter (vCenter Quick Patch) обеспечивает оперативное применение обновлений с минимальным, а в ряде случаев — нулевым временем простоя. Уровень простоя зависит от того, какие именно сервисы подвергаются обновлению. Механизм Quick Patch ориентирован на быстрое устранение критических уязвимостей безопасности в vCenter.

Традиционный in-place патчинг обновляет все RPM-пакеты на vCenter вне зависимости от того, изменился ли соответствующий сервис или компонент. Quick Patch затрагивает только те RPM или бинарные файлы, которые действительно изменились в составе патча. Такой подход кардинально сокращает общее окно обслуживания и снижает время простоя vCenter до менее чем 1 минуты, а в ряде случаев сводит его к нулю.

Благодаря vCenter Quick Patch критически важные обновления безопасности можно применять без прерывания рабочих процессов: развёртывание виртуальных машин и кластеров Kubernetes продолжается в штатном режиме, автоматизированные сценарии и API-вызовы не прерываются. Меньше времени уходит на планирование окон обслуживания — больше на поддержание актуальности патчей.

Подробности — в статье о vCenter Quick Patch.

Упрощение обслуживания vCenter

Помимо Quick Patch, в версии 9.1 улучшены и другие аспекты обслуживания vCenter.

Обновление vCenter с сокращённым временем простоя (Reduced Downtime Upgrade, RDU) теперь поддерживает работу с онлайн-репозиторием. Это упрощает использование метода RDU для подключённых к интернету экземпляров vCenter. Автономный метод с использованием примонтированного ISO по-прежнему доступен. Последующие патчи, обновления и апгрейды vCenter 9.1.x и более поздних версий также можно применять через RDU с онлайн-репозиторием, что значительно упрощает эксплуатацию для подключённых инсталляций.

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

При выполнении мажорных апгрейдов (с 8.x до 9.1.0) или минорных обновлений (с 9.0.x до 9.1.0) методом RDU версия аппаратного обеспечения виртуальной машины vCenter автоматически повышается с версии 10 до версии 17, поскольку создаётся новая ВМ vCenter. При выполнении in-place обновления (с 9.0.x до 9.1.0) версию аппаратного обеспечения ВМ vCenter потребуется обновить вручную — эта процедура требует выключения ВМ vCenter.

Изменение ресурсов vCenter через единый API

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

Вызов API можно инициировать из Developer Center API Explorer в интерфейсе vCenter. API называется deployment/size и использует метод PATCH.

Упрощение обслуживания хостов ESX

Образы, создаваемые и управляемые через vSphere Lifecycle Manager, теперь включают контрольную сумму SHA256. Она позволяет проверять целостность образов при экспорте и импорте в другие экземпляры vCenter: администратор может сравнить контрольные суммы на источнике и целевом сервере. Речь идёт о контрольной сумме именно определения образа, а не VIB-файлов ESX.

В предыдущих версиях vSphere Lifecycle Manager проверял актуальность прошивок и драйверов устройств по HCL только при наличии стороннего Hardware Support Manager (HSM). Начиная с версии 9.1 вывод информации о текущих драйверах и прошивках устройств, а также их валидация по HCL выполняются для кластеров vSAN даже в отсутствие HSM. Некоторые устройства могут не сообщать данные о прошивке без соответствующего HSM. Это обеспечивает базовый уровень проверки устройств в кластере vSAN.

Подготовка кластеров vSphere с образом и конфигурацией

Zero Touch Provisioning (ZTP) строится на базе существующей инфраструктуры vSphere Auto-Deploy. Механизм задействует современные протоколы загрузки — UEFI HTTP/S Boot — и поддерживает актуальные серверные конфигурации, включая Secure Boot и TPM. ZTP не требует внешнего TFTP-сервера: достаточно настроить URL загрузки UEFI, указывающий на vCenter, и загрузить хост по сети. Если UEFI не поддерживает настройку статического IP для загрузки, потребуется DHCP-сервер.

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

Быстрое и менее затратное обновление кластеров vSphere

ESX Live Patch включён по умолчанию для всех кластеров и автоматически применяется, если устанавливаемый патч поддерживает этот режим. Если патч несовместим с Live Patch, по умолчанию используется стандартный метод с переходом в режим обслуживания и перезагрузкой хоста.

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

ESX Live Patch теперь поддерживает серверы с включённым TPM. Пользователям не нужно отключать TPM или отказываться от Live Patch при использовании ESX 9.1 и более поздних версий.

Поддержка Live Patch расширена: охватывает больше компонентов vmkernel и обеспечивает более высокую производительность при патчинге ядра. Теперь механизм поддерживает дополнительные пользовательские демоны и сервисы, включая демоны vSAN, базовые демоны хранилища и соответствующие библиотеки.

Расширение интеграции с механизмом Desired State Configuration

Профили конфигурации vSphere (vSphere Configuration Profiles) обеспечивают соответствие изменений конфигурации и операций по устранению отклонений требованиям vSAN. Политики режима обслуживания vSAN и политики доступности объектов соблюдаются при исправлении кластеров vSAN. Расширенная конфигурация vSAN может применяться на уровне всего кластера.

Профили конфигурации vSphere используются для настройки memory tiering на хостах кластера. Устройства NVMe могут быть выделены для memory tiering; дополнительное устройство NVMe опционально может быть задействовано в качестве зеркального устройства для программного зеркалирования.

Профили конфигурации vSphere обеспечивают конфигурацию хостов при установке через Zero Touch Provisioning, а также поддерживают начальную настройку vSphere Distributed Switch в процессе развёртывания хоста.

Оптимизация Desired State Configuration

При добавлении новых хостов в кластеры с включёнными профилями конфигурации vSphere желаемая конфигурация автоматически применяется к входящему хосту. Специфичные для хоста атрибуты (например, IP-адреса) извлекаются из него автоматически и добавляются в соответствующий раздел профиля кластера.

Автоматическое устранение отклонений отключено по умолчанию и может быть включено как на уровне vCenter, так и на уровне отдельного кластера. Подробности — в руководстве How to Configure the vSphere Lifecycle Manager Remediation Settings.

Автоматическое управление сертификатами

Сертификат TLS для vCenter теперь обновляется автоматически за 5 дней до истечения срока действия. Сертификат ESX обновляется за 30 дней до истечения. Порог для ESX настраивается через расширенные параметры vCenter Server с помощью параметра vpxd.certmgmt.certs.autoRenewThreshold.

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

Если до истечения срока действия корневого сертификата VMCA остаётся менее 1 года, в процессе обновления vCenter автоматически обновляются корневой сертификат VMCA, а также дочерние сертификаты решений. Сертификаты TLS для vCenter и ESX в рамках этой операции не обновляются.

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

В крупных и сверхкрупных развёртываниях vCenter ожидается увеличение числа операций в минуту до 25%. Это касается множества операций с виртуальными машинами и хостами, а также изменений конфигурации. Масштаб одновременных операций резервного копирования ВМ увеличен до 500–1000 в зависимости от размера vCenter. Операции резервного копирования ВМ теперь защищены от бесконтрольного потребления всех ресурсов vCenter. Передача файлов использует выделенные потоки, что исключает влияние на другие операции vCenter. Расширенные параметры vCenter для операций резервного копирования позволяют настраивать масштабируемость под конкретную среду.

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

Введены два новых оповещения — High Session Count и Increased Request Load — для сигнализации о нагрузке на один или несколько сервисов vCenter. Оповещение High Session Count срабатывает, когда число сессий приближается к лимиту (по умолчанию 3000); в сообщении указываются IP-адреса и имена пяти пользователей, создавших наибольшую нагрузку с более чем 100 сессиями каждый. При изменении состава топ-5 пользователей генерируется новое событие. В список могут попасть любые пользователи, включая сервисные аккаунты. Оповещение Increased Request Load срабатывает при достижении лимита активных запросов к конечной точке сервиса (по умолчанию 1024 для большинства конечных точек) и содержит информацию о затронутых сервисах и конечных точках.

Гибкая настройка виртуальных машин

Для поддержки миграции с VMware Cloud Director (vCD) на VMware Cloud Foundation Automation (VCFA) гостевой API настройки ОС (Guest OS Customization, GOSC) дополнен следующими возможностями, обеспечивающими паритет с функциями vCD:

Установка пароля учётной записи root в Linux
Сброс пароля учётной записи root в Linux
Сброс паролей учётных записей группы администраторов в Windows
Выполнение скриптов настройки в Windows

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

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

Сохранение производительности рабочих нагрузок во время обслуживания хоста

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

При переводе хоста в режим обслуживания для кластеров с включённым DRS доступны два варианта:

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

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

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

Улучшение утилизации ресурсов vMotion и снижение конкуренции

Максимальное количество одновременных задач vMotion по умолчанию равно 8. В предыдущих версиях, если 8 задач vMotion выполнялись одновременно в рамках пакетной операции, новые задачи не начинались до завершения всех предыдущих. Начиная с vSphere 9.1, как только одна задача vMotion завершается и освобождается слот, следующая задача может немедленно стартовать.

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

Более высокая пропускная способность vMotion и сокращение времени миграции

В VCF 9.1 появилась возможность разгрузки операций зашифрованного vMotion на Intel QAT (QuickAssist Technology). Это освобождает ценные ресурсы CPU и возвращает их рабочим нагрузкам.

Для максимально эффективного использования ресурсов в VCF задействована технология Intel QAT (QuickAssist Technology) для ускорения инфраструктурных операций. Перенос «тяжёлой» части задач vMotion на выделенное аппаратное обеспечение позволяет вернуть ценные ядра CPU реальным рабочим нагрузкам. Intel QAT берёт на себя шифрование данных при выполнении операций vMotion.

Оптимизированная масштабируемость и производительность для современных CPU

Планировщик Topology Aware Scheduler перешёл на событийно-ориентированный механизм встроенного обновления, что обеспечивает более согласованное и сбалансированное размещение по NUMA-узлам.

Архитектура NUMA (Non-Uniform Memory Access) используется для повышения масштабируемости и производительности серверов с несколькими процессорными сокетами. Планировщик — компонент ядра ESX, отвечающий за управление размещением виртуальных машин и балансировкой нагрузки по NUMA-узлам с целью минимизации задержек доступа к памяти и оптимального использования ресурсов CPU и памяти рабочими нагрузками.

Topology Aware Scheduler оптимизирован для нового поколения высокоплотных процессоров: улучшена модель оценки эффективности использования CPU и памяти. Существующий планировщик при принятии решений о размещении в основном учитывал конкуренцию за CPU (ready time). Topology Aware Scheduler учитывает не только конкуренцию за CPU, но и конкуренцию за кэш и пропускную способность памяти.

Для систем с асимметричной топологией NUMA, где расстояние между некоторыми парами узлов существенно больше, чем между другими, Topology Aware Scheduler может размещать смежные NUMA-клиенты одной ВМ на подмножестве узлов, расположенных ближе друг к другу.

Готовность к работе с AI-платформами различных производителей

В VCF 9.1 расширена поддержка Enhanced DirectPath I/O.

Речь идёт не просто о «проброске» оборудования, а о его виртуализации — это обеспечивает лучшую утилизацию ресурсов и возможность выполнения операций обслуживания и масштабирования без остановки AI-рабочих нагрузок. Поддержка новых аппаратных устройств в VCF 9.1 открывает доступ ко многим преимуществам виртуализации, включая stun-based операции и быстрое приостановление и возобновление работы. Среди этих преимуществ:

Storage vMotion
Снапшоты (включая снапшоты памяти)
Операции реконфигурации дисков
Горячее добавление и удаление виртуальных устройств
ESX Live Patch

ESX 9.1 расширяет свои возможности, внедряя поддержку виртуализации IOMMU для CPU AMD. Теперь администраторы могут задействовать устройства PCI passthrough на системах на базе AMD, повышая производительность и обеспечивая прямой доступ к оборудованию для виртуальных машин.

AMD vIOMMU (Virtual I/O Memory Management Unit) — аппаратно-ускоренная технология, обеспечивающая безопасный высокопроизводительный прямой доступ к памяти (DMA) для виртуальных машин за счёт прямого доступа гостевых систем к регистрам MMIO.

Flow Processing Offload (FPO) и аппаратное направление трафика (hardware steering) повышают эффективность центра обработки данных, перенося обработку сложных сетевых правил с CPU на выделенное аппаратное обеспечение. Это обеспечивает производительность на уровне линейной скорости и быструю масштабируемость виртуализированных сред, освобождая ресурсы CPU для бизнес-приложений.

Enhanced DirectPath I/O поддерживает прямую связь GPU-to-GPU через RDMA over Converged Ethernet (RoCE). Решение предназначено для организаций, выполняющих массивные AI-рабочие нагрузки или высокоскоростную обработку данных: оно обеспечивает производительность, близкую к нативной (необходимую для AI), без отказа от инструментов управления, которые упрощают эксплуатацию виртуализованных ЦОД.

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

Функция vCenter Quick Patch в VMware Cloud Foundation 9.1

Fri, 22 May 2026 09:59:52 UTC

VMware vCenter является критически важным компонентом стека VMware Cloud Foundation (VCF), помогая администраторам балансировать между доступностью сервисов и необходимостью проводить регулярное обслуживание и установку патчей. Традиционный in-place патчинг vCenter может приводить к простою продолжительностью до часа и более. VMware Cloud Foundation 9.1 представляет механизм vCenter Quick Patch, выводящий процесс обновлений vCenter на принципиально новый уровень.

vCenter Quick Patch обеспечивает оперативное применение обновлений с минимальным, а в ряде случаев — нулевым временем простоя. Уровень простоя зависит от того, какие именно сервисы подвергаются обновлениям. Механизм Quick Patch ориентирован на быстрое развёртывание критических исправлений безопасности для vCenter.

Важно: как и в случае с ESX Live Patch, не каждый патч для vCenter совместим с Quick Patch — это определяется содержимым конкретного патча. Информация о совместимости с Quick Patch указывается в примечаниях к выпуску vCenter и в деталях патча непосредственно в интерфейсе продукта. Главная область применения vCenter Quick Patch — обновления безопасности.

Традиционный in-place патчинг обновляет все RPM-пакеты на vCenter вне зависимости от того, были ли изменения в соответствующем сервисе или компоненте. vCenter Quick Patch изменяет только те RPM или бинарные файлы, которые действительно претерпели изменения в составе патча. Такой подход кардинально сокращает общее окно обслуживания: время простоя vCenter снижается до менее чем 1 минуты, а в ряде случаев сводится к нулю.

vCenter Quick Patch позволяет применять критически важные патчи безопасности без прерывания рабочих процессов: развёртывание ВМ и кластеров Kubernetes продолжается в штатном режиме, автоматизированные сценарии и API-вызовы не прерываются, а затраты времени на планирование окон обслуживания сокращаются.

Применение vCenter Quick Patch выполняется через VMware Appliance Management Interface (VAMI) и использует тот же рабочий процесс, что и традиционный in-place патчинг. Патч, совместимый с Quick Patch, отмечается специальным значком Quick Patch. В деталях патча указываются влияние на рабочие нагрузки, затрагиваемые сервисы и ожидаемое время простоя. vCenter Quick Patch также можно применять с помощью CLI-методов. Специально выбирать метод Quick Patch не требуется: если патч поддерживает этот режим, vCenter автоматически использует его.

В представленном ниже примере ожидаемое время простоя составляет 0 минут, влияние на рабочие нагрузки отсутствует, а затрагиваемыми сервисами являются vmware-updatemgr и vsphere-ui.

При переходе на вкладку обновлений vCenter в vSphere Client отображается информация о том, что выбранный патч совместим с Quick Patch, с рекомендацией воспользоваться именно этим методом. Применение Quick Patch-совместимого обновления по-прежнему возможно через метод Reduced Downtime Update, однако это увеличит общее время обслуживания и продолжительность простоя.

Примечание: vCenter Quick Patch рекомендуется использовать для минорных патчей обслуживания, совместимых с Quick Patch (например, обновление vCenter с 9.1.0 до 9.1.1). Метод Reduced Downtime Update рекомендуется для минорных обновлений или мажорных апгрейдов (например, с vCenter 9.0.0 до 9.1.0).

Итог

vCenter Quick Patch обеспечивает оперативное применение обновлений с минимальным, а в ряде случаев — нулевым временем простоя. Уровень простоя определяется тем, какие сервисы задействованы в патче. Механизм Quick Patch ориентирован на быстрое развёртывание критических исправлений безопасности для vCenter.

Дополнительная информация — в документации: vCenter Quick Patches и Patching vCenter Using the vCenter Management Interface.

VMware Cloud Foundation Edge 9.1: автономная платформа для периферии

Thu, 21 May 2026 17:16:16 UTC

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

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

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

VCF Edge 9.1 развивает эту концепцию за счёт автономных периферийных операций — автоматизации развёртывания, управления жизненным циклом в масштабе и политик безопасности, в том числе в окружениях без подключения и в полностью изолированных (air-gapped) средах.

Автономные периферийные операции

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

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

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

Рисунок: гибкие топологии развёртывания VCF Edge для распределённых сред.

Ускорение развёртывания с помощью Zero-Touch Provisioning

Классические сценарии развёртывания периферии подразумевают ручную настройку, присутствие ИТ-специалистов на площадке и недели координации, из-за чего крупные внедрения идут медленно и дорого. VCF Edge снимает эти барьеры с помощью технологии Zero-Touch Provisioning (ZTP). После включения сервер безопасно загружается, подключается к централизованному управлению и получает полное целевое состояние — образ ОС, конфигурацию кластера и сетевые параметры, — что автоматизирует развёртывание от начала до конца. Скрипт активации Day 0 Activation Script гарантирует готовность каждой площадки к продуктивной работе вместе с платформенными сервисами и интеграцией GitOps.

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

Рисунок: Zero-Touch Provisioning > активация Day 0 > непрерывная поставка приложений.

Оптимизация производительности и стоимости через Advanced NVMe Memory Tiering

На периферии масштабирование инфраструктуры часто означает добавление новых серверов, что ведёт к росту стоимости, занимаемого пространства и энергопотребления. В VCF Edge добавлены улучшения в технологии NVMe Memory Tiering, которая расширяет системную память за счёт высокопроизводительных NVMe-устройств без дополнительной установки модулей DRAM. В результате повышается плотность размещения нагрузок, лучше используется имеющееся оборудование и появляется возможность отложить или вовсе отказаться от дорогостоящих обновлений инфраструктуры.

Рисунок: NVMe Memory Tiering для периферийной инфраструктуры (расширение памяти без добавления DRAM).

Единая платформа, готовая к AI-нагрузкам периферии

Управление инфраструктурой, Kubernetes и AI-сервисами в распределённых средах становится крайне сложной задачей. VCF Edge упрощает её за счёт единой платформы для виртуальных машин, Kubernetes и AI, что избавляет от необходимости развёртывать и обслуживать раздельные стеки.

Готовый к производственной среде Kubernetes на периферии

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

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

Простота без сложности Kubernetes

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

Рисунок: запуск контейнеров через vSphere Pods (CaaS без сложности Kubernetes).

AI на периферии без инфраструктурных компромиссов

Доступность GPU, их стоимость и ограничения по энергоснабжению нередко лимитируют список мест, где можно развернуть AI. VCF Edge позволяет запускать инференс AI-моделей вместе с уже работающими нагрузками с использованием GPU либо вычислений на CPU (через llama.cpp). Организации получают возможность размещать AI-сервисы ближе к источникам данных, не разворачивая отдельные инфраструктурные стеки. Итог — снижение стоимости инфраструктуры под AI, более быстрое внедрение сценариев применения AI и возможность охватить большее число периферийных площадок без обязательной установки GPU на каждой из них.

Ускорение AI-нагрузок с поддержкой GPU и других ускорителей

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

Рисунок: поддержка GPU и ускорителей для AI-нагрузок на периферии.

Распространение AI через инференс на CPU

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

Рисунок: CPU-инференс для периферийных сред (llama.cpp).

Непрерывная поставка через распределённые периферийные площадки

Поддержание согласованности на периферии — это не разовая задача развёртывания, а постоянный операционный вызов.

Централизованная дистрибуция образов (pull-модель)

VCF Edge обеспечивает непрерывность работы благодаря централизованной дистрибуции образов по pull-модели, использующей Content Library для синхронизации образов в рамках всего парка. Эта архитектура целенаправленно спроектирована под надёжную эксплуатацию в средах с низкой связностью, без подключения или полностью изолированных, поскольку позволяет каждой площадке хранить и управлять своим состоянием локально. Благодаря отказу от постоянного канала к управлению уменьшается потребление трафика, и каждая периферийная площадка остаётся отказоустойчивой автономной единицей, способной поддерживать согласованные развёртывания вне зависимости от внешней связи.

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

Автоматизация на основе GitOps для непрерывной поставки

После развёртывания инфраструктуры поддержание согласованности между распределёнными периферийными площадками требует непрерывной поставки и автоматизированного управления конфигурацией.

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

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

Рисунок: управление желаемым состоянием по GitOps в распределённых периферийных средах (Argo CD).

Наблюдаемость парка в реальном времени

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

Рисунок: наблюдаемость и мониторинг распределённых периферийных сред в реальном времени.

Защищённая и устойчивая периферия

Обеспечение безопасности на периферии сопряжено с трудностями: локальные ИТ-ресурсы ограничены, а риски распределены.

Live-патчинг без прерывания работы

VCF Edge поддерживает ESX Live Patching для хостов с TPM, что позволяет устанавливать до 80% патчей безопасности без перезагрузки. Обновления выполняются удалённо, без окон обслуживания, благодаря чему нагрузки остаются доступными непрерывно, а защита поддерживается в нужном масштабе.

Рисунок: ESX Live Patching без прерывания работы для периферийной инфраструктуры (хосты с TPM).

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

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

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