Augmenter la taille d'un RAID 1 en changeant les disques durs

Support Debian
Tags: #<Tag:0x00007f509ba26190>
#1

Bonjour,

j’ai actuellement :

  • un disque SYSTEM (partition / et swap) en SSD de 60 GO (/dev/sda);
  • un disque HOME en RAID 1 de 50 GO (/dev/md0 composé de /dev/sdb1 et /dev/sdc1);
  • un disque DATA en RAID 1 de 1,95 TO (/dev/md1 composé de /dev/sdb2 et /dev/sdc2);

Les disques /dev/sdb et /dev/sdc sont deux disques SATA de 2 TO, que je veux remplacer par deux disques SATA de 4 TO.

Sur mon PC, je n’ai qu’une seule nappe SATA de disponible (c’est à dire inutilisée) pour faire les manipulations.

J’aimerais obtenir au final :

  • le disque HOME en RAID 1 de 1 TO (/dev/md0 composé de /dev/sdd1 et /dev/sde1) sans perte de données des deux disques initiaux;
  • le disque DATA en RAID 1 de 3 TO (/dev/md1 composé de /dev/sdd2 et /dev/sde2) sans perte de données des deux disques initiaux;

J’aimerais avant de faire les manipulations avoir votre confirmation des étapes à suivre…

Étape 1 - Brancher le disque /dev/sdd de 4 TO sur la nappe SATA disponible.

Étape 2 - Partitionner le disque /dev/sdd avec parted :
- /dev/sdd1 : 1 TO de type “raid”;
- /dev/sdd2 : 3 TO de type “raid”;

Étape 3 - Rajouter /dev/sdd1 à la grappe /dev/md0 :
# mdadm --add /dev/md0 /dev/sdd1
À ce stade, /dev/md0 mesure toujours 50 GO et /dev/sdd1 n’est pas complètement utilisée par le RAID 1.

Étape 4 - Rajouter /dev/sdd2 à la grappe /dev/md1 :
# mdadm --add /dev/md1 /dev/sdd2
De même, /dev/md1 mesure toujours 1,95 TO et /dev/sdd2 n’est pas complètement utilisée par le RAID 1.

Étape 5 - Retirer les disques initiaux /dev/sdb et /dev/sdc des grappes RAID 1 :
# mdadm --remore /dev/md0 /dev/sdb1
# mdadm --remove /dev/md0 /dev/sdc1
# mdadm --remove /dev/md1 /dev/sdb2
# mdadm --remove /dev/md1 /dev/sdc2

Étape 6 - Retirer physiquement les disques durs de 2 TO du PC.

Étape 7 - Insérer le second disque de 4 TO sur une nappe SATA précédemment libérée.

Étape 8 - Partitionner le nouveau disque de 4 TO tout juste inséré (avec parted) :
- /dev/sde1 : 1 TO de type “raid”;
- /dev/sde2 : 3 TO de type “raid”;
En fait, ce nouveau disque s’appellera certainement /dev/sdb car il sera physiquement sur la deuxième nappe SATA, mais pour la commodité de l’explication je continue avec la dénomination /dev/sde.

Étape 9 - Rajouter /dev/sde1 à la grappe /dev/md0 :
# mdadm --add /dev/md0 /dev/sde1
À ce stade, /dev/md0 mesure toujours 50 GO et /dev/sde1 n’est pas complètement utilisée par le RAID 1.

Étape 10 - Rajouter /dev/sde2 à la grappe /dev/md1 :
# mdadm --add /dev/md1 /dev/sde2
De même, /dev/md1 mesure toujours 1,95 TO et /dev/sde2 n’est pas complètement utilisée par le RAID 1.

Étape 11 - Augmenter la taille de la grappe /dev/md0 à 1 TO :
# mdadm --grow /dev/md0 -z max
Maintenant, la partition RAID 1 /dev/md0 mesure bien 1 TO mais le système de fichiers ne l’utilise pas encore pleinement.

Étape 12 - Augmenter la taille de la grappe /dev/md1 à 3 TO :
# mdadm --grow /dev/md1 -z max
La encore, la partition RAID 1 /dev/md1 mesure bien 3 TO mais le système de fichiers ne l’utilise pas encore pleinement.

Étape 13 - Augmenter la taille utilisée par le système de fichiers ext4 pour utiliser toute la place disponible sur la partition /dev/md0 :
# resize2fs /dev/md0

Étape 14 - Augmenter la taille utilisée par le système de fichiers ext4 pour utiliser toute la place disponible sur la partition /dev/md1 :
# resize2fs /dev/md1

Voilà, est-ce que c’est correct ?
Et n’ai-je rien oublié ?

Merci à vous…

#2

Moi ça me parait propre mais je ne le dirais pas car je ne souhaite aucune responsabilité sur ce qui va se passer.

#3

Merci mattotop.

#4

D’autres avis ?

#5

Utiliser LVM car des trucs du genre

Cela devient pénible :rofl:
Cela dit, autant je suis à l’aise avec

pvcreate .dev/sdXy
lvextend  [--size xxxG]  /dev/data_vg/data_lv /dev/sdXy

autant je n’y connais rien en RAID logiciel. Et donc je ne sais pas dans quel ordre empiler les technologies

  • RAID logiciel sur des volumes LVM
  • ou l"inverse créer des volumes LVM au-dessus du RAID logiciel

On voit que vous maîtrisez votre sujet. Votre message est pratiquement un modèle du genre.

Vu les volumes de données concernés, ces opérations vont prendre “un certain temps”.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#6

Bonjour,

A ta place je repartirais sur quelque chose de propre et copierais l’existant avec rsync. En gros :

  • Création d’un nouveau RAID1
  • Création d’un PV
  • Création d’un VG
  • Création des deux LV
  • Formatage des deux LV (ext4 ou autre)
  • Copie des données

Après, quitte à faire ça, pourquoi ne pas faire du ZFS ou BTRFS ?

Sinon, au niveau de ta procédure, ça semble “propre” pour reprendre @mattotop.

#7

J’ai plusieurs critiques sur cette procédure.

  1. Il aurait mieux valu créer un seul ensemble RAID et le partitionner avec LVM, c’est plus souple. Mais c’est un peu tard.

  2. Il faut marquer un membre comme “failed” avant de pouvoir le retirer.

  3. Les partitions du disque de 4 To sont ajoutées en tant que spare, donc elles ne vont pas être synchronisées immédiatement. La synchronisation automatique ne démarrera que lorsqu’une partition active sera marquée “failed”. Cela a deux inconvénients :

  • pendant la reconstruction, il n’y aura plus de redondance (1 membre actif, 1 membre failed et 1 membre en reconstruction)
  • si tu marques les deux partitions actives “failed” en même temps, l’ensemble RAID sera défaillant ; il faut marquer une partition et attendre la fin de la reconstruction de la nouvelle partition avant de marquer l’autre.

Si tu veux conserver deux ensembles RAID, je recommande plutôt la procédure suivante qui maintient la redondance :

Brancher un disque de 4 To et le partitionner.
Ajouter ses partitions aux ensembles RAID.
Changer le nombre de membres actifs des deux ensembles RAID de 2 à 3. Cela lancera immédiatement la synchronisation sans dégrader la redondance.
Attendre la fin de la reconstruction.
Marquer les partitions d’un seul des disques de 2 To “failed” et les retirer.
Remplacer le disque correspondant (ne pas se tromper sinon on perd la redondance) et partitionner le second disque de 4 To.
Ajouter les partitions du second disque de 4 To. Comme les ensembles RAID sont dégradés, la synchronisation commencera immédiatement.
Attendre la fin de la reconstruction.
Marquer les partitions du disque de 2 To restant “failed” et les retirer.
Changer le nombre de membres actifs des deux ensembles RAID de 3 à 2.

#8

Merci littlejohn75,

effectivement à l’époque je n’avais pas utilisé LVM et je ne vois pas trop comment le rajouter maintenant dans mon environnement en RAID 1. :thinking:

#9

Merci à toi sk4hrr,

je suis d’accord avec toi, c’est ce qu’il faudrait idéalement faire, mais je n’ai qu’une nappe SATA de disponible pour recréer un nouveau RAID 1 en plus du RAID déjà existant…

#10

Merci PascalHambourg pour ce retour très détaillé.

Pour le point 1, y a-t-il encore la possibilité de la faire ?
Par exemple en créant sur le nouveau disque de 4 TO un RAID 1 avec 1 seul disque ? puis suivre la procédure de sk4hrr ci-dessus ?
Ensuite, démonter les deux anciens disques de 2 TO et rajouter le second disque de 4 TO au RAID 1 nouvellement créé ?

En tout cas, merci pour les conseils sur le démontage propre des disques du RAID (avec “failed”) et des problèmes de synchronisation des disques. :+1:

#11

Tu n’as pas de boitier externe en USB ou autre ?
Après comme je l’ai dit, ta procédure semble bonne, c’est juste que je suis du genre à éviter de faire trop compliqué/risqué lorsque cela est possible.

#12

Oui, mais ça implique de passer par une phase ou au moins un des ensembles RAID sera dégradé sans redondance.

  • Soit tu crées le futur ensemble RAID dégradé sur un seul disque de 4 To, tu le remplis puis tu le complètes avec le second disque.
  • Soit tu dégrades les ensembles RAID actuels pour créer et remplir le futur RAID complet sur les deux disques de 4 To.

Quelle est la meilleure option ? J’aurais tendance à dire que c’est la première car elle laisse intacts les ensembles RAID d’origine.

1 J'aime
#13

Merci sk4hrr et PascalHambourg pour vos dernières réponses.

Je n’avais pas pensé au boîtier de disque dur externe pour palier le manque de nappe SATA disponible le temps de la mise à jour.

C’est une bonne idée, je pense que je vais me tourner vers cette solution et recréer un RAID + LVM plus propre sur mes nouveaux DD.

Merci à vous tous.

#14

Ah si, petite précision…
Une fois la nouvelle partition “raid” partagée en LVM entre 1 TO pour /home et 3 TO pour /data, comment par la suite étendre par exemple /home à 1,5 TO et réduire /data à 2,5 TO ?

C’est possible sans perte de données ?

#15

Trois cas :

  • le système de fichiers à réduire ne supporte pas la réduction -> il faut exporter et ré-importer les données (exemple : XFS avec xfs_dump et xfs_restore).

  • le système de fichiers à réduire supporte uniquement la réduction “à froid”, c’est-à-dire non monté -> il faut le démonter, et donc qu’il ne soit pas utilisé (aucun processus n’y a de fichier ouvert ou son répertoire courant).

  • le système de fichiers à réduire supporte la réduction “à chaud”, c’est-à-dire monté -> pas besoin de le démonter (exemple : Btrfs).

Dans tous les cas, il faut réduire le système de fichiers avec le programme correspondant à son type (exemple : resize2fs pour ext4) avant de réduire le volume ou la partition, et ne surtout pas réduire le volume à une taille inférieure à celle du système du fichier, même d’un octet sinon le système de fichiers risque d’être endommagé (parfois de façon irréparable) et de ne pas se monter. Pour agrandir, on agrandit d’abord le volume ou la partition, puis le système de fichiers.

Comme la reduction d’un système de fichiers peut avoir des contraintes exposées ci-dessus et implique un déplacement des données situées au-delà de la nouvelle taille, le mieux est encore de l’éviter. Pour cela, il y a une méthode simple : au lieu d’allouer tout l’espace du groupe de volumes lors de la création des volumes logiques, on crée les volumes logiques avec des tailles initiales suffisantes et on laisse beaucoup d’espace libre. Ensuite, en fonction des besoins futurs on pourra facilement agrandir chaque volume grâce à l’espace libre disponible, ce qui est un des avantages de LVM par rapport aux partitions classiques. Si le système de fichiers est Btrfs, on peut même simplement créer un nouveau volume logique et l’ajouter au système de fichiers existant pour l’agrandir au lieu d’agrandir le volume existant.

Exemple : on crée les volumes home et data à 1 To chacun, il reste 2 To libres. Si un volume se remplit à plus de 80%, on l’agrandit de 500 Go par exemple.

2 J'aime
#16

Ça fonctionne, même si les espaces alloués ne sont pas contigus ?
Par exemple :

  • début du disque : LV_HOME(1/2) de 1TO;
  • puis : LV_DATA de 1 TO;
  • ensuite : LV_HOME(2/2) de 500 MO;
  • reste l’espace libre de 1,5 TO;

LVM sait faire ?

#17

Bien sûr. Comme je l’écrivais, c’est un des nombreux avantages de LVM sur les partitions classiques.

Exemple :

lvdisplay -m
  --- Logical volume ---
  LV Path                /dev/t43/root
  LV Name                root
  VG Name                t43
  LV UUID                ExmVBR-8D6d-x5Fo-ti1i-B8s3-dwjW-1bwbpo
  LV Write Access        read/write
  LV Creation host, time groseille, 2018-07-08 16:05:26 +0200
  LV Status              available
  # open                 0
  LV Size                4,00 GiB
  Current LE             1024
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0
   
  --- Segments ---
  Logical extents 0 to 952:
    Type		linear
    Physical volume	/dev/sda2
    Physical extents	0 to 952
   
  Logical extents 953 to 1023:
    Type		linear
    Physical volume	/dev/sda2
    Physical extents	1667 to 1737
#18

Ah oui, Génial !

Merci PascalHambourg.

#19

Bonjour à tous,

j’ai créé le RAID 1 et partitionné ce dernier avec LVM et créé des systèmes de fichiers ext4.

Je suis en train de copier les données sur les nouveaux disques avec rsync et c’est extrêmement long…

Rsync m’indique des taux de transfert pour les plus gros fichiers ne dépassant pas les 116 MB/s.

Est-ce normal pour du SATA à 6 Gb/s (ce qui devrait faire “en théorique” aux alentours de 700 M0/s) ?

#20

Sans avoir la commande rsync exacte qui a été passée (on a pas mal d’options il me semble) comment voulez-vous que nous vous répondions ?

On est très près d’un maximum théorique du 128 Mo/s d’un lien Gigabit, ceci étant dit.

Ne vous plaignez pas, car avec un rsync entre machines directement connectées, j’étais très loin de ce genre de débit, simplement parce que le système de fichier source était dans un état de fragmentation déplorable (les fichiers avaient été générés par un un programme qui ne prenait pas en compte ce genre de difficultés).

Et pourquoi s’inquiéter ? Cette opération de copie ne va se faire qu’une fois, cela prendra le temps qu’il faudra.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

« Celui qui, parti de rien, n’est arrivé nulle part n’a de merci à dire à personne !! »
Pierre Dac