Heu... J'aimerai savoir pourquoi 4 SSD flanchent d'un coup ?

Alors… Cet épisode a désormais une suite…

Le 14 décembre 2018, nous avons à nouveau perdu 4 SSD Samsung 850 Pro. Pour rappel, nous avons acheté 10 SSD en mai 2015 (en un seul coup, dans un même magasin, les numéros de série se suivent malgré quelques trous dans les séquences). Nous avons deux serveurs donc nous avons mis 5 SSD par serveur. Dans chaque serveur, 4 SSD sont actifs (RAID 5 logiciel Linux), et 1 SSD est inactif (hot spare).

Début juin 2017, nous avons perdu 4 SSD le même jour dans l'un des serveurs. En décembre 2018, nous avons perdu 4 SSD le même jour dans l'autre serveur. C'est étrange : les SSD ont été mis en production le même jour et sont censées avoir le même nombre d'écritures puisque nous sommes en RAID et que DRBD écrit les mêmes données sur chaque serveur. Sur le serveur tombé en panne en juin 2017, je constate une variation de 10 To entre les SSD membres d'une même grappe RAID et je ne l'explique pas. Dans les détails, l'attribut SMART « Total LBA written » indique respectivement 37 To, 41 To, 43 To et 50 To.

Que s'est-il passé lors de cette panne de décembre 2018 ?

• Un premier SSD a été automatiquement retiré de la grappe par mdadm. Le SSD de réserve (hot-spare) commence a être écrit par mdadm ;
  
  
• Environ deux heures plus tard, un deuxième SSD a été retiré de la grappe alors que la reconstruction de la grappe n'était pas terminée ;
  
  
• Plus tard dans la soirée, nous éteignons la machine ;
  
  
• Le lendemain, nous nous déplaçons au centre de données dans lequel sont hébergés nos serveurs. Nous allumons la machine et nous regardons la phase de démarrage sur l'écran : seulement 3 SSD sont détectés par le contrôleur SATA ;
  
  
• Nous démarrons sur un live USB. Ce live USB ne dispose pas de smartctl ni de mdadm donc nous sommes en mesure de récolter que peu d'éléments, ce qui exclu le nombre de secteurs écrits…
  
  
• Nous lançons un dd if=/dev/sdb of=/dev/null sur l'un des SSD restants. Après 94 Go de lecture, dd affiche « i/o error » et le noyau journalise « mpt2sas reset port » puis « mpt2sas removing unresponding device » ;
  
  
• Nous lançons un dd similaire sur un des SSD survivants. 227 Go sont lus avant que le noyau journalise « critical error ». Il suffit de dd skip= 3 secteurs pour que la lecture reprenne et que tout le contenu (512 Go) soit lu (mais cela signifie que nous avons 3 secteurs endommagés…). On recommence… Toujours aucun problème pour lire le contenu, à l'exception des trois secteurs défectueux ;
  
  
• Nous redémarrons la machine : 2 SSD sont détectés par le contrôleur SATA. Nous redémarrons encore : 1 seul SSD est détecté. Nous éteignons la machine et nous procédons à un démarrage à froid : toujours un seul SSD ;
  
  
• Nous avons fait jouer la garantie 10 ans Samsung et nous avons reçus 4 SSD neufs durant les fêtes de fin d'année.

Ce que l'on peut exposer :

• Il n'y a visiblement pas que le nombre d'écritures qui importe, ce qui nuance un peu plus l'intérêt de superviser ce nombre d'écritures ;
  
  
• Pour qu'un contrôleur SATA ne détecte plus un quelconque support de stockage, cela signifie quand même que le contrôleur interne du support de stockage foire complètement. On avait déjà mis ça en évidence en juin 2017, mais quand même.
  
  
• Le contrôleur SATA et le backplane de notre ancien serveur sont innocentés… Ils n'ont pas envoyés de chocs électriques à nos SSD, ce qui aurait pu expliquer leur mort prématurée.