VMware NSX për të vegjlit. Pjesa 5: Konfigurimi i një balancuesi të ngarkesës

Pjesa e pare. hyrëse
Pjesa e dyte. Konfigurimi i rregullave të Firewall dhe NAT
Pjesa e tretë. Konfigurimi i DHCP
Pjesa e katërt. Konfigurimi i rrugëzimit

Herën e fundit folëm për aftësitë e NSX Edge në drejtim të rrugëzimit statik dhe dinamik, ndërsa sot do të merremi me balancuesin e ngarkesës.
Para se të fillojmë vendosjen, do të doja t'ju kujtoja shkurtimisht llojet kryesore të balancimit.

teori

Të gjitha zgjidhjet e sotme të balancimit të ngarkesës ndahen më shpesh në dy kategori: balancimi në nivelet e katërt (transportit) dhe të shtatë (aplikimit) të modelit. OSE NESE. Modeli OSI nuk është pika më e mirë e referencës kur përshkruan metodat e balancimit. Për shembull, nëse një balancues L4 mbështet gjithashtu përfundimin TLS, a bëhet ai një balancues L7? Por është ajo që është.

• Balancues L4 më shpesh është një përfaqësues i mesëm që qëndron midis klientit dhe një grupi mbështetësesh të disponueshme, i cili përfundon lidhjet TCP (d.m.th., i përgjigjet në mënyrë të pavarur SYN), zgjedh një backend dhe fillon një sesion të ri TCP në drejtimin e tij, duke dërguar në mënyrë të pavarur SYN. Ky lloj është një nga ato bazë; opsione të tjera janë të mundshme.
• Balancues L7 shpërndan trafikun nëpër bazat e disponueshme "më të sofistikuara" sesa balancuesi L4. Ai mund të vendosë se cilin backend të zgjedhë 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ërbimit është procesi i përcaktimit të grupit të backend-eve të disponueshme (Static, DNS, Consul, Etcd, etj.).
• Kontrollimi i funksionalitetit të backend-eve të zbuluara ("ping" aktiv i backend-it duke përdorur një kërkesë HTTP, zbulimi pasiv i problemeve në lidhjet TCP, prania e disa kodeve 503 HTTP në përgjigje, etj.).
• Vetë balancimi (Round Robin, përzgjedhje e rastësishme, hash IP burim, URI).
• Përfundimi i TLS dhe verifikimi i certifikatës.
• Opsionet e lidhura me sigurinë (autentifikimi, parandalimi i sulmit DoS, kufizimi i shpejtësisë) dhe shumë më tepër.

NSX Edge ofron mbështetje për dy mënyra të vendosjes së balancuesit të ngarkesës:

Modaliteti i përfaqësuesit, ose me një krah. Në këtë modalitet, NSX Edge përdor adresën e tij IP si adresën e burimit kur dërgon një kërkesë në një nga backend-et. Kështu, balancuesi kryen njëkohësisht funksionet e Burimit dhe Destinacionit NAT. Backend e sheh të gjithë trafikun si të dërguar nga balancuesi dhe i përgjigjet drejtpërdrejt atij. Në një skemë të tillë, balancuesi duhet të jetë në të njëjtin segment të rrjetit me serverët e brendshëm.

Ja si shkon:
1. Përdoruesi dërgon një kërkesë në adresën VIP (adresa e balancuesit) që është konfiguruar në Edge.
2. Edge zgjedh një nga backend-et dhe kryen destinacionin NAT, duke zëvendësuar adresën VIP me adresën e backend-it të zgjedhur.
3. Edge kryen NAT burimore, duke zëvendësuar adresën e përdoruesit që dërgoi kërkesën me adresën e saj.
4. Paketa dërgohet në backend-in e zgjedhur.
5. Backend-i nuk i përgjigjet drejtpërdrejt përdoruesit, por Edge, pasi adresa origjinale e përdoruesit është ndryshuar në adresën e balancuesit.
6. Edge transmeton përgjigjen e serverit tek përdoruesi.
Diagrami është më poshtë.


Modaliteti transparent ose inline. Në këtë skenar, balancuesi ka ndërfaqe në rrjetet e brendshme dhe të jashtme. Në të njëjtën kohë, nuk ka qasje të drejtpërdrejtë në rrjetin e brendshëm nga ai i jashtëm. Balancuesi i integruar i ngarkesës vepron si një portë NAT për makinat virtuale në rrjetin e brendshëm.

Mekanizmi është si më poshtë:
1. Përdoruesi dërgon një kërkesë në adresën VIP (adresa e balancuesit) që është konfiguruar në Edge.
2. Edge zgjedh një nga backend-et dhe kryen destinacionin NAT, duke zëvendësuar adresën VIP me adresën e backend-it të zgjedhur.
3. Paketa dërgohet në backend-in e zgjedhur.
4. Backend merr një kërkesë me adresën origjinale të përdoruesit (burimi NAT nuk u krye) dhe i përgjigjet drejtpërdrejt asaj.
5. Trafiku pranohet përsëri nga balancuesi i ngarkesës, pasi në një skemë inline ai zakonisht vepron si porta e paracaktuar për fermën e serverëve.
6. Edge kryen NAT burimi për të dërguar trafikun te përdoruesi, duke përdorur VIP-në e tij si adresën IP të burimit.
Diagrami është më poshtë.

Praktikë

Paneli im i provës ka 3 serverë që funksionojnë Apache, i cili është konfiguruar të funksionojë mbi HTTPS. Edge do të kryejë balancimin e rrumbullakët të kërkesave HTTPS, duke përfaqësuar çdo kërkesë të re në një server të ri.
Le të fillojmë.

Gjenerimi i një certifikate SSL që do të përdoret nga NSX Edge
Mund të importoni një certifikatë të vlefshme CA ose të përdorni një të vetë-nënshkruar. Për këtë test unë do të përdor vetë-nënshkruar.

1. Në ndërfaqen vCloud Director, shkoni te cilësimet e shërbimeve Edge.
   
2. Shkoni te skeda Certifikata. Nga lista e veprimeve, zgjidhni shtimin e një CSR të re.
   
3. Plotësoni fushat e kërkuara dhe klikoni Mbaj.
   
4. Zgjidhni CSR-në e krijuar rishtazi dhe zgjidhni opsionin e vetë-nënshkrimit CSR.
   
5. Zgjidhni periudhën e vlefshmërisë së certifikatës dhe klikoni Mbaj
   
6. Certifikata e vetë-nënshkruar shfaqet në listën e atyre të disponueshme.
   

Vendosja e profilit të aplikacionit
Profilet e aplikacioneve ju japin kontroll më të plotë mbi trafikun e rrjetit dhe e bëjnë menaxhimin e tij të thjeshtë dhe efektiv. Ato mund të përdoren për të përcaktuar sjelljen për lloje specifike të trafikut.

1. Shkoni te skeda Load Balancer dhe aktivizoni balancuesin. Opsioni i aktivizuar përshpejtimin këtu lejon balancuesin të përdorë balancimin më të shpejtë L4 në vend të L7.
   
2. Shkoni te skeda Profili i aplikacionit për të vendosur profilin e aplikacionit. Klikoni +.
   
3. Vendosni emrin e profilit dhe zgjidhni llojin e trafikut për të cilin do të aplikohet profili. Më lejoni të shpjegoj disa parametra.
   Këmbëngulje – ruan dhe gjurmon të dhënat e sesionit, për shembull: cili server specifik në grup po i shërben kërkesës së përdoruesit. Kjo siguron që kërkesat e përdoruesve t'i drejtohen të njëjtit anëtar të grupit gjatë gjithë jetës së sesionit ose sesioneve pasuese.
   Aktivizo kalimin SSL – Kur zgjidhet ky opsion, NSX Edge ndalon përfundimin e SSL. Në vend të kësaj, përfundimi ndodh drejtpërdrejt në serverët që janë duke u balancuar.
   Fut kokën X-Forwarded-For HTTP – ju lejon të përcaktoni adresën IP të burimit të klientit që lidhet me serverin në internet përmes balancuesit të ngarkesës.
   Aktivizo Pool Side SSL – ju lejon të specifikoni që grupi i zgjedhur përbëhet nga serverë HTTPS.
   
4. Meqenëse do të balancoj trafikun HTTPS, më duhet të aktivizoj SSL-në anësore të grupit dhe të zgjedh certifikatën e krijuar më parë në skedën Certifikatat e Serverit Virtual -> Certifikata e Shërbimit.
   
5. Në mënyrë të ngjashme për Certifikatat Pool -> Certifikata e Shërbimit.
   

Ne krijojmë një grup serverësh, trafiku në të cilin do të jetë i balancuar Pools

1. Shkoni te skeda Pools. Klikoni +.
   
2. Vendosim emrin e grupit, zgjedhim algoritmin (do të përdor round robin) dhe llojin e monitorimit për backend-in e kontrollit shëndetësor.Opsioni Transparent tregon nëse IP-të e burimit fillestar 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 nga IP-ja e burimit të balancuesit.
   • Nëse opsioni është i aktivizuar, serverët e brendshëm shohin IP-në e burimit të klientëve. Në këtë konfigurim, NSX Edge duhet të veprojë si porta e paracaktuar për të siguruar që paketat e kthyera të kalojnë përmes NSX Edge.

   NSX mbështet algoritmet e mëposhtme të balancimit:

   • IP_HASH – Zgjedhja e serverit bazuar në rezultatet e një funksioni hash për IP-në e burimit dhe të destinacionit të secilës paketë.
   • LEASTCONN – balancimi i lidhjeve hyrëse, në varësi të numrit të disponueshëm tashmë në një server të caktuar. Lidhjet e reja do të drejtohen te serveri me më pak lidhje.
   • ROUND_ROBIN – lidhjet e reja i dërgohen çdo serveri me radhë, në përputhje me peshën që i është caktuar.
   • URI – pjesa e majtë e URI-së (para pikëpyetjes) hash dhe ndahet me peshën totale të serverëve në grup. Rezultati tregon se cili server e merr kërkesën, duke siguruar që kërkesa të drejtohet gjithmonë në të njëjtin server, për sa kohë që të gjithë serverët mbeten të disponueshëm.
   • HTTPHEADER – balancimi i bazuar në një titull specifik HTTP, i cili mund të specifikohet si një parametër. Nëse titulli mungon ose nuk ka ndonjë vlerë, zbatohet algoritmi ROUND_ROBIN.
   • URL – Çdo kërkesë HTTP GET kërkon për parametrin URL të specifikuar si argument. Nëse parametri ndiqet nga një shenjë e barabartë dhe një vlerë, atëherë vlera hash dhe pjesëtohet me peshën totale të serverëve që funksionojnë. Rezultati tregon se cili server e merr kërkesën. Ky proces përdoret për të mbajtur gjurmët e ID-ve të përdoruesve në kërkesa dhe për të siguruar që i njëjti id i përdoruesit të dërgohet gjithmonë në të njëjtin server, për sa kohë që të gjithë serverët mbeten të disponueshëm.

   

3. Në bllokun e Anëtarëve, klikoni + për të shtuar serverë në grup.
   
   
   Këtu duhet të specifikoni:
   • Emri i serverit;
   • Adresa IP e serverit;
   • porti në të cilin serveri do të marrë trafik;
   • porti për kontroll shëndetësor (Monitor shëndetësor);
   • pesha – duke përdorur këtë parametër mund të rregulloni sasinë proporcionale të trafikut të marrë për një anëtar specifik të grupit;
   • Max Connections – numri maksimal i lidhjeve me serverin;
   • Minim Lidhjet – numri minimal i lidhjeve që serveri duhet të përpunojë përpara se trafiku të përcillet te anëtari tjetër i grupit.

   
   
   Kështu duket grupi përfundimtar i tre serverëve.
   

Shtimi i serverit virtual

1. Shkoni te skeda Serverët Virtualë. Klikoni +.
   
2. Ne aktivizojmë serverin virtual duke përdorur Enable Virtual Server.
   Ne i japim një emër, zgjedhim profilin e aplikacionit të krijuar më parë, Pool dhe tregojmë adresën IP në të cilën Serveri Virtual do të marrë kërkesa nga jashtë. Ne specifikojmë protokollin HTTPS dhe portin 443.
   Parametrat opsionale këtu:
   Kufiri i lidhjes – numri maksimal i lidhjeve të njëkohshme që serveri virtual mund të përpunojë;
   Kufiri i shpejtësisë së lidhjes (CPS) – numri maksimal i kërkesave të reja hyrëse për sekondë.
   

Kjo përfundon konfigurimin e balancuesit; mund të kontrolloni funksionalitetin e tij. Serverët kanë një konfigurim të thjeshtë që ju lejon të kuptoni se cili server nga grupi përpunoi kërkesën. Gjatë konfigurimit, ne zgjodhëm algoritmin e balancimit Round Robin dhe parametri Pesha për çdo server është i barabartë me një, kështu që çdo kërkesë pasuese do të përpunohet nga serveri tjetër nga grupi.
Ne futim adresën e jashtme të balancuesit në shfletues dhe shohim:


Pas rifreskimit të faqes, kërkesa do të përpunohet nga serveri i mëposhtëm:


Dhe përsëri - për të kontrolluar serverin e tretë nga pishina:


Kur kontrolloni, mund të shihni se certifikata që na dërgon Edge është e njëjta që krijuam që në fillim.

Po kontrollon statusin e balancuesit nga tastiera e portës Edge. Për ta bërë këtë, futni tregoni pishinën e balancuesit të shërbimit.


Konfigurimi i Monitorit të Shërbimit për të kontrolluar statusin e serverëve në pishinë
Duke përdorur Service Monitor ne mund të monitorojmë statusin e serverëve në grupin e backend. Nëse përgjigja ndaj një kërkese nuk është siç pritej, serveri mund të hiqet nga grupi në mënyrë që të mos marrë asnjë kërkesë të re.
Si parazgjedhje, janë konfiguruar tre metoda verifikimi:

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

Le të krijojmë një të re.

1. Shkoni te skeda e Monitorimit të Shërbimit, klikoni +.
   
2. Zgjidhni:
   • emri për metodën e re;
   • intervali në të cilin do të dërgohen kërkesat,
   • koha e pritjes për një përgjigje,
   • lloji i monitorimit – Kërkesa HTTPS duke përdorur metodën GET, kodi i statusit të pritur – 200(OK) dhe URL-ja e kërkesës.
3. Kjo përfundon konfigurimin e Monitorit të ri të Shërbimit; tani ne mund ta përdorim atë kur krijojmë një grup.
   

Vendosja e Rregullave të Aplikimit

Rregullat e aplikimit janë një mënyrë për të manipuluar trafikun bazuar në disa shkaktarë. Me këtë mjet ne mund të krijojmë rregulla të avancuara të balancimit të ngarkesës që mund të mos jenë të mundshme përmes profileve të aplikacionit ose shërbimeve të tjera të disponueshme në Edge Gateway.

1. Për të krijuar një rregull, shkoni te skeda Rregullat e Aplikimit të balancuesit.
   
2. Zgjidhni një emër, një skript që do të përdorë rregullin dhe klikoni Mbaj.
   
3. Pasi të krijohet rregulli, duhet të modifikojmë Serverin Virtual tashmë të konfiguruar.
   
4. Në skedën Advanced, shtoni rregullin që krijuam.
   

Në shembullin e mësipërm kemi aktivizuar mbështetjen tlsv1.

Disa shembuj të tjerë:

Ridrejto trafikun në një pishinë tjetër.
Me këtë skript, ne mund ta ridrejtojmë trafikun në një grup tjetër balancues nëse grupi kryesor është i dëmtuar. Që rregulli të funksionojë, duhet të konfigurohen shumë grupe në balancuesin dhe të gjithë anëtarët e grupit kryesor duhet të jenë në gjendje të ulët. Duhet të specifikoni 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


Ridrejtoni trafikun në një burim të jashtëm.
Këtu ne ridrejtojmë trafikun në uebsajtin e jashtëm nëse të gjithë anëtarët e grupit kryesor janë jashtë funksionit.

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

Edhe më shumë shembuj këtu.

Kjo është e gjitha për mua në lidhje me balancuesin. Nëse keni ndonjë pyetje, pyesni, unë jam gati të përgjigjem.

Burimi: www.habr.com