په Yandex.Cloud کې د شبکې بار بیلانسر جوړښت

سلام، زه سرګي ایلانتسیف یم، زه وده کوم د شبکې بار بیلانسر په Yandex.Cloud کې. مخکې، ما د Yandex پورټل لپاره د L7 بیلنسر پراختیا رهبري کړې - همکاران ټوکه کوي چې هیڅ مهمه نده چې زه څه وکړم، دا یو بیلانسر دی. زه به د هابر لوستونکو ته ووایم چې څنګه په بادل پلیټ فارم کې بار اداره کړئ ، هغه څه چې موږ د دې هدف ترلاسه کولو لپاره د مثالي وسیلې په توګه ګورو ، او موږ څنګه د دې وسیلې جوړولو په لور حرکت کوو.

لومړی، راځئ چې ځینې اصطلاحات معرفي کړو:

• VIP (مجازی IP) - د بیلانس IP پته
• سرور، پس منظر، مثال - یو مجازی ماشین چې غوښتنلیک چلوي
• RIP (اصلي IP) - د سرور IP پته
• روغتیایی معاینه - د سرور چمتووالی معاینه کول
• د شتون زون، AZ - د معلوماتو مرکز کې جلا زیربنا
• سیمه - د مختلفو AZs اتحادیه

د بار توازن کونکي درې اصلي دندې حل کوي: دوی پخپله توازن ترسره کوي ، د خدماتو غلط برداشت ته وده ورکوي ، او د هغې اندازه کول ساده کوي. د غلطی زغم د اتوماتیک ترافیک مدیریت له لارې تضمین شوی: بیلانس د غوښتنلیک حالت څارنه کوي او د توازن څخه مثالونه لرې کوي چې د ژوند چیک نه تیریږي. اندازه کول په مساوي ډول د بار په ټولو مثالونو ویشلو ، او همدارنګه په الوتنه کې د مثالونو لیست تازه کولو سره تضمین کیږي. که چیرې توازن په کافي اندازه یونیفورم نه وي، ځینې مثالونه به یو بار ترلاسه کړي چې د دوی د ظرفیت له حد څخه ډیر وي، او خدمت به لږ باوري شي.

د بار بیلانسر اکثرا د پروتوکول پرت لخوا د OSI ماډل څخه طبقه بندي کیږي چې دا پرمخ ځي. د کلاوډ بیلانسر د TCP په کچه کار کوي، کوم چې د څلورم پرت، L4 سره مطابقت لري.

راځئ چې د کلاوډ بیلانس جوړښت عمومي لید ته لاړ شو. موږ به په تدریجي ډول د توضیحاتو کچه لوړه کړو. موږ د توازن اجزا په دریو ټولګیو ویشو. د ترتیب الوتکې ټولګي د کارونکي متقابل عمل مسؤلیت لري او د سیسټم هدف حالت ذخیره کوي. د کنټرول الوتکه د سیسټم اوسنی حالت ذخیره کوي او د ډیټا الوتکې ټولګي څخه سیسټمونه اداره کوي، کوم چې په مستقیم ډول د پیرودونکو څخه ستاسو مثالونو ته د ټرافیک رسولو مسولیت لري.

د معلوماتو الوتکه

ټرافیک په قیمتي وسایلو پای ته رسیږي چې د سرحدي روټرونو په نوم یادیږي. د غلطۍ زغم زیاتولو لپاره، دا ډول ډیری وسایل په یو ډیټا مرکز کې په ورته وخت کې کار کوي. بیا، ټرافیک توازن ته ځي، کوم چې د پیرودونکو لپاره د BGP له لارې ټولو AZs ته د هر ډول کاسټ IP پتې اعلانوي. 

ترافیک د ECMP له لارې لیږدول کیږي - دا د روټینګ ستراتیژي ده چې له مخې یې هدف ته څو مساوي ښې لارې شتون لري (زموږ په قضیه کې هدف به د منزل IP پته وي) او کڅوړې د دوی هر یو سره لیږل کیدی شي. موږ د لاندې سکیم سره سم په ډیری شتون زونونو کې د کار ملاتړ هم کوو: موږ په هر زون کې یو پته اعلانوو، ټرافيک نږدې نږدې ته ځي او له حد څخه بهر نه ځي. وروسته په پوسټ کې موږ به په ډیر تفصیل سره وګورو چې ترافیک څه پیښیږي.

د الوتکې ترتیب

 
د کنفنګ الوتکې کلیدي برخه API ده ، د کوم له لارې چې د بیلانسونو سره لومړني عملیات ترسره کیږي: رامینځته کول ، حذف کول ، د مثالونو ترکیب بدلول ، د روغتیا چیک پایلو ترلاسه کول او داسې نور. له یوې خوا ، دا یو REST API دی ، او له بلې خوا. بل، موږ په کلاوډ کې ډیری وختونه د gRPC چوکاټ کاروو، نو موږ REST ته gRPC ته "ژباړه" کوو او بیا یوازې gRPC کاروو. هره غوښتنه د غیر متناسب ایډمپوټینټ دندو لړۍ رامینځته کولو لامل کیږي چې د Yandex.Cloud کارمندانو په ګډ حوض کې اجرا کیږي. دندې په داسې ډول لیکل کیږي چې دوی هر وخت وځنډول شي او بیا پیل شي. دا د توزیع کولو وړتیا، تکرار وړتیا او د عملیاتو ننوتل تضمینوي.

د پایلې په توګه، د API څخه دنده به د توازن خدمت کنټرولر ته غوښتنه وکړي، کوم چې په Go کې لیکل شوی. دا کولی شي بیلانسونه اضافه او لرې کړي ، د بیک انډونو او تنظیماتو ترکیب بدل کړي. 

خدمت خپل حالت په Yandex ډیټابیس کې ذخیره کوي، یو توزیع شوی اداره شوی ډیټابیس چې تاسو به یې ډیر ژر وکاروئ. په Yandex.Cloud کې، لکه څنګه چې موږ دمخه وویل، د سپي خواړو مفهوم پلي کیږي: که موږ پخپله زموږ خدمات وکاروو ، نو زموږ پیرودونکي به د دوی کارولو څخه خوښ وي. د Yandex ډیټابیس د داسې مفهوم د پلي کولو یوه بیلګه ده. موږ خپل ټول معلومات په YDB کې ذخیره کوو، او موږ اړتیا نلرو چې د ډیټابیس ساتلو او اندازه کولو په اړه فکر وکړو: دا ستونزې زموږ لپاره حل شوي، موږ ډیټابیس د خدمت په توګه کاروو.

راځئ چې د بیلانس کنټرولر ته راستون شو. د دې دنده د بیلانسر په اړه معلومات خوندي کول او د روغتیا چیک کنټرولر ته د مجازی ماشین چمتووالي چیک کولو لپاره دنده لیږل دي.

د روغتیا چک کنټرولر

دا د چک مقرراتو بدلولو لپاره غوښتنې ترلاسه کوي، په YDB کې یې خوندي کوي، د هیلچیک نوډونو ترمنځ دندې توزیع کوي او پایلې یې راټولوي، چې بیا ډیټابیس ته خوندي کیږي او د loadbalancer کنټرولر ته لیږل کیږي. دا، په بدل کې، د معلوماتو په الوتکه کې د کلستر جوړښت بدلولو لپاره غوښتنه لیږي loadbalancer-node، کوم چې زه به یې لاندې بحث وکړم.

راځئ چې د روغتیا معاینې په اړه نور خبرې وکړو. دوی کولی شي په څو ټولګیو ویشل شي. پلټنې د بریالیتوب مختلف معیارونه لري. د TCP چکونه باید په بریالیتوب سره د یو ټاکلي وخت دننه اړیکه رامینځته کړي. د HTTP چکونه دواړه بریالي پیوستون او د 200 حالت کوډ سره ځواب ته اړتیا لري.

همدارنګه، چکونه د عمل په ټولګي کې توپیر لري - دوی فعال او غیر فعال دي. غیر فعال چکونه په ساده ډول څارنه کوي چې د ټرافیک سره څه پیښیږي پرته له کوم ځانګړي اقدام څخه. دا په L4 کې ډیر ښه کار نه کوي ځکه چې دا د لوړې کچې پروتوکولونو منطق پورې اړه لري: په L4 کې هیڅ معلومات شتون نلري چې عملیات څومره وخت نیسي یا ایا د پیوستون بشپړول ښه یا بد وو. فعال چیکونه بیلانس ته اړتیا لري ترڅو هر سرور مثال ته غوښتنې واستوي.

ډیری بار بیلانسران پخپله د ژوندانه معاینه ترسره کوي. په کلاوډ کې، موږ پریکړه وکړه چې د سیسټم دا برخې جلا کړو ترڅو د توزیع زیاتولو لپاره. دا طریقه به موږ ته اجازه درکړو چې د بیلانس شمیر زیات کړو پداسې حال کې چې خدمت ته د روغتیا چک غوښتنې شمیر ساتل کیږي. چکونه د جلا روغتیایی چک نوډونو لخوا ترسره کیږي، په کوم کې چې د چک هدفونه ټوټه شوي او نقل شوي دي. تاسو نشئ کولی د یو کوربه څخه چکونه ترسره کړئ، ځکه چې دا ممکن ناکام شي. بیا به موږ د هغه حالت حالت ترلاسه نه کړو چې هغه یې چیک کړی. موږ لږترلږه د دریو روغتیایی چک نوډونو څخه په هر حالت کې چیکونه ترسره کوو. موږ د دوامداره هیشینګ الګوریتمونو په کارولو سره د نوډونو تر مینځ د چیکونو اهداف شریکوو.

د توازن او روغتیا معاینه جلا کول کولی شي ستونزې رامینځته کړي. که چیرې د روغتیا چیک نوډ مثال ته غوښتنې وکړي ، د بیلانسر له لارې (کوم چې اوس مهال ترافیک ته خدمت نه کوي) ، نو یو عجیب حالت رامینځته کیږي: سرچینه ژوندي ښکاري ، مګر ترافیک به ورته ونه رسیږي. موږ دا ستونزه په دې ډول حل کوو: موږ تضمین لرو چې د بیلانس له لارې د روغتیا چیک ترافیک پیل کړو. په بل عبارت، د پیرودونکو او روغتیایی چکونو څخه د ټرافیک سره د کڅوړو حرکت کولو سکیم لږ تر لږه توپیر لري: په دواړو حالتونو کې، پاکټونه به توازن ته ورسیږي، کوم چې به یې هدف سرچینو ته ورسوي.

توپیر دا دی چې پیرودونکي VIP ته غوښتنې کوي، پداسې حال کې چې روغتیایی چکونه د هر انفرادي RIP لپاره غوښتنې کوي. یوه په زړه پورې ستونزه دلته راپورته کیږي: موږ خپلو کاروونکو ته فرصت ورکوو چې په خړ IP شبکې کې سرچینې رامینځته کړي. راځئ چې تصور وکړو چې دوه مختلف بادل مالکان شتون لري چې خپل خدمات یې د بیلانسونو تر شا پټ کړي دي. د دوی هر یو په 10.0.0.1/24 سبنټ کې سرچینې لري، د ورته پتې سره. تاسو اړتیا لرئ چې په یو ډول د دوی توپیر وکړئ، او دلته تاسو اړتیا لرئ چې د Yandex.Cloud مجازی شبکې جوړښت ته لاړ شئ. دا به غوره وي چې نور جزییات په کې ومومئ د شاوخوا څخه ویډیو: بادل پیښهدا زموږ لپاره اوس مهمه ده چې شبکه څو پرتې ده او تونلونه لري چې د فرعي نیټ ID لخوا توپیر کیدی شي.

د روغتیا چیک نوډونه د نامتو نیم IPv6 ادرسونو په کارولو سره بیلانسرز سره اړیکه نیسي. نیمه پته د IPv6 پته ده چې د IPv4 پته او د کارونکي فرعي نیټ ID په دننه کې ځای په ځای شوي. ټرافیک بیلانسر ته رسیږي، کوم چې د هغې څخه د IPv4 سرچینې پته استخراجوي، IPv6 د IPv4 سره بدلوي او پیکټ د کارونکي شبکې ته لیږي.

ریورس ټرافیک په ورته ډول ځي: بیلانسر ګوري چې منزل د روغتیایی چک کونکو څخه خړ شبکه ده، او IPv4 IPv6 ته بدلوي.

VPP - د معلوماتو الوتکې زړه

بیلانسر د ویکتور پیکټ پروسس کولو (VPP) ټیکنالوژۍ په کارولو سره پلي کیږي، د سیسکو څخه د شبکې ټرافیک د بیچ پروسس کولو لپاره یو چوکاټ. زموږ په قضیه کې، چوکاټ د کارونکي ځای شبکې وسیلې مدیریت کتابتون - د ډیټا پلان پرمختیا کټ (DPDK) په سر کې کار کوي. دا د پاکټ پروسس کولو لوړ فعالیت تضمینوي: په کرنل کې ډیر لږ مداخلې واقع کیږي، او د کرنل ځای او د کارونکي ځای ترمنځ هیڅ ډول بدلونونه شتون نلري. 

VPP حتی نور هم ځي او په بستونو کې د کڅوړو ترکیب کولو سره د سیسټم څخه حتی نور فعالیت فشاروي. د فعالیت لاسته راوړنې په عصري پروسیسرونو کې د کیچونو له تیریدونکي کارونې څخه راځي. دواړه ډیټا کیچونه کارول کیږي (پاکټونه په "ویکټرونو" کې پروسس کیږي، ډاټا یو بل ته نږدې دي) او د لارښوونې کیچونه: په VPP کې، د کڅوړې پروسس کول یو ګراف تعقیبوي، نوډونه چې هغه دندې لري چې ورته دنده ترسره کوي.

د مثال په توګه ، په VPP کې د IP پاکټونو پروسس په لاندې ترتیب کې پیښیږي: لومړی ، د پاکټ سرلیکونه په پارس کولو نوډ کې تجزیه کیږي ، او بیا دوی نوډ ته لیږل کیږي ، کوم چې د روټینګ جدولونو سره سم پاکټونه نور هم وړاندې کوي.

لږ سخت. د VPP لیکوالان د پروسیسر کیچونو په کارولو کې جوړجاړی نه زغمي ، نو د پاکټونو ویکتور پروسس کولو لپاره ځانګړي کوډ د لارښود ویکتوریزیشن لري: د پروسس کولو لوپ شتون لري په کوم کې چې "موږ په کتار کې څلور پاکټونه لرو" پروسس کیږي ، بیا د دوو لپاره ورته، بیا د یو لپاره. د پری فیچ لارښوونې ډیری وختونه په کیچونو کې ډیټا پورته کولو لپاره کارول کیږي ترڅو په راتلونکو تکرارونو کې دوی ته لاسرسی ګړندی کړي.

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-ټوپل د تاسیس شویو غونډو لپاره. 5-ټوپل کې د پیرودونکي پته او بندر شامل دي چې له هغې څخه معلومات لیږدول کیږي، د ټرافیک ترلاسه کولو لپاره د سرچینو پته او بندرونه، او همدارنګه د شبکې پروتوکول. 

د 5-ټوپل هش موږ سره مرسته کوي چې په راتلونکي دوامداره هیشینګ نوډ کې لږ محاسبه ترسره کړو ، په بیله بیا د بیلانسر شاته د سرچینو لیست بدلونونه ښه اداره کړئ. کله چې یو پاکټ چې هیڅ سیشن شتون نلري بیلنسر ته راځي، دا د دوامداره هشینګ نوډ ته لیږل کیږي. دا هغه ځای دی چې توازن د دوامداره هشنګ په کارولو سره پیښیږي: موږ د موجود "ژوندی" سرچینو لیست څخه سرچینه غوره کوو. بیا ، پاکټونه د NAT نوډ ته لیږل کیږي ، کوم چې واقعیا د منزل پته ځای په ځای کوي او چیکسمونه بیا محاسبه کوي. لکه څنګه چې تاسو لیدلی شئ، موږ د VPP قواعد تعقیب کوو - د خوښولو په څیر، د ورته حسابونو ګروپ کول ترڅو د پروسیسر کیچونو موثریت زیات کړي.

په دوامداره توګه هش کول

موږ ولې دا غوره کړه او دا هم څه ده؟ لومړی، راځئ چې پخوانۍ دنده په پام کې ونیسو - د لیست څخه د سرچینې غوره کول. 

د متضاد هش کولو سره ، د راتلونکي کڅوړې هش محاسبه کیږي ، او یوه سرچینه د لیست څخه غوره کیږي د پاتې سرچینو شمیر لخوا د دې هیش ویشلو سره. تر هغه چې لیست بدل نه وي، دا سکیم ښه کار کوي: موږ تل د ورته 5-ټوپل سره ورته مثال ته پیکټونه لیږو. که، د بیلګې په توګه، ځینې سرچینې د روغتیا چکونو ته ځواب ویل بند کړي، نو د هش د پام وړ برخې لپاره به انتخاب بدل شي. د پیرودونکي د TCP پیوستون به مات شي: یوه کڅوړه چې دمخه مثال A ته رسیدلې ممکن مثال B ته رسیدل پیل کړي ، کوم چې د دې کڅوړې ناستې سره آشنا ندي.

دوامداره هش کول تشریح شوې ستونزه حل کوي. د دې مفکورې تشریح کولو ترټولو اسانه لار دا ده: تصور وکړئ چې تاسو یوه حلقه لرئ چې تاسو یې د هش لخوا سرچینې توزیع کوئ (د مثال په توګه د IP: پورټ لخوا). د سرچینې غوره کول د څرخ په زاویه بدلول دي، کوم چې د کڅوړې د هش لخوا ټاکل کیږي.

دا د ټرافیک بیا ویش کموي کله چې د سرچینو جوړښت بدل شي. د سرچینې حذف کول به یوازې د دوامداره هشنګ حلقې برخه اغیزه وکړي چیرې چې سرچینه موقعیت لري. د سرچینې اضافه کول هم توزیع بدلوي ، مګر موږ د چپچینې ناستې نوډ لرو ، کوم چې موږ ته اجازه نه راکوي چې دمخه رامینځته شوي ناستې نوي سرچینو ته واړوو.

موږ وګورو چې د بیلانس او ​​سرچینو تر مینځ مستقیم ترافیک ته څه پیښیږي. اوس راځئ چې بیرته راستنیدونکي ترافیک وګورو. دا ورته نمونه تعقیبوي لکه د ترافیک چیک - د الګوریتمیک NAT له لارې ، دا د پیرودونکي ترافیک لپاره د NAT 44 ریورس له لارې او د روغتیا چیک ترافیک لپاره د NAT 46 له لارې. موږ خپل سکیم ته غاړه کیږدو: موږ د روغتیایی چکونو ترافیک او د ریښتیني کارونکي ترافیک متحد کوو.

د لوډ بیلانسر نوډ او راټول شوي اجزا

په VPP کې د بیلانسونو او سرچینو ترکیب د ځایی خدماتو لخوا راپور شوی - loadbalancer-node. دا د loadbalancer-controller څخه د پیښو جریان کې ګډون کوي ​​​​او د دې وړتیا لري چې د اوسني VPP حالت او د کنټرولر څخه ترلاسه شوي هدف حالت ترمینځ توپیر پلیټ کړي. موږ یو تړل شوی سیسټم ترلاسه کوو: د API څخه پیښې د توازن کنټرولر ته راځي، کوم چې د روغتیا چک کنټرولر ته دندې ګماري ترڅو د سرچینو "ژوندیتوب" وګوري. دا، په بدل کې، د روغتیا چک نوډ ته دندې ګماري او پایلې راټولوي، وروسته له هغې چې دا بیرته د توازن کنټرولر ته لیږي. Loadbalancer-node د کنټرولر څخه پیښو ته ګډون کوي ​​او د VPP حالت بدلوي. په داسې سیسټم کې، هر خدمت یوازې هغه څه پوهیږي چې د ګاونډیو خدماتو په اړه اړین دي. د ارتباطاتو شمیر محدود دی او موږ د دې وړتیا لرو چې مختلف برخې په خپلواکه توګه کار او اندازه کړو.

د کومو مسلو مخنیوی وشو؟

په کنټرول الوتکه کې زموږ ټول خدمات په Go کې لیکل شوي او د ښه پیمانه کولو او اعتبار وړ ځانګړتیاوې لري. Go د توزیع شوي سیسټمونو جوړولو لپاره ډیری خلاصې سرچینې کتابتونونه لري. موږ په فعاله توګه GRPC کاروو، ټولې برخې د خدماتو کشف کولو خلاصې سرچینې پلي کول لري - زموږ خدمتونه د یو بل فعالیت څارنه کوي، کولی شي د دوی جوړښت په متحرک ډول بدل کړي، او موږ دا د GRPC توازن سره تړلې. د میټریکونو لپاره، موږ د خلاصې سرچینې حل هم کاروو. د ډیټا په الوتکه کې، موږ ښه فعالیت او د زیرمو لوی زیرمه ترلاسه کړه: دا خورا ستونزمنه وه چې یو موقف راټول کړو چې موږ کولی شو د VPP فعالیت باندې تکیه وکړو، د اوسپنې شبکې کارت پرځای.

ستونزې او حل لارې

څه شی دومره ښه کار نه دی کړی؟ Go د اتوماتیک حافظې مدیریت لري ، مګر د حافظې لیک لاهم پیښیږي. د دوی سره د معاملې ترټولو اسانه لار د ګوروټین چلول دي او په یاد ولرئ چې دوی یې ختم کړئ. ټیک وے: د خپل Go برنامو د حافظې مصرف وګورئ. ډیری وختونه یو ښه شاخص د ګوروټینونو شمیر دی. پدې کیسه کې یو پلس شتون لري: په Go کې د چلولو ډیټا ترلاسه کول اسانه دي - د حافظې مصرف ، د چلولو ګوروټینونو شمیر ، او ډیری نور پیرامیټونه.

همچنان ، Go ممکن د فعال ازموینو لپاره غوره انتخاب نه وي. دوی خورا لفظي دي ، او "په CI کې هرڅه په یوه بسته کې چلول" معیاري چلند د دوی لپاره خورا مناسب ندي. حقیقت دا دی چې فعالې ازموینې ډیرې سرچینې غوښتنې دي او د ریښتیني وخت پای ته رسیدو لامل کیږي. د دې له امله، ازموینې ممکن ناکام شي ځکه چې CPU د واحد ازموینې سره بوخت دی. پایله: که امکان ولري، د واحد ازموینې څخه جلا "درانه" ازموینې ترسره کړئ. 

د مایکرو سرویس پیښې جوړښت د مونولیت په پرتله خورا پیچلی دی: په لسګونو مختلف ماشینونو کې د لاګونو راټولول خورا اسانه ندي. پایله: که تاسو مایکرو خدمتونه جوړ کړئ ، سمدلاسه د تعقیب په اړه فکر وکړئ.

زموږ پلانونه

موږ به یو داخلي بیلانسر په لاره واچوو، یو IPv6 بیلنسر، د Kubernetes سکریپټونو لپاره مالتړ اضافه کړو، زموږ خدماتو ته ادامه ورکړو (اوس مهال یوازې د روغتیا چیک نوډ او روغتیا چیک-ctrl شارډ شوي)، نوي روغتیایی چکونه اضافه کړئ، او د چکونو سمارټ مجموعه هم پلي کړئ. موږ د دې امکان په پام کې نیسو چې زموږ خدمتونه نور هم خپلواک کړي - ترڅو دوی په مستقیم ډول له یو بل سره اړیکه ونلري، مګر د پیغام کتار په کارولو سره. د SQS سره مطابقت لرونکی خدمت پدې وروستیو کې په کلاوډ کې څرګند شوی د Yandex پیغام کتار.

په دې وروستیو کې، د Yandex Load Balancer عامه خوشې کول ترسره شوي. سپړنه اسناد خدمت ته ، بیلانسران په داسې طریقه اداره کړئ چې ستاسو لپاره مناسب وي او ستاسو د پروژو د خطا زغم زیات کړئ!

سرچینه: www.habr.com