Дизайн зон доступности в vCloud Director

1.jpg

*- Источник Tom Fojta's Blog

Поставщики услуг, располагающие несколькими центрами обработки данных, зачастую предлагают клиентам возможность построения виртуального ЦОД, используя две и более зоны доступности, или availability zone. В таком сценарии сбой одной зоны не оказывает влияния на работоспособность другой. Озвученный метод обеспечивает эластичное развертывание приложений с использованием балансировки нагрузки и кластеризации. При этом заказчик получает доступ к инфраструктуре с помощью vCloud Director, используя удобный для работы GUI или API.

 Дизайн нескольких vCenter Server

Подход, при котором используется один экземпляр vCloud Director и несколько зон доступности, определяет следующие правила: каждая availability zone требует наличия собственного vCenter Server и vCNS Manager. Рисунок ниже показывает, как в контексте двух сайтов представлены зоны доступности, включая кластеры управления и ресурсов.

2.png

Пример с использованием нескольких сайтов

Отметим, что для каждого сайта предусматривается кластер управления. При этом 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 или организуют внешнее сетевое подключение. Все это приводит к достаточно сложной настройке маршрутизации.

3.png

Пример сетевой связности между vDC

Дизайн vCenter Server с «растянутой» сетью организации

Предлагаем рассмотреть альтернативный подход, цель которого заключается в «растяжении» сети организации – назовем ее Org VDC net (shared) – между двумя сайтами при наличии высокодоступного пограничного шлюза (Edge Gateway). Результат, который необходимо получить в итоге, показан на рисунке ниже.

4.png

Пример «растягивания» сети

Для достижения поставленной цели потребуется один экземпляр ресурсной группы 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 расширяется или сужается.

5.png

Редактирование настроек 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 будет иметь доступ к пулу ресурсов другого сайта, за исключением доступа к его хранилищу. Рисунок ниже иллюстрирует вышесказанное.

6.png

Пример «растяжения» 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 меняют на параметры второго экземпляра другого сайта. Таким образом, происходит реконфигурация экземпляра шлюза и на другой площадке.

7.png

Пример развертывания пограничного шлюза

Заключение

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

Опубликовано 28.02.2017 18:12:11 автором E.Yudina в разделе Решения, в разделе Функциональность

/* */

Посетите наш сайт!

IaaS облако IT-GRAD

Подпишитесь на блог!

IaaS для бизнеса по кирпичикам