Informaticien - [RAID-1 Linux] Problème sur un des disques

07/01/2008 @ 10:58:24: ovh: [RAID-1 Linux] Problème sur un des disques

Bonjour,

J'ai un gros problème sur un serveur d'un client... :sad:

(décidément ce client-là ne m'aura apporté que des ennuis :fou:

)

Le serveur : machine installée en Debian AMD64 stable, 2 disques SATA en RAID-1 (mirroring) logiciel (mdadm), une seule partition qui contient système + données sur le RAID (les swap ne sont pas raidés :wink:

).

Le problème : mail reçu cette nuit :

Subject: Fail event on /dev/md0:tuxmail

This is an automatically generated mail message from mdadm
running on tuxmail

A Fail event had been detected on md device /dev/md0.

It could be related to component device /dev/sda1.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid1]
md0 : active raid1 sda1[2](F) sdb1[1]
311524352 blocks [2/1] [_U]

unused devices: <none>

Et de fait ça ne va pas, car si je compare l'output de mdstat par rapport à une autre machine ayant une config identique, mais saine, j'ai :

Personalities : [raid1]
md0 : active raid1 hda1[0] hdb1[1]
159862656 blocks [2/2] [UU]

unused devices: <none>

Après consultation des logs /var/log/messages je découvre l'horreur :

Spoiler:

Jan 3 06:04:05 tuxmail kernel: ata1: EH complete
Jan 3 06:04:05 tuxmail last message repeated 4 times
Jan 3 06:04:05 tuxmail kernel: sd 0:0:0:0: SCSI error: return code = 0x08000002
Jan 3 06:04:05 tuxmail kernel: sda: Current: sense key: Medium Error
Jan 3 06:04:05 tuxmail kernel: Additional sense: Unrecovered read error - auto reallocate failed
Jan 3 06:04:05 tuxmail kernel: end_request: I/O error, dev sda, sector 475830751
Jan 3 06:04:05 tuxmail kernel: ata1: EH complete
Jan 3 06:04:05 tuxmail kernel: SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
Jan 3 06:04:05 tuxmail kernel: sda: Write Protect is off
Jan 3 06:04:05 tuxmail kernel: ata1: EH complete
Jan 3 06:04:05 tuxmail last message repeated 4 times
Jan 3 06:04:05 tuxmail kernel: sd 0:0:0:0: SCSI error: return code = 0x08000002
Jan 3 06:04:05 tuxmail kernel: sda: Current: sense key: Medium Error
Jan 3 06:04:05 tuxmail kernel: Additional sense: Unrecovered read error - auto reallocate failed
Jan 3 06:04:05 tuxmail kernel: end_request: I/O error, dev sda, sector 475830759
Jan 3 06:04:05 tuxmail kernel: ata1: EH complete
Jan 3 06:04:05 tuxmail kernel: SCSI device sda: drive cache: write back
Jan 3 06:04:05 tuxmail kernel: SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
Jan 3 06:04:05 tuxmail kernel: sda: Write Protect is off
Jan 3 06:04:05 tuxmail kernel: SCSI device sda: drive cache: write back
Jan 3 06:04:05 tuxmail kernel: raid1:md0: read error corrected (8 sectors at 475830696 on sda1)
Jan 3 06:25:23 tuxmail syslogd 1.4.1#18: restart.
Jan 4 06:25:26 tuxmail syslogd 1.4.1#18: restart.
Jan 5 06:25:29 tuxmail syslogd 1.4.1#18: restart.
Jan 6 01:06:02 tuxmail kernel: md: syncing RAID array md0
Jan 6 01:06:02 tuxmail kernel: md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
Jan 6 01:06:02 tuxmail kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for reconstruction.
Jan 6 01:06:02 tuxmail kernel: md: using 128k window, over a total of 311524352 blocks.
Jan 6 02:25:04 tuxmail kernel: ata1: EH complete
Jan 6 02:25:04 tuxmail last message repeated 4 times
Jan 6 02:25:04 tuxmail kernel: sd 0:0:0:0: SCSI error: return code = 0x08000002
Jan 6 02:25:04 tuxmail kernel: sda: Current: sense key: Medium Error
Jan 6 02:25:04 tuxmail kernel: Additional sense: Unrecovered read error - auto reallocate failed
Jan 6 02:25:04 tuxmail kernel: end_request: I/O error, dev sda, sector 485673663
Jan 6 02:25:04 tuxmail kernel: ata1: EH complete
Jan 6 02:25:04 tuxmail kernel: SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
Jan 6 02:25:04 tuxmail kernel: sda: Write Protect is off
Jan 6 02:25:04 tuxmail kernel: SCSI device sda: drive cache: write back
Jan 6 02:25:04 tuxmail kernel: ^IOperation continuing on 1 devices
Jan 6 02:25:04 tuxmail kernel: blk: request botched
Jan 6 02:25:04 tuxmail last message repeated 2 times
Jan 6 02:25:04 tuxmail kernel: SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
Jan 6 02:25:04 tuxmail kernel: blk: request botched
Jan 6 02:25:04 tuxmail last message repeated 3 times
Jan 6 02:25:04 tuxmail kernel: md: md0: sync done.
Jan 6 02:25:04 tuxmail kernel: ata1.00: WARNING: zero len r/w req
Jan 6 02:25:04 tuxmail last message repeated 5 times
Jan 6 02:25:04 tuxmail kernel: RAID1 conf printout:
Jan 6 02:25:04 tuxmail kernel: --- wd:1 rd:2
Jan 6 02:25:04 tuxmail kernel: disk 0, wo:1, o:0, dev:sda1
Jan 6 02:25:04 tuxmail kernel: disk 1, wo:0, o:1, dev:sdb1
Jan 6 02:25:04 tuxmail kernel: sda: Write Protect is off
Jan 6 02:25:04 tuxmail kernel: SCSI device sda: drive cache: write back
Jan 6 02:25:04 tuxmail kernel: RAID1 conf printout:
Jan 6 02:25:04 tuxmail kernel: --- wd:1 rd:2
Jan 6 02:25:04 tuxmail kernel: disk 1, wo:0, o:1, dev:sdb1

Comme c'est la première fois que j'ai des problèmes avec du RAID, j'avoue que je stresse un max... :ciler:

Est-ce que le disque sda est mort et que le serveur fonctionne pour le moment uniquement avec sdb ?
Est-ce que l'erreur sur sda est grave et nécessite le remplacement immédiat du disque ?
Comment faire ce remplacement : éteindre la machine, débrancher l'ancien disque, remplacer par un nouveau SATA de taille équivalente (de préférence le même modèle mais bon), redémarrer et linux mdadm fait tout tout seul ou bien il y a une manip à faire, si oui laquelle ? :fouyaya:

Question subsidiaire : comment savoir physiquement quel disque est sda dans la machine ?... :kiki:

On peut considérer que le premier connecteur SATA utilisé sera celui-là ?...

Bref voilà au secouuuuuuuuurs :totoz:

Merci beaucoup de vos conseils avisés :cupra:

07/01/2008 @ 11:01:30: zion: [RAID-1 Linux] Problème sur un des disques

Désolé, jamais utilisé de RAID encore sous nunux, du moins pas qui a tenu le coup plus d'une heure :tinostar:

07/01/2008 @ 11:24:46: ovh: [RAID-1 Linux] Problème sur un des disques

Après analyse plus fine des logs on dirait qu'il a rencontré des clusters défectueux 2 fois, le 3 janvier et le 6 janvier.
Le 3 janvier ça semble corrigé (clusters marqués pour ne plus être utilisés je présume) :

Jan 3 06:04:05 tuxmail kernel: raid1:md0: read error corrected (8 sectors at 475830696 on sda1)

Par contre le 6 janvier il ne met plus ça, mais il était visiblement en reconstruction du RAID et il met quand même que tout s'est bien terminé :

Jan 6 02:25:04 tuxmail kernel: md: md0: sync done.

Mais je vois encore des messages inquiétants après, puis il reste toujours la sortie du mdstat qui ne me paraît pas bon signe... :sad:

Qu'en pensez-vous ? Le sda est proche de la mort ?

Question subsidiaire : est-ce normal qu'il fasse une reconstruction comme ça en pleine nuit ou est-ce dû aux clusters défectueux ? A mon sens le RAID-1 écrit quand même les données simultanément sur les 2 disques non ? Parce que s'il met dans un cache RAM et ne les synchronise sur l'autre disque qu'une fois de temps en temps la nuit bonjour la fiabilité... :ciler:

Bref j'ai peur, au secours, aidez-moi :totoz:

07/01/2008 @ 11:38:25: ovh: [RAID-1 Linux] Problème sur un des disques

Bon d'après ce que j'ai vu sur le net le mdstat est sans appel :
[UU] = OK
[U_] ou [_U] bref un underscore à la place d'un des U veut dire que ce disque-là est mort (ou plus utilisé par le RAID, donc ça revient au même).

Bref ma question principale : comment remplacer un disque sans stress avec mdadm ? Quelle(s) manip(s) faut-il effectuer à part le remplacement physique du disque évidemment ? :cupra:

07/01/2008 @ 12:29:45: philfr: [RAID-1 Linux] Problème sur un des disques

- mdadm -r du disque foireux
- swap du disque foireux
- mdadm -a du disque remplacé

07/01/2008 @ 12:59:53: ovh: [RAID-1 Linux] Problème sur un des disques

Merci phil :dawaaa:

C'est tout simple donc :dawa:

Pas besoin de recréer des partitions avec un livecd ou quoique ce soit, super :smile:

Par contre, concernant le boot (grub), étant donné que c'est le disque système ça va bien se passer ?...
Voici mon menu.lst :

Spoiler:

# menu.lst - See: grub(8), info grub, update-grub(8)
# grub-install(8), grub-floppy(8),
# grub-md5-crypt, /usr/share/doc/grub
# and /usr/share/doc/grub-doc/.

## default num
# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not change this entry to 'saved' or your
# array will desync and will not let you boot your system.
default 0

## timeout sec
# Set a timeout, in SEC seconds, before automatically booting the default entry
# (normally the first entry defined).
timeout 3

# Pretty colours
color cyan/blue white/blue

## password ['--md5'] passwd
# If used in the first section of a menu file, disable all interactive editing
# control (menu entry editor and command-line) and entries protected by the
# command 'lock'
# e.g. password topsecret
# password --md5 $1$gLhU0/$aW78kHK1QfV3P2b2znUoe/
# password topsecret

#
# examples
#
# title Windows 95/98/NT/2000
# root (hd0,0)
# makeactive
# chainloader +1
#
# title Linux
# root (hd0,1)
# kernel /vmlinuz root=/dev/hda2 ro
#

#
# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=/dev/md0 ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,0)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
## alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
## lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=

## should update-grub lock old automagic boot options
## e.g. lockold=false
## lockold=true
# lockold=false

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
## altoptions=(single-user) single
# altoptions=(single-user mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
## howmany=7
# howmany=all

## should update-grub create memtest86 boot option
## e.g. memtest86=true
## memtest86=false
# memtest86=true

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

## ## End Default Options ##

title Debian GNU/Linux, kernel 2.6.18-4-amd64
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-4-amd64 root=/dev/md0 ro vga=791
initrd /boot/initrd.img-2.6.18-4-amd64
savedefault

title Debian GNU/Linux, kernel 2.6.18-4-amd64 (single-user mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-4-amd64 root=/dev/md0 ro single
initrd /boot/initrd.img-2.6.18-4-amd64
#savedefault

title Debian GNU/Linux, kernel memtest86+
root (hd0,0)
kernel /boot/memtest86+.bin

### END DEBIAN AUTOMAGIC KERNELS LIST

C'est le truc fait par l'installateur debian (j'ai juste rajouté le vga=791 sinon la console est illisible et c'est un serveur donc pas de X) et le RAID avait été fait à l'install aussi, mais malgré cela on dirait qu'il boote d'office sur le premier disque (hd0,0) ?!!??!! :wam:

Cela ne risque-t-il pas de me poser problème lors du reboot ça ?? Etant donné que c'est justement sda qui est foireux...

Merci :cupra:

07/01/2008 @ 13:12:30: ovh: [RAID-1 Linux] Problème sur un des disques

Citation de: philfr

- mdadm -r du disque foireux
- swap du disque foireux
- mdadm -a du disque remplacé

Tiens dans ce tuto j'ai trouvé autre chose :
- mdadm /dev/md0 -f /dev/sda1 (j'ai adapté la partition à mon cas)
- remplacement du disque
- mdadm /dev/md0 -a /dev/sda1
Que faire :figti:

Par contre dans un autre (http://arnofear.free.fr/linux/template.php?tuto=14&page=1#2) j'ai ceci :

Pour mettre en panne le disque /dev/sdd par exemple :
[root@pc user]# mdadm /dev/md0 --fail /dev/sdd
mdadm: set /dev/sdd faulty in /dev/md0

Pour supprimer un disque en panne :
[root@pc user]# mdadm /dev/md0 --remove /dev/sdd
mdadm: hot removed /dev/sdd

Pour ajouter un disque de spare en RAID 1,4,5 :
[root@pc user]# mdadm /dev/md0 --add /dev/sdh
mdadm: hot added /dev/sdh

Ce qui semble plus se rapprocher de ce que tu m'as dit :smile:

Je suppose aussi que la commande pour le "mettre en faute" n'est pas nécessaire vu qu'il l'est déjà :joce:

Sinon pour grub, dans ce même tuto j'ai trouvé ça :

*invoquer le shell grub :
grub>
* Dans le shell de grub exécuter:

#Ecrire le MBR de /dev/sda
root (hd0,0)
setup (hd0)
#Ecrire le MBR de /dev/sdb
device (hd0) /dev/sdb
root (hd0,0)
setup (hd0)

Qu'en penser ? Nécessaire dans mon cas ou pas ? :figti:

Merciiii

07/01/2008 @ 13:17:45: Jean-Christophe: [RAID-1 Linux] Problème sur un des disques

Les raid Software, c'est mal :oh:

Je sais ca n'aide pas, mais pour l'avenir, ca peut servir à d'autres :smile:

07/01/2008 @ 13:28:43: ovh: [RAID-1 Linux] Problème sur un des disques

Citation de: Jean-Christophe

Les raid Software, c'est mal :oh:

Je sais ca n'aide pas, mais pour l'avenir, ca peut servir à d'autres :smile:

Sous linux tu n'as pas le choix, à moins de mettre des cartes très chères (3Ware et autres). Les pseudo "RAID hardware" intégrés aux cartes mère sont des fakes ! C'est comme les winmodems à l'époque, ça nécessite un pilote proprio dispo la plupart du temps uniquement sous windows (comme par hasard) pour fonctionner. C'est donc une merde sans nom.
Et au niveau perf, ça ne change pas grand chose d'après ce que j'ai lu, un soft-raid linux vaut un raid hardware. Au niveau facilité d'installation, là bien sûr il n'y a pas photo... Le vrai RAID hardware + baie hot-swap et là c'est le pied total :petrusbranle:

07/01/2008 @ 13:31:16: Altar: [RAID-1 Linux] Problème sur un des disques

Les raid hardware, c'est mal :ocube:

07/01/2008 @ 13:32:16: ovh: [RAID-1 Linux] Problème sur un des disques

Citation de: Altar

Les raid hardware, c'est mal :ocube:

Et pourquoi ? :write:

07/01/2008 @ 13:38:15: ovh: [RAID-1 Linux] Problème sur un des disques

Tiens autre question : le système reste-t-il utilisable (nombreuses écritures disques car c'est un serveur mail :oh:

) pendant la reconstruction du RAID ou pas ? Sinon, je devrais passer en fin de journée, voire même un vendredi soir... :kiki:

07/01/2008 @ 13:46:51: Altar: [RAID-1 Linux] Problème sur un des disques

ovh > Parce que quand ton controlleur raid claque et que tu n'arrives pas à retrouver exactement le même (au firmware / driver prêt), tu as 95% de chances de perdre tes données. :itm:

Sans compter tous les soucis hardware que tu peux avoir avec la carte, le backplane, etc...

Ici on a eu le coup où le backplane (Il a mis 1 disque en erreur, commencer à reconstruire le raid, remis ce disque en actif & mis un autre en erreur qu'il a aussi voulu reconstruire... Evidemment les deux disques fonctionnent parfaitement.) a déliré un soir ce qui fait qu'on a perdu 6 To de données.

Edit : et oui quand tu fais une reconstruction de ton raid, tu peux continuer à l'utiliser :dawaaa:

07/01/2008 @ 13:49:08: didix: [RAID-1 Linux] Problème sur un des disques

Si ton controleur raid est mort, soit tu retrouve le même pour le remplacer, soit tu te brosse et tu pleures pour tes données :itm:

07/01/2008 @ 13:56:19: Keeper: [RAID-1 Linux] Problème sur un des disques

d'où l'importance des backups

Sur des machines bien rodées la perte hardware du RAID ne doit pas être un problème qui dure plus longtemps que le temps de restaurer les données depuis le backup

07/01/2008 @ 14:01:34: philfr: [RAID-1 Linux] Problème sur un des disques

+1000 pour Altar et didix...

Le drive foireux est déjà en fail, le mdadm -f c'est pour s'entraîner avant une vraie catastrophe :grin:

La reconstruction peut se faire pendant l'utilisation (tout comme ton système continue à tourner pendant la panne)

07/01/2008 @ 14:06:40: ovh: [RAID-1 Linux] Problème sur un des disques

OK merci beaucoup :smile:

Et merci pour les commentaires sur le raid hardware, je n'avais pas pensé à ça :oops:

Par contre il me reste juste un doute par rapport au grub... A vot' bon coeur :cupra:

07/01/2008 @ 14:28:38: philfr: [RAID-1 Linux] Problème sur un des disques

Si ton disque foireux est le disque de boot, il faut que son remplaçant puisse booter. Mais le problème est plus vaste, car il n'y a pas que le MBR, il y a aussi la partition qui contient l'image linux (et éventuellement le initrd)

Comme tu n'as pas décrit comment est organisée la partition de boot (et que grub par défaut ne boote pas directement sur un md), j'attends plus d'infos...

07/01/2008 @ 14:32:48: ovh: [RAID-1 Linux] Problème sur un des disques

Que te faut-il comme info exactement ? :figti:

Le fstab ?

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/md0 / reiserfs notail 0 1
/dev/sda2 none swap sw 0 0
/dev/sdb2 none swap sw 0 0
/dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

07/01/2008 @ 14:50:30: philfr: [RAID-1 Linux] Problème sur un des disques

Le /boot/grub/menu.lst plutôt...