रिपोर्ट कुबेरनेट्स में एक ऑपरेटर को विकसित करने, इसकी वास्तुकला और बुनियादी संचालन सिद्धांतों को डिजाइन करने के व्यावहारिक मुद्दों के लिए समर्पित है।
रिपोर्ट के पहले भाग में हम इस पर विचार करेंगे:
- कुबेरनेट्स में ऑपरेटर क्या है और इसकी आवश्यकता क्यों है;
- ऑपरेटर जटिल प्रणालियों के प्रबंधन को कैसे सरल बनाता है;
- ऑपरेटर क्या कर सकता है और क्या नहीं।
इसके बाद, आइए ऑपरेटर की आंतरिक संरचना पर चर्चा करें। आइए चरण दर चरण ऑपरेटर की वास्तुकला और संचालन को देखें। आइए इसे विस्तार से देखें:
- ऑपरेटर और कुबेरनेट्स के बीच बातचीत;
- ऑपरेटर कौन से कार्य करता है और वह कुबेरनेट्स को कौन से कार्य सौंपता है।
आइए कुबेरनेट्स में शार्ड और डेटाबेस प्रतिकृतियों को प्रबंधित करने पर नज़र डालें।
आगे, हम डेटा भंडारण के मुद्दों पर चर्चा करेंगे:
- एक ऑपरेटर के दृष्टिकोण से परसिस्टेंट स्टोरेज के साथ कैसे काम करें;
- स्थानीय संग्रहण का उपयोग करने के नुकसान.
रिपोर्ट के अंतिम भाग में, हम अनुप्रयोग के व्यावहारिक उदाहरणों पर विचार करेंगे Amazon या Google क्लाउड सेवा के साथ। रिपोर्ट ClickHouse के लिए एक ऑपरेटर के विकास और संचालन अनुभव के उदाहरण पर आधारित है।
वीडियो:
मेरा नाम व्लादिस्लाव क्लिमेंको है। आज मैं एक ऑपरेटर के विकास और संचालन में हमारे अनुभव के बारे में बात करना चाहता था, और यह डेटाबेस क्लस्टर के प्रबंधन के लिए एक विशेष ऑपरेटर है। उदाहरण के लिए ClickHouse क्लस्टर को प्रबंधित करने के लिए।
हमें ऑपरेटर और ClickHouse के बारे में बात करने का अवसर क्यों मिलता है?
- हम ClickHouse का समर्थन और विकास करते हैं।
- फिलहाल, हम धीरे-धीरे ClickHouse के विकास में अपना योगदान देने का प्रयास कर रहे हैं। और ClickHouse में किए गए परिवर्तनों की मात्रा के मामले में हम Yandex के बाद दूसरे स्थान पर हैं।
- हम ClickHouse पारिस्थितिकी तंत्र के लिए अतिरिक्त परियोजनाएँ बनाने का प्रयास कर रहे हैं।
मैं आपको इनमें से एक परियोजना के बारे में बताना चाहूंगा। यह कुबेरनेट्स के लिए क्लिकहाउस-ऑपरेटर के बारे में है।
अपनी रिपोर्ट में मैं दो विषयों पर बात करना चाहूंगा:
- पहला विषय यह है कि हमारा क्लिकहाउस डेटाबेस प्रबंधन ऑपरेटर कुबेरनेट्स में कैसे काम करता है।
- दूसरा विषय यह है कि कोई भी ऑपरेटर कैसे काम करता है, यानी वह कुबेरनेट्स के साथ कैसे इंटरैक्ट करता है।
हालाँकि, ये दोनों प्रश्न मेरी पूरी रिपोर्ट में एक दूसरे से जुड़े रहेंगे।
मैं जो कहना चाह रहा हूं उसे सुनने में किसे दिलचस्पी होगी?
- यह उन लोगों के लिए सबसे अधिक रुचिकर होगा जो ऑपरेटर संचालित करते हैं।
- या उन लोगों के लिए जो यह समझने के लिए अपना स्वयं का निर्माण करना चाहते हैं कि यह आंतरिक रूप से कैसे काम करता है, ऑपरेटर कुबेरनेट्स के साथ कैसे इंटरैक्ट करता है, और क्या नुकसान सामने आ सकते हैं।
आज हम जिस पर चर्चा करेंगे उसे बेहतर ढंग से समझने के लिए, यह जानना एक अच्छा विचार है कि कुबेरनेट्स कैसे काम करता है और कुछ बुनियादी क्लाउड प्रशिक्षण प्राप्त करें।
क्लिकहाउस क्या है? यह विश्लेषणात्मक प्रश्नों के ऑनलाइन प्रसंस्करण के लिए विशिष्ट सुविधाओं वाला एक स्तंभ डेटाबेस है। और यह पूरी तरह से खुला स्रोत है.
और हमारे लिए दो ही बातें जानना जरूरी है. आपको यह जानना होगा कि यह एक डेटाबेस है, इसलिए जो मैं आपको बताऊंगा वह लगभग किसी भी डेटाबेस पर लागू होगा। और तथ्य यह है कि ClickHouse DBMS बहुत अच्छी तरह से स्केल करता है, लगभग रैखिक स्केलेबिलिटी देता है। और इसलिए, क्लिकहाउस के लिए क्लस्टर स्थिति एक प्राकृतिक स्थिति है। और हम कुबेरनेट्स में क्लिकहाउस क्लस्टर की सेवा कैसे करें, इस पर चर्चा करने में सबसे अधिक रुचि रखते हैं।
उसकी वहां आवश्यकता क्यों है? हम इसे स्वयं संचालित क्यों नहीं कर सकते? और उत्तर आंशिक रूप से तकनीकी और आंशिक रूप से संगठनात्मक हैं।
- व्यवहार में, हम तेजी से ऐसी स्थिति का सामना कर रहे हैं जहां बड़ी कंपनियों में लगभग सभी घटक पहले से ही कुबेरनेट्स में हैं। डेटाबेस बाहर रहते हैं.
- और यह सवाल तेजी से पूछा जा रहा है: "क्या इसे अंदर रखा जा सकता है?" इसलिए, बड़ी कंपनियाँ अपने डेटा गोदामों को शीघ्रता से प्रबंधित करने में सक्षम होने के लिए प्रबंधन का अधिकतम एकीकरण प्राप्त करने का प्रयास कर रही हैं।
- और यह विशेष रूप से तब मदद करता है जब आपको एक ही चीज़ को नई जगह पर दोहराने के लिए अधिकतम अवसर की आवश्यकता होती है, यानी अधिकतम पोर्टेबिलिटी।
यह कितना आसान या कठिन है? बेशक, यह हाथ से किया जा सकता है। लेकिन यह इतना आसान नहीं है, क्योंकि हमारे पास कुबेरनेट्स को प्रबंधित करने की अतिरिक्त जटिलता है, लेकिन साथ ही ClickHouse की विशिष्टताएँ आरोपित हैं। और ऐसे एकत्रीकरण का परिणाम होता है।
और यह सब मिलकर प्रौद्योगिकियों का एक काफी बड़ा सेट देता है, जिसे प्रबंधित करना काफी कठिन हो जाता है, क्योंकि कुबेरनेट्स अपने रोजमर्रा के मुद्दों को संचालन में लाता है, और क्लिकहाउस अपने स्वयं के मुद्दों को रोजमर्रा के संचालन में लाता है। विशेष रूप से यदि हमारे पास कई ClickHouse हैं, और हमें उनके साथ लगातार कुछ न कुछ करने की आवश्यकता है।
गतिशील कॉन्फ़िगरेशन के साथ, ClickHouse में काफी बड़ी संख्या में समस्याएँ हैं जो DevOps पर निरंतर लोड पैदा करती हैं:
- जब हम ClickHouse में कुछ बदलना चाहते हैं, उदाहरण के लिए, एक प्रतिकृति या शार्ड जोड़ना, तो हमें कॉन्फ़िगरेशन को प्रबंधित करने की आवश्यकता होती है।
- फिर डेटा स्कीमा बदलें, क्योंकि ClickHouse में एक विशिष्ट शार्डिंग विधि है। वहां आपको डेटा आरेख तैयार करने, कॉन्फ़िगरेशन तैयार करने की आवश्यकता है।
- आपको निगरानी स्थापित करने की आवश्यकता है.
- नए टुकड़ों के लिए, नई प्रतिकृतियों के लिए लॉग एकत्रित करना।
- बहाली का ख्याल रखें.
- और पुनः आरंभ करें.
ये नियमित कार्य हैं जिन्हें मैं वास्तव में उपयोग में आसान बनाना चाहूंगा।
कुबेरनेट्स स्वयं संचालन में अच्छी तरह से मदद करता है, लेकिन बुनियादी सिस्टम चीजों पर।
कुबेरनेट्स निम्नलिखित चीजों को सुविधाजनक बनाने और स्वचालित करने में अच्छा है:
- स्वास्थ्य लाभ।
- पुनः आरंभ करें।
- भंडारण प्रणाली प्रबंधन.
यह अच्छा है, यह सही दिशा है, लेकिन डेटाबेस क्लस्टर को कैसे संचालित किया जाए, इसके बारे में वह पूरी तरह से अनभिज्ञ है।
हम और अधिक चाहते हैं, हम चाहते हैं कि पूरा डेटाबेस कुबेरनेट्स में काम करे।
मैं एक बड़े जादुई लाल बटन जैसा कुछ पाना चाहता हूं जिसे आप दबाते हैं और रोजमर्रा के कार्यों का एक समूह जिसे हल करने की आवश्यकता होती है, उसे पूरे जीवन चक्र में तैनात और बनाए रखा जाता है। कुबेरनेट्स में क्लिकहाउस क्लस्टर।
और हमने एक ऐसा समाधान निकालने का प्रयास किया जो काम को आसान बनाने में मदद करेगा। यह Altinity से Kubernetes के लिए एक ClickHouse-ऑपरेटर है।
ऑपरेटर एक प्रोग्राम होता है जिसका मुख्य कार्य अन्य प्रोग्राम को मैनेज करना होता है अर्थात यह एक मैनेजर होता है।
और इसमें व्यवहार के पैटर्न शामिल हैं। इसे आप विषय क्षेत्र के बारे में संहिताबद्ध ज्ञान कह सकते हैं।
और उनका मुख्य कार्य DevOps के जीवन को आसान बनाना और माइक्रोमैनेजमेंट को कम करना है, ताकि वह (DevOps) पहले से ही उच्च-स्तरीय शब्दों में सोचें, यानी, ताकि वह (DevOps) माइक्रोमैनेजमेंट में संलग्न न हों, ताकि वह कॉन्फ़िगर न करें सभी विवरण मैन्युअल रूप से।
और बस ऑपरेटर एक रोबोटिक सहायक है जो माइक्रोटास्क से निपटता है और DevOps की मदद करता है।
आपको ऑपरेटर की आवश्यकता क्यों है? वह दो क्षेत्रों में विशेष रूप से अच्छा प्रदर्शन करता है:
- जब ClickHouse से संबंधित विशेषज्ञ के पास पर्याप्त अनुभव नहीं है, लेकिन पहले से ही ClickHouse को संचालित करने की आवश्यकता है, तो ऑपरेटर ऑपरेशन की सुविधा देता है और आपको एक जटिल कॉन्फ़िगरेशन के साथ ClickHouse क्लस्टर को संचालित करने की अनुमति देता है, बिना यह बताए कि यह सब कैसे काम करता है। अंदर। आप बस उसे उच्च-स्तरीय कार्य दें, और यह काम करता है।
- और दूसरा कार्य जिसमें यह सबसे अच्छा प्रदर्शन करता है वह तब होता है जब बड़ी संख्या में विशिष्ट कार्यों को स्वचालित करना आवश्यक होता है। सिस्टम प्रशासकों से सूक्ष्म कार्य हटाता है।
इसकी सबसे अधिक आवश्यकता या तो उन लोगों को है जो अभी अपनी यात्रा शुरू कर रहे हैं, या उनके लिए जिन्हें बहुत अधिक स्वचालन करने की आवश्यकता है।
ऑपरेटर-आधारित दृष्टिकोण अन्य प्रणालियों से किस प्रकार भिन्न है? हेल्म है. यह ClickHouse को स्थापित करने में भी मदद करता है; आप हेल्म चार्ट बना सकते हैं, जो पूरे ClickHouse क्लस्टर को भी स्थापित करेगा। तो फिर ऑपरेटर और उसी, उदाहरण के लिए, हेल्म के बीच क्या अंतर है?
मुख्य मूलभूत अंतर यह है कि हेल्म पैकेज प्रबंधन है और ऑपरेटर एक कदम आगे जाता है। यह संपूर्ण जीवन चक्र के लिए समर्थन है। यह केवल इंस्टालेशन नहीं है, ये रोजमर्रा के कार्य हैं जिनमें स्केलिंग, शार्डिंग, यानी वह सब कुछ जो जीवन चक्र के दौरान करने की आवश्यकता है (यदि आवश्यक हो, तो हटाना भी) - यह सब ऑपरेटर द्वारा तय किया जाता है। यह संपूर्ण सॉफ़्टवेयर जीवनचक्र को स्वचालित और बनाए रखने का प्रयास करता है। प्रस्तुत किए गए अन्य समाधानों से यह इसका मूलभूत अंतर है।
वह परिचयात्मक भाग था, चलिए आगे बढ़ते हैं।
हम अपना ऑपरेटर कैसे बनाएं? हम ClickHouse क्लस्टर को एकल संसाधन के रूप में प्रबंधित करने के मुद्दे पर विचार करने का प्रयास कर रहे हैं।
यहां हमारे पास चित्र के बाईं ओर इनपुट डेटा है। यह एक क्लस्टर विनिर्देश के साथ YAML है, जिसे Kubectl के माध्यम से क्लासिक तरीके से Kubernetes को पास किया जाता है। वहां हमारा ऑपरेटर उसे उठाता है और अपना जादू दिखाता है। और आउटपुट पर हमें निम्नलिखित योजना मिलती है। यह Kubernetes में ClickHouse का कार्यान्वयन है।
और फिर हम धीरे-धीरे देखेंगे कि ऑपरेटर वास्तव में कैसे काम करता है, कौन से विशिष्ट कार्य हल किए जा सकते हैं। हम केवल विशिष्ट कार्यों पर विचार करेंगे क्योंकि हमारे पास सीमित समय है। और हर उस चीज़ पर चर्चा नहीं की जाएगी जो ऑपरेटर तय कर सकता है।
चलिए अभ्यास से शुरू करते हैं। हमारा प्रोजेक्ट पूरी तरह से खुला स्रोत है, इसलिए आप देख सकते हैं कि यह GitHub पर कैसे काम करता है। और आप इस विचार से आगे बढ़ सकते हैं कि अगर आप इसे लॉन्च करना ही चाहते हैं तो क्विक स्टार्ट गाइड से शुरुआत कर सकते हैं।
यदि आप विस्तार से समझना चाहते हैं तो हम दस्तावेज़ीकरण को कमोबेश सभ्य रूप में बनाए रखने का प्रयास करते हैं।
आइए एक व्यावहारिक समस्या से शुरुआत करें। पहला कार्य, जहाँ से हम सभी शुरू करना चाहते हैं, पहला उदाहरण किसी तरह चलाना है। मैं ऑपरेटर का उपयोग करके ClickHouse कैसे लॉन्च कर सकता हूं, भले ही मैं वास्तव में नहीं जानता कि यह कैसे काम करता है? हम एक घोषणापत्र लिख रहे हैं, क्योंकि... K8s के साथ सभी संचार मैनिफ़ेस्ट के माध्यम से संचार है।
यह बहुत ही जटिल घोषणापत्र है. हमने लाल रंग में जो हाइलाइट किया है, उसी पर हमें ध्यान केंद्रित करने की जरूरत है। हम ऑपरेटर से डेमो नाम का एक क्लस्टर बनाने के लिए कहते हैं।
ये अभी के लिए बुनियादी उदाहरण हैं। भंडारण का अभी तक वर्णन नहीं किया गया है, लेकिन हम थोड़ी देर बाद भंडारण पर लौटेंगे। अभी के लिए, हम क्लस्टर के विकास की गतिशीलता का अवलोकन करेंगे।
हमने यह घोषणापत्र बनाया. हम इसे अपने ऑपरेटर को खिलाते हैं। उसने काम किया, उसने जादू किया।
हम कंसोल को देखते हैं। तीन घटक रुचि के हैं: एक पॉड, दो सेवाएँ, और एक स्टेटफुलसेट।
ऑपरेटर ने काम किया है, और हम देख सकते हैं कि उसने वास्तव में क्या बनाया है।
वह कुछ इस तरह का निर्माण करता है. हमारे पास प्रत्येक प्रतिकृति के लिए एक स्टेटफुलसेट, पॉड, कॉन्फ़िगमैप, संपूर्ण क्लस्टर के लिए कॉन्फ़िगमैप है। क्लस्टर में प्रवेश बिंदु के रूप में सेवाओं की आवश्यकता होती है।
सेवाएँ केंद्रीय लोड बैलेंसर सेवा हैं और इनका उपयोग प्रत्येक प्रतिकृति के लिए, प्रत्येक शार्ड के लिए भी किया जा सकता है।
हमारा मूल क्लस्टर कुछ इस तरह दिखता है। यह एक ही नोड से है.
आइए आगे बढ़ें और चीजों को जटिल बनाएं। हमें क्लस्टर को शार्प करने की जरूरत है।
हमारे कार्य बढ़ रहे हैं, गतिशीलता शुरू हो रही है। हम एक टुकड़ा जोड़ना चाहते हैं. हम विकास का अनुसरण करते हैं। हम अपना विनिर्देश बदल रहे हैं. हम संकेत करते हैं कि हमें दो टुकड़े चाहिए।
यह वही फ़ाइल है जो सिस्टम के विकास के साथ गतिशील रूप से विकसित होती है। भंडारण नहीं, भंडारण पर आगे चर्चा की जाएगी, यह एक अलग विषय है।
हम YAML ऑपरेटर को फ़ीड करते हैं और देखते हैं कि क्या होता है।
ऑपरेटर ने सोचा और निम्नलिखित इकाइयाँ बनाईं। हमारे पास पहले से ही दो पॉड, तीन सेवाएँ और, अचानक, 2 स्टेटफुलसेट हैं। 2 स्टेटफुलसेट क्यों?
आरेख पर यह इस प्रकार था - यह हमारी प्रारंभिक अवस्था है, जब हमारे पास एक पॉड था।
ऐसा हो गया. अब तक सब कुछ सरल है, इसे दोहराया गया है।
और दो स्टेटफुलसेट क्यों बन गए? यहां हमें विषयांतर करने और इस प्रश्न पर चर्चा करने की आवश्यकता है कि कुबेरनेट्स में पॉड्स को कैसे प्रबंधित किया जाता है।
स्टेटफुलसेट नामक एक ऑब्जेक्ट है जो आपको टेम्पलेट से पॉड्स का एक सेट बनाने की अनुमति देता है। यहां मुख्य कारक टेम्पलेट है। और आप एक स्टेटफुलसेट में एक टेम्पलेट का उपयोग करके कई पॉड्स लॉन्च कर सकते हैं। और यहां मुख्य वाक्यांश "एक टेम्पलेट के लिए कई पॉड्स" है।
और पूरे क्लस्टर को एक स्टेटफुलसेट में पैक करके बनाने का बड़ा प्रलोभन था। यह काम करेगा, इसमें कोई दिक्कत नहीं है. लेकिन एक चेतावनी है. यदि हम एक विषम क्लस्टर को इकट्ठा करना चाहते हैं, यानी क्लिकहाउस के कई संस्करणों से, तो सवाल उठने लगते हैं। हां, स्टेटफुलसेट एक रोलिंग अपडेट कर सकता है, और वहां आप एक नया संस्करण रोल आउट कर सकते हैं, समझाएं कि आपको एक ही समय में इतने सारे नोड्स से अधिक प्रयास करने की आवश्यकता नहीं है।
लेकिन अगर हम कार्य का विस्तार करते हैं और कहते हैं कि हम एक पूरी तरह से विषम क्लस्टर बनाना चाहते हैं और हम रोलिंग अपडेट का उपयोग करके पुराने संस्करण से नए में बदलना नहीं चाहते हैं, लेकिन हम बस दोनों शब्दों में एक विषम क्लस्टर बनाना चाहते हैं ClickHouse के विभिन्न संस्करणों और विभिन्न भंडारण के संदर्भ में। हम चाहते हैं, उदाहरण के लिए, अलग-अलग डिस्क पर, धीमी डिस्क पर, सामान्य तौर पर, पूरी तरह से एक विषम क्लस्टर बनाने के लिए कुछ प्रतिकृतियां बनाएं। और इस तथ्य के कारण कि स्टेटफुलसेट एक टेम्पलेट से एक मानकीकृत समाधान बनाता है, ऐसा करने का कोई तरीका नहीं है।
कुछ देर सोचने के बाद यह निर्णय लिया गया कि हम इसे इसी तरह से करेंगे। हमारे पास प्रत्येक प्रतिकृति अपने स्वयं के स्टेटफुलसेट में है। इस समाधान में कुछ कमियां हैं, लेकिन व्यवहार में यह सब ऑपरेटर द्वारा पूरी तरह से समझाया गया है। और इसके बहुत सारे फायदे हैं. हम सटीक क्लस्टर बना सकते हैं जो हम चाहते हैं, उदाहरण के लिए, एक बिल्कुल विषम। इसलिए, एक क्लस्टर में जिसमें हमारे पास एक प्रतिकृति के साथ दो शार्ड हैं, हमारे पास 2 स्टेटफुलसेट और 2 पॉड होंगे क्योंकि हमने एक विषम क्लस्टर बनाने में सक्षम होने के लिए ऊपर बताए गए कारणों के लिए इस दृष्टिकोण को चुना है।
आइये व्यावहारिक समस्याओं पर लौटते हैं। हमारे क्लस्टर में हमें उपयोगकर्ताओं को कॉन्फ़िगर करने की आवश्यकता है, अर्थात। आपको Kubernetes में ClickHouse का कुछ कॉन्फ़िगरेशन करने की आवश्यकता है। ऑपरेटर इसके लिए सभी संभावनाएं प्रदान करता है।
हम जो चाहते हैं उसे सीधे YAML में लिख सकते हैं। सभी कॉन्फ़िगरेशन विकल्प सीधे इस YAML से ClickHouse कॉन्फ़िगरेशन में मैप किए जाते हैं, जिन्हें फिर पूरे क्लस्टर में वितरित किया जाता है।
आप इसे इस तरह लिख सकते हैं. यह उदाहरण के लिए है. पासवर्ड एन्क्रिप्ट किया जा सकता है. बिल्कुल सभी ClickHouse कॉन्फ़िगरेशन विकल्प समर्थित हैं। यहाँ सिर्फ एक उदाहरण है.
क्लस्टर कॉन्फ़िगरेशन को कॉन्फ़िगमैप के रूप में वितरित किया जाता है। व्यवहार में, कॉन्फिग मैप अपडेट तुरंत नहीं होता है, इसलिए यदि क्लस्टर बड़ा है, तो कॉन्फ़िगरेशन को आगे बढ़ाने की प्रक्रिया में कुछ समय लगता है। लेकिन यह सब उपयोग करने में बहुत सुविधाजनक है।
आइए कार्य को जटिल बनाएं। क्लस्टर विकसित हो रहा है. हम डेटा को दोहराना चाहते हैं. यानी, हमारे पास पहले से ही दो शार्ड हैं, प्रत्येक की एक प्रतिकृति है, और उपयोगकर्ता कॉन्फ़िगर हैं। हम बढ़ रहे हैं और प्रतिकृति बनाना चाहते हैं।
प्रतिकृति के लिए हमें क्या चाहिए?
हमें ज़ूकीपर की आवश्यकता है। ClickHouse में, ZooKeeper का उपयोग करके प्रतिकृति बनाई जाती है। ZooKeeper की आवश्यकता है ताकि विभिन्न ClickHouse प्रतिकृतियों में इस बात पर आम सहमति हो कि कौन से डेटा ब्लॉक किस ClickHouse पर हैं।
ज़ूकीपर का उपयोग कोई भी कर सकता है। यदि उद्यम के पास बाहरी ज़ूकीपर है, तो इसका उपयोग किया जा सकता है। यदि नहीं, तो आप इसे हमारे रिपॉजिटरी से इंस्टॉल कर सकते हैं। एक इंस्टॉलर है जो इस पूरी चीज़ को आसान बनाता है।
और पूरे सिस्टम का इंटरेक्शन आरेख इस प्रकार निकलता है। हमारे पास एक मंच के रूप में Kubernetes है। यह ClickHouse ऑपरेटर को निष्पादित करता है। मैंने यहां ज़ूकीपर का चित्रण किया है। और ऑपरेटर ClickHouse और ZooKeeper दोनों के साथ इंटरैक्ट करता है। अर्थात् अंतःक्रिया परिणामित होती है।
और यह सब ClickHouse के लिए k8s में डेटा को सफलतापूर्वक दोहराने के लिए आवश्यक है।
आइए अब स्वयं कार्य को देखें, प्रतिकृति के लिए मेनिफेस्ट कैसा दिखेगा।
हम अपने मेनिफेस्ट में दो अनुभाग जोड़ रहे हैं। पहला यह है कि ज़ूकीपर कहाँ से प्राप्त करें, जो या तो कुबेरनेट्स के अंदर या बाहरी हो सकता है। ये तो सिर्फ एक विवरण है. और हम प्रतिकृतियां ऑर्डर करते हैं। वे। हम दो प्रतिकृतियां चाहते हैं. कुल मिलाकर, हमारे पास आउटपुट पर 4 पॉड होने चाहिए। हमें भंडारण के बारे में याद है, यह थोड़ी देर बाद वापस आएगा। भंडारण एक अलग कहानी है.
यह इस प्रकार था.
ऐसा हो जाता है. प्रतिकृतियाँ जोड़ी जाती हैं. चौथा फिट नहीं हुआ, हमारा मानना है कि वहाँ उनमें से कई हो सकते हैं। और ज़ूकीपर को साइड में जोड़ दिया गया है। योजनाएँ अधिक जटिल होती जा रही हैं।
और अगला कार्य जोड़ने का समय आ गया है। हम पर्सिस्टेंट स्टोरेज जोड़ देंगे।
पर्सिस्टेंट स्टोरेज के लिए हमारे पास विभिन्न विकल्प हैं।
यदि हम क्लाउड प्रदाता में काम कर रहे हैं, उदाहरण के लिए, अमेज़ॅन, Google का उपयोग कर रहे हैं, तो क्लाउड स्टोरेज का उपयोग करने का एक बड़ा प्रलोभन है। यह बहुत सुविधाजनक है, यह अच्छा है.
और दूसरा विकल्प भी है. यह स्थानीय भंडारण के लिए है, जब हमारे पास प्रत्येक नोड पर स्थानीय डिस्क होती है। इस विकल्प को लागू करना कहीं अधिक कठिन है, लेकिन साथ ही यह अधिक उत्पादक भी है।
आइए देखें कि क्लाउड स्टोरेज के संबंध में हमारे पास क्या है।
फायदे हैं. इसे कॉन्फ़िगर करना बहुत आसान है. हम तो बस क्लाउड प्रोवाइडर से ऑर्डर करते हैं कि कृपया हमें फलां क्षमता का, अमुक श्रेणी का स्टोरेज दीजिए। कक्षाएँ प्रदाताओं द्वारा स्वतंत्र रूप से निर्धारित की जाती हैं।
और एक कमी है. कुछ लोगों के लिए, यह एक गैर-महत्वपूर्ण कमी है। बेशक, कुछ प्रदर्शन संबंधी समस्याएं होंगी। इसका उपयोग करना बहुत सुविधाजनक और विश्वसनीय है, लेकिन इसमें कुछ संभावित प्रदर्शन कमियां हैं।
और क्योंकि ClickHouse विशेष रूप से उत्पादकता पर ध्यान केंद्रित करता है, कोई यह भी कह सकता है कि यह वह सब कुछ निचोड़ लेता है जो वह कर सकता है, यही कारण है कि कई ग्राहक अधिकतम उत्पादकता निचोड़ने का प्रयास करते हैं।
और इसका अधिकतम लाभ उठाने के लिए, हमें स्थानीय भंडारण की आवश्यकता है।
कुबेरनेट्स कुबेरनेट्स में स्थानीय भंडारण का उपयोग करने के लिए तीन सार प्रदान करता है। यह:
- खालीदिर
- होस्टपाथ.
- स्थानीय
आइए देखें कि वे कैसे भिन्न हैं और वे कैसे समान हैं।
सबसे पहले, तीनों दृष्टिकोणों में हमारे पास भंडारण है - ये स्थानीय डिस्क हैं जो समान भौतिक k8s नोड पर स्थित हैं। लेकिन उनमें कुछ अंतर हैं.
आइए सबसे सरल से शुरू करें, यानी खालीडिर। व्यवहार में यह क्या है? हमारे विनिर्देश में, हम कंटेनरीकरण प्रणाली (अक्सर डॉकर) से हमें स्थानीय डिस्क पर एक फ़ोल्डर तक पहुंच प्रदान करने के लिए कहते हैं।
व्यवहार में, डॉकर अपने पथ के साथ कहीं एक अस्थायी फ़ोल्डर बनाता है और इसे एक लंबा हैश कहता है। और इसे एक्सेस करने के लिए एक इंटरफ़ेस प्रदान करता है।
यह प्रदर्शन-वार कैसे काम करेगा? यह स्थानीय डिस्क गति पर काम करेगा, अर्थात। यह आपके स्क्रू तक पूर्ण पहुंच है।
लेकिन इस मामले की अपनी खामी है. परसिस्टेंट इस मामले में काफी संदिग्ध है. पहली बार जब डॉकर कंटेनरों के साथ चलता है, तो पर्सिस्टेंट खो जाता है। यदि कुबेरनेट्स किसी कारण से इस पॉड को किसी अन्य डिस्क पर ले जाना चाहता है, तो डेटा खो जाएगा।
यह दृष्टिकोण परीक्षणों के लिए अच्छा है, क्योंकि यह पहले से ही सामान्य गति दिखाता है, लेकिन किसी गंभीर चीज़ के लिए यह विकल्प उपयुक्त नहीं है।
इसलिए एक दूसरा दृष्टिकोण है. यह होस्टपाथ है. यदि आप पिछली स्लाइड और इस स्लाइड को देखें तो आपको केवल एक ही अंतर दिखाई देगा। हमारा फ़ोल्डर डॉकर से सीधे कुबेरनेट्स नोड में चला गया। यहां यह थोड़ा आसान है. हम सीधे स्थानीय फ़ाइल सिस्टम पर पथ निर्दिष्ट करते हैं जहाँ हम अपना डेटा संग्रहीत करना चाहते हैं।
इस विधि के फायदे हैं. यह पहले से ही एक वास्तविक पर्सिस्टेंट है, और उस पर एक क्लासिक भी है। हमारे पास किसी पते पर डिस्क पर रिकॉर्ड किया गया डेटा होगा।
इसके नुकसान भी हैं. यह प्रबंधन की जटिलता है. हमारे कुबेरनेट्स पॉड को किसी अन्य भौतिक नोड पर ले जाना चाह सकते हैं। और यहीं पर DevOps काम आता है। उसे पूरे सिस्टम को सही ढंग से समझाना होगा कि इन पॉड्स को केवल उन्हीं नोड्स पर ले जाया जा सकता है, जिन पर इन रास्तों पर कुछ लगा हुआ है, और एक समय में एक से अधिक नोड नहीं। यह काफी कठिन है.
विशेष रूप से इन उद्देश्यों के लिए, हमने इस सारी जटिलता को छिपाने के लिए अपने ऑपरेटर में टेम्पलेट बनाए। और आप बस इतना कह सकते हैं: "मैं प्रत्येक भौतिक नोड के लिए और ऐसे और ऐसे पथ पर ClickHouse का एक उदाहरण चाहता हूं।"
लेकिन हम अकेले नहीं हैं जिन्हें इस आवश्यकता की आवश्यकता है, इसलिए स्वयं कुबेरनेट्स के सज्जन भी समझते हैं कि लोग भौतिक डिस्क तक पहुंच चाहते हैं, इसलिए वे एक तीसरी परत प्रदान करते हैं।
इसे स्थानीय कहा जाता है. पिछली स्लाइड से व्यावहारिक रूप से कोई अंतर नहीं है। केवल पहले यह मैन्युअल रूप से पुष्टि करना आवश्यक था कि हम इन पॉड्स को एक नोड से दूसरे नोड में स्थानांतरित नहीं कर सकते हैं, क्योंकि उन्हें किसी पथ के साथ स्थानीय भौतिक डिस्क से जोड़ा जाना चाहिए, लेकिन अब यह सारा ज्ञान कुबेरनेट्स में ही समाहित है। और इसे कॉन्फ़िगर करना बहुत आसान हो गया है।
आइये अपनी व्यावहारिक समस्या पर वापस आते हैं। आइए YAML टेम्पलेट पर वापस लौटें। यहां हमारे पास वास्तविक भंडारण है। हम इस पर वापस आ गए हैं। हमने क्लासिक वॉल्यूमक्लेम टेम्पलेट को k8s में सेट किया है। और हम वर्णन करते हैं कि हमें किस प्रकार का भंडारण चाहिए।
इसके बाद, k8s स्टोरेज का अनुरोध करेगा। इसे हमें स्टेटफुलसेट में आवंटित किया जाएगा। और अंत में यह ClickHouse के निपटान में होगा।
हमारे पास यह योजना थी. हमारा पर्सिस्टेंट स्टोरेज लाल था, जो यह संकेत दे रहा था कि इसे करने की जरूरत है।
और वह हरा हो जाता है. अब k8s क्लस्टर योजना पर ClickHouse को पूरी तरह से अंतिम रूप दे दिया गया है। हमारे पास शार्क, प्रतिकृतियां, ज़ूकीपर हैं, हमारे पास एक वास्तविक पर्सिस्टेंट है, जिसे एक या दूसरे तरीके से लागू किया जाता है। यह योजना पहले से ही पूरी तरह से चालू है।
हम जीना जारी रखते हैं। हमारा क्लस्टर विकसित हो रहा है। और एलेक्सी कोशिश करता है, और ClickHouse का एक नया संस्करण जारी करता है।
एक व्यावहारिक कार्य उठता है - हमारे क्लस्टर पर ClickHouse के नए संस्करण का परीक्षण करना। और, स्वाभाविक रूप से, आप इसे पूरी तरह से रोल आउट नहीं करना चाहते हैं; आप कहीं दूर कोने में एक प्रतिकृति में एक नया संस्करण रखना चाहते हैं, और शायद एक नया संस्करण नहीं, बल्कि एक ही बार में दो, क्योंकि वे अक्सर सामने आते हैं।
इस बारे में हम क्या कह सकते हैं?
यहां हमारे पास ऐसा ही एक अवसर है। ये पॉड टेम्पलेट हैं. आप लिख सकते हैं कि हमारा ऑपरेटर आपको एक विषम क्लस्टर बनाने की पूरी तरह से अनुमति देता है। वे। कॉन्फ़िगर करें, एक समूह में सभी प्रतिकृतियों से शुरू करके, प्रत्येक व्यक्तिगत प्रतिकृति के साथ समाप्त करते हुए, हम कौन सा संस्करण चाहते हैं ClickHouse, कौन सा संस्करण हम भंडारण चाहते हैं। हम क्लस्टर को उस कॉन्फ़िगरेशन के साथ पूरी तरह से कॉन्फ़िगर कर सकते हैं जिसकी हमें आवश्यकता है।
आइए थोड़ा और अंदर चलें। इससे पहले, हमने इस बारे में बात की थी कि ClickHouse-ऑपरेटर ClickHouse की विशिष्टताओं के संबंध में कैसे काम करता है।
अब मैं इस बारे में कुछ शब्द कहना चाहूंगा कि कोई भी ऑपरेटर सामान्य रूप से कैसे काम करता है, साथ ही यह K8s के साथ कैसे इंटरैक्ट करता है।
आइए पहले K8s के साथ बातचीत पर नजर डालें। जब हम kubectl लागू करते हैं तो क्या होता है? हमारी वस्तुएं एपीआई के माध्यम से आदि में दिखाई देती हैं।
उदाहरण के लिए, मूल कुबेरनेट्स ऑब्जेक्ट: पॉड, स्टेटफुलसेट, सर्विस, इत्यादि सूची के नीचे।
वहीं, अभी तक कुछ भी भौतिक नहीं हुआ है। इन वस्तुओं को क्लस्टर में मूर्त रूप दिया जाना चाहिए।
इस प्रयोजन के लिए, एक नियंत्रक प्रकट होता है. नियंत्रक एक विशेष k8s घटक है जो इन विवरणों को मूर्त रूप दे सकता है। वह जानता है कि शारीरिक रूप से कैसे और क्या करना है। वह जानता है कि कंटेनरों को कैसे चलाना है, सर्वर को काम करने के लिए वहां क्या कॉन्फ़िगर करना होगा।
और यह हमारी वस्तुओं को K8s में मूर्त रूप देता है।
लेकिन हम न केवल पॉड्स और स्टेटफुलसेट्स के साथ काम करना चाहते हैं, हम एक ClickHouseInstallation बनाना चाहते हैं, यानी ClickHouse प्रकार का एक ऑब्जेक्ट, ताकि इसे एक पूरे के रूप में संचालित किया जा सके। अभी तक ऐसी कोई संभावना नहीं है.
लेकिन K8s में निम्नलिखित अच्छी चीज़ है। हम चाहते हैं कि हमारे पास ऐसी कोई जटिल इकाई हो जिसमें हमारा क्लस्टर पॉड्स और स्टेटफुलसेट से इकट्ठा किया जाएगा।
और इसके लिए क्या करना होगा? सबसे पहले, कस्टम संसाधन परिभाषा चित्र में आती है। यह क्या है? यह K8s के लिए एक विवरण है, कि आपके पास एक और डेटा प्रकार होगा, कि हम पॉड, स्टेटफुलसेट में एक कस्टम संसाधन जोड़ना चाहते हैं, जो अंदर से जटिल होगा। यह डेटा संरचना का विवरण है.
हम इसे kubectl apply के माध्यम से भी वहां भेजते हैं। कुबेरनेट्स ने ख़ुशी से इसे ले लिया।
और अब हमारे भंडारण में, आदि में ऑब्जेक्ट के पास ClickHouseInstallation नामक एक कस्टम संसाधन रिकॉर्ड करने का अवसर है।
लेकिन फिलहाल आगे कुछ नहीं होगा. अर्थात्, यदि अब हम YAML फ़ाइल बनाते हैं जिसे हमने शार्ड और प्रतिकृतियों का वर्णन करते हुए देखा था और कहते हैं "कुबेक्टल अप्लाई", तो कुबेरनेट्स इसे स्वीकार कर लेंगे, इसे आदि में डाल देंगे और कहेंगे: "बहुत बढ़िया, लेकिन मुझे नहीं पता कि क्या करना है इसके साथ। मुझे नहीं पता कि ClickHouseInstallation को कैसे बनाए रखा जाए।"
तदनुसार, हमें कुबेरनेट्स को नए डेटा प्रकार की सेवा में मदद करने के लिए किसी की आवश्यकता है। बाईं ओर हमारे पास एक देशी कुबेरनेट्स नियंत्रक है जो देशी डेटा प्रकारों के साथ काम करता है। और दाईं ओर हमारे पास एक कस्टम नियंत्रक होना चाहिए जो कस्टम डेटा प्रकारों के साथ काम कर सके।
और दूसरे तरीके से इसे ऑपरेटर कहा जाता है. मैंने इसे विशेष रूप से यहां कुबेरनेट्स के रूप में शामिल किया है, क्योंकि इसे K8s के बाहर भी निष्पादित किया जा सकता है। अक्सर, निश्चित रूप से, सभी ऑपरेटरों को कुबेरनेट्स में निष्पादित किया जाता है, लेकिन कुछ भी इसे बाहर खड़े होने से नहीं रोकता है, इसलिए यहां इसे विशेष रूप से बाहर ले जाया गया है।
और बदले में, कस्टम नियंत्रक, जिसे ऑपरेटर के रूप में भी जाना जाता है, एपीआई के माध्यम से कुबेरनेट्स के साथ इंटरैक्ट करता है। यह पहले से ही जानता है कि एपीआई के साथ कैसे इंटरैक्ट करना है। और वह पहले से ही जानता है कि उस जटिल सर्किट को कैसे मूर्त रूप दिया जाए जिसे हम एक कस्टम संसाधन से बनाना चाहते हैं। यह बिल्कुल वही है जो ऑपरेटर करता है।
ऑपरेटर कैसे काम करता है? आइए दाहिनी ओर देखें कि वह यह कैसे करता है। आइए जानें कि ऑपरेटर यह सब कैसे करता है और K8s के साथ आगे की बातचीत कैसे होती है।
ऑपरेटर एक प्रोग्राम है. वह घटना-उन्मुख है। ऑपरेटर Kubernetes API का उपयोग करके ईवेंट की सदस्यता लेता है। कुबेरनेट्स एपीआई में प्रवेश बिंदु हैं जहां आप घटनाओं की सदस्यता ले सकते हैं। और यदि K8s में कुछ परिवर्तन होता है, तो कुबेरनेट्स सभी को ईवेंट भेजता है, अर्थात। जिसने भी इस एपीआई पॉइंट की सदस्यता ली है उसे सूचनाएं प्राप्त होंगी।
ऑपरेटर घटनाओं की सदस्यता लेता है और उसे किसी प्रकार की प्रतिक्रिया देनी होती है। इसका काम उभरती घटनाओं पर प्रतिक्रिया देना है.
इवेंट कुछ अद्यतनों द्वारा उत्पन्न होते हैं। ClickHouseInstallation के विवरण के साथ हमारी YAML फ़ाइल आती है। वह kubectl apply के माध्यम से आदि में गया। वहां एक इवेंट शुरू हुआ, और परिणामस्वरूप यह इवेंट ClickHouse-ऑपरेटर के पास आया। ऑपरेटर को यह विवरण प्राप्त हुआ. और उसे कुछ करना ही होगा. यदि ClickHouseInstallation ऑब्जेक्ट के लिए कोई अपडेट आया है, तो आपको क्लस्टर को अपडेट करने की आवश्यकता है। और ऑपरेटर का कार्य क्लस्टर को अपडेट करना है।
वह क्या कर रहा है? सबसे पहले, हमें इस अद्यतन के साथ क्या करना है इसके लिए एक कार्य योजना तैयार करनी होगी। अपडेट बहुत छोटे हो सकते हैं, यानी. YAML निष्पादन में छोटा, लेकिन क्लस्टर पर बहुत बड़े परिवर्तन ला सकता है। इसलिए, ऑपरेटर एक योजना बनाता है, और फिर वह उस पर कायम रहता है।
इस योजना के अनुसार, वह फली, सेवाओं, यानी को मूर्त रूप देने के लिए इस संरचना को अंदर से पकाना शुरू कर देता है। वही करो जो उसका मुख्य कार्य है। कुबेरनेट्स में क्लिकहाउस क्लस्टर बनाने का तरीका इस प्रकार है।
अब आइए ऐसी ही एक दिलचस्प बात पर बात करते हैं। यह कुबेरनेट्स और ऑपरेटर के बीच जिम्मेदारी का विभाजन है, अर्थात। कुबेरनेट्स क्या करता है, ऑपरेटर क्या करता है, और वे एक दूसरे के साथ कैसे बातचीत करते हैं।
कुबेरनेट्स सिस्टम चीजों के लिए जिम्मेदार है, अर्थात। वस्तुओं के एक मूल सेट के लिए जिसे सिस्टम-स्कोप के रूप में व्याख्या किया जा सकता है। कुबेरनेट्स जानता है कि पॉड्स को कैसे लॉन्च किया जाए, कंटेनरों को कैसे पुनरारंभ किया जाए, वॉल्यूम कैसे बढ़ाया जाए, कॉन्फिग मैप के साथ कैसे काम किया जाए, यानी। वह सब कुछ जिसे एक प्रणाली कहा जा सकता है।
ऑपरेटर डोमेन में कार्य करते हैं. प्रत्येक ऑपरेटर अपने स्वयं के विषय क्षेत्र के लिए बना है। हमने इसे ClickHouse के लिए किया।
और ऑपरेटर विषय क्षेत्र के संदर्भ में सटीक रूप से बातचीत करता है, जैसे प्रतिकृति जोड़ना, आरेख बनाना, निगरानी स्थापित करना। इसका परिणाम विभाजन होता है।
आइए एक व्यावहारिक उदाहरण देखें कि जब हम ऐड रेप्लिका कार्रवाई करते हैं तो जिम्मेदारी का यह विभाजन कैसे होता है।
ऑपरेटर को एक कार्य प्राप्त होता है - एक प्रतिकृति जोड़ने के लिए। ऑपरेटर क्या करता है? ऑपरेटर गणना करेगा कि एक नया स्टेटफुलसेट बनाने की आवश्यकता है, जिसमें ऐसे और ऐसे टेम्पलेट, वॉल्यूम दावे का वर्णन किया जाना चाहिए।
उसने यह सब तैयार किया और इसे K8s को भेज दिया। उनका कहना है कि उन्हें कॉन्फिगमैप, स्टेटफुलसेट, वॉल्यूम की जरूरत है। कुबेरनेट्स काम कर रहा है। वह उन बुनियादी इकाइयों को मूर्त रूप देता है जिनके साथ वह काम करता है।
और फिर ClickHouse-ऑपरेटर फिर से काम में आता है। उसके पास पहले से ही एक भौतिक पॉड है जिस पर वह पहले से ही कुछ कर सकता है। और ClickHouse-ऑपरेटर फिर से डोमेन शर्तों में काम करता है। वे। विशेष रूप से ClickHouse, एक क्लस्टर में एक प्रतिकृति शामिल करने के लिए, आपको सबसे पहले, इस क्लस्टर में मौजूद डेटा स्कीमा को कॉन्फ़िगर करना होगा। और, दूसरी बात, इस प्रतिकृति को निगरानी में शामिल किया जाना चाहिए ताकि इसका स्पष्ट रूप से पता लगाया जा सके। ऑपरेटर इसे पहले से ही कॉन्फ़िगर करता है.
और उसके बाद ही ClickHouse स्वयं खेल में आता है, अर्थात। एक अन्य उच्च स्तरीय इकाई। यह पहले से ही एक डेटाबेस है. इसका अपना उदाहरण है, एक और कॉन्फ़िगर की गई प्रतिकृति जो क्लस्टर में शामिल होने के लिए तैयार है।
यह पता चला है कि प्रतिकृति जोड़ते समय निष्पादन और जिम्मेदारी के विभाजन की श्रृंखला काफी लंबी है।
हम अपने व्यावहारिक कार्य जारी रखते हैं। यदि आपके पास पहले से ही क्लस्टर है, तो आप कॉन्फ़िगरेशन को माइग्रेट कर सकते हैं।
हमने इसे इसलिए बनाया है ताकि आप सीधे मौजूदा xml में पेस्ट कर सकें, जिसे ClickHouse समझता है।
आप ClickHouse को फाइन-ट्यून कर सकते हैं। होस्टपाथ, स्थानीय भंडारण की व्याख्या करते समय मैंने बस ज़ोन परिनियोजन के बारे में बात की थी। ज़ोन परिनियोजन को सही ढंग से करने का तरीका इस प्रकार है।
अगला व्यावहारिक कार्य निगरानी करना है।
यदि हमारा क्लस्टर बदलता है, तो हमें समय-समय पर मॉनिटरिंग कॉन्फ़िगर करने की आवश्यकता होती है।
आइए आरेख देखें. हम पहले ही यहां हरे तीरों को देख चुके हैं। अब आइए लाल तीरों को देखें। इस प्रकार हम अपने क्लस्टर की निगरानी करना चाहते हैं। ClickHouse क्लस्टर से मेट्रिक्स प्रोमेथियस और फिर ग्राफाना में कैसे आते हैं।
निगरानी में क्या कठिनाई है? इसे किसी प्रकार की उपलब्धि के रूप में क्यों प्रस्तुत किया जाता है? कठिनाई गतिशीलता में है. जब हमारे पास एक क्लस्टर होता है और यह स्थिर होता है, तो हम एक बार निगरानी स्थापित कर सकते हैं और अब परेशान नहीं होंगे।
लेकिन अगर हमारे पास बहुत सारे क्लस्टर हैं, या कुछ लगातार बदल रहा है, तो प्रक्रिया गतिशील है। और लगातार निगरानी को पुन: कॉन्फ़िगर करना संसाधनों और समय की बर्बादी है, यानी। यहां तक कि सिर्फ आलस्य भी. इसे स्वचालित करने की आवश्यकता है. कठिनाई प्रक्रिया की गतिशीलता में है। और ऑपरेटर इसे बहुत अच्छी तरह से स्वचालित करता है।
हमारा क्लस्टर कैसे विकसित हुआ? शुरुआत में वह ऐसे ही थे.
तब वह ऐसे थे.
अन्त में वह ऐसा हो गया।
और मॉनिटरिंग ऑपरेटर द्वारा स्वचालित रूप से की जाती है। प्रवेश का एकल बिंदु.
और बाहर निकलते ही हम ग्राफाना डैशबोर्ड को देखते हैं कि हमारे क्लस्टर का जीवन अंदर कैसे उबल रहा है।
वैसे, ग्राफाना डैशबोर्ड भी हमारे ऑपरेटर के साथ सीधे स्रोत कोड में वितरित किया जाता है। आप कनेक्ट कर उपयोग कर सकते हैं. हमारे DevOps ने मुझे यह स्क्रीनशॉट दिया।
हम आगे कहाँ जाना चाहेंगे? यह:
- परीक्षण स्वचालन विकसित करें. मुख्य कार्य नए संस्करणों का स्वचालित परीक्षण है।
- हम वास्तव में ज़ूकीपर के साथ एकीकरण को स्वचालित करना चाहते हैं। और ज़ूकीपर-ऑपरेटर के साथ एकीकृत करने की योजना है। वे। ज़ूकीपर के लिए एक ऑपरेटर लिखा गया है और यह तर्कसंगत है कि दोनों ऑपरेटर अधिक सुविधाजनक समाधान बनाने के लिए एकीकृत होना शुरू करें।
- हम और अधिक जटिल महत्वपूर्ण संकेत करना चाहते हैं।
- मैंने हरे रंग में हाइलाइट किया कि हम टेम्प्लेट्स के इनहेरिटेंस के करीब पहुंच रहे हैं - हो गया, यानी ऑपरेटर की अगली रिलीज के साथ हमारे पास पहले से ही टेम्प्लेट्स का इनहेरिटेंस होगा। यह एक शक्तिशाली उपकरण है जो आपको टुकड़ों से जटिल कॉन्फ़िगरेशन बनाने की अनुमति देता है।
- और हम जटिल कार्यों का स्वचालन चाहते हैं। इनमें से मुख्य है री-शेयरिंग।
चलिए कुछ मध्यवर्ती परिणाम लेते हैं।
परिणामस्वरूप हमें क्या मिलता है? और क्या यह करने लायक है या नहीं? क्या डेटाबेस को कुबेरनेट्स में खींचने का प्रयास करना और सामान्य रूप से ऑपरेटर और विशेष रूप से एलिटनिटी ऑपरेटर का उपयोग करना आवश्यक है?
आउटपुट पर हमें मिलता है:
- कॉन्फ़िगरेशन, परिनियोजन और रखरखाव का महत्वपूर्ण सरलीकरण और स्वचालन।
- तुरंत अंतर्निहित निगरानी।
- और जटिल स्थितियों के लिए उपयोग के लिए तैयार संहिताबद्ध टेम्पलेट। प्रतिकृति जोड़ने जैसी क्रिया को मैन्युअल रूप से करने की आवश्यकता नहीं है। ऑपरेटर ऐसा करता है.
बस एक आखिरी सवाल बचा है. हमारे पास कुबेरनेट्स, वर्चुअलाइजेशन में पहले से ही एक डेटाबेस है। ऐसे समाधान के प्रदर्शन के बारे में क्या ख़याल है, खासकर जब से ClickHouse को प्रदर्शन के लिए अनुकूलित किया गया है?
उत्तर है सब कुछ ठीक है! मैं विस्तार में नहीं जाऊंगा, यह एक अलग रिपोर्ट का विषय है.
लेकिन टीएसबीएस जैसी एक परियोजना है। इसका मुख्य कार्य क्या है? यह एक डेटाबेस प्रदर्शन परीक्षण है. यह गर्म को गर्म से, नरम को नरम से तुलना करने का एक प्रयास है।
वह कैसे काम करता है? एक डेटा सेट तैयार किया जाता है. फिर डेटा के इस सेट को परीक्षणों के एक ही सेट का उपयोग करके विभिन्न डेटाबेस पर चलाया जाता है। और प्रत्येक डेटाबेस एक समस्या को अपने तरीके से हल करता है। और फिर आप परिणामों की तुलना कर सकते हैं.
यह पहले से ही डेटाबेस के एक बड़े समूह का समर्थन करता है। मैंने तीन मुख्य की पहचान की है। यह:
- टाइमस्केलडीबी।
- इन्फ्लक्सडीबी.
- क्लिकहाउस.
एक अन्य समान समाधान के साथ तुलना भी की गई थी। रेडशिफ्ट के साथ तुलना। तुलना अमेज़न पर की गई थी। ClickHouse भी इस मामले में सभी से काफी आगे है।
मैंने जो कहा उससे क्या निष्कर्ष निकाला जा सकता है?
- कुबेरनेट्स में डीबी संभव है। संभवतः कोई भी संभव है, लेकिन कुल मिलाकर ऐसा लगता है कि यह संभव है। Kubernetes में ClickHouse हमारे ऑपरेटर की मदद से निश्चित रूप से संभव है।
- ऑपरेटर प्रक्रियाओं को स्वचालित करने में मदद करता है और वास्तव में जीवन को आसान बनाता है।
- प्रदर्शन सामान्य है.
- और हमें ऐसा लगता है कि इसका उपयोग किया जा सकता है और किया भी जाना चाहिए।
खुला स्रोत - हमसे जुड़ें!
जैसा कि मैंने पहले ही कहा, ऑपरेटर पूरी तरह से ओपन सोर्स उत्पाद है, इसलिए यह बहुत अच्छा होगा यदि अधिकतम संख्या में लोग इसका उपयोग करें। हमसे जुड़ें! हम आप सभी का इंतजार कर रहे हैं!
आप सभी को धन्यवाद!
सवाल
रिपोर्ट के लिए धन्यवाद! मेरा नाम एंटोन है. मैं SEMrush से हूँ. मैं सोच रहा हूं कि लॉगिंग में क्या हो रहा है। अगर हम पूरे क्लस्टर के बारे में बात करें तो हम निगरानी के बारे में सुनते हैं, लेकिन लॉगिंग के बारे में कुछ नहीं सुनते। उदाहरण के लिए, हमने हार्डवेयर पर एक क्लस्टर तैयार किया है। और हम मानकीकृत लॉगिंग का उपयोग करते हैं, मानक साधनों का उपयोग करके उन्हें एक सामान्य ढेर में एकत्रित करते हैं। और फिर वहां से हमें वह डेटा मिलता है जिसमें हमारी रुचि होती है।
अच्छा प्रश्न है, यानी कार्य सूची में लॉग इन करना। हमारा ऑपरेटर अभी तक इसे स्वचालित नहीं करता है। यह अभी भी विकसित हो रहा है, परियोजना अभी भी काफी नई है। हम लॉगिंग की आवश्यकता को समझते हैं. यह भी एक बहुत ही महत्वपूर्ण विषय है. और यह शायद निगरानी से कम महत्वपूर्ण नहीं है. लेकिन कार्यान्वयन की सूची में सबसे पहले निगरानी थी। लॉगिंग होगी. स्वाभाविक रूप से, हम क्लस्टर के जीवन के सभी पहलुओं को स्वचालित करने का प्रयास करते हैं। इसलिए, उत्तर यह है कि फिलहाल ऑपरेटर, दुर्भाग्य से, यह नहीं जानता कि यह कैसे करना है, लेकिन यह योजनाओं में है, हम इसे करेंगे। यदि आप शामिल होना चाहते हैं, तो कृपया अनुरोध खींचें।
नमस्ते! रिपोर्ट के लिए धन्यवाद! मेरे पास परसिस्टेंट वॉल्यूम से संबंधित एक मानक प्रश्न है। जब हम इस ऑपरेटर के साथ एक कॉन्फ़िगरेशन बनाते हैं, तो ऑपरेटर यह कैसे निर्धारित करता है कि हमारे पास किस नोड पर एक विशेष डिस्क या फ़ोल्डर जुड़ा हुआ है? हमें पहले उसे समझाना होगा कि कृपया हमारे ClickHouse को इन नोड्स पर रखें जिनमें डिस्क है?
जहां तक मैं समझता हूं, यह प्रश्न स्थानीय भंडारण, विशेष रूप से इसके होस्टपाथ भाग की निरंतरता है। यह पूरे सिस्टम को यह समझाने जैसा है कि पॉड को ऐसे और ऐसे नोड पर लॉन्च करने की आवश्यकता है, जिससे हमारे पास एक भौतिक रूप से जुड़ी हुई डिस्क है, जो कि ऐसे और ऐसे पथ पर लगी हुई है। यह एक संपूर्ण खंड है जिसे मैंने बहुत सतही रूप से छुआ है क्योंकि इसका उत्तर काफी बड़ा है।
संक्षेप में यह इस प्रकार दिखता है. स्वाभाविक रूप से, हमें इन संस्करणों का प्रावधान करने की आवश्यकता है। फिलहाल, स्थानीय भंडारण में कोई गतिशील प्रावधान नहीं है, इसलिए DevOps को इन वॉल्यूम को स्वयं डिस्क में काटना होगा। और उन्हें कुबेरनेट्स प्रावधान को समझाना होगा कि आपके पास ऐसे और ऐसे वर्ग के लगातार वॉल्यूम होंगे, जो ऐसे और ऐसे नोड्स पर स्थित हैं। फिर आपको कुबेरनेट्स को यह समझाने की आवश्यकता होगी कि जिन पॉड्स को ऐसे और ऐसे स्थानीय भंडारण वर्ग की आवश्यकता होती है, उन्हें लेबल का उपयोग करके केवल ऐसे और ऐसे नोड्स पर निर्देशित करने की आवश्यकता होती है। इन उद्देश्यों के लिए, ऑपरेटर के पास किसी प्रकार का लेबल और प्रति होस्ट इंस्टेंस एक निर्दिष्ट करने की क्षमता होती है। और यह पता चला है कि पॉड्स को कुबेरनेट्स द्वारा केवल उन नोड्स पर चलाने के लिए रूट किया जाएगा जो सरल शब्दों में आवश्यकताओं, लेबलों को पूरा करते हैं। प्रशासक मैन्युअल रूप से लेबल और प्रावधान डिस्क आवंटित करते हैं। और फिर यह स्केल हो जाता है।
और यह तीसरा विकल्प है, स्थानीय, जो इसे थोड़ा आसान बनाने में मदद करता है। जैसा कि मैंने पहले ही जोर दिया है, यह ट्यूनिंग पर श्रमसाध्य काम है, जो अंततः अधिकतम प्रदर्शन प्राप्त करने में मदद करता है।
मेरा इससे जुड़ा दूसरा प्रश्न है. कुबेरनेट्स को इस तरह से डिज़ाइन किया गया था कि इससे हमें कोई फर्क नहीं पड़ता कि हम एक नोड खोते हैं या नहीं। इस मामले में हमें क्या करना चाहिए यदि हमने वह नोड खो दिया है जहां हमारा टुकड़ा लटका हुआ है?
हां, कुबेरनेट्स की शुरुआत में यह धारणा थी कि हमारे पॉड्स के साथ हमारा रिश्ता मवेशियों की तरह है, लेकिन यहां हमारे साथ प्रत्येक डिस्क एक पालतू जानवर की तरह बन जाती है। कुछ ऐसी समस्या है कि हम उन्हें यूं ही फेंक नहीं सकते. और कुबेरनेट्स का विकास इस दिशा में आगे बढ़ रहा है कि इसे पूरी तरह से दार्शनिक रूप से व्यवहार करना असंभव है, जैसे कि यह पूरी तरह से त्याग दिया गया संसाधन हो।
अब एक व्यावहारिक प्रश्न के लिए. यदि आपने वह नोड खो दिया है जिस पर डिस्क थी तो क्या करें? यहां समस्या का समाधान उच्च स्तर पर किया जा रहा है. ClickHouse के मामले में, हमारे पास ऐसी प्रतिकृतियाँ हैं जो उच्च स्तर पर काम करती हैं, अर्थात। क्लिकहाउस स्तर पर।
परिणामी स्वभाव क्या है? DevOps यह सुनिश्चित करने के लिए ज़िम्मेदार है कि डेटा नष्ट न हो। उसे प्रतिकृति सही ढंग से सेट करनी होगी और यह सुनिश्चित करना होगा कि प्रतिकृति चल रही है। ClickHouse स्तर पर प्रतिकृति में डुप्लिकेट डेटा होना चाहिए। यह वह समस्या नहीं है जिसे ऑपरेटर हल करता है। और वह समस्या नहीं जिसे कुबेरनेट्स स्वयं हल करता है। यह ClickHouse स्तर पर है.
यदि आपका लोहे का नोड गिर जाए तो क्या करें? और यह पता चला है कि आपको एक दूसरा स्थापित करने, उस पर डिस्क को उचित रूप से व्यवस्थित करने और लेबल लगाने की आवश्यकता होगी। और उसके बाद, यह उन आवश्यकताओं को पूरा करेगा कि कुबेरनेट्स इस पर एक इंस्टेंस पॉड लॉन्च कर सकता है। कुबेरनेट्स इसे लॉन्च करेगा। आपके पॉड्स की संख्या निर्दिष्ट संख्या को पूरा करने के लिए पर्याप्त नहीं है। यह उस चक्र से गुज़रेगा जो मैंने दिखाया था। और उच्चतम स्तर पर, ClickHouse समझ जाएगा कि हमने एक प्रतिकृति दर्ज की है, यह अभी भी खाली है और हमें इसमें डेटा स्थानांतरित करना शुरू करने की आवश्यकता है। वे। यह प्रक्रिया अभी भी अच्छी तरह से स्वचालित नहीं है.
रिपोर्ट के लिए धन्यवाद! जब सभी प्रकार की ख़राब चीज़ें होती हैं, तो ऑपरेटर क्रैश हो जाता है और पुनरारंभ हो जाता है, और उसी क्षण घटनाएँ आ जाती हैं, क्या आप किसी तरह इसे संभालते हैं?
यदि ऑपरेटर क्रैश हो जाए और फिर से चालू हो जाए तो क्या होगा?
हाँ। और उसी क्षण घटनाएँ आ गईं।
इस मामले में क्या करना है इसका कार्य आंशिक रूप से ऑपरेटर और कुबेरनेट्स के बीच साझा किया जाता है। कुबेरनेट्स में घटित घटना को दोबारा चलाने की क्षमता है। वह दोबारा खेलता है। और ऑपरेटर का कार्य यह सुनिश्चित करना है कि जब ईवेंट लॉग उस पर दोबारा चलाया जाए, तो ये ईवेंट निष्क्रिय हों। और ताकि एक ही घटना के बार-बार घटित होने से हमारा सिस्टम न टूटे। और हमारा ऑपरेटर इस कार्य का सामना करता है।
नमस्ते! रिपोर्ट के लिए धन्यवाद! दिमित्री ज़ाव्यालोव, कंपनी समेडोवा। क्या ऑपरेटर में हैप्रोक्सी के साथ कॉन्फ़िगर करने की क्षमता जोड़ने की योजना है? मुझे मानक बैलेंसर के अलावा किसी अन्य बैलेंसर में दिलचस्पी होगी, ताकि यह स्मार्ट हो और समझ सके कि ClickHouse वास्तव में है।
क्या आप इनग्रेस के बारे में बात कर रहे हैं?
हां, इनग्रेस को हैप्रोक्सी से बदलें। हैप्रोक्सी में आप क्लस्टर की टोपोलॉजी निर्दिष्ट कर सकते हैं जहां इसकी प्रतिकृतियां हैं।
हमने अभी तक इस बारे में नहीं सोचा है. यदि आपको इसकी आवश्यकता है और आप बता सकते हैं कि इसकी आवश्यकता क्यों है, तो इसे लागू करना संभव होगा, खासकर यदि आप भाग लेना चाहते हैं। हमें विकल्प पर विचार करने में खुशी होगी. संक्षिप्त उत्तर है नहीं, वर्तमान में हमारे पास ऐसी कार्यक्षमता नहीं है। टिप के लिए धन्यवाद, हम इस मामले पर गौर करेंगे। और यदि आप उपयोग के मामले को भी समझाते हैं और व्यवहार में इसकी आवश्यकता क्यों है, उदाहरण के लिए, GitHub पर मुद्दे बनाते हैं, तो यह बहुत अच्छा होगा।
पहले से ही है।
अच्छा। हम किसी भी सुझाव के लिए खुले हैं। और हैप्रोक्सी को कार्य सूची में जोड़ा गया है। कार्य सूची बढ़ रही है, अभी कम नहीं हो रही है। लेकिन यह अच्छा है, इसका मतलब है कि उत्पाद मांग में है।
स्रोत: www.habr.com