हाइपर-वी सर्वर में फ़ाइल लेआउट के लिए सर्वोत्तम अभ्यास?


11

हमें एक हाइपर- V सर्वर सेट मिला है, और फाइलों का लेआउट असंगत है क्योंकि इसे कई लोगों द्वारा स्थापित किया गया था। यहां दो अलग-अलग "टेम्पलेट" का उपयोग किया गया था:

खाका १

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

....

तथा

खाका २

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 के लिए किया गया तर्क, यह था कि जब आप एक वीएम का निर्यात करते हैं तो निर्यात मशीन के नाम से एक फ़ोल्डर बनाता है, डिस्क और वीएम के लिए अलग-अलग फ़ोल्डर डालता है। जब आप एक आयात चलाते हैं तो आप बस मशीन निर्देशिका को इंगित कर सकते हैं।

तर्क इस टेम्पलेट शैली को स्वीकार करता है कि अगर वहाँ केवल एक फ़ाइल है तो वर्चुअल मशीन नामक एक निर्देशिका होने का कोई मतलब नहीं है। इसके विरूद्ध दूसरा तर्क यह है कि ऐसा प्रतीत होता है कि हाइपर- V सर्वर को स्वयं यह उम्मीद लगती है कि सभी हार्ड डिस्क एक फ़ोल्डर में हैं, और सभी वर्चुअल मशीन एक अलग फ़ोल्डर में हैं। यानी यह प्रत्येक वीएम के लिए अलग फ़ोल्डर नहीं बनाता है (वर्चुअल मशीन निर्देशिका में GUID द्वारा नामित लोगों के लिए अपवाद)

खाका २

टेम्पलेट 2 के लिए तर्क यह है कि ऐसा लगता है कि हाइपर-वी लेआउट के होने की उम्मीद करता है।

AGAINST टेम्प्लेट 2 का तर्क यह है कि आप यह नहीं बता सकते कि कौन सी वर्चुअल मशीन फाइलें किसी विशिष्ट मशीन से जुड़ी हैं, जब तक कि आप xml फाइलों के अंदर नहीं दिखते।

मैं लेआउट के किसी भी नुकसान के बारे में सुनना पसंद करूंगा।


2
ऐसा लग रहा है जैसे बाइक का शेड मेरे पास है।
इवान एंडरसन

2
मैं असहमत हूं। अनुभव से, नामकरण सम्मेलन होने के कुछ अच्छे तकनीकी कारण हैं जहां आप पहचान सकते हैं कि कौन से डिस्क हाइपर-वी टूल्स के बाहर से वीएम से संबंधित हैं। उनका एक विकल्प आपको आसानी से ऐसा करने की अनुमति नहीं देता है - या बिल्कुल भी, अगर हाइपर-वी एक्सएमएल फाइलें भ्रष्ट हैं, जो हो सकती हैं।
अनुदान

2
आप सही हे। टेम्प्लेट 2 वीएम के फोल्डर को अलग नहीं करता है, जो कि शुरुआती वीएचडी (एक्स) के लिए ठीक है, लेकिन बाद के वीएचडी (एक्स) के लिए समस्याग्रस्त हो सकता है जब तक कि आप उनके नामकरण के बारे में ईमानदार न हों।
जोकेवेटी

1
कैसे पथ में कोई जगह के साथ एक टेम्पलेट के बारे में?
user2813274

2
@BenjaminPeikes बाइक शेड में पार्किंसंस के तुच्छता के नियम का उल्लेख है - en.wikipedia.org/wiki/Parkinson_law_of_triviality
ग्रांट

जवाबों:


12

आप वास्तव में, वास्तव में आसानी से पहचानना चाहते हैं कि कौन सी फाइलें किस वर्चुअल मशीन से संबंधित हैं। भले ही आप हाइपर-वी कंसोल तक पहुंच खो देते हैं।

यह तब आता है जब वीएम को बैकअप से पुनर्स्थापित करने का प्रयास किया जाता है। या जब हाइपर-वी आपके सभी वीएम के बारे में भूल जाता है और आपको उन्हें आयात करने की आवश्यकता होती है। या VM कॉन्फ़िग फ़ाइल दूषित हैं, और आपको VM को फिर से बनाना है और पुरानी हार्ड ड्राइव फ़ाइलों (जो कि अब आप पहचान नहीं सकते हैं, क्योंकि आपकी कॉन्फ़िग फ़ाइल भ्रष्ट है) पर इंगित करना है। या आप बस यह जांचना चाहते हैं कि प्रत्येक वीएम कितना डिस्क स्थान लेता है। या आपको उन बैकअप से पुनर्स्थापित करने की आवश्यकता है जहां आप फ़ाइल नाम देख सकते हैं, लेकिन आसानी से XML फ़ाइलों को पहले पूरी पुनर्स्थापना प्रक्रिया से गुजरे बिना नहीं पढ़ सकते हैं।

यह देखते हुए कि, मैं टेम्पलेट 1 के समान कुछ के लिए जाऊंगा, जहाँ प्रत्येक वीएम के लिए एक फ़ोल्डर है - लेकिन "वर्चुअल मशीन" और "वर्चुअल मशीन हार्ड डिस्क" सबफ़ोल्डर को छोड़ दें - बस एक वीएम से संबंधित सभी फाइलों को इसमें डालें। VM के नाम के साथ एक फ़ोल्डर।

आपको हाइपर- V \ Virtual मशीनों की भी आवश्यकता नहीं है - उन लेबलों में से किसी एक को चुनें, आपको दोनों की आवश्यकता नहीं है।

इसलिए:

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 \ मशीन_b_OS.vhdx
D: \ Virtual Machines \ 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

यहां मुख्य टेकअवे फाइलों को व्यवस्थित करने के लिए है ताकि फ़ाइल संरचना के अलावा और कुछ न देखकर, आप यह बता सकें कि वीएम प्रत्येक फ़ाइल क्या है, और वह फ़ाइल किस लिए है।


मैं उस लेआउट की ओर झुक रहा हूँ जिसे आप प्रस्तावित करते हैं। इस विशेष लेआउट के बारे में एक बात जो मुझे पसंद नहीं है, वह यह है कि यह फ़ोल्डर की संरचना और फ़ाइल नामकरण सम्मेलन दोनों में मशीन के नाम का उपयोग करता है। इसका मतलब है कि आप बस एक नया बनाने के लिए मशीन के एक फ़ोल्डर की प्रतिलिपि नहीं बना सकते।
बेंजामिन पीएस

एक तर्क जो मैंने सुना है, वह यह है कि आप बता सकते हैं कि प्रत्येक GUID के लिए xml फ़ाइलों को देखकर कौन सी फाइलें किस वर्चुअल मशीन से संबंधित हैं। भले ही यह निश्चित रूप से उपयोगी है एक नामकरण सम्मेलन को समझना आसान है, यह पूरी तरह से अलग हो जाता है अगर कोई इसका पालन नहीं करता है, यहां तक ​​कि एक बार भी। यह कोड में टिप्पणी करने जैसा है जो कोड से मेल नहीं खाता है। चूँकि मशीन के बारे में पूरी जानकारी xml फ़ाइल में है, इसलिए मुझे कुछ भी पता लगाने के लिए फ़ोल्डर और फ़ाइलों के नामकरण पर निर्भर रहना चाहिए।
बेंजामिन पीएस

@BenjaminPeikes VMs में फ़ाइलों से मेल करने के लिए XML फ़ाइलों पर निर्भर करना जोखिम भरा है। मेरे पास ऐसे मामले हैं जहां या तो आकस्मिक विलोपन या डेटा भ्रष्टाचार के माध्यम से एक्सएमएल फाइलें चली गईं या अपठनीय थीं। इसके अलावा, यह केवल GUIDs के मिलान की तुलना में अधिक तेज़ है। लेकिन मैं मानता हूं कि आपको फ़ाइल नाम में VM नाम का उपयोग करने की आवश्यकता नहीं है, यदि आप चाहें तो बस फ़ोल्डर। बस यह सुनिश्चित करें कि - फ़ाइल संरचना के अलावा और कुछ भी नहीं - आप बता सकते हैं कि कौन सी फाइलें किस वीएम से संबंधित हैं और वे किस उद्देश्य से सेवा करते हैं।
ग्रांट

2

मुझे कोई पसंद नहीं है।

क्योंकि वीएम को स्थानांतरित करने के मामले में आपका कोई भी टेम्प्लेट स्थिर नहीं है।

मैं - और मैं खुद ऐसा करता हूं - एक फ़ोल्डर संरचना का उपयोग उसी के समान करें जो आपको तब मिलता है जब आप मेजबानों के बीच एक वीएम को एमवीओ करते हैं। इस तरह से कुछ भी नहीं बदलता है जब - आप मेजबान के बीच एक वीएम को स्थानांतरित करते हैं।


जब आप होस्ट के बीच एक वीएम को स्थानांतरित करते हैं तो क्या टेम्पलेट 1 नहीं होता है?
बेंजामिन ने

यह कोशिश करो - यह नहीं है। उदाहरण के लिए मशीन नाम फ़ोल्डर के तहत "वर्चुअल हार्ड डिस्क" फ़ोल्डर में डिस्क समाप्त हो जाती है।
टॉमटॉम

यही मेरा खाका 1 करता है। प्रत्येक मशीन में स्वयं फ़ोल्डर होता है, और उन सभी फ़ोल्डरों में एक वर्चुअल मशीन फ़ोल्डर और एक वर्चुअल हार्ड डिस्क फ़ोल्डर होता है।
बेंजामिन ने

1
क्या VM को @TomTom बनाते समय, उस संरचना का उपयोग करने का कोई तरीका है जिसे आपने डिफ़ॉल्ट रूप से वर्णित किया है? मुझे अपना VM अपने खुद के फ़ोल्डर में रखना पसंद है। लेकिन हर बार, मैं VM को तब बनाना चाहता हूं जब मैं चाहता हूं कि फ़ोल्डर संरचना प्राप्त करने के बाद इसे सीधे स्थानांतरित कर दूं।
मैटी ब्राउन

1

स्टोरेज चिंताओं से वर्चुअल मशीन भागों के लिए अलग-अलग युग्मन के लिए आपको टेम्पलेट 2 करने की आवश्यकता है। वीएम के लिए एक वीएचडीएक्स एक प्रदर्शन की मात्रा के लिए जा सकता है, एक ही वीएम के लिए एक और वीएचडीएक्स क्षमता से अधिक चिंतित है - और सभी के बीच मतभेद के साथ हो सकता है।

इसलिए आप टेम्पलेट 1 को तब तक नहीं कर पाएंगे जब तक कि आप फ़ाइल संरचना लेआउट में अलग-अलग स्टोरेज स्थानों को मैप करने की जटिलता को वर्चुअल मशीन फ़ाइल भागों के लिए युग्मन में शामिल नहीं करते हैं।

इस प्रकार:

मंदिर २

टेम्प्लेट 2 - यहाँ स्टोरेज मैनेजमेंट नेमस्पेस लेआउट के बारे में पूर्वता लेता है (इस बीच, VM के प्रबंधन के लिए यूआई में नेमस्पेस लेआउट को संभाला जाता है ... अर्थात VM के कुछ भाग स्थानीय नहीं हो सकते हैं, लेकिन उदाहरण के लिए स्टोरेज का उपयोग करके क्लाउड आदि में हो सकते हैं। बस)

... भंडारण प्रबंधन में विभिन्न चिंताओं का प्रबंधन:

D: \ Storage \ Pool1 \ Hyper-V \ Virtual हार्ड डिस्क \ xxx-xx-xx-System-01-Prod.vxx

D: \ Storage \ Pool1 \ Hyper-V \ Virtual हार्ड डिस्क \ xxx-xx-xx-Data-01-Prod.vidx

D: \ Storage \ Pool2 \ Hyper-V \ Virtual हार्ड डिस्क \ xxx-xx-xx-Data-02-Prod.vidx

D: \ Storage \ Pool3 \ Hyper-V \ Virtual हार्ड डिस्क \ xxx-xx-xx-Recovery-01-Prod.vxx

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

टेम्प्लेट 1

टेम्पलेट 1 में इस मैपिंग को करने के लिए - जहाँ फ़ाइल सिस्टम में नाम स्थान की चिंता (उर्फ एक छद्म प्रावधानित यूआई) पूर्वता लेता है - भंडारण चिंताओं को बनाए रखते हुए:

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-System-01-Prod.vhdx> (से जुड़ा हुआ) D: \ Storage \ Pool1 \ Hyper-V \ Virtual हार्ड डिस्क / xxx xx-xx-सिस्टम-01-Prod.vhdx

D: \ VMs \ xxx-xx-xx-01-Prod \ xxx-xx-xx-Data-01-Prod.vhdx> D: \ Storage \ Pool1 \ Hyper-V \ Virtual हार्ड डिस्क \ 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 हार्ड डिस्क \ 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 हार्ड डिस्क \ 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: \ Storage \ Pool1 \ Hyper-V \ Virtual Machines \ GUID_1.xml D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_2> D: \ Storage \ Pool1 \ Hyper-V की वर्चुअल मशीनें \ GUID_2 D: \ VMs \ xxx-xx-xx-01-Prod \ GUID_2.xml> D: \ Storage \ Pool1 \ Hyper-V \ Virtual मशीनें \ GUID_2.xml

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.