Le 14972ième jour après Epoch,
Thierry B. écrivait:Le 28/12/2010 10:51, Thierry B a écrit :Bonjour,
Je voulais savoir si quelqu'un utilisait une config serveur xen + debian
lenny à partir de laquelle il fait des sauvegarde VM régulières?
Sur ma dedibox, j'utilise une lenny avec xen de testing et pour ma
sauvegarde de VM, je fais un script qui pour résumer fait :
- xm pause
- Création d'un LV snapshot à partir du LV de la VM
- xm unpause
Qu'en pensez-vous?
Avant le xm pause / unpause, c'etait xm save VM / xm restore VM, mais
une fois, lors de l'exécution automatique du script, j'ai eu un
plantage à cause de cela, et j'ai du redémarrer ma machine physique
carrement pour pouvoir redemarrer ma VM, le pause /unpause a l'air moins
méchant...
Sinon, y'a aussi la solution, de faire un shutdown et de la relancer
mais bon, c'est p-e pas top pour une config serveur non?
J'attends vos avis.
Merci :-)
Hello,
A priori, ça ne fonctionne pas trop mal en essayant de restaurer cela
sur un autre domU.
Le soucis, c'est qu'il n'arrive pas à démarrer clamav et il me dit qe ce
n'est pas clean niveau mysql.
Je fais ça pour migrer des DomU d'un Dom0 à un autre, avec un
save/restore, et ça marche très bien...
D'ailleurs, durant le "save", le DomU est renommé de "<name>" à
"migrate-<name>" ... C'est un signe, hein?
Perso, je n'ai pas eu de soucis majeurs avec save/restore, sauf la fois
où j'avais oublié de mettre les mêmes noyaux sur les Dom0 :(
Je n'ai jamais essayé avec pause/unpause, mais je ne le ferais pas, car
la doc indique que:
When in a paused state the domain will still consume
allocated resources such as memory, but will not be eligible
for scheduling by the Xen hypervisor.
Ça signifie que ce qui est en mémoire ne peut pas être sauvé, et que les
tampons disque (du DomU) ne sont pas forcément à jour.
Voilà.
Le 14972ième jour après Epoch,
Thierry B. écrivait:
Le 28/12/2010 10:51, Thierry B a écrit :
Bonjour,
Je voulais savoir si quelqu'un utilisait une config serveur xen + debian
lenny à partir de laquelle il fait des sauvegarde VM régulières?
Sur ma dedibox, j'utilise une lenny avec xen de testing et pour ma
sauvegarde de VM, je fais un script qui pour résumer fait :
- xm pause
- Création d'un LV snapshot à partir du LV de la VM
- xm unpause
Qu'en pensez-vous?
Avant le xm pause / unpause, c'etait xm save VM / xm restore VM, mais
une fois, lors de l'exécution automatique du script, j'ai eu un
plantage à cause de cela, et j'ai du redémarrer ma machine physique
carrement pour pouvoir redemarrer ma VM, le pause /unpause a l'air moins
méchant...
Sinon, y'a aussi la solution, de faire un shutdown et de la relancer
mais bon, c'est p-e pas top pour une config serveur non?
J'attends vos avis.
Merci :-)
Hello,
A priori, ça ne fonctionne pas trop mal en essayant de restaurer cela
sur un autre domU.
Le soucis, c'est qu'il n'arrive pas à démarrer clamav et il me dit qe ce
n'est pas clean niveau mysql.
Je fais ça pour migrer des DomU d'un Dom0 à un autre, avec un
save/restore, et ça marche très bien...
D'ailleurs, durant le "save", le DomU est renommé de "<name>" à
"migrate-<name>" ... C'est un signe, hein?
Perso, je n'ai pas eu de soucis majeurs avec save/restore, sauf la fois
où j'avais oublié de mettre les mêmes noyaux sur les Dom0 :(
Je n'ai jamais essayé avec pause/unpause, mais je ne le ferais pas, car
la doc indique que:
When in a paused state the domain will still consume
allocated resources such as memory, but will not be eligible
for scheduling by the Xen hypervisor.
Ça signifie que ce qui est en mémoire ne peut pas être sauvé, et que les
tampons disque (du DomU) ne sont pas forcément à jour.
Voilà.
Le 14972ième jour après Epoch,
Thierry B. écrivait:Le 28/12/2010 10:51, Thierry B a écrit :Bonjour,
Je voulais savoir si quelqu'un utilisait une config serveur xen + debian
lenny à partir de laquelle il fait des sauvegarde VM régulières?
Sur ma dedibox, j'utilise une lenny avec xen de testing et pour ma
sauvegarde de VM, je fais un script qui pour résumer fait :
- xm pause
- Création d'un LV snapshot à partir du LV de la VM
- xm unpause
Qu'en pensez-vous?
Avant le xm pause / unpause, c'etait xm save VM / xm restore VM, mais
une fois, lors de l'exécution automatique du script, j'ai eu un
plantage à cause de cela, et j'ai du redémarrer ma machine physique
carrement pour pouvoir redemarrer ma VM, le pause /unpause a l'air moins
méchant...
Sinon, y'a aussi la solution, de faire un shutdown et de la relancer
mais bon, c'est p-e pas top pour une config serveur non?
J'attends vos avis.
Merci :-)
Hello,
A priori, ça ne fonctionne pas trop mal en essayant de restaurer cela
sur un autre domU.
Le soucis, c'est qu'il n'arrive pas à démarrer clamav et il me dit qe ce
n'est pas clean niveau mysql.
Je fais ça pour migrer des DomU d'un Dom0 à un autre, avec un
save/restore, et ça marche très bien...
D'ailleurs, durant le "save", le DomU est renommé de "<name>" à
"migrate-<name>" ... C'est un signe, hein?
Perso, je n'ai pas eu de soucis majeurs avec save/restore, sauf la fois
où j'avais oublié de mettre les mêmes noyaux sur les Dom0 :(
Je n'ai jamais essayé avec pause/unpause, mais je ne le ferais pas, car
la doc indique que:
When in a paused state the domain will still consume
allocated resources such as memory, but will not be eligible
for scheduling by the Xen hypervisor.
Ça signifie que ce qui est en mémoire ne peut pas être sauvé, et que les
tampons disque (du DomU) ne sont pas forcément à jour.
Voilà.
L'avantage je trouve de gérer ça depuis le dom0, c'est que l'on eff ectue
la sauvegarde que depuis le dom0
Enfin je veux dire que meême si pon fait des snapshots dans un domU,
faut bien aussi faire une seconde sauvegarde depuis le dom0 pour
sauvegarder la VM en tant que tel non?
L'avantage je trouve de gérer ça depuis le dom0, c'est que l'on eff ectue
la sauvegarde que depuis le dom0
Enfin je veux dire que meême si pon fait des snapshots dans un domU,
faut bien aussi faire une seconde sauvegarde depuis le dom0 pour
sauvegarder la VM en tant que tel non?
L'avantage je trouve de gérer ça depuis le dom0, c'est que l'on eff ectue
la sauvegarde que depuis le dom0
Enfin je veux dire que meême si pon fait des snapshots dans un domU,
faut bien aussi faire une seconde sauvegarde depuis le dom0 pour
sauvegarder la VM en tant que tel non?
Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)
Hello,
Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:
- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.
- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :
Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)
Hello,
Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:
- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.
- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)
Hello,
Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:
- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.
- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Bonsoir,
Le 31/12/2010 18:31, Thierry B a écrit :Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)Hello,Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Tout dépend comment elle est installée :)
Dans le meilleur des mondes, on s'en fout: toute la conf est gérée par
Puppet ou CFEngine, donc tu as juste besoin d'un template de VM de base.
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.
Si la VM plante, on en démarre une nouvelle, on raccroche le LV data et
c'est reparti.
C'est par exemple le modèle Amazon.
Au pire, tu fais une sauvegarde de la VM une fois installée/configurée
au petits oignons. Du coup, plus besoin de faire de sauvegarde (sauf si
changement de conf !). Et tu as juste besoin de faire les maj de paquets
audn tu en démarres une nouvelle.Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Encore une fois, je n'aime pas bcp les backups depuis le dom0
Aller, dernier mail de l'année :)
Bon réveillon à toutes et à tous,
JB
Bonsoir,
Le 31/12/2010 18:31, Thierry B a écrit :
Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :
Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)
Hello,
Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Tout dépend comment elle est installée :)
Dans le meilleur des mondes, on s'en fout: toute la conf est gérée par
Puppet ou CFEngine, donc tu as juste besoin d'un template de VM de base.
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.
Si la VM plante, on en démarre une nouvelle, on raccroche le LV data et
c'est reparti.
C'est par exemple le modèle Amazon.
Au pire, tu fais une sauvegarde de la VM une fois installée/configurée
au petits oignons. Du coup, plus besoin de faire de sauvegarde (sauf si
changement de conf !). Et tu as juste besoin de faire les maj de paquets
audn tu en démarres une nouvelle.
Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:
- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.
- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Encore une fois, je n'aime pas bcp les backups depuis le dom0
Aller, dernier mail de l'année :)
Bon réveillon à toutes et à tous,
JB
Bonsoir,
Le 31/12/2010 18:31, Thierry B a écrit :Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)Hello,Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Tout dépend comment elle est installée :)
Dans le meilleur des mondes, on s'en fout: toute la conf est gérée par
Puppet ou CFEngine, donc tu as juste besoin d'un template de VM de base.
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.
Si la VM plante, on en démarre une nouvelle, on raccroche le LV data et
c'est reparti.
C'est par exemple le modèle Amazon.
Au pire, tu fais une sauvegarde de la VM une fois installée/configurée
au petits oignons. Du coup, plus besoin de faire de sauvegarde (sauf si
changement de conf !). Et tu as juste besoin de faire les maj de paquets
audn tu en démarres une nouvelle.Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Encore une fois, je n'aime pas bcp les backups depuis le dom0
Aller, dernier mail de l'année :)
Bon réveillon à toutes et à tous,
JB
Le 31/12/2010 21:06, Jean Baptiste FAVRE a écrit :Bonsoir,
Le 31/12/2010 18:31, Thierry B a écrit :Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)Hello,Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Tout dépend comment elle est installée :)
Dans le meilleur des mondes, on s'en fout: toute la conf est gérée par
Puppet ou CFEngine, donc tu as juste besoin d'un template de VM de base.
Un template de VM sous forme d'un LV ou fichier image?
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?
Si la VM plante, on en démarre une nouvelle, on raccroche le LV data et
c'est reparti.
C'est par exemple le modèle Amazon.
Au pire, tu fais une sauvegarde de la VM une fois installée/configurée
au petits oignons. Du coup, plus besoin de faire de sauvegarde (sauf si
changement de conf !). Et tu as juste besoin de faire les maj de paquets
audn tu en démarres une nouvelle.Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Encore une fois, je n'aime pas bcp les backups depuis le dom0
Aller, dernier mail de l'année :)
Bon réveillon à toutes et à tous,
Bonne année 2011 :-)
Le 31/12/2010 21:06, Jean Baptiste FAVRE a écrit :
Bonsoir,
Le 31/12/2010 18:31, Thierry B a écrit :
Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :
Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)
Hello,
Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Tout dépend comment elle est installée :)
Dans le meilleur des mondes, on s'en fout: toute la conf est gérée par
Puppet ou CFEngine, donc tu as juste besoin d'un template de VM de base.
Un template de VM sous forme d'un LV ou fichier image?
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?
Si la VM plante, on en démarre une nouvelle, on raccroche le LV data et
c'est reparti.
C'est par exemple le modèle Amazon.
Au pire, tu fais une sauvegarde de la VM une fois installée/configurée
au petits oignons. Du coup, plus besoin de faire de sauvegarde (sauf si
changement de conf !). Et tu as juste besoin de faire les maj de paquets
audn tu en démarres une nouvelle.
Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:
- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.
- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Encore une fois, je n'aime pas bcp les backups depuis le dom0
Aller, dernier mail de l'année :)
Bon réveillon à toutes et à tous,
Bonne année 2011 :-)
Le 31/12/2010 21:06, Jean Baptiste FAVRE a écrit :Bonsoir,
Le 31/12/2010 18:31, Thierry B a écrit :Le 31/12/2010 15:48, Jean Baptiste FAVRE a écrit :Qu'en pensez-vous ?
J'en pense que, pour ma part, moins j'en mets dans le dom0, mieux je me
porte. Le dom0 est là pour gérer les VM, pas les backups. La solution
domU dédié aux backups me paraît plus "propre".
Au pire, il peut être intéressant pour les paranos comme moi de
s'inspirer de Qubes-OS qui déporte la gestion du stockage dans un domU :)
Un snapshot d'un FS en cours d'utilisation impose un fsck à un moment ou
à un autre. Si en plus il est fait hors du domU (donc par exemple depuis
le dom0 soit "sous" le domU) , il n'y a aucun moyen "élégant" (c-a-d
hors SSH) de dire au domU de synchroniser ses disques juste avant de
faire le snapshot. Ajoutez à cela les différents rôles que peuvent
prendre un domU (MySQL, HTTP, ...) et vous aurez vite un script façon
usine à gaz.
Ce n'est que mon avis, mais je le partage :)Hello,Tu gérerais comment ensuite la sauvegarde de la VM proprement parlé dans
cette hypothèse?
Tout dépend comment elle est installée :)
Dans le meilleur des mondes, on s'en fout: toute la conf est gérée par
Puppet ou CFEngine, donc tu as juste besoin d'un template de VM de base.
Un template de VM sous forme d'un LV ou fichier image?
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?
Si la VM plante, on en démarre une nouvelle, on raccroche le LV data et
c'est reparti.
C'est par exemple le modèle Amazon.
Au pire, tu fais une sauvegarde de la VM une fois installée/configurée
au petits oignons. Du coup, plus besoin de faire de sauvegarde (sauf si
changement de conf !). Et tu as juste besoin de faire les maj de paquets
audn tu en démarres une nouvelle.Finalement, je me dis que pour mon utilisation de cette VM, une fois que
tout sera bien installé, plus trop besoin d'installer de nouvelles
choses, donc par exemple, je pourrais faire:- une sauvegarde avec shutdown + lv snapshot de temps en temps en cas
d'install de nouveaux paquets avec donc une interruption de service de
la VM d'une minute ou deux peut-etre.- des synchrpnisations de ce qui change de façon quotidienne, comme les
logs, les mails...
Encore une fois, je n'aime pas bcp les backups depuis le dom0
Aller, dernier mail de l'année :)
Bon réveillon à toutes et à tous,
Bonne année 2011 :-)
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.
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à :-)
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.
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à :-)
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.
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à :-)
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?
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?
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 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.
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.
zC
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?
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?
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 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.
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.
zC
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?
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?
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 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.
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.
zC
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 exempleDonc 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
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
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 exempleDonc 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