هيلو، حبر! مان Artem Karamyshev آهيان، سسٽم انتظامي ٽيم جو سربراهه . اسان وٽ گذريل سال ۾ ڪيترائي نوان پراڊڪٽ لانچ ڪيا ويا آهن. اسان پڪ ڪرڻ چاهيون ٿا ته API خدمتون آساني سان اسپيبلبل، غلطي برداشت ڪندڙ، ۽ صارف جي لوڊ ۾ تيز ترقي لاء تيار آهن. اسان جو پليٽ فارم OpenStack تي لاڳو ڪيو ويو آهي، ۽ مان توهان کي ٻڌائڻ چاهيان ٿو ته اسان کي ڪهڙي جزن جي غلطي رواداري جا مسئلا حل ڪرڻا پوندا هڪ غلطي برداشت ڪندڙ نظام حاصل ڪرڻ لاءِ. منهنجو خيال آهي ته اهو انهن لاءِ دلچسپ هوندو جيڪي OpenStack تي پراڊڪٽس پڻ ٺاهيندا آهن.
پليٽ فارم جي مجموعي غلطي رواداري ان جي اجزاء جي لچڪ تي مشتمل آهي. تنهن ڪري اسان آهستي آهستي انهن سڀني سطحن مان گذري وينداسين جتي اسان خطرن جي نشاندهي ڪئي ۽ انهن کي بند ڪيو.
هن ڪهاڻي جو وڊيو نسخو، جنهن جو بنيادي ذريعو اپٽائم ڏينهن 4 ڪانفرنس ۾ هڪ رپورٽ هئي، پاران منظم ڪيل ، توهان ڏسي سگهو ٿا .
جسماني فن تعمير جي استحڪام
MCS ڪلائوڊ جو عوامي حصو ھاڻي ٻن ٽائر III ڊيٽا سينٽرن تي ٻڌل آھي، انھن جي وچ ۾ ھڪڙو ڊارڪ فائبر آھي، جيڪو جسماني سطح تي مختلف رستن ذريعي محفوظ ڪيو ويو آھي، 200 Gbit/s جي ٿرو پُٽ سان. ٽائر III فزيڪل انفراسٽرڪچر لاءِ ضروري سطح جي غلطي رواداري فراهم ڪري ٿو.
ڳاڙهو فائبر ٻنهي جسماني ۽ منطقي سطحن تي محفوظ آهي. چينل رزرويشن جو عمل بار بار هو، مسئلا پيدا ٿيا، ۽ اسان مسلسل ڊيٽا سينٽرن جي وچ ۾ رابطي کي بهتر بڻائي رهيا آهيون.
مثال طور، گهڻو وقت اڳ، ڊيٽا سينٽرن مان هڪ جي ويجهو هڪ کوهه ۾ ڪم ڪندي، هڪ کوٽائي ڪندڙ هڪ پائپ کي ڀڃي ڇڏيو، ۽ هن پائپ جي اندر هڪ مکيه ۽ هڪ بيڪ اپ آپٽيڪل ڪيبل هو. ڊيٽا سينٽر سان اسان جي غلطي برداشت ڪندڙ مواصلاتي چينل هڪ نقطي تي، کوهه ۾ خطرناڪ ثابت ٿيو. ان جي مطابق، اسان انفراسٽرڪچر جو حصو وڃائي ڇڏيو آهي. اسان نتيجو ڪڍيو ۽ ڪيترن ئي ڪارناما ڪيا، جن ۾ ڀرپاسي واري کوهه ۾ اضافي آپٽڪس نصب ڪرڻ شامل آهن.
ڊيٽا سينٽرن ۾ اتي موجود پوائنٽس موجود آهن ڪميونيڪيشن فراهم ڪندڙن جي جن کي اسان BGP ذريعي اسان جا اڳڪٿيون نشر ڪندا آهيون. هر نيٽ ورڪ جي هدايت لاء، بهترين ميٽرڪ چونڊيو ويو آهي، جيڪو مختلف گراهڪن کي مهيا ڪرڻ جي اجازت ڏئي ٿو بهترين ڪنيڪشن جي معيار سان. جيڪڏهن هڪ فراهم ڪندڙ ذريعي ڪميونيڪيشن گهٽجي وڃي، اسان دستياب فراهم ڪندڙن ذريعي اسان جي رستي کي ٻيهر ٺاهيندا آهيون.
جيڪڏهن هڪ مهيا ڪندڙ ناڪام ٿئي ٿو، اسان خودڪار طور تي ايندڙ هڪ ڏانهن سوئچ ڪريون ٿا. ڊيٽا سينٽرن مان هڪ جي ناڪامي جي صورت ۾، اسان وٽ ٻئي ڊيٽا سينٽر ۾ اسان جي خدمتن جي آئيني ڪاپي آهي، جيڪا پوري لوڊ تي کڻندي آهي.
جسماني زيربنا جي استحڪام
جيڪو اسان استعمال ڪندا آهيون ايپليڪيشن-سطح جي غلطي رواداري لاءِ
اسان جي خدمت ڪيترن ئي اوپن سورس حصن تي ٺهيل آهي.
ExaBGP هڪ خدمت آهي جيڪا BGP جي بنياد تي متحرڪ روٽنگ پروٽوڪول استعمال ڪندي ڪيترن ئي افعال کي لاڳو ڪري ٿي. اسان ان کي فعال طور تي استعمال ڪندا آهيون اسان جي وائيٽ لسٽ ٿيل IP پتي جي اشتهار ڏيڻ لاءِ جنهن ذريعي صارف API تائين رسائي ڪن ٿا.
HAProxy هڪ اعلي-لوڊ بيلنس آهي جيڪو توهان کي اجازت ڏئي ٿو تمام لچڪدار ٽرئفڪ بيلنسنگ ضابطن کي ترتيب ڏيڻ جي مختلف سطحن تي OSI ماڊل. اسان ان کي استعمال ڪندا آهيون سڀني خدمتن جي سامهون بيلنس ڪرڻ لاءِ: ڊيٽابيس، پيغام بروکرز، API خدمتون، ويب خدمتون، اسان جا اندروني منصوبا - سڀ ڪجهه HAProxy جي پويان آهي.
API ايپليڪيشن - هڪ ويب ايپليڪيشن python ۾ لکيل آهي، جنهن سان استعمال ڪندڙ پنهنجي انفراسٽرڪچر ۽ سروس کي منظم ڪري ٿو.
ڪم ڪندڙ جي درخواست (هتي صرف ڪم ڪندڙ) - OpenStack خدمتن ۾، هي هڪ انفراسٽرڪچر ڊيمون آهي جيڪو توهان کي API حڪمن کي انفراسٽرڪچر تي نشر ڪرڻ جي اجازت ڏئي ٿو. مثال طور، ڊسڪ تخليق ڪم ڪندڙ ۾ ٿئي ٿي، ۽ تخليق جي درخواست ايپليڪيشن API ۾ ٿئي ٿي.
معياري OpenStack ايپليڪيشن آرڪيٽيڪچر
گهڻيون خدمتون جيڪي ترقي ڪيون ويون آهن OpenStack لاءِ هڪ واحد پيراڊم جي پيروي ڪرڻ جي ڪوشش ڪريو. هڪ خدمت عام طور تي 2 حصن تي مشتمل آهي: API ۽ ڪارڪنن (پسندن جي عمل ڪندڙ). ضابطي جي طور تي، هڪ API پيٿون ۾ هڪ WSGI ايپليڪيشن آهي، جيڪا يا ته هڪ آزاد پروسيس (ڊيمون) جي طور تي شروع ڪئي وئي آهي، يا تيار ڪيل نينگڪس يا اپاچي ويب سرور استعمال ڪندي. API صارف جي درخواست تي عمل ڪري ٿو ۽ عمل لاءِ ڪم ڪندڙ ايپليڪيشن کي وڌيڪ هدايتون پاس ڪري ٿو. منتقلي هڪ پيغام بروکر استعمال ڪندي ٿئي ٿي، عام طور تي RabbitMQ، ٻيا خراب طور تي سپورٽ آهن. جڏهن پيغام بروکر تائين پهچن ٿا، انهن تي عمل ڪيو وڃي ٿو ڪارڪنن طرفان ۽، جيڪڏهن ضروري هجي ته، جواب ڏيو.
ھن تمثيل ۾ ناڪامي جا الڳ الڳ عام نقطا شامل آھن: RabbitMQ ۽ ڊيٽابيس. پر RabbitMQ هڪ خدمت جي اندر الڳ ٿيل آهي ۽، نظريي ۾، هر خدمت لاءِ انفرادي ٿي سگهي ٿو. تنهن ڪري MCS تي اسان انهن خدمتن کي جيترو ٿي سگهي الڳ ڪريون ٿا؛ هر انفرادي منصوبي لاءِ اسان هڪ الڳ ڊيٽابيس ٺاهيون ٿا، هڪ الڳ RabbitMQ. اهو طريقو سٺو آهي ڇو ته حادثي جي صورت ۾ ڪجهه خطرناڪ پوائنٽن تي، سڄي سروس نه خراب ٿئي ٿي، پر صرف ان جو حصو.
ڪم ڪندڙ ايپليڪيشنن جو تعداد لامحدود آهي، تنهنڪري API ڪارڪردگي ۽ غلطي رواداري کي وڌائڻ لاء بيلنسرز جي پويان افقي طور تي ماپ ڪري سگھي ٿو.
ڪجهه خدمتن کي خدمت جي اندر هم آهنگي جي ضرورت هوندي آهي جڏهن پيچيده ترتيب وار عمل APIs ۽ ڪارڪنن جي وچ ۾ ٿئي ٿي. انهي صورت ۾، هڪ واحد ڪوآرڊينيشن سينٽر استعمال ڪيو ويندو آهي، هڪ ڪلستر سسٽم جهڙوڪ Redis، Memcache، etcd، جيڪو هڪ ڪم ڪندڙ کي ٻئي کي ٻڌائڻ جي اجازت ڏئي ٿو ته هي ڪم هن کي لڳايو ويو آهي ("مهرباني ڪري اهو نه وٺو"). اسان استعمال ڪندا آهيون وغيره. ضابطي جي طور تي، ڪارڪنن کي فعال طور تي ڊيٽابيس سان رابطو ڪيو، اتان کان معلومات لکڻ ۽ پڙهڻ. اسان mariadb کي ڊيٽابيس طور استعمال ڪندا آهيون، جيڪو هڪ ملٽي ماسٽر ڪلستر ۾ واقع آهي.
هي کلاسک اڪيلو خدمت منظم ڪيل طريقي سان عام طور تي OpenStack لاءِ قبول ٿيل آهي. اهو هڪ بند سسٽم سمجهي سگهجي ٿو، جنهن لاء اسڪيلنگ ۽ غلطي رواداري جا طريقا بلڪل واضح آهن. مثال طور، API غلطي رواداري لاء، اهو ڪافي آهي ته انهن جي سامهون هڪ بيلنس رکڻ لاء. اسڪيلنگ مزدورن جو تعداد وڌائڻ سان حاصل ڪيو ويندو آهي.
سڄي منصوبي ۾ ڪمزور نقطو RabbitMQ ۽ MariaDB آهي. انهن جو فن تعمير هڪ الڳ مضمون جو مستحق آهي. هن آرٽيڪل ۾ آئون API غلطي رواداري تي ڌيان ڏيڻ چاهيان ٿو.
Openstack ايپليڪيشن آرڪيٽيڪچر. بادل پليٽ فارم جي توازن ۽ غلطي رواداري
ExaBGP استعمال ڪندي HAProxy بيلنس کي غلطي برداشت ڪرڻ
اسان جي APIs کي اسپيبلبل، تيز ۽ غلطي برداشت ڪرڻ لاء، اسان انهن جي اڳيان لوڊ بيلنس رکون ٿا. اسان چونڊيو HAProxy. منهنجي خيال ۾، ان ۾ اسان جي ڪم لاءِ تمام ضروري خاصيتون آهن: ڪيترن ئي او ايس آئي جي سطحن تي توازن، هڪ انتظاماتي انٽرفيس، لچڪدار ۽ اسڪاليبلٽي، بيلنسنگ طريقن جو هڪ وڏو تعداد، سيشن ٽيبل جي حمايت.
پهريون مسئلو جنهن کي حل ڪرڻ جي ضرورت هئي، خود بيلنس جي غلطي رواداري هئي. بس هڪ بيلنس کي نصب ڪرڻ ۾ ناڪامي جو هڪ نقطو پڻ پيدا ٿئي ٿو: بيلنس برڪ ۽ سروس حادثو. ائين ٿيڻ کان روڪڻ لاءِ، اسان استعمال ڪيو HAProxy سان گڏ ExaBGP.
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 پتي کي اشتهار ڏئي ٿو، پر انهن مان هڪ، هن بيلنس لاء بنيادي، گهٽ ۾ گهٽ ميٽرڪ سان اشتهار ڏنو ويو آهي. تنهن ڪري جڏهن سڀئي ٽي بيلنس آپريشن ۾ آهن، پهرين IP پتي تي ڪالون پهرين بيلنس ڏانهن وڃو، ٻئي کان ٻئي کي ڪال، ۽ ٽيون کان ٽيون ڪالون.
ڇا ٿيندو جڏهن بيلنس مان هڪ پوي ٿو؟ جيڪڏهن ڪو به بيلنس ناڪام ٿئي ٿو، ان جو مکيه پتو اڃا تائين ٻين ٻن مان اشتهار ڏنو ويندو آهي، ۽ ٽرئفڪ انهن جي وچ ۾ ٻيهر ورهايو ويندو آهي. ان ڪري، اسان صارف کي ڪيترن ئي IP پتي هڪ ڀيرو DNS ذريعي ڏيون ٿا. DNS ۽ مختلف ميٽرڪ ذريعي توازن ڪندي، اسان سڀني ٽن بيلنسرز ۾ لوڊ جي برابر ورڇ حاصل ڪندا آهيون. ۽ ساڳئي وقت اسان غلطي برداشت نه وڃايو.
DNS + BGP جي بنياد تي HAProxy کي بيلنس ڪرڻ
ExaBGP ۽ HAProxy جي وچ ۾ رابطي
تنهن ڪري، اسان غلطي رواداري کي لاڳو ڪيو آهي جڏهن سرور ڇڏڻ جي صورت ۾، رستن جي اعلان کي روڪڻ جي بنياد تي. پر HAProxy سرور جي ناڪامي کان سواءِ ٻين سببن لاءِ بند ڪري سگھي ٿو: انتظامي غلطيون، خدمت ۾ ناڪاميون. اسان چاهيون ٿا ته ٽوٽل بيلنس کي انهن حالتن ۾ به لوڊ هيٺان، ۽ اسان کي هڪ مختلف ميکانيزم جي ضرورت آهي.
تنهن ڪري، پوئين اسڪيم کي وڌايو، اسان ExaBGP ۽ HAProxy جي وچ ۾ دل جي ڌڙڪن تي عمل ڪيو. هي ExaBGP ۽ HAProxy جي وچ ۾ رابطي جو هڪ سافٽ ويئر عمل آهي، جڏهن ExaBGP ايپليڪيشنن جي صورتحال کي جانچڻ لاءِ ڪسٽم اسڪرپٽ استعمال ڪري ٿو.
هن کي ڪرڻ لاءِ، توهان کي ExaBGP ترتيب ۾ صحت جي چڪاس ڪندڙ کي ترتيب ڏيڻ جي ضرورت آهي، جيڪو HAProxy جي حالت کي جانچي سگهي ٿو. اسان جي صورت ۾، اسان HAProxy ۾ صحت جي پس منظر کي ترتيب ڏنو، ۽ ExaBGP پاسي کان اسان هڪ سادي GET درخواست سان چيڪ ڪريون ٿا. جيڪڏهن اعلان ٿيڻ بند ٿي وڃي ته پوءِ HAProxy گهڻو ڪري ڪم نه ڪري رهيو آهي ۽ ان کي اشتهار ڏيڻ جي ڪا ضرورت ناهي.
HAProxy صحت جي چڪاس
HAProxy Peers: سيشن هم وقت سازي
ڪرڻ لاء ايندڙ شيء سيشن کي هم وقت سازي ڪرڻ هو. جڏهن ورهايل بيلنسرز ذريعي ڪم ڪري رهيا آهن، ڪلائنٽ سيشن بابت معلومات جي اسٽوريج کي منظم ڪرڻ ڏکيو آهي. پر HAProxy چند بيلنسرز مان ھڪڙو آھي جيڪو ڪري سگھي ٿو پيرن جي ڪارڪردگي جي ڪري - مختلف HAProxy عملن جي وچ ۾ سيشن ٽيبل کي منتقل ڪرڻ جي صلاحيت.
اتي مختلف توازن جا طريقا آهن: سادو، جهڙوڪ ، ۽ وڌايو ويو، جڏهن ڪلائنٽ جو سيشن ياد ڪيو ويندو آهي، ۽ هر ڀيري هو ساڳئي سرور تي ختم ٿي ويندو آهي جيئن اڳ. اسان ٻئي اختيار کي لاڳو ڪرڻ چاهيون ٿا.
HAProxy اسٽيڪ ٽيبل استعمال ڪري ٿو ڪلائنٽ سيشن کي بچائڻ لاءِ هن ميڪانيزم جي. اهي محفوظ ڪن ٿا ڪلائنٽ جي اصل IP پتي، چونڊيل ٽارگيٽ ايڊريس (پسند) ۽ ڪجهه خدمت جي معلومات. عام طور تي، اسٽيڪ ٽيبل استعمال ڪيا ويندا آهن هڪ ماخذ-IP + منزل-IP جوڙو ذخيرو ڪرڻ لاءِ، جيڪو خاص طور تي انهن ايپليڪيشنن لاءِ ڪارآمد آهي جيڪي صارف سيشن جي حوالي سان منتقل نه ڪري سگھن ٿيون جڏهن ٻئي بيلنسر ڏانهن سوئچ ڪندي، مثال طور، RoundRobin بيلنسنگ موڊ ۾.
جيڪڏهن هڪ اسٽڪ ٽيبل کي سيکاريو وڃي ته مختلف HAProxy عملن جي وچ ۾ (جنهن جي وچ ۾ بيلنس ٿئي ٿو)، اسان جا بيلنس هڪ تلاءَ واري اسٽڪ ٽيبل سان ڪم ڪرڻ جي قابل هوندا. اهو ممڪن بڻائيندو ته ڪلائنٽ جي نيٽ ورڪ کي بيحد طور تي سوئچ ڪرڻ لاء جيڪڏهن بيلنسرز مان هڪ ناڪام ٿئي؛ ڪلائنٽ سيشن سان ڪم جاري رهندو ساڳئي پس منظر تي جيڪي اڳ ۾ چونڊيل هئا.
مناسب آپريشن لاء، بيلنسر جي ماخذ IP پتي جو مسئلو جنهن مان سيشن قائم ڪيو ويو حل ڪيو وڃي. اسان جي حالت ۾، هي هڪ متحرڪ پتو آهي لوپ بيڪ انٽرفيس تي.
ساٿين جو صحيح ڪم صرف ڪجهه حالتن هيٺ حاصل ڪري سگهجي ٿو. اهو آهي، TCP ٽائيم آئوٽ ڪافي وڏو هجڻ گهرجي يا سوئچنگ ڪافي تيز هجڻ گهرجي ته جيئن TCP سيشن ختم ٿيڻ جو وقت نه هجي. بهرحال، اها اجازت ڏئي ٿي بيحد سوئچنگ لاءِ.
IaaS ۾ اسان وٽ ھڪڙي خدمت آھي ساڳي ٽيڪنالاجي استعمال ڪندي. هي جنهن کي Octavia سڏيو ويندو آهي. اهو ٻن HAProxy پروسيس تي ٻڌل آهي ۽ شروعاتي طور تي ساٿين جي مدد شامل آهي. انهن پاڻ کي هن خدمت ۾ شاندار ثابت ڪيو آهي.
تصوير اسڪيمي طور تي ٽي HAProxy مثالن جي وچ ۾ پير ٽيبل جي حرڪت ڏيکاري ٿي، هڪ ترتيب پيش ڪئي وئي آهي ته اهو ڪيئن ترتيب ڏئي سگهجي ٿو:
HAProxy Peers (سيشن هم وقت سازي)
جيڪڏهن توهان ساڳئي منصوبي تي عمل ڪريو ٿا، ان جي آپريشن کي احتياط سان جانچڻ گهرجي. اها حقيقت ناهي ته اهو ساڳئي طريقي سان ڪم ڪندو 100٪ وقت جي. پر گهٽ ۾ گهٽ توهان اسٽيڪ ٽيبل نه وڃايو جڏهن توهان کي ڪلائنٽ جي ماخذ IP کي ياد رکڻ جي ضرورت آهي.
ساڳئي ڪلائنٽ کان هڪ ئي وقت جي درخواستن جي تعداد کي محدود ڪرڻ
ڪي به خدمتون جيڪي عوامي طور تي دستياب آهن، بشمول اسان جي APIs، درخواستن جي برفاني طوفان جي تابع ٿي سگهي ٿي. انهن جا سبب مڪمل طور تي مختلف ٿي سگهن ٿا، صارف جي غلطين کان ٽارگيٽ حملن تائين. اسان وقتي طور تي IP پتي جي ذريعي DDoSed آهن. ڪلائنٽ اڪثر ڪري انهن جي اسڪرپٽ ۾ غلطيون ڪندا آهن ۽ اسان کي مني-DDoSs ڏيو.
هڪ طريقو يا ٻيو، اضافي تحفظ فراهم ڪيو وڃي. واضح حل API جي درخواستن جي تعداد کي محدود ڪرڻ ۽ سي پي يو جي وقت کي خراب ڪرڻ واري درخواستن جي پروسيسنگ کي ضايع نه ڪرڻ آهي.
اهڙين پابندين کي لاڳو ڪرڻ لاء، اسان شرح جي حد استعمال ڪندا آهيون، HAProxy جي بنياد تي ترتيب ڏنل، ساڳئي اسٽيڪ ٽيبل استعمال ڪندي. حدن کي ترتيب ڏيڻ بلڪل سادو آهي ۽ توهان کي اجازت ڏئي ٿو ته صارف کي API جي درخواستن جي تعداد تائين محدود ڪري. الورورٿم اهو ماخذ IP ياد ڪري ٿو جنهن کان درخواستون ڪيون وينديون آهن ۽ هڪ صارف کان هڪ ئي وقت جي درخواستن جي تعداد کي محدود ڪري ٿي. يقينا، اسان حساب ڪيو اوسط API لوڊ پروفائل هر خدمت لاء ۽ مقرر ڪيو حد ≈ 10 ڀيرا هن قدر. اسان صورتحال کي ويجهي نگراني ڪرڻ جاري رکون ٿا ۽ اسان جي آڱر نبض تي رکون ٿا.
اهو عمل ۾ ڇا نظر اچي ٿو؟ اسان وٽ گراهڪ آهن جيڪي هر وقت اسان جي آٽو اسڪيلنگ APIs استعمال ڪندا آهن. اهي صبح جو لڳ ڀڳ ٻه کان ٽي سؤ ورچوئل مشينون ٺاهيندا آهن ۽ شام جو انهن کي حذف ڪندا آهن. OpenStack لاءِ، هڪ ورچوئل مشين ٺاهڻ لاءِ، PaaS خدمتن سان گڏ، گهٽ ۾ گهٽ 1000 API درخواستن جي ضرورت آهي، ڇاڪاڻ ته خدمتن جي وچ ۾ رابطو به API ذريعي ٿئي ٿو.
ڪمن جي اهڙي منتقلي هڪ ڪافي وڏي لوڊ سبب آهي. اسان هن لوڊ جو اندازو لڳايو، روزانه چوٽيون گڏ ڪيون، انهن کي ڏهه ڀيرا وڌايو، ۽ اهو اسان جي شرح جي حد بڻجي وئي. اسان پنهنجي آڱر نبض تي رکون ٿا. اسان اڪثر بوٽ ۽ اسڪينر ڏسون ٿا جيڪي اسان کي ڏسڻ جي ڪوشش ڪري رهيا آهن ته ڇا اسان وٽ ڪي سي اي اسڪرپٽ آهن جيڪي هلائي سگهجن ٿيون، اسان انهن کي فعال طور تي ڪٽي رهيا آهيون.
توهان جي ڪوڊ بيس کي ڪيئن تازه ڪاري ڪجي بغير صارفين کي ڌيان ڏيڻ
اسان ڪوڊ جي ترتيب واري عمل جي سطح تي غلطي رواداري کي پڻ لاڳو ڪريون ٿا. رول آئوٽ دوران خرابيون ٿي سگھن ٿيون، پر سروس جي دستيابي تي انھن جو اثر گھٽجي سگھي ٿو.
اسان مسلسل اسان جي خدمتن کي اپڊيٽ ڪيو ۽ يقيني بڻائڻ گهرجي ته ڪوڊ بيس صارفين کي متاثر ڪرڻ کان سواء اپڊيٽ ڪيو ويو آهي. اسان HAProxy جي انتظامي صلاحيتن ۽ اسان جي خدمتن ۾ Graceful Shutdown جي نفاذ کي استعمال ڪندي هن مسئلي کي حل ڪرڻ ۾ ڪامياب ٿي ويا آهيون.
هن مسئلي کي حل ڪرڻ لاء، اهو ضروري هو ته بيلنس جي ڪنٽرول کي يقيني بڻائڻ ۽ خدمتن جي "صحيح" بندش:
- HAProxy جي صورت ۾، ڪنٽرول هڪ اسٽيٽس فائل ذريعي ڪيو ويندو آهي، جيڪو بنيادي طور تي هڪ ساکٽ آهي ۽ HAProxy ترتيب ۾ بيان ڪيل آهي. توھان موڪلي سگھو ٿا ان کي حڪم stdio ذريعي. پر اسان جو بنيادي ٺاھ جوڙ ڪنٽرول اوزار قابل قبول آھي، تنھنڪري ان ۾ HAProxy کي منظم ڪرڻ لاء ھڪڙو ٺهيل ماڊل آھي. جيڪو اسان فعال طور تي استعمال ڪندا آهيون.
- اسان جون ڪيتريون ئي API ۽ انجڻ جون خدمتون شاندار شٽ ڊائون ٽيڪنالاجيز جي حمايت ڪن ٿيون: جڏهن بند ٿي رهيا آهن، اهي موجوده ڪم جي مڪمل ٿيڻ جو انتظار ڪن ٿا، پوءِ اها HTTP درخواست هجي يا ڪجهه خدمت جو ڪم. ائين ئي ڪم ڪندڙ سان ٿئي ٿو. اهو سڀني ڪمن کي ڄاڻي ٿو جيڪو اهو ڪري رهيو آهي ۽ ختم ٿئي ٿو جڏهن اهو ڪاميابيء سان مڪمل ڪيو آهي.
انهن ٻن پوائنٽن جي مهرباني، اسان جي ترتيب ڏيڻ لاء محفوظ الگورتھم هن طرح نظر اچي ٿو.
- ڊولپر ڪوڊ جو هڪ نئون پيڪيج گڏ ڪري ٿو (اسان لاءِ اهو RPM آهي)، ان کي ڊيو ماحول ۾ آزمائي ٿو، ان کي اسٽيج ۾ آزمائي ٿو، ۽ ان کي اسٽيج مخزن ۾ ڇڏي ٿو.
- ڊولپر ترتيب ڏيڻ لاءِ ٽاسڪ مقرر ڪري ٿو سڀ کان وڌيڪ تفصيلي وضاحت سان ”نادرات“: نئين پيڪيج جو نسخو، نئين ڪارڪردگيءَ جي وضاحت ۽ ضروري هجي ته مقرري بابت ٻيا تفصيل.
- سسٽم ايڊمنسٽريٽر تازه ڪاري شروع ڪري ٿو. جوابي راند جو ڪتاب شروع ڪري ٿو، جنهن جي نتيجي ۾ هيٺ ڏنل آهي:
- اسٽيج مخزن مان هڪ پيڪيج وٺي ٿو ۽ ان کي استعمال ڪري ٿو پيڪيج جي ورزن کي اپڊيٽ ڪرڻ لاءِ پراڊڪٽ مخزن ۾.
- اپڊيٽ ڪيل سروس جي پس منظر جي هڪ فهرست مرتب ڪري ٿي.
- HAProxy ۾ تازه ڪاري ٿيڻ واري پهرين خدمت کي بند ڪري ٿو ۽ ان جي عملن کي هلائڻ لاءِ انتظار ڪري ٿو. شاندار بند ڪرڻ جي مهرباني، اسان کي يقين آهي ته سڀ موجوده ڪلائنٽ درخواستون ڪاميابي سان مڪمل ٿينديون.
- API ۽ ڪارڪنن کان پوء مڪمل طور تي بند ٿي ويا آهن، ۽ HAProxy بند ڪيو ويو آهي، ڪوڊ اپڊيٽ ڪيو ويو آهي.
- جوابي هلائيندڙ خدمتون.
- هر خدمت لاء، ڪجهه "هينڊلز" کڄي ويندا آهن، جيڪي اڳئين بيان ڪيل اهم ٽيسٽن تي يونٽ ٽيسٽ انجام ڏين ٿا. نئين ڪوڊ جو هڪ بنيادي چيڪ جاء وٺندو آهي.
- جيڪڏهن اڳئين قدم ۾ ڪا به غلطي نه ملي هئي، پس منظر چالو ڪيو ويو آهي.
- اچو ته ايندڙ پس منظر ڏانهن وڃو.
- سڀني پس منظرن کي اپڊيٽ ڪرڻ کان پوء، فنڪشنل ٽيسٽ شروع ڪيا ويا آهن. جيڪڏهن اهي غائب آهن، پوء ڊولپر ڪنهن به نئين ڪارڪردگي تي نظر اچي ٿو جيڪا هن پيدا ڪئي.
هي لڳائڻ مڪمل ڪري ٿو.
سروس اپڊيٽ چڪر
اها اسڪيم ڪم نه ڪري ها جيڪڏهن اسان وٽ هڪ ضابطو نه هجي ها. اسان جنگ ۾ پراڻي ۽ نئين نسخن جي حمايت ڪريون ٿا. اڳ ۾، سافٽ ويئر ڊولپمينٽ جي مرحلي ۾، اهو طئي ڪيو ويو آهي ته جيتوڻيڪ سروس ڊيٽابيس ۾ تبديليون آهن، اهي پوئين ڪوڊ کي ٽوڙي نه سگهندا. نتيجي طور، ڪوڊ جو بنياد تدريجي طور تي اپڊيٽ ڪيو ويو آهي.
ٿڪل
هڪ غلطي برداشت ڪندڙ WEB فن تعمير جي باري ۾ پنهنجا پنهنجا خيال حصيداري ڪندي، مان هڪ ڀيرو ٻيهر ان جي اهم نقطي کي نوٽ ڪرڻ چاهيندس:
- جسماني غلطي رواداري؛
- نيٽ ورڪ غلطي رواداري (balancers, BGP);
- استعمال ٿيل ۽ ترقي يافته سافٽ ويئر جي غلطي رواداري.
مستحڪم اپ ٽائيم هرڪو!
جو ذريعو: www.habr.com
