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

rmy · Le 31/08/2010, à 17:25

Bonjour,
je n'ai pas à proprement parler de problème. Pas encore. Mais je préfère anticiper pour rester le moins longtemps possible dans une situation délicate.

Voici la situation de départ : j'ai une install d'ubuntu 10.04.1 sur un LVM chiffré, avec une partition de boot en dehors de celle-ci. Ci-dessous un peu plus de détail.

sudo sfdisk -luS

Disque /dev/sda : 77825 cylindres, 255 têtes, 63 secteurs/piste
Unités= secteurs de 512 octets, décompte à partir de 0

   Périph Amorce  Début       Fin   #secteurs Id  Système
/dev/sda1   *        63    498014     497952  83  Linux
/dev/sda2        498015 1250258624 1249760610  83  Linux
/dev/sda3             0         -          0   0  Vide
/dev/sda4             0         -          0   0  Vide

sudo vgdisplay
  --- Volume group ---
  VG Name               debian
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  11
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               595,93 GiB
  PE Size               4,00 MiB
  Total PE              152558
  Alloc PE / Size       152558 / 595,93 GiB
  Free  PE / Size       0 / 0   
  VG UUID               CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe

sudo lvdisplay
  --- Logical volume ---
  LV Name                /dev/debian/swap_1
  VG Name                debian
  LV UUID                LxEGT1-fmgR-XGGX-byOt-j2p6-bXrs-SasLSs
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                2,53 GiB
  Current LE             648
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1
   
  --- Logical volume ---
  LV Name                /dev/debian/rootbuntu
  VG Name                debian
  LV UUID                qjJsVW-8iWp-CT0H-YqoS-hsl1-yFTL-MlzMub
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                15,00 GiB
  Current LE             3840
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2
   
  --- Logical volume ---
  LV Name                /dev/debian/homebuntu
  VG Name                debian
  LV UUID                fo3HBW-BL0n-ctuO-Rgg7-U03h-Vorb-bjq8cP
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                578,40 GiB
  Current LE             148070
  Segments               3
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:3

Le but de l'opération : Migrer vers une solution en raid5, en gardant l'install actuelle.

Ce que j'envisage de faire : Comme j'ai 4 nouveaux disques de 1Tio et que je n'ai que 4 connecteurs sata sur ma carte mère (sans raid matériel, mais ce n'est pas le problème, je n'en veux pas), plutôt que de créer un raid5 dégradé, puis d'ajouter le 4è disque après avoir copié l'actuel, je me suis dit qu'il serait peut-être plus malin de procéder comme suit.

1/ Brancher les 4 disques neufs, réserver le miens
2/ Booter sur un live USB
3/ Créer le raid5
4/ Créer une partition boot non chiffrée sur le raid5
5/ Créer un LVM chiffré sur l'ensemble du raid5 restant
6/ Créer mes LV sur ce LVM
7/ Brancher mon disque actuel en externe et rsync-er les fichiers des différentes partition/LV vers leurs homologues fraîchement créés
8/ Réparer/Réinstaller grub probablement ?

J'aimerais vos avis, vos liens vers toutes les docs que vous connaissez concernant le raid logiciel, mdadm, et autres utiles, si possible en français, et votre aide quand ça se passera mal après

Merci d'avance.

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

tshirtman · Le 31/08/2010, à 17:53

http://blog.windfluechter.net/archives/147-Adding-a-RAID-under-a-LVM.html

ça peut aider je pense…

je crois que j'avais un lien avec quelqu'un qui faisait la même chose en crypté… je cherche

edit: http://current.workingdirectory.net/posts/2010/growing-disks/ c'est un peu différent, il fait juste grossir son raid, mais bon les deux combinés y'a peut être assez d'info

Dernière modification par tshirtman (Le 31/08/2010, à 17:56)

rmy · Le 31/08/2010, à 18:26

Cool déjà de la bonne lecture. À mon avis c'est loin d'être l'option la plus simple pour moi, mais ça me permettrait de tester les capacités de reconstruction de mon raid5. Autre option donc, mais je privilégie la première pour l'urgence...

1/ Passer d'un LVMchiffré à un raid5lvmchiffré avec ton premier lien (mais celui-ci n'utilisera pas tout l'espace puisque mon premier disque fait 640Gio)

2/ Déclarer le premier disque comme mort pour le raid et le retirer (normalement ça continue de tourner),

3/ rajouter mon idsque de 1To à la place du 640Gio et reconstruire le raid

4/ Agrandir le raid, le VG, le LV et les FS

rmy · Le 04/09/2010, à 03:59

up des idées ? Sinon je me lance demain…

rmy · Le 05/09/2010, à 15:50

re up parce que je suis à la bourre, je prends donc encore vos propositions pour cette nuit (¿)

Hoper · Le 07/09/2010, à 14:08

Polom polom...

Ce que tu envisage de faire, et que tu décrit donc dans ton premier post, fonctionnera très probablement. Par contre, c'est une méthode longue et compliqué, et qui nécessitera un arrêt de la machine assez long. (Ce qui ne pose peut etre aucun problème hein...)

La seule chose que je ne peux pas garantir, ne l'ayant pas encore testé moi même, c'est la capacité de grub à booter sur un raid5. Vérifie donc bien qu'il en est capable, et qu'il n'y a pas des restrictions ou autre trucs bizarroïdes...

Maintenant, et parce que je suis une grosse feignasse, voila comment j'aurai procédé personnellement :

- Mise en place de trois disques, création d'un raid5.
La, deux possibilités... soit tu fait un raid5 dégradé, soit, si ca te semble trop risqué, tu fais un raid5 "normal" sur 3 disques (sachant qu'on fera ensuite un --grow avec le quatrième).

pvcreate /dev/md0p2 (la première partition sera la partition de boot)
vgextend debian /dev/md0p2
pvmove /dev/xxx2 (ton disque actuel) --> Toutes les données LVM seront migrées à chaud vers /dev/md0p2
vgreduce /dev/debian/xxx2 (on retire l'ancien disque).

Et pour lvm, c'est finit. Bien sur il reste la partition système à copier normalement (rsync ou cpio...)

Il faudra de toute façon ré-installer grub et ajouter le quatrième disque du raid, et soit tu l'agrandi, soit tu le répare si il était en mode dégradé.

Si tu choisit l'agrandissement, il restera à augmenter la taille de la partition lvm (puisque le disque à grossi), un petit coup de "pvresize" pour que lvm s'aperçoive que le disque est maintenant plus gros, et le tour est joué.

-> Beaucoup moins de commande à taper, et toutes les opérations longues (déplacement des données présentes dans LVM) sont faites à chaud.

Je te met toutefois en garde contre une chose... Si tu voulais utiliser ma méthode mais en branchant tous les disques d'un coup, et en mettant ton ancien disque système en externe. Je te le déconseille vivement, car tu pourrai tomber (comme moi il y a une semaine) sur ce bug :
https://bugzilla.kernel.org/show_bug.cgi?id=9401
(on dirait qu'il y a un soucis avec la bdd pour le moment )

En résumé, bug de pvmove lorsque on utilise trois couches (mdadm/cryptsetup/lvm) et un port usb... enfin.. je crois pour le port usb, car je n'avais jamais eu le moindre souci avant, et des pvmove, j'en ai fait quelque uns...

Bref, ta technique est plus fiable (plus progressive, tu fais des copies et non des déplacement) mais plus pénible à réaliser. La mienne est plus simple et plus "cool", mais elle n'est fiable qu'a 99,9% (ou un truc dans le genre

Dernière remarque, j'aime pas beaucoup les partitions sur un raid software...
Tant qu'a faire, si je devais absolument mettre la partition de boot sur un raid, je pense que j'essayerai de voir si grub (grub2 maintenant) ne serait pas capable de booter sur un volume logique... Auquel cas, plus de partitions, tout le raid serait sous LVM... (mais je n'ai jamais testé hein... la je garanti vraiment rien).

rmy · Le 07/09/2010, à 16:55

Merci Hoper pour le passage. J'ai bien relu deux fois, parce qu'avec le boulot à foison j'ai un peu mal au crâne, et je crois que j'ai tout suivi. Il y a juste le dernier paragraphe… Je n'arrive pas à saisir ce que tu veux dire. En fait, pour lvm et cryptsetup il faut que les modules soient chargés, non ? Est-ce que j'aurais loupé un épisode avec grub2 ? Il me semblait bien qu'avec grub il fallait que /boot soit en dehors du lvm chiffré…

Ce que je pensais faire, pour ne pas faire de partitions dans mon raid, c'est faire mon raid sur des partitions. Je ne suis peut-être pas clair :
chaque disque partitionné à l'identique avec une mini partition et une grosse (en fait je perd 3x la taille de ma partition /boot, mais c'est raisonnable) ex :
sda1=sdb1=sdc1=sdd1=500Mio
sda2=sdb2=sdc2=sdd2=le reste
ensuite le raid5 sur sdX2
enfin le lvm par dessus avec mon lv / et mon lv /home.

Est-ce que ce serait problématique ?

Question subsidiaire, mais juste pour avoir une réponse parce que je n'en vois pas l'intérêt :
On peut mettre en place un LVM sur plusieurs PV différents (donc par exemple un disque seul, un raid5, un raid1 et un raid0 pour faire une salade de raids), mais peut-on mettre en place un raid à partir de plusieurs LV ?

EDIT pour précision : je peux arrêter cette machine sans souci, d'ailleurs, est-il bien raisonnable de brancher du sata à chaud dans une tour ?

Dernière modification par rmy (Le 07/09/2010, à 16:58)

Hoper · Le 07/09/2010, à 17:19

Ce que je pensais faire, pour ne pas faire de partitions dans mon raid, c'est faire mon raid sur des partitions. Je ne suis peut-être pas clair :
chaque disque partitionné à l'identique avec une mini partition et une grosse (en fait je perd 3x la taille de ma partition /boot, mais c'est raisonnable) ex :
sda1=sdb1=sdc1=sdd1=500Mio
sda2=sdb2=sdc2=sdd2=le reste
ensuite le raid5 sur sdX2
enfin le lvm par dessus avec mon lv / et mon lv /home.
Est-ce que ce serait problématique ?

Aucun problème ! Je ne sais pas ou j'avais la tête, mais c'est de loin la meilleure solution. La plus propre et la plus fiable en tout cas.
Par contre, tant qu'a sortir le système de LVM (ce qui t'évite de te poser trop de question vis à vis de grub etc), a ta place je sortirai TOUT le système, et pas seulement /boot.

J'ignore ou son stockée tes données, et si tu as des choses importantes (ou susceptibles de grossir beaucoup comme /var par exemple) tu peux parfaitement les mettre dans LVM. Mais tout le reste... / /etc /usr et compagnie.. tout ça je mettrait ca hors LVM. Donc ca ferait 1 partition de quelque Go pour l'OS, et le reste avec LVM. A l'intérieur, éventuellement var si tu en ressent le besoin. (et swap, et home...)

Question subsidiaire, mais juste pour avoir une réponse parce que je n'en vois pas l'intérêt :
On peut mettre en place un LVM sur plusieurs PV différents (donc par exemple un disque seul, un raid5, un raid1 et un raid0 pour faire une salade de raids), mais peut-on mettre en place un raid à partir de plusieurs LV ?

Je n'ai jamais testé, mais techniquement, oui, ca fonctionnerai forcément. Pour l'intérêt... La comme ça je vois pas... L'avantage d'un lv est d'avoir une taille facilement modifiable, alors que la contrainte du raid et de s'appuyer justement sur des devices de taille identiques... donc bon...

Basiquement on pourrait imaginer le scenario suivant :
Une personne veut un raid 5 avec 3 disques de 1 To. Mais il n'a que 2 disques de 1 To et 2 disque de 500 Go. Il fait un lv de 1 To sur les deux disques de 500 et ajoute ce lv aux deux autres disques pour faire son raid.
Sauf que c'est non seulement ultra crade comme solution, mais aussi bien moins performant que si il avait tout simplement fait un premier raid0 avec les deux disques de 500g, puis un raid 5 avec les deux disques de 1 To plus le raid0 précocement crée.

En fait, je vois un seul exemple valable d'utilisation (il doit y en avoir d'autre hein... c'est juste que je manque d'imagination .

Imagine un très gros serveur dans une grande entreprise. L'application à besoin de pouvoir écrire très, très,très, très vite une énorme quantité de donnée. (Disons qu'ils font des mesures pour des explosions atomique ou un truc du genre). Autrement dit, il faut un débit en écriture de malade. La société en question fait le tour des fournisseurs de solution de stockage, mais aucune baie de disque du marché n'offre les capacités requises.
Alors tu achete non pas une baie de disque, mais 4 ou 5. Bien sur, chaque baie de disque à des raids interne, ca on s'en fiche. Elles présentes des volumes que tu met bien sur dans LVM. Ensuite, et uniquement pour augmenter les débits I/O tu va créer un raid0 entre les lv construits sur les différentes baies de disques.

Bon, dans la vraie vie j'ai jamais vu hein... les baies actuelles sont capable d'encaisser des débits que bien peu de machines peuvent envoyer... (parce qu'il faut les cpus qui vont bien derrières Mais en pure théorie, ca pourrait être utile oui.

rmy · Le 07/09/2010, à 17:29

merci de toutes les remarques. En fait, je veux garder le système aussi dans le lvm pour qu'il soit chiffré aussi.

Par contre, je viens de voir que grub, depuis sa version 1.95, est capable de gérer un /boot sur lvm. Reste à trouver comment. Comme j'aime un peu les défis, je crois que je vais m'accorder un peu de temps là dessus, et envisager une solution full lvm

Je complèterai ta doc si j'y arrive.

Hoper · Le 07/09/2010, à 17:35

En fait, je veux garder le système aussi dans le lvm pour qu'il soit chiffré aussi.

EDIT : D'après ton message tu boot déjà sur un OS chiffré (/boot excepté) donc j'avais écrit n'importe quoi. Techniquement je me demande bien comment ca peut fonctionner, et comment le noyau sait ou trouver les autres fs, avec quel algo les déchiffrer, avec quel clef etc...

Ceci dit, objectivement, je ne vois pas trop l'intérêt de chiffrer le système. Autant il est évident que le home ou le var devrait être chiffré, autant les binaires ou les librairies... quel intérêt ?

Dernière modification par Hoper (Le 07/09/2010, à 17:38)

rmy · Le 07/09/2010, à 17:54

En fait jusqu'à présent je ne me suis pas pris la tête à dissocier /var /tmp /mnt et consors du système. Je me prépare à passer "en production" à un rythme soutenu pour ma boite de récup de données. Je stocke des images et je les monte un peu au besoin, je ne veux simplement pas, en aucun cas, que des données de clients soient accessibles. Même en cas de saisie de mon matériel par exemple.

J'ai trouvé ça entre temps :
http://forums.linuxmint.com/viewtopic.php?f=46&t=41573
http://lwn.net/Articles/339994/
./viewtopic.php?id=412574

et sur irc :

/boot on LVM should work out of the box, at least with a current snapshot (1.98 has some problems with how current distributions tend to set up /dev/mapper). If you have cryptsetup then your /boot needs to be unencrypted.

Dernière modification par rmy (Le 07/09/2010, à 18:25)

Hoper · Le 08/09/2010, à 09:34

Merci pour les infos. Autrement dit avec cryptsetup, il faut toujours dissocier /boot (autrement dit / en ce qui me concerne). Et globalement, chiffrement ou pas, tout n'est peut etre pas encore assez sec pour faire du full LVM en prod.

Je comprend ta problématique de confidentialité, mais justement, les images des disques de tes clients ne se trouveront jamais dans /, mais plutot dans /data ou /home ou /boulot ou je sais pas quoi... Bref, un lv qui sera bien sur chiffré.

Le fait de monter ensuite l'image dans /mnt ou n'importe ou est une opération uniquement en mémoire... Bref, il n'y aura jamais aucune donnée client dans /

Bonne chance pour ton entreprise. Vu la très faible quantité de gens qui comprenne l'importance des sauvegarde, tu aura surement des clients

Dernière modification par Hoper (Le 08/09/2010, à 09:35)

rmy · Le 08/09/2010, à 18:04

J'en ai déjà pas mal

Ceci dit je n'ai pas compris comme ça la réponse IRC : pour moi le "unencrypted" laissait entendre qu'il devait être déchiffré avant, mais pas forcément stocké en clair.

En fait l'autre côté pratique d'éviter un partitionnement en amont du raid est l'évolutivité vers un raid 6 avec un spare, et ça m'éviterait de me retapper un partitionnement "à chaque fois" même si j'espère qu'il n'y aura pas trop de fois… Alors du coup, voici ce que je pensais :
raid5 sur les 4 disques, en entier. LVM sur le raid5 avec un LV non chiffré pour le boot si nécessaire, le reste chiffré ou non ça ne change pas grand chose, si ? Y a-t-il vraiment une perte importante de performance à chiffrer le "/" ?

Hoper · Le 08/09/2010, à 21:03

Tout depend des I/O qu'il y a sur le /. Globalement ... bon c'est une estimation vraiment très à la louche hein... Mais pour une bande passante de 10 Mo/s en ecriture, je pense qu'il faut, en gros donc, 500 Mhz de puissance.. Autrement dit, pour écrire à 40 ou 50 Mo/s sur un volume chiffré, tu as un coeur qui ne fera que du chiffrement. C'est vraiment très, très grosse louche hein...

Par contre quand tu fais des copies de données (déchifrer -> copier -> rechiffrer) ca a vite fait de bouffer du cpu.

Moi si je ne chiffre jamais le / c'est plutot parce que je n'en voit pas l'interet (que des binaires qui ne revelent rien) et surtout qu'en cas de problèmes ce sera toujours beaucoup plus facile de booter sur un live CD, n'importe lequel et de réparer son OS si il n'y a pas en plus des couches type LVM ou chiffrement.

Cela dit, pour le LVM, c'est vrai qu'on gagne vraiment en souplesse quand même donc bon...

rmy · Le 21/09/2010, à 10:04

Désolé d'avance pour les multi-posts, je vais garder ici une trace de toute la manip, comme ça je pourrai éventuellement alimenter un tuto ensuite ou linker depuis ce qui existe déjà.

Situation de départ, starting blocks, feu.

rmy@rmyprod:~$ sudo fdisk -l

Disque /dev/sda: 640.1 Go, 640135028736 octets
255 têtes, 63 secteurs/piste, 77825 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0xa32865b4

Disque /dev/sdb: 1000.2 Go, 1000204886016 octets
255 têtes, 63 secteurs/piste, 121601 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x00000000

Disque /dev/sdc: 1000.2 Go, 1000204886016 octets
255 têtes, 63 secteurs/piste, 121601 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x00000000

Disque /dev/sdd: 1000.2 Go, 1000204886016 octets
255 têtes, 63 secteurs/piste, 121601 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x000b6215

rmy · Le 21/09/2010, à 10:11

1/ Préparation des disques (abrégé)

sudo fdisk /dev/sdb
: n
: p
: 1
: 1 
: 121601
: t
: fd >> Type système de partition modifié de 1 à fd (Linux raid autodetect)

: w

idem sur /dev/sdc et /dev/sdd

2/ Création du raid5 sur 3 disques

sudo mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sd[bcd]1
mdadm: /dev/sdd1 appears to contain an ext2fs file system
    size=976760000K  mtime=Tue Sep 21 08:50:47 2010
Continue creating array? y
mdadm: array /dev/md0 started.

sudo mdadm --daemonise /dev/md0

sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Tue Sep 21 10:15:40 2010
     Raid Level : raid5
     Array Size : 1953519872 (1863.02 GiB 2000.40 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Sep 21 10:15:40 2010
          State : clean, degraded, recovering
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 3% complete

           UUID : d9126e19:7dd8a0b1:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.1

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

À ce stade, si j'ai bien compris, le raid est en train de se "synchroniser", je vais éviter tout redémarrage donc, mais par contre sdb1 et sdc1 étant prêts je peux commencer à

3/ migrer mon lvm.

sudo parted /dev/md0 mklabel msdos, puis création d'une partition non formatée avec gparted

sudo pvcreate /dev/md0p1
  Physical volume "/dev/md0p1" successfully created

sudo vgextend debian /dev/md0p1
  Volume group "debian" successfully extended

sudo pvmove /dev/mapper/cryptroot -i 5

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

rmy · Le 21/09/2010, à 11:12

Hoper, si tu passes par là, peux-tu me confirmer cette dernière commande ? C'est la seule qui jusqu'à présent diffère de ce que tu m'avais dit. Le man de pvmove demande en argument un PV (ou2)…

Ça va prendre un bout de temps, je vais partir au boulot, retour ce soir très tard. Je me pose encore une autre question du coup : pour la suite, le vgreduce pour sortir le disque précédent du VG, ça je comprends.
Dans la manip que je fais actuellement, je n'ai pas encore touché à /boot, qui était en dehors de mon lvm. Donc normalement quand toute la migration des extents et la construction du raid seront finis, je devrais pouvoir rebooter dans cette situation sans changer mes disques, non ?

Ensuite, je ferai un essai en intégrant /boot au lvm (copie des fichiers dans le dossier adéquat) et en réinstallant grub.

Si ça ne fonctionne pas, je rajouterai un LV non chiffré pour /boot et je réinstallerai grub à nouveau.

Qu'en penses-tu ? (Oui, je sais, je n'ai pas sorti / du lvm chiffré, mais c'était tellement plus simple de conserve la situation actuelle…)

Question subsidiaire : depuis que j'ai commencé le pvmove, la ligne de mdadm -details montre que :

Rebuild Status : 22% complete

reste bloqué à cette valeur là. Cela va-t-il reprendre après ? Ai-je fait une boulette en lançant le pvmove trop tôt ?

Dernière modification par rmy (Le 21/09/2010, à 11:58)

Hoper · Le 21/09/2010, à 12:49

Polom polom....

Comme tu l'indique, le man de pvmove demande en argument un PV. Donc un "physical volume", autrement dit, un disque.
Or, pour moi "/dev/mapper/cryptroot" est tout sauf un disque. C'est un device chiffré, monté au dessus d'un lv, ou peut etre d'un disque, la je manque d'info. Mais dans tous les cas, je doute que ce soit un "disque physique".

Tu aura la liste de tes pv avec la commande pvs
Ce n'est qu'un de ces pvs que tu dois pouvoir donner en argument à la commande pvmove. Cela dit, si elle n'a pas retournée d'erreur, c'est que tu as du effectivement utiliser ce device comme pv... ce que je trouve vraiment, très bizarre comme technique. (pourquoi mettre le chiffrement si "bas" dans la couche de stockage ?)

Ensuite, la construction du raid entraine évidement de très nombreuses opérations sur les disques. Lancer une autre opération, elle aussi très consommatrice en terme d'io n'était pas forcément judicieux. En théorie, cela ne peut rien "casser". Mais les tétes des disques vont passer leur temps à se balader à droite a gauche, et au final tu va prendre 3 ou 4 fois plus de temps que si tu avais attendu la fin de la première opération. (exactement comme si tu avait lancé des copies multiples ou autre trucs dans le genre).

Pour le reste... heu... il faudrait que je me replonge un peu dans le sujet et dans ce que tu veux faire, parce que j'avoue que j'avais plus trop la tête à ça la...

rmy · Le 21/09/2010, à 13:20

^^

sudo pvdisplay
[sudo] password for rmy: 
  --- Physical volume ---
  PV Name               /dev/mapper/cryptroot
  VG Name               debian
  PV Size               595,93 GiB / not usable 1,67 MiB
  Allocatable           yes (but full)
  PE Size               4,00 MiB
  Total PE              152558
  Free PE               0
  Allocated PE          152558
  PV UUID               TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV
   
  --- Physical volume ---
  PV Name               /dev/md0p1
  VG Name               debian
  PV Size               1,82 TiB / not usable 2,56 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               324373
  Allocated PE          152558
  PV UUID               NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg

tu te doutes bien que le nom du PV je l'ai pas inventé, hein…

En fait, ça vient d'une install debian où j'avais suivi un tutuo lorsque je ne maîtisait rien du tout… (est-ce vraiment mieux maintenant…  ?) et ensuite j'avais récupéré le LVM lors du passage à ubuntu, j'avais fait un tuto quelque par là dessus sur ma démarche… si je le retrouve je linke.

Hoper · Le 21/09/2010, à 14:52

ouai.... c'est spécial en effet... la du coup... le contenu de /dev/md0p1 sera déjà chiffré... J'ai un petit peu du mal à voir comment tout va fonctionner au final (même si de toute façon, puisque ca marchait avant, il n'y a pas de raison que ca change, on ne fait qu'un déplacement des donnes).

Au boot de la machine, il te demande un mot de passe ? tu as mis un truc dans /etc/crypttab ? Si oui j'avoue que j'aimerai bien voir quoi.

Un détail... bon on y peut rien la mais... C'est dommage d'être toujours avec des tailles de PE à 4 MB. 4 MB c'est bien pour des petits VG... Mais la tu frôle des 2To quand même, alors une taille de PE plus grande (64 MB par exemple) aurait été préférable.

Tes deux opérations avancent ? le cat /proc/mdstat il dit quoi ? Et le pvmove ?

rmy · Le 21/09/2010, à 19:43

je suis parti au boulot et la, c'est réunion RMLL… Je rentre un mdp au boot, et il me semble bien avoir mis un truc dans cryptsetup. Si j'arrive à passer le ssh par mon téléphone, je te mets le fichier avant ce soir, sinon vers minuit.

Et sinon, je ne frole pas les 2Tion, mais les 3Tio, puisqu'il y a un autre disque qui va venir s'ajouter en grow...
(et en gros aussi)

Je peux encore tout refaire, c'est instructif, si je peux changer la taille des PE... Et d'ailleurs, ne faudrait-il pas caller la taille des PE avec celle des stripes raid ?

rmy · Le 22/09/2010, à 00:51

cat /etc/crypttab
# <target name>	<source device>		<key file>	<options>
cryptroot		/dev/sda2	none	luks,retry=1,lvm=debian

Et pour l'historique, ça vient de là :
./viewtopic.php?id=271397

rmy · Le 22/09/2010, à 00:53

sudo mdadm --detail /dev/md0
[sudo] password for rmy: 
/dev/md0:
        Version : 00.90
  Creation Time : Tue Sep 21 10:15:40 2010
     Raid Level : raid5
     Array Size : 1953519872 (1863.02 GiB 2000.40 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Wed Sep 22 00:52:02 2010
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : d9126e19:7dd8a0b1:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.1868

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

\O/

rmy · Le 22/09/2010, à 00:53

  /dev/mapper/cryptroot: Moved: 100,0%

Hoper · Le 22/09/2010, à 09:52

Je peux encore tout refaire, c'est instructif, si je peux changer la taille des PE... Et d'ailleurs, ne faudrait-il pas caller la taille des PE avec celle des stripes raid ?

Question intéressante. mais en fait... non, je vois pas l'intérêt. Les PE sont des unités d'allocation d'espace disque, pas des quantités de données à écrire. (et il n'y a, a priori, aucun lien entre les deux donc). Si je voulais augmenter la taille des PE c'est juste pour simplifier le travail de LVM, pour économiser un tout petit peu de place disque (et encore, je suis même pas certain que la partie allouée aux metadata lvm serait vraiment plus petite), quelques ko de ram et encore....

En revanche, c'est au niveau système de fichier qu'il faudrait, dans l'absolu, essayer de faire un peu de tuning pour que chaque bloc puisse etre facilement découpé au moment de repartir la donnée sur le raid.

Mais bon... tout ça c'est super théorique hein... Sachant qu'en plus, tous ces réglages fins s'écrouleront complétement le jour ou tu rajoute un disque...
Bref, ce sont des questions sympa à résoudre en théorie, en pratique il vaut mieux éviter de toucher à ce genre de chose dans 99% des cas

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 31/08/2010, à 17:25

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

#2 Le 31/08/2010, à 17:53

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

#3 Le 31/08/2010, à 18:26

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

#4 Le 04/09/2010, à 03:59

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

#5 Le 05/09/2010, à 15:50

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

#6 Le 07/09/2010, à 14:08

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

#7 Le 07/09/2010, à 16:55

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

#8 Le 07/09/2010, à 17:19

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

#9 Le 07/09/2010, à 17:29

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

#10 Le 07/09/2010, à 17:35

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

#11 Le 07/09/2010, à 17:54

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

#12 Le 08/09/2010, à 09:34

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

#13 Le 08/09/2010, à 18:04

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

#14 Le 08/09/2010, à 21:03

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

#15 Le 21/09/2010, à 10:04

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

#16 Le 21/09/2010, à 10:11

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

#17 Le 21/09/2010, à 11:12

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

#18 Le 21/09/2010, à 12:49

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

#19 Le 21/09/2010, à 13:20

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

#20 Le 21/09/2010, à 14:52

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

#21 Le 21/09/2010, à 19:43

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

#22 Le 22/09/2010, à 00:51

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

#23 Le 22/09/2010, à 00:53

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

#24 Le 22/09/2010, à 00:53

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

#25 Le 22/09/2010, à 09:52

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

Pied de page des forums