सेवा ग्रिड प्रज्वलित करा - रीबूट करा

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

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

सर्व्हिस ग्रिड API वापरून, तुम्ही फक्त डिप्लॉयमेंट स्कीम निर्दिष्ट करून सेवा तैनात करू शकता आणि त्यानुसार, कॉन्फिगरेशनमध्ये सेवा स्वतःच.

सामान्यतः, उपयोजन योजना क्लस्टर नोड्सवर उपयोजित केलेल्या घटनांच्या संख्येचे संकेत असते. दोन विशिष्ट उपयोजन योजना आहेत. पहिला क्लस्टर सिंगलटन आहे: कोणत्याही वेळी, क्लस्टरमध्ये वापरकर्ता सेवेचा एक प्रसंग उपलब्ध असण्याची हमी दिली जाते. दुसरा नोड सिंगलटन आहे: प्रत्येक क्लस्टर नोडवर सेवेचा एक प्रसंग तैनात केला जातो.

वापरकर्ता संपूर्ण क्लस्टरमधील सेवा उदाहरणांची संख्या देखील निर्दिष्ट करू शकतो आणि योग्य नोड्स फिल्टर करण्यासाठी एक पूर्वसूचना परिभाषित करू शकतो. या परिस्थितीत, सर्व्हिस ग्रिड स्वतः सेवा तैनात करण्यासाठी इष्टतम वितरणाची गणना करेल.

याव्यतिरिक्त, अॅफिनिटी सर्व्हिस सारखे वैशिष्ट्य आहे. अ‍ॅफिनिटी हे असे फंक्शन आहे जे टोपोलॉजीमध्ये विभाजनांच्या की आणि पक्षांचे नोड्समधील संबंध परिभाषित करते. की वापरून, आपण प्राथमिक नोड निर्धारित करू शकता ज्यावर डेटा संग्रहित केला जातो. अशा प्रकारे तुम्ही तुमची स्वतःची सेवा की आणि अ‍ॅफिनिटी फंक्शन कॅशेसह संबद्ध करू शकता. अ‍ॅफिनिटी फंक्शन बदलल्यास, स्वयंचलित रीडिप्लॉयमेंट होईल. अशा प्रकारे, सेवा नेहमी हाताळण्यासाठी आवश्यक असलेल्या डेटाच्या जवळ स्थित असेल आणि त्यानुसार, माहितीमध्ये प्रवेश करण्याचे ओव्हरहेड कमी करेल. या योजनेला एक प्रकारची कोलोकेटेड कॉम्प्युटिंग म्हणता येईल.

आता आम्ही सर्व्हिस ग्रिडचे सौंदर्य काय आहे हे शोधून काढले आहे, चला त्याच्या विकासाच्या इतिहासाबद्दल बोलूया.

आधी काय झालं

सर्व्हिस ग्रिडची पूर्वीची अंमलबजावणी इग्नाइटच्या ट्रान्झॅक्शनल रिप्लिकेटेड सिस्टम कॅशेवर आधारित होती. इग्नाइटमधील "कॅशे" हा शब्द स्टोरेजला संदर्भित करतो. म्हणजेच, ही काही तात्पुरती नाही, जसे तुम्हाला वाटते. कॅशेची प्रतिकृती तयार केली आहे आणि प्रत्येक नोडमध्ये संपूर्ण डेटा सेट आहे हे असूनही, कॅशेमध्ये त्याचे विभाजन केलेले प्रतिनिधित्व आहे. हे स्टोरेज ऑप्टिमायझेशनमुळे आहे.

जेव्हा वापरकर्त्याला सेवा उपयोजित करायची होती तेव्हा काय झाले?

• क्लस्टरमधील सर्व नोड्स अंगभूत सतत क्वेरी यंत्रणा वापरून स्टोरेजमधील डेटा अद्यतनित करण्यासाठी सदस्यता घेतात.
• इनिशिएटिंग नोडने, रीड-कमिटेड ट्रान्झॅक्शन अंतर्गत, सीरिअलाइज्ड इन्स्टन्ससह सर्व्हिस कॉन्फिगरेशन असलेल्या डेटाबेसमध्ये रेकॉर्ड केले.
• नवीन एंट्रीबद्दल सूचित केल्यावर, समन्वयकाने कॉन्फिगरेशनवर आधारित वितरणाची गणना केली. परिणामी ऑब्जेक्ट डेटाबेसवर परत लिहिला गेला.
• जर नोड वितरणाचा भाग असेल, तर समन्वयकाने तो तैनात करावा.

जे आम्हाला शोभत नव्हते

काही क्षणी आम्ही निष्कर्षापर्यंत पोहोचलो: सेवांसह कार्य करण्याचा हा मार्ग नाही. अनेक कारणे होती.

उपयोजनादरम्यान काही त्रुटी आढळल्यास, ते फक्त नोडच्या लॉगमधून शोधले जाऊ शकते जिथे सर्व काही घडले. तेथे फक्त असिंक्रोनस उपयोजन होते, म्हणून उपयोजन पद्धतीवरून वापरकर्त्याकडे नियंत्रण परत केल्यानंतर, सेवा सुरू करण्यासाठी काही अतिरिक्त वेळ आवश्यक होता - आणि या काळात वापरकर्ता काहीही नियंत्रित करू शकला नाही. सेवा ग्रिड आणखी विकसित करण्यासाठी, नवीन वैशिष्ट्ये तयार करण्यासाठी, नवीन वापरकर्त्यांना आकर्षित करण्यासाठी आणि प्रत्येकाचे जीवन सोपे करण्यासाठी, काहीतरी बदलणे आवश्यक आहे.

नवीन सर्व्हिस ग्रिड डिझाइन करताना, आम्ही सर्व प्रथम सिंक्रोनस उपयोजनाची हमी देऊ इच्छितो: वापरकर्त्याने API वरून नियंत्रण परत केल्यावर, तो त्वरित सेवा वापरू शकतो. मी इनिशिएटरला डिप्लॉयमेंट एरर हाताळण्याची क्षमता देखील देऊ इच्छित होतो.

याव्यतिरिक्त, मला अंमलबजावणी सुलभ करायची होती, म्हणजे, व्यवहार आणि पुनर्संतुलनापासून दूर जा. कॅशेची प्रतिकृती तयार केली आहे आणि कोणतेही संतुलन नाही हे असूनही, अनेक नोड्ससह मोठ्या तैनाती दरम्यान समस्या उद्भवल्या. जेव्हा टोपोलॉजी बदलते, तेव्हा नोड्सना माहितीची देवाणघेवाण करणे आवश्यक असते आणि मोठ्या उपयोजनासह, हा डेटा खूप वजन करू शकतो.

जेव्हा टोपोलॉजी अस्थिर होते, तेव्हा समन्वयकाला सेवांच्या वितरणाची पुनर्गणना करणे आवश्यक होते. आणि सर्वसाधारणपणे, जेव्हा तुम्हाला अस्थिर टोपोलॉजीवर व्यवहारांसह कार्य करावे लागते, तेव्हा यामुळे अंदाज वर्तवण्यास कठीण त्रुटी येऊ शकतात.

समस्या

समस्यांशिवाय जागतिक बदल काय आहेत? यातील पहिला टोपोलॉजीमधील बदल होता. आपल्याला हे समजून घेणे आवश्यक आहे की कोणत्याही क्षणी, अगदी सेवा तैनातीच्या क्षणीही, नोड क्लस्टरमध्ये प्रवेश करू शकतो किंवा सोडू शकतो. शिवाय, उपयोजनाच्या वेळी नोड क्लस्टरमध्ये सामील झाल्यास, सेवांबद्दलची सर्व माहिती नवीन नोडमध्ये सातत्याने हस्तांतरित करणे आवश्यक असेल. आणि आम्ही फक्त काय आधीच तैनात केले आहे याबद्दल बोलत नाही, तर वर्तमान आणि भविष्यातील तैनातीबद्दल देखील बोलत आहोत.

ही फक्त एक समस्या आहे जी वेगळ्या सूचीमध्ये एकत्रित केली जाऊ शकते:

• नोड स्टार्टअपवर स्टॅटिकली कॉन्फिगर केलेल्या सेवा कशा तैनात करायच्या?
• क्लस्टरमधून नोड सोडणे - नोडने सेवा होस्ट केल्यास काय करावे?
• संयोजक बदलले असल्यास काय करावे?
• क्लायंट क्लस्टरशी पुन्हा कनेक्ट झाल्यास काय करावे?
• सक्रियकरण/निष्क्रियीकरण विनंत्यांवर प्रक्रिया करणे आवश्यक आहे का आणि कसे?
• जर त्यांनी कॅशे नष्ट करण्याची मागणी केली आणि आमच्याकडे त्याच्याशी संलग्नता सेवा असेल तर?

आणि एवढेच नाही.

निर्णय

लक्ष्य म्‍हणून, आम्‍ही संदेश वापरून प्रक्रिया संप्रेषणाची अंमलबजावणी करून इव्‍हेंट चालित पध्दत निवडली. इग्नाइटने दोन घटक आधीच लागू केले आहेत जे नोड्स आपापसात संदेश फॉरवर्ड करण्यास परवानगी देतात - कम्युनिकेशन-स्पी आणि डिस्कवरी-स्पी.

कम्युनिकेशन-स्पी नोड्सना थेट संप्रेषण करण्यास आणि संदेश फॉरवर्ड करण्यास अनुमती देते. मोठ्या प्रमाणात डेटा पाठवण्यासाठी हे योग्य आहे. डिस्कव्हरी-स्पी तुम्हाला क्लस्टरमधील सर्व नोड्सवर संदेश पाठविण्याची परवानगी देते. मानक अंमलबजावणीमध्ये, हे रिंग टोपोलॉजी वापरून केले जाते. झूकीपरसह एकीकरण देखील आहे, या प्रकरणात स्टार टोपोलॉजी वापरली जाते. आणखी एक महत्त्वाचा मुद्दा लक्षात घेण्यासारखा आहे की डिस्कवरी-स्पी हमी देतो की संदेश निश्चितपणे सर्व नोड्सवर योग्य क्रमाने वितरित केला जाईल.

चला डिप्लॉयमेंट प्रोटोकॉल पाहू. डिप्लॉयमेंट आणि अनडिप्लॉयमेंटसाठी सर्व वापरकर्ता विनंत्या डिस्कवरी-स्पी द्वारे पाठवल्या जातात. हे खालील देते हमी:

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

जेव्हा एखादी विनंती प्राप्त होते, तेव्हा क्लस्टरमधील नोड्स त्याचे प्रमाणीकरण करतात आणि प्रक्रिया कार्ये तयार करतात. ही कार्ये रांगेत आहेत आणि नंतर वेगळ्या कार्यकर्त्याद्वारे दुसर्या थ्रेडमध्ये प्रक्रिया केली जातात. हे अशा प्रकारे अंमलात आणले जाते कारण तैनातीमध्ये बराच वेळ लागू शकतो आणि महाग शोध प्रवाह असह्यपणे विलंब होऊ शकतो.

रांगेतील सर्व विनंत्या तैनाती व्यवस्थापकाद्वारे प्रक्रिया केल्या जातात. यात एक विशेष कार्यकर्ता आहे जो या रांगेतून एखादे कार्य खेचतो आणि तैनाती सुरू करण्यासाठी त्यास प्रारंभ करतो. यानंतर, खालील क्रिया होतात:

1. प्रत्येक नोड स्वतंत्रपणे वितरणाची गणना करतो, नवीन निर्धारक असाइनमेंट फंक्शनमुळे.
2. नोड्स तैनातीच्या परिणामांसह एक संदेश तयार करतात आणि समन्वयकाला पाठवतात.
3. समन्वयक सर्व संदेश एकत्रित करतो आणि संपूर्ण उपयोजन प्रक्रियेचा परिणाम तयार करतो, जो डिस्कवरी-स्पी द्वारे क्लस्टरमधील सर्व नोड्सवर पाठविला जातो.
4. परिणाम प्राप्त झाल्यावर, उपयोजन प्रक्रिया समाप्त होते, त्यानंतर कार्य रांगेतून काढले जाते.

नवीन इव्हेंट-चालित डिझाइन: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java

उपयोजनादरम्यान एखादी त्रुटी आढळल्यास, नोड समन्वयकाला पाठवलेल्या संदेशामध्ये ही त्रुटी त्वरित समाविष्ट करते. संदेश एकत्रीकरणानंतर, समन्वयकाकडे तैनातीदरम्यान सर्व त्रुटींबद्दल माहिती असेल आणि तो डिस्कवरी-स्पी द्वारे हा संदेश पाठवेल. क्लस्टरमधील कोणत्याही नोडवर त्रुटी माहिती उपलब्ध असेल.

या ऑपरेटिंग अल्गोरिदमचा वापर करून सर्व्हिस ग्रिडमधील सर्व महत्त्वाच्या घटनांवर प्रक्रिया केली जाते. उदाहरणार्थ, टोपोलॉजी बदलणे देखील डिस्कवरी-स्पी द्वारे संदेश आहे. आणि सर्वसाधारणपणे, पूर्वीच्या तुलनेत, प्रोटोकॉल अगदी हलके आणि विश्वासार्ह असल्याचे दिसून आले. तैनाती दरम्यान कोणतीही परिस्थिती हाताळण्यासाठी पुरेसे आहे.

पुढे काय होईल

आता योजनांबद्दल. इग्नाइट प्रकल्पातील कोणताही मोठा बदल इग्नाइट सुधारणा उपक्रम म्हणून पूर्ण केला जातो, ज्याला IEP म्हणतात. सर्व्हिस ग्रिड रीडिझाइनमध्ये एक IEP देखील आहे - IEP #17 "सेवा ग्रिडमध्ये तेल बदल" या उपहासात्मक शीर्षकासह. पण खरं तर, आम्ही इंजिन तेल बदलले नाही, परंतु संपूर्ण इंजिन.

आम्ही IEP मधील कार्ये 2 टप्प्यात विभागली. पहिला हा एक प्रमुख टप्पा आहे, ज्यामध्ये तैनाती प्रोटोकॉलचे पुन: कार्य करणे समाविष्ट आहे. हे आधीपासूनच मास्टरमध्ये समाविष्ट केले आहे, आपण नवीन सर्व्हिस ग्रिड वापरून पाहू शकता, जे आवृत्ती 2.8 मध्ये दिसेल. दुसऱ्या टप्प्यात इतर अनेक कार्ये समाविष्ट आहेत:

• हॉट रीडिप्लॉय
• सेवा आवृत्ती
• दोष सहिष्णुता वाढली
• छोटा ग्राहक
• विविध मेट्रिक्सचे निरीक्षण आणि गणना करण्यासाठी साधने

शेवटी, आम्ही तुम्हाला दोष-सहिष्णु, उच्च-उपलब्धता प्रणाली तयार करण्यासाठी सर्व्हिस ग्रिडवर सल्ला देऊ शकतो. येथे आम्हाला भेट देण्यासाठी आम्ही तुम्हाला आमंत्रित करतो देव-सूची и वापरकर्ता-सूची तुमचा अनुभव शेअर करा. तुमचा अनुभव समुदायासाठी खरोखर महत्त्वाचा आहे; तो तुम्हाला पुढे कुठे जायचे आहे, भविष्यात घटक कसा विकसित करायचा हे समजण्यास मदत करेल.

स्त्रोत: www.habr.com