वर्चुअलाइजेशन x86 का सामान्य सिद्धांत और पुरातत्व

परिचय

लेखकों की टीम

एंटोन झेनकोव ( एंटोनवर्थ , क्लाउडआर्किटेक्ट.सीसी ) द्वारा पोस्ट
सह-लेखक: ग्रिगोरी प्रिलुखिन , एवगेनी परफेनोव

सामान्य वर्चुअलाइजेशन अवधारणाओं

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

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

वर्चुअलाइजेशन - संसाधनों / डेटा तक पहुँचने की एक सार्वभौमिक मानकीकृत विधि के पीछे एक विशिष्ट कार्यान्वयन को छिपाना।

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

POZOR!

Uwaga! आक्टंग! Pozor!

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

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

आइए हम पूरी तरह से अमूर्त अवधारणाओं से अपने प्यारे कंप्यूटरों के बारे में अधिक परिचितों तक लौटें।

भंडारण वर्चुअलाइजेशन

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

एफएस -> एलबीए -> सीएचएस

एक एकल हार्ड मैग्नेटिक डिस्क पर स्टोरेज सिस्टम का सबसे सरल मामला लें। डेटा के साथ काम करने के लिए सामान्य प्रारूप वह फाइलें हैं जो तार्किक ड्राइव पर हैं। फ़ाइल को खोला, पढ़ा, बंद किया जा सकता है। लेकिन फ़ाइल के रूप में ऐसी वस्तु बस शारीरिक रूप से मौजूद नहीं होती है - केवल "ड्राइव: \ folder1 \ folder2 \ file" फॉर्म की एड्रेसिंग पद्धति का उपयोग करके कुछ डेटा ब्लॉक तक पहुंचने का एक तरीका है। यानी हम वर्चुअलाइजेशन की पहली परत से मिलते हैं - मानव और समझने योग्य मनुष्यों से, हम सब कुछ सिस्टम-समझने योग्य पते में अनुवाद करते हैं। मेटाडेटा तालिकाओं में, फ़ाइल सिस्टम ड्राइवर यह देखता है कि किस तरह के डेटा ब्लॉक हैं, और हमें तार्किक ब्लॉक एड्रेसिंग (LBA) सिस्टम में पता मिलता है। एलबीए प्रणाली में, ब्लॉकों का एक निश्चित आकार होता है और एक दूसरे का रैखिक रूप से अनुसरण करते हैं, अर्थात। किसी तरह इसे चुंबकीय टेप पर डेटा संग्रहीत करने के साथ करना पड़ सकता है, लेकिन हार्ड डिस्क किसी तरह पूरी तरह से अलग है! और यहां हम वर्चुअलाइजेशन की दूसरी परत पर जाते हैं - सीएचएस (सिलेंडर / हेड / सेक्टर) को संबोधित एलबीए का अनुवाद।



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

RAID

वर्चुअलाइजेशन की अगली परत, जिसे बहुत से लोग गलती से वर्चुअलाइजेशन नहीं मानते हैं, वह है RAID (सस्ती / स्वतंत्र डिस्क का बेमानी सरणी)।

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

RAID डिस्क वर्चुअलाइजेशन है।

इसके अलावा, RAID नियंत्रक केवल कई भौतिक डिस्क से एक बड़ी वर्चुअल डिस्क नहीं बनाता है, लेकिन वर्चुअलाइजेशन की एक और परत जोड़कर उनमें से एक मनमाना संख्या बना सकता है।

वर्चुअलाइजेशन देखें

अगले प्रकार का वर्चुअलाइजेशन, जिसका हम में से कई लोग लगभग हर दिन उपयोग करते हैं, लेकिन इसे वर्चुअलाइजेशन नहीं मानते हैं, यह डेस्कटॉप का रिमोट कनेक्शन है।

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

एक्स 86 वर्चुअलाइजेशन का परिचय

प्रोसेसर का इतिहास और अवलोकन

कार्यक्रम का निष्पादन

एक विशेष प्रोग्रामिंग कोर्स में पहले पाठ में, व्लादिमीर डेनिसोविच लिलीयुख (उसके लिए शांति में) ने छात्रों से कहा: कंप्यूटर, इसके नाम के बावजूद, गिनती नहीं कर सकता, यह दिखावा कर सकता है कि यह गिनती कर सकता है। लेकिन अगर कोई बत्तख जैसा दिखता है, तो बत्तख की तरह चलता है और बत्तख की तरह झपटता है, व्यावहारिक दृष्टि से यह एक बत्तख है।

आइए इसे आगे के व्यावहारिक उपयोग के लिए याद रखने की कोशिश करें।

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

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

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

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

मल्टीटास्किंग

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

छद्म-मल्टीटास्किंग तब प्रकट होता है जब किसी कार्य को सीधे स्विच करते समय निष्पादित किया जाता है।

भविष्य में, एक सहकारी (गैर-प्रीमेप्टिव मल्टीटास्किंग) प्रकट होता है - निष्पादन योग्य कार्य स्वयं समझता है कि इसे अब प्रोसेसर संसाधनों की आवश्यकता नहीं है और यह किसी और को नियंत्रण देता है। लेकिन यह सब पर्याप्त नहीं है।

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

वास्तविक मोड

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

यह प्रोसेसर के इंटेल x86 परिवार के संचालन का प्रारंभिक मोड है।

संरक्षित मोड

1982 में, इंटेल 80286 प्रोसेसर (इसके बाद केवल 286) में एक नवाचार दिखाई दिया - ऑपरेशन का एक संरक्षित मोड, जो स्मृति के साथ काम के संगठन में नवाचारों के साथ लाया (उदाहरण के लिए, मेमोरी सेगमेंट के प्रकारों का आवंटन - कोड, डेटा, स्टैक)। लेकिन सबसे महत्वपूर्ण बात यह है कि 286 प्रोसेसर को x86 दुनिया में लाया गया है जो सुरक्षा के छल्ले की अवधारणा है, जिसका उपयोग हम अभी भी करते हैं।

सुरक्षा छल्लों की अवधारणा मूल रूप से GE645 मेनफ्रेम (1967) के लिए मल्टीिक्स OS में आंशिक रूप से सॉफ्टवेयर कार्यान्वयन के साथ दिखाई देती है, और 1970 में हनीवेल 6180 सिस्टम में पूरी तरह से हार्डवेयर।



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

हनीवेल 6180 के बहुत पहले पूर्ण कार्यान्वयन में, 8 सुरक्षा रिंगों को लागू किया गया था, लेकिन इंटेल ने सर्किट को 4 को सरल बनाने का निर्णय लिया, जिनमें से व्यवहार में ओएस निर्माताओं ने केवल दो का उपयोग करना शुरू किया - शून्य और तीसरा।

32 बिट

1985 में, x86 लाइन में एक और बेहद महत्वपूर्ण प्रोसेसर जारी किया गया था - 80386 (इसके बाद 386), जिसने 32-बिट मेमोरी एड्रेसिंग को लागू किया और 32-बिट निर्देशों का उपयोग किया। और हां, मेमोरी वर्चुअलाइजेशन। जैसा कि पहले ही उल्लेख किया गया है, वर्चुअलाइजेशन कृत्रिम "आभासी" संसाधनों के प्रावधान के माध्यम से वास्तविक कार्यान्वयन का छिपाव है। इस मामले में, हम मेमोरी एड्रेसिंग के बारे में बात कर रहे हैं। मेमोरी सेगमेंट का अपना पता होता है, जिसका मेमोरी सेल के वास्तविक स्थान से कोई लेना-देना नहीं होता है।
प्रोसेसर मांग में इतना बदल गया कि 2007 से पहले इसका उत्पादन किया गया।
इंटेल के संदर्भ में वास्तुकला को IA32 कहा जाता है।

64 बिट

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

एएमडी ने वास्तुकला के अपने संस्करण को पेश किया, जिसे एएमडी 64 कहा जाता है। इंटेल में, उन्होंने IA64 प्लेटफॉर्म (Intel Architecture 64) की आशा की, जिसे हम इटेनियम नाम से भी जानते हैं। हालांकि, बाजार ने बहुत उत्साह के बिना इस वास्तुकला से मुलाकात की, और परिणामस्वरूप, इंटेल को AMD64 निर्देशों के लिए अपने स्वयं के समर्थन को लागू करने के लिए मजबूर किया गया, जिसे पहले EM64T कहा जाता था, और फिर बस Intel 64।

अंततः, हम सभी इस वास्तुकला को AMD64, x86-64, x86_64, या कभी-कभी x64 के रूप में जानते हैं।

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

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

UMA

X86 मल्टीप्रोसेसर सिस्टम ने UMA (यूनिफ़ॉर्म मेमोरी एक्सेस) मोड के साथ काम करना शुरू किया, जिसमें किसी भी प्रोसेसर (किसी मेमोरी सेल तक पहुंचने में देरी) से दूरी समान है। इंटेल प्रोसेसर में, 54xx पीढ़ी (हार्परटाउन) तक मल्टी-कोर प्रोसेसर की उपस्थिति के बाद भी कार्य की यह योजना संरक्षित थी। 55xx (Nehalem) जेनरेशन से शुरू होकर, प्रोसेसर NUMA आर्किटेक्चर में बदल गए हैं।

निष्पादन तर्क के दृष्टिकोण से, यह अतिरिक्त हार्डवेयर थ्रेड्स की उपस्थिति है, जिस पर आप समानांतर में निष्पादन के लिए कोड स्ट्रीम असाइन कर सकते हैं।

NUMA

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

2019 के लिए इंटेल एक्सॉन स्केलेबल वी 2 प्रोसेसर के लिए, आंतरिक वास्तुकला अभी भी सॉकेट के भीतर यूएमए बनी हुई है, अन्य सॉकेट्स के लिए एनयूएमए में बदल रही है (हालांकि वास्तव में नहीं है, और यह केवल होने का दिखावा करता है)। सबसे पुराने UMA Xeon के समय में भी AMD के Opteron प्रोसेसर में NUMA आर्किटेक्चर था, और तब NUMA रोम की अंतिम पीढ़ी तक सॉकेट के अंदर भी हो गया, जिसमें वे NUMA = सॉकेट में वापस आ गए।

वर्चुअल मशीन

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

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

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

सॉफ्टवेयर वर्चुअलाइजेशन

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

लेकिन सब कुछ काफी सरल रूप से तय किया गया था: चूंकि हाइपरविजर के लिए अतिथि ओएस पूरी प्रत्यक्ष पहुंच के साथ मेमोरी पेजों का एक सेट है, और वर्चुअल प्रोसेसर सिर्फ कमांडों की एक कतार है, उन्हें फिर से क्यों नहीं लिखा जाता है? सही पर मक्खी, हाइपरविजर वर्चुअल प्रोसेसर पर निष्पादन के लिए निर्देशों की कतार से बाहर फेंक देता है, सभी निर्देशों में शून्य-रिंग विशेषाधिकारों की आवश्यकता होती है, उन्हें कम विशेषाधिकार प्राप्त लोगों की जगह। लेकिन इन निर्देशों का परिणाम ठीक उसी तरह से प्रस्तुत किया गया है जैसे कि अतिथि ओएस शून्य रिंग में था। इस प्रकार, आप अतिथि ओएस की पूर्ण अनुपस्थिति तक कुछ भी वर्चुअलाइज कर सकते हैं।
इस दृष्टिकोण को विकास टीम द्वारा 1999 में VMware वर्कस्टेशन उत्पाद में लागू किया गया था, और फिर 2001 में GSX सर्वर हाइपरविजर्स (दूसरा प्रकार, वर्कस्टेशन की तरह) और ESX (पहला प्रकार)।

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

Paravirtualization एक बहुत ही सरल अवधारणा है, जो मानता है कि अतिथि OS जानता है कि यह एक वर्चुअल मशीन में है, और कुछ सिस्टम फ़ंक्शन के लिए होस्ट OS तक पहुंचने का तरीका जानता है। — , .
x86 2003 Linux Xen.

, . , VMware ESXi SCSI PVSCSI, , . ( VMware Tools), Linux (open-vm-tools).

, .

— Intel VT-x AMD-V , , . .

2 (hosted)

— , . . , , , . . , . , - , .

: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

1 (bare-metal)

, . , , -. -, . . x86 VMware ESX, 1+. “” VMware ESXi — ESX, RHEL.

ESXi. API , VMkernel. , , . , .



: “” , HCL (hardware compatibility list).

1+ ( )

( 1+, 1a, 1.5) , (parent partition Microsoft Hyper-V) (domain dom0 Xen). , , . -.

, . : , ESXi, , HCL. , .

1+ :



: VMware ESX, Microsoft Hyper-V, Xen-based (Citrix XenServer Xen Linux). , Citrix XenServer – RHEL-based OS, Red-Hat Enterprise Linux. Xen : Linux Xen dom0. , Xen-based 1 .

VMware, . . , , . , , .

SLA

, SLA (RPO / RTO).

HA

High Availability — . . : RTO HA + / .

FT

Fault Tolerance — . , . , . . : RTO .

TCO

, TCO.

vMotion

vMotion — . , , .. . : RTO , , .

Storage vMotion

Storage vMotion — . , . : RTO , , .

DPM

Distributed Power Management — / . DRS. : .

Distributed vSwitch

Distributed vSwitch — . : , .

EVC

Enhanced vMotion Compatibility — , . , . : / .

QoS

, SLA .

vNUMA

vNUMA — NUMA (vCPU vRAM > NUMA). : , NUMA.

Resource Pool

— . : , .

Limit / Reserve

/ , / .

DRS

Dynamic Resource Scheduler — . vMotion.

Storage IO Control

Storage IO control — , “ ”, , . — / .

Network IO Control

Network IO Control — , “ ”, .

Storage Integration (VAAI etc)

:

• / , .
• — VAAI, ODX. , . , , , . , .

Security

Microsegmentation

— , . .

Agentless AV

. . , “ ”.

, — . . , .

. + + . . , “ ”. .

आर्किटेक्चर

, .

, , , . — SDS.

हमें मिलता है:

• — , , , /. .
• — , , . .

, , . , .

— .
. , SDS. disaggregated HCI ( ). , , NetApp , . NetApp HCI ( 2019) — hybrid cloud infrastructure.

, , .

• 1. . SDS , vSAN + ESXi
• 1.5 . SDS , S2D + Hyper-V
• 2. . SDS . Nutanix, Cisco Hyperflex, HPE Simplivity.

, , . 1 , , 2 .

कंटेनर

, , . , OSI, . — , .

— , . , .

vs

दोनों दृष्टिकोणों के पेशेवरों और विपक्ष काफी सरल और सीधे विपरीत हैं।

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

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

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

कंटेनर 0.1

chroot

1979 में कंटेनरों का प्रोटोटाइप चुरोट था।

“चिरोट यूनिक्स जैसे ऑपरेटिंग सिस्टम पर रूट डायरेक्टरी को बदलने का ऑपरेशन है। संशोधित रूट डायरेक्टरी के साथ लॉन्च किए गए प्रोग्राम में केवल इस डायरेक्टरी में मौजूद फाइलों तक पहुंच होगी। "

यानी वास्तव में, अलगाव केवल फ़ाइल सिस्टम स्तर पर है, अन्यथा यह ओएस में एक सामान्य प्रक्रिया है।

Freebsd जेल

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

हालाँकि, पूर्ण वर्चुअलाइज़ेशन से पहले (और इसके संस्करण के रूप में paravirtualization) जेल में अतिथि VM में एक अलग संस्करण के कर्नेल को चलाने और दूसरे होस्ट सिस्टम में VM के प्रवास के साथ क्लस्टरिंग की क्षमता का अभाव है।

सोलारिस ज़ोन

सोलारिस ज़ोन एक ऑपरेटिंग सिस्टम वर्चुअलाइज़ेशन तकनीक (कंटेनर वर्चुअलाइज़ेशन) है, जिसे सन सोलारिस में 2004 में शुरू किया गया था। मूल सिद्धांत कम वर्चुअलाइजेशन ओवरहेड है।

ज्यादा लोकप्रियता हासिल नहीं करने पर, OpenSolaris और उसके आधार पर वितरण, 2019 में उपलब्ध हो गए।

कंटेनर 1.0

कंटेनरों 1.0 के युग में, कंटेनरीकरण की दो मुख्य दिशाएं सामने आई हैं - ये होस्टिंग प्रदाताओं, और अनुप्रयोगों के कंटेनरीकरण के लिए वाणिज्यिक उत्पाद हैं।

Virtuozzo / OpenVZ

2001 में रूसी SWsoft ने होस्टिंग प्रदाताओं के बाजार के उद्देश्य से कंटेनर वर्चुअलाइजेशन Virtuozzo का अपना पहला संस्करण पेश किया। दृढ़ संकल्प और विशिष्ट व्यावसायिक लक्ष्य दर्शकों के कारण, उत्पाद काफी सफल रहा और लोकप्रियता हासिल की। तकनीकी रूप से, 2002 में, 8 प्रोसेसर सर्वर पर 2500 कंटेनरों के एक साथ संचालन का प्रदर्शन किया गया था।

2005 में, लिनक्स के लिए Virtuozzo कंटेनरों का एक ओपन संस्करण जिसे OpenVZ कहा जाता है, दिखाई दिया। और लगभग VPS की मेजबानी के लिए सोने का मानक बन गया।

LXC

LinuX कंटेनरों (LXC) नेमस्पेस और cgroups के आधार पर एक और प्रसिद्ध कंटेनर वर्चुअलाइजेशन है, जो 2008 में दिखाई दिया। यह वर्तमान में लोकप्रिय डॉकर्स आदि को रेखांकित करता है।

1.1 कंटेनरों (अनुप्रयोग वर्चुअलाइजेशन)

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

एप्लिकेशन-वी

Microsoft अनुप्रयोग वर्चुअलाइज़ेशन (App-V), पूर्व में Softricity SoftGrid - विशिष्ट अनुप्रयोगों (कंटेनर के आसपास अन्य तरीका है) को अलग-थलग सैंडबॉक्स में रखने की तकनीक है, फिर Microsoft। 2006 में, Microsoft ने Softricity स्टार्टअप का अधिग्रहण किया, जिसने वास्तव में कंटेनर को चारों ओर घुमा दिया।

ThinApp

VMware ThinApp (पूर्व में स्थापना) 2008 में VMware द्वारा अधिग्रहित Jilt से एक आवेदन कंटेनरकरण उत्पाद है। VMware का अनुमान है कि दुनिया में सभी पैक किए गए अनुप्रयोगों में से 90-95% इस तकनीक का उपयोग करते हैं।

कंटेनर 2.0

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

हुड के नीचे कंटेनर

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

लिनक्स नामस्थान

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

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

लेकिन सब कुछ इतना सरल नहीं है, प्रत्येक प्रक्रिया एक एकल नामस्थान से नहीं होती है, लेकिन प्रत्येक श्रेणी में एक नाम स्थान पर है:

• माउंट (mnt)
• प्रक्रिया आईडी (पीआईडी)
• नेटवर्क (नेट)
• अंतर-प्रक्रिया संचार (आईपीसी)
• UTS
• उपयोगकर्ता आईडी (उपयोगकर्ता)

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

नेटवर्क नेमस्पेस नेटवर्क इंटरफेस की दृश्यता को निर्धारित करता है, अंदर की प्रक्रिया केवल इस नामस्थान से संबंधित इंटरफेस को देखेगी।

लिनक्स नियंत्रण समूह (समूह)

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

डाक में काम करनेवाला मज़दूर

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

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

डॉकटर ने कंटेनरों के निर्माण, भंडारण, स्थानांतरण और प्रक्षेपण के लिए एक पारिस्थितिकी तंत्र बनाया है। डोकर दुनिया में तीन प्रमुख घटक हैं:

• छवियां - एक छवि, यह इकाई है जिसमें आपके एप्लिकेशन, आवश्यक वातावरण और कंटेनर को लॉन्च करने के लिए आवश्यक अन्य मेटाडेटा शामिल हैं;
• रजिस्टरों - डॉकर छवियों के लिए भंडार, भंडारण स्थान। कई प्रकार के रिपॉजिटरी हैं, जो आधिकारिक से लेकर - hub.docker.com और कंपनी के बुनियादी ढांचे में तैनात निजी लोगों के साथ समाप्त होते हैं;
• कंटेनर - एक कंटेनर, लिनक्स कंटेनर जो डॉकर छवि से बनाया गया है। जैसा कि ऊपर उल्लेख किया गया है, यह एक लिनक्स प्रक्रिया है जो डॉकटर के साथ लिनक्स सिस्टम पर चल रही है, अन्य प्रक्रियाओं और ओएस से अलग है।

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

Kubernetes

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

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

चूंकि यह लेख मुख्य रूप से वर्चुअलाइजेशन इंजीनियरों के लिए है, ऑपरेशन के सिद्धांतों की सामान्य समझ और K8 के मुख्य घटकों के लिए, हम अनुशंसा करते हैं कि आप उस लेख को पढ़ें जो K8 और VMware vSphere के बीच समानांतर खींचता है: https : // medium@@pryalukhin/kubernetes-introduction-for-vmware-vmware उन-232cc2f69c58

X86 औद्योगिक वर्चुअलाइजेशन इतिहास

VMware

VMware 1998 में दिखाई दिया, दूसरे प्रकार के हाइपरविजर के विकास के साथ शुरू हुआ, जिसे बाद में VMware वर्कस्टेशन के रूप में जाना जाने लगा।

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

2003 में, वर्चुअल सेंटर सेंट्रल मैनेजमेंट सिस्टम, vSMP तकनीक और वर्चुअल मशीनों का लाइव माइग्रेशन दिखाई दिया।

2004 में, VMware, एक विशालकाय संग्रहण EMC द्वारा अधिग्रहित किया गया था, लेकिन परिचालन स्वतंत्र छोड़ दिया गया।

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

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

Connectix

1988 में स्थापित, कनेक्टिक्स ने वर्चुअलाइजेशन तक कई प्रकार की प्रणाली उपयोगिताओं पर काम किया। 1997 में, Apple Macintosh के लिए पहला VirtualPC उत्पाद बनाया गया, जिससे विंडोज़ को वर्चुअल मशीन में चलाया जा सके। विंडोज के लिए वर्चुअलपीसी का पहला संस्करण 2001 में दिखाई दिया।

2003 में, Microsoft ने VirtualPC खरीदा और, Connectix के साथ समझौता करके, डेवलपर्स ने Microsoft को स्विच किया। उसके बाद, कनेक्टिक्स बंद हो गया।

VHD (वर्चुअल हार्ड डिस्क) फॉर्मेट को VirtualPC के लिए Connectix द्वारा विकसित किया गया था, और इसके स्मरण के रूप में, हाइपर- V मशीनों के वर्चुअल डिस्क में उनके हस्ताक्षर में "Conectix" होते हैं।
VIrtual PC, जैसा कि आप अनुमान लगा सकते हैं, दूसरे प्रकार का एक क्लासिक डेस्कटॉप हाइपरविजर है।

माइक्रोसॉफ्ट

Microsoft के औद्योगिक वर्चुअलाइज़ेशन में Microsoft की यात्रा Connectix की खरीद और Microsoft वर्चुअल PC 2004 में Connectix Virtual PC की रीब्रांडिंग के साथ शुरू हुई। थोड़ी देर के लिए वर्चुअल PC को विकसित किया गया, Windows 7 में Windows Virtual PC नाम के तहत शामिल किया गया। विंडोज 8 में और बाद में वर्चुअल PC को बदल दिया गया। हाइपर-वी का डेस्कटॉप संस्करण।

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

"बेशक, आप सोच सकते हैं कि Microsoft ने जावा के विचार को चुरा लिया है।" लेकिन यह सच नहीं है, Microsoft ने उसे प्रेरित किया! - (विंडोज 2003 सर्वर की प्रस्तुति में एक Microsoft प्रतिनिधि के एक भाषण से)

उत्सुक क्षणों से, यह ध्यान दिया जा सकता है कि माइक्रोसॉफ्ट के अंदर, शून्य वर्षों में मालिकाना वर्चुअलाइजेशन उत्पादों का उपयोग, इसे हल्के ढंग से वैकल्पिक करने के लिए किया गया था। वर्चुअलाइजेशन पर लेखों से टेक्नेट के स्क्रीनशॉट हैं, जहां ट्रे में वीएमवेयर टूल्स लोगो स्पष्ट रूप से मौजूद है। इसके अलावा, मॉस्को में 2009 प्लेटफार्म पर मार्क रोसिनोविच ने वीएमवेयर वर्कस्टेशन के साथ एक प्रदर्शन किया।

नए बाजारों में प्रवेश करने के प्रयास में, Microsoft ने हाइपर- V, S2D और SDN समर्थन के साथ मंच के रूप में एक अत्यधिक संशोधित नैनो सर्वर का उपयोग करते हुए, अपना सार्वजनिक क्लाउड, Azure बनाया। यह ध्यान देने योग्य है कि शुरू में, कुछ बिंदुओं पर एज़्योर ऑन-प्रिमाइसेस सिस्टम से बहुत पीछे था। उदाहरण के लिए, दूसरी पीढ़ी की वर्चुअल मशीनों (सिक्योर बूट के लिए समर्थन के साथ, GPT विभाजन से बूट, पीएक्सई बूट, आदि) का समर्थन केवल 2018 में एज़्योर में दिखाई दिया। ऑन-प्रीमीज़ में, दूसरी पीढ़ी के वीएम विंडोज सर्वर 2012 आर 2 के बाद से जाने जाते हैं। वही पोर्टल समाधान के लिए जाता है: 2017 तक, एज़्योर और विंडोज एज़्योर पैक (एसडीएन और शील्ड वीएम समर्थन के साथ बहु-टेनेंसी क्लाउड समाधान, जो 2013 में सिस्टम सेंटर ऐप कंट्रोलर को बदल दिया गया था) ने उसी पोर्टल डिज़ाइन का उपयोग किया। Microsoft द्वारा सार्वजनिक बादलों पर एक कोर्स की घोषणा करने के बाद, Azure ने विभिन्न जानकारियों को विकसित करने और कार्यान्वित करने के लिए आगे कदम बढ़ाया। वर्ष 2016 के आसपास, आप पूरी तरह से तार्किक तस्वीर देख सकते हैं: अब विंडोज सर्वर में सभी नवाचार एज़्योर से आते हैं, लेकिन विपरीत दिशा में नहीं। Azure से ऑन-प्रिमाइसेस के रूप में प्रलेखन के कुछ हिस्सों की प्रतिलिपि बनाने का तथ्य "जैसा है" (Azure SDN और नेटवर्क नियंत्रक के लिए दस्तावेज़ देखें) यह इंगित करता है, जो एक ओर ऑन-प्रिमाइसेस समाधान के दृष्टिकोण पर संकेत देता है, और दूसरी ओर, समाधान के संबंध को इंगित करता है। संस्थाओं और वास्तुकला के संदर्भ में। किसने किस से नकल की और यह वास्तव में कैसे है - एक बहस का सवाल है।

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

आभासी लोहा

2003 Virtual Iron Xen , .
2009 Oracle Oracle VM x86. Oracle VM SPARC.

Innotek

2007 Innotek GmbH VirtualBox, . .

2008 Sun, 2010 Oracle. Oracle .
VirtualBox — VDI (), VMDK (VMware), VHD (Microsoft). , Windows, macOS, Linux, Solaris OpenSolaris. VirtualBox FreeBSD.

आईबीएम

— ( : 60- 1 ). , : . -. - , . (!) ( , , – ). – , . - , IBM .

60- XX , , . . ( Pay as you go , ?). . .

IBM IBM System/360-67. CP/CMS , , . CP (Control Program) – , « » (VM). CMS ( – Cambridge Monitor System, Conversational Monitor System) . , CMS z/VM. , 90- ( , ) Time-Sharing. , – , . , , .

CP/CMS VM/370 System/370 2 1972 . – VM, VM IBM. , ( ) – VM/370. : () System/370 VM/370 ( ! – ). .

80- « ». VM , . , VM. (Logical Partition Access Resources LPAR), . , - VM, LPAR VM . - , . , VM , 80-:

VM/SP – System z
VM/SP HPO (High Performance Option) – VM/SP System z
VM/XA (extended architecture) – VM S/370.

90- x86 , . , , - . , , , . , IBM , .

Linux Xen

Xen ( ) — , (Ian Pratt) GPL. 2003 . , XenSource.
2013 Xen Linux Foundation.

XenSource

XenServer XenEnterprise, 2007 Citrix.

Citrix XenServer

XenSource 500 , Citrix . , , XenServer , . VMware ESX XenServer 2009 . XenCenter .
Citrix Microsoft , , .

, Citrix XenApp XenDesktop Xen.

Amazon

Amazon IaaS EC2 (Elastic Compute) 2006 . EC2 Xen, Amazon , , .

2017 EC2 KVM . , EC2 KVM .

Linux QEMU / KVM

QEMU (Quick EMUlator) — , GPL v2. x86 ARM, MIPS, RISC-V, PowerPC, SPARC, SPARC64. QEMU , . QEMU x86 , KVM (Kernel-based Virtual Machine) Qumranet.

KVM — QEMU KVM, qcow2 (QEMU copy-on-write 2) KVM.
, QEMU , QEMU / KVM .

Qumranet

एक इज़राइली कंपनी, एक पूर्व डेवलपर और KVM हाइपरविजर और SPICE प्रोटोकॉल की मुख्य प्रायोजक। 2005 में स्थापित, केवीएम को लिनक्स कर्नेल में शामिल करने के बाद प्रसिद्धि मिली। 4 सितंबर, 2008, Red Hat द्वारा अधिग्रहित।

लाल टोपी

GNU/Linux, 2010 Red Hat Xen. , , . , KVM. Red Hat Enterprise Virtualization 2.2 (RHEV) 2010 VDI Citrix VMware Qumranet, . , Live Migration, 2 ( RHEL). , , Red Hat Xen .

28 2018 IBM Red Hat.

OpenStack

OpenStack - VMware x86. 2010 Rackspace Hosting ( ) NASA ( Nebula). , 2012 VMware OpenStack, -.

Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP, Oracle.

. 2012 NASA , AWS. 2016 HPE Helion OpenStack.

OpenStack KVM. OpenStack , OpenStack .

OpenStack . — OpenStack. , , .

OpenStack , . OpenStack — , .

OpenStack . , , OpenStack .

Nutanix AHV

Nutanix VMware vSphere. - , - VMware , . KVM, AHV (Acropolis HyperVisor).

समानताएं

7 Virtuozzo KVM.

Proxmox

Proxmox VE (Virtual Environment) — Proxmox Server Solutions GmbH Debian Linux. 2008 .
LXC ( OpenVZ), KVM.

Parallels / Virtuozzo /

1999 SWsoft . 2003 - Plesk.

2004 SWsoft Parallels Parallels Workstation ( Windows).
Parallels Parallels Desktop Mac ( MacOS).

, . Virtuozzo OpenVZ, . Parallels Parallels Bare Metal Server ( Parallels Hypervisor Cloud Server, Virtuozzo), Cloud Storage. .

2015 — ( ) Virtuozzo, . Depo IBS -.

7 Virtuozzo , 7 KVM. , — KVM.
, 2019 .

Parallels Desktop Parallels Corel. Odin IngramMicro. Virtuozzo / .