VMware vCenter Converter – это классический инструмент VMware для перевода физических и виртуальных систем в формат виртуальных машин VMware. Его корни уходят к утилите VMware P2V Assistant, которая существовала в 2000-х годах для «Physical-to-Virtual» миграций. В 2007 году VMware выпустила первую версию Converter (3.0), заменив P2V Assistant...
Azure VMware Solution управляет глобальным парком производственных приватных облаков, каждое из которых работает в полноценной управляющей плоскости (control plane) VMware NSX и vCenter Server. Когда, например, кластер VMware NSX Manager теряет кворум, NSX может генерировать множество связанных алармов, однако наблюдаемое воздействие выглядит как одновременный каскадный сбой: обновления плоскости управления и конфигурации прекращаются, работоспособность кластера может деградировать, а некоторые симптомы Edge-узлов или транспортных узлов могут проявляться следом — при этом существующая динамическая маршрутизация Tier-0, как правило, остаётся работоспособной. Иными словами, несколько симптомов могут иметь один общий корневой сбой, который необходимо верифицировать с учётом состояния кластера, работоспособности сервисов, хранилища, состояния Compute Manager и связности транспортных узлов. Без модели, кодирующей направленные зависимости между этими уровнями, набор тревог структурно неотличим от множества независимых одновременных сбоев.
Оператор, обрабатывающий каждую тревогу независимо, продлевает инцидент, повторно проходя один и тот же путь распространения сбоя с каждым действием. В условиях производственных масштабов распространение сбоев NSX стабильно опережает ручную сортировку инцидентов. Система автономного самовосстановления приватного облака Azure VMware Solution — это архитектура управления с замкнутым контуром, созданная для устранения именно этого класса сбоев. Система коррелирует сигналы плоскости управления причинно-следственным образом с использованием динамического графа зависимостей в реальном времени, применяет полный стек политик-шлюзов перед любым автоматическим действием, захватывает ограниченное взаимное исключение перед началом выполнения и независимо верифицирует восстановление прежде, чем закрыть инцидент. В данной статье описываются архитектура системы и принятые проектные решения.
Архитектурные компоненты
Azure VMware Solution — это VMware-валидированный сервис Azure первой стороны от Microsoft, предоставляющий приватные облака с кластерами VMware vSphere на базе выделенной bare-metal инфраструктуры Azure. Это позволяет заказчикам использовать существующие инвестиции в навыки и инструменты VMware, сосредоточившись на разработке и запуске своих VMware-нагрузок в Azure.
Каждый архитектурный компонент Azure VMware Solution выполняет следующие функции:
Azure Subscription — управление доступом, бюджетом и квотами для Azure VMware Solution.
Azure Region — физические местоположения по всему миру, объединяющие центры обработки данных в зоны доступности (AZ), а зоны доступности — в регионы.
Azure Resource Group — контейнер для группировки сервисов и ресурсов Azure в логические группы.
Azure VMware Solution Private Cloud — использует программное обеспечение VMware, включая vCenter Server, программно-определяемые сети NSX, программно-определяемое хранилище vSAN и bare-metal хосты ESXi Azure для предоставления вычислительных ресурсов, сетевых ресурсов и хранилища. Поддерживаются также Azure NetApp Files, Azure Elastic SAN и Pure Cloud Block Store.
Azure VMware Solution Resource Cluster — масштабирует приватное облако за счёт дополнительных bare-metal хостов ESXi и программного обеспечения vSAN.
VMware HCX — обеспечивает мобильность, миграцию и расширение сети.
VMware Site Recovery — обеспечивает автоматизацию аварийного восстановления и репликацию хранилища через vSphere Replication. Также поддерживаются сторонние решения DR — Zerto DR и JetStream DR.
Dedicated Microsoft Enterprise Edge (D-MSEE) — маршрутизатор, обеспечивающий связность между Azure и приватным облаком Azure VMware Solution.
Azure Virtual Network (VNet) — частная сеть для соединения сервисов и ресурсов Azure.
Azure Route Server — позволяет сетевым устройствам обмениваться динамической информацией о маршрутизации с сетями Azure.
Azure Virtual Network Gateway — кросс-облачный шлюз для подключения через IPSec VPN, ExpressRoute и VNet-to-VNet.
Azure ExpressRoute — высокоскоростные приватные подключения между центрами обработки данных Azure и локальной или колокационной инфраструктурой.
Azure Virtual WAN (vWAN) — объединяет функции сетевого взаимодействия, безопасности и маршрутизации в единую глобальную сеть.
Что обеспечивает автономное самовосстановление
Система автономного самовосстановления вводит пять гарантированных на системном уровне свойств корректности, ни одно из которых ранее не существовало как системно-принудительное поведение в пути реагирования на инциденты плоскости управления Azure VMware Solution:
Возможность
Что делает Autonomous Self-Heal
Предыдущее состояние
Ограниченное, верифицируемое время восстановления
Измеряет время от первого скоррелированного сигнала до верифицированного стабильного восстановления.
Инциденты закрывались по завершении действия, а не восстановления.
Целостность сигнала при поступлении
Нормализует события, дедуплицирует источники и подавляет флаппинг перед корреляцией.
Конвейера нормализации не существовало. Инженеры получали необработанный поток тревог.
Выполнение с политикой-шлюзом
Атомарно проверяет окна заморозки, бюджеты риска, радиус проблемы, ограничения скорости и согласования перед выполнением.
Единого атомарного стека шлюзов для ограничений и согласований не существовало.
Доказательная база инцидента с возможностью только дополнения
Сохраняет сигналы, топологию, решения, трассировку workflow и верификацию в структурированной записи.
Доказательства находились в отдельных журналах и с трудом воспроизводились.
Прогрессивная модель доверия
Поддерживает режим только-уведомления, чтобы операторы могли проверить обнаружения и предлагаемые действия перед включением.
Автоматизация была бинарной — не было механизма наблюдения за поведением системы до предоставления полномочий на выполнение.
Принципы проектирования
Автономное самовосстановление вводит семь проектных элементов в операции плоскости управления приватным облаком Azure VMware Solution:
Разделение трёх плоскостей (обнаружение, принятие решений, выполнение) с изоляцией поверхностей сбоя по всему управляющему контуру.
Динамический граф зависимостей реального времени, непрерывно обновляемый из потоков событий VMware NSX и vCenter Server, заменяющий статические наборы правил, которые расходятся с реальной топологией.
Трёхвходная модель причинно-следственной корреляции (сила доказательств, временной порядок, направленность зависимости), отличающая причинно-следственные цепочки от совпадающих событий.
Вычисление радиуса проблемы перед выполнением - входной параметр шлюза, обеспечивающий пропорциональное применение политик до совершения любого действия.
Модель фазовых границ (стабилизация, выполнение, верификация), преобразующая событийные осцилляции в демпфированную петлю обратной связи с гистерезисом.
Структура контракта выполнения (триггер, объявление шлюза, спецификация шагов, контракт верификации), принудительно обеспечивающая допустимость области действия и актуальность топологии как системных ограничений.
Единый журнал с возможностью только дополнения, формирующий идентичные записи для автоматизированных и управляемых людьми путей разрешения инцидентов — для целей управления и воспроизведения после инцидента.
Для сбоев в охватываемой области результат — это ограниченное, воспроизводимое время восстановления в любое время суток без участия оператора. Для сбоев в охватываемой области, где автоматическое устранение не может быть санкционировано, результат — детерминированный пакет доказательств, заменяющий воспоминания инженера структурированной, воспроизводимой передачей дел.
Архитектура: обнаружение, принятие решений и выполнение
Автономное самовосстановление разделяет обнаружение, принятие решений и выполнение на отдельные плоскости с единственными, тестируемыми контрактами между ними. Объединение этих функций — более простой подход — разделяет поверхность сбоя между всеми тремя: ошибка в движке выполнения может повредить доказательства, от которых зависит модель корреляции; всплеск объёма тревог может лишить ресурсов оценщика шлюзов; неправильно настроенный шлюз может заблокировать нормализацию сигналов. Разделение устраняет эти режимы взаимозаражения сбоев.
Плоскость обнаружения преобразует необработанные потоки тревог VMware NSX и vCenter Server в стабильные, дискретные кандидаты на инцидент. Конвейер нормализует форматы событий из разных источников, сворачивает избыточные сигналы и применяет окно задержки для фильтрации переходных изменений состояния. Кандидаты, пересекающие границу плоскости, — это подтверждённые, стабильные единицы, единственная форма, которую модель корреляции способна корректно обработать.
Плоскость принятия решений выполняет причинно-следственную корреляцию по динамическому графу зависимостей приватного облака перед оценкой шлюза, формируя ранжированную гипотезу первопричины с оценками уверенности и вычисленной оценкой радиуса проблемы. Плоскость выдаёт ровно один из двух результатов: санкционированное шлюзом разрешение на выполнение или эскалацию с полным пакетом доказательств.
Плоскость выполнения получает токен, ограниченный минимально жизнеспособной областью сбоя, запускает версионированный идемпотентный контрольно-точечный плейбук и закрывает инцидент только после того, как независимая верификация постусловий подтверждает стабильное восстановление в течение окна стабильности. Каждый переход состояния дополняет журнал инцидента.
Журнал инцидентов
Автономное самовосстановление формирует структурированный журнал с возможностью только дополнения для каждого инцидента вне зависимости от пути разрешения. Последовательно фиксируются пять категорий: необработанные и нормализованные сигналы с результатами подавления; снимок топологии на момент обнаружения; полная запись решений, включая результаты корреляции, ранжирование первопричин, оценку радиуса проблемы и трассировку оценки шлюза; трассировка workflow с метаданными шагов и идентификаторами аренды; и результат верификации с результатами постусловий и диспозицией окна стабильности.
Автоматизированные и управляемые людьми пути формируют одинаковую структуру записи — это требование управляемости, а не предпочтение проектирования. Воспроизведение детерминировано: по одному и тому же журналу два рецензента реконструируют одинаковую временную шкалу инцидента.
Итог
Автономное самовосстановление обрабатывает определённое подмножество сбоев плоскости управления NSX и vCenter в приватном облаке Azure VMware Solution. Система не обрабатывает сбои плоскости данных, сбои хранилища, сбои гипервизора, аппаратные сбои или сбои плоскости управления вне смоделированного графа зависимостей. Она не запускает произвольные скрипты, не обходит управление доступом на основе ролей и не переопределяет границы изоляции тенантов. Ограниченная область является источником надёжности системы — система, пытающаяся устранять всё подряд, несёт режимы сбоя, пропорциональные её охвату.
Когда автономное самовосстановление не может предпринять действий, формируемый им пакет доказательств обеспечивает полную структурированную передачу для ответа оператора.
Независимое исследование, проведённое компанией Principled Technologies, сравнило плотность Kubernetes-подов и скорость их готовности в двух средах: VMware Cloud Foundation (VCF) 9.0 с vSphere Kubernetes Service (VKS) 3.6 и Red Hat OpenShift 4.21 на bare metal. Это нагрузочное тестирование с использованием kube-burner — инструмента, разработанного Red Hat, — наглядно демонстрирует превосходство VCF по масштабируемости и задержкам при запуске Kubernetes в корпоративной среде.
Что такое плотность подов Kubernetes
По определению CNCF, под — наименьшая единица развёртывания контейнеризованного приложения. Каждый под содержит один экземпляр приложения с одним или несколькими контейнерами, совместно использующими вычислительные ресурсы, хранилище и сеть. Плотность подов — это количество подов, которые узел способен поддерживать при сохранении стабильной работы.
Ключевые результаты
Плотность подов: vSphere Kubernetes Service (VKS) поддержал 42 000 Kubernetes-подов до достижения пределов стабильности. Red Hat OpenShift на bare metal на идентичном оборудовании смог поддержать лишь 7 400 подов. Таким образом, VCF 9.0 обеспечил в 5,6 раза больше подов на узел/хост, чем Red Hat OpenShift, при использовании инструмента kube-burner.
Скорость готовности подов: в среднем VCF 9.0 продемонстрировал задержку в 4,9 раза ниже, чем Red Hat OpenShift, при тестировании инструментом kube-burner. На уровне 99-го процентиля vSphere Kubernetes Service (VKS) оказался быстрее в 22,5 раза при одновременном поддержании почти пятикратно большего количества подов.
Методология тестирования
Оборудование: четыре сервера Dell PowerEdge R640 с идентичными процессорами, объёмом памяти и дисковой подсистемой на обеих платформах.
Инструмент тестирования:Kube-burner — открытый инструмент CNCF, разработанный преимущественно Red Hat, предназначенный для нагрузочного тестирования и оценки масштабируемости Kubernetes-кластеров.
Метод: инструмент kube-burner постепенно увеличивал количество подов в каждой среде вплоть до достижения максимальной стабильной плотности — точки, за которой дополнительные поды приводят к деградации производительности или нестабильности кластера.
Характер отказов:
Red Hat OpenShift: при превышении порогового количества подов рабочие узлы начинали переходить в состояние «Not Ready», что приводило к завершению работы подов и нестабильности кластера.
VCF 9.0: масштабирование продолжалось без нестабильности узлов; ограничением стало лишь приближение к уровням потребления памяти, влияющим на производительность.
Компания «Базис», работающая на российском рынке программных решений для управления динамической инфраструктурой, сообщила о выходе платформы серверной виртуализации Basis Dynamix Enterprise версии 4.5.
В новом релизе расширены возможности экосистемы за счёт более тесной интеграции с системой управления программно-определяемыми сетями Basis SDN, улучшена совместимость с отечественными системами хранения данных, а также добавлены инструменты для повышения производительности и автоматизации управления ИТ-инфраструктурой. Всего версия 4.5 включает более 90 доработок и нововведений.
Расширение поддержки отечественных систем хранения данных
Одним из ключевых направлений развития версии 4.5.0 стало расширение поддержки российских СХД. В частности, добавлена работа с системой хранения uStor, включая полный набор операций: создание и управление дисками, работу с образами и снапшотами, а также презентацию и депрезентацию дисков вычислительным узлам.
Кроме того, реализована поддержка СХД Yadro Tatlin.Unified с версией ПО 3.2, при этом сохранена обратная совместимость с предыдущими версиями прошивки Tatlin. Это даёт заказчикам больше гибкости при выборе оборудования для построения импортонезависимой инфраструктуры и упрощает взаимодействие с ним через платформу.
Эффективное использование дискового пространства
В версии 4.5 внедрена поддержка unmap для дисков виртуальных машин. Теперь при удалении файлов внутри виртуальной машины освобождённое пространство не только помечается как свободное в гостевой системе, но и возвращается обратно в СХД. Это обеспечивает более эффективное использование дисковой ёмкости, что особенно важно при большом количестве виртуальных машин и использовании thin-provisioned дисков.
Развитие интеграции с программно-определяемыми сетями
Релиз 4.5 усиливает нативную интеграцию Basis Dynamix Enterprise с решением для программно-определяемых сетей Basis SDN и расширяет сетевые возможности платформы. Например, при создании виртуальных машин появилась возможность автоматически подключать SDN-сегменты с одновременным созданием логических портов, что сокращает объём ручной настройки и упрощает работу администраторов.
Автоматизация управления узлами
В Basis Dynamix 4.5 появился механизм автоматического перевода физического узла из состояния «На обслуживании» в статус «Работает». Соответствующая настройка доступна на странице «Физические узлы» в интерфейсе системы. При этом вместе с узлом автоматически запускаются виртуальные машины, ранее закреплённые за ним на момент перевода в режим обслуживания. Функция применима как к отдельным узлам, так и к целым зонам, что упрощает эксплуатацию крупных инфраструктур.
Другие улучшения
Помимо этого, версия 4.5.0 включает ряд дополнительных улучшений, повышающих удобство администрирования:
Механизм Watchdog, обеспечивающий автоматическое восстановление зависших виртуальных машин.
Поддержка режима Cache Write Through, повышающего производительность дисковой подсистемы.
Упрощённая начальная установка за счёт минимального конфигурационного файла.
Обновление спецификации API до версии OpenAPI 3.1.0.
Доработка модели физического узла: понятие «вычислительный узел» (stack) было упразднено, а его функциональность перенесена в сущность «физический узел» (node), что позволило упростить как модель данных, так и API платформы.
Возможность при создании виртуальной машины, даже если она разворачивается не из образа, включать дополнительные возможности гипервизора — такие как NUMA, CPU pinning и Huge Pages.
Возможность сделать виртуальную машину доступной только для чтения для всех пользователей.
При создании ВМ можно задавать маску сети для интерфейсов DPDK и VFNIC, а также настраивать MTU для транковых сетей в диапазоне от 1500 до 9216.
Можно ограничивать количество узлов, обрабатываемых одновременно, и при этом сбой на одном узле не прерывает общий процесс.
После первичной установки реализовано автоматическое обновление API-ключа для служебного пользователя.
Комментарий разработчика
«Одной из важнейших задач в рамках развития нашей флагманской платформы Basis Dynamix Enterprise является поддержание её совместимости с актуальным инфраструктурным оборудованием и ПО. Это касается в том числе и нашего собственного решения для организации программно-определяемых сетей Basis SDN, которое успешно работает в тестовых средах заказчиков и быстро развивается с учётом их пожеланий. Нашей целью является не просто поддержка отечественных систем хранения данных, инструментов резервного копирования или других решений. Мы хотим дать заказчику возможность построить на базе Basis Dynamix Enterprise полностью импортонезависимую динамическую ИТ-инфраструктуру, не ограничивая его при этом в выборе поставщиков "железа" или программных продуктов»
— Дмитрий Сорокин, технический директор компании «Базис».
Несмотря на своё название, VCF Installer способен разворачивать как VMware Cloud Foundation (VCF), так и VMware vSphere Foundation (VVF). Многие ошибочно полагают, что установщик жёстко привязан к конкретному продукту в зависимости от имеющихся лицензий: VVF — для VVF-лицензий, VCF — для VCF-лицензий. На самом деле это не так.
VCF Installer не проверяет и не учитывает имеющиеся лицензии в момент развёртывания. Как VVF-, так и VCF-установки по умолчанию запускаются в режиме 90-дневного пробного периода. Лицензирование компонентов выполняется пользователем уже после завершения развёртывания — через VCF Operations, который обращается к Broadcom Business Service Console (BSC) для получения и применения соответствующих прав.
Гибкое развёртывание под разные сценарии
В зависимости от требований может возникнуть необходимость развернуть полный VCF-стек в основном дата-центре, а в региональном или граничном узле — только подмножество инфраструктурных компонентов. Один из типичных сценариев — развёртывание только компонентов VVF (VCF Operations, vCenter и ESX) с последующим лицензированием через VCF-права. Это полностью поддерживаемый вариант использования.
Конечно, отдельные компоненты можно развернуть вручную — через OVA VCF Operations и ISO-установщик vCenter. Однако VCF Installer предоставляет единый сквозной рабочий процесс: он разворачивает все компоненты VVF и автоматически их связывает. Весь процесс можно полностью автоматизировать, передав готовую JSON-конфигурацию.
Лицензирование через Broadcom BSC
После завершения развёртывания VCF Operations регистрируется в Broadcom Business Service Console (BSC), откуда получает и применяет соответствующие права — будь то VVF или VCF. Таким образом, выбор продукта при установке и применение лицензий — это два независимых этапа, которые не следует путать.
Отложенное развёртывание VCF Operations и VCF Automation
VCF Installer предоставляет дополнительную возможность — отложить развёртывание VCF Operations и/или VCF Automation. Это полезно, если требуется подключить их к альтернативным сетям (DVPGs или NSX-сегментам), отличным от Management Network, выбранной при начальной установке.
Часть организаций предпочитает отложить внедрение VCF Automation до того момента, когда они будут готовы перейти к современным методам доставки рабочих нагрузок через портал самообслуживания. В таком случае можно развернуть VCF-стек без VCF Automation, а позже добавить его как операцию Day-N через VCF Operations Fleet Manager.
Ключевой вывод
VCF Installer — крайне гибкий инструмент. Главное — не смешивать два разных понятия: тип развёртывания (VCF или VVF) и имеющиеся лицензионные права. Это две независимые вещи.
VCF Installer разворачивает как VCF, так и VVF вне зависимости от типа лицензий
Оба варианта запускаются с 90-дневным пробным периодом — до применения лицензий
Лицензии применяются через VCF Operations после развёртывания, через подключение к Broadcom BSC
Развёртывание VVF-компонентов с VCF-правами является полностью поддерживаемым сценарием
VCF Automation можно отложить и добавить позже как операцию Day-N
Полная автоматизация возможна через JSON-конфигурацию
Функция vSphere Configuration Profiles, впервые представленная в VMware vSphere 8.0, позволяет администраторам VMware Cloud Foundation управлять конфигурацией хостов ESX на уровне кластера. В данном материале рассматривается, чем эта функция отличается от Host Profiles, и как выполнить переход с Host Profiles на vSphere Configuration Profiles в vSphere 9.
Примечание: скриншоты и описанные шаги основаны на vSphere 9.0.2. В более ранних или более поздних версиях отдельные элементы интерфейса или формулировки могут отличаться.
О vSphere Configuration Profiles
vSphere Configuration Profiles — новая функция, впервые появившаяся в vSphere 8.0. Она является преемником Host Profiles в части управления конфигурацией хостов ESX в масштабе. Host Profiles неудобны тем, что требуют полного описания конфигурации хоста целиком. Это создаёт избыточную нагрузку на администраторов, которым, как правило, достаточно указать лишь те изменения, которые необходимо внести в конфигурацию.
vSphere Configuration Profiles, напротив, требует от администратора только определить отклонения от конфигурации по умолчанию. Это делает конфигурационный документ удобочитаемым и значительно более управляемым.
Переход с Host Profiles
Администраторы, управляющие конфигурацией хостов ESX с помощью Host Profiles в кластере, жизненный цикл которого управляется образами vSphere Lifecycle Manager, могут перевести кластеры на использование vSphere Configuration Profiles.
Примечание: использование vSphere Configuration Profiles с кластерами под управлением базовых уровней (baselines) поддерживается в vSphere 8 U3. Однако в vSphere 9 такие кластеры больше не поддерживаются, а Host Profiles считаются устаревшими, хотя и продолжают поддерживаться. Рекомендуется использовать кластеры под управлением образов vSphere Lifecycle Manager.
Перед переходом рекомендуется убедиться, что хосты ESX соответствуют текущему Host Profile. Ниже описан процесс перехода.
Управление конфигурацией на уровне кластера
Первый шаг — включить vSphere Configuration Profiles в кластере. Для этого перейдите в Cluster > Configure > Configuration в разделе Desired State и нажмите Create Configuration. Будут запущены проверки совместимости, чтобы убедиться, что кластер может быть переведён на vSphere Configuration Profiles. На рисунке 1 показан вариант запуска vSphere Configuration Profiles в существующем кластере.
Примечание: если к кластеру прикреплён Host Profile, появится предупреждение о необходимости удалить его после завершения перехода. После перехода Host Profiles не могут быть прикреплены ни к кластеру, ни к хостам внутри него. Этот процесс можно использовать и в том случае, если Host Profiles в данный момент не применяются.
Создание конфигурации
Далее необходимо указать, каким образом конфигурация хоста ESX для vSphere Configuration Profiles должна быть импортирована. Доступны два варианта:
Импорт с эталонного хоста.
Импорт JSON-файла с желаемой конфигурацией кластера.
Поскольку выполняется переход кластера, управляемого с помощью Host Profiles, предпочтительным вариантом является IMPORT FROM REFERENCE HOST. В качестве эталонного хоста можно выбрать любой хост ESX в кластере — все хосты уже должны соответствовать используемому Host Profile.
Примечание: при импорте с эталонного хоста любые отклонения от его конфигурации будут зафиксированы как переопределения хоста. Возможно, потребуется вручную проверить конфигурацию и удалить эти переопределения, если необходима единая конфигурация для всех хостов кластера.
На рисунке 2 показаны варианты импорта. Нажмите Import.
На рисунке 3 показан выбор эталонного хоста.
После импорта нажмите Next. Процесс импорта проверяет сгенерированный документ относительно всех хостов ESX в кластере. После успешной проверки нажмите Next. На рисунке 4 показан этап проверки конфигурации.
Предварительная проверка и применение
На последнем шаге vSphere Configuration Profiles проверяет хосты ESX в кластере на соответствие желаемой конфигурации и устраняет любые отклонения, обнаруженные в ходе проверки.
Примечание: поскольку выполняется переход с кластера под управлением Host Profile, исправлений не ожидается. Ознакомьтесь с влиянием изменений конфигурации на хосты. Нажмите Finish and Apply. На рисунке 5 показан предварительный просмотр эффекта применения. Нажмите Continue.
После этого сгенерированный vSphere Configuration Profile будет установлен в качестве желаемой конфигурации кластера, а все несоответствующие хосты ESX будут приведены в соответствие. На рисунке 6 показан диалог подтверждения завершения и применения.
Функция vSphere Configuration Profiles теперь включена, и доступен просмотр заданных конфигураций. На рисунке 7 показано, что конфигурация на уровне кластера включена.
На рисунке 8 показано соответствие хостов конфигурации кластера.
На завершающем шаге необходимо отсоединить Host Profile от хостов ESX.
Итог
Управление конфигурациями ESX остаётся непростой задачей в корпоративных средах. vSphere Configuration Profiles — новая возможность, впервые представленная в vSphere 8.0, которая решает эту задачу в масштабе большой инфраструктуры.
На Cloud Field Day 25 команда VMware представила серию докладов о том, как VMware Cloud Foundation (VCF) решает критически важные задачи корпоративной инфраструктуры. Сессии продемонстрировали уникальные возможности VCF: устранение глобального дефицита памяти, доставку сетевых сервисов по образцу публичного облака в частных облачных средах и организацию самообслуживаемого выделения баз данных.
Многоуровневое кэширование памяти на NVMe
Первую сессию открыл Дейв Морера (Dave Morera), старший технический архитектор по маркетингу, с докладом о технологии Advanced NVMe Memory Tiering в VCF. Память является самым дорогостоящим и ограничивающим узким местом современных датацентров: она сдерживает плотность виртуальных машин и увеличивает совокупную стоимость владения.
Технология Advanced NVMe Memory Tiering решает эту задачу за счёт интеллектуальной интеграции на уровне гипервизора: она автоматически распределяет данные между высокопроизводительным и более экономичным уровнями памяти. Результаты говорят сами за себя: организации могут достичь снижения TCO более чем на 40%, одновременно повышая плотность виртуальных машин и эффективность потребления ресурсов. Ключевое преимущество VCF — бесшовная интеграция непосредственно на уровне гипервизора. Вместо того чтобы рассматривать память как фиксированное аппаратное ограничение, VCF превращает её в динамический стратегический ресурс, адаптирующийся к требованиям рабочих нагрузок в реальном времени.
База данных как услуга без узких мест
Эрик Грей (Eric Gray), главный архитектор по техническому маркетингу, показал, как VMware Data Services Manager (DSM) устраняет давнюю проблему — узкие места при выделении баз данных. Базы данных с открытым исходным кодом — PostgreSQL и MySQL — пользуются высоким спросом, однако традиционный процесс их предоставления порождает очереди заявок, пробелы в управлении и риски.
DSM обеспечивает предоставление баз данных как услуги (DBaaS) по требованию на платформе VMware Cloud Foundation. Расширенный сервис для VCF обеспечивает защищённое самообслуживаемое развёртывание баз данных при сохранении видимости и контроля через политики инфраструктуры и управление доступом на основе ролей (RBAC). Решение автоматизирует развёртывание высокодоступных конфигураций, реплик для чтения, резервное копирование и восстановление на момент времени. Это превращает операции второго дня из обременительной работы в автоматизированную возможность. С помощью DSM команды разработчиков получают необходимую им гибкость, тогда как инфраструктурные команды сохраняют управление и операционный контроль.
Сетевые сервисы с гибкостью облака
В завершающей сессии выступил Дмитрий Десмидт (Dimitri Desmidt), старший технический менеджер продукта NSX, с докладом о сетевых возможностях VCF. Цель доклада состояла в том, чтобы развеять распространённое заблуждение: будто возможности физических фабрик VXLAN устраняют необходимость в программно-определяемых сетях. Доклад «Почему VCF Networking (NSX) необходим — даже в мире VXLAN» обосновал, почему современные частные облака требуют большего, чем просто базовое оверлейное соединение.
VCF Networking (NSX) отделяет сеть от физической фабрики, обеспечивая автоматизированные сетевые сервисы, управляемые политиками, которые нативно интегрируются с vCenter и VCF Automation. Эта интеграция даёт операционную простоту, недостижимую только за счёт физических фабрик. Особого внимания заслуживают виртуальные частные облака (VPC): они позволяют разработчикам мгновенно выделять защищённые многопользовательские среды без глубоких знаний в области сетевых технологий. VCF Networking — это не просто оверлей, а базовый уровень, открывающий гибкость, операционную простоту и подлинные облачные операционные модели внутри современного датацентра.
Ценностное предложение VCF
Три сессии на Cloud Field Day 25 продемонстрировали единую тему: VMware Cloud Foundation предоставляет возможности, которые решают реальные корпоративные задачи с измеримыми бизнес-результатами. Снижение TCO на 40% и более за счёт интеллектуального многоуровневого кэширования памяти, устранение узких мест при выделении баз данных, обеспечение облачной гибкости в частной инфраструктуре — всё это делает VCF фундаментом современных корпоративных ИТ. Полные записи докладов доступны в плейлисте Cloud Field Day 25 на YouTube и предлагают техническую глубину по каждой из обсуждённых возможностей.
В какой-то момент требования к ресурсам для Witness VM в vSAN ESA исчезли из официальной документации. Между тем этот вопрос остаётся актуальным: сколько памяти выделяется виртуальной машине и сколько у неё vCPU? Ответ зависит от выбранного профиля — Witness VM доступна в трёх вариантах: M, L и XL.
Выбор профиля определяется количеством виртуальных машин, которые планируется развернуть. При этом рекомендуется закладывать запас на рост. Когда Witness VM разворачивается через мастер развёртывания, нужные цифры там не указаны — однако их можно узнать, заглянув в OVF-дескриптор.
Из OVF-файла vSAN ESA Witness получены следующие данные о ресурсах:
vSAN ESA Witness XL — 8 vCPU, 64 ГБ памяти
vSAN ESA Witness L — 4 vCPU, 32 ГБ памяти
vSAN ESA Witness M — 4 vCPU, 16 ГБ памяти
Для тех, кто использует vSAN OSA, требования к ресурсам следующие:
vSAN OSA Witness XL — 6 vCPU, 32 ГБ памяти
vSAN OSA Witness L — 2 vCPU, 32 ГБ памяти
vSAN OSA Witness Normal — 2 vCPU, 16 ГБ памяти
vSAN OSA Witness Tiny — 2 vCPU, 8 ГБ памяти
Важно учитывать, что приведённые значения актуальны на момент публикации — с выходом новых версий vSAN требования к ресурсам могут измениться.
В сфере виртуализации и облачной инфраструктуры системные инженеры регулярно сталкиваются с задачами расчётов, проверки параметров конфигурации и подготовки инфраструктуры к развертыванию. Именно для таких задач создан сайт https://tools.virtualbytes.cloud/ — онлайн-площадка с полезными утилитами для специалистов по VMware-инфраструктуре и облачным платформам.
Что представляет собой сервис
Tools.VirtualBytes.Cloud — это коллекция веб-инструментов, предназначенных для работы с инфраструктурными компонентами VMware-экосистемы и сопутствующих технологий. Сервис позволяет использовать различные утилиты прямо в браузере без установки дополнительного программного обеспечения на локальную машину.
Основная идея платформы — предоставить инженерам быстрый доступ к вспомогательным инструментам, которые упрощают администрирование и проектирование виртуальной инфраструктуры.
Какие инструменты доступны онлайн
Сервис ориентирован на специалистов, работающих с современными датацентрами и программно-определяемыми инфраструктурами. Среди основных направлений инструментов:
Работа с платформой VMware Cloud Foundation (VCF)
Инструменты для VMware NSX и сетевой виртуализации
Вспомогательные утилиты для vSAN
Сетевые и инфраструктурные калькуляторы
Инструменты для анализа и подготовки конфигураций
Благодаря веб-формату инструменты можно использовать с любого устройства — достаточно открыть сайт в браузере.
Бесплатные онлайн-утилиты
VCF Pre-Deployment Checklist
Интерактивный чеклист, охватывающий все требования перед развертыванием VCF — DNS, NTP, сетевую инфраструктуру, оборудование, лицензии, сертификаты, порты файрвола и многое другое. Позволяет добавлять заметки и экспортировать результат в PDF.
VCF Upgrade Path Advisor
Визуальный планировщик путей обновления для VMware Cloud Foundation версий 4.0–9.0. Использует поиск оптимального пути (BFS) между поддерживаемыми этапами обновления и предупреждает о промежуточных версиях.
VCF Host Sizing Calculator
Калькулятор минимального количества хостов для доменов нагрузки VCF с учетом отказоустойчивости N+1 и N+2. Учитывает накладные расходы vSAN, резервации HA и нагрузку management-компонентов.
IP Subnet Planner
Калькулятор подсетей VLSM и планировщик диапазонов IP-адресов для сетей VCF: management, vMotion, vSAN и NSX TEP. Проверяет пересечения подсетей и позволяет экспортировать готовый IP-план для развертывания.
MTU Path Calculator
Калькулятор эффективного MTU для overlay-сетей GENEVE и VXLAN. Моделирует накладные расходы инкапсуляции на каждом уровне и проверяет требования к jumbo-фреймам для NSX-инфраструктуры.
VLAN Allocation Planner
Инструмент для проектирования полного диапазона VLAN с использованием 9 шаблонов VCF. Включает обнаружение конфликтов, автоматическое заполнение подсетей, контроль соглашений по именованию, заметки по L3-маршрутизации и экспорт конфигураций коммутаторов для Arista, Cisco NX-OS, IOS-XE и Juniper.
VCF 9 Network Config Generator
Генератор полной сетевой конфигурации для VCF 9, включая назначение VLAN, параметры MTU, политики teaming и конфигурацию пулов NSX TEP для развертываний с несколькими кластерами.
vSAN Capacity Calculator
Калькулятор полезной емкости vSAN для архитектур OSA и ESA с политиками RAID-1, RAID-5 и RAID-6. Учитывает slack space, отказ хостов и приблизительную эффективность дедупликации.
NSX Firewall Rule Planner
Инструмент для планирования и документирования правил распределенного файрвола NSX. Позволяет задавать группы источников и назначений, сервисы и область применения (Applied-To), проверяет логику правил и экспортирует их в структурированную таблицу.
VCF Day 2 Operations Planner
Набор пошаговых runbook-процедур для операций Day-2: расширение кластера, создание доменов нагрузки, ротация сертификатов, обновление компонентов, смена паролей, расширение vSAN и управление сегментами NSX.
Для кого предназначен сайт
Платформа будет полезна:
Системным администраторам и инженерам виртуализации
Архитекторам облачной инфраструктуры
DevOps-специалистам
Инженерам датацентров и лабораторий
Особенно ценным ресурс становится при работе с VMware-экосистемой, где часто требуется быстро рассчитать параметры инфраструктуры или проверить настройки перед развертыванием.
Итог
Tools.VirtualBytes.Cloud — это полезный ресурс для специалистов по виртуализации и облачным технологиям. Он объединяет набор практических инструментов, которые помогают упростить работу с инфраструктурой VMware и ускорить решение повседневных задач администрирования.
Для инженеров, работающих с VCF, NSX и другими компонентами программно-определяемого дата-центра, подобные сервисы позволяют экономить время и повышать эффективность управления инфраструктурой.
Сегодня мы рассмотрим вопросы о неизменяемости (immutability) в Kubernetes. На фоне новой волны интереса особенно заметно, что сообщество Kubernetes рассматривает эту тему с иной точки зрения, чем раньше. Пользователи меньше сосредоточены на неизменяемости на уровне отдельного узла и больше интересуются тем, как принципы неизменяемости применяются при управлении целым парком кластеров. Именно это является фундаментальной причиной существования проекта Cluster API.
Почему неизменяемость важна
Значимость неизменяемости проистекает из тех преимуществ, которые этот подход даёт приложениям, работающим поверх Kubernetes. Наиболее важные преимущества, которые пользователи Kubernetes получают благодаря неизменяемости, приведены ниже.
Скорость
В современной ИТ-среде скорость имеет первостепенное значение. Например, скорость необходима, когда нужно масштабировать инфраструктуру для обработки всплесков пользовательских запросов, она нужна при выполнении blue/green-развертываний или при масштабировании инфраструктуры вниз, чтобы держать под контролем стоимость приложений или освобождать ресурсы для других задач.
Скорость также критически важна при выполнении операций обслуживания, которые должны укладываться в ограниченное временное окно, или при реагировании на любые виды сбоев — от проблем с одним экземпляром приложения до ситуаций, когда выходит из строя целый регион.
Неизменяемость является фундаментальной основой для достижения скорости во всех этих сценариях и не только. Именно благодаря неизменяемости можно использовать инструменты, позволяющие за миллисекунды запускать десять идентичных Pod’ов, за секунды создавать новые клоны машин, на которых размещаются узлы Kubernetes, или за минуты поднимать новый полностью работоспособный кластер Kubernetes.
Операции в масштабе
С определённой точки зрения современные ИТ-операции находятся на пересечении масштаба и скорости. Неизменяемость крайне важна для решения подобных задач, потому что она создаёт основу для создания согласованных и доверенных клонов ваших Pod’ов, виртуальных машин и даже всего кластера Kubernetes.
Когда вы начинаете использовать такие доверенные клоны, появляется уверенность, что среды разработки, QA и production ведут себя одинаково. Без доверенных клонов вашей операционной команде придётся сталкиваться с дрейфом конфигураций, а «снежинки» (уникальные, неповторимые конфигурации хостов) плохо масштабируются.
Безопасность
Неизменяемость также часто связывают с безопасностью. Хотя это в целом верно, есть несколько уникальных преимуществ, которые неизменяемость даёт именно с точки зрения безопасности. При этом для некоторых аспектов безопасности существуют и другие достойные альтернативы, которые организации могут и должны рассматривать.
Например, одно из уникальных преимуществ — неизменяемость создаёт основу для построения систем, в которых базовые виртуальные машины являются эфемерными, поскольку они периодически пересоздаются «с нуля». Это создаёт движущуюся цель, значительно усложняя работу злоумышленников.
С другой стороны, например, неизменяемая операционная система может успешно использоваться для уменьшения поверхности атаки внутри виртуальной машины, но многие организации достигают той же цели с помощью AppArmor, SELinux, защищённых образов и других механизмов.
Продолжая тот же пример, процесс обновления A/B, характерный для неизменяемых ОС, также может иметь достойную и, возможно, более надёжную альтернативу — когда изменения разворачиваются путём создания новых машин и удаления старых. Результат тот же, но используются простые примитивы создания и удаления — такие же, какие Kubernetes применяет для Pod’ов.
Стабильность
Инженеры-разработчики те, кто поддерживает open source-проекты, постоянно сталкиваются с тем, что у любого проекта или системы есть ограниченный «бюджет сложности», который она может выдержать за определённое время. Когда этот бюджет исчерпывается, начинаются проблемы. Снижается качество, и становится сложно своевременно исправлять ошибки и уязвимости (CVE).
Неизменяемость значительно помогает справляться с этим бюджетом сложности. Она позволяет инженерам резко сократить количество переменных, которые нужно учитывать, например, при управлении жизненным циклом объектов вроде виртуальной машины, на которой работает узел Kubernetes. В результате системы, основанные на принципах неизменяемости, обычно обеспечивают более простую, стабильную и надёжную платформу для приложений. А стабильность и надёжность важны как сегодня, так и для долгосрочной устойчивости вашего технологического стека.
Как добиться неизменяемости в Kubernetes
В своей основе неизменяемость — это концепция, философия. Чтобы сделать её реальностью, нужны технологии, которые поддерживают этот подход. Kubernetes - отличная отправная точка: он предоставляет такие примитивы, как неизменяемые Pod’ы, а также более высокоуровневые абстракции - например Deployments и StatefulSet - для управления ими.
Однако Kubernetes не управляет базовой инфраструктурой. Именно здесь появляется Cluster API, поскольку один из фундаментальных принципов проекта — «Kubernetes на всех уровнях». Cluster API позволяет рассматривать Machine (элемент инфраструктуры, например виртуальную машину, на которой работает узел Kubernetes) как неизменяемый компонент.
Когда требуется изменение, вместо модификации существующей машины Cluster API создаёт новую и удаляет старую — аналогично тому, как Kubernetes заменяет Pod’ы. Предоставляя абстракции для управления группами машин, такие как KubeadmControlPlane и MachineDeployment, Cluster API позволяет усиливать преимущества неизменяемости при управлении целым кластером или даже парком кластеров.
Если вы хорошо знакомы с Cluster API, вы можете заметить, что здесь есть серая зона — операционная система, установленная на машине, управляемой CAPI. Cluster API не занимает жёсткой позиции относительно операционной системы на машине, потому что, как показал опыт последних лет, именно здесь разные организации и продукты могут и должны применять разные подходы.
Во-первых, у каждой организации есть собственные предпочтения относительно используемой ОС и допустимых компромиссов на уровне операционной системы. Во-вторых, многие организации не хотят вводить особый подход к операционной системе машин в кластере Kubernetes. Они предпочитают иметь одну поддерживаемую ОС и использовать её на разных платформах и для разных типов приложений — и чаще всего это не неизменяемая ОС.
Ключом к работе с такими различными требованиями и технологиями являются многочисленные точки расширения Cluster API. Используя эти точки расширения, теперь можно выполнять тщательно проверенный набор операций обновления «на месте» безопасным и полностью автоматизированным способом.
Несколько примеров
Пошаговые обновления (rolling upgrades)
Вместо выполнения сложных процедур обновления существующих машин Cluster API проводит rollout, при котором создаются новые «чистые» машины для замены старых. Этот подход, основанный на принципах неизменяемости, позволяет не только выполнять обновления Kubernetes, но и вносить любые изменения в машины (инфраструктура, ОС и компоненты Kubernetes), используя два простых примитива: создание и удаление Machine.
Процесс по своей природе повторяем и предсказуем; замена каждой машины гарантирует, что каждый узел достигнет желаемого состояния без сюрпризов, часто вызванных конфигурационным дрейфом. Это просто, надёжно, быстро и безопасно.
Кроме того, Cluster API гарантирует соблюдение требований к доступности во время rollout. Он также поддерживает цепочные обновления Kubernetes через несколько минорных версий, а рабочие узлы могут пропускать промежуточные минорные версии, если это допускается политикой version skew Kubernetes.
Восстановление нездоровых машин
Как поступить с машинами, которые постоянно работают некорректно — например, когда узел Kubernetes, размещённый на машине, сообщает состояние Ready = false более пяти минут? Cluster API позволяет определить MachineHealthChecks для обработки таких случаев. Когда запускается автоматическое восстановление, система использует принцип неизменяемости для быстрого и эффективного решения проблемы: быстро создаётся новая «чистая» машина-замена, а старая удаляется — снова используя те же два простых примитива: создание и удаление Machine.
Избегание ненужных rollout’ов
Машины — сложные компоненты, и иногда требуется внести изменения, которые не требуют drain узла или перезапуска Pod’ов; например, изменение сертификата реестра образов.
Если по какой-то причине вы хотите выполнить такие изменения без полного rollout машины, Cluster API предоставляет точки расширения, позволяющие выполнить тщательно проверенный набор обновлений «на месте» безопасным и полностью автоматизированным способом. Даже в этих случаях конфигурационный дрейф предотвращается за счёт одинакового применения изменений ко всем машинам.
Тот же пользовательский опыт, неизменяемость и лучшие стороны изменяемой инфраструктуры — всё под строгим контролем.
Итоги
Неизменяемость лежит в основе многих cloud-native систем, поскольку она обеспечивает скорость, масштабируемость операций и более сильные практики безопасности. В то же время сочетание неизменяемой инфраструктуры с тщательно контролируемыми изменяемыми операциями позволяет организациям использовать и другие проверенные операционные подходы там, где это уместно.
Именно этот баланс между неизменяемой и изменяемой инфраструктурой позволяет командам достигать скорости, безопасности и надёжности при управлении Kubernetes в большом масштабе.
В последнем выпуске подкаста Virtually Speaking Ли Ховард, руководитель IAM Product Management в Broadcom, рассказал, как Identity Security для VMware Cloud Foundation (VCF) обеспечивает безопасный, масштабируемый доступ с нулевым доверием в современных средах частного облака.
Этот выпуск является частью серии VCF Advanced Services, где освещаются возможности, усиливающие безопасность, соответствие требованиям и операционный контроль сверх базовой инфраструктуры.
В этом видео объясняется, почему идентификация больше не может рассматриваться как дополнительная функция безопасности. В мире Kubernetes-нагрузок, приложений, управляемых через API, систем AI и требований суверенных облаков идентификация должна быть фундаментальной.
От статической аутентификации к Zero Trust
Традиционные стратегии управления идентификацией строились вокруг служб каталогов, статических политик и базового единого входа. Эта модель работала, когда приложения были централизованы, а пользователи действовали в пределах определённых сетевых границ. Современное частное облако устроено иначе.
Пользователи распределены. Приложения контейнеризированы. Сервисы аутентифицируются друг перед другом. AI-агенты и платформы автоматизации действуют самостоятельно. В такой среде идентификация должна быть непрерывной, контекстной и учитывающей риски.
Архитектура нулевого доверия оценивает не только то, кто входит в систему, но и как, откуда и к чему именно пытается получить доступ. Безопасность идентификации становится динамической, адаптируясь к поведенческим сигналам, уровням привилегий и контексту среды. Именно здесь современные возможности IAM и PAM становятся критически важными.
IAM и PAM в VMware Cloud Foundation
Identity and Access Management (IAM) управляет аутентификацией, авторизацией и федерацией, используя такие стандарты, как SAML и OpenID Connect. В частном облаке, построенном на VMware Cloud Foundation, IAM должен быть управляемым через API и дружественным к DevOps, позволяя командам разработки интегрировать идентификацию в современные рабочие процессы без жёстких проприетарных ограничений.
Privileged Access Management (PAM) защищает наиболее чувствительный уровень среды: административный доступ и доступ уровня root. PAM обеспечивает доступ с минимально необходимыми привилегиями, хранит учётные данные в защищённых хранилищах, автоматически ротирует пароли и записывает привилегированные сессии. Это снижает риск внутренних угроз, злоупотребления учётными данными и горизонтального перемещения во время взлома.
Важно, что безопасность идентификации теперь распространяется не только на человеческих администраторов. Машинные идентификаторы, сервисные аккаунты и системы автоматизации также должны находиться под управлением. По мере роста Kubernetes-нагрузок и AI-систем управление секретами и доступом нечеловеческих субъектов становится столь же важным, как и управление входом пользователей.
Нативная для Kubernetes идентификация в частном облаке
Платформа Identity Security работает на Kubernetes внутри VMware Cloud Foundation. Такая облачно-нативная архитектура обеспечивает быстрое развертывание, автоматическое масштабирование при всплесках аутентификации и обновления без простоев.
Сервисы идентификации являются критически важными. Если аутентификация не работает, не работает ничего. Архитектура на базе Kubernetes обеспечивает устойчивость и операционную эффективность, одновременно устраняя необходимость избыточного резервирования ресурсов, характерную для устаревших систем идентификации.
Идентификация как ключевая возможность платформы
По мере того как организации пересматривают размещение нагрузок, требования суверенности и стратегии внедрения AI, идентификация становится центральным элементом архитектуры частного облака. Она должна поддерживать доступ по модели нулевого доверия, соответствие нормативным требованиям, управление машинными идентификациями и единый контроль в разных средах.
Безопасность идентификации больше не ограничивается входом в систему. Речь идёт о контроле доступа повсюду — для пользователей, приложений, сервисов и данных. И в современной среде VMware Cloud Foundation она встроена непосредственно в саму платформу.
Что дальше в серии роликов?
Этот выпуск является частью продолжающейся серии Virtually Speaking, посвящённой Advanced Services, доступным в VMware Cloud Foundation. В каждом выпуске специалисты VMware подробнее рассматривают конкретный сервис и практические результаты, которые он обеспечивает, вместе с людьми, которые ежедневно создают и внедряют эти решения.
В следующих выпусках будут освещаться сервисы, расширяющие возможности VCF за пределы базовой инфраструктуры, включая такие области, как продвинутые сети, безопасность, сервисы данных, наблюдаемость и AI. Цель этих роликов — показать, как эти возможности работают вместе, помогая организациям модернизировать инфраструктуру, защищать приложения и ускорять инновации.
RSS
