Qual è la versione del firmware più "corretta" e "funzionante"? Se la SAN garantisce un'affidabilità del 99,9999%, significa che funzionerà senza interruzioni anche senza aggiornamenti software? O al contrario, per ottenere la massima affidabilità, è necessario installare sempre l'ultima versione del firmware? Cercheremo di rispondere a queste domande basandoci sulla nostra esperienza.
Una breve introduzione
Tutti noi capiamo che in ogni versione del software, sia essa un sistema operativo o un driver per un dispositivo, ci possono essere difetti, bug e altre "particolarità" che possono non "manifestarsi" fino alla fine della vita dell'hardware o "emergere" solo in determinate condizioni. Il numero e la rilevanza di queste sfide dipende dalla complessità (funzionalità) del software e dalla qualità dei test durante il suo sviluppo.
Spesso gli utenti rimangono sulla "versione di fabbrica" (il famoso – "funziona, quindi non toccare") o installano sempre l'ultima versione (nella loro comprensione, l'ultima significa la più funzionante). Noi invece utilizziamo un approccio diverso: verifichiamo le note di rilascio per tutto ciò che utilizziamo. di attrezzature e selezioniamo attentamente il firmware appropriato per ciascun dispositivo.
Siamo giunti a questa conclusione attraverso l'esperienza. Racconteremo il nostro esempio di utilizzo per spiegare perché il promettente 99,9999% di affidabilità delle soluzioni di archiviazione non significa nulla se non si monitora regolarmente l'aggiornamento e la documentazione del software. Il nostro caso si adatta agli utenti di soluzioni di archiviazione di qualsiasi fornitore, poiché situazioni del genere possono verificarsi con l'hardware di qualsiasi produttore.
La scelta di un nuovo sistema di archiviazione dati
Alla fine dello scorso anno, la nostra infrastruttura ha aggiunto un interessante sistema di archiviazione dati: il modello base della serie IBM FlashSystem 5000, che al momento dell'acquisto era chiamato Storwize V5010e. Ora viene venduto con il nome di FlashSystem 5010, ma di fatto si tratta della stessa base hardware con lo stesso Spectrum Virtualize all'interno.
La disponibilità di un sistema di gestione unificato è, per inciso, la principale differenza dell'IBM FlashSystem. Nei modelli della serie entry-level, esso non differisce praticamente dai modelli più performanti. La scelta di un determinato modello offre solo una base hardware specifica, le cui caratteristiche consentono di utilizzare determinate funzionalità o garantire un livello più elevato di scalabilità. Il software identifica la parte hardware e fornisce le funzionalità necessarie e sufficienti per questa piattaforma.
IBM FlashSystem 5010
Breve panoramica del nostro modello 5010. Si tratta di un sistema di storage a blocchi con doppio controller di livello entry. Può ospitare dischi NLSAS, SAS, SSD. L'installazione di NVMe non è disponibile, poiché questo modello di storage è posizionato per affrontare compiti che non richiedono le prestazioni dei dischi NVMe.
Lo storage è stato acquistato per l'archiviazione di informazioni archiviate o dati a cui non si accede frequentemente. Pertanto, ci è bastato il set standard delle sue funzionalità: tiering (Easy Tier), Thin Provision. Le prestazioni sui dischi NLSAS, nell'ordine di 1000-2000 IOPS, erano adeguate per le nostre esigenze.
La nostra esperienza: come non abbiamo aggiornato il firmware in tempo
Ora parliamo dell'aggiornamento del software. Al momento dell'acquisto, il sistema aveva già una versione di Spectrum Virtualize leggermente obsoleta, ovvero, 8.2.1.3.
Abbiamo esaminato la descrizione dei firmware e programmato l'aggiornamento a 8.2.1.9. Se fossimo stati un po' più solerti, questo articolo non sarebbe esistito: con un firmware più recente, il bug non si sarebbe verificato. Tuttavia, per ragioni specifiche, l'aggiornamento di questo sistema è stato rinviato.
Di conseguenza, un piccolo ritardo nell'aggiornamento ha portato a una situazione estremamente sgradevole, come descritto nel link: .
Sì, nel firmware di quella versione era presente il cosiddetto APAR (Authorized Program Analysis Report) HU02104. Si manifesta in questo modo: sotto carico, in determinate circostanze, la cache inizia a traboccare, e quindi il sistema entra in modalità protetta, nella quale disabilita le operazioni di input-output per il pool. Nel nostro caso, si è trattato della disabilitazione di 3 dischi per il gruppo RAID in modalità RAID 6. La disabilitazione dura 6 minuti. Successivamente, l'accesso ai volumi nel pool viene ripristinato.
Se qualcuno non è familiare con la struttura e la nomenclatura delle entità logiche nel contesto di IBM Spectrum Virtualize, ora ne darò una breve spiegazione.
Struttura degli elementi logici dello storage
I dischi vengono raggruppati in unità chiamate MDisk (Managed Disk). L'MDisk può rappresentare un RAID classico (0,1,10,5,6) o virtualizzato – DRAID (Distributed RAID). L'uso del DRAID consente di aumentare le prestazioni dell'array, poiché verranno utilizzati tutti i dischi del gruppo, e di ridurre i tempi di ripristino, poiché sarà necessario ripristinare solo determinati blocchi, anziché tutti i dati del disco guasto.
Distribuzione dei blocchi di dati sui dischi utilizzando il Distributed RAID (DRAID) in modalità RAID-5.
Questo schema mostra la logica del ripristino del DRAID in caso di guasto di un disco:
Logica del ripristino del DRAID in caso di guasto di un disco
Successivamente, uno o più MDisk formano quello che viene chiamato Pool. All'interno di un pool non è consigliabile utilizzare MDisk con livelli RAID/DRAID diversi su dischi dello stesso tipo. Non ci soffermeremo troppo su questo, poiché intendiamo trattarlo in uno dei prossimi articoli. In effetti, il Pool si divide in Volumi (Volumes), che vengono presentati tramite uno dei protocolli di accesso ai blocchi ai host.
Quindi, a causa della situazione descritta in APAR HU02104, a causa di un guasto logico di tre dischi, il MDisk ha smesso di funzionare, causando a sua volta un guasto nel Pool e nei relativi Volumi.
Poiché questi sistemi sono piuttosto «intelligenti», possono essere collegati al sistema cloud di monitoraggio IBM Storage Insights, che invia automaticamente una richiesta di supporto a IBM in caso di guasto. Viene creata una richiesta e gli specialisti IBM effettuano la diagnostica da remoto e contattano l'utente del sistema.
Grazie a ciò, la questione è stata risolta piuttosto rapidamente e abbiamo ricevuto una raccomandazione tempestiva dal supporto per aggiornare il nostro sistema alla versione firmware 8.2.1.9, precedentemente scelta, in cui questo problema era già stato risolto. Questo è confermato da .
Conclusioni e le nostre raccomandazioni
Come si suol dire: «è bene ciò che finisce bene». Il bug nel firmware non ha provocato seri problemi: il funzionamento dei server è stato ripristinato in tempi brevi e senza perdita di dati. Alcuni clienti hanno dovuto riavviare le macchine virtuali, ma nel complesso eravamo pronti a conseguenze più negative, poiché eseguiamo quotidianamente backup di tutti gli elementi dell'infrastruttura e delle macchine dei clienti.
Abbiamo ricevuto conferma che anche i sistemi più affidabili con una disponibilità promessa del 99,9999% richiedono attenzione e manutenzione tempestiva. Sulla base della situazione, abbiamo tratto alcune conclusioni e condividiamo le nostre raccomandazioni:
È fondamentale tenere d'occhio il rilascio degli aggiornamenti, studiare le Note di Rilascio per identificare la correzione di potenziali criticità e eseguire tempestivamente gli aggiornamenti programmati.
Questo è un punto organizzativo e persino piuttosto ovvio, sul quale, a prima vista, non sembrerebbe necessario soffermarsi. Tuttavia, è facile inciampare proprio su questo "punto pianeggiante". È stato proprio questo aspetto a causare le difficoltà descritte sopra. Trattate con molta attenzione la redazione del regolamento di aggiornamento e monitorate con altrettanta attenzione il rispetto di esso. Questo punto si ricollega maggiormente al concetto di "disciplina".
È sempre meglio mantenere il sistema con la versione software più aggiornata. Inoltre, "aggiornata" non significa solo quella con un numero maggiore, ma deve anche avere una data di rilascio più recente.
Ad esempio, IBM mantiene almeno due versioni software aggiornate per i suoi sistemi di archiviazione dati. Al momento della scrittura di questo articolo, si tratta delle versioni 8.2 e 8.3. Gli aggiornamenti per la versione 8.2 vengono rilasciati prima. Di seguito, con un leggero ritardo, di solito viene rilasciato un aggiornamento analogo per la versione 8.3.
La versione 8.3 presenta diversi vantaggi funzionali, come la possibilità di espandere MDisk (in modalità DRAID) aggiungendo uno o più nuovi dischi (questa funzionalità è disponibile a partire dalla versione 8.3.1). Si tratta di una funzionalità piuttosto basica, ma nella versione 8.2 non è purtroppo disponibile.
Se non è possibile effettuare l'aggiornamento per vari motivi, per le versioni del software Spectrum Virtualize precedenti alle versioni 8.2.1.9 e 8.3.1.0 (dove il bug descritto sopra è attivo), per ridurre il rischio della sua apparizione, il supporto tecnico di IBM raccomanda di limitare le prestazioni del sistema a livello di pool, come mostrato nell'immagine qui sotto (screenshot realizzato nella versione localizzata dell'interfaccia GUI). Il valore 10000 IOPS è indicato a titolo esemplificativo e deve essere regolato in base alle caratteristiche del vostro sistema.
Limitazione delle prestazioni dello storage IBM
È fondamentale calcolare correttamente il carico sui sistemi di storage e evitare sovraccarichi. A tal fine, è possibile utilizzare il size tool di IBM (se disponibile), l'assistenza dei partner o risorse esterne. È essenziale comprendere il profilo del carico sul sistema di storage, poiché le prestazioni in MB/s e IOPS variano significativamente a seconda almeno dei seguenti parametri:
tipo di operazione: lettura o scrittura,
dimensione del blocco dell'operazione,
percentuale di operazioni di lettura e scrittura nel flusso totale di input/output.
Inoltre, la velocità di esecuzione delle operazioni è influenzata da come vengono letti i blocchi di dati: in modo sequenziale o casuale. Durante l'esecuzione di più operazioni di accesso ai dati da parte dell'applicazione, esiste il concetto di operazioni dipendenti. Questo è un aspetto da considerare. Tutto ciò può aiutare a vedere la somma dei dati dai contatori di prestazioni del sistema operativo, del sistema di storage, dei server/ipervisori, oltre a comprendere le peculiarità delle applicazioni, dei database e di altri 'consumatori' di risorse disco.
E infine, è fondamentale avere backup aggiornati e funzionanti. La pianificazione dei backup deve essere impostata in base ai valori RPO accettabili per l'azienda e la loro integrità deve essere controllata periodicamente (molti fornitori di software di backup hanno implementato controlli automatizzati) per garantire un RTO accettabile.
Grazie per aver letto fino alla fine.
Siamo pronti a rispondere alle vostre domande e commenti. Inoltre,dove organizziamo regolarmente promozioni (sconti su IaaS e estrazioni di codici sconto fino al 100% su VPS), condividiamo notizie interessanti e annunciamo nuovi articoli nel blog di Habr.
Fonte: habr.com
