नमस्ते, हबर! मैं आपके ध्यान में लेख का अनुवाद प्रस्तुत करता हूँ "सर्विस मेश डेटा प्लेन बनाम कंट्रोल प्लेन" लेखक मैट क्लेन.

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

जैसा कि "सेवा जाल" का विचार पिछले दो वर्षों में तेजी से लोकप्रिय हो गया है (मूल लेख 10 अक्टूबर, 2017) और इस क्षेत्र में प्रतिभागियों की संख्या में वृद्धि हुई है, मैंने संपूर्ण के बीच भ्रम में एक समान वृद्धि देखी है विभिन्न समाधानों की तुलना और अंतर करने के तरीके के बारे में तकनीकी समुदाय।

जुलाई में मेरे द्वारा लिखे गए ट्वीट्स की निम्नलिखित शृंखला से स्थिति का सबसे अच्छा सारांश प्रस्तुत किया जा सकता है:

सेवा जाल भ्रम #1: लिंकरड ~ = नग्नेक्स ~ = हैप्रोक्सी ~ = दूत। उनमें से कोई भी इस्तियो के बराबर नहीं है। इस्तियो बिल्कुल अलग चीज़ है। 1/

पहले केवल डेटा प्लेन हैं। वे स्वयं कुछ नहीं करते। वे कुछ और करने के मूड में होंगे। 2/

इस्तियो एक नियंत्रण विमान का एक उदाहरण है जो भागों को एक साथ जोड़ता है। यह एक और परत है. /अंत

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

वास्तव में सर्विस मेश क्या है?

चित्र 1: सर्विस मेश अवलोकन

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

डेटा प्लेन

सर्विस मेश में, एप्लिकेशन के लिए स्थानीय रूप से स्थित एक प्रॉक्सी सर्वर निम्नलिखित कार्य करता है:

• सेवा खोज. आपके आवेदन के लिए कौन सी सेवाएँ/एप्लिकेशन उपलब्ध हैं?
• स्वास्थ्य जांच. क्या सेवा खोज द्वारा लौटाए गए सेवा उदाहरण स्वस्थ हैं और नेटवर्क ट्रैफ़िक स्वीकार करने के लिए तैयार हैं? इसमें सक्रिय (जैसे प्रतिक्रिया/स्वास्थ्य जांच) और निष्क्रिय (उदाहरण के लिए अस्वस्थ सेवा स्थिति के संकेत के रूप में लगातार 3 5xx त्रुटियों का उपयोग करना) स्वास्थ्य जांच दोनों शामिल हो सकते हैं।
• मार्ग. REST सेवा से "/foo" के लिए अनुरोध प्राप्त होने पर, अनुरोध किस सेवा क्लस्टर को भेजा जाना चाहिए?
• भार का संतुलन. एक बार रूटिंग के दौरान एक सर्विस क्लस्टर का चयन हो जाने के बाद, किस सर्विस इंस्टेंस को अनुरोध भेजा जाना चाहिए? किस टाइमआउट के साथ? किस सर्किट ब्रेकिंग सेटिंग के साथ? यदि अनुरोध विफल हो जाता है, तो क्या इसे पुनः प्रयास किया जाना चाहिए?
• सत्यापन और प्राधिकरण. आने वाले अनुरोधों के लिए, क्या कॉलिंग सेवा को एमटीएलएस या किसी अन्य तंत्र का उपयोग करके क्रिप्टोग्राफ़िक रूप से पहचाना/अधिकृत किया जा सकता है? यदि यह मान्यता प्राप्त/अधिकृत है, तो क्या इसे सेवा पर अनुरोधित ऑपरेशन (एंडपॉइंट) को कॉल करने की अनुमति है या एक अप्रमाणित प्रतिक्रिया लौटा दी जानी चाहिए?
• observability. प्रत्येक अनुरोध के लिए विस्तृत आँकड़े, लॉग/लॉग और वितरित ट्रेस डेटा तैयार किया जाना चाहिए ताकि ऑपरेटर वितरित ट्रैफ़िक प्रवाह और डिबगिंग समस्याओं के उत्पन्न होने पर उन्हें समझ सकें।

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

नियंत्रण विमान

डेटा प्लेन में एक स्थानीय प्रॉक्सी जो नेटवर्क एब्स्ट्रैक्शन प्रदान करता है वह जादुई (?) है। हालाँकि, प्रॉक्सी को वास्तव में सेवा बी के "/foo" मार्ग के बारे में कैसे पता चलता है? प्रॉक्सी अनुरोधों द्वारा भरे गए सेवा खोज डेटा का उपयोग कैसे किया जा सकता है? लोड संतुलन, टाइमआउट, सर्किट ब्रेकिंग आदि के लिए पैरामीटर कैसे कॉन्फ़िगर किए गए हैं? आप नीली/हरी पद्धति या ग्रेसफुल ट्रैफ़िक ट्रांज़िशन पद्धति का उपयोग करके किसी एप्लिकेशन को कैसे तैनात करते हैं? सिस्टम-व्यापी प्रमाणीकरण और प्राधिकरण सेटिंग्स कौन कॉन्फ़िगर करता है?

उपरोक्त सभी वस्तुएँ सर्विस मेश के नियंत्रण तल के नियंत्रण में हैं। नियंत्रण विमान पृथक स्टेटलेस प्रॉक्सी का एक सेट लेता है और उन्हें एक वितरित प्रणाली में बदल देता है.

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

चित्र 2: मानव नियंत्रण विमान

हालाँकि, हम लंबे समय से नियंत्रण विमानों का उपयोग कर रहे हैं, हालाँकि अधिकांश नेटवर्क ऑपरेटर सिस्टम के इस हिस्से को किसी भी प्रौद्योगिकी घटक के साथ नहीं जोड़ सकते हैं। वजह साफ है:
आज उपयोग में आने वाले अधिकांश नियंत्रण विमान हैं... हम.

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

चित्र 3: उन्नत सेवा जाल नियंत्रण विमान

पर चित्रा 3 सर्विस मेश का "विस्तारित" नियंत्रण तल दिखाता है। इसमें निम्नलिखित भाग शामिल हैं:

• इंसान: अभी भी एक व्यक्ति है (उम्मीद है कि कम क्रोधित) जो संपूर्ण प्रणाली के संबंध में उच्च स्तरीय निर्णय लेता है।
• नियंत्रण विमान यूआई: एक व्यक्ति सिस्टम को नियंत्रित करने के लिए किसी प्रकार के यूजर इंटरफेस के साथ इंटरैक्ट करता है। यह एक वेब पोर्टल, एक कमांड लाइन एप्लिकेशन (सीएलआई), या कोई अन्य इंटरफ़ेस हो सकता है। उपयोगकर्ता इंटरफ़ेस का उपयोग करते हुए, ऑपरेटर के पास वैश्विक सिस्टम कॉन्फ़िगरेशन पैरामीटर तक पहुंच होती है जैसे:
  • परिनियोजन नियंत्रण, नीला/हरा और/या क्रमिक यातायात संक्रमण
  • प्रमाणीकरण और प्राधिकरण विकल्प
  • राउटिंग टेबल विनिर्देश, उदाहरण के लिए जब एप्लिकेशन ए "/foo" के बारे में जानकारी का अनुरोध करता है तो क्या होता है
  • लोड बैलेंसर सेटिंग्स, जैसे टाइमआउट, पुनः प्रयास, सर्किट ब्रेकिंग सेटिंग्स इत्यादि।
• कार्यभार अनुसूचक: सेवाएँ कुछ प्रकार की शेड्यूलिंग/ऑर्केस्ट्रेशन प्रणाली, जैसे कुबेरनेट्स या नोमैड, के माध्यम से बुनियादी ढांचे पर चलाई जाती हैं। शेड्यूलर सेवा को उसके स्थानीय प्रॉक्सी के साथ लोड करने के लिए जिम्मेदार है।
• सेवा खोज. जब शेड्यूलर सेवा इंस्टेंस को प्रारंभ और बंद करता है, तो यह सेवा खोज प्रणाली को स्वास्थ्य स्थिति की रिपोर्ट करता है।
• साइडकार प्रॉक्सी कॉन्फ़िगरेशन एपीआई : स्थानीय प्रॉक्सी ऑपरेटर के हस्तक्षेप के बिना अंततः सुसंगत मॉडल का उपयोग करके विभिन्न सिस्टम घटकों से गतिशील रूप से स्थिति निकालते हैं। संपूर्ण सिस्टम, जिसमें वर्तमान में चल रहे सभी सेवा उदाहरण और स्थानीय प्रॉक्सी सर्वर शामिल हैं, अंततः एक पारिस्थितिकी तंत्र में परिवर्तित हो जाते हैं। एन्वॉय का यूनिवर्सल डेटा प्लेन एपीआई इस बात का एक उदाहरण है कि यह व्यवहार में कैसे काम करता है।

अनिवार्य रूप से, नियंत्रण विमान का उद्देश्य उस नीति को निर्धारित करना है जिसे अंततः डेटा विमान द्वारा स्वीकार किया जाएगा। अधिक उन्नत नियंत्रण विमान ऑपरेटर से कुछ प्रणालियों के अधिक हिस्सों को हटा देंगे और कम मैन्युअल संचालन की आवश्यकता होगी, बशर्ते वे सही ढंग से काम करें!...

डेटा प्लेन और कंट्रोल प्लेन। डेटा प्लेन बनाम कंट्रोल प्लेन सारांश

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

वर्तमान परियोजना परिदृश्य

उपरोक्त स्पष्टीकरण को समझने के बाद, आइए सर्विस मेश परियोजना की वर्तमान स्थिति पर नजर डालें।

• डेटा विमान: लिंकर्ड, एनजीआईएनएक्स, हैप्रोक्सी, एनवॉय, ट्रैफिक
• विमानों को नियंत्रित करें: इस्तियो, नेल्सन, स्मार्टस्टैक

उपरोक्त प्रत्येक समाधान के गहन विश्लेषण में जाने के बजाय, मैं उन कुछ बिंदुओं पर संक्षेप में चर्चा करूंगा जिनके बारे में मेरा मानना ​​है कि इस समय पारिस्थितिकी तंत्र में बहुत अधिक भ्रम पैदा हो रहा है।

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

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

नेल्सन और स्मार्टस्टैक नियंत्रण विमान और डेटा विमान के पृथक्करण को और स्पष्ट करने में मदद करते हैं। नेल्सन एन्वॉय को अपने प्रॉक्सी के रूप में उपयोग करता है और हाशीकॉर्प स्टैक के आधार पर सर्विस मेश के लिए एक विश्वसनीय नियंत्रण विमान बनाता है, अर्थात। खानाबदोश, आदि. स्मार्टस्टैक शायद सर्विस मेश की नई लहर में से पहला था। स्मार्टस्टैक HAProxy या NGINX के आसपास एक नियंत्रण विमान बनाता है, जो डेटा विमान से सेवा जाल से नियंत्रण विमान को अलग करने की क्षमता प्रदर्शित करता है।

सर्विस मेश के साथ माइक्रोसर्विस आर्किटेक्चर अधिक से अधिक ध्यान आकर्षित कर रहा है (ठीक है!), और अधिक से अधिक परियोजनाएं और विक्रेता इस दिशा में काम करना शुरू कर रहे हैं। अगले कुछ वर्षों में हम डेटा प्लेन और कंट्रोल प्लेन दोनों में बहुत सारे नवाचार देखेंगे, साथ ही विभिन्न घटकों का मिश्रण भी देखेंगे। अंततः, ऑपरेटर के लिए माइक्रोसर्विस आर्किटेक्चर अधिक पारदर्शी और जादुई (?) बनना चाहिए।
उम्मीद है कि कम और कम चिढ़ होगी।

चाबी छीनना

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

स्रोत: www.habr.com