Créer des services cloud à tolérance de panne

Une grande partie de la gestion des centres de données et du management des services cloud implique la conception et la maintenance d’un service fiable basé sur des parties non fiables. La figure suivante montre une partie de formation destinée aux nouveaux employés. Elle doit donner une idée du grand nombre (et des types) de défaillances qui se produisent régulièrement dans un grand centre de données.

Figure 2 : Problèmes de fiabilité, comme indiqué dans une présentation de formation

Une défaillance dans un système se produit à la suite d’un état non valide introduit dans le système en raison d’une erreur. Les systèmes développent généralement des erreurs de l’un des types suivants :

• Erreurs temporaires : Erreurs temporaires dans le système, qui se corrigent avec le temps.
• Erreurs permanentes : Erreurs irrécupérables, qui nécessitent généralement le remplacement des ressources.
• Erreurs intermittentes : Erreurs qui se produisent périodiquement dans un système.

Les erreurs peuvent affecter la disponibilité du système en réduisant les services ou les performances des fonctionnalités du système. Un système à tolérance de panne peut remplir sa fonction même en cas de défaillance du système. Dans le cloud, un système à tolérance de panne est souvent considéré comme un système qui fournit des services de manière cohérente avec des temps d’arrêt inférieurs à ceux autorisés par les SLA (Contrats de niveau de service).

Pourquoi la tolérance de panne est-elle importante ?

Les défaillances des systèmes stratégiques peuvent entraîner des pertes financières significatives pour toutes les parties concernées. La nature même des systèmes de cloud computing repose sur une architecture en couches. Ainsi, une défaillance dans une couche des ressources cloud peut déclencher une défaillance dans les autres couches supérieures, ou masquer l’accès aux couches inférieures.

Par exemple, une défaillance d’un composant matériel du système peut affecter l’exécution normale d’une application SaaS (software as a service) s’exécutant sur une machine virtuelle qui utilise des ressources défectueuses. Les erreurs qui surviennent sur un système à n’importe quelle couche ont une relation directe avec les SLA entre les fournisseurs à chaque niveau.

Mesures proactives

Les fournisseurs de services prennent plusieurs mesures afin de concevoir le système de manière spécifique pour éviter les problèmes connus ou les pannes prévisibles.

Profilage et test

Les tests de charge et les tests de contrainte des ressources cloud sont essentiels pour comprendre les causes possibles de défaillance ainsi que pour garantir la disponibilité des services. Le profilage de ces métriques permet de concevoir un système capable de supporter correctement la charge attendue sans aucun comportement imprévisible.

Surprovisionnement

Le surprovisionnement est la pratique qui consiste à déployer des ressources dans des volumes plus importants que l’utilisation générale prévue de ces ressources à un moment donné. Dans les situations où les besoins exacts du système ne peuvent pas nécessairement être prédits, un surprovisionnement des ressources peut être une stratégie acceptable pour gérer les pics de charge inattendus.

Prenons l’exemple d’une plateforme d’e-commerce qui a une charge moyenne constante sur ses serveurs toute l’année. Pendant la période des fêtes, on s’attend à ce que le modèle de charge atteigne rapidement des pics. En prévision de ces pics, il est conseillé de provisionner des ressources supplémentaires en fonction des données historiques pour une utilisation maximale. Une augmentation rapide du trafic est généralement difficile à gérer sur une période de temps limitée. Comme indiqué dans les prochaines sections, il existe un coût en temps associé à la mise à l’échelle dynamique, ce qui implique des étapes fastidieuses de détection d’un changement dans le modèle de charge, et de provisionnement de ressources supplémentaires pour la gestion de la nouvelle charge. Ces deux étapes nécessitent du temps. Ce retard d’ajustement peut être suffisant pour saturer, et dans le pire des cas, planter le système, ou dans le meilleur des cas, dégrader la qualité de service.

Le surprovisionnement est également une tactique utilisée pour se défendre contre les attaques DoS (déni de service) ou DDoS (DoS distribué), c’est-à-dire le moment où les attaquants génèrent des requêtes conçues pour saturer un système en y envoyant de gros volumes de trafic afin de provoquer l’échec de ce système. Dans toute attaque, il faut toujours un certain temps pour que le système détecte le problème et prenne des mesures correctives. Bien qu’une analyse des modèles de requête soit en cours d’exécution, le système est déjà attaqué et doit être capable de s’adapter à l’augmentation du trafic jusqu’à ce qu’une stratégie d’atténuation puisse être implémentée.

Réplication

Vous pouvez dupliquer les composants système critiques à l’aide de composants matériels et logiciels supplémentaires pour gérer sans assistance les défaillances de certaines parties du système sans que le système entier ne tombe en panne. La réplication a deux stratégies de base :

• La réplication active, où toutes les ressources répliquées sont actives simultanément. Elles répondent à toutes les requêtes, et les traitent. Cela signifie que pour toutes les requêtes clientes, toutes les ressources reçoivent la même requête, toutes les ressources répondent à la même requête, et l’ordre des requêtes conserve l’état parmi toutes les ressources.
• La réplication passive, où seule l’unité principale traite les requêtes, et où les unités secondaires conservent simplement l’état et prennent le relais en cas de défaillance de l’unité principale. Le client est uniquement en contact avec la ressource principale, qui relaie le changement d’état à toutes les ressources secondaires. L’inconvénient de la réplication passive est qu’il existe parfois des requêtes abandonnées ou une qualité de service (QoS) dégradée au moment du passage de l’instance principale à l’instance secondaire.

Il existe également une stratégie hybride, appelée stratégie semi-active, qui est très similaire à la stratégie active. La différence vient du fait que seule la sortie de la ressource principale est exposée au client. Les sorties des ressources secondaires sont suspendues et journalisées, prêtes à être activées dès qu'une défaillance de la ressource principale survient. La figure suivante montre les différences entre les stratégies de réplication.

Figure 3 : Stratégies de réplication

Il existe un facteur important à prendre en compte dans la réplication. Il s’agit du nombre de ressources secondaires à utiliser. Bien que cela diffère d’une application à l’autre en fonction de l’état critique du système, il existe 3 niveaux formels de réplication :

• N+1 : Cela signifie que pour une application qui a besoin de N nœuds pour fonctionner correctement, une ressource supplémentaire est provisionnée en tant que ressource de prévention de défaillance.
• 2N : À ce niveau, un nœud supplémentaire pour chaque nœud nécessaire à un fonctionnement normal est provisionné en tant que nœud de prévention de défaillance.
• 2N + 1 : À ce niveau, un nœud supplémentaire pour chaque nœud nécessaire à un fonctionnement normal et un nœud supplémentaire global sont provisionnés en tant que nœuds de prévention de défaillance.

Mesures réactives

En plus des mesures prédictives, les systèmes peuvent prendre des mesures réactives et gérer les défaillances au fur et à mesure qu’elles se produisent :

Vérifications et supervision

Toutes les ressources sont supervisées en permanence pour permettre l’identification des comportements imprévisibles ou des pertes de ressources. En fonction des informations de supervision, des stratégies de récupération ou de reconfiguration sont conçues pour permettre le redémarrage des ressources ou la mise en place de nouvelles ressources. La supervision peut permettre d’identifier les erreurs au sein des systèmes. Les erreurs qui provoquent l’indisponibilité d’un service sont appelées erreurs de plantage, alors que celles qui induisent un comportement irrégulier/incorrect dans le système sont appelées erreurs byzantines.

Il existe plusieurs tactiques de supervision pour rechercher les erreurs de plantage dans un système. Deux de ces tactiques sont :

• Ping-echo : Le service de supervision demande à chaque ressource son état et dispose d’un délai pour répondre.
• Pulsation : Chaque instance envoie un état au service de supervision à intervalles réguliers, sans déclencheur.

La surveillance des défauts byzantins dépend généralement des propriétés du service fourni. Les systèmes de supervision peuvent vérifier les métriques de base telles que la latence, l’utilisation du processeur et l’utilisation de la mémoire. Ils peuvent également vérifier les valeurs attendues pour voir si la qualité de service s’est dégradée. De plus, les journaux de supervision spécifiques aux applications sont généralement conservés à chaque point d’exécution de service important et analysés régulièrement pour vérifier si le service fonctionne correctement à tout moment (ou pour déterminer s’il existe des défaillances injectées dans le système).

Point de contrôle et redémarrage

Plusieurs modèles de programmation dans le cloud implémentent des stratégies de point de contrôle, dont l’état est enregistré à plusieurs étapes de l’exécution pour permettre une récupération vers le dernier point de contrôle enregistré. Dans les applications d’analytique données, il existe souvent des tâches distribuées parallèles de longue durée qui s’exécutent sur des téraoctets de jeux de données pour extraire des informations. Dans la mesure où ces tâches sont exécutées en plusieurs petits blocs d’exécution, chaque étape de l’exécution du programme peut enregistrer l’état global de l’exécution en tant que point de contrôle. Aux points de défaillance où les nœuds individuels ne peuvent pas effectuer leur travail, l’exécution peut redémarrer à partir d’un point de contrôle précédent. Le plus grand défi dans l’identification des points de contrôle valides à restaurer est le moment où les processus parallèles partagent des informations. Une défaillance dans l’un des processus peut entraîner une restauration en cascade dans un autre processus, car les points de contrôle créés dans ce processus peuvent résulter d’une erreur dans les données partagées par le processus défaillant. Vous en apprendrez plus sur la tolérance de panne pour les modèles de programmation dans les prochains modules.

Études de cas dans les tests de résilience

Vous devez concevoir les services cloud en ayant à l’esprit les fonctionnalités de redondance et de tolérance de panne, car aucun composant d’un grand système distribué ne peut garantir une disponibilité ou une durée de fonctionnement de 100 %.

Toutes les défaillances (notamment les défaillances de dépendances dans le même nœud, le même rack, le même centre de données ou les déploiements redondants régionaux) doivent être gérées correctement sans affecter l’intégralité du système. Il est important de tester la capacité du système à gérer les défaillances graves, car parfois même quelques secondes de temps d’arrêt ou de dégradation de service peuvent entraîner des centaines de milliers, voire des millions de dollars de pertes financières.

Le test des défaillances avec du trafic réel doit être effectué régulièrement pour durcir la sécurité du système, et permettre à ce dernier de faire face à une panne non planifiée. Il existe différents systèmes conçus pour tester la résilience. L’une de ces suites de tests est la Simian Army créée par Netflix.

La suite Simian Army se compose de services cloud (faisant référence à des singes), qui permettent de générer divers genres de panne, de détecter des conditions anormales et de tester la capacité du système à y résister. L’objectif est de garder le cloud fiable, sécurisé et hautement disponible. Voici quelques singes trouvés dans Simian Army :

• Chaos Monkey : Outil qui sélectionne au hasard une instance de production et la désactive pour vérifier que le cloud résiste aux types de défaillance courants sans le moindre impact pour le client. Netflix décrit Chaos Monkey comme « l’idée de lâcher un singe sauvage armé dans votre centre de données (ou région cloud) afin de tirer sur des instances et de ronger des câbles au hasard, tout en continuant à fournir vos services à vos clients sans interruption ». Ce type de test avec monitoring détaillé peut exposer diverses formes de faiblesses dans le système, et des stratégies de récupération automatique peuvent être générées en fonction des résultats.
• Latency Monkey : Service qui induit des retards dans la communication RESTful de différents clients et serveurs, en simulant une dégradation des services et des temps d’arrêt.
• Doctor Monkey : Service qui recherche les instances présentant des comportements non sains (par exemple au niveau de la charge du processeur), et qui les supprime. Cela permet aux propriétaires de services de disposer d’un certain temps pour comprendre la raison du problème et mettre fin à l’instance.
• Chaos Gorilla : Service qui peut simuler la perte d’une zone de disponibilité AWS entière. Cela permet de vérifier si les services rééquilibrent automatiquement la fonctionnalité entre les zones restantes, sans impact visible par l’utilisateur ou intervention manuelle.