etcd साठी पुरेशा कार्यक्षमतेसाठी fio सह डिस्क कसे तपासायचे

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

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

etcd क्लस्टरचे कार्यप्रदर्शन अंतर्निहित स्टोरेजच्या गतीवर खूप अवलंबून असते. etcd कामगिरीचे निरीक्षण करण्यासाठी विविध प्रोमिथियस मेट्रिक्स निर्यात करते. त्यापैकी एक आहे wal_fsync_duration_seconds. इत्यादीसाठी कागदपत्रांमध्ये ते म्हणतातजर या मेट्रिकचा 99 वा पर्सेंटाइल 10 ms पेक्षा जास्त नसेल तर ते स्टोरेज पुरेसे जलद मानले जाऊ शकते…

जर तुम्ही लिनक्स मशिनवर etcd क्लस्टर सेट करण्याचा विचार करत असाल आणि ड्राइव्हस् (जसे की SSDs) पुरेशी वेगवान आहेत की नाही हे तपासायचे असेल तर आम्ही लोकप्रिय I/O टेस्टर वापरण्याची शिफारस करतो. फियो. खालील आदेश चालविण्यासाठी पुरेसे आहे (निर्देशिका test-data चाचणी केलेल्या ड्राइव्हच्या आरोहित विभाजनामध्ये स्थित असणे आवश्यक आहे):

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

हे फक्त आउटपुट पाहण्यासाठी आणि 99 व्या टक्केवारीत बसते की नाही हे तपासण्यासाठी राहते 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 etcd बद्दल काही शब्द

साधारणपणे, डेटाबेस वापरतात सक्रिय लॉगिंग (लेखन-पुढे लॉगिंग, WAL). etcd देखील प्रभावित आहे. 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 सह वापरण्यासाठी योग्य आहे की नाही याचे तुम्ही मूल्यांकन करू शकता फियो — एक लोकप्रिय I/O परीक्षक. लक्षात ठेवा की डिस्क I/O अनेक प्रकारे होऊ शकते: सिंक/असिंक, अनेक भिन्न सिस्कॉल वर्ग, आणि असेच. नाण्याची दुसरी बाजू आहे ती fio वापरणे अत्यंत कठीण. युटिलिटीमध्ये अनेक पॅरामीटर्स आहेत आणि त्यांच्या मूल्यांच्या विविध संयोजनांमुळे पूर्णपणे भिन्न परिणाम होतात. etcd साठी वाजवी अंदाज मिळविण्यासाठी, तुम्हाला fio द्वारे व्युत्पन्न केलेले लेखन लोड etcd च्या WAL फाइल लेखन लोडच्या शक्य तितक्या जवळ आहे याची खात्री करणे आवश्यक आहे:

• याचा अर्थ असा की व्युत्पन्न 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, क्लस्टर निष्क्रिय असताना देखील. आमच्यासाठी, हे मेट्रिक्स अतिशय संशयास्पद वाटले आणि ते नेमके कशाचे प्रतिनिधित्व करतात याची आम्हाला खात्री नव्हती. याव्यतिरिक्त, क्लस्टरमध्ये व्हर्च्युअल मशीन्सचा समावेश होता, त्यामुळे विलंब आभासीकरणामुळे झाला होता की SSD दोषी होता हे सांगता येत नाही.

याव्यतिरिक्त, आम्ही हार्डवेअर आणि सॉफ्टवेअर कॉन्फिगरेशनमधील विविध बदलांचा विचार केला, म्हणून आम्हाला त्यांचे मूल्यांकन करण्याचा मार्ग आवश्यक आहे. अर्थात, प्रत्येक कॉन्फिगरेशनमध्ये etcd चालवणे आणि संबंधित प्रोमिथियस मेट्रिक्स पाहणे शक्य होईल, परंतु त्यासाठी महत्त्वपूर्ण प्रयत्न करावे लागतील. विशिष्ट कॉन्फिगरेशनचे मूल्यांकन करण्याचा एक सोपा मार्ग आम्हाला आवश्यक होता. आम्हाला etcd मधून येणार्‍या प्रोमिथियस मेट्रिक्सबद्दलची आमची समज तपासायची होती.

यासाठी दोन समस्यांचे निराकरण करणे आवश्यक आहे:

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

आम्ही समान कमांड-आधारित दृष्टिकोनाने दोन्ही समस्या सोडवल्या lsof и strace:

• च्या मदतीने lsof तुम्ही प्रक्रियेद्वारे वापरलेले सर्व फाइल वर्णनकर्ते, तसेच त्यांनी संदर्भित केलेल्या फाइल्स पाहू शकता.
• च्या मदतीने strace तुम्ही आधीच चालू असलेल्या प्रक्रियेचे विश्लेषण करू शकता किंवा प्रक्रिया चालवू शकता आणि ती पाहू शकता. कमांड या प्रक्रियेद्वारे केलेले सर्व सिस्टम कॉल आणि आवश्यक असल्यास, त्याचे वंशज प्रदर्शित करते. नंतरची प्रक्रिया फोर्किंगसाठी महत्वाची आहे आणि etcd ही अशी एक प्रक्रिया आहे.

पहिली गोष्ट आम्ही वापरली strace कुबर्नेट्स क्लस्टरमधील etcd सर्व्हर निष्क्रिय असताना तपासण्यासाठी.

म्हणून असे आढळून आले की डब्ल्यूएएल रेकॉर्ड ब्लॉक्स खूप घनतेने गटबद्ध आहेत, बहुसंख्यांचा आकार 2200-2400 बाइट्सच्या श्रेणीत होता. म्हणूनच या लेखाच्या सुरुवातीला दिलेली आज्ञा ध्वज वापरते --bs=2300 (bs मध्ये प्रत्येक राइट ब्लॉकचा बाइट्सचा आकार आहे fio).

कृपया लक्षात घ्या की आवृत्ती, उपयोजन, पॅरामीटर मूल्ये इत्यादींवर अवलंबून etcd लेखन ब्लॉक्सचा आकार बदलू शकतो. - त्याचा कालावधी प्रभावित होतो fdatasync. जर तुमच्याकडे समान वापर केस असेल तर, यासह विश्लेषण करा strace अद्ययावत मूल्ये मिळविण्यासाठी तुमची etcd प्रक्रिया.

मग, फाईल सिस्टमसह etcd कसे कार्य करते याची स्पष्ट आणि सर्वसमावेशक कल्पना मिळविण्यासाठी, आम्ही ते खालील पासून सुरू केले strace ध्वजांसह -ffttT. यामुळे बाल प्रक्रिया कॅप्चर करणे आणि प्रत्येकाचे आउटपुट वेगळ्या फाईलमध्ये लिहिणे शक्य झाले. याव्यतिरिक्त, प्रत्येक सिस्टम कॉलची प्रारंभ वेळ आणि कालावधी याबद्दल तपशीलवार माहिती प्राप्त झाली.

आम्ही कमांड देखील वापरली lsofतुमच्या आउटपुटबद्दलच्या समजाची पुष्टी करण्यासाठी strace कोणत्या फाईल डिस्क्रिप्टरचा वापर कोणत्या उद्देशाने केला गेला. मी निष्कर्ष काढला strace, वरील प्रमाणेच. सिंक्रोनाइझेशन वेळेसह सांख्यिकीय हाताळणीने पुष्टी केली की मेट्रिक wal_fsync_duration_seconds etcd मॅच कॉल्सवरून 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 etcd सह वापरण्यासाठी असलेले माध्यम पुरेसे जलद आहे की नाही हे कोणी ठरवू शकतो. आता हे तुमच्यावर अवलंबून आहे! तुम्ही सेवेमध्ये SSD-आधारित स्टोरेजसह व्हर्च्युअल मशीन एक्सप्लोर करू शकता आयबीएम क्लाउड.

अनुवादकाकडून पुनश्च

तयार-तयार वापर प्रकरणांसह fio इतर कामांसाठी, पहा दस्तऐवजीकरण किंवा थेट प्रकल्प भांडार (दस्तऐवजीकरणात नमूद करण्यापेक्षा त्यापैकी बरेच आहेत).

अनुवादकाकडून PPS

आमच्या ब्लॉगवर देखील वाचा:

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

स्त्रोत: www.habr.com