Comment un seul disque dans une matrice matérielle SATA RAID-10 peut-il mettre la matrice entière à l'arrêt?
Prélude:
Je suis un singe-code qui assume de plus en plus les tâches SysAdmin pour ma petite entreprise. Mon code est notre produit et nous fournissons de plus en plus la même application que le SaaS.
Il y a environ 18 mois, j'ai déplacé nos serveurs d'un fournisseur centré sur l'hébergement premium vers un poussoir de rack barebones dans un centre de données de niveau IV. (Littéralement de l'autre côté de la rue.) Cela signifie faire beaucoup plus nous-mêmes - des choses comme la mise en réseau, le stockage et la surveillance.
Dans le cadre du grand changement, pour remplacer notre stockage attaché direct loué auprès de la société d'hébergement, j'ai construit un 9 noeuds à deux nœuds NAS basé sur SuperMicro chassises, 3ware RAID cards, Ubuntu 10.04, deux douzaines de SATA disques, DRBD et. Tout cela est documenté avec amour dans trois articles de blog: Création et test d'un nouveau NAS 9 To SATA RAID10 NFSv4: Partie I , Partie 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, comme des valeurs SMART.
Je n'aurais pas pu faire tout cela sans le génialboffinsatServerFault. Ce fut une expérience amusante et éducative. Mon patron est heureux (nous avons économisé des charges de seau de $$$) , nos clients sont heureux (les coûts de stockage sont en baisse) , Je suis heureux (amusant, amusant, amusant) .
Jusqu'à hier.
Panne et récupération:
Quelque temps après le déjeuner, nous avons commencé à obtenir des rapports sur les performances médiocres de notre application, un CMS multimédia en streaming à la demande. À peu près au même moment, notre système de surveillance Cacti a envoyé un blizzard d'e-mails. L'une des alertes les plus révélatrices était un graphique de l'attente iostat.
Les performances sont devenues si dégradées que Pingdom a commencé à envoyer des notifications de "serveur arrêté". 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, clients NFS du NAS, j'ai confirmé que presque tout connaissait des temps d'attente très intermittents et incroyablement longs IO. Et une fois j'ai sauté sur le principal NAS node lui-même, les mêmes retards étaient évidents lors de la tentative de navigation dans le système de fichiers de la baie à problèmes.
Il était temps de basculer, 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 une autopsie pour déterminer la cause de la défaillance. La première chose que j'ai faite a été de remettre ssh dans la boîte et de commencer à examiner les journaux. C'était complètement hors ligne. Temps pour un voyage au centre de données. Réinitialisation matérielle, sauvegarde et exécution.
Dans /var/syslog J'ai trouvé cette entrée effrayante:
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]:
Je suis donc allé vérifier les graphiques Cacti pour les disques dans le tableau. Ici, nous voyons que, oui, le disque 7 glisse, tout comme le dit Syslog. Mais nous voyons également que les erros de lecture du disque 8 SMART) fluctuent.
Il n'y a aucun message sur le disque 8 dans syslog. Plus intéressant est que les valeurs fluctuantes du disque 8 sont directement corrélées aux temps d'attente élevés IO! Mon interprétation est que :
- Le disque 8 connaît une anomalie matérielle étrange qui se traduit par de longs temps de fonctionnement intermittents.
- D'une manière ou d'une autre, cette condition de panne sur le disque verrouille l'ensemble de la baie
Il existe peut-être une description plus précise ou correcte, mais le résultat net a été que l'unique disque a un impact sur les performances de l'ensemble de la baie.
Questions)
- Comment un seul disque dans une matrice matérielle SATA RAID-10 peut-il mettre la matrice entière à l'arrêt?
- Suis-je naïf de penser que la carte RAID aurait dû gérer cela?
- Comment puis-je empêcher un seul disque défectueux d'avoir un impact sur l'ensemble de la baie?
- Suis-je en train de manquer quelque chose?
Je déteste dire "n'utilisez pas SATA" dans des environnements de production critiques, mais j'ai vu cette situation assez souvent. Les disques SATA ne sont généralement pas destinés au cycle de service que vous décrivez, bien que vous ayez spécifié disques spécifiquement conçus pour un fonctionnement 24x7 dans votre configuration. D'après mon expérience, les disques SATA peuvent échouer de manière imprévisible, affectant souvent la totalité de la matrice de stockage, même lorsque vous utilisez RAID 1 + 0, comme vous l'avez fait. Parfois, les disques tombent en panne d'une manière qui peut bloquer tout le bus. Une chose à noter est de savoir si vous utilisez des extensions SAS dans votre configuration. Cela peut faire une différence dans la façon dont les disques restants sont affectés par une panne de disque.
Mais il aurait peut-être été plus judicieux de choisir midline/nearline (7200 RPM) SAS drives versus SATA. Il y a une petite prime de prix par rapport à SATA, mais les disques fonctionner/échouer de façon plus prévisible. La correction des erreurs et la génération de rapports dans l'interface SAS interface/protocole est plus robuste que l'ensemble SATA. Donc, même avec les lecteurs dont la mécanique est la même =, la différence de protocole SAS peut avoir empêché la douleur que vous avez ressentie lors de la panne de votre lecteur.
Comment un seul disque peut-il faire tomber la baie? La réponse est que cela ne devrait pas, mais cela dépend en quelque sorte de la cause de la panne. Si le disque devait mourir d'une manière qui se comportait, il ne devrait pas le retirer. Mais il est possible qu'il échoue dans un "cas de bord" que le contrôleur ne peut pas gérer.
Êtes-vous naïf de penser que cela ne devrait pas se produire? Non je ne pense pas. Une carte RAID matérielle comme celle-ci aurait dû gérer la plupart des problèmes.
Comment l'empêcher? Vous ne pouvez pas anticiper des cas Edge étranges comme celui-ci. Cela fait partie du fait d'être un administrateur système ... mais vous pouvez travailler sur des procédures de récupération pour l'empêcher d'avoir un impact sur votre entreprise. La seule façon d'essayer de résoudre ce problème en ce moment est d'essayer une autre carte matérielle (pas probablement ce que vous voudriez faire) ou de changer vos disques en SAS au lieu de SATA pour voir si SAS est plus robuste. Vous pouvez également contacter votre fournisseur de la carte RAID et lui dire ce qui s'est passé et voir ce qu'ils disent; ils sont, après tout, une entreprise censée se spécialiser dans connaître les tenants et aboutissants de l'électronique de disque dur. Ils peuvent avoir plus de conseils techniques sur le fonctionnement des disques ainsi que leur fiabilité ... si vous pouvez trouver les bonnes personnes à qui parler.
Vous avez manqué quelque chose? Si vous souhaitez vérifier que le disque présente une défaillance du boîtier Edge, retirez-le de la baie. Le tableau sera dégradé mais vous ne devriez pas avoir plus de ralentissements et d'erreurs étranges (à part le statut du tableau dégradé). Vous dites qu'en ce moment, cela semble fonctionner correctement, mais s'il y a des erreurs de lecture sur le disque, vous devez remplacer le lecteur pendant que vous le pouvez. Les disques à haute capacité peuvent parfois présenter des erreurs URE (meilleure raison de ne pas exécuter RAID 5, note latérale) qui n'apparaissent pas tant qu'un autre disque n'est pas tombé en panne. Et si vous rencontrez un comportement Edge-case à partir de ce lecteur, vous ne voulez pas que les données corrompues soient migrées vers les autres lecteurs de la baie.
Je ne suis pas un expert, mais je vais prendre une photo sauvage dans le noir sur la base de mon expérience avec les contrôleurs RAID et les matrices de stockage.
Les disques échouent de différentes manières. Malheureusement, les disques peuvent échouer, ou être défectueux, de manière à ce que leurs performances soient sérieusement affectées mais que le contrôleur RAID ne considère pas comme une défaillance.
Si un disque tombe en panne de manière évidente, tout logiciel de contrôleur RAID devrait être assez bon pour détecter l'absence de réponse du disque, le retirer du pool et déclencher toutes les notifications. Cependant, je suppose que ce qui se passe ici est que le disque subit une défaillance inhabituelle qui, pour une raison quelconque, ne déclenche pas une défaillance du côté du contrôleur. Par conséquent, lorsque le contrôleur effectue un vidage d'écriture ou une lecture à partir du disque affecté, il faut beaucoup de temps pour revenir et, à son tour, suspend l'ensemble IO en fonctionnement et donc la baie. Pour tout raison, cela ne suffit pas pour que le contrôleur RAID fasse "ah, disque défaillant", probablement parce que les données finissent par revenir éventuellement.
Mon conseil serait de remplacer immédiatement le disque défectueux. Après cela, j'examinerais la configuration de votre carte RAID (c'est 3ware, je pensais qu'ils étaient assez bons) et je découvrirais ce qu'elle considère comme un disque défaillant.
P.S. Belle idée d'importer SMART dans les cactus.
Vous avez besoin des fonctionnalités des périphériques de stockage de classe entreprise. Plus précisément, les disques d'entreprise WD RE 4 ont deux fonctionnalités nécessaires pour empêcher ce comportement dans les matrices RAID. La première technologie répertoriée ci-dessous empêche les vibrations harmoniques de rotation de provoquer une usure inutile des composants mécaniques du disque dur. La deuxième technologie est à l'origine de votre problème, le protocole SATA ne possède pas cette fonctionnalité. Pour obtenir ces fonctionnalités, vous avez besoin de SAS, et si vous insistez sur les disques SATA, vous pouvez acheter SAS sur des cartes d'interposition SATA telles que la LSISS9252.
Technologie RAFF améliorée Une électronique sophistiquée surveille l'entraînement et corrige les vibrations linéaires et rotationnelles en temps réel. Le résultat est une amélioration significative des performances dans les environnements à fortes vibrations par rapport à la génération précédente de disques.
Récupération d'erreurs limitée dans le temps (TLER) spécifique au RAID Empêche les pannes de disque causées par les processus étendus de récupération d'erreurs du disque dur communs aux disques de bureau.
http://en.wikipedia.org/wiki/Error_recovery_control#Overview
Veuillez également voir le lien ci-dessous:
http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers
Voir également: Western Digital TLER Document expliquant le processus de récupération d'erreur en profondeur. Prévention des retombées de récupération d'erreur dans les disques durs Serial ATA WD Caviar RAID Edition:
Juste une supposition: les disques durs sont configurés pour réessayer les erreurs de lecture plutôt que de signaler une erreur. Bien que ce comportement soit souhaitable dans un environnement de bureau, il est contre-productif dans un RAID (où le contrôleur doit réécrire tout secteur qui échoue à la lecture des autres disques, afin que le lecteur puisse le remapper).
ma photo dans le noir:
le lecteur 7 échoue. il a des fenêtres d'échec où il n'est pas disponible.
le lecteur 8 a également quelques erreurs "plus légères"; corrigé par une nouvelle tentative.
RAID10 est généralement "un RAID0 de plusieurs paires RAID1", les lecteurs 7 et 8 sont-ils membres de la même paire?
si c'est le cas, il semble que vous ayez touché le cas "ne devrait pas se produire" de défaillance de deux disques sur la même paire. presque la seule chose qui peut tuer un RAID10. malheureusement, cela peut arriver si tous vos disques proviennent du même lot d'expédition, ils sont donc légèrement plus susceptibles de mourir simultanément.
Je suppose que lors d'une panne du lecteur 7, le contrôleur a redirigé toutes les lectures vers le lecteur 8, donc toute nouvelle tentative d'erreur a provoqué de gros retards qui ont provoqué une avalanche de tâches gelées, ce qui a tué les performances pendant un certain temps.
vous avez de la chance que le lecteur 8 ne semble pas encore mort, vous devriez donc pouvoir réparer sans perte de données.
Je commencerais par changer les deux disques, et n'oubliez pas de vérifier le câblage. une connexion lâche peut provoquer cela, et si elle n'est pas acheminée fermement, elle est plus susceptible de se produire dans les lecteurs adjacents. De plus, certaines cartes multiports ont plusieurs connecteurs à deux ports, si le lecteur 7 et le lecteur 8 sont sur le même, cela pourrait être la source de votre problème.
Les cartes d'interposition SATA sont une autre solution.
J'ai récemment vécu exactement le même sort et j'ai trouvé ce fil. Le ténor général est que le protocole SAS est mieux adapté pour RAID que SATA, car SATA manque de fonctionnalités. pourquoi les mêmes disques physiques sont équipés de contrôleurs SAS, puis vendus en tant que Nearline SAS.
En cherchant plus loin, j'ai trouvé:
http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx
J'étudie la mise à niveau d'un de mes stockages avec un lot de ceux-ci. En ce moment, la différence de prix entre 3 TB SATA vs SAS est de 400% (prix Vanilla, même marque, spécifications et boutique, Allemagne). Je peux évidemment 't dire si cette stratégie fonctionne bien, mais ça vaut le coup d'essayer.
Commentaires très bienvenus :-)
J'ai vu un disque SATA avec une électronique cassée verrouiller solidement l'initialisation du firmware d'un Areca 12, il n'y avait aucun moyen d'accéder au BIOS et encore moins de démarrer la machine à partir de n'importe quel support jusqu'à ce que le disque dur incriminé soit trouvé en tirant les disques dans un fichier binaire mode de recherche.