[reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

rmy · Le 31/12/2010, à 16:34

Je ne comprends pas pourquoi il va falloir reconstruire le raid dans cas :
Je ne parle pas de mettre un disque en fail et de le remplacer, mais de faire une image disque d'un 1Tio sur le 2Tio (MBR compris) et de le swapper ensuite. Le raid devrai y retrouver ses petits, non  ?

chopinhauer · Le 31/12/2010, à 16:55

rmy a écrit :

Je ne parle pas de mettre un disque en fail et de le remplacer, mais de faire une image disque d'un 1Tio sur le 2Tio (MBR compris) et de le swapper ensuite. Le raid devrai y retrouver ses petits, non  ?

Oui, ça devrait marcher (pour le premier Tio du disque). Après tu vas devoir redimensionner les partitions pour utiliser les 2 Tio entiers. C'est à ce point que les choses vont se compliquer. Dès que tu redimensionnes une partition, le composant du RAID correspondant sera endommagé (mdadm ne va plus retrouver les métadonnées qui seront au milieu du disque au lieu d'être à la fin).

rmy · Le 31/12/2010, à 19:19

Donc techniquement je n'évite pas la reconstruction, mais du coup je peux accélérer un peu les choses et améliorer grandement la sécurité pour moi…

Nouvelle proposition donc :
Copier à froid sda,sdb,sdc,sdd sur des disques de 2To. Je remplace tous les disques d'un coup, le raid devrait continuer à tourner et j'ai mon raid sain sous la main si ça merde.
Ensuite je peux tranquillement sortir un disque du raid, agrandir la partition et le remettre dans le raid sans avoir à chercher lequel débrancher, exact ?

Après je reprends les étapes d'agrandissement des différentes couches.

Je crois que je vais tenter ça, j'ai un peu de temps, et puis la copie des 4 disques ça va vous laisser le temps de me répondre… de toutes façons j'ai une copie client encore en cours…

Hoper · Le 31/12/2010, à 19:46

Pardon, j'avais pas compris ce que tu voulais faire. Je pense que chopinhauer à tord. Etendre une partition ne fait que modifier la taille de la boite. Le contenu, le raid, n'est absolument pas modifié, et je suis quasiment certain que mdadm retrouvera donc sans problème l'ensemble de ces données.

En plus, tu ne risque vraiment rien à essayer.. au pire tu aura simplement perdu le temps nécessaire à la copie. Du coup, c'est à mon avis la meilleure piste. A la fois simple et fiable. dd de tous les disques (table des partitions comprises donc), puis extensions des partitions, puis resize du device chiffré, puis mdadm --grow.

chopinhauer · Le 31/12/2010, à 19:51

rmy a écrit :

Donc techniquement je n'évite pas la reconstruction, mais du coup je peux accélérer un peu les choses et améliorer grandement la sécurité pour moi…

Pas avec les version 0.90 et 1.0 des meta-données en tout cas. C'est probablement possible avec les versions 1.1 et 1.2, mais j'ignore si les outils d'administration offrent cette possibilité. En tout cas pour ton nouveau ensemble la version 1.2 est conseillée (sauf pour le /boot).

rmy a écrit :

Ensuite je peux tranquillement sortir un disque du raid, agrandir la partition et le remettre dans le raid sans avoir à chercher lequel débrancher, exact ?

Oui, c'est exacte, mais tu peux aussi essayer de voir les liens dans /dev/disk/by-id te donnent une idée de quel disque est lequel. Ainsi tu vas copier les données une seule fois (la reconstruction de l'ensemble et la copie de données, c'est à peu près la même chose ; bon, tu peux faire la deuxième en parallèle et pas la première, mais il faut voir si t'as plusieurs bus USB ou un seul, dans ce cas la bande passante sera partagée).

chopinhauer · Le 31/12/2010, à 19:54

Hoper a écrit :

Pardon, j'avais pas compris ce que tu voulais faire. Je pense que chopinhauer à tord. Etendre une partition ne fait que modifier la taille de la boite. Le contenu, le raid, n'est absolument pas modifié, et je suis quasiment certain que mdadm retrouvera donc sans problème l'ensemble de ces données.

Les meta-données de l'ensemble RAID ont une position fixe par rapport à la fin de la boîte (version 0.9 et 1.0) ou au début de la boîte (version 1.1 et 1.2). Dans le premier cas après agrandissement de la boîte mdadm aura du mal à retrouver ces données.

rmy · Le 01/01/2011, à 03:13

Plus que plusieurs bus usb, j'ai surtout plusieurs ordis, et parfois je dors. Dès que la copie client est finie (1Tio via ethernet + samba, +650000 fichiers, encore 12 heures au moins si pas de problème), Je coupe la tour principale, je dispatche les 4 disques sur les autres ordis en sata ou e-sata et je fais la copie. Je vous tiens au courant de la suite.

Edit : Copie client finie, copie de mes disque pratiquement aussi. Demain, je tente le swap des 4 disques d'un coup. Je crois que mdadm se fiche bien de leur positionnement, mais ua cas où, je l'ai noté.

Dernière modification par rmy (Le 02/01/2011, à 04:02)

rmy · Le 02/01/2011, à 15:21

Me revoici déjà sur un système fonctionnel. J'ai touché à rien à part remplacer les disques, mais c'est rassurant de voir que ddrescue s'est bien passé.

cat /proc/mdstat 
Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10] 
md0 : active raid5 sdd2[2] sda2[3] sdc2[1] sdb2[0]
      2929484544 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      
md1 : active raid1 sda1[3] sdc1[0] sdd1[1] sdb1[2]
      264960 blocks [4/4] [UUUU]
      
unused devices: <none>

sudo mdadm --detail /dev/md0
[sudo] password for rmy: 
/dev/md0:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 2929484544 (2793.77 GiB 2999.79 GB)
  Used Dev Size : 976494848 (931.26 GiB 999.93 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jan  2 14:20:18 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 6ac8eba5:c657b0f7:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.8040

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2
       2       8       50        2      active sync   /dev/sdd2
       3       8        2        3      active sync   /dev/sda2

Dernière modification par rmy (Le 02/01/2011, à 15:22)

rmy · Le 02/01/2011, à 15:42

Étape suivante donc, pour chaque partition du raid, je fais faire :

sudo mdadm --manage /dev/md0 --set-faulty /dev/sdX2 --remove /dev/sdX2
sfdisk => agrandissement de /dev/sdX2 à sa taill max
sudo mdadm --manage /dev/md0 --add /dev/sdX2

Je commence… arrêtez-moi si je me trompe !

sudo mdadm --manage /dev/md0 --set-faulty /dev/sda2
mdadm: set /dev/sda2 faulty in /dev/md0

sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 2929484544 (2793.77 GiB 2999.79 GB)
  Used Dev Size : 976494848 (931.26 GiB 999.93 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jan  2 14:46:02 2011
          State : clean, degraded
 Active Devices : 3
Working Devices : 3
 Failed Devices : 1
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 6ac8eba5:c657b0f7:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.8062

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2
       2       8       50        2      active sync   /dev/sdd2
       3       0        0        3      removed

       4       8        2        -      faulty spare   /dev/sda2

sudo mdadm --manage /dev/md0 --remove /dev/sda2
mdadm: hot removed /dev/sda2

sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 2929484544 (2793.77 GiB 2999.79 GB)
  Used Dev Size : 976494848 (931.26 GiB 999.93 GB)
   Raid Devices : 4
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jan  2 14:47:11 2011
          State : clean, degraded
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 6ac8eba5:c657b0f7:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.8092

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2
       2       8       50        2      active sync   /dev/sdd2
       3       0        0        3      removed

J'ai ensuite tenté le redimensionnement, mais couillon que je suis, je me suis retrouvé à ne pas pouvoir valider les modifs parce que sda1 était utilisée… donc j'ai retiré sda de md1 de la même maière, puis j'ai utilisé

sudo partprobe /dev/sda

J'ai ensuite rajouté /dev/sda1 à md1 (c'est allé très vite, mais la taille est minuscule…) et je suis en train de regarder la reconstruction de /dev/sda2 sous mes yeux ébahis…

cat /proc/mdstat 
Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10] 
md0 : active raid5 sda2[4] sdd2[2] sdc2[1] sdb2[0]
      2929484544 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
      [>....................]  recovery =  0.0% (438656/976494848) finish=185.4min speed=87731K/sec
      
md1 : active raid1 sda1[3] sdc1[0] sdd1[1] sdb1[2]
      264960 blocks [4/4] [UUUU]

À demain, le temps de faire pareil avec les 4 disques les uns après les autres (je le mets en gras au cas où quelqu'un s'inspirerai de mon topic pour faire pareil chez lui)

edit : et de un !

/dev/md0:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 2929484544 (2793.77 GiB 2999.79 GB)
  Used Dev Size : 976494848 (931.26 GiB 999.93 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jan  2 17:55:03 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 6ac8eba5:c657b0f7:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.10762

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2
       2       8       50        2      active sync   /dev/sdd2
       3       8        2        3      active sync   /dev/sda2

EDIT : et de 2 (je vous passe les détails)
EDIT : et de 3 (je vous passe les détails)

Dernière modification par rmy (Le 03/01/2011, à 01:28)

rmy · Le 03/01/2011, à 04:22

Voilà, tout s'est bien passé. Je continue…

/dev/md0:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 2929484544 (2793.77 GiB 2999.79 GB)
  Used Dev Size : 976494848 (931.26 GiB 999.93 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Mon Jan  3 03:19:25 2011
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 6ac8eba5:c657b0f7:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.17814

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2
       2       8       50        2      active sync   /dev/sdd2
       3       8        2        3      active sync   /dev/sda2

Et donc après avoir re-vérifié que ma structure c'était bien /dev/sdX2 => raid5 => luks => LVM, je commence donc par un :

sudo mdadm --grow /dev/md0 -z max

et… à demain !

Every 2,0s: cat /proc/mdstat                                                                                Mon Jan  3 03:50:06 2011

Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
md0 : active raid5 sdd2[2] sdc2[1] sdb2[0] sda2[3]
      5859740544 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      [==========>..........]  resync = 50.0% (978191616/1953246848) finish=454.0min speed=35788K/sec

md1 : active raid1 sdd1[1] sdc1[0] sdb1[2] sda1[3]
      264960 blocks [4/4] [UUUU]

Dernière modification par rmy (Le 03/01/2011, à 04:52)

rmy · Le 03/01/2011, à 13:17

Sans souci pour le grow…

/dev/md0:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 5859740544 (5588.28 GiB 6000.37 GB)
  Used Dev Size : 1953246848 (1862.76 GiB 2000.12 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Mon Jan  3 12:11:22 2011
          State : clean

Je poursuis :

sudo cryptsetup resize cryptraid

sudo pvresize /dev/mapper/cryptraid
  Physical volume "/dev/mapper/cryptraid" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

Tout cela est instantané et confirmé par :

sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/mapper/cryptraid
  VG Name               debian
  PV Size               5,46 TiB / not usable 2,06 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              1430600
  Free PE               715397
  Allocated PE          715203
  PV UUID               nmSZ1z-ruhx-q5F4-5skz-2WjH-9ohF-GOYz4B

Hoper · Le 03/01/2011, à 13:26

Comme sur des roulettes donc

rmy · Le 03/01/2011, à 19:36

Yop, j'ai pas écrit la fin, mais effectivement, ça y est… me voici avec mon raid5 sur les 4 disques de 2Tio et ça a été plutôt rapide en fait, je m'attendais à des timings de l'ordre de 12H pour la resynchro de chaque disque et c'était en fait 3H pour chacun, et le grow a pris environ 7H à la louche je dirais.

Quelques détails tout de même : mon agrandissement à chaud du fs ou j'ai mon home ne s'est pas bien passé : plantage de metacity, de firefox, de plein de petits trucs, et proco/memoire en stand by alors que le terminal ne m'annonçait pas que c'était fini. J'ai dû rebooter avec les magic keys, suivi bien sûr d'un e2fsck, et j'ai relancé le resize (à chaud toujours), et il manuait juste la fin. Ça c'est fini très vite, j'ai refait un e2fsck et c'est tout bon.

Ensuite pour le resize de la partition de stockage des images client, elle était démontée, j'ai eu une demande expresse de faire d'abord un e2fsck -f. Il y a eu des modifs. Après ça ne marche toujours pas, il faut en refaire un qui se termine sans modification du FS. Et là tout s'est bien passé.

Voilà, je repasse le sujet en Re-résolu. Merci pour le suivi et les encouragements (et les infos pertinentes). Bonne année.

Hoper · Le 03/01/2011, à 22:18

Curieux que ce soit mal passé pour le /home... c'était de l'ext3 ?
Inquietant aussi que des fs data aient du subir des modifications, cela veut dire que les fs n'étaient pas en parfait état avant l'opération

rmy · Le 04/01/2011, à 02:19

Semble-t-il juste une modif sur le journal. Mais j'avais eu quelques coupures d'électricité en décembre (d'où l'achat d'un onduleur…) peut-être que je n'avais pas fait de vérif ensuite sur cette partition…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#201 Le 31/12/2010, à 16:34

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#202 Le 31/12/2010, à 16:55

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#203 Le 31/12/2010, à 19:19

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#204 Le 31/12/2010, à 19:46

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#205 Le 31/12/2010, à 19:51

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#206 Le 31/12/2010, à 19:54

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#207 Le 01/01/2011, à 03:13

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#208 Le 02/01/2011, à 15:21

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#209 Le 02/01/2011, à 15:42

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#210 Le 03/01/2011, à 04:22

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#211 Le 03/01/2011, à 13:17

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#212 Le 03/01/2011, à 13:26

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#213 Le 03/01/2011, à 19:36

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#214 Le 03/01/2011, à 22:18

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#215 Le 04/01/2011, à 02:19

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

Pied de page des forums