सास अनुप्रयोगों के लिए बहु-किरायेदार वास्तुकला

बहुक्रिया क्या है?

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

बहु-किरायेदारी अलग है, उदाहरण के लिए, इसे निम्नलिखित योजना द्वारा दर्शाया जा सकता है:



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

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

बहु-किरायेदार दृष्टिकोण के लाभ क्या हैं?

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

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



स्रोत: क्लाउड कम्प्यूटिंग: क्लाउड के लिए प्रतिबद्ध करने से पहले अपने एसएएएस स्मार्ट को तेज करें

फिर भी, एक समर्पित मॉडल या बहु-किरायेदार क्या चुनना है?

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

स्रोत: विंडोज एज़्योर के लिए मल्टी-टेनेंट डेटा रणनीतियाँ - भाग 1

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

आर्किटेक्चर

1. एक बहु-किरायेदार आवेदन में, आप हमेशा एक समर्पित मोड (एक ग्राहक) का अनुकरण कर सकते हैं, जबकि आमतौर पर कई स्वतंत्र सदस्यता के लिए एक चयनित आवेदन का विस्तार करने का कोई तरीका नहीं है।

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

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

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

3. सेवा स्तर समझौता (SLA) । आप सेवा स्तर के विभिन्न स्तरों के लिए विभिन्न सेवा स्तर समझौते (SLAs) की पेशकश कर सकते हैं। यदि विभिन्न SLAs के ग्राहक समान बहु-किरायेदार परिनियोजन साझा करते हैं, तो उच्चतम SLA प्राप्त किया जाना चाहिए।

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

5. प्रमाणीकरण और प्राधिकरण । क्लाउड में एक एप्लिकेशन अपने स्वयं के प्रमाणीकरण और प्राधिकरण प्रणाली का उपयोग कर सकता है, जिस स्थिति में एप्लिकेशन के ग्राहकों को एप्लिकेशन के सभी उपयोगकर्ताओं के लिए क्रेडेंशियल बनाने की आवश्यकता होगी। दूसरी ओर, ग्राहक अपने मौजूदा प्रमाणीकरण प्रणाली का उपयोग करना पसंद कर सकते हैं और आवेदन के लिए नई साख बनाने की आवश्यकता से बच सकते हैं। एक बहु-किरायेदार आवेदन के लिए दूसरा विकल्प का मतलब है कि आपको कई प्रमाणीकरण प्रदाताओं का समर्थन करने की आवश्यकता है, और स्थानीय प्राधिकरण बुनियादी ढांचे की योजना के लिए क्लाउड में एप्लिकेशन प्राधिकरण योजना को मैप करने की भी आवश्यकता हो सकती है। विंडोज एज़्योर में, एक्सेस कंट्रोल सर्विसेज का उपयोग प्रमाणीकरण और प्राधिकरण को कॉन्फ़िगर करने के लिए किया जाता है, जिसके साथ आप LiveId, Google, Facebook और अन्य OpenID प्रदाताओं के माध्यम से, सक्रिय निर्देशिका के माध्यम से प्रपत्रों पर प्रमाणीकरण लागू कर सकते हैं। यदि हम सक्रिय निर्देशिका के साथ एकीकरण और AD ग्राहक और सेवा के बीच महासंघ स्थापित करने के बारे में बात कर रहे हैं, तो सबसे अधिक संभावना यह भी समर्पित तैनाती की आवश्यकता हो सकती है।

अनुप्रयोग जीवनचक्र प्रबंधन

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

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

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

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

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

4. तृतीय-पक्ष घटकों का उपयोग । यदि आप एक बहु-किरायेदार वास्तुकला का उपयोग करने का निर्णय लेते हैं, तो आपको यह मूल्यांकन करना होगा कि इस मोड में तीसरे पक्ष के घटक कितनी अच्छी तरह काम करेंगे। यह सुनिश्चित करने के लिए कि एक तृतीय-पक्ष घटक बहु-किरायेदार वास्तुकला में काम कर सकता है, आपको कुछ अतिरिक्त चरणों का प्रदर्शन करने की आवश्यकता हो सकती है।

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

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

एप्लिकेशन सेटअप

1. आवेदन का उपयोग करने के लिए यूआरएल । डिफ़ॉल्ट रूप से, Windows Azure प्रत्येक एप्लिकेशन को फॉर्म के DNS नाम के साथ प्रदान करता है <application name> .cloudapp.net। एक समर्पित परिनियोजन के लिए, आप सब्स्क्राइबर के DNS नाम (उदाहरण के लिए, contoso.com ) को आवेदन करने के लिए CNAME रिकॉर्ड का उपयोग कर सकते हैं। एक बहु-किरायेदार एप्लिकेशन में, आप निम्नलिखित फॉर्म की योजनाओं को संबोधित कर सकते हैं: http: //.cloudapp.net// या फिर, CNAME और होस्ट हैडर का उपयोग करके। उदाहरण के लिए, आप mydomain.ru को http: // <multitenat-application-name> .cloudapp.net पर मैप कर सकते हैं, जहां होस्ट हैडर का उपयोग करके, अनुरोधित किरायेदार का निर्धारण करें। इस दृष्टिकोण के बारे में अधिक जानकारी के लिए, बहु-किरायेदार अज़ुर अनुप्रयोगों में किरायेदार की पहचान करना देखें - भाग 2 । यह दृष्टिकोण आपको उपयोगकर्ता से इस तथ्य को छिपाने की अनुमति देता है कि यह एक बहु-किरायेदार आवेदन है, क्योंकि अपील किरायेदार के लिए चयनित अद्वितीय URL पर जाती है। स्थिति जब पहुंच HTTPS के माध्यम से होनी चाहिए, थोड़ी अधिक जटिल हो जाती है, इस बारे में लेख में बहु-किरायेदार अज़ुर अनुप्रयोगों में किरायेदार की पहचान करना - भाग 3 ।

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

डेटा लेयर आर्किटेक्चर

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

• डेटाबेस स्कीमा जहाँ प्रत्येक क्लाइंट की टेबल एक अलग स्कीमा में होती है;
• डेटाबेस सुरक्षा उपकरण जो आपको डेटाबेस स्तर पर पहुंच नियंत्रण तंत्र का उपयोग करने की अनुमति देते हैं;
• ग्राहक डेटा को अलग करने के लिए विभाजन;
• इन दृष्टिकोणों का एक संयोजन।

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

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

2. डेटा आर्किटेक्चर की व्यापकता । डेटा वेयरहाउस बनाने के कई तरीके हैं ताकि ग्राहकों को अपनी स्वयं की कस्टम विशेषताओं को शामिल करने के लिए डेटा मॉडल का विस्तार करने की अनुमति दी जाए। कई दृष्टिकोण हैं:

• एक दृष्टिकोण जिसमें प्रत्येक ग्राहक की एक अलग योजना होती है;
• एक दृष्टिकोण जहां पूर्वनिर्धारित उपयोगकर्ता कॉलम का एक सेट प्रदान किया जाता है।
• अधिक लचीली योजनाओं के साथ दृष्टिकोण जो क्लाइंट को तालिका में उपयोगकर्ता क्षेत्रों की एक मनमानी संख्या जोड़ने की अनुमति देता है।

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

3. डेटा आर्किटेक्चर की स्केलेबिलिटी । क्षैतिज विभाजन आपको डेटा वेयरहाउस को स्केल करने की अनुमति देता है। SQL Azure में scalability को प्राप्त करने के लिए, आप व्यक्तिगत ग्राहक डेटा को Azure SQL के एक नए उदाहरण में माइग्रेट कर सकते हैं।

विंडोज एज़्योर टेबल स्टोरेज की स्केलेबिलिटी निर्धारित करने की कुंजी पार्टीशन की पसंद है। कई विभाजनों को देखने (स्कैनिंग) से बचने के लिए, सभी अनुरोधों में विभाजन कुंजी शामिल होनी चाहिए।

Windows Azure के लिए मल्टी-टेनेंट डेटा रणनीतियाँ - भाग 1 और Windows Azure के लिए मल्टी-टेनेंट डेटा रणनीतियाँ - भाग 2 में डेटा आर्किटेक्चर और शामिल किए गए ट्रेडऑफ़ को चुनने के बारे में अधिक जानकारी के लिए । विशेष रूप से, SLA, बैकअप और एकल साझा डेटाबेस का उपयोग करके संबंधित डेटा की पुनर्प्राप्ति के बारे में दिलचस्प सवाल उठाए जाते हैं।

वित्तीय मुद्दे

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

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

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


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

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

नतीजतन, अंतिम लाभ प्राप्त करने के लिए, पर्याप्त संख्या में सब्सक्रिप्शन बेचना आवश्यक है जो निश्चित और परिवर्तनीय लागतों को कवर करेगा।

यदि आपके ग्राहक आधार में बड़ी और छोटी दोनों कंपनियां शामिल हैं, तो छोटे ग्राहकों को आकर्षित करने के लिए मानक मासिक शुल्क बहुत अधिक हो सकता है। . , , .

2. . SaaS Windows Azure . , $0,02 (Extra Small ), ( ) — , $28,8 . , . , .

, :

• , ;
• .

, ( , ..), .. .

. . .

निष्कर्ष

1. , .
2. , .. , \ (, DNS ). , .
3. SaaS , .. .
4. SaaS . PaaS .
5. , SaaS ( ).

• Gartner Reference Architecture for Multitenancy, 2010
• Cloud Computing: Sharpen Your SAAS Smarts Before Committing to the Cloud, 2010
• Busting Myths of On-Demand: Why Multi-Tenancy Matters, 2007
• Microsoft, ., .
• Multi-Tenant Data Strategies for Windows Azure – Part 1
• Multi-Tenant Data Strategies for Windows Azure – Part 2
• Identifying the Tenant in Multi-Tenant Azure Applications — Part 1
• Identifying the Tenant in Multi-Tenant Azure Applications — Part 2
• Identifying the Tenant in Multi-Tenant Azure Applications — Part 3