Qual è la versione del firmware più "corretta" e "funzionante"? Se lo storage garantisce un'operatività senza guasti del 99,9999%, significa che continuerà a funzionare senza interruzioni anche senza aggiornamenti software? Oppure, 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.
Piccola introduzione
Tutti noi capiamo che in ogni versione del software, sia esso un sistema operativo o un driver per un dispositivo, spesso ci sono problemi e altre "caratteristiche" che possono, a volte, non "manifestarsi" fino alla fine del ciclo di vita dell'hardware o "svilupparsi" solo in determinate condizioni. La quantità e l'importanza di tali dettagli dipende dalla complessità (funzionalità) del software e dalla qualità dei test durante la sua sviluppo.
Spesso gli utenti rimangono nella "versione di fabbrica" (il famoso — "funziona, quindi non toccarlo") o installano sempre l'ultima versione disponibile (nel loro concetto, l'ultima è sempre la più funzionante). Noi adottiamo un approccio diverso: consultiamo le note di rilascio per tutto ciò che utilizziamo e scegliamo attentamente il firmware adatto per ogni singolo pezzo di hardware.
Siamo giunti a questa conclusione, per così dire, per esperienza. Condivideremo la nostra esperienza d'uso per spiegare perché il 99,9999 % di affidabilità promessa dallo storage non conta nulla se non ci si prende cura di aggiornamenti e descrizioni del software in tempo. Il nostro caso è adatto agli utenti di storage di qualsiasi vendor, poiché situazioni del genere possono verificarsi con l'hardware di qualsiasi produttore.
Scelta di un nuovo sistema di archiviazione dati
Alla fine dello scorso anno, la nostra infrastruttura ha acquisito un interessante sistema di archiviazione dati: il modello entry-level della linea IBM FlashSystem 5000, che al momento dell'acquisto era conosciuto come Storwize V5010e. Ora è venduto sotto il nome FlashSystem 5010, ma di fatto è la stessa base hardware con lo stesso Spectrum Virtualize all'interno.
La presenza di un sistema di gestione unificato è, tra l'altro, la principale distinzione di IBM FlashSystem. Nei modelli della serie inferiore, esso non differisce praticamente dai modelli più performanti. La scelta di un determinato modello offre solo l'hardware appropriato, le cui caratteristiche consentono di utilizzare una determinata funzionalità o garantire un livello di scalabilità più elevato. Il software, in questo caso, identifica la parte hardware e fornisce la funzionalità necessaria e sufficiente per questa piattaforma.
IBM FlashSystem 5010
Brevemente sulla nostra versione 5010. Si tratta di un sistema di archiviazione a blocchi a due controller di livello entry. Può ospitare dischi NLSAS, SAS, SSD. L'inserimento di NVMe non è disponibile, poiché questo modello di storage è posizionato per affrontare compiti che non richiedono le prestazioni dei dischi NVMe.
Lo storage è stato acquisito per l'archiviazione di informazioni archiviate o dati a cui non si accede frequentemente. Pertanto, ci è stato sufficiente il set standard delle sue funzionalità: tiraggio (Easy Tier), Thin Provision. Le prestazioni sui dischi NLSAS di 1000-2000 IOPS ci soddisfacevano.
La nostra esperienza — come non abbiamo aggiornato il firmware in tempo
Ora parliamo proprio dell'aggiornamento del software. Al momento dell'acquisto, il sistema aveva già una versione del software Spectrum Virtualize leggermente obsoleta, vale a dire, 8.2.1.3.
Abbiamo esaminato la descrizione dei firmware e pianificato l'aggiornamento a 8.2.1.9. Se fossimo stati un po' più solerti, non ci sarebbe stato questo articolo: su un firmware più aggiornato il bug non si sarebbe verificato. Tuttavia, per determinate ragioni, 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 l'APAR (Authorized Program Analysis Report) HU02104. Si manifesta nel seguente modo. Sotto carico, in determinate circostanze, la cache inizia a sovraccaricarsi, quindi il sistema entra in modalità di protezione, disattivando l'input/output per il pool. Nel nostro caso, è sembrato come disattivare 3 dischi per il gruppo RAID in modalità RAID 6. La disattivazione dura 6 minuti. Successivamente, l'accesso ai volumi nel pool viene ripristinato.
Se qualcuno non è familiare con la struttura e la denominazione delle entità logiche nel contesto di IBM Spectrum Virtualize, ora ne parlerò brevemente.
Struttura degli elementi logici del sistema di archiviazione (SCD)
I dischi sono raggruppati in gruppi chiamati MDisk (Managed Disk). Un MDisk può rappresentare un RAID classico (0,1,10,5,6) o un RAID virtualizzato – DRAID (Distributed RAID). L'uso del DRAID consente di aumentare le prestazioni dell'array, poiché verranno utilizzati tutti i dischi del gruppo, e ridurre il tempo di rebuild, grazie al fatto che sarà necessario ripristinare solo determinati blocchi, e non tutti i dati del disco guasto.
Distribuzione dei blocchi di dati su dischi utilizzando Distributed RAID (DRAID) in modalità RAID-5.
E questo schema mostra la logica del rebuild del DRAID nel caso di guasto di un disco:
Logica del rebuild del DRAID in caso di guasto di un disco
Successivamente, uno o più MDisk formano quello che viene chiamato Pool. All'interno di un unico pool non è consigliabile utilizzare MDisk con differenti livelli di RAID/DRAID su dischi dello stesso tipo. Non approfondiremo eccessivamente questo aspetto, poiché prevediamo di parlarne in uno dei prossimi articoli. Inoltre, il Pool si divide in Volumi (Volumes), che vengono presentati tramite un protocollo di accesso a blocchi verso i server.
Quindi, abbiamo, a seguito dell'emergere della situazione descritta in APAR HU02104, a causa del guasto logico di tre dischi, l'MDisk ha smesso di essere operativo, il che ha portato all'inefficienza del Pool e dei relativi Volumi.
Poiché questi sistemi sono piuttosto "intelligenti", possono essere collegati al sistema di monitoraggio cloud IBM Storage Insights, che automaticamente, al verificarsi di un guasto, invia una richiesta di assistenza al supporto IBM. Viene aperta una segnalazione e gli specialisti IBM eseguono diagnostica a distanza e si mettono in contatto con l'utente del sistema.
Grazie a ciò, la questione è stata risolta piuttosto rapidamente e dal supporto è stata ricevuta una raccomandazione tempestiva per aggiornare il nostro sistema alla versione firmware 8.2.1.9, già scelta in precedenza da noi, in cui questo problema era già stato corretto. Questo è confermato da .
Risultati e le nostre raccomandazioni
Come si suol dire: «bene ciò che bene finisce». Il bug nel firmware non si è trasformato in problemi seri: il funzionamento dei server è stato ripristinato in tempi brevissimi e senza perdita di dati. Alcuni clienti hanno dovuto riavviare le macchine virtuali, ma nel complesso eravamo preparati a conseguenze più negative, poiché quotidianamente facciamo backup di tutti gli elementi dell'infrastruttura e delle macchine dei clienti.
Abbiamo ricevuto conferma che anche i sistemi affidabili con il 99,9999% di disponibilità promesso richiedono attenzione e manutenzione tempestiva. Alla luce della situazione, abbiamo tratto una serie di conclusioni e condividiamo le nostre raccomandazioni:
È fondamentale tenere d'occhio il rilascio di aggiornamenti, esaminare le Note di Rilascio per correggere potenziali problemi critici e eseguire tempestivamente gli aggiornamenti programmati.
Questo è un aspetto organizzativo, anzi un punto piuttosto ovvio, su cui non si dovrebbe realmente focalizzare l'attenzione. Tuttavia, è proprio in questo «punto piatto» che è piuttosto facile inciampare. Infatti, è stato proprio questo aspetto a contribuire alle sfortunate disavventure di cui sopra. Prestate molta attenzione alla redazione del regolamento di aggiornamento e monitorate altrettanto attentamente il suo rispetto. Questo punto è più attinente al concetto di «disciplina».
È sempre meglio mantenere il sistema con la versione del software aggiornata. Inoltre, per aggiornata non si intende quella con un numero di versione più elevato, ma precisamente quella con una data di rilascio più recente.
Ad esempio, IBM mantiene nei suoi sistemi di archiviazione dati almeno due versioni di software aggiornate. Al momento della stesura di questo articolo, queste sono 8.2 e 8.3. Gli aggiornamenti per la 8.2 vengono rilasciati prima. Solitamente, dopo un breve intervallo, viene rilasciato un aggiornamento corrispondente per la 8.3.
La versione 8.3 presenta una serie di vantaggi funzionali, ad esempio la possibilità di espandere MDisk (in modalità DRAID) aggiungendo uno o più dischi nuovi (questa possibilità è disponibile a partire dalla versione 8.3.1). Questo è un funzionalità piuttosto basilare, ma sfortunatamente nella 8.2 non è presente.
Se non è possibile eseguire un aggiornamento per vari motivi, per le versioni del software Spectrum Virtualize precedenti alla 8.2.1.9 e 8.3.1.0 (dove il bug descritto sopra è rilevante), per ridurre il rischio della sua apparizione il supporto tecnico IBM raccomanda di limitare le prestazioni del sistema a livello di pool, come mostrato nell'immagine qui sotto (screenshot realizzato in una versione GUI localizzata). Il valore di 10000 IOPS è mostrato a titolo esemplificativo e viene selezionato in base alle caratteristiche del tuo sistema.
Limitazione delle prestazioni dello storage IBM
È necessario calcolare correttamente il carico sui sistemi di storage e non consentire sovraccarichi. A tal fine, è possibile utilizzare sia il sizing tool IBM (se accessibile), sia il supporto dei partner, sia risorse esterne. È fondamentale comprendere il profilo del carico sul sistema di storage, poiché le prestazioni in MB/s e IOPS variano notevolmente in base ad almeno i seguenti parametri:
tipo di operazione: lettura o scrittura,
dimensione del blocco dell'operazione,
percentuale di operazioni di lettura e scrittura nel flusso complessivo di input/output.
Inoltre, la velocità di esecuzione delle operazioni è influenzata dal modo in cui i blocchi di dati vengono letti: in modo sequenziale o casuale. Quando si eseguono più operazioni di accesso ai dati lato applicazione, esiste il concetto di operazioni dipendenti. Questo è anche importante da considerare. Tutto ciò può aiutare a visualizzare l'insieme dei dati dai contatori di prestazione del sistema operativo, dello storage, dei server/ipervisori, oltre a comprendere le peculiarità di funzionamento delle applicazioni, dei DBMS e di altri "consumatori" di risorse disco.
Infine, è fondamentale avere copie di backup aggiornate e funzionanti. La pianificazione dei backup deve essere configurata in base a valori RPO accettabili per l'azienda e la solidità delle copie di backup deve essere periodicamente verificata (numerosi fornitori di software per il backup hanno implementato il controllo automatizzato nelle loro soluzioni) per garantire un valore RTO accettabile.
Grazie per aver letto fino alla fine.
Siamo pronti a rispondere alle vostre domande e commenti. Inoltre,, in cui conduciamo regolarmente promozioni (sconti su IaaS e sorteggi di codici promozionali fino al 100% su VPS), condividiamo notizie interessanti e annunciamo nuovi articoli nel blog di Habr.
Fonte: habr.com
