टारेंटूल कार्ट्रिज: तीन लाइनों में शेयरिंग लुआ बैकेंड

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

अच्छी खबर: हमें धक्कों का अपना हिस्सा मिला (उदाहरण के लिए, [2] , [3] ) और एक और ढांचा बनाया, जो इस समस्या के समाधान को काफी सरल करता है।

टारेंटूल कार्ट्रिज जटिल वितरित प्रणालियों को विकसित करने का नया ढांचा है। यह आपको बुनियादी ढांचे की समस्याओं को हल करने के बजाय व्यावसायिक तर्क लिखने पर ध्यान केंद्रित करने की अनुमति देता है। कटौती के तहत, मैं आपको बताऊंगा कि यह रूपरेखा कैसे काम करती है और वितरित सेवाओं को लिखने में कैसे मदद कर सकती है।

तो वास्तव में समस्या क्या है?

हमारे पास टारनटूल और वर्शार्ड है - हमें और क्या चाहिए?

पहला, यह सुविधा का सवाल है। Vshard Lua तालिकाओं में कॉन्फ़िगर किया गया है। लेकिन सही ढंग से काम करने के लिए कई टारेंटूल प्रक्रियाओं की वितरित प्रणाली के लिए, कॉन्फ़िगरेशन हर जगह समान होना चाहिए। कोई भी इसे मैन्युअल रूप से नहीं करना चाहेगा, इसलिए सभी प्रकार की स्क्रिप्ट, Ansible और परिनियोजन सिस्टम का उपयोग किया जाता है।

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

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

हमने इन समस्याओं को बार-बार हल किया, और कुछ बिंदु पर, हम अपने संपूर्ण जीवन चक्र में आवेदन के साथ काम को सरल बनाने के लिए एक दृष्टिकोण विकसित करने में कामयाब रहे: निर्माण, विकास, परीक्षण, सीआई / सीडी, रखरखाव।

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

टारनटूल कारतूस की मुख्य विशेषताएं:

• स्वचालित क्लस्टर ऑर्केस्ट्रेशन;
  
• नई भूमिकाओं के साथ विस्तारित अनुप्रयोग कार्यक्षमता;
  
• विकास और तैनाती के लिए आवेदन टेम्पलेट;
  
• अंतर्निहित स्वचालित शार्किंग;
  
• Luatest ढांचे के साथ एकीकरण;
  
• WebUI और API का उपयोग करके क्लस्टर प्रबंधन;
  
• पैकेजिंग और परिनियोजन उपकरण।
  

नमस्ते विश्व!

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

$ tarantoolctl rocks install cartridge-cli $ export PATH=$PWD/.rocks/bin/:$PATH 

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

 $ cartridge create --name myapp 

और यहाँ है कि हम क्या मिलता है:

 myapp/ ├── .git/ ├── .gitignore ├── app/roles/custom.lua ├── deps.sh ├── init.lua ├── myapp-scm-1.rockspec ├── test │ ├── helper │ │ ├── integration.lua │ │ └── unit.lua │ ├── helper.lua │ ├── integration/api_test.lua │ └── unit/sample_test.lua └── tmp/ 

यह एक तैयार-से-उपयोग के साथ एक गिट रिपॉजिटरी है "हैलो, वर्ल्ड!" आवेदन। आइए निर्भरता स्थापित करने के बाद इसे चलाने का प्रयास करें (फ्रेमवर्क सहित):

 $ tarantoolctl rocks make $ ./init.lua --http-port 8080 

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

अनुप्रयोगों का विकास करना

कल्पना करें कि हम एक ऐसी प्रणाली तैयार कर रहे हैं, जिसमें डेटा प्राप्त करना चाहिए, उसे सहेजना चाहिए, और दिन में एक बार एक रिपोर्ट बनानी चाहिए।


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


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


Vshard- राउटर और गेटवे को अलग-अलग इंस्टेंस पर रखने में बहुत समझदारी नहीं है। हम एक बार फिर नेटवर्क पर क्यों जाएंगे, अगर यह पहले से ही राउटर की जिम्मेदारी है? उन्हें एक ही प्रक्रिया के भीतर चलना चाहिए, अर्थात, गेटवे और vshard.router.cfg दोनों को एक ही प्रक्रिया में आरंभीकृत किया जाना चाहिए, और स्थानीय रूप से बातचीत करना चाहिए।

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


और जब मामला मंचन या उत्पादन के लिए तैनात करने की चिंता करता है, तो हम अंतर्निहित हार्डवेयर क्षमताओं के आधार पर हर टारेंटूल प्रक्रिया के लिए एक अलग सेट प्रदान करते हैं:

टोपोलॉजी प्रबंधन

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


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

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

भूमिका जीवनचक्र

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

 function init() function validate_config() function apply_config() function stop() 

प्रत्येक भूमिका में एक init फ़ंक्शन होता है। इसे एक बार कहा जाता है: या तो जब भूमिका सक्षम होती है, या जब टारेंटूल पुनरारंभ होता है। यहां यह सुविधाजनक है, उदाहरण के लिए, box.space.create को इनिशियलाइज़ करने के लिए, या शेड्यूलर कुछ बैकग्राउंड फाइबर चला सकते हैं जो नियमित अंतराल पर कार्य पूरा करेंगे।

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

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

कचरा साफ करने के लिए रोल्स stop मेथड का भी समर्थन करते हैं। यदि हम कहते हैं कि इस सर्वर पर अनुसूचक की कोई आवश्यकता नहीं है, तो यह उन तंतुओं को रोक सकता है, जिनका उपयोग init ने शुरू किया था।

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

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


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


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

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

डॉकर के विपरीत, हम केवल एक भूमिका की "छवि" नहीं ले सकते हैं, इसे किसी अन्य मशीन में स्थानांतरित कर सकते हैं और इसे वहां चला सकते हैं। हमारी भूमिकाएं डॉकटर कंटेनरों की तरह अलग-थलग नहीं हैं। इसके अलावा, हम एक ही उदाहरण पर दो समान भूमिका नहीं निभा सकते। भूमिका या तो वहाँ है या यह नहीं है; एक अर्थ में, यह एक सिंगलटन है। और तीसरे, पूरे प्रतिकृति समूह के भीतर भूमिकाएं समान होनी चाहिए क्योंकि, अन्यथा, यह हास्यास्पद लगेगा: डेटा समान है, लेकिन व्यवहार अलग है।

परिनियोजन उपकरण

मैंने आपको यह दिखाने का वादा किया कि कार्ट्रिज अनुप्रयोगों को तैनात करने में कैसे मदद कर सकता है। जीवन को आसान बनाने के लिए, फ्रेमवर्क RPM संकुल बनाता है:

 $ cartridge pack rpm myapp # will create ./myapp-0.1.0-1.rpm $ sudo yum install ./myapp-0.1.0-1.rpm 

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

 $ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080} myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False} myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False} CONFIG 

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

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

 $ sudo systemctl start myapp@router $ sudo systemctl start myapp@storage_A $ sudo systemctl start myapp@storage_B 

हमने कॉन्फ़िगरेशन में कार्ट्रिज वेब इंटरफ़ेस के लिए HTTP पोर्ट निर्दिष्ट किया है: 8080। चलो वहाँ पर चलते हैं और एक नज़र रखते हैं:


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

चलो खुद पीते हैं और लंबे काम के सप्ताह के बाद आराम करते हैं। आवेदन का उपयोग करने के लिए तैयार है।

परिणाम

परिणामों के बारे में क्या? Github पर कृपया परीक्षण करें, उपयोग करें, प्रतिक्रिया छोड़ें और टिकट बनाएं।

संदर्भ

[1] टारेंटूल »२.२» संदर्भ »रॉक्स संदर्भ» मॉड्यूल बनाम
[२] हमने टारेंटूल के आधार पर अल्फ़ा-बैंक के निवेश व्यवसाय के मूल को कैसे कार्यान्वित किया
[३] अगली पीढ़ी के बिलिंग आर्किटेक्चर: ट्रेंटुलिंग में संक्रमण
[४] SWIM - क्लस्टर बिल्डिंग प्रोटोकॉल
[५] गिटहब - टारेंटूल / कार्ट्रिज-क्लाई
[६] गिटहब - टारनटूल / कारतूस