Análisis Post Mortem de la Interrupción de Stellar el 20 de Sept, 2014

El sábado 20 de septiembre, varios de los nodos validadores de Stellar comenzaron a fallar. Esto eventualmente llevó a que la red no alcanzara consenso sobre los ledgers, por lo que todas las transacciones se detuvieron. Las máquinas y la red volvieron unas 11 horas después.

Al observar los nodos y las estadísticas históricas de Zabbix, es claro que la mayoría de las instancias tenían poca RAM disponible, por lo que el killer OOM ("Out Of Memory") de Linux estaba matando pids en las máquinas en un intento por sobrevivir al agotamiento de memoria.

A continuación, los puntos principales que describen la interrupción que duró aproximadamente 16 horas desde el 20/09/2014 ~ 02:00 UTC hasta el 20/09/2013 ~ 18:00 UTC

• server_info : el primer ledger dejó de ser reportado a las 02:00 UTC
• server_info : la edad del ledger creció hasta las 18:00 UTC
• Durante la interrupción, la mayoría de los nodos perdieron conexión con la red (sin ledgers, sin pares)
• Aumento visible en las lecturas de disco en todos los volúmenes (db, rocksdb, rocksdb-cache).
• Aumento visible en los picos de tráfico de red saliente.
• Todos los servidores fallidos se estrellaron debido al agotamiento de memoria.

A juzgar por los gráficos, podemos decir que algunos servidores murieron y otros lucharon durante la interrupción, aunque incluso los nodos que sobrevivieron reportaron errores con pares/ledgers/edad del ledger.

Durante este tiempo, no hubo comunicación adecuada con la comunidad. Asumimos toda la responsabilidad por la respuesta lenta, pero queremos que la comunidad sepa por qué no pudimos responder de inmediato en este caso particular: En ese momento, la mayoría de nosotros estábamos en un retiro de la empresa trabajando en diseñar una gran refactorización/rediseño de stellard (irónicamente para solucionar los problemas que causaron esta interrupción de la red). Los servidores comenzaron a quedarse sin RAM durante la noche. Por la mañana, el internet en nuestra ubicación fuera de la oficina se cortó (junto con dos conexiones de internet de respaldo que habíamos provisto). Nos trasladamos a un lugar diferente y logramos estabilizar la red. Sin embargo, nuestro internet continuó teniendo problemas. Durante ese tiempo, parece que el clúster de Stellar también continuó quedándose sin RAM. La situación se estabilizó unas horas después.

• Reiniciamos todos los nodos fallidos y reiniciamos stellard en algunos de los otros nodos.
• Reducimos el tamaño del nodo stellard a medio en todos los servidores
• La red volvió en línea después de que reiniciamos algunos stellard más

La causa raíz única es desconocida pero los factores incluyen:

• Base de código antiguo teniendo problemas de escalabilidad. Stellar es la base de usuarios más grande en vivo en esta base de código y está probando los límites de esta tecnología en tiempo real. Esta interrupción nos ha hecho muy conscientes de las limitaciones de escalabilidad del sistema actual, en el cual estamos trabajando actualmente.
• Nodestore está filtrando o usando demasiada RAM.

• Completado: Reconstruir validadores con más RAM
• Completado: Añadir miembros adicionales al equipo a los canales de la comunidad para que puedan informar actualizaciones de la Fundación en tiempo real.
• Completado: Reducir la salida de alertas de monitoreo para que no nos perdamos de problemas legítimos.
• Investigar alternativas de backends/configuraciones de almacenamiento de nodos.
• Confirmar si la aplicación está filtrando memoria o no.
• Crear una página "status.stellar.org" que pueda ser actualizada fácilmente con informes de progreso/interrupciones.
• Continuar la contratación prioritaria para la expansión de miembros del equipo de devops.
• Continuar la reescritura de stellard para abordar los problemas de escalabilidad.
• Continuar el enfoque para expandir la diversidad y número de entidades que ejecutan validadores (La descentralización es un objetivo importante para asegurar la robustez de la red).

Nuevamente pedimos disculpas por la interrupción y hemos comenzado a trabajar en las medidas preventivas para evitar que esto ocurra de nuevo. Si te gustaría sugerir cualquier otra medida preventiva, queremos escucharlas. Por favor, envíalas a [email protected]—gracias.