Как вы все знаете, на прошлой неделе прошла главная конференция по виртуализации этого странного года - VMworld 2020 Online. Несмотря на то, что она прошла онлайн, было сделано немало интересных объявлений, а перед самой конференцией были анонсированы главные обновления продуктовой линейки. Одним из них был скорый выпуск новой версии платформы VMware vSphere 7 Update 1, который и состоялся:

На днях также появилась возможность скачать новые версии нескольких продуктов, помимо vSphere 7 U1. Давайте посмотрим, какие именно решения были выпущены:

Скоро постараемся написать о том из этого, о чем еще не рассказали. Заходите чаще!

Продолжаем рассказывать об анонсах прошедшей на прошлой неделе конференции VMworld 2020 Online. В прошлый раз мы рассказывали о проекте Project Monterey, который является продолжением развития технологии Project Pacific для контейнеров на базе виртуальной инфраструктуры, а сегодня расскажем о новой сертификации.

Программа VMware Certified Technical Associate (VCTA) предназначена для тех специалистов, которые осуществляют ежедневные операции в виртуальной инфраструктуре. Обучающий курс в рамках данной сертификации затрагивает операции в нескольких облачных окружениях, настройку сети, безопасность и управление устройствами.

Если сравнивать сертификацию VCTA и VMware Certified Professional (VCP), то можно сказать, что первая - это, в основном, для начинающих администраторов, которые только погружаются в тему и отвечают за Day-2 операции, а VCP предполагает понимание всех аспектов виртуальной инфраструктуры, включая ее проектирование, развертывание и настройку.

При этом VCTA не является каким-то обязательным условием сертификации VCP, ее может получить любой желающий. Обучение происходит на портале VMware Customer Connect Learning. Основные треки сертификации VCTA:

• VCTA-DCV – доступно сейчас
• VCTA-NV – доступно сейчас
• VCTA-SEC – доступно сейчас
• VCTA-CMA – скоро будет доступно
• VCTA-DW – в разработке
• VCTA-AM – в разработке

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

На данный момент о сертификации VCTA есть документ с вопросами и ответами, который дает основные пояснения к программе. Также 27 октября пройдет онлайн-вебинар (регистрация тут), где будут озвучены основные детали новой сертификации.

На сайте проекта VMware Labs появилось очередное бесплатное средство для администраторов VMware vSphere - SQL30. Эта штука представляет собой ORM-обертку для легковесной БД SQLITE под ESXi.

Python нативно поддерживает взаимодействие с SQLITE за счет модуля "sqlite" (или sqlite3 в python3). Ну а решение SQLAlchemy - это популярная ORM, используемая для взаимодействия с базами данных sqlite из Python. Однако это решение не работает на ESXi, так как многие его пакеты имеют зависимости от других пакетов, которые не могут быть установлены на ESXi.

Решение SQL30 как замена SQLAlchemy - весьма легковесно и написано только с использованием нативных конструкций Python, а также не имеет никаких внешних зависимостей, поэтому работает на ESXi 6.5 и более поздних версиях.

SQL30 вам пригодится для:

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

На VMware ESXi 6.5 будет использоваться версия Python 3.5, что ниже актуальной версии 3.6, но все равно лучше чем ничего.

Скачать SQL30 можно тут. Инструкции по установки приведены вот здесь.

Как вы знаете, на прошлой неделе компания 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 были посвящены следующие сессии, которые вы можете найти тут:

Ждем!

На сайте проекта VMware Labs появилась очередная интересная и полезная штука - Python Utility for VMware Cloud Foundation Management. Она представляет собой утилиту командной строки для администрирования решения VMware Cloud Foundation через интерфейс SDDC Manager public API.

После установки у вас появится утилита vcfkite, которая позволит управлять инфраструктурой VCF через SDDC Manager. Она является кроссплатформенной и протестирована на Linux CentOS и Windows 2012.

Сама утилита это wheel-пакет, который можно развернуть с помощью нативной команды pip3:

# Install vcfkite wheel package
(flings-env) $ pip3 install vcfkite-1.0.0-py3-none-any.whl

Основное назначение данного средства - дать пользователям удобный инструмент для управления VMware Cloud Foundation API с помощью простого языка Python.

Для начала работы вам понадобится Python версии 3.6 или более поздней, а также VCF 4.0.1 или более поздняя.

Скачать Python Utility for VMware Cloud Foundation Management можно по этой ссылке.

Какое-то время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere 7 Update 1. Одним из главных улучшений стало увеличение максимальных параметров платформы, что привело к возможности организовывать кластер HA/DRS из еще большего числа хостов, а на самих хостах - исполнять виртуальные машины еще большего размера.

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

В кластере теперь может быть до 96 хостов, правда не все технологии поддерживают это число. Например, кластер VMware vSAN 7 Update 1 и топология HCI Mesh поддерживают все еще 64 хоста, а технология Native File Services в vSAN 7 U1 поддерживает только 32 хоста.

Самое большое улучшение - теперь в кластере может быть до 10 тысяч виртуальных машин, а это на 50% выше показателя vSphere седьмой версии:

Для виртуальных машин, находящихся под экстремальной нагрузкой, теперь поддерживается 768 виртуальных процессоров (vCPU) и до 24 ТБ памяти. Это больше, чем для виртуальных машин на любой из других облачных или онпремизных платформ:

К подобным нагрузкам можно отнести системы на базе SAP HANA и EPIC Cache Operational Database. Все эти ресурсы виртуальная машина может реально использовать:

Для виртуальной инфраструктуры в целом на базе одного кластера в Sphere 7 Update 1 максимальные показатели следующие: 393 216 vCPU (96 хостов по 4 096 vCPU) / 2.3 ПБ памяти (96 хостов по 24 ТБ):

Если говорить об исполнении контейнеров vSphere with Tanzu в такой инфраструктуре, то их может поместиться просто огромное количество. Согласно статистике, средний размер контейнера составляет 1 vCPU и 400 МБ памяти (например, контейнер node.js "кушает" 1/3 CPU и 384 МБ памяти). Таких контейнеров в одном кластере vSphere 7 U1 может быть запущено 393 216 штук. А контейнеров node.js можно запустить до миллиона экземпляров!

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

Ранее vMotion могла не пройти для больших ВМ, которые имели более 64 vCPU и 512 ГБ памяти (они же Monster VMs). В документе "vMotion Innovations in vSphere 7.0 U1" можно найти конкретное описание улучшений. Давайте посмотрим на них вкратце.

Прежде всего, VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.  

В документе выше для примера делается миграция vMotion сервера БД Oracle, запущенного в виртуальной машине с 72-vCPU / 1 TБ памяти на борту. На картинке ниже показано число тразакций в секунду с шагом как раз в секунду - до, во время и после vMotion (тест HammerDB):

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

• Общее время миграции уменьшилось более чем в 2 раза (с 271 секунды до 120 секунд)
• Итоговое время для установления трассировки уменьшилось с 86 секунд до 7.5 секунд (снизилось в 11 раз)
• Общее проседание пропускной способности во время миграции - на 50% для vSphere 6.7 и всего лишь 5% для vSphere 7.0 Update 1
• Ответ Oracle во время переключения в среднем стал менее одной секунды, а ранее составлял более 6 секунд

Второй тест проводили для миграции vMotion сервера БД Oracle в виртуальной машине с 12 vCPU / 64 ГБ памяти для vSphere 6.7 и vSphere 7.0 U1. На картинке ниже показано число транзакций в секунду с шагом в полсекунды - до, во время и после vMotion (тест HammerDB):

Основные результаты теста:

• Общее время горячей миграции сократилось с 23 секунд в vSphere 6.7 до 11 секунд в vSphere 7.0 U1 (уменьшение в 2 раза)
• Итоговое время для установления трассировки уменьшилось с 2.8 секунд до 0.4 секунд (снизилось в 7 раз)
• Увеличение полосы пропускания где-то на 45% (около 3480 транзакций в секунду, по сравнению с 2403 транзакции в секунду)

Остальные интересные подробности приведены в документе "vMotion Innovations in vSphere 7.0 U1".

На сайте VMware Labs появилась очень нужная многим администраторам вещь - генератор сертификатов VMCA Certificate Generator. С помощью этой утилиты можно получить сертификаты, подписанные центром сертификации VMware Certificate Authority (VMCA) со стороны сервера VMware vCenter / Platform Services Controller (PSC), и использовать их в сервисах VMware или любых других сторонних сервисах.

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

Полученные сертификаты можно использовать для таких продуктов, как vRealize Suite и NSX, а также других из корпоративной линейки VMware. Надо понимать, что если вы доверяете корневому сертификату VMCA, то вы доверяете и всем службам, использующим данные сертификаты.

Срок действия сертификатов вы не можете настраивать, это зависит от версии vCenter. Для vCenter 7.0 вы получите сертификаты сроком действия 2 года.

VMCA Certificate Generator поставляется в виде .jar-файла, который нужно открывать по правой кнопке и выбирать пункт меню "open with jar Launcher", либо надо выполнить следующую команду:

java -jar vmca-cert-generator.jar

Выглядит интерфейс утилиты следующим образом:

Для соединения с vCenter/PSC нужно заполнить данные доступа к серверу и данные сертификата, который необходимо выписать. Далее нужно нажать кнопку "START". Начнется процесс создания сертификата с выводом лога, после чего станет активна кнопка "DOWNLOAD", по нажатию на которую вы получите zip-архив со следующим содержимым:

• certool.cfg - конфиг настроек сертификата
• root.cer - корневой VMCA-сертификат
• Ключи private.key и public.key
• .cer - сертификат в формате X509
• .pfx - зашифрованный сертификат в формате PKCS#12 (пароль для него будет тот, который вы указывали в форме выше)
• chain-with-privkey.pem - цепочка сертификата, включая приватный ключ
• chain-without-privkey.pem - цепочка сертификата без приватного ключа

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

Для работы генератора вам потребуется среда Java Runtime (протестирована версия 1.8.x) и сервер vCenter 6.7 / 7.0. Скачать VMCA Certificate Generator можно по этой ссылке.

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

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

Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.

Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:

• Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
• SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
• SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).

Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).

Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.

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

Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.

Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).

Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.

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

С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.

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

Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:

Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.

На этой неделе компания VMware опубликовала новость об окончании поддержки браузера Internet Explorer 11. Шаг этот совершенно логичен, поскольку сама Microsoft анонсировала окончание поддержки Explorer 11 продуктами линейки MS365 (вот официальный guidance). Пользователям предлагается мигрировать на браузер Edge.

Поддержка IE 11 будет прекращена всеми активными версиями vSphere Client, начиная со следующего за vSphere 7.0 Update 1 релиза платформы. На самом деле, де-факто IE 11 был в опале уже довольно давно, и его использует менее 2% пользователей согласно статистике (большинство, конечно же, корпоративные). Одна из причин, помимо качества предоставляемого сервиса (стабильность и производительность) - недостаточная защищенность (смотрим пример от января этого года).

Также IE не поддерживает новые возможности HTML5, не имеет полной поддержки CSS, WebAPI и WebGL. Работает vSphere Client в IE намного хуже, чем в других современных браузерах. Также там возникает много ошибок, работая с которыми VMware тратит много ресурсов.

Таким образом, скоро IE 11 вылетит из списка совместимых браузеров для vSphere Client. Случится это для всех версий с выходом vSphere 7 Update 2. В общем, имейте в виду.

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также обновленных функциях платформы для организации кластеров хранилищ VMware vSAN 7 Update 1.

Одной из новых возможностей VMware vSphere 7 U1 стала служба vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter.

Как вы знаете, кластер HA/DRS очень зависит от постоянной доступности сервисов vCenter, который является критическим звеном виртуальной инфраструктуры. Поэтому для него организовывают такие сервисы, как vCenter Server High Availability (VCHA), но и они не идеальны. Также проблема наблюдается при масштабировании кластеров в больших окружениях, которые объединяют онпремизные и облачные площадки, где масштабируемость vCenter является серьезной проблемой.

Учитывая это, VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:

Таких виртуальных машин три в кластере, где 3 или более хостов, и две, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.

Три этих виртуальных машин следят друг за другом и оповещают об этом кластерные службы vCenter:

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

Есть 3 состояния служб vCLS:

• Healthy – как минимум 1 агентская ВМ работает в кластере, чтобы обеспечить доступность кластера развертываются 3 ВМ для кворума.
• Degraded – как минимум одна агентская машина недоступна, но DRS продолжает функционировать и исполнять свою логику. Такое может, например, произойти при передеплое служебных машин vCLS или после какого-то события, повлиявшего на их "включенность".
• Unhealthy – логика DRS не выполняется (балансировка или размещение ВМ), так как vCLS control-plane недоступна (то есть ни одной агентской ВМ не работает).

Легковесные машины-агенты исполняются на хостах ESXi и лежат на общих хранилищах, если общие хранилища недоступны - то на локальных дисках. Если вы развернули общие хранилища после того, как собрали кластер DRS/HA (например, развернули vSAN), то рекомендуется перенести агентские ВМ с локальных хранилищ на общие.

Сама гостевая ОС агентских ВМ очень легковесная, используется Photon OS следующей конфигурации:

Диск в 2 ГБ - это тонкий диск, растущий по мере наполнения данными (thin provisioned). Эти машины не имеют своего нетворка, а также не видны в представлении Hosts and Clusters в клиенте vSphere.

Агентские ВМ можно увидеть в представлении VMs and Templates где есть папка vCLS:

Обратите внимание, написано, что для агентских ВМ управление питанием производится со стороны служб vCLS. Если вы попытаетесь выключить эти ВМ, то будет показано следующее предупреждение:

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

Жизненный цикл агентских ВМ обслуживается со стороны vSphere ESX Agent Manager (EAM).

EAM отвечает за развертывание и включение агентских ВМ, а также их пересоздание, если с ними что-то произошло. В анимации ниже показано, как EAM восстанавливает ВМ, если пользователь выключил и/или удалил ее:

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

В интерфейсе vSphere Client список агентских ВМ можно вывести в разделе "Administration > vCenter Server Extensions > vSphere ESX Agent Manager".

У агентских ВМ есть свойства, по которым разработчик может понять, что это они. В частности:

• ManagedByInfo
  • extensionKey == "com.vmware.vim.eam"
  • type == "cluster-agent"

• ExtraConfig keys
  • "eam.agent.ovfPackageUrl"
  • "eam.agent.agencyMoId"
  • "eam.agent.agentMoId"

Основное свойство, по которому можно идентифицировать агентскую ВМ, это HDCS.agent, установленное в значение "true". В Managed Object Browser (MOB) выглядит это так:

Ну и напоследок - небольшое демо технологии vSphere Clustering Service:

Как вы знаете, у компании VMware есть клиент для управления отдельными хостами VMware ESXi, который называется VMware ESXi Embedded Host Client. Последний раз обновлялся он в феврале прошлого года, и VMware не уделяет ему никакого внимания.

Между тем, VMware рассказала о том, что в ближайшем будущем эта недоработка будет исправлена. Дело в том, что интерфейс существующего хост-клиента построен на базе фреймворка Angular JS web framework, последний стабильный релиз которого 1.7 вошел в фазу long term support 30 июня 2018 года. Начиная с 1 января 2022 года, Angular JS больше не будет поддерживаться со стороны Google.

Последующие релизы фреймворка (Angular 4 и более поздние) не будут совместимы с Angular JS. Соответственно, VMware пора уходить с технологии, которая скоро устареет. Поэтому Host Client переедет с технологии Angular JS на последнюю версию Angular web framework (сейчас это Angular 9).

Вместе с этим произойдет и удаление компонентов, которые зависят от Angular JS, а также апдейт основного графического фреймворка Clarity на третью версию.

Собственно, это та причина, по которой VMware не обновляет текущий ESXi Host Client. Этот клиент больше не будет получать новых возможностей, но будет получать некоторые текущие обновления.

А вот новый клиент выйдет уже как Single host managing UI (он же ESXi UI) во второй половине 2021 года.

Для старого клиента будут предоставляться только следующие обновления:

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

Новый ESXi UI будет являться частью ESXi Client и будет построен на базе Clarity 3 в его составе. Соответственно все процессы управления отдельным хостом ESXi будут аналогично таковым в рамках кластера под управлением vCenter.

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

Но первую версию нового клиента с базовой функциональностью нам обещают уже в первом квартале следующего года.

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также решения для создания отказоустойчивых хранилищ на базе хостов VMware vSAN 7 Update 1. В статье о vSAN мы упоминали о том, что VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Давайте посмотрим на эти возможности подробнее.

Во-первых, начнем с небольшого обзора от Дункана Эппинга:

Поддержка протокола SMB была введена в vSAN не просто так - целью была поддержка постоянных томов read-write many (RWM) volumes для cloud native applications (то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes). Для доступа поддерживаются хранилища SMB версий v2.1, так и v3 (SMB v1 находится в статусе Deprecated).

SMB-хранилища, создаваемые в vSAN, могут быть доступны из Windows-клиентов (версии 8/2012+) и Mac-клиентов (OS 10 и позднее). Это, совместно с поддержкой Active Directory, делает SMB-хранилища отличным вариантом для:

• VDI-сценариев, где пользователи предпочитают перенаправление каталога user/home на выделенную файловую шару.
• Файловые ресурсы, обслуживающие различные топологии (например, удаленные офисы или филиалы), могут управляться напрямую из vSAN, без необходимости иметь отдельную ВМ для предоставления общего доступа к папкам.

Файловые шары видны через Windows MMC, где администраторы могут: 

• Смотреть число клиентских соединений к шаре
• Смотреть число открытых файлов
• Управлять разрешениями и безопасностью (в стиле NTFS)
• Закрывать клиентские соединения
• Закрывать открытые файлы

Как мы писали выше, поддерживается и протокол аутентификации Kerberos, который предотвращает доступ NFS-клиентов через более уязвимые методы доступа, такие как auth_sys. vSAN поддерживает 3 модели аутентификации:

• KRB5, который проводит только безопасную аутентификацию (только на NFS v4.1)
• KRB5I, включая аутентификацию и проверку контрольных сумм
• KRB5P, включая аутентификацию, проверку контрольных сумм и шифрование

Надо отметить, что несмотря на то, что VMware vSphere 7 U1 поддерживает кластеры до 64 хостов, службы Native File Services поддерживают доступ до 32 хостов к файловым шарам.

Теперь службы Skyline Health (ранее это называлось "vSAN Health") содержат дополнительные хэлсчеки, включая file server health и share health:

Тут есть три основных типа проверок:

• Проверки Infrastructure health checks - развернута ли машина FSVM и демон VDFS, а также есть ли файловая система root на хосте. Если чего-то из этого нет, то проверка показывает красный сигнал.
• Проверки File Server Health checks показывают, все ли в порядке с файловым сервером на отдельных хостах, и есть ли там файловая система root. Если что-то из этого не в порядке - показывается красный сигнал.
• Проверки Share Health отвечают за статус объектов файловых шар. Если служба протокола не работает для данного объекта, то показывается красный сигнал. Также могут быть оповещения для шар - и тогда будет желтый.

Для файловых шар SMB появился мониторинг производительности в интерфейсе vSAN UI. Можно смотреть за пропускной способностью (throughput), IOPS, задержками (latency) на уровне отдельной шары в реальном времени. Можно увеличивать временное окно просмотра для отдельных метрик. Также эти метрики доступны через API, поэтому такие продукты, как vRealize Operations также будут их использовать.

Доступную емкость SMB-хранилищ можно отслеживать через vSAN Capacity view:

Если вы нажмете на ссылку File shares overview в левом нижнем углу, то сможете открыть просмотр емкости на уровне отдельных шар. На картинке ниже представлен микс из SMB и NFS хранилищ, столбики в Usage/Quota показывают жесткие аппаратные квоты с цветовым кодированием заполненности:

Ну и напоследок небольшой обзор VMware vSAN File Services от VMware:

На сайте проекта VMware Labs вышла очередная полезность - сценарий для интеграции VMware vRealize Network Insight (vRNI) и VMware HCX. Напомним, что vRNI - это решение для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений, а HCX - продукт для миграций с различных опремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud.

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

Затем эти vRNI application constructs интегрируются в объекты HCX Mobility Groups, экономя время на ручное создание этих сущностей. После подготовки объектов вы можете начать сам процесс миграции виртуальных машин.

Для работы сценария оба продукта vRNI и HCX должны иметь лицензию Enterprise, также у вас должны быть установлены модули PowervRNI and the PowerCLI HCX.

Пример использования сценария:

$vrni_pw = ConvertTo-SecureString 'admin' -AsPlainText -Force
$hcx_pw = ConvertTo-SecureString 'VMware1!' -AsPlainText -Force
./sync-vrni-to-hcx.ps1 -vRNI_Server 10.196.164.134 -vRNI_Username admin@local -vRNI_Password $vrni_pw -HCX_Server hcxe.vrni.cmbu.local -HCX_Username hcx@cmbu.local -HCX_Password $hcx_pw -HCX_DestinationVC vc-pks.vrni.cmbu.local -HCX_DestinationCloud hcxc.vrni.cmbu.local
[03-05-2020_05:19:59] Connecting to vRealize Network Insight..
[03-05-2020_05:20:01] Retrieving all applications..
[03-05-2020_05:20:20] Found application: 'onprem_imagic' with 6 VMs
[03-05-2020_05:20:22] Found application: '3TierApp02' with 1 VMs
[03-05-2020_05:20:25] Found application: 'HIVE Training' with 1 VMs
[03-05-2020_05:20:27] Found application: 'VDI Pool 1' with 8 VMs
[03-05-2020_05:20:29] Found application: 'app_mcclanahanc' with 2 VMs
[03-05-2020_05:20:31] Found application: 'Top-Video' with 15 VMs
[03-05-2020_05:20:33] Found application: 'F5-3TierApp05' with 5 VMs
[03-05-2020_05:20:34] Connecting to VMware HCX..
[03-05-2020_05:20:48] Created Mobility Group: 'onprem_imagic_2020-03-05'
[03-05-2020_05:20:49] Created Mobility Group: '3TierApp02_2020-03-05'
[03-05-2020_05:20:50] Created Mobility Group: 'HIVE Training_2020-03-05'
[03-05-2020_05:20:51] Created Mobility Group: 'VDI Pool 1_2020-03-05'
[03-05-2020_05:20:52] Created Mobility Group: 'app_mcclanahanc_2020-03-05'
[03-05-2020_05:20:53] Created Mobility Group: 'Top-Video_2020-03-05'
[03-05-2020_05:20:54] Created Mobility Group: 'F5-3TierApp05_2020-03-05'

Инструкции по использованию скрипта приведены здесь, а сам он доступен по этой ссылке на GitHub.

Компания VMware, сразу после анонсов новых версий VMware vSAN 7 Update 1 и VMware Cloud Foundation 4.1, объявила о скорой доступности для загрузки новой версии своей серверной платформы виртуализации VMware vSphere 7 Update 1.

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

Вот небольшой обзор платформы VMware vSphere with Tanzu, о первых объявлениях компонентов которой мы уже писали тут и тут (а о текущей версии рассказано в блоге VMware):

Нововведения vSphere 7 U1 разбиты на 3 блока:

• Инфраструктура для разработчиков (контейнеры)
• Продолжение масштабирования возможностей платформы
• Упрощение операций администраторов

Итак, давайте посмотрим, что нового в VMware vSphere 7 Update 1:

1. Инфраструктура для разработчиков

Здесь VMware добавила следующие важные возможности:

• Служба Tanzu Kubernetes Grid (TKG) - о ней мы упоминали вот тут. Она позволяет администраторам развертывать Kubernetes-окружения и управлять их составляющими с помощью решения для кластеров Tanzu Kubernetes. Делается это теперь за минуты вместо часов. Также TKG идет в соответствии с политиками upstream Kubernetes, что позволяет сделать процесс миграции максимально бесшовным.
• Bring Your Own Networking - пользователи могут выбирать, какой сетевой стек использовать для кластеров Tanzu Kubernetes. Можно использовать традиционную инфраструктуру на базе vSphere Distributed Switch (vDS) для конфигурации, мониторинга и администрирования виртуальных машин и кластеров Kubernetes. Новый Networking for Tanzu Kubernetes clusters позволяет использовать и решения VMware NSX. Также можно использовать Antrea для максимальной производительности внутренней сети для сервисов Tanzu Kubernetes Grid.
• Bring Your Own Load Balancer - можно выбирать тип балансировки L4 для кластеров Tanzu Kubernetes. Первым партнером VMware стало решение HAProxy в формате виртуального модуля OVA.
• Application-focused management - теперь пользователи могут применять vCenter не только для управления виртуальными машинами, но и для обслуживания, мониторинга и траблшутинга инфраструктуры контейнеров, включая приложения и неймспейсы (подход application focused management).

2. Продолжение масштабирования возможностей платформы

В этой категории нужно отметить следующие возможности:

• Monster VMs - для пользователей решений SAP HANA, Epic Operational Databases, InterSystems Cache и IRIS компания VMware позволяет масштабировать виртуальные машин до 24 ТБ памяти и до 768 виртуальных процессоров (vCPU). То есть все ресурсы хоста могут быть предоставлены виртуальной машине, требующей их большое количество. Это было сделано за счет улучшения планировщика ESXi, а также логики ко-шедулинга для больших ВМ.

• Cluster scale enhancements - теперь в   vSphere 7 U1 кластер может содержать до 96 хостов! Это на 50% больше значения в релизе vSphere 7 (64 штуки):

3. Упрощение операций администраторов

• vSphere Lifecycle Manager - теперь vLCM поддерживает и хосты vSAN, и конфигурацию сетевого стека NSX-T. В vSphere 7 Update 1 решение vLCM также мониторит соответствие образов непрерывно, что позволяет вовремя запустить процесс обновления (remediation).

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

• vCenter Connect - теперь пользователи могут управлять своими виртуальными ресурсами VMware Cloud on AWS или в других облаках на базе vCenter из единого интерфейса.

Доступность для загрузки VMware vSphere 7 Update 1 ожидается в рамках или после конференции VMworld Online 2020. Следите за нашими обновлениями!

Вчера компания VMware сделала сразу несколько интересных анонсов. Одним из них стало объявление о скором выпуске новой версии платформы VMware vSAN 7 Update 1, а сегодня мы расскажем еще об одной интересной вещи - обновлении VMware Cloud Foundation 4.1.

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

Новый релиз продолжает развитие функций прошлой версии, где появилась интеграция с Tanzu, добавляя возможности в рамках подхода "developer ready infrastructure".

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

1. Платформа vSAN Data Persistence Platform

vSAN Data Persistence предоставляет фреймворк для сервис-провайдеров, который позволяет построить глубокую интеграцию Kubernetes с нижележащей виртуальной инфраструктурой за счет метода Kubernetes operator и службы vSphere Pod Service. Эта платформа создана для партнерских решений, поэтому ее физическое воплощение мы увидим, когда кто-то из разработчиков сделает под нее свои продукты. Более подробно об этом можно почитать вот тут.

В числе первых партнеров будут:

• Cloudian
• DataStax
• Dell Technologies
• MinIO

2. Технология VMware Cloud Foundation Remote Clusters

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

3. VVols как основное хранилище VCF Workload Domain

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

4. Функции автоматизации для vRealize Suite 8

VMware Cloud Foundation 4.1 позволит автоматически развертывать vRealize Suite 8.1. Продукт vRealize Suite Life Cycle Manager (vRSLCM) развертывается со стороны SDDC manager, а сам vRSLCM теперь знает о VCF и отвечает после установки за все компоненты, что упрощает управление программным обеспечением и развертывание новых систем.

5. Улучшения SDDC Manager

В главной управляющей консоли появилось множество небольших улучшений. Например, администраторы могут пропускать прошлые релизы и позволять кластерам NSX-T обновляться в параллельном режиме. Кроме того, в SDDC Manager появились сервисные аккаунты для упрощения коммуникаций между SDDC manager и другими продуктами в составе Cloud Foundation.

6. Поддержка VCF со стороны VMware Skyline

Служба VMware Skyline для VCF позволяет не только отслеживать и решать текущие проблемы в рамках управляющих и рабочих доменов, которые теперь видны для Skyline, но и проактивно формировать предложения по инфраструктуре VMware Cloud Foundation.

Доступность VMware Cloud Foundation 4.1 ожидается в самое ближайшее время (возможно, после предстоящего VMworld Online 2020).

Компания VMware анонсировала новую версию платформы для создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 7.0 Update 1. Напомним, что о прошлой версии vSAN 7 мы писали вот тут.

Данная версия vSAN сфокусирована на функциях по обеспечению эффективности датацентра, которые нацелены на увеличения возврата инвестиций в оборудование и программное обеспечение:

Новые возможности VMware vSAN 7 U1 можно разделить на 3 категории:

• Эффективность и производительность
• Упрощение операций с инфраструктурой хранения
• Интеграция с облачной инфраструктурой

1. Технология HCI Mesh

Главная из новых возможностей - это технология VMware HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):

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

В такой конфигурации можно делать vMotion виртуальных машин между кластерами vSAN, но хранилище (Storage vMotion) при этом перемещать нельзя.

Также в топологии HCI Mesh можно использовать подход Full Mesh, когда один и тот же кластер выступает и клиентом, и сервером:

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

Особенности технологии HCI Mesh:

• Минимальное число узлов кластера-клиента и кластера-сервера - 2 узла
• Технически Compute-only vSAN cluster (без своих датасторов) сейчас работает, но не рекомендуется к использованию и не поддерживается
• Поддерживается одновременное использование хранилищ Hybrid (SSD+HDD) и All-Flash одновременно

Небольшой обзор технологии:

2. Поддержка SMB для vSAN Native File Services

VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Таким образом, vSAN теперь поддерживает NFS (версии 3 и 4.1) и SMB.

3. Шифрование vSAN Data-in-Transit Encryption

Теперь в vSAN 7 Update 1 есть возможность шифрования при передаче данных между узлами кластера по протоколу TCP с использованием крипто-модуля FIPS-2. При этом вам не потребуется использовать Key Management Server (KMS).

Также надо отметить, что одновременное использование HCI Mesh и Data-in-Transit Encryption не поддерживается.

4. Техника SSD Secure Erase

В vSAN 7 Update 1 появился надежный способ удаления данных с SSD-дисков. Пока это поддерживается только для оборудования Dell и HPE. Например, это можно будет использовать для готовых серверных узлов vSAN Ready Nodes и комплектов DellEMC VxRail.

5. Общая оптимизация производительности

Как и всегда, VMware проводит работу над улучшением vSAN в контексте производительности. Заявляется, что vSAN 7 Update 1 работает примерно на 30% быстрее при выполнении операций, чем vSAN 6.7 U3 (который до этого был самым производительным).

6. Возможность использования компрессии без дедупликации

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

Дедупликация

• На уровне дисковой группы
• Работает при дестейджинге данных на capacity tier
• Работа с фиксированными блоками 4 КБ

Компрессия

• Работает после дедупликации, но до того, как данные дестейджатся
• Если блок можно сжать до 2 КБ или менее, то он сжимается
• Иначе сохраняется блок 4 КБ

Компрессия работает значительно быстрее дедупликации, поэтому ее отдельно удобно использовать для OLTP-нагрузок.

7. Функция Enhanced durability при выполнении операций обслуживания

Если хост ESXi находится в режиме обслуживания (maintenance mode), то vSAN теперь имеет механизм защиты данных, которые в этот период находятся только в одном экземпляре (у них был задан failures to tolerate равный 1, а а хост перевели в режим обслуживания - и теперь есть только одна активная реплика данных).

В таком случае vSAN понимает, что у вас был FTT=1, и на время обслуживания все операции записи начинает дублировать на выделенный хост для delta writes, чтобы вы не потеряли данные во время отказа хоста с единственной копией данных:

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

Данный механизм можно использовать как для RAID Mirroring, так и для Erasure Coding.

8. Быстрая перезагрузка и ускоренный апгрейд кластеров

• Существенное ускорение апгрейда кластеров за счет более быстрой перезагрузки хостов
• Метаданные хоста записываются на диск перед перезагрузкой и восстанавливаются в память после загрузки - это ускоряет актуализацию метаданных
• Как результат - хосты загружаются до 5 раз быстрее

9. Общий witness-хост для нескольких кластеров

Это очень удобно для ROBO-инсталляций. vSAN 7 Update 1 поддерживает до 64 кластеров в двухузловых конфигурациях с общим witness для ROBO-сценариев (это решения для удаленных офисов и филиалов - Remote or Branch Offices).

10. Оптимизация всегда доступной емкости (Slack Space)

По рекомендациям VMware нужно было всегда держать 25-30% свободной емкости хранилищ в кластере. Это называлось Slack Space. Теперь это называется Reserved Capacity, и ее необходимый объем зависит о числа узлов в кластере (чем меньше узлов - тем меньше емкость), например:

• 12 node cluster = ~16%
• 24 node cluster = ~12%
• 48 node cluster =~ 10%

Эта емкость нужна для:

• Операций Resync при изменении политик, ребалансировке, перемещении данных (Operations Reserve)
• Активностей Rebuild при отказах хранилищ и хостов (Host Rebuild Reserve)

Надо понимать, что Reserved Capacity предотвращает только развертывание новых виртуальных машин, но не затрагивает ввод-вывод уже имеющихся.

Также Reserved Capacity - это опциональный механизм, который не включен по умолчанию:

Функция vSAN Reserved Capacity не поддерживается для растянутых кластеров и двухузловых конфигураций.

11. Улучшения vSphere Lifecycle Manager (vLCM)

Еще в vSAN 7 поддерживались узлы Dell и HPE для решения vLCM, теперь же к ним добавилось и оборудование Lenovo ReadyNode.

Сам vLCM получил следующие улучшения:

• Работа с vSAN Fault Domains, двухузловыми конфигурациями и растянутыми кластерами (Stretched Clusters)
• Предпроверки Hardware compatibility pre-checks
• Параллельное обновление кластера до 64 хостов
• Поддержка окружений с NSX-T 3.1

12. Упрощенная маршрутизация для некоторых топологий

Раньше для топологии vSAN с внешним witness должны были иметь статическую маршрутизацию. Теперь в vSAN 7 Update 1 можно добавить шлюз по умолчанию и не прописывать статические маршруты:

13. Утилита vSAN I/O Insight

С помощью этого средства можно анализировать I/O-паттерны для анализа рабочих нагрузок в кластере. Это утилита, встроенная в vSphere Client, в которой доступен большой набор паттернов метрик и гистограмм для анализа таких вещей, как R/W ratio, Seq/Random ratio, 4K aligned / unaligned ratio, IO size distribution.

Все это позволяет не пользоваться сторонними утилитами для решения узких проблем, а понимать их природу прямо из vSphere Client:

14. Улучшения сервисов для Cloud native applications

• Платформа vSAN Data Persistence - это новый фреймворк для партнеров, который позволяет интегрировать информацию о приложениях для операционных задач через API.
• SAN Direct Configuration - это альтернативный способ для прямой интеграции сервисов с хранилищами vSAN.
• Улучшения интеграции с vSphere with Tanzu за счет расширений для томов гостевых кластеров TKG, а также получения информации о состоянии томов TKG supervisor и guest.

Доступность для загрузки VMware vSAN 7 Update 1 ожидается в самое ближайшее время, следите за нашими новостями.

Компания Veeam Software, широко известная своим главным в отрасли решением Veeam Backup and Replication для резервного копирования виртуальных и физических сред, а также своими бесплатными утилитами, выпустила бесплатное руководство "Veeam Unofficial VMware VCP-DCV 2020 Study Guide", которое позволит вам подготовиться к главному экзамену на сертифицированного специалиста VMware Certified Professional Datacenter Virtualization (VCP-DCV 2020).

Напомним, что VMware недавно выпустила данную сертификацию для 2020 года и обновила основной экзамен Professional VMware vSphere 7.x Exam (2V0-21.20), который позволяет ее получить.

Руководство от Veeam на 133 (!) страницах позволит вам качественно подготовиться к сдаче этого экзамена и с помощью практических заданий отточить все основные операции по администрированию виртуальной инфраструктуры VMware vSphere 7.

Основные разделы документа:

• VMware vSphere architectures & technologies
• VMware product and solutions
• Installing, configuring and setting up a VMware vSphere solution
• Performance-tuning and optimizing a VMware vSphere solution
• Administrative and operational tasks in a VMware vSphere solution

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

Скачать Veeam Unofficial VMware VCP-DCV 2020 Study Guide можно по этой ссылке.

На сайте проекта VMware Labs обновилась утилита Horizon Session Recording до версии 2.1.50. Напомним, что о прошлой ее версии (2.08) мы писали вот тут.

Данная утилита предназначена для записи пользовательских сессий и активности в виртуальных десктопах и приложениях, доставляемых по протоколу Blast Extreme (PCoIP пока не поддерживается). С помощью Session Recording администратор Horizon имеет возможность перенаправить запись экрана сессий пользователей, сделанных в определенное время, на центральный сервер, где потом он может воспроизвести их в HTML5-консоли. Саму сессию в виде видеофайла можно скачать как MP4 для воспроизведения в локальном плеере.

Посмотрим, что нового в Horizon Session Recording 2.1.50:

• Добавлена поддержка новой версии VMware Horizon 8 (он же 2006)
• Исправлены проблемы с дэдлоками при записи видео со стороны агента
• Множество исправлений ошибок на стороне агента (еще в версии 2.1)

Авторы утилиты обещают скорую поддержку LDAP и интеграцию продукта в состав решения VMware Horizon.

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

Некоторое время назад мы писали о сервисах технической поддержки VMware Skyline (и тут). Напомним, что это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов VMware vSphere.

На днях VMware аноснировала новую полезную утилиту Skyline Health Diagnostic Tool, с помощью которой пользователи смогут взаимодействовать с технической поддержкой вендора (GSS) и совмесно работать над возникающими проблемами в техническом ключе.

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

Проще говоря, Skyline Health Diagnostics for vSphere - это утилита самообслуживания, которая позволяет идентифицировать проблемы с помощью лог-бандлов и получить ссылки на помогающие статьи VMware KB. Самое интересное, что утилита Health Diagnostics for vSphere доступна абсолютно бесплатно (за сам сервис Skyline, конечно же, надо платить).

Те из вас, кто использовал Skyline, знают, что есть такое средство Skyline Advisor, которое выполняет схожие (на первый взгляд) функции. Так зачем же нужен Skyline Health Diagnostic Tool?

Во-первых, Skyline Advisor - это облачный веб-сервис, а SHD - полноценный онпремизный тул для заказчиков. Ну а, во-вторых, Skyline Advisor - это тул для проактивной аналитики, а Health Diagnostic Tool сфокусирован на текущем анализе логов и решении проблем.

Управление утилитой Skyline Health Diagnostics происходит через веб-интерфейс виртуального модуля.

SHD выполняет следующие функции:

• На базе симптомов какой-либо проблемы представляет ссылку на Knowledge Base (где рассказано о ее исправлении), либо сразу выводит конкретные шаги по устранению трудностей.
• Механика самообслуживания ускоряет процесс самостоятельного нахождения причины проблем.
• Быстрое приведение инфраструктуры в соответствие с помощью конкретных рекомендаций позволяет оперативно устранить неполадку без нарушения процессов бизнеса.

Установка продукта разбита на 3 простых шага:

Более подробно об установке Health Diagnostic Tool рассказано вот тут, а сам процесс разобран в видео ниже:

Апгрейд виртуального модуля происходит в рамках простого рабочего процесса: надо просто зайти в Settings-> Upgrade & History.

С помощью SHD логи можно анализировать в двух режимах:

• Online - можно соединиться с сервером vCenter Server или ESXi и собрать логи. В рамках одной задачи анализа можно обрабатывать до 32 хостов.
• Offline - можно руками загрузить логи в формате .TGZ или zip-файла (когда отчеты сгенерируются, они будут доступны для скачивания.

Загрузить VMware Skyline Health Diagnostic Tool можно по этой ссылке. Документация доступна тут.

Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.

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

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

Итак, после того, как вы скачаете драйвер, его установка делается одной командой:

# esxcli software vib install -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

На VMware ESXi 7 можно использовать фичу "component":

# esxcli software component apply -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:

# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard"   # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles

$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip"        # Uncomment for ESXi 7.0

#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip"  # Uncomment for ESXi 6.7

#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip"  # Uncomment for ESXi 6.5
Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Export-ESXImageProfile -ImageProfile $baseProfile -ExportToBundle -filepath "$($baseProfile).zip"

Remove-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Invoke-WebRequest -Method "GET" https://download3.vmware.com/software/vmw-tools/USBNND/$($usbFling) -OutFile $($usbFling)

Add-EsxSoftwareDepot "$($baseProfile).zip"

Add-EsxSoftwareDepot $usbFling

$newProfile = New-EsxImageProfile -CloneProfile $baseProfile -name $($baseProfile.Replace("standard", "usbnic")) -Vendor "virten.net"

Add-EsxSoftwarePackage -ImageProfile $newProfile -SoftwarePackage "vmkusb-nic-fling"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToIso -filepath "$($baseProfile.Replace("standard", "usbnic")).iso"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToBundle -filepath "$($baseProfile.Replace("standard", "usbnic")).zip"
 

При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.

Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:

Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:

# esxcli network nic list |grep vusb |awk '{print $1, $8}'

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:

# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling

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

Далее нужно проверить маппинги с помощью команды:

# esxcli system module parameters list -m vmkusb_nic_fling
Name                        Type    Value              Description
--------------------------  ------  -----------------  -----------
usbCdromPassthroughEnabled  int                        Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac                   string  00:23:54:8c:43:45  persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                   string  a0:ce:c8:cd:3d:5d  persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                   string                     persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                   string                     persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                   string                     persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                   string                     persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                   string                     persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                   string                     persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx

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

# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling

Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:

PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac 

Name  Mac

----  ---

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Настраиваем маппинги MAC-адресов:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling | Set-VMHostModule -Options "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d"
 

Проверяем результат:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling |ft -AutoSize

  Name             Options

  ----             -------

vmkusb_nic_fling vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d

Тестируем производительность адаптеров

В тесте используются три типа адаптеров на хосте ESXi:

• Intel NUC embedded NIC (подключен к физическому коммутатору)
• 1 Gbit StarTech USB NIC (подключен к физическому коммутатору)
• 2.5 Gbit CableCreation (кросс-соединение между хостами)

Измеряем задержки (latency) с помощью пинга (50 штук):

# ping [Address] -c 50

Результат:

Далее тестируем пропускную способность (bandwidth) с помощью iperf3. Для этого нужно сделать копию бинарника утилиты:

# cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

Запускаем сервер на первом ESXi:

# /usr/lib/vmware/vsan/bin/iperf3.copy -s

Далее запускаем клиент на втором ESXi. Тест идет 5 минут (300 секунд) с сэмплами каждые 10 секунд:

# /usr/lib/vmware/vsan/bin/iperf3.copy -i 10 -t 300 -c [SERVER-IP]

Результат:

Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:

Очевидно, кросс-соединение на адаптерах 2.5G рулит.

Проверка совместимости

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

Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.

Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:

• MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
• MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
• Netgear MS510TX ($260 USD) - 10 портов
• TRENDnet TEG-30102WS ($450 USD) - 10 портов

Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:

Проверяйте параметр MTU size, когда включаете Jumbo Frames

Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.

Посмотреть размер MTU можно следующей командой:

[root@esx4:~] esxcfg-nics -l
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:00:1f.6 ne1000      Up   1000Mbps   Full   00:1f:c6:9c:47:13 1500   Intel Corporation Ethernet Connection (2) I219-LM
vusb0   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:18 1600   ASIX Elec. Corp. AX88179
vusb1   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:19 1500   ASIX Elec. Corp. AX88179

В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:

2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0

Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)

Источник статьи.

Иногда в кластере хранилищ VMware vSAN случается такая ситуация, что один из хостов ESXi оказывается "пустым", то есть не содержит компонентов виртуальных машин. При этом хранилища остальных хостов в кластере могут быть загружены почти полностью.

В этом случае надо посмотреть на интерфейс vSphere Client в разделе vSAN health check - там может быть такое сообщение для проблемного хоста:

vSAN node decommission state

Означает это, что хост находится в режиме обслуживания с точки зрения vSAN (Node Decommission State). При этом, например, с точки зрения хостов ESXi кластера VMware vSphere / HA он может не быть в maintenance mode. Поэтому может сложиться впечатление, что хост просто не принимает дисковые объекты по каким-то причинам.

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

localcli vsan maintenancemode cancel

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

Это отменит и перевод в режим обслуживания vSAN, после чего хост сможет размещать дисковые объекты виртуальных машин (для этого надо запустить операцию Rebalance). Более подробно об этом в KB 51464.

На сайте проекта VMware Hans-on Labs (HOL) появились две новые лабораторные работы, посвященные новой версии продукта для создания отказоустойчивых хранилищ VMware vSAN 7.

• HOL-2108-01-HCI – What’s new in vSAN – Getting Started
• HOL-2108-91-HCI – vSAN Quick Start – Lightening Lab

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

Напомним, что в последнее время мы уже писали об обновлениях лабораторных работ:

• 18 новых лабораторных работ (Hands-On Labs) на тему vCloud Management Platform
• Новые лабораторные работы (Hands-on Labs) на VMware vSphere 7

Первая лабораторная работа "What's New in vSAN 7" охватывает следующие аспекты развертывания и эксплуатации продукта:

• Политики хранилищ и средства обеспечения доступности (vSAN SPBM and Availability)
• Файловые службы для работы с протоколами NFS и SMB - vSAN File Services
• Хранилища vSAN Cloud Native Storage (CNS) для контейнеров кластеров Kubernetes
• Мониторинг состояния, доступных емкостей и производительности
• Облуживание и управление жизненным циклом хранилищ и виртуальных машин
• Шифрование и безопаность платформы

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

В конце августа компания VMware объявила о скором выпуске решения vRealize Operations 8.2, предназначенного для управления и мониторинга виртуальной инфраструктуры. Напомним, что о прошлой версии vROPs 8.1 мы писали вот тут.

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

1. Функции Application-Aware Troubleshooting

В vROPs в последнее время быстро развиваются возможности для мониторинга инфраструктуры приложений в виртуальных машинах и контейнерах за счет пакетов Application Performance Management (APM) management packs. Это позволяет дополнить средства мониторинга компонентов инфраструктуры точными метриками, получаемыми от приложений.

Вот так выглядят средства обнаружения приложений и их параметров в решении vRealize Network Insight в виртуальном датацентре, которые далее передаются в vRealize Operations:

vRNI обнаруживает приложения и их взаимосвязи через анализ сетевых потоков, что отлично дополняет инфраструктурный метод обнаружения со стороны vROPs.

Еще одно важное улучшение в этой категории - опция "near real-time monitoring", что позволяет собирать данные в 15 раз чаще, что близко к режиму реального времени:

2. Улучшения поддержки Kubernetes

Главное улучшение vRealize Operations 8.2 - это возможности автоматического обнаружения гостевых кластеров Tanzu Kubernetes:

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

Ну и Management Pack for Container Monitoring теперь переименован в "Management Pack for Kubernetes".

3. Интеграции с внешними системами

Помимо более глубокой интеграции с vRNI, решение vROPs 8.2 поддерживает целую экосистему интеграции с внешними системами и облачными технологиями. Это лучше всего иллюстрируется картинкой (интеграции доступны через соответствующие Management Packs):

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

• Management Pack for AWS будет включать в себя аналитику емкостей EC2
• В VxRail появится 140 новых алертов
• Существенно обновятся пакеты для SNMP, NSX-T и Skyline
• Новый management pack для Flowgate (о нем мы писали вот тут)
• vRealize Operations management pack for Horizon будет доступен только для vRealize Operations Cloud

Ну и в vROPs появятся средства True Visibility Suite от купленной компании Blue Medora, теперь они будут называться vRealize True Visibility Suite. Более подробная информация об этом появится чуть позже.

4. Простота использования

Во-первых, был существенно упрощен рабочий процесс управления политиками, с которым теперь значительно удобнее работать в интерфейсе vROPs 8.2. Все операции доступны в контексте выбранных объектов:

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

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

5. Прочие улучшения

Тут можно отметить следующие наиболее важные вещи:

• Интеграция с vRealize Automation (Cloud и 8.2)
• Оценка потенциала оптимизации рабочих нагрузок (прогноз результата)
• Скачиваемые отчеты об оптимизации рабочих нагрузок (workload optimization reports)
• Поддержка назначения цен для всех нагрузок (а не только vRealize Automation) с кастомизируемыми ставками
• Оценка затрат на уровне отдельных дней
• Улучшения в движке оценки стоимости ресурсов
• Метрики AWS CloudWatch API для гостевых ОС
• Увеличен масштаб для оценки корреляции метрик
• Новые страницы информации для vSAN
• Упрощенные представления контента (с функциями импорта и экспорта), а также простые представления настроек
• Кастомные шаблоны комплаенса для vRealize Operations Cloud
• Поддержка Cloud Director Service для vRealize Operations Cloud
• Новый регион Sydney для vRealize Operations Cloud
• vRealize Operations Cloud доступен на VMware Cloud Provider Hub

О доступности для загрузки VMware vRealize Operations 8.2, скорее всего, будет объявлено на предстоящем VMworld Online 2020.

Несмотря на то, что компания VMware представила версию средства для создания отказоустойчивых хранилищ vSAN 6.5 еще в 2016 году, многие крупные компании продолжают ей пользоваться. Между тем, надо понимать, что скоро браузеры отключат поддержку Flash, и все консоли на базе этой технологии (а именно на ней работает старый vSphere Web Client) просто прекратят работать (в Chrome это запланировано на декабрь этого года).

Чтобы вы могли и дальше использовать vSAN 6.5, нужно накатить патч vSAN 6.6.1 Patch 05 (вышел еще 30 июля), в котором добавлена поддержка технологии HTML5, поддерживающейся всеми современными браузерами. О возможностях vSAN 6.6.1 мы писали вот тут.

В новом апдейте vSAN 6.6.1 на базе мажорной версии 6.5 есть следующие нововведения:

• Отчеты о производительности вы можете найти в Cluster > вкладка Monitor > секция vSAN > Performance
• Добавлена панель общей информации в разделе Virtual object, показывающая размещение и доступность объектов в кластере. Также можно фильтровать список по статусу и типу объектов.
• В разделе Virtual Objects/ View data placement есть чекбокс "Group components by host placement", который дает возможность увидеть состояние компонентов данных и быстрее обнаружить потенциальные проблемы на хостах ESXi.

Также из блога VMware мы утянули вот такое видео с обзором интерфейса HTML5 для vSAN 6.6.1:

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

Есть простой способ сделать это для VMware Horizon Agent. Нужно на Windows-машине с установленным агентом открыть ветку реестра:

HKEY_LOCAL_MACHINE\Software\VMware, Inc.\Installer\Features_HorizonAgent

Там будут перечислены установленные фичи (значение "Local"), а для не поставленных будет выставлено значение "Absent":

Такая же штука есть и для VMware Horizon Client на Windows-машине. Нужно открыть ветку реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMware VDM\Client\Installer\

И там для установленных фич будут стоять единички, а для неустановленных - нолики:

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

На днях состоялся релиз интересного продукта Project Antrea 0.9.1, который позволяет пользователям кластеров Kubernetes на платформе VMware управлять сетевым взаимодействием контейнеров на базе политик.

Ну а VMware Container Networking with Antrea - это новый коммерческий продукт на базе Project Antrea, представляющий собой решение для публичных и частных облаков, использующих Open vSwitch, которое позволяет управлять сетевым взаимодействием на нескольких уровнях с предоставлением поддержки со стороны VMware. Он реализует следующие функции в рамках среды Kubernetes:

1. Исполнение политик для Managed Kubernetes Services

Antrea добавляет официальную поддержку служб AWS EKS. Кроме того, Antrea улучшает поддержку сервисов Azure AKS с использованием CNI chaining и режимом трафика "networkPolicyOnly" с соблюдением политик при использовании нативного соединения.

Также решение Antrea имеет поддержку Google GKE и может быть использовано как primary CNI в Amazon и Azure для решения проблемы исчерпания IP-адресов в окружении с большим количеством небольших нагрузок в контейнерах.

2. Политики ClusterNetworkPolicy

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

3. Разделение политик на уровни

В Antrea есть глобальные политики (а в будущем будут нативные политики уровня неймспейсов), которые можно сгруппировать в ярус политик (policy tier). Сейчас есть 5 таких статических ярусов: Emergency, SecurityOps, NetworkOps, Platform и Application.

В будущих релизах пользователи смогут создавать кастомные ярусы и задавать порядок их подчинения. Ролевая модель Kubernetes RBAC обеспечивает контроль создания политик пользователями. Администраторы информационной безопасности могут делегировать права по созданию политик разработчикам, при этом глобальные политики остаются на контроле администраторов ИБ.

4. Улучшения мониторинга и диагностики

Antrea предоставляет набор диагностических и операционных метрик за счет средств мониторинга Prometheus и предоставляет нативные определения CustomResourceDefinitions (CRDs), чтобы наблюдать и диагностировать состояния компонентов инфраструктуры Antrea и потоков данных.

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

5. Интеграция NSX-T и VMware Container Networking

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

Более подробно о решении VMware Container Networking with Antrea рассказано на этой странице.

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

1. Новая версия OS Optimization Tool b1171

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

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

• Пункт Disable Passive Polling больше не выбран по умолчанию (некоторые приложения думали, что отсутствует интернет соединение).
• Новая настройка - использовать графический драйвер WDDM для подключений через Remote Desktop.
• Новая функция поиска по оптимизациям, чтобы найти отдельные объекты. Это доступно на вкладках Optimize и My Templates.
• Добавлен сплиттер для расширения зоны дерева слева в разделе My Templates.
• Новые контролы для управления поиском Cortana и поведением окошка поиска в таскбаре.
• Новая опция для указания аккаунта администратора, чтобы выполнять операции после отработавшего SysPrep (по умолчанию это текущий пользователь, который добавляется в группу Администраторы).
• Исправлено много ошибок.

Скачать VMware OS Optimization Tool b1171 можно по этой ссылке.

2. Обновление USB Network Native Driver for ESXi 1.6

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

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

• Добавлена поддержка устройств Aquantia и Trendnet AQC111U (0xe05a:0x20f4).
• Добавлена поддержка Realtek RTL8153 (0x045e:0x07c6).
• Поддержка Realtek RTL8156 (0x0bda:0x8156).
• Поддержка постоянных маппингов MAC-адресов VMkernel на USB NIC.
• Упрощенное сохранения состояния USB NIC.
• Решена проблема со скоростью соединения для чипсетов RTL8153.
• Это последний релиз, поддерживающий ESXi 6.5.

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

3. Новая версия App Volumes Migration Utility 1.0.4

Эта штука позволяет смигрировать старые объекты AppStacks, в которых распространялись приложения в VMware App Volumes 2.18, на новый формат VMware App Volumes 4.0, который реализует концепцию приложений и пакетов. Подробно мы писали об этой утилите вот тут.

Обновление 1.0.4 небольшое - тут появилась только пара исправлений ошибок. Скачать апдейт можно по этой ссылке.

Вчера мы писали про анонс новой версии настольной платформы виртуализации VMware Workstation 16, а одновременно с этим было объявлено и о выходе настольного продукта для Mac OS - VMware Fusion 12. Напомним, что этот продукт был в статусе технологического превью Fusion Tech Preview 20H1 с начала этого года.

Первое, что надо отметить - это изменения цен. Вместо $159 за Pro-версию теперь придется отдать $199:

Версии Fusion Standard за $79 больше нет, вместо нее пришел на смену продукт Fusion Player (с теми же функциями), который стоит $149:

Но самый большой плюс заключается в том, что VMware Fusion Player 12 полностью бесплатен для личного использования (не на работе). Смысл этого издания в том, что оно аналогично Workstation Player на платформах Windows и Linux.

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

VMware сделала множество оптимизаций для новой версии macOS Big Sur - как для гостевой, так и для хостовой ОС. Архитектура Fusion также подверглась изменениям, чтобы соответствовать новой структуре Apple hypervisor API. Теперь нет необходимости в kernel extensions, чтобы запускать Fusion, что делает платформу более безопасной.

Также Fusion 12 будет полностью поддерживать macOS Catalina при доступности для загрузки, а также сразу будет совместима и с Big Sur. Для Catalina все еще будут использоваться kernel extensions, а для Big Sur контейнеры и кластеры Kubernetes будут использовать уже Apple API.

2. Улучшения работы с контейнерами и движком Kubernetes

Теперь утилита vctl может выполнять команду vctl login для постоянного логина в реестр контейнера без необходимости писать полный ULR-путь при выполнении pull для образа. Также теперь можно развертывать локальные кластеры Kind на Kubernetes. В дополнение к поддержке kind, vctl создает docker-совместимый сокет для kind без модификации за счет собственной имплементации containerd.

3. Поддержка DirectX 11 и OpenGL 4.1

Workstation 16 поддерживает запуск игр и приложений с Direct3D версии 11 (он же DirectX 11) или OpenGL 4.1. Пользователи могут выделить до 8 ГБ vRAM для гостевой ОС (для этого сама виртуальная машина должна иметь 16 ГБ или больше оперативной памяти).

Fusion 12 Player и Fusion 12 Pro поддерживают устройства eGPU. За счет это требовательные к графике задачи можно перенести с интегрированного или дискретного GPU на внешнюю графическую карту.

5. Установка из Recovery Partition с использованием APFS

Теперь была добавлена поддержка APFS для установки macOS из раздела Recovery Partition, чтобы можно было быстро разворачивать гостевые ОС Mac.

Теперь поддерживаются соединения с ESXi 7 и vCenter 7 для управления виртуальными машинами, включая их перемещение между хостами и совместимость с инфраструктурой виртуальных ПК. Это доступно только в Pro-версиях.

7. Движок рендеринга графики в песочнице

Теперь есть новая функция Sandbox Renderer, которая позволяет отделить виртуальный графический движок, дав ему пониженные привилегии, что делает платформы Fusion и Workstation более безопасными.

8. Улучшенные специальные возможности

Теперь продукт соответствует стандарту VPAT Section 508 для лиц с ограниченными возможностями.

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

Пользователи, купившие VMware Fusion 11.5 или VMware Fusion 11.5 Pro после 15 июня, получат бесплатный ключ на Fusion 12. Доступность продукта ожидается уже в самое ближайшее время.

На днях компания VMware сделала анонс новых версий настольных платформ виртуализации Workstation 16 и Fusion 12. Напомним, что их обновления были анонсированы в продолжение технологических превью Workstation Tech Preview 20H1 (первая половина 2020 года) и Fusion Tech Preview 20H1. Сегодня мы поговорим о новых возможностях VMware Workstation 16.

С выходом новых версий поменялась и лицензионная политика. Теперь нет издания Standard, остались только Pro-версия и плеер. За $99 существующие пользователи могут переехать на новые версии Fusion Pro и Workstation Pro:

Стоимость новой лицензии для обоих продуктов стала $199 - это несколько дороже старых стандартных версий (особенно Fusion по $79), но вроде как это теперь Pro-версия для обеих платформ. Она стала дешевле для Workstation и дороже для Fusion.

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

1. Поддержка контейнеров и Kubernetes

Для разработчиков, использующих контейнеры, появилась новая утилита командной строки - vctl. Ранее уже доступная в Fusion, она позволяет пользователям выполнять операции push, pull, build и run для образов OCI, а также развертывать локальные кластеры Kind на Kubernetes.

В дополнение к поддержке kind, vctl создает docker-совместимый сокет для kind без модификации контейнера за счет собственной имплементации containerd.

Также данная функция будет доступна и с Workstation Player.

Workstation 16 поддерживает запуск игр и приложений с Direct3D версии 11 (он же DirectX 11) или OpenGL 4.1. Пользователи могут выделить до 8 ГБ vRAM для гостевой ОС (для этого сама виртуальная машина должна иметь 16 ГБ или больше оперативной памяти).

Теперь поддерживаются соединения с ESXi 7 и vCenter 7 для управления виртуальными машинами, включая их перемещение между хостами и совместимость с инфраструктурой виртуальных ПК. Это доступно только в Pro-версиях.

4. Темная версия интерфейса

Теперь в Workstation 16 есть темная тема Dark Mode UI, доступная как в Pro, так и в Player. Эта версия отлично дополняет темную тему Windows 10 билд 2004.

5. Движок рендеринга графики в песочнице

Теперь есть новая функция Sandbox Renderer, которая позволяет отделить виртуальный графический движок, дав ему пониженные привилегии, что делает платформы Fusion и Workstation более безопасными.

На Workstation 16 для Linux теперь появилась поддержка Vulkan API. Теперь рендер может использовать DirectX 10.1 и OpenGL 3.3 даже на базе интегрированной карты Intel GPU.

7. Улучшенные специальные возможности

Теперь продукт соответствует стандарту VPAT Section 508 для лиц с ограниченными возможностями.

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

Пользователи, купившие VMware Workstation 15.5 Pro или Workstation 15.5 после 15 августа, получат бесплатный ключ на Workstation 16. Доступность продукта ожидается уже в самое ближайшее время.