Инфраструктурные команды сталкиваются с парадоксом: среды становятся все сложнее, а бюджеты и численность персонала остаются прежними. VMware Cloud Foundation (VCF) 9.1 призвана ответить на эту проблему инновациями, которые повышают эффективность, ускоряют доставку приложений и усиливают киберустойчивость, сохраняя при этом простоту эксплуатации. За последние несколько лет разговор об инфраструктуре изменился. Вопрос уже не только в том, где выполняются рабочие нагрузки, но и в том...
Медленная работа приложений и простои серьезно влияют на удовлетворенность клиентов, вызывают перебои в бизнес-процессах и могут отражаться на выручке. Когда критически важное приложение дает сбой в сложной распределенной среде, главная трудность заключается в том, чтобы быстро определить первопричину. Во время инцидентов высокой важности ИТ-команды оказываются в ситуационных комнатах для диагностики, где снова и снова возникает один и тот же вопрос: проблема находится в базовой инфраструктуре или в самом приложении?
При традиционном подходе сетевые, инфраструктурные и DevOps-команды вынуждены работать изолированно. Они используют разные инструменты и разрозненные наборы данных, не имея сквозной видимости. В результате возникает изматывающий цикл обмена сообщениями туда и обратно. Поиск первопричины превращается в тяжелый и медленный процесс, который занимает дни, а иногда и недели. Устаревшие балансировщики нагрузки, хотя и видят транзакции как со стороны клиента, так и со стороны сервисов, способны предоставлять только фрагментированные метрики.
Как Avi ускоряет диагностику с помощью App Health Score
Программно-определяемая архитектура балансировки нагрузки Avi является основой его аналитического преимущества. Avi собирает полную телеметрию на уровне транзакций по каждому потоку и показывает ее в единой панели управления. Благодаря этому разрозненные команды получают доступ к одной и той же сквозной аналитике задержек приложения на стороне клиента, сервера и самого приложения. Все участники могут быстро и точно определить первопричину узких мест производительности или угроз безопасности. Рассмотрим подробнее.
Сокращение Mean Time to Innocence (MTTI) за счет детальной аналитики:
Avi Analytics сводит данные о производительности приложений в понятные оценки здоровья от 0 до 100. Avi App Health Score дает комплексную оценку общего состояния приложения или виртуального сервиса, объединяя показатели производительности, доступности ресурсов, аномального поведения и факторов риска безопасности. Эти оценки дают администраторам практические подсказки и позволяют быстро находить проблемы прямо на панели управления. Например, желтая оценка 72 для «confluence prod» сразу указывает на деградацию сервиса из-за базовых ресурсов и подсвечивает критические проблемы вместе с релевантной диагностической информацией.
Кроме того, Avi Analytics существенно сокращает MTTI, предоставляя детальную видимость каждой транзакции приложения. Централизация этих метрик в единой панели помогает кросс-функциональным командам сразу понять, что задержка 75 мс возникает в приложении, а не в сети или на стороне клиента. Такой подход на основе данных сокращает длительный триаж и позволяет организациям с высокой точностью определить конкретный источник проблем производительности.
Повышение устойчивости приложений благодаря встроенной веб-безопасности:
Интегрируя сведения о безопасности непосредственно в App Health Score, Avi улучшает защиту приложений за счет встроенного web application firewall (WAF). Аналитика платформы в реальном времени выявляет частые ошибки соединений и отмечает сложные веб-атаки, включая DDoS-атаки: от обнаружения до автоматического смягчения последствий проходят минуты. В результате устойчивость приложений повышается, а высокая доступность и производительность сохраняются даже при большой нагрузке или целевых веб-угрозах.
Минимизация простоя приложений за счет выявления временных проблем:
Avi ускоряет анализ первопричин, используя глубокую историческую аналитику и избавляя команды от необходимости ждать, пока периодическая проблема повторится. Традиционным аппаратным балансировщикам нагрузки почти невозможно находить временные аномалии уровня «иголка в стоге сена», тогда как подробные журналы транзакций Avi позволяют инженерам переходить к конкретным IP-адресам серверов пула и выявлять исчерпание ресурсов виртуальных машин, то есть базовую проблему на стороне приложения.
Преимущество Avi Analytics: аналитика задержек приложений
Устаревшие балансировщики нагрузки уже не соответствуют требованиям современных приложений к производительности, гибкости и масштабируемости. Диагностика проблем производительности приложений стала реактивным и утомительным процессом. Avi собирает аналитику прямо из трафика и предоставляет единый «источник истины», который сокращает длительный операционный триаж между сетевыми, безопасностными и прикладными командами.
Программно-определяемая архитектура: Avi обеспечивает глубокую видимость в реальном времени, разделяя централизованную плоскость управления и распределенную плоскость данных. Avi развертывается как виртуальные машины рядом с вычислительной инфраструктурой. Он собирает детальную телеметрию из потока трафика и дает комплексную аналитику со сквозной видимостью из одной консоли, чтобы ускорять диагностику, автоматизировать масштабирование и заранее поддерживать высокую производительность приложений.
Полнота данных и охвата: Avi Controller непрерывно агрегирует более 700 метрик производительности из распределенных балансировщиков нагрузки. Используя высокопроизводительные вычислительные ресурсы, Avi обрабатывает крупное озеро телеметрических данных и применяет расширенные ML/AI-выводы для анализа паттернов и аномалий. Avi Analytics преобразует инфраструктурные данные в практические сведения о приложениях, позволяя ИТ-командам перейти от реактивного устранения неполадок к проактивной оптимизации.
Контекст VCF без сложной настройки: Avi глубоко и нативно интегрируется с частным облаком VCF. Благодаря контексту рабочих нагрузок VCF Avi обеспечивает согласованную видимость для виртуальных машин и контейнеров. Такая контекстная осведомленность связывает доставку и безопасность приложений с инфраструктурой, уменьшает слепые зоны и упрощает балансировку нагрузки в VCF.
Как крупная финансовая организация сократила количество заявок на 90%
Сетевые команды одной очень крупной финансовой организации до внедрения Avi Analytics постоянно были перегружены большим накопившимся объемом заявок на диагностику приложений. Ограниченная видимость, которую давали устаревшие балансировщики нагрузки, приводила к тому, что все проблемы приложений направлялись сетевым командам, даже если сеть не была их причиной. Это создавало серьезное узкое место: операционные специалисты обрабатывали почти все заявки.
После развертывания Avi Analytics организация предоставила более чем 50 DevOps-командам прямой доступ к единой аналитической панели. Команды получили практические сведения по более чем 90 000 виртуальных IP-адресов и смогли самостоятельно диагностировать, находится ли причина проблемы в приложении или в сети.
Переход к современной балансировке нагрузки на основе аналитики привел к резкому сокращению количества заявок, связанных с приложениями, которые попадали в сетевую команду: их стало меньше на 90%. В результате операционные специалисты смогли перераспределить ресурсы с обработки заявок на более ценные стратегические проекты, что показывает явное преимущество такого подхода по сравнению с традиционной балансировкой нагрузки.
Функционал vSphere Configuration Profiles помогает администраторам VMware Cloud Foundation управлять настройками ESX-хостов не по отдельности, а на уровне всего кластера. Такой подход удобен, когда нужно не только поддерживать единый стандарт внутри одного кластера, но и переносить уже проверенную конфигурацию в другие кластеры.
Примечание: описанные шаги и интерфейсные элементы относятся к VMware vSphere 9.0.2. В других версиях названия пунктов меню и формулировки могут отличаться.
Что такое vSphere Configuration Profiles
vSphere Configuration Profiles появилась в vSphere 8.0 как развитие идеи Host Profiles для масштабного управления конфигурацией ESX-хостов. В Host Profiles администратору приходилось описывать конфигурацию целиком, что усложняло работу: часто известны только конкретные изменения, которые нужно внести, а не весь полный набор настроек.
В vSphere Configuration Profiles требуется зафиксировать только отличия от конфигурации по умолчанию. Благодаря этому профиль получается более понятным для человека, проще читается и легче поддерживается.
Перенос конфигурации в новые кластеры
Один из типовых сценариев управления конфигурацией — обеспечить одинаковые настройки сразу в нескольких кластерах vSphere. vSphere Configuration Profiles делает такой перенос достаточно прямолинейным: желаемое состояние можно экспортировать из существующего кластера, скорректировать уникальные параметры хостов и затем импортировать в новый кластер.
Совет: конфигурацию можно подготовить для кластера еще до добавления в него ESX-хостов. Для этого нужно заранее знать Host BIOS UUID будущих хостов.
Ниже приведен рабочий процесс копирования конфигурации из одного кластера в другой.
Экспорт конфигурации из существующего кластера
Сначала нужно выгрузить желаемую конфигурацию из уже настроенного кластера. В интерфейсе vSphere следует открыть Cluster, затем Configure, затем Configuration в разделе Desired State. Экспортированный файл будет сохранен в формате JSON.
Внутри JSON находятся как общие для кластера настройки, так и уникальные атрибуты отдельных хостов, например IP-адреса и имена хостов. Минимальная обязательная правка перед переносом — заменить host-specific секцию vSphere Configuration Profile на значения, соответствующие целевому кластеру.
Перед импортом полезно понимать структуру JSON-файла профиля. В секции profile > esx находятся настройки, не зависящие от конкретного хоста. Такие параметры можно применить ко всем хостам кластера, поскольку они не содержат уникальных значений для отдельного сервера.
Настройки vSphere Distributed Switch, Port Groups или Datastores могут отличаться от кластера к кластеру, поэтому при необходимости их нужно менять в соответствующих разделах JSON. В демонстрационном сценарии используются те же vSphere Distributed Switch, Port Groups и Datastores, что и в исходном кластере.
Основное внимание при переносе нужно уделить секции host-specific. В показанном примере уникальными значениями для хостов являются IP-адреса трех vmkernel-интерфейсов и имя хоста.
Каждый ESX-хост в host-specific разделе идентифицируется через Host UUID. Этот идентификатор также называют BIOS UUID, поскольку он уникален на уровне аппаратной платформы. В актуальных версиях vSphere и VCF проще всего получить Host UUID через PowerCLI, подключившись к vCenter или напрямую к ESX-хосту.
После этого в JSON-файле нужно заменить Host UUID, IP-адреса, маски подсети и имена хостов для каждого сервера целевого кластера. При необходимости хосты можно добавлять или удалять, но важно следить за корректным синтаксисом JSON, особенно за запятыми между элементами.
Импорт обновленной конфигурации в новый кластер
Если целевой кластер еще не создан с включенными vSphere Configuration Profiles или пока не переведен на них, обновленный JSON можно импортировать через workflow перехода на vSphere Configuration Profiles.
Если кластер уже использует vSphere Configuration Profiles, нужно открыть вкладку Draft, выбрать Import From File и загрузить подготовленный JSON-файл.
Затем на вкладке Draft нужно выбрать Apply Changes, чтобы выполнить remediation и применить импортированную конфигурацию. Перед фактическим применением стоит внимательно пройти окна Pre-check, Remediation Settings и Review Impact.
Pre-check проверяет готовность хоста к remediation, включая возможность перевести его в maintenance mode. Также учитывается, включен ли DRS, чтобы при необходимости автоматически эвакуировать виртуальные машины с хоста. Окно Remediation Settings показывает текущие параметры remediation, унаследованные от vSphere Lifecycle Manager.
В окне Review Impact на вкладке Host-Level Details можно раскрыть каждый хост и увидеть, какие именно изменения будут применены. Там же отображается, потребуется ли конкретному хосту переход в maintenance mode.
После проверки влияния изменений остается нажать Remediate, чтобы применить конфигурацию к кластеру.
Итог
vSphere Configuration Profiles позволяет переносить стандартную конфигурацию из одного кластера в другой без ручного повторения всех настроек. Это помогает поддерживать единое желаемое состояние как внутри отдельного кластера, так и между несколькими кластерами vSphere.
В настройках кластера VMware vSphere High Availability существует параметр Performance degradation VMs tolerate, который определяет допустимый уровень снижения производительности виртуальных машин при отказе одного из хостов кластера.
По умолчанию значение параметра установлено в 100%, что фактически означает отсутствие ограничений по деградации производительности в аварийном сценарии. При таком значении система не будет предупреждать администратора о возможном ухудшении SLA виртуальных машин после отказа узла.
Как работает параметр
Механизм оценивает, смогут ли уже запущенные виртуальные машины сохранить сопоставимый объем вычислительных ресурсов после отказа одного хоста. Логика работы следующая:
Рассматривается сценарий отказа одного узла кластера.
Оценивается суммарная доступная вычислительная емкость после отказа.
С помощью VMware Distributed Resource Scheduler DRS моделируется перераспределение работающих виртуальных машин на другие хосты ESX.
Проверяется, какой уровень снижения ресурсов (CPU / Memory) получат виртуальные машины.
Если ожидаемая деградация превышает заданный порог, генерируется предупреждение.
Важно! Это не блокирующий механизм. Даже при появлении предупреждения запуск новых виртуальных машин остается возможным - параметр выполняет исключительно функцию оповещения.
Требования для работы
Для корректной работы параметра необходим работающий DRS, но включенный Admission Control не требуется. Это частое заблуждение: параметр не использует настройки Admission Control (например, Host failures cluster tolerates). Вместо этого он самостоятельно моделирует отказ одного хоста и анализирует последствия для производительности виртуальных машин.
Практический смысл настройки
Параметр полезен в сценариях, когда:
В кластере высокая консолидация нагрузки.
Виртуальные машины активно используют CPU / RAM выше уровня reservation.
Ресурсы после отказа хоста могут оказаться достаточными для запуска ВМ, но недостаточными для сохранения нужной производительности.
Пример:
Допустим, кластер работает с загрузкой 80–85%. После выхода одного узла из строя оставшиеся хосты смогут принять виртуальные машины, однако фактическая доступность ресурсов для каждой машины снизится.
50% — допускается существенное снижение производительности
100% — предупреждения фактически отключены
Рекомендации по настройке
Практически значение 100% малоинформативно, так как не дает сигналов о потенциальной проблеме.
Часто используются значения:
0–10% — для критичных production-нагрузок
25% — сбалансированный вариант
50% — для сред с менее строгими SLA
Выбор зависит от допустимого уровня деградации сервисов при аварийном восстановлении.
Вывод
Параметр Performance degradation VMs tolerate — это механизм оценки риска снижения производительности ВМ при отказе узла, а не механизм резервирования ресурсов.
Его особенности:
Анализирует сценарий отказа одного хоста
Требует DRS
Не зависит от Admission Control
Не запрещает запуск ВМ
Предупреждает о возможном ухудшении производительности
Настройка позволяет заранее понять, насколько кластер готов к отказу оборудования с точки зрения SLA, а не только с точки зрения возможности перезапуска виртуальных машин.
DVD Store — это инструментарий для тестирования баз данных с открытым исходным кодом, который активно применяется с момента своего первого релиза в 2005 году. Он поддерживает работу с СУБД SQL Server, Oracle, PostgreSQL и MySQL. DVD Store моделирует интернет-магазин, в котором пользователи авторизуются, просматривают каталог, оставляют отзывы, выставляют оценки и покупают DVD. В тесте задействуется большое число типичных возможностей реляционных БД: хранимые процедуры, индексы, внешние ключи, полнотекстовый поиск, сложные запросы с множественными join'ами и транзакции.
Изначально DVD Store разрабатывался как нагрузка, ориентированная преимущественно на CPU. Тем не менее в нём с самого начала были предусмотрены параметры, позволяющие менять этот профиль и переключаться на сценарии, в которых акцент делается на сеть, дисковую подсистему или даже память. Примеры таких профилей теперь добавлены и описаны в основном репозитории DVD Store на GitHub: https://github.com/dvdstore/ds35/tree/main/workload_profiles
VMware провела тестирование тестирование платформы VMware vSphere с помощью этого инструмента для того, чтобы понять, насколько эти профили меняют поведение нагрузки относительно стандартного CPU-ориентированного сценария. Все измерения проводились на одной виртуальной машине, развёрнутой на сервере ESX 9.0 платформы VMware Cloud Foundation (VCF). ВМ работала под управлением Windows Server 2022, в качестве СУБД использовалась SQL Server 2022. Все показатели производительности фиксировались со стороны хоста ESX с помощью утилиты esxtop (аналог linux top, но адаптированный под ESX и собирающий значительно более широкий набор метрик).
CPU Utilization — загрузка процессора на хосте ESX
Disk I/O per second (IOPS) — операции чтения и записи на диск со стороны хоста ESX
Mb received per second (Mb Rec/s) — мегабиты, принятые в секунду по сети
Mb sent per second (Mb Sent/s) — мегабиты, отправленные в секунду по сети
Active Memory (ActiveMem) — объём памяти, к которой недавно было обращение (активная память)
Относительное изменение ключевых метрик в разных профилях нагрузки
Для построения базовой линии замеры выполнялись на CPU-ориентированном профиле. Затем те же тесты были проведены с профилями, акцентированными на диск, на максимально высокий IOPS, на сеть и на память; полученные значения ключевых метрик сопоставлялись с базовыми. На графиках ниже показаны относительные различия по этим метрикам относительно базового CPU-профиля. На первом графике приведены все профили нагрузки; на втором профиль highIOPS убран, чтобы наглядно увидеть различия между остальными.
Если кратко резюмировать результаты, то в ключевой для каждого профиля метрике заметен значительный прирост:
Disk-профиль выдаёт в 13 раз больше IOPS
HighIOPS-профиль обеспечивает в 95 раз больше IOPS — это в 7 раз выше, чем у Disk-профиля
Network-профиль увеличивает количество отправленных мегабит в секунду в 15 раз
Memory-профиль вызывает в 2,9 раза большее значение активной памяти
Подробное описание всех профилей нагрузки приведено в файле ds35_workload_profiles.txt в репозитории DVD Store на GitHub. Там же указаны конкретные параметры DVD Store, особенности конфигурации БД и краткие пояснения к каждому сценарию.
Облачные нативные приложения обеспечивают гибкость, масштабируемость и более быструю доставку сервисов, однако они также вносят новую операционную сложность. В средах Kubernetes рабочие нагрузки являются эфемерными, сервисы распределены, а телеметрия генерируется в больших объёмах на разных уровнях стека. Компания VMware выпустила новый документ "Observability on vSphere Kubernetes Service", в котором рассматривается, как решить эту задачу на платформе VMware Cloud Foundation (VCF) с использованием vSphere Kubernetes Service (VKS).
В документе представлена практическая референсная архитектура, основанная на трёх ключевых компонентах наблюдаемости:
Метрики
Для сбора метрик архитектура использует стек Prometheus Community (kube-prometheus-stack), который включает:
Prometheus Operator для динамического обнаружения целей
Grafana для построения дашбордов
Node Exporter для сбора статистики на уровне узлов
Метрики дополнительно обогащаются телеметрией сервисов Istio и интегрируются с решением VCF Operations для предоставления контекста базовой инфраструктуры.
Логи
Для работы с логами используется Fluent Bit, который собирает и обогащает данные логов Kubernetes. Для хранения и индексации применяется Grafana Loki, обеспечивая нативный для Kubernetes анализ логов через Grafana.
Тот же поток логов также передаётся в VCF Operations for Logs, что позволяет коррелировать события с более широкой инфраструктурной средой.
Трейсы
Для трассировки используется OpenTelemetry для распределённого трейсинга, Jaeger v2 — для приёма и визуализации данных трассировки в формате OTLP, а OpenSearch — в качестве постоянного хранилища трейсов.
Это позволяет отслеживать прохождение запросов через различные сервисы и анализировать их вместе с сопутствующей телеметрией приложений и платформы.
Для команд, использующих vSphere Kubernetes Service на платформе VMware Cloud Foundation, этот документ представляет собой практическую отправную точку для построения модульного, ориентированного на промышленную эксплуатацию стека наблюдаемости. Также репозиторий, на который ссылается документ, размещен по этой ссылке.
«Группа Астра» объявила о коммерческом релизе продукта Astra Migration — инструмента для автоматизированного и управляемого переноса рабочих станций с Windows на российскую платформу Astra Linux. Решение уже доступно для заказа и нацелено на решение одной из ключевых задач отечественного ИТ-рынка — массового и контролируемого перевода организаций на отечественное программное обеспечение. Компания занимает 76% российского рынка ОС для ПК и серверов и выпускает инструмент, который призван сделать переход на её платформу максимально быстрым и безболезненным.
Зачем нужен Astra Migration
На практике миграция с Windows сопряжена с серьёзными операционными трудностями: ручные сценарии плохо масштабируются, требуют значительного участия ИТ-специалистов и не дают прозрачной картины процесса. Без централизованного инструмента контролировать сроки, статусы и качество перехода крайне сложно. Именно эти барьеры призван устранить новый продукт «Группы Астра».
Актуальность задачи подтверждается рыночными прогнозами. По оценкам аналитиков Strategy Partners, объём российского рынка операционных систем для ПК и серверов к 2030 году вырастет до 55 млрд рублей при среднегодовых темпах роста в 23%. В государственном секторе уровень проникновения отечественных ОС к тому же сроку приблизится к 100%, тогда как корпоративный сегмент сохранит значительный потенциал для дальнейшего роста.
Клиент-серверная архитектура
Astra Migration построен по клиент-серверной модели с чётким разделением функций между двумя компонентами.
Astra Migration App — клиентский модуль, устанавливаемый централизованно на исходные рабочие станции под управлением Windows. Он автоматически выполняет инвентаризацию конфигурации АРМ: полный сбор сведений об аппаратном обеспечении и установленном ПО занимает не более 30 секунд. На всех этапах перехода приложение информирует пользователя о ходе миграции через интерактивные уведомления, прогресс-бар и подсказки — всё это обеспечивает вовлечённость сотрудника при минимальных требованиях к его участию.
Astra Migration Server — серверная часть, предоставляющая IT-администратору единую панель управления. Через неё выполняется полная настройка сценариев и волн миграции, мониторинг состояния устройств в реальном времени и контроль блокеров, препятствующих переходу.
Что настраивает администратор
Работа с продуктом со стороны IT-специалиста включает несколько уровней конфигурации. На уровне сценария задаются параметры целевой ОС, сетевые настройки и параметры установки Astra Linux. На уровне волн миграции — их состав (группы АРМов), статусы и перечень блокеров, при наличии которых переход конкретной станции откладывается. Предусмотрен запуск проверки совместимости программного обеспечения и оборудования до фактического начала переноса, а также формирование отчётов о динамике перехода пользователей на новую ОС.
Что происходит на рабочем месте пользователя
Процесс перехода со стороны конечного пользователя организован следующим образом:
На рабочий стол поступает уведомление о включении АРМ в волну миграции.
Пользователь самостоятельно выбирает удобную ему дату из перечня, предоставленного администратором.
Накануне миграции пользователь получает уведомление о запланированной процедуре, её этапах, а также рекомендации по подготовке и приветственный баннер с инструкциями по работе в Astra Linux.
В выбранную дату миграция запускается и завершается в автоматическом режиме без дальнейшего участия сотрудника.
Такой подход обеспечивает плавную адаптацию персонала: сотрудники заблаговременно осведомлены о предстоящих изменениях и чувствуют себя участниками процесса, а не его объектами.
Что переносится и что сохраняется
В ходе миграции Astra Migration обеспечивает перенос пользовательских данных и персональных настроек операционной системы. Отдельно выполняется проверка совместимости установленного ПО и подключённого оборудования с новой ОС. При возникновении проблем предусмотрен откат: образ исходной ОС сохраняется, что позволяет вернуться к Windows при необходимости.
Текущие возможности и планы
В выпущенной версии реализован режим Dualboot — Windows и Astra Linux устанавливаются параллельно на одном устройстве с переносом данных в рамках поддерживаемого сценария. Режим полной замены ОС с переносом данных (clean install) запланирован к добавлению в следующих обновлениях продукта.
По заявлению разработчиков, Astra Migration ускоряет процесс перевода рабочих мест в десятки раз по сравнению с ручным подходом, обеспечивая параллельную обработку более 100 АРМов одновременно. Все этапы — от инвентаризации исходной системы до финального перехода — полностью прозрачны для IT-администратора.
Для кого предназначено решение
Продукт ориентирован на широкий круг заказчиков: государственные структуры, крупный бизнес, а также средние и малые предприятия, которые решают задачу импортозамещения Windows и стремятся провести переход без потери эффективности работы сотрудников.
Зрелость платформы определяется не только качеством ядра, но и тем, насколько легко на неё перейти. Тысячи компаний переходят на Astra Linux прямо сейчас, и качество этого процесса формирует их отношение к нашему продукту на годы вперёд. Именно поэтому мы создали Astra Migration — инструмент, который позволяет перевести тысячи рабочих мест на Astra Linux без остановки бизнеса и перегрузки ИТ-службы, превращая миграцию из необходимости в управляемый и предсказуемый процесс. — Михаил Геллерман, директор управления операционных систем «Группы Астра»
Первая публичная демонстрация Astra Migration состоялась 20 апреля 2026 года на стенде «Группы Астра» в рамках конференции АКПО-Конф. 23 апреля 2026 года компания проводит онлайн-вебинар «Astra Migration: автоматизированная миграция с Windows без боли», на котором будет показана практическая работа продукта и разобраны сценарии внедрения.
Развёртывание Kubernetes в производственной среде требует не просто установки кластера — необходимо с самого начала принять правильные архитектурные решения, от которых будут зависеть масштабируемость, доступность и управляемость платформы. Вебинар специалистов Broadcom Professional Services и MomentumAI посвящён ключевым принципам проектирования VMware vSphere Kubernetes Service (VKS) поверх VMware Cloud Foundation (VCF). Докладчики — Vijay Appani, Solution Architect компании Broadcom, и Caleb Washburn, CTO и основатель MomentumAI — рассматривают проверенные шаблоны проектирования, которые их команды применяют в реальных enterprise-проектах.
Что такое VKS и зачем запускать Kubernetes на VCF
VMware vSphere Kubernetes Service (VKS) — это встроенный механизм запуска Kubernetes на платформе vSphere, интегрированный непосредственно в VMware Cloud Foundation. В отличие от сторонних дистрибутивов, VKS использует подтверждённую CNCF версию Kubernetes и глубоко интегрирован с инфраструктурными компонентами VCF: вычислительным слоем (vSphere), сетью (NSX) и хранилищем (vSAN). Это позволяет организациям строить современную private cloud-платформу, избегая «лоскутных» решений и накапливаемого технического долга.
Ключевая идея заключается в том, что VCF предоставляет единую платформу, объединяющую ресурсы compute, network и storage в согласованный операционный слой. Kubernetes в таком окружении получает доступ к корпоративным политикам хранения, сетевой изоляции на уровне неймспейсов и интеграции с порталом самообслуживания VCF Automation — всё это без необходимости разворачивать и поддерживать внешние инструменты.
Три модели развёртывания Supervisor-кластера
Центральным компонентом VKS является Supervisor-кластер — уровень управления Kubernetes, развёртываемый поверх рабочего домена VCF. Существует три основные топологии его размещения, и выбор между ними определяет поведение платформы при сбоях, требования к ресурсам и сложность эксплуатации.
Модель 1: Single Cluster. Supervisor-кластер и рабочие нагрузки размещаются в одном vSphere-кластере. Это наиболее простой с точки зрения конфигурации вариант. Он подходит для начального знакомства с платформой или сред разработчиков, однако не обеспечивает разделения плоскости управления и плоскости данных. При сбое кластера теряется и управление, и рабочие нагрузки.
Модель 2: Multi-Cluster с разделёнными зонами. Supervisor-контрольная плоскость развёртывается в отдельном управляющем домене, а рабочие нагрузки — в выделенных рабочих доменах. Такое разделение обеспечивает независимость управляющего слоя от прикладного, что принципиально важно для инфраструктуры среднего масштаба. Недостатком является необходимость большего числа хостов и более сложная настройка сети и зон.
Модель 3: vSphere Zones (рекомендуется для enterprise). Виртуальные машины управляющей плоскости Supervisor-кластера распределяются по трём vSphere Zones — логическим группам, каждая из которых соответствует отдельному физическому кластеру. Рабочие нагрузки могут совместно использовать те же три зоны или размещаться в выделенных. Платформа выдерживает полный отказ одной зоны без потери доступности — ни управляющий слой, ни приложения не затрагиваются. Данная модель рекомендуется для крупных enterprise-развёртываний, требующих гарантий высокой доступности на уровне инфраструктуры.
Сетевые опции: NSX или VDS
При настройке сети для VKS на VCF доступны два варианта: NSX и vSphere Distributed Switch (VDS). Выбор между ними оказывает существенное влияние на функциональность платформы и возможности автоматизации.
NSX является рекомендованным выбором для любого нового (greenfield) развёртывания VCF. Overlay-сеть на основе Geneve/VXLAN обеспечивает полную изоляцию на уровне неймспейсов, встроенный распределённый файрвол, встроенный балансировщик нагрузки уровней L4 и L7 (NSX Advanced Load Balancer / AVI), а также глубокую интеграцию с VCF Automation. Именно NSX позволяет реализовать портал самообслуживания, где разработчики и команды самостоятельно запрашивают ресурсы, не взаимодействуя напрямую с vSphere-администраторами.
VDS применяется в случаях, когда NSX не может быть развёрнут — например, при модернизации существующей инфраструктуры или при строгих ограничениях лицензирования. VDS поддерживает базовые возможности VKS, однако не поддерживает VCF Automation, overlay-сети и встроенный балансировщик нагрузки. При использовании VDS в производственной среде потребуется внешний балансировщик, что добавляет операционную сложность.
Отдельно подчёркивается, что если требования к приложению предполагают L4 или L7 балансировку, использование выделенного балансировщика нагрузки является обязательным — независимо от выбранного сетевого варианта.
Хранилище: vSAN, политики и управление томами
Хранилище в архитектуре VKS разделяется на два типа: эфемерное (ephemeral) и постоянное (persistent). Эфемерное хранилище используется для дисков самих узлов Kubernetes (Control Plane VMs и Worker Nodes) и временных томов Pod'ов. Оно берётся из основного или дополнительного хранилища рабочего домена и настраивается при активации Supervisor-кластера.
Постоянные тома (Persistent Volumes, PV) предназначены для stateful-приложений — баз данных, очередей сообщений, систем хранения состояния. Доступ к постоянному хранилищу управляется через Storage Policies — политики хранения vSAN, которые администратор создаёт в vCenter. Политики описывают параметры производительности, доступности (RAID-1, RAID-5/6) и шифрования. Каждый арендатор (tenant) в мультитенантной конфигурации получает доступ только к тем политикам хранения, которые ему явно назначены.
Если арендатору не назначена ни одна storage policy, он не сможет создавать Persistent Volume Claims (PVC) — это удобный механизм ограничения: организации могут предоставлять namespace без прав на stateful-хранение там, где это нежелательно. Поддерживаются режимы доступа RWO (ReadWriteOnce) и RWX (ReadWriteMany) — последний обычно требует дополнительных компонентов типа vSAN File Services или внешних NFS-решений.
Мультитенантность и интеграция с VCF Automation
Одним из ключевых преимуществ VKS на VCF является встроенная поддержка мультитенантности через механизм namespace и интеграцию с VCF Automation. Каждый неймспейс представляет собой изолированную рабочую область, которой могут быть назначены: квоты на CPU и RAM, доступные storage policies, сетевые профили NSX, а также права доступа пользователей или групп из Active Directory / LDAP.
VCF Automation предоставляет портал самообслуживания, через который подразделения и команды разработчиков могут самостоятельно запрашивать Kubernetes namespace, инициировать развёртывание приложений и управлять ресурсами — без участия администратора vSphere. Платформа автоматически создаёт необходимые ресурсы: сетевые сегменты NSX, политики хранения, RBAC-права. Это, по словам авторов вебинара, является «новейшим и наиболее зрелым способом организации современного private cloud».
Рекомендуется начинать с NSX в качестве сетевого стека при любом новом greenfield-развёртывании VCF именно потому, что VCF Automation поддерживает только NSX, и без него модель самообслуживания недоступна.
Рекомендации по проектированию production-платформы
По итогам вебинара сформулированы следующие практические рекомендации для команд, проектирующих VKS на VCF в производственной среде:
Используйте топологию vSphere Zones для любого развёртывания с требованиями к высокой доступности — она обеспечивает автоматический failover при отказе целого кластера без вмешательства администратора.
Выбирайте NSX как сетевой стек при greenfield-развёртывании — только с NSX доступна полная интеграция с VCF Automation и портал самообслуживания.
Планируйте storage policies заранее: определите требования к производительности и отказоустойчивости для разных классов рабочих нагрузок ещё до запуска первых неймспейсов.
Разграничивайте доступ к хранилищу на уровне арендаторов — не назначайте storage policies тем неймспейсам, которым stateful-хранение не нужно.
Если среда требует L4/L7 балансировки, включайте NSX Advanced Load Balancer (AVI) в архитектуру с самого начала — добавить его позднее значительно сложнее.
Не смешивайте управляющую и рабочую плоскости в одном кластере для производственной среды: выделяйте отдельный рабочий домен для приложений, даже если это требует дополнительных хостов.
Вопросы и ответы: ключевые моменты
В ходе сессии вопросов и ответов слушателей интересовали несколько практических аспектов. На вопрос о поддержке собственных сервисов поверх VKS ответ был однозначным: технически это возможно, однако рекомендуется использовать интегрированный стек — vSAN, NSX и VCF Automation — поскольку именно на нём строится поддержка и будущее развитие платформы.
На вопрос об источниках эфемерного хранилища пояснялось, что при активации Supervisor-кластера администратор указывает datastore, из которого берётся эфемерное хранилище для узлов Kubernetes и временных томов Pod'ов. Это может быть как vSAN, так и дополнительное (supplemental) хранилище рабочего домена.
Относительно нестандартных конфигураций — в частности, развёртывания VKS поверх существующей vSphere-среды без полного стека VCF — авторы отметили, что такие варианты существуют, но лишены ключевых преимуществ интегрированной платформы: автоматизации, самообслуживания и единого управления жизненным циклом.
Итог
VMware vSphere Kubernetes Service на VMware Cloud Foundation представляет собой зрелую enterprise-платформу для запуска production-Kubernetes с полной интеграцией в корпоративную инфраструктуру. Правильный выбор топологии Supervisor-кластера, сетевого стека и модели хранения на этапе проектирования определяет, насколько легко платформа будет масштабироваться и насколько просто её будет эксплуатировать в долгосрочной перспективе. Ознакомиться с предстоящими вебинарами серии VCF можно по ссылке go-vmware.broadcom.com/VCFWebinars.
Современный разработчик привык к беспрепятственному доступу к инфраструктуре. В публичном облаке достаточно нажать кнопку или вызвать API — и через несколько минут кластер Kubernetes, виртуальная машина или база данных готовы к работе. Но что происходит, когда требования к суверенитету данных, соответствию нормативным требованиям или прогнозируемости затрат обязывают развёртывать нагрузки на собственной инфраструктуре?
Исторически онпрем-инфраструктура означала создание заявок в IT-систему и ожидание ресурсов в течение дней или даже недель. Такие задержки превращались в серьёзное препятствие для вывода продуктов на рынок. Разработчики, уставшие от очередей, нередко поднимали собственные «теневые» базы данных на неуправляемых виртуальных машинах — только чтобы двигаться быстрее. Результатом становились бесконтрольное разрастание баз данных, дрейф конфигураций, отсутствие управления и серьёзные угрозы безопасности.
Платформенная инженерия на базе VMware Cloud Foundation (VCF) изменила эту картину. Используя платформу частного облака VCF, организации могут устранить разрыв между IT-операциями и командами разработчиков. VCF обеспечивает настоящее «от платформы до данных» самообслуживание, сравнимое с возможностями публичного облака: разработчики получают нужную им скорость, а платформенные инженеры — централизованное управление всем парком ресурсов.
Соответствие публичному облаку: эквиваленты на on-prem VCF
Чтобы оценить возможности VCF как платформы частного облака, полезно сопоставить её функциональность с сервисами публичного облака, которые разработчики уже хорошо знают. Для тех, кто работал с AWS, on-prem-эквиваленты в VCF выглядят следующим образом:
Amazon EC2 > VCF VM Service: позволяет разработчикам декларативно развёртывать традиционные виртуальные машины и управлять ими совместно с контейнерами.
Amazon EKS > VCF VKS (vSphere Kubernetes Service): предоставляет конформные Kubernetes-кластеры с самообслуживанием, нативно встроенные в VCF.
Amazon RDS > VCF DSM (Data Services Manager): реализует инструмент управления парком баз данных в режиме Database-as-a-Service (DBaaS) по запросу.
Совместное использование этих трёх компонентов позволяет платформенным командам предлагать разработчикам комплексный каталог сервисов, управляемый через API, непосредственно из собственного датацентра.
Рабочий процесс платформенного инженера: установка границ
Архитектурный принцип этого решения — управление через персоны. Системный администратор или платформенный инженер определяет «правила игры» и сохраняет контроль, а разработчик потребляет ресурсы строго в заданных рамках. Рабочий процесс устроен следующим образом.
1. Создание границ. Администратор инфраструктуры создаёт vSphere namespace в VCF. Этот namespace выступает границей tenancy: к конкретному проекту или команде разработчиков привязываются лимиты вычислительных ресурсов, памяти и хранилища.
2. Определение инфраструктуры и политик. В рамках namespace платформенный инженер задаёт правила взаимодействия:
Вычислительные ресурсы: размеры кластеров, пулы ресурсов и классы ВМ (размеры: small, medium, large) — чтобы разработчики не превышали допустимое потребление.
Хранилище и сеть: конкретные политики хранения (vSAN или NFS) и привязка нагрузок к нужным VLAN и VPC-подсетям.
Сервисы данных в DSM: разрешённые движки баз данных и их версии, предварительно проверенные командой DBA.
Опыт разработчика: развёртывание в режиме самообслуживания
После того как администратор задал политики, платформенный инженер открывает доступ команде разработки через защищённый API-токен. С этого момента разработчики полностью самостоятельны — никакого ожидания в очереди задач и утверждений. Используя стандартный инструментарий Kubernetes (kubectl), портал или API DSM либо собственные Terraform-пайплайны, они могут:
поднять новый Kubernetes-кластер (VKS) для тестирования микросервисов;
выбрать движок базы данных — PostgreSQL, MySQL или Microsoft SQL Server (появится в версии 9.1).
При этом все самостоятельно подготовленные ресурсы автоматически соответствуют корпоративным политикам резервного копирования, сети и безопасности, установленным администратором.
Автоматизация и интеграция с Infrastructure-as-Code
Всю описанную среду можно полностью автоматизировать с помощью подхода Infrastructure as Code. Платформенная команда может управлять пространствами имен и конфигурациями сервисов через различные инструменты в зависимости от предпочтений: Kubernetes CRD, Terraform-манифест или корпоративный блупринт, охватывающий целый комплекс ресурсов — VKS-кластер с набором виртуальных машин, сервисы данных DSM и даже ArgoCD для доставки приложений в VKS-кластеры — всё в рамках единого набора API-вызовов.
Ниже — пример CRD для декларативного развёртывания базы данных в namespace, демонстрирующий простоту этого подхода. CRD можно использовать как часть GitOps-процесса:
День второй: операционное управление после запуска
Одно из наиболее значимых преимуществ платформенного подхода, особенно с Data Services Manager, состоит в том, что он не заканчивается на первоначальном «нажатии кнопки». Платформа автоматизирует критически важные операции второго дня жизненного цикла — когда приложению предстоит выйти в продуктив. Задачи, которые традиционно поглощали ресурсы DBA, теперь решаются простым изменением декларативного параметра в CRD:
Высокая доступность: автоматическое развёртывание кластеров для немедленной отказоустойчивости.
Масштабируемость: возможность легко добавлять read-реплики по мере роста нагрузки на приложение.
Защита данных: автоматическое резервное копирование и восстановление до точки во времени (PITR) — «из коробки».
Управление: централизованная видимость для платформенной команды с контролем использования и устранением разрастания баз данных по всем рабочим доменам.
Поддержка OSS-баз данных корпоративного уровня: DSM предоставляет возможности и поддержку коммерческого класса, недоступные в бесплатных open-source версиях PostgreSQL или MySQL.
Заключение
Создание каталога самообслуживания — от платформы до данных — не требует переноса всего в публичное облако. Используя VCF, VKS и DSM, организации получают гибкость публичного облака в сочетании с безопасностью и контролем собственной частной инфраструктуры. Платформенные инженеры при этом трансформируются из ИТ-привратников в enabler'ов — обеспечивая разработчиков API-эндпоинтами, Kubernetes-кластерами и управляемыми базами данных, необходимыми для более быстрой и безопасной разработки ПО, готового к производственному окружению.
Технология Advanced Memory Tiering в VMware Cloud Foundation 9 позволяет существенно расширить эффективный объём памяти хоста за счёт NVMe-накопителей — без изменения рабочих процессов и без влияния на привычные инструменты управления. Ниже собраны практические рекомендации, которые помогут правильно оценить среду, корректно настроить платформу и избежать типичных ошибок при развёртывании.
Как работает двухуровневая память
Архитектура Advanced Memory Tiering строится на двух уровнях.
Tier 0 — это DRAM: быстрая оперативная память, которая обслуживает активные страницы виртуальных машин.
Tier 1 — NVMe-накопитель, куда перемещаются холодные, редко используемые страницы. При этом память гипервизора (vmkernel) никогда не попадает в NVMe: ESX всегда работает исключительно в DRAM.
Когда виртуальная машина обращается к странице, находящейся в Tier 1, гипервизор возвращает её в DRAM — прозрачно и без участия гостевой ОС. Такая схема идеально подходит для рабочих нагрузок с выраженным разделением горячих и холодных страниц памяти.
Оценка готовности среды
Прежде чем включать Memory Tiering, необходимо проанализировать текущее потребление памяти. Ключевой показатель — активная память (active memory): объём страниц, к которым виртуальные машины реально обращаются в единицу времени. Технология оптимально работает, когда потреблённая (allocated) память превышает 50% от установленного объёма DRAM, а активная остаётся ниже этого порога.
Проверить активную память можно несколькими способами. В интерфейсе vCenter откройте VM > Monitor > Performance > Advanced, переключитесь в режим отображения памяти и выберите режим реального времени — показатель active memory доступен только в нём, поскольку относится к статистике уровня 1.
Для более широкого охвата подойдёт VCF Operations — если он уже развёрнут в инфраструктуре, он обеспечит сквозную видимость по всем хостам и кластерам. Ещё один вариант — RVTools: утилита собирает статистику памяти в реальном времени и позволяет быстро оценить картину по всей среде.
Порог активной памяти: правило 50%
Главное эксплуатационное правило Memory Tiering звучит просто: активная память должна оставаться на уровне 50% или ниже от объёма DRAM. Это гарантирует, что горячий рабочий набор данных комфортно размещается в быстрой памяти и при этом остаётся достаточный запас.
Если активная память стабильно превышает 70% от объёма DRAM, часть горячих страниц неизбежно окажется в Tier 1, и производительность виртуальных машин может заметно снизиться. В такой ситуации следует либо добавить DRAM на хост, либо перераспределить нагрузку между узлами кластера, прежде чем включать тиринг.
Настройка соотношения DRAM:NVMe
При включении Memory Tiering ESXi устанавливает соотношение DRAM к NVMe равным 1:1 по умолчанию. Это означает, что при наличии 512 ГБ DRAM хост получит дополнительные 512 ГБ ёмкости Tier 1. Параметр контролируется через расширенную настройку хоста: Mem.TierNVMePct со значением по умолчанию 100 (100% от объёма DRAM).
Рекомендуется сохранять соотношение 1:1 для большинства рабочих нагрузок — оно охватывает типичные сценарии использования. Изменять его стоит только после тщательного анализа профиля активной памяти конкретных ВМ. При выборе размера NVMe-накопителей разумно ориентироваться с запасом: более ёмкие устройства замедляют износ ячеек, дают пространство для будущего изменения соотношения и позволяют безболезненно справляться с неожиданным ростом нагрузки.
Подходящие рабочие нагрузки
Memory Tiering наиболее эффективна для рабочих нагрузок с естественным разделением горячих и холодных страниц. В их числе:
Общая серверная виртуализация — разнородный парк ВМ с умеренной и переменной активностью памяти.
VDI-среды — виртуальные рабочие столы с большим количеством ВМ, каждая из которых использует лишь часть выделенной памяти одновременно.
Среды разработки и тестирования — временные ВМ, которые редко используют всю выделенную память одновременно.
Веб-серверы и серверы приложений — нагрузки с предсказуемым рабочим набором в памяти.
Базы данных с умеренной активностью — СУБД, у которых значительная часть данных в памяти остаётся холодной
Неподходящие рабочие нагрузки
Ряд профилей виртуальных машин в настоящее время не поддерживает работу с Memory Tiering. Для таких ВМ тиринг следует отключить на уровне виртуальной машины — это принудительно размещает все её страницы в Tier 0 (DRAM).
Высокопроизводительные и latency-sensitive ВМ — приложения, требующие предсказуемых ультранизких задержек доступа к памяти
ВМ с аппаратной защитой памяти — виртуальные машины, использующие технологии шифрования AMD SEV, Intel SGX или Intel TDX
ВМ с Fault Tolerance (FT) — непрерывная синхронизация состояния несовместима с тирингом
«Монстроидальные» ВМ — машины с объёмом памяти от 1 ТБ и более 128 vCPU
ВМ с большими страницами памяти (large memory pages)
Вложенная виртуализация (nested VMs)
Если в кластере присутствуют такие нагрузки, оптимальная стратегия — выделить для них отдельные хосты и включить Memory Tiering только на оставшихся узлах кластера, либо управлять исключениями на уровне отдельных ВМ.
Интеграция с vSphere
Advanced Memory Tiering полностью интегрирована в стандартные механизмы управления vSphere — никаких специальных процедур не требуется:
vMotion — миграция ВМ между хостами работает прозрачно; оба уровня памяти учитываются при переносе.
DRS — балансировщик нагрузки осведомлён об обоих уровнях и учитывает их при принятии решений о размещении ВМ.
High Availability (HA) — при отказе хоста ВМ перезапускаются на оставшихся узлах по стандартным правилам HA.
Рекомендации по развёртыванию
Для успешного внедрения рекомендуется придерживаться следующих принципов. Во-первых, поддерживайте единую конфигурацию хостов в кластере с помощью vSphere Configuration Profiles — это исключает расхождения между узлами и упрощает масштабирование. Во-вторых, применяйте поэтапный подход: включайте тиринг последовательно, начиная с одного-двух хостов, оценивайте результаты и только потом распространяйте изменение на весь кластер. В-третьих, фиксируйте исключения: документируйте все ВМ, для которых Memory Tiering отключена на уровне виртуальной машины, чтобы не потерять контроль над конфигурацией при росте инфраструктуры.
Мониторинг после включения
После включения Memory Tiering следует регулярно отслеживать ключевые показатели:
Процент активной памяти на уровне хостов и кластера
Паттерны доступа к страницам (горячие/холодные)
Тренды утилизации памяти по кластеру в целом
Потребление памяти на уровне отдельных ВМ
Задержки чтения и записи NVMe-накопителей Tier 1
Рост задержек NVMe или увеличение активной памяти выше порога 50% DRAM — сигнал для пересмотра распределения нагрузки или конфигурации тиринга. Регулярный мониторинг позволяет выявлять изменения в профиле нагрузки на ранней стадии и реагировать проактивно.
С момента запуска VMware Cloud on AWS компании VMware и AWS совместно расширяли портфель специализированных инстансов на базе bare-metal — от оригинальных i3.metal и i3en.metal до высокоплотного i4i.metal. Теперь для VMware Cloud on AWS объявлен запуск нового типа инстансов — i7i.metal-24xl. Оснащённый процессорами 5 поколения Intel Xeon Scalable (Emerald Rapids), SSD третьего поколения AWS Nitro и высокоскоростной памятью DDR5, новый инстанс обеспечивает значимый скачок в пропускной способности хранилища и вычислительной эффективности — при этом существующая операционная модель VMware не требует каких-либо изменений.
По мере того как всё больше заказчиков переносят в облако наиболее требовательные рабочие нагрузки, новый инстанс i7i обеспечивает наилучшую вычислительную производительность и производительность хранилища среди x86-инстансов Amazon EC2, оптимизированных для хранения данных. Пользователи VMware Cloud on AWS получают заметно более высокую пропускную способность ввода-вывода, меньшую задержку и улучшенное соотношение цены и производительности по сравнению с предыдущим поколением.
Ключевые характеристики
Инстанс i7i.metal-24xl представляет собой универсальный bare-metal-инстанс, разработанный для I/O-интенсивных корпоративных рабочих нагрузок, которым требуется максимально возможная производительность случайного ввода-вывода с предсказуемой субмиллисекундной задержкой.
Характеристика
i7i.metal-24xl
Процессор
5th Gen Intel Xeon (Emerald Rapids)
vCPU
96
Физические ядра
48
Память
768 ГиБ DDR5 (5600 MT/s)
Локальное NVMe-хранилище
6 x 3,75 ТБ NVMe SSD
Используемая ёмкость*
vSAN OSA ~ 13 ТБ / vSAN ESA ~ 20 ТБ
Пропускная способность сети
56,25 Гбит/с
Источник: Amazon EC2 I7i Instances — aws.amazon.com. Используемая ёмкость является оценочной. Для конфигураций с оптимизацией vSAN на кластере из 3 узлов фактическая ёмкость будет варьироваться в зависимости от профиля нагрузки, политики FTT/RAID и применяемых параметров сжатия и дедупликации vSAN.
Региональная доступность
Тип инстансов i7i.metal-24xl доступен для приобретения в следующих регионах AWS:
География
Регионы AWS
Америка
US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Central)
Европа
Europe (Ireland), Europe (London), Europe (Frankfurt), Europe (Stockholm), Europe (Milan)
Ближний Восток
Middle East (Bahrain)
Азиатско-Тихоокеанский регион
Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Melbourne), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Osaka), Asia Pacific (Mumbai), Asia Pacific (Hyderabad)
VMware vSAN работает непосредственно поверх локальных NVMe-дисков каждого хоста i7i.metal-24xl. При включённом сжатии vSAN кластер из 3 узлов обеспечивает значительную используемую ёмкость — конкретный результат зависит от характеристик нагрузки, политики FTT/RAID и показателей снижения объёма данных. Размер конфигурации рекомендуется валидировать применительно к конкретному профилю данных.
На i7i.metal-24xl по умолчанию включён гиперпоточный режим, что обеспечивает 96 логических ядер на хост — это хорошо подходит для приложений, выигрывающих от увеличенного параллелизма потоков CPU. Для заказчиков, которым важны показатели производительности приложений или условия программного лицензирования, VMware Cloud on AWS поддерживает опцию Custom CPU Core Count, позволяющую управлять количеством физических ядер, доступных на каждом хосте.
Для вторичных кластеров i7i.metal поддерживаются следующие конфигурации:
Кластеры от 3 узлов: 8, 16, 24, 30 или 36 физических ядер на хост
Кластеры из 2 узлов: 16, 24, 30 или 36 физических ядер на хост
Такая гибкость особенно ценна для ПО с лицензированием по числу ядер — например, Oracle Database и Microsoft SQL Server: сокращение числа активных ядер может существенно снизить лицензионные расходы без потери объёма памяти и хранилища хоста.
Кроме того, доступно развёртывание Stretched Cluster с охватом нескольких зон доступности для новых SDDC на базе i7i.metal-24xl — это обеспечивает высокую доступность рабочих нагрузок сразу в двух зонах доступности AWS в пределах одного региона. По умолчанию в Stretched Cluster SDDC используется vSAN OSA.
Приобретение подписок i7i.metal-24xl
За информацией о ценах, доступных регионах и вариантах приобретения следует обращаться к представителю Broadcom. Если контактные данные представителя неизвестны, можно воспользоваться формой на сайте продаж Broadcom.
Важно учитывать, что тип инстансов i7i требует предварительного обновления существующих развёртываний до версии SDDC 1.26v2 — для конвертации кластеров и развёртывания новых вторичных кластеров. Для запроса досрочного обновления необходимо открыть запрос в поддержку с указанием организации, данных SDDC и желаемой даты обновления — команда VMC поддержки скоординирует дальнейшие шаги.
Развёртывание и миграция на i7i.metal-24xl
Существует два сценария: развертывание нового SDDC с инстансами i7i.metal-24xl или миграция рабочих нагрузок с имеющихся узлов i3.metal, i3en.metal и/или i4i.metal на новый i7i.metal-24xl. Тип инстансов i7i доступен только для SDDC версии 1.26v2.
Создание нового SDDC
Все вновь развёртываемые SDDC будут работать на актуальной версии SDDC 1.26v2 и по умолчанию использовать vSAN ESA. Подробные инструкции доступны в разделе «Развёртывание SDDC из VMware Cloud Console».
Выберите Create SDDC и укажите тип хоста i7i.metal-24xl.
Задайте размер кластера (минимум 2 хоста) и выполните оставшиеся шаги.
Завершите развёртывание SDDC. VMware автоматически выполняет настройку ESXi, vSAN, vCenter и NSX.
Добавление вторичного кластера в существующий SDDC
К существующему SDDC (после обновления до версии 1.26v2) можно добавить новый кластер на базе i7i.metal-24xl без прерывания выполняющихся нагрузок. После подготовки кластера vSphere vMotion позволяет перенести виртуальные машины из имеющихся кластеров в новый i7i с минимальным воздействием. Новый кластер будет работать под управлением SDDC 1.26v2 и по умолчанию использовать vSAN ESA. Подробные инструкции — в разделе «Добавление кластера».
Конвертация кластеров с хостами i3 / i3en / i4i
Миграция с i3.metal, i4i.metal или i3en.metal на i7i.metal-24xl возможна с помощью vSphere vMotion. Для подходящих конфигураций VMware также предоставляет услугу конвертации кластера по запросу. Подробные инструкции — в разделе «Конвертация типов хостов в кластерах».
Следует учитывать, что кластеры, использующие аппаратную версию виртуальных машин 21, не подходят для конвертации с i4i на i7i из-за ограничений совместимости оборудования. Для получения помощи с расчётом размеров и планированием конвертации кластеров следует обращаться к команде Broadcom. Также доступен инструмент VMC Sizer — для оценок на основе хостов, нагрузок или конвертации кластеров.
Начало работы
Для обсуждения того, как i7i.metal-24xl может модернизировать среду VMware Cloud on AWS, рекомендуется связаться с представителем Broadcom. На vmc.broadcom.com доступны настройка нового SDDC, изучение вариантов расчёта размеров и запрос оценки рабочих нагрузок.
RSS
