Vmware nsx t настройка

Обновлено: 03.07.2024

В этой статье я опишу как развертывать NSX-T Manager, его особенности, требования и ограничения. Далее рассмотрим, как собрать Manager Cluster для отказоустойчивости наших NSX Manager-ов и познакомимся с интерфейсом панели управления. Поехали.

Установка NSX Manager

Теперь о размерах развертывания, их несколько.

Форм Фактор	Кол-во vCPU	Память GB	HDD GB	Ограничения
Extra Small	2	8	300	Только для Cloud Service Manager
Small	4	16	300	Для лаб
Medium	6	24	300	До 64 гипервизоров
Large	12	48	300	Более 64 гипервизоров

Далее идет совсем нехитрая процедура деплоя нашего шаблона в vSphere, повторюсь, развернуть NSX Manager можно и на KVM, для этого на странице загрузки нужно выбрать другой формат. Да, стоить не забывать, что перед развертыванием нужно внести запись DNS.

По классике мы задаем кластер, хост, сеть и хранилище нашему будущему Manager-y. Так же потребуется сконфигурировать специфические настройки.

В первой секции мы заполняем логины и пароли для административных учетных записей в том числе и для root и admin, который и будет являться учетной записью по умолчанию для администрирования NSX. Дальше у нас следует Network Properties – настройки сети для аплайнса. Тут все просто – IP, mask, gateway, hostname. Но есть кое-что, это выбор роли развертываемого.

Мы останавливаемся на NSX Manager, nsx-cloud-service-manager потребуется если мы разворачиваем NSX-T в подходящем для этого публичном облаке, а NSX Global Manager – для создания NSX-T Federation, но эти два пункта за пределами наших статей. Дальше у нас идут настройки DNS, NTP и последняя графа Internal Properties, ее не трогаем. Переходим к Ready to complete и жмем Finish. Начинается процесс развертывания нашего NSX Manager, он будет продолжительным, потому что OVA немаленького размера, а мы пока можем пойти за кофе.

После окончания процесса, NSX Manager доступен в браузере, и мы можем залогинимся под учеткой admin.

Развертывание NSX Manager Cluster

Что ж NSX Manager мы развернули теперь рассмотрим, как организовать ему отказоустойчивость. Как было написано в предыдущем посте, отказоустойчивость NSX Manager-а обеспечивается кластером. Кластер может состоять из максимум трех участников, это такие же NSX Manager-ы разнесенные по разным гипервизорам для исключения потери функционала в связи с падением одного физического хоста. Развертывание трехнодового кластера настоятельно рекомендуется для Production инфраструктуры, если у вас лаба или тестовая инфраструктура, то кластер можно и не создавать. Размещать ноды NSX Manager Cluster-а можно как в одном vSphere кластере, естественно настроив anty-affinity правила DRS, так и на одиночные хосты, главное что б на разные.

Теперь про Виртуальный IP кластера (VIP). Это адрес, который назначается кластеру и на него отвечает активная нода, затем она перенаправляет запросы соответствующим модулям на других нодах. Если активный NSX Manager по какой-то причине становиться недоступен, активной становиться другая нода и работа продолжается. Использование VIP допускается если все участники кластера расположены в одной подсети.

Как показано на картинке, VIP можно назначить на сетевой балансироващик и спрятать NSX Manager-ы за него. Для этого может быть использован сторонний балансировщик, но не NSX, например, NetScaler. Конфигурация с балансировщиком добавляет несколько плюшек в дизайн:

NSX Manager-ы могут находиться в разных подсетях (без балансировщика только в одной подсети)
Сетевая нагрузка распределяется равномерно по всем NSX manager-ам (без балансировщика, нагрузка ложиться на одну активную ноду)
Более быстрое восстановление доступности служб Manager-а после сбоя для пользователя (без балансировщика восстановление доступности занимает 1-3 минуты)

При использовании балансировщика, VIP настраивается на нем, в NSX Manager-е виртуальный IP адрес не прописывается.

Перейдем к развертыванию самого кластера. Заходим на наш первый и пока что единственный NSX Manager, переходим во вкладку System, выбираем Appliances и нажимаем Add NSX Appliance.

Откроется окно для настройки сетевой конфигурации и выбора размера будущего члена кластера.

Затем выбираем куда мы поместим второй NSX Manager, то есть ресурсы для него.

Ну и учетные данные пользователя root.

Административная учетная запись admin наследуется с первого NSX Manager-а и тут соответственно про нее ничего у нас не спрашивают. Далее нажимаем Install Appliance и идем за кофе.

Через некоторое время второй NSX Manager успешно развернут, а мы напились кофе.

Мы можем залогиниться на него с той же самой учеткой admin. Для администратора не будет никакой разницы с какой ноды производить управление, все объекты NSX-T будут консистентны в пределах двух Manager-ов. Таким же способом можем развернуть и третий NSX manager.

Круто, теперь черед для VIP. Настроить его можно в том же самом разделе. В его настройке нет ничего особенного, просто прописываем его в соответствующем окне.

Имейте ввиду, что NSX Manager-ы должны быть в одной подсети для использования VIP, только использование стороннего балансировщика даст нам возможность поместить ноды в разные подсети.

Задаем наш VIP, ждем какое-то время и вуаля.

Настроен VIP, и он назначен одной из нод, в нашем случае это нода, которую разворачивали первой. Теперь для проверки подключимся к VIP из браузера и нам ответит активная нода. Для удобства можно настроить в DNS A запись для VIP, к примеру, nsx-mngr-vip, в то время пока на нодах настроены nsx-mngr-01,nsx-mngr-02 и так далее. Стоит отметить что после настройки виртуального IP вы так же можете продолжать подключаться к каждому NSX Manager-у в кластере по отдельности.

На этом все, в итоге мы имеем рабочий NSX Manager Cluster с общим IP адресом и отказоустойчивостью.

Что бы удалить или изменить VIP, залогиньтесь на любой NSX Manager в кластере, используя его персональный адрес и произведите операцию на нем. Редактирование виртуального IP недоступно, если вы зашли на NSX Manager Cluster используя VIP.
Если вы потеряете два NSX Manager-а из трех в кластере, то до их восстановления вы не сможете делать изменения топологии NSX а также vMotion машин, зависящих от NSX будет неуспешным, так как процесс Control Plane распределен по всем трем нодам, большая часть из которых будет недоступной.

Знакомство с Inventory

Мы закончили с развертыванием NSX Manager-а, теперь настало время немного расслабиться и ознакомиться с интерфейсом управления NSX-T. Интерфейс покажется очень «насыщенным» по сравнению с NSX-V и сложным. Но стоит попользоваться им некоторое время, и он становиться настолько удобным и знакомым, что начинаешь мысленно хвалить UX-дизайнеров VMware. Итак, после логина в NSX мы видим это:

Куча всевозможных кнопочек и объектов. Но для начала нам нужно выделить для себя шесть верхних вкладок:

Home
Networking
Security
Inventory
Plan & Troubleshoot
System

Каждый из них является точкой управления с интуитивно понятным смыслом. Опишем вкратце каждый из них.

System

На этапе внедрения и развертывания NSX-T в этой секции мы будем проводить больше всего времени. Тут управляем пользователями, их привилегиями, резервным копированием, лицензиями, апгрейдами, дополнительными NSX Manager-ами (которые в кластере) и что самое интересное и важное нашей фабрикой (Fabric).

Fabric – это раздел, где мы управляем добавлением и настройкой наших Транспортных Нод и созданием Транспортных Зон. То есть строим нашу инфраструктуру NSX с «физической» перспективы. Но это все впереди.

Networking

Security

Да, вы уже поняли про что это. Данный раздел ответственен за все что про безопасность в NSX-T.

Тут, как и во всем интерфейсе много всего, но стоит выделить две секции:

East West Security
North South Security

Так вот эти две секции в разделе Security соответствуют настройкам файрволлов, которые обрабатывают эти два типа траффика. Это распределенный файрволл и пограничный. Но о них в дальнейших статьях.

Inventory

Тут мы создаем различные административные объекты, например, собираем VM в группы, чтобы потом назначать на эти группы различные политики и правила брандмауэра, создаем профили сервисов, что бы NSX мог их различать в трафике, например, трафик FTP. И так далее.

Plan & Troubleshoot

Тут разместились превосходные инструменты для анализа и траблшутинга нашей виртуальной сети. Port Mirroring, TraceFlow и так далее. Особое внимание хочу уделить TraceFlow. Это инструмент, который может продиагностировать сетевую доступность между некоторыми объектами в нашей виртуальной сети NSX.

При логине мы попадаем сюда. Это Summary нашего NSX-T. Тут мы видим общие сведения сколько и чего у нас есть в инфраструктуре, панель мониторинга и алармы. Присутствует очень удобная строка поиска по объектам NSX. В принципе все.

Стоит так же упомянуть про профиль отображения – policy/manager. В предыдущем посте я упоминал его. Как говорилось ранее, у нас есть Policy и Management Plane. Policy Plane оперирует более понятными пользователю объектами, например сегменты (L2 домены), ротуеры. В то время как Management Plane смотрит на эти вещи как на более технические в контексте NSX – Logical Switch (тот же L2 домен), Logical Router и так далее. Наш интерфейс поддерживает оба представления. По умолчанию нам доступен только policy mode, он более простой в понимании для администратора и содержит в некоторых секциях больше функций. Но мы можем переключиться на manager mode. Для этого нужно зайти в System> User Interface Settings> Edit и настроить возможность переключения профиля отображения для всех пользователей или только для тех, у кого роль Enterprise Admin. Там же можно задать режим отображения по умолчанию. После этого у нас под панелью пользователя появиться переключатель режима отображения.

Переключение работает в пределах секции, в которой вы работаете, например, в Network. После того как возможность переключения policy/manager доступна, каждая секция в зависимости от выбранного режима может предстать перед пользователем в несколько ином свете. Для меня больше удобен режим policy, он более понятно представляет некоторые объекты. Перечислять разницу этих режимов вне темы этого топика, нужно сказать только что некоторые вещи мы можем сконфигурировать только из одно режима.

Мы развернули NSX Manager, настроили NSX Manager Cluster для отказоустойчивости и назначили ему виртуальный IP. На этом все.

После развертывания Решения Azure VMware можно настроить сегмент сети NSX-T с помощью NSX-T Manager или портала Azure. После настройки сегменты отображаются в Решении Azure VMware, NSX-T Manger и vCenter. В NSX-T по умолчанию имеется шлюз NSX-T уровня 0 в режиме Активный/активный и шлюз NSX-T уровня 1 по умолчанию в режиме Активный/резервный. Эти шлюзы позволяют подключать сегменты (логические коммутаторы) и обеспечивать горизонтальные и вертикальные подключения.

Портал Azure предлагает упрощенное представление необходимых администратору VMware регулярно операций NSX-T, которое предназначено для пользователей, не знакомых с NSX-T Manager.

В этом руководстве описано следующее:

Добавление сегментов сети с помощью NSX-T Manager или портала Azure.
Проверка нового сегмента сети.

Предварительные требования

Частное облако Решения Azure VMware с доступом к интерфейсам vCenter и NSX-T Manager. Дополнительные сведения см. в статье о конфигурации сети.

Использование NSX-T Manager для добавления сегмента сети

Виртуальные машины, созданные в vCenter, помещаются в сегменты сети, созданные в NSX-T, и они видимы в vCenter.

В NSX-T Networking > Segments (Manager > Сеть > Сегменты), а затем выберите Add Segment (Добавить сегмент).

Введите имя сегмента.

Выберите шлюз уровня 1 (TNTxx-T1) в качестве подключенного шлюза и оставьте значение Flexible (Гибкий) в поле Type (Тип).

Выберите предварительно настроенную зону транспортировки для наложения (TNTxx-OVERLAY-TZ), а затем выберите Set Subnets (Задать подсети).

Введите IP-адрес шлюза и выберите элемент Добавить.

IP-адрес должен находиться в неперекрывающемся блоке адресов RFC1918, что обеспечит подключение к виртуальным машинам в новом сегменте.

Выберите No (Нет), чтобы отказаться от дальнейшей настройки сегмента.

Добавление сегмента NSX-T с помощью портала Azure

Если вы планируете использовать DHCP, необходимо настроить DHCP-сервер или ретранслятор DHCP, и только затем настроить сегмент сети NSX-T.

В частном облаке Решения Azure VMware в разделе Сетевые подключения рабочей нагрузки выберите Сегменты > Добавить.

Укажите сведения о новом логическом сегменте и нажмите кнопку ОК.

Имя сегмента — имя сегмента, который отображается в vCenter.

Шлюз подсети — IP-адрес шлюза для подсети сегмента с маской подсети. Виртуальные машины подключаются к логическому сегменту, а все виртуальные машины, подключенные к этому сегменту, принадлежат к одной подсети. Кроме того, все виртуальные машины, подключенные к этому логическому сегменту, должны иметь IP-адрес из того же сегмента.

DHCP (необязательно) — диапазоны DHCP для логического сегмента. DHCP-сервер или ретранслятор DHCP должен быть настроен для использования DHCP в сегментах.

Подключенный шлюз выбран по умолчанию и доступен только для чтения. Отображается шлюз уровня 1 и тип сведений о сегменте.

T1 — имя шлюза уровня 1 в NSX-T Manager. В частном облаке имеется шлюз NSX-T уровня 0 в режиме "Активный/активный" и шлюз NSX-T уровня 1 по умолчанию в режиме "Активный/резервный". Сегменты, созданные с помощью консоли Решения Azure VMware, подключаются только к шлюзу уровня 1 по умолчанию, а рабочие нагрузки этих сегментов получают возможность устанавливать подключения в горизонтальном и вертикальном направлении. С помощью NSX-T Manager можно создавать только шлюзы уровня 1. Шлюзы уровня 1, созданные из консоли NSX-T Manager, не отображаются в консоли Решения Azure VMware.

Тип ― сегмент наложения, поддерживаемый Решением Azure VMware.

После этого сегмент отображается в Решении Azure VMware, NSX-T Manger и vCenter.

Проверка нового сегмента сети.

Убедитесь в наличии нового сегмента сети. В этом примере новый сегмент сети — это ls01.

В NSX-T Manager выберите Networking > Segments (Сеть > Сегменты).

В vCenter выберите Networking > SDDC-Datacenter (Сеть > Центр обработки данных SDDC).

Дальнейшие действия

В рамках этого руководства вы создали сегмент сети NSX-T, который будет использоваться для виртуальных машин в vCenter.

Заключительная большая часть про настройку VPN IPsec, L2 VPN, SSL VPN-Plus.

Сегодня мы посмотрим на возможности настройки VPN, которые предлагает нам NSX Edge.

В целом мы можем разделить VPN-технологии на два ключевых вида:

Site-to-site VPN. Чаще всего используется IPSec для создания защищенного туннеля, например, между сетью главного офиса и сетью на удаленной площадке или в облаке.
Remote Access VPN. Используется для подключения отдельных пользователей к частным сетям организаций с помощью ПО VPN-клиента.

NSX Edge позволяет нам использовать оба варианта.

Настройку будем производить с помощью тестового стенда с двумя NSX Edge, Linux-сервера с установленным демоном racoon и ноутбука с Windows для тестирования Remote Access VPN.

IPsec

В интерфейсе vCloud Director переходим в раздел Administration и выделяем vDC. На вкладке Edge Gateways выбираем нужный нам Edge, кликаем правой кнопкой и выбираем Edge Gateway Services.

Enabled – активирует удаленную площадку.
PFS – гарантирует, что каждый новый криптографический ключ не связан с любым предыдущим ключом.
Local ID и Local Endpoint – внешний адрес NSX Edge.
Local Subnets – локальные сети, которые будут использовать IPsec VPN.
Peer ID и Peer Endpoint – адрес удаленной площадки.
Peer Subnets – сети, которые будут использовать IPsec VPN на удаленной стороне.
Encryption Algorithm – алгоритм шифрования туннеля.

Authentication – как мы будем аутентифицировать пир. Можно использовать Pre-Shared Key либо сертификат.
Pre-Shared Key – указываем ключ, который будет использоваться для аутентификации и должен совпадать с обеих сторон.
Diffie-Hellman Group – алгоритм обмена ключами.

После заполнения необходимых полей нажимаем Keep.

--- 192.168.0.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 59.941/59.941/59.941/0.000 ms

log debug;
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

listen isakmp 80.211.43.73 [500];
strict_address;
>

remote 185.148.83.16 exchange_mode main,aggressive;
proposal encryption_algorithm aes256;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1536;
>
generate_policy on;
>

sainfo address 10.255.255.0/24 any address 192.168.0.0/24 any encryption_algorithm aes256;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
>

spdadd 192.168.0.0/24 10.255.255.0/24 any -P in ipsec
esp/tunnel/185.148.83.16-80.211.43.73/require;

spdadd 10.255.255.0/24 192.168.0.0/24 any -P out ipsec
esp/tunnel/80.211.43.73-185.148.83.16/require;

В этом примере мы использовали PSK для аутентификации пира, но возможен также вариант с аутентификацией по сертификатам. Для этого нужно перейти во вкладку Global Configuration, включить аутентификацию по сертификатам и выбрать сам сертификат.

Кроме того, в настройках сайта необходимо будет поменять метод аутентификации.

Отмечу, что количество IPsec-туннелей зависит от размера развернутого Edge Gateway (об этом читайте в нашей первой статье).

SSL VPN

SSL VPN-Plus – один из вариантов Remote Access VPN. Он позволяет отдельным удаленным пользователям безопасно подключаться к частным сетям, находящимся за шлюзом NSX Edge. Зашифрованный туннель в случае SSL VPN-plus устанавливается между клиентом (Windows, Linux, Mac) и NSX Edge.

Здесь же можно изменить сертификат, который будет использовать сервер.

Переходим во вкладку IP Pools и жмем +.

Network — локальная сеть, к которой будет доступ у удаленных пользователей.
Send traffic, у него два варианта:

— over tunnel – отправлять трафик к сети через туннель,

— bypass tunnel – отправлять трафик к сети напрямую в обход туннеля.

Ниже в этом окне можно указать параметры клиента для Windows. Выбираем:

start client on logon – VPN-клиент будет добавлен в автозагрузку на удаленной машине;
create desktop icon – создаст иконку VPN-клиента на рабочем столе;
server security certificate validation – будет валидировать сертификат сервера при подключении.

Настройка сервера завершена.

В окне авторизации необходимо ввести учетные данные пользователя, которого мы создали ранее.

L2 VPN

L2VPN понадобится в том случае, когда нужно объединить несколько географически распределенных сетей в один broadcast-домен.

Это может быть полезно, например, при миграции виртуальной машины: при переезде ВМ на другую географическую площадку машина сохранит настройки IP-адресации и не потеряет связность с другими машинами, находящимися в одном L2-домене с ней.

В нашей тестовой среде соединим друг с другом две площадки, назовем их, соответственно, A и B. У нас есть два NSX и две одинаково созданные маршрутизируемые сети, привязанные к разным Edge. Машина A имеет адрес 10.10.10.250/24, машина B – 10.10.10.2/24.

Возвращаемся в интерфейс NSx Edge/ Переходим на вкладку VPN —> L2VPN. Включаем L2VPN, выбираем режим работы Server, в настройках Server Global указываем внешний IP-адрес NSX, на котором будет слушаться порт для туннеля. По умолчанию, сокет откроется на 443 порту, но его можно поменять. Не забываем выбрать настройки шифрования для будущего туннеля.

В Egress Optimization Gateway Address задаем адрес шлюза. Это нужно для того, чтобы не происходил конфликт IP-адресов, ведь шлюз у наших сетей имеет один и тот же адрес. После чего нажимаем на кнопку SELECT SUB-INTERFACES.

Заходим на NSX стороны B, переходим в VPN —> L2VPN, включаем L2VPN, устанавливаем L2VPN mode в клиентский режим работы. На вкладке Client Global задаем адрес и порт NSX A, который мы указывали ранее как Listening IP и Port на серверной стороне. Также необходимо выставить одинаковые настройки шифрования, чтобы они согласовались при поднятии туннеля.

Проматываем ниже, выбираем сабинтерфейс, через который будет строиться туннель для L2VPN.

В Egress Optimization Gateway Address задаем адрес шлюза. Задаем user-id и пароль. Выбираем сабинтерфейс и не забываем сохранить настройки.

На этом про VPN на NSX Edge у меня все. Спрашивайте, если что-то осталось непонятным. Также это последняя часть из серии статей по работе с NSX Edge. Надеемся, они были полезны :)

В прошлый раз мы говорили о возможностях NSX Edge в разрезе статической и динамической маршрутизации, а сегодня будем разбираться с балансировщиком.

Прежде чем приступить к настройке, я хотел бы совсем кратко напомнить об основных видах балансировки.

Теория

Все сегодняшние решения по балансировке полезной нагрузки чаще всего делят на две категории: балансировка на четвертом (транспортном) и седьмом (прикладном) уровнях модели OSI. Модель OSI не самая лучшая референтная точка при описании методов балансировки. Например, если L4-балансировщик также поддерживает терминирование TLS, становится ли он в таком случае L7-балансировщиком? Но что есть, то есть.

Режим прокси, или one-arm. В этом режиме NSX Edge при отправке запроса на один из бэкендов использует свой IP-адрес в качестве адреса источника. Таким образом, балансировщик выполняет одновременно функции Source и Destination NAT. Бэкенд видит весь трафик как отправленный с балансировщика и отвечает ему напрямую. В такой схеме балансировщик должен быть в одном сетевом сегменте с внутренними серверами.

Вот как это происходит:

Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
Edge выполняет source NAT, заменяя адрес отправившего запрос пользователя на свой собственный.
Пакет отправляется к выбранному бэкенду.
Бэкенд отвечает не напрямую пользователю, а Edge, так как изначальный адрес пользователя был изменен на адрес балансировщика.
Edge передает ответ сервера пользователю.

Прозрачный, или inline, режим. В этом сценарии балансировщик имеет интерфейсы во внутренней и внешней сети. При этом ко внутренней сети нет прямого доступа из внешней. Встроенный балансировщик нагрузки действует как шлюз NAT для виртуальных машин во внутренней сети.

Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
Пакет отправляется к выбранному бэкенду.
Бэкенд получает запрос с изначальным адресом пользователя (source NAT не выполнялся) и отвечает ему напрямую.
Трафик снова принимается балансировщиком нагрузки, так как в inline схеме он обычно выступает в качестве шлюза по умолчанию для фермы серверов.
Edge выполняет source NAT для отправки трафика пользователю, используя свой VIP в качестве source IP-адреса.

Практика

Генерируем SSL-сертификат, который будет использовать NSX Edge

Вы можете импортировать валидный CA-сертификат или использовать самоподписанный. В этом тесте я воспользуюсь самоподписанным.

Настраиваем Application Profile

Application profiles дают более полный контроль над сетевым трафиком и делают управление им простым и эффективным. С их помощью можно определять поведение для конкретных типов трафика.

Persistence – сохраняет и отслеживает данные сеанса, например: какой конкретный сервер из пула обслуживает пользовательский запрос. Это позволяет гарантировать, что запросы пользователя направляются одному и тому же члену пула в течение всей жизни сеанса или последующих сеансов.

Enable SSL passthrough – при выборе этой опции NSX Edge перестает терминировать SSL. Вместо этого терминация происходит непосредственно на серверах, для которых выполняется балансировка.

Создаем пул серверов, трафик к которым будет балансироваться Pools

Если опция выключена, трафик для внутренних серверов идет с source IP балансировщика.
Если опция включена, внутренние сервера видят source IP клиентов. В такой конфигурации NSX Edge должен выступать в качестве шлюза по умолчанию, чтобы гарантировать, что возвращаемые пакеты проходят через NSX Edge.

Здесь нужно указать:

имя сервера;
IP-адрес сервера;
порт, на который сервер будет получать трафик;
порт для health check (Monitor healthcheck);
вес (Weight) – с помощью этого параметра можно регулировать пропорциональное количество получаемого трафика для конкретного члена пула;
Max Connections – максимальное количество соединений к серверу;
Min Connections – минимальное количество соединений, которое должен обработать сервер, прежде чем трафик будет перенаправлен следующему члену пула.

Вот так выглядит итоговый пул из трех серверов.

Добавляем Virtual Server

Connection Limit – максимальное количество одновременных соединений, которые может обработать виртуальный сервер;
Connection Rate Limit (CPS) – максимальное количество новых входящих запросов в секунду.

На этом конфигурация балансировщика завершена, можно проверить его работоспособность. Сервера имеют простейшую конфигурацию, позволяющую понять, каким именно сервером из пула был обработан запрос. Во время настройки мы выбрали алгоритм балансировки Round Robin, а параметр Weight для каждого сервера равен единице, поэтому каждый следующий запрос будет обрабатываться следующим сервером из пула.

Вводим в браузере внешний адрес балансировщика и видим:

После обновления страницы запрос будет обработан следующим сервером:

И еще раз – чтобы проверить и третий сервер из пула:

При проверке можно видеть, что сертификат, который отправляет нам Edge, тот самый, что мы генерировали в самом начале.

Проверка статуса балансировщика из консоли Edge gateway. Для этого введите show service loadbalancer pool.

Настраиваем Service Monitor для проверки состояния серверов в пуле

С помощью Service Monitor мы можем отслеживать состояние серверов в бэкенд пуле. Если ответ на запрос не соответствует ожидаемому, сервер можно вывести из пула, чтобы он не получал никаких новых запросов.

По умолчанию сконфигурировано три метода проверки:

Настраиваем Application Rules

Application Rules – способ манипулирования трафиком, основанный на определенных триггерах. С помощью этого инструмента мы можем создавать расширенные правила балансировки нагрузки, настройка которых может быть невозможна через Application profiles или с помощью других сервисов, доступных на Edge Gateway.

В примере выше мы включили поддержку tlsv1.

Еще пара примеров:

Редирект трафика в другой пул.

Редирект трафика на внешний ресурс.

Здесь мы перенаправляем трафик на внешний веб-сайт, если все участники основного пула в состоянии down.

Еще больше примеров тут.

На этом про балансировщик у меня все. Если остались вопросы, спрашивайте, я готов ответить.

Читайте также: