Многие из вас, прочитав заголовок этой новости, не вспомнят продукта Dynamic Environment Manager у VMware. Но тут все просто - так теперь называется решение по управлению пользовательскими окружениями на уровне ОС VMware User Environment Manager (напомним, что о прошлой версии UEM 9.8 мы писали вот тут).

Ранее мы рассказывали о новых возможностях VMware Horizon 7.10 и VMware Horizon Clients 5.2, а сегодня посмотрим, что нового появилось в VMware Dynamic Environment Manager 9.9 и App Volumes 2.18 (прошлую версию App Volumes мы упоминали вот тут).

В Dynamic Environment Manager 9.9 появилось всего пара нововведений: во-первых, это функция Active Directory Attribute Condition. Она позволяет проверить соответствует ли заданный аттрибут Active Directory заданному критерию.

Ну и, во-вторых, это расширенная конфигурация для сбора логов и диагностики продукта:

Скачать VMware DEM 9.9 можно по этой ссылке. Кстати, очень крутое руководство по продукту находится тут.

Что касается VMware App Volumes 2.18, то тут появились следующие новые возможности:

• Централизованное управление задачами - администраторы могут использовать вкладку Jobs в разделе Activity графического интерфейса App Volumes Manager для тонкой настройки задач в больших инсталляциях. Более подробно об этом рассказано здесь.
• Появилась поддержка ОС Windows Server 2019.
• Была добавлена поддержка протокола IPv6.
• Обновилась подсистема безопасности.
• Добавлена поддержка накатывания апгрейда серверов App Volumes Manager 2.18 на более поздние версии.

Скачать VMware App Volumes 2.18 можно по этой ссылке. Release Notes находятся здесь.

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

Напомним, что о первой версии данной утилиты мы писали летом этого года вот тут. Давайте посмотрим, что нового появилось в Virtual Machine Compute Optimizer 2.0:

• Собираются приоритеты найденных несоответствий.
• Вывод деталей найденных несоответствий.
• Собирается информация о кластере, чтобы определить совместимость оборудования хостов на уровне кластера.
• В отчет добавляется информация, если виртуальная машина использует разные физические pNUMA узлы, которые транслируются в гостевую ОС.
• Добавляется информация об измененных расширенных настройках на уровне ВМ или хоста ESXi, касающихся представления pNUMA-узлов в гостевую ОС.
• В отчет попадают ВМ, если у них число vCPU (с использованием гипертрэдов как vCPU) превышает число физических ядер CPU на хосте ESXi.
• Возможность использовать отдельную функцию Get-OptimalvCPU для получения еще большей гибкости.

Скачать VM Compute Optimizer 2.0 можно по этой ссылке. Данный сценарий PowerCLI можно запустить различными способами, смотрите сопровождающий PDF (можно выбрать в комбобоксе при загрузке) для получения более детальной информации.

Интересно наблюдать за тем, какими темпами компания VMware наверстывает упущенное по наращиванию функциональности мобильного клиента для VMware vSphere. Еще совсем недавно мы писали о версии 1.5, а на днях был выпущен уже обновленный VMware vSphere Mobile Client 1.6.

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

• Хосты ESXi теперь можно перезагружать из интерфейса мобильного клиента.
• Последние задачи теперь можно видеть в представлении Tasks (статусы running/in-progress).
• Был проведен редизайн карточек объектов (ВМ, хост, кластер и задача).
• Быстрые действия с объектом теперь можно вывести по тапу на него.
• Карточка виртуальной машины содержит скриншот гостевой ОС, который можно увеличить, тапнув на него.
• На дэшборд был добавлен портлет обратной связи, который позволяет написать разработчикам отзыв о приложении.
• Для хостов ESXi теперь доступы графики производительности.
• Меню навигации было укрупнено, поэтому теперь проще попадать по его элементам.

Скачать обновленный vSphere Mobile Client 1.6 можно по этим ссылкам:

• Android (доступно как Early access приложение).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

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

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

Новое в VMware Horizon Client 5.2 for Windows:

• Функция "Log in as current user" поддерживается для однонаправленных трастовых доменов.
• Функци Real-Time Audio-Video и scanner redirection поддерживаются в режиме вложенной виртуализации (см. подробности в KB 67248).
• Улучшенная производительность отображения картинки и уменьшение использования CPU клиентской системы за счет использования Lightweight Protocol Client вместо устаревшей консоли vmware-remotemks.
• Улучшенная производительность 3Dconnexion SpaceMouse с возможностью перенаправления USB и протоколом VMware Blast.
• Можно использовать Horizon Client для изменения разрешения и масштабирования удаленного десктопа (подробнее тут).
• Можно использовать групповые политики для настройки комбинаций горячих клавиш, например, для комбинации клавиш получения и отпускания фокуса ввода в гостевую ОС (подробнее тут).
• Возможность синхронизации нажатых состояний клавиш Num Lock, Scroll Lock и Caps Lock с клиентской системы средствами групповых политик (подробнее тут).
• Возможность разрешить проверку сертификатов для вторичных соединений через SSL прокси-сервер. Эта возможность применяется к Blast Secure Gateway и соединениям через защищенный туннель. Подробнее об этом тут.
• Возможность разрешать и запрещать соединения VMware Blast через SSL прокси-сервер. Подробнее тут.
• Возможность выбрать букву диска при перенаправлении клиентских устройств в ВМ. Как это сделать, описано тут.
• Поддержка функции Browser Redirection, которая появилась в Horizon Agent 7.10. Содержимое веб-сайтов в Google Chrome рендерится на клиентской системе вместо виртуальной машины, что снимает нагрузку с хост-серверов датацентра. Подробнее тут.
• Возможность перенаправления нескольких веб-камер и микрофонов с функциями Real-Time Audio-Video. Эта возможность требует Horizon Agent 7.10. Она не работает с опубликованными десктопами и приложениями, о ее настройке можно почитать тут.

Новое в VMware Horizon Client 5.2 for Linux:

• Обновленная поддержка 64-битных дистрибутивов RHEL:
  
  • RHEL 8 поддерживается с некоторыми ограничениями (только X11 display server protocol и без поддержки Skype for Business Virtualization).
  • RHEL 7.7 теперь поддерживается полностью.
  • RHEL 6.x больше не поддерживается, ввиду отсутствия там поддержки GTK 3.
• Поддержка GTK 3 toolkit и library для улучшенной поддержки отображения графики и прочих возможностей.
• Теперь можно использовать запуск Horizon Client в минимизированном режиме (ключ --launchMinimized), когда окно клиента спрятано в бэкграунде.
• Поддержка High Efficiency Video Decoding (HEVC) при добавлении параметра view.allowEnableHEVC, а также возможность использования прокси-сервера для VMware Blast.
• Прекращена поддержка параметров view.defaultAppSize и --appSize=.
• Прекращена поддержка параметров view.disableMaximizedApp и --disableMaximizedApp.

Новое в VMware Horizon Client 5.2 for Mac OS:

• Более быстрое восстановление соединения при открытии крышки ноутбука.
• Улучшенная производительность отображения картинки и уменьшение использования CPU клиентской системы за счет использования Lightweight Protocol Client вместо устаревшей консоли vmware-remotemks.
• Улучшенная производительность 3Dconnexion SpaceMouse с возможностью USB redirection и протоколом VMware Blast.
• Можно использовать Horizon Client для изменения разрешения и масштабирования удаленного десктопа (подробнее тут).
• Поддержка High Efficiency Video Decoding (HEVC), а также возможность использования прокси-сервера для VMware Blast. Подробнее об этом тут.
• Возможность разрешить проверку сертификатов для вторичных соединений через SSL прокси-сервер. Эта возможность применяется к Blast Secure Gateway и соединениям через защищенный туннель. Подробнее об этом тут.

Новое в VMware Horizon Client 5.2 for iOS:

• Когда вы используете Workspace ONE UEM для доставки клиентов Horizon Client на iOS-устройства, вы можете настроить позицию камеры и качество видео. Подробнее об этом рассказано тут.

Новое в VMware Horizon Client 5.2 for Android:

• Поддержка Android 10 (Q) для установки клиента.
• Поддержка режима Dark mode на Android 10 (Q) и более поздних устройствах.
• Использование консоли Google Admin для настройки приложения Horizon Client на устройствах Chromebook (таких как масштабирование и разрешение экрана, режим нескольких мониторов и другое). Подробнее об этом тут.
• Использование Workspace ONE UEM для настройки приложения Horizon Client. Подробнее об этом тут.

Как обычно, все клиенты VMware Horizon Clients 5.2 можно скачать по этой ссылке (там вы увидите, что клиенты версии 5.0, но при нажатии на загрузку, вы увидите страничку, где указана версия 5.2).

Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.

При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.

В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.

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

Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.

Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:

New-AdvancedSetting -Entity YOUR_VM_NAME -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Это же можно сделать и для групп виртуальных машин, например, находящихся в папке Test Group 1:

Get-Folder "Test Group 1" | Get-VM | New-AdvancedSetting -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.

После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.

Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):

Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.

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

На сайте проекта VMware Labs за последние дни появилась пара интересных обновлений полезных утилит. Первое - это апдейт средства vSAN Performance Monitor 1.2, предназначенного для мониторинга и визуализации (в Grafana) метрик в среде отказоустойчивых кластеров VMware vSAN.

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

В версии vSAN Performance Monitor 1.2 появились следующие улучшения:

• Исправлена проблема с настройкой CA-сертификатов
• Некоторые доработки агента, собирающиего данные
• Убран анонимный сбор статистики от influxdb

Скачать vSAN Performance Monitor 1.2 можно по этой ссылке.

Второе существенное обновление в Labs - это апдейт утилиты vRealize Operations REST Notifications Helper 1.3. О прошлой версии 1.2 этого средства мы писали вот тут. Напомним, что эта штука позволяет администратору vROPs изменять свойства алерта перед его отправкой на сторону.

В данном обновлении появились следующие новые функции:

• Добавлена конфигурация предпочитаемого HTTP-запроса
• Добавлена конфигурация маппинга критичности алерта
• Добавлены черные списки с полем resourceName
• Добавлена настройка структуры конечного устройства (endpoint) для обработки разного поведения на базе состояний сработавшего/несработавшего триггера
• Добавлено описание симптомов в одну строку как и для рекомендаций.
• Различные исправления ошибок

Обновленный vRealize Operations REST Notifications Helper 1.3 можно скачать по этой ссылке.

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

Облачный провайдер «ИТ-ГРАД» (входит в Группу МТС) и компания itelligence, SAP Platinum Partner с более чем 30-летним опытом реализации SAP-проектов, объявляют о стратегическом сотрудничестве и запуске сервиса для решений SAP по модели облачного хостинга на российских локациях.

Дата проведения: 17.10.2019
Время: 11:30

Новые возможности владения системой SAP в РФ:

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

Темы обсуждения:

• «ИТ-ГРАД» и itelligence – актуальность коллаборации
• Рынок SAP-хостинга в России – взгляд международного SAP-интегратора
• Проблемы, с которыми сталкиваются клиенты, и пути их решения
  • Некорректная оценка и планирование требований системы к объему вычислительных мощностей
  • Сжатые сроки на запуск проекта SAP
  • Завышенные инвестиции при старте новых проектов
  • Самостоятельная поддержка систем SAP
• Сравнение моделей размещения SAP: on-premise и SAP Hosting, преимущества и недостатки в разрезе IT и бизнеса
• Экономическая эффективность и выгоды использования облака
• Сравнение показателей TCO при on-premise и облачном подходе
• Ответственность сторон на примере собственных сотрудников и внешних подрядчиков
• Техническая составляющая для выбора в пользу облака
• Анализ существующих кейсов на примере SAP Hosting

Для кого:

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

Для участия в вебинаре необходима регистрация. Спешите, количество мест ограничено.

На сайте VMware обновился основной документ Product Lifecycle Matrix, в котором приведены дата доступности продукта для загрузки, окончание поддержки, завершение технического сопровожнения и дата снятия с продаж.

Документ обновился совсем недавно и актуален на 1 октября 2019 года (кстати, обращайте внимание на колонку Notes и расшифровку этих заметок в конце документа):

Для каждого из продуктов приведен тип политики поддержки по отношению к обслуживанию жизненного цикла серии продуктов. VMware разделяет эти политики на следующие типы:

• APP: - Application Platform Policy
• EAP: - Enterprise Application Policy
• EDP: - Enterprise Desktop and Mobility Policy
• EIP: - Enterprise Infrastructure Policy
• GSP: - General Support Policy
• N-2: - N-2 Policy
• N/A: - No lifecycle policy applies
• PDP: - Personal Desktop Policy
• VI3P: - VMware Infrastructure 3 Policy

Скачать VMware Product Lifecycle Matrix можно по этой ссылке. Если у вас большая инфраструктура, где есть продукты довольно древних версий, то будет полезным занести в закладки этот документ, чтобы понимать, когда нужно запланировать обновление, чтобы не остаться без поддержки от вендора.

Довольно интересная штука обнаружилась среди бесплатных средств для мониторинга виртуальной инфраструктуры VMware vSphere - утилита с неблагозвучным названием LPAR2RRD. Оказывается на днях вышла ее версия 6.1, где появилось несколько новых возможностей.

Сама утилита LPAR2RRD - это бесплатное средство мониторинга для сред VMware vSphere и IBM Power Systems без агентов, которое позволяет отслеживать различные аспекты производительности хостов и виртуальных машин. Если же поставить агенты в ОС, то решение будет работать и с такими системами, как AIX & Linux, IBM i (AS/400) и Solaris.

Полнофункциональное демо этого продукта доступно по этой ссылке.

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

• Мониторинг ресурсов
  • vCenter
  • Cluster
  • Resource Pool
  • Datastore
  • ESXi
  • Virtual Machine
• Метрики мониторинга
  • Производительность CPU (GHz, число CPU, показатель CPU ready)
  • Использование памяти (reserved, granted, consumed, active, baloon, swap in, limit)
  • Производительность LAN в МБ/сек
  • Производительность дисковой подсистемы (МБ/сек, IO per sec, latency в миллисекундах)
  • Использование дисков (ГБ)
• Другие возможности
  • Функция Trends
  • Исторические отчеты
  • Функции Heatmap
  • Возможность масштабирования графиков

Для тех, кто знаком с этим решением, вот список новых возможностей LPAR2RRD 6.1, вышедшей в октябре:

• Новый раздел Dashboard - полностью кастомизабельное пространство для графиков и диаграмм. Пользователь может менять размер графиков, создавать группы и двигать графики между ними.
• Раздел Heatmap - добавлена визуализация в сортируемых и фильтруемых таблицах.
• Улучшенная конфигурация через REST API для IBM Power Systems в части виртуальных сетей vSCSI и NPIV.
• Поддержка папок для vSphere (VM, Datastores).
• Таблица использования пространства виртуальными машинами в кластере (VM SPACE).
• Поддержка формата CSV в компоненте Reporter.
• Структура меню Hyper-V консолидирована по использованию ресурсов на вкладках вместо подразделов меню.
• Поддержка Solaris: мониторинг пулов.
• Reporter: поддержка Solaris и Hyper-V.
• Reporter: поддержка функционала TOP10 (графики можно вывести в pdf).
• Reporter: доступен файл с рекомендациями конфигурации в формате CSV.
• Поддержка кастомных групп для Hyper-V.
• Улучшения контроля доступа (ACL) - роль read-only.
• Множество небольших улучшений и багофиксов для следующих платформ:
  • IBM Power Systems: HMC REST API
  • Oracle Solaris
  • Microsoft Windows и Hyper-V

Скачать LPAR2RRD можно абсолютно бесплатно в виде виртуального модуля (Virtual Appliance) вот здесь.

Некоторое время назад мы писали о новых возможностях продукта VMware vCloud Director 10.0, которые раскрыл Daniel Paluszek. На днях он сделал еще очень полезную диаграмму, которая раскрывают логику миграции на vCD 10 с предыдущих версий.

Daniel использовал утилиту MindNode для составления данной диаграммы апгрейда на vCD 10. Как видно на картинках, там описаны разные варианты исходной системы, например, вы решите пойти по пути обновления только Linux / External PostgreSQL (PgSQL) с раздельной инсталляцией vCD или сделаете интегрированные виртуальные модули vCloud Director.

Диаграмма доступна как с фоном, так и с прозрачностью PNG-формата:

Для Linux-систем Daniel отмечает следующие моменты:

1. vCD 10.0 поддерживает только PostgreSQL, у него нет больше поддержки Microsoft SQL Server. Oracle уже прекратил поддерживаться ранее, поэтому все пути миграции ведут на PgSQL в данных диаграммах.
2. Использование виртуального модуля vCD позволяет обеспечить высокую доступность PgSQL, но в случае сбоя нужно будет вручную переключаться на реплику.
3. Использование внешнего экземпляра PostgreSQL полностью поддерживается. Но нужно внимательно следить за конфигурацией соединения к БД.
4. VMware будет продолжать поставлять как установщик, так и виртуальный модуль vCD. Поэтому можно использовать оба варианта, в зависимости от нужд вашей команды.

Более подробно о данных диаграммах можно почитать у Daniel Paluszek.

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

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

• Проблемы сетевых соединений vMotion
  • Хосты ESXi не пингуются или отваливаются по таймауту в 20 секунд.
  • Несоответствие MTU между интерфейсом VMkernel и данным параметром в сети (на коммутаторах или маршрутизаторах).
  • Неправильная конфигурация сети на хостах ESXi.
• Проблемы хранилищ
  • Целевой датастор недоступен или переведен в статус APD (All Paths Down).
  • Таймаут операций ввода-вывода (I/O) составляет 20 секунд или более.
• Операция vMotion прошла успешно, но наблюдаются проблемы с гостевой ОС.
  • Ошибка VM network is not reachable – на уровне layer-2 нет соединения на целевом хосте ESXi.
• Ошибки, связанные с ресурсами.
  • В течение долгого времени хост не может выделить память виртуальной машине.
  • Свопирование идет очень долго, что приводит к вываливанию vMotion по таймауту.

При траблшутинге vMotion, в первую очередь, проверьте, что в вашей инфраструктуре соблюдаются основные требования, приведенные здесь.

С точки зрения логирования процесса vMotion, он устроен следующим образом:

Из картинки видно, что 4 лог-файла можно найти на хосте ESXi и один - на сервере vCenter.

Демоны vCenter Daemon (VPXD), vCenter Agent (VPXA) и Host Daemon (hostd) - это основные службы, которые отвечают за процесс миграции vMotion, и именно там следует начинать искать проблему. Что касается компонентов, отвечающих за реализацию на стороне ВМ - это процесс VMX и службы VMkernel.

Первый шаг траблшутинга - это найти Operation ID (opID) операции vMotion в логах. Этот opID отсылает уже к нужному Migration ID на обоих хостах ESXi.

VPXD-лог на vCenter Server позволит найти opID. Для этого залогиньтесь на VCSA (vCenter Server Appliance) и выполните команду:

grep "relocate" /var/log/vmware/vpxd/vpxd-*.log | grep BEGIN

В выводе команды вы найдете нужный opID:

/var/log/vmware/vpxd/vpxd-214.log:2019-09-24T15:38:10.042Z info vpxd[29243] [Originator@6876 sub=vpxLro opID=jzlgfw8g-11824-auto-94h-h5:70003561-20] [VpxLRO] — BEGIN task-8031 — vm-269 — vim.VirtualMachine.relocate — 52b17681-35d1-998b-da39-de07b7925dda(520681db-25b7-c5d6-44d7-6a056620e043)

Далее, зная opID, вы можете найти Migration ID в hostd-логах на соответствующих хостах ESXi. Делается это следующей командой:

grep jzlgfw8g-11824-auto-94h-h5:70003561-20 /var/log/hostd.log | grep -i migrate

Исходный хост ESXi

2019-09-24T15:38:47.070Z info hostd[2100388] [Originator@6876 sub=Vcsvc.VMotionSrc.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1 2019-09-24T15:38:47.072Z info hostd[2100388] [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/b86202d8-fb958817-0000-000000000000/NH-DC-02/NH-DC-02.vmx opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-10-e036 user=vpxuser:VSPHERE.LOCAL\Administrator] VigorMigrateNotifyCb:: hostlog state changed from success to none

Целевой хост ESXi

2019-09-24T15:38:47.136Z info hostd[2099828] [Originator@6876 sub=Vcsvc.VMotionDst.3117907752192811422 opID=jzlgfw8g-11824-auto-94h-h5:70003561-20-01-2c-3c35 user=vpxuser:VSPHERE.LOCAL\Administrator] VMotionEntry: migrateType = 1

На стороне VMkernel вы можете найти информацию о неудачной миграции следующей командой:

grep VMotion /var/log/vmkernel*

Исходный хост ESXi:

019-09-24T15:38:47.402Z cpu13:46101760)VMotionUtil: 5199: 3117907752192811422 S: Stream connection 1 added.

2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 2062: Allocating pool 0.

2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:38:47.445Z cpu8:46092538)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

2019-09-24T15:38:47.445Z cpu8:46092538)VMotion: 8134: 3117907752192811422 S: Requiring explicit resume handshake.

2019-09-24T15:38:47.445Z cpu13:46101760)XVMotion: 3384: 3117907752192811422 S: Starting XVMotion stream.

2019-09-24T15:39:34.622Z cpu14:46101762)VMotion: 5426: 3117907752192811422 S: Disk copy complete, no bandwidth estimate.

2019-09-24T15:39:34.905Z cpu24:46092539)VMotion: 5281: 3117907752192811422 S: Stopping pre-copy: only 37 pages left to send, which can be sent within the switchover time goal of 0.500 seconds (network bandwidth ~185.134 MB/s, 1536000% t2d)

2019-09-24T15:39:34.965Z cpu13:46101760)VMotionSend: 5095: 3117907752192811422 S: Sent all modified pages to destination (network bandwidth ~281.100 MB/s)

2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:39:35.140Z cpu15:46101757)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

Целевой хост ESXi:

2019-09-24T15:38:47.397Z cpu15:2099283)VMotionUtil: 5199: 3117907752192811422 D: Stream connection 1 added.

2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 2062: Allocating pool 0.

2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:38:47.440Z cpu3:3543984)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

2019-09-24T15:38:47.440Z cpu3:3543984)VMotion: 8134: 3117907752192811422 D: Requiring explicit resume handshake.

2019-09-24T15:39:34.907Z cpu3:3543984)VMotionRecv: 761: 3117907752192811422 D: Estimated network bandwidth 205.138 MB/s during pre-copy

2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2961: 3117907752192811422 D: DONE paging in

2019-09-24T15:39:34.960Z cpu3:3543984)VMotionRecv: 2969: 3117907752192811422 D: Estimated network bandwidth 200.096 MB/s during page-in

2019-09-24T15:39:35.059Z cpu6:3543972)VMotion: 6675: 3117907752192811422 D: Received all changed pages.

2019-09-24T15:39:35.067Z cpu1:3543972)VMotion: 6454: 3117907752192811422 D: Resume handshake successful

2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap page: len = 16384, pgLen = 1, bitSet = 3001, bitClear = 13383.

2019-09-24T15:39:35.082Z cpu6:3543980)XVMotion: 642: Bitmap block: len = 131072, pgLen = 4, bitSet = 131072, bitClear = 0.

В выводе вы можете увидеть такие интересные вещи, как, например, средняя скорость (average bandwidth), которая была получена при передаче данных (см. вывод).

В папке с виртуальной машиной находится файл vmware.log, в котором также можно найти информацию о неудавшемся vMotion с учетом исходного и целевого IP-адресов хостов ESXi:

2019-09-24T15:38:47.280Z| vmx| I125: Received migrate ‘from’ request for mid id 3117907752192811422, src ip <192.168.200.93>.
2019-09-24T15:38:47.280Z| vmx| I125: MigrateSetInfo: state=8 srcIp=<192.168.200.93> dstIp=<192.168.200.91> mid=3117907752192811422 uuid=4c4c4544-004a-4c10-8044-c7c04f4d4e32 priority=high
2019-09-24T15:38:47.282Z| vmx| I125: MigID: 3117907752192811422
2019-09-24T15:39:34.971Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422
2019-09-24T15:39:35.023Z| vmx| I125: Migrate_Open: Restoring from <192.168.200.93> with migration id 3117907752192811422

Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.

Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:

Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.

Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:

Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:

Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:

В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?

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

В кластере vSAN это выглядит вот так:

Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.

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

С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):

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

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

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

С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:

Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.

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

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

• Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
• Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
• Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
• Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
• Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
• Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.

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

Обновленный USB Network Native Driver 1.2 теперь дополнительно поддерживает следующие устройства:

• Aquantia Multi-Gig (1G/2.5G/5G) USB network adapter (компания Aquantia - это часть Marvell, кстати это также и производитель адаптеров 10GbE NICs в Mac Mini 2018 и новых iMac Pro).
• Поддержка функции Auto Speed/Connection detection для чипсетов RTL8153/RTL8152.

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

Как пишет Вильям Лам, адаптер  USB-based Multi-Gigabit Network Adapter (QNA-UC5G1T) от QNAP теперь полностью поддерживается (он есть в таблице выше), и он может работать на скоростях 1Gbps, 2.5Gbps и 5Gbps. Но на практике USB 3.1 выдает не больше 3Gbps:

Скачать USB Network Native Driver 1.2 можно по этой ссылке.

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

Давайте посмотрим, что нового в vSphere Mobile Client версий 1.4 и 1.5 (кстати, в Changelog версия 1.5 была ошибочно обозначена также как 1.4):

• Теперь поддерживаются прямые соединения к хостам ESXi, а не только через vCenter.
• Хост ESXi можно перевести в режим обслуживания (maintenance mode).
• Новое представление Cluster View, где видны события кластера.
• Появился диалог подтверждения при быстрых операциях с виртуальными машинами.
• Карточка кластера теперь показывает имеющиеся проблемы, статус DRS и HA, а также число событий vMotion.
• Карточка хоста ESXi показывает имеющиеся проблемы, число виртуальных машин, текущий аптайм и статус соединения.
• Выход из деталей ВМ обратно не обновляет страницу.
• Множество исправлений ошибок.

Скачать обновленный vSphere Mobile Client 1.5 можно по этим ссылкам:

• Android (в комбобоксе загрузки просто выберите apk-файл).
• iOS - до того, как ставить это приложение на айфон, нужно скачать приложение для тестировщиков Test Flight.

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

Да, все еще продолжаем рассказывать об анонсах конференции VMworld 2019. Одним из главных обновлений в части сетевой инфраструктуры стал выпуск платформы VMware NSX-T 2.5. Новые возможности продукта сосредоточены в следующих сферах:

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

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

1. Новый движок NSX Intelligence.

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

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

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

2. Улучшения механизма работы в гибридной среде (Hybrid Cloud Networking).

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

В версии NSX-T 2.5 появился новый режим развертывания и функционирования - Native Cloud Enforced. Он позволяет обеспечить соблюдение унифицированных политик в гибридной среде без необходимости установки агентов (NSX tools) в виртуальных машинах, а значит не создает дополнительную нагрузку на них. Эти политики через API транслируются в инфраструктуру сервис-провайдера, где они уже применяются к виртуальным машинам и приложениям средствами облачного ПО.

Этот режим реализуется в дополнение к режиму NSX Enforced, который требует установки агентов и более гранулярно следит за политиками безопасности. Каждый из режимов имеет свои преимущества и недостатки. Вот как выглядит режим Native Cloud Enforced для решения NSX Cloud on Azure:

3. Улучшения комплаенса и безопасности.

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

• Соответствие регуляции FIPS 140-2 (не актуально для России).
• Поддержка L4-L7 функций распределенного фаервола (DFW), механизма Identity/User ID firewalling и белых списков FQDN/URL.
• Правила Layer 7 на базе application ID в сетевом экране шлюза NSX Edge для трафика north-south.
• Поддержка Layer 7 сетевой фильтрации на базе application ID в DFW для гипервизоров KVM.
• VPN на уровне каждого клиента у сервис-провайдеров. Ранее IPsec-соединение поддерживалось только в шлюзах Tier 0, теперь же в целях большей изоляции VPN выделен на уровне клиента и изолируется внутри облака.
• NSX-T поддерживает откидывание копий пакетов на сервисную ВМ (Service Virtual Machine, SVM), такую как Gigamon или NETSCOUT для анализа, мониторинга и сбора статистики. Это позволяет не организовывать дополнительный канал прохождения трафика через эти сервисы.

4. Улучшенные возможности операционного управления Day-2.

Здесь появилось 2 основных улучшения:

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

• Дэшборд Capacity Monitoring. Этот дэшборд показывает текущее использование объектов (таких как логические коммутаторы, логические роутеры TO/T1, экземпляры DHCP-серверов, правила NAT) по отношению к доступным максимумам конфигурации.

Скачать решение VMware NSX-T 2.5 можно по этой ссылке. Документация доступна тут.

Среди множества анонсов конференции VMworld 2019, которая прошла в августе этого года, мы забыли рассказать о новой версии VMware vRealize Network Insight 5.0 (vRNI). Напомним, что это решение позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Напомним, что о прошлой версии VMware vRNI 4.2 мы писали вот тут.

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

1. Поддержка решения VeloCloud.

Компания VeloCloud не так давно была куплена компанией VMware. VeloCloud производит решение SD-WAN, которое позволяет воплотить принципы Software-Defined Networking в рамках WAN-сетей. Здесь появились 3 основных момента:

• End-to-End мониторинг соединений SD-WAN в облаке и онпремизном датацентре.
• Анализ потока и трафика приложений и бизнес-сервисов, используемых на Edge-площадках.
• Уровень видимости Site/Branch и решение проблем приложений в собственном датацентре и облачной инфраструктуре.

Основное, на чем сфокусирован этот релиз vRNI 5.0 - обеспечение комплексной видимости сетевых потоков датацентров в гибридной и мультиоблачной среде.

2. Поддержка облака Microsoft Azure.

Как некоторые знают, прошлая версия vRNI поддерживала облака VMware Cloud on AWS, включая решение по управлению контейнерами Kubernetes - VMware Enterprise PKS, а также среды контейнеров OpenShift. Теперь же vRNI пятой версии поддерживает и облачные инфраструктуры Microsoft Azure.

Сегодня гибридные Enterprise-инфраструктуры очень часто используют ресурсы облака Azure, поэтому появление такой поддержки со стороны vRNI было вполне ожидаемым. Этот релиз содержит функции для работы с такими сервисами, как Application Discovery, Application Dependency Mapping, Security Recommendations, Network Flow Analysis и прочими, которые доступны в одной консоли с помощью инвентаря Azure.

Единую консоль управления теперь можно использовать как для собственной инфраструктуры (частного облака), так и для приложений в средах VMware Cloud on AWS, Amazon AWS и Microsoft Azure.

Те, кто хочет почитать об окупаемости внедрения решения vRNI, могут почитать вот такой Case Study.

Решение Network Insight Cloud можно попробовать бесплатно как обланый сервис VMware Cloud Service в течение 30 дней по этой ссылке.

Компания VMware наконец объявила о выпуске новой мажорно версии пакета для гоствых ОС VMware Tools 11. Напомним, что о предыдущей версии VMware Tools 10.3 мы уже довольно давно писали вот тут.

Давайте посмотрим, что нового есть в VMware Tools 11:

• Улучшенная интеграция со службой обновления Microsoft Update Service. Обновленные драйверы (pvscsi, vmxnet3 and vmci) будут доступны через этот сервис для Windows Server 2016 и более поздние, как только произойдет их публикация.
• Обновленный компилятор VMware Tools - теперь это Microsoft Visual Studio 2017.
• VMware Tools 11 версии теперь поддерживается для MacOS 10.14.5. Это полноценная версия пакета, которая будет развиваться. А вот для Linux разработка новых фичей - наоборот, приостановлена.
• Добавлена поддержка дополнительного драйвера под AppDefense. Это позволяет гостевому модулю AppDefense обновляться без перезагрузки гостевой ОС. Больше подробностей об этом приведено здесь.
• Добавлен читаемый с хоста параметр AppInfo для публикации информации о запущенных приложений внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). Подробнее тут.
• Добавлена возможность для администратора гостевой ОС контролировать автоматический апгрейд (можно его остановить) и удаление фичей администратором vSphere. Подробнее тут.
• Добавлена поддержка режима GDI Hardware Acceleration в версии драйвера WDDM 1.1.
• Добавлен пример конфигурации tool.conf для упрощения администрирования настроек. Подробнее тут.
• Была существенно улучшена производительность в плане коммуникации между хостом и гостевой ОС.
• Устранены некоторые ошибки, описание приведено здесь.

Скачать VMware Tools 11 для соответствующих гостевых ОС можно по этой ссылке.

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

Последний раз мы писали про эту утилиту в апреле прошлого года, давайте же посмотрим, что нового появилось в VMware OS Optimization Tool b1110:

• Новая кнопка Common Options - позволяет быстро выбрать и настроить параметры для управления общей функциональностью. Теперь в интерфейсе можно с помощью данного блока выбрать нужный вариант тюнинга, не заглядывая в различные индивидуальные настройки в разных разделах.
• Разделение Windows 10 на 2 шаблона, чтобы лучше обрабатывать различия между этими двумя версиями. Один шаблон для версий 1507-1803, а второй - для 1809-1909.
• Улучшенные оптимизации для Windows 10, особенно для версий 1809 - 1909.
• Исправлены многочисленные ошибки: сброс настроек при сохранении кастомизированных шаблонов, недоступные ссылки на вкладке Reference, недоступность Windows Store после оптимизации и многое другое.

Для новых версий Windows 10 была добавлена следующая функциональность для шаблонов:

• Перемещение элементов между mandatory user и current user к default user.
• Добавлено 34 новых элемента групповых политик, относящихся к OneDrive, Microsoft Edge, приватности, Windows Update, нотификациям и диагностике.
• Добавлено 6 элементов в группу Disable Services.
• Добавлен 1 элемент в группу Disable Scheduled Tasks.
• Добавлен 1 элемент в группу HKEY_USERS\temp настроек реестра.
• Добавлен 2 элемента в группу настроек HKLM.
• Упрощено удаление встроенных приложений Windows (кроме Windows Store).

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

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

Давайте посмотрим, что нового в VMware Horizon 7.10:

1. Обновления платформы Horizon 7.10.

Новый апдейт платформы Horizon включает обновление Extended Service Branch update, которое содержит в себе много исправлений ошибок, поддержку новой Windows 10, а также обновления компонентов, необходимых для работы инфраструктуры виртуальных ПК.

Такое обновление уже не выпускалось с версии 7.5, поэтому будет очень кстати сейчас. Напомним, что Extended Service Branch - это параллельный релиз Horizon 7 для тех, кому нужна стабильная версия окружения для своих виртуальных десктопов. Он включает в себя полный пакет продуктов VMware Horizon 7, App Volumes, Dynamic Environment Manager (так теперь называется User Environment Manager) и Unified Access Gateway.

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

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

• Функция бэкапа Global Data Layer Backup для конфигураций CPA (Cloud Pod Architecture) - теперь поддерживается возможность резервного копирования и восстановления конфигурации LDAP, что позволяет восстановить CPA-конфигурацию в случае сбоя.
• REST APIs – теперь можно писать функции автоматизации или интегрировать сторонние продукты для административных задач или мониторинга.
• Поддержка RTX GPU – теперь поддерживается еще больше GPUs на базе архитектуры Turing для тяжелых (графических и вычислительных) нагрузок, а также протокол Blast Extreme H.265 и H.264.
• Instant Clones теперь поддерживают IPv6. Кроме того сценарии cleanup scripts для мгновенных клонов стали более user-friendly.

2. Обновления Horizon 7 Administrator и Horizon Console

Различий между новым HTML5 интерфейсом Horizon Console и старой консолью Horizon 7 Administrator продолжает становиться все меньше и меньше. В этом релизе были добавлены еще новые функции в HTML5-консоль, поэтому теперь в старом интерфейсе уникальной функциональностью осталось только управление приложениями ThinApp и работа с ролью Security Server.

Начиная с этой версии, кстати, VMware будет добавлять новые возможности только в Horizon Console. Поэтому тут появились такие новые фичи, как назначения для механизма JMP, обновленные иконки Hosted App, статус мгновенных клонов для хостов RDSH и другие. Также на новом дэшборде можно увидеть статус сервисов и сессий Horizon, а также их состояние. Больше подробностей вы можете увидеть в видео выше.

3. Новые возможности Horizon Agents.

Теперь для агентов Windows и Linux доступны возможности улучшенного использования CPU для протокола Blast. Агент Horizon Agent теперь автоматически устанавливает роль RDS на серверную ОС, а также предоставляет поддержку ОС Windows 10 1909 и Red Hat 8.

Horizon Agent теперь поддерживает функцию Browser Content Redirection, которая перехватывает все содержимое активного окна браузера виртуального десктопа и перенаправляет его в браузер клиентской машины.

Это позволяет сбалансировать нагрузку на серверную инфраструктуру и не зависеть от контента, с которым работают в браузерах пользователи виртуальных ПК.

4. Обновления Horizon GPO Bundle.

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

• Файл шаблона VMware Horizon Client Drive Redirection ADMX (vdm_agent_cdr.admx) содержит следюущие новые настройки:
  • Настройка режима маппинга диска в гостевую ОС.
  • Настройка буквы диска при маппинге.
• Файл шаблона VMware View Agent Configuration ADMX (vdm_agent.admx) содержит следюущие новые настройки:
  • Disconnect Session Time Limit (VDI).
  • Включение режима automatic fallback после нарушения правила вайтлиста.
  • Включение Navigation URL list для VMware Browser Redirection
  • Включение VMware Browser Redirection
  • Включение списка URL list для VMware Browser Redirection
  • Idle Time Until Disconnect (VDI)
  • Показ страницы с информацией об ошибке перед началом automatic fallback.
• Файл шаблона Scanner Redirection ADMX (vdm_agent_scanner.admx) содержит следюущие новые настройки:
  • Принудительный показ диалога TWAIN Scanning Properties.
  • Размещение диалога TWAIN Scanner Properties.
• Файл шаблона VMware Horizon Client Configuration ADMX (vdm_client.admx) содержит следюущие новые настройки:
  • Позволить соединениям Blast использовать настройки прокси операционной системы.
  • Автоматическая синхронизация блока клавиш скролла и caps lock.
  • Включить кэш для функции browser redirection.
  • Включить WebRTC камеру и микрофон для функции browser redirection.
  • Горячие клавиши для получения и отдачи фокуса ввода.
  • Игнорирование ошибок сертификатов для функции browser redirection.

Помимо этого, много всего нового появилось в клиентах VMware Horizon Client версии 5.2, а также продуктах Dynamic Environment Manager 9.9 и App Volumes 2.18, но об этом мы расскажем завтра.

VMware Horizon 7.10 уже доступен для скачивания по этой ссылке.

Перед проходившей недавно конференцией VMworld 2019 компания VMware объявила об обновлении платформы VMware HCX Enterprise, которая теперь позволяет проводить миграции с различных опремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud. Давайте посмотрим, как устроено это решение.

Ранее VMware HCX (расшифровывается как Hybrid Cloud Extension) мог сопровождать процессы миграции виртуальных машин vSphere из локального датацентра в облачную инфраструктуру сервис-провайдеров VCPP или публичных облаков, но теперь это гораздо более функциональное средство - для миграции поддерживаются гипервизоры RedHat OpenStack/KVM и Microsoft Hyper-V. Для этого есть специальные дата муверы, которые обеспечивают процесс, называемый OS Assisted Migration (OSAM).

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

VMware HCX работает с vSphere 5.5 и более поздними версиями, а также гипервизорами KVM и Hyper-V, чтобы создать единую среду между онпремизным датацентром и облачным на основе архитектуры VMware Cloud Foundation (VCF), где работают средства по обеспечению катастрофоустойчивости рабочих нагрузок VMware Site Recovery Manager. Кстати, самыми крупными партнерами VMware в рамках программы VCPP являются IBM, OVH и Centurylink, а поддерживаемыми публичными облаками - AWS, Azure и GCP.

VMware HCX может быть первым шагом для крупных компаний в плане начала создания гибридной инфраструктуры, которая использует ресурсы нескольких облаков (то, что на картинке выше обозначено как v5). Ведь уже сейчас пользователи испытывают потребность облачных ресурсах больших публичных облаков, а также сторонних специализированных облаках, таких как Telco Clouds (на базе решений SDN / NFV).

HCX предоставляет возможность миграции виртуальных машин и приложений между различными видами облаков по принципу Any2Any. С точки зрения виртуальной машины, ее ОС и приложений, HCX выступает уровнем абстракции, который представляет машине единую гибридную среду в которой находятся все локальные и облачные ресурсы (infrastructure hybridity). Это дает возможность машинам перемещаться между датацентрами, не требуя реконфигурации самих ВМ или инфраструктуры.

Решение HCX представлено двумя компонентами:

• HCX Cloud (Target) – это машина HCX Management, которая развернута, например, в облаке VMC on AWS SDDC.
• HCX Enterprise (Source) – это ВМ, которая развертывается в онпремизном датацентре клиента.

Если вы пользуетесь услугами облака VMware vCloud on AWS, то HCX Cloud у вас готов к использованию (надо только нажать кнопку Deploy в консоли VMC). После этого вы сможете использовать HCX cloud web console, где можно скачать готовый виртуальный модуль HCX Enterprise OVA для использования уже в онпремизном датацентре. После создания конфигурации из локальной и облачных сред между ними автоматически настраивается IPsec VPN.

После этого вы сможете управлять гибридной средой с помощью HCX Manager:

HCX Enterprise в онпремизном датацентре отвечает за выполнение следующих задач:

• Создание интегрированной среды управления vCenter между облаком и онпремизным датацентром.
• Соединение площадок в единое облако HCX Cloud.
• Развертывание дополнительных компонентов (сервисных виртуальных модулей). Эти компоненты автоматически развертываются и в облаке AWS одновременно с онпремизными:
  • HCX WAN Interconnect - проводит миграцию vMotion между площадками через интернет или выделенные линии. Он также отвечает за обеспечение безопасности и шифрования. С точки зрения vCenter, это выглядит как фейковый ESXi-хост на обеих площадках, действующий как прокси для миграции ВМ между сайтами.
  • HCX WAN Optimization - отвечает за оптимизацию канала средствами дедупликации и компрессии трафика.
  • HCX Network Extension - реализует расширение L2-адресации на единое пространство с облаком, чтобы машины при миграции не требовали перенастройки MAC и IP-адресов.
• Предоставление Restful API и HCX API (к документации можно получить доступ по адресу https://<HCX Enterprise>/hybridity/docs).

На стороне публичного облака, например, vCloud on AWS, это выглядит несколько более сложно (там задействуется решение VMware NSX для обеспечения сетевой инфраструктуры), но компоненты те же:

Для инфраструктуры на базе VCPP (например, в облаке IBM) все выглядит проще (но там несколько меньше возможностей для конфигурации сетевого стека):

Помимо перечисленных основных 3 компонентов, HCX реализует еще несколько полезных сервисов, таких как пакетная миграция ВМ, средства катастрофоустойчивости (Disaster Recovery), возможности миграции с других гипервизоров (OS Assisted Migration) и прочее:

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

• VMware HCX Bulk Migration - этот метод использует средства VMware vSphere Replication для массового перемещения виртуальных машин на удаленную площадку. Потом происходит переключение обслуживания на реплики, что эквивалентно простою сервиса на период перезагрузки ВМ.
• VMware HCX vMotion - здесь применяются обычные средства vMotion для перемещения ВМ (1 машина в один момент времени, без перерыва в обслуживании).
• VMware HCX Cold Migration - это миграция остановленной машины с источника на таргет, с максимальными гарантиями сохранности данных, но простоем сервиса.
• VMware HCX Replication Assisted vMotion (RAV) - эта техника совмещает в себе преимущества HCX Bulk Migration (параллелизм операций и возможность запланированного запуска) с HCX vMotion (без прерывания сервиса). Это новый режим, появившийся в августе этого года.
• VMware HCX OS Assisted Migration - это миграция виртуальных машин с не-vSphere гипервизоров на онпремизную или облачную инфраструктуру vSphere (также новая функция HCX Enteprise).

Для мониторинга решения HCX можно использовать специальный пакет vRealize Operations Management Pack for HCX, который предоставляет интегрированные дэшборды и отчеты, а также дает всю необходимую информацию о возникающих проблемах.

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

Оригинал статьи на английском языке в блоге StarWind Software.

Продолжаем рассказывать (пока еще есть что!) о новых продуктах и технологиях, анонсированных на конференции VMworld 2019, которая закончилась уже почти 3 недели назад. Одна из самых интересных и перспективных технологий - это, конечно же, техника VMware Cluster Memory, которая действительно может поменять архитектуру датацентров в будущем.

Об этой технологии хорошо написал Дункан Эппинг. Как известно некоторым из вас, еще 20 лет назад скорость доступа к оперативной памяти серверов была примерно в 1000 раз выше, чем доступ к данным другого хоста по локальной сети. Шли годы, сетевой стек и оборудование улучшались - и в итоге на сегодняшний день доступ по сети всего в 10 раз медленнее, чем локальный доступ к RAM. Достигается это различными способами, в том числе технологией удалённого прямого доступа к памяти (remote direct memory access, RDMA).

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

Поэтому VMware в рамках сессии VMworld "Big Memory with VMware Cluster Memory" рассказала о том, как можно строить кластеры с помощью так называемых "серверов памяти", которые обеспечивают работу хостов ESXi и их виртуальных машин, которым нужно дополнительное пространство памяти по требованию.

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

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

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

Если страницы долгое время остаются невостребованными - они перемещаются обратно на Memory Server. По-сути, эта технология представляет собой оптимизацию механизма паджинации. В то же время, здесь пока существуют следующие проблемы:

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

В рамках демо на VMworld 2019 была показана технология Cluster Memory в действии для виртуальной машины, использующей 3 ГБ такой памяти.

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

Обратите внимание, и это здесь четко видно, что Cluster Memory всегда работает быстрее, чем локальный SSD-Swap. Второй важный момент тут, что даже при 70% использовании удаленной памяти виртуальная машина, с точки зрения производительности, чувствует себя вполне хорошо.

Понятно, что технология VMware Cluster Memory еще дело будущего, но пока вы можете посмотреть интересную запись упомянутой сессии на VMworld.

Расскажем еще немного о новостях с VMworld 2019, хотя наша серия получается несколько длинновата. Но обо всем образовательном и бесплатном грех не рассказать. Компания VMware объявила о доступности ресурса Kubernetes Academy, где ИТ-профессионалы, занимающиеся развертыванием и администрированием контейнеризованных приложений, могут узнать о том, как это делать в рамках интегрированной виртуальной инфраструктуры VMware vSphere и дополнительных средств управления единой средой виртуальных машин и контейнеров.

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

Бесплатные курсы Kubernetes Academy состоят из серии видеоуроков, которые длятся 5-7 минут и дают возможность усвоить какой-то законченный блок материала. Это позволяет администраторам лучше планировать свое время для прохождения курсов. Курсы разделены по уровням сложности от beginner до intermediate, скоро появится и уровень advanced.

Сейчас доступны следующие курсы:

• Containers 101 - дает базовые знания о контейнерах приложений.
• Kubernetes 101 - этот курс рассказывает об оркестрации контейнеров с помощью инструментов Kubernetes.
• Kubernetes in Depth - здесь уже раскрываются дополнительные моменты, например, архитектура платформы, типы объектов и т.п.
• Interacting with Kubernetes - здесь уже раскрываются практические аспекты работы с кластерами Kubernetes в рамках использования средств kubectl и ingress.
• How to Prepare for the CKA Exam - тут обсуждают практические моменты для подготовки к сдаче экзаменов на сертификаты CKA и CKAD. Здесь также полезно будет узнать об основных ресурсах и документах для подготовки, а также как формируются баллы при прохождении экзамена. Кроме того, в этом курсе вы научитесь работать с различными сложными операциями с Kubernetes в командной строке.

Добро пожаловать в VMware Kubernetes Academy.

Продолжаем рассказывать о новостях с конференции VMworld 2019. Еще одним небольшим, но важным анонсом стала публичная доступность облачного решения VMware Cloud on Dell EMC.

Работа над этим решением велась еще в 2018 году. Тогда был такой проект Dimension, представленный на VMworld 2018 в США. Он представлял собой специальный сервис VMware по поставке, развертыванию, обслуживанию и сопровождению виртуальных датацентров.

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

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

• Dell EMC VxRail G1 E560F
• Intel Cascade Lake, 20 cores @ 2.5GHz
• 192 GB RAM
• 52 TB сырого хранилища

Со временем Dell EMC (а как вы помните, это родительская компания VMware) будет расширять доступный выбор вариантов комплектаций стоек.

В целом, архитектура VMware Cloud on Dell EMC дает следующие преимущества для клиентов:

• Если у вас есть потребность в небольшой инфраструктуре, которую никто не обслуживает на постоянной основе, то это - отличный вариант, так как по всем программным и аппаратным вопросам единой точкой входа будут компании EMC/VMware, специалисты которых будут решать все возникающие проблемы с железом и софтом в рамках одного контракта.
• Все ресурсы инфраструктуры в географически распределенных датацентрах будут объединяться и управляться из одной консоли VMware Cloud Console.

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

Больше о решении можно узнать из следующих сессий VMworld 2019:

• Spotlight Keynote (EIOT2750BU) – Extend your hybrid cloud strategy to the Edge
• Business 100 (HBI2748BU) – Driving business benefits through Hybrid cloud IT outcomes
• Business 100 (HCI2560BU) – A new model for IaaS: shifting SLAs to VMware with VMware Cloud on Dell EMC
• Business 100 (HBI2293BU) – Build a killer application with VMC on Dell EMC
• Technical 100 (HBI1428BU) – VMC on Dell EMC technical overview
• Business 100 (HBI2367BU) – Empower the future of modern application with VMC on Dell EMC with a beta customer joining the discussion
• Technical 200 (HBI1975BU) – VMC on Dell EMC technical deep dive
• Technical 200 (HBI1980BU) – Customer experience, architectures, service benefits

Главная страница платформы VMware Cloud on Dell EMC находится вот тут.

Продолжаем рассказывать об анонсах продуктов и технологий, представленных на конференции VMworld 2019, так как есть о чем еще говорить. Одним из главных анонсов для сервис-провайдеров на мероприятии стала доступность платформы VMware Cloud Foundation for Cloud Providers.

Напомним, что vCloud Foundation (VCF) - это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить. Важно, что в рамках этой архитектуры полностью поддерживается взаимодействие всех компонентов друг с другом, поэтому для VCF есть список продуктов и их версий (и это могут быть не самые последние версии), который и составляет архитектуру VCF. Напомним, что о версии VCF 3.0 мы писали вот тут.

Представленная архитектура VCF для сервис-провайдеров (VCPP) позиционируется как главный продукт для построения выделенных облачных инфраструктур для крупных клиентов (Dedicated Private Clouds). Решение комбинирует в себе возможности платформ VMware Software-Defined (vSphere и прочие продукты) и решения для миграции в виртуальную среду HCX. Облачная платформа VCF поставляется в трех изданиях, в зависимости от изданий входящих в него продуктов (подробнее об этом тут):

VMware Cloud Foundation соединяет в себе портфолио SDDC (vSphere, NSX, vSAN), а также средства управления SDDC Manager, что позволяет создать валидированную архитектуру на стороне сервис-провайдера и обеспечить управление жизненным циклом всех компонентов, чтобы облачные провайдеры могли запускать апгрейд всей инфраструктуры в один клик.

Кстати, решение VCF можно потестировать вживую в рамках лабораторной работы Hands-on Lab.

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

Надо сказать, что решение VCF может работать поверх гибридной инфраструктуры предприятия - просто в облаке сервис-провайдера появляется еще один объединяющий элемент. Для традиционных хостинг-провайдеров, которые предоставляют услуги Shared Hosting / Virtual Private Servers, решение VCF для VCPP позволит получить крупных заказчиков, при этом оно изначально заточено под выделенную инфраструктуру со множеством клиентов.

Для старта с решением VMware Cloud Foundation for Cloud Providers партнерам потребуется пройти специальное обучение в течение 1 недели.

Вторым важным анонсом стал выпуск архитектуры vCloud Foundation версии 3.8.1. Надо сказать, что этот релиз сфокусирован на инфраструктуре контейнеризованных приложений под управлением Kubernetes. Такая инфраструктура управляется совершенно иначе, по сравнению с традиционной платформой для виртуальных машин, поэтому целью было объединить рабочие процессы PKS (Pivotal Container Service) и VCF.

В этом релизе у VCF 3.8.1 появились следующие новые возможности:

• Автоматизация развертывания решения PKS - теперь можно автоматически разместить нагрузку VMware Enterprise PKS в домене рабочей нагрузки NSX-T.

Средства интеграции VCF и PKS построены таким образом, что администраторам облака не требуется никаких специальных знаний в области Kubernetes, чтобы управлять интегрированной инфраструктурой контейнеров и виртуальных машин. Подробнее об этом рассказано тут.

• Поддержка двухфакторной аутентификации - теперь она доступна для API на базе паролей в консоли SDDC Manager.
• Улучшенные возможности Phone Home - предоставляет возможность провайдеру организовать функции phone home для данных в SDDC Manager одним кликом.
• Обновленные списки версий ПО (Bill of materials, BOM) - включают в себя vSphere 6.7 Update 3, vSAN 6.7 U3, новые версии Horizon, NSX-T и vRealize.

• Улучшения безопасности и исправления ошибок.

Более подробно о новых возможностях VCF можно узнать из Release Notes.

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

На днях на сайте VMware Labs эта утилита была обновлена до версии 2.2. Давайте посмотрим, что там появилось нового:

• Возможность игнорировать Extra AppStacks на Primary и Secondary серверах - это могло приводить к вылету утилиты.
• Возможность экспорта назначения прав для основного и резервного серверов в формат XML.
• Пофикшены ошибки с отсутствующими назначениями прав на стороне источника App Stack. Если права не назначены, то отображается лейбл "No Entitlements".

Скачать App Volumes Entitlement Sync версии 2.2 можно по этой ссылке.

Некоторые из вас знают, что у VMware есть решение для организации доступа конечных пользователей к ресурсам виртуальной инфраструктуры Workspace ONE. Одним из компонентов этого решения является средство Workspace ONE Access (бывший продукт VMware Identity Manager), позволяющее организовать идентификацию и авторизацию пользователей и их устройств в инфраструктурах vSphere и Horizon.

В мае 2018 компании VMware и Octa анонсировали партнерство в области создания единой инфраструктуры по управлению интегрированной аутентификацией и авторизацией пользователей и их устройств (Unified Endpoint Management). Ну а на VMworld 2019 было рассказано о прогрессе в развитии совместных инициатив обеих компаний.

Цель сотрудничества компаний VMware и Okta - создать единую среду универсального SSO-доступа для мобильных устройств и установить доверие к ним для различных платформ на уровне виртуального датацентра.

VMware приносит здесь экспертизу по управлению мобильными устройствами и комплаенса в контексте самих устройств (на базе решений купленной когда-то компании AirWatch), а Octa берет на себя контекст управления идентификацией на уровне пользователя и SSO-интеграцию с различными системами датацентра.

Вторая важная вещь, анонсированная на VMworld 2019 - это интеграции VMware и Octa при работе со службами каталога. Теперь решение Okta Integration Network может быть добавлено в Workspace ONE Intelligent Hub, чтобы создать единую точку управления идентификацией для всех приложений и платформ.

Также функционал для работы с восстановлением идентификации без пароля (повторная авторизация с мобильного) был перенесен со стороны Octa на Workspace ONE во избежание дублирования функционала.

Помимо этого, был убран следующий дублирующийся функционал за счет его перенесения в среду Octa: мобильный SSO и политики доверия на уровне устройств (device trust policies). Теперь пользователи и назначения им прав на ресурсы централизованы в консоли Okta (только те юзеры, которые используют Octa и VMware одновременно). Там же сосредоточены политики и действия (actions).

Еще одна возможность, анонсированная на VMworld - это Workspace ONE Okta Universal Directory Integration. Теперь пользователи получат интеграцию между Workspace ONE Access (бывший VMware Identity Manager) и Okta Universal Directory (UD). Функции UD теперь позволяют могут использовать в качестве источника идентификации не только службы каталога Active Directory, но и любые другие службы, такие как HR-системы со списками сотрудников.

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

Теперь такие пользователи являются полноценными участниками экосистемы VMware Workspace ONE, а также защищаются в рамках концепции VMware Zero Trust.

UD и Workspace ONE Access коммуницируют за счет SCIM-интеграции, а пользовательская информация передается в Workspace ONE UEM через специальный UEM API.

Кстати, об этих всех моментах написала не только VMware, на и сама Octa.

Продолжаем рассказывать о новостях конференции VMworld 2019, которая прошла в конце августа в Сан-Франциско. Среди анонсов новых версий продуктов и технологий, компания VMware рассказала о скором выпуске продукта vRealize Suite Lifecycle Manager 8.0 (vRSLCM), предназначенного для обслуживания жизненного цикла компонентов продуктовой линейки vRealize Suite. Напомним, что в апреле этого года мы писали о версии vRSLCM 2.1, теперь же версия продукта была приведена в соответствие с версией vRealize Automation 8.0.

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

1. Обновленный интерфейс.

Теперь главный и остальные дэшборды выглядят поприятнее:

2. Переработанное представление Lifecycle Management.

Теперь на этой странице представлены быстрые действия, последние сделанные запросы и нарисована красивая карта ваших датацентров:

3. Измененная процедура установки.

Теперь, чтобы развернуть vRealize Automation (vRA), вам предварительно потребуется установить Lifecycle Manager. Это позволит упростить процесс развертывания vRA (для этого есть Easy Installer) и выбрать конфигурацию HA для узлов, если требуется. Также перед установкой vRA потребуется развернуть и Workspace ONE Access (ранее он назывался VMware Identity Manager), который поддерживает все продукты пакета vRealize Suite в рамках единого рабочего процесса управления идентификацией пользователей.

4. Функция Locker для управления сертификатами.

Теперь на главном дэшборде vRSLCM есть иконка Locker, при клике на которую откроется функциональность управления сертификатами. Отсюда же можно управлять лицензиями и паролями:

5. Улучшенный интерфейс для Directory Management.

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

О доступности для загрузки vRealize Suite Lifecycle Manager 8.0 будет объявлено в этом году.

Давно компания VMware не обновляла на VMware Labs решение VMware vSphere HTML5 Web Client, которое по-сути и есть vSphere Client, включаемый в дистрибутивы VMware vSphere как основное и (теперь уже) единственное средство для управления виртуальной инфраструктурой.

Напомним, что именно как Fling клиент vSphere Client обновлялся довольно давно (о версии 4.1 мы писали вот тут, потом была еще версия 4.2). И вот на днях был выпущен vSphere HTML5 Web Client версии 4.3.

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

• Возможность кастомизировать цвет в заголовке окна клиента, чтобы отличать серверы vCenter. Для задания конкретного цвета конкретному vCenter идите в Administration -> System Configuration и выберите сервер, для которого нужно изменить цвет.
• Пофикшены проблемы с заливкой OVF-шаблона в библиотеку Content Library.
• Были убраны функции vSphere Perspective Management, которые появились ранее в версии 4.2. Они позволяли администратору контролировать области интерфейса, которые могли видеть другие пользователи VMware vSphere. Демо этой технологии можно посмотреть тут. Но, похоже, либо эта функциональность не зашла, либо ее отозвали на доработку и пока исключили из состава клиента.

Также в версии vSphere Client 4.2 были добавлены следующие полезные возможности:

• Режим Code Capture может захватывать и записывать операции с объектами Content Libraries.
• Code Capture может генерировать сценарии на других языках, в частности Python и vRO (vRealize Orchestrator) Javascript.

Скачать vSphere HTML5 Web Client 4.3 можно по этой ссылке.

На конференции VMworld 2019, которая недавно прошла в Сан-Франциско, было представлено так много новых анонсов продуктов и технологий, что мы не успеваем обо всех рассказывать. Одной из самых интересных новостей стала информация про новую версию распределенного планировщика ресурсов VMware Distributed Resource Scheduler (DRS) 2.0. Об этом было рассказано в рамках сессии "Extreme Performance Series: DRS 2.0 Performance Deep Dive (HBI2880BU)", а также про это вот тут написал Дункан Эппинг.

Надо сказать, что технология DRS, позволяющая разумно назначать хосты ESXi для виртуальных машин и балансировать нагрузку за счет миграций ВМ посредством vMotion между серверами, была представлена еще в 2006 году. Работает она без кардинальных изменений и по сей день (13 лет!), а значит это очень востребованная и надежная штука. Но все надо когда-то менять, поэтому скоро появится и DRS 2.0.

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

Сейчас технология DRS 2.0 находится в статусе Technical Preview, что значит, что никто не гарантирует ее присутствие именно в таком виде в будущих продуктах VMware, кроме того нет и никаких обещаний по срокам.

В целом, изменилось 3 основных момента:

• Появилась новая модель затраты-преимущества (cost-benefit model)
• Добавлена поддержка новых ресурсов и устройств
• Все стало работать быстрее, а инфраструктура стала масштабируемее

Давайте посмотрим на самое интересное - cost-benefit model. Она вводит понятие "счастья виртуальной машины" (VM Happiness) - это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness.

VM Happiness будет основным KPI, которым будет руководствоваться DRS 2.0 при проведении миграций (то есть цель - улучшить этот показатель). Также эту оценку можно будет увидеть и в интерфейсе. Помимо этого, можно будет отслеживать этот агрегированный показатель и на уровне всего кластера VMware HA / DRS.

Второй важный момент - DRS 2.0 будет срабатывать каждую минуту, а не каждые 5 минут, как это происходит сейчас. Улучшение связано с тем, что раньше надо было снимать "снапшот кластера", чтобы вырабатывать рекомендации по перемещению виртуальных машин, а сейчас сделан простой и эффективный механизм - VM Happiness.

Отсюда вытекает еще одна полезная функциональность - возможность изменять интервал опроса счастливости виртуальных машин - для стабильных нагрузок это может быть, например, 40-60 минут, а для более непредсказуемых - 15-20 или даже 5.

Еще одна интересная фича - возможность проводить сетевую балансировку нагрузки при перемещении машин между хостами (Network Load Balancing). Да, это было доступно и раньше, что было вторичной метрикой при принятии решений о миграции посредством DRS (например, если с ресурсами CPU и памяти было все в порядке, то сетевая нагрузка не учитывалась). Теперь же это полноценный фактор при принятии самостоятельного решения для балансировки.

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

Модель cost-benefit также включает в себя возможности Network Load Balancing и устройства PMEM. Также DRS 2.0 будет учитывать и особенности аппаратного обеспечения, например, устройства vGPU. Кстати, надо сказать, что DRS 2 будет также принимать во внимание и характер нагрузки внутри ВМ (стабильна/нестабильна), чтобы предотвратить "пинг-понг" виртуальных машин между хостами ESXi. Кстати, для обработки таких ситуаций будет использоваться подход "1 пара хостов source-destination = 1 рекомендация по миграции".

Также мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (memory overcommit), поэтому вместо "active memory" DRS 2.0 будет использовать параметр "granted memory".

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

• Level 1 – балансировка не работает, происходит только выравнивание нагрузки в моменты, когда произошло нарушение правил DRS.
• Level 2 – работает для очень стабильных нагрузок.
• Level 3 – работает для стабильных нагрузок, но сфокусирован на метрике VM happiness (включено по умолчанию).
• Level 4 – нагрузки со всплесками (Bursty workloads).
• Level 5 – динамические (Dynamic) нагрузки с постоянными изменениями.

В среднем же, DRS 2.0 обгоняет свою первую версию на 5-10% по быстродействию, что весьма существенно при больших объемах миграций. При этом VMware понимает, что новый механизм DRS второй версии может родить новые проблемы, поэтому в любой момент можно будет вернуться к старому алгоритму балансировки с помощью расширенного параметра кластера FastLoadBalance=0.

По срокам доступности технологии DRS 2.0 информации пока нет, но, оказывается, что эта технология уже почти год работает в облаке VMware Cloud on AWS - и пока не вызывала нареканий у пользователей. Будем следить за развитием событий.