Reprise du message précédent :
Hello,
 
Je dois migrer plusieurs VM (windows et debian) sur Xen entre différents Dom0. J'aimerais trouver un moyen rapide pour le faire.
 
Actuellement je fais des backups des paritions LVM avec dd et je zip le tout. J'aimerais éviter de multiplier les étapes (backup, transfert, et dézip sur le nouveau serveur).
 
J'ai essayée la commande suivante :
dd if=/dev/xenvg/MonLV | ssh MonHote "of=/dev/xenvg/LVDest"
Mais cela ne fonctionne pas, je récupère quasiment directement la main et aucun message ne s'affiche.
 
Avez vous déjà utilisé ce genre de commande ? Vous utilisez/utiliseriez quel méthode/outil pour ce genre de travail ?

y'a pas déjà un outil pour ça (migration d'une VM d'un dom0 à un autre) dans Xen ?

rsync, what else ?

Quoique pour les VMs Windows ça va pas être top
Mais sinon rsync
 
et pour dd, ça doit pouvoir se faire avec un petit netcat des familles
 
(au passage pour ton ssh, il manque le dd dans la commande sur la destination)

'TIN    
 
J'ai cherche une heure ce qui ne marchait pas ! Ça doit bien être le dd dans la commande de destination qui manque.
 
Sinon oui j'avais prévu d'utiliser rsync pour les debian.
 
Merci pour votre aide !

Pour l'outil de migration, si il existe, je n'en ai jamais entendu parler.
 
Mais ça m’intéresse.

 
En fait, avec Xen4 sous debian, tu peux faire des migrations live assez simplement, la condition, c'est d'avoir un stockage partagé sur tes 2 dom0.
J'ai pas vu de possibilité de migrer le disque automatiquement.
 
Sinon, pour speeder les transferts ssh, assure toi que la compression est bien activée dans ton transfert ssh (-C).  
Perso, je compresse les données avec gzip, et je décompresse de l'autre côté avec gunzip, ça devrait marcher:
dd if=/dev/xenvg/MonLV | gzip | ssh MonHote "gunzip | dd of=/dev/xenvg/LVDest"  
 
Tu peux aussi choisir le cipher (-c), on m'a conseillé arcfour qui utiliserait moins de cpu (-c arcfour).

 
Ptin c'est quand même beau Linux et son shell ça fait longtemps maintenant, mais je reste toujours autant émerveillé par cette puissance.

Je confirme
perso je fais ça sur un LAN: pas de compression et chiffrement rapide. J'avais benché les différents modes et c'est arcfour qui avait donné les résultats les + intéressants (50-60Mo/s sur du lien giga)
 
dd if=/dev/VGsrc/VM-disk bs=1M |ssh -c arcfour root@DEST dd of=/dev/VGdest/VM-disk bs=1M

Bah sur un LAN ou y a pas besoin de chiffrer du tout, utilise plutôt netcat

Alors je vais quoter un grand auteur:

Tu dois adapter ça à tes /dev/volmachin et tu peux aussi naturellement te passer de l'étape serveur et attaquer directement la cible depuis la source.

C'est intéressant pour mon cas parce que je n'ai pas la thune pour blinder mes VM de baie de stockage de classe militaire et je cherche toujours un moyen simple et fiable de monter du NFS haute dispo. Déjà DRBD je trouve pas ça simple et ça paraît trop sensible (fragile) pour être utilisé chez moi. Le raid 1 de device réseau vous avez essayé ?

P-NFS
http://www.pnfs.com/

http://www.snia.org/sites/default/ [...] v4-3_0.pdf
 

Je contre:
LUSTRE
www.lustre.org

Il y a l'informatique et l'informatique by microsoft

C'est vrai que le powershell c'est pas mal tu as raison

Je bosse dans un domaine de l'informatique ou microsoft a disparu depuis pas mal d'années alors  

 
J'ai une install lustre sympatoche au taff, on a 170To, et de mémoire, on monte à 3Go/s en read/write. Le truc, c'est que c'est performant et scalable, ça c'est clair. Par contre pour la fiabilité, j'y mettrai pas ma main au feu    
C'est spécialement intéressant pour faire un filesystem scratch dans un cluster de calcul, où on ne garantit pas les données sur le long terme (voire on purge automatiquement tous les fichiers vieux de plus de x jours).

Le but de Lustre n'est pas la fiabilité mais les performances. La redondance doit être assurée au niveau des disques.
 
Dans les clusters on utilise des systèmes de données hiérarchiques: en fonction de la fréquence d'utilisation les données sont migrées automatiquement vers le niveau suivant. D'abord Lustre ou équivalent pour les perf puis un deuxième niveau un peu moins perf pour les données à quelques jours et enfin les bandes pour la longue durée.
Avec du Lustre j'ai déjà vu du 500go/s en read/write
\HS

Oracle ne supporte quasi plus le projet. Les dev ont monté leur propre boite.

Vous tombez bien je fais des tests sur GlusterFS aujourd'hui ou demain

Pré-étude : opé sur les « gros » fichiers (> 100ko), très belles perfs à la fois en read et en write (même si plutôt réputé pour les vitesses en read). Niveau simplicité d'utilisation, difficile de faire mieux.
Le seul « problème », à revalider avec 4 noeuds, c'est la décompression d'une tarball de noyau Linux : entre le fs local et celui de GlusterFS, on a bien un ordre de grandeur de différence..

Est-ce que c'est vraiment un problème pour stocker du fichier « users » ou du gros espace de stockage ? Je pense pas, à creuser encore donc

Mais pratiquement ça veut dire qu'on ne gère pas la perte d'un nœud ? On se contente d'en ajouter quand ils tombent ?

 
Soit tu le fais remonter (et il se resynchro), soit tu le remplace (plus long à resychro mais ça marcherai quand même)

 
j'allais le dire  
 

 
il manque un petit pipeview pour avoir le débit en live
 

 
Panasas
Isilon
 

 
je surcontre
GPFS

Va falloir créer un topic unique FS distribués voir HPC

 
Je t'en prie

Ouai enfin si on est 3 clampins...

fous "Apple" dans le titre, ça va remplir le topic.

Un cluster de mac book pro
Le cluster le plus cher du monde

Hello,

On a fait quelques tests également par ici sur gluster. Quelques conclusions (corroborées par les dires sur la ML GlusterFS) :
- Pour faire du filer "bureautique" ca roule.
- Pour les gros fichiers (>100 Go soit un disque d'une vm), ca patine dans la choucroute. Débit très faible de quelques ko
- Les accès concurents sont pas au top ...

=> En conclusion ce n'est pas forcément très adapté à la virtu, surtout avec un minimum d'activité. D'ailleurs dans la roadmap de gluster est indiqué la volonté d'améliorer les perfs pour la virtu, sur les gros fichiers et les accès concurents.

Actuellement on teste également mooseFS .. interessant

Concernant lustre, l'objectif est clairement la performance et il ne gère pas la redondance.

ps : j'avais lancé un topic à une époque de FS distribué/réparti/performance mais sans beaucoup d'émultion dessus
ps2 : actuellement le support côté client sur RHEL du pNFS est dispo en "preview" uniquement.  Les constructeurs commencent seulement à implémenter le pNFS sur le tête NAS. Je suis en tout cas impatient de pouvoir jouer avec et voir les implémentations

Autres sujets : sur les kernel 2.6.X, avec un FS journalisés, sous fortes charges (load > 1000) et avec beaucoup d'IO (>50k), le kernel plante (kernel panic). C'est un bug  dans la journalisation, corrigé sur la branche 3.X.

load > 1000

Pour nos tests on a un tentinet chargé la mule xD Ca permet de pousser les systèmes aux extrèmes, c'est chouette
Bien sur dans la vie de tous les jours ...

Du coup le test est-il bien pertinent ?

J'en viens aux mêmes conclusions. Pour la virtu, je pense fortement aujourd'hui sur du ZFS avec NFS (et du zfs send sur une deuxieme serveur quasi hot spare à quelques minutes près).

Par contre, je me demande bien quel paramétrage utiliser dans la conf de mes VM (file, tap, blktap2 ?) pour avoir de bonnes perfs. Car j'ai absolument pas l'habitude de bosser en fichier pour les HDD des vm (LVM depuis le début )

Des conseils ?

Salut,

L'aventage du fichier est sa simplicité de gestion. Les perfs sont bonnes (5/10% de pertes sur du heavy IO par rapport à du FC en direct). En format, soit du raw soit du qcow2. Ce dernier proposant plus de fonctionnalités (snap principalement) mais avec une toute chtite perte de perf.
Sur ZFS je n'ai pas d'avis ...

edit : sous KVM hein

Oui, ca permet de voir si ca explose ou non : au sens perte de données ? perte d'accès ? etc... même si effectivement le service au sens utilisateurs n'est plus utilisable depuis belle lurette

Et si tu cherches pas les limites comment les connaitres ?

 
À voir sur Xen donc

 
   
 
Je pense pas que ca change énormément sur les principes