etcd का लागि पर्याप्त प्रदर्शनको लागि fio सँग डिस्कहरू कसरी जाँच गर्ने

नोट। अनुवाद।: यो लेख etcd डाटाबेस को सञ्चालन संग सम्बन्धित एक वास्तविक समस्या को समाधान को लागी IBM क्लाउड ईन्जिनियरहरु द्वारा आयोजित एक मिनी-अनुसन्धान को परिणाम हो। यस्तै कार्य हाम्रो लागि सान्दर्भिक थियो, तर लेखकहरूको विचार र कार्यहरूको पाठ्यक्रम व्यापक सन्दर्भमा रोचक हुन सक्छ।

सम्पूर्ण लेखको संक्षिप्त सारांश: fio र etcd

एक etcd क्लस्टर को प्रदर्शन धेरै अन्तर्निहित भण्डारण को गति मा निर्भर गर्दछ। etcd प्रदर्शन निगरानी गर्न विभिन्न प्रोमेथियस मेट्रिक्स निर्यात गर्दछ। ती मध्ये एक हो wal_fsync_duration_seconds। आदि कागजातमा यो भन्छयदि यो मेट्रिकको 99 औं प्रतिशत 10 ms भन्दा बढी छैन भने त्यो भण्डारण पर्याप्त छिटो मान्न सकिन्छ ...

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

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

आउटपुट हेर्न र यो 99th प्रतिशतमा फिट हुन्छ कि भनेर जाँच गर्न बाँकी छ fdatasync 10 ms मा। यदि त्यसो हो भने, तपाईंको ड्राइभ पर्याप्त छिटो छ। यहाँ एक उदाहरण आउटपुट छ:

fsync/fdatasync/sync_file_range:
  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]

केहि नोटहरू:

1. माथिको उदाहरणमा हामीले प्यारामिटरहरू समायोजन गरेका छौं --size и --bs एक विशेष मामला को लागी। बाट सार्थक परिणाम प्राप्त गर्न fio, तपाईको प्रयोग केसको लागि उपयुक्त मानहरू निर्दिष्ट गर्नुहोस्। तिनीहरूलाई कसरी चयन गर्न तल छलफल गरिनेछ।
2. परीक्षणको क्रममा मात्र fio डिस्क सबसिस्टम लोड गर्दछ। वास्तविक जीवनमा, यो सम्भव छ कि अन्य प्रक्रियाहरूले डिस्कमा लेख्नेछ (सम्बन्धित ती बाहेक wal_fsync_duration_seconds)। यस्तो अतिरिक्त लोड मा वृद्धि हुन सक्छ wal_fsync_duration_seconds। अर्को शब्दमा, यदि परीक्षणबाट 99 औं प्रतिशत fio, 10 ms भन्दा थोरै मात्र, भण्डारण कार्यसम्पादन अपर्याप्त हुने राम्रो मौका छ।
3. परीक्षणको लागि तपाईलाई संस्करण चाहिन्छ fio 3.5० भन्दा कम होइन, किनकि पुरानो संस्करणहरूले परिणामहरू जम्मा गर्दैनन् fdatasync प्रतिशतको रूपमा।
4. माथिको निष्कर्ष समग्र निष्कर्षको सानो अंश मात्र हो fio.

fio र etcd बारे विवरण

WALs आदि बारे केही शब्दहरू

सामान्यतया, डाटाबेस प्रयोग सक्रिय लगिङ (लेखन अगाडि लगिङ, WAL)। आदि यो पनि लागू हुन्छ। WAL को छलफल यस लेखको दायराभन्दा बाहिर छ, तर हाम्रो उद्देश्यका लागि तपाईंले जान्न आवश्यक पर्ने कुराहरू यहाँ छन्: प्रत्येक etcd क्लस्टर सदस्यले निरन्तर भण्डारणमा WAL भण्डार गर्दछ। etcd ले WAL लाई कार्यान्वयन गर्नु अघि केहि प्रमुख-मान स्टोर सञ्चालनहरू (जस्तै अद्यावधिकहरू) लेख्छ। यदि नोड क्र्यास हुन्छ र स्न्यापसटहरू बीच पुन: सुरु हुन्छ भने, etcd ले WAL को सामग्रीहरूमा आधारित अघिल्लो स्न्यापसट पछि गरिएका लेनदेनहरू पुनर्स्थापित गर्न सक्छ।

यसरी, प्रत्येक पटक ग्राहकले KV स्टोरमा कुञ्जी थप्छ वा अवस्थित कुञ्जीको मान अपडेट गर्दछ, etcd ले WAL मा सञ्चालनको विवरण थप्छ, जुन निरन्तर भण्डारणमा नियमित फाइल हो। etcd 100% निश्चित हुनुपर्दछ कि WAL प्रविष्टि वास्तवमा अगाडि बढ्नु अघि बचत गरिएको छ। लिनक्समा यो प्राप्त गर्न, यो प्रणाली कल प्रयोग गर्न पर्याप्त छैन write, भौतिक माध्यममा लेख्ने कार्य आफैमा ढिलाइ हुन सक्छ। उदाहरणका लागि, लिनक्सले केही समयको लागि मेमोरीमा कर्नेल क्यास (जस्तै पृष्ठ क्यास) मा WAL प्रविष्टि राख्न सक्छ। मिडियामा डाटा लेखिएको छ भनी सुनिश्चित गर्न, लेखेपछि प्रणाली कल आह्वान गर्नुपर्छ fdatasync - यो ठ्याक्कै के हो etcd (जस्तै निम्न आउटपुटमा देख्न सकिन्छ strace; यहाँ 8 - WAL फाइल ह्यान्डल):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

दुर्भाग्यवश, निरन्तर भण्डारणमा लेख्न केही समय लाग्छ। fdatasync कल पूरा गर्न लामो समय लिँदा etcd कार्यसम्पादनलाई असर गर्न सक्छ। भण्डारको लागि कागजातमा संकेतकि पर्याप्त कार्यसम्पादनको लागि सबै कलहरूको अवधिको 99 औं प्रतिशत आवश्यक छ fdatasync WAL फाइलमा लेख्दा 10 ms भन्दा कम थियो। त्यहाँ अन्य भण्डारण-सम्बन्धित मेट्रिक्सहरू छन्, तर यो लेख त्यसमा केन्द्रित हुनेछ।

fio प्रयोग गरेर भण्डारण मूल्याङ्कन गर्दै

तपाईंले उपयोगिता प्रयोग गरेर etcd सँग प्रयोगको लागि निश्चित भण्डारण उपयुक्त छ कि छैन भनेर मूल्याङ्कन गर्न सक्नुहुन्छ fio - एक लोकप्रिय I/O परीक्षक। दिमागमा राख्नुहोस् कि डिस्क I/O धेरै फरक तरिकामा हुन सक्छ: सिंक/एसिन्क, धेरै फरक syscall कक्षाहरू, र यस्तै। सिक्काको अर्को पाटो पनि यही हो fio प्रयोग गर्न धेरै गाह्रो। उपयोगितामा धेरै प्यारामिटरहरू छन्, र तिनीहरूको मानहरूको विभिन्न संयोजनहरूले पूर्ण रूपमा फरक परिणामहरू निम्त्याउँछ। etcd को लागि एक उचित अनुमान प्राप्त गर्न, तपाईंले fio द्वारा उत्पन्न लेखन लोड WAL फाइलहरूमा etcd को लेखन लोड गर्न सम्भव छ भनेर सुनिश्चित गर्नुपर्छ:

• यसको मतलब उत्पन्न हुन्छ fio लोड कम्तिमा फाइलमा लगातार लेखहरूको श्रृंखला हुनुपर्छ, जहाँ प्रत्येक लेखन प्रणाली कल समावेश गर्दछ। writeपछि fdatasync.
• क्रमिक रेकर्डिङ सक्षम गर्न, तपाईंले झण्डा निर्दिष्ट गर्नुपर्छ --rw=write.
• कि fio कल प्रयोग गरेर लेखे write (र अन्य प्रणाली कलहरू होइन - उदाहरणका लागि, pwrite), झण्डा प्रयोग गर्नुहोस् --ioengine=sync.
• अन्तमा, झण्डा --fdatasync=1 सुनिश्चित गर्दछ कि प्रत्येक write हुनुपर्छ fdatasync.
• हाम्रो उदाहरणमा दुई अन्य प्यारामिटरहरू: --size и --bs - विशिष्ट प्रयोग मामला मा निर्भर गर्दछ भिन्न हुन सक्छ। अर्को खण्डले तिनीहरूलाई कसरी कन्फिगर गर्ने भनेर वर्णन गर्नेछ।

हामीले किन fio छनोट गर्यौं र यसलाई कसरी सेटअप गर्ने भनेर हामीले सिक्यौं

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

थप रूपमा, हामीले हार्डवेयर र सफ्टवेयर कन्फिगरेसनमा विभिन्न परिवर्तनहरू विचार गर्यौं, त्यसैले हामीलाई तिनीहरूको मूल्याङ्कन गर्ने तरिका चाहिन्छ। निस्सन्देह, प्रत्येक कन्फिगरेसनमा etcd चलाउन र सम्बन्धित प्रोमेथियस मेट्रिक्स हेर्न सम्भव हुनेछ, तर त्यसका लागि महत्त्वपूर्ण प्रयास आवश्यक पर्दछ। हामीलाई के चाहिन्छ एक विशिष्ट कन्फिगरेसन मूल्याङ्कन गर्न एक सरल तरिका थियो। हामी आदिबाट आउँदै गरेको प्रोमेथियस मेट्रिक्सको हाम्रो बुझाइ परीक्षण गर्न चाहन्थ्यौं।

यो गर्नको लागि, दुई समस्याहरू समाधान गर्न आवश्यक थियो:

• पहिलो, WAL फाइलहरूमा लेख्दा etcd उत्पन्न हुने I/O लोड कस्तो देखिन्छ? कुन प्रणाली कलहरू प्रयोग गरिन्छ? लेखन ब्लक आकार के हो?
• दोस्रो, हामीसँग माथिका प्रश्नहरूको जवाफ छ भनौं। संग सम्बन्धित लोड कसरी पुन: उत्पादन गर्ने fio? जे भएपनि fio - धेरै प्यारामिटरहरूको साथ अत्यन्त लचिलो उपयोगिता (यो प्रमाणित गर्न सजिलो छ, उदाहरणका लागि, यहाँ - लगभग। अनुवाद।).

हामीले एउटै आदेश-आधारित दृष्टिकोण प्रयोग गरेर दुवै समस्याहरू समाधान गर्यौं lsof и strace:

• सहयोगको साथ lsof तपाइँ प्रक्रिया द्वारा प्रयोग गरिएका सबै फाइल वर्णनकर्ताहरू, साथै उनीहरूले सन्दर्भ गर्ने फाइलहरू हेर्न सक्नुहुन्छ।
• सहयोगको साथ strace तपाईले पहिले नै चलिरहेको प्रक्रियाको विश्लेषण गर्न सक्नुहुन्छ वा प्रक्रिया चलाउन सक्नुहुन्छ र यसलाई हेर्न सक्नुहुन्छ। आदेशले यस प्रक्रियाद्वारा गरिएका सबै प्रणाली कलहरू र आवश्यक भएमा, यसको सन्तानहरू देखाउँछ। पछिल्लो फोर्किंग प्रक्रियाहरूको लागि महत्त्वपूर्ण छ, र etcd यस्तो प्रक्रिया हो।

हामीले प्रयोग गरेको पहिलो कुरा हो strace कुबेरनेट क्लस्टरमा etcd सर्भर निष्क्रिय हुँदा अध्ययन गर्न।

यसरी, यो पत्ता लाग्यो कि WAL मा लेख्ने ब्लकहरू धेरै घना समूहबद्ध छन्, तीमध्ये अधिकांश 2200-2400 बाइटको दायरामा छन्। यसैले यस लेखको सुरुमा आदेशले झण्डा प्रयोग गर्दछ --bs=2300 (bs - प्रत्येक रेकर्डिङ ब्लक को बाइट मा आकार fio).

कृपया नोट गर्नुहोस् कि etcd लेखन ब्लक आकारहरू संस्करण, परिनियोजन, प्यारामिटर मानहरू, इत्यादिको आधारमा भिन्न हुन सक्छ। - यसले अवधिलाई असर गर्छ fdatasync। यदि तपाइँसँग समान प्रयोग केस छ भने, विश्लेषण गर्नुहोस् strace तपाईंको etcd प्रक्रियाहरू नवीनतम मानहरू प्राप्त गर्न।

त्यसोभए, फाइल प्रणालीसँग etcd कसरी काम गर्दछ भन्ने स्पष्ट र व्यापक विचार प्राप्त गर्न, हामीले यसलाई तलबाट सुरु गर्यौं। strace झण्डा संग -ffttT। यसले बच्चा प्रक्रियाहरू क्याप्चर गर्न र प्रत्येकको आउटपुटलाई छुट्टै फाइलमा लेख्न सम्भव बनायो। थप रूपमा, प्रत्येक प्रणाली कलको सुरुवात क्षण र अवधि बारे विस्तृत जानकारी प्राप्त गरिएको थियो।

हामीले आदेश पनि प्रयोग गर्यौं lsofआउटपुट बारे आफ्नो बुझाइ पुष्टि गर्न strace कुन उद्देश्यका लागि कुन फाइल वर्णनकर्ता प्रयोग गरिएको थियो भन्ने सन्दर्भमा। नतिजा आयो strace, माथिको जस्तै। सिंक्रोनाइजेसन समयको साथ सांख्यिकीय हेरफेरले पुष्टि गर्यो कि मेट्रिक wal_fsync_duration_seconds आदि मेल कलहरूबाट fdatasync WAL फाइल वर्णनकर्ताहरूसँग।

प्रयोग गरेर उत्पन्न गर्न fio etcd बाट लोड जस्तै कार्यभार, उपयोगिता कागजात अध्ययन गरियो र हाम्रो कार्यको लागि उपयुक्त प्यारामिटरहरू चयन गरियो। हामीले सुनिश्चित गर्यौं कि सही प्रणाली कलहरू समावेश थिए र चलाएर तिनीहरूको अवधि पुष्टि गर्‍यौं fio बाट strace (जस्तै etcd को मामला मा गरिएको थियो)।

प्यारामिटरको मूल्य निर्धारण गर्न विशेष ध्यान दिइयो --size। यसले fio उपयोगिता द्वारा उत्पन्न कुल I/O लोड प्रतिनिधित्व गर्दछ। हाम्रो अवस्थामा, यो मिडियामा लेखिएका बाइटहरूको कुल संख्या हो। यो कल को संख्या को सीधा समानुपातिक छ write (र fdatasync)। एक निश्चित को लागी bs कलहरूको संख्या fdatasync बराबरी size / bs.

हामीले पर्सेन्टाइलमा रुचि राखेको हुनाले, हामी नमूनाहरूको संख्या सांख्यिकीय रूपमा महत्त्वपूर्ण हुन पर्याप्त ठूलो हुन चाहन्छौं। र त्यो निर्णय गरे 10^4 (जुन 22 MB को आकार संग मेल खान्छ) पर्याप्त हुनेछ। सानो प्यारामिटर मानहरू --size थप स्पष्ट आवाज दियो (उदाहरणका लागि, कलहरू fdatasync, जसले सामान्य भन्दा धेरै समय लिन्छ र 99 औं प्रतिशतलाई असर गर्छ)।

यो तिमीमा भर पर्छ

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

अनुवादकबाट PS

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

अनुवादकबाट PPS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «etcd 3.4.3: भण्डारण विश्वसनीयता र सुरक्षाको अध्ययन»;
• «etcd Kubernetes क्लस्टरमा डाटासँग काम गर्ने हाम्रो अनुभव सीधा (K8s API बिना)»;
• «Kubernetes को सञ्चालनमा 6 मनोरञ्जन प्रणाली बगहरू [र तिनीहरूको समाधान]"।

स्रोत: www.habr.com