Preludio:

Sono una scimmia-codice che viene sempre più assunta dai compiti di SysAdmin per la mia piccola azienda. Il mio codice è il nostro prodotto e sempre più forniamo la stessa app di SaaS.

Circa 18 mesi fa ho spostato i nostri server da un fornitore incentrato sull'hosting premium a un pusher rack barebone in un data center di livello IV. (Letteralmente dall'altra parte della strada.) Questo accenno fa molto di più noi stessi - cose come rete, archiviazione e monitoraggio.

Come parte della grande mossa, per sostituire il nostro storage affittato diretto affittato dalla società di hosting, ho creato un NAS a due nodi da 9 TB basato su chassise SuperMicro, schede RAID 3ware, Ubuntu 10.04, due dozzine di dischi SATA, DRBD e. È tutto amorevolmente documentato in tre post del blog: Creazione e test di un nuovo NAS SFS RAID10 NFSv4 da 9 TB: Parte I , Parte II e Parte III .

Abbiamo anche installato un sistema di monitoraggio Cacit. Di recente abbiamo aggiunto sempre più punti dati, come i valori SMART.

Non avrei potuto fare tutto questo senza i fantastici boffin di ServerFault . È stata un'esperienza divertente ed educativa. Il mio capo è felice (abbiamo risparmiato un sacco di dollari) , i nostri clienti sono felici (i costi di archiviazione sono bassi) , io sono felice (divertente, divertente, divertente) .

Fino a ieri

Interruzione e recupero:

Qualche tempo dopo pranzo abbiamo iniziato a ricevere rapporti sulle prestazioni lente della nostra applicazione, un CMS di streaming multimediale on demand. Più o meno nello stesso periodo il nostro sistema di monitoraggio dei cactus ha inviato una bufera di neve di e-mail. Uno degli avvisi più rivelatori era un grafico di iostat in attesa.

Le prestazioni sono diventate così degradate che Pingdom ha iniziato a inviare notifiche "server down". Il carico complessivo è stato moderato, non vi è stato un picco di traffico.

Dopo aver effettuato l'accesso ai server delle applicazioni, client NFS del NAS, ho confermato che quasi tutto stava vivendo tempi di attesa di I / O estremamente intermittenti e follemente lunghi. E una volta passato sul nodo NAS primario stesso, gli stessi ritardi erano evidenti quando si cercava di navigare nel file system dell'array problematico.

È tempo di fallire, è andato bene. Entro 20 minuti tutto è stato confermato per il backup e il funzionamento perfetto.

Post-Mortem:

Dopo ogni errore del sistema eseguo un post mortem per determinare la causa dell'errore. La prima cosa che ho fatto è stata tornare nella scatola e iniziare a rivedere i registri. Era offline, completamente. Tempo per un viaggio nel data center. Ripristino hardware, backup e in esecuzione.

In /var/syslogho trovato questa voce dall'aspetto spaventoso:

Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1  Short offline       Completed: read failure       90%      6576         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2  Short offline       Completed: read failure       90%      6087         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3  Short offline       Completed: read failure       10%      5901         656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4  Short offline       Completed: read failure       90%      5818         651637856
Nov 15 06:49:45 umbilo smartd[2827]:

Quindi sono andato a controllare i grafici dei cactus per i dischi nell'array. Qui vediamo che, sì, il disco 7 sta scivolando via proprio come dice syslog. Ma vediamo anche che gli SMART Read di Disk 8 sono fluttuanti.

Non ci sono messaggi sul disco 8 in syslog. Più interessante è che i valori fluttuanti per il disco 8 sono direttamente correlati ai tempi di attesa IO elevati! La mia interpretazione è che:

• Il disco 8 presenta uno strano errore hardware che provoca lunghi tempi di funzionamento intermittenti.
• In qualche modo questa condizione di errore sul disco sta bloccando l'intero array

Forse esiste una descrizione più accurata o corretta, ma il risultato netto è stato che l'unico disco sta influenzando le prestazioni dell'intero array.

Le domande)

• In che modo un singolo disco in un array SATA RAID-10 hardware può arrestare l'intero array?
• Sono ingenuo pensare che la scheda RAID avrebbe dovuto occuparsene?
• Come posso evitare che un singolo disco che si comporta male si ripercuota sull'intero array?
• Mi sto perdendo qualcosa?

Odio dire "non usare SATA" in ambienti di produzione critici, ma ho visto questa situazione abbastanza spesso. Le unità SATA non sono generalmente pensate per il ciclo di lavoro descritto, anche se nella configurazione sono state specificate unità specificatamente classificate per il funzionamento 24x7 . La mia esperienza è stata che le unità SATA possono fallire in modi imprevedibili, spesso influenzando l'intero array di archiviazione, anche quando si utilizza RAID 1 + 0, come hai fatto. A volte le unità si guastano in un modo che può bloccare l'intero bus. Una cosa da notare è se stai usando espansori SAS nella tua configurazione. Ciò può fare la differenza nel modo in cui i dischi rimanenti sono influenzati da un guasto dell'unità.

Ma potrebbe essere più sensato andare con le unità SAS midline / nearline (7200 RPM) rispetto a SATA. C'è un piccolo prezzo rispetto a SATA, ma le unità funzioneranno / guasteranno in modo più prevedibile. La correzione e la segnalazione degli errori nell'interfaccia / protocollo SAS sono più robuste rispetto al set SATA. Quindi, anche con unità i cui meccanismi sono gli stessi , la differenza del protocollo SAS potrebbe aver impedito il dolore che si è verificato durante il guasto dell'unità.

Come può un singolo disco far crollare l'array? La risposta è che non dovrebbe, ma in qualche modo dipende da cosa sta causando l'interruzione. Se il disco dovesse morire in un modo che si comportava, non dovrebbe smontarlo. Ma è possibile che non riesca in un "caso limite" che il controller non è in grado di gestire.

Sei ingenuo pensare che ciò non dovrebbe accadere? No, non la penso così. Una scheda RAID hardware del genere avrebbe dovuto gestire la maggior parte dei problemi.

Come prevenirlo? Non puoi anticipare casi strani come questo. Questo fa parte dell'essere un amministratore di sistema ... ma puoi lavorare sulle procedure di recupero per evitare che influisca sul tuo business. L'unico modo per provare a risolvere questo problema ora è provare un'altra scheda hardware (probabilmente non quella che vorresti fare) o cambiare le tue unità in unità SAS invece di SATA per vedere se SAS è più affidabile. Puoi anche contattare il tuo fornitore della scheda RAID e dire loro cosa è successo e vedere cosa dicono; sono, dopo tutto, un'azienda che dovrebbe specializzarsi nel conoscere i dettagli dell'elettronica di azionamento traballante. Potrebbero avere più consigli tecnici su come funzionano le unità e affidabilità ... se riesci a contattare le persone giuste con cui parlare.

Ti sei perso qualcosa? Se si desidera verificare che l'unità abbia un errore del caso limite, estrarla dall'array. L'array sarà degradato ma non dovresti avere più degli strani rallentamenti ed errori (a parte lo stato dell'array degradato). Stai dicendo che in questo momento sembra funzionare bene, ma se si verificano errori di lettura del disco, è necessario sostituire l'unità mentre è possibile. A volte le unità con capacità elevata possono avere errori URE (motivo migliore per non eseguire RAID 5, nota a margine) che non vengono visualizzati fino a quando un'altra unità non si guasta. E se si verifica un comportamento a margine da quell'unità, non si desidera migrare i dati danneggiati sulle altre unità dell'array.

Non sono un esperto, ma ho intenzione di scattare una foto selvaggia nel buio sulla base della mia esperienza con controller RAID e array di archiviazione.

I dischi si guastano in molti modi diversi. Sfortunatamente, i dischi possono fallire, o essere difettosi, in modi in cui le loro prestazioni sono gravemente compromesse ma il controller RAID non vede come un fallimento.

Se un disco si guasta in modo ovvio, qualsiasi software di controller RAID dovrebbe essere abbastanza bravo a rilevare la mancanza di risposta dal disco, rimuoverlo dal pool e lanciare eventuali notifiche. Tuttavia, la mia ipotesi su ciò che sta accadendo qui è che il disco sta subendo un errore insolito che, per qualche motivo, non sta causando un errore sul lato controller. Pertanto, quando il controller sta eseguendo un flush flush o una lettura dal disco interessato, ci vuole molto tempo per tornare indietro e a sua volta sta bloccando l'intero IO operativo e quindi l'array. Per qualsiasi motivo, questo non è sufficiente per il controller RAID per andare "ah, disco guasto", probabilmente perché i dati finiscono per tornare alla fine.

Il mio consiglio sarebbe di sostituire immediatamente il disco guasto. Dopodiché, darei un'occhiata alla configurazione della tua scheda RAID (è 3ware, ho pensato che fossero abbastanza buoni) e scoprire cosa considera un disco guasto.

PS bella idea importando SMART in cactus.

Sono necessarie le funzionalità dei dispositivi di archiviazione di classe enterprise. In particolare, le unità aziendali WD RE 4 hanno due funzionalità necessarie per prevenire questo comportamento negli array RAID. La prima tecnologia elencata di seguito impedisce alle vibrazioni armoniche di rotazione di provocare un'usura inutile dei componenti meccanici del disco rigido. La seconda tecnologia è ciò che ha causato il tuo problema, il protocollo SATA non ha questa funzionalità. Per ottenere queste funzionalità hai bisogno di SAS e, se insisti sulle unità SATA, puoi acquistare le schede SAS su SATA Interposer come LSISS9252.

Tecnologia RAFF avanzata Elettronica sofisticata controlla l'azionamento e corregge le vibrazioni lineari e rotazionali in tempo reale. Il risultato è un significativo miglioramento delle prestazioni in ambienti ad alta vibrazione rispetto alla generazione precedente di azionamenti.

Ripristino errori limitato nel tempo specifico per RAID (TLER) Previene il fallout dell'unità causato dai processi estesi di recupero errori del disco rigido comuni alle unità desktop.

http://en.wikipedia.org/wiki/Error_recovery_control#Overview

Vedi anche il link seguente:

http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers

Vedi anche: Documento TLER di Western Digital che spiega in dettaglio il processo di recupero degli errori. Prevenzione errori di Fallout Recovery nei dischi rigidi ATA seriali WD Caviar RAID Edition:

http://www.3dfxzone.it/public/files/2579-001098.pdf

Solo un'ipotesi: i dischi rigidi sono configurati per riprovare su errori di lettura piuttosto che segnalare un errore. Sebbene questo sia un comportamento desiderabile in un'impostazione desktop, è controproducente in un RAID (in cui il controller dovrebbe riscrivere qualsiasi settore che non riesce a leggere dagli altri dischi, in modo che l'unità possa rimapparlo).

il mio scatto al buio:

• l'unità 7 non funziona. ha alcune finestre di errore in cui non è disponibile.

• l'unità 8 presenta anche alcuni errori "più leggeri"; corretto riprovando.

• RAID10 è in genere "un RAID0 di più coppie RAID1", i drive 7 e 8 sono membri della stessa coppia?

in tal caso, sembra che tu abbia colpito il caso "non dovrebbe succedere" di un errore su due dischi sulla stessa coppia. quasi l'unica cosa che può uccidere un RAID10. sfortunatamente, può succedere se tutte le tue unità provengono dallo stesso lotto di spedizione, quindi hanno una probabilità leggermente maggiore di morire simultaneamente.

Immagino che durante un guasto all'unità 7, il controller reindirizzi tutte le letture all'unità 8, quindi qualsiasi tentativo di errore ha causato grandi ritardi che hanno causato una valanga di attività bloccate, uccidendo le prestazioni per un po '.

sei fortunato che l'unità 8 non sembra essere ancora morta, quindi dovresti essere in grado di risolvere senza perdita di dati.

Comincerei cambiando entrambe le unità e non dimenticherò di controllare il cablaggio. una connessione allentata potrebbe causare questo, e se non instradato saldamente, è più probabile che accada in unità adiacenti. inoltre, alcune schede multiporta hanno diversi connettori a due porte, se l'unità 7 e l'unità 8 sono sullo stesso, potrebbe essere la causa del problema.

Le schede interposer SATA sono un'altra soluzione.

Di recente ho sperimentato esattamente lo stesso destino e ho trovato questa discussione. Il tenore generale è che il protocollo SAS è più adatto per RAID rispetto a SATA, perché SATA manca di funzionalità. Questo è il motivo per cui le stesse unità fisiche sono dotate di controller SAS, quindi vendute come Nearline SAS.

Cercando ulteriormente, ho trovato:

http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx

Sto studiando l'aggiornamento di uno dei miei archivi con una serie di questi. In questo momento, la differenza di prezzo tra 3 TB SATA vs SAS è del 400% (prezzo vaniglia, stessa marca, specifiche e negozio, Germania). Ovviamente non posso dire se questa strategia funzioni bene, ma vale la pena provare.

Commenti molto graditi :-)

Ho visto un disco SATA con elettronica rotta bloccare in modo solido l'iniziale del firmware di un Areca 12, non c'era modo di accedere al BIOS e tanto meno avviare la macchina da qualsiasi supporto fino a quando non è stato trovato il disco rigido offensivo estraendo i dischi in un file binario ricerca della moda.