Le 7 décembre dernier, l’hébergeur de cloud public AWS a essuyé une panne réseau au niveau de son principal datacenter américain, au nord-ouest des USA. Les accès aux services hébergés – dont ceux de Netflix, mais aussi du site d’e-commerce de la maison mère Amazon – ont été perturbés pendant plus de 7 heures. La panne, comme dans le cas de Facebook, comme dans le cas des numéros d’urgence d’Orange, fut la conséquence d’opérations de maintenance hasardeuses, selon un communiqué d’AWS. Elle a surtout mis en lumière la précarité d’une certaine installation réseau qu’AWS s’engage désormais à redonder.
« Ils souhaitent redonder le dispositif d’équilibrage de charge, censé basculer sur un réseau alternatif en cas de panne, avec une architecture actif-actif qui, quoiqu’il arrive, fait passer les données par deux trajets. En effet, le système d’équilibrage de charge peut lui-même être perturbé par la panne qu’il est censé contourner et dysfonctionner à son tour. Le mode actif-actif permet dès lors de passer par un module d’équilibrage de charge encore fonctionnel », commente le consultant en architectures réseau Mattias Andersson, du cabinet de conseil A Cloud Guru.
« Cette architecture permettra de continuer à fournir des services même si une région subit une panne, en orientant le trafic vers une autre région. Toutefois, elle sera plus complexe à mettre en place et à maintenir, car elle va nécessiter davantage de communications entre les serveurs pour rester synchronisée. La difficulté est de faire en sorte qu’une architecture active-active se comporte comme un système unique, alors qu’elle fonctionne à plusieurs endroits. La synchronisation des données sur de grandes distances est problématique », ajoute-t-il.
Le risque de panne est lié au risque de ne pas voir ce qu’il se passe
Selon AWS, si sa panne a duré si longtemps, c’est en partie parce qu’elle a affecté, comme chez Facebook, l’accès aux données de surveillance du réseau. Sans ces informations, les administrateurs d’AWS ne savaient pas simplement diagnostiquer le problème. Ce problème en a déclenché un autre : les informations relatives à la panne ne sont pas non plus remontées jusqu’aux tableaux de bord de monitoring qu’AWS met à la disposition des entreprises dont il héberge les services.
« Ces règles génériques – en clair, tout avoir en double ou en triple à des endroits différents – peuvent induire des coûts prohibitifs. »
Mattias AndersonConsultant en architectures réseau, cabinet de conseil A Cloud Guru.
En clair, les clients d’AWS n’ont pas été automatiquement prévenus de l’existence d’une panne, car leur console est restée muette. Ils n’ont réagi que tardivement : il était possible à leur niveau de router leurs abonnés vers d’autres régions d’AWS, encore opérationnelles. AWS a promis de mettre à jour ce système de tableau de bord au début cette année, pour améliorer la communication pendant les pannes.
« Les entreprises devraient plus que jamais s’intéresser au document Well Architected Framework d’AWS, afin d’évaluer dans quelles mesures elles peuvent se protéger des pannes du cloud public. La compréhension des fonctionnements inhérents au cloud d’AWS sera bien plus enrichissante que l’application de règles génériques qui sont censées réduire les risques », estime Mattias Andersson.
« Ces règles génériques – en clair, tout avoir en double ou en triple à des endroits différents – peuvent induire des coûts prohibitifs. D’autant que garantir 100 % de disponibilité tout le temps est rarement nécessaire. En revanche, si vous comprenez les mécanismes du cloud, vous pouvez mettre en place des processus de basculement efficaces, sans la contrainte d’un budget hors de proportion », conclut le consultant.
