Utilizzo di HAProxy per il bilanciamento del carico su E2E Cloud:stabilità e sicurezza della sessione

Nella prima parte di questo blog abbiamo impostato HAProxy su un nodo Virtual Load Balancer su E2E Cloud. Abbiamo anche configurato HAProxy per instradare le richieste ai server Web back-end utilizzando una politica round-robin.

In questa seconda e conclusiva parte di questo blog, analizzeremo un paio di impostazioni di configurazione avanzate richieste dalla maggior parte dei siti Web:persistenza della sessione e accesso sicuro al sito Web tramite SSL. Ma prima di farlo, mostreremo come la nostra singola istanza HAProxy può soddisfare un grande sito Web con molte applicazioni Web, in virtù degli ACL. Nel frattempo, presenteremo alcune opzioni di configurazione aggiuntive, come la politica round robin ponderata, e concluderemo con indicazioni su altre considerazioni importanti per un'implementazione di produzione.

Configurazione del bilanciamento del carico per più applicazioni Web

Molti siti Web di grandi dimensioni sono costituiti da diversi cluster di server Web, ciascuno dei quali ospita un'applicazione Web diversa. Ad esempio, potrebbe esserci un sito Web con contenuti principali insieme a un sito Web per divertimento e intrattenimento. HAProxy è in grado di instradare le richieste al cluster corretto in base a modelli di URL e Elenchi di controllo degli accessi (ACL).

Per illustrare questa capacità, creiamo prima due nuovi nodi di server Web su E2E Cloud, denominati "webserver3" e "webserver4". Come al solito, installiamo il web server Apache ei pacchetti PHP sui due nuovi nodi. Quindi distribuiamo una seconda applicazione PHP all'URL '/fun/films.php' su solo questi due nodi appena aggiunti . (La seconda applicazione utilizza la persistenza della sessione e le sue funzionalità verranno spiegate nella sezione successiva.)

Quindi, abbiamo i seguenti nodi (4 server web e un sistema di bilanciamento del carico) visibili sulla nostra dashboard:

Figura 1:server Web per più applicazioni Web

Quindi HAProxy deve indirizzare le richieste dei client per l'URL '/fun/films.php' solo a uno dei nodi 'webserver3' e 'webserver4', altrimenti la richiesta non può essere soddisfatta. Per soddisfare questo requisito, modifichiamo la configurazione di HAProxy (/etc/haproxy/haproxy.cfg) e creiamo un altro backend (denominato "film") composto solo dai due nuovi nodi del server web. Questo è in aggiunta al backend esistente chiamato "sito".

Figura 2:configurazione del backend per una nuova applicazione

Quindi, nella configurazione frontend esistente, introduciamo un ACL come mostrato di seguito. Ciò significa che qualsiasi percorso URL che inizia con '/fun' verrà instradato al backend denominato 'films', mentre per impostazione predefinita tutte le altre richieste atterreranno sul backend (preesistente) denominato 'site' (costituito da nodi solo 'websrv1' e 'websrv2').

Figura 3:configurazione frontend con ACL

Figura 4:bilanciamento del carico HAProxy con ACL

Impostazioni di configurazione avanzate

Normativa ponderata Round Robin :Durante le modifiche agli ACL, abbiamo introdotto un peso a ciascun server. In produzione, server diversi possono avere una potenza di calcolo diversa, quindi l'utilizzo dei pesi consente a HAProxy di instradare più richieste a server più potenti. (Nel nostro caso tutti i nodi del server Web sono simili e tutti i pesi sono uguali, ma possiamo usarlo come modello e modificarlo in uno scenario diverso.)

Numero massimo di connessioni per server :In secondo luogo, abbiamo anche utilizzato il parametro 'maxconn' a livello di server back-end , in modo che ogni server possa limitare il numero di connessioni a quanto è ragionevole per la sua potenza di elaborazione. Il "maxconn" globale dovrebbe essere maggiore della somma totale dei valori a livello di server di questo parametro (lasciando spazio per l'aggiunta di più nodi del server Web per la scalabilità).

Vischiosità della sessione

La nuova applicazione PHP utilizza sessioni PHP. Ogni volta che un client accede a questa applicazione, fornisce il nome di un film preferito (tramite un parametro HTTP GET denominato "fav"), che viene aggiunto alla sessione PHP. Il server risponde con l'elenco dei film preferiti (unico per ogni cliente) raccolto finora.

2. inizio_sessione();
3. $fav =$_GET['fav'];
4. if ( isset( $_SESSION['preferiti'] ) ) {
5.     $_SESSION['preferiti'] .=' , ';
6.     $_SESSION['preferiti'] .=$fav;
7. } altro {
8.     $_SESSION['preferiti'] =$preferito;
9. }
10. $msg ='I miei film preferiti:'. $_SESSION['preferiti'];
11. ?>
13.    
14.        
15.    
16.    
17.        
18.         echo $msg;
19.         ?>
20.    

Le sessioni PHP possono essere locali in un'istanza del server Web (a meno che la persistenza o la replica della sessione non siano abilitate). Pertanto, se lo stesso client viene instradato casualmente a diverse istanze del server Web di back-end in momenti diversi, quando effettua una serie di richieste, i dati della sua sessione potrebbero diventare imprevedibili. Ma un cliente può essere costretto a "rimanere ' a una singola istanza del server web entro la durata di una sessione.

Un modo per configurarlo in HAProxy consiste nell'introdurre il parametro 'appsession' nella configurazione del backend pertinente ('films' , nel nostro caso). Diversi tipi di applicazioni utilizzano diversi cookie HTTP per la gestione delle sessioni. In caso di applicazioni PHP, questo Cookie è denominato "PHPSESSID". Impostando 'appsession', HAProxy associa un singolo server web a ciascuno 'PHPSESSID' (quello in cui è stata creata questa sessione) e instrada le richieste client ripetute contenenti lo stesso ID sessione allo stesso server Web, finché è attivo e in esecuzione o la sessione è scaduta .

1. appsession PHPSESSID len 32 timeout 1h

Ovviamente, se quel server web non è disponibile per qualsiasi motivo, HAProxy dovrebbe essere libero di instradare le richieste con lo stesso ID di sessione a una diversa istanza del server attivo. Ciò può essere assicurato aggiungendo l'opzione 'redispatch' nella sezione 'default' del file di configurazione HAProxy.

1. opzione di rispedizione

Test

Ora possiamo testare sia gli ACL che la persistenza della sessione. Possiamo pedinare i log HAProxy sul nodo di bilanciamento del carico:

1. coda -f /var/log/haproxy.log

Cogliamo anche i log di accesso al server web su ciascuno dei nodi 'webserver3' e 'webserver4'.

1. tail -f /var/log/apache2/access.log

Da due diversi computer client, inviamo richieste al seguente URL da un browser:http:///fun/films.php?fav=afilm

In ogni richiesta possiamo impostare un valore diverso per il parametro della query denominato 'fav'.

Dal primo cliente, inviamo le seguenti richieste successive:

1. http:///fun/films.php?fav=avengers
2. http:///fun/films.php?fav=jurassicworld

La finestra del browser sul primo client visualizzerà:

Figura 5:una sessione client

Dal secondo client, inviamo le seguenti richieste successive:

1. http:///fun/films.php?fav=race3
2. http:///fun/films.php?fav=gold

La finestra del browser nel secondo client visualizzerà:

Figura 6:un'altra sessione client

Dalla risposta visualizzata in ciascun browser client, è chiaro che le sessioni vengono mantenute correttamente in ogni caso. In Firefox, dalla console web, possiamo anche controllare i valori PHPSESSID.

Possiamo fare le seguenti due osservazioni dai registri HAProxy e del server web:

1. Queste richieste con pattern URL '/fun' vengono indirizzate al backend denominato solo 'films' (politiche ACL)
2. Una richiesta dallo stesso indirizzo IP del client arriva allo stesso nodo del server web (persistenza della sessione)

Figura 7:registri HAProxy con sessioni permanenti

Figura 8:Accesso ai log sul nodo webserver3 con sessioni permanenti

Figura 9:Accesso ai log sul nodo webserver4 con sessioni permanenti

Sicurezza:terminazione SSL

Un'ultima ma cruciale configurazione che ci piace adottare è relativa alla sicurezza. I server Web Apache possono essere configurati per supportare HTTPS, ma quando abbiamo HAProxy installato sul frontend, le richieste dei client arriveranno prima al sistema di bilanciamento del carico.

Quindi, si consiglia di configurare HAProxy per supportare HTTPS. Questo è un processo in quattro fasi:

1. Ottieni un certificato SSL per il nostro sito web. A scopo sperimentale, abbiamo creato un certificato autofirmato denominato haproxy.pem utilizzando openssl
2. Collega il frontend a una porta HTTPS (per impostazione predefinita 443) e assegna il certificato SSL a questo frontend
3. Abilita HAProxy per reindirizzare le richieste client inviate tramite HTTP alla porta HTTPS
4. Aggiungi o imposta le intestazioni richieste alla richiesta HTTP su ciascuna dei backend configurati

I primi tre passaggi precedenti sono implementati a livello di frontend. (Abbiamo rinominato il nostro frontend come 'alltraffic' invece di 'httptraffic'.)

Figura 10:configurazione frontend per SSL

Il quarto passaggio precedente è implementato in ciascuno backend:

Figura 11:configurazione del backend per SSL

Di solito le intestazioni X-Forward-Port e X-Forward-Proto aiutano l'applicazione a costruire correttamente l'URL quando sono possibili sia richieste HTTP che HTTPS.

La terminazione di SSL sul nodo di bilanciamento del carico crea un sovraccarico di elaborazione su questo nodo (rispetto all'inoltro della richiesta crittografata ai backend). Esiste un parametro relativo all'algoritmo di crittografia sottostante utilizzato. Un valore più alto aumenta il sovraccarico di elaborazione sul nodo HAProxy. Può essere impostato nella sezione 'globale' della configurazione HAProxy:

1. tune.ssl.default-dh-param 2048

Quindi le richieste crittografate con SSL terminano al sistema di bilanciamento del carico, che instrada le richieste HTTP non crittografate ai server Web di back-end.

Figura 12:Terminazione SSL

Impostazioni firewall

Dobbiamo aprire la porta 443 sul nodo di bilanciamento del carico virtuale (in esecuzione su CentOS), eseguendo il comando:

1. iptables -A INPUT -i eth0 -p tcp –dport 443 -m state –state NEW,ESTABLISHED -j ACCEPT
2. systemctl riavvia iptables

Test

Ora proviamo ad accedere alla nostra applicazione PHP Greeter tramite un browser (Firefox), puntando all'HTTP non sicuro URL:

http:///greet.php

Anche in questo caso, Firefox ci chiederà di aggiungere un'eccezione di sicurezza, indicando che il client viene inoltrato all'URL HTTPS sicuro . Questo è indicato anche nella barra degli indirizzi del browser stesso.

Figura 13:accesso all'applicazione Web tramite SSL

Creazione di immagini e monitoraggio della macchina

Suggerimento :sono stati dedicati molti sforzi alla configurazione dell'istanza del servizio di bilanciamento del carico virtuale. È possibile salvare un'immagine macchina di questo nodo in modo da poter creare in futuro istanze di bilanciamento del carico simili utilizzandolo come modello. Su E2E Cloud, questo può essere ottenuto spegnendo prima il nodo HAProxy e poi salvando un'immagine di questo nodo dal Dashboard.

Figura 14:salvataggio dell'immagine macchina HAProxy

Figura 15:creazione dell'immagine della macchina dal nodo HAProxy

Facoltativamente, è possibile salvare anche un'immagine macchina di istanze del server Web.

Monitoraggio tramite Zabbix :Il nodo HAProxy, come qualsiasi altro nodo virtuale sul cloud E2E, può essere monitorato utilizzando Zabbix. Dovremmo sfruttare questa capacità.

Figura 16:monitoraggio dell'integrità del sistema di bilanciamento del carico

Conclusione e passaggi successivi

E2E Cloud offre nodi Virtual Load Balancer per impostare il bilanciamento del carico utilizzando HAProxy. In questi due blog abbiamo esaminato come un'installazione HAProxy su E2E Cloud può essere configurata per supportare il bilanciamento del carico round-robin per siti Web multi-applicazione semplici e di grandi dimensioni con persistenza della sessione e accesso sicuro su HTTPS.

Concluderemo questo blog prendendo nota di alcune altre considerazioni per un'implementazione di produzione:

• In primo luogo il nodo Virtual Load Balancer (e facoltativamente i nodi del server web) dovrebbero essere collegati a un dominio utilizzando le impostazioni DNS appropriate
• Di conseguenza, il certificato SSL per l'accesso sicuro all'istanza HAProxy dovrebbe essere legato allo stesso dominio
• Infine, il sistema di bilanciamento del carico non dovrebbe diventare un singolo punto di errore. Pertanto, potrebbe essere consigliata una distribuzione attiva-passiva di HAProxy.