ओपनस्टैक बड़े पैमाने पर बेंचमार्किंग: हमने सॉफ्टलेयर में मिरांटिस ओपनस्टैक का परीक्षण कैसे किया

लेखक: ओलेग गेल्बुख



ऐसा लगता है कि क्लाउड कंप्यूटिंग उद्योग में शामिल लोगों की चिंता का एक मुख्य मुद्दा ओपन लोडैक का सवाल था जो पीक लोड पर उद्यम स्तर पर उपयोग के लिए तैयार है। आम बातचीत के विषयों में एक पैमाने पर ओपनस्टैक-आधारित क्लाउड सेवाओं की स्थिरता और प्रदर्शन शामिल हैं। लेकिन पैमाने का क्या मतलब है? वास्तविक दुनिया में किस स्तर का स्तर लागू है?



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



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

सॉफ्टलेनयर पर आधारित स्केलिंग मिरांटिस ओपनस्टैक

हमने इस तरह के वर्चुअल डेटा सेंटर में लोड होने के कारण मिरांटिस ओपनस्टैक प्लेटफॉर्म के वांछित व्यवहार का मूल्यांकन करने का निर्णय लिया। आईबीएम सॉफ्टलेयर से अपने दोस्तों के साथ सहयोग करते हुए, हमने दो स्थानों पर स्थित 350 भौतिक मशीनों का एक आधारभूत ढांचा तैयार किया। शुरू करने के लिए, हम मिरांटिस ओपनकैक पर चलने वाले आभासी डेटा केंद्रों के लिए एक सेवा स्तर समझौते (एसएलए) के तहत एक निश्चित बुनियादी स्तर स्थापित करना चाहते थे।



जाहिर है, आकार मायने रखता है। लेकिन सॉफ्टलेयर में ओपनस्टैक वर्चुअल डेटा सेंटर के संबंध में अन्य प्रश्न थे, जिनका हमने शुरुआत से ही उत्तर देना महत्वपूर्ण समझा। उदाहरण के लिए:

• क्या क्लाउड-आधारित वर्चुअल डेटा सेंटर एक बार में सैकड़ों अनुरोधों को पूरा कर सकता है?



• वर्चुअल डेटा सेंटर में वर्चुअल सर्वर की संख्या में वृद्धि उपयोगकर्ता के अनुभव को प्रभावित करेगी?



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







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



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



मूल SLA पैरामीटर जिन्हें हम परीक्षण करना चाहते थे वे इस प्रकार हैं:

• वर्चुअल सर्वर इंस्टेंसेस के लोडिंग समय का फैलाव, समय और क्लाउड डेटाबेस में वर्चुअल इंस्टेंस की संख्या के बीच संबंध सहित;



• हमारे उदाहरणों के लिए लोडिंग प्रक्रिया की सफलता का प्रतिशत, दूसरे शब्दों में, 100 में से कितने अनुरोध एक कारण या किसी अन्य के लिए विफल होंगे।



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

ओपनस्टैक बेंचमार्किंग के लिए एक टेस्ट पर्यावरण की स्थापना

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



आवश्यक संसाधनों की मात्रा निर्धारित करने के लिए, हम पहले ओपनस्टैक के संदर्भ में, उदाहरण के प्रकार या विविधता को निर्धारित करते हैं: 1 वर्चुअल प्रोसेसर, 64 एमबी रैम और एक 2 जीबी हार्ड ड्राइव (जो कि उदाहरण के लिए, उदाहरण के लिए m1 .micro AWS से बहुत छोटा है)। यह एक Cirros परीक्षण छवि को लोड करने के लिए पर्याप्त है।



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



संसाधनों की कुल राशि:

• 100,000 वर्चुअल प्रोसेसर (vCPU);



• 6250 जीबी की रैम;



• डिस्क स्थान की 200TB।



इसलिए, हमने तय किया कि इस परीक्षण के लिए कंप्यूटिंग सर्वर का एक प्रतिनिधि विन्यास 4 भौतिक कोर (एचटी के लिए +4), 16 जीबी रैम और 250 जीबी डिस्क स्थान के साथ एक कॉन्फ़िगरेशन होगा। चूंकि हम वीएम पर किसी भी वास्तविक भार की अनुमति नहीं देने वाले हैं, इसलिए हम आसानी से 1:32 के अनुपात में सीपीयू को पुनर्वितरित कर सकते हैं (दो बार डिफ़ॉल्ट रूप से ओपनस्टैक के लिए निर्धारित ओवरकमिटी रेट) और 1: 1.5 के अनुपात में रैम को फिर से विभाजित करें। , जो हमें 250 नोड प्रति भौतिक नोड के बराबर घनत्व देता है। इस तरह के गैर-मानक पुनर्वितरण गुणांक के साथ, हमें 100 हजार वीएम के लक्ष्य को प्राप्त करने के लिए केवल 400 हार्डवेयर सर्वर की आवश्यकता थी।



यह जानते हुए कि अधिकतम भार हमारे नियंत्रकों पर होगा, हम उनके लिए एक उन्नत सर्वर कॉन्फ़िगरेशन निर्धारित करते हैं। प्रत्येक नियंत्रक के पास डेटा संग्रहीत करने के लिए 128GB RAM और एक ठोस-राज्य हार्ड ड्राइव (SSD) था, जिसने नियंत्रक के आधार पर OpenStack राज्य डेटाबेस के संचालन में तेजी लाने की अनुमति दी।

एक दिलचस्प नोट: कम्प्यूट और कंट्रोलर नोड्स के कॉन्फ़िगरेशन में अंतर के कारण, उनके प्रोविजनिंग को विभिन्न सॉफ्टलेयर डेटा केंद्रों में उनके बीच 40ms की देरी के साथ किया गया था; यह उम्मीद करना अजीब नहीं होगा कि एक वास्तविक क्लस्टर में आपके पास बिल्कुल समान कॉन्फ़िगरेशन हो सकता है। सौभाग्य से, सॉफ्टलेयर डेटा केंद्रों के बीच छोटी देरी के कारण, बेंचमार्किंग के दौरान इस तरह के वितरित वास्तुकला का कोई महत्वपूर्ण प्रभाव नहीं देखा गया था।

ओपनस्टैक विवरण

हमने मिरांटिस ओपनस्टैक के रिलीज़ 4.0 का उपयोग किया, जिसमें ओपनस्टैक 2013.2 (हवाना) शामिल है, और इसे सॉफ्टलेयर द्वारा प्रदान किए गए सर्वरों पर तैनात किया है। ऐसा करने के लिए, हमें अपने परिनियोजन फ्रेमवर्क को थोड़ा बदलना पड़ा: चूँकि हम मिरांटिस ओपनस्टैक आईएसओ को सॉफ्टलेयर पर अपलोड नहीं कर पाए, इसलिए हमने मानक ऑपरेटिंग सिस्टम इमेज के माध्यम से rsync का उपयोग करके आवश्यक कोड की प्रतिलिपि बनाई। तैनाती के बाद, क्लस्टर बेंचमार्किंग के लिए तैयार था।



हमारे कॉन्फ़िगरेशन में केवल तीन ओपनस्टैक सेवाएं शामिल थीं: कंप्यूट (नोवा), छवि (झलक) और पहचान (कीस्टोन)। यह हमारे उपयोग के मामलों (मोबाइल प्लेटफ़ॉर्म का परीक्षण) के लिए पर्याप्त, कम्प्यूट सेवा की मूल कार्यक्षमता प्रदान करता है।



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



बेंचमार्क परीक्षण करते समय, हमें डिफ़ॉल्ट ओपनस्टैक कॉन्फ़िगरेशन के कुछ मापदंडों के मूल्यों को बढ़ाना पड़ा। सबसे महत्वपूर्ण परिवर्तन SQLAlchemy मॉड्यूल (max_pool_size और nova.conf फ़ाइल में max_overflow पैरामीटर) के लिए कनेक्शन पूल आकार है। अन्य सभी पहलुओं में, हमने उच्च उपलब्धता के मानक मिरांटिस ओपनस्टैक आर्किटेक्चर का उपयोग किया, जिसमें बहु-होस्ट सिंक्रोनस प्रतिकृति डेटाबेस (MySQL + Galera), एपीआई सेवाओं के लिए सॉफ्टवेयर लोड बैलेंसर (हैप्रोक्सी) और कोरोसिंक / पेसमेकर शामिल हैं, जो उच्च स्तर पर उपलब्धता को सुनिश्चित करते हैं। आईपी।

एक बेंचमार्किंग टूल के रूप में रैली

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



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

संदर्भ विन्यास कुछ इस तरह दिखता है:



{

"निष्पादन": "निरंतर",

"विन्यास": {

किरायेदारों: 500,

"Users_per_tenant": 1,

Active_users: 250,

"टाइम्स": 25000

}

"आर्ग्स": {

"Image_id": "0aca7aff-b7d8-4176-a0b1-f498d9396c9f",

फ्लेवर_ड: १

}

}



इस कॉन्फ़िगरेशन में पैरामीटर निम्नानुसार हैं:

• निष्पादन - बेंचमार्किंग टूल के संचालन का तरीका। यदि मान "निरंतर" है, तो पिछला परिणाम वापस आने पर (या टाइमआउट समाप्त हो जाता है) रैली वर्कफ़्लो अगला अनुरोध जारी करेगा।



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



• users_per_tenant - उपरोक्त अस्थायी परियोजनाओं में से प्रत्येक में बनाए गए अस्थायी अंत उपयोगकर्ताओं की संख्या। रैली स्ट्रीम इस सूची से यादृच्छिक रूप से चयनित उपयोगकर्ताओं की ओर से वास्तविक अनुरोध भेजती हैं।



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



• बार - बेंचमार्किंग के दौरान भेजे गए अनुरोधों की कुल संख्या। इस मूल्य के आधार पर, सफलता का प्रतिशत निर्धारित किया जाता है।



• image_id और flavor_id - वर्चुअल सर्वर शुरू करने के लिए उपयोग किए जाने वाले क्लस्टर-विशिष्ट पैरामीटर। रैली संदर्भ पुनरावृत्ति में सभी सर्वरों के लिए समान रूप और दृश्य का उपयोग करती है।



• nics - प्रत्येक वर्चुअल सर्वर से कनेक्ट होने के लिए नेटवर्क की संख्या। डिफ़ॉल्ट रूप से, केवल एक ऐसा नेटवर्क है (यह डिफ़ॉल्ट रूप से प्रोजेक्ट के लिए निर्दिष्ट नेटवर्क है)।

बेंचमार्किंग प्रक्रिया

सबसे पहले, हम एक ही समय में अनुरोध भेजने के लिए एक स्थिर गति निर्धारित करते हैं। ऐसा करने के लिए, हमने संदर्भ कॉन्फ़िगरेशन का एक सेट बनाया, जो केवल दो मापदंडों में भिन्न होता है - किरायेदारों और सक्रिय_सर्स - 100 से 500 तक। शुरू करने के लिए आवश्यक वीएम की संख्या 5000 या 25000 थी। शुरुआती चरणों में संसाधनों को बचाने के लिए, हमने और अधिक के साथ शुरुआत की 200 कंप्यूट सर्वर और 3 नियंत्रक सर्वर का एक छोटा समूह।

नीचे दिए गए आरेख एक विशिष्ट वर्चुअल सर्वर के प्रारंभ समय की निर्भरता को एक साथ निष्पादित अनुरोधों की संख्या पर दिखाते हैं।







टेस्ट रन 1.1। 100 समवर्ती सत्र, 5000 वी.एम.



कुल सफलता। (%) मिन। (सेक) मैक्स। (सेकंड) औसत (सेकंड) 90 वाँ प्रतिशत 95 वाँ प्रतिशत



5000 | 98.96 | 33.54 | 120.08 | 66.13 | 78.78 | 83.27









टेस्ट रन 1.2। 250 समवर्ती सत्र, 25000 वी.एम.



कुल सफलता। (%) मिन। (सेक) मैक्स। (सेकंड) औसत। (सेकंड) 90 वाँ प्रतिशत 95 वाँ प्रतिशतक



25000 | 99.96 | 26.83 | 420.26 | 130.25 | 201.1 | 226.04



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



इसके बाद अगला कदम क्लाउड में वीएम की संख्या को 100,000 के लक्ष्य तक बढ़ाना था। हमने 10,000 और 25,000, 40,000, 50,000, 75,000, 75,000 के लक्ष्य के साथ परीक्षण भार के तहत कॉन्फ़िगरेशन का एक अलग सेट तैयार किया और इसके लिए रैली को दौड़ाया। 100,000 समवर्ती आभासी सर्वर। हमने पाया कि अधिकतम स्थिर स्तर 250 समवर्ती प्रश्न हैं। इस स्तर पर, हमने क्लस्टर में 150 और भौतिक होस्ट जोड़े, कुल सर्वरों की संख्या 350 प्लस 3 नियंत्रक सर्वर बन गई।



परिणामों के आधार पर, हमने लक्ष्यों में बदलाव किया और लक्ष्य को 100,000 से घटाकर 75,000 वीएम कर दिया। इसने हमें 350 + 3 क्लस्टर के विन्यास में प्रयोग जारी रखने की अनुमति दी।

समानांतर निष्पादन के स्थापित स्तर पर, चयनित आवृत्ति कॉन्फ़िगरेशन के साथ 75,000 वर्चुअल सर्वर को तैनात करने में कुल 8 घंटे से अधिक समय लगा। नीचे दिए गए आरेख परीक्षण निष्पादन के दौरान वीएम चलाने की संख्या पर वीएम स्टार्टअप समय की निर्भरता को दर्शाता है।







टेस्ट रन 1.3। 500 समवर्ती सत्र, 75,000 वीएम



कुल सफलता। (%) मिन। (सेक) मैक्स। (सेकंड) औसत। (सेकंड) 90 वाँ प्रतिशत 95 वाँ प्रतिशतक



75000 | 98.57 | 23.63 | 614.29 | 197.6 | 283.93 | 318.96



जैसा कि आरेख से देखा जा सकता है, 500 एक साथ कनेक्शन के साथ, प्रति मशीन औसत समय 200 सेकंड से कम था, या प्रत्येक 98.8 सेकंड में औसतन 250 वीएम।

सॉफ्टलेयर के आधार पर मिरेंटिस ओपनस्टैक के परीक्षण के परिणाम

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

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

भविष्य की तलाश: ओपनस्टैक वर्कलोड रेंज का विस्तार

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



मूल लेख अंग्रेजी में ।