¿Mejores prácticas para el diseño de archivos en un servidor Hyper-V?

11

Tenemos un servidor Hyper-V configurado, y el diseño de los archivos es inconsistente porque fue configurado por varias personas. Estas son las dos "plantillas" diferentes que se utilizaron:

Plantilla 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

....

y

Plantilla 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

Plantilla 1

El argumento hecho para FOR Template 1, fue que cuando haces una exportación de una VM, la exportación crea una carpeta con el nombre de la máquina, coloca carpetas separadas para los discos y vm. Luego, simplemente puede apuntar al directorio de la máquina cuando ejecuta una importación.

El argumento EN CONTRA de este estilo de plantilla es que no tiene sentido que haya un directorio llamado Máquinas virtuales si solo hay un archivo. El otro argumento en contra es que parece que el servidor Hyper-V en sí mismo parece esperar que todos los discos duros estén en una carpeta y que todas las máquinas virtuales estén en una carpeta diferente. es decir, no crea carpetas separadas para cada VM (a excepción de las nombradas por GUID en el directorio de Máquinas virtuales)

Plantilla 2

El argumento FOR Template 2 es que parece que eso es lo que Hyper-V espera que sea el diseño.

El argumento CONTRA la Plantilla 2, es que no puede saber qué archivos de Máquina virtual están asociados con una máquina específica a menos que mire dentro de los archivos xml.

Me encantaría saber acerca de cualquier trampa para cualquiera de los diseños.

hyper-v best-practices hyper-v-server-2012 Benjamin Peikes
fuente
2
Me parece un cobertizo de bicicletas.
Evan Anderson
2
Estoy en desacuerdo. Por experiencia, hay algunas buenas razones técnicas para tener una convención de nomenclatura en la que pueda identificar qué discos pertenecen a qué máquinas virtuales desde fuera de las herramientas de Hyper-V. Una de sus opciones no le permite hacerlo fácilmente, o en absoluto, si los archivos XML de hyper-v están dañados, lo que puede suceder.
Grant
2
Tienes razón. La plantilla 2 no segrega las VM por carpeta, lo cual está bien para el VHD inicial (X) pero podría ser problemático para los VHD (X) posteriores a menos que sea consciente de nombrarlos.
joeqwerty
1
¿Qué tal una plantilla sin espacio en el camino?
usuario2813274
2
@BenjaminPeikes El cobertizo para bicicletas se refiere a la ley de trivialidad de Parkinson - en.wikipedia.org/wiki/Parkinson's_law_of_triviality
Grant

Respuestas:

12

Realmente, realmente deseas poder identificar fácilmente qué archivos pertenecen a qué máquina virtual. Incluso si pierde el acceso a la consola Hyper-V.

Esto aparece cuando se intenta restaurar una VM a partir de copias de seguridad. O cuando Hyper-V se olvida de todas sus máquinas virtuales y necesita importarlas. O bien, los archivos de configuración de VM están dañados, y debe volver a crear la VM y apuntar a los archivos antiguos del disco duro (que ahora no puede identificar, ya que su archivo de configuración está dañado). O simplemente desea verificar rápidamente cuánto espacio en disco ocupa cada VM. O necesita restaurar desde copias de seguridad donde puede ver los nombres de archivo, pero no puede leer fácilmente los archivos XML sin pasar primero por todo el proceso de restauración.

Teniendo en cuenta eso, elegiría algo similar a la Plantilla 1, donde hay una carpeta para cada VM, pero omito las subcarpetas "Máquinas virtuales" y "Discos duros de máquinas virtuales", simplemente coloque todos los archivos relacionados con una VM una carpeta con el nombre de la VM.

Tampoco necesita Hyper-V \ Máquinas virtuales: elija una de esas etiquetas, no necesita ambas.

Entonces:

D: \ Máquinas virtuales \ MACHINE_A \ GUID_1.xml
D: \ Máquinas virtuales \ MÁQUINA_A \ Máquina_a_OS.vhdx
D: \ Máquinas virtuales \ MÁQUINA_A \ Máquina_a_Data.vhdx

D: \ Máquinas virtuales \ MACHINE_B \ GUID_2.xml
D: \ Máquinas virtuales \ MÁQUINA_B \ Máquina_b_OS.vhdx
D: \ Máquinas virtuales \ MACHINE_B \ Machine_b_Data.vhdx

etc.

O puede decidir que no necesita los nombres de los archivos para que coincidan con la máquina virtual: el nombre de la carpeta es suficiente. Nombrarlo de esta manera facilitaría clonar una VM sin tener que preocuparse por cambiar el nombre de sus archivos:

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

La conclusión principal aquí es organizar los archivos de modo que al observar nada más que la estructura del archivo, pueda saber a qué VM pertenece cada archivo y para qué sirve ese archivo.

Conceder
fuente
Me he inclinado hacia el diseño que propones. Una cosa sobre este diseño particular que no me gusta es que usa el nombre de la máquina tanto en la estructura de carpetas como en la convención de nomenclatura de archivos. Esto significa que no puede simplemente copiar una carpeta de una máquina para hacer una nueva.
Benjamin Peikes
Un argumento que he escuchado es que puede saber qué archivos pertenecen a qué máquina virtual al buscar en los archivos xml para cada GUID. Aunque definitivamente es útil tener una convención de nomenclatura fácil de entender, se desmorona por completo si alguien no la sigue, ni siquiera una vez. Es como tener comentarios en el código que ya no coinciden con el código. Dado que toda la información sobre la máquina está en el archivo xml, desconfío de confiar en el nombre de las carpetas y archivos para resolver cualquier cosa.
Benjamin Peikes
@BenjaminPeikes Confiar en los archivos XML para unir archivos con máquinas virtuales es arriesgado. He tenido casos en los que, ya sea por eliminación accidental o corrupción de datos, los archivos XML desaparecieron o no se pudieron leer. Además, es simplemente más rápido que los GUID coincidentes. Pero estoy de acuerdo en que no necesariamente necesita usar el nombre de VM en el nombre de archivo, solo la carpeta si lo prefiere. Solo asegúrate de que, observando solo la estructura de archivos, puedes saber qué archivos pertenecen a qué VM y para qué sirven.
Grant
2

No me gusta ninguno

Porque ninguna de sus plantillas es estable en caso de que mueva una VM.

Yo, y lo hago yo mismo, usaría una estructura de carpetas idéntica a la que obtienes cuando mueves una VM entre hosts. De esa manera, nada cambia cuando: mueve una VM entre hosts.

TomTom
fuente
¿No es la Plantilla 1 lo que obtienes cuando mueves una VM entre hosts?
Benjamin Peikes
Pruébalo, no lo es. Por ejemplo, los discos terminan en una carpeta "Discos duros virtuales" debajo de la carpeta del nombre de la máquina.
TomTom
eso es lo que hace mi Plantilla 1. Cada máquina tiene su propia carpeta, y en cada una de esas carpetas hay una carpeta de máquinas virtuales y una carpeta de discos duros virtuales.
Benjamin Peikes
1
¿Hay alguna forma de hacer que Hyper-V use la estructura que ha descrito de manera predeterminada cuando se crea una VM, @TomTom? Me gusta poner mis máquinas virtuales en una carpeta propia. Pero cada vez, termino creando la VM y luego moviéndola directamente para obtener la estructura de carpetas que quiero.
Matty Brown el
1

Debe hacer la plantilla 2 para separar el acoplamiento de las partes de la máquina virtual de los problemas de almacenamiento. Es decir, un VHDX para una VM puede ir por un volumen de rendimiento, otro VHDX para la misma VM está más preocupado por la capacidad, y todos pueden estar relacionados con diferencias en la resistencia.

Por lo tanto, no podrá hacer la plantilla 1 a menos que también introduzca en el diseño de la estructura del archivo la complicación de asignar diferentes ubicaciones de almacenamiento en el acoplamiento para las partes de archivo de las máquinas virtuales.

Así:

PLANTILLA 2

Plantilla 2: aquí la administración del almacenamiento tiene prioridad sobre el diseño de los espacios de nombres (mientras tanto, el diseño del espacio de nombres se maneja en la interfaz de usuario para administrar la VM ... es decir, algunas partes de la VM pueden no ser locales sino estar en la nube, etc. usando, por ejemplo, el almacenamiento autobús)

... gestionando diferentes preocupaciones en la gestión del almacenamiento:

D: \ Storage \ Pool1 \ Hyper-V \ Discos duros virtuales \ xxx-xx-xx-System-01-Prod.vhdx

D: \ Storage \ Pool1 \ Hyper-V \ Discos duros virtuales \ xxx-xx-xx-Data-01-Prod.vhdx

D: \ Storage \ Pool2 \ Hyper-V \ Discos duros virtuales \ xxx-xx-xx-Data-02-Prod.vhdx

D: \ Storage \ Pool3 \ Hyper-V \ Discos duros virtuales \ xxx-xx-xx-Recovery-01-Prod.vhdx

D: \ Almacenamiento \ Pool1 \ Hyper-V \ Máquinas virtuales \ GUID_1

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

D: \ Almacenamiento \ Pool1 \ Hyper-V \ Máquinas virtuales \ GUID_2

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

PLANTILLA 1

Para hacer esta asignación en la plantilla 1, donde las preocupaciones de espacio de nombres en el sistema de archivos (también conocido como una interfaz de usuario pseudo aprovisionada) tiene prioridad, mientras se mantienen las preocupaciones de almacenamiento:

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-System-01-Prod.vhdx> (vinculado a) D: \ Storage \ Pool1 \ Hyper-V \ Discos duros virtuales \ 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 \ Discos duros virtuales \ 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 \ Discos duros virtuales \ 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 \ Discos duros virtuales \ 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
fuente