В 2014 году мы писали о продукте Horizon View Event Notifier, который предназначен для отправки администраторам писем по протоколу SMTP с различными алертами, произошедшими в VMware View.

Утилита соединяется с одной или несколькими базами данных Horizon View Event Database, вытаскивает оттуда выбранные администратором события (ошибки, предупреждения, инфо) и шлет письма на указанный email-адрес. При этом поддерживается возможность работы с несколькими БД, что позволяет собирать алерты с разных инсталляций VMware View (они же View Pods).

Спустя 7 лет, на сайте проекта VMware Labs неожиданно вышло обновление этой утилиты - появился Horizon Event Notifier 1.5. Что там нового:

• Изменено название с Horizon View Event Notifier на Horizon Event Notifier
• Изменена иконка и некоторые графические ресурсы
• Нотификации приходят в локальном формате времени, где запущена утилита
• Алерты теперь видны в интерфейсе
• Совместимо и протестировано с VMware Horizon 2103 (вышел в марте этого года)

Скачать VMware Horizon Event Notifier 1.5 можно по этой ссылке.

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

На днях VMware сделала небольшое обновление этого пакета - VMware Cloud Foundation 4.2.1, давайте посмотрим, что там нового:

• Обновления безопасности для Photon OS в SDDC Manager 4.2.1 (пакет PHSA-2021-3.0-185 обновлен до PHSA-2021-3.0-209 - подробнее тут).
• Критические обновления безопасности для VMware vCenter Server Appliance (мы писали об уязвимости тут).
• Обновление некоторых версий продуктов в составе пакета.

Новый Bill of Materials включает в себя следующие версии решений VMware:

Для пользователей пакета версии 3.10.2 также есть обновление - VCF 3.10.2.1, о нем прдробно рассказано вот тут. Вот его Bill of Materials:

Об обновлении подсистемы безопасности VMware vCenter Server Appliance 6.7 Update 3n рассказано тут.

Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.

Итак, для начала выводим список доступных USB-интерфейсов на сервере:

esxcli hardware usb passthrough device list

У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):

Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:

esxcli hardware usb passthrough device disable -d 2:7:90c:1000

После этого будет вот такая картина:

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

Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1

Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:

vdq -q

Затем создаем переменную с именем устройства, например:

DEVICE_NAME="t10.JMicron_Generic_________0123456789ABCDEF"

Затем выполняем следующие команды для создания SATP-правила и перезагрузки устройства, которое подцепится как SSD-хранилище:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=${DEVICE_NAME} --option=enable_ssd

esxcli storage core claiming unclaim --type device --device=${DEVICE_NAME}

esxcli storage core claimrule load

esxcli storage core claimrule run

Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:

Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.

Создаем переменную с полным путем к устройству:

DEVICE_PATH="/vmfs/devices/disks/t10.JMicron_Generic_________0123456789ABCDEF"

Далее выполняем команду, которая разметит наш том как VMFS:

partedUtil mklabel ${DEVICE_PATH} msdos

END_SECTOR=$(eval expr $(partedUtil getptbl ${DEVICE_PATH} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1)

/sbin/partedUtil "setptbl" "${DEVICE_PATH}" "gpt" "1 2048 ${END_SECTOR} AA31E02A400F11DB9590000C2911D1B8 0"

/sbin/vmkfstools -C vmfs6 -b 1m -S $(hostname -s)-local-usb-ssd-datastore ${DEVICE_PATH}:1

Если все в порядке, вы увидите новый том в списке VMFS-томов в vSphere Client:

Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).

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

Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.

Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:

Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).

Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:

configstorecli config current get -g cluster -c ha -k fdm
{
   "mem_reservation_MB": 200,
   "memory_checker_time_in_secs": 0
}

Все это можно также экспортировать в json-файл командой:

configstorecli config current get -g cluster -c ha -k fdm > test.json

Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:

{
    "mem_reservation_MB": 200,
    "memory_checker_time_in_secs": 0,
    "node_goodness": 10000000
}

И импортируем его обратно в ConfigStore:

configstorecli config current set -g cluster -c ha -k fdm -infile test.json

В итоге хост ESXi 1507 был Primary:

А затем им стал узел 1505, для которого мы изменили данную расширенную настройку:

Ну и Дункан записал небольшое видео, раскрывающее весь процесс изменения данных настроек в VMware FDM / HA:

Компания VMware анонсировала новую возможность KB Insights, которая стала доступна в облачной версии решения для аналитики лог-файлов и мониторинга инфраструктуры VMware vRealize Log Insight Cloud.

С помощью KB Insights можно проанализировать проблемы облачной виртуальной инфраструктуры, которые выявляются вследствие анализа логов, и получить соответствующие ссылки на статьи VMware Knowledge Base и VMware Community, которые помогут в их решении.

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

Вот пример аналитики Log Insight Cloud, которая выявила проблемы по недоступности виртуальной машины в сети, случавшейся время от времени:

Оказалось, что эта проблема связана с дублированием IP-адреса в какой-то момент. Функция KB Insights предложила как ветку обсуждений этой проблемы на VMware Community, так и релевантную статью базы знаний "Duplicate IP address detected (1020647)".

Статья KB рассказывает о том, как изменить IP-адрес для найденного MAC-адреса устройства, а вот статья на комьюнити рассказывает о том, как найти второй сервис, где торчит тот же самый IP-адрес, чтобы решить, какой из адресов нужно поменять. Это решение, конечно же, дает администратору больше гибкости:

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

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

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

Источник.

Весной этого года мы писали о двух критических ошибках безопасности в сервисах VMware Carbon Black и VMware vCenter - тут и тут, соответственно. В свое время для них были выпущены патчи, закрывающие эти уязвимости. Но, надо сказать, что это далеко не единственные критические моменты в инфраструктуре безопасности vCenter - на днях VMware опубликовала патчи к VMSA-2021-0010 (сообщения CVE-2021-21985 и CVE-2021-21986).

Суть уязвимости заключается в том, что в плагине Virtual SAN Health Check есть дыра в процедуре валидации ввода данных, которая позволяет злоумышленнику получить доступ к удаленному исполнению кода через vSphere Client. CVSSv3 base score этой уязвимости максимальный - 9.8, поэтому нужно обновлять серверы vCenter прямо сейчас.

Если вы не используете VMware vSAN, у вас все равно эта дырка есть, так как плагин vSAN идет вместе с установкой vCenter по умолчанию. Затронуты, кстати, vCenter версий 6.5, 6.7 и 7.0 и их обновления, то есть все самые актуальные на текущий момент. Компания VMware создала по данной уязвимости специальный FAQ.

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

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

Итак, теперь, собственно, какие патчи вам надо накатить (полное описание находится здесь):

• Для VMware vCenter 7.0 накатываем vCenter 7.0 Update 2b (вот тут)
• Для vCenrer 6.7 накатываем vCenter 6.7 Update 3n (вот тут)
• Для vCenrer 6.5 накатываем vCenter 6.5 Update 3p (вот тут)

VMware настойчиво рекомендует сделать обновление прямо сейчас, чтобы злоумышленники и всякое ransomware не добавили вам проблем, например, перед летним отпуском:)

На сайте проекта VMware Labs появилась запись о том, что утилита App Volumes Packaging Utility 1.3 теперь официально включена в состав VMware App Volumes 4, version 2103. Такое иногда происходит с утилитами проекта Labs, некоторые из которых становятся либо самостоятельными продуктами, либо включаются в состав уже существующих решений.

Напомним, что Packaging Utility позволяет упаковывать приложения для использования с App Volumes. С помощью нее можно добавить необходимые метаданные в приложение MSIX на базе дисков VHD таким образом, чтобы их можно было использовать вместе с пакетами формата AV. Получившиеся VHD формата MSIX будут требовать App Volumes 4 версии 2006 или более поздней, а также Windows 10 версии 2004 или более поздней.

Соответственно сам продукт App Volumes был обновлен, давайте посмотрим на его новые возможности:

• Теперь при установке App Volumes Manager можно выбрать пункт "App Volumes Tools" при установке на машину с Windows 10, который и устанавливает Packaging Utility. Далее с помощью команды appcapture.exe можно упаковывать приложения без необходимости использования консоли App Volumes Manager. С помощью appcapture можно автоматизировать процессы упаковки приложений для установщиков в silent-режиме, которые можно получать как в VMDK, так и в VDH форматах (причем одновременно). С помощью appcapture можно конвертировать пакеты между форматами VHD and VMDK, а также работать с пакетами формата MSIX.
• Теперь есть возможность использовать глобальную настройку, позволяющую использовать пакет на любой ОС Windows 10. В Advanced Settings можно поставить галочку, которая отключает проверку, что та же самая версия ОС использовалась для создания пакета и его доставки в рабочее окружение пользователя.
• Интервал Import Storage Groups по умолчанию был увеличен с 15 минут до 4 часов, чтобы позволить задаче закончить обработку большого числа пакетов на медленных хранилищах. Этот параметр можно изменить в настройках.
• На странице Managed Storage Locations хранилище может быть помечено как read-only. В этом случае App Volumes Manager пропускает это хранилище, когда обновляет пакет или AppStack. Так как App Volumes регулярно записывает дополнительные метаданные в пакеты, чтобы отслеживать их обновления, эта опция оказывается очень полезной для некоторых хранилищ.
• Также была обновлена подсистема безопасности и исправлены ошибки.

Загрузить VMware App Volumes 4, version 2103 со встроенной утилитой App Volumes Packaging Utility 1.3 можно по этой ссылке.

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a.

Многие пользователи жалуются, что консоль виртуальных машин, развернутых через VM Service в кластере vSphere with Tanzu, оказывается недоступна для логина, даже для администраторов. Над этой проблемой работают, но пока в интерфейсе это выглядит так:

Между тем, попасть в консоль иногда нужно (например, для отладки или траблшутинга) - и для этого есть воркэраунд.

Итак, заходим по SSH на VMware vCenter Server Appliance (vCSA) и выполняем следующие команды, которые получают root-пароль от Supervisor Cluster, выводят его в консоли и инициируют сессию к одному из узлов супервизор-кластера:

SV_DECRYPT_OUTPUT=$(/usr/lib/vmware-wcp/decryptK8Pwd.py)

SV_CLUSTER_IP=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'IP: ' '{print $2}' | awk '{print $1}')

SV_CLUSTER_ROOT_PASSWORD=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'PWD: ' '{print $2}' | awk '{print $1}')

echo -e "\n${SV_CLUSTER_ROOT_PASSWORD}\n"

ssh root@${SV_CLUSTER_IP}

Далее, после того, как мы залогинились в Supervisor Cluster, нужно получить креды от нужного нам узла. Делается это следующим набором команд:

VM_SERVICE_ACCOUNT_USERNAME=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.password}' | base64 -d)
VM_SERVICE_ACCOUNT_PASSWORD=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.username}' |base64 -d)
echo -e "\n${VM_SERVICE_ACCOUNT_PASSWORD}\n${VM_SERVICE_ACCOUNT_USERNAME}\n"

После этого заходим в vSphere Client под этими кредами и функция запуска консоли для данной ВМ вам будет доступна:

Источник.

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

С момента того, как мы впервые писали об этом пакете драйверов, вышли их версии 1.1 и 1.2 - давайте посмотрим, что в них появилось нового:

• Поддержка больших пакетов Jumbo Frames (размер MTU до 9000)
• Поддержка механизма Wake-on-LAN (WOL) для устройств Intel i225 NIC
• Исправлена проблема для карточек Intel vPro, которая могла приводить к "розовому экрану смерти" (PSOD) на ESXi

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

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

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

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

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

На сайте проекта VMware Labs появилась еще одна утилита в сфере Machine Learning, которая может оказаться полезной некоторым Enterprise-администраторам, работающим с высокопроизводительными системами. Средство Resource-Efficient Supervised Anomaly Detection Classifier представляет собой ресурсно-эффективный классификатор для обнаружения аномалий запросов, который дополняет алгоритмы Random-Forest и XGBoost. По сравнению с упомянутыми средствами, VMware заявляет меньший объем используемой памяти и более эффективное использование CPU.

Цель данной утилиты - быстро натренировать небольшую модель таким образом, чтобы она корректно классифицировала большинство запросов. Далее, используя полученную универсальную модель, можно создавать более сложные экспертные ML-модели, натренированные на исключительные случаи.

Для работы алгоритма на Python вам потребуется наличие следующих компонентов:

• CMake 3.13 или выше
• numpy
• pandas
• sklearn
• xgboost

Скачать Resource-Efficient Supervised Anomaly Detection Classifier можно по этой ссылке.

Когда вышло обновление VMware vSphere 7 Update 2, мы рассказывали о новых оптимизациях для процессоров AMD EPYC, которые были сделаны в платформе виртуализации на базе гипервизора ESXi. Реализация поддержки новых функций CPU идет в соответствии с развитием технологий аппаратной виртуализации AMD, которую VMware поддерживает наравне с таковой от Intel.

Недавно VMware выпустила отдельный документ "Performance Optimizations in VMware vSphere 7.0 U2 CPU Scheduler for AMD EPYC Processors", где рассказано, какие были сделаны оптимизации, и как именно они влияют на увеличение производительности:

В документе есть много интересных тестов (большинство из них сделано с помощью утилиты VMmark3), приведем ниже результаты некоторых из них:

• Увеличение производительности одной ВМ для БД Microsoft SQL Server под нагрузкой HammerDB (тут и далее нормировано к показателям vSphere 7 Update 1):

• Несколько виртуальных машин с 8 vCPU на борту и нагрузкой HammerDB - производительность при увеличении числа виртуальных машин на хосте:

Использование базы данных CockroachDB на 6-узловом кластере, прирост производительности до 50%:

Тестирование кластера Kubernetes c узлами по 64 воркера с помощью бенчмарка Weathervane (на 16 инстансах приложений прирост производительности - более 40%):

В общем, документ очень интересный - посмотрите.

Оказывается у VMware есть утилита TENS, что расшифровывается как Traffic Emulator for Network Service. Это еще один эмулятор сетевой нагрузки от VMware, который, в отличие от аналогов, сфокусирован на паттернах нагрузки, а не только на генерации объема и интенсивности сетевого потока. В основном, подобные средства предназначены для того, чтобы выяснить максимальные параметры сетевой нагрузки, которые могут выдержать те или иные компоненты. Кроме того, при генерации нагрузки эти средства, как правило, работают с одним приложением, когда речь идет о задании паттернов.

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

Продукт состоит из двух компонентов:

• Traffic Engine Controller (TEC) - это мозг всей системы, который управляет распределенными воркерами (их может быть сколько угодно) и предоставляет доступ сторонним системам через API.
• Traffic Engines Datapath (TE-DP) - компоненты непосредственно эмулирующие трафик нагрузки в соответствии с реальными паттернами.

TENS может эмулировать несколько браузерных сессий, клиентов, соединений и запросов на уровнях L4 и L7. Это позволяет заполнить разрыв между тестовым окружением, предпроизводственной средой, которую надо хорошо оттестировать, и производственным окружением, где приложения должны выдерживать требования к нагрузке по TCP/HTTP/UDP. Также TENS выводит отчет о метриках и ошибках для компонентов тестируемой системы.

Основные возможности VMware Traffic Emulator for Network Service:

• Функции для валидации и отчетности серверов балансировки нагрузки и серверов приложений.
• Генерация трафика от нескольких пользователей, нескольких сессий одного пользователя и нескольких соединений/запросов в рамках одной сессии - все это для нескольких вычислительных узлов.
• Комплексные метрики, выявление аномалий и мониторинг в реальном времени с одного узла с возможностью сообщения об ошибках как на уровне L4 (TCP/UDP), так и на L7 (HTTP/HTTPS).
• Возможность генерации L7-траффика с разных исходных IP и пространств имен, с внедренными куками, хэдерами и параметрами запросов в измерениях RPS, TPS, TPUT и CPS.
• Возможность запуска в нескольких процессинговых узлах, которые контролируются единой точкой доступа через API.
• Поддержка трафика http/1, http/1.1 и http/2 на уровне L7.
• Поддержка SSL версий SSLv2, SSLv3, TLSv1, TLSv1.0, TLSv1.1, TLSv1.2 и TLSv1.3 на уровне L7.
• Поддержка взаимной аутентификации сервер-клиент за счет проверки сертификатов на уровне L7.
• Возможность эмуляции аплоадов и загрузок больших UDP-датаграмм с несколькими одновременными подключениями на уровне L4.
• Утилита TENS упакована для использования в контейнеризованных системах - как в облачных, так и онпремизных.
• Возможность управлять утилитой через REST API для автоматизации операций и интеграции в общую инфраструктуру рабочих процессов тестирования.
• Поддержка SSL session reuse и persistence validation, что позволяет более безопасно организовывать процесс тестирования.

Скачать VMware TENS можно по этой ссылке.

Недавно на сайте проекта VMware Labs обновилась утилита App Volumes Entitlement Sync до версии 4.4. Напомним, что она позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать. В прошлый раз мы писали об этом средстве вот тут.

Давайте посмотрим, что нового в Entitlement Sync 4.4 и других версиях, вышедших после 4.1:

• Возможность обработки очень больших JSON-файлов (когда у вас много приложений и пакетов, он получается большой).
• Полностью переработанный механизм сравнения приложений и пакетов с возможностью исправления связей на реплицируемых сайтах
• Предыдущий пункт работает хорошо для формата репликации App Volumes 4.3+, но в целом подходит для любой версии 4.x.
• Поддержка сравнения GUID на основной и резервной площадках в целях индентификации GUID приложений.
• Полностью обновленный механизм логирования - данные записываются в %temp%. Теперь их много, что позволяет лучше проводить траблшутинг процесса.
• Нереплицируемые приложения больше не помечаются как ошибки в консоли.
• Улучшенный механизм постпроцессинга репликации.

Загрузить последнюю версию App Volumes Entitlement Sync можно по этой ссылке.

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

Давайте посмотрим, что появилось в VMware Cloud DR:

1. Cloud-to-Cloud DR - поддержка VMware Cloud on AWS SDDC в качестве исходного сайта

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

2. Двухузловая конфигурация Pilot Light

Pilot Light - это схема, которую пользователи большой инфраструктуры VMware используют для уменьшения RTO (Recovery Time Objective) в случае сбоев. Для этого развертывается небольшое горячее окружение, которое всегда готово принять на себя нагрузку производственной среды. Теперь минимальный размер этого окружения сократился с 3 до 2 хостов, что дает меньшую цену входа в эту схему.

3. Управление несколькими инстансами из одной консоли

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

4. Новые географии

Теперь для решения Cloud DR доступны Сан-Паулу, Сеул и Стокгольм. Общая карта регионов теперь выглядит так (всего их 16):

5. Комплаенс HIPAA BAA

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

Более подробно о решении VMware Cloud Disaster Recovery можно узнать на этой странице.

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

Дункан Эппинг рассказал о том, что происходит, если в нем всего три хоста. Например, если у вас есть 2 площадки, по три хоста ESXi на каждой, но в случае сконфигурированной политикии SFTT=1 (это Stretched FTT) у вас получается RAID-1 для дисковых объектов виртуальной машины на каждой из площадок:

При этом два хоста хранят в себе Data Component виртуальной машины, а третий хост работает для нее как Witness на случай изоляции одного из хостов кластера. Теперь возникает вопрос - а что произойдет с механизмом Enhanced Durability, если один из хостов перевести в Maintenance Mode? Где будет создаваться Durability Component (он хранит все поступающие операции записи Write IO), который защищает машину от сбоя на уровне площадки при переведенном в режим обслуживания хосте?

Ответ тут прост - этот компонент будет создаваться на других хостах, даже если он выполняет функции Witness (но, конечно же, он будет создан на хосте этой площадки):

Ну и небольшое демо процесса тестирования механизма Enhanced Durability в этих условиях от Дункана:

На сайте проекта VMware Labs обновилась интересная и полезная многим Enterprise-админстраторам утилита Forklift for Workspace ONE UEM (она же Workspace ONE UEM Workload Migration Tool) - ее третья версия вышла в начале мая. О первой версии этого средства мы писали еще два года назад вот тут.

Forklift for Workspace ONE UEM позволяет провести бесшовную миграцию конфигураций приложений и устройств между различными окружениями Workspace One UEM (например, тестовой средой и производственной). Ее возможности включают в себя:

• Миграцию приложений, профилей, сенсоров (Sensors), скриптов объектов Windows 10 Baselines Continuous Delivery pipelines как часть решения для создания/обновления и апгрейда ресурсов из сред разработчиков в производственные среды.
• Шаблоны экспортируемых/импортируемых ресурсов в виде контейнеров для быстрого их развертывания в среде UEM.

Forklift for Workspace ONE UEM представляет собой набор из двух связанных контейнеров, вспомогательные скрипты для их запуска, а также Docker Compose file, чтобы обеспечивать связь этих контейнеров.

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

• Поддержка более чем одного окружения (исходного и целевого)
• Поддержка MST и иконок для миграции приложений Windows 10
• Поддержка приложений размером более 2 ГБ
• Поддержка сенсоров и сценариев при миграции
• Поддержка объектов Continuous Delivery Pipelines

Скачать VMware Forklift for Workspace ONE UEM можно по этой ссылке.

Еще в 2019 году компания VMware анонсировала утилиту VMware Usage Meter 3.6.1 для vCloud Availability 3.x, которая позволяла автоматически измерять потребление облачных ресурсов и создавать отчеты на помесячной основе. Предназначено это для облачных провайдеров, предоставляющих услуги аренды виртуальных машин по модели IaaS. На днях была анонсирована новая версия Usage Meter 4.4, которая расширяет функциональность версии 3.6.1.

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

1. Ежемесячные отчеты

Новая возможность Usage Meter позволяет привязать метку (label) к каждому клиенту и на базе нее отслеживать потребление ресурсов, формируя ежемесячные отчеты. Это делается за счет применения механизма правил к объектам vCenter или VMware Cloud Director.

2. Поддержка LDAP

Теперь облачные администраторы могут залогиниться в виртуальный модуль Usage Meter с использованием аутентификации LDAP. Более подробно об этом можно почитать вот тут.

3. Офлайн отчеты

Ранее отчеты UM были доступны только после утверждения со стороны поддержки VMware, теперь же они доступны всем. Настроить их можно при развертывании виртуального модуля vCenter Server в формате OVA, где можно настроить обход валидации Usage Insight registration.

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

4. Улучшения механизма апгрейда

В прошлом апгрейд Usage Meter 4.X использовал файл SHAR, который загружался в Usage Meter, после чего выполнялся скрипт апгрейда. Теперь в версии 4.4 для этого используется ISO-образ, который можно привязать к любому виртуальному модулю Usage Meter 4.1+ и выполнить сценарий из ISO-образа как Root.

Ну и напоследок небольшое обзорное видео о развертывании Usage Meter:

Для использования возможностей Usage Meter вам нужно переключиться на Flex Pricing Model, что является обязательным требованием:

Скачать VMware Usage Meter 4.4 можно по этой ссылке.

На сайте проекта VMware Labs появилась новая версия утилиты Virtual Machine Compute Optimizer 3.0, о которой в последний раз мы писали летом 2019 года. С тех пор вышло несколько обновлений этого средства. Напомним, что VMCO - это PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

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

Также в последних версиях была добавлена опция -simple, которая позволяет отобразить только информацию о виртуальных машинах (без серверов vCenter, кластеров и хостов ESXi), обновлена документация и исправлено много ошибок.

Скачивайте Virtual Machine Compute Optimizer 3.0 и выясняйте, правильно ли у вас настроены vCPU и Memory для виртуальных машин. Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри.

Большинство маководов знают, что с 2020 года компания Apple делает ноутбуки MacBook с процессорами M1 на базе архитектуры ARM в рамках серии Apple Silicon. Те, кто нас читают регулярно, знают, что компания VMware уже некоторое время делает эксперименты по виртуализации на базе архитектуры ARM и даже имеет свой серверный продукт ESXi ARM Edition. Многие у нас в комментариях спрашивали - а зачем, собственно, это продукт нужен? Один из ответов - это разрабатываемая сейчас платформа VMware Fusion для Apple MacBook с процессорами M1.

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

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

Как описано вот в этой статье, на данный момент по VMware Fusion для ARM ситуация следующая:

• Tech Preview платформы VMware Fusion для macOS на базе Apple Silicon будет готово уже в этом году.
• VMware не планирует поддерживать виртуальные машины на базе x86 в этой версии Fusion.
• С Windows 10 ARM, которая сейчас находится в статусе Insider Preview, есть лицензионные сложности.
• Поэтому в приоритете поддержка Linux-систем, на которые брошены основные силы разработки.
• Виртуальные машины macOS тоже пока не планируются, так как требуется совместная работа команд VMware и Apple над поддержкой этой технологии, а с этим также есть трудности.

Прежде всего, надо сказать, что внутренняя версия у разработчиков для гостевых ОС Linux уже работает. В статье по ссылке выше рассказано о том, как на ноутбуке (M1 MacBook Air 8 CPU + 8GPU, 16GB RAM) без проблем работают 7 виртуальных машин, а один из разработчиков говорит, что такой производительности он не видел за свои 12 лет работы в VMware.

Если с Linux все более-менее понятно, то с Windows ситуация неясна. Пока лицензия на Windows 10 Insider Preview для ARM содержит следующее:

To install Windows 10 Insider Preview Builds, you must be running a licensed version of Windows 10 on your device.

То есть на данный момент Microsoft не дала зеленый свет сторонним разработчикам решений для виртуализации, и есть несколько дискуссий на эту тему (раз+два). Также Microsoft пока только сообщает вот что:

With Windows 10 on ARM Insider Preview builds, you can create 64-bit ARM (ARM64) VMs in Hyper-V on Windows 10 ARM-based PCs. Creating ARM64 VMs is not supported on x64 hardware.

ARM64 VMs are only supported on devices that meet the pre-requisites:

• Windows 10 ARM-based PCs with a Microsoft SQ1, Microsoft SQ2, Qualcomm Snapdragon 8cx, or Qualcomm Snapdragon 850 processor
• Windows 10 Pro or Enterprise, build 19559 or newer
• Hyper-V enabled (instructions)

Тем не менее, VMware общается с Microsoft по этому вопросу, поэтому в итоге, скорее всего, какое-то продуктивное соглашение здесь, все-таки, будет.

Что касается отсутствия поддержки x86 виртуальных машин, то тут суть такая - их поддержка вызовет определенные технические сложности и, скорее всего, проблемы с падением производительности из-за эмуляции. Ну а сама Microsoft планирует сделать поддержку x86 приложений в своей ОС для ARM, поэтому лучше всего будет использовать механизм Microsoft, так как он более нативен, поскольку будет реализован на уровне слоя эмуляции приложений, а не всей виртуальной машины в целом.

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

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

На сайте проекта VMware Labs появилась еще одна полезная администраторам Enterprise-инфраструктур утилита NSX Mobile.

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

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

Вот какие возможности доступны в NSX Mobile:

• Просто устанавливаете приложение и вводите свои учетные данные NSX-T (поддерживается NSX 3.0+, также убедитесь, что IP-адрес доступен с вашего смартфона).
• Вывод списка сетей с возможностью поиска, а также отобржение сущностей, касающихся безопасности (Tier-0s, Network segments, Firewall Rules и прочее).
• Просмотр алармов, сгенерированных в NSX (например, высокое использование CPU, упавший VPN, обнаруженное вторжение, если у вас есть IDS-система).
• Быстрые действия - включить/выключить что-либо (если возможно), также некоторые другие действия для сбоев и алармов.
• Скоро сделают пуш-нотификации.

Вот небольшой обзор мобильного приложения:

Скачать NSX Mobile можно по этой ссылке.

Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.

Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):

Failed to load crypto64.efi

Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.

Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:

• Supervisor Cluster
  • Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
  • Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
• Tanzu Kubernetes Grid Service for vSphere
  • Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
  • Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
  • Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.

Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-7.0U2a-17867351-standard \

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

esxcli network firewall ruleset set -e false -r httpClient

Скачать VMware vSphere 7 Update 2a можно по этой ссылке. Release notes доступны тут.

Компания VMware какое-то время назад добавила возможность Managed Guest Sessions для операционной системы Chrome OS в своем решении Workspace ONE UEM Console (версия 2102 и выше). Эта опция позволяет гибко управлять общими устройствами на базе Chrome OS с точки зрения сессий пользователей.

Эта концепция была доступна и ранее, но для одного приложения в виде single-app kiosk profile, что позволяло путем применения политики залочить десктоп на одно приложение для публичного десктопа, которое могут использовать несколько пользователей.

С помощью нового механизма Managed Guest Sessions можно выделять отдельному пользователю сессию с необходимым доступом к приложениям и другим ресурсам. Теперь администратор может гранулярно настроить права доступа и политики для таких сессий, что значительно расширяет варианты использования решения Workspace ONE для публичных десктопов: например, библиотеки, тренировочные центры, торговые залы и многое другое.

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

В консоли Workspace ONE UEM можно настроить управление сессиями. Вот какие настройки можно делать:

• Managed Guest Session Name – отображение настраиваемого имени сессии на устройстве.
• Browser Settings – администратор может настроить домашнюю страницу, закладки, а также открывать вкладки при логине в систему.
• Security and Privacy - здесь можно включить Safe Browsing, а также создавать allow- и deny- списки для большего контроля над активностью пользователей. Также можно включить Incognito Mode для всех пользователей в целях обеспечения приватности.
• Application Control – здесь можно настроить приложения и экстеншены, которые будут доступны в рамках сессии на данном устройстве. Также можно использовать allowed и blocked списки приложений.
• Session Length – максимальное время, в течение которого пользователь может находиться в своей сессии, перед тем, как его принудительно разлогинит.

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

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

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

Более подробно о решении можно почитать вот тут.

В вышедшем на днях обновлении VMware vSphere 7 Update 2a (обновился только vCenter) компания VMware представила службу vSphere Virtual Machine Service (она же VM Service), которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин.

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

Служба VM Service дополняет ранее анонсированные службы Network Service и Storage Service, которые дают возможности по управлению через API сетью и хранилищем, соответственно, в среде vSphere with Tanzu. Вот хороший обзор новых функций VM Service:

Со стороны vSphere служба встроена напрямую в vCenter, она позволяет управлять образами ВМ (VM Images / Content Libraries) и классами ВМ (VM Classes / VM sizing).

Со стороны Kubernetes компонент называется VM Operator, он создает и обслуживает ресурсы Kubernetes Custom Resources (CRs/CRDs), а также общается с компонентом на стороне vSphere.

VM Service даст компаниям следующие преимущества:

• Разработчикам в среде Kubernetes больше не требуется создавать заявки на создание ВМ для администраторов.
• Администратор может преконфигурировать заданные классы ВМ, доступные разработчикам, задав лимиты их ресурсов, а также обеспечив защиту и изоляцию от продуктивного окружения.
• Некоторые приложения в контейнерах, например, могут использовать базу данных, размещенную в ВМ. В этом случае разработчик сможет создать спецификацию такого сервиса в YAML и обслуживать такую структуру самостоятельно.
• Open Source природа сервиса позволит дорабатывать и создавать новые службы с учетом потребностей больших команд. Репозиторий компонента VM Operator находится тут.

Более подробно о службе vSphere Virtual Machine Service рассказано в этой статье. Служба VM Service доступна в последнем релизе VMware vSphere 7 Update 2a.

На сайте проекта VMware Labs появилось обновление утилиты VMware Event Broker Appliance (VEBA) v0.6. Напомним, что это решение, которое позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That". О версии VEBA 0.5, вышедшей в декабре прошлого года, мы писали вот тут.

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

1. Функции Embedded Knative

Еще в прошлой версии VEBA поддерживал serverless-приложения Knative в качестве процессора событий, теперь же эта опция выбрана по умолчанию. Делать ничего не потребуется, нужно просто нажать Next.

2. Интеграция с пользовательским интерфейсом vSphere Client

Теперь в клиенте можно установить плагин VMware Event Broker, который доступен из инвентаря (только для варианта развертывания Knative):

В плагине есть 3 блока функций VEBA:

• Events – это первая точка настройки событий vCenter Server. Пользователям теперь не нужно ковыряться в репозитории vCenter Event Mappings repo, они могут видеть все события в окружении vCenter.
• Functions - здесь можно увидеть все развернутые функции и создавать переменные окружения.
• Secrets - здесь задаются пароли (secrets), используемые в функциях.

Для регистрации плагина VEBA понадобится доступ к vCenter Server:

3. Поддержка PowerShell для Knative

VEBA использует механизм CloudEvents для преобразования событий vCenter Server в рабочую нагрузку, которая может потребляться сценариями PowerShell. PowerShell SDK для CloudEvents опубликован в PowerShell Gallery, запустить его установку можно командой Install-Module CloudEvents.Sdk:

4. Репозиторий Knative Sample Functions

Для помощи новичкам был создан репозиторий по адресу: https://vmweventbroker.io/examples-knative. Пока есть сценарии реализации на PowerShell, но скоро будут добавлены примеры на Python и Go.

5. Просмотрщик vSphere CloudEvents Viewer

С помощью сервиса Sockeye по адресу https://[FQDN-VEBA]/events можно увидеть просмотрщик событий vCenter Server, которые можно фильтровать:

Фильтры можно группировать с помощью элемента + Add Filter:

Можно также скопировать сгенерированный JSON для события, чтобы самостоятельно симулировать его в окружении vCenter.

Более подробно о функциях новой версии VMware Event Broker Appliance 0.6 можно почитать в статье Вильяма Лама. Скачать последнюю версию виртуального модуля можно тут. Ну и небольшой видеообзор от коллег, имеющих непосредственное отношение к выпуску обновления:

На днях компания VMware анонсировала новую версию пакета для интеграции мониторинга vRealize Operations (vROPs) и инфраструктуры виртуальных ПК - vRealize Operations Management Pack for Horizon 1.1. Это решение предназначено для мониторинга виртуальных десктопов, обнаружения аномалий и оптимизации VDI-инфраструктуры. Напомним, что первая версия этого пакета вышла в октябре прошлого года.

Пользователи продукта vRealize Operations Advanced / Enterprise, vRealize Suite, а также облачной подписки vRealize Cloud Universal смогут включить пакет vRealize Operations Management Pack for Horizon через vRealize Operations Marketplace. Давайте посмотрим, что нового появилось в версии 1.1:

1. Обновленные дэшборды

Почти на всех дэшбордах были добавлены новые информационные блоки и оптимизированы старые. В представлении Horizon World Overview стало еще больше всего полезного, также теперь все более наглядно:

2. Поддержка Login Duration Metrics

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

3. Повявились дэшборды Pools & Farms

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

4. Метрики RDS Capacity и Disparity

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

5. Новые алерты

Следующие алерты были добавлены в версии 1.1 пакета:

• Notification Event Alert on GET API Failure on object Collection
• Notification Event Alert on Pod for collection failures
• Notification Event Alert on Help desk API Failure
• Notification Event Alert on relationship Failure
• Notification Event Alert on Version Issues
• Data collection failed on the Horizon Connection Server
• Horizon adapter collection time is going beyond default threshold limit
• Average Application Session Helpdesk API response time above threshold
• Average VDI session Helpdesk API response time above threshold
• Average RDS desktop Session Helpdesk API response time above threshold

Скачать vRealize Operations Management Pack for Horizon 1.1 можно из маркетплейса VMware по этой ссылке. Также попробовать этот пакет можно в рамках лабораторной работы на Hands-on Labs. Release notes доступны тут.

На днях компания VMware представила обновленную версию экзамена, который проходят специалисты облачных провайдеров, предоставляющих услуги на базе продуктов VMware - Cloud Provider Specialist 2021 Exam.

Экзамен является частью сертификации Cloud Provider Specialist 2021, которая доступна для специалистов VMware Certified Professional (VCP) и подтверждает владение продуктом VMware Cloud Director и в целом платформой Cloud Provider Platform. То есть формула проста:

VCP + Cloud Provider Specialist 2021 Exam = Cloud Provider Specialist 2021

Экзамен длится 60 минут и содержит 40 вопросов. В принципе, сам по себе экзамен несложный, если вы ежедневно пользуетесь Cloud Director (за основу в тесте взята версия VCD 10.2).

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

• VMware Cloud Director
• Варианты использования Cloud Foundation, Container Service Extension и других дополняющих VCD решений
• VMware Cloud Director Availability
• vRealize Operations Tenant App
• Интеграция NSX-T c Cloud Director

Зарегистрироваться на экзамен можно по этой ссылке.

На сайте проекта VMware Labs недавно обновился основной клиент для управления инфраструктурой vSphere - VMware vSphere Client, а через пару дней после этого обновился и мобильный клиент - вышел vSphere Mobile Client версии 2.2. Напомним, что последний раз об этом клиенте мы писали летом прошлого года вот тут.

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

• Добавлена поддержка VMware Cloud в части VMware Cloud on AWS, что позволяет получить доступ к облачным серверам через мобильное устройство
• Добавлен фильтр по серьезности проблем в разделах Alarm и Events
• Добавлена клавиша Windows в виртуальной клавиатуре и для сочетаний клавиш
• Улучшена стабильность консоли ВМ при повороте устройства
• Добавлена забытая кнопка Back в разделах страниц логина
• Обновлены иконки и сплэш-скрины
• Теперь на странице деталей ВМ есть навигация по связанным объектам
• Страница деталей виртуальной машины грузится быстрее, когда ВМ выключена

Скачать vSphere Mobile Client 2.2 можно по этим ссылкам:

• vSphere Mobile Client for Android devices
• vSphere Mobile Client for iOS devices

Также не забудьте посмотреть инструкцию о развертывании Notification Service, чтобы включить Push-уведомления на своих устройствах. Его можно развернуть в одном из двух вариантов:

• Как OVA виртуальный модуль
• Как контейнер Docker

Ну и немного устаревшее, но еще не полностью потерявшее актуальность видео о версии 1.13:

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

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

Финальный релиз Antrea первой версии добавляет возможности по улучшению управляемости сетевым окружением Kubernetes-native networking, а также улучшает функциональность политик за счет еще большей гранулярности, консистентности и контроля со стороны пользователя. Последний релиз включает в себя политики для исходящего трафика, политики безопасности на уровне кластера и расширенную поддержку экосистемы, в частности, решений Prometheus, ELK и Octant:

• Сервер Prometheus может предоставлять информацию в Antrea Controller и Agent.
• Плагин Octant может мониторить компоненты и выполнять трассировку пакетов в графическом интерфейсе.
• Стек ELK может предоставлять визуализацию карт потоков (flow maps) для сети кластера.

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

1. Политики безопасности на уровне кластера и ярусы политик (Policy Tiering)

Antrea позволяет назначать политики безопасности на уровне кластеров как ИТ-операторам и администраторам, так и разработчикам для контроля сетевого взаимодействия инфраструктуры контейнеров. Помимо Kubernetes Network Policies доступны также политики Antrea Cluster Network Policy (ACNP) и Antrea Network Policy (ANP) CRDs, которые включены по умолчанию. Политики ACNP определяются на уровне кластера, а ANP - на уровне неймспейсов, чтобы дополнить стандартные политики Kubernetes.

Политики можно группировать в ярусы (Tiers) с разным приоритетом, указывая разные эндпоинты для применения правил. Разные политики можно применять к разным группам кластеров, а логгирование трафика и статистики можно отслеживать на уровне политик. Также есть действие Reject для срабатывания политики и диагностика исполнения политики.

Ярусы политик Antrea могут быть представлены так:

2. Политики для исходящего трафика

Средствами Project Antrea вы можете контролировать трафик исходящих узлов (Egress Nodes) и SNAT IP для Pod Egress Traffic (от Pod ко внешней сети).

3. Функции мониторинга и диагностики

Antrea мониторит потоки в модуле Linux conntrack, который предоставляет множество данных на уровнях Pod-to-Pod, Pod-to-Service и Pod-to-External, где можно найти ассоциированные статистики, такие как data throughput, packet throughput и packet counts.

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

Flow Aggregator и Flow Exporter используют IPFix, позволяя потокам приходить в любое решение с поддержкой IPFix. Вот так выглядит визуализация потоков, собранных через Antrea:

Antrea поддерживает использование утилиты Traceflow для диагностики сети. Она формирует запросы на трассировку трафика через OVS-потоки, которые генерируются агентом Antrea. Также в реальном времени можно трассировать трафик между Pods. Также Antrea можно интегрировать с плагином Octant, чтобы увидеть результаты Traceflow на графе:

4. Интеграция со сторонними решениями

Antrea поддерживает работу воркер-узлов на базе Windows путем настройки оверлей-сети для пересылки пакетов между узлами. За счет использования режима transparent mode в Host Networking Service (HNS) контейнеры напрямую соединяются с физической сетью через внешний коммутатор Hyper-V. Также в Antrea 1.0 добавлена поддержка Traceflow для Windows.

Демо использования Traceflow для политик узлов Linux и Windows можно посмотреть ниже:

Также Antrea можно запускать в кластере AWS EKS, кластере Azure AKS и кластере Google GKE. Помимо этого, Docker-образы Antrea теперь доступны и для архитектур arm/v7 и arm64.

5. Режимы Overlay Encap и шифрование

Antrea поддерживает разные режимы Режимы Overlay Encapsulation: GRE, GENEVE, VXLAN и STT. Режим Encap Mode включен по умолчанию - трафик Pod'ов между узлами инкапсулируется и посылается через туннель выбранного типа. Если этого не требуется, то есть режим noEncap mode. Есть также и режим Hybrid mode, в котором трафик Pod не инкапсулируется, если узлы источника и назначения находятся в одной подсети.

Скачать Antrea 1.0 можно из этого репозитория на GitHub. Документация доступна тут. Ну и, если интересно, подключайтесь к комьюнити.

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

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

Вот небольшое видео о том, как зарегистрироваться на ресурсе Hands-on Labs, найти эти лабораторные работы и приступить к их выполнению:

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