¿Qué son los fallos en cascada?

En sistemas informáticos complejos, existe un riesgo perpetuo de pequeños errores. A veces estos errores se ocupan de lo suyo y todo vuelve rápidamente a la normalidad. Otras veces, un error provoca que siga otro problema relacionado, que a su vez se realimenta al error original o quizás a otros adicionales en otra parte del sistema. El efecto dominó resultante de aumentar los fallos debido a mecanismos de retroalimentación positiva están lo que se está denominado fallo en cascada.

Mecanismos de retroalimentación

Los errores independientes suponen una amenaza mucho menor para los sistemas que aquellos que contribuyen a bucles de retroalimentación. En dicho bucle de retroalimentación, los sistemas de software distribuido pueden experimentar primero una reducción relativamente pequeña de la capacidad, un pico de errores o un aumento de la latencia. A medida que otras partes del sistema intentan responder y corregir el problema original, acaban empeorándolo.

Por ejemplo, un servidor dentro de un conjunto de servidores que trabajan juntos podría experimentar una carga excesiva que provoca que falle. Regularmente, descargaría un pequeño excedente en un servidor vecino que actúa como respaldo manteniendo su propia carga. Pero este segundo servidor no puede manejar dos cargas completas tras el fallo total del primero, por lo que también falla.

Las cargas excedentes continúan pasando por la línea de servidores vecinos, acumulándose en cargas excedentes cada vez mayores hasta que todo el sistema se desmorona.  Este tipo de fallo en cascada están una mezcla de sobrecarga y disparadores de retroalimentación por conmutación por conmutación por proximidad, como se menciona a continuación.

Disparadores de retroalimentación de fallos en cascada

Varios desencadenantes pueden explicar el fallo típico en cascada, tanto individualmente como en conjunto entre sí, incluyendo:

Si tu sistema nunca ha experimentado una avería en cascada, no te dejes llevar por una falsa sensación de seguridad. En cualquier momento, tu sistema puede intentar operar fuera de sus límites, lo que puede provocar un problema inesperado.

Algunos de estos desencadenantes son evitables mediante una adecuada estructuración y gestión de un sistema. Otros son esencialmente inevitables, pero pueden prepararse y mitigarse estudiando cómo funcionan antes de Crea problemas significativos.

Por ejemplo, los picos de carga son una parte esperada del funcionamiento del sistema y son el desencadenante de retroalimentación más común para fallos en cascada. No te puedes detener razonablemente, pero sí te puedes gestionar cómo reacciona tu sistema a ellos. Aunque el sistema de planificación de tareas y el balanceador de carga gestionan las cargas típicas de una manera que suele funcionar, también deben estar preparados para cargas anormales. Cuando la carga supera la media, puede que necesiten implementar nuevas tácticas para evitar un fallo en cascada.

Recuperación de una falla en cascada

Independientemente del tipo de disparador, recuperarse de una avería en cascada está casi siempre extremadamente difícil. Con frecuencia, el sistema requiere un apagado total porque ya no puede restablecerse sin intervención manual.

¿Por qué están tan difícil?

Si tu sistema contiene las condiciones adecuadas para una falla en cascada, probablemente no te imagines y el evento ocurrirá casi al instante sin previo aviso. Y una vez que ha comenzado, está muy poco probable de ralentizarlo o detenerlo. El estado del sistema suele Obtén cada vez más sin auto-reparación de ninguna manera.

Muchos equipos pueden tener el instinto de intentar recuperar el sistema añadiendo más capacidad. Pero esto también probablemente solo contribuirá a la retroalimentación positiva del fallo. A medida que tú añades una nueva instancia sana, inmediatamente se Obtén con la carga excesiva de otras instancias que fallan. Una carga tan grande satura la nueva instancia, haciendo que falle antes de que pueda ayudar, descartando la posibilidad de que tú llegues a un punto en el que tú tengas suficiente capacidad de servicio para afrontar la carga.

Configurar el sistema de antemano para que no envíe todas las solicitudes solo a instancias sanas podría evitar este tipo de problema, ralentizando o deteniendo una falla en cascada. Pero sin esa previsión, a menudo la única forma de recuperarse de una falla en cascada está dejando todo el servicio fuera de servicio y luego reintroduciendo la carga.

Tácticas para abordar un fallo

Si tu sistema ya están sufriendo una avería en cascada, son hay algunos pasos te puedes dar para intentar solucionarlo de inmediato antes de recurrir a un apagado total del sistema. Primero, comprueba que cualquier sobrecarga de capacidad no están debido a recursos inactivos. Añadir recursos inactivos a las tareas activas puede recuperar rápidamente un sistema si la carga no están demasiado grande.

Si todos los recursos son activos participando, entonces cambiar el comportamiento de los controles de salud puede detener la espiral. A medida que el sistema revisa la salud de las tareas, verá que muchas tareas son poco saludables y que otras son reiniciadas. Por ello, normalmente enviará cargas desproporcionadas a las pocas instancias sanas que quedan, haciendo que también se vuelvan poco saludables.

Desactivar temporalmente o cambiar el comportamiento de este tipo de comprobaciones de auto-salud podría ayudar a que el sistema se reestabilize. Una opción están que el sistema Haz una distinción entre tareas completamente no responsivas y temporalmente no responsivas, para poder incluir estos últimos tipos en la distribución de carga.

Una respuesta más drástica a un fallo en cascada están cortar tráfico y entrar en modos degradados. Esta táctica requiere cierta agresividad para funcionar, con una reducción significativa del tráfico hasta algo así como el 1% de las tasas normales. A medida que los servidores se recuperan, más tráfico puede pasar gradualmente. A medida que la carga vuelve a niveles normales, las cachés pueden calentarse y establecer conexiones, pero los usuarios tendrán una experiencia muy negativa.

Reducir el tráfico de esta manera debe implementarse simultáneamente con la reparación del problema subyacente. De lo contrario, puede haber un segundo fallo en cascada tan pronto como la recuperación están completa y el tráfico vuelva a la normalidad. Si el ordenador se quedó sin memoria o el sistema tenía capacidad insuficiente, asegúrese de añadir más memoria o tareas antes de intentar reintroducir el tráfico.

Además, los sistemas con la capacidad de diferenciar entre distintos tipos de tráfico pueden eliminar específicamente el tráfico menos importante o malo. Esto debe formar ya parte de las capacidades del sistema, pero puede permitir priorizar el tráfico que pasa para Reduce las consecuencias negativas.

De manera similar, discriminar contra lotes de carga menos importantes puede Reduce la carga sobre tareas con resultados negativos minimizados. Pausar fuentes como la recopilación de estadísticas, copias de datos y actualizaciones de índices puede contribuir a una recuperación.

Si todas estas estrategias no logran detener la falla en cascada, un apagado total del sistema probablemente están la única opción restante.

Prevención de fallos en cascada antes de que comiencen

Prevenir la sobrecarga de servidores

Como la sobrecarga están el desencadenante más común, centrarse en la prevención de sobrecarga puede ayudar mucho a evitar fallos en cascada. Para evitar la sobrecarga, considera limitar el número de solicitudes entrantes al sistema. Aceptar un número ilimitado de solicitudes puede Crea enormes colas de peticiones e hilos concurrentes que intentan ejecutarse durante un fallo en cascada.

Esta acumulación hace que el sistema se volva poco responsivo, requiriendo frecuentemente una intervención o reinicio. Para evitarlo, modera el comportamiento de reintentos del cliente para evitar avalanchas de solicitudes reintentadas, establece límites en la carga en cada instancia y considera el corte de suministro en un balanceador de carga. Esto último establece algunos límites a tu servicio, pero también lo haría la alternativa de un fallo en cascada.

Realizar pruebas

Cuando se trata de otros posibles desencadenantes de retroalimentación, a veces ni siquiera te das cuenta de que tu sistema tiene una configuración o respuesta inadecuada. La mejor manera de saber cómo maneja situaciones problemáticas están comparándolo con ellos.

Las pruebas fuzz pueden ayudar a Detecta programas que se bloquean por una entrada incorrecta, también conocidas como Consultas de la Muerte. En lugar de bloquearse, un programa debería ser capaz de reconocer si su estado interno plantea preocupaciones de seguridad y reaccionar de manera que no provoque un fallo. Este tipo de pruebas están especialmente útiles para servicios que frecuentemente reciben entradas externas a la organización.

Además de la carga, prueba el comportamiento del cliente y los backends no críticos. Los clientes deberían poder poner en cola su trabajo mientras el sistema están caído, y deberían reducir exponencialmente los errores. Mientras tanto, la falta de backends durante un fallo no debería interferir con las partes más críticas del sistema.

Al realizar cualquier prueba, asegúrate de considerar tanto cambios graduales como de impulsos. El sistema puede responder bien a aumentos graduales de carga, pero colapsar durante un pico repentino. Y una vez que ocurra una avería en el sistema, continúa probando para Ve si y cómo está capaz de recuperarse.

Después de te identificar los problemas únicos de tu sistema, te puede implementar los cambios adecuados. Modificar la configuración del sistema y mejorar la respuesta puede mitigar e incluso prevenir por completo fallos en cascada.

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.