В статье ниже рассказано о том, как можно использовать API платформы VMware Cloud Foundation (VCF) для расширения кластера между стойками без расширения уровня L2 в физической сети.
Обзор
Расширение кластера на хосты в разных стойках служит двум ключевым целям: увеличению емкости вычислительных мощностей и хранилищ, а также повышению устойчивости для рабочих нагрузок. Серверы в одной стойке часто имеют общую инфраструктуру питания и сети, что делает их уязвимыми к одновременному отказу.
В VMware Cloud Foundation (VCF) добавление хостов в кластер выполняется просто, когда новые хосты находятся в той же подсети, что и существующие. Однако современные конструкции центров обработки данных не поощряют расширение L2 между стойками из-за широкого влияния локальных сбоев в традиционных сетях L2. Вместо этого предпочтительны небольшие широковещательные домены L2, обычно ограниченные отдельными стойками, что означает, что хосты в отдельных стойках работают в разных подсетях.
Хотя такие технологии, как EVPN over VXLAN, позволяют безопасно расширять подсети по стойкам, они в значительной степени зависят от конфигурации физической инфраструктуры. Такая зависимость может препятствовать автоматизации и ставить под угрозу бесперебойный облачный опыт, ожидаемый в средах VCF.
Давайте рассмотрим сценарии, в которых расширение кластера достижимо без необходимости расширения L2, а также объяснение того, как этого добиться — спойлер: это делается через API.
Типы сетей и кластеров VCF
В среде VCF хост ESXi подключен к нескольким сетям, которые видны VCF. Их можно разделить на две категории: сети виртуальных машин и сети инфраструктуры хоста.
Сети виртуальных машин
Эти сети соединяют виртуальные машины, критически важные для инфраструктуры VCF, такие как SDDC Manager, серверы vCenter, менеджеры NSX и другие.
Сеть управления виртуальными машинами - она обеспечивает подключения к управлению инфраструктурными виртуальными машинами. На вершине этой сети находятся кластеры, хостящие NSX Edge. Виртуальная машина NSX Edge обычно запускает шлюз уровня Tier-0, который действует как виртуальный маршрутизатор, связывающий виртуальную сеть NSX с физической сетью. Хотя здесь не рассматриваются подробности кластеров с виртуальными машинами NSX Edge, важно отметить, что для шлюза уровня Tier-0 требуются следующие элементы:
Сеть Edge TEP: конечные точки туннеля (tunnel end points, TEP) периферии используют эту сеть для подключения к сегментам NSX.
Сети Edge Uplink: предоставляют VLAN для подключения шлюза Tier-0 к физическим маршрутизаторам.
Все эти сети должны расширяться между стойками для поддержки мобильности ВМ в целях обеспечения высокой доступности. Машины должны сохранять свои IP-адреса во время динамических переходов между стойками. Поскольку пограничные кластеры VCF всегда включают сеть управления ВМ (поверх их конкретных пограничных сетей TEP/uplinks), общим знаменателем для всех кластеров, требующих расширения L2 между стойками, является наличие сети управления ВМ.
Сети инфраструктуры хоста ESXi
Эти сети соединяют интерфейсы vmkernel хостов ESXi.
Сеть управления (Management Network): используется для управления хостом ESXi.
Сети vMotion и vSAN: определяются совместно в сетевом пуле VCF и используются функциями vMotion и vSAN.
Сеть хостов TEP: TEP хостов ESXi используют эту сеть для реализации сегментов NSX.
Эти сети технически не требуют расширения по стойкам, поскольку сами хосты ESXi являются физическими устройствами с фиксированными IP-адресами, привязанными к их расположению в стойках. Однако конфигурация VCF потребует охвата этих сетей по стойкам, если расширяемый кластер включает сеть управления ВМ. Отдельной конфигурацией является растянутый кластер vSAN (stretched cluster), выходящий за рамки этой статьи.
Определение типа расширения кластера
Только кластеры без сети управления ВМ могут быть расширены по стойкам без необходимости расширения L2 в физической инфраструктуре. Чтобы проверить, есть ли у кластера сеть управления ВМ, перейдите в Workload Domains ? Clusters ? Network в пользовательском интерфейсе SDDC Manager. На снимке экрана ниже сеть управления VM выделена красным цветом для Edge-кластера:
Расширение по стойкам кластера без сети управления виртуальными машинами
Несколько слов о пользовательском интерфейсе
Пользовательский интерфейс не поддерживает выбор хостов из другого сетевого пула или указание сети TEP хоста во время расширения, что делает необходимым расширение L2 в физической сети.
Метод API, описанный в следующем разделе, представляет собой единственное работающее на практике решение для расширения кластера по стойкам без необходимости расширения L2.
Расширение через API
Кластер можно расширить на другую стойку без необходимости расширения L2 в физической инфраструктуре, если в VCF не определена сеть управления виртуальными машинами, а расширение выполняется через API.
На схеме ниже показан кластер, изначально ограниченный стойкой 1, расширенный за счет включения хостов в стойке 2. В этой настройке сетевой пул, сеть TEP хоста и сеть управления хостом являются отдельными.
Обратите внимание также, что рабочие виртуальные машины по-прежнему могут использовать подсети, охватывающие стойки (одна такая сеть представлена ??зеленым цветом). Это расширение предоставляется NSX и не зависит от конфигурации физической сети, что позволяет достичь желаемого результата.
Сетевые пулы назначаются хостам во время подготовки, а VCF игнорирует сеть управления хостом. Основная сложность заключается в настройке сети Host TEP во время расширения кластера по стойкам. Пример ниже поясняет процесс.
Пример расширения кластера API
В этом разделе описывается процесс расширения «Lab-cluster» для включения хоста в новую стойку.
Начальная настройка:
«Lab-cluster» изначально состоит из трех хостов (new0.corp.vmbeans.com, new1.corp.vmbeans.com и new2.corp.vmbeans.com) в стойке rack1. Четвертый хост, new3.corp.vmbeans.com в стойке rack2, добавляется через API.
Инфраструктурные сети:
Управление хостом: rack1 и rack2 используют разные сети управления хостом, которыми VCF не управляет и не требует их соответствия.
Сетевые пулы: существующие хосты используют «Network-pool-rack1», в то время как new3.corp.vmbeans.com развернут с сетью «Network-pool-rack2», это подразумевает различные сети vSAN и vMotion.
Host TEP Network: все текущие хосты в кластере совместно используют одну и ту же хостовую сеть TEP, управляемую с помощью Transport Node Profile (TNP) в NSX. Поскольку новый хост в rack2 не может использовать конфигурацию TEP, специфичную для rack1, VCF должен создать sub-TNP с хостовой сетью TEP, специфичной для rack2.
На диаграмме ниже представлено обобщенное представление этого лабораторного сценария:
Чтобы добавить new3.corp.vmbeans.com в существующий «Lab-cluster», выполните следующие действия:
Получите идентификатор кластера. Используйте следующий вызов API, чтобы получить идентификатор «Lab-cluster»:
GET /v1/clusters
Проверьте входную спецификацию для вызова API
POST /v1/clusters/{cluster ID}/validations
- Используйте идентификатор кластера, полученный на предыдущем шаге
- Тело этого вызова - это тело, представленное в нижней части этого раздела, инкапсулированное в «clusterUpdateSpec»: { <body> }
Тело запроса API для этой операции подробно описано ниже:
{
«clusterExpansionSpec»: {
«hostSpecs»: [
{
"id": "2a1c3eec-2b16-41bc-9b10-825e1343f22e",
Идентификатор ссылается на хост new3.corp.vmbeans.com в rack2, добавляемый в кластер. Сетевой пул был назначен во время ввода в эксплуатацию в VCF, поэтому этот шаг настраивает только параметры NSX, специфичные для его TEP. Хотя этот пример добавляет один хост, в один вызов API могут быть включены несколько хостов.
"licenseKey": "xxx",
LicenseKey: лицензионный ключ для хоста, который также можно применить непосредственно на хосте.
Профиль сети NSX определяет конфигурацию сети TEP. Для этого расширения в этом вызове API создается новый профиль сети, alternate-network-profile, для использования другой сети TEP.
"networkSpec": {
"nsxClusterSpec": {
"ipAddressPoolsSpec": [
{
"name": "alternate-address-pool",
"description": "different IP pool for rack2",
Rack2 использует другую подсеть для своих инфраструктурных сетей, требуя от хостовых TEP использовать отдельный пул IP NSX. В этом вызове API для этой цели определяется новый пул IP, alternate-address-pool.
Мы определяем профиль аплинков для новой стойки.
Профиль аплинков NSX определяет имена, их политику объединения и, наконец, транспортную VLAN (то есть идентификатор VLAN, используемый для трафика TEP).
Нет необходимости создавать другие имена аплинков NSX или политику объединения для хоста, который мы добавляем в rack2. Мы создаем новый профиль аплинков, потому что хотим использовать другой идентификатор VLAN для трафика NSX на rack2. Если бы мы хотели сохранить в rack2 тот же идентификатор VLAN, что и для rack1 (обратите внимание, что тот же идентификатор VLAN не означает ту же VLAN), мы могли бы использовать существующий профиль аплинка для rack1.
Определение двух аплинков для трафика NSX: nsx-uplink-1 и nsx-uplink-2. Это просто имена (мы могли бы использовать здесь любую строку символов), используемые при определении политики объединения по умолчанию типа «ID исходного порта балансировки нагрузки».
В конечном итоге аплинки NSX будут сопоставлены с аплинками VDS.
"transportVlan": 243
}
]
},
Как было отмечено ранее, идентификатор VLAN для трафика TEP отличается в rack2 по сравнению с rack1.
Сетевой профиль, указанный в разделе «hostSpecs», определяет все специфичные для NSX детали, необходимые для настройки NSX на хосте. Он включает:
– Профиль аплинков.
– Ранее определенный пул IP (обратите внимание, что DHCP также поддерживается, просто оставьте ipAddressPoolName пустым в этом случае.)
– Связи между аплинками NSX и аплинками VDS.
В NSX эта информация представлена ??как профиль транспортного узла (TNP), шаблон для идентичной настройки нескольких хостов в кластере. Новый сетевой профиль, созданный с помощью этого API, отличается от того, который использовался в rack1, что не позволяет использовать согласованный TNP во всем кластере. В результате VCF создает «sub-TNP» для «alternate-network-profile» и применяет его к «sub-cluster», группируя хосты в rack2. Подкластер назван в честь нового сетевого профиля VCF.
При выполнении этого вызова API, узел new3.corp.vmbeans.com добавляется в кластер Lab-cluster. Поскольку новый хост использует другой сетевой пул, отличный от исходного кластера, VCF автоматически создает новые распределенные порты VDS (dvpgs) для сетей vSAN и vMotion, как показано на скриншоте ниже.
Детали сети TEP хоста не отображаются напрямую в VCF, но их можно просмотреть через NSX Manager. На скриншоте ниже показан «alternate-uplink-profile», настроенный VCF для нового хоста в стойке rack2:
На скриншоте ниже показана конфигурация кластера "Lab-cluster" в NSX. К кластеру привязан TNP (Transport Node Profile) с именем "vcenter-vi1-paris-Lab-cluster", а для недавно добавленного хоста (new3.corp.vmbeans.com) назначен sub-TNP под названием "alternate-network-profile". Этот sub-TNP, разумеется, применяет конфигурацию, заданную в части сетевого профиля вызова API.
RSS
