Сегодня организации нуждаются в защите облачных данных, но, к сожалению, пока нет такого решения, которое как безразмерный сапог подходило бы на ногу любого размера. Поставщикам услуг, как и клиентам, следует изначально разобраться в технических и бизнес-требованиях, после чего убедиться, что выбраны действительно правильные инструменты для решения имеющихся задач. В случае с vCloud Availability для vCloud Director заказчики получают простое и экономически эффективное средство аварийного восстановления на базе облака, которое подходит для малого, среднего и крупного бизнеса.
Говоря простыми словами, vCloud Availability выступает в виде сервиса, который расширяет возможности vCloud Director, реплицируя виртуальные машины между средами vSphere и публичными облаками. Особенность решения заключается в отсутствии необходимости создавать частные (private) сети для репликации трафика между многопользовательскими on-premise-окружениями и публичными облаками. Двунаправленная репликация гарантирует безопасное движение трафика через интернет, о чем подробнее поговорим в этой статье.
Пример связки публичного облака с инфраструктурой vSphere
Чтобы понять, как организуется репликация между on-premise-инфраструктурой и публичным облаком с помощьью vCloud Availability, рассмотрим основные компоненты.
On-premise-компоненты
Итак, многопользовательское on-premise-окружение работает практически с любой версией vSphere используя апплайнс vSphere Replication (VR). Технология позволяет выполнять репликацию данных между сайтами, реализуемую на уровне гипервизора, для чего не нужно привлекать специальные возможности СХД. С точки зрения пользователя процесс выглядит прозрачно и просто. Гипервизор отслеживает изменения, вносящиеся в диски виртуальных машин, и согласно заданным политикам выполняет регулярную синхронизацию с резервной площадкой. При этом синхронизацией управляют служебные ВМ VR Appliance, расположенные на каждой стороне. Апплайнс требует доступ к интернету, но совершенно не обязательно задавать публичный маршрутизируемый IP. VR Appliance может находиться за брандмауэром с Secure NAT и лишь одним открытым портом TCP 443. vSphere Replication представлен тремя компонентами:
- vSphere Replication Manager Service (vRMS) – это по сути «мозг» on-premise VR, использующий внутреннюю или внешнюю базу данных по выбору. В vRMS также предусмотрен плагин vSphere Web Client для управления репликацией.
- vSphere Replication Server (vRS) – ключевая точка для входящей (идущей из облака) репликации, используемая до того, как трафик достигнет места назначения в виде целевого датастора. Этот компонент поддерживает масштабирование в случае, если потребуется развертывание дополнительного апплайнса. Однако компонент не используется для исходящей репликации.
- vCloud Tunneling Agent (vCTA) – компонент, отвечающий за организацию безопасного туннеля при подключении к облаку. Ведет контроль и оставляет подключение открытым для возможности обратной репликации.
Помимо названных компонентов, больше ничего не требуется, поскольку фактический механизм репликации (vSphere Replication агент и vSCSI фильтр) уже присутствует в гипервизоре – ESXi VMkernel. Таким образом, To-the-cloud репликации происходит по схеме:
ESXi host (VR Agent) > vSphere Replication Appliance (vCTA) > Internet > vCloud Availability public endpoint (Cloud Proxy load balanced VIP)
Тогда как репликация From-the-cloud использует иной порядок:
vCloud Availability public endpoint (Cloud Proxy) > Internet > vSphere Replication Appliance (vCTA) > vSphere Replication Server (either embedded on VR appliance or standalone) > ESXi host
Компоненты публичного облака
Для работы в облаке требуется поддерживаемая версия vCloud Director. При этом vCloud Availability использует vSphere Replication-компоненты в виде vRMS-апплайнсов. Дополнительно потребуются:
- vSphere Replication Cloud Service (vRCS) – высокодоступный апплайнс с расширенными vCloud VR API. Кроме этого, используется внешняя БД Cassandra и RabbitMQ для взаимодействия с vCloud Director.
- Cloud Proxies – балансирующие нагрузку vCloud Director элементы в виде компонентов со всеми отключенными vCloud-сервисами и единственным включенным сервисом Cloud Proxy (multitenanted vCTA).
- vCloud Availability Portal appliances – балансирующие нагрузку stateless компоненты для управления репликацией в облаке, где on-premise vSphere Replication UI недоступен.
В таком сценарии поставщик услуг может обслуживать сотни клиентов с тысячами одновременных туннелей. Для достижения такого уровня масштабирования Cloud Proxy разворачиваются в режиме scale-out с распределителем нагрузки на границе. При этом балансировщик нагрузки обеспечивает контроль on-premise vCTA соединения, а также репликации облачного трафика. Для организации To-the-cloud репликации используется следующая схема:
Tenant on-prem VR Appliance > Internet > Load balancer > Cloud Proxy > vRS > ESXi host
Для репликации From-the-cloud задействован иной порядок, где используется один из двух возможных вариантов: балансировщик нагрузки с набором L7 правил приложений и без него. Второй вариант считается более рекомендуемым. Остановимся на нем подробнее.
Обзор компонентов vCloud Director и vCloud Availability
Как отмечалось ранее, «коннект» всегда инициируется on-premise-стороной. Вот почему мы имеем управляющее соединение (control connection), которое балансирует нагрузку на один из облачных прокси, в нашем случае Cloud Proxy 2. Реплицируемый трафик исходит от ESX-хоста, направляясь в облако (2) через Internal Load Balancer к одному из Cloud Proxy. В нашем случае используется Cloud Proxy 1 (3). За счет установленного соединения on-premise vCTA получает оповещение о том, какой Cloud Proxy используется для конкретной репликации (4-7). В текущем примере vCTA может установить соединение с Cloud Proxy 1, используя при этом 1:1 DNAT IP/ FQDN Cloud Proxy (9). Таким образом, два подключения (3) и (9) как бы «сшиваются» друг с другом (10), инициируя передачу трафика из облака в сторону on-premise-окружения.
Подводя итоги
Чтобы озвученная схема была по-настоящему рабочей, дополнительно потребуется:
- Балансировщик нагрузки Cloud Proxy с Cloud ProxyBase VIP, который используется для контрольного коннекта и to-the-cloud репликации.
- Внутренний балансировщик нагрузки (Internal) для трафика, идущего от ESXi к Cloud Proxy.
- Дополнительный публичный IP/FQDN для каждого Cloud Proxy при передаче from-the-cloud трафика. Озвученный FQDN конфигурируется в файле global.properties в Cloud Proxy cell (loudproxy.reverseconnection.fqdn=FQDN:443).
- В случае использования того же самого Cloud Proxy и разных FQDN необходимо убедиться, что http-сертификат Cloud Proxy cell установлен на обоих FQDN.
*Текст подготовлен с использованием материала Tom Fojta’s Blog
