Systèmes de routages répartis : attention danger !

Article de vulgarisation, volontairement simplifié.

Un système de routage décentralisé est constitué de plusieurs plateformes (des "nœuds" ou "serveurs") qui interopèrent de manière raisonnée pour router quelque chose (par exemple une demande d'autorisation de paiement, une demande de connexion d'appel vocal, etc.) vers le bon destinataire et recevoir les réponses des bons émetteurs de réponse pour les rerouter ensuite vers le bon demandeur.

Photo by Alina Grubnyak on Unsplash

Une très bonne résilience matérielle

Avec sa redondance intrinsèque de serveurs et son maillage réseau, la panne d'un nœud ou la coupure d'une liaison sont insuffisantes pour mettre le système à l'arrêt. Cette architecture protège donc bien des pannes les plus courantes qui sont rendues invisibles à l'usager et résolue par l'exploitant.

En revanche il peut rester des "pannes de mode commun" qui s'appliqueront à tous les matériels : coupure de courant s'ils sont dans la même salle, cryptovirus se propageant et chiffrant toutes les données, défaut dans le logiciel installé à l'identique sur tous les nœuds etc. Normalement ces risques sont traités vu l'enjeu du service rendu. Donc le problème n'est en général pas là.

Des risques inhérents à l'architecture répartie

Les risques de pannes ou plutôt de ralentissement sont ailleurs. Certains phénomènes peuvent se produire, citons en trois classiques :
  • La saturation du système : une demande restée "trop longtemps" sans réponse peut être réémise, la réponse à la première demande est alors purgée... une multiplication de cas à traiter et purger peut apparaître qui va charger l'ensemble, surtout à l'heure de pointe. "Trop longtemps" ici pouvant dire 0,5 seconde...
  • Les nœuds qui s'attendent l'un l'autre : "l'étreinte mortelle"; le noeud A demande une information au nœud B (ex : accès à une information de routage). Or le noeud B attend une information de C qui attend une information de A : le système va se bloquer partiellement. Partiellement seulement car il n'est pas mono tâche...mais les tâches suspendues vont se multiplier ainsi que les locks d'accès aux données...
  • La contention en accès. Suite à un changement administratif, seul le nœud C a les informations récentes, tous les autres nœuds ont des informations "invalidées", tout va donc converger vers C qui sera saturé alors que les autres sont en attente... C cherchant à propager les bonnes informations vers tous les autres...
On voit sur ces exemples que ces situations peuvent être en partie provoquées par une intervention humaine malheureuse. Des paramètres trop courts sur les timers (pour limiter le temps d'attente usager) peuvent saturer le système et donner l'effet inverse ! Si de plus il existe des automatismes qui peuvent superposer leurs actions à l'action de l'homme : attention danger ! L'homme essaie d'arrêter un nœud, l'automate de le redémarrer. On n'y comprend plus rien.

Une surveillance, un pilotage et une administration très attentives sont absolument nécessaires.

Un système de ce type doit bénéficier d'une surveillance implacable par des spécialistes.

Point important : rien ne remplacera un ingénieur système qui sait comment cela a été conçu, comment marchent les automatismes, dans quel ordre il faut opérer, ce qu'il ne faut pas faire dans telle ou telle situation, comment anticiper et prévenir les risques. Comment contrôler le flux en tuant le minimum de demandes. Quand cette personne est en vacances : danger !

Dans des situations de blocage ou fort ralentissement mentionnées plus haut, il est difficile :
  • de savoir ce qui se passe : tout marche et fonctionne à fond et pourtant 70% des appels sont en souffrance, les outils de surveillance ne donnent pas forcément une bonne vision de la réalité
  • d'opérer correctement : les effets des actions de pilotage peuvent être pires que le mal : au redémarrage tel serveur lance automatiquement des actions qu'il ne faut pas faire...on le voit trop tard !
  • d'apprécier concrètement comment le monde extérieur réagit et en quoi il peut être responsable à son tour de dégradations (en relançant les demandes par exemples, en réinitialisant des liens télécoms qui vont nous basculer sur un secours inutile, etc.)
Bref, on ne sait pas comment s'en sortir sauf à tout arrêter. Et alors des nœuds redémarrent automatiquement avec des paramétrages anciens non valides, et etc. etc. c'est reparti pour la galère !

La surveillance, le pilotage et l'administration doivent fort probablement être dédiés sur ce type de systèmes, à ne pas mettre entre toutes les mains.









Commentaires

Enregistrer un commentaire

Si vous avez des idées constructives ou des avis d'expérience, laissez un commentaire.

Posts les plus consultés de ce blog

Les PCA éliminent-ils les cellules de crise?

Image
Nous entendons quelquefois dire dans nos missions que l’approche PCA vient remplacer l’approche « gestion de crise » et la rendre inutile. Or nous pensons que cette position est en partie vraie et en partie fausse. Voici pourquoi. Photo E.Besluau Quand le PCA évite la crise Dans une approche rigoureuse de Continuité d’activité, des actions de réduction de risques ont été menées qui éliminent des situations qui auraient sinon conduit à une crise. Quelques exemples : Votre serveur critique a été rendu plus tolérant aux pannes et a été doublé : la panne de ce serveur est devenue plus rare et provoque de toute façon moins de conséquences qu’avant : des situations de crise sont donc évitées. La partie ‘traitement des risques’ de l’approche CA a effectivement éliminé des cas à crise. Autrefois vous n‘aviez qu’un seul fournisseur pour des éléments critiques de votre production en usine. Le sinistre de ce fournisseur vous a arrêté l’année dernière. Depuis, vous avez musclé un peu votre stock e...
Lire la suite

Attention aux mauvaises pratiques des exploitations informatiques !

Image
Il n'est pas rare dans nos missions sur la sécurité et continuité d'attirer l'attention du client sur des faiblesses de son exploitation informatique et de le mettre en garde. En effet, à quoi bon se préparer à l'événement rare (avec un coûteux "PCA"), alors que la panne fréquente n'est pas palliée ! photo : E.Besluau Quelques constats : Nous voyons de plus en plus des exploitations informatiques qui se sont contentés d'accumuler des serveurs dans une salle en espérant que "cela marchera". Il n'y a pas de vision de production de service, la prévention des pannes et arrêts est insuffisante. Les implémentations techniques, les choix réalisés et les méthodes d'exploitation ne permettent pas de fiabiliser l'exploitation. Le risque d'une interruption -potentiellement longue- est alors élevé. Toute mise en place d'un PCA (ou PCIT dans ce cas) est illusoire. Il faut d'abord réaliser une analyse de la situation et réduire les ...
Lire la suite

Faut-il opposer Continuité d'Activité et "Résilience opérationnelle" ?

Image
 En lisant des textes récents et des interventions de spécialistes, certains responsables de Continuité d'activité s'interrogent : "On nous parle de résilience, comme si c'était un concept nouveau ! Nous autres RPCA, en faisons depuis longtemps" ! Ce mot de "résilience", que je devais expliquer il y a dix ans, est complétement entré dans les mœurs. Certains l'opposant aux démarche de type PCA. Discutons le sujet pour essayer d'y voir clair. Exemple vécu chez un grand compte En discussion avec un responsable de direction générale, celui-ci me déclare : " Nous avons depuis quelques années développé un PCA. Il est prévu qu'en cas de perte de notre informatique, nous allions récupérer des moyens de secours chez Untel." "Or, récemment nous avons eu une paralysie totale de notre informatique à cause de montées de versions logicielles qui se sont mal passées. Cela nous a arrêtés pendant au moins deux jours. Cela a généré un gros trava...
Lire la suite