Pannes dans le Cloud : les acteurs les plus résistants

AWS n°1

Amazon Web Services a certes eu sa part de pannes graves ces dernières années, mais cette année, tout a été calme dans ce domaine, s’accordent à dire les partenaires de la société. « Nous avons constaté quelques ralentissements des services, mais aucune interruption n’a été remontée par les clients », précise Kris Bliesner, CTO de 2^nd Watch, un partenaire Amazon, spécialisé dans le conseil.

« Le groupe avait prévu de développer une application qui pouvait servir de premier service d’alerte pour ses clients, en cas de panne. Mais cela avait finalement été relégué dans le bas de la liste des développements prioritaires, soutient Kris Bliesner. « Nous ne constatons tout simplement plus de pannes », justifie-t-il.

Cela pourrait être dû au fait qu’AWS a développé une certaine expertise à concevoir une infrastructure hautement résistante et qu'il est déjà passé par des étapes qui  affectent aujourd’hui les fournisseurs de Cloud moins matures, explique-t-il.

Cela fut d’ailleurs le message de James Hamilton, vice-président chez AWS, qui a présenté les innovations de la société lors de la conférence re:Invent du groupe. Amazon en est venu à développer son propre réseau ainsi que ses propres équipements stockage et serveurs ; ce qui a eu pour conséquence d’abaisser les coûts et d’améliorer la fiabilité, affirme le vice-président.

Avec l’expérience, les clients AWS ont appris à créer des applications plus résilientes

« Les entreprises ont livré des exigences très complexes aux équipementiers réseaux qui doivent ensuite les intégrer dans des dizaines de millions de lignes de code qui ne peuvent pas être entretenues », affirme James Hamilton dans sa présentation. « Nous n’utilisons pas tout cela. »

Amazon prend aussi très à cœur l’amélioration du contrôle et des indicateurs d’infrastructure sur un rythme hebdomadaire, ce qui a contribué à également améliorer la fiabilité, ajoute-t-il. Le système de zones de disponibilité (AZ) d’AWS relie plusieurs datacenters au sein de zones qui sont synchronisées pour la haute disponibilité. Des services, comme RDS (Relational Database Service) offre également de la réplication entre AZ, augmentant ainsi le nombre de sites redondants.

Avec l’expérience, les clients AWS ont appris à créer des applications plus résilientes. Lors de l’arrivée de RDS, seulement 26% exploitaient la réplication entre plusieurs zones  de disponibilité. Ce nombre est aujourd’hui de 40% et l’objectif est d’atteindre 70%, confie James Hamilton.

Les nouvelles bases de données dans le Cloud d’AWS, comme Aurora, offrent également plus de résilience grâce à une sur-couche au dessus du moteur de stockage – celle-ci existe dans Aurora et est séparée de la base de données principale. Elle peut être récupérée rapidement en cas de défaillance. Aurora triple également la réplication des données, réalisant 6 copies à travers les AZ.

La conception de datacenter chez Amazon a aussi été pensée pour offrir une résilience optimale, affirme encore James Hamilton. Ces datacenters renferment entre 50 000 et 80 000 serveurs au maximum.

« Nous pouvons aller plus loin, mais cela comporte un risque. S’il y a un problème, la perte est trop importante », commente-t-il.

Parce que AWS a appris à optimiser le rapport disponibilité / dimensionnement, les concurrents d’AWS, qui sont entrés plus tard dans le marché du Iaas, pourraient être sujets aux pannes dont Amazon a précédemment été victime, rapporte Kris Bliesner. « A un moment donné, si Azure et Google veulent rivaliser, ils vont devoir faire un bond en termes de dimensionnement. Les clients sont-ils plus exposés aux pannes pendant cette période ? », s’interroge-t-il.  «  Je pense que oui. »

Toutefois, Amazon se classe parfois derrière Google. Google Cloud Storage a connu en effet 8 pannes pour un total de 14,23 minutes tandis qu’Amazon S3 a été victime de 22 pannes pour 2,66 heures, selon les chiffres de CloudHarmony.

Pas d’infaillibilité complète

Les erreurs en cascade sont possibles, mais lorsque des pannes majeures interviennent, c’est généralement dû à une erreur humaine, plutôt qu’à une défaillance du hardware, raconte Jonah Kowall, analyste chez Gartner.

« Ils mettent en place toutes les bonnes pratiques pour éviter ces problèmes, mais les pannes restent possibles sur un système complexe sur lequel on opère des modifications », poursuit-il. Les entreprises vont généralement plus lentement car elles ont créé une infrastructure et des processus très complexes, ajoute  Jonah Kowall. Le Cloud apparaît comme un cercle vicieux, car si l’attrait tourne autour de l’agilité et de la rapidité, les cycles de mise à jour, plus courts et moins sujets à règles d’approbations strictes, peuvent être synonymes de bugs. Un problème pour les clients, soutient-il.

Les redémarrages prévus à l’avance sont souvent une cause d’interruption de services de compute. Cela peut aussi être un signe d’une infrastructure dont l’administration est perfectible, explique à son tour Jason Read.

« Les fournisseurs composent avec les pannes, poursuit-il. Les bons mènent des enquêtes sur les causes premières de l’incident et changent leur politique ou ajustent leurs applications pour s’assurer que les événements en cause ne se reproduisent pas. »

Et apprendre à partir de ce type d’erreur est souvent d’une grande aide, rapporte Paul  Voccio, vice-président du développement logiciel chez Rackspace. « Lorsque l’industrie est en phase de maturité, chacun apprend de l’autre comment il doit opérer ses serveurs à grande échelle et d’une façon avisée. »

Au siège de Rackspace à San Antonio, Paul Voccio dispose de deux larges écrans sur son bureau pour contrôler et surveiller les indicateurs du Cloud public de la société. « Les clients attendent un état de fonctionnement permanent,  nous prenons cela très au sérieux », avance-t-il.

Rackspace, qui met en avant un taux de disponibilité de 99,999% dans tous ses datacenters depuis 2009, organise des réunions hebdomadaires pour discuter des performances du système et d’assurer que les opérations de maintenance prévues sont bien calées. La société a amélioré la résilience et la redondance de chacun de ses centres. Elle a appris qu’isoler les clusters est primordial pour diagnostiquer rapidement les problèmes et empêche une panne en cascade dans les autres datacenters, explique Paul Voccio.

Le Cloud (Compute) de Rackspace est resté indisponible pendant 7,52 heures, toutes régions confondues, l’année dernière, selon les chiffres de CloudHarmony. Le groupe est connu pour avoir relancé son système l’année dernière à cause d’un bug de l’hyperviseur Xen et a dû affronter les critiques sur sa gestion de crise.

« Il est difficile de dire aux clients qu’un problème doit être résolu mais qu’ils ne doivent pas en parler à cause d’un embargo », explique-t-il. Rackspace cite souvent son support comme un élément différenciateur, mais pour Paul Voccio, c'est mieux si les clients ont ce qu’ils veulent sans avoir à se tourner vers l’équipe support. « Même si nous sommes là pour répondre au téléphone, la plupart des clients préfère ne pas appeler. »

Les barrières de la transparence

Les fournisseurs de services Cloud ont certes publié sur leurs sites Web des informations sur des temps d’indisponibilité courant sur plusieurs semaines, mais aucun d’entre eux contactés par nos confrères de TechTarget (propriétaire du MagIT) ne donnent de chiffres sur une base annuelle.

Nombre d’acteurs du Cloud limite la capacité des clients à vérifier le bon fonctionnement de leurs services

Jonah Kowall, Cabinet Gartner

Ils hésitent à livrer les informations et certaines ne mentionnent pas les périodes de pannes, totales ou partielles, de leur système, affirme Jason Read. Des problèmes peuvent également intervenir sur les pages liées à la santé du Cloud, ce qui est plus grave lorsque le fournisseur héberge son propre site et qu’une panne efface le tableau de bord des services à destination des clients.

« Une partie du problème tient au fait que nombre d’acteurs du Cloud d’entreprise limite l’action des clients et de leur capacité à vérifier le fonctionnement des services et c’est particulièrement vrai pour le Saas », explique Jonah Kowall.

La plupart essaie d’émuler le comportement d’un utilisateur. Une application est configurée pour se logguer, effectuer une série d’actions quelques minutes depuis plusieurs sites. « Mais les fournisseurs n’apprécient pas car cela augmente la charge de leur système », soutient-il. 

« Ils essaient de limiter cela avec des contrats, et probablement, ne souhaitent pas qu’on les tienne responsables en matière de stabilité, ce qui est préoccupant, ajoute Jonah Kowall, vous devez négocier avec eux sur ce que vous êtes autorisés à faire avec leurs systèmes ».

Les fournisseurs de services Cloud devraient en faire davantage pour accroître la transparence afin que les clients en sachent plus sur la mécanique du système, lance Paul Voccio de Rackspace. « Les clients veulent avoir davantage d’informations sur la stack. Cela suscite de l’hésitation donc nous réfléchissons à des moyens pour être plus transparents sur l’ensemble de la pile technologique. »

Google n’a pas souhaité répondre aux questions de la rédaction dans le cadre cet article, mais a rappelé dans un communiqué que le groupe s’était engagé à améliorer la  fiabilité de la Google Cloud Platform.

Quat à Microsoft, il s’est refusé à tout commentaire.

Adapté par la rédaction