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

Esimene osa. Sissejuhatus
Teine osa. Firewalli ja NAT-i reeglite seadistamine
Kolmas osa. DHCP seadistamine
Neljas osa. Suunamise seadistamine

Eelmisel korral rääkisime NSX Edge'i võimalustest staatilise ja dünaamilise marsruutimise osas, täna aga uurime koormuse tasakaalustajat.
Enne seadistamise alustamist sooviksin lühidalt meenutada peamisi tasakaalustamise tüüpe.

Teooria

Kõik tänapäeva koormuse tasakaalustamise lahendused jagunevad enamasti kaheks kategooriaks: tasakaalustamine neljandas (transport) ja seitsmendas (rakenduse) tasemes. OSI. OSI mudel ei ole parim viidatud punkt tasakaalustamismeetodite kirjeldamiseks. Näiteks, kui L4 tasakaalustaja toetab ka TLS-i lõpetamist, kas ta muutub sel juhul L7 tasakaalustajaks? Aga mis seal siis ikka.

• L4 tasakaalustaja tavaliselt esindab vahekohtuniku süsteemi, mis asub kliendi ja saadaolevate tagapoolsete vahel, lõpetades TCP-ühendused (st vastates iseseisvalt SYN-le), valib tagapoolse ja algatab tema suunas uue TCP-seansi, saates iseseisvalt SYN. See tüüp on üks põhilisi, olemas on ka teisi variante.
• L7 tasakaalustaja suunab liiklust saadaval olevate tagaplaanide vahel „keerukamalt” kui L4- tasandi koormuse jaotur. See suudab tagaplaani valikute tegemisel arvestada näiteks HTTP-sõnumi sisu (URL, küpsis jne).

Olenemata tüübist, koormuse jaotur võib toetada järgmisi funktsioone:

• Teenuste avastamine – protsess saadaval olevate tagaplaanide (Static, DNS, Consul, Etcd jne) määramiseks.
• Avastatud tagaplaanide töökontroll (aktiivne „ping” HTTP-päringu abil, probleemide passiivne avastamine TCP-ühendustes, mitu järjestikust 503 HTTP-koodi vastustes jne).
• Koormuse jaotamine (ringikujuline, juhuslik valik, allika IP-hashing, URI).
• TLS-i lõpetamine ja sertifikaatide valideerimine.
• Turvalisuse tagamisega seotud valikud (autentimine, DoS-rünnakute ennetamine, kiiruspiirang) ja palju muud.

NSX Edge pakub toetust kaheks koormuse jaoturi juurutamise režiimiks:

Proxirežiim, ehk one-arm. Selles režiimis kasutab NSX Edge päringu saatmisel ühele tagasuunamisdestinaatorist IP-aadressi allika aadressina. Seega täidab tasakaalustaja samaaegselt nii Source kui ka Destination NAT funktsioone. Tagasuunamisdestinaator näeb kogu liiklust kui tasakaalustajalt saadetud ja vastab sellele otse. Sellises skeemis peab tasakaalustaja olema samas võrgu segmendis sisemiste serveritega.

Nii see toimub:
1.       Kasutaja saadab päringu VIP-aadressile (tasakaalustaja aadress), mis on konfigureeritud Edge'il.
2.       Edge valib ühe tagasuunamisdestinaatoritest ja teostab sihtkoha NAT, asendades VIP-aadressi valitud tagasuunamisdestinaatori aadressiga.
3.       Edge teostab allika NAT, asendades päringu saatva kasutaja aadressi oma enda aadressiga.
4.       Pakett saadetakse valitud tagasuunamisdestinaatorile.
5.       Tagasuunamisdestinaator ei vasta otse kasutajale, vaid Edge'ile, kuna algne kasutaja aadress oli muudetud tasakaalustaja aadressiks.
6.       Edge edastab serveri vastuse kasutajale.
Allolev skeem.


Läbipaistev või inline režiim. Selles stsenaariumis on koormuse tasakaalustajal liideseid nii sise- kui ka välisvõrgus. Välisest võrgust ei ole sisevõrku otsesele ligipääsule.

Mehanism on järgmine:
1.       Kasutaja saadab päringu VIP-aadressile (tasakaalustaja aadress), mis on konfigureeritud Edge'il.
2.       Edge valib ühe tagasuunamisdestinaatoritest ja teostab sihtkoha NAT, asendades VIP-aadressi valitud tagasuunamisdestinaatori aadressiga.
3.       Paket saadetakse valitud taustteenusele.
4.       Taustteenus saab päringu kasutaja algse aadressiga (source NAT ei ole teostatud) ja vastab sellele otse.
5.       Liiklus võetakse taas vastu koormuse tasakaalustaja poolt, kuna inline skeemis toimib see tavaliselt serverifarmi vaikeväravana.
6.       Edge teostab source NAT, et saata liiklust kasutajale, kasutades oma VIP-d source IP-aadressina.
Allolev skeem.

Praktika

Minu testimise keskuses on seadistatud 3 serverit, mille Apache on konfigureeritud töötama HTTPS-iga. Edge teostab HTTPS-päringute koormuse tasakaalustamist round robin meetodiga, edastades iga uue päringu uuele serverile.
Alustame.

Genereerime SSL-sertifikaadi, mida kasutab NSX Edge.
Saate importida kehtiva CA-sertifikaadi või kasutada iseenese allkirjastatud sertifikaati. Selles testis kasutan iseenese allkirjastatud sertifikaati.

1. vCloud Director'i liideses liigume Edge teenuste seadete juurde.
   
2. Liigume sertifikaatide vahekaardile. Tegevuste loendist valime uue CSR lisamise.
   
3. Täidame vajalikud väljad ja vajutame Keep.
   
4. Valime just loodud CSR-i ja valime valiku self-sign CSR.
   
5. Valime sertifikaadi kehtivusaja ja vajutame Keep.
   
6. Enesepoolt allkirjastatud sertifikaat ilmus saadavalolevate hulka.
   

Seame Application Profile'i.
Rakendusprofiilid annavad täieliku kontrolli võrgu liikluse üle ning muudavad selle haldamise lihtsaks ja tõhusaks. Nende abil saab määrata käitumise konkreetsetele liiklustüüpidele.

1. Liigume Load Balancer'i vahekaardile ja aktiveerime tasakaalustamise. Valik Acceleration enabled aitab tasakaalustajal kasutada kiiremaks L4 tasakaalustamist L7 asemel.
   
2. Liigume rakendusprofiili vahekaardile, et määrata rakendusprofiil. Vajutage +.
   
3. Määrame profiili nime ja valime liikluse tüübi, millele profiil kehtib. Selgitan mõningaid parameetreid.
   Persistence – salvestab ja jälgib sessiooni andmeid, näiteks: milline konkreetne server teenindab kasutaja päringut. See tagab, et kasutaja päringud suunatakse kogu sessiooni või järgmiste sessioonide vältel sama grupi liikme juurde.
   Luba SSL'i edasiviimine – kui see valik on valitud, NSX Edge enam SSL'i ei termineeri. Selle asemel toimub termineerimine otse serverites, millele toimub koormuse jaotamine.
   Sisesta X-Forwarded-For HTTP päis – võimaldab määrata kliendi algse IP-aadressi, kes ühendub veebiserveriga koormuse jaotaja kaudu.
   Luba rühma poolne SSL – võimaldab määrata, et valitud rühm koosneb HTTPS-serveritest.
   
4. Kuna ma balanseerin HTTPS-liiklust, tuleb lubada rühma poolne SSL ja valida eelnevalt genereeritud sertifikaat vahekaardilt Virtuaalserveri Sertifikaadid —> Teenuse Sertifikaat.
   
5. Sama kehtib ka rühma Sertifikaatide —> Teenuse Sertifikaadi kohta.
   

Loome serverite rühma, millele liiklus jaotatakse

1. Liigume vahekaardile Rühmad. Klõpsame +.
   
2. Määrame partii nime, valime algoritmi (kasutan ringjuhitust) ja jälgimise tüübi bänneri tervisekontrolli jaoks. Valik Transparent näitab, kas algsed kliendi allika IP-d on nähtavad sisemistele serveritele.
   • Kui valik on keelatud, siis sisemistele serveritele edastatav liiklus tuleb tasakaalustajast allika IP-ga.
   • Kui valik on lubatud, näevad sisemised serverid klientide allika IP-d. Sellise konfiguratsiooni puhul peab NSX Edge olema vaikimisi värav, et tagada tagasisaadetavate pakettide läbimine NSX Edge'ist.

   NSX toetab järgmisi tasakaalustamisalgorithme:

   • IP_HASH – serveri valik põhineb hash-funktsiooni tulemuste alusel iga paketi allika ja siht-IP jaoks.
   • LEASTCONN – sisenemisseoste tasakaalustamine sõltub juba olemasolevate seoste arvust konkreetses serveris. Uued seosed suunatakse serverisse, kus on kõige vähem seoseid.
   • ROUND_ROBIN – uued seosed saadetakse vaheldumisi igasse serverisse vastavalt määratud kaalule.
   • URI – URI vasak osa (kuni küsimärgini) on häälestatud ja jagatud serverite kogukaaluga. Tulemuseks on see, milline server saab päringu, tagades, et päring suunatakse alati ühte ja samasse serverisse, kuni kõik serverid on endiselt kättesaadavad.
   • HTTPHEADER – tasakaalustamine põhineb kindlal HTTP-pealkirjal, mida saab määrata parameetrina. Kui pealkiri puudub või ei oma mingit väärtust, rakendatakse ROUND_ROBIN algoritmi.
   • URL – igas HTTP GET päringus otsib URL-i parameetrit, mis on määratud argumendina. Kui parameetrile järgneb võrdusmärk ja väärtus, siis väärtus häälestatakse ja jagatakse käivitatud serverite kogukaaluga. Tulemuseks on see, milline server saab päringu. Seda protsessi kasutatakse kasutaja ID-de jälgimiseks päringutes ja tagamiseks, et sama kasutaja ID saadetakse alati ühte ja samasse serverisse, kuni kõik serverid on endiselt kättesaadavad.

   

3. Liikmete blokis vajutage +, et lisada serverid puuli.
   
   
   1. Elasticsearch serveri aadress (seatakse installimise ajal).
   • serveri nimi;
   • serveri IP-aadress;
   • port, kuhu server saab liiklust;
   • health check'i port (Monitor healthcheck);
   • kaal (Weight) – selle parameetri abil saab reguleerida konkreetse basseini liikme jaoks saadud liikluse proportsionaalset hulka;
   • Max Connections – maksimaalne ühenduste arv serverisse;
   • Min Connections – minimaalne ühenduste arv, mida server peab töötlema, enne kui liiklus suunatakse järgmisele basseini liikmele.

   
   
   Nii näeb välja lõppbassein kolmest serverist.
   

Lisame Virtuaalse Serveri

1. Liigume Virtuaalsete Serverite vahekaardile. Vajutame +.
   
2. Aktiveerime virtuaalse serveri, kasutades Enable Virtual Server.
   Määrame nime, valime varem loodud Rakenduse Profiili, Basseini ja näitame IP-aadressi, kuhu Virtuaalne Server väljastpoolt päringuid vastu võtab. Valime protokolliks HTTPS ja pordiks 443.
   Siin on valikulised parameetrid:
   Connection Limit – maksimaalne arv samaaegseid ühendusi, mida virtuaalne server suudab töödelda;
   Connection Rate Limit (CPS) – maksimaalne arv uusi sissetulevaid päringuid sekundis.
   

Selle konfiguratsiooni koormuse jaotaja lõpetamine on nüüdseks tehtud ja saab kontrollida selle tööd. Serveritel on lihtne konfiguratsioon, mis võimaldab mõista, milline server grupist on päringut töötlenud. Seadistuse käigus valisime Round Robin tasakaalustamismeetodi ja iga serveri kaal on üks, seega töödeldakse iga järgmine päring järgmise serveri poolt grupist.
Sisestame brauserisse koormuse jaotaja välise aadressi ja näeme:


Pärast lehe uuendamist töödeldakse päring järgmise serveri poolt:


Ja veel kord – et kontrollida ka kolmandat serverit grupist:


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

Kontrollige koormuse jaotaja staatust Edge gateway konsoolist. Selleks sisestage show service loadbalancer pool.


Seadistame teenuse monitori serverite seisundi kontrollimiseks grupis
Teenuse monitori abil saame jälgida serverite seisundit tagapool grupis. Kui päringu vastus ei vasta ootusele, saab serveri grupist eemaldada, et see ei saaks uusi päringuid.
Vaikimisi on seadistatud kolm kontrollimise meetodit:

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

Loome uus.

1. Liigume jaotisse Service Monitoring, klõpsame +.
   
2. Valime:
   • uue meetodi nime;
   • intervall, millega päringud saadetakse,
   • ootamise aja piirang,
   • monitooringu tüüp – HTTPS päring, kasutades meetodit GET, oodatav staatuse kood – 200 (OK) ja päringu URL.
3. Sellega on uue Service Monitori seadistamine lõpetatud, nüüd saame seda kasutada puu loomisel.
   

Seame Application Rules

Application Rules – liikluse käsitlemise meetod, mis põhineb teatud vallandajatel. Selle tööriistaga saame luua täiustatud koormuse tasakaalustamise reegleid, mille seadistamine võib olla võimatu läbi Application profiles või teiste teenuste, mis on saadaval Edge Gatewayl.

1. Reegli loomiseks liigume koormuse tasakaalustaja jaotisse Application Rules.
   
2. Valime nime, skripti, mis reeglit kasutab, ja klõpsame Keep.
   
3. Pärast reegli loomist peame redigeerima juba seadistatud Virtual Serverit.
   
4. Jaotises Advanced lisame meie loodud reegli.
   

Ülaltoodud näites aktiveerisime tlsv1 toe.

Veel mõned näited:

Liikluse suunamine teise puusse.
Selle skripti abil saame suunata liiklust teise tasakaalustusgruppi, kui põhigrupp ei toimi. Et reegel rakenduks, peab tasakaalustajal olema konfigureeritud mitu gruppi ja kõik põhigrupi liikmed peavad olema seisundis 'down'. Tuleb näidata just grupi nime, mitte selle ID-d.

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


Liikluse ümber suunamine välistesse allikatesse.
Siin suuname liikluse välish veebisaidile, kui kõik põhigrupi osalised on seisundis 'down'.

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

Veel rohkem näiteid siin.

Sellega on tasakaalustaja teemad kaetud. Kui on küsimusi, küsige, vastan meeleldi.

Allikas: habr.com