Последен пат зборувавме за можностите на NSX Edge во однос на статичко и динамично рутирање, а денес ќе се занимаваме со load balancer.
Пред да започнеме со поставување, би сакал накратко да ве потсетам за главните типови на балансирање.
Теорија
Сите денешни решенија за балансирање на носивост најчесто се поделени во две категории: балансирање на четвртото (транспортно) и седмото (апликативно) ниво на моделот. . Моделот OSI не е најдобрата референтна точка кога се опишуваат методите за балансирање. На пример, ако балансерот L4 поддржува и завршување на TLS, дали тој тогаш станува балансер L7? Но, тоа е она што е.
- Балансатор L4 најчесто тоа е среден прокси кој стои помеѓу клиентот и збир на достапни задни делови, кој ги прекинува TCP врските (односно, независно одговара на SYN), избира заднина и иницира нова TCP сесија во нејзина насока, независно испраќајќи SYN. Овој тип е еден од основните, можни се и други опции.
- Балансатор L7 го дистрибуира сообраќајот низ достапните задни делови „пософистицирани“ од балансерот L4. Може да одлучи кој заднина да избере врз основа на, на пример, содржината на HTTP пораката (URL, колаче, итн.).
Без оглед на видот, балансерот може да ги поддржува следните функции:
- Откривањето на услугата е процес на одредување на множеството достапни задни делови (Static, DNS, Consul, Etcd, итн.).
- Проверка на функционалноста на откриените позадини (активен „пинг“ на заднината со користење на барање HTTP, пасивно откривање на проблеми во TCP врските, присуство на неколку 503 HTTP кодови во одговорите итн.).
- Самото балансирање (круг, случаен избор, изворен хаш IP, URI).
- Престанок на TLS и верификација на сертификатот.
- Опции поврзани со безбедноста (автентикација, спречување DoS напади, ограничување на брзината) и многу повеќе.
NSX Edge нуди поддршка за два режима на распоредување на балансерот на оптоварување:
Режим на прокси, или еднокрак. Во овој режим, NSX Edge ја користи својата IP адреса како изворна адреса кога испраќа барање до еден од позадините. Така, балансерот истовремено ги извршува функциите на извор и дестинација NAT. Заднината го гледа целиот сообраќај како испратен од балансерот и реагира директно на него. Во таква шема, балансерот мора да биде во истиот мрежен сегмент со внатрешните сервери.
Еве како оди тоа:
1. Корисникот испраќа барање до ВИП адресата (адреса за балансирање) која е конфигурирана на Edge.
2. Edge избира еден од задниот дел и врши дестинација NAT, заменувајќи ја VIP адресата со адресата на избраниот заднина.
3. Edge врши изворен NAT, заменувајќи ја адресата на корисникот кој го испратил барањето со своја.
4. Пакетот се испраќа до избраниот заден дел.
5. Заднината не реагира директно на корисникот, туку на Edge, бидејќи оригиналната адреса на корисникот е сменета во адресата на балансерот.
6. Edge го пренесува одговорот на серверот до корисникот.
Дијаграмот е подолу.
Транспарентен или вграден режим. Во ова сценарио, балансерот има интерфејси на внатрешните и надворешните мрежи. Во исто време, нема директен пристап до внатрешната мрежа од надворешната. Вградениот баланс на оптоварување делува како NAT порта за виртуелни машини на внатрешната мрежа.
Механизмот е како што следува:
1. Корисникот испраќа барање до ВИП адресата (адреса за балансирање) која е конфигурирана на 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.
- Одете во табулаторот Сертификати. Од списокот со дејства, изберете додавање нова ООП.
- Пополнете ги бараните полиња и кликнете Задржи.
- Изберете ја новосоздадената ООП и изберете ја опцијата за самопотпишување ООП.
- Изберете го периодот на важност на сертификатот и кликнете Задржи
- Самопотпишаниот сертификат се појавува во списокот со достапни.
Поставување профил на апликација
Профилите на апликации ви даваат поцелосна контрола врз мрежниот сообраќај и го прават управувањето едноставно и ефективно. Тие можат да се користат за дефинирање на однесувањето за одредени видови сообраќај.
- Одете во картичката Load Balancer и овозможете го балансерот. Опцијата овозможено забрзување овде му овозможува на балансерот да користи побрзо L4 балансирање наместо L7.
- Одете во картичката Профил на апликација за да го поставите профилот на апликацијата. Кликнете на +.
- Поставете го името на профилот и изберете го типот на сообраќај за кој профилот ќе се применува. Дозволете ми да објаснам некои параметри.
Упорност – ги зачувува и следи податоците од сесиите, на пример: кој специфичен сервер во базенот го сервисира барањето на корисникот. Ова осигурува дека корисничките барања се пренасочени до истиот член на базенот за време на траењето на сесијата или следните сесии.
Овозможете SSL премин – Кога е избрана оваа опција, NSX Edge престанува да го прекинува SSL. Наместо тоа, прекинувањето се случува директно на серверите што се балансираат.
Вметнете заглавие X-Forwarded-For HTTP – ви овозможува да ја одредите изворната IP адреса на клиентот што се поврзува со веб-серверот преку балансерот на оптоварување.
Овозможете SSL од страна на базенот – ви овозможува да одредите дека избраниот базен се состои од HTTPS сервери.
- Бидејќи ќе го балансирам сообраќајот на HTTPS, треба да овозможам SSL од страна на базенот и да го изберам претходно генерираниот сертификат во табулаторот Виртуелни сервери -> сертификат за услуги.
- Слично за сертификати за базен -> Сертификат за услуги.
Ние создаваме базен на сервери, сообраќајот до кој ќе биде избалансиран Pools
- Одете во табулаторот Базени. Кликнете на +.
- Го поставуваме името на базенот, го избираме алгоритмот (ќе користам круг) и типот на мониторинг за бекендот на здравствената проверка.Опцијата Transparent покажува дали почетните изворни IP-адреси на клиентите се видливи за внатрешните сервери.
- Ако опцијата е оневозможена, сообраќајот за внатрешните сервери доаѓа од изворната IP адреса на балансерот.
- Ако опцијата е овозможена, внатрешните сервери ја гледаат изворната IP на клиентите. Во оваа конфигурација, NSX Edge мора да дејствува како стандардна порта за да се осигура дека вратените пакети минуваат низ NSX Edge.
NSX ги поддржува следните алгоритми за балансирање:
- IP_HASH – избор на сервер врз основа на резултатите од хаш-функција за изворната и дестинацијата IP на секој пакет.
- ЛИСТКОНН – балансирање на дојдовните конекции, во зависност од бројот што е веќе достапен на одреден сервер. Новите врски ќе бидат насочени кон серверот со најмалку врски.
- ROUND_ROBIN – нови врски се испраќаат до секој сервер по ред, во согласност со тежината што му е доделена.
- URI – левиот дел од URI (пред прашалникот) е хаширан и поделен со вкупната тежина на серверите во базенот. Резултатот покажува кој сервер го прима барањето, осигурувајќи дека барањето секогаш е насочено кон истиот сервер, сè додека сите сервери останат достапни.
- HTTPHEADER – балансирање врз основа на специфичен HTTP заглавие, кој може да се наведе како параметар. Ако заглавието недостасува или нема никаква вредност, се применува алгоритмот ROUND_ROBIN.
- URL – Секое барање HTTP GET го бара параметарот URL наведен како аргумент. Ако параметарот е проследен со знак за еднаквост и вредност, тогаш вредноста се хашира и се дели со вкупната тежина на активните сервери. Резултатот покажува кој сервер го прима барањето. Овој процес се користи за следење на корисничките идентификатори во барањата и за да се осигура дека истиот кориснички идентификатор секогаш се испраќа до истиот сервер, сè додека сите сервери останат достапни.
- Во блокот Членови, кликнете + за да додадете сервери во базенот.
Овде треба да наведете:- име на серверот;
- IP адреса на серверот;
- портата на која серверот ќе прима сообраќај;
- пристаниште за здравствена проверка (Monitor Healthcheck);
- тежина – со помош на овој параметар можете да го прилагодите пропорционалниот износ на примен сообраќај за одреден член на базенот;
- Max Connections – максимален број на конекции со серверот;
- Мини врски – минималниот број на врски што серверот мора да ги обработи пред сообраќајот да се проследи до следниот член на базенот.
Вака изгледа последниот базен од три сервери.
Додавање виртуелен сервер
- Одете во табулаторот Виртуелни сервери. Кликнете на +.
- Ние го активираме виртуелниот сервер користејќи Овозможи виртуелен сервер.
Му даваме име, го избираме претходно креираниот Профил на апликацијата, Базен и ја означуваме IP адресата на која Виртуелниот сервер ќе прима барања однадвор. Го одредуваме протоколот HTTPS и портата 443.
Факултативни параметри овде:
Ограничување на врската – максималниот број на истовремени врски што виртуелниот сервер може да ги обработи;
Ограничување на стапката на поврзување (CPS) – максималниот број на нови дојдовни барања во секунда.
Ова ја комплетира конфигурацијата на балансерот; можете да ја проверите неговата функционалност. Серверите имаат едноставна конфигурација која ви овозможува да разберете кој сервер од базенот го обработил барањето. За време на поставувањето, го избравме алгоритмот за балансирање Round Robin, а параметарот Weight за секој сервер е еднаков на еден, така што секое следно барање ќе биде обработено од следниот сервер од базенот.
Ја внесуваме надворешната адреса на балансерот во прелистувачот и гледаме:
По освежувањето на страницата, барањето ќе биде обработено од следниот сервер:
И повторно - да го проверите третиот сервер од базенот:
При проверка, можете да видите дека сертификатот што ни го испраќа Edge е истиот што го генериравме на самиот почеток.
Проверка на статусот на балансерот од конзолата на Edge gateway. За да го направите ова, внесете прикажи сервис loadbalancer базен.
Конфигурирање на сервисниот монитор за проверка на статусот на серверите во базенот
Користејќи сервисен монитор, можеме да го следиме статусот на серверите во задниот базен. Ако одговорот на барање не е како што се очекуваше, серверот може да се извади од базенот за да не прима нови барања.
Стандардно, три методи за верификација се конфигурирани:
- TCP-монитор,
- HTTP монитор,
- HTTPS-монитор.
Ајде да создадеме нов.
- Одете во табулаторот „Следење на услуги“, кликнете +.
- Изберете:
- име за новиот метод;
- интервалот во кој ќе се испраќаат барањата,
- тајмаут чекајќи одговор,
- тип на мониторинг – барање HTTPS со користење на методот GET, очекуван статусен код – 200(OK) и URL на барање.
- Ова го комплетира поставувањето на новиот сервисен монитор; сега можеме да го користиме кога креираме базен.
Поставување правила за апликација
Правилата за апликација се начин за манипулирање со сообраќајот врз основа на одредени предизвикувачи. Со оваа алатка можеме да создадеме напредни правила за балансирање на оптоварување кои можеби не се можни преку профилите на апликации или други услуги достапни на Edge Gateway.
- За да креирате правило, одете во табулаторот Правила за апликација на балансерот.
- Изберете име, скрипта што ќе го користи правилото и кликнете Keep.
- Откако ќе се креира правилото, треба да го уредиме веќе конфигурираниот виртуелен сервер.
- Во табулаторот Advanced, додадете го правилото што го создадовме.
Во примерот погоре, овозможивме поддршка за tlsv1.
Уште неколку примери:
Пренасочете го сообраќајот кон друг базен.
Со оваа скрипта можеме да го пренасочиме сообраќајот кон друг базен за балансирање ако главниот базен е неактивен. За да функционира правилото, мора да се конфигурираат повеќе базени на балансерот и сите членови на главниот базен мора да бидат во долна состојба. Треба да го наведете името на базенот, а не неговиот ID.
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