🥇गिटलैब आपको बड़े नेक्स्टक्लाउड स्टोरेज का बैकअप बनाने में कैसे मदद करता है

हे हबर!

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

इंस्टॉलेशन की सुविधाओं से उत्पन्न होने वाली समस्या यह है कि इसमें बहुत अधिक डेटा है। नेक्स्टक्लाउड द्वारा प्रदान किया गया संस्करण, अतिरेक, व्यक्तिपरक कारण और बहुत कुछ कई डुप्लिकेट बनाता है।

पृष्ठभूमि

नेक्स्टक्लाउड का प्रबंधन करते समय, एक प्रभावी बैकअप व्यवस्थित करने की समस्या उत्पन्न होती है, जिसे एन्क्रिप्ट किया जाना चाहिए, क्योंकि डेटा मूल्यवान है।

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

कई ग्राहक हैं, उनमें से सभी अलग-अलग कॉन्फ़िगरेशन के साथ हैं, और सभी अपनी-अपनी साइटों पर और अपनी विशेषताओं के साथ हैं। यह एक मानक तकनीक है जब पूरी साइट आपकी होती है, और बैकअप क्राउन से बनाए जाते हैं; यह अच्छी तरह से फिट नहीं बैठता है।

सबसे पहले, आइए इनपुट डेटा देखें। ज़रुरत है:

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

बैकअप प्रबंधित करने की समस्या को हल करने के लिए, हमने GitLab स्थापित किया। टैकल द्वारा अधिक विवरण।

बेशक, हम ऐसी समस्या को हल करने वाले पहले व्यक्ति नहीं हैं, लेकिन हमें ऐसा लगता है कि हमारा व्यावहारिक, कड़ी मेहनत से अर्जित अनुभव दिलचस्प हो सकता है और हम इसे साझा करने के लिए तैयार हैं।

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

बैकअप उपकरण

हमने बैकअप निर्माण उपकरण चुनकर समाधान विधियों की खोज शुरू की।

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

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

बैकअप प्रबंधित करना

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

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

हमें क्या मिला? निष्पादन से प्रतिक्रिया, परिवर्तनों पर सुविधाजनक नियंत्रण, त्रुटि के मामले में विवरण।

यहां यहाँ GitHub पर हमने विभिन्न कार्यों के लिए स्क्रिप्ट के उदाहरण पोस्ट किए, और हमने इसे न केवल नेक्स्टक्लाउड, बल्कि कई अन्य सेवाओं के बैकअप के साथ जोड़ दिया। यदि आप इसे मैन्युअल रूप से कॉन्फ़िगर नहीं करना चाहते हैं (और हम नहीं चाहते हैं) और .gitlab-ci.yml तो वहां एक शेड्यूलर भी है

Gitlab API में CI/CD टाइमआउट को बदलने का अभी तक कोई तरीका नहीं है, लेकिन यह छोटा है। इसे बढ़ाने की जरूरत है, कहते हैं 1d.

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

अब रैपर स्क्रिप्ट के बारे में।

हमने इस स्क्रिप्ट के लिए निम्नलिखित शर्तें निर्धारित की हैं:

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

पूरा लॉग GitLab में एक आर्टिफैक्ट के रूप में सहेजा गया है; यदि कोई त्रुटि नहीं है, तो लॉग हटा दिया गया है। हम स्क्रिप्ट को बैश में लिखते हैं।

हमें ओपन सोर्स के संबंध में किसी भी सुझाव और टिप्पणी पर विचार करने में खुशी होगी - स्वागत है।

Как это работает

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

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

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

अपनी स्थानीय मशीन को हैकर से बचाने के लिए, क्योंकि वह S3 पर डेटा मिटा सकता है, आपको संस्करण सक्षम करना होगा।
बैकअप हमेशा बैकअप को एन्क्रिप्ट करता है।

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

एक अलग अनुसूचक अनुक्रमणिका और सामग्री की अखंडता के लिए बैकअप की जाँच करता है। चेक धीमा और लंबा है, इसलिए हम इसे महीने में एक बार अलग से चलाते हैं। इसमें कई दिन लग सकते हैं.

मुझे रूसी में पढ़ें

मुख्य कार्य

prepare प्रशिक्षण
testcheck तत्परता की जाँच
maincommand मूल समूह
forcepostscript एक फ़ंक्शन जो अंत में या त्रुटि से निष्पादित होता है। हम इसका उपयोग विभाजन को अनमाउंट करने के लिए करते हैं।

सेवा कार्य

cleanup हम त्रुटियाँ रिकॉर्ड करते हैं या लॉग फ़ाइल मिटा देते हैं।
checklog किसी त्रुटि वाली पंक्ति की घटना के लिए लॉग को पार्स करें।
ret निकास हैंडलर.
checktimeout टाइमआउट की जाँच करें.

वातावरण

VERBOSE=1 हम त्रुटियों को तुरंत स्क्रीन पर प्रदर्शित करते हैं (स्टडआउट)।
SAVELOGSONSUCCES=1 सफलता पर लॉग सहेजें.
INIT_REPO_IF_NOT_EXIST=1 यदि यह मौजूद नहीं है तो एक रिपॉजिटरी बनाएं। डिफ़ॉल्ट रूप से अक्षम.
TIMEOUT मुख्य ऑपरेशन के लिए अधिकतम समय. आप इसे अंत में 'एम', 'एच' या 'डी' के रूप में सेट कर सकते हैं।

पुरानी प्रतियों के लिए भंडारण मोड। गलती करना:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

स्क्रिप्ट के अंदर वेरिएबल

ERROR_STRING - त्रुटि के लिए चेक इन लॉग के लिए स्ट्रिंग।
EXTRACT_ERROR_STRING - त्रुटि होने पर शो स्ट्रिंग के लिए अभिव्यक्ति।
KILL_TIMEOUT_SIGNAL - समय समाप्त होने पर मारने का संकेत।
TAIL - स्क्रीन पर त्रुटियों के साथ कितने तार।
COLORMSG — संदेश का रंग (डिफ़ॉल्ट पीला).

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

रेस्टिक बनाम बोर्ग

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

हमारे चयन मानदंड, पहले से बताए गए मानदंडों के अलावा (डीडुप्लीकेशन, तेज़ पुनर्प्राप्ति, आदि):

अधूरे कार्य का विरोध. किल-9 की जाँच करें।
डिस्क पर आकार।
संसाधनों की आवश्यकता (सीपीयू, मेमोरी)।
संग्रहित बूँदों का आकार.
S3 के साथ कार्य करना.
अखंडता की जांच।

परीक्षण के लिए, हमने वास्तविक डेटा और 1,6 टीबी के कुल आकार वाला एक क्लाइंट लिया।
स्थितियां।

बोर्ग को नहीं पता कि S3 के साथ सीधे कैसे काम करना है, और हमने डिस्क को फ़्यूज़ के रूप में माउंट किया नासमझ. रेस्टिक ने इसे S3 पर ही भेजा।

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

नेटवर्क के प्रभाव को कम करने के लिए, हमने एक स्थानीय प्रदाता - यांडेक्स क्लाउड का उपयोग किया।

तुलना परीक्षण परिणाम.

पुनः आरंभ के साथ किल -9 दोनों सफल रहे।
डिस्क पर आकार। बोर्ग संपीड़ित हो सकता है, इसलिए परिणाम अपेक्षा के अनुरूप हैं।

बैकअपर
आकार

बोर्ग
562Gb

आराम करना
628Gb

सीपीयू द्वारा
डिफ़ॉल्ट संपीड़न के साथ, बोर्ग स्वयं बहुत कम खपत करता है, लेकिन इसका मूल्यांकन नासमझ प्रक्रिया के साथ किया जाना चाहिए। कुल मिलाकर, वे तुलनीय हैं और एक ही परीक्षण वर्चुअल मशीन पर लगभग 1,2 कोर का उपयोग करते हैं।
याद। रेस्टिक लगभग 0,5GB है, बोर्ग लगभग 200MB है। लेकिन सिस्टम फ़ाइल कैश की तुलना में यह सब महत्वहीन है। इसलिए अधिक मेमोरी आवंटित करने की सलाह दी जाती है।
बूँद के आकार में अंतर आश्चर्यजनक था।

बैकअपर
आकार

बोर्ग
लगभग 500एमबी

आराम करना
लगभग 5एमबी

रेस्टिक के S3 के साथ अनुभव उत्कृष्ट है। नासमझों के माध्यम से बोर्ग के साथ काम करने से कोई सवाल नहीं उठता है, लेकिन यह नोट किया गया है कि कैश को पूरी तरह से रीसेट करने के लिए बैकअप पूरा होने के बाद umount करने की सलाह दी जाती है। S3 की ख़ासियत यह है कि कम पंप किए गए टुकड़ों को कभी भी बाल्टी में नहीं भेजा जाएगा, जिसका अर्थ है कि अधूरा भरा गया डेटा बड़ी क्षति का कारण बनता है।
अखंडता जांच दोनों मामलों में अच्छी तरह से काम करती है, लेकिन गति में काफी अंतर होता है।
रेस्टिक 3,5 घंटे.
बोर्ग, 100GB SSD फ़ाइल कैश के साथ - 5 घंटे.यदि डेटा स्थानीय डिस्क पर है तो लगभग समान गति परिणाम।
बोर्ग बिना कैश के सीधे S3 से पढ़ता है 33 घंटे. राक्षसी रूप से लंबा.

लब्बोलुआब यह है कि बोर्ग संपीड़ित हो सकता है और इसमें बड़ी बूँदें होती हैं - जो S3 में भंडारण और GET/PUT संचालन को सस्ता बनाती हैं। लेकिन यह अधिक जटिल और धीमे सत्यापन की कीमत पर आता है। जहां तक रिकवरी स्पीड की बात है तो हमें कोई अंतर नजर नहीं आया। रेस्टिक बाद के बैकअप (पहले के बाद) थोड़ा अधिक समय लेता है, लेकिन महत्वपूर्ण रूप से नहीं।

चुनाव में अंतिम लेकिन महत्वपूर्ण बात समुदाय का आकार था।

और हमने बोर्ग को चुना।

संपीड़न के बारे में कुछ शब्द

बोर्ग के शस्त्रागार में एक उत्कृष्ट नया संपीड़न एल्गोरिथ्म है - zstd। संपीड़न गुणवत्ता gzip से बदतर नहीं है, लेकिन बहुत तेज़ है। और गति में डिफ़ॉल्ट lz4 से तुलनीय है।

उदाहरण के लिए, एक MySQL डेटाबेस डंप को समान गति पर lz4 से दो गुना बेहतर तरीके से संपीड़ित किया जाता है। हालाँकि, वास्तविक डेटा के अनुभव से पता चलता है कि नेक्स्टक्लाउड नोड के संपीड़न अनुपात में बहुत कम अंतर है।

बोर्ग में एक बोनस संपीड़न मोड है - यदि फ़ाइल में उच्च एन्ट्रॉपी है, तो संपीड़न बिल्कुल भी लागू नहीं होता है, जिससे गति बढ़ जाती है। बनाते समय विकल्प द्वारा सक्षम किया गया
-C auto,zstd
Zstd एल्गोरिथ्म के लिए
तो इस विकल्प के साथ, डिफ़ॉल्ट संपीड़न की तुलना में, हमें मिला
क्रमशः 560 जीबी और 562 जीबी। उपरोक्त उदाहरण से डेटा, मैं आपको याद दिला दूं, संपीड़न के बिना परिणाम 628 जीबी है। 2GB के अंतर के नतीजे ने हमें कुछ हद तक आश्चर्यचकित कर दिया, लेकिन हमने सोचा कि आख़िरकार हम इसे ही चुनेंगे। auto,zstd.

बैकअप सत्यापन विधि

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

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

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

निष्कर्ष

परिणामस्वरूप, हम निश्चित रूप से जानते हैं कि हम बैकअप बनाते हैं, कि हमारे बैकअप वैध हैं, उनके साथ उत्पन्न होने वाली समस्याओं में बहुत कम समय लगता है और ड्यूटी प्रशासक के स्तर पर हल किया जाता है। tar.gz या Bacula की तुलना में बैकअप वास्तव में बहुत कम जगह लेता है।

स्रोत: www.habr.com

GitLab आपको बड़े नेक्स्टक्लाउड स्टोरेज का बैकअप लेने में कैसे मदद करता है