एक-क्लाउड - Odnoklassniki मा डाटा केन्द्र स्तर OS

Aloha, मानिसहरू! मेरो नाम Oleg Anastasyev हो, म प्लेटफर्म टोलीमा Odnoklassniki मा काम गर्छु। र म बाहेक, Odnoklassniki मा काम गर्ने धेरै हार्डवेयर छ। हामीसँग लगभग 500 र्याकहरू सहित 8 हजार भन्दा बढी सर्भरहरू भएका चार डाटा केन्द्रहरू छन्। एक निश्चित बिन्दुमा, हामीले महसुस गर्यौं कि नयाँ व्यवस्थापन प्रणालीको परिचयले हामीलाई उपकरणहरू अझ प्रभावकारी रूपमा लोड गर्न, पहुँच व्यवस्थापनलाई सहज बनाउन, कम्प्युटिङ स्रोतहरूको (पुनः) वितरणलाई स्वचालित बनाउन, नयाँ सेवाहरूको प्रक्षेपणको गति बढाउन र प्रतिक्रियाहरूको गति बढाउन अनुमति दिनेछ। ठूला ठूला दुर्घटनाका लागि।

यसमा के आयो ?

म र हार्डवेयरको गुच्छा बाहेक, यस हार्डवेयरसँग काम गर्ने मानिसहरू पनि छन्: इन्जिनियरहरू जो सीधै डाटा केन्द्रहरूमा अवस्थित छन्; नेटवर्क सफ्टवेयर सेट अप गर्ने नेटवर्करहरू; पूर्वाधार लचिलोपन प्रदान गर्ने प्रशासकहरू, वा SREs; र विकास टोलीहरू, तिनीहरू प्रत्येक पोर्टलको कार्यहरूको अंशको लागि जिम्मेवार छन्। तिनीहरूले सिर्जना गर्ने सफ्टवेयरले यस्तो काम गर्छ:

प्रयोगकर्ता अनुरोधहरू मुख्य पोर्टलको दुवै मोर्चाहरूमा प्राप्त हुन्छन् www.ok.ru, र अरूहरूमा, उदाहरणका लागि संगीत API फ्रन्टहरूमा। व्यापार तर्क प्रशोधन गर्न, तिनीहरूले अनुप्रयोग सर्भरलाई कल गर्छन्, जुन, अनुरोध प्रशोधन गर्दा, आवश्यक विशेष माइक्रोसेवाहरू कल गर्दछ - एक-ग्राफ (सामाजिक जडानहरूको ग्राफ), प्रयोगकर्ता-क्यास (प्रयोगकर्ता प्रोफाइलहरूको क्यास), आदि।

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

त्यो किन हो? यो दृष्टिकोण धेरै लाभ थियो:

• राहत पाए जन व्यवस्थापन। मानौं एउटा कार्यलाई केही पुस्तकालयहरू, केही सेटिङहरू आवश्यक पर्दछ। र त्यसपछि सर्भरलाई ठ्याक्कै एक विशेष समूहमा तोकिएको छ, यो समूहको लागि cfengine नीति वर्णन गरिएको छ (वा यो पहिले नै वर्णन गरिएको छ), र यो कन्फिगरेसन केन्द्रीय रूपमा र स्वचालित रूपमा यस समूहमा सबै सर्भरहरूमा रोल आउट हुन्छ।
• सरलीकृत डायग्नोस्टिक्स। मानौं कि तपाईले केन्द्रीय प्रोसेसरमा बढेको लोडलाई हेर्नुभयो र यो भार यस हार्डवेयर प्रोसेसरमा चल्ने कार्यद्वारा मात्र उत्पन्न गर्न सकिन्छ भन्ने महसुस गर्नुहोस्। कसैलाई दोष दिन खोज्ने काम चाँडै समाप्त हुन्छ।
• सरलीकृत निगरानी। यदि सर्भरमा केहि गलत छ भने, मनिटरले यसलाई रिपोर्ट गर्दछ, र तपाईलाई थाहा छ कि दोषी को हो।

धेरै प्रतिकृतिहरू समावेश भएको सेवालाई धेरै सर्भरहरू आवंटित गरिएको छ - प्रत्येकको लागि एक। त्यसपछि सेवाको लागि कम्प्युटिङ स्रोत धेरै सरल रूपमा आवंटित गरिएको छ: सेवाको सर्भरहरूको संख्या, अधिकतम मात्रामा यो खपत गर्न सकिन्छ। यहाँ "सजिलो" को मतलब यो प्रयोग गर्न सजिलो छैन, तर यो अर्थमा कि स्रोत आवंटन म्यानुअल रूपमा गरिन्छ।

यो दृष्टिकोणले हामीलाई पनि गर्न अनुमति दियो विशेष फलाम कन्फिगरेसन यो सर्भरमा चलिरहेको कार्यको लागि। यदि कार्यले ठूलो मात्रामा डाटा भण्डार गर्दछ भने, त्यसपछि हामी 4 डिस्कहरूसँग चेसिसको साथ 38U सर्भर प्रयोग गर्दछौं। यदि कार्य विशुद्ध रूपमा कम्प्युटेसनल हो भने, हामी सस्तो 1U सर्भर किन्न सक्छौं। यो कम्प्यूटेशनली कुशल छ। अन्य चीजहरू मध्ये, यो दृष्टिकोणले हामीलाई एक अनुकूल सामाजिक नेटवर्कको तुलनामा लोडको साथ चार गुणा कम मेसिनहरू प्रयोग गर्न अनुमति दिन्छ।

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

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

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

तर मुख्य कुरा एउटै मेसिनमा चल्ने कार्यहरू बीच कुनै अलगाव छैन। यहाँ, उदाहरणका लागि, एउटै सर्भरमा अर्को कम्प्युटेसनल एप्लिकेसन सुरु हुनु अघि र पछि सर्भर कार्यको औसत प्रतिक्रिया समयको ग्राफ हो, पहिलोसँग सम्बन्धित छैन - मुख्य कार्यको प्रतिक्रिया समय उल्लेखनीय रूपमा बढेको छ।

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

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

साथै, डकरमा तयार-निर्मित रजिस्ट्री र छवि ट्यागिङले हामीलाई संस्करणको लागि र उत्पादनमा कोड डेलिभर गर्नको लागि तयार-निर्मित प्रिमिटिवहरू दिन्छ।

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

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

8 हजार सर्भर र 8-16 हजार कन्टेनरहरू हुँदा कन्टेनरहरू म्यानुअल रूपमा वितरण गर्ने विकल्प छैन।

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

जाहिर छ, हामीलाई एक नियन्त्रण तह चाहिन्छ जसले यो स्वचालित रूपमा गर्नेछ।

त्यसोभए हामी एक सरल र बुझ्न योग्य तस्वीरमा आएका छौं जुन सबै आर्किटेक्टहरूले मन पराउँछन्: तीन वर्गहरू।

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

स्रोत बाँडफाँड समिति

अब धेरै minions को लागि थप जटिल संसाधन आवंटन को समस्या हेरौं।

एक-क्लाउडमा एक कम्प्युटिङ स्रोत हो:

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

त्यसपछि केही सेवाका लागि, उदाहरणका लागि प्रयोगकर्ता-क्यासका लागि, हामीले उपभोग गरिएका स्रोतहरूलाई यसरी रेकर्ड गर्न सक्छौं: ४०० प्रोसेसर कोर, २.५ TB मेमोरी, दुबै दिशामा ५० Gbit/s ट्राफिक, १०० स्पिन्डलहरूमा रहेको HDD स्पेसको ६ TB। वा यो जस्तै अधिक परिचित फारममा:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

कम्पोनेन्टहरूको अन्तरक्रियाको हाम्रो धेरै सरलीकृत रेखाचित्रमा फर्कौं र यसलाई थप विवरणहरूको साथ पुन: कोरौं - जस्तै:

तपाइँको आँखा के समात्छ:

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

फेरि चित्र कोरौं:

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

अतिरिक्त रेखाहरू हटाएर, हामी हाम्रो चित्रको प्रत्येक नोडलाई चापलूसी रूपमा लेख्न सक्छौं: group1.web.front, api.music.front, user-cache.cache.

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

सेवाहरूमा नजिकबाट हेरौं। सेवाको पूर्ण रूपमा योग्य नाम हुन्छ, जसमा सधैं लामको नाम समावेश हुन्छ। त्यसपछि अगाडि वेब सेवा नाम हुनेछ ok-web.group1.web.front। र यसले पहुँच गर्ने अनुप्रयोग सर्भर सेवालाई कल गरिनेछ ok-app.group1.web.front। प्रत्येक सेवाको एउटा प्रकट हुन्छ, जसले विशेष मेसिनहरूमा प्लेसमेन्टको लागि सबै आवश्यक जानकारी निर्दिष्ट गर्दछ: यो कार्यले कति स्रोतहरू खपत गर्छ, यसको लागि कुन कन्फिगरेसन आवश्यक छ, कति प्रतिकृतिहरू हुनुपर्छ, यस सेवाको विफलताहरू ह्यान्डल गर्नका लागि गुणहरू। र सेवा सिधै मेसिनहरूमा राखे पछि, यसको उदाहरणहरू देखा पर्दछ। तिनीहरूको नाम पनि स्पष्ट रूपमा राखिएको छ - उदाहरण नम्बर र सेवा नामको रूपमा: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

यो धेरै सुविधाजनक छ: चलिरहेको कन्टेनरको नाम मात्र हेरेर, हामी तुरुन्तै धेरै पत्ता लगाउन सक्छौं।

अब यी उदाहरणहरूले वास्तवमा के प्रदर्शन गर्दछ भनेर नजिकबाट हेरौं: कार्यहरू।

टास्क आइसोलेशन कक्षाहरू

OK मा सबै कार्यहरू (र, सम्भवतः, जताततै) समूहहरूमा विभाजन गर्न सकिन्छ:

• छोटो विलम्बता कार्यहरू - उत्पादन। त्यस्ता कार्यहरू र सेवाहरूको लागि, प्रतिक्रिया ढिलाइ (विलम्बता) धेरै महत्त्वपूर्ण छ, प्रणाली द्वारा प्रत्येक अनुरोधलाई कति चाँडो प्रशोधन गरिनेछ। कार्यहरूको उदाहरणहरू: वेब फ्रन्टहरू, क्यासहरू, अनुप्रयोग सर्भरहरू, OLTP भण्डारण, आदि।
• गणना समस्याहरू - ब्याच। यहाँ, प्रत्येक विशिष्ट अनुरोधको प्रशोधन गति महत्त्वपूर्ण छैन। तिनीहरूका लागि, यो महत्त्वपूर्ण छ कि यो कार्यले निश्चित (लामो) समय (थ्रुपुट) मा कति गणना गर्नेछ। यी MapReduce, Hadoop, मेसिन लर्निङ, तथ्याङ्कका कुनै पनि कार्यहरू हुनेछन्।
• पृष्ठभूमि कार्यहरू - निष्क्रिय। त्यस्ता कार्यहरूको लागि, न विलम्बता वा थ्रुपुट धेरै महत्त्वपूर्ण छन्। यसमा विभिन्न परीक्षणहरू, माइग्रेसनहरू, पुन: गणनाहरू, र डेटाको एक ढाँचाबाट अर्कोमा रूपान्तरण समावेश छन्। एकातिर, तिनीहरू गणना गरिएकाहरूसँग मिल्दोजुल्दो छन्, अर्कोतर्फ, तिनीहरू कति चाँडो पूरा हुन्छन् भन्ने कुराले हामीलाई केही फरक पार्दैन।

हेरौं कसरी त्यस्ता कार्यहरूले स्रोतहरू खपत गर्छ, उदाहरणका लागि, केन्द्रीय प्रोसेसर।

छोटो ढिलाइ कार्यहरू। यस्तो कार्यमा CPU उपभोग ढाँचा यो जस्तै हुनेछ:

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

यस्तो कार्यको लागि न्यूनतम विलम्बताको ग्यारेन्टी गर्न, हामीले यसले खपत गर्ने अधिकतम स्रोतहरू लिनुपर्छ र मिनियन (कार्य कार्यान्वयन गर्ने मेसिन) मा आवश्यक संख्यामा कोरहरू आरक्षित गर्नुपर्छ। त्यसपछि हाम्रो समस्याको लागि आरक्षण सूत्र निम्नानुसार हुनेछ:

alloc: cpu = 4 (max)

र यदि हामीसँग 16 कोर भएको मिनियन मेसिन छ भने, त्यसमा ठीक चारवटा कार्यहरू राख्न सकिन्छ। हामी विशेष गरी नोट गर्छौं कि त्यस्ता कार्यहरूको औसत प्रोसेसर खपत प्राय: धेरै कम हुन्छ - जुन स्पष्ट छ, किनकि समयको एक महत्त्वपूर्ण भाग कार्यले अनुरोधको लागि पर्खन्छ र केहि गर्दैन।

गणना कार्यहरू। तिनीहरूको ढाँचा अलि फरक हुनेछ:

त्यस्ता कार्यहरूको लागि औसत CPU स्रोत खपत धेरै उच्च छ। प्रायः हामी गणना कार्य निश्चित समयमा पूरा गर्न चाहन्छौं, त्यसैले हामीले यसलाई आवश्यक पर्ने प्रोसेसरहरूको न्यूनतम संख्या आरक्षित गर्न आवश्यक छ ताकि सम्पूर्ण गणना स्वीकार्य समयमा पूरा होस्। यसको आरक्षण सूत्र यस्तो देखिनेछ:

alloc: cpu = [1,*)

"कृपया यसलाई एक मिनियनमा राख्नुहोस् जहाँ कम्तिमा एउटा नि: शुल्क कोर छ, र त्यसपछि त्यहाँ जति धेरै छन्, यसले सबै चीज खान्छ।"

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

तर त्यो कसरी गर्ने?

पहिले, prod र यसको alloc हेरौं: cpu = 4। हामीले चार कोरहरू आरक्षित गर्न आवश्यक छ। डकर रनमा यो दुई तरिकामा गर्न सकिन्छ:

• विकल्प प्रयोग गर्दै --cpuset=1-4, अर्थात् कार्यको लागि मेसिनमा चार विशिष्ट कोरहरू आवंटित गर्नुहोस्।
• Использовать --cpuquota=400_000 --cpuperiod=100_000, प्रोसेसर समयको लागि कोटा तोक्नुहोस्, अर्थात् प्रत्येक 100 ms रियल टाइममा कार्यले 400 ms प्रोसेसर समय भन्दा बढी खपत गर्दैन भनेर संकेत गर्नुहोस्। एउटै चार कोरहरू प्राप्त हुन्छन्।

तर यी मध्ये कुन विधि उपयुक्त छ?

cpuset धेरै आकर्षक देखिन्छ। कार्यमा चार समर्पित कोरहरू छन्, जसको मतलब प्रोसेसर क्यासहरूले सकेसम्म कुशलतापूर्वक काम गर्नेछ। यसको नकारात्मक पक्ष पनि छ: हामीले ओएसको सट्टा मेसिनको अनलोड गरिएको कोरहरूमा गणनाहरू वितरण गर्ने कार्य लिनु पर्छ, र यो एक बरु गैर-तुच्छ कार्य हो, विशेष गरी यदि हामीले ब्याच कार्यहरू राख्ने प्रयास गरेमा। मेसिन। परीक्षणहरूले देखाएको छ कि कोटाको साथ विकल्प यहाँ राम्रोसँग उपयुक्त छ: यस तरिकाले अपरेटिङ सिस्टमसँग हालको क्षणमा कार्य गर्नको लागि कोर छनौट गर्न बढी स्वतन्त्रता छ र प्रोसेसर समय अधिक कुशलतापूर्वक वितरण गरिएको छ।

कोरहरूको न्यूनतम संख्याको आधारमा डकरमा रिजर्भेसनहरू कसरी गर्ने भनेर पत्ता लगाउनुहोस्। ब्याच कार्यहरूको लागि कोटा अब लागू हुँदैन, किनभने त्यहाँ अधिकतम सीमित गर्न आवश्यक छैन, यो केवल न्यूनतम ग्यारेन्टी गर्न पर्याप्त छ। र यहाँ विकल्प राम्रोसँग फिट हुन्छ docker run --cpushares.

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

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

• SCHED_OTHER
  पूर्वनिर्धारित रूपमा, लिनक्स मेसिनमा सबै सामान्य प्रयोगकर्ता प्रक्रियाहरू प्राप्त हुन्छन्।
• SCHED_BATCH
  संसाधन-गहन प्रक्रियाहरूको लागि डिजाइन गरिएको। प्रोसेसरमा कार्य राख्दा, एक तथाकथित सक्रियता दण्ड पेश गरिन्छ: यदि यो हाल SCHED_OTHER सँग कार्यद्वारा प्रयोग भइरहेको छ भने त्यस्तो कार्यले प्रोसेसर स्रोतहरू प्राप्त गर्ने सम्भावना कम हुन्छ।
• SCHED_IDLE
  धेरै कम प्राथमिकता भएको पृष्ठभूमि प्रक्रिया, राम्रो -19 भन्दा पनि कम। हामी हाम्रो खुला स्रोत पुस्तकालय प्रयोग गर्छौं one-nio, कल गरेर कन्टेनर सुरु गर्दा आवश्यक नीति सेट गर्न

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

तर यदि तपाइँ जाभामा प्रोग्राम गर्नुहुन्न भने पनि, chrt आदेश प्रयोग गरेर उही कुरा गर्न सकिन्छ:

chrt -i 0 $pid

स्पष्टताको लागि हाम्रा सबै अलगाव स्तरहरूलाई एक तालिकामा संक्षेप गरौं:

इन्सुलेशन वर्ग
Alloc उदाहरण
डकर रन विकल्पहरू
sched_setscheduler chrt*

उत्पादन
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

ब्याच
Cpu = [१, *)
--cpushares=1024
SCHED_BATCH

निष्क्रिय
Cpu = [२, *)
--cpushares=2048
SCHED_IDLE

*यदि तपाइँ कन्टेनर भित्रबाट chrt गर्दै हुनुहुन्छ भने, तपाइँलाई sys_nice क्षमता चाहिन्छ, किनकि पूर्वनिर्धारित रूपमा डकरले कन्टेनर सुरु गर्दा यो क्षमता हटाउँछ।

तर कार्यहरूले प्रोसेसर मात्र होइन, तर ट्राफिक पनि खपत गर्दछ, जसले प्रोसेसर स्रोतहरूको गलत आवंटन भन्दा पनि नेटवर्क कार्यको विलम्बतालाई असर गर्छ। त्यसकारण, हामी स्वाभाविक रूपमा ट्राफिकको लागि ठ्याक्कै उही तस्वीर प्राप्त गर्न चाहन्छौं। त्यो हो, जब प्रोड कार्यले नेटवर्कमा केही प्याकेटहरू पठाउँछ, हामी अधिकतम गति (सूत्र alloc: lan=[*,500mbps) ), जसको उत्पादनले यो गर्न सक्छ। र ब्याचको लागि हामी न्यूनतम थ्रुपुट मात्र ग्यारेन्टी गर्छौं, तर अधिकतम (सूत्र alloc: lan=[10Mbps,*) ) यस अवस्थामा, प्रोड ट्राफिकले ब्याच कार्यहरू भन्दा प्राथमिकता प्राप्त गर्नुपर्छ।
यहाँ डकरसँग हामीले प्रयोग गर्न सक्ने कुनै पनि आदिम छैन। तर यो हाम्रो सहयोगमा आउँछ लिनक्स ट्राफिक नियन्त्रण। अनुशासनको सहयोगमा हामीले अपेक्षित नतिजा हासिल गर्न सफल भयौं पदानुक्रमिक निष्पक्ष सेवा वक्र। यसको मद्दतले, हामी ट्राफिकको दुई वर्गहरू छुट्याउन सक्छौं: उच्च-प्राथमिकता उत्पादन र कम-प्राथमिकता ब्याच/निष्क्रिय। नतिजाको रूपमा, बाहिर जाने ट्राफिकको कन्फिगरेसन यस्तो छ:

यहाँ 1:0 hsfc अनुशासनको "मूल qdisc" हो; 1:1 - 8 Gbit/s को कुल ब्यान्डविथ सीमा भएको hsfc बाल कक्षा, जस अन्तर्गत सबै कन्टेनरहरूको बाल कक्षाहरू राखिएको छ; 1:2 - hsfc चाइल्ड क्लास "गतिशील" सीमा भएका सबै ब्याच र निष्क्रिय कार्यहरूमा सामान्य छ, जसलाई तल छलफल गरिएको छ। बाँकी hsfc बाल कक्षाहरू हाल चलिरहेको प्रोड कन्टेनरहरूको लागि तिनीहरूको म्यानिफेस्टहरू - 450 र 400 Mbit/s सीमाहरूका लागि समर्पित कक्षाहरू हुन्। प्रत्येक hsfc वर्गलाई qdisc queue fq वा fq_codel तोकिएको छ, Linux कर्नेल संस्करणमा निर्भर गर्दै, ट्राफिक बर्स्टको समयमा प्याकेट नोक्सानबाट बच्न।

सामान्यतया, tc अनुशासनले बाहिर जाने ट्राफिकलाई मात्र प्राथमिकता दिन्छ। तर हामी आगमन ट्राफिकलाई पनि प्राथमिकता दिन चाहन्छौं - आखिर, केहि ब्याच कार्यले सजिलै सम्पूर्ण आगमन च्यानल चयन गर्न सक्छ, प्राप्त गर्न, उदाहरणका लागि, नक्सा र घटाउनको लागि इनपुट डेटाको ठूलो ब्याच। यसका लागि हामी मोड्युल प्रयोग गर्छौं ifb, जसले प्रत्येक सञ्जाल इन्टरफेसको लागि ifbX भर्चुअल इन्टरफेस सिर्जना गर्छ र इनकमिङ ट्राफिकलाई इन्टरफेसबाट ifbX मा बाहिर जाने ट्राफिकमा रिडिरेक्ट गर्छ। यसबाहेक, ifbX को लागि, सबै समान अनुशासनहरू बाहिर जाने ट्राफिक नियन्त्रण गर्न काम गर्दछ, जसको लागि hsfc कन्फिगरेसन धेरै समान हुनेछ:

प्रयोगको क्रममा, हामीले पत्ता लगायौं कि hsfc ले उत्कृष्ट नतिजाहरू देखाउँछ जब 1:2 वर्गको गैर-प्राथमिकता ब्याच/निष्क्रिय ट्राफिक मिनियन मेसिनहरूमा एक निश्चित फ्री लेन भन्दा बढीमा सीमित हुन्छ। अन्यथा, गैर-प्राथमिकता ट्राफिकले उत्पादन कार्यहरूको विलम्बतामा धेरै प्रभाव पार्छ। miniond ले प्रत्येक सेकेन्डमा नि:शुल्क ब्यान्डविथको हालको मात्रा निर्धारण गर्दछ, दिइएको minion को सबै प्रोड-टास्कहरूको औसत ट्राफिक खपत मापन गर्दछ। र यसलाई नेटवर्क इन्टरफेस ब्यान्डविथबाट घटाउँदै एक सानो मार्जिन संग, अर्थात्

ब्यान्डहरू आगमन र बाहिर जाने ट्राफिकको लागि स्वतन्त्र रूपमा परिभाषित छन्। र नयाँ मानहरू अनुसार, miniond ले गैर-प्राथमिकता वर्ग सीमा १:२ लाई पुन: कन्फिगर गर्दछ।

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

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

अतिरिक्त लाइनहरू फेरि हटाएपछि, हामी पूर्ण सेवा नामको अन्त्यमा टास्क आइसोलेसन क्लास थपेर हाम्रो सेवा नामहरू फ्ल्याटर लेख्न सक्छौं: web.front.prod, catalog.music.batch, transformer.music.idle.

र अब, सेवाको नाम हेर्दै, हामीले यो के कार्य गर्दछ भनेर मात्र बुझ्दैनौं, तर यसको अलगाव वर्ग, जसको अर्थ यसको आलोचनात्मकता, इत्यादि हो।

सबै कुरा महान छ, तर त्यहाँ एक तितो सत्य छ। एउटै मेसिनमा चल्ने कार्यहरूलाई पूर्ण रूपमा अलग गर्न असम्भव छ।

हामीले के हासिल गर्न व्यवस्थित गर्यौं: यदि ब्याच गहन रूपमा खपत हुन्छ मात्र CPU स्रोतहरू, त्यसपछि निर्मित लिनक्स CPU अनुसूचकले आफ्नो काम धेरै राम्रोसँग गर्छ, र प्रोड कार्यमा व्यावहारिक रूपमा कुनै प्रभाव छैन। तर यदि यो ब्याच कार्य सक्रिय रूपमा मेमोरी संग काम गर्न थाल्छ, त्यसपछि आपसी प्रभाव पहिले देखि नै देखिन्छ। यो हुन्छ किनभने प्रोड कार्य प्रोसेसरको मेमोरी क्यासहरूको "धोइयो" हुन्छ - नतिजाको रूपमा, क्यास मिसहरू बढ्छ, र प्रोसेसरले प्रोड कार्यलाई अझ बिस्तारै प्रशोधन गर्दछ। यस्तो ब्याच कार्यले हाम्रो विशिष्ट प्रोड कन्टेनरको विलम्बता 10% बढाउन सक्छ।

आधुनिक नेटवर्क कार्डहरूमा प्याकेटहरूको आन्तरिक लाम रहेको तथ्यको कारणले ट्राफिकलाई अलग गर्न अझ गाह्रो छ। यदि ब्याच टास्कबाट प्याकेट पहिले त्यहाँ पुग्छ, त्यसपछि यो केबलमा प्रसारण हुने पहिलो हुनेछ, र यसको बारेमा केहि गर्न सकिँदैन।

थप रूपमा, हामीले अहिलेसम्म TCP ट्राफिकलाई प्राथमिकता दिने समस्या समाधान गर्न व्यवस्थित गरेका छौं: hsfc दृष्टिकोणले UDP का लागि काम गर्दैन। र TCP ट्राफिकको मामलामा पनि, यदि ब्याच कार्यले धेरै ट्राफिक उत्पन्न गर्छ भने, यसले उत्पादन कार्यको ढिलाइमा लगभग 10% वृद्धि पनि दिन्छ।

दोष सहिष्णुता

एक-क्लाउड विकास गर्दा एक लक्ष्य Odnoklassniki को दोष सहिष्णुता सुधार गर्न थियो। त्यसकारण, अर्को म असफलता र दुर्घटनाहरूको सम्भावित परिदृश्यहरू थप विस्तारमा विचार गर्न चाहन्छु। एक साधारण परिदृश्य संग सुरु गरौं - एक कन्टेनर विफलता।

कन्टेनर आफै धेरै तरिकामा असफल हुन सक्छ। यो manifest मा केहि प्रकारको प्रयोग, बग वा त्रुटि हुन सक्छ, जसको कारण prod कार्यले manifest मा संकेत गरिएको भन्दा बढी स्रोतहरू खपत गर्न थाल्छ। हामीसँग एउटा केस थियो: एक विकासकर्ताले एउटा जटिल एल्गोरिदम लागू गर्‍यो, यसलाई धेरै पटक पुन: काम गर्‍यो, आफैंलाई अतिविचार गर्‍यो र यति भ्रमित भयो कि अन्ततः समस्या धेरै गैर-तुच्छ तरिकामा लुप भयो। र प्रोड कार्यको समान मिनियनहरूमा अन्य सबै भन्दा उच्च प्राथमिकता भएकोले, यसले सबै उपलब्ध प्रोसेसर स्रोतहरू उपभोग गर्न थाल्यो। यस अवस्थामा, अलगाव, वा बरु CPU समय कोटा, दिन बचत भयो। यदि कुनै कार्यलाई कोटा छुट्याइयो भने, कार्यले बढी खपत गर्दैन। त्यसकारण, एउटै मेसिनमा चल्ने ब्याच र अन्य उत्पादन कार्यहरूले केहि पनि याद गरेन।

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

यदि सम्पूर्ण मिनियन अनुपलब्ध छ भने तपाइँ के गर्न सक्नुहुन्छ?

जाहिर छ, अर्को मेसिनमा कन्टेनर चलाउनुहोस्। यहाँ चाखलाग्दो भाग भनेको कन्टेनरमा तोकिएको IP ठेगाना(es) लाई के हुन्छ।

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

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

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

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

पछि, यी ठेगानाहरू परिवर्तन गर्दैनन्: तिनीहरू एक पटक तोकिएका छन् र उत्पादनमा सेवाको जीवनभर अवस्थित रहन्छन्। IP ठेगानाहरू नेटवर्कमा कन्टेनरहरू पछ्याउँछन्। यदि कन्टेनर अर्को मिनियनमा स्थानान्तरण गरिएको छ भने, ठेगानाले यसलाई पछ्याउनेछ।

तसर्थ, IP ठेगानाहरूको सूचीमा सेवाको नामको म्यापिङ एकदमै विरलै परिवर्तन हुन्छ। यदि तपाईंले लेखको सुरुमा उल्लेख गरेका सेवा उदाहरणहरूको नामहरू फेरि हेर्नुभयो भने (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), हामी नोटिस गर्नेछौं कि तिनीहरू DNS मा प्रयोग गरिएका FQDN सँग मिल्दोजुल्दो छन्। यो सही छ, सेवा उदाहरणहरूको नामहरू तिनीहरूको IP ठेगानाहरूमा नक्सा गर्न, हामी DNS प्रोटोकल प्रयोग गर्छौं। यसबाहेक, यो DNS सबै कन्टेनरहरूको सबै आरक्षित आईपी ठेगानाहरू फर्काउँछ - दुबै चलिरहेको र रोकिएको (तीन प्रतिकृतिहरू प्रयोग गरिन्छ भनौं, र हामीसँग त्यहाँ पाँचवटा ठेगानाहरू आरक्षित छन् - सबै पाँच फर्काइनेछ)। ग्राहकहरू, यो जानकारी प्राप्त गरिसकेपछि, सबै पाँच प्रतिकृतिहरूसँग जडान स्थापित गर्ने प्रयास गर्नेछन् - र यसरी काम गरिरहेकाहरूलाई निर्धारण गर्नेछन्। उपलब्धता निर्धारण गर्नको लागि यो विकल्प धेरै भरपर्दो छ; यसले DNS वा सेवा खोजलाई समावेश गर्दैन, जसको मतलब यी प्रणालीहरूको जानकारीको सान्दर्भिकता र त्रुटि सहिष्णुता सुनिश्चित गर्न समाधान गर्न कुनै कठिन समस्याहरू छैनन्। यसबाहेक, महत्वपूर्ण सेवाहरूमा जसमा सम्पूर्ण पोर्टलको सञ्चालन निर्भर हुन्छ, हामी DNS प्रयोग गर्न सक्दैनौं, तर कन्फिगरेसनमा IP ठेगानाहरू प्रविष्ट गर्नुहोस्।

कन्टेनरहरू पछाडि यस्तो IP स्थानान्तरण लागू गर्नु गैर-तुच्छ हुन सक्छ - र हामी निम्न उदाहरणको साथ यसले कसरी काम गर्छ भनेर हेर्नेछौं:

मानौं एक-क्लाउड मास्टरले minion M1 लाई चलाउन आदेश दिन्छ 1.ok-web.group1.web.front.prod ठेगाना 1.1.1.1 संग। Minion मा काम गर्नुहुन्छ बर्ड, जसले यो ठेगानालाई विशेष सर्भरहरूमा विज्ञापन गर्दछ मार्ग रिफ्लेक्टर। पछिल्लोसँग नेटवर्क हार्डवेयरसँग BGP सत्र छ, जसमा M1.1.1.1 मा ठेगाना 1 को मार्ग अनुवाद गरिएको छ। M1 ले लिनक्स प्रयोग गरेर कन्टेनर भित्र प्याकेट मार्गहरू। त्यहाँ तीन मार्ग रिफ्लेक्टर सर्भरहरू छन्, किनकि यो एक-क्लाउड पूर्वाधारको एक धेरै महत्त्वपूर्ण भाग हो - तिनीहरू बिना, एक-क्लाउडमा नेटवर्कले काम गर्दैन। हामी तिनीहरूलाई विभिन्न र्याकहरूमा राख्छौं, यदि सम्भव भएमा डाटा केन्द्रको विभिन्न कोठाहरूमा अवस्थित छ, एकै समयमा तीनवटा असफल हुने सम्भावना कम गर्न।

अब मानौं कि एक-क्लाउड मास्टर र M1 मिनियन बीचको जडान हराएको छ। एक-क्लाउड मास्टरले अब M1 पूर्ण रूपमा असफल भएको धारणामा कार्य गर्नेछ। त्यो हो, यसले M2 minion लाई सुरुवात गर्न आदेश दिनेछ web.group1.web.front.prod एउटै ठेगाना 1.1.1.1 संग। अब हामीसँग 1.1.1.1 नेटवर्कमा दुई विवादित मार्गहरू छन्: M1 र M2 मा। त्यस्ता विवादहरू समाधान गर्नको लागि, हामी बहु निकास विभेदक प्रयोग गर्छौं, जुन BGP घोषणामा निर्दिष्ट गरिएको छ। यो विज्ञापित मार्गको वजन देखाउने नम्बर हो। विवादित मार्गहरू मध्ये, कम MED मान भएको मार्ग चयन गरिनेछ। एक-क्लाउड मास्टरले कन्टेनर IP ठेगानाहरूको अभिन्न भागको रूपमा MED लाई समर्थन गर्दछ। पहिलो पटक, ठेगाना पर्याप्त ठूलो MED = 1 संग लेखिएको छ। यस्तो आपतकालीन कन्टेनर स्थानान्तरणको अवस्थामा, मास्टरले MED लाई घटाउँछ, र M000 ले पहिले नै MED = सँग ठेगाना 000 विज्ञापन गर्न आदेश प्राप्त गर्नेछ। 2। M1.1.1.1 मा चलिरहेको उदाहरण यस मामला मा कुनै जडान छैन मा रहनेछ, र उसको अर्को भाग्य हामीलाई थोरै चासो छ जब सम्म मालिक संग जडान पुनर्स्थापित हुन्छ, जब उहाँ पुरानो टेक जस्तै रोकिनेछ।

दुर्घटनाहरू

सबै डाटा सेन्टर प्रबन्धन प्रणालीहरूले सधैं सानो विफलताहरू स्वीकार्य रूपमा ह्यान्डल गर्छन्। कन्टेनर ओभरफ्लो लगभग सबै ठाउँमा सामान्य हो।

डेटा सेन्टरको एक वा बढी कोठामा पावर फेल हुने जस्ता आपत्‌कालीन अवस्थालाई कसरी व्यवस्थापन गर्छौं भनी हेरौं।

डेटा केन्द्र व्यवस्थापन प्रणालीको लागि दुर्घटनाको अर्थ के हो? सबैभन्दा पहिले, यो धेरै मेशिनहरूको एक-पटकको ठूलो विफलता हो, र नियन्त्रण प्रणालीले एकै समयमा धेरै कन्टेनरहरू माइग्रेट गर्न आवश्यक छ। तर यदि प्रकोप धेरै ठूलो मात्रामा छ भने, यो हुन सक्छ कि सबै कार्यहरू अन्य minions लाई पुन: आवंटित गर्न सकिँदैन, किनभने डाटा केन्द्रको स्रोत क्षमता लोडको 100% भन्दा कम हुन्छ।

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

तपाईं यो सबै बारेमा के गर्न सक्नुहुन्छ?

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

हामी परिचित सेवाहरूको पदानुक्रमलाई फेरि हेरौं र कुन कार्यहरू हामीले पहिले चलाउन चाहन्छौं भनेर निर्णय गर्ने प्रयास गरौं।

निस्सन्देह, यी प्रक्रियाहरू हुन् जुन प्रत्यक्ष रूपमा प्रयोगकर्ता अनुरोधहरू प्रशोधनमा संलग्न छन्, अर्थात् प्रोड। हामी यो संग संकेत गर्दछौं नियुक्ति प्राथमिकता - लाममा तोक्न सकिने नम्बर। यदि लाममा उच्च प्राथमिकता छ भने, यसको सेवाहरू पहिले राखिन्छन्।

उत्पादनमा हामी उच्च प्राथमिकताहरू प्रदान गर्छौं, ०; ब्याच मा - अलि कम, 0; निष्क्रियमा - अझ कम, 100। प्राथमिकताहरू क्रमबद्ध रूपमा लागू गरिन्छ। पदानुक्रममा तल्लो तहका सबै कार्यहरूलाई समान प्राथमिकता दिइनेछ। यदि हामी प्रोड भित्र क्यासहरू फ्रन्टएन्डहरू अघि लन्च गर्न चाहन्छौं भने, हामी क्यास = 200 र अगाडि सबक्युहरू = 0 लाई प्राथमिकताहरू तोक्छौं। यदि, उदाहरणका लागि, हामी मुख्य पोर्टललाई अगाडिबाट सुरु गर्न चाहन्छौं, र संगीत अगाडि मात्र। त्यसोभए, त्यसपछि हामी पछिल्लोलाई कम प्राथमिकता तोक्न सक्छौं - 1।

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

प्लेसमेन्ट प्राथमिकताको विपरीत, हामी सबै ब्याच कार्यहरू अन्धाधुन्ध रूपमा त्याग गर्न सक्दैनौं; तिनीहरूमध्ये केही पोर्टल सञ्चालनको लागि महत्त्वपूर्ण छन्। त्यसैले, हामीले छुट्टै हाइलाइट गरेका छौं पूर्वनिर्धारित प्राथमिकता कार्यहरू। राखिएको बेला, उच्च प्राथमिकताको कार्यले प्रीम्प्ट गर्न सक्छ, अर्थात् रोक्नुहोस्, कम प्राथमिकताको कार्य यदि त्यहाँ कुनै नि:शुल्क मिनियनहरू छैनन् भने। यस अवस्थामा, कम प्राथमिकता भएको कार्य सम्भवतः स्थानहीन रहनेछ, अर्थात् त्यहाँ पर्याप्त नि:शुल्क स्रोतहरूसँग यसको लागि उपयुक्त मिनियन हुनेछैन।

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

सम्पूर्ण DC दुर्घटनाहरू

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

र यो हामी कसैलाई #alive ट्वीट गर्नबाट रोक्नको लागि गर्छौं।

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

यो दृष्टिकोणले शारीरिक विफलताबाट मात्र सुरक्षा गर्दैन, तर अपरेटर त्रुटिबाट पनि सुरक्षा गर्न सक्छ।

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

परिणामहरू

एक-क्लाउडको विशिष्ट विशेषताहरू:

• सेवा र कन्टेनरहरूको लागि श्रेणीबद्ध र दृश्य नामकरण योजना, जसले तपाईंलाई कार्य के हो, यो केसँग सम्बन्धित छ र यसले कसरी काम गर्छ र यसको लागि को जिम्मेवार छ भनेर धेरै चाँडै पत्ता लगाउन अनुमति दिन्छ।
• हामी हाम्रो लागू उत्पादन र ब्याच संयोजन गर्ने प्रविधिमेसिन साझेदारीको दक्षता सुधार गर्न minions मा कार्यहरू। cpuset को सट्टा हामी CPU कोटा, शेयर, CPU अनुसूचक नीतिहरू र Linux QoS प्रयोग गर्छौं।
• एउटै मेसिनमा चलिरहेका कन्टेनरहरूलाई पूर्ण रूपमा अलग गर्न सम्भव थिएन, तर तिनीहरूको आपसी प्रभाव 20% भित्र रहन्छ।
• पदानुक्रममा सेवाहरू व्यवस्थित गर्नाले स्वचालित विपद् रिकभरी प्रयोग गर्न मद्दत गर्दछ नियुक्ति र पूर्वनिर्धारित प्राथमिकताहरू.

FAQ

हामीले किन तयार समाधान निकालेनौं?

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

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

अन्तिम पङ्क्तिहरू पढ्नेहरूलाई, तपाईंको धैर्य र ध्यानको लागि धन्यवाद!

स्रोत: www.habr.com