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

rmy · Le 14/10/2010, à 11:19

Ça avance, merci…

mais je vais devenir chèvre. Maintenant, cryptsetup me demande encore le mot de passe pour dévérouiller /dev/sda2 au lieu de /dev/md0… et forcément, ça ne marche pas… mais le problème du grub est résolu.

Edit : je refais un update-initramfs -k all -c, on va voir ce que ça donne…

Dernière modification par rmy (Le 14/10/2010, à 11:39)

rmy · Le 14/10/2010, à 12:07

\o/

Pfiou, merci hoper et chopinauer, vraiment !

Bizarrement, je pense que je vais remettre à plus tard la suite de l'expérimentation qui consistait à remettre à plat mes lv…
J'ai comme un peu de retard à rattraper…

Donc, la suite, serait maintenant d'ajouter mon 4è disque et de grossir mon raid.
Si j'ai bien compris, il va falloir que :
1- Je partitionne ce nouveau disque à l'identique des 3 autres.
2- Je fasse un mdadm --grow
3- Je crée un /dev/md2 pour mon "autre" /boot avec sda1 (oui, le nouveau disque est en position1 et va faire glisser les autres, je pense) et sdb1
4- Je crée un /dev/md10 qui sera un raid0 par dessus les deux raid 1 de /boot (c'est comme ça que ça marche ?)
5- Je synchronise mon raid1+0, je modifie mon fstab, je fais un grub-update, puis un grub-install, et je recommence à croiser les doigts ?

(Je me dis que finalement je vais pas faire le malin pour un truc totalement inutile (un raid1+0 sur un /boot c'est vraiment chercher des ennuis…) et je vais peut-être me passer de cette expérience et aller directement vers un raid1 sur 4 disques du coup, comme ça, je boote quelque soit le disque qui tombe en rade…

apparté @chopinauer : Je traîne sur le forum depuis un bon bout de temps, je m'intéresse aux lvm depuis un petit moment aussi (raid plus récemment) et je ne t'avais encore jamais croisé. Tu as pourtant des interventions de grande qualité, et tu possèdes clairement un très haut niveau de maîtrise. Est-ce le hasard, ou bien tu n'interviens sur le forum que depuis récemment ? Est-ce indiscret de te demander si ce que tu fais dans la vie est en rapport ou si c'est juste par passion ?

chopinhauer · Le 14/10/2010, à 14:37

Pour le problème de l'image initramfs je pense que contrôler la crypttab et effacer /etc/initramfs-tools/conf.d/cryptroot pour qu'elle puisse se régénérer pourrait aider à dépasser le problème.

Le RAID 10 c'est pour le répertoire /boot? Je pense que ce n'est pas nécessaire. Ajoute plutôt deux autres partitions à ton RAID 1. De toute manière ce système de fichiers n'est utilisé que pour lire le noyau et initrd, donc niveau performance pas grand chose ne changera. Et de pour la fiabilité, du moment où un des disques se casse, il faut le remplacer (à cause du RAID 5).

rmy · Le 15/10/2010, à 12:09

Je crois que le problème venait du fait que j'ai fait les choses à l'envers…
Normalement, si j'ai bien suivi, il aurait fallu faire, après modif des fichiers de conf nécessaires, d'abord grub-update, puis grub-install (sans les ajouts de modules, finalement c'est bon), puis enfin seulement l'update initramfs.

Pour le raid10 sur /boot, je n'avais pas l'intention de l'utiliser en prod, c'était juste pour l'intérêt de l'expérimentation. Il faudrait faire le tests, mais j'ai l'intuition que le gain de rapidité théorique du raid0 dans ce cas ne devrait pas compenser, vu la faible quantité d'accés disque, la perte de temps due au montage des raids (2x raid1 + raid0 par dessus) entre autres.

Pour la suite : je vais ajouter un disque de 1To en "position" sda. Actuellement comme ce port sata est vide, les autres disques apparaissent en sd[abc]. Normalement cela ne devrait pas poser de problème puisque maintenant tout passe par les UUID. Sauf peut-être le raid5 qui va encore vouloir se reconstruire ?

Arrêtez moi si je me trompe, mais il faut :
1- Que j'ajoute le disque (matériellement), et que je vérifie qu'il se nomme bien /dev/sda après reboot. (Je ne sens pas trop le coup de l'ajouter en sdd puis qu'il réaparaisse en sda ensuite… Et que je le partitionne à l'identique.
2- Que je l'ajoute (logiciellement) au raid :

sudo mdadm --add /dev/md0 /dev/sda2

3- Que j'étende le raid :

sudo mdadm --grow /dev/md0 --raid-devices=4 --backup-file=/media/autredisque/backup_grow_raid5.log

Et pour /dev/md1 :

sudo mdadm --add /dev/md1 /dev/sda1
sudo mdadm --add /dev/sdb1
sudo mdadm --grow /dev/md1 --raid-devices=4

puis

sudo grub-install /dev/sda

pour avoir grub aussi sur ce nouveau disque

Les questions que je me pose : est-ce que cryptsetup ne va pas se fâcher parce que je lui change la taille de son conteneur "cryptraid". Je ne pense pas, je crois que c'est indépendant de la taille du support, mais je demande au cas où.

Ensuite est-ce que je peux retailler directement mes LV, et/ou en créer d'autre ou bien j'oublie quelque chose d'important au passage ?

chopinhauer · Le 15/10/2010, à 14:03

Le Grub assemble le RAID 1 ou utilise '(hd0)' comme périphérique, sachant que c'est presque (sauf un morceau à la fin) identique au RAID 1? Vaudra mieux peut-être installer Grub sur toutes les périphériques.

Pour le Luks, je pense qu'il utilise de toute manière le périphérique entier, mais il faut voir. Après il faudra aussi un pvresize pour le LVM.

rmy · Le 15/10/2010, à 14:07

Effectivement, j'avais zappé le pvresize…

Pour grub, je l'ai déjà installé dans le manips précédentes sur sda, sdb, sdc, qui vont devenir respectivement sdb, sdc, sdd. Faut-il le réinstaller sur tous les périphériques ou seulement sur sd qui ne l'a pas encore ?

chopinhauer · Le 15/10/2010, à 14:31

Tu peux regarder si cela démarre sur le deuxième disque avec le premier débranché. Juste pour voir la résistance aux pannes. Avec deux disque débranchés ce n'est pas la peine, car ton RAID 5 sera en pannes.

rmy · Le 15/10/2010, à 15:21

OK, je verrai ça ce soir

Hoper · Le 15/10/2010, à 16:30

Par contre attention... si tu commence à faire des tests avec un disque en moins, tu va désyncroniser ton raid... Et vu la taille de tes disques, la re-syncrho sera longue... très longue.. enfin tu dois en savoir quelque chose.

As tu déjà envisagé de mettre en place les fonctionnalités de log au niveau du raid ? Tu perd certes en performances (jusqu'a 20% de perte en écriture, peut être même un peu plus d'après ce que j'avais lu) mais alors les re-syncrho sont instantanées.... (et j'en ai fait l'expérience il n'y a pas très longtemps).

rmy · Le 15/10/2010, à 16:36

Non, je ne m'étais pas encore penché sur cette voie… as-tu un lien pratique pour m'éviter de chercher ?

Hoper · Le 15/10/2010, à 16:44

Tout est la :
http://etbe.coker.com.au/2008/01/28/wri … t-bitmaps/

rmy · Le 15/10/2010, à 17:58

Merci. Je ne pense aps tester pour le moment parce que je n'ai pas les moyens d'un "bitmap externe" et l'essentiel de l'usage de mon raid va être de la copie d'image disque. J'ai donc besoin d'un max de perf sur ce type d'opérations, quitte à faire de la reconstruction plus longue si nécessaire.

rmy · Le 15/10/2010, à 20:53

Hop, déjà une info : j'ai branché mon 4è disque, sdj au branchement -> sda au reboot. J'ai juste pris soin d'intstaller grub avant le reboot. Le raid n'a pas bronché, même pas de resynchro.

Je passe à la suite :

sudo sfdisk -d /dev/sdb  > sfdisk_sdb.out
sudo sfdisk /dev/sda < sfdisk_sdb.out

voilà pour le partitionnement.

Je commence par le raid 1

sudo mdadm --add /dev/md1 /dev/sda1
mdadm: added /dev/sda1
sudo mdadm --add /dev/md1 /dev/sdb1
mdadm: added /dev/sdb1
sudo mdadm --grow /dev/md1 --raid-devices=4

et comme j'ai écrasé le mbr de sda, je lui recolle un grub-install.

enfin :

sudo mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90
  Creation Time : Sat Oct  9 11:51:22 2010
     Raid Level : raid1
     Array Size : 264960 (258.79 MiB 271.32 MB)
  Used Dev Size : 264960 (258.79 MiB 271.32 MB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Fri Oct 15 20:49:08 2010
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

           UUID : a8faec27:afb2d420:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.112

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1
       2       8       17        2      active sync   /dev/sdb1
       3       8        1        3      active sync   /dev/sda1

rmy · Le 15/10/2010, à 20:58

et pour le raid5 :

sudo mdadm --add /dev/md0 /dev/sda2
mdadm: added /dev/sda2

sudo mdadm --grow /dev/md0 --raid-devices=4 --backup-file=/media/f7e20052-a7a2-4a9c-ad98-0a846c34eeee/backup_grow_raid5.log
mdadm: Need to backup 384K of critical section..
mdadm: ... critical section passed.

et c'est parti. Je vais attendre tranquillement avant le pvresize ^^ de toutes façons, j'ai faim.

sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.91
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 1952989696 (1862.52 GiB 1999.86 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 : Fri Oct 15 20:55:21 2010
          State : clean, recovering
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

 Reshape Status : 0% complete
  Delta Devices : 1, (3->4)

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

    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 : la taille de l'array augmente seulement quand la synchro est finie ?

Dernière modification par rmy (Le 15/10/2010, à 21:00)

rmy · Le 15/10/2010, à 22:51

Every 2,0s: cat /proc/mdstat                                                              Fri Oct 15 22:43:14 2010

Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid10]
md0 : active raid5 sda2[3] sdd2[2] sdb2[0] sdc2[1]
      1952989696 blocks super 0.91 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      [==>..................]  reshape = 14.8% (144603092/976494848) finish=547.8min speed=25305K/sec

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

unused devices: <none>

chopinhauer · Le 15/10/2010, à 23:04

À demain alors.

rmy · Le 15/10/2010, à 23:14

ouaip. Une bonne nuit sans scrupules...

rmy · Le 16/10/2010, à 07:36

    Update Time : Sat Oct 16 07:35:46 2010
          State : clean

rmy · Le 16/10/2010, à 21:19

sudo pvresize /dev/mapper/cryptraid 
  Physical volume "/dev/mapper/cryptraid" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
rmy@rmyprod:~$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/mapper/cryptraid
  VG Name               debian
  PV Size               2,73 TiB / not usable 3,94 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              715205
  Free PE               300503
  Allocated PE          414702
  PV UUID               nmSZ1z-ruhx-q5F4-5skz-2WjH-9ohF-GOYz4B

rmy · Le 27/10/2010, à 21:05

Bon, voilà, le temps me manque pour poursuivre l'expérimentation, et comme j'ai besoin d'un système fonctionnel et qu'il l'est, que le projet de départ a abouti à savoir migrer l'ensemble, je repasse (oui, j'ai un peu oublié, ce qui prouve que ça tourne très bien) dire encore une fois MERCI à vous, et mettre ce sujet en résolu.

rmy · Le 30/12/2010, à 11:14

Et Hop, comme dirait mon fils, "REVENUUUUUUU !"

Pour plein de bonnes raisons je ré-ouvre ce post. Papa Nowel a bien écouté ma requête et devrait livrer dans quelques heures (minutes ?) 4 disques de 2Tio. Bien sûr, la suite de l'exercice est de migrer tout ça en gagnant de la place.
Justement, je me souvenait que :
1/ Tshirtman avait parlé d'un gus qui faisait un grow sur du raid chiffré + LVM… par contre je ne me souvenais plus que c'était du RAID1.
2/ Hoper avait parlé d'un moyen d'accélérer les resynchros, peut-être que cela serait sage au moins le temps de la migration…
3/ Je voulais l'avis d'expert sur la méthode que je compte employer…

Situation de départ :
4* 1Tio, formatés identiques avec 2 partitions :
sd[a-d]1 dans un Raid 1 pour /boot
sd[a-d]2 dans un Raid 5 support de cryptesetup, lui-même support de LVM
grub installé sur chaque disque.

Ce que je compte faire :
0- Activer le "intend-bitmap" (en fait non, il semblerait que ça n'ait aucun intérêt pour une reconstruction sur un disque complet)
1- Remplacer mes 4 disques l'un après l'autre, avec à chaque fois les étapes suivantes :
[*]

mdadm --manage /dev/md0 --set-faulty /dev/sda2
mdadm --manage /dev/md1 --set-faulty /dev/sda1

mdadm --manage /dev/md0 --remove /dev/sda2
mdadm --manage /dev/md1 --remove /dev/sda1

Extinction, remplacement du 1Tio par le 2 Tio
Copie du partitionnement avec fdisk

mdadm --manage /dev/md0 --add /dev/sda2
mdadm --manage /dev/md1 --add /dev/sda1

Attente de la resynchro avant disque suivant, grub-install etc…
[/*]
2- Agrandir le raid :

mdadm --grow /dev/md0 -z max

3- Puis le conteneur luks :

cryptsetup resize cryptraid

4- Vient ensuite le PV :

pvresize /dev/mapper/cryptraid

5- Et enfin le(s) LV et le(s) FS contenu(s) (cf La doc LVM de Hoper )

Bon, ça c'est la théorie, mais en pratique, ce ne serait pas possible de remplacer tout le 1- par une simple copie directe de chacun des disques, MBR compris, de disque à disque ?

rmy · Le 30/12/2010, à 13:30

Ceci n'est pas un UP !

Disques reçus, pas d'urgence pour la réponse, je vous laisse… deux heures
Non, bien sûr… j'ai une copie pour un client en cours qui va me prendre 33 heures, et j'ai bien l'intention de sauver mes données avant la manip…

À continuer de me creuser la cervelle, j'en arrive à une question subsidiaire : dans la première méthode présentée (set-faulty, remove, add) : Comment savoir quel disque physique correspond à la lettre de lecteur de celui que l'on a viré ? Parce que je n'ai pas de raid6… et du coup j'imagine que si je retire un autre disque que celui que j'ai viré du raid, alors que celui-ci est dégradé, je risque quelques soucis majeurs… Une idée ?

Hoper · Le 30/12/2010, à 16:10

Yop.

Globalement, ta technique doit fonctionner, mais quel bordel... je veux dire, c'est super long et c***** à faire. Je suppose que si tu part dans cette direction c'est que tu n'a absolument pas les moyens de brancher des 4 disques en plus des disques existants ? Au moins trois peut etre ?
Sincérement, quitte à racheter une carte contrôleur sata à 10 euros, je crois vraiment que c'est ce que je ferai. (pour l'alimentation, au pire tu prend une seconde alimentation, c'est pas vraiment un soucis).

Parce que si tu trouve le moyen de brancher au moins trois disques, (et donc construction d'un raid dégradé) alors tout devient beaucoup, beaucoup plus facile... Pas pour le /boot, mais pour le lvm, tu ajoute le nouveau device (crypt2 ?) dans le vg, puis tu fais un pvmove et tu regarde tout se faire tout seul

Concernant le moyen de retrouver le disque à coup sur après l'avoir supprimé du raid (méthode 1 donc), la seule méthode vraiment fiable consiste à retrouver le numéro de serie du disque, à l'aide de la commande hdparm.

rmy · Le 31/12/2010, à 02:43

Est-ce que ça te parraît viable de les brancher dans des boitiers externes usb/firewire le temps de faire la manip ?
Et puis je vais encore avoir à me refaire la config cryptsetup et refaire mon grub et compagnie avec ta méthode, non ? (Rappel, mon LVM est une surcouche de mon luks)

Et le coup de faire une image disque et de les remplacer un par un ? Je duplique /dev/sda, j'éteinds, je remplace, je rallume… qu'est-ce que ça donne ?

Hoper · Le 31/12/2010, à 16:06

Et le coup de faire une image disque et de les remplacer un par un ? Je duplique /dev/sda, j'éteinds, je remplace, je rallume… qu'est-ce que ça donne ?

Ca marche, c'est juste que ca fait plus de manipulation... 4 arret de la mahchine, 4 reconstructions de raid... c'est super long.

Re : [RE-OUVERT] migration d'un lvm chiffré vers un raid5+lvm chiffré
Est-ce que ça te parraît viable de les brancher dans des boitiers externes usb/firewire le temps de faire la manip ?

Usb, je te conseil pas. Tu peux tomber sur un gros bug de pvmove dans ce cas de figure (je dois pouvoir retrouver les références du bug en question puisque je suis tombé en plein dedans).

Ma technique fonctionne bien pour la partie LVM, mais c'est sur que toute la partie boot bein... oui ca t'oblige à tout refaire. Si tu as le temps ta technique va fonctionner hein... c'est juste que ca semble vraiment lourd juste pour changer de raid.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#176 Le 14/10/2010, à 11:19

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

#177 Le 14/10/2010, à 12:07

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

#178 Le 14/10/2010, à 14:37

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

#179 Le 15/10/2010, à 12:09

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

#180 Le 15/10/2010, à 14:03

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

#181 Le 15/10/2010, à 14:07

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

#182 Le 15/10/2010, à 14:31

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

#183 Le 15/10/2010, à 15:21

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

#184 Le 15/10/2010, à 16:30

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

#185 Le 15/10/2010, à 16:36

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

#186 Le 15/10/2010, à 16:44

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

#187 Le 15/10/2010, à 17:58

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

#188 Le 15/10/2010, à 20:53

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

#189 Le 15/10/2010, à 20:58

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

#190 Le 15/10/2010, à 22:51

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

#191 Le 15/10/2010, à 23:04

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

#192 Le 15/10/2010, à 23:14

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

#193 Le 16/10/2010, à 07:36

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

#194 Le 16/10/2010, à 21:19

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

#195 Le 27/10/2010, à 21:05

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

#196 Le 30/12/2010, à 11:14

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

#197 Le 30/12/2010, à 13:30

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

#198 Le 30/12/2010, à 16:10

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

#199 Le 31/12/2010, à 02:43

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

#200 Le 31/12/2010, à 16:06

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

Pied de page des forums