De vorige keer hebben we het gehad over de mogelijkheden van NSX Edge op het gebied van statische en dynamische routing. Vandaag gaan we het hebben over de balancer.
Voordat we met de installatie beginnen, wil ik u nog even kort de belangrijkste soorten balanceren uitleggen.
Теория
Alle huidige oplossingen voor payload balancing worden meestal onderverdeeld in twee categorieën: balancing op het vierde (transport) en zevende (applicatie) niveau van het model . Het OSI-model is niet het beste referentiepunt voor het beschrijven van methoden voor lastverdeling. Als een L4-load balancer bijvoorbeeld ook TLS-beëindiging ondersteunt, wordt het dan een L7-load balancer? Maar wat is, is.
- L4-balancer meestal is het een tussenproxy die tussen de client en de set 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, en onafhankelijk SYN verzendt. Dit type is een van de basistypen, er zijn ook andere opties mogelijk.
- L7-balancer verdeelt het verkeer "geavanceerder" over beschikbare backends dan de L4-balancer dat doet. Het kan op basis van bijvoorbeeld de inhoud van het HTTP-bericht (URL, cookie, enz.) beslissen welke backend gebruikt moet worden.
Ongeacht het type kan de balancer de volgende functies ondersteunen:
- Service discovery is het proces waarbij de set beschikbare backends wordt bepaald (Static, DNS, Consul, Etcd, etc.).
- Controleren van de functionaliteit van de gedetecteerde back-ends (actief pingen van de back-end met behulp van een HTTP-verzoek, passief detecteren van problemen in TCP-verbindingen, de aanwezigheid van meerdere 503 HTTP-codes achter elkaar in reacties, 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 meer.
NSX Edge biedt ondersteuning voor twee implementatiemodi voor load balancers:
Proxy-modus of één-arm. In deze modus gebruikt NSX Edge zijn IP-adres als bronadres bij het verzenden van een aanvraag naar een van de back-ends. De balancer voert dus zowel de bron- als de doel-NAT-functies tegelijkertijd uit. De backend ziet al het verkeer als verzonden vanaf de balancer en reageert hier 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 een 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 de aanvraag heeft verzonden door zijn eigen adres.
4. Het pakket wordt naar de geselecteerde backend verzonden.
5. De backend reageert niet rechtstreeks naar de gebruiker, maar naar de Edge, omdat het oorspronkelijke gebruikersadres is gewijzigd naar het balanceradres.
6. Edge geeft het antwoord van de server door aan de gebruiker.
Het diagram vindt u hieronder.
Transparante, of inline, modus. In dit scenario heeft de load balancer interfaces op het interne en externe netwerk. Er is echter geen directe toegang tot het interne netwerk vanuit het externe netwerk. De ingebouwde load balancer fungeert als NAT-gateway voor virtuele machines in 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 een 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 gebruikersadres (bron-NAT werd niet uitgevoerd) en reageert hier rechtstreeks op.
5. Het verkeer wordt opnieuw geaccepteerd door de load balancer, omdat deze in een inline-opstelling doorgaans fungeert als de standaardgateway voor de serverfarm.
6. Edge voert bron-NAT uit om verkeer naar de gebruiker te sturen met diens VIP als bron-IP-adres.
Het diagram vindt u hieronder.
Praktijk
Mijn testopstelling bestaat uit 3 servers die Apache draaien en geconfigureerd zijn om via HTTPS te werken. Edge voert een 'round robin balancing' uit van HTTPS-verzoeken, waarbij elk nieuw verzoek wordt doorgestuurd naar een nieuwe server.
Laten we beginnen.
Genereer een SSL-certificaat dat NSX Edge zal gebruiken
U kunt een geldig CA-certificaat importeren of een zelfondertekend certificaat gebruiken. In deze test maak ik gebruik van self-signed.
- Ga in de vCloud Director-interface naar de Edge-service-instellingen.
- Ga naar het tabblad Certificaten. Selecteer in de lijst met acties de optie om een nieuwe CSR toe te voegen.
- Vul de vereiste velden in en klik op Behouden.
- Selecteer de nieuw aangemaakte CSR en kies de optie CSR zelf ondertekenen.
- Selecteer de geldigheidsperiode van het certificaat en klik op Behouden
- Het zelfondertekende certificaat verscheen in de lijst met beschikbare certificaten.
Toepassingsprofiel instellen
Met toepassingsprofielen hebt u meer controle over uw netwerkverkeer en kunt u dit eenvoudig en efficiënt beheren. Ze kunnen worden gebruikt om het gedrag voor 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 de snellere L4-balancering gebruiken in plaats van L7.
- Ga naar het tabblad Toepassingsprofiel om het toepassingsprofiel in te stellen. Klik op +.
- We stellen de profielnaam in en selecteren het verkeerstype waarop het profiel wordt toegepast. Ik zal enkele parameters uitleggen.
Volharding – slaat sessiegegevens op en volgt deze, zoals welke specifieke server in de pool een gebruikersverzoek verwerkt. Hiermee wordt gegarandeerd dat gebruikersverzoeken tijdens de gehele sessie of daaropvolgende sessies naar hetzelfde poollid worden doorgestuurd.
SSL-passthrough inschakelen – Wanneer deze optie is geselecteerd, stopt NSX Edge met het beëindigen van SSL. In plaats daarvan vindt de beëindiging rechtstreeks plaats op de servers die in balans worden gebracht.
X-Forwarded-For HTTP-header invoegen – Hiermee kunt u het bron-IP-adres bepalen van de client die via de balancer verbinding maakt met de webserver.
SSL aan de poolzijde inschakelen – Hiermee kunt u opgeven dat de geselecteerde pool uit HTTPS-servers bestaat.
- Omdat ik HTTPS-verkeer ga balanceren, moet ik Pool Side SSL inschakelen en het eerder gegenereerde certificaat selecteren op het tabblad Virtuele servercertificaten —> tabblad Servicecertificaat.
- Hetzelfde geldt voor zwembadcertificaten —> servicecertificaat.
We creëren een pool van servers, waarvan het verkeer in evenwicht zal zijn.
- Ga naar het tabblad Pools. Druk op +.
- We stellen de poolnaam in, selecteren het algoritme (ik gebruik round robin) en het monitoringstype voor de health check-backend. Met de optie Transparant wordt opgegeven of het oorspronkelijke bron-IP-adres van clients zichtbaar is voor interne servers.
- Als de optie is uitgeschakeld, is het verkeer voor interne servers afkomstig van het bron-IP-adres van de balancer.
- Als deze optie is ingeschakeld, zien interne servers het bron-IP-adres van clients. In deze configuratie moet NSX Edge fungeren als standaardgateway om ervoor te zorgen dat retourpakketten via NSX Edge gaan.
NSX ondersteunt de volgende load balancing-algoritmen:
- IP_HASH – serverselectie op basis van de resultaten van de 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 specifieke server. Nieuwe verbindingen worden doorgestuurd naar de server met de minste verbindingen.
- ROUND_ROBIN – Nieuwe verbindingen worden op hun beurt naar elke server verzonden, overeenkomstig het daaraan toegekende gewicht.
- URI – het linkerdeel 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. Zo wordt het verzoek altijd naar dezelfde server gestuurd, zolang alle servers beschikbaar zijn.
- HTTP-HEADER – balanceren op basis van een specifieke HTTP-header die als parameter kan worden opgegeven. Als de header ontbreekt of geen betekenis heeft, wordt het ROUND_ROBIN-algoritme toegepast.
- URL – Elke HTTP GET-aanvraag voert een zoekopdracht uit op 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 de actieve servers. Het resultaat geeft aan welke server het verzoek ontvangt. Dit proces wordt gebruikt om gebruikers-ID's bij te houden bij verzoeken en ervoor te zorgen dat altijd dezelfde gebruikers-ID naar dezelfde server wordt verzonden, zolang alle servers beschikbaar blijven.
- Klik in het blok Leden op + om servers aan de pool toe te voegen.
Hier moet u aangeven:- servernaam;
- Server-IP-adres;
- de poort waarop de server verkeer ontvangt;
- poort voor gezondheidscontrole (Monitor gezondheidscontrole);
- gewicht – met deze parameter kunt u de proportionele hoeveelheid verkeer regelen die voor een specifiek poollid wordt ontvangen;
- Max. verbindingen – maximaal aantal verbindingen met de server;
- Minimumaantal verbindingen: het minimum aantal verbindingen dat een server moet kunnen verwerken voordat het verkeer wordt doorgestuurd naar het volgende lid van de pool.
Zo ziet de uiteindelijke pool van drie servers eruit.
Een virtuele server toevoegen
- Ga naar het tabblad Virtuele servers. Druk op +.
- Activeer de virtuele server met behulp van Virtuele server inschakelen.
We geven het een naam, selecteren het eerder aangemaakte toepassingsprofiel, de pool en specificeren het IP-adres 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 een virtuele server aankan;
Verbindingssnelheidslimiet (CPL) – het maximale aantal nieuwe inkomende verzoeken per seconde.
Nu is de balancerconfiguratie voltooid en kunt u de functionaliteit ervan controleren. De servers hebben een zeer eenvoudige configuratie waarmee u kunt zien welke server uit de pool het verzoek heeft verwerkt. Tijdens de installatie hebben we gekozen voor het Round Robin-balanceringsalgoritme. De Weight-parameter voor elke server is gelijk aan één. Hierdoor wordt elk volgend verzoek verwerkt door de volgende server uit de pool.
We voeren het externe adres van de balancer in de browser in en zien:
Nadat u de pagina heeft vernieuwd, wordt het verzoek verwerkt door de volgende server:
En nogmaals – om de derde server uit de pool te controleren:
Als u dit controleert, ziet u dat het certificaat dat Edge ons stuurt, hetzelfde is als het certificaat dat wij in het begin hebben gegenereerd.
De balancerstatus controleren vanaf de Edge Gateway-console. Om dit te doen, voer je in service loadbalancer pool weergeven.
Service Monitor configureren om de status van servers in de pool te controleren
Met Service Monitor kunnen we de status van servers in de backend pool controleren. Als de reactie op een verzoek niet aan de verwachtingen voldoet, kan de server uit de pool worden verwijderd, zodat deze geen nieuwe verzoeken meer ontvangt.
Standaard zijn er drie verificatiemethoden geconfigureerd:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Laten we er een nieuwe maken.
- Ga naar het tabblad Service Monitoring en klik op +.
- Kiezen:
- naam voor de nieuwe methode;
- het interval waarmee verzoeken worden verzonden,
- reactie-time-out,
- bewakingstype – 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 aanmaken van een pool.
Toepassingsregels instellen
Toepassingsregels – een manier om verkeer te manipuleren op basis van bepaalde triggers. Met deze tool kunnen we geavanceerde regels voor load balancing maken die mogelijk niet geconfigureerd kunnen worden via toepassingsprofielen of andere services die beschikbaar zijn op de Edge Gateway.
- Om een regel te maken, gaat u naar het tabblad Toepassingsregels van de balancer.
- Selecteer een naam, een script dat de regel zal gebruiken en klik op Behouden.
- Nadat de regel is gemaakt, moeten we de reeds geconfigureerde virtuele server bewerken.
- Op het tabblad Geavanceerd voegen we 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 load balancing pool als de hoofdpool niet beschikbaar is. Om de regel te laten werken, moet de balancer meerdere pools geconfigureerd hebben en moeten alle leden van de hoofdpool zich in de down-status bevinden. U moet 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 het verkeer om naar een 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
Meer voorbeelden .
Dat is alles wat ik over de balancer te zeggen heb. Als u vragen heeft, stel ze gerust. Ik beantwoord ze graag.
Bron: www.habr.com
