Facebook: Plus de détails sur la super panne du 4 octobre 2021
Maintenant que nos plateformes sont opérationnelles comme d'habitude après la panne d'hier, j'ai pensé qu'il vaudrait la peine de partager un peu plus de détails sur ce qui s'est passé et pourquoi – et surtout, comment nous en apprenons. Cette panne a été déclenchée par le système qui gère la capacité de notre réseau dorsal mondial. L'épine dorsale est le réseau que Facebook a construit pour connecter toutes nos installations informatiques entre elles, qui se compose de dizaines de milliers de kilomètres de câbles à fibres optiques traversant le monde et reliant tous nos centres de données. Ces centres de données se présentent sous différentes formes.
Certains sont des bâtiments massifs qui abritent des millions de machines qui stockent des données et exécutent les lourdes charges de calcul qui maintiennent nos plates-formes en marche, et d'autres sont des installations plus petites qui connectent notre réseau fédérateur à l'Internet plus large et aux personnes utilisant nos plates-formes.
Lorsque vous ouvrez l'une de nos applications et chargez votre flux ou vos messages, la demande de données de l'application se déplace de votre appareil vers l'installation la plus proche, qui communique ensuite directement via notre réseau fédérateur vers un centre de données plus important. C'est là que les informations nécessaires à votre application sont récupérées et traitées, puis renvoyées sur le réseau vers votre téléphone. 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.
Et dans le travail quotidien intensif de maintenance de cette infrastructure, nos ingénieurs doivent souvent prendre en charge une partie de la dorsale hors ligne pour la maintenance, par exemple en réparant une ligne de fibre, en ajoutant plus de capacité ou en mettant à jour le logiciel sur le routeur lui-même. C'était la source de la panne d'hier,le 4 octobre 2021.
Au cours de l'un de ces travaux de maintenance de routine, une commande a été émise avec l'intention d'évaluer la disponibilité de la capacité du réseau fédérateur mondial, ce qui a involontairement interrompu toutes les connexions de notre réseau fédérateur, déconnectant efficacement les centres de données Facebook dans le monde. Nos systèmes sont conçus pour auditer des commandes comme celles-ci afin d'éviter de telles erreurs, mais un bogue dans cet outil d'audit l'a empêché d'arrêter correctement la commande.
*********************************************************************************
Le protocole internet Memcached mit en doute par une attaque DDOS sur le système Azure de Microsoft en 2020 et 2021 récemment ou d'une cyberattaques comme avec SolarWinds, est un système de mise en cache d'objets distribué, à haute performance et à code source ouvert. Il est couramment utilisé par des réseaux sociaux comme Facebook et son créateur LiveJournal comme un stockage clé-valeur en mémoire, pour de petits morceaux de données arbitraires. Dans ce cas, il est très utile. Lorsqu'il est utilisé de manière abusive, Cloudflare, l'entreprise spécialisée dans la sécurité et les performances du web, a découvert que 15 octets de requête peuvent provoquer 750 Ko de trafic d'attaque, soit une amplification de 51 200 fois ! Facebook utilise memcached car il offre un accès à faible latence à un pool de stockage partagé à faible coût. Ces qualités de memcached permettent à Facebook de créer des fonctionnalités gourmandes en données qui seraient autrement peu pratiques.
Explications:
cache-1: Cache d'écriture : pour les demandes d'écriture, le serveur Web envoie des instructions SQL à la base de données, puis envoie une demande de suppression à Memcache qui invalide toutes les données obsolètes. La suppression est choisie plutôt que la mise à jour car l'opération de suppression est idempotente. Si la mise à jour était plutôt choisie, le cache pourrait avoir des données périmées en raison de sa non-idempotence s'il y avait des rafales d'écritures pour une seule donnée et les mises à jour associées à ces écritures seraient réorganisées.
Facebook a de grands clusters informatiques et a probablement de nombreux serveurs memcached défaillants chaque jour parce que les ordinateurs se brisent de manière étrange. Pour éviter que ces échecs ne se multiplient, Facebook a construit un système appelé Gutter. Gutter entre en jeu si un client Memcache n'obtient pas de réponse pour une clé. Dans ce cas, les données sont extraites de la base de données et placées sur le serveur Gutter, détournant essentiellement cette clé du cluster principal. Cette approche est explicitement choisie par rapport à l'alternative consistant à redistribuer les clés d'une machine défaillante sur les machines saines restantes (ce qui, selon le document, est une alternative plus dangereuse qui pourrait surcharger les serveurs sains).Note:Ce document contient une quantité incroyable de détails sur la façon dont Facebook a fait évoluer son infrastructure Memcache, bien que le document ait été publié en 2013 et que 8 ans, c'est long. Je serais prêt à parier que leur infrastructure a considérablement changé depuis la publication initiale du document.
Il y a aussi les problêmes de mise a jour du logiciel memcached! Selon Cloudflare: Afin de vaincre de telles attaques à l'avenir, nous devons corriger les protocoles vulnérables ainsi que l'usurpation d'adresse IP. Tant que l'usurpation d'adresse IP est autorisée sur Internet, nous aurons des problèmes.
Hacker,mais ça été écarté rapidement par facebook: Un memcache hacking tool depuis 2010,tout comme des attaques DDOS du port UDP 11211, a ne pas négliger.
Tandis que la lanceuse d'alerte: Frances Haugen, ancienne employée de Facebook,comme d'autres personnes disent que Facebook a choisi l'économie(serveurs désuets,pas a jour ou difficilement mit a jour ,....memcached(écrit en Perl) .....) par rapport a la sécurité.
*********************************************************************************
Ce changement a entraîné une déconnexion complète de nos connexions de serveurs entre nos 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 nos plus petites installations consiste à répondre aux requêtes DNS. Le DNS est le carnet d'adresses d'Internet, permettant aux simples noms Web que nous tapons dans les navigateurs d'être traduits en adresses IP de serveur spécifiques.
Ces requêtes de traduction sont traitées par nos serveurs de noms faisant autorité qui occupent eux-mêmes des adresses IP bien connues, qui à leur tour sont annoncées au reste d'Internet via un autre protocole appelé le protocole de passerelle frontière (BGP). Pour garantir un fonctionnement fiable, nos serveurs DNS désactivent ces publicités BGP s'ils ne peuvent pas eux-mêmes parler à nos centres de données, car cela indique une connexion réseau malsaine. Lors de la récente panne, l'ensemble du backbone a été retiré du service, ce qui a amené ces emplacements à se déclarer insalubres et à retirer ces publicités 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.
Tout cela s'est passé très vite. Et pendant que nos ingénieurs cherchaient à 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 à nos centres de données par nos moyens habituels car leurs réseaux étaient en panne, et deuxièmement, la perte totale du DNS s'est rompue. bon nombre des outils internes que nous utilisons normalement pour enquêter et résoudre des pannes comme celle-ci. Notre accès réseau principal et hors bande était en panne, nous avons 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 ces installations sont conçues avec des niveaux élevés de sécurité physique et système à l'esprit. 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 lorsque vous y avez physiquement accès. Il a donc fallu plus de temps 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 pourrions confirmer le problème et remettre notre épine dorsale en ligne. Une fois la connectivité de notre réseau fédérateur restaurée dans les régions de nos centres de données, tout a été rétabli. Mais le problème n'était pas résolu : nous savions que le fait de réactiver nos services d'un seul coup pouvait potentiellement provoquer une nouvelle série de plantages en raison d'une augmentation du trafic. Les centres de données individuels signalaient des baisses de consommation d'énergie de l'ordre de dizaines de mégawatts, et l'inversion soudaine d'une telle baisse de consommation d'énergie pourrait mettre en danger tout, des systèmes électriques aux caches.
Heureusement, c'est un événement auquel nous sommes bien préparés grâce aux exercices de « tempête » que nous organisons depuis longtemps maintenant. Dans un exercice de tempête, nous simulons une panne système majeure en prenant un service, un centre de données ou un entière région hors ligne, test de stress toute l'infrastructure et les logiciels impliqués. L'expérience de ces exercices nous a donné la confiance et l'expérience nécessaires pour remettre les choses en ligne et gérer avec soin les charges croissantes. En fin de compte, nos services sont revenus relativement rapidement sans aucune autre panne à l'échelle du système.
Et bien que nous n'ayons jamais eu auparavant de tempête simulant la mise hors ligne de notre épine dorsale mondiale, nous chercherons certainement des moyens de simuler des événements comme celui-ci à l'avenir.
Chaque échec comme celui-ci est une opportunité d'apprendre et de s'améliorer, et il y a beaucoup à apprendre de celui-ci. Après chaque problème, petit ou grand, nous effectuons un processus d'examen approfondi pour comprendre comment nous pouvons rendre nos systèmes plus résilients.
Ce processus est déjà en cours.
Nous avons beaucoup travaillé pour renforcer nos systèmes pour empêcher les accès non autorisés, et il était intéressant de voir comment ce renforcement nous a ralentis alors que nous essayions de nous remettre d'une panne causée non pas par une activité malveillante, mais par une erreur de notre part. Je pense qu'un compromis comme celui-ci en vaut la peine - une sécurité quotidienne considérablement accrue par rapport à une récupération plus lente après un événement, espérons-le rare, comme celui-ci.
À partir de maintenant, notre travail consiste à renforcer nos tests, nos exercices et notre résilience globale pour nous assurer que des événements comme celui-ci se produisent aussi rarement que possible.
