क्लाउड आर्किटेक्चर एप्लिकेशन गाइड बुक

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

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


आज हम इस पुस्तक के पहले अध्याय का हिस्सा प्रकाशित करते हैं। आप यहाँ पूर्ण संस्करण डाउनलोड कर सकते हैं ।

---

सामग्री की तालिका

• वास्तुकला का विकल्प - 1;
• कंप्यूटिंग और भंडारण डेटा के लिए प्रौद्योगिकियों का विकल्प - 35;
• एक Azure अनुप्रयोग डिज़ाइन करना: डिज़ाइन सिद्धांत - 60;
• एक एज़्योर एप्लिकेशन डिजाइन करना: गुणवत्ता संकेतक - 95;
• एक एज़्योर एप्लिकेशन डिज़ाइन करना: डिज़ाइन पैटर्न - 103;
• खाका निर्देशिका - 110;
• आर्किटेक्चर वैलिडेशन चेकलिस्ट - 263;
• निष्कर्ष - 291;
• एज़्योर संदर्भ वास्तुकला - 292;

वास्तुकला का विकल्प

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

वास्तुकला की पसंद आवेदन की संरचना पर कुछ प्रतिबंध लगाती है, प्रौद्योगिकियों और आवेदन के अन्य तत्वों की पसंद को सीमित करती है। ये सीमाएं चयनित वास्तुकला के फायदे और नुकसान दोनों से जुड़ी हैं।

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

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

• वास्तुकला का वर्णन और तर्क;
• इस वास्तुकला के दायरे पर सिफारिशें;
• फायदे, नुकसान और उपयोग के लिए सिफारिशें;
• उपयुक्त एज़्योर सेवाओं का उपयोग करते हुए अनुशंसित परिनियोजन विकल्प।

वास्तुकला अवलोकन

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

एन स्तरीय

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

एन-टियर आर्किटेक्चर एक प्राकृतिक पसंद है, जब पहले से उपयोग किए गए अनुप्रयोगों को tiered आर्किटेक्चर के आधार पर स्थानांतरित किया जाता है। इसलिए, इस वास्तुकला का उपयोग IaaS (सेवा के रूप में बुनियादी ढांचे) समाधान में या प्रबंधित सेवाओं के साथ IaaS के संयोजन में अनुप्रयोगों में सबसे अधिक बार किया जाता है।

वेब इंटरफ़ेस - कतार - कार्यकर्ता भूमिका

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

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

Mikrosluzhby

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

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

CQRS

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

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

घटना आधारित वास्तुकला

ईवेंट-आधारित आर्किटेक्चर एक प्रकाशन-सदस्यता वाले मॉडल का उपयोग करता है जिसमें आपूर्तिकर्ता घटनाओं को प्रकाशित करते हैं और उपभोक्ता उनकी सदस्यता लेते हैं। आपूर्तिकर्ता उपभोक्ताओं से स्वतंत्र होते हैं, और उपभोक्ता एक दूसरे से स्वतंत्र होते हैं।

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

बड़ा डेटा, बड़ी कंप्यूटिंग

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

सीमाओं के रूप में वास्तुकला विकल्प

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

उदाहरण के लिए, माइक्रोसर्विसेज को निम्नलिखित प्रतिबंधों की विशेषता है:

• प्रत्येक सेवा एक अलग कार्य के लिए जिम्मेदार है;
• सेवाएं एक-दूसरे से स्वतंत्र हैं;
• डेटा केवल उस सेवा के लिए उपलब्ध है जो इसके लिए जिम्मेदार है। सेवाएं डेटा का आदान-प्रदान नहीं करती हैं।

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

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

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

फायदे और नुकसान का विश्लेषण

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

आर्किटेक्चर चुनते समय विचार करने के कुछ नुकसान नीचे दिए गए हैं:

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

एन-टियर आर्किटेक्चर

एन-टियर आर्किटेक्चर में, एक एप्लिकेशन को तार्किक परतों और भौतिक परतों में विभाजित किया गया है।



परतें जिम्मेदारी साझा करने और निर्भरता के प्रबंधन के लिए एक तंत्र हैं। प्रत्येक परत की अपनी जिम्मेदारी का क्षेत्र है। उच्च-स्तरीय परतें निम्न-स्तरीय परतों की सेवाओं का उपयोग करती हैं, लेकिन इसके विपरीत नहीं।

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

एन-टियर एप्लिकेशन में एक बंद परत वास्तुकला या एक खुली परत वास्तुकला हो सकती है।

• एक बंद वास्तुकला में, एक मनमानी परत केवल निकटतम निचली परत तक पहुंच सकती है।
• एक खुली वास्तुकला में, एक मनमानी परत किसी भी निचली परतों को संदर्भित कर सकती है।

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

वास्तुकला अनुप्रयोगों

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

निम्नलिखित मामलों में उपयोग के लिए एन-टियर आर्किटेक्चर की सिफारिश की जाती है:

• सरल वेब अनुप्रयोग;
• न्यूनतम रिफ्लेक्टरिंग के साथ एज़्योर के लिए एक स्थानीय एप्लिकेशन को पोर्ट करना
• ऑन-प्रिमाइसेस और क्लाउड एप्लिकेशन की निरंतर तैनाती।

एन-टियर आर्किटेक्चर सामान्य ऑन-प्रिमाइसेस अनुप्रयोगों में सामान्य है, इसलिए यह मौजूदा अनुप्रयोगों को एज़्योर में पोर्ट करने के लिए अच्छी तरह से अनुकूल है।

लाभ

• ऑन-प्रिमाइसेस परिनियोजन और क्लाउड के साथ-साथ क्लाउड प्लेटफ़ॉर्म के बीच अनुप्रयोगों को स्थानांतरित करने की क्षमता।
• अधिकांश डेवलपर्स के लिए कम प्रशिक्षण।
• पारंपरिक एप्लिकेशन मॉडल का एक प्राकृतिक विस्तार।
• विषम वातावरण (विंडोज / लिनक्स) के लिए समर्थन।

कमियों

• एक आवेदन प्राप्त करना आसान है जिसमें मध्य स्तरीय डेटाबेस में केवल CRUD संचालन करता है, अनुरोधों के प्रसंस्करण समय को बढ़ाता है और कोई लाभ नहीं लाता है।
• अखंड वास्तुकला स्वतंत्र विकास टीमों द्वारा व्यक्तिगत घटकों के विकास की अनुमति नहीं देगा।
• IaaS एप्लिकेशन का प्रबंधन एक प्रबंधित सेवा-केवल अनुप्रयोग की तुलना में अधिक समय लेने वाला है।
• बड़ी प्रणालियों में नेटवर्क सुरक्षा का प्रबंधन करना मुश्किल हो सकता है।

सिफारिशें

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

एन-टियर वर्चुअल मशीन वास्तुकला

यह खंड वर्चुअल मशीनों का उपयोग करते हुए एन-टियर आर्किटेक्चर के निर्माण के लिए दिशानिर्देश प्रदान करता है।



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

प्रत्येक स्तर को अपने स्वयं के सबनेट के अंदर भी रखा जाता है। इसका मतलब है कि उनके आंतरिक आईपी पते एक ही सीमा में हैं। इससे नेटवर्क सुरक्षा समूह (NSG) नियम और राउटिंग टेबल को व्यक्तिगत परतों में लागू करना आसान हो जाता है।

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

प्रत्येक स्तर तक पहुंच नेटवर्क सुरक्षा समूहों (एनएसजी) द्वारा सीमित है। उदाहरण के लिए, डेटाबेस टियर की पहुंच केवल बिजनेस टियर के लिए दी जाती है

अतिरिक्त सुविधाएँ

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

---

आप पुस्तक के पूर्ण संस्करण को मुफ्त में डाउनलोड कर सकते हैं और नीचे दिए गए लिंक पर अध्ययन कर सकते हैं।

→ डाउनलोड करें