Herën e fundit folëm për mundësitë e NSX Edge në kontekstin e ruterëve statikë dhe dinamikë, dhe sot do të merremi me balancuesin.
Para se të fillojmë konfigurimin, do të doja të kujtoja shumë shkurt për llojet kryesore të balancimit.
Teoria
Të gjitha zgjidhjet e sotme për balancimin e ngarkesës zakonisht ndahen në dy kategori: balancimi në nivelin e katërt (transportit) dhe në nivelin e shtatë (aplikativ) të modelit . Modeli OSI nuk është pikë referimi më e mirë kur bëhet fjalë për përshkrimin e metodave të balancimit. Për shembull, nëse balancuesi L4 gjithashtu mbështet përfundimin e TLS, a bëhet ai kështu balancues L7? Por çfarë të bëjmë, është kështu.
- Balancuesi L4 zakonisht përfaqëson një proxy mes klientit dhe grupeve të disponueshme të back-end, i cili përfundon lidhjet TCP (dmth përgjigjet vetë ndaj SYN), zgjedh back-end dhe nisin një sesion të ri TCP në drejtim të tij, duke dërguar autonomisht SYN. Ky lloj është një nga bazikët, dhe janë të mundshme edhe variante të tjera.
- Balancuesi L7 distribuon trafikun në backendet e disponueshme më "të sofistikuar" se sa një balancues L4. Ai mund të vendosë për zgjedhjen e backendit bazuar, për shembull, në përmbajtjen e mesazhit HTTP (URL, cookie, etj.).
Pavarësisht nga lloji, balancuesi mund të mbështesë funksionet e mëposhtme:
- Zbulimi i shĂ«rbimeve â procesi i pĂ«rcaktimit tĂ« grupit tĂ« backend-eve tĂ« disponueshme (Static, DNS, Consul, Etcd, etj.).
- Kontrolli i gatishmërisë së backend-eve të zbuluara (ping aktiv të backend-it me kërkesë HTTP, zbulimi pasiv i problemeve në lidhjet TCP, përfshirja e disa 503 HTTP-code në përgjigje, etj.).
- Balancimi vetë (round robin, seleksion random, hash ip i burimit, URI).
- Terminizimi TLS dhe verifikimi i certifikatave.
- Opsionet që lidhen me sigurinë (autentifikimi, parandalimi i sulmeve DoS, kufizimi i shpejtësisë) dhe shumë më tepër.
NSX Edge ofron mbështetje për dy mënyra implementimi të balancuesit:
Mënyra proxy, ose one-arm. Në këtë mod, NSX Edge përdor IP adresën e tij si adresë burimi kur dërgon një kërkesë në njërën nga backend-et. Kështu, balansuesi kryen njëkohësisht funksionet e NAT-it të Burimit dhe Destinacionit. Backend-i e sheh gjithë trafikun si të dërguar nga balansuesi dhe i përgjigjet direkt atij. Në një këtë skemë, balansuesi duhet të jetë në të njëjtin segment rrjeti me serverët e brendshëm.
Ja si ndodh:
1.       Përdoruesi dërgon një kërkesë në VIP adresën (adresa e balansuesit), e cila është konfiguruar në Edge.
2.       Edge zgjedh njërin nga backend-et dhe kryen NAT-it të destinacionit, duke e zëvendësuar VIP adresën me adresën e backend-it të zgjedhur.
3.       Edge kryen NAT-it të burimit, duke e zëvendësuar adresën e përdoruesit që dërgoi kërkesën me adresën e tij.
4.       Paketa dërgohet te backend-i i zgjedhur.
5.       Backend-i nuk i përgjigjet direkt përdoruesit, por Edge-it, pasi adresa origjinale e përdoruesit ishte ndryshuar në adresën e balansuesit.
6.       Edge-i transmeton përgjigjen e serverit te përdoruesi.
Skema më poshtë.
Rekesi transparente, ose në linjë. Në këtë skenar, balancuesi ka ndërfaqe në rrjetet e brendshme dhe të jashtme. Nuk ka akses të drejtpërdrejt në rrjetin e brendshëm nga ai i jashtmi. Balancuesi i ngarkesës i integruar vepron si një derë NAT për makinat virtuale në rrjetin e brendshëm.
Mekanizmi është si më poshtë:
1.       Përdoruesi dërgon një kërkesë në VIP adresën (adresa e balansuesit), e cila është konfiguruar në Edge.
2.       Edge zgjedh njërin nga backend-et dhe kryen NAT-it të destinacionit, duke e zëvendësuar VIP adresën me adresën e backend-it të zgjedhur.
3. Paketa dërgohet te backend-i i zgjedhur.
4. Backend-i merr kërkesën me adresën origjinale të përdoruesit (nuk është kryer source NAT) dhe i përgjigjet atij direkt.
5. Trafiku pranohet përsëri nga balancuesi i ngarkesës, pasi në skemën inline ai zakonisht vepron si dera e paracaktuar për fermën e serverëve.
6. Edge kryen source NAT për të dërguar trafikun te përdoruesi, duke përdorur VIP-in e tij si adresë IP origjinale.
Skema më poshtë.
Praktika
Në platformën time testuese, janë konfiguruar 3 serverë me Apache, i cili është i vendosur për të punuar përmes HTTPS. Edge do të kryejë balancimin e kërkesave HTTPS me metodën round robin, duke përçuar çdo kërkesë të re në një server të ri.
Le të fillojmë.
Të gjenerojmë një certifikatë SSL, e cila do të përdoret nga NSX Edge.
Mund të importoni një certifikatë CA të vlefshme ose të përdorni një të vetë-nënshkruar. Në këtë test do të përdor një të vetë-nënshkruar.
- Në ndërfaqen vCloud Director, kalojmë te cilësimet e shërbimeve Edge.
- Shkojmë te skeda Certifikatat. Nga lista e veprimeve, zgjidhni shtimin e një CSR të ri.
- Plotësojmë fushat e nevojshme dhe klikojmë Ruaj.
- Zgjidhni CSR-në e sapo krijuar dhe zgjidhni opsionin CSR me vetë-nënshkrim.
- Zgjidhni periudhën e vlefshmërisë së certifikatës dhe klikoni Ruaj.
- Certifikata e vetë-nënshkruar u shfaq në listën e atyre në dispozicion.
Konfiguroni Profilin e Aplikacionit.
Profili i aplikacioneve ofron një kontroll më të plotë mbi trafikun rrjet dhe e bën menaxhimin e tij të thjeshtë dhe efektiv. Me ndihmën e tyre, mund të përcaktoni sjelljen për lloje të caktuara trafiku.
- Shkojmë te skeda Balancuesi i Ngarkesës dhe aktivizojmë balancuesin. Opsioni Aktivizimi i Shpejtësisë këtu e lejon balancuesin të përdorë balancimin më të shpejtë L4 në vend të L7.
- Shkojmë te skeda Profil i Aplikacionit për të caktuar profilin e aplikacionit. Klikoni +.
- Caktoni emrin e profilit dhe zgjidhni llojin e trafikut për të cilin do të aplikohet profili. Do të shpjegoj disa parametra.
Ruajtje â ruan dhe ndjek tĂ« dhĂ«nat e sesionit, si pĂ«r shembull: cila server specifik nga pool-i shĂ«rben kĂ«rkesĂ«n e pĂ«rdoruesit. Kjo siguron qĂ« kĂ«rkesat e pĂ«rdoruesit dĂ«rgohen te i njĂ«jti anĂ«tar i pool-it gjatĂ« gjithĂ« jetĂ«s sĂ« sesionit ose seancave tĂ« mĂ«vonshme.
Aktivizo SSL pĂ«rmes â kur zgjidhet kjo opsion, NSX Edge ndalon pĂ«rfundimin e SSL. NĂ« vend tĂ« kĂ«saj, pĂ«rfundimi ndodh direkt nĂ« serverat pĂ«r tĂ« cilĂ«t bĂ«het balancimi.
Vendosni headerin HTTP X-Forwarded-For â lejon pĂ«rcaktimin e adresĂ«s IP origjinale tĂ« klientit qĂ« lidhet me serverin web nĂ«pĂ«rmjet balancuesit.
Aktivizo SSL nĂ« anĂ«n e Pool-it â lejon tĂ« specifikoni se pool-i i zgjedhur pĂ«rbĂ«het nga servera HTTPS.
- Duke qenĂ« se do tĂ« balancoj trafik HTTPS, duhet tĂ« aktivizoj Pool Side SSL dhe tĂ« zgjedh certifikatĂ«n e generuar mĂ« parĂ« nĂ« skedĂ«n Virtual Server Certificates â> Certifikata e ShĂ«rbimit.
- Po ashtu pĂ«r Certifikatat e Pool-it â> Certifikata e ShĂ«rbimit.
Krijojmë një pool serverash, trafik i cilëve do të balancohet Pools
- Kalojmë në skedën Pools. Klikoni +.
- Vendosni emrin e grupit, zgjidhni algoritmin (unë do të përdor round robin) dhe llojin e monitorimit për kontrollin e shëndetit të backend-it. Opsioni Transparent tregon nëse IP-të burim origjinalë të klientëve janë të dukshme për serverët e brendshëm.
- Nëse opsioni është i çaktivizuar, trafiku për serverët e brendshëm vjen me IP-në burim të balancuesit.
- Nëse opsioni është aktivizuar, serverët e brendshëm shohin IP-të burim të klientëve. Në këtë konfiguracion, NSX Edge duhet të veprojë si porta e paracaktuar për të garantuar që paketat e kthyera kalojnë përmes NSX Edge.
NSX mbështet algoritet e mëposhtme të balancimit:
- IP_HASH â zgjedhja e serverit bazuar nĂ« rezultatet e funksionit hash pĂ«r IP-nĂ« burim dhe destinacion tĂ« çdo pakete.
- LEASTCONN â balancimi i lidhjeve tĂ« hyra, nĂ« varĂ«si tĂ« numrit tĂ« lidhjeve qĂ« tashmĂ« ekzistojnĂ« nĂ« serverin pĂ«rkatĂ«s. Lidhjet e reja do tĂ« drejtohen nĂ« serverin me numrin mĂ« tĂ« vogĂ«l tĂ« lidhjeve.
- ROUND_ROBIN â lidhjet e reja dĂ«rgohen nĂ« çdo server rend pas rendi, nĂ« pĂ«rputhje me peshĂ«n e caktuar atij.
- URI â pjesa e majtĂ« e URI-sĂ« (para pikĂ«s sĂ« pyetjes) Ă«shtĂ« hash-uara dhe e ndanĂ« peshĂ«n e pĂ«rgjithshme tĂ« serverĂ«ve nĂ« grup. Rezultati tregon se cili server merr kĂ«rkesĂ«n, duke garantuar se kĂ«rkesa gjithmonĂ« dĂ«rgohet nĂ« tĂ« njĂ«jtin server, derisa tĂ« gjithĂ« serverĂ«t tĂ« mbeten tĂ« disponueshĂ«m.
- HTTPHEADER â balancimi bazohet nĂ« njĂ« titull tĂ« caktuar HTTP, i cili mund tĂ« jepet si parametĂ«r. NĂ«se titulli nuk Ă«shtĂ« prezent ose nuk ka ndonjĂ« vlerĂ«, aplikohet algoritmi ROUND_ROBIN.
- URL â nĂ« çdo kĂ«rkesĂ« HTTP GET, bĂ«het njĂ« kĂ«rkim sipas parametrin URL qĂ« Ă«shtĂ« specifikuar si argument. NĂ«se pas parametrin ndodhet njĂ« barazim dhe njĂ« vlerĂ«, atĂ«herĂ« vlera Ă«shtĂ« hash-uar dhe ndarĂ« nĂ« peshĂ«n e pĂ«rgjithshme tĂ« serverĂ«ve tĂ« aktivizuar. Rezultati tregon se cili server merr kĂ«rkesĂ«n. Ky proces pĂ«rdoret pĂ«r tĂ« ndjekur identifikuesit e pĂ«rdoruesve nĂ« kĂ«rkesa dhe pĂ«r tĂ« siguruar qĂ« i njĂ«jti user id gjithmonĂ« dĂ«rgohet nĂ« tĂ« njĂ«jtin server, derisa tĂ« gjithĂ« serverĂ«t tĂ« mbeten tĂ« disponueshĂ«m.
- Në bllokun Members, klikoni + për të shtuar serverët në grup.
Këtu duhet të shkruani:- emrin e serverit;
- IP adresën e serverit;
- porta për të cilën serveri do të pranojë trafik;
- porta për kontrollin e shëndetit (Monitor healthcheck);
- peshĂ« (Weight) â me kĂ«tĂ« parametrin mund tĂ« rregulloni sasinĂ« proporcionale tĂ« trafik tĂ« pranuar pĂ«r njĂ« anĂ«tar tĂ« caktuar tĂ« grupit;
- Max Connections â numri maksimal i lidhjeve me serverin;
- Min Connections â numri minimal i lidhjeve qĂ« serveri duhet tĂ« pĂ«rpunojĂ« pĂ«rpara se trafiku tĂ« redirektohet te anĂ«tari tjetĂ«r i grupit.
Kështu duket grupi përfundimtar i tre serverëve.
Shtojmë Serverin Virtual
- Kalim te tabi Virtual Servers. Shtypni +.
- Aktivizoni serverin virtual me Enable Virtual Server.
I caktojmë emrin, zgjedhim Application Profile dhe Pool të krijuar më parë dhe tregojmë adresën IP, në të cilën Serveri Virtual do të pranojë kërkesat nga jashtë. Caktojmë protokollin HTTPS dhe portin 443.
Parametrat opcionale këtu:
Connection Limit â numri maksimal i lidhjeve tĂ« pĂ«rkohshme qĂ« mund tĂ« pĂ«rpunojĂ« serveri virtual;
Connection Rate Limit (CPS) â numri maksimal i kĂ«rkesave tĂ« reja qĂ« hyjnĂ« pĂ«r sekondĂ«.
Në këtë konfigurim, balancuesi përfundon, dhe mund të kontrolloni funksionalitetin e tij. Serverat kanë një konfigurim të thjeshtë që lejon të kuptoni se cilit server nga grupi i përgjigjet kërkesa. Gjatë konfigurimit, zgjodhëm algoritmin e balansimit Round Robin, dhe parametri Pesha për secilin server është një, prandaj çdo kërkesë e ardhshme do të trajtohet nga serveri tjetër në grup.
Shkruajmë në shfletues adresën e jashtme të balancuesit dhe shohim:
Pas përditësimit të faqes, kërkesa do të trajtohet nga serveri tjetër:
Dhe përsëri - për të kontrolluar serverin e tretë në grup:
Gjatë kontrollit, mund të shihni se certifikata që na dërgon Edge është ajo që ne e gjeneruam në fillim.
Kontrolli i statusit të balancuesit nga konsola e Edge gateway. Për këtë, shkruani show service loadbalancer pool.
Konfigurojmë Monitorin e Shërbimit për të kontrolluar gjendjen e serverëve në grup
Me ndihmën e Monitorit të Shërbimit, mund të ndjekim gjendjen e serverëve në grupin e pasëm. Nëse përgjigja për kërkesën nuk përputhet me atë që pritet, mund të nxjerrim serverin nga grupi që të mos marrë kërkesa të reja.
Për default janë konfiguruar tre metoda verifikimi:
- TCP-monitor,
- Monitorimi HTTP,
- Monitorimi HTTPS.
Të krijojmë një të ri.
- Shkoni te skeda Monitorimi i Shërbimeve, klikoni +.
- Zgjidhni:
- emrin për metodën e re;
- intervali me të cilin do të dërgohen kërkesat,
- koha e pritjes për përgjigje,
- tipi i monitorimit â kĂ«rkesĂ« HTTPS me metodĂ«n GET, kodi i statusit i pritur â 200(OK) dhe URL e kĂ«rkesĂ«s.
- Këtu përfundojmë konfigurimin e monitorit të ri të shërbimeve, tani mund ta përdorim atë kur krijojmë një grup.
Konfiguroni Rregullat e Aplikacionit
Rregullat e Aplikacionit â njĂ« mĂ«nyrĂ« pĂ«r tĂ« manipuluar trafik, tĂ« bazuar nĂ« triger tĂ« caktuar. Me kĂ«tĂ« mjet ne mund tĂ« krijojmĂ« rregulla tĂ« avancuara tĂ« balancimit tĂ« ngarkesĂ«s, konfigurimi i tĂ« cilave mund tĂ« jetĂ« i pamundur pĂ«rmes profileve tĂ« aplikacionit ose me shĂ«rbime tĂ« tjera tĂ« disponueshme nĂ« Edge Gateway.
- Për të krijuar një rregull kaloni te skeda Rregullat e Aplikacionit të balancuesit.
- Zgjidhni emrin, skenarin që do të përdorë rregulli, dhe klikoni Ruaj.
- Pas krijimit të rregullit, na nevojitet të redaktojmë serverin virtual tashmë të konfiguruar.
- Në skedën Avancuar shtojmë rregullin që krijuam.
Në shembullin e mësipërm kemi aktivizuar mbështetje për tlsv1.
Disa shembuj të tjerë:
Rredirectimi i trafikut në një grup tjetër.
Me këtë skript ne mund të ridrejtoshim trafik në një grup tjetër balancimi nëse grupi kryesor nuk funksionon. Për të funksionuar rregulla, në balancuesin duhet të jenë konfiguruar disa grupe dhe të gjithë anëtarët e grupit kryesor duhet të jenë në gjendje down. Duhet të tregoni saktësisht emrin e grupit, jo ID-në e tij.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Ridrejtimi i trafikut në një burim të jashtëm.
Këtu ne ridrejtoshim trafik në një sit të jashtëm, nëse të gjithë pjesëtarët e grupit kryesor janë në gjendje down.
acl pool_down nbsrv(NUMRI_I_PULLES) eq 0
redirigj vendndodhjen http://www.example.com nese pool_down
Më shumë shembuj .
Kjo është për balancuesin nga ana ime. Nëse keni pyetje, mos hezitoni të pyesni, unë jam në dispozicion për t'u përgjigjur.
Burimi: habr.com
