J'avais une matrice RAID 0 à trois disques et j'ai lancé ceci pour ajouter un quatrième disque:
mdadm --manage /dev/md127 --add /dev/xvdi
Chaque disque est un volume EC2 de 1 To. Il a fallu environ 40 heures pour que le tableau se redessine. Environ 1 heure après, le remodelage s'est arrêté et le volume est devenu inaccessible. J'ai redémarré la machine et le remodelage a continué, puis s'est apparemment terminé avec succès, mais le niveau de la matrice est maintenant signalé comme RAID 4 et la capacité utilisable n'a pas changé.
mdadm --detail /dev/md127
rapporte maintenant ce qui suit:
/dev/md127:
Version : 1.2
Creation Time : Wed Jul 1 22:26:36 2015
Raid Level : raid4
Array Size : 4294965248 (4096.00 GiB 4398.04 GB)
Used Dev Size : 1073741312 (1024.00 GiB 1099.51 GB)
Raid Devices : 5
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Sun Oct 11 07:40:48 2015
State : clean, degraded
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
Name : [removed]
UUID : [removed]
Events : 63530
Number Major Minor RaidDevice State
0 202 160 0 active sync /dev/xvdk
1 202 144 1 active sync /dev/xvdj
2 202 80 2 active sync /dev/xvdf
4 202 128 3 active sync /dev/xvdi
4 0 0 4 removed
Mon objectif ici est d’avoir une matrice RAID 0 de 4 To. Je n'ai pas besoin de redondance puisque je sauvegarde en prenant des instantanés de volume dans AWS. J'utilise Ubuntu Server 14.04.3.
Comment passer en mode RAID 0 sans perdre de données, en tenant compte du fait que l'état est clean, degraded
?
Vous pouvez modifier la configuration actuelle directement en RAID avec mdadm -G -l 0 /dev/md127
. Dans la mesure où un RAID 4 avec seulement 4 membres sur 5 est essentiellement un RAID 0 sans bande de parité, la conversion aura lieu instantanément. S'il y avait un membre de parité, il serait supprimé, mais comme il est déjà répertorié comme "Supprimé", il sera simplement supprimé, les périphériques Raid décrémentés à 4 et l'état devrait être "propre".
Dans la requête mdadm imprimée ci-dessus, vous pouvez voir que la taille du membre est de 1 To et la taille du volume de 4 To. Le volume doit donc être utilisable tel quel, même sans le membre de parité. Vous devrez ensuite agrandir la partition avec parted et effectuer le redimensionnement du système de fichiers comme à l'habitude.
Je sais que c'est vieux, mais ces étapes pourraient être utiles aux gens.
Comment ajouter des disques à RAID-0?
Env:
Configuration initiale:
$ Sudo mdadm --create --verbose /dev/md0 --level=0 --name=DB_RAID2 --raid-devices=3 /dev/xvdh /dev/xvdi /dev/xvdj
$ Sudo mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Sep 5 14:25:10 2017
Raid Level : raid0
Array Size : 31432704 (29.98 GiB 32.19 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Tue Sep 5 14:25:10 2017
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
Name : temp:DB_RAID2 (local to Host temp)
UUID : e8780813:5adbe875:ffb0ab8a:05f1352d
Events : 0
Number Major Minor RaidDevice State
0 202 112 0 active sync /dev/xvdh
1 202 128 1 active sync /dev/xvdi
2 202 144 2 active sync /dev/xvdj
$ Sudo mkfs -t ext4 /dev/md0
$ Sudo mount /dev/md0 /mnt/test
Ajouter un disque à RAID-0 en une étape (ne fonctionne pas):
$ Sudo mdadm --grow /dev/md0 --raid-devices=4 --add /dev/xvdk
mdadm: level of /dev/md0 changed to raid4
mdadm: added /dev/xvdk
mdadm: Failed to initiate reshape!
Probablement, cela échoue à cause de ceci bug .
Étape 1: conversion en RAID 4:
$ Sudo mdadm --grow --level 4 /dev/md0
mdadm: level of /dev/md0 changed to raid4
$ cat /proc/mdstat
Personalities : [raid0] [raid6] [raid5] [raid4]
md0 : active raid4 xvdj[2] xvdi[1] xvdh[0]
31432704 blocks super 1.2 level 4, 512k chunk, algorithm 5 [4/3] [UUU_]
unused devices: <none>
Étape 2: ajoutez un disque:
$ Sudo mdadm --manage /dev/md0 --add /dev/xvdk
mdadm: added /dev/xvdk
Attendez de récupérer:
$ cat /proc/mdstat
Personalities : [raid0] [raid6] [raid5] [raid4]
md0 : active raid4 xvdk[4] xvdj[2] xvdi[1] xvdh[0]
31432704 blocks super 1.2 level 4, 512k chunk, algorithm 5 [4/3] [UUU_]
[=>...................] recovery = 8.5% (893572/10477568) finish=3.5min speed=44678K/sec
$ cat /proc/mdstat
Personalities : [raid0] [raid6] [raid5] [raid4]
md0 : active raid4 xvdk[4] xvdj[2] xvdi[1] xvdh[0]
31432704 blocks super 1.2 level 4, 512k chunk, algorithm 5 [4/4] [UUUU]
unused devices: <none>
Étape 3: conversion en RAID-0:
$ Sudo mdadm --grow --level 0 --raid-devices=4 /dev/md0
$
Attendez que ça se reforme:
$ cat /proc/mdstat
Personalities : [raid0] [raid6] [raid5] [raid4]
md0 : active raid4 xvdk[4] xvdj[2] xvdi[1] xvdh[0]
31432704 blocks super 1.2 level 4, 512k chunk, algorithm 5 [5/4] [UUUU_]
[===>.................] reshape = 16.2% (1702156/10477568) finish=6.1min speed=23912K/sec
$ cat /proc/mdstat
Personalities : [raid0] [raid6] [raid5] [raid4]
md0 : active raid0 xvdk[4] xvdj[2] xvdi[1] xvdh[0]
41910272 blocks super 1.2 512k chunks
Étape 4: redimensionner le système de fichiers:
$ Sudo mdadm -D /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Tue Sep 5 14:25:10 2017
Raid Level : raid0
Array Size : 41910272 (39.97 GiB 42.92 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Tue Sep 5 14:55:46 2017
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Chunk Size : 512K
Name : temp:DB_RAID2 (local to Host temp)
UUID : e8780813:5adbe875:ffb0ab8a:05f1352d
Events : 107
Number Major Minor RaidDevice State
0 202 112 0 active sync /dev/xvdh
1 202 128 1 active sync /dev/xvdi
2 202 144 2 active sync /dev/xvdj
4 202 160 3 active sync /dev/xvdk
$ df -h
/dev/md0 30G 45M 28G 1% /mnt/test
Redimensionnement réel et après redimensionnement:
$ Sudo resize2fs /dev/md0
resize2fs 1.42.9 (28-Dec-2013)
Filesystem at /dev/md0 is mounted on /mnt/test; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 5
The filesystem on /dev/md0 is now 10477568 blocks long.
$ df -h /dev/md0
Filesystem Size Used Avail Use% Mounted on
/dev/md0 40G 48M 38G 1% /mnt/test
Il existe un scénario dans lequel je me retrouve avec un tableau FAILED dégradé. Ça va comme ça:
Dans la dernière étape, le disque de parité est supprimé et il découvre qu'il ne peut pas convertir la matrice en RAID0. Cependant, il aurait pu le savoir d'avance (apparemment, tous les disques sans parité doivent être en ligne). Le résultat est un tableau à l'état propre et dégradé.
mdadm --grow/dev/md/vg_docker --level = 4 mdadm --détail/dev/md/vg_docker
mdadm --management/dev/md/vg_docker --add/dev/sdm mdadm --détail/dev/md/vg_docker
mdadm --management/dev/md/vg_docker - échec/dev/sde mdadm --détail/dev/md/vg_docker
mdadm --manager/dev/md/vg_docker - supprimer/dev/sde mdadm --détail/dev/md/vg_docker
mdadm --grow/dev/md/vg_docker --level = stripe
Donne en sortie: mdadm:/dev/md/vg_docker: impossible de définir le niveau sur raid0
mdadm --detail/dev/md/vg_docker
L'état est maintenant propre, ÉCHEC et toutes les données sont perdues.
Ce serait bien si mdadm pouvait vérifier avant de convertir la matrice en bande RAID0 si l'opération pouvait être effectuée.
Arrière-plan: La segmentation RAID0 est utile pour obtenir plus de performances dans une configuration en nuage. Le stockage sous-jacent est déjà hautement disponible. RAID n'est donc nécessaire que pour améliorer les performances. Certaines des expériences ci-dessus tentaient de remplacer un disque dans une matrice RAID0 par un autre disque en ajoutant un nouveau disque (parité), puis en supprimant le disque à supprimer. Ensuite, la reconversion en RAID0 devrait donner le résultat requis dans lequel un disque est remplacé.