vCloud Availability: глубокое погружение в репликацию трафика

vCloud Availability: глубокое погружение в репликацию трафика

В конце января этого года VMware анонсировала выход семейства продуктов vCloud Availability для vCloud Director, представляющее собой простое облакоориентированное средство аварийного восстановления. Инструмент предназначен для решения актуальных проблем как поставщиков облачных услуг, так и непосредственно клиентов.

Сегодня организации нуждаются в защите облачных данных, но, к сожалению, пока нет такого решения, которое как безразмерный сапог подходило бы на ногу любого размера. Поставщикам услуг, как и клиентам, следует изначально разобраться в технических и бизнес-требованиях, после чего убедиться, что выбраны действительно правильные инструменты для решения имеющихся задач. В случае с vCloud Availability для vCloud Director заказчики получают простое и экономически эффективное средство аварийного восстановления на базе облака, которое подходит для малого, среднего и крупного бизнеса.

vCloud Availability

Говоря простыми словами, vCloud Availability выступает в виде сервиса, который расширяет возможности vCloud Director, реплицируя виртуальные машины между средами vSphere и публичными облаками. Особенность решения заключается в отсутствии необходимости создавать частные (private) сети для репликации трафика между многопользовательскими on-premise-окружениями и публичными облаками. Двунаправленная репликация гарантирует безопасное движение трафика через интернет, о чем подробнее поговорим в этой статье.

Пример связки публичного облака с инфраструктурой vSphere

Пример связки публичного облака с инфраструктурой 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

Обзор компонентов vCloud Director и vCloud Availability

Как отмечалось ранее, «коннект» всегда инициируется on-premise-стороной. Вот почему мы имеем управляющее соединение (control connection), которое балансирует нагрузку на один из облачных прокси, в нашем случае Cloud Proxy 2. Реплицируемый трафик исходит от ESX-хоста, направляясь в облако (2) через Internal Load Balancer к одному из Cloud Proxy. В нашем случае используется Cloud Proxy 1 (3). За счет установленного соединения onpremise 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

Поделиться в социальных сетях

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...