Hyper-V sunucusunda dosya düzeni için en iyi uygulamalar?

Bir Hyper-V sunucumuz var ve dosyaların düzeni tutarsız çünkü birkaç kişi tarafından kuruldu. Kullanılan iki farklı "şablon" şunlardır:

Şablon 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

....

Şablon 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

Şablon 1

Şablon 1 için yapılan argüman, bir VM'yi dışa aktardığınızda dışa aktarma işleminin makine adı ile bir klasör oluşturması, diskler ve vm için ayrı klasörler koymasıydı. Daha sonra, bir içe aktarma işlemi gerçekleştirdiğinizde makine dizinini işaret edebilirsiniz.

Bu şablon stiline karşılık gelen argüman, sadece bir dosya varsa Sanal Makineler adlı bir dizinin bulunmasının mantıklı olmamasıdır. Karşıdaki diğer argüman, Hyper-V sunucusunun kendisinin tüm sabit disklerin bir klasörde ve tüm Sanal Makinelerin farklı bir klasörde olmasını beklediği görülüyor. yani her VM için ayrı klasörler oluşturmaz (Sanal Makineler dizininde GUID tarafından adlandırılanlar için yürütülür)

Şablon 2

Şablon 2'nin argümanı, Hyper-V'nin mizanpaj olmasını beklediği gibi görünüyor.

Şablon 2'ye karşılık gelen argüman, xml dosyalarının içine bakmadığınız sürece hangi Sanal Makine dosyalarının belirli bir makine ile ilişkili olduğunu söyleyemezsiniz.

Her iki düzene de herhangi bir tuzak duymak isterim.

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

— Benjamin Peikes
kaynak

Bana bir bisiklet döküldü.

— Evan Anderson

Katılmıyorum. Deneyimden, hangi disklerin Hyper-V araçlarının dışından hangi VM'lere ait olduğunu tanımlayabileceğiniz bir adlandırma kuralına sahip olmanın bazı iyi teknik nedenleri vardır. Seçeneklerinden biri bunu kolayca yapmanıza izin vermez - ya da hyper-v XML dosyaları bozuksa, bu gerçekleşebilir.

— Grant

Haklısın. Şablon 2, ilk VHD (X) için iyi olan VM'leri klasöre ayırmaz, ancak adlandırma konusunda bilinçli değilseniz sonraki VHD (X) 'lar için sorunlu olabilir.

— joeqwerty

Yolda boşluğu olmayan bir şablona ne dersiniz?

— user2813274

- @BenjaminPeikes Bisiklet kulübe önemsizlik Parkinson yasasına atıfta en.wikipedia.org/wiki/Parkinson's_law_of_triviality

— Grant

Yanıtlar:

Gerçekten, gerçekten hangi dosyaların hangi sanal makineye ait olduğunu kolayca tanımlayabilmek istiyorsunuz. Hyper-V konsoluna erişiminizi kaybetseniz bile.

Bu, bir sanal makineyi yedeklemelerden geri yüklemeye çalışırken ortaya çıkar. Veya Hyper-V tüm sanal makinelerinizi unuttuğunda ve bunları içe aktarmanız gerektiğinde. Veya VM yapılandırma dosyaları bozuktur ve VM'yi yeniden oluşturmanız ve eski sabit sürücü dosyalarını işaretlemeniz gerekir (yapılandırma dosyanız bozulduğundan artık tanımlayamazsınız). Veya her VM'nin ne kadar disk alanı kapladığını hızlıca kontrol etmek istersiniz. Veya dosya adlarını görebileceğiniz yedeklemelerden geri yüklemeniz gerekir, ancak önce tüm geri yükleme işlemine girmeden XML dosyalarını kolayca okuyamazsınız.

Bu göz önüne alındığında, her VM için bir klasör bulunan Şablon 1'e benzer bir şey için gideceğim - ancak "Sanal Makineler" ve "Sanal Makine Sabit Diskleri" alt klasörlerini dışarıda bıraktım - bir VM ile ilgili tüm dosyaları VM adında bir klasör.

Ayrıca Hyper-V \ Virtual makinelerine de ihtiyacınız yok - bu etiketlerden birini seçin, ikisine de ihtiyacınız yok.

Yani:

D: \ Sanal Makineler \ MACHINE_A \ GUID_1.xml
D: \ Sanal Makineler \ MACHINE_A \ Machine_a_OS.vhdx
D: \ Sanal Makineler \ MACHINE_A \ Machine_a_Data.vhdx

D: \ Sanal Makineler \ MACHINE_B \ GUID_2.xml
D: \ Sanal Makineler \ MACHINE_B \ Machine_b_OS.vhdx
D: \ Sanal Makineler \ MACHINE_B \ Machine_b_Data.vhdx

vb.

Veya sanal makineyle eşleşen dosya adlarına ihtiyacınız olmadığına karar verebilirsiniz - klasör adı yeterlidir. Bu şekilde adlandırmak, dosyaları yeniden adlandırma konusunda endişelenmenize gerek kalmadan bir VM'yi klonlamayı kolaylaştırır:

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

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

Buradaki ana paket, dosyaları, dosya yapısından başka bir şeye bakarak, her dosyanın hangi VM'ye ait olduğunu ve dosyanın ne için olduğunu söyleyecek şekilde organize etmektir.

— hibe
kaynak

Teklif ettiğin düzene doğru eğildim. Sevmediğim bu özel düzen hakkında bir şey, hem klasör yapısında hem de dosya adlandırma kuralında makine adını kullanmasıdır. Bu, yeni bir klasör oluşturmak için bir makinenin klasörünü kopyalayamayacağınız anlamına gelir.

— Benjamin Peikes

Duyduğum bir argüman, her bir GUID için xml dosyalarına bakarak hangi dosyaların hangi sanal makineye ait olduğunu söyleyebilmenizdir. Anlaşılması kolay bir adlandırma kuralına sahip olmak kesinlikle yararlı olsa da, biri bir kez bile takip etmezse tamamen parçalanır. Kodda artık kodla eşleşmeyen yorumlara sahip olmak gibi. Makine ile ilgili tüm bilgiler xml dosyasında olduğundan, bir şey bulmak için klasör ve dosyaların adlarına güvenmeye dikkat ediyorum.

— Benjamin Peikes

@BenjaminPeikes Dosyaları VM'lerle eşleştirmek için XML dosyalarına güvenmek risklidir. Yanlışlıkla silme veya veri bozulması yoluyla XML dosyalarının gittiği veya okunamadığı durumlar yaşadım. Ayrıca, GUID'leri eşleştirmekten daha hızlıdır. Ancak, dosya adında VM adını kullanmanız gerekmediğini kabul ediyorum, sadece isterseniz klasörü. Sadece - dosya yapısından başka hiçbir şeye bakmadan - hangi dosyaların hangi VM'ye ait olduğunu ve hangi amaca hizmet ettiklerini söyleyebilirsiniz.

— Hibe

Hiçbirini sevmiyorum.

Çünkü bir sanal makineyi taşımanız durumunda şablonlarınızın hiçbiri kararlı değildir.

Bunu yapardım - ve bunu kendim yapıyorum - ana bilgisayarlar arasında bir VM çalıştırdığınızda aldığınızla aynı klasör yapısını kullanın. Bu şekilde VM'yi ana bilgisayarlar arasında taşıdığınızda hiçbir şey değişmez.

— TomTom
kaynak

Şablon 1'i bir VM'yi ana bilgisayarlar arasında taşıdığınızda elde ettiğiniz şey değil mi?

— Benjamin Peikes

Deneyin - değil. Örneğin diskler, makine adı klasörü altındaki bir "Sanal Sabit Diskler" klasörüne yerleştirilir.

— TomTom

Şablon 1'in yaptığı budur. Her makinenin kendi klasörü vardır ve bu klasörlerin her birinde bir Sanal Makineler klasörü ve bir Sanal Sabit Diskler klasörü bulunur.

— Benjamin Peikes

VM oluşturulduğunda varsayılan olarak tanımladığınız yapıyı Hyper-V kullanmanın bir yolu var mı, @TomTom? VM'lerimi kendi klasörlerinin altına koymayı seviyorum. Ama her seferinde, VM'yi oluşturuyorum ve sonra istediğim klasör yapısını almak için hemen taşıyorum.

— Matty Brown

Sanal makine parçaları için kaplini depolama endişelerinden ayırmak için şablon 2'yi yapmanız gerekir. Bir VM için bir VHDX bir performans hacmi için gidebilir, aynı VM için başka bir VHDX kapasite ile daha fazla ilgilidir - ve hepsi esneklik farklılıklarıyla olabilir.

Bu nedenle, dosya yapısı düzenine, farklı depolama konumlarını sanal makineler dosya parçaları için kuplajla eşleştirmenin karmaşıklığını tanıtmadıkça şablon 1 yapamazsınız.

Böylece:

ŞABLON 2

Şablon 2 - Burada depolama yönetimi, ad alanları düzenine göre önceliklidir (bu arada, VM'yi yönetmek için kullanıcı arayüzünde ad alanı düzeni işlenir ... yani VM'nin bazı bölümleri yerel olmayabilir, ancak örneğin depolama alanını kullanarak bulutta vb. otobüs)

... depolama yönetimindeki farklı endişeleri yönetmek:

D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Sabit Diskler \ xxx-xx-xx-System-01-Prod.vhdx

D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Sabit Diskler \ xxx-xx-xx-Veri-01-Prod.vhdx

D: \ Depolama \ Havuz2 \ Hiper-V \ Sanal Sabit Diskler \ xxx-xx-xx-Veri-02-Prod.vhdx

D: \ Depolama \ Havuz3 \ Hiper-V \ Sanal Sabit Diskler \ xxx-xx-xx-Recovery-01-Prod.vhdx

D: \ Depolama \ Havuz1 \ Hyper-V \ Sanal Makineler \ GUID_1

D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Makineler \ GUID_1.xml

D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Makineler \ GUID_2

D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Makineler \ GUID_2.xml

ŞABLON 1

Bu eşlemeyi, dosya sistemindeki ad alanı endişelerinin (sözde bir sağlanan UI olarak da bilinir) öncelikli olduğu şablon 1'de yapmak için, depolama endişelerini korurken:

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-Sistem-01-Prod.vhdx> (bağlantılı) D: \ Storage \ Pool1 \ Hyper-V \ Sanal Sabit Diskler \ xxx- xx-xx-Sistem-01-Prod.vhdx

D: \ VM'ler \ xxx-xx-xx-01-Ürün \ xxx-xx-xx-Veri-01-Prod.vhdx> D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Sabit Diskler \ xxx-xx-xx- Veri-01-Prod.vhdx

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-Veri-02-Prod.vhdx> D: \ Depolama \ Havuz2 \ Hiper-V \ Sanal Sabit Diskler \ xxx-xx-xx- Veri-02-Prod.vhdx

D: \ VM'ler \ xxx-xx-xx-01-Ürün \ xxx-xx-xx-Kurtarma-01-Ürün.vhdx> D: \ Depolama \ Havuz3 \ Hiper-V \ Sanal Sabit Diskler \ xxx-xx-xx- Kurtarma-01-Prod.vhdx

D: \ VM'ler \ xxx-xx-xx-01-Ürün \ GUID_1> D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Makineler \ GUID_1 D: \ VM'ler \ xxx-xx-xx-01-Üretim \ GUID_1.xml > D: \ Storage \ Pool1 \ Hyper-V \ Sanal Makineler \ GUID_1.xml D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_2> D: \ Storage \ Pool1 \ Hyper-V \ Sanal Makineler \ GUID_2 D: \ VM'ler \ xxx-xx-xx-01-Ürün \ GUID_2.xml> D: \ Depolama \ Havuz1 \ Hiper-V \ Sanal Makineler \ GUID_2.xml

— computermensch
kaynak