VMware vCenter Converter – это классический инструмент VMware для перевода физических и виртуальных систем в формат виртуальных машин VMware. Его корни уходят к утилите VMware P2V Assistant, которая существовала в 2000-х годах для «Physical-to-Virtual» миграций. В 2007 году VMware выпустила первую версию Converter (3.0), заменив P2V Assistant...
VMware недавно опубликовала обновлённый набор технических руководств, которые приводят рекомендации в соответствие с архитектурой эпохи VMware Cloud Foundation
и с новыми возможностями приложений Microsoft, включая SQL Server 2025 и Windows Server 2025.
Если вы планируете развёртывание VCF, модернизируете существующие среды, стандартизируете платформу, обновляете парк SQL Server или модернизируете инфраструктуру идентификации, мы рекомендуем ознакомиться с этими документами до того, как будет окончательно утверждён ваш следующий дизайн-воркшоп, цикл закупок или план миграции.
Руководство 1: Проектирование Microsoft SQL Server на VMware Cloud Foundation
Для многих команд решение о виртуализации SQL Server уже принято. Как говорится в руководстве: «вопрос больше не в том, виртуализировать ли SQL Server, а в том, как…». И это «как» существенно изменилось в мире VCF. Платформа стала более регламентированной, операционная модель — более стандартизированной, а поддерживающие возможности (хранилище, сеть, управление жизненным циклом, безопасность) эволюционировали с учётом развития аппаратных возможностей и операционных методик.
Обновлённое руководство предназначено для читателей, которые уже понимают как VCF, так и SQL Server. Оно ориентировано на несколько ролей: архитекторов, инженеров/администраторов и DBA.
Несколько моментов, на которые стоит обратить внимание:
Современные рекомендации по CPU и NUMA теперь учитывают и новое поведение топологии в эпоху VCF. Руководство рассматривает «новые параметры конфигурации топологии vNUMA в VMware Cloud Foundation (VCF)» и объясняет, почему это поведение важно для крупных виртуальных машин SQL Server.
Чёткая и обновлённая позиция по CPU hot plug в эпоху SQL Server 2025. В руководстве прямо указано: CPU Hot-Add больше не поддерживается в SQL Server 2025, и его не следует включать на таких виртуальных машинах.
Рекомендации по хранилищу, соответствующие направлению развития VCF. Если вы оцениваете архитектурные варианты vSAN, руководство объясняет, почему vSAN Express Storage Architecture (ESA) привлекателен для заказчиков, переходящих на более современное оборудование, и подчёркивает возможности эффективности ESA, такие как глобальная дедупликация и преимущества сжатия для нагрузок баз данных.
Пояснения по устаревающим функциям, влияющим на долгоживущие архитектуры. Если в вашей текущей архитектуре активно используются vVols, учтите, что Virtual Volumes объявлены устаревшими, начиная с VCF 9.0 и VMware vSphere Foundation 9.0 (полный отказ запланирован в будущих релизах).
Операционная реалистичность для мобильности и обслуживания. Руководство рассматривает использование multi-NIC vMotion для снижения риска зависания (stun) при миграции крупных, потребляющих много памяти виртуальных машин SQL, а также отмечает, что VCF внедряет vMotion Notifications, чтобы помочь чувствительным к задержкам и кластер-осведомлённым приложениям безопаснее обрабатывать миграции.
Если вы принимаете решения - это тот документ, который снижает объём переработок, вызванных неожиданностями. Если вы технический специалист - это тот документ, который не позволит вам унаследовать архитектуру в стиле «it depends», которая позже приведёт к простою.
Руководство 2: Проектирование Microsoft SQL Server для высокой доступности на VMware Cloud Foundation
Второе руководство сосредоточено там, где ставки особенно высоки: корректное проектирование доступности SQL Server на VCF без смешивания устаревших предположений, неподдерживаемых конфигураций или подхода «потом исправим» в кластеризации.
Оно написано для смешанной аудитории, включая DBA, администраторов VMware, архитекторов и IT-руководителей. И в нём ясно указано, что «доступность» — это не функция, которую добавляют в конце; выбранная модель защиты должна определяться бизнес-требованиями.
Несколько особенно практичных обновлений:
Реалии доступности SQL Server 2025, чётко сопоставленные с механизмами защиты. Руководство связывает уровни защиты с современными возможностями обеспечения доступности SQL Server, подчёркивает области, где SQL Server 2025 усиливает архитектуры на базе Availability Groups (AG), и отмечает, что Database Mirroring удалён в SQL Server 2025.
Рекомендации по согласованию жизненного цикла, которые действительно важны для IT-руководства. Начиная с SQL Server 2025, отмечается, что более старые версии Windows Server вышли из основной поддержки, и рекомендуется использовать Windows Server 2025 или Windows Server 2022 при наличии совместимости — прямой переход к поддерживаемым и обоснованным платформам.
Современные варианты кластеризации с общими дисками без навязывания устаревших архитектур. Руководство указывает, что в средах эпохи VCF 9 семантика общих дисков для FCI может быть реализована современными способами — подчёркивается использование Clustered VMDKs и явно обозначается движение в сторону отказа от устаревших зависимостей.
Рекомендации по DRS anti-affinity, предотвращающие «самоорганизованные» события HA. Если узлы кластера SQL работают на одном и том же хосте ESXi «потому что так решил DRS», это не высокая доступность, а отложенный инцидент. Настройте соответствующие правила DRS, чтобы узлы кластера были физически разделены.
Требования к vMotion Application Notification, изложенные подробно. Руководство описывает использование уведомлений приложений, включая требования, такие как актуальные VMware Tools и рекомендуемая настройка таймаутов — именно те детали, которые команды часто выясняют в условиях уже упавшей системы.
Рекомендации по vSAN ESA, отражающие текущие возможности. Указывается направление политик ESA и отмечается глобальная дедупликация (впервые представленная в VCF 9.0) как рекомендуемая для определённых сценариев Availability Group SQL Server в пределах одного кластера vSAN.
Это то руководство, которое вы передаёте команде, когда бизнес говорит: «нам нужна более высокая доступность», — и вы хотите, чтобы ответом стало инженерно проработанное решение.
Руководство 3: Виртуализация служб домена Active Directory на VMware Cloud Foundation
Active Directory (AD) Domain Services (DS) — одна из тех служб, о которых не думают до тех пор, пока всё не перестанет работать. Обновлённое руководство по AD DS прямо признаёт это, указывая, что многие организации справедливо рассматривают AD DS как по-настоящему критичное для бизнеса приложение, поскольку аутентификация, доступ к ресурсам и бесчисленные рабочие процессы зависят от него.
Оно также напрямую обращается к сохраняющемуся рефлексу «физического контроллера домена». Благодаря развитию Windows Server и зрелым практикам VCF, в руководстве говорится, что эти улучшения теперь позволяют организациям «безопасно виртуализировать сто процентов своей инфраструктуры AD DS».
Существенно обновлены не общие рекомендации «виртуализируйте это», а современный набор функций и механизмов защиты, которые меняют подход к проектированию и защите виртуальных контроллеров домена:
В руководстве указано, что лишь несколько усовершенствований существенно изменяют прежние рекомендации, включая Virtualization-Based Security (VBS), Secure Boot, шифрование на уровне виртуальной машины и улучшенную синхронизацию времени в гостевых ВМ — и эти изменения учтены там, где это необходимо.
Документ явно ориентирован на несколько аудиторий (архитекторов, инженеров/администраторов и руководителей/владельцев процессов), что важно для AD DS, поскольку проектирование и эксплуатация неразделимы.
Подчёркиваются операционные меры защиты при восстановлении после сбоев. Например, рекомендуется использовать приоритет перезапуска ВМ в vSphere HA, чтобы ключевые инфраструктурные службы запускались раньше после аварийного восстановления.
Подробно рассматриваются механизмы обеспечения целостности в эпоху виртуализации (например, поведение VM-Generation ID), созданные специально для устранения исторических опасений, связанных со снапшотами и откатами.
Если вы модернизируете инфраструктуру идентификации, консолидируете датацентры или строите частное облако на базе VCF с сильной позицией по безопасности, этот документ обязателен к прочтению. AD DS — это не просто ещё одна рабочая нагрузка. Это сущность, от которой зависит работа всего вашего стека.
Руководство 4: Запуск Microsoft SQL Server Failover Cluster Instance на VMware vSAN платформы VMware Cloud Foundation 9
Если ваша модель обеспечения доступности по-прежнему основана на кластеризации с общими дисками — будь то из-за ограничений приложений, операционных предпочтений или необходимости сохранить модель SQL Server FCI — это руководство является практическим дополнением «как это реально работает на VCF 9» к более общим рекомендациям по HA. Это эталонная архитектура для запуска Microsoft SQL Server Failover Cluster Instance (FCI) с использованием общих дисков на базе vSAN, валидированная как для стандартного кластера vSAN, так и для сценария растянутого кластера vSAN.
Несколько моментов, на которые стоит обратить внимание:
Нативная поддержка WSFC + общих дисков на vSAN (с подробным описанием механики). В VCF 9 «vSAN обеспечивает нативную поддержку виртуализированных Windows Server Failover Clusters (WSFC)» и «поддерживает SCSI-3 Persistent Reservations (SCSI3PR) на уровне виртуального диска» — ключевое требование для арбитража общих дисков в WSFC.
Две настройки конфигурации, от которых зависит работоспособность общих дисков. Указывается, что общие диски должны быть подключены к контроллеру с параметром SCSI Bus Sharing, установленным в Physical, и что «режим диска для всех дисков в кластере должен быть установлен в Independent – Persistent», чтобы избежать неподдерживаемой семантики снапшотов на общих дисках.
Операционные особенности растянутого кластера: задержки, размещение и кворум являются частью архитектуры. Рекомендуется «менее четырёх миллисекунд межсайтовой (round trip) задержки» для SQL-баз данных уровня tier-1 в растянутых кластерах vSAN, а также подчёркивается необходимость правил DRS VM/Host для разделения узлов WSFC по разным хостам.
Также рекомендуется использовать диск-свидетель кворума, чтобы растянутый кластер сохранял доступность witness-диска при отказе сайта без остановки службы кластера FCI.
Практический путь миграции с SAN pRDM на общие VMDK vSAN. С самого начала подчёркивается: «перед миграцией настоятельно рекомендуется создать резервную копию», и отмечается, что миграция выполняется офлайн. Описываются шаги по остановке роли кластера, выключению узлов и использованию Storage Migration для преобразования pRDM в VMDK на vSAN ± с обходным решением через PowerCLI (включая пример кода) в случае, если выбор формата диска в мастере Migrate недоступен.
Это руководство, которое вы передаёте команде, когда требование звучит как «нам нужна семантика FCI», и вы хотите получить осознанную, поддерживаемую архитектуру.
Что дальше
Если вы активно проектируете, обновляете или мигрируете инфраструктуру, рассматривайте эти руководства в контексте команд:
Команды платформы: сначала прочитайте руководство по SQL Server, чтобы согласовать значения по умолчанию вычислений/хранилища/сети с поведением SQL.
DBA и инженеры инфраструктуры: прочитайте руководство по HA до того, как зафиксируете модель кластеризации, стратегию хранения и модель обслуживания.
Команды по идентификации и безопасности: прочитайте руководство по AD DS, чтобы согласовать меры настройки, восстановления и операционные процессы с современными механизмами защиты виртуализации.
Команды, использующие (или стандартизирующие) SQL Server FCI: прочитайте руководство по FCI на vSAN, чтобы зафиксировать требования к общим дискам, позицию по политике хранения и ограничения растянутого кластера до внедрения.
Ниже приведены прямые ссылки для скачивания упомянутых документов:
В современных гибридных и частных облаках большое количество данных о состоянии систем поступает из самых разных источников: систем резервного копирования, хранилищ данных, SaaS-платформ и внешних сервисов. Однако интеграция этих данных в единую платформу мониторинга часто оказывается сложной задачей. Для решения этой проблемы в составе VMware Cloud Foundation был представлен инструмент Management Pack Builder (MPB), предназначенный для расширения наблюдаемости и видимости инфраструктуры. О его бета-версии мы писали еще в 2022 году, но сейчас он уже полноценно доступен в составе VCF.
Что такое Management Pack Builder
Management Pack Builder (MPB) — это функциональность VMware Cloud Foundation, представляющая собой no-code-решение для создания пакетов управления (management packs), которые позволяют импортировать данные наблюдения из внешних источников в систему мониторинга VCF Operations. MPB выполняет роль промежуточного слоя, преобразуя данные, полученные через REST API сторонних систем, в объекты, метрики, свойства и события, понятные и используемые в экосистеме VMware Cloud Foundation.
С помощью Management Pack Builder можно:
Подключаться к REST API внешних систем
Создавать собственные типы объектов мониторинга
Сопоставлять данные API с метриками и свойствами в VCF Operations
Формировать повторно используемые пакеты управления для развертывания в разных средах
Какие задачи решает Management Pack Builder
Заполнение пробелов в мониторинге
Во многих организациях используются системы, для которых не существует готовых адаптеров мониторинга VMware. MPB позволяет интегрировать такие источники данных и устранить «слепые зоны» в наблюдаемости инфраструктуры.
Упрощение интеграции сторонних решений
Традиционная разработка адаптеров требует значительных затрат времени и ресурсов. Management Pack Builder позволяет создавать интеграции без написания кода, что существенно ускоряет процесс и снижает операционные издержки.
Централизация данных наблюдаемости
MPB помогает устранить разрозненность данных, объединяя телеметрию из различных систем в единой платформе. Это упрощает корреляцию событий, ускоряет диагностику проблем и снижает среднее время восстановления сервисов.
Масштабируемость и повторное использование
Один раз созданный пакет управления может быть экспортирован и развернут в других инсталляциях VMware Cloud Foundation, обеспечивая единый подход к мониторингу в масштабах всей организации.
Работа с нестандартными API
Management Pack Builder поддерживает гибкое сопоставление данных и может использоваться даже в случаях, когда REST API внешних систем не полностью соответствует стандартным спецификациям.
Преимущества использования MPB
Использование Management Pack Builder обеспечивает следующие преимущества:
Быстрое подключение новых источников телеметрии
Единая панель мониторинга в рамках VMware Cloud Foundation
Снижение затрат на разработку и поддержку интеграций
Возможность моделирования пользовательских объектов и метрик
Простое распространение решений между средами
Типовой рабочий процесс в Management Pack Builder
Процесс создания пакета управления с помощью MPB включает следующие этапы:
Определение источника данных и необходимых конечных точек API
Проектирование объектной модели и связей между объектами
Настройка параметров сбора данных, включая аутентификацию и расписание
Сопоставление полей ответов API с метриками и свойствами
Тестирование корректности сбора и отображения данных
Экспорт и развертывание пакета управления в других средах
Пример использования: мониторинг задач резервного копирования
Предположим, что система резервного копирования предоставляет данные о заданиях через REST API, включая статус выполнения, продолжительность и объем обработанных данных. С помощью Management Pack Builder можно:
Подключиться к API системы резервного копирования
Создать новый тип объекта, представляющий задачу резервного копирования
Определить метрики, отражающие состояние и эффективность выполнения
Настроить дашборды и оповещения в VCF Operations
Использовать созданный пакет управления в других кластерах
Данный процесс на примере решения Rubrik показан в видео ниже:
В результате информация о резервном копировании становится частью единой системы наблюдаемости VMware Cloud Foundation, и вам не потребуется никаких отдельных консолей для мониторинга этого процесса.
Рекомендации по эффективному использованию MPB
Для успешного применения Management Pack Builder рекомендуется:
Начинать с минимального набора метрик и постепенно расширять модель
Использовать стабильные и уникальные идентификаторы объектов
Оптимизировать частоту опроса API, чтобы избежать избыточной нагрузки
Использовать примеры и лучшие практики, опубликованные в сообществах VMware
Роль Management Pack Builder в экосистеме VMware Cloud Foundation
VMware Cloud Foundation ориентирован на обеспечение унифицированного управления, операций и наблюдаемости в гибридных и частных облаках. Management Pack Builder дополняет эту концепцию, позволяя включать в контур мониторинга любые внешние и пользовательские системы.
Это обеспечивает целостное представление о состоянии инфраструктуры и приложений, независимо от источника данных.
Заключение
Management Pack Builder является важным инструментом для расширения возможностей наблюдаемости в VMware Cloud Foundation. Он позволяет быстро и гибко интегрировать сторонние источники телеметрии, сократить затраты на разработку адаптеров и централизовать мониторинг.
Использование MPB помогает организациям получить полную и целостную картину состояния своей инфраструктуры, повышая надежность и управляемость IT-среды.
Отличные новости для сетевых инженеров и архитекторов, работающих в экосистеме VMware. Компания представила новую сертификацию VMware Certified Advanced Professional – VCAP Administrator Networking (3V0-25.25). Этот экзамен продвинутого уровня (VCAP) предназначен для подтверждения глубоких знаний и практических навыков в проектировании, развертывании и администрировании сетевых решений VMware Cloud Foundation (VCF).
Новый стандарт профессиональной экспертизы в VCF Networking
Экзамен 3V0-25.25 ориентирован на опытных ИТ-специалистов, которые работают с современными корпоративными и мультиоблачными инфраструктурами. Получение данной сертификации демонстрирует способность кандидата эффективно решать сложные сетевые задачи в рамках архитектуры VMware Cloud Foundation.
Ключевые параметры экзамена:
Код экзамена: 3V0-25.25
Продолжительность: 135 минут
Количество вопросов: 60
Проходной балл: 300
Стоимость: 250 USD
Язык: английский
Кому подойдет эта сертификация
Экзамен рассчитан на специалистов с уверенным опытом в корпоративных сетях и экспертизой по решению VMware NSX. Рекомендуемый профиль кандидата включает:
1–2 года практического опыта проектирования и администрирования решений NSX
Не менее 2 лет работы с Enterprise-сетями
Уверенное владение UI-, CLI- и API-ориентированными рабочими процессами VCF
Практический опыт работы с VCF Networking и vSphere
Если вы ежедневно сталкиваетесь с проектированием и эксплуатацией сложных сетевых архитектур, этот экзамен станет логичным шагом в развитии карьеры.
Что проверяет экзамен 3V0-25.25
Основной акцент в экзамене сделан на планирование и дизайн сетевых решений VCF, с максимальной ориентацией на реальные архитектурные сценарии. Ключевые области оценки знаний включают:
ИТ-архитектуры, технологии и стандарты - проверяется понимание архитектурных принципов, умение различать бизнес- и технические требования, а также управлять рисками и ограничениями при проектировании.
Планирование и проектирование решений VMware - центральный блок экзамена, оценивающий способность спроектировать полноценное решение VMware Cloud Foundation с учетом доступности, управляемости, производительности, безопасности и восстановляемости.
Несмотря на то что в экзаменационном гайде указано наличие разделов без активных проверяемых целей, глубокое понимание всего жизненного цикла VCF Networking — от установки до устранения неполадок — значительно повышает шансы на успех.
Как подготовиться к экзамену
VMware рекомендует сочетать практический опыт с целенаправленным обучением. Для подготовки к экзамену доступны следующие курсы:
VMware Cloud Foundation Networking Advanced Design
VMware Cloud Foundation Networking Advanced Configuration
VMware Cloud Foundation Networking Advanced Troubleshooting
Также крайне важно изучить официальную документацию VMware Cloud Foundation 9.0, актуальные release notes и технические материалы от Broadcom, чтобы быть в курсе всех возможностей и изменений платформы.
Будьте среди первых сертифицированных специалистов
Выход сертификации VMware Certified Advanced Professional – VCF Networking — значимое событие для профессионалов в области сетевых технологий. Этот статус подтверждает высокий уровень экспертизы и позволяет выделиться на фоне других специалистов, открывая новые карьерные возможности. Если вы хотите быть на передовой в индустрии и официально подтвердить свои знания в области VCF Networking — сейчас самое время сделать этот шаг.
Недавно был выпущен пакет управления vCommunity Management Pack для VCF Operations (подробнее о нем - тут), который охватывает несколько сценариев использования, включая: расширенные системные настройки хоста ESX, его пакеты и лицензирование, статус сетевых интерфейсов (NIC), расширенные параметры виртуальных машин, параметры ВМ, типы контроллеров SCSI виртуальных машин, а также службы события Windows.
Ну а на днях стал доступен для скачивания проект Hardware vCommunity Management Pack для VCF Operations, разрабатываемый инженером Broadcom Онуром Ювсевеном. Начальная версия поддерживает серверы Dell EMC PowerEdge (с использованием Redfish API на iDRAC). Он собирает десятки метрик, свойств и событий. Пакет управления включает 5 дашбордов, 8 представлений, 14 алертов и 19 симптомов (symptoms). Дашборды выглядят следующим образом.
Сам Management Pack можно скачать здесь. После загрузки он устанавливается так же, как и любой другой Management Pack. Затем необходимо создать экземпляр адаптера (или несколько, если требуется), который будет выглядеть примерно следующим образом.
Существует несколько требований:
Файл конфигурации физических серверов — список FQDN/IP-адресов серверов Dell EMC. Файлы конфигурации можно создать в разделе Operations > Configurations > Management Pack Configurations > User Defined. Формат должен быть вот таким.
Учётные данные iDRAC Redfish API (только чтение), а также Dell TechDirect Client ID/Secret (если требуется информация о гарантии).
Collector/Group — необходимо использовать Cloud Proxy.
Dell iDRAC Log Monitoring — уровень событий iDRAC, которые вы хотите собирать (или Disabled, если сбор не нужен).
Dell TechDirect URL — URL Dell TechDirect, к которому экземпляр адаптера будет обращаться для получения информации о гарантии.
Maximum worker threads for data collection — максимальное количество рабочих потоков для сбора данных (по умолчанию 200).
Maximum worker threads for ping request — максимальное количество рабочих потоков для ping-запросов (по умолчанию 100).
Adapter Mode — режим работы адаптера: Server Monitoring или PING Only.
Adapter Memory Limit (MB) — максимальный объём памяти, который будет использовать экземпляр адаптера.
После установки назначьте Custom Group Dell EMC Servers политике Hardware vCommunity Policy. Это включит все определения оповещений. vCommunity Management Pack создаст новый тип объекта с именем Physical Server.
MP собирает десятки метрик и свойств не только по самому серверу, но также по батареям, блокам питания, вентиляторам и другим компонентам. Кроме того, был добавлен бонусный дашборд (Dell EMC Server Details), который при желании можно использовать в качестве страницы сводной информации по физическому серверу (Physical Server Summary Page).
Чтобы настроить этот дашборд как страницу сводки физического сервера, выполните описанные здесь действия. После настройки он будет выглядеть следующим образом.
vCommunity Hardware Management Pack также включает алерты, как показано ниже:
Два ключевых свойства, которые собираются и по которым формируются оповещения — это остаточный прогнозируемый срок службы физического диска (Physical Disk Predicted Media Life Remaining) и оставшийся срок гарантии (Warranty Remaining), что позволяет администраторам заблаговременно планировать обслуживание и предотвращать проблемы.
В дальнейшем планируется расширение функциональности, включая связи с хостами ESX и поддержку дополнительных аппаратных платформ. Скачивайте и начинайте использовать уже сегодня!
Это заключительная часть серии статей (см. прошлые части тут, тут, тут, тут, тут и тут), посвящённых технологии Memory Tiering. В предыдущих публикациях мы рассмотрели архитектуру, проектирование, расчёт ёмкости и базовую настройку, а также другие темы. Теперь мы переходим к расширенной конфигурации. Эти параметры не являются обязательными для работы функции как таковой, но предоставляют дополнительные возможности - такие как шифрование данных и настройка соотношений памяти, но и не только.
Хотя значения по умолчанию в vSphere в составе VMware Cloud Foundation 9.0 разработаны так, чтобы «просто работать» в большинстве сред, для настоящей оптимизации требуется тонкая настройка. Независимо от того, используете ли вы виртуальные рабочие столы или базы данных, важно понимать, какие рычаги управления стоит задействовать.
Ниже описано, как освоить расширенные параметры для настройки соотношений памяти, шифрования на уровне хоста и отдельных ВМ, а также отключения технологии Memory Tiering на уровне отдельных машин.
Настройка соотношения DRAM:NVMe
По умолчанию при включении Memory Tiering ESX устанавливает соотношение DRAM к NVMe равным 1:1, то есть 100% дополнительной памяти за счёт NVMe. Это означает, что при наличии 512 ГБ DRAM хост получит ещё 512 ГБ NVMe-ёмкости в качестве памяти Tier 1, что в сумме даст 1 ТБ памяти.
Однако в зависимости от типа рабочих нагрузок вы можете захотеть изменить эту плотность. Например, в VDI-среде, где ключевым фактором является стоимость одного рабочего стола, может быть выгодно использовать более высокое соотношение (больше NVMe на каждый гигабайт DRAM). Напротив, для кластеров с высокими требованиями к производительности вы можете захотеть ограничить размер NVMe-яруса.
Управление этим параметром осуществляется через расширенную системную настройку хоста: Mem.TierNVMePct.
Параметр
Где настраивается: Host Advanced System Settings
Ключ: Mem.TierNVMePct
Значение: процент DRAM, используемый в качестве NVMe-яруса
Возможные значения:
100 (по умолчанию): 100% от объёма DRAM (соотношение 1:1)
200: 200% от объёма DRAM (соотношение 1:2)
50: 50% от объёма DRAM — очень консервативный вариант (соотношение 2:1)
Примечание. Рекомендации и лучшие практики предполагают сохранение соотношения по умолчанию 1:1, так как оно подходит для большинства рабочих нагрузок. Если вы решите изменить это соотношение, необходимо предварительно тщательно проанализировать свои нагрузки и убедиться, что вся активная память может быть размещена в объёме DRAM хоста. Подробнее о расчёте ёмкости Memory Tiering см. вот тут.
Защита уровня: шифрование
Одним из архитектурных различий между DRAM и NVMe является постоянство хранения данных. В то время как обычная оперативная память теряет данные (практически) мгновенно при отключении питания, NVMe является энергонезависимой. Несмотря на то что VMware выполняет очистку страниц памяти, организации с повышенными требованиями к безопасности (особенно в регулируемых отраслях) часто требуют шифрование данных «на диске» (Data-at-Rest Encryption) для любых данных, записываемых на накопители, даже если эти накопители используются как память. Более подробное описание шифрования NVMe в контексте Memory Tiering приведено вот тут.
Здесь доступны два уровня управления: защита всего NVMe-уровня хоста целиком либо выборочное шифрование данных только для определённых виртуальных машин, вместо шифрования данных всех ВМ на хосте.
Вариант A: шифрование на уровне хоста
Это «универсальный» подход. Он гарантирует, что любая страница памяти, перемещаемая из DRAM в NVMe-уровень на данном хосте, будет зашифрована с использованием алгоритма AES-XTS.
Параметр
Где настраивается:Host Advanced Configuration Parameters
Ключ: Mem.EncryptTierNvme
Значение: 1 — включено, 0 — отключено
Вариант Б: шифрование на уровне виртуальной машины
Если вы хотите включить шифрование только для отдельных виртуальных машин — то есть шифровать лишь те страницы памяти, которые размещаются на NVMe, — вы можете применить эту настройку только к наиболее критичным рабочим нагрузкам (например, контроллерам домена или финансовым базам данных).
Параметр
Где настраивается: VM Advanced Configuration Parameters
Ключ: sched.mem.EncryptTierNVMe
Значение: TRUE
Отказ от использования: отключение Memory Tiering для критичных ВМ
Memory Tiering отлично подходит для «холодных» данных, однако «горячие» данные должны находиться в DRAM. Несмотря на то, что планировщик ESX чрезвычайно интеллектуален в вопросах размещения страниц памяти, некоторые рабочие нагрузки слишком чувствительны, чтобы допускать даже минимальные всплески задержек, связанные с использованием Memory Tiering.
Типичные сценарии использования:
SAP HANA и другие in-memory базы данных
Приложения для высокочастотной торговли (High-Frequency Trading)
Виртуальные машины безопасности
Кроме того, существуют профили виртуальных машин, которые в настоящее время не поддерживают Memory Tiering, такие как ВМ с низкой задержкой, ВМ с Fault Tolerance (FT), ВМ с большими страницами памяти (large memory pages) и др. Для таких профилей Memory Tiering необходимо отключать на уровне виртуальной машины. Это принудительно размещает страницы памяти ВМ исключительно в Tier 0 (DRAM). Полный список профилей ВМ см. в официальной документации VMware.
Параметр
Где настраивается: VM Advanced Configuration Parameters
Ключ: sched.mem.enableTiering
Значение: FALSE
Ну и в заключение - таблица расширенных параметров Memory Tiering:
Memory Tiering в VCF 9.0 представляет собой серьёзный сдвиг в подходе к плотности серверов и интеллектуальному потреблению ресурсов. Эта технология уводит нас от жёсткого «потолка по RAM» и предоставляет гибкий, экономически эффективный буфер памяти. Однако, как и в случае с любым мощным инструментом, значения по умолчанию — лишь отправная точка. Используя описанные выше параметры, вы можете настроить поведение системы в соответствии как с ограничениями бюджета, так и с требованиями SLA.
Наверняка не всем из вас знаком ресурс virten.net — технический портал, посвящённый информации, новостям, руководствам и инструментам для работы с продуктами VMware и виртуализацией. Сайт предлагает полезные ресурсы как для ИТ-специалистов, так и для энтузиастов виртуализации, включая обзоры версий, документацию, таблицы сравнений и практические руководства.
Там можно найти:
Новости и статьи о продуктах VMware (релизы, обновления, сравнения версий, технические обзоры).
Полезные разделы по VMware vSphere, ESX, vCenter и другим продуктам, включая истории релизов, конфигурационные лимиты и различия между версиями.
Практические инструменты и утилиты, такие как декодеры SCSI-кодов, RSS-трекер релизов (vTracker), помощь по OVF/PowerShell, события vCenter и JSON-репозиторий полезных данных.
Давайте посмотрим, что на этом сайте есть полезного для администраторов инфраструктуры VMware Cloud Foundation.
Эта страница содержит список продуктов, выпущенных компанией VMware. vTracker автоматически обновляется, когда на сайте vmware.com становятся доступны для загрузки новые продукты (GA — общедоступный релиз). Если вы хотите получать уведомления о выходе новых продуктов VMware, подпишитесь на RSS-ленту. Вы также можете использовать экспорт в формате JSON для создания собственного инструмента. Не стесняйтесь оставлять там комментарии, если у вас есть предложения по новым функциям.
Если вы просто хотите узнать, какая версия того или иного продукта VMware сейчас актуальна, самый простой способ - это посмотреть вот эту таблицу с функцией поиска:
В этом разделе представлен полный перечень релизов флагманского гипервизора VMware ESX (ранее ESXi). Все версии, выделенные жирным шрифтом, доступны для загрузки. Все патчи указаны под своими официальными названиями релизов, датой выхода и номером билда. Обратите внимание, что гипервизор ESXi доступен начиная с версии 3.5.
Если вы столкнулись с какими-либо проблемами при работе с этим сайтом или заметили отсутствие сборок, пожалуйста, свяжитесь с автором.
Эта страница представляет собой коллекцию заранее настроенных фрагментов PowerShell-скриптов для развертывания OVF/OVA. Идея заключается в ускорении процесса развертывания, если вам необходимо устанавливать несколько виртуальных модулей, выполнять повторное развертывание из-за неверных входных данных или сохранить файл в качестве справочного примера для будущих установок.
Просто заполните подготовленные переменные так же, как вы обычно делаете это в клиенте vSphere, и запустите скрипт. Все шаблоны используют одинаковую последовательность действий и тексты подсказок из мастера развертывания. Необязательные параметры конфигурации можно закомментировать. Если у параметров есть значения по умолчанию, они уже заполнены.
Ошибки или предупреждения SCSI в логах и интерфейсе ESX отображаются с использованием 6 кодов состояния. Эта страница преобразует эти коды, полученные от хостов ESX, в понятную для человека информацию о состоянии подсистемы хранения. В системном журнале vmkernel.log на хостах ESXi версии 5.x или 6.0 вы можете увидеть записи, подобные приведённым ниже. На странице декодера вы можете ввести нужные числа в форму и получить пояснения по сообщениям SCSI:
Виртуализация решила основную проблему «один сервер — одно приложение». Контейнеризация опиралась на этот результат и уточнила способ его достижения. Однако виртуализация остаётся основой современной вычислительной среды, и многие из наиболее критически важных рабочих нагрузок в мире продолжают и будут продолжать работать в виртуальных машинах. Помимо своей долговечности, виртуализация улучшает контейнеризацию и Kubernetes, помогая обеспечивать ключевые результаты, которых ожидают пользователи и которые требуются бизнесу.
Администраторы ИТ-инфраструктур и ИТ-менеджеры часто задают вопросы наподобие: «Какое отношение виртуализация имеет к Kubernetes?» Понимание этого крайне важно для ИТ-подразделений и организационных бюджетов. Вычисления революционизировали то, как мы взаимодействуем друг с другом, как работаем, и сформировали рамки возможного в промышленности. ИТ-нагрузки требуют вычислительных ресурсов, таких как CPU, память, хранилище, сеть и т. д., чтобы выполнять нужные функции — например, отправку электронного письма или обновление базы данных. Важная часть бизнес-операций заключается в том, чтобы ИТ-организации оптимизировали стратегию размещения своих нагрузок — будь то на мейнфрейме, в локальном дата-центре или в публичном облаке.
Виртуализация не исчезла с появлением Kubernetes — напротив, она помогает Kubernetes работать лучше в масштабе предприятия.
Виртуализация
С зарождения электронной вычислительной техники в 1940-х годах пользователи взаимодействовали с выделенным физическим оборудованием для выполнения своих задач. Приложения, рабочие нагрузки и оборудование стремительно развивались и расширяли возможности, сложность и охват того, что пользователи могли делать с помощью вычислений. Однако оставалось ключевое ограничение — одна машина, или сервер, выделялась под одно приложение. Например, у организаций были серверы, выделенные под почтовую функциональность, или целый сервер, выделенный под действия, выполнявшиеся лишь несколько раз в месяц, такие как начисление заработной платы.
Виртуализация — использование технологий для имитации ИТ-ресурсов — была впервые реализована в 1960-х годах на мейнфреймах. В ту эпоху виртуализация обеспечивала совместный доступ к ресурсам мейнфрейма и позволяла использовать мейнфреймы для нескольких приложений и сценариев. Это стало прообразом современной виртуализации и облачных вычислений, позволяя нескольким приложениям работать на выделенном оборудовании.
VMware возглавила бум облачных вычислений благодаря виртуализации архитектуры x86 — самого распространённого набора инструкций для персональных компьютеров и серверов. Теперь физическое оборудование могло размещать несколько распределённых приложений, поддерживать многих пользователей и полностью использовать дорогостоящее «железо». Виртуализация — ключевая технология, которая делает возможными публичные облачные вычисления; ниже приведено резюме:
Абстракция: виртуализация абстрагирует физическое оборудование, предоставляющее CPU, RAM и хранилище, в логические разделы, которыми можно управлять независимо.
Гибкость, масштабируемость, эластичность: абстрагированные разделы теперь можно масштабировать под потребности бизнеса, выделять и отключать по требованию, а ресурсы - возвращать по мере необходимости.
Консолидация ресурсов и эффективность: физическое оборудование теперь может запускать несколько логических разделов «правильного размера» с нужным объёмом CPU, RAM и хранилища — максимально используя оборудование и снижая постоянные затраты, такие как недвижимость и электроэнергия.
Изоляция и безопасность: у каждой ВМ есть собственный «мир» с ОС, независимой от той, что запущена на физическом оборудовании, что обеспечивает глубокую безопасность и изоляцию для приложений, использующих общий хост.
Для большинства предприятий и организаций критически важные рабочие нагрузки, обеспечивающие их миссию, рассчитаны на работу в виртуальных машинах, и они доверяют Broadcom предоставлять лучшие ВМ и лучшие технологии виртуализации. Доказав, что инфраструктуру можно абстрагировать и управлять ею независимо от физического оборудования, виртуализация заложила основу для следующей эволюции размещения рабочих нагрузок.
Контейнеризация
По мере роста вычислительных потребностей экспоненциально росла и сложность приложений и рабочих нагрузок. Приложения, которые традиционно проектировались и управлялись как монолиты, то есть как единый блок, начали разбиваться на меньшие функциональные единицы, называемые микросервисами. Это позволило разработчикам и администраторам приложений управлять компонентами независимо, упрощая масштабирование, обновления и повышая надёжность. Эти микросервисы запускаются в контейнерах, которые стали популярны в отрасли благодаря Docker.
Контейнеры Docker упаковывают приложения и их зависимости - такие как код, библиотеки и конфигурационные файлы - в единицы, которые могут стабильно работать на любой инфраструктуре: будь то ноутбук разработчика, сервер в датацентре предприятия или сервер в публичном облаке. Контейнеры получили своё название по аналогии с грузовыми контейнерами и дают многие из тех же преимуществ, что и их физические «тёзки», такие как стандартизация, переносимость и инкапсуляция. Ниже — краткий обзор ключевых преимуществ контейнеризации:
Стандартизация: как грузовые контейнеры упаковывают товары в формат, с которым другое оборудование может взаимодействовать единообразно, так и программные контейнеры упаковывают приложения в унифицированную, логически абстрагированную и изолированную среду
Переносимость: грузовые контейнеры перемещаются с кораблей на грузовики и поезда. Программные контейнеры могут запускаться на ноутбуке разработчика, в средах разработки, на продакшн-серверах и между облачными провайдерами
Инкапсуляция: грузовые контейнеры содержат всё необходимое для выполнения заказа. Программные контейнеры содержат код приложения, среду выполнения, системные инструменты, библиотеки и любые другие зависимости, необходимые для запуска приложения.
Изоляция: и грузовые, и программные контейнеры изолируют своё содержимое от других контейнеров. Программные контейнеры используют общую ОС физической машины, но не зависимости приложений.
По мере того как контейнеры стали отраслевым стандартом, команды начали разрабатывать собственные инструменты для оркестрации и управления контейнерами в масштабе. Kubernetes появился из этих проектов в 2015 году, а затем был передан сообществу open source. Продолжая морскую тематику контейнеров, Kubernetes по-гречески означает «рулевой» или «пилот» и выполняет роль мозга инфраструктуры.
Контейнер позволяет легко развёртывать приложения - Kubernetes позволяет масштабировать число экземпляров приложения, он гарантирует, что каждый экземпляр остаётся запущенным, и работает одинаково у любого облачного провайдера или в любом датцентре. Это три «S»-столпа: самовосстановление (Self-Healing), масштабируемость (Scalability) и стандартизация (Standardization). Эти результаты ускорили рост Kubernetes до уровня отраслевого золотого стандарта, и он стал повсеместным в cloud native-вычислениях, обеспечивая операционную согласованность, снижение рисков и повышенную переносимость.
Виртуализация > Контейнеризация
Виртуализация проложила путь разработчикам к размещению и изоляции нескольких приложений на физическом оборудовании, администраторам — к управлению ИТ-ресурсами, отделёнными от базового оборудования, и доказала жизнеспособность абстрагирования нижних частей стека для запуска и масштабирования сложного ПО. Контейнеры развивают эти принципы и абстрагируют уровень приложений, предоставляя следующие преимущества по сравнению с виртуализацией:
Эффективность: благодаря общей ОС контейнеры устраняют накладные расходы (CPU, память, хранилище), связанные с запуском нескольких одинаковых ОС для приложений.
Скорость: меньший «вес» позволяет значительно быстрее запускать и останавливать.
Переносимость: контейнеры лёгкие и могут выполняться на любом совместимом контейнерном рантайме.
Виртуализация улучшает Kubernetes
Виртуализация также стабилизирует и ускоряет Kubernetes. Большинство управляемых Kubernetes-сервисов, включая предложения гиперскейлеров (EKS на AWS, AKS на Azure, GKE на GCP), запускают Kubernetes-слой поверх виртуализованной ОС. Поскольку Kubernetes-среды обычно сложны, виртуализация значительно усиливает изоляцию, безопасность и надёжность, а также упрощает операции управления накладными процессами. Краткий обзор преимуществ:
Изоляция и безопасность: без виртуализации все контейнеры, работающие в кластере Kubernetes на физическом хосте, используют один и тот же Kernel (ядро ОС). Если контейнер взломан, всё, что работает на физическом хосте, потенциально может быть скомпрометировано на уровне оборудования. Гипервизор препятствует распространению злоумышленников на другие узлы Kubernetes и контейнеры.
Надёжность: Kubernetes может перезапускать контейнеры, если те падают, но бессилен, если проблемы возникают на уровне физического хоста. Виртуализация может перезапустить окружение Kubernetes за счёт высокой доступности (High Availability) на другом физическом сервере.
Операции: без виртуализации весь физический хост обычно принадлежит одному Kubernetes-кластеру. Это означает, что среда привязана к одной версии Kubernetes, что снижает скорость развития и делает апгрейды и операции сложными.
Именно поэтому каждый крупный управляемый Kubernetes-сервис работает на виртуальных машинах: виртуализация обеспечивает изоляцию, надёжность и операционную гибкость, необходимые в корпоративном масштабе.
Broadcom предоставляет лучшую платформу для размещения рабочих нагрузок
Инженерные команды Broadcom продолжают активно участвовать в upstream Kubernetes и вносят вклад в такие проекты, как Harbor, Cluster API и etcd.
С выпуском VCF 9 подразделение VCF компании Broadcom принесло в отрасль унифицированные операции, общую инфраструктуру и единые инструменты, независимые от форм-факторов рабочих нагрузок. Клиенты могут запускать ВМ и контейнеры/Kubernetes-нагрузки на одном и том же оборудовании и управлять ими одними и теми же инструментами, на которых миллионы специалистов построили свои навыки и карьеры. Предприятия и организации могут снизить капитальные и операционные расходы, стандартизировать операционную модель и модернизировать приложения и инфраструктуру, чтобы бизнес мог двигаться быстрее, защищать данные и повышать надёжность своих ключевых систем.
В этой части статей о технологии NVMe Memory Tiering (см. прошлые части тут, тут, тут, тут и тут) мы поговорим о настройке этой технологии на серверах VMware ESX инфраструктуры VCF.
На протяжении всей этой серии статей мы рассматривали важные аспекты, которые следует учитывать перед настройкой Memory Tiering, такие как проектирование, подбор размеров, совместимость, избыточность, безопасность и многое другое. Теперь пришло время применить то, чему вы научились, и оптимизировать эту функцию для вашей среды, бюджета и стратегии.
Поскольку во многих статьях подробно описаны шаги настройки, этот пост будет сосредоточен на подходе высокого уровня и будет ссылаться на предыдущие посты для конкретных разделов. Всегда полагайтесь на официальную документацию Broadcom для точных шагов настройки — официальное руководство можно найти здесь, ну а основные аспекты развертывания Memory Tiering мы описывали тут.
Шаги настройки
Технически для настройки Memory Tiering в вашей среде требуется всего два шага, но мы добавили задачи до и после настройки, чтобы обеспечить должную тщательность и проверить внедрение.
Предварительные проверки
Плотники живут по правилу «семь раз отмерь — один раз отрежь», потому что после разреза нельзя прокрутить фарш обратно. Чтобы избежать критических ошибок при настройке, мы должны сначала убедиться, что приняли правильные архитектурные решения для нашей среды.
После того как вы приняли все эти важные решения, этап предварительных проверок включает подтверждение того, что устройства корректно отображаются на всех ESX-хостах. Вам понадобится UID каждого устройства, чтобы создать раздел, который будет использоваться Memory Tiering.
Создание разделов
Первый шаг — создание раздела для каждого NVMe-устройства. Независимо от того, разворачиваете ли вы одно устройство на хост или используете аппаратный RAID, раздел требуется на каждом логическом NVMe-устройстве.
Методы:
ESXCLI: выполните стандартную команду esxcli (подробности тут).
PowerShell: создайте скрипт для автоматизации процесса. Пример скрипта доступен тут, он может быть изменён под среду вашего кластера.
Частые вопросы
Вопрос: Могу ли я настроить разделы на двух устройствах без RAID на одном и том же хосте для обеспечения избыточности?
Ответ: Нет. Хотя VCF 9.0 позволяет без ошибок создавать разделы Memory Tiering на нескольких устройствах на хост, система не объединяет их и не зеркалирует данные.
Результат: Memory Tiering смонтирует только один диск, выбранный недетерминированным образом в процессе загрузки. Второй диск будет проигнорирован и не даст ни избыточности, ни увеличения ёмкости (см. будущую информацию об обновлении VCF 9.1 - там что-то может поменяться).
Включение Memory Tiering
Этот шаг активирует функцию Memory Tiering. Вы можете выполнить эту настройку через ESXCLI, PowerShell или интерфейс vCenter UI, применяя её к отдельным хостам или ко всему кластеру одновременно.
Вопрос: Требуется ли настраивать Memory Tiering на всех хостах в кластере VCF 9.0?
Ответ: Нет. У вас есть возможность выбрать конкретные хосты для Memory Tiering.
Хотя идеально, чтобы все хосты имели одинаковую конфигурацию, все понимают, что определённые ограничения ВМ могут потребовать исключений (см. тут).
Самый эффективный способ настроить Memory Tiering — использовать профили конфигурации vSphere. Это позволяет включить функцию сразу на всех ваших хостах, одновременно используя переопределения хостов для тех хостов, где вы не хотите включать её. Подробнее — тут.
Финальный шаг
Последний шаг прост: перезагрузите все хосты и выполните проверку. В VCF/VVF 9.0 перезагрузка является обязательной, чтобы эта функция вступила в силу.
Если вы используете профили конфигурации (Configuration Profiles), система автоматизирует поочерёдные перезагрузки (одна за другой), одновременно мигрируя ВМ, чтобы они оставались в сети. И если вам интересно, обеспечивает ли этот метод также доступность данных vSAN - ответ: да.
После того как все хосты снова будут онлайн, вы увидите новые элементы в интерфейсе, расположенные в разделах Advanced System Settings, на вкладке Monitor, а также Configure > Hardware > Overview > Memory.
Вы также должны увидеть, что по умолчанию объём доступной памяти увеличился в 2 раза как на уровне хоста, так и на уровне кластера. Вот это простой и недорогой способ удвоить ваш объём памяти!
В заключение: включение Memory Tiering - очень простой и понятный процесс. В качестве бонуса добавляем ссылку на актуальную лабораторную работу (Hands-on Lab), посвящённую Memory Tiering. Там вы можете выполнить настройку «от начала до конца», включая расширенные параметры, которые будут рассмотрены в следующих постах.
В этой статье мы завершаем рассказывать об итогах 2025 года в сферах серверной и настольной виртуализации на базе российских решений. Сегодня мы поговорим о том, как их функционал соотносится с таковым от ведущего мирового производителя - VMware.
Первую часть статьи можно прочитать тут, вторая - доступна здесь.
Сравнение с VMware vSphere
Как же отечественные решения выглядят на фоне VMware vSphere, многолетнего эталона в сфере виртуализации? По набору функций российские платформы стремятся обеспечить полный паритет с VMware – и во многом этого уже достигли. Однако при более глубоком сравнении выявляются отличия в зрелости, экосистеме и опыте эксплуатации.
Функциональность
Почти все базовые возможности VMware теперь доступны и в отечественных продуктах: от управления кластерами, миграции ВМ на лету и снапшотов до сетевой виртуализации и распределения нагрузки. Многие платформы прямо ориентируются на VMware при разработке. Например, SpaceVM позиционирует свои компоненты как аналоги VMware: SDN Flow = NSX, FreeGRID = NVIDIA vGPU (для Horizon), Space Dispatcher = Horizon Connection Server. ZVirt, Red, ROSA, SpaceVM – все поддерживают VMware-совместимые форматы виртуальных дисков (VMDK/OVA) и умеют импортировать ВМ из vSphere.
То есть миграция технически осуществима без кардинальной переделки ВМ. Live Migration, HA, кластеры, резервирование – эти функции стали стандартом де-факто, и российские продукты их предоставляют. Более того, появились и некоторые новые возможности, которых нет в базовом издании vSphere: например, интеграция с Kubernetes (KubeVirt) в решении Deckhouse от Flant позволяет управлять ВМ через Kubernetes API – VMware предлагает нечто подобное (vSphere with Tanzu), но это отдельно лицензируемый модуль.
Другой пример – поддержка облачных сервисов: некоторые отечественные платформы сразу рассчитаны на гибридное облако, тогда как VMware требует vCloud Suite (сейчас это часть платформы VMware Cloud Foundation, VCF). Тем не менее, зрелость функционала различается: если у VMware каждая возможность отполирована годами использования по всему миру, то у новых продуктов возможны баги или ограничения. Эксперты отмечают, что просто сравнить чекбоксы “есть функция X” – недостаточно, важна реализация. У VMware она, как правило, образцовая, а у российского аналога – может требовать ручных доработок. Например, та же миграция ВМ в российских системах работает, но иногда возникают нюансы с live migration при специфических нагрузках (что-то, что VMware давно решила).
Производительность и масштабирование
VMware vSphere славится стабильной работой кластеров до 64 узлов (в v7 – до 96 узлов) и тысяч ВМ. В принципе, и наши решения заявляют сопоставимый масштаб, но проверены они временем меньше. Как упоминалось, некоторые продукты испытывали сложности уже на 50+ хостах. Тем не менее, для 90% типовых инсталляций (до нескольких десятков серверов) разницы в масштабируемости не будет. По производительности ВМ – разница тоже минимальна: KVM и VMware ESXi показывают близкие результаты бенчмарков. А оптимизации вроде vStack с 2% overhead вообще делают накладные расходы незаметными. GPU-виртуализация – здесь VMware имела преимущество (технология vGPU), но сейчас SpaceVM и другие сократили отставание своим FreeGRID. Зато VMware до последнего времени обеспечивала более широкую поддержку оборудования (драйверы для любых RAID, сетевых карт) – российские ОС и гипервизоры поддерживают далеко не все модели железа, особенно новейшие. Однако ситуация улучшается за счет локализации драйверов и использования стандартных интерфейсов (VirtIO, NVMe и пр.).
Совместимость и экосистема
Ключевое различие – в экосистеме смежных решений. Окружение VMware – это огромный пласт интеграций: сотни backup-продуктов, мониторингов, готовых виртуальных апплаенсов, специальных плагинов и т.д. В российской экосистеме такого разнообразия пока нет. Многие специализированные плагины и appliance, рассчитанные на VMware, не будут работать на отечественных платформах.
Например, виртуальные апплаенсы от зарубежных вендоров (сетевые экраны, балансировщики), выпускались в OVF под vSphere – их можно включить и под KVM, но официальной поддержки может не быть. Приходится либо искать аналогичный российский софт, либо убеждаться, что в open-source есть совместимый образ. Интеграция с enterprise-системами – тоже вопрос: у VMware был vCenter API, поддерживаемый многими инструментами. Отечественным гипервизорам приходится писать собственные модули интеграции. Например, не все мониторинговые системы «из коробки» знают про zVirt или SpaceVM – нужно настраивать SNMP/API вручную.
Такая же ситуация с резервным копированием: знакомые всем Veeam и Veritas пока не имеют официальных агентов под наши платформы (хотя Veeam частично работает через стандартный SSH/VIX). В итоге на текущем этапе экосистема поддержки у VMware гораздо более развита, и это объективный минус для новых продуктов. Однако постепенно вокруг популярных российских гипервизоров формируется своё сообщество: появляются модули для Zabbix, адаптеры для Veeam через скрипты, свои решения backup (например, CyberProtect для Cyber Infrastructure, модуль бэкапа в VMmanager и т.п.).
Надёжность и поддержка
VMware десятилетиями оттачивала стабильность: vSphere известна редкими «падениями» и чётким поведением в любых ситуациях. Российским платформам пока ещё не хватает шлифовки – пользователи отмечают, что полностью «скучной» работу с ними назвать нельзя. Периодически инженерам приходится разбираться с нетривиальными багами или особенностями. В пример приводят трудоёмкость настройки сетевой агрегации (линков) – то, что на VMware привычно, на некоторых отечественных системах реализовано иначе и требует дополнительных манипуляций.
При обновлении версий возможны проблемы с обратной совместимостью: участники рынка жалуются, что выход каждого нового релиза иногда «ломает» интеграции, требуя доработки скриптов и настроек. Отсюда повышенные требования к квалификации админов – нужно глубже понимать «под капотом», чем при работе с отлаженной VMware. Но есть и плюс: почти все российские вендоры предоставляют оперативную техподдержку, зачастую напрямую от команд разработчиков. В критических случаях они готовы выпустить патч под конкретного заказчика или дать обходной совет. В VMware же, особенно после перехода на Broadcom, поддержка стала менее клиентоориентированной для средних клиентов. В России же каждый клиент на вес золота, поэтому реакция, как правило, быстрая (хотя, конечно, уровень экспертизы разных команд разнится).
Стоимость и лицензирование
Ранее VMware имела понятную, хоть и недешёвую модель лицензирования (по процессорам, +опции за функции). После покупки Broadcom стоимость выросла в разы, а бессрочные лицензии отменены – только подписка. Это сделало VMware финансово тяжелее для многих. Отечественные же продукты зачастую предлагают более гибкие условия: кто-то лицензирует по ядрам, кто-то по узлам, у кого-то подписка с поддержкой. Но в целом ценовой порог для легального использования ниже, чем у VMware (тем более, что последняя официально недоступна, а «серыми» схемами пользоваться рискованно). Некоторые российские решения и вовсе доступны в рамках господдержки по льготным программам для госучреждений. Таким образом, с точки зрения совокупной стоимости владения (TCO) переход на отечественную виртуализацию может быть выгоден (но может и не быть), особенно с учётом локальной техподдержки и отсутствия валютных рисков.
Подведём коротко плюсы и минусы российских платформ относительно VMware.
Плюсы отечественных решений:
Импортонезависимость и соответствие требованиям. Полное соблюдение требований законодательства РФ для госкомпаний и КИИ (реестр ПО, совместимость с ГОСТ, сертификация ФСТЭК у компонентов).
Локальная поддержка и доработка. Возможность напрямую взаимодействовать с разработчиком, получать кастомные улучшения под свои задачи и быстро исправлять проблемы в сотрудничестве (что практически невозможно с глобальным вендором).
Интеграция с отечественной экосистемой. Совместимость с российскими ОС (Astra, РЕД, ROSA), СУБД, средствами защиты (например, vGate) – упрощает внедрение единого импортозамещённого ландшафта.
Новые технологии под свои нужды. Реализация специфичных возможностей: работа без лицензий NVIDIA (FreeGRID), поддержка гостевых Windows без обращения к зарубежным серверам активации, отсутствие жёсткого вендорлока по железу (любое x86 подходит).
Стоимость и модель владения. Более низкая цена лицензий и поддержки по сравнению с VMware (особенно после удорожания VMware); оплата в рублях, отсутствие риска отключения при санкциях.
Минусы и вызовы:
Меньшая зрелость и удобство. Интерфейсы и процессы менее отточены – администрирование требует больше времени и знаний, некоторые задачи реализованы не так элегантно, больше ручной работы.
Ограниченная экосистема. Не все привычные внешние инструменты совместимы – придется пересматривать решения для бэкапа, мониторинга, а автоматизация требует дополнительных скриптов. Нет огромного сообщества интеграторов по всему миру, как у VMware.
Риски масштабируемости и багов. На больших нагрузках или в сложных сценариях могут всплывать проблемы, которые VMware уже давно решила. Требуется тщательное пилотирование и возможно компромиссы (уменьшить размер кластера, разделить на несколько и др.).
Обучение персонала. ИТ-специалистам, годами работавшим с VMware, нужно переучиваться. Нюансы каждой платформы свои, документация не всегда идеальна, на русском языке материалов меньше, чем англоязычных по VMware.
Отсутствие некоторых enterprise-фишек. Например, у VMware есть многолетние наработки по гибридному облаку, экосистема готовых решений в VMware Marketplace. Российским аналогам предстоит путь создания таких же богатых экосистем.
Таким образом, при функциональном паритете с VMware на бумаге, в практической эксплуатации российские продукты могут требовать больше усилий и доставлять больше проблем. Но этот разрыв постепенно сокращается по мере их развития и накопления опыта внедрений.
Выводы и перспективы импортозамещения VMware
За почти четыре года, прошедшие с ухода VMware, российская индустрия виртуализации совершила огромный рывок. Из десятков появившихся решений постепенно выделился костяк наиболее зрелых и универсальных продуктов, способных заменить VMware vSphere в корпоративных ИТ-инфраструктурах. Как показывают кейсы крупных организаций (банков, промышленных предприятий, госструктур), импортозамещение виртуализации в России – задача выполнимая, хотя и сопряжена с определёнными трудностями. Подводя итоги обзора, можно назвать наиболее перспективные платформы и технологии, на которые сегодня стоит обратить внимание ИТ-директорам:
SpaceVM + Space VDI (экоcистема Space) – комплексное решение от компании «ДАКОМ M», которое отличается максимальной полнотой функционала. SpaceVM обеспечивает производительную серверную виртуализацию с собственными технологиями (SDN, FreeGRID), а Space VDI дополняет её средствами виртуализации рабочих мест. Этот тандем особенно хорош для компаний, которым нужны все компоненты "как у VMware" под одним брендом – гипервизор, диспетчеры, клиенты, протоколы. Space активно набирает популярность: 1-е место в рейтингах, успешные внедрения, награды отрасли. Можно ожидать, что он станет одним из столпов корпоративной виртуализации РФ.
Basis Dynamix – продукт компании «Базис», ставший лидером технических рейтингов. Basis привлекает госзаказчиков и большие корпорации, ценящие интегрированный подход: платформа тесно сопряжена с отечественным оборудованием, ОС и имеет собственный центр разработки. Ее козыри – высокая производительность, гибкость (поддержка и классической, и HCI-схем) и готовность к кастомизации под клиента. Basis – хороший выбор для тех, кто строит полностью отечественный программно-аппаратный комплекс, и кому нужна платформа с длительной перспективой развития в России.
zVirt (Orion soft) – одна из самых распространённых на практике платформ, обладающая богатым набором функций и сильным акцентом на безопасность. За счет происхождения от oVirt, zVirt знаком многим по архитектуре, а доработки Orion soft сделали его удобнее и безопаснее (SDN, микросегментация, интеграция с vGate). Крупнейшая инсталляционная база говорит о доверии рынка. Хотя у zVirt есть ограничения по масштабированию, для средних размеров (десятки узлов) он отлично справляется. Это надежный вариант для постепенной миграции с VMware в тех организациях, где ценят проверенные решения и требуются сертификаты ФСТЭК по безопасности.
Red Виртуализация – решение от РЕД СОФТ, важное для госсектора и компаний с экосистемой РЕД ОС. Его выбрал, к примеру, Россельхозбанк для одной из крупнейших миграций в финансовом секторе. Продукт относительно консервативный (форк известного проекта), что можно считать плюсом – меньше сюрпризов, более понятный функционал. Red Virtualization перспективна там, где нужна максимальная совместимость с отечественным ПО (ПО РЕД, СУБД РЕД и пр.) и официальная поддержка на уровне регуляторов.
vStack HCP – хотя и более нишевое решение, но весьма перспективное для тех, кому нужна простота HCI и высочайшая производительность. Отсутствие зависимости от громоздких компонентов (ни Linux, ни Windows – гипервизор на FreeBSD) дает vStack определенные преимущества в легковесности. Его стоит рассматривать в том числе для задач на периферии, в распределенных офисах, где нужна автономная работа без сложной поддержки, или для быстрорастущих облачных сервисов, где горизонтальное масштабирование – ключевой фактор.
HostVM VDI / Veil / Termidesk – в сфере VDI помимо Space VDI, внимания заслуживают и другие разработки. HostVM VDI – как универсальный брокер с множеством протоколов – может подойти интеграторам, строящим сервис VDI для разных платформ. Veil VDI и Termidesk – пока чуть менее известны на рынке, но имеют интересные технологии (например, Termidesk с собственным кодеком TERA). Для компаний, уже использующих решения этих вендоров, логично присмотреться к их VDI для совместимости.
В заключение, можно уверенно сказать: российские продукты виртуализации достигли уровня, при котором ими можно заменить VMware vSphere во многих сценариях. Да, переход потребует усилий – от тестирования до обучения персонала, – но выгоды в виде независимости от внешних факторов, соответствия требованиям законодательства и поддержки со стороны локальных вендоров зачастую перевешивают временные сложности. Российские разработчики продемонстрировали способность быстро закрыть функциональные пробелы и даже внедрить новые инновации под нужды рынка. В ближайшие годы можно ожидать дальнейшего роста качества этих продуктов: уже сейчас виртуализация перестает быть "экзотикой" и становится обыденным, надёжным инструментом в руках отечественных ИТ-специалистов. А значит, корпоративный сектор России получает реальную альтернативу VMware – собственный технологический базис для развития ИТ-инфраструктуры.
В этой части статей о технологии NVMe Memory Tiering (см. прошлые части тут, тут, тут и тут) мы предоставим некоторую информацию о различиях при включении Memory Tiering в разных сценариях. Хотя основной процесс остаётся тем же, есть моменты, которые могут потребовать дополнительного внимания и планирования, чтобы сэкономить время и усилия. Когда мы говорим о сценариях greenfield, мы имеем в виду совершенно новые развертывания VMware Cloud Foundation (VCF), включая новое оборудование и новую конфигурацию для всего стека. Сценарии brownfield будут охватывать настройку Memory Tiering в существующей среде VCF. Наконец, мы рассмотрим и лабораторные сценарии, поскольку встречаются неоднозначные утверждения о том, что это не поддерживается, но мы рассмотрим это в конце данной статьи.
Greenfield-развертывания
Давайте начнём с процесса конфигурации сред greenfield. Ранее мы рассказали о том, как VMware vSAN и Memory Tiering совместимы и могут сосуществовать в одном и том же кластере. Мы также обращали внимание на кое-что важное, о чём вам следует помнить во время greenfield-развертываний VCF. Начиная с VCF 9.0, включение Memory Tiering — это операция «Day 2», то есть сначала вы настраиваете VCF, а затем можете настроить Memory Tiering, но в ходе рабочего процесса развертывания VCF вы заметите, что опции для включения Memory Tiering (пока) нет, зато можно включить vSAN. То, как вы поступите с вашим NVMe-устройством, выделенным для Memory Tiering, будет определять шаги, необходимые для того, чтобы это устройство было представлено для его конфигурации.
Если все NVMe-устройства и для vSAN, и для Memory Tiering присутствуют во время развертывания VCF, есть вероятность, что vSAN может автоматически занять все накопители (включая NVMe-устройство, которое вы выделили для Memory Tiering). В этом случае вам пришлось бы удалить накопитель из vSAN после конфигурации, стереть разделы, а затем начать настройку Memory Tiering. Этот шаг был рассмотрен тут.
Другой подход — извлечь или не устанавливать устройство Memory Tiering в сервер и добавить его обратно в сервер после развертывания VCF. Таким образом вы не будете рисковать тем, что vSAN автоматически займет NVMe для Memory Tiering. Хотя это и не является серьёзным препятствием, всё равно полезно знать, что произойдёт и почему, чтобы вы могли быстро выделить ресурсы, необходимые для настройки Memory Tiering.
Brownfield-развертывания
Сценарии brownfield немного проще, так как VVF/VCF уже настроен; однако vSAN мог быть включён или ещё нет.
Если vSAN не включён, вам нужно будет отключить функцию auto-claim, пройти через конфигурацию vSAN и вручную выбрать ваши устройства (кроме NVMe-устройств для Memory Tiering). Всё выполняется в интерфейсе UI и по процедуре, которая используется уже много лет. Это гарантирует, что NVMe-устройство Memory Tiering будет доступно для настройки. Подробный процесс задокументирован в TechDocs.
Если vSAN уже включён, мы предполагаем, что NVMe-устройство для Memory Tiering только что было приобретено и готово к установке. Значит, всё, что нам нужно сделать, — добавить его в хост и убедиться, что оно корректно отображается как NVMe-устройство и что на нём нет существующих разделов. Это, вероятно, самый простой сценарий и самый распространённый.
Развертывания в тестовой среде
Теперь давайте поговорим о давно ожидаемом лабораторном сценарии. Для лаборатории типа bare metal, где сервер ESX одноуровневый и нет вложенных сред, применяются те же принципы greenfield и brownfield. Что касается вложенной (nested) виртуализации, многие говорят о том, что вложенный Memory Tiering не поддерживается. Ну, это и так, и не так.
Когда мы говорим о вложенных средах, мы имеем в виду два уровня ESX. Внешний уровень — это ESX, установленный на оборудовании (обычная настройка), а внутренний уровень ESX состоит из виртуальных машин, запускающих ESX и выступающих в роли как бы физических хостов. Memory Tiering МОЖЕТ быть включён на внутреннем уровне (вложенном), и все параметры конфигурации работают нормально. Мы делаем следующее: берём datastore и создаём виртуальный Hard Disk типа NVMe, чтобы представить его виртуальной машине, которая выступает в роли вложенного хоста. Хотя мы видим NVMe-устройство на вложенном хосте и можем настроить Memory Tiering, базовое устройство хранения состоит из устройств, формирующих выбранный datastore. Вы можете настроить Memory Tiering, и вложенные хосты смогут видеть hot и active pages, но не ожидайте какого-либо уровня производительности, учитывая, что компоненты базового хранилища построены на традиционных накопителях. Работает ли это? ДА, но только в лабораторных средах.
Тестирование в лабораторной среде очень полезно: оно помогает вам пройти шаги конфигурации и понять, как работает настройка и какие расширенные параметры можно задать. Это отличный вариант использования для подготовки (практики) к развертыванию в производственной среде или даже просто для знакомства с функцией, например, для целей сдачи сертификационного экзамена.
А как насчёт внешнего уровня? Ну, это как раз то, что не поддерживается в VCF 9.0, поскольку внешний уровень ESX не имеет видимости внутреннего уровня и не может видеть активность памяти ВМ, по сути пытаясь «прозреть» сквозь вложенный уровень до виртуальной машины (inception). Это и есть главное отличие (не вдаваясь слишком глубоко в технические детали).
Так что если вам интересно протестировать Memory Tiering, а всё, что у вас есть — это вложенная среда, вы можете настроить Memory Tiering и любые расширенные параметры. Интересно наблюдать, как несколько шагов настройки могут добавить хостам 100% дополнительной памяти.
В ранних статьях мы упоминали, что вы можете настраивать разделы NVMe с помощью команд ESXCLI, PowerCLI и даже скриптов. В более поздних публикациях мы говорили о том, что опубликуем скрипт для настройки разделов, который мы приводим ниже, но с оговоркой и прямым предупреждением: вы можете запускать скрипт на свой страх и риск, и он может не работать в вашей среде в зависимости от вашей конфигурации.
Рассматривайте этот скрипт только как пример того, как это можно автоматизировать, а не как поддерживаемое решение автоматизации. Кроме того, скрипт не стирает разделы за вас, поэтому убедитесь, что вы сделали это до запуска скрипта. Как всегда, сначала протестируйте.
Есть некоторые переменные, которые вам нужно изменить, чтобы он работал в вашей среде:
$vCenter = “ваш vCenter FQDN или IP” (строка 27)
$clusterName = “имя вашего кластера” (строка 28)
Вот и сам скрипт:
function Update-NvmeMemoryTier {
param (
[Parameter(Mandatory=$true)]
[VMware.VimAutomation.ViCore.Impl.V1.Inventory.VMHostImpl]$VMHost,
[Parameter(Mandatory=$true)]
[string]$DiskPath
)
try {
# Verify ESXCLI connection
$esxcli = Get-EsxCli -VMHost $VMHost -V2
# Note: Verify the correct ESXCLI command for NVMe memory tiering; this is a placeholder
# Replace with the actual command or API if available
$esxcli.system.tierdevice.create.Invoke(@{ nvmedevice = $DiskPath }) # Hypothetical command
Write-Output "NVMe Memory Tier created successfully on host $($VMHost.Name) with disk $DiskPath"
return $true
}
catch {
Write-Warning "Failed to create NVMe Memory Tier on host $($VMHost.Name) with disk $DiskPath. Error: $_"
return $false
}
}
# Securely prompt for credentials
$credential = Get-Credential -Message "Enter vCenter credentials"
$vCenter = "vcenter FQDN"
$clusterName = "cluster name"
try {
# Connect to vCenter
Connect-VIServer -Server $vCenter -Credential $credential -WarningAction SilentlyContinue
Write-Output "Connected to vCenter Server successfully."
# Get cluster and hosts
$cluster = Get-Cluster -Name $clusterName -ErrorAction Stop
$vmHosts = Get-VMHost -Location $cluster -ErrorAction Stop
foreach ($vmHost in $vmHosts) {
Write-Output "Fetching disks for host: $($vmHost.Name)"
$disks = @($vmHost | Get-ScsiLun -LunType disk |
Where-Object { $_.Model -like "*NVMe*" } | # Filter for NVMe disks
Select-Object CanonicalName, Vendor, Model, MultipathPolicy,
@{N='CapacityGB';E={[math]::Round($_.CapacityMB/1024,2)}} |
Sort-Object CanonicalName) # Explicit sorting
if (-not $disks) {
Write-Warning "No NVMe disks found on host $($vmHost.Name)"
continue
}
# Build disk selection table
$diskWithIndex = @()
$ctr = 1
foreach ($disk in $disks) {
$diskWithIndex += [PSCustomObject]@{
Index = $ctr
CanonicalName = $disk.CanonicalName
Vendor = $disk.Vendor
Model = $disk.Model
MultipathPolicy = $disk.MultipathPolicy
CapacityGB = $disk.CapacityGB
}
$ctr++
}
# Display disk selection table
$diskWithIndex | Format-Table -AutoSize | Out-String | Write-Output
# Get user input with validation
$maxRetries = 3
$retryCount = 0
do {
$diskChoice = Read-Host -Prompt "Select disk for NVMe Memory Tier (1 to $($disks.Count))"
if ($diskChoice -match '^\d+$' -and $diskChoice -ge 1 -and $diskChoice -le $disks.Count) {
break
}
Write-Warning "Invalid input. Enter a number between 1 and $($disks.Count)."
$retryCount++
} while ($retryCount -lt $maxRetries)
if ($retryCount -ge $maxRetries) {
Write-Warning "Maximum retries exceeded. Skipping host $($vmHost.Name)."
continue
}
# Get selected disk
$selectedDisk = $disks[$diskChoice - 1]
$devicePath = "/vmfs/devices/disks/$($selectedDisk.CanonicalName)"
# Confirm action
Write-Output "Selected disk: $($selectedDisk.CanonicalName) on host $($vmHost.Name)"
$confirm = Read-Host -Prompt "Confirm NVMe Memory Tier configuration? This may erase data (Y/N)"
if ($confirm -ne 'Y') {
Write-Output "Configuration cancelled for host $($vmHost.Name)."
continue
}
# Configure NVMe Memory Tier
$result = Update-NvmeMemoryTier -VMHost $vmHost -DiskPath $devicePath
if ($result) {
Write-Output "Successfully configured NVMe Memory Tier on host $($vmHost.Name)."
} else {
Write-Warning "Failed to configure NVMe Memory Tier on host $($vmHost.Name)."
}
}
}
catch {
Write-Warning "An error occurred: $_"
}
finally {
# Disconnect from vCenter
Disconnect-VIServer -Server $vCenter -Confirm:$false -ErrorAction SilentlyContinue
Write-Output "Disconnected from vCenter Server."
}
RSS
