Очередной интересный гостевой пост компании ИТ-ГРАД. Функция vCloud Connector Datacenter Extension позволяет растянуть ЦОД заказчика до облака провайдера. Таким образом клиент получает возможность перераспределения рабочей нагрузки и переноса виртуальных машин или vApp на публичную площадку с сохранением первоначальных настроек сети. Следовательно, виртуальные машины продолжают по-прежнему использовать заданный IP- и MAC-адрес в публичной среде. К тому же на ВМ распространяются те же правила NAT и межсетевого экрана, которые ранее применялись в локальной сети.
Как работает Stretch Deploy
При перемещении (stretch deploy) виртуальной машины или vApp в публичное облако из локального центра обработки данных vCloud Connector растягивает приватную сеть с ВМ и vApp до публичного облака путем создания L2 SSL VPN-туннеля, устанавливаемого между vShield Edge в приватной и публичной сетях. Если взглянуть на этот процесс изнутри, получаем следующее:
vCloud Connector изначально проверяет, можно ли растянуть локальную сеть ЦОД с расположенными в ней ВМ или vApp.
После этого формируется новая маршрутизируемая vApp-сеть в Organization VDC клиента в публичном облаке.
Если необходимо, создаются правила NAT и Firewall в публичной сети.
Также по мере необходимости определяются правила NAT и Firewall в приватной сети.
Создается SSL VPN-туннель между vShield Edge в приватной сети и vShield Edge в новой маршрутизируемой сети в публичном облаке.
ВМ или vApp копируются и разворачиваются в публичном облаке.
Важно! Если Stretch Deploy организуется из инфраструктуры на базе vSphere, vCloud Connector создает временный vApp в VDC организации публичного облака и удаляется по завершении выполнения Stretch Deploy команд. Если же растягивание происходит из ЦОД на базе vCloud Director, vCloud Connector создает временные vApp на обеих сторонах и удаляет по завершении выполнения Stretch Deploy команд.
Движение трафика при растягивании ЦОД
Пример использования Stretch Deploy
Давайте рассмотрим, как происходит движение трафика в случае растягивания ЦОД. Но для начала обратимся к схеме, представленной на рисунке выше, и сравним, как следует трафик без Stretch Deploy.
Здесь машина VM A выступает в роли Apache Tomcat сервера с открытым портом 8000. Подключение пользователя к этой ВМ происходит через NAT, используя публичный IP-адрес 10.112.185.1:8000. При этом взаимодействие VM B с машиной VM A происходит через внутренний IP, имеющий значение 192.168.2.2:8000. Если пользователь обращается к Apache Tomcat серверу через публичный IP (10.112.185.1), запрос перенаправляется в маршрутизируемую сеть организации средствами пограничного шлюза vShield Edge. Обращение VM B к серверу Apache Tomcat происходит напрямую, поскольку обе ВМ расположены в одной и той же L2-сети.
В случае Stretch Deploy виртуальная машина VM A попадает в публичную сеть (Public cloud network). При этом vCloud Connector создает маршрутизируемую vApp-сеть в облаке, после чего организуется SSL VPN-туннель между vShield Edge в сети предприятия (Enterprise network) и vShield Edge новой маршрутизируемой сети в облаке.
Таким образом, когда VM A находится в сети публичного облака, происходит следующее:
Пользователь обращается к Tomcat server виртуальной машины VM A, используя публичный IP 112.185.1. Запрос направляется в сеть предприятия с установленным L2-туннелем, поступая на vShield Edge. После запрос направляется через SSL VPN-туннель, попадает на vShield Edge в маршрутизируемой сети организации публичного облака и достигает машины VM A.
Когда VM B обращается к VM A используя «серый» IP-адрес (192.168.2.2), запрос перенаправляется на vShield Edge, размещенный в сети предприятия, где установлен L2-туннель. Затем запрос передается в маршрутизируемую сеть организации в публичном облаке, используя vShield Edge, и в рамках установленного SSL VPN-туннеля достигает машины VM A.
В сценарии, когда VM C обращается к Tomcat server (VM A) используя внутренний IP-адрес (168.2.2), запрос приходит к VM A напрямую, поскольку машины расположены в одной и той же L2-сети и по одну сторону L2-туннеля.
Чтобы функция Stretch Deploy работала полноценно, необходимо учитывать следующие системные требования:
Подготовка окружения для Stretch Deploy
Прежде чем воспользоваться преимуществами Stretch Deploy, необходимо задать настройки в веб-консоли vCloud Connector Server Admin.
# Инфраструктура на базе vSphere
Для каждой инфраструктуры на базе vSphere, где требуется использовать Stretch Deploy, необходимо зарегистрировать vShield Manager, ассоциированный с vSphere. Это позволит vCloud Connector получать сетевую информацию относительно инфраструктуры vShield.
Что требуется? Уже установленные и настроенные vCloud Connector Server, vCloud Connector Node. Последний, в свою очередь, должен быть зарегистрирован на стороне vCloud Connector Server.
Что дальше? Открываем веб-консоль vCloud Connector Server Admin, вводим логин, пароль. Переходим на закладку Nodes, где отражаются все зарегистрированные узлы vCloud Connector Nodes. В качестве примера приведем следующую иллюстрацию:
Пример зарегистрированных узлов на стороне vCloud Connector Server
Необходимо убедиться, что в рассматриваемом списке присутствует узел, который используется для Stretch Deploy. Далее кликаем на значок шестеренки и выбираем Stretch Deploy Settings. Задаем следующие значения:
Настройку необходимо выполнить на всех vSphere-инфраструктурах, где планируется использовать Stretch Deploy.
# Облако vCloud Director
Для любого облака vCloud, требующего функциональность Stretch Deploy, необходимо задать параметры учетной записи администратора уровня организации.
RSS
