Год назад в центр компетенций по системам управления ИТ и мониторинга «прилетела» задача: развернуть продукт Pivotal Cloud Foundry (являющийся, фактически, эталонным образцом модели PaaS). В двух словах, Pivotal Cloud Foundry (PCF) – это готовое коммерческое решение для предприятий, которые:

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

В этой статье я не стремлюсь прорекламировать вендорский продукт или в очередной раз «пояснить за микросервисы». Моя главная цель – поделиться опытом развертывания инфраструктуры для облачной платформы PCF в нестандартной конфигурации такого рода решения. Эта конфигурация пришла в ходе задачи о создании среды для разработчиков проекта, который без ложной скромности называли «Цифровой трансформацией».

Pivotal просто «готовить»

От «бизнеса» была поставлена глобальная задача: строить продукты, используя микросервисную архитектуру. В качестве IaaS была выбрана виртуальная инфраструктура VMware; в качестве PaaS – платформа Pivotal Cloud Foundry.

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

Немного истории

Крупнейший разработчик программного обеспечения для виртуализации – компания VMware – стояла у истоков создания гибридной облачной платформы Cloud Foundry с открытым исходным кодом под лицензией Apache 2.0, разрабатываемой с целью повышения качества процессов непрерывной интеграции и непрерывной поставки (CI/CD) программного обеспечения. В 2014 году был создан некоммерческий фонд Cloud Foundry Foundation (CFF), под покровительством некоммерческой организации Linux Foundation, что позволило создать нейтральную площадку для совместного развития, управления и продвижения проекта. В 2015 году сообщество CFF приняло решение о сертификации систем, базирующихся на проекте с открытым исходным кодом Cloud Foundry. Программа сертификации была призвана обеспечить переносимость PaaS-решений между различными облачными сервисами и системами, размещенными на площадках предприятий (on-premise). В настоящее время в объединение CFF входит более шестидесяти организаций – лидеров мирового рынка телекоммуникаций и инженерных систем: Cisco, Dell EMC, Hewlett Packard Enterprise, IBM, Pivotal, SAP, VMware, Intel и многих других.

Компания Pivotal Software, Inc. (Pivotal) – обособленное c 2013 года подразделение компаний EMC Corporation и VMware – объединила широкий спектр инновационных разработок для создания продукта Pivotal Cloud Foundry (на базе открытого исходного кода), включающего в себя привычные сервисы конфигурации, управления и мониторинга приложений, «под ключ».

Самый главный «ингредиент»

Краеугольным камнем философии Cloud Foundry является термин «микросервисная архитектура» (microservice architecture).

Микросервисная архитектура — это способ представления единого приложения как набора небольших сервисов, каждый из которых работает в собственном процессе и связывается с остальными, используя легковесные механизмы (как правило, протокол HTTP). Данный термин проще всего проиллюстрировать на примере сравнения с «монолитом» (monolithic architecture) – приложением, построенным как единое целое.

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

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

• Центральным звеном облачной среды является BOSH – инструментарий с открытым исходным кодом для развертывания и управления распределенных систем, поддерживающий целый ряд платформ: AWS, Azure, OpenStack, vSphere, vCloud и Google Compute Platform.
• За корректную работу среды выполнения (runtime) приложений отвечает целый ряд систем: управления жизненным циклом (Cloud Controller), управления производительностью (Diego), аутентификации и авторизации пользователей (UAA), обмена сообщениями (NATS), мониторинга технического состояния и работоспособности (Health Manager) и др.

Несмотря на то, что список микросервисов, входящих в релиз платформы Cloud Foundry, огромен, данный релиз закладывает минимальный фундамент, необходимый для развертывания и запуска в облаке так называемых «контейнерных» приложений (application containers).

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

На этом вводная по микросервисам заканчивается, и я приступаю к самому интересному — описанию инфраструктуры.

Для "приготовления" нам потребуется…

Проанализировав системные требования платформы PCF к кластеру VMware, сформировался ряд обязательных условий:

• Необходимы права на чтение/запись уровня datacenter согласно vSphere Inventory Hierarchy;
• Необходим доступ к vCenter по протоколу HTTPS;
• Необходим доступ к ESXi по протоколу TCP к портам: 443, 902, 903;
• При включении опции vSphere DRS (Distributed Resource Scheduler) уровень автоматизации должен быть установлен в Partially automated или Fully automated.

Уже исходя из этих требований, стало очевидно, что для развертывания PCF необходимо иметь изолированный vCenter и, как следствие, изолированные хосты ESXi. Чтобы реализовать такой сегмент (читай, сэкономить на железе), в голову пришла идея использовать концепцию вложенной виртуализации.

Сказано – сделано! Для исполнения такой, мягко говоря, нетрадиционной модели IaaS мне понадобился кусочек нашего публичного облака Техносерв Cloud, который реализован сразу в двух средах виртуализации: VMware и OpenStack. В качестве панели управления средой VMware выступает продукт vCloud Director.

Сразу оговорюсь: на практике такие решения не идут в Prod, но в качестве Test или Dev стенда сгодятся. Дальше по тексту я постараюсь рассказать об архитектуре, ключевых особенностях и преимуществах инсталляции (или недостатках, как пойдет).

Тот самый «слоеный пирог»

Итак, в облаке TS-Cloud был создан виртуальный дата-центр (VDC) TS-CloudDev со следующими характеристиками:

• Memory Quota: 750 GB
• vCPU speed: 2.60 GHz
• CPU Quota: 314.60 GHz
• Disk Quota: 3474 GB
• VM Quota: 100
• Network Quota: 10

Для целевого кластера, используя Edge Gateway, созданы 4 внутренних подсети:

1. 10.0.10.0/24 – в качестве management сети хостов Nested ESXi.
2. 10.0.11.0/24 – в качестве vMotion сети для миграции виртуальных машин, развернутых на хостах Nested ESXi.
3. 192.168.63.192/26 – в качестве сети для интеграции с внутренней сетью.
4. 10.10.0.0/16 – в качестве сети развертывания платформы PCF.

Подсеть 10.0.150.0/24 является внешней по отношению к VDC.

Стоит отметить, что наличие компонента Edge Gateway является одним из ключевых преимуществ использования среды vCloud. Это виртуальный маршрутизатор VDC-сетей, который можно настроить для предоставления сетевых услуг: DHCP, NAT, firewall, static routing, VPN и load balancing.

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

Вид «снизу»:

Вид «ex machina»:

Вид «сверху»:

…А еще через неделю место на первом сторадже закончилось, поэтому было оперативно подключено второе хранилище.

Хозяйке на заметку

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

• Виртуальный маршрутизатор Edge Gateway может поддерживать до 10 интерфейсов (см. выше Network Quota). Интерфейс может классифицироваться как uplink при подключении к внешней сети и как внутренний интерфейс при подключении к VDC-сети. При создании Edge Gateway необходимо указать по крайней мере один uplink. Внутренний интерфейс добавляется автоматически при создании маршрутизируемой VDC-сети.

• Общий размер хранилища, выделенный для VDC, считается независимо от выбранной модели (Allocation Model) по формуле:

  
  

  Storage size to be allocated = Total Storage Allocated to virtual machines + Total Memory Allocated to virtual machines (except memory allocated to templates) + Media Storage used

  Таким образом, в общий размер хранилища входит выделенная виртуальным машинам память. В нашей конфигурации выделено 750 GB оперативной памяти, по 2 GB в качестве внутреннего хранилища для каждого ESXi, 100 GB в качестве внутреннего хранилища для vCenter, 16 GB в качестве внутреннего хранилища для виртуальной машины storage1. То есть, суммарно для VDC будет выделено 750 + 2*4 + 100 + 16 + 2600 = 3474 GB (см. выше Disk Quota).

  
  
• Возникает необходимость включения Promiscuous Mode за пределами VDC. Это обязательное требование вложенности VMware, которое объясняется следующим образом:
  как VSS (vSphere Standard Switch), так и VDS (vSphere Distributed Switch) не реализуют функцию MAC Learning в отличие от традиционных сетевых коммутаторов, поскольку платформа vSphere уже знает, какие MAC-адреса назначаются определенной виртуальной машине. Это означает, что виртуальный коммутатор будет перенаправлять сетевые пакеты на виртуальную машину, только если MAC-адрес назначения соответствует MAC-адресу ESXi vmnic (pNIC). В среде вложенной виртуализации MAC-адрес назначения сетевых пакетов, предназначенных для этих виртуальных машин, будет отличаться от MAC-адреса Nested ESXi vmnic. В связи с этим виртуальный коммутатор физического ESXi-сервера отбрасывает пакет, если режим Promiscuous не включен.
• Файловое хранилище (первоначально использовался NFS) не обеспечивает требуемой для штатной работы платформы производительности дисковой подсистемы; рекомендуется использовать блочное хранилище (вот откуда взялся iSCSI).

Заключение

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

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