{"id":95870,"date":"2020-10-04T13:41:59","date_gmt":"2020-10-04T11:41:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999"},"modified":"2020-10-04T13:41:59","modified_gmt":"2020-10-04T11:41:59","slug":"pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","title":{"rendered":"Perch\u00e9 \u00e8 importante verificare il software sul vostro sistema di archiviazione ad alta disponibilit\u00e0 (99,9999%)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Perch\u00e9<\/p>\n

Qual \u00e8 la versione del firmware pi\u00f9 \"corretta\" e \"funzionante\"? Se un sistema di archiviazione garantisce un'affidabilit\u00e0 del 99,9999%, significa che funzioner\u00e0 senza interruzioni anche senza aggiornamenti del software? O al contrario, per ottenere la massima affidabilit\u00e0, bisogna sempre installare l'ultima versione del firmware? Ci sforzeremo di rispondere a queste domande basandoci sulla nostra esperienza.<\/p>\n

Piccola introduzione<\/h3>\n

Tutti noi sappiamo che in ogni versione di software, sia essa un sistema operativo o un driver per un dispositivo, spesso ci sono imperfezioni\/bug e altre \"particolarit\u00e0\" che possono, nel migliore dei casi, non \"manifestarsi\" fino alla fine del ciclo di vita dell'hardware, o \"emergere\" solo in condizioni specifiche. Il numero e la rilevanza di tali dettagli dipendono dalla complessit\u00e0 (funzionalit\u00e0) del software e dalla qualit\u00e0 dei test effettuati durante lo sviluppo. <\/p>\n

Spesso gli utenti rimangono sulla \"versione di fabbrica\" (il famoso \u2014 \"funziona, quindi non toccare\") o installano sempre l'ultima versione (nella loro concezione, l'ultima \u00e8 la pi\u00f9 funzionante). Noi adottiamo un approccio diverso: esaminiamo le note di rilascio per tutto il software utilizzato. nel cloud mClouds<\/a><\/noindex> e scegliamo attentamente il firmware adatto per ogni singolo pezzo di hardware. <\/p>\n

Siamo giunti a questa conclusione, per cos\u00ec dire, per esperienza. Condivideremo la nostra esperienza d'uso per spiegare perch\u00e9 il 99,9999 % di affidabilit\u00e0 promessa dallo storage non conta nulla se non ci si prende cura di aggiornamenti e descrizioni del software in tempo. Il nostro caso \u00e8 adatto agli utenti di storage di qualsiasi vendor, poich\u00e9 situazioni del genere possono verificarsi con l'hardware di qualsiasi produttore.<\/p>\n

Scelta di un nuovo sistema di archiviazione dati<\/h3>\n

Alla fine dello scorso anno, nella nostra infrastruttura \u00e8 stato aggiunto un interessante sistema di archiviazione dei dati: il modello base della linea IBM FlashSystem 5000, che al momento dell'acquisto era conosciuto come Storwize V5010e. Ora \u00e8 venduto con il nome FlashSystem 5010, ma in effetti si tratta della stessa base hardware con lo stesso Spectrum Virtualize all'interno. <\/p>\n

La presenza di un sistema di gestione unificato \u00e8, tra l'altro, la principale differenza di IBM FlashSystem. Nei modelli della serie inferiore, \u00e8 praticamente identico a quello dei modelli pi\u00f9 performanti. La scelta di un determinato modello offre solo la relativa base hardware, le cui caratteristiche consentono di utilizzare determinate funzionalit\u00e0 o garantire un livello di scalabilit\u00e0 pi\u00f9 elevato. Il software identifica la parte hardware e fornisce le funzionalit\u00e0 necessarie e sufficienti per questa piattaforma. <\/p>\n

\"Perch\u00e9IBM FlashSystem 5010<\/p>\n

Brevemente sulla nostra versione 5010. Si tratta di un sistema di archiviazione a blocchi a due controller di livello entry. Pu\u00f2 ospitare dischi NLSAS, SAS, SSD. L'inserimento di NVMe non \u00e8 disponibile, poich\u00e9 questo modello di storage \u00e8 posizionato per affrontare compiti che non richiedono le prestazioni dei dischi NVMe.<\/p>\n

Lo storage \u00e8 stato acquisito per l'archiviazione di informazioni archiviate o dati a cui non si accede frequentemente. Pertanto, ci \u00e8 stato sufficiente il set standard delle sue funzionalit\u00e0: tiraggio (Easy Tier), Thin Provision. Le prestazioni sui dischi NLSAS di 1000-2000 IOPS ci soddisfacevano. <\/p>\n

La nostra esperienza \u2014 come non abbiamo aggiornato il firmware in tempo<\/h3>\n

Ora parliamo proprio dell'aggiornamento del software. Al momento dell'acquisto, il sistema aveva gi\u00e0 una versione del software Spectrum Virtualize leggermente obsoleta, vale a dire, 8.2.1.3.<\/strong><\/p>\n

Abbiamo esaminato la descrizione dei firmware e abbiamo pianificato un aggiornamento a 8.2.1.9<\/strong>. Se fossimo stati un po' pi\u00f9 solerti, non ci sarebbe stato questo articolo: su un firmware pi\u00f9 aggiornato il bug non si sarebbe verificato. Tuttavia, per determinate ragioni, l'aggiornamento di questo sistema \u00e8 stato rinviato.<\/p>\n

Di conseguenza, un piccolo ritardo nell'aggiornamento ha portato a una situazione estremamente sgradevole, come descritto nel link: https:\/\/www.ibm.com\/support\/pages\/node\/6172341<\/u><\/a><\/noindex>. <\/p>\n

S\u00ec, 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\u00e0 di protezione, disattivando l'input\/output per il pool. Nel nostro caso, \u00e8 sembrato come disattivare 3 dischi per il gruppo RAID in modalit\u00e0 RAID 6. La disattivazione dura 6 minuti. Successivamente, l'accesso ai volumi nel pool viene ripristinato.<\/p>\n

Se qualcuno non \u00e8 familiare con la struttura e la denominazione delle entit\u00e0 logiche nel contesto di IBM Spectrum Virtualize, ora ne parler\u00f2 brevemente.<\/p>\n

\"Perch\u00e9Struttura degli elementi logici del sistema di archiviazione (SCD)<\/p>\n

I dischi sono raggruppati in gruppi chiamati MDisk (Managed Disk). Un MDisk pu\u00f2 rappresentare un RAID classico (0,1,10,5,6) o un RAID virtualizzato \u2013 DRAID (Distributed RAID). L'uso del DRAID consente di aumentare le prestazioni dell'array, poich\u00e9 verranno utilizzati tutti i dischi del gruppo, e ridurre il tempo di rebuild, grazie al fatto che sar\u00e0 necessario ripristinare solo determinati blocchi, e non tutti i dati del disco guasto.<\/p>\n

\"Perch\u00e9Distribuzione dei blocchi di dati su dischi utilizzando Distributed RAID (DRAID) in modalit\u00e0 RAID-5.<\/p>\n

E questo schema mostra la logica del rebuild del DRAID nel caso di guasto di un disco:<\/p>\n

\"Perch\u00e9Logica del rebuild del DRAID in caso di guasto di un disco<\/p>\n

Successivamente, uno o pi\u00f9 MDisk formano quello che viene chiamato Pool. All'interno di un unico pool non \u00e8 consigliabile utilizzare MDisk con differenti livelli di RAID\/DRAID su dischi dello stesso tipo. Non approfondiremo eccessivamente questo aspetto, poich\u00e9 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.<\/p>\n

Quindi, abbiamo, a seguito dell'emergere della situazione descritta in APAR HU02104<\/em>, 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.<\/p>\n

Poich\u00e9 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. <\/p>\n

Grazie a ci\u00f2, la questione \u00e8 stata risolta piuttosto rapidamente e dal supporto \u00e8 stata ricevuta una raccomandazione tempestiva per aggiornare il nostro sistema alla versione firmware 8.2.1.9, gi\u00e0 scelta in precedenza da noi, in cui questo problema era gi\u00e0 stato corretto. Questo \u00e8 confermato da una nota di rilascio corrispondente<\/u><\/a><\/noindex>.<\/u><\/p>\n

Risultati e le nostre raccomandazioni<\/h3>\n

Come si suol dire: \u00abbene ci\u00f2 che finisce bene\u00bb. Un bug nel firmware non ha comportato seri problemi: il funzionamento dei server \u00e8 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\u00f9 negative, poich\u00e9 eseguiamo quotidianamente backup di tutti gli elementi dell'infrastruttura e delle macchine dei clienti. <\/p>\n

Abbiamo ricevuto conferma che anche i sistemi affidabili con il 99,9999% di disponibilit\u00e0 promesso richiedono attenzione e manutenzione tempestiva. Alla luce della situazione, abbiamo tratto una serie di conclusioni e condividiamo le nostre raccomandazioni:<\/p>\n