आदि को लागि उपयुक्त भण्डारण गति? फिओलाई सोधौं

fio र etcd को बारे मा एक छोटो कथा

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

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

तपाईंले भर्खरै नतिजाहरू हेर्नु पर्छ र अवधिको 99th प्रतिशतक जाँच गर्नुहोस् fdatasync 10 ms भन्दा कम। यदि त्यसो हो भने, तपाईंसँग उचित रूपमा छिटो भण्डारण छ। यहाँ परिणाम को एक उदाहरण छ:

  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 विकल्पहरू अनुकूलित गरेका छौं। fio बाट उपयोगी नतिजा प्राप्त गर्न, आफ्नै मानहरू प्रदान गर्नुहोस्। तिनीहरूलाई कहाँ पाउन? पढ्नुहोस् हामीले कसरी fio कन्फिगर गर्न सिक्यौं.
• परीक्षणको क्रममा, सबै I/O लोड fio बाट आउँछ। वास्तविक जीवनको परिदृश्यमा, भण्डारणमा wal_fsync_duration_seconds सँग सम्बन्धित अन्य लेखन अनुरोधहरू आउने सम्भावना छ। अतिरिक्त लोडले wal_fsync_duration_seconds को मान बढाउँछ। त्यसोभए यदि 99 औं पर्सेन्टाइल 10ms को नजिक छ भने, तपाईंको भण्डारण गति सकिँदैछ।
• संस्करण लिनुहोस् fio 3.5० भन्दा कम होइन (अघिल्लोले fdatasync अवधि प्रतिशतक देखाउँदैन)।
• माथि fio बाट नतिजाहरूको एक स्निपेट मात्र हो।

fio र etcd को बारे मा लामो कथा

आदिमा WAL के हो?

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

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

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

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

fio सँग भण्डारण अनुमान गर्दै

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

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

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

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

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

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

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

हामीले fio को लागि कागजातहरू मार्फत गयौं र हाम्रो लिपिको लागि विकल्पहरू छनोट गर्यौं ताकि fio ले etcd जस्तै लोड उत्पन्न गर्नेछ। हामीले स्ट्रेसबाट fio चलाएर प्रणाली कलहरू र तिनीहरूको अवधि जाँच गर्यौं, etcd जस्तै।

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

यसलाई आफै प्रयास गर्नुहोस्

हामीले तपाईंलाई fio कसरी प्रयोग गर्ने र उच्च प्रदर्शन आदिको लागि भण्डारणमा पर्याप्त गति छ कि छैन भनेर देख्यौं। अब तपाईं यसलाई प्रयोग गरेर आफ्नै लागि प्रयास गर्न सक्नुहुन्छ, उदाहरणका लागि, SSD भण्डारणमा भर्चुअल मेसिनहरू आईबीएम क्लाउड.

स्रोत: www.habr.com