Des problèmes au niveau du matériel sur un serveur dédié!
Salut JGSCN
Heureux de voir que tout finit bien pour toi.
Je n'ai rien dit avant, mais reconstruire un Raid quand le disque de données commence à fatiguer,
c'est toujours très délicat, car le travail est assez intense et peut parfois achever le disque malade...
Quoi qu'il en soit, c'est un rappel que le Raid doit toujours être surveillé.
Ca peut se faire par exemple en surveillant le fichier /proc/mdstat que tu connais déjà.
Un monitoring qui reste silencieux tant qu'il ne voit que des [UU] mais qui hurle/mail sinon
Bonsoir,
Normalement tout est bon là. Voici le résultat de cat /proc/mdstat
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md2 : active raid1 sdb2[1] sda2[0]
20478912 blocks [2/2] [UU]
md3 : active raid1 sdb3[1] sda3[0]
1932506048 blocks [2/2] [UU]
[==>..................] check = 10.5% (204025344/1932506048) finish=443.4min speed=64954K/sec
unused devices:
Cependant, je souhaites savoir un truc concernant le changement du disque principal. En effectuant le changement du SDA, il suffit que je lance par la suite la requête de reconstruction en inversant le SDA et le SDB ou y a-t-il une autre manipulation ?
Pour la première reconstruction j'ai du faire cela:
mdadm /dev/md2 --manage --add /dev/sdb2
mdadm /dev/md3 --manage --add /dev/sdb3
en faisant ceci: mdadm --misc --detail /dev/md2
voilà ce que j'ai comme résultat:
#mdadm --misc --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Thu Jun 27 11:56:15 2013
Raid Level : raid1
Array Size : 20478912 (19.53 GiB 20.97 GB)
Used Dev Size : 20478912 (19.53 GiB 20.97 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent
Update Time : Sun Aug 24 01:54:13 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : e653e761:ec0bfd37:a4d2adc2:26fd5302
Events : 0.12156891
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2
Et en faisant la même commande sur le md3 j'ai ceci:
# mdadm --misc --detail /dev/md3
/dev/md3:
Version : 0.90
Creation Time : Thu Jun 27 11:56:21 2013
Raid Level : raid1
Array Size : 1932506048 (1842.98 GiB 1978.89 GB)
Used Dev Size : 1932506048 (1842.98 GiB 1978.89 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 3
Persistence : Superblock is persistent
Update Time : Sun Aug 24 01:55:10 2014
State : active, checking
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Check Status : 12% complete
UUID : aa33e5a9:b80f6ffb:a4d2adc2:26fd5302
Events : 0.26790565
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
Merci par avance.
Cordialement,
darthmaul0181
23/08/2014, 11h20
La reconstruction semble en cours oui
Je ne sais pas si j'ai bien fait mais je crois que la reconstruction du Raid est en cours là :
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md2 : active raid1 sdb2[1] sda2[0]
20478912 blocks [2/2] [UU]
md3 : active raid1 sdb3[2] sda3[0]
1932506048 blocks [2/1] [U_]
[>....................] recovery = 1.1% (21868736/1932506048) finish=918.7min speed=34659K/sec
unused devices:
J'espère en tout cas que c'est correct ce que je suis entrain de faire...
Merci à vous deux pour vos réponses ! À priori tout fonctionnait sans problème et je crois qu'un hard reboot à fait péter le deuxième disque... chose qui me semble bizarre puisque dès la location du serveur aucune manipulation en relation avec le Raid n'a été faite mis à part quelques manip simple pour sécuriser genre installation de fail2ban, restriction sur les ping, etc.
J'avoue ne pas avoir des compétences avancées en matière d'administration sys. et malheureusement, je suis là dans une situation très délicate avec un seul disque dur surtout que celui ci est défectueux et doit être remplacé.
J'ai tenté moi-même de reconstruire tout ça en suivant le guide d'OVH mais j'arrive à un point où je ne comprends plus ce que je fais du coup j'arrête cela. Au début, la commande sgdisk ne fonctionnait pas (pas reconnue), j'ai du coup installé gdisk pour qu'elle soit prise en compte. Là où je bloque c'est au niveau de la reconstruction du raid.
# mdadm --misc --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Thu Jun 27 11:56:15 2013
Raid Level : raid1
Array Size : 20478912 (19.53 GiB 20.97 GB)
Used Dev Size : 20478912 (19.53 GiB 20.97 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 2
Persistence : Superblock is persistent
Update Time : Thu Aug 21 23:29:01 2014
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
UUID : e653e761:ec0bfd37:a4d2adc2:26fd5302
Events : 0.12156071
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 0 0 1 removed
# mdadm --misc --detail /dev/md3
/dev/md3:
Version : 0.90
Creation Time : Thu Jun 27 11:56:21 2013
Raid Level : raid1
Array Size : 1932506048 (1842.98 GiB 1978.89 GB)
Used Dev Size : 1932506048 (1842.98 GiB 1978.89 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 3
Persistence : Superblock is persistent
Update Time : Thu Aug 21 23:30:18 2014
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
UUID : aa33e5a9:b80f6ffb:a4d2adc2:26fd5302
Events : 0.26735809
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 0 0 1 removed
Donc c'est là où je bloque...
Il me semble que dès l'installation, si le serveur est équipé de deux disques dur, t'as le choix d'un "raid 0" ou "raid 1".
Ce raid est ensuite monté puis "on s'occupe plus" ™ (tout faux bien sur - il faut s'en occuper).
Mais, je suis d'accord avec JGSCN, que dès début de la location de son serveur, ce raid 1 a du fonctionner.
Il faut qu'il tire l'admin de son serveur par l'oreille car ce type ne lui a pas prévenue qu'un de ces disques est entrée dans l'état "non-sync".
(et bien sur, le disque qui casse le premier est le seul disque dans le raid, ça, c'est normal. Murphy le confirme )
C'est à toi de reconstruire le RAID, pas à OVH. OVH change le disque dur défaillant, ce qui se passe après sur la machine c'est à toi de t'en occuper.
Il y a un tuto dans le guide qui explique la procédure à faire pour le RAID soft.
Bonjour,
Je me permets de poster un message ici à la recherche d'une éventuelle aide que je n'obtiens malheureusement pas à travers les tickets.
En effet, j'ai un serveur dédié chez OVH depuis 2013, tout fonctionnait sans problèmes jusqu'à ce que je commence à avoir des down-time au niveau du serveur. En cherchant l'origine du problème, je constate que le disque dur principal du serveur est endommagé, au début je ne m'inquiète pas trop puisque, normalement, y a le deuxième disque monté en raid et qui contient les données.
En contactant le support OVH pour trouver une solution à ce problème avec le remplacement du disque défectueux et le montage du deuxième disque pour qu'il soit le principal afin d'avoir toujours mes données intactes, j'ai été informé que le deuxième disque n'est pas activé en raid d'après ce que j'ai compris et ne contient pas une synchronisation des données du premier disque. Chose que je ne comprends et me parait inadmissible puisque si on paie un serveur dédié avec deux disques montés en raid c'est qu'on cherche la sécurité contre la perte de données... OVH a-t-elle omis de faire le nécessaire pour éviter ce genre de problème et là je sais que l'erreur est humaine et sa résolution est toujours bien appréciée?
Sachant que le matériel d'OVH est garanti à vie selon ce que je vois sur le site, si dans le cas d'une défaillance matériel, une perte de données survient, qui assumerait la responsabilité ? Le client qui fait confiance à OVH et à son matériel ou l'hébergeur ?
Merci par avance et ce problème ne remet pas en question la qualité de service de l'hébergeur ou ses employés.
Cordialement,
