L'ultima volta abbiamo parlato delle capacità di NSX Edge in termini di routing statico e dinamico, mentre oggi ci occuperemo del bilanciamento del carico.
Prima di iniziare la configurazione, vorrei ricordarvi brevemente le principali tipologie di bilanciamento.
Teoria
Tutte le attuali soluzioni di bilanciamento del carico utile sono spesso divise in due categorie: bilanciamento al quarto (trasporto) e al settimo livello (applicazione) del modello . Il modello OSI non è il miglior punto di riferimento quando si descrivono i metodi di bilanciamento. Ad esempio, se un sistema di bilanciamento L4 supporta anche la terminazione TLS, diventa un sistema di bilanciamento L7? Ma è quello che è.
- Bilanciatore L4 molto spesso si tratta di un proxy intermedio che si trova tra il client e una serie di backend disponibili, che termina le connessioni TCP (ovvero risponde in modo indipendente a SYN), seleziona un backend e avvia una nuova sessione TCP nella sua direzione, inviando in modo indipendente SYN. Questo tipo è uno di quelli base; sono possibili altre opzioni.
- Bilanciatore L7 distribuisce il traffico tra i backend disponibili in modo "più sofisticato" rispetto al bilanciatore L4. Può decidere quale backend scegliere in base, ad esempio, al contenuto del messaggio HTTP (URL, cookie, ecc.).
Indipendentemente dal tipo, il bilanciatore può supportare le seguenti funzioni:
- L'individuazione del servizio è il processo di determinazione dell'insieme di backend disponibili (Static, DNS, Consul, Etcd, ecc.).
- Controllo della funzionalità dei backend rilevati (ping attivo del backend utilizzando una richiesta HTTP, rilevamento passivo di problemi nelle connessioni TCP, presenza di diversi codici 503 HTTP nelle risposte, ecc.).
- Il bilanciamento stesso (round robin, selezione casuale, hash IP di origine, URI).
- Terminazione TLS e verifica del certificato.
- 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 del carico:
Modalità proxy o ad un braccio. In questa modalità, NSX Edge utilizza il proprio indirizzo IP come indirizzo di origine quando invia una richiesta a uno dei backend. Pertanto, il bilanciatore esegue contemporaneamente le funzioni di NAT di origine e di destinazione. Il backend vede tutto il traffico inviato dal bilanciatore e risponde direttamente ad esso. In tale schema, il bilanciatore deve trovarsi nello stesso segmento di rete con i server interni.
Ecco come succede:
1. L'utente invia una richiesta all'indirizzo VIP (indirizzo del bilanciatore) configurato sull'Edge.
2. Edge seleziona uno dei backend ed esegue il NAT di destinazione, sostituendo l'indirizzo VIP con l'indirizzo del backend selezionato.
3. Edge esegue il NAT sorgente, 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 all'Edge, poiché l'indirizzo originale dell'utente è stato modificato nell'indirizzo del bilanciatore.
6. Edge trasmette la risposta del server all'utente.
Il diagramma è sotto.
Modalità trasparente o in linea. In questo scenario, il bilanciatore dispone di interfacce sulle reti interne ed esterne. Allo stesso tempo, non è possibile accedere direttamente alla rete interna da quella esterna. Il sistema di bilanciamento del carico integrato funge da gateway NAT per le macchine virtuali sulla rete interna.
Il meccanismo è il seguente:
1. L'utente invia una richiesta all'indirizzo VIP (indirizzo del bilanciatore) configurato sull'Edge.
2. Edge seleziona uno dei backend ed esegue il NAT di destinazione, sostituendo l'indirizzo VIP con l'indirizzo del backend selezionato.
3. Il pacchetto viene inviato al backend selezionato.
4. Il backend riceve una richiesta con l'indirizzo originale dell'utente (il NAT di origine non è stato eseguito) e risponde direttamente ad essa.
5. Il traffico viene nuovamente accettato dal bilanciatore del carico, poiché in uno schema inline funge solitamente da gateway predefinito per la server farm.
6. Edge esegue il NAT di origine per inviare traffico all'utente, utilizzando il suo VIP come indirizzo IP di origine.
Il diagramma è sotto.
Pratica
Il mio banco di prova ha 3 server che eseguono Apache, che è configurato per funzionare su HTTPS. Edge eseguirà il bilanciamento round robin delle richieste HTTPS, inoltrando ogni nuova richiesta a un nuovo server.
Cominciamo
Generazione di un certificato SSL che verrà utilizzato da NSX Edge
È possibile importare un certificato CA valido o utilizzarne uno autofirmato. Per questo test utilizzerò self-signed.
- Nell'interfaccia di vCloud Director, vai alle impostazioni dei servizi Edge.
- Vai alla scheda Certificati. Dall'elenco delle azioni, seleziona l'aggiunta di una nuova CSR.
- Compila i campi richiesti e fai clic su Mantieni.
- Seleziona la CSR appena creata e seleziona l'opzione CSR autofirmata.
- Selezionare il periodo di validità del certificato e fare clic su Conserva
- Il certificato autofirmato viene visualizzato nell'elenco di quelli disponibili.
Configurazione del profilo dell'applicazione
I profili applicativi offrono un controllo più completo sul traffico di rete e ne rendono la gestione semplice ed efficace. Possono essere utilizzati per definire il comportamento per tipi specifici di traffico.
- Vai alla scheda Load Balancer e abilita il bilanciatore. L'opzione Accelerazione abilitata qui consente al bilanciatore di utilizzare il bilanciamento più veloce L4 invece di L7.
- Vai alla scheda Profilo dell'applicazione per impostare il profilo dell'applicazione. Fare clic su +.
- Imposta il nome del profilo e seleziona il tipo di traffico per il quale verrà applicato il profilo. Lasciatemi spiegare alcuni parametri.
Persistenza – memorizza e tiene traccia dei dati della sessione, ad esempio: quale server specifico nel pool sta servendo la richiesta dell'utente. Ciò garantisce che le richieste degli utenti vengano instradate allo stesso membro del pool per tutta la durata della sessione o per le sessioni successive.
Abilita pass-through SSL – Quando questa opzione è selezionata, NSX Edge interrompe la terminazione di SSL. La terminazione avviene invece direttamente sui server in fase di bilanciamento.
Inserisci l'intestazione HTTP X-Forwarded-For – consente di determinare l'indirizzo IP di origine del client che si connette al server web tramite il bilanciamento del carico.
Abilita SSL lato pool – consente di specificare che il pool selezionato è costituito da server HTTPS.
- Poiché bilancerò il traffico HTTPS, devo abilitare Pool Side SSL e selezionare il certificato generato in precedenza nella scheda Certificati server virtuale -> Certificato di servizio.
- Allo stesso modo per i certificati del pool -> Certificato di servizio.
Creiamo un pool di server, il cui traffico sarà bilanciato. Pool
- Vai alla scheda Pool. Fare clic su +.
- Impostiamo il nome del pool, selezioniamo l'algoritmo (userò round robin) e il tipo di monitoraggio per il backend di controllo dello stato. L'opzione Trasparente indica se gli IP di origine iniziali dei client sono visibili ai server interni.
- Se l'opzione è disabilitata, il traffico per i server interni proviene dall'IP di origine del bilanciatore.
- Se l'opzione è abilitata, i server interni vedono l'IP di origine 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 in base ai risultati di una funzione hash per l'IP di origine e destinazione di ciascun pacchetto.
- CONN.MIN – bilanciamento delle connessioni in entrata, a seconda del numero già disponibile su un particolare server. Le nuove connessioni verranno indirizzate al server con il minor numero di connessioni.
- GIRO_ROBIN – le nuove connessioni vengono inviate a turno a ciascun server, in base al peso ad esso assegnato.
- URI – la parte sinistra dell'URI (prima del punto interrogativo) viene sottoposta ad hashing e divisa per il peso totale dei server nel pool. Il risultato indica quale server riceve la richiesta, garantendo che la richiesta venga sempre instradata allo stesso server, purché tutti i server rimangano disponibili.
- INTESTAZIONE HTTP – bilanciamento basato su una specifica intestazione HTTP, che può essere specificata come parametro. Se l'intestazione manca o non ha alcun valore, viene applicato l'algoritmo ROUND_ROBIN.
- URL – Ogni richiesta HTTP GET cerca il parametro URL specificato come argomento. Se il parametro è seguito da un segno di uguale e da un valore, il valore viene sottoposto ad hashing e diviso per il peso totale dei server in esecuzione. Il risultato indica quale server riceve la richiesta. Questo processo viene utilizzato per tenere traccia degli ID utente nelle richieste e garantire che lo stesso ID utente venga sempre inviato allo stesso server, purché tutti i server rimangano disponibili.
- Nel blocco Membri, fai clic su + per aggiungere server al pool.
Qui è necessario indicare:- nome del server;
- Indirizzo IP del server;
- la porta su cui il server riceverà il traffico;
- porta per il controllo sanitario (Monitor Healthcheck);
- peso: utilizzando questo parametro è possibile regolare la quantità proporzionale di traffico ricevuto per uno specifico membro del pool;
- Connessioni massime – numero massimo di connessioni al server;
- Connessioni minime: il numero minimo di connessioni che il server deve elaborare prima che il traffico venga inoltrato al membro successivo del pool.
Questo è l'aspetto del pool finale di tre server.
Aggiunta del server virtuale
- Vai alla scheda Server virtuali. Fare clic su +.
- Attiviamo il server virtuale utilizzando Abilita server virtuale.
Gli diamo un nome, selezioniamo il Profilo Applicazione precedentemente creato, il Pool e indichiamo l'indirizzo IP al quale il Server Virtuale riceverà le richieste dall'esterno. Specifichiamo il protocollo HTTPS e la porta 443.
Parametri opzionali qui:
Limite di connessione – il numero massimo di connessioni simultanee che il server virtuale può elaborare;
Limite di velocità di connessione (CPS) – il numero massimo di nuove richieste in entrata al secondo.
Questo completa la configurazione del bilanciatore; potrai verificarne la funzionalità. 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 ciascun server è uguale a uno, quindi ogni richiesta successiva verrà elaborata dal server successivo del pool.
Inseriamo l'indirizzo esterno del bilanciatore nel browser e vediamo:
Dopo aver aggiornato la pagina, la richiesta verrà elaborata dal seguente server:
E ancora: per controllare il terzo server del pool:
Durante il controllo, puoi vedere che il certificato che Edge ci invia è lo stesso che abbiamo generato all'inizio.
Controllo dello stato del sistema di bilanciamento dalla console del gateway Edge. Per fare ciò, entra mostra il pool del servizio di bilanciamento del carico.
Configurazione di Service Monitor per verificare lo stato dei server nel pool
Utilizzando Service Monitor possiamo monitorare lo stato dei server nel pool backend. Se la risposta ad una richiesta non è quella prevista, il server può essere tolto dal pool in modo che non riceva nuove richieste.
Per impostazione predefinita, sono configurati tre metodi di verifica:
- Monitor TCP,
- Monitoraggio HTTP,
- Monitor HTTPS.
Creiamone uno nuovo.
- Vai alla scheda Monitoraggio del servizio, fai clic su +.
- Scegliere:
- nome per il nuovo metodo;
- l'intervallo con cui verranno inviate le richieste,
- timeout in attesa di una risposta,
- tipo di monitoraggio: richiesta HTTPS utilizzando il metodo GET, codice di stato previsto: 200 (OK) e URL della richiesta.
- Questo completa la configurazione del nuovo Service Monitor; ora possiamo usarlo durante la creazione di un pool.
Impostazione delle regole dell'applicazione
Le regole dell'applicazione rappresentano un modo per manipolare il traffico in base a determinati trigger. Con questo strumento possiamo creare regole avanzate di bilanciamento del carico che potrebbero non essere possibili tramite i profili applicativi o altri servizi disponibili sull'Edge Gateway.
- Per creare una regola, vai alla scheda Regole applicazione del bilanciatore.
- Seleziona un nome, uno script che utilizzerà la regola e fai clic su Mantieni.
- Dopo aver creato la regola, dobbiamo modificare il server virtuale già configurato.
- Nella scheda Avanzate, aggiungi la regola che abbiamo creato.
Nell'esempio sopra abbiamo abilitato il supporto tlsv1.
Ancora un paio di esempi:
Reindirizzare il traffico verso un altro pool.
Con questo script possiamo reindirizzare il traffico verso un altro pool di bilanciamento se il pool principale è inattivo. Affinché la regola funzioni, è necessario configurare più pool sul sistema di bilanciamento e tutti i membri del pool principale devono essere nello stato inattivo. È necessario specificare 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 verso una risorsa esterna.
Qui reindirizziamo il traffico al sito Web esterno se tutti i membri del pool principale sono inattivi.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Ancora più esempi .
Questo è tutto per me riguardo al bilanciatore. Se avete domande fatele, sono pronto a rispondere.
Fonte: habr.com