{"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 testare il software sul tuo sistema di storage 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 \"giusta\" e \"funzionante\"? Se il sistema di archiviazione garantisce un'affidabilit\u00e0 del 99,9999%, significa che funzioner\u00e0 senza interruzioni anche senza aggiornare il software? Oppure, al contrario, per ottenere la massima affidabilit\u00e0 \u00e8 necessario installare sempre l'ultima versione del firmware? Cercheremo di rispondere a queste domande basandoci sulla nostra esperienza.<\/p>\n

Una breve introduzione<\/h3>\n

Tutti noi sappiamo che ogni versione del software, che si tratti di un sistema operativo o di un driver per un dispositivo, spesso contiene errori o altre \"particolarit\u00e0\" che possono non manifestarsi fino alla fine della vita utile dell'hardware o \"emergere\" solo in determinate condizioni. Il numero e l'importanza di tali dettagli dipendono dalla complessit\u00e0 (funzionalit\u00e0) del software e dalla qualit\u00e0 dei test effettuati durante il suo sviluppo. <\/p>\n

Spesso gli utenti restano sulla \"versione di fabbrica\" (il famoso \u2014 \"funziona, quindi non toccare\") o installano sempre l'ultima versione (nella loro comprensione, l'ultima significa la pi\u00f9 funzionante). Noi adottiamo un approccio diverso: consultiamo le note di rilascio per tutto il software utilizzato. nel cloud mClouds<\/a><\/noindex> di attrezzature e selezioniamo attentamente il firmware appropriato per ciascun dispositivo. <\/p>\n

Siamo giunti a questa conclusione attraverso l'esperienza. Racconteremo il nostro esempio di utilizzo per spiegare perch\u00e9 il promettente 99,9999% di affidabilit\u00e0 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\u00e9 situazioni del genere possono verificarsi con l'hardware di qualsiasi produttore.<\/p>\n

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

Alla fine dello scorso anno, abbiamo aggiunto alla nostra infrastruttura un interessante sistema di archiviazione dati: il modello base della gamma IBM FlashSystem 5000, che al momento dell'acquisto era conosciuto come Storwize V5010e. Oggi \u00e8 venduto con il nome FlashSystem 5010, ma in realt\u00e0 si basa sulla stessa architettura hardware con la stessa Spectrum Virtualize all'interno. <\/p>\n

La presenza di un sistema di gestione unico \u2014 questo, per inciso, \u00e8 la principale differenza dell'IBM FlashSystem. Nei modelli di fascia bassa, esso differisce praticamente dai modelli pi\u00f9 performanti. La scelta di un modello specifico offre solo una base hardware corrispondente, le cui caratteristiche consentono di utilizzare una determinata funzionalit\u00e0 o assicurare un livello di scalabilit\u00e0 pi\u00f9 elevato. Il software, nel frattempo, identifica la parte hardware e fornisce le funzionalit\u00e0 necessarie e sufficienti per questa piattaforma. <\/p>\n

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

Breve panoramica del nostro modello 5010. Si tratta di un sistema di storage a blocchi con doppio controller di livello entry. Pu\u00f2 ospitare dischi NLSAS, SAS, SSD. L'installazione 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 acquistato per l'archiviazione di informazioni archiviate o dati a cui non si accede frequentemente. Pertanto, ci \u00e8 bastato il set standard delle sue funzionalit\u00e0: tiering (Easy Tier), Thin Provision. Le prestazioni sui dischi NLSAS, nell'ordine di 1000-2000 IOPS, erano adeguate per le nostre esigenze. <\/p>\n

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

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

Abbiamo studiato la descrizione dei firmware e programmato l'aggiornamento a 8.2.1.9<\/strong>. Se fossimo stati un po' pi\u00f9 solerti, questo articolo non sarebbe esistito: con un firmware pi\u00f9 recente, il bug non si sarebbe verificato. Tuttavia, per ragioni specifiche, 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 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\u00e0 protetta, nella quale disabilita le operazioni di input-output per il pool. Nel nostro caso, si \u00e8 trattato della disabilitazione di 3 dischi per il gruppo RAID in modalit\u00e0 RAID 6. La disabilitazione dura 6 minuti. Successivamente, l'accesso ai volumi nel pool viene ripristinato.<\/p>\n

Se qualcuno non \u00e8 familiare con la struttura e la nomenclatura delle entit\u00e0 logiche nel contesto di IBM Spectrum Virtualize, ora ne dar\u00f2 una breve spiegazione.<\/p>\n

\"Perch\u00e9Struttura degli elementi logici dello storage<\/p>\n

I dischi vengono raggruppati in unit\u00e0 chiamate MDisk (Managed Disk). L'MDisk pu\u00f2 rappresentare un RAID classico (0,1,10,5,6) o 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 di ridurre i tempi di ripristino, poich\u00e9 sar\u00e0 necessario ripristinare solo determinati blocchi, anzich\u00e9 tutti i dati del disco guasto.<\/p>\n

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

Questo schema mostra la logica del ripristino del DRAID in caso di guasto di un disco:<\/p>\n

\"Perch\u00e9Logica del ripristino 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 pool non \u00e8 consigliabile utilizzare MDisk con livelli RAID\/DRAID diversi su dischi dello stesso tipo. Non ci soffermeremo troppo su questo, poich\u00e9 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.<\/p>\n

Quindi, a causa della situazione descritta in APAR HU02104<\/em>, 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.<\/p>\n

Poich\u00e9 questi sistemi sono piuttosto \u00abintelligenti\u00bb, 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. <\/p>\n

Grazie a ci\u00f2, la questione \u00e8 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\u00e0 stato risolto. Questo \u00e8 confermato da una Release Note corrispondente<\/u><\/a><\/noindex>.<\/u><\/p>\n

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

Come si suol dire: \"\u00e8 bene ci\u00f2 che finisce bene\". Un bug nel firmware non ha causato seri problemi \u2014 il funzionamento dei server \u00e8 stato ripristinato nel minor tempo possibile e senza perdita di dati. Alcuni clienti hanno dovuto riavviare le macchine virtuali, ma in generale 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 pi\u00f9 affidabili con una disponibilit\u00e0 promessa del 99,9999% richiedono attenzione e manutenzione tempestiva. Sulla base della situazione, abbiamo tratto alcune conclusioni e condividiamo le nostre raccomandazioni:<\/p>\n