هڪ-ڪڪر - Odnoklassniki ۾ ڊيٽا سينٽر سطح او ايس

الاءِ، ماڻهو! منهنجو نالو Oleg Anastasyev آهي، مان پليٽ فارم ٽيم ۾ Odnoklassniki ۾ ڪم ڪريان ٿو. ۽ مون کان علاوه، Odnoklassniki ۾ تمام گهڻو هارڊويئر ڪم ڪري رهيو آهي. اسان وٽ چار ڊيٽا سينٽر آهن جن ۾ اٽڪل 500 ريڪ آهن 8 هزار کان وڌيڪ سرورن سان. هڪ خاص نقطي تي، اسان محسوس ڪيو ته نئين انتظامي نظام جو تعارف اسان کي سامان کي وڌيڪ موثر انداز ۾ لوڊ ڪرڻ، رسائي جي انتظام کي آسان ڪرڻ، ڪمپيوٽنگ وسيلن جي (ٻيهر) ورڇ کي خودڪار ڪرڻ، نئين خدمتن جي لانچ کي تيز ڪرڻ، ۽ جوابن کي تيز ڪرڻ جي اجازت ڏيندو. وڏي پيماني تي حادثا.

ان مان ڇا نڪتو؟

مون کان علاوه ۽ هارڊويئر جو هڪ گروپ، اهڙا ماڻهو پڻ آهن جيڪي هن هارڊويئر سان ڪم ڪن ٿا: انجنيئر جيڪي سڌو سنئون ڊيٽا سينٽرن ۾ واقع آهن؛ نيٽ ورڪرز جيڪي نيٽ ورڪ سافٽ ويئر قائم ڪن ٿا؛ منتظمين، يا SREs، جيڪي بنيادي ڍانچي جي لچڪ مهيا ڪن ٿا؛ ۽ ترقياتي ٽيمون، انهن مان هر هڪ پورٽل جي ڪم جي حصي لاء ذميوار آهي. سافٽ ويئر اهي ٺاهي رهيا آهن ڪجهه هن طرح ڪم ڪري ٿو:

صارف جون درخواستون مليون آهن ٻنهي مکيه پورٹل جي محاذن تي www.ok.ru، ۽ ٻين تي، مثال طور ميوزڪ API فرنٽ تي. ڪاروباري منطق کي پروسيس ڪرڻ لاء، اهي ايپليڪيشن سرور کي سڏين ٿا، جيڪو، درخواست جي پروسيسنگ دوران، ضروري خاص مائڪرو سروسز کي سڏيندو آهي - هڪ گراف (سماجي رابطن جو گراف)، صارف-ڪيش (يوزر پروفائلز جو ڪيش) وغيره.

انهن خدمتن مان هر هڪ ڪيترن ئي مشينن تي لڳايو ويو آهي، ۽ انهن مان هر هڪ ذميوار ڊولپرز آهن جيڪي ماڊلز جي ڪم، انهن جي آپريشن ۽ ٽيڪنالاجي ترقي لاء ذميوار آهن. اهي سڀئي خدمتون هارڊويئر سرورز تي هلن ٿيون، ۽ تازو ئي اسان في سرور تي هڪ ڪم شروع ڪيو، يعني اهو مخصوص ڪم لاءِ مخصوص ڪيو ويو هو.

ائين ڇو آهي؟ هن طريقي جا ڪيترائي فائدا هئا:

• رليف ٿيل ڪاميٽي جو انتظام. اچو ته هڪ ڪم لاءِ ڪجهه لائبريريون، ڪجهه سيٽنگون گهرجن. ۽ پوءِ سرور کي مقرر ڪيو ويو آهي بلڪل هڪ مخصوص گروپ، هن گروپ لاءِ cfengine پاليسي بيان ڪئي وئي آهي (يا اهو اڳ ۾ ئي بيان ڪيو ويو آهي)، ۽ هي ترتيب مرڪزي طور تي ۽ خودڪار طريقي سان هن گروپ جي سڀني سرورن ڏانهن وڌايو ويندو آهي.
• سمايل تشخيص. اچو ته چئو ته توهان مرڪزي پروسيسر تي وڌندڙ لوڊ کي ڏسو ۽ محسوس ڪيو ته اهو لوڊ صرف انهي ڪم ذريعي پيدا ٿي سگهي ٿو جيڪو هن هارڊويئر پروسيسر تي هلندو آهي. ڪنهن کي الزام ڏيڻ جي ڳولا تمام جلدي ختم ٿي ويندي آهي.
• سمايل نگراني. جيڪڏهن سرور سان ڪجهه غلط آهي، مانيٽر ان کي رپورٽ ڪري ٿو، ۽ توهان کي خبر آهي ته ڪير ذميوار آهي.

هڪ خدمت ڪيترن ئي نقلن تي مشتمل آهي ڪيترن ئي سرورن کي مختص ڪيو ويو آهي - هر هڪ لاءِ. پوءِ خدمت لاءِ ڪمپيوٽنگ جو وسيلو تمام سادو مختص ڪيو ويو آهي: خدمت جي سرورن جو تعداد، وسيلن جو وڌ ۾ وڌ مقدار جيڪو استعمال ڪري سگھي ٿو. هتي "آسان" جو مطلب اهو ناهي ته اهو استعمال ڪرڻ آسان آهي، پر ان معنى ۾ ته وسيلن جي مختص دستي طور تي ڪئي وئي آهي.

اهو طريقو به اسان کي ڪرڻ جي اجازت ڏني خاص لوهه جي جوڙجڪ هن سرور تي هلندڙ ڪم لاءِ. جيڪڏهن اهو ڪم ڊيٽا جي وڏي مقدار کي ذخيرو ڪري ٿو، پوء اسان 4U سرور استعمال ڪندا آهيون هڪ چيسس سان 38 ڊسڪ سان. جيڪڏهن ڪم خالص طور تي ڪمپيوٽيشنل آهي، ته پوء اسان هڪ سستا 1U سرور خريد ڪري سگهون ٿا. اهو ڪمپيوٽنگ طور تي موثر آهي. ٻين شين جي وچ ۾، هي طريقو اسان کي چار ڀيرا گھٽ مشينون استعمال ڪرڻ جي اجازت ڏئي ٿو جيڪو هڪ دوستانه سماجي نيٽ ورڪ جي مقابلي ۾ لوڊ سان.

ڪمپيوٽنگ وسيلن جي استعمال ۾ اهڙي ڪارڪردگي پڻ اقتصادي ڪارڪردگي کي يقيني بڻائڻ گهرجي، جيڪڏهن اسان ان بنياد کان اڳتي وڌون ٿا ته سڀ کان وڌيڪ قيمتي شيء سرور آهي. هڪ ڊگهي وقت تائين، هارڊويئر سڀ کان مهانگو هو، ۽ اسان هارڊويئر جي قيمت کي گهٽائڻ ۾ تمام گهڻي ڪوشش ڪئي، هارڊويئر جي اعتبار جي گهرج کي گهٽائڻ لاءِ غلطي برداشت ڪرڻ واري الگورتھم سان گڏ. ۽ اڄ اسان ان اسٽيج تي پهچي چڪا آهيون جنهن تي سرور جي قيمت فيصلو ڪندڙ ٿيڻ بند ٿي وئي آهي. جيڪڏهن توهان جديد exotics تي غور نه ڪندا، ته پوء ريڪ ۾ سرور جي مخصوص تشڪيل ڪا به اهميت نه رکندو آھي. هاڻي اسان وٽ هڪ ٻيو مسئلو آهي - ڊيٽا سينٽر ۾ سرور تي قبضو ڪيل جڳهه جي قيمت، اهو آهي، ريڪ ۾ خلا.

اهو محسوس ڪندي ته اهو معاملو هو، اسان اهو ڳڻڻ جو فيصلو ڪيو ته اسان ريڪ کي ڪيئن استعمال ڪري رهيا آهيون.
اسان سڀ کان وڌيڪ طاقتور سرور جي قيمت اقتصادي طور تي جائز ماڻهن کان ورتي، حساب ڪيو ته ڪيترا اهڙا سرور اسان ريڪ ۾ رکي سگهون ٿا، ڪيترا ڪم اسان انهن تي هلندا هئاسين، پراڻي ماڊل جي بنياد تي "هڪ سرور = هڪ ڪم" ۽ ڪيترو. ڪم سامان استعمال ڪري سگهو ٿا. اهي ڳوڙها ڳاڙيندا هئا. اهو ظاهر ٿيو ته ريڪ استعمال ڪرڻ ۾ اسان جي ڪارڪردگي اٽڪل 11٪ آهي. نتيجو واضح آهي: اسان کي ڊيٽا سينٽر استعمال ڪرڻ جي ڪارڪردگي وڌائڻ جي ضرورت آهي. اهو لڳي ٿو ته حل واضح آهي: توهان کي هڪ ئي وقت ۾ هڪ سرور تي ڪيترن ئي ڪمن کي هلائڻ جي ضرورت آهي. پر هي آهي جتي مشڪلاتن جي شروعات.

ماس ڪنفيگريشن ڊرامي طور تي وڌيڪ پيچيده ٿي ويندي آهي - اهو هاڻي ناممڪن آهي ته ڪنهن هڪ گروهه کي سرور تي تفويض ڪرڻ. آخرڪار، هاڻي مختلف ڪمن جا ڪيترائي ڪم هڪ سرور تي شروع ڪري سگهجن ٿيون. اضافي طور تي، ترتيب مختلف ايپليڪيشنن لاء تڪرار ٿي سگهي ٿي. تشخيص پڻ وڌيڪ پيچيده ٿي ويندي آهي: جيڪڏهن توهان سرور تي سي پي يو يا ڊسڪ جي استعمال کي وڌايو، توهان کي خبر ناهي ته ڪهڙو ڪم مصيبت جو سبب آهي.

پر بنيادي شيء اها آهي ته ساڳئي مشين تي هلندڙ ڪمن جي وچ ۾ ڪو به اڪيلائي نه آهي. هتي، مثال طور، هڪ سرور ٽاسڪ جي اوسط جوابي وقت جو گراف آهي ان کان اڳ ۽ پوءِ ساڳئي سرور تي هڪ ٻي ڪمپيوٽيشنل ايپليڪيشن شروع ڪئي وئي هئي، ڪنهن به طريقي سان پهرين سان لاڳاپيل ناهي - مکيه ڪم جو جوابي وقت گهڻو وڌي ويو آهي.

ظاهر آهي، توهان کي ڪم هلائڻ جي ضرورت آهي يا ته ڪنٽينرز ۾ يا ورچوئل مشينن ۾. جيئن ته اسان جا لڳ ڀڳ سڀئي ڪم هڪ او ايس (لينڪس) جي تحت هلندا آهن يا ان لاءِ ٺاهيا ويا آهن، اسان کي ضرورت ناهي ته ڪيترن ئي مختلف آپريٽنگ سسٽم کي سپورٽ ڪرڻ جي. ان جي مطابق، ورچوئلائيزيشن جي ضرورت ناهي؛ اضافي اوور هيڊ جي ڪري، اهو ڪنٽينرائيزيشن کان گهٽ موثر ٿيندو.

جيئن سرورز تي سڌو سنئون ڪمن کي هلائڻ لاءِ ڪنٽينرز جي عمل درآمد لاءِ، ڊاڪر هڪ سٺو اميدوار آهي: فائيل سسٽم جون تصويرون متضاد ترتيبن سان چڱيءَ طرح مسئلا حل ڪن ٿيون. حقيقت اها آهي ته تصويرون ڪيترن ئي تہن مان ٺهيل ٿي سگهن ٿيون، اسان کي بنيادي طور تي بنيادي طور تي انهن کي ترتيب ڏيڻ لاء گهربل ڊيٽا جي مقدار کي گھٽائڻ جي اجازت ڏئي ٿي، عام حصن کي الڳ الڳ بنيادي تہن ۾ الڳ ڪري ٿو. پوءِ بنيادي (۽ گھڻيون وڏيون) تہن کي پوري انفراسٽرڪچر ۾ تمام تيزيءَ سان ڪيش ڪيو ويندو، ۽ ڪيترن ئي قسمن جي ايپليڪيشنن ۽ ورزن کي پهچائڻ لاءِ، صرف ننڍڙن تہن کي منتقل ڪرڻ جي ضرورت پوندي.

ان سان گڏ، ڊاڪر ۾ هڪ تيار ٿيل رجسٽري ۽ تصويري ٽيگنگ اسان کي نسخن ۽ پيداوار لاءِ ڪوڊ پهچائڻ لاءِ تيار ڪيل پرائمٽيوز ڏيو.

Docker، ڪنهن ٻئي ساڳي ٽيڪنالاجي وانگر، اسان کي فراهم ڪري ٿو ڪجهه سطح جي ڪنٽينر جي اڪيلائي کي دٻي کان ٻاهر. مثال طور، ميموري آئسوليشن - هر ڪنٽينر کي مشين ميموري جي استعمال تي هڪ حد ڏني وئي آهي، جنهن کان ٻاهر اهو استعمال نه ڪندو. توهان پڻ CPU استعمال جي بنياد تي ڪنٽينرز کي الڳ ڪري سگهو ٿا. اسان لاء، جيتوڻيڪ، معياري موصليت ڪافي نه هئي. پر هيٺ ڏنل تي وڌيڪ.

سرور تي سڌو سنئون ڪنٽينر هلائڻ صرف مسئلو جو حصو آهي. ٻيو حصو سرور تي ميزباني ڪنٽينرز سان لاڳاپيل آهي. توھان کي سمجھڻ گھرجي ته ڪھڙو ڪنٽينر رکي سگھجي ٿو جنھن سرور تي. اهو ايترو آسان ڪم نه آهي، ڇاڪاڻ ته ڪنٽينرز کي انهن جي رفتار کي گهٽائڻ کان سواءِ جيترو ممڪن ٿي سگهي سرور تي رکڻو پوندو. اهڙي جڳهه کي غلطي رواداري جي نقطي نظر کان پڻ ڏکيو ٿي سگهي ٿو. گهڻو ڪري اسان چاهيون ٿا ته ساڳي خدمت جي نقلن کي مختلف ريڪ ۾ يا ڊيٽا سينٽر جي مختلف ڪمرن ۾، انهي ڪري ته جيڪڏهن ڪو ريڪ يا ڪمرو ناڪام ٿئي، اسان فوري طور تي سڀني خدمت جي نقلن کي نه وڃايو.

ڪنٽينرز کي دستي طور تي ورهائڻ ڪو اختيار ناهي جڏهن توهان وٽ 8 هزار سرور ۽ 8-16 هزار ڪنٽينرز آهن.

ان کان علاوه، اسان ڊولپرز کي وسيلن جي مختص ڪرڻ ۾ وڌيڪ آزادي ڏيڻ چاهيون ٿا ته جيئن اهي منتظم جي مدد کان سواءِ، پيداوار ۾ پنهنجون خدمتون خود ميزباني ڪري سگهن. ساڳئي وقت، اسان ڪنٽرول کي برقرار رکڻ چاهيندا هئاسين ته ڪجهه معمولي خدمت اسان جي ڊيٽا سينٽرن جي سڀني وسيلن کي استعمال نه ڪن ها.

ظاهر آهي، اسان کي هڪ ڪنٽرول پرت جي ضرورت آهي جيڪا خودڪار طريقي سان ڪندي.

تنهنڪري اسان هڪ سادي ۽ سمجھڻ واري تصوير تي آيا آهيون جنهن کي سڀئي معمار پسند ڪن ٿا: ٽي چورس.

ون ڪلائوڊ ماسٽرس ڪلائوڊ آرڪيسٽريشن لاءِ ذميوار هڪ ناڪام ڪلستر آهي. ڊولپر ماسٽر ڏانهن هڪ منشور موڪلي ٿو، جنهن ۾ خدمت کي ميزباني ڪرڻ لاءِ ضروري معلومات شامل آهي. ان جي بنياد تي، ماسٽر چونڊيل منائن کي حڪم ڏئي ٿو (مشينون جيڪي ڪنٽينرز کي هلائڻ لاء ڊزائين ڪيل آھن). منن وٽ اسان جو ايجنٽ آهي، جيڪو ڪمانڊ وصول ڪري ٿو، ان جو حڪم جاري ڪري ٿو Docker ڏانهن، ۽ Docker ترتيب ڏئي ٿو لينڪس ڪنيل کي لاڳاپيل ڪنٽينر کي لانچ ڪرڻ لاءِ. حڪمن تي عمل ڪرڻ کان علاوه، ايجنٽ مسلسل ماسٽر کي رپورٽ ڪري ٿو ٻنهي منين مشين ۽ ان تي هلندڙ ڪنٽينرز جي حالت ۾ تبديلين بابت.

رَسَپُرِدِيَلِينِي رَسُرُسَوَ

هاڻي اچو ته ڪيترن ئي منائن لاءِ وڌيڪ پيچيده وسيلن جي مختص جي مسئلي تي نظر وجهون.

ھڪڙي ڪلائوڊ ۾ ھڪڙي ڪمپيوٽنگ وسيلو آھي:

• پروسيسر جي طاقت جو مقدار هڪ مخصوص ڪم ذريعي استعمال ڪيو ويو آهي.
• ڪم لاءِ موجود ميموري جو مقدار.
• نيٽورڪ ٽرئفڪ. مائنز مان هر هڪ وٽ محدود بينڊوڊٿ سان هڪ مخصوص نيٽ ورڪ انٽرفيس هوندو آهي، تنهن ڪري ڪمن کي ورهائڻ ناممڪن آهي بغير ڪنهن حساب ۾ ڊيٽا جي مقدار کي جيڪي اهي نيٽ ورڪ تي منتقل ڪن ٿا.
• ڊسڪ. اضافي طور تي، واضح طور تي، انهن ڪمن لاء جاء تي، اسان پڻ ڊسڪ جو قسم مختص ڪريون ٿا: HDD يا SSD. ڊسڪ في سيڪنڊ درخواستن جي هڪ محدود تعداد جي خدمت ڪري سگهي ٿو - IOPS. تنهن ڪري، انهن ڪمن لاءِ جيڪي هڪ ڊسڪ کان وڌيڪ IOPS ٺاهي سگھن ٿا، اسان پڻ مختص ڪريون ٿا ”اسپنڊلز“ - يعني، ڊسڪ ڊوائيسز جيڪي خاص طور تي ڪم لاءِ مخصوص ٿيڻ گهرجن.

پوءِ ڪجھ خدمت لاءِ، مثال طور يوزر ڪيش لاءِ، اسان استعمال ٿيل وسيلن کي ھن طريقي سان رڪارڊ ڪري سگھون ٿا: 400 پروسيسر ڪور، ميموري جو 2,5 TB، 50 Gbit/s ٽريفڪ ٻنهي طرفن ۾، 6 TB HDD اسپيس جو 100 اسپنڊلز تي واقع آھي. يا هن طرح هڪ وڌيڪ واقف فارم ۾:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

صارف-ڪيش سروس وسيلن کي صرف پيداوار جي انفراسٽرڪچر ۾ موجود سڀني وسيلن جو هڪ حصو استعمال ڪري ٿو. تنهن ڪري، مان پڪ ڪرڻ چاهيان ٿو ته اوچتو، آپريٽر جي غلطي جي ڪري يا نه، صارف-ڪيش ان کي مختص ڪيل وسيلن کان وڌيڪ وسيلن کي استعمال نٿو ڪري. اهو آهي، اسان کي وسيلن کي محدود ڪرڻ گهرجي. پر اسان ڪوٽا کي ڇا سان ڳنڍي سگهون ٿا؟

اچو ته اجزاء جي رابطي جي اسان جي تمام آسان ٿيل ڊراگرام ڏانھن واپس وڃو ۽ ان کي وڌيڪ تفصيل سان ٻيهر ٺاھيو - جھڙوڪ:

ڇا توهان جي اکين کي پڪڙي ٿو:

• ويب فرنٽ اينڊ ۽ ميوزڪ ساڳئي ايپليڪيشن سرور جي الڳ ٿيل ڪلستر استعمال ڪن ٿا.
• اسان منطقي تہن ۾ فرق ڪري سگھون ٿا جن سان اھي ڪلستر آھن: فرنٽ، ڪيش، ڊيٽا اسٽوريج ۽ مئنيجمينٽ پرت.
• فرنٽ اينڊ هيٽروجنيئس آهي؛ اهو مختلف فنڪشنل سب سسٽم تي مشتمل آهي.
• ڪيش به ان سب سسٽم ۾ پکڙيل ٿي سگهن ٿا جن جي ڊيٽا اهي ڪيش ڪن ٿا.

اچو ته تصوير کي ٻيهر ٺاھيون:

به! ها، اسان ڏسون ٿا هڪ ترتيب وار! ان جو مطلب اهو آهي ته توهان وسيلن کي وڏين حصن ۾ ورهائي سگهو ٿا: هڪ ذميوار ڊولپر کي تفويض ڪريو هن درجي بندي جي نوڊ تي جيڪو فنڪشنل سب سسٽم سان لاڳاپيل آهي (جهڙوڪ "موسيقي" تصوير ۾)، ۽ هڪ ڪوٽا ڳنڍيو درجه بندي جي ساڳئي سطح تي. هي درجه بندي اسان کي اجازت ڏئي ٿي ته اسان کي انتظام جي آسانيءَ لاءِ وڌيڪ لچڪدار طريقي سان خدمتون ترتيب ڏيو. مثال طور، اسان سڀني ويب کي ورهايو، ڇاڪاڻ ته هي سرورز جو هڪ تمام وڏو گروپ آهي، ڪيترن ئي ننڍن گروپن ۾، تصوير ۾ گروپ 1، گروپ 2 طور ڏيکاريل آهي.

اضافي لائينن کي هٽائڻ سان، اسان اسان جي تصوير جي هر نوڊ کي فليٽ فارم ۾ لکي سگهون ٿا: group1.web.front, api.music.front, user-cache.cache.

اهڙيءَ طرح اسان ”حيرتياتي قطار“ جي تصور تي پهتا آهيون. ان جو نالو آهي "group1.web.front". وسيلن ۽ صارف جي حقن لاء ڪوٽا ان کي لڳايو ويو آهي. اسان DevOps مان هڪ شخص کي قطار ۾ خدمت موڪلڻ جا حق ڏينداسين، ۽ اهڙو ملازم قطار ۾ ڪجهه شروع ڪري سگهي ٿو، ۽ OpsDev جي شخص کي انتظامي حق حاصل هوندا، ۽ هاڻي هو قطار کي منظم ڪري سگهي ٿو، اتي ماڻهن کي تفويض ڪري، انهن ماڻهن کي حق ڏيو، وغيره. هن قطار تي هلندڙ خدمتون قطار جي ڪوٽا اندر هلنديون. جيڪڏهن قطار جي ڪمپيوٽنگ ڪوٽا سڀني خدمتن کي هڪ ئي وقت تي عمل ڪرڻ لاءِ ڪافي نه آهي، ته پوءِ انهن کي ترتيب وار عمل ڪيو ويندو، اهڙيءَ طرح قطار پاڻ ٺاهيندي.

اچو ته خدمتن تي هڪ ويجهي نظر رکون. ھڪڙي خدمت ھڪڙي مڪمل طور تي قابل نالو آھي، جنھن ۾ هميشه قطار جو نالو شامل آھي. پوءِ سامهون واري ويب سروس جو نالو هوندو ok-web.group1.web.front. ۽ ايپليڪيشن سرور سروس جيڪا ان تائين پهچندي ان کي سڏيو ويندو ok-app.group1.web.front. هر خدمت ۾ هڪ پڌرو هوندو آهي، جيڪو مخصوص مشينن تي لڳائڻ لاءِ تمام ضروري معلومات بيان ڪري ٿو: هي ڪم ڪيترا وسيلا استعمال ڪري ٿو، ان لاءِ ڪهڙي ترتيب جي ضرورت آهي، ڪيتريون ئي نقلون هجڻ گهرجن، هن خدمت جي ناڪامين کي سنڀالڻ لاءِ ملڪيتون. ۽ خدمت کان پوء سڌو سنئون مشين تي رکيل آهي، ان جا مثال ظاهر ٿيندا آهن. انهن جو نالو پڻ غير واضح طور تي رکيو ويو آهي - مثال نمبر ۽ خدمت جو نالو: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

اهو تمام آسان آهي: صرف هلندڙ ڪنٽينر جي نالي کي ڏسڻ سان، اسان فوري طور تي گهڻو ڪجهه ڳولي سگهون ٿا.

هاڻي اچو ته هڪ ويجهي نظر رکون ته اهي مثال اصل ۾ انجام ڏين ٿا: ڪم.

ٽاسڪ آئسوليشن ڪلاس

OK ۾ سڀ ڪم (۽، شايد، هر جڳهه) گروپن ۾ ورهائي سگهجن ٿا:

• مختصر ويڪرائي ڪم - prod. اهڙين ڪمن ۽ خدمتن لاءِ، جواب جي دير (ويڪرائي) تمام ضروري آهي، ته هر هڪ درخواست تي سسٽم طرفان ڪيترو جلدي عمل ڪيو ويندو. ڪمن جا مثال: ويب فرنٽ، ڪيش، ايپليڪيشن سرور، OLTP اسٽوريج، وغيره.
• حسابي مسئلا - بيچ. هتي، هر مخصوص درخواست جي پروسيسنگ جي رفتار اهم ناهي. انهن لاءِ، اهو ضروري آهي ته اهو ڪم ڪنهن خاص (ڊگهي) عرصي ۾ (ذريعي) ڪيتري حساب سان ڪندو. اهي MapReduce، Hadoop، مشين سکيا، شماريات جا ڪم هوندا.
• پس منظر جا ڪم - بيڪار. اھڙن ڪمن لاءِ، نه ئي دير ۽ نه ئي انتھپٽ تمام ضروري آھن. ھن ۾ شامل آھن مختلف ٽيسٽون، لڏپلاڻ، حساب ڪتاب، ۽ ڊيٽا کي ھڪ فارميٽ کان ٻئي ۾ تبديل ڪرڻ. هڪ طرف، اهي ڳڻپيوڪر سان ملندڙ جلندڙ آهن، ٻئي طرف، اهو اسان لاء اهم ناهي ته اهي ڪيئن جلدي مڪمل ڪيا ويا آهن.

اچو ته ڏسو ته ڪئين ڪم وسيلن کي استعمال ڪن ٿا، مثال طور، مرڪزي پروسيسر.

مختصر دير وارا ڪم. اهڙي ڪم ۾ CPU واپرائڻ وارو نمونو هن جهڙو هوندو:

پروسيسنگ لاءِ صارف کان هڪ درخواست ملي ٿي، ڪم شروع ٿئي ٿو سڀ موجود سي پي يو ڪور استعمال ڪرڻ، ان کي پروسيس ڪري ٿو، جواب ڏئي ٿو، ايندڙ درخواست جو انتظار ڪري ٿو ۽ روڪي ٿو. ايندڙ درخواست اچي وئي - ٻيهر اسان سڀ ڪجهه چونڊيو جيڪو اتي هو، ان جو حساب ڪيو، ۽ ايندڙ لاء انتظار ڪري رهيا آهيون.

اهڙي ڪم لاءِ گهٽ ۾ گهٽ دير جي ضمانت ڏيڻ لاءِ، اسان کي لازمي طور تي وڌ ۾ وڌ وسيلا وٺڻ گهرجن جيڪي ان کي استعمال ڪن ٿا ۽ منين تي گهربل تعداد کي محفوظ ڪريون (اها مشين جيڪا ڪم کي انجام ڏيندي). پوء اسان جي مسئلي لاء رزرويشن فارمولا هن ريت ٿيندو:

alloc: cpu = 4 (max)

۽ جيڪڏهن اسان وٽ 16 ڪورن سان گڏ هڪ منين مشين آهي، ته پوءِ ان تي چار اهڙا ڪم رکي سگهجن ٿا. اسان خاص طور تي ياد رکون ٿا ته اهڙين ڪمن جي اوسط پروسيسر واپرائڻ اڪثر ڪري تمام گهٽ آهي - جيڪو واضح آهي، ڇاڪاڻ ته وقت جو هڪ اهم حصو هڪ درخواست جو انتظار ڪري ٿو ۽ ڪجهه به نه ڪندو آهي.

حساب ڪتاب جا ڪم. انهن جو نمونو ٿورو مختلف ٿيندو:

اهڙين ڪمن لاءِ سراسري سي پي يو وسيلن جو استعمال تمام گهڻو آهي. گهڻو ڪري اسان چاهيون ٿا ته حساب ڪتاب جو ڪم هڪ خاص وقت ۾ مڪمل ٿئي، ان ڪري اسان کي ضرورت آهي ته پروسيسرز جو گهٽ ۾ گهٽ تعداد محفوظ رکون ته جيئن سمورو ڳڻپ قابل قبول وقت ۾ مڪمل ٿئي. ان جو رزرويشن فارمولا هن طرح نظر ايندو:

alloc: cpu = [1,*)

"مهرباني ڪري ان کي ھڪڙي منين تي رکو جتي گھٽ ۾ گھٽ ھڪڙو مفت ڪور آھي، ۽ پوء جيتري قدر آھن، اھو سڀ ڪجھ کائي ويندو."

هتي استعمال جي ڪارڪردگي اڳ ۾ ئي تمام گهڻو بهتر آهي ڪمن تي ٿوري دير سان. پر فائدو تمام گهڻو ٿيندو جيڪڏهن توهان ٻنهي قسمن جي ڪمن کي هڪ ميني مشين تي گڏ ڪيو ۽ ان جا وسيلا هلندي هلندي ورهايو. جڏهن هڪ ڪم ٿوري دير سان هڪ پروسيسر جي ضرورت آهي، اهو ان کي فوري طور تي حاصل ڪري ٿو، ۽ جڏهن وسيلن جي ضرورت نه هوندي آهي، اهي ڪمپيوٽيشنل ٽاسڪ ڏانهن منتقل ڪيا ويندا آهن، يعني ڪجهه هن طرح:

پر اهو ڪيئن ڪجي؟

پهرين، اچو ته prod ۽ ان جي مختص کي ڏسو: cpu = 4. اسان کي چار ڪور محفوظ ڪرڻ گهرجن. Docker رن ۾ اهو ٻن طريقن سان ٿي سگهي ٿو:

• اختيار سان --cpuset=1-4، يعني مشين تي چار مخصوص ڪور کي ڪم لاءِ مختص ڪريو.
• استعمال ڪريو --cpuquota=400_000 --cpuperiod=100_000، پروسيسر جي وقت لاءِ ڪوٽا مقرر ڪريو، يعني ظاهر ڪريو ته هر 100 ms حقيقي وقت جو ڪم 400 ms کان وڌيڪ پروسيسر وقت استعمال نٿو ڪري. ساڳيا چار ڪور حاصل ڪيا ويا آهن.

پر انهن مان ڪهڙو طريقو مناسب آهي؟

cpuset ڪافي پرڪشش نظر اچي ٿو. ڪم ۾ چار وقف ٿيل ڪور آهن، جنهن جو مطلب آهي ته پروسيسر ڪيچ ممڪن طور تي ڪم ڪندو. ان جو پڻ هڪ نقصان آهي: اسان کي OS جي بدران مشين جي اڻ لوڊ ٿيل ڪور ۾ حسابن کي ورهائڻ جو ڪم کڻڻو پوندو، ۽ اهو هڪ بلڪه غير معمولي ڪم آهي، خاص طور تي جيڪڏهن اسان ڪوشش ڪريون ته بيچ ٽاسڪ کي اهڙي قسم تي. مشين ٽيسٽ ڏيکاريا آهن ته ڪوٽا سان اختيار هتي بهتر آهي: هن طريقي سان آپريٽنگ سسٽم کي موجوده وقت تي ڪم انجام ڏيڻ لاء بنيادي چونڊڻ ۾ وڌيڪ آزادي آهي ۽ پروسيسر جو وقت وڌيڪ موثر انداز ۾ ورهايو ويو آهي.

اچو ته اهو معلوم ڪريون ته ڊڪر ۾ رزرويشن ڪيئن ڪجي گهٽ ۾ گهٽ ڪور جي بنياد تي. بيچ جي ڪمن لاء ڪوٽا هاڻي لاڳو نه آهي، ڇو ته وڌ ۾ وڌ کي محدود ڪرڻ جي ڪا ضرورت ناهي، اهو صرف گهٽ ۾ گهٽ ضمانت ڏيڻ لاء ڪافي آهي. ۽ هتي اختيار مناسب آهي docker run --cpushares.

اسان اتفاق ڪيو ته جيڪڏهن هڪ بيچ گهٽ ۾ گهٽ هڪ ڪور جي ضمانت جي ضرورت آهي، پوء اسان اشارو ڪيو --cpushares=1024، ۽ جيڪڏهن گهٽ ۾ گهٽ ٻه ڪور آهن، ته پوء اسان اشارو ڪندا آهيون --cpushares=2048. سي پي يو شيئرز پروسيسر جي وقت جي تقسيم سان ڪنهن به طريقي سان مداخلت نه ڪندا آهن جيستائين اهو ڪافي آهي. ان ڪري، جيڪڏهن پروڊ في الحال پنهنجي چار ڪور استعمال نه ڪري رهيو آهي، اتي بيچ ڪمن کي محدود ڪرڻ جي ڪا به شيء ناهي، ۽ اهي اضافي پروسيسر وقت استعمال ڪري سگهن ٿا. پر اهڙي صورتحال ۾ جتي پروسيسرز جي گهٽتائي آهي، جيڪڏهن پروڊ پنهنجي چار ڪور کي استعمال ڪري چڪو آهي ۽ پنهنجي ڪوٽا تي پهچي چڪو آهي، باقي پروسيسر وقت سي پيشرز جي تناسب سان ورهايو ويندو، يعني ٽن مفت ڪور جي صورتحال ۾، هڪ هوندو. 1024 cpushares سان هڪ ٽاسڪ ڏنو ويندو، ۽ باقي ٻه 2048 cpushares سان هڪ ڪم کي ڏنو ويندو.

پر ڪوٽا ۽ حصص استعمال ڪرڻ ڪافي ناهي. اسان کي پڪ ڪرڻ جي ضرورت آهي ته هڪ ڪم ٿوري دير سان گڏ هڪ بيچ ڪم تي ترجيح حاصل ڪري ٿي جڏهن پروسيسر وقت مختص ڪيو وڃي. اهڙي ترجيح جي بغير، بيچ جو ڪم هن وقت پروسيسر جو سڄو وقت وٺندو جڏهن اهو پروڊ طرفان گهربل هجي. ڊاڪر رن ۾ ڪنٽينر جي ترجيح جا اختيار نه آھن، پر لينڪس سي پي يو شيڊولر پاليسيون ڪم ۾ اچن ٿيون. توهان انهن جي باري ۾ تفصيل سان پڙهي سگهو ٿا هتي، ۽ هن آرٽيڪل جي فريم ورڪ ۾ اسين مختصر طور تي انهن جي ذريعي وڃون ٿا:

• SCHED_OTHER
  ڊفالٽ طور، لينڪس مشين تي سڀئي عام صارف پروسيس وصول ڪن ٿا.
• SCHED_BATCH
  وسيلن جي گھڻائي واري عمل لاء ٺهيل. جڏهن هڪ پروسيسر تي هڪ ڪم رکي، هڪ نام نهاد ايڪٽيويشن سزا متعارف ڪرايو ويندو آهي: اهڙي ڪم کي پروسيسر وسيلن جي حاصل ڪرڻ جو امڪان گهٽ هوندو آهي جيڪڏهن اهو في الحال SCHED_OTHER سان ڪم ذريعي استعمال ڪيو پيو وڃي.
• SCHED_IDLE
  ھڪڙو پس منظر وارو عمل تمام گھٽ ترجيح سان، بھترين کان گھٽ -19. اسان استعمال ڪندا آهيون اسان جي اوپن سورس لائبريري هڪ نئون، ضروري پاليسي مقرر ڪرڻ لاءِ جڏهن ڪنٽينر کي ڪال ڪندي شروع ڪيو وڃي

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

پر اڃا به توهان جاوا ۾ پروگرام نٿا ڪريو، ساڳيو ڪم ڪري سگهجي ٿو chrt حڪم استعمال ڪندي:

chrt -i 0 $pid

اچو ته وضاحت لاءِ اسان جي سڀني اڪيلائي جي سطحن کي ھڪڙي جدول ۾ بيان ڪريون:

موصليت ڪلاس
Alloc مثال
Docker هلائڻ جا اختيار
sched_setscheduler chrt*

Prod
سي پي يو = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

بيچ
سي پي يو = [1، *)
--cpushares=1024
SCHED_BATCH

بيڪار
سي پي يو = [2، *)
--cpushares=2048
SCHED_IDLE

*جيڪڏهن توهان ڪنٽينر جي اندر کان chrt ڪري رهيا آهيو، توهان کي شايد ضرورت هجي sys_nice صلاحيت، ڇاڪاڻ ته ڊفالٽ طور Docker هن صلاحيت کي هٽائي ٿو جڏهن ڪنٽينر کي شروع ڪندي.

پر ڪم نه رڳو پروسيسر کي استعمال ڪن ٿا، پر ٽرئفڪ پڻ، جيڪو پروسيسر وسيلن جي غلط مختص ڪرڻ کان به وڌيڪ نيٽ ورڪ ڪم جي ويڪرائي کي متاثر ڪري ٿو. تنهن ڪري، اسان قدرتي طور تي ٽرئفڪ لاء ساڳئي تصوير حاصل ڪرڻ چاهيون ٿا. اهو آهي، جڏهن هڪ پروڊ ڪم نيٽ ورڪ ڏانهن ڪجهه پيڪيٽ موڪلي ٿو، اسان وڌ ۾ وڌ رفتار کي محدود ڪريون ٿا (فارمولا alloc: lan=[*,500mbps) )، جنهن سان پروڊ اهو ڪري سگهي ٿو. ۽ بيچ لاءِ اسان ضمانت ڏيون ٿا صرف گھٽ ۾ گھٽ ان پٽ جي، پر وڌ ۾ وڌ حد نه ڏيو (فارمولا alloc: lan=[10Mbps،*) ) انهي صورت ۾، پروڊ ٽرئفڪ کي بيچ ڪمن تي ترجيح حاصل ڪرڻ گهرجي.
هتي Docker وٽ ڪا به پراڻيون شيون نه آهن جيڪي اسان استعمال ڪري سگهون ٿا. پر اهو اسان جي مدد لاء اچي ٿو لينڪس ٽرئفڪ ڪنٽرول. اسان نظم و ضبط جي مدد سان گهربل نتيجو حاصل ڪرڻ جي قابل ٿي ويا درجه بندي منصفانه خدمت وکر. ان جي مدد سان، اسان ٽريفڪ جي ٻن طبقن ۾ فرق ڪريون ٿا: اعليٰ ترجيحي پروڊ ۽ گھٽ-ترجيح واري بيچ/بدل. نتيجي طور، نڪرڻ واري ٽرئفڪ لاء ترتيب هن طرح آهي:

هتي 1:0 hsfc نظم جو ”روٽ qdisc“ آهي. 1:1 - hsfc چائلڊ ڪلاس 8 Gbit/s جي ڪل بينڊوڊٿ جي حد سان، جنهن هيٺ سڀني ڪنٽينر جا ٻار ڪلاس رکيا ويا آهن؛ 1:2 - hsfc چائلڊ ڪلاس سڀني بيچ ۽ بيڪار ڪمن لاءِ عام آهي "متحرڪ" حد سان، جنهن تي هيٺ بحث ڪيو ويو آهي. بچيل hsfc ٻارن جا ڪلاس في الحال هلندڙ پراڊ ڪنٽينرز لاءِ وقف ڪيل ڪلاس آهن جن جون حدون انهن جي پڌرنامي سان ملن ٿيون - 450 ۽ 400 Mbit/s. هر hsfc ڪلاس کي qdisc queue fq يا fq_codel مقرر ڪيو ويو آهي، لينڪس ڪنيل ورزن تي منحصر ڪري، ٽرئفڪ جي دفن دوران پيڪٽ جي نقصان کان بچڻ لاء.

عام طور تي، tc نظم و ضبط صرف ٻاهرئين ٽرئفڪ کي ترجيح ڏيڻ جي خدمت ڪن ٿا. پر اسان چاهيون ٿا ته ايندڙ ايندڙ ٽرئفڪ کي به اوليت ڏيو - آخرڪار، ڪجهه بيچ ٽاسڪ آساني سان پوري ايندڙ چينل کي منتخب ڪري سگھن ٿا، وصول ڪري، مثال طور، نقشي ۽ گھٽائڻ لاءِ ان پٽ ڊيٽا جو هڪ وڏو بيچ. ان لاءِ اسان ماڊل استعمال ڪريون ٿا ايڇ، جيڪو هر نيٽ ورڪ انٽرفيس لاءِ هڪ ifbX ورچوئل انٽرفيس ٺاهي ٿو ۽ انٽرفيس کان ايندڙ ٽرئفڪ کي ifbX تي ٻاهرين ٽريفڪ ڏانهن منتقل ڪري ٿو. وڌيڪ، ifbX لاءِ، سڀ ساڳيا نظمون ڪم ڪن ٿيون ٻاهر وڃڻ واري ٽريفڪ کي ڪنٽرول ڪرڻ لاءِ، جن لاءِ hsfc ٺاھ جوڙ بلڪل ساڳي ھوندي:

تجربن دوران، اسان اهو معلوم ڪيو ته hsfc بهترين نتيجا ڏيکاري ٿو جڏهن 1:2 طبقي جي غير ترجيحي بيچ/بدل ٽريفڪ مينين مشينن تي محدود هوندي آهي هڪ خاص مفت لين کان وڌيڪ نه. ٻي صورت ۾، غير ترجيحي ٽرئفڪ جو تمام گھڻو اثر آھي پروڊ ڪمن جي دير تي. miniond هر سيڪنڊ ۾ مفت بينڊوڊٿ جي موجوده رقم کي طئي ڪري ٿو، ڏنل منين جي سڀني پروڊ-ٽاسڪ جي سراسري ٽرئفڪ جي استعمال کي ماپ ڪري ٿو ۽ ان کي نيٽ ورڪ انٽرفيس بينڊوڊٿ کان گھٽائڻ ٿوري مارجن سان، يعني

بينڊن کي آزاديءَ سان بيان ڪيو ويو آھي ايندڙ ۽ نڪرڻ واري ٽرئفڪ لاءِ. ۽ نئين قدرن جي مطابق، miniond غير ترجيح طبقي جي حد 1:2 کي ٻيهر ترتيب ڏئي ٿو.

اهڙيء طرح، اسان لاڳو ڪيو سڀني ٽن الڳ الڳ طبقن: پروڊ، بيچ ۽ بيڪار. اهي طبقن ڪمن جي ڪارڪردگي خاصيتن تي تمام گهڻو اثر انداز ڪن ٿا. تنهن ڪري، اسان هن وصف کي درجه بندي جي چوٽي تي رکڻ جو فيصلو ڪيو آهي، تنهنڪري جڏهن درجه بندي واري قطار جي نالي کي ڏسندي، اهو فوري طور تي واضح ٿي ويندو ته اسان ڇا ڪري رهيا آهيون:

اسان جا سڀ دوست ويب и موسيقي ان کان پوءِ فرنٽ کي پراڊڪٽ جي هيٺان درجه بندي ۾ رکيل آهي. مثال طور، بيچ جي تحت، اچو ته خدمت رکون موسيقي جي فهرست، جيڪو وقتي طور تي Odnoklassniki تي اپ لوڊ ڪيل mp3 فائلن جي سيٽ مان ٽريڪز جي هڪ فهرست مرتب ڪري ٿو. بيڪار جي تحت هڪ خدمت جو هڪ مثال هوندو ميوزڪ ٽرانسفارمر، جيڪو موسيقي جي مقدار جي سطح کي معمول ڪري ٿو.

اضافي لائنن کي ٻيهر هٽائڻ سان، اسان مڪمل سروس جي نالي جي آخر ۾ ٽاسڪ آئسوليشن ڪلاس شامل ڪندي پنهنجي سروس جا نالا فلٽر ڪري سگھون ٿا: web.front.prod, catalog.music.batch, transformer.music.idle.

۽ ھاڻي، خدمت جي نالي کي ڏسي، اسان سمجھندا آھيون نه رڳو اھو ڪھڙو ڪم انجام ڏئي ٿو، پر ان جي اڪيلائي وارو طبقو، جنھن جو مطلب آھي ان جي تنقيد، وغيره.

هر شي عظيم آهي، پر اتي هڪ تلخ سچ آهي. هڪ مشين تي هلندڙ ڪمن کي مڪمل طور تي الڳ ڪرڻ ناممڪن آهي.

ڇا اسان حاصل ڪرڻ ۾ منظم ڪيو: جيڪڏهن بيچ شدت سان استعمال ڪري ٿي صرف سي پي يو وسيلا، پوءِ تعمير ٿيل لينڪس سي پي يو شيڊولر پنهنجو ڪم تمام سٺو ڪري ٿو، ۽ عملي طور تي پروڊ ڪم تي ڪو به اثر نه آهي. پر جيڪڏهن هن بچ جو ڪم فعال طور تي ميموري سان ڪم ڪرڻ شروع ٿئي ٿو، پوء باهمي اثر اڳ ۾ ئي ظاهر ٿئي ٿو. اهو ٿي سگهي ٿو ڇاڪاڻ ته پروسيسر جي ميموري ڪيچز مان پروڊ ٽاسڪ "ڌوئي ٻاهر" آهي - نتيجي طور، ڪيش مسز وڌي ٿو، ۽ پروسيسر پروسيسر ڪم کي وڌيڪ سست رفتار سان پروسيس ڪري ٿو. اهڙو بيچ ڪم اسان جي عام پروڊ ڪنٽينر جي ويڪرائي کي 10٪ وڌائي سگھي ٿو.

ٽريفڪ کي الڳ ڪرڻ اڃا به وڌيڪ ڏکيو آهي ان حقيقت جي ڪري ته جديد نيٽ ورڪ ڪارڊن ۾ پيڪن جي اندروني قطار هوندي آهي. جيڪڏهن بيچ ٽاسڪ مان پيڪٽ پهرين اتي پهچي ٿو، پوء اهو پهريون هوندو جيڪو ڪيبل تي منتقل ڪيو ويندو، ۽ ان بابت ڪجهه به نه ٿو ڪري سگهجي.

ان کان علاوه، اسان اڃا تائين صرف TCP ٽرئفڪ کي ترجيح ڏيڻ جي مسئلي کي حل ڪرڻ ۾ منظم ڪيو آهي: hsfc طريقو UDP لاء ڪم نٿو ڪري. ۽ جيتوڻيڪ TCP ٽرئفڪ جي صورت ۾، جيڪڏهن بيچ ٽاسڪ تمام گهڻي ٽرئفڪ پيدا ڪري ٿي، اهو پڻ پروڊ ٽاسڪ جي دير ۾ تقريبا 10٪ اضافو ڏئي ٿو.

غلطي رواداري

ھڪڙي ھڪڙي بادل کي ترقي ڪرڻ جو ھڪڙو مقصد Odnoklassniki جي غلطي رواداري کي بھتر ڪرڻ ھو. تنهن ڪري، اڳيان آئون وڌيڪ تفصيل سان غور ڪرڻ چاهيندس ناڪامي ۽ حادثن جي ممڪن منظرنامي. اچو ته هڪ سادي منظر سان شروع ڪريون - هڪ ڪنٽينر ناڪامي.

ڪنٽينر پاڻ ڪيترن ئي طريقن سان ناڪام ٿي سگهي ٿو. اھو ٿي سگھي ٿو ڪنھن قسم جو تجربو، بگ يا نقص مينيفيسٽ ۾، جنھن جي ڪري پروڊ ٽاسڪ منشور ۾ بيان ڪيل کان وڌيڪ وسيلا استعمال ڪرڻ شروع ڪري ٿو. اسان وٽ هڪ ڪيس هو: هڪ ڊولپر هڪ پيچيده الورورٿم تي عمل ڪيو، ان کي ڪيترائي ڀيرا ٻيهر ڪم ڪيو، پنهنجو پاڻ تي غور ڪيو ۽ ايترو پريشان ٿي ويو ته آخرڪار مسئلو هڪ تمام غير معمولي طريقي سان ختم ٿي ويو. ۽ جيئن ته پروڊ ڪم کي ٻين سڀني کان وڌيڪ ترجيح ڏني وئي آهي ساڳئي منائن تي، اهو سڀني پروسيسر وسيلن کي استعمال ڪرڻ شروع ڪيو. هن صورتحال ۾، اڪيلائي، يا بلڪه سي پي يو ٽائيم ڪوٽا، ڏينهن بچايو. جيڪڏهن ڪو ڪم ڪوٽا مختص ڪيو وڃي ته اهو ڪم وڌيڪ خرچ نه ڪندو. تنهن ڪري، بيچ ۽ ٻيا پروڊ ڪم جيڪي ساڳي مشين تي هلندا هئا، ڪجهه به نوٽيس نه ڪيو.

ٻيو ممڪن مسئلو آهي ڪنٽينر گرڻ. ۽ هتي ٻيهر شروع ڪريو پاليسيون اسان کي بچايو، هرڪو انهن کي ڄاڻي ٿو، ڊاکر پاڻ هڪ عظيم ڪم ڪري ٿو. تقريبن سڀني پروڊ ڪمن ۾ هميشه ٻيهر شروع ڪرڻ واري پاليسي آهي. ڪڏهن ڪڏهن اسان استعمال ڪندا آهيون on_failure بيچ ڪمن لاءِ يا پروڊ ڪنٽينرز کي ڊيبگ ڪرڻ لاءِ.

توهان ڇا ڪري سگهو ٿا جيڪڏهن هڪ مڪمل منين دستياب ناهي؟

ظاهر آهي، ڪنٽينر کي ٻي مشين تي هلائي. هتي دلچسپ حصو اهو آهي ته ڇا ٿئي ٿو IP پتي (es) جو ڪنٽينر تي لڳايو ويو آهي.

اسان ڪنٽينرز کي ساڳيا IP پتي تفويض ڪري سگھون ٿا جيئن منين مشينون جن تي اهي ڪنٽينر هلن ٿا. پوءِ، جڏهن ڪنٽينر کي ٻي مشين تي لانچ ڪيو ويندو آهي، ان جو IP پتو تبديل ٿيندو آهي، ۽ سڀني ڪلائنٽ کي اهو سمجهڻ گهرجي ته ڪنٽينر منتقل ٿي ويو آهي، ۽ هاڻي انهن کي ڪنهن ٻئي ايڊريس تي وڃڻو پوندو، جنهن لاءِ الڳ سروس ڊسڪووري سروس جي ضرورت هوندي آهي.

سروس دريافت آسان آهي. خدمت رجسٽري کي منظم ڪرڻ لاءِ غلطي رواداري جي مختلف درجي جي مارڪيٽ تي ڪيترائي حل آھن. گهڻو ڪري اهڙا حل لوڊ بيلنس منطق کي لاڳو ڪن ٿا، ڪي وي اسٽوريج جي صورت ۾ اضافي ترتيبن کي ذخيرو ڪن ٿا، وغيره.
تنهن هوندي، اسان هڪ الڳ رجسٽري کي لاڳو ڪرڻ جي ضرورت کان بچڻ چاهيندا، ڇاڪاڻ ته اهو هڪ نازڪ سسٽم متعارف ڪرائڻ جو مطلب آهي جيڪو پيداوار ۾ سڀني خدمتن پاران استعمال ڪيو ويندو آهي. هن جو مطلب اهو آهي ته اهو ناڪامي جو هڪ امڪاني نقطو آهي، ۽ توهان کي چونڊڻ يا ترقي ڪرڻ جي ضرورت آهي هڪ تمام نقص برداشت ڪندڙ حل، جيڪو واضح طور تي تمام ڏکيو، وقت سازي ۽ قيمتي آهي.

۽ هڪ وڌيڪ وڏي خرابي: اسان جي پراڻي انفراسٽرڪچر لاءِ نئين سان ڪم ڪرڻ لاءِ، اسان کي مڪمل طور تي سڀني ڪمن کي ٻيهر لکڻو پوندو ڪنهن قسم جي سروس ڊسڪوري سسٽم کي استعمال ڪرڻ لاءِ. ڪم جو تمام گهڻو آهي، ۽ ڪجهه هنڌن تي اهو تقريبا ناممڪن آهي جڏهن اهو گهٽ-سطح جي ڊوائيسز تي اچي ٿو جيڪي OS ڪنييل سطح تي ڪم ڪن ٿيون يا سڌو هارڊويئر سان. قائم ڪيل حل جي نمونن کي استعمال ڪندي هن ڪارڪردگي کي لاڳو ڪرڻ، جهڙوڪ پاسي واري ڪار مطلب ته ڪجھ هنڌن تي اضافي لوڊ، ٻين ۾ - آپريشن جي پيچيدگي ۽ اضافي ناڪامي منظرنامو. اسان شين کي پيچيده ڪرڻ نٿا چاهيون، ان ڪري اسان فيصلو ڪيو ته خدمت جي دريافت کي اختياري استعمال ڪيو وڃي.

ھڪڙي بادل ۾، IP ڪنٽينر جي پٺيان آھي، يعني ھر ڪم جي مثال جو پنھنجو IP پتو آھي. هي پتو آهي "جامد": اهو هر مثال تي لڳايو ويو آهي جڏهن خدمت پهرين بادل ڏانهن موڪلي وئي آهي. جيڪڏھن ھڪڙي خدمت پنھنجي زندگيءَ دوران مختلف مثالن جو تعداد ھو، پوءِ آخر ۾ ان کي تفويض ڪيو ويندو جيترا IP پتي وڌ ۾ وڌ مثال ھئا.

تنهن کان پوء، اهي پتا تبديل نه ٿيندا آهن: اهي هڪ ڀيرو مقرر ڪيا ويا آهن ۽ پيداوار ۾ خدمت جي سڄي زندگي ۾ موجود آهن. IP پتي نيٽ ورڪ ۾ ڪنٽينرز جي پيروي ڪندا آهن. جيڪڏهن ڪنٽينر ٻئي منين ڏانهن منتقل ڪيو ويو آهي، پوء پتو ان جي پيروي ڪندو.

ان ڪري، خدمت جي نالي جو نقشو ان جي IP پتي جي لسٽ ۾ تمام گھٽ تبديل ٿي وڃي ٿو. جيڪڏھن توھان وري ڏسو خدمت جي نالن جي نالن تي جن جو ذڪر اسان مضمون جي شروعات ۾ ڪيو آھي (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …)، اسان نوٽيس ڪنداسين ته اهي DNS ۾ استعمال ٿيل FQDNs وانگر آهن. اھو صحيح آھي، خدمت جي نالن جي نالن کي انھن جي IP پتي تي نقشي ڪرڻ لاء، اسان استعمال ڪريون ٿا DNS پروٽوڪول. ان کان علاوه، هي DNS سڀني ڪنٽينرز جي سڀني محفوظ IP پتي کي واپس ڪري ٿو - ٻئي هلائيندڙ ۽ بند (چون ٿا ته ٽي نقل استعمال ڪيا ويا آهن، ۽ اسان وٽ پنج ايڊريس محفوظ آهن - سڀئي پنج واپس ڪيا ويندا). ڪلائنٽ، هي معلومات حاصل ڪرڻ کان پوء، ڪوشش ڪندا ته سڀني پنجن نقلن سان ڪنيڪشن قائم ڪرڻ - ۽ اهڙيء طرح انهن کي طئي ڪيو جيڪي ڪم ڪري رهيا آهن. دستيابي کي طئي ڪرڻ لاءِ هي اختيار گهڻو وڌيڪ قابل اعتماد آهي؛ ان ۾ يا ته DNS يا خدمت دريافت شامل ناهي، جنهن جو مطلب آهي ته معلومات جي مطابقت ۽ انهن سسٽم جي غلطي رواداري کي يقيني بڻائڻ ۾ حل ڪرڻ لاءِ ڪو به ڏکيو مسئلو ناهي. ان کان علاوه، نازڪ خدمتن ۾ جنهن تي پوري پورٽ جي آپريشن تي منحصر آهي، اسان DNS استعمال نٿا ڪري سگهون، پر صرف IP پتي کي ترتيب ۾ داخل ڪريو.

ڪنٽينرز جي پويان اهڙي IP منتقلي کي لاڳو ڪرڻ غير معمولي ٿي سگهي ٿو - ۽ اسان ڏسنداسين ته اهو ڪيئن ڪم ڪري ٿو هيٺين مثال سان:

اچو ته چون ٿا ون ڪلائوڊ ماسٽر minion M1 کي هلائڻ لاءِ حڪم ڏئي ٿو 1.ok-web.group1.web.front.prod ايڊريس 1.1.1.1 سان. مينيو تي ڪم ڪري ٿو جنڊ، جيڪو هن ايڊريس کي خاص سرورز ڏانهن اشتهار ڏئي ٿو رستو موٽائيندڙ. بعد ۾ نيٽ ورڪ هارڊويئر سان گڏ هڪ BGP سيشن آهي، جنهن ۾ M1.1.1.1 تي ايڊريس 1 جو رستو ترجمو ڪيو ويو آهي. M1 لينڪس استعمال ڪندي ڪنٽينر اندر پيڪٽ رستن کي. ٽي رستا ريفلڪٽر سرور آهن، ڇاڪاڻ ته هي ون ڪلائوڊ انفراسٽرڪچر جو انتهائي نازڪ حصو آهي - انهن کان سواءِ، ون ڪلائوڊ ۾ نيٽ ورڪ ڪم نه ڪندو. اسان انهن کي مختلف ريڪ ۾ رکون ٿا، جيڪڏهن ممڪن هجي ته ڊيٽا سينٽر جي مختلف ڪمرن ۾ واقع هجي، هڪ ئي وقت تي سڀني ٽن ناڪامين جي امڪان کي گهٽائڻ لاء.

اچو ته ھاڻي فرض ڪريون ته ھڪڙي بادل ماسٽر ۽ M1 منين جي وچ ۾ ڪنيڪشن گم ٿي ويو آھي. ھڪڙو بادل ماسٽر ھاڻي ان فرض تي عمل ڪندو ته M1 مڪمل طور تي ناڪام ٿي چڪو آھي. اھو آھي، اھو حڪم ڏيندو M2 منين کي لانچ ڪرڻ لاء web.group1.web.front.prod ساڳئي پتي سان 1.1.1.1. هاڻي اسان وٽ نيٽ ورڪ تي 1.1.1.1 لاءِ ٻه متضاد رستا آهن: M1 ۽ M2 تي. اهڙين تڪرارن کي حل ڪرڻ لاءِ، اسان استعمال ڪريون ٿا ملٽي ايگزٽ ڊسڪريمينٽر، جنهن جو ذڪر BGP اعلان ۾ ڪيو ويو آهي. اھو ھڪڙو نمبر آھي جيڪو ڏيکاري ٿو مشھور رستي جو وزن. متضاد رستن جي وچ ۾، هيٺين MED قدر سان رستو چونڊيو ويندو. ون ڪلائوڊ ماسٽر MED کي سپورٽ ڪري ٿو ڪنٽينر IP پتي جو لازمي حصو. پهريون ڀيرو، پتو ڪافي وڏي MED = 1 سان لکيل آهي. اهڙي ايمرجنسي ڪنٽينر جي منتقلي جي صورتحال ۾، ماسٽر MED کي گھٽائي ٿو، ۽ M000 کي اڳ ۾ ئي حڪم ملي ويندو ته ايڊريس 000 کي MED = سان اشتهار ڏيڻ لاءِ. 2. M1.1.1.1 تي هلندڙ مثال هن صورت ۾ باقي رهندو، ڪو به واسطو نه آهي، ۽ هن جي وڌيڪ قسمت اسان کي ٿوري دلچسپي رکي ٿي جيستائين ماسٽر سان ڪنيڪشن بحال نه ٿئي، جڏهن هن کي پراڻي ٽيڪ وانگر روڪيو ويندو.

حادثا

سڀ ڊيٽا سينٽر مئنيجمينٽ سسٽم هميشه معمولي ناڪامي کي قبول ڪن ٿا. ڪنٽينر اوور فلو تقريبن هر جڳهه آهي.

اچو ته ڏسون ته اسان ايمرجنسي کي ڪيئن سنڀاليندا آهيون، جيئن ڊيٽا سينٽر جي هڪ يا وڌيڪ ڪمرن ۾ بجلي جي ناڪامي.

ڊيٽا سينٽر مئنيجمينٽ سسٽم لاءِ حادثو ڇا مطلب آهي؟ سڀ کان پهريان، اهو ڪيترن ئي مشينن جي هڪ ڀيري ناڪامي آهي، ۽ ڪنٽرول سسٽم کي ساڳئي وقت ڪيترن ئي ڪنٽينرز کي منتقل ڪرڻ جي ضرورت آهي. پر جيڪڏهن آفت تمام وڏي پيماني تي آهي، ته اهو ٿي سگهي ٿو ته سڀني ڪمن کي ٻيهر مختص نه ڪري سگهجي ٻين مننين کي، ڇاڪاڻ ته ڊيٽا سينٽر جي وسيلن جي گنجائش لوڊ جي 100٪ کان گهٽ آهي.

اڪثر حادثا ڪنٽرول پرت جي ناڪامي سان گڏ آهن. اهو ٿي سگهي ٿو ان جي سامان جي ناڪامي جي ڪري، پر گهڻو ڪري ان حقيقت جي ڪري ته حادثن جي آزمائش نه ڪئي وئي آهي، ۽ ڪنٽرول پرت پاڻ کي وڌندڙ لوڊ جي ڪري پوي ٿو.

توهان هن سڀني بابت ڇا ڪري سگهو ٿا؟

وڏي پئماني تي لڏپلاڻ جو مطلب اهو آهي ته انفراسٽرڪچر ۾ وڏي تعداد ۾ سرگرميون، لڏپلاڻ، ۽ تعیناتيون موجود آهن. هر هڪ لڏپلاڻ ۾ ڪجهه وقت لڳن ٿا ڪنٽينر جون تصويرون مينين تائين پهچائڻ ۽ ان کي پيڪ ڪرڻ، ڪنٽينرز کي لانچ ڪرڻ ۽ ان جي شروعات ڪرڻ وغيره. ان ڪري، اهو ضروري آهي ته گهٽ اهم ڪمن کان پهريان وڌيڪ اهم ڪم شروع ڪيا وڃن.

اچو ته ٻيهر ڏسو خدمتن جي درجي بندي تي جنهن کان اسين واقف آهيون ۽ فيصلو ڪرڻ جي ڪوشش ڪريون ته ڪهڙن ڪمن کي پهرين هلائڻ چاهيون ٿا.

يقينن، اهي اهي عمل آهن جيڪي سڌو سنئون صارف جي درخواستن جي پروسيسنگ ۾ ملوث آهن، يعني پروڊ. اسان هن سان اشارو ڪريون ٿا مقرري جي ترجيح - ھڪڙو نمبر جيڪو قطار ۾ مقرر ڪري سگھجي ٿو. جيڪڏهن هڪ قطار کي اعلي ترجيح آهي، ان جون خدمتون پهرين رکيل آهن.

پروڊڪٽ تي اسان اعليٰ ترجيحات تفويض ڪريون ٿا، 0؛ بيچ تي - ٿورو هيٺ، 100؛ بيڪار تي - اڃا به گهٽ، 200. ترجيحن کي ترتيب وار طور لاڳو ڪيو ويندو آهي. سڀني ڪمن جي درجه بندي ۾ هيٺيون هڪ لاڳاپيل ترجيح هوندي. جيڪڏهن اسان چاهيون ٿا ته پروڊ اندر ڪيچز کي فرنٽ اينڊز کان اڳ لانچ ڪيو وڃي، ته پوءِ اسان ترجيحات کي ڪيش = 0 ۽ فرنٽ سبڪيوز = 1 کي تفويض ڪريون ٿا. جيڪڏهن، مثال طور، اسان چاهيون ٿا ته مکيه پورٽل پهرين فرنٽ کان لانچ ڪيو وڃي، ۽ صرف ميوزڪ فرنٽ. ان کان پوء، پوء اسان کي هيٺين ترجيح ڏئي سگھون ٿا بعد ۾ - 10.

ايندڙ مسئلو وسيلن جي کوٽ آهي. تنهن ڪري، سامان جو هڪ وڏو مقدار، ڊيٽا سينٽر جو سڄو هال، ناڪام ٿي ويو، ۽ اسان ڪيتريون ئي خدمتون ٻيهر شروع ڪيون آهن ته هاڻي هر ڪنهن لاء ڪافي وسيلا نه آهن. توهان کي اهو فيصلو ڪرڻو پوندو ته مکيه نازڪ خدمتن کي جاري رکڻ لاءِ ڪهڙن ڪمن کي قربان ڪيو وڃي.

جڳهه جي ترجيح جي برعڪس، اسان بيچيني طور تي سڀني بيچ ڪمن کي قربان نٿا ڪري سگهون؛ انهن مان ڪجهه پورٽل جي آپريشن لاء اهم آهن. تنهن ڪري، اسان الڳ الڳ ڌيان ڏنو آهي ترجيحي ترجيح ڪم. جڏهن رکيل هجي، هڪ اعلي ترجيح وارو ڪم اڳڀرائي ڪري سگهي ٿو، يعني روڪي، گهٽ ترجيح وارو ڪم جيڪڏهن ڪو وڌيڪ مفت مينيو نه هجي. انهي صورت ۾، گهٽ ترجيح سان هڪ ڪم شايد اڻڄاتل رهندو، يعني ڪافي مفت وسيلن سان گڏ ان لاء مناسب منين نه هوندو.

اسان جي درجي بندي ۾، اڳڀرائي جي ترجيح جي وضاحت ڪرڻ بلڪل سادو آهي جيئن ته پروڊ ۽ بيچ جا ڪم بيڪار ڪمن کي اڳڀرائي يا بند ڪن ٿا، پر هڪ ٻئي کي نه، 200 جي برابر idle لاءِ ترجيح بيان ڪرڻ سان. بلڪل ائين جيئن جڳهه جي ترجيح جي صورت ۾، اسان وڌيڪ پيچيده ضابطن کي بيان ڪرڻ لاءِ اسان جو درجو استعمال ڪري سگهون ٿا. مثال طور، اچو ته اهو ظاهر ڪريون ته اسان ميوزڪ فنڪشن کي قربان ڪريون ٿا جيڪڏهن اسان وٽ مکيه ويب پورٽل لاءِ ڪافي وسيلا نه آهن، لاڳاپيل نوڊس لاءِ ترجيح مقرر ڪريو هيٺين: 10.

مڪمل ڊي سي حادثا

ڇو سڄي ڊيٽا سينٽر ناڪام ٿي سگهي ٿي؟ عنصر. سٺي پوسٽ هئي طوفان ڊيٽا سينٽر جي ڪم کي متاثر ڪيو. عناصر بي گهر ماڻهن کي سمجهي سگهجي ٿو جيڪي هڪ ڀيرو ڪيترن ئي سطحن ۾ آپٽڪس کي ساڙي ڇڏيو، ۽ ڊيٽا سينٽر مڪمل طور تي ٻين سائيٽن سان رابطو وڃائي ڇڏيو. ناڪامي جو سبب پڻ انساني عنصر ٿي سگهي ٿو: آپريٽر اهڙو حڪم جاري ڪندو ته سڄي ڊيٽا سينٽر گر ٿي ويندو. اهو ٿي سگهي ٿو هڪ وڏي بگ جي ڪري. عام طور تي، ڊيٽا مرڪز جو خاتمو غير معمولي ناهي. اهو اسان وٽ هر چند مهينن ۾ هڪ ڀيرو ٿئي ٿو.

۽ هي اهو آهي جيڪو اسان ڪنهن کي ٽوئيٽ ڪرڻ کان روڪڻ لاءِ ڪندا آهيون #live.

پهرين حڪمت عملي اڪيلائي آهي. هر هڪ ڪلائوڊ مثال الڳ الڳ آهي ۽ صرف هڪ ڊيٽا سينٽر ۾ مشينن کي منظم ڪري سگهي ٿو. اهو آهي، ڪڪر جي نقصان يا غلط آپريٽر حڪمن جي ڪري صرف هڪ ڊيٽا سينٽر جو نقصان آهي. اسان هن لاءِ تيار آهيون: اسان وٽ هڪ بيڪار پاليسي آهي جنهن ۾ ايپليڪيشن ۽ ڊيٽا جون نقلون سڀني ڊيٽا سينٽرن ۾ واقع آهن. اسان استعمال ڪندا آهيون غلطي برداشت ڪندڙ ڊيٽابيس ۽ وقتي طور تي ناڪامين لاءِ ٽيسٽ.
اڄ کان وٺي اسان وٽ چار ڊيٽا سينٽر آهن، ان جو مطلب آهي چار الڳ الڳ، مڪمل طور تي الڳ ٿيل مثالون هڪ ڪلائوڊ.

اهو طريقو نه رڳو جسماني ناڪامي کان بچائيندو آهي، پر آپريٽر جي غلطي جي خلاف پڻ حفاظت ڪري سگهي ٿو.

انساني عنصر سان ٻيو ڇا ٿي سگهي ٿو؟ جڏهن ڪو آپريٽر بادل کي ڪجهه عجيب يا امڪاني طور تي خطرناڪ حڪم ڏئي ٿو، ته هن کي اوچتو هڪ ننڍڙو مسئلو حل ڪرڻ لاءِ چيو وڃي ٿو ته اهو ڏسڻ لاءِ ته هن ڪيترو سٺو سوچيو. مثال طور، جيڪڏهن اهو ڪجهه قسم جو ماس اسٽاپ آهي ڪيترن ئي نقلن جو يا صرف هڪ عجيب حڪم - نقلن جو تعداد گهٽائڻ يا تصوير جو نالو تبديل ڪرڻ، ۽ نه رڳو نئين منشور ۾ نسخن جو نمبر.

نتيجو

ھڪڙي بادل جون خاص خاصيتون:

• خدمتن ۽ ڪنٽينرز لاءِ درجه بندي ۽ بصري نالي جي اسڪيم، جيڪو توهان کي تمام جلدي ڳولڻ جي اجازت ڏئي ٿو ته اهو ڪم ڇا آهي، ان سان ڪهڙو تعلق آهي ۽ اهو ڪيئن ڪم ڪري ٿو ۽ ڪير ان جو ذميوار آهي.
• اسان لاڳو ڪندا آهيون پيداوار ۽ بيچ کي گڏ ڪرڻ جي ٽيڪنڪمشين شيئرنگ جي ڪارڪردگي کي بهتر ڪرڻ لاء minions تي ڪم. cpuset جي بدران اسان استعمال ڪريون ٿا سي پي يو ڪوٽا، شيئرز، سي پي يو شيڊولر پاليسيون ۽ لينڪس QoS.
• ساڳئي مشين تي هلندڙ ڪنٽينرز کي مڪمل طور تي الڳ ڪرڻ ممڪن نه هو، پر انهن جو باهمي اثر 20 سيڪڙو جي اندر رهي ٿو.
• خدمتن کي ترتيب ڏيڻ واري ترتيب ۾ مدد ڪري ٿي خودڪار آفت جي بحالي جي استعمال سان مقرري ۽ ترجيحات.

سوالات

اسان تيار ٿيل حل ڇو نه ورتو؟

• ٽاسڪ آئسوليشن جي مختلف طبقن کي مختلف منطق جي ضرورت هوندي آهي جڏهن منن تي رکيل هجي. جيڪڏهن پروڊ ڪمن کي صرف وسيلن کي محفوظ ڪرڻ سان رکي سگهجي ٿو، پوء بيچ ۽ بيڪار ڪم رکيا وڃن، منين مشينن تي وسيلن جي حقيقي استعمال کي ٽريڪ ڪندي.
• ڪمن ذريعي استعمال ڪيل وسيلن کي اڪائونٽ ۾ رکڻ جي ضرورت آهي، جهڙوڪ:
  • نيٽ ورڪ بينڊوڊٿ؛
  • ڊسڪ جا قسم ۽ ”اسپنڊل“.
• هنگامي جواب جي دوران خدمتن جي ترجيحن کي ظاهر ڪرڻ جي ضرورت، وسيلن لاء حڪمن جا حق ۽ ڪوٽا، جيڪي ھڪڙي بادل ۾ درجه بندي قطار استعمال ڪندي حل ڪيا ويا آھن.
• حادثن ۽ واقعن جي جوابي وقت کي گهٽائڻ لاءِ ڪنٽينرز جي انساني نالي جي ضرورت آهي
• سروس دريافت جي ھڪڙي وقت جي وڏي پيماني تي عمل ڪرڻ جو ناممڪن؛ هارڊويئر هوسٽس تي ميزباني ڪيل ڪمن سان گڏ هڪ ڊگهي وقت تائين گڏ رهڻ جي ضرورت آهي - ڪجهه جيڪو حل ڪيو وڃي ٿو ”جامد“ IP پتي هيٺ ڏنل ڪنٽينرز، ۽ نتيجي طور، وڏي نيٽ ورڪ انفراسٽرڪچر سان منفرد انضمام جي ضرورت.

انهن سڀني ڪمن لاءِ موجوده حلن جي اهم تبديلين جي ضرورت پوندي ته جيئن اسان کي مناسب هجي، ۽، ڪم جي مقدار جو اندازو لڳائڻ کان پوءِ، اسان محسوس ڪيو ته اسان تقريبن ساڳين مزدورن جي خرچن سان پنهنجو حل ٺاهي سگهون ٿا. پر توهان جو حل هلائڻ ۽ ترقي ڪرڻ تمام آسان ٿيندو - ان ۾ غير ضروري تجزيا شامل نه آهن جيڪي ڪارڪردگي جي حمايت ڪن ٿيون جنهن جي اسان کي ضرورت ناهي.

انهن لاءِ جن آخري سٽون پڙهيون، توهان جي صبر ۽ توجه جي مهرباني!

جو ذريعو: www.habr.com