BBWC: en teoría es una buena idea, pero ¿alguna vez ha guardado sus datos?

26

Estoy familiarizado con lo que pretende hacer un BBWC (caché de escritura con respaldo de batería), y los usé anteriormente en mis servidores incluso con un buen UPS. Obviamente hay fallas para las que no brinda protección. Tengo curiosidad por entender si realmente ofrece algún beneficio real en la práctica.

(Nota: estoy buscando específicamente respuestas de personas que tienen BBWC y tuvieron accidentes / fallas y si BBWC ayudó a la recuperación o no)

Actualizar

Después de los comentarios aquí, soy cada vez más escéptico sobre si un BBWC agrega algún valor.

Para tener alguna confianza sobre la integridad de los datos, el sistema de archivos DEBE saber cuándo los datos se han comprometido con el almacenamiento no volátil (no necesariamente el disco, un punto al que volveré). Vale la pena señalar que muchos discos mienten sobre cuándo se han enviado datos al disco ( http://brad.livejournal.com/2116715.html ). Si bien parece razonable suponer que deshabilitar la memoria caché en el disco podría hacer que los discos sean más honestos, todavía no hay garantía de que este sea el caso tampoco.

Debido a las memorias intermedias típicamente grandes en un BBWC, una barrera puede requerir una cantidad significativamente mayor de datos que se comprometerán en el disco, causando retrasos en las escrituras: el consejo general es deshabilitar las barreras cuando se usa una memoria caché de escritura no volátil (y deshabilitar en- almacenamiento en caché de disco). Sin embargo, esto parecería socavar la integridad de la operación de escritura, solo porque se mantengan más datos en un almacenamiento no volátil no significa que sea más consistente. De hecho, podría decirse que sin una demarcación entre las transacciones lógicas parece haber menos oportunidades para garantizar la coherencia que de otra manera.

Si el BBWC reconociera las barreras en el momento en que los datos ingresan en su almacenamiento no volátil (en lugar de estar comprometido con el disco), parecería satisfacer el requisito de integridad de los datos sin una penalización de rendimiento, lo que implica que las barreras aún deberían estar habilitadas. Sin embargo, dado que estos dispositivos generalmente exhiben un comportamiento consistente con el vaciado de los datos al dispositivo físico (significativamente más lento con las barreras) y el consejo generalizado de desactivar las barreras, por lo tanto, no pueden comportarse de esta manera. ¿POR QUÉ NO?

Si la E / S en el sistema operativo se modela como una serie de secuencias, entonces existe cierto margen para minimizar el efecto de bloqueo de una barrera de escritura cuando el sistema operativo gestiona el almacenamiento en caché de escritura, ya que en este nivel solo se realiza la transacción lógica (una sola secuencia ) necesita ser comprometido. Por otro lado, un BBWC sin conocimiento de qué bits de datos componen la transacción tendría que enviar toda su caché al disco. Si los sistemas kernel / files realmente implementan esto en la práctica requeriría mucho más esfuerzo del que estoy dispuesto a invertir en este momento.

Una combinación de discos que dicen mentiras sobre lo que se ha cometido y la pérdida repentina de energía indudablemente conduce a la corrupción, y con un sistema de archivos estructurado Journalling o log que no realiza un fsck completo después de una interrupción, es poco probable que se detecte la corrupción y mucho menos Se intentó repararlo.

En términos de los modos de falla, en mi experiencia, la mayoría de los apagones repentinos ocurren debido a la pérdida de la alimentación de la red eléctrica (se mitiga fácilmente con un UPS y el apagado administrado). Las personas que extraen el cable incorrecto del bastidor implica una falta de higiene en el centro de datos (etiquetado y gestión de cables). Hay algunos tipos de eventos de pérdida repentina de energía que no son evitados por un UPS: una falla en la PSU o VRM, un BBWC con barreras proporcionaría integridad de datos en caso de una falla aquí, sin embargo, ¿qué tan comunes son tales eventos? Muy raro a juzgar por la falta de respuestas aquí.

Ciertamente, mover la tolerancia a fallas más alto en la pila es significativamente más costoso que un BBWC; sin embargo, implementar un servidor como un clúster tiene muchos otros beneficios para el rendimiento y la disponibilidad.

Una forma alternativa de mitigar el impacto de la pérdida repentina de energía sería implementar un SAN - AoE hace de esto una propuesta práctica (realmente no veo el punto en iSCSI) pero nuevamente hay un costo más alto.

symcbean
fuente
3
Los servidores de archivos de NetApp han tenido durante muchos años memorias caché de escritura NVRAM, y muchos de ellos han perdido energía y no han estropeado sus sistemas de archivos. Es difícil demostrar que algo salvó a uno, porque desde que uno se salvó, el desastre no sucedió; ¿Qué evidencia estarías buscando?
MadHatter apoya a Monica el
Podría decirse que también debe pensar en los modos de falla de un caché de escritura respaldado por batería frente a un caché de escritura sin batería.
Stefan Lasiewski
1
No es una encuesta, he pasado mucho tiempo investigando esto, y puedo encontrar mucha información sobre lo que se supone que debe hacer el BBWC, pero muy poca información sobre los beneficios que se han obtenido en la práctica. Tenga en cuenta que la única respuesta que he tenido a continuación cuando alguien dice que un BBWC ha guardado sus datos es donde no hubo un apagado administrado en caso de una falla de energía. Hasta ahora, nada ha refutado mi sospecha de que: si bien un BBWC puede guardar sus datos en algunas circunstancias, estas circunstancias pueden evitarse por otros medios.
symcbean
1
No, eso es evidencia de que no tener BBWC puede perder sus datos . Demostrando eso, y sospecho que la mayoría de los administradores de sistemas de larga distancia en este sistema tienen historias donde se perdieron datos volátiles en cortes de energía; Lo más seguro es que no probaría que tener BBWC puede guardar sus datos , que es lo que solicitó el OP.
MadHatter apoya a Monica el
1
Algunos análisis y modelos adicionales sugieren que BBWC + sin barreras puede conducir a la corrupción no detectada con cualquier planificador de E / S que no sea NOOP (podría estar equivocado al respecto, pero he intentado encontrar pruebas que sugieran lo contrario). Ver también symcbean.blogspot.co.uk/2014/03/…
symcbean

Respuestas:

34

Seguro. He tenido un caché respaldado por batería (BBWC) y luego un caché de escritura respaldado por flash (FBWC) para proteger los datos en vuelo después de fallas y pérdida repentina de energía.

En los servidores HP ProLiant, el mensaje típico es:

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

Lo que significa, " ¡Oye, hay datos en la caché de escritura que sobrevivieron al reinicio / pérdida de energía! ¡Voy a escribir eso en el disco ahora! "

Un caso interesante fue mi autopsia de un sistema que perdió energía durante un tornado , la secuencia de la matriz fue:

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

El error 1793 POST es único. - Mientras el sistema estaba en uso, la energía se interrumpió mientras los datos estaban en la memoria del Acelerador de matriz. Sin embargo, debido al hecho de que se trataba de un tornado, la energía no se restableció en cuatro días, por lo que las baterías del conjunto se agotaron y se perdieron los datos. El servidor tenía dos controladores RAID. El otro controlador tenía una unidad FBWC, que dura mucho más que una batería. Esa unidad se recuperó correctamente. Se produjo cierta corrupción de datos en la matriz respaldada por la batería vacía.


A pesar del tiempo de duración de la batería en la instalación, cuatro días sin energía y condiciones peligrosas hicieron imposible que cualquiera cerrara los servidores de manera segura. ingrese la descripción de la imagen aquí

ewwhite
fuente
55
Muy informativo, buen trabajo para mantener esos resultados durante el tiempo que sea necesario.
deed02392
¡Interesante! Me pregunto si HP planea incluir en los controladores Smart Arrays el mismo caché sin batería que pusieron en el P2000
Gabriel Talavera
44
@GabrielTalavera Sí, HP ha estado utilizando caché con respaldo de flash (condensadores) desde 2010 más o menos. No más pilas.
ewwhite
Lo mismo aquí usando Adaptec;) No más preocupaciones y reemplazos regulares.
TomTom
Gracias ewwhite, exactamente el tipo de cosas que estoy buscando. Una pregunta: ¿qué pasó con la alimentación del UPS? ¿Su UPS no daña el sistema cuando está bajo?
symcbean
10

Sí, tenía ese caso.

Servidor "sin UPS" en un centro de datos (con el centro de datos que tiene un UPS). Falla de la PDU: el sistema se bloqueó con fuerza. Sin pérdida de datos.

Y eso básicamente es todo. Lo bueno de un BBWC es que está en la máquina. Tenga un UPS: créame, a veces alguien hace algo estúpido (como tirar del cable equivocado). Un UPS es externo. Oh, ESE cable;)

TomTom
fuente
Gracias TomTom Por lo tanto, le permite avanzar sus datos a la siguiente barrera en lugar de retroceder a la anterior (a menos que no use el diario o registre sistemas de archivos estructurados). Este es uno de los puntos clave que estoy tratando de evaluar aquí. Parecería una retención marginalmente mejor para un rol de servidor de archivos, pero no ayuda con la integridad del sistema de archivos o de la base de datos OLTP.
symcbean
Acutalmente lo haría: OLTP está estructurado para manejar las fallas de alimentación del servidor con gracia siempre que las escrituras de registro se escriban de forma aguda;) Y como la velocidad de E / S del registro es limitada, las "escrituras falsas" (informadas por el controlador de ataque) dan velocidad, pero a riesgo de pérdida de datos, a menos que tenga un caché no volátil.
TomTom
Observo que RedHat opina que debe desactivar las barreras con BBWC; si bien eso mejorará el rendimiento, no brinda protección en caso de una interrupción repentina, como una pérdida de energía, ¡erk! access.redhat.com/site/documentation/en-US/…
symcbean
@symcbean No debería tener una pérdida repentina de energía en su entorno. Esa es una de las situaciones más fáciles de prevenir. ¿Por qué hacer que su servidor funcione como basura el 100% del tiempo para un evento relativamente infrecuente?
ewwhite
1
En realidad, la razón por la que existe un BBWC es para mitigar el problema de una pérdida repentina de energía. Por lo tanto, está bien no tener barreras.
TomTom
4

He tenido 2 casos donde la memoria caché respaldada por batería en los controladores RAID HW falló por completo (en 2 compañías separadas).

BBC confía en la sorprendente idea de que la batería funciona. El problema es que, en algún momento, la batería del controlador falla y lo devastador es que en muchos controladores de ataque HW falla silenciosamente . Pensamos que teníamos un caché protegido contra la pérdida de energía, pero no lo hicimos.

En caso de pérdida de energía, la pérdida de datos de la matriz RAID fue tan extensa que todo el contenido del disco se volvió irrecuperable. Todo estaba perdido Uno de los casos involucraba una máquina dedicada por completo a las pruebas, pero aún así.

Después de eso dije "nunca más", cambié a la duplicación de disco basada en software (mdadm) en Linux + fs basado en el diario que tiene una resistencia decente contra la pérdida de energía (ext4) y nunca miré hacia atrás. De acuerdo, lo he usado en servidores que no tenían un uso de E / S extremadamente alto.

LetMeSOThat4U
fuente
Gracias JD: aunque no específicamente sobre lo que estaba preguntando, puedo ver que esto tiene mucha relevancia para los supuestos que la gente hace sobre BBWC. Resuena con gran parte de la discusión sobre RAID de hardware frente a software, creo que debería advertir a la posteridad que el software RAID no excluye el uso de un controlador de almacenamiento en caché (volátil o de otro tipo).
symcbean
Las tarjetas de banda IME, Dell y HP se quejarán (suponiendo que tenga un sistema de monitoreo adecuado) por baterías defectuosas en un BBWC.
mfinni
Los procedimientos adecuados para BBWC deben incluir la prueba de la batería; por ejemplo, los controladores 3ware le avisarán si la batería no se ha probado durante un período de tiempo prolongado, y es fácil comprobar que la batería todavía está en buen estado (el único inconveniente es que la memoria caché de escritura está deshabilitado durante la prueba).
iustin
4

Esto parece requerir una segunda respuesta a la pregunta ...

Acabo de tener un host VMware ESXi independiente que pierde una unidad en una matriz RAID 5. La matriz degradada afectó el rendimiento a nivel de VM y aplicación.

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 de TI de esta empresa no sabía que una unidad fallaba y reinició el servidor (¿ para mejorarlo todo? ).

El efecto interesante de hacer esto en una matriz comprometida con máquinas virtuales ocupadas ejecutándose en la parte superior fue este:

Detalles del estado de la memoria caché: el controlador de la matriz actual tenía datos válidos almacenados en su memoria caché de escritura respaldada por batería / condensador la última vez que se restableció o se encendió. Esto indica que es posible que el sistema no se haya apagado correctamente. El controlador de matriz ha escrito automáticamente, o ha intentado escribir, estos datos en las unidades. Este mensaje continuará mostrándose hasta el próximo reinicio o ciclo de encendido del controlador de matriz.

Entonces, aunque el sistema se detuvo abruptamente, los datos en vuelo estaban protegidos por el BBWC. Todas las máquinas virtuales se recuperaron correctamente y el sistema está en buen estado ahora.

ewwhite
fuente
3

Además de "guardar sus datos", son buenos para otras cosas. También son buenos para almacenar las escrituras en el búfer (en la memoria caché) para mejorar el rendimiento del subsistema IO manteniendo baja la cola de escritura en disco. Esto es particularmente importante para los servidores donde el rendimiento interactivo es primordial, por ejemplo, Citrix XenApp o Windows Terminal Services.

Esto es menos importante para un servidor web o un servidor de archivos. Es posible que no note, o incluso esté acostumbrado a, un pequeño retraso. Sin embargo, cuando hace clic en un icono en una aplicación de Office, espera capacidad de respuesta. Y también tu CEO.

mfinni
fuente
"Estoy familiarizado con lo que pretende hacer un BBWC (caché de escritura con respaldo de batería)"
symcbean
2
También dijo: "Tengo curiosidad por entender si realmente ofrece algún beneficio real en la práctica". Te di (y futuros lectores) uno concreto. De su pregunta, no estaba nada claro que supiera sobre este beneficio. Y mi respuesta no es incorrecta.
mfinni
Entonces, ¿cómo difieren los puntos que hizo de un caché de escritura volátil?
symcbean
Obviamente esa era la característica que conocías. Pero de nuevo, no lo dejaste claro. @mfinni solo está siendo útil.
deed02392
Algunos sistemas no le permitirán habilitar un caché de escritura volátil, así que eso es todo. Pero no, si no le importan los datos y puede usar un caché de escritura volátil, entonces hágalo.
mfinni