🤷🏼 🔣 🍬 एकीकृत सर्वर लोड मैट्रिक्स मूल्यांकन 🙌 🍑 👬

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

वर्चुअल सर्वर का उपयोग करने की सुविधाओं के बारे में कुछ शब्द

बड़े संगठनों (विशेष रूप से बैंकों) में विभिन्न वर्चुअलाइजेशन तकनीकों का उपयोग करके विभिन्न सर्वरों पर तैनात विरासत अनुप्रयोगों का एक प्रेरक चिड़ियाघर है। एक निजी क्लाउड एक आशाजनक तकनीक है, लेकिन वास्तव में, बड़े संगठन विभिन्न अनुप्रयोगों को तैनात करने के लिए विभिन्न वर्चुअलाइजेशन प्लेटफार्मों का उपयोग करेंगे।

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

सारांश के रूप में, बड़े संगठनों में, आभासी खेत संसाधनों को बेहद अक्षम रूप से खर्च किया जाता है।

नीचे मैंने एक कार्यप्रणाली प्रस्तावित की है जिसके साथ आप वर्चुअल सर्वर को आवंटित संसाधनों में वृद्धि और कमी को आसानी से सही ठहरा सकते हैं, चाहे वह किसी भी परिदृश्य का हो।

क्रियाविधि

संसाधनों के भार का आकलन करने के लिए, विभिन्न काउंटरों के आंकड़ों को एकत्र करना आवश्यक है, संसाधनों के भार का आकलन करने के लिए, विभिन्न मैट्रिक्स का उपयोग किया जाएगा। परंपरागत रूप से, काउंटरों को 2 प्रकारों (परिवर्तन की दर के अनुसार) में विभाजित किया जा सकता है: "तेज" और "धीमी"। एक "तेज़" काउंटर का एक अच्छा उदाहरण प्रोसेसर लोड काउंटर (% CPU) है। धीमे काउंटर का एक उदाहरण मुक्त हार्ड डिस्क स्थान (% फ्रीस्पेस) का प्रतिशत है।
धीमे काउंटरों के मूल्यांकन में अवधि के लिए मीट्रिक के चरम (न्यूनतम या अधिकतम) मूल्य की गणना होती है। यह दृष्टिकोण अनुमति देता है (उदाहरण के लिए, डिस्क मुक्त स्थान का आकलन करते समय) मुक्त संसाधन का अनुमान लगाने के लिए और यदि आवश्यक हो, तो अतिरिक्त वॉल्यूम आवंटित करने या अन्य को कम करने के लिए।

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

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

नीचे, चित्रण के रूप में,% CPU काउंटर का साप्ताहिक और दैनिक चार्ट। चार्ट पर अधिकतम काउंटर मूल्य 100% था।

ग्राफ दिखाता है कि संकेतित अवधि के दौरान लोड का एक विस्फोट होता है, जो लगभग 3 घंटे तक रहता है। इस काउंटर के लिए, सप्ताह के लिए विभिन्न मैट्रिक्स की गणना की गई थी। चित्रा 2 से पता चलता है कि माध्यिका (ग्रीन लाइन, 5% मूल्य), औसत (पीला, 12% मूल्य) और 0.9 मात्रात्मक (लाल, 27% मूल्य) लोड परिवर्तन को फ़िल्टर करता है और इसके बारे में जानकारी खो जाती है।

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

जैसा कि आप रेखांकन से देख सकते हैं, 0.9 की चलती मात्राएं गतिशील विशेषताएं हैं (भूरा - तेज, बैंगनी - धीमा)। सादगी के लिए, यह उपयोग करने के लिए प्रस्तावित मैट्रिक्स के रूप में काउंटर की स्थिति का मूल्यांकन:

1 घंटे की अवधि के साथ अधिकतम मात्रात्मक मान, जो अवधि के लिए अधिकतम निरंतर सर्वर लोड दिखाता है,
24 घंटे की अवधि के साथ औसत मात्रात्मक मान, जो अवधि के लिए औसत सर्वर लोड दिखाता है।

ग्राफ पर, तेज क्वांटाइल का अधिकतम मूल्य 85% पर काली रेखा है, धीमी गति से मात्रा का औसत मूल्य 30% पर गुलाबी रेखा है।

इस प्रकार, सर्वर संसाधनों के लोड का विश्लेषण करते समय (% CPU काउंटर के अनुसार), यदि हम एक मीट्रिक के रूप में महीने (12%) के लिए औसत लेते हैं, तो हम आवंटित संसाधनों को कम करने के लिए एक गलत निर्णय ले सकते हैं। डबल तेज / धीमी गति से चलती क्वांटिक मेट्रिक (85 और 30%) से पता चलता है कि पर्याप्त आवंटित संसाधन हैं, लेकिन कोई अतिशयोक्ति नहीं।

फेसला

संसाधन उपयोग की दक्षता के मूल्यांकन के कार्यान्वयन को 3 कार्यों में विघटित किया गया है:

आंकड़ा संग्रहण
मूल्यांकन पद्धति का विकास
वर्तमान वास्तुकला में कार्यप्रणाली कार्यान्वयन

ऊपर, मैंने इस कार्यान्वयन के कार्य 2 की जांच की, नीचे हम तीसरे कार्य के बारे में थोड़ी बात करेंगे।

डेटा को ClickHouse डेटाबेस में एकत्र किया गया था। यह कॉलम DBMS समय-श्रृंखला डेटा संग्रहीत करने के लिए आदर्श है। 5 सितंबर, 2019 को ClickHouse Meetup में इस पर विस्तार से चर्चा की गई । अन्य टाइम-सीरीज़ DBMS के साथ ClickHouse की तुलना यहाँ पाई जा सकती है ।
डेटा संग्रह के परिणामस्वरूप, हमने कई तालिकाओं का गठन किया जिसमें डेटा को लाइन द्वारा व्यवस्थित किया गया था (प्रत्येक काउंटर के मूल्यों को एक अलग लाइन में लिखा गया था)। और, ज़ाहिर है, कच्चे डेटा के साथ समस्याएं थीं।

पहली समस्या काउंटर प्रविष्टियों के बीच अंतराल की असमानता है। उदाहरण के लिए, यदि मानक काउंटर रिकॉर्डिंग की अवधि 5 मिनट थी, तो कभी-कभी अंतराल होते थे और अगला रिकॉर्ड पिछले एक मिनट से 5 मिनट (20 मिनट तक) से अधिक था।

दूसरी समस्या यह है कि कभी-कभी काउंटर डेटा 2 या अधिक बार (विभिन्न मूल्यों के साथ) एक ही समय स्टाम्प के साथ आया था।

और तीसरी समस्या - ClickHouse में कोई विंडो फ़ंक्शन नहीं है।

पहली समस्या को हल करने के लिए, आप ASOF JOIN का उपयोग कर सकते हैं। विचार काफी सरल है - प्रत्येक सर्वर के प्रत्येक काउंटर के लिए समान रूप से भरे समय अंतराल के साथ समान रूप से एक तालिका बनाने के लिए। ASOF JOIN का उपयोग करने से कच्चे डेटा टेबल से निकटतम मानों के साथ नई तालिका में मानों को भरने की अनुमति मिलती है (ffill और bfill के समान विकल्प कॉन्फ़िगर किए जा सकते हैं)।

दूसरी समस्या का समाधान एक निश्चित समय में अधिकतम मूल्य की पसंद के साथ एकत्रीकरण है।

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

कार्यशील समाधान ClickHouse के लिए एक SQL स्क्रिप्ट हो सकता है। इस लिपि का एक उदाहरण नीचे दिया गया है। सादगी के लिए, मैंने कई सर्वरों के लिए एक ही काउंटर के लिए केवल तेज मात्रा की गणना करने पर ध्यान दिया। समाधान बहुत सरल नहीं दिखता है और बहुत सुविधाजनक नहीं है, लेकिन यह काम करता है।

परिणामस्वरूप, कार्यप्रणाली को प्रदर्शित करने के लिए पावरबीआई में एक परीक्षण रिपोर्ट बनाई गई थी।

निष्कर्ष

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

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

PS

परीक्षण के लिए कोड और डेटा यहां पोस्ट किए गए हैं ।

एकीकृत सर्वर लोड मैट्रिक्स मूल्यांकन

वर्चुअल सर्वर का उपयोग करने की सुविधाओं के बारे में कुछ शब्द

क्रियाविधि

फेसला

निष्कर्ष

More articles: