कंटेनर बादलों का भविष्य हैं

ओला, हेब्रोसोसिटी!

परिचय

यह रिपोर्ट मूल रूप से 24-25 अगस्त, 2013 को एस्टोनिया के टालिन में आयोजित FastVPS ROCK IT 2013 के सम्मेलन में भाषण के लिए तैयार की गई थी।

शायद किसी ने इसे व्यक्तिगत रूप से सुना (धन्यवाद!), लेकिन मेरा सुझाव है कि आप इसे वैसे भी पढ़ते हैं, क्योंकि यह प्रकाशन अधिक विस्तृत है और रिपोर्ट (मुस्कान) से छोड़ा गया अधिक विवरण मानता है

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

आभासी वातावरण बनाने के लिए लिनक्स खुला स्रोत समाधान

आज की कहानी के नायकों से मिलिए!





नाम से:

• केवीएम
• एक्सईएन
• Linux VServer
• OpenVZ
• LXC (लिनक्स कंटेनर)

तालिका: लिनक्स में आभासी वातावरण को लागू करने के लिए मौजूदा प्रौद्योगिकियों की तुलना



मैं यह नोट करना चाहूंगा कि ओरेकल वर्चुअलबॉक्स को जानबूझकर तालिका में शामिल नहीं किया गया था, क्योंकि यह पूरी तरह से खुला नहीं है, और लेख में हम केवल खुली प्रौद्योगिकियों पर विचार करते हैं।

यह तालिका यह निष्कर्ष निकालना आसान बनाती है कि आज औद्योगिक उपयोग के लिए केवल तीन प्रौद्योगिकियां तैयार हैं: KVM, Xen और OpenVZ। इसके अलावा, LXC तकनीक बहुत सक्रिय गति से विकसित हो रही है, और इस कारण से हमें बस इस पर विचार करना चाहिए। बदले में सभी चार प्रौद्योगिकियां, अलगाव के लिए दो दृष्टिकोणों को लागू करती हैं - पूर्ण वर्चुअलाइजेशन और कंटेनरीकरण, जिसके बारे में हम बात करेंगे।

पूर्ण वर्चुअलाइजेशन

आइए विशुद्ध रूप से सैद्धांतिक विवरण से दूर जाएं और KVM के उदाहरण पर एक दृश्य आरेख देखें।



जैसा कि आप देख सकते हैं, हमारे पास तीन स्तर हैं:

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

यहाँ सभी इंटरैक्शन बहुत पारदर्शी है - बेस लिनक्स कर्नेल (HWN) हार्डवेयर (प्रोसेसर, मेमोरी, I / O) के साथ इंटरैक्ट करता है, और बदले में काम करने की क्षमता प्रदान करता है जिसमें पूर्ण लिनक्स, FreeBSD, या यहाँ तक कि विंडोज। यह ध्यान देने योग्य है कि ये काफी सामान्य प्रक्रियाएं नहीं हैं; वर्चुअल मशीन का संचालन कर्नेल मॉड्यूल (KVM) के माध्यम से सुनिश्चित किया जाता है, जो क्लाइंट ऑपरेटिंग सिस्टम से HWN में सिस्टम कॉल का अनुवाद करता है। कार्य के इस विवरण को पूरी तरह से सही नहीं माना जा सकता है, लेकिन यह पूरी तरह से इस दृष्टिकोण का अर्थ बताता है। ध्यान देने वाली सबसे महत्वपूर्ण बात यह है कि क्लाइंट ओएस कॉल से एचओएनटी कॉल में विशेष प्रोसेसर प्रौद्योगिकी (एएमडी-वी, इंटेल वीटी) का उपयोग करके किया जाता है।

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

पूर्ण वर्चुअलाइजेशन को लागू करने की लागत

हाल ही में आईबीएम के अध्ययनों के अनुसार, ओवरहेड (यह वर्चुअल वातावरण के अंदर एक एप्लिकेशन के प्रदर्शन और सभी में वर्चुअलाइजेशन का उपयोग किए बिना एक ही आवेदन के बीच अंतर है), केवीएम I / O तकनीक SUSE लिनक्स एंटरप्राइज सर्वर 11 सर्विस 3 पर परीक्षण किए जाने पर लगभग 15% है।

जर्नल ऑफ फिजिक्स: कॉन्फ्रेंस 219 (2010) में एक बहुत ही दिलचस्प परीक्षण भी प्रस्तुत किया गया है, जिसमें संख्याओं की घोषणा की गई है: प्रोसेसर के लिए 3-4% ओवरहेड, और डिस्क I / O के लिए 20-30%।

उसी समय, 2013 रेडहैट प्रस्तुति ने 12% का आंकड़ा (यानी वर्चुअलाइजेशन के बिना चल रहे कॉन्फ़िगरेशन के प्रदर्शन का 88%) की घोषणा की।

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

कन्टेनीकरण

वही करें, चित्रण का उपयोग करें।



मैं एक बार आरक्षण देना चाहूंगा कि नीचे दी गई सभी बातें OpenVZ और LXC दोनों के लिए सही हैं। ये प्रौद्योगिकियां बहुत, समान हैं और बेहद करीबी रिश्तेदार हैं (मैं अपने अगले प्रकाशन में इस विषय का खुलासा करने की कोशिश करूंगा)।

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

सबसे पहले, यह चिरोट का एक संशोधित एनालॉग है (संशोधनों में मुख्य रूप से चिंता संरक्षण है, ताकि चेरोट के पर्यावरण से रूट फाइल सिस्टम से बचना संभव न हो), जो कि हम सभी से परिचित है, यह आपको एक ही फाइल सिस्टम के भीतर एक दूसरे से पृथक पदानुक्रम बनाने की अनुमति देता है। लेकिन चेरोट अनुमति नहीं देता है, उदाहरण के लिए, अपनी खुद की init प्रक्रिया शुरू करने के लिए (pid 1, चूंकि PID डेटा के साथ एक init प्रक्रिया पहले से ही HWN पर मौजूद है), और यह एक अनिवार्य आवश्यकता है अगर हम कंटेनर में पूरी तरह से पृथक क्लाइंट OS चाहते हैं। इसके लिए, पीआईडी ​​नामस्थान तंत्र का उपयोग किया जाता है, जो प्रत्येक चेरोट वातावरण के अंदर एक प्रक्रिया पहचानकर्ता प्रणाली को पूरी तरह से स्वतंत्र बनाता है, जहां हम पीआईडी ​​1 के साथ अपनी प्रक्रिया कर सकते हैं, भले ही यह प्रक्रिया पहले से ही सर्वर पर चल रही हो। सामान्य मामले में, हम सैकड़ों या हजारों व्यक्तिगत कंटेनर बना सकते हैं जो एक दूसरे के साथ किसी भी तरह से जुड़े नहीं हैं।

तो मेमोरी, सीपीयू और हार्ड ड्राइव कैसे सीमित हैं? वे cgroups तंत्र द्वारा भी सीमित हैं, जो, केवीएम प्रौद्योगिकी में बिल्कुल समान उद्देश्यों के लिए भी उपयोग किया जाता है।

कंटेनरीकरण लागत

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

वर्चुअलाइजेशन बनाम वर्चुअलाइजेशन

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

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

मैंने कुछ समय के लिए सोचा कि इसे कैसे प्राप्त किया जाए और मैं एक अद्भुत दस्तावेज के साथ आया जिसमें KVM, XEN और OpenVZ / PCS का परीक्षण Intel - vConsolidate, साथ ही साथ एक मानक LAMP परीक्षण द्वारा विकसित परीक्षण पद्धति के आधार पर किया गया है, जो आपको घर पर सभी परिणामों की जांच करने की अनुमति देता है। उनकी सच्चाई सुनिश्चित करें।



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

इसलिए, मैं एक और अधिक समझने योग्य LAMP परीक्षण प्रस्तावित करता हूं, समान दस्तावेज़ Parallels से, यह LAMP अनुप्रयोग के प्रदर्शन का परीक्षण करता है जो चल रहे आभासी वातावरणों की संख्या पर निर्भर करता है:



सब कुछ बहुत स्पष्ट है और स्पष्ट रूप से दिखाई दे रहा है LAMP एप्लिकेशन द्वारा किए गए लेनदेन की कुल संख्या में लगभग 2 गुना वृद्धि हुई है! इससे ज्यादा आप क्या पूछ सकते हैं? :)

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

मुझे आशा है कि मैं आपको यह समझाने में सक्षम था कि कंटेनरीकरण पर आधारित समाधान आपको लोहे से लगभग सभी संभावित क्षमता को निचोड़ने की अनुमति देता है

कंटेनरीकरण बादलों का भविष्य है!

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

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

यह भी ध्यान देने योग्य है कि दुनिया में सबसे बड़ा कंप्यूटिंग सिस्टम - Google , Yandex , Heroku, और कई अन्य लोगों के स्वयं के बादल LXC तकनीक का उपयोग करके बनाए गए हैं, जो एक बार फिर क्लाउड कंप्यूटिंग में कंटेनरीकरण का लाभ साबित करता है और वास्तविक कंपनियों के उदाहरण पर दिखाता है।

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

आगामी प्रकाशनों में, हम OpenVZ और LXC प्रौद्योगिकियों पर ध्यान केंद्रित करेंगे, और हम उनका तुलनात्मक विश्लेषण भी करेंगे :)

अपडेट, प्रकाशनों की एक श्रृंखला जारी है:

• लिनक्स पर विस्तार से कंटेनरकरण - LXC और OpenVZ। भाग 1

मैं एलएक्ससी तकनीक के विशेष रूप से जटिल पहलुओं को समझाने के लिए वैसिली एवेरिन (समानताएं) को भी धन्यवाद देना चाहूंगा।

साभार, पावेल ओडिन्टसोव
सीटीओ फास्टवीपीएस एलएलसी