प्रबंधन समूह और सब्सक्रिप्शन

Azure संसाधनों को चार-स्तरीय पदानुक्रम में व्यवस्थित करता है। सबसे ऊपर Management Groups होते हैं — ऐसे कंटेनर जो बड़े पैमाने पर नीति और पहुँच नियंत्रण के लिए Subscription को समूहित करते हैं। इनके नीचे Subscriptions होते हैं — बिलिंग और संसाधन सीमा की इकाइयाँ। Subscription के भीतर Resource Groups होते हैं — संबंधित संसाधनों के लिए तार्किक कंटेनर। सबसे नीचे Resources होते हैं — VM, Database और Storage खाते जैसी अलग-अलग सेवाएँ। ऊपरी स्तरों पर लागू की गई नीतियाँ और अनुमतियाँ नीचे के स्तरों तक स्वतः लागू होती हैं।

Azure Subscription बिलिंग इकाई और तार्किक संसाधन सीमा, दोनों होती है। किसी Subscription में संसाधनों के पूरे उपयोग का बिल एक ही इनवॉइस में आता है। Subscription यह सीमाएँ (कोटा) निर्धारित करती हैं कि प्रत्येक प्रकार के कितने संसाधन तैनात किए जा सकते हैं। संगठन अक्सर अलग-अलग Environment (Production, Development, Testing), व्यावसायिक इकाइयों या भौगोलिक क्षेत्रों के लिए अलग Subscription बनाते हैं — प्रत्येक की अपनी Cost रिपोर्टिंग और पहुँच नियंत्रण होता है।

बड़े उद्यम कई कारणों से एकाधिक Subscription का उपयोग करते हैं। अलगाव — Production संसाधन dev/test से पूरी तरह अलग रहते हैं; dev में गलत कॉन्फ़िगरेशन Production को प्रभावित नहीं कर सकता। बिलिंग की सूक्ष्मता — प्रत्येक विभाग की Subscription स्पष्ट Cost आवंटन के लिए अपना इनवॉइस बनाती है। Subscription सीमाएँ — Azure में प्रत्येक Subscription के लिए कोटा होते हैं (जैसे, प्रत्येक क्षेत्र में 250 VM); बड़े कार्यभार को इन सीमाओं के भीतर रहने के लिए कई Subscription की आवश्यकता हो सकती है।

Management Group Azure पदानुक्रम में subscriptions के ऊपर स्थित एक कंटेनर है। आप subscriptions को management groups में व्यवस्थित कर सकते हैं और management group स्तर पर Azure Policy परिभाषाएँ तथा RBAC भूमिका-नियुक्तियाँ लागू कर सकते हैं। ये समूह के अंतर्गत आने वाली प्रत्येक subscription और संसाधन तक नीचे की ओर लागू होती हैं। इससे दर्जनों अलग-अलग subscriptions में एक ही नीति या भूमिका-नियुक्ति को दोहराने की आवश्यकता समाप्त हो जाती है।

Management groups को अधिकतम छह स्तरों तक एक-दूसरे के भीतर रखा जा सकता है। प्रत्येक Azure directory के शीर्ष पर एकल Root Management Group होता है, जिसके अंतर्गत अन्य सभी management groups और subscriptions आती हैं। किसी सामान्य enterprise पदानुक्रम का उदाहरण इस प्रकार हो सकता है: Root → Company → Platform → Production → Landing Zones → अलग-अलग Workloads subscriptions। Root स्तर पर लागू की गई नीतियाँ पूरी directory की प्रत्येक subscription को प्रभावित करती हैं।

पदानुक्रम के किसी भी स्तर पर की गई पहुँच-नियंत्रण नियुक्तियाँ नीचे की ओर विरासत में मिलती हैं। यदि आप किसी उपयोगकर्ता को management group पर Reader भूमिका देते हैं, तो उसे उस management group के अंतर्गत आने वाली प्रत्येक subscription और resource group पर Reader पहुँच अपने-आप मिल जाती है। यह विरासत संचयी होती है — आप निचले स्तर पर विरासत में मिली अनुमति वापस नहीं ले सकते (आप केवल और अनुमतियाँ जोड़ सकते हैं)। Deny नियुक्तियाँ इसका अपवाद हैं: वे कार्रवाइयों को रोक देती हैं, भले ही कोई भूमिका-नियुक्ति उन्हें अनुमति देती हो।

इसी तरह, management group स्तर पर की गई Azure Policy नियुक्तियाँ उस समूह के अंतर्गत आने वाली सभी subscriptions, resource groups और संसाधनों पर लागू होती हैं। एक सामान्य तरीका यह है कि पूरे संगठन में अनुमत क्षेत्रों, अनिवार्य टैग या आवश्यक निदान सेटिंग जैसी मानक आवश्यकताओं को लागू करने के लिए Root या Company management group पर कॉर्पोरेट आधारभूत नीति नियुक्त की जाए। इसके बाद अलग-अलग subscription के स्वामी नीचे अधिक विशिष्ट नीतियाँ जोड़ सकते हैं, बिना कॉर्पोरेट आधारभूत नीति को बदलने के।

Azure subscriptions बनाई, उनका नाम बदला, रद्द और management groups के बीच स्थानांतरित की जा सकती हैं। किसी subscription को स्थानांतरित करना यह बदल देता है कि उस पर कौन-सी नीतियाँ और भूमिका-नियुक्तियाँ लागू होंगी — नीति में किए गए बदलाव subscription के सभी संसाधनों पर तुरंत प्रभावी हो जाते हैं। किसी subscription को रद्द करना संसाधन बनाने की सुविधा बंद कर देता है और अंततः रियायत अवधि के बाद उसके सभी संसाधनों को हटा देता है, इसलिए यह कार्रवाई सावधानीपूर्वक योजना बनाकर ही करनी चाहिए।

बड़े संगठन ऐसे बिलिंग समझौतों के माध्यम से Azure का उपयोग करते हैं, जो subscriptions की संरचना को प्रभावित करते हैं। एक उद्यम समझौता (EA) बड़े प्रतिबद्ध खर्च के लिए केंद्रीय बिलिंग खाते के अंतर्गत नामांकन के साथ subscriptions उपलब्ध कराता है। Microsoft ग्राहक समझौता (MCA) इसका आधुनिक उत्तराधिकारी है, जो subscription प्रबंधन के लिए अधिक स्व-सेवा सुविधाएँ प्रदान करता है। दोनों व्यवस्थाओं में billing profiles और invoice sections अलग-अलग विभागों के subscription शुल्क को समूहित करने की सुविधा देते हैं।

प्रत्येक Azure subscription में सेवा कोटा होते हैं — ये इस बात की नरम सीमाएँ हैं कि प्रत्येक क्षेत्र में किसी प्रकार के कितने संसाधन मौजूद रह सकते हैं। डिफ़ॉल्ट उदाहरण: प्रत्येक क्षेत्र में 20,000 vCPUs, प्रत्येक subscription में 980 resource groups और प्रत्येक subscription में 800 managed disks। जब आपका Workloads किसी कोटा की सीमा के करीब पहुँचता है, तो आप Azure portal में कोटा बढ़ाने का अनुरोध भेज सकते हैं (Support + troubleshooting > New support request)। बहुत बड़े पैमाने पर विस्तार के लिए Microsoft Workloads को कई subscriptions में वितरित करने की अनुशंसा करता है।

Microsoft management group के design के लिए कई सर्वोत्तम अभ्यास सुझाता है। तीन से चार से अधिक स्तरों की नेस्टिंग से बचें — बहुत अधिक स्तर नीति की समस्याओं का पता लगाना जटिल बना देते हैं। साझा सेवाओं (Identity, Connectivity, Management) के लिए एक समर्पित Platform management group बनाएँ, और उसे Landing Zones के Workloads से अलग रखें। Production और Non-Production को अलग-अलग management groups में रखें, ताकि केवल Production पर लागू होने वाली नीतियाँ (जैसे सार्वजनिक internet पहुँच बंद करना) गलती से Dev Environment पर लागू न हो जाएँ।

इस lesson में आपने सीखा: Azure संसाधन पदानुक्रम management groups से subscriptions, फिर resource groups और अंततः संसाधनों तक जाता है, management group स्तर पर की गई policies और RBAC नियुक्तियाँ नीचे की ओर सभी child subscriptions में विरासत के रूप में लागू होती हैं, और कई subscriptions से billing अलगाव, Environment पृथक्करण और प्रति-subscription कोटा के लिए वैकल्पिक उपाय मिलता है। आगे हम Azure Policy का विस्तार से अध्ययन करेंगे।