بہت سے لوگ Elasticsearch کے ساتھ جدوجہد کرتے ہیں۔ لیکن کیا ہوتا ہے جب آپ اسے لاگس کو "خاص طور پر بڑے حجم میں" ذخیرہ کرنے کے لیے استعمال کرنا چاہتے ہیں؟ اور کیا متعدد ڈیٹا سینٹرز میں سے کسی کی ناکامی کا تجربہ کرنا بھی بے درد ہے؟ آپ کو کس قسم کا فن تعمیر کرنا چاہیے، اور آپ کو کن نقصانات سے ٹھوکریں لگیں گی؟
Odnoklassniki میں ہم نے لاگ مینجمنٹ کے مسئلے کو حل کرنے کے لیے elasticsearch استعمال کرنے کا فیصلہ کیا، اور اب ہم Habr کے ساتھ اپنے تجربے کا اشتراک کرتے ہیں: فن تعمیر کے بارے میں اور نقصانات کے بارے میں۔
میں Pyotr Zaitsev ہوں، میں Odnoklassniki میں ایک سسٹم ایڈمنسٹریٹر کے طور پر کام کرتا ہوں۔ اس سے پہلے، میں ایڈمن بھی تھا، مینٹیکور سرچ، اسفنکس سرچ، ایلاسٹک سرچ کے ساتھ کام کرتا تھا۔ شاید، اگر کوئی اور تلاش ظاہر ہوتی ہے، تو میں شاید اس کے ساتھ بھی کام کروں گا۔ میں رضاکارانہ بنیادوں پر متعدد اوپن سورس پروجیکٹس میں بھی حصہ لیتا ہوں۔
جب میں Odnoklassniki آیا تو میں نے انٹرویو میں لاپرواہی سے کہا کہ میں Elasticsearch کے ساتھ کام کر سکتا ہوں۔ جب میں نے اس پر قابو پا لیا اور کچھ آسان کاموں کو مکمل کر لیا، مجھے لاگ مینجمنٹ سسٹم کی اصلاح کا بڑا کام سونپا گیا جو اس وقت موجود تھا۔
کے تقاضے
نظام کی ضروریات کو مندرجہ ذیل طور پر مرتب کیا گیا تھا:
- گرے لاگ کو فرنٹ اینڈ کے طور پر استعمال کیا جانا تھا۔ چونکہ کمپنی کو پہلے سے ہی اس پروڈکٹ کو استعمال کرنے کا تجربہ تھا، پروگرامرز اور ٹیسٹرز اسے جانتے تھے، یہ ان کے لیے مانوس اور آسان تھا۔
- ڈیٹا کا حجم: اوسطاً 50-80 ہزار پیغامات فی سیکنڈ، لیکن اگر کوئی چیز ٹوٹ جائے تو ٹریفک کسی بھی چیز سے محدود نہیں ہوتی، یہ فی سیکنڈ 2-3 ملین لائنیں ہوسکتی ہیں۔
- صارفین کے ساتھ تلاش کے سوالات پر کارروائی کی رفتار کے تقاضوں پر بات کرنے کے بعد، ہم نے محسوس کیا کہ اس طرح کے نظام کو استعمال کرنے کا عام نمونہ یہ ہے: لوگ گزشتہ دو دنوں سے اپنی درخواست کے لاگز تلاش کر رہے ہیں اور ایک سے زیادہ انتظار نہیں کرنا چاہتے۔ ترتیب شدہ استفسار کے نتیجے کے لیے دوسرا۔
- منتظمین نے اصرار کیا کہ اگر ضروری ہو تو سسٹم آسانی سے توسیع پذیر ہو، اس کے کام کرنے کے بارے میں گہرائی سے تحقیق کرنے کی ضرورت کے بغیر۔
- تاکہ صرف دیکھ بھال کا کام جس کی ان سسٹمز کو وقتاً فوقتاً ضرورت ہوتی ہے وہ ہے کچھ ہارڈ ویئر کو تبدیل کرنا۔
- اس کے علاوہ، Odnoklassniki کی ایک بہترین تکنیکی روایت ہے: جو بھی سروس ہم شروع کرتے ہیں اسے ڈیٹا سینٹر کی ناکامی سے بچنا چاہیے (اچانک، غیر منصوبہ بند اور بالکل کسی بھی وقت)۔
اس منصوبے کے نفاذ میں آخری ضرورت ہمیں سب سے زیادہ لاگت آئی، جس پر میں مزید تفصیل سے بات کروں گا۔
بدھ
ہم چار ڈیٹا سینٹرز میں کام کرتے ہیں، جبکہ Elasticsearch ڈیٹا نوڈس صرف تین میں واقع ہوسکتے ہیں (کئی غیر تکنیکی وجوہات کی بناء پر)۔
ان چاروں ڈیٹا سینٹرز میں تقریباً 18 ہزار مختلف لاگ ذرائع - ہارڈویئر، کنٹینرز، ورچوئل مشینیں ہیں۔
اہم خصوصیت: کلسٹر کنٹینرز میں شروع ہوتا ہے۔ جسمانی مشینوں پر نہیں، بلکہ پر . کنٹینرز کو 2 کور کی ضمانت دی جاتی ہے، جو کہ 2.0Ghz v4 کی طرح ہے، اگر وہ بیکار ہیں تو بقیہ کوروں کو ری سائیکل کرنے کے امکان کے ساتھ۔
دوسرے الفاظ میں:
ٹوپولوجی
میں نے ابتدائی طور پر حل کی عمومی شکل کو اس طرح دیکھا:
- 3-4 VIPs گرے لاگ ڈومین کے A-ریکارڈ کے پیچھے ہیں، یہ وہ پتہ ہے جس پر لاگ بھیجے جاتے ہیں۔
- ہر VIP ایک LVS بیلنسر ہے۔
- اس کے بعد، لاگز گرے لاگ بیٹری میں جاتے ہیں، کچھ ڈیٹا GELF فارمیٹ میں ہوتا ہے، کچھ syslog فارمیٹ میں ہوتا ہے۔
- پھر یہ سب کچھ بڑے بیچوں میں Elasticsearch کوآرڈینیٹرز کی بیٹری پر لکھا جاتا ہے۔
- اور وہ، بدلے میں، متعلقہ ڈیٹا نوڈس کو لکھنے اور پڑھنے کی درخواستیں بھیجتے ہیں۔
اصطلاحات
شاید ہر کوئی اس اصطلاح کو تفصیل سے نہیں سمجھتا، اس لیے میں اس پر تھوڑا سا غور کرنا چاہوں گا۔
Elasticsearch کے کئی قسم کے نوڈس ہیں - ماسٹر، کوآرڈینیٹر، ڈیٹا نوڈ۔ مختلف کلسٹرز کے درمیان مختلف لاگ ٹرانسفارمیشنز اور مواصلت کے لیے دو دوسری قسمیں ہیں، لیکن ہم نے صرف وہی استعمال کیا جو درج ہیں۔
ماسٹر
یہ کلسٹر میں موجود تمام نوڈس کو پنگ کرتا ہے، کلسٹر کا تازہ ترین نقشہ برقرار رکھتا ہے اور اسے نوڈس کے درمیان تقسیم کرتا ہے، واقعہ کی منطق پر عمل کرتا ہے، اور مختلف قسم کے کلسٹر وائڈ ہاؤس کیپنگ انجام دیتا ہے۔
کوآرڈینیٹر
ایک واحد کام انجام دیتا ہے: کلائنٹس سے پڑھنے یا لکھنے کی درخواستوں کو قبول کرتا ہے اور اس ٹریفک کو روٹ کرتا ہے۔ اگر کوئی تحریری درخواست ہے تو، غالباً، یہ ماسٹر سے پوچھے گا کہ اسے متعلقہ انڈیکس کا کون سا حصہ ڈالنا چاہیے، اور درخواست کو مزید ری ڈائریکٹ کرے گا۔
ڈیٹا نوڈ
ڈیٹا کو اسٹور کرتا ہے، باہر سے آنے والے سرچ سوالات کو انجام دیتا ہے اور اس پر موجود شارڈز پر آپریشن کرتا ہے۔
گرےلوگ
یہ ELK اسٹیک میں Logstash کے ساتھ Kibana کے فیوژن کی طرح کچھ ہے۔ گرے لاگ UI اور لاگ پروسیسنگ پائپ لائن دونوں کو یکجا کرتا ہے۔ ہڈ کے نیچے، گرے لاگ کافکا اور زوکیپر چلاتے ہیں، جو گرے لاگ کو کلسٹر کے طور پر کنیکٹیویٹی فراہم کرتے ہیں۔ Elasticsearch دستیاب نہ ہونے کی صورت میں Graylog لاگز (کافکا) کو کیش کر سکتا ہے اور مخصوص قواعد کے مطابق پڑھنے اور لکھنے کی ناکام درخواستوں، گروپ اور مارک لاگز کو دہرا سکتا ہے۔ Logstash کی طرح، Graylog میں صفوں کو Elasticsearch پر لکھنے سے پہلے ان میں ترمیم کرنے کی فعالیت ہے۔
اس کے علاوہ، Graylog کے پاس ایک بلٹ ان سروس دریافت ہے جو ایک دستیاب Elasticsearch نوڈ کی بنیاد پر، پورے کلسٹر نقشے کو حاصل کرنے اور اسے ایک مخصوص ٹیگ کے ذریعے فلٹر کرنے کی اجازت دیتی ہے، جس سے مخصوص کنٹینرز کو درخواستیں بھیجنا ممکن ہوتا ہے۔
بصری طور پر یہ کچھ اس طرح لگتا ہے:
یہ ایک مخصوص مثال سے اسکرین شاٹ ہے۔ یہاں ہم تلاش کے استفسار پر مبنی ایک ہسٹوگرام بناتے ہیں اور متعلقہ قطاریں ڈسپلے کرتے ہیں۔
سوچکانک
سسٹم آرکیٹیکچر پر واپس آتے ہوئے، میں مزید تفصیل سے غور کرنا چاہوں گا کہ ہم نے انڈیکس ماڈل کیسے بنایا تاکہ یہ سب صحیح طریقے سے کام کرے۔
اوپر دیے گئے خاکے میں، یہ سب سے نچلی سطح ہے: Elasticsearch ڈیٹا نوڈس۔
انڈیکس ایک بڑی ورچوئل ہستی ہے جو Elasticsearch shards سے بنی ہے۔ اپنے آپ میں، ہر ایک شارڈ لوسین انڈیکس سے زیادہ کچھ نہیں ہے۔ اور ہر لوسین انڈیکس، بدلے میں، ایک یا زیادہ حصوں پر مشتمل ہوتا ہے۔
ڈیزائن کرتے وقت، ہم نے سوچا کہ ڈیٹا کی ایک بڑی مقدار پر پڑھنے کی رفتار کی ضرورت کو پورا کرنے کے لیے، ہمیں اس ڈیٹا کو ڈیٹا نوڈس میں یکساں طور پر "پھیلنے" کی ضرورت ہے۔
اس کا نتیجہ یہ نکلا کہ شارڈز کی تعداد فی انڈیکس (نقل کے ساتھ) ڈیٹا نوڈس کی تعداد کے برابر ہونی چاہیے۔ سب سے پہلے، دو کے برابر ریپلیکشن فیکٹر کو یقینی بنانے کے لیے (یعنی ہم کلسٹر کا نصف کھو سکتے ہیں)۔ اور، دوسرا، کلسٹر کے کم از کم نصف پر پڑھنے اور لکھنے کی درخواستوں پر کارروائی کرنے کے لیے۔
ہم نے سب سے پہلے 30 دن کے طور پر ذخیرہ کرنے کا وقت مقرر کیا۔
شارڈز کی تقسیم کو گرافک طور پر اس طرح دکھایا جا سکتا ہے:
مکمل گہرا سرمئی مستطیل ایک اشاریہ ہے۔ اس میں بائیں سرخ مربع بنیادی شارڈ ہے، انڈیکس میں پہلا۔ اور نیلا مربع ایک نقلی شارڈ ہے۔ وہ مختلف ڈیٹا سینٹرز میں واقع ہیں۔
جب ہم ایک اور شارڈ شامل کرتے ہیں، تو یہ تیسرے ڈیٹا سینٹر میں جاتا ہے۔ اور، آخر میں، ہمیں یہ ڈھانچہ ملتا ہے، جو ڈیٹا کی مستقل مزاجی کو کھونے کے بغیر DC کو کھونا ممکن بناتا ہے:
اشاریہ جات کی گردش، یعنی ایک نیا انڈیکس بنا کر اور سب سے پرانے کو حذف کرتے ہوئے، ہم نے اسے 48 گھنٹے کے برابر کر دیا (انڈیکس کے استعمال کے انداز کے مطابق: آخری 48 گھنٹے اکثر تلاش کیے جاتے ہیں)۔
یہ انڈیکس گردش کا وقفہ درج ذیل وجوہات کی وجہ سے ہے:
جب تلاش کی درخواست کسی مخصوص ڈیٹا نوڈ پر پہنچتی ہے، تو کارکردگی کے نقطہ نظر سے، یہ زیادہ منافع بخش ہوتا ہے جب ایک شارڈ سے استفسار کیا جاتا ہے، اگر اس کا سائز نوڈ کے کولہے کے سائز سے موازنہ کیا جائے۔ یہ آپ کو انڈیکس کے "گرم" حصے کو ایک ڈھیر میں رکھنے اور فوری طور پر اس تک رسائی حاصل کرنے کی اجازت دیتا ہے۔ جب بہت سارے "گرم حصے" ہوتے ہیں تو انڈیکس کی تلاش کی رفتار کم ہو جاتی ہے۔
جب ایک نوڈ ایک شارڈ پر تلاش کے استفسار پر عمل درآمد شروع کرتا ہے، تو یہ فزیکل مشین کے ہائپر تھریڈنگ کور کی تعداد کے برابر دھاگوں کی ایک بڑی تعداد کو مختص کرتا ہے۔ اگر تلاش کا سوال بڑی تعداد میں شارڈز کو متاثر کرتا ہے، تو دھاگوں کی تعداد متناسب طور پر بڑھتی ہے۔ اس کا سرچ کی رفتار پر منفی اثر پڑتا ہے اور نئے ڈیٹا کی انڈیکسنگ پر منفی اثر پڑتا ہے۔
مطلوبہ تلاش میں تاخیر فراہم کرنے کے لیے، ہم نے ایک SSD استعمال کرنے کا فیصلہ کیا۔ درخواستوں پر تیزی سے کارروائی کرنے کے لیے، ان کنٹینرز کی میزبانی کرنے والی مشینوں کے پاس کم از کم 56 کور ہونا ضروری ہے۔ 56 کے اعداد و شمار کو مشروط طور پر کافی قدر کے طور پر منتخب کیا گیا تھا جو دھاگوں کی تعداد کا تعین کرتا ہے جو Elasticsearch آپریشن کے دوران پیدا کرے گا۔ Elasitcsearch میں، بہت سے تھریڈ پول پیرامیٹرز براہ راست دستیاب کوروں کی تعداد پر منحصر ہوتے ہیں، جس کے نتیجے میں "کم کور - زیادہ نوڈس" کے اصول کے مطابق کلسٹر میں نوڈس کی مطلوبہ تعداد پر براہ راست اثر پڑتا ہے۔
نتیجے کے طور پر، ہم نے پایا کہ اوسطاً ایک شارڈ کا وزن تقریباً 20 گیگا بائٹس ہے، اور فی انڈیکس 1 شارڈز ہیں۔ اس کے مطابق، اگر ہم انہیں ہر 360 گھنٹے میں ایک بار گھمائیں، تو ہمارے پاس ان میں سے 48 ہیں۔ ہر انڈیکس میں 15 دن کا ڈیٹا ہوتا ہے۔
ڈیٹا رائٹنگ اور ریڈنگ سرکٹس
آئیے معلوم کریں کہ اس سسٹم میں ڈیٹا کیسے ریکارڈ کیا جاتا ہے۔
ہم کہتے ہیں کہ کچھ درخواست گرے لاگ سے کوآرڈینیٹر تک پہنچتی ہے۔ مثال کے طور پر، ہم 2-3 ہزار قطاروں کو انڈیکس کرنا چاہتے ہیں۔
کوآرڈینیٹر، گرے لاگ سے درخواست موصول ہونے کے بعد، ماسٹر سے سوال کرتا ہے: "اشاریہ سازی کی درخواست میں، ہم نے خاص طور پر ایک اشاریہ متعین کیا تھا، لیکن اسے کس شارڈ میں لکھنا ہے، اس کی وضاحت نہیں کی گئی تھی۔"
ماسٹر جواب دیتا ہے: "اس معلومات کو شارڈ نمبر 71 پر لکھیں،" جس کے بعد اسے براہ راست متعلقہ ڈیٹا نوڈ پر بھیجا جاتا ہے، جہاں پرائمری-شارڈ نمبر 71 واقع ہے۔
جس کے بعد ٹرانزیکشن لاگ کو ایک ریپلیکا-شارڈ میں نقل کیا جاتا ہے، جو دوسرے ڈیٹا سینٹر میں واقع ہے۔
تلاش کی درخواست Graylog سے کوآرڈینیٹر تک پہنچتی ہے۔ کوآرڈینیٹر اسے انڈیکس کے مطابق ری ڈائریکٹ کرتا ہے، جبکہ Elasticsearch راؤنڈ رابن اصول کا استعمال کرتے ہوئے پرائمری-شارڈ اور ریپلیکا-شارڈ کے درمیان درخواستیں تقسیم کرتا ہے۔
180 نوڈس غیر مساوی طور پر جواب دیتے ہیں، اور جب وہ جواب دے رہے ہوتے ہیں، کوآرڈینیٹر معلومات جمع کر رہا ہوتا ہے جو پہلے سے ہی تیز ڈیٹا نوڈس کے ذریعے "تھوکا" جا چکا ہوتا ہے۔ اس کے بعد، جب یا تو تمام معلومات پہنچ جاتی ہیں، یا درخواست کا وقت ختم ہوجاتا ہے، تو یہ سب کچھ براہ راست کلائنٹ کو دیتا ہے۔
یہ پورا نظام اوسطاً پچھلے 48 گھنٹوں کے لیے 300-400ms میں تلاش کے سوالات پر کارروائی کرتا ہے، ان سوالات کو ایک معروف وائلڈ کارڈ کے ساتھ چھوڑ کر۔
Elasticsearch کے ساتھ پھول: جاوا سیٹ اپ
یہ سب کچھ اس طرح کام کرنے کے لیے جس طرح ہم اصل میں چاہتے تھے، ہم نے کلسٹر میں مختلف قسم کی چیزوں کو ڈیبگ کرنے میں کافی وقت گزارا۔
دریافت ہونے والے مسائل کا پہلا حصہ Elasticsearch میں جاوا کو پہلے سے ترتیب دینے کے طریقے سے متعلق تھا۔
مسئلہ ایک
ہم نے بہت بڑی تعداد میں رپورٹس دیکھی ہیں کہ لوسین کی سطح پر، جب بیک گراؤنڈ جابز چل رہی ہوتی ہیں، لوسین سیگمنٹ ایک غلطی کے ساتھ فیل ہو جاتا ہے۔ اسی وقت، لاگز میں یہ واضح تھا کہ یہ ایک OutOfMemoryError کی خرابی تھی۔ ہم نے ٹیلی میٹری سے دیکھا کہ کولہا آزاد تھا، اور یہ واضح نہیں تھا کہ یہ آپریشن کیوں ناکام ہو رہا ہے۔
یہ پتہ چلا کہ لوسین انڈیکس انضمام کولہے کے باہر واقع ہوتا ہے۔ اور کنٹینرز استعمال ہونے والے وسائل کے لحاظ سے کافی حد تک محدود ہیں۔ ان وسائل میں صرف ہیپ ہی فٹ ہو سکتا ہے (heap.size قدر تقریباً RAM کے برابر تھی)، اور کچھ آف ہیپ آپریشنز میموری مختص کرنے کی غلطی کے ساتھ کریش ہو جاتے ہیں اگر کسی وجہ سے وہ ~500MB میں فٹ نہیں ہوتے جو حد سے پہلے رہ جاتے ہیں۔
حل کافی معمولی تھا: کنٹینر کے لئے دستیاب RAM کی مقدار میں اضافہ کیا گیا تھا، جس کے بعد ہم بھول گئے کہ ہمیں اس طرح کے مسائل بھی تھے۔
مسئلہ دو
کلسٹر کے آغاز کے 4-5 دن بعد، ہم نے دیکھا کہ ڈیٹا نوڈس وقتاً فوقتاً کلسٹر سے باہر آنا شروع ہو جاتے ہیں اور 10-20 سیکنڈ کے بعد اس میں داخل ہوتے ہیں۔
جب ہم نے اس کا پتہ لگانا شروع کیا تو پتہ چلا کہ Elasticsearch میں یہ آف ہیپ میموری کسی بھی طرح سے کنٹرول نہیں ہے۔ جب ہم نے کنٹینر کو مزید میموری دی، تو ہم مختلف معلومات کے ساتھ براہ راست بفر پولز کو بھرنے میں کامیاب ہو گئے، اور ایلسٹک سرچ سے واضح GC شروع ہونے کے بعد ہی اسے صاف کیا گیا۔
بعض صورتوں میں، اس آپریشن میں کافی وقت لگا، اور اس وقت کے دوران کلسٹر اس نوڈ کو پہلے سے ہی خارج ہونے کے طور پر نشان زد کرنے میں کامیاب رہا۔ یہ مسئلہ اچھی طرح بیان کیا گیا ہے۔ .
حل مندرجہ ذیل تھا: ہم نے ان آپریشنز کے لیے ڈھیر سے باہر میموری کا بڑا حصہ استعمال کرنے کی جاوا کی صلاحیت کو محدود کر دیا۔ ہم نے اسے 16 گیگا بائٹس (-XX:MaxDirectMemorySize=16g) تک محدود کر دیا، اس بات کو یقینی بناتے ہوئے کہ واضح GC کو زیادہ کثرت سے بلایا جائے اور بہت تیزی سے کارروائی کی جائے، اس طرح کلسٹر کو مزید غیر مستحکم نہیں کیا جائے گا۔
مسئلہ تین
اگر آپ کو لگتا ہے کہ "سب سے زیادہ غیر متوقع لمحے میں کلسٹر چھوڑنے والے نوڈس" کے مسائل ختم ہو گئے ہیں، تو آپ غلطی پر ہیں۔
جب ہم نے کام کو اشاریہ جات کے ساتھ ترتیب دیا، تو ہم نے mmapfs کا انتخاب کیا۔ عظیم انقطاع کے ساتھ تازہ شارڈز پر۔ یہ بہت بڑی غلطی تھی، کیونکہ جب mmapfs کا استعمال کرتے ہوئے فائل کو RAM میں میپ کیا جاتا ہے، اور پھر ہم میپ شدہ فائل کے ساتھ کام کرتے ہیں۔ اس کی وجہ سے، یہ پتہ چلتا ہے کہ جب جی سی ایپلی کیشن میں تھریڈز کو روکنے کی کوشش کرتا ہے، تو ہم کافی دیر تک سیف پوائنٹ پر جاتے ہیں، اور اس کے راستے میں، ایپلی کیشن ماسٹر کی درخواستوں کا جواب دینا بند کر دیتی ہے کہ آیا یہ زندہ ہے یا نہیں۔ . اس کے مطابق، ماسٹر کا خیال ہے کہ نوڈ اب کلسٹر میں موجود نہیں ہے۔ اس کے بعد، 5-10 سیکنڈ کے بعد، کوڑا اٹھانے والا کام کرتا ہے، نوڈ زندہ ہو جاتا ہے، دوبارہ کلسٹر میں داخل ہوتا ہے اور شارڈز کو شروع کرنا شروع کر دیتا ہے۔ یہ سب کچھ "جس پروڈکشن کے ہم مستحق تھے" کی طرح محسوس ہوا اور کسی بھی سنگین چیز کے لیے موزوں نہیں تھا۔
اس رویے سے چھٹکارا پانے کے لیے، ہم نے پہلے معیاری niofs کی طرف رخ کیا، اور پھر، جب ہم ایلاسٹک کے پانچویں ورژن سے چھٹے میں منتقل ہوئے، تو ہم نے ہائبرڈ ایف کو آزمایا، جہاں یہ مسئلہ دوبارہ پیش نہیں کیا گیا تھا۔ آپ اسٹوریج کی اقسام کے بارے میں مزید پڑھ سکتے ہیں۔ .
مسئلہ چار
پھر ایک اور بہت ہی دلچسپ مسئلہ تھا جس کا ہم نے ریکارڈ وقت تک علاج کیا۔ ہم نے اسے 2-3 ماہ تک پکڑا کیونکہ اس کا نمونہ بالکل سمجھ سے باہر تھا۔
کبھی کبھی ہمارے رابطہ کار فل جی سی میں جاتے تھے، عموماً دوپہر کے کھانے کے بعد، اور وہاں سے واپس نہیں آتے تھے۔ ایک ہی وقت میں، جب جی سی تاخیر کو لاگ ان کرتے ہوئے، یہ اس طرح نظر آیا: سب کچھ ٹھیک چل رہا ہے، ٹھیک ہے، ٹھیک ہے، اور پھر اچانک سب کچھ بہت خراب ہو رہا ہے۔
پہلے تو ہم نے سوچا کہ ہمارے پاس ایک برا صارف ہے جو کسی قسم کی درخواست شروع کر رہا تھا جس نے کوآرڈینیٹر کو کام کے موڈ سے باہر کر دیا۔ ہم نے کافی دیر تک درخواستیں لاگ ان کیں، یہ جاننے کی کوشش کی کہ کیا ہو رہا ہے۔
نتیجے کے طور پر، یہ پتہ چلا کہ اس وقت جب کوئی صارف ایک بہت بڑی درخواست شروع کرتا ہے، اور یہ ایک مخصوص Elasticsearch کوآرڈینیٹر تک پہنچ جاتا ہے، کچھ نوڈس دوسروں کے مقابلے میں زیادہ دیر تک جواب دیتے ہیں۔
اور جب کوآرڈینیٹر تمام نوڈس سے جواب کا انتظار کر رہا ہوتا ہے، وہ نوڈس سے بھیجے گئے نتائج کو جمع کرتا ہے جو پہلے ہی جواب دے چکے ہیں۔ GC کے لیے، اس کا مطلب ہے کہ ہمارے ہیپ کے استعمال کے پیٹرن بہت تیزی سے بدل جاتے ہیں۔ اور GC جو ہم نے استعمال کیا وہ اس کام سے نمٹ نہیں سکا۔
اس صورت حال میں کلسٹر کے رویے کو تبدیل کرنے کا واحد حل JDK13 کی طرف ہجرت اور Shenandoah کوڑا اٹھانے والے کا استعمال ہے۔ اس سے مسئلہ حل ہو گیا، ہمارے رابطہ کاروں نے گرنا بند کر دیا۔
یہیں سے جاوا کے مسائل ختم ہوئے اور بینڈوتھ کے مسائل شروع ہوئے۔
Elasticsearch کے ساتھ "بیریاں": تھرو پٹ
تھرو پٹ کے ساتھ مسائل کا مطلب یہ ہے کہ ہمارا کلسٹر مستحکم طور پر کام کرتا ہے، لیکن انڈیکس شدہ دستاویزات کی تعداد میں چوٹیوں پر اور مشقوں کے دوران، کارکردگی ناکافی ہے۔
پہلی علامت کا سامنا کرنا پڑا: پیداوار میں کچھ "دھماکے" کے دوران، جب لاگز کی ایک بہت بڑی تعداد اچانک پیدا ہو جاتی ہے، تو اشاریہ سازی کی خرابی es_rejected_execution Graylog میں کثرت سے چمکنا شروع ہو جاتی ہے۔
یہ اس حقیقت کی وجہ سے تھا کہ ایک ڈیٹا نوڈ پر thread_pool.write.queue، اس لمحے تک جب تک Elasticsearch انڈیکسنگ کی درخواست پر کارروائی کرنے اور معلومات کو ڈسک پر موجود شارڈ پر اپ لوڈ کرنے کے قابل ہے، صرف 200 درخواستوں کو بطور ڈیفالٹ کیش کرنے کے قابل ہے۔ اور میں اس پیرامیٹر کے بارے میں بہت کم کہا جاتا ہے۔ صرف دھاگوں کی زیادہ سے زیادہ تعداد اور پہلے سے طے شدہ سائز کی نشاندہی کی گئی ہے۔
بلاشبہ، ہم اس قدر کو موڑنے کے لیے گئے اور مندرجہ ذیل چیزیں دریافت کیں: خاص طور پر، ہمارے سیٹ اپ میں، 300 تک کی درخواستوں کو کافی اچھی طرح سے محفوظ کیا گیا ہے، اور اس سے زیادہ قیمت اس حقیقت سے بھری ہوئی ہے کہ ہم دوبارہ مکمل GC میں پرواز کرتے ہیں۔
اس کے علاوہ، چونکہ یہ پیغامات کے بیچز ہیں جو ایک درخواست کے اندر پہنچتے ہیں، اس لیے گرے لاگ کو موافقت کرنا ضروری تھا تاکہ یہ اکثر اور چھوٹے بیچوں میں نہیں بلکہ بڑے بیچوں میں یا ہر 3 سیکنڈ میں ایک بار لکھتا ہے اگر بیچ ابھی بھی مکمل نہ ہو۔ اس معاملے میں، یہ پتہ چلتا ہے کہ جو معلومات ہم Elasticsearch میں لکھتے ہیں وہ دو سیکنڈ میں نہیں، بلکہ پانچ میں دستیاب ہو جاتی ہے (جو ہمارے لیے کافی مناسب ہے)، لیکن ری ٹرے کی تعداد جو کہ ایک بڑے کو آگے بڑھانے کے لیے کرنی پڑتی ہے۔ معلومات کا ذخیرہ کم ہو گیا ہے۔
یہ ان لمحات میں خاص طور پر اہم ہوتا ہے جب کوئی چیز کہیں کریش ہو جاتی ہے اور اس کے بارے میں غصے سے اطلاع دیتا ہے، تاکہ مکمل طور پر اسپام شدہ لچکدار نہ ملے، اور کچھ عرصے کے بعد - گرے لاگ نوڈس جو بھرے ہوئے بفرز کی وجہ سے ناکارہ ہوں۔
اس کے علاوہ، جب ہمارے پاس پروڈکشن میں یہی دھماکے ہوتے تھے، تو ہمیں پروگرامرز اور ٹیسٹرز کی طرف سے شکایات موصول ہوئیں: اس وقت جب انہیں واقعی ان لاگز کی ضرورت تھی، انہیں بہت آہستہ سے دیا گیا۔
وہ اس کا اندازہ لگانے لگے۔ ایک طرف، یہ واضح تھا کہ تلاش کے استفسارات اور اشاریہ سازی کے سوالات دونوں پر عملدرآمد کیا گیا تھا، بنیادی طور پر، ایک ہی جسمانی مشینوں پر، اور کسی نہ کسی طریقے سے کچھ کمی ہوگی۔
لیکن یہ جزوی طور پر اس حقیقت کی وجہ سے روکا جا سکتا ہے کہ Elasticsearch کے چھٹے ورژن میں ایک الگورتھم نمودار ہوا جو آپ کو متعلقہ ڈیٹا نوڈس کے درمیان سوالات کی تقسیم کرنے کی اجازت دیتا ہے نہ کہ بے ترتیب راؤنڈ رابن اصول کے مطابق (وہ کنٹینر جو اشاریہ سازی کرتا ہے اور پرائمری- shard بہت مصروف ہو سکتا ہے، فوری جواب دینے کا کوئی طریقہ نہیں ہو گا)، لیکن اس درخواست کو ریپلیکا-شارڈ والے کم بھرے ہوئے کنٹینر پر بھیجنا، جو بہت تیزی سے جواب دے گا۔ دوسرے لفظوں میں، ہم use_adaptive_replica_selection پر پہنچے: true۔
پڑھنے کی تصویر اس طرح نظر آنے لگتی ہے:
اس الگورتھم کی منتقلی نے ان لمحات میں استفسار کے وقت کو نمایاں طور پر بہتر کرنا ممکن بنایا جب ہمارے پاس لکھنے کے لیے لاگز کا ایک بڑا بہاؤ تھا۔
آخر کار، بنیادی مسئلہ ڈیٹا سینٹر کو بے دردی سے ہٹانا تھا۔
ایک ڈی سی سے کنکشن کھونے کے فوراً بعد ہم کلسٹر سے کیا چاہتے تھے:
- اگر ہمارے پاس ناکام ڈیٹا سینٹر میں موجودہ ماسٹر ہے، تو اسے دوبارہ منتخب کیا جائے گا اور کسی دوسرے ڈی سی میں کسی دوسرے نوڈ میں بطور کردار منتقل کیا جائے گا۔
- ماسٹر کلسٹر سے تمام ناقابل رسائی نوڈس کو جلدی سے ہٹا دے گا۔
- باقی کی بنیاد پر، وہ سمجھے گا: کھوئے ہوئے ڈیٹا سینٹر میں ہمارے پاس فلاں فلاں پرائمری شارڈز تھے، وہ بقیہ ڈیٹا سینٹرز میں تیزی سے تکمیلی ریپلیکا شارڈز کو فروغ دے گا، اور ہم ڈیٹا کو انڈیکس کرنا جاری رکھیں گے۔
- اس کے نتیجے میں، کلسٹر کی تحریر اور پڑھنے کا عمل بتدریج کم ہو جائے گا، لیکن عام طور پر سب کچھ کام کرے گا، اگرچہ آہستہ آہستہ، لیکن مستحکم طور پر۔
جیسا کہ یہ نکلا، ہم کچھ اس طرح چاہتے تھے:
اور ہمیں درج ذیل ملا:
یہ کیسے ممکن ہوا؟
جب ڈیٹا سینٹر گرا تو ہمارا آقا رکاوٹ بن گیا۔
کیوں؟
حقیقت یہ ہے کہ ماسٹر کے پاس ایک TaskBatcher ہے، جو کلسٹر میں کچھ کاموں اور واقعات کو تقسیم کرنے کا ذمہ دار ہے۔ کوئی بھی نوڈ ایگزٹ، ریپلیکا سے پرائمری تک شارڈ کی کوئی پروموشن، کہیں شارڈ بنانے کا کوئی بھی کام - یہ سب سب سے پہلے TaskBatcher کے پاس جاتا ہے، جہاں اسے ترتیب وار اور ایک دھاگے میں پروسیس کیا جاتا ہے۔
ایک ڈیٹا سینٹر کی واپسی کے وقت، پتہ چلا کہ بچ جانے والے ڈیٹا سینٹرز میں موجود تمام ڈیٹا نوڈس ماسٹر کو مطلع کرنا اپنا فرض سمجھتے ہیں "ہم نے فلاں فلاں شارڈز اور فلاں فلاں ڈیٹا نوڈس کھو دیے ہیں۔"
اسی وقت، زندہ بچ جانے والے ڈیٹا نوڈس نے یہ تمام معلومات موجودہ ماسٹر کو بھیجی اور اس بات کی تصدیق کا انتظار کرنے کی کوشش کی کہ اس نے اسے قبول کر لیا ہے۔ انہوں نے اس کا انتظار نہیں کیا، کیونکہ ماسٹر کو اس کے جواب سے زیادہ تیزی سے کام ملتے تھے۔ نوڈس نے دہرائی جانے والی درخواستوں کا وقت ختم کر دیا، اور اس وقت ماسٹر نے ان کا جواب دینے کی کوشش بھی نہیں کی، بلکہ ترجیحی بنیادوں پر درخواستوں کو چھانٹنے کے کام میں پوری طرح مشغول ہو گیا۔
ٹرمینل شکل میں، یہ پتہ چلا کہ ڈیٹا نوڈس نے ماسٹر کو اس مقام تک اسپام کیا کہ یہ مکمل GC پر چلا گیا۔ اس کے بعد، ہمارا ماسٹر رول کسی اگلے نوڈ پر چلا گیا، بالکل ایسا ہی اس کے ساتھ ہوا، اور اس کے نتیجے میں کلسٹر مکمل طور پر گر گیا۔
ہم نے پیمائش کی، اور ورژن 6.4.0 سے پہلے، جہاں یہ طے کیا گیا تھا، ہمارے لیے کلسٹر کو مکمل طور پر بند کرنے کے لیے بیک وقت 10 میں سے صرف 360 ڈیٹا نوڈس آؤٹ پٹ کرنا کافی تھا۔
یہ کچھ اس طرح نظر آیا:
ورژن 6.4.0 کے بعد، جہاں اس خوفناک بگ کو ٹھیک کر دیا گیا، ڈیٹا نوڈس نے ماسٹر کو مارنا بند کر دیا۔ لیکن اس نے اسے "ہوشیار" نہیں بنایا۔ یعنی: جب ہم 2، 3 یا 10 (ایک کے علاوہ کوئی بھی نمبر) ڈیٹا نوڈس آؤٹ پٹ کرتے ہیں، تو ماسٹر کو پہلا پیغام ملتا ہے جس میں کہا جاتا ہے کہ نوڈ A چھوڑ گیا ہے، اور نوڈ B، نوڈ C کو اس بارے میں، نوڈ D کو بتانے کی کوشش کرتا ہے۔
اور اس وقت، یہ صرف 20-30 سیکنڈ کے برابر، کسی کو کسی چیز کے بارے میں بتانے کی کوششوں کے لیے ٹائم آؤٹ مقرر کرکے ہی نمٹا جا سکتا ہے، اور اس طرح کلسٹر سے باہر جانے والے ڈیٹا سینٹر کی رفتار کو کنٹرول کیا جا سکتا ہے۔
اصولی طور پر، یہ ان تقاضوں میں فٹ بیٹھتا ہے جو ابتدائی طور پر پراجیکٹ کے حصے کے طور پر حتمی مصنوع کے لیے پیش کیے گئے تھے، لیکن "خالص سائنس" کے نقطہ نظر سے یہ ایک بگ ہے۔ جسے، ویسے، ورژن 7.2 میں ڈویلپرز نے کامیابی کے ساتھ طے کیا تھا۔
مزید برآں، جب ایک مخصوص ڈیٹا نوڈ نکلا، تو پتہ چلا کہ اس کے اخراج کے بارے میں معلومات کو پھیلانا پورے کلسٹر کو بتانے سے زیادہ اہم تھا کہ اس پر فلاں فلاں پرائمری شارڈز موجود ہیں (دوسرے ڈیٹا میں ریپلیکا شارڈ کو فروغ دینے کے لیے) پرائمری میں مرکز، اور معلومات میں ان پر لکھا جا سکتا ہے)۔
لہذا، جب سب کچھ پہلے ہی ختم ہو چکا ہے، جاری کردہ ڈیٹا نوڈس کو فوری طور پر باسی کے طور پر نشان زد نہیں کیا جاتا ہے۔ اس کے مطابق، ہمیں اس وقت تک انتظار کرنے پر مجبور کیا جاتا ہے جب تک کہ تمام پنگز جاری کردہ ڈیٹا نوڈس تک ختم نہ ہو جائیں، اور اس کے بعد ہی ہمارا کلسٹر ہمیں یہ بتانا شروع کر دیتا ہے کہ وہاں، وہاں، اور وہاں ہمیں معلومات کی ریکارڈنگ جاری رکھنے کی ضرورت ہے۔ آپ اس بارے میں مزید پڑھ سکتے ہیں۔ .
نتیجے کے طور پر، آج ڈیٹا سینٹر کو نکالنے کے آپریشن میں ہمیں رش کے اوقات میں تقریباً 5 منٹ لگتے ہیں۔ اتنے بڑے اور اناڑی کالوسس کے لیے، یہ بہت اچھا نتیجہ ہے۔
نتیجے کے طور پر، ہم مندرجہ ذیل فیصلے پر پہنچے:
- ہمارے پاس 360 گیگا بائٹ ڈسک کے ساتھ 700 ڈیٹا نوڈس ہیں۔
- انہی ڈیٹا نوڈس کے ذریعے ٹریفک کو روٹنگ کے لیے 60 کوآرڈینیٹر۔
- 40 ماسٹرز جو ہم نے 6.4.0 سے پہلے کے ورژن کے بعد سے ایک قسم کی میراث کے طور پر چھوڑے ہیں - ڈیٹا سینٹر سے دستبرداری سے بچنے کے لیے، ہم ذہنی طور پر کئی مشینوں کو کھونے کے لیے تیار تھے تاکہ اس بات کی ضمانت دی جا سکے کہ ماسٹرز کا کورم بدترین صورت حال
- ایک کنٹینر پر کرداروں کو یکجا کرنے کی کسی بھی کوشش کو اس حقیقت کے ساتھ پورا کیا گیا کہ جلد یا بدیر نوڈ بوجھ کے نیچے ٹوٹ جائے گا۔
- پورا کلسٹر 31 گیگا بائٹس کا ایک heap.size استعمال کرتا ہے: سائز کو کم کرنے کی تمام کوششوں کے نتیجے میں یا تو سرکردہ وائلڈ کارڈ کے ساتھ بھاری تلاش کے سوالات پر کچھ نوڈس ختم ہو جاتے ہیں یا پھر Elasticsearch میں ہی سرکٹ بریکر حاصل کرتے ہیں۔
- اس کے علاوہ، تلاش کی کارکردگی کو یقینی بنانے کے لیے، ہم نے کوشش کی کہ کلسٹر میں موجود اشیاء کی تعداد کو جتنا ممکن ہو سکے کم رکھا جائے، تاکہ ہم ماسٹر میں پائے جانے والے رکاوٹ میں ممکنہ حد تک کم واقعات پر کارروائی کریں۔
آخر میں نگرانی کے بارے میں
اس بات کو یقینی بنانے کے لیے کہ یہ سب کچھ مقصد کے مطابق کام کرتا ہے، ہم درج ذیل کی نگرانی کرتے ہیں:
- ہر ڈیٹا نوڈ ہمارے کلاؤڈ کو رپورٹ کرتا ہے کہ یہ موجود ہے، اور اس پر فلاں فلاں شارڈز ہیں۔ جب ہم کہیں کسی چیز کو بجھاتے ہیں تو کلسٹر 2-3 سیکنڈ کے بعد رپورٹ کرتا ہے کہ مرکز A میں ہم نے نوڈس 2، 3 اور 4 کو بجھا دیا ہے - اس کا مطلب ہے کہ دوسرے ڈیٹا سینٹرز میں ہم کسی بھی حالت میں ان نوڈس کو نہیں بجھا سکتے جن پر صرف ایک شارڈ ہوتا ہے۔ بائیں.
- ماسٹر کے رویے کی نوعیت کو جانتے ہوئے، ہم زیر التواء کاموں کی تعداد کو بہت غور سے دیکھتے ہیں۔ کیونکہ ایک رکا ہوا کام بھی، اگر وہ وقت پر ختم نہیں ہوتا ہے، تو نظریاتی طور پر کسی ہنگامی صورت حال میں اس کی وجہ بن سکتی ہے، مثال کے طور پر، پرائمری میں ریپلیکا شارڈ کا پروموشن کام نہیں کرتا، جس کی وجہ سے انڈیکسنگ کام کرنا بند کر دے گی۔
- ہم کوڑا اٹھانے میں تاخیر کو بھی بہت قریب سے دیکھتے ہیں، کیونکہ اصلاح کے دوران ہمیں پہلے ہی اس کے ساتھ بڑی مشکلات کا سامنا کرنا پڑا ہے۔
- دھاگے کے ذریعے مسترد کر دیتا ہے تاکہ پہلے سے سمجھ لیا جائے کہ رکاوٹ کہاں ہے۔
- ٹھیک ہے، معیاری میٹرکس جیسے ہیپ، RAM اور I/O۔
مانیٹرنگ کی تعمیر کرتے وقت، آپ کو Elasticsearch میں تھریڈ پول کی خصوصیات کو مدنظر رکھنا چاہیے۔ تلاش اور اشاریہ سازی کے لیے کنفیگریشن کے اختیارات اور ڈیفالٹ اقدار کی وضاحت کرتا ہے، لیکن thread_pool.management کے بارے میں مکمل طور پر خاموش ہے۔ یہ تھریڈز پراسیس کرتے ہیں، خاص طور پر، _cat/shards اور اسی طرح کے دیگر سوالات، جو مانیٹرنگ لکھتے وقت استعمال کرنے میں آسان ہیں۔ کلسٹر جتنا بڑا ہوگا، اتنی ہی زیادہ اس طرح کی درخواستیں فی یونٹ وقت پر عمل میں لائی جاتی ہیں، اور مذکورہ بالا thread_pool.management کو نہ صرف آفیشل دستاویزات میں پیش کیا جاتا ہے، بلکہ یہ ڈیفالٹ طور پر 5 تھریڈز تک محدود ہوتا ہے، جسے بہت جلد نمٹا دیا جاتا ہے۔ جس کی نگرانی صحیح طریقے سے کام کرنا چھوڑ دیتی ہے۔
میں آخر میں کیا کہنا چاہتا ہوں: ہم نے یہ کیا! ہم اپنے پروگرامرز اور ڈویلپرز کو ایک ایسا ٹول دینے کے قابل تھے جو تقریباً کسی بھی صورت حال میں پروڈکشن میں کیا ہو رہا ہے اس کے بارے میں فوری اور قابل اعتماد معلومات فراہم کر سکتا ہے۔
جی ہاں، یہ کافی پیچیدہ نکلا، لیکن، اس کے باوجود، ہم اپنی خواہشات کو موجودہ پروڈکٹس میں فٹ کرنے میں کامیاب ہو گئے، جنہیں ہمیں اپنے لیے پیچ اور دوبارہ لکھنے کی ضرورت نہیں تھی۔
ماخذ: www.habr.com