نوٹ. ترجمہ: اگست کے اوائل میں، Red Hat نے عوامی طور پر قابل رسائی مسائل کو حل کرنے کے بارے میں بات کی جو اس کی سروس کے صارفین کو پچھلے مہینوں میں درپیش تھے۔ (یہ کنٹینر امیجز کی رجسٹری پر مبنی ہے، جو کمپنی کو CoreOS کی خریداری کے ساتھ موصول ہوئی ہے)۔ اس سروس میں آپ کی دلچسپی سے قطع نظر، کمپنی کے SRE انجینئرز نے حادثے کی وجوہات کی تشخیص اور اسے ختم کرنے کے لیے جو راستہ اختیار کیا وہ سبق آموز ہے۔
19 مئی کو، صبح سویرے (ایسٹرن ڈے لائٹ ٹائم، EDT)، quay.io سروس کریش ہو گئی۔ حادثے نے quay.io صارفین اور اوپن سورس پروجیکٹس دونوں کو متاثر کیا جو quay.io کو سافٹ ویئر بنانے اور تقسیم کرنے کے پلیٹ فارم کے طور پر استعمال کرتے ہیں۔ ریڈ ہیٹ دونوں کے اعتماد کو اہمیت دیتا ہے۔
SRE انجینئرز کی ایک ٹیم فوری طور پر شامل ہو گئی اور جلد از جلد Quay سروس کو مستحکم کرنے کی کوشش کی۔ تاہم، جب وہ یہ کر رہے تھے، کلائنٹس نے نئی تصاویر کو آگے بڑھانے کی صلاحیت کھو دی، اور صرف کبھی کبھار وہ موجودہ تصاویر کو کھینچنے کے قابل تھے۔ کسی نامعلوم وجہ سے، quay.io ڈیٹا بیس کو سروس کو پوری صلاحیت تک بڑھانے کے بعد بلاک کر دیا گیا تھا۔
«کیا بدل گیا ہے؟"- یہ پہلا سوال ہے جو عام طور پر ایسے معاملات میں پوچھا جاتا ہے۔ ہم نے دیکھا کہ ایشو سے کچھ دیر پہلے، OpenShift Dedicated کلسٹر (جو quay.io چلاتا ہے) نے ورژن 4.3.19 میں اپ ڈیٹ ہونا شروع کیا۔ چونکہ quay.io Red Hat OpenShift Dedicated (OSD) پر چلتا ہے، اس لیے باقاعدہ اپ ڈیٹس معمول کے مطابق ہوتی تھیں اور کبھی بھی مسائل پیدا نہیں ہوتے تھے۔ مزید برآں، پچھلے چھ مہینوں کے دوران، ہم نے سروس میں کسی رکاوٹ کے بغیر کئی بار Quay کلسٹرز کو اپ گریڈ کیا ہے۔
جب ہم سروس کو بحال کرنے کی کوشش کر رہے تھے، دوسرے انجینئرز نے سافٹ ویئر کے پچھلے ورژن کے ساتھ ایک نیا OSD کلسٹر تیار کرنا شروع کر دیا، تاکہ اگر کچھ ہو جائے تو وہ اس پر سب کچھ تعینات کر سکیں۔
جڑ کا تجزیہ
ناکامی کی بنیادی علامت دسیوں ہزار ڈیٹا بیس کنکشنز کا برفانی تودہ تھا، جس نے MySQL مثال کو مؤثر طریقے سے ناقابل استعمال بنا دیا۔ اس سے مسئلہ کی تشخیص کرنا مشکل ہو گیا۔ SRE ٹیم کو مسئلے کا جائزہ لینے میں مدد کرنے کے لیے ہم نے کلائنٹس کے کنکشنز کی زیادہ سے زیادہ تعداد پر ایک حد مقرر کی ہے۔ ہمیں ڈیٹا بیس پر کوئی غیر معمولی ٹریفک نظر نہیں آئی: درحقیقت، زیادہ تر درخواستیں پڑھی گئیں، اور صرف چند ہی لکھی گئیں۔
ہم نے ڈیٹا بیس ٹریفک میں ایک پیٹرن کی نشاندہی کرنے کی بھی کوشش کی جو اس برفانی تودے کا سبب بن سکتا ہے۔ تاہم، ہمیں نوشتہ جات میں کوئی نمونہ نہیں مل سکا۔ OSD 4.3.18 کے ساتھ نئے کلسٹر کے تیار ہونے کا انتظار کرتے ہوئے، ہم نے quay.io pods کو لانچ کرنے کی کوشش جاری رکھی۔ جب بھی کلسٹر مکمل صلاحیت تک پہنچ جاتا ہے، ڈیٹا بیس منجمد ہو جاتا ہے۔ اس کا مطلب یہ تھا کہ تمام quay.io pods کے علاوہ RDS مثال کو دوبارہ شروع کرنا ضروری تھا۔
شام تک، ہم نے سروس کو صرف پڑھنے کے موڈ میں مستحکم کر دیا اور ڈیٹا بیس پر بوجھ کو کم کرنے کے لیے زیادہ سے زیادہ غیر ضروری فنکشنز (مثال کے طور پر نام کی جگہ کوڑا کرکٹ جمع کرنے) کو غیر فعال کر دیا۔ جمنا بند ہو گیا ہے۔ لیکن وجہ کبھی نہیں مل سکی. نیا OSD کلسٹر تیار تھا، اور ہم نے سروس کو منتقل کیا، ٹریفک کو منسلک کیا اور مسلسل نگرانی کی۔
Quay.io نے نئے OSD کلسٹر پر مستحکم طور پر کام کیا، اس لیے ہم ڈیٹابیس لاگز پر واپس چلے گئے، لیکن ایسا کوئی تعلق نہیں مل سکا جو رکاوٹوں کی وضاحت کرے۔ OpenShift انجینئرز نے یہ سمجھنے کے لیے ہمارے ساتھ کام کیا کہ آیا Red Hat OpenShift 4.3.19 میں تبدیلیاں Quay کے ساتھ مسائل پیدا کر سکتی ہیں۔ تاہم، کچھ نہیں ملا، اور لیبارٹری کے حالات میں مسئلہ کو دوبارہ پیدا کرنا ممکن نہیں تھا۔.
دوسری ناکامی۔
28 مئی کو، دوپہر EDT سے کچھ دیر پہلے، quay.io اسی علامت کے ساتھ دوبارہ کریش ہو گیا: ڈیٹا بیس کو بلاک کر دیا گیا تھا۔ اور ایک بار پھر ہم نے اپنی تمام کوششیں تحقیقات میں جھونک دیں۔ سب سے پہلے، سروس کو بحال کرنا ضروری تھا. البتہ اس بار RDS کو دوبارہ شروع کرنے اور quay.io pods کو دوبارہ شروع کرنے سے کچھ نہیں ہوا۔: کنکشن کے ایک اور برفانی تودے نے بیس کو زیر کر لیا ہے۔ لیکن کیوں؟
Quay Python میں لکھا گیا ہے اور ہر پوڈ ایک سنگل کنٹینر کے طور پر کام کرتا ہے۔ کنٹینر رن ٹائم بہت سے متوازی کام بیک وقت چلاتا ہے۔ ہم لائبریری کا استعمال کرتے ہیں۔ gevent نیچے gunicorn ویب درخواستوں پر کارروائی کرنے کے لیے۔ جب کوئی درخواست Quay میں آتی ہے (ہمارے اپنے API کے ذریعے، یا Docker's API کے ذریعے)، اسے ایک جیونٹ ورکر تفویض کیا جاتا ہے۔ عام طور پر اس کارکن کو ڈیٹا بیس سے رابطہ کرنا چاہیے۔ پہلی ناکامی کے بعد، ہم نے دریافت کیا کہ جیونٹ ورکرز ڈیفالٹ سیٹنگز کا استعمال کرتے ہوئے ڈیٹا بیس سے منسلک ہو رہے تھے۔
Quay pods کی نمایاں تعداد اور فی سیکنڈ آنے والی ہزاروں درخواستوں کے پیش نظر، ڈیٹا بیس کنکشنز کی ایک بڑی تعداد نظریاتی طور پر MySQL مثال کو زیر کر سکتی ہے۔ نگرانی کی بدولت یہ معلوم ہوا کہ Quay فی سیکنڈ اوسطاً 5 ہزار درخواستوں پر کارروائی کرتا ہے۔ ڈیٹا بیس سے کنکشن کی تعداد تقریباً ایک جیسی تھی۔ 5 ہزار کنکشن ہمارے RDS مثال کی صلاحیتوں کے اندر تھے (جس کے بارے میں دسیوں ہزار نہیں کہا جا سکتا)۔ کسی وجہ سے کنکشن کی تعداد میں غیر متوقع طور پر اضافہ ہوا۔تاہم، ہم نے آنے والی درخواستوں کے ساتھ کوئی تعلق محسوس نہیں کیا۔
اس بار ہم نے مسئلہ کے ماخذ کو تلاش کرنے اور اسے ختم کرنے کا عزم کیا، اور خود کو دوبارہ شروع کرنے تک محدود نہیں رکھا۔ Quay codebase پر تبدیلیاں ہر کارکن کے لیے ڈیٹا بیس سے کنکشن کی تعداد کو محدود کرنے کے لیے کی گئی تھیں۔ gevent یہ نمبر کنفیگریشن میں ایک پیرامیٹر بن گیا: نئی کنٹینر امیج بنائے بغیر اسے فلائی پر تبدیل کرنا ممکن ہو گیا۔ یہ معلوم کرنے کے لیے کہ کتنے کنکشنز کو حقیقت پسندانہ طور پر ہینڈل کیا جا سکتا ہے، ہم نے اسٹیجنگ ماحول میں کئی ٹیسٹ چلائے، مختلف قدریں سیٹ کیں تاکہ یہ دیکھا جا سکے کہ یہ لوڈ ٹیسٹنگ کے منظرناموں کو کیسے متاثر کرے گا۔ نتیجے کے طور پر، یہ پتہ چلا کہ جب کنکشنز کی تعداد 502 ہزار سے تجاوز کر جاتی ہے تو Quay 10 غلطیاں پھینکنا شروع کر دیتا ہے۔
ہم نے فوری طور پر اس نئے ورژن کو پروڈکشن میں تعینات کر دیا اور ڈیٹا بیس کنکشن کے شیڈول کی نگرانی شروع کر دی۔ ماضی میں، بیس منٹ کے بعد بند کر دیا گیا تھا. 20 پریشانیوں سے پاک منٹ کے بعد ہمیں امید تھی، اور ایک گھنٹے بعد ہمیں اعتماد ملا۔ ہم نے سائٹ پر ٹریفک کو بحال کیا اور پوسٹ مارٹم کا تجزیہ شروع کیا۔
مسدود ہونے کی وجہ سے اس مسئلے کو نظرانداز کرنے میں کامیاب ہونے کے بعد، ہمیں اس کی اصل وجوہات کا پتہ نہیں چل سکا. اس بات کی تصدیق کی گئی کہ یہ OpenShift 4.3.19 میں کسی تبدیلی سے متعلق نہیں ہے، کیونکہ ورژن 4.3.18 پر بھی ایسا ہی ہوا تھا، جو پہلے Quay کے ساتھ بغیر کسی پریشانی کے کام کرتا تھا۔
کلسٹر میں واضح طور پر کچھ اور چھپا ہوا تھا۔
تفصیلی مطالعہ
Quay.io نے بغیر کسی پریشانی کے چھ سال تک ڈیٹا بیس سے منسلک ہونے کے لیے پہلے سے طے شدہ ترتیبات کا استعمال کیا۔ کیا بدلا؟ یہ واضح ہے کہ اس تمام عرصے میں quay.io پر ٹریفک مسلسل بڑھ رہی ہے۔ ہمارے معاملے میں، ایسا لگتا تھا جیسے کچھ حد تک پہنچ گئی ہو، جس نے کنکشن کے برفانی تودے کے لیے ایک محرک کا کام کیا۔ ہم نے دوسری ناکامی کے بعد ڈیٹا بیس لاگز کا مطالعہ جاری رکھا، لیکن ہمیں کوئی نمونہ یا واضح تعلق نہیں ملا۔
اس دوران، SRE ٹیم Quay کی درخواست کے مشاہدے اور مجموعی سروس کی صحت میں بہتری پر کام کر رہی ہے۔ نئے میٹرکس اور ڈیش بورڈز تعینات کیے گئے ہیں۔, یہ ظاہر کرتا ہے کہ Quay کے کن حصوں کی صارفین کی طرف سے سب سے زیادہ مانگ ہے۔
Quay.io نے 9 جون تک ٹھیک کام کیا۔ آج صبح (EDT) ہم نے دوبارہ ڈیٹا بیس کنکشن کی تعداد میں نمایاں اضافہ دیکھا۔ اس بار کوئی ڈاون ٹائم نہیں تھا۔، چونکہ نئے پیرامیٹر نے ان کی تعداد کو محدود کر دیا ہے اور انہیں MySQL تھرو پٹ سے تجاوز کرنے کی اجازت نہیں دی ہے۔ تاہم، تقریباً آدھے گھنٹے تک، بہت سے صارفین نے quay.io کی سست کارکردگی کو نوٹ کیا۔ ہم نے اضافی مانیٹرنگ ٹولز کا استعمال کرتے ہوئے تیزی سے تمام ممکنہ ڈیٹا اکٹھا کیا۔ اچانک ایک نمونہ ابھرا۔
رابطوں میں اضافے سے عین پہلے، ایپ رجسٹری API کو بڑی تعداد میں درخواستیں کی گئیں۔. ایپ رجسٹری quay.io کی ایک غیر معروف خصوصیت ہے۔ یہ آپ کو ہیلم چارٹس اور امیر میٹا ڈیٹا کے ساتھ کنٹینرز جیسی چیزوں کو ذخیرہ کرنے کی اجازت دیتا ہے۔ زیادہ تر quay.io صارفین اس خصوصیت کے ساتھ کام نہیں کرتے ہیں، لیکن Red Hat OpenShift اسے فعال طور پر استعمال کرتے ہیں۔ OpenShift کے حصے کے طور پر OperatorHub تمام آپریٹرز کو ایپ رجسٹری میں اسٹور کرتا ہے۔ یہ آپریٹرز OpenShift ورک لوڈ ایکو سسٹم اور پارٹنر سنٹرک آپریٹنگ ماڈل (دن 2 آپریشنز) کی بنیاد بناتے ہیں۔
ہر OpenShift 4 کلسٹر انسٹالیشن کے لیے دستیاب آپریٹرز کا کیٹلاگ شائع کرنے اور پہلے سے انسٹال ہونے والوں کو اپ ڈیٹ فراہم کرنے کے لیے بلٹ ان OperatorHub کے آپریٹرز کا استعمال کرتا ہے۔ OpenShift 4 کی بڑھتی ہوئی مقبولیت کے ساتھ، دنیا بھر میں اس پر کلسٹرز کی تعداد میں بھی اضافہ ہوا ہے۔ ان کلسٹرز میں سے ہر ایک آپریٹر کے مواد کو بلٹ ان OperatorHub چلانے کے لیے ڈاؤن لوڈ کرتا ہے، quay.io کے اندر ایپ رجسٹری کو بیک اینڈ کے طور پر استعمال کرتا ہے۔ مسئلہ کے ماخذ کی تلاش میں، ہم نے اس حقیقت کو کھو دیا کہ جیسے جیسے OpenShift کی مقبولیت میں بتدریج اضافہ ہوتا گیا، quay.io کے شاذ و نادر ہی استعمال ہونے والے فنکشنز میں سے ایک پر بوجھ بھی بڑھتا گیا۔.
ہم نے ایپ رجسٹری کی درخواست کے ٹریفک کا کچھ تجزیہ کیا اور رجسٹری کوڈ پر ایک نظر ڈالی۔ فوری طور پر، کوتاہیوں کا انکشاف ہوا، جس کی وجہ سے ڈیٹا بیس سے متعلق سوالات بہتر طریقے سے نہیں بنائے گئے۔ جب لوڈ کم ہوا تو انہیں کوئی پریشانی نہیں ہوئی لیکن جب لوڈ بڑھ گیا تو مسائل کا باعث بن گئے۔ ایپ رجسٹری میں دو پریشانی والے اختتامی نکات نکلے جنہوں نے بڑھتے ہوئے بوجھ کا اچھا جواب نہیں دیا: پہلے نے ریپوزٹری میں موجود تمام پیکجوں کی فہرست فراہم کی، دوسرے نے پیکیج کے لیے تمام بلاب واپس کر دیے۔
اسباب کا خاتمہ
اگلے ہفتے ہم نے ایپ رجسٹری کے کوڈ اور اس کے ماحول کو بہتر بنانے میں گزارا۔ واضح طور پر غیر موثر SQL سوالات پر دوبارہ کام کیا گیا اور غیر ضروری کمانڈ کالز کو ختم کر دیا گیا۔ tar (یہ ہر بار چلایا جاتا تھا جب بلاب بازیافت کیے جاتے تھے)، جہاں بھی ممکن ہو کیشنگ شامل کی جاتی تھی۔ اس کے بعد ہم نے کارکردگی کی وسیع جانچ کی اور تبدیلیوں سے پہلے اور بعد میں ایپ رجسٹری کی رفتار کا موازنہ کیا۔
API کی درخواستیں جو پہلے آدھے منٹ تک لیتی تھیں اب ملی سیکنڈ میں مکمل ہو جاتی ہیں۔. اگلے ہفتے ہم نے پیداوار میں تبدیلیاں کیں، اور تب سے quay.io مستحکم طریقے سے کام کر رہا ہے۔ اس وقت کے دوران، ایپ رجسٹری کے اختتامی نقطہ پر ٹریفک میں کئی تیزی سے اضافہ ہوا، لیکن بہتری نے ڈیٹا بیس کی بندش کو روک دیا۔
ہم نے کیا سیکھا ہے؟
یہ واضح ہے کہ کوئی بھی سروس ڈاؤن ٹائم سے بچنے کی کوشش کرتی ہے۔ ہمارے معاملے میں، ہمیں یقین ہے کہ حالیہ بندش نے quay.io کو بہتر بنانے میں مدد کی ہے۔ ہم نے چند اہم اسباق سیکھے ہیں جنہیں ہم شیئر کرنا چاہیں گے:
- آپ کی سروس کون استعمال کرتا ہے اور کیسے اس بارے میں ڈیٹا کبھی بھی ضرورت سے زیادہ نہیں ہوتا ہے۔. کیونکہ Quay نے "ابھی کام کیا"، ہمیں کبھی بھی ٹریفک کو بہتر بنانے اور بوجھ کا انتظام کرنے میں وقت نہیں گزارنا پڑا۔ اس سب نے سیکورٹی کا غلط احساس پیدا کیا کہ سروس غیر معینہ مدت تک پیمانہ کر سکتی ہے۔
- جب سروس بند ہو جاتی ہے، اسے واپس لانا اور چلانا اولین ترجیح ہے۔. چونکہ Quay پہلی بندش کے دوران ایک مقفل ڈیٹا بیس کا شکار رہا، اس لیے ہمارے معیاری طریقہ کار کا مطلوبہ اثر نہیں ہوا اور ہم ان کا استعمال کرتے ہوئے سروس کو بحال کرنے سے قاصر رہے۔ اس کی وجہ سے ایک ایسی صورتحال پیدا ہوئی جہاں فعالیت کی بحالی پر تمام کوششوں پر توجہ مرکوز کرنے کے بجائے اصل وجہ تلاش کرنے کی امید میں ڈیٹا کا تجزیہ اور جمع کرنے میں وقت صرف کرنا پڑا۔
- ہر سروس فیچر کے اثر کا اندازہ لگائیں۔. کلائنٹ شاذ و نادر ہی ایپ رجسٹری کا استعمال کرتے ہیں، اس لیے یہ ہماری ٹیم کے لیے ترجیح نہیں تھی۔ جب پروڈکٹ کی کچھ خصوصیات بمشکل استعمال ہوتی ہیں، تو ان کے کیڑے شاذ و نادر ہی ظاہر ہوتے ہیں، اور ڈویلپرز کوڈ کی نگرانی کرنا چھوڑ دیتے ہیں۔ اس غلط فہمی کا شکار ہونا آسان ہے کہ اسے ایسا ہی ہونا چاہیے — جب تک کہ اچانک وہ فنکشن خود کو کسی بڑے واقعے کے مرکز میں نہ پا لے۔
اس کے بعد کیا ہے؟
سروس کے استحکام کو یقینی بنانے کا کام کبھی نہیں رکتا اور ہم اسے مسلسل بہتر کر رہے ہیں۔ چونکہ quay.io پر ٹریفک کی مقدار میں مسلسل اضافہ ہوتا جارہا ہے، ہم تسلیم کرتے ہیں کہ ہماری ذمہ داری ہے کہ ہم اپنے صارفین کے اعتماد پر پورا اترنے کے لیے ہر ممکن کوشش کریں۔ لہذا، ہم فی الحال مندرجہ ذیل کاموں پر کام کر رہے ہیں:
- بنیادی RDS مثال کے ساتھ مسائل کی صورت میں مناسب ٹریفک کو سنبھالنے میں سروس کی مدد کرنے کے لیے صرف پڑھنے کے لیے ڈیٹا بیس کی نقلیں لگائیں۔
- RDS مثال کو اپ ڈیٹ کرنا۔ موجودہ ورژن خود مسئلہ نہیں ہے۔ بلکہ، ہم صرف جھوٹی پگڈنڈی کو ہٹانا چاہتے ہیں (جس کی ہم نے ناکامی کے دوران پیروی کی)؛ سافٹ ویئر کو اپ ٹو ڈیٹ رکھنے سے مستقبل میں بندش کی صورت میں ایک اور عنصر ختم ہو جائے گا۔
- پورے کلسٹر میں اضافی کیشنگ۔ ہم ان علاقوں کی تلاش جاری رکھتے ہیں جہاں کیشنگ ڈیٹا بیس پر بوجھ کو کم کر سکتی ہے۔
- ایک ویب ایپلیکیشن فائر وال (WAF) کو شامل کرنا یہ دیکھنے کے لیے کہ quay.io سے کون جڑ رہا ہے اور کیوں۔
- اگلی ریلیز کے ساتھ شروع کرتے ہوئے، Red Hat OpenShift کلسٹرز quay.io پر دستیاب کنٹینر امیجز پر مبنی آپریٹر کیٹلاگ کے حق میں ایپ رجسٹری کو ترک کر دیں گے۔
- ایپ رجسٹری کے لیے ایک طویل مدتی متبادل اوپن کنٹینر انیشی ایٹو (OCI) آرٹفیکٹ وضاحتوں کے لیے معاون ثابت ہو سکتا ہے۔ یہ فی الحال مقامی Quay فعالیت کے طور پر لاگو کیا گیا ہے اور صارفین کے لیے اس وقت دستیاب ہو گا جب تفصیلات کو حتمی شکل دی جائے گی۔
مندرجہ بالا سبھی quay.io میں Red Hat کی جاری سرمایہ کاری کا حصہ ہیں کیونکہ ہم ایک چھوٹی "اسٹارٹ اپ طرز" ٹیم سے ایک بالغ SRE سے چلنے والے پلیٹ فارم کی طرف جاتے ہیں۔ ہم جانتے ہیں کہ ہمارے بہت سے صارفین اپنے روزمرہ کے کام میں quay.io پر انحصار کرتے ہیں (بشمول Red Hat!) اور ہم حالیہ بندشوں اور بہتری کی جاری کوششوں کے بارے میں زیادہ سے زیادہ شفاف ہونے کی کوشش کرتے ہیں۔
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com