🥇 स्टोरेजचा वेग etcd साठी योग्य आहे का? चला फिओला विचारूया

fio आणि etcd बद्दल एक छोटी कथा

क्लस्टर कामगिरी इ मुख्यत्वे त्याच्या स्टोरेजच्या कामगिरीवर अवलंबून असते. etcd काही मेट्रिक्स निर्यात करते Prometheusइच्छित स्टोरेज कामगिरी माहिती प्रदान करण्यासाठी. उदाहरणार्थ, wal_fsync_duration_seconds मेट्रिक. etcd साठी कागदपत्रे सांगतात: स्टोरेज पुरेसे जलद मानले जाण्यासाठी, या मेट्रिकचा 99 वा पर्सेंटाइल 10ms पेक्षा कमी असणे आवश्यक आहे. जर तुम्ही लिनक्स मशिन्सवर etcd क्लस्टर चालवण्याचा विचार करत असाल आणि तुमचे स्टोरेज पुरेसे जलद आहे की नाही याचे मूल्यांकन करायचे असल्यास (उदा. SSD), तुम्ही वापरू शकता. फियो I/O ऑपरेशन्सची चाचणी घेण्यासाठी लोकप्रिय साधन आहे. खालील आदेश चालवा, जेथे चाचणी-डेटा स्टोरेज माउंट पॉइंट अंतर्गत निर्देशिका आहे:

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

तुम्हाला फक्त निकाल पाहण्याची आणि कालावधीची 99 वी टक्केवारी तपासायची आहे 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 च्या जवळ असल्यास, तुमचे स्टोरेज स्पीड संपत आहे.
आवृत्ती घ्या फियो 3.5 पेक्षा कमी नाही (मागील fdatasync कालावधी टक्केवारी दर्शवत नाही).
वर फक्त fio च्या निकालांचा एक झलक आहे.

fio आणि etcd बद्दल दीर्घ कथा

इत्यादी मध्ये WAL म्हणजे काय?

सहसा डेटाबेस वापरतात लिहा-पुढे लॉग; etcd ते देखील वापरते. आम्ही येथे राइट-अहेड लॉग (WAL) वर तपशीलवार चर्चा करणार नाही. आमच्यासाठी हे जाणून घेणे पुरेसे आहे की etcd क्लस्टरचा प्रत्येक सदस्य पर्सिस्टंट स्टोरेजमध्ये त्याची देखभाल करतो. etcd स्टोअरमध्ये लागू करण्यापूर्वी प्रत्येक की-व्हॅल्यू ऑपरेशन (जसे की अपडेट) WAL वर लिहिते. जर स्टोरेज सदस्यांपैकी एक क्रॅश झाला आणि स्नॅपशॉट्स दरम्यान रीस्टार्ट झाला, तर तो WAL सामग्रीद्वारे शेवटच्या स्नॅपशॉटपासून स्थानिक पातळीवर व्यवहार पुनर्संचयित करू शकतो.

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

fio नक्की का आणि आम्ही ते कसे सेट करायला शिकलो

या पोस्टमध्ये, आम्ही एका वास्तविक प्रकरणाचे वर्णन करतो. आमच्याकडे क्लस्टर आहे कुबेरनेट्स v1.13 ज्याचे आम्ही Prometheus सह परीक्षण केले. etcd v3.2.24 SSD वर होस्ट केले होते. क्लस्टर काहीही करत नसतानाही, Etcd मेट्रिक्सने fdatasync लेटेंसी खूप जास्त दाखवल्या. मेट्रिक्स विचित्र होते आणि आम्हाला त्यांचा अर्थ काय आहे हे माहित नव्हते. क्लस्टरमध्ये व्हर्च्युअल मशीन्सचा समावेश होता, समस्या काय आहे हे समजून घेणे आवश्यक होते: भौतिक एसएसडीमध्ये किंवा आभासीकरण स्तरामध्ये. याव्यतिरिक्त, आम्ही अनेकदा हार्डवेअर आणि सॉफ्टवेअर कॉन्फिगरेशनमध्ये बदल केले आणि आम्हाला त्यांच्या परिणामांचे मूल्यमापन करण्याचा मार्ग आवश्यक आहे. आम्ही प्रत्येक कॉन्फिगरेशनमध्ये etcd चालवू शकतो आणि प्रोमिथियस मेट्रिक्स पाहू शकतो, परंतु ते खूप त्रासदायक आहे. विशिष्ट कॉन्फिगरेशनचे मूल्यांकन करण्यासाठी आम्ही एक सोपा मार्ग शोधत होतो. आम्हाला etcd मधून Prometheus मेट्रिक्स बरोबर समजतात का ते तपासायचे होते.

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

क्लस्टरवर कोणतेही लोड नसताना आम्ही कुबर्नेट्ससाठी etcd सर्व्हर एक्सप्लोर करण्यासाठी प्रथम स्ट्रेसचा वापर केला. आम्ही पाहिले की जवळजवळ सर्व WAL रेकॉर्ड समान आकाराचे होते: 2200-2400 बाइट्स. म्हणून, पोस्टच्या सुरूवातीस कमांडमध्ये, आम्ही पॅरामीटर -bs=2300 (bs म्हणजे प्रत्येक fio एंट्रीसाठी बाइट्समध्ये आकार) निर्दिष्ट केला आहे. लक्षात ठेवा की etcd एंट्रीचा आकार etcd आवृत्ती, वितरण, पॅरामीटर मूल्ये इत्यादींवर अवलंबून असतो आणि fdatasync कालावधीवर परिणाम करतो. तुमच्याकडेही अशीच परिस्थिती असल्यास, अचूक संख्या शोधण्यासाठी तुमच्या etcd प्रक्रियेचे स्ट्रेससह परीक्षण करा.

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

आम्ही fio साठी कागदपत्रे पाहिली आणि आमच्या स्क्रिप्टसाठी पर्याय निवडले जेणेकरुन fio सारखे लोड तयार करेल. आम्ही स्ट्रेस वरून fio चालवून सिस्टम कॉल आणि त्यांचा कालावधी देखील तपासला, etcd प्रमाणेच.

fio वरून संपूर्ण I/O लोडचे प्रतिनिधित्व करण्यासाठी आम्ही --size पॅरामीटरचे मूल्य काळजीपूर्वक निवडले आहे. आमच्या बाबतीत, स्टोरेजवर लिहिलेल्या बाइट्सची ही एकूण संख्या आहे. हे लेखन (आणि fdatasync) सिस्टम कॉलच्या संख्येच्या थेट प्रमाणात असल्याचे दिसून आले. bs च्या ठराविक मूल्यासाठी, fdatasync कॉलची संख्या = आकार/bs. आम्हाला पर्सेंटाइलमध्ये स्वारस्य असल्याने, आमच्याकडे खात्री करण्यासाठी पुरेसे नमुने असणे आवश्यक होते आणि आम्ही गणना केली की 10^4 आमच्यासाठी पुरेसे असेल (म्हणजे 22 मेबीबाइट्स). --size लहान असल्यास, आउटलियर्स येऊ शकतात (उदाहरणार्थ, अनेक fdatasync कॉल्स नेहमीपेक्षा जास्त वेळ घेतात आणि 99 व्या टक्केवारीवर परिणाम करतात).

ते स्वतः करून पहा

आम्ही तुम्हाला fio कसे वापरायचे ते दाखवले आणि etcd चांगली कामगिरी करण्यासाठी स्टोरेज पुरेसे जलद आहे की नाही ते पाहिले. आता तुम्ही ते वापरून स्वतःसाठी वापरून पाहू शकता, उदाहरणार्थ, SSD स्टोरेजसह व्हर्च्युअल मशीन आयबीएम क्लाउड.

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

इत्यादीसाठी स्टोरेज गती योग्य आहे? चला फिओला विचारूया

fio आणि etcd बद्दल एक छोटी कथा

fio आणि etcd बद्दल दीर्घ कथा

fio सह अंदाजे स्टोरेज

fio नक्की का आणि आम्ही ते कसे सेट करायला शिकलो

ते स्वतः करून पहा

एक टिप्पणी जोडा Отменить ответ