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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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

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

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

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

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

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

VMware Live Recovery (VLR) продолжает обеспечивать надёжную кибер- и информационную устойчивость для VMware Cloud Foundation 9 (VCF), предлагая унифицированную защиту и безопасное восстановление после инцидентов ИБ. Помимо возможностей кибервосстановления, VMware Live Recovery остаётся основой корпоративного оркестратора аварийного восстановления в различных топологиях на базе VCF и включает расширенную репликацию vSphere между сайтами с RPO до одной минуты для поддержки критически важных приложений. VMware Live Recovery также интегрирован с функциями защиты данных хранилища VMware vSAN ESA. Всё более глубокая интеграция между VLR и основными компонентами VCF, такими как vSAN, выделяет решение на фоне конкурентов и усиливает ценность единой платформы для клиентов.

С последним релизом VMware Cloud Foundation 9 в решение VMware Live Recovery были добавлены следующие ключевые улучшения:

• VLR Appliance – упрощённое развертывание и управление сервисами
• Интеграция с VMware Cloud Foundation – улучшенный доступ к данным защиты
• Улучшенная интеграция Protection Group и Recovery Plan с защитой данных vSAN
• Кибервосстановление – поддержка сценариев на стороне заказчика, повышение суверенитета данных

VLR Appliance – упрощённое развертывание и управление сервисами

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

В новом объединённом устройстве VLR консолидации подверглись следующие сервисы защиты и восстановления:

• Расширенная репликация между сайтами на базе vSphere
• Снапшоты на базе vSAN на заданных (исходном/целевом) сайтах vSAN ESA
• Автоматизация и оркестрация Site Recovery

Этот релиз VLR Appliance доступен всем клиентам с подпиской VLR, а также владельцам бессрочных лицензий SRM с действующей поддержкой SnS или временной подпиской. Новый модуль можно установить на сервер vCenter для объединения ранее установленных компонентов, как показано ниже:

Информация по развертыванию

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

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

Для получения более подробной информации и системных требований см. документацию по VMware Live Recovery.

Важно отметить, что новый модуль VLR будет единственным вариантом, совместимым с VCF, но при этом сохраняет обратную совместимость с более старыми версиями ESX и vCenter (8.0 U3b+, 8.0 U2d+), чтобы обеспечить корректную межсайтовую работу и совместимость при переходе клиентов на новую платформу VCF. Как всегда, рекомендуется использовать инструмент совместимости продуктов VMware перед обновлениями — в данном случае, чтобы сравнить компоненты VMware Live Site Recovery и VMware Cloud Foundation.

Расширенная репликация vSphere теперь включена в унифицированную модель развертывания VLR и обеспечивает более масштабируемую и эффективную репликацию с возможностью RPO до одной минуты.

Важно: расширенная репликация vSphere теперь является конфигурацией по умолчанию и единственно поддерживаемой для репликации между сайтами. Для сайтов, использующих старые версии vSphere Replication, перед установкой нового модуля VLR потребуется обновление до Enhanced vSphere Replication. Подробности об обновлении см. в документации. Если используется репликация на уровне СХД (array-based replication), необходимо установить SRA и array-менеджеры на новое устройство VLR и настроить их отдельно. Для дополнительной информации о выпуске этого VLR Appliance см. документацию по VMware Live Recovery Appliance.

Интеграция с VMware Cloud Foundation – лучший доступ к данным защиты

Платформа VMware Cloud Foundation поддерживает одновременную работу как традиционных виртуальных машин, так и модернизированных рабочих нагрузок. Совместимость VMware Live Recovery была обновлена, особенно в части свойств виртуальных машин для поддержки переключения (failover) и возврата (failback). Подробности о поддержке защищённых, управляемых сервисами ВМ доступны в документации.

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

Панель Data Protection & Recovery в VCF Operations для VMware Live Recovery предоставляет критически важную информацию в одном месте. Пользователи могут быстро оценить:

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

Для более глубокого анализа можно установить VLR и VR Management Packs, чтобы получить доступ к предустановленным дэшбордам. Пример дэшборда верхнего уровня:

Улучшенная интеграция групп защиты (Protection Groups) и планов восстановления (Recovery Plans) с защитой данных vSAN

Устройство VLR Appliance поддерживает службы Data Protection Snapshot Management Services для vSAN ESA и обеспечивает более глубокую интеграцию в оркестрационную платформу VMware Live Recovery. Для хранилищ на базе vSAN ESA благодаря интеграции с VLR теперь доступны три ключевые функции:

• Локальные снимки хранилища (local datastore snapshots)
• Удалённые снимки хранилища (remote datastore snapshots)
• Репликация между хранилищами vSAN ESA

Чтобы упростить защиту виртуальных машин, конфигурации групп защиты (Protection Groups) автоматически обнаруживаются и доступны как через интерфейс vSAN Data Protection UI, так и через VMware Live Site Recovery, что существенно упрощает администрирование защиты и восстановления в масштабах всей инфраструктуры предприятия.

Кибервосстановление – поддержка локальных сценариев и повышение суверенитета данных

С этим релизом VCF и новой версией VLR клиенты могут использовать утверждённую VMware архитектуру (VMware Validated Solution), реализованную как драфт для версии 9.0, для создания локальной зоны кибервосстановления (clean room). Эта архитектура использует:

• Домен рабочих нагрузок VCF как изолированную clean room.
• Кластер хранения vSAN ESA как защищённое кибер-хранилище (cyber data vault).
• vDefend для сетевой изоляции.
• VMware Live Recovery для оркестрации процессов восстановления.

Теперь организации, которым необходимо соблюдать требования к конфиденциальности данных или территориальной принадлежности (data residency), могут обеспечивать суверенитет данных, не передавая их в публичное облако, а размещая инфраструктуру восстановления в локальной среде VCF clean room.

Общая архитектура такого сценария показана на схеме ниже:

Последний релиз VMware Cloud Foundation (VCF) и обновления VMware Live Recovery (VLR) включают важные усовершенствования, направленные на удовлетворение современных требований ИТ-организаций к защите и восстановлению данных. Чтобы узнать больше о глубокой интеграции всех средств защиты, упрощённых методах развертывания и управления, а также расширенных возможностях сценариев восстановления — ознакомьтесь с материалами по следующим ссылкам: VMware Live Recovery и документация по VLR.

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

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

Что внутри VMware Cloud Foundation 9 Design Guide?

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

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

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

Доступные шаблоны включают описания VCF-компонентов в следующих конфигурациях:

• На одной площадке с минимальным размером
• Полноценно на одной площадке
• На нескольких площадках в одном регионе
• На нескольких площадках в разных регионах
• На нескольких площадках в одном регионе плюс дополнительные регионы

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

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

Новая версия платформы VMware Cloud Foundation 9.0, включающая компоненты виртуализации серверов и хранилищ VMware vSphere 9.0, а также виртуализации сетей VMware NSX 9, привносит не только множество улучшений, но и устраняет ряд устаревших технологий и функций. Многие возможности, присутствовавшие в предыдущих релизах ESX (ранее ESXi), vCenter и NSX, в VCF 9 объявлены устаревшими (deprecated) или полностью удалены (removed). Это сделано для упрощения архитектуры, повышения безопасности и перехода на новые подходы к архитектуре частных и публичных облаков. Ниже мы подробно рассмотрим, каких функций больше нет во vSphere 9 (в компонентах ESX и vCenter) и NSX 9, и какие альтернативы или рекомендации по миграции существуют для администраторов и архитекторов.

Почему важно знать об удалённых функциях?

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

VMware vSphere 9: удалённые и устаревшие функции ESX и vCenter

В VMware vSphere 9.0 (гипервизор ESX 9.0 и сервер управления vCenter Server 9.0) прекращена поддержка ряда старых средств администрирования и внедрены новые подходы. Ниже перечислены основные функции, устаревшие (подлежащие удалению в будущих версиях) или удалённые уже в версии 9, а также рекомендации по переходу на современные альтернативы:

• vSphere Auto Deploy (устарела) – сервис автоматического развертывания ESXi-хостов по сети (PXE-boot) объявлен устаревшим. В ESX 9.0 возможность Auto Deploy (в связке с Host Profiles) будет удалена в одном из следующих выпусков линейки 9.x.
  
  Рекомендация: если вы использовали Auto Deploy для бездискового развёртывания хостов, начните планировать переход на установку ESXi на локальные диски либо использование скриптов для автоматизации установки. В дальнейшем управление конфигурацией хостов следует осуществлять через образы vLCM и vSphere Configuration Profiles, а не через загрузку по сети.

• vSphere Host Profiles (устарела) – механизм профилей хоста, позволявший применять единые настройки ко многим ESXi, будет заменён новой системой конфигураций. Начиная с vCenter 9.0, функциональность Host Profiles объявлена устаревшей и будет полностью удалена в будущих версиях.
  
  Рекомендация: вместо Host Profiles используйте vSphere Configuration Profiles, позволяющие управлять настройками на уровне кластера. Новый подход интегрирован с жизненным циклом vLCM и обеспечит более надежную и простую поддержку конфигураций.

• vSphere ESX Image Builder (устарела) – инструмент для создания кастомных образов ESXi (добавления драйверов и VIB-пакетов) больше не развивается. Функциональность Image Builder фактически поглощена возможностями vSphere Lifecycle Manager (vLCM): в vSphere 9 вы можете создавать библиотеку образов ESX на уровне vCenter и собирать желаемый образ из компонентов (драйверов, надстроек от вендоров и т.д.) прямо в vCenter.
  
  Рекомендация: для формирования образов ESXi используйте vLCM Desired State Images и новую функцию ESX Image Library в vCenter 9, которая позволит единообразно управлять образами для кластеров вместо ручной сборки ISO-файлов.

• vSphere Virtual Volumes (vVols, устарела) – технология виртуальных томов хранения объявлена устаревшей с выпуском VCF 9.0 / vSphere 9.0. Поддержка vVols отныне будет осуществляться только для критических исправлений в vSphere 8.x (VCF 5.x) до конца их поддержки. В VCF/VVF 9.1 функциональность vVols планируется полностью удалить.
  
  Рекомендация: если в вашей инфраструктуре используются хранилища на основе vVols, следует подготовиться к миграции виртуальных машин на альтернативные хранилища. Предпочтительно задействовать VMFS или vSAN, либо проверить у вашего поставщика СХД доступность поддержки vVols в VCF 9.0 (в индивидуальном порядке возможна ограниченная поддержка, по согласованию с Broadcom). В долгосрочной перспективе стратегия VMware явно смещается в сторону vSAN и NVMe, поэтому использование vVols нужно минимизировать.

• vCenter Enhanced Linked Mode (устарела) – расширенный связанный режим vCenter (ELM), позволявший объединять несколько vCenter Server в единый домен SSO с общей консолью, более не используется во VCF 9. В vCenter 9.0 ELM объявлен устаревшим и будет удалён в будущих версиях. Хотя поддержка ELM сохраняется в версии 9 для возможности обновления существующих инфраструктур, сама архитектура VCF 9 переходит на иной подход: единое управление несколькими vCenter осуществляется средствами VCF Operations вместо связанного режима.
  
  Рекомендация: при планировании VCF 9 откажитесь от развёртывания новых связанных групп vCenter. После обновления до версии 9 рассмотрите перевод существующих vCenter из ELM в раздельный режим с группированием через VCF Operations (который обеспечивает центральное управление без традиционного ELM). Функции, ранее обеспечивавшиеся ELM (единый SSO, объединённые роли, синхронизация тегов, общая точка API и пр.), теперь достигаются за счёт возможностей VCF Operations и связанных сервисов.

• vSphere Clustering Service (vCLS, устарела) – встроенный сервис кластеризации, который с vSphere 7 U1 запускал небольшие служебные ВМ (vCLS VMs) для поддержки DRS и HA, в vSphere 9 более не нужен. В vCenter 9.0 сервис vCLS помечен устаревшим и подлежит удалению в будущем. Кластеры vSphere 9 могут работать без этих вспомогательных ВМ: после обновления появится возможность включить Retreat Mode и отключить развёртывание vCLS-агентов без какого-либо ущерба для функциональности DRS/HA.
  
  Рекомендация: отключите vCLS на кластерах vSphere 9 (включив режим Retreat Mode в настройках кластера) – деактивация vCLS никак не влияет на работу DRS и HA. Внутри ESX 9 реализовано распределенное хранилище состояния кластера (embedded key-value store) непосредственно на хостах, благодаря чему кластер может сохранять и восстанавливать свою конфигурацию без внешних вспомогательных ВМ. В результате вы упростите окружение (больше никаких «мусорных» служебных ВМ) и избавитесь от связанных с ними накладных расходов.

• ESX Host Cache (устарела) - в версии ESX 9.0 использование кэша на уровне хоста (SSD) в качестве кэша с обратной записью (write-back) для файлов подкачки виртуальных машин (swap) объявлено устаревшим и будет удалено в одной из будущих версий. В качестве альтернативы предлагается использовать механизм многоуровневой памяти (Memory Tiering) на базе NVMe. Memory Tiering с NVMe позволяет увеличить объём доступной оперативной памяти на хосте и интеллектуально распределять память виртуальной машины между быстрой динамической оперативной памятью (DRAM) и NVMe-накопителем на хосте.
  
  Рекомендация: используйте функции Advanced Memory Tiering на базе NVMe-устройств в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогого оборудования.
  
  
• Память Intel Optane Persistent Memory (удалена) - в версии ESX 9.0 прекращена поддержка технологии Intel Optane Persistent Memory (PMEM). Для выбора альтернативных решений обратитесь к представителям вашего OEM-поставщика серверного оборудования.
  
  Рекомендация: в качестве альтернативы вы можете использовать функционал многоуровневой памяти (Memory Tiering), официально представленный в ESX 9.0. Эта технология позволяет добавлять локальные NVMe-устройства на хост ESX в качестве дополнительного уровня памяти. Дополнительные подробности смотрите в статье базы знаний VMware KB 326910.
  
  
• Технология Storage I/O Control (SIOC) и балансировщик нагрузки Storage DRS (удалены) - в версии vCenter 9.0 прекращена поддержка балансировщика нагрузки Storage DRS (SDRS) на основе ввода-вывода (I/O Load Balancer), балансировщика SDRS на основе резервирования ввода-вывода (SDRS I/O Reservations-based load balancer), а также компонента vSphere Storage I/O Control (SIOC). Эти функции продолжают поддерживаться в текущих релизах 8.x и 7.x. Удаление указанных компонентов затрагивает балансировку нагрузки на основе задержек ввода-вывода (I/O latency-based load balancing) и балансировку на основе резервирования ввода-вывода (I/O reservations-based load balancing) между хранилищами данных (datastores), входящими в кластер хранилищ Storage DRS. Кроме того, прекращена поддержка активации функции Storage I/O Control (SIOC) на отдельном хранилище и настройки резервирования (Reservations) и долей (Shares) с помощью политик хранения SPBM Storage Policy. При этом первоначальное размещение виртуальных машин с помощью Storage DRS (initial placement), а также балансировка нагрузки на основе свободного пространства и политик SPBM Storage Policy (для лимитов) не затронуты и продолжают работать в vCenter 9.0.
  
  Рекомендация: администраторам рекомендуется нужно перейти на балансировку нагрузки на основе свободного пространства и политик SPBM. Настройки резервирований и долей ввода-вывода (Reservations, Shares) через SPBM следует заменить альтернативными механизмами контроля производительности со стороны используемых систем хранения (например, встроенными функциями QoS). После миграции необходимо обеспечить мониторинг производительности, чтобы своевременно устранять возможные проблемы.
  
  
• vSphere Lifecycle Manager Baselines (удалена) – классический режим управления патчами через базовые уровни (baselines) в vSphere 9 не поддерживается. Начиная с vCenter 9.0 полностью удалён функционал VUM/vLCM Baselines – все кластеры и хосты должны использовать только рабочий процесс управления жизненным циклом на базе образов (image-based lifecycle). При обновлении с vSphere 8 имеющиеся кластеры на baselines придётся перевести на работу с образами, прежде чем поднять их до ESX 9.
  
  Рекомендация: перейдите от использования устаревших базовых уровней к vLCM images – желаемым образам кластера. vSphere 9 позволяет применять один образ к нескольким кластерам или хостам сразу, управлять соответствием (compliance) и обновлениями на глобальном уровне. Это упростит администрирование и устранит необходимость в ручном создании и применении множества baseline-профилей.
  
  
• Integrated Windows Authentication (IWA, удалена) – в vCenter 9.0 прекращена поддержка интегрированной Windows-аутентификации (прямого добавления vCenter в домен AD). Вместо IWA следует использовать LDAP(S) или федерацию. VMware официально заявляет, что vCenter 9.0 более не поддерживает IWA, и для обеспечения безопасного доступа необходимо мигрировать учетные записи на Active Directory over LDAPS или настроить федерацию (например, через ADFS) с многофакторной аутентификацией.
  
  Рекомендация: до обновления vCenter отключите IWA, переведите интеграцию с AD на LDAP(S), либо настройте VMware Identity Federation с MFA (эта возможность появилась начиная с vSphere 7). Это позволит сохранить доменную интеграцию vCenter в безопасном режиме после перехода на версию 9.
  
  
• Локализации интерфейса (сокращены) – В vSphere 9 уменьшено число поддерживаемых языков веб-интерфейса. Если ранее vCenter поддерживал множество языковых пакетов, то в версии 9 оставлены лишь английский (US) и три локали: японский, испанский и французский. Все остальные языки (включая русский) более недоступны.
  
  Рекомендация: администраторы, использующие интерфейс vSphere Client на других языках, должны быть готовы работать на английском либо на одной из трёх оставшихся локалей. Учебные материалы и документацию стоит ориентировать на английскую версию интерфейса, чтобы избежать недопонимания.

Общий совет по миграции для vSphere: заранее инвентаризуйте использование перечисленных функций в вашей инфраструктуре. Переход на vSphere 9 – удобный повод внедрить новые подходы: заменить Host Profiles на Configuration Profiles, перейти от VUM-бейзлайнов к образам, отказаться от ELM в пользу новых средств управления и т.д. Благодаря этому обновление пройдет более гладко, а ваша платформа будет соответствовать современным рекомендациям VMware.

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

VMware NSX 9: Устаревшие и неподдерживаемые функции

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

• Подключение физических серверов через NSX-Agent (удалено) – В NSX 9.0 больше не поддерживается развёртывание NSX bare-metal agent на физических серверах для включения их в оверлей NSX. Ранее такие агенты позволяли физическим узлам участвовать в логических сегментах NSX (оверлейных сетях). Начиная с версии 9, оверлейная взаимосвязь с физическими серверами не поддерживается – безопасность для физических серверов (DFW) остаётся, а вот L2-overlay connectivity убрана.
  
  Рекомендация: для подключения физических нагрузок к виртуальным сетям NSX теперь следует использовать L2-мосты (bridge) на NSX Edge. VMware прямо рекомендует для новых подключений физических серверов задействовать NSX Edge bridging для обеспечения L2-связности с оверлеем, вместо установки агентов на сами серверы. То есть физические серверы подключаются в VLAN, который бриджится в логический сегмент NSX через Edge Node. Это позволяет интегрировать физическую инфраструктуру с виртуальной без установки NSX компонентов на сами серверы. Если у вас были реализованы bare-metal transport node в старых версиях NSX-T 3.x, их придётся переработать на схему с Edge-бриджами перед обновлением до NSX 9. Примечание: распределённый мост Distributed TGW, появившийся в VCF 9, также может обеспечить выход ВМ напрямую на ToR без Edge-узла, что актуально для продвинутых случаев, но базовый подход – через Edge L2 bridge.

• Виртуальный коммутатор N-VDS на ESXi (удалён) – исторически NSX-T использовала собственный виртуальный коммутатор N-VDS для хостов ESXi и KVM. В NSX 9 эта технология более не применяется для ESX-хостов. Поддержка NSX N-VDS на хостах ESX удалена, начиная с NSX 4.0.0.1 (соответствует VCF 9). Теперь NSX интегрируется только с родным vSphere Distributed Switch (VDS) версии 7.0 и выше. Это означает, что все среды на ESX должны использовать конвергентный коммутатор VDS для работы NSX. N-VDS остаётся лишь в некоторых случаях: на Edge-нодах и для агентов в публичных облаках или на bare-metal Linux (где нет vSphere), но на гипервизорах ESX – больше нет.
  
  Рекомендация: перед обновлением до NSX 9 мигрируйте все транспортные узлы ESXi с N-VDS на VDS. VMware предоставила инструменты миграции host switch (начиная с NSX 3.2) – ими следует воспользоваться, чтобы перевести существующие NSX-T 3.x host transport nodes на использование VDS. После перехода на NSX 9 вы получите более тесную интеграцию сети с vCenter и упростите управление, так как сетевые политики NSX привязываются к стандартному vSphere VDS. Учтите, что NSX 9 требует наличия vCenter для настройки сетей (фактически NSX теперь не работает автономно от vSphere), поэтому планируйте инфраструктуру исходя из этого.

• Поддержка гипервизоров KVM и стороннего OpenStack (удалена) – NSX-T изначально позиционировался как мультигипервизорное решение, поддерживая кроме vSphere также KVM (Linux) и интеграцию с opensource OpenStack. Однако с выходом NSX 4.0 (и NSX 9) стратегия изменилась. NSX 9.0 больше не поддерживает гипервизоры KVM и дистрибутивы OpenStack от сторонних производителей. Поддерживается лишь VMware Integrated OpenStack (VIO) как исключение. Проще говоря, NSX сейчас нацелен исключительно на экосистему VMware.
  
  Рекомендация: если у вас были развёрнуты политики NSX на KVM-хостах или вы использовали NSX-T совместно с не-VMware OpenStack, переход на NSX 9 невозможен без изменения архитектуры. Вам следует либо остаться на старых версиях NSX-T 3.x для таких сценариев, либо заменить сетевую виртуализацию в этих средах на альтернативные решения. В рамках же VCF 9 такая ситуация маловероятна, так как VCF подразумевает vSphere-стек. Таким образом, основное действие – убедиться, что все рабочие нагрузки NSX переведены на vSphere, либо изолировать NSX-T 3.x для специфичных нужд вне VCF. В будущем VMware будет развивать NSX как часть единой платформы, поэтому мультиплатформенные возможности урезаны в пользу оптимизации под vSphere.

• NSX for vSphere (NSX-V) 6.x – не применяется – отдельно стоит упомянуть, что устаревшая платформа NSX-V (NSX 6.x для vSphere) полностью вышла из обращения и не входит в состав VCF 9. Её поддержка VMware прекращена еще в начале 2022 года, и миграция на NSX-T (NSX 4.x) стала обязательной. В VMware Cloud Foundation 4.x и выше NSX-V отсутствует, поэтому для обновления окружения старше VCF 3 потребуется заранее выполнить миграцию сетевой виртуализации на NSX-T.
  
  Рекомендация: если вы ещё используете NSX-V в старых сегментах, необходимо развернуть параллельно NSX 4.x (NSX-T) и перенести сетевые политики и сервисы (можно с помощью утилиты Migration Coordinator, если поддерживается ваша версия). Только после перехода на NSX-T вы сможете обновиться до VCF 9. В новой архитектуре все сетевые функции будут обеспечиваться NSX 9, а NSX-V останется в прошлом.

Подводя итог по NSX: VMware NSX 9 сфокусирован на консолидации функций для частных облаков на базе vSphere. Возможности, выходящие за эти рамки (поддержка разнородных гипервизоров, агенты на физической базе и др.), были убраны ради упрощения и повышения производительности. Администраторам следует заранее учесть эти изменения: перевести сети на VDS, пересмотреть способы подключения физических серверов и убедиться, что все рабочие нагрузки, требующие NSX, работают в поддерживаемой конфигурации. Благодаря этому переход на VCF 9 будет предсказуемым, а новая среда – более унифицированной, безопасной и эффективной. Подготовившись к миграции от устаревших технологий на современные аналоги, вы сможете реализовать преимущества VMware Cloud Foundation 9.0 без длительных простоев и с минимальным риском для работы дата-центра.

Итоги

Большинство приведённых выше изменений официально перечислены в документации Product Support Notes к VMware Cloud Foundation 9.0 для vSphere и NSX. Перед обновлением настоятельно рекомендуется внимательно изучить примечания к выпуску и убедиться, что ни одна из устаревших функций, на которых зависит ваша инфраструктура, не окажется критичной после перехода. Следуя рекомендациям по переходу на новые инструменты (vLCM, Configuration Profiles, Edge Bridge и т.д.), вы обеспечите своей инфраструктуре поддерживаемость и готовность к будущим обновлениям в экосистеме VMware Cloud Foundation.

Недавно компания VMware обновила свой распределенный сетевой экран vDefend 9 в рамках релиза VMware Cloud Foundation 9.0. Новые усовершенствования включают поддержку lateral security с учетом среды VPC, самостоятельную микро-сегментацию, упрощённую миграцию vDefend в VCF и централизованное глобальное управление IDS/IPS-политиками для ускоренного реагирования на угрозы и их устранения.

Современные предприятия стремительно внедряют стратегию частного облака в своих инфраструктурах. Недавнее исследование, охватившее 1 800 руководителей высокого уровня, показало, что их организации отдают приоритет частным облакам для решения проблем, связанных со стоимостью, необходимостью предсказуемости, требованиями AI-нагрузок, lateral security и соблюдением нормативных требований.

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

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

Новые возможности vDefend для VCF 9.0

• Боковая безопасность с поддержкой VPC (VPC-Aware Lateral Security): теперь пользователи могут применять vDefend на уровне виртуального частного облака (VPC), внедряя изолированные и управляемые политики боковой безопасности для каждого арендатора/потребителя. Это обеспечивает точный контроль и делегированное управление, упрощая многопользовательские среды.

• Самостоятельная микросегментация (Self-Service Micro-segmentation): команды инфраструктуры создают централизованные политики межсетевого экранирования для «огороженных» зон приложений. В версии vDefend 9.0 владельцам приложений можно делегировать создание детализированных политик внутри этих зон. Автоматизация возможна через API в рамках DevOps CI/CD-процессов.

• Интеграция импорта в VCF (VCF Import Integration): существующие развертывания vDefend вне VCF могут быть импортированы в среду VCF 9.0 с сохранением политик, что снижает усилия по миграции. Это упрощает и ускоряет переход на полнофункциональную платформу VCF.

• Глобальное управление IDS/IPS-политиками (Global Policy Management): централизованное управление политиками предотвращения и обнаружения вторжений на разных площадках обеспечивает единообразие политики и ускоренное реагирование на угрозы вне зависимости от местоположения рабочих нагрузок.

• Портал сигнатур IDS/IPS (Signature Portal): позволяет в реальном времени изучать изменения сигнатур без входа в консоль vDefend, что оптимизирует рабочие процессы, повышает осведомлённость об угрозах и ускоряет реагирование на инциденты.

• Фильтрация по геолокации (Geo-IP Filtering): межсетевой экран шлюза vDefend теперь может управлять трафиком с учётом географии, разрешая или блокируя подключения к определённым странам прямо на шлюзе уровня T0, обеспечивая точный контроль глобальных потоков.

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

Боковая безопасность с поддержкой VPC

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

С выпуском VMware Cloud Foundation (VCF) 9.0, vDefend расширяет возможности боковой безопасности, предоставляя полноценную изоляцию сетей на уровне VPC с помощью микро-сегментации, пропуская только доверенный трафик между приложениями. Это улучшение позволяет делегировать управление: администратор каждого VPC может видеть и настраивать только собственную среду. Команды теперь могут работать параллельно, обладая полной самостоятельностью и изоляцией, делая безопасную многопользовательскую работу в частном облаке реальностью.

Self-service микросегментация

Межсетевой экран vDefend предоставляет возможности как администраторам инфраструктуры, так и владельцам VPC. Администраторы инфраструктуры могут создавать защищённые виртуальные частные облака (VPC), сводя к минимуму горизонтальный (east-west) трафик. Одновременно с этим владельцы VPC получают гибкость в настройке детализированных правил для своих приложений, обеспечивая их работоспособность без нарушения централизованных политик безопасности. Такой подход способствует внедрению модели «самообслуживания» в вопросах безопасности для конечных пользователей при сохранении общего уровня защищённости организации.

Бесшовная миграция с импортом в VCF

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

Упрощённое и централизованное управление IDS/IPS-политиками в многокомпонентных VCF-средах с поддержкой изолированных (air-gapped) сред

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

Кроме того, возможность назначать несколько пакетов сигнатур IDS/IPS позволяет пользователям применять конкретные наборы сигнатур в нужных местах своих развертываний VCF. Для изолированных (air-gapped) сред поддерживается доставка пакетов сигнатур IDS/IPS на локальные управляющие узлы (Local Managers), даже при отсутствии подключения к интернету и наличии ограничений по соблюдению требований безопасности.

В совокупности эти возможности обеспечивают единообразное и централизованное управление политиками предотвращения угроз в многокомпонентных развертываниях VCF. Все события IDS/IPS отображаются в единой консоли управления.

Мониторинг в реальном времени с новым порталом сигнатур IDS/IPS

Поддержание актуальности защитных механизмов — критически важная задача; предприятия полагаются на частые обновления сигнатур, чтобы опережать новые угрозы. Хотя vDefend уже позволяет легко загружать и просматривать актуальные пакеты сигнатур IDS/IPS через свою консоль, аналитикам по безопасности зачастую требуется более глубокое понимание — например, определение новшеств в каждом пакете, отслеживание истории версий, поиск сигнатур по конкретным уязвимостям (CVE) или по определённым шаблонам атак, таким как каналы управления и контроля (Command and Control).

В новом портале сигнатур IDS/IPS VMware представила мощный инструмент, который позволяет операторам исследовать обновления сигнатур в реальном времени — без необходимости входа в консоль vDefend. Благодаря удобному веб-доступу портал позволяет командам изучать сигнатуры, искать покрытия по конкретным угрозам, сравнивать версии и экспортировать списки сигнатур. Эта возможность не только упрощает начальное планирование и развертывание, но и способствует более эффективному взаимодействию команд и ускоренному реагированию, повышая осведомлённость об угрозах и улучшая реагирование на инциденты в масштабе всей организации.

Точный контроль трафика с геозональной фильтрацией по странам

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

Более подробно о VMware vDefend 9 можно узнать на странице продукта. Release Notes доступны тут.

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

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

С VCF 9.0 стали доступны расширенные возможности самообслуживания в части сетевых сервисов, приближенные к опыту публичного облака, более простое развёртывание и гибкие варианты подключения, а также повышенная операционная эффективность и экономия за счёт интеграции полной автоматизации и управления на всех уровнях. Настройка и эксплуатация сетей стала проще благодаря глубокой интеграции со стеком VCF, прямому подключению к коммутаторным фабрикам и расширенной конфигурируемости и доступности виртуальных частных облаков (VPC). Благодаря улучшениям в VCF Automation, VCF Operations и vCenter компания VMware помогает компаниям запускать критически важные рабочие нагрузки — быстрее, надёжнее и эффективнее.

Основные сетевые новшества в VCF 9.0

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

VCF 9.0 представляет серьёзный прогресс в области сетевого самообслуживания, делая развёртывания VCF готовыми к использованию Virtual Private Cloud (VPC) "из коробки". Это позволяет разным командам легко использовать изолированные виртуальные сети, управляемые политиками, аналогично опыту в публичных облаках.

Изначально представленные как упрощённая модель потребления сетевых сервисов, VPC в VMware Cloud Foundation создают изолированные облачные окружения, позволяющие различным арендаторам, проектам или отделам безопасно и независимо работать, предоставляя им доступ в модели самообслуживания к подсетям, сетевым сервисам (таким как NAT), правилам межсетевого экрана и балансировке нагрузки.

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

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

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

2. Более простое развёртывание и гибкие варианты подключения

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

Упрощённое развёртывание

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

Предустановленные сетевые модули устраняют необходимость в сложной ручной настройке и сокращают время получения ценности от новых облачных сред. Ядро ESX теперь по умолчанию включает модули виртуальной сети (VIB), что снижает сложность и время установки и обновления сетевых функций. Эти улучшенные процессы позволяют использовать виртуальные сетевые возможности «из коробки», следуя рекомендованным архитектурным подходам и лучшим практикам — это позволяет быстро создавать новые домены рабочих нагрузок без отдельного развёртывания и настройки NSX.

Гибкие подключения

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

Transit Gateway полностью совместим с существующими сетевыми архитектурами на базе vSphere VDS и VLAN, что упрощает интеграцию с физической сетевой инфраструктурой. Вы можете подключаться напрямую от хоста к коммутаторной фабрике, используя упрощённую модель внешнего подключения, которая не требует развёртывания пограничных (edge) узлов или сложной маршрутизации. Это уменьшает количество промежуточных переходов, увеличивает пропускную способность, снижает задержки и облегчает устранение неполадок за счёт согласованности между физической и виртуальной топологиями.

VMware Cloud Foundation 9.0 теперь поддерживает развертывание одного NSX Manager — для клиентов, которым не требуется высокая доступность, обеспечиваемая кластером NSX Manager, и которые хотят сократить потребление ресурсов. Хотя наивысший уровень доступности по-прежнему требует кластера из трёх NSX Manager, новая топология с одним экземпляром позволяет более лёгкое управление в небольших окружениях, тестовых лабораториях или на периферийных площадках, где особенно важно экономить ресурсы.

3. Гибкая эксплуатация и мониторинг

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

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

• Обновлённая панель мониторинга состояния системы (System Health Dashboard) предоставляет унифицированное представление ключевых данных по сетевым, защитным и платформенным сервисам. Это ускоряет поиск причин неисправностей и отслеживание трендов.

• Поддержка "живых" обновлений через vLCM (vSphere Lifecycle Manager) и синхронизация с циклами обновления vSphere делает обновления NSX более эффективными. Операторы могут применять патчи безопасности и функциональные улучшения без полного простоя, минимизируя влияние на сервисы.

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

Резюме

С выпуском VCF 9.0 VMware предлагает более мощную сетевую основу для частных облаков — такую, которая сочетает гибкость и простоту публичных облаков с контролем и эффективностью локальной инфраструктуры.

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

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

Итак, наконец-то начинаем рассказывать о новых возможностях платформы виртуализации VMware vSphere 9, которая является основой пакета решений VMware Cloud Foundation 9, о релизе которого компания Broadcom объявила несколько дней назад. Самое интересное - гипервизор теперь опять называется ESX, а не ESXi, который также стал последователем ESX в свое время :)

Управление жизненным циклом

Путь обновления vSphere

vSphere 9.0 поддерживает прямое обновление только с версии vSphere 8.0. Прямое обновление с vSphere 7.0 не поддерживается. vCenter 9.0 не поддерживает управление ESX 7.0 и более ранними версиями. Минимально поддерживаемая версия ESX, которую может обслуживать vCenter 9.0, — это ESX 8.0. Кластеры и отдельные хосты, управляемые на основе baseline-конфигураций (VMware Update Manager, VUM), не поддерживаются в vSphere 9. Кластеры и хосты должны использовать управление жизненным циклом только на основе образов.

Live Patch для большего числа компонентов ESX

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

Компоненты vmkernel, пользовательское пространство, vmx (исполнение виртуальных машин) и NSX теперь могут использовать Live Patch. Службы ESX (например, hostd) могут потребовать перезапуска во время применения Live Patch, что может привести к кратковременному отключению хостов ESX от vCenter. Это ожидаемое поведение и не влияет на работу запущенных виртуальных машин. vSphere Lifecycle Manager сообщает, какие службы или демоны будут перезапущены в рамках устранения уязвимостей через Live Patch. Если Live Patch применяется к среде vmx (исполнение виртуальных машин), запущенные ВМ выполнят быструю приостановку и восстановление (Fast-Suspend-Resume, FSR).

Live Patch совместим с кластерами vSAN. Однако узлы-свидетели vSAN (witness nodes) не поддерживают Live Patch и будут полностью перезагружаться при обновлении. Хосты, использующие TPM и/или DPU-устройства, в настоящее время не совместимы с Live Patch.

Создавайте кластеры по-своему с разным оборудованием

vSphere Lifecycle Manager поддерживает кластеры с оборудованием от разных производителей, а также работу с несколькими менеджерами поддержки оборудования (hardware support managers) в рамках одного кластера. vSAN также поддерживает кластеры с различным оборудованием.

Базовая версия ESX является неизменной для всех дополнительных образов и не может быть настроена. Однако надстройки от производителей (vendor addon), прошивка и компоненты в определении каждого образа могут быть настроены индивидуально для поддержки кластеров с разнородным оборудованием. Каждое дополнительное определение образа может быть связано с уникальным менеджером поддержки оборудования (HSM).

Дополнительные образы можно назначать вручную для подмножества хостов в кластере или автоматически — на основе информации из BIOS, включая значения Vendor, Model, OEM String и Family. Например, можно создать кластер, состоящий из 5 хостов Dell и 5 хостов HPE: хостам Dell можно назначить одно определение образа с надстройкой от Dell и менеджером Dell HSM, а хостам HPE — другое определение образа с надстройкой от HPE и HSM от HPE.

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

Образами vSphere Lifecycle Manager и их привязками к кластерам или хостам можно управлять на глобальном уровне — через vCenter, датацентр или папку. Одно определение образа может применяться к нескольким кластерам и/или отдельным хостам из единого централизованного интерфейса. Проверка на соответствие (Compliance), предварительная проверка (Pre-check), подготовка (Stage) и устранение (Remediation) также могут выполняться на этом же глобальном уровне.

Существующие кластеры и хосты с управлением на основе базовых конфигураций (VUM)

Существующие кластеры и отдельные хосты, работающие на ESX 8.x и использующие управление на основе базовых конфигураций (VUM), могут по-прежнему управляться через vSphere Lifecycle Manager, но для обновления до ESX 9 их необходимо перевести на управление на основе образов. Новые кластеры и хосты не могут использовать управление на основе baseline-конфигураций, даже если они работают на ESX 8. Новые кластеры и хосты автоматически используют управление жизненным циклом на основе образов.

Больше контроля над операциями жизненного цикла кластера

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

Гибкость при выборе хостов для обновления

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

Больше никакой неопределённости при обновлениях и патчах

Механизм рекомендаций vSphere Lifecycle Manager учитывает версию vCenter. Версия vCenter должна быть равной или выше целевой версии ESX. Например, если vCenter работает на версии 9.1, механизм рекомендаций не предложит обновление хостов ESX до 9.2, так как это приведёт к ситуации, где хосты будут иметь более новую версию, чем vCenter — что не поддерживается. vSphere Lifecycle Manager использует матрицу совместимости продуктов Broadcom VMware (Product Interoperability Matrix), чтобы убедиться, что целевой образ ESX совместим с текущей средой и поддерживается.

Упрощённые определения образов кластера

Компоненты vSphere HA и NSX теперь встроены в базовый образ ESX. Это делает управление их жизненным циклом и обеспечением совместимости более прозрачным и надёжным. Компоненты vSphere HA и NSX автоматически обновляются вместе с установкой патчей или обновлений базового образа ESX. Это ускоряет активацию NSX на кластерах vSphere, поскольку VIB-пакеты больше не требуется отдельно загружать и устанавливать через ESX Agent Manager (EAM).

Определение и применение конфигурации NSX для кластеров vSphere с помощью vSphere Configuration Profiles

Теперь появилась интеграция NSX с кластерами, управляемыми через vSphere Configuration Profiles. Профили транспортных узлов NSX (TNP — Transport Node Profiles) применяются с использованием vSphere Configuration Profiles. vSphere Configuration Profiles позволяют применять TNP к кластеру одновременно с другими изменениями конфигурации.

Применение TNP через NSX Manager отключено для кластеров с vSphere Configuration Profiles

Для кластеров, использующих vSphere Configuration Profiles, возможность применять TNP (Transport Node Profile) через NSX Manager отключена. Чтобы применить TNP с помощью vSphere Configuration Profiles, необходимо также задать:

• набор правил брандмауэра с параметром DVFilter=true
• настройку Syslog с параметром remote_host_max_msg_len=4096

Снижение рисков и простоев при обновлении vCenter

Функция Reduced Downtime Update (RDU) поддерживается при использовании установщика на базе CLI. Также доступны RDU API для автоматизации. RDU поддерживает как вручную настроенные топологии vCenter HA, так и любые другие топологии vCenter. RDU является рекомендуемым способом обновления, апгрейда или установки патчей для vCenter 9.0.

Обновление vCenter с использованием RDU можно выполнять через vSphere Client, CLI или API. Интерфейс управления виртуальным устройством (VAMI) и соответствующие API для патчинга также могут использоваться для обновлений без переустановки или миграции, однако при этом потребуется значительное время простоя.

Сетевые настройки целевой виртуальной машины vCenter поддерживают автоматическую конфигурацию, упрощающую передачу данных с исходного vCenter. Эта сеть автоматически настраивается на целевой и исходной виртуальных машинах vCenter с использованием адреса из диапазона Link-Local RFC3927 169.254.0.0/16. Это означает, что не требуется указывать статический IP-адрес или использовать DHCP для временной сети.

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

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

Масштабирование объема памяти с более низкой стоимостью владения благодаря Memory Tiering с использованием NVMe

Memory Tiering использует устройства NVMe на шине PCIe как второй уровень оперативной памяти, что увеличивает доступный объем памяти на хосте ESX. Memory Tiering на базе NVMe снижает общую стоимость владения (TCO) и повышает плотность размещения виртуальных машин, направляя память ВМ либо на устройства NVMe, либо на более быструю оперативную память DRAM.

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

Функция Memory Tiering теперь доступна в производственной среде. В vSphere 8.0 Update 3 функция Memory Tiering была представлена в режиме технологического превью. Теперь же она стала доступна в режиме GA (General Availability) с выпуском VCF 9.0. Это позволяет использовать локально установленные устройства NVMe на хостах ESX как часть многоуровневой (tiered) памяти.

Повышенное время безотказной работы для AI/ML-нагрузок

Механизм Fast-Suspend-Resume (FSR) теперь работает значительно быстрее для виртуальных машин с поддержкой vGPU. Ранее при использовании двух видеокарт NVIDIA L40 с 48 ГБ памяти каждая, операция FSR занимала около 42 секунд. Теперь — всего около 2 секунд. FSR позволяет использовать Live Patch в кластерах, обрабатывающих задачи генеративного AI (Gen AI), без прерывания работы виртуальных машин.

Передача данных vGPU с высокой пропускной способностью

Канал передачи данных vGPU разработан для перемещения больших объемов данных и построен с использованием нескольких параллельных TCP-соединений и автоматического масштабирования до максимально доступной пропускной способности канала, обеспечивая прирост скорости до 3 раз (с 10 Гбит/с до 30 Гбит/с).

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

vMotion с предкопированием (pre-copy) — это технология передачи памяти виртуальной машины на другой хост с минимальным временем простоя. Память виртуальной машины (как "холодная", так и "горячая") копируется в несколько проходов пока ВМ ещё работает, что устраняет необходимость полного чекпойнта и передачи всей памяти во время паузы, во время которой случается простой сервисов.

Улучшения в предкопировании холодных данных могут зависеть от характера нагрузки. Например, для задачи генеративного AI с большим объёмом статических данных ожидаемое время приостановки (stun-time) будет примерно:

• ~1 секунда для GPU-нагрузки объёмом 24 ГБ
• ~2 секунды для 48 ГБ
• ~22 секунды для крупной 640 ГБ GPU-нагрузки

Отображение профилей vGPU в vSphere DRS

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

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

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

Администраторы теперь могут перемещать существующие библиотеки контента на новые хранилища данных (datastore) - OVF/OVA-шаблоны, образы и другие элементы могут быть перенесены. Элементы, хранящиеся в формате VM Template (VMTX), не переносятся в целевой каталог библиотеки контента. Шаблоны виртуальных машин (VM Templates) всегда остаются в своем назначенном хранилище, а в библиотеке контента хранятся только ссылки на них.

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

Служба виртуальных машин (VM Service) теперь может импортировать виртуальные машины, находящиеся за пределами Supervisor-кластера, и взять их под своё управление.

В vSphere 8 был представлен протокол Unified Data Transport (UDT) для "холодной" миграции дисков, ранее выполнявшейся с использованием NFC. UDT значительно ускоряет холодную миграцию, но вместе с повышенной эффективностью увеличивается и нагрузка на сеть предоставления ресурсов (provisioning network), которая в текущей архитектуре использует общий канал с критически важным трафиком управления.

Чтобы предотвратить деградацию трафика управления, необходимо использовать Network I/O Control (NIOC) — он позволяет гарантировать приоритет управления даже при высокой сетевой нагрузке.

vSphere Distributed Switch 9 добавляет отдельную категорию системного трафика для provisioning, что позволяет применять настройки NIOC и обеспечить баланс между производительностью и стабильностью.

Provisioning/NFC-трафик (включая Network File Copy) является тяжеловесным и низкоприоритетным, но при этом использует ту же категорию трафика, что и управляющий (management), который должен быть легковесным и высокоприоритетным. С учетом того, что трафик provisioning/NFC стал ещё более агрессивным с внедрением NFC SOV (Streaming Over vMotion), вопрос времени, когда критически важный трафик управления начнёт страдать.

Существует договоренность с VCF: как только NIOC для provisioning/NFC будет реализован, можно будет включать NFC SOV в развёртываниях VCF. Это ускорит внедрение NFC SOV в продуктивных средах.

Устройства, которые не могут быть приостановлены (non-stunnable devices), теперь поддерживают Storage vMotion (но не обычный vMotion), а также горячее добавление виртуальных устройств, таких как:

• vCPU
• Память (Memory)
• Сетевые адаптеры (NIC)

Примеры non-stunnable устройств:

• Intel DLB (Dynamic Load Balancer)
• AMD MI200 GPU

Гостевые ОС и рабочие нагрузки

Виртуальное оборудование версии 22 (Virtual Hardware Version 22)

• Увеличен лимит vCPU до 960 на одну виртуальную машину
• Поддержка новейших моделей процессоров от AMD и Intel
• Поддержка новых версий гостевых ОС для развертывания ВМ (см. Guest OS Support в VCF 9.0)

Виртуальный модуль доверенной платформы (vTPM)

• vTPM теперь поддерживает спецификацию TPM 2.0, версия 1.59.
• ESX 9.0 соответствует TPM 2.0 Rev 1.59.
• Это повышает уровень кибербезопасности, когда вы добавляете vTPM-устройство в виртуальную машину с версией 22 виртуального железа.

Новые vAPI для настройки гостевых систем (Guest Customization)

Представлен новый интерфейс CustomizationLive API, который позволяет применять спецификацию настройки (customization spec) к виртуальной машине в работающем состоянии (без выключения). Подробности — в последней документации по vSphere Automation API для VCF 9.0. Также добавлен новый API для настройки гостевых систем, который позволяет определить, можно ли применить настройку к конкретной ВМ, ещё до её применения.

• Namespace Write Protection - позволяет горячее добавление независимых непостоянных (non-persistent) дисков в виртуальную машину без создания дополнительных delta-дисков. Эта функция особенно полезна для рабочих нагрузок, которым требуется быстрое развёртывание приложений.
• Write Zeros - для виртуальных NVMe-дисков улучшает производительность, эффективность хранения данных и дает возможности управления данными для различных типов нагрузок.

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

Одним из частых запросов в последние годы была возможность использовать собственные сертификаты Secure Boot для ВМ. Обычно виртуальные машины работают "из коробки" с коммерческими ОС, но некоторые организации используют собственные ядра Linux и внутреннюю PKI-инфраструктуру для их подписи.

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

Обновлён список отозванных сертификатов Secure Boot

VMware обновила стандартный список отозванных сертификатов Secure Boot, поэтому при установке Windows на виртуальную машину с новой версией виртуального оборудования может потребоваться современный установочный образ Windows от Microsoft. Это не критично, но стоит иметь в виду, если установка вдруг не загружается.

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

Обычно мы стремимся к тому, чтобы снапшот ВМ можно было запустить повторно и обеспечить согласованность при сбое (crash-consistency), то есть чтобы система выглядела как будто питание отключилось. Большинство ОС, СУБД и приложений умеют с этим справляться.

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

Теперь вы можете создавать собственный профиль EVC (Enhanced vMotion Compatibility), определяя набор CPU- и графических инструкций, общих для всех выбранных хостов. Это решение более гибкое и динамичное, чем стандартные предустановленные профили EVC.

Custom EVC позволяет:

• Указать хосты и/или кластеры, для которых vCenter сам рассчитает максимально возможный общий набор инструкций
• Применять полученный профиль к кластерам или отдельным ВМ

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

• CPU-1 содержит функции A, B, D, E, F
• CPU-2 содержит функции B, C, D, E, F
• То есть: CPU-1 поддерживает FEATURE-A, но не FEATURE-C, CPU-2 — наоборот.

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

В vSphere 9 появилась новая политика вычислений: «Limit VM placement span plus one host for maintenance» («ограничить размещение ВМ числом хостов плюс один для обслуживания»).

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

Больше не нужно вручную закреплять ВМ за хостами или создавать отдельные кластеры/хосты. Теперь администратору нужно просто:

1. Знать, сколько лицензий куплено.
2. Знать, на скольких хостах они могут применяться.
3. Создать политику с указанием числа хостов, без выбора конкретных.
4. Применить эту политику к ВМ с нужным тегом.

vSphere сама гарантирует, что такие ВМ смогут запускаться только на разрешённом числе хостов. Всегда учитывается N+1 хост в запас для обслуживания. Ограничение динамическое — не привязано к конкретным хостам.

Полный список новых возможностей VMware vSphere 9 также приведен в Release Notes.

Хорошая новость для энтузиастов облачных технологий! Готовы значительно прокачать свои навыки? С выходом VMware Cloud Foundation 9.0 появились новые интерактивные лабораторные работы (Hands-on Labs, HoL), доступные для самостоятельного изучения! Они специально созданы для того, чтобы быстро и эффективно освоить VCF 9.0 и входящие в ее состав новые версии продуктов.

Вот список новых лабораторий, доступных прямо сейчас:

• Что нового в VMware Cloud Foundation 9.0 – платформа (HOL-2610-01-VCF-L)
  Изучите VCF 9.0! Узнайте основные концепции VCF, развертывание с помощью VCF Installer и увеличьте продуктивность с виртуальными частными облаками (VPC) и транзитными шлюзами.
• Что нового в VMware Cloud Foundation 9.0 – автоматизация (HOL-2610-02-VCF-L)
  Эта лаба поможет освоить автоматизацию VMware Cloud Foundation, начиная с быстрой настройки организаций арендаторов. Изучите портал провайдера (инфраструктура, доступ, идентификация) и управление организацией (библиотеки контента, политики IaaS). Получите практический опыт развёртывания виртуальных машин и кластеров Kubernetes.
• Что нового в VMware Cloud Foundation 9.0 – операции (HOL-2610-03-VCF-L)
  Эта лаба охватывает мониторинг состояния частного облака, анализ сетевого трафика, управление хранилищами и vSAN, операции безопасности и реализацию подсчёта затрат. Получите практические навыки единого мониторинга, устранения неполадок и внедрения лучших практик для эффективного управления, защиты и оптимизации вашего частного облака.
• Объединённое управление виртуальными машинами и Kubernetes с помощью vSphere Supervisor в VMware Cloud Foundation 9.0 (HOL-2633-01-VCF-L)
  Эта лаба научит объединённому управлению виртуальными машинами и кластерами Kubernetes с помощью vSphere Supervisor. Изучите концепции и компоненты vSphere Supervisor, включая взаимодействие с vCenter и vSphere. Включите и настройте vSphere Supervisor и разверните кластеры Kubernetes и vSphere POD вместе с виртуальными машинами.
• Что нового в vSphere на платформе VMware Cloud Foundation 9.0 (HOL-2630-01-VCF-L)
  Лаба охватывает упрощённое единое лицензирование, улучшенное многоуровневое использование памяти, онлайн-обновление без простоев, управление мультивендорными кластерами и улучшения Lifecycle Manager, сокращающие административную нагрузку благодаря образам уровня кластера.

Hands-on Labs зарекомендовали себя как ценный ресурс для обучения:

• Доступны и бесплатны: изучайте передовые облачные технологии совершенно бесплатно.
• Гибкость в обучении: выбирайте свой темп и график.
• Онлайн-доступ 24/7: пользуйтесь лабораториями в любое время и из любого места.
• Без необходимости установки: сразу приступайте к обучению, не тратя время на установку или настройку программного обеспечения.
• Повторяемость лабораторий: закрепляйте полученные знания, повторяя лаборатории столько раз, сколько пожелаете.
• Изучайте в собственном темпе: проходите материалы в удобном для вас ритме для лучшего усвоения информации.
• Практический опыт: получайте реальные навыки в интерактивных условиях с использованием VMware Cloud Foundation 9.0 и других продуктов VMware.

Нажмите сюда, чтобы получить доступ к каталогу лабораторий VMware Cloud Foundation 9.0 и начать своё обучение.

Многоуровневая память (Memory Tiering) снижает затраты и повышает эффективность использования ресурсов. Эта функция была впервые представлена в виде технологического превью в vSphere 8.0 Update 3 и получила очень положительные отзывы от клиентов. Обратная связь от пользователей касалась в основном устойчивости данных, безопасности и гибкости в конфигурациях хостов и виртуальных машин. С выходом платформы VCF 9.0 все эти вопросы были решены.

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

В компании Broadcom было проведено масштабное внутреннее тестирование, которое показало, что использование многоуровневой памяти позволяет сократить совокупную стоимость владения (TCO) до 40% для большинства рабочих нагрузок, а также обеспечивает рост загрузки CPU, позволяя использовать на 25–30% больше ядер под задачи. Меньше затрат — больше ресурсов. Кроме того, лучшая консолидация ВМ может означать меньше серверов или больше ВМ на каждом сервере.

Многоуровневая память обеспечивает все эти и многие другие преимущества, используя NVMe-устройства в качестве второго уровня памяти. Это позволяет увеличить объём доступной памяти до 4 раз, задействуя при этом существующие слоты сервера для недорогих устройств, таких как NVMe. Между предварительной технической версией и готовым к промышленному использованию выпуском с VCF 9.0 существует множество важных отличий. Давайте рассмотрим эти улучшения.

Новые возможности Advanced Memory Tiering

Смешанный кластер

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

Резервирование

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

Поддержка DRS

Технология DRS (Distributed Resource Scheduler) существует уже довольно давно, это одна из функций, без которой большинство клиентов уже не могут обходиться. VMware вложила много усилий в то, чтобы сделать алгоритм Memory Tiering «умным» — чтобы он не только анализировал состояние страниц памяти, но и эффективно управлял ими в пределах кластера.

DRAM:NVMe — новое соотношение

В vSphere 8.0 U3 функция Memory Tiering была представлена как технологическое превью. Тогда использовалось соотношение 4:1, то есть на 4 части DRAM приходилась 1 часть NVMe. Это дало увеличение объёма памяти на 25%. Хотя это может показаться незначительным, при сравнении стоимости увеличения объёма памяти на 25% с использованием DRAM и NVMe становится очевидно, насколько это выгодно.

В VCF 9.0, после всех улучшений производительности, изменили соотношение по умолчанию: теперь оно 1:1 — то есть увеличение объема памяти в 2 раза по умолчанию. И это значение можно настраивать в зависимости от нагрузки и потребностей. То есть, если у вас есть хост ESX с 1 ТБ DRAM и вы включаете Memory Tiering, вы можете получить 2 ТБ доступной памяти. Для некоторых сценариев, таких как VDI, возможно соотношение до 1:4 — это позволяет вчетверо увеличить объём памяти при минимальных затратах.

Другие улучшения

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

Как начать использовать Advanced Memory Tiering

С чего начать? Как понять, подходят ли ваши рабочие нагрузки для Memory Tiering? Клиентам стоит учитывать следующие факторы при принятии решения о внедрении Memory Tiering:

Активная память

Memory Tiering особенно подходит для клиентов с высоким потреблением (выделено под ВМ более 50%) и низким уровнем активного использования памяти (фактически используемая нагрузками — менее 50% от общего объема DRAM).

Скриншот ниже показывает, как можно отслеживать активную память и объём DRAM с помощью vCenter:

NVMe-устройства

Существуют рекомендации по производительности и ресурсу для поддерживаемых накопителей — в руководстве по совместимости Broadcom (VMware) указано более 1500 одобренных моделей. NVMe-накопители, такие как E3.S, являются модульными и зачастую могут быть установлены в свободные слоты серверов, например, как в Dell PowerEdge, показанном ниже. VMware настоятельно рекомендует клиентам обращаться к руководству по совместимости Broadcom, чтобы обеспечить нужный уровень производительности своих рабочих нагрузок за счёт выбора рекомендованных устройств.

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

Недавно мы рассказали об улучшениях и нововведениях платформы VMware Cloud Foundation 9.0, включающей в себя платформу виртуализации VMware vSphere 9.0 и средство создания отказоустойчивой инфраструктуры хранения VMware vSAN 9.0. Посмотрим теперь, что нового эти продукты включают с точки зрения сервисов хранилищ (Core Storage).

Улучшения поддержки хранилищ VCF

Для новых (greenfield) развёртываний VCF теперь поддерживаются хранилища VMFS, Fibre Channel и NFSv3 в качестве основных вариантов хранилища для домена управления. Полную информацию о поддержке хранилищ см. в технической документации VCF 9.

Улучшения NFS

Поддержка TRIM для NFS v3

Существующая поддержка команд TRIM и UNMAP позволяет блочным хранилищам, таким как vSAN и хранилища на базе VMFS, освобождать место после удаления файлов в виртуальной машине или при многократной записи в один и тот же файл. В типичных средах это позволяет освободить до 30% пространства, обеспечивая более эффективное использование ёмкости. С использованием плагина VAAI NFS системы NAS, подключённые через NFSv3, теперь могут выполнять освобождение пространства в VCF 9.

Шифрование данных в процессе передачи для NFS 4.1

Krb5p шифрует трафик NFS при передаче. Шифрование данных «на лету» защищает данные при передаче между хостами и NAS, предотвращая несанкционированный доступ и обеспечивая конфиденциальность информации организации, особенно в случае атак типа «man-in-the-middle». Также будет доступен режим Krb5i, который не выполняет шифрование, но обеспечивает проверку целостности данных, исключая их подмену.

Улучшения базовой подсистемы хранения

Сквозная (End-to-End, E2E) поддержка 4Kn

В версии 9.0 реализована поддержка E2E 4Kn, включающая:

• Фронтэнд — представление виртуальных дисков (VMDK) с сектором 4K для виртуальных машин.
• Бэкэнд — использование SSD-накопителей NVMe с 4Kn для vSAN ESA. OSA не поддерживает 4Kn SSD.
• ESXi также получает поддержку 4Kn SSD с интерфейсом SCSI для локального VMFS и внешних хранилищ.

SEsparse по умолчанию для снимков с NFS и VMFS-5

Исторически, создание снимков (snapshots) имело значительное влияние на производительность ввода-вывода.
Формат Space Efficient Sparse Virtual Disks (SEsparse) был разработан для устранения двух основных проблем формата vmfsSparse:

1. Освобождение пространства при использовании снимков — SEsparse позволяет выполнять более точную и настраиваемую очистку места, что особенно актуально для VDI-сценариев.

2. Задержки чтения и снижение производительности из-за множественных операций чтения при работе со снимками.

Производительность была повышена благодаря использованию вероятностной структуры данных, такой как Bloom Filter, особенно для снимков первого уровня. Также появилась возможность настраивать размер блока (grain size) в SEsparse для соответствия типу используемого хранилища.

SEsparse по умолчанию применяется к VMDK объёмом более 2 ТБ на VMFS5, начиная с vSphere 7 Update 2. В vSphere 9 SEsparse становится форматом по умолчанию для всех VMDK на NFS и VMFS-5, независимо от размера. Это уменьшит задержки и увеличит пропускную способность чтения при работе со снимками. Формат SEsparse теперь также будет использоваться с NFS, если не используется VAAI snapshot offload plugin.

Поддержка спецификации vNVMe 1.4 — команда Write Zeroes

С выходом версии 9.0 поддержка NVMe 1.4 в виртуальном NVMe (vNVMe) позволяет гостевой ОС использовать команду NVMe Write Zeroes — она устанавливает заданный диапазон логических блоков в ноль. Эта команда аналогична SCSI WRITE_SAME, но ограничена только установкой значений в ноль.

Поддержка нескольких соединений на сессию iSCSI (Multiple Connections per Session)

Рекомендуется использовать iSCSI с Multi-path I/O (MPIO) для отказоустойчивого подключения к хостам. Это требует отдельных физических путей для каждого порта VMkernel и отказа от использования failover на базе состояния соединения или агрегацию сетевых интерфейсов (NIC teaming) или Link Aggregation Group (LAG), поскольку такие методы не обеспечивают детерминированный выбор пути.

Проблема: iSCSI традиционно использует одиночное соединение, что делает невозможным распределение трафика при использовании NIC teaming или LAG.

Решение — iSCSI с несколькими соединениями в рамках одной сессии, что позволяет:

1. Использовать несколько каналов, если один порт VMkernel работает в составе LAG с продвинутыми алгоритмами хеширования.

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

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

Выведенные из эксплуатации технологии

• Устаревание NPIV

Как VMware предупреждала ранее, технология N-Port ID Virtualization (NPIV) была признана устаревшей и в версии 9.0 больше не поддерживается.

• Устаревание гибридной конфигурации в оригинальной архитектуре хранения vSAN (OSA)

Гибридная конфигурация в vSAN Original Storage Architecture будет удалена в одном из будущих выпусков платформы VCF.

• Устаревание поддержки vSAN over RDMA

Поддержка vSAN поверх RDMA для архитектуры vSAN OSA также будет прекращена в будущем выпуске VCF.

• Устаревание поддержки RVC и зависимых Ruby-компонентов

Начиная с версии VCF 9.0, Ruby vSphere Console (RVC) и её компоненты на базе Ruby (такие как Rbvmomi) в составе vCenter считаются устаревшими. RVC, ранее использовавшаяся технической поддержкой для тестирования и мониторинга систем, уже была признана устаревшей, начиная с vSAN 7.0.

Для задач мониторинга и сопровождения Broadcom рекомендует использовать PowerCLI, DCLI или веб-интерфейс vCenter (UI), поскольку они теперь предоставляют весь функционал, ранее доступный в RVC. RVC и все связанные с ней Ruby-компоненты будут окончательно удалены в одном из будущих выпусков VCF.

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

Тенденции отрасли и вызовы для клиентов

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

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

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

Инфраструктурная фрагментация и гибридное облако

Рост объёма данных и внедрение новых интерфейсов усугубляется фрагментацией инфраструктуры, вызванной активным переходом к гибридным облачным стратегиям. По недавнему исследованию компании Broadcom, 92% организаций используют смесь частных и публичных облаков. Это означает, что данные и рабочие нагрузки распределены между локальными датацентрами, периферийными (edge) точками и публичными облаками. В результате появляется множество уникальных архитектур на базе точечных решений, которые трудно масштабировать и поддерживать. ИТ-отделам нужен единый подход к хранению данных и операциям с ними во всех средах, чтобы снизить сложность.

Какие рабочие нагрузки вызывают этот рост данных и требуют новых интерфейсов?

AI-задачи предъявляют совершенно новые требования к инфраструктуре хранения. Как прогнозирующий AI (уже широко используемый), так и генеративный AI (стремительно набирающий популярность) зависят от быстрого и надёжного доступа к огромным объёмам данных. Даже такие специфические рабочие нагрузки, как RAG (Retrieval Augmented Generation), нуждаются в хранилищах с высокой производительностью и низкой задержкой — гораздо выше, чем у традиционных систем на жёстких дисках, где сейчас хранятся многие AI-данные. Более того, AI-среды требуют прямого, высокоскоростного доступа к хранилищам с GPU, в обход узких мест, связанных с CPU, чтобы обрабатывать данные с минимальной задержкой.

Контейнеры, хранилище и скорость разработки

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

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

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

Наконец, киберустойчивость остаётся в приоритете. Программы-вымогатели (ransomware) по-прежнему представляют серьёзную угрозу: в 2023 году две трети организаций подверглись атакам, и более 75% таких случаев сопровождались шифрованием данных. Кибербезопасность регулярно занимает первые места среди главных проблем CIO.

Стратегия хранения данных VMware и современные решения

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

Снижение стоимости хранения

VMware уделяет особое внимание снижению затрат, что особенно важно для клиентов. VMware Cloud Foundation включает 1 TiB хранилища vSAN на одно ядро в своей лицензионной модели, что позволило клиентам сократить среднюю стоимость хранения на 30%, а в отдельных случаях — снизить TCO более чем на 40% по сравнению с традиционными массивами с контроллерами.

Дополнительно, VMware снижает расходы за счёт поддержки сертифицированных стандартных серверов: более 500 конфигураций vSAN ReadyNode от 15 OEM-производителей. Это в среднем снижает стоимость хранения на 46% за терабайт. Масштабируемая гиперконвергентная архитектура устраняет неиспользуемую ёмкость, типичную для масштабируемых систем (scale-up), а серверный подход позволяет существенно сократить затраты на поддержку и управление. В итоге заказчики получают высокопроизводительное, устойчивое хранилище для критически важных задач — без высокой стоимости устаревших решений.

С выпуском VCF 9.0 VMware представила глобальную дедупликацию на программном уровне, которая позволяет дополнительно сократить объём хранимых данных вплоть до 8 раз, что особенно актуально при росте объёма информации.

Новая дедупликация vSAN:

• Имеет минимальную нагрузку на CPU
• Работает в фоновом режиме, когда системные ресурсы не загружены
• Охватывает все данные в кластере, а не только данные за одним контроллером, как в традиционных системах
• Масштабируется вместе с кластером, что даёт более высокую эффективность

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

Хранилище с низкой задержкой для AI-нагрузок

AI-задачи предъявляют повышенные требования к инфраструктуре, и vSAN соответствует этим требованиям благодаря архитектуре Express Storage Architecture (ESA) нового поколения. На сегодняшний день vSAN ESA обеспечивает:

• До 300 000 IOPS на узел.
• Постоянную задержку менее 1 мс, даже при пиковых нагрузках.
• Линейный рост производительности и ёмкости по мере масштабирования кластера — в отличие от традиционного хранилища, где масштабируется только ёмкость.
• Гибкость при сбоях: недавние тесты показали на 60% меньшую задержку в аварийных сценариях по сравнению с классическими системами.

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

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

Программно-определяемое хранилище для любых рабочих нагрузок

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

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

Автоматизация VCF

VCF Automation (VCF-A) в VCF 9.0 предоставляет простой способ предоставления томов для различных арендаторов, использующих хранилище как для ВМ, так и для постоянных томов в Kubernetes-среде VMware (VKS).

В будущем VMware планирует развивать многопользовательские сценарии и инфраструктуру как услугу (IaaS), чтобы дать разработчикам быстрый доступ к ресурсам при сохранении корпоративного контроля.

Единая модель управления хранилищем для локальных, периферийных и облачных сред

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

VCF 9.0 включает важные инновации в управлении хранилищем:

• Автоматическое развертывание, масштабирование и обновление инфраструктуры на базе vSAN
• Единая консоль для всей VCF-инфраструктуры (vSAN, VMFS, NFS)
• Уведомления о состоянии, рекомендации и пошаговое устранение проблем
• Поддержка мультисайтовых сред для единого мониторинга.

В ближайшее время облачные партнёры внедрят vSAN ESA (Express Storage Architecture) в свои стеки VCF: VMware Cloud Foundation на AWS, Google Cloud VMware Engine и Azure VMware Solution добавят поддержку ESA.

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

Их распространённость остаётся низкой (единицы процентов), и они остаются нишевым решением. VMware по-прежнему будет поддерживать внешние хранилища через VMFS и NFS.

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

Безопасность и устойчивость — основа vSAN, особенно важная для пользователей VCF. С выпуском vSAN 8.0 появилась новая система моментальных снимков (снапшотов), а в vSAN 8 Update 3 — встроенная защита данных, позволяющая администраторам легко защищать ВМ от случайных или вредоносных действий (например, удаления или атак программ-вымогателей).

Это реализуется через группы защиты, где можно задать, что защищать, как часто и как долго, с поддержкой неизменяемых снапшотов и шифрованием (FIPS 140-3) как для хранимых, так и передаваемых данных.

В VCF 9.0 добавлена репликация vSAN-to-vSAN, основанная на защите данных vSAN. Она позволяет удалённо реплицировать снапшоты на любое хранилище vSAN ESA — как гиперконвергентное, так и разнесённое.

Эта асинхронная репликация:

• Дешевле и быстрее традиционной массивной репликации
• Позволяет восстанавливать отдельные ВМ, а не целые LUN
• Требует меньше места и меньше трафика
• Значительно упрощает восстановление, переключение и возврат свободного места

Также репликация интегрирована с VMware Live Recovery (VLR) для восстановления после кибератак и аварий. VCF 9.0 поддерживает кибервосстановление в изолированную зону внутри локального VCF, что важно для соблюдения требований суверенитета и конфиденциальности данных.

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

В перспективе будет реализована функция Intelligent Threat Detection — AI/ML-алгоритмы для превентивной защиты, раннего обнаружения и анализа зашифрованных копий.

Унифицированное хранилище для всех типов данных

Клиенты давно хотят единую платформу хранения для всех задач, а не отдельные решения для блочного, файлового и объектного хранилища, что создаёт избыточную сложность. vSAN изначально предлагает блочное хранилище, а с 2019 года — встроенные файловые сервисы. VCF 9.0 расширяет их масштабируемость: теперь до 500 файловых ресурсов на кластер.

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

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

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

Благодаря единым операциям во всех средах (edge, core, облако) и ведущим в отрасли возможностям киберустойчивости, vSAN становится фундаментом современного частного облака.

VMware продолжает инвестировать в инновации, чтобы:

• Снижать TCO
• Упрощать многосайтовые операции
• Ускорять работу разработчиков
• Масштабировать AI во всей инфраструктуре

Компания VMware объявила о том, что обновленная версия платформы VMware Cloud Foundation 9.0 теперь доступна для пользователей. Напомним, что ее анонс состоялся еще в августе прошлого года.

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

Современные рабочие нагрузки, особенно в сфере AI и обработки данных, диктуют новую реальность. Датасеты размером в петабайты невозможно просто так перемещать между регионами. Законодательные требования всё чаще обязывают размещать критически важные рабочие нагрузки в пределах национальных границ. А шок от реальных затрат в модели облака pay-as-you-go раздражают финансовые отделы по всей индустрии.

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

Если всё сделано правильно, частное облако:

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

Впервые VMware приоткрыла завесу над VCF 9.0 на мероприятии VMware Explore в прошлом году. С тех пор компания провела ее испытания в реальных условиях, а также воркшопы по проектированию внедрений с множеством клиентов. Результат — релиз, ставший следующим крупным шагом на пути частного облака VMware. За 25 лет со времени изобретения гипервизора VMware Cloud Foundation опирается на долгую историю инноваций компании.

Фундаментальный сдвиг в VMware Cloud Foundation 9.0

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

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

• Один интерфейс для управления частным облаком — контроль состояния, установка обновлений и соблюдение требований соответствия по всей инфраструктуре из одной консоли, чтобы операционные решения основывались на едином источнике доверия.
• Один интерфейс для облачного пользовательского опыта — разработчики взаимодействуют с единой конечной точкой для инфраструктуры как кода (IaC): через Terraform-провайдеры, REST API или VCF Automation Blueprints — без необходимости использовать дополнительные модули.
• Запуск ВМ и контейнеров/K8s — запускайте виртуальные машины с производительностью, близкой к bare metal, и полностью управляемые кластеры Kubernetes в одной среде. Интеграция с Argo CD и встроенные CI/CD-механизмы позволяют доставлять контейнерный код из репозитория в продакшн без внешней обвязки.
• Суверенность и безопасность как платформа — теги территориальной принадлежности данных, гео-политики и автоматическая ротация сертификатов теперь могут быть частью каждой спецификации кластера. Суверенность — это не просто модное слово, это возможность развертывания с рамками контроля, понимание того, где находятся данные, способность управлять ими, защищать их и обеспечивать постоянное соответствие каждого кластера суверенным требованиям.
• Встроенный контроль затрат — механизмы перераспределения и демонстрации затрат, а также панели управления стоимостью и прогнозированием превращают потребление ресурсов в готовые к выставлению счета с цифрами для каждого арендатора или бизнес-единицы. Это не просто showback — это возможность для бизнес-лидеров планировать бюджеты, вводить ограничения, заключать договоры и масштабировать инфраструктуру, опираясь на прозрачную аналитику расходов, основанную на фактическом потреблении.

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

Что нового в VCF 9.0: прорывы платформы с реальными результатами

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

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

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

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

Инновации в ядре

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

• Расширенное многоуровневое использование памяти NVMe — движки высокочастотной торговли, аналитика в оперативной памяти и приложения, активно использующие JVM, сталкиваются с одной и той же проблемой: память DRAM дорогая и ограниченная. VCF 9.0 позволяет расширить пул памяти за счёт NVMe — используя быструю флеш-память как второй, более доступный по стоимости уровень. Вычислительно-интенсивные нагрузки сохраняют активные данные рядом с CPU, в то время как «холодные» страницы переносятся на NVMe, освобождая DRAM для тех задач, которым она действительно нужна. В результате вы можете запускать больше виртуальных машин или контейнеров на каждом узле без необходимости увеличивать бюджет на оборудование.
• Глобальная дедупликация в vSAN — флеш-память остаётся ключевым драйвером стоимости в большинстве частных облаков. Теперь глобальная дедупликация на уровне блоков охватывает не только диски, но и целые кластеры, устраняя дубликаты данных один раз и распространяя экономию повсюду. Это позволяет защищать и обслуживать большие объёмы данных на том же объёме флеш-хранилища — и делать это без потери производительности, как это часто бывает с механизмами постобработки дедупликации.
• Улучшенные пути передачи данных — задержки — это своеобразный «налог» на трафик east-west в рамках интенсивно использующих сеть рабочих нагрузок, особенно в пайплайнах AI и микросервисных сетках. Новые оптимизации ядра и возможность offload'а нагрузки на DPU значительно снижают этот налог. Пакеты дольше остаются на хосте, проходят меньше сетевых коммутаторов, что означает более быструю обработку запросов на инференс и стабильное время отклика API даже при росте плотности кластера. Во многих случаях это и есть разница между необходимостью обновлять spine-leaf архитектуру в этом году или можно отложить до следующего.

Но дело не только в новых функциях. Ядро VCF 9.0 идеально соответствует целям по повышению эффективности и снижению затрат. Вот лишь некоторые впечатляющие показатели, которые вы увидите при развёртывании инфраструктуры на VCF 9.0:

Возможности современной инфраструктуры

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

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

Теперь кратко о некоторых функциях из категории современная инфраструктура:

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

Унифицированный облачный опыт

Если модернизация инфраструктуры — это, в первую очередь, о «простой в работе», современной, производительной и масштабируемой среде, то унифицированный облачный опыт фокусируется на том, чтобы предоставить вам удобство публичного облака с надёжными ограничителями и комфортом частного развертывания. И снова — наша цель? — единое, сквозное управление автоматизацией через единую панель.

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

Независимо от того, создаёте ли вы каталог самообслуживания для своих бизнес-заказчиков или просто работаете с инфраструктурой как кодом (IaC), в центре всего находится среда VCF Automation. Используйте шаблоны (blueprints) для создания, копирования и последовательного развертывания инфраструктурных ресурсов — и начните говорить с разработчиками на одном языке.

• VCF Automation Consumption Experience — единый открытый API (плюс поддержка Terraform и GitOps) обрабатывает все запросы на развёртывание, включая политики и метки стоимости — это дает скорость самообслуживания без потери управляемости.
• Упрощённое облачное сетевое взаимодействие и потребление VPC — команды просто описывают VPC в коде, а маршрутизация, балансировка и безопасность настраиваются автоматически — без глубокого погружения в сетевой стек и без тикет-систем.
• Готовые шаблоны для самообслуживания, IaC и управления кластерами VKS — преднастроенные blueprints для баз данных, AI-стеков и кластеров Kubernetes запускаются за считаные минуты; команды подставляют параметры, нажимают «развернуть» — и получают готовое к аудиту, согласованное окружение.

Безопасность и устойчивость

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

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

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

• Панель управления операциями безопасности (Security Operations Dashboard) — единая консоль, которая совмещает в себе интерактивные карты атакующей поверхности и оценки соответствия требованиям в реальном времени. Это даёт SecOps-команде единое место для обнаружения уязвимостей, приоритизации патчей и проверки устранения проблем — ещё до того, как это сделает аудитор.
• Соответствие конфигурации и мониторинг — постоянные сканирования, сравнивающие параметры времени выполнения с эталонами CIS, NIST и пользовательскими профилями. Отклонения выявляются сразу при появлении, и (где это допускается политиками) автоматически исправляются — так что аудит становится просто проверкой, а не пожарной тревогой.
• Управление идентификацией и сертификатами — федерация идентификаций по всей платформе, автоматическая выдача и ротация сертификатов избавляют от ручного управления доверием, предотвращают аврал из-за просроченных сертификатов и обеспечивают бесшовный SSO для всех доменов рабочей нагрузки.

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

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

• Эффективный запуск современных, AI и традиционных приложений с vSphere в VMware Cloud Foundation 9.0
• Модернизация хранения с помощью VMware vSAN в VMware Cloud Foundation 9.0
• Сетевые возможности VMware Cloud Foundation 9.0: переосмысление облачной операционной модели для частных облаков
• Переосмысленное частное облако: единый опыт облачного потребления с VMware Cloud Foundation 9.0
• Операции в VMware Cloud Foundation 9.0: современный способ построения и управления частным облаком
• Kubernetes в VMware Cloud Foundation 9.0: единая платформа для безопасного запуска рабочих нагрузок с упрощённым управлением
• VMware Cloud Foundation 9.0: модернизация инфраструктуры, ускорение доставки приложений и усиление безопасности и устойчивости

Расширенные сервисы:

• DBaaS для частного облака: VMware Data Services Manager для VCF 9.0
• VMware Private AI Foundation с NVIDIA: откройте потенциал AI с VMware Cloud Foundation 9.0
• Сохранение суверенитета данных и усиленная защита от кибератак с VMware Cloud Foundation 9.0

ROSA Virtualization — это отечественная платформа для управления виртуальной серверной инфраструктурой, разработанная АО «НТЦ ИТ РОСА». Она построена на базе открытого программного обеспечения (KVM, libvirt и др.) и предназначена для развёртывания отказоустойчивых, масштабируемых и защищённых виртуализованных сред.

• Создание и управление виртуальными машинами
• Настройка виртуальных сетей и хранилищ
• Кластеры высокой доступности (HA)
• Живая миграция ВМ между хостами
• Резервное копирование и восстановление
• Централизованное управление через веб-интерфейс
• Поддержка требований по безопасности и соответствие ГОСТ
• Сертификация для использования в госорганах

Главные изменения ROSA Virtualization 3.1 (релиз 27 мая 2025 года)

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

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

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

Добавлена визуализация сетевой схемы, мастер настройки NFS, улучшен интерфейс бэкапов (включительно поддержка СУСВ через веб), а также адаптация событий под требования ГОСТ.

Нововведения включают поддержку Loudplay (протокол для передачи консольных данных) и адаптацию событийной логики в соответствии с ГОСТ-стандартами.

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

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

• Упрощение управления: привычные интерфейсы GUI значительно снижают порог входа для операторов и системных администраторов.
• Надёжность и масштабируемость: интеграция с Ceph обеспечивает отказоустойчивую, распределённую архитектуру хранения.
• Бесшовность и доступность: живая миграция и автозапуск ВМ минимизируют время простоя.
• Безопасность и соответствие: ГОСТ-адаптация и сертификация ФСТЭК делают решение готовым к внедрению в государственных структурах и критически важной инфраструктуре.

Кому подойдёт ROSA Virtualization 3.1

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

ROSA Virtualization 3.1 — зрелое отечественное решение для виртуализации, сочетающее:

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

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

Недавно вышла новая версия VMware Tanzu Greenplum v7.5, которая уже доступна и предлагает повышенную производительность и меньшие затраты ресурсов при обработке сложных рабочих нагрузок, включая аналитические запросы, машинное обучение, потоковую загрузку данных в реальном времени и геопространственные запросы.

VMware Tanzu Greenplum — один из ключевых компонентов портфеля VMware Tanzu Data — представляет собой мощную платформу для хранилищ данных и аналитики, основанную на открытом исходном коде PostgreSQL. Она предназначена для масштабной агрегации и анализа больших объёмов данных. Tanzu Greenplum идеально подходит для организаций с высокой степенью регулирования и критически важными задачами, которым необходимо обрабатывать данные из множества источников и разных типов, чтобы ускорить принятие решений за счёт более эффективной агрегации, анализа и использования ключевых информационных активов.

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

Оптимизатор GPORCA теперь охватывает более широкий спектр пользовательских запросов, а выполнение запросов в Tanzu Greenplum было улучшено для ускорения операций с таблицами, оптимизированными на добавление (Append Optimized, AO).

Обновлённые команды обслуживания ANALYZE и VACUUM снижают нагрузку на систему, обеспечивая более эффективное использование платформы. Greenplum Streaming Server (GPSS) теперь поддерживает масштабируемую архитектуру, способную обрабатывать большие объёмы данных из Apache Kafka и VMware Tanzu RabbitMQ. Компонент gpMLBot автоматизирует машинное обучение с тонкой настройкой гиперпараметров, сокращая время обучения моделей. Также включены расширения для геопространственного анализа: pgPointCloud, 3DCityDB, pgRouting, H3 Index и геокодирование TIGER, что открывает новые сценарии использования.

Ускоренное выполнение запросов

GPORCA в новой версии создаёт планы выполнения запросов с меньшим использованием памяти и более эффективным порядком объединения таблиц. Он поддерживает расширенные возможности SQL, такие как подзапросы по нескольким столбцам, ROW-выражения и оконные агрегаты с квалификатором DISTINCT, ускоряя выполнение сложных запросов. Движок выполнения запросов использует усовершенствования TupleTableSlot, включая частичную и отложенную десериализацию, что снижает нагрузку на CPU. В результате операции с AO-таблицами выполняются до двух раз быстрее, чем в предыдущих версиях.

Сжатые AO-таблицы теперь поддерживают чисто индексное сканирование, устраняя необходимость в дорогостоящих bitmap-сканах. Это обеспечивает значительный прирост производительности, включая ускоренные запросы ORDER BY с LIMIT, более быстрые pg_vector-запросы и более эффективные объединения и агрегирования, делая Tanzu Greenplum подходящей платформой для аналитических нагрузок.

Упрощённое обслуживание и эксплуатация

Процесс ANALYZE в v7.5 стал более эффективным: он пропускает неизменённые партиции и объединяет статистику, уменьшая использование ресурсов и время обслуживания. Это обеспечивает более актуальные статистические данные для планирования запросов без ущерба для производительности системы. Операции COPY, VACUUM и CREATE INDEX для широких таблиц теперь требуют меньше ресурсов CPU благодаря новым оптимизациям десериализации. Инструмент gprecoverseg теперь поддерживает выборочное восстановление сегментов, ускоряя исправление и балансировку. Новый инструмент управления кластером gpctl, основанный на архитектуре gRPC, упрощает и ускоряет развертывание кластера и настройку новых сред.

Масштабируемый приём данных с помощью GPSS

Greenplum Streaming Server теперь использует многозвенную архитектуру на базе Kubernetes. Он работает как распределённая система, способная масштабироваться в зависимости от объёма поступающих данных. GPSS эффективно обрабатывает большие потоки данных из таких источников, как Kafka и RabbitMQ, поддерживая аналитику в реальном времени с низкой задержкой.

Эффективное AutoML с gpMLBot

gpMLBot в версии 7.5 упрощает автоматическое машинное обучение (AutoML), включая подбор гиперпараметров, что помогает находить наилучшую модель и параметры для конкретных наборов данных. Благодаря интеграции с высокопроизводительным движком базы данных Tanzu Greenplum и встроенными библиотеками аналитики, gpMLBot сокращает время обучения и выбора модели, ускоряя работу дата-сайентистов с большими объемами данных или сложными признаковыми пространствами.

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

Tanzu Greenplum 7.5 поддерживает масштабный геоанализ с помощью расширений pgPointCloud, 3DCityDB, pgRouting, H3 Index и TIGER. pgPointCloud обеспечивает эффективное хранение и запросы к облакам точек LiDAR, 3DCityDB управляет 3D-моделями городов на основе CityGML для планирования и визуализации, pgRouting реализует оптимизированную маршрутизацию в крупных сетях, H3 Index улучшает поиск и распределение данных для объединений, а TIGER геокодирует адреса в координаты, облегчая пространственные запросы.

Итоги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дункан Эппинг рассказал о том, как можно убедиться, что ваши диски VMware vSAN зашифрованы.

Если у вас включена техника шифрования "vSAN Encryption – Data At Rest", то вы можете проверить, что действительно данные на этих дисках зашифрованы в разделе настроек vSAN в клиенте vSphere Client. Однако вы можете сделать это и на уровне хоста ESXi, выполнив команду:

esxcli vsan storage list

Как вы можете увидеть из вывода команды, для шифрования указан параметр Encryption: true.

Второй момент - вам надо убедиться, что служба управления ключами шифрования Key Management System доступна и работает как положено. Это вы можете увидеть в разделе vSAN Skyline Health клиента vSphere:

Дункан также обращает внимание, что если вы используете Native Key Server и получаете ошибку "not available on host", проверьте, опцию "Use key provider only with TPM". Если она включена, то вы должны иметь модуль TPM для корректной работы механизмов шифрования. Если у вас модуля такого нет - просто снимите эту галочку.

Есть вопрос, который администраторы платформы виртуализации VMware vSphere задают регулярно:

Какие идеальные соотношения vCPU к pCPU я должен планировать и поддерживать для максимальной производительности? Как учитывать многопоточность Hyper-Threading и Simultaneous Multithreading в этом соотношении?

Ответ?

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

Раньше мы пользовались рекомендациями вроде 4 vCPU на 1 pCPU (4:1) или даже 10:1, но этот подход основывался на негласной предпосылке — рабочие нагрузки в основном были в простое. Многие организации начинали свою виртуализацию с консолидации наименее нагруженных систем, и в таких случаях высокое соотношение vCPU:pCPU было вполне обычным явлением.

Так появилась концепция коэффициента консолидации, ставшая основой для планирования ресурсов в виртуальных средах. Даже возникала конкуренция: кто сможет добиться более высокого уровня консолидации. Позже появились технологии вроде Intel Hyper-Threading и AMD SMT (Simultaneous Multithreading), которые позволяли достичь ещё большей консолидации. Тогда расчёт стал сложнее: нужно было учитывать не только физические ядра, но и логические потоки. Огромные Excel-таблицы превратились в операционные панели мониторинга ресурсов.

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

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

Вместо этого нужно "управлять по конкуренции" (drive by contention)

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

Именно под такие задачи была спроектирована платформа VMware Cloud Foundation (VCF) и ее инструменты управления — и не только для CPU. На уровне платформы vSphere поддерживает крупные кластеры, автоматически балансируемые такими сервисами, как DRS, которые минимизируют влияние конфликтов на протяжении всего жизненного цикла приложений.

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

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

• Логические CPU не равно физические CPU/ядра (в случае гиперпоточности)
• Важность точного подбора размеров виртуальных машин (right-sizing)

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

Если обеспечить быструю реакцию пока невозможно — начните с консервативного соотношения 1:1 vCPU:pCPU, не учитывая гиперпоточность. Это безопасный старт. По мере роста зрелости вашей инфраструктуры, процессов и инструментов, соотношение будет естественно улучшаться.

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

Вкратце:

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

В рамках конференции FinOps X в Сан-Диего команда VMware CloudHealth анонсировала самое большое улучшение платформы с момента её создания. Новый интерфейс CloudHealth специально разработан с учетом потребностей современных специалистов по FinOps и предназначен для решения новых задач и проблем, возникающих в постоянно развивающейся области FinOps (мы писали ранее о CloudHealth вот тут). Благодаря инновационным функциям на базе AI, таким как Intelligent Assist и Smart Summary, новая версия помогает решать ключевые проблемы пользователей и продвигать FinOps как культурную практику во всей организации.

С 2012 года CloudHealth представляет разработки в области управления финансовыми аспектами облаков (FinOps). За последние 13 лет мы стали свидетелями бурного роста облачной инфраструктуры, программного обеспечения, ресурсов и, в последнее время, искусственного интеллекта. Видимость облачного потребления и затрат, рекомендации по оптимизации и обеспечение управления — это теперь базовые ожидания, поскольку от FinOps-команд требуют управления всё более сложными средами, контроля новых направлений ИТ-расходов и взаимодействия с расширяющимся кругом заинтересованных сторон.

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

Intelligent Assist

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

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

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

Smart Summary

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

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

Asset Explorer

Видимость на уровне ресурсов — это не просто информация о стоимости актива или регионе, в котором он работает. Это ещё и визуализация связанных ресурсов, каталогизация тегов и метаданных, а также понимание сценариев использования актива. Asset Explorer предоставляет специалистам по FinOps доступ по требованию к метаданным активов и связям между ними.

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

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

Дэшборды оптимизации и фактической экономии

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

В новом интерфейсе CloudHealth появились панели Optimization Dashboard и Realized Savings Dashboard, которые обеспечивают FinOps-команды необходимыми данными и отчётностью для принятия эффективных и результативных решений по оптимизации и демонстрации их влияния бизнесу в целом.

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

Несмотря на значительные усилия и инвестиции в оптимизацию, FinOps-командам часто бывает сложно ответить на вопрос: «Как узнать, сколько мы сэкономили с помощью CloudHealth?». Панель Realized Savings Dashboard позволяет отслеживать достигнутую экономию и демонстрировать финансовую ответственность организации. Клиенты могут видеть агрегированные данные об экономии из различных источников в одном месте. Встроенные виджеты по умолчанию включают охват и использование обязательств, стоимость единицы ресурса и эффективную ставку экономии. Благодаря этой панели FinOps-специалисты получают конкретные показатели, которые позволяют им показать результаты своей работы и её вклад в бизнес.

Пользовательские отчёты (Custom Reports)

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

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

• SQL (через новый интерфейс отчётности CloudHealth),
• Естественного языка (с помощью Intelligent Assist)
• Или визуального конструктора в интерфейсе

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

Пользовательские виджеты и дэшборды

С учётом множества ролей, участвующих в FinOps-практике, важно, чтобы каждый пользователь CloudHealth мог настроить интерфейс под свои задачи и всегда иметь под рукой самую актуальную информацию. С новыми пользовательскими панелями (Dashboards) и виджетами (Widgets) пользователи могут создавать полностью кастомизированные дашборды, объединяя на одной панели несколько собственных отчётов в виде виджетов.

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

• Возможности для оптимизации
• Сводки по обязательствам
• Аномалии в расходах
• Неэффективные затраты и ресурсы и многое другое

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

Продолжаем рассказывать о российском ПО в сфере серверной виртуализации. Numa vServer — российская платформа серверной виртуализации корпоративного уровня, разработанная компанией «НумаТех». Она предназначена для создания защищённых виртуальных инфраструктур и соответствует требованиям информационной безопасности, установленным ФСТЭК России.

Архитектура и технологии

В основе Numa vServer лежит гипервизор первого типа на базе Xen, доработанный более чем в 300 аспектах для повышения безопасности, надёжности и производительности. Платформа устанавливается напрямую на аппаратное обеспечение (bare-metal), что исключает необходимость в хостовой операционной системе и обеспечивает высокую производительность и безопасность.

Безопасность и сертификация

Numa vServer сертифицирован ФСТЭК России по 4 уровню доверия и 4 классу защиты (сертификат № 4580 от 23.09.2022) . Это позволяет использовать платформу в государственных информационных системах, системах обработки персональных данных, АСУ ТП и критически важных объектах.

Ключевые функции безопасности:

• Изолированная среда исполнения управляющей ВМ (Domain 0).
• Мандатный контроль доступа и зонирование.
• Контроль целостности конфигураций, журналов и образов ВМ.
• Журналирование действий пользователей и фильтрация потоков данных.
• Поддержка многофакторной аутентификации и интеграция с LDAP/Active Directory.

Функциональные возможности

• Кластеризация и высокая доступность: поддержка до 64 серверов в одном пуле с возможностью автоматической миграции ВМ при сбоях.
• Резервное копирование и восстановление: полные и дельта-копии, снэпшоты, репликация, поддержка протоколов NFS, SMB/CIFS, S3.
• Импорт/экспорт ВМ: поддержка форматов VMware, Citrix, VirtualBox.
• Управление через Numa Collider: веб-интерфейс для администрирования, мониторинга и настройки виртуальной инфраструктуры.
• Интеграция с OpenStack и CloudStack: поддержка инструментов IaC, таких как Packer и Terraform.
• Виртуализация GPU: возможность делить графический адаптер между несколькими ВМ с поддержкой 3D-графики.

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

Numa vServer предъявляет низкие требования к оборудованию, что позволяет использовать его на серверах возрастом более 10 лет.

Минимальные требования:

• Процессор: 2 ядра, 1.5 ГГц.
• Оперативная память: 4 ГБ.
• Диск: 128 ГБ.
• Сетевой адаптер: 1 порт, 100 Мбит/с.

Рекомендуемые характеристики:

• Процессор: 4–8 ядер, 2.5 ГГц с поддержкой Intel-VT или AMD-V.
• Оперативная память: 16 ГБ с поддержкой ECC.
• Диск: 750 ГБ.
• Сетевой адаптер: 2 порта, 1 Гбит/с.

Лицензирование и поддержка

Лицензирование Numa vServer осуществляется по количеству физических процессоров. В базовую лицензию входит редакция «Начальная» консоли управления Numa Collider. Доступны также расширенные редакции с дополнительным функционалом, такими как балансировка нагрузки, программно-определяемые сети и расширенные возможности резервного копирования.

Применение и преимущества

Numa vServer подходит для организаций, стремящихся к импортозамещению и обеспечению информационной безопасности. Платформа может использоваться для:

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

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

• Быстрое развёртывание и простота эксплуатации.
• Высокий уровень безопасности и соответствие требованиям ФСТЭК.
• Низкие системные требования и возможность использования на устаревшем оборудовании.
• Гибкая модель лицензирования и конкурентная стоимость владения.

Заключение

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

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

• Официальный сайт Numa vServer
• Руководство пользователя Numa vServer (PDF)

Если вы знакомы с PowerCLI, вам наверняка нравится, как легко с его помощью выполнять обычные административные задачи в экосистеме VMware. Недавно компания рассказала о совершенно новом уровне возможностей. Он предоставляет прямой доступ ко всем API-методам - это пакет PowerCLI SDK. Он уже включён в вашу установку PowerCLI — дополнительных скачиваний или настройки не требуется.

Что такое PowerCLI SDK?

Фоеймворк PowerCLI предлагает высокоуровневые командлеты. Кроме того, он включает автоматически генерируемые SDK-модули для многих основных продуктов VMware, таких как vSphere, NSX, SRM и VMware Cloud Foundation (VCF). Эти SDK дают точный доступ к API через PowerShell, позволяя создавать пользовательские автоматизации низкого уровня.

Чтобы увидеть доступные SDK в вашей среде, выполните команду:

Вы увидите вывод наподобие:

Начало работы: изучение VMware Cloud Foundation с помощью SDK

Давайте рассмотрим реальный пример использования модуля VMware.Sdk.Vcf.SddcManager. Этот модуль предоставляет доступ к полному API VMware Cloud Foundation (VCF) через PowerShell.

1. Загрузка модуля

2. Подключение к VCF. Подобно Connect-VIServer, SDK имеет собственную команду подключения:

После подключения вы увидите детали соединения, включая токены доступа, которые автоматически используются в дальнейших вызовах.

Реальный API-вызов: получение доменов нагрузки (Workload Domains)

Предположим, вы хотите вывести список всех доменов нагрузки в вашей среде VCF.

API-метод для этого:

Вам не нужно составлять запросы cURL или вручную отправлять HTTP-запросы. Вместо этого вы можете найти и вызвать нужный командлет прямо в PowerShell.

3. Поиск нужного командлета

Используйте команду Get-VcfSddcManagerOperation для поиска доступных API-операций:

Это направит вас к нужному командлету:

4. Вызов API

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

Встроенная помощь и документация

SDK-командлеты включают полную поддержку справки по всем аспектам вызываемых API:

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

Поддерживаемые продукты

SDK-модули доступны для многих продуктов VMware, включая:

• VMware Cloud Foundation (SDDC Manager)
• vSphere
• NSX-T
• Site Recovery Manager (SRM)
• vSphere Replication

Важно понимать, что все они автоматически включаются в последние версии фреймворка PowerCLI.

Итог

PowerCLI SDK предоставляет полный доступ к API продуктов VMware с помощью привычного синтаксиса PowerShell. Вы получаете полный контроль при создании сложных автоматизаций и можете интегрировать свои сценарии в конвейеры CI/CD без необходимости выходить из терминала. Вы также можете комбинировать высокоуровневые командлеты PowerCLI с операциями SDK, чтобы получить максимальную эффективность.

По умолчанию скорость соединения (link speed) адаптера vmxnet3 виртуальной машины устанавливается как 10 Гбит/с. Это применяемое по умолчанию отображаемое значение в гостевой ОС для соединений с любой скоростью. Реальная скорость будет зависеть от используемого вами оборудования (сетевой карты).

VMXNET 3 — это паравиртуализированный сетевой адаптер, разработанный для обеспечения высокой производительности. Он включает в себя все функции, доступные в VMXNET 2, и добавляет несколько новых возможностей, таких как поддержка нескольких очередей (также известная как Receive Side Scaling в Windows), аппаратное ускорение IPv6 и доставка прерываний с использованием MSI/MSI-X. VMXNET 3 не связан с VMXNET или VMXNET 2.

Если вы выведите свойства соединения на адаптере, то получите вот такую картину:

В статье Broadcom KB 368812 рассказывается о том, как с помощью расширенных настроек виртуальной машины можно установить корректную скорость соединения. Для этого выключаем ВМ, идем в Edit Settings и на вкладке Advanced Parameters добавляем нужное значение:

ethernet0.linkspeed    20000

Также вы можете сделать то же самое, просто добавив в vmx-файл виртуальной машины строчку ethernetX.linkspeed = "ХХХ".

При этом учитывайте следующие моменты:

• Начиная с vSphere 8.0.2 и выше, vmxnet3 поддерживает скорость соединения в диапазоне от 10 Гбит/с до 65 Гбит/с.
• Значение скорости по умолчанию — 10 Гбит/с.
• Если вами указано значение скорости меньше 10000, то оно автоматически устанавливается в 10 Гбит/с.
• Если вами указано значение больше 65000, скорость также будет установлена по умолчанию — 10 Гбит/с.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

VMware/Broadcom представили новую сертификацию — VMware Certified Professional – Private Cloud Security Administrator (VCP-PCS), которая подтверждает квалификацию специалистов по обеспечению безопасности в среде VMware Cloud Foundation (VCF) с использованием решений VMware vDefend. Это важный шаг в направлении усиления защиты частных облаков, особенно в условиях растущего спроса на модели Zero Trust и комплексные меры кибербезопасности.

Что представляет собой VCP-PCS?

Сертификация VCP-PCS предназначена для специалистов, отвечающих за безопасность VCF, включая:

• Архитекторов и инженеров облачной инфраструктуры
• Администраторов виртуальной инфраструктуры
• Системных администраторов
• Специалистов по поддержке и внедрению решений

VCP-PCS подтверждает способность кандидата:

• Настраивать и управлять распределёнными и шлюзовыми межсетевыми экранами
• Реализовывать защиту от продвинутых угроз
• Внедрять архитектуру Zero Trust с использованием VMware vDefend
• Использовать аналитические инструменты и средства безопасности для мониторинга и реагирования на инциденты

Подготовка и экзамен

Для получения сертификации необходимо:

• Курс: VMware vDefend Security for VCF 5.x Administrator
• Темы: архитектура vDefend, управление политиками безопасности, практическое применение в VCF

• Название: VMware vDefend Security for VCF 5.x Administrator (6V0-21.25)
• Формат: 75 вопросов (множественный выбор и множественные ответы)
• Продолжительность: 90 минут
• Проходной балл: 70%
• Язык: английский
• Стоимость: $250
• Регистрация: через портал сертификации VMware

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

Сертификация VCP-PCS демонстрирует вашу способность:

• Обеспечивать безопасность в современных частных облаках
• Внедрять и поддерживать архитектуру Zero Trust
• Использовать инструменты VMware vDefend для защиты инфраструктуры

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

Как сообщает CNews, 15 мая 2025 года было официально подтверждено, что отечественная платформа виртуализации SpaceVM успешно прошла тестовые испытания на совместимость с серверами Fplus «Спутник». Это событие стало важным шагом в направлении формирования полностью отечественной ИТ-инфраструктуры, обеспечивающей технологический суверенитет и независимость от зарубежных решений.

Тестирование и результаты

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

• Создание, клонирование и управление виртуальными машинами
• Работа со снапшотами, восстановление и миграция ВМ
• Операции с виртуальными дисками и проброс хранилищ по Fibre Channel
• Настройка виртуальных сетей и интерфейсов

Гостевые операционные системы на архитектуре x86_64 запускались и функционировали без ошибок. Тестирование проводилось на двух конфигурациях серверов Fplus «Спутник», оснащённых процессорами Intel Xeon Scalable и сетевыми адаптерами Broadcom и Mellanox. Все тесты завершились успешно, подтвердив полную интеграцию программного обеспечения SpaceVM с серверной платформой.

Значение для отрасли

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

Алексей Мензовитый, директор по продукту SpaceVM, отметил:

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

Михаил Волков, главный исполнительный директор Fplus, добавил:

"Мы как производитель 'железа' продолжаем расширять технологическую совместимость с программным обеспечением ведущих отечественных разработчиков. Успешное тестирование серверов 'Спутник' и платформы SpaceVM гарантирует заказчикам, что их ИТ-инфраструктура будет реализована на полностью совместимых российских реестровых решениях."

Перспективы

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

Для получения дополнительной информации о платформе виртуализации SpaceVM и серверах Fplus «Спутник» вы можете посетить официальные сайты компаний:

• SpaceVM: https://spacevm.ru
• Fplus: https://fplustech.ru(fplustech.ru)

Object First — это компания, основанная Ратмиром Тимашевым, одним из легендарных сооснователей Veeam Software. После того как Veeam был продан инвестиционной компании Insight Partners за $5 млрд в 2020 году, Тимашев отошел от операционного управления компанией, но остался в ИТ-индустрии. Его новым проектом стала Object First, цель которой — предложить максимально простое, защищенное и производительное решение для хранения резервных копий, оптимизированное под решения Veeam.

Цели и философия Object First

Object First была создана с четким пониманием болевых точек ИТ-отделов: сложность настройки хранилищ, высокая стоимость масштабируемых решений и растущие угрозы кибератак, в том числе программ-вымогателей. Команда Object First стремится решить эти проблемы с помощью подхода "Secure by Design" и глубокой интеграции с Veeam Backup and Replication.

Что такое Ootbi?

Флагманский продукт Object First называется Ootbi ("Out-of-the-box immutability") — это on-premise объектное хранилище, специально созданное для Veeam. Основные технические особенности Ootbi:

• Готовность к работе "из коробки": решение поставляется в виде готового устройства, не требующего глубокой предварительной настройки.
• Поддержка объектного хранилища S3: Ootbi работает по протоколу S3 и полностью совместим с Veeam Backup & Replication.
• Неизменяемость данных (immutability): встроенная защита от программ-вымогателей (Ransomware). Используются политики WORM (Write Once, Read Many), гарантирующие, что резервные копии не могут быть удалены или изменены в течение заданного периода (даже с административными привилегиями).
• Интеграция с Veeam через Scale-Out Backup Repository (SOBR): Ootbi можно использовать как capacity tier, обеспечивая гибкое и масштабируемое резервное копирование.
• Безопасность и упрощенное администрирование: не требуется root-доступ или отдельные операционные системы. Решение изолировано и минимизирует человеческий фактор.

Аппаратная архитектура

На данный момент Ootbi представляет собой масштабируемую кластерную систему из 2-4 узлов:

• Каждый узел содержит вычислительные ресурсы и локальное хранилище (HDD и SSD для кэширования).
• Используется распределённая файловая система, обеспечивающая отказоустойчивость и высокую доступность.
• Производительность: до 4 ГБ/сек совокупной пропускной способности, до 1 ПБ эффективного объема хранения с учетом дедупликации и компрессии на стороне Veeam.

Преимущества для клиентов

• Минимизация риска потери данных благодаря immutability и встроенной защите.
• Снижение TCO (total cost of ownership) за счет простоты управления и отказа от сложных инфраструктур.
• Быстрое развёртывание: установка и настройка возможна за считанные часы.
• Отсутствие необходимости в публичном облаке, что важно для компаний с повышенными требованиями к безопасности и локализации данных.

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

Недавно мы писали о программном доступе к спискам совместимости Broadcom Compatibility Guide (BCG), а на днях стало известно, что ключевой компонент платформы VMware Cloud Foundation 9 - платформа VMware vSphere 9 - уже присутствует в BCG, так что можно проверять свои серверы и хранилища на предмет совместимости с VMware ESXi 9.0 и VMware vSAN 9.0:

Кстати в списках совместимости с vVols не указан VMware ESXi 9, так как эта технология будет признана deprecated в следующей версии платформы (и окончательно перестанет поддерживаться в vSphere 9.1).

Имейте в виду, что список совместимости еще может поменяться к моменту финального релиза VMware vSphere 9, но ориентироваться на это для планирования закупок можно уже сейчас.

Виртуальные модули VMware NSX Edge Appliances играют ключевую роль в инфраструктуре VMware NSX, обеспечивая маршрутизацию север-юг, функции межсетевого экрана, балансировку нагрузки и VPN-сервисы. Потеря доступа к NSX Edge из-за забытого или истёкшего пароля может нарушить работу системы и ограничить возможности управления. В этой статье мы рассмотрим процедуру сброса пароля для устройства NSX Edge. Описанная ниже процедура подходит для сброса паролей на виртуальных модулях NSX Manager, Edge и Cloud Service Manager.

Чтобы сбросить пароль root, используйте следующую процедуру:

• Войдите в графический интерфейс NSX > System > Nodes > Edge Cluster > выберите узел Edge > кликните правой кнопкой мыши > выберите «Put into Maintenance Mode», чтобы перевести хост Edge в режим обслуживания.
• Войдите в vCenter, найдите виртуальную машину Edge и установите задержку загрузки (boot delay) на 9000.
• Подключитесь к консоли виртуального модуля Edge Appliance.
• Перезагрузите систему.
• Когда появится меню загрузчика GRUB, быстро нажмите левую клавишу SHIFT или ESC. Если вы не успеете, и процесс загрузки продолжится, необходимо будет перезагрузить систему снова.

• Нажмите e, чтобы отредактировать пункт меню. Выберите верхнюю строку с Ubuntu, затем введите имя пользователя root и пароль GRUB для пользователя root (он отличается от пароля пользователя root на самом устройстве). Пароль по умолчанию — NSX@VM!WaR10 (скорее всего, вы его не меняли).

Нажмите e, чтобы отредактировать выбранный пункт. Найдите строку, начинающуюся с linux, и добавьте в конец этой строки следующее:
systemd.wants=PasswordRecovery.service

• Нажмите Ctrl+X, чтобы продолжить загрузку. Когда появятся последние сообщения журнала, введите новый пароль для пользователя root.
  Введите пароль ещё раз. Загрузка продолжится.
• После перезагрузки вы можете убедиться в смене пароля, выполнив вход под пользователем root с новым паролем. С помощью входа под root вы также можете изменить пароли пользователей admin и audit, если потребуется.
• Заключительный шаг — вывести узел Edge из режима обслуживания.

Как сообщалось еще в апреле, загрузки VMware Fling были перенесены в раздел бесплатных загрузок на портале поддержки Broadcom (BSP), и этот переход завершился на прошедших выходных. В дальнейшем все новые и обновленные версии VMware Flings будут публиковаться на BSP.

Чтобы получить доступ к загрузкам VMware Flings или любому другому бесплатному или предоставленному программному обеспечению Broadcom, необходимо зарегистрировать бесплатную учетную запись BSP — там допускаются и личные email-адреса (например, Gmail).

После перехода в раздел бесплатных загрузок, выберите раздел (Division) VMware и подраздел Flings:

Там вы увидите полный список бесплатных утилит для виртуальной инфраструктуры VMware vSphere / Cloud Foundation:

К сожалению, не все Flings (которые у нас можно найти по тэгу Labs) выжили, плюс не всегда актуальная версия утилиты соответствует вашей версии среды. Поискать прошлые версии этих утилит можно с помощью Wayback Machine.

На прошедшей недавно конференции VeeamON 2025 было рассказано о скором выходе новой версии Veeam Backup & Replication 13, в которой будут представлены новые функции, направленные на повышение доступности (High Availability, HA), что позволяет компаниям поддерживать бесперебойную работу и защищать критически важные данные даже в случае непредвиденных ситуаций. Эта возможность уже давно запрашивалась пользователями, и вот, наконец, она будет реализована в производственной среде.

Помимо высокой доступности, Veeam Backup & Replication v13 предложит впечатляющие возможности, такие как развертывание сервера управления, хранилища, прокси и других компонентов напрямую из Veeam Software Appliance, мгновенное восстановление в Microsoft Azure, расширенное управление доступом на основе ролей (RBAC), а также множество других улучшений.

В Veeam Backup & Replication v13 возможности HA были расширены за счёт внедрения резервного управляющего сервера, готового к моментальному переключению при необходимости. В фоновом режиме репликация базы данных PostgreSQL обеспечивает постоянное дублирование всех конфигурационных данных, что гарантирует готовность системы к любым сбоям. При этом механизм репликации кэша, встроенный в базу данных, непрерывно передаёт данные на резервный сервер, обеспечивая его синхронность с основным узлом. Такая проактивная настройка устраняет время ожидания в случае аварии — резервная машина Veeam Backup & Replication полностью готова к работе и может быть активирована при необходимости.

На первом этапе функция HA будет доступна только для Veeam Backup & Replication на платформе Linux (дистрибутив основан на Rocky Linux). Процесс переключения выполняется вручную и по требованию — администраторы могут инициировать его в нужный момент, так как автоматические триггеры пока не предусмотрены. Архитектура реализована по схеме "активный-пассивный" с двумя узлами, с акцентом на надёжность.

Настройка сервера

После установки Veeam Backup & Replication v13 с помощью Veeam Software Appliance (в формате .ova или .iso), необходимо выполнить несколько базовых шагов конфигурации самого сервера. В этот процесс входят следующие ключевые этапы:

• Настройка имени: присвойте виртуальному модулю понятное и информативное имя для его простой идентификации в инфраструктуре.
• Сетевые настройки: установите сетевые параметры для надёжной связи с другими компонентами и резервным сервером.
• Настройка NTP: укажите сервер синхронизации времени (Network Time Protocol), чтобы обеспечить точное совпадение времени на всех системах. Это критически важно, например, для проверки одноразовых паролей (OTP).
• Пароль в соответствии с DISA STIG: создайте безопасный пароль, соответствующий требованиям DISA STIG, чтобы усилить защиту сервера Veeam Backup & Replication.
• OTP для администратора и офицера безопасности Veeam: сгенерируйте и настройте одноразовые пароли для ролей администратора и офицера безопасности (Security Officer). Несмотря на то, что для корректной работы OTP требуется точное время, доступ к интернету для их проверки не нужен, что позволяет использовать систему в изолированных средах.

Настройка кластера

• Создание кластера и настройка сети - укажите сетевые параметры для надёжной связи с другими компонентами и резервным сервером.

• Задайте сетевые параметры основного и резервного узлов. Убедитесь, что оба узла кластера находятся в одной IP-подсети — на этапе бета-тестирования это обязательное условие.

• После этого начнется процесс создания и конфигурации кластера.

• Если основной узел не отвечает, вы можете инициировать операцию переключения (failover), чтобы ввести в работу резервный узел.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Увеличено максимальное число поддерживаемых групп LDAP и Active Directory — с 20 до 500.

• Поддержка стандарта FIPS 140-3: NSX 4.2.2 теперь использует криптографические модули, соответствующие требованиям FIPS 140-3 (Federal Information Processing Standards). NSX работает в режиме соответствия FIPS по умолчанию во всех развертываниях. Подтверждение соответствия стандарту FIPS 140-3 гарантирует, что NSX использует актуальные криптомодули для надёжной защиты рабочих нагрузок. Дополнительная информация о модулях доступна по ссылке в оригинальной документации.