Настройки сети
Сценарии настройки VRF
Балансировка внутри VRF

Балансировка внутри VRF

Приложение балансируется внутри изолированной сети: и VIP, и серверы находятся в VRF demo. Значения — из сквозного примера.

Что получится

  • Балансировщики будут принимать соединения на 10.88.0.100 внутри VRF demo.
  • Проверки доступности серверов пойдут с адресов агентов в этом же VRF, а не с адресов рабочего трафика.
  • Соединения к серверам будут открываться из VRF demo, поэтому серверам не нужен маршрут в сеть балансировщиков.

Перед началом

  • Профиль demo создан и показывает статус Работает.
  • Серверы приложения доступны в сети 10.88.0.0/24 — например, 10.88.0.201 и 10.88.0.202.

Настройка

  1. Создайте клиентские серверы для 10.88.0.201 и 10.88.0.202. В поле VRF каждого сервера выберите demo.
  2. Создайте группу серверов и добавьте в неё оба сервера. В поле VRF группы выберите demo.
  3. В секции Проверка здоровья группы подключите монитор — без него балансировщик будет считать доступными все серверы.
  4. Создайте конфигурацию балансировки:
    • в поле VRF выберите demo;
    • в секции Отказоустойчивость (HA) выберите тип VRRP (Active-Passive) и в группе VIP укажите 10.88.0.100/32;
    • в секции Сервисы выберите созданную группу серверов.
  5. Сохраните конфигурацию.
ℹ️

Отдельно заводить VIP на вкладке Сеть → <сетевой агент> → IP/VIP не нужно: адрес поднимается из настроек отказоустойчивости и появляется в списке после сохранения конфигурации.

VRF конфигурации балансировки и VRF её группы серверов должны совпадать. Если серверы приложения находятся в другом VRF, потребуется Cross-VRF политика — см. Серверы в другом VRF.

Проверка

В интерфейсе системы

  1. В группе серверов узлы перешли в состояние ОК. Если они остаются недоступными, проверьте, что серверы отвечают на адресах из изолированной сети, а не из общей.

  2. На вкладке Сеть → <сетевой агент> → IP/VIP у одного из агентов появился VIP 10.88.0.100. Этот агент и есть MASTER.

  3. Текущее распределение ролей MASTER и BACKUP отдаёт запрос статуса VRRP:

    GET /api/v1/clusters/{clusterId}/services/{serviceId}/vrrp_status

  4. Обмен с серверами можно снять инструментом TCP Dump на интерфейсе ens19.300 — в нём видно, с какого адреса балансировщик обращается к серверам.

Трафиком

С узла изолированной сети обратитесь к VIP:

curl -sS -o /dev/null -w '%{http_code}\n' http://10.88.0.100:8080/

В журнале сервера приложения источником запросов будет 10.88.0.11 или 10.88.0.12 — адрес агента в VRF, а не адрес его рабочего трафика.

Частые ошибки

СообщениеЧто означаетЧто сделать
Нужна cross-VRF политика demo→tenant2: VIP в VRF "demo", backend — в "tenant2"VRF конфигурации балансировки и VRF группы серверов различаютсяПриведите их к одному VRF либо создайте политику по сценарию Серверы в другом VRF
VRF группы нельзя изменить, пока она обслуживает сервис — перенесите сервис целикомПопытка сменить VRF у группы, на которую ссылается конфигурация балансировкиОтвяжите группу от конфигурации либо переносите конфигурацию вместе с группой
VRF сервера нельзя изменить, пока он состоит в группеПопытка сменить VRF у сервера, уже включённого в группуВыведите сервер из группы, смените VRF, верните обратно
Правка VRF оставит сервис "..." без data-контекста семейства IPv4 на агенте slb-node-2 — сначала измените сервис или добавьте адрес в VRFИз профиля убирают агента, на котором работает конфигурация балансировкиВерните агента в сегмент либо снимите с него конфигурацию

Дальше

Изолированная сеть на VLANОбмен маршрутами по BGP