وغيره پرو هوسٽر

نوٽ. ترجمو: هي آرٽيڪل IBM ڪلائوڊ انجنيئرز پاران ڪيل هڪ ننڍي تحقيق جا نتيجا آهن جيڪي اي ڊي ڊي ڊيٽابيس جي آپريشن سان لاڳاپيل هڪ حقيقي مسئلي جي حل جي ڳولا ۾ آهن. ساڳيو ڪم اسان لاءِ لاڳاپيل هو، پر ليکڪن جي سوچن ۽ عملن جو رخ وسيع تناظر ۾ دلچسپ ٿي سگهي ٿو.

سڄي مضمون جو مختصر خلاصو: fio ۽ وغيره

هڪ etcd ڪلستر جي ڪارڪردگي تمام گهڻو منحصر آهي بنيادي اسٽوريج جي رفتار تي. ڪارڪردگي جي نگراني ڪرڻ لاء، وغيره مختلف Prometheus ميٽرڪ برآمد ڪري ٿو. انهن مان هڪ آهي wal_fsync_duration_seconds. وغيره دستاويزن ۾ اهو چوي ٿو، انهي اسٽوريج کي ڪافي تيز سمجهي سگهجي ٿو جيڪڏهن هن ميٽرڪ جو 99th سيڪڙو 10 ms کان وڌيڪ نه آهي ...

جيڪڏهن توهان لينڪس مشينن تي هڪ etcd ڪلستر قائم ڪرڻ تي غور ڪري رهيا آهيو ۽ جانچڻ چاهيو ٿا ته ڇا اسٽوريج ڊرائيو (جهڙوڪ SSDs) ڪافي تيز آهن، اسان هڪ مشهور I/O ٽيسٽر استعمال ڪرڻ جي صلاح ڏيو ٿا. fio. بس ھيٺ ڏنل حڪم (ڊائريڪٽري 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]

ڪجھ نوٽس:

مٿين مثال ۾ اسان پيرا ميٽرز کي ترتيب ڏنو آهي --size и --bs هڪ خاص ڪيس لاء. مان بامعني نتيجا حاصل ڪرڻ لاء fio, قيمت بيان ڪريو جيڪي توهان جي استعمال جي صورت لاء مناسب آهن. ڪيئن انھن کي چونڊي هيٺ بحث ڪيو ويندو.
صرف جاچ دوران fio ڊسڪ سب سسٽم کي لوڊ ڪري ٿو. حقيقي زندگي ۾، اهو ممڪن آهي ته ٻيا عمل (ان کان سواء جيڪي لاڳاپيل آهن wal_fsync_duration_seconds). اهڙي اضافي لوڊ ۾ اضافو ٿي سگهي ٿو wal_fsync_duration_seconds. ٻين لفظن ۾، جيڪڏهن 99 هين فيصد سان ٽيسٽ مان حاصل ڪئي وئي fio، صرف 10 ms کان ٿورو گهٽ، اتي هڪ سٺو موقعو آهي ته اسٽوريج ڪارڪردگي ڪافي نه آهي.
ٽيسٽ لاءِ توھان کي ورجن جي ضرورت پوندي fio 3.5 کان گهٽ ناهي, ڇاڪاڻ ته پراڻا نسخا مجموعي نتيجا نٿا ڏين fdatasync سيڪڙو جي صورت ۾.
مٿيون نتيجو صرف مجموعي نتيجي جو هڪ ننڍڙو اقتباس آهي fio.

fio ۽ etcd بابت تفصيل

WALs وغيره بابت ڪجھ لفظ

عام طور تي، ڊيٽابيس استعمال ڪريو فعال لاگنگ (لکڻ-اڳتي لاگنگ، WAL). وغيره اهو پڻ لاڳو ٿئي ٿو. WAL بابت بحث هن مضمون جي دائري کان ٻاهر آهي، پر اسان جي مقصدن لاءِ هتي اهو آهي جيڪو توهان کي ڄاڻڻ جي ضرورت آهي: هر etcd ڪلسٽر ميمبر WAL کي مسلسل اسٽوريج ۾ محفوظ ڪري ٿو. etcd لکڻ کان اڳ WAL کي ڪي ڪي-ويليو اسٽور آپريشنز (جهڙوڪ اپڊيٽ) لکي ٿو. جيڪڏهن ڪو نوڊ حادثو ٿئي ٿو ۽ سنيپ شاٽ جي وچ ۾ ٻيهر شروع ٿئي ٿو، وغيره، WAL جي مواد جي بنياد تي اڳوڻي سنيپ شاٽ کان وٺي ڪيل ٽرانزيڪشن کي بحال ڪري سگهي ٿو.

اهڙيءَ طرح، هر دفعي هڪ ڪلائنٽ KV اسٽور ۾ هڪ ڪنجي شامل ڪري ٿو يا موجوده ڪيئي جي قيمت کي اپڊيٽ ڪري ٿو، etcd آپريشن جي وضاحت کي WAL ۾ شامل ڪري ٿو، جيڪو مستقل اسٽوريج ۾ هڪ باقاعده فائل آهي. etcd کي 100٪ پڪ هجڻ گهرجي ته اڳتي وڌڻ کان اڳ WAL داخل ٿيڻ اصل ۾ محفوظ ٿيل آهي. لينڪس تي هن کي حاصل ڪرڻ لاء، اهو ڪافي ناهي ته سسٽم ڪال استعمال ڪرڻ لاء write, ڇاڪاڻ ته لکڻ جي عمل پاڻ کي جسماني وچولي ۾ دير ٿي سگهي ٿي. مثال طور، لينڪس ڪجهه وقت لاءِ ميموري ۾ ڪنيل ڪيش (جهڙوڪ پيج ڪيش) ۾ WAL انٽري رکي سگهي ٿو. انهي کي يقيني بڻائڻ لاءِ ته ڊيٽا ميڊيا ڏانهن لکيل آهي، لکڻ کان پوءِ هڪ سسٽم ڪال سڏڻ لازمي آهي fdatasync - اھو اھو آھي جيڪو وغيره وغيره ڪندو آھي (جيئن ھيٺ ڏنل آئوٽ ۾ ڏسي سگھجي ٿو 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 کان گهٽ هئي. اسٽوريج سان لاڳاپيل ٻيون ميٽرڪ آهن، پر هي مضمون هن تي ڌيان ڏيندو.

فيو استعمال ڪندي اسٽوريج جو جائزو وٺڻ

توهان اندازو لڳائي سگهو ٿا ته ڇا هڪ خاص اسٽوريج يوٽيليٽي استعمال ڪندي etcd سان استعمال لاءِ مناسب آهي fio - هڪ مشهور I/O ٽيسٽر. ذهن ۾ رکو ته ڊسڪ I/O مختلف طريقن سان ٿي سگھي ٿو: sync/async، سسٽم ڪالن جا ڪيترائي مختلف طبقا، وغيره. سڪي جو ٻيو پاسو اهو آهي fio استعمال ڪرڻ تمام ڏکيو. افاديت ۾ ڪيترائي پيٽرول آهن، ۽ انهن جي قيمتن جي مختلف ميلاپ کي مڪمل طور تي مختلف نتيجن جي ڪري ٿي. etcd لاءِ مناسب تخمينو حاصل ڪرڻ لاءِ، توھان کي پڪ ڪرڻ گھرجي ته fio پاران تيار ڪيل لکڻ وارو لوڊ WAL فائلن تي etcd جي لکڻ واري لوڊ سان جيترو ٿي سگھي.

ان جو مطلب اهو آهي ته پيدا ڪيل fio ڪم لوڊ گھٽ ۾ گھٽ ھڪڙي فائل کي ترتيب وار لکڻين جو ھڪڙو سلسلو ھئڻ گھرجي، جتي ھر لکڻ جي عمل تي مشتمل آھي سسٽم ڪال writeپٺيان fdatasync.
ترتيب واري رڪارڊنگ کي فعال ڪرڻ لاء، توھان کي جھنڊو بيان ڪرڻ گھرجي --rw=write.
ته fio ڪال استعمال ڪندي لکيو write (۽ نه ٻيا سسٽم ڪالون - مثال طور، pwrite)، پرچم استعمال ڪريو --ioengine=sync.
آخرڪار، پرچم --fdatasync=1 ضمانت ڏئي ٿو ته هر ڪنهن جي پويان write هجي fdatasync.
اسان جي مثال ۾ ٻه ٻيا پيٽرولر: --size и --bs - استعمال جي مخصوص صورت جي لحاظ کان مختلف ٿي سگھي ٿو. ايندڙ سيڪشن بيان ڪندو ته انهن کي ڪيئن ترتيب ڏيو.

اسان ڇو چونڊيو fio ۽ اسان سکيو ته ان کي ڪيئن سيٽ ڪيو وڃي

هي نوٽ هڪ حقيقي ڪيس مان اچي ٿو جيڪو اسان سامهون آيو آهي. اسان وٽ ھڪڙو ڪلستر ھو Kubernetes v1.13 تي پروميٿيس جي نگراني سان. سولڊ اسٽيٽ ڊرائيو استعمال ڪيو ويو اسٽوريج جي طور تي etcd v3.2.24. etcd ميٽرڪس تمام گهڻي دير ڏيکاري ٿي fdatasync، جيتوڻيڪ جڏهن ڪلستر بيڪار هو. اسان ڏٺا اهي ميٽرڪ تمام قابل اعتراض آهن ۽ اسان کي پڪ ناهي ته انهن جي نمائندگي ڪهڙي آهي. ان کان علاوه، ڪلستر مجازي مشينن تي مشتمل آهي، تنهنڪري اهو ٻڌائڻ ناممڪن هو ته دير جي ورچوئلائيزيشن جي سبب هئي يا SSDs کي الزام ڏيڻو هو.

اضافي طور تي، اسان هارڊويئر ۽ سافٽ ويئر جي ترتيبن ۾ مختلف تبديلين کي ڏسي رهيا هئاسين، تنهنڪري اسان کي انهن جو جائزو وٺڻ لاء هڪ طريقي جي ضرورت آهي. يقينن، اهو ممڪن هوندو ته هر ترتيب ۾ etcd کي هلائڻ ۽ لاڳاپيل Prometheus ميٽرڪس کي ڏسو، پر ان لاءِ وڏي ڪوشش جي ضرورت پوندي. اسان کي ضرورت آھي ھڪڙي سادي طريقي جي ھڪڙي مخصوص تشڪيل کي جانچڻ لاءِ. اسان چاهيون ٿا ته اسان جي سمجھاڻي کي جانچڻ لاءِ پرومٿيس ميٽرڪس وغيره کان اچي رهيا آهيون.

هن کي ڪرڻ لاء، ٻه مسئلا حل ٿيڻ گهرجن:

پهريون، I/O لوڊ ڇا ٿو ٿئي جيڪا وغيره ٺاهي ٿي جڏهن WAL فائلن کي لکندي نظر اچي ٿي؟ ڇا سسٽم ڪالون استعمال ڪيا ويا آهن؟ لکڻ جي بلاڪ سائيز ڇا آهي؟
ٻيو، چئو ته اسان وٽ مٿين سوالن جا جواب آهن. انهي سان لاڳاپيل لوڊ ڪيئن ٻيهر پيدا ڪجي fio؟ سپني کان پوءِ fio - گھڻن پيٽرولن سان انتهائي لچڪدار افاديت (اها تصديق ڪرڻ آسان آهي، مثال طور، هتي - لڳ ڀڳ ترجمو.).

اسان ٻنهي مسئلن کي حل ڪيو ساڳئي حڪم تي ٻڌل طريقي سان استعمال ڪندي lsof и strace:

جي مدد سان lsof توھان ڏسي سگھوٿا سڀ فائل بيان ڪندڙ ھڪڙي پروسيس پاران استعمال ٿيل آھن، ۽ گڏوگڏ فائلون جيڪي اھي حوالا آھن.
جي مدد سان strace توهان اڳ ۾ ئي هلندڙ عمل جو تجزيو ڪري سگهو ٿا يا عمل کي هلائي سگهو ٿا ۽ ان جو مشاهدو ڪري سگهو ٿا. حڪم ڏيکاري ٿو سڀني سسٽم ڪالن کي هن پروسيس پاران ٺاهيو ويو آهي ۽، اختياري طور تي، ان جي اولاد. بعد ۾ انهن عملن لاءِ اهم آهي جيڪي فورڪ ڪري رهيا آهن، ۽ etcd اهڙن عملن مان هڪ آهي.

پهرين شيء جيڪا اسان استعمال ڪئي هئي strace ڪبرنيٽس ڪلستر ۾ etcd سرور جو مطالعو ڪرڻ لاءِ جڏهن اهو بيڪار هو.

اهڙيء طرح، اهو دريافت ڪيو ويو ته WAL ۾ لکڻ جا بلاڪ تمام گھڻا گروپ آهن، انهن مان اڪثريت 2200-2400 بائيٽ جي حد ۾ آهن. اهو ئي سبب آهي ته هن آرٽيڪل جي شروعات ۾ حڪم پرچم استعمال ڪري ٿو --bs=2300 (bs - سائيز ۾ هر رڪارڊنگ بلاڪ جي بائيٽ ۾ fio).

مهرباني ڪري نوٽ ڪريو ته etcd لکڻ جي بلاڪ جي سائيز مختلف ٿي سگھي ٿي نسخن جي لحاظ کان، ترتيب ڏيڻ، پيٽرولر ويلز، وغيره. - هي مدت کي متاثر ڪري ٿو fdatasync. جيڪڏھن توھان وٽ ھڪڙو ساڳيو استعمال ڪيس آھي، تجزيو ڪريو strace توهان جي وغيره جي عمل کي جديد قدر حاصل ڪرڻ لاء.

پوءِ، صاف ۽ جامع سمجھڻ لاءِ ته etcd فائل سسٽم سان ڪيئن ڪم ڪري ٿي، اسان ان کي ھيٺ کان ھليو. strace جھنڊن سان -ffttT. اهو ممڪن ٿيو ته ٻار جي عمل کي پڪڙڻ ۽ هر هڪ جي آئوٽ کي الڳ فائل ۾ لکڻ. ان کان سواء، تفصيلي ڄاڻ حاصل ڪئي وئي شروعاتي لمحن ۽ هر سسٽم ڪال جي مدت بابت.

اسان پڻ حڪم استعمال ڪيو lsofتوهان جي پيداوار جي سمجھ جي تصديق ڪرڻ لاء strace ڪهڙي مقصد لاءِ استعمال ڪيو ويو جنهن جي فائل وضاحت ڪندڙ. نتيجو اهو نڪتو strace، مٿي ڏنل هڪ جهڙو. هم وقت سازي جي وقت سان شمارياتي ڦيرڦار جي تصديق ڪئي وئي ته ميٽرڪ wal_fsync_duration_seconds etcd ميچز ڪالن مان fdatasync WAL فائل وضاحت ڪندڙ سان.

استعمال ڪندي پيدا ڪرڻ fio ڪم لوڊ وغيره جي لوڊ سان ملندڙ جلندڙ، يوٽيلٽي دستاويزن جو اڀياس ڪيو ويو ۽ اسان جي ڪم لاءِ مناسب پيرا ميٽر چونڊيا ويا. اسان پڪ ڪيو ته صحيح سسٽم ڪالون شامل هئا ۽ انهن جي مدت کي هلائڻ جي تصديق ڪئي fio کان strace (جيئن ڪيو ويو وغيره جي صورت ۾).

خاص ڌيان ڏنو ويو ته پيراگراف جي قيمت جو تعين ڪرڻ لاء --size. اهو نمائندگي ڪري ٿو ڪل I/O لوڊ فيو يوٽيليٽي طرفان ٺاهيل. اسان جي صورت ۾، هي ميڊيا ڏانهن لکيل بائيٽ جو ڪل تعداد آهي. اهو سڌو سنئون متناسب آهي ڪالن جو تعداد write (۽ fdatasync). هڪ خاص لاءِ bs ڪالن جو تعداد fdatasync برابر size / bs.

ڇاڪاڻ ته اسان فيصد ۾ دلچسپي وٺندا هئاسين، اسان پڪ ڪرڻ جي ڪوشش ڪئي ته نمونن جو تعداد شمارياتي اهميت لاء ڪافي آهي. ۽ انهن اهو فيصلو ڪيو 10^4 (جيڪو 22 MB جي سائيز سان ملندو) ڪافي ٿيندو. ننڍا پيٽرول قدر --size وڌيڪ واضح شور پيدا ڪيو (مثال طور، ڪالون fdatasync، جيڪو معمول کان گهڻو وقت وٺندو آهي ۽ 99 سيڪڙو تي اثر انداز ٿئي ٿو).

اهو توهان تي آهي

آرٽيڪل ڏيکاري ٿو ته ڪيئن استعمال ڪجي fio توھان اندازو ڪري سگھو ٿا ته ڇا ميڊيا جو ارادو ڪيو ويو آھي وغيره سان استعمال ڪرڻ لاءِ ڪافي تيز آھي. هاڻي اهو توهان تي آهي! توھان ڳولي سگھوٿا ورچوئل مشينون SSD-based اسٽوريج سان خدمت ۾ آئي بي ايم کلاڊ.

پي ايس مترجم کان

استعمال جي تيار ڪيل مثالن سان fio ٻين مسئلن کي حل ڪرڻ لاءِ دستاويز يا سڌو سنئون ڏانهن پروجيڪٽ repositories (انهن مان گھڻا ئي آھن جن کان وڌيڪ دستاويز ۾ ذڪر ڪيو ويو آھي).

مترجم کان PPS

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

وغيره لاءِ ڪافي ڪارڪردگي لاءِ فيو سان ڊسڪ کي ڪيئن چيڪ ڪجي