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

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



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



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

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



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

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

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

पहले क्या था

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



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

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

हमें क्या सूट नहीं किया

कुछ बिंदु पर, हम इस निष्कर्ष पर पहुंचे: सेवाओं के साथ काम करना असंभव है। कई कारण थे।

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

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

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

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

समस्याओं

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

यह सिर्फ एक समस्या है जिसे एक अलग सूची में एक साथ रखा जा सकता है:

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

और यह सब नहीं है।

निर्णय

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



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

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

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

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

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

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

नई घटना संचालित डिजाइन: org.apache.ignite.internal.processors.service.IgniteServiceProcess..ava

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

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

आगे क्या होगा

अब योजनाओं के बारे में। इग्नाइट परियोजना में किसी भी बड़े विकास को इग्नाइट, तथाकथित IEP को बेहतर बनाने की पहल के रूप में किया जाता है। सर्विस ग्रिड रिडिजाइन में एक IEP - IEP नंबर 17 भी है, जिसका नाम बैंकर के नाम के साथ "ऑयल चेंज इन सर्विस ग्रिड" है। लेकिन वास्तव में, हमने इंजन में तेल नहीं, बल्कि पूरे इंजन को बदल दिया।

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

• हॉट रेडिप
  
• सेवा संस्करण
  
• बढ़ी हुई वैमनस्यता
  
• पतला ग्राहक
  
• विभिन्न मैट्रिक्स की निगरानी और गिनती के लिए उपकरण
  

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