इग्नाइट सर्विस ग्रिड - रिबूट

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

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

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

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

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

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

अब जब हमें पता चल गया है कि सर्विस ग्रिड की खूबसूरती क्या है, तो आइए इसके विकास के इतिहास के बारे में बात करते हैं।

पहले क्या हुआ था

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

जब उपयोगकर्ता सेवा को तैनात करना चाहता था तो क्या हुआ?

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

हमें क्या पसंद नहीं आया

कुछ बिंदु पर हम इस निष्कर्ष पर पहुंचे: सेवाओं के साथ काम करने का यह तरीका नहीं है। इसके कई कारण थे.

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

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

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

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

समस्याओं

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

यह उन समस्याओं में से एक है जिन्हें एक अलग सूची में एकत्र किया जा सकता है:

• नोड स्टार्टअप पर स्थिर रूप से कॉन्फ़िगर की गई सेवाओं को कैसे तैनात करें?
• क्लस्टर से एक नोड छोड़ना - यदि नोड ने सेवाओं की मेजबानी की है तो क्या करें?
• यदि समन्वयक बदल गया है तो क्या करें?
• यदि क्लाइंट क्लस्टर से पुनः कनेक्ट हो तो क्या करें?
• क्या सक्रियण/निष्क्रियकरण अनुरोधों को संसाधित करने की आवश्यकता है और कैसे?
• यदि वे कैश को नष्ट करने के लिए कहते हैं और हमारे पास एफ़िनिटी सेवाएँ इससे जुड़ी हैं तो क्या होगा?

और यह सब से बहुत दूर है।

समाधान

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

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

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

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

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

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

1. प्रत्येक नोड स्वतंत्र रूप से एक नए नियतात्मक असाइनमेंट फ़ंक्शन के कारण वितरण की गणना करता है।
2. नोड्स परिनियोजन के परिणामों के साथ एक संदेश उत्पन्न करते हैं और इसे समन्वयक को भेजते हैं।
3. समन्वयक सभी संदेशों को एकत्रित करता है और संपूर्ण परिनियोजन प्रक्रिया का परिणाम उत्पन्न करता है, जिसे डिस्कवरी-एसपीआई के माध्यम से क्लस्टर में सभी नोड्स पर भेजा जाता है।
4. जब परिणाम प्राप्त होता है, तो परिनियोजन प्रक्रिया समाप्त हो जाती है, जिसके बाद कार्य कतार से हटा दिया जाता है।

नया इवेंट-संचालित डिज़ाइन: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

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

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

आगे क्या होगा?

अब योजनाओं के बारे में. इग्नाइट परियोजना में कोई भी बड़ा बदलाव इग्नाइट सुधार पहल के रूप में पूरा किया जाता है, जिसे आईईपी कहा जाता है। सर्विस ग्रिड रीडिज़ाइन में IEP भी है - आईईपी #17 मज़ाकिया शीर्षक "सर्विस ग्रिड में तेल परिवर्तन" के साथ। लेकिन वास्तव में, हमने इंजन ऑयल नहीं, बल्कि पूरा इंजन बदला।

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

• गरम पुनः तैनाती
• सेवा संस्करण
• दोष सहनशीलता में वृद्धि
• दूसरे कंप्यूटर पर निर्भर रहने वाला कंप्यूटर प्रोग्राम
• विभिन्न मेट्रिक्स की निगरानी और गणना के लिए उपकरण

अंत में, हम आपको दोष-सहिष्णु, उच्च-उपलब्धता प्रणाली के निर्माण के लिए सर्विस ग्रिड पर सलाह दे सकते हैं। हम आपको यहां आने के लिए भी आमंत्रित करते हैं देव-सूची и उपयोगकर्ता सूची अपना अनुभव साझा करें. आपका अनुभव वास्तव में समुदाय के लिए महत्वपूर्ण है; यह आपको यह समझने में मदद करेगा कि आगे कहाँ जाना है, भविष्य में घटक कैसे विकसित करना है।

स्रोत: www.habr.com