VMware NSX za najmanjše. Del 5. Nastavitev ravnotežja obremenitve

Prvi del. Uvod
Drugi del. Konfiguracija pravilnika za požarni zid in NAT
Tretji del. Konfiguracija DHCP
Četrti del. Konfiguracija usmerjanja

Nazadnje smo govorili o funkcionalnostih NSX Edge v kontekstu statičnega in dinamičnega usmerjanja, danes pa se bomo poglobili v uravnoteževalnik.
Preden začnemo s konfiguracijo, bi rad na kratko spomnil na glavne vrste uravnoteženja.

Teorija

Vse današnje rešitve za uravnoteženje obremenitve delimo na dve kategoriji: uravnoteženje na četrti (transportni) in sedmi (aplikacijski) ravni modela. OSIModel OSI ni najboljša referenčna točka pri opisu metod uravnoteženja. Na primer, če L4-uravnoteževalnik podpira tudi zaključenje TLS, ali postane v tem primeru L7-uravnoteževalnik? Toda kar imamo, imamo.

• L4-uravnoteževalnik pogosto služi kot srednji proxy med stranko in sklopom razpoložljivih backendov, ki zaključi TCP-povezave (to pomeni, da samodejno odgovarja na SYN), izbira backend in začenja novo TCP-sejo v njegovo smer ter samodejno pošilja SYN. Ta tip je osnovni, možne so tudi druge variante.
• L7-uravnoteževalnik porazdeli promet po razpoložljivih backendih na 'naprednejši' način kot to stori L4-uravnoteževalnik. Odločitev o izbiri backend lahko sprejme na osnovi, na primer, vsebine HTTP-sporočila (URL, piškotek itd.).

Ne glede na tip lahko uravnoteževalnik podpira naslednje funkcije:

• Odkritje storitev – proces določanja nabora razpoložljivih backendov (Static, DNS, Consul, Etcd itd.).
• Preverjanje delovanja odkritih backendov (aktivni 'ping' backend z uporabo HTTP-loga, pasivno odkrivanje težav v TCP-povezavah, prisotnost več zaporednih 503 HTTP-kod v odgovorih itd.).
• Samo uravnoteženje (round robin, naključna izbira, hash izvorne IP, URI).
• Zaključitev TLS in preverjanje certifikatov.
• Možnosti, povezane z zagotavljanjem varnosti (avtorizacija, preprečevanje DoS napadov, omejevanje hitrosti) in še več.

NSX Edge ponuja podporo za dva načina delovanja uravnoteževalnika:

Proxy način, ali one-arm. V tem načinu NSX Edge pri pošiljanju zahteve na enega od backendov uporablja svoj IP-naslov kot izvorni naslov. Tako uravnovalnik opravlja funkcije Source in Destination NAT hkrati. Backend vidi ves promet kot poslan z uravnovalnika in mu neposredno odgovarja. V takšni shemi mora biti uravnovalnik v istem omrežnem segmentu z notranjimi strežniki.

Tako to deluje:
1.      Uporabnik pošlje zahtevo na VIP-naslov (naslov uravnovalnika), ki je konfiguriran na Edge.
2.      Edge izbere enega od backendov in izvede destination NAT, pri čemer zamenja VIP-naslov z naslovom izbranega backend.
3.      Edge izvede source NAT, pri čemer zamenja naslov pošiljatelja z naslovom zase.
4.      Paketa se pošlje izbranemu backendu.
5.      Backend ne odgovarja neposredno uporabniku, ampak Edgeu, saj je bil prvotni naslov uporabnika spremenjen v naslov uravnovalnika.
6.      Edge posreduje odgovor strežnika uporabniku.
Spodnja shema.


Prozoren, ali inline, način. V tem scenariju ima uravnovalnik vmesnike v notranjem in zunanjem omrežju. Pri tem ni neposrednega dostopa do notranjega omrežja iz zunanje. Vgrajeni uravnovalnik obremenitve deluje kot NAT prehod za virtualne stroje v notranjem omrežju.

Mehanizem je naslednji:
1.      Uporabnik pošlje zahtevo na VIP-naslov (naslov uravnovalnika), ki je konfiguriran na Edge.
2.      Edge izbere enega od backendov in izvede destination NAT, pri čemer zamenja VIP-naslov z naslovom izbranega backend.
3.      Paketa se pošlje izbranemu backendu.
4.      Backend prejme zahtevo s prvotnim naslovom uporabnika (source NAT ni bil izveden) in mu neposredno odgovarja.
5.      Promet ponovno prevzame uravnovalnik obremenitve, saj običajno v inline shemi deluje kot privzeti prehod za farmo strežnikov.
6.      Edge izvede source NAT za pošiljanje prometa uporabniku, pri čemer uporablja svoj VIP kot izvorni IP-naslov.
Spodnja shema.

Praktika

Na mojem testnem okolju sta nastavljena 3 strežnika z Apache, ki je konfiguriran za delovanje prek HTTPS. Edge bo izvajal obremenitev HTTPS-zahtev po metodi round robin, pri čemer bo vsak nov zahtevek poslal na nov strežnik.
Pričnimo.

Generiramo SSL-certifikat, ki ga bo uporabljal NSX Edge
Lahko uvozite veljaven CA-certifikat ali uporabite samopodpisanega. V tem testu bom uporabil samopodpisanega.

1. V vmesniku vCloud Director preidite na nastavitve storitev Edge.
   
2. Preidite na zavihek Certifikati. Iz seznama dejanj izberite dodajanje novega CSR.
   
3. Izpolnite potrebna polja in pritisnite Keep.
   
4. Izberite pravkar ustvarjen CSR in izberite možnost self-sign CSR.
   
5. Izberemo trajanje veljavnosti potrdila in pritisnemo Keep.
   
6. Samopodpisano potrdilo se je pojavilo na seznamu razpoložljivih.
   

Nastavimo Application Profile.
Profil aplikacije daje popoln nadzor nad omrežnim prometom in poenostavi njegovo upravljanje. Z njihovo pomočjo lahko določite vedenje za specifične tipe prometa.

1. Pojdite na zavihek Load Balancer in vklopite uravnoteževalnik. Možnost Acceleration enabled tukaj omogoča uravnoteževalniku uporabo hitrejše L4 uravnoteženja namesto L7.
   
2. Pojdite na zavihek Application profile, da nastavite profil aplikacije. Pritisnite +.
   
3. Določite ime profila in izberite tip prometa, na katerega se bo profil uporabil. Pojasnil bom nekatere parametre.
   Persistence – shranjuje in spremlja podatke seje, na primer: kateri točno strežnik iz bazena obravnava uporabniški zahtevek. To zagotavlja, da so uporabniški zahtevki usmerjeni k istemu članu bazena v celotnem trajanju seje ali v nadaljnjih sejah.
   Enable SSL passthrough – pri izbiri te možnosti NSX Edge preneha terminirati SSL. Namesto tega se terminacija izvede neposredno na strežnikih, za katere se izvaja uravnoteženje.
   Insert X-Forwarded-For HTTP header – omogoča določitev izvornega IP-naslova odjemalca, ki se povezuje na spletni strežnik preko uravnoteževalnika.
   Enable Pool Side SSL – omogoča določitev, da izbrani bazen vsebuje HTTPS-strežnike.
   
4. Ker bom uravnotežil HTTPS-promet, je treba omogočiti Pool Side SSL in izbrati prej generirano potrdilo na zavihku Virtual Server Certificates —> Service Certificate.
   
5. Podobno za Pool Certificates —> Service Certificate.
   

Ustvarimo bazen strežnikov, katerega promet bo uravnotežen Pools

1. Pojdite na zavihek Pools. Pritisnite +.
   
2. Določite ime bazena, izberite algoritem (jaz bom uporabil round robin) in vrsto spremljanja za health check zadnje naprave. Možnost Transparent označuje, ali so izvorni IP-ji odjemalcev vidni notranjim strežnikom.
   • Če je možnost izklopljena, promet za notranje strežnike prihaja z IP-naslova uravnoteževalnika.
   • Če je možnost vključena, notranji strežniki vidijo izvorni IP odjemalcev. V takšni konfiguraciji mora NSX Edge delovati kot privzeti usmerjevalnik, da zagotovi, da se vračajoči paketi preusmerjajo preko NSX Edge.

   NSX podpira naslednje algoritme uravnoteženja:

   • IP_HASH – izbira strežnika na podlagi rezultatov izvajanja hash funkcije za izvorni in cilj IP vsakega paketa.
   • LEASTCONN – uravnoteženje prihajajočih povezav glede na že obstoječe povezave na določenem strežniku. Nove povezave bodo usmerjene na strežnik z najmanjšim številom povezav.
   • ROUND_ROBIN – nove povezave se po vrsti pošljejo vsakemu strežniku v skladu z dodeljeno težo.
   • URI – leva del URI (pred vprašajem) se hashira in deli s skupno težo strežnikov v skupini. Rezultat določa, kateri strežnik prejme zahtevo, kar zagotavlja, da se zahteva vedno usmeri na isti strežnik, dokler so vsi strežniki dostopni.
   • HTTPHEADER – uravnoteženje na podlagi določenega HTTP naslednika, ki ga lahko navedemo kot parameter. Če naslednik ni prisoten ali nima vrednosti, se uporablja algoritem ROUND_ROBIN.
   • URL – v vsaki HTTP GET zahtevi se išče parameter URL, naveden kot argument. Če parameter sledi enakosti in vrednosti, se ta vrednost hashira in deli s skupno težo zagnanih strežnikov. Rezultat določa, kateri strežnik prejme zahtevo. Ta postopek se uporablja za sledenje identifikatorjem uporabnikov v zahtevah in zagotavljanje, da se isti uporabniški ID vedno pošlje na isti strežnik, dokler so vsi strežniki dostopni.

   

3. V razdelku Člani pritisnemo +, da dodamo strežnike v skupino.
   
   
   Tu je potrebno navesti:
   • ime strežnika;
   • IP naslov strežnika;
   • port, na katerega bo strežnik prejemal promet;
   • port za health check (Nadzor zdravja);
   • teža (Weight) – s tem parametrom lahko uravnate proporcionalno količino prejetega prometa za določenega člana skupine;
   • Max Connections – največje število povezav do strežnika;
   • Min Connections – najmanjše število povezav, ki jih mora obdelati strežnik, preden se promet preusmeri na naslednjega člana skupine.

   
   
   Tako izgleda končna skupina treh strežnikov.
   

Dodajamo Virtual Server

1. Preklopimo na zavihek Virtual Servers. Pritisnemo +.
   
2. Aktiviramo virtualni strežnik z Enable Virtual Server.
   Določimo mu ime, izberemo prej ustvarjen Application Profile, Pool in navedemo IP-naslov, na katerega bo Virtual Server prejemal zahteve od zunaj. Navedemo protokol HTTPS in pristanišče 443.
   Opcijski parametri so tu:
   Omejitev povezav – največje število hkratnih povezav, ki jih lahko obdela virtualni strežnik;
   Omejitev hitrosti povezav (CPS) – največje število novih prihajajočih zahtev na sekundo.
   

S to konfiguracijo ravnotežnika je končano, zdaj lahko preverimo njegovo delovanje. Strežniki imajo najpreprostejšo konfiguracijo, ki omogoča razumevanje, kateri strežnik iz bazena je obdelal zahtevo. Med nastavljanjem smo izbrali algoritem uravnoteženja Round Robin, parameter Weight za vsak strežnik pa je enak ena, zato bo vsaka naslednja zahteva obdelana z naslednjim strežnikom iz bazena.
V vnosno polje brskalnika vnesemo zunanji naslov ravnotežnika in vidimo:


Po osvežitvi strani bo zahtevo obdelal naslednji strežnik:


In še enkrat – da preverimo tudi tretji strežnik iz bazena:


Med preverjanjem lahko vidimo, da je certifikat, ki nam ga pošilja Edge, prav tisti, ki smo ga generirali na samem začetku.

Preverjanje statusa ravnotežnika iz konzole Edge gateway. Za to vnesite show service loadbalancer pool.


Nastavljamo Service Monitor za preverjanje stanja strežnikov v bazenu
S pomočjo Service Monitorja lahko spremljamo stanje strežnikov v back-end bazenu. Če odgovor na zahtevo ne ustreza pričakovanemu, lahko strežnik izločimo iz bazena, da ne bo prejemal novih zahtev.
Privzeto so konfigurirani trije metode preverjanja:

• TCP-monitor,
• HTTP-monitor,
• HTTPS-monitor.

Ustvarimo novega.

1. Pojdite na zavihek Service Monitoring, kliknite +.
   
2. Izberemo:
   • ime za novo metodo;
   • interval, s katerim bodo pošiljane zahteve,
   • čakanje na odgovor,
   • tip monitoringa – HTTPS zahteva z uporabo metode GET, pričakovana statusna koda – 200(OK) in URL zahteve.
3. S tem je nastavitev novega Service Monitorja končana, zdaj ga lahko uporabimo pri ustvarjanju bazena.
   

Nastavljamo Application Rules

Application Rules – način manipulacije s prometom, ki temelji na določenih sprožilcih. S tem orodjem lahko ustvarimo razširjena pravila uravnoteženja obremenitve, katerih nastavitev ni mogoča preko Application profiles ali z drugimi storitvami, dostopnimi na Edge Gateway.

1. Za kreiranje pravila prelazimo na karticu Application Rules balansirnog uređaja.
   
2. Biramo ime, skriptu koja će koristiti pravilo, i kliknemo na Keep.
   
3. Nakon što je pravilo kreirano, potrebno je urediti već postavljeni Virtual Server.
   
4. Na kartici Advanced dodajemo stvoreno pravilo.
   

U gornjem primeru omogućili smo podršku za tlsv1.

Još nekoliko primera:

Preusmeravanje saobraćaja na drugi пул.
Pomoću ove skripte možemo preusmeriti saobraćaj na drugi balansirajući пул, ako glavni пул ne radi. Da bi pravilo funkcionisalo, na balansiru mora biti konfigurisan više пула i svi članovi glavnog пула moraju biti u stanju down. Treba navesti tačno ime пула, a ne njegov ID.

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


Preusmeravanje saobraćaja na spoljašnji resurs.
Ovde preusmeravamo saobraćaj na spoljašnju veb stranicu, ako su svi članovi glavnog пула u stanju down.

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

Još više primera tukaj.

Ovo je sve o balansirniku. Ako imate pitanja, slobodno pitajte, spreman sam da odgovorim.

Izvor: habr.com