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

VMware AI Factory и новые AI-возможности VCF

Mon, 14 Sep 2026 07:20:01 UTC

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

Новые вызовы эпохи агентного AI

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

Эксплуатационная сложность: агентные рабочие нагрузки ведут себя не так, как традиционные запросы на вывод. Агенты выстраивают цепочки из десятков вызовов моделей, обращений к инструментам и циклов рассуждений. Традиционная инфраструктура попросту не создавалась под такой устойчивый и динамичный характер спроса. К трудностям развёртывания относятся:
- Развёртывание Day 0: вычислительные ресурсы, сети, хранилище, Kubernetes и сетевая инфраструктура.
- Эксплуатация Day 2: управление жизненным циклом, включая установку исправлений, обновления, версионирование моделей и миграции между фреймворками, — всё это превращается из отдельных проектов в непрерывные, накладывающиеся друг на друга циклы.
Рост затрат на токены: AI-агенты работают в итеративных циклах, поэтому потребление токенов масштабируется нелинейно. Более того, по прогнозам, к 2030 году стоимость токенов вырастет вплоть до 24 раз. Раздувание контекста, обмен сообщениями между несколькими агентами, исправление ошибок и рефлексия, а также внутренние промпты «размышления» — всё это примеры причин непредсказуемого удорожания токенов. Облачные LLM тарифицируются по числу токенов, и их пользователи уже сталкивались с неожиданным ростом расходов.
Пробелы в управлении: инженерные команды создают приложения и разворачивают автономных агентов быстрее, чем за ними успевают процессы приватности, безопасности, управления и эксплуатации. В результате возникла разрозненная среда, в которой у руководителей может не быть централизованной картины того, какие модели, инструменты и агенты используются и каким именно образом. Инфраструктура обязана обеспечивать детальный контроль приватности, а также доступа к инфраструктуре и данным, ограничивая то, что каждый агент может читать и изменять, — даже если сама базовая модель считается доверенной.

VMware Private AI Cloud

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

Экономичное масштабирование AI: VMware Private AI Cloud охватывает три основных источника затрат на AI — капитальные вложения в оборудование, эксплуатационную сложность и экономику токенов (токеномику). VCF поддерживает графические процессоры, CPU и ускорители ведущих производителей, а также серверное оборудование крупных OEM- и ODM-поставщиков, что позволяет заказчикам экономично эксплуатировать гетерогенные кластеры. Для оптимизации токеномики и использования ресурсов предусмотрены мониторинг токенов, мультитенантное совместное использование моделей, расширенный учёт GPU/vGPU и панель наблюдаемости AI-метрик. Одна из ключевых инноваций VMware Private AI Cloud — VMware AI Factory, обеспечивающая быстрый путь от развёртывания на «голом железе» до запуска первой модели.
Более безопасная эксплуатация: платформа VCF построена по принципу эшелонированной защиты в соответствии с NIST CSF 2.0 и противостоит угрозам, усиленным средствами AI, за счёт минимизации поверхности атаки и обеспечения непрерывного соответствия требованиям. Автоматические обновления, не нарушающие работу сервисов, поддерживают системы в актуальном состоянии, а VMware vDefend применяет виртуальное патчирование и горизонтальную защиту на уровне гипервизора с микросегментацией, реализуя принцип Zero Trust и блокируя эксплойты. Кроме того, многоуровневая защита от угроз vDefend, а также межсетевой экран уровня веб-приложений и защита API в VMware Avi Load Balancer предотвращают сложные атаки.
Быстрые инновации для эпохи агентного AI: в отличие от традиционных приложений, автономные AI-агенты способны действовать бесконтрольно, выходить за рамки своих полномочий или неверно истолковывать инструкции. Соответственно, доверие к ним зависит от надёжных механизмов контроля и целостности данных. VMware Tanzu Platform в связке с VMware vDefend формирует основу для доверенных корпоративных агентов за счёт архитектуры с запретом по умолчанию, готовой обвязки (harness) и курируемого маркетплейса.

Ниже — подробности о VMware AI Factory, ключевой инновации в составе VMware Private AI Cloud.

VMware AI Factory: движущая сила VMware Private AI Cloud

VMware AI Factory — это программно-определяемый фундамент VMware Private AI Cloud. Он даёт заказчикам упрощённый путь к промышленному AI благодаря новым средствам автоматизации развёртывания инфраструктуры, готовой к ИИ-нагрузкам, и поддержки операций Day 2. С VMware AI Factory заказчики могут быстрее выйти на развёртывание первой модели и эффективнее управлять токеномикой AI.

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

Партнёрства, обеспечивающие работу VMware AI Factory

VMware AI Factory сочетает VCF с сертифицированными серверами Dell PowerEdge и узлами VCF AI ReadyNodes от Cisco, Lenovo, Supermicro и других вендоров, а также с предпочитаемыми заказчиком программными средствами AI и архитектурами ускорителей.

Broadcom и AMD совместно работают над вариантом VMware AI Factory, объединяющим VCF с графическими процессорами AMD Instinct и открытой программной экосистемой AMD ROCm. Технология zero-touch provisioning будет оркестрировать сквозное развёртывание всего стека — от vSphere и vSAN до Kubernetes и оператора AMD GPU, — а драйвер AMD DVX сможет подключать графические процессоры к крупным виртуальным машинам, которые использует кластер VMware vSphere Kubernetes Service.

Для дальнейшего упрощения развёртывания VCF AI Factory Broadcom объявила о новом партнёрстве с MetalSoft, в рамках которого будет реализована интегрированная гетерогенная автоматизация работы с «голым железом» для VCF, сокращающая время подготовки физических серверов с недель до минут. Интеграция поможет ИТ-специалистам выделять или переразвёртывать физические серверы разных производителей напрямую через консоль управления VCF, объединяя жизненный цикл программного обеспечения и оборудования в единую операционную модель и снимая необходимость в специфичных для каждого вендора инструментах управления оборудованием и прошивками.

Новые возможности VMware AI Factory

Сервисы VCF Private AI Services помогают сделать AI управляемым, контролируемым и экономически эффективным и входят в состав VMware Cloud Foundation (VCF). Число сервисов, предлагаемых в рамках VCF Private AI Services, будет и дальше расширяться. Рассмотрим эти возможности подробнее.

Доступно в общем релизе

Мультитенантное совместное использование моделей

В релизе VCF 9.1.1 компонент Model Runtime был доработан так, чтобы обеспечить безопасное совместное использование AI-моделей между тенантами или отдельными направлениями бизнеса в их пространствах имён при полном сохранении приватности данных каждого из них. На практике это означает, что предприятия и облачные провайдеры теперь могут иметь один запущенный сервис Model Runtime, который обслуживает и масштабирует модели для всей организации, тогда как каждая команда или подразделение располагает отдельным приватным и защищённым пространством имён для своих данных. Эта возможность устраняет необходимость разворачивать избыточные копии модели, впустую расходуя выделенные GPU и инфраструктурные ресурсы. Одновременно сохраняются приватность и изоляция данных при оптимизации совокупной стоимости владения.

Возможности будущих релизов

AI Gateway

Чтобы сбалансировать сегодняшние потребности в оптимизации стоимости токенов, сценариях использования и производительности, предприятиям нужны модели, развёрнутые и в облаке, и локально. Облачные LLM могут потреблять большое количество токенов, поэтому управление ими приобретает первостепенное значение. Возможность AI Gateway существенно поможет в разрешении этих конкурирующих компромиссов. Вот конкретные детали:

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

Secure Agent Framework

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

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

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

Автоматическое масштабирование моделей

AI-нагрузки не умеют динамически реагировать на внезапные всплески запросов или агентные циклы. Для решения этой проблемы будет представлена возможность Model Autoscaling. С её помощью администратор или AI-оператор сможет задать пороговые значения по задержке и числу сессий, и при их достижении AI-модель будет масштабироваться автоматически, чтобы соблюдались SLA по задержке и производительности. Когда нагрузка опускается ниже порогового значения, рабочая нагрузка масштабируется в обратную сторону.

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

Другие AI-новинки и анонсы с Explore

Поддержка Broadcom широкого спектра моделей в составе VCF

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

Broadcom намерена помогать предприятиям справляться с этими конкурирующими факторами, поддерживая как модели с открытыми весами, так и строго коммерческие решения. VMware AI Factory даёт предприятиям готовый к промышленной эксплуатации путь к запуску ведущих AI-моделей локально. Использование vLLM в качестве среды исполнения моделей по умолчанию позволяет заказчикам запускать на VCF более 150 моделей с открытым исходным кодом с оптимизацией по производительности. Broadcom объявила, что на работоспособность в VCF протестированы следующие модели:

Nemotron 3: семейство открытых мультимодальных моделей NVIDIA Nemotron 3 обеспечивает ведущую точность и эффективность, помогая агентам быстрее выполнять задачи. Сочетание гибридной архитектуры Mamba-Transformer MoE, контекстного окна в один миллион токенов и обучения с подкреплением в нескольких средах позволяет Nemotron 3 поддерживать масштабируемые длительные агентные рабочие процессы в корпоративных приложениях.
Gemma 4: новейшее семейство мультимодальных моделей Google DeepMind с открытым исходным кодом и открытыми весами, созданное специально для разработчиков и исследовательского сообщества, обеспечивающее локальное исполнение и позволяющее предприятиям создавать и разворачивать автономных AI-агентов.
cotomi: проприетарная AI-модель компании NEC, оптимизированная для японского языка и обученная на тщательно отобранных, высоконадёжных наборах данных. Она сочетает высокую скорость обработки с повышением эффективности использования токенов на 40%.
Qwen3.8-27B: разработанная Alibaba модель Qwen3.8-27B — плотная визуально-языковая модель с открытыми весами от команды Qwen. Она подходит для написания кода, профессиональных рабочих процессов, исследований, мультимодального взаимодействия и длительных агентных задач, а режим «размышления» в ней можно включать и отключать. Это нативно мультимодальная плотная модель на 27 млрд параметров, рассчитанная на эффективное локальное развёртывание и коммерческое использование.
GLM 5.2: General Language Model с открытым исходным кодом от Z.ai (ранее Zhipu AI) позволяет предприятиям локально разворачивать агентов для написания кода и рассуждений в многошаговых автономных сценариях с соблюдением суверенитета данных и оптимальной производительностью оборудования.

VCF получила сертификацию NVIDIA: производительность AI-нагрузок подтверждена на уровне, близком к «голому железу»

Недавно NVIDIA запустила программу NVIDIA-Certified Hypervisors. Она удостоверяет, что участвующие в ней гипервизоры обеспечивают для AI- и HPC-нагрузок производительность, близкую к «голому железу».

VMware vSphere 9.1 (и все будущие релизы vSphere 9) получили сертификат NVIDIA-Certified Hypervisor. Таким образом, ИИ- и HPC-нагрузки на VCF теперь официально сертифицированы на работу с производительностью, близкой к «голому железу». Эта сертификация позволяет заказчикам уверенно использовать VCF в качестве оптимизированной по производительности платформы частного облака с поддержкой со стороны основных партнёров экосистемы — для обеспечения работы AI-приложений и приложений ускоренных вычислений в корпоративных центрах обработки данных. Более подробно об этом рассказано в недавно опубликованной статье.

Новые партнёры экосистемы VCF Private AI Services

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

Appian: Appian предоставляет AI-автоматизацию для критически важных задач, автоматизируя сложные процессы в крупных предприятиях и государственных структурах. Платформа Appian известна своей надёжностью и масштабируемостью, подкреплёнными более чем 25-летним опытом в области корпоративных операций. Документация по установке Appian на VCF доступна на этой странице.
ClearML: ClearML предоставляет уровень оркестрации AI, управляющий доступом к GPU, моделями и агентами в рамках VMware Cloud Foundation. Это повышает утилизацию графических процессоров и снижает стоимость выполнения AI-нагрузок, давая предприятиям встроенный путь к модели AI-as-a-Service. Подробнее о ClearML можно узнать здесь.
Eve Security: Eve обеспечивает управление, наблюдаемость и контроль времени исполнения, необходимые предприятиям для безопасного масштабирования AI-агентов. Её агент, встроенный в контур, автоматически проверяет высокорисковую или аномальную активность, обогащает решения контекстом из систем управления идентификацией, DLP и нижележащих систем, а при необходимости применяет средства контроля в реальном времени. Подробнее об Eve Security — здесь.
Solo.io: Solo.io создаёт агентную инфраструктуру с открытым исходным кодом для предприятий, эксплуатирующих AI в продуктивной среде. Среда исполнения kagent и плоскость данных agentgateway дают платформенным командам возможность разворачивать AI-агентов и контролировать каждый вызов модели, инструмента и обращение агента к агенту — на инфраструктуре, которой они владеют и управляют. Дополнительные сведения о сотрудничестве Solo.io и Broadcom приведены в этой статье.
TrueFoundry: TrueFoundry предоставляет AI Gateway корпоративного уровня, объединяющий LLM Gateway, MCP Gateway и Agent Gateway, что позволяет предприятиям подключать, наблюдать и контролировать агентные AI-приложения разных провайдеров из единой плоскости управления. Дополнительные подробности о TrueFoundry доступны здесь.

10 ключевых нововведений в VMware Cloud Foundation 9.1.1

Fri, 11 Sep 2026 08:14:24 UTC

Недавно в Лас-Вегасе прошла конференция VMware Explore 2026 — со встречами с заказчиками и партнёрами, техническими сессиями и воркшопами. К мероприятию приурочен анонс общей доступности VMware Cloud Foundation (VCF) 9.1.1 — первого maintenance-релиза для ветки VCF 9.1.

Примечание: хотя для maintenance-релизов и экспресс-патчей (EP) жёсткая последовательность установки не задана, для релиза VCF 9.1.1 предусмотрено особое исключение — несколько компонентов необходимо обновлять в строго определённом порядке (соответствующие предварительные проверки уже встроены в релиз). В одном из будущих maintenance-релизов эти исключения будут сняты, но пока о них следует помнить.

Fleet LCM необходимо обновить до 9.1.1 прежде, чем обновлять до 9.1.1 остальные компоненты VCF.
VCFMS необходимо обновить до 9.1.1 прежде, чем обновлять до этой же версии Identity Broker и компонент Salt Master/RaaS.
VCF Automation (VCFA) необходимо обновить до 9.1.1 прежде, чем обновлять компонент VCD Migrator.

Как maintenance-релиз он включает все накопленные исправления ошибок и обновления безопасности из ранее вышедших экспресс-патчей (EP), а также улучшения стабильности платформы и доработки, упрощающие переход на VCF 9.1.

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

1. Поддержка обновления с back-in-time релизов

После выхода VCF 9.1 было опубликовано несколько релизов vSphere и VMware Cloud Foundation (VCF), которые считались back-in-time релизами: прямого пути обновления до VCF 9.1 у них не было. С выходом VCF 9.1.1 для всех этих релизов появился поддерживаемый сценарий обновления.

Исходная версия	9.1.0	9.1.1
VCF 9.0.2 EP02 (9.1.0.0200)	Нет	Да
VCF 5.2.4	Нет	Да
vSphere 8.0 U3J-U3K	Нет	Да

2. Поддержка актуальных версий компонентов VCF в VCF Download Tool (VCFDT)

Экспресс-патчи (EP) для компонентов VCF выходят всё чаще, и определить актуальные версии всех компонентов, необходимых для новой установки или обновления VCF, становится всё сложнее. VCF Download Tool (VCFDT) позволяет без труда узнать последнюю версию отдельного компонента, но с определением актуальных версий по всему программному стеку VCF всё обстояло не так просто.

В VCFDT 9.1.1 задачу упрощает новый флаг --latest: он автоматически отбирает необходимые компоненты VCF в их последних версиях с экспресс-патчами — как для сценария установки, так и для сценария обновления.

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

vcf-download-tool binaries list --depot-download-token-file=/Users/lamw/vcf_download_token.txt --vcf-version=9.1.0 --sku=VCF --type=INSTALL --automated-install --latest

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

vcf-download-tool binaries download --depot-download-token-file=/Users/lamw/vcf_download_token.txt --depot-store=/Volumes/Storage/Software/VCF-LATEST --vcf-version=9.1.0 --sku=VCF --type=INSTALL --automated-install --latest

3. Поддержка OCI-артефактов, а также образов vSphere Supervisor, VKS и VKR в VCF Download Tool

Унифицированный VCF Software Depot представляет собой единый репозиторий, в котором хранятся все бинарные файлы, используемые развёртыванием VCF, — OVA, ZIP-архивы, PAK-файлы и артефакты в формате OCI. VCFDT остаётся основным инструментом взаимодействия с онлайновым VCF Software Depot: с его помощью загружают содержимое и создают офлайновый VCF Software Depot. Однако одно ограничение сохранялось — инструмент не умел работать с артефактами в формате OCI, включая vSphere Kubernetes Releases (VKR).

В VCF 9.1.1 в VCFDT появилась новая команда artifacts, которая упрощает загрузку сервисов vSphere Supervisor, включая vSphere Kubernetes Service (VKS), и, что особенно важно, релизов vSphere Kubernetes Releases (VKR). Новая команда позволяет выбрать, какие именно VKR нужно загрузить. Раньше подписка на онлайновую библиотеку контента VKR делала доступными для развёртывания сразу все релизы VKR, и у операторов платформы не было простого способа контролировать, какие из них используются.

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

SUPERVISOR — обновления управляющего уровня vSphere Supervisor
VKS — обновления vSphere Kubernetes Service
SUPERVISOR_SERVICE — обновления сервисов vSphere Supervisor
VCF_CLI — VCF Consumption CLI и плагины к нему
VCF_SERVICE — сервисы VCF, предоставляемые VCF Automation
DSM — обновления Data Service Manager

Команда для вывода списка релизов VKR:

vcf-download-tool artifacts list --depot-download-activation-code-file=/Users/lamw/vcf_activation_code.txt --sku=VCF --vcf-version=9.1.0 --component=VKR

Команда для загрузки конкретного релиза VKR:

vcf-download-tool artifacts download --depot-download-activation-code-file=/Users/lamw/vcf_activation_code.txt --sku=VCF --vcf-version=9.1.0 --component=VKR --depot-store=/Volumes/Storage/Software/VKR --component-version=1.36.1+vmware.4-vkr.5

4. Уменьшенный ресурсный след VCF Management Services (VCFMS)

Когда в VCF 9.1.0 появился компонент VCF Management Services (VCFMS), размеры его виртуальных машин подбирались с расчётом на самый крупный из опциональных сервисов Day-N. Это снижало вероятность того, что при включении дополнительных сервисов потребуется переход на более крупную конфигурацию ВМ. Но в средах, где такие опциональные сервисы Day-N не разворачивались, часть виртуальных машин VCFMS оказывалась больше, чем необходимо.

В VCF 9.1.1 размеры VCFMS оптимизированы под первоначальное развёртывание Day-0. Кроме того, отдельные компоненты VCFMS были дополнительно перенастроены так, чтобы каждый сервис резервировал только те ресурсы, которые ему действительно требуются, — это повышает общую эффективность использования ресурсов. Например, при развёртывании Simple (без высокой доступности) теперь будет на один рабочий узел VCFMS меньше (12 vCPU / 24 ГБ памяти).

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

5. Поддержка развёртывания Small HA для VCF Management Services (VCFMS) в VCF Installer

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

В VCF 9.1.1 для VCF Management Services (VCFMS) появился новый вариант развёртывания Small HA: высокой доступности можно добиться, не выходя за пределы ресурсов самой компактной конфигурации.

Если эта возможность используется через JSON API VCF Installer, в качестве значения размера развёртывания в секции vspClusterSpec, описывающей конфигурацию VCF Management Services (VCFMS), указывается small_ha.

Если VCF Fleet развёрнут в варианте Small без высокой доступности, масштабировать его до Small HA можно как операцию Day-N — через интерфейс VCF Operations в разделе Build > Lifecycle > VCF Management > Components > VCF Services Runtime, выбрав Action > Scale.

6. Поддержка HTTP и произвольного URL для офлайнового депо в интерфейсе VCF Installer

Возможность настроить офлайновый депозиторий VCF через HTTP-эндпоинт, включая поддержку произвольного пути в URL, появилась в API VCF Installer ещё в VMware Cloud Foundation (VCF) 9.1.0. Начиная с VCF 9.1.1 то же самое доступно непосредственно в интерфейсе VCF Installer: средам, которым не нужен HTTPS и/или которые используют собственный URL офлайнового депо, больше не требуется обращаться к API VCF Installer.

7. Поддержка дисков вне HCL vSAN ESA в интерфейсе VCF Installer

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

Важно: в продуктивных средах VVF и VCF с vSAN ESA поддерживаются только NVMe-устройства, перечисленные в Broadcom Compatibility Guide (BCG).

Для использования этой возможности через JSON API VCF Installer в секцию vsanSpec добавлено новое свойство skipHclAutoDiskClaim. Установка его в true включает то же поведение, что и в интерфейсе VCF Installer.

"datastoreSpec": {
    "vsanSpec": {
        "vsanDedup": false,
        "failuresToTolerate": 1,
        "esaConfig": {
            "enabled": true,
            "skipHclAutoDiskClaim": true
        },
        "datastoreName": "vsanDatastore",
        "encryptionConfig": {
            "dataInTransitConfig": {
                "enable": false
            }
        }
    }
}

8. Поддержка развёртывания на одном хосте ESX в интерфейсе VCF Installer

В лабораторных и пилотных средах с ограниченными аппаратными ресурсами выполнить минимальные требования к количеству хостов ESX удаётся не всегда. Хотя обходной путь через переопределение настройки доступен ещё с VCF 5.x, интерфейс VCF Installer всё равно требовал соблюдения минимального числа хостов и блокировал развёртывание даже при заданном переопределении. В результате развёртывание приходилось выполнять через Cloud Builder или JSON API VCF Installer.

Начиная с VCF 9.1.1 интерфейс VCF Installer учитывает такое переопределение, и подобные развёртывания можно выполнять прямо из UI. Для тех, кто только начинает знакомиться с VCF в лабораторных и пилотных средах, это заметно упрощает работу.

Важно: в продуктивных развёртываниях VVF и VCF поддерживается только официальная минимальная конфигурация хостов ESX.

9. Поддержка дисков вне HCL vSAN ESA в процедуре ввода хостов в эксплуатацию

При добавлении нового домена рабочей нагрузки VCF или расширении существующего, если в нём используется vSAN ESA, для ввода в эксплуатацию хостов ESX с несертифицированными NVMe-устройствами раньше требовалось дополнительное переопределение настроек. Продолжая линию на упрощение работы, заданную в VCF 9.1.1, ввод хостов ESX в эксплуатацию теперь выполняется прямо из интерфейса vCenter Server или SDDC Manager без этого дополнительного переопределения.

Прежде чем добавлять введённый в эксплуатацию хост ESX с несертифицированными NVMe-устройствами в кластер vSAN ESA, необходимо убедиться, что функция vSAN Managed Disk Claim отключена. По умолчанию она автоматически захватывает сертифицированные NVMe-устройства для использования с vSAN ESA. Несертифицированные устройства требуют ручной обработки, поэтому в противном случае операция будет заблокирована.

10. Поддержка VPC на базе VLAN без Overlay Tunnel Endpoint (TEP)

С появлением Distributed Transit Gateway (DTGW) для начала работы с Virtual Private Cloud (VPC) достаточно распределённой группы портов (DVPG) на базе VLAN, однако дополнительно всё равно приходилось настраивать overlay-сеть для Tunnel Endpoint (TEP) между хостами ESX. В VCF 9.1.1 у DTGW появился ещё один вариант — на базе VLAN и без необходимости настраивать сеть TEP на каждом хосте ESX, что сокращает объём конфигурации, требуемой для начала работы с VPC.

Примечание: новый вариант развёртывания VPC на базе VLAN полностью совместим с vSphere Kubernetes Service (VKS) и VCF Automation (VCFA), но имеет ряд ограничений. В их числе — отсутствие приватных подсетей VPC, сервисов SNAT/DNAT/VPN и поддержки протоколов, отличных от IP (например, VRRP и Multicast).

Источник.

Новые возможности AI и Kubernetes в VMware Cloud Foundation 9.1.1

Wed, 09 Sep 2026 16:25:17 UTC

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

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

AI Assistant for VCF

Рисунок 1. Функция AI Assistant for VCF упрощает операции Day-2 за счёт диалогового поиска неисправностей и диагностики.

В VCF 9.1.1 появилась функция, которая даёт возможность встроить диалоговый AI-интерфейс непосредственно в пользовательский интерфейс VCF Operations, настроив его локально с выбранной моделью. Эта функция изначально поддерживает различные большие языковые модели (LLM), работающие на Private AI Services (PAIS), либо частный экземпляр Google Gemini. Требуется ли администратору помощь в поиске причин проблем инфраструктуры или в управлении сторонними интеграциями — функция AI Assistant for VCF способна содержательно и безопасно помогать в эксплуатации частного облака.

Диалоговая диагностика. Функция AI Assistant for VCF даёт администраторам любого уровня подготовки возможность управлять средами частного облака с помощью простых запросов на английском языке.

Интеллектуальная видимость состояния. Функция AI Assistant for VCF также может помочь администратору в устранении проблем с работоспособностью VCF. Новые возможности обеспечивают диагностическую видимость для VMware vSphere и служб управления VCF. Администраторы могут сопоставлять проактивные оповещения о состоянии, конфигурацию и журналы.

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

Больше подробностей содержится в записи следующей сессии VMware Explore 2026:

From Tokens to Traces: AI Observability in VMware Cloud Foundation Operations [CLOB1168LV]

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

Рисунок 2. VCF Operations обеспечивает наблюдаемость VKS и поиск неисправностей в реальном времени.

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

Наблюдаемость VMware vSphere Kubernetes Service (VKS). Администраторы могут сопоставлять метрики вычислительных ресурсов, сети и хранилища, получаемые в реальном времени, с системными журналами и событиями, чтобы быстро изолировать первопричины. Стандартные пятиминутные интервалы опроса теперь можно сократить до секунд. В VCF Operations появилась потоковая передача метрик в реальном времени с интервалом 2 секунды для кластеров VKS. Используя стандарт OpenTelemetry, команды могут оперативно обнаруживать короткоживущие поды, всплески потребления памяти и кратковременные узкие места производительности.

Мониторинг нескольких кластеров VKS. Администраторы получают централизованную видимость всех кластеров Kubernetes благодаря автоматизированному сбору данных OpenTelemetry без написания кода.

Импорт дашбордов Grafana. Администраторы могут беспрепятственно импортировать существующие дашборды Grafana или дашборды из библиотеки сообщества Grafana, чтобы отслеживать рабочие нагрузки Kubernetes из VCF Operations и одновременно просматривать нативные дашборды VKS.

Больше подробностей содержится в записи следующей сессии VMware Explore 2026.

Kubernetes Observability for Platform Operators: VMware vSphere Kubernetes Service and Application Services [CLOB1167LV]

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

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

Динамическое управление идентификацией по запросу. При настройке единого входа (SSO) для доступа к различным компонентам VCF необходимость в предварительно созданных учётных записях пользователей осталась в прошлом. VCF 9.1.1 поддерживает запросы к Active Directory и OpenLDAP (Lightweight Directory Access Protocol) в реальном времени. Членство пользователя в группах вычисляется динамически ровно в момент входа в систему, что упрощает выдачу временного группового доступа и обеспечивает соответствие прав текущему состоянию каталога.
Упрощённое управление паролями. VCF Operations выступает единой точкой для управления парольными политиками и их применения в рамках всего парка систем. Применять парольные политики стало проще, поскольку в рабочем процессе доступно больше компонентов. Администраторы могут отслеживать актуальность учётных данных по компонентам, включая теперь и учётные записи приложений для VMware vCenter, VMware Cloud Foundation Automation, средств управления парком VMware Cloud Foundation Operations и коллекторов VMware Cloud Foundation Operations for Networks.
Расширенное управление сертификатами. Управление жизненным циклом сертификатов теперь охватывает NSX Edges, супервизоры VMware vSphere, серверы лицензирования, cloud proxy для VCF Operations и коллекторы VCF Operations for Networks. Система обеспечивает непрерывное отслеживание сроков истечения, автоматические оповещения о сбоях автоматического обновления и интеграцию со сторонними удостоверяющими центрами (CA). Также реализована поддержка сертификатов, не относящихся к TLS. Эта возможность даёт расширенную видимость компонентов VCF и помогает свести к минимуму перебои во взаимодействии настроенных компонентов при истечении срока действия сторонних сертификатов. С помощью VCF Operations администраторы могут заменять самоподписанные сертификаты на сертификаты, выпущенные удостоверяющим центром.
VMware Salt for VCF Component APIs. Новые для VCF интерфейсы VMware Salt for VCF Component APIs построены на базе VMware Salt и дают командам всесторонний программный контроль над управлением конфигурациями. Опираясь на нативные конструкции Salt, эта новая возможность задействует целый ряд встроенных параметров конфигурации, которые единообразно работают во всём VCF. Более 300 доступных настроек позволяют администраторам поддерживать согласованное операционное состояние всего стека.

Больше подробностей содержится в записи следующей сессии VMware Explore 2026:

What’s New in VMware Cloud Foundation Operations [CLOT1139LV]

Гибкость развёртывания и масштабирование

Компактный форм-фактор. Для организаций, которым нужно развернуть частное облако меньшего размера, в VCF 9.1.1 предложен новый компактный форм-фактор, сокращающий требования к процессорным ресурсам и памяти до 40%. Он включает конфигурацию из двух узлов для обеспечения высокой доступности. Кроме того, такая упрощённая архитектура позволяет импортировать в VCF существующие экземпляры VMware vCenter из brownfield-сред без перенастройки сетевых портгрупп.

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

Больше подробностей содержится в записи следующей сессии VMware Explore 2026:

Lifecycle Management in VMware Cloud Foundation 9.1 for VMware vSphere Admins [CLOB1568LV]

Итог

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

«Базис» приобрёл 70% разработчика российского аналога Dynatrace

Mon, 07 Sep 2026 08:41:41 UTC

Разработчик отечественной observability-платформы Proto перешёл под контроль «Базиса». Proto Observability Platform в России рассматривают как импортонезависимую замену американской Dynatrace.

Условия сделки

«Базис», поставляющий решения для динамической инфраструктуры, виртуальных рабочих мест и облачных сервисов, забрал себе Proto — команду, которая делает платформу наблюдаемости и аналитики операционных данных на базе искусственного интеллекта. Покупателю досталась доля в 70%. Оформлено приобретение через внесение денег в капитал Proto, и эти средства пойдут на доработку AI-платформы и её встраивание в экосистему «Базиса». Сумму и прочие параметры стороны раскрывать не стали.

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

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

Сама Proto видит в новом владельце сильного союзника — с солидным запасом ресурсов и широкой клиентской базой.

Партнерство с таким игроком позволяет нам быстрее реализовать наше видение развития Proto и масштабировать продукт вместе с одной из ведущих российских ИТ-компаний, — отметил генеральный директор и сооснователь Proto Денис Безкоровайный.

Что умеет Proto Observability Platform

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

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

Расчёт покупателя

Интерес «Базиса» сосредоточен именно на технологиях Proto: их предстоит встроить в собственную программную экосистему. Такой путь избавляет компанию от расходов на создание аналогичной по возможностям разработки с чистого листа.

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

Технологии Proto планируется перенести во флагманские продукты вендора, и прежде всего в Basis Dynamix — платформу виртуализации серверов и контейнеров. За счёт этого заказчики получат предиктивную аналитику состояния ИТ-инфраструктуры и прогнозирование инцидентов средствами искусственного интеллекта. Тем, кто инфраструктурными продуктами «Базиса» не пользуется, оставят возможность настраивать платформу самостоятельно.

Профиль Proto

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

На домашнем рынке компании противостоят «Ключ-Астром», Monq, Volgablob, Gmonit и Sage. Если смотреть шире, зарубежными аналогами продукта выступают Dynatrace, Instana Observability, Datadog и New Relic.

Юридическое лицо — ООО «ПротоСервисез» — зарегистрировано в Москве в мае 2014 г. Уставный капитал составляет 25 тыс. руб. и поделён поровну между Надеждой Борисовной Фердман и Денисом Игоревичем Безкоровайным; последний занимает пост генерального директора. За 2025 г. выручка ООО «ПротоСервисез» составила 9,5 млн руб. при чистой прибыли 4,5 млн руб. Годом ранее показатели были заметно выше: 23 млн руб. доходов и 14,8 млн руб. прибыли.

Рекордным для компании остаётся 2021 г. — тогда выручка достигла 166,7 млн руб., а чистая прибыль — 17,5 млн руб. Уже в 2022 г. доходы просели примерно в десять раз, до 15,2 млн руб., прибыль опустилась до 4,1 млн руб., а 2023 г. и вовсе завершился убытком в 7,1 млн руб.

Одноимённую платформу Proto Observability Platform компания представила рынку в 2022 г. Продукт предназначен для сквозного контроля бизнес-систем, приложений, пользовательского опыта и ИТ-инфраструктуры. В Единый реестр отечественного ПО Минцифры России его внесли в начале августа 2022 г.

Чем известен «Базис»

Выручка «Базиса» по итогам 2025 г. прибавила 37% и достигла 6,3 млрд руб. Показатель OIBDA составил 3,84 млрд руб., чистая прибыль в годовом сопоставлении выросла на 8,6%, до 2,22 млрд руб. В декабре 2025 г. компания вышла на биржу с IPO.

Платформа Basis Dynamix Enterprise возглавила рейтинг российских платформ виртуализации CNewsMarket 2026. Для флагманского продукта вендора это третья победа кряду: он набрал 695 баллов и оторвался от ближайшего преследователя на 25 баллов. Двумя годами ранее, в 2024 г., «Базис» забрал себе «Рустэк» — на тот момент одного из лидеров отечественного рынка средств виртуализации. Разработка «Рустэка» ещё в 2023 г. занимала первую строчку среди российских платформ по версии CNews.

В мае 2026 г. материнская структура «Базиса» — «РТК-ЦОД», компания «СкайФолл Лабс» (SkyFLabs) и Proto подписали соглашение о технологическом партнёрстве. Партнёры договорились строить общую платформу управления ИТ-инфраструктурой и сервисами, которая сведёт воедино инструменты ITSM/ESM, ITAM, мониторинга, наблюдаемости, автоматизации и сервисного взаимодействия.

Объявлена доступность VMware Cloud Foundation 9.1.1

Sat, 05 Sep 2026 11:00:32 UTC

Вслед за успешно прошедшей конференцией VMware Explore в Лас-Вегасе и майским запуском VMware Cloud Foundation (VCF) 9.1 объявлено о переходе в стадию общей доступности версии VCF 9.1.1. Этот релиз развивает возможности VCF 9.1 и приносит усиленную защиту, объектное хранилище vSAN Object Storage (в статусе технического превью, о чём сообщалось ранее), а также новые функции, призванные сделать частное облако лучшей площадкой для запуска AI-нагрузок, управления ими и их защиты — при одновременном снижении совокупной стоимости владения (TCO) и операционной сложности.

Рассмотрим, что нового появилось в этой версии.

Multi-Tenant Model Sharing: безопасное совместное использование AI-моделей

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

Механизм Multi-Tenant Model Sharing решает эту задачу, позволяя безопасно делиться моделями между тенантами или отдельными направлениями бизнеса с сохранением конфиденциальности данных. Команды получают доступ к общим моделям без раскрытия чувствительных обучающих данных и без необходимости создавать изолированные инфраструктурные «острова».

Рисунок 1: Multi-Tenant Model Sharing в VMware Cloud Foundation

К операционным преимуществам такого подхода относятся:

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

Именно так выглядит платформа, изначально спроектированная под AI, а не дополненная соответствующими функциями постфактум.

AI Assistant for VCF: диагностика и конструктор management packs

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

Помощник AI Assistant for VCF берёт на себя диагностику и построение пакетов управления (management packs). Диагностика на базе AI сокращает среднее время устранения неисправностей (MTTR), помогая командам быстрее выявлять первопричины. С помощью AI пользователи могут разбирать инциденты — например, конкуренцию за ресурсы процессора и память на ESX или иные диагностические аномалии — не обладая узкоспециализированными навыками. Другой пример работы помощника при устранении неполадок — совместный анализ множества ошибок vMotion, позволяющий точно определить, почему миграция vMotion даёт сбой в рамках всей среды vCenter.

AI Assistant for VCF также помогает заказчикам создавать интеграции со сторонними продуктами: конструктор контента задействует API для формирования management packs и content packs, которые в противном случае пришлось бы готовить вручную.

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

Новый сервис GitOps [техническое превью]: Argo CD внутри VCF

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

Новый GitOps Service (выпущен в статусе технического превью) добавляет Argo CD в качестве нативного GitOps-сервиса в рамках сервисной управляющей среды VCF. Это объединяет развёртывание и управление жизненным циклом непосредственно в интерфейсе VCF Automation, перенося процессы GitOps в ту же операционную плоскость, где находится остальная инфраструктура. Сокращая разрастание инструментария, команды повышают операционную эффективность и отдачу от вложений. Кроме того, сервис GitOps защищает доступ к конвейерам с помощью аутентификации OIDC, интегрированной с VCF Automation.

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

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

Архитектурные улучшения EVPN: проще и масштабируемее

В VCF 9.1.1 появились важные архитектурные улучшения EVPN, включая оптимизированный путь передачи данных между транзитными шлюзами VCF и физической фабрикой для трафика «восток - запад». Прямые туннели VXLAN между транзитным шлюзом и коммутаторами уровня leaf оптимизируют производительность датаплейна для трафика «восток - запад». Помимо этого, сетевые сервисы — NAT, балансировка нагрузки NSX, балансировка нагрузки AVI и DHCP relay — теперь доступны в режиме распределённой связности EVPN VXLAN. В совокупности эти улучшения обеспечивают критически важную мультитенантную и внешнюю связность, а также дают более высокую производительность, более простую конфигурацию и упрощённую диагностику сред EVPN.

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

Add-on Management Framework в VMware vSphere Kubernetes Service 3.7: уверенность при масштабировании

По мере роста сред Kubernetes разрастается и экосистема дополнительных инструментов — сетевых, средств наблюдаемости, безопасности, хранения данных. Основные трудности проявляются на этапе Day 2: управление жизненным циклом дополнений и устранение возникающих проблем. Ситуацию усугубляет неясность в зонах ответственности за поддержку - непонятно, к кому обращаться, когда что-то ломается. Механизм Add-on Management Framework в vSphere Kubernetes Service (VKS) 3.7 обеспечивает предсказуемую поддержку с прозрачным распределением ответственности и даёт заказчикам свободу выбора при внедрении экосистемных инструментов. Чёткие маршруты поддержки на каждом уровне сокращают время до решения проблемы, давая командам уверенность при масштабировании и скорость для внедрения инноваций.

Следующий шаг

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

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

Представлена программа VMware/Broadcom Frontier AI Security Readiness

Tue, 01 Sep 2026 12:24:09 UTC

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

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

Сегодня по всему миру запускается программа Frontier AI Security Readiness Program, которая предлагает заказчикам направляемую, предписывающую и адаптированную траекторию движения к более устойчивому частному облаку. Эффективная защита от угроз, управляемых AI, требует сквозного, целостного подхода к безопасности, а не разрозненных фрагментарных решений.

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

Assess (оценка): количественно измерить экспозицию и пробелы в защитной позиции, чтобы получить базовую линию, основанную на данных.
Architect (проектирование): определить целевое состояние, объединив результаты анализа пробелов с проверенными блупринтами по пяти разрезам.
Implement (внедрение): развернуть усиленные конфигурации, опираясь на бесшовное обновление, непрерывный мониторинг и сортировку инцидентов с помощью AI.
Upskill (повышение квалификации): развить компетенции организации за счёт специализированных учебных курсов по VMware Cloud Foundation (VCF) 9.1 и будущей сертификации AI Resilient Infrastructure Expert (ARIE).

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

Подать заявку на участие в программе Frontier AI Security Readiness можно по ссылке, также рекомендуется обратиться к своей команде по работе с клиентами: https://go-vmware.broadcom.com/frontier-ai-security-readiness-program

Ниже разобран каждый из четырёх этапов программы.

Этап Assess

Чтобы построить устойчивое частное облако, первым фундаментальным шагом программы безопасности становится оценка, поскольку нельзя защищать то, что не измерено. Веб-инструмент VCF Security Assessment даёт объективную, основанную на баллах видимость защитной позиции по всему стеку, применяя риск-ориентированную систему оценок, чтобы приоритизировать значимые продуктивные среды и DMZ над менее критичными лабораторными нагрузками.

Защита частных облаков VMware Cloud Foundation (VCF) от управляемых ИИ угроз, действующих на машинной скорости, требует отказа от статических периметров в пользу автоматизированной модели secure-by-design. Лепестковая диаграмма и анализ пробелов, которые формирует опросник оценки безопасности, помогают совершить этот переход: они вскрывают критические уязвимости и дают немедленную визуальную ясность по пяти архитектурным опорам — People and Process, User Security, Platform Security, Lateral Security и Application Security & Recovery. Вооружившись этими данными, организации могут выстроить устойчивую базовую линию платформы, которая минимизирует поверхность атаки, обеспечивает строгий контроль идентичностей, ограничивает горизонтальное перемещение и позволяет быстро восстанавливаться. Тем самым реактивное управление обновлениями превращается в целенаправленную непрерывную защиту, способную выдерживать атаки эпохи Frontier AI.

Этап Architect

После того как базовая линия безопасности установлена, этап Architect переводит сырые результаты оценки в конкретный устойчивый целевой дизайн. Сочетание баллов оценки безопасности и тепловых карт пробелов с VCF Security Blueprints по тем же пяти ключевым разрезам — People & Process, Platform, User, Lateral и Application Security & Recovery — даёт чёткие предписывающие рекомендации. Это обеспечивает точный набор строительных блоков для реализации: от внедрения строгого RBAC и SSO до перехода на VCF 9.1+ ради автоматизированного обновления в рамках жизненного цикла и встраивания базовых сетевых механизмов, шифрования и средств аварийного восстановления.

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

Этап Implement

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

Развёртывание компонентов по проверенным, усиленным блупринтам
Выполнение бесшовного автоматизированного обновления для поддержания соответствия требованиям
Использование сканеров безопасности для бюллетеней VMware Security Advisories, чтобы быстро приоритизировать уязвимости

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

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

На всех трёх этапах заказчики работают рука об руку со своими системными инженерами (SE) и техническими менеджерами (TAM), либо с партнёрами. Стоит отметить, что VCF Professional Services предлагает набор сервисов, соответствующих этапам программы (Assess, Architect, Implement), а экспертное сопровождение способно заметно ускорить сроки проектов. Подробности о VCF Professional Services можно узнать у своей команды по работе с клиентами.

Этап Upskill

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

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

Ознакомиться с актуальными обучающими материалами по VCF 9.1 можно по следующим направлениям.

Цифровое обучение по запросу (On-Demand Digital Learning):

Очное обучение с инструктором (ILT):

Сертификационный трек AI Resilient Infrastructure Expert (ARIE), скоро

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

Специалисты по продажам (4 часа): фокус на свободном владении темой устойчивости к AI, позиционировании VCF как стека безопасности и эффективных стратегиях общения с CISO.
Системные инженеры (около 10 часов): технические погружения во внутреннее устройство DFW, VM-identity, Avi WAF, Live Recovery и VulnOps для защиты на машинной скорости.
Кандидаты VCDX (40 часов): продвинутые лабораторные работы, ведущие к сертификациям VCAP/VCDX, с упором на применение Zero Trust и автономное реагирование на угрозы.

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

Проектировать архитектуры Zero Trust в соответствии с методиками NIST, CIS и MITRE.
Обеспечивать защиту рабочих нагрузок средствами микросегментации vDefend, IDS/IPS и Avi WAF.
Использовать Salt для автоматизации непрерывного контроля соответствия и устранения дрейфа конфигураций.
Обеспечивать устойчивость к программам-вымогателям и выполнять быстрое ускоренное восстановление.

С обучением AI Resilient Infrastructure Expert команды не просто узнают о защите современного частного облака. Они получают сертификацию на защиту платформы VCF. Стоит учитывать, что сертификации сгруппированы по нескольким технологическим направлениям и имеют уровни как для новичков в отрасли, так и для экспертов. Подробнее об этом рассказывает страница VMware Certification.

Дальнейшие шаги

Для участия в программе Frontier AI Security Readiness нужно заполнить форму заявки: https://go-vmware.broadcom.com/frontier-ai-security-readiness-program

Во-вторых, стоит связаться со своей командой по работе с клиентами или партнёром, чтобы разобраться в предложениях VCF Professional Services, которые помогают ускорить высокоприоритетные ИТ-проекты. Наконец, стоит воспользоваться правами на обучение VCF Learning, чтобы повысить или сменить квалификацию с помощью продвинутых курсов и новых сертификаций VCAP и VCDX, а также следить за анонсом будущего трека обучения и сертификации AI Resilient Infrastructure Expert (ARIE).

Как выбрать путь миграции Kubernetes на VMware VKS

Thu, 27 Aug 2026 10:00:26 UTC

Одна мысль звучит от заказчиков VMware постоянно: перенос нагрузок Kubernetes на VMware vSphere Kubernetes Service (VKS) — самый важный шаг на пути внедрения VMware Cloud Foundation (VCF). Долгое время он же оставался и самым трудным для объяснения. У большого числа заказчиков миграция раз за разом всплывала как блокер номер один на пути к VCF. Опасения были реальными и повторяющимися: длинные окна переключения, риск потери данных и методы резервного копирования и восстановления, которые попросту не поспевали за масштабом крупных наборов данных. В отдельных случаях заказчикам приходилось полностью отказываться от старой среды и разворачивать новые кластеры VKS с нуля — только чтобы обойти эту сложность.

Именно эту проблему и взялись решить. За несколько последних месяцев команды профессиональных сервисов, решений и инженерная команда проверили три различных пути миграции на широком наборе исходных топологий: от Tanzu и OpenShift на vSphere до Kubernetes на «голом железе» и облачных дистрибутивов вроде EKS, GKE и AKS. Результатом стал повторяемый плейбук из трёх путей, за которым стоят скрипты, ранбуки и технические документы. Этот материал обобщает четыре документа, кодифицирующих плейбук, и даёт практическую систему выбора нужного пути под конкретную ситуацию. Полный список документов доступен по ссылкам ниже.

Технические документы: VMware vSphere Kubernetes Service White Papers
Скрипты миграции и ранбуки: VKS-Migrations на GitHub

Четыре ситуации миграции

Большинство разговоров о миграции сводится к одной из ситуаций, на которые хорошо ложатся технические документы:

Ваша ситуация	Технический документ	Исходная платформа
Kubernetes уже работает на vSphere (с драйвером vSphere CSI)	Migrating vSphere-Based Kubernetes Workloads to VKS Using Zero-Copy FCD Adoption	Tanzu Kubernetes Grid, OpenShift, Rancher, upstream-Kubernetes — всё на vSphere
Инфраструктура уже на VKS, перенос идёт между кластерами VKS	Migrating Workloads Between VKS Clusters Using Cross-vCenter vMotion	Гостевой кластер VKS в другой гостевой кластер VKS (тот же или другой Supervisor)
Kubernetes на vSphere, но для хранения используется сторонний CSI (NFS, Ceph, внешние массивы)	Migrating non-vSphere Kubernetes Sources to VKS Using Filesystem Replication	Любой Kubernetes на vSphere с хранением на стороннем CSI (NFS, Ceph, внешние SAN и NAS)
Kubernetes работает вне vSphere (облачный, «голое железо», стороннее хранение)	Migrating Kubernetes Workloads to VKS Using Velero and S3-Compatible Storage	OpenShift на «голом железе», облачные Kubernetes, любой сторонний CSI

Методология, общая для всех сценариев

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

Discover — инвентаризация всего: объекты Kubernetes API, топология сети, RBAC и секреты (значения никогда не выгружаются), а также перекрёстная сверка с FCD в vSphere, сопоставляющая каждый PVC с PV и с UUID диска FCD.
Analyze — трансляция специфичных для платформы объектов в эквиваленты VKS (Routes в OpenShift становятся Ingress, SCC — Pod Security Admission, проекты Rancher — пространствами имён) и выбор пути для данных.
Blueprint — фиксация плана в файле Solution Definition File (SDF) с тремя письменными шлюзами согласования: спонсор, платформа, комплаенс. Ни одна волна не выполняется, пока не подписаны все три.
Execute — поволновая миграция с прогонами вхолостую, шлюзами валидации и отрепетированным откатом.

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

Варианты переноса постоянных данных

Это самое важное решение в любой миграции на VKS, и сводится оно к одному вопросу: находится ли диск, на котором лежит постоянный том, уже внутри vSphere?

Путь 1: Zero-Copy, адаптация FCD только на уровне метаданных

Применяется, когда источник использует драйвер vSphere CSI, а диск First Class Disk (FCD) присутствует в базе данных vCenter. Данные приложения не копируются вообще. Velero переносит манифесты Kubernetes (PV, PVC и снимки при этом исключаются), а сам FCD отцепляется от источника и заново регистрируется на целевом кластере через CnsRegisterVolume. Всё это время том физически остаётся на том же хранилище данных.

Простой: ограничен синхронизацией API, а не полосой пропускания — менее 2 минут для тома объёмом 100 ГБ.
Риск потери данных: низкий, поскольку копирования нет, но операционный риск вполне реален — опасность в разделении состояния (split-brain). Оба кластера ни в коем случае не должны монтировать FCD одновременно, иначе повреждение данных наступает немедленно. Источник должен быть масштабирован до нуля прежде, чем целевой кластер подключит диск.
Предварительные требования: хранение источника на vSphere CSI; FCD разрешается в vCenter; политика reclaim у PV изменена на Retain до освобождения исходного claim; проверена целостность UUID диска FCD (Storage vMotion между хранилищами может изменить UUID); подключением должен управлять драйвер CSI, а не команда govc disk.attach.

Путь 2: Data-Copy, копирование данных

Применяется, когда хранение реализовано не на vSphere CSI (AWS EBS, Ceph, NFS, облачные блочные хранилища) либо когда FCD в vCenter отсутствует. Данные физически перемещаются через S3-совместимое объектное хранилище с помощью Data Mover для снимков CSI в Velero: встроенный в агент узла движок Kopia выполняет дедупликацию, сжатие, шифрование и выгрузку блоков, а целевая сторона создаёт новый том vSphere CSI и загружает данные в него.

Простой: растёт вместе с объёмом тома и зависит от полосы пропускания — 45–90 минут для тома 100 ГБ. Замеры дали около 24 минут для одного PVC на 450 ГиБ при использовании движка под управлением оператора и около 86 минут для четырёх томов по 450 ГиБ (1,8 ТиБ) параллельно.
Риск потери данных: выше, поскольку данные активно копируются. Но источник при этом не изменяется, поэтому откат обходится дёшево: достаточно удалить целевое пространство имён и заново созданные тома, а источник остаётся главным вплоть до момента переключения.
Предварительные требования: Velero и CSI Data Mover (либо файловое резервное копирование для драйверов без поддержки снимков); общая точка BackupStorageLocation на S3, доступность которой подтверждена с обоих кластеров; сетевая доступность; класс хранения с немедленной привязкой (Immediate) на целевой стороне; MinIO или S3 объёмом не менее 1,2 от самой крупной партии.

Замечание об инструментах: путь с копированием данных использует Velero вместе с Restic или Kopia (либо Data Mover для снимков CSI в составе Velero). Для источников вне vSphere документы описывают также pv-migrate — более прямой инструмент переноса данных «точка-точка» на базе rsync. А для переездов между кластерами VKS в разных vCenter блоки FCD переносит сам vMotion, и этот вариант предпочтительнее и Velero, и pv-migrate, поскольку он уже является частью vSphere.

Какой путь выбрать: руководство по принятию решения

Ниже — практическая рекомендация для каждой ситуации.

Ситуация 1: инфраструктура уже на vSphere (TKG, OpenShift, Rancher, upstream)

Это идеальный случай, и именно на него приходится основной спрос со стороны заказчиков сегодня: более 300 кластеров на vSphere CSI ждут такого переезда. Почти наверняка такая инфраструктура подходит под zero-copy-адаптацию FCD, которая превращает многочасовое окно простоя в считанные минуты. Схема принятия решения из документа выглядит так:

Драйвер хранения — csi.vsphere.vmware.com, и FCD присутствует в vCenter: zero-copy через CnsRegisterVolume.
Любой другой драйвер CSI либо отсутствие FCD в vCenter: копирование данных через Velero с Restic или Kopia.

Обязательно следует сменить политику reclaim у PV на Retain до удаления исходного PVC, проверить UUID диска FCD после любого Storage vMotion и никогда не допускать одновременного монтирования обоими кластерами. Состояние Helm нужно обрабатывать явно. Миграция пространств имён без фильтров исключения сохраняет на целевой стороне секреты релизов Helm (sh.helm.release.v1) и блокирует helm upgrade. Этап 6.5 методологии выполняет сверку или пересборку релиза с ключом --take-ownership.

Рекомендация: по умолчанию выбирать zero-copy. Копирование данных оставить для небольшого набора томов на стороннем хранилище. Рассчитывать стоит на SLA отката менее 10 минут, если что-то пойдёт не так.

Ситуация 2: инфраструктура уже на VKS, перенос между кластерами VKS

Внешне это похоже на первую ситуацию, но нюанс в том, где расположены Supervisor и vCenter.

Тот же vCenter и то же хранилище данных: zero-copy — объекты Supervisor сохраняются, создаётся новый PV в VKS, и всё завершается менее чем за 2 минуты на каждые 100 ГБ.
Разные vCenter: копирование данных, но силами vMotion, а не Velero и не pv-migrate. vMotion переносит блоки FCD нативно, через транспортную оболочку в виде выключенной вспомогательной виртуальной машины, после чего CnsRegisterVolume адаптирует диск на приёмной стороне. Закладывать следует 45–90 минут на каждые 100 ГБ.
Резервное копирование и восстановление томов средствами Velero здесь явно не выбрано как путь: промежуточное хранение в S3 добавляет задержку, которой vMotion избегает.

Два правила для сценария с разными vCenter важнее прочих. Первое: UUID диска FCD сохраняется при миграции, но его всегда необходимо заново обнаруживать после vMotion — нельзя предполагать, что он совпадает с исходным идентификатором, и нельзя передавать исходный UUID в CnsRegisterVolume. Второе: пространству имён на целевом Supervisor нужна политика хранения, назначенная этому FCD и открытая для данного пространства имён, а также трансляция реестра образов и ingress (например, AKO в Contour) через плагины ConfigMap в Velero.

Рекомендация: если оба кластера используют один vCenter и одно хранилище данных, zero-copy тривиален. Если нет — опираться следует на vMotion, а UUID диска FCD рассматривать как величину, которую всегда перепроверяют, а не принимают на веру. Откат ограничен длительностью vMotion, поэтому RTO стоит отрепетировать.

Ситуация 3: инфраструктура на vSphere, но хранение не на vSphere CSI (NFS, Ceph, внешние массивы)

Этот сценарий сбивает с толку чаще всего. Кластер Kubernetes работает на vSphere, поэтому легко предположить, что zero-copy-адаптация FCD доступна. Но постоянные тома обслуживает сторонний драйвер CSI: NFS, Ceph, внешний массив SAN или NAS либо любой другой сторонний плагин хранения. Адаптировать в vCenter нечего, FCD там просто нет, поэтому zero-copy отпадает. Документ формулирует это прямо: реализация хранения на стороне источника не имеет значения для метода переноса, пока исходный PVC является файловым томом, который задание миграции может смонтировать и прочитать.

Рекомендуемый путь — копирование данных через pv-migrate (rsync поверх SSH), тогда как манифесты Kubernetes переносит Velero. Поскольку перенос работает на уровне файловой системы по сети, источнику и приёмнику не нужно иметь общую платформу хранения, общий драйвер CSI и даже общий vCenter. Этот же документ покрывает и полностью не-vSphere источники: методология идентична, потому что абстракция хранения одна и та же.

Простой: растёт вместе с объёмом набора данных, количеством файлов и доступной полосой пропускания — 45–90 минут для тома 100 ГБ.
Риск потери данных: выше, чем при zero-copy, поскольку данные физически копируются, но исходный PVC не удаляется до тех пор, пока волна не принята, — граница отката сохраняется полностью.
Предварительные требования: исходный PVC является файловым томом; pv-migrate (rsync поверх SSH) для данных; Velero для манифестов; Helm для сверки; сетевая достижимость между источником и VKS по TCP 22 до балансировщика нагрузки VKS; класс хранения StorageClass на стороне VKS.
Ключевой принцип: исходный и целевой тома — независимые объекты хранения. Им не требуется общий vCenter, общий домен CNS, общий массив хранения, общий драйвер CSI или общий дистрибутив Kubernetes. Исходный PVC остаётся на месте и обеспечивает возможность отката до тех пор, пока волна миграции не будет принята.

Нюанс по сравнению с первой ситуацией стоит подчеркнуть: работать на vSphere — недостаточно. Решающим фактором является то, лежит ли постоянный том на диске FCD, которым управляет драйвер vSphere CSI. Если нет, то даже когда сам кластер работает на виртуальных машинах vSphere, сценарий относится к территории копирования данных.

Рекомендация: использовать pv-migrate для копирования данных и Velero для манифестов. Заложить окно по полосе пропускания, выполнить инкрементальную синхронизацию перед переключением, чтобы минимизировать финальную дельту, и сохранять исходный PVC до тех пор, пока нагрузка в VKS не пройдёт проверку. Откат чистый: достаточно удалить целевой PVC и создать его заново, источник остаётся нетронутым.

Ситуация 4: инфраструктура вне vSphere (облако, «голое железо», стороннее хранение)

Zero-copy здесь недоступен, потому что в vCenter нет FCD, который можно было бы адаптировать. Копирование данных остаётся единственным путём, а эталонная архитектура на Velero и S3 — проверенный способ его реализовать. Главная мысль этого документа в том, что источники вне vSphere заставляют встретиться с гравитацией данных лицом к лицу, поэтому работа уходит в классификацию и тонкую настройку, а не в изобретательные приёмы с хранилищем.

Каждый объект классифицируется до переключения по одной из трёх проекций: MIGRATE_AS_IS (переносимый, восстанавливается без изменений), REVIEW_REQUIRED (нужен трансформирующий оверлей — Route в Ingress, DeploymentConfig в Deployment, SCC в Pod Security Admission) или BLOCK_MIGRATION (на целевой стороне отсутствует CRD или оператор — сначала установить, либо исключить). Скрипты проверяются по записанным ожидаемым вердиктам, поэтому неверная классификация всплывает как дефект инструментария до переключения, а не как сломанное приложение после.
Предпочтительна установка под управлением оператора: на источнике это OADP в OpenShift. По результатам проверки она оказалась примерно в 4 раза быстрее нативного Velero для одного PVC на 450 ГиБ (24 минуты против примерно 90), потому что плагин CSI, Data Mover и агент узла остаются согласованными по версиям и обновляются как единое целое. На целевой стороне VKS всегда работает нативный Velero.
Ориентироваться следует на ресурсы DataUpload и DataDownload, а не на фазу Backup или Restore: именно ресурсы данных являются источником истины. PartiallyFailed — нормальное конечное состояние для восстановления, и только постпроверочное сканирование вместе с чек-листом приёмки решают, прошла ли партия.
Асимметрия ёмкости: файловые системы вне vSphere (например, CephFS) сообщают всю номинальную ёмкость как доступную, тогда как целевые тома на vSphere CSI с ext4 заранее выделяют таблицы inode (около 1,7%) и резервируют 5% для root. Исходные PVC следует заполнять не более чем на 90%, а целевые PVC для патологически заполненных томов делать больше.

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

Сводим воедино: краткая таблица решений

Если источник…	А хранение…	Использовать путь	Простой (100 ГБ)	Основной инструментарий
Kubernetes на vSphere (TKG, OpenShift, Rancher, upstream)	vSphere CSI и FCD в vCenter	Zero-copy	Менее 2 минут	Velero (манифесты) и CnsRegisterVolume
VKS в VKS, разные vCenter	vSphere CSI	Копирование данных через vMotion	45–90 минут	vMotion и CnsRegisterVolume
Kubernetes на vSphere	Сторонний CSI, FCD отсутствует	Копирование данных	45–90 минут	Velero с Restic или Kopia либо pv-migrate
Kubernetes вне vSphere (облако, «голое железо»)	Любое хранение вне vSphere	Копирование данных	45–90 минут	Velero, CSI Data Mover и S3

Несколько правил, действующих для всех четырёх методов

Каким бы ни был выбранный путь, эти правила работают всегда:

Разделять конфигурацию без состояния и хранение с состоянием. Velero переносит манифесты, путь хранения переносит данные. Смешивать их не нужно.
Никогда не обслуживать трафик с обеих сторон одновременно. Перед финальной партией источник нужно остановить или масштабировать вниз, либо выполнить дельта-партию прямо перед переключением. Две расходящиеся живые копии — самый быстрый способ получить повреждение данных.
Сохранять метаданные PVC, принадлежащие приложению (метки и аннотации для Helm и операторов), но никогда не копировать метаданные привязки и выделения, сгенерированные самим Kubernetes: на восстановленной целевой стороне они не совпадут.
Явно обрабатывать состояние Helm. Не удалять вслепую секреты релизов Helm; до переключения извлечь значения и версию чарта из источника и выполнить сверку с ключом --take-ownership.
Проверять до продвижения. Шлюз продвижения контролирует, что PVC находится в состоянии Bound, реплики готовы, а конечная точка проверки состояния приложения отвечает healthy. До перевода волны в стабильное состояние должны пройти все четыре проверки.
Откат всегда репетируется. Zero-copy даёт RTO менее 10 минут, копирование данных даёт дешёвый откат, поскольку источник не тронут. В любом случае RTO нужно знать до переключения.

Итог

Правильная стратегия миграции — та, что соответствует месту, где данные уже находятся. Если тома уже являются дисками FCD в vSphere, zero-copy-адаптация превращает миграцию в операцию с метаданными, измеряемую минутами. Если нет, хорошо настроенный конвейер копирования данных на Velero и S3, с дисциплинированной классификацией объектов и отрепетированным откатом, приведёт к цели столь же безопасно, просто по графику, который упирается в полосу пропускания. А если инфраструктура уже работает на VKS, vMotion вместе с CnsRegisterVolume позволяет переезжать между кластерами вообще без копирования на уровне Kubernetes.

Обратная связь

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

Шифрованный vMotion на Intel QAT в VCF 9.1: цифры из тестов

Mon, 24 Aug 2026 17:06:27 UTC

Шифрованный vMotion уже много лет остаётся одним из краеугольных камней защиты рабочих нагрузок в средах VMware. Он гарантирует, что данные виртуальной машины защищены при передаче каждый раз, когда ВМ перемещается между хостами, и для большинства продуктивных сред это попросту обязательное требование. С выходом VMware Cloud Foundation (VCF) 9.1 эта защита становится ещё эффективнее: криптографическая работа перекладывается на Intel QuickAssist Technology (QAT) — аппаратный ускоритель, встроенный в современные процессоры Intel Xeon. В VCF 9.1 функция включена по умолчанию и не требует какой-либо настройки. Команде инженеров было важно понять, сколько именно вычислительной мощности CPU возвращается заказчику, когда шифрованием занимается QAT, а не процессор. Тесты были проведены, и результаты дают вполне однозначную картину.

Как работает разгрузка на QAT

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

Стенд для тестирования

Для испытаний требовалась нагрузка, чувствительная к доступности CPU, — такая, на которой было бы отчётливо видно, что происходит с производительностью приложения, когда процессор получает обратно такты, ранее уходившие на шифрование. Выбор пал на базу данных Oracle под управлением HammerDB — OLTP-нагрузку с интенсивным профилем дисковых операций. Основной метрикой состояния системы на протяжении всех испытаний служила пропускная способность транзакций Oracle (операций в секунду).

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

Тестировались три конфигурации:

Шифрование отключено: теоретический потолок без каких-либо криптографических накладных расходов.
QAT Off: шифрованный vMotion полностью выполняется программно силами CPU.
QAT On: шифрованный vMotion разгружен на аппаратный ускоритель Intel QAT.

Результаты

Медианные значения по всем восьми миграциям:

Метрика	Шифрование отключено	QAT OFF	QAT ON
Время миграции (секунды)	57,22	86,97	84,71
Пропускная способность предварительного копирования (МБ/с)	10 871	7 592	7 146
CPU исходного хоста (среднее число одновременно занятых ядер)	7,8*	20,1	7,7
CPU целевого хоста (среднее число одновременно занятых ядер)	18,8*	13,6	10,5
Пропускная способность Oracle (операций/с)	51 319	44 306	50 634
Время простоя ВМ (секунды)**	0,42	0,33	0,78

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

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

Экономия CPU на исходном хосте

Загрузка CPU исходного хоста падает с примерно 20,1 ядра при QAT Off до примерно 7,7 ядра при QAT On — это около 62% сокращения вычислительной мощности, расходуемой на шифрование vMotion на стороне источника. Процессорные ресурсы, ранее занятые шифрованием, теперь могут быть отданы работе Oracle. Целевой хост тоже выигрывает: накладные расходы на расшифровку сокращаются примерно на 23% (с ~13,6 до ~10,5 ядра). Больший выигрыш достаётся исходному хосту, поскольку шифрование из этих двух операций вычислительно более затратно.

Пропускная способность Oracle

При QAT Off пропускная способность Oracle в окне миграции составляла 44 306 операций в секунду. При QAT On она восстановилась до 50 634 операций в секунду, что на 14% больше, чем при чисто программном шифровании. Для OLTP-среды, где темп транзакций напрямую отражается на бизнес-результате, эта возвращённая пропускная способность имеет вполне ощутимую ценность.

Время миграции

Конфигурации QAT On и QAT Off дают практически одинаковое время миграции — 84,71 против 86,97 секунды. Разгрузка на QAT и не рассчитана на то, чтобы ускорять саму миграцию. Операции копирования по сети и работы с памятью занимают одинаковое время в обоих случаях. Меняется другое — сколько процессорного запаса остаётся работающей нагрузке, пока идёт эта передача.

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

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

Результаты при одновременных миграциях vMotion

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

При невысокой степени параллелизма (от 4 до 6 ВМ одновременно на каналах 25–50 GbE) QAT обеспечивает сокращение нагрузки на CPU на 40–45% без изменения времени завершения миграций. При более высокой степени параллелизма, характерной для полной эвакуации хоста, миграции завершаются практически с той же скоростью, что и без QAT, тогда как потребление CPU на исходном хосте снижается вплоть до ~39%. Плановое обслуживание или аварийная эвакуация — в обоих случаях QAT возвращает задействованным хостам заметный запас процессорной мощности.

Возврат CPU рабочим нагрузкам

Основная ценность разгрузки на QAT состоит не в скорости миграции. Она в том, что именно возвращается системе. Каждое ядро вычислительной мощности, которое QAT удерживает от работы по шифрованию, — это ядро, которое рабочая нагрузка забирает себе для полезной работы. В проведённых тестах это выразилось в 14% приросте пропускной способности Oracle, удерживаемом на протяжении всего окна миграции, и примерно 62% сокращении вычислительной мощности, потребляемой шифрованием на исходном хосте, что эквивалентно примерно 12 освободившимся ядрам во время миграции.

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

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

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

Если VCF 9.1 уже работает на поддерживаемом оборудовании Intel Xeon, разгрузка на QAT уже активна. В среде виртуализации настраивать ничего не требуется. Практический вопрос в другом — что именно дадут конкретной инфраструктуре возвращённые процессорные такты. Для нагрузок с интенсивным OLTP-профилем вроде Oracle ответ очевиден: это пропускная способность транзакций, которую QAT возвращает приложению. Для других чувствительных к CPU нагрузок профиль выигрыша схож.

Итоги

Разгрузка на QAT в VCF 9.1 даёт примерно на 62% меньше накладных расходов CPU на исходном хосте, на 14% более высокую пропускную способность Oracle, удерживаемую в течение окна миграции, и меньший разброс времени миграции и производительности приложения при повторяющихся прогонах. Всё это происходит прозрачно на уровне инфраструктуры, на оборудовании, которое уже присутствует в большинстве развёртываний на Intel Xeon. Шифрованный vMotion продолжает делать ровно то же, что делал всегда: защищать рабочие нагрузки при передаче. Разгрузка на QAT лишь позволяет ему делать это, одновременно возвращая процессорные ресурсы тем нагрузкам, которым они нужны.

Тем, кто ещё не перешёл на VCF 9.1, это даёт конкретный измеримый повод для обновления. Для тех, кто уже работает на этой версии, описанный механизм уже действует в их среде. Проверить, поддерживает ли конкретная модель Intel Xeon технологию QAT, можно на ark.intel.com — и начать возвращать процессорные такты уже сегодня.

VMware ESXCLI 9.1.0: упрощённая установка и усиленная безопасность

Thu, 20 Aug 2026 10:56:00 UTC

Для администраторов vSphere и инженеров автоматизации ESXCLI остаётся одной из самых базовых утилит в наборе средств управления VMware. Она позволяет удалённо выполнять команды управления хостом: обращаться к хосту ESXi напрямую или работать с любым хостом под управлением vCenter Server — с локальной рабочей станции или административного jumpbox, без интерактивной SSH-сессии к самому хосту.

Недавно было объявлено о переводе автономной версии ESXCLI 9.1.0 (сборка 25692154) в статус общей доступности. Этот выпуск приносит упрощённую установку за счёт использования штатной упаковки Python, модернизацию платформы, ужесточение требований безопасности при проверке хоста, детальное управление клиентским логированием и критически важные исправления стабильности аутентификации.

Независимо от того, на какой системе выполняются задачи администрирования — Linux, macOS или Windows, — ESXCLI 9.1.0 делает удалённое управление более безопасным, доступным и надёжным.

Что нового в ESXCLI 9.1.0

1. Современные требования к Python и упрощённая поставка через PyPI

ESXCLI 9.1.0 распространяется как единый пакет Python, совместимый с PyPI. Установку и обновление автономной версии на Linux, Windows и macOS теперь можно выполнять стандартными инструментами управления пакетами Python.

Системные требования:

Версия Python: требуется Python 3.10 или новее.
Отказ от устаревших версий: Python 2.7 и версии Python ниже 3.10 больше не поддерживаются.

Чтобы установить ESXCLI 9.1 через PyPI, выполните:

pip install vmware-esxcli

Автономный пакет также можно загрузить напрямую с портала Broadcom Developer Portal.

2. Ужесточение требований безопасности: отказ от SHA-1

Требования стандартов безопасности в корпоративной инфраструктуре продолжают развиваться. В ESXCLI 9.1.0 отпечатки серверных сертификатов SHA-1 официально больше не принимаются.

Уведомление о критическом изменении

При установлении проверенных удалённых сессий поддерживаются только отпечатки SHA-256 и SHA-512. Это относится к следующим способам передачи отпечатка:

параметр командной строки --thumbprint;
переменная окружения VI_THUMBPRINT;
записи, сохранённые в хранилище учётных данных ESXCLI.

Важное действие, которое нужно выполнить до обновления: проверьте автоматизированные скрипты, конвейеры CI/CD, переменные окружения и конфигурации хранилища учётных данных. Отпечатки SHA-1 необходимо заменить на отпечатки SHA-256 или SHA-512 до перехода на новую версию. Соединения, опирающиеся на отпечатки SHA-1, в версии 9.1.0 работать не будут.

Пример: запуск ESXCLI с отпечатком SHA-256

esxcli --server=vcenter.domain.local --target=esxi01.domain.local 
--username=administrator@vsphere.local 
--thumbprint=25:E3:4C:…:SHA256_THUMBPRINT… 
system version get

3. Гибкое управление клиентским логированием

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

Поведение по умолчанию: клиент больше не создаёт файл журнала на диске и не пишет в него.
Произвольный путь к журналу (--log-file): перенаправление клиентских сообщений журнала в выбранный вами файл.
Подробное и отладочное журналирование (--log-verbose): включение детализации уровня debug для изучения деталей протокола и диагностики проблем с подключением или выполнением команд.

Пример: подробное журналирование в произвольный файл

esxcli --server=esxi01.domain.local 
--log-file=/var/log/esxcli-debug.log 
--log-verbose 
network nic list

Чек-лист обновления для администраторов

Прежде чем переходить на версию 9.1, держите в уме этот короткий список проверок:

Проверьте окружение Python: убедитесь, что на административных рабочих станциях используется Python 3.10 или новее.
Обновите отпечатки: замените все отпечатки SHA-1 в скриптах и сохранённых хранилищах учётных данных на отпечатки SHA-256 или SHA-512.
Пересмотрите сценарии работы с журналами: если какие-либо пользовательские рабочие процессы полагаются на чтение файла журнала, который раньше создавался по умолчанию рядом с бинарным файлом ESXCLI, обновите эти сценарии так, чтобы они явно передавали --log-file <path>.

Загрузка и документация

Начать работу можно уже сегодня:

Загрузка с портала Broadcom Developer Portal: Download ESXCLI 9.1.0
Дистрибутив в PyPI: pip install vmware-esxcli
Официальные заметки о выпуске: ESXCLI 9.1.0 Release Notes

Новый модуль VMware Bootstrap Registry Appliance для изолированных сред VCF 9.0

Wed, 19 Aug 2026 12:52:09 UTC

Развёртывание контейнерных нагрузок в изолированных (air-gapped) средах всегда требовало тщательной проработки — особенно в ситуации, когда реестр платформы, который планируется использовать, не может установить сам себя без образов, которых у него ещё нет. Именно поэтому упрощение развёртывания Harbor в качестве Supervisor Service в изолированных средах VMware Cloud Foundation (VCF) стало одним из ключевых направлений работы. Раньше эффективным промежуточным решением служили наработки сообщества, например сторонние реестры, а теперь предлагается официальный, поддерживаемый в рамках VCF вариант, спроектированный специально под этот сценарий.

С выходом VMware Bootstrap Registry Appliance в полной доступности (General Availability) появилось официальное решение с поддержкой со стороны VCF: специализированный OVA-образ, который даёт заказчикам VCF чистый, безопасный и чётко регламентированный с эксплуатационной точки зрения путь первоначальной загрузки (bootstrapping) Harbor в роли Supervisor Service в изолированных средах VCF 9.0 и vSphere 8.0 Update 3.

Что такое VMware Bootstrap Registry Appliance

VMware Bootstrap Registry Appliance — это защищённый (hardened) виртуальный модуль, распространяемый в формате OVA. В его составе поставляется совместимый со спецификацией OCI реестр Harbor, работающий нативно на Photon OS 5.0. Модуль предназначен для размещения OCI-образов, необходимых для включения Harbor Supervisor Service (а также Contour) на vSphere Supervisor.

При этом модуль не является универсальным корпоративным реестром и не предназначен для обслуживания рабочих нагрузок в продуктивной среде. Его роль — Registry 0 в последовательности развёртывания изолированной среды: это временный инструмент первоначальной загрузки, который передаёт ответственность сервису Harbor Supervisor Service (Registry 1), как только тот становится работоспособным и функционирует штатно.

Чтобы обеспечить соответствие архитектурным требованиям и сохранить право на поддержку, развёртывание VMware Bootstrap Registry Appliance регулируется следующими обязательными эксплуатационными ограничениями:

Исключительно задача bootstrap: VMware Bootstrap Registry Appliance допускается применять только для загрузки и хранения OCI-образов, необходимых для включения сервисов Contour и Harbor Supervisor на Supervisor.
Запрет вторичных ролей: модуль не должен использоваться в инфраструктуре ни для каких иных целей. В частности, прямо запрещено его применение в качестве постоянного реестра платформы или корпоративного реестра рабочих нагрузок.
Ограничение по версии развёртывания: использование VMware Bootstrap Registry Appliance допускается только в развёртываниях версий ниже VCF 9.1. Начиная с VCF 9.1 официально поддерживаемым решением для управления жизненным циклом изолированных сред становится Fleet Depot Service (FDS).

Загрузка VMware Bootstrap Registry Appliance

Модуль доступен на портале Broadcom Support Portal по следующим путям:

Для vSphere 8.0: Broadcom Support Portal > My Downloads > VMware vSphere > VMware vSphere Standard > 8.0 > Drivers and Tools > VMware Bootstrap Appliance > BOOTSTRAP_APPLIANCE-2.15.2+vmware.1-25635995.ova
Для VCF 9.0: Broadcom Support Portal > My Downloads > VMware Cloud Foundation > VMware Cloud Foundation 9 – 9.0.2 > VMware vCenter > Drivers and Tools > VMware Bootstrap Appliance > BOOTSTRAP_APPLIANCE-2.15.2+vmware.1-25635995.ova

Обзор процесса развёртывания

Развёртывание VCF в изолированной среде выполняется по двухфазной схеме. Сначала, на первой фазе, создаётся bootstrap-реестр на базе VMware Bootstrap Registry Appliance. На второй фазе разворачивается Harbor в качестве Supervisor Service, который затем становится продуктивным реестром для всех рабочих нагрузок.

Полное пошаговое описание, включающее развёртывание OVA, регистрацию на Supervisor, предварительную загрузку образов с помощью Carvel imgpkg и настройку data values для Harbor, требуемую при работе в изолированной среде, приведено в обновлённой статье о развёртывании: Deploying Harbor Service in Air-Gapped VMware Cloud Foundation 9.0, а также в репозитории VMware vSphere Supervisor на GitHub.

Взгляд в будущее: VCF 9.1 и Fleet Depot Service

Сегодня VMware Bootstrap Registry Appliance является подходящим решением для сред VCF 9.0 и vSphere 8.0 U3. Заказчики, которые перейдут на VCF 9.1, смогут воспользоваться преимуществами Fleet Depot Service (FDS). Этот встроенный реестр нативно обслуживает жизненный цикл первоначальной загрузки как часть платформы. В средах VCF 9.1 VMware Bootstrap Registry Appliance больше не требуется, поскольку эту роль берёт на себя FDS.

Заключение

Таким образом, VMware Bootstrap Registry Appliance закрывает пробел в сценарии развёртывания изолированных сред VCF. Он представляет собой специализированный и поддерживаемый инструмент первоначальной загрузки сервиса Harbor Supervisor Service. Решение на базе Bitnami Harbor заменяется альтернативой, готовой к промышленной эксплуатации. Этот путь рекомендуется как при развёртывании с нуля на VCF 9.0, так и при миграции уже существующей изолированной среды.

Загрузить модуль можно с Broadcom Support Portal в разделах VMware vSphere или VCF 9.0, а полное пошаговое описание приведено в обновлённом руководстве по развёртыванию Harbor в изолированной среде.

Дополнительные сведения о Harbor доступны в серии статей:

Управляющий уровень VMware Cloud Foundation для нагрузок Kubernetes

Fri, 14 Aug 2026 21:38:28 UTC

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

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

В недавнем вебинаре Activating VKS Supervisor to Support Kubernetes было показано, как активация управляющего уровня, называемого vSphere Supervisor, в VMware Cloud Foundation (VCF) 9.1 напрямую решает эту дилемму современных приложений.

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

Преодоление разрыва: что такое vSphere Supervisor

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

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

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

Для администраторов vSphere: контроль и соответствие требованиям сохраняются за счёт пространств имён vSphere Namespaces. Администраторы задают границы ресурсов (квоты на CPU, память и хранилище), назначают ролевую модель доступа (RBAC) и сохраняют полную операционную видимость через vSphere Client и VMware Cloud Foundation Operations.
Для DevOps-инженеров: платформа предоставляет стандартную конечную точку API Kubernetes. Инженеры могут применять декларативные YAML-манифесты через kubectl и Helm, чтобы разворачивать кластеры рабочих нагрузок (кластеры VKS), виртуальные машины (через VM Service) и контейнеризованные нагрузки прямо внутри выделенных им пространств имён vSphere.

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

Архитектура vSphere Supervisor и высокая доступность

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

На низком уровне примитивы хранения и вычислений тесно связаны между собой, что помогает обеспечить высокую доступность. Алгоритм размещения управляющего уровня динамически распределяет виртуальные машины по доменам отказа, а временные данные обслуживаются через эфемерные диски (Ephemeral Disks), которые автоматически очищаются при завершении работы пода. Кроме того, диски с образами контейнеров кэшируются непосредственно на отдельных хостах ESX, что позволяет обойти задержки загрузки из реестра и обеспечить практически мгновенное создание подов и их восстановление при отказе хоста.

Топологии хранения и управление политиками

Приложениям с сохранением состояния, построенным по облачно-нативным принципам, требуется надёжная работа с постоянным хранилищем. vSphere Supervisor связывает запросы Kubernetes на постоянные тома с примитивами хранения vSphere через Cloud Native Storage (CNS) и нативный драйвер vSphere Container Storage Interface (CSI).

Когда разработчик отправляет запрос PersistentVolumeClaim (PVC), драйвер CNS-CSI напрямую обращается к vCenter и транслирует этот запрос в диск First Class Disk (FCD) на нижележащем хранилище. Администраторы обеспечивают управляемость, назначая политики хранения (например, Gold, Silver) и лимиты ёмкости непосредственно пространствам имён vSphere.

vSphere Supervisor поддерживает три различные топологии хранения, рассчитанные на конкретные требования рабочих нагрузок:

Хотя чаще всего в качестве примера приводится гиперконвергентный vSAN, традиционные внешние массивы хранения (Fibre Channel, iSCSI и NFS) отображаются на те же самые топологии. Стандартные внешние хранилища SAN/NAS, подключённые к одному кластеру vSphere, работают как зональные хранилища (Zonal Datastores). В мультизональных развёртываниях заказчики, использующие репликацию на уровне сторонних массивов — например, метрокластеры хранения на базе FC/iSCSI, — могут добиться доступности межзональных хранилищ (Cross-Zone Datastore) без применения нативного растянутого кластера vSAN.

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

Сеть и балансировка нагрузки в vSphere Supervisor

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

Маршрутизация трафика между пространствами имён, управляющими сетями и внешними сервисами обеспечивается транзитными шлюзами Tier-0 и Tier-1, что помогает организовать безопасную и высокопроизводительную транзитную передачу по сетевой фабрике. Для балансировки нагрузки и входящего трафика vSphere Supervisor интегрируется с VMware Avi Load Balancer. Эта интеграция автоматизирует выделение и управление жизненным циклом виртуальных IP-адресов (VIP), балансировщиков для конечной точки API Kubernetes и контроллеров ingress уровней L4/L7, обеспечивая точное управление трафиком, полностью автоматическую настройку сети и глубокую изоляцию по безопасности без ручного вмешательства в сетевую конфигурацию.

Современная сеть: NSX VPC и транзитные шлюзы

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

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

Ключевые возможности этой сетевой архитектуры:

Изолированные VPC для каждого пространства имён: каждое пространство имён vSphere изолировано внутри собственного NSX VPC с приватными подсетями и выделенными шлюзами VPC.
Отсутствие конфликтов IP и развязанная маршрутизация: развязанная маршрутизация между VPC позволяет разным командам разработки использовать пересекающиеся диапазоны IP без сетевых коллизий.
Линейная масштабируемость: централизованные транзитные шлюзы безопасно обрабатывают высокоскоростную маршрутизацию между пространствами имён и во внешние сети через шлюзы Tier-0/Tier-1.
Встроенная балансировка нагрузки: Avi Load Balancer автоматизирует маршрутизацию трафика через контроллер ingress и балансировку API Kubernetes.

Пошаговая активация и сценарий демонстрации

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

Наблюдаемость на этапе Day-2: вся телеметрия, метрики производительности и логи поступают напрямую в централизованный VCF Operations для проактивного мониторинга и операций жизненного цикла.

Предварительные требования и запуск активации: перед запуском активации Supervisor необходимо убедиться, что выполнены базовые требования: действующий домен рабочих нагрузок VCF с включёнными vSphere HA и DRS, сетевая конфигурация на базе NSX или распределённого коммутатора vSphere с назначенными пулами IP-адресов, поддерживаемый балансировщик нагрузки, выделенная политика хранения vSphere и подписная библиотека контента (Subscribed Content Library). После этого активацию можно инициировать при создании домена рабочих нагрузок в VCF Operations либо уже после развёртывания непосредственно в vCenter в разделе Supervisor Management -> Get Started, где мастер перед развёртыванием проверяет вычислительные зоны, политики хранения, библиотеки контента и настройки балансировки нагрузки.

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

Декларативное развёртывание: DevOps-инженер аутентифицируется на управляющем уровне vSphere Supervisor через kubectl и применяет YAML-манифест с запросом на новый кластер VKS. vSphere Supervisor автоматически разворачивает узлы управляющего уровня и рабочие узлы.

Двойная перспектива наблюдения: администратор виртуальной инфраструктуры отслеживает состояние инфраструктуры и объекты виртуальных машин в vSphere и VCF Operations, тогда как разработчик управляет подами, сервисами и развёртываниями через kubectl.

Развёртывание гибридного приложения: команды разворачивают многоуровневые приложения, объединяющие виртуальные машины (через API службы VM Service) и контейнеризованные нагрузки на базе Helm-чартов.

Заключение и что дальше

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

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

Готовы попробовать на практике?

Лабораторные работы: доступна лабораторная работа Hands-on Lab по Kubernetes.
Официальная документация: полезные материалы:
Учебные курсы: войдите в Learning@Broadcom через портал поддержки Broadcom, раздел «Education Portal», чтобы получить доступ к следующим курсам по VKS:

Если по проектам VKS нужна помощь, обратитесь к своему аккаунт-менеджеру Broadcom, чтобы узнать, чем могут помочь профессиональные сервисы VCF и партнёры, такие как TeraSky.

Производительность Memory Tiering в VMware Cloud Foundation 9.x

Tue, 11 Aug 2026 09:40:12 UTC

Механизм Memory Tiering в VMware Cloud Foundation 9 использует два типа устройств памяти, чтобы нарастить её объём при существенно меньшей стоимости. Технология незаметно для виртуальных машин отслеживает активность обращений к памяти и удерживает часто используемые данные в быстрой и дорогой DRAM, вытесняя редко запрашиваемые страницы на второй, более медленный и дешёвый уровень на NVMe-накопителе.

Такой подход оптимизирует совокупную стоимость владения (TCO), сохраняя производительность на уровне систем исключительно на DRAM. Тестирование инженеров Broadcom с помощью отраслевых бенчмарков VMmark, Login Enterprise, DVD Store и HammerDB показало, что потери на разнообразных корпоративных нагрузках не превышают 10%. При этом плотность виртуальных машин удваивается, а экономия TCO достигает 40%.

Зачем понадобилось разделение памяти на уровни

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

В VCF 9.0 Memory Tiering предоставляет виртуальным машинам единое логическое пространство памяти, а под капотом управляет двумя её типами в зависимости от активности обращений:

Tier 0 — высокоскоростная DRAM: дорогая и очень быстрая системная память, где остаётся активная, «горячая» память.
Tier 1 — устройства NVMe: производительные SSD, более медленные и заметно более дешёвые, куда переносится неактивная, «холодная» память.

После включения тиринга информация о нём доступна в интерфейсе VMware vCenter: вкладка Configure > Hardware > Overview > Memory. Там отображается суммарный объём памяти и его распределение по уровням — например, 1 022,93 ГБ всего, из которых 511,46 ГБ приходится на Tier 0 и столько же на Tier 1. Настройка описана в документации vSphere, а бизнес-обоснование технологии разобрано в блоге VMware Cloud Foundation.

Архитектура

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

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

Методика тестирования

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

Бенчмарк	Нагрузка	Результат
Login Enterprise	Приложения VDI	Двукратный рост плотности ВМ, потери 0–8%
VMmark	Корпоративные приложения	Двукратный рост плотности ВМ, потери 5%
DVD Store	Oracle Database	Двукратный рост плотности ВМ, потери менее 5%
HammerDB	SQL Server, MySQL	Двукратный рост плотности ВМ, потери 5–10%

Все цифры относятся к двукратной плотности виртуальных машин; при меньшей плотности влияние на производительность будет ниже или вовсе незаметным. Соотношение DRAM к NVMe по умолчанию в VCF 9.0 составляет 1:1 — при 1 ТБ DRAM можно получить ещё около 1 ТБ памяти на NVMe. Во всех тестах применялось именно оно.

Результаты представлены через три группы метрик: прирост плотности виртуальных машин, разница в производительности относительно системы только на DRAM и загрузка процессора — как в части дополнительно утилизируемых ресурсов, так и в части накладных расходов тиринга. Чтобы точнее отразить последние, большие страницы (large pages) на хосте везде оставались отключёнными — это настройка по умолчанию для ESX с тирингом.

Метрика активной памяти в разных инструментах называется по-разному: в esxtop это TCHD (touched memory), причём общехостового счётчика нет и значения всех машин приходится суммировать; в vCenter — счётчик Active в разделе Monitor > Performance > Overview > Memory; в VCF Operations — Metrics > Memory > Guest Active.

VDI: тестирование с Login Enterprise

Login Enterprise от Login VSI — отраслевой стандарт для оценки ёмкости и производительности VDI: виртуальные пользователи имитируют реальных сотрудников и замеряют время отклика на каждое взаимодействие. Инфраструктурой рабочих столов служила Omnissa Horizon. Из двух преднастроенных профилей выбран knowledge worker как самый тяжёлый и распространённый: он включает девять приложений, среди которых Word, PowerPoint, Excel, Outlook, браузер Edge и потоковое видео. Главная метрика — оценка пользовательского опыта EUX, складывающаяся из таймеров типичных действий: отзывчивости приложений, обработки клавиатурного ввода, ресурсоёмких вычислений и задержек дисковых операций.

Тесты шли в двух вариантах провижининга: с отключённым межмашинным Pshare (ModeB) и с включённым (ModeA). В ModeA мгновенные клоны при создании клонируются от родительской ВМ и разделяют её память; в ModeB — от выключенной ВМ-реплики, без разделения. Режимы различаются не только поведением разделения страниц, но и работой алгоритма тиринга, поэтому в исследование вошли оба. Одиночный узел — Dell PowerEdge R760 с двумя Intel Xeon 8480 (56 ядер на сокет) и 1 или 2 ТБ DRAM, устройство тиринга Dell Ent NVMe P5620 MU на 1,6 ТБ, рабочие столы Windows 11 на 2 vCPU.

В режиме ModeB машинам выделялось 8 ГБ RAM: при 1 ТБ DRAM это давало около 120 VDI-сессий, а добавление 1 ТБ на NVMe позволило довести их число до 240. Потери составили менее 6% относительно варианта только на DRAM (1 ТБ). Оценка EUX снизилась с 8,6 до 8,3 при сравнении дорогой системы с 2 ТБ DRAM и заметно более дешёвой с 1 ТБ DRAM плюс 1 ТБ тиринга — падение всего около 3,5%. Загрузка процессора выросла с 63,5% до 74%: перемещение данных между уровнями имеет свою цену.

Время отклика приложений изменилось незначительно: Outlook открывался за 1,10 секунды против 0,94 на чистой DRAM, запуск Excel и PowerPoint замедлился примерно на 0,002 секунды. Активная память хоста держалась в диапазоне 420–450 ГБ — около 50% от ёмкости DRAM. Динамика EUX по мере роста числа сессий тесно коррелирует с показателями NVMe: когда задержка поднималась выше 200 микросекунд, метрики CPU score и Generic application score проседали, а при стабилизации около 200 микросекунд снова росли вместе с общей оценкой.

В режиме ModeA машинам выделялось 6 ГБ: выигрыш от разделения страниц оставляет алгоритму больше пространства для масштабирования. Число сессий выросло с 160 до 320. Оценка EUX снизилась с 8,7 до 7,9, но причина не в тиринге: в первом случае процессор работал с турбо-ускорением в 1,5 раза, а при 320 машинах из-за высокой загрузки его частота была близка к номинальной. С включёнными большими страницами EUX составила 8,3 при загрузке CPU 84,5%, с отключёнными — 7,9 при загрузке 90%. Сравнение 8,3 и 7,8 даёт потерю 6%, а если брать только малые страницы, падение с 7,9 до 7,8 — порядка 1%. Столь низкие потери согласуются с задержкой NVMe всего в 100 микросекунд при пропускной способности чтения заметно ниже 100 МБ/с.

Многоузловые тесты шли на трёхузловом кластере vSAN архитектуры ESA с RAID 5 на серверах Dell PowerEdge R660 с двумя Intel Xeon 6430 (32 ядра на сокет) и 512 ГБ DRAM: четыре NVMe в каждом хосте отданы под vSAN, пятое — под тиринг. В режиме ModeB тиринг позволил удвоить плотность машин за счёт добавления 512 ГБ NVMe, при этом оценка EUX относительно 1 ТБ DRAM снизилась лишь на 8%. Пропускная способность чтения NVMe составляла около 200 МБ/с, задержки стартовали со 100 микросекунд, поднимались до 400 по мере добавления сессий и опускались до 200 в установившемся режиме.

Во втором наборе тестов число рабочих столов увеличили до 200 на хост, то есть до 600 на кластер, с мгновенными клонами по 5 ГБ и провижинингом ModeA. Оценки EUX для DRAM (1 ТБ) и Memory Tiering (1 ТБ) составили 6,9 и 7,0 при загрузке процессора выше 90% в обоих случаях — то есть удвоение плотности прошло вовсе без потерь производительности. Задержки устройства тиринга достигали 150 микросекунд, пропускная способность держалась около 200 МБ/с, активная память доходила до 320 ГБ — 62,5% от доступной DRAM.

Корпоративные приложения: VMmark

VMmark оценивает производительность и масштабируемость виртуализованных ЦОД. Бенчмарк объединяет типовые приложения (standby, DVD Store и Weathervane) в блоки-«тайлы»; один тайл состоит из 19 Linux-машин с нагрузками от 1 до 8 vCPU и от 4 до 250 ГБ памяти. Использовалась конфигурация с большим объёмом памяти: размер ВМ с базой увеличен с 32 до 250 ГБ, размер базы — со 100 до 300 ГБ, время раздумий — с 1 до 1,5 секунды, чтобы сделать тест в большей степени memory-intensive, чем compute-intensive. Тестовая система — два Intel Xeon 8592 по 64 ядра с 1 или 2 ТБ DRAM, устройство тиринга Samsung PM9A3 на 3,84 ТБ, на тайл приходилось 376 ГБ памяти и 31 vCPU.

Итоговая оценка агрегирует метрики пропускной способности приложений с нормализацией по весу каждого, а тайлы добавлялись до появления сбоев качества обслуживания. Конфигурация только на DRAM (1 ТБ) выдержала 57 виртуальных машин в трёх тайлах, конфигурация с тирингом (2 ТБ) — 114 машин в шести тайлах.

Сравнение трёх конфигураций показывает накладные расходы технологии по производительности и по процессору. В базовом варианте загрузка CPU была ограничена нехваткой памяти, тогда как при большем её объёме сервер утилизировался значительно плотнее. Производительность тиринговой конфигурации оказалась менее чем на 5% ниже варианта с 2 ТБ DRAM — притом что хост располагал лишь 1 ТБ реальной DRAM. Пропускная способность чтения NVMe была чуть выше рекомендованной, но задержка оставалась около 100 микросекунд, и производительность не пострадала.

Базы данных: SQL Server, Oracle и MySQL

Нагрузки баз данных требовательны к процессору, дискам и памяти одновременно, что делает их хорошим полигоном для проверки тиринга. Тестировались СУБД, типичные для развёртываний VCF: Microsoft SQL Server 2022, Oracle Database 21c и MySQL 8.0.

SQL Server измерялся с помощью HammerDB 5.0 (профиль TPC-C, 1000 складов, 125 виртуальных пользователей) на Dell PowerEdge R760 с 512 ГБ или 1 ТБ DRAM и виртуальными машинами на 8 vCPU и 80 ГБ. На хосте с 512 ГБ DRAM удавалось запустить не более 6 машин — при попытке добавить больше транзакции завершались по таймауту. Расширение памяти до 1 ТБ с помощью тиринга позволило удвоить их число. Прирост производительности при переходе от 512 ГБ к 1 ТБ DRAM составил 1,6 раза (нелинейность объясняется факторами, не связанными с тирингом), а падение при сравнении DRAM (1 ТБ) и тиринга (1 ТБ) не превысило 10%.

Активная память в установившемся режиме составляла около 256 ГБ, а процессорная нагрузка снизилась, поскольку машины ожидали обслуживания промахов DRAM накопителем. Задержка чтения NVMe на фазе разогрева держалась в районе 300–400 микросекунд и стабилизировалась примерно на 200 в измерительной фазе. Показательна корреляция: пока активная память на разогреве превышала 50% от DRAM, число транзакций в минуту проседало; когда она устоялась на уровне около 50%, показатель TPM вырос и стабилизировался.

Oracle Database 21c тестировалась на Oracle Enterprise Linux 8.8 с нагрузкой DVD Store 3.5: 600 пользователей на машину, время раздумий 5 секунд, база около 200 ГБ. Система — односокетный AMD EPYC 9755 на 128 ядер с 768 ГБ DRAM, виртуальные машины на 16 vCPU и 192 ГБ. Проверялись три сценария: 768 ГБ DRAM, 1,5 ТБ DRAM и тиринговый вариант из 768 ГБ DRAM плюс 768 ГБ NVMe. Число машин подбиралось так, чтобы полностью законтрактовать память: 4 машины на 768 ГБ и 8 машин на 1,5 ТБ. Результат — рост с 4 до 8 машин при потере менее 5% относительно 1,5 ТБ чистой DRAM.

Особенно показательна динамика процессора: в базовом сценарии его загрузка была ограничена 43%, а с тирингом достигла 85%. Это наглядно демонстрирует способность технологии раскрывать ёмкость хоста там, где система упирается в память, а процессорные циклы простаивают. Активная память по счётчику touched memory в esxtop в среднем составляла около 400 ГБ — чуть больше 50% от DRAM, а средняя задержка чтения NVMe — 86 микросекунд при пропускной способности около 35 МБ/с.

MySQL 8.0 на RHEL 9.4 тестировался тем же HammerDB на машинах с 14 vCPU и 60 ГБ; плотность также удалось удвоить при потере менее 5%. Параметром keyingandthinktime здесь регулировались нагрузка на процессор и объём активной памяти. При времени раздумий 10 миллисекунд загрузка CPU в базовом сценарии на 512 ГБ была высокой — 70%, активная память достигала 286 ГБ (около 55% ёмкости DRAM); при удвоении числа машин в работу вовлекались 224 vCPU и процессор доходил почти до насыщения, что объясняет нелинейное масштабирование. Когда время раздумий подняли до 45 миллисекунд, активная память выросла до 410 ГБ (около 80% DRAM), а загрузка CPU снизилась до 45% — благодаря запасу по процессору удвоение плотности дало двукратный рост пропускной способности. Примечательно, что даже при активной памяти на уровне 80% потери оказались минимальными: вероятно, большое время раздумий поглощало задержки NVMe.

Влияние на vMotion

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

Тестировался Dell PowerEdge R750 с двумя Intel Xeon 8380 и адаптерами Mellanox 100GbE. Четыре машины на 12 vCPU и 48 ГБ работали под RHEL 8.1 с Oracle 21c и SGA 43 ГБ, нагрузка создавалась HammerDB; чтобы активировать тиринг, память хоста искусственно уменьшили до 164 ГБ. В сценарии эвакуации хоста с одновременной миграцией всех четырёх машин пропускная способность Oracle оставалась практически неизменной: наблюдался единственный провал в фазе переключения, но простой не превышал секунды.

Сценарий	Среднее время миграции	Простой ВМ	Штраф для гостя
4 ВМ, базовый вариант (только DRAM)	23,5 секунды	менее 1 секунды	менее 5%
4 ВМ, Memory Tiering	82 секунды	менее 1 секунды	менее 5%

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

Эксплуатация и мониторинг

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

Активную память рекомендуется удерживать не выше 50% от ёмкости DRAM хоста; для некоторых нагрузок она может быть выше без каких-либо проблем. В диапазоне от 50% до 75% необходимы тестирование и наблюдение за конкретной нагрузкой. Выше 75% в большинстве случаев следует ожидать существенных потерь.

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

При выборе накопителя стоит ориентироваться на высокий класс износостойкости D и высокий класс производительности — более 100 000 операций записи в секунду при DWPD = 3 — а также на больший объём.

Нужные метрики доступны в vCenter на странице Advanced Performance через Chart Options. Пропускная способность записи показывает перенос холодных страниц на NVMe, чтения — извлечение страницы, которая снова стала активной, но отсутствует в DRAM; если чтение превышает 200 МБ/с, стоит присмотреться к задержкам. На качественном накопителе они остаются заметно ниже 200 микросекунд даже при 400 МБ/с, тогда как некоторые другие модели на схожем трафике показывают около 300. Чтобы понять, почему конкретная машина работает медленно, стоит посмотреть пропускную способность чтения в её разрезе: всплывающее окно графика позволяет вывести несколько машин сразу. Активная память хоста доступна там же, а также в VCF Operations.

Дополнительно рекомендуется обеспечить достаточный запас по процессору под накладные расходы тиринга; следить, чтобы загрузка CPU на нетиринговых хостах кластера не превышала 75%, иначе эффективность технологии может снизиться; и не использовать с Memory Tiering «монструозные» виртуальные машины — крупнее 32 vCPU и 512 ГБ DRAM.

Выводы

Memory Tiering — важное усовершенствование VCF 9, позволяющее за счёт добавления NVMe SSD получить значительно больший объём памяти при существенно меньшей стоимости по сравнению с использованием только DRAM. Технология решает проблему растущей стоимости памяти в ЦОД, оптимизируя совокупную стоимость владения серверами и нагрузками, ограниченными объёмом памяти.

Измерения на нескольких бенчмарках дали стабильно хорошие результаты: двукратный рост плотности виртуальных машин и экономия TCO до 40%. Тиринг также высвобождает процессорные ресурсы хоста, которые при дефиците памяти иначе остались бы неиспользованными, а простой машин при vMotion неизменно остаётся ниже одной секунды. Оптимальную производительность обеспечивает мониторинг двух показателей: активную память в идеале следует удерживать ниже 50% от объёма DRAM, а задержку устройства нижнего уровня — ниже 200 микросекунд.

Больше подробностей - в документе "Memory Tiering Performance VMware Cloud Foundation 9.0".

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