क्लाउड सेवाको सृष्टिको इतिहास, साइबरपंकको स्वादमा

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

त्यसोभए हामीले क्लाउड प्लेटफर्म निर्माण गर्ने सम्मान पाएका थियौं, र यसको लागि हामीले हामीसँग काम गर्नका लागि केही उपप्रणालीहरूलाई "मनाउन" आवश्यक छ। सौभाग्यवश, हामीसँग "API भाषा", प्रत्यक्ष हात र धेरै उत्साह छ।

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

बिरालोमा स्वागत छ।

बाटोको सुरुवात

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

त्यहाँ धेरै आवश्यकताहरू पनि थिए:

• सेवालाई सुविधाजनक व्यक्तिगत खाता चाहिन्छ;
• प्लेटफर्म अवस्थित बिलिङ प्रणालीमा एकीकृत हुनुपर्छ;
• सफ्टवेयर र हार्डवेयर: OpenStack + Tungsten Fabric (Open Contrail), जुन हाम्रा इन्जिनियरहरूले राम्रोसँग "पकाउन" सिकेका छन्।

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

• Python + Flask + Swagger + SQLAlchemy - एक पूर्ण मानक पाइथन सेट;
• फ्रन्टएन्डको लागि Vue.js;
• हामीले AMQP मा सेलरी प्रयोग गरेर कम्पोनेन्ट र सेवाहरू बीच अन्तरक्रिया गर्ने निर्णय गर्यौं।

पाइथन छनौट गर्ने बारे प्रश्नहरू अनुमान गर्दै, म व्याख्या गर्नेछु। भाषाले हाम्रो कम्पनीमा आफ्नो स्थान पाएको छ र यसको वरिपरि एउटा सानो, तर अझै पनि संस्कृति विकसित भएको छ। त्यसैले यसमा सेवा निर्माण सुरु गर्ने निर्णय भएको हो । यसबाहेक, यस्ता समस्याहरूमा विकासको गति अक्सर निर्णायक हुन्छ।

त्यसोभए, हाम्रो परिचय सुरु गरौं।

मौन बिल - बिलिङ

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

हामीले साथी बनाउन खोजेको पहिलो प्रणाली बिलिङ हो। र हामीले सामना गरेको पहिलो कठिनाई सेवाहरू प्रशोधन गर्दा थियो।

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

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

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

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

अर्को समस्या मौनता हो।

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

UI मार्फत प्रणालीसँग काम गर्दा मैले लगहरू अध्ययन गर्नुपर्‍यो। यो बाहिरियो कि बिलिङ आफैले समान अनुरोधहरू प्रदर्शन गर्दछ, एक विशिष्ट प्रयोगकर्तामा दायरा परिवर्तन गर्दै, उदाहरणका लागि, प्रशासक, यसलाई su प्यारामिटरमा पास गर्दै।

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

त्यसोभए, संक्षेपमा, हामीले अन्तरक्रियाको चरणमा सामना गरेका मुख्य समस्याहरू विशेष प्रणालीको कार्यान्वयन सुविधाहरूसँग सम्बन्धित छन्:

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

सौभाग्यवश, उत्पादनसँग पर्याप्त व्यापक API छ र हामीले हाम्रो व्यक्तिगत खातामा निम्न उपप्रणालीहरू एकीकृत गरेका छौं:

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

टंगस्टन क्षेत्रहरू मार्फत हिड्दै - टंगस्टन कपडा

टंगस्टन क्षेत्रहरू सयौं तारहरूले भरिएका छन्, तिनीहरूमार्फत हजारौं बिट जानकारीहरू पार गर्दै। जानकारी "प्याकेटहरू" मा सङ्कलन गरिन्छ, पार्स, जटिल मार्गहरू निर्माण, जादुई जस्तै।

यो दोस्रो प्रणालीको डोमेन हो जसको साथ हामीले साथी बनाउनुपर्‍यो - टंगस्टन फेब्रिक (TF), पहिले OpenContrail। यसको कार्य नेटवर्क उपकरणहरू प्रबन्ध गर्नु हो, प्रयोगकर्ताहरूको रूपमा हामीलाई सफ्टवेयर अमूर्तता प्रदान गर्नु। TF - SDN, नेटवर्क उपकरण संग काम को जटिल तर्क encapsulates। त्यहाँ प्रविधिको बारेमा राम्रो लेख छ, उदाहरणका लागि, यहाँ.

प्रणाली न्यूट्रोन प्लगइन मार्फत OpenStack (तल छलफल गरिएको) संग एकीकृत छ।

OpenStack सेवाहरूको अन्तरक्रिया।

अपरेशन विभागका केटाहरूले हामीलाई यो प्रणालीमा परिचय गराए। हामी हाम्रा सेवाहरूको नेटवर्क स्ट्याक व्यवस्थापन गर्न प्रणालीको API प्रयोग गर्छौं। यसले हामीलाई अहिलेसम्म कुनै गम्भीर समस्या वा असुविधाहरू उत्पन्न गरेको छैन (म OE बाट केटाहरूको लागि बोल्न सक्दिन), तर अन्तरक्रियामा केही विचित्रताहरू छन्।

पहिलो यस्तो देखिन्थ्यो: आदेशहरू जसले SSH मार्फत जडान गर्दा इन्स्ट्यान्स कन्सोलमा ठूलो मात्रामा डाटा आउटपुट गर्न आवश्यक हुन्छ जडानलाई "ह्याङ अप" गर्छ, जबकि VNC मार्फत सबैले सही रूपमा काम गर्यो।

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

अर्को समस्या कुनाको वरपर मात्र थियो। एक "सुन्दर" क्षणमा, मार्गको जादू गायब भयो, जस्तै। TF ले उपकरणहरूमा मार्ग प्रबन्ध गर्न रोकेको छ।

हामीले व्यवस्थापक स्तरबाट Openstack सँग काम गर्यौं र त्यसपछि आवश्यक प्रयोगकर्ता स्तरमा सारियो। SDN ले कार्यहरू प्रदर्शन गर्ने प्रयोगकर्ताको दायरा "हाइज्याक" गरेको देखिन्छ। तथ्य यो हो कि उही प्रशासक खाता TF र OpenStack जडान गर्न प्रयोग गरिन्छ। प्रयोगकर्तामा स्विच गर्ने चरणमा, "जादू" गायब भयो। यो प्रणाली संग काम गर्न एक अलग खाता सिर्जना गर्ने निर्णय गरियो। यसले हामीलाई एकीकरण कार्यक्षमता तोड्न बिना काम गर्न अनुमति दियो।

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

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

OpenStack हाम्रो प्लेटफर्मको मूल हो।

ओपनस्ट्याकसँग धेरै उपप्रणालीहरू छन्, जसमध्ये हामी हाल नोभा, ग्लान्स र सिन्डरलाई सबैभन्दा सक्रिय रूपमा प्रयोग गर्छौं। तिनीहरूमध्ये प्रत्येकको आफ्नै API छ। नोभा गणना स्रोतहरू र उदाहरणहरूको सिर्जनाको लागि जिम्मेवार छ, Cinder भोल्युमहरू र तिनीहरूको स्न्यापशटहरू व्यवस्थापन गर्न जिम्मेवार छ, Glance एउटा छवि सेवा हो जसले OS टेम्प्लेटहरू र तिनीहरूमा मेटेनफर्मेसन व्यवस्थापन गर्दछ।

प्रत्येक सेवा कन्टेनरमा चल्छ, र सन्देश ब्रोकर "सेतो खरायो" हो - RabbitMQ।

यो प्रणालीले हामीलाई सबैभन्दा अप्रत्याशित समस्या दियो।

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

हामीले एक चक्कर लिने निर्णय गर्यौं र Nova API बाट उही कार्य अनुरोध गर्यौं। नतिजा यो हो कि उपकरण सही रूपमा जडान हुन्छ र सर्भर भित्र पहुँचयोग्य छ। यस्तो देखिन्छ कि समस्या तब हुन्छ जब ब्लक-भण्डारणले सिन्डरलाई प्रतिक्रिया दिदैन।

डिस्क संग काम गर्दा अर्को कठिनाई हामीलाई पर्खिरहेको थियो। प्रणाली भोल्युम सर्भरबाट विच्छेदन गर्न सकिएन।

फेरि, ओपनस्ट्याक आफैले "कसम खान्छ" कि यसले जडानलाई नष्ट गरेको छ र अब तपाइँ सही रूपमा भोल्युमसँग छुट्टै काम गर्न सक्नुहुन्छ। तर API स्पष्ट रूपमा डिस्कमा सञ्चालन गर्न चाहँदैन थियो।

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

OpenStack यसको आफ्नै अन्तरक्रिया तर्क र अलंकृत API संग प्रणालीहरूको एक जटिल सेट हो। हामीलाई पर्याप्त विस्तृत कागजातहरू र निस्सन्देह, परीक्षण र त्रुटि (यस बिना हामी कहाँ हुनेछौं) द्वारा मद्दत गरिन्छ।

टेस्ट रन

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

परीक्षण आफैं, निस्सन्देह, यसको हास्यास्पद क्षणहरू बिना थिएन, किनभने यो जहाँ हाम्रो साहसिक भर्खर सुरु हुँदैछ।

सर्वप्रथम, हामीले केही हदसम्म गलत तरिकाले परियोजनामा ​​​​चासोको मूल्याङ्कन गर्‍यौं र परीक्षणको क्रममा तुरुन्तै कम्प्युट नोडहरू थप्नुपर्‍यो। एक क्लस्टर को लागी एक सामान्य मामला, तर यहाँ केहि बारीकियां पनि थिए। TF को विशिष्ट संस्करणको लागि कागजातले कर्नेलको निर्दिष्ट संस्करणलाई संकेत गर्दछ जसमा vRouter सँग काम परीक्षण गरिएको थियो। हामीले हालैका कर्नेलहरूसँग नोडहरू सुरु गर्ने निर्णय गर्यौं। नतिजाको रूपमा, TF ले नोडहरूबाट मार्गहरू प्राप्त गरेन। मैले तुरुन्तै कर्नेलहरू फिर्ता गर्नुपर्‍यो।

अर्को जिज्ञासा तपाईको व्यक्तिगत खातामा "पासवर्ड परिवर्तन गर्नुहोस्" बटनको कार्यक्षमतासँग सम्बन्धित छ।

हामीले हाम्रो व्यक्तिगत खातामा पहुँच व्यवस्थित गर्न JWT प्रयोग गर्ने निर्णय गर्यौं ताकि सत्रहरूसँग काम नगर्न सकियोस्। प्रणालीहरू विविध र व्यापक रूपमा छरिएका हुनाले, हामी हाम्रो आफ्नै टोकन प्रबन्ध गर्छौं, जसमा हामी बिलिङबाट सत्रहरू र OpenStack बाट टोकन "रेप" गर्छौं। जब पासवर्ड परिवर्तन हुन्छ, टोकन, निस्सन्देह, "खराब जान्छ", किनभने प्रयोगकर्ता डेटा अब मान्य छैन र यसलाई पुन: जारी गर्न आवश्यक छ।

हामीले यो बिन्दुको दृष्टि गुमायौं, र यो टुक्रालाई तुरुन्तै समाप्त गर्न पर्याप्त स्रोतहरू थिएनन्। हामीले परीक्षण सुरु गर्नु अघि कार्यक्षमता काट्नुपर्‍यो।
यदि पासवर्ड परिवर्तन भएको छ भने हाल हामी प्रयोगकर्तालाई लगआउट गर्छौं।

यी सूक्ष्मताहरूको बावजुद, परीक्षण राम्रो भयो। दुई हप्तामा, करिब 300 जना मानिसहरू रोकिए। हामीले प्रयोगकर्ताहरूको आँखाबाट उत्पादन हेर्न, कार्यमा परीक्षण गर्न र उच्च गुणस्तरको प्रतिक्रिया सङ्कलन गर्न सक्षम थियौं।

जारी राख्न

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

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

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

हामीले भर्खरै सेवा सुरु गरेका छौं।
तपाईं हाम्रो मा सबै विवरण पाउन सक्नुहुन्छ साइट.

CLO विकास टोली

उपयोगी लिङ्कहरू

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