Re: xen + debian lenny + sauvegarde VM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 01/01/2011 14:32, Thierry B a écrit :
> Le 01/01/2011 13:40, Jean Baptiste FAVRE a écrit :
>> Tout dépend de ce que tu utilises. Mais dans le cas d'un LVM, un
>> snapshot VM arrêté suivi d'un gros dd est amplement suffisant :-)
>> Tu obtiens une image disque que tu peut restaurer sur ton nouveau LV.
>>
>> Ou alors tu joues avec des fichiers images et tu peux même utiliser le
>> Copy-On-Write (QCOW).
>> Du coup ton image de base ne change jamais et chacun de tes domU
>> n'utilise en espace disque que le delta avec l'image de base.
>
> Ok donc ton domU vu depuis le dom0 est soit
> - un LV : sauvegarde avec dd par exemple
> - une image de base et là tu peux utiliser la Copy On Write (je sais pas
> trop encore ce que c'est lol)
>
> Pourquoi l'image ne changerait pas?
> Si tu installes des nouveaux paquets dans ton domU par exemple, l'image
> va grossir ou bien l'espace utilisé par le LV depuis dom0 va augmenter
> aussi non?
Il faut considérer l'image de base comme le plus petit dénominateur
commun à tous tes domU (en gros, une install "système de base" debian).
Le Copy-On-Write est aux fichiers image ce que le snapshot est à LVM: le
snapshot initial prend très peu de place. Il va dériver au fil du temps
puisque chaque modif dans le LV d'origine provoque la modif inverse dans
le snapshot.
Dans le cas de images, si l'image en lecture seule est le système de
base, l'image en écriture contiendra toutes les modifications de conf et
les paquets supplémentaires que tu auras installé: exemple d'un serveur
Web, le serveur HTTP n'est pas présent dans l'image de base, mais il est
ajouté dans l'image spécifique au domU.
>>
>>>> Reste le problème des data: de mon point de vue, il faut séparer les
>>>> partitions data du système. Donc par exemple un LV data dédié. Du coup,
>>>> on fait les backups depuis le domU.
>>
>>> Ouais, j'ai essayé de séparer le data du système mais en créeant le LV
>>> data coté dom0 : par exemple, un LV pour stocker le mail, un autre pour
>>> le web et ensuite ces LV sont mappés vers des partitions virtuelle
>>> xdva1,2...
>>
>>> Si les backups sont justement sur le domU, j'ai du mal à voir comment en
>>> cas de crash de la VM, tu peux récupérer ces backups vu qu'ils sont dans
>>> le domU?
>>
>> Euh... Le fait que tu sois en environnement virtualisé ou non ne change
>> rien au besoin de gestion des backups.
>> Que tu fasse les backups depuis le dom0, depuis un domU dédié ou dans
>> chaque domU ne change rien au problème: il faut les séparer des data
>> d'origine.
>>
>> Chez moi, j'ai un domU dédié aux backup qui dispose d'un accès NFS sur
>> un NAS. Quand j'ajoute une machine (domU ou non) J'ai juste besoin
>> d'ajouter le nom de la machine à la liste des backups à faire.
>> Ensuite, tous mes serveurs et domU sont organisés de la même façon:
>> installation en PXE avec preseed + configuration par Puppet. Tout est
>> dans /data. Du coup, pas de questions existentielles à se poser pour
>> savoir quoi backuper:
>> /etc (au cas où, même si en fait je n'en ai pas besoin grâce à Puppet)
>> /data
>> /home
>> /usr/local (pour les scripts que j'ajoute. Là encore, en fait pas besoin
>> car déployé par Puppet)
>>
>> Les backups sont faits avec rdiff-backups et stockés sur le NAS.
>>
>> Et voilà :-)
>
> Euh pas compris cette histoire de /data.
> /data est monté à partir d'une partition qui se trouve où? sur ton dom0,
> sur chaque domU?
En fait peu importe: soit tu fais un LV particulier dans le dom0 que tu
"exporte" au niveau du domU (le plus propre selon moi), soit tu fais un
LV ou une partition à l'intérieur du domU.
> Par exemple pour le mail, j'ai un LV Mail crée depuis le dom0 et depuis
> le domU dédié, ce LV est vu comme une partition virtuelle.
Donc tu utilises mon premier exemple
> Donc ces datas là, pour le moment, je les sauvegarde depuis le dom0 dans
> le dom0.
>
> Si je voulais sauvegarder ces datas dans un domU, faudrait que je linke
> ce LV là (qui a été crée coté dom0), dans le domU à partir duquel je
> souhaite faire la sauvegarder de ces datas.
> Mais du coup, si je fais ma sauvegarde depuis le domU, la sauvegarde
> sera stockée dans le domU.
Rien ne t'empêche de faire un snapshot depuis ton domU s'il est installé
en LVM. En revanche, il faut toujours sortir les data du domU, d'où
l'intérêt d'avoir une machine (virtuelle ou non) qui soit dédiée à cela.
Tu ne peux pas linker 1 LV sur 2 domU (sauf avoir un FS cluster, mais de
toute façon je ne pense pas que Xen te l'autorise).
En revanche, rien ne t'empêche de faire un rsync depuis un autre domU
(man rdiff-backup :) )
> Si tu as un peu de temps à l'occcasion, tu pourrais me donner un exemple
> concret et simple (création d'un LV toto depuis tel domX...) pq j'ai
> toujours du mal à voir comment ta conf marche lol.
Ma conf n'a rien de sorcier: je fais en virtualisé ce que je faisais
déjà en physique: un serveur se charge de backuper tous les autres et
stocke les backup sur un NAS.
Au pire, pour "optimiser", tu peux considérer que les domU sont
"jetables" (surtout avec Puppet ou équivalent). Du coup, il vaut
peut-être mieux que chaque domU se charge de pousser ses backups sur le
domU de backup.
Quelques doc que j'ai écrit à propos de Xen:
http://publications.jbfavre.org/virtualisation/xen_lvm_drbd_debian
http://publications.jbfavre.org/virtualisation/cluster-xen-corosync-pacemaker-drbd-ocfs2.fr
Je n'ay aborde pas tellement les aspects backup, mais encore une fois,
que l'on soit en virtuel ou en physique ne change rien au problème: il
faut backuper et centraliser les sauvegardes hors des serveurs de data.
Cordialement,
JB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0fM88ACgkQM2eZoKJfKd3f/ACfSzXLRiYgQ0lk6wZ+ZFX091V2
5RIAoLr+YMa3fPl2AmPOwW/LAgPRIl80
=3EzC
-----END PGP SIGNATURE-----
Reply to: