VMware NSX vir die kleintjies. Deel 5: Opstel van 'n Load Balancer

Deel een. inleidend
Deel twee. Konfigureer Firewall en NAT-reëls
Deel drie. Konfigureer DHCP
Deel vier. Roete-opstelling

Laas het ons gepraat oor die vermoëns van NSX Edge in terme van statiese en dinamiese roetering, en vandag gaan ons met die lasbalanseerder handel.
Voordat ons begin opstel, wil ek jou kortliks herinner aan die hooftipes balansering.

teorie

Al vandag se loonvragbalanseringsoplossings word meestal in twee kategorieë verdeel: balansering op die vierde (vervoer) en sewende (toepassing) vlak van die model OF INDIEN. Die OSI-model is nie die beste verwysingspunt wanneer balanseringsmetodes beskryf word nie. Byvoorbeeld, as 'n L4-balanseerder ook TLS-beëindiging ondersteun, word dit dan 'n L7-balanseerder? Maar dit is wat dit is.

• Balanseerder L4 meestal is dit 'n middelste instaanbediener wat tussen die kliënt en 'n stel beskikbare backends staan, wat TCP-verbindings beëindig (dit wil sê, onafhanklik reageer op SYN), 'n backend kies en 'n nuwe TCP-sessie in sy rigting inisieer, wat SYN onafhanklik stuur. Hierdie tipe is een van die basiese; ander opsies is moontlik.
• Balanseerder L7 versprei verkeer oor beskikbare backends "meer gesofistikeerd" as wat die L4-balanseerder doen. Dit kan besluit watter backend om te kies gebaseer op, byvoorbeeld, die inhoud van die HTTP-boodskap (URL, koekie, ens.).

Ongeag die tipe, kan die balanseerder die volgende funksies ondersteun:

• Diensontdekking is die proses om die stel beskikbare backends (Static, DNS, Consul, Ens, ens.) te bepaal.
• Kontroleer die funksionaliteit van die bespeurde backends (aktiewe "ping" van die backend met behulp van 'n HTTP-versoek, passiewe opsporing van probleme in TCP-verbindings, die teenwoordigheid van verskeie 503 HTTP-kodes in die antwoorde, ens.).
• Die balansering self (round robin, ewekansige seleksie, bron IP-hash, URI).
• TLS-beëindiging en sertifikaatverifikasie.
• Sekuriteitverwante opsies (verifikasie, DoS-aanvalvoorkoming, spoedbeperking) en nog baie meer.

NSX Edge bied ondersteuning vir twee load balancer-ontplooiingsmodusse:

Proxy-modus, of eenarm. In hierdie modus gebruik NSX Edge sy IP-adres as die bronadres wanneer 'n versoek na een van die backends gestuur word. Die balanseerder voer dus gelyktydig die funksies van Bron en Bestemming NAT uit. Die agterkant sien alle verkeer soos gestuur vanaf die balanseerder en reageer direk daarop. In so 'n skema moet die balanseerder in dieselfde netwerksegment met die interne bedieners wees.

Hier is hoe dit gaan:
1. Die gebruiker stuur 'n versoek na die BBP-adres (balanseerderadres) wat op die Edge gekonfigureer is.
2. Edge kies een van die backends en voer bestemming NAT uit, en vervang die VIP-adres met die adres van die geselekteerde backend.
3. Edge voer bron-NAT uit, en vervang die adres van die gebruiker wat die versoek gestuur het met sy eie.
4. Die pakket word na die geselekteerde agterkant gestuur.
5. Die backend reageer nie direk op die gebruiker nie, maar op die Edge, aangesien die gebruiker se oorspronklike adres na die balanseerder se adres verander is.
6. Edge stuur die bediener se reaksie aan die gebruiker oor.
Die diagram is hieronder.


Deursigtige, of inlyn, modus. In hierdie scenario het die balanseerder koppelvlakke op die interne en eksterne netwerke. Terselfdertyd is daar geen direkte toegang tot die interne netwerk vanaf die eksterne een nie. Die ingeboude lasbalanseerder dien as 'n NAT-poort vir virtuele masjiene op die interne netwerk.

Die meganisme is soos volg:
1. Die gebruiker stuur 'n versoek na die BBP-adres (balanseerderadres) wat op die Edge gekonfigureer is.
2. Edge kies een van die backends en voer bestemming NAT uit, en vervang die VIP-adres met die adres van die geselekteerde backend.
3. Die pakket word na die geselekteerde agterkant gestuur.
4. Die backend ontvang 'n versoek met die gebruiker se oorspronklike adres (bron NAT is nie uitgevoer nie) en reageer direk daarop.
5. Die verkeer word weer deur die lasbalanseerder aanvaar, aangesien dit in 'n inlynskema gewoonlik as die verstekpoort vir die bedienerplaas optree.
6. Edge voer bron-NAT uit om verkeer na die gebruiker te stuur, met sy VIP as die bron-IP-adres.
Die diagram is hieronder.

Praktyk

My toetsbank het 3 bedieners wat Apache gebruik, wat opgestel is om oor HTTPS te werk. Edge sal rondweg-balansering van HTTPS-versoeke uitvoer, en elke nuwe versoek na 'n nuwe bediener stuur.
Laat ons begin.

Genereer 'n SSL-sertifikaat wat deur NSX Edge gebruik sal word
Jy kan 'n geldige CA-sertifikaat invoer of 'n selfondertekende een gebruik. Vir hierdie toets sal ek self-onderteken gebruik.

1. Gaan in die vCloud Director-koppelvlak na die Edge-dienste-instellings.
   
2. Gaan na die Sertifikate-oortjie. Kies die byvoeging van 'n nuwe CSR uit die lys van aksies.
   
3. Vul die vereiste velde in en klik Hou.
   
4. Kies die nuutgeskepte CSR en kies die selfteken CSR-opsie.
   
5. Kies die geldigheidstydperk van die sertifikaat en klik Hou
   
6. Die self-ondertekende sertifikaat verskyn in die lys van beskikbare.
   

Stel toepassingsprofiel op
Toepassingsprofiele gee jou meer volledige beheer oor netwerkverkeer en maak die bestuur daarvan eenvoudig en effektief. Hulle kan gebruik word om gedrag vir spesifieke soorte verkeer te definieer.

1. Gaan na die Load Balancer-oortjie en aktiveer die balancer. Die versnelling-geaktiveerde opsie hier laat die balanseerder toe om vinniger L4-balansering in plaas van L7 te gebruik.
   
2. Gaan na die Toepassingsprofiel-oortjie om die toepassingsprofiel te stel. Klik op +.
   
3. Stel die naam van die profiel en kies die tipe verkeer waarvoor die profiel toegepas sal word. Kom ek verduidelik 'n paar parameters.
   Volharding – stoor en volg sessiedata, byvoorbeeld: watter spesifieke bediener in die swembad die gebruikerversoek bedien. Dit verseker dat gebruikersversoeke na dieselfde poellid gestuur word vir die leeftyd van die sessie of daaropvolgende sessies.
   Aktiveer SSL-deurlaat – Wanneer hierdie opsie gekies word, stop NSX Edge om SSL te beëindig. In plaas daarvan vind beëindiging direk plaas op die bedieners wat gebalanseer word.
   Voeg X-Forwarded-For HTTP-opskrif in – laat jou toe om die bron-IP-adres van die kliënt wat aan die webbediener koppel deur die lasbalanseerder te bepaal.
   Aktiveer Pool Side SSL – laat jou toe om te spesifiseer dat die geselekteerde poel uit HTTPS-bedieners bestaan.
   
4. Aangesien ek HTTPS-verkeer sal balanseer, moet ek Pool Side SSL aktiveer en die voorheen gegenereerde sertifikaat in die Virtuele bedienersertifikate -> Dienssertifikaat-oortjie kies.
   
5. Net so vir swembadsertifikate -> dienssertifikaat.
   

Ons skep 'n poel van bedieners, die verkeer sal gebalanseerde Pools

1. Gaan na die Pools-oortjie. Klik op +.
   
2. Ons stel die naam van die swembad, kies die algoritme (ek sal round robin gebruik) en die tipe monitering vir die gesondheidskontrole-agterkant Die Deursigtige opsie dui aan of die aanvanklike bron-IP's van kliënte sigbaar is vir interne bedieners.
   • As die opsie gedeaktiveer is, kom verkeer vir interne bedieners vanaf die bron-IP van die balanseerder.
   • As die opsie geaktiveer is, sien interne bedieners die bron-IP van kliënte. In hierdie opstelling moet NSX Edge as die verstekpoort optree om te verseker dat teruggekeerde pakkies deur NSX Edge gaan.

   NSX ondersteun die volgende balanseringsalgoritmes:

   • IP_HASH - bedienerseleksie gebaseer op die resultate van 'n hash-funksie vir die bron- en bestemmings-IP van elke pakkie.
   • LEASTCONN – balansering van inkomende verbindings, afhangende van die nommer wat reeds op 'n spesifieke bediener beskikbaar is. Nuwe verbindings sal na die bediener met die minste verbindings gerig word.
   • ROUND_ROBIN – nuwe verbindings word om die beurt na elke bediener gestuur, in ooreenstemming met die gewig wat daaraan toegeken is.
   • URI – die linker gedeelte van die URI (voor die vraagteken) word gehash en gedeel deur die totale gewig van bedieners in die swembad. Die resultaat dui aan watter bediener die versoek ontvang, om te verseker dat die versoek altyd na dieselfde bediener gestuur word, solank alle bedieners beskikbaar bly.
   • HTTPHEADER – balansering gebaseer op 'n spesifieke HTTP-opskrif, wat as 'n parameter gespesifiseer kan word. As die kopskrif ontbreek of geen waarde het nie, word die ROUND_ROBIN-algoritme toegepas.
   • URL - Elke HTTP GET-versoek soek na die URL-parameter wat as 'n argument gespesifiseer is. As die parameter gevolg word deur 'n gelyke teken en 'n waarde, dan word die waarde gehash en gedeel deur die totale gewig van lopende bedieners. Die resultaat dui aan watter bediener die versoek ontvang. Hierdie proses word gebruik om tred te hou met gebruikers-ID's in versoeke en te verseker dat dieselfde gebruiker-ID altyd na dieselfde bediener gestuur word, solank alle bedieners beskikbaar bly.

   

3. In die Lede-blok, klik + om bedieners by die swembad te voeg.
   
   
   Hier moet jy spesifiseer:
   • bediener naam;
   • Bediener IP-adres;
   • die poort waarop die bediener verkeer sal ontvang;
   • poort vir gesondheidskontrole (Monitor healthcheck);
   • gewig – met hierdie parameter kan u die proporsionele hoeveelheid verkeer wat vir 'n spesifieke swembadlid ontvang word, aanpas;
   • Maksimum verbindings – maksimum aantal verbindings met die bediener;
   • Min verbindings – die minimum aantal verbindings wat die bediener moet verwerk voordat verkeer na die volgende swembadlid gestuur word.

   
   
   Dit is hoe die finale poel van drie bedieners lyk.
   

Voeg virtuele bediener by

1. Gaan na die Virtuele bedieners-oortjie. Klik op +.
   
2. Ons aktiveer die virtuele bediener met Aktiveer virtuele bediener.
   Ons gee dit 'n naam, kies die voorheen geskepte toepassingsprofiel, poel en dui die IP-adres aan waarheen die virtuele bediener versoeke van buite sal ontvang. Ons spesifiseer die HTTPS-protokol en poort 443.
   Opsionele parameters hier:
   Verbindingsbeperking – die maksimum aantal gelyktydige verbindings wat die virtuele bediener kan verwerk;
   Verbindingskoerslimiet (CPS) – die maksimum aantal nuwe inkomende versoeke per sekonde.
   

Dit voltooi die konfigurasie van die balanseerder; jy kan die funksionaliteit daarvan nagaan. Die bedieners het 'n eenvoudige konfigurasie wat jou toelaat om te verstaan ​​watter bediener uit die swembad die versoek verwerk het. Tydens die opstelling het ons die Round Robin-balanseringsalgoritme gekies, en die gewig-parameter vir elke bediener is gelyk aan een, so elke daaropvolgende versoek sal deur die volgende bediener uit die swembad verwerk word.
Ons voer die eksterne adres van die balanseerder in die blaaier in en sien:


Nadat die bladsy verfris is, sal die versoek deur die volgende bediener verwerk word:


En weer - om die derde bediener vanaf die swembad na te gaan:


Wanneer u nagaan, kan u sien dat die sertifikaat wat Edge vir ons stuur, dieselfde is as wat ons heel aan die begin gegenereer het.

Kontroleer balanseerderstatus vanaf die Edge-poortkonsole. Om dit te doen, voer in wys diens loadbalancer swembad.


Diensmonitor opstel om die status van bedieners in die swembad na te gaan
Met Service Monitor kan ons die status van bedieners in die backend-poel monitor. As die reaksie op 'n versoek nie soos verwag is nie, kan die bediener uit die swembad gehaal word sodat dit geen nuwe versoeke ontvang nie.
By verstek is drie verifikasiemetodes opgestel:

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

Kom ons skep 'n nuwe een.

1. Gaan na die Diensmonitering-oortjie, klik +.
   
2. Kies:
   • naam vir die nuwe metode;
   • die interval waarteen versoeke gestuur sal word,
   • time-out wag vir 'n antwoord,
   • moniteringstipe – HTTPS-versoek met behulp van die GET-metode, verwagte statuskode – 200 (OK) en versoek-URL.
3. Dit voltooi die opstelling van die nuwe diensmonitor; nou kan ons dit gebruik wanneer 'n swembad geskep word.
   

Opstel van toepassingsreëls

Toepassingsreëls is 'n manier om verkeer te manipuleer op grond van sekere snellers. Met hierdie hulpmiddel kan ons gevorderde lasbalanseringsreëls skep wat dalk nie moontlik is deur toepassingsprofiele of ander dienste wat op die Edge Gateway beskikbaar is nie.

1. Om 'n reël te skep, gaan na die Toepassingsreëls-oortjie van die balanseerder.
   
2. Kies 'n naam, 'n skrif wat die reël sal gebruik, en klik Hou.
   
3. Nadat die reël geskep is, moet ons die reeds gekonfigureerde virtuele bediener wysig.
   
4. Voeg die reël wat ons geskep het by die Gevorderde-oortjie.
   

In die voorbeeld hierbo het ons tlsv1-ondersteuning geaktiveer.

Nog 'n paar voorbeelde:

Herlei verkeer na 'n ander swembad.
Met hierdie skrif kan ons verkeer na 'n ander balanseringspoel herlei as die hoofpoel af is. Vir die reël om te werk, moet veelvuldige swembaddens op die balanseerder gekonfigureer word en alle lede van die hoofpoel moet in die af-toestand wees. Jy moet die naam van die swembad spesifiseer, nie sy ID nie.

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


Herlei verkeer na 'n eksterne hulpbron.
Hier herlei ons verkeer na die eksterne webwerf as alle lede van die hoofpoel af is.

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

Nog meer voorbeelde hier.

Dit is al vir my oor die balanseerder. As jy enige vrae het, vra, ek is gereed om te antwoord.

Bron: will.com