✊🏼 😿 👩🏼‍🤝‍👨🏾 टारेंटूल कुबेरनेट्स ऑपरेटर 👩🏽‍🚀 ✊ 👈🏻

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

हम राज्य के टारनटूल कारतूस समूहों को लॉन्च करने के लिए अपने समाधान को पेश करना चाहते हैं: टारेंटूल कुबेरनेट्स ऑपरेटर , कट के नीचे और अधिक।

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

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

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

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

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

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

आज हम Tarantool Kubernetes Operator के अल्फा संस्करण को पेश करते हैं।

एक हजार शब्दों के बजाय

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

जहाँ

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

रूटर्स पर आने वाले HTTP ट्रैफ़िक को संतुलित करने के लिए, एक कुबेरनेट्स इनग्रेड का उपयोग किया जाता है। डेटा को टारेंटूल के स्तर पर भंडारण में वितरित किया जाता है, जिसका उपयोग vshard घटक का उपयोग करके किया जाता है ।

हमें कुबेरनेट्स 1.14+ की आवश्यकता है, लेकिन मिनिक्यूब करेंगे। कुबेटेल का होना भी प्यारा है। ऑपरेटर को शुरू करने के लिए, एक ServiceAccount, एक रोल और एक रोलबाइंडिंग बनाएं:

$ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/service_account.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/role.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/role_binding.yaml

टारेंटूल ऑपरेटर अपनी संसाधन परिभाषाओं के साथ कुबेरनेट्स एपीआई का विस्तार करता है, तो चलिए उन्हें बनाते हैं:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_cluster_crd.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_role_crd.yaml $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/crds/tarantool_v1alpha1_replicasettemplate_crd.yaml

सब कुछ ऑपरेटर शुरू करने के लिए तैयार है, इसलिए यहाँ यह जाता है:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/deploy/operator.yaml

हम ऑपरेटर के शुरू होने की प्रतीक्षा कर रहे हैं, और फिर हम आवेदन शुरू करने के साथ आगे बढ़ सकते हैं:

 $ kubectl create -f https://raw.githubusercontent.com/tarantool/tarantool-operator/0.0.1/examples/kv/deployment.yaml

उदाहरण के साथ YAML फ़ाइल में वेब UI पर एक इनग्रेड घोषित किया गया है; यह cluster_ip/admin/cluster में उपलब्ध है। जब कम से कम एक इनग्रेड पॉड तैयार और चल रहा हो, तो आप यह देखने के लिए वहां जा सकते हैं कि क्लस्टर में नए इंस्टेंस कैसे जोड़े जाते हैं और इसके टॉपर्स कैसे बदलते हैं।
हम क्लस्टर के उपयोग की प्रतीक्षा कर रहे हैं:

 $ kubectl describe clusters.tarantool.io examples-kv-cluster

हम निम्नलिखित क्लस्टर स्थिति की प्रतीक्षा कर रहे हैं:

 … Status: State: Ready …

यह सब है, और आवेदन का उपयोग करने के लिए तैयार है!

क्या आपको अधिक संग्रहण स्थान की आवश्यकता है? फिर, आइए कुछ शर्ते जोड़ें:

 $ kubectl scale roles.tarantool.io storage --replicas=3

यदि शार्क लोड को संभाल नहीं सकते हैं, तो चलो प्रतिकृति सेट टेम्पलेट को संपादित करके शार्क में उदाहरणों की संख्या बढ़ाएँ:

 $ kubectl edit replicasettemplates.tarantool.io storage-template

आइए हम प्रत्येक .spec.replicas में दो उदाहरणों की संख्या बढ़ाने के लिए .spec.replicas मान को दो पर सेट करें।

यदि क्लस्टर की आवश्यकता नहीं है, तो उसे सभी संसाधनों के साथ हटा दें:

 $ kubectl delete clusters.tarantool.io examples-kv-cluster

क्या कुछ गलत हुआ? एक टिकट बनाएं , और हम जल्दी से इस पर काम करेंगे।

ऑपरेटर वास्तव में क्या करता है

टारेंटूल कार्ट्रिज क्लस्टर का स्टार्ट-अप और संचालन एक विशिष्ट समय में एक विशिष्ट क्रम में विशिष्ट कार्यों को करने की कहानी है।

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

हम टारेंटूल उदाहरणों की आवश्यक संख्या को तैनात करते हैं, उदाहरण के लिए, सिस्टमड का उपयोग करते हुए।
तब हम उदाहरणों को सदस्यता से जोड़ते हैं:
```
 mutation { probe_instance: probe_server(uri: "storage:3301") } 
```
फिर हम उदाहरणों को भूमिकाएँ सौंपते हैं और उदाहरण और प्रतिकृति सेट पहचानकर्ताओं को निर्दिष्ट करते हैं। इस उद्देश्य के लिए ग्राफकार्ड एपीआई का उपयोग किया जाता है:
```
 mutation { join_server( uri:"storage:3301", instance_uuid: "cccccccc-cccc-4000-b000-000000000001", replicaset_uuid: "cccccccc-0000-4000-b000-000000000000", roles: ["storage"], timeout: 5 ) } 
```
inally, हम API का उपयोग करते हुए तेज करने के लिए जिम्मेदार घटक को बूटस्ट्रैप करते हैं:
```
 mutation { bootstrap_vshard cluster { failover(enabled:true) } } 
```

आसान है, है ना?

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

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

विवरण के बारे में एक छोटी सी

टारनटूल कार्ट्रिज क्लस्टर एडमिनिस्ट्रेटर एपीआई के साथ काम करते समय, कॉल और उनके गंतव्य दोनों का क्रम आवश्यक है। वह क्यों है?

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

 servers: d8a9ce19-a880-5757-9ae0-6a0959525842: uri: storage-2-0.examples-kv-cluster:3301 replicaset_uuid: 8cf044f2-cae0-519b-8d08-00a2f1173fcb 497762e2-02a1-583e-8f51-5610375ebae9: uri: storage-0-0.examples-kv-cluster:3301 replicaset_uuid: 05e42b64-fa81-59e6-beb2-95d84c22a435 … vshard: bucket_count: 30000 ...

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

हर उदाहरण की एक निश्चित पहचान होनी चाहिए, अर्थात् instance_uuid और replicaset_uuid का एक सेट, साथ ही साथ advertise_uri । यदि अचानक भंडारण फिर से शुरू होता है, और इनमें से एक पैरामीटर बदलता है, तो आप कोरम को तोड़ने का जोखिम चलाते हैं, और ऑपरेटर इसके लिए जिम्मेदार है।

ऑपरेटर कैसे काम करता है

ऑपरेटर का उद्देश्य सिस्टम को उपयोगकर्ता-परिभाषित राज्य में लाना है और इस दिशा में सिस्टम को बनाए रखना है जब तक कि नई दिशाएं नहीं दी जाती हैं। ऑपरेटर को काम करने में सक्षम होने के लिए, इसकी आवश्यकता है:

सिस्टम की स्थिति का वर्णन।
वह कोड जो सिस्टम को इस स्थिति में लाएगा।
इस कोड को k8s में एकीकृत करने का एक तंत्र (उदाहरण के लिए, राज्य परिवर्तन सूचनाएं प्राप्त करने के लिए)।

टारेंटूल कार्ट्रिज क्लस्टर को कस्टम संसाधन परिभाषा (CRD) का उपयोग करके k8 के संदर्भ में वर्णित किया गया है। ऑपरेटर को टारेंटूल.io/v1alpha समूह के तहत तीन कस्टम संसाधनों की आवश्यकता होगी:

क्लस्टर एक शीर्ष-स्तरीय संसाधन है जो एकल टारेंटूल कार्ट्रिज क्लस्टर से मेल खाता है।
टारेंटूल कार्ट्रिज के संदर्भ में भूमिका एक उपयोगकर्ता की भूमिका है।
रेप्लिकेटसेट टेम्प्लेट स्टेटफुलसेट बनाने के लिए एक टेम्प्लेट है (मैं आपको बाद में बताऊंगा कि वे राज्य क्यों हैं? K8s प्रतिकृति के साथ भ्रमित नहीं होना चाहिए)।

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

कोड जो दिए गए राज्य में सिस्टम लाता है वह K8s के संदर्भ में नियंत्रक है। टारेंटूल ऑपरेटर के मामले में, कई नियंत्रक हैं:

क्लस्टर नियंत्रक टारेंटूल कार्ट्रिज क्लस्टर के साथ बातचीत के लिए जिम्मेदार है; यह क्लस्टर से इंस्टेंस को जोड़ता है और क्लस्टर से इंस्टेंस को डिस्कनेक्ट करता है।
भूमिका नियंत्रक टेम्पलेट से StatefulSets बनाने और उनमें से पूर्वनिर्धारित संख्या बनाए रखने के लिए जिम्मेदार उपयोगकर्ता भूमिका नियंत्रक है।

नियंत्रक की तरह क्या है? यह कोड का एक सेट है जो धीरे-धीरे दुनिया भर में खुद को क्रम में रखता है। एक क्लस्टर नियंत्रक योजनाबद्ध रूप से दिखेगा:

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

सामान्य तौर पर, सब कुछ काफी सरल है। हालांकि, प्रत्येक चरण को पारित करने के लिए सफलता के मानदंड को निर्धारित करना महत्वपूर्ण है। उदाहरण के लिए, क्लस्टर ज्वाइन ऑपरेशन को तब सफल नहीं माना जाता है जब वह काल्पनिक सफलता = सही लौटाता है, लेकिन जब वह "पहले से ही ज्वाइन" जैसी त्रुटि देता है।

और इस तंत्र का अंतिम भाग K8s के साथ नियंत्रक का एकीकरण है। एक पक्षी की नज़र से, पूरे K8s में नियंत्रकों का एक समूह होता है जो घटनाओं को उत्पन्न करते हैं और उनका जवाब देते हैं। इन घटनाओं को उन कतारों में आयोजित किया जाता है जिन्हें हम सदस्यता दे सकते हैं। यह आमतौर पर ऐसा दिखेगा:

उपयोगकर्ता kubectl create -f tarantool_cluster.yaml , और संबंधित क्लस्टर संसाधन बनाया जाता है। क्लस्टर नियंत्रक को क्लस्टर संसाधन निर्माण के बारे में सूचित किया जाता है। और पहली बात यह है कि सभी भूमिका संसाधनों को ढूंढना है जो इस क्लस्टर का हिस्सा होना चाहिए। यदि ऐसा होता है, तो यह क्लस्टर को रोल के मालिक के रूप में असाइन करता है और रोल संसाधन को अपडेट करता है। भूमिका नियंत्रक को एक रोल अपडेट अधिसूचना प्राप्त होती है, यह समझता है कि संसाधन का मालिक है, और स्टेटफुलसेट बनाना शुरू करता है। यह वह तरीका है जो काम करता है: पहला ईवेंट दूसरे को ट्रिगर करता है, दूसरा इवेंट तीसरे को ट्रिगर करता है, और इसी तरह जब तक उनमें से एक बंद नहीं हो जाता। आप एक समय ट्रिगर भी सेट कर सकते हैं, उदाहरण के लिए, हर 5 सेकंड में।

यह है कि ऑपरेटर को कैसे व्यवस्थित किया जाता है: हम एक कस्टम संसाधन बनाते हैं और उस कोड को लिखते हैं जो संसाधनों से संबंधित घटनाओं पर प्रतिक्रिया करता है।

ऑपरेटर क्या बनाता है

ऑपरेटर की कार्रवाइयाँ अंततः K8s पॉड्स और कंटेनर बनाने में परिणत होती हैं। K8s पर तैनात टारनटूल कारतूस समूह में, सभी पॉड्स स्टेटफुलसेट्स से जुड़े हैं।

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

जब सभी क्लस्टर संसाधन तैयार होते हैं और वांछित स्थिति में होते हैं, तो वे निम्नलिखित पदानुक्रम को दर्शाते हैं:

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

स्टेटफुलसेट्स के अलावा, टारनटूल ऑपरेटर लीडर चुनाव के लिए एक हेडलेस सर्विस बनाता है, और इस सेवा के दौरान इंस्टेंस एक दूसरे के साथ संवाद करते हैं।

टारेंटूल ऑपरेटर ऑपरेटर फ्रेमवर्क पर आधारित है, और ऑपरेटर कोड गोलंग में लिखा गया है, इसलिए यहां कुछ खास नहीं है।

सारांश

यह सब बहुत सुंदर है। हम आपकी प्रतिक्रिया और टिकटों की प्रतीक्षा कर रहे हैं। हम उनके बिना नहीं कर सकते - यह सब के बाद अल्फा संस्करण है। आगे क्या है? अगला कदम बहुत चमकाने वाला है:

यूनिट, ई 2 ई परीक्षण;
अराजकता बंदर परीक्षण;
तनाव परीक्षण;
बैकअप / पुनर्स्थापना;
बाहरी टोपोलॉजी प्रदाता।

इनमें से प्रत्येक विषय अपने आप में व्यापक है और एक अलग लेख का हकदार है, इसलिए कृपया अपडेट की प्रतीक्षा करें!