Yandex.Cloud တွင် network load balancer ၏ တည်ဆောက်ပုံ

မင်္ဂလာပါ၊ ကျွန်ုပ်သည် Sergey Elantsev ပါ၊ ကျွန်ုပ်သည် ဖွံ့ဖြိုးတိုးတက်သည်။ network load balancer Yandex.Cloud တွင် ယခင်က Yandex ပေါ်တယ်အတွက် L7 balancer ဖွံ့ဖြိုးတိုးတက်ရေးကို ကျွန်တော် ဦးဆောင်ခဲ့သည် - လုပ်ဖော်ကိုင်ဖက်များက ကျွန်ုပ်ဘာပဲလုပ်လုပ်၊ ၎င်းသည် ဟန်ချက်ညီသူအဖြစ်သို့ ပြောင်းလဲသွားသည်ဟု လုပ်ဖော်ကိုင်ဖက်များက ဟာသလုပ်ကြသည်။ Habr စာဖတ်သူများအား cloud ပလပ်ဖောင်းတွင် ဝန်ထုပ်ဝန်ပိုးကို မည်ကဲ့သို့ စီမံခန့်ခွဲရမည်၊ ဤပန်းတိုင်ကို အောင်မြင်ရန်အတွက် စံပြကိရိယာအဖြစ် ကျွန်ုပ်တို့မြင်ရသည့်အရာနှင့် ဤကိရိယာကို တည်ဆောက်ရန် ကျွန်ုပ်တို့ မည်သို့လုပ်ဆောင်နေပုံကို ပြောပြပါမည်။

ပထမဦးစွာ ဝေါဟာရအချို့ကို မိတ်ဆက်ပေးပါရစေ။

• VIP (Virtual IP) - ဟန်ချက်ညီသော IP လိပ်စာ
• ဆာဗာ၊ နောက်ကွယ်၊ ဥပမာ - အက်ပလီကေးရှင်းကို လုပ်ဆောင်နေသည့် virtual machine တစ်ခု
• RIP (Real IP) - ဆာဗာ IP လိပ်စာ
• Healthcheck - ဆာဗာအဆင်သင့်စစ်ဆေးခြင်း။
• ရရှိနိုင်မှုဇုန်၊ AZ - ဒေတာစင်တာရှိ သီးခြားအခြေခံအဆောက်အအုံ
• ဒေသ - မတူညီသော AZs များသမဂ္ဂ

Load Balancers များသည် အဓိကလုပ်ဆောင်စရာသုံးခုကို ဖြေရှင်းပေးသည်- ၎င်းတို့သည် ဟန်ချက်ညီမှုကို လုပ်ဆောင်ပြီး၊ ဝန်ဆောင်မှု၏ အမှားအယွင်းကို ခံနိုင်ရည်ရှိမှုကို မြှင့်တင်ပေးပြီး ၎င်း၏ အတိုင်းအတာကို ရိုးရှင်းစေသည်။ အမှားအယွင်းခံနိုင်ရည်အား အလိုအလျောက်အသွားအလာစီမံခန့်ခွဲမှုအားဖြင့် သေချာစေသည်- ချိန်ခွင်လျှာသည် အပလီကေးရှင်း၏အခြေအနေကို စောင့်ကြည့်ပြီး အသက်ဝင်မှုစစ်ဆေးခြင်းမအောင်မြင်သည့် ဟန်ချက်ညီခြင်းမှ ဖြစ်ရပ်များကို ဖယ်ထုတ်ထားသည်။ သာဓကများတစ်လျှောက် ဝန်ကို အညီအမျှ ခွဲဝေပေးသည့်အပြင် ပျံသန်းနေသော ဖြစ်ရပ်များစာရင်းကို အပ်ဒိတ်လုပ်ခြင်းဖြင့် အတိုင်းအတာကို သေချာစေသည်။ ချိန်ခွင်လျှာ လုံလောက်စွာ မညီပါက၊ အချို့သော ဖြစ်ရပ်များသည် ၎င်းတို့၏ စွမ်းဆောင်ရည် ကန့်သတ်ချက်ထက် ကျော်လွန်သော ဝန်ကို လက်ခံရရှိမည်ဖြစ်ပြီး ဝန်ဆောင်မှုသည် ယုံကြည်စိတ်ချရမှု နည်းပါးလာပါမည်။

load balancer ကို မကြာခဏ OSI မော်ဒယ်မှ ပရိုတိုကောအလွှာဖြင့် ခွဲခြားသတ်မှတ်သည်။ Cloud Balancer သည် စတုတ္ထအလွှာ L4 နှင့် ကိုက်ညီသည့် TCP အဆင့်တွင် လုပ်ဆောင်သည်။

Cloud Balancer ဗိသုကာ၏ ခြုံငုံသုံးသပ်ချက်သို့ ဆက်သွားကြပါစို့။ အသေးစိတ်အဆင့်ကို ဖြည်းဖြည်းချင်း တိုးသွားမယ်။ Balancer အစိတ်အပိုင်းများကို အမျိုးအစားသုံးမျိုးခွဲထားပါသည်။ config plane class သည် အသုံးပြုသူ အပြန်အလှန်ဆက်သွယ်မှုအတွက် တာဝန်ရှိပြီး စနစ်၏ ပစ်မှတ်အခြေအနေကို သိမ်းဆည်းထားသည်။ ထိန်းချုပ်ရေးလေယာဉ်သည် စနစ်၏လက်ရှိအခြေအနေကို သိမ်းဆည်းထားပြီး ဒေတာလေယာဉ်အမျိုးအစားမှ စနစ်များကို စီမံခန့်ခွဲသည်၊ ၎င်းသည် ဖောက်သည်များထံမှ လမ်းကြောင်းများကို သင့်ဖြစ်ရပ်များသို့ တိုက်ရိုက်ပို့ဆောင်ရန် တာဝန်ရှိသည်။

အပါယ်ဒေ

လမ်းကြောင်းသည် နယ်စပ်ရောက်တာများဟုခေါ်သော စျေးကြီးသော စက်များတွင် အဆုံးသတ်သည်။ အမှားအယွင်းခံနိုင်ရည်ကို တိုးမြှင့်ရန်၊ ဒေတာစင်တာတစ်ခုတွင် ယင်းကဲ့သို့သော စက်များစွာသည် တစ်ပြိုင်နက် လုပ်ဆောင်သည်။ ထို့နောက် အသွားအလာသည် သုံးစွဲသူများအတွက် BGP မှတစ်ဆင့် AZs များအားလုံးသို့ မည်သည့်ကာစ် IP လိပ်စာများကို ကြေညာသည့် ချိန်ခွင်လျှာများထံ ရောက်သွားပါသည်။ 

Traffic ကို ECMP မှတဆင့် ပေးပို့သည် - ၎င်းသည် ပစ်မှတ်သို့ အညီအမျှ ကောင်းမွန်သော လမ်းကြောင်းများစွာ ရှိနိုင်သည် (ကျွန်ုပ်တို့၏ အခြေအနေတွင်၊ ပစ်မှတ်သည် ဦးတည်ရာ IP လိပ်စာဖြစ်လိမ့်မည်) နှင့် ၎င်းတို့အနက်မှ အစုံလိုက်များကို ပေးပို့နိုင်ပါသည်။ အောက်ပါအစီအစဥ်အရ ရရှိနိုင်မှုဇုန်အများအပြားတွင်လည်း ကျွန်ုပ်တို့သည် အလုပ်များကို ပံ့ပိုးပေးသည်- ကျွန်ုပ်တို့သည် ဇုန်တစ်ခုစီတွင် လိပ်စာတစ်ခုကို ကြော်ငြာကာ အနီးဆုံးနေရာသို့သွားကာ ကန့်သတ်ချက်များကို ကျော်လွန်မသွားပါ။ နောက်ပိုင်းတွင် ကျွန်ုပ်တို့သည် ယာဉ်ကြောအသွားအလာများ မည်သို့ဖြစ်မည်ကို အသေးစိတ်ကြည့်ရှုပါမည်။

လေယာဉ်စီစဉ်မှု

 
config plane ၏ အဓိက အစိတ်အပိုင်းမှာ ချိန်ခွင်လျှာများဖြင့် အခြေခံလုပ်ဆောင်မှုများကို လုပ်ဆောင်ပေးသည့် API ဖြစ်သည်- ဥပမာများကို ဖန်တီးခြင်း၊ ဖျက်ခြင်း၊ ပေါင်းစပ်မှုကို ပြောင်းလဲခြင်း၊ ကျန်းမာရေးစစ်ဆေးမှုရလဒ်များ ရယူခြင်းစသည်ဖြင့် တစ်ဖက်တွင်၊ ၎င်းသည် REST API ဖြစ်ပြီး၊ အခြား၊ ကျွန်ုပ်တို့သည် Cloud တွင် gRPC မူဘောင်ကို အလွန်မကြာခဏအသုံးပြုသည်၊ ထို့ကြောင့် ကျွန်ုပ်တို့သည် REST ကို gRPC သို့ “ဘာသာပြန်ဆိုပြီးနောက် gRPC ကိုသာအသုံးပြုသည်။ မည်သည့်တောင်းဆိုမှုမဆို Yandex.Cloud လုပ်သားများ၏ ဘုံရေကန်တွင် လုပ်ဆောင်သည့် အပြိုင်အဆိုင်လုပ်ဆောင်နိုင်သော အစွမ်းထက်သည့်အလုပ်များ ဆက်တိုက်ဖန်တီးခြင်းကို ဦးတည်စေသည်။ လုပ်ဆောင်စရာများကို အချိန်မရွေး ဆိုင်းငံ့ထားနိုင်ပြီး ပြန်လည်စတင်နိုင်သည့် နည်းလမ်းဖြင့် ရေးသားထားသည်။ ၎င်းသည် ချဲ့ထွင်နိုင်မှု၊ ထပ်တလဲလဲနိုင်မှုနှင့် လည်ပတ်မှုမှတ်တမ်းများကို သေချာစေသည်။

ရလဒ်အနေဖြင့်၊ API မှလုပ်ဆောင်စရာသည် Go တွင်ရေးသားထားသည့် balancer service controller သို့ တောင်းဆိုမှုတစ်ခုပြုလုပ်မည်ဖြစ်သည်။ ၎င်းသည် ချိန်ခွင်လျှာများကို ပေါင်းထည့်နိုင်ပြီး ဖယ်ရှားနိုင်သည်၊ နောက်ခံများနှင့် ဆက်တင်များ၏ ဖွဲ့စည်းမှုကို ပြောင်းလဲနိုင်သည်။ 

ဝန်ဆောင်မှုသည် မကြာမီ သင်အသုံးပြုနိုင်တော့မည့် ဖြန့်ဝေစီမံထားသော ဒေတာဘေ့စ်တစ်ခုဖြစ်သည့် Yandex Database တွင် ၎င်း၏အခြေအနေကို သိမ်းဆည်းထားသည်။ Yandex.Cloud တွင်၊ ကျွန်ုပ်တို့ရှိပြီးသားဖြစ်သည်။ ပြောတယ်ခွေးအစားအစာ အယူအဆ အကျုံးဝင်သည်- ကျွန်ုပ်တို့ကိုယ်တိုင် ကျွန်ုပ်တို့၏ ဝန်ဆောင်မှုများကို အသုံးပြုပါက၊ ကျွန်ုပ်တို့၏ ဖောက်သည်များသည် ၎င်းတို့ကို အသုံးပြုရသည်ကို ပျော်ရွှင်စေပါသည်။ Yandex ဒေတာဘေ့စ်သည် ထိုကဲ့သို့သော အယူအဆကို အကောင်အထည်ဖော်ခြင်း၏ ဥပမာတစ်ခုဖြစ်သည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဒေတာအားလုံးကို YDB တွင် သိမ်းဆည်းထားပြီး ဒေတာဘေ့စ်ကို ထိန်းသိမ်းခြင်းနှင့် အရွယ်အစားချဲ့ထွင်ခြင်းအတွက် စဉ်းစားရန်မလိုအပ်ပါ- ဤပြဿနာများကို ကျွန်ုပ်တို့အတွက် ဖြေရှင်းပေးသည်၊ ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်ကို ဝန်ဆောင်မှုတစ်ခုအဖြစ် အသုံးပြုပါသည်။

Balancer Controller သို့ ပြန်သွားကြပါစို့။ ၎င်း၏တာဝန်မှာ Balancer နှင့်ပတ်သက်သော အချက်အလက်များကို သိမ်းဆည်းရန်နှင့် virtual machine ၏ အဆင်သင့်ဖြစ်မှုကို ကျန်းမာရေးစစ်ဆေးသည့် controller သို့ စစ်ဆေးရန် တာဝန်တစ်ခု ပေးပို့ရန်ဖြစ်သည်။

ကျန်းမာရေးစစ်ဆေးခြင်း ထိန်းချုပ်ကိရိယာ

၎င်းသည် စစ်ဆေးခြင်းစည်းမျဉ်းများကို ပြောင်းလဲရန် တောင်းဆိုမှုများကို လက်ခံရရှိသည်၊ YDB တွင် ၎င်းတို့ကို သိမ်းဆည်းကာ၊ healtcheck node များအကြား လုပ်ဆောင်စရာများကို ဖြန့်ဝေကာ ရလဒ်များကို စုစည်းကာ၊ ထို့နောက် database တွင် သိမ်းဆည်းပြီး loadbalancer controller သို့ ပေးပို့သည်။ တစ်ဖန် ၎င်းသည် အောက်တွင်ဖော်ပြထားသော ဆွေးနွေးမည့် loadbalancer-node သို့ data plane အတွင်းရှိ cluster ၏ဖွဲ့စည်းပုံကို ပြောင်းလဲရန် တောင်းဆိုချက်တစ်ခု ပေးပို့သည်။

ကျန်းမာရေးစစ်ဆေးမှုတွေအကြောင်း ထပ်ပြောကြရအောင်။ ၎င်းတို့ကို အတန်းများစွာ ခွဲခြားနိုင်သည်။ စာရင်းစစ်များသည် မတူညီသော အောင်မြင်မှုစံနှုန်းများရှိသည်။ TCP စစ်ဆေးမှုများသည် သတ်မှတ်ထားသောအချိန်အတိုင်းအတာတစ်ခုအတွင်း ချိတ်ဆက်မှုကို အောင်မြင်စွာတည်ဆောက်ရန် လိုအပ်သည်။ HTTP စစ်ဆေးမှုများသည် အောင်မြင်သောချိတ်ဆက်မှုနှင့် အခြေအနေကုဒ် 200 ပါသော တုံ့ပြန်မှုနှစ်ခုစလုံး လိုအပ်သည်။

ထို့အပြင်၊ စစ်ဆေးမှုများသည် လုပ်ဆောင်ချက်အမျိုးအစားတွင် ကွဲပြားသည် - ၎င်းတို့သည် တက်ကြွပြီး passive ဖြစ်သည်။ Passive checks များသည် အထူးလုပ်ဆောင်မှုမရှိဘဲ အသွားအလာနှင့်ဖြစ်ပျက်နေသည့်အရာကို စောင့်ကြည့်ရုံသာဖြစ်သည်။ ၎င်းသည် L4 တွင် ကောင်းစွာအလုပ်မလုပ်သောကြောင့် ၎င်းသည် မြင့်မားသောအဆင့်ပရိုတိုကောများ၏ ယုတ္တိအပေါ် မူတည်သောကြောင့်ဖြစ်သည်- L4 တွင် လုပ်ဆောင်ချက်မည်မျှကြာခဲ့သည် သို့မဟုတ် ချိတ်ဆက်မှုပြီးစီးမှု ကောင်းမွန်ခြင်းရှိ၊ မရှိနှင့်ပတ်သက်သော အချက်အလက်မရှိပါ။ Active checks များသည် server instance တစ်ခုစီသို့ တောင်းဆိုချက်များကို ပေးပို့ရန် balancer ကို လိုအပ်ပါသည်။

load balancers အများစုသည် အသက်ဝင်မှု စစ်ဆေးမှုများကို ကိုယ်တိုင်လုပ်ဆောင်ကြသည်။ Cloud တွင်၊ ချဲ့ထွင်နိုင်မှုကို တိုးမြှင့်ရန်အတွက် စနစ်၏ ဤအစိတ်အပိုင်းများကို ခွဲထုတ်ရန် ဆုံးဖြတ်ခဲ့သည်။ ဤချဉ်းကပ်မှုသည် ဝန်ဆောင်မှုအတွက် ကျန်းမာရေးစစ်ဆေးရန် တောင်းဆိုမှုအရေအတွက်ကို ထိန်းသိမ်းထားစဉ်တွင် မျှတမှုအရေအတွက်ကို တိုးမြှင့်နိုင်စေမည်ဖြစ်သည်။ စစ်ဆေးမှုများကို သီးခြားကျန်းမာရေးစစ်ဆေးသည့် ခုံများမှ လုပ်ဆောင်ပြီး စစ်ဆေးသည့်ပစ်မှတ်များကို ခွဲခြမ်းစိပ်ဖြာပြီး ထပ်တူပြုပါသည်။ မအောင်မြင်နိုင်သောကြောင့် အိမ်ရှင်တစ်ဦးထံမှ စစ်ဆေးမှုများကို သင်လုပ်ဆောင်၍မရပါ။ အဲဒီအခါမှာ ခြံထဲ အခြေအနေကို ရောက်မှာမဟုတ်ဘူး။ ကျွန်ုပ်တို့သည် အနည်းဆုံး ကျန်းမာရေးစစ်ဆေးမှု ဆုံမှတ်သုံးခုမှ ဖြစ်ရပ်တစ်ခုခုကို စစ်ဆေးမှုများ ပြုလုပ်ပါသည်။ ကိုက်ညီသော hashing algorithms ကို အသုံးပြု၍ node များကြား စစ်ဆေးခြင်း၏ ရည်ရွယ်ချက်များကို ကျွန်ုပ်တို့ မျှဝေပါသည်။

ဟန်ချက်ညီခြင်းနှင့် ကျန်းမာရေးစစ်ဆေးခြင်းတို့ကို ခွဲထုတ်ခြင်းသည် ပြဿနာများကို ဖြစ်ပေါ်စေနိုင်သည်။ healthcheck node သည် instance အား တောင်းဆိုမှုများပြုလုပ်ပြီး balancer (လက်ရှိ traffic ကို ဆောင်ရွက်ပေးခြင်းမရှိသည့်) ကိုကျော်ဖြတ်ပါက၊ ထူးဆန်းသောအခြေအနေတစ်ခု ဖြစ်ပေါ်လာသည်- အရင်းအမြစ်သည် အသက်ရှင်နေပုံရသော်လည်း traffic သည် ၎င်းကိုရောက်ရှိမည်မဟုတ်ပါ။ ဤပြဿနာကို ဤနည်းဖြင့် ဖြေရှင်းပါသည်- ဟန်ချက်ညီသူများမှတဆင့် ကျန်းမာရေးစစ်ဆေးခြင်းလမ်းကြောင်းကို စတင်ရန် ကျွန်ုပ်တို့ အာမခံပါသည်။ တစ်နည်းဆိုရသော်၊ ဖောက်သည်များထံမှ အသွားအလာရှိသော ပက်ကေ့ခ်ျများကို ရွှေ့ခြင်းနှင့် ကျန်းမာရေးစစ်ဆေးမှုများမှ အနည်းအကျဉ်းကွာခြားသည်- နှစ်ခုလုံးတွင်၊ ပက်ကတ်များသည် ပစ်မှတ်အရင်းအမြစ်များသို့ ပို့ဆောင်ပေးမည့် ချိန်ခွင်လျှာများဆီသို့ ရောက်ရှိသွားမည်ဖြစ်သည်။

ကွာခြားချက်မှာ သုံးစွဲသူများသည် VIP သို့ တောင်းဆိုမှုများ ပြုလုပ်ကြပြီး ကျန်းမာရေးစစ်ဆေးမှုများသည် တစ်ဦးချင်း RIP တစ်ဦးစီထံ တောင်းဆိုမှုများ ပြုလုပ်ကြသည်။ ဤနေရာတွင် စိတ်ဝင်စားစရာကောင်းသည့် ပြဿနာတစ်ခု ပေါ်လာသည်- ကျွန်ုပ်တို့သည် သုံးစွဲသူများအား မီးခိုးရောင် IP ကွန်ရက်များတွင် အရင်းအမြစ်များကို ဖန်တီးရန် အခွင့်အရေးပေးပါသည်။ Balancers များနောက်တွင် ၎င်းတို့၏ ဝန်ဆောင်မှုများကို ဝှက်ထားသော မတူညီသော cloud ပိုင်ရှင်နှစ်ဦးရှိကြောင်း စိတ်ကူးကြည့်ကြပါစို့။ ၎င်းတို့တစ်ခုစီတွင် တူညီသောလိပ်စာများဖြင့် 10.0.0.1/24 subnet တွင် အရင်းအမြစ်များရှိသည်။ သင်သည် ၎င်းတို့ကို တစ်နည်းနည်းဖြင့် ခွဲခြားသိမြင်နိုင်ရန်လိုအပ်ပြီး ဤနေရာတွင် Yandex.Cloud virtual network ၏ တည်ဆောက်ပုံသို့ ဝင်ရောက်ရန် လိုအပ်ပါသည်။ အသေးစိတ်အချက်အလက်များကို ပိုမိုသိရှိရန် ပိုမိုကောင်းမွန်ပါသည်။ about:cloud event မှ ဗီဒီယို၊ ကွန်ရက်တွင် အလွှာပေါင်းစုံရှိပြီး subnet id ဖြင့် ခွဲခြားနိုင်သော tunnels များ ရှိကြောင်း ယခု ကျွန်ုပ်တို့အတွက် အရေးကြီးပါသည်။

Healthcheck nodes များသည် quasi-IPv6 လိပ်စာများဟုခေါ်သော ဟန်ချက်ညီသူများထံ ဆက်သွယ်ပါ။ လိပ်စာတစ်ပိုင်းသည် IPv6 လိပ်စာတစ်ခုပါရှိသော IPv4 လိပ်စာတစ်ခုဖြစ်ပြီး ၎င်းအတွင်းတွင် ထည့်သွင်းထားသော အသုံးပြုသူ၏ subnet id ဖြစ်သည်။ လမ်းကြောင်းသည် ၎င်းမှ IPv4 အရင်းအမြစ်လိပ်စာကို ထုတ်ယူသည့် Balancer သို့ရောက်ရှိပြီး IPv6 ကို IPv4 ဖြင့် အစားထိုးပြီး အသုံးပြုသူ၏ကွန်ရက်သို့ ပက်ကတ်ကို ပေးပို့သည်။

ပြောင်းပြန်အသွားအလာသည် တူညီသည်- ချိန်ခွင်လျှာသည် ဦးတည်ရာသည် ကျန်းမာရေးစစ်ဆေးသူများထံမှ မီးခိုးရောင်ကွန်ရက်ဖြစ်ကြောင်း မြင်ပြီး IPv4 သို့ IPv6 အဖြစ် ပြောင်းလဲသည်။

VPP - ဒေတာလေယာဉ်၏နှလုံး

ချိန်ခွင်လျှာသည် ကွန်ရက်အသွားအလာကို အသုတ်လိုက်လုပ်ဆောင်ခြင်းအတွက် Cisco မှ မူဘောင်တစ်ခုဖြစ်သည့် Vector Packet Processing (VPP) နည်းပညာကို အသုံးပြုထားသည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ မူဘောင်သည် အသုံးပြုသူနေရာလွတ်ကွန်ရက်စက်ပစ္စည်းစီမံခန့်ခွဲမှုစာကြည့်တိုက် - Data Plane Development Kit (DPDK) ၏ထိပ်တွင်အလုပ်လုပ်သည်။ ၎င်းသည် မြင့်မားသော packet လုပ်ဆောင်ခြင်း စွမ်းဆောင်ရည်ကို သေချာစေသည်- kernel တွင် နှောင့်ယှက်မှုများ နည်းပါးပြီး kernel space နှင့် user space အကြား ဆက်စပ်ခလုတ်များ မရှိပါ။ 

VPP သည် ပိုမိုတိုးတက်ကောင်းမွန်လာပြီး ပက်ကေ့ဂျ်များကို အစုလိုက်အပြုံလိုက် ပေါင်းစပ်ခြင်းဖြင့် စနစ်၏စွမ်းဆောင်ရည်ကို ပိုမိုညှစ်ထုတ်ပါသည်။ ခေတ်မီပရိုဆက်ဆာများပေါ်တွင် ကက်ရှ်များကို ပြင်းထန်စွာအသုံးပြုခြင်းကြောင့် စွမ်းဆောင်ရည်များ မြင့်တက်လာသည်။ ဒေတာ ကက်ရှ် နှစ်ခုလုံးကို အသုံးပြုသည် (ပက်ကေ့ခ်ျများကို “vectors” တွင် လုပ်ဆောင်သည်၊ ဒေတာသည် တစ်ခုနှင့်တစ်ခု နီးကပ်နေသည်) နှင့် ညွှန်ကြားချက် ကက်ရှ်များ- VPP တွင်၊ packet processing သည် ဂရပ်တစ်ခုကို လိုက်နာသည်၊ ၎င်းသည် တူညီသော လုပ်ငန်းဆောင်တာများ ပါဝင်သော node များဖြစ်သည်။

ဥပမာအားဖြင့်၊ VPP ရှိ IP ပက်ကေ့ခ်ျများကို စီမံဆောင်ရွက်ခြင်းသည် အောက်ပါအစီအစဥ်အတိုင်း ဖြစ်ပေါ်သည်- ပထမဦးစွာ၊ ပက်ကေ့ချ်ခေါင်းစီးများကို ခွဲခြမ်းစိတ်ဖြာခြင်း node တွင် ခွဲခြမ်းစိတ်ဖြာပြီးနောက် ၎င်းတို့အား လမ်းကြောင်းဇယားများအတိုင်း ထပ်ဆင့်ပေးပို့သော ပက်ကေ့ဂျ်များဆီသို့ ပေးပို့သည်။

နည်းနည်း ခက်ထန်တယ်။ VPP ၏စာရေးဆရာများသည် ပရိုဆက်ဆာ ကက်ရှ်များအသုံးပြုရာတွင် အပေးအယူလုပ်ခြင်းကို သည်းမခံနိုင်သောကြောင့် packets တစ်ခု၏ vector တစ်ခုလုပ်ဆောင်ရန်အတွက် ပုံမှန် code တွင် manual vectorization ပါရှိသည်- "ကျွန်တော်တို့တွင် packets လေးခုရှိသည်" ကဲ့သို့သော အခြေအနေမျိုးကို လုပ်ဆောင်နေသည့် လုပ်ငန်းစဉ် loop တစ်ခုရှိပါသည်။ နှစ်ခုအတွက် အတူတူ၊ ထို့နောက် တစ်ခုအတွက် ဖြစ်သည်။ နောက်ဆက်တွဲ ထပ်မံပြုလုပ်မှုများတွင် ၎င်းတို့ထံဝင်ရောက်ခွင့်ကို အရှိန်မြှင့်ရန် ဒေတာကို ကက်ရှ်များထဲသို့ တင်ရန် ကြိုတင်မှာယူရန် ညွှန်ကြားချက်များကို မကြာခဏ အသုံးပြုပါသည်။

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);
}

ထို့ကြောင့်၊ Healthchecks သည် IPv6 ကို VPP သို့ပြောပြီး ၎င်းတို့ကို IPv4 အဖြစ် ပြောင်းလဲပေးသည်။ ၎င်းကို ကျွန်ုပ်တို့ algorithmic NAT ဟုခေါ်သော ဂရပ်ရှိ node တစ်ခုဖြင့် လုပ်ဆောင်သည်။ ပြောင်းပြန်အသွားအလာအတွက် (IPv6 မှ IPv4 သို့ ပြောင်းလဲခြင်း) အတွက် တူညီသော algorithmic NAT node ရှိသည်။

ဟန်ချက်ညီသော ဖောက်သည်များထံမှ တိုက်ရိုက်အသွားအလာသည် ဟန်ချက်ညီမှုကို ကိုယ်တိုင်လုပ်ဆောင်ပေးသည့် ဂရပ်အမှတ်များမှတစ်ဆင့် ဖြတ်သန်းသွားပါသည်။ 

ပထမဆုံး node သည် sticky sessions ဖြစ်သည်။ ၎င်းသည် hash ကိုသိမ်းဆည်းထားသည်။ 5-tuple သတ်မှတ်အစည်းအဝေးများအတွက်။ 5-tuple တွင် အချက်အလက် ပို့လွှတ်သည့် client ၏ လိပ်စာနှင့် ဆိပ်ကမ်း၊ လမ်းကြောင်း လက်ခံရရှိရန် ရရှိနိုင်သော အရင်းအမြစ်များ၏ လိပ်စာနှင့် ဆိပ်ကမ်းများ နှင့် ကွန်ရက် ပရိုတိုကောတို့ ပါဝင်သည်။ 

5-tuple hash သည် ကျွန်ုပ်တို့အား နောက်ဆက်တွဲ တသမတ်တည်း hashing node တွင် တွက်ချက်မှု နည်းပါးစေပြီး Balancer ၏ နောက်ကွယ်ရှိ အရင်းအမြစ်စာရင်းပြောင်းလဲမှုများကို ပိုမိုကောင်းမွန်စွာ ကိုင်တွယ်ရန် ကူညီပေးပါသည်။ ဆက်ရှင်မရှိသော ပက်ကတ်တစ်ခုသည် balancer သို့ရောက်ရှိသောအခါ၊ ၎င်းကို ကိုက်ညီသော hashing node သို့ ပေးပို့သည်။ ဤနေရာတွင် တသမတ်တည်း ကိန်းအောင်းခြင်းကို အသုံးပြု၍ ဟန်ချက်ညီမှု ဖြစ်ပေါ်သည်- ကျွန်ုပ်တို့သည် ရရှိနိုင်သော "တိုက်ရိုက်" အရင်းအမြစ်များစာရင်းမှ အရင်းအမြစ်တစ်ခုကို ရွေးချယ်ပါသည်။ ထို့နောက်၊ packets များကို NAT node သို့ပို့ပြီး၊ အမှန်တကယ် destination address ကိုအစားထိုးပြီး checksums များကိုပြန်လည်တွက်ချက်ပေးပါသည်။ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ကျွန်ုပ်တို့သည် ပရိုဆက်ဆာ ကက်ရှ်များ၏ စွမ်းဆောင်ရည်ကို တိုးမြင့်လာစေရန် ကျွန်ုပ်တို့သည် အလားတူ တွက်ချက်မှုများကို အုပ်စုဖွဲ့ကာ VPP ၏ စည်းမျဉ်းများကို လိုက်နာပါသည်။

တသမတ်တည်း တားဆီးခြင်း

ငါတို့ဘာကြောင့်ရွေးချယ်ခဲ့တာလဲ၊ အဲဒါကဘာလဲ။ ဦးစွာ၊ စာရင်းထဲမှ အရင်းအမြစ်ကို ရွေးချယ်ခြင်းတွင် ယခင်လုပ်ဆောင်ရမည့်တာဝန်ကို စဉ်းစားကြည့်ကြပါစို့။ 

မကိုက်ညီသော hashing ဖြင့်၊ အဝင်ပက်ကတ်၏ hash ကို တွက်ချက်ပြီး ကျန်ရှိသော hash ကို အရင်းအမြစ်အရေအတွက်ဖြင့် ပိုင်းခြားခြင်းဖြင့် စာရင်းထဲမှ အရင်းအမြစ်တစ်ခုကို ရွေးချယ်ပါသည်။ စာရင်းမပြောင်းလဲသရွေ့၊ ဤအစီအစဥ်သည် ကောင်းမွန်စွာအလုပ်လုပ်သည်- ကျွန်ုပ်တို့သည် တူညီသော 5-tuple ပါသည့် packets များကို တူညီသောဥပမာတစ်ခုဆီသို့ အမြဲပို့ပေးပါသည်။ ဥပမာအားဖြင့်၊ အချို့သောအရင်းအမြစ်များသည် ကျန်းမာရေးစစ်ဆေးမှုများကို တုံ့ပြန်မှုရပ်သွားပါက၊ ထို့နောက် hashes ၏ သိသာထင်ရှားသောအစိတ်အပိုင်းတစ်ခုအတွက် ရွေးချယ်မှုသည် ပြောင်းလဲသွားမည်ဖြစ်သည်။ ကလိုင်းယင့်၏ TCP ချိတ်ဆက်မှုများ ပျက်သွားလိမ့်မည်- ယခင်က instance A သို့ရောက်ရှိခဲ့သော packet တစ်ခုသည် ဤပက်ကတ်အတွက် session နှင့် မရင်းနှီးသော instance B သို့ စတင်ရောက်ရှိနိုင်သည်။

တသမတ်တည်း တားဆီးခြင်းသည် ဖော်ပြထားသော ပြဿနာကို ဖြေရှင်းပေးသည်။ ဤသဘောတရားကို ရှင်းပြရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ ဤအရာဖြစ်သည်- သင့်တွင် အရင်းအမြစ်များကို hash ဖြင့် ဖြန့်ဝေပေးမည့် လက်စွပ်တစ်ကွင်းရှိသည် (ဥပမာ၊ IP:port ဖြင့်)။ အရင်းအမြစ်တစ်ခုကို ရွေးချယ်ခြင်းသည် ပက်ကတ်၏ hash ဖြင့် ဆုံးဖြတ်သည့် ထောင့်တစ်ခုဖြင့် ဘီးကို လှည့်ခြင်းဖြစ်သည်။

၎င်းသည် အရင်းအမြစ်များ၏ဖွဲ့စည်းမှုပြောင်းလဲသောအခါ အသွားအလာပြန်လည်ဖြန့်ဝေမှုကို လျှော့ချပေးသည်။ အရင်းအမြစ်တစ်ခုအား ဖျက်ခြင်းသည် အရင်းအမြစ်တည်ရှိသည့် တသမတ်တည်း ဟက်ခ်လုပ်ခြင်း၏ အစိတ်အပိုင်းကိုသာ အကျိုးသက်ရောက်စေမည်ဖြစ်သည်။ ရင်းမြစ်တစ်ခုထည့်ခြင်းသည် ဖြန့်ဖြူးမှုကိုလည်း ပြောင်းလဲစေသည်၊ သို့သော် ကျွန်ုပ်တို့တွင် သတ်မှတ်ထားပြီးသား sessions များကို အရင်းအမြစ်အသစ်များသို့ ပြောင်းခြင်းမပြုနိုင်သည့် ကပ်စေးသည့် session node တစ်ခုရှိသည်။

Balancer နှင့် အရင်းအမြစ်များကြား တိုက်ရိုက်လမ်းကြောင်း ဖြစ်ပျက်မှုကို ကျွန်ုပ်တို့ ကြည့်ရှုခဲ့ပါသည်။ အခုပြန်သွားတဲ့လမ်းကြောင်းကို ကြည့်ရအောင်။ ၎င်းသည် စစ်ဆေးခြင်းအသွားအလာကဲ့သို့တူညီသောပုံစံအတိုင်းလုပ်ဆောင်သည် - algorithmic NAT မှတဆင့်၊ ဆိုလိုသည်မှာ၊ ဖောက်သည်အသွားအလာအတွက် NAT 44 မှတဆင့်နှင့် ကျန်းမာရေးစစ်ဆေးမှုများအတွက် NAT 46 မှတဆင့်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်အစီအစဥ်ကို လိုက်နာပါသည်- ကျွန်ုပ်တို့သည် ကျန်းမာရေးစစ်ဆေးမှုအသွားအလာနှင့် အမှန်တကယ်အသုံးပြုသူအသွားအလာတို့ကို ပေါင်းစပ်ထားသည်။

Loadbalancer-node နှင့် တပ်ဆင်ထားသော အစိတ်အပိုင်းများ

VPP ရှိ ချိန်ခွင်လျှာနှင့် အရင်းအမြစ်များ၏ ပေါင်းစပ်ဖွဲ့စည်းမှုကို ပြည်တွင်းဝန်ဆောင်မှု - loadbalancer-node မှ အစီရင်ခံပါသည်။ ၎င်းသည် loadbalancer-controller မှဖြစ်ရပ်များ၏စီးကြောင်းတွင်စာရင်းသွင်းထားပြီးလက်ရှိ VPP အခြေအနေနှင့် controller မှရရှိသည့်ပစ်မှတ်အခြေအနေအကြားခြားနားချက်ကိုကြံစည်နိုင်သည်။ ကျွန်ုပ်တို့သည် အပိတ်စနစ်တစ်ခုကို ရရှိပါသည်- API မှ ဖြစ်ရပ်များသည် အရင်းအမြစ်များ၏ "ရှင်သန်မှု" ကိုစစ်ဆေးရန် ကျန်းမာရေးစစ်ဆေးမှု ထိန်းချုပ်သူထံ အလုပ်များကို တာဝန်ပေးသည့် ချိန်ခွင်လျှာထိန်းကိရိယာသို့ ရောက်ရှိလာပါသည်။ ၎င်းသည် တစ်ဖန်၊ ၎င်းသည် ကျန်းမာရေးစစ်ဆေးမှု- node တွင် လုပ်ဆောင်စရာများကို တာဝန်ပေးအပ်ပြီး ရလဒ်များကို ပေါင်းစပ်ပြီးနောက် ၎င်းတို့အား balancer controller သို့ ပြန်လည်ပေးပို့သည်။ Loadbalancer-node သည် ထိန်းချုပ်ကိရိယာမှ အဖြစ်အပျက်များကို စာရင်းသွင်းပြီး VPP ၏ အခြေအနေကို ပြောင်းလဲသည်။ ထိုသို့သောစနစ်တွင်၊ ဝန်ဆောင်မှုတစ်ခုစီသည် အိမ်နီးချင်းဝန်ဆောင်မှုများနှင့်ပတ်သက်ပြီး လိုအပ်သည်များကိုသာ သိသည်။ ချိတ်ဆက်မှု အရေအတွက် ကန့်သတ်ထားပြီး ကျွန်ုပ်တို့တွင် မတူညီသော အပိုင်းများကို လွတ်လပ်စွာ လည်ပတ်နိုင်ပြီး အတိုင်းအတာကို လုပ်ဆောင်နိုင်စွမ်းရှိပါသည်။

မည်သည့်ပြဿနာများကို ရှောင်ရှားခဲ့သနည်း။

ထိန်းချုပ်ရေးလေယာဉ်ရှိ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုအားလုံးကို Go တွင် ရေးသားထားပြီး ကောင်းမွန်သောအတိုင်းအတာနှင့် ယုံကြည်စိတ်ချရမှုလက္ခဏာများရှိသည်။ Go တွင် ဖြန့်ဝေမှုစနစ်များတည်ဆောက်ရန်အတွက် open source စာကြည့်တိုက်များစွာရှိသည်။ ကျွန်ုပ်တို့သည် GRPC ကိုတက်ကြွစွာအသုံးပြုပါသည်၊ အစိတ်အပိုင်းအားလုံးတွင် ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှု၏ open source အကောင်အထည်ဖော်မှုတစ်ခုပါရှိသည် - ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများသည် တစ်ခုနှင့်တစ်ခု၏စွမ်းဆောင်ရည်ကိုစောင့်ကြည့်ခြင်း၊ ၎င်းတို့၏ဖွဲ့စည်းပုံကို dynamically ပြောင်းလဲနိုင်ပြီး ၎င်းကို GRPC ချိန်ခွင်လျှာညှိခြင်းနှင့် ချိတ်ဆက်ထားပါသည်။ မက်ထရစ်များအတွက်၊ ကျွန်ုပ်တို့သည် open source ဖြေရှင်းချက်ကိုလည်း အသုံးပြုပါသည်။ ဒေတာလေယာဉ်တွင်၊ ကျွန်ုပ်တို့သည် သင့်တင့်လျောက်ပတ်သောစွမ်းဆောင်ရည်နှင့် ကြီးမားသောအရင်းအမြစ်အရန်အရံများကို ရရှိပါသည်- သံကွန်ရက်ကတ်ထက် ကျွန်ုပ်တို့ VPP ၏စွမ်းဆောင်ရည်အပေါ် အားကိုးနိုင်သည့်ရပ်တည်ချက်ကို စုစည်းရန် အလွန်ခက်ခဲသွားပါသည်။

ပြဿနာများနှင့် ဖြေရှင်းချက်များ

ဘာက ဒီလောက် အဆင်မပြေဘူးလဲ။ Go တွင် အလိုအလျောက် မမ်မိုရီစီမံခန့်ခွဲမှု၊ သို့သော် မမ်မိုရီယိုစိမ့်မှုများ ဖြစ်ပေါ်နေဆဲဖြစ်သည်။ ၎င်းတို့ကို ကိုင်တွယ်ရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ gooutines များကို လုပ်ဆောင်ပြီး ၎င်းတို့ကို အဆုံးသတ်ရန် သတိရပါ။ Takeaway- သင်၏ Go ပရိုဂရမ်များ၏ မှတ်ဉာဏ်သုံးစွဲမှုကို ကြည့်ပါ။ မကြာခဏဆိုသလို ကောင်းသောညွှန်ပြချက်မှာ ဂေါ်ရီရိုးတင်း အရေအတွက်ဖြစ်သည်။ ဤဇာတ်လမ်းတွင် အားသာချက်တစ်ခုရှိသည်- Go တွင် ၎င်းသည် runtime ဒေတာကိုရရန် လွယ်ကူသည် - မှတ်ဉာဏ်သုံးစွဲမှု၊ လည်ပတ်နေပုံနည်းလမ်းအရေအတွက်နှင့် အခြားကန့်သတ်ချက်များများစွာရှိသည်။

ထို့အပြင် Go သည် လုပ်ဆောင်ချက်ဆိုင်ရာ စမ်းသပ်မှုများအတွက် အကောင်းဆုံးရွေးချယ်မှုလည်း ဖြစ်နိုင်သည်။ ၎င်းတို့သည် စကားလုံးအသုံးအနှုန်းများပြီး "CI တွင် အရာအားလုံးကို အသုတ်လိုက်လုပ်ဆောင်ခြင်း" ၏ စံချဉ်းကပ်ပုံသည် ၎င်းတို့အတွက် အလွန်သင့်လျော်ခြင်းမရှိပေ။ အမှန်မှာ functional tests များသည် အရင်းအမြစ်-တောင်းဆိုမှုများ ပိုမိုများပြားပြီး အမှန်တကယ် အချိန်ကုန်သွားခြင်းကြောင့်ဖြစ်သည်။ ထို့အတွက်ကြောင့် CPU သည် ယူနစ်စမ်းသပ်မှုများနှင့် အလုပ်ရှုပ်နေသောကြောင့် စမ်းသပ်မှုများ မအောင်မြင်နိုင်ပါ။ နိဂုံးချုပ်- ဖြစ်နိုင်ပါက ယူနစ်စမ်းသပ်မှုများမှ သီးခြား "လေးလံသော" စမ်းသပ်မှုများကို လုပ်ဆောင်ပါ။ 

Microservice event architecture သည် monolith ထက် ပိုရှုပ်ထွေးသည်- များစွာသော စက်များတွင် မှတ်တမ်းများ စုဆောင်းခြင်းသည် အဆင်မပြေပါ။ နိဂုံး- သင်သည် မိုက်ခရိုဝန်ဆောင်မှုများ ပြုလုပ်ပါက ခြေရာခံခြင်းအကြောင်း ချက်ချင်းစဉ်းစားပါ။

ကျွန်ုပ်တို့၏အစီအစဉ်များ

ကျွန်ုပ်တို့သည် အတွင်းပိုင်းချိန်ခွင်လျှာ၊ IPv6 ချိန်ခွင်လျှာအတွက်၊ Kubernetes scripts များအတွက် ပံ့ပိုးမှုပေါင်းထည့်ရန်၊ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများကို ဆက်လက်ခွဲခြမ်းရန် (လောလောဆယ်တွင် healthcheck-node နှင့် healthcheck-ctrl များကိုသာ ဖျက်ထားသည်)၊ ကျန်းမာရေးစစ်ဆေးမှုအသစ်များကို ထည့်သွင်းပြီး စမတ်စစ်ဆေးမှုများ ပေါင်းစည်းမှုကိုလည်း အကောင်အထည်ဖော်ပါမည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများကို ပို၍လွတ်လပ်စေရန်အတွက် ဖြစ်နိုင်ခြေကို စဉ်းစားနေပါသည် - ထို့ကြောင့် ၎င်းတို့သည် တစ်ဦးနှင့်တစ်ဦး တိုက်ရိုက်မဆက်သွယ်ဘဲ မက်ဆေ့ချ်တန်းစီခြင်းကို အသုံးပြုပါသည်။ SQS-သဟဇာတဖြစ်သောဝန်ဆောင်မှုသည် မကြာသေးမီက Cloud တွင်ပေါ်လာသည်။ Yandex မက်ဆေ့ခ်ျတန်းစီ.

မကြာသေးမီက Yandex Load Balancer ကိုအများပြည်သူဖြန့်ချိခဲ့သည်။ စူးစမ်းပါ။ စာရွက်စာတမ်း ဝန်ဆောင်မှုအတွက်၊ သင့်အတွက် အဆင်ပြေသောနည်းဖြင့် ချိန်ခွင်လျှာများကို စီမံခန့်ခွဲပြီး သင့်ပရောဂျက်များ၏ အမှားအယွင်းများကို ခံနိုင်ရည်ရှိအောင် တိုးမြှင့်ပါ။

source: www.habr.com