Ultima dată am vorbit despre capacitățile NSX Edge în ceea ce privește rutarea statică și dinamică, iar astăzi ne vom ocupa de load balancer.
Înainte de a începe configurarea, aș dori să vă reamintesc pe scurt despre principalele tipuri de echilibrare.
Теория
Toate soluțiile de echilibrare a sarcinii utile de astăzi sunt cel mai adesea împărțite în două categorii: echilibrare la nivelul al patrulea (transport) și al șaptelea (aplicație) al modelului . Modelul OSI nu este cel mai bun punct de referință atunci când descrie metodele de echilibrare. De exemplu, dacă un echilibrator L4 acceptă și terminarea TLS, atunci devine un echilibrator L7? Dar este ceea ce este.
- Balancer L4 cel mai adesea este un proxy de mijloc care se află între client și un set de backend-uri disponibile, care termină conexiunile TCP (adică răspunde independent la SYN), selectează un backend și inițiază o nouă sesiune TCP în direcția sa, trimițând independent SYN. Acest tip este unul dintre cele de bază, alte opțiuni sunt posibile.
- Balancer L7 distribuie traficul pe backend-urile disponibile „mai sofisticat” decât face echilibrul L4. Poate decide ce backend să aleagă în funcție, de exemplu, de conținutul mesajului HTTP (URL, cookie etc.).
Indiferent de tip, balansierul poate suporta următoarele funcții:
- Descoperirea serviciului este procesul de determinare a setului de backend-uri disponibile (Static, DNS, Consul, Etcd etc.).
- Verificarea funcționalității backend-urilor detectate („ping” activ al backend-ului folosind o cerere HTTP, detectarea pasivă a problemelor în conexiunile TCP, prezența mai multor coduri HTTP 503 la rând în răspunsuri etc.).
- Echilibrarea în sine (round robin, selecție aleatorie, hash IP sursă, URI).
- Rezilierea TLS și verificarea certificatului.
- Opțiuni legate de securitate (autentificare, prevenirea atacurilor DoS, limitarea vitezei) și multe altele.
NSX Edge oferă suport pentru două moduri de implementare a echilibrului de încărcare:
Modul proxy sau cu un singur braț. În acest mod, NSX Edge își folosește adresa IP ca adresă sursă atunci când trimite o solicitare către unul dintre backend-uri. Astfel, echilibratorul îndeplinește simultan funcțiile NAT sursă și destinație. Backend-ul vede tot traficul ca fiind trimis de la echilibrator și răspunde direct la acesta. Într-o astfel de schemă, echilibrerul trebuie să fie în același segment de rețea cu serverele interne.
Iată cum merge:
1. Utilizatorul trimite o solicitare la adresa VIP (adresa de echilibrare) care este configurată pe Edge.
2. Edge selectează unul dintre backend-uri și efectuează NAT de destinație, înlocuind adresa VIP cu adresa backend-ului selectat.
3. Edge realizează NAT sursă, înlocuind adresa utilizatorului care a trimis cererea cu propria sa.
4. Pachetul este trimis la backend-ul selectat.
5. Backend-ul nu răspunde direct utilizatorului, ci Edge, deoarece adresa inițială a utilizatorului a fost schimbată cu adresa echilibrantului.
6. Edge transmite utilizatorului răspunsul serverului.
Diagrama este mai jos.
Mod transparent sau inline. În acest scenariu, echilibrerul are interfețe pe rețelele interne și externe. În același timp, nu există acces direct la rețeaua internă din cea externă. Echilibratorul de încărcare încorporat acționează ca o poartă NAT pentru mașinile virtuale din rețeaua internă.
Mecanismul este după cum urmează:
1. Utilizatorul trimite o solicitare la adresa VIP (adresa de echilibrare) care este configurată pe Edge.
2. Edge selectează unul dintre backend-uri și efectuează NAT de destinație, înlocuind adresa VIP cu adresa backend-ului selectat.
3. Pachetul este trimis la backend-ul selectat.
4. Backend-ul primește o solicitare cu adresa originală a utilizatorului (sursa NAT nu a fost efectuată) și răspunde direct la aceasta.
5. Traficul este din nou acceptat de echilibrator de încărcare, deoarece într-o schemă inline, acesta acționează de obicei ca gateway implicit pentru ferma de servere.
6. Edge efectuează NAT sursă pentru a trimite trafic către utilizator, folosind VIP-ul său ca adresă IP sursă.
Diagrama este mai jos.
Practică
Bancul meu de testare are 3 servere care rulează Apache, care este configurat să funcționeze prin HTTPS. Edge va efectua o echilibrare round robin a cererilor HTTPS, transferând fiecare cerere nouă către un nou server.
Să începem.
Generarea unui certificat SSL care va fi utilizat de NSX Edge
Puteți importa un certificat CA valid sau puteți utiliza unul autosemnat. Pentru acest test voi folosi autosemnatul.
- În interfața vCloud Director, accesați setările serviciilor Edge.
- Accesați fila Certificate. Din lista de acțiuni, selectați adăugarea unui nou CSR.
- Completați câmpurile obligatorii și faceți clic pe Păstrați.
- Selectați CSR-ul nou creat și selectați opțiunea de auto-semnare CSR.
- Selectați perioada de valabilitate a certificatului și faceți clic pe Păstrați
- Certificatul autosemnat apare în lista celor disponibile.
Configurarea profilului aplicației
Profilurile aplicației vă oferă un control mai complet asupra traficului de rețea și fac gestionarea acestuia simplă și eficientă. Ele pot fi folosite pentru a defini comportamentul pentru anumite tipuri de trafic.
- Accesați fila Load Balancer și activați echilibrul. Opțiunea activată Accelerație aici permite echilibratorului să folosească o echilibrare L4 mai rapidă în loc de L7.
- Accesați fila Profil aplicație pentru a seta profilul aplicației. Faceți clic pe +.
- Setați numele profilului și selectați tipul de trafic pentru care se va aplica profilul. Să explic niște parametri.
Persistență – stochează și urmărește datele de sesiune, de exemplu: care server specific din pool deservește cererea utilizatorului. Acest lucru asigură că solicitările utilizatorilor sunt direcționate către același membru al pool-ului pe durata de viață a sesiunii sau a sesiunilor ulterioare.
Activați trecerea SSL – Când este selectată această opțiune, NSX Edge nu mai termina SSL. În schimb, terminarea are loc direct pe serverele care sunt echilibrate.
Inserați antetul HTTP X-Forwarded-For – vă permite să determinați adresa IP sursă a clientului care se conectează la serverul web prin echilibrul de încărcare.
Activați SSL pentru piscină – vă permite să specificați că pool-ul selectat este format din servere HTTPS.
- Deoarece voi echilibra traficul HTTPS, trebuie să activez Pool Side SSL și să selectez certificatul generat anterior în fila Virtual Server Certificates -> Service Certificate.
- În mod similar, pentru Certificate de grup -> Certificat de serviciu.
Creăm un pool de servere, al cărui trafic va fi echilibrat Pool-uri
- Accesați fila Pools. Faceți clic pe +.
- Setăm numele pool-ului, selectăm algoritmul (voi folosi round robin) și tipul de monitorizare pentru backend-ul de verificare a stării de sănătate Opțiunea Transparent indică dacă IP-urile sursei inițiale ale clienților sunt vizibile pentru serverele interne.
- Dacă opțiunea este dezactivată, traficul pentru serverele interne provine de la IP-ul sursă al echilibrantului.
- Dacă opțiunea este activată, serverele interne văd IP-ul sursă al clienților. În această configurație, NSX Edge trebuie să acționeze ca gateway implicit pentru a se asigura că pachetele returnate trec prin NSX Edge.
NSX acceptă următorii algoritmi de echilibrare:
- IP_HASH – selectarea serverului pe baza rezultatelor unei funcții hash pentru IP-ul sursă și destinație a fiecărui pachet.
- LEASTCONN – echilibrarea conexiunilor de intrare, în funcție de numărul deja disponibil pe un anumit server. Noile conexiuni vor fi direcționate către serverul cu cele mai puține conexiuni.
- ROUND_ROBIN – noi conexiuni sunt trimise pe rând către fiecare server, în conformitate cu ponderea care i-a fost atribuită.
- URI – partea din stânga a URI-ului (înainte de semnul întrebării) este hashing și împărțită la greutatea totală a serverelor din pool. Rezultatul indică ce server primește cererea, asigurându-se că cererea este întotdeauna direcționată către același server, atâta timp cât toate serverele rămân disponibile.
- HTTPHEADER – echilibrare bazată pe un antet HTTP specific, care poate fi specificat ca parametru. Dacă antetul lipsește sau nu are nicio valoare, se aplică algoritmul ROUND_ROBIN.
- URL-ul – Fiecare cerere HTTP GET caută parametrul URL specificat ca argument. Dacă parametrul este urmat de un semn egal și o valoare, atunci valoarea este hashing și împărțită la greutatea totală a serverelor care rulează. Rezultatul indică ce server primește cererea. Acest proces este utilizat pentru a ține evidența ID-urilor de utilizator din solicitări și pentru a se asigura că același ID de utilizator este întotdeauna trimis la același server, atâta timp cât toate serverele rămân disponibile.
- În blocul Membri, faceți clic pe + pentru a adăuga servere la pool.
Aici trebuie să specificați:- numele serverului;
- Adresa IP a serverului;
- portul pe care serverul va primi trafic;
- port pentru verificarea stării de sănătate (Monitor healthcheck);
- greutate – folosind acest parametru puteți ajusta cantitatea proporțională de trafic primită pentru un anumit membru al pool-ului;
- Max Connections – numărul maxim de conexiuni la server;
- Conexiuni minime – numărul minim de conexiuni pe care serverul trebuie să le proceseze înainte ca traficul să fie redirecționat către următorul membru al pool-ului.
Așa arată grupul final de trei servere.
Adăugarea serverului virtual
- Accesați fila Servere virtuale. Faceți clic pe +.
- Activăm serverul virtual folosind Enable Virtual Server.
Îi dăm un nume, selectăm Profilul de Aplicație creat anterior, Pool și indicăm adresa IP la care Serverul Virtual va primi solicitări din exterior. Specificăm protocolul HTTPS și portul 443.
Parametri opționali aici:
Limită de conectare – numărul maxim de conexiuni simultane pe care le poate procesa serverul virtual;
Limită de rată de conectare (CPS) – numărul maxim de solicitări noi primite pe secundă.
Acest lucru completează configurația balansierului; puteți verifica funcționalitatea acestuia. Serverele au o configurație simplă care vă permite să înțelegeți ce server din pool a procesat cererea. În timpul instalării, am ales algoritmul de echilibrare Round Robin, iar parametrul Greutate pentru fiecare server este egal cu unul, astfel încât fiecare cerere ulterioară va fi procesată de următorul server din pool.
Introducem adresa externă a echilibrantului în browser și vedem:
După reîmprospătarea paginii, cererea va fi procesată de următorul server:
Și din nou - pentru a verifica al treilea server din pool:
La verificare, puteți vedea că certificatul pe care ni-l trimite Edge este același pe care l-am generat la început.
Verificarea stării echilibrului din consola gateway-ului Edge. Pentru a face acest lucru, intrați arată pool-ul de echilibrare a încărcării serviciului.
Configurarea Service Monitor pentru a verifica starea serverelor din pool
Folosind Service Monitor putem monitoriza starea serverelor din pool-ul backend. Dacă răspunsul la o solicitare nu este cel așteptat, serverul poate fi scos din pool, astfel încât să nu primească nicio solicitare nouă.
În mod implicit, sunt configurate trei metode de verificare:
- monitor TCP,
- monitor HTTP,
- Monitor HTTPS.
Să creăm unul nou.
- Accesați fila Monitorizare serviciu, faceți clic pe +.
- Alege:
- denumirea noii metode;
- intervalul la care vor fi trimise cererile,
- timeout în așteptarea unui răspuns,
- tip de monitorizare – cerere HTTPS folosind metoda GET, codul de stare așteptat – 200(OK) și adresa URL a solicitării.
- Aceasta completează configurarea noului Service Monitor; acum îl putem folosi atunci când creăm un pool.
Configurarea regulilor de aplicare
Regulile de aplicare sunt o modalitate de a manipula traficul pe baza anumitor declanșatori. Cu acest instrument putem crea reguli avansate de echilibrare a încărcăturii, care ar putea să nu fie posibile prin profilurile de aplicație sau alte servicii disponibile pe Edge Gateway.
- Pentru a crea o regulă, accesați fila Reguli de aplicare a echilibrului.
- Selectați un nume, un script care va folosi regula și faceți clic pe Păstrați.
- După ce regula este creată, trebuie să edităm serverul virtual deja configurat.
- În fila Avansat, adăugați regula pe care am creat-o.
În exemplul de mai sus am activat suportul tlsv1.
Încă câteva exemple:
Redirecționați traficul către alt grup.
Cu acest script, putem redirecționa traficul către un alt pool de echilibrare dacă pool-ul principal este oprit. Pentru ca regula să funcționeze, mai multe pool-uri trebuie să fie configurate pe echilibrator și toți membrii pool-ului principal trebuie să fie în starea dezactivată. Trebuie să specificați 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
Redirecționați traficul către o resursă externă.
Aici redirecționăm traficul către site-ul web extern dacă toți membrii grupului principal nu sunt.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Chiar mai multe exemple .
Asta e tot pentru mine despre echilibrator. Dacă aveți întrebări, întrebați, sunt gata să vă răspund.
Sursa: www.habr.com