Selon Facebook, la cause première de la panne de lundi est la conséquence d’une opération de maintenance de routine qui a mal tourné, provoquant l’inaccessibilité de ses serveurs DNS. Mais c'est d'abord l'ensemble du backbone de Facebook qui s'est effondré. Pour ne rien arranger, la perte du DNS a empêché les ingénieurs de Facebook d'accéder à distance aux dispositifs dont ils avaient besoin pour rétablir le réseau. Ils ont donc dû se rendre physiquement dans les datacenters pour redémarrer manuellement les systèmes.
Les leçons d'une catastrophe de stockage dans le cloud
L’obligation d’intervenir manuellement a certes ralenti les opérations, mais c’est les règles de sécurité des datacenters pour parer à toute intrusion qui a davantage compliqué les choses. « Il est difficile d'y pénétrer et, une fois à l'intérieur, le matériel et les routeurs ont été configurés de telle manière que toute modification est compliquée, même avec un accès physique au matériel », a expliqué Santosh Janardhan, vice-président de l'ingénierie et de l'infrastructure de Facebook dans un blog.
Il a donc fallu du temps, mais une fois les systèmes restaurés, le réseau est revenu à la normale. Cependant, le processus de restauration des services destinés aux clients qui fonctionnent sur le réseau a demandé également du temps, car une réactivation simultanée de tous ces services pouvait provoquer une autre série de pannes. « Les datacenters ont signalé des baisses de consommation d'énergie de l'ordre de dizaines de mégawatts, et l’inversion brutale de cette faible consommation présentait un risque important pour les équipements électriques mais aussi les caches », a encore écrit M. Janardhan. Au total, le réseau social a été indisponible pendant sept heures et cinq minutes.
Une erreur de maintenance de routine
C’est la mise hors ligne par Facebook d’une partie de son backbone pour maintenance qui a été le véritable déclencheur de la panne. « Au cours de l'une de ces opérations de maintenance de routine, une commande a été émise afin d'évaluer la disponibilité de la capacité globale du backbone, et elle a mis involontairement hors service toutes les connexions de notre backbone, déconnectant les datacenters de Facebook dans le monde entier », a encore expliqué Santosh Janardhan. Ce n'était pas prévu, d’autant que le réseau social avait même mis en place un outil pour trier les commandes susceptibles de provoquer une panne catastrophique de ce type, mais la parade n'a pas fonctionné. « Nos systèmes sont conçus pour auditer ce genre de commandes et éviter de telles erreurs, mais un bug dans notre outil d'audit a empêché le blocage de la commande », a écrit M. Janardhan. Une fois que la panne avait eu lieu, le DNS était condamné.
Le DNS, point unique de défaillance
Selon Angélique Medina, responsable du marketing produit chez Cisco ThousandEyes, qui surveille le trafic et les pannes sur Internet, c'est une réponse automatisée à la panne du backbone qui semble avoir mis le DNS hors service. Le système de noms de domaines répond aux demandes de traduction de noms de sites Web en adresses IP, et Facebook héberge ses propres serveurs de noms DNS. « L’architecture est conçue de façon à étendre ou à réduire le service DNS en fonction de la disponibilité des serveurs », a expliqué Mme Medina. « Au moment où la disponibilité des serveurs est tombée à zéro en raison d'une panne du réseau, ces serveurs ont mis hors service tous leurs serveurs DNS », a-t-elle ajouté.
Cette mise hors service a été réalisée par les serveurs de noms DNS de Facebook, qui ont envoyé des messages aux routeurs BGP (Internet Border Gateway Protocol), lesquels stockent des informations sur les routes à utiliser pour atteindre des adresses IP spécifiques. Ces routes sont régulièrement rappelées aux routeurs afin qu'ils sachent diriger le trafic de manière appropriée. Les serveurs DNS de Facebook ont envoyé des messages BGP qui désactivaient les routes annoncées pour eux-mêmes, rendant impossible la résolution du trafic sur le backbone de Facebook. « La conséquence de tout cela, c’est que nos serveurs DNS sont devenus inaccessibles, même s'ils étaient encore opérationnels. Il était donc impossible pour le reste de l'Internet de trouver nos serveurs », a écrit Santosh Janardhan.
Une gestion trop centralisée des DNS
Même si les serveurs DNS étaient encore accessibles depuis l'internet, les clients de Facebook auraient perdu le service parce que le réseau qu'ils essayaient d'atteindre était en panne. Malheureusement pour Facebook, ses propres ingénieurs ont également perdu l'accès aux serveurs DNS, indispensables pour que leurs plateformes de gestion à distance puissent atteindre les systèmes de backbone en panne. « Facebook n'utilise pas son service DNS uniquement pour ses sites Web destinés aux clients », a aussi expliqué Angélique Medina.
« Ils l'utilisent également pour leurs propres outils et systèmes internes. Le fait qu’il ait été complètement hors service a empêché les opérateurs ou les ingénieurs réseau d'accéder aux systèmes dont ils avaient besoin pour résoudre le problème », a-t-elle ajouté. « Dans une architecture plus robuste, les services DNS seraient dédoublés de façon à ce que l’un des services puisse sauvegarder l'autre », a-t-elle encore ajouté. « Par exemple, Amazon, et plus exactement son service DNS sur AWS, utilise deux services externes - Dyn et UltraDNS - pour son DNS », a rappelé Mme Medina.
Les leçons à tirer
L'incident semble indiquer que l'architecture de Facebook ne respectait pas les meilleures pratiques en matière de réseau. « Pourquoi le DNS a-t-il effectivement été le point de défaillance unique ? », s’interroge Angélique Medina. « Si la défaillance résulte uniquement du DNS et qu’il n’y a pas de DNS de secours, alors on peut effectivement craindre une panne prolongée. C’est pourquoi, la redondance du DNS est une des leçons importantes à retenir de la panne de Facebook », a conclu Mme Medina. Cette dernière fait également une observation générale à propos d'autres pannes de fournisseurs de services.
« Souvent, ces pannes sont dues à un nombre élevé d'interdépendances au sein du réseau, si bien qu'un petit problème dans une partie de l'architecture du service peut se répercuter en cascade dans toute l’architecture », a-t-elle expliqué. « La plupart des entreprises exécutent un grand nombre de services internes, ce qui peut avoir des conséquences imprévues. Cet aspect concerne peut-être davantage les techniciens, mais je pense qu’il mérite d'être souligné ».