Grave problème RAID que le système panique
Système: Dual CPU Xeon E5-2630, 32 Go de RAM, le disque principal est un système d'exploitation SSD Crucial SATA-III de 512 Go: Xubuntu 14.04.1
J'ai un sérieux problème avec le RAID sur ce nouveau système et j'espère que certains d'entre vous pourront donner un aperçu. Actuellement, le disque SSD principal avec le système de fichiers racine n'est pas mis en miroir, bien que je prévoie de le mettre en miroir sur un deuxième disque SSD identique à l'avenir. J'essaie de configurer un RAID sur un ensemble de disques durs secondaire et je ne souhaite pas mettre à niveau l'ensemble de SSD principal jusqu'à ce que ce problème soit résolu.
J'ai une paire de disques SATA-III Seagate ST4000DM0004TB Baracuda 4 To dans ce système qui ont été formatés de manière identique avec une seule grande partition ext4 GPT. J'ai essayé de créer un miroir RAID 1 utile sur ces disques, qui est ensuite monté sur/x. À un moment donné, quelque chose qui semblait stable et a duré quelques semaines jusqu'à ce que j'essaie de modifier le tableau, aussitôt échoué. Chaque fois que le miroir échoue, il panique apparemment le système et le système de fichiers racine sur le disque SSD est remonté en lecture seule conformément au paramètre défini dans/etc/fstab (errors = remount-ro). Bien sûr, le système est maintenant inutile et nécessite une réinitialisation matérielle. Le système redémarre mais le miroir est maintenant totalement corrompu et doit généralement être détruit et reconstruit. J'ai exécuté des diagnostics de matériel et je ne vois aucun problème. Il n'y a aucune indication sur ce qui ne va pas dans les fichiers journaux (dmesg, kern.log, syslog). Voici quelques détails:
Je crée le tableau comme suit:
# mdadm --create /dev/md2 --verbose --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdc1 appears to contain an ext2fs file system
size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: /dev/sdd1 appears to contain an ext2fs file system
size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: size set to 3906885440K
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
Je vérifie la progression de la construction du RAID:
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[1] sdc1[0]
3906885440 blocks super 1.2 [2/2] [UU]
[>....................] resync = 0.4% (17314560/3906885440) finish=415.6min speed=155968K/sec
unused devices: <none>
Je continue à surveiller périodiquement l'opération de resynchronisation à l'aide de la commande ci-dessus et elle avance sans problème. Cependant, à un moment donné (la resynchronisation a été synchronisée entre 4% et 60%), le système panique et la racine est remontée en mode RO. Lorsque le système est redémarré, je trouve généralement les éléments suivants:
# l /dev/md*
/dev/md127 /dev/md127p1
/dev/md:
dymaxion:2@ dymaxion:2p1@
Dans le cas où j'ai réussi à obtenir/dev/md2 construit et en cours d'exécution, j'avais les périphériques/dev/md2 et/dev/md2p1 sans rien dans le sous-répertoire/dev/md. Ici, le système paniqué semble essayer de sauver le tableau sous le nom md127. Je ne comprends pas pourquoi, mais c'est arrivé à plusieurs reprises. Peut-être est-ce le résultat d'un algorithme codé dans le logiciel mdadm.
Parfois, le tableau md127 est dégradé à un point tel qu'il ne peut pas être monté au démarrage (il existe une entrée pour le tableau dans/etc/fstab) et à d'autres moments, il est monté et tenté de resynchroniser. Cependant, il panique souvent le système au cours de cette opération, ce qui entraîne une série continue de redémarrages.
Je détruis ensuite le tableau et tente de le recréer. Ce sont les commandes que j'utilise pour le détruire.
# mdadm --stop /dev/md127
mdadm: stopped /dev/md127
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
appareils non utilisés:
# mdadm -QD /dev/md127
mdadm: cannot open /dev/md127: No such file or directory
# mdadm --zero-superblock /dev/sdc1
# mdadm --zero-superblock /dev/sdd1
J'ai essayé de construire la matrice sur un système silencieux sans aucun processus de bureau exécutant autre chose que quelques fenêtres de terminal. J'ai lancé la suite de tests de matériel checkbox-gui et tout se passe bien. J'ai essayé de débrancher tous les autres disques SATA, ports USB, lecteur de carte, disque optique, etc., puis d'exécuter la construction et elle échoue toujours.
Quelqu'un peut-il identifier une raison expliquant l'échec du réseau ou suggérer un moyen de mieux déterminer ce qui se passe?
Voici quelques informations supplémentaires sur mes efforts.
Ce que je fais depuis 10 ans sur mon serveur Sun (Solaris 10), c’est d’attacher un troisième disque à la matrice, de lui permettre de se synchroniser, de le détacher de la matrice, puis de le retirer du site pour la reprise après sinistre. Cela fonctionne très bien et c'est ce que j'avais prévu de faire sur ce système Ubuntu.
En utilisant les procédures ci-dessus, j’ai réussi une fois à obtenir/dev/md2 correctement construit avec les deux disques internes. Le système fonctionnant sans problème pendant quelques semaines, j'étais donc prêt à connecter le troisième disque à l'aide d'une baie remplaçable à chaud. J'ai redémarré avec le troisième disque de la baie remplaçable à chaud. En raison des réaffectations de périphériques arbitraires, le nouveau disque est apparu sous le nom/dev/sda et le miroir utilisait/dev/sdd et/dev/sde.
# mdadm -QD /dev/md2p1 (or: # mdadm -QD /dev/md2)
/dev/md2:
Version : 1.2
Creation Time : Tue Sep 9 17:50:52 2014
Raid Level : raid1
Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Fri Sep 19 14:02:45 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : dymaxion:2 (local to Host dymaxion)
UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
Events : 129
Number Major Minor RaidDevice State
3 8 65 0 active sync /dev/sde1
2 8 49 1 active sync /dev/sdd1
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[2] sde1[3]
3906885440 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Tout a l'air bien. Ajoutons/dev/sda1 comme réserve à/dev/md2p1:
# mdadm /dev/md2 --add /dev/sda1
# mdadm -QD /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Tue Sep 9 17:50:52 2014
Raid Level : raid1
Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Fri Oct 17 13:36:13 2014
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Name : dymaxion:2 (local to Host dymaxion)
UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
Events : 130
Number Major Minor RaidDevice State
3 8 65 0 active sync /dev/sde1
2 8 49 1 active sync /dev/sdd1
4 8 1 - spare /dev/sda1
OK, attachons le disque de secours au tableau en utilisant l'option de développement:
# mdadm /dev/md2 --grow -n3
# mdadm -QD /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Tue Sep 9 17:50:52 2014
Raid Level : raid1
Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Fri Oct 17 14:43:08 2014
State : clean, degraded, recovering
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Rebuild Status : 0% complete
Name : dymaxion:2 (local to Host dymaxion)
UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
Events : 134
Number Major Minor RaidDevice State
3 8 65 0 active sync /dev/sde1
2 8 49 1 active sync /dev/sdd1
4 8 1 2 spare rebuilding /dev/sda1
Cela semble bon! Autoriser le troisième disque à se synchroniser:
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda1[4] sdd1[2] sde1[3]
3906885440 blocks super 1.2 [3/2] [UU_]
[>....................] recovery = 0.7% (27891328/3906885440) finish=376.2min speed=171823K/sec
unused devices: <none>
Quelque part après que le miroir ait synchronisé plus de 10%, le système a paniqué. Cette fois, lorsque le système a été redémarré, le processus de démarrage n'a pas pu rattacher le miroir à/x et il a été invité à réessayer ou à ignorer le montage. Je l'ai ignoré et lorsque le système a démarré, il n'y avait aucun moyen de réactiver/dev/md2. Finalement, je devais le détruire et recommencer. Je n'ai plus jamais été aussi proche. Si cela avait fonctionné, il était prévu de marquer le troisième disque comme étant en panne, de le supprimer et de ramener la matrice à deux périphériques (ou à deux périphériques et à un disque de secours manquant.)
Voyez-vous quelque chose de mal avec l'une de ces procédures de construction?
Je m'excuse pour le long post. Je voulais essayer de fournir autant d'informations que possible pour essayer d'anticiper les questions.
Toutes les suggestions sont grandement appréciées. Je suis particulièrement préoccupé par ce qui cause la panique du système.
Tout ce qui suit a été ajouté le samedi 15 novembre 2014
Premièrement, laissez-moi clarifier un malentendu apparent. @psusi a écrit:
Puisque vous n'avez pas mentionné la création d'un système de fichiers sur le tableau RAID et son montage après la création du tableau, et que mdadm vous a averti que/dev/sdc1 contient déjà un système de fichiers ext2, je suppose que vous voulez dire que vous avez déjà un système de fichiers/dev/sdc1, et c’est ce qui est remonté en lecture seule.
Le système de fichiers racine se trouve sur son propre lecteur SATA-III SSD (sda1) alors que je tente de construire le miroir md2 à l'aide de deux autres disques de 4 To (sdc et sdd). C’est pendant la synchronisation de ce miroir que quelque chose ne va pas, le système entier panique, et c’est le système de fichiers racine, et non le miroir, qui est remonté en lecture seule, ce qui rend le système d’exploitation non opérationnel et nécessite une réinitialisation matérielle. Lors du redémarrage, le miroir tente apparemment d'être reconstruit, mais il s'appelle désormais généralement/dev/md127.
Oui, j'essayais de créer le miroir à l'aide de deux disques précédemment partitionnés avec une table de partitions GPT, puis formatés avec un système de fichiers ext4 volumineux. D'après tout ce que j'ai lu, cela devrait être acceptable.
[REMARQUE: Lorsque mdadm indique que "/ dev/sdd1 semble contenir un système de fichiers ext2fs", il s’agit d’une erreur d’identification de ext4fs - probablement à cause d’un message d’erreur codé en dur qui n’a jamais été correctement mis à jour. En ce qui concerne les types de partition, GParted ne leur permet pas d'être formatés directement en tant que type fd, mais je pense que mdadm les étiquette comme tels lorsqu'il les assemble dans le tableau.]
D'après les commentaires ci-dessous, voici ce que j'ai essayé:
1: J'ai exécuté un test de surface étendu S.M.A.R.T. Sur les quatre disques de 4 To (2 pour le miroir, 2 pour les futurs disques de rechange). Chaque test a duré plus de 8,5 heures et tous les disques ont été signalés sans erreur. L'exercice individuel de ces disques n'a jamais provoqué de panique du système.
2: En utilisant GParted, j'ai supprimé les partitions ext4 des disques sdc et sdd.
3: Pour m'assurer que les tables de partition GPT d'origine ont été éliminées, j'ai exécuté:
# sgdisk -Z /dev/sdc
# sgdisk -Z /dev/sdd
4: J'ai recréé le tableau en utilisant les deux disques non formatés.
# mdadm --create /dev/md2 --verbose --level=1 --metadata 1.2 --raid-devices=2 /dev/sdc /dev/sdd
mdadm: size set to 3906887360K
mdadm: array /dev/md2 started
5: J'ai commencé à surveiller la synchronisation en utilisant "cat/proc/mdstat" et je l'ai vue progresser.
Après quelques minutes, le système a paniqué comme d'habitude et le système de fichiers racine (sda1) a été remonté RO et a nécessité une réinitialisation matérielle. Au redémarrage, le tableau a été renommé/dev/md127 et, dans ce cas, il se trouve dans un état "resync = PENDING" et ne tente pas automatiquement de se synchroniser. Le but était de créer la table de partition GPT et la partition ext4 sur le miroir une fois la synchronisation terminée. (Je sais que j'aurais probablement pu procéder ainsi pendant la synchronisation, mais j'essaie d'isoler les étapes de ce processus pour voir où se situe le problème.)
Voici quelques nouvelles informations que j'ai trouvées en double dans les fichiers syslog et kern.log. Ces messages ont été enregistrés juste avant l’opération remount-ro.
Nov 15 14:31:15 dymaxion kernel: [58171.002154] ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 15 14:31:15 dymaxion kernel: [58171.002163] ata8.00: failed command: IDENTIFY DEVICE
Nov 15 14:31:15 dymaxion kernel: [58171.002167] ata8.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 16 pio 512 in
Nov 15 14:31:15 dymaxion kernel: [58171.002167] res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 15 14:31:15 dymaxion kernel: [58171.002169] ata8.00: status: { DRDY }
Nov 15 14:31:15 dymaxion kernel: [58171.002175] ata8: hard resetting link
Nov 15 14:31:15 dymaxion kernel: [58171.329795] ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Nov 15 14:31:15 dymaxion kernel: [58171.330336] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.334346] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.339116] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.343149] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.347557] ata8.00: configured for UDMA/133
Nov 15 14:31:15 dymaxion kernel: [58171.347625] ata8: EH complete
Cela semble indiquer une sorte d'erreur SATA, bien que, pour le moment, je ne puisse pas l'interpréter.
Alors, est-ce que cela fournit des indices supplémentaires quant à ce qui peut être faux? J'apprécie vraiment l'aide apportée jusqu'à présent. Cela m'a fait réfléchir dans deux nouvelles directions. J'espère que quelqu'un pourra fournir d'autres idées ou suggestions. Merci.
Tout ce qui suit a été ajouté samedi 20 décembre 2014
Comme dernière entrée dans cette saga, je fournis les informations suivantes dans l’espoir que cela aidera d’autres à l’avenir.
J'ai réussi à contacter le support US ASUS concernant ce problème. J'ai reçu une carte mère WS Z9PE-D8 de remplacement que j'ai installée et configurée. Lorsque j’ai exécuté mes tests RAID, j’ai fini par observer exactement les mêmes résultats que pour la carte mère d’origine. Avec le lecteur de système de fichiers racine connecté au contrôleur Marvel:
Si les disques RAID 1 supplémentaires se trouvaient sur le contrôleur Marvel, toute tentative d'effectuer une opération significative de mdadm (8) sur la baie de disques générerait l'exception du noyau et les erreurs mentionnées ci-dessus, ce qui entraînerait la panique de l'ensemble du système d'exploitation.
Si les disques RAID étaient retirés du contrôleur Marvel, les opérations de mdadm (8) pourraient être effectuées sans problème et le système fonctionner sans problème.
Comme j'avais l'intention de mettre en miroir la partition racine, j'avais hâte de voir ce qui se passerait si le système de fichiers racine était supprimé du contrôleur Marvel et que le RAID y était remis. Malheureusement, je n'ai trouvé aucun moyen de démarrer le système d'exploitation si le système de fichiers racine était déplacé vers le chipset Intel C602 intégré. Ce fut le cas avec les deux cartes mères.
[NOTE: Si quelqu'un a une idée de la raison pour laquelle cela n'a pas pu être fait, j'aimerais en connaître le motif. Par exemple, GRUB2 stocke-t-il des informations particulières spécifiques à l’automate lors de l’installation?]
Par conséquent, j'ai mordu dans la balle et décidé de réinstaller complètement la dernière version du serveur Ubuntu version 14.10 et de refléter le système de fichiers racine dans le cadre du processus d'installation. J'ai déplacé les disques SSD sur la paire de ports SATA-III contrôlés par le contrôleur Intel et effectué une nouvelle installation. Tout a bien fonctionné.
Maintenant, avec un système en cours d'exécution avec une racine en miroir, j'ai connecté les deux disques de 4 To au contrôleur Marvel et j'ai essayé de construire un nouveau module RAID 1. Le tableau a bientôt échoué. Ainsi, nous pouvons conclure de manière concluante que le contrôleur Marvel fait quelque chose d’incompatible avec la gestion RAID logiciel.
J'ai déplacé les disques de 4 To sur les ports SATA-II contrôlés par l'Intel C602 et tout a fonctionné et continue de fonctionner sans accroc. L'ingénierie ASUS étudie le problème alors qu'il me reste une machine sur laquelle quatre des six ports SATA-III d'origine sont inutilisables.
La leçon à tirer est que quiconque envisage d'utiliser un contrôleur Marvel PCIe 9230 sous Linux doit se préoccuper de la compatibilité RAID.
J'espère que cette information est utile. Si quelqu'un d'autre découvre des problèmes similaires avec le contrôleur Marvel et peut éclairer davantage le sujet, veuillez me contacter. Merci. ~
Chercher l'amour dans tous les mauvais endroits ....
Merci psusi et ppetraki pour vos réponses utiles. Chacun de vous m'a donné des informations supplémentaires sur le fonctionnement du RAID sous Linux.
Il s’avère que les disques ou les commandes mdadm que j’utilisais pour créer et manipuler les baies RAID ne présentaient aucun problème. Une fois que j’ai découvert les messages du noyau ata8, j’ai cherché sur Internet en les utilisant comme clé et trouvé d’autres qui rapportaient des messages similaires associés à un contrôleur Marvel SATA. J'ai une carte mère ASUS Z9PE-D8 WS avec un contrôleur Marvel PCIe 9230 intégré, qui gère quatre ports SATA-III qui étaient utilisés pour ces disques. J'ai débranché les lecteurs de ces ports et les ai connectés à d'autres ports SATA de la carte pilotés par un jeu de puces Intel C602, puis redémarrés. À ce stade, j'ai pu construire plusieurs tableaux, les reconfigurer, etc. sans aucun problème!
L'unique disque SSD avec le système de fichiers racine est toujours connecté au contrôleur Marvel et n'a pas posé de problème. Cependant, je n'ai pas l'intention de tenter de mettre en miroir ce disque jusqu'à ce qu'il soit également retiré du contrôleur Marvel.
J'essaie d'obtenir des informations d'ASUS sur ce problème. Je ne le sais pas, cela pourrait indiquer un problème matériel ou du BIOS. Jusqu'ici, le support technique ASUS a été lent à répondre à mes demandes. Je ne suis pas impressionné par leur service.
Si quelqu'un avait des informations supplémentaires sur les problèmes de contrôleur Marvel, j'apprécierais certainement de les entendre.
Donc, je suis de retour dans les affaires pour le moment, quatre ports SATA-III craignant un système fonctionnant correctement. Merci encore pour votre assistance.
Le plus gros problème que je vois est celui-ci
mdadm: /dev/sdd1 appears to contain an ext2fs file system
En outre, ces partitions doivent être marquées comme membres RAID (type fd) , pas de systèmes de fichiers Linux.
Ce qui signifie qu'il existe des superblocs sur lesquels les outils extfs peuvent se verrouiller, comme fsck, et gâcher votre monde. Je vous recommande fortement de nettoyer complètement les lecteurs avant de les ajouter à array en utilisant dd like so.
dd if=/dev/zero of=/dev/bye-bye-entire-sd-device
Assurez-vous de formater le périphérique MD avec votre système de fichiers, et non avec les membres.
Si tout cela fonctionne et que vous constatez toujours une corruption aléatoire, vous avez probablement une mémoire marginale qui écrit des ordures de temps en temps et détruit vos disques.
Pour plus de références: https://raid.wiki.kernel.org/index.php/RAID_setup
Puisque vous n'avez pas mentionné la création d'un système de fichiers sur le tableau RAID et son montage après la création du tableau, et que mdadm vous a averti que/dev/sdc1 contient déjà un système de fichiers ext2, je suppose que vous voulez déjà dire avoir un système de fichiers dans/dev/sdc1, et c’est ce qui est remonté en lecture seule. En effet, la création d’une matrice RAID à partir d’un disque ou d’une partition est généralement une opération destructive. C’est pourquoi mdadm vous a averti. En écrivant les métadonnées de raid sur la partition, vous avez endommagé le système de fichiers existant.
À ce stade, vous devez essayer d’annuler les dommages que vous avez causés si vous souhaitez récupérer les données existantes dans/dev/sdc1. Commencez par démonter l'ancien système de fichiers, puis en supprimant les superblocs raid que vous avez créés, puis fsck l'ancien système de fichiers et espérez qu'il puisse être réparé:
umount /dev/sdc1
mdadm --zero-superblocks /dev/sdc1 /dev/sdd1
e2fsck -fy /dev/sdc1
Pour mettre à niveau un système de fichiers existant vers un raid1, vous devez d’abord créer le tableau de raid en utilisant niquement le nouveau disque, puis copier manuellement tous vos fichiers de l’ancien FS vers le nouveau. un:
mdadm --create --level 1 -n 2 /dev/sdd1 missing
mkfs.ext4 /dev/md0
mkdir /mnt/new
mkdir /mnt/old
mount /dev/md0 /mnt/new
mount /dev/sdc1 /mnt/old
cp -ax /mnt/old/* /mnt/new/
umount /mnt/old
umount /mnt/new
rmdir /mnt/old
rmdir /mnt/new
Editez maintenant votre fichier/etc/fstab pour monter le nouveau volume dans/dev/md0 au lieu de l'ancien dans/dev/sdc1. Enfin, vous pouvez transmettre/dev/sdc1 à md pour tout mettre en miroir dans/dev/sdd1:
mdadm /dev/md0 --add /dev/sdc1
Vous pouvez utiliser blkid pour rechercher l'UUID du nouveau système de fichiers dans le tableau RAID et l'utiliser pour remplacer l'ancien UUID dans/etc/fstab. De plus, toutes ces commandes doivent être exécutées en tant que root. Vous souhaiterez donc commencer par Sudo -s pour devenir root.
Enfin, FYI, vous voudrez peut-être utiliser raid10 au lieu de raid1. Avec la disposition décalée (-p o2 à mdadm) et une taille de bloc assez grande (-c 1024 à 4096), vous pouvez obtenir la redondance de raid1 plus le débit de lecture séquentielle de raid0.