VMware NSX per i più picculi. Part 5: Configurazione di un Load Balancer

Prima parte. introduttu
A seconda parte. Configurazione di Firewall è regule NAT
Terza parte. Configurazione di DHCP
Quattru parte. Configurazione di u routing

L'ultima volta avemu parlatu di e capacità di NSX Edge in quantu à u routing staticu è dinamicu, è oghje avemu da trattà cù u balancer di carica.
Prima di principià a stallazione, vogliu ricurdà brevemente i principali tipi di equilibriu.

Teoria

Tutte e soluzioni di bilanciamentu di carichi d'oghje sò più spessu divisu in duie categurie: equilibriu à u quartu (trasportu) è u settimu (applicazione) livelli di u mudellu. O SI. U mudellu OSI ùn hè micca u megliu puntu di riferimentu quandu descrive i metudi di equilibriu. Per esempiu, se un equilibratore L4 sustene ancu a terminazione TLS, diventerà allora un equilibratore L7? Ma hè ciò chì hè.

• Balancer L4 u più spessu hè un proxy mediu chì si trova trà u cliente è un settore di backends dispunibili, chì finisce e cunnessione TCP (vale à dì, risponde indipindentamente à SYN), selezziunate un backend è inizia una nova sessione TCP in a so direzzione, mandendu indipindente SYN. Stu tipu hè unu di i basi; altre opzioni sò pussibuli.
• Balancer L7 distribuisce u trafficu à traversu backend dispunibuli "più sufisticati" cà u balancer L4. Pò decide quale backend sceglite basatu, per esempiu, u cuntenutu di u missaghju HTTP (URL, cookie, etc.).

Indipendentemente da u tipu, u balancer pò sustene e seguenti funzioni:

• A scuperta di u serviziu hè u prucessu di determinà u settore di backends dispunibili (Static, DNS, Consul, Etcd, etc.).
• Verificate a funziunalità di i backends rilevati ("ping" attivu di u backend utilizendu una dumanda HTTP, rilevazione passiva di prublemi in cunnessione TCP, a presenza di parechji codici HTTP 503 in i risposti, etc.).
• L'equilibriu stessu (round robin, selezzione aleatoria, hash IP source, URI).
• Terminazione TLS è verificazione di certificatu.
• Opzioni di sicurità (autentificazione, prevenzione di attacchi DoS, limitazione di velocità) è assai di più.

NSX Edge offre supportu per dui modi di implementazione di bilanciatore di carica:

Modu proxy, o un bracciu. In questu modu, NSX Edge usa u so indirizzu IP cum'è l'indirizzu fonte quandu invià una dumanda à unu di i backends. Cusì, u balancer simultaneamente eseguisce e funzioni di Source è Destination NAT. U backend vede tuttu u trafficu cum'è mandatu da u balancer è risponde direttamente à questu. In un tali schema, u balancer deve esse in u stessu segmentu di a reta cù i servitori internu.

Eccu cumu si passa:
1. L'utilizatore manda una dumanda à l'indirizzu VIP (indirizzu di equilibriu) chì hè cunfiguratu nantu à u Edge.
2. Edge selezziunate unu di i backends è eseguisce destinazione NAT, rimpiazzà l'indirizzu VIP cù l'indirizzu di u backend sceltu.
3. Edge realiza a fonte NAT, rimpiazzà l'indirizzu di l'utilizatore chì hà mandatu a dumanda cù u so propiu.
4. U pacchettu hè mandatu à u backend sceltu.
5. U backend ùn risponde micca direttamente à l'utilizatore, ma à l'Edge, postu chì l'indirizzu originale di l'utilizatore hè statu cambiatu à l'indirizzu di u balancer.
6. Edge trasmette a risposta di u servitore à l'utilizatore.
U schema hè quì sottu.


Modu trasparente, o in linea. In questu scenariu, u balancer hà interfacce nantu à e rete internu è esternu. À u listessu tempu, ùn ci hè micca accessu direttu à a reta interna da l'esterno. L'equilibriu di carica integratu agisce cum'è una porta NAT per e macchine virtuali in a reta interna.

U mecanismu hè u siguenti:
1. L'utilizatore manda una dumanda à l'indirizzu VIP (indirizzu di equilibriu) chì hè cunfiguratu nantu à u Edge.
2. Edge selezziunate unu di i backends è eseguisce destinazione NAT, rimpiazzà l'indirizzu VIP cù l'indirizzu di u backend sceltu.
3. U pacchettu hè mandatu à u backend sceltu.
4. U backend riceve una dumanda cù l'indirizzu uriginale di l'utilizatore (la fonte NAT ùn hè micca stata realizata) è risponde direttamente à questu.
5. U trafficu hè di novu accettatu da u balancer di carica, postu chì in un schema inline generalmente agisce cum'è a porta predeterminata per a splutazioni di u servitore.
6. Edge realiza a fonte NAT per mandà u trafficu à l'utilizatore, utilizendu u so VIP cum'è l'indirizzu IP fonte.
U schema hè quì sottu.

Prutizzioni

U mo bancu di teste hà 3 servitori chì correnu Apache, chì hè cunfiguratu per travaglià nantu à HTTPS. Edge eseguirà un equilibru round robin di e richieste HTTPS, proxy ogni nova dumanda à un novu servitore.
Cuminciamu.

Generazione di un certificatu SSL chì serà utilizatu da NSX Edge
Pudete impurtà un certificatu CA validu o aduprà un autofirmatu. Per sta prova, aghju aduprà l'autofirmatu.

1. In l'interfaccia di vCloud Director, andate à i paràmetri di i servizii Edge.
   
2. Andà à a tabulazione Certificati. Da a lista di l'azzioni, selezziunate aghjunghje una nova CSR.
   
3. Inserite i campi richiesti è cliccate Mantene.
   
4. Selezziunate a nova CSR creata è selezziunate l'opzione CSR autofirmata.
   
5. Selezziunate u periodu di validità di u certificatu è cliccate Mantene
   
6. U certificatu autofirmatu appare in a lista di quelli dispunibili.
   

Configurazione di u Profilu di l'Applicazione
I profili di l'applicazione vi danu un cuntrollu più cumpletu nantu à u trafficu di a rete è facenu a gestione simplice è efficace. Puderanu esse usatu per definisce u cumpurtamentu per i tipi specifichi di trafficu.

1. Andate à a tabulazione Load Balancer è attivate u balancer. L'opzione Accelerazione attivata quì permette à l'equilibratore di utilizà un equilibriu L4 più veloce invece di L7.
   
2. Andà à a tabulazione di u prufilu di l'applicazione per stabilisce u prufilu di l'applicazione. Cliccate +.
   
3. Definite u nome di u prufilu è selezziunate u tipu di trafficu per quale u prufilu serà applicatu. Lasciami spiegà certi paràmetri.
   Persistenza - almacena è traccia i dati di sessione, per esempiu: quale servitore specificu in a piscina serve a dumanda di l'utilizatori. Questu assicura chì e richieste di l'utilizatori sò dirette à u stessu membru di u pool per a vita di a sessione o sessioni successive.
   Attivà u passthrough SSL - Quandu sta opzione hè selezziunata, NSX Edge ferma a terminazione di SSL. Invece, a terminazione si trova direttamente nantu à i servitori chì sò equilibrati.
   Inserite l'intestazione HTTP X-Forwarded-For - permette di determinà l'indirizzu IP fonte di u cliente chì si cunnetta à u servitore web per mezu di l'equilibriu di carica.
   Abilita SSL Pool Side - permette di specificà chì a piscina scelta hè custituita da servitori HTTPS.
   
4. Siccomu equilibraraghju u trafficu HTTPS, aghju bisognu di attivà Pool Side SSL è selezziunate u certificatu generatu prima in a tabulazione Certificati di Server Virtual -> Certificatu di serviziu.
   
5. In listessu modu per i Certificati Pool -> Certificatu di serviziu.
   

Avemu crià una piscina di servori, u trafficu à quale sarà equilibratu Pools

1. Andà à a tabulazione Piscine. Cliccate +.
   
2. Avemu stabilitu u nome di a piscina, selezziunà l'algoritmu (aghju da aduprà round robin) è u tipu di surviglianza per u backend di cuntrollu di salute L'opzione Trasparente indica se l'IP di fonti iniziali di i clienti sò visibili à i servitori interni.
   • Se l'opzione hè disattivata, u trafficu per i servitori internu vene da l'IP fonte di u balancer.
   • Se l'opzione hè attivata, i servitori interni vedenu l'IP fonte di i clienti. In questa cunfigurazione, NSX Edge deve agisce cum'è a porta predeterminata per assicurà chì i pacchetti restituiti passanu per NSX Edge.

   NSX supporta i seguenti algoritmi di equilibriu:

   • IP_HASH - Selezzione di u servitore basatu nantu à i risultati di una funzione di hash per l'IP fonte è destinazione di ogni pacchettu.
   • LEASTCONN - equilibriu di cunnessione in entrata, secondu u numeru digià dispunibule nantu à un servitore particulari. I novi cunnessione seranu diretti à u servitore cù u menu di cunnessione.
   • ROUND_ROBIN - novi cunnessione sò mandati à ogni servitore à turnu, in cunfurmità cù u pesu attribuitu.
   • URI - a parte manca di l'URI (prima di u puntu d'interrogazione) hè hashed è divisu da u pesu tutale di i servitori in a piscina. U risultatu indica quale servore riceve a dumanda, assicurendu chì a dumanda hè sempre diretta à u stessu servitore, sempre chì tutti i servitori restanu dispunibili.
   • HTTPHEADER - equilibriu basatu annantu à un header HTTP specificu, chì pò esse specificatu cum'è paràmetru. Se l'intestazione manca o ùn hà micca valore, l'algoritmu ROUND_ROBIN hè appiicatu.
   • URL - Ogni dumanda HTTP GET cerca u paràmetru URL specificatu cum'è argumentu. Se u paràmetru hè seguitu da un signu uguali è un valore, u valore hè hashed è divisu da u pesu tutale di i servitori in esecuzione. U risultatu indica quale servitore riceve a dumanda. Stu prucessu hè utilizatu per mantene a traccia di l'ID di l'utilizatori in e dumande è assicurà chì u stessu ID d'utilizatore hè sempre mandatu à u stessu servitore, sempre chì tutti i servitori restanu dispunibili.

   

3. In u bloccu Membri, cliccate + per aghjunghje servitori à a piscina.
   
   
   Quì avete bisognu di specificà:
   • nome di u servitore;
   • indirizzu IP di u servitore;
   • u portu nantu à quale u servitore riceverà u trafficu;
   • portu per u cuntrollu di salute (Monitor healthcheck);
   • pesu - usendu stu paràmetru pudete aghjustà a quantità proporzionale di u trafficu ricevutu per un membru specificu di a piscina;
   • Max Connections - numeru massimu di cunnessione à u servitore;
   • Min Connections - u numeru minimu di cunnessione chì u servitore deve processà prima chì u trafficu hè trasmessu à u prossimu membru di a piscina.

   
   
   Questu hè ciò chì pare u pool finale di trè servitori.
   

Adding Server Virtual

1. Andà à a tabulazione Servitori Virtuali. Cliccate +.
   
2. Attivamu u servitore virtuale usendu Enable Virtual Server.
   Demu un nome, selezziunà u Profile di l'Applicazione creatu prima, Pool è indicà l'indirizzu IP à quale u Server Virtual riceverà richieste da fora. Specificemu u protocolu HTTPS è u portu 443.
   Paràmetri opzionali quì:
   Limitu di cunnessione - u numeru massimu di cunnessione simultanea chì u servitore virtuale pò processà;
   Limite di Rate di Cunnessione (CPS) - u numeru massimu di novi richieste entrate per seconda.
   

Questu cumpleta a cunfigurazione di u balancer; pudete verificà a so funziunalità. I servitori anu una cunfigurazione simplice chì permette di capisce quale servitore da a piscina hà trattatu a dumanda. Durante a cunfigurazione, avemu sceltu l'algoritmu di equilibriu Round Robin, è u paràmetru di Pezu per ogni servitore hè uguali à unu, cusì ogni dumanda successiva serà processata da u servitore prossimu da a piscina.
Insememu l'indirizzu esternu di u balancer in u navigatore è vede:


Dopu avè rinfriscatu a pagina, a dumanda serà trattata da u servitore seguente:


È dinò - per verificà u terzu servitore da a piscina:


Quandu verificate, pudete vede chì u certificatu chì Edge ci manda hè u listessu chì avemu generatu à u principiu.

Verificate u statu di l'equilibriu da a cunsola di a porta di l'Edge. Per fà questu, entre mostra u pool loadbalancer di serviziu.


Configurazione di u Monitor di serviziu per verificà u statutu di i servitori in a piscina
Utilizendu Service Monitor pudemu monitorà u statutu di i servitori in u pool backend. Se a risposta à una dumanda ùn hè micca cum'è s'aspittava, u servitore pò esse cacciatu da a piscina per ùn riceve micca novi richieste.
Per automaticamente, trè metudi di verificazione sò cunfigurati:

• monitor TCP,
• monitor HTTP,
• Monitor HTTPS.

Creemu un novu.

1. Andà à a tabulazione di Monitoraghju di u serviziu, cliccate +.
   
2. Sceglite:
   • nome per u novu metudu;
   • l'intervallu à quale e dumande seranu mandate,
   • timeout aspittendu una risposta,
   • tipu di monitoraghju - dumanda HTTPS utilizendu u metudu GET, codice di statutu previstu - 200 (OK) è URL di dumanda.
3. Questu cumpleta a cunfigurazione di u novu Service Monitor; avà pudemu usà quandu crea una piscina.
   

Stabbilimentu di e regule di l'applicazione

Regoli di Applicazione sò un modu per manipulà u trafficu basatu annantu à certi triggers. Cù sta strumentu, pudemu creà regule avanzate di bilanciamentu di carica chì ùn pò micca esse pussibule attraversu i profili di l'applicazione o altri servizii dispunibili nantu à u Gateway Edge.

1. Per creà una regula, andate à a tabulazione Reguli di l'applicazione di u balancer.
   
2. Sceglite un nome, un script chì aduprà a regula, è cliccate Mantene.
   
3. Dopu chì a regula hè creata, avemu bisognu di edità u Servitore Virtuale digià cunfiguratu.
   
4. In a tabulazione Avanzata, aghjunghje a regula chì avemu creatu.
   

In l'esempiu sopra, avemu attivatu u supportu tlsv1.

Un paru di altre esempi:

Redirige u trafficu à un altru pool.
Cù questu script pudemu redirige u trafficu à un altru equilibriu piscina se a piscina principale hè falata. Per chì a regula funziona, parechje piscine deve esse cunfigurate nantu à u balancer è tutti i membri di a piscina principale deve esse in u statu di down. Avete bisognu di specificà u nome di a piscina, micca u so ID.

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


Redirige u trafficu à una risorsa esterna.
Quì avemu redirect u trafficu à u situ web esternu se tutti i membri di a piscina principale sò falati.

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

Ancu più esempii ccà.

Hè tuttu per mè nantu à u balancer. Sì avete qualchì quistione, dumandate, sò prontu à risponde.

Source: www.habr.com