Archivi tag: load balancing

NGROK – reverse proxy server cross-platform

ngrok mostrare un sito in locale

Ngrok Pubblica il tuo sito in localhost

Lo sviluppo di siti e di Webb Application e’, al giorno d’oggi, uno dei core business piu’ importanti per la maggior parte delle aziende in tutto il mondo, motivo per cui sono nati una grande quantita’ di tool per agevolare i web developer durante tutte le operazioni di sviluppo, test e produzione.

Molto spesso capita che non si abbia il tempo o anche il budget per gestire piu’ ambienti di sviluppo, cosi ci si riduce per avere tutto il proprio ambiente [sviluppo / test / pre produzione] soltanto sul proprio pc.

Come fare quindi se c’e’ bisogno di mostrare l’avanzamento del lavoro al cliente senza dover prima creare e/o aggiornare gli altri ambienti di test/pre-produzione??? …. e’ per aiutare in questa pressante fase che e’ nato un tool come ngrok.

Ngrok e’ un reverse proxy server con cui e’ possibile rendere “pubblico” un server locale, anche se e’ collocato dietro un NAT od un Firewall, il tutto tramite secure tunnel. Quindi attraverso Ngrok si potra’ implementare un personal cloud service direttamente dalla propria postazione di lavoro realizzando cosi uno stack LAMP/LEMP

 

INSTALLAZIONE

mkdir ngrok
cd ngrok/
wget -c https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-amd64.zip
unzip ngrok-stable-linux-amd64.zip

Dopo aver installato il pacchetto possiamo fare una prova, se ad esempio usate come web server Apache, potete farlo in questo modo;

sudo nano /var/www/html/index.html

<!DOCTYPE html> <html> <body> <h1>Prova</h1> <p>Test di Ngrock.</p> </body> </html>

Salviamo il file e ora possiamo avviare il tool puntandolo sulla porta su cui abbiamo in ascolto il nostro Web server:

ngrok http 80

Una volta lanciato il comando ci apparira’ qualcosa di simile:

Session Status online Session Expires 7 hours, 53 minutes
Version 2.2.8 Region United States (us)
Web Interface http://127.0.0.1:4040
Forwarding http://44c9afca.ngrok.io -> localhost:80
Forwarding https://44c9afca.ngrok.io -> localhost:80

Una volta avviato possiamo dunque iniziare ad usarlo anche tramite la comoda interfaccia Web:

http://localhost:4040

ngrok localhost

Tornando alla descrizione del Tunnel appena creato, le voci a cui dobbiamo fare caso sono:

  • Web Interface: tramite questo indirizzo potrai accedere ad un’interfaccia web dove puoi monitorare tutte le attività associate all’url che hai appena creato. Questo vuol dire che potrai vedere quanti utenti si stanno collegando ed altre informazioni.
  • Forwarding: questo è il link che dovrai fornire al tuo cliente. Hai entrambe le versioni, sia http che https. Lavorando in locale probabilmente userai quasi sempre l’http.
  • HTTP Requests: In questa sezione vedrai in tempo reale tutte le richieste http che vengono fatte tramite il tuo link. Ti è utile per capire se qualcuno sta guardando il sito in un dato momento.

Quindi dando al proprio cliente il link http://44c9afca.ngrok.io  quest’ultimo avra’ accesso alla root web del localhost

Questo vuol dire che se stai utilizzando MAMP o XAMPP verrà servito il file index.php all’interno della tua cartella /htdocs

Se invece utilizzi WAMP su Windows il tuo tunnel porterà gli utenti alla index.php della cartella www

Per coloro che utilizzano un Virtual Host per gestire i tuoi progetti la procedura e’
leggermente diversa ma pur sempre semplice; nella pratica bastera’ aggiungere un solo
parametro, come nell’esempio seguente:

ngrok http -host-header=miosito.dev 80

dove ovviamente al posto di “miosito.dev” metterete l’indirizzo del vostro in locale. ** WordPress per coloro che invece usano la piattaforma di WordPress si dovranno applicare altri accorgimenti per far in modo che il vostro cliente veda correttamente il sito. Questo perche’ tutti gli url che creati da WordPress sono assoluti ovvero mostrano per esteso l’indirizzo di un determinato documento. Per poter effettuare questo tipo di modifica consiglio di utilizzare un comodo tool come Relative URL , un tool che fa gia parte dei plugin consigliati da WordPress, con il quale sara’ possibile modificare URL da qualcosa come questo (esempio):

http://localhost:8080/wp/2012/09/01/hello-world/

in qualcos’altro come questo:

/wp/2012/09/01/hello-world/

Una volta effettuate tutte le modifiche del caso bisognera’ aggiornare il file wp-config.php
inserendo, prima della riga “/* i parametri dei re indirizzamenti, qualcosa del tipo:

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);

PS:Ricordatevi di disinstallare il plugin e rimuovere le righe di codice dal file wp-config.php quando metterete il sito online.

Le configurazioni possibili con Ngrok sono davvero svariate e potete trovare tutto cio che non e’ stato contemplato in questo articolo, direttamente sul sito del progetto NGROK

MaxScale – un proxy per i Database MariaDB e MySQL

Maxscale - Proxy per MariaDB & Mysql

Maxscale – Proxy per MariaDB & Mysql

MaxScale è il nuovo database proxy server open source sviluppato da MariaDB Corporation Ab.

MaxScale nasce con un concetto di proxy alla base, ma con una filosofia ed un approccio “database centrico” ed una architettura a plugin estremamente configurabile.

Per chi si fosse perso i precedenti articoli riguardanti i Proxy Server, ricordiamo che, un proxy, è un server che fa da intermediario in una connessione, ossia esso riceve le richieste da un client e le reindirizza verso altri server che sono i destinatari delle richieste. In altre parole un proxy funziona come un centralinista: riceve la chiamata del cliente  e la gira al primo operatore libero.
Per capire meglio cosa e’ in grado fare elenchiamo alcune delle sue funzionalità principali quali:

  • controllo della disponibilità del Database (monitoring)
  • load balancing
  • analisi della query in ingresso per capire se indirizzarla su una specifica tipologia di server

tutto questo, e molto altro ancora.

MaxScale si può inserire in modo trasparente tra l’applicativo e il server MySQL, esattamente come fa un proxy web tra il nostro browser e il sito che stiamo cercando di visitare.
Grazie ad un proxy è possibile avere:

  • Ridondanza: usando più di un database dietro al proxy, poiche’ un solo server non fornisce l’affidabilità e l’alta disponibilità in caso di down di una macchina.
  • Diminuizione dei costi di infrastruttura: perché generalmente due server piccoli sono meno costosi che un unico server molto performante.

Per migliorare la spiegazione ora vedremo due tipi di database proxy server:

I proxy di livello trasporto come HAProxy (di cui abbiamo piu’ volte parlato in altri articoli).
I proxy di livello applicativo come MaxScale
HAProxy: un proxy efficiente, rapido e funzionale

Fino ad oggi tra i proxy più usati in ambito MySQL Cluster è l’HAProxy che lavora ad un livello più basso (livello 4: trasporto). HAproxy pero’ non conosce nulla di MySQL e si occupa quindi soltanto di bilanciare le connessioni tra i server. Haproxy e’ molto veloce, leggero ed efficente, tuttavia questo tipo di bilanciamento è fatto senza che il proxy sia a conoscenza di cosa sta smistando. Questo rende il sistema meno efficente poiché un server può ricevere molte richieste pesanti, mentre altri server possono essere scarichi. Quindi l’HAProxy non è la scelta vincente in tutti i casi.

MaxScale: e’ un proxy che in configurazioni di questo tipo può fare cose incredibili

MaxScale lavora a livello più alto (livello 7: applicativo) e, monitorando i server riesce a capire cosa sta succedendo all’interno dell’infrastruttura. Conoscendo il protocollo MySQL può intervenire manipolando il traffico tra client e server. Ecco alcune delle sue principali funzionalità:

  • Filtro delle query al database
  • Gestione del routing: instradamento delle richieste a uno o più database server
  • Modifica delle query al volo prima che raggiungano il database
  • Possibilità di nascondere la struttura interna dell’infrastruttura lasciando un singolo punto d’accesso.
  • Alta affidabilità e scalabilità del sistema
  • Possibilità di spostare un database dal server locale ad un server esterno senza modificare la configurazione delle applicazioni
  • Divide automaticamente le scritture sul server MASTER e le letture su uno o più database SLAVE.
  • MaxScale può fornire un Load Balacing delle connessioni senza bisogno di utilizzare applicazioni o CMS che prevedano questa funzionalità. Questo significa che CMS come Joomla! o WordPress possono trarre i benefici usando una replicazione Master/Slave per rendere scalabile il proprio sito.

Caratteristiche di MaxScale

Il punto di forza di MaxScale è sicuramente la sua modularità che permette una notevole libertà adattandosi a molti casi d’uso. MaxScale è :

  • Modulare: un sistema di moduli ne definisce le funzionalità
  • Estendibile: è possibile applicare più filtri anche in cascata
  • Flessibile: i moduli e i filtri possono essere aggiunti dinamicamente

I moduli base di MaxScale

Ecco i 5 moduli che costituiscono il cuore di MaxScale:

  • Protocol: da la possibilità di utilizzare più protocolli es. MySQL client, http, telnet;
    I client si connettono a MaxScale anziché al database MySQL senza accorgersi della differenza. Possono usare le stesse librerie di connessione utilizzate fino ad ora: es. MySQL client o MariaDB client
  • Authentication: il sistema di autenticazione permette ai client di accedere a MaxScale usando le credenziali presenti sui server di Backend;
    MaxScale non ha un sistema di autenticazione o un database di utenti. Vengono utilizzati gli stessi utenti presenti sui database di backend, caricati all’avvio dell’applicazione
  • Monitor: legge la configurazione dello stato del sistema direttamente dai server di backend;
    Viene utilizzato per capire in ogni momento lo stato di tutti i database di backend collegati a MaxScale. In questo modo è possibile sapere qual’è il server Master e quanti Slave stanno replicando correttamentei dati. Il monitor può essere utilizzato per controllare un Galera Cluster.
  • Router: smista le connessioni a uno o più database di backend;
    Dirige il traffico dal client ai server utilizzando una regola specifica denominata connection routing
  • Filter e logging: i filtri permettono di modificare le query oppure di scrivere un file di log con tutte le richieste e le risposte ricevute;
    Tra i più potenti strumenti messi a disposizione di MaxScale ci sono sicuramente i filtri che permettono di effettuare operazioni avanzate sulle query senza modificare il comportamento dell’applicazione, 1) processando query SQL e risultati, 2) utilizzando una semplice regex, 3)  analizzando, modificando o rifiutando le query, 4) mettendo più filtri in cascata

Non resta che testare di persona, magari con un ambiente ad hoc con Docker e Vagrant.

 

Load Balancing Systems

Load Balancing Systems

Load Balancing Systems

Ormai Internet e’ parte della vita di milioni di persone e’ lo sara’ sempre di piu’. Sono lontanissimi i tempi dei siti statici con qualche migliaio di accessi al mese o poco piu’, oggi quasi ogni tipologia di servizio offerto dalle aziende o dalla pubblica amministrazione, ha la gestione su di un portale Internet, dunque la gestione degli accessi, al secondo, e’ diventata la discriminante per valutare un ottimo servizio da uno scadente; si pensi alla fantastica operabilita’ di portali come Facebook, Twitter o Gmail, solo per citarne alcuni, che permettono e gesticono l’accesso di milioni di utenti 24h senza praticamente disservizi o rallentamenti .

Ora dietro c’e’ una mole di lavoro ingegneristico del software, dell’hardware, dell’architettura migliore, del DB piu’ performante etc ma, prima che tutto cio’ inizi ad operare l’utente dev’essere, per prima cosa, agganciato ed instradato verso il server (fisico o virtuale che sia) che accogliera’ le sue operazioni (acquisti , home banking, pagamento bollette…), tutto cio verra’ fatto dall’infrastruttura di Load Balancing, che puo’ essere un fiore all’occhiello dell’azienda oppure trasformarsi in un Mega Point of Failure, quindi vediamo di spiegare meglio che cosa sono i Load Balancer e come operano.

Letteralmente “Load Balancing” significa bilanciare il carico di lavoro su più nodi dell’architettura.Viene spesso confuso come tecnica per ottenere l’ High Availability (HA), ma pur condividendone alcuni mezzi, ha dei fini totalmente diversi.

In pratica il “bilanciatore di carico”, per chi non lo sapesse, è quel componente (di frontend) che prende in carico le connessioni in ingresso (quelle degli utenti per gli accessi POP/IMAP ad esempio) e le smista verso i server (backend) veri e propri che erogano i servizi (webserver, application server..). E’ sempre il bilanciatore che interviene quando un server di backend viene rimosso dal cluster, per manutenzione o interruzione, a dirottare il traffico verso i server rimasti attivi.

Uno degli errori più comuni per effettuare il Load Balancing è quello di prendere come riferimento il Load dei server, scrivendo sulle console delle nostre macchine il comando “uptime”, riceveremo come risposta un dato come questo

16:49 up 453 days, 12:17, 56 users, load averages: 0,59 0,46 0,47

dove gli ultimi tre numeri identificano il carico del server negli ultimi 1, 5 e 15 minuti rispettivamente.

Immaginiamo ora di aggiungere ulteriori nodi quando il carico di un server negli ultimi 5 minuti superera’ il valore di 1,5. La nuova macchina aggiunta partirà con un carico pressoché a 0 e verrà invasa da centinaia di richieste fino a rischiarne la saturazione, e dovremo inoltre attendere altri 5 minuti prima che un nuovo bilanciamento possa intervenire.

Peccato che prima di quei 5 minuti il nostro nuovo server farà parecchia fatica a rispondere a tutte queste richieste, perdendo cosi di fatto parecchi utenti a causa di errori di pagina non trovata oppure di time out per la troppa attesa etc….facendo perdere parecchi soldi all’azienda. Questo tipo di problema è chiamato “staleness”, e può essere aggirato con altre tecniche che non si basano su una metrica numerica.

Come implementare il load balancing:

Come scegliere quindi su quale server dirigere una richiesta?

La tecnica di Load Balaincing più semplice è detta Round Robin, il suo principio e’ che ogni richiesta che viene effettuata viene smistata su un server differente, a rotazione.

In un cluster di 100 macchine, 100 richieste verranno distribuite su tutti 100 i servers a rotazione dal primo all’ultimo. Questa è una tecnica molto semplice da usare, e inclusa ad esempio già in Apache, ma si porta il limite che se un server è sovraccarico non avrà mail il tempo rientrare in una situazione di normalità che subito dopo dovra’ gestire un’ennesima richiesta e cosi via.

La tecnica “Random” ci offre un modo elegante per distribuire le richieste; in pratica non si basa su nessuna metrica, ma per i puristi resta comunque fuori controllo poiche’ offre comunque la possibilià (anche se randomica) di continuare a girare richieste verso server già sovraccarichi.

Una variante della tecnica “Random” è la “Weighted Random“, dove viene introdotta la variabile “potenza del server”, ossia i server più potenti avranno una possibilià più alta di ricevere richieste, rispetto ad hardware meno performante.

La tecnica “Predictive” invece è una variante del “Round Robin”, in questa metodologia vengono introdotte alcune variabili al normale ciclo per permettere di avere una ripartizione più accurata saltando ad esempio i server già troppo carichi. E’ una tecnica implementata a livello di Load Balancers hardware, e i produttori sono di solito restii a documentare gli algoritmi “Predictive”.

Resta scontato che, una volta scelta la tecnica preferita, dovremo prendere in considerazione anche altri problemi. Ora, ad esempio, proviamo ad uscire dal ragionamento di un singolo Load Balancer, e proviamo ad aumentare la posta ed a pensare in modalita’ High Availability con almeno due bilanciatori dove il lavoro del primo verrà supportato o, in caso di problemi, preso in carico dal secondo, che redistribuirà il traffico secondo una sua logica.

Per l’utente finale (colui che naviga dal suo browser) non cambierà nulla, infatti il browser si connetterà ad un IP dove non ci sarà un webserver ad attenderlo, ma il Load Balancer. Il Load Balancer girerà quindi, seguendo il nostro metodo di allocazione scelto, la richiesta ad un webserver scarico pronto a risponderci.

Cosa fondamentale e’ che i due, o più load balancer, devono essere in grado di parlarsi e condividere informazioni, così che entrambi sapranno che un dato server è da considerare sovraccarico o che un altro server sta per uscire dal pool.

Come scegliere il giusto load balancing

Scegliere il metodo di load balancing, e lo strumento col quale applicarlo, necessitano quindi di studi specifici sul tipo di traffico, e sull’architettura dell’applicazione che si vuole bilanciare, soprattutto quando entrano in gioco variabili come SSL.

L’SSL è basato sulla generazione di un certificato legato ad un IP, e in uno scenario dove abbiamo diversi IP virtuali che rigirano il traffico verso altri “nattati” diventa quantomeno improbabile poter gestire in modo corretto il certificato. Questo proprio perche’ il certificato è usato per validare la reale identità del server web, quindi mettendoci in mezzo un load balancer otterremmo un “man in the middle” che invalidera’ la connessione SSL.

L’unico modo diventa spostare la connessione SSL solo tra browser e Load balancer, inserendo il certificato sul VIP del sistema di Load Balancing e lasciando il traffico dopo il Load balancer in chiaro (anche se è sempre possibile attraverso una VPN ottenere maggiore sicurezza sui canali di comunicazione).

In sostanza, il Load balancing è un argomento semplice da capire, e probabilmente ancora più semplice da ottenere anche con hardware non dedicato, grazie alle diverse opportunità che il mondo Open Source ci regala.

Come sempre, il grosso del problema è strutturare l’applicazione nel suo complesso, incastrando i vari elementi affinché tutto il flusso dei dati sia ottimale.

La scelta del bilanciatore non e’ facile, ce ne sono di diversi tipi, sia hardware che software e, molte volte, la loro bonta’ non dipende dal prezzo che lo pagate ma dalla giusta scelta che farete a monte, di ottimizzazione del servizio che dovete erogare. Possiamo dire che molto spesso, in ambito Opensource la scelta ricade su LVS, HAProxy, Pound…, mentre in ambiti piu’ istituzionali (Banche, Assicurazioni etc) la scelta spesso ricade su F5, Citrix, Radware….

Personalmente sono un sostenitore di LVS, che ho usato spesso in grossi progetti, ma vediamo quali sono i suoi punti di forza confrontandolo con l’altro ottimo prodotto Open HAProxy.

LVS lavora in kernel-space (disponibile quindi solo per Linux) il che lo rende estremamente leggero e veloce, anche se limitato in termini di funzionalità. Haproxy è invece un software che gira in user-space, sicuramente più portabile (gira praticamente su qualsiasi Linux/Unix) ma anche più costoso in termini di risorse.

Per darvi un idea di quante poche risorse usa LVS, considerate che ogni connessione attiva occupa solo 128 bytes di memoria (nella tabella dove queste vengono memorizzate). Con circa 4GB di RAM sarete in grado di smistare qualcosa tipo 500.000 connessioni simultanee.

LVS lavora al layer 4 (vedi Open Systems Interconnection), mentre HAProxy lavora al layer 7 della pila OSI. Se questo da una parte è un vantaggio per haproxy, che può ispezionare anche il contenuto del pacchetto, di fatto si traduce in un maggiore carico a livello di CPU e quindi minore scalabilità.  In un bilanciatore di carico con LVS il carico del server sarà quasi sempre pari a 0.00, mentre con haproxy si manterrà intorno allo 0.50.

Sempre con LVS è possibile ottimizzare il consumo di banda dei singoli server che compongono il cluster. Se configurato in modalità “Direct Routing” (o LVS-TUN) il bilanciatore si farà carico solo del traffico in ingresso mentre saranno i singoli server di backend ad inviare il traffico di risposta ai client remoti. Con haproxy (o LVS configurato come NAT) tutto il traffico IN/OUT passa dal bilanciatore il che lo tiene maggiormente sotto stress e vi constringe a dimensionarlo in modo da poter sostenere un traffico di rete pari alla somma totale del traffico diretta verso l’intero cluster.

Non ultimo LVS puo’ vantare il tool ipvsadm, questo ottimo tool aggiorna la tabella d’instradamento IPVS nel kernel. Ipvsadm consente di modificare la configurazione di LVS aggiungendo e rimuovendo servizi, modificando la modalita’ di forwarding, paradigmi di bilanciamento, ecc. Il pacchetto ipvsadm non ha interfacce grafiche e segue il principio unix, fare una cosa sola e farla bene, quindi risponde al solo compito di avere uno strumento per il bilanciamento a livello 4.

Con ipvsadm è possibile selezionare un metodo per passare i pacchetti dal server LVS ai real server dove gira il servizio, i metodi principali sono:

LVS-DR (direct routing) dove il MAC addresses nel pacchetto è cambiato ed il pacchetto indirizzatto verso il real server
LVS-NAT basato sul network address translation (NAT)
LVS-TUN (tunneling) where the packet is IPIP encapsulated and forwarded to the realserver.

Praticamente un bilanciatore di carico con LVS lo potete accendere, configurare e dimenticarvelo per anni.

Catturare il traffico di rete

redirectRedirect fai da te

Molte volte vi capitera’ (ed a me e’ capitato piu’ volte) di aver bisogno di gestire il traffico di rete ottimizzandolo, filtrandolo e redirezionandolo.
Si pensi, ad esempio, ai test di sviluppo effettuati sulle molte VM in cui si deve tenere conto della quantita’ di Server interessati e del carico di rete da gestire bilanciando quest’ultimo e gestendo le porte interessate.

In questo articolo illustrero’ alcuni dei migliori tra quelli da me usati in ambito OpenSource sono, Rinetd, LVS e Pound, ma l’elenco potrebbe ancora allungarsi, magari per un seguito.

PARTIAMO

rinetd

E’ il piu’ semplice dei tre, dunque partiremo da questo; esso permette di ridirigere una destinazione TCP, definita attraverso una coppia <indirizzo-ip>:<numero-di-porta>, presso un’altra coppia di questi valori. Lo scopo di questo può essere semplicemente quello di dirigere una porta locale verso un’altra porta locale, oppure si può arrivare a intercettare il traffico IP che attraversa un router in modo da ridirigere alcune coppie di indirizzi e porte presso altre destinazioni.

Tutto è composto semplicemente da un daemon, rinetd, che si avvale di un file di configurazione, /etc/rinetd.conf, nel quale si indicano semplicemente le ridirezioni da applicare.

La presenza in funzione di rinetd è incompatibile con altri daemon che stanno in ascolto delle stesse porte che devono essere ridirette, anche se queste sono intese appartenere a host differenti.

Il programma rinetd è il demone che si occupa di ridirigere il traffico TCP in base a quanto contenuto nel file di configurazione /etc/rinetd.conf
E' sufficiente avviarlo e, se il file di configurazione risultera'corretto, iniziare subito a lavorarci. All'avvio, dopo aver letto la configurazione, rinetd deve poter stare in ascolto dell'indirizzo da ridirigere e della porta relativa; qualunque sia l'indirizzo in questione, è necessario che non ci sia già un programma locale che fa la stessa cosa su quella stessa porta; per esempio, non si può tentare di ridirigere il servizio HTTP di un indirizzo qualunque, se questo è presente localmente.

Un esempio di configurazione del file rinetd.conf dovrebbe essere sufficiente a chiarire le idee su questo file. Supponiamo di voler dirottare il traffico diretto verso l’indirizzo IP 10.11.12.13 alla porta 80, in modo che questo vada verso l’indirizzo IP 192.168.1.7, alla porta 80.

120.121.122.123 80 192.168.1.7 80

L’indirizzo da ridirigere, può appartenere a un’interfaccia del nodo presso cui si trova in funzione il demone rinetd,
oppure no, purché i pacchetti diretti a tale indirizzo transitino attraverso il nodo che attua la ridirezione.
Se si vuole apprendere il funzionamento di rinetd senza disporre di una rete vera e propria, basta una direttiva di configurazione simile a quella seguente:

localhost 8888 localhost html

In questo modo, la porta locale 8888 viene ridiretta sulla porta del servizio HTTP (80). Se il servizio HTTP è attivo, si può verificare la ridirezione con un programma di navigazione qualunque, puntando all’URL

http://localhost:8888

Rispetto ai prossimi due tool rinetd non e’ in grado di fungere anche come LoadBalancer.

ipvsadm

Questo servizio aggiorna la tabella d’instradamento IPVS nel kernel. Il demone lvs imposta e gestisce Load Balancer Add-On richiamando ipvsadm per aggiungere, modificare e cancellare le voci all’interno della tabella d’instradamento IPVS. Inoltre ipvsadm fa parte del paccheto LVS  che è una soluzione di bilanciamento del carico avanzato per sistemi Linux.
Si tratta di un progetto open source avviato da Wensong Zhang nel lontano 1998. La missione del progetto è di costruire un server ad alte prestazioni e ad alta disponibilità per Linux utilizzando tecnologie di clustering, offrendo una buona scalabilità, affidabilità e facilità di manutenzione. L’opera principale del progetto LVS è ora quello di sviluppare un software avanzato di bilanciamento del carico IP (IPVS), ed un software di bilanciamento a livello dell’applicazione (KTCPVS), ed i componenti di gestione dei cluster.

Ipvs in pratica

IPVS (IP Virtual Server) implementa un bilanciatore di carico a livello Layer 4 della rete. IPVS in esecuzione su un host si comporta come un sistema di bilanciamento del carico di fronte ad un insieme di server reali in cluster, può indirizzare le richieste per servizi basati si TCP/UDP ai veri server, e fa apparire i servizi dei server reali come un unico servizio virtuale su un unico indirizzo IP.

La componente IPVS è presente in tutti i recenti Kernel, per installare la componente in user-space utilizzate il vostro gestore di pacchetti, ad esempio in Ubuntu:

aptitude install ipvsadm

a questo punto si può creare uno script da far avviare al boot. Io di solito inserisco i comandi all’interno del file
/etc/rc.local.

Prima di tutto dobbiamo resettare l’attuale configurazione con il comando:
ipvsadm -C
Dopodiché iniziamo a dare le regole con i comandi come nell’esempio qui sotto in cui diciamo che le chiamate TCP (parametro -t) all’indirizzo 192.168.10.100 sulla porta 5060 (quella per il protocollo SIP) debbano essere inoltrate alla stessa porta dell’indirizzo 192.168.10.250.  Per reindirizzare una chiamata UDP sostituire il -t con -u.
ipvsadm -A -t 192.168.10.100:5060 -s rr

ipvsadm -a -t 192.168.10.100:5060 -r 192.168.10.250:5060 -m

Naturalmente è possibile catturare il traffico su una porta e inoltrarla ad un’altra con un comando tipo questo:
ipvsadm -A -t 192.168.10.100:88 -s rr
ipvsadm -a -t 192.168.10.100:88 -r 192.168.10.250:80 -m
In questo caso non abbiamo fatto altro che prendere le chiamate alla porta 88 dell’indirizzo 192.168.10.100 e rinviarle al server web dell’IP 192.168.10.250 sulla normale porta 80

Metodi di bilanciamento utilizzati da LVS

In caso si desideri testare il funzionamento di LVS senza la necessita’ di monitorare i servizi e possibile aggiungere e rimuovere nodi con il comando ipvsadm:

ipvsadm -C
ipvsadm -A -t 10.2.1.164:8080 -s lc
ipvsadm -a -t 10.2.1.164:8080 -r 10.2.1.166 -g
ipvsadm -a -t 10.2.1.164:8080 -r 10.2.1.165 -g

Le opzioni utilizzate nelle linee di comando di ipvsadm per l’esempio riportato sono le seguenti:

– -C, –clear: cancella la tabella del virtual server.
– -A, –add-service: crea un servizio virtuale.
– -a, –add-server: aggiunge un nodo ad un servizio virtuale.
– -t, –tcp-service: specifica indirizzo ip e numero di porta tcp del servizio virtuale.
– -s, –scheduler: specifica l’algoritmo di bilanciamento
– -r, –real-server: specifica l’indirizzo ip del nodo reale
– -g, –gatewaying: indica il metodo di forwarding direct routing (LVS-DR)

** algoritmi per il bilanciamento che possiamo usare con LVS.

Statici:

– Round Robin

– Weighted Round Robin

– Destination Hashing

– Source Hashing

Dinamici:

– Least-Connection

– Weighted least-connection

– Never queue

– Locality-based least-connection

– Locality-based least-connection with replication scheduling

– Shortest expected delay

pound

Pound è un proxy server di bilanciamento del carico inverso. Accetta richieste da HTTP / HTTPS clienti e li distribuisce a uno o più server web. Le richieste HTTPS vengono decifrati e passati al back-end come semplice protocollo HTTP.

Se più di un server back-end è definita, Pound sceglie uno di loro a caso, sulla base delle priorità definite. Per impostazione predefinita, Pound tiene traccia di associazioni tra client e server back-end (sessioni).

General Principles

In generale, Pound ha bisogno di tre tipi di oggetti definiti, al fine di funzione: ascoltatori , i servizi e back-end .

Ascoltatori
Un ascoltatore è una definizione di come Pound riceve le richieste dai client (browser). Due tipi di ascoltatori può essere definito: normale connessione HTTP ascoltatori e HTTPS (HTTP su SSL / TLS) ascoltatori . Per lo meno un ascoltatore deve definire l’indirizzo e la porta per l’ascolto su, con ulteriori requisiti per HTTPS ascoltatori .

Servizi
Un servizio è la definizione di come le domande trovano risposta. Il servizio può essere definito all’interno di un ascoltatore o al livello superiore (globale). Quando viene ricevuta una richiesta Pound tenta di far corrispondere a ciascun servizio , a sua volta, a partire dai servizi definiti nel ascoltatore stesso e, se necessario, di proseguire con l’ servizi definiti a livello globale. I servizi possono definire le proprie condizioni al quale le domande si può rispondere: in genere si tratta certo URL (solo foto, o un certo percorso) o intestazioni specifiche (come ad esempio l’intestazione Host). Un servizio può anche definire una sessione meccanismo: se definito le richieste future da un determinato cliente sarà sempre la stessa risposta da parte di back-end .

Back-end
Il back-end sono i server reale per il contenuto richiesto. Di per sé, Pound fornisce nessuna risposta – tutti i contenuti devono essere ricevuti da un vero e proprio “web server”. Il back-end definisce come il server dovrebbe essere contattato.

Tre tipi di back-end può essere definito: un “regolare” back-end che riceve le richieste e le risposte restituisce, un “redirect” back-end in questo caso, Pound risponde con una risposta redirect, senza l’accesso a qualsiasi back-end a tutti , o una “emergenza” back-end che sarà usato solo se tutti gli altri backend sono “morti”.

Multiple back-end può essere definito all’interno di un servizio , nel qual caso Pound sarà bilanciamento del carico tra i disponibili back-end .

Se un back-end non riesce a rispondere, sarà considerato “morto”, nel qual caso Pound si ferma l’invio di richieste ad esso. Dead indietro _ e NDS sono periodicamente controllate per la disponibilità, e una volta che rispondono ancora sono “resurected” e le richieste sono inviati di nuovo la loro strada. Se non back-end sono disponibili (nessuno è stato definito, o sono tutti “morti”), allora Pound risponderà con “503 Servizio non disponibile”, senza verificare ulteriori servizi .

Il collegamento tra Pound e il back end- è sempre via HTTP, a prescindere dal protocollo utilizzato tra Pound e il cliente.

Installazione 

sudo apt-get install pound

La gestione completa del servizio avviene tramite la configurazione del file /etc/pound/pound.cfg
Esempio 1:

Semplice configurazione HTTP Proxy
Supponiamo di forwardare le richieste http che arrivano dall”IP pubblico 202.54.10.5 all’IP sulla LAN 192.168.1.5 su cui è configurato un web server Apache sulla porta 8080.
Editiamo il file di configurazione di pound di una distro Debian/Ubuntu:

vim /etc/pound/pound.cfg

Questo è l’aspetto del file:

ListenHTTP
Address  202.54.10.5
Port          80
Service
BackEnd
Address  192.168.1.5
Port           8080
End
End
End

Salvare e chiudere il file e restartare Pound:

/etc/init.d/pound restart

Esempio 2
Semplice configurazione HTTP & HTTPS Proxy
In questo esempio vediamo come “proxare” una richiesta http e https dallo stesso IP pubblico 202.54.10.5 a due web server 192.168.1.5 e 192.168.1.6, entrambi sulla porta 80:

ListenHTTP
Address  202.54.10.5
Port          80
End

ListenHTTPs
Address   202.54.10.5
Port           443
Cert           “/etc/ssl/local.server.pem” -–>percorso certificato ssl
End

Service
BackEnd
Address     192.168.1.5
Port              80
Priority       1
Backend
Address     192.168.1.6
Port              80
Priority       3
End
End

Salviamo il file di configurazione e restartiamo pound.

In questo esempio le richieste alla porta 80 all’ ip 202.54.10.5  vengono inoltrate alla porta 80 del webserver 192.168.1.5, mentre le richieste alla porta 443 dall’ ip 202.54.10.5 vengono inoltrate alla porta 80 del web server 192.168.1.6  e in questo caso pound gestisce il certificato ssl, che è possibile generarsi senza alcuna modifica nel backend del web server, che continua a gestire chiamate in http.

PS: e’ possibile inoltre impostare una priorità di inoltro del traffico differente, nel caso si disponga di più server web, cosi’ come indicato dalla voce “Priority” presente nella configurazione del secondo esempio; minore è la cifra, maggiore sarà la priorità assegnata al server.

Buon divertimento !