Data trecută am discutat despre capabilitățile NSX Edge în contextul rutării statice și dinamice, iar astăzi ne vom axa pe echilibrator.
Înainte de a începe configurarea, aș dori să fac un scurt rezumat al principalelor tipuri de echilibrare.
Teorie
Toate soluțiile de echilibrare a încărcării de astăzi se împart, de obicei, în două categorii: echilibrarea la nivelul patru (transport) și la nivelul șapte (aplicație) al modelului . Modelul OSI nu este cea mai bună referință atunci când descriem metodele de echilibrare. De exemplu, dacă un echilibrator L4 suportă și terminarea TLS, devine el astfel un echilibrator L7? Dar așa stau lucrurile.
- Echilibrator L4 de obicei reprezintă un proxy care stă între client și un set de backend-uri disponibile, terminând conexiunile TCP (adică răspunzând singur la SYN), alegând un backend și inițiind o nouă sesiune TCP către acesta, trimițând singur SYN. Acest tip este unul de bază, pot exista și alte variații.
- Echilibrator L7 distribuie traficul către backend-urile disponibile „mai sofisticat” decât o face echilibratorul L4. Acesta poate lua decizii de selecție a backend-ului pe baza, de exemplu, conținutului mesajului HTTP (URL, cookie etc.).
Indiferent de tip, echilibratorul poate susține următoarele funcții:
- Descoperirea serviciilor – procesul de determinare a setului de backend-uri disponibile (Static, DNS, Consul, Etcd etc.).
- Verificarea funcționării backend-urilor descoperite (ping activ al backend-ului printr-o cerere HTTP, descoperire pasivă a problemelor în conexiunile TCP, apariția consecutivă a mai multor coduri HTTP 503 în răspunsurile primite etc.).
- Efectuarea echilibrării (round robin, selecție aleatoare, hash IP sursă, URI).
- Terminarea TLS și validarea certificatelor.
- Opțiuni legate de asigurarea securității (autentificare, prevenirea atacurilor DoS, limitarea ratelor) și multe altele.
NSX Edge oferă suport pentru două moduri de desfășurare a echilibratorului:
Modul proxy, sau one-arm. În acest mod, NSX Edge folosește adresa sa IP ca adresă sursă atunci când trimite solicitări către unul dintre backend-uri. Astfel, echilibratorul de sarcină îndeplinește simultan funcțiile de NAT sursă și destinație. Backend-ul vede tot traficul ca fiind trimis de la echilibrator și îi răspunde direct. În această schemă, echilibratorul trebuie să fie în același segment de rețea cu serverele interne.
Iată cum se întâmplă:
1. Utilizatorul trimite o solicitare către adresa VIP (adresa echilibratorului), care este configurată pe Edge.
2. Edge alege unul dintre backend-uri și efectuează NAT de destinație, înlocuind adresa VIP cu adresa backend-ului ales.
3. Edge efectuează NAT sursă, înlocuind adresa utilizatorului care a trimis solicitarea cu propria sa adresă.
4. Pachetul este trimis către backend-ul ales.
5. Backend-ul răspunde nu direct utilizatorului, ci lui Edge, deoarece adresa inițială a utilizatorului a fost schimbată cu adresa echilibratorului.
6. Edge transmite răspunsul serverului utilizatorului.
Schema de mai jos.
Modul transparent sau inline. În acest scenariu, echilibratorul are interfețe în rețeaua internă și în cea externă. Totuși, nu există acces direct la rețeaua internă din exterior. Echilibratorul de încărcare integrat acționează ca un gateway NAT pentru mașinile virtuale din rețeaua internă.
Mecanismul este următorul:
1. Utilizatorul trimite o solicitare către adresa VIP (adresa echilibratorului), care este configurată pe Edge.
2. Edge alege unul dintre backend-uri și efectuează NAT de destinație, înlocuind adresa VIP cu adresa backend-ului ales.
3. Pachetul este trimis către backend-ul ales.
4. Backend-ul primește solicitarea cu adresa inițială a utilizatorului (NAT sursă nu a fost efectuat) și îi răspunde direct.
5. Traficul este din nou preluat de echilibratorul de sarcină, deoarece în schema inline de obicei acționează ca gateway implicit pentru ferma de servere.
6. Edge efectuează NAT sursă pentru a trimite trafic utilizatorului, folosind VIP-ul său ca adresă IP sursă.
Schema de mai jos.
Practică
În laboratorul meu de testare am configurat 3 servere cu Apache, care este configurat să funcționeze pe HTTPS. Edge va realiza echilibrarea solicitărilor HTTPS folosind metoda round robin, proxiind fiecare nouă solicitare către un nou server.
Să începem.
Generăm un certificat SSL, care va fi utilizat de NSX Edge.
Puteți importa un certificat CA valid sau utiliza unul auto-semnat. În acest test, voi folosi un certificat auto-semnat.
- În interfața vCloud Director, accesăm setările serviciilor Edge.
- Accesăm tab-ul Certificate. Din lista de acțiuni, alegem adăugarea unui nou CSR.
- Completăm câmpurile necesare și apăsăm Keep.
- Selectăm CSR-ul nou creat și alegem opțiunea self-sign CSR.
- Alegem perioada de valabilitate a certificatului și apăsăm Keep.
- Certificatul auto-semnat a apărut în lista disponibilă.
Configurăm Application Profile.
Profilele de aplicație oferă un control mai mare asupra traficului de rețea și fac gestionarea acestuia simplă și eficientă. Cu ajutorul lor, se poate defini comportamentul pentru anumite tipuri de trafic.
- Trecem la tab-ul Load Balancer și activăm balansorul. Opțiunea Acceleration enabled permite balansorului să utilizeze un echilibru L4 mai rapid în loc de L7.
- Trecem la tab-ul Application profile pentru a defini profilul aplicației. Apăsați +.
- Definim numele profilului și alegem tipul de trafic pentru care profilul va fi aplicat. Voi explica câteva dintre parametri.
Persistence – păstrează și urmărește datele sesiunii, de exemplu: care server specific din pool deservește cererea utilizatorului. Aceasta garantează că cererile utilizatorului sunt direcționate către același membru din pool pe parcursul întregii sesiuni sau în sesiuni ulterioare.
Enable SSL passthrough – alegând această opțiune, NSX Edge încetează să termine SSL. În schimb, terminarea are loc direct pe serverele pentru care se face echilibrarea.
Insert X-Forwarded-For HTTP header – permite identificarea adresei IP originale a clientului care se conectează la serverul web prin intermediul balansorului.
Enable Pool Side SSL – permite specificarea faptului că pool-ul selectat constă din servere HTTPS.
- Deoarece voi echilibra traficul HTTPS, trebuie să activez Pool Side SSL și să aleg certificatul generat anterior în tab-ul Virtual Server Certificates —> Service Certificate.
- Similar pentru Pool Certificates —> Service Certificate.
Creăm un pool de servere, traficul către care va fi echilibrat Pools.
- Trecem la tab-ul Pools. Apăsăm +.
- Definim numele pool-ului, alegem algoritmul (voi folosi round robin) și tipul de monitorizare pentru health check-ul backend-ului. Opțiunea Transparent indică dacă adresele IP originale ale clienților sunt vizibile pentru serverele interne.
- Dacă opțiunea este dezactivată, traficul pentru serverele interne vine cu adresa IP a balansorului.
- Dacă opțiunea este activată, serverele interne văd adresa IP a clienților. Într-o astfel de configurație, NSX Edge trebuie să acționeze ca gateway implicit pentru a garanta că pachetele returnate trec prin NSX Edge.
NSX suportă următoarele algoritmi de echilibrare:
- IP_HASH – alegerea serverului pe baza rezultatelor funcției de hash pentru adresele IP sursă și destinație ale fiecărui pachet.
- LEASTCONN – echilibrarea conexiunilor de intrare, în funcție de numărul deja existent pe un server specific. Noi conexiuni vor fi direcționate către serverul cu cele mai puține conexiuni.
- ROUND_ROBIN – noile conexiuni sunt trimise pe rând către fiecare server, conform greutății atribuite acestuia.
- URI – partea stângă a URI (până la semnul întrebării) este hash-uită și împărțită la greutatea totală a serverelor din pool. Rezultatul indică ce server primește cererea, garantând că cererea este întotdeauna direcționată către același server, atâta timp cât toate serverele rămân disponibile.
- HTTPHEADER – echilibrarea pe baza unui anumit header HTTP, care poate fi specificat ca parametru. Dacă headerul lipsește sau nu are o valoare, se aplică algoritmul ROUND_ROBIN.
- URL – în fiecare cerere HTTP GET se caută parametrul URL specificat ca argument. Dacă parametrul este urmat de semnul egal și o valoare, atunci valoarea este hash-uită și împărțită la greutatea totală a serverelor active. Rezultatul indică ce server primește cererea. Acest proces este utilizat pentru a urmări identificatorii utilizatorilor în cereri și pentru a asigura că același user id este întotdeauna trimis către același server, atâta timp cât toate serverele rămân disponibile.
- În blocul Members apăsăm + pentru a adăuga servere în pool.
Aici trebuie specificat:- numele serverului;
- adresa IP a serverului;
- portul pe care serverul va primi trafic;
- portul pentru health check (Monitor healthcheck);
- greutatea (Weight) – cu ajutorul acestui parametru se poate regla cantitatea proporțională de trafic primit pentru un anumit membru al pool-ului;
- Max Connections – numărul maxim de conexiuni către server;
- Min Connections – numărul minim de conexiuni pe care serverul trebuie să le proceseze înainte de a redirecționa traficul către următorul membru al pool-ului.
Iată cum arată pool-ul final din trei servere.
Adăugăm Server Virtual
- Trebuie să trecem la tab-ul Servere Virtuale. Apăsăm +.
- Activăm serverul virtual prin Enable Virtual Server.
Îi dăm un nume, alegem Application Profile, Pool create anterior și specificăm adresa IP la care Serverul Virtual va accepta cereri din exterior. Specificăm protocolul HTTPS și portul 443.
Parametrii opționali aici:
Limită de Conexiuni – numărul maxim de conexiuni simultane pe care le poate gestiona serverul virtual;
Limită de Rată a Conexiunilor (CPS) – numărul maxim de cereri noi de intrare pe secundă.
Configurarea echilibrașului de sarcină este acum finalizată, iar funcționalitatea acestuia poate fi verificată. Serverele au o configurație simplă care permite înțelegerea care server din pool a gestionat cererea. În timpul configurării, am ales algoritmul de echilibrare Round Robin, iar parametrul Weight pentru fiecare server este egal cu unu, astfel încât fiecare cerere ulterioară va fi gestionată de următorul server din pool.
Introducem în browser adresa externă a echilibrașului de sarcină și vedem:
După actualizarea paginii, cererea va fi gestionată de următorul server:
Și încă o dată – pentru a verifica și al treilea server din pool:
La verificare, putem vedea că certificatul pe care ni-l trimite Edge este același pe care l-am generat la început.
Verificarea stării echilibrașului de sarcină din consola Edge gateway. Pentru aceasta, introduceți show service loadbalancer pool.
Configurăm Service Monitor pentru a verifica starea serverelor din pool
Cu ajutorul Service Monitor putem urmări starea serverelor din pool-ul backend. Dacă răspunsul la cerere nu corespunde așteptărilor, serverul poate fi exclus din pool, astfel încât să nu primească cereri noi.
Implicit, sunt configurate trei metode de verificare:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Vom crea unul nou.
- Trecem la tab-ul Service Monitoring, apăsăm +.
- Alegerile sunt:
- numele pentru noua metodă;
- intervalul la care vor fi trimise cererile,
- timpul de așteptare pentru răspuns,
- tipul de monitorizare – cerere HTTPS folosind metoda GET, codul de stare așteptat – 200(OK) și URL-ul cererii.
- Aceasta este configurația noului Service Monitor, acum o putem folosi la crearea pool-ului.
Configurăm Reguli pentru Aplicații
Regulile pentru Aplicații – un mod de manipulare a traficului bazat pe anumite declanșatoare. Cu ajutorul acestui instrument, putem crea reguli avansate de echilibrare a sarcinii, configurația cărora poate fi imposibilă prin intermediul Application profiles sau folosind alte servicii disponibile pe Edge Gateway.
- Pentru a crea o regulă, mergem la fila Application Rules a echilibratorului.
- Alegem un nume, scriptul care va folosi regula și dăm click pe Keep.
- După ce regula este creată, trebuie să edităm Serverul Virtual deja configurat.
- În fila Advanced adăugăm regula pe care am creat-o.
În exemplul de mai sus, am activat suportul pentru tlsv1.
Încă câteva exemple:
Redirectarea traficului către un alt pool.
Cu acest script putem redirecționa traficul către un alt pool de echilibrare, dacă pool-ul principal nu funcționează. Pentru ca regula să funcționeze, trebuie să existe configurate mai multe pool-uri pe echilibrator, iar toți membrii pool-ului principal trebuie să fie în stare down. Trebuie specificat numele pool-ului, nu ID-ul acestuia.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirectarea traficului către o resursă externă.
Aici redirecționăm traficul către un site web extern, dacă toți participanții pool-ului principal sunt în stare down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Încă și mai multe exemple .
Asta a fost tot despre echilibrator. Dacă mai aveți întrebări, întrebați, sunt pregătit să răspund.
Sursa: habr.com
