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

Support Debian
Tags: #<Tag:0x00007fe4cd22b550>
#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

#21

De quelle “théorie” manifestement erronée sortent ces 700 Mo/s ? La vitesse maximum de copie d’un gros fichier non fragmenté est limitée par le débit séquentiel des disques durs source et destination (le plus lent des deux). 116 Mo/s est une valeur honnête. Le débit séquentiel le plus élevé que j’ai vu sur un disque dur SATA “classique” d’ordinateur de bureau (sans aller chercher les disques SAS de compétition) est de l’ordre de 200 Mo/s.

Qu’est-ce que le débit d’un lien ethernet gigabit vient faire dans une copie entre disques locaux ?
Et de quelle théorie sort cette valeur de 128 Mo/s ?

Comment un programme peut-il prendre en compte la fragmentation lorsqu’il crée des fichiers ? Ce n’est pas censé être du ressort du système de fichiers ?

#22

Désolé, la commande passée est :
# mount -t ext4 /dev/VG_RAID/LV_DATA /mnt
# rsync -a --stats --progress --delete /data/ /mnt

C’est bien là le problème , je suis étonné qu’un transfert entre deux disques SATA ne dépasse pas ceux de liens ethernet.

En fait, je m’inquiète d’avoir un mauvais paramétrage quelque part qui bride les taux de transferts de mes disques durs que ce soit pour cette “longue opération” ou pour d’autres futurs transferts de fichiers.

#23

Par un simple calcul de conversion de débits.
6 Gb/s <=> 6 000 000 000 bits/s <=> (/8) 750 000 000 octets/s <=> (/1024^2) 715 Mo/s

Voilà qui me rassure, mais je reste étonné de cette faible valeur.

#24

Ce n’est pas si simple. Tout d’abord les bits dont il est question résultent d’un encodage 8B/10B (10 bits servent à transmettre un octet) donc il serait plus parlant d’écrire 600 Mo/s au lieu de 6 Gbit/s, et d’autre part tous les octets transmis ne contiennent pas des données de charge utile, une certaine proportion est utilisée par le protocole SATA lui-même (comme les 54 octets des en-têtes d’un paquet TCP/IP/ethernet), c’est ce qu’on appelle la “surcharge protocolaire” (overhead).

D’autre part tu as commis une erreur : 1 Mo vaut 10^6 octets, pas 1024^2 (soit 2^20). C’est 1 Mio qui vaut 2^20 octets. En transmission, l’usage est d’employer les préfixes décimaux et non binaires. En stockage de masse, c’est selon. Les fabricants utilisent les préfixes décimaux du SI (valeur légale oblige), les logiciels utilisent les préfixes décimaux ou binaires. Les fabricants de puces de mémoire RAM ou flash utilisent les préfixes binaires par commodité, les capacités étant des puissances entières de 2. L’ennui est qu’ils ont (avaient ?) tendance à utiliser les notations des préfixes décimaux du SI en leur donnant les valeurs des préfixes binaires. Il en est de même avec de nombreux logiciels, mais les corrections progressent.

#25

Ah oui, je comprends alors pourquoi les débits sont plus faibles que ceux que j’imaginai.

Merci PascalHambourg pour ces précisions.

#26

Plains-toi, mon disque dur PATA (IDE) de 120 Go plafonne à 50 Mo/s…
Le débit séquentiel d’un disque dur est proportionnel à 3 facteurs :

  • la vitesse de rotation des plateaux

  • le rayon de la piste (plus on s’enfonce vers le centre, c’est-à-dire vers la fin, plus le débit diminue)

  • la densité linéaire d’enregistrement. Celle-ci est liée de façon plus ou moins floue à la capacité par plateau qui résulte non seulement de la densité linéaire (quantité de données par unité de longueur sur une piste) mais aussi de la densité des pistes (nombre de pistes par plateau). Ainsi la récente technologie SMR (Shingled Magnetic Recording) permet d’augmenter la capacité par plateau en rapprochant les pistes, c’est-à-dire en augmentant la densité des pistes et non la densité linéaire, donc a priori sans augmenter le débit séquentiel.