L'ultima volta abbiamo parlato delle funzionalità di NSX Edge in relazione al routing statico e dinamico, mentre oggi ci concentreremo sul bilanciatore.
Prima di iniziare la configurazione, vorrei rapidamente ricordare i principali tipi di bilanciamento.
Teoria
Oggi, le soluzioni di bilanciamento del carico vengono generalmente suddivise in due categorie: bilanciamento a livello quattro (trasporto) e a livello sette (applicativo) del modello. . Il modello OSI non è il migliore punto di riferimento per descrivere i metodi di bilanciamento. Ad esempio, se un bilanciatore L4 supporta anche la terminazione TLS, diventa un bilanciatore L7? Ma così sta di fatto.
- Bilanciatore L4 è spesso un proxy intermedio che si colloca tra il client e un insieme di backend disponibili, terminando le connessioni TCP (cioè risponde autonomamente a SYN), selezionando un backend e avviando una nuova sessione TCP in direzione di quest'ultimo, inviando autonomamente un SYN. Questo tipo è uno dei più basilari, sono possibili anche altre varianti.
- Bilanciatore L7 distribuisce il traffico tra i backend disponibili in modo "più sofisticato" rispetto al bilanciatore L4. Può decidere quale backend utilizzare, ad esempio, in base al contenuto del messaggio HTTP (URL, cookie, ecc.).
Indipendentemente dal tipo, il bilanciatore può supportare le seguenti funzionalità:
- Rilevamento dei servizi: processo di identificazione di un insieme di backend disponibili (Statico, DNS, Consul, Etcd, ecc.).
- Controllo della disponibilità dei backend rilevati (ping attivo del backend con una richiesta HTTP, rilevamento passivo di problemi nelle connessioni TCP, presenza di più risposte consecutive 503 HTTP, ecc.).
- Il bilanciamento stesso (round robin, selezione casuale, hash dell'IP sorgente, URI).
- Terminazione TLS e verifica dei certificati.
- Opzioni legate alla sicurezza (autenticazione, prevenzione degli attacchi DoS, limitazione della velocità) e molto altro.
NSX Edge offre supporto per due modalità di distribuzione del bilanciatore:
Modalità proxy, o one-arm. In questa modalità, NSX Edge utilizza il proprio indirizzo IP come indirizzo sorgente quando invia una richiesta a uno dei backend. In questo modo, il bilanciatore svolge simultaneamente le funzioni di Source e Destination NAT. Il backend vede tutto il traffico come inviato dal bilanciatore e risponde direttamente a esso. In questo schema, il bilanciatore deve trovarsi nella stessa rete dei server interni.
Ecco come avviene:
1. L'utente invia una richiesta all'indirizzo VIP (l'indirizzo del bilanciatore) configurato su Edge.
2. Edge seleziona uno dei backend ed esegue il destination NAT, sostituendo l'indirizzo VIP con l'indirizzo del backend scelto.
3. Edge esegue il source NAT, sostituendo l'indirizzo dell'utente che ha inviato la richiesta con il proprio.
4. Il pacchetto viene inviato al backend selezionato.
5. Il backend risponde non direttamente all'utente, ma a Edge, poiché l'indirizzo originale dell'utente è stato modificato in quello del bilanciatore.
6. Edge trasmette la risposta del server all'utente.
Lo schema è riportato di seguito.
Modalità trasparente, o inline. In questo scenario, il bilanciatore dispone di interfacce nella rete interna e in quella esterna. Allo stesso tempo, non vi è accesso diretto alla rete interna dall'esterno. Il bilanciatore di carico integrato funge da gateway NAT per le macchine virtuali nella rete interna.
Il meccanismo è il seguente:
1. L'utente invia una richiesta all'indirizzo VIP (l'indirizzo del bilanciatore) configurato su Edge.
2. Edge seleziona uno dei backend ed esegue il destination NAT, sostituendo l'indirizzo VIP con l'indirizzo del backend scelto.
3. Il pacchetto viene inviato al backend selezionato.
4. Il backend riceve la richiesta con l'indirizzo originale dell'utente (non è stato eseguito il source NAT) e risponde direttamente ad essa.
5. Il traffico viene nuovamente acquisito dal bilanciatore di carico, poiché nella modalità inline funge normalmente da gateway predefinito per il gruppo di server.
6. Edge esegue il source NAT per inviare il traffico all'utente, utilizzando il proprio VIP come indirizzo IP sorgente.
Lo schema è riportato di seguito.
Pratica
Nel mio ambiente di test sono configurati 3 server con Apache, configurato per operare tramite HTTPS. Edge eseguirà il bilanciamento delle richieste HTTPS utilizzando il metodo round robin, indirizzando ogni nuova richiesta a un nuovo server.
Iniziamo.
Generiamo un certificato SSL che sarà utilizzato da NSX Edge
È possibile importare un certificato CA valido o utilizzare uno autofirmato. In questo test utilizzerò un certificato autofirmato.
- Nell'interfaccia di vCloud Director, andiamo alle impostazioni dei servizi Edge.
- Andiamo alla scheda Certificati. Dalla lista delle azioni, scegliamo di aggiungere un nuovo CSR.
- Compiliamo i campi necessari e premiamo Keep.
- Selezioniamo il CSR appena creato e scegliamo l'opzione self-sign CSR.
- Selezioniamo la durata di validità del certificato e premiamo Keep.
- Il certificato autofirmato è apparso nell'elenco disponibile.
Configuriamo il Profilo dell'Applicazione.
I profili delle applicazioni forniscono un controllo più completo sul traffico di rete e rendono la gestione semplice ed efficace. Con essi è possibile definire il comportamento per specifici tipi di traffico.
- Andiamo alla scheda Load Balancer e attiviamo il bilanciatore. L'opzione Acceleration enabled qui consente al bilanciatore di utilizzare un bilanciamento L4 più veloce invece di L7.
- Passiamo alla scheda Profilo Applicazione per impostare il profilo dell'applicazione. Clicca su +.
- Assegniamo un nome al profilo e scegliamo il tipo di traffico per il quale il profilo verrà applicato. Spiegherò alcuni parametri.
Persistenza – conserva e monitora i dati della sessione, ad esempio: quale server specifico del pool gestisce la richiesta dell'utente. Questo garantisce che le richieste dell'utente vengano indirizzate allo stesso membro del pool durante l'intera durata della sessione o delle sessioni successive.
Abilita SSL passthrough – selezionando questa opzione NSX Edge smette di terminare l'SSL. Invece, la terminazione avviene direttamente sui server per i quali viene effettuato il bilanciamento.
Inserisci l'intestazione HTTP X-Forwarded-For – consente di determinare l'indirizzo IP originale del client che si connette al server web tramite il bilanciatore.
Abilita SSL lato Pool – consente di specificare che il pool selezionato è composto da server HTTPS.
- Poiché bilancerò il traffico HTTPS, è necessario abilitare SSL lato Pool e selezionare il certificato generato in precedenza nella scheda Virtual Server Certificates -> Service Certificate.
- Similmente per Pool Certificates -> Service Certificate.
Creiamo un pool di server al quale verrà bilanciato il traffico Pools.
- Andiamo alla scheda Pools. Clicca su +.
- Assegniamo un nome al pool, scegliamo l'algoritmo (io userò round robin) e il tipo di monitoraggio per il controllo dello stato del backend. L'opzione Transparent indica se gli indirizzi IP originali dei clienti sono visibili ai server interni.
- Se l'opzione è disattivata, il traffico per i server interni proviene dall'IP sorgente del bilanciatore.
- Se l'opzione è attivata, i server interni vedono l'IP sorgente dei clienti. In questa configurazione, NSX Edge deve fungere da gateway predefinito per garantire che i pacchetti restituiti passino attraverso NSX Edge.
NSX supporta i seguenti algoritmi di bilanciamento:
- IP_HASH – scelta del server basata sui risultati dell'esecuzione della funzione hash per gli IP source e destination di ogni pacchetto.
- LEASTCONN – bilanciamento delle connessioni in entrata, in base al numero di connessioni già stabilite su un determinato server. Le nuove connessioni saranno indirizzate al server con il minor numero di connessioni.
- ROUND_ROBIN – nuove connessioni vengono inoltrate a ciascun server in ordine, in base al peso assegnato.
- URI – la parte sinistra dell'URI (fino al punto interrogativo) viene hashata e divisa per il peso totale dei server nel pool. Il risultato indica quale server riceve la richiesta, garantendo che la richiesta venga sempre inviata allo stesso server, finché tutti i server rimangono disponibili.
- HTTPHEADER – bilanciamento basato su un determinato header HTTP, che può essere specificato come parametro. Se l'header è assente o non ha alcun valore, viene applicato l'algoritmo ROUND_ROBIN.
- URL – in ogni richiesta HTTP GET viene effettuata una ricerca in base al parametro URL specificato come argomento. Se dopo il parametro c'è un segno di uguale e un valore, il valore viene hashato e diviso per il peso totale dei server attivi. Il risultato indica quale server riceve la richiesta. Questo processo viene utilizzato per tenere traccia degli identificatori utente nelle richieste e garantire che lo stesso user id venga sempre inviato allo stesso server, finché tutti i server rimangono disponibili.
- Nella sezione Members clicchiamo su + per aggiungere i server al pool.
Qui è necessario specificare:- nome del server;
- indirizzo IP del server;
- porta sulla quale il server riceverà il traffico;
- porta per il controllo della salute (Monitor healthcheck);
- peso (Weight) – con questo parametro è possibile regolare la quantità proporzionale di traffico ricevuto per un determinato membro del pool;
- Max Connections – numero massimo di connessioni al server;
- Min Connections – numero minimo di connessioni che il server deve gestire prima che il traffico venga reindirizzato al prossimo membro del pool.
Ecco come appare il pool finale di tre server.
Aggiungiamo il Server Virtuale
- Passiamo alla scheda Server Virtuali. Clicchiamo su +.
- Attiviamo il server virtuale utilizzando Abilita Server Virtuale.
Diamo un nome, selezioniamo il profilo dell'applicazione creato in precedenza, il Pool e indichiamo l'indirizzo IP, al quale il Server Virtuale accetterà richieste dall'esterno. Indichiamo il protocollo HTTPS e la porta 443.
I parametri opzionali sono:
Limite di connessione – il numero massimo di connessioni simultanee che il server virtuale può gestire;
Limite di velocità di connessione (CPS) – il numero massimo di nuove richieste in entrata al secondo.
A questo punto la configurazione del bilanciatore è completata, possiamo verificarne la funzionalità. I server hanno una configurazione semplice, che consente di comprendere quale server del pool ha elaborato la richiesta. Durante la configurazione abbiamo scelto l'algoritmo di bilanciamento Round Robin e il parametro Weight per ogni server è pari a uno, quindi ogni richiesta successiva sarà gestita dal server successivo nel pool.
Inseriamo nell browser l'indirizzo esterno del bilanciatore e vediamo:
Dopo il caricamento della pagina, la richiesta sarà elaborata dal server successivo:
E un'altra volta – per verificare anche il terzo server del pool:
Dalla verifica si può vedere che il certificato inviato da Edge è quello che abbiamo generato all'inizio.
Verifica dello stato del bilanciatore dalla console dell'Edge gateway. Per farlo, inserire: show service loadbalancer pool.
Configuriamo il Service Monitor per controllare lo stato dei server nel pool
Con il Service Monitor possiamo monitorare lo stato dei server nel pool backend. Se la risposta alla richiesta non corrisponde a quanto previsto, il server può essere rimosso dal pool per non ricevere ulteriori richieste.
Sono stati configurati per impostazione predefinita tre metodi di verifica:
- TCP-monitor,
- HTTP-monitor,
- HTTPS-monitor.
Creiamo un nuovo metodo.
- Passiamo alla scheda Service Monitoring, premiamo +.
- Selezioniamo:
- un nome per il nuovo metodo;
- l'intervallo con cui verranno inviate le richieste,
- il timeout di attesa della risposta,
- il tipo di monitoraggio – richiesta HTTPS che utilizza il metodo GET, codice di stato atteso – 200(OK) e URL della richiesta.
- A questo punto la configurazione del nuovo Service Monitor è completata, ora possiamo usarlo durante la creazione del pool.
Configuriamo le Regole dell'Applicazione
Le Regole dell'Applicazione sono un modo per manipolare il traffico, basato su determinati trigger. Con questo strumento possiamo creare regole avanzate di bilanciamento del carico, la cui configurazione potrebbe essere impossibile tramite i profili delle applicazioni o con altri servizi disponibili sull'Edge Gateway.
- Per creare una regola, andiamo sulla scheda Application Rules del bilanciatore.
- Selezioniamo il nome, lo script che utilizzerà la regola e premiamo Keep.
- Dopo aver creato la regola, dobbiamo modificare il Virtual Server già configurato.
- Nella scheda Advanced aggiungiamo la regola che abbiamo creato.
Nell'esempio sopra abbiamo abilitato il supporto per tlsv1.
Altri esempi:
Reindirizzare il traffico a un altro pool.
Con questo script possiamo reindirizzare il traffico a un altro pool di bilanciamento, se il pool principale non funziona. Affinché la regola funzioni, devono essere configurati più pool sul bilanciatore e tutti i membri del pool principale devono essere in stato di down. È necessario specificare esattamente il nome del pool, non il suo ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Reindirizzare il traffico a una risorsa esterna.
Qui reindirizziamo il traffico a un sito web esterno, se tutti i membri del pool principale sono in stato di down.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ancora più esempi .
Questo è tutto sul bilanciatore. Se avete domande, chiedete pure, sono pronto a rispondere.
Fonte: habr.com
