[Incident majeur] Coupure du vendredi 20 au dimanche 22 septembre

Forum pour signaler un incident ou plus largement s'informer sur l'infrastructure et les services informatiques du lab
zenos
Electrolab::Staff
Messages : 581
Enregistré le : 24 avr. 2016, 17:05

[Incident majeur] Coupure du vendredi 20 au dimanche 22 septembre

Messagepar zenos » 22 sept. 2019, 18:13

Comme vous l'aurez peu-être remarqué les services informatique de l'Electrolab sont tombés pendant 50h

Le module en aval des alimentations redondées sur une des baies de disque du serveur de fichier principal est parti en défaut, emportant avec lui 4 disques et la carte SAS de ce serveur.

Vendredi :
9h15 : début de la panne

15h : Début de l'intervention, les courses pour les travaux du lendemain devant impérativement être faites le vendredi. Constat : le serveur de fichier est crashé et une des baie de disque est éteinte.

16h : La source du problème sur la baie de disque est identifiée : le module en sortie des alimentations redondées surchauffe et se met en sécurité et ce même à vide ce qui tend à indiquer que ce n'est pas le fond de panier de la baie de disque qui est en défaut.

16h30 : le module fautif est remplacé, la baie de disque démarre correctement. 3 disques sont affichés en erreur.

Un petit aparté sur la topologie du filer :
Le volume principale est composé d'un pool zfs de 5 zvol de 10 disques en raidz2 + un cache de lecture SSD en PCIe . Les disques sont des 600Go SAS 10k rpm. Il est complémenté par un volume plus petit sur SSD.

Petit décodage pour ceux qui ne partent pas zfs couramment : vous prenez 10 disques et vous les agrégez ensemble de manière logicielle pour qu'ils ne forment qu'une entité logique, dans le cas du raidz2 cette entité logique tolère la perte de 2 disques au prix de la perte d'un volume équivalent à deux disques et d'un calcul de double parité coûteux en CPU. Vous obtenez un volume qui présente un volume exploitable de 8x600Go avec un débit en lecture très élevé, un peu moins élevé en écriture à cause du calcul de double parité et qui qui permet d'un nombre d'opérations d'entrées / sorties par seconde (IOPS) équivalent à un seul disque. Vous prenez ensuite 5 de ces entités logique pour en former une plus grosse qui aura le volume et les performances cumulées des 5.

Pour calculer la quintuple double parité le serveur est équipé de 2 X5650 (xeon génération i7 à 6 core physique / 12 vcore) et 96Go de ram pour le cache et la table de déduplication. Si on amène cette machine à ses performances maximales : 2.2Go/s en lecture + 1.5Go/s en écriture avec 1500 IOPS on est autour de 90-95% de charge CPU. Performance honorables pour une machine montée avec du matériel de récup et dans tous les cas pas besoin d'aller au delà : on est limité par le réseau avec 2*10Gbps ("limité" ...)

Le serveur de fichier incriminé et ses 2 baies de disques.
20190922_161153 (Medium).jpg
20190922_161153 (Medium).jpg (257.2 Kio) Vu 204 fois


17h30 : Le constat est amer : la carte SAS de la machine semble morte (à 1400€ la carte en occasion ....) Heureusement on en a une de rechange, on ne se serait pas permis de mettre en prod un système avec un élément aussi central qu'on ne saurait remplacer.
18h : départ pour la cité des sciences pour opérer le radiotéléscope

Samedi :
01h : Retour de la cité des sciences, le temps a permis à d'autres personnes de co-cogiter sur des procédures de test

02h : On a une procédure, retour aux tests

02h30 : C'est officiel, la carte SAS est morte, un 4eme disque est en erreur, les autres disques semblent ok.

03:00 : La carte SAS est remplacée, on relance le serveur de fichier. Le pool ne monte pas seul, on tente l'import, un message nous prévient que les données ont l'air en vrac et nous recommande d'importer le pool dans son dernier état stable et de perdre au plus 5 secondes de données ou de tenter la récupération. L'abandon des 5 secondes de données permet un import instantané mais au risque de pertes lourdes (le pool accueille des disques de machine virtuelle, le risque est de corrompre le file system de la vm et de la perdre), la tentative de récupération des données prendra un temps ... inconnu entre quelques heures et quelques jours sans garantie de succès. Sans connaitre la proportion de données corrompues (il y a 13To de données sur ce volume) décision est prise de tenter la récupération.
L'import se fait et là on découvre l'état du pool : sur les 4 disques HS deux sont dans le pool de disques de rechange et n'impactent donc pas. Les deux autres sont dans le même raidz2... on est donc à un rien de perdre l'intégralité du pool. Il reste un disque en état dans le pool de disques de rechange, il est automatiquement réquisitionné et la reconstruction du raidz2 commence. Celle ci va bloquer le début de l'analyse des données pour récupération mais d'une part l'opération a été lancée automatiquement et donc avant qu'on ne puisse intervenir, d'autre part il est critique de revenir à un état avec une tolérance de panne plus élevée.

3h15 : Panne d'une des 2 alimentation sur le serveur de fichier. Décision est prise d'attendre la fin du rebuild pour la remplacer. Un secouage accidentel du câble de la seule alim opérationnelle sur la machine pourrait faire crasher la machine en plein rebuild avec tous les risques associés.

11h45 : Fin du rebuild. Remplacement de l'alimentation, début de la récupération des données

20h30 : Fin de la récupération, ce fut rapide :) 400Ko ont été récupérés avec succès, aucun échec de récupération.

21h : le coeur de l'infrastructure est de nouveau opérationnel, les services encore down sont le gitlab et le proxy frontal web. On récupère enfin le contrôle de la domotique au lab. Pendant 30h on aura allumé et éteint les lumières en alimentant manuellement les relais dans les armoires.

21h30 : Remplacement des disques de rechange HS, début du rebuild du second disque dans le zvol dégradé.

5h30 : Fin du rebuild, retour du pool et du serveur de fichier dans un état de tolérance de panne nominal.

Dimanche :
6h : le frontal web est de nouveau opérationnel

13h30 : gitlab est de nouveau opérationnel,

Jusqu'ici 6 personnes seront intervenues sur ce cas. Comme toujours dans ce genre de situation : prendre son temps, peser chaque action, vérifier chaque commande, etc.

Et ce n'est pas fini : le module électrique défectueux va être analysé.

Les coupables :
20190922_161248 (Medium).jpg
20190922_161248 (Medium).jpg (264.29 Kio) Vu 204 fois
Prophy
Electrolab::Membre
Messages : 7
Enregistré le : 20 janv. 2018, 16:57

Re: [Incident majeur] Coupure du vendredi 20 au dimanche 22 septembre

Messagepar Prophy » 23 sept. 2019, 19:34

Bonsoir à tous,
Je reste plus que jamais admiratif à la fois de votre savoir à tous, de votre persévérance et votre intelligence de travail mise à profit pour le bien commun.
Et de votre efficacité.
Respect.

Retourner vers « Infrastructure et services informatiques »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité