Análisis post mortem de la interrupción del servicio de Tarsnap

• El servidor central de Tarsnap se cayó en Amazon EC2 us-east-1 con failed system status check, y el servicio estuvo interrumpido durante aproximadamente 26 horas y 16 minutos desde alrededor de 2023-07-02 13:07:58 UTC
• La falla fue detectada a las 13:10 UTC, pero tras un reinicio inesperado se aplicó la política operativa de mantener desactivado el arranque automático del código del servidor para que una persona lo revisara directamente
• La recuperación se realizó leyendo los encabezados de metadatos del sistema de archivos con estructura de log en Amazon S3 y reproduciendo en orden las operaciones localmente; la primera etapa terminó a las 2023-07-03 01:49:49 UTC
• Durante la reconstrucción del estado salieron a la luz un caso no validado del manejo de machine re-owned implementado en 2014 y la omisión de reinicialización de la lógica de reanudación, además de que el límite de rendimiento del disco retrasó la recuperación
• Aunque Tarsnap no tiene un SLA explícito, siguiendo su política de otorgar créditos en incidentes que considera justos, el 2023-07-13 entregó a todas las cuentas un crédito del 50% del costo mensual de almacenamiento

---

Ocurrencia de la falla y respuesta inicial

• Alrededor de 2023-07-02 13:07:58 UTC, el servidor central de Tarsnap quedó offline en la región us-east-1 de Amazon EC2
  • El estado de EC2 era failed system status check
  • En una máquina virtual, este estado puede apuntar a varias causas, como un corte de energía, una falla de hardware del servidor físico o un problema de red de EC2
  • En ese mismo momento no se veían reportes de una falla amplia en EC2, así que se consideró más probable una falla aislada de hardware
• El monitoreo detectó la falla a las 2023-07-02 13:10 UTC
  • La supervisión se hacía ejecutando cada 5 minutos escritura, lectura y eliminación de archivos de respaldo desde otras regiones de EC2
  • La alerta por SMS de las 13:10 UTC no logró despertar al responsable, pero la alerta telefónica de las 13:15 UTC inició la respuesta
  • Como en la investigación inicial no se veía un error transitorio claro, se asumió que el sistema había muerto y se empezó a preparar una instancia alternativa de EC2

Política operativa para evitar el reinicio automático

• Alrededor de 2023-07-02 13:52 UTC, Amazon reinició el servidor afectado en una nueva instancia de EC2
  • Esto ocurrió unos 45 minutos después del inicio de la falla
  • El sistema operativo, FreeBSD, sí arrancó, pero el código del servidor de Tarsnap no se inició automáticamente
• La razón para desactivar el arranque automático era poder verificar manualmente el estado antes de recibir tráfico después de un reinicio inesperado
  • Según la política operativa, “evitar la pérdida de datos cuando algo se rompe” es más importante que “maximizar la disponibilidad del servicio”
• Después del reinicio, los logs del servidor mostraban corrupción del sistema de archivos
  • Se consideró que la causa de la falla había destruido el hardware o cortado la conexión entre el servidor y el Elastic Block Store que contenía el sistema de archivos
  • Se decidió seguir configurando un servidor nuevo en vez de intentar recuperar el servidor existente

Estructura de log en S3 y procedimiento de recuperación

• El servicio de Tarsnap guarda los datos en Amazon S3 como un sistema de archivos con estructura de log
  • Cada objeto de S3 contiene un encabezado con los metadatos de todas las entradas del log y, opcionalmente, los datos de la entrada del log
  • La entrada de log start write transaction solo tiene un encabezado que identifica la máquina y el nonce de la transacción, y no incluye datos de log
  • La entrada de log store data block incluye tanto un encabezado que identifica la máquina y el nombre del bloque como los datos del bloque
• En estado normal, los metadatos de las entradas del log se almacenan en caché en EC2 y no se vuelven a leer desde Amazon S3
  • Las lecturas desde Amazon S3 solo ocurren cuando se leen datos de bloques para responder a solicitudes de clientes de tarsnap
• La recuperación del estado de la instancia de EC2 se dividió en dos etapas
  • Primero se leyeron desde S3 todos los encabezados de metadatos
  • Después se reprodujeron (replay) todas las operaciones localmente
  • En un almacenamiento con estructura de log, cuando se borran datos las entradas del log se vuelven a escribir para recuperar espacio, así que no se pueden realizar ambas etapas al mismo tiempo
  • Las entradas del log tienen números de secuencia para poder reproducirlas en el orden correcto, pero primero hay que ordenarlas después de encontrarlas

Defectos y cuellos de botella detectados durante la recuperación

• La primera etapa avanzó sin problemas y terminó a las 2023-07-03 01:49:49 UTC
  • El proceso de recuperación estaba configurado para enviar 250 solicitudes concurrentes a Amazon S3
  • Ese valor estaba ajustado a lo que Amazon S3 podía manejar hace 10 años, y probablemente hoy se habría podido aumentar bastante
• La segunda etapa falló casi de inmediato
  • Apareció un error indicando que las entradas de log reproducidas registraban datos pertenecientes a una máquina que no existía
  • La causa estaba en el código escrito en 2014 para manejar el traslado de cuentas de máquina
  • Cuando un usuario de Tarsnap necesitaba mover una máquina entre cuentas, se guardaba una nueva entrada de log machine registration y se borraba la entrada anterior
  • Había pruebas, pero faltaba el caso de reconstruir el estado del servidor después de que una máquina fuera re-owned con datos ya almacenados
  • Como el número de secuencia de la nueva entrada de registro de máquina era más alto, durante la reproducción parecía que se estaban guardando datos en una máquina que todavía no existía
• Una vez identificada la causa, se desactivó ese “seatbelt” y se reanudó la reconstrucción del estado
  • Poco después apareció un error indicando que no se podían encontrar datos en Amazon S3
  • Esto ocurrió porque, al reanudar, se saltó la etapa de descarga de datos de S3 y el valor de maximum log entry sequence number no se reinicializó, por lo que quedó en 0
  • Después de corregir ese problema, la reconstrucción del estado continuó con normalidad
• La reconstrucción del estado avanzó más lento de lo necesario
  • Si se hubiera identificado antes que el cuello de botella era el rendimiento del disco, se podría haber configurado un mayor throughput para el volumen EBS correspondiente
  • La falta de sueño impidió vigilar el proceso con el nivel de detalle necesario; de otro modo, se habría podido detectar el cuello de botella con gstat(8) y Amazon CloudWatch y reconfigurar el volumen EBS

Reanudación del servicio y entrega de créditos

• Alrededor de 2023-07-03 15:10 UTC, el proceso de reconstrucción del estado terminó
  • No se registró la hora exacta de finalización
  • El servidor se dejó en modo de solo lectura y se realizaron pruebas rápidas
  • Se verificó, comparándolo con el estado del servidor anterior, que coincidiera salvo por los últimos segundos de datos que el sistema de archivos del servidor previo perdió al momento de la falla
• El primer tráfico real de producción después de la falla ocurrió a las 2023-07-03 15:25:58 UTC
  • Ese momento fue aproximadamente 26 horas y 16 minutos después del inicio de la falla
• Aunque Tarsnap no tiene un SLA explícito, aplica una política de otorgar créditos en incidentes que considera justos
  • El 2023-07-13 se otorgó a todas las cuentas de Tarsnap un crédito de 50% del costo de un mes de almacenamiento
  • El procesamiento de los créditos se realizó después de atender la falla y descansar

[GN⁺]

Opiniones en Hacker News

• Realmente no esperaba que este artículo llegara a lo más alto de HN. Me gustaría responder preguntas, pero ahora son las 10 p. m. y mi hijo se quedó dormido a las 5 p. m., así que, si tengo suerte, quizá pueda dormir unas 4 horas antes de que se despierte.
  Volveré a revisar por la mañana y responderé preguntas.

  • Me pregunto cuál sería la razón para usar este servicio en lugar de restic. Agradezco a Colin, pero al leer esto parece que, en la práctica, hay una sola persona como responsable de infraestructura de este servicio.
    Está bien que hayan dejado claro que no hay SLA, pero siento que hay un riesgo grande interpuesto entre mis backups y yo.
  • Si en el futuro vuelven a escribir otro post mortem —aunque espero que sean muy pocos o ninguno—, estaría bueno que incluyeran claramente las lecciones aprendidas, para que se vea qué elementos no se repetirán y por qué.
  • Es un post mortem realmente bien escrito y considerado, pero espero no volver a ver uno de estos :)
  • Ya es hora de poner al niño a cargo del soporte 24/7 ;)
    Estoy leyendo https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... y me está dando cierto resultado. Se puede conseguir en cualquier biblioteca, es decir, una especie de Blockbuster para libros.
  • Me pregunto cuánto tiempo conservan los logs de transacciones antes de sobrescribirlos.
    En las últimas semanas también se me cayeron algunas instancias EC2 con síntomas que parecían de desconexión de EBS, en mi caso fue en eu-west.

• La parte donde, según la política ambigua de “Tarsnap no tiene SLA, pero otorga créditos por interrupciones si parece justo”, el 2023-07-13 acreditaron a todas las cuentas de Tarsnap el 50% de un mes de costo de almacenamiento muestra muy bien qué clase de persona es Percival.
  Ese crédito parece bastante generoso en cuanto a compensar suficientemente a los clientes y, a diferencia de los grandes proveedores cloud, no hicieron que cada cliente viniera por separado a suplicar. Además, hubo un post mortem claro, técnico y detallado. Creo que en todos lados deberían hacerlo así.

  • La expresión “gracias por ser un faro en la oscuridad” encaja perfecto.
    Me alegra bastante vivir en un mundo donde existe Tarsnap y sus precios se calculan en picodólares.

• Si los procedimientos de recuperación ante desastres se hubieran configurado y probado correctamente, el downtime podría haberse reducido mucho.
  Hace falta crear un sistema de staging completamente separado, que se pueda bajar y volver a crear, probar periódicamente distintos modos de falla y documentar todos los detalles del procedimiento de recuperación del sistema.
  A largo plazo, también valdría la pena pensar si se pueden aumentar los ingresos para contratar personal part-time, lo que ayudaría mucho si ocurre algo similar.
  Nosotros también somos un pequeño proveedor de soluciones cloud y nos enfocamos en APIs de ML, y con los años se volvió cada vez más evidente que, al usar hardware cloud, ya sea dedicado o virtual, las fallas ocurren periódicamente. La RAM, los HDD u otros componentes de hardware pueden fallar en cualquier momento, así que, al operar un servicio online de alta disponibilidad a largo plazo, hay que considerarlo al 100%.

• Mis respetos por el post mortem honesto y por haber manejado bien una situación difícil. Dicho eso, sobre la falta de sueño, si solo hay una persona que puede arreglar el problema, no hay que avergonzarse de aceptar un poco más de tiempo de caída para tener la mente despejada.
  Irse a dormir un rato mientras suenan las alertas se siente raro, pero con la adrenalina sumada a la falta de sueño es demasiado fácil empeorar el problema.

  • No se preocupen, tomé algunas siestas en el medio. “Esto parece estar funcionando bien, pero va a tardar varias horas más, así que voy a poner la alarma para dentro de 2 horas y dormir un poco” fue una de las razones por las que no me di cuenta de que el segundo paso estaba atascado innecesariamente en un cuello de botella de E/S.

• Por la descripción, este proceso de recuperación parece relativamente fácil de probar con regularidad, y eso permitiría encontrar bugs restantes o estimar el tiempo de recuperación.
  Como suele decirse, solo un backup probado es un backup de verdad.

  • Estoy 100% de acuerdo, como alguien que solo después de probarlo descubrió que mi proceso de recuperación ante desastres no funcionaba. El único plan que realmente tiene posibilidades de funcionar es uno repetible y probado.
  • Sí. Llevaba tiempo queriendo hacerlo, pero siempre había algo con más prioridad. No me di cuenta de que casi no lo había probado en 10 años hasta antes de esta interrupción.
    De ahora en adelante, definitivamente pondré los ensayos anuales como una prioridad alta.

• Siempre es bueno ver un post mortem tan profesional, cortés y honesto.

• Quizá estoy hablando con base en información antigua sobre la empresa Tarsnap, pero el único factor que me hizo dudar de usar Tarsnap en serio fue una posible falla inesperada de Colin Percival, es decir, el riesgo de persona clave.
  No creo ser el único.

  • Es parecido a calcular el tiempo medio entre fallas. La cuestión es si confiar en una solución bien diseñada de una empresa unipersonal bien diseñada, con pocas partes móviles, o en una solución de una empresa mucho más grande, pero con muchas más partes móviles y probablemente menos bien diseñada.
    En lo personal, elegiría la solución más simple. En mi experiencia, para alcanzar el nivel de confiabilidad de un sistema simple hace falta una enorme complejidad adicional, y la mayor parte de esa complejidad empeora las cosas.
    Esto es evidente en el clustering de servidores. Un solo servidor con energía y red estables puede ser más confiable que cualquier intento de duplicar ese servicio, hasta llegar a un punto en que el costo y la complejidad aumentan más o menos 5 veces. Recién ahí se obtiene un tiempo medio entre fallas similar al de un solo servidor, y solo después de eso se puede lograr una mejora real.
    Creo firmemente que el mejor camino hacia una confiabilidad real es la máxima simplicidad posible y buenos backups. Si se necesita disponibilidad 24/7 todo el año, las tecnologías entre las que se puede elegir se reducen bastante.
  • Entiendo que esto sea un riesgo, pero no estoy seguro de que sea necesariamente más riesgoso que una empresa más grande.
    Esto es el trabajo de Colin, lleva el nombre de Colin y es muy importante para Colin.
    En BigBackupCorp es difícil recibir el mismo tipo de servicio. Los empleados son reemplazables, la gerencia es reemplazable y, francamente, yo como cliente también soy reemplazable si la empresa decide cambiar de rumbo y convertirse en BigFlowerArrangementShippingCorp.
    Lo bueno de un negocio pequeño es que funciona completamente por interés propio. No hay juegos con el precio de las acciones ni trucos al estilo VC. Si es un negocio rentable, alguien puede llegar, comprarlo, poner su nombre y hacerlo suyo. Creo que la Internet abierta se beneficia mucho de este tipo de cosas.
  • Si haces una lista de los competidores que desaparecieron antes que Tarsnap, el cálculo puede cambiar un poco. El riesgo a evaluar no debería ser “¿qué pasa si le ocurre algo al operador?”, sino “¿qué pasa si le ocurre algo, el servicio también se cae y yo tampoco hice un backup del backup?”.
    Con una planificación cuidadosa, este riesgo puede hacerse tan pequeño como uno quiera.
  • Si uno está mirando HN, probablemente se enteraría en menos de 24 horas de que a Colin le pasó algo. En la práctica, para que haya un problema real, tendrían que fallar al mismo tiempo el almacenamiento principal, Tarsnap y Colin dentro de una ventana de unas 24 horas antes de migrar a un nuevo proveedor de backups.
  • No pienso confiar más que eso en un proveedor de backups. Porque en el momento en que uno depende de él, fallará en el peor momento.
    Es mejor tratar un servicio como Tarsnap como una de varias capas, armar backups multicapa y verificarlos periódicamente.

• Un error como que una entrada de log reproducida esté registrando datos de una máquina que no existe parece algo que podría detectarse escribiendo un modelo en TLA+.

• Si se usa una combinación como restic+backblaze, el costo baja varios órdenes de magnitud, así que me pregunto cuál es la ventaja de usar Tarsnap. No sé qué necesidad concreta tendría que existir para motivar pagar 3000 dólares por TB-año.

  • Algunos de nosotros tenemos bastante dinero de sobra y nos gusta tener una excusa para darle dinero a cperciva, para que no trabaje en un empleo horrible y use sus habilidades y talento en cosas más grandes y mejores.
    A quienes preguntan por el bajo bus factor: no van a dejar sus backups en un solo servicio o en una sola ubicación, ¿verdad? Usarían Tarsnap junto con Restic+Backblaze, Rsync.net, S3, etc., ¿no? “Los backups son el impuesto que se paga para darse el lujo de poder restaurar”.
  • La deduplicación funciona muy bien, así que el costo del conjunto de datos esenciales y muy importantes que respaldo en Tarsnap es despreciable. Si los datos cambiaran con más frecuencia, creo que el cálculo sería distinto.
    Por ejemplo, para mi biblioteca de videos y fotos uso otros servicios, pero respaldo en Tarsnap la base de datos contable y documentos importantes.
    Llevo 10 años usando Tarsnap y casi no he tenido problemas de disponibilidad, y hasta donde recuerdo casi ningún problema de ningún tipo.

• Suena a que la mayor parte de las 26 horas de downtime se usaron para restaurar backups. Casualmente, esa es exactamente la razón por la que no puedo usar Tarsnap en un entorno de producción.
  Desde el punto de vista del usuario, restaurar backups es dolorosamente lento. Cuando mi sistema está offline, no tengo paciencia para esperar horas por culpa del servicio de backups. Puede que ahora haya mejorado, pero la última vez que lo usé, hace varios años, restaurar un backup de unos pocos GB tomaba aproximadamente del orden de una hora.