Caso di Studio: File Server

Qualche mese fa siamo stati chiamati presso una ditta, che chiameremo Caso2 di grosse dimensioni, il nostro intervento è stato richiesto per investigare sul motivo di una certa lentezza della rete. La ditta in oggetto ha diverse filiali e un unico ced centralizzato, tutte le filiali sono dotate di collegamenti adsl o hdsl e si collegano al ced della ditta per qualsiasi servizio di elaborazione. Nel ced della ditta sono presenti diverse decine di server, gli utenti si collegano al ced usando servizi RDP.

Abbiamo analizzato il parallelismo dei server e i relativi carichi di lavoro, la rete interna e gli switch, poi abbiamo piazzato un portatile con un programma di logging realizzato da noi, che campiona a intervalli regolari l'attività delle cpu, la memoria utilizzata e il numero di utenti di ogni singolo server. Per risolvere un problema la prima cosa è metterlo bene a fuoco!!

Dopo svariate prove abbiamo notato che i rallentamenti si verificavano quando gli utenti cercavano di accedere ad alcuni file condivisi, presenti su un file server.

Quindi ci siamo concentrati sul file server e lo abbiamo analizzato nei dettagli costruttivi:

• HL ML370G5
• 8 Dischi SAS da 148Gb in raid 1+0
• Controller Raid con 512Mbyte di Cache e Batteria Tampone
• 4Gb di RAM
• 2 Schede Gbit in aggregazione di banda
• 2 Processori Xeon E5335 a 2Ghz (in tutto 8 core)

Non male per un file server. Sicuramente ora c'è di meglio (Giugno 2011) ma sarebbero risorse sprecate sostituirlo magari con un HP370G6 che sicuramente è più veloce, ma neanche di tanto. Ma continuiamo l'analisi analizzandone il carico:

• Carico medio delle CPU: 8-10%
• Uso della RAM 468MByte (tutto il resto cache per i file)
• Coda media del disco 0
• Traffico sulle schede di rete 1MB/Sec

Analizzando la differenza fra traffico di rete e traffico verso il sistema disco si evidenzia che almeno il 50% dei files sono tratti dalla cache del sistema operativo ove sono bufferizzati.

Ora analizziamo il filesystem del server installando un programma di deframmentazione che esegue l'intera scansione del filesystem. Risultato:

Più in dettaglio il server ospita circa 1.500.000 file di cui:

Il server è stato deframmentato circa un mese fa, quindi quello che vediamo è il risultato di un mese di lavoro.

A questo punto il problema è evidente, vi è una forte frammentazione di alcuni file. Analizzando il dettaglio del log del programma abbiamo trovato dei file con più di 1000 frammenti. Quando questi file devono essere letti su disco, ammasso che non siano stati bufferizzati in ram, occorre un tempo che è funzione del numero massimo di I/O che il sistema controller/disco riesce a fare in un secondo. Non mi stupirei, tenendo conto degli accessi concorrenti e della frammentazione che per leggere un file, nella condizione peggiore il server possa impiegare qualche secondo, tempo non eccettabile.

A questo punto, individuato il problema (peraltro in questo caso abbastanza banale) occorre trovare una soluzione definitiva.

Possibili soluzioni:

• Implementare un bacth che deframmenta i dischi tutte le notti (quando gli utenti che lavorano sono pochi). Purtroppo da prove fatte occorre un tempo molto lungo. Per ora è l'unica cosa che abbiamo potuto fare senza modificare il file server.
• Rimpiazzare il sistema controller/dischi con qualcosa di più efficiente (ipotesi che analizzeremo in seguito) allo scopo di evitare che il disco del File Server si frammenti
• Aumentare la cache di sistema (ipotesi da scartare perchè poi aumenterebbe la latenza nella lettura della cache e si perderebbero i vantaggi)

Soluzione definitiva: Aggiungere (lasciando il sitema operativo sui dischi originali) un ulteriore controller collegandolo a dei dischi SSD che non hanno problemi di frammentazione. La soluzione di aggiungere un disco SSD integrato su una scheda PCIe non è possibile in quanto detti dischi, anche se incredibilmente veloci e con una bassa latenza, non hanno sistemi di ridondanza che li rendano accettabili dal punto di vista della disponibilità essendo dei raid 0. Quindi la scelta è ricaduta su 8 dischi SSD Ocz Sata3 collegati ad un controller LSI (Megaraid), 6 in Raid5 e 2 in HotSpare (per garantire la continuità di servizio). Questa soluzione è esente da frammentazione, ha una velocità di due ordini di grandezza superiore (100 Volte più veloce a livello di numero di I/O al secondo). Unico interrogativo è la durata. Per evitare sorprese occorre usare dei dischi con una capacità abbastanza grande da dare la possibilità agli stessi di ricircolare le celle evitando di riscrivere sempre le stesse. Il costo di una soluzione del genere è leggermente più alto rispetto alla precedente, utilizzando componenti commerciali, mentre usando compunenti originali HP è notevolmente più costosa (e anche meno performante, anche se probabilmente più affidabile).