VMware NSX til de mindste. Del 5: Konfiguration af en Load Balancer

Del et. indledende
Del to. Konfiguration af firewall og NAT-regler
Del tre. Konfiguration af DHCP
Del fire. Routing opsætning

Sidste gang talte vi om mulighederne i NSX Edge med hensyn til statisk og dynamisk routing, og i dag vil vi beskæftige os med belastningsbalanceren.
Inden vi går i gang med opsætningen, vil jeg gerne kort minde dig om hovedtyperne af balancering.

Теория

Alle nutidens nyttelastbalanceringsløsninger er oftest opdelt i to kategorier: Balancering på fjerde (transport) og syvende (applikations) niveau af modellen ELLER HVIS. OSI-modellen er ikke det bedste referencepunkt, når man skal beskrive afbalanceringsmetoder. For eksempel, hvis en L4 balancer også understøtter TLS-terminering, bliver den så en L7 balancer? Men det er hvad det er.

• Balancer L4 oftest er det en mellemproxy, der står mellem klienten og et sæt af tilgængelige backends, som afslutter TCP-forbindelser (det vil sige uafhængigt reagerer på SYN), vælger en backend og starter en ny TCP-session i dens retning, og sender SYN uafhængigt. Denne type er en af ​​de grundlæggende; andre muligheder er mulige.
• Balancer L7 distribuerer trafik på tværs af tilgængelige backends "mere sofistikeret" end L4 balanceren gør. Den kan bestemme, hvilken backend der skal vælges baseret på for eksempel indholdet af HTTP-meddelelsen (URL, cookie osv.).

Uanset typen kan balanceren understøtte følgende funktioner:

• Tjenesteopdagelse er processen med at bestemme sættet af tilgængelige backends (Static, DNS, Consul, Etcd, etc.).
• Kontrol af funktionaliteten af ​​de opdagede backends (aktiv "ping" af backend ved hjælp af en HTTP-anmodning, passiv detektering af problemer i TCP-forbindelser, tilstedeværelsen af ​​flere 503 HTTP-koder i svarene osv.).
• Selve balanceringen (round robin, tilfældigt valg, kilde-IP-hash, URI).
• TLS-opsigelse og certifikatbekræftelse.
• Sikkerhedsrelaterede muligheder (godkendelse, forebyggelse af DoS-angreb, hastighedsbegrænsning) og meget mere.

NSX Edge tilbyder understøttelse af to load balancer-implementeringstilstande:

Proxy-tilstand eller en-arm. I denne tilstand bruger NSX Edge sin IP-adresse som kildeadresse, når den sender en anmodning til en af ​​backends. Således udfører balanceren samtidigt funktionerne Source og Destination NAT. Backend ser al trafik som sendt fra balanceren og reagerer direkte på den. I en sådan ordning skal balanceren være i samme netværkssegment med de interne servere.

Sådan går det:
1. Brugeren sender en anmodning til VIP-adressen (balanceradressen), der er konfigureret på Edge.
2. Edge vælger en af ​​backends og udfører destinations-NAT og erstatter VIP-adressen med adressen på den valgte backend.
3. Edge udfører kilde-NAT og erstatter adressen på den bruger, der sendte anmodningen, med sin egen.
4. Pakken sendes til den valgte backend.
5. Backend svarer ikke direkte til brugeren, men til Edge, da brugerens oprindelige adresse er blevet ændret til balancerens adresse.
6. Edge sender serverens svar til brugeren.
Diagrammet er nedenfor.


Transparent eller inline-tilstand. I dette scenarie har balanceren grænseflader på de interne og eksterne netværk. Samtidig er der ikke direkte adgang til det interne netværk fra det eksterne. Den indbyggede load balancer fungerer som en NAT-gateway for virtuelle maskiner på det interne netværk.

Mekanismen er som følger:
1. Brugeren sender en anmodning til VIP-adressen (balanceradressen), der er konfigureret på Edge.
2. Edge vælger en af ​​backends og udfører destinations-NAT og erstatter VIP-adressen med adressen på den valgte backend.
3. Pakken sendes til den valgte backend.
4. Backend modtager en anmodning med brugerens originale adresse (kilde NAT blev ikke udført) og svarer direkte på den.
5. Trafikken accepteres igen af ​​load balanceren, da den i et inline-skema normalt fungerer som standard-gatewayen for serverfarmen.
6. Edge udfører kilde-NAT for at sende trafik til brugeren ved at bruge sin VIP som kilde-IP-adresse.
Diagrammet er nedenfor.

Praksis

Min testbænk har 3 servere, der kører Apache, som er konfigureret til at arbejde over HTTPS. Edge vil udføre round robin-balancering af HTTPS-anmodninger, hvorved hver ny anmodning sendes til en ny server.
Lad os komme igang.

Generering af et SSL-certifikat, der vil blive brugt af NSX Edge
Du kan importere et gyldigt CA-certifikat eller bruge et selvsigneret. Til denne test vil jeg bruge selvsigneret.

1. Gå til Edge Services-indstillingerne i vCloud Director-grænsefladen.
   
2. Gå til fanen Certifikater. Vælg tilføjelse af en ny CSR fra listen over handlinger.
   
3. Udfyld de påkrævede felter, og klik på Behold.
   
4. Vælg den nyoprettede CSR og vælg muligheden for selvsignering af CSR.
   
5. Vælg gyldighedsperioden for certifikatet, og klik på Behold
   
6. Det selvsignerede certifikat vises på listen over tilgængelige.
   

Opsætning af applikationsprofil
Applikationsprofiler giver dig mere fuldstændig kontrol over netværkstrafikken og gør administrationen enkel og effektiv. De kan bruges til at definere adfærd for specifikke typer trafik.

1. Gå til fanen Load Balancer og aktiver balanceren. Den Accelerationsaktiverede mulighed her giver balanceren mulighed for at bruge hurtigere L4-balancering i stedet for L7.
   
2. Gå til fanen Applikationsprofil for at indstille applikationsprofilen. Klik på +.
   
3. Indstil navnet på profilen, og vælg den type trafik, som profilen skal anvendes til. Lad mig forklare nogle parametre.
   Vedholdenhed – gemmer og sporer sessionsdata, for eksempel: hvilken specifik server i puljen, der betjener brugeranmodningen. Dette sikrer, at brugeranmodninger sendes til det samme puljemedlem i hele sessionens levetid eller efterfølgende sessioner.
   Aktiver SSL-passthrough – Når denne indstilling er valgt, stopper NSX Edge med at afslutte SSL. I stedet sker opsigelsen direkte på de servere, der balanceres.
   Indsæt X-Forwarded-For HTTP header – giver dig mulighed for at bestemme kilde-IP-adressen på klienten, der forbinder til webserveren gennem belastningsbalanceren.
   Aktiver Pool Side SSL – giver dig mulighed for at angive, at den valgte pulje består af HTTPS-servere.
   
4. Da jeg vil afbalancere HTTPS-trafik, skal jeg aktivere Pool Side SSL og vælge det tidligere genererede certifikat på fanen Virtual Server Certificates -> Service Certificate.
   
5. Tilsvarende for Pool-certifikater -> Servicecertifikat.
   

Vi opretter en pulje af servere, hvortil trafikken vil være afbalanceret puljer

1. Gå til fanen Pools. Klik på +.
   
2. Vi indstiller navnet på puljen, vælger algoritmen (jeg vil bruge round robin) og typen af ​​overvågning for sundhedstjekkets backend. Indstillingen Transparent angiver, om klienternes oprindelige kilde-IP'er er synlige for interne servere.
   • Hvis indstillingen er deaktiveret, kommer trafik til interne servere fra balancerens kilde-IP.
   • Hvis indstillingen er aktiveret, ser interne servere klienternes kilde-IP. I denne konfiguration skal NSX Edge fungere som standardgateway for at sikre, at returnerede pakker passerer gennem NSX Edge.

   NSX understøtter følgende balanceringsalgoritmer:

   • IP_HASH – Servervalg baseret på resultaterne af en hash-funktion for hver pakkes kilde- og destinations-IP.
   • LEASTCONN – afbalancering af indgående forbindelser, afhængigt af antallet, der allerede er tilgængeligt på en bestemt server. Nye forbindelser vil blive dirigeret til serveren med færrest forbindelser.
   • RUNDE ROBIN – nye forbindelser sendes til hver server efter tur i overensstemmelse med den vægt, den er tildelt.
   • URI – venstre del af URI'en (før spørgsmålstegnet) hashes og divideres med den samlede vægt af servere i puljen. Resultatet angiver, hvilken server der modtager forespørgslen, hvilket sikrer, at anmodningen altid sendes til den samme server, så længe alle servere forbliver tilgængelige.
   • HTTPHEADER – balancering baseret på en specifik HTTP-header, som kan angives som en parameter. Hvis headeren mangler eller ikke har nogen værdi, anvendes ROUND_ROBIN-algoritmen.
   • URL – Hver HTTP GET-anmodning søger efter URL-parameteren angivet som et argument. Hvis parameteren efterfølges af et lighedstegn og en værdi, hashes værdien og divideres med den samlede vægt af kørende servere. Resultatet angiver, hvilken server der modtager anmodningen. Denne proces bruges til at holde styr på bruger-id'er i anmodninger og sikre, at det samme bruger-id altid sendes til den samme server, så længe alle servere forbliver tilgængelige.

   

3. Klik på + i blokken Medlemmer for at tilføje servere til puljen.
   
   
   Her skal du angive:
   • server navn;
   • Server IP-adresse;
   • den port, som serveren vil modtage trafik på;
   • port til sundhedstjek (Monitor sundhedstjek);
   • vægt – ved hjælp af denne parameter kan du justere den proportionale mængde trafik modtaget for et specifikt puljemedlem;
   • Max Connections – maksimalt antal forbindelser til serveren;
   • Min Connections – det mindste antal forbindelser, som serveren skal behandle, før trafikken videresendes til det næste poolmedlem.

   
   
   Sådan ser den endelige pulje på tre servere ud.
   

Tilføjelse af virtuel server

1. Gå til fanen Virtuelle servere. Klik på +.
   
2. Vi aktiverer den virtuelle server ved hjælp af Enable Virtual Server.
   Vi giver den et navn, vælger den tidligere oprettede applikationsprofil, pool og angiver den IP-adresse, som den virtuelle server vil modtage anmodninger udefra. Vi specificerer HTTPS-protokollen og port 443.
   Valgfrie parametre her:
   Forbindelsesgrænse – det maksimale antal samtidige forbindelser, som den virtuelle server kan behandle;
   Forbindelseshastighedsgrænse (CPS) – det maksimale antal nye indkommende anmodninger pr. sekund.
   

Dette fuldender konfigurationen af ​​balanceren; du kan kontrollere dens funktionalitet. Serverne har en simpel konfiguration, der giver dig mulighed for at forstå, hvilken server fra puljen, der behandlede anmodningen. Under opsætningen valgte vi Round Robin balanceringsalgoritmen, og vægtparameteren for hver server er lig med én, så hver efterfølgende anmodning vil blive behandlet af den næste server fra puljen.
Vi indtaster balancerens eksterne adresse i browseren og ser:


Efter opdatering af siden vil anmodningen blive behandlet af følgende server:


Og igen - for at tjekke den tredje server fra poolen:


Når du tjekker, kan du se, at det certifikat, som Edge sender os, er det samme, som vi genererede i begyndelsen.

Kontrol af balancerstatus fra Edge-gateway-konsollen. For at gøre dette skal du indtaste vis service loadbalancer pool.


Konfiguration af Service Monitor for at kontrollere status for servere i poolen
Ved hjælp af Service Monitor kan vi overvåge status på servere i backend-puljen. Hvis svaret på en anmodning ikke er som forventet, kan serveren tages ud af puljen, så den ikke modtager nye anmodninger.
Som standard er tre verifikationsmetoder konfigureret:

• TCP-monitor,
• HTTP skærm,
• HTTPS-monitor.

Lad os skabe en ny.

1. Gå til fanen Serviceovervågning, klik på +.
   
2. Vælge:
   • navn på den nye metode;
   • det interval, hvormed anmodninger sendes,
   • timeout venter på svar,
   • overvågningstype – HTTPS-anmodning ved hjælp af GET-metoden, forventet statuskode – 200(OK) og anmodnings-URL.
3. Dette fuldender opsætningen af ​​den nye Service Monitor; nu kan vi bruge den, når vi opretter en pulje.
   

Opsætning af applikationsregler

Applikationsregler er en måde at manipulere trafik baseret på bestemte triggere. Med dette værktøj kan vi oprette avancerede belastningsbalanceringsregler, som muligvis ikke er mulige gennem applikationsprofiler eller andre tjenester, der er tilgængelige på Edge Gateway.

1. For at oprette en regel skal du gå til fanen Anvendelsesregler i balanceren.
   
2. Vælg et navn, et script, der skal bruge reglen, og klik på Behold.
   
3. Efter at reglen er oprettet, skal vi redigere den allerede konfigurerede virtuelle server.
   
4. Tilføj den regel, vi har oprettet, på fanen Avanceret.
   

I eksemplet ovenfor aktiverede vi tlsv1-understøttelse.

Et par eksempler mere:

Omdiriger trafikken til en anden pool.
Med dette script kan vi omdirigere trafik til en anden balanceringspulje, hvis hovedpuljen er nede. For at reglen skal fungere, skal flere puljer konfigureres på balanceren, og alle medlemmer af hovedpuljen skal være i nede-tilstand. Du skal angive navnet på poolen, ikke dens ID.

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


Omdiriger trafik til en ekstern ressource.
Her omdirigerer vi trafik til den eksterne hjemmeside, hvis alle medlemmer af hovedpuljen er nede.

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

Endnu flere eksempler her.

Det er alt for mig om balanceren. Hvis du har spørgsmål, så spørg, jeg er klar til at svare.

Kilde: www.habr.com