एकीकृत बुनियादी ढांचा "क्लाउड + भौतिक उपकरण"

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


एक डेटा सेंटर में एक भौतिक और आभासी सर्वर के बीच इंटरनेट के माध्यम से कनेक्ट होने पर एक आम यातायात मार्ग योजना।

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


विभिन्न ट्रैफ़िक केंद्रों में एक भौतिक और आभासी सर्वर के बीच इंटरनेट से जुड़ते समय एक सामान्य यातायात मार्ग योजना।

हमें इसी तरह की समस्या का हल मिला और मॉस्को थोक और खुदरा व्यापार कंपनी के बुनियादी ढांचे में इसे सफलतापूर्वक लागू किया। जो हम आगे बताएंगे।

शुरू करने के लिए, आइए फैसला करें कि क्यों और किन मामलों में इसकी आवश्यकता हो सकती है:

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

ये सभी संभावित कारणों से दूर हैं, हमने मुख्य और सबसे आम लोगों को सूचीबद्ध किया है जो व्यवहार में सामने आए हैं।

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

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

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

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

हम नेटवर्क कोर के विवरण पर ध्यान केंद्रित नहीं करेंगे; फोटो और विवरण के साथ इसके लिए एक अलग पोस्ट है । हम केवल बादल के बारे में निर्णय के बारे में बात करेंगे।
यह स्पष्ट है कि क्लाउड संसाधन अलग-अलग रैक में स्थित हैं, उनके अपने स्विच हैं, लेकिन कोर साझा किया गया है। रैक में जहां बादल स्थित है, वहाँ सिस्को उत्प्रेरक 3750X श्रृंखला स्विच एक साथ ढेर हो गए हैं। चार अपलिंक को एक रैक में कोर से दो स्विच तक स्क्रॉल किया जाता है। स्वाभाविक रूप से, ये अपलिंक एक दूसरे को आरक्षित करते हैं, और यदि स्विच में से एक, कर्नेल का हिस्सा, या अपलिंक विफल हो जाता है, तो क्लाइंट इस पर ध्यान नहीं देगा।

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

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

इसी समय, हाइपर-वी वर्चुअलाइजेशन सिस्टम, जो कि मेजबानों पर स्थापित है, पूरी तरह से वीएलएएन में यातायात के अलगाव को समझता है। वास्तुकला काफी सरल है:

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

यदि एक वर्चुअल सर्वर को कई अलग-अलग वीएलएएन से ट्रैफ़िक प्राप्त करने की आवश्यकता होती है, तो कई वर्चुअल नेटवर्क एडेप्टर जोड़े जाते हैं, जिनमें से प्रत्येक को एक विशिष्ट एचएएन सौंपा जाता है।


इस परियोजना में भौतिक और आभासी सर्वर के बीच एक आंतरिक नेटवर्क के आयोजन की एक उदाहरण योजना है।

इस परियोजना में इसे कैसे लागू किया गया है? कनेक्शन प्रक्रिया इस प्रकार है:

• क्लाइंट को दो वीएलएएन आवंटित किए गए थे, जहां सबनेट्स के घाव थे। उदाहरण के लिए, वीएलएएन 1 10.1.1.0/24 और वीएलएएन 2 10.1.2.0/24।
• VLAN1 से जुड़ा एक वर्चुअल नेटवर्क एडॉप्टर वर्चुअल सर्वर में जोड़ा गया है।
• भौतिक सर्वर एक अलग नेटवर्क पोर्ट द्वारा रैक में एक स्विच से जुड़ा हुआ है। पोर्ट की आपूर्ति VLAN2 के साथ की जाती है।
• कर्नेल में, वीएलएएन 1 में नेटवर्क 10.1.1.0/24 और वीएलएएन 2 में 10.1.2.0/24 के बीच रूटिंग कॉन्फ़िगर किया गया है (आपको यह समझना चाहिए कि सर्वर के बीच का कनेक्शन एल 3 के माध्यम से होगा)।
• नए नेटवर्क एडेप्टर पर वर्चुअल सर्वर पर, सबनेट 10.1.1.0/24 से एक आईपी एड्रेस असाइन किया गया है (यदि यह एकमात्र नेटवर्क एडेप्टर है, तो इस सबनेट का गेटवे भी पंजीकृत है। यदि दूसरे गेटवे पहले से ही अन्य नेटवर्क एडेप्टर पर पंजीकृत है, तो नेटवर्क 10.1 के लिए रूट बस पंजीकृत है। 2.0 / 24)।
• भौतिक सर्वर पर, सब कुछ समान था, लेकिन केवल 10.1.2.0/24 नेटवर्क के लिए।
• हो गया! अब सर्वरों के बीच एक आंतरिक पृथक नेटवर्क है, और ट्रैफ़िक नेटवर्क कोर से होकर जाता है।

इस उदाहरण के लिए भौतिक और आभासी सर्वर के बीच आंतरिक नेटवर्क के संगठन का एक सरल आरेख।

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

योजना काफी सरल है, और, सबसे महत्वपूर्ण, सार्वभौमिक। बादल या कोर में कोई बैसाखी नहीं थी।

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

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

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

जैसा कि आप देख सकते हैं, यदि आप समाधान को व्यापक रूप से देखते हैं, तो आप किसी भी ग्राहक की इच्छाओं को महसूस कर सकते हैं। स्वाभाविक रूप से, मुख्य मुद्दों में से एक होगा जो एक समाधान की लागत है। लेकिन यह एक अलग बातचीत है। ;)