- PVSM.RU - https://www.pvsm.ru -
Год назад в центр компетенций по системам управления ИТ и мониторинга «прилетела» задача: развернуть продукт Pivotal Cloud Foundry (являющийся, фактически, эталонным образцом модели PaaS). В двух словах, Pivotal Cloud Foundry [1] (PCF) – это готовое коммерческое решение для предприятий, которые:
В этой статье я не стремлюсь прорекламировать вендорский продукт или в очередной раз «пояснить за микросервисы». Моя главная цель – поделиться опытом развертывания инфраструктуры для облачной платформы PCF в нестандартной конфигурации такого рода решения. Эта конфигурация пришла в ходе задачи о создании среды для разработчиков проекта, который без ложной скромности называли «Цифровой трансформацией».
От «бизнеса» была поставлена глобальная задача: строить продукты, используя микросервисную архитектуру. В качестве IaaS была выбрана виртуальная инфраструктура VMware; в качестве PaaS – платформа Pivotal Cloud Foundry.
В пользу выбора PCF говорила возможность предоставления пользователям (в смысле, разработчикам) готового набора различных сред программирования, баз данных и сервисов для создания приложений любых масштабов без привязки к конкретному гипервизору. Такая гибкость позволила сконцентрироваться на построении бизнес-логики приложений и минимально обращаться к низкоуровневым функциям уровня IaaS.
Крупнейший разработчик программного обеспечения для виртуализации – компания VMware – стояла у истоков создания гибридной облачной платформы Cloud Foundry [2] с открытым исходным кодом под лицензией 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 можно выделить два основных направления:
Несмотря на то, что список микросервисов, входящих в релиз платформы Cloud Foundry, огромен, данный релиз закладывает минимальный фундамент, необходимый для развертывания и запуска в облаке так называемых «контейнерных» приложений (application containers).
Контейнерные приложения – это следующий уровень изоляции, на котором приложение содержит все необходимые ему компоненты и работает вне зависимости от операционной системы. Контейнерная виртуализация приложений обеспечивает лучшую производительность, масштабируемость, плотность размещения, динамическое управление ресурсами, а также легкость в администрировании, по сравнению с альтернативными решениями.
На этом вводная по микросервисам заканчивается, и я приступаю к самому интересному — описанию инфраструктуры.
Проанализировав системные требования платформы PCF к кластеру VMware, сформировался ряд обязательных условий:
Уже исходя из этих требований, стало очевидно, что для развертывания PCF необходимо иметь изолированный vCenter и, как следствие, изолированные хосты ESXi. Чтобы реализовать такой сегмент (читай, сэкономить на железе), в голову пришла идея использовать концепцию вложенной виртуализации.
Сказано – сделано! Для исполнения такой, мягко говоря, нетрадиционной модели IaaS мне понадобился кусочек нашего публичного облака Техносерв Cloud [5], который реализован сразу в двух средах виртуализации: VMware и OpenStack. В качестве панели управления средой VMware выступает продукт vCloud Director.
Сразу оговорюсь: на практике такие решения не идут в Prod, но в качестве Test или Dev стенда сгодятся. Дальше по тексту я постараюсь рассказать об архитектуре, ключевых особенностях и преимуществах инсталляции (или недостатках, как пойдет).
Итак, в облаке TS-Cloud был создан виртуальный дата-центр (VDC) TS-CloudDev со следующими характеристиками:
Для целевого кластера, используя Edge Gateway, созданы 4 внутренних подсети:
Подсеть 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»:
Вид «сверху»:
…А еще через неделю место на первом сторадже закончилось, поэтому было оперативно подключено второе хранилище.
В процессе развертывания я неизбежно столкнулась с ограничениями, которые необходимо учитывать при подготовке инфраструктуры:
Общий размер хранилища, выделенный для VDC, считается независимо от выбранной модели (Allocation Model) по формуле [6]:
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).
В заключение хотелось бы отметить, что использование вложенной виртуализации для Dev стенда оказалось одним из главных преимуществ, поскольку это позволило одновременно:
Автор: anniemelen
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/it-infrastruktura/280828
Ссылки в тексте:
[1] Pivotal Cloud Foundry: https://pivotal.io/platform
[2] Cloud Foundry: https://www.cloudfoundry.org
[3] BOSH: https://bosh.io/docs
[4] vSphere Inventory Hierarchy: https://vmware.github.io/pyvmomi-community-samples/assets/vchierarchy.pdf
[5] Техносерв Cloud: https://ts-cloud.ru
[6] формуле: https://kb.vmware.com/s/article/2043173
[7] VDS: https://www.reg.ru/?rlink=reflink-717
[8] Источник: https://habr.com/post/359104/?utm_campaign=359104
Нажмите здесь для печати.