मैचों पर सहेजें: फ़िल्टर का उपयोग करके ओपनस्टैक में स्थानीयता कैसे बढ़ाएं

लेखक: एलेक्सी ओविचनिकोव

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

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

मैं एक साधारण प्रश्न के साथ अपनी चर्चा शुरू करूंगा, अर्थात्, वीएम को एक विशेष नोड पर कैसे रखा जा सकता है।

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

फिल्टर के बारे में कुछ शब्द

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

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

उदाहरण के लिए, एक रैम फिल्टर पर विचार करें जो पर्याप्त मेमोरी के साथ नोड्स का चयन करता है। यह एक मानक फिल्टर है जिसमें काफी सरल संरचना है, इसलिए इसके आधार पर अधिक जटिल फिल्टर विकसित किए जा सकते हैं:

कक्षा रामफिल्टर (फ़िल्टर ।बेसहोस्टफ़िल्टर):
"" सब्सक्रिप्शन झंडे के साथ "राम फ़िल्टर" ""

def host_passes (स्वयं, host_state, filter_properties):
"" "केवल पर्याप्त मात्रा में उपलब्ध रैम के साथ मेजबान वापसी करता है।" "
inst_type = filter_properties.get ('inst_type')
अनुरोध किया गया
free_ram_mb = host_state.free_ram_mb
Total_usable_ram_mb = host_state.total_usable_ram_mb

memory_mb_limit = total_usable_ram_mb * FLAGS.ram_allocation_ratio
इस्तेमाल किया_राम_म्ब = कुल_सुख_राम_भी - free_ram_mb
usable_ram = memory_mb_limit - used_ram_mb
यदि उपयोग करने योग्य नहीं है
LOG.debug (_ ("% (host_state) s में% (request_ram) s MB नहीं है")
"प्रयोग करने योग्य राम, इसमें केवल% (usable_ram) एमबी प्रयोग करने योग्य राम है।")।
स्थानीय लोग ()
झूठा लौटना

# के खिलाफ परीक्षण करने के लिए गणना नोड के लिए ओवरसब्सक्रिप्शन सीमा को बचाएं:
host_state.limits ['memory_mb'] = memory_mb_limit
सच लौटाओ

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

शेड्यूलर टिप्स

शेड्यूलर संकेत कुंजी-मूल्य जोड़े के शब्दकोश से ज्यादा कुछ नहीं है जो nova boot कमांड द्वारा उत्पन्न हर अनुरोध में निहित है। यदि कुछ नहीं किया जाता है, तो यह शब्दकोश खाली रहेगा और कुछ भी दिलचस्प नहीं होगा। यदि उपयोगकर्ता कुछ संकेत पारित करने का निर्णय लेता है और इस प्रकार संकेत के साथ शब्दकोश को फिर से भर देता है, तो यह आसानी से कुंजी - hint रूप में किया जा सकता है, उदाहरण के लिए, निम्न कमांड में: nova boot … --hint your_hint_name=desired_value । अब संकेत के साथ शब्दकोश खाली नहीं है, इसमें संचरित जोड़ी है। यदि अनुसूचक के किसी भी विस्तार से पता चलता है कि इस संकेत का उपयोग कैसे करना है, तो उसे बस जानकारी मिली जिसे काम करते समय विचार किया जाना चाहिए। अगर ऐसा विस्तार नहीं हुआ, तो फिर कुछ नहीं होगा। दूसरा मामला पहले जैसा दिलचस्प नहीं है, इसलिए पहले पर ध्यान दें। आइए देखें कि एक्सटेंशन कैसे युक्तियों का लाभ उठा सकता है।

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

अनुसूचक_हिन्ते = फ़िल्टर_प्रक्रियाएँ ['अनुसूचक_हिन्ते']
important_hint = अनुसूचक_हिन्ता.गेट ('important_hint', गलत)

nova scheduler_hints अनुसूचक में अनुसूचक nova scheduler_hints हमेशा अनुरोध में मौजूद nova scheduler_hints हैं, इसलिए अपना विस्तार विकसित करते समय आप यहां अप्रिय आश्चर्य की उम्मीद नहीं कर सकते हैं, हालांकि, संकेत के मूल्य को पढ़ते समय आपको सावधान रहना चाहिए।

अब हमारे पास मनमाना संकेत प्राप्त करने का अवसर है। इस लक्ष्य को प्राप्त करने के लिए, यह चर्चा करना बाकी है कि उनका उपयोग कैसे किया जाए

भंडारण उपकरणों की कनेक्टिविटी में सुधार!

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

सबसे पहले, फ़िल्टर के लिए volume_id पास करने के लिए संकेत तंत्र का उपयोग करें। इसके लिए, हम same_host_volume_id नाम का उपयोग करने के लिए सहमत हैं। यह एक सरल कार्य है, जिसे हल करने के बाद हम तुरंत निम्नलिखित का सामना करते हैं, जिसे कम स्पष्ट रूप से हल किया जाता है: भंडारण डिवाइस के पहचानकर्ता को जानते हुए, होस्ट नाम कैसे प्राप्त करें? दुर्भाग्य से, जाहिरा तौर पर, इस समस्या को हल करने का कोई आसान तरीका नहीं है, इसलिए हम उस से मदद मांगेंगे जो डेटा भंडारण के लिए जिम्मेदार है: सिंडर घटक।

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

वॉल्यूम = cinder.cinderclient (संदर्भ) .volumes.get (volume_id)
vol_host = getattr (वॉल्यूम, 'os-vol-host-attr: host', कोई नहीं)

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

आगे कार्यान्वयन तुच्छ है - आपको उन नामों के साथ vol_host तुलना करने की आवश्यकता है, जब वे मेल खाते हैं और केवल तभी वापस आते हैं। कार्यान्वयन विवरण या तो ग्रिज़ली पैकेज में, या हवाना के कार्यान्वयन में पाया जा सकता है। परिणामस्वरूप फ़िल्टर पर कुछ प्रतिबिंब के साथ, प्रश्न अनिवार्य रूप से उठता है:

क्या यह सबसे अच्छा आप कर सकते हैं?

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

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

एक आफ्टरवर्ड के बजाय

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

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