Herën e kaluar folëm për mundësitë e NSX Edge në lidhje me routingun statik dhe dinamik, dhe sot do të shqyrtojmë balancuesin.
Para se të fillojmë konfigurimin, do të doja të përmendja shkurtimisht 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 (transport) dhe balancimi në nivelin e shtatë (aplikativ) të modelit . Modeli OSI nuk është pikë reference e shkelqyer kur flasim për metodat e balancimit. Për shembull, nëse një balancues L4 gjithashtu mbështet terminimin TLS, a bëhet ai me këtë rast një balancues L7? Por kjo është situata.
- Balancuesi L4 zakonisht përbën një proxy në mes të klientit dhe një grupi të disponueshëm backend, i cili terminon lidhjet TCP (do të thotë, përgjigjet vetë ndaj SYN), zgjedh backend dhe inicon një seancë të re TCP në drejtim të tij, duke dërguar vetë SYN. Ky tip është një nga bazikët, janë të mundshme dhe variante të tjera.
- Balancuesi L7 distribuon trafikun tek backendet e disponueshme më "sofistikuar" se çfarë bën balancuesi L4. Ai mund të marrë vendime mbi zgjedhjen e backendit në bazë, për shembull, të përmbajtjes së mesazhit HTTP (URL, cookie etj.).
Pavarësisht nga tipi, balancuesi mund të mbështesë funksione të tjera si:
- Zbulimi i shĂ«rbimeve â procesi i identifikimit tĂ« grupit tĂ« backendave tĂ« disponueshĂ«m (Static, DNS, Consul, Etcd etj.).
- Kontrolli i disponueshmërisë së backendave të zbuluar (ping aktiv të backendit me kërkesë HTTP, zbulimi pasiv i problemeve në lidhjet TCP, prania në përgjigje të disa kodeve HTTP 503 njëpasnjëshëm etj.).
- Vetë balancimi (round robin, zgjedhje rastësore, hash i IP burimit, URI).
- Terminimi TLS dhe verifikimi i certifikatat.
- Opsionet e lidhura me sigurinë (autentikimi, parandalimi i sulmeve DoS, kufizimi i shpejtësisë) dhe shumë të tjera.
NSX Edge ofron mbështetje për dy moda të vendosjes së balancuesit:
Rejimi proxy, ose one-arm. Në këtë mënyrë, NSX Edge, kur dërgon një kërkesë te një nga backend-et, përdor adresën e tij IP si adresën burimore. Kështu, balancuesi kryen njëkohësisht funksionet Source dhe Destination NAT. Backend-i e sheh të gjithë trafikun si të dërguar nga balancuesi dhe i përgjigjet drejtpërsëdrejti atij. Në një skemë të tillë, balancuesi duhet të jetë në të njëjtin segment rrjeti me serverat e brendshëm.
Ja si ndodh:
1.       Përdoruesi dërgon një kërkesë për adresën VIP (adresën e balancuesit), e cila është e konfiguruar në Edge.
2.       Edge zgjedh një nga backend-et dhe kryen destination NAT, duke zëvendësuar adresën VIP me adresën e backend-it të zgjedhur.
3.       Edge kryen source NAT, duke 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 përgjigjet jo drejtpërsëdrejti përdoruesit, por Edge-it, pasi adresa fillestare e përdoruesit u ndryshua në adresën e balancuesit.
6.       Edge kalon përgjigjen e serverit te përdoruesi.
Skema më poshtë.
ReĆŸimi transparent ose inline. NĂ« kĂ«tĂ« skenar, balancuesi ka ndĂ«rfaqe nĂ« rrjetin e brendshĂ«m dhe tĂ« jashtĂ«m. NĂ« kĂ«tĂ« rast, nuk ka qasje tĂ« drejtpĂ«rdrejtĂ« nĂ« rrjetin e brendshĂ«m nga jashtĂ«. Balancuesi i ngarkesĂ«s vepron si njĂ« gateway NAT pĂ«r makinat virtuale nĂ« rrjetin e brendshĂ«m.
Mekanizmi është si vijon:
1.       Përdoruesi dërgon një kërkesë për adresën VIP (adresën e balancuesit), e cila është e konfiguruar në Edge.
2.       Edge zgjedh një nga backend-et dhe kryen destination NAT, duke zëvendësuar adresën VIP 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 fillestare të përdoruesit (source NAT nuk është kryer) dhe i përgjigjet asaj drejtpërsëdrejti.
5.       Trafiku përsëri merret nga balancuesi i ngarkesës, pasi në skemën inline ai zakonisht vepron si gateway i parazgjedhur 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 burimore.
Skema më poshtë.
Praktika
Në skenarin tim të testimit, janë konfiguruar 3 serverë me Apache, i cili është konfiguruar për të punuar përmes HTTPS. Edge do të kryejë balancimin e kërkesave HTTPS sipas metodës round robin, duke proxy-uar çdo kërkesë të re në një server të ri.
Le të fillojmë.
Krijojmë një certifikatë SSL, e cila do të përdoret nga NSX Edge
Mund të importoni një certifikatë valide CA ose të përdorni një të vetëshkruar. Në këtë test, unë do të përdor një të vetëshkruar.
- Në ndërfaqen e vCloud Director kalojmë në konfigurimet e shërbimeve Edge.
- Kalojmë në skedën Certifikatat. Nga lista e veprimeve zgjedhim shtimin e një CSR të ri.
- Plotni fushat e nevojshme dhe klikoni mbi Keep.
- Zgjidhni CSR-në e sapor krijuar dhe zgjidhni opsionin self-sign CSR.
- Zgjidhni periudhën e vlefshmërisë të certifikatës dhe klikoni mbi Keep.
- Certifikata e vetë-nënshkruar u shfaq në listën e atyre që janë në dispozicion.
Konfigurojmë Profilin e Aplikacionit
Profilat e aplikacionëve ofrojnë kontroll më të plotë mbi trafikun në rrjet dhe e bëjnë menaxhimin e tij të thjeshtë dhe efektiv. Me ndihmën e tyre, mund të përcaktojmë sjelljen për lloje të veçanta të trafik.
- Kalo në skedën Load Balancer dhe aktivizo balancuesin. Opsioni Acceleration enabled këtu lejon balancuesin të përdorë balancimin më të shpejtë L4 në vend të L7.
- Kalo në skedën Application profile për të vendosur profilin e aplikacionit. Klikoni +.
- Vendosni emrin e profilit dhe zgjidhni llojin e trafik që do të aplikohet për profilin. Do të shpjegoj disa parametra.
PersistencĂ« â ruan dhe ndjek tĂ« dhĂ«nat e sesionit, pĂ«r shembull: cili server i veçantĂ« nga grupi shĂ«rben kĂ«rkesĂ«n e pĂ«rdoruesit. Kjo garanton qĂ« kĂ«rkesat e pĂ«rdoruesit dĂ«rgohen nĂ« tĂ« njĂ«jtin anĂ«tar tĂ« grupit gjatĂ« gjithĂ« jetĂ«s sĂ« sesionit ose sesioneve tĂ« ardhshme.
Aktivizo SSL passthrough â duke zgjedhur kĂ«tĂ« opsion, NSX Edge ndalon terminimin e SSL. NĂ« vend tĂ« kĂ«saj, terminimi ndodh direkt nĂ« serverat pĂ«r tĂ« cilĂ«t kryhet balancimi.
Shto header-in X-Forwarded-For HTTP â lejon pĂ«rcaktimin e IP-nĂ« origjinale tĂ« klientit, qĂ« lidhet me serverin e uebit nĂ«pĂ«rmjet balancuesit.
Aktivizo SSL nĂ« anĂ«n e grupit â lejon ta pĂ«rshkruash se grupi i zgjedhur pĂ«rbĂ«het nga servera HTTPS.
- Pasi do tĂ« balancoj trafik HTTPS, duhet tĂ« aktivizoj SSL-nĂ« nĂ« anĂ«n e grupit dhe tĂ« zgjidh njĂ« certifikatĂ« tĂ« krijuar mĂ« parĂ« nĂ« skedĂ«n Virtual Server Certificates â> Service Certificate.
- E njĂ«jta gjĂ« pĂ«r Pool Certificates â> Service Certificate.
Krijo një grup serverash, trafik për të cilët do të balancohet
- Kalo në skedën Pools. Klikoni +.
- Vendosni emrin e grupit, zgjidhni algoritmin (do të përdor round robin) dhe llojin e monitorimit për kontrollin e shëndetit të backendit. Opsioni Transparent tregon nëse IP-të origjinale të klientëve janë të dukshme për serverat e brendshëm.
- Nëse opsioni është i çaktivizuar, trafiku për serverat e brendshëm shkon me IP-në origjinale të balancuesit.
- Nëse opsioni është aktivizuar, serverat e brendshëm shohin IP-në origjinale të klientëve. Në një konfigurim të tillë, NSX Edge duhet të veprojë si gateway-i i parazgjedhur për të siguruar që paketat e kthimit kalojnë nëpër NSX Edge.
NSX mbështet algoritmet e mëposhtme të balancimit:
- IP_HASH â zgjedhja e serverit nĂ« bazĂ« tĂ« rezultateve tĂ« funksionit hash pĂ«r IP-nĂ« source dhe destination tĂ« çdo pakete.
- LEASTCONN â balancimi i lidhjeve tĂ« ardhshme, nĂ« varĂ«si tĂ« numrit tĂ« lidhjeve qĂ« tashmĂ« ekzistojnĂ« nĂ« serverin pĂ«rkatĂ«s. Lidhjet e reja do tĂ« dĂ«rgohen nĂ« serverin me numrin mĂ« tĂ« vogĂ«l tĂ« lidhjeve.
- ROUND_ROBIN â lidhjet e reja dĂ«rgohen nĂ« çdo server nĂ« mĂ«nyrĂ« tĂ« rregullt, nĂ« pĂ«rputhje me peshĂ«n qĂ« i Ă«shtĂ« caktuar.
- URI â pjesa e majtĂ« e URI (deri te pika e pyetjeve) hash-it dhe ndahet nĂ« peshĂ«n totale tĂ« serverĂ«ve nĂ« grup. Rezultati tregon se cili server merr kĂ«rkesĂ«n, duke garantuar qĂ« kĂ«rkesa gjithmonĂ« dĂ«rgohet nĂ« tĂ« njĂ«jtin server, pĂ«r sa kohĂ« qĂ« tĂ« gjithĂ« serverĂ«t mbeten tĂ« aksesueshĂ«m.
- HTTPHEADER â balancimi nĂ« bazĂ« tĂ« njĂ« header-i tĂ« caktuar HTTP, i cili mund tĂ« vihet si parametrik. NĂ«se header-i mungon ose nuk ka ndonjĂ« vlerĂ«, aplikohet algoritmi ROUND_ROBIN.
- URL â nĂ« çdo kĂ«rkesĂ« HTTP GET, bĂ«het njĂ« kĂ«rkim mbi parametrin e URL-sĂ«, tĂ« caktuar si argument. NĂ«se pas parametrin ka njĂ« barazim dhe vlerĂ«, atĂ«herĂ« vlera hash-it dhe ndahet nĂ« peshĂ«n totale 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Ă« id e njĂ«soj pĂ«rdoruesi gjithmonĂ« dĂ«rgohet nĂ« tĂ« njĂ«jtin server, pĂ«r sa kohĂ« qĂ« tĂ« gjithĂ« serverĂ«t mbeten tĂ« aksesueshĂ«m.
- Në pjesën Members kliko + për të shtuar serverë në grup.
Këtu duhet të tregoni:- emrin e serverit;
- IP-adresën e serverit;
- portin, në të cilin serveri do të marrë trafik;
- portin për kontrollin shëndetësor (Monitor healthcheck);
- peshĂ«n (Weight) â me kĂ«tĂ« parameter mund tĂ« rregulloni sasinĂ« proporcionale tĂ« trafikut tĂ« marrĂ« pĂ«r çdo anĂ«tar tĂ« grupit;
- Max Connections â numri maksimal i lidhjeve nĂ« server;
- Min Connections â numri minimal i lidhjeve qĂ« duhet tĂ« pĂ«rpunojĂ« serveri, para se trafiku tĂ« redirektohet te anĂ«tari tjetĂ«r i grupit.
Kështu duket grupi përfundimtar i tre serverëve.
Shtojmë Virtual Server
- Kalo në kartelën Virtual Servers. Kliko +.
- Aktivizoni serverin virtual me Enable Virtual Server.
I përcaktojmë emrin, zgjedhim Application Profile, Pool të krijuar më parë dhe çojmë IP-në e adresës ku Serveri Virtual do të pranojë kërkesat nga jashtë. Të cilat janë protokolli HTTPS dhe porta 443.
Parametrat opsionalë këtu:
Limiti i lidhjes â numri maksimal i lidhjeve tĂ« pĂ«rkohshme qĂ« mund tĂ« pĂ«rpunojĂ« serveri virtual;
Limiti i ritmit tĂ« lidhjes (CPS) â numri maksimal i kĂ«rkesave tĂ« reja qĂ« i pranohen nĂ« sekondĂ«.
Me këtë, konfigurimi i balancuesit përfundon, mund të kontrollojmë funksionalitetin e tij. Serverat kanë një konfigurim të thjeshtë, e cila lejon të kuptojmë se cili server nga pool-i ka procesuar kërkesën. Gjatë konfigurimit, ne zgjodhëm algoritmin e balancimit Round Robin, dhe parametri Weight për çdo server është një, kështu që çdo kërkesë e ardhshme do të përpunojë serverin pasues nga pool-i.
Shkruajmë në shfletues adresën e jashtme të balancuesit dhe shohim:
Pasi të përditësohet faqja, kërkesa do të përpunojë serverin pasues:
Dhe njĂ« herĂ« tjetĂ«r â pĂ«r tĂ« kontrolluar dhe serverin e tretĂ« nga pool-i:
Gjatë kontrollit, mund të shohim se certifikata, e cila na dërgon Edge, është ajo e cila u gjenerua në fillim.
Kontrollimi i statusit të balancuesit nga konsola e Gateway-it Edge. Për këtë, shkruani show service loadbalancer pool.
Konfigurojmë Monitorin e Shërbimeve për të kontrolluar gjendjen e serverëve në pool
Me ndihmën e Monitorit të Shërbimeve, ne mund të mbikëqyrim gjendjen e serverëve në pool-in e bllokuar. Nëse përgjigjja në kërkesë nuk përputhet me atë të pritur, serveri mund të përjashtohet nga pool-i, në mënyrë që të mos pranojë kërkesa të reja.
Në parazgjedhje janë konfiguruar tre metoda kontrolli:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Krijojmë një të re.
- Kalojmë në tab-in e Monitorimit të Shërbimeve, shtypim +.
- Zgjedhim:
- emrin për metodën e re;
- intervalin me të cilin do të dërgohen kërkesat,
- kohën e pritjes për përgjigjen,
- tipin e monitorimit â kĂ«rkesĂ« HTTPS duke pĂ«rdorur metodĂ«n GET, kodin e pritur tĂ« statusit â 200(OK) dhe URL-nĂ« e kĂ«rkesĂ«s.
- Me këtë, konfigurimi i Monitorit të Shërbimeve të ri përfundon, tani mund ta përdorim atë gjatë krijimit të pool-it.
Konfigurojmë Rregullat e Aplikacioneve
Rregullat e Aplikacioneve â njĂ« mĂ«nyrĂ« pĂ«r tĂ« manipuluar trafikun, e bazuar nĂ« disa triggerr. Me kĂ«tĂ« mjet mund tĂ« krijojmĂ« rregulla tĂ« avancuara pĂ«r balancimin e ngarkesave, konfigurimi i tĂ« cilave mund tĂ« jetĂ« i pamundur pĂ«rmes profileve tĂ« Aplikacioneve ose shĂ«rbimeve tĂ« tjera tĂ« disponueshme nĂ« Gateway-in Edge.
- Për të krijuar një rregull, kalojmë në skedën Rregullat e Aplikacionit të balancuesit.
- Zgjidhni emrin, skriptin që do të përdorë rregulli, dhe kliko në Ruaj.
- Pasi të krijohet rregulli, na nevojitet të redaktojmë Serverin Virtual të konfigurueshëm.
- Në skedën Avancuar, shtojmë rregullin që krijuam.
Në shembullin e mësipërm, aktivizuam mbështetje për tlsv1.
Disa shembuj të tjerë:
Rredirectimi i trafikut në një grup tjetër.
Me këtë skript mund të drejtojmë trafikun në një grup tjetër balancimi nëse grupi kryesor nuk funksionon. Për të vepruar rregulli, balancuesi duhet të ketë disa grupe të konfiguruara dhe të gjitha anëtarët e grupit kryesor duhet të jenë në gjendje down. Duhet të specifikohet emri i grupit, jo ID-ja e tij.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Rredirectimi i trafikut në një burim të jashtëm.
Këtu ne drejtojmë trafikun në një uebfaqe të jashtme, nëse të gjithë pjesëmarrësit e grupit kryesor janë në gjendje down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Edhe më shumë shembuj .
Këtu për balancuesin kam përfunduar. Nëse keni pyetje, pyetni, jam gati të përgjigjem.
Burimi: habr.com
