Миналия път говорихме за възможностите на NSX Edge по отношение на статично и динамично маршрутизиране, а днес ще се занимаваме с балансиращото натоварване.
Преди да започнем настройката, бих искал накратко да ви напомня за основните видове балансиране.
теория
Всички днешни решения за балансиране на полезен товар най-често се разделят на две категории: балансиране на четвърто (транспортно) и седмо (приложно) ниво на модела . OSI моделът не е най-добрата отправна точка при описване на методи за балансиране. Например, ако L4 балансьор също поддържа TLS терминиране, тогава става ли L7 балансьор? Но е каквото е.
- Балансьор L4 най-често това е среден прокси, стоящ между клиента и набор от налични бекендове, който прекъсва TCP връзките (т.е. независимо отговаря на SYN), избира бекенд и инициира нова TCP сесия в неговата посока, независимо изпращайки SYN. Този тип е един от основните, възможни са и други варианти.
- Балансьор L7 разпределя трафика между наличните бекендове „по-усъвършенствано“, отколкото прави L4 балансьорът. Той може да реши кой бекенд да избере въз основа например на съдържанието на HTTP съобщението (URL, бисквитка и т.н.).
Независимо от вида, балансьорът може да поддържа следните функции:
- Откриването на услуга е процесът на определяне на набор от налични бекендове (статични, DNS, консулски, и т.н.).
- Проверка на функционалността на откритите бекендове (активен „пинг” на бекенда чрез HTTP заявка, пасивно откриване на проблеми в TCP връзките, наличие на няколко 503 HTTP кода в отговорите и др.).
- Самото балансиране (кръгов режим, произволен избор, хеш IP на източника, URI).
- Прекратяване на TLS и проверка на сертификат.
- Опции, свързани със сигурността (удостоверяване, предотвратяване на DoS атаки, ограничаване на скоростта) и много други.
NSX Edge предлага поддръжка за два режима на разгръщане на балансиращото натоварване:
Прокси режим или с една ръка. В този режим NSX Edge използва своя IP адрес като адрес на източника, когато изпраща заявка към един от бекендовете. По този начин балансиращият едновременно изпълнява функциите на NAT на източник и дестинация. Бекендът вижда целия трафик като изпратен от балансьора и отговаря директно на него. При такава схема балансьорът трябва да бъде в същия мрежов сегмент с вътрешните сървъри.
Ето как става:
1. Потребителят изпраща заявка до VIP адреса (адрес на балансьор), който е конфигуриран на Edge.
2. Edge избира един от бекенда и извършва NAT на дестинацията, като замества VIP адреса с адреса на избрания бекенд.
3. Edge извършва NAT на източника, като заменя адреса на потребителя, изпратил заявката, със свой собствен.
4. Пакетът се изпраща до избрания бекенд.
5. Бекендът не отговаря директно на потребителя, а на Edge, тъй като оригиналният адрес на потребителя е променен на адреса на балансиращия.
6. Edge предава отговора на сървъра на потребителя.
Диаграмата е по-долу.
Прозрачен или вграден режим. В този сценарий балансьорът има интерфейси във вътрешната и външната мрежа. В същото време няма директен достъп до вътрешната мрежа от външната. Вграденият балансьор на натоварването действа като NAT шлюз за виртуални машини във вътрешната мрежа.
Механизмът е следният:
1. Потребителят изпраща заявка до VIP адреса (адрес на балансьор), който е конфигуриран на Edge.
2. Edge избира един от бекенда и извършва NAT на дестинацията, като замества VIP адреса с адреса на избрания бекенд.
3. Пакетът се изпраща до избрания бекенд.
4. Бекендът получава заявка с оригиналния адрес на потребителя (изходният NAT не е извършен) и отговаря директно на нея.
5. Трафикът отново се приема от балансиращото натоварване, тъй като във вградена схема той обикновено действа като шлюз по подразбиране за сървърната група.
6. Edge изпълнява NAT на източника, за да изпрати трафик към потребителя, използвайки неговия VIP като IP адрес на източника.
Диаграмата е по-долу.
Практика
Моят тестов стенд има 3 сървъра, работещи с Apache, който е конфигуриран да работи през HTTPS. Edge ще извършва кръгово балансиране на HTTPS заявки, като проксира всяка нова заявка към нов сървър.
Да започнем.
Генериране на SSL сертификат, който ще се използва от NSX Edge
Можете да импортирате валиден CA сертификат или да използвате самоподписан. За този тест ще използвам самоподписан.
- В интерфейса на vCloud Director отидете на настройките на Edge services.
- Отидете в раздела Сертификати. От списъка с действия изберете добавяне на нов CSR.
- Попълнете задължителните полета и щракнете върху Запазване.
- Изберете новосъздадения CSR и изберете опцията за самоподписване на CSR.
- Изберете периода на валидност на сертификата и щракнете върху Запази
- Самоподписаният сертификат се появява в списъка с налични.
Настройване на профил на приложението
Профилите на приложения ви дават по-пълен контрол върху мрежовия трафик и правят управлението му лесно и ефективно. Те могат да се използват за определяне на поведение за специфични видове трафик.
- Отидете в раздела Load Balancer и активирайте балансира. Активираната опция за ускорение тук позволява на балансира да използва по-бързо L4 балансиране вместо L7.
- Отидете в раздела Профил на приложението, за да зададете профила на приложението. Кликнете върху +.
- Задайте името на профила и изберете типа трафик, за който ще се прилага профилът. Нека обясня някои параметри.
Постоянство – съхранява и проследява данни за сесията, например: кой конкретен сървър в пула обслужва потребителската заявка. Това гарантира, че потребителските заявки се насочват към един и същ член на пула за целия живот на сесията или следващите сесии.
Активирайте SSL passthrough – Когато тази опция е избрана, NSX Edge спира да прекъсва SSL. Вместо това прекратяването се извършва директно на сървърите, които се балансират.
Вмъкнете X-Forwarded-For HTTP заглавка – позволява ви да определите IP адреса на източника на клиента, който се свързва с уеб сървъра чрез балансиращото натоварване.
Активирайте SSL от страната на басейна – позволява ви да посочите, че избраният пул се състои от HTTPS сървъри.
- Тъй като ще балансирам HTTPS трафик, трябва да активирам SSL от страната на басейна и да избера предварително генерирания сертификат в раздела Сертификати за виртуален сървър -> Сертификат за услуга.
- По същия начин за Сертификати за пул -> Сертификат за услуга.
Създаваме пул от сървъри, трафикът към който ще бъде балансиран Пулове
- Отидете в раздела Пулове. Кликнете върху +.
- Задаваме името на пула, избираме алгоритъма (аз ще използвам кръгов режим) и вида на мониторинга за бекенда за проверка на здравето.Опцията Transparent показва дали първоначалните IP адреси на клиентите са видими за вътрешните сървъри.
- Ако опцията е деактивирана, трафикът за вътрешните сървъри идва от изходния IP адрес на балансира.
- Ако опцията е активирана, вътрешните сървъри виждат изходния IP адрес на клиентите. В тази конфигурация NSX Edge трябва да действа като шлюз по подразбиране, за да гарантира, че върнатите пакети преминават през NSX Edge.
NSX поддържа следните алгоритми за балансиране:
- IP_HASH – избор на сървър въз основа на резултатите от хеш функция за IP на източника и местоназначението на всеки пакет.
- LESTCONN – балансиране на входящи връзки, в зависимост от наличния брой на даден сървър. Новите връзки ще бъдат насочени към сървъра с най-малко връзки.
- ROUND_ROBIN – новите връзки се изпращат към всеки сървър на свой ред, в съответствие с присвоената му тежест.
- URI,en – лявата част на URI (преди въпросителния знак) се хешира и разделя на общото тегло на сървърите в пула. Резултатът показва кой сървър получава заявката, като гарантира, че заявката винаги се насочва към същия сървър, докато всички сървъри остават налични.
- HTTPHEADER – балансиране на базата на специфичен HTTP хедър, който може да бъде зададен като параметър. Ако заглавието липсва или няма стойност, се прилага алгоритъмът ROUND_ROBIN.
- URL – Всяка HTTP GET заявка търси URL параметъра, посочен като аргумент. Ако параметърът е последван от знак за равенство и стойност, тогава стойността се хешира и се разделя на общото тегло на работещите сървъри. Резултатът показва кой сървър получава заявката. Този процес се използва за проследяване на потребителски идентификатори в заявките и гарантиране, че един и същ потребителски идентификатор винаги се изпраща до един и същ сървър, стига всички сървъри да останат налични.
- В блока Членове щракнете върху +, за да добавите сървъри към пула.
Тук трябва да посочите:- Име на сървъра;
- IP адрес на сървъра;
- порта, на който сървърът ще получава трафик;
- порт за проверка на здравето (Monitor healthcheck);
- тегло – с помощта на този параметър можете да регулирате пропорционалното количество трафик, получен за конкретен член на пула;
- Max Connections – максимален брой връзки към сървъра;
- Минимални връзки – минималният брой връзки, които сървърът трябва да обработи, преди трафикът да бъде пренасочен към следващия член на пула.
Ето как изглежда окончателният пул от три сървъра.
Добавяне на виртуален сървър
- Отидете в раздела Виртуални сървъри. Кликнете върху +.
- Активираме виртуалния сървър с помощта на Enable Virtual Server.
Даваме му име, избираме създадения преди това профил на приложение, пул и посочваме IP адреса, на който виртуалният сървър ще получава заявки отвън. Посочваме HTTPS протокола и порт 443.
Незадължителни параметри тук:
Лимит на връзката – максималния брой едновременни връзки, които виртуалният сървър може да обработва;
Ограничение на скоростта на свързване (CPS) – максималния брой нови входящи заявки за секунда.
Това завършва конфигурацията на балансира, можете да проверите неговата функционалност. Сървърите имат проста конфигурация, която ви позволява да разберете кой сървър от пула е обработил заявката. По време на настройката избрахме алгоритъма за балансиране Round Robin и параметърът Weight за всеки сървър е равен на единица, така че всяка следваща заявка ще бъде обработена от следващия сървър от пула.
Въвеждаме външния адрес на балансьора в браузъра и виждаме:
След опресняване на страницата заявката ще бъде обработена от следния сървър:
И отново - за проверка на третия сървър от пула:
Когато проверявате, можете да видите, че сертификатът, който Edge ни изпраща, е същият, който генерирахме в самото начало.
Проверка на състоянието на балансьора от конзолата на Edge gateway. За да направите това, въведете показване на пул за балансиране на натоварването на услугата.
Конфигуриране на Service Monitor за проверка на състоянието на сървърите в пула
С помощта на Service Monitor можем да наблюдаваме състоянието на сървърите в бекенд пула. Ако отговорът на заявка не е според очакванията, сървърът може да бъде изваден от пула, така че да не получава нови заявки.
По подразбиране са конфигурирани три метода за проверка:
- TCP-монитор,
- HTTP монитор,
- HTTPS-монитор.
Нека създадем нов.
- Отидете в раздела за наблюдение на услугата, щракнете върху +.
- Избирам:
- име за новия метод;
- интервала, на който ще се изпращат заявки,
- таймаут в очакване на отговор,
- тип мониторинг – HTTPS заявка чрез метода GET, очакван статус код – 200(OK) и URL на заявката.
- Това завършва настройката на новия Service Monitor; сега можем да го използваме, когато създаваме пул.
Настройване на правила за кандидатстване
Правилата за приложение са начин за манипулиране на трафик въз основа на определени задействания. С този инструмент можем да създадем разширени правила за балансиране на натоварването, които може да не са възможни чрез профили на приложения или други услуги, налични на Edge Gateway.
- За да създадете правило, отидете в раздела Правила на приложението на балансира.
- Изберете име, скрипт, който ще използва правилото, и щракнете върху Запазване.
- След като правилото е създадено, трябва да редактираме вече конфигурирания виртуален сървър.
- В раздела Разширени добавете създаденото от нас правило.
В примера по-горе активирахме поддръжката на tlsv1.
Още няколко примера:
Пренасочване на трафика към друг басейн.
С този скрипт можем да пренасочим трафика към друг балансиращ пул, ако основният пул не работи. За да работи правилото, множество пулове трябва да бъдат конфигурирани на балансира и всички членове на главния пул трябва да са в неактивно състояние. Трябва да посочите името на пула, а не неговия идентификатор.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Пренасочване на трафик към външен ресурс.
Тук пренасочваме трафика към външния уебсайт, ако всички членове на основния пул не работят.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Още повече примери .
Това е всичко за мен за балансьора. Ако имате въпроси, питайте, готов съм да отговоря.
Източник: www.habr.com