В данной статье описывается, как развернуть дома полноценную лабораторию VMware Cloud Foundation (VCF) на одном физическом компьютере. Мы рассмотрим выбор оптимального оборудования, поэтапную установку всех компонентов VCF (включая ESXi, vCenter, NSX, vSAN и SDDC Manager), разберем архитектуру и взаимодействие компонентов, поделимся лучшими практиками...

Иногда у администратора VMware vSphere возникает необходимость отключить физический интерфейс на хосте VMware ESXi, чтобы сделать некоторые операции или протестировать различные сценарии.

Например:

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

Итак, чтобы отключить vmnic, нужно зайти на ESXi по SSH и выполнить там следующую команду, чтобы вывести список сетевых адаптеров:

esxcli network nic list

Далее отключаем vmnic командой (X - это номер в имени адаптера):

esxcli network nic down -n vmnicX

В разделе физических адаптеров vSphere Client мы увидим следующую картину (адаптер в статусе "down"):

Чтобы вернуть vmnic в исходное состояние, просто выполняем команду:

esxcli network nic up -n vmnicX

Источник.

В январе 2025 года компания VMware опубликовала технический документ под названием «Performance Tuning for Latency-Sensitive Workloads: VMware vSphere 8». Этот документ предоставляет рекомендации по оптимизации производительности для рабочих нагрузок, критичных к задержкам, в среде VMware vSphere 8.

Документ охватывает различные аспекты конфигурации, включая требования к базовой инфраструктуре, настройки хоста, виртуальных машин, сетевые аспекты, а также оптимизацию операционной системы и приложений. В разделе «Host considerations» обсуждаются такие темы, как изменение настроек BIOS на физическом сервере, отключение EVC, управление vMotion и DRS, а также настройка продвинутых параметров, таких как отключение action affinity и открытие кольцевых буферов.

В разделе «VM considerations» рассматриваются рекомендации по оптимальному выделению ресурсов виртуальным машинам, использованию актуальных версий виртуального оборудования, настройке vTopology, отключению функции hot-add, активации параметра чувствительности к задержкам для каждой ВМ, а также использовании сетевого адаптера VMXNET3. Кроме того, обсуждается балансировка потоков передачи и приема данных, привязка потоков передачи к определенным ядрам, ассоциация ВМ с конкретными NUMA-нодами и использование технологий SR-IOV или DirectPath I/O при необходимости.

Раздел о сетевых настройках акцентирует внимание на использовании улучшенного пути передачи данных для NFV-нагрузок и разгрузке сервисов vSphere на DPU (Data Processing Units), также известных как SmartNICs.

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

В статье ниже рассказано о том, как можно использовать API платформы VMware Cloud Foundation (VCF) для расширения кластера между стойками без расширения уровня L2 в физической сети. Расширение кластера на хосты в разных стойках служит двум ключевым целям: увеличению емкости вычислительных мощностей и ...

Что означает "реализовать Private AI" для одного или нескольких сценариев использования на платформе VMware Cloud Foundation (VCF)?

VMware недавно представила примеры того, что значит "реализовать Private AI". Эти сценарии использования уже внедрены внутри компании Broadcom в рамках частного применения. Они доказали свою ценность для бизнеса Broadcom, что дает вам больше уверенности в том, что аналогичные сценарии могут быть реализованы и в вашей инсталляции VCF на собственных серверах.

Описанные ниже сценарии были выбраны, чтобы показать, как происходит увеличение эффективности бизнеса за счет:

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

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

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

Вот пример пользовательского интерфейса простого стартового чат-бота из NVIDIA AI Enterprise Suite, входящего в состав продукта. Существует множество различных примеров чат-ботов для начинающих в этой области. Вы можете ознакомиться с техническим описанием от NVIDIA для чат-ботов здесь.

Набор шагов для изучения работы этого стартового чат-бота в качестве учебного упражнения приведен в техническом обзоре VMware Private Foundation с NVIDIA.

Современные чат-боты с поддержкой AI проектируются с использованием векторной базы данных, которая содержит приватные данные вашей компании. Эти данные разделяются на блоки, индексируются и загружаются в векторную базу данных офлайн, без связи с основной моделью чат-бота. Когда пользователь задает вопрос в приложении чат-бота, сначала извлекаются все релевантные данные из векторной базы данных. Затем эти данные, вместе с исходным запросом, передаются в большую языковую модель (LLM) для обработки. LLM обрабатывает и суммирует извлеченные данные вместе с исходным запросом, представляя их пользователю в удобном для восприятия виде. Этот подход к проектированию называется Retrieval Augmented Generation (RAG).

RAG стал общепринятым способом структурирования приложений Generative AI, чтобы дополнить знания LLM приватными данными вашей компании, что позволяет предоставлять более точные ответы. Обновление приватных данных теперь сводится к обновлению базы данных, что гораздо проще, чем повторное обучение или настройка модели.

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

В Broadcom специалисты по данным разработали производственный чат-бот для внутреннего использования под названием vAQA (или “VMware’s Automated Question Answering Service”). Этот чат-бот обладает мощными функциями для интерактивного чата или поиска данных, собранных как внутри компании, так и извне.

На панели навигации справа есть возможность фильтровать источники данных. Пример простого использования системы демонстрирует её способность отвечать на вопросы на естественном языке. Например, сотрудник спросил чат-бота о блогах с информацией о виртуальных графических процессорах (vGPU) на VMware Cloud Foundation, указав, чтобы он предоставил URL-адреса этих статей. Система ответила списком релевантных URL-адресов и, что важно, указала свои источники.

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

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

Как VMware Private AI Foundation с NVIDIA позволяет создать чат-бота для работы с приватными данными

На диаграмме ниже обобщены различные части архитектуры VMware Private AI Foundation с NVIDIA. Более подробную информацию можно найти в документации VMware Private AI Foundation with NVIDIA – a Technical Overview, а также на сайте документации NVIDIA AI Enterprise.

Для реализации приложения чат-бота можно использовать несколько компонентов из представленной выше архитектуры для проектирования и доставки рабочего приложения (начиная с синего уровня от VMware).

• Система управления моделями (Model Governance) используется для тестирования, оценки и хранения предварительно обученных больших языковых моделей, которые считаются безопасными и подходящими для бизнес-использования. Эти модели сохраняются в библиотеке (называемой "галерея моделей", основанной на Harbor). Процесс оценки моделей уникален для каждой компании.
• Функционал векторной базы данных применяется через развертывание этой базы данных с помощью дружественного интерфейса с использованием автоматизации VCF. Затем база данных заполняется очищенными и организованными приватными данными компании.
• Инструменты "автоматизации самообслуживания", основанные на автоматизации VCF, используются для предоставления наборов виртуальных машин глубокого обучения для тестирования моделей, а затем для создания кластеров Kubernetes для развертывания и масштабирования приложения.
• Средства мониторинга GPU в VCF Operations используются для оценки влияния приложения на производительность GPU и системы в целом.

Вы можете получить лучшие практики и технические советы от авторов VMware о развертывании собственного чат-бота, основанного на RAG, прочитав статью VMware RAG Starter Pack вместе с упомянутыми техническими документами.

Сценарий использования 2: ассистента кода для помощи инженерам в процессе разработки

Предоставление ассистента разработки кода для ускорения процессов разработки программного обеспечения является одним из наиболее значимых сценариев для любой организации, занимающейся разработкой ПО. Это включает подсказки по коду, автозаполнение, рефакторинг, обзоры кода и различные интеграции с IDE.

Инженеры и специалисты по данным VMware изучили множество инструментов, управляемых AI, в области ассистентов кода и, после тщательного анализа, остановились на двух сторонних поставщиках: Codeium и Tabnine, которые интегрированы с VMware Private AI Foundation with NVIDIA. Ниже кратко описан первый из них.

Основная идея состоит в том, чтобы помочь разработчику в процессе написания кода, позволяя общаться с AI-"советником" без прерывания рабочего потока. Советник предлагает подсказки по коду прямо в редакторе, которые можно принять простым нажатием клавиши "Tab". По данным компании Codeium, более 44% нового кода, добавляемого клиентами, создается с использованием их инструментов. Для получения дополнительной информации о советнике можно ознакомиться с этой статьей.

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

Сторонний ассистент от Codeium разворачивается локально — либо в виртуальной машине с Docker, либо в кластере Kubernetes, созданном, например, с помощью службы vSphere Kubernetes Service (VKS). Код пользователя, независимо от того, написан он вручную или сгенерирован инструментом, не покидает компанию, что защищает интеллектуальную собственность. Целевой кластер Kubernetes создается с помощью инструмента автоматизации VCF и поддерживает работу с GPU благодаря функции VMware Private AI Foundation с NVIDIA — GPU Operator. Этот оператор устанавливает необходимые драйверы vGPU в поды, работающие на кластере Kubernetes, чтобы поддерживать функциональность виртуальных GPU. После этого функциональность Codeium разворачивается в Kubernetes с использованием Helm charts.

Инфраструктура Codeium включает серверы Inference Server, Personalization Server, а также аналитическую базу данных, как показано на рисунке ниже:

Вы можете получить больше информации об использовании Codeium с VMware Private AI Foundation с NVIDIA в этом кратком описании решения.

Ниже приведены простые примеры использования Codeium для генерации функции на Python на основе текстового описания.

Затем в Broadcom попросили ассистента кода написать и включить тестовые сценарии использования для ранее созданной функции.

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

Естественно, существует множество других сценариев, применимых к конкретным отраслям или горизонтальным задачам, поскольку вся область Private AI продолжает развиваться на рынке. Для получения дополнительной информации ознакомьтесь с документацией: Private AI Ready Infrastructure for VMware Cloud Foundation Validated Solution и VMware Private AI Foundation with NVIDIA Guide.

Для сценариев использования в финансовых услугах см. статью Private AI: Innovation in Financial Services Combined with Security and Compliance.

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

С выпуском VMware Cloud Foundation (VCF) 5.2 в июле 2024 года VMware представила инструмент VCF Import Tool — новый интерфейс командной строки (CLI), разработанный для упрощения перехода клиентов к частному облаку. Этот инструмент позволяет быстро расширить возможности управления инвентарем SDDC Manager, такие как управление сертификатами, паролями и жизненным циклом, на ваши существующие развертывания vSphere или vSphere с vSAN. Интеграция управления SDDC Manager с вашей текущей инфраструктурой проходит бесшовно, без влияния на работающие нагрузки, сервер vCenter, API vSphere или процессы управления.

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

Загрузка последних обновлений

Это обновление доступно в составе выпуска 5.2.1.1 для VCF 5.2.1. Чтобы загрузить обновление, войдите в портал Broadcom Software и в разделе «My Downloads» перейдите в «VMware Cloud Foundation», раскройте пункт «VMware Cloud Foundation 5.2» и выберите «5.2.1». Последняя версия инструмента VCF Import (5.2.1.1) доступна на вкладке «Drivers & Tools», как показано на изображении ниже.

Новые возможности VMware Cloud Foundation Import Tool

Возможность импорта кластеров vSphere с общими vSphere Distributed Switches (VDS)

До этого обновления инструмент VCF Import требовал, чтобы у каждого кластера был выделенный VDS. Это соответствовало рекомендуемой практике изоляции кластеров vSphere и избегания зависимости между ними. Однако многие клиенты предпочитают минимизировать количество VDS в своей среде и часто создают единый VDS, который используется несколькими кластерами. С последним обновлением добавлена поддержка как выделенных, так и общих конфигураций VDS. Это дает клиентам гибкость в выборе топологии развертывания VDS и упрощает импорт существующих рабочих нагрузок в Cloud Foundation.

Поддержка импорта кластеров с включенным LACP

Многие клиенты используют протокол управления агрегацией каналов (Link Aggregation Control Protocol, LACP) на своих физических коммутаторах для объединения каналов. Ранее использование LACP с VCF не поддерживалось. Это обновление добавляет поддержку LACP как для преобразованных, так и для импортированных доменов. Теперь использование LACP больше не является препятствием для переноса инфраструктуры vSphere в Cloud Foundation.

Импорт сред vSphere с использованием смешанных конфигураций vLCM Images и Baselines

При развертывании кластеров vSphere VCF предоставляет возможность выбора между использованием образов vSphere Lifecycle Manager (vLCM) и базовых конфигураций (Baselines). Образы vLCM представляют собой современный подход к обновлению программного обеспечения хостов vSphere, основанный на модели желаемого состояния. Базовые конфигурации следуют традиционному подходу, включающему создание базовых профилей и их привязку к кластерам.

Во время перехода клиентов от традиционного подхода с базовыми конфигурациями к новому подходу с образами vLCM многие используют смешанную конфигурацию, где одни кластеры применяют образы, а другие — базовые профили. Ранее VCF требовал, чтобы все кластеры в инвентаре vCenter использовали один тип vLCM. Последнее обновление устраняет это ограничение, добавляя поддержку смешанных сред, где одни кластеры используют vLCM Images, а другие — vLCM Baselines. Это упрощает переход клиентов на VCF, позволяя импортировать существующую инфраструктуру в частное облако Cloud Foundation без необходимости вносить изменения или модификации.

Ослабление ограничений для vSphere Standard Switches и автономных хостов

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

• Разрешение импорта сред vSphere с использованием стандартных коммутаторов vSphere Standard Switches.
• Поддержку сред vSphere с автономными хостами в инвентаре vCenter.
• Поддержку одноузловых кластеров.

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

Интересный пост, касающийся использования виртуальных хранилищ NFS (в формате Virtual Appliance) на платформе vSphere и их производительности, опубликовал Marco Baaijen в своем блоге. До недавнего времени он использовал центральное хранилище Synology на основе NFSv3 и две локально подключенные PCI флэш-карты. Однако из-за ограничений драйверов он был вынужден использовать ESXi 6.7 на одном физическом хосте (HP DL380 Gen9). Желание перейти на vSphere 8.0 U3 для изучения mac-learning привело тому, что он больше не мог использовать флэш-накопители в качестве локального хранилища для размещения вложенных виртуальных машин. Поэтому Марко решил использовать эти флэш-накопители на отдельном физическом хосте на базе ESXi 6.7 (HP DL380 G7).

Теперь у нас есть хост ESXi 8 и и хост с версией ESXi 6.7, которые поддерживают работу с этими флэш-картами. Кроме того, мы будем использовать 10-гигабитные сетевые карты (NIC) на обоих хостах, подключив порты напрямую. Марко начал искать бесплатное, удобное и функциональное виртуальное NAS-решение. Рассматривал Unraid (не бесплатный), TrueNAS (нестабильный), OpenFiler/XigmaNAS (не тестировался) и в итоге остановился на OpenMediaVault (с некоторыми плагинами).

И вот тут начинается самое интересное. Как максимально эффективно использовать доступное физическое и виртуальное оборудование? По его мнению, чтение и запись должны происходить одновременно на всех дисках, а трафик — распределяться по всем доступным каналам. Он решил использовать несколько паравиртуальных SCSI-контроллеров и настроить прямой доступ (pass-thru) к портам 10-гигабитных NIC. Всё доступное пространство флэш-накопителей представляется виртуальной машине как жесткий диск и назначается по круговому принципу на доступные SCSI-контроллеры.

В OpenMediaVault мы используем плагин Multiple-device для создания страйпа (striped volume) на всех доступных дисках.

На основе этого мы можем создать файловую систему и общую папку, которые в конечном итоге будут представлены как экспорт NFS (v3/v4.1). После тестирования стало очевидно, что XFS лучше всего подходит для виртуальных нагрузок. Для NFS Марко решил использовать опции async и no_subtree_check, чтобы немного увеличить скорость работы.

Теперь переходим к сетевой части, где автор стремился использовать оба 10-гигабитных порта сетевых карт (X-соединённых между физическими хостами). Для этого он настроил следующее в OpenMediaVault:

С этими настройками серверная часть NFS уже работает. Что касается клиентской стороны, Марко хотел использовать несколько сетевых карт (NIC) и порты vmkernel, желательно на выделенных сетевых стэках (Netstacks). Однако, начиная с ESXi 8.0, VMware решила отказаться от возможности направлять трафик NFS через выделенные сетевые стэки. Ранее для этого необходимо было создать новые стэки и настроить SunRPC для их использования. В ESXi 8.0+ команды SunRPC больше не работают, так как новая реализация проверяет использование только Default Netstack.

Таким образом, остаётся использовать возможности NFS 4.1 для работы с несколькими соединениями (parallel NFS) и выделения трафика для портов vmkernel. Но сначала давайте посмотрим на конфигурацию виртуального коммутатора на стороне NFS-клиента. Как показано на рисунке ниже, мы создали два раздельных пути, каждый из которых использует выделенный vmkernel-порт и собственный физический uplink-NIC.

Первое, что нужно проверить, — это подключение между адресами клиента и сервера. Существуют три способа сделать это: от простого до более детального.

[root@mgmt01:~] esxcli network ip interface list
---
vmk1
   Name: vmk1
   MAC Address: 00:50:56:68:4c:f3
   Enabled: true
   Portset: vSwitch1
   Portgroup: vmk1-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 134217815

vmk2
   Name: vmk2
   MAC Address: 00:50:56:6f:d0:15
   Enabled: true
   Portset: vSwitch2
   Portgroup: vmk2-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 167772315

[root@mgmt01:~] esxcli network ip netstack list defaultTcpipStack
   Key: defaultTcpipStack
   Name: defaultTcpipStack
   State: 4660

[root@mgmt01:~] ping 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.219 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.173 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.174 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.173/0.189/0.219 ms

[root@mgmt01:~] ping 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.155 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.187 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.161/0.187 ms

root@mgmt01:~] vmkping -I vmk1 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.981 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.183 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.435/0.981 ms

[root@mgmt01:~] vmkping -I vmk2 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.131 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.187 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.190 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.131/0.169/0.190 ms

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk1 -H 10.10.10.62
   Trace: 
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 139 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 180 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 148 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 10.10.10.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 139 us
         Round-trip Avg: 155 us
         Round-trip Max: 180 us

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk2 -H 172.16.0.62
   Trace: 
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 182 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 136 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 213 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 172.16.0.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 136 us
         Round-trip Avg: 177 us
         Round-trip Max: 213 us

С этими положительными результатами мы теперь можем подключить NFS-ресурс, используя несколько подключений на основе vmk, и убедиться, что всё прошло успешно.

[root@mgmt01:~] esxcli storage nfs41 add --connections=8 --host-vmknic=10.10.10.62:vmk1,172.16.0.62:vmk2 --share=/fio-folder --volume-name=fio

[root@mgmt01:~] esxcli storage nfs41 list
Volume Name  Host(s)                  Share        Vmknics    Accessible  Mounted  Connections  Read-Only  Security   isPE  Hardware Acceleration
-----------  -----------------------  -----------  ---------  ----------  -------  -----------  ---------  --------  -----  ---------------------
fio          10.10.10.62,172.16.0.62  /fio-folder  vmk1,vmk2        true     true            8      false  AUTH_SYS  false  Not Supported

[root@mgmt01:~] esxcli storage nfs41 param get -v all
Volume Name  MaxQueueDepth  MaxReadTransferSize  MaxWriteTransferSize  Vmknics    Connections
-----------  -------------  -------------------  --------------------  ---------  -----------
fio             4294967295               261120                261120  vmk1,vmk2            8

Наконец, мы проверяем, что оба подключения действительно используются, доступ к дискам осуществляется равномерно, а производительность соответствует ожиданиям (в данном тесте использовалась миграция одной виртуальной машины с помощью SvMotion). На стороне NAS-сервера Марко установил net-tools и iptraf-ng для создания приведённых ниже скриншотов с данными в реальном времени. Для анализа производительности флэш-дисков на физическом хосте использовался esxtop.

root@openNAS:~# netstat | grep nfs
tcp        0    128 172.16.0.62:nfs         172.16.0.60:623         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:617         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:616         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:621         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:613         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:620         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:610         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:611         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:615         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:619         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:609         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:614         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:618         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:622         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:624         ESTABLISHED
tcp        0      0 10.10.10.62:nfs         10.10.10.60:612         ESTABLISHED

По итогам тестирования NFS на ESXi 8 Марко делает следующие выводы:

• NFSv4.1 превосходит NFSv3 по производительности в 2 раза.
• XFS превосходит EXT4 по производительности в 3 раза (ZFS также был протестирован на TrueNAS и показал отличные результаты при последовательных операциях ввода-вывода).
• Клиент NFSv4.1 в ESXi 8.0+ не может быть привязан к выделенному/отдельному сетевому стэку (Netstack).
• Использование нескольких подключений NFSv4.1 на основе выделенных портов vmkernel работает очень эффективно.
• Виртуальные NAS-устройства демонстрируют хорошую производительность, но не все из них стабильны (проблемы с потерей NFS-томов, сообщения об ухудшении производительности NFS, увеличении задержек ввода-вывода).

Не все виртуальные машины на базе vSphere одинаковы, Вильям Лам написал интересный пост об обнаружении ВМ разного типа с помощью PowerCLI. Это особенно актуально с введением vSphere IaaS (ранее известного как vSphere Supervisor, vSphere with Tanzu или Project Pacific), который включает современный способ развертывания традиционных/классических виртуальных машин, а также новый тип виртуальной машины, основанный на контейнерах, известный как vSphere Pod VM.

vSphere Pod - это эквивалент Kubernetes pod в среде VMware Tanzu / vSphere IaaS. Это легковесная виртуальная машина, которая запускает один или несколько контейнеров на базе Linux. Каждый vSphere Pod точно настроен для работы с конкретной нагрузкой и имеет явно указанные reservations для ресурсов этой нагрузки. Он выделяет точное количество хранилища, памяти и процессорных ресурсов, необходимых для работы нагрузки внутри ВМ. vSphere Pods поддерживаются только в случаях, когда компонент Supervisor настроен с использованием NSX в качестве сетевого стека.

Недавно возник вопрос о том, как можно различать традиционные/классические виртуальные машины, созданные через пользовательский интерфейс или API vSphere, и виртуальные машины vSphere Pod средствами PowerCLI, в частности с использованием стандартной команды Get-VM.

Как видно на приведенном выше скриншоте, vSphere может создавать и управлять несколькими типами виртуальных машин, от традиционных/классических, которые мы все знаем последние два десятилетия, специализированных "Сервисных/Агентских" виртуальных машин, управляемых различными решениями VMware или сторонних разработчиков, и до новых виртуальных машин vSphere IaaS и виртуальных машин рабочих нагрузок контейнеров vSphere Pod (которые можно назвать Supervisor VM и Supervisor Pod VM).

Хотя команда Get-VM не различает эти типы виртуальных машин, существует несколько свойств, которые можно использовать в vSphere API для различения этих типов виртуальных машин. Ниже приведен фрагмент кода PowerCLI, который Вильям написал для того, чтобы различать типы виртуальных машин, что может быть полезно для автоматизации и/или отчетности.

$vms = Get-Vm

$results = @()
foreach ($vm in $vms) {
    if($vm.GuestId -eq "crxPod1Guest" -or $vm.GuestId -eq "crxSys1Guest") {
        $vmType = "Supervisor Pod VM"
    } elseif($vm.ExtensionData.Config.ManagedBy -ne $null) {
        switch($vm.ExtensionData.Config.ManagedBy.ExtensionKey) {
            "com.vmware.vim.eam" {$vmType = "EAM Managed VM"}
            "com.vmware.vcenter.wcp" {$vmType = "Supervisor VM"}
            "default" {$vmType = "Other 2nd/3rd Party Managed Classic VM"}
        }
    } else {
        $vmType = "Classic VM"
    }

    $tmp = [pscustomobject] @{
        Name = $vm.Name
        Type = $vmType
    }
    $results+=$tmp
}

$results | FT | Sort-Object -Property Types

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

VMware выпустила новое руководство «Защита и восстановление критически важных приложений в гибридном облаке VMware с помощью VMware Live Site Recovery».

Документ подробно описывает, как предприятия могут использовать VMware Live Site Recovery для автоматизации и упрощения планов обеспечения непрерывности бизнеса и восстановления после катастроф (BCDR) для критически важных приложений, таких как контроллеры домена Windows Active Directory и Microsoft SQL Server.

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

VMware Live Site Recovery предлагает унифицированное управление возможностями восстановления после катастроф и защиты от программ-вымогателей через облачный интерфейс, обеспечивая защиту VMware vSphere виртуальных машин путем их репликации в облачную файловую систему с возможностью быстрого восстановления при необходимости.

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

Windows 11 предъявляет строгие требования к аппаратному обеспечению, включая наличие устройства Trusted Platform Module (TPM) версии 2.0. Для запуска Windows 11 в виртуальной среде VMware vSphere необходимо использовать виртуальный TPM-модуль (vTPM).

В целом, установка Windows 11 ничем не отличается от установки других ОС в VMware vSphere или Workstation:

Настройка vSphere для поддержки Windows 11

Для добавления vTPM в виртуальные машины требуется настройка провайдера ключей (Key Provider). Если вы видите предупреждение, приведенное ниже, это означает, что провайдер ключей не настроен:

Microsoft Windows 11 (64-bit) requires a Virtual TPM device, which cannot be added to this virtual machine because the Sphere environment is not configured with a key provider.

На платформе vSphere в качестве провайдера ключей может быть встроенный Native Key Provider или сторонний провайдер ключей. Native Key Provider поддерживается, начиная с версии vSphere 7 Update 2. Более подробная информация о его настройке приведена тут.

Основные шаги:

1. Настройте Native Key Provider через vSphere Client, если необходимо.
2. Шифрование файлов ВМ: файлы домашней директории ВМ (память, swap, NVRAM) будут зашифрованы автоматически при использовании vTPM. Полное шифрование диска не требуется.
3. Подключение vTPM: добавьте виртуальный TPM через мастер создания ВМ (если он отсутствует) или обновите существующую ВМ.

Установка Windows 11 в виртуальной машине

Установка на vSphere 8:

1. Создайте новую виртуальную машину с совместимостью ESXi 8.0 и выше (hardware version 20).
2. Выберите Microsoft Windows 11 (64-bit) в качестве версии ОС.
3. Если отображается ошибка о необходимости настройки Key Provider, выполните настройку согласно рекомендациям выше.
4. Завершите мастер создания ВМ и установите Windows 11 как обычно.

Установка на vSphere 7:

1. Создайте новую виртуальную машину с совместимостью ESXi 6.7 U2 и выше (hardware version 15).
2. Выберите Microsoft Windows 10 (64-bit) в качестве версии ОС (Windows 11 в списке отсутствует).
3. Вручную добавьте vTPM в разделе Customize Hardware.

4. В разделе VM Options установите параметры Encrypted vMotion и Encrypted FT в значение Required (это временная мера для поддержки Windows 11).

5. Завершите мастер создания ВМ.

Помните, что для виртуальных дисков рекомендуется использовать контроллер VMware Paravirtual SCSI (PVSCSI) в целях оптимизации производительности.

Клонирование и шаблоны виртуальных машин с vTPM

• Клонирование ВМ

Если вы удалите или замените устройство vTPM на виртуальной машине с Windows 11, используя функции, такие как Windows BitLocker или Windows Hello, эти функции перестанут работать, и вы можете потерять доступ к операционной системе Windows или данным, если у вас нет соответствующих вариантов восстановления.

При клонировании ВМ с vTPM с помощью vSphere Client устройство и его секреты копируются. Для соблюдения лучших практик используйте новую функцию TPM Provision Policy в vSphere 8, чтобы автоматически заменять vTPM при клонировании.

Политика TPM Provision Policy появилась в последней мажорной версии платформы - vSphere 8. Устройства vTPM могут автоматически заменяться во время операций клонирования или развёртывания. Это позволяет соблюдать лучшие практики, при которых каждая виртуальная машина содержит уникальное устройство TPM, и улучшает поддержку массового развёртывания Windows 11 в больших инсталляциях. Версия vSphere 8.0 также включает расширенную настройку vpxd.clone.tpmProvisionPolicy, которая задаёт поведение по умолчанию для клонирования, при котором устройства vTPM заменяются.

• Шаблоны ВМ

1. На vSphere 8 при развёртывании из шаблона также можно настроить копирование или замену vTPM.
2. На vSphere 7 настройка vTPM выполняется вручную в процессе развёртывания из шаблона.
3. Для шаблонов в Content Library используйте формат VMTX. Формат OVF/OVA не поддерживает vTPM.

Миграция виртуальных машин Windows 11

1. Миграция ВМ с vTPM выполняется с использованием шифрования vMotion.
2. Для миграции между экземплярами vCenter требуется синхронизация Key Provider.
3. Настройте резервное копирование и восстановление Key Derivation Key (KDK) для Native Key Provider. Подробнее об этом тут:

• Back up a vSphere Native Key Provider
• Restore a vSphere Native Key Provider

Использование WinPE для создания шаблонов Windows 11

ВМ с vTPM не поддерживают формат OVF/OVA. Для создания шаблона можно использовать Windows Preinstallation Environment (WinPE):

1. Создайте ВМ без vTPM.
2. Сохраните её как шаблон в формате OVF/OVA.
3. После развёртывания добавьте уникальный vTPM для каждой ВМ.

Известные проблемы

1. Отсутствие опции Windows 11 при создании ВМ (KB 85665).
2. Ошибка добавления vTPM (KB 85974).
3. Проблемы с резервным копированием Native Key Provider через IP (KB 84068).

Сброс устройства TPM в Windows 11

Вы можете очистить ключи, связанные с устройством TPM, непосредственно изнутри Windows 11. Очистка TPM приведет к утрате всех созданных ключей, связанных с этим TPM, а также данных, защищённых этими ключами, таких как виртуальная смарт-карта или PIN-код для входа. При этом существующее устройство vTPM на виртуальной машине сохраняется. Убедитесь, что у вас есть резервная копия и метод восстановления любых данных, защищённых или зашифрованных с использованием TPM. Об этом написано у Microsoft вот тут.

Продолжаем рассказывать о технологии ярусной памяти Memory Tiering, которая появилась в VMware vSphere 8 Update 3 (пока в статусе Tech Preview). Вильям Лам написал об интересной возможности использования одного устройства как для NVMe Tiering, так и для датасторов VMFS на платформе VMware vSphere.

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

Оказывается, можно использовать одно устройство NVMe для NVMe Tiering!

Для владельцев систем малого форм-фактора, таких как ASUS NUC, с ограниченным количеством NVMe-устройств, есть такой вариант: вы можете запустить ESXi с USB-устройства, сохранив возможность использовать локальный VMFS-датастор и NVMe Tiering. Таким образом, у вас даже останется свободный слот или два для vSAN OSA или ESA!

Важно: Это решение не поддерживается официально со стороны VMware. Используйте его на свой страх и риск.

Шаг 1 - Убедитесь, что у вас есть пустое устройство NVMe, так как нельзя использовать устройство с существующими разделами. Для идентификации и получения имени SSD-устройства используйте команду vdq -q.

Шаг 2 – Скачайте скрипт calculateSharedNVMeTeiringAndVMFSPartitions.sh на ваш хост ESXi и укажите значения для трёх необходимых переменных:

• SSD_DEVICE – имя NVMe-устройства, полученное на шаге 1.
• NVME_TIERING_SIZE_IN_GB – объём хранилища (в гигабайтах), который вы хотите выделить для NVMe Tiering.
• VMFS_DATASTORE_NAME – имя VMFS-датастора, который будет создан на NVMe-устройстве.

Убедитесь, что скрипт имеет права на выполнение, выполнив команду:

Затем запустите его, как показано на скриншоте ниже:

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

Пример выполнения сгенерированных команд для конкретной настройки: есть NVMe-устройство объёмом 1 ТБ (913,15 ГБ), из которого выделяется 256 ГБ для NVMe Tiering, а оставшееся пространство будет использовано для VMFS-датастора.

С помощью клиента ESXi Host Client мы можем увидеть два раздела, которые мы только что создали:

Шаг 3 – Включите функцию NVMe Tiering, если она еще не активирована, выполнив следующую команду ESXCLI:

Шаг 4 – Настройте желаемый процент использования NVMe Tiering (от 25 до 400), исходя из конфигурации вашей физической оперативной памяти (DRAM), выполнив следующую команду:

Шаг 5 – Наконец, перезагрузите хост ESXi, чтобы настройки NVMe Tiering вступили в силу. После перезагрузки ваш хост ESXi будет поддерживать использование одного NVMe-устройства как для NVMe Tiering, так и для локального VMFS-датастора, готового для размещения виртуальных машин.

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

В последнее время Вильям получает множество запросов как изнутри VMware, так и извне, по поводу рекомендаций по оборудованию для создания нового или обновления существующего домашнего лабораторного/тестового окружения с целью развертывания полноценного решения VMware Cloud Foundation (VCF). Обычно он получает не менее шести запросов в неделю по теме VMware Homelabs, но сейчас их количество возросло. Возможно, это связано с недавними распродажами в США на Black Friday и Cyber Monday, а возможно, некоторые уже готовятся к переезду на VCF 9.

В любом случае, он обычно направляет пользователей к своему проекту VMware Community Homelab, основанному на коллективной работе, где участники могут делиться своими списками оборудования (bill of materials, BOM), совокупными затратами на оборудование и решениями VMware, которые они используют в полученной среде.

Проект VMware Community Homelab существует уже несколько лет и помог множеству пользователей. Однако большинство предоставленных конфигураций в основном охватывают лишь часть портфолио VMware, и только небольшое количество из них включает VCF. Более того, некоторые из этих конфигураций устарели на несколько лет.

Внутри компании уже несколько человек поделились более актуальными списками оборудования (BOM) для создания среды, способной запускать последнюю версию VCF 5.x. Также Вильям нашел несколько подобных решений вне VMware. Поэтому он решил, что было бы полезно и своевременно собрать их аппаратные конфигурации, чтобы дать пользователям представление о том, что работает и какие варианты доступны, особенно в преддверии обновления лабораторий к 2025 году.

Нужно также упомянуть несколько ресурсов, которые могут быть полезны при создании вашей новой лаборатории/тестовой среды с VCF:

• Ознакомьтесь с этой статьей VMware KB о выводе из эксплуатации и прекращении поддержки процессоров в выпусках vSphere, чтобы понять, какие процессоры будут поддерживаться в будущем, особенно с учетом следующего крупного релиза vSphere.
• Многие сотрудники используют популярный сайт PC Server and Parts для поиска мощных, но относительно недорогих настольных рабочих станций старых поколений. Это хороший вариант, если вы не хотите тратить деньги на процессоры Intel или AMD последнего поколения.
• Если вы выберете процессор, который больше не поддерживается, убедитесь, что он поддерживает инструкцию XSAVE CPU. Также можно обойти проверку установщика ESXi, используя параметр allowLegacyCPU=TRUE.
• Память часто является первым ресурсом, который исчерпывается, поэтому убедитесь, что у вас есть достаточная емкость NVMe для использования новой функции vSphere NVMe (Memory) Tiering. Это кардинально меняет правила игры, независимо от того, запускаете ли вы нагрузки в лаборатории или будете использовать их в будущем в продакшене.
• Что касается выбора процессоров, Вильям заметил, что всё больше пользователей отдают предпочтение процессорам AMD, а не Intel. Причина — не только стоимость, но и общие возможности (количество ядер, энергопотребление, охлаждение и т. д.). Например, у Raiko (см. ниже для получения дополнительной информации) есть отличная конфигурация, которую многие считают очень экономически выгодной. Многие планируют использовать его BOM для своих VCF-лабораторий.

Вот основные моменты его конфигурации (кликните для увеличения картинки):

• Независимо от того, создаете ли вы лабораторную среду для работы или дома, в конечном счете, дело не только в самом оборудовании (хотя и в нем тоже), а в инвестиции в себя и свою карьеру. Вы получите от этой работы столько, сколько в нее вложите. У всех разные потребности, поэтому универсального решения не существует. Ресурсы проекта VMware Community Homelab Project и конфигурации, представленные ниже, помогут вам понять, что работает, ну а в конечном итоге выбор лучшей конфигурации зависит от ваших требований, бюджета и целей.

Примечание: если вы недавно (в течение последнего года) построили новую лабораторную среду для запуска VCF 5.x или более поздних версий и хотите поделиться своим опытом, отправьте их через VMware Community Homelab Project, перейдя сюда.

Ну и, собственно, таблица наиболее удачных конфигураций:

Последнее независимое исследование, проведенное компанией Principled Technologies, показало, что по сравнению с Red Hat OpenShift Virtualization 4.16.2, платформа VMware vSphere поддерживает на 62% больше транзакций баз данных и сохраняет их стабильную производительность при увеличении количества виртуальных машин. Кроме того, vSphere поддерживает в 1.5 раза больше виртуальных машин на хост, чем OpenShift, без необходимости дополнительной настройки для переподписки памяти (memory overcommitment).

VMware vSphere — это корпоративная платформа виртуализации вычислительных ресурсов, разработанная для предоставления преимуществ облачных технологий в рамках локальных рабочих нагрузок. Она объединяет передовые облачные инфраструктурные технологии с ускорением, основанным на процессорах для обработки данных (DPU) и графических процессорах (GPU), чтобы повысить производительность машин. Сегодня более 300 000 компаний используют vSphere для обеспечения цифровой трансформации. vSphere позволяет ИТ-командам повысить операционную эффективность, ускорить внедрение DevOps-решений и усилить безопасность.

Последнее обновление VMware vSphere 8 Update 3 включает специальную функцию управления памятью для технологии memory overcommitment, которая помогает балансировать производительность виртуальных машин и их плотность. Но как управление памятью в vSphere соотносится с конкурирующими решениями? Компания Principled Technologies провела детальное исследование производительности и плотности виртуальных машин для VMware vSphere 8 Update 3 в сравнении с Red Hat OpenShift Virtualization версии 4.16.2.

Обзор протестированных сценариев

Исследование Principled Technologies началось с тестирования 10 виртуальных машин с установленной СУБД SQL Server c использованием нагрузки TPROC-C для оценки производительности OLTP-транзакций (измеряемой в операциях в минуту, NOPM) для каждой платформы. Начальная конфигурация предполагала memory overcommitment без фактического перераспределения памяти или стрессового использования других ресурсов сервера. Затем плотность виртуальных машин постепенно увеличивалась: сначала до 12 ВМ, создавая сценарий с небольшой переподпиской по памяти, после чего добавлялись ВМ до тех пор, пока производительность платформы не снизилась на 10% или более. Как только платформа показывала значительное ухудшение производительности, тестирование масштабирования для него прекращалось.

Оба сценария использовали один и тот же сервер Dell PowerEdge R650, отличалась только используемая платформа виртуализации.

Ключевые результаты исследования от Principled Technologies

• vSphere 8 обеспечивает лучшую производительность OLTP-транзакций и масштабирование до большего количества виртуальных машин без снижения производительности.

В базовом тесте каждое окружение было настроено с 10 виртуальными машинами по 28 ГБ виртуальной памяти (vRAM) каждая, что составило 280 ГБ выделенной памяти без необходимости переподписки. VMware vSphere 8 Update 3 обеспечила на 27,6% больше NOPM (новых операций в минуту), чем OpenShift, при этих условиях.

На следующем этапе тестирования на обех платформах виртуальное окружение масштабировалось до 12 виртуальных машин, что превысило физическую память сервера и потребовало переподписки. vSphere 8 Update 3 успешно справилась с этим увеличением без дополнительных настроек, обеспечив рост NOPM на 6% относительно базового уровня. Напротив, OpenShift потребовала ручной настройки переподписки памяти, что привело к снижению NOPM на 6,9% относительно базового уровня.

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

• vSphere 8 достигает более высоких пределов плотности виртуальных машин с минимальным падением производительности

Когда оба решения были доведены до предела их возможностей для определения порога плотности виртуальных машин, была зафиксирована значительная деградация (снижение NOPM более чем на 10%). VMware vSphere 8 Update 3 достигла значительной деградации при 20 виртуальных машинах, показав снижение NOPM на 14,31% по сравнению с конфигурацией из 12 виртуальных машин с небольшой переподпиской памяти. В то же время OpenShift Virtualization 4.16.2 столкнулась с деградацией уже при 13 виртуальных машинах, продемонстрировав снижение NOPM на 23,19% по сравнению с конфигурацией из 12 виртуальных машин. Это указывает на более низкий порог плотности для оптимальной производительности в случае OpenShift.

При запуске 20 виртуальных машин решение vSphere 8 Update 3 достигло пикового уровня загрузки процессора в 94,4%. При 12 виртуальных машинах загрузка процессора у vSphere составила 91,7%, а при 10 виртуальных машинах — 80,1%. В то же время решение OpenShift Virtualization 4.16.2 показало загрузку процессора в 58,3% при 13 виртуальных машинах, 61,5% при 12 виртуальных машинах и 52,1% при 10 виртуальных машинах. Этот тест демонстрирует, что vSphere 8 Update 3 может справляться с более высокой плотностью виртуальных машин, обеспечивая лучшую стабильность производительности при переподписке выделенной памяти по сравнению с OpenShift.

Интересный документ выпустила компания VMware - "Improving VDI Workload Consolidation with VMware vSGA and Intel Data Center GPU Flex Series", в нем рассматриваются аспекты тестирования производительности VDI-нагрузок в различных контекстах на базе оборудования Intel Data Center GPU Flex в режиме vSGA (то есть совместного использования видеоадаптера несколькими ВМ)...

Компания VMware недавно выпустила интересное видео в рамках серии Extreme Performance, где рассматривается, как технологии Memory Tiering могут оптимизировать серверную инфраструктуру, улучшить консолидацию серверов и снизить общую стоимость владения (TCO). Ведущие эксперты, работающие в сфере производительности платформ VMware, делятся новейшими разработками и результатами тестов, которые помогут сделать работу администраторов с серверами более эффективной.

Основные моменты видео:

1. Что такое Memory Tiering? Memory Tiering — это технология, реализованная в ядре ESXi, которая прозрачно для приложений и гостевых ОС разделяет память на два уровня:

   • Tier 1: Быстрая память DRAM.
   • Tier 2: Бюджетные и емкие устройства памяти, такие как NVMe SSD и CXL.
2. Преимущества Memory Tiering:
   • Увеличение доступной памяти за счет использования NVMe в качестве памяти второго уровня.
   • Снижение затрат на память до 50%.
   • Исключение таких проблем, как ballooning и случайный обмен страницами.
3. Реальные результаты:
   • Удвоение плотности виртуальных машин (VMs): на одной хост-машине можно разместить вдвое больше ВМ без заметной потери производительности (<3%).
   • Оптимизация работы баз данных: для SQL Server и Oracle наблюдалось почти линейное масштабирование с минимальными потерями производительности.
   • Стабильный пользовательский опыт (VDI): эталонный тест Login VSI показал, что даже при удвоении числа ВМ пользовательский опыт остается на высоком уровне.
4. Ключевые метрики и рекомендации:
   • Active memory: один из основных параметров для мониторинга. Оптимальный уровень — около 50% от объема Tier 1 (DRAM).
   • Использование NVMe: рекомендации по чтению и записи (до 200 мс latency для чтения и 500 мс для записи).
5. Практические примеры и кейсы:
   • Клиенты из финансового и медицинского секторов, такие как SS&C Cloud, уже успешно применяют Memory Tiering, чтобы уменьшить затраты на серверы и улучшить их производительность.
6. Советы по настройке и мониторингу:
   • Как отслеживать активность NVMe-устройств и состояние памяти через vCenter.
   • Какие показатели важны для анализа производительности.

Кому будет полезно:

• Системным администраторам, DevOps-инженерам и специалистам по виртуализации.
• Организациям, которые стремятся сократить затраты на ИТ-инфраструктуру и повысить плотность виртуализации.
• Любителям передовых технологий, которые хотят понять, как современные подходы меняют управление памятью в дата-центрах.

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

Broadcom сообщила, что ОС Windows Server 2025 официально сертифицирована для работы на платформе VMware vSphere версий 7.0 U3, 8.0, 8.0 U1, 8.0 U2 и 8.0 U3. Эти версии прошли тестирование и валидацию, обеспечивая стабильную и высокопроизводительную платформу для запуска Windows Server 2025 в качестве гостевой операционной системы в виртуальных машинах. Для получения подробной информации о поддерживаемых версиях обратитесь к Broadcom Compatibility Guide.

Что нового?

Сертификация VMware vSphere в рамках программы Microsoft SVVP

VMware vSphere 7.0 U3, 8.0, 8.0 U1, 8.0 U2 и 8.0 U3 входят в число первых гипервизоров, сертифицированных в рамках программы Microsoft Windows Server Virtualization Validation Program (SVVP). Эта сертификация подтверждает официальную поддержку Microsoft и VMware для работы Windows Server 2025 в средах VMware vSphere. Подробнее ознакомиться с сертификацией можно на странице сертификации VMware vSphere SVVP.

Поддержка VMware Tools с первого дня для Windows Server 2025

Все драйверы в режиме ядра VMware Tools полностью сертифицированы для Windows Server 2025, что обеспечивает высокую совместимость, стабильность и безопасность. Дополнительную информацию можно найти в блоге: VMware Tools 12.5.0 готов к работе с новейшими операционными системами Windows.

Драйверы VMware PVSCSI и VMXNET3 включены в Windows Server 2025

Начиная с Windows Server 2022, а теперь и для Windows Server 2025, драйверы VMware Paravirtual SCSI (PVSCSI) и сетевого адаптера VMXNET3 предустановлены в ОС от Microsoft. Это упрощает процесс настройки и обеспечивает эффективное развертывание виртуальных машин Windows Server с высокопроизводительными виртуальными устройствами без необходимости ручной установки драйверов.

Новый плагин VMXNET3 KDNET для отладки сетевого ядра

В Windows Server 2025 включён плагин расширения VMXNET3 KDNET для отладки сетевого ядра. Это позволяет выполнять отладку напрямую в виртуальной среде, предоставляя разработчикам удобный и эффективный процесс отладки. Дополнительную информацию о настройке сетевой отладки ядра можно найти в документации Microsoft.

Установка Windows Server 2025 в VMware vSphere

Перед развертыванием виртуальных машин с Windows Server 2025 в VMware vSphere рекомендуется ознакомиться с Руководством по совместимости Broadcom, чтобы убедиться в совместимости вашего оборудования и продуктов VMware. Это руководство содержит важную информацию о поддерживаемых серверах, устройствах хранения, сетевых адаптерах и других компонентах.

Для получения подробных инструкций по установке обратитесь к документации VMware: "Руководство по установке Windows Server 2025".

Ссылки и известные проблемы

Для устранения неисправностей и оптимизации развертывания виртуальных машин Windows Server 2025 на VMware vSphere ознакомьтесь с приведёнными ниже статьями базы знаний (KB). Эти статьи охватывают вопросы совместимости VMware Tools, а также решения известных проблем.

• VMware Tools compatibility with guest operating systems
• Windows Server 2025 Guest OS option is not Available During VMware vSphere ESXi Virtual Machine Creation
• Upgrading guest OS in VMware vSphere ESXi VM from Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022 to Windows Server 2025
• Windows Server 2025 with a virtual NVME boot disk may fail to boot when other disks are on the same NVME controller
• Windows Server 2025 does not recognize virtual NVDIMM devices

В ноябре этого года компания Broadcom объявила о продолжении эволюции портфолио в сфере серверной виртуализации, включающего в себя платформы VMware Cloud Foundation (VCF) и VMware vSphere Foundation (VVF).

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

Чтобы предложить клиентам более мощное и ценное решение корпоративного класса для гиперконвергентной инфраструктуры (HCI), которое позволяет запускать виртуальные машины и контейнеры с оптимизацией ИТ-инфраструктуры, VMware увеличит объём предоставляемого дискового пространства vSAN в составе VMware vSphere Foundation в 2.5 раза — до 250 GiB на ядро (аналог гигабайт). А для завершения портфеля, для клиентов, сосредоточенных на виртуализации вычислений, теперь будет два издания платформы: VMware vSphere Enterprise Plus (раньше это издание отменили, а теперь возвращают снова) и VMware vSphere Standard. Весь портфель VCF доступен конечным пользователям через дистрибьюторскую сеть или напрямую от Broadcom.

Спасибо Сергею за новость.

Если вы пропустили новость о том, что вышло обновление платформы VMware vSphere 8 Update 3b, то сейчас самое время подумать об обновлении, так как сообщений о каких-то серьезных багах не поступало.

Итак, что нового в VMware ESXi 8.0 Update 3b:

• DPU/SmartNIC - появилась поддержка VMware vSphere Distributed Services Engine с DPU NVIDIA Bluefield-3. Устройства DPU NVIDIA Bluefield-3 поддерживаются как в режиме одиночного DPU, так и в dual-DPU конфигурациях.
• ESXi 8.0 Update 3b добавляет поддержку vSphere Quick Boot для нескольких серверов, включая:
  • HPE ProLiant DL145 Gen11
  • HPE ProLiant MicroServer Gen11
  • Cisco UCSC-C245-M8SX
  • Supermicro AS-2025HS-TNR

Для полного списка поддерживаемых серверов смотрите VMware Compatibility Guide.

• Улучшения в проектировании переменных cloud-init guestInfo: начиная с ESXi 8.0 Update 3b, попытка обычных пользователей задать переменные cloud-init guestInfo внутри гостевой ОС приводит к ошибке. Для получения дополнительной информации см. KB 377267.

Что нового в VMware vCenter 8.0 Update 3b:

• Этот выпуск устраняет уязвимости CVE-2024-38812 и CVE-2024-38813. Для получения дополнительной информации об этих уязвимостях и их влиянии на продукты VMware посмотрите статью VMSA-2024-0019.
• VMware vCenter Server 8.0 Update 3b предоставляет исправления ошибок, описанные в разделе Resolved Issues.
• Для информации об обновлениях VMware vSphere with Tanzu смотрите Release Notes для VMware vSphere IaaS Control Plane 8.0.
• Для информации об обновлениях Photon OS смотрите обновления безопасности VMware vCenter Server Appliance Photon OS.

Если вы не знаете, как скачать VMware vSphere 8 Update 3b, воспользуйтесь информацией по этой ссылке.

В этом месяце VMware опубликовала девять новых результатов тестов VMmark 4 от компаний Dell Technologies, Hewlett Packard Enterprise и Supermicro, которые демонстрируют производительность и масштабируемость новых серверных процессоров AMD EPYC серии 9005, поддерживающихся в хостах VMware vSphere 8. Результаты можно посмотреть на странице результатов VMmark 4, но основные моменты освещены в статье ниже.

VMmark 4

VMware VMmark 4 — это бесплатный кластерный тест, измеряющий производительность и масштабируемость корпоративных сред виртуализации. Если вы хотите узнать больше о VMmark 4, обратитесь к статье "Введение в VMmark 4: модернизированный эталон консолидации серверов для частных облаков" и к разделу часто задаваемых вопросов по продуктам VMmark.

Важная особенность: одна плитка (tile) VMmark включает 23 виртуальных машины, выполняющих разнообразные рабочие нагрузки — от традиционных Java- и баз данных до Kubernetes, Docker-контейнеров, NoSQL и нагрузок социальных сетей, характерных для современных корпоративных дата-центров.

Результаты тестирования Supermicro

Первое сравнение демонстрирует, как хорошо масштабируются эти новые процессоры при использовании VMmark 4 и последнего гипервизора VMware ESXi при удвоении общего числа ядер с 128 до 256 (результаты - для двух плиток и для четырех).

Как видно из таблицы и графика выше, результат с 256 ядрами в 1,9 раза выше, чем результат с 128 ядрами, при этом в течение 3 часов теста VMmark работало в два раза больше виртуальных машин (разные плитки).

Результаты тестирования Dell Technologies

На данный момент у Dell есть три результата тестирования VMmark 4 на базе процессоров EPYC 9005 с разным количеством ядер (1, 2, 3).

Одна плитка VMmark 4 состоит из 23 виртуальных машин, однако два из этих результатов содержат дробное количество плиток. Что это значит? Ответ заключается в том, что в VMmark 4 была добавлена функция частичных плиток. Частичные плитки запускают подмножество рабочих нагрузок для более точной детализации, что позволяет тестировщикам максимально использовать производительность их решений для виртуализации. Например, 4.6 плитки включают 99 активных виртуальных машин, тогда как 5 плиток — 115 виртуальных машин, что на 16% больше.

Результаты Dell также являются первыми результатами VMmark, использующими NVMe over TCP с подключением к внешнему хранилищу через двухпортовые сетевые карты Broadcom BCM957508-P2100G со скоростью 100 Гбит/с, вместо традиционных адаптеров шины.

Результаты тестирования Hewlett Packard Enterprise

У HPE есть три результата тестирования VMmark 4 (1, 2, 3).

Первый результат использует процессоры предыдущего поколения EPYC 4-го поколения (обозначенные номером "4" в конце модели процессора). Несмотря на одинаковое количество ядер в первых двух результатах, процессоры 5-го поколения показывают производительность выше более чем на 10%.

Если сравнить результат предыдущего поколения с результатом на 1280 ядрах, он оказывается на впечатляющие 45% выше!

Вильям Лам написал наиполезнейшую статью о сбросе/восстановлении пароля консоли сервера VMware ESXi 8 и 7 в составе платформы виртуализации VMware vSphere.

Общее руководство и самый быстрый способ восстановления пароля root для хоста ESXi, если вы забыли или потеряли его, заключается в сбросе с помощью профилей хостов vSphere, если он управлялся сервером vCenter, или просто переустановке ESXi, что позволит сохранить существующие тома VMFS вместе с виртуальными машинами, которые могут на них находиться.

Ранее также было возможно сбросить пароль root ESXi, загрузив систему в Linux и вручную обновив файл /etc/shadow, что похоже на то, как можно сбросить пароль в системе на базе Linux. В сети можно найти множество статей в блогах, описывающих этот процесс. Однако с появлением ESXi Configuration Store данный метод больше не работает для современных версий ESXi, начиная с ESXi 7.0 Update 1 и выше.

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

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

Предварительные требования:

• Доступ к физическому носителю, на который установлен ESXi (USB или HDD/SSD)
• Виртуальная машина Linux (Ubuntu или Photon OS)
• Виртуальная машина с вложенным ESXi

Для демонстрации описанного ниже процесса восстановления Вильям установил ESXi 8.0 Update 3c на USB-устройство с базовой конфигурацией (имя хоста, сеть, SSH MOTD), чтобы убедиться в возможности восстановления системы. Затем он изменил пароль root на что-то полностью случайное и удалил этот пароль, чтобы нельзя было войти в систему. Хост ESXi, на котором он "забыл" пароль, будет называться физическим хостом ESXi, а вложенная виртуальная машина с ESXi, которая будет помогать в восстановлении, будет называться вложенным хостом (Nested ESXi).

Шаг 1 — Разверните вложенную виртуальную машину с ESXi (скачать с сайта VMware Flings), версия которой должна соответствовать версии вашего физического хоста ESXi, который вы хотите восстановить.

Шаг 2 — Скопируйте файл state.tgz с физического хоста ESXi, который вы хотите восстановить. Обязательно сделайте резервную копию на случай, если допустите ошибку.

• Если ваш хост ESXi установлен на USB, отключите USB-устройство, подключите его к настольной системе и скопируйте файл с тома BOOTBANK1.
• Если ваш хост ESXi установлен на HDD/SSD, вам нужно будет загрузить физическую систему с помощью Linux LiveCD (Ubuntu или Knoppix) и смонтировать раздел 5 для доступа к файлу state.tgz.

Шаг 3 — Скопируйте файл state.tgz с вашего физического хоста ESXi на вложенный хост ESXi и поместите его в /tmp/state.tgz, затем выполните следующую команду для извлечения содержимого файла:

tar -zxvf state.tgz
rm -f state.tgz

Шаг 4 — Войдите на ваш вложенный хост ESXi и выполните следующие команды для извлечения его файла state.tgz, который будет помещен в каталог /tmp/a. Затем мы используем утилиту crypto-util для расшифровки файла local.tgz.ve вложенного хоста ESXi, чтобы получить файл local.tgz, и затем просто удаляем зашифрованный файл вместе с файлом encryption.info вложенного хоста ESXi. После этого мы заменим их файлом encryption.info с нашего физического хоста ESXi и создадим модифицированную версию state.tgz, которая будет загружаться в нашей вложенной виртуальной машине ESXi. Мы используем это для расшифровки исходного файла state.tgz с нашего физического хоста ESXi.

mkdir /tmp/a
cd /tmp/a
tar xzf /bootbank/state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve encryption.info
cp /tmp/encryption.info /tmp/a/encryption.info
tar -cvf /tmp/state-mod.tgz encryption.info local.tgz

После успешного выполнения последней команды, нам нужно скопировать файл /tmp/state-mod.tgz на ваш рабочий стол, а затем выключить вложенную виртуальную машину ESXi.

Шаг 5 — Смонтируйте первый VMDK диск из вашей вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux. В данном случае Вильм использует Photon OS, который также управляет и DNS-инфраструктурой.

Шаг 6 — Убедитесь, что VMDK вашей вложенной виртуальной машины ESXi виден в вашей системе Linux, выполнив следующую команду. Мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже:

fdisk -l

Шаг 7 — Перенесите файл state-mod.tgz, созданный на Шаге 4, на вашу виртуальную машину с Linux, затем смонтируйте оба раздела bootbank и замените файл state.tgz на нашу модифицированную версию.

mount /dev/sdb5 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

mount /dev/sdb6 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

Примечание: Этот шаг необходим, потому что, если вы просто скопируете модифицированный файл state.tgz напрямую на USB-устройство физического хоста ESXi, вы обнаружите, что система восстановит оригинальный файл state.tgz, даже если на обоих разделах содержится модифицированная версия.

Шаг 8 — Сделайте remove (не удаляйте) VMDK файл вложенной виртуальной машины ESXi с виртуальной машины Linux, затем включите вложенную виртуальную машину ESXi.

После успешной загрузки вложенной виртуальной машины ESXi, она теперь работает с оригинальным файлом encryption.info с нашего физического хоста ESXi, что позволит нам восстановить исходный файл state.tgz.

Шаг 9 — Скопируйте исходный файл state.tgz, созданный на Шаге 2, во вложенную виртуальную машину ESXi, поместите его в каталог /tmp/state.tgz и выполните следующую команду, которая теперь позволит нам расшифровать файл state.tgz с физического хоста ESXi, как показано на скриншоте ниже!

cd /tmp
tar -zxvf state.tgz
rm -f state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve

Шаг 10 — После расшифровки исходного файла state.tgz у нас должен появиться файл local.tgz, который мы извлечем локально в каталоге /tmp, выполнив следующую команду:

Следующие три каталога: .ssh, etc/ и var/ будут размещены в /tmp, а /tmp/var/lib/vmware/configstore/backup/current-store-1 — это хранилище конфигурации ESXi для физического хоста ESXi, которое нам нужно обновить и заменить оригинальный хеш пароля root на желаемый, чтобы мы могли войти в систему.

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

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "select * from config where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

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

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "update config set UserValue='{\"name\":\"root\",\"password_hash\":\"\$6\$s6ic82Ik\$ER28x38x.1umtnQ99Hx9z0ZBOHBEuPYneedI1ekK2cwe/jIpjDcBNUHWHw0LwuRYJWhL3L2ORX3I5wFxKmyki1\",\"description\":\"Administrator\"}' where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

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

Шаг 12 — Теперь, когда мы обновили хранилище конфигурации ESXi с нашим желаемым паролем root, нам нужно заново создать файл state.tgz, который будет содержать наши изменения, выполнив следующие команды:

rm -f local.tgz 
tar -cvf /tmp/local.tgz .ssh/ etc/ var/ 
tar -cvf /tmp/state-recover.tgz encryption.info local.tgz

Скопируйте файл /tmp/state-recover.tgz с вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux, которая затем будет использоваться для монтирования носителя физического хоста ESXi, чтобы заменить файл state.tgz на нашу восстановленную версию.

Шаг 13 — Смонтируйте носитель физического хоста ESXi на вашу виртуальную машину с Linux. Поскольку физический хост ESXi установлен на USB, можно просто подключить USB-устройство напрямую к виртуальной машине с Linux.

Снова мы можем убедиться, что виртуальная машина с Linux видит носитель с установленным физическим хостом ESXi, выполнив команду fdisk -l, и мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже.

Шаг 14 — Теперь нам просто нужно смонтировать раздел bootbank и заменить оригинальный файл state.tgz на нашу модифицированную версию (state-recover.tgz).

mount /dev/sdb5 /mnt 
cp ~/state-recover.tgz /mnt/state.tgz 
chmod 755 /mnt/state.tgz 
umount /mnt

Примечание: Поскольку физический хост ESXi был только что установлен, на втором разделе bootbank не было ничего для замены, но если вы найдете файл state.tgz, его также следует заменить, используя ту же команду, но указав другой номер раздела.

Шаг 15 — Последний шаг: размонтируйте носитель физического хоста ESXi с виртуальной машины Linux, затем включите ваш физический хост ESXi, и теперь вы сможете войти в систему, используя обновленный пароль root!

Вчера мы писали об обновленной утилите SexiGraf для мониторинга виртуальной инфраструктуры VMware vSphere. Сегодня мы поговорим еще об одном наборе бесплатных дэшбордов Grafana для мониторинга VMware vSphere, которые сделал Jorge de la Cruz.

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

Итак, сами дэшборды:

1. VMware vSphere - Overview

Этот дэшборд содержит пять различных разделов: один для мониторинга производительности ESXi и vCenter, другой для производительности виртуальных машин, третий для дисков, четвёртый для хранилищ, и последний для хостов и их IPMI. Дэшборд включает переменные, чтобы сделать его использование проще и подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами:

2. VMware vSphere - Datastore

Этот дэшборд содержит два раздела: один для мониторинга производительности ESXi и vCenter, другой - для производительности виртуальных машин. Дашборд включает переменные, чтобы упростить его использование и сделать его подходящим для различных типов рабочих нагрузок. Индикаторы автоматически настраиваются в зависимости от выбранных вами хранилищ данных. Если у вас много хранилищ, рассмотрите возможность изменения параметра Min Width для Repeat Panel.

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

3. VMware vSphere - Hosts

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

4. VMware vSphere - VMs

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Ну и главное - вот эта статья. Она описывает, как настроить мониторинг VMware с помощью дэшбордов Grafana, InfluxDB и Telegraf. В ней пошагово объясняется создание стека контейнеров с использованием Docker Compose, настройка InfluxDB и Telegraf для сбора метрик VMware из vCenter, а также визуализация данных в Grafana. Там подробно рассматривается использование готовых дэшбордов для ускорения процесса настройки и предлагаются советы по устранению неполадок.

Спасибо Сергею за новость.

Наш читатель Сергей справедливо заметил, что мы давно не писали о новых релизах бесплатной утилиты SexiGraf, предназначенной для мониторинга виртуальной инфраструктуры VMware vSphere. В последний раз мы писали об этом в январе прошлого года, а на днях вышло обновление этого продукта - SexiGraf 0.99k (Lighthouse Point).

Это средство было сделано энтузиастами (Raphael Schitz и Frederic Martin) в качестве альтернативы платным продуктам для мониторинга серверов ESXi и виртуальных машин. Представления SexiPanels для большого числа метрик в различных разрезах есть не только для VMware vSphere и vSAN, но и для ОС Windows и FreeNAS.

Давайте посмотрим на новые возможности двух недавних релизов:

Релиз Lighthouse Point (0.99k) от 7 октября 2024

VMware Snapshot Inventory

Начиная с версии SexiGraf 0.99h, панель мониторинга «VI Offline Inventory» заменена на VMware Inventory с инвентаризацией ВМ, хостов и хранилищ данных (вскоре добавятся портгруппы и другие элементы). Эти новые панели имеют расширенные возможности фильтрации и значительно лучше подходят для крупных инфраструктур (например, с более чем 50 000 виртуальных машин). Это похоже на извлечение данных из RVtools, которое всегда отображается и актуально.

В релизе v0.99k появилось представление VM Snapshot Inventory:

Улучшения "Cluster health score" для VMware vSAN 8

Вместо того чтобы бесконечно нажимать на кнопку обновления на вкладке «Resyncing Components» в WebClient, начиная с версии SexiGraf 0.99b разработчики добавили панель мониторинга vSAN Resync:

Shell In A Box

В версии SexiGraf 0.99k разработчики добавили отдельный дэшборд Shell In A Box за обратным прокси-сервером, чтобы снова сделать отладку удобной.

Прочие улучшения:

• Официальная поддержка vSphere и vSAN 8.3 API, а также Veeam Backup & Replication v12
• Движок обновлен до Grafana 8.5.9
• PowerShell core обновлен до 7.4.4 LTS
• PowerCLI 13.3
• Graphite 1.2.0
• Автоматическая очистка /var/lib/grafana/png/
• Добавлен выбор версии в панель мониторинга VMware Evo Version
• Добавлена многострочная панель в панель мониторинга репозиториев Veeam
• Обработка учетных записей с очень ограниченными правами
• Опция использования MAC-адреса вместо Client-ID при использовании DHCP
• Добавлено имя хоста гостевой ОС в инвентаризацию виртуальных машин

Релиз St. Olga (0.99j) от 12 февраля 2024

В этой версии авторы добавили официальную поддержку новых API vSphere и vSAN 8.2, а также Veeam Backup & Replication v11+.

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

• Поддержка Veeam Backup & Replication
• Автоматическое слияние метрик ВМ и ESXi между кластерами (функция DstVmMigratedEvent в VROPS)
• Количество путей до HBA
• PowerShell Core 7.2.17 LTS
• PowerCLI 13.2.1
• Grafana 8.5.9 (не 8.5.27 из-за ошибки, появившейся в v8.5.10)
• Ubuntu 20.04.6 LTS

Улучшения и исправления:

• Метрика IOPS для виртуальных машин
• Инвентаризация VMware VBR
• История инвентаризации
• Панель мониторинга эволюции версий активов VMware
• Исправлено пустое значение datastoreVMObservedLatency на NFS
• Различные исправления ошибок

SexiGraf теперь поставляется только в виде новой OVA-аппаратной версии, больше никаких патчей (за исключением крайних случаев). Для миграции необходимо использовать функцию Export/Import, чтобы извлечь данные из вашей предыдущей версии SexiGraf и перенести их в новую.

Актуальная версия SexiGraf доступна для бесплатной загрузки на странице Quickstart.

Недавно мы писали о технологии NVMe Tiering, которая появилась в режиме технологического превью в платформе VMware vSphere 8.0 Update 3.

Memory Tiering использует более дешевые устройства в качестве памяти. В Update 3 платформа vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).

Вильям Лам написал интересный пост о выводе информации для NVMe Tiering в VMware vSphere через API. После успешного включения функции NVMe Tiering, которая была введена в vSphere 8.0 Update 3, вы можете найти полезную информацию о конфигурации NVMe Tiering, перейдя к конкретному хосту ESXi, затем выбрав "Configure" -> "Hardware" и в разделе "Memory", как показано на скриншоте ниже.

Здесь довольно много информации, поэтому давайте разберём отдельные элементы, которые полезны с точки зрения NVMe-тиринга, а также конкретные vSphere API, которые можно использовать для получения этой информации.

Memory Tiering Enabled

Поле Memory Tiering указывает, включён ли тиринг памяти на хосте ESXi, и может иметь три возможных значения: "No Tiering" (без тиринга), "Hardware Memory Tiering via Intel Optane" (аппаратный тиринг памяти с помощью технологии Intel Optane) или "Software Memory Tiering via NVMe Tiering" (программный тиринг памяти через NVMe). Мы можем получить значение этого поля, используя свойство "memoryTieringType" в vSphere API, которое имеет три перечисленных значения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTieringType

Tier 0 Memory

Поле Tier 0 представляет общий объём физической оперативной памяти (DRAM), доступной на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "DRAM"}).Size

Tier 1 Memory

Поле Tier 1 представляет общий объём памяти, предоставляемой NVMe-тирингом, которая доступна на хосте ESXi. Мы можем получить это поле, используя свойство "memoryTierInfo" в vSphere API, которое возвращает массив результатов, содержащий значения как Tier 0, так и Tier 1.

Примечание: Можно игнорировать термин "Unmappable" — это просто другой способ обозначения памяти, отличной от DRAM.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

((Get-VMHost "esxi-01.williamlam.com").ExtensionData.Hardware.MemoryTierInfo | where {$_.Type -eq "NVMe"}).Size

Поле Total представляет общий объём памяти, доступный ESXi при объединении как DRAM, так и памяти NVMe-тиринга, который можно агрегировать, используя размеры Tier 0 и Tier 1 (в байтах).

Устройства NVMe для тиринга

Чтобы понять, какое устройство NVMe настроено для NVMe-тиринга, нужно перейти в раздел "Configure" -> "Storage" -> "Storage Devices", чтобы просмотреть список устройств. В столбце "Datastore" следует искать значение "Consumed for Memory Tiering", как показано на скриншоте ниже. Мы можем получить это поле, используя свойство "usedByMemoryTiering" при энумерации всех устройств хранения.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

$storageSystem = Get-View (Get-vmhost "esxi-01.williamlam.com").ExtensionData.ConfigManager.StorageSystem
($storageSystem.StorageDeviceInfo.ScsiLun | where {$_.UsedByMemoryTiering -eq $true}).CanonicalName

Соотношение NVMe-тиринга и DRAM

Отношение объёма DRAM к NVMe по умолчанию составляет 25% и настраивается с помощью следующего расширенного параметра ESXi под названием "Mem.TierNvmePct". Мы можем получить значение этого поля, используя либо vSphere API ("OptionManager"), либо через ESXCLI.

Вот небольшой фрагмент PowerCLI-кода для получения этого поля для конкретного хоста ESXi:

(Get-vmhost "esxi-01.williamlam.com" | Get-AdvancedSetting -Name Mem.TierNvmePct).Value

Сводный отчёт

Вильям собрал все вышеперечисленные парметры и создал скрипт PowerCLI под названием "get-nvme-tiering-info.ps1", который предоставляет удобное резюме для всех хостов ESXi в рамках конкретного кластера Sphere (вы также можете изменить скрипт, чтобы он запрашивал конкретный хост ESXi). Это может быть полезно для быстрого получения информации о хостах, на которых NVMe-тиринг может быть настроен (или нет).

Вот скриншот того, как выглядит вывод скрипта:

Компания VMware представила обновленную версию документа "Best Practices for VMware vSphere 8.0 Update 3", описывающего лучшие практики повышения производительности для последней версии платформы VMware vSphere 8.0 Update 3 — ценный ресурс, наполненный экспертными советами по оптимизации быстродействия. Хотя это и не является всеобъемлющим руководством по планированию и настройке ваших развертываний, он предоставляет важные рекомендации по улучшению производительности в ключевых областях.

Краткий обзор содержания:

• Глава 1: Оборудование для использования с VMware vSphere (Стр. 11) — узнайте важные советы по выбору правильного оборудования, чтобы максимально эффективно использовать вашу среду vSphere.
• Глава 2: ESXi и виртуальные машины (Стр. 25) — ознакомьтесь с лучшими практиками для платформы VMware ESXi и тонкими настройками виртуальных машин, работающих в этой среде.
• Глава 3: Гостевые операционные системы (Стр. 57) — узнайте, как правильно оптимизировать гостевые ОС, работающие в ваших виртуальных машинах vSphere.
• Глава 4: Управление виртуальной инфраструктурой (Стр. 69) — получите советы по эффективному управлению для поддержания высокопроизводительной виртуальной инфраструктуры.

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

vSphere Memory Tiering - это очень интересная функция, которую VMware выпустила в качестве технического превью в составе vSphere 8.0 Update 3, чтобы дать своим клиентам возможность оценить механику ранжирования памяти в их тестовых средах. Об этом мы уже немного рассказывали, а сегодня дополним.

По сути, Memory Tiering использует более дешевые устройства в качестве памяти. В vSphere 8.0 Update 3 vSphere использует флэш-устройства PCIe на базе NVMe в качестве второго уровня памяти, что увеличивает доступный объем памяти на хосте ESXi. Memory Tiering через NVMe оптимизирует производительность, распределяя выделение памяти виртуальных машин либо на устройства NVMe, либо на более быструю динамическую оперативную память (DRAM) на хосте. Это позволяет увеличить объем используемой памяти и повысить емкость рабочих нагрузок, одновременно снижая общую стоимость владения (TCO).

Memory Tiering также решает проблемы несоответствия между ядрами процессора и объемом памяти и способствует лучшей консолидации рабочих нагрузок и виртуальных машин.

Memory Tiering настраивается на каждом ESXi в кластере, и все хосты должны работать на vSphere 8.0 U3. По умолчанию соотношение DRAM к NVMe составляет 4:1, но его можно изменить для использования большего количества ресурсов NVMe в качестве памяти.

Для изменения этого соотношения нужно зайти в Host > Manage > System > Advanced settings и поменять там настройку Mem.TierNvmePct. По умолчанию это 25, то есть NVMe занимает 25% от общей оперативной памяти хоста ESXi. Максимальное значение составляет 400, минимальное - 1.

Технические подробности настройки vSphere Memory Tiering описаны в статье базы знаний KB 95944. Там можно скачать документ "Memory Tiering over NVMe Tech Preview", где описываются все аспекты использования данной технологии:

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

• NVMe Tiering in vSphere 8.0 Update 3 is a Homelab game changer!
• Quick Tip - NVMe Tiering configured but not working?

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

Чтобы облегчить этот переход и предоставить больше гибкости, недавно было объявлено о продлении периода общей поддержки VMware vSphere 7.x.

Изначально vSphere 7.x должна была достичь окончания общей поддержки 2 апреля 2025 года. С этим объявлением общий период поддержки был продлен до 2 октября 2025 года.

Продление этой поддержки будет осуществляться с учетом следующих условий:

• В течение периода продленной общей поддержки Broadcom будет стремиться решать любые критические уязвимости в исходном коде, которые могут быть обнаружены. Однако возможность обновления компонентов с открытым исходным кодом, включая обновление до более новой версии пакета, зависит от различных факторов, включая, но не ограничиваясь доступностью патча в upstream и поддержкой версии пакета его разработчиками.
• Broadcom не гарантирует, что будут выпущены обновления для всех выявленных уязвимостей в исходном коде. Broadcom оставляет за собой право не включать исправления ошибок, уязвимостей безопасности или любое другое обслуживание компонентов с открытым исходным кодом, даже если они доступны в upstream.
• Последняя поддерживаемая версия Kubernetes на VCF 4.x (vCenter 7.x) будет минорной версией 1.28. Клиентам, использующим панель управления vSphere IaaS, следует планировать переход на vCenter 8.x до окончания общей поддержки Kubernetes v1.28 28 мая 2025 года. Начиная с vCenter 8.0 Update 3, служба TKG может быть обновлена независимо для поддержки новых версий Kubernetes.
• В vSphere 7.x включен встроенный реестр Harbor, который можно активировать на Supervisor кластере для хранения и обмена образами контейнеров. Поддержка этого встроенного реестра Harbor на vSphere 7.x не будет продлена в период продленной общей поддержки. Клиенты, использующие встроенный реестр Harbor, могут выбрать один из следующих вариантов:
  • Рассмотреть возможность миграции на внешний частный реестр контейнеров на продленный период.
  • Обновиться до последней версии vSphere 8.x и перейти на использование службы Harbor Supervisor.

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

vSphere GPU Monitoring Fling предоставляет метрики GPU на уровне кластера в VMware vSphere, что позволяет максимально эффективно использовать дорогостоящее оборудование. Он совместим с vSphere версий 7 и 8. Также функционал утилиты также доступен в виде основного патча vCenter 8.0 Update 2 для тех, кто использует более новые версии платформы (то есть, Fling не требуется!). Скачайте плагин здесь и поделитесь своим мнением в разделе Threads на портале community.broadcom.com или по электронной почте vspheregpu.monitoring@broadcom.com.

Пользователям нужно провести установку плагина для объекта Datacenter, после чего они смогут видеть сводные метрики своих GPU для кластеров в этом датацентре. В представлении датацентра пользователь может нажать на «View Details», чтобы увидеть более подробную информацию о распределении и потреблении GPU, а также о типе совместного использования GPU.

Наконец, температура также является важной метрикой для отслеживания, так как долговечность и производительность GPU значительно снижаются, если они слишком долго работают при высокой температуре. Этот Fling также включает и мониторинг температуры:

В рамках функционала Configuration Profiles платформы VMware vSphere вы можете создать пользовательское определение аларма, который будет срабатывать, когда один или несколько хостов в кластере не соответствуют заданной конфигурации. Определение аларма можно создать на уровне vCenter или кластера (а также на уровнях папок и объекта datacenter). Для упрощения можно создать одно определение аларма на уровне vCenter, чтобы одно и то же определение применялось ко всем кластерам...

Недавно мы писали о новых возможностях продукта VMware NSX 4.2, который стал доступен одновременно с релизом платформы VMware Cloud Foundation 5.2. В состав этого комплексного решения также вошло и средство VMware Aria Operations 8.18 для управления и мониторинга виртуального датацентра. Напомним также, что о версии Aria Operations 8.16 мы писали вот тут.

Удаленные коллекторы

VMware Aria Operations 8.14 был последним релизом, поддерживающим удаленные коллекторы. В версиях 8.16 и позднее обновления невозможны при наличии удаленных коллекторов. Для обновления необходимо заменить все удаленные коллекторы на облачные прокси. Это изменение улучшит сбор данных и упростит управление.

Устаревание XML в REST API

В следующем крупном релизе VMware Aria Operations поддержка XML в новых API и новых функциях существующих API будет прекращена. Для обмена данными рекомендуется использовать JSON, хотя текущие API продолжат поддерживать XML.

Поддержка облачных платформ и новых интеграций

Поддержка интеграций с облачными платформами Amazon Web Services, Microsoft Azure, Oracle Cloud VMware Solution и Google Cloud Platform будет доступна только через Marketplace. Важно обновить адаптер Google Cloud Platform до версии 8.18 сразу после обновления кластера, чтобы избежать потери данных.

Улучшенная навигация и управление

Введено новое меню навигации, ориентированное на выполнение задач, и средства для управления стеком VMware Cloud Foundation, включая обновление сертификатов, контроль конфигураций и диагностику. На вкладке Overview на главной странице представлены возможности управления и мониторинга VMware Cloud Foundation.

Диагностика и мониторинг

Теперь можно получать информацию о известных проблемах, влияющих на программное обеспечение VMware, и следить за состоянием ключевых случаев использования VMware Cloud Foundation, таких как vMotion, Snapshots и Workload Provisioning. Введены новые функции для контроля и устранения отклонений конфигураций vCenter.

Единый вход и управление лицензиями

Поддержка единого входа (SSO) для VMware vSphere Foundation с возможностью импорта пользователей и групп из провайдера SSO. Управление лицензиями VMware Cloud Foundation и VMware vSphere Foundation теперь доступно в VMware Aria Operations.

Управление сертификатами

Появилось централизованное управление сертификатами для всех компонентов VMware Cloud Foundation. Также есть и возможность мониторинга и получения информации о сертификатах инфраструктуры VMware Cloud Foundation.

Улучшение пользовательского опыта и отчетности

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

Снижение шума предупреждений и улучшение панели инструментов

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

Управление емкостью и стоимостью

Возможность переопределения метрик для расчета емкости и получения рекомендаций по оптимизации ресурсов. Управление затратами на лицензии VMware по ядрам, а также доступность метрик затрат для проектов и развертываний VMware Aria Automation.

Миграция Telegraf и усиление безопасности

Поддержка сохранения конфигурации плагинов Telegraf при переустановке и усиление безопасности за счет ограничения входящих сетевых подключений и предотвращения несанкционированного доступа.

Улучшения для vSAN и отчеты о соответствии

Поддержка кластера vSAN Max и улучшения виджетов для отображения информации о предках и потомках объектов. Обновления пакетов соответствия для CIS и DISA, поддержка новых версий ESXI и vSphere.

Эти новые возможности и улучшения делают VMware Aria Operations 8.18 более мощным и удобным инструментом для управления виртуальной инфраструктурой, повышая эффективность и безопасность работы с облачными и локальными ресурсами.

Подробнее обо всем этом вы можете почитать в Release Notes.

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

В последнем релизе платформ Cloud Foundation 5.2 и vSphere 8.0 Update 3 компания VMware представила новинку - поддержку возможностей устройств Dual DPU. Эта функция предназначена для значительного повышения производительности и обеспечения высокой доступности вашей сетевой инфраструктуры.

Почему поддержка Dual DPU важна

С ростом требований к производительности и надежности сетевой инфраструктуры, поддержка Dual DPU в VMware Cloud Foundation 5.2 дает клиентам надежное решение. Увеличивая пропускную способность вдвое и предоставляя гибкие настройки для производительности или высокой доступности, эта функция отвечает потребностям современных центров обработки данных и частных облачных сред. Независимо от того, стремитесь ли вы улучшить производительность сети или обеспечить резервную мощность для критически важных рабочих нагрузок, поддержка Dual DPU обеспечивает универсальность и надежность, необходимые вам.

Основные особенности поддержки Dual DPU

• Управление несколькими DPU на одном хосте

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

• Повышенная производительность и пропускная способность

Одним из самых значимых преимуществ поддержки Dual DPU является увеличение производительности. Поддерживая два DPU на одном хосте, VMware позволяет удвоить пропускную способность. Каждый DPU работает независимо, но вместе они обеспечивают 2-кратное увеличение пропускной способности.

Гибкость в использовании DPU

Новая конфигурация Dual DPU предлагает клиентам гибкость в использовании их DPU:

1. Производительность: оба DPU работают независимо, обеспечивая максимальную пропускную способность. Эта конфигурация идеальна для сред, где производительность критически важна, так как она полностью использует увеличенную полосу пропускания.
2. Высокая доступность: Клиенты могут настроить DPU в состоянии Active-Standby для повышения отказоустойчивости. В этом режиме, если активный DPU выходит из строя, весь трафик бесшовно переключается на резервный DPU, обеспечивая непрерывность обслуживания. Эта конфигурация идеально подходит для критически важных приложений, где время бесперебойной работы имеет первостепенное значение.

Поддержка VMware vSphere Lifecycle Manager

В VMware vSphere 8 Update 3, vSphere Lifecycle Manager (vLCM) включает поддержку конфигураций с двумя DPU. Как и в случае с одиночными DPU, vLCM будет обеспечивать обновление и поддержание в актуальном состоянии версий ESXi для обоих модулей DPU. Эта интегрированная поддержка упрощает управление жизненным циклом и обеспечивает согласованность в вашей инфраструктуре.