Forrige gang snakket vi om egenskapene til NSX Edge når det gjelder statisk og dynamisk ruting, og i dag skal vi ta for oss lastbalanseren.
Før vi begynner å sette opp, vil jeg kort minne om hovedtypene av balansering.
Теория
Alle dagens nyttelastbalanseringsløsninger er oftest delt inn i to kategorier: balansering på fjerde (transport) og syvende (applikasjons) nivå av modellen . OSI-modellen er ikke det beste referansepunktet når man skal beskrive balanseringsmetoder. For eksempel, hvis en L4-balanser også støtter TLS-terminering, blir den da en L7-balanser? Men det er hva det er.
- Balanser L4 oftest er det en mellomproxy som står mellom klienten og et sett med tilgjengelige backends, som avslutter TCP-tilkoblinger (det vil si uavhengig reagerer på SYN), velger en backend og starter en ny TCP-sesjon i dens retning, og sender SYN uavhengig. Denne typen er en av de grunnleggende; andre alternativer er mulige.
- Balanser L7 distribuerer trafikk på tvers av tilgjengelige backends "mer sofistikert" enn L4-balansereren gjør. Den kan bestemme hvilken backend som skal velges basert på for eksempel innholdet i HTTP-meldingen (URL, informasjonskapsel osv.).
Uavhengig av type, kan balanseren støtte følgende funksjoner:
- Tjenesteoppdagelse er prosessen med å bestemme settet med tilgjengelige backends (Static, DNS, Consul, Etcd, etc.).
- Kontrollere funksjonaliteten til de oppdagede backends (aktiv "ping" av backend ved hjelp av en HTTP-forespørsel, passiv gjenkjenning av problemer i TCP-tilkoblinger, tilstedeværelsen av flere 503 HTTP-koder i svarene, etc.).
- Selve balanseringen (round robin, tilfeldig utvalg, kilde-IP-hash, URI).
- TLS-oppsigelse og sertifikatverifisering.
- Sikkerhetsrelaterte alternativer (autentisering, DoS-angrepsforebygging, hastighetsbegrensning) og mye mer.
NSX Edge tilbyr støtte for to distribusjonsmoduser for lastbalansering:
Proxy-modus, eller en-arm. I denne modusen bruker NSX Edge sin IP-adresse som kildeadresse når du sender en forespørsel til en av backends. Dermed utfører balanseren samtidig funksjonene til Kilde og Destinasjon NAT. Backend ser all trafikk som sendt fra balanseringsenheten og svarer direkte på den. I et slikt opplegg må balanseren være i samme nettverkssegment med de interne serverne.
Slik går det:
1. Brukeren sender en forespørsel til VIP-adressen (balanseringsadressen) som er konfigurert på Edge.
2. Edge velger en av backends og utfører destinasjons-NAT, og erstatter VIP-adressen med adressen til den valgte backend.
3. Edge utfører kilde-NAT, og erstatter adressen til brukeren som sendte forespørselen med sin egen.
4. Pakken sendes til valgt backend.
5. Backend svarer ikke direkte til brukeren, men til Edge, siden brukerens opprinnelige adresse har blitt endret til balanserens adresse.
6. Edge overfører serverens svar til brukeren.
Diagrammet er nedenfor.
Transparent eller innebygd modus. I dette scenariet har balanseren grensesnitt på de interne og eksterne nettverkene. Samtidig er det ingen direkte tilgang til det interne nettverket fra det eksterne. Den innebygde lastbalanseren fungerer som en NAT-gateway for virtuelle maskiner på det interne nettverket.
Mekanismen er som følger:
1. Brukeren sender en forespørsel til VIP-adressen (balanseringsadressen) som er konfigurert på Edge.
2. Edge velger en av backends og utfører destinasjons-NAT, og erstatter VIP-adressen med adressen til den valgte backend.
3. Pakken sendes til valgt backend.
4. Backend mottar en forespørsel med brukerens opprinnelige adresse (kilde NAT ble ikke utført) og svarer direkte på den.
5. Trafikken blir igjen akseptert av lastbalanseren, siden den i et inline-skjema vanligvis fungerer som standard gateway for serverfarmen.
6. Edge utfører kilde-NAT for å sende trafikk til brukeren, og bruker VIP-en som kilde-IP-adresse.
Diagrammet er nedenfor.
Praksis
Testbenken min har 3 servere som kjører Apache, som er konfigurert til å fungere over HTTPS. Edge vil utføre round robin-balansering av HTTPS-forespørsler, og sende hver ny forespørsel til en ny server.
La oss komme i gang.
Genererer et SSL-sertifikat som skal brukes av NSX Edge
Du kan importere et gyldig CA-sertifikat eller bruke et selvsignert. For denne testen vil jeg bruke selvsignert.
- I vCloud Director-grensesnittet går du til innstillingene for Edge-tjenester.
- Gå til Sertifikater-fanen. Velg å legge til en ny CSR fra listen over handlinger.
- Fyll ut de obligatoriske feltene og klikk på Behold.
- Velg den nyopprettede CSR-en og velg CSR-alternativet for selvsignering.
- Velg gyldighetsperioden for sertifikatet og klikk på Behold
- Det selvsignerte sertifikatet vises i listen over tilgjengelige.
Sette opp applikasjonsprofil
Applikasjonsprofiler gir deg mer fullstendig kontroll over nettverkstrafikk og gjør administrasjonen enkel og effektiv. De kan brukes til å definere atferd for spesifikke typer trafikk.
- Gå til fanen Load Balancer og aktiver balansereren. Det Acceleration-aktiverte alternativet her lar balanseren bruke raskere L4-balansering i stedet for L7.
- Gå til fanen Applikasjonsprofil for å angi applikasjonsprofilen. Klikk på +.
- Angi navnet på profilen og velg typen trafikk som profilen skal brukes for. La meg forklare noen parametere.
Utholdenhet – lagrer og sporer øktdata, for eksempel: hvilken spesifikk server i bassenget som betjener brukerforespørselen. Dette sikrer at brukerforespørsler blir rutet til det samme bassengmedlemmet i løpet av øktens levetid eller påfølgende økter.
Aktiver SSL-passthrough – Når dette alternativet er valgt, slutter NSX Edge å avslutte SSL. I stedet skjer avslutningen direkte på serverne som balanseres.
Sett inn X-Forwarded-For HTTP-header – lar deg bestemme kilde-IP-adressen til klienten som kobler til webserveren gjennom lastbalanseren.
Aktiver Pool Side SSL – lar deg spesifisere at det valgte bassenget består av HTTPS-servere.
- Siden jeg skal balansere HTTPS-trafikk, må jeg aktivere Pool Side SSL og velge det tidligere genererte sertifikatet i kategorien Virtual Server Certificates -> Service Certificate.
- Tilsvarende for Pool Certificates -> Service Certificate.
Vi oppretter en pool av servere, trafikken som vil bli balansert Pools
- Gå til fanen Bassenger. Klikk på +.
- Vi setter navnet på bassenget, velger algoritmen (jeg vil bruke round robin) og type overvåking for helsesjekkens backend. Alternativet Transparent indikerer om de opprinnelige kilde-IPene til klientene er synlige for interne servere.
- Hvis alternativet er deaktivert, kommer trafikk for interne servere fra kilde-IP-en til balanseren.
- Hvis alternativet er aktivert, ser interne servere kilde-IP-en til klientene. I denne konfigurasjonen må NSX Edge fungere som standard gateway for å sikre at returnerte pakker passerer gjennom NSX Edge.
NSX støtter følgende balanseringsalgoritmer:
- IP_HASH – servervalg basert på resultatene av en hash-funksjon for kilden og destinasjons-IP-en til hver pakke.
- LEASTCONN – balansering av innkommende tilkoblinger, avhengig av antallet som allerede er tilgjengelig på en bestemt server. Nye tilkoblinger vil bli dirigert til serveren med færrest tilkoblinger.
- ROUND_ROBIN – nye tilkoblinger sendes til hver server etter tur, i samsvar med vekten som er tildelt den.
- URI – venstre del av URI-en (før spørsmålstegnet) hashes og divideres med totalvekten av servere i bassenget. Resultatet indikerer hvilken server som mottar forespørselen, og sikrer at forespørselen alltid rutes til samme server, så lenge alle servere forblir tilgjengelige.
- HTTPHEADER – balansering basert på en spesifikk HTTP-header, som kan spesifiseres som en parameter. Hvis overskriften mangler eller ikke har noen verdi, brukes ROUND_ROBIN-algoritmen.
- URL – Hver HTTP GET-forespørsel søker etter URL-parameteren angitt som et argument. Hvis parameteren følges av et likhetstegn og en verdi, hashes verdien og divideres med totalvekten av kjørende servere. Resultatet indikerer hvilken server som mottar forespørselen. Denne prosessen brukes til å holde styr på bruker-ID-er i forespørsler og sikre at samme bruker-ID alltid sendes til samme server, så lenge alle servere forblir tilgjengelige.
- I Members-blokken klikker du på + for å legge til servere i bassenget.
Her må du spesifisere:- Server navn;
- Server IP-adresse;
- porten som serveren vil motta trafikk på;
- port for helsesjekk (Monitor helsesjekk);
- vekt – ved å bruke denne parameteren kan du justere den proporsjonale mengden trafikk mottatt for et spesifikt bassengmedlem;
- Maks tilkoblinger – maksimalt antall tilkoblinger til serveren;
- Minste tilkoblinger – minimum antall tilkoblinger som serveren må behandle før trafikk videresendes til neste gruppemedlem.
Slik ser den endelige puljen på tre servere ut.
Legger til virtuell server
- Gå til fanen Virtuelle servere. Klikk på +.
- Vi aktiverer den virtuelle serveren ved å bruke Aktiver virtuell server.
Vi gir den et navn, velger den tidligere opprettede applikasjonsprofilen, Pool og angir IP-adressen som den virtuelle serveren vil motta forespørsler til utenfra. Vi spesifiserer HTTPS-protokollen og port 443.
Valgfrie parametere her:
Tilkoblingsgrense – det maksimale antallet samtidige tilkoblinger som den virtuelle serveren kan behandle;
Tilkoblingshastighetsgrense (CPS) – maksimalt antall nye innkommende forespørsler per sekund.
Dette fullfører konfigurasjonen av balanseren; du kan sjekke funksjonaliteten. Serverne har en enkel konfigurasjon som lar deg forstå hvilken server fra bassenget som behandlet forespørselen. Under oppsettet valgte vi Round Robin-balanseringsalgoritmen, og vektparameteren for hver server er lik én, så hver påfølgende forespørsel vil bli behandlet av neste server fra bassenget.
Vi legger inn den eksterne adressen til balanseren i nettleseren og ser:
Etter å ha oppdatert siden, vil forespørselen bli behandlet av følgende server:
Og igjen - for å sjekke den tredje serveren fra bassenget:
Når du sjekker, kan du se at sertifikatet som Edge sender oss er det samme som vi genererte helt i begynnelsen.
Sjekker balanserstatus fra Edge-gateway-konsollen. For å gjøre dette, skriv inn vis service loadbalancer pool.
Konfigurere Service Monitor for å sjekke statusen til serverne i bassenget
Ved å bruke Service Monitor kan vi overvåke statusen til servere i backend-poolen. Hvis svaret på en forespørsel ikke er som forventet, kan serveren tas ut av bassenget slik at den ikke mottar nye forespørsler.
Som standard er tre verifiseringsmetoder konfigurert:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
La oss lage en ny.
- Gå til fanen Tjenesteovervåking, klikk på +.
- Velge:
- navn på den nye metoden;
- intervallet som forespørsler sendes med,
- tidsavbrudd venter på svar,
- overvåkingstype – HTTPS-forespørsel ved bruk av GET-metoden, forventet statuskode – 200(OK) og forespørsels-URL.
- Dette fullfører oppsettet av den nye Service Monitor; nå kan vi bruke den når vi oppretter en pool.
Sette opp applikasjonsregler
Applikasjonsregler er en måte å manipulere trafikk basert på visse utløsere. Med dette verktøyet kan vi lage avanserte lastbalanseringsregler som kanskje ikke er mulig gjennom applikasjonsprofiler eller andre tjenester tilgjengelig på Edge Gateway.
- For å opprette en regel, gå til kategorien Applikasjonsregler i balanseringsenheten.
- Velg et navn, et skript som skal bruke regelen, og klikk på Behold.
- Etter at regelen er opprettet, må vi redigere den allerede konfigurerte virtuelle serveren.
- I Avansert-fanen legger du til regelen vi opprettet.
I eksemplet ovenfor aktiverte vi tlsv1-støtte.
Et par eksempler til:
Omdiriger trafikk til et annet basseng.
Med dette skriptet kan vi omdirigere trafikk til en annen balansepool hvis hovedbassenget er nede. For at regelen skal fungere, må flere bassenger konfigureres på balanseringsenheten, og alle medlemmene av hovedbassenget må være i nede tilstand. Du må spesifisere navnet på bassenget, ikke dets ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Omdiriger trafikk til en ekstern ressurs.
Her omdirigerer vi trafikk til den eksterne nettsiden dersom alle medlemmer av hovedbassenget er nede.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Enda flere eksempler .
Det er alt for meg om balanseren. Hvis du har spørsmål, spør, jeg er klar til å svare.
Kilde: www.habr.com