Openstack मा लोड सन्तुलन

ठूला क्लाउड प्रणालीहरूमा, स्वचालित सन्तुलन वा कम्प्युटिङ स्रोतहरूमा भार समतल गर्ने मुद्दा विशेष गरी तीव्र छ। Tionix (क्लाउड सेवाहरूको विकासकर्ता र अपरेटर, कम्पनीहरूको Rostelecom समूहको भाग) ले पनि यस मुद्दाको ख्याल राखेको छ।

र, हाम्रो मुख्य विकास प्लेटफर्म ओपनस्ट्याक भएकोले, र हामी, सबै मानिसहरू जस्तै, अल्छी छौं, यो प्लेटफर्ममा पहिले नै समावेश गरिएको केही तयार मोड्युल चयन गर्ने निर्णय गरियो। हाम्रो छनोट Watcher मा पर्यो, जुन हामीले हाम्रो आवश्यकताको लागि प्रयोग गर्ने निर्णय गर्यौं।

पहिले, सर्तहरू र परिभाषाहरू हेरौं।

सर्तहरू र परिभाषाहरू

लक्ष्य एक मानव-पठनीय, अवलोकनयोग्य र मापनयोग्य अन्तिम परिणाम हो जुन हासिल गर्नुपर्दछ। प्रत्येक लक्ष्य हासिल गर्न एक वा बढी रणनीतिहरू छन्। रणनीति भनेको एल्गोरिदमको कार्यान्वयन हो जुन दिइएको लक्ष्यको लागि समाधान खोज्न सक्षम छ।

कार्य एउटा प्राथमिक कार्य हो जसले OpenStack क्लस्टरको लक्षित व्यवस्थित स्रोतको हालको अवस्था परिवर्तन गर्छ, जस्तै: भर्चुअल मेसिन माइग्रेट गर्ने (माइग्रेसन), नोडको पावर स्टेट (change_node_power_state) परिवर्तन गर्ने, nova सेवाको अवस्था परिवर्तन गर्ने (change_nova_service_state) ), स्वाद परिवर्तन (रिसाइज), NOP सन्देशहरू दर्ता गर्दै (नप), निश्चित समयको लागि कार्यको अभाव - पज (निद्रा), डिस्क स्थानान्तरण (भोल्युम_माइग्रेट)।

कार्य योजना - एक निश्चित लक्ष्य प्राप्त गर्न को लागी एक निश्चित क्रम मा कार्यहरु को एक विशेष प्रवाह। कार्य योजनाले कार्यसम्पादन सूचकहरूको सेटको साथ मापन गरिएको विश्वव्यापी कार्यसम्पादन पनि समावेश गर्दछ। एक सफल लेखापरीक्षण पछि वाचर द्वारा एक कार्य योजना उत्पन्न हुन्छ, जसको फलस्वरूप प्रयोग गरिएको रणनीतिले लक्ष्य प्राप्त गर्न समाधान खोज्छ। कार्य योजनाले क्रमिक कार्यहरूको सूची समावेश गर्दछ।

लेखापरीक्षण क्लस्टर अनुकूलन गर्न अनुरोध छ। दिइएको क्लस्टरमा एउटा लक्ष्य हासिल गर्नको लागि अप्टिमाइजेसन गरिन्छ। प्रत्येक सफल अडिटको लागि, वाचरले कार्य योजना उत्पन्न गर्दछ।

लेखापरीक्षण दायरा स्रोतहरूको एक सेट हो जसमा लेखापरीक्षण गरिन्छ (उपलब्धता क्षेत्र(हरू), नोड एग्रीगेटरहरू, व्यक्तिगत गणना नोडहरू वा भण्डारण नोडहरू, आदि। अडिट स्कोप प्रत्येक टेम्प्लेटमा परिभाषित गरिएको छ। यदि लेखापरीक्षण दायरा तोकिएको छैन भने, सम्पूर्ण क्लस्टर लेखापरीक्षण गरिन्छ।

अडिट टेम्प्लेट - लेखापरीक्षण सुरु गर्नको लागि सेटिङहरूको बचत गरिएको सेट। एउटै सेटिङहरूसँग धेरै पटक अडिटहरू चलाउन टेम्प्लेटहरू आवश्यक छन्। टेम्प्लेटमा अनिवार्य रूपमा लेखापरीक्षणको उद्देश्य समावेश हुनुपर्छ; यदि रणनीतिहरू निर्दिष्ट गरिएको छैन भने, सबैभन्दा उपयुक्त अवस्थित रणनीतिहरू चयन गरिन्छ।

क्लस्टर भौतिक मेसिनहरूको संग्रह हो जसले गणना, भण्डारण, र नेटवर्किङ स्रोतहरू प्रदान गर्दछ र उही OpenStack व्यवस्थापन नोडद्वारा व्यवस्थित गरिन्छ।

क्लस्टर डाटा मोडेल (CDM) क्लस्टरद्वारा व्यवस्थित स्रोतहरूको वर्तमान अवस्था र टोपोलोजीको तार्किक प्रतिनिधित्व हो।

दक्षता सूचक - यो रणनीति प्रयोग गरेर सिर्जना गरिएको समाधान कसरी प्रदर्शन गरिन्छ भनेर संकेत गर्ने सूचक। कार्यसम्पादन सूचकहरू एक विशेष लक्ष्यका लागि विशिष्ट हुन्छन् र परिणाम स्वरूप कार्य योजनाको विश्वव्यापी प्रभावकारिता गणना गर्न प्रयोग गरिन्छ।

प्रभावकारिता विशिष्टता प्रत्येक लक्ष्यसँग सम्बन्धित विशिष्ट सुविधाहरूको सेट हो जसले विभिन्न कार्यसम्पादन सूचकहरूलाई परिभाषित गर्दछ जुन सम्बन्धित लक्ष्य हासिल गर्ने रणनीतिले यसको समाधानमा हासिल गर्नुपर्छ। वास्तवमा, रणनीति द्वारा प्रस्तावित प्रत्येक समाधान यसको विश्वव्यापी प्रभावकारिता गणना गर्नु अघि विशिष्टता विरुद्ध जाँच गरिनेछ।

स्कोरिङ इन्जिन एक निष्पादन योग्य फाइल हो जसमा राम्ररी परिभाषित इनपुटहरू, राम्रो-परिभाषित आउटपुटहरू छन्, र विशुद्ध रूपमा गणितीय कार्य गर्दछ। यस तरिकाले, गणना यो प्रदर्शन गरिएको वातावरणबाट स्वतन्त्र छ - यसले कहीं पनि समान परिणाम दिनेछ।

हेरचाह योजनाकार - वाचर निर्णय लिने इन्जिनको भाग। यो मोड्युलले रणनीतिद्वारा उत्पन्न गरिएका कार्यहरूको सेट लिन्छ र कार्यप्रवाह योजना सिर्जना गर्दछ जसले यी विभिन्न कार्यहरूलाई समय र प्रत्येक कार्यको लागि, पूर्व शर्तहरू के हो भनेर निर्दिष्ट गर्दछ।

पहरेदार लक्ष्य र रणनीतिहरू

लक्ष्य
रणनीतिहरू

डमी गोल
डमी रणनीति 

नमूना स्कोरिङ इन्जिनहरू प्रयोग गरेर डमी रणनीति

रिसाइजको साथ डमी रणनीति

ऊर्जा बचत गर्दै
ऊर्जा बचत रणनीति

सर्भर समेकन
आधारभूत अफलाइन सर्भर समेकन

VM कार्यभार समेकन रणनीति

कार्यभार सन्तुलन
कार्यभार सन्तुलन माइग्रेसन रणनीति

भण्डारण क्षमता ब्यालेन्स रणनीति

कार्यभार स्थिरीकरण

कोलाहलपूर्ण छिमेकी
कोलाहलपूर्ण छिमेकी

थर्मल अनुकूलन
आउटलेट तापमान आधारित रणनीति

एयरफ्लो अनुकूलन
समान वायुप्रवाह माइग्रेसन रणनीति

हार्डवेयर मर्मत
क्षेत्र माइग्रेसन

वर्ग
अभिनेता

डमी गोल - आरक्षित लक्ष्य जुन परीक्षण उद्देश्यका लागि प्रयोग गरिन्छ।

सम्बन्धित रणनीतिहरू: डमी रणनीति, नमूना स्कोरिङ इन्जिनहरू प्रयोग गरेर डमी रणनीति र रिसाइजको साथ डमी रणनीति। डमी रणनीति टेम्पेस्ट मार्फत एकीकरण परीक्षणको लागि प्रयोग गरिने डमी रणनीति हो। यो रणनीतिले कुनै उपयोगी अप्टिमाइजेसन प्रदान गर्दैन, यसको मात्र उद्देश्य टेम्पेस्ट परीक्षणहरू प्रयोग गर्नु हो।

नमूना स्कोरिङ इन्जिनहरू प्रयोग गरेर डमी रणनीति - रणनीति अघिल्लो एक जस्तै छ, फरक एक नमूना "स्कोरिङ इन्जिन" को प्रयोग हो जसले मेसिन लर्निङ विधिहरू प्रयोग गरेर गणना सञ्चालन गर्दछ।

रिसाइजको साथ डमी रणनीति - रणनीति अघिल्लो एक जस्तै छ, मात्र फरक स्वाद (माइग्रेसन र रिसाइज) परिवर्तन गर्ने प्रयोग हो।

उत्पादनमा प्रयोग हुँदैन।

ऊर्जा बचत गर्दै - ऊर्जा खपत कम गर्नुहोस्। यस लक्ष्यको बचत ऊर्जा रणनीति, VM वर्कलोड कन्सोलिडेसन रणनीति (सर्भर कन्सोलिडेसन) सँगसँगै, गतिशील पावर व्यवस्थापन (DPM) सुविधाहरूमा सक्षम छ जसले कम स्रोत उपयोगको अवधिमा पनि गतिशील रूपमा कार्यभार समेकित गरेर ऊर्जा बचत गर्दछ: भर्चुअल मेसिनहरू कम नोडहरूमा सारियो। , र अनावश्यक नोडहरू असक्षम छन्। समेकन पछि, रणनीतिले निर्दिष्ट प्यारामिटरहरू अनुसार नोडहरू अन/अफ गर्ने निर्णय प्रस्ताव गर्दछ: "min_free_hosts_num" - लोडको लागि पर्खिरहेका निःशुल्क सक्षम नोडहरूको संख्या, र "free_used_percent" - नि: शुल्क सक्षम होस्टहरूको प्रतिशत। मेशिनहरूले ओगटेका नोडहरूको संख्या। काम गर्न रणनीति हुनुपर्छ नोडहरूमा पावर साइकल चलाउनको लागि Ironic सक्षम र कन्फिगर गरियो।

रणनीति मापदण्डहरू

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

free_used_percent
नम्बर
10.0
भर्चुअल मेसिनहरू भएका कम्प्युटिङ नोडहरूको सङ्ख्यामा नि:शुल्क कम्प्युटिङ नोडहरूको सङ्ख्याको अनुपात

min_free_hosts_num
int
1
निःशुल्क कम्प्युटिङ नोडहरूको न्यूनतम संख्या

क्लाउडमा कम्तिमा दुई नोडहरू हुनुपर्छ। प्रयोग गरिएको विधिले नोडको पावर स्टेट (change_node_power_state) परिवर्तन गर्दैछ। रणनीतिलाई मेट्रिक्स सङ्कलन आवश्यक पर्दैन।

सर्भर कन्सोलिडेशन - कम्प्युटिङ नोड्स (एकीकरण) को संख्या कम गर्नुहोस्। यसमा दुईवटा रणनीतिहरू छन्: आधारभूत अफलाइन सर्भर कन्सोलिडेशन र VM वर्कलोड कन्सोलिडेशन रणनीति।

आधारभूत अफलाइन सर्भर कन्सोलिडेसन रणनीतिले प्रयोग गरिएका सर्भरहरूको कुल सङ्ख्यालाई न्यूनीकरण गर्छ र माइग्रेसनहरूको सङ्ख्यालाई पनि कम गर्छ।

आधारभूत रणनीति निम्न मेट्रिक्स आवश्यक छ:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

compute.node.cpu.percent
सिलोमिटर
कुनै पनि
 

cpu_util
सिलोमिटर
कुनै पनि
 

रणनीति प्यारामिटरहरू: माइग्रेसन_प्रयास - बन्दको लागि सम्भावित उम्मेद्वारहरू खोज्नका लागि संयोजनहरूको संख्या (पूर्वनिर्धारित, ०, कुनै प्रतिबन्ध छैन), अवधि - मेट्रिक डेटा स्रोतबाट स्थिर एकत्रीकरण प्राप्त गर्न सेकेन्डमा समय अन्तराल (पूर्वनिर्धारित, 0)।

प्रयोग गरिएका विधिहरू: माइग्रेसन, नोभा सेवा अवस्था परिवर्तन गर्दै (change_nova_service_state)।

VM वर्कलोड कन्सोलिडेसन रणनीति पहिलो-फिट हिउरिस्टिकमा आधारित छ जुन मापन गरिएको CPU लोडमा केन्द्रित छ र धेरै वा धेरै थोरै भार दिइएको स्रोत क्षमता अवरोधहरू भएका नोडहरूलाई कम गर्ने प्रयास गर्दछ। यस रणनीतिले निम्न चार चरणहरू प्रयोग गरेर क्लस्टर स्रोतहरूको अधिक कुशल प्रयोगमा परिणाम दिने समाधान प्रदान गर्दछ:

1. अनलोडिंग चरण - अत्यधिक प्रयोग गरिएका स्रोतहरूको प्रशोधन;
2. समेकन चरण - कम प्रयोग भएका स्रोतहरू ह्यान्डलिङ;
3. समाधान को अनुकूलन - माइग्रेसन को संख्या कम गर्दै;
4. प्रयोग नगरिएका कम्प्युट नोडहरू असक्षम गर्दै।

रणनीतिलाई निम्न मेट्रिक्स चाहिन्छ:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

स्मृति
सिलोमिटर
कुनै पनि
 

disk.root.size
सिलोमिटर
कुनै पनि
 

निम्न मेट्रिक्स ऐच्छिक छन् तर उपलब्ध भएमा रणनीति शुद्धतामा सुधार हुनेछ:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

स्मृति निवासी
सिलोमिटर
कुनै पनि
 

cpu_util
सिलोमिटर
कुनै पनि
 

रणनीति प्यारामिटरहरू: अवधि - मेट्रिक डेटा स्रोत (पूर्वनिर्धारित, 3600) बाट स्थिर एकत्रीकरण प्राप्त गर्न सेकेन्डमा समय अन्तराल।

अघिल्लो रणनीति जस्तै समान विधिहरू प्रयोग गर्दछ। थप विवरण यहाँ.

कार्यभार सन्तुलन - कम्प्युटिङ नोडहरू बीच कार्यभार सन्तुलन। लक्ष्यका तीन रणनीतिहरू छन्: कार्यभार ब्यालेन्स माइग्रेसन रणनीति, कार्यभार स्थिरीकरण, भण्डारण क्षमता ब्यालेन्स रणनीति।

वर्कलोड ब्यालेन्स माइग्रेसन रणनीतिले होस्ट भर्चुअल मेसिन वर्कलोडमा आधारित भर्चुअल मेसिन माइग्रेसनहरू चलाउँछ। एक माइग्रेसन निर्णय गरिन्छ जब कुनै नोडको % CPU वा RAM उपयोग निर्दिष्ट थ्रेसहोल्ड नाघ्छ। यस अवस्थामा, सारिएको भर्चुअल मेसिनले नोडलाई सबै नोडहरूको औसत कार्यभारको नजिक ल्याउनु पर्छ।

आवश्यकताहरू

• भौतिक प्रोसेसर को प्रयोग;
• कम्तिमा दुई भौतिक कम्प्युटिङ नोडहरू;
• Ceilometer घटक स्थापना र कन्फिगर गरियो - ceilometer-agent-compute, प्रत्येक कम्प्युट नोडमा चलिरहेको छ, र Ceilometer API, साथै निम्न मेट्रिकहरू सङ्कलन गर्दै:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

cpu_util
सिलोमिटर
कुनै पनि
 

स्मृति निवासी
सिलोमिटर
कुनै पनि
 

रणनीति मापदण्डहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

मेट्रिक्स
घागो
'cpu_util'
अन्तर्निहित मेट्रिकहरू हुन्: 'cpu_util', 'memory.resident'।

थ्रेसहोल्ड
नम्बर
25.0
माइग्रेसनको लागि कार्यभार थ्रेसहोल्ड।

अवधि
नम्बर
300
संचयी समय अवधि Ceilometer।

प्रयोग गरिएको विधि माइग्रेसन हो।

वर्कलोड स्ट्याबिलाइजेसन भनेको प्रत्यक्ष माइग्रेसन प्रयोग गरेर कार्यभारलाई स्थिर बनाउने रणनीति हो। रणनीति मानक विचलन एल्गोरिदममा आधारित छ र क्लस्टरमा भीड छ कि छैन भनेर निर्धारण गर्दछ र क्लस्टरलाई स्थिर गर्न मेसिन माइग्रेसन ट्रिगर गरेर प्रतिक्रिया दिन्छ।

आवश्यकताहरू

• भौतिक प्रोसेसर को प्रयोग;
• कम्तिमा दुई भौतिक कम्प्युटिङ नोडहरू;
• Ceilometer घटक स्थापना र कन्फिगर गरियो - ceilometer-agent-compute, प्रत्येक कम्प्युट नोडमा चलिरहेको छ, र Ceilometer API, साथै निम्न मेट्रिकहरू सङ्कलन गर्दै:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

cpu_util
सिलोमिटर
कुनै पनि
 

स्मृति निवासी
सिलोमिटर
कुनै पनि
 

भण्डारण क्षमता ब्यालेन्स रणनीति (क्वीन्सबाट सुरु गरी लागू गरिएको रणनीति) - रणनीतिले सिन्डर पूलहरूमा लोडको आधारमा डिस्कहरू स्थानान्तरण गर्दछ। एक स्थानान्तरण निर्णय गरिन्छ जब पूल उपयोग दर निर्दिष्ट थ्रेसहोल्ड नाघ्छ। सारिएको डिस्कले पूललाई ​​सबै सिन्डर पूलहरूको औसत लोडको नजिक ल्याउनु पर्छ।

आवश्यकता र प्रतिबन्धहरू

• न्यूनतम दुई सिन्डर पूलहरू;
• डिस्क माइग्रेसनको सम्भावना।
• क्लस्टर डाटा मोडेल - सिन्डर क्लस्टर डाटा मोडेल कलेक्टर।

रणनीति मापदण्डहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

भोल्यूम_थ्रेशोल्ड
नम्बर
80.0
भोल्युमहरू सन्तुलनका लागि डिस्कहरूको थ्रेसहोल्ड मान।

प्रयोग गरिएको विधि डिस्क माइग्रेसन (भोल्युम_माइग्रेट) हो।

कोलाहल छिमेकी - पहिचान गर्नुहोस् र माइग्रेट गर्नुहोस् "शोर छिमेकी" - एक कम प्राथमिकता भर्चुअल मेसिन जसले IPC को सर्तमा अन्तिम स्तर क्यासको अत्यधिक प्रयोग गरेर उच्च प्राथमिकता भर्चुअल मेसिनको कार्यसम्पादनलाई नकारात्मक रूपमा असर गरिरहेको छ। आफ्नै रणनीति: कोलाहल छिमेकी (रणनीति प्यारामिटर प्रयोग गरिन्छ cache_threshold (पूर्वनिर्धारित मान 35 हो), जब कार्यसम्पादन तोकिएको मानमा झर्छ, माइग्रेसन सुरु हुन्छ। कार्यनीतिको लागि, सक्षम पारिएको छ। LLC (अन्तिम स्तर क्यास) मेट्रिक्स, CMT समर्थन संग नवीनतम Intel सर्भर, साथै निम्न मेट्रिक्स सङ्कलन:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

cpu_l3_cache
सिलोमिटर
कुनै पनि
Intel आवश्यक छ CMT.

क्लस्टर डाटा मोडेल (पूर्वनिर्धारित): नोभा क्लस्टर डाटा मोडेल कलेक्टर। प्रयोग गरिएको विधि माइग्रेसन हो।

ड्यासबोर्ड मार्फत यो लक्ष्य संग काम क्वीन्स मा पूर्ण रूपमा लागू गरिएको छैन।

थर्मल अनुकूलन - तापमान व्यवस्था अनुकूलन। सर्भरको थर्मल/वर्कलोड स्थिति मापन गर्न आउटलेट (निकास हावा) तापमान महत्त्वपूर्ण थर्मल टेलिमेट्री प्रणालीहरू मध्ये एक हो। लक्ष्यसँग एउटै रणनीति छ, आउटलेट तापक्रममा आधारित रणनीति, जसले स्रोत होस्टहरूको आउटलेट तापक्रम कन्फिगर योग्य थ्रेसहोल्डमा पुग्दा कार्यभारहरूलाई थर्मली अनुकूल होस्टहरू (न्यूनतम आउटलेट तापक्रम) मा स्थानान्तरण गर्ने निर्णय गर्छ।

रणनीति काम गर्नको लागि, तपाईंलाई इन्टेल पावर नोड प्रबन्धक स्थापना र कन्फिगर भएको सर्भर चाहिन्छ 3.0 वा पछि, साथै निम्न मेट्रिक्स सङ्कलन:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

hardware.ipmi.node.outlet_temperature
सिलोमिटर
IPMI
 

रणनीति मापदण्डहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

थ्रेसहोल्ड
नम्बर
35.0
माइग्रेसनको लागि तापमान थ्रेसहोल्ड।

अवधि
नम्बर
30
समय अन्तराल, सेकेन्डमा, मेट्रिक डेटा स्रोतबाट सांख्यिकीय एकत्रीकरण प्राप्त गर्न।

प्रयोग गरिएको विधि माइग्रेसन हो।

एयरफ्लो अनुकूलन - भेन्टिलेसन मोड अप्टिमाइज गर्नुहोस्। आफ्नै रणनीति - प्रत्यक्ष माइग्रेसन प्रयोग गरेर समान वायुप्रवाह। रणनीतिले भर्चुअल मेसिन माइग्रेसनलाई ट्रिगर गर्छ जब सर्भर फ्यानबाट हावा प्रवाहले तोकिएको थ्रेसहोल्ड नाघ्यो।

रणनीति काम गर्न को लागी तपाईलाई आवश्यक छ:

• हार्डवेयर: कम्प्युट नोड्स < समर्थन गर्ने NodeManager 3.0;
• कम्तिमा दुई कम्प्युटिङ नोडहरू;
• ceilometer-agent-compute र Ceilometer API कम्पोनेन्ट प्रत्येक कम्प्युटिङ नोडमा स्थापित र कन्फिगर गरिएको छ, जसले वायु प्रवाह, प्रणाली शक्ति, इनलेट तापक्रम जस्ता मेट्रिकहरू सफलतापूर्वक रिपोर्ट गर्न सक्छ:

मेट्रिक्स
सेवा
प्लगइनहरू
टिप्पणी

hardware.ipmi.node.airflow
सिलोमिटर
IPMI
 

hardware.ipmi.node.temperature
सिलोमिटर
IPMI
 

hardware.ipmi.node.power
सिलोमिटर
IPMI
 

रणनीति काम गर्नको लागि, तपाईंलाई Intel Power Node Manager 3.0 वा पछि स्थापित र कन्फिगर गरिएको सर्भर चाहिन्छ।

सीमाहरू: अवधारणा उत्पादनको लागि इरादा होइन।

यो एल्गोरिथ्मलाई निरन्तर अडिटहरूको साथ प्रयोग गर्न प्रस्ताव गरिएको छ, किनकि प्रति पुनरावृत्ति मात्र एक भर्चुअल मेसिन माइग्रेट गर्ने योजना छ।

प्रत्यक्ष माइग्रेसन सम्भव छ।

रणनीति मापदण्डहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

threshold_airflow
नम्बर
400.0
माइग्रेसन एकाइको लागि वायु प्रवाह थ्रेसहोल्ड 0.1CFM हो

threshold_inlet_t
नम्बर
28.0
माइग्रेसन निर्णयको लागि इनलेट तापमान थ्रेसहोल्ड

threshold_power
नम्बर
350.0
माइग्रेसन निर्णयको लागि प्रणाली पावर थ्रेसहोल्ड

अवधि
नम्बर
30
समय अन्तराल, सेकेन्डमा, मेट्रिक डेटा स्रोतबाट सांख्यिकीय एकत्रीकरण प्राप्त गर्न।

प्रयोग गरिएको विधि माइग्रेसन हो।

हार्डवेयर रखरखाव - हार्डवेयर मर्मत। यस लक्ष्यसँग सम्बन्धित रणनीति जोन माइग्रेसन हो। रणनीति हार्डवेयर मर्मतसम्भारको आवश्यकता पर्दा भर्चुअल मेसिन र डिस्कहरूको प्रभावकारी स्वचालित र न्यूनतम माइग्रेसनको लागि एक उपकरण हो। रणनीतिले तौल अनुसार कार्यको योजना बनाउँछ: अधिक वजन भएका कार्यहरूको सेट अरूको अगाडि योजना बनाइनेछ। त्यहाँ दुई कन्फिगरेसन विकल्पहरू छन्: action_weights र parallelization।

सीमाहरू: कार्य वजन र समानान्तर कन्फिगर गर्न आवश्यक छ।

रणनीति मापदण्डहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

compute_nodes
array
कुनै पनि
माइग्रेसनका लागि नोडहरू गणना गर्नुहोस्।

भण्डारण_पूलहरू
array
कुनै पनि
माइग्रेसनका लागि भण्डारण नोडहरू।

parallel_total
पूर्णांक
6
समानान्तर रूपमा कार्यान्वयन गरिनु पर्ने गतिविधिहरूको कुल संख्या।

parallel_per_node
पूर्णांक
2
प्रत्येक कम्प्युट नोडको लागि समानान्तर रूपमा प्रदर्शन गरिएका कार्यहरूको संख्या।

parallel_per_pool
पूर्णांक
2
प्रत्येक भण्डारण पोखरीको लागि समानान्तर रूपमा प्रदर्शन गरिएका कार्यहरूको संख्या।

प्राथमिकता
वस्तु
कुनै पनि
भर्चुअल मेसिन र डिस्कहरूको लागि प्राथमिकता सूची।

with_attached_volume
बूलियन
झूटा
False — भर्चुअल मेसिनहरू सबै डिस्कहरू माइग्रेट गरिसकेपछि माइग्रेट हुनेछन्। साँचो - सबै जडान गरिएका डिस्कहरू माइग्रेट गरिसकेपछि भर्चुअल मेसिनहरू माइग्रेट हुनेछन्।

कम्प्युटिङ नोडहरूको एरेका तत्वहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

src_node
string
कुनै पनि
कम्प्युट नोड जसबाट भर्चुअल मेसिनहरू माइग्रेट भइरहेका छन् (आवश्यक)।

dst_node
string
कुनै पनि
भर्चुअल मेसिनहरू माइग्रेट हुने नोडको गणना गर्नुहोस्।

भण्डारण नोड एरे तत्वहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

src_pool
string
कुनै पनि
भण्डारण पूल जसबाट डिस्कहरू माइग्रेट भइरहेका छन् (आवश्यक)।

dst_pool
string
कुनै पनि
डिस्क माइग्रेट भएको भण्डारण पूल।

src_type
string
कुनै पनि
मूल डिस्क प्रकार (आवश्यक)।

dst_type
string
कुनै पनि
परिणामस्वरूप डिस्क प्रकार (आवश्यक)।

वस्तु प्राथमिकता तत्वहरू:

प्यारामिटर
प्रकार
पूर्वनिर्धारित द्वारा
विवरण

परियोजना
array
कुनै पनि
परियोजना नामहरू।

compute_node
array
कुनै पनि
नोड नामहरू गणना गर्नुहोस्।

भण्डारण_पूल
array
कुनै पनि
भण्डारण पोखरी नामहरू।

रचना गर्नुहोस्
एनम
कुनै पनि
भर्चुअल मेसिन प्यारामिटरहरू [“vcpu_num”, “mem_size”, “disk_size”, “created_at”]।

भण्डारण
एनम
कुनै पनि
डिस्क प्यारामिटरहरू [“आकार”, “created_at”]।

प्रयोग गरिएका विधिहरू भर्चुअल मेसिन माइग्रेसन, डिस्क माइग्रेसन हुन्।

वर्ग - रणनीति विकास प्रक्रियालाई सहज बनाउन प्रयोग गरिने सहायक लक्ष्य। कुनै विशिष्टताहरू समावेश गर्दैन र रणनीति अझै अवस्थित लक्ष्यसँग सम्बन्धित नभएको बेला प्रयोग गर्न सकिन्छ। यो लक्ष्यलाई संक्रमण बिन्दुको रूपमा पनि प्रयोग गर्न सकिन्छ। यस लक्ष्यसँग सम्बन्धित रणनीति एक्चुएटर हो।   

नयाँ लक्ष्य सिर्जना गर्दै

वाचर निर्णय इन्जिन एक "बाह्य लक्ष्य" प्लगइन इन्टरफेस छ जसले बाह्य लक्ष्यलाई एकीकृत गर्न सम्भव बनाउँछ जुन रणनीति प्रयोग गरेर हासिल गर्न सकिन्छ।

तपाईंले नयाँ लक्ष्य सिर्जना गर्नु अघि, तपाईंले कुनै पनि अवस्थित लक्ष्यहरू तपाईंको आवश्यकताहरू पूरा गर्दैनन् भनेर सुनिश्चित गर्नुपर्छ।

नयाँ प्लगइन सिर्जना गर्दै

नयाँ लक्ष्य सिर्जना गर्न, तपाइँले: लक्ष्य वर्ग विस्तार गर्नुहोस्, वर्ग विधि लागू गर्नुहोस् get_name() तपाईंले सिर्जना गर्न चाहनुभएको नयाँ लक्ष्यको अद्वितीय आईडी फिर्ता गर्न। यो अद्वितीय पहिचानकर्ता तपाईंले पछि घोषणा गर्नुहुने प्रविष्टि बिन्दु नामसँग मेल खानुपर्छ।

अर्को तपाईंले कक्षा विधि लागू गर्न आवश्यक छ get_display_name() तपाईंले सिर्जना गर्न चाहनुभएको लक्ष्यको अनुवादित प्रदर्शन नाम फिर्ता गर्न (अनुवादित स्ट्रिङ फिर्ता गर्न चर प्रयोग नगर्नुहोस् ताकि यसलाई अनुवाद उपकरणद्वारा स्वचालित रूपमा सङ्कलन गर्न सकिन्छ।)

कक्षा विधि लागू गर्नुहोस् get_translatable_display_name()तपाईंको नयाँ लक्ष्यको अनुवाद कुञ्जी (वास्तवमा अंग्रेजी प्रदर्शन नाम) फिर्ता गर्न। फिर्ताको मान get_display_name() मा अनुवादित स्ट्रिङसँग मिल्नुपर्छ।

उसको पद्धति लागू गर्नुहोस् get_eficacy_specification()तपाईंको लक्ष्यको लागि दक्षता विशिष्टता फिर्ता गर्न। get_eficacy_specification() विधिले Watcher द्वारा प्रदान गरिएको Unclassified() उदाहरण फिर्ता गर्छ। यो कार्यसम्पादन विशिष्टता तपाईंको लक्ष्य विकास गर्ने प्रक्रियामा उपयोगी छ किनभने यो खाली स्पेसिफिकेशनसँग मेल खान्छ।

→ यहाँ थप पढ्नुहोस्

वाचर वास्तुकला (थप विवरण) यहाँ).

अवयव

Watcher API - Watcher द्वारा प्रदान गरिएको REST API लागू गर्ने कम्पोनेन्ट। अन्तरक्रिया संयन्त्र: CLI, Horizon प्लगइन, Python SDK।

हेरचाह DB - वाचक डाटाबेस।

पहरेदार एप्लायर — वाचर डिसिजन इन्जिन कम्पोनेन्टद्वारा सिर्जना गरिएको कार्य योजनाको कार्यान्वयनलाई कार्यान्वयन गर्ने कम्पोनेन्ट।

वाचर निर्णय इन्जिन - लेखापरीक्षण लक्ष्य प्राप्त गर्न सम्भावित अनुकूलन कार्यहरूको सेट गणना गर्न जिम्मेवार घटक। यदि रणनीति निर्दिष्ट गरिएको छैन भने, घटकले स्वतन्त्र रूपमा सबैभन्दा उपयुक्त एक चयन गर्दछ।

वाचर मेट्रिक्स प्रकाशक - एक कम्पोनेन्ट जसले केही मेट्रिक्स वा घटनाहरू सङ्कलन र गणना गर्दछ र तिनीहरूलाई CEP अन्तिम बिन्दुमा प्रकाशित गर्दछ। कम्पोनेन्टको कार्यक्षमता पनि Ceilometer प्रकाशक द्वारा प्रदान गर्न सकिन्छ।

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

कम्पोनेन्टहरू AMQP प्रोटोकल प्रयोग गरेर अन्तरक्रिया गर्छन्।

→ वाचर कन्फिगर गर्दै

Watcher संग अन्तरक्रिया को योजना

पहरेदार परीक्षण परिणाम

1. अप्टिमाइजेसनमा - कार्य योजना 500 पृष्ठहरू (दुवै शुद्ध क्वीन्समा र Tionix मोड्युलहरूको साथ स्ट्यान्डमा), यो लेखा परीक्षण सुरु भएपछि र कार्य योजना उत्पन्न भएपछि मात्र देखिन्छ; खाली एउटा सामान्य रूपमा खुल्छ।
2. कार्य विवरण ट्याबमा त्रुटिहरू छन्, अडिट लक्ष्य र रणनीति प्राप्त गर्न सम्भव छैन (दुवै शुद्ध क्वीन्समा र Tionix मोड्युलहरूको साथ स्ट्यान्डमा)।
3. डमी (परीक्षण) को उद्देश्यका साथ लेखापरीक्षणहरू सिर्जना गरिन्छ र सामान्य रूपमा सुरू गरिन्छ, कार्य योजनाहरू उत्पन्न हुन्छन्।
4. अवर्गीकृत लक्ष्यका लागि लेखापरीक्षणहरू सिर्जना गरिएका छैनन् किनभने लक्ष्य कार्यात्मक छैन र नयाँ रणनीतिहरू सिर्जना गर्दा मध्यवर्ती कन्फिगरेसनको लागि लक्षित छ।
5. कार्यभार सन्तुलन (भण्डारण क्षमता ब्यालेन्स रणनीति) को उद्देश्यका लागि लेखापरीक्षणहरू सफलतापूर्वक सिर्जना गरिएका छन्, तर कार्य योजना सिर्जना गरिएको छैन। कुनै भण्डारण पूल अनुकूलन आवश्यक छैन।
6. वर्कलोड सन्तुलन लक्ष्य (वर्कलोड ब्यालेन्स माइग्रेसन रणनीति) को लागि अडिटहरू सफलतापूर्वक बनाइन्छ, तर कार्य योजना सिर्जना गरिएको छैन।
7. वर्कलोड ब्यालेन्सिङ (वर्कलोड स्टेबिलाइजेसन स्ट्राटेजी) को लागि अडिटहरू असफल।
8. कोलाहलपूर्ण छिमेकी लक्ष्यका लागि लेखापरीक्षणहरू सफलतापूर्वक सिर्जना गरिएका छन्, तर कार्य योजना सिर्जना गरिएको छैन।
9. हार्डवेयर मर्मतका लागि अडिटहरू सफलतापूर्वक सिर्जना गरिन्छन्, कार्य योजना पूर्ण रूपमा उत्पन्न हुँदैन (कार्यसम्पादन सूचकहरू उत्पन्न हुन्छन्, तर कार्यहरूको सूची आफैं उत्पन्न हुँदैन)।
10. nova.conf कन्फिगहरू (पूर्वनिर्धारित खण्ड compute_monitors = cpu.virt_driver मा) कम्प्युट र नियन्त्रण नोडहरूमा सम्पादन गर्दा त्रुटिहरू सच्याउँदैन।
11. सर्भर कन्सोलिडेसन (आधारभूत रणनीति) लक्षित लेखापरीक्षणहरू पनि असफल हुन्छन्।
12. सर्भर कन्सोलिडेशन (VM वर्कलोड कन्सोलिडेशन रणनीति) को उद्देश्यका लागि अडिटहरू त्रुटिको साथ असफल हुन्छन्। लगहरूमा स्रोत डेटा प्राप्त गर्नमा त्रुटि छ। विशेष गरी त्रुटिको चर्चा यहाँ.
    हामीले कन्फिगरेसन फाइलमा वाचर निर्दिष्ट गर्ने प्रयास गर्‍यौं (यसले मद्दत गरेन - सबै अप्टिमाइजेसन पृष्ठहरूमा त्रुटिको परिणामको रूपमा, कन्फिग फाइलको मूल सामग्रीहरूमा फर्किएर स्थिति सुधार गर्दैन):
    [watcher_strategies.basic] डाटा स्रोत = सिलोमिटर, gnocchi
13. ऊर्जा बचतको लागि लेखापरीक्षण असफल भयो। लगहरू द्वारा न्याय गर्दै, समस्या अझै पनि आइरनिकको अभावमा छ; यो बेरेमेटल सेवा बिना काम गर्दैन।
14. थर्मल अप्टिमाइजेसनको लागि अडिटहरू असफल। ट्रेसब्याक सर्भर कन्सोलिडेशन (VM वर्कलोड कन्सोलिडेशन रणनीति) (स्रोत डेटा त्रुटि) को लागि जस्तै हो।
15. एयरफ्लो अप्टिमाइजेसनको उद्देश्यका लागि अडिटहरू त्रुटिको साथ असफल हुन्छन्।

निम्न लेखापरीक्षण समापन त्रुटिहरू पनि सामना गरिएका छन्। निर्णय-engine.log लगहरूमा ट्रेसब्याक (क्लस्टर अवस्था परिभाषित गरिएको छैन)।

→ त्रुटिको चर्चा यहाँ

निष्कर्षमा

हाम्रो दुई-महिनाको अनुसन्धानको नतिजा स्पष्ट निष्कर्ष थियो कि एक पूर्ण, काम गर्ने भार सन्तुलन प्रणाली प्राप्त गर्न, हामीसँग, यस भागमा, ओपनस्ट्याक प्लेटफर्मको लागि उपकरणहरू परिष्कृत गर्न नजिकबाट काम गर्न हुनेछ।

वाचरले ठूलो क्षमताको साथ एक गम्भीर र द्रुत रूपमा विकास गर्ने उत्पादन साबित भएको छ, जसको पूर्ण प्रयोगले धेरै गम्भीर कामको आवश्यकता पर्दछ।

तर यस श्रृंखलाको अर्को लेखहरूमा थप।

स्रोत: www.habr.com