Quale versione firmware è la più “corretta” e “funzionante”? Se un sistema di storage garantisce una tolleranza ai guasti del 99,9999%, significa che funzionerà ininterrottamente anche senza un aggiornamento software? Oppure, al contrario, per ottenere la massima tolleranza agli errori bisognerebbe installare sempre il firmware più recente? Cercheremo di rispondere a queste domande in base alla nostra esperienza.
Piccola introduzione
Comprendiamo tutti che ogni versione del software, sia esso un sistema operativo o un driver per un dispositivo, spesso contiene difetti/bug e altre "caratteristiche" che potrebbero non "apparire" fino alla fine della vita utile dell'apparecchiatura, o "aprirsi" solo a determinate condizioni. Il numero e il significato di tali sfumature dipendono dalla complessità (funzionalità) del software e dalla qualità dei test durante il suo sviluppo.
Spesso gli utenti utilizzano il “firmware di fabbrica” (il famoso “funziona, quindi non scherzare”) o installano sempre la versione più recente (a loro avviso, più recente significa più funzionante). Usiamo un approccio diverso: guardiamo le note di rilascio per tutto ciò che utilizziamo apparecchiatura e selezionare attentamente il firmware appropriato per ciascuna apparecchiatura.
Siamo arrivati a questa conclusione, come si suol dire, con l'esperienza. Usando il nostro esempio di funzionamento, ti diremo perché l'affidabilità promessa del 99,9999% dei sistemi di archiviazione non significa nulla se non si monitorano tempestivamente gli aggiornamenti e le descrizioni del software. Il nostro case è adatto agli utenti di sistemi di storage di qualsiasi fornitore, poiché una situazione simile può verificarsi con hardware di qualsiasi produttore.
Scelta di un nuovo sistema di storage
Alla fine dello scorso anno si è aggiunto alla nostra infrastruttura un interessante sistema di archiviazione dati: un modello junior della linea IBM FlashSystem 5000, che al momento dell'acquisto si chiamava Storwize V5010e. Ora viene venduto con il nome FlashSystem 5010, ma in realtà è la stessa base hardware con lo stesso Spectrum Virtualize all'interno.
La presenza di un sistema di gestione unificato è, tra l'altro, la principale differenza tra IBM FlashSystem. Per i modelli delle serie più giovani, praticamente non è diverso dai modelli più produttivi. La scelta di un modello specifico fornisce solo la base hardware appropriata, le cui caratteristiche consentono di utilizzare l'una o l'altra funzionalità o fornire un livello più elevato di scalabilità. Il software identifica l'hardware e fornisce le funzionalità necessarie e sufficienti per questa piattaforma.
IBM FlashSystem 5010
Brevemente sul nostro modello 5010. Questo è un sistema di archiviazione a blocchi a doppio controller entry-level. Può ospitare dischi NLSAS, SAS, SSD. Il posizionamento NVMe non è disponibile in esso, poiché questo modello di archiviazione è posizionato per risolvere problemi che non richiedono le prestazioni delle unità NVMe.
Il sistema di storage è stato acquistato per ospitare informazioni o dati di archivio a cui non si accede frequentemente. Pertanto, per noi era sufficiente il set standard delle sue funzionalità: Tiering (Easy Tier), Thin Provision. Anche le prestazioni sui dischi NLSAS al livello di 1000-2000 IOPS sono state per noi abbastanza soddisfacenti.
La nostra esperienza: come non abbiamo aggiornato il firmware in tempo
Ora riguardo all'aggiornamento del software stesso. Al momento dell'acquisto, il sistema disponeva già di una versione leggermente obsoleta del software Spectrum Virtualize, vale a dire: 8.2.1.3
Abbiamo studiato le descrizioni del firmware e pianificato un aggiornamento 8.2.1.9. Se fossimo stati un po' più efficienti, questo articolo non sarebbe esistito: il bug non si sarebbe verificato su un firmware più recente. Tuttavia, per alcuni motivi, l'aggiornamento di questo sistema è stato rinviato.
Di conseguenza, un leggero ritardo nell'aggiornamento ha portato ad un'immagine estremamente spiacevole, come nella descrizione al link: .
Sì, nel firmware di quella versione era rilevante il cosiddetto APAR (Authorized Program Analysis Report) HU02104. Appare come segue. Sotto carico, in determinate circostanze, la cache inizia a traboccare, quindi il sistema entra in modalità protettiva, in cui disabilita l'I/O per il pool. Nel nostro caso, sembrava che si fossero disconnessi 3 dischi per un gruppo RAID in modalità RAID 6. La disconnessione avviene per 6 minuti. Successivamente, viene ripristinato l'accesso ai volumi nel pool.
Se qualcuno non ha familiarità con la struttura e la denominazione delle entità logiche nel contesto di IBM Spectrum Virtualize, lo spiegherò ora brevemente.
Struttura degli elementi logici del sistema di storage
I dischi vengono raccolti in gruppi chiamati MDisk (Managed Disk). MDisk può essere un RAID classico (0,1,10,5,6) o virtualizzato - DRAID (RAID distribuito). L'utilizzo di DRAID consente di aumentare le prestazioni dell'array, perché... Verranno utilizzati tutti i dischi del gruppo e il tempo di ricostruzione sarà ridotto, poiché sarà necessario ripristinare solo alcuni blocchi e non tutti i dati del disco guasto.
Distribuzione dei blocchi di dati sui dischi quando si utilizza RAID distribuito (DRAID) in modalità RAID-5.
E questo diagramma mostra la logica di come funziona una ricostruzione DRAID in caso di guasto di un disco:
Logica della ricostruzione DRAID in caso di guasto di un disco
Successivamente uno o più MDisk formano un cosiddetto Pool. All'interno dello stesso pool, non è consigliabile utilizzare MDisk con livelli RAID/DRAID diversi su dischi dello stesso tipo. Non entreremo in questo argomento troppo in profondità, perché... abbiamo intenzione di trattare questo argomento in uno dei seguenti articoli. Ebbene, in effetti, il Pool è diviso in Volumi, che vengono presentati agli host utilizzando l'uno o l'altro protocollo di accesso a blocchi.
Quindi, noi, a seguito della situazione descritta in APAR HU02104, a causa del guasto logico di tre dischi, MDisk ha smesso di funzionare, il che, a sua volta, ha comportato il guasto del Pool e dei volumi corrispondenti.
Poiché questi sistemi sono piuttosto intelligenti, possono essere collegati al sistema di monitoraggio basato su cloud IBM Storage Insights, che invia automaticamente una richiesta di servizio al supporto IBM se si verifica un problema. Viene creata un'applicazione e gli specialisti IBM eseguono la diagnostica da remoto e contattano l'utente del sistema.
Grazie a ciò, il problema è stato risolto abbastanza rapidamente e il servizio di supporto ha ricevuto una pronta raccomandazione per aggiornare il nostro sistema al firmware 8.2.1.9 precedentemente selezionato, che a quel tempo era già stato corretto. Lo conferma .
Risultati e i nostri consigli
Come dice il proverbio: “tutto è bene quel che finisce bene”. Il bug nel firmware non ha causato problemi seri: i server sono stati ripristinati il prima possibile e senza perdita di dati. Alcuni clienti hanno dovuto riavviare le macchine virtuali, ma in generale eravamo preparati a conseguenze più negative, poiché effettuiamo backup giornalieri di tutti gli elementi dell'infrastruttura e delle macchine client.
Abbiamo ricevuto conferma che anche sistemi affidabili con una disponibilità promessa del 99,9999% richiedono attenzione e manutenzione tempestiva. Sulla base della situazione, abbiamo tratto una serie di conclusioni e condividiamo le nostre raccomandazioni:
-
È fondamentale monitorare il rilascio degli aggiornamenti, studiare le note di rilascio per le correzioni di problemi potenzialmente critici ed eseguire tempestivamente gli aggiornamenti pianificati.
Questo è un punto organizzativo e anche abbastanza ovvio, sul quale, a quanto pare, non vale la pena concentrarsi. Tuttavia, su questo “terreno pianeggiante” si può inciampare abbastanza facilmente. In realtà, è stato questo momento ad aggiungere i problemi sopra descritti. Prestare molta attenzione nel redigere le norme di aggiornamento e vigilare con non minore attenzione sul loro rispetto. Questo punto si riferisce più al concetto di “disciplina”.
-
È sempre meglio mantenere il sistema con la versione software più recente. Inoltre, quello attuale non è quello che ha una designazione numerica più grande, ma piuttosto quello con una data di rilascio successiva.
Ad esempio, IBM mantiene aggiornate almeno due versioni software per i suoi sistemi di storage. Al momento in cui scrivo, questi sono 8.2 e 8.3. Gli aggiornamenti per 8.2 arrivano prima. Un aggiornamento simile per 8.3 viene solitamente rilasciato con un leggero ritardo.
La versione 8.3 presenta numerosi vantaggi funzionali, ad esempio la possibilità di espandere MDisk (in modalità DRAID) aggiungendo uno o più nuovi dischi (questa funzionalità è apparsa a partire dalla versione 8.3.1). Questa è una funzionalità abbastanza basilare, ma sfortunatamente nella versione 8.2 non è presente tale funzionalità.
-
Se per qualche motivo non è possibile eseguire l'aggiornamento, per le versioni del software Spectrum Virtualize precedenti alle versioni 8.2.1.9 e 8.3.1.0 (dove il bug descritto sopra è rilevante), per ridurre il rischio che si verifichi, il supporto tecnico IBM consiglia limitando le prestazioni del sistema a livello di pool, come mostrato nella figura seguente (la foto è stata scattata nella versione russificata della GUI). Il valore di 10000 IOPS è mostrato a titolo di esempio e viene selezionato in base alle caratteristiche del proprio sistema.
Limitazione delle prestazioni di storage IBM
-
È necessario calcolare correttamente il carico sui sistemi di accumulo ed evitare il sovraccarico. Per fare ciò, puoi utilizzare il sizer IBM (se ne hai accesso), oppure l'aiuto di partner o risorse di terze parti. È fondamentale comprendere il profilo di carico sul sistema di accumulo, perché Le prestazioni in MB/s e IOPS variano notevolmente in base almeno ai seguenti parametri:
-
tipo di operazione: lettura o scrittura,
-
dimensione del blocco operazione,
-
percentuale di operazioni di lettura e scrittura nel flusso I/O totale.
Inoltre, la velocità delle operazioni è influenzata dal modo in cui vengono letti i blocchi di dati: in sequenza o in ordine casuale. Quando si eseguono più operazioni di accesso ai dati dal lato dell'applicazione, esiste il concetto di operazioni dipendenti. È opportuno tenere conto anche di questo. Tutto ciò può aiutare a vedere la totalità dei dati dai contatori delle prestazioni del sistema operativo, del sistema di archiviazione, dei server/hypervisor, nonché a comprendere le caratteristiche operative di applicazioni, DBMS e altri "consumatori" di risorse disco.
-
-
E infine, assicurati di avere i backup aggiornati e funzionanti. La pianificazione del backup dovrebbe essere configurata in base a valori RPO accettabili per l'azienda e dovrebbero essere verificati controlli periodici di integrità dei backup (non pochi fornitori di software di backup hanno implementato la verifica automatizzata nei loro prodotti) per garantire un valore RTO accettabile.
Grazie per aver letto fino alla fine.
Siamo pronti a rispondere alle vostre domande e commenti nei commenti. Anche, in cui organizziamo promozioni regolari (sconti su IaaS e omaggi per codici promozionali fino al 100% su VPS), scriviamo notizie interessanti e annunciamo nuovi articoli sul blog Habr.
Fonte: habr.com