Aggiungiamo un altro disco

Ho iniziato ad installare server con Novell NetWare 2.x

La società per cui lavoravo in quel periodo quando doveva vendere piccole soluzioni forniva un Compaq Deskpro 286 su cui veniva installato l’applicativo di NetWare 2. I PC avevano, ovviamente un solo disco che durava spesso più dell’applicativo che supportavano. Naturalmente si facevano i backup, spesso sui dischi locali dei PC.

Poi siamo passati a Novell NetWare 3.x, installati o su Deskpro 386 oppure, per i più facoltosi, su Compaq SystemPro, tra i primi “PC” in fatti per essere “server”. Anche in questo caso si installava un solo disco, che durava per anni (sempre con il suo bravo backup, si capisce). Solamente verso il 1994 ho installato i primi RAID di Compaq: gli IDA, precursori degli Smart Array Controller che hanno dimostrato infinite volte di meritare il loro nome di battesimo.

Nella seconda metà degli anni 90, con l’esplosione dei server il RAID diventa quasi obbligatorio, sia perché chi vende vende più dischi sia perché i dischi diventano meno robusti sia perché inizia la frenesia, spesso ingiustificata, dello zero downtime. Si mette tutto ridondante: alimentatore, dischi, NIC, così il server può funzionare senza problemi 24x7x365, magari con un contratto di assistenza analogo. E poi l’azienda lavora 40 ore la settimana e nessuno controlla se il server ha dei guasti, ma questo è un altro discorso.

Con l’avvento sul finire del millennio di enclosure che permettono RAID da 14 dischi si fa avanti l’idea del disco di spare: un disco pronto ad entrare in azione se uno (o più) dei volumi RAID degrada per guasto di un disco. Abbiamo quindi dei dischi in più per ridondanza (il doppio nel caso di RAID1[0], uno solo nel caso di RAID5) a cui si aggiungono altri dischi di hot spare.

Alla fine del 2000 (vado a memoria) Compaq introduce la SMART 6300 con la funzionalità ADG, che altri chiamano RAID6: in pratica la ridondanza distribuita è gestita in modo tale da poter perdere anche due dischi e mantenere il volume RAID leggibile, anche se degradato, ovviamente i dischi che si “perdono” sono due. Se l’ADG è una sorta di hot spare online, molti preferiscono avere sia ADG sia hot spare.

Le dimensioni dei dischi crescono geometricamente, ma non sono seguite da un’altrettanta crescita della banda delle interfacce e dei controller; contestualmente si fanno sentire le iniziative di contrazione dei costi di gestione, le ottimizzazioni della logistica e tutte queste cose.

Adesso è normale che un fornitore consegni un server con tutti i dischi di un RAID non solo della stessa marca e modello, ma anche dello stesso lotto di produzione, il che significa che la probabilità che si guastino relativamente assieme è altissima. Infatti è successo tre volte dall’inizio dell’anno a dei clienti (molto diversi tra loro) di una ditta con cui collaboro. La dimensione di un disco è diventata tale per cui ci possono volere decine di ore per ricostruire un RAID; le impostazioni di default dei controller che privilegiano le performance rispetto alla ricostruzione non aiutano.

Qualcuno comincia timidamente a sussurrare che la ridondanza con parità distribuita (RAID 5/6) non è più adatta e bisogna adottare solamente ridondanza per copia (RAID 1/1+0/0+1). Un po’ come quando CISCO in ogni configurazione che propone dopo ogni dispositivo aggiunge “due, per ridondanza”: come (cercare di) raddoppiare le vendite scaricando sul cliente i problemi di un calo della qualità del prodotto.


Pubblicato

in

,

da

Tag:

Commenti

6 risposte a “Aggiungiamo un altro disco”

  1. Avatar Luca Dell'Oca

    Ciao Luigi,
    ci sono altre considerazioni da fare per gli storage moderni.

    La ridondanza raid sta mostrando evidenti limiti negli storage moderni perchè semplicemente i dischi meccanici sono troppo grandi in proporzione alle velocità che il business moderno richiede (too big to fail mi verrebbe da dire), e i tempi di rebuild di un raid5 con dischi da 4tb è semplicemente insopportabile, e oltretutto introduce uno stress aggiuntivo sui dischi, che spesso si rompono ulteriormente proprio durante i rebuild.

    Alcuni storage stanno introducendo concetti tipici degli object storage, dove i dati (scorporati in blocchi o chunks che dir si voglia) vengono molto più semplicemente e in modo più efficiente deduplicati e copiati N volte in altre aree (dischi differenti, chassis, storage…). Piuttosto che il raid level si imposta il replication factor (quante copie se ne vogliono) e in caso di perdita di una delle copie, il sistema verifica che RF non è più rispettato e provvede a ricreare un’altra copia.

    La perdita di spazio per ridondanza è simile ai raid, ma la gestione di grosse moli di dati molto più semplice e performante.

    Ad oggi sono strumenti disponibili solo su sistemi di fascia media-alta (nutanix, pure storage, solidfire gli esempi recenti) ma si stanno vedendo sistemi piccoli in arrivo sul mercato, uno su tutti ExaBlox. Il trucco è che questa gestione viene tutta fatta nel backend, mentre nel frontend lo storage si presenta sempre con un semplice NAS o block storage, nascondendo la parte object…

    Luca.

    1. Avatar Luigi Rosa

      Non l’ho scritto e avrei dovuto farlo: il contesto e’ l’SMB, non l’enterprise. Nell’enterprise esistevano gia’ alla fine degli anni 90 storage con RAID policy e altre raffinatezze. Un ambiente enterprise ha collegato centinaia o migliaia di utenti, un ambiente SMB arriva a decine (quando va bene), quindi i tempi di down e di ripristino hanno diverse implicazioni economiche (vedi quelli che fanno contratti 24x7x365 e poi durante la notte e festivi non c’e’ nessuno in ufficio).

      Una cosa pero’: la storia dello stress per la ricostruzione. E’ una cosa che sento solamente da quest’anno. Un disco tra i superstiti durante la ricostruzione deve solamente fare delle letture e spesso ne fa in sequenziale perche’ le richieste del “lato utente” possono non essere molte. Se la lettura di tutto il disco spalmata su qualche decina di ore genera “stress”, cosa gli fa un database relazionale con 100 utenti agguerriti sempre connessi? 🙂

      Non so, come ho scritto ho la sensazione che le compagnie di hardware stiano scaricando lungo la filiera le loro politiche di riduzione della qualita’ del loro prodotto.

      1. Avatar Luca Dell'Oca

        Uhm, ni, sono solo letture (ma essendo testine magnetiche, fanno comunque attività sulla superficie dei dischi) ma non sono sequenziali. I dati sono sparpagliati sui settori, e i blocchi non sono in sequenza quasi mai.
        E un DB relazionale non gira al 100% per tre giorni filati sui dischi, come invece ho visto fare giusto recentemente a un rebuild di uno storage per la perdita di un solo disco da 2TB.
        Ripeto, tralascia le rotture, il problema del raid sono i tempi di rebuild oggigiorno che ci sono dischi cosi grandi (che hanno però le stesse prestazioni di quelli di 10 anni fa, che erano grossi un decimo), che abbattono le prestazioni per tempi troppo lunghi per non inficiare l’attività, anche quella delle smb.
        E secondo me si, la qualità dei dischi di oggi non è paragonabile a quella di anni fa, la continua rincorsa ai prezzi bassi è stata possibile si migliorando i processi produttivi, ma anche lasciando per strada qualche componente troppo costoso. Ma temo il problema principale sia ancora la dimensione: la densità dei dati sui dischi multi-TB porta con se problemi di coerenza dei dati…

        PS: dimenticavo, rispetto uno dei problemi iniziali. Sono sicuro per esperienza diretta che almeno EMC e 3Par forniscono in ogni storage dischi provenienti tutti da lotti differenti proprio per evitare lotti difettosi e rotture contemporanee di più dischi. E credo anche altri vendor lo facciano.

        1. Avatar Luigi Rosa

          Altri vendor lo FACEVANO. Con Compaq (e ho avuto una notevole esperienza sul campo in materia durante il boom delle dot-com) con un server nuovo era normale infilare dischi di produttori diversi ordinati tutti assieme.

          Adesso e’ solamente una prerogativa degli storage enterprise, grazie anche ai consulenti dell’ottimizzazione logistica, che ne capiscono un razzo di storage.

          I tempi di rebuild sono indubbiamente il problema maggiore perche’ la banda dell’interfaccia non e’ aumentata come e’ aumentata la dimensione del disco. Pero’ anche se hai un sistema in RAID 1+0 se ti si fottono due dischi “sbagliati” sei a piedi.

          Per la cronaca, dati ‘n’ dischi la probabilita’ di perdita dati con due failure in un RAID 0+1 e’ (n/2)/(n – 1) mentre in un RAID 1+0 e’ 1/(n – 1)

          Alla fine tanto ti dicono sempre “uno in piu’ per ridondanza” 🙂 🙂 🙂

          1. Avatar Alessandro Carini

            Non per essere il solito bastian contrario …

            Ma cosa intendi per “produttori diversi”, nel mercato delle unità meccaniche di adesso?

  2. Avatar Kurgan

    Non dimentichiamo che un disco meccanico che magari e` enorme ma viene usato solo per una piccola parte (e viene usato cosi` per molto tempo) potrebbe accumulare micropolvere metallica sulla zona dei piatti che non e` usata. Quando vai a farci passare la testina sopra (rebuild del raid, per dire, che rebuilda anche l’area non usata dai dati) ecco che la testina tira su la polvere e succede un macello. Questo l’ho visto succedere un paio di volte.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *