सेवा ग्रिड प्रज्वलित गर्नुहोस् - रिबुट गर्नुहोस्

फेब्रुअरी 26 मा, हामीले Apache Ignite GreenSource बैठक आयोजना गर्‍यौं, जहाँ खुला स्रोत परियोजनाका योगदानकर्ताहरूले बोलेका थिए। अपाचे प्रज्वलित। यस समुदायको जीवनमा महत्त्वपूर्ण घटना घटकको पुनर्संरचना थियो सेवा ग्रिड प्रज्वलित गर्नुहोस्, जसले तपाईंलाई इग्नाइट क्लस्टरमा सिधै अनुकूलन माइक्रोसर्भिसेसहरू डिप्लोय गर्न अनुमति दिन्छ। उनले भेटमा यो कठिन प्रक्रियाको बारेमा कुरा गरे व्याचेस्लाव दारादुर, सफ्टवेयर इन्जिनियर र Apache Ignite योगदानकर्ता दुई वर्ष भन्दा बढीको लागि।

Apache Ignite सामान्यतया के हो त्यसबाट सुरु गरौं। यो एक डाटाबेस हो जुन SQL, लेनदेन र क्यासिङको लागि समर्थनको साथ वितरित कुञ्जी/मान भण्डारण हो। थप रूपमा, इग्नाइटले तपाईंलाई इग्नाइट क्लस्टरमा सिधै अनुकूलन सेवाहरू प्रयोग गर्न अनुमति दिन्छ। विकासकर्तासँग इग्नाइटले प्रदान गर्ने सबै उपकरणहरूमा पहुँच छ - वितरित डाटा संरचना, सन्देश, स्ट्रिमिङ, कम्प्युट र डाटा ग्रिड। उदाहरणका लागि, डाटा ग्रिड प्रयोग गर्दा, डाटा भण्डारणको लागि छुट्टै पूर्वाधार व्यवस्थापन गर्ने समस्या र परिणाम स्वरूप, उपरि लागतहरू हराउँछन्।

सेवा ग्रिड एपीआई प्रयोग गरेर, तपाइँ केवल डिप्लोइमेन्ट योजना निर्दिष्ट गरेर सेवा डिप्लोय गर्न सक्नुहुन्छ र, तदनुसार, कन्फिगरेसनमा सेवा नै।

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

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

थप रूपमा, त्यहाँ एफिनिटी सेवा जस्ता सुविधा छ। Affinity एक प्रकार्य हो जसले विभाजनहरूमा कुञ्जीहरूको सम्बन्ध र टोपोलोजीमा नोडहरूसँग पार्टीहरूको सम्बन्ध परिभाषित गर्दछ। कुञ्जी प्रयोग गरेर, तपाइँ प्राथमिक नोड निर्धारण गर्न सक्नुहुन्छ जसमा डाटा भण्डारण गरिएको छ। यस तरिकाले तपाईले आफ्नो सेवालाई कुञ्जी र एफिनिटी प्रकार्य क्याससँग सम्बद्ध गर्न सक्नुहुन्छ। यदि सम्बद्धता प्रकार्य परिवर्तन भयो भने, स्वचालित पुन: प्रयोग हुनेछ। यस तरिकाले, सेवा सधैं यसलाई हेरफेर गर्न आवश्यक डाटाको नजिक स्थित हुनेछ, र, तदनुसार, पहुँच जानकारी को ओभरहेड कम गर्नुहोस्। यस योजनालाई एक प्रकारको कोलोकेटेड कम्प्युटिङ भन्न सकिन्छ।

अब हामीले सेवा ग्रिडको सुन्दरता के हो भनेर पत्ता लगाएका छौं, यसको विकास इतिहासको बारेमा कुरा गरौं।

पहिले के भयो

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

प्रयोगकर्ताले सेवा प्रयोग गर्न चाहँदा के भयो?

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

के हामीलाई सुहाउँदैन

केही बिन्दुमा हामी निष्कर्षमा पुग्यौं: यो सेवाहरूसँग काम गर्ने तरिका होइन। त्यहाँ धेरै कारणहरू थिए।

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

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

थप रूपमा, म कार्यान्वयनलाई सरल बनाउन चाहन्छु, अर्थात्, लेनदेन र पुन: सन्तुलनबाट टाढा जानुहोस्। क्यास दोहोरिएको छ र त्यहाँ कुनै सन्तुलन छैन भन्ने तथ्यको बावजुद, धेरै नोडहरूसँग ठूलो परिनियोजनको समयमा समस्याहरू उत्पन्न भयो। जब टोपोलोजी परिवर्तन हुन्छ, नोडहरूले जानकारी आदानप्रदान गर्न आवश्यक हुन्छ, र ठूलो परिनियोजनको साथ, यो डेटा धेरै तौल हुन सक्छ।

जब टोपोलोजी अस्थिर थियो, संयोजकले सेवाहरूको वितरण पुन: गणना गर्न आवश्यक थियो। र सामान्यतया, जब तपाइँ एक अस्थिर टोपोलोजी मा लेनदेन संग काम गर्न को लागी, यो कठिन-गर्न-पूर्वानुमान त्रुटिहरु को नेतृत्व गर्न सक्छ।

समस्याहरू

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

यो एक अलग सूचीमा सङ्कलन गर्न सकिने समस्याहरू मध्ये एक मात्र हो:

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

र त्यो सबै होइन।

निर्णय

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

Communication-spi ले नोडहरूलाई सीधा सञ्चार गर्न र सन्देशहरू फर्वार्ड गर्न अनुमति दिन्छ। यो ठूलो मात्रामा डाटा पठाउनको लागि उपयुक्त छ। Discovery-spi ले तपाईंलाई क्लस्टरका सबै नोडहरूमा सन्देश पठाउन अनुमति दिन्छ। मानक कार्यान्वयनमा, यो रिंग टोपोलोजी प्रयोग गरी गरिन्छ। त्यहाँ Zookeeper सँग एकीकरण पनि छ, यस अवस्थामा तारा टोपोलोजी प्रयोग गरिन्छ। ध्यान दिनुपर्ने अर्को महत्त्वपूर्ण बिन्दु यो हो कि खोज-spi ले ग्यारेन्टी प्रदान गर्दछ कि सन्देश निश्चित रूपमा सबै नोडहरूमा सही क्रममा डेलिभर गरिनेछ।

डिप्लोइमेन्ट प्रोटोकल हेरौं। डिप्लोयमेन्ट र डिप्लोयमेन्टका लागि सबै प्रयोगकर्ता अनुरोधहरू डिस्कवरी-स्पि मार्फत पठाइन्छ। यसले निम्न दिन्छ ग्यारेन्टी:

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

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

लामबाट सबै अनुरोधहरू डिप्लोयमेन्ट प्रबन्धकद्वारा प्रशोधन गरिन्छ। यसमा एक विशेष कार्यकर्ता छ जसले यस लामबाट कार्य तान्दछ र यसलाई प्रयोग गर्न सुरु गर्न सुरु गर्दछ। यस पछि, निम्न कार्यहरू हुन्छन्:

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

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

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

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

अब के हुने हो

अब योजनाहरूको बारेमा। इग्नाइट परियोजनामा ​​भएको कुनै पनि ठूलो परिवर्तनलाई IEP भनिने इग्नाइट सुधार पहलको रूपमा पूरा गरिन्छ। सेवा ग्रिड पुन: डिजाइनमा पनि IEP छ - IEP #17 "सेवा ग्रिडमा तेल परिवर्तन" को उपहासात्मक शीर्षकको साथ। तर वास्तवमा, हामीले इन्जिनको तेल होइन, तर सम्पूर्ण इन्जिन परिवर्तन गर्यौं।

हामीले IEP मा भएका कार्यहरूलाई २ चरणमा विभाजन गरेका छौं। पहिलो एक प्रमुख चरण हो, जसमा डिप्लोइमेन्ट प्रोटोकल पुन: कार्य गर्ने समावेश छ। यो पहिले नै मास्टर मा समावेश छ, तपाईं नयाँ सेवा ग्रिड प्रयास गर्न सक्नुहुन्छ, जुन संस्करण 2 मा देखा पर्नेछ। दोस्रो चरणमा धेरै अन्य कार्यहरू समावेश छन्:

• तातो पुन: प्रयोग
• सेवा संस्करण
• दोष सहिष्णुता बढ्यो
• पातलो ग्राहक
• विभिन्न मेट्रिक्स निगरानी र गणना लागि उपकरण

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

स्रोत: www.habr.com