اعلی دستیابی کے لیے Amazon OpenSearch سروس کو ترتیب دیں۔ ایمیزون ویب سروسز

اعلی دستیابی کے لیے Amazon OpenSearch سروس کو ترتیب دیں۔ ایمیزون ویب سروسز

ٹائم سٹیمپ: 31 مئی 2023 شام 12:56 بجے
ماخذ نوڈ: 2691649

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

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

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

آئیے آپ کے لیے دستیاب آپشنز کو دیکھتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ ڈومین دستیاب ہے اور پرفارمنس ہے۔

کلسٹر کنفیگریشن

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

ملٹی AZ تعیناتی۔

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

سرشار کلسٹر مینیجر (ماسٹر نوڈس)

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

درج ذیل جدول CM کے سائز کے لیے AWS کی سفارشات دکھاتا ہے۔ CM نوڈس نوڈس کی تعداد، اشاریہ جات، شارڈز اور نقشہ سازی کی بنیاد پر کام کرتے ہیں۔ جتنا زیادہ کام، آپ کو کلسٹر سٹیٹ کے ساتھ رکھنے اور کام کرنے کے لیے اتنی ہی زیادہ کمپیوٹ اور میموری کی ضرورت ہوگی۔

مثال کی گنتی کلسٹر مینیجر نوڈ رام سائز زیادہ سے زیادہ تائید شدہ شارڈ کاؤنٹ تجویز کردہ کم از کم وقف شدہ کلسٹر مینیجر مثال کی قسم
1 10 8 جیبی 10,000 m5.large.search یا m6g.large.search
11 30 16 جیبی 30,000 c5.2xlarge.search یا c6g.2xlarge.search
31 75 32 جیبی 40,000 c5.4xlarge.search یا c6g.4xlarge.search
76 - 125 64 جیبی 75,000 r5.2xlarge.search یا r6g.2xlarge.search
126 - 200 128 جیبی 75,000 r5.4xlarge.search یا r6g.4xlarge.search

اشاریہ جات اور شارڈز

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

کلسٹر نگرانی اور انتظام

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

سی پی یو استعمال۔

آپ اپنے کام کا بوجھ چلانے کے لیے اپنے ڈومین میں CPU استعمال کرتے ہیں۔ عام اصول کے طور پر، آپ کو کسی بھی ڈیٹا نوڈ کے لیے 60% اوسط CPU استعمال کا ہدف بنانا چاہیے، جس کی چوٹی 80% ہے، اور چھوٹے اسپائکس کو 100% تک برداشت کرنا چاہیے۔ جب آپ دستیابی پر غور کرتے ہیں، اور خاص طور پر پورے زون کی عدم دستیابی پر غور کرتے ہیں، تو دو منظرنامے ہوتے ہیں۔ اگر آپ کے پاس دو دستیابی زون ہیں، تو ہر زون 50% ٹریفک کو ہینڈل کرتا ہے۔ اگر ایک زون دستیاب نہیں ہوتا ہے، تو دوسرا زون سی پی یو کے استعمال کو دوگنا کرتے ہوئے اس تمام ٹریفک کو لے جائے گا۔ اس صورت میں، آپ کو دستیابی کو برقرار رکھنے کے لیے ہر زون میں تقریباً 30-40% اوسط CPU استعمال کرنے کی ضرورت ہے۔ اگر آپ تین دستیابی زون چلا رہے ہیں، تو ہر زون 33% ٹریفک لے رہا ہے۔ اگر ایک زون دستیاب نہیں ہوتا ہے، تو ایک دوسرے زون کو تقریباً 17% ٹریفک حاصل ہو گا۔ اس صورت میں، آپ کو 50-60% اوسط CPU استعمال کا ہدف بنانا چاہیے۔

میموری کا استعمال

اوپن سرچ سروس دو قسم کے کوڑا کرکٹ جمع کرنے کی حمایت کرتی ہے۔ پہلا G1 کچرا جمع کرنا (G1GC) ہے، جو OpenSearch سروس نوڈس کے ذریعے استعمال ہوتا ہے، AWS Graviton 2. دوسرا کنکرنٹ مارک سویپ (CMS) ہے، جو دوسرے پروسیسرز کے ذریعے چلنے والے تمام نوڈس کے ذریعے استعمال ہوتا ہے۔ نوڈ کے لیے مختص کردہ تمام میموری میں سے آدھی میموری (32 جی بی تک) جاوا ہیپ کو تفویض کی جاتی ہے، اور باقی میموری آپریٹنگ سسٹم کے دیگر کاموں، فائل سسٹم کیش وغیرہ کے لیے استعمال ہوتی ہے۔ ڈومین کی دستیابی کو برقرار رکھنے کے لیے، ہم تجویز کرتے ہیں کہ زیادہ سے زیادہ JVM استعمال کو CMS میں تقریباً 80% اور G95GC میں 1% رکھیں۔ اس سے آگے کی کوئی بھی چیز آپ کے ڈومین کی دستیابی کو متاثر کرے گی اور آپ کے کلسٹر کو غیر صحت بخش بنا دے گی۔ ہم آٹو ٹیون کو فعال کرنے کی بھی تجویز کرتے ہیں، جو میموری کے استعمال کو فعال طور پر مانیٹر کرتا ہے اور کوڑا اٹھانے والے کو متحرک کرتا ہے۔

اسٹوریج کا استعمال

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

AWS ایک پرائمری شارڈ کی گنتی کا انتخاب کرنے کی بھی تجویز کرتا ہے تاکہ ہر شارڈ ایک بہترین سائز کے بینڈ کے اندر ہو۔ آپ اپنے ڈیٹا اور ٹریفک کے ساتھ ثبوت کے تصور کی جانچ کے ذریعے زیادہ سے زیادہ شارڈ سائز کا تعین کر سکتے ہیں۔ ہم تلاش کے استعمال کے کیسز کے لیے 10–30 GB پرائمری شارڈ سائز اور لاگ اینالیٹکس کے استعمال کے کیسز کے لیے 45–50 GB پرائمری شارڈ سائز بطور گائیڈ لائن استعمال کرتے ہیں۔ چونکہ شارڈز آپ کے ڈومین میں کارکن ہیں، وہ ڈیٹا نوڈس میں کام کے بوجھ کی تقسیم کے براہ راست ذمہ دار ہیں۔ اگر آپ کے شارڈز بہت بڑے ہیں، تو آپ کو اپنے جاوا ہیپ میں بڑے مجموعوں، خراب استفسار کی کارکردگی، اور کلسٹر سطح کے کاموں جیسے شارڈ ری بیلنسنگ، سنیپ شاٹس، اور گرم سے گرم منتقلی پر بدتر کارکردگی دیکھ سکتے ہیں۔ اگر آپ کے شارڈز بہت چھوٹے ہیں، تو وہ ڈومین کی جاوا ہیپ اسپیس کو زیر کر سکتے ہیں، ضرورت سے زیادہ اندرونی نیٹ ورکنگ کے ذریعے استفسار کی کارکردگی کو خراب کر سکتے ہیں، اور کلسٹر سطح کے کاموں کو سست بنا سکتے ہیں۔ ہم شارڈ فی نوڈ کی تعداد کو دستیاب ہیپ کے متناسب رکھنے کی بھی تجویز کرتے ہیں (مثال کی نصف RAM 32 GB تک) — 25 شارڈز فی GB جاوا ہیپ۔ یہ آپ کے ڈومین میں کسی بھی ڈیٹا نوڈ پر 1,000 شارڈز کی عملی حد بناتا ہے۔

نتیجہ

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

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

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

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

پرشانت اگروال Amazon OpenSearch سروس کے ساتھ ایک Sr. Search Specialist Solutions آرکیٹیکٹ ہے۔ وہ گاہکوں کے ساتھ مل کر کام کرتا ہے تاکہ وہ اپنے کام کے بوجھ کو کلاؤڈ پر منتقل کر سکیں اور موجودہ صارفین کو بہتر کارکردگی حاصل کرنے اور لاگت کو بچانے کے لیے اپنے کلسٹرز کو ٹھیک کرنے میں مدد کریں۔ AWS میں شامل ہونے سے پہلے، اس نے مختلف صارفین کو ان کی تلاش اور لاگ اینالیٹکس کے استعمال کے معاملات کے لیے OpenSearch اور Elasticsearch استعمال کرنے میں مدد کی۔ کام نہ کرنے پر، آپ اسے سفر کرتے اور نئی جگہوں کی تلاش کرتے ہوئے پا سکتے ہیں۔ مختصراً، وہ کھانا → سفر → دہرانا پسند کرتا ہے۔

ٹائم اسٹیمپ:

سے زیادہ AWS بگ ڈیٹا