Défaillance d'un disque sur `notix.lebib.org`
Le vendredi 4 novembre 2023, un des 4 disques assignés au stockage des données "froides" a progressivement cessé de fonctionner.
Il y a d'abord eu 632 erreurs de checksum, puis +1K erreurs de lecture, et le disque a alors complètement cessé de fonctionner (toutes les lectures passant en erreur). L'augmentation de charge I/O relative à ça a perturbé les clouds tendresse/bib, ce qui a fini par créer une situation de charge exceptionelle sur le serveur SQL sur core-sql
, mais à part ça il n'y a pas eu de conséquences visibles.
Dans la nuit du samedi au dimanche, le disque a été remplacé par un autre disque (Seagate Barracuda ES 1 To) sans interruption, (en hotplug, autant sur l'hôte physique que sur la VM). A l'heure de ce post, la reconstruction est toujours en cours, mais avance bien.
Tâches:
-
-
(notix) identifier le disque qui a lâché (par smartctl, dmesg et fdisk)
-
-
-
(notix) écrire la config de ce disque dans un petit fichier xml, disons "old.xml" (la balise qui correspond)
-
-
-
(notix) détacher ce disque de la VM : virsh detach-device bibix old.xml
-
-
-
(notix) retirer physiquement le disque, en commençant par la ligne de données
-
-
-
(notix) installer le disque de remplacement, en finissant par la ligne de données
-
-
-
(notix) copier old.xml dans new.xml, et y mettre à jour le chemin du disque qui vient d'être installé
-
-
-
(notix) attacher ce disque à la VM : virsh attach-device bibix new.xml
-
-
-
(bibix) vérifier (avec dmesg) que le disque a bien été attaché à /dev/sdX
-
-
-
(bibix) demander à ZFS de reconstruire le pool : zpool replace bibix /dev/sdX
-
-
-
se procurer un nouveau disque pour remplacer l'ancien (le stock fond...)
-
-
attendre la fin de la reconstruction sur le nouveau disque
J'étais seule là dessus, et j'ai pas eu l'énergie d'enregistrer ma session de travail avec asciinema, donc y'aura pas d'enregistrement pour cette fois. On essaiera de le faire la prochaine fois. Normalement la liste de tâches devrait donner une bonne indication de la séquence d'opérations à réaliser pour un changement de disque en production (faut juste pas se tromper sur le disque qu'on retire, là ça peut être catastrophique).
Annexe : surcharge du serveur SQL causée par la perte du disque
Une perte non-critique d'un disque n'est pas censée surcharger le serveur SQL, qui n'est même pas stockée sur ces disques (le serveur SQL est sur le stockage main/hot, pas sur le cold). Je pense que le concours de circonstances suivant a mené à cette situation :
- perte d'un disque sur
bibix-cold
, augmentation de la latence I/O sur ce pool - les logs NextCloud sont stockés sur le cloud (ce qui est un problème en soi), ce qui a du faire coincer des requêtes NextCloud
- ces requêtes avaient probablement des opérations sur la base de données en cours, qui n'ont jamais été fermées par NextCloud (bug de NextCloud)
- accumulation de requêtes au serveur SQL, coincées par des I/O qui n'allaient jamais finir
- surcharge du serveur SQL, qui avait environ 80 requêtes concurrentes venant de NextCloud
- ce nombre de 80 correspond au nombre maximum de workers php-fpm, c'est pas une coïncidence
Du coup, en conclusion, il semblerait que la défaillance du disque ait fait en sorte que NextCloud se mette à DoS le serveur SQL. Pour rémédier à ça et éviter ce problème dans le futur:
- déplacer le log de NextCloud dans le hot/main, et pas sur le cold (un log n'est pas "cold")
- vérifier les timeouts et watchdogs au niveau de php-fpm
- vérifier les timeouts au niveau du serveur SQL, et plus généralement protéger le serveur SQL de NextCloud (considérer NextCloud comme un client potentiellement hostile...)
- mettre en place des systèmes de détection de ce genre de situations (monitoring???)