Fichier vmdk et snapshot

[Abneits]

Bonjour,

J'aurais aimé vous poser plusieurs questions.

1°) Lorsque l'on créer un snapshot, la VM utilise donc le fichier delta associé à celui-ci en enregistrant les modifications etc ... Ma question est, dans quelles mesures utilise t-elle le fichier originel .vmdk (lecture, écriture, ou pas du tout) ? Les I/O sur celui-ci sont elles élevés par rapport au fichier Delta ?

2°) Toujours dans le cas ou j'ai au moins un snapshot de créer, puis-je zipper mon .vmdk originel sans soucis à chaud ?

3°) Dans le cas ou un problème survient et que je ne puisse la restaurer pour quelque conque raison à partir des snapshots ? Puis-je relancer directement mon .vmdk ?

Je vous pose ces questions car j'ai une refonte de l'architecture réseau à faire dans mon service et j'aurais aimé mettre en place ceci.

J'ai un ESX et un NAS, 60VM de 80GO chacune dont 15 qui doivent tourner simultanément. J'ai beaucoup plus de places sur le NAS que l'ESX bien entendu.

J'aurais aimé héberger sur le NAS uniquement les .vmdk de mes machines et sur l'ESX au minimum 5 snapshots par VM. J'ai deux ports gigabit pour les deux, dont un est utilisé pour les relié en direct, le deuxième ports étant réservé à l’accès pour le reste du réseau.

J'espère avoir été assez clair et vous remercie par avance,

Cordialement,

[Mandraxx]

Bonjour,

Je ne suis pas un spécialiste de VMWare mais voici un petit retour d'expérience sur quelques tests :

1. Un snapshot se comporte un peu comme un rollback segment de base de données : le VMDK est alors figé en l'état et toutes les modifications apportées sont écrites dans le snap. En revanche, la lecture nécessite les deux fichiers (le VMDK et le snap) pour offrir une vue cohérente de l'environnement.

2. Corolaire du 1 : non, ESX a besoin du VMDK pour les opérations de lecture donc il faut le conserver actif. Donc le zipper à chaud après snapshot pour sauvegarde, pourquoi pas en fonction de l'OS du host (mais je pense quand même que c'est dangereux). Quant à espérer zipper le VMDK pour gagner en espace disque.... Pas possible. A savoir que les VMDK sont des fichiers creux donc un disque de 80Go avec 10Go de données n'occupera qu'un peu plus de 10Go.

3. Théoriquement, supprimer les fichiers snapshots revient à restaurer au point de sauvegarde donc, oui : le système devrait repartir depuis le VMDK mais en perdant toutes les modifs effectuées depuis la prise du snapshot (j'ai jamais testé ça )

Concernant l'archi, la virtualisation en général est très gourmande en termes d'I/O, un NAS est donc généralement sous-dimensionné par rapport au besoin d'hébergement de 60 guests : j'aurai tendance à conseiller plutôt un SAN (technos fiber channel) qui permet souvent de ne plus créer des VMDK mais d'émuler un disque sur un LUN iSCSI pour faire abstraction d'un paquet de couches logicielles...

Cela est bien entendu à pondérer en fonction du nombre d'utilisateurs et des applications : si les besoins en I/O sont faibles (moteurs de calcul pur), un NAS peut suffire. En cas d'hébergement de données avec beaucoup d'utilisateurs, ça risque à coincer....

@+

[Abneits]

Merci beaucoup pour tes réponses,

Justement, dans un soucis de performances je voulais mettre mes .vmdk sur un NAS et les delta disk directement sur le serveurs, ces derniers devant en théorie prendre le plus d'I/O. Le .vmdk étant logiquement sollicité uniquement en lecture, je me disais qu'un NAS en gigabit dédié était suffisant, les VM étant des machines de test avec un seul voir deux utilisateurs maximum.

Le faite que le .vmdk soit uniquement lu ne permet pas de zipper à chaud la VM ? Je pensais qu'il n'y avais pas de soucis.

Mon idée était de faire un roulement de 5 snapshots dont un par semaine ainsi que la sauvegarde du .vmdk tout les mois, en le zippant justement,

La technologie étant hors de prix pour l'utilisation de test que nous faisons pour ces machines.

Merci,