👵🏻 🐼 🤵 लिनक्स के लिए बैकअप, या स्नैपशॉट कैसे बनाएं 🤸🏼 🧛🏼 ‼️

सभी को नमस्कार! मैं लिनक्स प्रोजेक्ट के लिए वीम एजेंट पर वीम पर काम करता हूं। इस उत्पाद के साथ, आप एक लिनक्स मशीन का बैकअप ले सकते हैं। नाम में "एजेंट" का मतलब है कि कार्यक्रम आपको भौतिक मशीनों का बैकअप लेने की अनुमति देता है। Virtualalkans भी बैकअप, लेकिन यह अतिथि OS पर स्थित है।

इस लेख की प्रेरणा लिनक्स पाइटर सम्मेलन में मेरी रिपोर्ट थी, जिसे मैंने सभी इच्छुक हबरगेटेली के लेख के रूप में जारी करने का निर्णय लिया था।

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

सभी इच्छुक कृपया एक कट के लिए पूछें!

शुरुआत में थोड़ा सिद्धांत

ऐतिहासिक रूप से, बैकअप बनाने के लिए दो दृष्टिकोण हैं: फ़ाइल बैकअप और वॉल्यूम बैकअप। पहले मामले में, हम प्रत्येक फ़ाइल को एक अलग ऑब्जेक्ट के रूप में कॉपी करते हैं, दूसरे में, हम वॉल्यूम की संपूर्ण सामग्री को एक तरह की छवि के रूप में कॉपी करते हैं।

दोनों तरीकों के बहुत सारे फायदे और नुकसान हैं, लेकिन हम उन्हें विफलता से उबरने के चश्मे के माध्यम से विचार करेंगे:

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

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

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

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

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

BTRFS और ZFS फाइल सिस्टम सबस्ट्रक्चर के स्नैपशॉट बनाना संभव बनाते हैं, जो बहुत अच्छा है, लेकिन फिलहाल सर्वर पर उनका हिस्सा छोटा है, और हम एक सार्वभौमिक समाधान बनाने की कोशिश कर रहे हैं।

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

यह कैसे काम करता है - सिद्धांत रूप में

माइक्रोस्कोप स्नैपशॉट

इसलिए, अब हम मॉड्यूल के संचालन के सामान्य सिद्धांत पर विचार करेंगे और प्रमुख मुद्दों पर अधिक विस्तार से विचार करेंगे।

वास्तव में, veeamsnap (जैसा कि हमने अपने कर्नेल मॉड्यूल कहा था) एक ब्लॉक डिवाइस ड्राइवर फ़िल्टर है।

उनका काम एक ब्लॉक डिवाइस ड्राइवर के लिए अनुरोधों को रोकना है।

एक लिखित अनुरोध को रोकने के बाद, मॉड्यूल मूल ब्लॉक डिवाइस से स्नैपशॉट डेटा क्षेत्र में डेटा की प्रतिलिपि बनाता है। इस क्षेत्र को हम स्नैपशॉट कहते हैं।

और स्नैपशॉट क्या है? यह एक वर्चुअल ब्लॉक डिवाइस है, जो किसी विशेष बिंदु पर मूल डिवाइस की एक प्रति है। जब इस डिवाइस पर डेटा ब्लॉक एक्सेस करते हैं, तो उन्हें स्नैप-इन या मूल डिवाइस से पढ़ा जा सकता है।

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

उदाहरण के लिए, हम फाइल सिस्टम से कब्जे वाले ब्लॉक का नक्शा प्राप्त कर सकते हैं। ऐसा करने का सबसे आसान तरीका ioctl GETFSMAP है ।
व्यस्त ब्लॉकों का डेटा आपको स्नैपशॉट से केवल नवीनतम डेटा पढ़ने की अनुमति देता है।

आप कुछ फ़ाइलों को बाहर भी कर सकते हैं। खैर, एक पूरी तरह से वैकल्पिक कार्रवाई: भविष्य में एक दानेदार रेस्तरां की संभावना के लिए, बैकअप में आने वाली फ़ाइलों को अनुक्रमित करें।

सीओडब्ल्यू बनाम RoW

चलो स्नैपशॉट एल्गोरिदम चुनने पर थोड़ा ध्यान दें। यहां चुनाव बहुत व्यापक नहीं है: कॉपी-ऑन-राइट या रीडायरेक्ट-ऑन-राइट लिखें ।

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

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

चूंकि डेटा सुरक्षा हमारी सर्वोच्च प्राथमिकता है, इसलिए हमने सीओडब्ल्यू पर ध्यान केंद्रित किया।

अब तक, सब कुछ सरल दिखता है, इसलिए चलिए वास्तविक जीवन की समस्याओं पर चलते हैं।

यह कैसे काम करता है - व्यवहार में

लगातार स्थिति

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

लेकिन हम 21 वीं सदी में रहते हैं! लॉगिंग तंत्र हैं जो ऐसी समस्याओं से बचाते हैं! सच है, सच है, एक महत्वपूर्ण "लेकिन" है: यह सुरक्षा विफलता से नहीं है, बल्कि इसके परिणामों से है। जब लॉग के अनुसार एक सुसंगत स्थिति में बहाल किया जाता है, तो अपूर्ण संचालन को छोड़ दिया जाएगा, जिसका अर्थ है कि वे खो जाएंगे। इसलिए, परिणामों का इलाज करने के बजाय, प्राथमिकता से सुरक्षा को प्राथमिकता देना महत्वपूर्ण है।

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

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

स्नैप को कहां रखें?

यह दूसरी समस्या है जो हमारे रास्ते में खड़ी है। पहली नज़र में, समस्या स्पष्ट नहीं है, लेकिन थोड़ी समझ के बाद, हम देखते हैं कि यह अभी भी एक किरच है।

बेशक, सबसे आसान समाधान स्नैप को रैम में रखना है। डेवलपर के लिए, विकल्प सिर्फ महान है! सब कुछ तेज़ है, डिबगिंग करने के लिए बहुत सुविधाजनक है, लेकिन एक जाम है: रैम एक मूल्यवान संसाधन है, और कोई भी हमें वहां एक बड़ा स्नैप नहीं देगा।

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

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

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

सिद्धांत रूप में, प्रतिबिंब के लिए दिशा एक है: आपको किसी तरह फाइल सिस्टम में जगह आवंटित करने की आवश्यकता है, लेकिन सीधे ब्लॉक डिवाइस के साथ काम करें। इस समस्या का समाधान सेवा में उपयोगकर्ता-अंतरिक्ष कोड में लागू किया गया था।

एक फैलोक सिस्टम कॉल है जो आपको वांछित आकार की एक खाली फ़ाइल बनाने की अनुमति देता है। हालाँकि, वास्तव में, फ़ाइल सिस्टम पर केवल मेटाडेटा बनाया जाता है जो वॉल्यूम पर फ़ाइल के स्थान का वर्णन करता है। और ioctl FIEMAP हमें फ़ाइल ब्लॉक के स्थान का नक्शा प्राप्त करने की अनुमति देता है।

और वॉइला: हम एक फाइल बनाते हैं जो फॉलोकैट का उपयोग करते हुए स्नैप के तहत आती है, FIEMAP हमें इस फाइल के ब्लॉक के स्थान का एक नक्शा देता है, जिसे हम अपने वीमेनस्पैप मॉड्यूल में काम करने के लिए स्थानांतरित कर सकते हैं। इसके अलावा, जब स्नैपस्टोर तक पहुंच होती है, तो मॉड्यूल सीधे हमारे द्वारा ज्ञात ब्लॉकों में ब्लॉक डिवाइस पर अनुरोध करता है, और कोई गतिरोध नहीं।

लेकिन एक अति सूक्ष्म अंतर है। फैलोकैट सिस्टम कॉल केवल XFS, EXT4 और BTRFS द्वारा समर्थित है। अन्य फ़ाइल सिस्टम जैसे EXT3 के लिए, आपको फ़ाइल को आवंटित करने के लिए इसे पूरी तरह से लिखना होगा। स्नैप्पड तैयार करने के लिए समय में वृद्धि से कार्यक्षमता प्रभावित होती है, लेकिन कोई विकल्प नहीं है। फिर, आपको उस पर काम करने में सक्षम होना चाहिए जो कि है।

यदि ioctl FIEMAP भी समर्थित नहीं है तो क्या होगा? यह NTFS और FAT32 की वास्तविकता है, जहां प्राचीन FIBMAP के लिए समर्थन भी नहीं है। मुझे एक निश्चित सामान्य एल्गोरिथ्म को लागू करना था, जिसका संचालन फ़ाइल सिस्टम की सुविधाओं पर निर्भर नहीं करता है। संक्षेप में, एल्गोरिथ्म है:

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

हां, मुश्किल, हां, धीरे, लेकिन कुछ नहीं से बेहतर। यह FIEMAP और FIBMAP समर्थन के बिना फ़ाइल सिस्टम के लिए दुर्लभ मामलों में उपयोग किया जाता है।

स्नैपशॉट अतिप्रवाह

बल्कि, जिस जगह को हमने स्नैपस्टोर के तहत आवंटित किया था, वह समाप्त हो गया। समस्या का सार यह है कि नए डेटा को छोड़ने के लिए कहीं नहीं है, जिसका अर्थ है कि स्नैपशॉट अनुपयोगी हो जाता है।
क्या करें?

जाहिर है, आपको तड़क-भड़क बढ़ाने की जरूरत है। कितना? स्नैपटेंट्स के आकार को निर्धारित करने का सबसे आसान तरीका वॉल्यूम पर मुक्त स्थान का प्रतिशत निर्धारित करना है (जैसा कि वीएसएस के लिए किया गया है)। 20 टीबी की मात्रा के लिए, 10% 2TB होगा - जो एक अनलोड किए गए सर्वर के लिए बहुत कुछ है। 200 जीबी की मात्रा के लिए, 10% 20GB है, जो एक सर्वर के लिए बहुत कम हो सकता है जो अपने डेटा को तीव्रता से अपडेट कर रहा है। और अभी भी पतले वॉल्यूम हैं ...

सामान्य तौर पर, केवल सर्वर का सिस्टम प्रशासक ही आवश्यक स्नैप-इन एडवांस के इष्टतम आकार का पता लगा सकता है, अर्थात, आपको व्यक्ति को अपने विशेषज्ञ की राय और विचार देना होगा। यह "यह सिर्फ काम करता है" के सिद्धांत का पालन नहीं करता है।

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

फिर, संक्षेप में एल्गोरिथ्म:

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

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

अन्य मामलों में क्या करना है? हम आवश्यक आकार का अनुमान लगाने की कोशिश कर रहे हैं और पूरी तरह से संपूर्ण स्नैपास्ट बनाते हैं। लेकिन हमारे आँकड़ों के अनुसार, लिनक्स सर्वर का विशाल बहुमत अब EXT4 और XFS का उपयोग करता है। EXT3 पुरानी मशीनों पर पाया जाता है। लेकिन SLES / OpenSUSE में आप BTRFS पर ठोकर खा सकते हैं।

ब्लॉक ट्रैकिंग (सीबीटी) बदलें

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

इस क्षेत्र में कई लोगों का अपना अनुभव है। उदाहरण के लिए, VMware vSphere में, यह सुविधा 2009 में संस्करण 4 के बाद से उपलब्ध है। हाइपर-वी में, समर्थन विंडोज सर्वर 2016 के साथ पेश किया गया था, और पहले रिलीज का समर्थन करने के लिए, अपने स्वयं के वीईएमईएफसीटी चालक को 2012 में वापस विकसित किया गया था। इसलिए, हमारे मॉड्यूल के लिए हम मूल नहीं बने और पहले से ही काम कर रहे एल्गोरिदम का उपयोग किया।
इसके बारे में कैसे काम करता है।

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

दो बारीकियां हैं।

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

प्रदर्शन का मुद्दा

बैकअप हमेशा आपके उपकरणों के IO पर इतना अच्छा भार है। यदि पहले से ही इस पर पर्याप्त सक्रिय कार्य हैं, तो बैकअप प्रक्रिया आपके सिस्टम को एक प्रकार की सुस्ती में बदल सकती है।
आइए देखें क्यों।

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

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

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

थ्रॉटलिंग

पहले से ही डिबगिंग चरण में, एक और अति सूक्ष्म अंतर सामने आया। बैकअप के दौरान, सिस्टम अनुत्तरदायी बन गया, अर्थात। सिस्टम I / O अनुरोध लंबी देरी के साथ चलने लगे। लेकिन, स्नैपशॉट से डेटा पढ़ने के अनुरोध को अधिकतम गति के करीब किया गया।
मुझे थ्रॉटलिंग तंत्र को लागू करके बैकअप प्रक्रिया को थोड़ा गला देना पड़ा। ऐसा करने के लिए, स्नैपशॉट छवि से पढ़ने की प्रक्रिया को प्रतीक्षा की स्थिति में डाल दिया जाता है यदि अवरोधन अनुरोधों की कतार खाली नहीं होती है। उम्मीद है, प्रणाली जीवन के लिए आया था।

नतीजतन, अगर I / O सिस्टम पर लोड तेजी से बढ़ता है, तो स्नैपशॉट से पढ़ने की प्रक्रिया इंतजार करेगी। यहां हमने सिद्धांत द्वारा निर्देशित होने का फैसला किया कि सर्वर को बाधित करने की तुलना में त्रुटि के साथ बैकअप को समाप्त करना बेहतर है।

गतिरोध

मुझे लगता है कि हमें और अधिक विस्तार से समझाने की आवश्यकता है कि यह क्या है।

पहले से ही परीक्षण के चरण में, हमने सात परेशानियों के निदान के साथ सिस्टम के पूर्ण हैंग की स्थितियों का सामना करना शुरू कर दिया - एक रीसेट।

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

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

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

राउंड रॉबिन डेटाबेस

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

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

ब्लॉक आकार चयन

अब, जब स्नैपशॉट को ब्लॉक में तोड़ दिया गया है, तो सवाल उठता है: क्या, वास्तव में, ब्लॉक का आकार स्नैपर को विभाजित करने के लिए है?

समस्या दुगुनी है। यदि ब्लॉक को बड़ा बना दिया जाता है, तो उन्हें संचालित करना आसान होता है, लेकिन यदि कम से कम एक सेक्टर बदलता है, तो आपको पूरे ब्लॉक को रिग में भेजना होगा और, परिणामस्वरूप रिग को भरने की संभावना बढ़ जाती है।

जाहिर है, ब्लॉक आकार जितना छोटा होगा, स्नैपशॉट में भेजे गए उपयोगी डेटा का प्रतिशत उतना ही अधिक होगा, लेकिन यह प्रदर्शन को कैसे प्रभावित करेगा?

उन्होंने अनुभवजन्य रूप से सत्य की खोज की और 16KiB के साथ आए। यह भी ध्यान दें कि विंडोज वीएसएस भी 16 KiB ब्लॉक का उपयोग करता है।

एक निष्कर्ष के बजाय

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

अब हम रिलीज़ संस्करण 3.0 की तैयारी कर रहे हैं, मॉड्यूल कोड जीथब पर है , और कोई भी इसे जीपीएल लाइसेंस के तहत उपयोग कर सकता है।

लिनक्स के लिए बैकअप, या स्नैपशॉट कैसे बनाएं