Una delle cose che spesso vengono sottovalutate nella configurazione dello storage in RAID con parità (tipicamente RAID5) è l’importanza della batteria tampone e conseguentemente la configurazione della cache write-back anzichè write-through.

Molti pensano che la batteria tampone sia una sorta di gadget, bello e soprattutto costoso, perchè diciamocela tutta, queste miserabili e banalissime batterie al litio sono care come il fuoco, e se esistesse una divinità della giustizia vedremmo fulmini cadere h24 sulle sedi di Adaptec, LSI, IBM, Dell, HP e tutte le altre società coinvolte in questo sanguionosissimo mercato…
Purtroppo l’utente medio (almeno questa è la mia esperienza frequentando varie realtà aziendali) è portato a pensare “Massì, è già tanto se abbiamo un controller raid hardware, noi non siamo così enterprise da aver persino bisogno della batteria…”. oppure “Ok, cosa cambiera mai con la batteria o senza… i dati sono comunque al sicuro”.

Tralasciamo i commenti su questa sensazione di finta sicurezza (“shit happens”, e non è questione di se, ma di quando…), il fatto è che le batterie tampone servono, e non solo per permettere la corretta esecuzioni delle transazioni di I/O, ma anche per una pura e semplice questione legata alle performance degli array con parità, più nello specifico le politiche di utilizzo della cache nell’esecuzioni delle attività di scrittura.
Non smetterò mai di lottare contro gli array RAID5 e RAID6, uno dei motivi per i quali osteggio questo genere di configurazione è la cosidetta write penalty, ovvero il sovraccarico di IOPS dovuto calcolo e salvataggio della parità durante ciascuna attività di scrittura; per tamponare questo handicap i controller dotati di batteria tampone utilizzano la cache del controller in modalità write-back (ovvero asincrona), in caso contrario utilizzano la più sicura modalità write-through (sincrona), per una spiegazione più esaustiva rimando a questa pagina di Wikipedia.

Se pensate che questa differenza possa essere marginale date un’occhiata al grafico che segue, queste sono le prestazioni di una lun su san IBM DS4300 con array raid5 composto da tre dischi SCSI Ultra320 da 10.000 rpm durante una banale import di uno schema Oracle 9 su GNU/Linux iniziata alle ore 01:00AM (non le 13:00).
San preistorica, server ancora più antiquato, storage malridotto, sistema operativo antidiluviano (RedHat Enterprise 3), tutte ottime ragioni per giustificare delle performance così basse, guardate però la differenza tra le prestazioni antecedenti alle ore 13:00 (batteria nuova in carica e cache write-through attiva) e dopo le ore 13:00 (batteria online e cache write-back)… non ho altro da aggiungere.