Augmenter la capacité d'un RAID 1

Support Debian
#1

Bonsoir,

J’aimerai remplacer 2 disques 1TO par 2 disques 2TO dans un RAID 0 soft (mdadm). Le but est d’augmenter la capacité de stockage.
C’est juste de le faire de la manière suivante ?
1 -Remplacer un premier disque de 1TO par un disque 2 TO et le laisser se reconstruire.
(avec les options -f et -r de mdadm, puis mdadm --add /dev/md0 /dev/sda).
2 - IDEM : Remplacer le second disque de 1TO par un disque 2 TO et le laisser se reconstruire.
3 - Faire augmenter la capacité du RAID (mdadm --grow /dev/md0 --size=max).
Pardon, je n’ai pas cherché des explications sur le net, c’est quoi (write-intent bitmap) ou quelle précaution faut-il prendre à son sujet ?
3 - Faire un fsck par precaution puis Etendre le fs (resize2fs /dev/md0). (remarque: Ce n’est pas un LVM).

#2

Le RAID 0 ne fournit pas de redondance. On ne peut pas remplacer un disque et le reconstruire puisque ses données ne sont pas répliquées. Le plus simple est probablement de créer un nouvel ensemble RAID et d’y transférer les données.

#3

Pardon, ce n’est pas le stripping mais le mirroir. Donc c’est un RAID 1 et non pas un RAID 0

#4

Dans ce cas si possible le plus sûr serait d’ajouter les deux nouveaux disques et de les synchroniser avant de retirer les deux anciens, ainsi la redondance serait préservée à tout moment.

  • ajouter les deux nouveaux disques en spare
  • augmenter le nombre de membres actifs à 4 avec --grow
  • attendre la synchronisation
  • retirer les deux anciens disques
  • réduire le nombre de disques actifs à 2 avec --grow
  • augmenter la taille de l’ensemble RAID
  • augmenter la taille du système de fichiers (pas besoin de fsck en général ou si monté, sinon resize2fs l’indique)
#5

Merci

#6

D’apres ce que j’ai lu sur le net, il est conseillé de désactiver le bitmap avant d’augmenter la taille du RAID, puis le réactiver ensuite.
Le bitmap serait une sorte de cartographie de l’espace de stockage RAID qu’il faut refaire apres avoir augmenté la taille du RAID. Le bitmap enregitrerait les adresses physiques ou sont modifiés les données sur l’espace RAID. (C’est pour des raisons de performance de synchro ou autres, mais c’est un autre sujet).
Du coup, si je garde l’ancien bitmap, il sera possible que la capacité de stockage redevienne à 1TO au prochain redemarrage du service ou de la machine, puisque l’ancien bitmap a la cartographie du RAID 1TO.
Je mets tout au conditionnel, car c’est ce que j’ai compris seulement.
Bien evidemment, n’hesitez pas à corriger ou à fournir des explications plus claires.

#7

D’après la page de manuel de mdadm, c’est même obligatoire :

Also the size of an array cannot be changed while it has an active bitmap. If an array has a bitmap, it must be removed before the size can be changed. Once the change is complete a new bitmap can be created.

#8

Oui, j’ai fini par retrouver les infos. Le manuel est clair. J’ai donc mis « mdadm --grow /dev/md0 --bitmap none » avant de faire un grow.

Le dernier tuto que j’ai lu mettais juste « …it is strongly recommended that you remove the bitmap before increasing the size of the array… » dans d’autres endroits, ils disent seulement que c’est « conseillé »…

#9

Je remarque qu’un des membres de l’ensemble RAID est un disque entier (sdb) et l’autre une partition (sdc1). Techniquement ce n’est pas une erreur mais c’est le genre de chose qui peut créer de la confusion a posteriori. Assure-toi notamment que sdb n’a pas de table de partition qui entrerait en conflit avec le superbloc RAID.

Personnellement je crée toujours une partition de type RAID même si elle occupe tout l’espace du disque, car je trouve que c’est plus clair.

#10

Le systeme est arreté brutalement par accident. je tente déjà de redemarrer le serveur s’il veut bien.

#11

Enfin le serveur a redémarré aprés quelques petites difficultés…

Voilà la nouvelle situation avec le RAID :

root@srv-deb:~# lsblk
NAME     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda        8:0    0 465,8G  0 disk  
├─sda1     8:1    0 244,1G  0 part  /
├─sda2     8:2    0     6G  0 part  [SWAP]
└─sda3     8:3    0 215,6G  0 part  
  └─sda3 253:0    0 215,6G  0 crypt /home
sdb        8:16   0   1,8T  0 disk  
└─md127    9:127  0   1,8T  0 raid1 
sdc        8:32   0   1,8T  0 disk  
└─sdc1     8:33   0   1,8T  0 part  
root@srv-deb:~# 

root@srv-deb:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md127 : active (auto-read-only) raid1 sdb[3]
      1953348608 blocks super 1.2 [2/1] [_U]
      
unused devices: <none>
root@srv-deb:~# 

root@srv-deb:~# mdadm --detail /dev/md0
mdadm: cannot open /dev/md0: No such file or directory
root@srv-deb:~# 

root@srv-deb:~# systemctl status mdadm
● mdadm.service
   Loaded: masked (Reason: Unit mdadm.service is masked.)
   Active: inactive (dead)
root@srv-deb:~#

J’ai encore un disque de 1TO qui contient toujours les données. ce disque était membre du RAID avant le début des manips.
Comment procéder ? Faut-il redémarrer le serveur en branchant ce disque de 1TO avec 1 nouveau disque pour revenir à une config fonctionnelle. Puis procéder à l’upgrade 1To–> 2TO ?

#12

Je ne suis pas sûr de comprendre tout ce que j’ai fait…je le laisse terminer.

root@srv-deb:~# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Mon Feb 20 20:06:18 2017
        Raid Level : raid1
        Array Size : 1953348608 (1862.86 GiB 2000.23 GB)
     Used Dev Size : 1953348608 (1862.86 GiB 2000.23 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

       Update Time : Fri Nov  6 13:19:15 2020
             State : clean, degraded, recovering 
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 1

Consistency Policy : unknown

    Rebuild Status : 0% complete

              Name : srv-deb:0  (local to host srv-deb)
              
            Events : 3114811

    Number   Major   Minor   RaidDevice State
       2       8       17        0      spare rebuilding   /dev/sdb1
       3       8       32        1      active sync   /dev/sdc
#13

Bonjour,
La recontruction est terminée. L’espace RAID est de 2TO mais le fs est de 1TO
lorsque je lance resize2fs /dev/md127, il me répond par « resize2fs: Périphérique ou ressource occupé while trying to open /dev/md127 » . Les disques sont cryptés.

Voici quelques retours de commandes :

root@srv-deb:~# resize2fs /dev/md127
resize2fs 1.44.5 (15-Dec-2018)
resize2fs: Périphérique ou ressource occupé while trying to open /dev/md127
root@srv-deb:~# 

root@srv-deb:~# lsof | grep md127
md127_rai  210                      root  cwd       DIR        8,1      4096          2 /
md127_rai  210                      root  rtd       DIR        8,1      4096          2 /
md127_rai  210                      root  txt   unknown                                 /proc/210/exeroot@srv-deb:~# 
root@srv-deb:~# 

root@srv-deb:~# lsblk               
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0 465,8G  0 disk  
├─sda1        8:1    0 244,1G  0 part  /
├─sda2        8:2    0     6G  0 part  [SWAP]
└─sda3        8:3    0 215,6G  0 part  
  └─sda3    253:0    0 215,6G  0 crypt /home
sdb           8:16   0   1,8T  0 disk  
└─md127       9:127  0   1,8T  0 raid1 
  └─md127   253:1    0   1,8T  0 crypt 
sdc           8:32   0   1,8T  0 disk  
└─sdc1        8:33   0   1,8T  0 part  
  └─md127     9:127  0   1,8T  0 raid1 
    └─md127 253:1    0   1,8T  0 crypt 
root@srv-deb:~#

Faut-il faire resizefs sur support décrypté ??
Si non, c’est en rapport avec :

#14

Qu’est-ce qui est chiffré ? Le contenu de l’ensemble RAID ? Dans ce cas il doit y avoir un volume chiffré /dev/mapper/xxx dont le nom xxx est défini dans /etc/crypttab pour ouverture automatique au démarrage. C’est dans ce volume chiffré qu’il faut agrandir le système de fichiers. Le volume chiffré lui-même s’adapte à la taille du conteneur chiffré lors de son ouverture, donc pas besoin de l’agrandir explicitement.

On peut voir la sortie de blkid ?

#15

Chaque disque etait chiffré avant la création du RAID.
/etc/crypttab est vide

#16

Comment as-tu procédé pour chiffrer les disques puis créer l’ensemble RAID ?
Je crains le pire.

#17

Ok, si je comprend bien, j’ai répondu un peu trop vite :slight_smile:
Il faut que je relise la documentation perso pour retrouver comment j’ai fait ce RAID.
Chose est sûre, les données sont encore là lorsque je monte /dev/md127 dans un repertoire.

Si non peut-on partir de l’état actuel des choses pour voir comment étendre le fs ?

#18

A condition de le connaître, l’état actuel des choses. D’où ma demande de la sortie de blkid.

#19

Yes sir,

root@srv-deb:~# blkid
/dev/sda1: UUID="c383c7a1-7e6b-4e7b-928e-603e19e928e1" TYPE="ext4" PARTUUID="b4836547-01"
/dev/sda2: UUID="5797f575-cbad-4590-ac7b-0783ec3c8390" TYPE="swap" PARTUUID="b4836547-02"
/dev/sda3: UUID="deaabdab-dae0-4199-a433-73bf969f77c2" TYPE="crypto_LUKS" PARTUUID="b4836547-03"
/dev/sdb: UUID="4f6eda2c-5dda-5614-54ed-03e103e62841" UUID_SUB="d2eecf94-e158-a0c8-a621-0a3c3b744458" LABEL="srv-deb:0" TYPE="linux_raid_member"
/dev/sdc1: UUID="4f6eda2c-5dda-5614-54ed-03e103e62841" UUID_SUB="146867c8-03a7-e16a-62af-a33740d3232a" LABEL="srv-deb:0" TYPE="linux_raid_member" PARTLABEL="Elements" PARTUUID="cbaa1bc5-c843-49da-93be-17a6c0e3706b"
/dev/md127: UUID="66d914a6-d4aa-41f2-967a-ba120004355c" TYPE="crypto_LUKS"
/dev/mapper/sda3: UUID="74cdff43-6471-4a36-9fdb-d4bab8b6c8b0" TYPE="ext4"
/dev/mapper/md127: UUID="031bb7f1-49db-4e6a-a77e-a97481d7869e" TYPE="ext4"
root@srv-deb:~# 

root@srv-deb:~# cat /etc/crypttab 
# < target name> < source device>         < key file>      < options>
root@srv-deb:~#
#20

Ça m’étonnerait. D’après blkid, /dev/md127 est un conteneur chiffré LUKS. Ce n’est pas un système de fichiers, ça ne se monte pas. Par contre /dev/mapper/md127 contient un système de fichiers ext4. Je suppose que c’est le volume chiffré ouvert à partir de /dev/md127. A mon avis le nom « md127 » est très mal choisi car il prête à confusion entre le conteneur et le contenant qui ont le même nom. Même remarque pour /dev/sda3 et /dev/mapper/sda3.

Alors comment sont ouverts les deux volumes chiffrés /dev/mapper/sda3 qui est monté sur /home et /dev/mapper/md127 ? Manuellement ? Avec des unités systemd ?