Сегодня Алексей Дарченков, специалист по гиперконвергентным систем и программно-определяемым системам компании VMware в России, проведет презентацию «VMware Cloud Foundation — флагманская платформа для построения инфраструктуры для традиционных и современных приложений», на которой он расскажет об архитектуре и возможностях флагманской платформы для построения программно-определяемого ЦОД от VMware.

Какие проблемы решает VMware Cloud Foundation? 

О чем сегодня просят администраторы инфраструктуры: чтобы все было сделано быстро, чтобы ничего не ломалось, все было дешево и безопасно. На предыдущем слайде отображены четыре проблемы, которые можно решить с помощью VMware Cloud Foundation. Это слишком долгое развертывание инфраструктуры и ее высокая сложность, которая начинается на стыке систем и отдельных продуктов системы. Цена: очень велики операционные затраты на поддержку сложной гетерогенной инфраструктуры, для этого нужно много разных отделов и специалистов. Что касается безопасности, то на базе VMware Cloud Foundation можно проще реализовать требования по безопасности.

Чтобы решить эти проблемы, надо построить свой программно-определяемый ЦОД. Можно взять инфраструктуру на платформе с основными продуктами VMware: vSphere в качестве гипервизора, vSan и NSX. Соответственно с помощью этих продуктов можно достаточно просто построить ликвидное облако для всех нагрузок.

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

Программно-определяемую инфраструктуру можно построить и самому, взяв для этого продукты VMware: vSphere - виртуализация вычислительных ресурсов, vSan - виртуализация СХД, NSX - виртуализация сети, vRealize – для создания полноценного частного облака и каталога сервисов и продукты семейства Tanzu для работы с контейнерами и другие продукты VMware.

К сожалению, не у всех получается самостоятельно построить инфраструктуру на продуктах этого вендора. Для помощи в этом VMware создал свод документов – VMware Validated Designs (VVDs), он есть в Интернете, его там можно прочитать. Этот свод иногда смотрят как энциклопедию, когда нужно принять то или иное решение. В результате вендор для автоматизации создал решение VMware Cloud Foundation, которое позволяет управлять жизненным циклом ПО и строить инфраструктуру правильно в соответствие с VMware Validated Designs. Что входит в VMware Validated Designs?

Это vSphere, vSan и NSX, SDDС Manager, который управляет жизненным циклом остальных инфраструктурных продуктов, все это делается из одной консоли. Также опционально можно использовать на VMware Cloud Foundation продукты для работы с современными приложениями семейства Tanzu, когда можно в Интернете запускать контейнеры и кластеры непосредственно рядом с виртуальными машинами на той же инфраструктуре. Причем все уже готово: сеть виртуализация сети для контейнеров, есть СХД для контейнеров. И конечно продукты из семейства vRealize для мониторинга емкости и производительности, для Charback и даже создания портала самообслуживания и каталога сервисов.

Поэтому с помощью VMware Cloud Foundation можно создать полноценный программно-определяемый центр обработки данных. Что из себя представляет VMware Cloud Foundation? Если используется vSAN, то это набор x86 стандартных серверов, на этих серверах работают vSphere, vSan и NSX, работают стековые компоненты vRealize, работают продукты семейства Tanzu и на этих серверах можно запускать виртуальные машины.

Основной архитектурный компонент VMware Cloud Foundation – это Workload Domain, это изолированный домен ресурсов, где есть вычислительные и сетевые ресурсы, предоставленные на базе NSX и ресурсы хранения данных на базе vSan или внешнего СХД.

Если говорить чуть подробнее, то есть отдельный Management Domain, где «живут» management компоненты, это прямая аналогия с management кластером в стандартной архитектуре центра обработки данных.

Есть выделенный management кластер, где «живут» NSX, vSan, системы сбора логов и прочие управляющие компоненты. И есть Workload Domain, где «живут» виртуальные машины и контейнеры.

В рамках VMware Cloud Foundation может быть до 15 Workload Domain. Они связаны таким образом, что если у вас есть права, то вы видите все ресурсы, которые есть в этой инсталляции.

На следующем большом слайде изображены разные серверы, здесь нет никаких ограничений, для Management Domain эти серверы совместимые с vSan, для Workload Domain эти серверы совместимые с vSphere, где-то больше памяти, где-то мощнее CPU, где-то есть GPU.

Эти серверы делятся на Workload Domain, эти домены отдаем той или иной рабочей группе, здесь все зависит от заказчика. Здесь все построено правильно, в соответствии с VMware Validated Designs, железо можно выбирать гибко, серверы добавлять в тот или иной Workload Domain. Таким образом получился классический программно-определяемый ЦОД со всеми необходимыми компонентами и с выделенным management кластером. Но это не обязательно, может быть консолидированная инфраструктура где management и Workload Domain «живут» в одном кластере.

Что же делает SDDС Manager?

Он занимается развертыванием инфраструктуры и ПО в соответствии с лучшими практиками, установкой обновлений и исправлений, а также масштабированием инфраструктуры. Он занимается правильной настройкой среды и разделением ресурсов на Workload Domain, установкой каких-то дополнительных компонентов, инициализацией дополнительных ресурсов: если появляются еще серверы, их можно добавить в тот или иной Workload Domain, если нужно уменьшить Workload Domain, то можно вытащить из него сервер с помощью SDDС Manager. Важный пункт – установка, исправление и обновление, здесь это происходит не так как в обычной инфраструктуре.

Какие задачи можно выполнить в SDDС Manager? Это быстрое развертывание, управление через политики, развертывание management доменов, создание Workload Domain, если есть на это ресурсы, то затем централизованная замена SSL сертификатов, управление паролями, управление ресурсами, создание/расширение/удаление Workload Domain, добавление серверов, патчинг, LCM, установка компонентов vRealize (vROps, vRLi, vRA), создание инфраструктуры для Kubernetes.

Вся эта функциональность помимо графического интерфейса осуществляется через API.

Если говорить о Lificycle Management, то на этот пункт стоит обратить особое внимание, это большое преимущество VMware Cloud Foundation. Здесь происходит обновление не на базе каждого компонента в отдельности, а всей инфраструктуры в целом.

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

Через SDDС Manager - Lificycle реагирует немного по-другому, мы проверяем обновления не на отдельные компоненты, т.е. после выпуска очередного пакета обновлений, потом выбираем домен или отдельный кластер, который хотим обновить. Потом происходит много проверок, которые осуществляет SDDС Manager. Далее администратор может либо запланировать обновление, либо нажать на «Обновить сейчас». Все происходит в рамках данной консоли. Не обязательно все обновлять до последней версии, обновление происходит на базе кластеров. Если что-то пошло не так в процессе обновления, то можно обновиться «руками».

Как это выглядит в интерфейсе? На предыдущем слайде изображен дашборд, на котором можно посмотреть как происходит то или иное действие, отсюда можно добавлять серверы, создавать домены и многое другое. Помимо интерфейса есть RESTful API, в котором можно выполнить все те же действия, которые есть в интерфейсе.

Таким образом через любую внешнюю систему, которая поддерживает RESTful API можно заниматься выделением ресурсов или, как минимум, мониторить, например, свободную емкость на платформе.

Теперь речь пойдет о возможной топологии внедрении VMware Cloud Foundation.

Это может быть как обычный Single Site Deployment (см. предыдущий слайд), это самое простое, ее внедряют бОльшая часть клиентов, также поддерживаются катастрофоустойчивые решения – растянутые кластеры на базе vSAN. Поддерживается также Edge Site Deployment. Если есть центральный ЦОД и какое-то количество филиалов, то требования для филиалов достаточно гуманные – 150 ms. Значит это можно внедрить и этим пользоваться. Вся управляющая инфраструктура в центральном ЦОДе, а непосредственно кластеры могут быть на площадках, в магазинах, цехах, есть много разных вариантов применения. Если в качестве storage используется vSAN, и если отключится vCenter, то vSAN полностью независим от него. Для особенно больших инсталляций поддерживается Multi-Site Deployment, когда можно объединить несколько SDDС Manager в одну инфраструктуру и видеть все ресурсы из одного окна (см. следующий слайд).

Можно спустится на уровень конкретной площадки и посмотреть как обстоят дела там.

Архитектура VMware Cloud Foundation

Начнем с Bill of Materials, то есть с текущих версий компонентов. Все версии компонентов представлены на следующем слайде.

Bill of Materials обновляется раз в квартал или даже чаще. Если появляется какая-то критическая уязвимость, то патчи могут ставиться отдельно в независимости от сетки релизов.

Существует консолидированная и стандартная архитектура.

Consolidated архитектура и Standart архитектура. В случае Consolidated архитектуры пользовательские нагрузки и инфраструктурные ВМ работают в одном кластере, а разделение ресурсов осуществляется с помощью Resource Pools. В случае же стандартной архитектуры есть отдельный management кластер и отдельный кластер для пользовательских нагрузок, это уже полноценный Deployment для больших площадок.

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

Теперь рассмотрим что представляет собой Management Domain.

Management Domain – это специальный домен для управляющих компонентов, это 4 сервера, которые должны поддерживать vSAN и они должны быть подключены к сети. На этом домене находятся все management компоненты (см. предыдущий слайд). В качестве системы хранения данных для первых 4-х серверов поддерживается только vSAN. 4 сервера – это минимальное количество, если у вас много Workload Domain, то вы можете добавить ресурсов.

В Workload Domain нет никаких лишних management компонентов, там работают только пользовательские виртуальные машины и опционально работают виртуальные маршрутизаторы NSX Edge, через которую обеспечивается связанность с внешней сетевой инфраструктурой. Серверы можно добавить в тот же Workload Domain или создать новый домен.

Workload Domain – это отдельный vCenter со встроенным платформ-сервис контроллером, отдельные NSX менеджеры, storage vSAN, либо какой-то внешний storage.

В каждом Workload Domain может быть до 400 серверов, до 15 Workload Domain на инсталляцию, включая MGMT.