VMworld 2016 Europe (день 3)

Отчет о третьем (последнем) дне VMworld 2016 Europe. Первая и вторая части.

Фотографии с мероприятия.

Сессии

Третий день на VMworld всегда проходит по укороченной программе. С одной стороны - конференция работает до 16 часов, с другой - за два дня все выматываются, и даже на партнерской выставке на тебя порой смотрят усталыми глазами: "-Про наше решение хочешь услышать? Вот тебе флешка, пользуйся на здоровье!" 

Первая сессия, которую я посетил (Simplifying Disaster Recovery in 2016 using VSAN, NSX and SRM [STO7802]) касалась синергетического эффекта, который можно получить при совместном использовании NSX, Virtual SAN и SRM при построении катастрофоустойчивых виртуальных инфраструктур.

Традиционные DR решения уже давно научились обеспечивать автоматическое восстановление в части вычислительных ресурсов (серверов), и даже на уровне СХД за счет механизма синхронизации/репликации данных все выглядит неплохо, но больным местом остается сеть. Без наличия растянутых L2 сетей или механизмов по переносу целого сегмента с перенастройкой маршрутизатора, восстановление оборачивается головной болью. А ведь еще надо обеспечить защиту на уровне брандмаэура и балансирование нагрузки восстановленных сервисов в резервном ЦОД.

Помочь в этом может VMware NSX. Начиная с версии 6.2, NSX поддерживает распределенную инсталляцию (Cross vCenter NSX), включающую до восьми серверов vCenter.

При этом появляется возможность использовать универсальные объекты - логические сети, распределенные маршрутизаторы, распределенный брандмауэр, группы безопасности, доступные в виртуальной инфраструктуре под управлением любого из серверов vCenter. Все это позволяет легко восстановить ВМ из основного ЦОД в резервный, сохраняя ее привязку к логической сети и правила фильтрации трафика.

При использовании распределенной инсталляции с использованием Cross vCenter NSX требуется определиться с тем, использовать функцию Local Egress для распределенных коммутаторов, или нет. Local Egress позволяет решить проблему Hairpinning, при которой ВМ, расположенные на одной площадке общаются с внешним миром через маршрутизаторы, расположенные на второй площадке, что приводит к дополнительной нагрузке на межсайтовое соединение. 

Что касается Virtual SAN, то он, в свою очередь, избавляет администратора от необходимости работы с LUN'ами СХД и хранилищами ВМ, заменяя это механизмом управления ресурсами хранения через политики (Storage Policies Based Management). Virtual SAN позволяет обеспечить высокий уровень доступности подсистемы хранения (до 99,9999% при использовании двойного зеркалирования данных, FTT=2), что обеспечивает RTO порядка 32 секунд в год при нулевом RPO. Для FTT=1, соответственно, 99,999% и 5 минут простоя в год.

Для Virtual SAN может быть обеспечен RPO в 5 минут при репликации средствами vSphere Replication (при репликации с других СХД RPO составляет 15 минут). Кроме того, для Virtual SAN поддерживается сценарий, при котором защита данных обеспечивается как средствами распределенного кластера (Virtual SAN Stretched Cluster), так и vSphere Replication в связке с SRM.

Также во время выступления упомянули о варианте развертывания двух распределенных кластеров Virtual SAN, узлы-свидетели которых располагаются друг на друге. Данное решение на текущий момент не поддерживается, но если очень хочется, то заказчик может обратиться в VMware, чтобы пройти процедуру RPQ (Request Product Qualification).

Заключительная сессия, на которой я побывал (An Overview of the vCenter Server Appliance Management Interface and API [INF9144]), касалась, по большей части, нововведений vCenter Server Appliance 6.5. Во-первых, в vCenter Server Appliance наконец-то интегрировали vSphere Update Manager. Больше не требуется разворачивать отдельный сервер на Windows для обновления хостов ESXi.

Во-вторых, это переработанный мастер установки, который теперь можно будет запускать не только под Windows, но также Linux и MAC OS. Через мастер установки также возможно перенести настройки с существующей инсталляции vCenter Server for Windows на апплайнс, при необходимости сохранив записи в журналах событий и счетчики производительности виртуальной инфраструктуры.

В-третьих, vCenter Appliance имеет встроенный механизм резервного копирования (Native Backup and Restore), который сохраняет все настройки и данные vCenter в виде единого архива на сервер про протоколу FTP(s) / HTTP(s) / SCP, который затем можно восстановить на чистый апплайнс. Размер такого бекапа существенно меньше бекапа всей ВМ vCenter целиком.

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

Существенной доработке подвергся vCenter Appliance Management User Interface (VAMI). Теперь в VAMI появился встроенный мониторинг состояния компонентов vCenter, уровня загрузки ресурсов и размер занятого дискового пространства. Таким образом, даже в случае недоступности служб vCenter Server возможно будет провести базовую диагностику, подключившись к VAMI.

Завершение

Подошел к концу еще один VMworld. Этот год принес приятный сюрприз в виде анонса новой версии vSphere и других продуктов. Часть нововведений, представленных VMware, вроде Cloud Foundation или vSphere Integrated Containers выглядят вполне понятно и логично, другие, вроде VMware Cloud on AWS, вызывают настороженно-оптимистический интерес, т.к. как можно увидеть, далеко не все инициативы, о которых рассказывают на VMworld, принимаются заказчиками (вспомнить хотя бы EVO:RAIL, EVO SDDC). Пожелаем же VMware успехов. До встречи в следующем году!