VMware पर लिनक्स - विभाजन का उपयोग क्यों करें?


46

जब एक आभासी वातावरण (मेरे मामले में ईएसएक्सआई) में लिनक्स वीएम स्थापित करते हैं, तो क्या प्रत्येक माउंट बिंदु के लिए अलग-अलग डिस्क जोड़ने के बजाय डिस्क (एक्स 4 का उपयोग करते हुए) को विभाजित करने के लिए कोई बाध्यकारी कारण हैं?

केवल एक ही मैं देख सकता हूं कि यह देखने के लिए कुछ हद तक आसान बनाता है कि क्या उदाहरण के लिए डिस्क जैसे डेटा पर मौजूद है fdisk।

दूसरी ओर, मैं विभाजन का उपयोग करने के कुछ अच्छे कारणों को देख सकता हूं (/ बूट के अलावा, स्पष्ट रूप से)।

  • डिस्क का विस्तार करने के लिए बहुत आसान है। यह केवल वीएम (आमतौर पर वीसीएनआर) के लिए डिस्क का आकार बढ़ाने के लिए है, फिर वीएम में डिवाइस को रीसेट करें, और ऑनलाइन फाइल सिस्टम का आकार बदलें।
  • अंतर्निहित LUN के साथ विभाजन को संरेखित करने के साथ कोई और समस्या नहीं है।

मुझे इस विषय पर बहुत कुछ नहीं मिला। क्या मैं कुछ महत्वपूर्ण याद किया है?


16
ओह और मैं बस यह टिप्पणी करना चाहता था कि एसएफ के अन्य 'उच्च प्रतिनिधि' उपयोगकर्ता खुद को कैसे प्रभावित करते हैं और आपके पहले प्रश्न के साथ थे। हम कभी-कभी नए लोगों की पिटाई करने का आरोप लगाते हैं लेकिन यह वास्तव में ऐसा है कि बहुत सारे नए उपयोगकर्ता नहीं पढ़ते हैं कि हम क्या कर रहे हैं और हम क्या नहीं कर रहे हैं - इसलिए मैंने सोचा कि मुझे बस एक उपयुक्त प्रश्न पूछने के लिए धन्यवाद कहना चाहिए अच्छी तरह से लिखा और माना तरीका :)
चोपर 3

5
मेरे पास दो टिप्पणियां हैं हालांकि: 1) VMWare एक उत्पाद नहीं है, बल्कि एक कंपनी है। VMWare ESXi एक उत्पाद होगा। 2) मैं इस प्रश्न को सामान्य रूप से वर्चुअलाइज्ड वातावरण के बारे में बताता हूं, क्योंकि यह KVM, Xen और HyperV के लिए समान रूप से प्रासंगिक है।
स्वेन

1
धन्यवाद। और मैंने शब्दों को थोड़ा और सामान्य करने के लिए संपादित किया है।
सवा

@ सावासोचे आपको जवाब देना चाहिए।
ewwhite

जवाबों:


27

यह एक दिलचस्प सवाल है...

मुझे नहीं लगता कि कोई निश्चित उत्तर है, लेकिन मैं इस विषय पर कुछ ऐतिहासिक संदर्भ दे सकता हूं कि समय के साथ इस विषय के आसपास की सर्वोत्तम प्रथाओं को कैसे बदला जा सकता है।

मुझे 2007 के बाद से VMware के वातावरण में विभिन्न रूपों में तैनात हजारों लिनक्स वीएम का समर्थन करना पड़ा है। तैनाती के लिए मेरा दृष्टिकोण विकसित हुआ है, और मुझे अन्य इंजीनियरों द्वारा निर्मित विरासत और रीफैक्टरिंग सिस्टम का अनूठा ( कभी-कभी दुर्भाग्यपूर्ण ) अनुभव मिला है।

पुराने दिन...

दिन में वापस (2007), मेरे शुरुआती VMware सिस्टम को मेरे नंगे धातु प्रणालियों की तरह विभाजित किया गया था। VMware की तरफ, मैं VM के डेटा को सम्‍मिलित करने के लिए स्प्लिट 2GB मोटी फ़ाइलों का उपयोग कर रहा था, और कई VMDKs की धारणा के बारे में सोचा भी नहीं था, क्योंकि मैं अभी खुश था कि वर्चुअलाइजेशन भी काम कर सकता था!

वर्चुअल इन्फ्रास्ट्रक्चर ...

ESX 3.5 और आरंभिक ESX / ESXi 4.x रिलीज़ (2009-2011) तक, मैं लिनक्स का उपयोग कर रहा था, जो सामान्य रूप से विभाजित मोटी वीएमडीके फाइलों के रूप में विभाजित था । उपदेश भंडारण के बाद मुझे इस तरह से लिनक्स डिजाइन के बारे में सोचने के लिए मजबूर किया, जैसा कि मैं वास्तविक हार्डवेयर के साथ करूंगा। मैं ऑपरेटिंग सिस्टम के लिए 36GB, 72GB, 146GB VMDK बना रहा था, जो सामान्य /, / बूट, / usr, / var, / tmp को विभाजित करता है, फिर "डेटा" या "ग्रोथ" पार्टीशन के लिए एक और VMDK जोड़ रहा है (चाहे वो / हो घर, / ऑप्ट या कुछ आवेदन-विशिष्ट)। फिर, इस युग के दौरान भौतिक हार्ड डिस्क के आकार में मीठा-स्थान 146GB था, और चूंकि प्रचार की आवश्यकता थी (जब तक कि एनएफएस का उपयोग नहीं किया गया), मुझे अंतरिक्ष के साथ रूढ़िवादी होने की आवश्यकता थी।

पतली प्रावधान का आगमन

बाद में ESXi 4.x रिलीज़ में वीएमवेयर ने थिन प्रोविजनिंग के आसपास बेहतर सुविधाएँ विकसित कीं, और इसने मुझे नए सिस्टम को स्थापित करना शुरू कर दिया। पूर्ण फ़ीचर सेट को 5.0 / 5.1 में जोड़े जाने के साथ, एक नए प्रकार के लचीलेपन ने अधिक रचनात्मक डिजाइनों की अनुमति दी। ध्यान रहे, यह वर्चुअल मशीनों पर बढ़ी हुई क्षमताओं के साथ तालमेल बैठा रहा था, कितने वीसीपीयूएस और व्यक्तिगत वीएम के लिए कितनी रैम हो सकती है। अतीत की तुलना में अधिक प्रकार के सर्वर और एप्लिकेशन को वर्चुअलाइज किया जा सकता है। यह सही है क्योंकि कंप्यूटिंग वातावरण पूरी तरह से आभासी होने लगे थे।

LVM भयानक है ...

जब तक VM स्तर पर पूर्ण हॉट-ऐड फ़ंक्शनलिटी जगह और आम (2011-2012) थी, तब तक मैं एक फर्म के साथ काम कर रहा था जो किसी भी कीमत ( बेवकूफ ) पर अपने ग्राहकों के वीएम के लिए अपटाइम बनाए रखने के लिए प्रयास करता था । तो यह ऑनलाइन VMware सीपीयू / रैम बढ़ जाती है और शामिल जोखिम भरा एलवीएम डिस्क मौजूदा VMDKs पर आकार बदलने। इस वातावरण में अधिकांश लिनक्स सिस्टम LVM के शीर्ष पर ext3 विभाजन के साथ एकल VMDK सेटअप थे। यह भयानक था क्योंकि LVM परत ने परिचालन में जटिलता और अनावश्यक जोखिम जोड़ा । उदाहरण के लिए / usr में अंतरिक्ष से बाहर निकलते हुए, बुरे फैसलों की एक श्रृंखला हो सकती है जो अंततः बैकअप से एक प्रणाली को बहाल करने का मतलब है ... यह आंशिक रूप से प्रक्रिया और संस्कृति से संबंधित था, लेकिन फिर भी ...

विभाजन स्नोबेरी ...

मैंने इसे बदलने का प्रयास करने का अवसर लिया । मैं लिनक्स में एक विभाजन-स्नोब का एक सा हूं और महसूस करता हूं कि निगरानी और परिचालन आवश्यकताओं के लिए फाइल सिस्टम को अलग किया जाना चाहिए। मैं LVM को भी नापसंद करता हूं, विशेष रूप से VMware और आपके द्वारा पूछे जाने वाले काम को करने की क्षमता के साथ। इसलिए मैंने VMDK फ़ाइलों के विभाजन का विस्तार किया जो संभावित रूप से बढ़ सकता था। / ऑप्ट, / var, / होम जरूरत पड़ने पर अपनी स्वयं की वर्चुअल मशीन फ़ाइलें प्राप्त कर सकते हैं। और वे कच्चे डिस्क होंगे। कभी-कभी यह मक्खी पर विशेष रूप से बिना विभाजन के विस्तार के लिए एक आसान तरीका था।

Obamacare ...

एक बहुत ही हाई-प्रोफाइल क्लाइंट के ऑनबोर्डिंग के साथ , मुझे लिनक्स वीएम संदर्भ टेम्प्लेट के डिज़ाइन के साथ काम सौंपा गया था जो कि उनके अत्यंत दृश्यमान एप्लिकेशन वातावरण बनाने के लिए उपयोग किया जाएगा । अनुप्रयोग की सुरक्षा आवश्यकताओं में आरोह का एक अनूठा सेट आवश्यक है , इसलिए डेवलपर्स के साथ काम करने के लिए एक VMDK पर गैर-वृद्धि विभाजन को रटना करने की कोशिश करें, और फिर प्रत्येक माउंट के लिए अलग-अलग VMDKs जोड़ें जो विकास की क्षमता या विशिष्ट आवश्यकताओं (एन्क्रिप्शन) था ऑडिटिंग, आदि) तो, अंत में, इन वीएम में 5 या अधिक वीएमडीके शामिल थे, लेकिन भविष्य के आकार और डेटा की सुरक्षा के लिए सबसे अच्छा लचीलापन प्रदान किया गया।

मैं आज क्या करूँ ...

आज, लिनक्स और पारंपरिक फाइल सिस्टम के लिए मेरा सामान्य डिजाइन एक पतली वीएमडीके (विभाजन) पर ओएस है, और किसी अन्य चीज के लिए वीएमडीके को असतत करें। मैं आवश्यक रूप से हॉट-ऐड करूंगा। ZFS जैसे उन्नत फाइलसिस्टम के लिए, यह OS के लिए एक VMDK है, और एक अन्य VMDK जो ZFS zpool के रूप में कार्य करता है और इसे आकार दिया जा सकता है, अतिरिक्त ZFS फाइल सिस्टम में खुदी हुई है, आदि।


2
ओह गीज़, मुझे सुपर ओल्ड महसूस कराने के लिए धन्यवाद। मेरे लिए 2007 अभी भी "लगभग चालू" है। :-)
ब्रायन नोबलुच

1
एक माउंटपॉइंट के रूप में जोड़े जा रहे अतिरिक्त VMDK का विभाजन नहीं होता है।
ewwhite

1
हर तकनीक की सीमा होती है, और उस पृष्ठ पर कुछ भी आपके दावे का समर्थन नहीं करता है कि LVM भयानक है। मैं आपको सलाह दूंगा कि आप अपने उत्तर के उस हिस्से को संशोधित करें, क्योंकि यह एक FUD से अधिक लाभकारी जानकारी है। पुनश्च। क्षमा करें, यदि मेरी कोई भी टिप्पणी कठोर प्रतीत होती है, तो मैं वास्तविक काम करने के बीच लिखने का उपयोग करता हूं, इसलिए मैं अक्सर यह नहीं सोचता कि मेरे शब्द दूसरों को कैसे सुनाए जा सकते हैं।
जकोव सोसिक

5
"बैक इन द डे" 2007 था? मैं 1999 में आईबीएम में एक मानार्थ लाइसेंस प्राप्तकर्ता था जब संस्करण 1 को भेज दिया गया था। मैं एक VM डायनासोर हूं: D (तरंग @BrianKnoblauch)। आपकी LVM टिप्पणियों के अनुसार, ऐसा लगता है जैसे आप इसे लिनक्स के संदर्भ में आंक रहे हैं। लिनक्स से पहले वर्षों के लिए वाणिज्यिक UNIX भूमि में LVM परिपक्व प्रौद्योगिकी। यदि आपने टॉप-एंड सोलारिस / स्पार्क / ईएमसी सिमेट्रिक्स प्रबंधित किया था, तो लिनक्स एक कदम नीचे की तरह था (और अभी भी कई मायनों में है)। छोटे डिस्क के दिनों में, LVM ने बहु-टेराबाइट डेटाबेस को प्रबंधनीय बना दिया। मुझे आपके द्वारा बताई गई समस्याएं कभी नहीं थीं, जो वास्तव में लोगों की समस्याओं की तरह लगती हैं, हालांकि मैं निश्चित रूप से संबंधित कर सकता हूं।
कोडेनहेम

1
LVM को कोसने के बावजूद +1। बाकी का जवाब स्पष्ट अनुभव से अच्छा सामान है।
कोडेनहेम

7

आप कई मायनों में सही हैं, मैं तर्क देख सकता हूं - एक मुद्दा है जो हालांकि मुश्किल साबित हो सकता है। यदि आप संसाधन पूल का उपयोग करते हैं (और मुझे पता है कि मैं घृणित चीजें नहीं करता हूं) तो वीएम अधिक IO समय प्राप्त कर सकते हैं यदि उनके पास अधिक डिस्क हैं - चरम संसाधन में बाधाएं स्थितियों में दो डिस्क के साथ एक वीएम दो बार अधिक से अधिक IO संसाधन प्राप्त कर सकता है। एक डिस्क। यह अच्छी तरह से आप के लिए एक मुद्दा नहीं हो सकता है, लेकिन मैंने सोचा कि मैं इसे इंगित करता हूं।

संपादित करें - ओह और यह थोड़ा धीमा भी कर देगा, लेकिन फिर से यह एक मुद्दा नहीं हो सकता है।


6

जब मैंने एक विशेष "बड़े वर्चुअलाइजेशन सॉफ्टवेयर कंपनी" के बुनियादी ढांचे में काम किया, तो हमें अक्सर वीएम के फाइल सिस्टम के आकार को बढ़ाने की आवश्यकता होती है। हमने उस समय ext3 / 4 का उपयोग किया था।

वर्चुअल डिस्क को बढ़ाना बहुत आसान है, लाइव ओएस में नए डिवाइस का आकार चुनना अपेक्षाकृत आसान है (लगभग / pys में poke), ext3 / 4 फाइलसिस्टम लाइव का आकार बदलना आसान था, लेकिन जो हमेशा असंभव लगता था (लाइव करने के लिए) विभाजन का आकार बदलना।

आपको विभाजन का उपयोग करने के लिए gparted या rewrite / resizeite / resize का उपयोग करना था - लेकिन इसे हमेशा कर्नेल द्वारा लॉक किया गया था और नए लेआउट को लेने के लिए कर्नेल प्राप्त करने के लिए रिबूट की आवश्यकता थी (partprobe ने यह भी नहीं किया।

मैंने कई प्रणालियों को LVM में स्थानांतरित कर दिया और फ़ाइल सिस्टम का आकार बदलना एक आसान, लगभग सुखद, अनुभव बन गया!

  • VM के बाहर वर्चुअल डिस्क छवि बढ़ाएँ
  • वीएम में,
    • डिस्क मेट्रिक्स (echo "1"> / sys / class / scsi_device // device / rescan) को पुन: सक्रिय करने के लिए प्रहार / साइज़ करें
    • pvresize / dev / sdX (LVM में भौतिक आयतन का आकार बदलें)
    • lvresize --extents + 100% मुफ़्त / dev / VG / lvolXX (LVM में तार्किक आयतन का आकार बदलें)
    • resize2fs (फाइल सिस्टम का आकार बदलें)

यह सब एक जीवित प्रणाली पर सुरक्षित रूप से किया जा सकता है - और किसी भी रिबूट की आवश्यकता नहीं है!

नंगे डिस्क क्यों नहीं? यह मुझे परेशान करता है - मुझे नहीं लगता कि नंगे डिस्क व्यापक रूप से अभी तक पर्याप्त रूप से स्वीकार किए जाते हैं, लेकिन मुझे लगता है कि हम बहुत व्यापक स्वीकृति के कगार पर हैं। इससे संबंधित btrfs मेलिंग सूची में एक धागा था:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

लेकिन एक नंगे डिस्क को सिर्फ rescan और resize2fs की जरूरत होगी।

तो, सारांश में, हाँ, यदि आप कर सकते हैं तो विभाजन तालिकाओं से बचें।


1
आपको कर्नेल को विभाजन तालिका को फिर से पढ़ने के लिए रिबूट की आवश्यकता नहीं है। लेकिन आपको रिसाइज्ड डिवाइस पर फाइल सिस्टम (ओं) को अनमाउंट करना होगा (जो कि / विभाजन है तो मुश्किल है)। उस विभाजन सारणी के अलावा अन्य दस्तावेजी उद्देश्यों की सेवा कर रहे हैं - हर कोई और उसके चाचा fdisk -lएक अज्ञात डिस्क के बारे में देखने के लिए (या संगत समकक्ष) चलाएंगे । यदि यह अप्रतिबंधित है, तो यह आसानी से "खाली" और ओवरराइट के लिए गलत हो सकता है। यही कारण है कि मैं हमेशा डिस्क के लिए एक विभाजन तालिका बनाता हूं । LVM बुराई है, यद्यपि।
वैबबिट

इन विशिष्ट वीएम पर मेरा अनुभव नहीं है, हालांकि यह दूसरों पर अतीत में काम कर चुका है। Fs को अनमाउंट करने से लॉक मुक्त नहीं हुआ। शायद यह सिर्फ Centos5 था, मुझे पता नहीं था। मैं स्तब्ध था। विभाजन की दुनिया में, LVM कमाल का है। नई btrfs / zfs दुनिया में, यह अप्रचलित है। IMHO, बिल्कुल।
rrauenza

मुझे यह महसूस करने में थोड़ा समय लगा कि आप वास्तव में VM के अंदर lvm का उपयोग कर रहे थे ... क्या कोई कारण है कि आप होस्ट पर LVM का उपयोग नहीं करते हैं और अतिथि को डिस्क के रूप में उपयोग करने के लिए एक lv देते हैं? आकार बदलने के चरण होंगे: मेजबान में वॉल्यूम का आकार, अतिथि पर rescan, अतिथि पर resize2fs।
GnP

हां, वीएम के अंदर। चूंकि यह esx के अंतर्गत है इसलिए वर्चुअल डिस्क को vmdk फ़ाइल होना चाहिए। हां, सैद्धांतिक रूप से हम अतिथि में एक कच्ची डिस्क का उपयोग कर सकते थे।
rrauenza

नंगे डिस्क का उपयोग करना बहुत सरल है - 5 में से 2 चरणों को हटा देता है, जिसमें एलवीएम को जानने की कोई आवश्यकता नहीं है। LVM में FS का आकार बदलना जोखिम भरा है, हालांकि यह बेहतर हो रहा है: LVM खतरे और चेतावनी
रिचवेल

1

जबकि आपका प्रश्न लिखित रूप में VMWare (ESXi) के बारे में है, मैं एक ऐसी स्थिति जोड़ना चाहूंगा जहां मैंने KVM पर समान विचार के बाद विभाजन तालिका का उपयोग करके वापस स्विच किया हो।

यह पता चला है कि यदि आपके पास वीएम के लिए वीवीएम वॉल्यूम है और विभाजन का उपयोग किए बिना वीएम के अंदर एलवीएम वॉल्यूम समूह बना सकते हैं (पीवी के रूप में पूरे वर्चुअल डिस्क का उपयोग करके), तो यह वीजी होस्ट मशीन पर वीएम के बाहर दिखाई देगा। यदि आप PV के रूप में विभाजन का उपयोग करते हैं तो यह मामला नहीं है।

दी, यह एक कोने का मामला है लेकिन अगर आपको इस तरह के सेटअप की आवश्यकता है, तो यह विचार करने लायक है।


आपको वीएम में वीवी पर वीजी की आवश्यकता क्यों होगी? (ध्यान दें कि मैं LVM के लिए नया हूँ, मैं आपके रास्ते को नहीं समझ रहा हूँ, बस इस तरह के सेटअप का उपयोग करने की कोशिश कर रहा हूँ)
GnP

होस्टेड LVs को फ़िल्टर करने के लिए आप होस्ट पर LVM फ़िल्टर का उपयोग कर सकते हैं।
मिरिके वुटकोविसी

1

यह करना बेहतर है या नहीं यह आपके सिस्टम पर निर्भर करता है।

प्रत्येक सेटअप के पेशेवरों और विपक्ष हैं।

हालाँकि, एकल ड्राइव के मुख्य लाभ इस प्रकार हैं:

  1. सरलता: एक एकल ड्राइव में एक एकल फ़ाइल होती है, जिसे आसानी से वितरित और दोहराया जा सकता है।
  2. होस्ट ओएस के लिए संकेत: एक एकल फ़ाइल को डेटा के एक एकल ब्लॉक के रूप में माना जाएगा, और इसलिए होस्ट ओएस को पता चल जाएगा कि अतिथि मशीन पहुंच के अनुक्रम सभी उस एक फ़ाइल में होंगे। यह केवल एक ही फाइल में सभी ड्राइव छवियों को रखकर कुछ होस्ट OS कॉन्फ़िगरेशन पर प्राप्त किया जा सकता है, लेकिन यह जरूरी नहीं होगा।

हालांकि, मल्टी-ड्राइव करने के फायदे हैं।

  1. नंगे धातु की आत्मीयता / मैनुअल स्थान: एक एकल ड्राइव के साथ आप ड्राइव के एकल नंगे-धातु संबंध में बंद हो जाते हैं।
  2. आकार सीमाएँ: यदि आपके सिस्टम में ड्राइव के आकार या फाइलों पर सीमाएँ हैं, तो आप उन्हें बहुत बड़ी प्रणालियों पर मार सकते हैं।
  3. सुरक्षा के लिए रीड-ओनली वॉल्यूम: यह बड़ा फायदा है यदि ओएस के लिए आपका मास्टर वॉल्यूम केवल वीएम पक्ष पर पढ़ा जाता है तो यह प्रमुख सुरक्षा लाभ प्रदान करता है, अनिवार्य रूप से अतिथि के बेस ओएस को संपादित करने से वीएम के अंदर कार्यक्रमों की क्षमता को लॉक करना। एक अलग डेटा ड्राइव का उपयोग आपको रीड-ओनली ड्राइव बनाने की अनुमति देता है, जिसमें केवल क्लीनरूम टेम्पलेट डेटा के बिना रखरखाव और अपडेट के लिए रीड-राइट को बूट किया जा सकता है, सर्वर के भीतर से महत्वपूर्ण ओएस निर्देशिकाओं के संशोधन को रोका जा सकता है।

मल्टी-ड्राइव आपको स्वतंत्र मोड में कुछ डिस्क फ़ाइलों को (कम से कम ईएसएक्सआई पर) देता है। इस तरह आप स्नैप और स्नैप आधारित बैकअप में उदाहरण के लिए अस्थायी डेटा सहित से बच सकते हैं।
दिलकश

1

एक और विकल्प है: एनएफएस वॉल्यूम पर एप्लिकेशन डेटा माउंट करें। आपको अच्छे फाइलरों की आवश्यकता है (सभी एनएफएस कार्यान्वयन समान नहीं हैं)।

जब एनएफएस वॉल्यूम भरते हैं, तो वॉल्यूम का विस्तार करें, लिनक्स क्लाइंट को अतिरिक्त स्थान तुरंत दिखाई देगा।

आपके आवेदन और विक्रेता को एनएफएस पर इसके डेटा होने का समर्थन करना चाहिए, और आपको एक सावधान NAS डिजाइन की आवश्यकता है, लेकिन इसलिए आप अपने आभासी वातावरण के लिए हर भंडारण समाधान के साथ करते हैं।

इस दृष्टिकोण के लिए एक और बोनस बिंदु यह है कि यदि आपके स्टोरेज वेंडर के पास स्नैपशॉटिंग / क्लोनिंग तकनीक (जैसे zfs या नेटप्प) है तो डेटा का बैकअप लेना और परीक्षण / देव वातावरण बनाना वास्तव में आसान है।


0

जिस कारण से आपको अभी भी कुछ लिनक्स वितरणों के लिए डिस्क को विभाजन करने की आवश्यकता है, इस तथ्य के कारण है कि इसके साथ जाने के लिए एक बूटलोडर और सभी विरासत के टुकड़े हैं, अर्थात एमुसेटेड BIOS। इससे डिस्क का आकार बदलना कठिन हो जाता है और कई लोग LVM या इसी तरह की अन्य गैर-समझ का उपयोग कर समाप्त हो जाते हैं।

एक व्यक्ति पूरे सिस्टम पर बस एक फाइल सिस्टम बना सकता है और उस पर माउंट कर सकता है /, जो कि बहुत ही कस्टम (या कस्टमाइजेबल / नॉन-ऑप्टीमेटेड) लिनक्स वितरण के साथ काम करेगा। पिछली बार जब मैंने उबंटू 12.04 के साथ यह कोशिश की थी, तो इंस्टॉलर को यह नहीं पता था कि इसे कैसे संभालना है क्योंकि यह उनके बेवकूफ विभाजन तालिका को सभी जैज को स्थापित करना होगा। यह वर्चुअलाइज्ड दुनिया में सामान्य उद्देश्य वितरण की समस्या है।

दूसरी ओर, वास्तव में एक कम पारंपरिक उपयोग के लिए विभाजन रखा जा सकता है, उदाहरण के लिए ChromeOS और CoreOS में सिस्टम अपग्रेड के लिए दो रीड-ओनली रूट विभाजन हैं।


0

एक कारण जो अब तक उल्लेख नहीं किया गया है, वह यह है कि कुछ बुनियादी ढांचे जैसे कि Google कंप्यूट में, डिस्क IO प्रदर्शन डिस्क के आकार के साथ रैखिक रूप से बढ़ता है । दूसरे शब्दों में, एक बड़ी विभाजन ड्राइव में कई छोटे ड्राइव की तुलना में बेहतर IO प्रदर्शन होगा।

ध्यान दें कि यह आम तौर पर हालांकि मामला नहीं है। जैसा कि चॉपर 3 द्वारा बताया गया है कि कई बार कई ड्राइव में बेहतर आईओ प्रदर्शन होगा। अंतत: यदि आपके सभी वर्चुअल ड्राइव को सिंगल फिजिकल ड्राइव पर मैप किया जाता है, तो कोई अंतर नहीं होना चाहिए।


0

मेरे अनुभव में बेहतर दृष्टिकोण ओएस के लिए 1 VMDK का उपयोग करना है और मैं आमतौर पर इसे निम्नलिखित तरीके से विभाजित करता हूं:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

मैंने 8GB को / के लिए पर्याप्त पाया है, क्योंकि मैं आमतौर पर न्यूनतम लिनक्स वितरण (~ 800MB) + सॉफ़्टवेयर स्थापित करता हूं, जिनकी मुझे आवश्यकता होती है। लॉग भी उस विभाजन पर जाते हैं, लेकिन यदि सही तरीके से सेट किया गया है (एक सप्ताह के लिए लॉग्रोट), और कहीं और भेज दिया (सिस्लॉग / इलास्टिसर्च) तो वे आमतौर पर विभाजन को भरने के लिए इलाज नहीं करते हैं।

डेटा को एक और VMDK के रूप में जोड़ा जाता है, और मैं आमतौर पर नंगे डिस्क (जैसे / देव / एसडीबी) पर सीधे फाइलसिस्टम को प्रारूपित करता हूं। यह मुझे VmWare में वॉल्यूम का आकार बदलने की अनुमति देता है, और इसे वीएम में सीधे पुनरावृत्ति / umount / रिबूट की आवश्यकता के बिना आकार देता है।


मुझे पसंद है कि आपने विशेष रूप से / स्वैप के बाद अपनी स्वैप कैसे विभाजित की है, कुछ ऐसा जो मैंने हाल ही में पता लगाया है (2008 या तो)। चारों ओर एक पुरानी फूला हुआ कर्नेल छवि रखने के कारण मामूली / बूट भागों में खिंचाव होता है, और sda2 / to बूट को खिलाने से अक्सर पर्याप्त जगह मिलती है। यह होने का मतलब यह है कि पीवी होल्डिंग रूट का कोई स्थानांतरण नहीं है, और यह एक मुश्किल ऑपरेशन को बचाता है जिसे कभी-कभी दूरस्थ रूप से करने की आवश्यकता होती है। :-)
user2066657

0

मैं दो कारणों से विभाजित हूं:

  1. दस्तावेज़ीकरण - मैंने एक बार "प्रशिक्षित" EMC प्रशासक को LUNs मेरे नीचे से चुराया था क्योंकि वे अनिर्दिष्ट थे और उन्हें असंबद्ध लग रहा था, और रात के बीच में, ओरेकल डेटाबेस के लिए मंचित किया गया था - अचानक वह ऑफ़लाइन हो गया था। उन्होंने एक असंबंधित ऐप के लिए मेरे LUN को एक और वॉल्यूम के लिए फिर से प्रावधान किया था। तब से मैं प्रलेखन के बारे में पागल हूँ।
  2. मेरी डिस्क पर ओवर-प्रोविजनिंग। प्लैटर्स के साथ यह धीमे सिलेंडरों का डेटा बंद रखता है और एसएसडी के साथ, यह जीवनकाल / एमटीबीएफ का विस्तार करता है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.