क्लोस्टर → सरल ओटीपी क्लस्टर प्रबंधन

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

यह इतना भाग्यशाली निकला Erlang, जिसे हमने इसके सुखद वाक्यविन्यास और इसके चारों ओर प्रचार के लिए चुना है, प्रथम श्रेणी का है वितरित प्रणालियों के लिए समर्थन. सिद्धांत रूप में, यह पूरी तरह से तुच्छ लगता है:

विभिन्न नोड्स पर प्रक्रियाओं के बीच, साथ ही लिंक और मॉनिटर के बीच संदेश भेजना पारदर्शी है […]

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

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

नोट: मुझे पता है कि वहाँ है libcluster. यह सचमुच बहुत अच्छा है, इसमें एक हजार से अधिक सितारे हैं, लेखक समुदाय में प्रसिद्ध है, इत्यादि। यदि क्लस्टर बनाने और बनाए रखने के लिए इस पैकेज द्वारा दी गई विधियाँ आपके लिए पर्याप्त हैं, तो मुझे आपके लिए खुशी होगी। दुर्भाग्य से, मुझे और भी बहुत कुछ चाहिए। मैं सेटअप को विस्तार से नियंत्रित करना चाहता हूं और क्लस्टर पुनर्गठन के थिएटर में बाहरी दर्शक नहीं बनना चाहता हूं।

आवश्यकताएँ

मुझे व्यक्तिगत रूप से एक ऐसी लाइब्रेरी की आवश्यकता थी जो क्लस्टर का प्रबंधन संभाले और जिसमें निम्नलिखित गुण हों:

• नोड्स की हार्ड-कोडित सूची और सेवाओं के माध्यम से गतिशील खोज दोनों के साथ पारदर्शी कार्य Erlang;
• प्रत्येक टोपोलॉजी परिवर्तन के लिए पूरी तरह कार्यात्मक कॉलबैक (वहां नोड, यहां नोड, नेटवर्क अस्थिरता, विभाजन);
• लंबे और छोटे नामों के साथ क्लस्टर लॉन्च करने के लिए पारदर्शी इंटरफ़ेस :nonode@nohost;
• इंफ्रास्ट्रक्चर कोड लिखने की आवश्यकता के बिना, बॉक्स से बाहर डॉकर समर्थन।

उत्तरार्द्ध का मतलब है कि मैंने स्थानीय स्तर पर एप्लिकेशन का परीक्षण किया :nonode@nohost, या कृत्रिम रूप से वितरित वातावरण का उपयोग करके test_cluster_task, मैं बस दौड़ना चाहता हूं docker-compose up --scale my_app=3 और देखें कि यह बिना किसी कोड परिवर्तन के डॉकर में तीन उदाहरणों को कैसे निष्पादित करता है। मुझे भी आश्रित अनुप्रयोग चाहिए जैसे mnesia - जब टोपोलॉजी बदलती है, तो पर्दे के पीछे वे एप्लिकेशन से किसी भी अतिरिक्त किक के बिना क्लस्टर को लाइव बनाते हैं।

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

चुना हुआ दृष्टिकोण

मठ इसे एक एप्लिकेशन के रूप में चलाने का इरादा है, हालांकि उन्नत उपयोगकर्ता सीधे चलाकर क्लस्टर के असेंबली और रखरखाव के साथ काम कर सकते हैं Cloister.Manager लक्ष्य अनुप्रयोग के पर्यवेक्षक वृक्ष में।

जब एक एप्लिकेशन के रूप में चलाया जाता है, तो लाइब्रेरी इस पर निर्भर होती है config, जिससे यह निम्नलिखित बुनियादी मूल्यों को पढ़ता है:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

उपरोक्त पैरामीटर का शाब्दिक अर्थ निम्नलिखित है: मठ ओटीपी एप्लिकेशन के लिए उपयोग किया जाता है :my_app, उपयोग करता है एरलांग सेवा खोज नोड्स को जोड़ने के लिए, कम से कम तीन, और MyApp.Listener मॉड्यूल (कार्यान्वयन) @behaviour Cloister.Listener) टोपोलॉजी परिवर्तनों के बारे में सूचनाएं प्राप्त करने के लिए कॉन्फ़िगर किया गया है। संपूर्ण कॉन्फ़िगरेशन का विस्तृत विवरण यहां पाया जा सकता है प्रलेखन.

इस कॉन्फ़िगरेशन के साथ, एप्लिकेशन मठ होगा चरणों में लॉन्च करें, आम सहमति बनने तक मुख्य एप्लिकेशन को शुरू करने की प्रक्रिया में देरी करना (तीन नोड्स जुड़े हुए हैं और जुड़े हुए हैं, जैसा कि ऊपर दिए गए उदाहरण में है।) यह मुख्य एप्लिकेशन को यह मानने का अवसर देता है कि जब यह शुरू होता है, तो क्लस्टर पहले से ही उपलब्ध है। जब भी टोपोलॉजी बदलती है (उनमें से कई होंगे, क्योंकि नोड्स पूरी तरह से तुल्यकालिक रूप से शुरू नहीं होते हैं), हैंडलर को बुलाया जाएगा MyApp.Listener.on_state_change/2. जब हमें कोई स्थिति संदेश प्राप्त होता है तो अधिकांश समय हम कोई कार्रवाई करते हैं %Cloister.Monitor{status: :up}, जिसका अर्थ है: "हैलो, क्लस्टर इकट्ठा हो गया है।"

ज्यादातर मामलों में, स्थापना consensus: 3 इष्टतम है क्योंकि भले ही हम अधिक नोड्स कनेक्ट होने की उम्मीद करते हैं, कॉलबैक चलेगा status: :rehashing → status: :up किसी भी नए जोड़े गए या हटाए गए नोड पर।

डेवलपमेंट मोड में प्रारंभ करते समय, आपको बस सेट करने की आवश्यकता है consensus: 1 и मठ जब वह देखेगा तो क्लस्टर असेंबली के लिए प्रतीक्षा करना खुशी-खुशी छोड़ देगा :nonode@nohostया :node@hostया :[email protected] - इस पर निर्भर करता है कि नोड को कैसे कॉन्फ़िगर किया गया था (:none | :shortnames | :longnames).

वितरित अनुप्रयोग प्रबंधन

वितरित अनुप्रयोग, जो निर्वात में नहीं होते, आमतौर पर वितरित निर्भरताएँ शामिल होती हैं, जैसे mnesia. हमारे लिए उसी कॉलबैक से उनके पुनर्विन्यास को संभालना आसान है on_state_change/2. उदाहरण के लिए, पुन: कॉन्फ़िगर करने के तरीके का विस्तृत विवरण यहां दिया गया है mnesia उड़ते-उड़ते प्रलेखन मठ.

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

यद्यपि कस्टम कार्यान्वयन के माध्यम से टोपोलॉजी परिवर्तनों का जटिल प्रबंधन संभव है MyApp.Listener, हमेशा ऐसे किनारे वाले मामले हो सकते हैं जहां ये लाइब्रेरी सीमाएं और कॉन्फ़िगरेशन पूर्वाग्रह कार्यान्वयन की आधारशिला साबित होते हैं। यह ठीक है, बस ऊपर वाला ले लो libcluster, जो अधिक सामान्य-उद्देश्य है, या यहां तक ​​कि निम्न-स्तरीय क्लस्टर को स्वयं भी संभाल सकता है। इस कोड लाइब्रेरी का लक्ष्य हर संभावित परिदृश्य को कवर करना नहीं है, बल्कि अनावश्यक दर्द और बोझिल कॉपी-पेस्ट के बिना सबसे सामान्य परिदृश्य का उपयोग करना है।

नोट: मूल में इस बिंदु पर "हैप्पी क्लस्टरिंग!" वाक्यांश था, और यांडेक्स, जिसके साथ मैं अनुवाद करता हूं (मुझे स्वयं शब्दकोशों से गुजरने की ज़रूरत नहीं है), ने मुझे "हैप्पी क्लस्टरिंग!" विकल्प की पेशकश की। इससे बेहतर अनुवाद की कल्पना करना शायद असंभव है, खासकर वर्तमान भू-राजनीतिक स्थिति के आलोक में।

स्रोत: www.habr.com