[Liste-clx] LVM et Xen sont sur un disque dur......

VANHULLEBUS Yvan vanhu_clx at zeninc.net
Mer 21 Mar 16:32:40 CET 2018


On Wed, Mar 21, 2018 at 03:38:20PM +0100, Fran?ois wrote:
> On Wed, Mar 21, 2018 at 02:57:39PM +0100, VANHULLEBUS Yvan wrote:
> > Salut.
> >
> > Donc, j'avance sur la préparation de mon futur hyperviseur, et je me
> > pose des questions existentielles que je ne pourrai plus me poser plus
> > tard, en particulier comment répartir mon espace disque, et to LVM or
> > not to LVM, that is the question !
> >
> >
> > Pour vous résumer un peu la situation, je vais avoir:
> >
> > 2 disques de 8To chacun, en miroir. La, je pensais utiliser mdadm,
> > mais je viens de voir une option "mirror" dans lvcreate ????
> > A priori, il est très très peu probable que je rajoute d'autres
> > disques de stockage plus tard sur ce serveur.
> 
> Au pif, un raid1 sur des disques de 500G qui trainnent, ou qui coûtent
> rien pour faciliter (peut-être?) les choses: avoir le système sur la
> grappe "de gauche", et les datas sur la grappe "de droite"?

Alors, non: ca ne facilite pas les choses sur les points qui
m'interrogent, et si je suis à peu près certain de ne pas rajouter
plus tard de disques durs de stockage, c'est que je n'ai simplement
pas la place dans la machine pour les fixer proprement :)
Le SSD en cache, si je me décide, il sera direct en PCIe (aussi pour
des raisons de performances, remarque).


Du coup, je vais faire un md0 pour le / du Dom0 (et même là, j'hésite
à directement embarquer les disques complets en LVM, en fait....) et
un md1 pour "tout le reste en LVM, y compris pour le Dom0").

Ca ne répond pas tout à fait à ma question de "est-ce que je pourrais
directement utiliser LVM pour la partir RAID"..... mais je crois que
je vais choisir mdadm "parce que je connais", et que je vais déjà
faire pas mal de choses encore assez obscures pour moi avec LVM, la
partie "j'ai encore mes données quand un disque va lacher", je veux
l'assurer :D


> Pour le reste, j'aurais tendance à dire, au doigt mouillé, partant du
> principe que le "surcoût", qui n'est même pas certain se rattrape sur
> la flexibilité:
> 
> LVM sur l'host: comme ça tu fais un LV par guest.

LVM sur le dom0, j'étais pas mal parti dans l'idée.


> LVM dans la VM: comme ça chaque VM peut faire ses partitions sans
> faire chier l'host, ni compliquer le setup des disques dans xen.

Carrément ?
En fait, je crois que je suis seulement en train de vraiment assimiler
le niveau auquel LVM fonctionne.... il gère des bouts de disques par
morceaux, et se contrefout plus ou moins de ce qu'on met dedans, c'est
bien ca ?


> Xen passe un périf bloc, qui se trouve être sur du LVM. Et il se
> trouve aussi que sur ce LVM, il y a du LVM. Mais que si c'était un
> LUKS ça serait pareil. Et que si c'était un FS pour FreeBSD ça serait
> pareil aussi. Et que si tu accédais aux données en raw, ça serait
> pareil aussi. (J'arrête là?)

Oui, je commence à me faire à l'idée, comme j'ai dit au dessus :)
Et d'ailleurs, du coup, je me pose la question de faire un truc genre:
lvcreate -n firewall_raw -L ??? vg0
dd if=firewall.img of=/dev/vg0/firewall_raw

puis utiliser vg0/firewall_raw.
Pour la VM firewall en elle même, ca ne change rien, je pense.
Coté hyperviseur, ca me donne 2 avantages:

- Je n'ai pas besoin de créer une partition dont le seul but est de
  contenir le firewall.img (ou de le stocker à un autre endroit qui ne
  m'arrange pas plus que ca).

- si je veux faire un backup du firewall, maintenant que je me fais à
  l'idée que lvm gère des blocs, je peux stopper le firewall, faire un
  snapshot LVM de vg0/firewall_raw (ca prend 5 secondes en ayant
  préparé lv du snapshot en amont), redémarrer le firewall, puis faire
  tranquillement un dd de vg0/firewall_raw_snapshot avant de le
  détruire. J'ai bon ?



> > Et quelle que soit la solution retenue, est-ce que je pourrai
> > effectivement redimensionner les partitions de mes VMs facilement ?
> > (sinon, dans ce cas, LVM n'a pratiquement aucun intérêt pour
> > moi....)
> 
> Avec la solution décrite, l'host peut allouer plus de disque aux
> guest, et les guests gèrent eux même leurs partoches. Oui ça fait 2
> resize2fs mais si c'est que ça...

Ca fait au pire 2 resize, mais si par exemple je veux juste répartir
autrement à l'interieur d'un Dom0, le LVM du Dom0 n'est même pas
impacté....

Si je fais un resize au niveau du Dom0 (dans le bon sens), le LVM du
guest détecte l'augmentation/la diminution de taille du device
automatiquement au démarrage suivant, ou la manip est quand même plus
compliquée dans ce cas ?

Pour reprendre mon exemple, si je fais un:
xl shutdown VM1
lvextend -L+5G /dev/vg0/VM1_disk
xl create <...>/VM1.xl

il se passe quoi au niveau de ma VM ?
un 'vgdisplay vg_vm1' m'indiquera automatiquement la nouvelle taille ?
(je me doute que je devrai faire aussi un "lvextend
... /dev/vg_vm1/xxx" à un moment).


> > Et maintenant, la question subsidiaire, mon fameux gros /home....
> > A un moment, je voudrai peut être (probablement ?) rajouter un ssd
> > dans tout ca, dont le seul boulot sera de faire cache en lecture pour
> > ce /home...... via LVM.....
> 
> Pour ce qui est de l'ajout de cache disque: deux choix.
> Soit tu le mets dans le LVM d'en bas, tout le monde en profite*.

D'après ce que j'ai vu/compris, on ajoute un cache à un lv, pas à un
vg, non ?
Donc je l'ajouterais à vg0/VMNFS_HOME, et pas à vg0 ?

Et ca fonctionnerait, vu que LVM gère des blocs, donc lvmcache cache
des blocs, et non des fichiers d'un filesystem connu, c'est ca ? :)


> Soit tu ajoutes un disque/une grappe à ta VM storage, et tu ajoutes à
> ton LVM le /dev/sdb qui correspond à ton agregat de SSD.

Aussi, mais ca m'oblige à ce que ce /home soit lui aussi du LVM dans
du LVM, alors que c'était LE cas où je pouvais éventuellement faire
une seule couche de LVM.

Ou je fais l'inverse: le /home, je le file directement en md, il sera
donc de taille fixe (mais j'ai de la marge), je file aussi le device
du ssd et je fais du LVM uniquement au niveau de la VM........
Mais dans ce cas, je perds une partie de l'avantage du
redimensionnement à la volée pour mes autres images, vu que j'ai une
répartion fixe entre vg0 et le md du /home (donc soit je gaspille dans
vg0, soit un jour je le remplirai alors que j'aurai encore de la place
dans /home.....).



> * Par le profite, je n'ai aucune idée/métrique du gain atteignable en
> LVM par cette méthode. Par contre, je sais que ça marche bien en ZFS
> :emoji avec les yeux en coeurs:

Oui..... On en revient aux raisons dans mon autre post pour lesquelles
j'avais réfléchi à ZFS (et à FreeNAS en particulier) et pourquoi j'ai
finalement abandonné cette solution.....


> > Avant que je ne continue plus en détails dans les options tordues qui
> > me sont venues à l'esprit, quelqu'un a déjà fait ce genre de choses?
> 
> Moins tordues, mais à une époque je gérais quelques VMs sur du LVM
> comme ça. Donc j'avais du LVM sur LVM.

Ca me fait un retour d'expérience très intéressant !


> > Ou au moins des trucs un peu similaires, qui pourraient m'éclairer ?
> 
> :recherche d'image google^w^w duck duck go pour ampoule:

"ok" :)


> On te voit à l'AG? ;)

La, si je te demande "c'est quand", tu vas me répondre et à partir de
là commencer à te dire que je vais venir ? Ce qui ne serait pas tout à
fait impossible, mais pas plus probable que ca quand même, ca dépend
un peu aussi de la réponse à la question "c'est quand" :)




A +

VANHU.


Plus d'informations sur la liste de diffusion Liste-clx