Técnica de reinicio rápido en lugar de mantener el buen estado (disponibilidad y consistencia)

Question

¿Con qué frecuencia resuelve sus problemas reiniciando una computadora, enrutador, programa o navegador? ¿O incluso reinstalando el sistema operativo o el componente de software?

Esto parece ser un patrón común cuando hay una sospecha de que el componente de software no mantiene su estado de la manera correcta, entonces solo obtiene el estado inicial reiniciando el componente.

He oído que Amazon / Google tiene un grupo de muchos nodos. Y una propiedad importante de cada nodo es que puede reiniciarse en segundos. Entonces, si uno de ellos falla, regresarlo al estado inicial es solo cuestión de reiniciarlo.

¿Hay algún lenguaje / marco / patrón de diseño que aproveche esta tecnología como ciudadano de primera clase?

EDITAR El enlace que describe algunos principios detrás de Amazon, así como los principios generales de disponibilidad y coherencia: http://www.infoq.com/presentations/availability-consistency

Answer 1

Esto es común en el mundo de los sistemas integrados y en las telecomunicaciones. Es mucho menos común en el mundo basado en servidor.

Hay un grupo de investigación en el que puede estar interesado. Han estado trabajando en Computación orientada a la recuperación o "ROC". El principio clave en ROC es que el estado más limpio, mejor y más confiable en el que puede estar cualquier programa es justo después del inicio. Por lo tanto, al detectar una falla, prefieren reiniciar el software en lugar de intentar recuperarse de la falla.

Suena bastante simple, ¿verdad? Bueno, la mayor parte de la investigación se ha dedicado a implementar esa idea. La razón es exactamente lo que usted y otros comentaristas han señalado: los reinicios del sistema operativo son demasiado lentos para ser un método de recuperación viable.

ROC se basa en tres partes principales:

1. Un método para detectar fallas lo antes posible.
2. Un medio para aislar el componente defectuoso mientras se preserva el resto del sistema.
3. Reinicios a nivel de componente.

La diferencia clave real entre ROC y el típico "reinicio nocturno" El enfoque es que ROC es una estrategia donde los reinicios son una reacción. Lo que quiero decir es que la mayoría del software está escrito con cierto grado de manejo y recuperación de errores (lanzar y atrapar, iniciar sesión, volver a intentar bucles, etc.) Un programa ROC detectaría la falla (excepción) y inmediatamente salida. Combinar los dos paradigmas te deja con lo peor de ambos mundos: baja confiabilidad y errores.

Answer 2

Esto es realmente muy raro en el mundo unix / linux. Esas oses fueron diseñadas (y también Windows) para protegerse de los procesos mal comportados. Estoy seguro de que Google no se basa en reinicios duros para corregir el software mal comportamiento. ¡Diría que esta técnica no debe emplearse y si alguien dice que la ruta más rápida para la recuperación de su software debe buscar otra cosa!

Answer 3

Los microcontroladores generalmente tienen un temporizador de vigilancia, que debe reiniciarse (mediante una línea de código) cada cierto tiempo o de lo contrario el microcontrolador se reiniciará. Esto evita que el firmware se atasque en un bucle sin fin, atascado en espera de entrada, etc.

La memoria no utilizada a veces se configura en una instrucción que provoca un reinicio o un salto a la misma ubicación en la que se inicia el microcontrolador cuando se reinicia. Esto restablecerá el microcontrolador si de alguna manera salta a una ubicación fuera de la memoria del programa.

Answer 4

Los sistemas integrados pueden tener una función de punto de control donde cada n ms, la pila actual se guarda. La memoria no es volátil en el reinicio de la alimentación (es decir, con batería de respaldo), por lo que en un arranque de energía, se realiza una prueba para ver si el código debe saltar a un antiguo punto de control, o si se trata de un sistema nuevo.

Voy a adivinar que se usa una técnica similar (pero más sofisticada) para Amazon / Google.

Answer 5

Aunque no puedo pensar en un patrón de diseño per se, en mi experiencia, es el resultado de "select is broken" de los desarrolladores.

He visto un sitio de 50 usuarios paralizar tanto SQL Server Enterprise Edition (con una base de datos de 750 MB) como un servidor Novell debido a una mala gestión de la conexión junto con llamadas excesivas y sin almacenamiento en caché. Novell fue siempre el culpable según los desarrolladores hasta que encontramos una "CloseConnection" faltante llamar a una biblioteca central. Para entonces, miles se gastaron, sin éxito, en actualizaciones para abordar esa línea de código que faltaba.

(¡¿Por qué tenían Enterprise Edition estaba más allá de mí, así que no preguntes!)

Answer 6

Si observa los lenguajes de script como php que se ejecuta en Apache, cada invocación inicia un nuevo proceso. En el caso básico, no hay un estado compartido entre los procesos y una vez que la invocación ha finalizado, el proceso finaliza.

Las ventajas son menos onerosas en la gestión de recursos, ya que se liberarán cuando finalice el proceso y menos necesidad de manejo de errores ya que el proceso está diseñado para fallar rápidamente y no puede dejarse en un estado inconsistente.

Answer 7

Lo he visto en algunos lugares en el nivel de la aplicación (una aplicación se reinicia si se bombardea).

He implementado el patrón a nivel de aplicación, donde un servicio de lectura de archivos Dbase comienza a recibir errores después de leer x cantidad de veces. Busca un error particular que se produce y, si ve ese error, el servicio llama a una aplicación de consola que mata el proceso y reinicia el servicio. Es kludgey, y lo odio, pero para esta situación en particular, no pude encontrar una mejor respuesta.

Y tenga en cuenta que IIS tiene una característica integrada que reinicia el grupo de aplicaciones bajo ciertas condiciones.

Para el caso, reiniciar un servicio es una opción para cualquier servicio en Windows como una de las acciones a tomar cuando el servicio falla.