Re: xen + debian lenny + sauvegarde VM
Le 01/01/2011 15:01, Jean Baptiste FAVRE a écrit :
> 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
D'acc, merci :-)
Reply to: