Компания VMware обновила свои основные настольные платформы виртуализации, выпустив финальные версии VMware Fusion 12.2 и VMware Workstation 16.2. Напомним, что о прошлой мажорной версии Fusion 12 мы писали вот тут, а о Workstation 16 - вот тут.

Давайте посмотрим, что нового появилось в этих небольших обновлениях.

Итак, в VMware Fusion 12.2 появились следующие фичи:

1. Плавный переход к полной поддержке Windows 11

Пока полноценной поддержки Windows 11 еще нет, но технически Fusion уже полностью готова исполнять эту ОС в виртуальной машине, поэтому соответствующий тип ОС при выборе теперь называется "Windows 10 and Later".

Теперь на Intel-маках Windows 11 будет полноценно работать с VMware Tools 11.3.5, а также при установке ОС будут пройдены все необходимые проверки совместимости касательно минимальных требований.

2. Экспериментальная поддержка виртуального модуля vTPM

VMware продолжает развивать виртуальный модуль шифрования vTPM, в котором в этом релизе представлена новая модель шифрования, намного меньше влияющая на производительность. Для использования этого экспериментального устройства просто добавьте в конфигурационный vmx-файл виртуальной машины на Fusion следующую строчку:

managedvm.AddVTPM="software"

Использование такого модуля позволяет не применять полное шифрование виртуальных машин, которое используют некоторые пользователи, и которое очень сильно влияет на производительность.

3. Работа над поддержкой архитектуры Apple Silicon

Об этом мы подробно писали в мае этого года. VMware по-прежнему ведет работу над Public Tech Preview, который умеет исполнять ОС Linux и BSD aarch64. Все больше дистрибутивов nix-систем включают в себя Open VM Tools и ядро Linux 5.14 kernel, которые могут работать в виртуальных машинах на базе аппаратной платформы Apple Silicon.

4. macOS 10.15 Catalina больше не поддерживается

Теперь нужно использовать macOS, начиная с версии 11.0 (Big Sur).

Для обновления продукта просто выберите "Check for Updates" в меню VMware Fusion, либо скачайте новую версию по этой ссылке.

В VMware Workstation 16.2 появились следующие возможности:

1. Плавный переход к полной поддержке Windows 11

Пока полноценной поддержки Windows 11 еще нет, но технически Workstation уже полностью готова исполнять эту ОС в виртуальной машине (с точки зрения Secure Boot, vTPM, минимальных требований CPU/RAM), поэтому соответствующий тип ОС при выборе теперь называется "Windows 10 and Later".

В качестве хостовой системы Windows 11 работает сейчас так же хорошо, как она работала и с прошлой версией - Windows 10.

2. Экспериментальная поддержка виртуального модуля vTPM

VMware продолжает развивать виртуальный модуль шифрования vTPM, в котором в этом релизе представлена новая модель шифрования, намного меньше влияющая на производительность. Для использования этого экспериментального устройства просто добавьте в конфигурационный vmx-файл виртуальной машины на Workstation следующую строчку:

managedvm.AddVTPM="software"

Использование такого модуля позволяет не применять полное шифрование виртуальных машин, которое используют некоторые пользователи, и которое очень сильно влияет на производительность.

3. Убрана функция "Shared VM"

Эту возможность анонсировали больше года назад, она позволяла расшарить виртуальную машину через сеть, как будто она работает на хосте ESXi. Однако ввиду появляющихся артефактов в UI VMware пока убрала поддержку этой фичи (ВМ, настроенные на авто-старт в этом режиме также не будут работать после этого обновления).

4. Поддержка рендера Vulkan для модулей Intel, AMD и NVIDIA GPU на платформе Linux

Workstation 16.2.0 Pro поддерживает рендер Vulkan в ОС Linux на базе карточек Intel, NVIDIA и AMD. Рендер Vulkan поддерживает движок Direct3D 11 (и более ранние), а также OpenGL 4.1 (и более ранние) в гостевой ОС. Поддержка этого рендера ограничена следующими GPU:

• Intel Skylake и более поздние (например, Kaby Lake и Ice Lake)
• AMD RDNA/NAVI14 и более поздние (нужно использовать драйвер AMDVLK)
• Nvidia Turing и более поздние (например, серия RTX) - для более ранних Workstation будет использовать legacy OpenGL renderer.

Для обновления продукта просто выберите "Check for Updates" в меню VMware Workstation, либо скачайте новую версию по этой ссылке.

Во время онлайн-конференции VMworld 2021 компания VMware, как и каждый год, рассказывала о новых продуктах и технологиях (см. наши статьи тут). Одним из неожиданно интересных анонсов стало объявление о доступности бета-версии платформы в виртуальной реальности Workspace ONE XR Hub. Эта платформа позволяет проводить обучение в VR-среде по продуктам инфраструктуры VMware, а также полноценно работать в этой среде в ее продуктах.

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

Платформа XR Hub полностью поддерживает решение Workspace ONE Access для аутентификации пользователей и Workspace ONE UEM для расширенного управления конечными устройствами.

На данный момент там реализованы следующие возможности:

• Поддержка нескольких VR-платформ (Pico, Oculus, HTC)
• Кастомизируемый режим Kiosk mode
• Защищенная процедура логина в корпоративную учетную запись через Workspace ONE Access
• Многофакторная аутентификация, условный доступ и single sign-on (через компонент Workspace ONE Tunnel)
• Check-in/check-out общих устройств через интеграцию с Workspace ONE UEM
• Унифицированный каталог приложений в VR
• Возможность запуска нативных VR-приложений и контента
• Запуск облачных стриминговых приложений NVIDIA CloudXR
• Запуск приложений WebXR
• Единый доступ (SSO) в службы Web, SaaS и VDI (службы VMware Horizon)
• Кастомизация самого XR Hub и возможность создать свой туториал для пользователей

Также VMware продолжает тестировать последние VR-устройства для службы Workspace ONE Assist (техподдержка в реальном времени). Этими устройствами можно управлять через платформу Android Enterprise, а также Workspace ONE для устройств Work Managed AOSP.

На данный момент платформа XR Hub поддерживает следующие модели устройств:

• HTC Vive Focus Plus
• Pico Neo 2
• Pico Neo 2 Eye
• Pico Neo 3 – но официально пока Workspace ONE UEM не поддерживается
• Pico G2 4K
• Oculus Quest 2 (Oculus for Business, firmware version 28) – пока еще официально не поддерживаеся для Workspace ONE UEM

Вот эти два типа устройств еще не поддерживаются, но планируется их добавить в самое ближайшее время:

• HTC VIVE Focus 3 – также не поддерживается для Workspace ONE UEM
• Microsoft Windows-совместимые VR-устройства

Для пользователей можно сделать режим kiosk mode, в котором они увидят только те приложения и контент, которые вы настроите. Далее они запускают их в стиле point-and-click.

Пользователь может одновременно работать с несколькими типами приложений - Native VR приложения, веб-приложения WebXR, стриминговые CloudXR-приложения и другие поддерживаемые VR-технологии. Все эти окошки можно выравнивать, перемещать и изменять их размер:

Само виртуальное окружение поддерживает как 3DoF-устройства для картинки в 360-градусов (отслеживание только вращения головы), так 6DoF-устройства (отслеживание еще и перемещения) с поддержкой ходьбы по сцене. С точки зрения кастомизации, можно менять бэкграунд, офисное окружение и логотип компании (все ссылки на ассеты находятся в одном конфигурационном файле).

Управление платформой XR Hub и пользовательскими устройствами происходит централизованно через Workspace ONE UEM. Ну а с помощью Workspace ONE Access можно полностью удаленно управлять всей инфраструктурой. Администратор с помощью Workspace ONE Assist может подключиться к очкам пользователя и видеть то же самое, что он.

Workspace ONE XR Hub сейчас доступен в бета-версии на площадке VMware End-User Computing Beta Community Site.

В начале сентября компания VMware объявила о том, что ее флагманская платформа виртуализации VMware ESXi больше не будет поддерживаться для Apple 2019 Mac Pro 7,1 в целях виртуализации Mac OS систем. Причина проста - Apple осуществляет переход на архитектуру Apple Silicon, а во времена Covid затруднено технологическое партнерство между большими компаниями в этой сфере.

Недавно мы писали, кстати, о том, что VMware работает над поддержкой продукта Fusion для Apple MacBook, но и там есть свои сложности. Новый гипервизор VMware ESXi ARM Edition еще находится на ранней стадии разработки, на его доведение до производственной версии могут уйти годы.

Поэтому на сегодняшний день VMware сворачивает сертификацию поддержку Apple 2019 Mac Pro 7,1 для ESXi, но пока оставляет ее для следующих платформ:

• Apple 2018 Mac Mini 8,1
• Apple Mac Pro 6,1

Дункан Эппинг написал интересную заметку о том, как работают Storage Rules для политик хранения виртуальных машин в кластерах VMware vSAN (VM Storage Policies).

В большой инфраструктуре или, например, в топологии HCI Mesh часто встречается такая ситуация, когда некоторые кластеры построены на базе гибридных хостов (SSD+HDD), а некоторые на базе All-Flash оборудования. Также в зависимости от типа железа, эти кластеры могут предоставлять различные сервисы (например, шифрование или дудпликацию), которые могут использовать виртуальные машины.

Когда вы создаете VM Storage Policy в решении VMware vSAN, то, начиная с vSAN 7.0 U2, вы можете задать Storage Rules для данной политики на отдельной вкладке:

Эти настройки влияют вот на что: когда вы назначаете политику хранения виртуальной машине, у которой, например, выбран пункт "data-at-rest encryption" в качестве поддерживаемых сервисов хранилищ, то в качестве совместимых будут показаны только те хранилища, у которых реально предоставляется этот сервис со стороны оборудования. То есть эта вкладка нужна для того, чтобы обеспечить исполнение требований со стороны железа по сервисам перечисленным здесь (а именно: шифрование, компрессия, компрессия+дедупликация, размещение на гибридном/All-Flash хосте) для виртуальных машин, которым назначается политика.

То есть, Storage Rules - это поддержка тех сервисов, которые должны быть уже включены на ваших датасторах. Они работают именно на уровне vSAN Datastore и не применяются к сервисам данных (data services) на базе виртуальной машины или VMDK-дисков.

Недавно мы писали о новом продукте StarWind SAN & NAS от лидера в сфере программно-аппаратных хранилищ под виртуализацию - компании StarWind. Он предназначен для создания программных хранилищ на основе серверов с установленным там гипервизором.

Ну а на днях вышло еще одно новое решение - StarWind Backup Appliance. Оно, как можно догадаться, предназначено для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе хранилища NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Теперь бэкап на такое хранилище можно делать в любое время и без влияния на работу приложений и служб. За счет использования этого комплекса время резервного копирования у вас снизится минимум в 2 раза.

Более того, в случае сбоя вы сможете мгновенно восстановить виртуальные машины и файлы напрямую из резервной копии, обеспечив наилучшие показатели RPO и RTO по сравнению с традиционными решениями.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

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

Важный момент, который стоит отметить - продукт Backup Appliance от StarWind поддерживается со стороны ProActive Premium Support, а значит, что ваша инфраструктура резервного копирования будет работать 24x7, даже когда вы в отпуске или спите.

Естественно, данные, находящиеся на хранилище резервных копий, надежно защищены с помощью технологий RAID и полностью отделены от сервисов, непосредственно реализующих резервное копирование. Ну а приятный бонус - это то, что вы можете выбрать один из следующих гипервизоров на модуле StarWind BA:

• Microsoft Hyper-V версий 2016, 2019 или 2022
• VMware vSphere версий 6.5, 6.7 или 7.0

На данный момент доступны 2 модели Backup Appliance (BA 30 и BA 60):

Как мы видим, обе модели представляют собой одноюнитовые серверы с 30 или 60 ТБ емкости (это полезная емкость после создания RAID) и 64 ГБ оперативной памяти на борту.

В качестве протоколов доступа к данным поддерживаются следующие:

• iSCSI
• SMB3
• NFSv4.1
• NVMe-oF

Ну и главное - в качестве ПО для резервного копирования используется лидирующий в отрасли продукт Veeam Backup and Replication V10 и V11. Тут можно быть спокойным - он работает надежно и быстро. В качестве системы мониторинга и отчетности можно использовать решение Veeam ONE.

Больше информации о решении StarWind Backup Appliance можно получить на этой странице. Живое демо продукта вы можете запросить вот тут.

В прошлом году, в рамках рассказа об анонсах конференции VMworld 2020, мы писали об интересной инициативе VMware - Project Monterey. Вендоры аппаратного обеспечения пытаются сделать высвобождение некоторых функций CPU, передав их соответствующим компонентам сервера (модуль vGPU, сетевая карта с поддержкой offload-функций и т.п.), максимально изолировав их в рамках необходимостей. Но вся эта новая аппаратная архитектура не будет хорошо работать без изменений в программной платформе.

Project Monterey - это и есть переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF. За счет технологии SmartNIC инфраструктура VCF будет поддерживать операционные системы и приложения, исполняемые на "голом железе" (то есть без гипервизора). В данном решении будет три основных момента:

• Поддержка перенесения сложных сетевых функций на аппаратный уровень, что увеличит пропускную способность и уменьшит задержки (latency).
• Унифицированные операции для всех приложений, включая bare-metal операционные системы.
• Модель безопасности Zero-trust security - обеспечение изоляции приложений без падения производительности.

По-сути, Monterey - это продолжение развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, только с аппаратной точки зрения для инфраструктуры VMware Cloud Foundation (VCF).

После анонса этой инициативы в прошлом году, компания VMware расширила партнерства в этом плане с вендорами аппаратного обеспечения (Intel, NVIDIA и Pensando), а также OEM-производителями серверов (Dell Technologies, HPE и Lenovo), и теперь запускает программу Early Access Program этой инициативы для крупных корпоративных клиентов.

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

Обкатка всех аспектов программы займет 4-6 недель, ну и, само собой, приличное число человеко-часов ваших инженеров и администраторов. Если вы чувствуете в себе силы и возможности присоединиться к Early Access Program для Project Monterey, свяжитесь с VMware Sales Team напрямую или через вашего системного интегратора.

Компания VMware обновила пакет драйверов Community NVMe Driver for ESXi до версии 1.1 на сайте проекта VMware Labs. Эти драйверы были выпущены в начале года, а сейчас вышло их обновление с поддержкой VMware ESXi 7.0.

Данный Fling представляет собой пакет нативных драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах.

Драйверы теперь поддерживают VMware ESXi 7.0 или более поздние версии гипервизора для NVMe-хранилищ не от Apple. Пока список поддерживаемых устройств такой:

Для хранилищ Apple SSD пока поддерживается только ESXi 6.7 до версии Patch 03 (Build 16713306). Более новые версии гипервизора с NVMe-устройствами Apple, к сожалению, не работают. Пока драйверы поддерживают Apple 2018 Intel Mac Mini 8.1 и Apple 2019 Intel Mac Pro 7.1, причем подключение портов Thunderbolt 3 не поддерживется (ESXi может выпасть в PSOD).

Драйверы поставляются в виде VIB-пакета, установить который можно командой:

Скачать Community NVMe Driver for ESXi 1.1 можно по этой ссылке.

На сайте проекта VMware Labs появилось обновление еще одной полезной штуки - Horizon Peripherals Intelligence 2.0. О первой версии этого средства мы писали осенью прошлого года вот тут, напомним, что оно предназначено для самодиагностики периферийных устройств пользователями решения VMware Horizon. C помощью данного средства можно проверить работоспособность и поддержку устройств как со стороны конечных пользователей, так и администраторов платформы Horizon.

Напомним, что утилита Horizon Peripherals Intelligence служит для решения следующих задач:

• Публикация отчета о диагностике устройств по запросу конечных пользователей
• Обслуживание спектра пользовательских устройств в рамках поддерживаемых со стороны официального списка совместимости device compatibility matrix
• Возможность получения администратором доступа к метаданным устройств в каждой категории, где он может загружать, изменять и удалять метаданные, таким образом обслуживая матрицу поддерживаемых устройств на машинах пользователей

Что нового появилось в версии 2.0:

• Добавлена поддержа клиентов Linux на базе Ubuntu 18.04 , 20.04 и Redhat 8.3, 8.4
• Добавлена поддержка смарт-карт, USB-мыши и клавиатуры для Windows-клиентов
• Добавлена поддержка USB-дисков, сканнеров, принтеров, камер, USB-мыши и клавиатуры для Linux-клиентов
• Добавлена поддержка агента Horizon agent для последних версий Windows 10 21H1 и Windows Server 2022
• Обновлена таблица Device Matrix - теперь она соответствует разделу VMware validated peripherals на VMware Marketplace

Скачать Horizon Peripherals Intelligence 2.0 можно по этой ссылке.

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

А сделано тут было 3 важных вещи:

• Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
• Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere  
• Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA

Давайте посмотрим на все это несколько подробнее:

1. NVIDIA AI Enterprise Suite сертифицирован для vSphere

Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.

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

2. Поддержка последнего поколения NVIDIA GPU

Последнее поколение графических карт для ML-задач, Ampere Series A100 GPU от NVIDIA, имеет поддержку Multi-Instance GPU (MIG) и работает на платформе vSphere 7 Update 2.

Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.

Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.

При выборе профиля vGPU на хосте с карточкой A100 можно выбрать объем framebuffer memory (то есть памяти GPU) для виртуальной машины (это число в гигабайтах перед буквой c, в данном случае 5 ГБ):

Для режима MIG виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).

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

Первая цифра сразу после a100 - это число слайсов (slices), которые выделяются данной ВМ. Один слайс содержит 14 процессоров SM, которые будут использоваться только под эту нагрузку. Число доступных слайсов зависит от модели графической карты и числа ядер GPU на ней. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.

Например, доступные 8 memory (framebuffers) слотов и 7 compute (slices) слотов с помощью профилей можно разбить в какой угодно комбинации по виртуальным машинам на хосте (необязательно разбивать на равные части):

3. Улучшения GPUDirect RDMA

Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.

Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.

Режим ATS включен по умолчанию. Для его работы карточки GPU и сетевой адаптер должны быть назначены одной ВМ. GPU должен быть в режиме Passthrough или vGPU (эта поддержка появилась только в vSphere 7 U2). Для сетевой карты должен быть настроен проброс функций SR-IOV к данной ВМ.

Более подробно обо всем этом вы можете прочитать на ресурсах VMware и NVIDIA.

На сайте проекта VMware Labs вышло очередное обновление - VMware ESXi Arm Edition версии 1.4. Напомним, что эта специальная версия версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О версии 1.3 мы писали в начале апреля вот тут.

Давайте посмотрим, что нового в июньской версии VMware ESXi ARM Edition 1.4:

• Улучшенная технология виртуализации PMU (Performance Monitoring Unit)
• Исправлены проблемы с виртуальным устройством AHCI для некоторых ОС ACPI
• Улучшена работа с обработкой времени
• Экспериментальная поддержка NVIDIA Tegra Xavier AGX и NVIDIA Tegra Xavier NX (PCIe, USB, NVMe, SATA). Это что-то типа вот такой штуки:

• Экспериментальная поддержка серверов 2P Ampere на базе Altra. Это вот такие штуки:

• Увеличенная производительность виртуальных машин для мультисокетных серверов на базе ARM
• Исправлены проблемы с виртуальным NVMe в UEFI для некоторых ОС
• Улучшена виртуализация контроллера прерываний
• Улучшена общая производительность гипервизора и техник виртуализации в целом
• Улучшена совместимость с ядрами Linux для новых ОС
• Исправлены проблемы стабильности USB-устройств, особенно для сетевых адаптеров на базе RTL8153 для платформ Raspberry Pi и Tegra Xavier
• Обновлена документация для ESXi-Arm Fling, Raspberry Pi, Ampere Altra, NVIDIA Xavier AGX и NVIDIA Xavier NX (опции доступны в комбобоксе при скачивании продукта)

Загрузить VMware ESXi ARM Edition 1.4 и документацию можно по этой ссылке.

На сайте проекта VMware Labs обновился нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Эта версия (1.8) драйверов сделана специально для VMware vSphere 7.0 Update 2. При скачивании драйверов убедитесь, что вы выбрали вариант для нужной версии ESXi:

Что нового появилось в драйверах:

• Полная поддержка ESXi 7.0 Update 2
• По умолчанию отключено сканирование шины USB (расширенная настройка usbBusFullScanOnBootEnabled=0) - это позволяет предотвратить розовый экран смерти (PSOD) для пользователей, использующих несколько сетевых карт на USB-портах

Таблица поддерживаемых чипсетов и адаптеров на сегодняшний день выглядит так:

Загрузить USB Network Native Driver for ESXi для VMware vSphere 7.0 Update 1 и Update 2 можно по этой ссылке.

Многие из вас, наверняка, знакомы с инфраструктурой публичного облака VMware Cloud on AWS, которая была анонсирована еще летом 2017 года. Это все та же платформа VMware vSphere, все те же серверы VMware ESXi, но стоят они физически в датацентрах Amazon. Все это управляется совершенно нативно для инфраструктуры vSphere, туда же включаются и решение...

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

Оказывается, в весеннем обновлении VMware vSphere 7 Update 2 появилась поддержка нового механизма Precision Time for Windows. Раньше для почти всех задач в виртуальных машинах использовалась связка NTP+Active Directory, которая работает отлично в подавляющем большинстве случаев. NTP обеспечивает точность на уровне миллисекунд, а если нужна какая-то большая точность (например, финансовые приложения), то тут можно использовать специальное оборудование с поддержкой PTP (Precision Time Protocol).

VMware решила сделать еще одно улучшение для пользователей, которым требуется повышенная чувствительность служб точного времени. Теперь в vSphere 7 Update 2 есть поддержка Precision Time for Windows - механизма, который улучшает точность синхронизации времени в ОС Windows.

Сервис Windows Time Service (W32Time) - это служба, которая опирается на NTP и предоставляет клиентам ОС информацию о точном времени. В основном она нужна для синхронизации времени между хостами в Active Directory, но уже вышла за рамки этих задач и может быть использована приложениями. Архитектура W32Time построена на базе плагинов, что означает, что DLL-библиотека может быть зарегистрирована как провайдер служб точного времени. Это могут быть как чисто программные решения, так и комплексные системы со специальным оборудованием с поддержкой PTP-протокола.

API-интерфейсы для разработки таких плагинов находятся в открытом доступе, каждый может написать свой собственный. Вот и VMware разработала свой VMware Time Provider (vmwTimeProvider), который поставляется вместе с VMware Tools для ВМ на базе Windows. Он получает время от виртуального устройства Precision Clock (оно появилось еще в vSphere 7.0) и передает его на сторону W32Time по закрытому и быстрому каналу (на базе технологии паравиртуализации), минуя сетевой стек.

vmwTimeProvider - это плагин, работающий в пространстве user-space. По идее такое устройство требовало бы собственный драйвер, но у VMware есть собственный паравиртуализованный интерфейс, который использует преимущества технологии Memory-mapped I/O (MMIO), оптимизированной под операции чтения.

Устройство Precision Clock получает время от ядра гипервизора (VMkernel), одним из источников является устройство HyperClock, поставляющее в ядро системное время. Таким образом, если вы настроите VMkernel и HyperClock на получение времени через Precision Time Protocol (PTP), то устройство Precision Clock будет передавать его в виртуальные машины с большой точностью.

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

На сайте проекта VMware Labs вышло обновление VMware ESXi Arm Edition 1.3. Напомним, что эта версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлом релизе этой платформы мы писали вот тут.

Давайте посмотрим, что нового в ESXi для ARM:

• Улучшенная аппаратная совместимость (множество исправлений ошибок и улучшений по поддержке железа).
• Добавлена экспериментальная поддержка архитектуры Ampere Altra (только для односокетных систем (подробнее тут).
• Поддержка ACPI для виртуальных машин.
• Поддержка загрузки через NVMe и PVSCSI в EFI.
• Добавлен воркэраунд для загрузки с ISO для некоторых ARM-серверов.
• Пофикшена проблема с падением современных ОС при работе на системах на базе Neoverse N1.
• Улучшен механизм виртуализации контроллера прерываний для гостевых ОС.
• Улучшены средства работы с виртуальными PMU.
• Улучена поддержка big endian.

Скачать установочный образ VMware ESXi Arm Edition 1.3 можно по этой ссылке. Помните, что апгрейд с предыдущей версии не поддерживается - надо устанавливать заново.

Небольшое обзорное видео установки ESXi Arm Edition:

Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.

Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.

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

Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.

Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:

• 370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
• Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)

То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:

370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM

Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.

Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.

Общее правило развертывания таких хранилищ таково:

• Под VDO: аппаратный или программный RAID (LVM или mdraid)
• Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA

Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).

Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:

После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.

Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):

Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.

Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:

И пробросить его напрямую в виртуальную машину StarWind:

После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:

Рекомендации тут такие:

После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:

vdo create –activate=enabled –deduplication=enabled –compression=disabled –emulate512=enabled –indexMem=%size% –vdoLogicalSize=%size% –device=%yourdevice% -n=%name%

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

После создания это устройство надо отформатировать в XFS со следующими параметрами:

Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi

В значение 512:

Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.

На сайте проекта VMware Labs появилась очередная полезная штука - Community Networking Driver for ESXi. Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe.

Драйверы можно установить для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройство выглядит так:

Установить драйвер можно с помощью команды:

esxcli software vib install -d /path/to/the offline bundle zip

После этого нужно обязательно перезагрузить ваш ESXi, до перезагрузки сетевой адаптер работать не будет.

Также если вы хотите использовать драйвер для Intel NUC 11, вам нужно будет встроить его в образ ESXi (Image Profile). Для этого можно использовать графический интерфейс Image Builder в vSphere Client, либо Image Builder CLI на базе PowerCLI.

Скачать пакет драйверов Community Networking Driver for ESXi можно по этой ссылке.

На сайте VMware Labs появился интересный инструмент Virtualized High Performance Computing Toolkit, который может оказаться полезен компаниям, использующим VMware vSphere для организации высокопроизводительных вычислений (High Performance Computing, HPC). Такие комплексные вычислительные задачи, как правило, вовлекают параллельные вычисления, аппаратное ускорение (такое как GPU и FPGA), а также используют высокоскоростные каналы, такие как RDMA.

Все это требует определенных конфигураций VMware vSphere, для настройки которых и нужно данное средство. С помощью него, используя vSphere API, можно дать администраторам инструменты по сопровождению задач HPC, таких как клонирование ВМ, настройка Latency Sensitivity, сайзинг виртуальных машин по CPU и памяти и многое другое.

Основные возможности тулкита:

• Настройка устройств PCIe в режиме DirectPath I/O, таких как GPGPU, FPGA и RDMA
• Настройка NVIDIA vGPU
• Настройка RDMA SR-IOV (Single Root I/O Virtualization)
• Настройка PVRDMA (Paravirtualized RDMA)
• Простое создание и уничтожение кластеров HPC с помощью файлов конфигураций
• Выполнение задач vSphere, таких как клонирование, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, обычного и распределенного виртуального коммутатора, сетевых адаптеров и конфигураций

Например, клонирование 4 виртуальных машин с заданными кастомизациями CPU и памяти, а также добавлением NVIDIA vGPU с профилем grid_p100-4q выглядит так:

vhpc_toolkit> clone --template vhpc_clone --datacenter HPC_Datacenter --cluster COMPUTE_GPU_Cluster --datastore COMPUTE01_vsanDatastore --memory 8 --cpu 8 –-file VM-file
vhpc_toolkit> vgpu --add --profile grid_p100-4q --file VM-file

Для использования тулкита вам понадобится ОС Linux или Mac. Скачать Virtualized High Performance Computing Toolkit можно по этой ссылке.

Это статья нашего спонсора - компании ИТ-ГРАД, предлагающей услуги аренды виртуальных машин из облака. Изначально концепцию подводных ЦОД предложила Microsoft в рамках Project Natick и успешно эксплуатировала дата-центр с 12 стойками у берегов Шотландии в течение двух лет. Подводные ЦОД используют проточную морскую воду для охлаждения, что может на 30% снизить энергозатраты по сравнению с традиционными способами...

Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.

Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.

Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.

У него получилась вот такая картина:

В день у него получилось:

• 300 ГБ на диски Caching tier
• 20 ГБ на диски Capacity tier

Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.

Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.

Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.

Ну а вот параметры TBW, например, для устройств Samsung:

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

Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

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

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:

Многие администраторы VMware vSphere знают, что у этой платформы есть режим совместимости Enhanced vMotion Compatibility (EVC), который позволяет привести хосты с процессорами (CPU) разных моделей к единому базовому уровню по набору возможностей CPU Feature Set, чтобы обеспечить свободную миграцию vMotion между хостами ESXi. Делается это за счет маскирования некоторых наборов инструкций процессора через CPUID.

Сейчас многие приложения (например, реализующие техники Machine Learning / Deep Learning) используют ресурсы графического адаптера (GPU), поскольку их многоядерная архитектура отлично подходит для такого рода задач.

В VMware vSphere 7, вместе с соответствующей версией VM Hardware, были существенно улучшены функции работы для режима vSGA, который предназначен для совместного использования графического адаптера несколькими виртуальными машинами хоста.

Поэтому в VMware vSphere 7 Update 1 сделали еще одно полезное улучшение по этой теме - режим Enhanced vMotion Capabilities для графических процессоров GPU, который является частью EVC, настраиваемого в vSphere Client:

Графический режим VMFeatures включает в себя поддерживаемые возможности для 3D-приложений, включая библиотеки D3D 10.0/ Open Gl 3.3, D3D 10.1 / Open GL 3.3 и D3D 11.0 / Open GL 4.1. Пока приведение к базовому уровню доступно только до D3D 10.1 / OpenGL 3.3 (версии 11.0 и 4.1, соответственно, будут поддерживаться в следующих релизах).

Когда хост ESXi включается в кластер, где включена EVC for Graphics, сервер vCenter проверяет, что он поддерживает соответствующие версии библиотек. При этом можно добавлять хосты разных версий - ESXi 6.5, 6.7 и 7.0, благодаря поддержке D3D 10.0 и OpenGL 3.3.

Как и для обычного EVC, пользователи могут включить EVC for Graphics на уровне отдельных ВМ. В этом случае перед тем, как включить виртуальную машину на хосте ESXi, сервер vCenter убеждается, что он поддерживает соответствующие библиотеки. Такая настройка полезна при возможной миграции виртуальной машины между датацентрами или в публичное облако.

Если у вас включена EVC for Graphics, то перед миграциями vMotion также будут проводиться нужные предпроверки по поддержке графических функций GPU со стороны видеоадаптера целевого хоста.

На сайте проекта VMware Labs появилось очередное обновление - утилита Horizon Peripherals Intelligence, предназначенная для самодиагностики периферийных устройств пользователями решения VMware Horizon. C помощью данного средства можно проверить работоспособность и поддержку устройств как со стороны конечных пользователей, так и администраторов платформы Horizon.

На данный момент поддерживаются следующие устройства:

• USB-хранилища
• USB-принтеры
• USB-сканеры
• Камеры

В будущем будут также добавлены новые виды устройств. Сама же утилита Horizon Peripherals Intelligence служит для решения следующих задач:

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

• Обслуживать спектр пользовательских устройств в рамках поддерживаемых со стороны официального списка совместимости device compatibility matrix. Пользовательские окружения разные (версия ОС, версия агента и т.п.) - поэтому этот момент сложно отслеживать вручную. По запросу пользователя выводится отчет о поддерживаемых устройствах в его окружении.

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

Для начала работы вам потребуется:

• VMware Horizon 7.x или более поздняя версия
• Client OS - Windows 10
• Agent OS - Windows 10, 2016, 2019
• Виртуальный модуль построен на базе VMware Photon OS 3.0, что требует ESXi 6.5 или более поздней версии

Скачать Horizon Peripherals Intelligence можно по этой ссылке.

Какое-то время назад мы писали о первой версии платформы виртуализации VMware ESXi для архитектуры процессоров ARM, которая получила название ESXi-Arm или ESXi Arm Edition. Также мы рассказывали об установке этой платформы на компьютер Raspberry Pi на базе процессора ARM.

Недавно на сайте проекта VMware Labs появилось обновление этой платформы до версии 1.1. Эту версию нужно обязательно ставить заново, потому что обновление с версии 1.0 не поддерживется.

Давайте посмотрим, что там появилось нового:

• Исправлена критическая ошибка, вызывавшая розовый экран смерти (PSOD) при добавлении к коммутатору VDS (см. тут)
• Поддержка аппаратной платформы Arm N1 SDP
• Поддержка виртуальных машин на процессорах Neoverse N1 CPU
• Улучшения стабильности работы на платформах LS1046A и LX2160A
• Исправления ошибок для отображения некорректного использования CPU на vCenter/DRS
• Исправление ошибки с аварийным завершением виртуальной машины при полной заполненности хранилища
• Исправление ошибки с поддержка устройств non-coherent DMA
• Теперь можно ставить гипервизор имея в распоряжении 4% от 4 ГБ памяти вместо 3.125 (критично для некоторых аппаратных платформ)
• Улучшения работы с последовательным портом
• Обновление документации (больше информации об iSCSI, документы по платформам LS1046ARDB и Arm N1SDP, обновлен список поддерживаемых гостевых ОС)

Скачать VMware ESXi Arm Edition 1.1 можно по этой ссылке. Ну и бонусом несколько видео от Вильяма Лама по использованию этой платформы:

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

Недавно мы писали об анонсе Project Monterey на прошедшей конференции VMworld Online 2020. Это переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF. Но на этом новости не закончились.

На днях VMware выпустила еще одно важное средство на сайте проекта VMware Labs - модуль ESXi-Arm. Это, по-сути, издание VMware ESXi для компьютеров с 64-битными процессорами архитектуры ARM. Пока, конечно же, в режиме технологического превью, созданного в целях сбора обратной связи от пользователей.

История проекта такова - группа инженеров внутри VMware решила портировать ESXi с архитектуры x86 на ARM, после чего энтузиасты внутри компании поддерживали согласование нововведений в гипервизоре в рамках платформы x86 с версией для ARM. Теперь эта версия ESXi считается доведенной до ума, и она была выпущена публично:

На данный момент в экспериментальном режиме было протестировано следующее оборудование:

• Datacenter:
• Avantek Workstation (Ampere eMAG)
• Avantek Server (Ampere eMAG)
• Lenovo ThinkSystem HR330A (Ampere eMAG)
• Lenovo ThinkSystem HR350A (Ampere eMAG)
• Near Edge:
• SolidRun Honeycomb LX2
• Far Edge:
• Raspberry Pi 4b - 4GB or 8GB Model (8 ГБ очень рекомендуется, также для ESXi/VMFS очень желательно использовать USB 3.0)
• LS1046A-based NXP Freeway

Вы также можете управлять таким ESXi на архитектуре ARM с помощью обычного VMware vCenter 7.0 или более поздней версии.

Скачать VMware ESXi для ARM в виде загрузочного ISO-образа можно по этой ссылке. Документация доступна там же, правильный документ надо выбрать из комбобокса:

Также вот небольшое обзорное видео об установке ESXi на компьютер Raspberry Pi от Вильяма Лама:

Как вы знаете, на прошлой неделе компания VMware провела первую в истории онлайн-конференцию VMworld 2020 Online. Основные анонсы новых версий продуктов были сделаны еще до конференции, а VMware рассказывала, в основном, о новых технологиях и будущих продуктах для виртуального датацентра.

Одним из таких анонсов стала новость о разработке решения Project Monterey.

По заявлению VMware, Monterey - это продолжение развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, только с аппаратной точки зрения для инфраструктуры VMware Cloud Foundaton (VCF).

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

Поэтому вендоры аппаратного обеспечения пытаются сделать высвобождение некоторых функций CPU, передав их соответствующим компонентам сервера (модуль vGPU, сетевая карта с поддержкой offload-функций и т.п.), максимально изолировав их в рамках необходимостей. Но вся эта новая аппаратная архитектура не будет хорошо работать без изменений в программной платформе.

Project Monterey - это и есть переработка архитектуры VCF таким образом, чтобы появилась родная интеграция новых аппаратных возможностей и программных компонентов. Например, новая аппаратная технология SmartNIC позволяет обеспечить высокую производительность, безопасность по модели zero-trust и простую эксплуатацию в среде VCF.

Также за счет технологии SmartNIC инфраструктура VCF будет поддерживать операционные системы и приложения, исполняемые на "голом железе" (то есть без гипервизора). В данном решении будет три основных момента:

• Поддержка перенесения сложных сетевых функций на аппаратный уровень, что увеличит пропускную способность и уменьшит задержки (latency).
• Унифицированные операции для всех приложений, включая bare-metal операционные системы.
• Модель безопасности Zero-trust security - обеспечение изоляции приложений без падения производительности.

Вот так будет выглядеть сетевой адаптер сервера, поставляемый в партнерстве с вендорами оборудования:

Таким образом, это сетевая карта с обычным CPU, который занимается решением задач производительности и безопасности. Она будет состоять из следующих компонентов:

• Стандартный процессор общего назначения (general-purpose CPU) - позволяет исполнять часть кода прямо на сетевом адаптере (сервисы сети и хранилищ), что существенно увеличивает производительность (за счет уменьшения пути для операций ввода-вывода) и экономии циклов CPU сервера.
• Унифицированный процесс управления CPU сетевой карты, который предоставляет отдельный рабочий процесс, доступный из Lifecycle Manager.
• Возможность предоставления виртуальных устройств - SmartNIC может шарить на PCI-шине несколько виртуальных устройств, которые будут показываться гостевым ОС отдельными карточками.

Часть стандартной функциональности сервера и его CPU теперь переезжает на сетевую карту SmartNIC в рамках инфраструктуры VCF:

Тут есть следующие интересные моменты:

• ESXi on SmartNIC - да, теперь гипервизор будет работать на сетевой карте! Для этого VMware и делала порт ESXi для ARM-процессоров (помните анонсы 2018 года?), которые в основном и будут использоваться для устройств SmartNIC.
• 2 экземпляра ESXi на одном сервере - один на обычном CPU, а второй - на SmartNIC. Управлять ими можно как единым функциональным блоком, так и каждым гипервизором по отдельности.
• Сервисы сети и доступа к хранилищам - за счет этих сервисов повышается быстродействие и разгружается основной процессор сервера.
• SmartNIC ESXi теперь будет уметь управлять хостом ESXi, что упростит процедуры обслуживания жизненного цикла с помощью LCM.
• Двойной контроль - если основной гипервизор скомпрометирован, то отдельный SmartNIC ESXi будет продолжать предоставлять сервисы защиты, что улучшает защищенность инфраструктуры.
• Управление bare-metal операционными системами теперь будет происходить со стороны карточек SmartNIC, которые существенно упростят управление единой инфраструктурой датацентра.

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

Все это будет поддерживать кластеры Kubernetes и решение VCF with Tanzu, что расширит сферу применения SmartNIC для крупных инфраструктур, где ресурсы и сервисы необходимо выделять по требованию, а не планировать конфигурации серверов под конкретные приложения. Конечно же, все будет управляться не только через консоли, но и через API.

В итоге, вариантами использования SmartNIC станут:

• Сетевая производительность (передача сетевых функций на уровень адаптера) и безопасность (например, отдельный L4-7 фаервол на уровне сетевой карты).
• Улучшение сервисов датацентра - например, с помощью Project Monterey можно будет использовать offloaded-сервисы доступа к хранилищам, сжатие и т.п., что повысит производительность без создания единого домена отказа и падения производительности. Это повысит гибкость использования решения и даст возможность применения таких сервисов, как dynamic storage profiles (для управления емкостями и операциями ввода-вывода, IOPS) и удаленный доступ к хранилищам по требованию.
• Управление системами bare-metal - для тех, кто мечтал о единой консоли vSphere для физических и виртуальных систем.

Также все это сможет работать в гибридных облаках, как работают сейчас инфраструктуры VCF.

На данный момент главными аппаратными партнерами VMware в части технологии SmartNIC являются компании NVIDIA, Pensando и Intel. С точки зрения производителей серверов, первыми партнерами станут Dell Technologies, HPE и Lenovo. Этот список будет со временем расширен.

На прошедшем VMworld 2020 Online проекту Monterey были посвящены следующие сессии, которые вы можете найти тут:

Ждем!

Как многие из вас знают, у компании StarWind, выпускающей лучший продукт Virtual SAN для создания программных iSCSI хранилищ под виртуализацию, есть и программно-аппаратный комплекс HyperConverged Appliance (HCA). Чтобы управлять этим решением в контексте всей инфраструктуры, существует продукт StarWind Command Center, на который мы сегодня посмотрим.

Многие из вас знают, что в решении для организации отказоустойчивых кластеров хранилищ VMware vSAN есть функции дедупликации и сжатия данных (deduplication and compression, DD&C). С помощью этих функций можно более эффективно использовать ярус хранения данных виртуальных машин (Capacity Tier). О некоторых аспектах применения дедупликации и сжатия данных в vSAN мы рассказывали вот тут, а сегодня поговорим об их общем влиянии на производительность дисковой подсистемы.

Как знают администраторы vSAN, это решение использует двухъярусную архитектуру, создающую оптимальное соотношение цена/качество для хранилищ ВМ - на Cache Tier, собранном из дорогих SSD-дисков (быстро работающих на дисках), размещается Write Buffer и Read Cache, а на дешевых SSD/HDD-дисках - постоянные данные виртуальных машин.

Механизм DD&C работает так - если он включен, то как только из Cache Tier виртуальной машине отправляется квитанция о записи данных, то может начаться процесс дестейджинга данных на Capacity Tier, во время которого сам механизм и вступает в действие. Сначала с помощью механики дедупликации в рамках дисковой группы (deduplication domain) находятся идентичные блоки размером 4 КБ и дедуплицируются, а затем блоки сжимаются. При этом, если блок сжимается менее, чем на 50%, то целевое хранилище записывается оригинал блока в целях быстрого доступа при чтении (без декомпрессии).

Получается, что механизм DD&C - оппортунистический, то есть он работает не всегда, а по мере возможности и не гарантирует конкретных результатов по эффективности сжатия данных на целевом хранилище.

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

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

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

Такая двухъярусная система vSAN имеет 2 теоретических максимума:

• Max burst rate - возможность Cache Tier сбрасывать обработанные пакеты данных в сторону Capacity Tier
• Max steady state rate - установившаяся максимальная скорость записи данных на приемнике Capacity Tier

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

Если у вас идет дестейджинг данных с включенным DD&C, это потенциально может повлиять на производительность записи данных на Capacity Tier. При использовании DD&C снижается максимальная скорость записи данных на ярус постоянного хранения, так как перед этой записью должны быть выполнены операции дедупликации и сжатия.

Иными словами, кластер с включенным DD&C может давать такие же показатели качества обслуживания, как и кластер с более медленными устройствами в Capacity Tier, но с выключенным DD&C.

Логично ожидать, что при включенном DD&C буффер Write Buffer будет заполняться скорее, так как будут возникать задержки ожидания отработки DD&C. Но пока буффер полностью не заполнен - заметных просадок в производительности не будет. Очищаться также Write Buffer будет медленнее при включенном DD&C.

Также может измениться и время отсылки квитанции о записи (acknowledgment time, оно же write latency), которое увеличит latency для виртуальной машины. Это произойдет, если уже начался дестейджинг данных, а машина запрашивает ACK и ждет ответа с уровня буффера. Хотя в целом vSAN построен таким образом, чтобы как можно быстрее такой ответ дать.

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

Если вы также используете RAID 5/6 для кластеров vSAN, то совместно с техниками DD&C могут возникнуть серьезные эффекты с влиянием на производительность. Об этих аспектах подробно рассказано вот тут - обязательно ознакомьтесь с ними (см. также комментарий к статье).

По итогу можно сделать следующие выводы из этой схемы:

• Если вам хочется использовать DD&C, и вы видите, что у ВМ высокая latency - попробуйте более быстрые диски на Capacity Tier.
• Используйте больше дисковых групп, так как Buffer и его пространство hot working set используется на уровне дисковой группы. Две группы на хосте нужно минимум, а лучше три.
• Альтернативой DD&C могут стать устройства большой емкости - там просто все поместится).
• Используйте последнюю версию vSAN - алгоритмы работы с данными все время совершенствуются.
• Также помните, что RAID 5/6 также экономит место по сравнению с RAID1, что может стать альтернативой DD&C.

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

Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов (Partition Layout), которые произошли в VMware ESXi 7.

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

Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.

В VMware vSphere 6.x структура разделов выглядела следующим образом:

Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.

В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:

Теперь в ESXi 7 есть следующие 4 раздела:

• System boot - хранит boot loader и модули EFI. Формат: FAT16.
• Boot-banks (2 штуки) - системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
• ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.

Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.

В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:

Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.

Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).

Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:

В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:

Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):

Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.

Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.

ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:

• Boot media размером минимум 8 ГБ для устройств USB или SD
• 32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
• Boot device не может быть расшарен между хостами ESXi

Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.

Мы много писали о новых возможностях платформы VMware vSphere 7, но невозможно рассказать обо всех ее нововведениях в одной статье. Сегодня мы расскажем об одной интересной штуке - компоненте Watchdog Timer, который мы упоминали в одном предложении в статье о новых фичах.

Теперь для виртуальных машин доступно специальное устройство virtual watchdog timer (vWDT), которое позволяет администраторам в унифицированном виде узнавать о том, что гостевая операционная система и приложения данной ВМ зависли или вывалились в синий экран. Это особенно важно для кластеризованных приложений в целях поддержания их доступности.

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

Это виртуальное устройство пробрасывается в гостевую ОС через механизм BIOS/EFI ACPI и настраивается на уровне гостевой системы или самого BIOS/EFI.

Таблица Watchdog Resource Table (WDRT) имеет несколько регистров, в которые можно записать значения таймера, действия по их истечению и другие параметры. Большинство современных ОС поддерживают интеграцию с таблицей Watchdog Action Table (WDAT), определяющей список доступных действий для таймеров, которые и использует компонент WDRT.

Вот список доступных инструкций WDAT:

• WATCHDOG_ACTION_RESET
• WATCHDOG_ACTION_QUERY_CURRENT_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_SET_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_RUNNING_STATE
• WATCHDOG_ACTION_SET_RUNNING_STATE
• WATCHDOG_ACTION_QUERY_STOPPED_STATE
• WATCHDOG_ACTION_SET_STOPPED_STATE
• WATCHDOG_ACTION_QUERY_REBOOT
• WATCHDOG_ACTION_SET_REBOOT
• WATCHDOG_ACTION_QUERY_SHUTDOWN
• WATCHDOG_ACTION_SET_SHUTDOWN
• WATCHDOG_ACTION_QUERY_WATCHDOG_STATUS
• WATCHDOG_ACTION_SET_WATCHDOG_STATUS

Для большинства современных серверных ОС Windows и Linux не требуется каких-либо действий для дополнительной настройки таймера, но они могут понадобиться для некоторых старых систем, а FreeBSD или Mac OS X вовсе не поддерживают Watchdog Timer. Вот в целом информация о его поддержке:

• Windows 2003 поддерживает Watchdog Resource Table (WDRT)
• Windows 2008 и более поздняя поддерживает Watchdog Action Table (WDAT). Гостевая ОС не требует дополнительной конфигурации.
• Linux-дистрибутивы, такие как Ubuntu 18.04 и Red Hat Enterprise Linux 7.6, на базе ядра 4.9 или более позднего поддерживают Watchdog Action Table (WDAT). Для этого нужен драйвер wdat_wdt.ko.

Для настройки вам понадобится виртуальная машина с VM hardware версии 17 (появилось в vSphere 7). Надо просто добавить устройство Watchdog Timer:

Как вы видите, виртуальный Watchdog Timer можно включить либо на уровне BIOS/EFI (тогда он будет запускаться до старта ОС), либо на уровне гостевой ОС. Помните, что если гостевая ОС не поддерживает это устройство, то машина будет постоянно перезапускаться по команде от устройства Watchdog.

В vSphere Client видна информация о статусе исполнения Watchdog Timer. Не запущен:

Запущен: