جديد ويب ميڊيا مواد کان سواء تقريبا ناقابل تصور آهي: تقريبن هر ڏاڏي وٽ هڪ اسمارٽ فون آهي، هرڪو سماجي نيٽ ورڪن تي آهي، ۽ سار سنڀال ۾ گهٽتائي ڪمپنين لاء قيمتي آهي. هتي ڪمپني جي ڪهاڻي جو هڪ نقل آهي انهي بابت ته هن هارڊويئر حل استعمال ڪندي تصويرن جي ترسيل کي ڪيئن منظم ڪيو، پروسيس ۾ هن کي ڪهڙي ڪارڪردگي جي مسئلن جو سامنا ٿيو، انهن جو سبب ڇا آهي، ۽ اهي مسئلا ڪيئن حل ڪيا ويا Nginx تي ٻڌل سافٽ ويئر حل استعمال ڪندي، جڏهن ته هر سطح تي غلطي رواداري کي يقيني بڻائي ٿي (). اسان Oleg جي ڪهاڻي جي ليکڪن جي مهرباني Efimova ۽ Alexandra Dymova، جن ڪانفرنس ۾ پنهنجو تجربو شيئر ڪيو .
- اچو ته ٿورڙي تعارف سان شروع ڪريون ته ڪيئن اسان فوٽوز کي ذخيرو ۽ ڪيش ڪندا آهيون. اسان وٽ هڪ پرت آهي جتي اسان انهن کي ذخيرو ڪندا آهيون، ۽ هڪ پرت جتي اسان فوٽوز کي ڪيش ڪندا آهيون. ساڳي ئي وقت، جيڪڏهن اسان چاهيون ٿا ته اعليٰ چال جي شرح حاصل ڪرڻ ۽ اسٽوريج تي لوڊ گهٽائڻ، اهو اسان لاءِ ضروري آهي ته هر هڪ فرد جي تصوير هڪ ڪيشنگ سرور تي هجي. ٻي صورت ۾، اسان کي ڪيترائي ڀيرا وڌيڪ ڊسڪ انسٽال ڪرڻو پوندو جيئن اسان وٽ وڌيڪ سرور آهن. اسان جي ٽرڪ ريٽ 99 سيڪڙو جي لڳ ڀڳ آهي، يعني اسان پنهنجي اسٽوريج تي 100 ڀيرا لوڊ گهٽائي رهيا آهيون، ۽ اهو ڪرڻ لاءِ، 10 سال اڳ، جڏهن اهو سڀ ڪجهه ٺاهيو پيو وڃي، اسان وٽ 50 سرور هئا. ان جي مطابق، انهن تصويرن جي خدمت ڪرڻ لاء، اسان کي لازمي طور تي 50 خارجي ڊومينز جي ضرورت آهي جيڪي اهي سرور خدمت ڪن ٿا.
قدرتي طور تي، سوال فوري طور تي پيدا ٿيو: جيڪڏهن اسان جي سرور مان هڪ ٿي وڃي ٿي ۽ دستياب نه ٿي وڃي، اسان ٽرئفڪ جو ڪهڙو حصو وڃائي سگهون ٿا؟ اسان ڏٺو ته مارڪيٽ ۾ ڇا آهي ۽ هارڊويئر جو هڪ ٽڪرو خريد ڪرڻ جو فيصلو ڪيو ته جيئن اهو اسان جي سڀني مسئلن کي حل ڪري. انتخاب F5-نيٽ ورڪ ڪمپني جي حل تي ٿي ويو (جيڪو، رستي ۾، تازو خريد ڪيو NGINX, Inc): BIG-IP مقامي ٽرئفڪ مئنيجر.
هارڊويئر جو هي ٽڪرو (LTM) ڇا ڪندو آهي: اهو هڪ لوهه وارو روٽر آهي جيڪو پنهنجي ٻاهرين بندرگاهن کي لوهه جي بيڪار بڻائي ٿو ۽ توهان کي نيٽ ورڪ ٽوپولوجي جي بنياد تي ، ڪجهه سيٽنگن تي ، ۽ صحت جي چڪاس ڪرڻ جي اجازت ڏئي ٿو. اهو اسان لاء اهم هو ته هارڊويئر جو هي ٽڪرو پروگرام ٿي سگهي ٿو. ان جي مطابق، اسان اهو منطق بيان ڪري سگهون ٿا ته ڪيئن هڪ مخصوص صارف جون تصويرون هڪ مخصوص ڪيش مان پيش ڪيون ويون آهن. اهو ڇا وانگر آهي؟ هتي هارڊويئر جو هڪ ٽڪرو آهي جيڪو انٽرنيٽ کي هڪ ڊومين تي ڏسي ٿو، هڪ IP، ايس ايس ايل آف لوڊ ڪري ٿو، HTTP درخواستن کي پارس ڪري ٿو، IRule مان ڪيش نمبر چونڊي ٿو، جتي وڃڻو آهي، ۽ ٽرئفڪ کي اتي وڃڻ جي اجازت ڏئي ٿو. ساڳئي وقت، اهو صحت جي چڪاس ڪندو آهي، ۽ ڪجهه مشين جي غير موجودگي جي صورت ۾، ان وقت اسان ان کي ٺاهيو ته ٽريفڪ هڪ بيڪ اپ سرور ڏانهن ويو. ترتيب جي نقطي نظر کان، اتي موجود آهن، يقينا، ڪجهه nuances، پر عام طور تي هر شيء بلڪل سادو آهي: اسان هڪ ڪارڊ رجسٽر ڪريون ٿا، نيٽ ورڪ تي اسان جي IP ڏانهن هڪ خاص نمبر جو خط، اسان چئون ٿا ته اسان بندرگاهن تي ٻڌنداسين 80. ۽ 443، اسان چئون ٿا ته جيڪڏهن سرور دستياب ناهي، ته توهان کي بيڪ اپ هڪ ڏانهن ٽرئفڪ موڪلڻ جي ضرورت آهي، انهي صورت ۾ 35th، ۽ اسان منطق جو هڪ گروپ بيان ڪريون ٿا ته هن فن تعمير کي ڪيئن ڌار ڪيو وڃي. مسئلو صرف اهو هو ته ٻولي جنهن ۾ هارڊويئر پروگرام ڪيو ويو هو Tcl. جيڪڏهن ڪنهن کي اهو ياد آهي ته... هيءَ ٻولي پروگرامنگ لاءِ آسان ٻولي کان وڌيڪ لکڻ واري آهي:
اسان کي ڇا مليو؟ اسان کي هارڊويئر جو هڪ ٽڪرو ملي ٿو جيڪو اسان جي انفراسٽرڪچر جي اعليٰ دستيابي کي يقيني بڻائي ٿو، اسان جي سموري ٽرئفڪ کي روٽ ڪري ٿو، صحت جا فائدا مهيا ڪري ٿو ۽ صرف ڪم ڪري ٿو. ان کان علاوه، اهو ڪافي وقت تائين ڪم ڪري ٿو: گذريل 10 سالن ۾ ان بابت ڪا به شڪايت نه ڪئي وئي آهي. 2018 جي شروعات تائين، اسان اڳ ۾ ئي موڪلي رهيا هئاسين اٽڪل 80k تصويرون في سيڪنڊ. هي اسان جي ٻنهي ڊيٽا سينٽرن مان تقريباً 80 گيگا بائيٽ ٽرئفڪ آهي.
بهرحال…
2018 جي شروعات ۾، اسان چارٽ تي هڪ بدصورت تصوير ڏٺو: فوٽو موڪلڻ جو وقت واضح طور تي وڌي چڪو هو. ۽ اهو اسان کي مناسب ڪرڻ بند ڪيو. مسئلو اهو آهي ته اهو رويو صرف ٽرئفڪ جي چوٽي تي نظر ايندو هو - اسان جي ڪمپني لاء هي رات آچر کان سومر تائين آهي. پر باقي وقت سسٽم معمول وانگر ڪم ڪيو، ناڪامي جا نشان.
تنهن هوندي به، مسئلو حل ڪيو وڃي ها. اسان ممڪن رڪاوٽن جي نشاندهي ڪئي ۽ انهن کي ختم ڪرڻ شروع ڪيو. سڀ کان پهريان، يقيناً، اسان بيروني اپ لنڪس کي وڌايو، اندروني اپ لنڪس جو مڪمل آڊٽ ڪيو، ۽ سڀ ممڪن رڪاوٽون ڳوليون. پر اهو سڀ ڪجهه واضح نتيجو نه ڏنو، مسئلو غائب نه ٿيو.
هڪ ٻيو ممڪن رڪاوٽ خود فوٽو ڪيچ جي ڪارڪردگي هئي. ۽ اسان فيصلو ڪيو ته شايد مسئلو انهن سان گڏ آهي. خير، اسان ڪارڪردگي کي وڌايو - خاص طور تي فوٽو ڪيچ تي نيٽ ورڪ بندرگاهن. پر وري به ڪا واضح سڌارو نظر نه آيو. آخر ۾، اسان LTM جي ڪارڪردگي تي تمام گهڻو ڌيان ڏنو، ۽ هتي اسان گرافس تي هڪ اداس تصوير ڏٺو: سڀني سي پي يوز تي لوڊ آسانيء سان وڃڻ شروع ٿئي ٿو، پر پوء اوچتو هڪ پليٽ تي اچي ٿو. ساڳئي وقت، LTM صحت جي چڪاس ۽ اپ لنڪس کي مناسب طور تي جواب ڏيڻ بند ڪري ٿو ۽ بي ترتيب طور تي انهن کي بند ڪرڻ شروع ڪري ٿو، جيڪو سنگين ڪارڪردگي جي خراب ٿيڻ جي ڪري ٿي.
اهو آهي، اسان مسئلي جي ماخذ کي سڃاڻي ورتو آهي، ان جي نشاندهي ڪئي آهي. اهو فيصلو ڪرڻو آهي ته اسان ڇا ڪنداسين.
پهرين، سڀ کان وڌيڪ واضح شيء جيڪا اسان ڪري سگهون ٿا، ڪنهن به طرح LTM پاڻ کي جديد بڻائڻ آهي. پر هتي ڪجھ نزاڪت آهن، ڇاڪاڻ ته هي هارڊويئر بلڪل منفرد آهي، توهان ويجھي سپر مارڪيٽ ۾ نه ويندا ۽ ان کي خريد ڪندا. هي هڪ الڳ معاهدو آهي، هڪ الڳ لائسنس جو معاهدو، ۽ اهو گهڻو وقت وٺندو. ٻيو اختيار اهو آهي ته توهان پنهنجي لاءِ سوچڻ شروع ڪيو، اچو ته توهان جي پنهنجي اجزاء کي استعمال ڪندي پنهنجي حل سان، ترجيح طور تي هڪ کليل رسائي پروگرام استعمال ڪندي. باقي اهو فيصلو ڪرڻو آهي ته اسان ان لاءِ ڇا چونڊينداسين ۽ هن مسئلي کي حل ڪرڻ ۾ ڪيترو وقت خرچ ڪنداسين، ڇاڪاڻ ته صارفين کي ڪافي تصويرون نه ملي رهيون هيون. تنهن ڪري، اسان کي اهو سڀ ڪجهه ڪرڻ جي ضرورت آهي، تمام جلدي، ڪو ڪالهه چئي سگهي ٿو.
جيئن ته اهو ڪم لڳي رهيو آهي ته ”جيئن جلدي ممڪن ٿي سگهي ڪجهه ڪريو ۽ اسان وٽ موجود هارڊويئر کي استعمال ڪندي،“ پهرين شيءِ جيڪا اسان سوچيو ته صرف ڪجهه تمام طاقتور مشينن کي سامهون کان هٽائي، نينگڪس کي اتي رکي، جنهن سان اسان ڄاڻون ٿا ته ڪيئن ڪجي. ڪم ڪريو ۽ سڀني ساڳين منطق کي لاڳو ڪرڻ جي ڪوشش ڪريو جيڪي هارڊويئر ڪندا هئا. اهو آهي، حقيقت ۾، اسان پنهنجو هارڊويئر ڇڏيو، 4 وڌيڪ سرور نصب ڪيا جن کي اسان کي ترتيب ڏيڻو هو، انهن لاءِ خارجي ڊومين ٺاهيا هئا، جيئن 10 سال اڳ هئا... جيڪڏهن اهي مشينون گر ٿي ويون ته اسان دستيابي ۾ ٿورو وڃائي ويهندا هئاسين، پر اڃا به گهٽ، اهي مقامي طور تي اسان جي استعمال ڪندڙن جو مسئلو حل ڪيو.
ان جي مطابق، منطق ساڳيو رهي ٿو: اسان نينڪسڪس کي انسٽال ڪري سگهون ٿا، اهو ڪري سگهي ٿو SSL-offload، اسان ڪنهن به طريقي سان پروگرام ڪري سگهون ٿا روٽنگ منطق، صحت جي چڪاس جي ترتيبن ۾ ۽ صرف انهي منطق کي نقل ڪري سگهون ٿا جيڪو اسان اڳ ۾ ڪيو هو.
اچو ته configs لکڻ لاء ويھي. شروعات ۾ اهو محسوس ٿيو ته هر شيء بلڪل سادي هئي، پر، بدقسمتي سان، هر ڪم لاء دستياب ڳولڻ تمام ڏکيو آهي. تنهن ڪري، اسان صرف گوگلنگ جي سفارش نه ڪندا آهيون "فوٽوز لاء نينگڪس کي ڪيئن ترتيب ڏيڻ": اهو بهتر آهي ته سرڪاري دستاويزن ڏانهن اشارو ڪيو وڃي، جيڪو ڏيکاريندو ته ڪهڙي سيٽنگون کي ڇڪڻ گهرجي. پر اهو بهتر آهي ته مخصوص پيٽرولر پاڻ کي چونڊيو. خير، پوءِ سڀ ڪجھ سادو آهي: اسان انهن سرورن کي بيان ڪريون ٿا جيڪي اسان وٽ آهن، اسين بيان ڪريون ٿا سرٽيفڪيٽن... پر سڀ کان وڌيڪ دلچسپ شيءِ آهي، حقيقت ۾، خود روٽنگ منطق.
شروعات ۾ اسان کي اهو محسوس ٿيو ته اسان صرف پنهنجي جڳهه کي بيان ڪري رهيا آهيون، ان ۾ اسان جي فوٽو ڪيش جي تعداد سان ملائي، پنهنجي هٿن يا جنريٽر کي استعمال ڪندي بيان ڪري رهيا آهيون ته اسان کي ڪيترا اپ اسٽريم جي ضرورت آهي، هر اپ اسٽريم ۾ اسان سرور کي ظاهر ڪري رهيا آهيون جنهن ڏانهن ٽرئفڪ هجڻ گهرجي. وڃو، ۽ هڪ بيڪ اپ سرور - جيڪڏهن مکيه سرور دستياب ناهي:
پر، شايد، جيڪڏھن سڀ ڪجھ سادو ھجي ھا، ته اسان بس گھر وينداسين ۽ ڪجھ به نه چوندا. بدقسمتي سان، ڊفالٽ نينگڪس سيٽنگن سان، جيڪي، عام طور تي، ترقي جي ڪيترن ئي سالن کان ٺاهيا ويا آهن ۽ مڪمل طور تي هن ڪيس لاء مناسب نه آهن ... ترتيب هن طرح نظر اچن ٿا: جيڪڏهن ڪجهه اپ اسٽريم سرور ۾ درخواست جي غلطي يا وقت ختم ٿي وئي آهي، Nginx هميشه ايندڙ ٽرئفڪ کي تبديل ڪري ٿو. ان کان علاوه، پهرين ناڪامي کان پوء، 10 سيڪنڊن اندر سرور پڻ بند ڪيو ويندو، ٻئي غلطي سان ۽ وقت ختم ٿيڻ سان - اهو ڪنهن به طريقي سان ترتيب نه ٿو ڏئي سگهجي. اهو آهي، جيڪڏهن اسان اپ اسٽريم هدايت ۾ ٽائم آئوٽ آپشن کي هٽايو يا ري سيٽ ڪيو، پوء، جيتوڻيڪ نينڪس هن درخواست تي عمل نه ڪندو ۽ ڪجهه تمام سٺي غلطي سان جواب ڏيندو، سرور بند ٿي ويندو.
هن کان بچڻ لاء، اسان ٻه شيون ڪيون:
a) انهن نينگڪس کي دستي طور تي ڪرڻ کان منع ڪئي - ۽ بدقسمتي سان، اهو ڪرڻ جو واحد طريقو صرف سيٽنگ کي وڌ ۾ وڌ ناڪام سيٽنگون مقرر ڪرڻ آهي.
b) اسان کي ياد آهي ته ٻين منصوبن ۾ اسان هڪ ماڊل استعمال ڪندا آهيون جيڪو اسان کي پس منظر ۾ صحت جي چڪاس ڪرڻ جي اجازت ڏئي ٿو - ان جي مطابق، اسان ڪافي ڀيرا صحت جي چڪاس ڪئي هئي ته جيئن حادثي جي صورت ۾ گهٽ ۾ گهٽ وقت گهٽجي وڃي.
بدقسمتي سان، اهو سڀ ڪجهه نه آهي، ڇاڪاڻ ته لفظي طور تي هن اسڪيم جي آپريشن جي پهرين ٻن هفتن ۾ ظاهر ڪيو ويو آهي ته TCP صحت جي چڪاس پڻ هڪ ناقابل اعتبار شيء آهي: اپ اسٽريم سرور تي اهو ٿي سگهي ٿو Nginx، يا Nginx D-stat ۾، ۽ ان ۾. هن صورت ۾ ڪنيال ڪنيڪشن قبول ڪندو، صحت جي چڪاس پاس ٿي ويندي، پر ڪم نه ڪندي. تنهن ڪري، اسان هن کي فوري طور تي صحت جي جانچ http سان تبديل ڪيو، هڪ مخصوص ٺاهيو، جيڪو، جيڪڏهن اهو 200 موٽائي ٿو، ته پوء سڀ ڪجهه هن اسڪرپٽ ۾ ڪم ڪري ٿو. توھان اضافي منطق ڪري سگھو ٿا - مثال طور، ڪيشنگ سرور جي صورت ۾، چيڪ ڪريو ته فائل سسٽم صحيح طرح سان نصب ٿيل آھي:
۽ اهو اسان کي مناسب ڪندو، سواء ان وقت جي سرڪٽ مڪمل طور تي بار بار ڪيو جيڪو هارڊويئر ڪيو. پر اسان بهتر ڪرڻ چاهيون ٿا. اڳي، اسان وٽ هڪ بيڪ اپ سرور هو، ۽ اهو شايد تمام سٺو ناهي، ڇاڪاڻ ته جيڪڏهن توهان وٽ هڪ سئو سرور آهن، پوء جڏهن هڪ ئي وقت ۾ ڪيترائي ناڪام ٿين ٿا، هڪ بيڪ اپ سرور لوڊ کي منهن ڏيڻ ممڪن ناهي. تنهن ڪري، اسان سڀني سرورن تي رزرويشن کي ورهائڻ جو فيصلو ڪيو: اسان صرف هڪ ٻيو الڳ اپ اسٽريم ٺاهيو، سڀني سرورن کي اتي ڪجهه پيٽرولرن سان لکيو ته اهي لوڊ جي مطابق جيڪي اهي خدمت ڪري سگهن ٿا، ساڳيا صحت جي چڪاس شامل ڪيون جيڪي اسان اڳ ۾ ڪيون هيون:
جيئن ته هڪ اپ اسٽريم جي اندر ٻئي اپ اسٽريم ڏانهن وڃڻ ناممڪن آهي، ان ڪري اهو پڪ ڪرڻ ضروري هو ته جيڪڏهن مين اپ اسٽريم، جنهن ۾ اسان صرف صحيح، ضروري فوٽو ڪيش رڪارڊ ڪيو آهي، موجود نه هو، ته اسان صرف error_page ذريعي فال بيڪ ڏانهن ويا هئاسين. جتي اسان بيڪ اپ اپ اسٽريم ڏانهن وياسون:
۽ لفظي طور تي چار سرور شامل ڪرڻ سان، اھو آھي جيڪو اسان حاصل ڪيو: اسان لوڊ جو حصو تبديل ڪيو - اسان ان کي LTM کان انھن سرورن تي ھٽايو، ساڳئي منطق تي عمل ڪيو، معياري هارڊويئر ۽ سافٽ ويئر استعمال ڪندي، ۽ فوري طور تي بونس حاصل ڪيو جيڪي اھي سرور ڪري سگھن ٿا. اسڪيل ڪيو وڃي، ڇاڪاڻ ته اهي صرف گهربل طور تي فراهم ڪري سگهجن ٿيون. خير، صرف منفي آهي ته اسان خارجي صارفين لاء اعلي دستيابي وڃائي ڇڏيو آهي. پر ان وقت اسان کي اها قرباني ڏيڻي پئي، ڇو ته ان مسئلي کي فوري طور حل ڪرڻ ضروري هو. تنهن ڪري، اسان لوڊ جو حصو هٽايو، اهو ان وقت تقريبا 40٪ هو، LTM سٺو محسوس ڪيو، ۽ لفظي طور تي ٻه هفتا پوء مسئلو شروع ٿيو، اسان 45k درخواستون في سيڪنڊ نه، پر 55k موڪلڻ شروع ڪيو. حقيقت ۾، اسان 20٪ وڌايو - اهو واضح طور تي ٽرئفڪ آهي جيڪو اسان صارف کي نه ڏنو. ۽ ان کان پوء اهي سوچڻ شروع ڪيو ته ڪيئن باقي مسئلو حل ڪرڻ - اعلي خارجي رسائي کي يقيني بڻائڻ لاء.
اسان وٽ ڪجهه وقفو هو، جنهن دوران اسان بحث ڪيو ته اسان ان لاءِ ڪهڙو حل استعمال ڪنداسين. DNS استعمال ڪندي اعتماد کي يقيني بڻائڻ لاءِ تجويزون ڏنيون ويون، ڪجھ گھر ۾ لکيل اسڪرپٽ استعمال ڪندي، متحرڪ روٽنگ پروٽوڪول... اتي ڪيترائي آپشن ھئا، پر اھو اڳي ئي واضح ٿي چڪو آھي ته تصويرن جي صحيح ترسيل لاءِ، توھان کي ھڪ ٻي پرت متعارف ڪرائڻ جي ضرورت آھي جيڪا ھن جي نگراني ڪندي. . اسان انهن مشينن کي فوٽو ڊائريڪٽر سڏيو آهي. سافٽ ويئر جنهن تي اسان انحصار ڪيو هو Keepalived:
شروع ڪرڻ سان، Keepalived ڇا تي مشتمل آهي؟ پهريون VRRP پروٽوڪول آهي، وڏي پيماني تي نيٽ ورڪرز کي سڃاتو وڃي ٿو، نيٽ ورڪ سامان تي واقع آهي جيڪو خارجي IP پتي تي غلطي رواداري مهيا ڪري ٿو جنهن سان ڪلائنٽ ڳنڍيندا آهن. ٻيو حصو IPVS، IP ورچوئل سرور آهي، فوٽو روٽرز جي وچ ۾ توازن ۽ هن سطح تي غلطي رواداري کي يقيني بڻائڻ لاءِ. ۽ ٽيون - صحت جي چڪاس.
اچو ته پهرين حصي سان شروع ڪريون: VRRP - اهو ڇا ٿو لڳي؟ هتي هڪ مخصوص ورچوئل IP آهي، جنهن ۾ dns badoocdn.com ۾ داخلا آهي، جتي ڪلائنٽ ڳنڍجن ٿا. ڪجھ وقت تي، اسان وٽ ھڪڙو IP پتو آھي ھڪڙي سرور تي. Keepalived packets سرور جي وچ ۾ VRRP پروٽوڪول استعمال ڪندي هلن ٿا، ۽ جيڪڏهن ماسٽر راڊار کان غائب ٿي وڃي - سرور ريبوٽ ڪيو آهي يا ٻيو ڪجهه، پوء بيڪ اپ سرور خودڪار طريقي سان هن IP پتي کي چونڊيندو آهي - ڪنهن به دستي عملن جي ضرورت ناهي. ماسٽر ۽ بيڪ اپ جي وچ ۾ فرق بنيادي طور تي ترجيح آهي: اهو اعلي آهي، اهو وڏو موقعو آهي ته مشين هڪ ماسٽر بڻجي ويندي. هڪ تمام وڏو فائدو اهو آهي ته توهان کي سرور تي IP پتي کي ترتيب ڏيڻ جي ضرورت ناهي، اهو ڪافي آهي انهن کي ترتيب ۾ بيان ڪرڻ لاء، ۽ جيڪڏهن IP پتي کي ڪجهه ڪسٽم روٽنگ ضابطن جي ضرورت آهي، اهو سڌو سنئون ترتيب ۾ بيان ڪيو ويو آهي، استعمال ڪندي. ساڳي نحو جيئن بيان ڪيل VRRP پيڪيج ۾. توهان ڪنهن به اڻڄاتل شين کي منهن نه ڪندا.
اهو عمل ۾ ڇا نظر اچي ٿو؟ ڇا ٿيندو جيڪڏهن سرور مان هڪ ناڪام ٿئي؟ جيئن ئي ماسٽر غائب ٿئي ٿو، اسان جو بيڪ اپ اشتهارن کي حاصل ڪرڻ بند ڪري ٿو ۽ خودڪار طور تي ماسٽر بڻجي ويندو آهي. ڪجهه وقت کان پوء، اسان ماسٽر جي مرمت ڪئي، ريبوٽ ڪيو، Keepalived بلند ڪيو - اشتهارن کي بيڪ اپ جي ڀيٽ ۾ اعلي ترجيح سان اچي ٿو، ۽ بيڪ اپ خودڪار طريقي سان ڦري ٿو، IP پتي کي هٽائي ٿو، ڪو به دستي عمل ڪرڻ جي ضرورت ناهي.
ان ڪري، اسان خارجي IP پتي جي غلطي رواداري کي يقيني بڻايو آھي. ايندڙ حصو اهو آهي ته ڪنهن به طرح ٽرئفڪ کي بيلنس ڪرڻ لاءِ ٻاهرين IP پتي کان فوٽو روٽرز ڏانهن جيڪي اڳ ۾ ئي ختم ڪري رهيا آهن. توازن پروٽوڪول سان هر شيء بلڪل واضح آهي. اهو يا ته هڪ سادو گول رابن آهي، يا ٿورڙو وڌيڪ پيچيده شيون، wrr، لسٽ ڪنيڪشن وغيره. اهو بنيادي طور تي دستاويزن ۾ بيان ڪيو ويو آهي، ڪجهه خاص ناهي. پر پهچائڻ جو طريقو... هتي اسان هڪ ويجھو نظر وجهنداسين ڇو ته اسان انهن مان هڪ کي چونڊيو آهي. اهي آهن NAT، سڌي رستي ۽ TUN. حقيقت اها آهي ته اسان فوري طور تي سائيٽن مان 100 گيگا بائيٽ ٽرئفڪ پهچائڻ جو منصوبو ٺاهيو. جيڪڏهن توهان اندازو لڳايو، توهان کي 10 گيگابٽ ڪارڊ جي ضرورت آهي، صحيح؟ 10 گيگابٽ ڪارڊ هڪ سرور ۾ اڳ ۾ ئي گنجائش کان ٻاهر آهي، گهٽ ۾ گهٽ، اسان جي "معياري سامان" جو تصور. ۽ پوءِ اسان کي ياد آيو ته اسان صرف ڪجهه ٽريفڪ نه ٿا ڏيون ، اسان تصويرون ڏيون ٿا.
ڇا خاص آهي؟ - ايندڙ ۽ نڪرڻ واري ٽرئفڪ جي وچ ۾ وڏو فرق. ايندڙ ٽريفڪ تمام ننڍو آهي، ٻاهر وڃڻ واري ٽرئفڪ تمام وڏي آهي:
جيڪڏهن توهان انهن گرافس کي ڏسو، توهان ڏسي سگهو ٿا ته هن وقت ڊائريڪٽر 200 MB في سيڪنڊ حاصل ڪري رهيو آهي، اهو هڪ تمام عام ڏينهن آهي. اسان واپس ڏيون ٿا 4,500 MB في سيڪنڊ، اسان جو تناسب لڳ ڀڳ 1/22 آهي. اهو اڳ ۾ ئي واضح آهي ته 22 ورڪر سرورز کي مڪمل طور تي ٻاهر نڪرڻ واري ٽرئفڪ مهيا ڪرڻ لاء، اسان کي صرف هڪ ضرورت آهي جيڪو هن ڪنيڪشن کي قبول ڪري ٿو. اهو آهي جتي سڌو رستو الورورٿم اسان جي مدد لاء اچي ٿو.
اهو ڇا وانگر آهي؟ اسان جي فوٽو ڊائريڪٽر، هن جي ٽيبل جي مطابق، فوٽو روٽرز ڏانهن ڪنيڪشن منتقل ڪري ٿو. پر فوٽو روٽر واپسي ٽرئفڪ کي سڌو سنئون انٽرنيٽ ڏانهن موڪليندا آهن، ان کي ڪلائنٽ ڏانهن موڪليندا آهن، اهو فوٽو ڊائريڪٽر ذريعي واپس نه ٿو اچي، اهڙيء طرح، گهٽ ۾ گهٽ مشينن سان، اسان مڪمل غلطي رواداري ۽ سڀني ٽرئفڪ جي پمپنگ کي يقيني بڻائين ٿا. ترتيبن ۾ اهو هن طرح نظر اچي ٿو: اسان الگورتھم کي بيان ڪريون ٿا، اسان جي صورت ۾ اهو هڪ سادي rr آهي، سڌو رستو ڏيڻ جو طريقو مهيا ڪريو ۽ پوء سڀني حقيقي سرورن کي لسٽ ڪرڻ شروع ڪيو، انهن مان ڪيترا اسان وٽ آهن. جيڪو هن ٽريفڪ جو تعين ڪندو. جيڪڏهن اسان وٽ هڪ يا ٻه وڌيڪ سرور آهن، يا ڪيترائي سرور، اهڙي ضرورت پيدا ٿئي ٿي - اسان صرف هن حصي کي ترتيب ۾ شامل ڪيو ۽ تمام گهڻو پريشان نه ڪريو. حقيقي سرور جي پاسي کان، فوٽو روٽر جي پاسي کان، هي طريقو تمام گهٽ ۾ گهٽ ترتيب جي ضرورت آهي، اهو مڪمل طور تي دستاويز ۾ بيان ڪيو ويو آهي، ۽ اتي ڪو به نقصان نه آهي.
ڇا خاص طور تي سٺو آهي ته اهڙي حل جو مطلب مقامي نيٽ ورڪ جي بنيادي طور تي نئين ترتيب نه آهي؛ اهو اسان لاء اهم هو؛ اسان کي گهٽ ۾ گهٽ خرچن سان حل ڪرڻو پوندو. جيڪڏهن توهان ڏسندا ، پوءِ ڏسنداسين ته اهو ڇا ٿو لڳي. هتي اسان وٽ هڪ مخصوص ورچوئل سرور آهي، پورٽ 443 تي، ٻڌي ٿو، ڪنيڪشن قبول ڪري ٿو، سڀ ڪم ڪندڙ سرور درج ٿيل آهن، ۽ توهان ڏسي سگهو ٿا ته ڪنيڪشن آهي، ڏيو يا وٺو، ساڳيو. جيڪڏهن اسان ساڳئي ورچوئل سرور تي انگن اکرن تي نظر رکون ٿا، اسان وٽ ايندڙ پيڪيٽس، ايندڙ ڪنيڪشن آهن، پر بلڪل ٻاهر نڪرندڙ آهن. ٻاهر نڪرندڙ ڪنيڪشن سڌو سنئون ڪلائنٽ ڏانهن وڃو. ٺيڪ، اسان ان کي غير متوازن ڪرڻ جي قابل ٿي ويا. هاڻي، ڇا ٿيندو جيڪڏهن اسان جو هڪ فوٽو روٽر ناڪام ٿئي؟ سڀ کان پوء، لوهه لوهه آهي. اهو ٿي سگهي ٿو ڪني جي خوف ۾، اهو ڀڄي سگهي ٿو، بجلي جي فراهمي کي ساڙي سگھي ٿو. ڪا به شيءِ. اهو ئي سبب آهي ته صحت جي چڪاس جي ضرورت آهي. اهي آسان ٿي سگهن ٿا چيڪ ڪرڻ جي طور تي ته بندرگاهه ڪيئن کليل آهي، يا ڪجهه وڌيڪ پيچيده، ڪجهه گهر تي لکيل لکتن تائين جيڪي ڪاروباري منطق کي به چيڪ ڪندا.
اسان وچ ۾ ڪٿي روڪيو: اسان وٽ هڪ مخصوص جڳهه تي https جي درخواست آهي، اسڪرپٽ سڏيو ويندو آهي، جيڪڏهن اهو 200 هين جواب سان جواب ڏئي ٿو، اسان سمجهون ٿا ته هن سرور سان سڀ ڪجهه ٺيڪ آهي، ته اهو زنده آهي ۽ ڪافي آن ڪري سگهجي ٿو. آساني سان.
اهو ڪيئن، ٻيهر، عملي طور تي نظر اچي ٿو؟ اچو ته سار سنڀال لاءِ سرور کي بند ڪريون - BIOS کي چمڪائڻ، مثال طور. لاگن ۾، اسان وٽ فوري طور تي وقت ختم ٿي ويو آهي، اسان پهرين لائن ڏسون ٿا، پوء ٽن ڪوششن کان پوء اهو نشان لڳايو ويو آهي "ناڪام"، ۽ اهو صرف فهرست مان هٽايو ويو آهي.
هڪ ٻيو رويي جو اختيار پڻ ممڪن آهي، جڏهن VS صرف صفر تي سيٽ ڪيو ويو آهي، پر جيڪڏهن تصوير واپس ڪئي وئي آهي، اهو سٺو ڪم نٿو ڪري. سرور اچي ٿو، نينگڪس اتي شروع ٿئي ٿو، صحت جي چڪاس فوري طور تي سمجھي ٿو ته ڪنيڪشن ڪم ڪري رهيو آهي، اهو سڀ ڪجهه ٺيڪ آهي، ۽ سرور اسان جي لسٽ ۾ ظاهر ٿئي ٿو، ۽ لوڊ فوري طور تي ان تي لاڳو ٿيڻ شروع ٿئي ٿو. ڊيوٽي ايڊمنسٽريٽر کان ڪوبه دستي عمل گهربل ناهي. سرور رات جو ريبوٽ ٿيو - مانيٽرنگ ڊپارٽمينٽ اسان کي رات جو ان بابت نه سڏيندو آهي. اهي توهان کي خبر ڏيو ته اهو ٿيو، سڀ ڪجهه ٺيڪ آهي.
تنهن ڪري، بلڪل سادي طريقي سان، سرور جي هڪ ننڍڙي تعداد جي مدد سان، اسان خارجي غلطي رواداري جو مسئلو حل ڪيو.
اهو سڀ ڪجهه چيو وڃي ٿو ته اهو سڀ ڪجهه، يقينا، نگراني ڪرڻ جي ضرورت آهي. الڳ الڳ، اهو ياد رکڻ گهرجي ته Keepalivede، سافٽ ويئر جي طور تي هڪ ڊگهو وقت اڳ لکيو ويو آهي، ان کي مانيٽر ڪرڻ جا طريقا آهن، ٻنهي ذريعي چيڪ استعمال ڪندي DBus، SMTP، SNMP، ۽ معياري Zabbix. ان کان علاوه، هو پاڻ ڄاڻي ٿو ته تقريباً هر ڇڪ لاءِ خط ڪيئن لکڻا آهن، ۽ سچ پڇو ته، ڪنهن وقت اسان ان کي بند ڪرڻ جو به سوچيو هو، ڇاڪاڻ ته هو هر IP ڪنيڪشن لاءِ، ڪنهن به ٽريفڪ جي سوئچنگ، سوئچ آن ڪرڻ لاءِ ڪيترائي خط لکي ٿو، ۽ ايئن . يقينا، جيڪڏهن تمام گهڻا سرور آهن، ته پوء توهان انهن خطن سان پنهنجو پاڻ کي ختم ڪري سگهو ٿا. اسان معياري طريقن کي استعمال ڪندي فوٽو روٽرز تي نينڪس جي نگراني ڪندا آهيون، ۽ هارڊويئر مانيٽرنگ نه ٿي چڪي آهي. اسان، يقينا، ٻه وڌيڪ شيون مشورو ڏينداسين: پهريون، ٻاهرين صحت جي چڪاس ۽ دستيابي، ڇاڪاڻ ته جيتوڻيڪ سڀ ڪجهه ڪم ڪري ٿو، حقيقت ۾، شايد صارفين کي فوٽو نه ملي سگھن ٿيون، ٻاهرين فراهم ڪندڙن جي مسئلن جي ڪري يا ڪجهه وڌيڪ پيچيده. اهو هميشه ڪنهن ٻئي نيٽ ورڪ تي رکڻ جي قابل آهي، Amazon ۾ يا ڪنهن ٻئي هنڌ، هڪ الڳ مشين جيڪا توهان جي سرور کي ٻاهران پنگ ڪري سگهي ٿي، ۽ اهو پڻ استعمال ڪرڻ جي قابل آهي يا ته بي ترتيبي ڳولڻ، انهن لاءِ جيڪي ڄاڻن ٿا ته مشڪل مشين سکيا ڪيئن ڪجي، يا سادي نگراني. , گهٽ ۾ گهٽ ٽريڪ ڪرڻ لاء جيڪڏهن درخواستون تيزيء سان گهٽجي ويا آهن، يا، ان جي ابتڙ، وڌي ويا آهن. اهو پڻ مفيد ٿي سگهي ٿو.
اچو ته اختصار ڪريون: اسان، حقيقت ۾، لوهه سان ڍڪيل حل کي تبديل ڪيو، جيڪو ڪجهه وقت تي اسان کي مناسب ڪرڻ بند ڪري ڇڏيو، هڪ بلڪل سادي سسٽم سان جيڪو سڀ ڪجهه ساڳيو ڪري ٿو، اهو آهي، اهو HTTPS ٽرئفڪ کي ختم ڪرڻ ۽ وڌيڪ سمارٽ روٽنگ فراهم ڪري ٿو. ضروري صحت جي چڪاس. اسان هن سسٽم جي استحڪام کي وڌايو آهي، اهو آهي ته، اسان وٽ اڃا تائين هر پرت لاء اعلي دستياب آهي، انهي سان گڏ اسان وٽ اهو بونس آهي ته اهو هر پرت تي ان کي ماپ ڪرڻ بلڪل آسان آهي، ڇاڪاڻ ته اهو معياري سافٽ ويئر سان معياري هارڊويئر آهي، اهو آهي. ، اسان ممڪن مسئلن جي تشخيص کي آسان ڪيو آهي.
اسان آخر ڇا ڪيو؟ اسان کي 2018 جي جنوري جي موڪلن دوران هڪ مسئلو هو. پهرين ڇهن مهينن ۾ جڏهن اسان هن اسڪيم کي عمل ۾ آندو، اسان ان کي سڀني ٽريفڪ ڏانهن وڌايو ته جيئن LTM کان سموري ٽرئفڪ کي هٽايو وڃي، اسان صرف هڪ ڊيٽا سينٽر ۾ 40 گيگا بٽ کان 60 گيگا بٽ تائين ٽريفڪ وڌائي، ۽ ساڳئي وقت سڄو 2018 سال في سيڪنڊ تقريبا ٽي ڀيرا وڌيڪ تصويرون موڪلڻ جي قابل هئا.
جو ذريعو: www.habr.com