Archivi categoria: Networking

NGINX ecco le ragioni per cui dovreste usarlo

nginx fast web servernginx (pronunciato come “engine-x”) è un web server/reverse proxy leggero ad alte prestazioni; è anche un server proxy di posta elettronica (IMAP / POP3), rilasciato sotto licenza BSD-like. Funziona su sistemi Unix, Linux, varianti di BSD, Mac OS X, Solaris e Microsoft Windows.

 

nginx fornisce rapidamente i contenuti statici con un utilizzo efficiente delle risorse di sistema. È possibile distribuire contenuti dinamici HTTP su una rete che utilizza i gestori FastCGI (ad esempio php5-fpm, php-fastcgi) per gli script, e può servire anche come un bilanciatore di carico software molto capace.

nginx utilizza un approccio asincrono basato su eventi nella gestione delle richieste in modo da ottenere prestazioni più prevedibili sotto stress, in contrasto con il modello del server HTTP Apache che usa un approccio orientato ai thread o ai processi nella gestione delle richieste.

nginx è più leggero e meno dispendioso di memoria rispetto ad Apache e già questo è un punto a favore del web server russo. Poi, nonostante sia più compatto, garantisce prestazioni migliori rispetto al concorrente, infatti con un bassissimo utilizzo di risorse, nginx garantisce tempi di risposta eccellenti anche in presenza di un numero molto elevato di connessioni concomitanti e, con un’occupazione di memoria pari a un quarto di quella pretesa da Apache, nginx è capace di garantire fino a quattro volte il numero di connessioni contemporanee gestite dal concorrente. Di fronte a questa verità, siti ad alto traffico come WordPress.com, YouTube e tanti altri non potevano non effettuare il cambio e spostarsi su nginx.

Secondo il Web Server Survey Netcraft di febbraio 2014, nginx è risultato essere il terzo server web più utilizzato in tutti i domini (15,00% dei siti esaminati) e il secondo server web più utilizzato per tutti i siti “attivi” (13,46% dei siti esaminati).

Una cosa importante da capire, comunque, è che nginx possiede un’architettura event-based ovvero, detta in modo semplice, non necessita di effettuare la creazione di tanti processi per quante richieste siano in esecuzione, ottimizzando l’uso di memoria al contrario di Apache che, in certi casi, può provocare problemi di memoria su WordPress o altri CMS. Apache usa infatti un thread per connessione, mentre nginx lavora in modo asincrono con thread non bloccanti, il che riduce l’uso di RAM ed ottimizza l’esecuzione dei processi.

Una delle caratteristiche che più colpisce di nginx è la capacità di supportare nativamente il load balancing, per cui possiamo utilizzare questa tecnica per scalare velocemente i server HTTP. Con il load balancing di nginx possiamo distribuire il traffico fra differenti server, definiti in un gruppo nel file “nginx.conf”, in questo modo, ad esempio, se in un particolare momento operativo dobbiamo aggiungere un nuovo webserver al nostro stack LAMP, possiamo semplicemente inserirlo nel gruppo di server gestito dal file nginx.conf. In seguito al reload della configurazione (nginx -s reload), nginx effettuerà le operazioni di load balancing fra tutti i server indicati nel file di configurazione, compreso l’ultimo appena inserito.

Anche l’installazione di nginx è semplicissima e si può effettuare da qualsiasi shell-bash con una sola riga di comando. Nello specifico sulle distribuzioni Ubuntu e Debian scriveremo:

apt-get install nginx

mentre per CentOS, Red Hat Linux Enterprise e Fedora digiteremo:

yum install nginx

Caratteristiche HTTP di base

  • Gestione dei file statici, file di indice, e auto-indicizzazione
  • Reverse proxy con caching
  • Bilanciamento del carico
  • Tolleranza agli errori
  • Supporto SSL
  • Supporto FastCGI con il caching
  • Server virtuali basati su nome ed IP
  • Streaming FLV
  • Streaming MP4, utilizzando il modulo streaming MP4
  • Autenticazione di accesso nelle pagine web
  • Compressione gzip
  • Capacità di gestire più di 10000 connessioni simultanee
  • Riscrittura degli URL
  • Log personalizzato
  • include server-side
  • resistente agli attacchi di Slowloris
  • WebDAV

Nel prossimo articolo inizieremo a vedere in modo dettagliato quali siano le migliori configurazioni.

Sovraccarico di rete

sovraccarico_reteCome visto nel precedente articolo “ottimizzare la connessione ad internet” spesso ci si deve destreggiare, con l’aiuto di alcuni tool ad hoc, per poter far funzionare al massimo la nostra connessione di rete. Ma come possiamo capire se tutto sta funzionando per il meglio, o meglio ancora poter capire quale applicazione stia effettivamente consumando piu’ banda.

Tuttavia conosco due utili applicazioni che possono fare al nostro caso, nethogs ed iftop.

 

La prima è Nethogs utile applicazione che monitora ogni tentativo di connessione da parte di qualsiasi software, ed è disponibile nei repository, quindi per installarla ci basterà dare il comando:

sudo apt-get install nethogs

E successivamente digitare da terminale il comando:

sudo nethogs <INTERFACCIA>

Dove al posto di INTERFACCIA inserirete  la vostra interfaccia di rete. Ad esempio la mia è la  wlan0,quindi digiterò :

sudo nethogs wlan0

Con questa applicazione dovreste cosi riuscire a capire quale applicazione si “frega” per così dire, la vostra banda; per completezza si puo’ anche usare, sempre da terminale, un comando quale :

netstat -tanupv

che elenca le connessioni tcp/udp in ascolto o stabilite nel sistema.

Per vedere invece le connessioni attive sul pc utilizzeremo il software iftop, installabile anch’esso tramite repository, e successivamente utilizzabile tramite il comando :

sudo iftop -i <INTERFACCIA>

quindi ….

sudo iftop -i wlan0

Monitorare le connessioni ed il loro utilizzo di banda non sara’ piu’ un problema…!

Ottimizzare la connessione a Internet

wondershaperCon wondershaper diventa più veloce e reattiva

Se la connessione ad Internet qualche volta sembra essere lenta nella risposta, in particolare se utilizzata contemporaneamente da più applicazioni, allora significa che siamo in presenza di un cosiddetto “collo di bottiglia”, una strozzatura nel vero senso della parola, che rallenta irrimediabilmente la velocità di connessione e di conseguenza la navigazione.

Questo avviene perché, nella maggior parte dei casi, i provider privilegiano di norma la capacità di “smaltire” le richieste di download sacrificando la reattività della rete. Per fortuna GNU/Linux permette di aggirare questi fastidiosi comportamenti, rendendo così più fluido e in certi casi anche più veloce il collegamento a Internet.

Ottenere questo risultato non è proprio immediato, per questo motivo è stato creato wondershaper. Una volta installato il tool tramite

sudo apt-get install wondershaper

bastera’ eseguirlo indicando l’interfaccia di rete utilizzata per la connessione a Internet, ad esempio: wondershaper wlan0 4096 512. La voce wlan0 indica l’interfaccia di rete attraverso la quale il vostro PC è connesso al router. Questa può essere diversa e dipende dal sistema di connessione utilizzato, ad esempio ppp0 oppure eth0. Sempre in relazione all’esempio precedente, 4096 indica la velocità di download e 512 quella di upload, in modo che sia GNU/Linux a gestire direttamente le code e non il provider, a tutto beneficio della velocità della connessione. Per eseguire un prova,che come sempre consiglio di fare su di una Virtual Machine, basta scaricare un file di grosse dimensioni e contemporaneamente lanciare un ping; i tempi di risposta risulteranno molto diversi anche diminuendo solo di poco la velocità massima di connessione, vi consiglio quindi di fare diversi test. Per avere una base di partenza il consiglio e’ quello di fare un test di velocita’ della vostra connessione ADSL tramite il link di Speedtest.

Dopo aver individuato la configurazione ottimale, bastera’ configurare lo script wondershaper per rendere le modifiche definitive ed eseguirlo automaticamente al boot (vedi sezione “approfondimenti configurazione ottimale”) , oppure si puo’ configurare nel seguente modo:

Modifiche nel file /etc/network/interfaces

iface wlan0 inet dhcp
    up /sbin/wondershaper wlan0 4096 512
    down /sbin/wondershaper remove wlan0

Se i test non dovessero essere soddisfacenti e voleste tornare alla configurazione iniziale bastera’ non modificare  lo script di wondershaper ed invece dare il seguente comando :

sudo wondershaper clear INTERFACCIA

dove ovviamente con INTERFACCIA si intende sempre l’interfaccia di rete precedentemente indicata, esempio :

sudo wondershaper clear wlan0

Approfondimenti configurazione ottimale

Il file /usr/share/doc/wondershaper/README.Debian.gz descrive più in dettaglio il metodo di configurazione consigliato dal responsabile del pacchetto. In particolare, si consiglia di misurare la velocità di caricamento e scaricamento in modo da valutare al meglio i limiti reali.

 

Twemproxy il proxy per Memcached

twemproxy2

Twemproxy (repository GitHub) è un proxy server che consente di ridurre il numero di connessioni aperte verso un server Memcached o Redis. Per cosa può essere utile questo strumento?

 

 

Le caratteristiche principali sono :

– ridurre il numero di connessioni al cache server agendo come un proxy;

– sharding di dati automatico tra più cache server;

– supporto per l’hash con diverse strategie e funzioni di hashing;

– configurabile per disabilitare i nodi caduti;

– esecuzione di istanze multiple, consentendo al client di connettersi al primo proxy server disponibile;

– pipelining e batching di richieste con risparmio di round-trip;

– configurabile per disabilitare i nodi non più funzionanti, e richiamarli successivamente, dopo un po’ di tempo;

Twemproxy è stato reso open source da Twitter (che lo ha sviluppato per le proprie esigenze) all’inizio del 2012, con il supporto a memcached, e recentemente ha aggiunto anche il supporto a Redis. Twitter fa uso estensivo dei cache server ed il sistema sul quale gira Twemproxy, per Twitter, è di dimensioni impressionanti; immaginate che i sistemisti devono gestire centinaia di cache server, che a loro volta amministrano svariati TB di dati ciascuno per oltre trenta servizi diversi, in-memory, inclusa la memorizzazione dei tweet. Parliamo di almeno due milioni di miliardi di query al giorno, ossia più di ventitré milioni di query al secondo, per un’infrastruttura che, peraltro, continua a crescere in maniera esponenziale.

Leggi anche articolo (“Ottimizzazre grazie a Memcached“)

 

Ottimizzare grazie a Memcached

theflash_memcachedOttimizzazione server dedicato grazie a MemCached

Spesso si e’ portati a credere che i meccanismi di cache siano una specie di Panacea, e che dalla loro implementazione non si debba temere alcun  problema : ovviamente non è così.
Specialmente se il tuo cloud è dedicato all’erogazione di siti/portali web con volumi importanti l’utilizzo di memcached può sicuramente aumentare le performance di quest’ultimo;  ma può anche introdurre un nuovo point of failure, uno di quelli che non ti aspetti.
Facciamo un esempio, non ti aspetteresti che un’istanza memcached possa rappresentare un collo di bottiglia !, men che meno un pool di istanze bilanciate e, cosa forse ancor più singolare, che lo possano rappresentare a livello di networking. Eppure succede!

Cos’è memcached, e come funziona?
Memcached è un sistema di caching distribuito ed ha una struttura client/server che permette di servire i dati più richiesti direttamente dalla RAM, riducendo cosi al tempo stesso il carico sul database.
Questo può essere di grande aiuto se si ha la necessità di gestire una quantità di dati davvero importante.
Sfruttare elaborazioni già effettuate: questo è il punto di forza di Memcached; infatti raggruppando la cache dei nodi crea una memoria a breve termine che serve per ottimizzare le operazioni ripetute.

Memcached è semplice ma potente. Il suo design semplice promuove un’implementazione veloce, facilità di sviluppo, e risolve molti dei problemi che ci si trova ad affrontare quando si ha a che fare con grandi cache di dati.

Il server funziona ricevendo una serie di coppie chiave-valore e mantenendole in RAM.
In genere è compito della logica applicativa (quindi della programmazione degli scripts php, ruby, phyton ecc…) decidere se effettuare un’operazione di scrittura su memcached oppure di lettura, ed e’sempre compito dell’applicazione computare un hash delle key che invia a memcached e, successivamente, inviare la coppia chiave-valore al server stesso.
Nel caso di un cluster, l’applicazione deve determinare in base all’hash quale nodo memcached contiene quale valore.

Ora, può succedere che alcune coppie chiavi-valore siano molto più utilizzate di altre, queste si definiscono in gergo “hot keys”.
Può succedere inoltre, nel caso che il sito sia molto trafficato, che i front-end web interroghino con preferenza alcune coppie chiave-valore specifiche.
Facciamo un’altro esempio: immaginiamo di dover gestire la home page di un quotidiano nazionale (a me e’ capitato).
Immaginiamo che il codice che muove quel sito interroghi memcached per evitare che, ad ogni richiesta della home page, vengano fatte delle richieste al database.
Immaginiamo infine che la home page del tuo portale riceva un grosso picco di traffico completamente inatteso (per esempio un terremoto).
Man mano che il traffico aumenta, aumentano le richieste che i front-end devono effettuare al back-end memcached per evitare di interrogare continuamente i database.
Per servire un sito di questo tipo, si sono probabilmente predisposti una mezza dozzina di front-end applicativi, o forse di più, e ciascuno di questi chiama il back-end memcache.
Man mano che il traffico da servire lato pubblico scala verso le decine di Mbit/s, il traffico verso il backend memcached aumenta con un moltiplicatore pari al numero di front-end e questo comincia a saturare la scheda di rete del memcached.
Il traffico aumenta fintanto che la scheda di rete si satura, il sistema crolla, con buona pace di ottimizzazioni lato front-end, bilanciatori di carico, e ottimizzazioni lato SQL.

Se avessimo configurato un cluster memcached alle spalle dei front-end il problema potrebbe comunque presentarsi perchè alcuni nodi del cluster potrebbero avere delle “hot-keys” un po più “hot” delle chiavi degli altri nodi.

Ora, potrebbe anche essere che i memcached contengano solo piccole porzioni di dato e quindi il traffico sulla NIC sia molto contenuto, ma se non siete stati voi ad aver scritto l’applicazione, non potrete esserne certi, quindi si dovra’ quantomeno monitorare la saturazione della NIC e l’eventuale presenza di differenti hot keys sui server.

Come uscirne fuori?
Se la situazione non si è ancora deteriorata del tutto, potreste effettuare l’analisi del traffico in uscita dalla NIC con un packet sniffer e cercare di capire quale sia la chiave “incriminata” e i dati ad essa associati.
Ma c’e’ da dire che state facendo passare qualche centinaio di Mbit/s su una NIC, un’attività del genere non deve essere una passeggiata anche solo per la mole di dati che si deve processare.
In alternativa, può venirci in aiuto uno strumento come mctop, che permette di tracciare il numero di chiamate, richieste al secondo, e l’uso della banda per ogni singolo pacchetto.
In questo modo, sara’ molto più facile individuare le key che tendono a saturare la banda ed indicare dove ai programmatori o tecnici dove devono intervenire.

Non è solo un problema lato server.
Come si puo’ immaginare, questo tipo di problemi va affrontato sia lato sistemi che lato sviluppo
In una situazione di emergenza identificare una “hot key” manualmente, potra’ anche andare bene, ma il punto è che dal lato sviluppo applicativo dovranno mettere mano al codice ed essere in grado di effettuare, per quanto possibile, questo tipo di operazione in autonomia migliorando le fasi di test e di pre produzione.
Diventa cosi’ davvero opportuno avere nella propria infrastruttura, dei sistemi di monitoraggio e di alert, che possano segnalare per tempo gli status ed i possibili rischi di saturazione lato NIC.