وغیرہ کے لیے سٹوریج کی رفتار موزوں ہے؟ آئیے fio سے پوچھیں۔

fio اور etcd کے بارے میں ایک مختصر کہانی

کلسٹر کی کارکردگی وغیرہ زیادہ تر اس کے اسٹوریج کی کارکردگی پر منحصر ہے۔ etcd کچھ میٹرکس کو برآمد کرتا ہے۔ Prometheusمطلوبہ اسٹوریج کی کارکردگی کی معلومات فراہم کرنے کے لیے۔ مثال کے طور پر، wal_fsync_duration_seconds میٹرک۔ etcd کے لیے دستاویزات کہتی ہیں۔: ذخیرہ کرنے کے لیے کافی تیزی سے سمجھا جائے، اس میٹرک کا 99واں پرسنٹائل 10ms سے کم ہونا چاہیے۔ اگر آپ لینکس مشینوں پر ایک etcd کلسٹر چلانے کا سوچ رہے ہیں اور اس بات کا جائزہ لینا چاہتے ہیں کہ آیا آپ کا اسٹوریج کافی تیز ہے (جیسے SSD)، تو آپ استعمال کر سکتے ہیں۔ فیو I/O آپریشنز کی جانچ کے لیے ایک مقبول ٹول ہے۔ مندرجہ ذیل کمانڈ کو چلائیں، جہاں test-data سٹوریج ماؤنٹ پوائنٹ کے تحت ڈائریکٹری ہے:

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

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

  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 آپریشن کو 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 آپشن کی ضرورت ہوتی ہے۔ fio لکھتے وقت رائٹ سسٹم کال استعمال کرنے کے لیے، بجائے لکھناآپ کو --ioengine=sync پیرامیٹر کی وضاحت کرنی چاہیے۔ آخر میں، ہر تحریر کے بعد fdatasync کو کال کرنے کے لیے، آپ کو --fdatasync=1 پیرامیٹر شامل کرنا ہوگا۔ اس مثال میں دیگر دو اختیارات (-size اور -bs) اسکرپٹ کے لیے مخصوص ہیں۔ اگلے حصے میں، ہم آپ کو دکھائیں گے کہ انہیں کیسے ترتیب دیا جائے۔

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

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

لیکن اس کے لیے دو مسائل کو حل کرنا تھا۔ سب سے پہلے، WAL کو لکھتے وقت etcd جو I/O لوڈ بناتا ہے کیسا لگتا ہے؟ کون سی سسٹم کالز استعمال ہوتی ہیں؟ ریکارڈز کا سائز کیا ہے؟ دوسرا، اگر ہم ان سوالوں کے جواب دیتے ہیں، تو ہم fio کے ساتھ ملتے جلتے کام کے بوجھ کو کیسے دوبارہ پیش کرتے ہیں؟ مت بھولنا کہ fio بہت سے اختیارات کے ساتھ ایک بہت لچکدار ٹول ہے۔ ہم نے دونوں مسائل کو ایک نقطہ نظر سے حل کیا - کمانڈز کا استعمال کرتے ہوئے lsof и سٹرس. lsof تمام فائل ڈسکرپٹرز کی فہرست بناتا ہے جو عمل کے ذریعہ استعمال ہوتے ہیں اور ان سے وابستہ فائلوں کو۔ اور اسٹریس کے ساتھ، آپ پہلے سے چل رہے عمل کی جانچ کر سکتے ہیں، یا کوئی عمل شروع کر کے اس کی جانچ کر سکتے ہیں۔ strace جانچے جانے والے عمل (اور اس کے چائلڈ پروسیس) سے تمام سسٹم کالز کو پرنٹ کرتا ہے۔ مؤخر الذکر بہت اہم ہے، کیونکہ etcd صرف اسی طرح کا طریقہ اختیار کر رہا ہے۔

ہم نے سب سے پہلے اسٹریس کو کبرنیٹس کے لیے etcd سرور کو دریافت کرنے کے لیے استعمال کیا جب کلسٹر پر کوئی بوجھ نہیں تھا۔ ہم نے دیکھا کہ تقریباً تمام WAL ریکارڈ ایک ہی سائز کے تھے: 2200–2400 بائٹس۔ اس لیے، پوسٹ کے شروع میں کمانڈ میں، ہم نے پیرامیٹر -bs=2300 (bs کا مطلب ہے ہر fio اندراج کے لیے بائٹس میں سائز)۔ نوٹ کریں کہ etcd اندراج کا سائز etcd ورژن، تقسیم، پیرامیٹر کی قدروں وغیرہ پر منحصر ہے، اور fdatasync کی مدت کو متاثر کرتا ہے۔ اگر آپ کے پاس بھی ایسا ہی منظر ہے تو، درست نمبر معلوم کرنے کے لیے اپنے etcd کے عمل کو اسٹریس کے ساتھ چیک کریں۔

پھر، ای سی ڈی فائل سسٹم کیا کر رہا ہے اس کا اچھا اندازہ حاصل کرنے کے لیے، ہم نے اسے سٹریس اور -ffttT آپشنز سے شروع کیا۔ لہذا ہم نے بچوں کے عمل کو جانچنے اور ان میں سے ہر ایک کے آؤٹ پٹ کو الگ فائل میں ریکارڈ کرنے کی کوشش کی، اور ہر سسٹم کال کے آغاز اور مدت کے بارے میں تفصیلی رپورٹس بھی حاصل کیں۔ ہم نے اسٹریس آؤٹ پٹ کے اپنے تجزیہ کی تصدیق کے لیے lsof کا استعمال کیا اور یہ دیکھنے کے لیے کہ کون سا فائل ڈسکرپٹر کس مقصد کے لیے استعمال کیا جا رہا ہے۔ چنانچہ اسٹریس کی مدد سے اوپر دکھائے گئے نتائج حاصل کیے گئے۔ مطابقت پذیری کے وقت کے اعدادوشمار نے تصدیق کی ہے کہ etcd سے wal_fsync_duration_seconds WAL فائل ڈسکرپٹرز کے ساتھ fdatasync کالز کے ساتھ مطابقت رکھتا ہے۔

ہم نے fio کے لیے دستاویزات کا جائزہ لیا اور اپنی اسکرپٹ کے لیے آپشنز کا انتخاب کیا تاکہ fio وغیرہ وغیرہ کی طرح کا بوجھ پیدا کرے۔ ہم نے سٹریس سے fio چلا کر سسٹم کالز اور ان کا دورانیہ بھی چیک کیا۔

ہم نے fio سے پورے I/O بوجھ کی نمائندگی کرنے کے لیے --size پیرامیٹر کی قدر کو احتیاط سے منتخب کیا ہے۔ ہمارے معاملے میں، یہ اسٹوریج پر لکھے گئے بائٹس کی کل تعداد ہے۔ یہ رائٹ (اور fdatasync) سسٹم کالز کی تعداد کے براہ راست متناسب نکلا۔ bs کی ایک خاص قدر کے لیے، fdatasync کالز کی تعداد = سائز/bs۔ چونکہ ہم پرسنٹائل میں دلچسپی رکھتے تھے، اس لیے ہمارے پاس اس بات کا یقین کرنے کے لیے کافی نمونے ہونے تھے، اور ہم نے حساب لگایا کہ 10^4 ہمارے لیے کافی ہوگا (یعنی 22 میبی بائٹس ہے)۔ اگر --size چھوٹا ہے تو، آؤٹ لیرز ہو سکتے ہیں (مثال کے طور پر، متعدد fdatasync کالز میں معمول سے زیادہ وقت لگتا ہے اور 99ویں پرسنٹائل کو متاثر کرتے ہیں)۔

خود کریں

ہم نے آپ کو دکھایا کہ fio کا استعمال کیسے کریں اور دیکھیں کہ آیا سٹوریج اتنی تیز ہے کہ etcd اچھی کارکردگی کا مظاہرہ کر سکے۔ اب آپ اسے خود استعمال کر کے آزما سکتے ہیں، مثال کے طور پر، SSD اسٹوریج والی ورچوئل مشینیں آئی بی ایم کلاؤڈ.

ماخذ: www.habr.com