Как известно, Cross-VC NSX делает возможной мультисайтовость — обеспечивает централизованную вертикальную маршрутизацию между логическими сетями, развернутыми в доменах NSX, и внешней инфраструктурой физической сети.

Преимущества этой возможности ясны с первого взгляда — речь идет о мобильности, распределении рабочей нагрузки, создании пулов ресурсов, централизованного управления и применения политик безопасности в отношении доменов/сайтов vCenter, а также об аварийном восстановлении. Эта статья посвящена не исследованию детальных технических показателей, а легкости и гибкости в плане применения Cross-VC NSX для нескольких сайтов.


В этом примере vCenter, основной NSX Manager и Universal Controller Cluster (UCC) развернуты на сайте 1. Вторичный NSX Manager, зарегистрированный с основным NSX Manager, развернут на сайте 2 с соответствующим vCenter. Рисунок 1

На рисунке 2 показаны NSX Manager-ы с ролями «primary» и «secondary», а также соответствующие UCC-кластеры и взаимосвязи. Universal Controller Cluster развернут из NSX Manager с ролью «primary» на сайте 1 внутри vCenter, к которому прилинкован NSX Manager с ролью «primary».

На основном сайте существует всего 3 универсальных контроллера, которые управляют всеми универсальными и локальными объектами для всех доменов vCenter внутри развертывания Cross-VC NSX. Однако на Рисунке 2 внутри секции «NSX Controllers Node» статус всех контроллеров, относящихся ко всем NSX Managers. Рисунок 2

Как видно на рисунке 3, Universal Controller Cluster развернут в кластере Edge на сайте 1. Рисунок 3

Как только настроена конфигураций NSX, выбраны роли «primary» и «secondary» для NSX Manager, а также развернут UCC, можно начать создавать логические сети, объединяющие разные сайты, с помощью одного нажатия кнопки. Рисунок 4 Если пользователь хочет получить развертывания Active/Active, где активные рабочие нагрузки для одного и того же сегмента находятся на обоих сайтах (конфигурация развертывания с одним сервером высокой доступности), это можно легко сделать с помощью логических интервалов на обоих сайтах. К тому же, поскольку Cross-VC NSX распространяет логические сети и безопасность на все домены vCenter, рабочие нагрузки можно легко перемещать между доменами vCenter через все сайты без каких-либо изменений в IP-адресах или политиках безопасности.

Рисунок 5 показывает применение правил Universal Distributed Firewall к Universal Section. Рисунок 5

Если же пользователь хочет, чтобы только сайт 1 служил выходом для трафика North/South, то это можно сделать с помощью развертывания Universal Control VM, которая находится на уровне управления Universal Distributed Logical Router (UDLR) на основном сайте, а также с использованием маршрутизации «metric/weight» для того, чтобы убедиться что весь трафик North/South проходит через Edge Service Gateways (ESGs) сайта 1.

В этой модели трафик North/South соответствует модели active/passive, где Edge Service Gateways сайта 1 активны, а Edge Service Gateways сайта 2 пассивны в отношении трафика North/South.

Существование единственного сайта в точке Ingress/Egress для трафика North/South упрощает процесс развертывания и осуществления дальнейших действий и может потребоваться для тех случаев, когда службы отслеживания используют трафик North/South и необходимо избежать ассиметричных потоков трафика. Пример такого развертывания показан ниже.
 Рисунок 6

Если пользователю необходимы потоки трафика Active/Active North/South и его не беспокоит ассиметричность потоков трафика, либо у него есть какое-то решение по контролированию входящего трафика, то для обеспечения потока трафика North/South, специфичного для конкретного сайта, может использоваться функция Local Egress. Она активируется при создании UDLR.

Local Egress позволяет контролировать, какие маршруты предоставляются для хостов ESXi, на основе уникального идентификатора, так называемого Locale ID. Все хосты внутри домена NSX Manager имеют один и тот же Locale ID; по умолчанию это UUID NSX Manager-а локального сайта.

Universal Control VM на каждом сайте изучает маршруты от физической сети через ESG локального сайта. Затем UCC изучает лучшие маршруты с сопутствующим Locale ID от Universal Control VM каждого сайта. Наконец, UCC распространяет информацию о лучших маршрутах на хосты ESXi с соответствующими Locale ID. Такое развертывание с использованием Local Egress показано ниже. Отметим, что в этой модели развертывания Universal Control VM присутствует на каждом сайте. Рисунок 7 Как видно, Cross-VC NSX обеспечивает гибкость и возможности для множественных развертываний. По факту, таким образом можно развертывать инфраструктуру NSX для нескольких пользователей, при том, что некоторые пользователи будут использовать схему Active/Passive, а другие — Active/Active. Такое развертывание показано ниже: Пользователь 1 и Пользователь 2 используют один и тот же UDLR и единственную Universal Control VM со схемой Active/Passive. Пользователь 3 использует другой UDLR с Local Egress и, соответственно, другую Universal Control VM для сайта 1 и сайта 2; это делает возможной схему Active/Active. В этом случае IP-адреса пользователей не пересекаются. Отдельные UDLR и ESG также могут быть использованы для каждого пользователя, если требуется наложение IP-адресов или дополнительная изоляция. Рисунок 8 Корпоративный облачный провайдер