د ذخیره کولو سرعت د etcd لپاره مناسب دی؟ راځئ چې د فیو څخه پوښتنه وکړو

د ذخیره کولو سرعت د etcd لپاره مناسب دی؟ راځئ چې د فیو څخه پوښتنه وکړو

د fio او etc په اړه لنډه کیسه

د کلستر فعالیت 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 کې څه شی دی؟

معمولا ډیټابیسونه کاروي د لیکلو مخکی لاګ; 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 اختیار ته اړتیا لري. د فیو لپاره د لیکلو سیسټم کارولو لپاره د لیکلو پر ځای زنګ ووهئ لیکل، تاسو باید --ioengine=sync پیرامیټر مشخص کړئ. په نهایت کې ، د هرې لیکنې وروسته fdatasync زنګ وهلو لپاره ، تاسو اړتیا لرئ --fdatasync=1 پیرامیټر اضافه کړئ. په دې مثال کې نور دوه اختیارونه (--size او -bs) د سکریپټ ځانګړي دي. په راتلونکې برخه کې، موږ به تاسو ته وښیو چې څنګه یې تنظیم کړئ.

ولې واقعیا فیو او څنګه موږ د دې تنظیم کول زده کړل

پدې پوسټ کې ، موږ یو ریښتینی قضیه بیانوو. موږ یو کلستر لرو کوبنیټس v1.13 کوم چې موږ د پرومیټیوس سره څارنه وکړه. etcd v3.2.24 په SSD کې کوربه شوی و. د Etcd میټریکونو د fdatasync ځنډ خورا لوړ ښودلی، حتی کله چې کلستر هیڅ نه کوي. میټریکونه عجیب وو او موږ واقعیا نه پوهیږو چې دوی څه معنی لري. کلستر د مجازی ماشینونو څخه جوړه وه، دا اړینه وه چې پوه شي چې ستونزه څه وه: په فزیکي SSDs یا د مجازی کولو پرت کې. سربیره پردې، موږ ډیری وختونه د هارډویر او سافټویر ترتیب کې بدلونونه راوستل، او موږ د دوی پایلو ارزولو لپاره یوې لارې ته اړتیا درلوده. موږ کولی شو etcd په هر ترتیب کې پرمخ یوسو او د پرومیتیس میټریکونو ته وګورو، مګر دا ډیره ستونزه ده. موږ د یو ځانګړي ترتیب ارزولو لپاره د کافي ساده لارې په لټه کې یو. موږ غوښتل وګورو چې ایا موږ د etcd څخه د Prometheus میټریک په سمه توګه پوهیږو.

مګر د دې لپاره، دوه ستونزې باید حل شي. لومړی، د I/O بار چې etcd رامینځته کوي د WAL لیکلو په څیر څه ښکاري؟ کوم سیسټم زنګونه کارول کیږي؟ د ریکارډ اندازه څومره ده؟ دوهم، که موږ دې پوښتنو ته ځواب ووایو، موږ څنګه د فیو سره ورته کاري بار بیا تولید کوو؟ مه هیروئ چې فیو د ډیری اختیارونو سره خورا انعطاف وړ وسیله ده. موږ دواړه ستونزې په یوه طریقه حل کړې - د امرونو په کارولو سره lsof и پارچه. lsof ټول د فایل تشریح کونکي لیست کوي چې د پروسې لخوا کارول کیږي او د دوی اړوند فایلونه. او د سټریس سره ، تاسو کولی شئ دمخه روانه پروسه معاینه کړئ ، یا پروسه پیل کړئ او معاینه یې کړئ. سټریس د ازموینې پروسې (او د ماشوم پروسې) څخه ټول سیسټم غوښتنې چاپوي. وروستی خورا مهم دی، ځکه چې etcd یوازې ورته چلند کوي.

موږ لومړی د کبرنیټس لپاره د etcd سرور سپړلو لپاره سټریس کارولی کله چې په کلستر کې هیڅ بار نه و. موږ ولیدل چې د WAL نږدې ټول ریکارډونه د ورته اندازې په اړه وو: 2200-2400 بایټ. له همدې امله، د پوسټ په پیل کې په کمانډ کې، موږ پیرامیټر -bs = 2300 مشخص کړل (bs معنی د هر فیو ننوتلو لپاره د بایټ اندازه). په یاد ولرئ چې د etcd ننوتلو اندازه د etcd نسخه، توزیع، پیرامیټر ارزښتونو، او نور پورې اړه لري، او د fdatasync موده اغیزه کوي. که تاسو ورته سناریو لرئ، د کره شمیرې موندلو لپاره خپل etcd پروسې د سټیس سره معاینه کړئ.

بیا، د ښه نظر ترلاسه کولو لپاره چې د etcd فایل سیسټم څه کوي، موږ دا د سټریس او -ffttT اختیارونو سره پیل کړ. نو موږ هڅه وکړه چې د ماشوم پروسې معاینه کړو او د هر یو محصول په جلا فایل کې ثبت کړو، او همدارنګه د هر سیسټم کال د پیل او مودې په اړه مفصل راپورونه ترلاسه کړو. موږ د سټریس محصول زموږ تحلیل تاییدولو لپاره lsof کارولی او وګورو چې کوم فایل تشریح کونکی د کوم هدف لپاره کارول کیږي. نو د سټریس په مرسته، پورته ښودل شوي پایلې ترلاسه شوې. د همغږي کولو وخت احصایې تایید کړې چې د etcd څخه wal_fsync_duration_seconds د WAL فایل توضیح کونکو سره د fdatasync کالونو سره مطابقت لري.

موږ د fio لپاره اسنادو ته لاړ او زموږ د سکریپټ لپاره یې اختیارونه غوره کړل ترڅو fio د etcd په څیر یو بار تولید کړي. موږ د سیسټم زنګونه او د دوی موده هم د سټیس څخه د fio په چلولو سره چیک کړه ، ورته etcd.

موږ په دقت سره د --size پیرامیټر ارزښت غوره کړی ترڅو د fio څخه د I/O ټول بار استازیتوب وکړي. زموږ په قضیه کې، دا د ذخیره کولو لپاره لیکل شوي د بایټس مجموعه ده. دا په مستقیم ډول د لیکلو (او fdatasync) سیسټم تلیفونونو شمیر سره متناسب و. د bs د یو ټاکلي ارزښت لپاره، د fdatasync کالونو شمیر = اندازه/bs. څرنګه چې موږ د فیصدي سره علاقه درلوده، موږ باید د ډاډ ترلاسه کولو لپاره کافي نمونې ولرو، او موږ محاسبه کړه چې 10^4 به زموږ لپاره کافي وي (دا 22 میبیبایټ دی). که --size کوچنی وي، بهر ته رسیدونکي واقع کیدی شي (د بیلګې په توګه، د fdatasync ډیری زنګونه د معمول څخه ډیر وخت نیسي او 99 فیصده اغیزه کوي).

دا پخپله هڅه وکړئ

موږ تاسو ته وښودله چې څنګه fio وکاروئ او وګورئ چې ایا ذخیره د etcd لپاره د ښه ترسره کولو لپاره ګړندۍ ده. اوس تاسو کولی شئ دا د خپل ځان لپاره وکاروئ ، د مثال په توګه ، د SSD ذخیره کولو سره مجازی ماشینونه د IBM کلاز.

سرچینه: www.habr.com

Add a comment