Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Redondance et secours

Redondance et secours

D’une manière générale, la tolérance aux pannes consiste à mettre en œuvre, pour assurer une fonction, N équipements dont P suffisent.

On peut parler soit :

  • De secours actif, dans le cas où les N équipements sont opérationnels en nominal
  • De secours passif, lorsque P équipements sont opérationnels, et N-P sont en réserve, en secours, en « spare ».

Les questions clés sont bien sûr : Quel process, quel délai, pour que le secours intervienne, et quel impact visible l’événement a-t-il en termes de disponibilité ?

Surveillance et passage en secours

La première étape est la détection de la panne et l’activation du secours. On peut distinguer :

  • La surveillance par l’équipement homologue, et la reprise de la fonction par l’homologue.
  • La surveillance par l’étage amont, par l’appelant, et la réaffectation de la fonction à un homologue, qu’il soit actif ou passif.
  • La surveillance par la supervision, et la réaction prise en charge à ce niveau.

Surveillance par l’homologue et heartbeat

C’est le cas de deux équipements placés en parallèle, que ce soit avec un secours actif ou passif.

Typiquement, avec secours passif, on a un équipement de secours qui teste en permanence l’équipement principal pour vérifier son bon fonctionnement. Ce test est l’appel périodique d’un service qui témoigne du bon fonctionnement. On parle alors de heartbeat, c’est à dire de battement de cœur : tant qu’on entend battre son cœur, c’est qu’il va bien.

Pour plus de robustesse, l’échange de heartbeat peut se faire hors du réseau local, sur un câble Ethernet croisé, ou une liaison série.

S’il détecte la panne de l’équipement actif, l’équipement de secours reprend la fonction, en reprenant l’adresse IP. Il s’affecte l’adresse IP, puis envoie en broadcast un message d’effacement du cache ARP, afin que les switchs puissent associer son adresse physique (MAC) à l’adresse IP.

Dans certains cas, l’échange entre les équipements peut porter sur davantage qu’un simple signe de vie, et inclure une vraie synchronisation de données, afin de reprendre la fonction avec son contexte, et donc de manière transparente pour les clients.

Surveillance par l’étage amont

C’est typiquement le cas où l’on a un load-balancer en amont, affectant les requêtes à différents serveurs.

Le load-balancer teste lui-même le bon fonctionnement des serveurs. Cela peut se faire à différents niveaux : ICMP, test de connexion TCP, test au niveau HTTP, ou bien appel d’un service spécifique de surveillance.

Lorsqu’il détecte un équipement défaillant, le load-balancer le sort de la répartition, et peut adresser une alerte à la supervision.

Soulignons que la qualité de ce test est primordiale. Un cas d’effet de bord très classique est celui où un serveur en panne répond plus vite que tous les autres, précisément parce qu’il est en panne. Il répond au niveau HTTP, mais répond une erreur, ou pire encore une page bien formée mais comportant un message d’erreur. Dans certains cas, le load-balancer dirigera les requêtes de manière privilégiée vers ce serveur défaillant, transformant une panne partielle en indisponibilité globale.

Secours passif

Sur une plateforme web, on vise le plus souvent un secours transparent (« transparent failover »), c’est à dire s’opérant de manière automatique.

 

Il échoue pour différentes raisons :

  • La configuration du secours est obsolète ou erronée
  • Le mode opératoire du passage en secours est mal maîtrisé
  • La bonne personne n’est pas là.

On privilégie donc un secours transparent, mais il doit aussi être revalidé très régulièrement, et l’on préfère un secours actif, c’est à dire qui participait au travail en temps normal.

Secours actif

Dans un principe de secours actif, le composant de secours est déjà opérationnel avant d’être requis. Il est en surnombre, mais assure malgré tout une part de la fonction. Le secours actif est associé aussi à un dispositif de passage en mode secours transparent ou automatisé. On parle d’un secours « à chaud ». Les disques RAID, typiquement, fonctionnent selon un principe de secours actif.

En règle générale, le secours actif a beaucoup d’avantages :

  • Il réduit considérablement les risques. Risque que le composant de secours lui-même soit défaillant ou bien mal configuré, risque d’une procédure de passage en secours mal maîtrisée.
  • Il permet de tirer parti du surplus de matériel pour disposer d’une meilleure qualité de service même en l’absence de secours.
  • Et bien sûr, le passage en secours automatisé réduit la durée des incidents, et limite les besoins humains, pour autant que tout se passe comme prévu.

Aux rangs des inconvénients, on peut citer :

  • Une moindre flexibilité, et donc un coût matériel potentiellement supérieur : chaque plateforme d’un datacenter doit avoir son serveur de secours, (voire même un pour chaque grande fonction de la plateforme) alors qu’un hébergeur pourrait choisir de mutualiser un petit nombre de serveurs de secours pour différents clients.

Gestion mutualisée du secours

Une gestion mutualisée du secours consiste à disposer d’un ensemble (« pool ») de serveurs en spare, qui peuvent être utilisés pour remplacer différentes fonctions de la plateforme.

C’est une voie qui peut être nécessaire lorsqu’on a spécialisé les serveurs, que ce soit une spécialisation fonctionnelle, ou une spécialisation par partitionnement des données.

Bien sûr, cela suppose que la même configuration hardware puisse convenir aux différentes fonctions. Et cela implique aussi un process de passage en secours plus long, puisqu’il implique l’installation de la configuration spécifique à la fonction secourue.

La généralisation de la virtualisation des serveurs facilite grandement cette installation rapide du secours : il convient de disposer des VMs correspondant à toutes les fonctions de la plateforme, prêtes à l’emploi.

C’est un secours qui pourra être rendu automatique, mais ne sera pas instantané. A moins de disposer d’un SAN qui permette de faire repartir immédiatement un nouveau serveur sur une VM déjà installée sur une partition disque.

Single Point of Failure

« SPOF », c’est un acronyme célèbre en matière de disponibilité : le Single Point Of Failure, Point Unique de Panne, est un composant critique qui n’est pas secouru, un point de fragilité de la plateforme.

Dans une architecture, il est essentiel évidemment de l’avoir parfaitement analysé. Pour autant, cette analyse doit faire intervenir les probabilités de panne très différentes des composants : câble, switch, routeur, cpu, alimentation, disque, …

Il faut garder à l’esprit aussi que même si un composant est secouru, il devient critique dès la première panne, et jusqu’à réparation. Le temps moyen de réparation (MTTR Mean Time To Repair) est donc un facteur essentiel.

MTBF et probabilité de panne

On appelle MTBF, Mean Time Between Failures, le temps moyen entre pannes. C’est une caractéristique essentielle exprimant la fiabilité d’un composant. Ce n’est pas tout à fait la durée de vie moyenne, qui est une autre notion. L’idée est que à l‘intérieur de la durée de vie de l’équipement, le MTBF exprime la probabilité de panne. Précisément, le MTBF est l’inverse de l’espérance de panne. Par exemple, si le MTBF est de 10 ans, l’espérance de panne sur un an est de 0,1 : il y aura en moyenne 0,1 panne par an.

Les opérateurs qui exploitent plusieurs milliers de serveurs disposent de bonnes statistiques quant aux pannes. Le MTBF d’un serveur se situe entre 5 et 10 ans. 10 ans, cela signifie que si vous exploitez 10 serveurs, il vous faut compter sur une panne par an. Si vous exploitez 100 serveurs, environ une panne par mois. On voit bien qu’à partir de cette dimension, la panne est totalement banalisée. Et c’est lorsqu’elle est banalisée que l’on atteint la meilleure disponibilité.

Il existe différentes formules statistiques pour brasser les MTBF et les probabilités de panne. Sous Excel, vous disposez d’une fonction LOI.POISSON, qui vous donne la probabilité de N pannes pour une espérance donnée.

Il est intéressant par exemple de calculer ainsi la probabilité de double panne, comme sur le tableau suivant :

 

Si l’espérance d’occurrence d’un événement sur une période donnée est de E, alors la probabilité de N occurrence est LOI.POISSON(N, E, FAUX), et la probabilité de N occurrences ou moins est de LOI.POISSON(N, E, VRAI).

On voit ici que, pour un MTBF de 3 ans, la disponibilité malgré la redondance tombe en dessous de 0.995 pour un temps de réparation de 7 jours ce qui n’est pas négligeable, et en dessous de 0,9 s’il faut un mois pour réparer.

La brique de base, le serveur élémentaire

Supposons que les mesures de dimensionnement conduisent à une capacité de 100 pages par seconde sur un serveur, et que votre audience maximum à l’heure de pointe correspond à 150 pages par seconde. Il vous faut donc idéalement 1,5 serveurs, ce que raisonnablement on arrondit à 2 serveurs. Mais pour résister à une panne, on doit donc mettre en place 3 serveurs, c’est à dire deux fois la capacité nécessaire.

Si l’on pouvait disposer de serveurs ayant la moitié de cette capacité, pour la moitié du prix, alors on mettrait trois serveurs pour tenir 150 pages par seconde, un quatrième pour le secours. Soit au final 4 serveurs, mais pour les 2/3 du prix.

D’une manière plus générale, en matière de disponibilité, plus les unités élémentaires sont petites, moins la tolérance aux pannes est coûteuse, puisque le coût relatif de l’équipement de secours est de 1/N, où N est le nombre de serveurs en nominal.

Par ailleurs le meilleur rapport performance/prix est généralement obtenu vers le bas de la gamme.