सवाल एलवीएम खतरे और चेतावनी


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

एलवीएम का उपयोग करने के डाउनसाइड्स क्या हैं?


177
2018-06-12 07:34


मूल


इस प्रश्न के उत्तर पढ़ने पर, ध्यान दें कि उन्हें (दिनांक) पोस्ट किया गया था। इस उद्योग में 3 वर्षों में बहुत कुछ होता है। - MattBianco
मैंने हाल ही में कुछ अपडेट किए हैं (अप्रैल 2015) यह देखने के लिए स्कैन किया गया है कि कुछ भी बदल गया है या नहीं। 2.6 कर्नेल अब अप्रचलित है, एसएसडी अधिक आम हैं, लेकिन कुछ छोटे एलवीएम फिक्स के अलावा वास्तव में बहुत कुछ नहीं बदला है। मैंने एलवीएम स्नैपशॉट्स के बजाय वीएम / क्लाउड सर्वर स्नैपशॉट्स का उपयोग करने पर कुछ नई चीजें लिखीं। लेखन कैशिंग, फाइल सिस्टम आकार बदलने और LVM स्नैपशॉट्स की स्थिति वास्तव में जहां तक ​​मैं देख सकता हूं, वास्तव में बहुत कुछ नहीं बदला है। - RichVel
"भालू को ध्यान में रखते हुए" टिप्पणी के बारे में - पर्याप्त सच है, लेकिन यह भी मानते हैं कि बहुत से "उद्यम" अभी भी आरएचईएल 5 और आरएचईएल 6 का उपयोग कर रहे हैं, जिनमें से दोनों अत्याधुनिक हैं या तिथि से पुराने हैं उत्तर का - JDS


जवाब:


सारांश

एलवीएम का उपयोग करने के जोखिम:

  • एसएसडी या वीएम हाइपरवाइजर के साथ कैशिंग मुद्दों को लिखने के लिए कमजोर
  • अधिक जटिल ऑन-डिस्क संरचनाओं के कारण डेटा पुनर्प्राप्त करना कठिन होता है
  • फाइल सिस्टम का आकार बदलना मुश्किल है
  • स्नैपशॉट्स का उपयोग करना मुश्किल है, धीमी और छोटी गाड़ी
  • इन मुद्दों को सही तरीके से कॉन्फ़िगर करने के लिए कुछ कौशल की आवश्यकता है

पहले दो एलवीएम मुद्दे गठबंधन करते हैं: यदि लेखन कैशिंग सही ढंग से काम नहीं कर रहा है और आपके पास बिजली की कमी है (उदा। पीएसयू या यूपीएस विफल रहता है), तो आपको बैकअप से पुनर्प्राप्त करना होगा, जिसका मतलब महत्वपूर्ण डाउनटाइम है। एलवीएम का उपयोग करने का एक मुख्य कारण उच्च अपटाइम है (डिस्क जोड़ते समय, फाइल सिस्टम का आकार बदलते समय), लेकिन लिविंग वास्तव में अपटाइम को कम करने से बचने के लिए लेखन कैशिंग सेटअप सही करना महत्वपूर्ण है।

- सितम्बर 2017 को अपडेट किया गया: पुराने कर्नेल सामग्री को कम प्रमुख बना दिया

जोखिम को कम करना

एलवीएम अभी भी अच्छी तरह से काम कर सकता है अगर आप:

  • हाइपरवाइजर, कर्नेल और एसएसडी में अपना लेखन कैशिंग सेटअप प्राप्त करें
  • LVM स्नैपशॉट से बचें
  • फाइल सिस्टम का आकार बदलने के लिए हाल ही के LVM संस्करणों का उपयोग करें
  • अच्छे बैकअप लें

विवरण

मैंने अतीत में थोड़ा सा शोध किया है जिसमें एलवीएम से जुड़े कुछ डेटा हानि का अनुभव हुआ है। मुख्य एलवीएम जोखिम और मुद्दे जिनके बारे में मुझे पता है वे हैं:

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

  • हार्ड ड्राइव द्वारा कैशिंग लिखें और फिर से ऑर्डर लिखें अच्छे प्रदर्शन के लिए महत्वपूर्ण है, लेकिन वीएम हाइपरवाइजर, हार्ड ड्राइव लेखन कैशिंग, पुराने लिनक्स कर्नेल इत्यादि के कारण डिस्क पर ब्लॉक को फ्लश करने में असफल हो सकता है।
    • बाधाओं को लिखें इसका मतलब है कि कर्नेल गारंटी देता है कि यह "बाधा" डिस्क लिखने से पहले कुछ डिस्क लिखने को पूरा करेगा, यह सुनिश्चित करने के लिए कि फाइल सिस्टम और RAID अचानक बिजली की हानि या क्रैश की स्थिति में ठीक हो सकती है। ऐसी बाधाएं एक का उपयोग कर सकती हैं एफयूए (फोर्स यूनिट एक्सेस) ऑपरेशन डिस्क पर कुछ ब्लॉक तुरंत लिखने के लिए, जो एक पूर्ण कैश फ्लश से अधिक कुशल है। बाधाओं को कुशल के साथ जोड़ा जा सकता है चिह्नित/देशी कमांड क्यूइंग (एक साथ कई डिस्क I / O अनुरोध जारी करना) हार्ड ड्राइव को डेटा हानि के जोखिम को बढ़ाए बिना बुद्धिमान लेखन पुन: क्रम करने के लिए सक्षम करने के लिए सक्षम बनाता है।
  • वीएम हाइपरवाइजर समान समस्याएं हो सकती हैं: वीएमवेयर जैसे वीएम हाइपरवाइजर के शीर्ष पर लिनक्स अतिथि में LVM चलाना, एक्सईएन, केवीएम, हाइपर-वी या वर्चुअलबॉक्स बना सकते हैं इसी तरह की समस्याएंलिखने की बाधाओं के बिना कर्नेल को, कैशिंग लिखने और पुन: क्रम लिखने के कारण। "डिस्क पर फ्लश" या लिखने के माध्यम से कैश विकल्प (वर्तमान में) के लिए सावधानीपूर्वक अपने हाइपरवाइज़र दस्तावेज़ देखें केवीएम, VMware, एक्सईएन, VirtualBox और अन्य) - और इसे अपने सेटअप के साथ परीक्षण करें। वर्चुअलबॉक्स जैसे कुछ हाइपरवाइजर हैं एक डिफ़ॉल्ट सेटिंग जो अतिथि से किसी भी डिस्क फ्लश को अनदेखा करता है।
  • LVM के साथ एंटरप्राइज़ सर्वर हमेशा एक का उपयोग करना चाहिए बैटरी समर्थित RAID नियंत्रक और हार्ड डिस्क लेखन कैशिंग अक्षम करें (नियंत्रक बैटरी बैक लिखने कैश है जो तेज़ और सुरक्षित है) - देखें यह टिप्पणी के लेखक द्वारा यह एक्सएफएस एफएक्यू एंट्री। यह भी सुरक्षित हो सकता है लेखन बाधाओं को बंद करें कर्नेल में, लेकिन परीक्षण की सिफारिश की जाती है।
  • यदि आपके पास बैटरी-समर्थित RAID नियंत्रक नहीं है, तो हार्ड ड्राइव लेखन कैशिंग अक्षम करने से महत्वपूर्ण रूप से लिखना धीमा हो जाएगा लेकिन एलवीएम सुरक्षित होगा। आपको ext3 के समतुल्य का भी उपयोग करना चाहिए data=ordered विकल्प (या data=journal अतिरिक्त सुरक्षा के लिए), प्लस barrier=1 यह सुनिश्चित करने के लिए कि कर्नेल कैशिंग अखंडता को प्रभावित नहीं करता है। (या ext4 का उपयोग करें जो डिफ़ॉल्ट रूप से बाधाओं को सक्षम बनाता है।) यह सबसे आसान विकल्प है और प्रदर्शन की लागत पर अच्छी डेटा अखंडता प्रदान करता है। (लिनक्स डिफ़ॉल्ट ext3 विकल्प बदल दिया अधिक खतरनाक के लिए data=writeback थोड़ी देर पहले, इसलिए एफएस के लिए डिफ़ॉल्ट सेटिंग्स पर भरोसा न करें।)
  • हार्ड ड्राइव लेखन कैशिंग अक्षम करने के लिएजोड़ें hdparm -q -W0 /dev/sdX सभी ड्राइव के लिए /etc/rc.local (एसएटीए के लिए) या एससीएसआई / एसएएस के लिए एसडीपीआरएम का उपयोग करें। हालांकि, के अनुसार यह प्रविष्टि एक्सएफएस एफएक्यू (जो इस विषय पर बहुत अच्छा है) में, एक एसएटीए ड्राइव ड्राइव त्रुटि वसूली के बाद इस सेटिंग को भूल सकती है - इसलिए आपको एससीएसआई / एसएएस का उपयोग करना चाहिए, या यदि आपको सैटा का उपयोग करना चाहिए तो एक क्रॉन जॉब में hdparm कमांड डालें हर मिनट या तो चल रहा है।
  • एसएसडी / हार्ड ड्राइव लेखन कैशिंग सक्षम रखने के लिए बेहतर प्रदर्शन के लिए: यह एक जटिल क्षेत्र है - नीचे अनुभाग देखें।
  • यदि आप उपयोग कर रहे हैं उन्नत प्रारूप ड्राइव यानी 4 केबी भौतिक क्षेत्र, नीचे देखें - लेखन कैशिंग को अक्षम करने में अन्य समस्याएं हो सकती हैं।
  • यूपीएस एंटरप्राइज़ और एसओएचओ दोनों के लिए महत्वपूर्ण है लेकिन एलवीएम सुरक्षित बनाने के लिए पर्याप्त नहीं है: कुछ भी जो हार्ड क्रैश या पावर लॉस (उदा। यूपीएस विफलता, पीएसयू विफलता, या लैपटॉप बैटरी थकावट) का कारण बनता है, हार्ड ड्राइव कैश में डेटा खो सकता है।
  • बहुत पुराने लिनक्स कर्नेल (200 9 से 2.6.एक्स): बहुत पुराने कर्नेल संस्करणों में अपूर्ण लेखन बाधा समर्थन है, 2.6.32 और इससे पहले (2.6.31 में कुछ समर्थन है, जबकि 2.6.33 काम करता है सभी प्रकार के डिवाइस लक्ष्य के लिए) - आरएचईएल 6 2.6.32 का उपयोग करता है कई पैच के साथ। यदि इन पुराने 2.6 कर्नेल इन मुद्दों के लिए अप्रतिबंधित हैं, तो बड़ी संख्या में एफएस मेटाडाटा (पत्रिकाओं सहित) को हार्ड क्रैश द्वारा खोया जा सकता है जो हार्ड ड्राइव के लिखने वाले बफर में डेटा छोड़ देता है (सामान्य सैटा ड्राइव के लिए 32 एमबी प्रति ड्राइव कहें)। सबसे हाल ही में लिखित एफएस मेटाडाटा और जर्नल डेटा का 32 एमबी खोना, जो कर्नेल सोचता है कि डिस्क पर पहले से ही है, आमतौर पर बहुत सारे एफएस भ्रष्टाचार और इसलिए डेटा हानि का मतलब है।
  • सारांश: आपको फाइल सिस्टम, RAID, VM हाइपरवाइजर, और हार्ड ड्राइव / एसएसडी सेटअप में LVM के साथ उपयोग करना चाहिए। यदि आप LVM का उपयोग कर रहे हैं, तो आपके पास बहुत अच्छे बैकअप होना चाहिए, और विशेष रूप से LVM मेटाडेटा, भौतिक विभाजन सेटअप, एमबीआर और वॉल्यूम बूट सेक्टर का बैकअप लें। एससीएसआई / एसएएस ड्राइव का उपयोग करने की भी सलाह दी जाती है क्योंकि इन्हें झूठ बोलने के तरीके के बारे में झूठ बोलने की संभावना कम होती है - सैटा ड्राइव का उपयोग करने के लिए अधिक देखभाल की आवश्यकता होती है।

लेखन कैशिंग सक्षम रखना प्रदर्शन के लिए (और झूठ बोलने के साथ मुकाबला)

एसएसडी / हार्ड ड्राइव लिखने कैशिंग सक्षम रखने के लिए एक और जटिल लेकिन प्रदर्शन विकल्प है और कर्नेल 2.6.33+ पर एलवीएम के साथ काम कर रहे कर्नेल लेखन बाधाओं पर भरोसा करते हैं (लॉग में "अवरोध" संदेशों को देखकर दोबारा जांच करें)।

आपको यह भी सुनिश्चित करना चाहिए कि RAID सेटअप, वीएम हाइपरवाइजर सेटअप और फाइल सिस्टम लेखन बाधाओं का उपयोग करता है (यानी कुंजी मेटाडाटा / पत्रिका लिखने से पहले और बाद में लंबित लिखने के लिए ड्राइव की आवश्यकता होती है)। एक्सएफएस डिफ़ॉल्ट रूप से बाधाओं का उपयोग करता है, लेकिन ext3 नहीं करता है, तो ext3 के साथ आप का उपयोग करना चाहिए barrier=1 माउंट विकल्पों में, और अभी भी उपयोग करें data=ordered या data=journal ऊपरोक्त अनुसार।

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

SSDs समस्याग्रस्त हैं क्योंकि एसएसडी के जीवनकाल के लिए लेखन कैश का उपयोग महत्वपूर्ण है। एक एसएसडी का उपयोग करना सबसे अच्छा है जिसमें सुपरकेपसिटर होता है (पावर विफलता पर कैश फ्लश करने में सक्षम बनाता है, और इसलिए कैश को लिखने के लिए लिखने में सक्षम बनाता है)।

उन्नत प्रारूप ड्राइव सेटअप - कैशिंग, संरेखण, RAID, जीपीटी लिखें

  • नए के साथ उन्नत प्रारूप ड्राइव जो 4 कीबी भौतिक क्षेत्रों का उपयोग करते हैं, ड्राइव लिखने कैशिंग सक्षम रखना महत्वपूर्ण हो सकता है, क्योंकि वर्तमान में ऐसे अधिकांश ड्राइव 512 बाइट लॉजिकल सेक्टर का अनुकरण करते हैं ("512 अनुकरण"), और कुछ लोग 512-बाइट भौतिक क्षेत्रों का दावा करते हैं जबकि वास्तव में 4 कीबी का उपयोग करते हैं।
  • एक उन्नत प्रारूप ड्राइव के लिखने वाले कैश को बंद करने से एप्लिकेशन / कर्नेल 512 बाइट लिख रहा है, तो इस तरह के ड्राइव 8 x 512-बाइट लिखने के लिए कैश पर भरोसा करते हैं, एक सिंगल 4 कीबी भौतिक करने से पहले लिखो। यदि आप कैश को अक्षम करते हैं तो किसी भी प्रभाव की पुष्टि करने के लिए परीक्षण की अनुशंसा की जाती है।
  • 4 कीबी सीमा पर एलवी को संरेखित करना प्रदर्शन के लिए महत्वपूर्ण है लेकिन जब तक पीवी के लिए अंतर्निहित विभाजन गठबंधन होते हैं, तब तक स्वचालित रूप से तब तक होना चाहिए, क्योंकि डिफ़ॉल्ट रूप से LVM भौतिक विस्तार (पीई) 4 एमआईबी हैं। RAID यहां पर विचार किया जाना चाहिए - यह एलवीएम और सॉफ्टवेयर RAID सेटअप पेज एक विकल्प का उपयोग कर वॉल्यूम के अंत में RAID superblock डालने और (यदि आवश्यक हो) डालने का सुझाव देता है pvcreate पीवी संरेखित करने के लिए। यह एलवीएम ईमेल सूची धागा 2011 के दौरान कर्नल में किए गए कार्यों को इंगित करता है और आंशिक ब्लॉक का मुद्दा लिखता है जब एक एकल एलवी में 512 बाइट और 4 केईबी क्षेत्रों के साथ डिस्क मिश्रण करते हैं।
  • उन्नत प्रारूप के साथ जीपीटी विभाजन विशेष रूप से बूट + रूट डिस्क के लिए देखभाल की ज़रूरत है, यह सुनिश्चित करने के लिए कि पहला एलवीएम विभाजन (पीवी) 4 कीबी सीमा पर शुरू होता है।

अधिक जटिल ऑन-डिस्क संरचनाओं के कारण डेटा पुनर्प्राप्त करना कठिन होता है:

  • हार्ड क्रैश या पावर लॉस (गलत लेखन कैशिंग के कारण) के बाद आवश्यक LVM डेटा की कोई भी पुनर्प्राप्ति एक मैन्युअल प्रक्रिया है, क्योंकि स्पष्ट रूप से कोई उपयुक्त टूल नहीं हैं। एलवीएम इसके मेटाडेटा को बैक अप लेने में अच्छा है /etc/lvm, जो एलवी, वीजी और पीवी की मूल संरचना को पुनर्स्थापित करने में मदद कर सकता है, लेकिन खोए गए फाइल सिस्टम मेटाडेटा में मदद नहीं करेगा।
  • इसलिए बैकअप से पूर्ण पुनर्स्थापना की आवश्यकता है। LVM का उपयोग न करने पर त्वरित जर्नल-आधारित fsck की तुलना में इसमें बहुत अधिक डाउनटाइम शामिल है, और अंतिम बैकअप के बाद से लिखा गया डेटा खो जाएगा।
  • TestDisk, ext3grep, ext3undel तथा अन्य उपकरण  गैर-एलवीएम डिस्क से विभाजन और फ़ाइलों को पुनर्प्राप्त कर सकते हैं लेकिन वे सीधे LVM डेटा वसूली का समर्थन नहीं करते हैं। टेस्टडिस्क यह पता लगा सकता है कि खोए गए भौतिक विभाजन में एक एलवीएम पीवी है, लेकिन इनमें से कोई भी उपकरण LVM लॉजिकल वॉल्यूम्स को समझता नहीं है। फाइल नक्काशी जैसे उपकरण PhotoRec और कई अन्य काम करेंगे क्योंकि वे डेटा ब्लॉक से फ़ाइलों को फिर से इकट्ठा करने के लिए फाइल सिस्टम को बाईपास करते हैं, लेकिन यह मूल्यवान डेटा के लिए एक अंतिम-रिसॉर्ट, निम्न-स्तरीय दृष्टिकोण है, और खंडित फ़ाइलों के साथ कम अच्छी तरह से काम करता है।
  • कुछ मामलों में मैन्युअल एलवीएम रिकवरी संभव है, लेकिन जटिल और समय लेने वाला है - देखें यह उदाहरण तथा इस, इस, तथा इस कैसे ठीक हो सकता है।

फाइल सिस्टम का आकार बदलना मुश्किल है - आसान फाइल सिस्टम आकार बदलने को अक्सर LVM के लाभ के रूप में दिया जाता है, लेकिन आपको LVM आधारित FS का आकार बदलने के लिए आधा दर्जन खोल कमांड चलाने की आवश्यकता होती है - यह पूरे सर्वर के साथ अभी भी किया जा सकता है, और कुछ मामलों में एफएस घुड़सवार, लेकिन मैं कभी भी बैकअप के बिना उत्तरार्द्ध को जोखिम नहीं उठाऊंगा और समकक्ष सर्वर (उदाहरण के लिए उत्पादन सर्वर की आपदा रिकवरी क्लोन) पर प्री-टेस्ट किए गए आदेशों का उपयोग नहीं करूँगा।

  • अद्यतन करें: के हाल के संस्करण lvextend का समर्थन -r (--resizefs) विकल्प - यदि यह उपलब्ध है, तो यह एलवी और फाइल सिस्टम का आकार बदलने का एक सुरक्षित और तेज़ तरीका है, खासकर अगर आप एफएस को कम कर रहे हैं, और आप ज्यादातर इस सेक्शन को छोड़ सकते हैं।
  • एलवीएम-आधारित एफएस का आकार बदलने के लिए अधिकांश मार्गदर्शिका इस तथ्य का अधिक नहीं लेती हैं कि एफएस एलवी के आकार से कुछ हद तक छोटा होना चाहिए: यहां विस्तृत स्पष्टीकरण। फाइल सिस्टम को कम करते समय, आपको एफएस आकार बदलने के उपकरण के लिए नया आकार निर्दिष्ट करना होगा, उदा। resize2fs ext3 के लिए, और करने के लिए lvextend या lvreduce। बहुत सावधानी के बिना, 1 जीबी (10 ^ 9) और 1 के बीच के अंतर के कारण आकार थोड़ा अलग हो सकते हैं GiB (2 ^ 30), या जिस तरह से विभिन्न औजार गोल आकार ऊपर या नीचे।
  • यदि आप गणना बिल्कुल सही नहीं करते हैं (या सबसे स्पष्ट चरणों से परे कुछ अतिरिक्त चरणों का उपयोग करें), तो आप एक एफएस के साथ समाप्त हो सकते हैं जो एलवी के लिए बहुत बड़ा है। महीनों या वर्षों तक सब कुछ ठीक लगेगा, जब तक आप पूरी तरह से एफएस भर नहीं लेते, उस बिंदु पर आपको गंभीर भ्रष्टाचार मिलेगा - और जब तक आप इस मुद्दे से अवगत न हों, तब तक यह पता लगाना मुश्किल क्यों है, क्योंकि आपके पास वास्तविक डिस्क त्रुटियां भी हो सकती हैं वह स्थिति बादल। (यह संभव है कि यह समस्या केवल फाइल सिस्टम के आकार को कम करने पर प्रभाव डालती है - हालांकि, यह स्पष्ट है कि किसी भी दिशा में फाइल सिस्टम का आकार बदलने से डेटा हानि का खतरा बढ़ जाता है, संभवतः उपयोगकर्ता त्रुटि के कारण।)
  • ऐसा लगता है कि एलवी आकार एफएस आकार से 2 x एलवीएम भौतिक सीमा (पीई) आकार से बड़ा होना चाहिए - लेकिन विवरण के लिए ऊपर दिए गए लिंक को जांचें क्योंकि इसका स्रोत आधिकारिक नहीं है। अक्सर 8 एमआईबी की अनुमति पर्याप्त होती है, लेकिन अधिक अनुमति देने के लिए बेहतर हो सकता है, उदा। 100 एमआईबी या 1 जीबीबी, बस सुरक्षित होने के लिए। पीई आकार, और आपके लॉजिकल वॉल्यूम + एफएस आकारों की जांच करने के लिए, 4 KiB = 4096 बाइट ब्लॉक का उपयोग करके:

    KiB में पीई आकार दिखाता है:
    vgdisplay --units k myVGname | grep "PE Size"

    सभी एलवी का आकार:
    lvs --units 4096b

    (Ext3) एफएस का आकार, 4 KiB एफएस ब्लॉकize मानता है:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • इसके विपरीत, एक गैर-एलवीएम सेटअप एफएस को बहुत भरोसेमंद और आसान चलाने का आकार बदलता है gparted और आवश्यक एफएस का आकार बदलें, तो यह आपके लिए सबकुछ करेगा। सर्वर पर, आप इसका उपयोग कर सकते हैं parted खोल से

    • इसका उपयोग करना अक्सर सबसे अच्छा होता है Gparted लाइव सीडी या विभाजित जादू, क्योंकि इन्हें डिस्ट्रो संस्करण की तुलना में हाल ही में और अधिक बग-मुक्त Gparted और कर्नेल है - मैंने एक बार पूरे एफएस को खो दिया है क्योंकि डिस्ट्रो के Gparted को चल रहे कर्नेल में विभाजन को ठीक से अद्यतन नहीं किया गया है। यदि डिस्ट्रो के Gparted का उपयोग करते हैं, तो विभाजन को बदलने के बाद सही रीबूट करना सुनिश्चित करें ताकि कर्नेल का दृश्य सही हो।

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

स्नैपशॉट्स भी बहुत धीमे हो सकते हैं (जिसका अर्थ है कि LVM के बिना 3 से 6 गुना धीमा इन MySQL परीक्षणों) - देख यह जवाब विभिन्न स्नैपशॉट समस्याओं को कवर करता है। धीमापन आंशिक रूप से है क्योंकि स्नैपशॉट्स को कई सिंक्रोनस लिखने की आवश्यकता होती है

स्नैपशॉट्स में कुछ महत्वपूर्ण बग हैं, उदा। कुछ मामलों में वे बूट को बहुत धीमा कर सकते हैं, या बूट को पूरी तरह असफल कर सकते हैं (क्योंकि कर्नेल समय निकाल सकता है  रूट एफएस की प्रतीक्षा कर रहा है जब यह एक एलवीएम स्नैपशॉट है [डेबियन में तय किया गया है initramfs-tools अद्यतन, मार्च 2015])।

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

स्नैपशॉट विकल्प - फाइल सिस्टम और वीएम हाइपरवाइजर

वीएम / क्लाउड स्नैपशॉट्स:

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

फाइल सिस्टम स्नैपशॉट्स:

  • जेडएफएस या बीआरटीएफ के साथ फाइल सिस्टम स्तर स्नैपशॉट्स का उपयोग करना आसान है और आमतौर पर एलवीएम से बेहतर है, और यद्यपि न तो फाइल सिस्टम लिनक्स पर बहुत परिपक्व है, लेकिन वे उन लोगों के लिए बेहतर विकल्प हो सकते हैं जिन्हें वीएम / क्लाउड रूट के बिना स्नैपशॉट की ज़रूरत होती है:

    • जेएफएस: अब एक है कर्नेल जेएफएस कार्यान्वयन, जो कुछ सालों से उपयोग में है और एफयूएसई पर जेएफएस की तुलना में बहुत तेज़ होना चाहिए।
    • बीआरटीएफ उत्पादन के उपयोग के लिए काफी तैयार नहीं है, और इसकी fsck और मरम्मत उपकरण अभी भी विकास में हैं।

ऑनलाइन बैकअप और fsck के लिए स्नैपशॉट्स

एक स्थिर प्रदान करने के लिए स्नैपशॉट का उपयोग किया जा सकता है स्रोत बैकअप के लिए, जब तक आप आवंटित स्थान से सावधान रहें (आदर्श रूप से स्नैपशॉट एलवी के बैक अप के समान आकार है)। उत्कृष्ट rsnapshot (1.3.1 के बाद से) आपके लिए LVM स्नैपशॉट निर्माण / हटाना भी प्रबंधित करता है - इसे देखें LVM का उपयोग कर rsnapshot पर हाउटो। हालांकि, स्नैपशॉट के साथ सामान्य मुद्दों पर ध्यान दें और स्नैपशॉट को स्वयं में बैकअप नहीं माना जाना चाहिए।

आप ऑनलाइन एफएसके करने के लिए एलवीएम स्नैपशॉट्स का भी उपयोग कर सकते हैं: एलवी स्नैपशॉट करें और स्नैपशॉट को एफएसके करें, जबकि अभी भी मुख्य गैर स्नैपशॉट एफएस का उपयोग कर रहे हैं - यहां वर्णित है - हालांकि, यह है पूरी तरह से सीधा नहीं है तो इसका उपयोग करना सबसे अच्छा है e2croncheck जैसा टेड Ts'o द्वारा वर्णित, ext3 के रखरखाव।

तुम्हे करना चाहिए फाइल सिस्टम को "फ्रीज" करें स्नैपशॉट लेने के दौरान अस्थायी रूप से - कुछ फाइल सिस्टम जैसे ext3 और XFS करेंगे इसे स्वचालित रूप से करें जब LVM स्नैपशॉट बनाता है।

निष्कर्ष

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

एलएमवी को वीएम हाइपरवाइजर, हार्ड ड्राइव / एसएसडी लेखन कैशिंग, और इसी तरह के कारण लेखन कैशिंग सेटअप पर बहुत सावधानी बरतनी चाहिए - लेकिन यह डीबी सर्वर के रूप में लिनक्स का उपयोग करने पर भी लागू होता है। अधिकांश उपकरणों से समर्थन की कमी (gparted महत्वपूर्ण आकार गणना सहित, और testdisk इत्यादि) इसे इस्तेमाल करने से कठिन बनाना आसान बनाता है।

यदि LVM का उपयोग करते हैं, तो स्नैपशॉट्स के साथ बहुत सावधानी बरतें: यदि संभव हो तो वीएम / क्लाउड स्नैपशॉट का उपयोग करें, या पूरी तरह से LVM से बचने के लिए ZFS / btrfs की जांच करें - आपको ZFS या btrs स्नैपशॉट्स के साथ LVM की तुलना में पर्याप्त परिपक्व हो सकते हैं।

निचली पंक्ति: यदि आप ऊपर सूचीबद्ध मुद्दों और उन्हें कैसे संबोधित करने के बारे में नहीं जानते हैं, तो सबसे अच्छा है कि LVM का उपयोग न करें।


238
2018-06-12 08:19



Xfs के साथ ऑनलाइन आकार बदलना पूरी तरह से काम करता है, आपको आकार निर्दिष्ट करने की भी आवश्यकता नहीं है। यह एलएफ के आकार में बढ़ेगा xfs_grow (5) में और पढ़ें। ओटीओएच मैंने लिखने की बाधाओं पर सारांश के लिए +1 मारा। - cstamas
यार! मेरे पूरे जीवन में आप कहां रहे!? - songei2f
@ ट्री: बैटरी बैक वाले RAID नियंत्रक के साथ विचार यह है कि इसका कैश बिजली विफलताओं में लगातार रहता है और आम तौर पर दस्तावेज के रूप में काम करने के लिए भरोसा किया जा सकता है, जबकि कुछ हार्ड डिस्क कैश इस बात के बारे में झूठ बोलते हैं कि उन्होंने वास्तव में डिस्क पर ब्लॉक लिखा है या नहीं बेशक ये कैश लगातार नहीं हैं। यदि आप हार्ड डिस्क कैश सक्षम करते हैं तो आप अचानक बिजली विफलता (जैसे पीएसयू या यूपीएस विफल) के लिए कमजोर हैं, जो RAID नियंत्रक के बैटरी बैकअप के विरुद्ध सुरक्षित है। - RichVel
मैंने कभी देखा है कि सबसे अच्छे उत्तरों में से एक, कोई विषय। केवल परिवर्तन ही मैं करूँगा, ध्यान घाटे विकार वाले लोगों के लिए प्रश्न के शीर्ष पर सारांश को स्थानांतरित करें या बहुत समय नहीं। :-) - Prof. Falken
उत्तर में सभी टिप्पणियां और अंतिम अपडेट देखकर एक साल पहले, मैं सोच रहा था कि जवाब विश्वसनीयता, प्रदर्शन और उपयोग में आसानी में किसी भी नए बदलाव को दर्शाने के लिए अद्यतन किया जा सकता है। - Luis Alvarado


मैं [+1] वह पोस्ट, और कम से कम मेरे लिए मुझे लगता है कि ज्यादातर समस्याएं मौजूद हैं। कुछ 100 सर्वर और कुछ 100TB डेटा चलाते समय उन्हें देखा। मेरे लिए लिनक्स में LVM2 किसी के पास "चालाक विचार" जैसा लगता है। इनमें से कुछ की तरह, वे कई बार "चतुर नहीं" बन जाते हैं। अर्थात। सख्ती से अलग कर्नेल और यूजर स्पेस (lvmtab) राज्यों को दूर करने के लिए वास्तव में स्मार्ट महसूस नहीं हो सकता है, क्योंकि भ्रष्टाचार के मुद्दे हो सकते हैं (यदि आपको सही कोड नहीं मिलता है)

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

पुन: स्थिरता pvmove... यही वजह है कि

पीवीएमओवी डेटा हानि

मेरे ब्लॉग पर इस तरह के एक शीर्ष रैंकिंग लेख, हमम? अभी मैं एक डिस्क को देखता हूं जहां मध्य-पीवीएमओवी से राज्य पर phyiscal lvm डेटा अभी भी लटका हुआ है। मुझे लगता है कि कुछ memleaks रहे हैं, और सामान्य विचार उपयोगकर्ताओं की जगह से लाइव ब्लॉक डेटा के आसपास कॉपी करने के लिए एक अच्छी बात है बस दुखद है। एलवीएम सूची से अच्छा उद्धरण "vgreduce की तरह लगता है - चुंबन pvmove संभाल नहीं करता है" वास्तव में मतलब है कि यदि डिस्क pvmove के दौरान अलग हो जाती है तो lvm प्रबंधन उपकरण lvm से vi में बदल जाता है। ओह और वहां एक बग भी है जहां ब्लॉक पढ़ने / लिखने की त्रुटि के बाद pvmove जारी रहता है और वास्तव में लक्ष्य डिवाइस पर डेटा नहीं लिखता है। WTF?

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

लाभ प्रदर्शन में है, 3 के बजाय 1 लिखना। तेज़ लेकिन असुरक्षित एल्गोरिदम चुनना ऐसा कुछ है जो स्पष्ट रूप से "यूनिक्स" पर वीएमवेयर और एमएस जैसे लोगों से अपेक्षा करता है, मुझे लगता है कि चीज़ें "सही हो जाएंगी"। जब तक मेरे पास स्नैपशॉट बैकिंग स्टोर नहीं है तब तक मुझे बहुत अधिक प्रदर्शन समस्याएं नहीं दिखाई दे रही थीं विभिन्न प्राथमिक डेटा की तुलना में डिस्क ड्राइव (और बेशक अभी तक एक और बैकअप)

पुन: बाधाएं मुझे यकीन नहीं है कि कोई एलएमवी पर दोष दे सकता है। जहां तक ​​मुझे पता है, यह एक devmapper मुद्दा था। लेकिन कम से कम कर्नेल 2.6 से 2.6.33 तक इस मुद्दे की वास्तव में देखभाल करने के लिए कुछ दोष नहीं हो सकता है AFAIK Xen एकमात्र हाइपरवाइजर है जो वर्चुअल मशीनों के लिए O_DIRECT का उपयोग करता है, समस्या तब होती थी जब "लूप" का उपयोग किया जाता था क्योंकि कर्नेल अभी भी इसका उपयोग कर कैश करेगा। वर्चुअलबॉक्स में कम से कम इस तरह की सामग्री को अक्षम करने के लिए कुछ सेटिंग है और क्यूमु / केवीएम आम तौर पर कैशिंग की अनुमति देता है। सभी FUSE एफएस में भी समस्याएं हैं (कोई O_DIRECT नहीं)

पुन: आकार मुझे लगता है कि एलवीएम प्रदर्शित आकार के "गोल" करता है। या यह जीआईबी का उपयोग करता है। वैसे भी, आपको वीजी पी आकार का उपयोग करने और एलवी के LE संख्या से गुणा करने की आवश्यकता है। यह सही शुद्ध आकार देना चाहिए, और यह मुद्दा हमेशा एक उपयोग मुद्दा है। यह फाइल सिस्टम द्वारा खराब हो गया है जो fsck / mount (हैलो, ext3) के दौरान ऐसी कोई चीज़ नहीं देखता है या ऑनलाइन काम नहीं करता है "fsck -n" (हैलो, ext3)

बेशक यह कह रहा है कि आपको ऐसी जानकारी के लिए अच्छे स्रोत नहीं मिल रहे हैं। "वीआरए के लिए कितने LE?" "पीवीआरए, वीजीडीए, ... आदि के लिए फाईस्कल ऑफसेट क्या है"

मूल एक LVM2 की तुलना में "उन लोगों का मुख्य उदाहरण है जो यूनिक्स को नहीं समझते हैं, इसे खराब करने के लिए निंदा की जाती है।"

कुछ महीने बाद अपडेट करें: मैं अब तक एक परीक्षण के लिए "पूर्ण स्नैपशॉट" परिदृश्य को मार रहा हूं। अगर वे पूर्ण हो जाते हैं, स्नैपशॉट ब्लॉक, मूल एलवी नहीं। जब मैंने पहली बार इसे पोस्ट किया था तो मैं गलत था। मैंने कुछ डॉक्टर से गलत जानकारी उठाई, या शायद मैं इसे समझ गया था। मेरे सेटअप में मैं हमेशा भरने के लिए बहुत पागल हो गया था और इसलिए मैंने कभी भी सही नहीं किया। स्नैपशॉट्स को विस्तार / संक्षिप्त करना भी संभव है, जो एक इलाज है।

मैं अभी भी हल करने में असमर्थ हूं कि स्नैपशॉट की उम्र को कैसे पहचानें। उनके प्रदर्शन के अनुसार, "पतली" फेडोरा प्रोजेक्ट पेज पर एक नोट है जो कहता है कि स्नैपशॉट तकनीक को संशोधित किया जा रहा है ताकि वे प्रत्येक स्नैपशॉट के साथ धीमे न हों। मुझे नहीं पता कि वे इसे कैसे कार्यान्वित कर रहे हैं।


15
2017-12-11 14:03



अच्छे अंक, विशेष रूप से पीवीएमओवी डेटा हानि (यह नहीं पता था कि यह कम स्मृति के तहत क्रैश हो सकता है) और स्नैपशॉट डिज़ाइन। लिखने की बाधाओं / कैशिंग पर: मैं उपयोगकर्ता के दृष्टिकोण से एलवीएम और कर्नेल डिवाइस मैपर को भंग कर रहा था, जो एलवीएम प्रदान करता है, उसे वितरित करने के लिए वे मिलकर काम करते हैं। Upvoted। पीवीएमओवी डेटा हानि पर आपके ब्लॉग पोस्टिंग को भी पसंद आया: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
स्नैपशॉट्स पर: वे LVM में कुख्यात रूप से धीमे हैं, इसलिए स्पष्ट रूप से यह विश्वसनीयता पर प्रदर्शन के लिए जाने का एक अच्छा डिज़ाइन निर्णय नहीं था। "दीवार पर हिट" करके, क्या आपका मतलब स्नैपशॉट भरना था, और क्या यह वास्तव में मूल एलवी डेटा के भ्रष्टाचार का कारण बन सकता है? एलवीएम हाउटो का कहना है कि इस मामले में स्नैपशॉट गिरा दिया गया है: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"CoW स्नैपशॉट एलवी क्षेत्र में नया डेटा अपडेट करके और फिर स्नैप को हटाने के बाद वापस विलय करके, असुरक्षित रूप से किया जाता है।" यह सिर्फ झूठा है। जब मूल डिवाइस पर नया डेटा लिखा जाता है, तो पुराना संस्करण स्नैपशॉट्स गाय क्षेत्र में लिखा गया है। कोई डेटा कभी वापस विलय नहीं किया जाता है (सिवाय इसके कि यदि आप चाहते हैं)। देख kernel.org/doc/Documentation/device-mapper/snapshot.txt सभी गोर तकनीकी विवरण के लिए। - Damien Tournoud
हाय डेमियन, अगली बार बस उस बिंदु पर पढ़ा जहां मैंने अपनी पोस्ट को सही किया? - Florian Heigl


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

बीटीडब्ल्यू अगर आप 1TB ड्राइव का उपयोग करने जा रहे हैं, विभाजन संरेखण के बारे में याद रखें - इस ड्राइव में शायद 4kB भौतिक क्षेत्र हैं।


12
2018-06-12 09:44



खुले स्नैपशॉट्स के लिए प्रदर्शन चेतावनी के लिए +1। - Prof. Falken
मेरा अनुभव यह है कि 1 टीबी ड्राइव आमतौर पर 512 बाइट सेक्टर का उपयोग करती हैं, लेकिन अधिकांश 2 टीबी ड्राइव 4 केबी का उपयोग करती हैं। - Dan Pritts
@DanPritts को यह मानने में कोई हानि नहीं है कि क्षेत्र का आकार 4 केबी या यहां तक ​​कि 128 केबी है - बस मामले में छापे होने पर। आप बहुत कम खो देते हैं - शायद वह 128 केबी और आप बहुत कुछ हासिल कर सकते हैं। जब भी पुरानी डिस्क से इमेजिंग एक नई हो। - pQd
फाइल सिस्टम ब्लॉक आकार "बहुत बड़ा" बनाने के लिए कुछ मामूली नुकसान है; प्रत्येक फ़ाइल एक ब्लॉक से कम में निहित है। यदि आपके पास बहुत सी छोटी फ़ाइलें और 128 केबी ब्लॉक हैं तो यह जोड़ देगा। मैं मानता हूं कि 4K काफी उचित है, और यदि आप फाइल सिस्टम को नए हार्डवेयर में ले जाते हैं, तो आप अंततः 4k सेक्टरों के साथ समाप्त हो जाएंगे। - Dan Pritts
(मुझे मेरी पिछली टिप्पणी संपादित नहीं करने देगी) ... अंतरिक्ष की बर्बादी कोई फर्क नहीं पड़ता, लेकिन यह कताई डिस्क पर आपके औसत खोज समय को बढ़ाने के अंत में खत्म हो जाएगा। यह शायद एसएसडी पर लिखने के प्रवर्धन (नल के साथ क्षेत्र भरना) में बदल सकता है। - Dan Pritts


एडम,

एक अन्य लाभ: आप एक नया भौतिक वॉल्यूम (पीवी) जोड़ सकते हैं, सभी डेटा को उस पीवी में ले जा सकते हैं और फिर बिना किसी सेवा बाधा के पुराने पीवी को हटा सकते हैं। मैंने पिछले पांच वर्षों में कम से कम चार बार उस क्षमता का उपयोग किया है।

एक नुकसान मैंने स्पष्ट रूप से अभी तक नहीं देखा है: LVM2 के लिए कुछ हद तक सीखने की वक्र है। ज्यादातर अमूर्तता में यह आपकी फाइलों और अंतर्निहित मीडिया के बीच बनाता है। यदि आप सर्वर के एक सेट पर काम साझा करने वाले कुछ लोगों के साथ काम करते हैं, तो आप पूरी तरह से अपनी टीम के लिए अतिरिक्त जटिलता पा सकते हैं। आईटी काम को समर्पित बड़ी टीमों में आम तौर पर ऐसी कोई समस्या नहीं होगी।

उदाहरण के लिए, हम इसे अपने काम पर व्यापक रूप से यहां उपयोग करते हैं और पूरी टीम को बुनियादी बातों को ठीक करने के बारे में पूरी टीम को मूल बातें, भाषा और बेयर जरूरी सिखाने के लिए समय निकाला है।

एक चेतावनी विशेष रूप से इंगित करने के लिए: यदि आप LVM2 लॉजिकल वॉल्यूम से बूट करते हैं तो सर्वर को क्रैश होने पर आपको पुनर्प्राप्ति संचालन मुश्किल लगता है। Knoppix और दोस्तों के लिए हमेशा सही सामान नहीं है। इसलिए, हमने फैसला किया कि हमारी / बूट निर्देशिका इसके स्वयं के विभाजन पर होगी और हमेशा छोटी और मूल होगी।

कुल मिलाकर, मैं LVM2 का प्रशंसक हूं।


5
2018-06-22 21:03



रखना /boot अलग हमेशा एक अच्छा विचार है - Hubert Kario
GRUB2 LVM लॉजिकल वॉल्यूम से बूटिंग का समर्थन करता है (देखें wiki.archlinux.org/index.php/GRUB2#LVM) लेकिन GRUB1 नहीं करता है। यह सुनिश्चित करने के लिए कि यह पुनर्प्राप्त करना आसान है, मैं हमेशा एक अलग गैर-एलवीएम / बूट का उपयोग करता हूं। इन दिनों अधिकांश बचाव डिस्क LVM का समर्थन करते हैं - कुछ को मैन्युअल की आवश्यकता होती है vgchange -ayLVM वॉल्यूम खोजने के लिए। - RichVel
pvmove पर: फ्लोरियन हेग्ल के जवाब में किए गए पीवीएमओवी डेटा हानि के बारे में बिंदु देखें। - RichVel