ہیلو، حبر! میں Artem Karamyshev ہوں، سسٹم ایڈمنسٹریشن ٹیم کا سربراہ . ہمارے پاس پچھلے سال کے دوران بہت سی نئی پروڈکٹ لانچ ہوئی ہیں۔ ہم اس بات کو یقینی بنانا چاہتے تھے کہ API سروسز آسانی سے قابل توسیع، غلطی کو برداشت کرنے والی، اور صارف کے بوجھ میں تیزی سے ترقی کے لیے تیار ہوں۔ ہمارا پلیٹ فارم OpenStack پر لاگو کیا گیا ہے، اور میں آپ کو بتانا چاہتا ہوں کہ فالٹ ٹولرنٹ سسٹم حاصل کرنے کے لیے ہمیں کون سے اجزاء کی غلطی برداشت کرنے کے مسائل حل کرنے تھے۔ میرے خیال میں یہ ان لوگوں کے لیے دلچسپ ہوگا جو OpenStack پر بھی مصنوعات تیار کرتے ہیں۔
پلیٹ فارم کی مجموعی غلطی کی رواداری اس کے اجزاء کی لچک پر مشتمل ہوتی ہے۔ لہذا ہم آہستہ آہستہ ان تمام سطحوں سے گزریں گے جہاں ہم نے خطرات کی نشاندہی کی اور انہیں بند کیا۔
اس کہانی کا ویڈیو ورژن، جس کا بنیادی ذریعہ اپ ٹائم ڈے 4 کانفرنس کی ایک رپورٹ تھی، جس کا اہتمام کیا گیا تھا۔ ، آپ دیکھ سکتے ہیں .
جسمانی فن تعمیر کی لچک
MCS کلاؤڈ کا عوامی حصہ اب دو ٹائر III ڈیٹا سینٹرز پر مبنی ہے، ان کے درمیان اس کا اپنا ڈارک فائبر ہے، جو جسمانی سطح پر مختلف راستوں سے محفوظ ہے، جس کا تھرو پٹ 200 Gbit/s ہے۔ ٹائر III فزیکل انفراسٹرکچر کے لیے فالٹ ٹولرنس کی ضروری سطح فراہم کرتا ہے۔
ڈارک فائبر جسمانی اور منطقی دونوں سطحوں پر محفوظ ہے۔ چینل ریزرویشن کا عمل تکراری تھا، مسائل پیدا ہوئے، اور ہم ڈیٹا سینٹرز کے درمیان رابطے کو مسلسل بہتر کر رہے ہیں۔
مثال کے طور پر، کچھ عرصہ پہلے، ڈیٹا سینٹرز میں سے ایک کے قریب ایک کنویں میں کام کرتے ہوئے، ایک کھدائی کرنے والے نے ایک پائپ توڑ دیا، اور اس پائپ کے اندر ایک مین اور بیک اپ آپٹیکل کیبل دونوں موجود تھے۔ ڈیٹا سینٹر کے ساتھ ہمارا غلطی برداشت کرنے والا مواصلاتی چینل کنویں میں ایک موقع پر کمزور نکلا۔ اس کے مطابق، ہم نے انفراسٹرکچر کا کچھ حصہ کھو دیا ہے۔ ہم نے نتیجہ اخذ کیا اور متعدد کارروائیاں کیں، بشمول ملحقہ کنویں میں اضافی آپٹکس نصب کرنا۔
ڈیٹا سینٹرز میں کمیونیکیشن فراہم کرنے والوں کی موجودگی کے پوائنٹس ہیں جن کو ہم BGP کے ذریعے اپنے سابقے نشر کرتے ہیں۔ ہر نیٹ ورک کی سمت کے لیے، بہترین میٹرک کا انتخاب کیا جاتا ہے، جو مختلف کلائنٹس کو بہترین کنکشن کے معیار کے ساتھ فراہم کرنے کی اجازت دیتا ہے۔ اگر ایک فراہم کنندہ کے ذریعے مواصلت کم ہوجاتی ہے، تو ہم دستیاب فراہم کنندگان کے ذریعے اپنی روٹنگ کو دوبارہ بناتے ہیں۔
اگر کوئی فراہم کنندہ ناکام ہو جاتا ہے، تو ہم خود بخود اگلے پر سوئچ کر دیتے ہیں۔ ڈیٹا سینٹرز میں سے کسی ایک کی ناکامی کی صورت میں، ہمارے پاس دوسرے ڈیٹا سینٹر میں ہماری خدمات کی عکس کاپی ہوتی ہے، جو پورا بوجھ اٹھاتی ہے۔
فزیکل انفراسٹرکچر کی لچک
جو ہم ایپلیکیشن لیول فالٹ ٹولرنس کے لیے استعمال کرتے ہیں۔
ہماری سروس کئی اوپن سورس اجزاء پر بنائی گئی ہے۔
ExaBGP ایک ایسی خدمت ہے جو BGP پر مبنی ڈائنامک روٹنگ پروٹوکول کا استعمال کرتے ہوئے متعدد افعال کو نافذ کرتی ہے۔ ہم اسے فعال طور پر اپنے وائٹ لسٹ کردہ IP پتوں کی تشہیر کے لیے استعمال کرتے ہیں جن کے ذریعے صارف API تک رسائی حاصل کرتے ہیں۔
HAPROxy ایک ہائی-لوڈ بیلنسر ہے جو آپ کو OSI ماڈل کی مختلف سطحوں پر بہت لچکدار ٹریفک بیلنسنگ رولز ترتیب دینے کی اجازت دیتا ہے۔ ہم اسے تمام سروسز کے سامنے توازن کے لیے استعمال کرتے ہیں: ڈیٹا بیس، میسج بروکرز، API سروسز، ویب سروسز، ہمارے اندرونی پروجیکٹس - سب کچھ HAProxy کے پیچھے ہے۔
API ایپلیکیشن python میں لکھی گئی ایک ویب ایپلیکیشن، جس کے ساتھ صارف اپنے انفراسٹرکچر اور اپنی سروس کا انتظام کرتا ہے۔
کارکن کی درخواست (اس کے بعد صرف ورکر) - اوپن اسٹیک سروسز میں، یہ ایک انفراسٹرکچر ڈیمون ہے جو آپ کو انفراسٹرکچر میں API کمانڈز براڈکاسٹ کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، ڈسک کی تخلیق کارکن میں ہوتی ہے، اور تخلیق کی درخواست ایپلی کیشن API میں ہوتی ہے۔
معیاری اوپن اسٹیک ایپلیکیشن آرکیٹیکچر
زیادہ تر خدمات جو OpenStack کے لیے تیار کی گئی ہیں ایک ہی پیراڈائم پر عمل کرنے کی کوشش کرتی ہیں۔ ایک سروس عام طور پر 2 حصوں پر مشتمل ہوتی ہے: API اور کارکنان (بیک اینڈ ایگزیکیوٹرز)۔ ایک اصول کے طور پر، ایک API python میں ایک WSGI ایپلی کیشن ہے، جسے یا تو ایک آزاد عمل (ڈیمون) کے طور پر لانچ کیا جاتا ہے، یا ایک ریڈی میڈ Nginx یا Apache ویب سرور کا استعمال کرتے ہوئے کیا جاتا ہے۔ API صارف کی درخواست پر کارروائی کرتا ہے اور عمل درآمد کے لیے کارکن کی درخواست کو مزید ہدایات دیتا ہے۔ ٹرانسفر میسج بروکر کا استعمال کرتے ہوئے ہوتا ہے، عام طور پر RabbitMQ، دوسرے ناقص تعاون یافتہ ہیں۔ جب پیغامات بروکر تک پہنچتے ہیں، تو کارکنان ان پر کارروائی کرتے ہیں اور اگر ضروری ہو تو جواب واپس کرتے ہیں۔
اس تمثیل میں ناکامی کے الگ تھلگ مشترکہ نکات شامل ہیں: RabbitMQ اور ڈیٹا بیس۔ لیکن RabbitMQ ایک سروس کے اندر الگ تھلگ ہے اور اصولی طور پر، ہر سروس کے لیے انفرادی ہو سکتا ہے۔ لہذا MCS میں ہم ان خدمات کو ہر ایک پراجیکٹ کے لیے الگ الگ ڈیٹا بیس بناتے ہیں، ایک علیحدہ RabbitMQ۔ یہ نقطہ نظر اچھا ہے کیونکہ کچھ خطرناک مقامات پر حادثے کی صورت میں، پوری سروس نہیں ٹوٹتی، بلکہ اس کا صرف ایک حصہ۔
ورکر ایپلی کیشنز کی تعداد لامحدود ہے، لہذا کارکردگی اور غلطی کو برداشت کرنے کے لیے API آسانی سے بیلنسرز کے پیچھے افقی طور پر پیمائش کر سکتا ہے۔
جب APIs اور کارکنوں کے درمیان پیچیدہ ترتیب وار کارروائیاں ہوتی ہیں تو کچھ خدمات کو سروس کے اندر ہم آہنگی کی ضرورت ہوتی ہے۔ اس معاملے میں، ایک سنگل کوآرڈینیشن سینٹر استعمال کیا جاتا ہے، ایک کلسٹر سسٹم جیسے Redis، Memcache، etcd، جو ایک کارکن کو دوسرے کارکن کو بتانے کی اجازت دیتا ہے کہ یہ کام اسے تفویض کیا گیا ہے ("براہ کرم اسے نہ لیں")۔ ہم وغیرہ استعمال کرتے ہیں۔ ایک اصول کے طور پر، کارکن فعال طور پر ڈیٹا بیس کے ساتھ بات چیت کرتے ہیں، وہاں سے معلومات لکھتے اور پڑھتے ہیں۔ ہم mariadb کو ایک ڈیٹا بیس کے طور پر استعمال کرتے ہیں، جو کہ ایک ملٹی ماسٹر کلسٹر میں واقع ہے۔
یہ کلاسک سنگل سروس اس انداز میں ترتیب دی گئی ہے جسے عام طور پر OpenStack کے لیے قبول کیا جاتا ہے۔ اسے ایک بند نظام کے طور پر سمجھا جا سکتا ہے، جس کے لیے پیمانے اور فالٹ ٹولرنس کے طریقے بالکل واضح ہیں۔ مثال کے طور پر، API فالٹ ٹولرنس کے لیے، ان کے سامنے ایک بیلنس رکھنا کافی ہے۔ سکیلنگ کارکنوں کی تعداد میں اضافہ کرکے حاصل کیا جاتا ہے۔
پوری اسکیم کا کمزور نقطہ RabbitMQ اور MariaDB ہے۔ ان کا فن تعمیر ایک الگ مضمون کا مستحق ہے اس مضمون میں میں API فالٹ ٹولرنس پر توجہ مرکوز کرنا چاہتا ہوں۔
اوپن اسٹیک ایپلیکیشن آرکیٹیکچر۔ کلاؤڈ پلیٹ فارم کا توازن اور غلطی کی رواداری
ExaBGP کا استعمال کرتے ہوئے HAProxy بیلنس کو غلطی سے برداشت کرنے والا بنانا
اپنے APIs کو قابل توسیع، تیز اور غلطی سے برداشت کرنے کے لیے، ہم ان کے سامنے لوڈ بیلنسر رکھتے ہیں۔ ہم نے HAProxy کا انتخاب کیا۔ میری رائے میں، اس میں ہمارے کام کے لیے تمام ضروری خصوصیات ہیں: متعدد OSI سطحوں پر توازن، ایک انتظامی انٹرفیس، لچک اور اسکیل ایبلٹی، بڑی تعداد میں توازن کے طریقے، سیشن ٹیبلز کے لیے معاونت۔
پہلا مسئلہ جس کو حل کرنے کی ضرورت تھی وہ خود بیلنسر کی غلطی برداشت تھی۔ بس ایک بیلنسر انسٹال کرنا بھی ناکامی کا ایک نقطہ پیدا کرتا ہے: بیلنس ٹوٹ جاتا ہے اور سروس کریش ہو جاتی ہے۔ ایسا ہونے سے روکنے کے لیے، ہم نے ExaBGP کے ساتھ مل کر HAProxy کا استعمال کیا۔
ExaBGP آپ کو سروس کی حالت جانچنے کے لیے ایک طریقہ کار کو نافذ کرنے کی اجازت دیتا ہے۔ ہم نے اس طریقہ کار کو HAProxy کی فعالیت کو جانچنے کے لیے استعمال کیا اور، مسائل کی صورت میں، BGP سے HAProxy سروس کو غیر فعال کر دیا۔
ExaBGP+HAProxy اسکیم
- ہم تین سرورز پر ضروری سافٹ ویئر ExaBGP اور HAProxy انسٹال کرتے ہیں۔
- ہم ہر سرور پر ایک لوپ بیک انٹرفیس بناتے ہیں۔
- تینوں سرورز پر ہم اس انٹرفیس کو ایک ہی سفید IP ایڈریس تفویض کرتے ہیں۔
- ایک سفید IP ایڈریس ExaBGP کے ذریعے انٹرنیٹ پر مشتہر کیا جاتا ہے۔
تینوں سرورز سے ایک ہی IP ایڈریس کی تشہیر کرکے غلطی برداشت کی جاتی ہے۔ نیٹ ورک کے نقطہ نظر سے، ایک ہی پتہ تین مختلف اگلے ہاپس سے قابل رسائی ہے۔ راؤٹر تین ایک جیسے راستوں کو دیکھتا ہے، اپنے میٹرک کی بنیاد پر ان میں سے سب سے زیادہ ترجیح کا انتخاب کرتا ہے (یہ عام طور پر ایک ہی آپشن ہوتا ہے)، اور ٹریفک صرف ایک سرور پر جاتی ہے۔
HAProxy کے آپریشن یا سرور کی خرابی کے ساتھ مسائل کی صورت میں، ExaBGP روٹ کا اعلان کرنا بند کر دیتا ہے، اور ٹریفک آسانی سے دوسرے سرور پر چلا جاتا ہے۔
اس طرح، ہم نے بیلنسر کی غلطی کی رواداری حاصل کی۔
HAProxy بیلنسرز کی غلطی کی رواداری
اسکیم نامکمل نکلی: ہم نے HAProxy کو محفوظ کرنے کا طریقہ سیکھا، لیکن خدمات کے اندر بوجھ کو تقسیم کرنے کا طریقہ نہیں سیکھا۔ لہذا، ہم نے اس اسکیم کو تھوڑا سا بڑھایا: ہم کئی سفید IP پتوں کے درمیان توازن کی طرف بڑھے۔
DNS پلس BGP پر مبنی توازن
ہمارے HAProxy کے لیے لوڈ بیلنسنگ کا مسئلہ حل طلب ہے۔ تاہم، اسے کافی آسانی سے حل کیا جا سکتا ہے، جیسا کہ ہم نے یہاں کیا ہے۔
تین سرورز کو متوازن کرنے کے لیے آپ کو 3 سفید IP پتے اور اچھے پرانے DNS کی ضرورت ہوگی۔ ان میں سے ہر ایک پتے کا تعین ہر HAProxy کے لوپ بیک انٹرفیس پر کیا جاتا ہے اور انٹرنیٹ پر اشتہار دیا جاتا ہے۔
OpenStack میں، وسائل کو منظم کرنے کے لیے، ایک سروس ڈائرکٹری استعمال کی جاتی ہے، جو کسی خاص سروس کے اینڈ پوائنٹ API کی وضاحت کرتی ہے۔ اس ڈائرکٹری میں ہم ایک ڈومین نام - public.infra.mail.ru رجسٹر کرتے ہیں، جسے DNS کے ذریعے تین مختلف IP پتوں سے حل کیا جاتا ہے۔ نتیجے کے طور پر، ہمیں DNS کے ذریعے تین پتوں کے درمیان لوڈ کی تقسیم ملتی ہے۔
لیکن چونکہ سفید IP پتوں کا اعلان کرتے وقت ہم سرور کے انتخاب کی ترجیحات کو کنٹرول نہیں کرتے ہیں، اس لیے یہ ابھی تک متوازن نہیں ہے۔ عام طور پر، IP ایڈریس کی سنیارٹی کی بنیاد پر صرف ایک سرور کا انتخاب کیا جائے گا، اور باقی دو بیکار ہوں گے کیونکہ BGP میں کوئی میٹرکس متعین نہیں ہیں۔
ہم نے ExaBGP کے ذریعے مختلف میٹرکس کے ساتھ روٹس بھیجنا شروع کیا۔ ہر بیلنسر تینوں سفید IP پتوں کی تشہیر کرتا ہے، لیکن ان میں سے ایک، اس بیلنس کے لیے اہم، کم از کم میٹرک کے ساتھ مشتہر کیا جاتا ہے۔ لہذا جب تینوں بیلنس کام کر رہے ہیں، پہلے آئی پی ایڈریس پر کالیں پہلے بیلنسر پر جاتی ہیں، دوسرے سے دوسرے کو کال کرتی ہیں، اور تیسرے سے تیسرے کو کال کرتی ہیں۔
جب بیلنسرز میں سے ایک گر جائے تو کیا ہوتا ہے؟ اگر کوئی بیلنسر ناکام ہوجاتا ہے، تو اس کا مرکزی پتہ اب بھی دوسرے دو سے مشتہر کیا جاتا ہے، اور ٹریفک کو ان کے درمیان دوبارہ تقسیم کیا جاتا ہے۔ اس طرح، ہم صارف کو DNS کے ذریعے ایک ساتھ کئی IP پتے دیتے ہیں۔ DNS اور مختلف میٹرکس کے ذریعے توازن قائم کرکے، ہم تینوں بیلنسرز میں بوجھ کی یکساں تقسیم حاصل کرتے ہیں۔ اور اس کے ساتھ ساتھ ہم غلطی کو برداشت نہیں کرتے۔
DNS + BGP پر مبنی HAProxy کو متوازن کرنا
ExaBGP اور HAProxy کے درمیان تعامل
لہذا، ہم نے راستوں کے اعلان کو روکنے کی بنیاد پر، سرور چھوڑنے کی صورت میں غلطی کی رواداری کو نافذ کیا۔ لیکن HAProxy سرور کی ناکامی کے علاوہ دیگر وجوہات کی بنا پر بھی بند ہو سکتا ہے: انتظامیہ کی غلطیاں، سروس میں ناکامی۔ ہم ان معاملات میں ٹوٹے ہوئے بیلنس کو بوجھ کے نیچے سے ہٹانا چاہتے ہیں، اور ہمیں ایک مختلف طریقہ کار کی ضرورت ہے۔
لہذا، پچھلی اسکیم کو بڑھاتے ہوئے، ہم نے ExaBGP اور HAProxy کے درمیان دل کی دھڑکن کو نافذ کیا۔ یہ ExaBGP اور HAProxy کے درمیان تعامل کا ایک سافٹ ویئر عمل درآمد ہے، جب ExaBGP ایپلی کیشنز کی حیثیت کو چیک کرنے کے لیے حسب ضرورت اسکرپٹ استعمال کرتا ہے۔
ایسا کرنے کے لیے، آپ کو ExaBGP کنفگریشن میں ہیلتھ چیکر کو کنفیگر کرنے کی ضرورت ہے، جو HAProxy کی حیثیت کو چیک کر سکتا ہے۔ ہمارے معاملے میں، ہم نے ہیلتھ بیک اینڈ کو HAProxy میں کنفیگر کیا ہے، اور ExaBGP کی طرف سے ہم ایک سادہ GET درخواست کے ساتھ چیک کرتے ہیں۔ اگر اعلان ہونا بند ہو جاتا ہے، تو HAProxy غالباً کام نہیں کر رہا ہے اور اس کی تشہیر کرنے کی ضرورت نہیں ہے۔
HAProxy ہیلتھ چیک
HAProxy Peers: سیشن سنکرونائزیشن
اگلا کام سیشنز کو سنکرونائز کرنا تھا۔ تقسیم شدہ بیلنسرز کے ذریعے کام کرتے وقت، کلائنٹ سیشنز کے بارے میں معلومات کے ذخیرہ کو منظم کرنا مشکل ہوتا ہے۔ لیکن HAProxy ان چند بیلنسرز میں سے ایک ہے جو Peers کی فعالیت کی وجہ سے ایسا کر سکتے ہیں - HAProxy کے مختلف عملوں کے درمیان سیشن ٹیبلز کو منتقل کرنے کی صلاحیت۔
توازن کے مختلف طریقے ہیں: سادہ جیسے ، اور بڑھا دیا جاتا ہے، جب کلائنٹ کا سیشن یاد رہتا ہے، اور ہر بار وہ پہلے کی طرح اسی سرور پر ختم ہوتا ہے۔ ہم دوسرے آپشن کو نافذ کرنا چاہتے تھے۔
HAProxy اس میکانزم کے کلائنٹ سیشنز کو بچانے کے لیے اسٹک ٹیبلز کا استعمال کرتا ہے۔ وہ کلائنٹ کا اصل IP ایڈریس، منتخب کردہ ہدف کا پتہ (بیک اینڈ) اور کچھ سروس کی معلومات کو محفوظ کرتے ہیں۔ عام طور پر، اسٹک ٹیبلز کا استعمال سورس-IP + destination-IP جوڑے کو ذخیرہ کرنے کے لیے کیا جاتا ہے، جو خاص طور پر ان ایپلی کیشنز کے لیے مفید ہے جو دوسرے بیلنس پر سوئچ کرتے وقت صارف کے سیشن سیاق و سباق کو منتقل نہیں کر سکتیں، مثال کے طور پر، RoundRobin بیلنسنگ موڈ میں۔
اگر ایک اسٹک ٹیبل کو مختلف HAProxy عملوں کے درمیان منتقل کرنا سکھایا جاتا ہے (جس کے درمیان توازن ہوتا ہے)، ہمارے بیلنسرز اسٹک ٹیبل کے ایک پول کے ساتھ کام کرنے کے قابل ہوں گے۔ اس سے کلائنٹ کے نیٹ ورک کو بغیر کسی رکاوٹ کے بدلنا ممکن ہو جائے گا اگر بیلنسرز میں سے کوئی ایک ناکام ہو جاتا ہے تو کلائنٹ کے سیشنز کے ساتھ کام اسی بیک اینڈ پر جاری رہے گا جو پہلے منتخب کیے گئے تھے۔
مناسب آپریشن کے لیے، بیلنسر کے سورس آئی پی ایڈریس کا مسئلہ جس سے سیشن قائم کیا گیا تھا کو حل کرنا ضروری ہے۔ ہمارے معاملے میں، یہ لوپ بیک انٹرفیس پر ایک متحرک پتہ ہے۔
ساتھیوں کا درست کام صرف بعض شرائط کے تحت حاصل کیا جاتا ہے۔ یعنی، TCP ٹائم آؤٹ کافی بڑا ہونا چاہیے یا سوئچنگ کافی تیز ہونی چاہیے تاکہ TCP سیشن کو ختم ہونے کا وقت نہ ملے۔ تاہم، یہ ہموار سوئچنگ کی اجازت دیتا ہے۔
IaaS میں ہمارے پاس اسی ٹیکنالوجی کا استعمال کرتے ہوئے ایک سروس بنائی گئی ہے۔ یہ ، جسے اوکٹاویا کہا جاتا ہے۔ یہ دو HAProxy عمل پر مبنی ہے اور ابتدائی طور پر ساتھیوں کے لیے تعاون شامل ہے۔ انہوں نے اس خدمت میں خود کو بہترین ثابت کیا ہے۔
تصویر منصوبہ بندی کے ساتھ تین HAProxy مثالوں کے درمیان ہم مرتبہ میزوں کی نقل و حرکت کو ظاہر کرتی ہے، ایک ترتیب تجویز کی گئی ہے کہ اسے کس طرح ترتیب دیا جا سکتا ہے:
HAProxy Peers (سیشن سنکرونائزیشن)
اگر آپ اسی اسکیم کو لاگو کرتے ہیں، تو اس کے آپریشن کو احتیاط سے جانچنا ضروری ہے۔ یہ حقیقت نہیں ہے کہ یہ 100٪ وقت میں اسی طرح کام کرے گا۔ لیکن جب آپ کو کلائنٹ کے سورس آئی پی کو یاد رکھنے کی ضرورت ہو تو کم از کم آپ اسٹک ٹیبلز سے محروم نہیں ہوں گے۔
ایک ہی کلائنٹ سے بیک وقت درخواستوں کی تعداد کو محدود کرنا
کوئی بھی خدمات جو عوامی طور پر دستیاب ہیں، بشمول ہمارے APIs، درخواستوں کے برفانی تودے سے مشروط ہو سکتی ہیں۔ ان کی وجوہات بالکل مختلف ہو سکتی ہیں، صارف کی غلطیوں سے لے کر ٹارگٹ حملوں تک۔ ہم وقتاً فوقتاً IP پتوں کے ذریعے DDoSed ہوتے ہیں۔ کلائنٹ اکثر اپنی اسکرپٹ میں غلطیاں کرتے ہیں اور ہمیں mini-DDoSs دیتے ہیں۔
ایک یا دوسرے طریقے سے، اضافی تحفظ فراہم کرنا ضروری ہے. واضح حل یہ ہے کہ API کی درخواستوں کی تعداد کو محدود کیا جائے اور نقصان دہ درخواستوں پر کارروائی کرنے میں CPU کا وقت ضائع نہ کیا جائے۔
اس طرح کی پابندیوں کو لاگو کرنے کے لیے، ہم اسی اسٹک ٹیبلز کا استعمال کرتے ہوئے، HAProxy کی بنیاد پر ترتیب دی گئی شرح کی حدیں استعمال کرتے ہیں۔ حدود کا تعین کرنا کافی آسان ہے اور آپ کو صارف کو API کی درخواستوں کی تعداد تک محدود کرنے کی اجازت دیتا ہے۔ الگورتھم سورس آئی پی کو یاد رکھتا ہے جس سے درخواستیں کی جاتی ہیں اور ایک صارف کی بیک وقت درخواستوں کی تعداد کو محدود کرتا ہے۔ بلاشبہ، ہم نے ہر سروس کے لیے اوسط API لوڈ پروفائل کا حساب لگایا اور اس قدر سے 10 گنا ≈ کی حد مقرر کی۔ ہم صورتحال پر گہری نظر رکھتے ہیں اور نبض پر انگلی رکھتے ہیں۔
عملی طور پر یہ کیسا لگتا ہے؟ ہمارے پاس ایسے صارفین ہیں جو ہر وقت ہمارے آٹو اسکیلنگ APIs کا استعمال کرتے ہیں۔ وہ صبح کے وقت تقریباً دو سے تین سو ورچوئل مشینیں بناتے ہیں اور شام کو ڈیلیٹ کر دیتے ہیں۔ OpenStack کے لیے، ایک ورچوئل مشین بنانے کے لیے، PaaS سروسز کے ساتھ، کم از کم 1000 API درخواستوں کی ضرورت ہوتی ہے، کیونکہ سروسز کے درمیان تعامل بھی API کے ذریعے ہوتا ہے۔
کاموں کی اس طرح کی منتقلی کافی بڑے بوجھ کا سبب بنتی ہے۔ ہم نے اس بوجھ کا اندازہ لگایا، روزانہ کی چوٹیوں کو جمع کیا، ان میں دس گنا اضافہ کیا، اور یہ ہماری شرح کی حد بن گئی۔ ہم نبض پر انگلی رکھتے ہیں۔ ہم اکثر ایسے بوٹس اور سکینر دیکھتے ہیں جو ہمیں دیکھنے کی کوشش کر رہے ہوتے ہیں کہ آیا ہمارے پاس کوئی سی جی اے اسکرپٹ ہے جسے چلایا جا سکتا ہے، ہم انہیں فعال طور پر کاٹ رہے ہیں۔
صارفین کو دیکھے بغیر اپنے کوڈ بیس کو کیسے اپ ڈیٹ کریں۔
ہم کوڈ کی تعیناتی کے عمل کی سطح پر بھی غلطی کو برداشت کرتے ہیں۔ رول آؤٹ کے دوران خرابیاں ہو سکتی ہیں، لیکن سروس کی دستیابی پر ان کے اثرات کو کم کیا جا سکتا ہے۔
ہم اپنی خدمات کو مسلسل اپ ڈیٹ کرتے رہتے ہیں اور اس بات کو یقینی بنانا چاہیے کہ کوڈ بیس کو صارفین کو متاثر کیے بغیر اپ ڈیٹ کیا جائے۔ ہم نے HAProxy کی انتظامی صلاحیتوں اور اپنی خدمات میں Graceful Shutdown کے نفاذ کا استعمال کرتے ہوئے اس مسئلے کو حل کرنے میں کامیاب ہو گئے۔
اس مسئلے کو حل کرنے کے لیے، یہ ضروری تھا کہ بیلنس کے کنٹرول اور خدمات کے "درست" بند کو یقینی بنایا جائے:
- HAProxy کے معاملے میں، کنٹرول اعدادوشمار کی فائل کے ذریعے انجام دیا جاتا ہے، جو کہ بنیادی طور پر ایک ساکٹ ہے اور اس کی تعریف HAProxy کی تشکیل میں کی گئی ہے۔ آپ اسے stdio کے ذریعے کمانڈ بھیج سکتے ہیں۔ لیکن ہمارا بنیادی کنفیگریشن کنٹرول ٹول قابل قبول ہے، اس لیے اس میں HAProxy کے انتظام کے لیے ایک بلٹ ان ماڈیول ہے۔ جسے ہم فعال طور پر استعمال کرتے ہیں۔
- ہماری زیادہ تر API اور انجن خدمات خوبصورت شٹ ڈاؤن ٹیکنالوجیز کو سپورٹ کرتی ہیں: بند ہونے پر، وہ موجودہ کام کے مکمل ہونے کا انتظار کرتے ہیں، چاہے وہ HTTP درخواست ہو یا کوئی سروس ٹاسک۔ مزدور کے ساتھ بھی ایسا ہی ہوتا ہے۔ یہ ان تمام کاموں کو جانتا ہے جو وہ کر رہا ہے اور اس وقت ختم ہوتا ہے جب اس نے کامیابی سے سب کچھ مکمل کر لیا ہوتا ہے۔
ان دو نکات کی بدولت، ہماری تعیناتی کے لیے محفوظ الگورتھم اس طرح نظر آتا ہے۔
- ڈویلپر کوڈ کا ایک نیا پیکج جمع کرتا ہے (ہمارے لیے یہ RPM ہے)، اسے دیو ماحول میں ٹیسٹ کرتا ہے، اسٹیج میں ٹیسٹ کرتا ہے، اور اسے اسٹیج ریپوزٹری میں چھوڑ دیتا ہے۔
- ڈیولپر "نادرات" کی سب سے تفصیلی وضاحت کے ساتھ تعیناتی کے لیے کام طے کرتا ہے: نئے پیکیج کا ورژن، نئی فعالیت کی تفصیل اور اگر ضروری ہو تو تعیناتی کے بارے میں دیگر تفصیلات۔
- سسٹم ایڈمنسٹریٹر اپ ڈیٹ شروع کرتا ہے۔ جوابی پلے بک لانچ کرتا ہے، جو بدلے میں درج ذیل کام کرتا ہے:
- اسٹیج ریپوزٹری سے ایک پیکیج لیتا ہے اور اسے پروڈکٹ ریپوزٹری میں پیکیج کے ورژن کو اپ ڈیٹ کرنے کے لیے استعمال کرتا ہے۔
- اپ ڈیٹ کردہ سروس کے بیک اینڈز کی فہرست مرتب کرتا ہے۔
- HAProxy میں اپ ڈیٹ ہونے والی پہلی سروس کو بند کر دیتا ہے اور اس کے عمل کے مکمل ہونے کا انتظار کرتا ہے۔ شاندار شٹ ڈاؤن کا شکریہ، ہمیں یقین ہے کہ کلائنٹ کی تمام موجودہ درخواستیں کامیابی سے مکمل ہو جائیں گی۔
- API اور کارکنوں کے مکمل طور پر بند ہونے کے بعد، اور HAProxy بند ہو جانے کے بعد، کوڈ کو اپ ڈیٹ کر دیا جاتا ہے۔
- جوابدہ چلانے کی خدمات۔
- ہر سروس کے لیے، مخصوص "ہینڈلز" کھینچے جاتے ہیں، جو پہلے سے طے شدہ کلیدی ٹیسٹوں کی ایک بڑی تعداد پر یونٹ ٹیسٹنگ کرتے ہیں۔ نئے کوڈ کی ایک بنیادی جانچ پڑتال ہوتی ہے۔
- اگر پچھلے مرحلے میں کوئی نقص نہیں پایا گیا تو، پسدید کو چالو کر دیا جاتا ہے۔
- آئیے اگلے بیک اینڈ پر چلتے ہیں۔
- تمام بیک اینڈز کو اپ ڈیٹ کرنے کے بعد، فنکشنل ٹیسٹ شروع کیے جاتے ہیں۔ اگر وہ غائب ہیں، تو ڈویلپر اپنی تخلیق کردہ کسی بھی نئی فعالیت کو دیکھتا ہے۔
یہ تعیناتی مکمل کرتا ہے۔
سروس اپ ڈیٹ سائیکل
یہ اسکیم کام نہیں کرے گی اگر ہمارے پاس ایک اصول نہ ہو۔ ہم جنگ میں پرانے اور نئے دونوں ورژن کی حمایت کرتے ہیں۔ پہلے سے، سافٹ ویئر ڈویلپمنٹ کے مرحلے پر، یہ طے کیا جاتا ہے کہ اگر سروس ڈیٹا بیس میں تبدیلیاں ہوں تو بھی وہ پچھلے کوڈ کو نہیں توڑیں گے۔ نتیجے کے طور پر، کوڈ بیس آہستہ آہستہ اپ ڈیٹ کیا جاتا ہے.
حاصل يہ ہوا
غلطی برداشت کرنے والے WEB فن تعمیر کے بارے میں اپنے خیالات کا اظہار کرتے ہوئے، میں ایک بار پھر اس کے اہم نکات کو نوٹ کرنا چاہوں گا:
- جسمانی غلطی کی رواداری؛
- نیٹ ورک کی خرابی رواداری (بیلنسرز، بی جی پی)؛
- استعمال شدہ اور تیار کردہ سافٹ ویئر کی غلطی کی رواداری۔
مستحکم اپ ٹائم سب!
ماخذ: www.habr.com
