Najlepsze praktyki dotyczące układu plików na serwerze Hyper-V?

Mamy skonfigurowany serwer Hyper-V, a układ plików jest niespójny, ponieważ został skonfigurowany przez kilka osób. Oto dwa różne „szablony”, które zostały użyte:

Szablon 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

…

Szablon 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

Szablon 1

Argumentem dla szablonu 1 było to, że kiedy robisz eksport maszyny wirtualnej, eksport tworzy folder z nazwą komputera, umieszcza osobne foldery dla dysków i vm. Następnie możesz po prostu wskazać katalog maszyny po uruchomieniu importu.

Argument PRZECIWKO temu stylowi szablonu jest taki, że nie ma sensu istnienie katalogu o nazwie Maszyny wirtualne, jeśli jest tylko jeden plik. Drugi argument przemawia przeciwko temu, że wydaje się, że sam serwer Hyper-V wydaje się oczekiwać, że wszystkie dyski twarde są w jednym folderze, a wszystkie maszyny wirtualne znajdują się w innym folderze. tzn. nie tworzy osobnych folderów dla każdej maszyny Wirtualnej (execept dla tych o nazwie GUID w katalogu maszyn wirtualnych)

Szablon 2

Argumentem dla szablonu 2 jest to, że wydaje się, że właśnie tego oczekuje Hyper-V od układu.

Argument AGAINST Szablon 2 polega na tym, że nie można stwierdzić, które pliki maszyny wirtualnej są powiązane z konkretną maszyną, chyba że zajrzysz do plików xml.

Chciałbym usłyszeć o wszelkich pułapkach w obu układach.

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

— Benjamin Peikes
źródło

Wygląda mi to na rower.

— Evan Anderson

Nie zgadzam się. Z doświadczenia wynika, że istnieje kilka dobrych technicznych powodów, aby wprowadzić konwencję nazewnictwa, w której można określić, które dyski należą do których maszyn wirtualnych spoza narzędzi Hyper-V. Jedna z jego opcji nie pozwala na to łatwo - lub wcale, jeśli pliki XML hyper-v są uszkodzone, co może się zdarzyć.

— Grant

Masz rację. Szablon 2 nie segreguje maszyn wirtualnych według folderów, co jest dobre w przypadku początkowego dysku VHD (X), ale może być problematyczne w przypadku kolejnych dysków VHD (X), chyba że sumiennie je nazywasz.

— joeqwerty

A może szablon bez spacji na ścieżce?

— user2813274

@BenjaminPeikes na rowery dotyczy Prawo Parkinsona z trywialności - en.wikipedia.org/wiki/Parkinson's_law_of_triviality

— Grant

Odpowiedzi:

Naprawdę, naprawdę chcesz być w stanie łatwo zidentyfikować, które pliki należą do której maszyny wirtualnej. Nawet jeśli stracisz dostęp do konsoli Hyper-V.

Pojawia się to podczas próby przywrócenia maszyny wirtualnej z kopii zapasowych. Lub gdy Hyper-V zapomni o wszystkich maszynach wirtualnych i musisz je zaimportować. Lub pliki konfiguracyjne maszyny wirtualnej są uszkodzone i trzeba ponownie utworzyć maszynę wirtualną i wskazać stare pliki dysku twardego (których nie można teraz zidentyfikować, ponieważ plik konfiguracji jest uszkodzony). Lub po prostu chcesz szybko sprawdzić, ile miejsca na dysku zajmuje każda maszyna wirtualna. Lub trzeba przywrócić z kopii zapasowych, w których można zobaczyć nazwy plików, ale nie można łatwo odczytać plików XML bez uprzedniego przejścia całego procesu przywracania.

Biorąc to pod uwagę, wybrałbym coś podobnego do szablonu 1, w którym jest folder dla każdej maszyny wirtualnej - ale pomiń podfoldery „Maszyny wirtualne” i „Dyski twarde maszyny wirtualnej” - po prostu umieść wszystkie pliki związane z maszyną wirtualną w folder z nazwą maszyny wirtualnej.

Nie potrzebujesz również Hyper-V \ Maszyny wirtualne - wybierz jedną z tych etykiet, nie potrzebujesz obu.

Więc:

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

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

itp.

Lub możesz zdecydować, że nie potrzebujesz nazw plików pasujących do maszyny wirtualnej - nazwa folderu jest wystarczająca. Nazwanie go w ten sposób ułatwi klonowanie maszyny wirtualnej bez martwienia się o zmianę nazwy jej plików:

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

Najważniejszą kwestią jest uporządkowanie plików w taki sposób, aby patrząc tylko na strukturę plików, można było stwierdzić, do jakiej maszyny wirtualnej należy każdy plik i do czego ten plik jest przeznaczony.

— Dotacja
źródło

Opierałem się na zaproponowanym przez ciebie układzie. Jedną rzeczą dotyczącą tego konkretnego układu, który mi się nie podoba, jest to, że używa nazwy komputera zarówno w strukturze folderów, jak i konwencji nazewnictwa plików. Oznacza to, że nie można po prostu skopiować folderu komputera, aby utworzyć nowy.

— Benjamin Peikes

Jednym z argumentów, jaki słyszałem, jest to, że możesz stwierdzić, które pliki należą do której maszyny wirtualnej, przeglądając pliki xml dla każdego identyfikatora GUID. Mimo że zdecydowanie przydatna jest zrozumiała konwencja nazewnictwa, całkowicie się rozpada, jeśli ktoś nie zastosuje się do niej ani razu. To tak, jakby komentarze w kodzie nie pasowały już do kodu. Ponieważ wszystkie informacje o maszynie znajdują się w pliku xml, obawiam się, że mogę polegać na nazwach folderów i plików, aby cokolwiek wymyślić.

— Benjamin Peikes,

@BenjaminPeikes Poleganie na plikach XML w celu dopasowania plików do maszyn wirtualnych jest ryzykowne. Miałem przypadki, w których albo przez przypadkowe usunięcie lub uszkodzenie danych pliki XML zniknęły lub były nieczytelne. Ponadto jest to po prostu szybsze niż dopasowywanie identyfikatorów GUID. Ale zgadzam się, że niekoniecznie musisz używać nazwy VM w nazwie pliku, tylko folder, jeśli wolisz. Upewnij się tylko, że - patrząc tylko na strukturę plików - możesz stwierdzić, które pliki należą do jakiej maszyny wirtualnej i do jakiego celu służą.

— Grant

Nie lubię żadnego.

Ponieważ żaden z szablonów nie jest stabilny na wypadek przeniesienia maszyny wirtualnej.

Wolałbym - i robię to sam - użyć struktury folderów identycznej do tej, którą otrzymujesz, gdy przenosisz maszynę wirtualną między hostami. W ten sposób nic się nie zmienia, gdy - przenosisz maszynę wirtualną między hostami.

— TomTom
źródło

Czy szablon 1 nie jest tym, co dostajesz, gdy przenosisz maszynę wirtualną między hostami?

— Benjamin Peikes,

Spróbuj - nie jest. Na przykład dyski kończą w folderze „Wirtualne dyski twarde” w folderze nazw komputerów.

— TomTom,

to właśnie robi mój Szablon 1. Każda maszyna ma własny folder, aw każdym z tych folderów znajduje się folder Maszyny wirtualne i folder Wirtualne dyski twarde.

— Benjamin Peikes

Czy istnieje sposób na to, aby Hyper-V używał struktury opisanej domyślnie podczas tworzenia maszyny wirtualnej @TomTom? Lubię umieszczać moje maszyny wirtualne we własnym folderze. Ale za każdym razem tworzę maszynę wirtualną, a następnie przesuwam ją od razu, aby uzyskać pożądaną strukturę folderów.

— Matty Brown,

Musisz wykonać szablon 2, aby oddzielić połączenie części maszyn wirtualnych od problemów związanych z przechowywaniem. Tj. Jeden dysk VHDX dla maszyny wirtualnej może zostać wykorzystany do zwiększenia wydajności, inny dysk VHDX dla tej samej maszyny wirtualnej jest bardziej zainteresowany wydajnością - a wszystkie mogą mieć różnice w odporności.

Tak więc nie będziesz w stanie wykonać szablonu 1, chyba że wprowadzisz do układu struktury plików komplikację odwzorowania różnych lokalizacji pamięci w sprzężeniu dla części pliku maszyn wirtualnych.

A zatem:

SZABLON 2

Szablon 2 - Tutaj zarządzanie pamięcią masową ma pierwszeństwo przed układem przestrzeni nazw (tymczasem układ przestrzeni nazw jest obsługiwany w interfejsie użytkownika do zarządzania maszyną wirtualną ... tzn. Niektóre części maszyny wirtualnej mogą nawet nie być lokalne, ale znajdować się w chmurze itp., Na przykład używając magazynu autobus)

... zarządzanie różnymi problemami w zarządzaniu pamięcią:

D: \ Storage \ Pool1 \ Hyper-V \ Wirtualne dyski twarde \ xxx-xx-xx-System-01-Prod.vhdx

D: \ Storage \ Pool1 \ Hyper-V \ Wirtualne dyski twarde \ xxx-xx-xx-Data-01-Prod.vhdx

D: \ Storage \ Pool2 \ Hyper-V \ Wirtualne dyski twarde \ xxx-xx-xx-Data-02-Prod.vhdx

D: \ Storage \ Pool3 \ Hyper-V \ Wirtualne dyski twarde \ 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

SZABLON 1

Aby wykonać to odwzorowanie w szablonie 1 - gdy przestrzeń nazw dotyczy systemu plików (inaczej interfejs użytkownika udostępniany pseudo) - ma pierwszeństwo - przy jednoczesnym zachowaniu pamięci:

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-System-01-Prod.vhdx> (powiązany z) 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 \ Wirtualne dyski twarde \ 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 \ Wirtualne dyski twarde \ 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 \ Wirtualne dyski twarde \ 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
źródło