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

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


इसके बाद, आपको DevOpsConf Russia 2018 की सर्वश्रेष्ठ रिपोर्ट में से एक का वीडियो और टेक्स्ट संस्करण मिलेगा।



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

सेफ कई सॉफ्टवेयर घटकों के साथ एक सॉफ्टवेयर-परिभाषित भंडार है।


आरेख में:

• ऊपरी स्तर आंतरिक क्लस्टर नेटवर्क है जिसके माध्यम से क्लस्टर स्वयं संचार करता है;
• निचले स्तर - वास्तव में सेफ - आंतरिक सिफ के डेमन्स (मॉन, एमडीएस और ओएसडी) का एक सेट है जो डेटा को स्टोर करता है।

एक नियम के रूप में, सभी डेटा को दोहराया जाता है। आरेख में, मैंने जानबूझकर तीन समूहों का चयन किया है, जिनमें से प्रत्येक में तीन ओएसडी हैं, और इनमें से प्रत्येक समूह में आमतौर पर एक डेटा प्रतिकृति है। नतीजतन, डेटा तीन प्रतियों में संग्रहीत किया जाता है।

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

ग्राहकों

● S3 ग्राहक

S3 HTTP के लिए एक एपीआई है। S3 क्लाइंट HTTP पर काम करते हैं और सेफ रेडोस गेटवे (RGW) घटकों से जुड़ते हैं। वे लगभग हमेशा एक समर्पित नेटवर्क के माध्यम से एक घटक के साथ संवाद करते हैं। यह नेटवर्क (मैंने इसे S3 नेटवर्क कहा है) केवल HTTP का उपयोग करता है, अपवाद दुर्लभ हैं।

आभासी मशीनों के साथ ● पर्यवेक्षक

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

● आरबीडी क्लाइंट

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

● सीएफएफएस ग्राहक

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


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

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

हमें इन सभी घटकों को जोड़ना था, और हमें थोड़ा व्यापक क्लस्टर मिला।


हमारे पास दो केंद्रीय घटक हैं: SCSI गेटवे समूह , जो FibreChannel या iSCSI के माध्यम से एक सिफ क्लस्टर में डेटा तक पहुंच प्रदान करता है। इन घटकों का उपयोग हाइपरवी और ईएसएक्सआई को एक सिफ क्लस्टर से जोड़ने के लिए किया जाता है। PROXMOX ग्राहक अभी भी अपने तरीके से काम करते हैं - आरबीडी के माध्यम से।

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

इस सब का प्रबंधन करने के लिए, हमें वास्तव में अपने स्वयं के सेफ ऑर्केस्ट्रा और हमारे सभी घटकों को विकसित करना था, जो कि कई हैं। लेकिन इसके बारे में बात करने का अब कोई मतलब नहीं है, क्योंकि यह हमारा विकास है। सबसे शायद "नग्न" सिफ में ही दिलचस्पी होगी।

सेफ का उपयोग बहुत से स्थानों पर किया जाता है, और कभी-कभी असफलता भी मिलती है। निश्चित रूप से हर कोई जो सिफ के साथ काम करता है, वह CloudMouse के बारे में किंवदंती जानता है। यह एक भयानक शहरी किंवदंती है, लेकिन सब कुछ इतना बुरा नहीं है जितना लगता है। Rosreestr के बारे में एक नई परी कथा है। सेफ हर जगह घूम रहा था, और हर जगह वह असफल हो रहा था। कहीं न कहीं यह पूरी तरह से समाप्त हो गया, कहीं जल्दी से परिणाम को खत्म करने में कामयाब रहे।

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


समस्याएं सुबह 7 बजे शुरू हुईं, 11 बजे वे समझ गए कि क्या हो रहा है, और विफलता को खत्म करना शुरू कर दिया। ऐसा करने के लिए, उन्होंने दो आदेशों को आवंटित किया: किसी कारण से सर्वरों के आसपास भाग गया और वहां मेमोरी स्थापित की, और किसी कारण से दूसरे ने मैन्युअल रूप से एक के बाद एक सर्वर शुरू किया और सभी सर्वरों की सावधानीपूर्वक निगरानी की। क्यों? हम सभी एक क्लिक के साथ चालू की गई चीजों के लिए उपयोग किए जाते हैं

एक वितरित प्रणाली में मूल रूप से क्या होता है जब यह प्रभावी रूप से निर्मित होता है और लगभग अपनी क्षमताओं की सीमा पर काम करता है?

इस सवाल का जवाब देने के लिए, हमें यह देखने की जरूरत है कि सीएफएच क्लस्टर कैसे काम करता है और विफलता कैसे होती है।

सिफ फेलियर परिदृश्य

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

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

हर किसी को इस तथ्य के लिए उपयोग किया जाता है कि जब एक सर्वर विफल हो जाता है, तो सब कुछ खराब हो जाता है, और जब हम सर्वर को चालू करते हैं, तो सब कुछ अच्छा हो जाता है। यहां सब कुछ पूरी तरह से गलत है।

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


ऊपर सिफ के क्लस्टर प्रदर्शन का एक ग्राफ है जैसा कि एक विफलता विकसित होती है। कृपया ध्यान दें कि यहाँ जिन अंतरालों के बारे में हमने बात की है, वे बहुत स्पष्ट रूप से पता लगाए गए हैं:

• लगभग 70 सेकंड तक सामान्य ऑपरेशन;
• लगभग 130 सेकंड के लिए एक मिनट के लिए विफलता;
• एक पठार जो सामान्य ऑपरेशन की तुलना में काफी अधिक है, अपमानित समूहों का काम है;
• फिर हम लापता नोड को चालू करते हैं - यह एक प्रशिक्षण क्लस्टर है, केवल 3 सर्वर और 15 एसएसडी हैं। हम लगभग 260 सेकंड में सर्वर शुरू करते हैं।
• सर्वर चालू हुआ, क्लस्टर में प्रवेश किया - IOPS'y गिर गया।

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

OSD विफलता

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


इस मामले में, संदेश आमतौर पर मेजबान द्वारा वर्गीकृत किए जाते हैं, अर्थात, यदि अलग-अलग ओएसडी से दो संदेश एक ही मेजबान पर आते हैं, तो उन्हें एक संदेश में संयोजित किया जाता है। तदनुसार, यदि ओएसडी 11 और ओएसडी 12 रिपोर्ट करते हैं कि वे ओएसडी 1 तक नहीं पहुंच सकते हैं, तो यह व्याख्या की जाएगी क्योंकि होस्ट 11 को ओएसडी 1 के बारे में शिकायत की गई थी। जब ओएसडी 21 और ओएसडी 22 की रिपोर्ट की गई थी, तो यह व्याख्या की गई है कि होस्ट 21 ओएसडी 1 से असंतुष्ट है जिसके बाद मॉनिटर मानता है कि ओएसडी 1 डाउन स्थिति में है और क्लस्टर के सभी सदस्यों (ओएसडी मैप को बदलकर) को सूचित करता है, काम नीचा मोड में जारी है।


इसलिए, यहां हमारा क्लस्टर और विफल रैक (होस्ट 5 और होस्ट 6) है। हम होस्ट 5 और होस्ट 6 को चालू करते हैं, क्योंकि बिजली दिखाई देती है, और ...

सिफ का आंतरिक व्यवहार

और अब सबसे दिलचस्प हिस्सा यह है कि हम प्रारंभिक डेटा सिंक्रनाइज़ेशन शुरू कर रहे हैं। चूंकि कई प्रतिकृतियां हैं, उन्हें समकालिक होना चाहिए और एक ही संस्करण में होना चाहिए। OSD शुरू करने की प्रक्रिया में:

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

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

तुलना के लिए: जब हम RBD छवि के साथ काम करते हैं तो किसी वस्तु का विशिष्ट आकार 4 एमबी होता है। जब हम मिटाए गए कोड में काम करते हैं - 1MB। यदि हमारे पास 10 टीबी डिस्क है, तो हमें डिस्क पर एक मिलियन मेगाबाइट ऑब्जेक्ट मिलते हैं। यदि हमारे पास सर्वर में 10 डिस्क हैं, तो पहले से ही 10 मिलियन ऑब्जेक्ट हैं, अगर 32 डिस्क हैं (हम एक कुशल क्लस्टर का निर्माण कर रहे हैं, हमारे पास एक तंग आवंटन है), तो 32 मिलियन ऑब्जेक्ट को स्मृति में रखा जाना चाहिए। इसके अलावा, वास्तव में, प्रत्येक ऑब्जेक्ट के बारे में जानकारी कई प्रतियों में संग्रहीत होती है, क्योंकि प्रत्येक प्रतिलिपि इंगित करती है कि इस स्थान पर यह इस संस्करण में निहित है, और इसमें - इस एक में।

यह डेटा की एक बड़ी मात्रा को दर्शाता है, जो RAM में स्थित है:

• अधिक वस्तुएं, गुम होने का इतिहास जितना बड़ा_लोक;
• अधिक पीजी - अधिक pg_log और OSD मानचित्र;

इसके अलावा:

• डिस्क आकार जितना बड़ा होगा;
• उच्च घनत्व (प्रत्येक सर्वर में डिस्क की संख्या);
• क्लस्टर पर भार जितना अधिक होगा और आपका क्लस्टर उतना ही तेज़ होगा;
• अब OSD नीचे है (ऑफ़लाइन स्थिति में);

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

चरम अनुकूलन सभी बुराई की जड़ हैं

"... और काला OOM रात में बुरे लड़कों और लड़कियों के लिए आता है और बाएं और दाएं सभी प्रक्रियाओं को मारता है"

शहर sysadmin किंवदंती

तो, रैम की बहुत आवश्यकता है, मेमोरी की खपत बढ़ रही है (हमने क्लस्टर के एक तिहाई में तुरंत शुरू किया है) और सिद्धांत में सिस्टम SWAP में जा सकता है, अगर आपने इसे बनाया है। मुझे लगता है कि बहुत सारे लोग हैं जो सोचते हैं कि SWAP खराब है और वे इसे नहीं बनाते हैं: “क्यों? हमारे पास बहुत सी मेमोरी है! ” लेकिन यह गलत तरीका है।

यदि SWAP फ़ाइल पहले से नहीं बनाई गई है, क्योंकि यह निर्णय लिया गया था कि लिनक्स अधिक कुशलता से काम करेगा, तो जल्द ही या बाद में यह मेमोरी किलर (OOM- किलर) से बाहर हो जाएगा। और इस तथ्य से नहीं कि यह उस सभी को मार देगा जो सभी मेमोरी को खा जाता है, नहीं। वह जो पहले बदकिस्मत था। हम जानते हैं कि एक आशावादी स्थान क्या है - हम एक स्मृति के लिए पूछते हैं, वे हमें इसका वादा करते हैं, हम कहते हैं: "अब हमें एक" दो, जवाब में: "लेकिन नहीं!" - और मेमोरी किलर से बाहर।

यह एक नियमित लिनक्स काम है, जब तक कि वर्चुअल मेमोरी क्षेत्र में कॉन्फ़िगर नहीं किया जाता है।

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

फिर, प्रक्रिया, निश्चित रूप से, पुनरारंभ होगी - हमारे पास सिस्टमड है, यह भी लॉन्च करता है, यदि आवश्यक हो, तो ओएसडी जो गिर गए हैं। गिर OSDs शुरू, और ... एक श्रृंखला प्रतिक्रिया शुरू होती है।


हमारे मामले में, हमने ओएसडी 8 और ओएसडी 9 शुरू किया, उन्होंने सब कुछ कुचलना शुरू कर दिया, लेकिन कोई भी ओएसडी 0 और ओएसडी नहीं। 5. मेमोरी किलर में से एक ने उनके पास उड़ान भरी और उन्हें समाप्त कर दिया। उन्होंने पुनः आरंभ किया - उन्होंने अपना डेटा पढ़ा, शेष को समकालना और क्रश करना शुरू किया। तीन और अशुभ (OSD 9, OSD 4 और OSD 7)। ये तीनों फिर से शुरू हुए, पूरे क्लस्टर पर दबाव बनाना शुरू किया, अगला पैक अशुभ था।

क्लस्टर हमारी आंखों के सामने सचमुच गिरना शुरू कर देता है । गिरावट बहुत जल्दी होती है, और यह "बहुत तेज" आमतौर पर मिनटों में, अधिकतम दस मिनट में व्यक्त किया जाता है। यदि आपके पास 30 नोड्स (प्रति रैक 10 नोड्स) हैं, और बिजली की विफलता के कारण रैक को काट दिया - 6 मिनट के बाद, क्लस्टर का आधा हिस्सा।

तो, हम निम्नलिखित की तरह कुछ मिलता है।


लगभग हर सर्वर पर, हमारे पास एक विफल ओएसडी है। और अगर प्रत्येक सर्वर पर यह है, अर्थात, असफल ओएसडी के लिए हमारे पास प्रत्येक विफलता के क्षेत्र में है, तो हमारा अधिकांश डेटा अप्राप्य है । कोई अनुरोध अवरुद्ध है - लिखने के लिए, पढ़ने के लिए - इससे कोई फर्क नहीं पड़ता। वह सब है! हम उठे।

ऐसी स्थिति में क्या करें? अधिक सटीक रूप से, क्या किया जाना था ?

उत्तर: क्लस्टर को तुरंत शुरू न करें, अर्थात पूरा रैक, लेकिन ध्यान से एक-एक दानव बढ़ाएं।

लेकिन हम यह नहीं जानते थे। हमने तुरंत शुरुआत की, और हमें जो मिला वह मिला। इस मामले में, हमने चार डेमॉन (8, 9, 10, 11) में से एक को लॉन्च किया, मेमोरी की खपत लगभग 20% बढ़ जाएगी। एक नियम के रूप में, हम ऐसी छलांग लगाते हैं। फिर, मेमोरी की खपत कम होने लगती है, क्योंकि कुछ संरचनाएं जिनके बारे में जानकारी रखने के लिए इस्तेमाल किया गया था कि क्लस्टर कैसे ख़राब हो रहे हैं। यही है, प्लेसमेंट समूह का हिस्सा अपनी सामान्य स्थिति में लौट आया है, और अपमानित अवस्था को बनाए रखने के लिए आवश्यक हर चीज को मुक्त कर दिया गया है - सिद्धांत रूप में इसे मुक्त किया गया है ।

एक उदाहरण देखते हैं। बाईं और दाईं ओर C कोड लगभग समान है, अंतर केवल स्थिरांक में है।


ये दो उदाहरण सिस्टम से अलग मात्रा में मेमोरी का अनुरोध करते हैं:

• बाएं - 1 एमबी प्रत्येक के 2048 टुकड़े;
• दाएं - 1 कट्टे के 2097152 टुकड़े।

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

नीचे वास्तव में क्या हुआ है।

• सबसे पहले, दोनों प्रक्रियाएं शुरू हुईं और मेमोरी को खाया। सच की तरह लगता है - 2 जीबी आरएसएस।
• ENTER दबाएं और आश्चर्यचकित हो जाएं। पहला कार्यक्रम जो बड़े चौकों में खड़ा था, स्मृति वापस आ गई। लेकिन दूसरा कार्यक्रम नहीं लौटा।

ऐसा क्यों हुआ इसका जवाब लिनक्स मॉलॉक में है।

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

यदि हम छोटे टुकड़ों में मेमोरी आवंटित करते हैं, तो हम sbrk () करते हैं। sbrk () ढेर की पूंछ को सूचक को स्थानांतरित करता है, सिद्धांत रूप में, स्मृति को उपयोग नहीं किए जाने पर सिस्टम को स्मृति के पृष्ठ वापस करके शिफ्ट की गई पूंछ को वापस किया जा सकता है।

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


हमारे पास अभी भी बहुत सारे अप्रयुक्त स्थान हैं जिन्हें अगर हमें स्वैप किया जाता है तो उन्हें मुक्त किया जा सकता है। लेकिन हम स्मार्ट हैं - हमने SWAP को अक्षम कर दिया है।

बेशक, फिर ढेर की शुरुआत से मेमोरी का कुछ हिस्सा इस्तेमाल किया जाएगा, लेकिन यह केवल कुछ हिस्सा है, और बहुत महत्वपूर्ण शेष को कब्जा कर रखा जाएगा।

ऐसी स्थिति में क्या करें? जवाब नीचे है।

नियंत्रित प्रक्षेपण

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

DigitalOcean ने वास्तव में इसे पूरा किया:
"हमारी डाटासेंटर टीम स्मृति संवर्द्धन करती है जबकि दूसरी टीम धीरे-धीरे प्रत्येक मेजबान के मेमोरी बजट को प्रबंधित करते समय नोड्स को ऊपर ले जाती है।"


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

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

समस्या यह है कि सिफ में रखरखाव कैसे किया जाता है ।


हमारे पास 3 प्रतिकृतियां हैं: एक मास्टर ओएसडी और इसके लिए दो दास। हम स्पष्ट करेंगे कि प्रत्येक प्लेसमेंट समूह में मास्टर / दास का अपना एक है, लेकिन प्रत्येक के पास एक मास्टर और दो दास हैं।

लिखने या पढ़ने का कार्य मास्टर पर पड़ता है। पढ़ते समय, यदि मास्टर के पास सही संस्करण है, तो वह ग्राहक को देगा। रिकॉर्डिंग थोड़ा अधिक जटिल है, रिकॉर्डिंग को सभी प्रतिकृतियों पर दोहराया जाना चाहिए। तदनुसार, जब क्लाइंट OSD 0 में 64 KB लिखता है, तो हमारे उदाहरण में वही 64 KB OSD 5 और OSD 8 में जाता है।

लेकिन तथ्य यह है कि हमारा ओएसडी 8 बहुत नीचा है, क्योंकि हमने कई प्रक्रियाओं को फिर से शुरू किया है।


चूंकि सिफ में कोई भी परिवर्तन संस्करण से संस्करण में ओएसडी 0 और ओएसडी 5 पर एक संक्रमण है, हमारे पास ओएसडी 8 पर एक नया संस्करण होगा - पुराना। , , ( 64 ) OSD 8 — 4 ( ). 4 OSD 0, OSD 8, , . , 64 .

— .


:

• 4 1 , 1000 / 1 .
• 4 ( ) 22 , 45 /.

, , , , .

— .


4 22 , 22 , 1 4 . 45 SSD, 1 — 45 .

, .

• , — (45+1) / 2 = 23 .
• 75% , (45 * 3 + 1) / 4 = 34 .
• 90% —(45 * 9 + 1) / 10 = 41 — 40 , .

Ceph, . , , , .

Ceph .

1. — : , , , , .
   
2. — latency. latency , . 100% ( , ). Latency 60 , .
   

, . 10 , 1 200 /, 300 , , . 10 SSD — 300 , — , - 300 .

, .

, . 900 / ( SSD). 2 500 128 ( , ESXi HyperV 128 ). degraded, 225 . file store, object store, ( ), 110 , - .

SSD 110 — !

?

1: — .


: ; PG;
.

:

• , 45 — .
• ( . ), 14 .
• , 8 ( 10% PG).

, , , , , .

2: — (order, objectsize) .

, , , 4 2 1 . , , . :

• ;
• (latency) .

:

• ;
• ;
• — . 4 , .

(32 ) — !

3: — Ceph .

, -, Ceph . , , . .


, — Latency. — , — . Latency 30% , , .

Community , preproduction . , . , .

निष्कर्ष

- , . , Ceph - , , .

● - .
, . , . . , , production. , , , DigitalOcean , . , , , .

, , . , : « ! ?!» , , . , : , , down time.

● (OSD).
, , — , , - , . OSD — — . , .

● .
OSD . , . , , , .

● RAM OSD.

● SWAP.
SWAP Ceph' , Linux' . .

● .
100%, 10%. , , , .

● RBD Rados Getway.
, . SWAP — . , SWAP — , , , , .

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