Resumen
Entre el 29 de octubre y el 1 de noviembre de 2024, cuarenta y un discos NVMe empresariales en cuatro sitios dejaron de aceptar comandos a un contador fijo de horas de encendido, un defecto de firmware en un lote de fabricación. El espejo absorbió treinta y nueve de esos fallos sin impacto para el cliente. Un nodo en Varsovia perdió ambas mitades de un espejo en cuarenta minutos, porque ambos discos provenían del mismo lote y se montaron el mismo día. Dos instancias en ese nodo perdieron datos. Esa segunda parte fue culpa nuestra, no del proveedor.
Cronología
Todas las horas en UTC.
| Hora | Evento |
|---|---|
| 29 Oct 03:11 | Un disco se desconecta del bus en un nodo de Varsovia. El espejo se degrada, el hot spare comienza a reconstruirse. Rutinario, sin alerta. |
| 29 Oct 03:49 | El segundo disco del mismo espejo se desconecta. El nodo pierde su pool raíz y se detiene. |
| 29 Oct 03:52 | Salta la alerta. El de guardia se conecta a las 03:55. |
| 29 Oct 04:20 | El nodo se declara irrecuperable en su lugar. Reconstruir desde el hot spare es imposible; el spare estaba a mitad de reconstrucción desde una fuente que ya no responde. |
| 29 Oct 05:40 | Un ingeniero que revisa los registros del disco nota que los dos fallos están separados por dieciocho horas de encendido, no por dieciocho meses. La sospecha pasa de mala suerte a cohorte. |
| 29 Oct 06:15 | Consulta en toda la flota por identificador de lote y horas de encendido. Doscientos seis discos están en el lote afectado. Treinta y uno ya han pasado el contador y han fallado; el resto están entre cuarenta y novecientas horas de distancia. |
| 29 Oct 07:30 | Se contacta al proveedor. Defecto confirmado en cuatro horas: un contador en la telemetría de nivelación de desgaste se desborda a las 1,536 horas de encendido y bloquea el controlador. Una revisión de firmware que lo corregía se había publicado, en silencio, seis semanas antes. |
| 29 Oct 09:00 | Comienza la actualización de firmware por rodillo, priorizando por horas restantes. |
| 30 Oct 22:40 | Último disco del lote actualizado o reemplazado. |
| 1 Nov 14:00 | Instancias de clientes afectadas restauradas o reembolsadas. |
Causa raíz
Dos causas, y solo una de ellas pertenece al fabricante del disco.
La suya: un contador de telemetría se desbordó a un contador fijo de horas de encendido y bloqueó el controlador. El disco sobrevive a un ciclo de alimentación, vuelve y se bloquea de nuevo en minutos. Los datos en el plato están intactos e inalcanzables, lo cual es la peor combinación para cualquiera que intente diagnosticar a las cuatro de la mañana.
La nuestra: construimos espejos con discos que llegaron en el mismo envío. Un espejo debe ser dos dominios de fallo independientes, y dos discos del mismo lote, montados la misma tarde, encendidos dentro de la misma hora, no son independientes en ningún sentido que importe. Once espejos en toda la flota se construyeron así. Diez tuvieron suerte de que el hot spare terminara de reconstruirse primero. Uno no.
Sabíamos esto en principio desde hacía años. Nadie lo había escrito en el procedimiento de construcción, y el procedimiento de construcción es lo que la gente sigue a las dos de la mañana con una fecha de entrega.
Impacto
- Treinta y nueve fallos absorbidos por espejos sin efecto visible para el cliente.
- Un nodo fuera de línea durante nueve horas y dieciocho minutos.
- Catorce instancias en ese nodo restauradas desde copias de seguridad fuera del nodo, perdiendo como máximo once minutos de escrituras.
- Dos instancias sin copia de seguridad de ningún tipo. Ambas perdieron todo en el nodo.
Lo que cambiamos
- Se dividen los lotes de compra. Dos discos del mismo lote no pueden formar un espejo, y el hot spare que protege un par proviene de un tercer lote. Aplicado por las herramientas de construcción, no por un documento. Hecho el 4 de noviembre.
- Alertas de cohorte por horas de encendido. Ahora alertamos cuando más de cuatro discos que comparten un identificador de lote están dentro de cien horas entre sí y se acercan a cualquier número redondo de horas. Es una heurística tosca y habría detectado esto diecinueve días antes.
- Firmware en remojo antes de producción. Una nueva familia de discos pasa dos mil horas de encendido en un bastidor de pruebas antes de llevar datos de clientes. Este defecto habría aparecido a las 1,536.
- Ahora leemos las notas de versión del firmware del proveedor con regularidad. La corrección existía seis semanas antes de que la necesitáramos. Nadie fue asignado a mirar, así que nadie miró.
Lo que no cambiamos y por qué
No cambiamos de familia ni de proveedor de discos. El defecto era real y la divulgación fue pobre, pero nuestra pérdida vino de un lote correlacionado, que habríamos reproducido con cualquier fabricante. Cambiar habría parecido decisivo y no habría arreglado nada.
La copia de seguridad fuera del nodo sigue siendo un extra a nueve euros por quinientos gigabytes. Hacerla universal significa facturar a cada cliente por un servicio que la mayoría replica por sí mismo, y no vamos a cobrar a la gente por la apariencia de seguridad. Lo que sí cambió es el formulario de pedido, que ahora declara claramente que el almacenamiento de instancia está en espejo y que el espejo no es una copia de seguridad, y el paso de confirmación ya no permite que esa frase se omita en silencio.
No pasamos a triple espejo. Cuesta un tercio más por gigabyte y no aborda el fallo correlacionado, que fue el mecanismo real aquí. Dos dominios independientes superan a tres dependientes.
Los dos clientes
Ambos fueron reembolsados en su totalidad por el período afectado, en el activo con el que pagaron, sin que se les pidiera justificación. Uno se fue. El otro se quedó y ahora compra el extra de copia de seguridad, habiendo leído la misma frase en el formulario de pedido que ya estaba allí en una forma más débil.
Ninguno de esos resultados estaba en nuestra mano. Lo único que estaba en nuestra mano era construir el espejo correctamente, y no lo hicimos.