Озвученный метод обеспечивает эластичное развертывание приложений с использованием балансировки нагрузки и кластеризации. При этом заказчик получает доступ к инфраструктуре с помощью vCloud Director, используя удобный для работы GUI или API.
Дизайн нескольких vCenter Server
Подход, при котором используется один экземпляр vCloud Director и несколько зон доступности, определяет следующие правила: каждая availability zone требует наличия собственного vCenter Server и vCNS Manager. Рисунок ниже показывает, как в контексте двух сайтов представлены зоны доступности, включая кластеры управления и ресурсов.
Пример с использованием нескольких сайтов
Отметим, что для каждого сайта предусматривается кластер управления. При этом shared cloud management VMs запускается с Site A и имеет возможность аварийного переключения на Site B. Аналогично для каждого сайта предусмотрен Provider VDC управления ресурсами (vCenter Server, vCNS/NSX Managers, databases). Обратите внимание, что здесь не происходит разделения компонентов ресурсов группы, что делает дизайн зон доступности достаточно прозрачным.
Одна из проблем, с которыми сталкиваются клиенты, заключается в том, что сети организации vDC не умеют «растягиваться» между сайтами. Несмотря на то что VXLAN-сети работают поверх маршрутизируемых Layer3-сетей, «растяжения» между отдельно стоящими vCenter-серверами не происходит. vCNS/NSX-менеджер выступает фактической гранью для VXLAN-сетей, а между vCenter Server и vCNS/NSX Manager устанавливается связь «один к одному». Следовательно, чтобы добиться связности между виртуальными машинами в vDC из двух зон доступности, используют Edge Gateway IPsec VPN или организуют внешнее сетевое подключение. Все это приводит к достаточно сложной настройке маршрутизации.
Пример сетевой связности между vDC
Дизайн vCenter Server с «растянутой» сетью организации
Предлагаем рассмотреть альтернативный подход, цель которого заключается в «растяжении» сети организации – назовем ее Org VDC net (shared) – между двумя сайтами при наличии высокодоступного пограничного шлюза (Edge Gateway). Результат, который необходимо получить в итоге, показан на рисунке ниже.
Пример «растягивания» сети
Для достижения поставленной цели потребуется один экземпляр ресурсной группы vCenter Server и VXLAN-домен с разделением ресурсов на две зоны доступности. Эластичность vCenter Server достигается за счет vSphere HA, vCenter Server Heartbeat или Site Recovery Manager.
Возникает вопрос: можно ли использовать кластерный подход, как в сценарии с несколькими vCenter, где каждый Provider vDC имеет собственный набор кластеров, в рамках одного сайта? Для ответа необходимо ознакомиться с концепцией транспортных зон VXLAN. Дело в том, что сетевые пулы VXLAN в vCloud Director охватывают только скоп Provider VDC. Это означает, что любая сеть Org VDC, созданная на базе сетевого пула VXLAN, сможет охватить и кластеры в Provider VDC. Таким образом, когда добавляется новый кластер или удаляется существующий, скоп транспортной зоны VDC расширяется или сужается.
Редактирование настроек Transport Zones
Ниже приведены два способа, с помощью которых расширяют транспортную зону VXLAN.
Ручное расширение VXLAN-скопа
Первый метод является достаточно простым и включает в себя ручное расширение скопа транспортной зоны VXLAN в vCNS или NSX Manager. Его недостаток заключается в том, что любое изменение конфигурации кластера Provider VDC или пула ресурсов удаляет все внесенные вручную изменения. Но поскольку реконфигурация Provider VDC – задача не слишком частая, такой подход является вполне жизнеспособным.
Растяжение Provider VDC
Второй способ включает в себя «растяжение» по меньшей мере одного Provider VDC до другого сайта так, чтобы VXLAN скоп охватывал обе площадки. В итоге Org VDC связывает сети между двумя сайтами. Это достигается за счет особенностей Provider VDC и использования нескольких Resource Pools внутри кластеров. Поскольку существует необходимость в «растяжении» исключительно сети VXLAN, не затрагивая вычислительные ресурсы, для этих целей используются соответствующие политики хранилищ сайта. Таким образом, Provider VDC будет иметь доступ к пулу ресурсов другого сайта, за исключением доступа к его хранилищу. Рисунок ниже иллюстрирует вышесказанное.
Пример «растяжения» Provider VDC
Преимущество второго подхода заключается в большей прозрачности, хотя представляет более сложную конфигурацию.
Высокодоступный пограничный шлюз
Теперь, когда сеть Org VDC охватывает оба сайта, решим вопрос с пограничным шлюзом (Edge Gateway). Поскольку востребованные для клиента приложения без доступа к внешнему миру бесполезны, выполним настройку пограничного шлюза внутри основного Provider VDC. При этом сеть Org VDC net маркируется как shared-сеть, так что и другие Org VDC могут ее использовать. Обратите внимание, что пограничные шлюзы разворачиваются силами сервис-провайдера. Зачастую поставщик устанавливает Edge Gateway в конфигурации с высокой доступностью, что требует создания двух виртуальных машин Edge Gateway в рамках основного Provider VDC. При этом ВМ используют внутреннюю сеть Org VDC для обмена «хартбитами». Чтобы сделать сайт эластичным, выполняется конфигурация vCNS/NSX Edge, где Resource Pool (используется аналогичное имя VDC RP, но на другом кластере) и Datastore меняют на параметры второго экземпляра другого сайта. Таким образом, происходит реконфигурация экземпляра шлюза и на другой площадке.
Пример развертывания пограничного шлюза
Заключение
В этой статье, посвященной дизайну зон доступности в vCloud Director для услуги IaaS, мы рассмотрели сценарий с использованием двух физически разнесенных сайтов и ознакомились с возможностями «растяжения» сети между ними. Этот способ является наглядным примером использования failover-площадки, которая в случае выхода основного сайта из строя гарантирует беспрерывную работу сервиса.
*- Источник Tom Fojta's Blog
