Microsoft Azure क्लाउड में SQL सर्वर: IAS के बनाम PaaS

किसी भी बादल में SQL सर्वर की मेजबानी करने का मार्ग, यह Microsoft या अन्यथा, सावधानीपूर्वक योजना के साथ शुरू होना चाहिए। परियोजना के प्रारंभिक चरण में किए गए वास्तुशिल्प निर्णय परियोजना के भविष्य को पूरी तरह से अप्रत्याशित रूप से प्रभावित कर सकते हैं, और ये हमेशा स्पष्ट-हल की समस्याएं नहीं हो सकती हैं। नियोजन में एक निर्णय भी शामिल है कि किस मॉडल में SQL सर्वर को IaaS मॉडल (वर्चुअल मशीन पर) या PaS मॉडल में (SQL Azure DB की तरह) होस्ट किया जाना चाहिए। मॉडल के बीच का अंतर तकनीकी योजना की विशेषताओं और मूल्य में दोनों निहित है, उदाहरण के लिए, दोनों मॉडलों के सेवा समझौते स्तर (एसएलए), एक प्रारंभिक चरण में और एक परियोजना के रिलीज, स्वचालन, और बहुत कुछ के स्तर पर विलंबता का प्रभाव।



इस लेख में, हम यह समझने की कोशिश करेंगे कि Microsoft Azure में IaaS और PaaS के बीच न केवल क्या तकनीकी अंतर हैं, बल्कि यह भी कि यह अंतर कहाँ से आ सकता है, जहाँ PaaS में समस्याएं उत्पन्न हो सकती हैं, जो IaaS और वास्तुकला में नहीं मिल सकती हैं। ये समाधान, साथ ही साथ Azure SQL DB प्रीमियम क्या है और इसका उपयोग कब करना है।



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

IaaS और Azure SQL DB के बीच चयन

IaaS Way: सामान्य विवरण और वास्तुकला

Paa Way: सामान्य विवरण, वास्तुकला और संभावित समस्याएं

PaaS Way: सुरक्षा

Azure SQL DB SLA - वर्चुअल मशीन में SQL सर्वर SLA से क्या अंतर है?

पाएस वे: हाई एवलाबिलि

Azure SQL DB उपयोग मोड का चयन कैसे करें? प्रीमियम स्तर - सेवा के रूप में SQL सर्वर के लिए उच्च प्रदर्शन की गारंटी



IaaS और Azure SQL DB ( PaaS ) के बीच चयन



SQL सर्वर प्लेटफ़ॉर्म का उपयोग करके डेटा प्रबंधित करने वाले किसी भी समाधान में इस प्लेटफ़ॉर्म को होस्ट करने के तीन तरीके हैं:

स्थानीय तौर पर, खुद के बुनियादी ढांचे में

एक Azure वर्चुअल मशीन (IaaS) पर

सेवा के रूप में (Azure SQL DB)



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





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



माइग्रेशन के मामले में, हम एक कांटे के साथ सामना कर रहे हैं - चूंकि Azure SQL DB एक पूर्ण SQL सर्वर से कार्यक्षमता में बहुत भिन्न है, हमें अपने कोड बेस और डेटाबेस का विश्लेषण करना चाहिए और देखना चाहिए कि क्या परिवर्तन आवश्यक हैं और वे कितने महत्वपूर्ण हैं। यह एक बहुत महत्वपूर्ण कांटा है - यदि हम Azure SQL DB द्वारा असमर्थित डेटा प्रकार को याद करते हैं, तो हम बहुत समय और प्रयास खो देंगे। डेटाबेस के साथ, sqlazuremw.codeplex.com हमारी मदद कर सकता है , जो डेटाबेस का विश्लेषण कर सकता है और कह सकता है कि यह Azure SQL DB में समर्थित नहीं है। और, यदि इस चरण में हमारे समाधान में गंभीर परिवर्तन करने की आवश्यकता है, या ऐसी कार्यक्षमता होगी जो Azure SQL DB में समर्थित नहीं है, लेकिन हमें इसकी आवश्यकता है, तो निर्णय ट्री बंद हो जाता है और हमें एक स्थानीय SQL सर्वर का उपयोग करने या वर्चुअल मशीन पर रखने की आवश्यकता होती है (IaaS)।



यदि हम एक नया समाधान विकसित कर रहे हैं या माइग्रेटेड प्रोजेक्ट में गैर-महत्वपूर्ण परिवर्तन करने में सक्षम हैं, तो अगला प्रश्न जो हमारे सामने आता है, वह Azure SQL DB में डेटाबेस की आकार सीमा है, जो 500 GB है। क्या यह हमारे लिए पर्याप्त है? अनुमानित वृद्धि क्या होगी? यदि हम समझते हैं कि हम इस छत से नहीं टूटेंगे, तो हम सुरक्षित रूप से Azure SQL DB का उपयोग कर सकते हैं। यदि हम समझते हैं कि किसी दिन ऐसी स्थिति उत्पन्न हो सकती है जिसमें हमारे पास 501 जीबी होगा, तो अगले चरण पर जाएं।



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



आइए दोनों समाधानों के अंतर और वास्तुकला को देखें।



इयासा रास्ता



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



हम वर्चुअल मशीन पर एक पूर्ण SQL सर्वर की आपूर्ति कर सकते हैं। "पूर्ण" शब्द यहां महत्वपूर्ण है, क्योंकि SQL सर्वर और Azure SQL DB के बीच, सामान्य माता-पिता के बावजूद, कार्यात्मक अंतर हैं;

वर्चुअल मशीन की छवि Microsoft Azure स्टोरेज के साथ टिकी हुई है , जो एक अनुकूलन प्रकृति की सीमाएं लगाती है - डिस्क प्रदर्शन को बेहतर बनाने के लिए, आपको उदाहरण के लिए, उन्हें एक छापे में संयोजित करने की आवश्यकता है। डिफ़ॉल्ट रूप से Microsoft Azure में वर्चुअल मशीन के पास डिस्क नहीं होती है, जिसे एक छापे में जोड़ा जा सकता है - जब इसे बनाया जाता है, तो यह दो डिस्क प्राप्त करता है, एक डिस्क (D :) अस्थायी होने के कारण, यह उस सर्वर के डिस्क पर स्थित है जिस पर मशीन वर्तमान में चल रही है, और दूसरा (C :) को Microsoft Azure Storage पर एक Blob के रूप में होस्ट किया गया है, और सभी I / O अनुरोध कैशिंग परत के माध्यम से जाते हैं। इस कारण से, C: का प्रदर्शन हमेशा D से कम रहेगा: हालाँकि, D: वर्चुअल मशीन से प्रत्येक सिस्टम ऑपरेशन के दौरान (अन्य भौतिक संसाधनों में स्थानांतरण के कारण) क्लियर हो जाएगा। एक छापे बनाने के लिए, आपको मशीन पर खाली डेटा डिस्क (पोर्टल, पॉवर्सशेल और बहुत कुछ) बनाने और कनेक्ट करने की आवश्यकता है।







रेडी-मेड अनुकूलित SQL सर्वर छवियां (2008 R2 - 2014) पहले से ही Microsoft Azure में उपलब्ध हैं, जिनका उपयोग एक अलग से भुगतान किए गए लाइसेंस के साथ और अपना लाइसेंस लाकर (लाइसेंस गतिशीलता और सॉफ्टवेयर आश्वासन के तहत) दोनों में किया जा सकता है।

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



पा स वे



Paa दृष्टिकोण IaaS से बहुत अलग है, जिसमें बुनियादी ढाँचे, प्रतिबंधों और वास्तुशिल्प प्रसन्नता से अधिक डेवलपर सार हैं। बहुत नीचे, बुनियादी ढांचे और उपकरणों के स्तर पर, यह, निश्चित रूप से, एक ही मानकीकृत उपकरण है, इसलिए यदि आप Azure SQL DB के साझा मोड का उपयोग करते हैं, तो बेचैन पड़ोसियों की उपस्थिति में, प्रदर्शन पूरी तरह से अप्रत्याशित तरीके से डूब सकता है। सॉफ्ट / हार्ड प्रतिबंधों का एक सेट भी है, जो कि एक समझदार उद्देश्य के लिए किया जाता है - यदि हम एक वर्चुअल मशीन पर SQL सर्वर का प्रबंधन करते हैं, और हम प्रदर्शन और वास्तुकला की समस्याओं से निपटते हैं, पूरे फिर से, तो Paa पूरी तरह से विक्रेता द्वारा नियंत्रित किया जाता है, और आपको ऐसा करने की आवश्यकता है, ताकि समाधान अत्यधिक मापनीय और दोष-सहिष्णु हो, और बड़े मौसमी भार वाले बेचैन उपयोगकर्ता कुछ भी बुनियादी ढाँचे में न डालें।



उसी समय, जैसा कि ऊपर बताया गया है, डेवलपर द्वारा शार्डिंग और अन्य निर्णय लिए जाने चाहिए - अभी तक Azure SQL DB में कोई अंतर्निहित उपकरण नहीं हैं।



Azure SQL DB क्या है और यह कैसे काम करता है, इसे बेहतर ढंग से समझने के लिए, इसकी वास्तुकला पर विचार करें।



समझने वाली पहली बात - जब हम एज़्योर SQL डीबी सर्वर बनाते हैं, तो वास्तव में, तीन सर्वर बनाए जाते हैं, जो सामान्य तौर पर, सर्वर नहीं होते हैं - ये प्रतिकृतियां हैं, क्लाइंट से अनुरोध जिसमें से टीडीएस प्रविष्टि बिंदु से गुजरता है। पारंपरिक समाधान के साथ तुलना में, अपने आईपी सर्वर के मामले में, यह सर्वर की ओर जाता है, एज़्योर SQL डीबी के मामले में, आईपी बुनियादी ढांचे की ओर जाता है।







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









इसके अलावा, अनुरोध को प्लेटफ़ॉर्म लेयर पर रूट किया जाता है, जिस पर इन्फ्रास्ट्रक्चर सेवाएं चल रही हैं - ऐसा कुछ जो सर्विस के रूप में SQL सर्वर की तत्काल कार्यक्षमता प्रदान करता है। यह बुनियादी ढांचे पर अमूर्तता की अंतिम परत है, नीचे सिर्फ उपकरण है।

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

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







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

Azure SQL DB के कार्य के दौरान, मंच परत स्तर पर समस्याओं की निरंतर संभावना है - यह वह जगह है जहाँ विक्रेता द्वारा Azure SQL DB पर लगाए गए सभी प्रतिबंध लागू होते हैं, और यदि वे अधिक हो जाते हैं, तो संबंधित त्रुटि क्लाइंट को वापस कर दी जाएगी। यहां हम कुछ नहीं कर सकते हैं, एकमात्र विकल्प क्लाइंट साइड पर इन त्रुटियों को संभालना है (त्रुटियों की सूची msdn.microsoft.com/en-us/library/ff394106.aspx ) है।

Azure SQL DB के उपयोग को संक्षेप में, हमें निम्नलिखित स्थितियों को समझने और संभालने की आवश्यकता है:



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

एज़्योर SQL DB की सीमाएँ हैं जो एक कारण के लिए पेश की जाती हैं। यदि हम आराम से काम करना चाहते हैं, तो हमें यह नहीं देना चाहिए कि वे कितना देते हैं, बल्कि हमें कितनी ज़रूरत है, और यह ध्यान रखें कि कनेक्शन पूल रबर नहीं है।

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



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

आइए अब एक और महत्वपूर्ण पहलू पर नज़र डालते हैं - Azure SQL DB सुरक्षा। वर्चुअल मशीनों की सुरक्षा के बारे में, और इसलिए, उनमें SQL सर्वर, यह यहाँ लिखा है: blogs.msdn.com/b/albe/archive/2014/04/04/21/azure.aspx



PaaS Way : सुरक्षा



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



जैसा कि पहले ही लिखा गया है, SQL Azure डेटाबेस मानक SQL Server Tabular Data Stream (TDS) प्रोटोकॉल का उपयोग करता है, लेकिन विशेष रूप से एन्क्रिप्टेड संचार की अनुमति है। SQL सर्वर 2008 ने एक नई सुविधा शुरू की: पारदर्शी डेटा एन्क्रिप्शन (TDE), जो आपको न्यूनतम प्रयास के साथ डेटा को पूरी तरह से एन्क्रिप्ट करने की अनुमति देता है। हालाँकि, इस समय, SQL Azure डेटाबेस डेटाबेस-स्तर एन्क्रिप्शन का समर्थन नहीं करता है। यह ध्यान दिया जाना चाहिए कि वर्तमान में, Azure SQL DB केवल TCP कनेक्शन के माध्यम से और पोर्ट 1433 के माध्यम से उपलब्ध है। इसलिए, ADO.NET एन्क्रिप्शन क्षमताओं और प्रमाणपत्रों को ध्यान में रखना आवश्यक है। और, उदाहरण के लिए, Encrypt = True और TrustServerCertificate = गलत कनेक्शन के गुण संचारित डेटा की रक्षा करेंगे और मानव-मध्य हमलों को रोकने में मदद करेंगे। Azure SQL DB की दूसरी सुरक्षा विशेषता, और, सामान्य रूप से, मुख्य एक, Azure SQL DB फ़ायरवॉल है, जो शुरू में सर्वर तक सभी पहुंच को अवरुद्ध करता है। उपयुक्त सेटिंग्स से कनेक्ट करने का प्रयास विफल हो जाएगा। Azure SQL DB सर्वर के साथ काम करना शुरू करने के लिए, आपको Azure SQL DB पोर्टल पर जाने की आवश्यकता है और अपने सर्वर तक पहुँच के लिए फ़ायरवॉल सेटिंग्स निर्धारित करें। Azure SQL फ़ायरवॉल को Azure SQL DB पोर्टल या सीधे मास्टर डेटाबेस में संग्रहीत प्रक्रियाओं जैसे कि sp_set_firewall_rule और sp_delete_firewall_rule का उपयोग करके प्रबंधित किया जा सकता है।



किसी भी SQL सर्वर कार्यान्वयन के साथ, उपयोगकर्ता खाता प्रबंधन एक और पहलू है जिसे कसकर नियंत्रित करने की आवश्यकता है।

सुरक्षा संदर्भ में SQL सर्वर और SQL Azure डेटाबेस के बीच अंतर की एक सूची है:

Microsoft SQL सर्वर सक्रिय निर्देशिका से पहुँच सेटिंग्स का उपयोग करके Windows एकीकृत प्रमाणीकरण का समर्थन करता है; SQL Azure डेटाबेस केवल SQL सर्वर प्रमाणीकरण का समर्थन करता है।

Microsoft SQL सर्वर और SQL Azure डेटाबेस प्रत्येक डेटाबेस में बनाए गए उपयोगकर्ताओं और भूमिकाओं के आधार पर एक ही प्राधिकरण मॉडल का उपयोग करते हैं और उपयोगकर्ता लॉगिन के साथ जुड़े होते हैं।

Microsoft SQL सर्वर में serveradmin, Securityadmin और dbcreator जैसी मानक सर्वर-स्तरीय भूमिकाएँ होती हैं। SQL Azure डेटाबेस में ये भूमिकाएँ नहीं हैं। इसके बजाय, SQL Azure डेटाबेस में loginmanager (लॉगिन बनाने) और dbmanager (डेटाबेस बनाने और प्रबंधित करने) की भूमिकाएँ हैं। ये रोल मास्टर डेटाबेस में उपयोगकर्ताओं के साथ जुड़े हो सकते हैं।

SQL सर्वर और Azure SQL DB तक पहुँच Tabular Data Stream (TDS) अनुप्रयोग प्रोटोकॉल के माध्यम से होती है, जो कि TCP / 1433 पोर्ट के माध्यम से SSL द्वारा सुरक्षित है। SSL का उपयोग Microsoft SQL सर्वर के लिए वैकल्पिक है और Azure SQL DB के लिए आवश्यक है।

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

SQL सर्वर ट्रांसपेरेंट डेटा एनक्रिप्शन (TDE) कार्यक्षमता का उपयोग करके पेज स्तर पर सभी संग्रहीत डेटा का वास्तविक समय एन्क्रिप्शन प्रदान करता है। TDE Azure SQL DB में समर्थित नहीं है ।

Azure SQL DB में अंतर्निहित DDOS सुरक्षा है। SQL सर्वर में, कोई भी नहीं है।

एज़्योर SQL DB स्वचालित रूप से पैच किया जाता है और डाउनटाइम के बिना अपडेट किया जाता है। SQL सर्वर को अद्यतन करने की आवश्यकता है, और इससे डाउनटाइम हो सकता है।







इसलिए, सुरक्षा अंतर हैं, और उन्हें संबोधित करने की आवश्यकता है। कभी-कभी अवरोधक TDE की कमी है, कभी-कभी यह नहीं है - यह सब निर्णय पर निर्भर करता है। और अगले ब्लॉक मैं एसएलए में अंतर को देखने का प्रस्ताव करता हूं।



Azure SQL DB SLA - वर्चुअल मशीन में SQL सर्वर SLA से क्या अंतर है?



एसएलए किसी भी व्यावसायिक तैनाती का एक अनिवार्य हिस्सा है। एक Azure SQL DB SLA एक वर्चुअल मशीन में SQL Server SLA की तुलना में अधिक बारीक है, इस परिप्रेक्ष्य से कि SLA सीधे Azure SQL DB सेवा को प्रदान किया गया है और IaaS के मामले में अंतर्निहित अवसंरचना और वर्चुअल मशीन (लेकिन SQL सर्वर) को नहीं। यह मौलिक रूप से महत्वपूर्ण है। एज़्योर SQL DB पर SLA 99.9% है, जिसका अर्थ है प्रति कैलेंडर वर्ष में 10 घंटे का डाउनटाइम जो सेवा को पूरा करने के लिए जाता है। ग्राहक सेवा अग्रिम में चेतावनी दी है।



PaaS Way: उच्च उपलब्धता



Azure SQL DB को मूल रूप से उच्च उपलब्धता के तहत बनाया गया था, और वास्तुकला के सभी घटक दोष सहिष्णु हैं। यह समझना महत्वपूर्ण है कि SQL सर्वर के लिए HA मानक अवधारणाएं Azure SQL DB (फिर वास्तुशिल्प अंतर के कारण) पर लागू नहीं होती हैं। एज़्योर एसक्यूएल डीबी के अंदर, ऐसे तंत्र हैं जो तीन प्रतिकृतियों में सभी रिकॉर्ड्स को अलग-अलग सर्वरों में दोहराते हैं, जो 99.9% एसएलए प्रदान करता है। इसी समय, एक प्रतिकृति प्राथमिक है - इस पर एक लिखित ऑपरेशन किया जा रहा है, और अगर इसकी पुष्टि की जाती है, तो सब कुछ माध्यमिक प्रतिकृति के लिए सिंक्रोनस रूप से दोहराया जाता है।



यदि हम अपने दम पर Azure SQL DB को फिर से भरना चाहते हैं, तो कोई भी इसका उपयोग करने के लिए परेशान नहीं करता है, उदाहरण के लिए, डेटा सिंक।









Azure SQL DB के संचालन का तरीका कैसे चुनें?



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











एक अलग समीक्षा के लिए प्रीमियम मोड की आवश्यकता होती है। , , , . , , Azure SQL Database Benchmark

( , OLTP. Azure SQL DB Benchmark Database Throughput Units (DTU). DTU CPU, R/W. , DTU , . Azure SQL DB Benchmark Transaction Rate, , (basic — , standard — , premium ), , .

Premium. , Basic, 1 DTU, Premium P3 800 DTU, , , 800 , .



Azure SQL DB — msdn.microsoft.com/en-US/library/azure/dn741340.aspx







SQL Azure Databases – SQL Server PaaS. , , SQL Server ( , ), SQLAD , , , . , (IaaS PaaS) , , , , .