С выходом VMware Cloud Foundation 9.0 произошёл переломный момент в подходе к связыванию vCenter. VCF 9 вводит принципиально новую архитектуру единого входа (Single Sign-On) для всех компонентов частного облака, устраняя необходимость в классическом ELM для объединения серверов vCenter. Фактически, в окружениях на базе VCF 9 Enhanced Linked Mode более не используется для объединения vCenter в единый домен SSO...
Ландшафт корпоративного AI стремительно развивается, и организации сталкиваются с фундаментальными вопросами: как использовать генеративный AI, сохраняя контроль над собственными данными? Что необходимо для построения AI-инфраструктуры, которая масштабируется безопасно? Как перейти от экспериментов к рабочим AI-нагрузкам, готовым к промышленной эксплуатации?
На VMware Explore 2025 лидеры отрасли и технические эксперты напрямую рассмотрели эти критические задачи. От проектирования безопасных основ частного AI до подбора оптимальной инфраструктуры для ресурсоёмких AI-нагрузок — сессии предоставили практические инсайты, выходящие за пределы теоретических рамок и переходящие к стратегиям реальной реализации.
Будь вы инженер платформ, стремящийся внедрить AI во всей организации, специалист по безопасности, сосредоточенный на защите AI-нагрузок, или архитектор инфраструктуры, планирующий следующее AI-развёртывание, эти сессии предлагают проверенные подходы и полученные на практике уроки.
Вот ключевые AI-сессии, которые дают наиболее ясный путь вперёд для успеха при внедрении AI в корпоративной среде.
Building Secure Private AI Deep Dive [INVB1432LV]
С момента запуска VMware Private AI Foundation with NVIDIA это решение развилось и теперь предлагает надёжные сервисы, позволяющие превращать собственную интеллектуальную собственность в уникальные GenAI-приложения с использованием NVIDIA Inference Microservices (NIM), развёрнутых в архитектурах Retrieval Augmented Generation (RAG) в локальной инфраструктуре.
Присоединяйтесь к команде менеджеров продуктов VMware и NVIDIA совместно с UT Systems, чтобы узнать, как решение развивается, чтобы:
Поддерживать передовые GPU и системы HGX, разработанные специально для AI и использующие VMware Cloud Foundation (VCF)
Упростить доставку RAG-приложений с помощью: сервисов Private AI, включая среду исполнения моделей для развертывания LLM как сервиса; сервисов AI-данных, включая NVIDIA NeMo Microservices и сервис индексирования и поиска данных VMware; а также цифровых людей на VCF с использованием блупринтов NVIDIA.
Building Secure Private AI Deep Dive [INVB1432LV]
Узнайте, как безопасно создавать и масштабировать инфраструктуру Private AI с помощью VMware vDefend и VMware Private AI with NVIDIA. Эта сессия проведёт вас через процессы разработки надёжной архитектуры частного AI с встроенной защитой данных, изоляцией рабочих нагрузок и автоматическим применением политик.
Узнайте, как vDefend повышает безопасность AI-моделей с помощью сегментации и обнаружения угроз в реальном времени, а Private AI with NVIDIA предоставляет платформу для развертывания и управления AI-нагрузками с полным контролем.
Идеально подходит для архитекторов и команд безопасности: эта сессия предлагает практические инсайты для безопасного внедрения AI в среде частного облака.
Sizing AI Workloads in VMware Private AI Foundation [INVB1801LV]
По мере роста внедрения AI обеспечение оптимальной производительности и масштабируемости AI-нагрузок становится критически важным для получения точных результатов и своевременных инсайтов. В этой сессии мы разберём несколько типовых сценариев и покажем инструменты, которые помогут вам правильно рассчитать размеры ваших AI-нагрузок.
Tanzu AI Solutions Essentials: What You Need to Know to Get Up and Running [MODB1496LV]
Планируете запускать AI-нагрузки на своей платформе, но не знаете, с чего начать? Интересуетесь практической работой с AI с использованием VMware Tanzu Platform? Эта сессия предназначена для инженеров платформ, которым нужен практичный старт.
В ходе сессии рассмотриваются ключевые компоненты решений Tanzu AI — от готовности инфраструктуры до моделей развертывания, — чтобы вы могли включать, масштабировать и операционализировать AI в своих средах. Вы узнаете, как интегрировать AI-модели в новые или существующие платформы, обеспечивать управление и масштабируемость, а также предоставлять самообслуживание для команд данных и разработчиков.
Основные выводы включают архитектурные лучшие практики, ключевые шаги конфигурации и рекомендации по обеспечению быстрого и безопасного эксперимента с AI — чтобы вы были готовы поддерживать инновации с первого дня.
10 Big Benefits of Private AI That Make Your Decision Easy [CLOB1707LV]
В этой сессии мы поговорим о том, что такое Private AI, и рассмотрим 10 ключевых причин, по которым он является правильным подходом для использования генеративного AI на предприятии. Эта сессия поможет вам лучше разобраться в вопросе, принимать верные решения для своей организации и раскрыть потенциал частного AI в её масштабах.
Unlock Innovation with VMware Private AI Foundation with NVIDIA [INVB1446LV]
Узнайте, как предприятия трансформируют свои стратегии в области AI с помощью совместной платформы GenAI от Broadcom и NVIDIA — VMware Private AI Foundation with NVIDIA. В этой сессии основное внимание уделяется сервисам Private AI, включая среду выполнения моделей, индексирование и поиск данных, сервисы создания агентов и многое другое.
Real-World Lessons in Rightsizing VMware Cloud Foundation for On-Premises AI Workloads [INVB1300LV]
Нагрузки AI — особенно основанные на больших языковых моделях (LLM) — меняют то, как мы проектируем, масштабируем и эксплуатируем инфраструктуру. Речь уже не только о вычислениях и хранилищах. Размер модели, задержка при инференсе, параллельность и распределение GPU — всё это оказывает существенное влияние.
В этой сессии Фрэнк Деннеман и Йохан ван Амерсфорт делятся практическими уроками, полученными при проектировании и развертывании платформ VMware Cloud Foundation, готовых к AI, в различных средах заказчиков. Вы узнаете практические стратегии правильного подбора размеров инфраструктуры, балансировки компромиссов между резервным копированием и конвейерами MLOps, а также проектирования инфраструктуры для локальных AI-нагрузок.
Используя практический инструмент для расчёта размеров AI-инфраструктуры, они продемонстрируют, как согласовать инфраструктуру с реальными требованиями и вести предметный диалог со стейкхолдерами и поставщиками AI-решений, чтобы принимать более разумные и экономически эффективные решения по платформе.
Наблюдаемость (Observability) — это призма, через которую команды платформ получают понимание происходящего во всём ландшафте приложений. Она охватывает всё: от производительности, оповещений и устранения неполадок до развертывания и операций второго дня, таких как планирование ресурсов.
В VMware Tanzu Platform 10.3 компания Broadcom представила набор обновлений наблюдаемости в Tanzu Hub, которые углубляют видимость, ускоряют адаптацию команд и помогают сократить время решения проблем. Независимо от того, отвечаете ли вы за надежность, инженерные аспекты платформы или опыт разработчиков, новые функции позволяют автоматически получать и видеть релевантные данные, чтобы действовать быстрее и с большим доверием к своей платформе. Эти усовершенствования обеспечивают централизованный, целостный опыт наблюдаемости в Tanzu Hub.
Ключевые новые улучшения наблюдаемости в Tanzu Hub
В этом выпуске представлены усовершенствованные топологии и наложения оповещений, значительно повышающие видимость взаимосвязей инфраструктуры и зависимостей между сущностями. Теперь оверлей оповещений предоставляет более богатый контекст, включая возможность прямой связи с инфраструктурными системами или событиями в слое VCF, что упрощает процесс устранения неполадок. Контекстные оповещения автоматически сопоставляются с соответствующей сущностью, а в Tanzu Platform 10.3 эта функциональность распространяется также на сервисы и приложения. Эти оповещения будут отображаться в различных представлениях, включая Home, Alerts, Foundations, Applications, Service Instance и Topology.
Этот выпуск также предлагает новый уровень наблюдаемости и включает значительные улучшения тщательно настроенных панелей мониторинга и оповещений, основанных на ключевых показателях (KPI), а также runbook-ов для сервисов Tanzu Data Tile. Это позволяет различным командам сосредоточиться на формализации операционной экспертизы, делая её более доступной и практичной как для инженеров платформ, так и для команд разработчиков любого уровня опыта.
Ключевым аспектом этих улучшений является бесшовная интеграция runbook-ов с потоками наблюдаемости. Это означает, что оповещения и процессы их устранения больше не существуют изолированно; теперь runbook-и являются частью более широкой системы и содержат встроенные действия по следующему шагу прямо внутри оповещений, направляя инженеров через процесс диагностики и решения проблемы шаг за шагом. Runbook-и можно полностью настраивать, отображая контекстные данные, такие как соответствующие журналы ошибок во время и до возникновения оповещения, что делает рабочий процесс более плавным и сокращает время решения проблем. Такой интегрированный подход дает командам, особенно недавно присоединившимся инженерам, возможность действовать быстрее и эффективнее, снижая среднее время устранения проблем и повышая общую операционную эффективность.
Объединение метрик уровня приложений и уровня инфраструктуры в интерфейсе обеспечивает по-настоящему целостное понимание производительности системы. Этот интегрированный подход позволяет легко сопоставлять поведение приложения с состоянием базовой инфраструктуры, предоставляя детализированный обзор связанных сервисов или инфраструктурных изменений, которые могут повлиять на стабильность критически важных приложений. Объединив ранее разрозненные представления и благодаря удобной навигации Tanzu Hub, организации могут гораздо быстрее выявлять первопричины проблем, выходя за рамки поверхностных симптомов и устраняя коренные причины более эффективно.
Эти усовершенствованные представления приносят значительные бизнес-преимущества и могут быть настроены под нужды разных команд, включая инженеров платформы и команды разработчиков. Возможность создавать и управлять пользовательскими панелями мониторинга, а также гибко контролировать данные с помощью фильтров на уровне панели, позволяет командам точно адаптировать свой опыт наблюдения под свои задачи. Кроме того, настройка макетов, диаграмм и виджетов гарантирует, что критически важные данные всегда представлены в наиболее удобной и действенной форме. Это объединение направлено на покрытие большинства сценариев использования Healthwatch, обеспечивая действия на основе разрешений и расширенные возможности анализа метрик. Бесшовная миграция всех панелей Healthwatch, помеченных тегом “healthwatch”, обеспечивает преемственность и простоту поиска. В конечном итоге эти возможности приводят к снижению простоев, повышению операционной эффективности и более проактивному подходу к поддержанию оптимальной производительности приложений, напрямую влияя на удовлетворенность клиентов и непрерывность бизнеса.
Почему эти улучшения важны
Эти усовершенствования приносят значительные бизнес-преимущества, делая работу вашей платформы более эффективной, надежной и устойчивой к будущим изменениям. Наблюдаемость становится более прикладной и контекстной, обеспечивая полноценный анализ на всех уровнях стека. Вы получаете комплексное понимание не только поведения приложений, но и их прямой связи с платформой и базовой инфраструктурой. Это обеспечивает видимость на нескольких уровнях, планирование емкости и контроль соответствия требованиям. Runbook-и и встроенные рекомендации существенно снижают зависимость от индивидуального опыта и «внутренних знаний» команды, повышая эффективность операций на уровне всей организации. И наконец, по мере роста сложности сред, эти улучшения наблюдаемости масштабируются вместе с вами, обеспечивая стабильную производительность и прозрачность.
NVIDIA Run:ai ускоряет операции AI с помощью динамической оркестрации ресурсов, максимизируя использование GPU, обеспечивая комплексную поддержку жизненного цикла AI и стратегическое управление ресурсами. Объединяя ресурсы между средами и применяя продвинутую оркестрацию, NVIDIA Run:ai значительно повышает эффективность GPU и пропускную способность рабочих нагрузок.
Недавно VMware объявила, что предприятия теперь могут развертывать NVIDIA Run:ai с встроенной службой VMware vSphere Kubernetes Services (VKS) — стандартной функцией в VMware Cloud Foundation (VCF). Это поможет предприятиям достичь оптимального использования GPU с NVIDIA Run:ai, упростить развертывание Kubernetes и поддерживать как контейнеризованные нагрузки, так и виртуальные машины на VCF. Таким образом, можно запускать AI- и традиционные рабочие нагрузки на единой платформе.
Давайте посмотрим, как клиенты Broadcom теперь могут развертывать NVIDIA Run:ai на VCF, используя VMware Private AI Foundation with NVIDIA, чтобы развертывать кластеры Kubernetes для AI, максимизировать использование GPU, упростить операции и разблокировать GenAI на своих приватных данных.
NVIDIA Run:ai на VCF
Хотя многие организации по умолчанию запускают Kubernetes на выделенных серверах, такой DIY-подход часто приводит к созданию изолированных инфраструктурных островков. Это заставляет ИТ-команды вручную создавать и управлять службами, которые VCF предоставляет из коробки, лишая их глубокой интеграции, автоматизированного управления жизненным циклом и устойчивых абстракций для вычислений, хранения и сетей, необходимых для промышленного AI. Именно здесь платформа VMware Cloud Foundation обеспечивает решающее преимущество.
vSphere Kubernetes Service — лучший способ развертывания Run:ai на VCF
Наиболее эффективный и интегрированный способ развертывания NVIDIA Run:ai на VCF — использование VKS, предоставляющего готовые к корпоративному использованию кластеры Kubernetes, сертифицированные Cloud Native Computing Foundation (CNCF), полностью управляемые и автоматизированные. Затем NVIDIA Run:ai развертывается на этих кластерах VKS, создавая единую, безопасную и устойчивую платформу от аппаратного уровня до уровня приложений AI.
Ценность заключается не только в запуске Kubernetes, но и в запуске его на платформе, решающей базовые корпоративные задачи:
Снижение совокупной стоимости владения (TCO) с помощью VCF: уменьшение инфраструктурных изолятов, использование существующих инструментов и навыков без переобучения, единое управление жизненным циклом всех инфраструктурных компонентов.
Единые операции: основаны на привычных инструментах, навыках и рабочих процессах с автоматическим развертыванием кластеров и GPU-операторов, обновлениями и управлением в большом масштабе.
Запуск и управление Kubernetes для большой инфраструктуры: встроенный, сертифицированный CNCF Kubernetes runtime с полностью автоматизированным управлением жизненным циклом.
Поддержка в течение 24 месяцев для каждой минорной версии vSphere Kubernetes (VKr) - это снижает нагрузку при обновлениях, стабилизирует окружения и освобождает команды для фокусировки на ценности, а не на постоянных апгрейдах.
Лучшая конфиденциальность, безопасность и соответствие требованиям: безопасный запуск чувствительных и регулируемых AI/ML-нагрузок со встроенными средствами управления, приватности и гибкой безопасностью на уровне кластеров.
Сетевые возможности контейнеров с VCF
Сети Kubernetes на «железе» часто плоские, сложные для настройки и требующие ручного управления. В крупных централизованных кластерах обеспечение надежного соединения между приложениями с разными требованиями — сложная задача. VCF решает это с помощью Antrea, корпоративного интерфейса контейнерной сети (CNI), основанного на CNCF-проекте Antrea. Он используется по умолчанию при активации VKS и обеспечивает внутреннюю сетевую связность, реализацию политик сети Kubernetes, централизованное управление политиками и операции трассировки (traceflow) с уровня управления NSX. При необходимости можно выбрать Calico как альтернативу.
Расширенная безопасность с vDefend
Разные приложения в общем кластере требуют различных политик безопасности и контроля доступа, которые сложно реализовать последовательно и масштабируемо. Дополнение VMware vDefend для VCF расширяет возможности безопасности, позволяя применять сетевые политики Antrea и микросегментацию уровня «восток–запад» вплоть до контейнера. Это позволяет ИТ-отделам программно изолировать рабочие нагрузки AI, конвейеры данных и пространства имен арендаторов с помощью политик нулевого доверия. Эти функции необходимы для соответствия требованиям и предотвращения горизонтального перемещения в случае взлома — уровень детализации, крайне сложный для реализации на физических коммутаторах.
Высокая отказоустойчивость и автоматизация с VMware vSphere
Это не просто удобство, а основа устойчивости инфраструктуры. Сбой физического сервера, выполняющего многодневное обучение, может привести к значительным потерям времени. VCF, основанный на vSphere HA, автоматически перезапускает такие рабочие нагрузки на другом узле.
Благодаря vMotion возможно обслуживание оборудования без остановки AI-нагрузок, а Dynamic Resource Scheduler (DRS) динамически балансирует ресурсы, предотвращая перегрузки. Подобная автоматическая устойчивость отсутствует в статичных, выделенных средах.
Гибкое управление хранилищем с политиками через vSAN
AI-нагрузки требуют разнообразных типов хранения — от высокопроизводительного временного пространства для обучения до надежного объектного хранения для наборов данных. vSAN позволяет задавать эти требования (например, производительность, отказоустойчивость) индивидуально для каждой рабочей нагрузки. Это предотвращает появление новых изолированных инфраструктур и необходимость управлять несколькими хранилищами, как это часто бывает в средах на «голом железе».
Преимущества NVIDIA Run:ai
Максимизация использования GPU: динамическое выделение, дробление GPU и приоритизация задач между командами обеспечивают максимально эффективное использование мощной инфраструктуры.
Масштабируемые сервисы AI: поддержка развертывания больших языковых моделей (инференс) и других сложных AI-задач (распределённое обучение, тонкая настройка) с эффективным масштабированием ресурсов под изменяющуюся нагрузку.
Обзор архитектуры
Давайте посмотрим на высокоуровневую архитектуру решения:
VCF: базовая инфраструктура с vSphere, сетями VCF (включая VMware NSX и VMware Antrea), VMware vSAN и системой управления VCF Operations.
Кластер Kubernetes с поддержкой AI: управляемый VCF кластер VKS, обеспечивающий среду выполнения AI-нагрузок с доступом к GPU.
Панель управления NVIDIA Run:ai: доступна как услуга (SaaS) или для локального развертывания внутри кластера Kubernetes для управления рабочими нагрузками AI, планирования заданий и мониторинга.
Кластер NVIDIA Run:ai: развернут внутри Kubernetes для оркестрации GPU и выполнения рабочих нагрузок.
Рабочие нагрузки data science: контейнеризированные приложения и модели, использующие GPU-ресурсы.
Эта архитектура представляет собой полностью интегрированный программно-определяемый стек. Вместо того чтобы тратить месяцы на интеграцию разрозненных серверов, коммутаторов и систем хранения, VCF предлагает единый, эластичный и автоматизированный облачный операционный подход, готовый к использованию.
Диаграмма архитектуры
Существует два варианта установки панели управления NVIDIA Run:ai:
SaaS: панель управления размещена в облаке (см. https://run-ai-docs.nvidia.com/saas). Локальный кластер Run:ai устанавливает исходящее соединение с облачной панелью для выполнения рабочих нагрузок AI. Этот вариант требует исходящего сетевого соединения между кластером и облачным контроллером Run:ai.
Самостоятельное размещение: панель управления Run:ai устанавливается локально (см. https://run-ai-docs.nvidia.com/self-hosted) на кластере VKS, который может быть совместно используемым или выделенным только для Run:ai. Также доступен вариант с изолированной установкой (без подключения к сети).
Вот визуальное представление инфраструктурного стека:
Сценарии развертывания
Сценарий 1: Установка NVIDIA Run:ai на экземпляре VCF с включенной службой vSphere Kubernetes Service
Предварительные требования:
Среда VCF с узлами ESX, оснащёнными GPU
Кластер VKS для AI, развернутый через VCF Automation
GPU настроены как DirectPath I/O, vGPU с разделением по времени (time-sliced) или NVIDIA Multi-Instance GPU (MIG)
Если используется vGPU, NVIDIA GPU Operator автоматически устанавливается в рамках шаблона (blueprint) развертывания VCFA.
Основные шаги по настройке панели управления NVIDIA Run:ai:
Подготовьте ваш кластер VKS, назначенный для роли панели управления NVIDIA Run:ai, выполнив все необходимые предварительные условия.
Создайте секрет с токеном, полученным от NVIDIA Run:ai, для доступа к контейнерному реестру NVIDIA Run:ai.
Если используется VMware Data Services Manager, настройте базу данных Postgres для панели управления Run:ai; если нет — Run:ai будет использовать встроенную базу Postgres.
Добавьте репозиторий Helm и установите панель управления с помощью Helm.
Основные шаги по настройке кластера:
Подготовьте кластер VKS, назначенный для роли кластера, с выполнением всех предварительных условий, и запустите диагностический инструмент NVIDIA Run:ai cluster preinstall.
Установите дополнительные компоненты, такие как NVIDIA Network Operator, Knative и другие фреймворки в зависимости от ваших сценариев использования.
Войдите в веб-консоль NVIDIA Run:ai, перейдите в раздел Resources и нажмите "+New Cluster".
Следуйте инструкциям по установке и выполните команды, предоставленные для вашего кластера Kubernetes.
Преимущества:
Полный контроль над инфраструктурой
Бесшовная интеграция с экосистемой VCF
Повышенная надежность благодаря автоматизации vSphere HA, обеспечивающей защиту длительных AI-тренировок и серверов инференса от сбоев аппаратного уровня — критического риска для сред на «голом железе».
Сценарий 2: Интеграция vSphere Kubernetes Service с существующими развертываниями NVIDIA Run:ai
Почему именно vSphere Kubernetes Service:
Управляемый VMware Kubernetes упрощает операции с кластерами
Тесная интеграция со стеком VCF, включая VCF Networking и VCF Storage
Возможность выделить отдельный кластер VKS для конкретного приложения или этапа — разработка, тестирование, продакшн
Шаги:
Подключите кластер(ы) VKS к существующей панели управления NVIDIA Run:ai, установив кластер Run:ai и необходимые компоненты.
Настройте квоты GPU и политики рабочих нагрузок в пользовательском интерфейсе NVIDIA Run:ai.
Используйте возможности Run:ai, такие как автомасштабирование и разделение GPU, с полной интеграцией со стеком VCF.
Преимущества:
Простота эксплуатации
Расширенная наблюдаемость и контроль
Упрощённое управление жизненным циклом
Операционные инсайты: преимущество "Day 2" с VCF
Наблюдаемость (Observability)
В средах на «железе» наблюдаемость часто достигается с помощью разрозненного набора инструментов (Prometheus, Grafana, node exporters и др.), которые оставляют «слепые зоны» в аппаратном и сетевом уровнях. VCF, интегрированный с VCF Operations (часть VCF Fleet Management), предоставляет единую панель мониторинга для наблюдения и корреляции производительности — от физического уровня до гипервизора vSphere и кластера Kubernetes.
Теперь в системе появились специализированные панели GPU для VCF Operations, предоставляющие критически важные данные о том, как GPU и vGPU используются приложениями. Этот глубокий AI-ориентированный анализ позволяет гораздо быстрее выявлять и устранять узкие места.
Резервное копирование и восстановление (Backup & Disaster Recovery)
Velero, интегрированный с vSphere Kubernetes Service через vSphere Supervisor, служит надежным инструментом резервного копирования и восстановления для кластеров VKS и pod’ов vSphere. Он использует Velero Plugin for vSphere для создания моментальных снапшотов томов и резервного копирования метаданных напрямую из хранилища Supervisor vSphere.
Это мощная стратегия резервирования, которая может быть интегрирована в планы аварийного восстановления всей AI-платформы (включая состояние панели управления Run:ai и данные), а не только бездисковых рабочих узлов.
Итог: Bare Metal против VCF для корпоративного AI
Аспект
Kubernetes на «голом железе» (подход DIY)
Платформа VMware Cloud Foundation (VCF)
Сеть (Networking)
Плоская архитектура, высокая сложность, ручная настройка сетей.
Программно-определяемая сеть с использованием VCF Networking.
Безопасность (Security)
Трудно обеспечить защиту; политики безопасности применяются вручную.
Точная микросегментация до уровня контейнера при использовании vDefend; программные политики нулевого доверия (Zero Trust).
Высокие риски: сбой сервера может вызвать значительные простои для критических задач, таких как обучение и инференс моделей.
Автоматическая отказоустойчивость с помощью vSphere HA (перезапуск нагрузок), vMotion (обслуживание без простоя) и DRS (балансировка нагрузки).
Хранилище (Storage)
Приводит к «изолированным островам» и множеству разнородных систем хранения.
Единое, управляемое политиками хранилище через VCF Storage; предотвращает изоляцию и упрощает управление.
Резервное копирование и восстановление (Backup & DR)
Часто реализуется в последнюю очередь; чрезвычайно сложный и трудоемкий процесс.
Встроенные снимки CSI и автоматизированное резервное копирование на уровне Supervisor с помощью Velero.
Наблюдаемость (Observability)
Набор разрозненных инструментов с «слепыми зонами» в аппаратной и сетевой частях.
Единая панель наблюдения (VCF Operations) с коррелированным сквозным мониторингом — от оборудования до приложений.
Управление жизненным циклом (Lifecycle Management)
Ручное, трудоёмкое управление жизненным циклом всех компонентов.
Автоматизированное, полноуровневое управление жизненным циклом через VCF Operations.
Общая модель (Overall Model)
Заставляет ИТ-команды вручную собирать и интегрировать множество разнородных инструментов.
Единая, эластичная и автоматизированная облачная операционная модель с встроенными корпоративными сервисами.
NVIDIA Run:ai на VCF ускоряет корпоративный ИИ
Развертывание NVIDIA Run:ai на платформе VCF позволяет предприятиям создавать масштабируемые, безопасные и эффективные AI-платформы. Независимо от того, начинается ли внедрение с нуля или совершенствуются уже существующие развертывания с использованием VKS, клиенты получают гибкость, высокую производительность и корпоративные функции, на которые они могут полагаться.
VCF позволяет компаниям сосредоточиться на ускорении разработки AI и повышении отдачи от инвестиций (ROI), а не на рискованной и трудоемкой задаче построения и управления инфраструктурой. Она предоставляет автоматизированную, устойчивую и безопасную основу, необходимую для промышленных AI-нагрузок, позволяя NVIDIA Run:ai выполнять свою главную задачу — максимизировать использование GPU.
В VMware Cloud Foundation (VCF) 9.0 легко упустить из виду относительно новые функции, находящиеся прямо перед глазами. Защита данных в частном облаке в последнее время стала особенно актуальной темой, выходящей далеко за рамки обычных задач восстановления данных. Клиенты ищут практичные стратегии защиты от атак вымогателей и аварийного восстановления с помощью решений, которыми легко управлять в масштабах всей инфраструктуры.
vSAN Data Protection впервые появилась в vSAN 8 U3 как часть VMware Cloud Foundation 5.2. Наиболее часто упускаемый момент — это то, что vSAN Data Protection входит в лицензию VCF!
Почему это важно? Если вы используете vSAN ESA в своей среде VCF, у вас уже есть всё необходимое для локальной защиты рабочих нагрузок с помощью vSAN Data Protection. Это отличный способ дополнить существующие стратегии защиты или создать основу для более комплексной.
Рассмотрим кратко, что может предложить эта локальная защита и как просто и масштабируемо её внедрить.
Простая локальная защита
Как часть лицензии VCF, vSAN Data Protection позволяет использовать снапшоты именно так, как вы всегда хотели. Благодаря встроенному механизму создания снапшотов vSAN ESA, вы можете:
Легко определять группы ВМ и их расписание защиты и хранения — до 200 снапшотов на ВМ.
Создавать согласованные по сбоям снапшоты ВМ с минимальным влиянием на производительность.
Быстро восстанавливать одну или несколько ВМ прямо в vCenter Server через vSphere Client, даже если они были удалены из инвентаря.
Поскольку vSAN Data Protection работает на уровне ВМ, защита и восстановление отдельных VMDK-дисков внутри виртуальной машины пока не поддерживается.
Простое и гибкое восстановление
Причины восстановления данных могут быть разными, и vSAN Data Protection даёт администраторам платформ виртуализации возможность выполнять типовые задачи восстановления без привлечения других команд.
Например, обновление ОС виртуальной машины не удалось или произошла ошибка конфигурации — vSAN Data Protection готова обеспечить быстрое и простое восстановление. Или, допустим, виртуальная машина была случайно удалена из инвентаря. Ранее ни один тип снимков VMware не позволял восстановить снимок удалённой ВМ, но vSAN Data Protection справится и с этим.
Обратите внимание, что восстановление виртуальных машин в демонстрации выше выполняется напрямую в vSphere Client, подключённом к vCenter Server. Не нужно использовать дополнительные приложения, и поскольку процесс основан на уровне ВМ, восстановление интуитивно понятное и безопасное — без сложностей, связанных с восстановлением на основе снимков хранилища (array-based snapshots).
Для клиентов, уже внедривших vSAN Data Protection, такая простота восстановления стала одной из наиболее ценных возможностей решения.
Быстрое и гибкое клонирование
Преимущества автоматизированных снапшотов, создаваемых с помощью vSAN Data Protection, выходят далеко за рамки восстановления данных. С помощью vSAN Data Protection можно легко создавать клоны виртуальных машин из существующих снапшотов. Это чрезвычайно простой и эффективный по использованию пространства способ получить несколько ВМ для различных задач.
Клонирование из снапшотов можно использовать для разработки и тестирования программного обеспечения, а также для администрирования и тестирования приложений. Администраторы платформ виртуализации могут без труда интегрировать эту функцию в повседневные IT-операции и процессы управления жизненным циклом.
Давайте посмотрим, как выглядит такое быстрое клонирование большой базы данных в пользовательском интерфейсе.
Обратите внимание, что клонированная виртуальная машина, созданная из снапшота в vSAN Data Protection, представляет собой связанную копию (linked clone). Такой клон не может быть впоследствии защищён с помощью групп защиты и снапшотов в рамках vSAN Data Protection. Клон можно добавить в группу защиты, однако при следующем цикле защиты для этой группы появится предупреждение «Protection Group Health», указывающее, что создание снапшота для клонированной ВМ не удалось.
Ручные снапшоты таких связанных клонов можно создавать вне vSAN Data Protection (через интерфейс или с помощью VADP), что позволяет решениям резервного копирования, основанным на VADP, защищать эти клоны.
С чего начать
Так как функции защиты данных уже включены в вашу лицензию VCF, как приступить к работе? Рассмотрим краткий план.
Установка виртуального модуля для vSAN Data Protection
Для реализации описанных возможностей требуется установка виртуального модуля (Virtual Appliance) — обычно одного на каждый vCenter Server. Этот виртуальный модуль VMware Live Recovery (VLR) обеспечивает работу службы vSAN Data Protection, входящей в состав VCF, и предоставляет локальную защиту данных. Оно управляет процессом создания и координации снимков, но не участвует в передаче данных и не является единой точкой отказа.
Базовые шаги для развертывания и настройки модуля:
Загрузите виртуальный модуль для защиты данных с портала Broadcom.
Войдите в vSphere Client, подключённый к нужному vCenter Server, и разверните модуль как обычный OVF-шаблон.
Защита виртуальных машин осуществляется с помощью групп защиты (protection groups), которые определяют желаемую стратегию защиты ВМ. Вы можете управлять тем, какие ВМ будут защищены, как часто выполняется защита, а также настройками хранения снапшотов.
Группы защиты также позволяют указать, должны ли снапшоты быть неизменяемыми (immutable) — всё это настраивается с помощью простого флажка в интерфейсе.
Неизменяемость гарантирует, что снапшоты не могут быть каким-либо образом изменены или удалены. Эта опция обеспечивает базовую защиту от вредоносных действий и служит основой для более продвинутых механизмов киберустойчивости (cyber resilience).
Давайте посмотрим, насколько просто это реализуется в интерфейсе. Сначала рассмотрим настройку группы защиты в vSphere Client.
Группы защиты начинают выполнять заданные параметры сразу после создания первого снапшота. Это отличный пример принципа «настроил и забыл» (set it and forget it), реализованного в vSAN Data Protection, который обеспечивает простое и интуитивное восстановление одной или нескольких виртуальных машин при необходимости.
Рекомендация: если вы используете динамические шаблоны имен ВМ в группах защиты, убедитесь, что виртуальные машины, созданные из снапшотов в vSAN Data Protection, не попадают под этот шаблон. В противном случае будет сгенерировано предупреждение о состоянии группы защиты (Health Alert), указывающее, что связанный клон не может быть защищён в рамках этой группы.
Расширенные возможности в VCF 9.0
В версии VCF 9.0 vSAN Data Protection получила ряд улучшений, которые сделали её ещё более удобной и функциональной.
Единый виртуальный модуль
Независимо от того, используете ли вы только локальную защиту данных через vSAN Data Protection или расширенные возможности репликации и аварийного восстановления (DR), теперь для этого используется единый виртуальный модуль, доступный для загрузки по ссылке.
Он сокращает потребление ресурсов, упрощает управление и позволяет расширять функциональность для DR и защиты от программ-вымогателей путём простого добавления лицензионного ключа.
Защита ВМ на других кластерах vSAN
Хотя vSAN Data Protection обеспечивает простой способ локальной защиты рабочих нагрузок, новая технология, представленная в VCF 9.0, позволяет реплицировать данные на другой кластер vSAN — механизм, известный как vSAN-to-vSAN replication.
Для использования vSAN-to-vSAN репликации требуется дополнительная лицензия (add-on license). Если она отсутствует, вы по-прежнему можете использовать локальную защиту данных с помощью vSAN Data Protection. Однако эта лицензия предоставляет не только возможность удалённой репликации — она также добавляет инструменты для комплексной защиты данных и оркестрации, помогая выполнять требования по аварийному восстановлению (DR) и кибербезопасности.
Иными словами, все базовые возможности локальной защиты вы можете реализовать с помощью vSAN Data Protection. А когда придёт время расширить защиту для сценариев аварийного восстановления (DR) и восстановления после киберинцидентов (cyber recovery), это можно сделать просто — активировав дополнительные возможности с помощью add-on лицензии.
Для ответов на часто задаваемые вопросы о vSAN Data Protection см. раздел «vSAN Data Protection» в актуальной версии vSAN FAQs.
Итоги
Клиенты VCF, использующие vSAN ESA в составе VCF 5.2 или 9.0, уже обладают невероятно мощным инструментом, встроенным в их решение. vSAN Data Protection обеспечивает возможность локальной защиты рабочих нагрузок без необходимости приобретения дополнительных лицензий.
На VMware Explore 2025 в Лас-Вегасе было сделано множество анонсов, а также проведены подробные обзоры новых функций и усовершенствований, включённых в VMware Cloud Foundation (VCF) 9, включая популярную функцию NVMe Memory Tiering. Хотя эта функция доступна на уровне вычислительного компонента VCF (платформа vSphere), мы рассматриваем её в контексте всей платформы VCF, учитывая её глубокую интеграцию с другими компонентами, такими как VCF Operations, к которым мы обратимся в дальнейшем.
Memory Tiering — это новая функция, включённая в VMware Cloud Foundation, и она стала одной из основных тем обсуждения в рамках многих сессий на VMware Explore 2025. VMware заметила большой интерес и получила множество отличных вопросов от клиентов по поводу внедрения, сценариев использования и других аспектов. Эта серия статей состоит из нескольких частей, где мы постараемся ответить на наиболее частые вопросы от клиентов, партнёров и внутренних команд.
Предварительные требования и совместимость оборудования
Оценка рабочих нагрузок
Перед включением Memory Tiering крайне важно провести тщательную оценку вашей среды. Начните с анализа рабочих нагрузок в вашем датацентре, уделяя особое внимание использованию памяти. Один из ключевых показателей, на который стоит обратить внимание — активная память рабочей нагрузки.
Чтобы рабочие нагрузки подходили для Memory Tiering, общий объём активной памяти должен составлять не более 50% от ёмкости DRAM. Почему именно 50%?
По умолчанию Memory Tiering предоставляет на 100% больше памяти, то есть удваивает доступный объём. После включения функции половина памяти будет использовать DRAM (Tier 0), а другая половина — NVMe (Tier 1). Таким образом, мы стремимся, чтобы активная память умещалась в DRAM, так как именно он является самым быстрым источником памяти и обеспечивает минимальное время отклика при обращении виртуальных машин к страницам памяти. По сути, это предварительное условие, гарантирующее, что производительность при работе с активной памятью останется стабильной.
Важный момент: при оценке анализируется активность памяти приложений, а не хоста, поскольку в Memory Tiering страницы памяти ВМ переносятся (demote) на NVMe-устройство, когда становятся «холодными» или неактивными, но страницы vmkernel хоста не затрагиваются.
Как узнать объём активной памяти?
Как мы уже отметили, при использовании Memory Tiering только страницы памяти ВМ переносятся на NVMe при бездействии, тогда как системные страницы хоста остаются нетронутыми. Поэтому нам важно определить процент активности памяти рабочих нагрузок.
Это можно сделать через интерфейс vCenter в vSphere Client, перейдя в:
VM > Monitor > Performance > Advanced
Затем измените тип отображения на Memory, и вы увидите метрику Active Memory. Если она не отображается, нажмите Chart Options и выберите Active для отображения.
Обратите внимание, что метрика Active доступна только при выборе периода Real-Time, так как это показатель уровня 1 (Level 1 stat). Активная память измеряется в килобайтах (KB).
Если вы хотите собирать данные об активной памяти за более длительный период, можно сделать следующее: в vCenter Server перейдите в раздел Configure > Edit > Statistics.
Затем измените уровень статистики (Statistics Level) с Level 1 на Level 2 для нужных интервалов.
Делайте это на свой страх и риск, так как объём пространства, занимаемого базой данных, существенно увеличится. В среднем, он может вырасти раза в 3 или даже больше. Поэтому не забудьте вернуть данную настройку обратно по завершении исследования.
Также вы можете использовать другие инструменты, такие как VCF Operations или RVTools, чтобы получить информацию об активной памяти ваших рабочих нагрузок.
RVTools также собирает данные об активности памяти в режиме реального времени, поэтому убедитесь, что вы учитываете возможные пиковые значения и включаете периоды максимальной нагрузки ваших рабочих процессов.
Примечания и ограничения
Для VCF 9.0 технология Memory Tiering пока не подходит для виртуальных машин, чувствительных к задержкам (latency-sensitive VMs), включая:
Высокопроизводительные ВМ (High-performance VMs)
Защищённые ВМ, использующие SEV / SGX / TDX
ВМ с включенным механизмом непрерывной доступности Fault Tolerance
Так называемые "Monster VMs" с объёмом памяти более 1 ТБ.
В смешанных средах рекомендуется выделять отдельные хосты под Memory Tiering или отключать эту функцию на уровне отдельных ВМ. Эти ограничения могут быть сняты в будущем, поэтому стоит следить за обновлениями и расширением совместимости с различными типами нагрузок.
Программные предварительные требования
С точки зрения программного обеспечения, Memory Tiering требует новой версии vSphere, входящей в состав VCF/VVF 9.0. И vCenter, и ESX-хосты должны быть версии 9.0 или выше. Это обеспечивает готовность среды к промышленной эксплуатации, включая улучшения в области надёжности, безопасности (включая шифрование на уровне ВМ и хоста) и осведомлённости о vMotion.
Настройку Memory Tiering можно выполнить:
На уровне хоста или кластера
Через интерфейс vCenter UI
С помощью ESXCLI или PowerCLI
А также с использованием Desired State Configuration для автоматизации и последовательных перезагрузок (rolling reboots).
В VVF и VCF 9.0 необходимо создать раздел (partition) на NVMe-устройстве, который будет использоваться Memory Tiering. На данный момент эта операция выполняется через ESXCLI или PowerCLI (да, это можно автоматизировать с помощью скрипта). Для этого потребуется доступ к терминалу и включённый SSH. Позже мы подробно рассмотрим оба варианта и даже приведём готовый скрипт для автоматического создания разделов на нескольких серверах.
Совместимость NVMe
Аппаратная часть — это основа производительности Memory Tiering. Так как NVMe-накопители используются как один из уровней оперативной памяти, совместимость оборудования критически важна.
VMware рекомендует использовать накопители со следующими характеристиками:
Выносливость (Endurance): класс D или выше (больше или равно 7300 TBW) — для высокой долговечности при множественных циклах записи.
Производительность (Performance): класс F (100 000–349 999 операций записи/сек) или G (350 000+ операций записи/сек) — для эффективной работы механизма tiering.
Некоторые OEM-производители не указывают класс напрямую в спецификациях, а обозначают накопители как read-intensive (чтение) или mixed-use (смешанные нагрузки).
В таких случаях рекомендуется использовать Enterprise Mixed Drives с показателем не менее 3 DWPD (Drive Writes Per Day).
Если вы не знакомы с этим термином: DWPD отражает выносливость SSD и показывает, сколько раз в день накопитель может быть полностью перезаписан на протяжении гарантийного срока (обычно 3–5 лет) без отказов. Например, SSD объёмом 1 ТБ с 1 DWPD способен выдерживать 1 ТБ записей в день на протяжении гарантийного периода.
Чем выше DWPD, тем долговечнее накопитель — что критически важно для таких сценариев, как VMware Memory Tiering, где выполняется большое количество операций записи.
Также рекомендуется воспользоваться Broadcom Compatibility Guide, чтобы проверить, какие накопители соответствуют рекомендованным классам и как они обозначены у конкретных OEM-производителей. Этот шаг настоятельно рекомендуется, так как Memory Tiering может производить большие объёмы чтения и записи на NVMe, и накопители должны быть высокопроизводительными и надёжными.
Хотя Memory Tiering позволяет снизить совокупную стоимость владения (TCO), экономить на накопителях для этой функции категорически не рекомендуется.
Что касается форм-факторов, поддерживается широкий выбор вариантов. Вы можете использовать:
Устройства формата 2.5", если в сервере есть свободные слоты.
Вставляемые модули E3.S.
Или даже устройства формата M.2, если все 2.5" слоты уже заняты.
Наилучший подход — воспользоваться Broadcom Compatibility Guide. После выбора нужных параметров выносливости (Endurance, класс D) и производительности (Performance, класс F или G), вы сможете дополнительно указать форм-фактор и даже параметр DWPD.
Такой способ подбора поможет вам выбрать оптимальный накопитель для вашей среды и быть уверенными, что используемое оборудование полностью соответствует требованиям Memory Tiering.
Службы VMware vSphere Kubernetes Service (VKS) версии 3.5 появились в общем доступе. Этот новый выпуск обеспечивает 24-месячную поддержку для каждой минорной версии Kubernetes, начиная с vSphere Kubernetes release (VKr) 1.34. Ранее, в июне 2025 года, VMware объявила о 24-месячной поддержке выпуска vSphere Kubernetes (VKr) 1.33. Это изменение обеспечивает командам, управляющим платформой, большую стабильность и гибкость при планировании обновлений.
VKS 3.5 также включает ряд улучшений, направленных на повышение операционной согласованности и улучшение управления жизненным циклом, включая детализированные средства конфигурации основных компонентов Kubernetes, декларативную модель управления надстройками и встроенную генерацию пакетов поддержки напрямую из интерфейса командной строки VCF CLI. Кроме того, новые защитные механизмы при обновлениях — такие как проверка PodDisruptionBudget и проверки совместимости — помогают обеспечить более безопасные и предсказуемые обновления кластеров.
В совокупности эти усовершенствования повышают надежность, операционную эффективность и качество управления Kubernetes-средами на этапе эксплуатации (Day-2) в масштабах предприятия.
Выпуск vSphere Kubernetes (VKr) 1.34
VKS 3.5 добавляет поддержку VKr 1.34. Каждая минорная версия vSphere Kubernetes теперь поддерживается в течение 24 месяцев с момента выпуска. Это снижает давление, связанное с обновлениями, стабилизирует рабочие среды и позволяет командам сосредоточиться на создании ценности, а не на постоянном планировании апгрейдов. Команды, которым нужен быстрый доступ к последним возможностям Kubernetes, могут оперативно переходить на новые версии. Те, кто предпочитает стабильную среду на длительный срок, теперь могут работать в этом режиме с уверенностью. VKS 3.5 поддерживает оба подхода к эксплуатации.
Динамическое распределение ресурсов (Dynamic Resource Allocation, DRA)
Функция DRA получила статус «стабильной» в основной ветке Kubernetes 1.34. Эта возможность позволяет администраторам централизованно классифицировать аппаратные ресурсы, такие как GPU, с помощью объекта DeviceClass. Это обеспечивает надежное и предсказуемое размещение Pod'ов на узлах с требуемым классом оборудования.
DRA повышает эффективность использования устройств, позволяя делить ресурсы между приложениями по декларативному принципу, аналогично динамическому выделению томов (Dynamic Volume Provisioning). Механизм DRA решает проблемы случайного распределения и неполного использования ресурсов. Пользователи могут выполнять точную фильтрацию, запрашивая конкретные устройства с помощью ResourceClaimsTemplates и ResourceClaims при развертывании рабочих нагрузок.
DRA также позволяет совместно использовать GPU между несколькими Pod'ами или контейнерами. Рабочие нагрузки можно настроить так, чтобы выбирать GPU-устройство с помощью Common Expression Language (CEL) и запросов ResourceSlice, что обеспечивает более эффективное использование по сравнению с count-based запросами.
Расширенные возможности конфигурации компонентов кластера Kubernetes
VKS 3.5 предоставляет гибкость для управления более чем 35 параметрами конфигурации компонентов Kubernetes, таких как kubelet, apiserver и etcd. Эти настройки позволяют командам платформ оптимизировать различные аспекты работы кластеров в соответствии с требованиями их рабочих нагрузок. Полный список доступных параметров конфигурации приведён в документации к продукту. Ниже приведён краткий обзор областей конфигурации, которые предлагает VKS 3.5:
Конфигурация
Настраиваемые компоненты
Описание
Журналирование и наблюдаемость (Logging & Observability)
Kubelet, API Server
Настройка поведения журналирования для API-сервера и kubelet, включая частоту сброса логов, формат (text/json) и уровни детализации. Управление хранением логов контейнеров с указанием максимального количества и размера файлов. Это позволяет эффективно управлять использованием диска, устранять неполадки с нужным уровнем детализации логов и интегрироваться с системами агрегирования логов с помощью структурированного JSON-журналирования.
Управление событиями (Event Management)
Kubelet
Управление генерацией событий Kubernetes с настройкой лимитов скорости создания событий (eventRecordQPS) и всплесков (eventBurst), чтобы предотвратить перегрузку API-сервера. Это позволяет контролировать частоту запросов kubelet к API-серверу, обеспечивая стабильность кластера в периоды высокой активности при сохранении видимости важных событий.
Производительность и масштабируемость (Performance & Scalability)
API Server
Управление производительностью API-сервера с помощью настройки пределов на максимальное количество одновременных изменяющих (mutating) и неизменяющих (non-mutating) запросов, а также минимальной продолжительности тайм-аута запроса. Возможность включения или отключения профилирования. Это позволяет адаптировать кластер под высоконагруженные рабочие процессы, предотвращать перегрузку API-сервера и оптимизировать отзывчивость под конкретные сценарии использования.
Конфигурации etcd
etcd
Настройка максимального размера базы данных etcd (в диапазоне 2–8 ГБ). Том создаётся с дополнительными 25 % ёмкости для учёта операций уплотнения, дефрагментации и временных всплесков использования. Это позволяет правильно подобрать объём хранилища etcd в зависимости от масштаба кластера и количества объектов, предотвращая ситуации нехватки места, которые могут перевести кластер в режим только для чтения.
Управление образами (Image Management)
Kubelet
Настройка жизненного цикла образов контейнеров, включая пороги очистки (в процентах использования диска — высокий/низкий), минимальный и максимальный возраст образов до удаления, лимиты скорости загрузки образов (registryPullQPS и registryBurst), максимальное количество параллельных загрузок и политики проверки учётных данных при загрузке. Это помогает оптимизировать использование дискового пространства узлов, контролировать потребление сетевых ресурсов, ускорять запуск Pod’ов за счёт параллельных загрузок и обеспечивать безопасность доступа к образам.
Безопасность на уровне ОС (OS-level Security)
OS
Включение защиты загрузчика GRUB паролем с использованием хэширования PBKDF2 SHA-512. Настройка обязательной повторной аутентификации при использовании sudo. Это позволяет соответствовать требованиям безопасности при загрузке системы и управлении привилегированным доступом, предотвращая несанкционированные изменения системы и обеспечивая соблюдение политик безопасности во всей инфраструктуре кластера.
Cluster API v1beta2 для улучшенного управления кластерами Kubernetes
VKS 3.5 включает Cluster API v1beta2 (CAPI v1.11.1), который вносит ряд изменений и улучшений в версии API для ресурсов по сравнению с v1beta1. Полный список улучшений можно найти в Release Notes для CAPI.
Для обеспечения плавного перехода все новые и существующие кластеры, созданные с использованием прежнего API v1beta1, будут автоматически преобразованы в API v1beta2 обновлёнными контроллерами Cluster API. В дальнейшем рекомендуется использовать API v1beta2 для управления жизненным циклом (LCM) кластеров Kubernetes.
Версия API v1beta2 является важным шагом на пути к выпуску стабильной версии v1. Основные улучшения включают:
Расширенные возможности отслеживания состояния ресурсов, обеспечивающие лучшую наблюдаемость.
Исправления на основе отзывов клиентов и инженеров с реальных внедрений.
Предотвращение сбоев обновлений из-за неверно настроенного PodDisruptionBudget
Pod Disruption Budget (PDB) — это объект Kubernetes, который помогает поддерживать доступность приложения во время плановых операций (например, обслуживания узлов, обновлений или масштабирования). Он гарантирует, что минимальное количество Pod’ов останется активным во время таких событий. Однако неправильно настроенные PDB могут блокировать обновления кластера.
VKS 3.5 вводит механизмы защиты (guardrails) для выявления ошибок конфигурации PDB, которые могут привести к зависанию обновлений или других операций жизненного цикла. Система блокирует обновление кластера, если обнаруживает, что PDB не допускает никаких прерываний.
Для повышения надёжности и успешности обновлений введено новое условие SystemChecksSucceeded в объект Cluster. Оно позволяет пользователям видеть готовность кластера к обновлению, в частности относительно конфигураций PDB.
Ключевые преимущества новой проверки:
Проактивная блокировка обновлений — система обнаруживает PDB, препятствующие выселению Pod’ов, и останавливает обновление до его начала.
Более чёткая диагностика проблем — параметр SystemChecksSucceeded устанавливается в false, если у любого PDB значение allowedDisruptions меньше или равно 0, что указывает на риск простоев.
Планирование обновлений — позволяет заранее устранить ошибки конфигурации PDB до начала обновления.
Примечание: любой PDB, не связанный с Pod’ами (например, из-за неправильного селектора), также будет иметь allowedDisruptions = 0 и, следовательно, заблокирует обновление.
Упрощённые операции: CLI, управление надстройками и инструменты поддержки
Управление надстройками (Add-On Management)
VKS 3.5 упрощает эксплуатационные операции, включая управление жизненным циклом надстроек (add-ons) и создание пакетов поддержки. Новая функция VKS Add-On Management объединяет установку, обновление и настройку стандартных пакетов, предлагая:
Единый метод для всех операций с пакетами, декларативный API и предварительные проверки совместимости.
Возможность управления стандартными пакетами VKS через Supervisor Namespace (установка, обновления, конфигурации) — доступно через VKS-M 9.0.1 или новый плагин ‘addon’ в VCF CLI.
Упрощённую установку Cluster Autoscaler с возможностью автоматического обновления при апгрейде кластера.
Управление установками и обновлениями через декларативные API (AddonInstall, AddonConfig) с помощью Argo CD или других GitOps-контроллеров. Это обеспечивает версионируемое и повторяемое развертывание надстроек с улучшенной трассируемостью и согласованностью.
Возможность настройки Addon Repository во всех кластерах VKS с помощью API AddonRepository / AddonRepositoryInstall, включая случаи с приватными регистрами.
По умолчанию встроенный репозиторий VKS Standard Package устанавливается из пакета VKS (версия v2025.10.22 для релиза VKS 3.5.0).
Во время обновлений кластеров VKS выполняет предварительные проверки совместимости надстроек и обновляет их до последних поддерживаемых версий. Если проверка не пройдена — обновление блокируется. При установке или обновлении надстроек выполняются дополнительные проверки, включая проверку на дублирование пакетов и анализ зависимостей.
Упрощённое обнаружение новых версий и метаданных совместимости для Add-on Releases.
Интегрированный сборщик пакетов поддержки (Support Bundler) в VCF CLI
VKS 3.5 включает VKS Cluster Support Bundler непосредственно в VCF CLI, что значительно упрощает процесс сбора диагностической информации о кластерах. Теперь пользователи могут собирать всю необходимую информацию с помощью команды vcf cluster support-bundle, без необходимости загружать отдельный инструмент.
Основные улучшения здесь:
Существенное уменьшение размера выходного файла.
Селективный сбор логов — только с узлов control plane, для более быстрой и точной диагностики.
Интегрированный сбор сетевых логов, что помогает анализировать сетевые проблемы и получить целостную картину состояния кластера.
Поддержание доступности данных и приложений, которые эти данные создают или используют, может быть одной из самых важных задач администраторов центров обработки данных. Такие возможности, как высокая производительность или специализированные службы данных, мало что значат, если приложения и данные, которые они создают или используют, недоступны. Обеспечение доступности — это сложная тема, поскольку доступность приложений и доступность данных достигаются разными методами. Иногда требования к доступности реализуются с помощью механизмов на уровне инфраструктуры, а иногда — с использованием решений, ориентированных на приложения. Оптимальный вариант для вашей среды во многом зависит от требований и возможностей инфраструктуры.
Хотя VMware Cloud Foundation (VCF) может обеспечивать высокий уровень доступности данных и приложений простым способом, в этой статье рассматриваются различия между обеспечением высокой доступности приложений и данных с использованием технологий на уровне приложений и встроенных механизмов на уровне инфраструктуры в VCF. Мы также рассмотрим, как VMware Data Services Manager (DSM) может помочь упростить принятие подобных решений.
Учёт отказов
Защита приложений и данных требует понимания того, как выглядят типичные сбои, и что система может сделать для их компенсации. Например, сбои в физической инфраструктуре могут затрагивать:
Централизованные решения для хранения, такие как дисковые массивы
Отдельные устройства хранения в распределённых системах
Такие сбои могут затронуть данные, приложения, или и то, и другое. Сбои могут проявляться по-разному — некоторые явно, другие лишь по отсутствию отклика. Часть из них временные, другие — постоянные. Решения должны быть достаточно интеллектуальными, чтобы автоматически справляться с такими ситуациями отказа и восстановления.
Доступность и восстановление приложений и данных
Доступность приложений и их наборов данных кажется интуитивно понятной, но требует краткого пояснения.
Доступность приложения
Это состояние приложения, например базы данных или веб-приложения. Независимо от того, установлено ли оно в виртуальной машине или запущено в контейнере, приложение заранее настроено на работу с данными определённым образом. Некоторые приложения могут работать в нескольких экземплярах для повышения доступности при сбоях и использовать собственные механизмы синхронной репликации, чтобы данные сохранялись в нескольких местах. Технологии, такие как vSphere HA, могут повысить доступность приложения и его данных, перезапуская виртуальную машину на другом хосте кластера vSphere в случае сбоя.
Доступность данных
Это способность данных быть доступными для приложения или пользователей в любое время, даже при сбое. Высокодоступные данные хранятся с использованием устойчивых механизмов, обеспечивающих хранение в нескольких местах — в зависимости от возможных границ сбоя: устройства, хоста, массива хранения или целого сайта.
Надёжность данных
Хранить данные в нескольких местах недостаточно — они должны записываться синхронно и последовательно во все копии, чтобы при сбое данные из одного места совпадали с данными из другого. Корпоративные системы хранения данных реализуют принципы ACID (атомарность, согласованность, изолированность, долговечность) и протоколы, обеспечивающие надёжность данных.
Описанные выше концепции вводят два термина, которые помогают количественно определить возможности восстановления в случае сбоя:
RPO (Recovery Point Objective) — целевая точка восстановления. Показывает, с каким интервалом данные защищаются устойчивым образом. RPO=0 означает, что система всегда выполняет запись в синхронном, согласованном состоянии. Как будет отмечено далее, не все решения способны обеспечивать настоящий RPO=0.
RTO (Recovery Time Objective) — целевое время восстановления. Показывает минимальное время, необходимое для восстановления систем и/или данных до рабочего состояния. Например, RTO=10m означает, что восстановление займёт не менее 10 минут. RTO может относиться к восстановлению доступности данных или комбинации данных и приложения.
Эволюция решений для высокой доступности
Подходы к обеспечению доступности данных и приложений эволюционировали с развитием технологий и ростом требований. Некоторые приложения, такие как Microsoft SQL Server, MySQL, PostgreSQL и другие, включают собственные механизмы репликации, обеспечивающие избыточность данных и состояния приложения. Виртуализация, совместно с общим хранилищем, предоставляет простые способы обеспечения высокой доступности приложений и хранимых ими данных.
В зависимости от ваших требований может подойти один из подходов или их комбинация. Рассмотрим, как каждый из них обеспечивает высокий уровень доступности.
Высокая доступность на уровне приложений (Application-Level HA)
Этот подход основан на запуске нескольких экземпляров приложения в разных местах. Синхронное и устойчивое хранилище, а также механизмы отказоустойчивости обеспечиваются самим приложением для гарантии высокой доступности приложения и его данных.
Высокая доступность на уровне инфраструктуры (Infrastructure-Level HA)
Этот подход использует vSphere HA для перезапуска одного экземпляра приложения на другом хосте кластера. Синхронное и устойчивое хранение данных обеспечивает VMware vSAN (в контексте данного сравнения). Такая комбинация гарантирует высокую доступность приложения и его данных.
Оба подхода достигают схожих целей, но имеют определённые компромиссы. Рассмотрим два простых примера, чтобы лучше понять различия.
В приведённых примерах предполагается, что данные должны сохраняться в нескольких местах (например, на уровне сайта или зоны), чтобы обеспечить доступность при сбое площадки. Также предполагается, что приложение может работать в тех же местах. Оба варианта обеспечивают автоматический отказоустойчивый переход и RPO=0, поскольку данные записываются синхронно в несколько мест.
Высокая доступность на уровне приложений для приложений и данных
Высокая доступность на уровне приложений, как в случае MS SQL Always On Availability Groups (AG), использует два или более работающих экземпляра базы данных и дополнительное местоположение для определения кворума при различных сценариях отказа.
Этот подход полностью опирается на технологии, встроенные в само приложение, чтобы синхронно реплицировать данные в другое место и обеспечить механизм отказоустойчивого переключения состояния приложения.
Высокая доступность на уровне инфраструктуры для приложений и данных
Высокая доступность на уровне инфраструктуры использует приложение базы данных, работающее на одной виртуальной машине. vSphere HA обеспечивает автоматическое восстановление приложения, обращающегося к данным, в то время как vSAN гарантирует надёжность и доступность данных при различных типах сбоев инфраструктуры.
vSAN может выдерживать отказы отдельных устройств хранения, сетевых карт (NIC), сетевых коммутаторов, хостов и даже целых географических площадок или зон, которые определяются как «домен отказа» (fault domain).
В приведённом ниже примере кластер vSAN растянут между двумя площадками, чтобы обеспечить устойчивое хранение данных на обеих. Растянутые кластеры vSAN (vSAN Stretched Clusters) также используют третью площадку, на которой размещается небольшой виртуальный модуль — witness host appliance (хост-свидетель), помогающий определить кворум при различных возможных сценариях отказа.
Одним из самых убедительных преимуществ высокой доступности на уровне инфраструктуры является то, что в VCF она является встроенной частью платформы. vSAN интегрирован прямо в гипервизор и обеспечивает отказоустойчивость данных в соответствии с вашими требованиями, всего лишь посредством настройки простой политики хранения (storage policy). Экземпляры приложений становятся высокодоступными благодаря проверенной технологии vSphere HA, которая позволяет перезапускать виртуальные машины на любом хосте в пределах кластера vSphere. Такой подход также отлично работает, когда приложения баз данных развертываются и управляются в вашей среде VCF с помощью DSM.
Разные подходы к обеспечению согласованности данных
Хотя оба подхода могут обеспечивать цель восстановления точки (RPO), равную нулю (RPO=0), за счёт синхронной репликации, способы достижения этого различаются. Оба используют специальные протоколы, помогающие обеспечить согласованность данных, записываемых в нескольких местах — что на практике значительно сложнее, чем кажется.
В случае MS SQL Server Always On Availability Groups согласованность достигается на уровне приложения, тогда как vSAN обеспечивает синхронную запись данных по своей сути — как часть распределённой архитектуры, изначально разработанной для обеспечения отказоустойчивости.
При репликации данных на уровне приложения такой высокий уровень доступности ограничен только этим конкретным приложением и его данными. Однако возможности на уровне приложений реализованы не одинаково. Например, MS SQL Server Always On AG могут обеспечивать RPO=0 при множестве сценариев отказа, тогда как MySQL InnoDB Cluster использует подход, при котором RPO=0 возможно только при отказе одного узла. Хотя данные при этом остаются согласованными, в некоторых сценариях отказа — например, при полном сбое кластера или незапланированной перезагрузке — могут быть потеряны последние зафиксированные транзакции. Это означает, что при определённых обстоятельствах обеспечить истинный RPO=0 невозможно.
В случае vSAN в составе VCF, высокая доступность является универсальной характеристикой, которая применяется ко всем рабочим нагрузкам, записывающим данные в хранилище vSAN datastore.
Различия во времени восстановления (RTO)
Одной из основных причин различий между возможностями RTO при доступности на уровне приложения и на уровне инфраструктуры является то, как приложение возвращается в рабочее состояние после сбоя.
Например, некоторые приложения, такие как SQL Server AG, используют лицензированные «резервные» виртуальные машины (standby VMs) в вашей инфраструктуре, чтобы обеспечить использование другого состояния приложения при отказе. Это позволяет достичь низкого RTO, но приводит к увеличению затрат из-за необходимости дополнительных лицензий и потребляемых ресурсов. Высокая доступность на уровне приложения — это специализированное решение, требующее экспертизы в конкретном приложении для достижения нужного результата. Однако DSM может значительно снизить сложность таких сценариев, поскольку автоматизирует эти процессы и снимает значительную часть административной нагрузки.
Высокая доступность на уровне инфраструктуры работает иначе. Используя механизмы виртуализации, такие как vSphere High Availability (HA), она обеспечивает перезапуск приложения в другом месте при сбое виртуальной машины. Перезапуск ВМ и самого приложения, а также процесс восстановления журналов обычно занимают больше времени, чем подход с резервной ВМ, используемый при высокой доступности на уровне приложений.
Приведённые выше значения времени восстановления являются оценочными. Фактическое время восстановления может значительно различаться в зависимости от условий среды, размера и активности экземпляра MS SQL.
Что выбрать именно вам?
Наилучший выбор зависит от ваших требований, ограничений и того, насколько решение подходит вашей организации. Например:
Требования к доступности
Возможно, ваши требования предполагают, что приложение и его данные должны быть доступны за пределами определённой границы отказа — например, уровня сайта или зоны. Это поможет определить, нужна ли вообще доступность на уровне сайта или зоны.
Требования к RTO
Если требуемое время восстановления (RTO) допускает 2–5 минут, то высокая доступность на уровне инфраструктуры — отличный вариант, поскольку она встроена в платформу и работает для всех ваших нагрузок. Если же есть несколько отдельных приложений, для которых требуется меньшее RTO, и вас не смущают дополнительные затраты и сложность, связанные с этим решением, то подход на уровне приложения может быть оправдан.
Технические ограничения
В вашей организации могут быть инициативы по упрощению инструментов и рабочих процессов, что может ограничивать возможность или желание использовать дополнительные технологии, такие как высокая доступность на уровне приложений. Обычно предпочтение отдаётся универсальным инструментам, применимым ко всем системам, а не узкоспециализированным решениям. Другие технические факторы, например задержки (latency) между сайтами или зонами, также могут сделать тот или иной подход непрактичным.
Финансовые ограничения
Возможно, на вас оказывают давление с целью сократить постоянные расходы на программное обеспечение — например, на дополнительные лицензии или более дорогие уровни лицензирования, необходимые для обеспечения высокой доступности на уровне приложений. В этом случае более выгодным решением могут оказаться уже имеющиеся технологии.
Можно также использовать комбинацию обоих подходов.
Например, на первом рисунке в начале статьи показано, как высокая доступность на уровне приложений реализуется между сайтами или зонами с помощью MS SQL Always On Availability Groups, а высокая доступность на уровне инфраструктуры обеспечивается vSAN и vSphere HA внутри каждого сайта или зоны.
Этот вариант также может быть отличным примером использования VMware Data Services Manager (DSM). Вместо запуска и управления отдельными виртуальными машинами можно использовать базы данных, развёрнутые DSM, для обеспечения доступности приложений между сайтами или зонами. Такой подход обеспечивает низкое RTO, устраняет административную сложность, связанную с репликацией на уровне приложений, и при этом позволяет vSAN обеспечивать доступность данных внутри сайтов или зон.
Вильям Лам описал способ развертывания виртуального модуля OVF/OVA напрямую с сервера с Basic Authentication.
Он делал эксперименты с использованием OVFTool и доработал свой скрипт deploy_data_services_manager.sh, чтобы он ссылался на URL, где был размещён Data Services Manager (DSM) в формате OVA. В этом случае базовую аутентификацию (имя пользователя и пароль) можно включить прямым текстом в URL. Хотя это не самый безопасный способ, он позволяет удобно использовать этот метод развертывания.
p>Компания VMware опубликовала новое видео, в котором демонстрируется полный процесс обновления инфраструктуры vSphere 8.x и компонентов Aria Suite до последней версии VMware Cloud Foundation (VCF) 9.0.
В примере показано, как среда, использующая Aria Suite Lifecycle Manager и Aria Operations, переходит на новую версию платформы. Процесс начинается с обновления Aria Lifecycle Manager до версии 8.18 Patch 2 или выше. Затем с его помощью выполняется апгрейд Aria Operations до VCF Operations 9.0, что автоматически разворачивает новый компонент — VCF 9 Fleet Management Appliance.
После обновления сервисов Aria обновляется сама инфраструктура vSphere: выполняется переход на VLCM images, обновляются vCenter Server и хосты ESX до версии 9.0.
На следующем этапе используется установщик VMware Cloud Foundation, который скачивает необходимые бинарные файлы и проводит обновление среды до VCF 9.0. В ходе этого процесса выполняется консолидация существующих компонентов vCenter Server и VCF Operations в единый VCF Management Domain. Установщик также автоматически разворачивает Operations Collector, VMware NSX, настраивает SDDC Manager и при необходимости устанавливает модуль VCF Automation (его можно добавить позже через Fleet Management Appliance).
После завершения обновления выполняется повторное лицензирование среды под VCF 9.0, а также ряд действий после обновления: развёртывание VCF Logs, настройка внешнего vCenter Identity Broker, включение VCF SSO, связывание нескольких серверов vCenter и установка дополнительных модулей, включая Operations for Networks и HCX.
Видео демонстрирует комплексный процесс перехода на новую версию VMware Cloud Foundation и подчёркивает преимущества глубокой интеграции и автоматизации в экосистеме VMware.
В эпоху, когда AI всё чаще «уходит к краю сети» — то есть — выполняется непосредственно на устройстве или на близкой инфраструктуре, требования к беспроводным сетям меняются. Вместо гонки за пиковыми скоростями становится важнее низкая задержка, высокая надёжность, предсказуемость и адаптивность. Именно в этом контексте появляется новое поколение — Wi-Fi 8 (также обозначаемое как IEEE 802.11bn), задача которого — стать «основой» для беспроводного AI edge. Компания Broadcom представила своё семейство чипсетов Wi-Fi 8, позиционируя их как фундаментальную платформу для сетей с AI-устройствами.
Почему Wi-Fi 8 — это не про максимальную скорость?
В предыдущих поколениях Wi-Fi (например, Wi-Fi 6, Wi-Fi 6E, Wi-Fi 7) основной акцент делался на увеличение пропускной способности: больше GHz, больше антенн, более мощная модуляция. Однако в блоге Broadcom подчёркивается, что Wi-Fi 8 сменяет приоритеты: теперь главное — надёжность, предсказуемость, контроль задержки и способность работать в сложных, насыщенных средах. Другими словами: устройство может не показывать «в идеале» наибольшую скорость, но важно, чтобы оно доставляло данные вовремя, без провалов, даже если сеть нагружена.
Это особенно актуально для оконечных AI-устройств: камеры, датчики, автономные роботы, автомобили, «умный дом», промышленная автоматизация — там требуется мгновенная реакция, и беспроводная сеть не может быть слабым звеном.
Технические особенности Wi-Fi 8
Ниже — основные архитектурные и технологические моменты, которые Broadcom выделяет как отличительные черты Wi-Fi 8.
1. Телеметрия и адаптивность
Семейство чипов Wi-Fi 8 от Broadcom включает встроенные механизмы телеметрии, которые постоянно измеряют поведение сети: условия канала, загруженность, помехи, мобильность устройств. Эта информация используется в реальном времени для адаптации: например, переключение каналов, корректировка мощности, приоритизация трафика, динамическое управление потоком данных — всё с целью обеспечить низкую задержку и стабильное соединение.
2. Архитектура «краевого AI» (Edge AI)
Wi-Fi 8 позиционируется именно как платформа для Edge AI — то есть инфраструктуры, где модель, обработка данных или рекомендации выполняются ближе к устройству, а не в облаке. Broadcom подчёркивает: устройства и сети должны быть «AI-ready» — готовыми к работе с интенсивными задачами AI в режиме реального времени.
Это требует:
Очень низкой задержки (чтобы не было «запаздывания» отклика)
Высокой надёжности (чтобы результат был предсказуемым)
Способности одновременно обслуживать множество устройств (IoT, сенсоры, камеры и др.)
3. Поддержка различных классов устройств и сценариев
Broadcom указывает, что Wi-Fi 8 охватывает не только домашние маршрутизаторы, но и корпоративные точки доступа, а также клиентские устройства: смартфоны, ноутбуки, автомобильные системы.
Такая универсальность важна: сеть на краю должна обслуживать разные типы устройств с разными требованиями.
4. Лицензирование стратегии и экосистема
Интересный аспект: Broadcom открывает свою платформу Wi-Fi 8 через лицензирование IP и продуктов, особенно для рынков IoT и automotive. Это позволяет партнёрам быстрее внедрять Wi-Fi 8 в новые устройства и экосистемы.
5. Стандарт IEEE 802.11bn — ориентиры
Хотя Wi-Fi 8 ещё находится в разработке (стандарт IEEE 802.11bn), уже видны ориентиры: фокус на «Ultra High Reliability» (UHR) — чрезвычайно высокая надёжность, низкая задержка, устойчивость к помехам и плотной среде.
Например, даже если физические изменения по сравнению с Wi-Fi 7 не столь радикальны, акцент смещается на качество соединения, а не просто на максимальную скорость.
Зачем Wi-Fi 8 нужен именно для Wireless AI Edge
Рассмотрим ключевые сценарии, где преимущества Wi-Fi 8 раскрываются наиболее ярко.
Сценарий: автономные системы и роботы
Представьте завод с роботами-манипуляторами, дронами, транспортными средствами на базе AI. Они генерируют, обрабатывают и обмениваются данными на месте: карты, сенсоры, объекты, навигация. Здесь задержка, потеря пакетов или нестабильность соединения — недопустимы. Wi-Fi 8 помогает обеспечить:
Постоянное качество соединения даже при движении устройств
Адаптацию к изменяющимся условиям канала
Высокую плотность устройств в ограниченном пространстве
Сценарий: IP-камеры, видеоаналитика и умный дом
Камеры с AI-аналитикой могут находиться где-то между облаком и Edge. Wi-Fi 8 обеспечивает непрерывную передачу потока, реагирование на события и автономную работу без нарушения связи.
Сценарий: автомобильная и транспортная инфраструктура
Wi-Fi 8 встроен в автомобильные системы и мобильные устройства. При движении, смене точек доступа, большом количестве подключённых устройств важно, чтобы сеть была непрерывной, с минимальной задержкой, автоматически адаптировалась при смене сценария.
Так появится экосистема решений Wi-Fi 8 для домашних (BCM6718), корпоративных (BCM43840, BCM43820) и клиентских устройств (BCM43109).
Вызовы и что ещё предстоит
Хотя Wi-Fi 8 выглядит многообещающе, есть несколько моментов, на которые стоит обратить внимание.
Стандартизация и сроки - стандарт IEEE 802.11bn ещё не окончательно утверждён; коммерческая доступность устройств и сертификация могут занять несколько лет.
Это значит, что внедрение Wi-Fi 8-решений в промышленном масштабе может состояться не сразу.
Экосистема и совместимость - чтобы Wi-Fi 8 стал по-настоящему успешным, требуется: устройства-клиенты (смартфоны, ноутбуки, IoT-устройства), точки доступа, маршрутизаторы, инфраструктура поддержки, программные платформы. Переход всей экосистемы — задача небыстрая.
Цена и обоснование обновлений - поскольку пиковые скорости могут не сильно отличаться от Wi-Fi 7, организациям и пользователям придётся оценивать: стоит ли обновлять оборудование сейчас ради большей надёжности и «готовности к AI Edge». Некоторые аналитики отмечают, что без заметного прироста скорости маркетинг может быть слабее.
Безопасность и управление - с большим количеством устройств, большим количеством трафика «на краю», а также AI-нагрузками возрастает важность безопасности как на уровне устройства, так и на уровне сети. Wi-Fi 8 должен преодолеть этот вызов.
Заключение
Wi-Fi 8 от Broadcom — это не просто новое поколение беспроводного стандарта ради скорости — это полноценная платформа, ориентированная на эпоху Edge AI. Она призвана обеспечить надежную, предсказуемую, гибкую сеть, способную поддерживать устройства с AI-нагрузкой в самых требовательных сценариях.
Для организаций, которые планируют развивать инфраструктуру Edge AI, промышленный IoT, автономные системы, «умный город», Wi-Fi 8 может стать ключевым технологическим элементом. Однако, как и с любой новой технологией, важно учитывать сроки стандартизации, экосистему, реальную выгоду от обновления и стратегию внедрения.
RSS
