De vorige keer hadden we het over de mogelijkheden van NSX Edge op het gebied van statische en dynamische routing, en vandaag zullen we ons bezighouden met de load balancer.
Voordat we beginnen met het opzetten, wil ik u kort herinneren aan de belangrijkste soorten balancering.
Теория
Alle hedendaagse oplossingen voor het balanceren van de payload zijn meestal onderverdeeld in twee categorieën: balanceren op het vierde (transport) en zevende (toepassings) niveau van het model . Het OSI-model is niet het beste referentiepunt bij het beschrijven van balanceringsmethoden. Als een L4-balancer bijvoorbeeld ook TLS-beëindiging ondersteunt, wordt deze dan een L7-balancer? Maar het is wat het is.
- Balans L4 meestal is het een middelste proxy die tussen de client en een reeks beschikbare backends staat, die TCP-verbindingen beëindigt (dat wil zeggen, onafhankelijk reageert op SYN), een backend selecteert en een nieuwe TCP-sessie in zijn richting initieert, waarbij onafhankelijk SYN wordt verzonden. Dit type is een van de basistypes; andere opties zijn mogelijk.
- Balans L7 verdeelt verkeer over beschikbare backends die “geavanceerd” zijn dan de L4-balancer. Het kan beslissen welke backend het moet kiezen op basis van bijvoorbeeld de inhoud van het HTTP-bericht (URL, cookie, etc.).
Ongeacht het type kan de balancer de volgende functies ondersteunen:
- Servicedetectie is het proces waarbij de set beschikbare backends wordt bepaald (Statisch, DNS, Consul, Etcd, enz.).
- Controle van de functionaliteit van de gedetecteerde backends (actieve “ping” van de backend met behulp van een HTTP-verzoek, passieve detectie van problemen in TCP-verbindingen, de aanwezigheid van verschillende 503 HTTP-codes in de antwoorden, enz.).
- Het balanceren zelf (round robin, willekeurige selectie, bron-IP-hash, URI).
- TLS-beëindiging en certificaatverificatie.
- Beveiligingsgerelateerde opties (authenticatie, preventie van DoS-aanvallen, snelheidsbeperking) en nog veel meer.
NSX Edge biedt ondersteuning voor twee load balancer-implementatiemodi:
Proxymodus of eenarmig. In deze modus gebruikt NSX Edge zijn IP-adres als bronadres bij het verzenden van een verzoek naar een van de backends. De balancer voert dus gelijktijdig de functies van Source- en Destination NAT uit. De backend ziet al het verkeer zoals verzonden vanuit de balancer en reageert daar direct op. In een dergelijk schema moet de balancer zich in hetzelfde netwerksegment bevinden als de interne servers.
Hier is hoe het gaat:
1. De gebruiker stuurt een verzoek naar het VIP-adres (balanceradres) dat op de Edge is geconfigureerd.
2. Edge selecteert een van de backends en voert bestemmings-NAT uit, waarbij het VIP-adres wordt vervangen door het adres van de geselecteerde backend.
3. Edge voert bron-NAT uit en vervangt het adres van de gebruiker die het verzoek heeft verzonden door zijn eigen adres.
4. Het pakket wordt naar de geselecteerde backend verzonden.
5. De backend reageert niet rechtstreeks op de gebruiker, maar op de Edge, aangezien het oorspronkelijke adres van de gebruiker is gewijzigd in het adres van de balancer.
6. Edge verzendt het antwoord van de server naar de gebruiker.
Het diagram staat hieronder.
Transparante of inline-modus. In dit scenario heeft de balancer interfaces op de interne en externe netwerken. Tegelijkertijd is er geen directe toegang tot het interne netwerk vanaf het externe. De ingebouwde load balancer fungeert als NAT-gateway voor virtuele machines op het interne netwerk.
Het mechanisme is als volgt:
1. De gebruiker stuurt een verzoek naar het VIP-adres (balanceradres) dat op de Edge is geconfigureerd.
2. Edge selecteert een van de backends en voert bestemmings-NAT uit, waarbij het VIP-adres wordt vervangen door het adres van de geselecteerde backend.
3. Het pakket wordt naar de geselecteerde backend verzonden.
4. De backend ontvangt een verzoek met het oorspronkelijke adres van de gebruiker (bron-NAT is niet uitgevoerd) en reageert hier direct op.
5. Het verkeer wordt opnieuw geaccepteerd door de load balancer, omdat deze in een inline-schema meestal fungeert als de standaardgateway voor de serverfarm.
6. Edge voert bron-NAT uit om verkeer naar de gebruiker te sturen, waarbij de VIP als bron-IP-adres wordt gebruikt.
Het diagram staat hieronder.
Praktijk
Mijn testbank heeft 3 servers waarop Apache draait, die is geconfigureerd om via HTTPS te werken. Edge zal een round robin-balancering van HTTPS-verzoeken uitvoeren, waarbij elk nieuw verzoek naar een nieuwe server wordt gestuurd.
Laten we beginnen.
Het genereren van een SSL-certificaat dat door NSX Edge zal worden gebruikt
U kunt een geldig CA-certificaat importeren of een zelfondertekend certificaat gebruiken. Voor deze test gebruik ik self-signed.
- Ga in de vCloud Director-interface naar de Edge-services-instellingen.
- Ga naar het tabblad Certificaten. Selecteer in de lijst met acties het toevoegen van een nieuwe CSR.
- Vul de verplichte velden in en klik op Behouden.
- Selecteer de nieuw aangemaakte CSR en selecteer de CSR-optie voor zelfondertekening.
- Selecteer de geldigheidsduur van het certificaat en klik op Behouden
- Het zelfondertekende certificaat verschijnt in de lijst met beschikbare certificaat.
Applicatieprofiel instellen
Applicatieprofielen geven u meer volledige controle over het netwerkverkeer en maken het beheer ervan eenvoudig en effectief. Ze kunnen worden gebruikt om het gedrag van specifieke soorten verkeer te definiëren.
- Ga naar het tabblad Load Balancer en schakel de balancer in. Met de optie Versnelling ingeschakeld kan de balancer een snellere L4-balancering gebruiken in plaats van L7.
- Ga naar het tabblad Applicatieprofiel om het applicatieprofiel in te stellen. Klik op +.
- Stel de naam van het profiel in en selecteer het type verkeer waarvoor het profiel wordt toegepast. Laat me enkele parameters uitleggen.
Volharding – slaat sessiegegevens op en volgt deze, bijvoorbeeld: welke specifieke server in de pool het gebruikersverzoek afhandelt. Dit zorgt ervoor dat gebruikersaanvragen worden doorgestuurd naar hetzelfde poollid gedurende de levensduur van de sessie of daaropvolgende sessies.
Schakel SSL-passthrough in – Wanneer deze optie is geselecteerd, stopt NSX Edge met het beëindigen van SSL. In plaats daarvan vindt beëindiging rechtstreeks plaats op de servers die in evenwicht worden gebracht.
Voeg X-Forwarded-For HTTP-header in – hiermee kunt u het bron-IP-adres bepalen van de client die via de load balancer verbinding maakt met de webserver.
Schakel SSL aan zwembadzijde in – hiermee kunt u opgeven dat de geselecteerde pool uit HTTPS-servers bestaat.
- Omdat ik het HTTPS-verkeer zal balanceren, moet ik Pool Side SSL inschakelen en het eerder gegenereerde certificaat selecteren op het tabblad Virtuele servercertificaten -> Servicecertificaat.
- Hetzelfde geldt voor Poolcertificaten -> Servicecertificaat.
We creëren een pool van servers, waarvan het verkeer uit evenwichtige pools zal bestaan
- Ga naar het tabblad Pools. Klik op +.
- We stellen de naam van de pool in, selecteren het algoritme (ik gebruik round robin) en het type monitoring voor de backend voor de health check. De optie Transparent geeft aan of de initiële bron-IP's van clients zichtbaar zijn voor interne servers.
- Als de optie is uitgeschakeld, is het verkeer voor interne servers afkomstig van het bron-IP-adres van de balancer.
- Als de optie is ingeschakeld, zien interne servers het bron-IP-adres van clients. In deze configuratie moet NSX Edge fungeren als de standaardgateway om ervoor te zorgen dat geretourneerde pakketten via NSX Edge passeren.
NSX ondersteunt de volgende balanceringsalgoritmen:
- IP_HASH – serverselectie op basis van de resultaten van een hashfunctie voor het bron- en bestemmings-IP van elk pakket.
- MINSTECONN – balanceren van inkomende verbindingen, afhankelijk van het aantal dat al beschikbaar is op een bepaalde server. Nieuwe verbindingen worden doorgestuurd naar de server met de minste verbindingen.
- RONDE_ROBIN – nieuwe verbindingen worden beurtelings naar elke server verzonden, in overeenstemming met het eraan toegekende gewicht.
- URI – het linkergedeelte van de URI (vóór het vraagteken) wordt gehasht en gedeeld door het totale gewicht van de servers in de pool. Het resultaat geeft aan welke server het verzoek ontvangt, zodat het verzoek altijd naar dezelfde server wordt gerouteerd, zolang alle servers beschikbaar blijven.
- HTTPHEADER – balancering op basis van een specifieke HTTP-header, die als parameter kan worden opgegeven. Als de header ontbreekt of geen waarde heeft, wordt het ROUND_ROBIN-algoritme toegepast.
- URL – Bij elk HTTP GET-verzoek wordt gezocht naar de URL-parameter die als argument is opgegeven. Als de parameter wordt gevolgd door een gelijkteken en een waarde, wordt de waarde gehasht en gedeeld door het totale gewicht van actieve servers. Het resultaat geeft aan welke server het verzoek ontvangt. Dit proces wordt gebruikt om gebruikers-ID's in verzoeken bij te houden en ervoor te zorgen dat hetzelfde gebruikers-ID altijd naar dezelfde server wordt verzonden, zolang alle servers beschikbaar blijven.
- Klik in het ledenblok op + om servers aan de pool toe te voegen.
Hier moet u aangeven:- server naam;
- Server IP adres;
- de poort waarop de server verkeer zal ontvangen;
- poort voor gezondheidscontrole (Monitor healthcheck);
- gewicht – met deze parameter kunt u de proportionele hoeveelheid verkeer aanpassen die voor een specifiek poollid wordt ontvangen;
- Max. verbindingen – maximaal aantal verbindingen met de server;
- Min. verbindingen – het minimumaantal verbindingen dat de server moet verwerken voordat verkeer wordt doorgestuurd naar het volgende poollid.
Zo ziet de uiteindelijke pool van drie servers eruit.
Virtuele server toevoegen
- Ga naar het tabblad Virtuele servers. Klik op +.
- We activeren de virtuele server met Enable Virtual Server.
We geven het een naam, selecteren het eerder gemaakte applicatieprofiel, de pool en geven het IP-adres aan waarnaar de virtuele server verzoeken van buitenaf zal ontvangen. We specificeren het HTTPS-protocol en poort 443.
Optionele parameters hier:
Verbindingslimiet – het maximale aantal gelijktijdige verbindingen dat de virtuele server kan verwerken;
Limiet verbindingssnelheid (CPS) – het maximale aantal nieuwe inkomende verzoeken per seconde.
Hiermee is de configuratie van de balancer voltooid; u kunt de functionaliteit ervan controleren. De servers hebben een eenvoudige configuratie waarmee u kunt begrijpen welke server uit de pool het verzoek heeft verwerkt. Tijdens de installatie hebben we het Round Robin-balanceringsalgoritme gekozen en de parameter Weight voor elke server is gelijk aan één, zodat elk volgend verzoek wordt verwerkt door de volgende server uit de pool.
We voeren het externe adres van de balancer in de browser in en zien:
Na het vernieuwen van de pagina wordt het verzoek verwerkt door de volgende server:
En nogmaals - om de derde server uit de pool te controleren:
Bij controle kunt u zien dat het certificaat dat Edge ons stuurt hetzelfde is als het certificaat dat we in het begin hebben gegenereerd.
Balancerstatus controleren vanaf de Edge-gatewayconsole. Om dit te doen, voert u in toon service loadbalancer-pool.
Service Monitor configureren om de status van servers in de pool te controleren
Met Service Monitor kunnen we de status van servers in de backendpool monitoren. Als de reactie op een verzoek niet naar verwachting is, kan de server uit de pool worden gehaald, zodat deze geen nieuwe verzoeken ontvangt.
Standaard zijn er drie verificatiemethoden geconfigureerd:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Laten we een nieuwe maken.
- Ga naar het tabblad Servicemonitoring en klik op +.
- Kiezen:
- naam voor de nieuwe methode;
- het interval waarmee verzoeken worden verzonden,
- time-out bij wachten op antwoord,
- monitoringtype – HTTPS-verzoek met behulp van de GET-methode, verwachte statuscode – 200 (OK) en verzoek-URL.
- Hiermee is de installatie van de nieuwe Service Monitor voltooid; nu kunnen we deze gebruiken bij het maken van een pool.
Applicatieregels instellen
Applicatieregels zijn een manier om verkeer te manipuleren op basis van bepaalde triggers. Met deze tool kunnen we geavanceerde taakverdelingsregels maken die mogelijk niet mogelijk zijn via applicatieprofielen of andere services die beschikbaar zijn op de Edge Gateway.
- Om een regel aan te maken, gaat u naar het tabblad Applicatieregels van de balancer.
- Selecteer een naam, een script dat de regel gaat gebruiken en klik op Behouden.
- Nadat de regel is gemaakt, moeten we de reeds geconfigureerde virtuele server bewerken.
- Voeg op het tabblad Geavanceerd de regel toe die we hebben gemaakt.
In het bovenstaande voorbeeld hebben we tlsv1-ondersteuning ingeschakeld.
Nog een paar voorbeelden:
Verkeer omleiden naar een andere pool.
Met dit script kunnen we verkeer omleiden naar een andere balanceringspool als de hoofdpool niet beschikbaar is. Om de regel te laten werken, moeten er meerdere pools op de balancer zijn geconfigureerd en moeten alle leden van de hoofdpool zich in de down-status bevinden. U moet de naam van de pool opgeven, niet de ID ervan.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Verkeer omleiden naar een externe bron.
Hier leiden we verkeer om naar de externe website als alle leden van de hoofdpool offline zijn.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Nog meer voorbeelden .
Dat is voor mij alles over de balancer. Als je vragen hebt, stel ze dan, ik sta klaar om te antwoorden.
Bron: www.habr.com