Förra gången pratade vi om funktionerna hos NSX Edge när det gäller statisk och dynamisk routing, och idag ska vi ta itu med lastbalanseraren.
Innan vi börjar sätta upp vill jag kort påminna dig om huvudtyperna av balansering.
Теория
Alla dagens nyttolastbalanseringslösningar är oftast indelade i två kategorier: balansering på modellens fjärde (transport) och sjunde (applikations)nivå. . OSI-modellen är inte den bästa referenspunkten när man beskriver balanseringsmetoder. Till exempel, om en L4-balanserare också stöder TLS-terminering, blir den då en L7-balanserare? Men det är vad det är.
- Balanser L4 oftast är det en mellanproxy som står mellan klienten och en uppsättning tillgängliga backends, som avslutar TCP-anslutningar (det vill säga oberoende svarar på SYN), väljer en backend och initierar en ny TCP-session i dess riktning, och sänder SYN oberoende. Denna typ är en av de grundläggande, andra alternativ är möjliga.
- Balanser L7 distribuerar trafik över tillgängliga backends "mer sofistikerad" än L4 balancer gör. Den kan bestämma vilken backend som ska väljas baserat på till exempel innehållet i HTTP-meddelandet (URL, cookie, etc.).
Oavsett typ kan balanseraren stödja följande funktioner:
- Tjänsteupptäckt är processen för att fastställa uppsättningen av tillgängliga backends (Static, DNS, Consul, Etcd, etc.).
- Kontrollera funktionaliteten hos de upptäckta backends (aktiv "ping" av backend med en HTTP-begäran, passiv upptäckt av problem i TCP-anslutningar, närvaron av flera 503 HTTP-koder i svaren, etc.).
- Själva balanseringen (round robin, slumpmässigt urval, käll-IP-hash, URI).
- TLS uppsägning och certifikatverifiering.
- Säkerhetsrelaterade alternativ (autentisering, DoS-attackförebyggande, hastighetsbegränsning) och mycket mer.
NSX Edge erbjuder stöd för två distributionslägen för lastbalanserare:
Proxyläge, eller enarm. I det här läget använder NSX Edge sin IP-adress som källadress när en förfrågan skickas till en av backenderna. Således utför balanseraren samtidigt funktionerna för källa och destinations-NAT. Backend ser all trafik som skickad från balancern och svarar direkt på den. I ett sådant schema måste balanseringsenheten vara i samma nätverkssegment med de interna servrarna.
Så här går det till:
1. Användaren skickar en begäran till VIP-adressen (balanseringsadress) som är konfigurerad på Edge.
2. Edge väljer en av backenderna och utför destinations-NAT, och ersätter VIP-adressen med adressen till den valda backend.
3. Edge utför käll-NAT och ersätter adressen till användaren som skickade begäran med sin egen.
4. Paketet skickas till den valda backend.
5. Backend svarar inte direkt till användaren, utan till Edge, eftersom användarens ursprungliga adress har ändrats till balanserarens adress.
6. Edge sänder serverns svar till användaren.
Diagrammet är nedan.
Transparent, eller inline, läge. I detta scenario har balanseraren gränssnitt på de interna och externa nätverken. Samtidigt finns det ingen direkt åtkomst till det interna nätverket från det externa. Den inbyggda lastbalanseraren fungerar som en NAT-gateway för virtuella maskiner på det interna nätverket.
Mekanismen är som följer:
1. Användaren skickar en begäran till VIP-adressen (balanseringsadress) som är konfigurerad på Edge.
2. Edge väljer en av backenderna och utför destinations-NAT, och ersätter VIP-adressen med adressen till den valda backend.
3. Paketet skickas till den valda backend.
4. Backend tar emot en förfrågan med användarens ursprungliga adress (källa NAT utfördes inte) och svarar direkt på den.
5. Trafiken accepteras återigen av lastbalanseraren, eftersom den i ett inline-schema vanligtvis fungerar som standardgateway för serverfarmen.
6. Edge utför käll-NAT för att skicka trafik till användaren och använder dess VIP som käll-IP-adress.
Diagrammet är nedan.
Praxis
Min testbänk har 3 servrar som kör Apache, som är konfigurerad att fungera över HTTPS. Edge kommer att utföra round robin-balansering av HTTPS-förfrågningar, och proxyserverar varje ny begäran till en ny server.
Låt oss börja.
Genererar ett SSL-certifikat som kommer att användas av NSX Edge
Du kan importera ett giltigt CA-certifikat eller använda ett självsignerat. För detta test kommer jag att använda självsignerad.
- Gå till inställningarna för Edge-tjänster i vCloud Director-gränssnittet.
- Gå till fliken Certifikat. Välj att lägga till en ny CSR i listan över åtgärder.
- Fyll i de obligatoriska fälten och klicka på Behåll.
- Välj den nyskapade CSR och välj alternativet självsignering CSR.
- Välj giltighetstiden för certifikatet och klicka på Behåll
- Det självsignerade certifikatet visas i listan över tillgängliga.
Konfigurera applikationsprofil
Applikationsprofiler ger dig mer fullständig kontroll över nätverkstrafiken och gör hanteringen enkel och effektiv. De kan användas för att definiera beteenden för specifika typer av trafik.
- Gå till fliken Load Balancer och aktivera balanseraren. Alternativet Acceleration aktiverat här tillåter balanseraren att använda snabbare L4-balansering istället för L7.
- Gå till fliken Applikationsprofil för att ställa in applikationsprofilen. Klicka på +.
- Ställ in namnet på profilen och välj vilken typ av trafik som profilen ska tillämpas för. Låt mig förklara några parametrar.
Persistens – lagrar och spårar sessionsdata, till exempel: vilken specifik server i poolen som servar användarförfrågan. Detta säkerställer att användarförfrågningar dirigeras till samma poolmedlem under hela sessionen eller efterföljande sessioner.
Aktivera SSL-passthrough – När det här alternativet är valt, slutar NSX Edge att avsluta SSL. Istället sker uppsägning direkt på de servrar som balanseras.
Infoga X-Forwarded-For HTTP header – låter dig bestämma källans IP-adress för klienten som ansluter till webbservern via lastbalanseraren.
Aktivera Pool Side SSL – låter dig ange att den valda poolen består av HTTPS-servrar.
- Eftersom jag kommer att balansera HTTPS-trafik måste jag aktivera Pool Side SSL och välja det tidigare genererade certifikatet på fliken Virtual Server Certificates -> Service Certificate.
- Likadant för Poolcertifikat -> Servicecertifikat.
Vi skapar en pool av servrar, vars trafik kommer att balanseras i pooler
- Gå till fliken Pooler. Klicka på +.
- Vi ställer in namnet på poolen, väljer algoritmen (jag kommer att använda round robin) och typen av övervakning för hälsokontrollens backend. Alternativet Transparent indikerar om klienternas initiala käll-IP:er är synliga för interna servrar.
- Om alternativet är inaktiverat kommer trafik för interna servrar från käll-IP:n för balanseraren.
- Om alternativet är aktiverat ser interna servrar klienternas käll-IP. I den här konfigurationen måste NSX Edge fungera som standardgateway för att säkerställa att returnerade paket passerar genom NSX Edge.
NSX stöder följande balanseringsalgoritmer:
- IP_HASH – Serverval baserat på resultaten av en hash-funktion för käll- och destinations-IP för varje paket.
- LEASTCONN – balansering av inkommande anslutningar, beroende på antalet redan tillgängliga på en viss server. Nya anslutningar kommer att dirigeras till servern med minst anslutningar.
- ROUND_ROBIN – nya anslutningar skickas till varje server i tur och ordning, i enlighet med den vikt som den tilldelas.
- URI – den vänstra delen av URI:n (före frågetecknet) hashas och divideras med den totala vikten av servrarna i poolen. Resultatet indikerar vilken server som tar emot förfrågan, vilket säkerställer att förfrågan alltid dirigeras till samma server, så länge alla servrar är tillgängliga.
- HTTPHEADER – balansering baserad på en specifik HTTP-header, som kan anges som en parameter. Om rubriken saknas eller inte har något värde, tillämpas ROUND_ROBIN-algoritmen.
- URL – Varje HTTP GET-begäran söker efter URL-parametern som anges som ett argument. Om parametern följs av ett likhetstecken och ett värde, hashas värdet och divideras med den totala vikten av körande servrar. Resultatet indikerar vilken server som tar emot begäran. Denna process används för att hålla reda på användar-ID i förfrågningar och säkerställa att samma användar-ID alltid skickas till samma server, så länge alla servrar är tillgängliga.
- I Members-blocket klickar du på + för att lägga till servrar till poolen.
Här måste du specificera:- server namn;
- Server IP adress;
- porten på vilken servern kommer att ta emot trafik;
- port för hälsokontroll (Monitor healthcheck);
- vikt – med denna parameter kan du justera den proportionella mängden trafik som tas emot för en specifik poolmedlem;
- Max anslutningar – maximalt antal anslutningar till servern;
- Minsta anslutningar – det minsta antal anslutningar som servern måste bearbeta innan trafik vidarebefordras till nästa poolmedlem.
Så här ser den sista poolen med tre servrar ut.
Lägger till virtuell server
- Gå till fliken Virtuella servrar. Klicka på +.
- Vi aktiverar den virtuella servern med Aktivera virtuell server.
Vi ger den ett namn, väljer den tidigare skapade applikationsprofilen, pool och anger IP-adressen till vilken den virtuella servern kommer att ta emot förfrågningar utifrån. Vi anger HTTPS-protokollet och port 443.
Valfria parametrar här:
Anslutningsgräns – det maximala antalet samtidiga anslutningar som den virtuella servern kan bearbeta;
Anslutningshastighetsgräns (CPS) – det maximala antalet nya inkommande förfrågningar per sekund.
Detta slutför konfigurationen av balanseraren, du kan kontrollera dess funktionalitet. Servrarna har en enkel konfiguration som låter dig förstå vilken server från poolen som behandlade begäran. Under installationen valde vi balanseringsalgoritmen Round Robin, och viktparametern för varje server är lika med en, så varje efterföljande begäran kommer att behandlas av nästa server från poolen.
Vi anger balanserarens externa adress i webbläsaren och ser:
Efter att sidan har uppdaterats kommer begäran att behandlas av följande server:
Och igen - för att kontrollera den tredje servern från poolen:
När du kontrollerar kan du se att certifikatet som Edge skickar till oss är detsamma som vi genererade i början.
Kontrollera balanseringsstatus från Edge gateway-konsolen. För att göra detta, skriv in visa service loadbalancer pool.
Konfigurera Service Monitor för att kontrollera statusen för servrarna i poolen
Med Service Monitor kan vi övervaka statusen för servrar i backend-poolen. Om svaret på en förfrågan inte är som förväntat kan servern tas ur poolen så att den inte får några nya förfrågningar.
Som standard är tre verifieringsmetoder konfigurerade:
- TCP-monitor,
- HTTP-övervakning,
- HTTPS-monitor.
Låt oss skapa en ny.
- Gå till fliken Serviceövervakning, klicka på +.
- Välja:
- namn på den nya metoden;
- intervallet med vilket förfrågningar kommer att skickas,
- timeout väntar på svar,
- övervakningstyp – HTTPS-begäran med GET-metoden, förväntad statuskod – 200(OK) och begäran-URL.
- Detta slutför installationen av den nya Service Monitor; nu kan vi använda den när vi skapar en pool.
Ställa in applikationsregler
Programregler är ett sätt att manipulera trafik baserat på vissa utlösare. Med det här verktyget kan vi skapa avancerade lastbalanseringsregler som kanske inte är möjliga genom applikationsprofiler eller andra tjänster tillgängliga på Edge Gateway.
- För att skapa en regel, gå till fliken Tillämpningsregler i balansören.
- Välj ett namn, ett skript som ska använda regeln och klicka på Behåll.
- Efter att regeln har skapats måste vi redigera den redan konfigurerade virtuella servern.
- Lägg till regeln vi skapade på fliken Avancerat.
I exemplet ovan aktiverade vi tlsv1-stöd.
Ett par exempel till:
Omdirigera trafik till en annan pool.
Med det här skriptet kan vi omdirigera trafik till en annan balanseringspool om huvudpoolen är nere. För att regeln ska fungera måste flera pooler konfigureras på balanseringsenheten och alla medlemmar i huvudpoolen måste vara i nedläge. Du måste 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 den externa webbplatsen om alla medlemmar i huvudpoolen är nere.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ännu fler exempel .
Det är allt för mig om balanseraren. Om du har några frågor, fråga, jag är redo att svara.
Källa: will.com