Panne de SSD sur mother #119

New Issue

Closed

opened 2023-10-16 15:07:28 +02:00 by neox · 0 comments

neox commented

2023-10-16 15:07:28 +02:00

Owner

Une panne d'un des disques dur de mother s'est produite durant la période du 14 avril au 22 avril 2022.
En voici un historique.

14/04/2022, 17h: premiers signes

Ce jour, @Cpm signale dans le salon XMPP Cominfra que la machine aunt subit un très fort chargement du système, semblant bloquer des accès disques et ralentissant énormément des commandes apt full-upgrade.

16:57:30 up 18 days, 23:27,  2 users,  load average: 460,15, 342,66, 174,68

14/10/2022, 19h10: première interprétation

@neox attribue le chargement de aunt à une DDoS en cours sur la machine dns, qui s'avère tourner sur la machine aunt. Pourtant, @Cpm signale à 19h45 que le chargement continue d'augmenter rendant un git pull de la forge git.a-lec.org très très lent (plus d'une minute).

19:44:37 up 19 days,  1:51,  1 user,  load average: 506,93, 428,03, 231,98

@neox stoppe la DDoS et arrête des dizaines de processus de backup encore en cours (du au chargement élevé durant plusieurs semaines probablement), et le chargement diminue... @neox conclut que la situation est résolue.

En effet, des fallocate tournaient sur / au lieu de /var/backups par erreur (faute de logique dans le script de backup) et @neox pense alors que c'était la cause, non visible avant que la DDoS ne ralentisse le retour d'appel système en erreur (qui normalement se produit quand fallocate atteint les /proc/* car ce sont des fichiers virtuels).

Le chargement redescend à 9.

14/10/2022, 21h00: le mystère...

@neox et @cpm s'apercoivent que le chargement est remonté de plus belle et que la machine git est en vrac. @neox essaie un redémarrage de force de la machine git, et le chargement diminue.

À 21h30, la machine aunt affiche un chargement élevé:

21:33:43 up 19 days,  3:40,  3 users,  load average: 347,86, 402,94, 304,10

A 21h40, c'est une crise, beaucoup de services sur aunt ne répondent plus ou tombent et @neox doit les redémarrer de force.
Cependant, la machine git a subi une corruption dans la bataille (redémarrage sans sync). Une sauvegarde est donc restorée et tout semble aller mieux.

A 00h00 tout semble résolu.

16/04/2022: révélation

@Cpm signale aunt à 200 de charge, dns et xmpp à moitié hs.
@neox s'aperçoit que la thèse de la DDoS ne tient pas: Les machines mother et aunt sont identiques et pourtant une différence de performance est visible via le logiciel atop: aunt n'attend d'I/O que 17% du temps en moyenne alors que pour mother c'est 80%. Il est également remarqué que l'état smart sur tous les disques semble bon, mais on a des ssd et les données smart ne donnent que peu d'informations sur l'usure électronique. @neox pense alors que si on prend en compte l'erreur du fallocate (qui dure depuis plusieurs mois!) on peut considérer une probabilité d'usure prématurée assez élevée.

@croax confirme à @neox que le temps d'écriture sur ses vm est très long de même que les lectures (plus de 5s pour un ls par exemple)

@neox analyse ainsi que mother est très lente à gérer les I/O et que aunt se charge car doit attendre que les écritures faites sur la partition DRBD soit validées du côté de mother. Cette lenteur serait donc liée à un disque en difficulté !

La décision est prise de migrer toutes les machines vers aunt et stopper la synchro DRBD.

Ce qui est observé sur mother au repos, après avoir arrêté DRBD :

DSK |          sdb  | busy     64% | read  371212  | write 1572e4 |  avio 6.29 ms |
DSK |          sda  | busy     14% | read 1673195  | write 1671e4 |  avio 1.20 ms

Lorsque @neox lance un dd simple de /dev/urandom vers un fichier, on obtient alors :

DSK |          sdb  | busy     78% | read 0 | write 1053 |  avio 7.42 ms |
DSK |          sda  | busy     35% | read 9 | write 1087 |  avio 3.16 ms

Or, pour la même opération, sur aunt cela donne :

DSK |          sdb  | busy     28% | read 2 | write 1147 |  avio 2.47 ms |
DSK |          sda  | busy     28% | read 7 | write 1207 |  avio 2.28 ms

@Cpm confirme, complétant l'analyse, que iostat dit la même chose : la colonne %util montre une sévère différence, 13 % vs 63 %. Les différences de rMB/s, r_await et w_await semblent énormes sur mother. De telles différences ne sont pas visibles sur aunt.

17/04/2022: `mdadm` se réveille

@neox constate que mdadm déclare le disque /dev/sdb comme défectueux

Un disque est commandé en accord avec le CA.

22/04/2022: réparation

@neox installe dans mother le nouveau disque, remplaçant ainsi /dev/sdb dans le RAID1 de mdadm et relance la synchro DRBD avec aunt.
Tout se passe comme prévu

Une panne d'un des disques dur de mother s'est produite durant la période du 14 avril au 22 avril 2022. En voici un historique. ## 14/04/2022, 17h: premiers signes Ce jour, @Cpm signale dans le salon XMPP Cominfra que la machine aunt subit un très fort chargement du système, semblant bloquer des accès disques et ralentissant énormément des commandes `apt full-upgrade`. ``` 16:57:30 up 18 days, 23:27, 2 users, load average: 460,15, 342,66, 174,68 ``` ## 14/10/2022, 19h10: première interprétation @neox attribue le chargement de aunt à une DDoS en cours sur la machine dns, qui s'avère tourner sur la machine aunt. Pourtant, @Cpm signale à 19h45 que le chargement continue d'augmenter rendant un `git pull` de la forge git.a-lec.org très très lent (plus d'une minute). ``` 19:44:37 up 19 days, 1:51, 1 user, load average: 506,93, 428,03, 231,98 ``` @neox stoppe la DDoS et arrête des dizaines de processus de backup encore en cours (du au chargement élevé durant plusieurs semaines probablement), et le chargement diminue... @neox conclut que la situation est résolue. En effet, des `fallocate` tournaient sur / au lieu de /var/backups par erreur (faute de logique dans le script de backup) et @neox pense alors que c'était la cause, non visible avant que la DDoS ne ralentisse le retour d'appel système en erreur (qui normalement se produit quand fallocate atteint les /proc/* car ce sont des fichiers virtuels). Le chargement redescend à 9. ## 14/10/2022, 21h00: le mystère... @neox et @cpm s'apercoivent que le chargement est remonté de plus belle et que la machine git est en vrac. @neox essaie un redémarrage de force de la machine git, et le chargement diminue. À 21h30, la machine aunt affiche un chargement élevé: ``` 21:33:43 up 19 days, 3:40, 3 users, load average: 347,86, 402,94, 304,10 ``` A 21h40, c'est une crise, beaucoup de services sur aunt ne répondent plus ou tombent et @neox doit les redémarrer de force. Cependant, la machine git a subi une corruption dans la bataille (redémarrage sans sync). Une sauvegarde est donc restorée et tout semble aller mieux. A 00h00 tout semble résolu. ## 16/04/2022: révélation @Cpm signale aunt à 200 de charge, dns et xmpp à moitié hs. @neox s'aperçoit que la thèse de la DDoS ne tient pas: Les machines mother et aunt sont identiques et pourtant une différence de performance est visible via le logiciel `atop`: aunt n'attend d'I/O que 17% du temps en moyenne alors que pour mother c'est 80%. Il est également remarqué que l'état smart sur tous les disques semble bon, mais on a des ssd et les données smart ne donnent que peu d'informations sur l'usure électronique. @neox pense alors que si on prend en compte l'erreur du fallocate (qui dure depuis plusieurs mois!) on peut considérer une probabilité d'usure prématurée assez élevée. @croax confirme à @neox que le temps d'écriture sur ses vm est très long de même que les lectures (plus de 5s pour un `ls` par exemple) @neox analyse ainsi que mother est très lente à gérer les I/O et que aunt se charge car doit attendre que les écritures faites sur la partition DRBD soit validées du côté de mother. Cette lenteur serait donc liée à *un disque en difficulté* ! La décision est prise de migrer toutes les machines vers aunt et stopper la synchro DRBD. Ce qui est observé sur mother *au repos*, après avoir arrêté DRBD : ``` DSK | sdb | busy 64% | read 371212 | write 1572e4 | avio 6.29 ms | DSK | sda | busy 14% | read 1673195 | write 1671e4 | avio 1.20 ms ``` Lorsque @neox lance un dd simple de /dev/urandom vers un fichier, on obtient alors : ``` DSK | sdb | busy 78% | read 0 | write 1053 | avio 7.42 ms | DSK | sda | busy 35% | read 9 | write 1087 | avio 3.16 ms ``` Or, pour la même opération, sur aunt cela donne : ``` DSK | sdb | busy 28% | read 2 | write 1147 | avio 2.47 ms | DSK | sda | busy 28% | read 7 | write 1207 | avio 2.28 ms ``` @Cpm confirme, complétant l'analyse, que `iostat` dit la même chose : la colonne %util montre une sévère différence, 13 % vs 63 %. Les différences de rMB/s, r_await et w_await semblent énormes sur mother. De telles différences ne sont pas visibles sur aunt. ## 17/04/2022: `mdadm` se réveille @neox constate que `mdadm` déclare le disque /dev/sdb comme défectueux Un disque est commandé en accord avec le CA. ## 22/04/2022: réparation @neox installe dans mother le nouveau disque, remplaçant ainsi /dev/sdb dans le RAID1 de `mdadm` et relance la synchro DRBD avec aunt. Tout se passe comme prévu