Technique de redémarrage rapide au lieu de conserver le bon état (disponibilité et cohérence)

Question

À quelle fréquence résolvez-vous vos problèmes en redémarrant un ordinateur, un routeur, un programme ou un navigateur? Ou même en réinstallant le système d’exploitation ou le composant logiciel?

Cela semble être un modèle courant lorsqu'il est suspecté qu'un composant logiciel ne conserve pas son état de la bonne manière. Vous obtenez alors l'état initial en redémarrant le composant.

J'ai entendu dire qu'Amazon / Google possédait un cluster de nombreux nœuds. Et une propriété importante de chaque nœud est qu'il peut redémarrer en quelques secondes. En cas d'échec de l'un d'entre eux, il suffit alors de le redémarrer pour le remettre à l'état initial.

Existe-t-il des langages / cadres / modèles de conception qui exploitent cette technologie en tant que citoyen de premier ordre?

MODIFIER le lien décrivant certains principes sous-jacents à Amazon, ainsi que des principes généraux de disponibilité et de cohérence: http://www.infoq.com/presentations/availability-consistency

Answer 1

C’est courant dans le monde des systèmes embarqués et dans les télécommunications. C'est beaucoup moins courant dans le monde basé sur serveur.

Il existe un groupe de recherche qui pourrait vous intéresser. Ils ont travaillé sur l’ calcul orienté vers la récupération ou "ROC". Le principe clé de ROC est que l’état le plus propre, le meilleur et le plus fiable dans lequel un programme peut se trouver est juste après le démarrage. Par conséquent, lorsqu’ils détectent une erreur, ils préfèrent redémarrer le logiciel plutôt que de tenter d’y remédier.

Cela semble assez simple, non? Eh bien, la plupart des recherches ont été consacrées à la mise en œuvre de cette idée. La raison en est exactement ce que vous et d'autres commentateurs avez souligné: les redémarrages du système d'exploitation sont trop lents pour être une méthode de récupération viable.

ROC repose sur trois parties principales:

1. Une méthode pour détecter les défauts le plus tôt possible.
2. Un moyen d'isoler le composant défectueux tout en préservant le reste du système.
3. Redémarrage au niveau des composants.

La principale différence entre le ROC et le "redémarrage nocturne" typique approche est que ROC est une stratégie où les redémarrages sont une réaction. Ce que je veux dire, c'est que la plupart des logiciels sont écrits avec un certain degré de gestion des erreurs et de récupération (relance, journalisation, boucles de nouvelle tentative, etc.). Un programme ROC détecterait le défaut (exception) et immédiatement sortir. Mélanger les deux paradigmes ne vous laisse que le pire des deux mondes: fiabilité et erreurs réduites.

Answer 2

C’est vraiment très rare dans le monde Unix / Linux. Ces oses ont été conçus (de même que les fenêtres) pour se protéger des processus mal comportés. Je suis sûr que Google ne compte pas sur les redémarrages pour corriger les logiciels mal conduits. Je dirais que cette technique ne devrait pas être employée et si quelqu'un dit que la voie la plus grosse à la récupération de son logiciel, vous devriez chercher autre chose!

Answer 3

Les microcontrôleurs ont généralement un minuteur de surveillance, qui doit être réinitialisé (par une ligne de code) de temps en temps, sinon le microcontrôleur sera réinitialisé. Cela empêche le micrologiciel de rester bloqué dans une boucle sans fin, d’attendre une entrée, etc.

La mémoire inutilisée est parfois définie sur une instruction qui provoque une réinitialisation ou un saut vers le même emplacement que celui auquel le microcontrôleur démarre à la réinitialisation. Ceci réinitialisera le microcontrôleur s’il saute à un emplacement situé en dehors de la mémoire programme.

Answer 4

Les systèmes intégrés peuvent avoir une fonctionnalité de point de contrôle où toutes les n ms, la pile actuelle est enregistrée. La mémoire est non volatile au redémarrage (c.-à-d. Sauvegardée sur batterie). Ainsi, lors du démarrage, un test est effectué pour voir si le code doit passer à un ancien point de contrôle ou s'il s'agit d'un système récent.

Je suppose qu'une technique similaire (mais plus sophistiquée) est utilisée pour Amazon / Google.

Answer 5

Bien que je ne puisse pas penser à un modèle de conception en tant que tel, d'après mon expérience, il résulte de "Select is broken". des développeurs.

J'ai vu un site composé de 50 utilisateurs écraser à la fois SQL Server Enterprise Edition (avec une base de données de 750 Mo) et un serveur Novell en raison d'une mauvaise gestion des connexions associée à des appels excessifs et à l'absence de mise en cache. Novell était toujours le coupable selon les développeurs, jusqu'à ce que nous ayons trouvé un " CloseConnection & manquant manquant. appeler une bibliothèque principale. À ce moment-là, des milliers de dollars avaient été dépensés, sans succès, pour des mises à niveau afin de corriger cette ligne de code manquante.

(Pourquoi ils avaient Enterprise Edition était au-delà de moi alors ne demandez pas !!)

Answer 6

Si vous regardez des langages de script tels que php s'exécutant sur Apache, chaque appel lance un nouveau processus. Dans le cas de base, il n'y a pas d'état partagé entre les processus et une fois l'appel terminé, le processus est terminé.

La gestion des ressources présente moins d'avantages, car elles seront publiées à la fin du processus, et le traitement des erreurs est moins nécessaire, car le processus est conçu pour fonctionner rapidement et ne peut pas être laissé dans un état incohérent.

Answer 7

Je l’ai vue à quelques endroits au niveau de l’application (une application qui se redémarre si elle bombarde).

J'ai implémenté le modèle au niveau de l'application, où un service qui lit des fichiers Dbase commence à recevoir des erreurs après avoir lu x nombre de fois. Il recherche une erreur particulière qui est générée et, s'il le voit, le service appelle une application console qui tue le processus et redémarre le service. C'est ridicule, et je déteste ça, mais pour cette situation particulière, je ne pouvais pas trouver de meilleure réponse.

ET n'oubliez pas qu'IIS possède une fonctionnalité intégrée qui redémarre le pool d'applications sous certaines conditions.

D'ailleurs, le redémarrage d'un service est une option pour tout service sous Windows, qui est l'une des actions à entreprendre en cas d'échec du service.