ល្បឿនផ្ទុកសមរម្យសម្រាប់ etcd? តោះសួរហ្វី

រឿងខ្លីអំពី fio និង ល។

ការអនុវត្តចង្កោម ល ភាគច្រើនអាស្រ័យទៅលើដំណើរការនៃការផ្ទុករបស់វា។ etcd នាំចេញម៉ែត្រមួយចំនួនទៅ Prometheusដើម្បីផ្តល់ព័ត៌មានដំណើរការផ្ទុកដែលចង់បាន។ ឧទាហរណ៍ wal_fsync_duration_seconds ម៉ែត្រ។ ឯកសារសម្រាប់ etcd និយាយ៖ ដើម្បីឱ្យទំហំផ្ទុកត្រូវបានចាត់ទុកថាលឿនគ្រប់គ្រាន់នោះ ភាគរយទី 99 នៃម៉ែត្រនេះត្រូវតែតិចជាង 10ms ។ ប្រសិនបើអ្នកមានគម្រោងដំណើរការ etcd cluster នៅលើម៉ាស៊ីនលីនុច ហើយចង់វាយតម្លៃថាតើទំហំផ្ទុករបស់អ្នកលឿនគ្រប់គ្រាន់ (ឧ. SSD) អ្នកអាចប្រើ fio គឺជាឧបករណ៍ដ៏ពេញនិយមសម្រាប់សាកល្បងប្រតិបត្តិការ 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 នោះទំហំផ្ទុករបស់អ្នកនឹងអស់ល្បឿនហើយ។
• យកកំណែ fio មិនតិចជាង ៨០ (ពីមុនមិនបង្ហាញភាគរយរយៈពេល fdatasync) ។
• ខាង​លើ​គឺ​គ្រាន់​តែ​ជា​ផ្នែក​មួយ​នៃ​លទ្ធផល​ពី fio។

រឿងវែងអំពី fio និង ល។

តើអ្វីទៅជា WAL នៅក្នុង ល។

ជាធម្មតាមូលដ្ឋានទិន្នន័យប្រើ កំណត់ហេតុសរសេរជាមុន; etcd ក៏ប្រើវាដែរ។ យើងនឹងមិនពិភាក្សាអំពីកំណត់ហេតុសរសេរមុន (WAL) លម្អិតនៅទីនេះទេ។ វាគ្រប់គ្រាន់សម្រាប់ពួកយើងដើម្បីដឹងថាសមាជិកនីមួយៗនៃក្រុម etcd រក្សាវានៅក្នុងការផ្ទុកជាប់លាប់។ etcd សរសេរប្រតិបត្តិការតម្លៃគន្លឹះនីមួយៗ (ដូចជាការធ្វើបច្ចុប្បន្នភាព) ទៅ WAL មុនពេលអនុវត្តវាទៅហាង។ ប្រសិនបើសមាជិកផ្ទុកទិន្នន័យណាមួយគាំង និងចាប់ផ្តើមឡើងវិញរវាងរូបថតនោះ វាអាចស្តារប្រតិបត្តិការឡើងវិញក្នុងមូលដ្ឋាន ចាប់តាំងពីរូបថតចុងក្រោយដោយខ្លឹមសារ WAL។

នៅពេលម៉ាស៊ីនភ្ញៀវបន្ថែមកូនសោទៅឃ្លាំងតម្លៃសោរ ឬធ្វើបច្ចុប្បន្នភាពតម្លៃនៃសោដែលមានស្រាប់ ល.ល កត់ត្រាប្រតិបត្តិការនៅក្នុង 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 ចំណាយពេលតិចជាង 10ms ដើម្បីសរសេរទៅឯកសារ WAL ។ មានរង្វាស់ដែលមានប្រយោជន៍ផ្សេងទៀតសម្រាប់ការផ្ទុក ប៉ុន្តែនៅក្នុងការប្រកាសនេះ យើងគ្រាន់តែនិយាយអំពីម៉ែត្រនេះប៉ុណ្ណោះ។

ការប៉ាន់ស្មានទំហំផ្ទុកជាមួយ fio

ប្រសិនបើអ្នកត្រូវការវាយតម្លៃថាតើទំហំផ្ទុករបស់អ្នកសាកសមនឹង etcd សូមប្រើ fio ដែលជាឧបករណ៍ធ្វើតេស្តផ្ទុក I/O ដ៏ពេញនិយម។ វាគួរតែត្រូវបានចងចាំក្នុងចិត្តថា ប្រតិបត្តិការថាសអាចមានភាពខុសគ្នាខ្លាំង៖ ការធ្វើសមកាលកម្ម និងអសមកាល ថ្នាក់ជាច្រើននៃការហៅប្រព័ន្ធ។ល។ ជាលទ្ធផល fio ពិបាកប្រើណាស់។ វាមានប៉ារ៉ាម៉ែត្រជាច្រើន ហើយការបន្សំផ្សេងៗគ្នានៃតម្លៃរបស់វាបង្កើតបន្ទុកការងារ I/O ខុសគ្នាខ្លាំង។ ដើម្បីទទួលបានតួរលេខគ្រប់គ្រាន់សម្រាប់ etcd អ្នកគួរតែប្រាកដថាការធ្វើតេស្តសរសេរផ្ទុកពី fio គឺនៅជិតបំផុតតាមដែលអាចធ្វើទៅបានទៅនឹងបន្ទុកជាក់ស្តែងពី etcd នៅពេលសរសេរឯកសារ WAL ។

ដូច្នេះ fio គួរតែបង្កើតបន្ទុកនៃស៊េរីនៃការសរសេរជាបន្តបន្ទាប់ទៅកាន់ឯកសារ ការសរសេរនីមួយៗនឹងមានការហៅប្រព័ន្ធ។ សរសេរបន្តដោយការហៅប្រព័ន្ធ fdatasync ។ ការសរសេរជាបន្តបន្ទាប់ទៅ fio ទាមទារជម្រើស --rw=write ។ សម្រាប់ fio ដើម្បីប្រើការហៅប្រព័ន្ធសរសេរនៅពេលសរសេរជាជាង សរសេរអ្នកគួរតែបញ្ជាក់ប៉ារ៉ាម៉ែត្រ --ioengine=sync ។ ជាចុងក្រោយ ដើម្បីហៅ fdatasync បន្ទាប់ពីការសរសេរនីមួយៗ អ្នកត្រូវបន្ថែមប៉ារ៉ាម៉ែត្រ --fdatasync=1 ។ ជម្រើសពីរផ្សេងទៀតក្នុងឧទាហរណ៍នេះ (--size និង -bs) គឺជាស្គ្រីបជាក់លាក់។ នៅផ្នែកបន្ទាប់ យើងនឹងបង្ហាញអ្នកពីរបៀបដំឡើងពួកវា។

ហេតុអ្វីបានជា fio ពិតប្រាកដ និងរបៀបដែលយើងរៀនរៀបចំវា។

នៅក្នុងការប្រកាសនេះ យើងរៀបរាប់អំពីករណីពិតមួយ។ យើង​មាន​ចង្កោម Kubernetes v1.13 ដែលយើងត្រួតពិនិត្យជាមួយ Prometheus ។ etcd v3.2.24 ត្រូវបានបង្ហោះនៅលើ SSD ។ Etcd metrics បានបង្ហាញពីភាពយឺតយ៉ាវ fdatasync ខ្ពស់ពេក សូម្បីតែនៅពេលចង្កោមមិនធ្វើអ្វីក៏ដោយ។ រង្វាស់គឺចម្លែក ហើយយើងពិតជាមិនដឹងថាវាមានន័យអ្វីនោះទេ។ ចង្កោមមានម៉ាស៊ីននិម្មិត វាចាំបាច់ត្រូវយល់ពីអ្វីដែលជាបញ្ហា៖ នៅក្នុង SSDs រាងកាយ ឬនៅក្នុងស្រទាប់និម្មិត។ លើសពីនេះ ជាញឹកញាប់យើងធ្វើការផ្លាស់ប្តូរទៅលើការកំណត់រចនាសម្ព័ន្ធផ្នែករឹង និងសូហ្វវែរ ហើយយើងត្រូវការវិធីដើម្បីវាយតម្លៃលទ្ធផលរបស់វា។ យើងអាចដំណើរការ etcd នៅគ្រប់ការកំណត់រចនាសម្ព័ន្ធ ហើយមើលម៉ែត្រ Prometheus ប៉ុន្តែនោះជាការរំខានច្រើនពេកហើយ។ យើងកំពុងស្វែងរកមធ្យោបាយដ៏សាមញ្ញមួយដើម្បីវាយតម្លៃការកំណត់រចនាសម្ព័ន្ធជាក់លាក់មួយ។ យើងចង់ពិនិត្យមើលថាតើយើងយល់ពីម៉ែត្ររបស់ Prometheus ពី etcd ត្រឹមត្រូវដែរឬទេ។

ប៉ុន្តែសម្រាប់បញ្ហានេះ បញ្ហាពីរត្រូវដោះស្រាយ។ ទីមួយ តើការផ្ទុក I/O ដែល etcd បង្កើតនៅពេលសរសេរទៅ WAL មើលទៅដូចអ្វី? តើ​ការ​ហៅ​ទូរសព្ទ​ប្រព័ន្ធ​អ្វី​ត្រូវ​បាន​ប្រើ? តើកំណត់ត្រាមានទំហំប៉ុនណា? ទីពីរ ប្រសិនបើយើងឆ្លើយសំណួរទាំងនេះ តើយើងបង្កើតបន្ទុកការងារស្រដៀងគ្នាជាមួយ fio យ៉ាងដូចម្តេច? កុំភ្លេចថា fio គឺជាឧបករណ៍ដែលអាចបត់បែនបានជាមួយនឹងជម្រើសជាច្រើន។ យើងបានដោះស្រាយបញ្ហាទាំងពីរជាមួយនឹងវិធីសាស្រ្តមួយ - ដោយប្រើពាក្យបញ្ជា សូហ្វ и ខ្សែ. lsof រាយបញ្ជីឯកសារពណ៌នាទាំងអស់ដែលប្រើដោយដំណើរការ និងឯកសារដែលពាក់ព័ន្ធរបស់វា។ ហើយជាមួយនឹងការតាមដាន អ្នកអាចពិនិត្យមើលដំណើរការដែលកំពុងដំណើរការរួចហើយ ឬចាប់ផ្តើមដំណើរការ ហើយពិនិត្យមើលវា។ strace បោះពុម្ពការហៅប្រព័ន្ធទាំងអស់ពីដំណើរការដែលកំពុងពិនិត្យ (និងដំណើរការកូនរបស់វា)។ ក្រោយមកទៀតគឺមានសារៈសំខាន់ខ្លាំងណាស់ ចាប់តាំងពី etcd គឺគ្រាន់តែយកវិធីសាស្រ្តស្រដៀងគ្នា។

ដំបូងឡើយ យើងបានប្រើ strace ដើម្បីរុករក server etcd សម្រាប់ Kubernetes នៅពេលដែលមិនមានផ្ទុកនៅលើ cluster។ យើងឃើញថាកំណត់ត្រា WAL ស្ទើរតែទាំងអស់មានទំហំដូចគ្នា៖ 2200-2400 បៃ។ ដូច្នេះនៅក្នុងពាក្យបញ្ជានៅដើមប្រកាស យើងបានបញ្ជាក់ប៉ារ៉ាម៉ែត្រ -bs=2300 (bs មានន័យថាទំហំគិតជាបៃសម្រាប់ធាតុ fio នីមួយៗ)។ ចំណាំថាទំហំនៃធាតុ etcd អាស្រ័យលើកំណែ etcd ការចែកចាយ តម្លៃប៉ារ៉ាម៉ែត្រ។ល។ និងប៉ះពាល់ដល់រយៈពេល fdatasync ។ ប្រសិនបើអ្នកមានសេណារីយ៉ូស្រដៀងគ្នានេះ សូមពិនិត្យមើលដំណើរការ etcd របស់អ្នកជាមួយនឹងខ្សែបន្ទាត់ ដើម្បីរកឱ្យឃើញចំនួនពិតប្រាកដ។

បន្ទាប់មក ដើម្បីទទួលបានគំនិតល្អអំពីអ្វីដែលប្រព័ន្ធឯកសារ etcd កំពុងធ្វើ យើងបានចាប់ផ្តើមវាជាមួយនឹងជម្រើស strace និង -ffttT ។ ដូច្នេះ យើងបានព្យាយាមពិនិត្យមើលដំណើរការរបស់កុមារ និងកត់ត្រាលទ្ធផលនៃពួកវានីមួយៗនៅក្នុងឯកសារដាច់ដោយឡែកមួយ ហើយក៏ទទួលបានរបាយការណ៍លម្អិតអំពីការចាប់ផ្តើម និងរយៈពេលនៃការហៅប្រព័ន្ធនីមួយៗផងដែរ។ យើងបានប្រើ lsof ដើម្បីបញ្ជាក់ការវិភាគរបស់យើងអំពីលទ្ធផល strace និងមើលថាតើអ្នកពិពណ៌នាឯកសារមួយណាកំពុងត្រូវបានប្រើប្រាស់សម្រាប់គោលបំណងណាមួយ។ ដូច្នេះដោយមានជំនួយពី strace លទ្ធផលដែលបានបង្ហាញខាងលើត្រូវបានទទួល។ ស្ថិតិពេលវេលាធ្វើសមកាលកម្មបានបញ្ជាក់ថា wal_fsync_duration_seconds ពី etcd គឺស្របជាមួយនឹងការហៅ fdatasync ជាមួយអ្នកពិពណ៌នាឯកសារ WAL ។

យើងបានឆ្លងកាត់ឯកសារសម្រាប់ fio ហើយជ្រើសរើសជម្រើសសម្រាប់ស្គ្រីបរបស់យើង ដូច្នេះ fio នឹងបង្កើតបន្ទុកស្រដៀងនឹង etcd ។ យើងក៏បានពិនិត្យការហៅទូរសព្ទតាមប្រព័ន្ធ និងរយៈពេលរបស់វាដោយដំណើរការ fio ពី strace ស្រដៀងនឹង etcd ។

យើងបានជ្រើសរើសដោយប្រុងប្រយ័ត្ននូវតម្លៃនៃប៉ារ៉ាម៉ែត្រ --size ដើម្បីតំណាងឱ្យការផ្ទុក I/O ទាំងមូលពី fio ។ ក្នុងករណីរបស់យើង នេះគឺជាចំនួនសរុបនៃបៃដែលសរសេរទៅកន្លែងផ្ទុក។ វាប្រែទៅជាសមាមាត្រដោយផ្ទាល់ទៅនឹងចំនួននៃការហៅប្រព័ន្ធសរសេរ (និង fdatasync) ។ សម្រាប់តម្លៃជាក់លាក់នៃ bs ចំនួននៃការហៅ fdatasync = size/bs ។ ដោយសារយើងចាប់អារម្មណ៍លើភាគរយ យើងត្រូវតែមានគំរូគ្រប់គ្រាន់ដើម្បីប្រាកដ ហើយយើងបានគណនាថា 10^4 នឹងគ្រប់គ្រាន់សម្រាប់យើង (នោះគឺ 22 មេកាបៃ)។ ប្រសិនបើ --size តូចជាង នោះ outliers អាចនឹងកើតឡើង (ឧទាហរណ៍ ការហៅ fdatasync ជាច្រើនចំណាយពេលយូរជាងធម្មតា និងប៉ះពាល់ដល់ភាគរយទី 99)។

សាកល្បងវាដោយខ្លួនឯង។

យើង​បាន​បង្ហាញ​អ្នក​ពី​របៀប​ប្រើ fio និង​មើល​ថា​តើ​កន្លែង​ផ្ទុក​មាន​ល្បឿន​លឿន​គ្រប់គ្រាន់​ដើម្បី​ឲ្យ etcd ដំណើរការ​បាន​ល្អ​ឬ​អត់។ ឥឡូវ​នេះ អ្នក​អាច​សាកល្បង​វា​ដោយ​ខ្លួន​អ្នក​ដោយ​ប្រើ​ឧទាហរណ៍ ម៉ាស៊ីន​និម្មិត​ដែល​មាន​កន្លែង​ផ្ទុក SSD នៅ​ក្នុង IBM Cloud.

ប្រភព: www.habr.com