Vorige keer spraken we over de mogelijkheden van NSX Edge met betrekking tot statische en dynamische routering, en vandaag gaan we het hebben over de load balancer.
Voordat we met de configuratie beginnen, wil ik heel kort de belangrijkste soorten load balancing herinneren.
Theorie
De meeste huidige oplossingen voor load balancing worden vaak in twee categorieën verdeeld: load balancing op de vierde (transport) en zevende (toepassings) lagen van het model. Het OSI-model is niet de beste referentie bij het beschrijven van de methoden voor load balancing. Bijvoorbeeld, als een L4-load balancer ook TLS-terminatie ondersteunt, wordt het dan een L7-load balancer? Maar dat is hoe het is.
- Een L4-load balancer is vaak een tussenliggende proxy die zich bevindt tussen de client en een set beschikbare backends en die TCP-verbindingen beëindigt (dat wil zeggen, zelf op SYN antwoordt), een backend kiest en een nieuwe TCP-sessie in die richting initieert door zelf SYN te verzenden. Dit type is vrij basis; er zijn ook andere mogelijkheden.
- Een L7-load balancer verdeelt het verkeer op een 'fijnere' manier over de beschikbare backends dan een L4-load balancer. Hij kan besluiten welke backend te kiezen op basis van bijvoorbeeld de inhoud van het HTTP-bericht (URL, cookie, enz.).
Ongeacht het type kan de load balancer de volgende functies ondersteunen:
- Service discovery – het proces van het bepalen van de set beschikbare backends (Static, DNS, Consul, Etcd, enz.).
- De gezondheidstoetsing van ontdekte backends (actieve 'ping' naar de backend met een HTTP-verzoek, passieve probleemdetectie in TCP-verbindingen, aanwezigheid van meerdere opeenvolgende 503 HTTP-codes in de antwoorden, enz.).
- De load balancing zelf (round robin, willekeurige selectie, hash van het IP-adres van de bron, URI).
- TLS-terminatie en certificaatvalidatie.
- Opties met betrekking tot beveiliging (authenticatie, tegen DoS-aanvallen, snelheidslimitering) en nog veel meer.
NSX Edge biedt ondersteuning voor twee uitrolmodi van de load balancer:
Proxy-modus, of one-arm. In deze modus gebruikt NSX Edge zijn IP-adres als bronadres bij het verzenden van een verzoek naar een van de back-ends. Zo vervult de load balancer tegelijkertijd de functies van Source en Destination NAT. De backend ziet al het verkeer als verzonden door de load balancer en beantwoordt het rechtstreeks. In dit schema moet de load balancer zich in hetzelfde netwerksegment bevinden als de interne servers.
Dit is hoe het verloopt:
1. De gebruiker verzendt een verzoek naar het VIP-adres (het adres van de load balancer), dat is geconfigureerd op Edge.
2. Edge selecteert een van de back-ends en voert destination NAT uit, waarbij het VIP-adres wordt vervangen door het adres van de geselecteerde backend.
3. Edge voert source NAT uit, waarbij het adres van de verzoekende gebruiker wordt vervangen door het zijne.
4. Het pakket wordt naar de geselecteerde backend verzonden.
5. De backend beantwoordt niet rechtstreeks de gebruiker, maar Edge, aangezien het oorspronkelijke adres van de gebruiker is gewijzigd in het adres van de load balancer.
6. Edge geeft het antwoord van de server aan de gebruiker door.
De onderstaande schema.
Transparante of inline modus. In dit scenario heeft de load balancer interfaces in zowel het interne als het externe netwerk. Er is geen directe toegang tot het interne netwerk van buitenaf. De ingebouwde load balancer fungeert als een NAT-gateway voor de virtuele machines in het interne netwerk.
Het mechanisme is als volgt:
1. De gebruiker verzendt een verzoek naar het VIP-adres (het adres van de load balancer), dat is geconfigureerd op Edge.
2. Edge selecteert een van de back-ends en voert destination 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 het verzoek met het oorspronkelijke adres van de gebruiker (source NAT is niet uitgevoerd) en beantwoordt het rechtstreeks.
5. Het verkeer wordt opnieuw door de load balancer ontvangen, aangezien hij in de inline-configuratie doorgaans als de standaardgateway voor de serverfarm fungeert.
6. Edge voert source NAT uit om het verkeer naar de gebruiker te verzenden, waarbij hij zijn VIP gebruikt als source IP-adres.
De onderstaande schema.
Praktijk
Op mijn testomgeving zijn 3 servers ingesteld met Apache, dat is geconfigureerd om via HTTPS te werken. Edge zal HTTPS-verzoeken balanceren volgens de round robin-methode, waarbij elke nieuwe aanvraag naar een nieuwe server wordt geproxy'd.
Laten we beginnen.
Genereer een SSL-certificaat dat door NSX Edge zal worden gebruikt
U kunt een geldig CA-certificaat importeren of een zelfondertekend certificaat gebruiken. In deze test zal ik een zelfondertekend certificaat gebruiken.
- Ga in de interface van vCloud Director naar de instellingen van de Edge-services.
- Ga naar het tabblad Certificaten. Kies in de actielijst voor het toevoegen van een nieuw CSR.
- Vul de benodigde velden in en klik op Keep.
- Selecteer de zojuist aangemaakte CSR en kies de optie self-sign CSR.
- Kies de geldigheidsduur van het certificaat en klik op Keep.
- Het zelfondertekende certificaat is verschenen in de lijst met beschikbare certificaten.
Stel het Applicatieprofiel in.
Applicatieprofielen bieden meer controle over netwerkverkeer en maken het beheer ervan eenvoudig en effectief. Hiermee kan het gedrag voor specifieke soorten verkeer worden gedefinieerd.
- Ga naar het tabblad Load Balancer en schakel de load balancer in. De optie Acceleration enabled stelt de load balancer in staat om sneller L4 load balancing in plaats van L7 te gebruiken.
- Ga naar het tabblad Applicatieprofiel om het applicatieprofiel in te stellen. Klik op +.
- Geef een naam op voor het profiel en kies het type verkeer waarvoor het profiel van toepassing zal zijn. Ik zal enkele parameters uitleggen.
Persistentie – slaat en volgt sessiegegevens op, bijvoorbeeld: welke specifieke server uit de pool de gebruikersverzoek afhandelt. Dit garandeert dat gebruikersverzoeken naar dezelfde member van de pool worden geleid gedurende de hele levensduur van de sessie of bij volgende sessies.
Enable SSL passthrough – door deze optie te kiezen, stopt NSX Edge met het beëindigen van SSL. In plaats daarvan vindt de beëindiging rechtstreeks op de servers plaats waarvoor de load balancing wordt uitgevoerd.
Insert X-Forwarded-For HTTP header – stelt in staat om het oorspronkelijke IP-adres van de client te identificeren die via de load balancer verbinding maakt met de webserver.
Enable Pool Side SSL – maakt het mogelijk aan te geven dat de gekozen pool uit HTTPS-servers bestaat.
- Aangezien ik HTTPS-verkeer ga balanceren, moet ik Pool Side SSL inschakelen en het eerder gegenereerde certificaat kiezen op het tabblad Virtuele Server Certificaten —> Service Certificate.
- Evenzo voor Pool Certificates —> Service Certificate.
We creëren een pool van servers waarvan het verkeer zal worden gebalanceerd Pools.
- Ga naar het tabblad Pools. Klik op +.
- Geef een naam aan de pool, kies een algoritme (ik zal round robin gebruiken) en het type monitoring voor de health check van de backend. De optie Transparent geeft aan of de oorspronkelijke source IP van clients zichtbaar zijn voor interne servers.
- Als de optie is uitgeschakeld, gaat het verkeer voor interne servers met het source IP van de load balancer.
- Als de optie is ingeschakeld, zien interne servers het source IP van de clients. In zo'n configuratie moet NSX Edge optreden als de standaardgateway om ervoor te zorgen dat de geretourneerde pakketten door NSX Edge gaan.
NSX ondersteunt de volgende load balancing-algoritmen:
- IP_HASH – selectie van de server op basis van de resultaten van de hashfunctie voor source en destination IP van elk pakket.
- LEASTCONN – belasting van inkomende verbindingen, afhankelijk van het aantal al bestaande verbindingen op een specifieke server. Nieuwe verbindingen worden naar de server met het minste aantal verbindingen gestuurd.
- ROUND_ROBIN – nieuwe verbindingen worden om de beurt naar elke server gestuurd, volgens het gewicht dat aan die server is toegewezen.
- URI – het linker gedeelte van de URI (voor de vraagteken) wordt gehasht en gedeeld door het totale gewicht van de servers in de pool. Het resultaat geeft aan welke server het verzoek ontvangt, waarbij wordt gegarandeerd dat het verzoek altijd naar dezelfde server wordt gestuurd, zolang alle servers beschikbaar blijven.
- HTTPHEADER – belasting 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 – in elk HTTP GET-verzoek wordt er gezocht naar de URL-parameter die als argument is opgegeven. Als er een gelijkteken en waarde volgen, wordt de waarde gehasht en gedeeld door het totale gewicht van de 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 te waarborgen dat dezelfde gebruikers-id altijd naar dezelfde server wordt gestuurd, zolang alle servers beschikbaar blijven.
- In het blok Members klikken we op + om servers aan de pool toe te voegen.
Hier moet worden opgegeven:- de naam van de server;
- het IP-adres van de server;
- de poort waarop de server verkeer zal ontvangen;
- de poort voor health check (Monitor healthcheck);
- gewicht (Weight) – met deze parameter kan de proportionele hoeveelheid ontvangen verkeer voor een specifiek lid van de pool worden gereguleerd;
- Max Connections – het maximale aantal verbindingen naar de server;
- Min Connections – het minimum aantal verbindingen dat de server moet verwerken voordat het verkeer naar het volgende lid van de pool kan worden doorgestuurd.
Dit is hoe de uiteindelijke pool van drie servers eruitziet.
Voeg een Virtual Server toe
- Ga naar het tabblad Virtual Servers. Klik op +.
- Schakel de virtuele server in met Enable Virtual Server.
We assign a name to it, select the previously created Application Profile, Pool, and specify the IP address to which the Virtual Server will accept external requests. We specify the HTTPS protocol and port 443.
Optional parameters here:
Connection Limit – maximum number of simultaneous connections that the virtual server can handle;
Connection Rate Limit (CPS) – maximum number of new incoming requests per second.
The configuration of the load balancer is now complete, and we can check its functionality. The servers have a simple configuration that allows us to understand which server from the pool processed the request. During configuration, we selected the Round Robin load balancing algorithm, and the weight parameter for each server is one, so each subsequent request will be processed by the next server from the pool.
We enter the external address of the load balancer in the browser and see:
After refreshing the page, the request will be handled by the next server:
And once more – to check the third server from the pool:
Upon checking, you can see that the certificate sent to us by Edge is the same one that we generated at the very beginning.
Checking the status of the load balancer from the Edge gateway console. For this, enter show service loadbalancer pool.
Configuring the Service Monitor to check the status of the servers in the pool
With the Service Monitor, we can track the status of the servers in the backend pool. If the response to the request does not match the expected one, the server can be removed from the pool to prevent it from receiving any new requests.
Three check methods are configured by default:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Let's create a new one.
- We go to the Service Monitoring tab and click +.
- We select:
- a name for the new method;
- an interval at which requests will be sent,
- a response timeout,
- monitoring type – HTTPS request using GET method, expected status code – 200(OK) and request URL.
- This concludes the setup of the new Service Monitor; now we can use it when creating a pool.
Configuring Application Rules
Application Rules are a way to manipulate traffic based on certain triggers. With this tool, we can create advanced load balancing rules that may not be possible to configure through Application profiles or other services available on the Edge Gateway.
- Om een regel aan te maken, gaan we naar het tabblad Toepassingsregels van de load balancer.
- We kiezen een naam, het script dat de regel zal gebruiken, en drukken op Behouden.
- Nadat de regel is aangemaakt, moeten we de al ingestelde Virtuele Server bewerken.
- In het tabblad Geavanceerd voegen we de door ons aangemaakte regel toe.
In het bovenstaande voorbeeld hebben we de ondersteuning voor tlsv1 ingeschakeld.
Nog een paar voorbeelden:
Verkeer omleiden naar een andere pool.
Met dit script kunnen we verkeer naar een andere load balancing pool omleiden als de primaire pool niet werkt. Om de regel te laten werken, moeten er meerdere pools op de load balancer zijn geconfigureerd en moeten alle leden van de primaire pool zich in de status down bevinden. We moeten de naam van de pool opgeven, niet de ID.
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 een externe website als alle leden van de primaire pool in de status down zijn.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Nog meer voorbeelden .
Dat was alles over de load balancer. Als je nog vragen hebt, vraag maar, ik ben er om te antwoorden.
Bron: habr.com
