Sidste gang talte vi om mulighederne ved NSX Edge i forhold til statisk og dynamisk routing, og i dag vil vi dykke ned i balanceringssystemet.
Før vi går i gang med konfigurationen, vil jeg kort minde om de grundlæggende typer af lastbalancering.
Teori
De fleste af nutidens løsninger til lastbalancering opdeles oftest i to kategorier: lastbalancering på fjerde (transport) og syvende (applikations) niveau af modellen. . OSI-modellen er ikke den bedste referencepunkt til at beskrive metoder til lastbalancering. For eksempel, hvis en L4-balancer også understøtter TLS-terminering, bliver det så i så fald en L7-balancer? Men sådan er det.
- L4-balancer repræsenterer oftest en mellemproxy, der står mellem klienten og et sæt tilgængelige backends, som terminerer TCP-forbindelser (det vil sige svarer selv på SYN), vælger en backend og initierer en ny TCP-session i retning af den, mens den selv sender SYN. Denne type er en af de grundlæggende, og der er også andre muligheder.
- L7-balancer fordeler trafikken til de tilgængelige backends 'mere sofistikeret' end L4-balanceren. Den kan træffe beslutninger om valg af backend baseret på for eksempel indholdet af HTTP-beskeden (URL-adresse, cookie osv.).
Uanset type kan balanceringssystemet understøtte følgende funktioner:
- Tjenesteopdagelse – processen med at identificere en samling af tilgængelige backends (Static, DNS, Consul, Etcd osv.).
- Sundhedstjek af de opdagede backends (aktiv 'ping' af backend ved hjælp af HTTP-anmodninger, passiv opdagelse af problemer i TCP-forbindelser, tilstedeværelsen af flere på hinanden følgende 503 HTTP-koder osv.).
- Selve lastbalanceringen (round robin, tilfældig udvælgelse, kilde-IP-hash, URI).
- TLS-terminering og certifikatverifikation.
- Sikkerhedsrelaterede muligheder (autentificering, forebyggelse af DoS-angreb, hastighedsbegrænsning) og meget mere.
NSX Edge tilbyder støtte til to driftsmåder for balanceringssystemet:
Proxy-tilstand, eller one-arm. I denne tilstand bruger NSX Edge sin egen IP-adresse som kildeadresse, når den sender en forespørgsel til en af backend-serverne. På denne måde fungerer load-balanceren samtidig som både Source og Destination NAT. Backend-serveren ser al trafik som sendt fra load-balanceren og svarer direkte til den. I en sådan opsætning skal load-balanceren være i samme netværkssegment som de interne servere.
Sådan foregår det:
1. Brugeren sender en forespørgsel til VIP-adressen (load-balancerens adresse), som er konfigureret på Edge.
2. Edge vælger en af backend-serverne og udfører destination NAT ved at erstatte VIP-adressen med adressen på den valgte backend.
3. Edge udfører source NAT ved at ændre brugerens oprindelige adresse til sin egen.
4. Pakken sendes til den valgte backend.
5. Backend-serveren svarer ikke direkte til brugeren, men til Edge, da brugerens oprindelige adresse blev ændret til load-balancerens adresse.
6. Edge sender serverens svar til brugeren.
Diagrammet nedenfor.
Transparent eller inline mode. I dette scenarie har load-balanceren interfaces i det interne og det eksterne netværk. Der er ingen direkte adgang til det interne netværk fra det eksterne. Den indbyggede load-balancer fungerer som en NAT-gateway for virtuelle maskiner i det interne netværk.
Mechanismen er følgende:
1. Brugeren sender en forespørgsel til VIP-adressen (load-balancerens adresse), som er konfigureret på Edge.
2. Edge vælger en af backend-serverne og udfører destination NAT ved at erstatte VIP-adressen med adressen på den valgte backend.
3. Pakken sendes til den valgte backend.
4. Backend modtager en forespørgsel med brugerens oprindelige adresse (source NAT er ikke udført) og svarer direkte til den.
5. Trafikken modtages igen af load-balanceren, da den i inline-opstillingen normalt fungerer som standardgateway for serverfarm.
6. Edge udfører source NAT for at sende trafikken til brugeren, ved at bruge sin VIP som kilde IP-adresse.
Diagrammet nedenfor.
Praktik
På min testboks er der konfigureret 3 servere med Apache, som er sat op til at fungere over HTTPS. Edge vil balancere HTTPS-forespørgsler ved hjælp af round robin-metoden, og proxye hver ny forespørgsel til en ny server.
Lad os komme i gang.
Generering af SSL-certifikat, som vil blive brugt af NSX Edge
Du kan importere et gyldigt CA-certifikat eller bruge et selvsigneret certifikat. I denne test vil jeg bruge et selvsigneret.
- I vCloud Director-grænsefladen går vi til Edge serviceindstillinger.
- Vi går til fanen Certifikater. Fra handlingslisten vælger vi at tilføje et nyt CSR.
- Udfyld de nødvendige felter og klik på Keep.
- Vælg den netop oprettede CSR, og vælg muligheden for selvsigneret CSR.
- Vælg gyldighedsperioden for certifikatet, og klik på Keep.
- Det selvsignerede certifikat er tilføjet til listen over tilgængelige.
Konfigurerer Application Profile.
Application profiles giver mere kontrol over netværkstrafik og gør det nemt og effektivt at administrere den. Med dem kan du definere adfærd for specifikke typer trafik.
- Gå til fanen Load Balancer, og aktiver belastningsbalanceren. Muligheden Acceleration enabled her tillader belastningsbalanceren at bruge hurtigere L4 belastning i stedet for L7.
- Gå til fanen Application profile for at indstille applikationsprofilen. Klik på +.
- Angiv navnet på profilen og vælg den type trafik, som profilen vil blive anvendt på. Jeg vil forklare nogle af parametrene.
Persistence – gemmer og sporer sessiondata, eksempelvis: hvilken specifik server fra puljen der betjener brugerens anmodning. Dette sikrer, at brugerens anmodninger sendes til den samme medlem af puljen i hele sessionens levetid eller påfølgende sessioner.
Enable SSL passthrough – ved at vælge denne mulighed stopper NSX Edge med at terminere SSL. I stedet foregår termineringen direkte på de servere, som der udføres belastningsbalancering for.
Insert X-Forwarded-For HTTP header – giver mulighed for at identificere klientens oprindelige IP-adresse, der opretter forbindelse til webserveren gennem belastningsbalanceren.
Enable Pool Side SSL – angiver, at den valgte pulje består af HTTPS-servere.
- Da jeg vil balancere HTTPS-trafik, skal jeg aktivere Pool Side SSL og vælge det tidligere genererede certifikat i fanen Virtual Server Certificates —> Service Certificate.
- Det samme gælder for Pool Certificates —> Service Certificate.
Opretter en serverpulje, hvis trafik skal balanceres
- Gå til fanen Pools. Klik på +.
- Angiv puljens navn, vælg algoritmen (jeg vil bruge round robin) og typen af overvågning til health check af backend. Muligheden Transparent angiver, om klienternes oprindelige source IP er synlig for interne servere.
- Hvis muligheden er deaktiveret, går trafikken til interne servere fra belastningsbalancerens source IP.
- Hvis muligheden er aktiveret, ser de interne servere klienternes source IP. I en sådan konfiguration skal NSX Edge fungere som standard gateway for at sikre, at de returnerede pakker passerer gennem NSX Edge.
NSX understøtter følgende load balancing-algoritmer:
- IP_HASH – valg af server baseret på resultaterne af hashing-funktionen for source og destination IP for hver pakke.
- LEASTCONN – belastning af indgående forbindelser, afhængig af antallet af eksisterende forbindelser på en bestemt server. Nye forbindelser vil blive sendt til serveren med det laveste antal forbindelser.
- ROUND_ROBIN – nye forbindelser sendes til hver server i rækkefølge, i overensstemmelse med den vægt, der er tildelt til dem.
- URI – den venstre del af URI'en (før spørgsmålstegnet) hashes og deles op i den samlede vægt af serverne i puljen. Resultatet angiver, hvilken server der modtager anmodningen, hvilket sikrer, at anmodningen altid sendes til den samme server, så længe alle servere er tilgængelige.
- HTTPHEADER – balancering baseret på en bestemt HTTP-header, som kan specificeres som parameter. Hvis headeren ikke er til stede eller ikke har nogen værdi, anvendes ROUND_ROBIN-algoritmen.
- URL – i hver HTTP GET-anmodning søges der efter parameteren i URL'en, som er angivet som argument. Hvis der efter parameteren følger et lighedstegn og en værdi, hashers værdien og deles op i den samlede vægt af de aktive servere. Resultatet angiver, hvilken server der modtager anmodningen. Denne proces bruges til at spore bruger-ID'er i anmodninger og sikrer, at det samme bruger-ID altid sendes til den samme server, så længe alle servere er tilgængelige.
- I afsnittet Medlemmer klikker vi på + for at tilføje servere til puljen.
Her skal angives:- servernavn;
- serverens IP-adresse;
- porten, som serveren vil modtage trafik på;
- port til health check (Monitor healthcheck);
- vægt (Weight) – med denne parameter kan du regulere den proportionale mængde trafik, der modtages af det specifikke medlem af puljen;
- Max Connections – det maksimale antal forbindelser til serveren;
- Min Connections – det minimale antal forbindelser, som serveren skal håndtere, før trafikken bliver omdirigeret til det næste medlem af puljen.
Sådan ser den endelige pulje ud med tre servere.
Vi tilføjer Virtuel Server
- Vi går til fanen Virtuelle Servere. Klik på +.
- Aktiver den virtuelle server ved at vælge Enable Virtual Server.
Vi giver den et navn, vælger det tidligere oprettede Application Profile, Pool og angiver IP-adressen, som Virtual Server vil modtage forespørgsler udefra på. Vi angiver protokollen HTTPS og port 443.
Valgfrie parametre er her:
Connection Limit – det maksimale antal samtidige forbindelser, som den virtuelle server kan håndtere;
Connection Rate Limit (CPS) – det maksimale antal nye indkommende forespørgsler pr. sekund.
Konfigurationen af load balancer er nu afsluttet, og vi kan teste dens funktion. Serverne har en simpel konfiguration, som gør det muligt at forstå, hvilken server fra puljen der håndterede forespørgslen. Under opsætningen valgte vi Round Robin balanceringsalgoritmen, og vægtparameteren for hver server er ens, således at hver efterfølgende forespørgsel vil blive behandlet af den næste server i puljen.
Indtast den eksterne adresse på load balancer i browseren, og vi ser:
Efter opdatering af siden vil forespørgslen blive behandlet af den næste server:
Og endnu en gang – for at teste den tredje server i puljen:
Under testen kan vi se, at certifikatet, som Edge sender os, er det samme, som vi genererede i starten.
Tjek status for load balancer fra Edge gateway-konsollen. For at gøre dette skal du indtaste show service loadbalancer pool.
Vi opsætter Service Monitor for at kontrollere tilstanden for serverne i puljen
Med Service Monitor kan vi overvåge tilstanden for serverne i backend-puljen. Hvis svaret på forespørgslen ikke svarer til det forventede, kan serveren fjernes fra puljen, så den ikke modtager nye forespørgsler.
Som standard er der konfigureret tre kontrolmetoder:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Lad os oprette en ny.
- Vi går til fanen Service Monitoring, klikker på +.
- Vi vælger:
- et navn til den nye metode;
- intervallet mellem forespørgslerne,
- timeout for at vente på svar,
- monitoreringstype – HTTPS-forespørgsel ved brug af GET-metoden, forventet statuskode – 200(OK) og URL for forespørgslen.
- Opsætningen af den nye Service Monitor er nu afsluttet, og vi kan bruge den, når vi opretter puljen.
Vi opsætter Application Rules
Application Rules er en metode til at manipulere trafik baseret på bestemte triggere. Med dette værktøj kan vi oprette avancerede load balancing-regler, hvis opsætning kan være umulig via Application profiles eller ved hjælp af andre tjenester, der er tilgængelige på Edge Gateway.
- For creating a rule, go to the Application Rules tab of the load balancer.
- Select the name, the script that will use the rule, and click Keep.
- After the rule is created, we need to edit the already configured Virtual Server.
- In the Advanced tab, we add the rule we created.
In the example above, we enabled support for tlsv1.
A couple more examples:
Redirecting traffic to another pool.
With this script, we can redirect traffic to another load balancing pool if the primary pool is not operational. For the rule to work, multiple pools must be configured on the load balancer, and all members of the primary pool must be in a down state. It is important to specify the name of the pool, not its ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Redirecting traffic to an external resource.
Here we redirect traffic to an external website if all members of the primary pool are in a down state.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Even more examples .
That's all I have about the load balancer. If you have any questions, feel free to ask; I'm here to help.
Kilde: habr.com
