Для того чтобы принять решение о выборе технологий для построения собственной облачной платформы, нужно иметь представление о вариантах ее технической реализации: моделях, архитектуре и основных компонентах, инструментах управления. В качестве рекомендаций полезными могут быть примеры продуктов и платформ, представленных на рынке. Особый интерес, как показывает практика, представляет гибридная модель облака. Рассмотрим, что входит в состав такой инфраструктуры.
Прежде чем рассматривать техническую реализацию гибридной модели облачных инфраструктур, попробуем уточнить определения. Когда речь идет о гибридной модели, имеется в виду объединение нескольких различных облачных инфраструктур (частных или публичных), которые остаются независимыми с точки зрения управления и взаимодействуют между собой путем стандартизированных или частных интерфейсов, обеспечивая обмен данными и функциями управления. При этом технологии построения облачных платформ могут быть как идентичными, так и значительно различаться.
Архитектура и управление
Общая архитектура гибридных облачных платформ не имеет существенных отличий от архитектуры частного или публичного облака. Можно сказать, что нет специализированной и уникальной архитектуры облака, которое можно назвать гибридным. Изначально облачная платформа является частной, если мы говорим о ее развертывании в ЦОД организации, либо публичной, если ее эксплуатирует сервис-провайдер. Гибридность облака – это набор свойств, которые позволяют обеспечивать его интеграцию с другими видами облаков.
Такие гибридные свойства, реализуемые на разных уровнях архитектуры, могут предоставлять различные возможности и уровни интеграции. Для наглядности рассмотрим архитектуру классического частного или публичного облака (рис. 1). Можно выделить следующие основные уровни.
Аппаратная инфраструктура. Серверы, системы хранения данных и сетевое оборудование, обеспечивающие физическое существование ИТ-инфраструктуры. На этом уровне интеграция может быть предусмотрена только для узкоспециализированных задач, например для синхронизации или миграции больших объемов данных. На уровне протоколов систем хранения может быть выполнена передача данных. Как правило, в таких случаях речь идет об оборудовании одного типа и производителя. В некоторых ситуациях для этого сервис-провайдеры целенаправленно развертывают у себя оборудование, идентичное установленному у клиентов.
Программно-определяемая инфраструктура. Набор технологий, обеспечивающих возможность программного (автоматизированного) управления всеми ИТ-ресурсами: вычислительными, сетевыми, СХД. Этот уровень, который часто называют IaaS (Infrastructure-as-a-Service), является непосредственно источником ИТ-ресурсов и основной точкой входа для различных систем оркестрации и управления.
Интеграция с внешними облачными инфраструктурами на уровне IaaS осуществляется только в пределах идентичных технологий. В частности, если используются одинаковые гипервизоры, то облака при определенных условиях могут поддерживать миграцию виртуальных машин, задействовав инструменты конкретного типа гипервизора. Как правило, интеграция на таком уровне осуществляется только между однотипными видами облачных решений и при централизованной поддержке провайдера или вендора.
Оркестратор. Ключевой компонент любого облака, выполняющий различные автоматизированные операции над уровнем программно-определяемой инфраструктуры, начиная с распределения ресурсов и заканчивая глубокой настройкой виртуальных машин и приложений. Оркестратор – основной механизм, выполняющий операции интеграции, в том числе в рамках функциональности гибридных облаков. Он обеспечивает высокий уровень абстракции, позволяя изолировать специфичные технологии уровня IaaS, предоставляя унифицированные интерфейсы для обмена данными, миграции виртуальных машин или функций управления облаком из внешней среды.
Портал самообслуживания – основной клиентский интерфейс для пользователей облака и администраторов облачной инфраструктуры. Пользователи получают доступ к различным видам облачных сервисов: инфраструктурные (IaaS), управление развертыванием приложений (APaaS), управление платформами для запуска приложений (PaaS) и т. д. Администраторы выполняют функции по настройке и распределению ресурсов, настройке самих облачных сервисов. Портал обычно имеет прямой доступ к уровню IaaS и к уровню оркестратора, позволяя встраивать автоматизированные функции в каталог сервисов.
С позиции гибридного облака портал должен предоставлять возможности по настройкам правил интеграции между облаками и функции управления гибридной облачной средой. Например, пользователь портала вправе выбрать типовой сервис или приложение, указав, в какой из облачных сред он его желает запустить, либо выполнить его прозрачную миграцию из одной среды в другую.
Система мониторинга обеспечивает две основных функции: контроль над состоянием работы всех компонентов облака и контроль над доступными ресурсами уровня IaaS. Первая функция, как правило, привязана к локальным задачам администрирования и не предоставляет интеграционных возможностей. Единый контроль над доступными ресурсами сразу нескольких объединенных облаков позволяет значительно упростить работу администраторов и пользователей.
Биллинг. Каждое облако в зависимости от типа и назначения имеет возможность расчета потребляемых ресурсов и предоставляет пользователям статистику либо выставляет счета. В очень редких случаях реализуется интеграция биллинга между различными типами облаков. Как правило, единый биллинг в рамках гибридного облака существует только при использовании одних и тех же технологий.
Примеры продуктов и платформ
Техническая реализация облачных решений разнообразна, и перечисленные выше основные уровни архитектуры могут быть либо объединены в рамках одного продукта, либо разделены на большее количество компонентов. Есть два основных пути построения облака:
- создать платформу самостоятельно из отдельных компонентов, выбирая наиболее подходящие технологии для каждого уровня;
- приобрести готовую платформу, включающую в себя все или несколько уровней.
Первый путь позволяет создать облачную платформу, наиболее полно соответствующую запросам пользователя, однако занимает больше времени, требует значительных инвестиций и несет в себе большие риски. Второй путь снижает гибкость решения, однако сокращает сроки, уменьшает риски и затраты.
Рассмотрим примеры продуктов и технологий, которые применяются в настоящее время для построения гибридных облачных решений.
Аппаратная инфраструктура для создания гибридной облачной платформы может представлять собой множество вариантов оборудования и иметь различные архитектуры. Можно выделить два основных подхода к построению инфраструктуры:
- «сделай сам». Инфраструктура собирается из отдельных компонентов (серверы, коммутация, системы хранения данных) на основании разработанной архитектуры. Поставщиками компонентов могут быть любые аппаратные вендоры, такие как HP, Dell EMC, Lenovo, IBM и т. д.;
- конвергентная платформа. Приобретение готового программно-аппаратного комплекса, собранного, проверенного и протестированного поставщиком заранее. В этом случае поставщик обеспечивает техническую поддержку всего комплекса, гарантирует его работоспособность и предоставляет стандартные регламенты по обслуживанию. Примерами таких продуктов являются Cisco FlexPod, Dell EMC VxBlock, HP ConvergedSystem.
Наряду с этим все большую популярность при построении облачных инфраструктур получают гиперконвергентные системы. В отличие от классической инфраструктуры, где представлены аппаратные системы хранения данных, в гиперконвергентной среде их заменяет специальное ПО, объединяющее емкость всех серверных узлов в общий виртуальный массив и предоставляющее необходимые службы управления данными (защита, репликация, дедупликация и т. д.). Благодаря этому такие системы обладают более широкими возможностями по масштабируемости ресурсов, которые можно наращивать по мере роста их потребления. Примерами подобных решений являются продукты Nutanix, Dell EMC VxRail и VxRack, HP Simplivity.
В сфере создания гибридных облаков существуют задачи, требующие интеграции на уровне аппаратных компонентов. Такая интеграция необходима прежде всего на уровне систем хранения, когда обеспечивается обмен большими объемами данных, организуется территориально распределенное хранилище, выполняются операции по резервному копированию или репликации данных в резервный ЦОД. Как уже отмечалось, единственным ограничением служит необходимость использования одинакового оборудования во всех объединенных облачных инфраструктурах. Примерами такого оборудования могут быть HP 3PAR, Dell EMC Isilon, NetApp FAS Series.
Основная задача построения программно-управляемой инфраструктуры – обеспечить возможность автоматического управления базовыми компонентами ИТ-инфраструктуры облака. К традиционным составляющим IaaS-уровня относятся:
- гипервизоры для виртуализации вычислительных ресурсов. Примеры продуктов: VMware vSphere, Microsoft Hyper-V, KVM;
- программно-управляемые СХД (SDS – Software Defined Storage). Могут представлять собой гиперконвергентные решения, такие как VMware VSAN, Nutanix, Ceph, либо оркестраторы для управления аппаратными системами хранения данных, например Dell EMC ViPR Controller;
- сетевые гипервизоры для автоматизации управления сетевыми службами. Примеры продуктов: VMware NSX, OpenSwitch, Cisco ACI.
Кроме того, на рынке представлены комплексные решения IaaS, например OpenStack, включающие в себя все указанные уровни и являющиеся дополнительным уровнем абстракции для других решений IaaS. В частности, OpenStack имеет средства универсального управления различными гипервизорами и СХД, «представляясь» другим системам и потребителям универсальной платформой IaaS.
Что касается оркестратора, то на рынке ПО предлагается большое количество средств автоматизации управления ИТ-инфраструктурами. Они различаются по назначению и возможностям: часть решений – это самостоятельные продукты, часть входит в состав комплексных облачных решений. Примеры продуктов:
- самостоятельные решения: Puppet, Chef, Ansible;
- в составе комплексных облачных платформ:
- vRealize Orchestrator (в составе VMware vRealize Suite);
- BOSH (в составе Cloud Foundry);
- Heat (в составе OpenStack).
Порталы самообслуживания крайне редко являются самостоятельными решениями, почти всегда это часть комплексных облачных платформ, сочетающая в себе широкие возможности. Как правило, все основные настройки функций гибридного облака доступны пользователям и администраторам именно через этот компонент.
Примеры продуктов:
- vRealize Automation (в составе VMware vRealize Suite);
- Murano, Horizon (в составе OpenStack);
- Azure Stack Portal (составная часть облака Microsoft Azure Stack).
Системы мониторинга могут быть отдельными универсальными решениями либо входить в состав комплексных облачных платформ. Примеры продуктов:
- ViPR SRM (часть решения Dell EMC Native Hybrid Cloud);
- vRealize Operations (в составе VMware vRealize Suite);
- Zabbix (популярная универсальная open source мониторинговая система).
Наиболее простой способ построения гибридного облака – выбрать готовое облачное решение – комплексную облачную платформу, включающую в себя заранее настроенные и интегрированные между собой компоненты, перечисленные выше. На рынке представлено большое количество готовых программных и даже программно-аппаратных комплексов, которые можно внедрить в достаточно короткий срок.
Примерами облачных программных платформ являются OpenStack; VMware vRealize Suite; Microsoft Azure Stack; Cisco UCS Director; Cloud Foundry; Kubernetes; Mesosphere.
В качестве примеров программно-аппаратных комплексов, включающих все уровни гибридного облака, можно привести:
- Dell EMC Enterprise Hybrid Cloud (программно-аппаратный комплекс на базе облачного ПО VMware vRealize Suite и конвергентных платформ Dell EMC);
- HPE ProLiant for Microsoft Azure Stack (программно-аппаратный комплекс на основе облачного ПО Microsoft и аппаратной платформы HPE);
- FusionSphere OpenStack (комплекс на базе ПО OpenStack и аппаратных платформ Huawei).
Не стоит забывать о публичных облачных сервисах, с которыми поддерживается интеграция большей части популярного облачного программного обеспечения, в частности Amazon Web Services, Google Cloud Platform, Microsoft Azure, IBM SoftLayer, Dell EMC Virtustream.
Вместо заключения
До принятия решения о выборе технологий для построения собственной облачной платформы предварительно нужно проанализировать цели ее создания. Прежде всего следует определить архитектуру приложений (классическая, контейнеризированная, микросервисная), перечень служб, которые будут использовать приложения (базы данных, обмен сообщениями, бизнес-системы и т. д.), решить, кто будет пользователем облака. Затем необходимо составить список требований к отказоустойчивости, защите данных и масштабируемости, определиться с уровнями интеграции с внешними облачными платформами, оценить степень сложности разработки новых сервисов, уровень технической поддержки всех компонентов облака (один поставщик или несколько, их присутствие в регионе), а также многое другое
