BBWC: in teoria una buona idea ma ne hai mai salvati i dati?


26

Ho familiarità con ciò che una BBWC (cache di scrittura supportata da batteria) è destinata a fare - e li ho precedentemente utilizzati nei miei server anche con un buon UPS. Ci sono ovviamente fallimenti per cui non fornisce protezione. Sono curioso di capire se in realtà offre qualche reale vantaggio.

(NB Sto specificatamente cercando risposte da persone che hanno BBWC e hanno avuto crash / fallimenti e se il BBWC ha aiutato il recupero o meno)

Aggiornare

Dopo il feedback qui, sono sempre più scettico sul fatto che un BBWC aggiunga valore.

Per avere fiducia nell'integrità dei dati, il filesystem DEVE sapere quando i dati sono stati sottoposti a memorizzazione non volatile (non necessariamente il disco - un punto su cui tornerò). Vale la pena notare che molti dischi mentono su quando i dati sono stati impegnati sul disco ( http://brad.livejournal.com/2116715.html ). Anche se sembra ragionevole supporre che la disabilitazione della cache su disco possa rendere i dischi più onesti, non è ancora garantito che sia così.

A causa dei buffer tipicamente grandi in un BBWC, una barriera può richiedere un numero significativamente maggiore di dati da trasferire su disco, causando ritardi nelle scritture: il consiglio generale è di disabilitare le barriere quando si utilizza una cache di riscrittura non volatile (e disabilitare on- memorizzazione nella cache del disco). Tuttavia, ciò sembrerebbe minare l'integrità dell'operazione di scrittura - solo perché un numero maggiore di dati viene conservato in un archivio non volatile non significa che sarà più coerente. In effetti, senza dubbio, senza demarcazione tra le transazioni logiche, sembra che ci sia meno opportunità di garantire coerenza che in altro modo.

Se la BBWC dovesse riconoscere le barriere nel momento in cui i dati entrano nella sua memoria non volatile (piuttosto che impegnarsi su disco), sembrerebbe soddisfare i requisiti di integrità dei dati senza una penalità di prestazione, il che implica che le barriere dovrebbero essere ancora abilitate. Tuttavia, poiché questi dispositivi presentano generalmente un comportamento coerente con lo scaricamento dei dati sul dispositivo fisico (significativamente più lento con le barriere) e i consigli diffusi per disabilitare le barriere, non possono quindi comportarsi in questo modo. PERCHÈ NO?

Se l'I / O nel sistema operativo è modellato come una serie di flussi, esiste un margine per ridurre al minimo l'effetto di blocco di una barriera di scrittura quando la cache di scrittura è gestita dal sistema operativo, poiché a questo livello solo la transazione logica (un singolo flusso ) deve essere impegnata. D'altra parte, un BBWC senza sapere quali bit di dati compongono la transazione dovrebbe impegnare l'intera cache su disco. Se il kernel / filesystem effettivamente implementerà questo in pratica richiederebbe molto più sforzo di quello che sto per investire al momento.

Una combinazione di dischi che raccontano le ragioni di ciò che è stato commesso e la perdita improvvisa di potere indubbiamente porta alla corruzione - e con un filesystem strutturato su Journalling o log che non fa un completo colpo dopo un'interruzione è improbabile che la corruzione venga rilevata e tanto meno un tentativo di ripararlo.

In termini di modalità di guasto, nella mia esperienza la maggior parte delle interruzioni improvvise si verificano a causa della perdita di alimentazione di rete (facilmente mitigabile con un UPS e spegnimento gestito). Le persone che tirano il cavo sbagliato dal rack implicano una scarsa igiene del datacenter (etichettatura e gestione dei cavi). Esistono alcuni tipi di eventi improvvisi di perdita di potenza che non sono evitati da un UPS: un guasto nell'alimentatore o VRM un BBWC con barriere fornirebbe integrità dei dati in caso di guasto qui, tuttavia quanto sono comuni tali eventi? Molto raro a giudicare dalla mancanza di risposte qui.

Certamente spostare la tolleranza ai guasti più in alto nello stack è significativamente più costoso di un BBWC, tuttavia l'implementazione di un server come cluster ha molti altri vantaggi in termini di prestazioni e disponibilità.

Un modo alternativo per mitigare l'impatto di un'improvvisa perdita di potenza sarebbe quello di implementare una SAN - AoE rende questa una proposta pratica (non vedo davvero il punto in iSCSI) ma di nuovo c'è un costo più elevato.


3
I file server NetApp hanno da molti anni cache di scrittura NVRAM e ho avuto un buon numero di quelli che perdono energia e non distruggono i loro file system. È difficile dimostrare che qualcosa l'ha salvato, perché da quando uno è stato salvato, il disastro non è accaduto; quali prove avresti cercato?
MadHatter supporta Monica il

Probabilmente, dovresti anche pensare alle modalità di errore di una cache di scrittura con batteria contro una cache di scrittura senza batteria.
Stefan Lasiewski,

1
Non un sondaggio - ho trascorso molto tempo a indagare su questo - e posso trovare molte informazioni su cosa dovrebbe fare il BBWC - ma pochissime informazioni su quali benefici sono stati realizzati nella pratica. Si noti che l'unica risposta che ho ricevuto di seguito in cui qualcuno dice che un BBWC ha salvato i propri dati è dove non si è verificato alcun arresto gestito in caso di mancanza di corrente. Finora nulla ha confutato il mio sospetto che: mentre un BBWC può salvare i tuoi dati in alcune circostanze, queste circostanze possono essere evitabili con altri mezzi.
symcbean,

1
No, questa è la prova che non avere BBWC può perdere i tuoi dati . Dimostrando che - e sospetto che la maggior parte degli amministratori di sistema a lungo raggio su questo sistema abbia storie in cui i dati volatili sono stati persi in mancanza di corrente; Certamente, non proverei che avere BBWC può salvare i tuoi dati , che è ciò che l'OP ha richiesto.
MadHatter supporta Monica il

1
Alcune ulteriori analisi e modellazioni suggeriscono che BBWC + nessuna barriera può portare a corruzione non rilevata con qualsiasi scheduler IO diverso da NOOP (potrei sbagliarmi su questo, ma ho cercato molto duramente di trovare prove per suggerire diversamente). Vedi anche symcbean.blogspot.co.uk/2014/03/…
symcbean

Risposte:


34

Sicuro. Ho avuto la cache di backup a batteria (BBWC) e successivamente la cache di scrittura di backup flash (FBWC) proteggono i dati in volo a seguito di arresti anomali e improvvisa perdita di potenza.

Sui server HP ProLiant, il messaggio tipico è:

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

Il che significa " Ehi, ci sono dati nella cache di scrittura che sono sopravvissuti al riavvio / interruzione dell'alimentazione !! Ora li scrivo di nuovo su disco !! "

Un caso interessante è stato il mio post mortem di un sistema che ha perso potenza durante un tornado , la sequenza di array è stata:

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

L'errore POST 1793 è unico. - Durante l'utilizzo del sistema, l'alimentazione è stata interrotta mentre i dati erano nella memoria dell'acceleratore di array. Tuttavia, a causa del fatto che si trattava di un tornado, l'alimentazione non è stata ripristinata entro quattro giorni, quindi le batterie dell'array sono state esaurite e i dati all'interno sono andati persi. Il server aveva due controller RAID. L'altro controller aveva un'unità FBWC, che dura molto più a lungo di una batteria. Quell'unità si è ripristinata correttamente. Una certa corruzione dei dati ha provocato l'array supportato dalla batteria scarica.


Nonostante l'abbondanza di autonomia della batteria presso la struttura, quattro giorni senza alimentazione e condizioni pericolose hanno reso impossibile per chiunque arrestare i server in modo sicuro. inserisci qui la descrizione dell'immagine


5
Molto istruttivo, ottimo lavoro nel mantenere tali risultati per tanto tempo.
deed02392

Interessante! Mi chiedo se HP abbia intenzione di includere nei controller Smart Arrays la stessa cache senza batteria che hanno inserito nel P2000
Gabriel Talavera,

4
@GabrielTalavera Sì, HP utilizza cache con flash (condensatori) dal 2010 o giù di lì. Niente più batterie.
ewwhite,

Lo stesso qui usando Adaptec;) Niente più preoccupazioni e sostituzioni regolari.
TomTom

Grazie ewwhite - esattamente il tipo di cosa che sto cercando. Una domanda: cosa è successo alla potenza dell'UPS? Il tuo UPS non disattiva il sistema quando è in esaurimento?
Symbbean,

10

Sì, aveva quel caso.

Server "senza UPS" in un data center (con il data center con un UPS). Errore PDU: il sistema si è arrestato in modo anomalo. Nessuna perdita di dati.

E questo è fondamentalmente. La cosa buona di un BBWC è che è nella macchina. Avere un UPS - credimi, a volte qualcuno fa qualcosa di stupido (come tirare il cavo sbagliato). Un UPS è esterno. Oh, quel cavo;)


Grazie TomTom. Quindi ti permette di far avanzare i tuoi dati alla barriera successiva invece di riportarli alla precedente (a meno che tu non usi journaling o registri filesystem strutturati). Questo è uno dei punti chiave che sto cercando di valutare qui. Sembrerebbe offrire una conservazione leggermente migliore per un ruolo di fileserver, ma non aiuta con l'integrità del filesystem o del DB OLTP.
symcbean,

Acutally lo farebbe - OLTP è strutturato per gestire in modo corretto le interruzioni dell'alimentazione del server fintanto che le scritture del registro sono scritte in modo normale;) E poiché la velocità di I / O del registro sta limitando, le "scritture false" (riportate dal suo controller del raid) danno velocità - ma a rischio di perdita di dati, a meno che non si disponga di una cache non volatile.
TomTom

Noto che RedHat è dell'opinione che dovresti disabilitare le barriere con BBWC - mentre ciò migliorerà le prestazioni, non fornisce protezione in caso di un'interruzione improvvisa come la perdita di potenza - erk! access.redhat.com/site/documentation/en-US/…
symcbean

@symcbean Non dovresti avere improvvise perdite di potenza nel tuo ambiente. Questa è una delle situazioni più facili da prevenire. Perché far funzionare il tuo server come una schifezza il 100% delle volte per un evento relativamente poco frequente?
ewwhite,

1
In sostanza, l'intera ragione per cui esiste un BBWC è mitigare il problema di una perdita improvvisa di potenza. Quindi va bene non avere barriere.
TomTom

4

Ho avuto 2 casi in cui la cache di backup della batteria nei controller RAID HW non è riuscita completamente (in 2 società separate).

La BBC fa affidamento sull'idea non sorprendente che la batteria funzioni. Il problema è che a un certo punto la batteria del controller si guasta e la cosa devastante è che in molti controller di raid HW si guasta in silenzio . Pensavamo di avere una cache protetta contro la perdita di potenza, ma non lo abbiamo fatto.

In caso di interruzione dell'alimentazione, la perdita di dati dell'array RAID era così estesa che tutto il contenuto del disco era reso irrecuperabile. Tutto è andato perduto. Uno dei casi riguardava una macchina interamente dedicata ai test, ma comunque.

Dopodiché ho detto "mai più", sono passato al mirroring del disco basato su software (mdadm) in fs basati su diario Linux + che ha una buona resilienza contro la perdita di potenza (ext4) e non ha mai guardato indietro. Certo, l'ho usato su server che non avevano un uso IO estremamente elevato.


Grazie JD: anche se non specificamente quello che mi chiedevo, posso vedere che questo ha molta rilevanza per le ipotesi che le persone fanno su BBWC. Risuona molto con la discussione sull'hardware rispetto al software RAID, penso che dovrei escludere i posteri che il software RAID non preclude l'uso di un controller di cache (volatile o altro).
Symbbean,

Le carte raid IME, Dell e HP si lamenteranno (supponendo che abbiate un sistema di monitoraggio adeguato) delle batterie guaste in un BBWC.
mfinni

Le procedure corrette per BBWC devono includere il test della batteria - ad esempio, i controller 3ware ti avviseranno se la batteria non è stata testata per un certo periodo di tempo ed è facile verificare che la batteria sia ancora in buone condizioni (l'unico aspetto negativo è che la cache di scrittura è disabilitato durante il test).
Iustin,

4

Ciò sembra richiedere una seconda risposta alla domanda ...

Ho appena avuto un host ESXi VMware standalone perdere un'unità in un array RAID 5. L'array degradato ha influito sulle prestazioni a livello di VM e di applicazione.

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

La persona IT di questa azienda non era a conoscenza del fallimento di un'unità e ha ripristinato a fondo il server ( per rendere tutto migliore? ).

L'effetto interessante di fare questo su un array compromesso con macchine virtuali occupate in esecuzione era questo:

Dettagli sullo stato della cache: il controller di array corrente aveva dati validi memorizzati nella sua cache di scrittura supportata da batteria / condensatore l'ultima volta che è stato ripristinato o acceso. Ciò indica che il sistema potrebbe non essere stato spento correttamente. Il controller di array ha automaticamente scritto o ha tentato di scrivere questi dati sulle unità. Questo messaggio continuerà a essere visualizzato fino al successivo ripristino o ciclo di accensione del controller di array.

Quindi, anche se il sistema è stato arrestato bruscamente, i dati in volo sono stati protetti dal BBWC. Le macchine virtuali sono state tutte ripristinate correttamente e il sistema ora è in buone condizioni.


3

Oltre a "salvare i tuoi dati", sono utili anche per altre cose. Sono anche bravi nel buffering delle scritture (nella cache) in modo da migliorare le prestazioni del sottosistema IO mantenendo bassa la coda di scrittura del disco. Ciò è particolarmente importante per i server in cui le prestazioni interattive sono fondamentali, ad esempio Citrix XenApp o Windows Terminal Services.

Questo è meno importante per un server web o un file server. Potresti non notare, o addirittura essere abituato, un po 'di ritardo. Tuttavia, quando fai clic su un'icona in un'applicazione di Office, ti aspetti reattività. E anche il tuo CEO.


"Ho familiarità con ciò che una BBWC (cache di scrittura supportata da batteria) è destinata a fare"
symcbean

2
Hai anche detto: "Sono curioso di capire se in realtà offre qualche reale vantaggio in pratica". Ho dato a te (e ai futuri lettori) uno concreto. Dalla tua domanda, non era affatto chiaro che tu sapessi di questo vantaggio. E la mia risposta non è sbagliata.
mfinni,

Quindi, in che modo i punti che hai fatto differiscono da una cache di scrittura volatile?
Symbbean,

Ovviamente quella era la caratteristica di cui eri a conoscenza. Ma ancora una volta, non lo hai chiarito. @mfinni è solo utile.
deed02392

Alcuni sistemi non ti permetteranno di abilitare una cache di scrittura volatile, quindi c'è quello. Ma no, se non ti interessano i dati e puoi usare una cache di scrittura volatile, allora provaci.
mfinni,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.