GiBiLamp 8 – Testare i limiti del server

Terminiamo la nostra serie dedicata a GiBiLamp mostrando come testare i limiti e prevedere i problemi del nostro server web prima di metterlo in produzione.

E’ il momento dei test

Prima di lanciare il nostro sistema nel mucchio, ovvero metterlo in produzione, è bene effettuare dei test per capire fino a che livello di carico la nostra macchina risponde decentemente alle richieste dei nostri clienti.

Un utile comando per testare ciò è il comando ab (Apache http server Benchmarking tool) fornito da apache. Per una esaustiva guida relativa a questo comando vale la pena dare un’occhiata al man oppure all’indirizzo web http://httpd.apache.org/docs/2.2/programs/ab.html.

Per esempio lanciando da una qualsiasi postazione il comando

ab -n [numero di richieste] -c [max contemporanee] [url]

ci verrà fornito un ottimo report con i dati riguardanti i tempi di risposta di ogni richiesta. In combinazione possiamo anche verificare con cacti il livello di saturazione di risorse a cui siamo arrivati.

Sapere fino a che punto il nostro server è efficace è molto importante sia per offrire un buon servizio sia per programmare cosa serve al nostro sistema in termini di risorse hardware (e quindi economiche) per reggere un certo carico preventivato.

E’ sempre bene lasciare il nostro server su carichi medi inferiori al 50% per quanto riguarda le risorse primarie di sistema, ovvero CPU e RAM. Infatti i server web sono spesso “vittime” di inondazioni di richieste improvvise, e, se abbiamo un sistema già abbondantemente carico di norma, un picco di richieste lo metterebbe a terra.

Ovviamente, come ho già precisato durante la fase di introduzione è anche inutile esagerare, e soprattutto sbilanciare un server. Per esempio un server web configurato come fin qui espresso, equipaggiato con un processore Quad Core da 2.2 GHZ e 16 GB di RAM è completamente “sbilanciato”, con il processore al 100% arriveremmo si e no ad utilizzare 4/5 GB di RAM.

Problemi reali

L’informatica è la scienza dell’incertezza, purtroppo non esistono assiomi che garantiscono il corretto funzionamento e/o l’infallibilità di un sistema.

Ci sono troppe componenti in gioco che concorrono al fine di realizzare una infrastruttura informatica, web server incluso. Potrebbe infatti capitare che due macchine apparentemente identiche abbiano performance molto diverse a pari livello di carico, vuoi per piccole differenze hardware o per differenti configurazioni a livello applicativo.

E’ sempre bene quindi tenere in considerazione delle installazioni e dei modi di manutenzione standard per i nostri sistemi, anche se certe volte questo potrebbe riservarci della piacevoli o spiacevoli sorprese.

Di seguito analizzerò dei casi di errori/fallimenti che potrebbero accadere durante il tempo di vita di un web server.

Disastri ed operazioni di ripristino

La cosa peggiore che possa capitare al nostro server, direi anche una delle più remote è che vada distrutto fisicamente o logicamente. Per “distrutto” intendo che non sia più possibile ripristinare alcunché se non cambiando hardware o reinstallando il sistema.

In questo caso è vitale avere un backup, che sia in grado di salvaguardare:

• file di configurazione del web server
• database Mysql
• file di log del web server
• filesystem relativi ai nostri siti

Se abbiamo a disposizione una sola macchina fisica, il ripristino di un sistema fallito può richiedere anche più di una giornata di tempo, e spesso questo è un bruttissimo colpo per l’affidabilità dei nostri servizi.

Se abbiamo invece due macchine server, potremmo decidere si spostare tutti i siti ormai “falliti” verso questa nuova macchina in un paio d’ore, anche meno se siamo stati così bravi da eseguire dei backup incrociati fra le nostre due macchine server.

Il guaio in questo caso è che ora il nostro server “attivo” per una giornata o più dovrà reggere un carico doppio. Anche per questo è bene che un server non consumi mai più della metà delle proprie risorse in situazione di normalità.

In questo caso suderemo freddo, ma il nostro servizio rimarrà attivo e non perderà credibilità come nel caso precedente.

Virtuale

Una soluzione molto fault-tolerance dal punto di vista hardware è quello di utilizzare una  infrastruttura virtuale in grado di reggere anche se una intera macchina server fallisse. Pensiamo ad uno scenario dove un server Web virtuale è alloggiato su tre macchine fisiche; anche la caduta di una macchina permetterebbe ad un sistema di rimanere attivo, anche se con delle prestazioni ridotte.

Dal punto di vista software la cosa si complica, nel senso che se la macchina virtuale è una sola, allora un disastro software porterebbe delle gravi conseguenze. La soluzione paventata in questo punto ha dei costi  non indifferenti.

Attacchi hacker

Se siamo vittima di attacchi informatici, prima di compiere qualsiasi azione e bene capire dove e perché ci hanno “bucato”.

Le debolezze possono essere molteplici, sia a livello applicativo che umano:

• servizi con bug
• servizi non aggiornati
• errore umano nei file di configurazione
• password di accesso troppo facile e quindi “indovinata”

E’ bene quindi analizzare i file di log, per capire cosa è successo e poi, dopo aver ripristinato la situazione correggere il problema.

Quindi è buona norma effettuare il backup anche dei file di log, nel caso in cui un hacker smaliziato voglia toglierci la possibilità di comprendere il nostro errore cancellano i file di log del sistema.

Tengo a precisare che la struttura che abbiamo disegnato fin qui in questo documento offre un buon livello di sicurezza, Apache ed Ubuntu sono due prodotti molto solidi, che fanno della sicurezza uno dei punti cardine dei loro team di sviluppo. Comunque anche con queste premesse è bene essere pronti a possibili attacchi vincenti.

Carico troppo elevato

Per un web server il rischio più elevato di errori o crash è il carico troppo elevato. In questo caso il problema è meno drammatico rispetto ai primi due, ma comunque non va sottovalutato.

Un solo crash per carico elevato è sopportabile, due no, c’è qualcosa da cambiare se vogliamo offrire un servizio di buon livello.

Per analizzare come mai il nostro sistema è andato in crash abbiamo tutti gli strumenti: file di log, analisi con Cacti, programmi di benchmark come ab.

Sarebbe buona norma prendere iniziativa prima che un server diventi troppo carico, in modo da allontanare il più possibile l’eventualità di un crash. L’iniziativa potrebbe non sempre riguardare l’acquisto di nuovo hardware, ma a volte è sufficiente ottimizzare delle configurazioni in modo da abbassare considerevolmente l’impatto sul server.

Una delle migliori opzioni a livello apache è quello di abilitare la cache, per maggiori dettagli vedere:

• http://httpd.apache.org/docs/2.2/mod/mod_cache.html
• http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

Nel caso in cui comunque il nostro sistema sia in difficoltà perché ci sono troppe richieste attive, è bene fermare apache, con il comando:

apache2ctl stop

e poi riavviarlo con:

apache2ctl start

Se nemmeno in questo caso il server si scarica, è bene bloccare mysql:

/etc/init.d/mysql stop

Uccidere tutti i processi apache attivi:

kill -s 9 nome_processo

Aspettare che il carico del server si abbassi e poi riavviare tutti i servizi bloccati:

/etc/init.d/apache2 start

/etc/init.d/mysql start

Conclusioni

Pur non prevedendo tutto, il sistema illustrato nella nostra serie GiBiLamp dovrebbe offrire un buon livello di prestazioni e di sicurezza per un server web su base Linux.

E’ sempre importante conoscere gli strumenti, configurarli in maniera corretta, monitorare il sistema, e analizzare a fondo eventuali problemi. Solo così potremo offrire un servizio all’altezza delle aspettative.