क्या भंडारण गति आदि के लिए उपयुक्त है? फियो से पूछो

फियो और etcd के बारे में एक छोटी कहानी

Etcd क्लस्टर का प्रदर्शन काफी हद तक इसके भंडारण के प्रदर्शन पर निर्भर करता है। वगैरह ने भंडारण प्रदर्शन के बारे में आवश्यक जानकारी प्रदान करने के लिए प्रोमेथियस को कुछ मैट्रिक्स निर्यात किए। उदाहरण के लिए, मीट्रिक wal_fsync_duration_seconds। Etcd के लिए दस्तावेज़ीकरण कहता है : भंडारण के लिए तेजी से पर्याप्त माना जाता है, इस मीट्रिक का 99 वां प्रतिशत 10 एमएस से कम होना चाहिए। यदि आप लिनक्स मशीनों पर etcd क्लस्टर चलाने की योजना बनाते हैं और मूल्यांकन करना चाहते हैं कि क्या आपका स्टोरेज पर्याप्त है (उदाहरण के लिए, SSDs), तो आप fio का उपयोग कर सकते हैं, I / O संचालन के परीक्षण के लिए एक लोकप्रिय उपकरण। निम्न आदेश चलाएँ, जहाँ परीक्षण-डेटा संग्रहण माउंट बिंदु के नीचे निर्देशिका है:

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest 

आपको केवल परिणामों को देखने और यह सत्यापित करने की आवश्यकता है कि fdatasync अवधि का 99 वां प्रतिशत 10 एमएस से कम है। यदि हां, तो आपके पास काफी तेज भंडारण है। यहाँ परिणामों का एक उदाहरण है:

  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70 sync percentiles (usec): | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627], | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549], | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278], | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795], | 99.99th=[15795] 

नोट

• हमने अपने विशिष्ट परिदृश्य के लिए --size और --bs विकल्प कॉन्फ़िगर किए हैं। फियो से एक उपयोगी परिणाम प्राप्त करने के लिए, अपने मूल्यों को दर्ज करें। उन्हें कहाँ से लाएँ? पढ़ें कि हमने कैसे एफआईओ को कॉन्फ़िगर करना सीखा ।
• परीक्षण के दौरान, संपूर्ण I / O लोड फियो से आता है। वास्तविक परिदृश्य में, यह संभावना है कि अन्य लेखन अनुरोध भंडार पर आएंगे, केवल उन लोगों को छोड़कर, जो वॉल_एफ़्फ़्फ़्फ़्फ़्फ़्फ़्फ़्फ़्फ़्फ़्फ़्फ़्फ़्स्न्न्द्स्् it् it्ग्छ्छ्ठ्ठ्ठ्ठ्ठ्ठ्ठ्ठ्ठ्ठ्ठ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढढढ्ढ्ढ्ढ्ढ्ढ्ढ्ढढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढ्ढे में, इसमें जो कुछ भी लिखा गया है, वह होगा। अतिरिक्त लोड से wal_fsync_duration_seconds का मान बढ़ जाएगा। इसलिए यदि 99 प्रतिशत प्रतिशत लगभग 10 एमएस तक पहुंच गया है, तो आपके भंडारण में पर्याप्त गति नहीं होगी।
• 3.5 से कम कोई fio संस्करण लें (पिछले वाले fdatasync अवधि का प्रतिशत प्रदर्शित नहीं करते हैं)।
• इसके बाद के संस्करण fio से परिणामों का केवल एक टुकड़ा है।

फियो और कॉर्ड के बारे में एक लंबी कहानी

वॉर्ड में क्या है?

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

जब कोई क्लाइंट कुंजी-मूल्य वाले जोड़े के स्टोर में एक कुंजी जोड़ता है या किसी मौजूदा कुंजी के मूल्य को अपडेट करता है, तो etc वाल में इस ऑपरेशन को रिकॉर्ड करता है, जो लगातार भंडारण में एक नियमित फ़ाइल है। आगे बढ़ने से पहले, etcd MUST को पूरी तरह से यकीन है कि वाल को लिखना वास्तव में हुआ था। लिनक्स पर, इसके लिए एक एकल लेखन प्रणाली कॉल पर्याप्त नहीं है, क्योंकि वास्तव में भौतिक भंडारण में लिखने में देरी हो सकती है। उदाहरण के लिए, कुछ समय के लिए लिनक्स कर्नेल मेमोरी में कैश में वाल रिकॉर्ड स्टोर कर सकता है (उदाहरण के लिए, पेज कैश)। और डेटा को लगातार स्टोरेज पर सटीक रूप से लिखे जाने के लिए, आपको लिखने के बाद fdatasync सिस्टम कॉल की आवश्यकता होती है, और etcd बस इसका उपयोग करता है (जैसा कि आप स्ट्रेस से देख सकते हैं, जहां 8 वाल फाइल डिस्क्रिप्टर है):

 21:23:09.894875 lseek(8, 0, SEEK_CUR) = 12808 <0.000012> 21:23:09.894911 write(8, ".\0\0\0\0\0\0\202\10\2\20\361\223\255\266\6\32$\10\0\20\10\30\26\"\34\"\r\n\3fo"..., 2296) = 2296 <0.000130> 21:23:09.895041 fdatasync(8) = 0 <0.008314> 

दुर्भाग्य से, लगातार भंडारण के लिए लेखन तुरंत नहीं जाता है। यदि fdatasync कॉल धीमा है, तो etcd सिस्टम प्रदर्शन ड्रॉप हो जाता है। Etcd के लिए दस्तावेज़ीकरण कहता है कि रिपॉजिटरी को काफी तेज माना जाता है अगर 99 वाँ प्रतिशत fdatasync कॉल में इसे 10 से कम ms तक चलने के लिए WAL फ़ाइल को लिखना पड़ता है। भंडारण के लिए अन्य उपयोगी मीट्रिक हैं, लेकिन इस पोस्ट में हम केवल इस मीट्रिक के बारे में बात कर रहे हैं।

फियो के साथ भंडारण का आकलन करें

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

नतीजतन, फियो को कम से कम फाइल में अनुक्रमिक लिखने के संचालन की एक श्रृंखला के रूप में एक लोड बनाना चाहिए, प्रत्येक रिकॉर्ड में एक fdatasync सिस्टम कॉल के बाद एक लेखन सिस्टम कॉल शामिल होगा। क्रमिक लेखन कार्यों के लिए, fio को --rw = लिखने के विकल्प की आवश्यकता होती है। रिकॉर्डिंग के दौरान लिखने के बजाय लिखने की प्रणाली का उपयोग करने के लिए fio के लिए , यह --ioengine = सिंक पैरामीटर को निर्दिष्ट करने के लायक है। अंत में, प्रत्येक प्रविष्टि के बाद कॉल किए जाने वाले fdatasync के लिए, आपको --fdatasync = 1 पैरामीटर जोड़ना होगा। इस उदाहरण में अन्य दो विकल्प (--साइज और --बीएस) विशिष्ट हैं। अगले भाग में, हम आपको दिखाएंगे कि उन्हें कैसे कॉन्फ़िगर किया जाए।

फियो क्यों और कैसे हमने इसे कॉन्फ़िगर करना सीखा

इस पोस्ट में हम वास्तविक मामले का वर्णन करते हैं। हमारे पास एक कुबेरनेट्स v1.13 क्लस्टर था, जिसे हमने प्रोमेथियस का उपयोग करके मॉनिटर किया था। etcd v3.2.24 को एक SSD पर होस्ट किया गया था। Etcd मेट्रिक्स ने fdatasync के लिए बहुत अधिक विलंबताएं दिखाईं, तब भी जब क्लस्टर कुछ भी नहीं कर रहा था। मैट्रिक्स अजीब थे, और हम वास्तव में नहीं जानते थे कि उनका क्या मतलब है। क्लस्टर में वर्चुअल मशीन शामिल थी, आपको यह समझना था कि समस्या क्या थी: भौतिक SSDs में या वर्चुअलाइजेशन परत में। इसके अलावा, हमने अक्सर हार्डवेयर और सॉफ़्टवेयर कॉन्फ़िगरेशन में बदलाव किए, और हमें उनके परिणामों के मूल्यांकन के लिए एक तरीके की आवश्यकता थी। हम प्रत्येक कॉन्फ़िगरेशन में etcd चला सकते हैं और प्रोमेथियस मेट्रिक्स को देख सकते हैं, लेकिन यह बहुत तकलीफदेह है। हम एक विशिष्ट विन्यास का मूल्यांकन करने के लिए काफी सरल तरीके की तलाश कर रहे थे। हम यह जांचना चाहते थे कि क्या हमने वर्थ से प्रोमेथियस मेट्रिक्स को सही ढंग से समझा है।

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

सबसे पहले, हमने क्लस्टर पर लोड नहीं होने पर कुबेरनेट्स के लिए इंकड सर्वर सीखने के लिए स्ट्रेस का इस्तेमाल किया। हमने देखा कि लगभग सभी वाल रिकॉर्ड एक ही आकार के थे: 2200-2400 बाइट्स। इसलिए, पोस्ट की शुरुआत में कमांड में, हमने पैरामीटर निर्दिष्ट किया है --बीएस = 2300 (bs का अर्थ प्रत्येक फियो प्रविष्टि के लिए बाइट्स में आकार है)। ध्यान दें कि etcd प्रविष्टि का आकार etcd, वितरण, पैरामीटर मान आदि के संस्करण पर निर्भर करता है, और fdatasync की अवधि को प्रभावित करता है। यदि आपके पास एक समान परिदृश्य है, तो सटीक संख्याओं का पता लगाने के लिए स्ट्रेच के साथ अपने वक्ष प्रक्रियाओं की जांच करें।

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

हमने फिओ डॉक्यूमेंटेशन का अध्ययन किया और अपनी स्क्रिप्ट के लिए विकल्पों का चयन किया ताकि फियो आदि के समान लोड उत्पन्न हो। हमने सिस्टम कॉल और उनकी अवधि की जांच स्ट्रीड से Fio चलाकर की है, जैसे कि etcd।

हमने ध्यान से --साइज पैरामीटर के मान का चयन किया, जो फियो से संपूर्ण I / O लोड का प्रतिनिधित्व करता है। हमारे मामले में, यह स्टोरेज को लिखे गए बाइट्स की कुल संख्या है। यह लिखने की संख्या (और fdatasync) सिस्टम कॉल की सीधे आनुपातिक निकला। विशिष्ट bs मान के लिए, fdatasync = size / bs पर कॉल की संख्या। चूंकि हम प्रतिशत में रुचि रखते थे, इसलिए हमें विश्वसनीयता के लिए पर्याप्त नमूने होने चाहिए थे, और हमने गणना की कि 10 ^ 4 हमारे लिए पर्याप्त होगा (हमें 22 mebibytes मिलते हैं)। यदि - आकार छोटा है, तो आउटलेयर हो सकता है (उदाहरण के लिए, कई fdatasync कॉल सामान्य से अधिक समय तक काम करते हैं और 99 वें प्रतिशत को प्रभावित करते हैं)।

इसे स्वयं आजमाएं

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