В середине июня компания VMware представила сообществу Open Source свою новую разработку - нереляционную базу данных типа key-value SplinterDB. Базы данных с механиками "ключ-значение" работают очень быстро и в данный момент применяются для решения широкого круга задач. VMware сделала тут вот какую вещь - эта СУБД работает еще быстрее остальных (иногда в разы), поэтому она позиционируется как "ultra fast"-решение для высокопроизводительных нагрузок.

Платформа SplinterDB была разработана VMware Research Group в плотном сотрудничестве с группой разработки решений линейки vSAN. Ключевой особенностью этой базы данных является возможность быстро работать как с запросами на вставку/обновление данных, так и с запросами на чтение пар ключ-значение из хранилища. Вот так это выглядит в сравнении с СУБД RocksDB (она была разработана в Facebook), которая работает в той же нише, что и SplinterDB, на примере бенчмарка Yahoo Cloud Services Benchmark (YCSB):

SplinterDB максимально использует возможности ядер процессоров, легко масштабируется и использует все преимущества технологии организации хранилищ NVMe. Поэтому SplinterDB можно использовать поверх существующих key-value хранилищ, а также традиционных реляционных баз данных, NoSQL-СУБД, микросервисов, обработчиков потоков, архитектуры edge/IoT, хранилищ метаданных и графовых баз данных.

SplinterDB - это внедренное key-value хранилище во внешней памяти, что означает, что приложения используют SplinterDB путем линковки библиотеки SplinterDB в свой исполняемый файл. SplinterDB хранит данные на высокопроизводительных дисках SSD NVMe и может масштабироваться до огромных датасетов, которые значительно превышают объемы доступной памяти RAM.

На картинке выше показан пример, где SplinterDB и RocksDB хранили датасет 80 GiB в системе, имеющей 4 GiB RAM. Так как лишь малая часть базы данных помещалась в кэш оперативной памяти, то эффективность работы подсистемы ввода-вывода была ключевым фактором оценки производительности. Для теста использовались диски Intel Optane SSD, которые поддерживают 2 GiB/sec на чтение и запись. При этом RocksDB использовала только 30% доступного канала обмена с хранилищем (для операций записи), а SplinterDB использовала до 90% канала. При чтении SplinterDB также показала себя в полтора раза лучше, чем RocksDB, за счет более эффективного использования CPU и техник кэширования.

В чем же секрет такого высокого уровня производительности? Дело в том, что современные key-value хранилища (включая SplinterDB, RocksDB, LevelDB, Apache Cassandra и другие) хранят данные в больших сортируемых таблицах. Запросы ищут значения в каждой таблице, спускаясь от новых данных к старым. Таким образом, запросы замедляют систему, накапливая все больше и больше таблиц с данными. Чтобы избежать замедления работы, эти системы время от времени объединяют несколько отсортированных таблиц в одну (это называется compaction). Это и создает дисбаланс между скоростью на чтение и скоростью на запись. За счет этого запросы исполняются быстро, но вот вставка данных замедляется. Если compaction делать реже, то вставка будет работать быстрее, но и чтение замедлится.

SplinterDB делает compaction более чем в 8 раз реже, чем RocksDB, поэтому вставка данных и работает в первой примерно в 7 раз быстрее, чем во второй. Но что со скоростью на чтение? Чтобы поддерживать высокую скорость чтения, SplinterDB работает иначе, чем современные хранилища. Большинство из них используют фильтры Bloom (или их еще называют cuckoo), чтобы ускорять запросы.

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

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

SplinterDB использует новый вид фильтра, называемый routing filter. Один такой фильтр может заменить несколько фильтров типа Bloom, cuckoo или ribbon и может покрыть сразу несколько таблиц. Обычные фильтры могут сказать только, есть ли соответствующий ключ в доступности в данный момент или нет, а вот routing filter может не только сказать, что ключ есть, но и указать на то, какая конкретно из отсортированных таблиц его содержит. Поэтому запросам нужно делать гораздо меньше работы по поиску в фильтрах, а значит снижается нагрузка на CPU.

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

Более подробно о данной технологии можно почитать на официальном сайте SplinterDB, репозиторий продукта на GitHub доступен тут.

Аналитическая компания IDC недавно опубликовала 3 интересных документа, отражающих исследования рынка программного обеспечения в области управления оконечными устройствами на базе различных программно-аппаратных платформ.

Первое исследование - "MarketScape Worldwide Unified Endpoint Management Software" - посвящено решениям для управления пользовательскими средами и устройствами Unified Endpoint Management (UEM) на основе унифицированного подхода. Тут VMware занимает сильную позицию в квадранте лидеров:

Напомним, что у VMware данный аспект управления виртуальной и физической ИТ-средой реализуется продуктом Dynamic Environment Manager (DEM). Он предназначен для настройки и контроля пользовательских окружений на уровне ОС средствами политик (ранее он назывался VMware User Environment Manager, UEM). Этот продукт входит в семейство решений VMware Workspace ONE, которое получило новые возможности по управлению пользовательскими средами (включая мобильные устройства) после покупки компании AirWatch в 2014 году.

Второе исследование IDC - "Worldwide Unified Endpoint Management Software for Ruggedized/Internet of Things Device Deployments 2022" рассказывает о не только о решениях на базе стандартных пользовательских устройств, таких как компьютеры, ноутбуки, телефоны и планшеты, но и о продуктах и технологиях для управления промышленными системами, такими как медицинское оборудование, производственные IoT-устройства и различные платформы отдельных вертикалей, таких как логистика, общественная безопасность, строительство и прочие. Например, посмотрите наши заметки о решениях Workspace ONE ConQuest, XR Hub или Freestyle Orchestrator.

В третьем исследовании - MarketScape for UEM Software for Apple Devices 2022 - рассказывается о сложной для всех крупных предприятий теме - управлении устройствами Apple, которые, как известно, не всегда просто интегрировать в корпоративную инфраструктуру, а сотрудники широко ими пользуются, совмещая личное и рабочее окружение.

Тут VMware также в числе лидеров (забавно, что названия главного игрока, компании Jamf, на картинке не различить):

Тут VMware также имеет инструменты для управления устройствами на базе macOS и iOS, которые входят в состав решения Workspace ONE еще со времен покупки компании AirWatch. Еще здесь можно выделить некоторые новые инструменты, такие как Workspace ONE Mobile Threat Defense, Mobileconfig Importer и App Analyzer for macOS.

На сайте проекта VMware Labs обновилось средство Skyline Automation Toolkit до версии 1.2.5. Этот продукт предназначен для предоставления расширенной технической поддержки некоторым клиентам для Enterprise-продуктов с целью предотвратить возникновение проблем в будущем на базе анализа текущего состояния виртуальной среды. В последний раз мы писали об этом решении тут.

Появилось также новое обзорное видео о данной утилите:

Давайте посмотрим, что нового в Skyline Automation Toolkit версий 1.2.5 и 1.2.3:

• Добавлена команда "skyline-comm get-findings custom" на базе запроса от клиента
• Добавлена команда "skyline-comm get-findings detailall FILE.CSV" в целях сбора полученных объектов для любых CSV-отчетов
• Добавлена опция "skyline-comm get-findings top 5|10|25|50|200"
• Код утилиты был оптимизирован в целях уменьшения объема и лучшей читаемости

Скачать Skyline Automation Toolkit 1.2.5 можно по этой ссылке.

Недавно компания VMware опубликовала документ "Tanzu Application Platform (TAP) Reference Architecture", описывающий эталонную архитектуру инфраструктуры Tanzu Kubernetes Grid на базе облачных и онпремизных решений. Напомним, что на базе этой платформы, разработчики и операторы команд DevOps кластеров Kubernetes смогут разрабатывать различные решения для Azure Kubernetes Service, Amazon Elastic Kubernetes Service, Google Kubernetes Engine, а также непосредственно для инфраструктуры на базе Tanzu Kubernetes Grid.

Данная архитектура описывает дизайн инфраструктуры в части состава компонентов и их внутреннего и внешнего взаимодействия. Для производственных систем VMware рекомендует иметь два независимых экземпляра Tanzu Application Platform. Первый - для операторов, чтобы они могли выполнять внутренние тесты на надежность, функциональность инфраструктуры и для контроля качества обслуживания пользователей, а второй - для производственных нагрузок. Эти окружения должны быть изолированы на уровне отдельных кластеров.

В качестве необходимых требований к инфраструктуре TAP VMware указывает следующие:

• LoadBalancer для входящего контроллера (ingress controller), который имеет выделенный внешний IP-адрес
• Класс хранилищ по умолчанию
• Не менее 16 ГБ доступной памяти, доступной в рамках кластеров, не менее 8 ГБ на узел
• Включенное логирование для выбранной системы сохранения файлов журнала
• Включенный мониторинг для выбранной системы application observability platform

Также рекомендуется иметь три зоны Availability Zones (AZs) для обеспечения высокой доступности, а таже не устанавливать Tanzu Service Mesh (TSM).

Также в документе и внутрикластерная архитектура сервисов:

За более подробной информацией обращайтесь к оригинальному документу.

Мы довольно часто пишем о максимальных параметрах виртуальной инфраструктуры VMware vSphere и ее компонентов, в частности VMware vCenter (например, тут и тут). Сегодня мы немного освежим эти данные на примере последней версии сервера управления vCenter и приведем несколько примеров. Для начала напомним, что актуальные данные по максимальным конфигурациям продуктов VMware можно найти по адресу: https://configmax.vmware.com, а также в официальной документации.

Кроме того, у VMware есть отличное видео, посвященное лимитам vCenter и правилам выполнения одновременных операций в виртуальной среде:

Итак, лимиты можно разделить на 2 категории:

• Глобальные лимиты для инфраструктуры (виртуальный датацентр).
• Лимиты на уровне хоста и его компонентов (например, сетевые адаптеры).

Если говорить о глобальных параметрах, то значения тут следующие:

• Вы можете запустить до 640 одновременных операций в vCenter, пока они не начнут становиться в очередь.
• Всего можно запустить до 2000 одновременных операций на один сервер vCenter.

На уровне хостов ESXi есть следующие механизмы работы и ограничения:

• Хосты ESXi 6 и 7 версий имеют 16 слотов для выполнения операций в единицу времени:

• Любая операция с виртуальными машинами потребляет какое-то количество слотов на источнике и целевом хосте.
• Операция Storage vMotion стоит 8 слотов на хост. Если вы меняете только датастор у виртуальной машины, оставляя тот же хост, то потребляются эти 8 слотов, то вы можете сделать 2 одновременных миграции. Ранее это работало несколько иначе - смотрите наш пост вот тут.
• Операция Linked clone потребляет 1 слот, но для этого у вас уже должен быть создан снапшот. Если у вас его нет, то он сначала создается - это может замедлить создание первого связанного клона. Также снапшот требуется и при клонировании включенной ВМ, где требуется уже 2 слота (то есть одновременно можно делать 8 таких операций для данной пары хостов).

• Операции Clone, Relocate и vMotion стоят 2 слота каждая на каждом хосте - то есть и на источнике, и на целевом (суммарно получается потребляется 4 слота на двух хостах). Это же работает и при клонировании ВМ на том же самом хосте - на нем в этот момент потребляется 4 слота (то есть одновременно на хосте можно делать 4 таких операции).

Для датасторов также есть слоты и ограничения на одновременные операции:

• У одного датастора есть 128 слотов.
• Операция vMotion стоит 1 слот, то есть на одном датасторе может проходить до 128 одновременных миграций vMotion.
• Операция Storage vMotion стоит 16 слотов, то есть на одном датасторе может проходить до 8 одновременных миграций vMotion.
Это же работает и для датасторов vSAN, где часто встречаются конфигурации с одним датастором - это надо иметь в виду.

Лимиты для сетевых адаптеров сейчас следующие (помните, что для vMotion лучше иметь отдельный адаптер или выделенную пару портов на нем):

• У 1Gb NIC есть 4 слота, то есть можно делать до 4 одновременных миграций vMotion через этот адаптер.
• У 10Gb и 25Gb NIC есть 8 слотов, то есть можно делать до 8 одновременных миграций vMotion через такие адаптеры.

Более подробно об организации адаптеров для vMotion вы можете прочитать в KB 2108824.

Некоторое время назад мы писали о службах VMware vSphere Cluster Services (ранее они назывались Clustering Services), которые появились в VMware vSphere 7 Update 1. Они позволяют организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Для этого VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:

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

Иногда требуется отключить службы Cluster Services, что может оказаться необходимым в следующих случаях:

• Вам нужно правильно удалить кластер HA/DRS и выполнить корректную последовательность по выводу его из эксплуатации
• Требуется удалить / пересоздать дисковые группы VMware vSAN, на хранилищах которых размещены виртуальные машины vCLS
• Вам не требуется использовать DRS, и вы хотите отключить эти службы. В этом случае помните, что механизм обеспечения отказоустойчивости VMware HA также будет функционировать некорректно. Он зависит механизма балансировки нагрузки при восстановлении инфраструктуры после сбоя - именно на DRS он полагается при выборе оптимальных хостов для восстанавливаемых виртуальных машин.

Режим, в котором службы Cluster Services отключены, называется Retreat Mode. Итак, заходим в vSphere Client и выбираем кластер, в котором мы хотим ввести Retreat Mode. В строке браузера нам нужна строка вида:

domain ID domain-c<number>

Скопировав эту часть строчки, идем в Advanced Setting сервера vCenter и нажимаем Edit Settings:

Далее создаем там параметр со следующим именем и значением false:

config.vcls.clusters.domain-cxxx.enabled

Где cxxx - это идентификатор домена, который вы скопировали на прошлом шаге:

После этого нажимаем кнопку Save. В консоли vSphere Client в разделе vCLS для кластера мы увидим, что этих виртуальных машин больше нет:

На вкладке Summary мы увидим предупреждение о том, что vSphere Cluster Services больше не работает, а службы DRS вследствие этого также не функционируют корректно:

Чтобы вернуть все как было, нужно просто удалить добавленный параметр из Advanced Settings сервера vCenter.

На прошлой конференции VMworld 2021 компания VMware представила решение Project Ensemble, которое предназначено для мультиоблачных инфраструктур, построенных на базе комбинации различных частных и публичных облаков, где требуется предоставление пользователям единого и подстроенного под них интерфейса, ориентированного на приложения.

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

Частая проблема такой организации - трудность управления сущностями (например, виртуальными машинами), которые контролируются из различных компонентов виртуальной инфраструктуры. Виртуальную машину может создать сервер управления vCenter, но не только. Ее можно развернуть в рамках рабочего процесса vRealize Automation, тогда она получит его ID.

Операции с ВМ и их модификацией могут осуществлять такие продукты, как vRealize Operations, vRealize Network Insight и другие - все это вовлекает новые идентификаторы и собственные их базы данных в разных продуктах:

При выполнении операций, например, при мониторинге инфраструктуры средствами vRealize Operations (vROPs), продукту vRealize Automation (vRA) очень было бы полезно знать некоторую информацию из vROPs.

Если мы, к примеру, хотим удостовериться, что развернутое из vRealize Automation приложение сейчас в здоровом статусе в vRealize Operations, то нужно понимать и вызывать два разных API от обоих продуктов. Потом нужно как-то сопоставить эту информацию и использовать ее дальше в сценарии автоматизации. А теперь представим, что подобного рода объектов тысячи или десятки тысяч в большой инфраструктуре.

Для решения этой проблемы и нужен VMware Project Ensemble. Он предоставляет различным сервисам единую поверхность потребления информации об объектах, которые находятся под контролем различных компонентов виртуальной инфраструктуры (Ensemble по-французски означает "вместе").

Итак, Project Ensemble получает все данные от различных служб (например, vRealize Operations, vRealize Automation и vRealize Network Insight) и нормализует эти данных в рамках унифицированной модели common object model.

Далее в рамках концепции подхода API First можно получать различные данные об объекте в рамках лишь одного API-вызова. Вот так это визуализуется в консоли Project Ensemble для сервиса NSX Edge:

Многие пользователи VMware уже привыкли к RESTful API и Swagger, для которых VMware имеет большой объем документации. Но в данном случае Project Ensemble использует GraphQL для получения данных. В этом фреймворке есть 3 операции:

• Query - получение информации об объектах
• Mutation - запрос на выполнение действия с объектом
• Subscription - возможность отслеживать изменения в системе, когда они происходят

Project Ensemble педоставляет удобную оболочку разработки веб-IDE для GraphQL (на базе проекта GraphiQL):

Вот тут рассказано об API этого проекта, а мы посмотрим несколько примеров.

Объекты в среде Ensemble называются сущностями (entities). Обратиться к ним можно в рамках простого поиска по имени. Например, найдем объекты виртуальные машины, в имени которых содержится строка "Dina":

В ответе мы увидим данные от таких продуктов, как vRealize Automation, vRealize Operations и vRealize Network Insight:

Мы видим, что в каждом сервисе есть определенные ID данного объекта. Но для того, чтобы получить какие-то свойства объекта через Ensemble можно просто использовать универсальный Ensemble entity ID.

Например, мы хотим узнать CPU usage из решения vRealize Operations. Для этого можно сформировать вот такой запрос:

В качестве ответа мы получим актуальное значение метрики из vROPs:

Также можно выполнять действия через механизм mutations. Вот таким запросом мы можем сначала узнать о доступных действиях с объектом:

В ответе будет список только доступных действий. Вот так, например, будет выглядеть ответ для включенной виртуальной машины (у нее, само собой, нет действия Power on):

Кстати, обратите внимание, что ранее в запросе было поле actionRequests - это список действий, которые выполнялись с этой сущностью:

Итак, чтобы выполнить запрос на mutation, нужно создать вот такую конструкцию, содержащую entityId и actionDefinitionId из результатов запроса выше:

После этого мы увидим, что действие начало выполняться:

Через несколько минут оно перейдет в статус выполненного:

Вот таким образом VMware Project Ensemble позволит унифицировать операции с объектами под управлением различных сущностей в инфраструктуре виртуальных машин и приложений на основе API First подхода.

Компания VMware на днях анонсировала новый продукт из линейки Workspace ONE - Mobile Threat Defense. Это решение дополняет существующие средства по защите пользовательских окружений в части мобильных приложений на платформах Android, iOS и Chrome OS. Уже сегодня этот продукт доступен для пользователей и имеет интеграцию с решением Workspace ONE Intelligent Hub и UEM.

За счет интеграции с Intelligent Hub не требуется установки каких-то новых приложений или сервисов на пользовательские устройства. Администратору требуется лишь включить функции ONE Mobile Threat Defense в настройках, и данное решение автоматически будет развернуто на мобильных устройствах.

Основные возможности по защите мобильных пользовательских сред:

1. Средства защиты мобильных устройств

• От атак типа SSL certificate stripping
• От слабых алгоритмов (weaker algorithm negotiation)
• От сканеров портов
• От spyware и surveillance ware
• От sideloaded apps

2. Механизмы обработки вредоносного контента и фишинговых угроз

• В почте, SMS, мессенжерах и социальных приложениях
• Перехват вредоносных URL, веб-страниц, видео, фото

3. Предотвращение мобильных угроз

• Выстраивание цикла обновления ОС и накатывания патчей
• Решение проблем с устаревшими и давно не обновляемыми приложениями

4. Управление конфигурациями

• Отслеживание Jailbreak / root access
• Управление механизмом Wi-Fi auto join
• Выявление приложений, которые негативно влияют на пользовательское окружение и устройство

Более подробно о решении Workspace ONE Mobile Threat Defense можно узнать на этой странице (там же есть и небольшое видео о продукте). Документация доступна тут.

Многие администраторы виртуальных инфраструктур используют технологию NVIDIA vGPU, чтобы разделить физический GPU-модуль между виртуальными машинами (например, для задач машинного обучения), при этом используется профиль time-sliced vGPU (он же просто vGPU - разделение по времени использования) или MIG-vGPU (он же Multi-Instance vGPU, мы писали об этом тут). Эти два режима позволяют выбрать наиболее оптимальный профиль, исходя из особенностей инфраструктуры и получить наибольшие выгоды от технологии vGPU.

Недавно компания VMware выпустила документ "VMware vSphere 7 with NVIDIA AI Enterprise Time-sliced vGPU vs MIG vGPU: Choosing the Right vGPU Profile for Your Workload", в котором рассматриаются варианты использования обоих профилей и приводятся результаты сравнения производительности виртуальных ПК на базе этих профилей.

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

В этом эксперименте была запущена нагрузка Mask R-CNN с параметром batch size = 2 (training and inference), в рамках которой увеличивали число ВМ от 1 до 7, и которые разделяли A100 GPU в рамках профилей vGPU и MIG vGPU. Эта ML-нагрузка была легковесной, при этом использовались различные настройки профилей в рамках каждого тестового сценария, чтобы максимально использовать время и память модуля GPU. Результаты оказались следующими:

Как мы видим, MIG vGPU показывает лучшую производительность при росте числа ВМ, разделяющих один GPU. Из-за использования параметра batch size = 2 для Mask R-CNN, задача тренировки в каждой ВМ использует меньше вычислительных ресурсов (используется меньше ядер CUDA) и меньше памяти GPU (менее 5 ГБ, в сравнении с 40 ГБ, который имеет каждый GPU). Несмотря на то, что vGPU показывает результаты похуже, чем MIG vGPU, первый позволяет масштабировать нагрузки до 10 виртуальных машин на GPU, а MIG vGPU поддерживает на данный момент только 7.

Второй вариант теста - vGPU и MIG vGPU при масштабировании нагрузок Machine Learning.

В этом варианте исследовалась производительность ML-нагрузок при увеличении их интенсивности. Был проведен эксперимент, где также запускалась задача Mask R-CNN, которую модифицировали таким образом, чтобы она имела 3 разных степени нагрузки: lightweight, moderate и heavy. Время исполнения задачи тренировки приведено на рисунке ниже:

Когда рабочая нагрузка в каждой ВМ использует меньше процессора и памяти, время тренировки и пропускная способность MIG vGPU лучше, чем vGPU. Разница в производительности между vGPU и MIG vGPU максимальна именно для легковесной нагрузки. Для moderate-нагрузки MIG vGPU также показывает себя лучше (но немного), а вот для тяжелой - vGPU уже работает производительнее. То есть, в данном случае выбор между профилями может быть обусловлен степенью нагрузки в ваших ВМ.

Третий тест - vGPU и MIG vGPU для рабочих нагрузок с высокой интенсивность ввода-вывода (например, Network Function with Encryption).

В этом эксперименте использовалось шифрование Internet Protocol Security (IPSec), которое дает как нагрузку на процессор, так и на подсистему ввода-вывода. Тут также используется CUDA для копирования данных между CPU и GPU для освобождения ресурсов процессора. В данном тесте IPSec использовал алгоритмы HMAC-SHA1 и AES-128 в режиме CBC. Алгоритм OpenSSL AES-128 CBC был переписан в рамках тестирования в части работы CUDA. В этом сценарии vGPU отработал лучше, чем MIG vGPU:

Надо сказать, что нагрузка эта тяжелая и использует много пропускной способности памяти GPU. Для MIG vGPU эта полоса разделяется между ВМ, а вот для vGPU весь ресурс распределяется между ВМ. Это и объясняет различия в производительности для данного сценария.

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

• Для легковесных задач машинного обучения режим MIG vGPU даст бОльшую производительность, чем vGPU, что сэкономит вам деньги на инфраструктуру AI/ML.
• Для тяжелых задач, где используются большие модели и объем входных данных (а значит и меньше ВМ работают с одним GPU), разница между профилями почти незаметна.
• Для тяжелых задач, вовлекающих не только вычислительные ресурсы и память, но и подсистему ввода-вывода, режим vGPU имеет преимущество перед MIG vGPU, что особенно заметно для небольшого числа ВМ.

В любом случае, если вы строите большую виртуальную инфраструктуру, работающую с задачами машинного обучения и тяжелыми нагрузками, нужно предварительно провести тестирование обоих профилей - MIG vGPU и vGPU, чтобы определить оптимальный для себя режим и сократить затраты на оборудование и ПО. Подробнее вы можете прочитать в документе "VMware vSphere 7 with NVIDIA AI Enterprise Time-sliced vGPU vs MIG vGPU: Choosing the Right vGPU Profile for Your Workload".

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

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

Например, в видео рассказывается о функциях vSphere Cluster Services (vCLS), переработанных механизмах vMotion и DRS, новых возможностях поддержки GPU для требовательных к графике и CUDA-приложений, а также многих других нововведениях.

В целом, вы узнаете о лучших практиках в следующих сферах:

• Проектирование виртуальной архитектуры
• Развертывание vSphere
• Тюнинг производительности
• Использование средств управления
• Масштабирование инфраструктуры
• Обеспечение отказоустойчивости компонентов виртуальной среды

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

Основные улучшения и нововведения:

1. Байндинги PowerShell для интерфейсов NSX Policy Manager API.

Теперь появился новый модуль VMware.Sdk.Nsx.Policy, который реализует байндинг PowerShell для программных интерфейсов NSX Policy Manager API.

2. Новые командлеты для управления виртуальным модулем vCenter Server Appliance.

Теперь для управления резервными копиями vCenter Server Appliance можно использовать следующие командлеты:

• New-ApplianceBackupJob - стартует задачу резервного копирования на уровне файлов vCenter Server на бэкап-сервер.
• Wait-ApplianceBackupJob - мониторит прогресс задачи резервного копирования и возвращает в ApplianceBackupJob.
• Get-ApplianceBackupJob - получает список завершенных или находящихся в исполнении задач резервного копирования.
• Stop-ApplianceBackupJob - останавливает задачи РК в соответствии с указанными параметрами.
• Get-ApplianceBackupPart - получает список частей (parts), которые могут быть включены в задачу РК, а также их размер в резервной копии. Обязательные части всегда включаются в бэкап.

3. Поддержка SRM 8.5.

Модуль VMware.VimAutomation.Srm был обновлен и теперь поддерживает решение VMware Site Recovery Manager 8.5.

4. Исправления ошибок.

VMware приводит таблицу с багофиксами:

Загрузить компоненты фреймворка VMware PowerCLI 12.6 можно по этой ссылке. Release notes доступны тут.

Компания VMware обновила свое решение для облачных провайдеров, предоставляющих виртуальные машины в аренду по модели IaaS - Cloud Provider Lifecycle Manager до версии 1.3 (VCPLCM). Напомним, что Lifecycle Manager предназначен для автоматизации рутинных операций жизненного цикла пользователей, для которых можно разрабатывать свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров (VCPP) сосредоточиться на более высокоуровневых операциях.

О прошлой версии этого продукта мы писали вот тут. Нововведения версии 1.3 сосредоточены в следующих областях:

Давайте посмотрим, что нового появилось в vLCM 1.3 для облачных провайдеров:

1. Решение vLCM теперь Stateful

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

2. Улучшенная поддержка других продуктов в составе виртуального датацентра

Некоторые компоненты датацентра определяются как инстансы или сервисы, которые не управляются со стороны VCPLCM. С новой версией API v2 теперь доступна регистрация решений vCenter, NSX-T и vROPS как компонентов датацентра.

Также VCPLCM 1.3 теперь имеет совместимость со следующими версиями решений от VMware:

• VCD 10.1.x, 10.2.x и 10.3.x (протестировано с VCD 10.2.2.2 и 10.3.3)
• Usage Meter 4.4 и 4.5
• vROPS Tenant App 2.4, 2.6.2 и 8.6.1
• RabbitMQ – Bitnami VM image 3.8.6 и 3.8.14

3. VCPLCM 1.3 теперь имеет графический интерфейс

Теперь у решения появился полноценный GUI, который существенно увеличивает скорость работы с виртуальным модулем. Также уже существовавшие интерфейсы CLI и API никуда не делись и остались в продукте.

В графический интерфейс CPLCM можно попасть по ссылке:

https://<vcplcm-appliance>

В главном разделе "Environments" можно увидеть все развернутые продукты списком в алфавитном порядке, а также в том порядке, в котором они были развернуты. Также приводятся общие сведения об этих продуктах с возможностью открыть его или скачать его JSON-описание.

В данный момент VCPLCM поддерживает 3 компонента: vCenter, NSX-T и vROPS. Их можно увидеть в разделе "Datacenters". Они также идут в алфавитном порядке, либо в порядке того, в котором они были развернуты. Тут тоже есть информация о компонентах и возможность скачать JSON.

Таким образом, в дополнение к функции Overview, в решении можно выполнять следующие операции для объектов из GUI:

• Валидировать компоненты датацентра
• Регистрировать компоненты
• Скачивать определения JSON для компонентов датацентра
• Создавать, развертывать или скачивать JSON-определения для развернутых продуктов

Загрузить VMware Cloud Provider Lifecycle Manager 1.3 можно по этой ссылке. Рекомендации по апгрейду с прошлых версий доступны тут.

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

Итак, давайте посмотрим, что нового:

1. Skyline CLI версии 1.0.2

Решение Skyline CLI позволяет с помощью интерфейса командной строки автоматизировать операции и конфигурации компонентов Skyline Collectors. Несколько подробнее мы писали о нем тут.

Что нового в этом обновлении:

• Виртуальный модуль Skyline collector OVA получил новые возможности при развертывании и конфигурации решения
• Поддержка мониторинга конечных компьютеров с использованием решения VMware vRealize Operations (vROPs)

Скачать Skyline CLI 1.0.2 можно по этой ссылке.

2. Horizon Cloud Pod Architecture Tools версии 1.2

Об этом продукте мы писали вот тут. Он предназначен для того, чтобы улучшить исполнение команд назначения глобальных прав доступа. Как знают администраторы VMware Horizon, инфраструктура распределенных узлов cloud pod architecture (CPA) имеет в своем составе команды lmvutil, которые позволяют управлять назначением глобальных прав к базе данных через интерфейс командной строки. Теперь для lmvtools сделали обертку (wrapper), которая позволяет вводить пароль только один раз и далее исполнять команды управления назначением прав.

Что нового в этом обновлении:

• Решение протестировано на Horizon 7.13.x и Horizon 8.4.x
• Идентифицируются удаленные пользователи и группы. После этого можно удалить права, назначенные удаленным пользователям и группам с помощью команды:
  

  adlds-analyzer.cmd --resolve-site-ga

  
  
• Исправлены ошибки, связанные с обработкой уязвимости Log4J, таким образом, чтобы использовались текущие библиотеки Horizon Connection Server.
• Теперь зависший Global Entitlement Assignment только с локальными назначениями можно убрать с помощью команды:
  

  options adlds-analyzer.cmd --resolve-localpool-ga

• Бандлы локалей Horizon 8.4 идут в JSON-формате, также была изменена логика парсинга в целях поддержки других языков при экспорте в CSV

Скачать Horizon Cloud Pod Architecture Tools 1.2 можно по этой ссылке.

3. Skyline Automation Toolkit версии 1.2.2b

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

Что нового в этом апдейте:

• Теперь работает не только в Windows 10, но и в PhotonOS

Скачать Skyline Automation Toolkit 1.2.2b можно по этой ссылке.

4. Workspace ONE ConQuest версии 1.1

Это средство позволяет сконфигурировать устройства Meta Quest 2 VR (Firmware v37+) для использования с решением VMware Workspace ONE UEM. С помощью ConQuest, представляющим собой Windows-приложение, администраторы могут запустить его службы на устройстве Meta Quest 2 в режиме разработчика и подсоединить его к Windows-машине через USB-C. Ранее мы писали об этой утилите тут.

Что нового в версии 1.1:

• Добавлена поддержка Meta Quest firmware версии 40

Скачать Workspace ONE ConQuest 1.1 можно по этой ссылке.

Сегодня компания Broadcom, один из ведущих производителей микроэлектронных компонентов (а также владелец брендов LSI, Emulex и CA Technologies), сделала официальное объявление о том, что покупает компанию VMware у основателя корпорации Dell и его партнеров за 61 миллиард долларов. Broadcom Software Group с VMware на борту будет переформирована и интегрирует последнюю в свою единую структуру. При этом, как следует из пресс-релиза Broadcom, объединенная компания будет работать под брендом VMware.

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

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

Текущие акционеры VMware могут выбрать - получить кэш в размере $142.50 за акцию, либо конвертировать ее в 0.252 акции объединенной Broadcom. При этом, учитывая стоимость акции Broadcom, премия для новых акционеров составляет плюс 30-45% к цене акции.

Чтобы завершить эту транзакцию по покупке VMware, Broadcom открыла кредитные линии в банках в размере 32 миллиардов, а владельцы VMware (Michael Dell и PE-фонд Silver Lake), у которых 40.2% и 10% компании, соответственно) рекомендовали совету директоров одобрить поглощение.

Ну что, в ближайшее время мы увидим не только новые продукты, но и новое "железо" с лейблами VMware.

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

Давайте посмотрим, что нового в версии пакета 1.10:

• Добавлена поддержка VMware ESXi 7.0 Update 3c и 3d
• Исправлена проблема с выпадением ESXi в BSOD при использовании драйвера с последними версиями ESXi

Драйверы версии 1.10 подходят только для ESXi 7.0 Update 3c и Update 3d, вот их дистрибутив:

ESXi703-VMKUSB-NIC-FLING-55634242-component-19849370.zip

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

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

• Добавлена поддержка ESXi 7.0 Update 3, 3a и 3b.
• Добавлена поддержка идентификаторов VID: 0x0b05/PID: 0x1976 и VID: 0x1A56/PID: 0x3100.
• Исправлена проблема в механизме управления питанием в xHCI.
• Сканирование шины USB (usbBusFullScanOnBootEnabled=0) отключено по умолчанию, что позволяет предотвратить выпадение в PSOD для пользователей, у которых есть несколько сетевых карточек USB.

Этот релиз предназначен только для ESXi 7.0 Update 3, Update 3a и Update 3b:

ESXi703-VMKUSB-NIC-FLING-51233328-component-18902399.zip

Для использования драйверов в других версиях ESXi смотрите информацию о версиях на странице USB Network Native Driver for ESXi.

Одним из нововведений новой версии решения для обеспечения катастрофоустойчивости виртуальной инфраструктуры хранения VMware vSAN 7.0 Update 3 стал улучшенный механизм по обработке последовательных отказов. Называется он Enhanced Data Durability.

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

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

Проиллюстрируем это на примере, который привел Дункан Эппинг. Предположим, у нас есть вот такая инфраструктура:

И вот у нас отказывает полностью один из датацентров. В консоли RVC мы увидим следующее:

  VM R1-R1:

  Disk backing:

  [vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx

  RAID_1

  RAID_1

  Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221

  votes: 1, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201

  votes: 1, usage: 0.1 GB, proxy component: false)

  RAID_1

  Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238

  votes: 1, usage: 0.1 GB, proxy component: true)

  Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236

  votes: 1, usage: 0.1 GB, proxy component: true)

  Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231

  votes: 3, usage: 0.0 GB, proxy component: false)

  Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214

  votes: 1, usage: 0.0 GB, proxy component: false)

  Witness: 0b013262-5616-95c5-8b52-005056968de9 , host: 10.202.25.228

  votes: 1, usage: 0.0 GB, proxy component: false)

Здесь мы видим, что у нас 1 голос на каждый из дисковых компонентов основной площадки (итого 2), 3 голоса на Witness и 2 голоса на резервной площадке.

Теперь представим, что все хосты резервной площадки отказывают полностью. У нас остается 2+3=5 голосов из 7, то есть кворум есть, все в порядке (для обеспечения кворума нужно больше 50% голосов). Но вот если у нас после этого откажет компонент Witness, имеющий 3 голоса, то у нас останется только 2 голоса из 7, кворума не будет - и это может привести к проблемам в кластере.

Для этого в vSAN 7 Update 3 сделали механизм пересчета голосов. Посмотрим на то, как выглядит картина через 5 минут после отказа резервной площадки в консоли RVC:

  VM R1-R1:

  Disk backing:

  [vsanDatastore] 0b013262-0c30-a8c4-a043-005056968de9/R1-R1.vmx

  RAID_1

  RAID_1

  Component: 0b013262-c2da-84c5-1eee-005056968de9 , host: 10.202.25.221

  votes: 3, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3acf-88c5-a7ff-005056968de9 , host: 10.202.25.201

  votes: 3, usage: 0.1 GB, proxy component: false)

  RAID_1

  Component: 0b013262-a687-8bc5-7d63-005056968de9 , host: 10.202.25.238

  votes: 1, usage: 0.1 GB, proxy component: false)

  Component: 0b013262-3cef-8dc5-9cc1-005056968de9 , host: 10.202.25.236

  votes: 1, usage: 0.1 GB, proxy component: false)

  Witness: 0b013262-4aa2-90c5-9504-005056968de9 , host: 10.202.25.231

  votes: 1, usage: 0.0 GB, proxy component: false)

  Witness: 47123362-c8ae-5aa4-dd53-005056962c93 , host: 10.202.25.214

  votes: 3, usage: 0.0 GB, proxy component: false)
 

Итак, мы видим, что каждый из дисковых компонентов получил по 3 голоса. Компонент Witness вне площадок получил 1 голос вместо 3, а компонент Witness, поднявшийся на основной площадке также получил 3 голоса.

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

Как долго происходит пересчет голосов в кластере? Это зависит от количества дисковых объектов, голоса которых учитываются. В среднем на одну ВМ приходится по несколько секунд вычислений, поэтому общая реконфигурация состава голосов может занять до 5 минут. Зато в этом случае кластер будет более устойчив к отказам, которые в реальной жизни могут происходить один за другим.

Недавно на сайте проекта VMware Labs появилось 3 небольших обновления различных утилит, о которых мы хотели бы вам рассказать.

1. Обновился vCenter Plugin for vRealize Network Insight до версии 2.1

 vCenter Plugin for vRealize Network Insight. С помощью данного плагина для управляющего сервера vCenter можно получить всю необходимую информацию от решения VMware vRealize Network Insight (vRNI) в консоль vSphere Client в виде отдельного раздела.

Это все позволяет администраторам виртуальной инфраструктуры VMware vSphere видеть информацию о сетевом взаимодействии в виртуальном датацентре и потоках виртуальных машин сразу в клиенте vSphere, без необходимости постоянно переключаться между двумя консолями:

Что нового в версии 2.1:

• Поддержка vRealize Network Insight 6.4 и выше (теперь нет сообщения "Connection failed!")
• Улучшена обработка ошибок при неудачном соединении (неправильные креды, слишком много попыток логина, невозможно соединиться по другой причине)

Скачать vCenter Plugin for vRealize Network Insight 2.1 можно по этой ссылке.

2. Обновился SDDC Import/Export for VMware Cloud on AWS до версии 1.7

С помощью этого средства можно сохранять конфигурацию виртуального датацентра SDDC в облаке VMConAWS, а также импортировать ее из сохраненной копии.

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

Что нового в версии 1.7:

• Новые флаги в файле config.ini flags для пропуска импорта групп и сервисов
• Улучшенная обработка ошибок при неудачном импорте (например, неподдерживаемое членство ВМ во внешней группе)

Скачать SDDC Import/Export for VMware Cloud on AWS 1.7 можно по этой ссылке.

3. Обновился Python Client for VMC on AWS до версии 1.8

С помощью этой утилиты пользователям публичного облака VMware Cloud on AWS можно автоматизировать операции с инфраструктурой виртуального датацентра VMConAWS SDDC.

Это средство представляет собой не клиент для работы с сервером vCenter, а средство удаленного исполнения задач в облаке, таких как создание сетей или настройка групп и правил безопасности на шлюзах Management и Compute Gateways.

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

• Поддержка VCDR API, которой давно ждали пользователи.
• Был проведен рефакторинг функций, в результате вызовы API были разнесены по разным библиотекам. Это позволяет более универсально использовать API-вызовы, в том числе для повторного использования.
• Исправлены ошибки при обработке символов нижнего регистра во время создания правил сетевого экрана.
• Улучшена документация и прояснено значение некоторых аргументов функций (new-network и new-group).

Скачать Python Client for VMC on AWS 1.8 можно по этой ссылке.

На днях компания VMware опубликовала отчет по уязвимостям VMSA-2022-0014, которые были обнаружены в решениях Workspace ONE Access, VMware Identity Manager (vIDM), vRealize Lifecycle Manager, vRealize Automation и VMware Cloud Foundation. Напомним также, что vIDM является компонентом таких продуктов, как NSX vRealize Operations, vRealize Log Insight и vRealize Network Insight. Это критическая уязвимость, которая позволяет обойти процедуры аутентификации пользователя и повысить привилегии в соответствующем продукте.

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

Основная информация о том, как закрыть эти дыры, приведена по следующим двум ссылкам:

• https://www.vmware.com/security/advisories/VMSA-2022-0014.html (о том, как исправлять)
• https://via.vmw.com/vmsa-2022-0014-qna (это часто задаваемые вопросы)

Также вы можете подписаться на оповещения VMware о найденных уязвимостях по электронной почте по этой ссылке.

Недавно мы писали о весеннем обновлении облачной инфраструктуры Oracle Cloud VMware Solution (OCVS). Напомним, что это совместное решение Oracle и VMware, которое позволяет взять виртуальные машины в аренду напрямую из облака Oracle, заточенного под высокопроизводительные задачи, особенно под СУБД Oracle, включая различные оптимизации для этих баз данных (подробнее вы можете почитать об этом тут).

На днях VMware опубликовала документ Horizon on Oracle Cloud VMware Services Reference Architecture, в котором описывается уже не северная инфраструктура, а архитектура окружений виртуальных ПК и опубликованных приложений (virtual desktop infrastructure, VDI), которые доставляются конечным пользователям напрямую из облака. Сама инфраструктура включает в себя такие компоненты, как vSphere, Horizon, vSAN, NSX-T и vCenter Server. Oracle предоставляет серверное оборудование, сервисы L2-уровня и компоненты инфраструктуры хранения.

Horizon 8.x и OCVS работают вместе, чтобы предоставлять пользователям высокопроизводительные десктопы и приложения, которые защищены сервисами отказоустойчивости, восстановления после сбоев и повышенной безопасности.

Надо сказать, что Oracle Cloud Infrastructure (OCI), Oracle VMware Cloud Solution (как его часть) и инфраструктура комплексного управления software-defined data center (SDDC) полностью интегрировано в единое решение с точки зрения средств управления и средств внутренней и внешней коммуникации:

VMware vCenter Admin Console в этой инфраструктуре выступает единым центром управления для администраторов VDI-инфраструктуры.

С точки зрения отказоустойчивости, за этот момент отвечает архитектура Cloud Pod Architecture, которая связывает несколько кластеров виртуальных ПК как в облаке, так и в онпремизной инфраструктуре, создавая единую интегрированную гибридную среду.

Безопасность также является одним из приоритетов Oracle Cloud, она реализуются в рамках концепции Zero Trust (то есть слежение за подозрительной активностью происходит на уровне всех систем). При аутентификации в гибридной среде используется протокол LDAP.

С помощью Horizon Admin Console администраторы инфраструктуры виртуальных ПК имеют полный контроль над всеми виртуальными ПК и их пулами, для которых в облаке обеспечивается тот же уровень безопасности, что и в онпремизной среде.

Более подробно об инфраструктуре VDI и ее архитектуре вы можете узнать из документа Oracle Cloud VMware Services Reference Architecture.

На днях компания VMware опубликовала очередную книгу из серии для новичков (for dummies), касающуюся средств управления корпоративной инфраструктуры - vRealize Automation for Dummies. Напомним, что продукт vRA (а точнее пакет продуктов) предназначен для автоматизации рутинных операций в облаке и онпремизной инфраструктуре на базе VMware vSphere.

В книге на 69 страницах рассказывается о том, как развернуть и начать использовать решение vRealize Automation и основные его компоненты, такие как средство для автоматизации рабочих процессов vRealize Orchestrator. Книга не является чисто маркетинговым материалом - в ней присутствует множество примеров конфигураций продукта, а также скриншоты с разъяснением значений тех или иных параметров.

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

Содержание:

• Introducing vRealize Automation
• Cloud Assembly
• Service Broker
• Code Stream
• Orchestrator
• SaltStack Config
• Looking at Use Cases
• Ten Resources to Get Started with vRealize Automation

Также напомним наши посты о книгах из серии for dummies, которые были выпущены компанией VMware:

• VMware: Securing Your Organization from Threats for Dummies
• Managing a VMware Cloud for Dummies
  
• Multi-Cloud Load Balancing for Dummies
• Micro-segmentation for Dummies Guide, 2nd Edition
• Network Virtualization For Dummies
  

Компания VMware на днях обновила свое главное программное комплексное инфраструктурное решение VMware Cloud Foundation до версии 4.4.1. Напомним, что это платформа, которая включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О версии платформы VCF 4.1 мы писали вот тут.

На днях VMware представила VCF 4.4.1, давайте посмотрим, что там нового (напомним, что релиз VCF 4.4 вышел в феврале):

• Новая версия VMware SDDC Manager 4.4.1
• Обновление средства управления VMware vCenter Server 7.0 Update 3d, в котором было исправлено множество ошибок (подробнее тут)
• Обновися VMware NSX-T до версии 3.1.3.7.4 (подробнее тут и тут).
• Добавлен VMware vRealize Suite Lifecycle Manager 8.6.2 PSPAK 3

Пользователи могут развернуть Cloud Foundation 4.4.1 как новый релиз, а также как последовательный или skip-level (через несколько версий) апгрейд с 4.4, 4.3.1, 4.3, 4.2.1, 4.2, 4.1.0.1 и 4.1.

Более подробно о решении VCF вы можете почитать тут. Совместимые с этой инфраструктурой решения приведены на специальном портале.

На днях компания VMware обновила свое решение vRealize Suite Lifecycle Manager до версии 8.8, входящее в пакет решений vRealize Suite. Напомним, что оно предназначено для развертывания установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Он пришел на смену решению VMware Update Manager (VUM), расширив его возможности. О версии 8.6 vRLCM мы писали вот тут.

Давайте посмотрим, что нового в vRLCM 8.8:

1. Управление жизненным циклом vRealize Orchestrator

Теперь Lifecycle Manager поддерживает решение по автоматизации операций vRealize Orchestrator, которое есть в составе пакета vRealize Automation (базовая версия), так и существует в виде отдельного продукта (полнофункциональная версия для производственной среды).

Теперь можно добавить существующий сервер vRealize Orchestrator, развернуть новый в составе vRealize Automation, либо создать отдельный инстанс vRO в рамках установки инфраструктуры vRA:

Помните, что vRealize Orchestrator нельзя установить без наличия в инфраструктуре сервисов vRealize Automation. Импорт существующего инстанса выглядит очень просто:

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

После импорта иконка vRealize Orchestrator будет отображаться на карточке виртуального окружения:

Так как vRO ассоциирован с установленным vRA, то действия Day 2 для vRO появятся как подвкладка для продукта vRealize Automation:

Действия Day 2 для управления жизненным циклом доступны из меню в правом верхнем углу:

2. Улучшения для vRealize Automation

Раньше при снятии снапшота инфраструктуры vRealize Automation перед апгрейдом кластера требовалось около 10 минут на правильное выключение всех систем. Теперь это время было уменьшено в рамках улучшений рабочих процессов при создании онлайн-снапшота и откате к нему. Перед апгрейдом vRLCM проверяет нормальное функционирование vRealize Automation.

Второе улучшение в vRealize Automation Cloud - это поддержка развертывания Cloud Extensibility Proxy. Раньше карточка для прокси была, но доступна она была только для стандартных прокси. Теперь при создании нового прокси он будет развернут как extensibility service. На картинке ниже показано отличие от предыдущей версии:

3. Кластеры VMware Identity Manager

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

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

Обратите внимание, что все узлы должны использовать одну сеть в рамках серверов vCenter Server.

4. Улучшенные нотификации

Теперь появились нотификации для состояния лицензий и их устаревания:

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

Еще одно улучшение - это дополнительный шаг валидации при добавлении webhook URL для Slack и Teams, чтобы сразу убедиться в том, что параметры указаны верно (отсылается тестовое сообщение).

5. Улучшения VMware Cloud Foundation

В этом релизе появилась автоматическая установка менеджмент паков VMware Identity Manager и SDDC Health как части развертывания vRealize Operations. Это нужные паки для мониторинга окружения VMware Cloud Foundation, которые раньше устанавливались вручную.

Начиная с VMware Cloud Foundation 4.4 и vRealize Suite Lifecycle Manager 8.6.2, развертывание продуктов семейства vRealize контролируется vRLCM. Это позволяет пользователям делать апгрейд продуктов, как только выходят их новые версии, без необходимости ждать, пока обновится список поддерживаемых систем VMware Cloud Foundation BOM.

Теперь пользователи могут проводить апгрейды продуктов vRealize в режиме поддержки VMware Cloud Foundation, что сокращает время самого апгрейда. Это поддерживается для продуктов vRealize, начиная с версии 8.1.

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

Еще одно улучшение тут - это обработка изменений пароля vCenter. Теперь SDDC Manager может регулярно менять пароли vCenter Server, которые автоматически обновляются в хранилище Realize Suite Lifecycle Manager.

6. Улучшения Content Management

В этом релизе исправлена ошибка, когда контент не удалялся из источника (например, GitHub) при обновлении.

Подробнее о VMware vRealize Suite Lifecycle Manager 8.8 можно узнать по этой ссылке. Release Notes на русском языке доступны тут.

На сайте проекта VMware Labs появилось очередное обновление утилиты vRealize Build Tools 2.23. Напомним, что это средство позволяет разработчикам и администраторам, работая совместно, реализовывать новые сценарии и рабочие процессы vRealize Automation (vRA) и vRealize Orchestrator (vRO), используя стандартные практики DevOps.

Об одной из прошлых версий этого решения 2.20 мы писали вот тут, а теперь давайте посмотрим на нововведения двух последних версий (2.22.1 и 2.23):

• Поддержка composite type values для vRO
• Возможность выбора кастомных файлов для конвертации кода на базе git branch
• Исправлены ошибки типа NullPointerException с аутентификацией, профилями хранилищ, файлами json и свойством formFormat
• Возможность заменить свойством serverId поля учетной записи для всех типов проектов
• Исправлена ошибка с исчезновением кастомного ресурса при импорте multi-tenant окружения, когда указан его ID
• Исправлены ошибки экспорта при обработке алиасов
• Теперь корректно обрабатываются определения интерфейсов vro-type-defs
• Добавлены определения типов для плагина MQTT vRO
• Удален плагин vRO hint из vRBT
• Установщик удаляет ненужные файлы, которые уже импортированы
• Исправлена ошибка с polyglot-cache

Скачать VMware vRealize Build Tools 2.23 можно по этой ссылке.

В декабре прошлого года компания VMware анонсировала обновление решения VMware NSX-T 3.2, предназначенного для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров, физических серверов и контейнеров приложений Kubernetes.

В новой версии этой платформы появились функции URL Filtering, позволяющие фильтровать доступ к веб-сайтам по их адресу на базе таких параметров, как категория URL, его репутация, а также различные кастомные правила. Сегодня мы приведем перевод статьи сайта Yo Go Virtual о том, как работать с этим механизмом.

URL filtering поддерживается только на шлюзе Tier-1 Gateway. Политика Access Control Policy для URL filtering применяется как к обычному http-трафику, так и для шифрованного https-канала, для которого нужно включить политику TLS Inspection, чтобы расшифровать трафик. Без включенного TLS inspection функция URL filtering будет использоваться на уровне домена с использованием расширения TLS Server Name Indication (SNI) в клиенте TLS hello. Эта возможность работает совместно с FQDN Analysis (которая ранее называлась URL Analysis в NSX-T 3.0).

Функция URL Filtering настраивается в профиле L7 access profile для правил сетевого экрана шлюза. Сначала мы включаем URL Database для кластера Edge Cluster, где мы хотим использовать эту возможность. Это вызовет скачивание базы данных URL из NSX Threat Intelligence Cloud Service.

Чтобы это сделать, идем в:

NSX Manager -> Security -> General Settings -> URL Database

Теперь надо создать L7 access profile, для чего идем в:

NSX Manager -> Inventory -> Profiles -> L7 Access Profiles

Нажимаем ADD L7 ACCESS PROFILE и вводим имя профиля:

Нажимаем Set в колонке создания одного или нескольких атрибутов Attribute Entries:

Нажимаем ADD ATTRIBUTE TYPE, где можно выбрать различные типы добавляемого атрибута...Читать статью далее->

Известные блогеры, пишущие о платформе виртуализации VMware vSphere и системе отказоустойчивых хранилищ VMware vSAN - Дункан Эппинг и Кормак Хоган - обновили свою совместную книгу, посвященную расширенным настройкам инфраструктуры хранения - VMware vSAN Deep Dive 7.0 Update 3.

На 632 страницах Дункан и Кормак разбирают все самые полезные и глубокие настройки инфраструктуры отказоустойчивых хранилищ, с учетом последних нововведений, появившихся в vSAN 7 Update 3. Кстати, последняя версия книги была для vSAN 6.7 U1, поэтому обновление очень актуально именно сегодня. В книге рассматриваются все новые технологии, такие как vSAN File Service и HCI-Mesh.

Также не обошли стороной такие вещи, как поддержка режима Compression Only, Durability Components и изменения, связанные с функционалом резервирования ресурсов и Capacity Management. В книге рассматривается не только развертывание и первоначальная настройка отказоустойчивых кластеров хранения, но и Day-2 операции, связанные с решением задач, возникающих в процессе ежедневной эксплуатации платформы.

Книга в электронном варианте стоит 12 долларов, с подпиской Kindle Unlimited ее можно получить бесплатно.

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

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

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

Вот что нового в последнее время появилось о Project Monterey:

1. Документ от IDC - "Project Monterey: Evolving Infrastructure to Accelerate and Secure All Your Workloads"

2. Небольшая брошюра "Propelling the Hybrid Cloud into a New Era of Accelerated Infrastructure with VMware vSphere"

Напомним также несколько интересных материалов про Project Monterey с ресурсов VMware:

• The rise of DPUs in the Infrastructure
• Announcing Project Monterey – Redefining Hybrid Cloud Architecture
• Project Monterey at VMworld 2021
• VMworld vChat: Project Monterey
• Project Monterey:The Excitement Builds One Year In
• Project Monterey Early Access Program Now Available to Enterprises [NVIDIA]
• Announcing the Project Monterey Early Access Program [VMware]

Ну и статьи на VM Guru, касающиеся Project Monterey:

• 3 главных новости о VMware vSphere: Project Capitola, Project Monterey и уход от загрузки с SD-карт
• VMware открывает Early Access Program для Project Monterey
• Анонсы VMware VMworld 2020 Online - Project Monterey
  

На днях компания VMware обновила свое решение VMware vRealize Operations Cloud, предназначенное для комплексного управления и мониторинга виртуальной облачной инфраструктуры в различных аспектах. Напомним, что о февральских нововведениях этой платформы мы писали вот тут. vRealize Operations Cloud теперь объединяет датацентры в 9 странах, недавно оборудование было размещено в Индии.

Итак, что нового в vROPs Cloud May 2022:

1. In-App Guides для расчета затрат и емкостей

В платформе vROPs Cloud для новичков есть руководства по использованию различной функциональности (Guided Tours). Эти руководства позволяют вам учиться работать с дашбордами и отчетами, а также создавать алерты и решать различного рода проблемы. Теперь вот были добавлены руководства по управлению емкостями и затратами (capacity and cost management).

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

2. Размещение рабочих нагрузок с помощью vRealize Automation

vRealize Operations Cloud имеет тесную интеграцию с облачной платформой vRealize Automation Cloud. Она позволяет отслеживать производительность вашей инфраструктуры, оценивать затраты на нее и определять первоначальное размещение рабочих нагрузок в облаке. В этом обновлении вы можете создать модель доступных емкостей и на базе нее определить размещение систем. Это позволить контролировать переподписку доступных емкостей (overcommit) для наиболее критичных нагрузок.

3. Улучшения алертов

В пришлом году для механизма алертинга был добавлен компонент Conditions в дополнение к Symptoms. Напомним, что Condition привязан к одному определению алерта и представляет собой однозначное условие срабатывания, а Symptom - можно привязывать к разным определениям алертов, чтобы, например, оповещать разные группы поддержки и администрирования (это позволяет изменять симптом, не изменяя определения алертов).

В этом обновлении такой механизм добавлен для алертов, созданных в Troubleshooting Workbench или на вкладке метрик объектов. Также если вы создаете ad-hoc алерт, который использует ту же метрику, что и уже существующий, vRealize Operation предлагает обновить эту метрику вместо того, чтобы создавать дублированное определение алерта.

4. Управление доступом

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

5. Поддержка хранилищ Raw Device Mapping

Теперь vRealize Operations Cloud собирает детали конфигурации о томах RDM, такие как режим совместимости (compatibility mode), режим общих дисков (disk sharing), SCSI Bus Sharing, а также число томов RDM, связанных с конкретной ВМ.

Более подробная информация об обновлении vRealize Operations Cloud приведена в Release Notes. Пробную версию данной платформы можно запросить по этой ссылке.

В конце апреля компании VMware и Oracle выпустили обновление публичной облачной платформы Oracle Cloud VMware Solution (OCVS). Новый весенний релиз включает в себя много интересных возможностей, главной из которых стала более тесная интеграция нативных служб Oracle Cloud Infrastructure (OCI) и средств управления виртуальной облачной инфраструктурой от VMware.

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

1. Новый тип хоста OCVS ESXi на базе AMD EPYC E4 Dense

Он предназначен для тяжелых нагрузок, требовательных к памяти и интенсивности использования хранилищ. Теперь есть 3 варианта хостов E4 Dense ESXi с числом ядер 32, 64 или 128, с тактовой частотой 2.55 ГГц в базовом варианте и до 3.5 ГГц в режиме максимального ускорения.

Все конфигурации идут с 2 ТБ RAM на борту, сетью 100 Gbps и 54.4 ТБ хранилища на базе NVMe.

2. Защищенные инстансы VMware

Теперь есть так называемые "Shielded VMware Instances", которые надежно защищены от атак типа Ransomware. Эти инстансы используют комбинацию технологий Secure Boot и Trusted Platform Module (TPM) для того, чтобы убедиться, что ОС и установленные в ней приложения загружаются из валидированной конфигурации.

Эта технология интегрирована со службой OCVS Provisioning Service и может быть включена для всех серверов кластера. Система не загружает драйверы UEFI или приложения, пока загрузчик ОС не подписан криптографической подписью, а устанавливать можно только подписанные пакеты vSphere Installation Bundles (VIB). Аппаратные чипы TPM 2.0 проверяют целостность платформы, сам процесс валидации вы можете отслеживать через vSphere Client.

3. Интеграция хостов OCVS ESXi со службами OCI File Storage Services

На базе всего трех узлов OCVS можно построить высокопроизводительный кластер хранилищ объемом 120 ТБ средствами служб VMware vSAN. VMware и Oracle валидировали их работу на базе файловой системы Network File System version 3.0 (NFSv3).

Для облачных инстансов доступны службы мониторинга и нотификаций OCI с использованием электронной почты, сервисов PagerDuty и Slack. Служба OCI Infrastructure Health Monitoring теперь полностью настроена и работает для bare-metal хостов. С помощью службы OCI Observability Service администраторы могут настроить алармы и нотификации на базе инфраструктурных метрик. Эти возможности могут работать совместно с традиционно используемыми средствами мониторинга и оповещений.

4. Валидация решений VMware Site Recovery Manager и VMware vRealize Cloud Management с OCVS

Теперь решение VMware SRM полностью валидировано в облаке OCVS, об этом подробнее можно почитать в Oracle Site Recovery Manager on OCVS Playbook. Лицензия на Site Recovery Manager for OCVS включена в издание "Site Recover Manager for Hyperscalers".

Также vRealize Cloud Management полностью валидировано с OCVS в 37 регионах OCI Cloud Regions. Теперь следующие продукты вы можете использовать в облаке OCVS:

• vRealize Operations Cloud
• vRealize Automation Cloud
• vRealize Log Insight Cloud
• vRealize Network Insight Cloud

5. Валидация VMware Horizon в облаке OCVS

Ранее от пользователей был большой интерес к размещению инфраструктуры виртуальных ПК (VDI) в облаке OCVS, теперь это решение полностью валидировано, о чем написано в KB 88202.

6. Валидация VMware Tanzu Standard edition в облаке OCVS

Решение VMware Tanzu Standard на базе кластеров Kubernetes теперь можно полноценно использовать в публичном облаке OCVS.

Более подробно о платформе Oracle Cloud VMware Solution можно узнать по этой ссылке.

На сайте проекта VMware Labs появилась новая специфическая утилита Mjolnir, которая представляет собой библиотеку автоматизации для VMware Mangle. Mjolnir - это пакет утилит, который позволяет делать fault injections на удаленных хостах. Это легковесная обертка, которая забирает VMware Mangle REST API на бэкенде для инициации отказов (inject fault) или возвращения нормального статуса (remediate) на хостовой машине.

Сам Mangle - это проект с открытым исходным кодом от VMware, который позволяет конечным пользователям выполнять операции в рамках концепции chaos engineering (то есть симуляции отказов для моделирования тех или иных ситуаций отказа и выработки способов реагирования на них). Сам продукт можно использовать как через API, так и через пользовательский интерфейс. Но для обычных пользователей этот API слишком сложно интегрировать в различные фреймворки автоматизации, поэтому и придумали Mjolnir.

С помощью Mjolnir можно делать fault injections путем 3 простых шагов во фреймворке пользователя, где он пишет свои сценарии. Это дает следующие преимущества:

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

Утилита является платформонезависимой, но оттестирована только на Linux and Windows. Распространяется как python wheel package, который можно установить с помощью стандартной команды pip3.

Скачать Mjolnir можно по этой ссылке. Документация по Mangle доступна тут.

Компания VMware несколько недель назад объявила о выпуске обновленной версии своей платформы для виртуализации и доставки настольных ПК и приложений VMware Horizon 8 2203 (так обозначается теперь релиз, последние четыре цифры - это год и месяц выпуска). Как обычно в новом релизе появилось несколько интересных возможностей, но не все они были описаны детально в Release Notes. Сегодня мы рассмотрим семь самых интересных и полезных нововведений, которые появились в платформе, и опишем их несколько детальнее.

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):