Недавно в Лас-Вегасе прошла конференция VMware Explore 2026 — со встречами с заказчиками и партнёрами, техническими сессиями и воркшопами. К мероприятию приурочен анонс общей доступности VMware Cloud Foundation (VCF) 9.1.1 — первого maintenance-релиза для ветки VCF 9.1.
Примечание: хотя для maintenance-релизов и экспресс-патчей (EP) жёсткая последовательность установки не задана, для релиза VCF 9.1.1 предусмотрено особое исключение — несколько компонентов необходимо обновлять в строго определённом порядке (соответствующие предварительные проверки уже встроены в релиз). В одном из будущих maintenance-релизов эти исключения будут сняты, но пока о них следует помнить.
Fleet LCM необходимо обновить до 9.1.1 прежде, чем обновлять до 9.1.1 остальные компоненты VCF.
VCFMS необходимо обновить до 9.1.1 прежде, чем обновлять до этой же версии Identity Broker и компонент Salt Master/RaaS.
VCF Automation (VCFA) необходимо обновить до 9.1.1 прежде, чем обновлять компонент VCD Migrator.
Как maintenance-релиз он включает все накопленные исправления ошибок и обновления безопасности из ранее вышедших экспресс-патчей (EP), а также улучшения стабильности платформы и доработки, упрощающие переход на VCF 9.1.
Улучшений в этом релизе много, но ниже разобраны десять, которые заслуживают отдельного внимания.
2. Поддержка актуальных версий компонентов VCF в VCF Download Tool (VCFDT)
Экспресс-патчи (EP) для компонентов VCF выходят всё чаще, и определить актуальные версии всех компонентов, необходимых для новой установки или обновления VCF, становится всё сложнее. VCF Download Tool (VCFDT) позволяет без труда узнать последнюю версию отдельного компонента, но с определением актуальных версий по всему программному стеку VCF всё обстояло не так просто.
В VCFDT 9.1.1 задачу упрощает новый флаг --latest: он автоматически отбирает необходимые компоненты VCF в их последних версиях с экспресс-патчами — как для сценария установки, так и для сценария обновления.
Команда для вывода списка последних бинарных файлов VCF 9.1.0, необходимых только для первоначальной установки:
vcf-download-tool binaries list --depot-download-token-file=/Users/lamw/vcf_download_token.txt --vcf-version=9.1.0 --sku=VCF --type=INSTALL --automated-install --latest
Команда для загрузки последних бинарных файлов VCF 9.1.0, необходимых только для первоначальной установки:
3. Поддержка OCI-артефактов, а также образов vSphere Supervisor, VKS и VKR в VCF Download Tool
Унифицированный VCF Software Depot представляет собой единый репозиторий, в котором хранятся все бинарные файлы, используемые развёртыванием VCF, — OVA, ZIP-архивы, PAK-файлы и артефакты в формате OCI. VCFDT остаётся основным инструментом взаимодействия с онлайновым VCF Software Depot: с его помощью загружают содержимое и создают офлайновый VCF Software Depot. Однако одно ограничение сохранялось — инструмент не умел работать с артефактами в формате OCI, включая vSphere Kubernetes Releases (VKR).
В VCF 9.1.1 в VCFDT появилась новая команда artifacts, которая упрощает загрузку сервисов vSphere Supervisor, включая vSphere Kubernetes Service (VKS), и, что особенно важно, релизов vSphere Kubernetes Releases (VKR). Новая команда позволяет выбрать, какие именно VKR нужно загрузить. Раньше подписка на онлайновую библиотеку контента VKR делала доступными для развёртывания сразу все релизы VKR, и у операторов платформы не было простого способа контролировать, какие из них используются.
В составе подкоманды artifacts появился также фильтр по категориям, который позволяет быстро отобрать конкретный тип бинарных файлов для просмотра или загрузки:
SUPERVISOR — обновления управляющего уровня vSphere Supervisor
4. Уменьшенный ресурсный след VCF Management Services (VCFMS)
Когда в VCF 9.1.0 появился компонент VCF Management Services (VCFMS), размеры его виртуальных машин подбирались с расчётом на самый крупный из опциональных сервисов Day-N. Это снижало вероятность того, что при включении дополнительных сервисов потребуется переход на более крупную конфигурацию ВМ. Но в средах, где такие опциональные сервисы Day-N не разворачивались, часть виртуальных машин VCFMS оказывалась больше, чем необходимо.
В VCF 9.1.1 размеры VCFMS оптимизированы под первоначальное развёртывание Day-0. Кроме того, отдельные компоненты VCFMS были дополнительно перенастроены так, чтобы каждый сервис резервировал только те ресурсы, которые ему действительно требуются, — это повышает общую эффективность использования ресурсов. Например, при развёртывании Simple (без высокой доступности) теперь будет на один рабочий узел VCFMS меньше (12 vCPU / 24 ГБ памяти).
У тех, кто обновляет существующее развёртывание VCF 9.1 до версии 9.1.1, текущие размеры VCFMS останутся без изменений. При этом воспользоваться уменьшенным футпринтом VCFMS всё же можно — запустив после обновления скрипт перенастройки размеров, когда все компоненты VCFMS будут обновлены до 9.1.1.
5. Поддержка развёртывания Small HA для VCF Management Services (VCFMS) в VCF Installer
В VCF 9.1.0 конфигурация Small для VCFMS поддерживалась, но была доступна только в модели развёртывания Simple (без высокой доступности). В результате тем, кому требовалась высокая доступность управляющих узлов VCFMS, приходилось разворачивать следующий по размеру вариант VCFMS, обменивая дополнительное потребление ресурсов на повышенную доступность.
В VCF 9.1.1 для VCF Management Services (VCFMS) появился новый вариант развёртывания Small HA: высокой доступности можно добиться, не выходя за пределы ресурсов самой компактной конфигурации.
Если эта возможность используется через JSON API VCF Installer, в качестве значения размера развёртывания в секции vspClusterSpec, описывающей конфигурацию VCF Management Services (VCFMS), указывается small_ha.
Если VCF Fleet развёрнут в варианте Small без высокой доступности, масштабировать его до Small HA можно как операцию Day-N — через интерфейс VCF Operations в разделе Build > Lifecycle > VCF Management > Components > VCF Services Runtime, выбрав Action > Scale.
6. Поддержка HTTP и произвольного URL для офлайнового депо в интерфейсе VCF Installer
Возможность настроить офлайновый депозиторий VCF через HTTP-эндпоинт, включая поддержку произвольного пути в URL, появилась в API VCF Installer ещё в VMware Cloud Foundation (VCF) 9.1.0. Начиная с VCF 9.1.1 то же самое доступно непосредственно в интерфейсе VCF Installer: средам, которым не нужен HTTPS и/или которые используют собственный URL офлайнового депо, больше не требуется обращаться к API VCF Installer.
7. Поддержка дисков вне HCL vSAN ESA в интерфейсе VCF Installer
В лабораторных и пилотных развёртываниях доступ к NVMe-накопителям, сертифицированным для vSAN ESA, есть далеко не всегда. По умолчанию VCF Installer допускает использование с vSAN ESA только сертифицированных NVMe-устройств. Раньше это поведение можно было переопределить, добавив соответствующую настройку в VCF Installer. Начиная с VCF 9.1.1 поддержка несертифицированных NVMe-устройств с vSAN ESA встроена непосредственно в VCF Installer, и ручная настройка больше не нужна.
Важно: в продуктивных средах VVF и VCF с vSAN ESA поддерживаются только NVMe-устройства, перечисленные в Broadcom Compatibility Guide (BCG).
Для использования этой возможности через JSON API VCF Installer в секцию vsanSpec добавлено новое свойство skipHclAutoDiskClaim. Установка его в true включает то же поведение, что и в интерфейсе VCF Installer.
8. Поддержка развёртывания на одном хосте ESX в интерфейсе VCF Installer
В лабораторных и пилотных средах с ограниченными аппаратными ресурсами выполнить минимальные требования к количеству хостов ESX удаётся не всегда. Хотя обходной путь через переопределение настройки доступен ещё с VCF 5.x, интерфейс VCF Installer всё равно требовал соблюдения минимального числа хостов и блокировал развёртывание даже при заданном переопределении. В результате развёртывание приходилось выполнять через Cloud Builder или JSON API VCF Installer.
Начиная с VCF 9.1.1 интерфейс VCF Installer учитывает такое переопределение, и подобные развёртывания можно выполнять прямо из UI. Для тех, кто только начинает знакомиться с VCF в лабораторных и пилотных средах, это заметно упрощает работу.
9. Поддержка дисков вне HCL vSAN ESA в процедуре ввода хостов в эксплуатацию
При добавлении нового домена рабочей нагрузки VCF или расширении существующего, если в нём используется vSAN ESA, для ввода в эксплуатацию хостов ESX с несертифицированными NVMe-устройствами раньше требовалось дополнительное переопределение настроек. Продолжая линию на упрощение работы, заданную в VCF 9.1.1, ввод хостов ESX в эксплуатацию теперь выполняется прямо из интерфейса vCenter Server или SDDC Manager без этого дополнительного переопределения.
Прежде чем добавлять введённый в эксплуатацию хост ESX с несертифицированными NVMe-устройствами в кластер vSAN ESA, необходимо убедиться, что функция vSAN Managed Disk Claim отключена. По умолчанию она автоматически захватывает сертифицированные NVMe-устройства для использования с vSAN ESA. Несертифицированные устройства требуют ручной обработки, поэтому в противном случае операция будет заблокирована.
Важно: в продуктивных средах VVF и VCF с vSAN ESA поддерживаются только NVMe-устройства, перечисленные в Broadcom Compatibility Guide (BCG).
10. Поддержка VPC на базе VLAN без Overlay Tunnel Endpoint (TEP)
С появлением Distributed Transit Gateway (DTGW) для начала работы с Virtual Private Cloud (VPC) достаточно распределённой группы портов (DVPG) на базе VLAN, однако дополнительно всё равно приходилось настраивать overlay-сеть для Tunnel Endpoint (TEP) между хостами ESX. В VCF 9.1.1 у DTGW появился ещё один вариант — на базе VLAN и без необходимости настраивать сеть TEP на каждом хосте ESX, что сокращает объём конфигурации, требуемой для начала работы с VPC.
Примечание: новый вариант развёртывания VPC на базе VLAN полностью совместим с vSphere Kubernetes Service (VKS) и VCF Automation (VCFA), но имеет ряд ограничений. В их числе — отсутствие приватных подсетей VPC, сервисов SNAT/DNAT/VPN и поддержки протоколов, отличных от IP (например, VRRP и Multicast).
RSS
