Nell'ultima volta abbiamo parlato delle capacità di NSX Edge in termini di routing statico e dinamico, mentre oggi ci concentreremo sul bilanciatore di carico.
Prima di cominciare con la configurazione, vorrei ricordare brevemente i principali tipi di bilanciamento.
Teoria
Le odierne soluzioni di bilanciamento del carico sono generalmente suddivise in due categorie: bilanciamento di livello quattro (trasporto) e bilanciamento di livello sette (applicativo). . Il modello OSI non è il migliore punto di riferimento quando si descrivono i metodi di bilanciamento. Ad esempio, se un bilanciatore L4 supporta anche la terminazione TLS, diventa un bilanciatore L7 in questo caso? Tuttavia, questo è quanto.
- Il bilanciatore L4 solitamente si presenta come un proxy intermedio tra il cliente e un insieme di backend disponibili, che termina le connessioni TCP (rispondendo autonomamente al SYN), seleziona un backend e avvia una nuova sessione TCP verso di esso, inviando autonomamente un SYN. Questo tipo di bilanciatore è uno dei più basilari, ma possono esistere altre varianti.
- Il bilanciatore L7 distribuisce il traffico tra i backend disponibili in modo "più sofisticato" rispetto a un bilanciatore L4. Può prendere decisioni sulla scelta del backend basate, ad esempio, sul contenuto del messaggio HTTP (URL, cookie, ecc.).
Indipendentemente dal tipo, il bilanciatore può supportare le seguenti funzionalità:
- Scoperta dei servizi – il processo di identificazione di un insieme di backend disponibili (Static, DNS, Consul, Etcd, ecc.).
- Verifica della disponibilità dei backend identificati (ping attivo del backend tramite richiesta HTTP, rilevamento passivo dei problemi nelle connessioni TCP, presenza di più risposte consecutive con codice HTTP 503, ecc.).
- Effettiva bilanciatura (round robin, selezione casuale, hash IP sorgente, URI).
- Terminazione TLS e verifica dei certificati.
- Opzioni relative 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 di origine quando inoltra una richiesta a uno dei backend. In questo modo, il bilanciatore di carico 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 nello stesso segmento di 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 selezionato.
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 non risponde direttamente all'utente, ma a Edge, poiché l'indirizzo iniziale dell'utente è stato cambiato in quello del bilanciatore.
6. Edge trasmette la risposta del server all'utente.
Schema sottostante.
Modalità trasparente o inline. In questo scenario, il bilanciatore di carico ha interfacce nella rete interna e in quella esterna. Non c'è accesso diretto alla rete interna dalla rete esterna. 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 selezionato.
3. Il pacchetto viene inviato al backend selezionato.
4. Il backend riceve la richiesta con l'indirizzo originale dell'utente (non è stato effettuato source NAT) e risponde direttamente.
5. Il traffico viene nuovamente ricevuto dal bilanciatore di carico, poiché nello schema inline funge normalmente da gateway predefinito per il gruppo di server.
6. L'Edge esegue source NAT per inviare il traffico all'utente, utilizzando il proprio VIP come indirizzo IP sorgente.
Schema sottostante.
Pratica
Sul mio banco di prova sono configurati 3 server con Apache, impostato per funzionare su HTTPS. L'Edge eseguirà il bilanciamento delle richieste HTTPS utilizzando il metodo round robin, effettuando il proxy di ogni nuova richiesta su un nuovo server.
Iniziamo.
Generiamo un certificato SSL, che verrà utilizzato da NSX Edge.
Puoi importare un certificato CA valido o utilizzare uno autofirmato. In questo test utilizzerò un certificato autofirmato.
- Nel'interfaccia di vCloud Director, accediamo alle impostazioni dei servizi Edge.
- Andiamo alla scheda Certificati. Dalla lista delle azioni, selezioniamo l'aggiunta di 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 auto-firmato è apparso nell'elenco disponibile.
Configuriamo il Profilo dell'Applicazione.
I profili delle applicazioni offrono un controllo più completo sul traffico di rete e rendono la sua gestione semplice ed efficace. Con essi, è possibile definire il comportamento per tipi specifici di traffico.
- Andiamo alla scheda Load Balancer e attiviamo il bilanciatore di carico. L'opzione Acceleration enabled consente al bilanciatore di usare un bilanciamento L4 più veloce anziché L7.
- Andiamo alla scheda Profilo dell'applicazione per impostare il profilo dell'applicazione. Clicca su +.
- Impostiamo il nome del profilo e scegliamo il tipo di traffico per cui sarà applicato il profilo. Spiegherò alcuni parametri.
Persistenza – mantiene e traccia i dati della sessione, ad esempio: quale server specifico del pool gestisce la richiesta dell'utente. Ciò garantisce che le richieste dell'utente siano indirizzate allo stesso membro del pool per tutta la durata della sessione o per le sessioni successive.
Abilita il passthrough SSL – selezionando questa opzione, NSX Edge smette di terminare SSL. Invece, la terminazione avviene direttamente sui server per i quali viene effettuato il bilanciamento.
Inserisci l'intestazione HTTP X-Forwarded-For – consente di identificare 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 Certificati del server virtuale -> Certificato di servizio.
- Analogamente per Certificati del Pool -> Certificato di servizio.
Creiamo un pool di server, il cui traffico sarà bilanciato Pools
- Passiamo alla scheda Pools. Clicchiamo su +.
- Impostiamo il nome del pool, scegliamo l'algoritmo (userò round robin) e il tipo di monitoraggio per il health check del backend. L'opzione Trasparente indica se gli IP sorgente originali dei client 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 gli IP sorgente dei client. 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 – selezione del server basata sui risultati dell'esecuzione di una funzione hash per gli IP sorgente e destinazione di ciascun pacchetto.
- LEASTCONN – bilanciamento delle connessioni in entrata, in base al numero già presente su un determinato server. Le nuove connessioni verranno indirizzate al server con il minor numero di connessioni.
- ROUND_ROBIN – nuove connessioni vengono inviate a ciascun server a turno, in base al peso assegnato.
- URI – la parte sinistra dell'URI (fino al punto interrogativo) viene hashata e distribuita sul 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 eseguita una ricerca sul parametro URL specificato come argomento. Se dopo il parametro segue un segno di uguale e un valore, questo valore viene hashato e distribuito sul peso totale dei server attivi. Il risultato indica quale server riceve la richiesta. Questo processo viene utilizzato per tenere traccia degli identificatori degli utenti nelle richieste e garantire che lo stesso user id venga sempre inviato allo stesso server, finché tutti i server rimangono disponibili.
- Nel blocco Members, premi + per aggiungere server al pool.
1. L'indirizzo del server Elasticsearch (definito durante l'installazione).- 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) – questo parametro consente di regolare la quantità proporzionale di traffico ricevuto per un particolare membro del pool;
- Max Connections – il numero massimo di connessioni al server;
- Min Connections – il numero minimo di connessioni che il server deve gestire prima che il traffico venga reindirizzato al successivo membro del pool.
Ecco come appare il pool finale di tre server.
Aggiungiamo il Server Virtuale
- Passiamo alla scheda Server Virtuali. Facciamo clic su +.
- Attiviamo il server virtuale con Abilita Server Virtuale.
Assegniamo un nome, scegliamo il Profilo Applicazione e il Pool creati in precedenza e indichiamo l'indirizzo IP a cui il Server Virtuale riceverà le richieste dall'esterno. Selezioniamo il protocollo HTTPS e la porta 443.
I parametri opzionali sono:
Limite di Connessione – numero massimo di connessioni simultanee che può gestire il server virtuale;
Limite di Frequenza di Connessione (CPS) – numero massimo di nuove richieste in arrivo al secondo.
La configurazione del load balancer è stata completata, ora puoi verificarne il funzionamento. I server hanno una configurazione semplice che consente di capire 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 verrà elaborata dal server successivo del pool.
Inseriamo nell browser l'indirizzo esterno del load balancer e vediamo:
Dopo l'aggiornamento della pagina, la richiesta verrà elaborata dal server successivo:
E ancora una volta, per controllare anche il terzo server del pool:
Controllando, possiamo vedere che il certificato inviato da Edge è quello che abbiamo generato all'inizio.
Verifica dello stato del load balancer dalla console di Edge gateway. Per fare ciò, digita show service loadbalancer pool.
Impostiamo il Service Monitor per controllare lo stato dei server nel pool.
Con il Service Monitor possiamo tenere traccia dello stato dei server nel pool backend. Se la risposta alla richiesta non corrisponde a quella attesa, il server può essere rimosso dal pool per non ricevere ulteriori richieste.
Per impostazione predefinita, sono stati configurati tre metodi di verifica:
- TCP-monitor,
- Monitor HTTP,
- Monitor HTTPS.
Creiamo un nuovo.
- Passiamo alla scheda Service Monitoring, clicca su +.
- Selezioniamo:
- un nome per il nuovo metodo;
- l'intervallo con cui saranno inviati i richieste,
- il timeout per la risposta,
- il tipo di monitoraggio – richiesta HTTPS utilizzando il metodo GET, codice di stato atteso – 200 (OK) e URL della richiesta.
- Abbiamo completato la configurazione del nuovo Service Monitor, ora possiamo utilizzarlo nella creazione di un pool.
Configuriamo le Application Rules
Le Application Rules sono un modo per manipolare il traffico basato su specifici trigger. Con questo strumento possiamo creare regole avanzate di bilanciamento del carico, la cui configurazione potrebbe essere impossibile tramite Application profiles o altri servizi disponibili su Edge Gateway.
- Per creare una regola, passiamo alla scheda Application Rules del bilanciatore.
- Selezioniamo un nome, lo script che utilizzerà la regola e clicchiamo su Keep.
- Dopo che la regola è stata creata, dobbiamo modificare il Virtual Server già configurato.
- Nella scheda Advanced aggiungiamo la regola creata da noi.
Nell'esempio sopra abbiamo abilitato il supporto tlsv1.
Altri due esempi:
Redirecting traffic to another pool.
Con questo script possiamo reindirizzare il traffico a un altro pool di bilanciamento se il pool principale non funziona. Affinché la regola funzioni, su un bilanciatore deve essere configurato più di un pool e tutti i membri del pool principale devono essere in stato di inattività. È 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
Reindirizzamento del traffico a una risorsa esterna.
Qui reindirizziamo il traffico a un sito web esterno se tutti i partecipanti del pool principale sono in stato di inattività.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ancora più esempi .
Per quanto riguarda il bilanciatore, questo è tutto. Se avete domande, chiedete pure, sono disponibile a rispondere.
Fonte: habr.com
