Prélude:
Je suis un code-singe de plus en plus pris en charge par SysAdmin pour ma petite entreprise. Mon code est notre produit et, de plus en plus, nous fournissons la même application que SaaS.
Il y a environ 18 mois, j'ai transféré nos serveurs d'un fournisseur d'hébergement haut de gamme vers un pousseur rackable barebones dans un centre de données de niveau IV. (Littéralement de l’autre côté de la rue.) C’est beaucoup plus nous-mêmes - mise en réseau, stockage et surveillance.
Dans le cadre du déménagement, pour remplacer notre système de stockage attaché direct loué auprès de la société d’hébergement, j’ai construit un NAS à deux nœuds basé sur des châssis SuperMicro, des cartes RAID 3wares, Ubuntu 10.04, deux douzaines de disques SATA, DRBD et. Tout est documenté avec amour dans trois articles de blog: Mise en place et test d'un nouveau NAS 10T SATA RAID10 NATA SATA: parties I , parties II et partie III .
Nous avons également mis en place un système de surveillance Cacit. Récemment, nous avons ajouté de plus en plus de points de données, tels que les valeurs SMART.
Je n'aurais pas pu faire tout cela sans les géniaux boffins de ServerFault . Ce fut une expérience amusante et éducative. Mon patron est heureux (nous avons économisé des tonnes de $$$) , nos clients sont satisfaits (les coûts de stockage sont en baisse) , je suis heureux (plaisir, plaisir, plaisir) .
Jusqu'à hier.
Panne & Récupération:
Quelque temps après le déjeuner, nous avons commencé à recevoir des informations sur les performances médiocres de notre application, un système de gestion de contenu multimédia en continu à la demande. À peu près au même moment, notre système de surveillance Cacti a envoyé une tempête de neige d’emails. L'une des alertes les plus éloquentes était un graphique de iostat en attente.
Les performances se sont tellement dégradées que Pingdom a commencé à envoyer des notifications "serveur en panne". La charge globale était modérée, il n'y avait pas de pointe de trafic.
Après avoir ouvert une session sur les serveurs d'applications, les clients NFS du NAS, j'ai confirmé que presque tout connaissait des temps d'attente IO extrêmement intermittents et extrêmement longs. Et une fois que j’ai sauté sur le nœud NAS principal lui-même, les mêmes retards étaient évidents lorsqu’on essayait de naviguer dans le système de fichiers de la matrice à problèmes.
Il est temps d’échouer, cela s’est bien passé. En 20 minutes, tout a été confirmé comme étant parfaitement opérationnel.
Autopsie:
Après toute défaillance du système, j'effectue un post-mortem pour déterminer la cause de la défaillance. La première chose que j'ai faite a été de rentrer dans la boîte et de commencer à examiner les journaux. C'était hors ligne, complètement. Temps pour un voyage au centre de données. Réinitialisation du matériel, sauvegarde et exécution.
Dans /var/syslog
J'ai trouvé cette entrée à la recherche effrayant:
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1 Short offline Completed: read failure 90% 6576 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2 Short offline Completed: read failure 90% 6087 3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3 Short offline Completed: read failure 10% 5901 656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4 Short offline Completed: read failure 90% 5818 651637856
Nov 15 06:49:45 umbilo smartd[2827]:
Alors je suis allé vérifier les graphiques Cacti pour les disques dans le tableau. Nous voyons ici que, oui, le disque 7 est en train de s’écrouler comme le dit syslog. Mais nous constatons également que les erreurs de lecture SMART du disque 8 fluctuent.
Il n'y a pas de message concernant le disque 8 dans syslog. Plus intéressant, les valeurs fluctuantes du disque 8 sont directement corrélées aux temps d'attente IO élevés! Mon interprétation est la suivante:
- Le disque 8 rencontre un problème matériel étrange qui entraîne des durées de fonctionnement intermittentes longues.
- D'une manière ou d'une autre, cette condition d'erreur sur le disque bloque toute la matrice
Peut-être existe-t-il une description plus précise ou correcte, mais le résultat final est que ce disque a un impact sur les performances de l'ensemble du tableau.
Questions)
- Comment un seul disque dans une baie matérielle SATA RAID-10 peut-il tout arrêter complètement?
- Suis-je naïf de penser que la carte RAID aurait dû gérer cela?
- Comment puis-je empêcher un disque défectueux d'avoir un impact sur l'ensemble de la matrice?
- Est-ce que je manque quelque chose?