Que ressentiriez-vous si, un beau jour d'été, un centre de données avec votre équipement ressemblait à ça?
Bonjour à tous! Je m'appelle Dmitry Samsonov, je travaille en tant qu'administrateur système de premier plan chez
Odnoklassniki . La photo montre l'un des quatre centres de données où l'équipement qui sert notre projet est installé. Derrière ces murs, il y a environ 4 000 unités d'équipements: serveurs, système de stockage de données, équipements réseau, etc. - près des ⅓ de tous nos équipements.
La plupart des serveurs sont Linux. Il existe plusieurs dizaines de serveurs Windows (MS SQL) - notre héritage, que nous refusons 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.
Déni
14h45. Les incidents enfumés mineurs dans les centres de données sont plus courants qu'ils ne le semblent. Les indicateurs à l'intérieur des halls étaient normaux, donc notre première réaction a été relativement calme: nous avons introduit une interdiction de travailler avec la production, c'est-à-dire de tout changement de configuration, de déployer de nouvelles versions, etc., à l'exception des travaux liés à la réparation de quelque chose.
La colère
Avez-vous déjà essayé de savoir exactement auprès des pompiers où il y avait un incendie 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 de cinq personnes?
14h50.
Des informations ont été reçues indiquant que l'incendie s'approchait du système de refroidissement . Mais cela viendra-t-il? L'administrateur système en service affiche le trafic externe depuis les 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, un équilibrage au niveau DNS est utilisé, ce qui vous 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, il quitte automatiquement la rotation. Plus de détails peuvent être trouvés ici: Équilibrage de charge et tolérance aux pannes à Odnoklassniki.
L'incendie ne nous a pas encore affecté de quelque façon que ce soit - ni les utilisateurs ni l'équipement n'ont été affectés. Est-ce un accident? La première section du document «Plan d'action contre les accidents» définit le concept d '«accident», et la section se termine comme suit:
« En cas de doute, accident ou pas, c'est un accident! "14:53. Un coordinateur accident est nommé.
Un coordinateur est une personne qui contrôle la communication entre tous les participants, estime l'ampleur de l'accident, utilise le «Plan d'action contre les accidents», 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'élimination de l'accident.
Négociation
15:01. Nous commençons à déconnecter les serveurs qui ne sont pas liés à la production.
15h03. Désactivez correctement tous les services réservés.
Cela inclut non seulement les fronts (auxquels les utilisateurs ne se connectent plus à ce stade) et leurs services auxiliaires (logique métier, caches, etc.), mais également diverses bases de données avec facteur de réplication 2 ou plus (
Cassandra ,
stockage de données binaires ,
stockage à froid ,
NewSQL , etc.).
15h06.
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 ce hall, mais le fait que le feu puisse se propager du toit aux halls change considérablement l'image de ce qui se passe.
(Plus tard, il s'est avéré qu'il n'y avait aucune menace physique pour le hall, car il était hermétiquement isolé du toit. La menace était uniquement pour le système de refroidissement de ce hall.)
15h07. Nous permettons l'exécution de commandes sur des serveurs en mode accéléré sans vérifications supplémentaires (
sans notre calculatrice préférée ).
15h08. La température dans les chambres est dans les limites normales.
15:12.
Une augmentation de la température dans les halls a été enregistrée.15:13. Plus de la moitié des serveurs du centre de données sont hors tension. Nous continuons.
15:16. Il a été décidé d'éteindre tout l'équipement.
15 h 21 Nous commençons à couper l'alimentation des serveurs sans état sans arrêter correctement l'application et les systèmes d'exploitation.
15:23. Un groupe de responsables de MS SQL est isolé (il y en a peu, la dépendance des services à leur égard n'est pas grande, mais la procédure de récupération prend plus de temps et est plus compliquée que, par exemple, Cassandra).
La dépression
15h25.
Des informations ont été reçues sur la coupure du courant dans quatre des 16 chambres (n ° 6, 7, 8, 9). Dans les 7e et 8e salles se trouvent nos équipements. Il n'y a plus d'informations sur nos deux chambres (n ° 1 et 3).
Habituellement, pendant les incendies, l'alimentation 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 a été coupée pas partout et pas tout de suite, mais au besoin.
(Plus tard, il s'est avéré que l'alimentation dans les halls 8 et 9 ne s'était pas coupée.)
15:28. 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 bande passante réseau est-elle suffisante pour l'ensemble de l'itinéraire?
15:37.
Verrouillé certaines parties du réseau.Le réseau de gestion et de production est physiquement isolé l'un de l'autre. Si le réseau de production est disponible, vous pouvez vous rendre sur le serveur, arrêter l'application et désactiver le système d'exploitation. S'il n'est pas disponible, vous pouvez passer par IPMI, arrêter l'application et désactiver le système d'exploitation. S'il n'y a pas de réseau, vous ne pouvez rien faire. "Merci casquette!" Vous penserez.
"Quoi qu'il en soit, il y a beaucoup de confusion", pourrait-on aussi penser.
Le fait est que les serveurs même sans feu génèrent une énorme quantité de chaleur. Plus précisément, quand il y a du refroidissement, ils génèrent de la chaleur, et quand il n'y en a pas, ils créent un enfer infernal, qui au mieux fera fondre une partie de l'équipement et éteindra l'autre, et au pire ... cela provoquera un incendie à l'intérieur du hall, qui détruira presque certainement tout.
15:39. Nous corrigeons 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 portail, mais le portail lui-même peut fonctionner.
15:41. Les capteurs de température sur l'équipement du réseau central enregistrent des lectures proches du maximum autorisé. Il s'agit d'un boîtier qui occupe un rack entier et garantit le fonctionnement de tous les réseaux à l'intérieur du centre de données.
15:42. Le suivi des problèmes et le wiki ne sont pas disponibles, passez en mode veille.
Ce n'est pas de la production, mais en cas d'accident, la disponibilité de toute base de connaissances peut être critique.
15h50. L'un des systèmes de surveillance s'est déconnecté.
Il y en a plusieurs et ils sont responsables de divers aspects du travail des services. Certains d'entre eux sont configurés pour fonctionner de manière autonome à l'intérieur de chaque centre de données (c'est-à-dire qu'ils ne surveillent que leur centre de données), tandis que d'autres sont constitués de composants distribués qui survivent de manière transparente à la perte de tout centre de données.
Dans ce cas, le
système de détection des anomalies dans les indicateurs de logique métier qui fonctionne en mode maître-veille a cessé de fonctionner. Passez en veille.
Acceptation
15:51. Grâce à IPMI, tous les serveurs à l'exception de MS SQL ont été éteints sans un arrêt correct.
Êtes-vous prêt pour la gestion de serveurs de masse via IPMI si nécessaire?
Le moment même où le sauvetage de l'équipement dans le centre de données à ce stade est terminé. Tout ce qui pouvait être fait a été fait. Certains collègues peuvent se détendre.
16:13.
Il y avait des informations selon lesquelles des tubes de fréon des climatiseurs ont éclaté sur le toit - cela retardera le lancement du centre de données après avoir éliminé l'incendie.16:19. Selon les données reçues du personnel technique du centre de données, l'augmentation de la température dans les halls s'est arrêtée.
17:10. Restauré le travail de la base de données conf. Nous pouvons maintenant modifier les paramètres de l'application.
Pourquoi est-il si important que tout soit tolérant aux pannes et fonctionne même sans un seul centre de données?
Premièrement, tout n'est pas tolérant aux pannes. Il existe divers services secondaires qui ne survivent pas assez bien à la panne du centre de données, et il existe des bases en mode maître-veille. La capacité de gérer les paramètres vous permet de faire tout le nécessaire pour minimiser l'impact des conséquences de l'accident sur les utilisateurs même dans des conditions difficiles.
Deuxièmement, il est devenu clair que dans les prochaines heures, le centre de données ne se rétablira pas complètement, il était donc nécessaire de prendre des mesures pour que l'indisponibilité à long terme des répliques n'entraîne pas de problèmes supplémentaires tels que des dépassements de disque dans les centres de données restants.
17:29. Le temps de la pizza! Nous avons des gens qui travaillent, pas des robots.
Réhabilitation
18:02. Dans les chambres n ° 8 (les nôtres), 9, 10 et 11, la température s'est stabilisée. Dans l'un de ceux qui restent déconnectés (n ° 7), notre équipement est situé, et la température y continue d'augmenter.
18:31. Ils ont donné le feu vert pour lancer des équipements dans les halls nos 1 et 3 - l'incendie n'a pas affecté ces halls.
Actuellement, des serveurs sont lancés dans les halls n ° 1, 3, 8, à commencer par les plus critiques. Vérifie le bon fonctionnement de tous les services en cours d'exécution. Il y a encore des problèmes avec la chambre 7.
18:44. Le personnel technique du centre de données a constaté que dans le hall numéro 7 (où se trouvent uniquement nos équipements), de nombreux serveurs ne sont pas éteints. Selon nos données, 26 serveurs y restent. Après une nouvelle vérification, nous trouvons 58 serveurs.
20:18. Le personnel technique du centre de données souffle de l'air dans la pièce sans climatisation par des conduits mobiles posés dans les couloirs.
23:08. Ils ont laissé le premier administrateur rentrer chez lui. Quelqu'un a besoin de dormir la nuit pour continuer à travailler demain. Ensuite, nous publions une autre partie des administrateurs et des développeurs.
02:56. Nous avons lancé tout ce qui pouvait être lancé. Nous effectuons une grande vérification de tous les services avec des autotests.
3 h 02 Air conditionné dans le dernier, 7ème hall restauré.
03:36. Ils ont fait tourner les fronts du centre de données dans le DNS. A partir de ce moment, le trafic des utilisateurs commence à arriver.
Nous dissolvons la plupart de l'équipe des administrateurs à domicile. Mais nous laissons quelques personnes.
Petite FAQ:
Q: Que s'est-il passé de 18 h 31 à 02 h 56?
R: Suite au «Plan d'action contre les accidents», nous lançons tous les services, en commençant par les plus importants. Dans le même temps, le coordinateur du chat fournit un 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 ou si les indicateurs sont normaux. Une fois le lancement terminé, il informe le chat qu'il est libre et reçoit un nouveau service du coordinateur.
Le processus est en outre inhibé par le fer défaillant. Même si l'arrêt du système d'exploitation et l'arrêt des serveurs étaient corrects, certains serveurs ne reviennent pas en raison de disques, de mémoire ou de châssis soudainement défaillants. Avec une perte de puissance, le taux de défaillance augmente.
Q: Pourquoi ne pouvez-vous pas tout démarrer en même temps, puis réparer ce qui sort de la surveillance?
R: Tout doit être fait progressivement, car il existe des dépendances entre les services. Et tout doit être vérifié immédiatement, sans attendre la surveillance - car il vaut mieux traiter les problèmes tout de suite, pas attendre leur aggravation.
7 h 40 Le dernier administrateur (coordinateur) s'est couché. Le travail du premier jour est terminé.
8 h 09 Les premiers développeurs, ingénieurs des centres de données et administrateurs (dont le nouveau coordinateur) ont commencé les travaux de restauration.
09:37. Nous avons commencé à élever le hall numéro 7 (le dernier).
Dans le même temps, nous continuons de restaurer ce que nous n'avons pas fini dans d'autres salles: remplacer les disques / mémoire / serveurs, réparer tout ce qui est en feu dans la surveillance, inverser le changement de rôle dans les circuits maître-veille et d'autres petites choses, qui sont néanmoins beaucoup.
17:08. Autorisez tous les travaux réguliers avec la production.
21:45. Le travail du deuxième jour est terminé.
09h45. Aujourd'hui c'est vendredi. Il y a encore pas mal de problèmes mineurs dans la surveillance. Avant le week-end, tout le monde veut se détendre. Nous continuons à réparer massivement tout ce qui est possible. Les tâches d'administration régulières qui pourraient être reportées sont reportées. Le coordinateur est nouveau.
15h40. Soudainement, la moitié de la pile principale d'équipement réseau dans le centre de données OTHER a redémarré. Suppression des fronts de la rotation pour minimiser les risques. Il n'y a aucun effet pour les utilisateurs. Plus tard, il s'est avéré que c'était un mauvais châssis. Le coordinateur travaille à réparer deux plantages à la fois.
17:17. Le réseau d'un autre centre de données est restauré, tout est vérifié. Le centre de données est en rotation.
18:29. Le travail du troisième jour et, en général, la récupération de l'accident est terminé.
Postface
04/04/2013,
le jour de la 404ème erreur , Odnoklassniki a
survécu à un accident majeur - pendant trois jours, le portail a été totalement ou partiellement indisponible. Tout au long de cette période, plus de 100 personnes de différentes villes, de différentes entreprises (merci beaucoup!) À distance et directement dans les centres de données, ont réparé manuellement et automatiquement des milliers de serveurs.
Nous avons tiré des conclusions. Pour éviter que cela ne se reproduise, nous avons effectué et continuons de mener un travail considérable à ce jour.
Quelles sont les principales différences entre l'accident actuel et le 404?
- Nous avons un «plan d'action d'urgence». Une fois par trimestre, nous menons des exercices - nous jouons sur une urgence, qu'un groupe d'administrateurs (tous tour à tour) doit éliminer en utilisant le «Plan d'action d'urgence». Des administrateurs système de premier plan travaillent à tour de rôle sur le rôle de coordinateur.
- Trimestriellement en mode test, isolez les centres de données (tous à tour de rôle) sur le LAN et le WAN, ce qui vous permet d'identifier les goulots d'étranglement en temps opportun.
- Moins de mauvais disques, car nous avons resserré les normes: moins d'heures de fonctionnement, des seuils plus stricts pour SMART,
- BerkeleyDB complètement abandonné - une ancienne base de données instable qui nécessitait beaucoup de temps pour récupérer après un redémarrage du serveur.
- Réduisez le nombre de serveurs avec MS SQL et réduisez la dépendance vis-à-vis des autres.
- Nous avons notre propre cloud - un cloud , où nous migrons activement tous les services depuis deux ans. Le cloud simplifie considérablement tout le cycle de travail avec l'application et, en cas d'accident, fournit des outils uniques tels que:
- arrêter correctement toutes les applications en un seul clic;
- migration simple des applications à partir de serveurs défaillants;
- classement automatique (par ordre de priorité des services) de lancement d'un datacenter complet.
L'accident décrit dans cet article est devenu le plus important depuis le jour 404. Bien sûr, tout ne s'est pas bien passé. Par exemple, pendant l'indisponibilité du graveur de centre de données dans un autre centre de données, un disque est tombé en panne sur l'un des serveurs, c'est-à-dire qu'une seule des trois répliques du cluster Cassandra était disponible, raison pour laquelle 4,2% des utilisateurs d'applications mobiles n'ont pas pu se connecter . Dans le même temps, les utilisateurs déjà connectés ont continué à travailler. Au total, plus de 30 problèmes ont été identifiés selon les résultats de l'accident - des bogues banaux aux défauts de l'architecture des services.
Mais la principale différence entre l'accident actuel et le 404e est que, même si nous avons éliminé les conséquences de l'incendie, les utilisateurs ont toujours correspondu et passé des appels vidéo à
Tamtam , joué à des jeux, écouté de la musique, se sont fait des cadeaux, regardé des vidéos, des émissions de télévision et des chaînes de télévision dans
OK , et également diffusé sur
OK Live .
Comment se passent vos accidents?