C: \ OS के लिए है, D: \ Data के लिए है?

Question

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

अब वह सर्वर स्टोरेज केवल SAN पर होने की संभावना है (जहां डिस्क संसाधनों को कई अलग-अलग ऑपरेटिंग सिस्टम और एप्लिकेशन द्वारा साझा किया जाता है), क्या वास्तव में यह अधिक मायने रखता है कि ओएस और डेटा विभाजन को वॉल्यूम स्तर पर अलग किया जा सकता है?

आपके क्या विचार हैं?

Answer 1

OS और Data को अलग-अलग स्टोरेज-वार रखने के लिए तीन मुख्य ड्राइवर हैं।

1. अंतरिक्ष । जैसा कि एरिका बताते हैं, आप वास्तव में वास्तव में नहीं चाहते हैं कि आपका ओएस वॉल्यूम अंतरिक्ष से बाहर चला जाए। हर तरह की बुरी बातें हो सकती हैं। इन दोनों वृद्धि विधियों को अलग करना
2. आई / ओ पहुँच आवश्यकताओं । आपके OS वॉल्यूम पर उपयोग किए जाने वाले I / O का प्रकार आमतौर पर आपके डेटा वॉल्यूम द्वारा उपयोग किए गए प्रकार से बहुत भिन्न होता है। अपने I / O प्रकार को अलग रखना कई स्तरों पर एक बहुत अच्छा विचार है।
3. भंडारण पोर्टेबिलिटी । जब आपके सर्वर ओएस को अपग्रेड करने का समय आता है, तो आप ओएस वॉल्यूम को न्यूक कर सकते हैं और सभी डेटा रख सकते हैं। या SAN या VM परिवेशों में आप डेटा वॉल्यूम को एक नए, ताज़ा स्थापित सर्वर में स्थानांतरित कर सकते हैं और अपग्रेड पर समय बचा सकते हैं।

इसके अलावा, कुछ ऑपरेटिंग सिस्टम (विंडोज उनके बीच में है) ओएस वॉल्यूम को आकार देने में बहुत अधिक विनम्रता नहीं लेते हैं, जिसका अर्थ है कि आपको सर्वर को प्रारूपित करते समय अपने जीवनकाल में इसकी जितनी आवश्यकता होगी, उतनी देने की जरूरत है। इसके विपरीत डेटा वॉल्यूम जो एक सर्वर के जीवनकाल में कई बार पुन: आकार ले सकते हैं। यहां तक ​​कि पूरी तरह से वर्चुअलाइज्ड वातावरण में जहां ओएस और डेटावॉल्म्स खुद एक ही वास्तविक स्टोरेज में रखे जा रहे हैं, आपके ओएस वॉल्यूम को आकार देने में सक्षम नहीं होना एक प्रमुख बाधा हो सकती है। Windows 2008+ अब C: \ ड्राइव के लिए इन दिनों 30GB की सिफारिश कर रहा है, 10GB से बहुत दूर रोना जो हम सर्वर 2003 पर उपयोग कर रहे थे; यह कुछ के रूप में वे 2003 से 2008 तक रूपांतरण बनाने कि कई विंडोज व्यवस्थापक कील होगा।

Comments

ये अच्छे बिंदु हैं और वे उस साझा भंडारण प्रबंधन से संबंधित गहन मुद्दों पर छूते हैं। उदाहरण: यदि आपका C: और D: समान RAID कॉन्फ़िगरेशन में स्पिंडल के एक ही सेट पर हैं, तो आप OO प्रकार के लिए ऑप्टिमाइज़ नहीं कर सकते हैं। स्टोरेज पोर्टेबिलिटी के लिए, यह सुनिश्चित करने के लिए समान रूप से महत्वपूर्ण है कि सी और डी ड्राइव वास्तव में अलग-अलग हैं जो भी वस्तु वर्चुअल स्टोरेज का समर्थन कर रही है। अन्यथा, यदि वे एक ही LUN पर विभाजन कर रहे हैं तो आप एक पूर्ण प्रतिलिपि के बिना एक नए सर्वर पर नहीं जा सकते।

— जेरेमी

Answer 2

हाँ, सबसे निश्चित रूप से डेटा से अलग ओएस। मैंने इसे समय और समय फिर से देखा है, जहां एक साझा विभाजन के साथ, विभाजन समाप्त होता है और ओएस को पैच करना असंभव बना देता है, विभाजन का विस्तार करना असंभव (विभिन्न कारणों के कारण), आदि।

IMO, दो विभाजनों के प्रबंधन का ओवरहेड प्रदान किए गए अलगाव के लिए भुगतान करने के लिए एक छोटी सी कीमत है।

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

Comments

अजीब बात है, कारणों से आप ओएस और डेटा को अलग करने के लिए देने के जिन कारणों मैं नहीं ऐसा करने के लिए है वास्तव में कर रहे हैं।

— जॉन Gardeniers

हां, मुझे लगता है कि ऐसे मामले हैं (विशेष रूप से गैर-वर्चुअलाइज्ड सर्वर के लिए प्रत्यक्ष-संलग्न डिस्क के साथ) जहां आपके निपटान में एक बड़ी बाल्टी ओ 'डिस्क रखना फायदेमंद हो सकता है।

— EEAA

: एक दिलचस्प ओर ध्यान दें, ओएस पुनर्स्थापना के दौरान कुछ अजीब हो रहा है की वजह से, मेरे Windows OS ड्राइव एफ के बंद जूते: और मेरे अतिरिक्त डेटा ड्राइव सी के रूप में दिखाता है

— ब्रायन Knoblauch

Answer 3

मैं कहूंगा कि यह इस बात पर निर्भर करता है कि आप सिस्टम के साथ क्या कर रहे हैं। तो आपको एक अलग विभाजन पर अपने सभी डेटा के रख कर अपने आप को कुछ परेशानी की बचत हो सकती आप ओएस को पुनर्स्थापित करने की आवश्यकता हो सकती है। अन्यथा मुझे आवश्यकता नहीं दिखती है। मेरे दो सेंट।

Answer 4

सामान्य सिद्धांत में, मुझे लगता है कि डिफ़ॉल्ट OS स्थान को अलग करना (जैसे C :) डेटा से (D :) एक अच्छा विचार है, लेकिन मैं लॉग फ़ाइलों के लिए एक छोटा विभाजन बनाने की भी सिफारिश करूंगा (L :) उन्हें थोड़ा रखने के लिए अधिक सुरक्षित और कुछ प्रकार के डेनियल-ऑफ-सर्विस हमलों को रोकना।

लिनक्स बहुत अच्छा है कि फाइल सिस्टम एक रूट डायरेक्टरी के तहत पदानुक्रम में बना रहता है, चाहे आप कितने भी भौतिक डिस्क या वर्चुअल पार्टिशन का उपयोग करें। मैं निश्चित रूप से डिस्क का विभाजन करूंगा, लेकिन जरूरी नहीं कि डेटा बनाम ओएस सेपरेशन के लिए (चूंकि बहुत बार दोनों को वैसे भी मिला दिया जाता है)।

मैं इसे देखूंगा:

1. कौन सा उपनिर्देशिका अन्य निर्देशिकाओं के लिए उनके डिस्क और कारण अंतरिक्ष समस्याओं (यानी पार्टीशन बंद / घर और / var / उदाहरण के लिए लॉग) को भरने की संभावना है।
2. चाहे प्रदर्शन कारणों से अपने निर्देशिका संरचना की जरूरत अलग फाइल सिस्टम के विभिन्न भागों (यानी स्थिरता के लिए XFS, सभी के आसपास उपयोग, आदि के लिए Ext3)
3. कौन सा निर्देशिका भविष्य में विस्तार की जरूरत हो सकती - इन विभाजन क्योंकि आप बस निर्देशिका, विभाजन का नाम बदलें और निर्देशिका स्थान पर डिस्क स्थान का एक नया सेट माउंट कर सकते हैं के लिए अच्छा उम्मीदवार हैं, और पुराने से नए डेटा कॉपी स्थान।

Answer 5

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

आप एक डेस्कटॉप प्रणाली का निर्माण कर रहे हैं, तो मैं डेटा / गैर डेटा / स्वैप विभाजन के लिए जाना चाहते हैं। जब तक आप एक सर्वर का निर्माण नहीं कर रहे हैं जो गंभीर रूप से लेने की उम्मीद कर रहा है, सेपरेट / usr / लोकल और / var / tmp जैसे सामान सिर्फ एक स्पेस एलोकेशन सिरदर्द बन जाता है।

Comments

मैं कहता हूं कि लॉग और अस्थायी अलग थे क्योंकि उनमें एक दुष्ट उपयोगकर्ता से बकवास भरा होने की क्षमता थी - जैसा कि ओएस आमतौर पर एक साझा, बहु-उपयोगकर्ता वातावरण है। मुझे यकीन नहीं था कि विश्वसनीयता एक कारक थी।

— gbjbaanb

Answer 6

मैं कहूंगा कि इसका अभी भी अच्छा है - आपके पास 100 जीबी डेटा (बहुत ज्यादा प्रीड ड्यूड :)) है और आपको ओएस को फिर से स्थापित करने की आवश्यकता है (या, विंडोज इतिहास को ध्यान में रखते हुए, इसे बिल्ट-अप हटाने के लिए नियमित रूप से इंस्टॉल करें। cruft) तो इसका बहुत ही सरल मामला इसे बरकरार रखने के लिए, जैसे कि यह सी विभाजन पर भी था।

हालाँकि, मैं कहूँगा कि वहाँ एक समस्या है क्योंकि विंडोज विशेष रूप से सी ड्राइव पर निर्देशिकाओं में सभी प्रकार के सामानों को भरना पसंद करता है - इसके न केवल 'उपयोगकर्ता' निर्देशिका, बल्कि सभी एप्लिकेशन डेटा और विभिन्न बिट्स और टुकड़े जो अंत में अटक जाते हैं। ProgramData में भी।

इसके अलावा, एक और कारक है - वास्तव में बड़े सामान (हाँ, उस pr0n फिर से) के अलावा ऑनलाइन बैकअप उपकरण (या स्थानीय बैकअप उपयोगिताओं) के बहुत सारे हैं जो निरंतर बैकअप करते हैं। इन को देखते हुए, डेटा को अलग करने के लिए अपनी तरह के नहीं एक प्राथमिकता, के रूप में आप आसानी से बैकअप स्थान से बहाल कर सकते हैं।

व्यक्तिगत रूप से, मैं विभाजित करने के लिए डेटा + ओएस प्रयास करें। मैं एक अलग पार्टीशन पर भी ऐप्स डालने की कोशिश करता हूं, ताकि मेरे ओएस बैकअप बहुत छोटे हो जाएं।

Answer 7

मैं विचार के एक अलग स्कूल के लिए शैतान का वकील बनूंगा।

प्रदर्शन के कारणों के लिए मान लीजिए, आपका विक्रेता की अनुशंसा है कि OS विभाजन "विरल" नहीं है और आप पूर्ण OS विभाजन अग्रिम आवंटित करने के लिए चाहता है। पर सैन ड्राइव अप्रयुक्त स्थान की 20GB (या अधिक) के लिए 10Gb में यह परिणाम है।

यह एक एकल वीएम के लिए ठीक है, लेकिन संभावना है कि आपके पास कई "प्रदर्शन महत्वपूर्ण" सर्वर होंगे, जिनमें से प्रत्येक के पास 10 से 20 जीबी का व्हाट्सएप ओवरहेड होगा। हमारे वातावरण में इस व्हाट्सएप का 20% हिस्सा हमारे सैन डिस्क के लिए है। ध्यान रखें कि ऐसी सीमाएं हैं जिनके लिए हमें एक SAN डिस्क भरना चाहिए (लेकिन यह एक और कहानी है)।

प्रबंधन के पास एक विकल्प था

1) पर सैन, जो "श्वेत स्थान" की अन्य आवश्यकताओं के अतिरिक्त है 20% बर्बाद अंतरिक्ष को सोखना, और किसी भी "पूर्ण डिस्क" परिदृश्य है कि हो सकता है अलग

2) सी: \ ड्राइव पर सब कुछ रखो और एप्लिकेशन लॉग के कारण ड्राइव को भरने का जोखिम उठाएं।

उन्होंने क्या किया?

यह देखते हुए कि विंडोज 2008R2 गतिशील मेजबान ओएस सी विस्तार कर सकते हैं: \ ड्राइव, और ड्राइव का विस्तार कर सकते हैं जब पूरा, प्रबंधन लागत "बचत" ले लिया और SCOM जैसे उपकरणों की निगरानी में यह पुनर्निवेश।

अब हम एक सी का सिर्फ सरल सुरक्षा की तुलना में अधिक हो रही है: \ ड्राइव भरने, लेकिन हम एक और अधिक पूरा करने वाले सिस्टम की निगरानी से पहले ऐसा होता है अन्य चिंताओं को दूर करने की है।

Comments

पतला प्रावधान सैन मात्रा मोटी डेटा की वजह से प्रावधान बनने की एक आदत है समय के साथ मंथन, जब तक आप सॉफ्टवेयर ओएस जो वापस सैन करने के लिए कब संचार एक फ़ाइल हटा दिया गया है में चल रहा है। एक SAN वातावरण में, आप आमतौर पर बूट ड्राइव के लिए उतनी ही जगह आवंटित करना बेहतर समझते हैं, और यह स्वीकार करते हुए कि यह सब समय पर उपयोग किया जाएगा। सैन इसे और अधिक जटिल बनाता है, हालांकि, मैं आपको दे दूंगा! शायद आपको C और D दोनों के लिए एक ही SAN वॉल्यूम आवंटित किया जा सकता है (कई अन्य कारकों पर निर्भर करता है, जैसे डिस्क प्रदर्शन और वर्कलोड आवश्यकताएं)।

— जेरेमी