Yandex में प्रबंधित डेटाबेस सेवाओं को कैसे प्रबंधित किया जाता है

जब आप किसी के पास सबसे कीमती चीज पर भरोसा करते हैं - आपके आवेदन या सेवा का डेटा - आप कल्पना करना चाहते हैं कि यह कोई आपके सबसे बड़े मूल्य को कैसे संभालेगा।

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

अच्छा, चलिए!



प्रबंधित डेटाबेस (Yandex प्रबंधित डेटाबेस) सबसे लोकप्रिय Yandex.Cloud सेवाओं में से एक है। अधिक सटीक रूप से, यह सेवाओं का एक पूरा समूह है, जो अब लोकप्रियता में यैंडेक्स कंप्यूट क्लाउड वर्चुअल मशीनों के बाद दूसरे स्थान पर है।

Yandex प्रबंधित डेटाबेस जल्दी से काम करने वाला डेटाबेस प्राप्त करना संभव बनाता है और इस तरह के कार्य करता है:

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

कैसे प्रबंधित डेटाबेस सेवाओं की व्यवस्था की जाती है: शीर्ष दृश्य

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



सेवा उपयोगकर्ताओं के पास वास्तव में दो प्रवेश बिंदु हैं:

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

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

डाटा प्लेन

कंट्रोल प्लेन के घटकों को देखने से पहले, आइए देखें कि डेटा प्लेन में क्या हो रहा है।

एक वर्चुअल मशीन के अंदर

MDB उन्हीं वर्चुअल मशीनों में डेटाबेस चलाता है जो Yandex Compute Cloud में प्रदान की जाती हैं।



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

वर्चुअल मशीन के अंदर, सेवाओं का एक निश्चित मानक सेट लॉन्च किया गया है, प्रत्येक DBMS के लिए इसका अपना:

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

नेटवर्क टोपोलॉजी

प्रत्येक डेटा प्लेन होस्ट में दो नेटवर्क इंटरफेस हैं:

• उनमें से एक उपयोगकर्ता के नेटवर्क में चिपक जाता है। सामान्य तौर पर, उत्पाद लोड की सेवा के लिए यह आवश्यक है। इसके माध्यम से, प्रतिकृति पीछा कर रही है।
• दूसरा हमारे प्रबंधित नेटवर्क में से एक में चिपक जाता है जिसके माध्यम से होस्ट कंट्रोल प्लेन में जाते हैं।

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

डेटा विमान सुरक्षा

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

अंत में, हमने निम्नलिखित करने में बहुत प्रयास किया:

• स्थानीय और बड़े फ़ायरवॉल;
• सभी कनेक्शन और बैकअप का एन्क्रिप्शन;
• प्रमाणीकरण और प्राधिकरण के साथ सभी;
• निकल रहा;
• स्वयं लिखित IDS।

अब नियंत्रण विमान के घटकों पर विचार करें।

नियंत्रण विमान

आंतरिक एपीआई

आंतरिक एपीआई कंट्रोल प्लेन में पहला प्रवेश बिंदु है। आइए देखें कि यहां सब कुछ कैसे काम करता है।



मान लीजिए कि आंतरिक API को डेटाबेस क्लस्टर बनाने के लिए अनुरोध प्राप्त होता है।

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

और आंतरिक एपीआई अन्य सेवाओं के एपीआई के लिए अनुरोध भेज सकता है। यदि आप एक निश्चित नेटवर्क A में एक क्लस्टर बनाना चाहते हैं, और एक विशिष्ट सबनेट B में एक विशिष्ट होस्ट, आंतरिक API को यह सुनिश्चित करना होगा कि आपके पास नेटवर्क A और निर्दिष्ट सबनेट B दोनों के अधिकार हैं, साथ ही, यह जाँच करेगा कि सबनेट B नेटवर्क A से संबंधित है। इसके लिए इंफ्रास्ट्रक्चर एपीआई की पहुंच आवश्यक है।

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

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

मज़दूर

कार्यकर्ता बस प्रक्रियाओं का एक सेट है जो मेटाडाबी में परिचालन की कतार को क्वेरी करते हैं, उन्हें पकड़ते हैं और उन्हें निष्पादित करते हैं।



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

इसके अलावा, कार्यकर्ता अन्य क्लाउड सेवाओं तक पहुँच प्राप्त करता है। उदाहरण के लिए, यैंडेक्स ऑब्जेक्ट स्टोरेज को एक बाल्टी बनाने के लिए जिसमें क्लस्टर बैकअप सहेजे जाएंगे। यांडेक्स मॉनिटरिंग सेवा के लिए, जो डेटाबेस मेट्रिक्स को इकट्ठा करेगा और कल्पना करेगा। कार्यकर्ता को वहाँ क्लस्टर मेटा-जानकारी बनानी होगी। DNS एपीआई के लिए, यदि उपयोगकर्ता क्लस्टर होस्ट के लिए सार्वजनिक आईपी पते असाइन करना चाहता है।

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

इन्फ्रास्ट्रक्चर तैनात करें

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

नमक के मुख्य घटक नमक मास्टर हैं, जो कि क्या लागू किया जाना चाहिए और कहाँ के बारे में जानकारी संग्रहीत करता है, और नमक मिनियन, एक एजेंट जो प्रत्येक मेजबान पर स्थापित किया गया है, मास्टर के साथ बातचीत करता है और नमक मास्टर से सीधे मेजबान को नमक लागू कर सकता है। इस लेख के प्रयोजनों के लिए, हमारे पास इस ज्ञान के लिए पर्याप्त है, और आप साल्टस्टैक प्रलेखन में अधिक पढ़ सकते हैं।

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



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

नमक के स्वामी पर दो अतिरिक्त घटक स्थापित होते हैं:

• साल्ट रेस्ट एपीआई , जो एपीआई को रोलआउट करने के लिए इंटरैक्ट करता है। REST API स्थानीय नमक-स्वामी के पास जाता है, और वह पहले से ही ZeroMQ का उपयोग करके minions के साथ संचार करता है।
• सार यह है कि यह डिप्लॉय एपीआई में जाता है और सभी खानों की सार्वजनिक कुंजी प्राप्त करता है जो इस नमक-मास्टर से जुड़ा होना चाहिए। मास्टर पर सार्वजनिक कुंजी के बिना, मिनियन बस मास्टर से कनेक्ट नहीं कर सकता।

नमक मीनार के अलावा, दो घटक डेटा प्लेन में भी स्थापित किए गए हैं:

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

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

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

एमडीबी स्वास्थ्य

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



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

एमडीबी डीएनएस

CNB रिकॉर्ड्स को प्रबंधित करने के लिए MDB DNS माइक्रोसिस्ट सेवा की आवश्यकता है। यदि डेटाबेस से कनेक्ट करने के लिए ड्राइवर कनेक्शन स्ट्रिंग में कई होस्ट को स्थानांतरित करने की अनुमति नहीं देता है, तो आप एक विशेष CNAME से कनेक्ट कर सकते हैं, जो हमेशा क्लस्टर में वर्तमान मास्टर को इंगित करता है। यदि मास्टर स्विच करता है, तो CNAME बदल जाता है।



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

हमने इसके लिए एक अलग सेवा क्यों बनाई? क्योंकि DNS API का एक्सेस नियंत्रण केवल ज़ोन स्तर पर होता है। एक संभावित हमलावर, एक अलग वर्चुअल मशीन तक पहुंच प्राप्त करने, अन्य उपयोगकर्ताओं के CNAME रिकॉर्ड बदल सकता है। एमडीबी डीएनएस इस परिदृश्य को बाहर करता है क्योंकि यह प्राधिकरण के लिए जाँच करता है।

वितरण और डेटाबेस लॉग का प्रदर्शन

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

मशीनों का एक अलग पूल - LogConsumers - LogBroker कतार से लॉग लेता है और उन्हें LogsDB डेटाबेस में संग्रहीत करता है। ClickHouse DBMS लॉग डेटाबेस के लिए उपयोग किया जाता है।



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

बिलिंग

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

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

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

बैकअप

बैकअप योजना अलग-अलग DBMS के लिए थोड़ी भिन्न हो सकती है, लेकिन सामान्य सिद्धांत हमेशा समान होता है।

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



इस तरह कंट्रोल प्लेन और डाटा प्लेन काम करते हैं। इस सब से, Yandex.Cloud प्रबंधित डेटाबेस सेवा बनाई जाती है।

क्यों सब कुछ इस तरह से व्यवस्थित किया जाता है

बेशक, वैश्विक स्तर पर, कुछ को सरल योजनाओं के अनुसार लागू किया जा सकता है। लेकिन हमारे अपने कारण थे कि कम से कम प्रतिरोध के मार्ग का अनुसरण न किया जाए।

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

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

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

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

भविष्य की योजना

और मध्यम अवधि के लिए सेवा को बेहतर बनाने की योजनाओं के बारे में कुछ शब्द। ये ऐसी योजनाएं हैं जो व्यक्तिगत DBMS के बजाय संपूर्ण यांडेक्स प्रबंधित डेटाबेस को प्रभावित करती हैं।

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

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

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

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

प्रबंधित डेटाबेस सेवा के बारे में हमारी कहानी लंबी और शायद काफी थकाऊ रही। किसी भी शब्द और विवरण से बेहतर, केवल वास्तविक अभ्यास। इसलिए, यदि आप चाहें, तो आप स्वतंत्र रूप से हमारी सेवाओं की क्षमताओं का मूल्यांकन कर सकते हैं:

• PostgreSQL के लिए Yandex प्रबंधित सेवा
• MySQL के लिए Yandex प्रबंधित सेवा
• MongoDB के लिए यैंडेक्स प्रबंधित सेवा
• Yandex ClickHouse के लिए प्रबंधित सेवा
• रेडिस के लिए यैंडेक्स प्रबंधित सेवा
• Yandex Data Proc