Que ressentiriez-vous si, un beau jour d'été, le centre de données et vos équipements ressemblaient à ceci ?
Salut tout le monde! Je m'appelle Dmitry Samsonov, je travaille en tant qu'administrateur système de premier plan chez "" La photo montre l'un des quatre centres de données où sont installés les équipements servant notre projet. Derrière ces murs se trouvent environ 4 XNUMX équipements : serveurs, systèmes de stockage de données, équipements réseau, etc. - près des ⅓ de tous nos équipements.
La plupart des serveurs sont Linux. Il existe également plusieurs dizaines de serveurs sous Windows (MS SQL), notre héritage que nous abandonnons systématiquement depuis de nombreuses années.
Ainsi, le 5 juin 2019 à 14h35, les ingénieurs de l'un de nos centres de données ont signalé une alarme incendie.
Antithèse
14h45. Les incidents mineurs liés à la fumée dans les centres de données sont plus courants que vous ne le pensez. Les indicateurs à l'intérieur des halls étaient normaux, notre première réaction a donc été relativement calme : ils ont introduit une interdiction de travailler avec la production, c'est-à-dire de tout changement de configuration, de déploiement de nouvelles versions, etc., à l'exception des travaux liés à la réparation de quelque chose.
Colère
Avez-vous déjà essayé de savoir auprès des pompiers exactement où l'incendie s'est produit sur le toit, ou de monter vous-même sur un toit en feu pour évaluer la situation ? Quel sera le degré de confiance dans les informations reçues par cinq personnes ?
14: 50. Des informations ont été reçues selon lesquelles l'incendie s'approche du système de refroidissement. Mais est-ce que ça viendra ? L'administrateur système en service supprime le trafic externe des façades de ce centre de données.
À l'heure actuelle, les fronts de tous nos services sont dupliqués dans trois centres de données, l'équilibrage est utilisé au niveau DNS, ce qui nous permet de supprimer les adresses d'un centre de données du DNS, protégeant ainsi les utilisateurs des problèmes potentiels d'accès aux services. . Si des problèmes sont déjà survenus dans le centre de données, celui-ci quitte automatiquement la rotation. Vous pouvez lire plus ici:
L'incendie ne nous a encore affecté d'aucune façon : ni les utilisateurs ni les équipements n'ont été endommagés. Est-ce un accident ? La première section du document « Plan d'action contre les accidents » définit la notion d'« Accident », et la section se termine ainsi :
«S’il y a le moindre doute quant à savoir s’il y a un accident ou non, alors c’est un accident !»
14h53. Un coordinateur d'urgence est nommé.
Le coordinateur est la personne qui contrôle la communication entre tous les participants, évalue l'ampleur de l'accident, utilise le plan d'action d'urgence, attire le personnel nécessaire, surveille l'achèvement des réparations et, surtout, délègue toutes les tâches. En d’autres termes, c’est la personne qui gère l’ensemble du processus d’intervention d’urgence.
Trading
15h01. Nous commençons à désactiver les serveurs qui ne sont pas liés à la production.
15h03. Nous désactivons correctement tous les services réservés.
Cela inclut non seulement les fronts (auxquels les utilisateurs n'ont plus accès à ce stade) et leurs services auxiliaires (logique métier, caches, etc.), mais également diverses bases de données avec un facteur de réplication 2 ou plus (, , , etc.).
15: 06. Des informations ont été reçues selon lesquelles un incendie menace l'un des halls du centre de données. Nous n’avons pas d’équipement dans cette salle, mais le fait que le feu puisse se propager du toit aux halls change grandement la donne.
(Il s’est avéré plus tard qu’il n’y avait aucune menace physique pour la salle, puisqu’elle était hermétiquement fermée depuis le toit. La menace concernait uniquement le système de refroidissement de cette salle.)
15h07. Nous autorisons l'exécution de commandes sur les serveurs en mode accéléré sans vérifications supplémentaires ().
15h08. La température dans les halls se situe dans les limites normales.
15: 12. Une augmentation de la température dans les halls a été enregistrée.
15h13. Plus de la moitié des serveurs du data center sont éteints. Nous allons continuer.
15h16. Il a été décidé d'éteindre tous les équipements.
15h21. Nous commençons à couper l'alimentation des serveurs sans état sans arrêter correctement l'application et le système d'exploitation.
15h23. Un groupe de personnes responsables de MS SQL est affecté (ils sont peu nombreux, la dépendance des services à leur égard n'est pas grande, mais la procédure de restauration des fonctionnalités prend plus de temps et est plus compliquée que, par exemple, Cassandra).
Депрессия
15: 25. Des informations ont été reçues concernant des coupures de courant dans quatre salles sur 16 (n° 6, 7, 8, 9). Nos équipements sont situés dans les halls 7 et 8. Il n'y a aucune information sur nos deux salles (n°1 et 3).
Habituellement, lors d'incendies, l'alimentation électrique est immédiatement coupée, mais dans ce cas, grâce au travail coordonné des pompiers et du personnel technique du centre de données, elle n'a pas été coupée partout ni immédiatement, mais si nécessaire.
(On a découvert plus tard que l’électricité n’était pas coupée dans les halls 8 et 9.)
15h28. Nous commençons à déployer des bases de données MS SQL à partir de sauvegardes dans d'autres centres de données.
Combien de temps cela prendra-t-il ? La capacité du réseau est-elle suffisante pour l’ensemble de l’itinéraire ?
15: 37. Un arrêt de certaines parties du réseau a été enregistré.
La direction et le réseau de production sont physiquement isolés les uns des autres. Si le réseau de production est disponible, vous pouvez alors accéder au serveur, arrêter l'application et éteindre le système d'exploitation. S'il n'est pas disponible, vous pouvez vous connecter via IPMI, arrêter l'application et éteindre le système d'exploitation. S’il n’y a aucun réseau, vous ne pouvez rien faire. « Merci, Cap ! », penserez-vous.
« Et en général, il y a beaucoup de troubles », pourriez-vous aussi penser.
Le fait est que les serveurs, même sans incendie, génèrent une énorme quantité de chaleur. Plus précisément, lorsqu'il y a refroidissement, ils génèrent de la chaleur, et lorsqu'il n'y a pas de refroidissement, ils créent un enfer infernal, qui, au mieux, fera fondre une partie de l'équipement et en éteindra une autre, et au pire... provoquera un incendie à l'intérieur du hall, ce qui est presque garanti de tout détruire.
15h39. Nous résolvons les problèmes avec la base de données conf.
La base de données conf est le backend du service du même nom, qui est utilisé par toutes les applications de production pour modifier rapidement les paramètres. Sans cette base, nous ne pouvons pas contrôler le fonctionnement du portail, mais le portail lui-même peut fonctionner.
15h41. Les capteurs de température sur les équipements du réseau central enregistrent des lectures proches du maximum autorisé. Il s'agit d'un boîtier qui occupe un rack entier et assure le fonctionnement de tous les réseaux à l'intérieur du data center.
15h42. Le suivi des problèmes et le wiki ne sont pas disponibles, passez en veille.
Il ne s’agit pas de production, mais en cas d’accident, la disponibilité de toute base de connaissances peut s’avérer critique.
15h50. L'un des systèmes de surveillance s'est éteint.
Il y en a plusieurs et ils sont responsables de différents aspects des services. Certains d'entre eux sont configurés pour fonctionner de manière autonome au sein de chaque centre de données (c'est-à-dire qu'ils surveillent uniquement leur propre centre de données), d'autres sont constitués de composants distribués qui survivent de manière transparente à la perte de n'importe quel centre de données.
Dans ce cas, il ne fonctionne plus , qui fonctionne en mode maître-veille. Passé en veille.
Adoption
15h51. Tous les serveurs, à l'exception de MS SQL, ont été éteints via IPMI sans s'arrêter correctement.
Êtes-vous prêt pour une gestion massive des serveurs via IPMI si nécessaire ?
Le moment même où le sauvetage des équipements du data center s’achève à ce stade. Tout ce qui pouvait être fait a été fait. Certains collègues peuvent se reposer.
16: 13. Des informations ont été reçues selon lesquelles des tuyaux de fréon des climatiseurs ont éclaté sur le toit, ce qui retardera le lancement du centre de données une fois l'incendie éliminé.
16h19. Selon les données reçues du personnel technique du centre de données, l'augmentation de la température dans les halls a cessé.
17h10. La base de données de configuration a été restaurée. Nous pouvons maintenant modifier les paramètres de l'application.
Pourquoi est-ce si important si tout est tolérant aux pannes et fonctionne même sans centre de données ?
Premièrement, tout n’est pas tolérant aux pannes. Il existe divers services secondaires qui n'ont pas encore assez bien survécu à une panne de centre de données, et certaines bases de données sont en mode maître-veille. La possibilité de gérer les paramètres permet de faire tout le nécessaire pour minimiser l'impact des conséquences d'un accident sur les utilisateurs même dans des conditions difficiles.
Deuxièmement, il est devenu évident que le fonctionnement du centre de données ne serait pas entièrement rétabli dans les heures à venir. Il était donc nécessaire de prendre des mesures pour garantir que l'indisponibilité à long terme des répliques n'entraîne pas de problèmes supplémentaires tels que des disques pleins dans les centres de données restants.
17h29. C'est l'heure des pizzas ! Nous employons des personnes, pas des robots.
Réhabilitation
18h02. Dans les halls n°8 (le nôtre), 9, 10 et 11 la température s'est stabilisée. L’un de ceux qui restent hors ligne (n°7) abrite nos équipements, et la température y continue d’augmenter.
18h31. Ils ont donné le feu vert pour démarrer les équipements des halls n°1 et 3, ces halls n'ayant pas été touchés par l'incendie.
Actuellement, des serveurs sont en cours de lancement dans les halls n°1, 3, 8, en commençant par les plus critiques. Le bon fonctionnement de tous les services en cours d'exécution est vérifié. Il y a encore des problèmes avec le hall n°7.
18h44. Le personnel technique du data center a découvert que dans la salle n°7 (où se trouvent uniquement nos équipements) de nombreux serveurs ne sont pas éteints. Selon nos données, 26 serveurs y restent en ligne. Après une seconde vérification, nous trouvons 58 serveurs.
20h18. Les techniciens des centres de données soufflent de l'air dans une pièce non climatisée à travers des conduits mobiles traversant les couloirs.
23h08. Le premier administrateur a été renvoyé chez lui. Quelqu'un a besoin de dormir la nuit pour pouvoir continuer à travailler demain. Ensuite, nous publierons d'autres administrateurs et développeurs.
02h56. Nous avons lancé tout ce qui pouvait l'être. Nous effectuons de nombreuses vérifications de tous les services à l'aide de tests automatiques.
03h02. La climatisation du dernier et 7ème hall a été restaurée.
03h36. Nous avons mis en rotation les fronts du centre de données dans DNS. À partir de ce moment, le trafic des utilisateurs commence à arriver.
Nous renvoyons la majeure partie de l’équipe administrative chez elle. Mais nous laissons quelques personnes derrière nous.
Petite FAQ :
Q : Que s'est-il passé entre 18h31 et 02h56 ?
R : Suite au « Plan d'action en cas de catastrophe », nous lançons tous les services, en commençant par les plus importants. Dans ce cas, le coordinateur du chat délivre le service à un administrateur gratuit, qui vérifie si le système d'exploitation et l'application ont démarré, s'il y a des erreurs et si les indicateurs sont normaux. Une fois le lancement terminé, il signale au chat qu'il est libre et reçoit un nouveau service du coordinateur.
Le processus est encore ralenti par une panne matérielle. Même si l'arrêt du système d'exploitation et l'arrêt des serveurs se sont déroulés correctement, certains serveurs ne reviennent pas en raison d'une panne soudaine des disques, de la mémoire et du châssis. En cas de coupure de courant, le taux de panne augmente.
Q : Pourquoi ne pouvez-vous pas tout exécuter en même temps, puis corriger ce qui se produit lors de la surveillance ?
R : Tout doit se faire progressivement, car il existe des dépendances entre les services. Et tout doit être vérifié immédiatement, sans attendre le contrôle - car il vaut mieux traiter les problèmes tout de suite, sans attendre qu'ils s'aggravent.
7h40. Le dernier administrateur (coordinateur) s'est couché. Le travail de la première journée est terminé.
8h09. Les premiers développeurs, ingénieurs et administrateurs du centre de données (dont le nouveau coordinateur) ont commencé les travaux de restauration.
09h37. Nous avons commencé à surélever le hall n°7 (le dernier).
Dans le même temps, nous continuons à restaurer ce qui n'a pas été réparé dans d'autres salles : remplacement des disques/mémoire/serveurs, réparation de tout ce qui « brûle » dans la surveillance, inversion des rôles dans les schémas maître-veille et d'autres petites choses, dont il y a néanmoins beaucoup.
17h08. Nous autorisons tout travail régulier avec la production.
21h45. Le travail de la deuxième journée est terminé.
09h45. Aujourd'hui, nous sommes vendredi. Il reste encore quelques petits problèmes de surveillance. Le week-end approche, tout le monde veut se détendre. Nous continuons à réparer massivement tout ce que nous pouvons. Les tâches administratives régulières qui auraient pu être reportées ont été reportées. Le coordinateur est nouveau.
15h40. Soudain, la moitié de la pile d’équipements du réseau central d’UN AUTRE centre de données a redémarré. Les fronts ont été retirés de la rotation pour minimiser les risques. Il n'y a aucun effet pour les utilisateurs. Il s'est avéré plus tard qu'il s'agissait d'un châssis défectueux. Le coordinateur travaille à réparer deux accidents à la fois.
17h17. Le fonctionnement du réseau dans un autre centre de données a été rétabli, tout a été vérifié. Le data center est mis en rotation.
18h29. Les travaux du troisième jour et, en général, la restauration après l'accident sont terminés.
Postface
04.04.2013, , "Camarades de classe" —pendant trois jours, le portail était totalement ou partiellement indisponible. Pendant tout ce temps, plus de 100 personnes de différentes villes, de différentes entreprises (merci encore !), à distance et directement dans les centres de données, manuellement et automatiquement, ont réparé des milliers de serveurs.
Nous avons tiré des conclusions. Pour éviter que cela ne se reproduise, nous avons mené et continuons de mener jusqu’à aujourd’hui un travail approfondi.
Quelles sont les principales différences entre l'accident actuel et le 404 ?
- Nous avons un « Plan d'action contre les accidents ». Une fois par trimestre, nous effectuons des exercices - nous mettons en scène une situation d'urgence, qu'un groupe d'administrateurs (tous à tour de rôle) doit éliminer à l'aide du « Plan d'action d'urgence ». Les principaux administrateurs système jouent à tour de rôle le rôle de coordinateur.
- Chaque trimestre, en mode test, nous isolons les centres de données (tous à tour de rôle) via les réseaux LAN et WAN, ce qui nous permet d'identifier rapidement les goulots d'étranglement.
- Moins de disques cassés, car nous avons renforcé les normes : moins d'heures de fonctionnement, des seuils plus stricts pour SMART,
- Nous avons complètement abandonné BerkeleyDB, une base de données ancienne et instable dont la récupération après un redémarrage du serveur nécessitait beaucoup de temps.
- Nous avons réduit le nombre de serveurs équipés de MS SQL et réduit la dépendance vis-à-vis des serveurs restants.
- Nous avons le nôtre , où nous migrons activement tous les services depuis maintenant deux ans. Le cloud simplifie grandement tout le cycle de travail avec l'application et, en cas d'accident, il fournit des outils uniques tels que :
- arrêt correct de toutes les applications en un clic ;
- migration facile des applications à partir de serveurs défaillants ;
- lancement automatique classé (par ordre de priorité des services) de l'ensemble d'un centre de données.
L'accident décrit dans cet article est le plus important depuis le 404ème jour. Bien sûr, tout ne s’est pas bien passé. Par exemple, lors de l'indisponibilité d'un data center endommagé par un incendie dans un autre data center, un disque sur l'un des serveurs est tombé en panne, c'est à dire qu'une seule des trois répliques du cluster Cassandra est restée accessible, c'est pourquoi 4,2% des mobiles les utilisateurs de l'application n'ont pas pu se connecter. Dans le même temps, les utilisateurs déjà connectés ont continué à travailler. Au total, à la suite de l'accident, plus de 30 problèmes ont été identifiés - des bugs banals aux lacunes de l'architecture du service.
Mais la différence la plus importante entre l'accident actuel et le 404ème est que pendant que nous éliminions les conséquences de l'incendie, les utilisateurs continuaient d'envoyer des SMS et de passer des appels vidéo à , joué à des jeux, écouté de la musique, s'offrait des cadeaux, regardait des vidéos, des séries télévisées et des chaînes de télévision , et également diffusé en streaming .
Comment se passent vos accidents ?
Source: habr.com