هيلو، مان آهيان سرجي Elantsev، مان ترقي ڪريان ٿو Yandex.Cloud ۾. اڳي، مون Yandex پورٽل لاءِ L7 بيلنس جي ترقي جي اڳواڻي ڪئي - ساٿي مذاق ڪن ٿا ته مان ڇا ڪريان، اهو هڪ بيلنس بڻجي ٿو. مان Habr پڙهندڙن کي ٻڌايان ٿو ته ڪئين ڪلائوڊ پليٽ فارم ۾ لوڊ کي ڪيئن منظم ڪيو وڃي، جيڪو اسان ڏسون ٿا مثالي اوزار هن مقصد کي حاصل ڪرڻ لاء، ۽ ڪيئن اسان هن اوزار جي تعمير ڏانهن وڌي رهيا آهيون.
پهرين، اچو ته ڪجهه اصطلاحن کي متعارف ڪرايو:
- VIP (ورچوئل IP) - بيلنس ڪندڙ IP پتو
- سرور، پس منظر، مثال - هڪ مجازي مشين هلائيندڙ ايپليڪيشن
- RIP (اصلي IP) - سرور IP پتو
- صحت جي چڪاس - سرور جي تياري جي جانچ ڪرڻ
- دستيابي زون، AZ - ڊيٽا سينٽر ۾ الڳ ٿيل انفراسٽرڪچر
- علائقو - مختلف AZs جي هڪ يونين
لوڊ بيلنس وارا ٽي مکيه ڪم حل ڪن ٿا: اهي پاڻ کي بيلنس انجام ڏين ٿا، خدمت جي غلطي رواداري کي بهتر ڪن ٿا، ۽ ان جي اسڪيلنگ کي آسان ڪن ٿا. فالٽ رواداري کي يقيني بڻايو وڃي ٿو خودڪار ٽرئفڪ مينيجمينٽ ذريعي: بيلنس ڪندڙ ايپليڪيشن جي حالت کي مانيٽر ڪري ٿو ۽ بيلنس کان مثالن کي خارج ڪري ٿو جيڪي زندگي جي چڪاس کي پاس نٿا ڪن. اسڪيلنگ کي يقيني بڻايو وڃي ٿو برابر طور تي لوڊ کي مثالن ۾ ورهائڻ سان، ۽ انهي سان گڏ اڏام تي واقعن جي فهرست کي اپڊيٽ ڪندي. جيڪڏهن توازن ڪافي يونيفارم نه آهي، ڪجهه مثالن کي هڪ لوڊ ملندو جيڪو انهن جي گنجائش جي حد کان وڌيڪ آهي، ۽ خدمت گهٽ قابل اعتماد ٿي ويندي.
هڪ لوڊ بيلنس اڪثر ڪري درجه بندي ڪئي ويندي آهي پروٽوڪول پرت جي OSI ماڊل مان جنهن تي اهو هلندو آهي. Cloud Balancer TCP سطح تي هلندي آهي، جيڪو چوٿين پرت، L4 سان ملندو آهي.
اچو ته ڪلائوڊ بيلنس آرڪيٽيڪچر جو جائزو وٺون. اسان تدريجي طور تي تفصيل جي سطح کي وڌائينداسين. اسان بيلنس جي اجزاء کي ٽن طبقن ۾ ورهايو. config جهاز ڪلاس صارف جي رابطي لاء ذميوار آهي ۽ سسٽم جي ٽارگيٽ رياست کي محفوظ ڪري ٿو. ڪنٽرول جهاز سسٽم جي موجوده حالت کي محفوظ ڪري ٿو ۽ ڊيٽا جهاز ڪلاس مان سسٽم کي منظم ڪري ٿو، جيڪي سڌو سنئون ذميوار آهن ٽريفڪ کي گراهڪن کان توهان جي مثالن تائين پهچائڻ.
ڊيٽا جهاز
ٽريفڪ قيمتي ڊوائيسز تي ختم ٿي ويندي آهي جنهن کي بارڊر روٽرز سڏيو ويندو آهي. غلطي رواداري کي وڌائڻ لاء، ڪيترائي اهڙيون ڊوائيس هڪ ئي وقت هڪ ڊيٽا سينٽر ۾ هلن ٿيون. اڳيون، ٽريفڪ بيلنسرز ڏانهن وڃي ٿي، جيڪي ڪلائنٽ لاءِ BGP ذريعي سڀني AZs کي ڪنهن به ڪاسٽ IP پتي جو اعلان ڪن ٿا.
ٽريفڪ ECMP تي منتقل ڪئي وئي آهي - اها هڪ رستي واري حڪمت عملي آهي جنهن جي مطابق ٽارگيٽ تائين ڪيترائي هڪجهڙا سٺا رستا ٿي سگهن ٿا (اسان جي صورت ۾ ، ٽارگيٽ منزل IP پتو هوندو) ۽ انهن مان ڪنهن سان گڏ پيڪيٽ موڪلي سگهجن ٿا. اسان ھيٺ ڏنل اسڪيم جي مطابق ڪيترن ئي دستيابي زونن ۾ ڪم جي حمايت ڪريون ٿا: اسان هر زون ۾ ايڊريس جو اشتهار ڏيون ٿا، ٽرئفڪ ويجھي ھڪڙي ڏانھن وڃي ٿي ۽ پنھنجي حدن کان ٻاھر نه ٿي وڃي. بعد ۾ پوسٽ ۾ اسان وڌيڪ تفصيل سان ڏسنداسين ته ٽرئفڪ جو ڇا ٿيندو.
جهاز جي ترتيب
ترتيب واري جهاز جو اهم حصو API آهي، جنهن جي ذريعي بنيادي عملن کي بيلنسرز سان انجام ڏنو ويندو آهي: ٺاهڻ، حذف ڪرڻ، مثالن جي جوڙجڪ کي تبديل ڪرڻ، صحت جي چڪاس جا نتيجا حاصل ڪرڻ، وغيره. هڪ طرف، هي هڪ REST API آهي، ۽ ٻئي طرف. ٻيو، اسان Cloud ۾ اڪثر ڪري فريم ورڪ gRPC استعمال ڪندا آهيون، تنهنڪري اسان "ترجمو" ڪريون ٿا REST کي gRPC ۽ پوءِ صرف gRPC استعمال ڪريو. ڪا به درخواست غير مطابقت پذير ڪمن جو هڪ سلسلو ٺاهي ٿي جيڪا Yandex.Cloud ڪارڪنن جي عام تلاءَ تي عمل ۾ اچي ٿي. ڪم اهڙي طرح لکيل آهن ته اهي ڪنهن به وقت معطل ٿي سگهن ٿا ۽ پوءِ ٻيهر شروع ٿي سگهن ٿا. هي اسڪاليبلٽي، ورجائيبلٽي ۽ عملن جي لاگنگ کي يقيني بڻائي ٿو.
نتيجي طور، API کان ڪم بيلنس سروس ڪنٽرولر کي درخواست ڪندو، جيڪو Go ۾ لکيل آهي. اهو بيلنس شامل ڪري ۽ ختم ڪري سگھي ٿو، پس منظر ۽ سيٽنگن جي جوڙجڪ کي تبديل ڪري سگھي ٿو.
خدمت پنهنجي رياست کي Yandex ڊيٽابيس ۾ ذخيرو ڪري ٿو، هڪ ورهايل منظم ڊيٽابيس جيڪو توهان جلد ئي استعمال ڪرڻ جي قابل هوندو. Yandex.Cloud ۾، جيئن اسان اڳ ۾ ئي ، ڪتن جي کاڌي جو تصور لاڳو ٿئي ٿو: جيڪڏهن اسان پاڻ اسان جون خدمتون استعمال ڪريون ٿا، ته پوءِ اسان جا گراهڪ به انهن کي استعمال ڪري خوش ٿيندا. Yandex ڊيٽابيس اهڙي تصور جي عمل جو هڪ مثال آهي. اسان YDB ۾ اسان جي سڀني ڊيٽا کي ذخيرو ڪندا آهيون، ۽ اسان کي ڊيٽابيس کي برقرار رکڻ ۽ اسڪيلنگ بابت سوچڻ جي ضرورت ناهي: اهي مسئلا اسان لاء حل ڪيا ويا آهن، اسان ڊيٽابيس کي خدمت طور استعمال ڪندا آهيون.
اچو ته بيلنس ڪنٽرولر ڏانهن واپس وڃو. ان جو ڪم اهو آهي ته بيلنس جي باري ۾ معلومات محفوظ ڪرڻ ۽ ورچوئل مشين جي تياري کي جانچڻ لاءِ هڪ ڪم موڪلڻ آهي هيلٿ چيڪ ڪنٽرولر کي.
صحت جي چڪاس ڪنٽرولر
اهو چيڪ قاعدن کي تبديل ڪرڻ لاءِ درخواستون وصول ڪري ٿو، انهن کي YDB ۾ محفوظ ڪري ٿو، ڪمن کي ورهائي ٿو هيلچڪ نوڊس ۽ نتيجن کي گڏ ڪري ٿو، جيڪي پوءِ ڊيٽابيس ۾ محفوظ ڪيا وڃن ٿا ۽ لوڊ بيلنس ڪنٽرولر ڏانهن موڪليا وڃن ٿا. اهو، موڙ ۾، ڊيٽا جهاز ۾ ڪلستر جي جوڙجڪ کي تبديل ڪرڻ لاء هڪ درخواست موڪلي ٿو loadbalancer-node، جنهن تي آئون هيٺ بحث ڪندس.
اچو ته صحت جي چڪاس بابت وڌيڪ ڳالهايون. انهن کي ڪيترن ئي طبقن ۾ ورهائي سگهجي ٿو. آڊٽ مختلف ڪاميابي جا معيار آهن. TCP چيڪن کي ڪاميابيءَ سان ھڪ مقرر وقت اندر ڪنيڪشن قائم ڪرڻ جي ضرورت آھي. HTTP چيڪن کي هڪ ڪامياب ڪنيڪشن ۽ 200 اسٽيٽس ڪوڊ سان جواب جي ضرورت آهي.
انهي سان گڏ، چيڪ عمل جي طبقي ۾ مختلف آهن - اهي فعال ۽ غير فعال آهن. غير فعال چيڪ صرف نگراني ڪن ٿا ته ٽرئفڪ سان ڇا ٿي رهيو آهي بغير ڪنهن خاص عمل جي. اهو L4 تي تمام سٺو ڪم نٿو ڪري ڇاڪاڻ ته اهو اعلي سطحي پروٽوڪول جي منطق تي منحصر آهي: L4 تي ڪابه ڄاڻ ناهي ته آپريشن ڪيترو وقت ورتو يا ڪنيڪشن مڪمل ٿيڻ سٺو يا خراب هو. فعال چيڪن کي بيلنس جي ضرورت هوندي آهي ته هر سرور جي مثال تي درخواستون موڪلڻ لاءِ.
اڪثر لوڊ بيلنسرز پاڻ کي زندگي جي جانچ ڪن ٿا. ڪلائوڊ تي، اسان سسٽم جي انهن حصن کي الڳ ڪرڻ جو فيصلو ڪيو ته جيئن اسپيبلبل کي وڌايو وڃي. اهو طريقو اسان کي بيلنسرز جو تعداد وڌائڻ جي اجازت ڏيندو جڏهن ته خدمت جي صحت جي چڪاس جي درخواستن جي تعداد کي برقرار رکندي. چيڪ الڳ الڳ هيلٿ چيڪ نوڊس ذريعي ڪيا ويندا آهن، جن جي چوڌاري چيڪن جا نشان شارڊ ۽ نقل ڪيا ويندا آهن. توهان هڪ ميزبان کان چيڪ نه ٿا ڪري سگهو، جيئن اهو ناڪام ٿي سگهي ٿو. پوءِ اسان کي ان مثال جي حالت نه ملندي جيڪا هن چيڪ ڪئي. اسان گهٽ ۾ گهٽ ٽي هيلٿ چيڪ نوڊس مان ڪنهن به مثال تي چيڪ ڪندا آهيون. اسان مسلسل هيشنگ الگورتھم استعمال ڪندي نوڊس جي وچ ۾ چيڪن جا مقصد شارٽ ڪريون ٿا.
بيلنس ۽ صحت جي چڪاس کي الڳ ڪرڻ سان مسئلا پيدا ٿي سگهن ٿا. جيڪڏهن هيلٿ چيڪ نوڊ مثال طور درخواستون ڪري ٿو، بيلنسر (جيڪو في الحال ٽريفڪ جي خدمت نه ڪري رهيو آهي) کي پاس ڪري ٿو، پوء هڪ عجيب صورتحال پيدا ٿئي ٿي: وسيلو زنده لڳي ٿو، پر ٽرئفڪ ان تائين نه پهچندي. اسان هن مسئلي کي هن طريقي سان حل ڪندا آهيون: اسان بيلنسرز ذريعي صحت جي چڪاس واري ٽرئفڪ کي شروع ڪرڻ جي ضمانت ڏني آهي. ٻين لفظن ۾، ڪلائنٽ ۽ صحت جي چيڪن کان ٽرئفڪ سان پيڪيٽس کي منتقل ڪرڻ جو منصوبو گهٽ ۾ گهٽ مختلف آهي: ٻنهي صورتن ۾، پيڪيٽ بيلنسرز تائين پهچندا، جيڪي انهن کي ٽارگيٽ وسيلن تائين پهچائي سگهندا.
فرق اهو آهي ته گراهڪ VIP کي درخواستون ڏين ٿا، جڏهن ته صحت جي چڪاس هر فرد RIP کي درخواستون ڏين ٿيون. هتي هڪ دلچسپ مسئلو پيدا ٿئي ٿو: اسان پنهنجي صارفين کي سرمائي IP نيٽ ورڪن ۾ وسيلن ٺاهڻ جو موقعو ڏيو ٿا. اچو ته تصور ڪريون ته ٻه مختلف بادل مالڪ آهن جن انهن جي خدمتن کي بيلنسرز جي پويان لڪائي ڇڏيو آهي. انهن مان هر هڪ وٽ 10.0.0.1/24 سبٽ ۾ وسيلا آهن، ساڳئي پتي سان. توهان کي ڪنهن به طرح انهن ۾ فرق ڪرڻ جي ضرورت آهي، ۽ هتي توهان کي Yandex.Cloud مجازي نيٽ ورڪ جي جوڙجڪ ۾ ڊيو ڪرڻ جي ضرورت آهي. اهو بهتر آهي ته وڌيڪ تفصيلن ۾ ڳولڻ لاء اسان لاءِ ھاڻي اھو ضروري آھي ته نيٽ ورڪ گھڻن سطحن تي مشتمل آھي ۽ ان ۾ سرنگون آھن جن کي سب نيٽ id ذريعي سڃاڻي سگھجي ٿو.
هيلٿ چيڪ نوڊس نام نهاد quasi-IPv6 ايڊريس استعمال ڪندي بيلنسرز سان رابطو ڪن ٿا. هڪ اڌ-ايڊريس هڪ IPv6 ايڊريس آهي جنهن ۾ IPv4 ايڊريس ۽ صارف سب نيٽ id ان جي اندر شامل آهي. ٽرئفڪ بيلنس تائين پهچندي آهي، جيڪو ان مان IPv4 وسيلن جو پتو ڪڍي ٿو، IPv6 کي IPv4 سان تبديل ڪري ٿو ۽ پيڪٽ کي صارف جي نيٽ ورڪ ڏانهن موڪلي ٿو.
ريورس ٽريفڪ ساڳئي طريقي سان وڃي ٿي: بيلنس ڏسي ٿو ته منزل صحت جي چڪاس ڪندڙن کان گرين نيٽورڪ آهي، ۽ IPv4 کي IPv6 ۾ بدلائي ٿو.
VPP - ڊيٽا جهاز جي دل
بيلنس ویکٹر پيڪٽ پروسيسنگ (VPP) ٽيڪنالاجي استعمال ڪندي لاڳو ڪيو ويو آهي، نيٽ ورڪ ٽرئفڪ جي بيچ پروسيسنگ لاءِ سسکو کان هڪ فريم ورڪ. اسان جي صورت ۾، فريم ورڪ ڪم ڪندڙ صارف-اسپيس نيٽ ورڪ ڊيوائس مئنيجمينٽ لائبريري جي چوٽي تي - Data Plane Development Kit (DPDK). هي اعلي پيڪيٽ پروسيسنگ ڪارڪردگي کي يقيني بڻائي ٿو: ڪنيل ۾ تمام گهٽ مداخلت ٿينديون آهن، ۽ ڪنييل اسپيس ۽ يوزر اسپيس جي وچ ۾ ڪو به حوالو سوئچ نه آهي.
وي پي پي اڃا به اڳتي وڌندي آهي ۽ پيڪيجز کي بيچ ۾ گڏ ڪندي سسٽم مان اڃا به وڌيڪ ڪارڪردگي کي نچوض ڪري ٿو. ڪارڪردگي حاصلات جديد پروسيسرز تي ڪيش جي جارحتي استعمال مان ايندا آهن. ٻئي ڊيٽا ڪيش استعمال ڪيا ويندا آهن (پيڪٽس "ویکٹرز" ۾ پروسيس ڪيا ويندا آهن، ڊيٽا هڪ ٻئي جي ويجهو آهي) ۽ هدايتون ڪيچ: وي پي پي ۾، پيڪٽ پروسيسنگ هڪ گراف جي پيروي ڪري ٿو، جن جا نوڊس فنڪشن تي مشتمل آهن جيڪي ساڳيو ڪم ڪن ٿا.
مثال طور، VPP ۾ IP پيڪٽس جي پروسيسنگ ھيٺ ڏنل حڪم ۾ ٿئي ٿي: پھريائين، پيڪٽ ھيڊرز پارسنگ نوڊ ۾ پارس ڪيا ويندا آھن، ۽ پوءِ اھي نوڊ ڏانھن موڪليا ويندا آھن، جيڪي اڳتي وڌندا آھن پيڪٽن کي روٽنگ جدولن جي مطابق.
ٿورڙو سخت. VPP جا ليکڪ پروسيسر ڪيچز جي استعمال ۾ سمجھوتا برداشت نه ڪندا آھن، تنھنڪري پيڪيٽس جي ویکٹر کي پروسيس ڪرڻ لاءِ عام ڪوڊ مينوئل ویکٹرائيزيشن تي مشتمل آھي: اتي ھڪڙو پروسيسنگ لوپ آھي جنھن ۾ ”اسان وٽ قطار ۾ چار پيڪيٽ آھن“ تي عمل ڪيو ويندو آھي، پوء ٻن لاء ساڳيو، پوء - هڪ لاء. Prefetch هدايتون اڪثر ڪري استعمال ڪيون وينديون آهن ڊيٽا کي ڪيش ۾ لوڊ ڪرڻ لاءِ انهن تائين پهچ کي تيز ڪرڻ لاءِ ايندڙ ورهاڱي ۾.
n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// ...
while (n_left_from >= 4 && n_left_to_next >= 2)
{
// processing multiple packets at once
u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
// ...
/* Prefetch next iteration. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
// actually process data
/* verify speculative enqueues, maybe switch current next frame */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
while (n_left_from > 0 && n_left_to_next > 0)
{
// processing packets by one
}
// processed batch
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}تنهن ڪري، صحت جي چڪاس IPv6 تي VPP تي ڳالهائيندو آهي، جيڪو انهن کي IPv4 ۾ تبديل ڪري ٿو. اهو گراف ۾ هڪ نوڊ طرفان ڪيو ويندو آهي، جنهن کي اسين الورورٿمڪ NAT سڏين ٿا. ريورس ٽريفڪ لاءِ (۽ IPv6 کان IPv4 ۾ تبديلي) اتي ساڳيو الورورٿمڪ NAT نوڊ آهي.
بيلنس گراهڪ کان سڌو ٽرئفڪ گراف نوڊس ذريعي وڃي ٿو، جيڪو پاڻ کي بيلنس انجام ڏئي ٿو.
پهريون نوڊ چپچپا سيشن آهي. هي هش کي محفوظ ڪري ٿو قائم ڪيل سيشن لاء. 5-tuple ۾ ڪلائنٽ جو پتو ۽ بندرگاهه شامل آهي جتان معلومات منتقل ڪئي وئي آهي، ٽريفڪ حاصل ڪرڻ لاء موجود وسيلن جو پتو ۽ بندرگاهن، انهي سان گڏ نيٽ ورڪ پروٽوڪول.
5-tuple hash اسان کي مدد ڪري ٿو گھٽ حسابن کي انجام ڏيڻ ۾ بعد ۾ مسلسل هيشنگ نوڊ، انهي سان گڏ بهتر سنڀاليندڙ وسيلن جي فهرست جي تبديلين جي پويان بيلنس. جڏهن هڪ پيڪٽ جنهن لاءِ ڪو به سيشن نه آهي بيلنسر تي اچي ٿو، اهو مسلسل هشنگ نوڊ ڏانهن موڪليو ويو آهي. هي اهو آهي جتي بيلنس ٿئي ٿي مسلسل هيشنگ استعمال ڪندي: اسان دستياب "لائيو" وسيلن جي فهرست مان هڪ وسيلو چونڊيو. اڳيون، پيڪٽس NAT نوڊ ڏانهن موڪليا ويا آهن، جيڪو اصل ۾ منزل جي پتي کي تبديل ڪري ٿو ۽ چيڪسمس کي ٻيهر ڳڻپيندو آهي. جئين توهان ڏسي سگهو ٿا، اسان VPP جي ضابطن جي پيروي ڪندا آهيون - پسند ڪرڻ وانگر، پروسيسر ڪيچ جي ڪارڪردگي کي وڌائڻ لاء ساڳئي حسابن کي گروپ ڪرڻ.
مسلسل ڇڪڻ
اسان ان کي ڇو چونڊيو ۽ اهو ڇا آهي؟ پهرين، اچو ته پوئين ڪم تي غور ڪريو - فهرست مان هڪ وسيلو چونڊيو.
متضاد هيشنگ سان، ايندڙ پيڪٽ جو هيش حساب ڪيو ويندو آهي، ۽ هڪ وسيلن کي فهرست مان چونڊيو ويندو آهي باقي هن هيش کي ورهائڻ جي وسيلن جي تعداد سان. جيستائين لسٽ ۾ ڪا تبديلي نه رهي، هي اسڪيم چڱي طرح ڪم ڪري ٿو: اسان هميشه ساڳئي مثال سان ساڳي 5-ٽپل سان پيڪيٽ موڪليندا آهيون. جيڪڏهن، مثال طور، ڪجهه وسيلن کي صحت جي چڪاس جو جواب ڏيڻ بند ڪيو، پوء هيش جي هڪ اهم حصي لاء چونڊ تبديل ٿي ويندي. ڪلائنٽ جو TCP ڪنيڪشن ٽوڙيو ويندو: ھڪڙو پيڪٽ جيڪو اڳي پھچندو آھي مثال A ٿي سگھي ٿو مثال B تائين پھچڻ شروع ڪري، جيڪو ھن پيڪٽ جي سيشن کان واقف نه آھي.
مسلسل هيشنگ بيان ڪيل مسئلو حل ڪري ٿي. هن تصور جي وضاحت ڪرڻ جو آسان طريقو هي آهي: تصور ڪريو ته توهان وٽ هڪ انگو آهي جنهن ۾ توهان وسيلن کي هيش ذريعي ورهايو ٿا (مثال طور، IP: پورٽ ذريعي). هڪ وسيلو چونڊڻ هڪ زاويه سان ڦيٿي کي ڦيرائي رهيو آهي، جيڪو پيٽ جي هيش طرفان طئي ڪيو ويندو آهي.
هي ٽرئفڪ جي ٻيهر ورڇ کي گھٽائي ٿو جڏهن وسيلن جي جوڙجڪ ۾ تبديلي اچي ٿي. وسيلا کي ختم ڪرڻ سان صرف ان حصي تي اثر پوندو جنهن ۾ وسيلو موجود هو. هڪ وسيلو شامل ڪرڻ سان تقسيم کي به تبديل ڪري ٿو، پر اسان وٽ هڪ چپچپا سيشن نوڊ آهي، جيڪو اسان کي اجازت ڏئي ٿو ته اڳ ۾ ئي قائم ڪيل سيشن کي نئين وسيلن ڏانهن تبديل نه ڪريون.
اسان ڏٺو ته بيلنس ۽ وسيلن جي وچ ۾ سڌو ٽرئفڪ کي ڇا ٿيندو. هاڻي اچو ته واپسي جي ٽرئفڪ کي ڏسو. اهو ساڳيو نمونو آهي جيئن چيڪ ٽريفڪ - الورورٿمڪ NAT ذريعي، يعني ڪلائنٽ ٽرئفڪ لاءِ ريورس NAT 44 ذريعي ۽ صحت جي چڪاس واري ٽرئفڪ لاءِ NAT 46 ذريعي. اسان پنهنجي منصوبي تي عمل ڪريون ٿا: اسان صحت جي چڪاس ٽرئفڪ ۽ حقيقي صارف ٽرئفڪ کي متحد ڪريون ٿا.
لوڊ بيلنسر-نوڊ ۽ گڏ ڪيل اجزاء
وي پي پي ۾ بيلنسرز ۽ وسيلن جي ٺاھ جوڙ مقامي خدمت - loadbalancer-node پاران ٻڌايو ويو آھي. اهو loadbalancer-ڪنٽرولر کان واقعن جي وهڪري جي رڪنيت حاصل ڪري ٿو ۽ موجوده VPP رياست ۽ ڪنٽرولر کان حاصل ڪيل ٽارگيٽ رياست جي وچ ۾ فرق کي پلاٽ ڪرڻ جي قابل آهي. اسان هڪ بند سسٽم حاصل ڪريون ٿا: API کان واقعا بيلنس ڪنٽرولر وٽ ايندا آهن، جيڪي وسيلن جي "زندگي" کي جانچڻ لاءِ هيلٿ چيڪ ڪنٽرولر کي ڪم تفويض ڪري ٿو. اهو، موڙ ۾، ڪمن کي تفويض ڪري ٿو هيلٿ چيڪ-نوڊ ۽ نتيجن کي گڏ ڪري ٿو، جنهن کان پوء اهو انهن کي واپس بيلنس ڪنٽرولر ڏانهن موڪلي ٿو. Loadbalancer-node ڪنٽرولر کان واقعن جي رڪنيت حاصل ڪري ٿو ۽ VPP جي حالت کي تبديل ڪري ٿو. اهڙي سسٽم ۾، هر خدمت صرف ڄاڻي ٿو ته پاڙيسري خدمتن بابت ڇا ضروري آهي. ڪنيڪشن جو تعداد محدود آهي ۽ اسان وٽ مختلف حصن کي آزاديءَ سان هلائڻ ۽ ماپڻ جي صلاحيت آهي.
ڪهڙن مسئلن کان پاسو ڪيو ويو؟
ڪنٽرول جهاز ۾ اسان جون سڀئي خدمتون Go ۾ لکيل آهن ۽ سٺي اسڪيلنگ ۽ قابل اعتماد خاصيتون آهن. Go ۾ ورهايل نظام جي تعمير لاءِ ڪيتريون ئي اوپن سورس لائبريريون آهن. اسان فعال طور تي GRPC استعمال ڪريون ٿا، سڀني حصن ۾ خدمت جي دريافت جي اوپن سورس تي عمل درآمد شامل آهي - اسان جون خدمتون هڪ ٻئي جي ڪارڪردگي جي نگراني ڪن ٿيون، انهن جي جوڙجڪ کي متحرڪ طور تي تبديل ڪري سگهون ٿا، ۽ اسان ان کي GRPC توازن سان ڳنڍيو آهي. ميٽرڪس لاءِ، اسان پڻ استعمال ڪريون ٿا اوپن سورس حل. ڊيٽا جهاز ۾، اسان کي سٺي ڪارڪردگي ۽ هڪ وڏي وسيلن جو ذخيرو ملي ٿو: اهو هڪ موقف گڏ ڪرڻ ڏاڍو ڏکيو آهي، جنهن تي اسان لوهه نيٽ ورڪ ڪارڊ جي بدران، VPP جي ڪارڪردگي تي ڀروسو ڪري سگهون ٿا.
مسئلا ۽ حل
ڇا ايترو سٺو ڪم نه ڪيو؟ Go وٽ خودڪار ميموري جو انتظام آهي، پر ميموري لڪ اڃا به ٿئي ٿي. انھن سان ڊيل ڪرڻ جو آسان طريقو آھي goroutines کي ھلائڻ ۽ انھن کي ختم ڪرڻ ياد رکڻ. Takeaway: ڏسو پنھنجي گو پروگرامن جي ميموري جو استعمال. گهڻو ڪري هڪ سٺو اشارو goroutines جو تعداد آهي. ھن ڪهاڻي ۾ ھڪڙو پلس آھي: Go ۾ اھو رن ٽائم ڊيٽا حاصل ڪرڻ آسان آھي - ميموري جو استعمال، ھلندڙ گوروٽين جو تعداد، ۽ ٻيا ڪيترائي پيرا ميٽر.
انهي سان گڏ، گو شايد فنڪشنل ٽيسٽ لاء بهترين انتخاب نه هجي. اهي ڪافي لفظي آهن، ۽ "هڪ بيچ ۾ CI ۾ هر شي کي هلائڻ" جو معياري طريقو انهن لاء بلڪل مناسب ناهي. حقيقت اها آهي ته فنڪشنل ٽيسٽ وڌيڪ وسيلا گهربل آهن ۽ حقيقي وقت ختم ٿيڻ جو سبب آهن. انهي جي ڪري، ٽيسٽ ناڪام ٿي سگهي ٿي ڇو ته سي پي يو يونٽ ٽيسٽ سان مصروف آهي. نتيجو: جيڪڏهن ممڪن هجي ته، يونٽ ٽيسٽن کان الڳ الڳ ”ڀاري“ ٽيسٽ ڪريو.
Microservice ايونٽ آرڪيٽيڪچر هڪ monolith کان وڌيڪ پيچيده آهي: ڪيترن ئي مختلف مشينن تي لاگ گڏ ڪرڻ بلڪل آسان ناهي. نتيجو: جيڪڏهن توهان مائڪرو سروسز ٺاهيندا آهيو، فوري طور تي ٽريڪنگ بابت سوچيو.
اسان جا منصوبا
اسان هڪ اندروني بيلنس شروع ڪنداسين، هڪ IPv6 بيلنس، ڪبرنيٽس اسڪرپٽ لاءِ سپورٽ شامل ڪنداسين، اسان جي خدمتن کي تيز ڪرڻ جاري رکون ٿا (في الحال صرف صحت چيڪ-نوڊ ۽ هيلٿ چيڪ-ctrl شارڊ ٿيل آهن)، نئين صحت جي چڪاس شامل ڪندا، ۽ چيڪن جي سمارٽ مجموعي کي پڻ لاڳو ڪندا. اسان پنهنجي خدمتن کي اڃا به وڌيڪ آزاد بڻائڻ جي امڪان تي غور ڪري رهيا آهيون - ته جيئن اهي هڪ ٻئي سان سڌو رابطو نه ڪن، پر پيغام جي قطار کي استعمال ڪندي. هڪ SQS-مطابقت رکندڙ خدمت تازو ئي Cloud ۾ ظاهر ٿيو آهي .
تازو، Yandex لوڊ بيلنس جي عوامي رليز ٿي. دريافت ڪريو خدمت ۾، توهان جي لاء آسان طريقي سان بيلنس کي منظم ڪريو ۽ توهان جي منصوبن جي غلطي رواداري کي وڌايو!
جو ذريعو: www.habr.com