Panne de Facebook : tout est parti d’une commande entrée lors d’une maintenance

Data Center Facebook

Une fois la poussière retombée et que les plateformes sont de nouveau opérationnelles, Santosh Janardhan, Vice-président des infrastructures de Facebook, explique plus précisément les raisons de la panne qui a affecté le réseau social durant plus de 6 heures, le 4 octobre. Il s’git « d’une panne causée non pas par une activité malveillante, mais par une erreur de notre propre fait » reconnait-il.

La panne a touché le système qui gère la capacité du réseau mondial de Facebook

La panne est intervenue sur le système qui gère la capacité du réseau mondial de Facebook. Ce réseau interconnecte toutes ses installations informatiques et ses centres informatiques. Le trafic de données entre toutes ces installations informatiques est géré par des routeurs, qui déterminent où envoyer toutes les données entrantes et sortantes. « Au quotidien, nos ingénieurs ont souvent besoin de mettre hors ligne une partie du réseau pour la maintenance, cela peut concerner la réparation d’une ligne de fibre optique, l’ajout de capacité ou en mettant à jour le logiciel sur le routeur lui-même » décrit le responsable.

« Une commande a été émise afin d’évaluer la disponibilité de la capacité du réseau. Cela a involontairement interrompu toutes les connexions »

« C’est la source de la panne d’hier. Au cours d’une maintenance de routine, une commande a été émise dans le but d’évaluer la disponibilité de la capacité du réseau mondial. Cela a involontairement interrompu toutes les connexions de notre réseau fédérateur, déconnectant les centres de données de Facebook dans le monde » explique-t-il. Des garde-fous étaient pourtant prévus. « Nos systèmes sont conçus pour vérifier des commandes comme celles-ci afin d’éviter de telles erreurs, mais un bug dans cet outil d’audit l’a empêché d’arrêter correctement la commande » regrette Santosh Janardhan.

Ce changement a entraîné une déconnexion complète des connexions de serveurs entre les centres de données et internet. Et cette perte totale de connexion a causé un deuxième problème qui a aggravé les choses. L’une des tâches effectuées par les plus petites installations de Facebook consiste à répondre aux requêtes DNS (Domain Name Server). Le DNS est le carnet d’adresses d’internet, permettant aux simples noms Web saisis dans les navigateurs web d’être traduits en adresses IP de serveur spécifiques. « Ces requêtes de traduction sont traitées par nos serveurs de noms qui occupent eux-mêmes des adresses IP bien connues. Elles sont à leur tour annoncées au reste d’internet via un autre protocole appelé le protocole de passerelle frontière, le BGP (Border Gateway Protocol) » précise-t-il.

L’ensemble du réseau fédérateur de Facebook a été mis hors service

Pour garantir un fonctionnement fiable, les serveurs DNS de Facebook désactivent les messages diffusés par BGP s’ils ne peuvent pas eux-mêmes parler aux centres de données, car cela indique une connexion réseau qui ne fonctionne pas correctement. « Lors de la récente panne, l’ensemble du réseau fédérateur de Facebook a été retiré du service, ce qui a amené ces emplacements à se déclarer comme ne fonctionnant pas correctement et à retirer ces messages BGP. Le résultat final était que nos serveurs DNS sont devenus inaccessibles même s’ils étaient encore opérationnels. Cela empêchait le reste d’internet de trouver nos serveurs » explique-t-il.

« Il n’était pas possible d’accéder aux centres de données par les moyens habituels car leurs réseaux étaient en panne »

En pratique, tout s’est passé très vite. « Pendant que nos ingénieurs essayaient de comprendre ce qui se passait et pourquoi, ils ont été confrontés à deux grands obstacles. Premièrement, il n’était pas possible d’accéder aux centres de données par les moyens habituels car leurs réseaux étaient en panne, et deuxièmement, la perte totale du DNS a empêché l’usage de nombreux outils internes normalement utilisés pour enquêter et résoudre des pannes comme celle-ci » poursuit-il.

Les accès réseau étant en panne, Facebook a donc envoyé des ingénieurs sur site dans les centres de données pour qu’ils déboguent le problème et redémarrent les systèmes. Mais cela a pris du temps, car l’accès de ces installations est sécurisé. Il est difficile d’y accéder, et une fois à l’intérieur, le matériel et les routeurs sont conçus pour être difficiles à modifier, même lorsqu’on y a accès. « Il a donc fallu du temps supplémentaire pour activer les protocoles d’accès sécurisés nécessaires pour que les gens soient sur place et capables de travailler sur les serveurs. Ce n’est qu’alors que nous avons pu confirmer le problème et remettre notre réseau dorsal en service » dit-il.

Précautions prises lors du redémarrage

Une fois la connectivité du réseau fédérateur restaurée, tout est revenu. Mais le problème n’était pas résolu. Réactiver les services d’un seul coup pouvait potentiellement provoquer une nouvelle série d’arrêts en raison d’un pic de trafic de données. Les centres informatiques individuels signalaient des baisses de consommation d’énergie de l’ordre de dizaines de mégawatts, et inverser soudainement une telle baisse de consommation d’énergie pouvait tout mettre en danger depuis les systèmes électriques jusqu’aux caches. En fin de compte, les services sont revenus relativement rapidement sans aucune autre panne à l’échelle du système.

Au final, Facebook estime à la lumière de ces événements que les délais introduits par la sécurité pour empêcher les accès non autorisés à ses systèmes, ont ralenti la remise en marche de ses réseaux, mais que c’est une bonne chose. « Un compromis comme celui-ci en vaut la peine avec une sécurité quotidienne considérablement accrue par rapport à une récupération plus lente après un événement » tranche Santosh Janardhan. Quant à des pannes de cette ampleur, « il faut qu’elles soient le plus rares possibles, et à partir de maintenant, notre travail consiste à renforcer nos tests, nos exercices et notre résilience globale » conclut-il.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *