L'exécution permanente dans un instantané VMWare est-elle mauvaise pour les performances?

Je comprends que la base de connaissances VMWare fronce les sourcils sur les instantanés de longue durée, principalement en raison de deux choses (à mon avis)

Prendre des tonnes d'instantanés peut remplir le magasin de données. Les instantanés sont simplement des fichiers delta. Disons que vous avez un VMDK 50 Gig, presque plein, et que vous prenez un instantané. Dans votre instantané, vous retournez chaque bit. Votre fichier delta sera également d'environ 50 Go. Snapshot à nouveau, retournez les bits, un autre fichier delta de 50 Gig. Ceux-ci peuvent rapidement devenir incontrôlables.
Commettre de grands instantanés comporte des risques. Lors de la consolidation des instantanés, vous écrivez les modifications delta dans le VMDK d'origine. Cela prend du temps et comporte le risque que si quelque chose se produit, vous venez de neutraliser votre VMDK.

Leurs avertissements semblent logiques.

Cela étant dit, est-il intrinsèquement mauvais d'exécuter ma machine en permanence à partir d'un VMDK instantané? Je veux faire de mon arbre ce qui suit:

Base
- Snap1
  - Snap 2
  - Tu es là

Les snap 1 et 2 seront pris immédiatement après l'installation et l'approvisionnement du système de base. Ce sont des machines que je prévois de rafraîchir fréquemment, je vais donc simplement faire ressembler mon arbre à ceci:

Base
- Snap1
  - Tu es là
  - Snap 2

Supprimez Snap2 et recréez Snap2.

Je ne vois pas comment cela pourrait avoir des implications pour les raisons suivantes:

Étant donné que j'ai simplement installé une image de base et pris mes deltas immédiatement après, il n'y a aucun moyen de remplir le magasin de données. En supposant que mon image de base n'est que de 10 Go (sur un disque provisionné fin de 50 Go), même si mon delta a inversé chaque bit, mon utilisation totale maximale pourrait être de 60 Go (10 Go de base VMDK qui est verrouillé + 50 Go de delta dans le fichier instantané VMDK). Cela suppose que je ne crée pas d'autres instantanés.
Étant donné que mon cas d'utilisation n'appelle pas à la consolidation des instantanés, je ne risque pas d'erreurs lors de la consolidation de mes deltas. Lorsque je reviens à Snap1 et que je supprime Snap2, tout le delta qui résidait dans Snap2 est simplement supprimé.
La charge de stockage est exactement la même, donc je devrais obtenir le même IOPS. Je comprends que certains fichiers (principalement des fichiers système) existeront sur le VMDK d'origine et d'autres (tout après la base) résideront dans le delta, mais je ne vois pas comment ESXI s'en soucierait. Tous les fichiers se trouvent sur la même banque de données physique, donc les performances doivent être équivalentes à tout référencer dans le VMDK d'origine sans instantanés.

Des pensées? ESXI 5.5 avec le magasin de données étant RAID DAS.

Je n'ai pas de licence vCenter, donc les modèles et le clonage sont hors de propos.

RÉSULTATS DU TEST

Je suis arrivé tôt aujourd'hui pour effectuer des tests. Voici les résultats. Il y a une pénalité de performance mais je ne sais pas pourquoi.

Avant d'instantanés: Avant l'instantané

Après l'instantané: Après la prise de vue

— VM_Storage_Inception
source

Pas surement - avec le temps, les instantanés divergent de plus en plus. Enfin, il s'agira essentiellement d'exemplaires différents. Une fois que vous n'avez pas épargné beaucoup de disque en les prenant en instantanés, convertissez l'instantané en un volume complètement séparé. Comment? Normalement, j'utilise dd d'une troisième VM, mais la plupart du temps, je suis presque crucifié ici pour de telles opinions hérétiques, comme celle-ci. :-) Mais: cela fonctionnera et sera efficace .

— peterh

@ PeterHorvath - C'est ce que j'aime entendre. Solutions intelligentes, hacky, efficaces et dépouillées. Si cela ne vous dérange pas, pourriez-vous me donner un compte rendu sur ce que vous faites dans la boîte à pâte ou quelque chose? Avez-vous DD le VMDK et l'instantané ensemble?

— VM_Storage_Inception

Si je devais le faire plus souvent, je l'ai fait avec un script. Mais ce n'est pas le cas, et dans la plupart des cas, je n'utilise même pas de snapshpts, car ils sont lents.

— peterh

Réponses:

Oui, il existe des implications en termes de performances pour les instantanés de longue durée. La consolidation des VMDK delta dans le fichier disque d'origine a des implications encore plus importantes. Cela peut entraîner une absence de réponse dans le système d'exploitation de votre machine virtuelle ou d'autres comportements indésirables.

VMware intègre des fonctionnalités de création de modèles et de clonage dans vCenter. Vous avez besoin d'une licence vSphere Essentials de 600 $ pour l'activer.

Vous pouvez créer une machine virtuelle à votre goût, puis la cloner dans un modèle. Ce modèle peut ensuite être utilisé pour générer de nouvelles machines virtuelles à partir d'une image "Golden Master".

entrez la description de l'image ici

Cela vous permet d'avoir un "état propre" mais également de créer des machines virtuelles permanentes ou de longue durée à partir de cette image principale. Aucun instantané nécessaire.

— ewwhite
source

Intéressant, je vais examiner cela et voir comment cela fonctionne. Malheureusement, je n'ai pas de licence vCenter et je préférerais que mon organisation ne paie pas les 600 $ s'il n'y a aucune incidence sur les performances des instantanés utilisés de la manière que je décris. De plus, le modèle et le clonage ne semblent pas différents de la prise d'un OVA et de son redéploiement. La suppression des instantanés semble beaucoup plus rapide et je ne peux pas logiquement voir comment il y aurait des implications en termes de performances même si ce n'est pas la "méthode officielle approuvée par VMWare".

— VM_Storage_Inception

Pour répondre à votre montage, pourriez-vous me pointer vers un article ou expliquer quelles seraient les implications en termes de performances? Je ne vois pas comment il y en aurait en supposant que je les utilise comme je les décris. De plus, je ne consoliderais jamais les instantanés vers le VMDK d'origine.

— VM_Storage_Inception

Je suppose que j'essaie de comprendre pourquoi vous insistez pour concevoir une fonctionnalité destinée à un accès à court terme.

— ewwhite

@VM_Storage_Inception - on dirait presque que vous voulez une approche de pauvre homme pour le défunt Lab Manager de VMWare.

— TheCleaner

Parfois, acheter la bonne solution est logique. Vous avez consacré plus d' efforts et d'heures de travail à rechercher une solution de contournement que de simplement payer pour une licence vSphere Essentials (600 $), ce qui vous donnerait une option de modèle / clonage prise en charge.

— ewwhite

La réponse d'ewwhite est correcte, mais juste pour développer un peu plus ou la pénalité de performance, considérez le scénario suivant:

Vous créez une machine virtuelle. Une lecture virtuelle à partir du vmdk prend une lecture de disque physique de la même taille. Assez simple.

Imaginez maintenant que vous preniez un instantané de la machine virtuelle. Maintenant, pour chaque lecture virtuelle, vous allez subir 2 lectures physiques, l'une à partir du vmdk de base et l'autre à partir du vmdk delta, car vous avez besoin d'informations des deux pour obtenir l'état actuel. Vous êtes maintenant à deux fois le nombre de lectures de disque physique.

Pour deux instantanés, vous effectuez trois fois les lectures, etc. Si vous avez beaucoup d'instantanés, vous pouvez voir comment cela peut être une pénalité de performance assez importante. Cela ne se traduit pas nécessairement par des performances n fois moins bonnes (en raison de la mise en cache, des sections qui n'ont pas été modifiées, etc.), mais ce n'est pas une bonne pratique.

— tfrederick74656
source

Je suis presque sûr que les instantanés utilisent une table "quel bloc est dans quel fichier". Ainsi, la lecture d'un seul bloc entraînera la lecture d'un seul bloc à partir du fichier approprié. Bien sûr, la lecture de plusieurs blocs peut entraîner l'accès à plusieurs fichiers, ce qui signifie une pénalité pour le déplacement des têtes de disque si vous n'exécutez pas à partir d'un SSD, mais le nombre total d'accès aux blocs de disque ne devrait pas changer.

— Guntram Blohm prend en charge Monica

D'après ce que je comprends, les instantanés ne stockent que les modifications du disque d'origine. Si vous stockez le fichier A, puis prenez un instantané, puis modifiez à nouveau le fichier A, seules les modifications apportées à ce fichier sont écrites dans l'instantané. Ainsi, vous devez lire à la fois le VMDK d'origine et l'instantané pour obtenir l'intégralité du fichier. Sinon, chaque instantané serait simplement une copie complète du disque d'origine, ce qu'ils ne sont pas.

— tfrederick74656

cela peut être correct, mais la quantité totale de blocs que vous devez lire reste la même (par exemple 10 blocs de l'instantané et 100 du disque de base). ESXi vérifie d'abord les instantanés existants pour les blocs nécessaires jusqu'à ce qu'ils aboutissent à l'instantané correct (ou au disque de base). Il peut y avoir une pénalité mineure, car le système ignorera probablement cette capture instantanée traversant complètement la partie lorsqu'il n'y a pas de capture instantanée du tout. De plus, un fichier instantané de longue durée souffrira probablement d'une fragmentation importante.

— Dirk Trilsbeek

Un système d'instantané de disque virtuel qui effectue N lectures pour N instantané serait une implémentation très stupide. Je doute que c'est ainsi que cela soit implémenté dans VMWare. Une optimisation simple pourrait être effectuée en créant simplement un fichier d'index qui stocke dans quel fichier disque se trouve chaque bloc du lecteur émulé. Supposons que vous disposiez d'un disque virtuel de 512 Go avec une taille de bloc de 4 Ko, vous n'avez besoin que d'un index de 64 Mo pour déterminer en temps constant lequel des 16 fichiers de disque virtuel contient un bloc.

— Lie Ryan

Sur la base des réponses dans serverfault.com/questions/430138, je ne suis pas d'accord. J'ai toujours pensé aux instantanés comme le résultat de l'arithmétique binaire, pas seulement à une collection de nouvelles données. Donc, si vous avez des bits 01010101 dans votre VMDK de base, vous prenez un instantané, puis changez ces bits en 10101010, votre delta contiendrait 11111111 (indiquant que chaque bit du fichier d'origine a changé, PAS la nouvelle valeur de 10101010). Autant que je suis d'accord avec le commentaire ci-dessus, les VMDK sont censés être des fichiers bruts. Où l'index serait-il stocké? Je n'ai jamais vu cela mentionné dans les pubs technologiques VMWare.

— tfrederick74656

Les instantanés VMware ESX sont destinés à une utilisation à court terme.

Une utilisation prolongée et des E / S lourdes peuvent provoquer des blocages de VM. Si vous avez un cas où l'écriture d'E / S est plus importante / plus rapide que la consolidation des instantanés, ESX gèlera la machine virtuelle pour protéger les données. Avec les instantanés temporels qui sont fragmentés et ESX effectue une consolidation interne, vous pouvez rencontrer des blocages périodiques.

Vous pouvez effectuer un modèle de machine virtuelle manuellement via ssh. Copiez le dossier VM contenant vmdk, vmx, etc. dans un nouveau dossier. Dans le fichier vmx de la VM nouvellement copiée, changez l'UID et l'adresse MAC.

VMware a un produit, Linked Clone, qui est la même chose que vous essayez de faire. Et ils disent qu'il a des problèmes de performances potentiels. En pratique, vous allez remasteriser des machines virtuelles après un certain temps. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html

— dario
source