क्लाउड सेवाओं के लिए आप कंपाउंड सर्विस लेवल एग्रीमेंट (SLA) की गणना कैसे करते हैं?

Question

क्लाउड सेवाएं द्वारा की मेजबानी की अमेजन वेब सेवाओ , Azure , गूगल और सबसे दूसरों को प्रकाशित एस ervice एल evel एक greement व्यक्ति उनके द्वारा प्रदत्त सेवाओं के लिए, या SLA। आर्किटेक्ट्स, प्लेटफ़ॉर्म इंजीनियर्स और डेवलपर्स तब एक आर्किटेक्चर बनाने के लिए इन्हें एक साथ रखने के लिए जिम्मेदार होते हैं जो किसी एप्लिकेशन के लिए होस्टिंग प्रदान करता है।

अलगाव में लिया गया, ये सेवाएं आमतौर पर तीन से चार नौ की उपलब्धता की सीमा में कुछ प्रदान करती हैं:

• एज़्योर ट्रैफ़िक मैनेजर: 99.99% या 'चार निन्स'।
• एसक्यूएल अज़्योर: 99.99% या 'चार निन्स'।
• एज़्योर ऐप सेवा: 99.95% या 'तीन नौ पांच'।

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

सीरियल कंपाउंड की उपलब्धता

इस उदाहरण में तीन संभावित विफलता मोड हैं:

• SQL Azure नीचे है
• ऐप सेवा नीचे है
• दोनों नीचे हैं

इसलिए इस "सिस्टम" की समग्र उपलब्धता 99.95% से कम होनी चाहिए। यह सोचने के लिए मेरा तर्क है कि दोनों सेवाओं के लिए SLA था:

यह सेवा 24 में से 23 घंटे उपलब्ध होगी

फिर:

• ऐप सेवा 0100 और 0200 के बीच हो सकती है
• डेटाबेस 0500 और 0600 के बीच

दोनों घटक भाग अपने SLA के भीतर हैं, लेकिन कुल प्रणाली 24 में से 2 घंटे तक अनुपलब्ध थी।

सीरियल और समानांतर उपलब्धता

इस वास्तुकला में हालांकि मुख्य रूप से बड़ी संख्या में विफलता मोड हैं:

• क्षेत्र में SQL सर्वर नीचे है
• SQLB क्षेत्र में SQL सर्वर नीचे है
• क्षेत्र में ऐप सेवा नीचे है
• रीजनबी में ऐप सेवा बंद है
• ट्रैफिक मैनेजर नीचे है
• ऊपर के संयोजन

क्योंकि ट्रैफिक मैनेजर एक सर्किट ब्रेकर है जो किसी भी क्षेत्र में आउटेज का पता लगाने और कार्य क्षेत्र में ट्रैफ़िक को रूट करने में सक्षम है, हालाँकि ट्रैफ़िक मैनेजर के रूप में विफलता का एक बिंदु अभी भी है, इसलिए "सिस्टम" की कुल उपलब्धता नहीं हो सकती है 99.99% से अधिक हो।

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

यदि आप आरेखों को एनोटेट करना चाहते हैं, तो मैंने उन्हें ल्यूसिड चार्ट में बनाया है और एक बहु-उपयोग लिंक बनाया है, यह ध्यान रखें कि कोई भी इसे संपादित कर सकता है ताकि आप एनोटेट करने के लिए पृष्ठों की एक प्रति बनाना चाहें।

Comments

SPOF से सबसे कम SLA, यह मानते हुए कि आपका ऐप सत्र को तोड़ने में सक्षम है?

— तेंसिबाई

@Tensibai - मुझे नहीं लगता कि यह मेरे पहले उदाहरण के आधार पर हो सकता है, यदि दोनों सेवाओं के लिए SLA यह 24 में से 23 घंटे उपलब्ध होगा, तो ऐप सेवा 0100 और 0200 के बीच हो सकती है और डेटाबेस बाहर हो सकता है 0500 और 0600, दोनों घटक भाग उनके SLA के भीतर हैं लेकिन कुल प्रणाली 24 में से 2 घंटे तक अनुपलब्ध है। समझ में आता है?

— रिचर्ड स्लेटर

हां, समझ में आता है, लेकिन इस मामले में परिणाम सभी का उत्पाद होना चाहिए?

— तेनसीबाई

मेरा मतलब है कि ऐप 99.95 x sql 99.95 समूह की समग्र उपलब्धता होनी चाहिए

— Tensibai

यह भी ध्यान रखें कि आप एक ऐसी प्रणाली का निर्माण कर सकते हैं जो पूरी तरह से विफल होने के बजाय रिट्रीवर्स या फेलोवर्स या गिरावट के माध्यम से इसके घटकों से अधिक विश्वसनीय हो।

— Xiong Chiamiov

Answer 1

मुझे लगता है कि SLA के साथ एक गणित समस्या के रूप में ठीक होने की संभावना है।

इस मामले में हम समग्रता प्राप्त करने के लिए संभाव्यता नियमों पर भरोसा कर सकते हैं ।

आपके पहले मामले के लिए संभावना है कि एक ही समय में ऐप सेवा (ए) और एसक्यूएल सेवा (बी) नीचे हैं उनकी संभावना का उत्पाद है:

P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025

संभावना है कि उनमें से एक नीचे है उनकी संभावना का योग है:

P(A)+P(B) = 0.001

जब दो घटनाएँ स्वतंत्र होती हैं तो परिणामी सूत्र को ध्यान में रखते हुए दोनों की संभावना कम होती है:

P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975

तो कुल मिलाकर SLA 1 - 0,00099975 = 0,99900025प्रतिशत में विच होगा99.900025 %

एक सरलीकरण पहली संभावना का उत्पाद है 0.9995 * 0.9995 = 0,99900025:।

आपके 1h / 24h आउटेज पर लागू होता है (एक दिन का 4,166666%) यह देता है (दशमलव संक्षिप्त हैं):

0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222

तो ठीक होने की संभावना 1 - 0.0816 = 0.9184प्रतिशत में है:91,84%

24 * 0.0816 = 1.95 h

यह 2 घंटे के सबसे खराब मामले से कम है क्योंकि एक मौका है कि दोनों एक ही समय में नीचे हैं।

इस बात को ध्यान में रखते हुए, आप प्रत्येक के लिए उपलब्धता देख सकते हैं 95,84%और 0,958333333 * 0,958333333 = 0,918402778जो कि 91.84%ऊपर से हमारी है (यहाँ पूर्ण दशमलव के लिए खेद है, लेकिन वे प्रदर्शन के लिए आवश्यक हैं)

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

हमारे पास ट्रैफ़िक प्रबंधक ओके प्रायिकता P(T) = 0.9999और प्रत्येक ऐप + डीबी युगल से ओके प्रायिकता P(G) = 0,99900025है

हमारे पास एक क्षेत्र की भूमिका कितनी है, क्योंकि हमें विफलता की संभावना को लागू करने के लिए केवल दोनों ही क्षेत्र में एक ही समय में नीचे आने की संभावना है:
0,00099975 * 0,00099975 = 0,0000009995000625जिसका अर्थ है कम से कम एक क्षेत्र की समग्र उपलब्धता99,049375 %

अब हमारे पास समग्र क्षेत्र की उपलब्धता है, यातायात प्रबंधक के साथ उत्पाद हमें सिस्टम की समग्र उपलब्धता देता है:

0.9999 * 0,9999990004999375 = 0,99989900059988750625

समग्र उपलब्धता है 99.989900 %

स्पष्टीकरण के रूप में एक और स्रोत Azure के डॉक्स ( राज राव के शिष्टाचार लिंक ) पर उपलब्ध है

Comments

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

— रिचर्ड स्लेटर

ओह! मुझे यकीन था कि मैं पागल हो रहा था।

— रिचर्ड स्लेटर

@

— रीचर्डस्लेटर

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

— रिचर्ड स्लेटर

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

— तेनसीबाई

Answer 2

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

सीधे तौर पर तेनसीबाई के जवाब से मेरा सीरियल उदाहरण लेना प्रत्येक घटक की संभावना को दूसरे द्वारा उपलब्ध कराए जाने की संभावना को गुणा करने का मामला है:

इसलिए

99.95% * 99.95% = 99.9%

समानांतर में यह गिना जा रहा है एक छोटे से अधिक जटिल के रूप में हम विचार करने के लिए कितने प्रतिशत की जरूरत करना है संयुक्त राष्ट्र उपलब्धता हो जाएगा:

गणना निम्नानुसार की जाती है:

1. गुणा संयुक्त राष्ट्र एक साथ दोनों क्षेत्रों की उपलब्धता।

   0.1% * 0.1% = 0.0001%

2. उपलब्धता पर वापस कनवर्ट करें

   100% - 0.0001% = 99.9999%

3. दो क्षेत्रों की उपलब्धता से ट्रैफ़िक प्रबंधक की उपलब्धता को गुणा करें।

   99.99% * 99.9999% = 99.9899%

4. परिणाम पूरे सिस्टम की उपलब्धता है।

   99.9899% 99.99% के करीब है

मैंने गणनाएँ करने के लिए एक्सेल का उपयोग किया, यहाँ मूल्य दिए गए हैं:

... और सूत्र ...

Comments

यह है कि, मेरी तुलना में अधिक सरल तरीके से (मुझे पीछे के गणित को प्रदर्शित करने की आवश्यकता महसूस हुई :))

— तेंसिबाई

सहमत, आपका जवाब गणित के लिए वास्तव में अच्छा है।

— रिचर्ड स्लेटर

एसक्यूएल एज़्योर 99.99% नहीं 99.95% है

— जेफरी तांग

@JefferyTang यह (शायद) प्रश्न / उत्तर लिखने के समय (मुझे ठीक से याद नहीं है) पर था और वास्तविक मूल्य "व्यक्तिगत भागों SLA से यौगिक SLA की गणना कैसे करें" का उत्तर पाने के लिए कार्यप्रणाली में बदलाव नहीं करता है। असली सवाल है।

— तेनसीबाई