VMware NSX kõige väiksematele. Osa 5. Laadimisseadmise seadistamine

Esimene osa. Sissejuhatus
Teine osa. Firewali ja NAT-i reeglite seadistamine
Kolmas osa. DHCP seadistamine
Neljas osa. Maršrutimise seadistamine

Eelmises osas rääkisime NSX Edge'i võimetest staatilise ja dünaamilise maršrutimise kontekstis ning täna uurime koormuse tasakaalustajat.
Enne seadistamise alustamist tahaksin lühidalt meenutada peamisi koormuse tasakaalustamise tüüpe.

Teooria

Praegused koormuse tasakaalustamise lahendused jagunevad tavaliselt kaheks kategooriaks: koormuse tasakaalustamine neljandal (transport) ja seitsmendal (rakendus) tasemel mudelis. OSIOSI mudel ei ole parim juhtpunkt tasakaalustamismeetodite kirjeldamiseks. Näiteks, kui L4 koormuse tasakaalustaja toetab ka TLS-i lõpetamist, kas siis muutub see L7 tasakaalustajaks? Aga mis on, see on.

• L4 koormuse tasakaalustaja on kõige sagedamini vaheline proxy, mis asub kliendi ja kavaliteetide tagumise kogumi vahel ning lõpetab TCP-ühendused (st vastab SYN-ile), valib tagumise serveri ja algatab temaga uue TCP-seansi, saates iseseisvalt SYN-i. See tüüp on üks alusteist, kuid võimalused pole piiratud.
• L7 koormuse tasakaalustaja jagab liiklust kavaliteetide vahel „peenemalt“ kui L4 koormuse tasakaalustaja. See võib tagumise serveri valimise otsuse langetada nt HTTP sõnumi sisu (URL, küpsised jne) põhjal.

Ükskõik millise tüübi puhul võib koormuse tasakaalustaja toetada järgmisi funktsioone:

• Teenuste avastamine – protsess, millega määratakse kindlaks kavaliteetide kogum (Static, DNS, Consul, Etcd jms).
• Leitud tagumise serveri töökindluse kontrollimine (aktiivne „pingimine“ HTTP-päringu kaudu, passiivne probleemide avastamine TCP-ühendustes, järjestikuste 503 HTTP-koodide olemasolu vastustes jne).
• Ise koormuse tasakaalustamine (round robin, juhuslik valik, allika IP-hash, URI).
• TLS-i lõpetamine ja sertifikaatide kontrollimine.
• Turvafunktsioonidega seotud võimalused (autentimine, DoS-rünnakute vältimine, kiiruspiirangud) ja palju muud.

NSX Edge pakub koormuse tasakaalustaja kahe juurutamismoodi tuge:

Proxy-režiim ehk one-arm. Sellise režiimi puhul kasutab NSX Edge taotluse saatmisel ühe bändi IP-aadressi allika aadressina. Nii täidab koormuse tasakaalustaja samaaegselt nii Allika kui Kahtluse NAT funktsioone. Bänd näeb kogu liiklust kui saadetud koormuse tasakaalustajast ja vastab sellele otse. Sellisel skeemil peab koormuse tasakaalustaja olema samas võrgusegmentis sisemiste serveritega.

Nii see töötab:
1.       Kasutaja esitab taotluse VIP-aadressile (koormuse tasakaalustaja aadress), mis on seadistatud Edge'ile.
2.       Edge valib ühe bändidest ja teostab sihtkoha NAT, asendades VIP-aadressi valitud bändi aadressiga.
3.       Edge teostab allika NAT, asendades taotluse saatnud kasutaja aadressi oma isiklikuga.
4.       Pakett saadetakse valitud bändile.
5.       Bänd vastab mitte otse kasutajale, vaid Edge'ile, sest kasutaja algne aadress muudeti koormuse tasakaalustaja aadressiks.
6.       Edge edastab serveri vastuse kasutajale.
Allolev skeem.


Läbipaistev, või inline, režiim. Selles stsenaariumis on koormuse tasakaalustajal liidesed sise- ja välistesse võrkudesse. Sisevõrgule ei ole otsest juurdepääsu välisest. Sisseehitatud koormuse tasakaalustaja toimib NAT gateway'na virtuaalmasinate jaoks sisevõrgus.

Mehhanism on järgmine:
1.       Kasutaja esitab taotluse VIP-aadressile (koormuse tasakaalustaja aadress), mis on seadistatud Edge'ile.
2.       Edge valib ühe bändidest ja teostab sihtkoha NAT, asendades VIP-aadressi valitud bändi aadressiga.
3.       Pakett saadetakse valitud bändile.
4.       Bänd saab taotluse originaali aadressiga (allika NAT'i ei teostatud) ja vastab sellele otse.
5.       Liiklus võetakse uuesti vastu koormuse tasakaalustaja poolt, kuna inline skeemis toimib see tavaliselt vaikimisi väravana serverite farmi jaoks.
6.       Edge teostab allika NAT'i, et saata liiklus kasutajale, kasutades oma VIP-d allika IP-aadressina.
Allolev skeem.

Praktika

Minu testkeskkonnas on seadistatud 3 serverit Apache'iga, mis on seadistatud HTTPS-i töötamiseks. Edge teostab HTTPS-i taotluste tasakaalustamist round robin meetodiga, edastades iga uue taotluse uuele serverile.
Hakkame pihta.

Küpsetame SSL-sertifikaadi, mida NSX Edge kasutab
Saate importida kehtiva CA-sertifikaadi või kasutada isekirjutatud. Selles testis kasutan iseallkirjastatud sertifikaati.

1. vCloud Director'i liidese kaudu liikuda Edge'i teenuste seadete juurde.
   
2. Liigume Sertifikaadid vahelehele. Toimingute nimekirjast valige uue CSR-i lisamine.
   
3. Täida vajalikud väljad ja vajuta Keep.
   
4. Vali just loodud CSR ja vali valik self-sign CSR.
   
5. Vali sertifikaadi kehtivusaeg ja vajuta Keep.
   
6. Isesigneeritud sertifikaat on ilmunud saadavalolevate hulka.
   

Seadista Rakenduse Profiil.
Rakenduse profiilid annavad suurema kontrolli võrgu liikluse üle ja muudavad selle haldamise lihtsaks ja tõhusaks. Nende abil on võimalik määrata käitumine konkreetse liikluse tüübi jaoks.

1. Minna Load Balancer vahelehele ja aktiveerida tasakaalustaja. Valik Acceleration enabled võimaldab tasakaalustajal kasutada kiiremat L4 tasakaalustust L7 asemel.
   
2. Mine Rakenduse profiili vahelehele, et määrata rakenduse profiil. Vajuta +.
   
3. Määrake profiili nimi ja valige liikluse tüüp, millele profiil rakendub. Selgitan mõningaid parameetreid.
   Persistence – salvestab ja jälgib kasutusseansi andmeid, näiteks: milline konkreetne server basseinist teenindab kasutaja päringut. See tagab, et kasutaja päringud suunatakse kogu seansi või järgnevate seansside vältel samasse basseiniliikmesse.
   Enable SSL passthrough – kui see valik on valitud, NSX Edge lõpetab SSL-i. Selle asemel toimub lõpetamine otse serverites, millele tasakaalustamine toimub.
   Insert X-Forwarded-For HTTP header – võimaldab määrata kliendi algse IP-aadressi, kes ühendub veebiserveriga tasakaalustaja kaudu.
   Enable Pool Side SSL – võimaldab märkida, et valitud bassein koosneb HTTPS-serveritest.
   
4. Kuna ma tasakaalustan HTTPS-liiklust, pean lubama Pool Side SSL-i ja valima varem genereeritud sertifikaadi Virtual Server Certificates vahelehelt → Service Certificate.
   
5. Sarnaselt Pool Certificates → Service Certificate.
   

Loome serverite basseini, mille juurde liiklus tasakaalustatakse Pools.

1. Mine Pools vahelehele. Vajuta +.
   
2. Määrake basseini nimi, valige algoritm (kasutan round robin) ja tervisekontrolli tüübi jaoks. Valik Transparent näitab, kas kliendi algsed IP-d on sise-serverite jaoks nähtavad.
   • Kui valik on välja lülitatud, tuleb sise-serveritele liiklus tasakaalustaja algse IP-ga.
   • Kui valik on sisse lülitatud, näevad sise-serverid klientide algset IP-aadressi. Sellises konfiguratsioonis peab NSX Edge olema vaikimisi lühiühendus, et tagada, et tagastatud paketid lähevad läbi NSX Edge.

   NSX toetab järgmisi koormuse tasakaalustamise algoritme:

   • IP_HASH – serveri valik põhineb hash-funktsiooni tulemustel, mis arvutatakse iga paketi source ja destination IP jaoks.
   • LEASTCONN – sissetulevate ühenduste tasakaalustamine, sõltuvalt juba olemasolevate ühenduste arvust konkreetses serveris. Uued ühendused suunatakse serverisse, kus on kõige vähem ühendusi.
   • ROUND_ROBIN – uued ühendused saadetakse iga serveri juurde järjestikku vastavalt määratud kaalule.
   • URI – URI vasak pool (kuni küsimärkide) hashitakse ja jagatakse serverite kogukaalu järgi. Tulemuseks on see, milline server saab päringu, tagades, et päring saadetakse alati samasse serverisse, kuni kõik serverid jäävad kättesaadavaks.
   • HTTPHEADER – tasakaalustamine põhineb kindlal HTTP päisel, mida saab määrata parameetrina. Kui päis puudub või ei oma mingit väärtust, rakendatakse algoritmi ROUND_ROBIN.
   • URL – igas HTTP GET päringus otsitakse URL-i parameetrit, mis on määratud argumendiks. Kui parameetri järel on võrdsuse märk ja väärtus, siis väärtus hashitakse ja jagatakse käimasolevate serverite kogukaalu järgi. Tulemuseks on see, milline server saab päringu. Selle protsessi eesmärk on jälgida kasutaja id-d päringutes ja tagada, et sama kasutaja id saadetakse alati samasse serverisse, kuni kõik serverid jäävad kättesaadavaks.

   

3. Members plokis vajuta +, et lisada serverid gruppi.
   
   
   Siia tuleb märkida:
   • serveri nimi;
   • serveri IP-aadress;
   • port, millele server saab liiklust;
   • port tervise kontrollimiseks (Monitor healthcheck);
   • kaal (Weight) – selle parameetriga saab reguleerida koormuse jaotust konkreetse grupi liikme vahel;
   • Max Connections – maksimaalne ühenduste arv serverisse;
   • Min Connections – minimaalne ühenduste arv, mida server peab töötlema, enne kui liiklus suunatakse järgmisele grupi liikmed.

   
   
   Nii näeb välja lõplik grupp kolmest serverist.
   

Lisame Virtuaalse Serveri

1. Liigume virtuaalsete serverite vahekaardile. Vaja on vajutada +.
   
2. Aktiveerime virtuaalse serveri nuppu Enable Virtual Server.
   Anname sellele nime, valime varasemalt loodud rakenduse profiili, bassein ja määrame IP-aadressi, kuhu Virtuaalne Server väljastpoolt päringud vastu võtab. Määra protokoll HTTPS ja port 443.
   Valikulised parameetrid siin:
   Ühenduse limiit – maksimaalne samal ajal avatud ühenduste arv, mida virtuaalne server saab töödelda;
   Ühenduse määramise limiit (CPS) – maksimaalne uute sissetulevate päringute arv sekundis.
   

Sellega on koormustasakaalu konfiguratsioon lõpetatud, nüüd saab selle töökindlust kontrollida. Serveritel on kõige lihtsam konfiguratsioon, mis võimaldab mõista, milline server basseinist päringu töötleb. Seadistamise ajal valisime koormuse jaotusmeetodiks Round Robin ning iga serveri kaal on üks, seega töödeldakse iga järgmine päring järgmise serveri poolt basseinist.
Sisestame brauserisse koormustasakaalu välise aadressi ja näeme:


Pärast lehe värskendamist töödeldakse päring järgmisel serveril:


Ja veel kord – et kontrollida ka kolmandat serverit basseinist:


Kontrollimisel on näha, et sertifikaat, mille Edge meile saadab, on just see, mille me alguses genereerisime.

Kontrollime koormustasakaalu staatust Edge gateway konsoolist. Selle jaoks sisestage show service loadbalancer pool.


Seadistame teenuse seire koondamiseks serverite olekute kontrollimiseks basseinist
Teenuse seire abil saame jälgida serverite olekuid tagapool seotud basseinides. Kui päringu vastus ei vasta oodatavale, saab serveri basseinist välja jätta, et see ei saaks uusi päringuid.
Vaikesätetena on seadistatud kolm kontrollimise meetodit:

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

Loome uue.

1. Liigume teenuse seiramise vahekaardile, vajutame +.
   
2. Valime:
   • uue meetodi nime;
   • intervall, mille jooksul päringud saadetakse,
   • vastuse ootamise aja limit,
   • seire tüüp – HTTPS päring kasutades meetodit GET, oodatav staatuse kood – 200 (OK) ja päringu URL.
3. Sellega on uue teenuse seire seadistus lõpetatud, nüüd saame seda basseinide loomisel kasutada.
   

Seadistame rakenduse reegleid

Rakenduse reeglid – liikluse manipuleerimise viis, mis põhineb teatud käivitajatel. Selle tööriista abil saame luua laiendatud koormuse jaotusreegleid, mille seadistamine võib olla võimatu läbi rakenduse profiilide või teiste teenuste, mis on saadaval Edge Gateway's.

1. Läbi rakenduse reeglite vahekaardi loome reegli tasakaalustaja jaoks.
   
2. Valime nime, skripti, mis kasutab reeglit, ja vajutame Hoia.
   
3. Pärast reegli loomist tuleb meil redigeerida juba seatud Virtuaalserverit.
   
4. Vahekaardil Täiendavad lisame meie loodud reegli.
   

Eeltoodud näites aktiveerisime tlsv1 toe.

Veel mõned näited:

Liiklus suunamine teise gruppi.
Selle skripti abil saame suunata liikluse teise tasakaalustamisrühma, kui põhigrupp ei tööta. Reegli toimimiseks peab tasakaalustaja olema konfigureerinud mitu gruppi ja kõik põhigruppi kuuluvad liikmed peavad olema seisundis down. Tuleb märkida rühma nimi, mitte selle ID.

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


Liiklus suunamine välishankijale.
Siin suuname liikluse välishaavale veebisaidile, kui kõik põhigruppi kuuluvad liikmed on seisundis down.

acl pool_down nbsrv(NIME_TIIGI) eq 0
suuna asukoht http://www.example.com, kui pool_down

Veel rohkem näiteid siit.

Sellel meie tasakaalustaja teema lõpetan. Kui on küsimusi, küsige, olen valmis vastama.

Allikas: habr.com