Часто при миграциях 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 - и пока не вызывала нареканий у пользователей. Будем следить за развитием событий.

В рамках серии анонсов, представленных на прошедшей конференции VMworld 2019, компания VMware представила интересное средство, которое может оказаться полезным администраторам виртуальной инфраструктуры - vSphere Assessment Tool (vSAT).

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

Утилита vSAT реализована двумя компонентами:

• Десктопный клиент, который связывается с сервером vCenter и организует передачу данных.
• Онлайн-портал vSphere Assessment Portal, обрабатывающий ваши данный и визуализующий результаты.

Для начала работы просто нажимаете Get Started на первой странице портала:

Десктопный клиент поддерживает ОС Windows, OS X и Linux. В клиенте вы просто добавляете сервер vCenter, который нужно проанализировать. Для этого либо потребуется использовать административный аккаунт, либо создать пользователя с кастомной ролью с привилегиями "Host Settings".

После того, как в вашей инфраструктуре завершен сбор данных, есть 2 способа отправить их в облако:

• Онлайн-отправка на vSphere Assessment portal с использованием vSAT passcode (чтобы его получить, можно использовать опцию клиента "Forgot Your vSAT passcode?").

Также Passcode можно получить из меню аккаунта на vSAT Portal:

• Офлайн-отправка путем скачивания данных в файл и их последующая загрузка на портал в ручном режиме:

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

В представлении Summary вы найдете список всех версий vSphere, на которые вы можете выполнить миграцию, а также узнать, какие хосты ESXi рискуют оказаться в неподдерживаемой конфигурации. При клике на хост ESXi возникает панель host details, где можно увидеть текущую версию vSphere, модель сервера, сетевые адаптеры и контроллеры хранилищ. Для каждого компонента верифицируется поддержка соответствующей версией vSphere.

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

Пользуйтесь!

В рамках прошедшей конференции VMworld 2019 компания VMware сделала немало интересных анонсов. Для крупных компаний одним из главных анонсов стало, конечно же, объявление о выпуске мажорной версии продукта vRealize Automation 8. Напомним, что это средство позволяет автоматизировать большинство рутинных операций в облаке на базе VMware vSphere (то, что раньше делалось только с помощью Orchestrator). В прошлый раз мы писали о выпуске версии vRealize Automation 7.6 весной этого года.

Напомним, что решение vRealize Automation является онпремизным продуктом, но если вы хотите использовать его в облаке (например, VMware vCloud on AWS), то есть аналогичный SaaS-сервис, который называется VMware vRealize Automation Cloud (бывший Cloud Automation Services), который состоит из компонентов Cloud Assembly, Service Broker и Code Stream, которые есть и в онпремизном vRealize Automation.

vRealize Automation 8 теперь построен на базе популярной сейчас микросервисной архитектуре на базе контейнеров. Прошлая версия vRA была построена на базе виртуальных машин Windows Server (требовалось как минимум две ВМ), теперь же все реализовано на базе контейнеров внутри одной ВМ, что дает гибкость развертывания и простоту масштабирования.

Таким образом, процесс установки и конфигурации стал проще, мастера настройки дают возможность начать использование продукта уже через час после запуска. Установщик поставляется как ISO-файл и может быть развернут в Windows, Linux, or MacOS. Встроенный маркетплейс включает различные сэмплы ОС, приложений, блупринты и образы, чтобы быстро развернуть инфраструктуру vRA.

Помимо этого, вы сможете развернуть vRealize Lifecycle Manager, vRealize Automation и Workspace ONE Access (бывший VMware Identity Manager) в рамках единого процесса (либо можно использовать эти существующие компоненты, если они были установлены ранее, и подключить сервисы аутентификации).

Надо сказать, что теперь vRealize Automation 8 построен на базе нового HTML5-интерфейса на базе Clarity. Мощный API для развертывания и конфигурации расширяет возможности графического интерфейса. Существенно был доработан раздел блупринтов (Blueprints), где пользователь конструирует архитектуру будущей системы (ОС, приложения, сетевые ресурсы и т.п.).

Описательная часть блупринтов строится на базе языка разметки YAML, визуально можно также работать с блоками на рабочем поле. Блупринты поддерживают контроль версий и рабочий процесс Git. Более подробно об этом написано в статьях VMware Multi-cloud Management with vRealize Automation Cloud и  Introducing Blueprint Expressions in Cloud Assembly.

Также одно из нововведений vRealize 8 - это поддержка облачных платформ VMware Cloud on AWS, Amazon Web Services, Microsoft Azure и Google Cloud Platform. Для них можно создавать универсальные (не зависящие от конкретного облака) объекты Projects, Cloud Zones, Profiles и блупринты. Это дает большую гибкость в компаниях, которые используют гибридные облака, пользуясь услугами нескольких облачных провайдеров (подробнее тут).

vRealize Orchestrator, как главная часть vRealize Automation, теперь работает как сервис внутри виртуальной машины vRealize Automation VM и предоставляет полнуют интеграцию с Git, а работа происходит в HTML5-интерфейсе. Также в составе vRA появилась опция Action Based Extensibility (ABX), которая представляет собой альтернативу vRealize Orchestrator. С помощью ABX можно использовать сценарии Node.js или скрипты Python для обработки специфических триггеров. Более подробно про механизм ABX написано вот тут.

Окончательный релиз vRealize Automation 8 ожидается до 1 ноября этого года.

На прошедшей конференции VMworld 2019 компания VMware анонсировала новую (юбилейную) версию интегрированной платформы для сервис-провайдеров, предоставляющих виртуальные машины в аренду - VMware vCloud Director 10 (vCD). Напомним, что версия vCloud Director 9.5 была анонсирована ровно год назад на VMworld 2018, с тех пор был выпущен еще vCloud Director 9.7.

Daniel Paluszek сделал 2 интересных поста о новых возможностях VMware vCloud Director 10 (раз и два), основные моменты из которых мы приводим ниже.

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

Новый релиз vCD 10 сфокусирован на 3 основных аспектах:

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

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

1. Полный переход на интерфейс Clarity.

Теперь vCD 10 полностью работает на базе HTML5-фреймворка Clarity, который представляет интерфейс просто и четко, в рамках общей концепции остальных продуктов VMware (vSphere, Horizon, NSX).

Интерфейс Flex еще сохранился как резервный, но он будет отсутствовать в следующей версии, да и сейчас он остался лишь на всякий случай.

2. Переработаны мастера создания новых объектов.

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

Создание пула выглядит понятнее:

В менюшке есть удобная справка по ресурсам как для самого vCD, так и для платформы vSphere:

3. Поддержка VMware NSX-T.

Новый релиз vCD 10 сфокусирован на создании функциональных сетевых сервисов в среде NSX-T. Пока работа еще не закончена (как это было сделано с NSX-V), но движение вперед уже есть.

Creation Workflow теперь выглядит проще и понятнее:

При добавлении нового oVDC мы можем видеть наш NSX-T Overlay pool:

Для NSX-T доступны следующие функции...Читать статью далее->>

Перед самой конференцией VMworld 2019, которая прошла на прошлой неделе в Сан-Франциско, компания VMware анонсировала полезный сервис ports.vmware.com, где любой желающий может вывести порты и соединения по различным протоколам для следующих продуктов серверной линейки:

• vSphere
• vSAN
• NSX for vSphere
• vRealize Network Insight
• vRealize Operations Manager
• vRealize Automation

Выглядит это вот таким образом (кликабельно):

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

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

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

В общем, пользуемся - ports.vmware.com.

На прошедшей конференции VMworld 2019 было сделано немало интересных анонсов (о самых интересных из них мы рассказываем тут), один из них - это определенно технологическое превью Project Magna (год назад мы рассказывали о начале разработки этого продукта). Это облачное решение VMware, которое предназначено для постоянной непрерывной оптимизации инфраструктуры отказоустойчивых хранилищ VMware vSAN.

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

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

В качестве ML-алгоритма используется так называемый Reinforcement Learning, который анализирует заданные вами KPI по производительности и сравнивает их с аналогичными конфигурациями для похожих нагрузок. Этот алгоритм постоянно проверяет тысячи различных сценариев конфигурации, чтобы найти оптимальный именно для вашей инфраструктуры. Само испытание производится методом проб и ошибок:

Также продукт vRealize Operations можно будет интегрировать с Project Magna таким образом, чтобы первый мог получить от последнего нужные конфигурации, а пользователь может поставить настройку селф-тюнинга, которая будет следовать заданной вами цели.

Цели (KPI) могу быть заданы в виде следующих вариантов:

• Read Performance - все настраивается для наименьших задержек на чтение (latency), увеличения пропускной способности (максимум для этого будет использоваться до 10% памяти хоста).
• Write Performance - конфигурация стремится уменьшить задержки и увеличить производительность на запись (пренебрегая скоростью чтения).
• Balanced - оптимизация сбалансированного режима чтения-записи, в зависимости от требований рабочей нагрузки.

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

Например, на этом скриншоте мы видим, что Magna увеличила размер кэша на чтение до 50 ГБ 23 июля - и это благотворно повлияло на performance index.

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

• HCI1620BU – Artificial Intelligence and Machine Learning for Hyperconverged Infrastructure
• MLA2021BU – Realize your Self-Aware Hybrid Cloud with Machine Learning
• HCI1650BU – Optimize vSAN performance using vRealize Operations and Reinforcement Learning

Доступность Project Magna ожидается в следующем году.

Конференция VMworld 2019 уже заканчивается, а мы продолжаем публиковать главные новости о виртуализации этого года. Один из важных анонсов - это объявление о выпуске новых версий VMware Workstation 15.5 и Fusion 11.5, которые выйдут уже в сентябре. Напомним, что прошлые версии Workstation 15 и Fusion 11 вышли год назад.

Давайте посмотрим, что нового появилось в Workstation 15.5 и Fusion 11.5.

Общие нововведения для обеих платформ:

• Улучшения Jumbo Frames - теперь можно настраивать размер MTU-пакета для виртуальных сетей (доступно только в Pro-версиях платформ).
• Поддержка нового устройства pvscsi - теперь виртуальные машины полностью совместимы с платформой vSphere в этом плане.
• Поддержка новых ОС - Windows 10 19H2, Ubuntu 1910, Debian 10.0 и RHEL 7.7.
• Поддержка локальных кластеров Kubernetes - теперь это можно сделать через minikube и docker-machine-driver-vmware.
• Улучшения производительности и фиксы подсистемы безопасности.

Нововведения VMware Worlstation 15.5:

• Сохранение сетевой конфигурации - при апгрейде Workstation на новую версию у вас сохраняются все кастомные сетевые настройки.
• Экспорт сложной сетевой конфигурации - теперь это можно сделать через обычный текстовый файл.
• Быстрые клавиши для конфигурации с несколькими мониторами - теперь с помощью комбинации ctrl+shift+m можно быстро выбрать приоритет показа виртуальных дисплеев.

Нововведения VMware Fusion 11.5:

• Поддержка macOS 10.15 Catalina - эта ОС поддерживается и как хостовая, и как гостевая.
• Режимы Dark Mode и Dark Mode Sync - теперь Fusion переключается в ночной режим, когда Mac OS 10.14+ также переключается в него, эту настройку можно синхронизировать и с Windows 10.
• Sidecar (требует хост Catalina) - можно использовать Windows на вашем iPad c аппаратной клавиатурой и поддержкой Apple Pencil.

Ну и одна из главных новостей в тему - это сотрудничество VMware и Microsoft в плане поддержки VMware Workstation на серверах Hyper-V. Ранее это было невозможно ввиду наличия функций расширенной безопасности в платформе Hyper-V:

Теперь же платформа VMware Workstation будет работать на серверах с ролью Hyper-V благодаря сотрудничеству VMware и Microsoft. Пока ВМ на платформе Workstation на хосте Hyper-V работают медленно, но в следующем году обещают, что все будет близко к нативной производительности.

Официальный выпуск VMware Workstation 15.5 и Fusion 11.5 состоится в сентябре этого года.

Многие из вас следят за новостями и событиями конференции VMworld 2019, которая проходит в эти дни в Сан-Франциско. Одним из первых и важных анонсов конференции стало объявление о скором выпуске проекта VMware Tanzu. Те из вас, кто следит в последнее время за новыми релизами от VMware, знают, что компания выпускает очень много чего интересного для инфраструктуры контейнеризованных приложений Kubernetes.

Например, совсем недавно мы писали о новой подсистеме хранения для K8s - Cloud Native Storage (CNS), утилите для контроля и мониторинга состояния кластеров VMware Octant, а также средстве для управления инфраструктурой контейнеров приложений VMware Enterprise PKS 1.5 (Pivotal Container Service).

На данный момент свежепоявившееся семейство Tanzu представлено двумя продуктами:

• Project Pacific — набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes (будет доступно в следующих релизах vSphere).
• VMware Tanzu Mission Control - единая операционная консоль для кластеров Kubernetes, которая позволит контролировать все аспекты жизненного цикла приложений.

Project Pacific

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

Данный продукт будет решать следующие задачи:

• Использование vSphere для нативной среды Kubernetes
• Предоставление средств управления, сфокусированных на приложениях
• Возможность взаимодействия команд разработки и администрирования/оперирования

С помощью Pacific разработчики продолжат управлять приложениями посредством Kubernetes, но сами приложения за счет этого будут "комфортно себя чувствовать" на платформе ESXi. Администраторы же смогут выполнять рутинные задачи через средства управления VMware vCenter.

Так как подразумевается, что Kubernetes будет нативно работать в среде vSphere, то будет поддерживаться концепция пространств имен в рамках инфраструктуры vSphere. Пространства имен в K8s - это коллекции объектов (контейнеры, виртуальные машины, диски и т.п.).

На уровне пространств имен в среде K8s можно выполнять стандартные для vSphere операции, такие как контроль и выделение ресурсов, vMotion, шифрование, HA и снапшоты.

VMware Tanzu Mission Control

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

Платформа Tanzu Mission Control полностью построена на базе универсального API, который могут использовать разработчики для оперирования кластерами Kubernetes через Cluster API. Это касается всех рабочих процессов (например, создание или обновление кластера), а также аутентификации и прочих вспомогательных сервисов.

Сама консоль - это SaaS-решение, которое объединяет объекты разной природы в облачной консоли (например, это могут быть компоненты платформы vSphere, объекты из публичных облаков, средства OpenShift или просто самопальные инсталляции собственной архитектуры). Также вы можете привязать кластер VMware Essential PKS к консоли Tanzu Mission Control и использовать средства автоматизации обслуживания жизненного цикла кластеров, либо можно открыть и использовать расширенные средства сервисов PKS-кластера.

Консоль Mission Control использует:

• Cluster API для управления жизненным циклом (Lifecycle Management)
• Velero для резервного копирования и восстановления
• Sonobuoy для контроля конфигураций
• Contour для контроля компонентов ingress

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

Ну и одно из самых удобных для оператора - это федерация данных кластеров K8s из разных источников в единой консоли:

Более подробно о проекте Tanzu можно почитать в пресс-релизе VMware.

Пока мы готовим большие посты об анонсах проходящего в эти дни в Сан-Франциско VMworld 2019, расскажем о небольших обновлениях. На сайте проекта VMware Labs появился апдейт средства для управления инфраструктурой VMware vSphere с мобильного телефона - vSphere Mobile Client 1.3. Напомним, что о прошлой версии клиента Mobile Client 1.2 мы писали вот тут. Надо заметить, что обновляется он хорошими темпами.

Давайте посмотрим, что нового добавили в Mobile Client 1.3:

• Наконец-то появилось представление уровня хостов - Hosts View.
• Дэшборд vCenter теперь включает объекты с наибольшим числом сработавших алертов.
• Для iOS-клиента появилась функция сообщения о вылетах приложения (Crash reporting).
• Категории событий теперь видны в интерфейсе (что это - alarm, error или warning).
• Улучшена обработка получения имени сервера vCenter.

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

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

Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.

Год назад компания StarWind Software анонсировала собственный таргет и инициатор NVMe-oF для Hyper-V, с помощью которых можно организовать высокопроизводительный доступ к хранилищам на базе дисков NVMe (подключенных через шину PCI Express) из виртуальных машин. За прошедший год StarWind достаточно сильно улучшила и оптимизировала этот продукт и представила публично результаты его тестирования.

Для проведения теста в StarWind собрали стенд из 12 программно-апаратных модулей (Hyperconverged Appliances, HCA) на базе оборудования Intel, Mellanox и SuperMicro, составляющий высокопроизводительный вычислительный кластер и кластер хранилищ, где подсистема хранения реализована с помощью продукта Virtual SAN, а доступ к дискам происходит средствами инициатора NVMe-oF от StarWind. Между хостами был настроен 100 Гбит Ethernet, а диски SSD были на базе технологии NVMe (P4800X). Более подробно о конфигурации и сценарии тестирования с технологией NVMe-oF написано тут.

Аппаратная спецификация кластера выглядела так:

• Platform: Supermicro SuperServer 2029UZ-TR4+
• CPU: 2x Intel® Xeon® Platinum 8268 Processor 2.90 GHz. Intel® Turbo Boost ON, Intel® Hyper-Threading ON
• RAM: 96GB
• Boot Storage: 2x Intel® SSD D3-S4510 Series (240GB, M.2 80mm SATA 6Gb/s, 3D2, TLC)
• Storage Capacity: 2x Intel® Optane™ SSD DC P4800X Series (375GB, 1/2 Height PCIe x4, 3D XPoint™). The latest available firmware installed.
• RAW capacity: 9TB 
• Usable capacity: 8.38TB 
• Working set capacity: 4.08TB 
• Networking: 2x Mellanox ConnectX-5 MCX516A-CCAT 100GbE Dual-Port NIC
• Switch: 2x Mellanox SN2700 32 Spectrum ports 100GbE Ethernet Switch

Схема соединений тестового стенда:

Для оптимизации потока ввода-вывода и балансировки с точки зрения CPU использовался StarWind iSCSI Accelerator, для уменьшения latency применялся StarWind Loopback Accelerator (часть решения Virtual SAN), для синхронизации данных и метаданных - StarWind iSER initiator.

Как итог, ввод-вывод оптимизировался такими технологиями, как RDMA, DMA in loopback и TCP Acceleration.

С точки зрения размещения узлов NUMA было также сделано немало оптимизаций (кликните для увеличения):

Более подробно о механике самого теста, а также программных и аппаратных компонентах и технологиях, рассказано здесь. Сначала тест проводился на чистом HCA-кластере без кэширования.

Результаты для 4К Random reads были такими - 6,709,997 IOPS при теоретически достижимом значении 13,200,000 IOPS (подробнее вот в этом видео).

Далее результаты по IOPS были следующими:

• 90% random reads и 10% writes = 5,139,741 IOPS
• 70% random reads и 30% writes = 3,434,870 IOPS

Полная табличка выглядит так:

Потом на каждом хосте Hyper-V установили еще по 2 диска Optane NVMe SSD и запустили 100% random reads, что дало еще большую пропускную способность - 108.38 GBps (это 96% от теоретической в 112.5 GBps.

Для 100% sequential 2M block writes получили 100.29 GBps.

Полные результаты с учетом добавления двух дисков:

А потом на этой же конфигурации включили Write-Back cache на уровне дисков Intel Optane NVMe SSD для каждой из ВМ и для 100% reads получили 26,834,060 IOPS.

Полная таблица результатов со включенным кэшированием выглядит так:

Да-да, 26.8 миллионов IOPS в кластере из 12 хостов - это уже реальность (10 лет назад выжимали что-то около 1-2 миллионов в подобных тестах). Это, кстати, 101.5% от теоретического максимального значения в 26.4М IOPS (12 хостов, в каждом из которых 4 диска по 550 тысяч IOPS).

Для тестов, когда хранилища были презентованы посредством технологии NVMe-oF (Linux SPDK NVMe-oF Target + StarWind NVMe-oF Initiator), было получено значение 22,239,158 IOPS для 100% reads (что составляет 84% от теоретически расчетной производительности 26,400,000 IOPS). Более подробно об этом тестировании рассказано в отдельной статье.

Полные результаты этого теста:

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

Как вы знаете, недавно обновленная платформа виртуализации VMware vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.

Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

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

Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).

Архитектура CNS реализована двумя компонентами:

• Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
• Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.

Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.

Кстати, про оперирование CNS есть интересное видео от VMware:

Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.

До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.

Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.

Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.

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

Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.

Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.

Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.

Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:

Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.