इलास्टिसिटी (क्लाउड कंप्यूटिंग): Difference between revisions
m (Abhishek moved page लोच (क्लाउड कंप्यूटिंग) to इलास्टिसिटी (क्लाउड कंप्यूटिंग) without leaving a redirect) |
No edit summary |
||
| Line 1: | Line 1: | ||
{{redirect| | {{redirect|इलास्टिक कंप्यूटिंग|भौतिक संपत्ति|लोच (भौतिकी)|अर्थशास्त्र माप|लोच (अर्थशास्त्र)}} | ||
[[ क्लाउड कंप्यूटिंग ]] में, लोच को उस डिग्री के रूप में परिभाषित किया जाता है, जिस तक एक सिस्टम स्वायत्त | |||
क्लाउड कंप्यूटिंग में, लोच को "उस डिग्री के रूप में परिभाषित किया जाता है, जिस तक एक सिस्टम स्वायत्त विधि से संसाधनों का प्रावधान और डी-प्रोविजनिंग करके वर्कलोड परिवर्तनों को अनुकूलित करने में सक्षम होता है, जैसे कि प्रत्येक बिंदु पर उपलब्ध संसाधन वर्तमान मांग से निकटता से मेल खाते हैं। यथासंभव"। | |||
[[ क्लाउड कंप्यूटिंग |क्लाउड कंप्यूटिंग]] में, लोच को उस डिग्री के रूप में परिभाषित किया जाता है, जिस तक एक सिस्टम स्वायत्त विधि से संसाधनों का प्रावधान और डी-प्रोविजनिंग करके वर्कलोड परिवर्तनों को अनुकूलित करने में सक्षम होता है, जैसे कि प्रत्येक बिंदु पर उपलब्ध संसाधन वर्तमान मांग से निकटता से मेल खाते हैं। मुमकिन ।<ref>{{cite journal|last=Herbst|first=Nikolas|author2=Samuel Kounev |author3=Ralf Reussner |title=क्लाउड कंप्यूटिंग में लोच: यह क्या है और यह क्या नहीं है|journal=Proceedings of the 10th International Conference on Autonomic Computing (ICAC 2013), San Jose, CA, June 24–28|year=2013|url=http://sdqweb.ipd.kit.edu/publications/pdfs/HeKoRe2013-ICAC-Elasticity.pdf}}</ref><ref>Nikolas Herbst, Rouven Krebs, Giorgos Oikonomou, George Kousiouris, Athanasia Evangelinou, Alexandru Iosup, and Samuel Kounev. Ready for Rain? A View from SPEC Research on the Future of Cloud Metrics. Technical Report SPEC-RG-2016-01, SPEC Research Group - Cloud Working Group, Standard Performance Evaluation Corporation (SPEC), 2016. [https://research.spec.org/fileadmin/user_upload/documents/rg_cloud/endorsed_publications/SPEC-RG-2016-01_CloudMetrics.pdf]</ref> लोच एक परिभाषित विशेषता है जो क्लाउड कंप्यूटिंग को [[ ग्रिड कंप्यूटिंग |ग्रिड कंप्यूटिंग]] जैसे पहले प्रस्तावित कंप्यूटिंग प्रतिमानों से अलग करती है। '''क्षमता का गतिशील अनुकूलन, उदाहरण के लिए, एक अलग कार्यभार को पूरा करने के लिए कंप्यूटिंग संसाधनों के उपयोग को परिवर्तित कर, लोचदार कंप्यूटिंग कहा जाता है।'''<ref>{{citation |title=Cloud Computing Principles and Paradigms |publisher=John Wiley and Sons |year=2011 |isbn=978-0-470-88799-8}}</ref><ref>{{citation |author=Perez |title=Responsive Elastic Computing |isbn=978-1-60558-578-9|display-authors=etal}}</ref> | |||
क्षमता का गतिशील अनुकूलन, उदाहरण के लिए, अलग-अलग वर्कलोड को पूरा करने के लिए कंप्यूटिंग संसाधनों के उपयोग को परिवर्तित कर "इलास्टिक कंप्यूटिंग" कहा जाता है। | |||
== उदाहरण == | == उदाहरण == | ||
आइए एक सेवा प्रदाता के एक सरल उदाहरण के माध्यम से लोच को स्पष्ट करें जो [[ IaaS ]] क्लाउड पर एक [[ वेबसाइट ]] चलाना चाहता है। इस वक्त <math>t_0</math>, वेबसाइट अलोकप्रिय है और एक मशीन (आमतौर पर एक [[ आभासी मशीन ]]) सभी वेब उपयोगकर्ताओं को सेवा देने के लिए पर्याप्त है। इस वक्त <math>t_1</math>, वेबसाइट अचानक लोकप्रिय हो जाती है, उदाहरण के लिए, एक [[ फ्लैश भीड़ ]] के परिणामस्वरूप, और एक मशीन अब सभी उपयोगकर्ताओं को सेवा देने के लिए पर्याप्त नहीं है। एक साथ वेबसाइट तक पहुँचने वाले वेब उपयोगकर्ताओं की संख्या और [[ वेब सर्वर ]] की संसाधन आवश्यकताओं के आधार पर, यह हो सकता है कि दस मशीनों की आवश्यकता हो। एक लोचदार प्रणाली को तुरंत इस स्थिति का पता लगाना चाहिए और क्लाउड से नौ अतिरिक्त मशीनों का प्रावधान करना चाहिए, ताकि सभी वेब उपयोगकर्ताओं को जिम्मेदारी से सेवा प्रदान की जा सके। | आइए एक सेवा प्रदाता के एक सरल उदाहरण के माध्यम से लोच को स्पष्ट करें जो [[ IaaS |IaaS]] क्लाउड पर एक [[ वेबसाइट |वेबसाइट]] चलाना चाहता है। इस वक्त <math>t_0</math>, वेबसाइट अलोकप्रिय है और एक मशीन (आमतौर पर एक [[ आभासी मशीन |आभासी मशीन]] ) सभी वेब उपयोगकर्ताओं को सेवा देने के लिए पर्याप्त है। इस वक्त <math>t_1</math>, वेबसाइट अचानक लोकप्रिय हो जाती है, उदाहरण के लिए, एक [[ फ्लैश भीड़ |फ्लैश भीड़]] के परिणामस्वरूप, और एक मशीन अब सभी उपयोगकर्ताओं को सेवा देने के लिए पर्याप्त नहीं है। एक साथ वेबसाइट तक पहुँचने वाले वेब उपयोगकर्ताओं की संख्या और [[ वेब सर्वर |वेब सर्वर]] की संसाधन आवश्यकताओं के आधार पर, यह हो सकता है कि दस मशीनों की आवश्यकता हो। एक लोचदार प्रणाली को तुरंत इस स्थिति का पता लगाना चाहिए और क्लाउड से नौ अतिरिक्त मशीनों का प्रावधान करना चाहिए, ताकि सभी वेब उपयोगकर्ताओं को जिम्मेदारी से सेवा प्रदान की जा सके। | ||
समय पर <math>t_2</math>, वेबसाइट फिर से अलोकप्रिय हो जाती है। वर्तमान में वेबसाइट को आवंटित की गई दस मशीनें ज्यादातर बेकार हैं और एक मशीन उन कुछ उपयोगकर्ताओं को सेवा प्रदान करने के लिए पर्याप्त होगी जो वेबसाइट तक पहुंच रहे हैं। एक लोचदार प्रणाली को तुरंत इस स्थिति का पता लगाना चाहिए और नौ मशीनों को हटा देना चाहिए और उन्हें क्लाउड पर छोड़ देना चाहिए। | समय पर <math>t_2</math>, वेबसाइट फिर से अलोकप्रिय हो जाती है। वर्तमान में वेबसाइट को आवंटित की गई दस मशीनें ज्यादातर बेकार हैं और एक मशीन उन कुछ उपयोगकर्ताओं को सेवा प्रदान करने के लिए पर्याप्त होगी जो वेबसाइट तक पहुंच रहे हैं। एक लोचदार प्रणाली को तुरंत इस स्थिति का पता लगाना चाहिए और नौ मशीनों को हटा देना चाहिए और उन्हें क्लाउड पर छोड़ देना चाहिए। | ||
== उद्देश्य == | == उद्देश्य == | ||
लोच का उद्देश्य किसी सेवा को आवंटित संसाधन की मात्रा का मिलान वास्तव में आवश्यक संसाधन की मात्रा के साथ करना है, अधिक या कम प्रावधान से बचना। आवश्यकता से अधिक संसाधनों के आवंटन से बचना चाहिए, क्योंकि सेवा प्रदाता को अक्सर उन संसाधनों के लिए भुगतान करना पड़ता है जो सेवा के लिए आवंटित किए जाते हैं। उदाहरण के लिए, एक [[ Amazon EC2 ]] M4 एक्स्ट्रा-लार्ज इंस्टेंस की कीमत US$0.239/घंटा है। यदि किसी सेवा ने केवल एक की आवश्यकता होने पर दो वर्चुअल मशीनें आवंटित की हैं, तो सेवा प्रदाता हर साल $2,095 बर्बाद करता है। इसलिए, सेवा प्रदाता के [[ खर्च ]] इष्टतम से अधिक होते हैं और उनका [[ लाभ (लेखा) ]] कम हो जाता है। | लोच का उद्देश्य किसी सेवा को आवंटित संसाधन की मात्रा का मिलान वास्तव में आवश्यक संसाधन की मात्रा के साथ करना है, अधिक या कम प्रावधान से बचना। आवश्यकता से अधिक संसाधनों के आवंटन से बचना चाहिए, क्योंकि सेवा प्रदाता को अक्सर उन संसाधनों के लिए भुगतान करना पड़ता है जो सेवा के लिए आवंटित किए जाते हैं। उदाहरण के लिए, एक [[ Amazon EC2 |Amazon EC2]] M4 एक्स्ट्रा-लार्ज इंस्टेंस की कीमत US$0.239/घंटा है। यदि किसी सेवा ने केवल एक की आवश्यकता होने पर दो वर्चुअल मशीनें आवंटित की हैं, तो सेवा प्रदाता हर साल $2,095 बर्बाद करता है। इसलिए, सेवा प्रदाता के [[ खर्च |खर्च]] इष्टतम से अधिक होते हैं और उनका [[ लाभ (लेखा) |लाभ (लेखा)]] कम हो जाता है। | ||
अंडर-प्रोविजनिंग, यानी आवश्यकता से कम संसाधन आवंटित करने से बचना चाहिए, अन्यथा सेवा अपने उपयोगकर्ताओं को अच्छी सेवा प्रदान नहीं कर सकती है। उपरोक्त उदाहरण में, वेबसाइट को कम प्रावधान करने से यह धीमी या अगम्य लग सकती है। वेब उपयोगकर्ता अंततः इसे एक्सेस करना छोड़ देते हैं, इस प्रकार, सेवा प्रदाता ग्राहकों को खो देता है। दीर्घावधि में, प्रदाता की [[ आय ]] में कमी आएगी, जिससे उनके लाभ में भी कमी आएगी। | अंडर-प्रोविजनिंग, यानी आवश्यकता से कम संसाधन आवंटित करने से बचना चाहिए, अन्यथा सेवा अपने उपयोगकर्ताओं को अच्छी सेवा प्रदान नहीं कर सकती है। उपरोक्त उदाहरण में, वेबसाइट को कम प्रावधान करने से यह धीमी या अगम्य लग सकती है। वेब उपयोगकर्ता अंततः इसे एक्सेस करना छोड़ देते हैं, इस प्रकार, सेवा प्रदाता ग्राहकों को खो देता है। दीर्घावधि में, प्रदाता की [[ आय |आय]] में कमी आएगी, जिससे उनके लाभ में भी कमी आएगी। | ||
== समस्याएं == | == समस्याएं == | ||
| Line 20: | Line 26: | ||
=== लोचदार अनुप्रयोगों की निगरानी === | === लोचदार अनुप्रयोगों की निगरानी === | ||
लोचदार अनुप्रयोग विशिष्ट अनुप्रयोग घटकों की मांग पर संसाधनों (जैसे वीएम) को आवंटित और हटा सकते हैं। यह क्लाउड संसाधनों को अस्थिर बनाता है, और पारंपरिक निगरानी उपकरण जो मॉनिटरिंग डेटा को एक विशेष संसाधन (यानी वीएम) के साथ जोड़ते हैं, जैसे [[ गंगालिया (सॉफ्टवेयर) ]] या [[ Nagios ]], अब लोचदार अनुप्रयोगों के व्यवहार की निगरानी के लिए उपयुक्त नहीं हैं। उदाहरण के लिए, अपने जीवनकाल के दौरान, एक लोचदार अनुप्रयोग का डेटा स्टोरेज स्तर लागत और प्रदर्शन आवश्यकताओं के कारण डेटा स्टोरेज वीएम को जोड़ और हटा सकता है, प्रयुक्त वीएम की संख्या बदलती है। इस प्रकार, लोचदार अनुप्रयोगों की निगरानी में अतिरिक्त जानकारी की आवश्यकता होती है, जैसे कि अंतर्निहित वर्चुअल इन्फ्रास्ट्रक्चर पर तार्किक अनुप्रयोग संरचना को जोड़ना।<ref>{{cite book|last=Moldovan|first=Daniel |author2=Georgiana Copil |author3=Hong-Linh Truong |author4=Schahram Dustdar|title=मेला: क्लाउड सेवाओं की लोच की निगरानी और विश्लेषण|journal=Proceedings of IEEE 5th International Conference on Cloud Computing Technology and Science (CloudCom 2013)|volume=1 |pages=80–87 |year=2013|doi=10.1109/CloudCom.2013.18|isbn=978-0-7695-5095-4 }}</ref> यह बदले में अन्य समस्याएं उत्पन्न करता है, जैसे कि उन वीएम के शीर्ष पर चल रहे एप्लिकेशन घटक के व्यवहार को निकालने के लिए कई वीएम से डेटा को कैसे एकत्र किया जाए, क्योंकि अलग-अलग मेट्रिक्स को अलग-अलग एकत्र करने की आवश्यकता हो सकती है (उदाहरण के लिए, सीपीयू उपयोग औसत किया जा सकता है, नेटवर्क स्थानांतरण योग हो सकता है)। | लोचदार अनुप्रयोग विशिष्ट अनुप्रयोग घटकों की मांग पर संसाधनों (जैसे वीएम) को आवंटित और हटा सकते हैं। यह क्लाउड संसाधनों को अस्थिर बनाता है, और पारंपरिक निगरानी उपकरण जो मॉनिटरिंग डेटा को एक विशेष संसाधन (यानी वीएम) के साथ जोड़ते हैं, जैसे [[ गंगालिया (सॉफ्टवेयर) |गंगालिया (सॉफ्टवेयर)]] या [[ Nagios |Nagios]] , अब लोचदार अनुप्रयोगों के व्यवहार की निगरानी के लिए उपयुक्त नहीं हैं। उदाहरण के लिए, अपने जीवनकाल के दौरान, एक लोचदार अनुप्रयोग का डेटा स्टोरेज स्तर लागत और प्रदर्शन आवश्यकताओं के कारण डेटा स्टोरेज वीएम को जोड़ और हटा सकता है, प्रयुक्त वीएम की संख्या बदलती है। इस प्रकार, लोचदार अनुप्रयोगों की निगरानी में अतिरिक्त जानकारी की आवश्यकता होती है, जैसे कि अंतर्निहित वर्चुअल इन्फ्रास्ट्रक्चर पर तार्किक अनुप्रयोग संरचना को जोड़ना।<ref>{{cite book|last=Moldovan|first=Daniel |author2=Georgiana Copil |author3=Hong-Linh Truong |author4=Schahram Dustdar|title=मेला: क्लाउड सेवाओं की लोच की निगरानी और विश्लेषण|journal=Proceedings of IEEE 5th International Conference on Cloud Computing Technology and Science (CloudCom 2013)|volume=1 |pages=80–87 |year=2013|doi=10.1109/CloudCom.2013.18|isbn=978-0-7695-5095-4 }}</ref> यह बदले में अन्य समस्याएं उत्पन्न करता है, जैसे कि उन वीएम के शीर्ष पर चल रहे एप्लिकेशन घटक के व्यवहार को निकालने के लिए कई वीएम से डेटा को कैसे एकत्र किया जाए, क्योंकि अलग-अलग मेट्रिक्स को अलग-अलग एकत्र करने की आवश्यकता हो सकती है (उदाहरण के लिए, सीपीयू उपयोग औसत किया जा सकता है, नेटवर्क स्थानांतरण योग हो सकता है)। | ||
=== लोच आवश्यकताओं === | === लोच आवश्यकताओं === | ||
Revision as of 19:53, 19 January 2023
क्लाउड कंप्यूटिंग में, लोच को "उस डिग्री के रूप में परिभाषित किया जाता है, जिस तक एक सिस्टम स्वायत्त विधि से संसाधनों का प्रावधान और डी-प्रोविजनिंग करके वर्कलोड परिवर्तनों को अनुकूलित करने में सक्षम होता है, जैसे कि प्रत्येक बिंदु पर उपलब्ध संसाधन वर्तमान मांग से निकटता से मेल खाते हैं। यथासंभव"।
क्लाउड कंप्यूटिंग में, लोच को उस डिग्री के रूप में परिभाषित किया जाता है, जिस तक एक सिस्टम स्वायत्त विधि से संसाधनों का प्रावधान और डी-प्रोविजनिंग करके वर्कलोड परिवर्तनों को अनुकूलित करने में सक्षम होता है, जैसे कि प्रत्येक बिंदु पर उपलब्ध संसाधन वर्तमान मांग से निकटता से मेल खाते हैं। मुमकिन ।[1][2] लोच एक परिभाषित विशेषता है जो क्लाउड कंप्यूटिंग को ग्रिड कंप्यूटिंग जैसे पहले प्रस्तावित कंप्यूटिंग प्रतिमानों से अलग करती है। क्षमता का गतिशील अनुकूलन, उदाहरण के लिए, एक अलग कार्यभार को पूरा करने के लिए कंप्यूटिंग संसाधनों के उपयोग को परिवर्तित कर, लोचदार कंप्यूटिंग कहा जाता है।[3][4]
क्षमता का गतिशील अनुकूलन, उदाहरण के लिए, अलग-अलग वर्कलोड को पूरा करने के लिए कंप्यूटिंग संसाधनों के उपयोग को परिवर्तित कर "इलास्टिक कंप्यूटिंग" कहा जाता है।
उदाहरण
आइए एक सेवा प्रदाता के एक सरल उदाहरण के माध्यम से लोच को स्पष्ट करें जो IaaS क्लाउड पर एक वेबसाइट चलाना चाहता है। इस वक्त , वेबसाइट अलोकप्रिय है और एक मशीन (आमतौर पर एक आभासी मशीन ) सभी वेब उपयोगकर्ताओं को सेवा देने के लिए पर्याप्त है। इस वक्त , वेबसाइट अचानक लोकप्रिय हो जाती है, उदाहरण के लिए, एक फ्लैश भीड़ के परिणामस्वरूप, और एक मशीन अब सभी उपयोगकर्ताओं को सेवा देने के लिए पर्याप्त नहीं है। एक साथ वेबसाइट तक पहुँचने वाले वेब उपयोगकर्ताओं की संख्या और वेब सर्वर की संसाधन आवश्यकताओं के आधार पर, यह हो सकता है कि दस मशीनों की आवश्यकता हो। एक लोचदार प्रणाली को तुरंत इस स्थिति का पता लगाना चाहिए और क्लाउड से नौ अतिरिक्त मशीनों का प्रावधान करना चाहिए, ताकि सभी वेब उपयोगकर्ताओं को जिम्मेदारी से सेवा प्रदान की जा सके।
समय पर , वेबसाइट फिर से अलोकप्रिय हो जाती है। वर्तमान में वेबसाइट को आवंटित की गई दस मशीनें ज्यादातर बेकार हैं और एक मशीन उन कुछ उपयोगकर्ताओं को सेवा प्रदान करने के लिए पर्याप्त होगी जो वेबसाइट तक पहुंच रहे हैं। एक लोचदार प्रणाली को तुरंत इस स्थिति का पता लगाना चाहिए और नौ मशीनों को हटा देना चाहिए और उन्हें क्लाउड पर छोड़ देना चाहिए।
उद्देश्य
लोच का उद्देश्य किसी सेवा को आवंटित संसाधन की मात्रा का मिलान वास्तव में आवश्यक संसाधन की मात्रा के साथ करना है, अधिक या कम प्रावधान से बचना। आवश्यकता से अधिक संसाधनों के आवंटन से बचना चाहिए, क्योंकि सेवा प्रदाता को अक्सर उन संसाधनों के लिए भुगतान करना पड़ता है जो सेवा के लिए आवंटित किए जाते हैं। उदाहरण के लिए, एक Amazon EC2 M4 एक्स्ट्रा-लार्ज इंस्टेंस की कीमत US$0.239/घंटा है। यदि किसी सेवा ने केवल एक की आवश्यकता होने पर दो वर्चुअल मशीनें आवंटित की हैं, तो सेवा प्रदाता हर साल $2,095 बर्बाद करता है। इसलिए, सेवा प्रदाता के खर्च इष्टतम से अधिक होते हैं और उनका लाभ (लेखा) कम हो जाता है।
अंडर-प्रोविजनिंग, यानी आवश्यकता से कम संसाधन आवंटित करने से बचना चाहिए, अन्यथा सेवा अपने उपयोगकर्ताओं को अच्छी सेवा प्रदान नहीं कर सकती है। उपरोक्त उदाहरण में, वेबसाइट को कम प्रावधान करने से यह धीमी या अगम्य लग सकती है। वेब उपयोगकर्ता अंततः इसे एक्सेस करना छोड़ देते हैं, इस प्रकार, सेवा प्रदाता ग्राहकों को खो देता है। दीर्घावधि में, प्रदाता की आय में कमी आएगी, जिससे उनके लाभ में भी कमी आएगी।
समस्याएं
संसाधन प्रावधान समय
एक संभावित समस्या यह है कि लोच में समय लगता है। क्लाउड वर्चुअल मशीन (VM) को उपयोगकर्ता द्वारा किसी भी समय प्राप्त किया जा सकता है; हालाँकि, अधिग्रहीत VM को उपयोग के लिए तैयार होने में कई मिनट लग सकते हैं। वीएम स्टार्टअप समय कारकों पर निर्भर है, जैसे कि छवि का आकार, वीएम प्रकार, डेटा सेंटर स्थान, वीएम की संख्या आदि।[5] क्लाउड प्रदाताओं का VM स्टार्टअप प्रदर्शन भिन्न होता है। इसका तात्पर्य लोचदार अनुप्रयोगों के लिए डिज़ाइन किए गए किसी भी नियंत्रण तंत्र को अपनी निर्णय प्रक्रिया में लोच क्रियाओं के प्रभावी होने के लिए आवश्यक समय पर विचार करना चाहिए,[6] जैसे किसी विशिष्ट अनुप्रयोग घटक के लिए अन्य वीएम का प्रावधान करना।
लोचदार अनुप्रयोगों की निगरानी
लोचदार अनुप्रयोग विशिष्ट अनुप्रयोग घटकों की मांग पर संसाधनों (जैसे वीएम) को आवंटित और हटा सकते हैं। यह क्लाउड संसाधनों को अस्थिर बनाता है, और पारंपरिक निगरानी उपकरण जो मॉनिटरिंग डेटा को एक विशेष संसाधन (यानी वीएम) के साथ जोड़ते हैं, जैसे गंगालिया (सॉफ्टवेयर) या Nagios , अब लोचदार अनुप्रयोगों के व्यवहार की निगरानी के लिए उपयुक्त नहीं हैं। उदाहरण के लिए, अपने जीवनकाल के दौरान, एक लोचदार अनुप्रयोग का डेटा स्टोरेज स्तर लागत और प्रदर्शन आवश्यकताओं के कारण डेटा स्टोरेज वीएम को जोड़ और हटा सकता है, प्रयुक्त वीएम की संख्या बदलती है। इस प्रकार, लोचदार अनुप्रयोगों की निगरानी में अतिरिक्त जानकारी की आवश्यकता होती है, जैसे कि अंतर्निहित वर्चुअल इन्फ्रास्ट्रक्चर पर तार्किक अनुप्रयोग संरचना को जोड़ना।[7] यह बदले में अन्य समस्याएं उत्पन्न करता है, जैसे कि उन वीएम के शीर्ष पर चल रहे एप्लिकेशन घटक के व्यवहार को निकालने के लिए कई वीएम से डेटा को कैसे एकत्र किया जाए, क्योंकि अलग-अलग मेट्रिक्स को अलग-अलग एकत्र करने की आवश्यकता हो सकती है (उदाहरण के लिए, सीपीयू उपयोग औसत किया जा सकता है, नेटवर्क स्थानांतरण योग हो सकता है)।
लोच आवश्यकताओं
क्लाउड इन्फ्रास्ट्रक्चर (IaaS/PaaS) में अनुप्रयोगों को तैनात करते समय, उचित लोच व्यवहार सुनिश्चित करने के लिए हितधारक की आवश्यकताओं पर विचार किया जाना चाहिए। भले ही पारंपरिक रूप से लागत और गुणवत्ता या प्रदर्शन के बीच इष्टतम व्यापार-बंद खोजने की कोशिश की जाएगी, वास्तविक दुनिया के क्लाउड उपयोगकर्ताओं के लिए व्यवहार के संबंध में आवश्यकताएं अधिक जटिल हैं और लोच के कई आयामों को लक्षित करती हैं (जैसे, SYBL)[8]).
नियंत्रण के कई स्तर
परतों में तैनात कई स्तरों की कलाकृतियों के साथ क्लाउड एप्लिकेशन विभिन्न प्रकार और जटिलताओं के हो सकते हैं। ऐसी संरचनाओं को नियंत्रित करने के लिए विभिन्न प्रकार के मुद्दों को ध्यान में रखना चाहिए, इस अर्थ में एक दृष्टिकोण rSYBL है।[9] बहु-स्तरीय नियंत्रण के लिए, नियंत्रण प्रणालियों को प्रभाव पर विचार करने की आवश्यकता होती है जो निचले स्तर के नियंत्रण का प्रभाव उच्च स्तर पर होता है और इसके विपरीत (जैसे, आभासी मशीनों, वेब कंटेनरों, या वेब सेवाओं को एक ही समय में नियंत्रित करना), साथ ही साथ संघर्ष जो दिखाई दे सकते हैं विभिन्न स्तरों से विभिन्न नियंत्रण रणनीतियों के बीच।[10] बादलों पर लोचदार रणनीतियाँ नियंत्रण-सैद्धांतिक विधियों का लाभ उठा सकती हैं (उदाहरण के लिए, प्रतिक्रियात्मक तरीकों के संबंध में काफी लाभ दिखाते हुए क्लाउड परिदृश्यों में भविष्य कहनेवाला नियंत्रण का प्रयोग किया गया है)।[11]
यह भी देखें
- माइक्रोसॉफ्ट एज़्योर
- अमेज़न इलास्टिक कंप्यूट क्लाउड
- CELAR|CELAR: क्लाउड इलास्टिसिटी प्रोविजनिंग
संदर्भ
- ↑ Herbst, Nikolas; Samuel Kounev; Ralf Reussner (2013). "क्लाउड कंप्यूटिंग में लोच: यह क्या है और यह क्या नहीं है" (PDF). Proceedings of the 10th International Conference on Autonomic Computing (ICAC 2013), San Jose, CA, June 24–28.
- ↑ Nikolas Herbst, Rouven Krebs, Giorgos Oikonomou, George Kousiouris, Athanasia Evangelinou, Alexandru Iosup, and Samuel Kounev. Ready for Rain? A View from SPEC Research on the Future of Cloud Metrics. Technical Report SPEC-RG-2016-01, SPEC Research Group - Cloud Working Group, Standard Performance Evaluation Corporation (SPEC), 2016. [1]
- ↑ Cloud Computing Principles and Paradigms, John Wiley and Sons, 2011, ISBN 978-0-470-88799-8
- ↑ Perez; et al., Responsive Elastic Computing, ISBN 978-1-60558-578-9
- ↑ Mao, Ming; M. Humphrey (2012). क्लाउड में वीएम स्टार्टअप टाइम पर एक प्रदर्शन अध्ययन. p. 423. doi:10.1109/CLOUD.2012.103. ISBN 978-1-4673-2892-0.
{{cite book}}:|journal=ignored (help) - ↑ Gambi, Alessio; Daniel Moldovan; Georgiana Copil; Hong-Linh Truong; Schahram Dustdar (2013). इलास्टिक कंप्यूटिंग सिस्टम में एक्चुएशन देरी का अनुमान लगाने पर. pp. 33–42. CiteSeerX 10.1.1.353.691. doi:10.1109/SEAMS.2013.6595490. ISBN 978-1-4673-4401-2.
{{cite book}}:|journal=ignored (help) - ↑ Moldovan, Daniel; Georgiana Copil; Hong-Linh Truong; Schahram Dustdar (2013). मेला: क्लाउड सेवाओं की लोच की निगरानी और विश्लेषण. pp. 80–87. doi:10.1109/CloudCom.2013.18. ISBN 978-0-7695-5095-4.
{{cite book}}:|journal=ignored (help) - ↑ Georgiana Copil, Daniel Moldovan, Hong-Linh Truong, Schahram Dustdar, "SYBL: an Extensible Language for Controlling Elasticity in Cloud Applications", Proceedings of the 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), May 14–16, 2013, Delft, the Netherlands
- ↑ Georgiana Copil, Daniel Moldovan, Hong-Linh Truong, Schahram Dustdar, "Specifying, Monitoring, and Controlling Elasticity of Cloud Services", Proceedings of the 11th International Conference on Service Oriented Computing. Berlin, Germany, 2–5 December 2013. doi=10.1007/978-3-642-45005-1_31
- ↑ Kranas, Pavlos (2012). ElaaS: क्लाउड स्टैक परतों में गतिशील प्रबंधन के लिए एक सेवा ढांचे के रूप में एक अभिनव लोच. pp. 1042–1049. doi:10.1109/CISIS.2012.117. ISBN 978-1-4673-1233-2.
{{cite book}}:|journal=ignored (help) - ↑ Mencagli, Gabriele; Vanneschi, Marco (6 February 2014). "मॉडल भविष्य कहनेवाला नियंत्रण का उपयोग करके संरचित समानांतर संगणनाओं के गतिशील अनुकूलन के लिए एक व्यवस्थित दृष्टिकोण की ओर". Cluster Computing. 17 (4): 1443–1463. doi:10.1007/s10586-014-0346-3.
इस पेज में लापता आंतरिक लिंक की सूची
बाहरी कड़ियाँ
- The NIST Definition of Cloud Computing. Peter Mell and Timothy Grance, NIST Special Publication 800-145 (September 2011). National Institute of Standards and Technology, U.S. Department of Commerce.
