Meilleures pratiques pour la disposition des fichiers sur un serveur Hyper-V?

Nous avons un serveur Hyper-V configuré et la disposition des fichiers est incohérente car elle a été configurée par plusieurs personnes. Voici les deux différents "modèles" qui ont été utilisés:

Modèle 1

D:\Hyper-V\Virtual Machines\MACHINE_NAME_1\Virtual Hard Disks\MACHINE_NAME_1.vhdx
D:\Hyper-V\Virtual Machines\MACHINE_NAME_1\Virtual Machines\GUID_1
D:\Hyper-V\Virtual Machines\MACHINE_NAME_1\Virtual Machines\GUID_1.xml

D:\Hyper-V\Virtual Machines\MACHINE_NAME_2\Virtual Hard Disks\MACHINE_NAME_2.vhdx
D:\Hyper-V\Virtual Machines\MACHINE_NAME_2\Virtual Machines\GUID_2
D:\Hyper-V\Virtual Machines\MACHINE_NAME_2\Virtual Machines\GUID_2.xml

....

Modèle 2

D:\Hyper-V\Virtual Hard Disks\MACHINE_NAME_1.vhdx
D:\Hyper-V\Virtual Hard Disks\MACHINE_NAME_2.vhdx

D:\Hyper-V\Virtual Machines\GUID_1
D:\Hyper-V\Virtual Machines\GUID_1.xml
D:\Hyper-V\Virtual Machines\GUID_2
D:\Hyper-V\Virtual Machines\GUID_2.xml

Modèle 1

L'argument avancé pour le modèle 1 était que lorsque vous effectuez une exportation d'une machine virtuelle, l'exportation crée un dossier avec le nom de la machine, place des dossiers séparés pour les disques et vm. Vous pouvez ensuite simplement pointer vers le répertoire machine lorsque vous exécutez une importation.

L'argument CONTRE ce style de modèle est qu'il n'a pas de sens qu'il y ait un répertoire appelé Virtual Machines s'il n'y a qu'un seul fichier. L'autre argument contre est qu'il semble que le serveur Hyper-V lui-même semble s'attendre à ce que tous les disques durs se trouvent dans un dossier et que toutes les machines virtuelles se trouvent dans un dossier différent. c'est-à-dire qu'il ne crée pas de dossiers séparés pour chaque VM (sauf pour ceux nommés par GUID dans le répertoire Virtual Machines)

Modèle 2

L'argument POUR le modèle 2 est qu'il semble que c'est ce que Hyper-V attend de la disposition.

L'argument CONTRE le modèle 2 est que vous ne pouvez pas dire quels fichiers de machine virtuelle sont associés à une machine spécifique à moins de regarder à l'intérieur des fichiers xml.

J'adorerais entendre les pièges de l'une ou l'autre disposition.

hyper-v best-practices hyper-v-server-2012

— Benjamin Peikes
source

On dirait un hangar à vélo pour moi.

— Evan Anderson

Je ne suis pas d'accord. Par expérience, il existe de bonnes raisons techniques d'avoir une convention de dénomination permettant d'identifier quels disques appartiennent à quelles machines virtuelles en dehors des outils Hyper-V. L'une de ses options ne vous permet pas de le faire facilement - ou pas du tout, si les fichiers XML hyper-v sont corrompus, ce qui peut se produire.

— Grant

Vous avez raison. Le modèle 2 ne sépare pas les machines virtuelles par dossier, ce qui est bien pour le VHD (X) initial, mais pourrait être problématique pour les VHD (X) suivants, sauf si vous êtes consciencieux de les nommer.

— joeqwerty

Que diriez-vous d'un modèle sans espace sur le chemin?

— user2813274

@BenjaminPeikes Bike shed fait référence à la loi de trivialité de Parkinson - fr.wikipedia.org/wiki/Parkinson's_law_of_triviality

— Grant

Réponses:

Vous voulez vraiment, vraiment pouvoir identifier facilement quels fichiers appartiennent à quelle machine virtuelle. Même si vous perdez l'accès à la console Hyper-V.

Cela apparaît lorsque vous essayez de restaurer une machine virtuelle à partir de sauvegardes. Ou lorsque Hyper-V oublie toutes vos machines virtuelles et que vous devez les importer. Ou les fichiers de configuration de la machine virtuelle sont corrompus, et vous devez recréer la machine virtuelle et pointer vers les anciens fichiers du disque dur (que vous ne pouvez plus identifier, car votre fichier de configuration est corrompu). Ou vous voulez simplement vérifier rapidement l'espace disque occupé par chaque machine virtuelle. Ou vous devez restaurer à partir de sauvegardes où vous pouvez voir les noms de fichiers, mais pas facilement lire les fichiers XML sans passer par tout le processus de restauration.

Compte tenu de cela, j'opterais pour quelque chose de similaire au modèle 1, où il y a un dossier pour chaque machine virtuelle - mais en omettant les sous-dossiers "Virtual Machines" et "Virtual Machine Hard Disks" - il suffit de mettre tous les fichiers liés à une machine virtuelle dans un dossier avec le nom de la VM.

Vous n'avez pas non plus besoin de machines Hyper-V \ Virtual - choisissez l'une de ces étiquettes, vous n'avez pas besoin des deux.

Donc:

D: \ Machines virtuelles \ MACHINE_A \ GUID_1.xml
D: \ Machines virtuelles \ MACHINE_A \ Machine_a_OS.vhdx
D: \ Machines virtuelles \ MACHINE_A \ Machine_a_Data.vhdx

D: \ Machines virtuelles \ MACHINE_B \ GUID_2.xml
D: \ Machines virtuelles \ MACHINE_B \ Machine_b_OS.vhdx
D: \ Machines virtuelles \ MACHINE_B \ Machine_b_Data.vhdx

etc.

Ou vous pouvez décider que vous n'avez pas besoin des noms de fichiers pour correspondre à la machine virtuelle - le nom du dossier est suffisant. Le nommer ainsi faciliterait le clonage d'une machine virtuelle sans avoir à se soucier de renommer ses fichiers:

D: \ VMs \ Machine A \ GUID_1.xml
D: \ VMs \ Machine A \ OS.vhdx
D: \ VMs \ Machine A \ Data.vhdx

D: \ VMs \ Machine B \ GUID_2.xml
D: \ VMs \ Machine B \ OS.vhdx
D: \ VMs \ Machine B \ SQLData.vhdx
D: \ VMs \ Machine B \ SQLLog.vhdx

Le principal point à retenir ici est d'organiser les fichiers de sorte qu'en ne regardant rien d'autre que la structure des fichiers, vous puissiez dire à quelle machine virtuelle appartient chaque fichier et à quoi il sert.

— Subvention
source

Je me suis penché vers la mise en page que vous proposez. Une chose à propos de cette disposition particulière que je n'aime pas, c'est qu'elle utilise le nom de la machine dans la structure des dossiers et la convention de dénomination des fichiers. Cela signifie que vous ne pouvez pas simplement copier un dossier d'une machine pour en créer un nouveau.

— Benjamin Peikes

Un argument que j'ai entendu, c'est que vous pouvez savoir quels fichiers appartiennent à quelle machine virtuelle en consultant les fichiers xml pour chaque GUID. Même s'il est certainement utile d'avoir une convention de dénomination facile à comprendre, elle s'effondre complètement si quelqu'un ne la suit pas, même une fois. C'est comme avoir des commentaires dans le code qui ne correspondent plus au code. Étant donné que toutes les informations sur la machine se trouvent dans le fichier xml, je me méfie de compter sur le nommage des dossiers et des fichiers pour trouver quoi que ce soit.

— Benjamin Peikes

@BenjaminPeikes Se fier aux fichiers XML pour faire correspondre les fichiers aux machines virtuelles est risqué. J'ai eu des cas où, par suppression accidentelle ou corruption de données, les fichiers XML étaient partis ou illisibles. En outre, c'est tout simplement plus rapide que de faire correspondre les GUID. Mais je conviens que vous n'avez pas nécessairement besoin d'utiliser le nom de la machine virtuelle dans le nom de fichier, juste le dossier si vous préférez. Assurez-vous simplement qu'en ne regardant que la structure des fichiers, vous pouvez savoir quels fichiers appartiennent à quelle machine virtuelle et à quelle fin ils servent.

— Grant

Je n'aime rien.

Parce qu'aucun de vos modèles n'est stable au cas où vous déplaceriez une machine virtuelle.

Je voudrais - et je le fais moi-même - utiliser une structure de dossiers identique à celle que vous obtenez lorsque vous déplacez une machine virtuelle entre hôtes. De cette façon, rien ne change quand - vous déplacez une machine virtuelle entre les hôtes.

— TomTom
source

Le modèle 1 n'est-il pas ce que vous obtenez lorsque vous déplacez une machine virtuelle entre des hôtes?

— Benjamin Peikes

Essayez-le - ce n'est pas le cas. Par exemple, les disques se retrouvent dans un dossier "Virtual Hard Disks" sous le dossier du nom de la machine.

— TomTom

c'est ce que fait mon modèle 1. Chaque machine a son propre dossier, et dans chacun de ces dossiers se trouvent un dossier Machines virtuelles et un dossier Disques durs virtuels.

— Benjamin Peikes

Existe-t-il un moyen pour que Hyper-V utilise la structure que vous avez décrite par défaut lors de la création d'une machine virtuelle, @TomTom? J'aime placer mes VM dans un dossier qui leur est propre. Mais à chaque fois, je finis par créer la machine virtuelle, puis je la déplace tout de suite après pour obtenir la structure de dossiers que je souhaite.

— Matty Brown

Vous devez faire le modèle 2 pour séparer le couplage des pièces de machine virtuelle des problèmes de stockage. C'est-à-dire qu'un VHDX pour une VM peut aller pour un volume de performances, un autre VHDX pour la même VM est plus concerné par la capacité - et tous peuvent être avec des différences de résilience.

Vous ne pourrez donc pas faire le modèle 1, sauf si vous introduisez également dans la structure de la structure de fichiers la complication du mappage de différents emplacements de stockage dans le couplage pour les parties de fichier des machines virtuelles.

Donc:

MODÈLE 2

Modèle 2 - Ici, la gestion du stockage a priorité sur la disposition des espaces de noms (pendant ce temps, la disposition des espaces de noms est gérée dans l'interface utilisateur pour gérer la machine virtuelle ... c'est-à-dire que certaines parties de la machine virtuelle peuvent même ne pas être locales mais être dans le cloud, etc. en utilisant par exemple le stockage autobus)

... gérer différentes préoccupations dans la gestion du stockage:

D: \ Storage \ Pool1 \ Hyper-V \ Virtual Hard Disks \ xxx-xx-xx-System-01-Prod.vhdx

D: \ Storage \ Pool1 \ Hyper-V \ Virtual Hard Disks \ xxx-xx-xx-Data-01-Prod.vhdx

D: \ Storage \ Pool2 \ Hyper-V \ Virtual Hard Disks \ xxx-xx-xx-Data-02-Prod.vhdx

D: \ Storage \ Pool3 \ Hyper-V \ Virtual Hard Disks \ xxx-xx-xx-Recovery-01-Prod.vhdx

D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_1

D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_1.xml

D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_2

D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_2.xml

MODÈLE 1

Pour effectuer ce mappage dans le modèle 1 - où les problèmes d'espace de noms dans le système de fichiers (alias une interface utilisateur pseudo-provisionnée) ont priorité - tout en conservant les problèmes de stockage:

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-System-01-Prod.vhdx> (lié à) D: \ Storage \ Pool1 \ Hyper-V \ Virtual Hard Disks \ xxx- xx-xx-System-01-Prod.vhdx

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-Data-01-Prod.vhdx> D: \ Storage \ Pool1 \ Hyper-V \ Virtual Hard Disks \ xxx-xx-xx- Data-01-Prod.vhdx

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-Data-02-Prod.vhdx> D: \ Storage \ Pool2 \ Hyper-V \ Virtual Hard Disks \ xxx-xx-xx- Data-02-Prod.vhdx

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-Recovery-01-Prod.vhdx> D: \ Storage \ Pool3 \ Hyper-V \ Virtual Hard Disks \ xxx-xx-xx- Recovery-01-Prod.vhdx

D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_1> D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_1 D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_1.xml > D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_1.xml D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_2> D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_2 D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_2.xml> D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_2.xml

— computermensch
source