🥇 etcd کے لیے کافی کارکردگی کے لیے fio کے ساتھ ڈسک کو کیسے چیک کریں

نوٹ. ترجمہ: یہ مضمون ایک چھوٹی تحقیق کے نتائج ہیں جو IBM کلاؤڈ انجینئرز کی طرف سے etcd ڈیٹا بیس کے آپریشن سے متعلق ایک حقیقی مسئلے کے حل کی تلاش میں کی گئی تھی۔ اسی طرح کا ایک کام ہمارے لئے متعلقہ تھا، لیکن مصنفین کے خیالات اور اعمال کا کورس وسیع تر تناظر میں دلچسپ ہو سکتا ہے۔

پورے مضمون کا مختصر خلاصہ: fio اور etcd

ایک etcd کلسٹر کی کارکردگی بنیادی اسٹوریج کی رفتار پر بہت زیادہ منحصر ہے۔ کارکردگی کی نگرانی کے لیے، etcd مختلف Prometheus میٹرکس برآمد کرتا ہے۔ ان میں سے ایک ہے۔ wal_fsync_duration_seconds. etcd دستاویزات میں اس کا کہنا ہےاگر اس میٹرک کا 99 واں پرسنٹائل 10 ms سے زیادہ نہ ہو تو اس اسٹوریج کو کافی تیزی سے سمجھا جا سکتا ہے...

اگر آپ لینکس مشینوں پر ایک etcd کلسٹر ترتیب دینے پر غور کر رہے ہیں اور یہ جانچنا چاہتے ہیں کہ آیا سٹوریج ڈرائیوز (جیسے SSDs) کافی تیز ہیں، تو ہم ایک مشہور I/O ٹیسٹر استعمال کرنے کی تجویز کرتے ہیں۔ فیو. بس درج ذیل کمانڈ کو چلائیں (directory test-data ٹیسٹ کی جا رہی ڈرائیو کے ماونٹڈ پارٹیشن میں واقع ہونا چاہیے):

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

باقی صرف آؤٹ پٹ کو دیکھنا اور چیک کرنا ہے کہ آیا یہ 99ویں پرسنٹائل پر فٹ بیٹھتا ہے۔ fdatasync 10 ایم ایس پر اگر ایسا ہے، تو آپ کی ڈرائیو کافی تیز ہے۔ یہاں ایک مثال آؤٹ پٹ ہے:

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 پر عمل کرنے سے پہلے لکھتا ہے۔ اگر کوئی نوڈ کریش ہو جاتا ہے اور سنیپ شاٹس کے درمیان دوبارہ شروع ہو جاتا ہے، تو 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 مختلف طریقوں سے ہو سکتا ہے: مطابقت پذیری/async، سسٹم کالز کی بہت سی مختلف کلاسیں، وغیرہ۔ سکے کا دوسرا رخ یہ ہے۔ fio استعمال کرنے کے لئے انتہائی مشکل. افادیت کے بہت سے پیرامیٹرز ہیں، اور ان کی قدروں کے مختلف امتزاج بالکل مختلف نتائج کا باعث بنتے ہیں۔ etcd کے لیے معقول تخمینہ حاصل کرنے کے لیے، آپ کو یہ یقینی بنانا چاہیے کہ fio کے ذریعے تیار کردہ تحریری بوجھ WAL فائلوں پر etcd کے لکھنے کے بوجھ سے جتنا ممکن ہو سکے:

اس کا مطلب یہ ہے کہ پیدا ہوا fio کام کا بوجھ کم از کم ایک فائل میں ترتیب وار تحریروں کا ایک سلسلہ ہونا چاہیے، جہاں ہر تحریری عمل سسٹم کال پر مشتمل ہوتا ہے۔ writeاس کے بعد fdatasync.
ترتیب وار ریکارڈنگ کو فعال کرنے کے لیے، آپ کو پرچم کی وضاحت کرنی ہوگی۔ --rw=write.
کہ fio کالز کا استعمال کرتے ہوئے لکھا write (اور دوسرے سسٹم کالز نہیں - مثال کے طور پر، pwrite)، جھنڈا استعمال کریں۔ --ioengine=sync.
آخر میں، پرچم --fdatasync=1 اس بات کی ضمانت دیتا ہے کہ ہر ایک کے پیچھے write ہونا ضروری ہے fdatasync.
ہماری مثال میں دو دیگر پیرامیٹرز: --size и --bs - استعمال کے مخصوص کیس کے لحاظ سے مختلف ہو سکتے ہیں۔ اگلا حصہ ان کو ترتیب دینے کا طریقہ بتائے گا۔

ہم نے fio کا انتخاب کیوں کیا اور اسے ترتیب دینے کا طریقہ سیکھا۔

یہ نوٹ ایک حقیقی کیس سے آیا ہے جس کا ہم نے سامنا کیا۔ ہمارے پاس Prometheus پر نگرانی کے ساتھ Kubernetes v1.13 پر ایک کلسٹر تھا۔ سالڈ اسٹیٹ ڈرائیوز کو etcd v3.2.24 کے لیے اسٹوریج کے طور پر استعمال کیا گیا تھا۔ etcd میٹرکس نے بہت زیادہ تاخیر دکھائی fdatasyncیہاں تک کہ جب کلسٹر بیکار تھا۔ ہمیں یہ میٹرکس بہت قابل اعتراض معلوم ہوا اور ہمیں یقین نہیں تھا کہ وہ بالکل کس چیز کی نمائندگی کرتے ہیں۔ اس کے علاوہ، کلسٹر ورچوئل مشینوں پر مشتمل تھا، اس لیے یہ بتانا ناممکن تھا کہ آیا تاخیر ورچوئلائزیشن کی وجہ سے ہوئی یا SSDs کو قصوروار ٹھہرایا گیا۔

مزید برآں، ہم ہارڈ ویئر اور سافٹ ویئر کنفیگریشنز میں مختلف تبدیلیوں کو دیکھ رہے تھے، اس لیے ہمیں ان کا جائزہ لینے کے لیے ایک طریقہ درکار تھا۔ بلاشبہ، ہر ترتیب میں etcd کو چلانا اور متعلقہ Prometheus میٹرکس کو دیکھنا ممکن ہوگا، لیکن اس کے لیے اہم کوشش کی ضرورت ہوگی۔ ہمیں ایک مخصوص ترتیب کا اندازہ کرنے کے لیے ایک آسان طریقہ کی ضرورت تھی۔ ہم etcd سے آنے والے Prometheus میٹرکس کے بارے میں اپنی سمجھ کی جانچ کرنا چاہتے تھے۔

ایسا کرنے کے لئے، دو مسائل کو حل کرنا پڑا:

سب سے پہلے، WAL فائلوں کو لکھتے وقت etcd پیدا ہونے والا I/O لوڈ کیا ہوتا ہے؟ کون سی سسٹم کالز استعمال ہوتی ہیں؟ رائٹ بلاک کا سائز کیا ہے؟
دوم، ہم کہتے ہیں کہ ہمارے پاس مندرجہ بالا سوالات کے جوابات ہیں۔ اس کے ساتھ متعلقہ بوجھ کو دوبارہ کیسے تیار کیا جائے۔ fio? سب کے بعد fio - بہت سارے پیرامیٹرز کے ساتھ انتہائی لچکدار افادیت (اس کی تصدیق کرنا آسان ہے، مثال کے طور پر، یہاں - تقریبا. ترجمہ).

ہم نے ایک ہی کمانڈ پر مبنی نقطہ نظر کا استعمال کرتے ہوئے دونوں مسائل کو حل کیا۔ lsof и strace:

کے ساتھ lsof آپ کسی عمل کے ذریعے استعمال ہونے والے تمام فائل ڈسکرپٹرز کے ساتھ ساتھ ان فائلوں کو بھی دیکھ سکتے ہیں جن کا وہ حوالہ دیتے ہیں۔
کے ساتھ strace آپ پہلے سے چل رہے عمل کا تجزیہ کر سکتے ہیں یا کسی عمل کو چلا سکتے ہیں اور اس کا مشاہدہ کر سکتے ہیں۔ کمانڈ اس عمل کے ذریعے کی گئی تمام سسٹم کالز اور اختیاری طور پر اس کی اولاد کو دکھاتی ہے۔ مؤخر الذکر ان عملوں کے لئے اہم ہے جو فورک کر رہے ہیں، اور etcd ایسے ہی عملوں میں سے ایک ہے۔

پہلی چیز جو ہم نے کی تھی وہ استعمال تھی۔ strace Kubernetes کلسٹر میں etcd سرور کا مطالعہ کرنے کے لیے جب یہ بیکار تھا۔

اس طرح، یہ پتہ چلا کہ WAL میں لکھنے والے بلاکس بہت گھنے گروپ میں ہیں، ان میں سے زیادہ تر 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 ایم بی کے سائز کے مساوی ہے) کافی ہوگا۔ پیرامیٹر کی چھوٹی قدریں۔ --size زیادہ واضح شور پیدا کیا (مثال کے طور پر، کالز fdatasync، جو معمول سے بہت زیادہ وقت لیتا ہے اور 99 فیصد کو متاثر کرتا ہے)۔

یہ آپ پر منحصر ہے

مضمون بتاتا ہے کہ کس طرح استعمال کرنا ہے۔ fio آپ اندازہ کر سکتے ہیں کہ میڈیا جو etcd کے ساتھ استعمال کرنا ہے وہ کافی تیز ہے۔ اب یہ آپ پر منحصر ہے! آپ سروس میں SSD پر مبنی سٹوریج کے ساتھ ورچوئل مشینیں دریافت کر سکتے ہیں۔ آئی بی ایم کلاؤڈ.

مترجم سے PS

استعمال کی تیار شدہ مثالوں کے ساتھ fio دیگر مسائل کو حل کرنے کے لئے میں پایا جا سکتا ہے دستاویزات یا براہ راست پروجیکٹ کے ذخیرے (دستاویزات میں مذکور کے مقابلے میں ان میں سے بہت زیادہ ہیں)۔

مترجم سے پی پی ایس

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

etcd کے لیے کافی کارکردگی کے لیے fio کے ساتھ ڈسک کو کیسے چیک کریں۔