साइबरपंक से युक्त क्लाउड सेवा के निर्माण का इतिहास

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

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

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

बिल्ली में आपका स्वागत है.

एक यात्रा की शुरूआत

कुछ समय पहले, हमारी टीम को हमारे ग्राहकों के लिए क्लाउड प्लेटफ़ॉर्म लॉन्च करने का काम सौंपा गया था। सेवा के सॉफ़्टवेयर भाग को लागू करने के लिए प्रौद्योगिकियों को चुनने में हमारे पास प्रबंधन समर्थन, संसाधन, हार्डवेयर स्टैक और स्वतंत्रता थी।

वहाँ भी कई आवश्यकताएँ थीं:

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

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

• पायथन + फ्लास्क + स्वैगर + SQLAlchemy - एक पूरी तरह से मानक पायथन सेट;
• फ्रंटएंड के लिए Vue.js;
• हमने एएमक्यूपी पर सेलेरी का उपयोग करके घटकों और सेवाओं के बीच बातचीत करने का निर्णय लिया।

पायथन को चुनने के बारे में प्रश्नों का अनुमान लगाते हुए, मैं समझाता हूँ। भाषा ने हमारी कंपनी में अपना स्थान बना लिया है और इसके चारों ओर एक छोटी, लेकिन फिर भी संस्कृति विकसित हुई है। इसलिए, इस पर सेवा का निर्माण शुरू करने का निर्णय लिया गया। इसके अलावा, ऐसी समस्याओं में विकास की गति अक्सर निर्णायक होती है।

तो, आइए अपना परिचय शुरू करें।

साइलेंट बिल - बिलिंग

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

बिलिंग वह पहली प्रणाली है जिसके साथ हमने दोस्ती करने की कोशिश की। और पहली कठिनाई जिसका हमें सामना करना पड़ा वह सेवाओं को संसाधित करते समय थी।

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

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

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

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

दूसरी समस्या है मौन.

बिली कुछ एपीआई अनुरोधों का चुपचाप "ओके" उत्तर देता है। यह मामला था, उदाहरण के लिए, जब हमने परीक्षण के दौरान वादा किए गए भुगतान का भुगतान किया था (उस पर बाद में अधिक जानकारी दी जाएगी)। अनुरोधों को सही ढंग से निष्पादित किया गया और हमें कोई त्रुटि नहीं दिखी।

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

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

तो, संक्षेप में कहें तो, बातचीत के चरण में जिन मुख्य समस्याओं का हमें सामना करना पड़ा, वे एक विशिष्ट प्रणाली की कार्यान्वयन सुविधाओं से संबंधित हैं:

• अनिर्दिष्ट "सुविधाएँ" जो हमें किसी न किसी रूप में प्रभावित करती हैं;
• बंद स्रोत (बिलिंग C++ में लिखी गई है), परिणामस्वरूप - "परीक्षण और त्रुटि" के अलावा किसी भी तरह से समस्या 1 को हल करना असंभव है।

सौभाग्य से, उत्पाद में काफी व्यापक एपीआई है और हमने निम्नलिखित उपप्रणालियों को अपने व्यक्तिगत खाते में एकीकृत किया है:

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

टंगस्टन क्षेत्रों के माध्यम से चलना - टंगस्टन फैब्रिक

टंगस्टन क्षेत्र सैकड़ों तारों से युक्त हैं, जिनके माध्यम से हजारों बिट्स की जानकारी गुजरती है। जानकारी को "पैकेट" में एकत्र किया जाता है, पार्स किया जाता है, जटिल मार्गों का निर्माण किया जाता है, जैसे कि जादू से।

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

सिस्टम न्यूट्रॉन प्लगइन के माध्यम से ओपनस्टैक (नीचे चर्चा की गई) के साथ एकीकृत है।

ओपनस्टैक सेवाओं की सहभागिता।

परिचालन विभाग के लोगों ने हमें इस प्रणाली से परिचित कराया। हम अपनी सेवाओं के नेटवर्क स्टैक को प्रबंधित करने के लिए सिस्टम के एपीआई का उपयोग करते हैं। इससे हमें अभी तक कोई गंभीर समस्या या असुविधा नहीं हुई है (मैं OE के लोगों के लिए नहीं बोल सकता), लेकिन बातचीत में कुछ विषमताएँ रही हैं।

पहला इस तरह दिखता था: एसएसएच के माध्यम से कनेक्ट होने पर इंस्टेंस कंसोल में बड़ी मात्रा में डेटा आउटपुट करने की आवश्यकता वाले कमांड ने कनेक्शन को बस "हैंग" कर दिया, जबकि वीएनसी के माध्यम से सब कुछ सही ढंग से काम करता था।

जो लोग समस्या से परिचित नहीं हैं, उनके लिए यह काफी हास्यास्पद लगता है: ls /root सही ढंग से काम करता है, जबकि, उदाहरण के लिए, शीर्ष पूरी तरह से "जमा देता है"। सौभाग्य से, हमने पहले भी इसी तरह की समस्याओं का सामना किया है। इसका निर्णय कंप्यूट नोड्स से राउटर तक के मार्ग पर एमटीयू को ट्यून करके किया गया था। वैसे, यह कोई TF समस्या नहीं है.

अगली समस्या बस आने ही वाली थी। एक "खूबसूरत" पल में, रूटिंग का जादू गायब हो गया, ठीक वैसे ही। टीएफ ने उपकरण पर रूटिंग का प्रबंधन बंद कर दिया है।

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

सिलिकॉन लाइफफॉर्म्स - ओपनस्टैक

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

ओपनस्टैक हमारे प्लेटफ़ॉर्म का मूल है।

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

प्रत्येक सेवा एक कंटेनर में चलती है, और संदेश दलाल "सफेद खरगोश" है - RabbitMQ।

इस व्यवस्था ने हमें सबसे अप्रत्याशित परेशानी दी।

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

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

डिस्क के साथ काम करते समय एक और कठिनाई हमारा इंतजार कर रही थी। सिस्टम वॉल्यूम को सर्वर से डिस्कनेक्ट नहीं किया जा सका.

फिर से, ओपनस्टैक स्वयं "शपथ" लेता है कि उसने कनेक्शन को नष्ट कर दिया है और अब आप वॉल्यूम के साथ अलग से सही ढंग से काम कर सकते हैं। लेकिन एपीआई स्पष्ट रूप से डिस्क पर संचालन नहीं करना चाहता था।

यहां हमने विशेष रूप से लड़ने का नहीं, बल्कि सेवा के तर्क के बारे में अपना दृष्टिकोण बदलने का निर्णय लिया। यदि कोई उदाहरण है, तो एक सिस्टम वॉल्यूम भी होना चाहिए। इसलिए, उपयोगकर्ता अभी तक "सर्वर" को हटाए बिना सिस्टम "डिस्क" को हटा या अक्षम नहीं कर सकता है।

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

परीक्षण के लिए चलाना

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

निःसंदेह, परीक्षण अपने आप में मज़ेदार क्षणों से रहित नहीं था, क्योंकि यहीं से हमारे रोमांच की शुरुआत हो रही है।

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

एक अन्य जिज्ञासा आपके व्यक्तिगत खाते में "पासवर्ड बदलें" बटन की कार्यक्षमता से संबंधित है।

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

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

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

को जारी रखा जाएगा

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

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

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

हमने हाल ही में सेवा लॉन्च की है।
आप सारी जानकारी हमारे यहां पा सकते हैं ऑनलाइन.

सीएलओ विकास दल

उपयोगी लिंक्स

OpenStack

• https://docs.openstack.org/nova/latest/
• https://docs.openstack.org/keystone/latest/
• https://docs.openstack.org/cinder/latest/
• https://docs.openstack.org/glance/latest/

टंगस्टन कपड़ा

• http://docs.tungsten.io/en/latest/user/getting-started/index.html
• https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

स्रोत: www.habr.com