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

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.

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.

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;)

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.

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.

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.