फ्लाइंग कार्ट, अफू चैन

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

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

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

DevOps प्रोसेस से लेकर आपके अपने क्लाउड तक

DevOps प्रथाओं का उद्देश्य उत्पाद को जल्दी से जल्दी बाहर निकालना है:

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

सभी आभासी वातावरणों की वास्तुकला समान है: कंटेनर, एप्लिकेशन, सार्वजनिक और निजी नेटवर्क, भंडारण के साथ अतिथि मशीनें।

धीरे-धीरे, अधिक से अधिक सेवाओं को DevOps प्रक्रियाओं में और उसके आस-पास निर्मित आभासी बुनियादी ढांचे में तैनात किया जाता है, और आभासी वातावरण न केवल एक परीक्षण (विकास और परीक्षण के लिए उपयोग किया जाता है), बल्कि उत्पादक भी बन रहा है।

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

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

अपने स्वयं के क्लाउड का दूसरा तरीका बाहरी संसाधनों और बाहरी सेवा प्रदाताओं पर निर्भर नहीं होने की आवश्यकता है, अर्थात् आपकी स्वयं की सेवाओं के लिए कुछ तकनीकी स्वतंत्रता प्रदान करना।

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

निजी क्लाउड रिसीबिलिटी और प्रदर्शन

बादल बढ़ रहा है, व्यवसाय इस पर अधिक से अधिक निर्भर करता है, कंपनी अधिक विश्वसनीयता की मांग करना शुरू कर देती है।

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

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

स्थापना साइटों और आम भंडारण। लाल आयताकार नेटवर्क स्तर पर अड़चनें हैं।

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

कुछ प्रक्रियाओं के लिए, डेटा प्रतिकृति विलंबता स्वीकार्य है, लेकिन लेनदेन प्रसंस्करण जैसे मामलों में, लेनदेन खो नहीं सकते हैं। यदि एसिंक्रोनस प्रतिकृति का उपयोग किया जाता है, तो एक समय अंतराल होता है जो डेटा के एक हिस्से के नुकसान को जन्म दे सकता है यदि स्टोरेज सिस्टम (डेटा स्टोरेज सिस्टम) के "पूंछ" में से एक विफल हो जाता है। यदि तुल्यकालिक प्रतिकृति का उपयोग किया जाता है, तो सेवा समय बढ़ जाता है।

यह भी काफी स्वाभाविक है कि जब भंडारण का प्रसंस्करण समय (विलंबता) बढ़ता है, तो डेटाबेस धीमा होने लगता है और नकारात्मक प्रभाव पड़ता है जिससे लड़ना पड़ता है।

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

हरा रंग अतिरिक्त स्थानीय रूप से सिफित समूहों को इंगित करता है।

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

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

सिफ डायग्नोस्टिक्स: निगरानी का निर्माण कैसे करें

जब हमने बुनियादी ढांचे को तैनात किया और लॉन्च किया, तो समय के साथ इसकी कार्यप्रणाली सुनिश्चित करने और विफलताओं की संख्या को कम करने का समय था। इसलिए, बुनियादी ढांचे के विकास में अगला कदम निदान और निगरानी का निर्माण था।

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

मॉनिटरिंग द्वारा कवर नहीं किए गए तत्व

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

पहला चरण: हम निगरानी डिस्क को कवर करते हैं।

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

दूसरा चरण: नेटवर्क की निगरानी।

वे अक्सर इस पर रोकते हैं, लेकिन ऐसा नहीं किया जा सकता है, क्योंकि अधिकांश बुनियादी ढांचे को अभी तक निगरानी द्वारा बंद नहीं किया गया है।

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

तीसरा चरण: स्टोरेज डेमॉन की निगरानी।

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

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

केवल सेफ ही पर्याप्त क्यों नहीं है और इसके बारे में क्या करना है

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

निगरानी प्रणाली आपको यह देखने की अनुमति नहीं देती है कि आभासी पर्यावरण ग्राहकों के अंदर क्या हो रहा है। नतीजतन, समस्या की पहचान करने के लिए, हमने उन्नत विश्लेषण का उपयोग किया, जिसका अनुरोध उसकी वर्चुअल मशीन से blktrace उपयोगिता का उपयोग करके किया गया था।

एक विस्तारित विश्लेषण का परिणाम है।

विश्लेषण परिणामों में झंडे डब्ल्यू और डब्ल्यूएस के साथ चिह्नित संचालन शामिल हैं। W फ्लैग एक रिकॉर्ड है, WS फ्लैग एक सिंक्रोनस रिकॉर्ड है, जो ऑपरेशन को पूरा करने के लिए डिवाइस की प्रतीक्षा कर रहा है। जब हम डेटाबेस के साथ काम करते हैं, तो लगभग सभी SQL डेटाबेस में एक अड़चन होती है - WAL (राइट-फॉरवर्ड लॉग)।

डेटाबेस हमेशा लॉग में डेटा लिखता है, फ्लशिंग बफ़र्स के साथ डिस्क से पुष्टि प्राप्त करता है, फिर यह डेटा को डेटाबेस में ही लिखता है। यदि उसे बफर रीसेट की पुष्टि नहीं मिली है, तो उसका मानना है कि पावर रीसेट ग्राहक द्वारा पुष्टि किए गए लेनदेन को मिटा सकता है। यह डेटाबेस के लिए अस्वीकार्य है, इसलिए यह "SYNC / FLUSH लिखें" प्रदर्शित करता है, फिर डेटा लिखता है। जब लॉग भरे होते हैं, तो उनका स्विच होता है, और पेज कैश में जो कुछ भी मिला, उसे भी जबरन फ्लैश किया जाता है। जोड़ा गया: चित्र में स्वयं कोई रीसेट नहीं है - अर्थात, पूर्व-फ़्लश ध्वज के साथ संचालन। वे FWS की तरह दिखते हैं - प्री-फ्लश + राइट + सिंक या FWSF - प्री-फ्लश + राइट + सिंक + एचयूए

जब एक ग्राहक के कई छोटे लेन-देन होते हैं, तो उसके सभी I / O अनुक्रमिक श्रृंखला में बदल जाते हैं: लिखना - फ्लश - लिखना - फ्लश। चूंकि आप डेटाबेस के साथ कुछ नहीं कर सकते हैं, हम भंडारण प्रणाली के साथ काम करना शुरू करते हैं। इस समय, हम समझते हैं कि सिफ की क्षमताएं पर्याप्त नहीं हैं।

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

अतिरिक्त स्थानीयकृत रिपॉजिटरी लक्ष्य ए और बी।

इस तरह के स्थानीय भंडारण का सेवा समय प्रति स्ट्रीम 0.3 एमएस है। यदि यह किसी अन्य डेटा केंद्र में स्थित है, तो यह अधिक धीमी गति से काम करता है - लगभग 0.7 एमएस के प्रदर्शन के साथ। यह सेफ की तुलना में एक महत्वपूर्ण वृद्धि है, जो 1.2 एमएस का उत्पादन करता है, और डेटा केंद्रों पर वितरित किया जाता है - 2 एमएस। ऐसे छोटे कारखानों का प्रदर्शन, जिनमें से एक दर्जन से अधिक हमारे पास हैं, प्रति मॉड्यूल लगभग 100 हजार, प्रति रिकॉर्ड 100 हजार IOPS है।

बुनियादी ढांचे में इस तरह के बदलाव के बाद, हमारे क्लाउड लेखन के लिए एक लाख IOPS के तहत, या सभी ग्राहकों के लिए कुल पढ़ने के लिए लगभग दो से तीन मिलियन IOPS निचोड़ते हैं:

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

नए पुनरावृत्तियों: कोड और बुनियादी ढांचे में सुधार

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

ऐसा करने के लिए, हमें अंतिमकरण और गैर-तुच्छ रोल-आउट करना था - उत्पादक को पुनरावृत्त वितरण।

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

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

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

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

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

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

तीसरी समस्या है सोने की छवियों से HDD तक तैनात वर्चुअल मशीनों का गलत संचालन ।

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

अनुसंधान की प्रक्रिया में, हमने महसूस किया कि हमारे निगरानी बुनियादी ढांचे की क्षमताएं अभी भी पर्याप्त नहीं हैं।

निगरानी ने नीले हिस्से को बंद कर दिया, और समस्या बुनियादी ढांचे के शीर्ष पर थी, निगरानी द्वारा कवर नहीं किया गया।

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

हमने क्या देखा? हमने सेफ क्लस्टर / ओएसडी / क्लस्टर पर आंकड़े नहीं देखे, लेकिन क्लाइंट वर्चुअल मशीन के प्रत्येक डिस्क पर आंकड़े जिनकी डिस्क सेफ में थीं - यानी, डिवाइस से जुड़े आंकड़े।

उन्नत निगरानी आँकड़े परिणाम।

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

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

समस्या स्थानीय है, अब एक समाधान की आवश्यकता है - कोड या बुनियादी ढांचा?

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

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

क्यों बुनियादी ढाँचा निगरानी महत्वपूर्ण है

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

सेफ़ से अधिक: एमसीएस ब्लॉक क्लाउड स्टोरेज