Senast pratade vi om möjligheterna med NSX Edge när det gäller statisk och dynamisk routing, och idag ska vi titta närmare på lastbalanseraren.
Innan vi börjar med konfigurationen vill jag kort påminna om de grundläggande typerna av lastbalansering.
Teori
Dagens lastbalanseringslösningar delas oftast in i två kategorier: lastbalansering på fjärde (transport) och sjunde (applikations) nivån av modellen . OSI-modellen är inte den bästa referenspunkten för att beskriva metoder för lastbalansering. Om en L4-lastares också stödjer TLS-terminering, blir det då en L7-lastbalanserare? Men det är som det är.
- L4-lastbalanserare är oftast en mellanliggande proxy som står mellan klienten och en uppsättning tillgängliga backend, som terminerar TCP-anslutningar (det vill säga svarar på SYN själv), väljer en backend och initierar en ny TCP-session mot den, genom att själv skicka SYN. Denna typ är en av de grundläggande, andra varianter är också möjliga.
- L7-lastbalanserare fördelar trafiken mellan de tillgängliga backends "mer sofistikerat" än vad L4-lastbalanseraren gör. Det kan fatta beslut om val av backend baserat på, till exempel, innehållet i HTTP-meddelandet (URL, cookie etc.).
Oavsett typ kan en lastbalanserare stödja följande funktioner:
- Tjänstupptäckning – processen för att identifiera en uppsättning tillgängliga backends (Statisk, DNS, Consul, Etcd etc.).
- Hälsokontroll av upptäckta backends (aktiv "ping" av backend med en HTTP-förfrågan, passiv upptäckning av problem i TCP-anslutningar, mer än en följd av 503 HTTP-kod i svaren etc.).
- Själva lastbalanseringen (round robin, slumpmässigt val, käll-IP-hash, URI).
- TLS-terminering och certifikatverifiering.
- Säkerhetsrelaterade alternativ (autentisering, skydd mot DoS-attacker, hastighetsbegränsning) och mycket mer.
NSX Edge erbjuder stöd för två lägen för lastbalanserarens distribution:
Proxy-läge, eller one-arm. I det här läget använder NSX Edge sin egen IP-adress som källadress när det skickar en förfrågan till någon av backendarna. Så, lastbalanseraren utför samtidigt funktionerna för Source och Destination NAT. Backend ser all trafik som skickad från lastbalanseraren och svarar direkt på den. I ett sådant schema måste lastbalanseraren vara i samma nätverkssegment som de interna servrarna.
Så här går det till:
1. Användaren skickar en förfrågan till VIP-adressen (lastbalanserarens adress) som är konfigurerad på Edge.
2. Edge väljer en av backendarna och utför destination NAT genom att ersätta VIP-adressen med adressen till den valda backend.
3. Edge utför source NAT, vilket ersätter den ursprungliga användarens adress med sin egen.
4. Paketet skickas till den valda backend.
5. Backend svarar inte direkt till användaren, utan till Edge, eftersom den ursprungliga adressen för användaren har ändrats till lastbalanserarens adress.
6. Edge överför serverns svar till användaren.
Schema nedan.
Transparent eller inline-läge. I detta scenario har lastbalanseraren gränssnitt i både det interna och externa nätverket. Det finns ingen direkt åtkomst till det interna nätverket från utsidan. Den inbyggda lastbalanseraren fungerar som en NAT-gateway för virtuella maskiner i det interna nätverket.
Mechanismen är följande:
1. Användaren skickar en förfrågan till VIP-adressen (lastbalanserarens adress) som är konfigurerad på Edge.
2. Edge väljer en av backendarna och utför destination NAT genom att ersätta VIP-adressen med adressen till den valda backend.
3. Paketet skickas till den valda backend.
4. Backend tar emot förfrågan med den ursprungliga användarens adress (source NAT har inte utförts) och svarar direkt till den.
5. Trafiken tas åter emot av lastbalanseraren, eftersom den i inline-schemat vanligtvis fungerar som standardgateway för serverfarm.
6. Edge utför source NAT för att skicka trafiken till användaren, med sin VIP som käll-IP-adress.
Schema nedan.
Praxis
På min testmiljö har jag konfigurerat 3 servrar med Apache, som är inställt för att fungera via HTTPS. Edge kommer att balansera HTTPS-förfrågningar med round robin-metoden, genom att proxya varje ny förfrågan till en ny server.
Låt oss börja.
Generera ett SSL-certifikat som kommer att användas av NSX Edge.
Du kan importera ett giltigt CA-certifikat eller använda ett självsignerat. I detta test kommer jag att använda ett självsignerat.
- I gränssnittet för vCloud Director går vi till inställningarna för Edge-tjänster.
- Gå till fliken Certifikat. Välj att lägga till en ny CSR från åtgärdslistan.
- Fyll i de nödvändiga fälten och tryck på Keep.
- Markera den just skapade CSR:en och välj alternativet self-sign CSR.
- Välj giltighetstiden för certifikatet och tryck på Keep.
- Det självsignerade certifikatet har dykt upp i listan över tillgängliga.
Konfigurera Application Profile.
Application profiles ger mer fullständig kontroll över nätverkstrafiken och gör hanteringen enkel och effektiv. Med dem kan man definiera beteendet för specifika typer av trafik.
- Gå till fliken Load Balancer och aktivera lastbalanseraren. Alternativet Acceleration enabled här gör att lastbalanseraren kan använda snabbare L4-balans istället för L7.
- Gå till fliken Application profile för att ställa in applikationsprofilen. Tryck på +.
- Ange ett namn för profilen och välj typ av trafik som profilen ska tillämpas på. Jag förklarar några parametrar.
Persistence – sparar och spårar sessionsdata, till exempel: vilken specifik server i poolen som hanterar användarförfrågan. Detta gör att man kan garantera att användarens förfrågningar dirigeras till samma medlem i poolen under hela sessionens livstid eller följande sessioner.
Enable SSL passthrough – när detta alternativ väljs slutar NSX Edge att terminera SSL. Istället sker termineringen direkt på servrarna som lastbalanseras.
Insert X-Forwarded-For HTTP header – gör det möjligt att identifiera den ursprungliga IP-adressen för klienten som ansluter till webbservern via lastbalanseraren.
Enable Pool Side SSL – gör det möjligt att ange att den valda poolen består av HTTPS-servrar.
- Eftersom jag kommer att lastbalansera HTTPS-trafik behöver jag aktivera Pool Side SSL och välja det tidigare genererade certifikatet under fliken Virtual Server Certificates —> Service Certificate.
- Detsamma gäller för Pool Certificates —> Service Certificate.
Skapa en serverpool vars trafik kommer att lastbalanseras Pools.
- Gå till fliken Pools. Tryck på +.
- Ange namnet på poolen, välj algoritm (jag kommer att använda round robin) och typ av övervakning för health check av backend. Alternativet Transparent anger om de ursprungliga source IP:erna från klienterna är synliga för interna servrar.
- Om alternativet är avstängt går trafiken för interna servrar med source IP från lastbalanseraren.
- Om alternativet är aktivt ser interna servrar source IP:erna från klienterna. I en sådan konfiguration måste NSX Edge agera som standardgateway för att säkerställa att de returnerade paketen passerar genom NSX Edge.
NSX stöder följande lastbalanseringsalgoritmer:
- IP_HASH – val av server baserat på resultatet av hash-funktionen för käll- och destinations-IP för varje paket.
- LEASTCONN – lastbalansering av inkommande anslutningar beroende på antalet redan befintliga på en specifik server. Nya anslutningar kommer att dirigeras till den server med minst antal anslutningar.
- ROUND_ROBIN – nya anslutningar skickas till varje server i tur och ordning, i enlighet med den vikt som har tilldelats den.
- URI – vänster del av URI (innan frågetecknet) hashas och delas med den totala vikten av servrarna i poolen. Resultatet visar vilken server som får förfrågan, vilket garanterar att förfrågan alltid riktas till samma server, så länge alla servrar förblir tillgängliga.
- HTTPHEADER – lastbalansering baserat på en specifik HTTP-header som kan anges som parameter. Om headern saknas eller saknar värde tillämpas ROUND_ROBIN-algoritmen.
- URL – i varje HTTP GET-förfrågan görs en sökning på parameter-URL:n som anges som argument. Om det efter parametern följer ett lika med tecken och ett värde, så hash-mappars värdet och delas med den totala vikten av aktiva servrar. Resultatet visar vilken server som får förfrågan. Denna process används för att spåra användar-ID:n i förfrågningar och säkerställa att samma användar-ID alltid skickas till samma server, så länge alla servrar förblir tillgängliga.
- I avsnittet Medlemmar klickar vi på + för att lägga till servrar till poolen.
Här behöver du ange:- servernamn;
- serverns IP-adress;
- porten som servern kommer att ta emot trafik på;
- port för hälsokontroll (Monitor healthcheck);
- vikt (Weight) – genom denna parameter kan du justera den proportionella mängden trafik som tas emot av en specifik medlem i poolen;
- Max Connections – maximalt antal anslutningar till servern;
- Min Connections – minimalt antal anslutningar som servern måste hantera innan trafiken dirigeras till nästa medlem i poolen.
Så här ser den slutliga poolen av tre servrar ut.
Lägg till Virtuell Server
- Gå till fliken Virtuella Servrar. Klicka på +.
- Aktivera den virtuella servern med hjälp av Enable Virtual Server.
Vi anger ett namn, väljer en tidigare skapad Application Profile, Pool och anger IP-adressen som Virtual Server kommer att ta emot externa förfrågningar på. Vi anger protokollet HTTPS och port 443.
Valfria parametrar här:
Anslutningsgräns – det maximala antalet samtidiga anslutningar som den virtuella servern kan hantera;
Anslutningshastighetsgräns (CPS) – det maximala antalet nya inkommande förfrågningar per sekund.
Så här avslutas konfigurationen av lastbalanseraren, och vi kan kontrollera dess funktionalitet. Servrarna har en enklare konfiguration som gör det möjligt att förstå vilken server från poolen som hanterade förfrågan. Under inställningen valde vi balansmetoden Round Robin, och vikten för varje server är satt till ett, så varje nästa förfrågan kommer att hanteras av den följande servern i poolen.
Vi anger balancerarens externa adress i webbläsaren och ser:
Efter att ha uppdaterat sidan kommer förfrågan att hanteras av nästa server:
Och en gång till – för att kontrollera den tredje servern i poolen:
Vid kontrollen kan vi se att certifikatet som Edge skickar är det samma som vi genererade i början.
Kontroll av lastbalanserarens status från Edge-gatewayens konsol. För detta skriver vi in show service loadbalancer pool.
Vi konfigurerar Service Monitor för att kontrollera statusen på servrarna i poolen.
Genom Service Monitor kan vi övervaka statusen på servrarna i backend-poolen. Om svaret på förfrågan inte matchar det förväntade, kan servern tas bort från poolen så att den inte får några nya förfrågningar.
Som standard är tre metoder för kontroll konfigurerade:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Vi skapar en ny.
- Vi går till fliken Service Monitoring och klickar på +.
- Vi väljer:
- ett namn för den nya metoden;
- intervallet för hur ofta förfrågningar ska skickas,
- timeout för att vänta på svar,
- typ av övervakning – HTTPS-förfrågan med metod GET, förväntad statuskod – 200(OK) och URL för förfrågan.
- Nu är inställningen av den nya Service Monitor klar, och vi kan använda den vid skapandet av poolen.
Vi konfigurerar Application Rules.
Application Rules – ett sätt att manipulera trafiken baserat på specifika triggers. Med hjälp av detta verktyg kan vi skapa avancerade regler för lastbalansering, vars konfiguration kan vara omöjlig via Application profiles eller andra tjänster som är tillgängliga på Edge Gateway.
- För att skapa en regel går vi till fliken Application Rules för lastbalanseraren.
- Vi väljer namn, skriptet som kommer att använda regeln och klickar på Keep.
- Efter att regeln har skapats behöver vi redigera den redan inställda Virtual Server.
- I fliken Advanced lägger vi till regeln som vi har skapat.
I exemplet ovan har vi aktiverat stödet för tlsv1.
Ännu några exempel:
Omdirigera trafik till en annan pool.
Med detta skript kan vi omdirigera trafik till en annan lastbalanseringspool om den primära poolen inte fungerar. För att regeln ska fungera måste flera pooler vara konfigurerade på lastbalanseraren och alla medlemmar i den primära poolen måste vara nere. Det är viktigt att ange namnet på poolen, inte dess ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Omdirigera trafik till en extern resurs.
Här omdirigerar vi trafik till en extern webbplats om alla deltagare i den primära poolen är nere.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ännu fler exempel .
Det var allt om lastbalanseraren. Om det kvarstår frågor, fråga gärna, jag är redo att svara.
Källa: habr.com
