Nombreux sont nos clients qui nous posent la question de manière récurrente : Comment garantir la résilience dans le cloud public au regard des niveaux de services (SLA).
C’est en effet un véritable dilemme, car la résilience des applications et des services a un coût non négligeable et les compensations en cas de panne sont rarement avantageuses. Nos experts vous expliquent quelle sont les meilleures options de résilience au meilleur coût, en fonction des SLAs des services des CSPs.
Les fournisseurs Cloud Public offrent une gamme d'outils et de services optionnels permettant aux utilisateurs d’architecturer des applications résilientes, y compris des emplacements géographiquement distribués et des services d'équilibrages de charge.
Ils publient des données limitées pour évaluer la résilience, telles que le taux moyen de défaillances ou le temps moyen de réparation. Il n'existe pas de mesures publiées[1] sur le temps réel de récupération ou le temps moyen de récupération. Par conséquent, la conception de la résilience est un art axé sur "ce qui fonctionnera probablement" plutôt que sur de la rigueur scientifique.
Choisir la bonne option de résilience pour limiter l'impact des pannes.
Pour limiter l'impact de pannes de cloud de plus en plus fréquentes et généralisées, les utilisateurs doivent concevoir des applications cloud natives résilientes aux défaillances des machines virtuelles, des zones de disponibilités (AZ) et des régions des CSPs.
En cas d'interruption de service, il est en effet peu probable que les indemnités des fournisseurs puissent couvrir les pertes engendrées par l’indisponibilité de l’application et des pertes commerciales consécutives.
Pour anticiper une interruption de service en cloud public, il existe de multiples architectures permettant de fournir le meilleur compromis de résilience aux utilisateurs: Compromis en termes de garanties SLA, de temps de récupération, de niveau de protection, mais aussi de coûts engendrés.
Les SLA des CSPs s’appliquent sur les services et non sur les applications! Les compensations en cas de panne ne couvriront jamais les pertes commerciales!
Les accords de niveau de service (SLA) des fournisseurs de cloud computing et les modèles de référence publiés offrent des garanties de performance. Mais ces garanties sont axées sur leurs services et non sur les applications des utilisateurs.
De même, ces SLAs ne prévoient qu'une compensation minimale en cas de panne.
Si une application entière tombe en panne, à cause d'un seul service cloud, la compensation n'est due que pour le service défaillant. En conséquence, les SLAs offrent une compensation sanctionnant les temps d'arrêt et non une compensation équivalente à la perte commerciale.
Les utilisateurs peuvent toutefois demander une compensation pour la défaillance d'un service, même si la panne n'a pas eu d'impact sur une application.
La spécification d'un SLA varie selon les services. La résilience de certains services, tels que les équilibreurs de charge sont gérés par les CSPs sous la forme d'un modèle PaaS. Pour d'autres services, tels que les VMs, l’utilisateur est responsable d'architecturer la résilience sous la forme d'un modèle d'infrastructure en tant que service (IaaS). Voir ci-dessous les modèles de responsabilité Utilisateur vs CSP.
Responsabilité utilisateur | Responsabilité Fournisseur |
Architecture et déploiement des services cloud. Mise à l’échelle de l’architecture (scalability) | Installation, entretien et mise à jour des matériels et logiciels pour fournir les services |
Architecture-conception des applications en termes de résilience en utilisant des charges de travail redondantes entre les régions et les zones. Détermination de la résilience des applications | Proposition et gestion des AZ (zones de disponibilités) et/ou régions pour aider les utilisateurs à renforcer la résilience des applications. |
Configuration de l’équilibrage de charge | Equilibrage de charge en PaaS. Responsable de la résilience et de l’efficacité de l’équilibrage de charge |
Architecture de la résilience des VMs | Gestion et mise à jour |
Mesure du temps d’arrêt en cas de panne pour demander une compensation | Compensation offerte en crédit de service et non en espèces, en cas de panne |
L'indemnisation due par le prestataire en cas d'interruption de service dépend de la durée de l'indisponibilité du service. Pour le calcul de l’indemnité, il faut supposer que la consommation moyenne de la bande passante et de l'équilibreur de charge reste la même en cas de panne.
Par exemple, si une VM est indisponible pendant une heure, l'application sera incapable de gérer le trafic pendant ce laps de temps. Les frais de bande passante et d'équilibreur de charge seront donc nuls pendant cette période.
Exemples de scénarii de résilience.
Standard: Une VM, une zone, une région | Remboursement max 100% si temps d'arrêt > à 1,5 jrs, pour un taux de disponibilité < à 95%. Indemnisation plancher d'environ 29% même si application indisponible pendant plusieurs semaines! | Scénario à éviter tant que possible |
VM active-Active | Avec équilibrage de charge. Traffic entrant gratuit. Coût mensuel > 43%. Taux de disponibilité de 99,5% si VMs dans la même AZ : Temps de récupération 0'. Remboursement unique sur une VM en cas de panne. | Frais de largeur de bande entre équilibreur et utilisateur. Si VMs situées sur le même serveur physique et la même AZ. en cas de défaillance serveur ou de panne AZ, la protection est insuffisante. Remboursement uniquement sur la VM en panne. |
Résilience Zone Actif-Actif | Répartition du trafic sur plusieurs AZ. Equilibrage de charge dans plusieurs AZ. Protection au niveau VMs et zone. Taux de disponibilité de 99,99%. Attention en cas de panne de l'équilibreur de charge. Dispo globale = dispo équilibrage de charge. Tarif 43%> à scénario 1. | L'équilibrage de la charge sur deux AZ coûte le même prix que l'équilibrage sur une seule zone tout en offrant une plus grande résilience. Remboursement moyen, tous scénarios confondus, pour une panne > 1 journée d'environ 47 %. Assez bon compromis |
Résilience de la zone en basculement actif | Permet de limiter les coûts en arrêtant une VM dans une zone et réactivation dans une autre zone en cas de panne. Attention au temps de redémarrage de VM (5 à 15 mn). Coût de 14% par rapport à scénario 1 mais taux de disponibilité de 99,5% à cause du basculement. | Remboursement moyen dû pour une panne de plus de 1,5 jour de 57% du coût mensuel de l'application. Aucune compensation n'est due sur le basculement car il n'est pas en service. Assez bon ratio coût/dispo |
Résilience au niveau VMs, zones et régions | La plupart des services des CSPs sont résilients au niveau zone et ne sont pas conçus nativement pour fonctionner dans plusieurs régions. Pas d'équilibrage de charge inter région, il faut utiliser un DNS à la place. Pour réduire les coûts, une version barebones de l'application peut être mise en œuvre dans une région de basculement, voire un basculement actif en mode veille. Le mode pilote light est encore moins cher, mais avec un temps de récupération plus long. | Préférer un DNS actif actif inter régions. Le DNS a ses limites, notamment si l'adresse IP de l'application devient indisponible et avant MaJ du cache local. Coût du DNS faible mais pas d'amélioration notable du SLA même si une zone de disponibilité ou une région entière tombe en panne. Rares sont les CSPs qui fournissent des SLAs sur la disponibilité des deux régions ! |
De l’intérêt de bien comparer coût et niveaux de résilience!
Les zones de disponibilité (AZ) sont le pilier de la résilience du cloud. Elles offrent une redondance facilement configurable à un coût relativement faible. De nombreux services cloud sont conçus pour offrir une résilience entre les zones, en standard.
Les architectures de redondance et de basculement à travers les zones de disponibilité offre une disponibilité plus élevée que celle d'une seule zone, mais avec un impact négligeable sur les frais généraux ou d’administration du cloud.
Étant donné que la résilience au niveau de la zone est relativement bon marché, la 1ère des recommandations est de répartir les charges de travail sur plusieurs zones de disponibilité.
La résilience régionale doit faire l’objet d’une attention importante, car de nombreux services cloud ne sont pas résilients dans toutes les régions en standard. Il faut donc bien veiller à vérifier la disponibilité des services des CSPs par régions !
Les utilisateurs peuvent s'attendre à payer un surcoût d'environ 111 % du coût d'un scénario de résilience standard pour un scénario protégeant les VMs, les zones, et les régions défaillantes, avec un temps de récupération immédiat.
Ce surcoût peut être ramené à 52 % en mode d’architecture pilote léger, seulement si l'utilisateur peut tolérer un délai pour la mise en ligne de la capacité supplémentaire.
La mise en place d'un basculement vers une région reste assez bon marché.
Un service DNS pré-activé peut être utilisé pour basculer vers une région de secours lors d'une panne importante, et si la région est préparée à l'avance avec un minimum de ressources pour faciliter la récupération.
La résilience inter régionale devient nettement plus complexe avec les applications dynamiques car les données doivent être répliquées à une cadence régulière, sur des sites géographiques dispersés.
Cette protection présente surcoût de seulement 5 % par rapport à une architecture protégée par une zone active-active. Les utilisateurs devront cependant prévoir des scénarios pour faire face à une panne régionale.
La différence de coût entre une architecture active-active et une architecture active-failover est assez minime, d'environ 30 %.Les utilisateurs doivent donc bien réfléchir avant de restreindre les coûts au détriment du temps de récupération!
La résilience entre différents fournisseurs de clouds, dans le cas du multi cloud est également plus complexe en raison des différences de standard SLA entre les CSPs.
Plus l'application est résiliente, plus le nombre de services est important et plus le coût est élevé. Une plus grande résilience engendre également une plus grande complexité car il y a plus de composants à gérer et, par conséquent, plus d'éléments susceptibles de tomber en panne. La compensation due des SLAs est médiocre et il est très peu probable qu'elle couvre les impacts commerciaux qui résultent des temps d'arrêts. Le CSP n'accordera une compensation que pour le maillon le plus faible qui a causé la panne. C’est la raison pour laquelle, il propose un SLA pour chaque type de service.
Avec une architecture active-active inter régions, le CSP ne couvrira probablement que 50 % du coût de l'application, même si celle-ci est indisponible pendant un mois entier.
La construction d'architectures à travers des zones de disponibilité (AZ) et des régions est nécessairement plus résiliente qu'une seule VM dans une seule zone. Il est cependant difficile de quantifier cette résilience avec un haut degré de précision.
Les SLAs et objectifs de conception des CSPs n’offrent pas une vue objective de cette résilience. Les fournisseurs publient des données limitées pour évaluer cette résilience, telles que le taux moyen de défaillances ou le temps moyen de réparation. En absence de mesures publiées sur le temps de récupération ou le temps moyen de réparation, l'analyse de la résilience reposera "ce qui fonctionnera probablement".
[1] B2CLOUD a crée sa propre matrice de confiance qui permet de mesurer le taux de SLA avec les données fournies par les CSPs, incluant y compris la disponibilité des comptes de stockage. Dans cette matrice, le taux de SLA est corrélé avec d’autres valeurs de résilience des plateformes afin de calculer avec plus de granularité le rapport Transparence/Fiabilité