ایمیزون اوپن سرچ سروس میں شارڈ پر انفراسٹرکچر کی ناکامیوں کا اثر

ایمیزون اوپن سرچ سروس ایک منظم سروس ہے جو AWS Cloud میں بڑے پیمانے پر OpenSearch اور Legacy Elasticsearch کلسٹرز کو محفوظ، تعینات، اور آپریٹ کرنا آسان بناتی ہے۔ Amazon OpenSearch سروس آپ کے کلسٹر کے لیے تمام وسائل فراہم کرتی ہے، اسے لانچ کرتی ہے، اور خود بخود ناکام نوڈس کا پتہ لگاتی ہے اور ان کی جگہ لیتی ہے، جس سے خود نظم شدہ انفراسٹرکچر کے اوور ہیڈ کو کم کیا جاتا ہے۔ یہ سروس آپ کے لیے اوپن سرچ کے تازہ ترین ورژن، Elasticsearch کے 19 ورژن (1.5 سے 7.10 ورژنز) کے لیے سپورٹ، اور ویژولائزیشن کی صلاحیتوں کی پیشکش کر کے انٹرایکٹو لاگ اینالیٹکس، ریئل ٹائم ایپلیکیشن مانیٹرنگ، ویب سائٹ کی تلاش اور مزید بہت کچھ کرنا آسان بناتی ہے۔ اوپن سرچ ڈیش بورڈز اور کبانا (1.5 سے 7.10 ورژن)۔

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

اگر آپ عام طور پر شارڈ ایلوکیشن منطق پر مزید پس منظر چاہتے ہیں، تو براہ کرم دیکھیں ڈیمیسٹیفائنگ Elasticsearch شارڈ ایلوکیشن.

للکار

ایک Amazon OpenSearch سروس کے ڈومین کو "متوازن" کہا جاتا ہے جب نوڈس کی تعداد کو ترتیب شدہ دستیابی زونز میں یکساں طور پر تقسیم کیا جاتا ہے، اور شارڈز کی کل تعداد تمام دستیاب نوڈس میں یکساں طور پر تقسیم کی جاتی ہے، بغیر کسی ایک انڈیکس کے شارڈز کے ارتکاز کے۔ نوڈ نیز، OpenSearch کے پاس "Zone Awareness" کہلانے والی ایک خاصیت ہے جو، فعال ہونے پر، اس بات کو یقینی بناتی ہے کہ بنیادی شارڈ اور اس سے متعلقہ نقل مختلف دستیابی والے علاقوں میں مختص کی گئی ہے۔ اگر آپ کے پاس ڈیٹا کی ایک سے زیادہ کاپیاں ہیں، تو ایک سے زیادہ دستیابی زونز کا ہونا بہتر غلطی برداشت اور دستیابی فراہم کرتا ہے۔ اس صورت میں، ڈومین کو اسکیل آؤٹ یا اسکیل کیا جاتا ہے یا نوڈز کی ناکامی کے دوران، OpenSearch خودکار طور پر دستیاب نوڈس کے درمیان شارڈز کو دوبارہ تقسیم کرتا ہے جبکہ زون کی آگاہی کی بنیاد پر مختص قوانین کی پابندی کرتا ہے۔

جبکہ شارڈ بیلنسنگ کا عمل اس بات کو یقینی بناتا ہے کہ شارڈز کو دستیابی والے زونز میں یکساں طور پر تقسیم کیا گیا ہے، بعض صورتوں میں، اگر کسی ایک زون میں غیر متوقع طور پر ناکامی ہوتی ہے، تو شارڈز کو زندہ رہنے والے نوڈس میں دوبارہ تقسیم کیا جائے گا۔ اس کے نتیجے میں زندہ بچ جانے والے نوڈس مغلوب ہو سکتے ہیں، جو کلسٹر کے استحکام کو متاثر کر سکتے ہیں۔

مثال کے طور پر، اگر تین نوڈ کلسٹر میں ایک نوڈ نیچے چلا جاتا ہے، تو OpenSearch غیر تفویض کردہ شارڈز کو دوبارہ تقسیم کرتا ہے، جیسا کہ درج ذیل خاکہ میں دکھایا گیا ہے۔ یہاں "P" ایک پرائمری شارڈ کاپی کی نمائندگی کرتا ہے، جبکہ "R" ریپلیکا شارڈ کاپی کی نمائندگی کرتا ہے۔

ڈومین کے اس رویے کی دو حصوں میں وضاحت کی جا سکتی ہے - ناکامی کے دوران اور بحالی کے دوران۔

ناکامی کے دوران

متعدد دستیابی زونز میں تعینات ایک ڈومین اپنی زندگی کے دوران متعدد قسم کی ناکامیوں کا سامنا کر سکتا ہے۔

مکمل زون کی ناکامی

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

• جب متاثرہ زون کے شارڈز کو دوبارہ صحت مند زونز میں منتقل کیا جاتا ہے، تو وہ شارڈ ریکوری کو متحرک کرتے ہیں جو تاخیر کو بڑھا سکتے ہیں کیونکہ یہ اضافی CPU سائیکل اور نیٹ ورک بینڈوتھ استعمال کرتا ہے۔
• n-AZ، n-کاپی سیٹ اپ، (n>1) کے لیے، زندہ رہنے والے n-1 دستیابی والے زونز کو nth شارڈ کاپی کے ساتھ مختص کیا جاتا ہے، جو کہ ناپسندیدہ ہو سکتا ہے کیونکہ یہ شارڈ کی تقسیم میں کمی کا سبب بن سکتا ہے، جس کے نتیجے میں یہ بھی ہو سکتا ہے نوڈس میں غیر متوازن ٹریفک۔ یہ نوڈس اوورلوڈ ہو سکتے ہیں، جو مزید ناکامیوں کا باعث بنتے ہیں۔

جزوی زون کی ناکامی۔

جزوی زون کی ناکامی کی صورت میں یا جب ڈومین دستیابی زون میں صرف کچھ نوڈس کھو دیتا ہے، Amazon OpenSearch سروس ناکام نوڈس کو جلد از جلد تبدیل کرنے کی کوشش کرتی ہے۔ تاہم، اگر نوڈس کو تبدیل کرنے میں بہت زیادہ وقت لگتا ہے، تو OpenSearch اس زون کے غیر تفویض کردہ شارڈز کو Availability Zone میں بچ جانے والے نوڈس میں مختص کرنے کی کوشش کرتا ہے۔ اگر سروس متاثرہ Availability Zone میں نوڈس کو تبدیل نہیں کرسکتی ہے، تو یہ انہیں دوسرے کنفیگرڈ Availability Zone میں مختص کرسکتی ہے، جو زون کے اندر اور اس کے اندر شارڈز کی تقسیم کو مزید متزلزل کرسکتی ہے۔ اس کے دوبارہ غیر ارادی نتائج نکلتے ہیں۔

• اگر ڈومین پر نوڈس کے پاس اضافی شارڈز کو ایڈجسٹ کرنے کے لیے کافی ذخیرہ کرنے کی جگہ نہیں ہے، تو ڈومین تحریری طور پر بلاک کیا جا سکتا ہے، جس سے انڈیکسنگ آپریشن متاثر ہوتا ہے۔
• شارڈز کی ترچھی تقسیم کی وجہ سے، ڈومین کو تمام نوڈس پر متوازی ٹریفک کا سامنا بھی ہو سکتا ہے، جو پڑھنے اور لکھنے کے آپریشنز کے لیے تاخیر یا ٹائم آؤٹ کو مزید بڑھا سکتا ہے۔

شفایابی

آج، ڈومین کی مطلوبہ نوڈ کی گنتی کو برقرار رکھنے کے لیے، Amazon OpenSearch سروس نے باقی صحت مند دستیابی زونز میں ڈیٹا نوڈز شروع کیے ہیں، جیسا کہ اوپر ناکامی کے سیکشن میں بیان کیے گئے منظرناموں کی طرح ہے۔ اس طرح کے واقعے کے بعد تمام دستیابی زونز میں نوڈ کی مناسب تقسیم کو یقینی بنانے کے لیے، AWS کو دستی مداخلت کی ضرورت تھی۔

کیا بدل رہا ہے

مجموعی طور پر ناکامی سے نمٹنے اور ڈومین کی صحت اور کارکردگی پر ناکامی کے اثرات کو کم کرنے کے لیے، Amazon OpenSearch سروس درج ذیل تبدیلیاں کر رہی ہے:

• جبری زون بیداری: OpenSearch میں پہلے سے موجود شارڈ بیلنسنگ کنفیگریشن ہے جسے جبری آگاہی کہا جاتا ہے جو دستیابی زونز کو سیٹ کرنے کے لیے استعمال کیا جاتا ہے جن میں شارڈز کو مختص کرنے کی ضرورت ہوتی ہے۔ مثال کے طور پر، اگر آپ کے پاس ایک آگاہی وصف ہے جسے زون کہتے ہیں اور نوڈس کو ترتیب دیں۔ zone1 اور zone2اگر صرف ایک زون دستیاب ہو تو آپ OpenSearch کو نقلیں مختص کرنے سے روکنے کے لیے جبری آگاہی کا استعمال کر سکتے ہیں:

cluster.routing.allocation.awareness.attributes: zone
cluster.routing.allocation.awareness.force.zone.values: zone1,zone2

اس مثال کی ترتیب کے ساتھ، اگر آپ دو نوڈس کے ساتھ شروع کرتے ہیں node.attr.zone تیار zone1 اور پانچ شارڈز اور ایک نقل کے ساتھ ایک انڈیکس بنائیں، OpenSearch انڈیکس بناتا ہے اور پانچ بنیادی شارڈز مختص کرتا ہے لیکن کوئی نقل نہیں۔ نقلیں صرف ایک بار نوڈس کے ساتھ مختص کی جاتی ہیں۔ node.attr.zone تیار zone2 دستیاب ہیں.

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

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

نوٹ کہ کوئی بھی غیر تفویض کردہ پرائمری کلسٹر کو کسی بھی آسنن ڈیٹا کے نقصان سے روکنے کے لیے اوورلوڈ نوڈ پر کاپی کی اجازت ہوگی۔

اسی طرح، دستی ریکوری کے مسئلے کو حل کرنے کے لیے (جیسا کہ اوپر ریکوری سیکشن میں بیان کیا گیا ہے)، Amazon OpenSearch سروس اپنے اندرونی اسکیلنگ جزو میں بھی تبدیلیاں کر رہی ہے۔ نئی تبدیلیوں کے ساتھ، Amazon OpenSearch سروس بقیہ دستیابی زونز میں نوڈس شروع نہیں کرے گی یہاں تک کہ جب یہ پہلے بیان کردہ ناکامی کے منظر نامے سے گزر رہی ہو۔

موجودہ اور نئے طرز عمل کا تصور کرنا

مثال کے طور پر، ایک Amazon OpenSearch سروس کا ڈومین 3-AZ، 6 ڈیٹا نوڈس، 12 پرائمری شارڈز، اور 24 ریپلیکا شارڈز کے ساتھ ترتیب دیا گیا ہے۔ ڈومین AZ-1، AZ-2، اور AZ-3 میں فراہم کیا گیا ہے، ہر ایک زون میں دو نوڈس کے ساتھ۔

موجودہ شارڈ مختص:
شارڈز کی کل تعداد: 12 پرائمری + 24 ریپلیکا = 36 شارڈز
دستیابی والے علاقوں کی تعداد: 3
فی زون شارڈز کی تعداد (زون کی آگاہی درست ہے): 36/3 = 12
نوڈس کی تعداد فی دستیابی زون: 2
فی نوڈ شارڈز کی تعداد: 12/2 = 6

درج ذیل خاکہ ڈومین سیٹ اپ کی بصری نمائندگی فراہم کرتا ہے۔ حلقے نوڈ کے لیے مختص شارڈز کی گنتی کو ظاہر کرتے ہیں۔ ایمیزون اوپن سرچ سروس فی نوڈ چھ شارڈز مختص کرے گی۔

جزوی زون کی ناکامی کے دوران، جہاں AZ-3 میں ایک نوڈ ناکام ہوجاتا ہے، ناکام نوڈ کو باقی زون میں تفویض کیا جاتا ہے، اور زون میں موجود شارڈز کو دستیاب نوڈس کی بنیاد پر دوبارہ تقسیم کیا جاتا ہے۔ اوپر بیان کردہ تبدیلیوں کے بعد، کلسٹر کوئی نیا نوڈ نہیں بنائے گا یا نوڈ کی ناکامی کے بعد شارڈز کو دوبارہ تقسیم نہیں کرے گا۔

اوپر دیے گئے خاکے میں، AZ-3 میں ایک نوڈ کے کھو جانے کے ساتھ، Amazon OpenSearch سروس اسی زون میں متبادل صلاحیت شروع کرنے کی کوشش کرے گی۔ تاہم، کچھ بندش کی وجہ سے، زون خراب ہو سکتا ہے اور متبادل کو شروع کرنے میں ناکام ہو جائے گا۔ ایسی صورت میں، سروس کسی دوسرے صحت مند زون میں خسارے کی صلاحیت کو شروع کرنے کی کوشش کرتی ہے، جو دستیابی والے علاقوں میں زون کے عدم توازن کا باعث بن سکتی ہے۔ متاثرہ زون پر شارڈز اسی زون میں زندہ بچ جانے والے نوڈ پر بھرے جاتے ہیں۔ تاہم، نئے رویے کے ساتھ، سروس اسی زون میں صلاحیت کو شروع کرنے کی کوشش کرے گی لیکن عدم توازن سے بچنے کے لیے دوسرے زون میں خسارے کی صلاحیت کو شروع کرنے سے گریز کرے گی۔ شارڈ ایلوکیٹر اس بات کو بھی یقینی بنائے گا کہ بچ جانے والے نوڈس اوورلوڈ نہ ہوں۔

اسی طرح، اگر AZ-3 میں تمام نوڈس گم ہو جائیں، یا AZ-3 خراب ہو جائے تو، Amazon OpenSearch سروس کھوئے ہوئے نوڈس کو باقی دستیابی زون میں لاتی ہے اور نوڈس پر شارڈز کو دوبارہ تقسیم کرتی ہے۔ تاہم، نئی تبدیلیوں کے بعد، Amazon OpenSearch سروس نہ تو باقی زون میں نوڈس مختص کرے گی اور نہ ہی وہ کھوئے ہوئے شارڈز کو باقی زون میں دوبارہ مختص کرنے کی کوشش کرے گی۔ Amazon OpenSearch سروس ریکوری ہونے اور ڈومین کے ریکوری کے بعد اصل کنفیگریشن پر واپس آنے کا انتظار کرے گی۔

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

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

تم کیا کر سکتے ہو

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

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

ان نئی تبدیلیوں کو اپنے ڈومین پر لاگو کرنے کے لیے اپنے Amazon OpenSearch Service کے ڈومین کے سروس سافٹ ویئر کو اپ ڈیٹ کریں۔ سروس سافٹ ویئر اپ ڈیٹ کے عمل کے بارے میں مزید تفصیلات میں ہیں۔ ایمیزون اوپن سرچ سروس دستاویزات.

نتیجہ

اس پوسٹ میں ہم نے دیکھا کہ ایمیزون اوپن سرچ سروس نے حال ہی میں زونل بندش کے دوران دستیابی زونز میں نوڈس اور شارڈز کو تقسیم کرنے کی منطق کو کس طرح بہتر بنایا ہے۔

یہ تبدیلی سروس کو نوڈ یا زونل ناکامیوں کے دوران مزید مستقل اور قابل پیشن گوئی کارکردگی کو یقینی بنانے میں مدد کرے گی۔ ڈومینز رائٹ اور ریڈز کی پروسیسنگ کے دوران کوئی بڑھتی ہوئی تاخیر یا لکھنے والے بلاکس کو نہیں دیکھ پائیں گے، جو نوڈس پر شارڈز کے زیادہ مختص ہونے کی وجہ سے پہلے کبھی کبھی سامنے آتے تھے۔

مصنفین کے بارے میں

بختاور خان ایمیزون اوپن سرچ سروس پر کام کرنے والا ایک سینئر سافٹ ویئر انجینئر ہے۔ وہ تقسیم شدہ اور خود مختار نظاموں میں دلچسپی رکھتا ہے۔ وہ OpenSearch میں ایک فعال شراکت دار ہے۔

انشو اگروال Amazon Web Services میں AWS OpenSearch پر کام کرنے والا ایک سینئر سافٹ ویئر انجینئر ہے۔ وہ توسیع پذیر اور انتہائی قابل اعتماد نظاموں کی تعمیر سے متعلق مسائل کو حل کرنے کے بارے میں پرجوش ہے۔

شوریہ دتہ بسواس ایمیزون ویب سروسز پر AWS OpenSearch پر کام کرنے والا ایک سافٹ ویئر انجینئر ہے۔ وہ انتہائی لچکدار تقسیم شدہ نظاموں کی تعمیر کے بارے میں پرجوش ہے۔

رشاب ناہٹا ایمیزون ویب سروسز پر اوپن سرچ پر کام کرنے والا ایک سافٹ ویئر انجینئر ہے۔ وہ تقسیم شدہ نظاموں میں مسائل کو حل کرنے کے بارے میں متوجہ ہے۔ وہ OpenSearch میں فعال شراکت دار ہے۔

رنجیت رام چندر ایک انجینئرنگ مینیجر ہے جو Amazon Web Services میں Amazon OpenSearch سروس پر کام کر رہا ہے۔

جون ہینڈلر AWS سرچ ٹیکنالوجیز - Amazon CloudSearch، اور Amazon OpenSearch سروس میں مہارت رکھنے والے ایک سینئر پرنسپل سولیوشن آرکیٹیکٹ ہیں۔ پالو آلٹو کی بنیاد پر، وہ صارفین کی ایک وسیع رینج کو ان کی تلاش اور لاگ انالیٹکس ورک بوجھ کو صحیح طریقے سے تعینات کرنے اور اچھی طرح سے کام کرنے میں مدد کرتا ہے۔

• SEO سے چلنے والا مواد اور PR کی تقسیم۔ آج ہی بڑھا دیں۔
• پلیٹو بلاک چین۔ Web3 Metaverse Intelligence. علم میں اضافہ۔ یہاں تک رسائی حاصل کریں۔
• ماخذ: https://aws.amazon.com/blogs/big-data/impact-of-infrastructure-failures-on-shard-in-amazon-opensearch-service/