VM sul cloud e storage clusterizzato

La velocità dello storage è una questione davvero importante nella scelta del servizio cloud: difatti i filesystem clusterizzati che sono alla base di molti sistemi di cloud, sono estremamente robusti e scalabili, però non sono certo paragonabili ad un server con hard disk interno.

Inutile dire che, più di una questione software, in questo caso si tratta di una questione hardware: per minimizzare i costi e massimizzare la dimensione dello storage, è facile trovare alla base dello storage dei dischi SATA di grandi dimensioni; i dischi SAS girano mediamente a velocità più elevate per cui sarebbero un prodotto più performante anche se meno capiente ed economico; i dischi SSD, all’estremo, mal si adattano a mio avviso all’utilizzo in uno storage in quanto degradano nei processi di scrittura.

Se, conti alla mano, avete deciso di optare per uno storage su filesystem cluster basato su server con dischi SATA capienti, dovete monitorare con molta attenzione le performance dei singoli nodi che compongono il cluster per scongiurare sovratulizzi: per questo il semplice comando “top” ci fornisce tutte le informazioni necesarie per capire cosa succede. Difatti il sovrautilizzo del disco si riperquote sul carico del nodo (load average) ed è facile capire se la CPU è impegnata in calcoli o in attesa dell I/O attraverso il valore “wa” che indica la percentuale di carico dovuta all’attesa dell’I/O.

In un esempio concreto, usando il filesystem MooseFS, se il carico supera frequentemente i 4-5 processi in coda è ora di agire: è necessario aggiungere nuovi nodi e, in caso, agire anche sul numero di repliche.

La semplice aggiunta di nodi, permette di distribuire i dati tra più server e quindi, se abbiamo dati “diversi” (ad esempio tanti siti internet con poco traffico oppure un sistema di posta elettronica) ne trarremo beneficio. Se, invece, il nostro storage contiene dati usati con molta frequenza (ad esempio un sito web molto visitato) è utile agire anche sul numero di repliche: avere lo stesso dato presente su più server, permette al sistema di effettuare letture “in parallelo” da diversi server.

Sempre come termine di paragone, una configurazione “mirror” con due repliche su due server può essere una buona base di partenza per un ambiente di test, ma in produzione per me un buon compromesso è avere 5 server con 3 repliche.

Nota a margine: se si usa un qualsiasi sistema di storage basato su FUSE e KVM come virtualizzatore, è necessario verificare la compatibilità dello storage con la cache settata in KVM: nelle vecchie versioni di MooseFS, infatti, era necessario impostare la cache in modalità “writeback”, cosa che rallentava ulteriormente il sistema rendendo necessario scalare lo storage pesantemente pena continui errori sul disco delle VM. Nelle nuove versioni fortumatamente la modalità “default” fa il suo dovere.

Ma cosa fare se si è “dall’altra parte” e si utilizzano VM istanziate su uno storage lento? Il problema del timeout del disco è da tenere in considerazione: i vecchi kernel andavano in kernel painc bloccando il server, i nuovi sono più “smart” e agiscono rimontando il disco in modalità read-only per avere un sistema per lo più funzionante. In qualsiasi caso, se si verifica una simile situazione, sarà necessario riavviare la VM e correggere manualmente gli errori sul disco. Errori simili sono visibili da console:

ATA1.00: exeption Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ATA1,00: failed command: READ DMA

oppure il più grave:

end_request: I/O error, dev sda, sector xxxxx
aborting journal on device sda-x
journal commit I/O error
ext_4journal_start_sb: Detected Aborted journal
Remounting filesystem read-only

Consci del fatto che il timeout è causato dalla lentezza dello storage e non da dischi corrotti, è utile settare valori di timeout sull’I/O più elevati con il comando:

echo 180 > /sys/block/sda/device/timeout

Ovviamete è necessario sostituire sda con l’identificativo del disco e 180 con il numero di secondi di timeout.