Кращі практики для компонування файлів на сервері Hyper-V?

У нас налаштований сервер Hyper-V, і компонування файлів суперечлива, оскільки його створили кілька людей. Ось два різних "шаблони", які використовувались:

Шаблон 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

….

Шаблон 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

Шаблон 1

Аргумент, зроблений для шаблону 1, полягає в тому, що при виконанні експорту віртуального експорту експорт створює папку з назвою машини, ставить окремі папки для дисків і vm. Потім ви можете просто вказати на машинний каталог під час запуску імпорту.

Аргумент ПРОТИ цей стиль шаблону полягає в тому, що не має сенсу існувати каталог під назвою Virtual Machines, якщо є лише один файл. Інший аргумент - це те, що, здається, саме сервер Hyper-V очікує, що всі жорсткі диски знаходяться в одній папці, а всі віртуальні машини знаходяться в іншій папці. тобто він не створює окремих папок для кожного віртуального комп'ютера (за винятком тих, які названі GUID у каталозі віртуальних машин)

Шаблон 2

Аргумент ЗА Шаблону 2 полягає в тому, що схоже на те, що саме Hyper-V очікує, що буде макет.

Аргумент ПРОТИ Шаблон 2 полягає в тому, що ви не можете сказати, які файли віртуальної машини пов'язані з конкретною машиною, якщо ви не заглянете все до файлів xml.

Я хотів би почути про будь-які підводні камені будь-якого планування.

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

— Бенджамін Пейкес
джерело

Схоже, на мене пролягає велосипед.

— Еван Андерсон

Я не погоджуюсь. З досвіду, є кілька вагомих технічних причин, щоб створити правила іменування, де можна визначити, до яких дисків належать VM, які знаходяться поза інструментами Hyper-V. Один з його варіантів не дозволяє вам це зробити легко - або взагалі, якщо гіпер-v XML файли пошкоджені, що може статися.

— Грант

Ти маєш рацію. Шаблон 2 не відокремлює VM за папкою, що добре для початкового VHD (X), але може бути проблематичним для наступних VHD (X), якщо ви не сумлінно ставите їх до імені.

— joeqwerty

Як щодо шаблону, де немає місця на шляху?

— користувач2813274

@ BenjaminPeikes Велосипедний сарай посилається на закон тривіальності Паркінсона - en.wikipedia.org/wiki/Parkinson's_law_of_triviality

— Грант

Відповіді:

Ви дійсно дуже хочете мати можливість легко визначити, які файли належать до якої віртуальної машини. Навіть якщо ви втратите доступ до консолі Hyper-V.

Це з'являється при спробі відновити VM з резервного копіювання. Або коли Hyper-V забуде про всі ваші відеомагнітофони і вам потрібно імпортувати їх. Або файли конфігурації VM пошкоджені, і вам доведеться відтворити VM і вказати на старі файли жорсткого диска (які ви зараз не можете ідентифікувати, оскільки ваш конфігураційний файл пошкоджений). Або ви просто хочете швидко перевірити, скільки місця на диску займає кожен VM. Або вам потрібно відновити з резервних копій, де ви можете бачити назви файлів, але не легко читати файли XML, не проходячи спочатку весь процес відновлення.

Враховуючи це, я б хотів щось подібне до шаблону 1, де є папка для кожного віртуального комп'ютера, але не залишаю підпапки "Віртуальні машини" та "Жорсткі диски віртуальної машини" - просто покладіть усі файли, пов’язані з VM папку з назвою VM.

Вам також не потрібні Hyper-V \ Virtual машини - виберіть одну з цих міток, обидві вам не потрібні.

Тому:

D: \ Віртуальні машини \ MACHINE_A \ GUID_1.xml
D: \ Віртуальні машини \ MACHINE_A \ Machine_a_OS.vhdx
D: \ Віртуальні машини \ MACHINE_A \ Machine_a_Data.vhdx

D: \ Віртуальні машини \ MACHINE_B \ GUID_2.xml
D: \ Віртуальні машини \ MACHINE_B \ Machine_b_OS.vhdx
D: \ Віртуальні машини \ MACHINE_B \ Machine_b_Data.vhdx

тощо.

Або ви можете вирішити, що файли не потрібні, щоб відповідати віртуальній машині - імені папки достатньо. Назвавши його таким чином, було б простіше клонувати VM, не турбуючись про перейменування файлів:

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

Основний вихід тут полягає в організації файлів, щоб, дивлячись ні на що інше, як на структуру файлів, можна було сказати, до якого VM належить кожен файл і для чого цей файл.

— Грант
джерело

Я схилявся до запропонованого вами макета. Одна річ у цьому конкретному макеті, який мені не подобається, - це те, що він використовує ім’я машини як у структурі папок, так і в умові іменування файлів. Це означає, що ви не можете просто скопіювати папку машини, щоб створити нову.

— Бенджамін Пейкес

Один з аргументів, який я чув, - це те, що ви можете вказати, які файли належать до тієї віртуальної машини, заглянувши у файли xml для кожного GUID. Незважаючи на те, що це, безумовно, корисно легко зрозуміти умову іменування, вона повністю розпадається, якщо хтось не дотримується її навіть один раз. Це як мати коментарі в коді, які більше не відповідають коду. Оскільки вся інформація про машину знаходиться у файлі xml, я насторожено покладаюся на іменування папок та файлів, щоб щось зрозуміти.

— Бенджамін Пейкес

@BenjaminPeikes Покладатися на файли XML для відповідності файлів VM ризиковано. У мене були випадки, коли через випадкове видалення або пошкодження даних XML-файли були зникли або не читалися. Крім того, це просто швидше, ніж відповідність GUID. Але я погоджуюся, що вам не обов'язково потрібно використовувати ім'я VM у назві файлу, а лише папку, якщо вам зручніше. Просто переконайтесь, що - дивлячись ні на що, крім на структуру файлів, - ви можете сказати, які файли належать до якого VM і для якої мети вони служать.

— Грант

Мені ніхто не подобається.

Тому що жоден із ваших шаблонів не є стабільним у випадку, якщо ви переміщуєте VM.

Я б - і це роблю сам - використовував структуру папок, ідентичну тій, яку ви отримуєте, коли ви переміщуєте VM між хостами. Таким чином нічого не змінюється, коли - ви переміщуєте VM між хостами.

— TomTom
джерело

Чи не є шаблон 1, який ви отримуєте, коли переміщуєте VM між хостами?

— Бенджамін Пейкес

Спробуйте - це не так. Наприклад, диски потрапляють у папку "Віртуальні жорсткі диски" під папкою імені машини.

— TomTom

ось що робить мій шаблон 1. У кожної машини є своя папка, і в кожній з цих папок - папка Virtual Machines і папка Virtual Hard Disks.

— Бенджамін Пейкес

Чи є спосіб отримати Hyper-V використовувати структуру, яку ви описали за замовчуванням, коли створюється VM @TomTom? Мені подобається поміщати свої VM під власну папку. Але кожен раз, коли я закінчую створювати VM, то переміщую його відразу після отримання структури папки, яку я хочу.

— Матті Браун

Вам потрібно зробити шаблон 2, щоб відокремити з'єднання частин віртуальної машини від проблем зберігання. Тобто один VHDX для VM може йти на обсяг продуктивності, інший VHDX для того ж VM більше стосується ємності - і все може бути з різницею в стійкості.

Таким чином, ви не зможете зробити шаблон 1, якщо ви також не введете в макет файлової структури ускладнення відображення різних місць зберігання в муфті для файлових частин віртуальної машини.

Таким чином:

ТЕМПЛАТ 2

Шаблон 2 - Тут управління пам’яттю має перевагу над компонуванням просторів імен (тим часом, макет простору імен обробляється в інтерфейсі для управління VM ... тобто деякі частини ВМ можуть навіть не бути локальними, а бути у хмарі тощо, використовуючи, наприклад, сховище) автобус)

... управління різними проблемами в управлінні сховищами:

D: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні жорсткі диски \ xxx-xx-xx-System-01-Prod.vhdx

D: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні жорсткі диски \ xxx-xx-xx-Data-01-Prod.vhdx

D: \ Зберігання \ Pool2 \ Hyper-V \ Віртуальні жорсткі диски \ xxx-xx-xx-Data-02-Prod.vhdx

D: \ Зберігання \ Pool3 \ Hyper-V \ Віртуальні жорсткі диски \ xxx-xx-xx-Recovery-01-Prod.vhdx

D: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні машини \ GUID_1

D: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні машини \ GUID_1.xml

D: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні машини \ GUID_2

D: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні машини \ GUID_2.xml

ВРЕМЯ 1

Для цього відображення у шаблоні 1 - де проблеми файлу імен у файловій системі (він же псевдокористувальний інтерфейс) має перевагу - зберігаючи проблеми зберігання:

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-System-01-Prod.vhdx> (пов'язано з) 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- Дані-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- Дані-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- Відновлення-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: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні машини \ GUID_1.xml D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_2> D: \ Зберігання \ Pool1 \ Hyper-V \ Віртуальні машини \ GUID_2 D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_2.xml> D: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_2.xml

— комп'ютерні
джерело