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

На днях VMware заявила о выпуске обновлений продуктов линейки VMware vRealize 8.5, среди которых есть и обновление vRealize Log Insight Cloud 8.5. Давайте посмотрим, что там появилось нового:

• Поддержка нового региона - Сингапур. Теперь Log Insight Cloud доступен в регионе AWS Asia Pacific (Singapore). Помимо этого, решение уже работает в регионах US West, Asia Pacific (Sydney), Europe (Frankfurt) и Canada (central).
• Улучшенные фильтры Log Forwarding. Теперь они поддерживают новые опции, например, проверки на существование того или иного поля. Можно сделать комплексный фильтр - если поле существует, то уже смотреть его значение по условиям. Далее можно уже отправлять события во внешнее назначение.
• Пользователи теперь могут получать доступ к файлам VMware Cloud SDDC Grouping activity logs, которые появляются при создании/обновлении/удалении SDDC Group, добавлении/удалении нового члена группы SDDC, добавлении/удалении Direct Connect Gateway из группы, добавлении/удалении External AWS Account и обновлении external attachments.

Запросить пробную версию VMware vRealize Log Insight 8.5 можно по этой ссылке.

Также компания VMware обновила свое решение для комплексного управления и мониторинга виртуальной инфраструктуры в различных аспектах vRealize Operations Cloud и vRealize Operations 8.5. О прошлой версии vRealize Operations 8.4 мы писали весной этого года вот тут.

Это минорный релиз, который, в основном, добавляет исправления ошибок и обновления безопасности. Release notes по продуктам находятся тут.

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

• Поддержка нового региона - Сингапур. Теперь Log Insight Cloud доступен в регионе AWS Asia Pacific (Singapore). Помимо этого, решение уже работает в регионах US West, Asia Pacific (Sydney), Europe (Frankfurt) и Canada (central).
• Новый vRealize Operations Cloud Management Pack for Managed Service Providers (MSP). Он позволяет объединить разные инсталляции vRealize Operations Cloud у сервис-провайдеров в единую панель управления. В рамках каждой инсталляции на разных сайтах под управлением сервис-провайдера может находиться множество клиентов. Вот основные возможности, которые предоставляет данный MP:
  • Сводная статистика производительности, емкостей и конфигураций для всех окружений клиентов на разных площадках.
  • Возможность создать data warehouse с набором выбранных метрик, которые потом можно использовать для построения исторических отчетов.
  • Возможность создания сводного представления о текущем статусе работоспособности разных компонентов виртуальных датацентров, в том числе основных решений VMware - vCenter Server, NSX и vSAN. Также доступен мониторинг жизнедеятельности vRealize Operations, vRealize Log Insight, vRealize Automation, vRealize Business и VMware Site Recovery Manager.

Загрузить пробную версию VMware vRealize Operations 8.5 можно по этой ссылке.

Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...

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

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

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

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

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

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

На сайте проекта VMware Labs появилась еще одна одна мобильная версия клиента для управления большим продуктом VMware - Site Recovery Manager Mobile. Эта утилита предназначена для мониторинга состояния Protection-групп и планов восстановления в интерфейсе максимально приближенном к десктопному SRM.

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

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

• Мониторинг следующих сущностей:
  • Сводной информации о паре сайтов основной-резервный
  • Всех объектов protection groups / recovery plans
• Объекты отображаются в отдельном представлении в виде таблиц
• Объекты можно представить в виде меню drawer мобильного приложения для быстрого доступа к элементам дерева
• Информация о Protection groups разделена на 3 вкладки:
  • Summary
  • Recovery Plans
  • Virtual Machines
• Информация о планах восстановления разделена на 4 вкладки:
  • Summary
  • History
  • Protection Groups
  • Virtual Machines
• Администратор получает нотификацию, если какие-либо данные невозможно загрузить

Скачать VMware Site Recovery Manager Mobile можно по этой ссылке. Утилита пока работает только под Android версии 4.4 и выше.

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

Пару недель назад Cormac Hogan выпустил интересное видео для разработчиков и администраторов, в котором показывается, как можно создавать виртуальные машины на базе vSphere with Tanzu с помощью YAML-манифеста для пользовательских данных и ВМ:

Ну и, конечно же, рекомендуем отличную статью "A first look at vSphere VM Service" от автора видео.

Если у вас большая Enterprise-инсталляция VMware vSphere, и вам хочется оповещать пользователей о каких-либо важных статусах, изменениях или новостях, то вы можете использовать механизм Message of the Day (MotD) - сообщение, которое появляется в верхней части экрана vSphere Client. Например, пользователям можно сообщить, что они работают в Sandbox-окружении:

Вильям Лам рассказал о том, как правильно можно работать с этим с точки зрения автоматизации. В интерфейсе это сообщение можно настроить в разделе Configure->Settings->Message of Day:

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

Ну и главное - как это автоматизировать, если у вас несколько окружений vCenter?

Вот такой командой можно получить сообщение дня через PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.motd | select Value

К сожалению, с помощью Set-AdvancedSetting нельзя установить это сообщение, так как для обертки API это свойство находится в статусе Read Only. Поэтому нужно использовать API напрямую.

Вот так можно посмотреть текущий MotD:

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.Message

А вот так - обновить его:

$motd = "This is William Lam's environment, it is NOT supported. Use at your own risk"

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.UpdateServiceMessage($motd)

Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

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

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

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

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

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

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

На сайте проекта VMware Labs обновилась утилита HCIBench 2.6, которая до этого обновлялась осенью прошлого года. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.

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

Давайте взглянем на новые возможности HCIBench 2.6:

• Сервер tomcat обновлен до версии 8.5.68
• Поддержка IPv6 для сетей ВМ и Management Network - как для DHCPv6, так и для link-local mode
• Поддержка режима развертывания multi-writer disk
• Улучшенная пре-валидация за счет перехода на govc
• Поддержка спецификации read/write io_limit для fio
• Исправлена ошибка при запуске в инфраструктуре VMC
• Улучшена система сбора диагностических бандлов в режиме отладки vSAN

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

На сайте проекта VMware Labs появилась новая утилита - Edge Services Observability. Она предназначена для мониторинга служб Edge Services (VMware Tunnel, Content Gateway, Secure Email Gateway, Reverse и Horizon Secure Access), которые запущены на модуле Unified Access Gateway - одном из ключевых компонентов решений VMware Horizon и Workspace ONE.

С помощью этого средства можно понять:

• Производительность шлюза на основе его загрузки
• Распределение трафика
• Влияние правил Device Traffic Rules на производительность

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

• Поставляется как готовый к настройке и развертыванию виртуальный модуль (Virtual Appliance) в формате OVA:

• Веб-портал для управления инстансами Unified Access Gateway (UAG):

• Дашборды для визуализации метрик компонентов VMware Tunnel и VMware Horizon на базе Grafana:

• Возможность настройки алертов на основе различных условий, что позволяет оперативно выявлять аномалии

Скачать VMware Edge Services Observability можно по этой ссылке. Более подробная информация о продукте доступна тут.

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

Давайте посмотрим на новые возможности VMware vRA 8.4.2:

• Диски, добавленные через vRealize Orchestrator, и расширения теперь показываются в диаграмме развертывания (топология)
• Возможности шифрования Microsoft Azure disk encryption, которые поддерживают:
  • Disk Encryption для independent managed disks
  • Disk Encryption для действия Add Disk (Day 2 action)
• Группы Property groups теперь могут:
  • Использовать рабочие процессы vRO для задания свойств внешних динамических значений
  • Привязывать пароли к property groups для использования разных паролей для разных групп
• Теперь можно назначить одинаковые диапазоны IP-адресов, которые приходят от внутреннего или внешнего IPAM, для разных сетей
• События Provider Events срабатывают, когда тенант вызывает одно из действий CRUD (Create, Read, Update, and Delete)
• Настраиваемый лимит max number of supervisor namespaces, который определяет максимальное число пространств имен для проекта в заданной зоне Kubernetes
• Управление снапшотами Microsoft Azure disk snapshot management теперь поддерживает:
  • Выявление снапшотов
  • Действие по удалению снапшота (Day 2 action)
  • Совместимость Managed Disk Snapshot – поддержка параметров Resource Group, Encryption set, Network policy и Tags

Более подробно о новых возможностях и изменениях в API решения VMware vRealize Automation 8.4.2 можно прочитать в Release Notes. Скачать vRA можно по этой ссылке.

На сайте проекта VMware Labs вышло большое обновление утилиты VMware OS Optimization Tool версии v2106.

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

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

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

1. Пользовательский интерфейс

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

Экран Optimize был приведен в порядок, также элементы слева мигрировали на главную панель. Был улучшен блок системной информации, ну и был полностью переработан Analysis Summary Graph.

2. Оптимизации

Теперь в утилите есть встроенный шаблон оптимизаций версии 2.0, в котором произошли следующие изменения:

• Удалено много неактуальных элементов (например, они не изменяли дефолтные настройки Windows)
• Некоторые элементы отключали функциональность Windows, которая могла понадобиться, поэтому их тоже убрали
• Некоторые оптимизации изменяли UX/UI, но не давали существенного прироста производительности - их тоже стало меньше (но их все равно можно сделать через групповые политики или политики Dynamic Environment Manager)

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

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

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

3. Плагин Microsoft Deployment Toolkit

Теперь с утилитой идет плагин для Microsoft Deployment Toolkit (MDT), который отдельно доступен для загрузки. Он позволяет использовать MDT для автоматизации создания золотых образов ОС и добавления кастомных задач, которые можно вставлять в последовательности задач MDT:

• Install Agents - здесь можно установить VMware Tools, Horizon Agent, Dynamic Environment Manager, App Volumes Agent.
• Run OS Optimization Tool tasks – это задачи из разделов Optimize, Generalize, Finalize.

Более подробно об использовании MDK и OS Optimization Tool написано тут. Также есть специальное руководство Using Automation to Create Optimized Windows Images for VMware Horizon VMs.

4. Прочие изменения

Теперь по умолчанию не отключены блоки функций Firewall, Antivirus и Security Center. Их можно отключить в разделе Common Options перед выполнением задачи Optimize. Тут важно учесть 2 момента:

• Публично загруженные шаблоны от пользователей не проверяются со стороны VMware
• Пользователи могут создавать собственные шаблоны и экспортировать/импортировать их в формате XML

Функция и вкладка Remote Analysis был удалена из утилиты, также теперь недоступны утилиты NSUDO и SetAcl, на смену которых пришла внутренняя функциональность.

Помимо перечисленного, в утилите VMware OS Optimization Tool было исправлено множество ошибок разной степени критичности. Скачать VMware OSOT можно по этой ссылке. Основное руководство по использованию продукта доступно тут.

В начале года компания VMware запустила обновленный портал VMware Customer Connect, пришедший на смену устаревшему и неповоротливому My VMware, использовать который, зачастую, было мучением. Теперь VMware повернулась к пользователям лицом - на портале Customer Connect можно решать основные рутинные задачи, связанные...

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

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

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

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

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

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

Многие сетевые администраторы используют решение VMware vRealize Network Insight (vRNI), предназначенное для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений в виртуальном датацентре. Также в средних и крупных компаниях для управления тикетами используется ITSM-система ServiceNow, которая, помимо прочего, позволяет управлять инцидентами различного характера в ИТ-инфраструктуре, в том числе, виртуальной.

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

Сначала вам потребуется найти системный email-адрес ServiceNow. Например, для облачного продукта ServiceNow Cloud это адрес instancename@serive-now.com. Посмотреть данный адрес можно в разделе System Mailboxes -> Administration -> Email Accounts -> ServiceNow SMTP:

Затем в консоли vRNI нужно настроить отсылку почтовых нотификаций в ServiceNow для нужных алертов. Для этого идем в Settings -> Alerts and Notification -> Alerts:

Открываем нужный алерт, выставляем частоту отсылки сообщений и выбиваем почтовый адрес ServiceNow:

Теперь нужно создать Inbound Action для создания инцидента в ServiceNow. Идем в ServiceNow -> System Policy -> Email -> Inbound Actions -> New:

Там задаем имя инцидента, целевую таблицу и тип действия Record Action:

На вкладке Action нужно создать кастомный скрипт для обработки и кастомизации полей полученного сообщения:

Вот пример такого скрипта:

current.caller_id = gs.getUserID();
current.comments = "received from: " + email.origemail;
current.short_description = email.subject;
current.description = email.body_text.toString();
current.category = "network";
current.incident_state = IncidentState.NEW;
current.notify = 2;
current.contact_type = "email";
if (email.body_text.toString().indexOf('Critical') >=0 ){
 current.impact=1;
 current.urgency=1;
}
else if (email.body_text.toString().indexOf('Info')>=0 ){
 current.impact=2;
 current.urgency=3;
}
else if (email.body_text.toString().indexOf('Moderate')>=0 ){
 current.impact=2;
 current.urgency=2;
}
else if (email.body_text.toString().indexOf('Warning')>=0 ){
 current.impact=1;
 current.urgency=2;
}
if (email.body.assign != undefined)
 current.assigned_to = email.body.assign;
current.insert();

В этом скрипте можно задать параметры фиксируемого инцидента, такие как его критичность, срочность и т.п. Также вы можете написать свой сценарий на базе документации к ServiceNow. Инциденты будут отображаться в разделе Incident -> All.

Источник.

Компания VMware заявила о доступности решения VMware NSX Advanced Firewall for VMware Cloud on AWS, предназначенного для защиты сетевых соединений организаций, использующий публичное облако VMware Cloud на базе инфраструктуры AWS SDDC (software-defined data center). С помощью этого фаервола администраторы смогут контролировать все коммуникации на уровне 7, используя DPI-техники анализа пакетов на всех виртуальных сетевых адаптерах vNICS виртуальных машин на хостах ESXi виртуального датацентра SDDC.

Используя NSX Advanced Firewall for VMConAWS, вы получите следующие возможности:

• Обнаружение попыток использования эксплоитов и уязвимостей в вашей инфраструктуре
• Защита от уязвимостей на базе гранулярных политик безопасности, работающих на уровне приложений
• Уменьшение поверхности атаки для ваших рабочих нагрузкой за счет регулирования только разрешенного трафика приложений в вашем датацентре
• Бесшовный анализ всего трафика датацентра без единой точки анализа, которая могла бы вызвать падение сетевой производительности
• Возможности для обеспечения соответствия отраслевым стандартам (compliance)

NSX Advanced Firewall можно купить как аддон к вашей инфраструктуре VMware Cloud on AWS. Подробнее об этом фаерволе вы можете прочитать в блоге VMware.

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

Во-первых, в колонке слева теперь доступна информация не по 12 продуктам, как раньше, а по 34, среди которых есть и относительно новые, такие как Tanzu Kubernetes Grid и Lifecycle Manager:

Во-вторых, в верхней части страницы появилась вкладка «Network Diagrams», где собраны несколько сетевых диаграмм, наглядно показывающих соединения между различными компонентами продуктов:

Пока таких диаграмм немного, но список решений будет пополняться.

Компания VMware анонсировала обновление решения VMware HCX 4.1, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о версии HCX 4.0 мы писали весной этого года вот тут.

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

1. Предиктивные оценки для пакетных миграций

В версии 4.0 появилась оценка пакетных миграций (Bulk Migrations), а в версии 4.1 появился драфтинг процесса оценки пакетных миграций, что позволяет быстро сделать прикидку по времени переноса ВМ:

2. Seed Checkpoint для пакетных миграций

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

3. Финальная доступность Mobility Optimized Networking (MON)

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

Это позволяет избежать hairpin-эффекта:

4. Увеличенные максимумы VMware HCX

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

Скачать VMware HCX 4.1 можно по этой ссылке, Release Notes доступны тут.

Как вы знаете, в кластере отказоустойчивости VMware HA есть Primary и Secondary хосты серверов ESXi. Первые отвечают за управление кластером и восстановление виртуальных машин, а вторые – только за исполнение операций и рестарт ВМ. Недавно мы, кстати, писали о том, как сделать хост VMware vSphere Primary (он же Master) в кластере HA, а сегодня расскажем о том, какие события происходят на этих хостах в случае отказа хоста (именно полного отказа, а не при недоступности, например, его в сети).

Как пишет Дункан Эппинг, если отказывает хост Secondary, то происходят следующие вещи, начиная с времени T0:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+3 секунды – хост Primary начинает отслеживать хартбиты на хранилище в течение 15 секунд
• T+10 секунд – хост помечается как unreachable и Primary хост начинает пинговать его Management Network (постоянно в течение 5 секунд)
• T+15 секунд – если на датасторе на настроены хартбиты, то хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
• Либо если настроены хартбиты, но их нет, то через T+18 секунд хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин

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

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+10 секунд – начинаются выборы нового Primary хоста в кластере
• T+25 секунд - выбор хоста Primary сделан и он читает список виртуальных машин, а также ждет, пока Secondary хосты сообщат о своих виртуальных машинах
• T+35 секунд – старый хост Primary помечается как unreachable
• T+50 секунд – хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин согласно списку нового Primary

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

Многие администраторы VMware vSphere 7 после выхода обновления Update 2 этой платформы были удивлены, что многие настройки пропали из основного конфигурационного файла esx.conf. Мы уже рассказывали о configstore – хранилище настроек, к которому можно получить доступ через импорт и экспорт настроек в формате JSON.

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

configstorecli config current get -c esx -g network_vss -k switches

Ну а экспортировать эти настройки в JSON-файл можно командой:

configstorecli config current get -c esx -g network_vss -k switches > vswitch.json

Далее вы просто открываете этот файл в текстовом редакторе и изменяете имя коммутатора c vSwitch0 на нужное:

Потом получившийся файл нужно обратно импортировать в configstore:

configstorecli config current set -c esx -g network_vss -k switches -i vswitch.json --overwrite

После этого вы увидите изменения в vSphere Client:

Также Дункан записал видео, в котором показан этот процесс:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это позволяет вам получить ответы на следующие вопросы:

• Какие рекомендации DRS сделал на основе анализа cost/benefit
• Почему DRS сделал именно эту рекомендацию
• Почему DRS вообще иногда не делает рекомендаци для балансировки кластера
• Как кастомное правило affinity/anti-affinity влияет на балансировку в кластере
• Где взять полный список рекомендаций DRS

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

DRS Dump Insight User Guide небольшой и занимает всего 20 страниц, но там есть очень конкретные рекомендации по работе с интерфейсом утилиты и по трактовке ее результатов:

Напомним, что DRS Dump Insight в целом может делать следующие вещи:

• Автоматизация воспроизведения дампов (с помощью встроенных кастомных DRS replayers)
• Предоставление и визуализация дополнительной информации, которая недоступна в обычных анализаторах логов
• Парсинг и анализ логов для понимания и наглядного отображения решений балансировщика DRS
• Генерация итогового результата в текстовом формате

Скачать VMware vSphere DRS Dump Insight User Guide можно по этой ссылке.

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

Одной из новых возможностей июньского релиза Log Insight Cloud стала возможность Live Tail для логов, в которых вы ищете источники проблем. Этот механизм позволяет в реальном времени "прицепиться" к файлам журнала, например, определенного хоста и отслеживать там нужные вам параметры.

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

Тут рабочий процесс может выглядеть следующим образом:

• Добавляем ключевое слово, например, имя вебсайта
• Добавляем log_type для сужения области отслеживания, в данном случае Apache
• Добавляем фильтр, чтобы убедиться, что мы отслеживаем только те логи, где есть поле remote_host
• Добавляем колонку remote_host, чтобы видеть в реальном потоке, с какими хостами происходят соединения

Перейти в представление Live Tail можно по кнопке в правом верхнем углу раздела Export Logs:

Любой запрос можно добавить в Избранное (создать Favorite Query), после чего его можно выбирать для отслеживания в режиме Live Tail:

Для фильтрации можно использовать составные фильтры по множеству условий:

Ключевое слово подсвечивается в самом логе:

Live stream можно останавливать и запускать снова, а элементы лога можно развернуть, чтобы посмотреть детали записи:

Отображаемые колонки можно добавлять и удалять:

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

Помимо функций Live Tail, в июньском релизе были также добавлены новые дэшборды и запросы для AWS и Azure.

Так теперь выглядят новые интеграции для AWS:

Например, вот дэшборд EventBridge Overview:

А вот все дэшборды для EventBridge:

Ну а вот так выглядят новые интеграции для Azure:

Если вы хотите попробовать поработать с VMware vRealize Log Insight в облаке AWS или Azure, то VMware предоставляет пробную версию на 30 дней.

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

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

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

service-control --restart vsphere-ui

Компания VMware рассказала о том, что поменяется в содержательной части главного события года в сфере виртуализации в этом году - конференции VMworld 2021, которая пройдет 5-7 октября этого года. Перед этим мероприятием VMware получила около 1500 заявок на выступления и доклады от всех участников своей экосистемы (заказчики, партнеры, технические специалисты и блоггеры).

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

• Основной фокус будет сделан на заказчиках VMware, которые могут поделиться примерами использования продуктов и технологий из реальной жизни.
• Будет больше экспертных сессий с глубоко техническим контентом, для которых предусмотрен специальный билет Tech+. Он позволит больше общаться с экспертами и иметь доступ к документам уровня "deep dive".
• Бизнес и технические сессии будут разделяться по уровням сложности 100 и 200, также будут специальные технические сессии повышенной сложности с уровнем T300.
• Вернутся технические сессии, касающиеся VMware Design Studio и VMware {code} - об этом просили многие участники.
• Сессии можно будет также искать по метатемам, таким как управление несколькими облаками, защита современных приложений и облачных сервисов, использование перспективных технологий и т.п.

Не обойдется и без таких тем, как diversity, equity, inclusion и sustainability (хотя не очень понятно, как они относятся именно к виртуализации - но, видимо, у VMware уже есть и какая-то социальная миссия).

Регистрация на VMworld 2021 будет открыта с 15 июня по этой ссылке. Кстати, интересно, что прошлый VMworld Online посетили боле 100 тысяч участников.

Многие Enterprise-администраторы настраивают автоматический регулярный бэкап решения для виртуализации и агрегации сетей VMware NSX-T из консоли, что описано, например, вот тут.

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

В случае падения задачи бэкапа информация об этом доступна только в разделе Backup & Restore настроек:

Эту информацию можно получить и через API:

> GET /api/v1/cluster/backups/history HTTP/1.1
{
  "cluster_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615489436",
      "start_time": 1615489436085,
      "end_time": 1615489440865,
      "success": false,
      "error_code": "BACKUP_AUTHENTICATION_FAILURE",
      "error_message": "either backup server login failed or unauthorized access to backup directory"
    }
  ],
  "node_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615403036",
      "start_time": 1615403036017,
      "end_time": 1615403354709,
      "success": true
    }
  ],
  "inventory_backup_statuses": [
    {
      "backup_id": "inventory-1615490636",
      "start_time": 1615490636254,
      "end_time": 1615490641758,
      "success": true
    }
  ]
}

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

Коллега с virten.net написал сценарий на Python для Nagios, который позволит вам проверить статус последнего бэкапа кластера NSX-T, а также посмотреть возраст последней имеющейся резервной копии:

usage: check_nsxt_backup.py [-h] -n NSX_HOST [-t TCP_PORT] -u USER -p PASSWORD
                            [-i] [-a MAX_AGE]

# python check_nsxt_backup.py -n nsx.virten.lab -u audit -p password
NSX-T cluster backup failed
NSX-T node backup is to old (1461 minutes)

На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.

Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:

https://download3.vmware.com/software/vmw-tools/lib.json

Кстати, все статьи о вложенной виртуализации можно найти и у нас по тегу Nested.

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper