В миналия път говорихме за възможностите на NSX Edge в контекста на статичната и динамичната маршрутизация, а днес ще разгледаме балансировчика.
Преди да преминем към настройката, бих искал да припомня накратко основните видове балансировка.
Теория
Всички днешни решения за балансировка на натоварване най-често се разделят на две категории: балансировка на четвърто (транспортно) и седмо (приложно) ниво на модела. Моделът OSI не е най-добрата референтна точка при описване на методите за балансировка. Например, ако L4 балансировчикът също поддържа приключване на TLS, дали тогава става L7 балансировчик? Но каквото такова, такова.
- Балансировчик L4 често представлява задействан между клиента и набор от налични бекенди посредник, който приключва TCP връзките (т.е. самостоятелно отговаря на SYN), избира бекенд и иницира нова TCP сесия към него, самостоятелно изпращайки SYN. Този тип е един от основните, възможни са и други варианти.
- Балансировчик L7 разпределя трафика по достъпните бекенди 'по-изискано' от L4 балансировчика. Той може да вземе решение за избора на бекенд на базата, например, на съдържанието на HTTP съобщението (URL адрес, бисквитка и т.н.).
Независимо от типа, балансировчикът може да поддържа следните функции:
- Откриване на услуги – процес на определяне на набор от налични бекенди (Static, DNS, Consul, Etcd и т.н.).
- Проверка на работоспособността на откритите бекенди (активен 'пинг' на бекенда с помощта на HTTP заявка, пасивно откриване на проблеми в TCP връзките, наличие на многократни 503 HTTP кодове в отговорите и т.н.).
- Самата балансировка (round robin, случайно избиране, хеш на IP адреса на източника, URI).
- Приключване на TLS и проверка на сертификатите.
- Опции, свързани с осигуряване на сигурността (автентификация, предотвратяване на DoS атаки, ограничаване на скоростта) и много други.
NSX Edge предлага поддръжка на два режима на разполагане на балансировчика:
Режим на прокси, или one-arm. В този режим NSX Edge използва своя IP адрес като адрес на източника при изпращане на заявка до един от бекендите. По този начин балансировчикът изпълнява едновременно функциите на Source и Destination NAT. Бекендът вижда целия трафик като изпратен от балансировчика и му отговаря директно. В такава схема балансировчикът трябва да бъде в един мрежов сегмент с вътрешните сървъри.
Ето как става:
1. Потребителят изпраща заявка до VIP адреса (адреса на балансировчика), който е конфигуриран на Edge.
2. Edge избира един от бекендите и изпълнява destination NAT, замествайки VIP адреса с адреса на избрания бекенд.
3. Edge изпълнява source NAT, замествайки адреса на изпращача на заявката с неговия собствен.
4. Пакетът се изпраща до избрания бекенд.
5. Бекендът не отговаря директно на потребителя, а на Edge, тъй като оригиналният адрес на потребителя е бил променен на адреса на балансировчика.
6. Edge предава отговора на сървъра на потребителя.
Схемата е показана по-долу.
Прозрачен, или inline режим. В този сценарий балансировчикът има интерфейси и в вътрешната, и в външната мрежа. При това няма директен достъп до вътрешната мрежа от външната. Вградената балансировачка действа като NAT шлюз за виртуалните машини във вътрешната мрежа.
Механизмът е следният:
1. Потребителят изпраща заявка до VIP адреса (адреса на балансировчика), който е конфигуриран на Edge.
2. Edge избира един от бекендите и изпълнява destination NAT, замествайки VIP адреса с адреса на избрания бекенд.
3. Пакетът се изпраща до избрания бекенд.
4. Бекендът получава заявката с оригиналния адрес на потребителя (source NAT не е извършван) и отговаря директно на него.
5. Трафикът отново се приема от балансировчика, тъй като в inline схемата той обикновено действа като шлюз по подразбиране за фермата от сървъри.
6. Edge изпълнява source NAT, за да изпрати трафика до потребителя, използвайки своя VIP като source IP адрес.
Схемата е показана по-долу.
Практика
На моя тестови стенд са настроени 3 сървъра с Apache, който е конфигуриран да работи по HTTPS. Edge ще балансира HTTPS заявки по метода round robin, проксироваща всяка нова заявка към нов сървър.
Да започваме.
Генерирайте SSL сертификат, който ще използва NSX Edge.
Можете да импортирате валиден CA сертификат или да използвате самоподписан. В този тест ще използвам самоподписан.
- В интерфейса на vCloud Director преминете към настройките на услугите Edge.
- Придвижете се до таба Certificates. От списъка с действия изберете добавяне на нов CSR.
- Попълнете необходимите полета и натиснете Keep.
- Изберете току-що създадения CSR и изберете опцията self-sign CSR.
- Изберете срока на валидност на сертификата и натиснете Keep.
- Самоподписаният сертификат се появи в списъка с налични.
Настройваме профила на приложението.
Профилите на приложенията предлагат по-пълен контрол над мрежовия трафик и правят управлението му лесно и ефективно. С тяхна помощ можете да определите поведението на конкретни видове трафик.
- Преминете на таба Load Balancer и активирайте балансираника. Опцията Acceleration enabled позволява на балансираника да използва по-бързо L4 балансиране вместо L7.
- Преминете на таба Application profile, за да зададете профила на приложението. Натиснете +.
- Задайте име на профила и изберете типа трафик, за който профилът ще бъде приложен. Ще обясня някои параметри.
Постоянство – запазва и следи данните на сесията, например: кой конкретен сървър от пулът обслужва потребителската заявка. Това гарантира, че потребителските заявки се насочват към един и същ член на пула през целия живот на сесията или последващите сесии.
Активирайте SSL passthrough – при избора на тази опция, NSX Edge спира да терминализира SSL. Вместо това терминализацията става директно на сървърите, за които се извършва балансировка.
Вмъкнете HTTP заглавие X-Forwarded-For – позволява да определите оригиналния IP адрес на клиента, свързващ се с уеб сървъра през балансировача.
Активирайте Pool Side SSL – позволява да се посочи, че избраният пул се състои от HTTPS сървъри.
- Тъй като ще балансирам HTTPS трафик, трябва да активирам Pool Side SSL и да избера генерирания по-рано сертификат на таба Virtual Server Certificates —> Service Certificate.
- По аналогичен начин за Pool Certificates —> Service Certificate.
Създайте пул от сървъри, трафикът към които ще бъде балансиран.
- Преминете на таба Pools. Натиснете +.
- Задайте име на пула, изберете алгоритъм (ще използвам round robin) и тип мониторинг за health check на бекенда. Опцията Transparent показва дали оригиналните source IP на клиентите са видими за вътрешните сървъри.
- Ако опцията е изключена, трафикът за вътрешните сървъри идва с source IP на балансировача.
- Ако опцията е активирана, вътрешните сървъри виждат source IP на клиентите. В такава конфигурация NSX Edge трябва да функционира като основен шлюз, за да гарантира, че връщаните пакети преминават през NSX Edge.
NSX поддържа следните алгоритми за балансиране:
- IP_HASH – избор на сървър въз основа на резултатите от хеш-функцията за source и destination IP на всеки пакет.
- LEASTCONN – балансиране на входящите връзки в зависимост от броя на вече съществуващите на конкретния сървър. Новите връзки ще бъдат насочени към сървъра с най-малко връзки.
- ROUND_ROBIN – новите връзки се изпращат на всеки сървър последователно, в съответствие с зададения им тегло.
- URI – лявата част на URI (преди въпросителната) се хешира и разделя на общото тегло на сървърите в пул. Резултатът указва кой сървър получава заявката, осигурявайки, че заявката винаги се насочва към един и същи сървър, докато всички сървъри остават достъпни.
- HTTPHEADER – балансиране на базата на определен HTTP заглавие, което може да се зададе като параметър. Ако заглавието липсва или няма стойност, се прилага алгоритъмът ROUND_ROBIN.
- URL – в всяка HTTP GET заявка се търси по параметъра URL, посочен като аргумент. Ако след параметъра има знак за равенство и стойност, стойността се хешира и разделя на общото тегло на стартираните сървъри. Резултатът указва кой сървър получава заявката. Този процес се използва за проследяване на идентификаторите на потребителите в заявките и осигуряване на това, че един и същ user id винаги се изпраща към един и същи сървър, докато всички сървъри остават достъпни.
- В блока Members натискаме +, за да добавим сървъри в пула.
Тук трябва да се посочи:- име на сървъра;
- IP адрес на сървъра;
- порт, на който сървърът ще получава трафик;
- порт за проверка на здравето (Monitor healthcheck);
- тегло (Weight) – с този параметър можете да регулирате пропорционалното количество получаван трафик за конкретен член на пула;
- Max Connections – максималното количество връзки към сървъра;
- Min Connections – минималното количество връзки, които сървърът трябва да обработи, преди трафикът да бъде пренасочен към следващия член на пула.
Така изглежда финалният пул от три сървъра.
Добавяме виртуален сървър
- Преминаваме на раздела Virtual Servers. Натискаме +.
- Активираме виртуалния сървър с Enable Virtual Server.
Задайте му име, изберете създадените по-рано Application Profile, Pool и посочете IP адреса, на който Virtual Server ще приема заявки извън. Посочете протокол HTTPS и порт 443.
Опционални параметри тук:
Connection Limit – максималното количество едновременни свързвания, които може да обработи виртуалният сървър;
Connection Rate Limit (CPS) – максималното количество нови входящи заявки в секунда.
На този етап конфигурацията на балансировчика е завършена, можете да проверите работоспособността му. Сървърите имат опростена конфигурация, позволяваща да се разбере кой точно сървър от пула е обработил заявката. По време на настройката избрахме алгоритъм за балансировка Round Robin, а параметърът Weight за всеки сървър е равен на единица, затова всяка следваща заявка ще бъде обработена от следващия сървър от пула.
Въведете външния адрес на балансировчика в браузъра и вижте:
След обновяване на страницата, заявката ще бъде обработена от следващия сървър:
И отново – за да проверите и третия сървър от пула:
При проверката може да се види, че сертификатът, който ни изпраща Edge, е същият, който генерирахме в самото начало.
Проверка на статуса на балансировчика от конзолата на Edge gateway. За това напишете show service loadbalancer pool.
Настройваме Service Monitor за проверка на състоянието на сървърите в пула.
С помощта на Service Monitor можем да следим състоянието на сървърите в бекенд пула. Ако отговорът на заявката не отговаря на очакваното, сървърът може да бъде изключен от пула, за да не получава нови заявки.
По подразбиране са конфигурирани три метода за проверка:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Нека създадем нов.
- Преминаваме на таба Service Monitoring, натискаме +.
- Избираме:
- име за новия метод;
- интервал, с който ще се изпращат заявки,
- таймаут за изчакване на отговор,
- тип мониторинг – HTTPS заявка с използване на метода GET, очакван код за статус – 200(OK) и URL на заявката.
- На този етап настройката на новия Service Monitor е завършена, сега можем да го използваме при създаването на пула.
Настройваме Application Rules
Application Rules – метод за манипулиране на трафика, базиран на определени тригери. С помощта на този инструмент можем да създадем разширени правила за балансировка на натоварването, чиято настройка може да бъде невъзможна чрез Application profiles или с помощта на други услуги, налични на Edge Gateway.
- За да създадем правило, преминаваме в раздела Application Rules на балансировщика.
- Избираме име, скрипт, който ще използва правилото, и натискаме Keep.
- След като правилото е създадено, трябва да редактираме вече настроения Virtual Server.
- В раздела Advanced добавяме създаденото от нас правило.
В примера по-горе включихме поддръжка за tlsv1.
Още няколко примера:
Пренасочване на трафика към друг пул.
С помощта на този скрипт можем да пренасочим трафика към друг пул на балансировката, ако основният пул не работи. За да сработи правилото, на балансировщика трябва да бъдат конфигурирани няколко пула и всички членове на основния пул трябва да са в статус down. Трябва да укажете именно името на пула, а не неговото ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Пренасочване на трафика към външен ресурс.
Тук пренасочваме трафика към външен уебсайт, ако всички участници в основния пул са в статус down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Още примери .
На това съм приключил с балансировщика. Ако имате въпроси, питайте, готов съм да отговоря.
Източник: habr.com
