Mail.ru Cloud Solutions ပလပ်ဖောင်းတွင် အမှားအယွင်းခံနိုင်သော ဝဘ်ဗိသုကာကို မည်ကဲ့သို့ လုပ်ဆောင်ထားသည်။

မင်္ဂလာပါ Habr။ ကျွန်ုပ်သည် စနစ်စီမံခန့်ခွဲမှုအဖွဲ့၏ အကြီးအကဲ Artem Karamyshev ဖြစ်သည်။ Mail.Ru Cloud Solutions (MCS). ကျွန်ုပ်တို့သည် ပြီးခဲ့သောနှစ်တွင် ထုတ်ကုန်အသစ်များစွာကို မိတ်ဆက်ခဲ့သည်။ API ဝန်ဆောင်မှုများသည် အလွယ်တကူ အတိုင်းအတာ၊ အမှားအယွင်းခံနိုင်ရည်ရှိပြီး သုံးစွဲသူဝန်ဆောင်မှုတွင် လျင်မြန်စွာ တိုးတက်မှုအတွက် အဆင်သင့်ဖြစ်နေကြောင်း သေချာစေလိုပါသည်။ ကျွန်ုပ်တို့၏ပလပ်ဖောင်းကို OpenStack တွင်အကောင်အထည်ဖော်ထားပြီး၊ အမှား-ခံနိုင်ရည်ရှိသောစနစ်တစ်ခုရရှိရန် ကျွန်ုပ်တို့ဖြေရှင်းရမည့် အစိတ်အပိုင်းအမှားအယွင်းပြဿနာများကို ကျွန်ုပ်ပြောပြလိုပါသည်။ OpenStack တွင် ထုတ်ကုန်များကို တီထွင်နေသူများအတွက် ၎င်းသည် စိတ်ဝင်စားဖွယ်ကောင်းမည်ဟု ထင်ပါတယ်။

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

ဤဇာတ်လမ်း၏ ဗီဒီယိုဗားရှင်း၊ အဓိကအရင်းအမြစ်ဖြစ်သော Uptime day 4 ကွန်ဖရင့်တွင် အစီရင်ခံစာတစ်ခုဖြစ်သည်။ ITSummaသင်မြင်နိုင်သည်။ Uptime Community YouTube ချန်နယ်တွင်.

ရုပ်ပိုင်းဆိုင်ရာဗိသုကာ၏ခံနိုင်ရည်

MCS cloud ၏ အများသူငှာ အစိတ်အပိုင်းသည် ယခုအခါ Tier III ဒေတာစင်တာနှစ်ခုတွင် အခြေစိုက်ထားပြီး ၎င်းတို့အကြားတွင် ၎င်း၏ကိုယ်ပိုင် မှောင်မိုက်သောဖိုင်ဘာများ ရှိပြီး မတူညီသောလမ်းကြောင်းများဖြင့် သီးသန့်ထားရှိကာ 200 Gbit/s နှုန်းဖြင့် ရုပ်ပိုင်းဆိုင်ရာအဆင့်တွင် သိမ်းဆည်းထားသည်။ အဆင့် III သည် ရုပ်ပိုင်းဆိုင်ရာ အခြေခံအဆောက်အအုံအတွက် လိုအပ်သော အမှားအယွင်းများကို သည်းခံနိုင်မှုအဆင့်ကို ပေးဆောင်သည်။

အမှောင်ဖိုက်ဘာကို ရုပ်ပိုင်းဆိုင်ရာနှင့် ယုတ္တိအဆင့် နှစ်ခုစလုံးတွင် သိမ်းဆည်းထားသည်။ ချန်နယ်ကြိုတင်မှာယူခြင်းလုပ်ငန်းစဉ်သည် ထပ်ခါတလဲလဲဖြစ်ပြီး ပြဿနာများပေါ်ပေါက်လာကာ ဒေတာစင်တာများကြား ဆက်သွယ်ရေးကို အဆက်မပြတ်တိုးတက်စေပါသည်။

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

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

ဝန်ဆောင်မှုပေးသူ အဆင်မပြေပါက၊ ကျွန်ုပ်တို့သည် နောက်တစ်ခုသို့ အလိုအလျောက်ပြောင်းပါသည်။ ဒေတာစင်တာတစ်ခုမှ ပျက်ကွက်ပါက၊ ကျွန်ုပ်တို့တွင် ဝန်ဆောင်ခတစ်ခုလုံးကို ယူဆောင်သည့် ဒုတိယဒေတာစင်တာရှိ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများ၏ မှန်မိတ္တူတစ်ခုရှိသည်။

ရုပ်ပိုင်းဆိုင်ရာအခြေခံအဆောက်အဦများ၏ခံနိုင်ရည်

အပလီကေးရှင်းအဆင့် အမှားခံနိုင်ရည်အတွက် ကျွန်ုပ်တို့အသုံးပြုသည့်အရာ

ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုသည် opensource အစိတ်အပိုင်းများစွာပေါ်တွင် တည်ဆောက်ထားသည်။

ExaBGP BGP-based dynamic routing protocol ကို အသုံးပြု၍ လုပ်ဆောင်ချက်အများအပြားကို အကောင်အထည်ဖော်သည့် ဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ အသုံးပြုသူများ API ကိုဝင်ရောက်ကြည့်ရှုသည့်မှတစ်ဆင့် ကျွန်ုပ်တို့၏ခွင့်ပြုထားသောစာရင်းဝင် IP လိပ်စာများကိုကြော်ငြာရန် ၎င်းကိုတက်ကြွစွာအသုံးပြုပါသည်။

HAProxy OSI မော်ဒယ်၏ မတူညီသောအဆင့်များတွင် အလွန်ပြောင်းလွယ်ပြင်လွယ် အသွားအလာ ချိန်ခွင်လျှာညှိခြင်း စည်းမျဉ်းများကို ပြင်ဆင်သတ်မှတ်နိုင်စေမည့် high-load balancer တစ်ခုဖြစ်သည်။ ဒေတာဘေ့စ်များ၊ မက်ဆေ့ချ်ပွဲစားများ၊ API ဝန်ဆောင်မှုများ၊ ဝဘ်ဝန်ဆောင်မှုများ၊ ကျွန်ုပ်တို့၏ပြည်တွင်းရေးပရောဂျက်များ - အရာအားလုံးသည် HAProxy ၏နောက်ကွယ်တွင် ရှိနေပါသည်။

API အပလီကေးရှင်း — သုံးစွဲသူသည် ၎င်း၏ အခြေခံအဆောက်အအုံနှင့် ၎င်း၏ဝန်ဆောင်မှုကို စီမံခန့်ခွဲသည့် python ဖြင့် ရေးသားထားသော ဝဘ်အက်ပလီကေးရှင်းတစ်ခုဖြစ်သည်။

အလုပ်သမားလျှောက်လွှာ (ယနေ့မှစ၍ ရိုးရိုးအလုပ်သမား) - OpenStack ဝန်ဆောင်မှုများတွင်၊ ၎င်းသည် အခြေခံအဆောက်အဦသို့ API ညွှန်ကြားချက်များကို ထုတ်လွှင့်ခွင့်ပြုသည့် အခြေခံအဆောက်အဦ daemon တစ်ခုဖြစ်သည်။ ဥပမာအားဖြင့်၊ ဒစ်ခ်ဖန်တီးမှုသည် အလုပ်သမား၌ ဖြစ်ပေါ်ပြီး ဖန်တီးမှုတောင်းဆိုမှုသည် အပလီကေးရှင်း API တွင် ဖြစ်ပေါ်သည်။

Standard OpenStack Application Architecture

OpenStack အတွက် တီထွင်ထားသော ဝန်ဆောင်မှုအများစုသည် တစ်ခုတည်းသော ပါရာဒိုင်းကို လိုက်နာရန် ကြိုးစားကြသည်။ ဝန်ဆောင်မှုတစ်ခုတွင် အများအားဖြင့် အပိုင်း ၂ ပိုင်းပါဝင်သည်- API နှင့် အလုပ်သမားများ (backend executors)။ စည်းကမ်းအတိုင်း၊ API တစ်ခုသည် သီးခြားလုပ်ဆောင်မှု (daemon) အဖြစ် သို့မဟုတ် အဆင်သင့်လုပ်ထားသည့် Nginx သို့မဟုတ် Apache ဝဘ်ဆာဗာကို အသုံးပြုထားသည့် python တွင် WSGI အပလီကေးရှင်းတစ်ခုဖြစ်သည်။ API သည် အသုံးပြုသူတောင်းဆိုမှုကို လုပ်ဆောင်ပြီး အကောင်အထည်ဖော်ရန်အတွက် အလုပ်သမားအပလီကေးရှင်းသို့ နောက်ထပ်ညွှန်ကြားချက်များကို ပေးပို့သည်။ ပုံမှန်အားဖြင့် RabbitMQ သည် မက်ဆေ့ချ်ပွဲစားကို အသုံးပြု၍ လွှဲပြောင်းခြင်းသည် အခြားအရာများကို ညံ့ဖျင်းစွာ ဆောင်ရွက်ပေးပါသည်။ မက်ဆေ့ဂျ်များ ပွဲစားထံရောက်ရှိသောအခါ၊ ၎င်းတို့ကို အလုပ်သမားများက လုပ်ဆောင်ပြီး လိုအပ်ပါက တုံ့ပြန်ချက်ပြန်ပေးသည်။

ဤပါရာဒိုင်းတွင် ကျရှုံးမှု၏ သီးခြားဘုံအချက်များ ပါဝင်သည်- RabbitMQ နှင့် ဒေတာဘေ့စ်။ သို့သော် RabbitMQ သည် ဝန်ဆောင်မှုတစ်ခုအတွင်း သီးခြားခွဲထားပြီး သီအိုရီအရ ဝန်ဆောင်မှုတစ်ခုစီအတွက် တစ်ဦးချင်းဖြစ်နိုင်သည်။ ထို့ကြောင့် MCS တွင် ကျွန်ုပ်တို့သည် ဤဝန်ဆောင်မှုများကို တတ်နိုင်သမျှ ခွဲခြားထားပါသည်၊ ပရောဂျက်တစ်ခုစီအတွက် သီးခြားဒေတာဘေ့စ်တစ်ခု၊ သီးခြား RabbitMQ ကို ကျွန်ုပ်တို့ ဖန်တီးပါသည်။ အားနည်းချက်အချို့တွင် မတော်တဆမှုတစ်ခုဖြစ်ပွားသောအခါ ဝန်ဆောင်မှုတစ်ခုလုံး ပြိုပျက်သွားခြင်းမဟုတ်ဘဲ ၎င်း၏အစိတ်အပိုင်းတစ်ခုသာဖြစ်သောကြောင့် ဤချဉ်းကပ်မှုသည် ကောင်းမွန်ပါသည်။

လုပ်သားအပလီကေးရှင်းများ၏ အရေအတွက်မှာ အကန့်အသတ်မရှိသောကြောင့် API သည် စွမ်းဆောင်ရည်နှင့် အမှားခံနိုင်ရည်ကို တိုးမြှင့်ရန်အတွက် ချိန်ခွင်လျှာများနောက်တွင် အလျားလိုက် အလျားလိုက် အလွယ်တကူ အတိုင်းအတာကို ချိန်ညှိနိုင်သည်။

APIs များနှင့် အလုပ်သမားများအကြား ရှုပ်ထွေးသော ဆင့်ကဲလုပ်ဆောင်မှုများ ဖြစ်ပေါ်လာသောအခါ အချို့ဝန်ဆောင်မှုများသည် ဝန်ဆောင်မှုအတွင်း ပေါင်းစပ်ညှိနှိုင်းမှု လိုအပ်ပါသည်။ ဤကိစ္စတွင်၊ တစ်ခုတည်းသောညှိနှိုင်းရေးစင်တာ၊ Redis၊ Memcache၊ etcd ကဲ့သို့သော အစုလိုက်အပြုံလိုက်စနစ်အား အသုံးပြုပြီး အလုပ်သမားတစ်ဦးမှ ဤတာဝန်ကို ပေးအပ်ထားကြောင်း အခြားသူတစ်ဦးအား ပြောခွင့်ပြုသည် ("ကျေးဇူးပြု၍ မယူပါနှင့်")။ ငါတို့က etcd ကိုသုံးတယ်။ စည်းကမ်းအတိုင်း၊ အလုပ်သမားများသည် ဒေတာဘေ့စ်နှင့် တက်ကြွစွာ ဆက်သွယ်ပြောဆိုကြပြီး ထိုနေရာမှ အချက်အလက်များကို ရေးသားဖတ်ကြသည်။ ကျွန်ုပ်တို့သည် multimaster အစုအဝေးတွင်တည်ရှိသော ဒေတာဘေ့စ်အဖြစ် mariadb ကို အသုံးပြုပါသည်။

ဤဂန္ထဝင်တစ်ခုတည်းဝန်ဆောင်မှုကို OpenStack အတွက် ယေဘူယျလက်ခံသည့်ပုံစံဖြင့် ဖွဲ့စည်းထားသည်။ ၎င်းကို အတိုင်းအတာနှင့် အမှားခံနိုင်ရည်ရှိမှု နည်းလမ်းများသည် အလွန်ထင်ရှားသည့် အပိတ်စနစ်တစ်ခုအဖြစ် ယူဆနိုင်သည်။ ဥပမာအားဖြင့်၊ API အမှားခံနိုင်ရည်အတွက်၊ ချိန်ခွင်လျှာကို ၎င်းတို့ရှေ့တွင်ထားရန် လုံလောက်သည်။ လုပ်သားအရေအတွက်ကို တိုးမြှင့်ခြင်းဖြင့် အောင်မြင်သည်။

အစီအစဉ်တစ်ခုလုံး၏အားနည်းချက်မှာ RabbitMQ နှင့် MariaDB ဖြစ်သည်။ ၎င်းတို့၏ ဗိသုကာလက်ရာများသည် သီးခြားဆောင်းပါးတစ်ပုဒ်နှင့် ထိုက်တန်ပါသည်။ ဤဆောင်းပါးတွင် API အမှားခံနိုင်ရည်ကို အာရုံစိုက်လိုပါသည်။

Openstack လျှောက်လွှာဗိသုကာ။ cloud ပလပ်ဖောင်း၏ ဟန်ချက်ညီမှုနှင့် အမှားအယွင်းများကို သည်းခံနိုင်မှု

ExaBGP ကို ​​အသုံးပြု၍ HAProxy balancer အမှား-ခံနိုင်ရည်ရှိအောင် ပြုလုပ်ခြင်း။

ကျွန်ုပ်တို့၏ APIs များကို အရွယ်အစား၊ မြန်ဆန်ပြီး အမှားအယွင်းခံနိုင်စေရန်အတွက်၊ ၎င်းတို့ရှေ့တွင် load balancer ကို ထားရှိပါသည်။ ကျွန်ုပ်တို့သည် HAProxy ကိုရွေးချယ်ခဲ့သည်။ ကျွန်ုပ်၏အမြင်အရ၊ ၎င်းတွင်ကျွန်ုပ်တို့၏လုပ်ငန်းတာဝန်အတွက်လိုအပ်သောဝိသေသလက္ခဏာများရှိသည်- များစွာသော OSI အဆင့်များတွင် ဟန်ချက်ညီခြင်း၊ စီမံခန့်ခွဲမှုအင်တာဖေ့စ်၊ ပြောင်းလွယ်ပြင်လွယ်နှင့် အတိုင်းအတာ၊ ဟန်ချက်ညီသောနည်းလမ်းများစွာ၊ session tables အတွက်ပံ့ပိုးမှု။

ပထမဆုံးဖြေရှင်းရန် လိုအပ်သောပြဿနာမှာ balancer ကိုယ်တိုင်၏ အမှားကို သည်းခံနိုင်မှုပင်ဖြစ်သည်။ ချိန်ခွင်လျှာကို တပ်ဆင်ရုံဖြင့် ပျက်ကွက်သည့်အချက်ကို ဖန်တီးပေးသည်- ချိန်ခွင်လျှာ ဖြတ်တောက်ပြီး ဝန်ဆောင်မှု ပျက်သွားသည်။ ဒီလိုမဖြစ်အောင် ကျွန်တော်တို့ HAProxy ကို ExaBGP နဲ့တွဲသုံးပါတယ်။

ExaBGP သည် သင့်အား ဝန်ဆောင်မှုတစ်ခု၏ အခြေအနေကို စစ်ဆေးရန်အတွက် ယန္တရားတစ်ခုကို အကောင်အထည်ဖော်ရန် ခွင့်ပြုသည်။ ကျွန်ုပ်တို့သည် HAProxy ၏လုပ်ဆောင်နိုင်စွမ်းကိုစစ်ဆေးရန် ဤယန္တရားကိုအသုံးပြုပြီး ပြဿနာများရှိပါက BGP မှ HAProxy ဝန်ဆောင်မှုကို ပိတ်ပါ။

ExaBGP+HAProxy အစီအစဉ်

1. ကျွန်ုပ်တို့သည် လိုအပ်သောဆော့ဖ်ဝဲလ်ဖြစ်သည့် ExaBGP နှင့် HAProxy ကို ဆာဗာသုံးခုတွင် ထည့်သွင်းပါသည်။
2. ကျွန်ုပ်တို့သည် ဆာဗာတစ်ခုစီတွင် loopback interface တစ်ခုကို ဖန်တီးသည်။
3. ဆာဗာသုံးခုလုံးတွင် ကျွန်ုပ်တို့သည် တူညီသောအဖြူရောင် IP လိပ်စာကို ဤအင်တာဖေ့စ်အတွက် သတ်မှတ်ပေးသည်။
4. အဖြူရောင် IP လိပ်စာကို ExaBGP မှတစ်ဆင့် အင်တာနက်သို့ ကြော်ငြာထားသည်။

ဆာဗာသုံးခုလုံးမှ တူညီသော IP လိပ်စာကို ကြော်ငြာခြင်းဖြင့် အမှားခံနိုင်ရည်ကို ရရှိသည်။ ကွန်ရက်ရှုထောင့်မှကြည့်လျှင် တူညီသောလိပ်စာသည် မတူညီသောနောက်ထပ်သုံးမျိုးမှ ဝင်ရောက်နိုင်သည်။ router သည် တူညီသောလမ်းကြောင်းသုံးခုကိုမြင်ရပြီး ၎င်း၏ကိုယ်ပိုင်မက်ထရစ်အပေါ်အခြေခံ၍ ၎င်းတို့အနက်မှ အမြင့်ဆုံးဦးစားပေးကိုရွေးချယ်သည် (ဤသည်မှာ အများအားဖြင့် တူညီသောရွေးချယ်မှုဖြစ်သည်)၊ လမ်းကြောင်းသည် ဆာဗာများထဲမှတစ်ခုသာဖြစ်သည်။

HAProxy ၏လည်ပတ်မှု သို့မဟုတ် ဆာဗာချို့ယွင်းမှုတွင် ပြဿနာများရှိသောအခါတွင် ExaBGP သည် လမ်းကြောင်းကို ကြေငြာခြင်းရပ်သွားပြီး လမ်းကြောင်းသည် အခြားဆာဗာသို့ ချောမွေ့စွာပြောင်းသွားပါသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် balancer ၏ အမှားခံနိုင်ရည်ကို ရရှိခဲ့ပါသည်။

HAProxy ချိန်ခွင်လျှာများ၏ အမှားအယွင်းများကို သည်းခံနိုင်မှု

အစီအစဥ်သည် မပြည့်စုံတော့သည်- ကျွန်ုပ်တို့သည် HAProxy ကို မည်သို့ကြိုတင်ထားရမည်ကို လေ့လာခဲ့သော်လည်း ဝန်ဆောင်မှုများအတွင်း ဝန်ကို မည်သို့ဖြန့်ဝေရမည်ကို မလေ့လာခဲ့ပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဤအစီအစဥ်ကို အနည်းငယ်ချဲ့ထွင်လိုက်သည်- ကျွန်ုပ်တို့သည် အဖြူရောင် IP လိပ်စာများစွာကြား ချိန်ခွင်လျှာကို ဆက်သွားခဲ့သည်။

DNS နှင့် BGP ကိုအခြေခံ၍ ဟန်ချက်ညီခြင်း။

ကျွန်ုပ်တို့၏ HAProxy အတွက် Load Balancing ပြဿနာကို မဖြေရှင်းနိုင်သေးပါ။ သို့သော်၊ ကျွန်ုပ်တို့ ဤနေရာတွင် လုပ်သကဲ့သို့၊ ၎င်းကို ရိုးရှင်းစွာ ဖြေရှင်းနိုင်သည်။

ဆာဗာသုံးခုကို ဟန်ချက်ညီစေရန် သင်သည် အဖြူရောင် IP လိပ်စာ ၃ ခုနှင့် ကောင်းသော DNS အဟောင်းများ လိုအပ်မည်ဖြစ်သည်။ ဤလိပ်စာတစ်ခုစီကို HAProxy တစ်ခုစီ၏ loopback interface တွင် ဆုံးဖြတ်ပြီး အင်တာနက်သို့ ကြော်ငြာထားသည်။

OpenStack တွင်၊ အရင်းအမြစ်များကို စီမံခန့်ခွဲရန်၊ ဝန်ဆောင်မှုတစ်ခု၏ endpoint API ကို သတ်မှတ်ပေးသည့် ဝန်ဆောင်မှုလမ်းညွှန်ကို အသုံးပြုပါသည်။ ဤလမ်းညွှန်တွင် ကျွန်ုပ်တို့သည် မတူညီသော IP လိပ်စာသုံးခုဖြင့် DNS မှတစ်ဆင့် ဖြေရှင်းသည့် ဒိုမိန်းအမည် - public.infra.mail.ru ကို မှတ်ပုံတင်ပါသည်။ ရလဒ်အနေဖြင့် DNS မှတစ်ဆင့် လိပ်စာသုံးခုကြားတွင် ဝန်ဖြန့်ဝေမှုကို ရရှိသည်။

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

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

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

DNS + BGP ကို ​​အခြေခံ၍ HAProxy ကို ချိန်ခွင်လျှာညှိခြင်း။

ExaBGP နှင့် HAProxy အကြား အပြန်အလှန်အကျိုးသက်ရောက်မှု

ထို့ကြောင့်၊ လမ်းကြောင်းများကြေငြာခြင်းကို ရပ်တန့်ခြင်းအပေါ် အခြေခံ၍ ဆာဗာမှထွက်ခွာသည့်အခါတွင် ကျွန်ုပ်တို့သည် အမှားအယွင်းခံနိုင်ရည်ရှိမှုကို အကောင်အထည်ဖော်ဆောင်ရွက်ခဲ့ပါသည်။ သို့သော် HAProxy သည် ဆာဗာချို့ယွင်းမှုမှလွဲ၍ အခြားအကြောင်းများကြောင့် ပိတ်နိုင်သည်- စီမံခန့်ခွဲမှုအမှားများ၊ ဝန်ဆောင်မှုအတွင်း ပျက်ကွက်မှုများ။ ဤကိစ္စများတွင် ကျိုးနေသော balancer ကို ဖယ်ရှားလိုပြီး အခြားယန္တရားတစ်ခု လိုအပ်ပါသည်။

ထို့ကြောင့် ယခင်အစီအစဉ်ကို ချဲ့ထွင်ခြင်းဖြင့် ExaBGP နှင့် HAProxy ကြားတွင် နှလုံးခုန်နှုန်းကို အကောင်အထည်ဖော်ခဲ့သည်။ ExaBGP သည် အပလီကေးရှင်းများ၏ အခြေအနေကို စစ်ဆေးရန် စိတ်ကြိုက် scripts များကို အသုံးပြုသည့်အခါ ၎င်းသည် ExaBGP နှင့် HAProxy အကြား အပြန်အလှန်အကျိုးသက်ရောက်မှုရှိသော ဆော့ဖ်ဝဲကို အကောင်အထည်ဖော်ခြင်း ဖြစ်သည်။

၎င်းကိုလုပ်ဆောင်ရန်၊ HAProxy ၏အခြေအနေကိုစစ်ဆေးနိုင်သည့် ExaBGP config တွင်ကျန်းမာရေးစစ်ဆေးသူအား configure ပြုလုပ်ရန်လိုအပ်သည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် HAProxy ရှိ ကျန်းမာရေးနောက်ခံကို ပြင်ဆင်သတ်မှတ်ပြီး ExaBGP ဘက်မှ ရိုးရှင်းသော GET တောင်းဆိုချက်ဖြင့် စစ်ဆေးပါသည်။ ကြေငြာချက်ရပ်သွားပါက HAProxy သည် အလုပ်မလုပ်ဘဲ ကြော်ငြာရန်မလိုအပ်ပါ။

HAProxy ကျန်းမာရေးစစ်ဆေးခြင်း။

HAProxy Peers- စက်ရှင်ကို ထပ်တူပြုခြင်း။

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

ဟန်ချက်ညီအောင် ချိန်ညှိနည်းအမျိုးမျိုး ရှိပါသည်- ကဲ့သို့သော ရိုးရှင်းသောနည်းလမ်းများ round- ရော်ဘင်ဖောက်သည်၏ ဆက်ရှင်ကို သတိရသောအခါနှင့် ယခင်ကဲ့သို့ပင် ဆာဗာပေါ်တွင် ကုန်ဆုံးချိန်တိုင်း၊ နှင့် ထပ်တိုးသည်။ ဒုတိယရွေးချယ်မှုကို အကောင်အထည်ဖော်ချင်ခဲ့တယ်။

HAProxy သည် ဤယန္တရား၏ client sessions များကိုသိမ်းဆည်းရန် stick-tables ကိုအသုံးပြုသည်။ ၎င်းတို့သည် သုံးစွဲသူ၏ မူရင်း IP လိပ်စာ၊ ရွေးချယ်ထားသော ပစ်မှတ်လိပ်စာ (နောက်ကွယ်မှ) နှင့် ဝန်ဆောင်မှု အချက်အလက်အချို့ကို သိမ်းဆည်းထားသည်။ ပုံမှန်အားဖြင့်၊ ဥပမာအားဖြင့်၊ RoundRobin ချိန်ခွင်လျှာမုဒ်တွင် အခြားချိန်ခွင်လျှာကိုပြောင်းသည့်အခါ အသုံးပြုသူ session context ကိုမလွှဲပြောင်းနိုင်သောအပလီကေးရှင်းများအတွက်အထူးသဖြင့်အသုံးဝင်သောအရင်းအမြစ်-IP + destination-IP အတွဲကို သိမ်းဆည်းရန် stick table များကိုအသုံးပြုသည်။

အကယ်၍ stick table တစ်ခုသည် မတူညီသော HAProxy လုပ်ငန်းစဉ်များ (ဟန်ချက်ညီမှုဖြစ်ပေါ်သည့်ကြား) အကြား ရွေ့လျားရန် သင်ကြားပေးပါက၊ ကျွန်ုပ်တို့၏ balancers များသည် stick table တစ်ခုတည်းနှင့် အလုပ်လုပ်နိုင်မည်ဖြစ်သည်။ ချိန်ခွင်လျှာများထဲမှ တစ်ခုပျက်ကွက်ပါက သုံးစွဲသူ၏ကွန်ရက်ကို ချောမွေ့စွာပြောင်းနိုင်စေမည်၊ ကလိုင်းယင့်ဆက်ရှင်များနှင့် အလုပ်သည် အစောပိုင်းရွေးချယ်ထားသည့် တူညီသောနောက်ကွယ်တွင် ဆက်လက်ရှိနေမည်ဖြစ်သည်။

သင့်လျော်သောလည်ပတ်မှုအတွက်၊ session ကိုတည်ဆောက်ခဲ့သည့် balancer ၏အရင်းအမြစ် IP လိပ်စာပြဿနာကို ဖြေရှင်းရမည်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ၎င်းသည် loopback မျက်နှာပြင်ရှိ dynamic address တစ်ခုဖြစ်သည်။

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

IaaS တွင် တူညီသောနည်းပညာကို အသုံးပြု၍ တည်ဆောက်ထားသော ဝန်ဆောင်မှုတစ်ခုရှိသည်။ ဒီ OpenStack အတွက် ဝန်ဆောင်မှုတစ်ခုအနေဖြင့် Balancer ကို တင်ပါ။Octavia ဟုခေါ်သည်။ ၎င်းသည် HAProxy လုပ်ငန်းစဉ်နှစ်ခုအပေါ်အခြေခံပြီး အစပိုင်းတွင် သက်တူရွယ်တူများအတွက် ပံ့ပိုးမှုပါ၀င်သည်။ ဒီဝန်ဆောင်မှုမှာ သူတို့ကိုယ်သူတို့ အကောင်းဆုံးသက်သေပြခဲ့ပြီးပါပြီ။

ရုပ်ပုံသည် HAProxy ဖြစ်ရပ်သုံးခုကြားရှိ မျိုးတူဇယားများ၏ ရွေ့လျားမှုကို ဇယားကွက်ဖြင့်ပြသထားပြီး၊ ၎င်းကို မည်သို့ပြင်ဆင်နိုင်သည်ဆိုသည်ကို ဒီဇိုင်းပုံစံတစ်ခုက အဆိုပြုထားသည်။

HAProxy Peers (ဆက်ရှင် ထပ်တူပြုခြင်း)

တူညီသောအစီအစဥ်ကို သင်အကောင်အထည်ဖော်ပါက၊ ၎င်း၏လုပ်ဆောင်ချက်ကို ဂရုတစိုက်စမ်းသပ်ရမည်ဖြစ်သည်။ ၎င်းသည် အချိန်၏ 100% တူညီသည့်အတိုင်း လုပ်ဆောင်လိမ့်မည်ဟူသောအချက်မဟုတ်ပါ။ သို့သော် အနည်းဆုံး ကလိုင်းယင့်၏ရင်းမြစ် IP ကို ​​မှတ်မိရန် လိုအပ်သောအခါတွင် stick tables များကို ဆုံးရှုံးမည်မဟုတ်ပါ။

တူညီသော client ထံမှ တပြိုင်နက် တောင်းဆိုမှု အရေအတွက်ကို ကန့်သတ်ခြင်း။

ကျွန်ုပ်တို့၏ APIs များအပါအဝင် လူသိရှင်ကြားရရှိနိုင်သည့် မည်သည့်ဝန်ဆောင်မှုများသည်မဆို တောင်းဆိုမှုများ ပြိုကျပျက်စီးနိုင်ပါသည်။ ၎င်းတို့အတွက် အကြောင်းပြချက်များသည် သုံးစွဲသူအမှားများမှ ပစ်မှတ်ထားသော တိုက်ခိုက်မှုအထိ လုံးဝကွဲပြားနိုင်သည်။ ကျွန်ုပ်တို့သည် IP လိပ်စာများမှ အခါအားလျော်စွာ DDoSed လုပ်နေပါသည်။ ဖောက်သည်များသည် ၎င်းတို့၏ scripts များတွင် မကြာခဏ အမှားအယွင်းများ လုပ်ကြပြီး mini-DDoS များကို ပေးပါသည်။

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

ထိုကန့်သတ်ချက်များကို အကောင်အထည်ဖော်ရန်၊ တူညီသော stick tables များကို အသုံးပြု၍ HAProxy ကိုအခြေခံ၍ ဖွဲ့စည်းထားသော နှုန်းထားကန့်သတ်ချက်များကို အသုံးပြုပါသည်။ ကန့်သတ်ချက်များသတ်မှတ်ခြင်းသည် အလွန်ရိုးရှင်းပြီး API သို့ တောင်းဆိုမှုအရေအတွက်အားဖြင့် အသုံးပြုသူကို ကန့်သတ်ရန်ခွင့်ပြုသည်။ အယ်လဂိုရီသမ်သည် တောင်းဆိုမှုများပြုလုပ်သည့် အရင်းအမြစ် IP ကို ​​မှတ်သားပြီး သုံးစွဲသူတစ်ဦးထံမှ တစ်ပြိုင်နက် တောင်းဆိုမှုအရေအတွက်ကို ကန့်သတ်ထားသည်။ ဟုတ်ပါတယ်၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုတစ်ခုစီအတွက် ပျမ်းမျှ API load ပရိုဖိုင်ကို တွက်ချက်ပြီး ≈ ဤတန်ဖိုးကို 10 ဆ ကန့်သတ်သတ်မှတ်ထားသည်။ ကျွန်ုပ်တို့သည် အခြေအနေကို အနီးကပ် စောင့်ကြည့်နေပြီး ကျွန်ုပ်တို့၏ လက်ချောင်းများကို သွေးခုန်နှုန်းပေါ်တွင် ထားရှိပါ။

ဒါက လက်တွေ့မှာ ဘယ်လိုမြင်လဲ။ ကျွန်ုပ်တို့တွင် ကျွန်ုပ်တို့၏ အလိုအလျောက် အတိုင်းအတာ API များကို တစ်ချိန်လုံး အသုံးပြုနေပါသည်။ ၎င်းတို့သည် နံနက်ပိုင်းတွင် virtual machine ပေါင်း နှစ်ရာမှ သုံးရာခန့်ကို ဖန်တီးပြီး ညနေပိုင်းတွင် ၎င်းတို့ကို ဖျက်ပစ်ပါသည်။ OpenStack အတွက်၊ PaaS ဝန်ဆောင်မှုများနှင့်အတူ virtual machine တစ်ခုဖန်တီးရာတွင် API မှတစ်ဆင့် ဝန်ဆောင်မှုများကြား အပြန်အလှန်အပြန်အလှန်ဖြစ်ခြင်းကြောင့် အနည်းဆုံး API တောင်းဆိုချက် 1000 လိုအပ်ပါသည်။

ထိုသို့သော လုပ်ငန်းတာဝန်များကို လွှဲပြောင်းခြင်းသည် အလွန်ကြီးမားသောဝန်ကို ဖြစ်စေသည်။ ကျွန်ုပ်တို့သည် ဤဝန်ကို အကဲဖြတ်ပြီး နေ့စဉ် အမြင့်ဆုံးကို စုဆောင်းကာ ၎င်းတို့ကို ဆယ်ဆတိုးစေပြီး၊ ၎င်းသည် ကျွန်ုပ်တို့၏ နှုန်းထားကန့်သတ်ချက်ဖြစ်လာသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏လက်ချောင်းကို သွေးခုန်နှုန်းပေါ်တွင် ထားရှိသည်။ ကျွန်ုပ်တို့တွင် CGA scripts တစ်ခုခုရှိမရှိကိုကြည့်ရှုရန် bot များနှင့် scanner များကိုမကြာခဏတွေ့မြင်ရပြီး၎င်းတို့ကိုတက်ကြွစွာဖြတ်တောက်နေပါသည်။

သုံးစွဲသူများသတိမထားမိဘဲ သင့်ကုဒ်ဘေ့စ်ကို အပ်ဒိတ်လုပ်နည်း

ကုဒ်ဖြန့်ကျက်မှု လုပ်ငန်းစဉ်အဆင့်တွင် အမှားအယွင်းခံနိုင်ရည်ကို ကျွန်ုပ်တို့ ဖော်ဆောင်ပါသည်။ စတင်ရောင်းချစဉ်အတွင်း ချို့ယွင်းချက်များရှိနိုင်သော်လည်း ဝန်ဆောင်မှုရရှိနိုင်မှုအပေါ် ၎င်းတို့၏သက်ရောက်မှုကို လျှော့ချနိုင်သည်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများကို အဆက်မပြတ် အပ်ဒိတ်လုပ်ပြီး သုံးစွဲသူများကို မထိခိုက်စေဘဲ codebase ကို အပ်ဒိတ်လုပ်ထားကြောင်း သေချာစေရမည်။ ကျွန်ုပ်တို့သည် HAProxy ၏ စီမံခန့်ခွဲမှုစွမ်းရည်များနှင့် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများတွင် Graceful Shutdown ကို အကောင်အထည်ဖော်ခြင်းဖြင့် ဤပြဿနာကို ဖြေရှင်းနိုင်ခဲ့သည်။

ဤပြဿနာကိုဖြေရှင်းရန်၊ ချိန်ခွင်လျှာထိန်းညှိမှုနှင့် ဝန်ဆောင်မှုများကို "မှန်ကန်သော" ပိတ်ခြင်းအား သေချာစေရန် လိုအပ်သည်-

• HAProxy ကိစ္စတွင်၊ အဓိကအားဖြင့် socket တစ်ခုဖြစ်သည့် stats ဖိုင်မှတဆင့် ထိန်းချုပ်မှုကို လုပ်ဆောင်ပြီး HAProxy config တွင် သတ်မှတ်ထားသည်။ သင်သည် stdio မှတဆင့်၎င်းကိုအမိန့်များပေးပို့နိုင်သည်။ သို့သော် ကျွန်ုပ်တို့၏ ပင်မဖွဲ့စည်းပုံထိန်းချုပ်မှုကိရိယာသည် သာလွန်ကောင်းမွန်သောကြောင့် ၎င်းတွင် HAProxy ကို စီမံခန့်ခွဲရန်အတွက် built-in module တစ်ခုရှိသည်။ ကျွန်ုပ်တို့ တက်ကြွစွာ အသုံးပြုနေပါသည်။
• ကျွန်ုပ်တို့၏ API နှင့် Engine ဝန်ဆောင်မှုအများစုသည် လှပသောပိတ်ခြင်းနည်းပညာများကို ပံ့ပိုးပေးသည်- ပိတ်လိုက်သောအခါတွင်၊ ၎င်းတို့သည် လက်ရှိလုပ်ဆောင်ရမည့်တာဝန်၊ http တောင်းဆိုမှု သို့မဟုတ် ဝန်ဆောင်မှုလုပ်ငန်းတစ်ခုဖြစ်စေရန် စောင့်ဆိုင်းနေကြသည်။ အလုပ်သမားမှာလည်း အလားတူပါပဲ။ သူလုပ်နေတဲ့ အလုပ်တွေအားလုံးကို သိပြီး အရာအားလုံးကို အောင်မြင်စွာ ပြီးမြောက်သွားတဲ့အခါ ပြီးဆုံးသွားပါတယ်။

ဤအချက်နှစ်ချက်ကြောင့် ကျွန်ုပ်တို့၏ဖြန့်ကျက်မှုအတွက် ဘေးကင်းသော အယ်လဂိုရီသမ်သည် ဤကဲ့သို့ဖြစ်ပုံရသည်။

1. ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ကုဒ်အသစ်အထုပ်တစ်ခုကို စုစည်းသည် (ကျွန်ုပ်တို့အတွက် ၎င်းသည် RPM ဖြစ်သည်)၊ ၎င်းကို dev ပတ်၀န်းကျင်တွင် စမ်းသပ်ပြီး၊ ၎င်းကို စင်မြင့်တွင် စမ်းသပ်ပြီး အဆင့်သိုလှောင်မှုတွင် ထားခဲ့သည်။
2. developer သည် "artifacts" ၏အသေးစိတ်ဆုံးဖော်ပြချက်ဖြင့် ဖြန့်ကျက်ရန်တာဝန်ကို သတ်မှတ်ပေးသည်- ပက်ကေ့ဂျ်အသစ်၏ဗားရှင်း၊ လုပ်ဆောင်ချက်အသစ်၏ဖော်ပြချက်နှင့် လိုအပ်ပါက ဖြန့်ကျက်ခြင်းဆိုင်ရာ အခြားအသေးစိတ်အချက်အလက်များကို သတ်မှတ်ပေးသည်။
3. စနစ်စီမံခန့်ခွဲသူက အပ်ဒိတ်ကို စတင်သည်။ Ansible playbook ကိုဖွင့်ပြီး အောက်ပါတို့ကို လုပ်ဆောင်ပေးပါသည်။
   • အဆင့်သိုလှောင်မှုမှ ပက်ကေ့ဂျ်တစ်ခုကိုယူပြီး ထုတ်ကုန်သိုလှောင်ရာရှိ ပက်ကေ့ဂျ်၏ဗားရှင်းကို အပ်ဒိတ်လုပ်ရန် ၎င်းကိုအသုံးပြုပါ။
   • အပ်ဒိတ်လုပ်ထားသော ဝန်ဆောင်မှု၏ နောက်ကွယ်တွင် စာရင်းကို စုစည်းပါ။
   • HAProxy တွင် အပ်ဒိတ်လုပ်မည့် ပထမဆုံးဝန်ဆောင်မှုကို ပိတ်လိုက်ပြီး ၎င်း၏လုပ်ငန်းစဉ်များ ပြီးဆုံးရန် စောင့်ဆိုင်းနေပါသည်။ သပ်ရပ်စွာ ပိတ်ခြင်းအား ကျေးဇူးတင်လျက်၊ လက်ရှိ အသုံးပြုသူ တောင်းဆိုချက်များအားလုံး အောင်မြင်စွာ ပြီးမြောက်မည်ဟု ကျွန်ုပ်တို့ ယုံကြည်ပါသည်။
   • API နှင့် အလုပ်သမားများကို လုံးဝရပ်တန့်လိုက်ပြီး HAProxy ကို ပိတ်ပြီးနောက်၊ ကုဒ်ကို အပ်ဒိတ်လုပ်ထားသည်။
   • Ansible ဝန်ဆောင်မှုများ
   • ဝန်ဆောင်မှုတစ်ခုစီအတွက်၊ ကြိုတင်သတ်မှတ်ထားသောသော့စမ်းသပ်မှုများစွာတွင် ယူနစ်စမ်းသပ်ခြင်းလုပ်ဆောင်သည့် အချို့သော "လက်ကိုင်များ" ကို ဆွဲထုတ်ပါသည်။ ကုဒ်အသစ်၏ အခြေခံ စစ်ဆေးမှုကို ပြုလုပ်သည်။
   • ယခင်အဆင့်တွင် အမှားအယွင်းများမတွေ့ပါက၊ နောက်ခံဖိုင်ကို စတင်အသုံးပြုနိုင်မည်ဖြစ်သည်။
   • နောက်ကျောဘက်သို့ ဆက်သွားကြပါစို့။
4. နောက်ခံအားလုံးကို အပ်ဒိတ်လုပ်ပြီးနောက်၊ လုပ်ဆောင်ချက်ဆိုင်ရာ စမ်းသပ်မှုများကို စတင်သည်။ ၎င်းတို့ ပျောက်ဆုံးနေပါက၊ developer သည် သူဖန်တီးထားသည့် မည်သည့်လုပ်ဆောင်ချက်အသစ်ကိုမဆို ကြည့်ရှုသည်။

ဤအရာသည် ဖြန့်ကျက်မှုကို အပြီးသတ်စေသည်။

ဝန်ဆောင်မှု အပ်ဒိတ်စက်ဝန်း

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

ကောက်ချက်

အမှားအယွင်းခံနိုင်သော WEB ဗိသုကာနှင့်ပတ်သက်ပြီး ကျွန်ုပ်၏ကိုယ်ပိုင်အတွေးအမြင်များကို မျှဝေရင်း၊ ၎င်း၏ အဓိကအချက်များကို ကျွန်ုပ် ထပ်မံမှတ်သားလိုပါသည်။

• ရုပ်ပိုင်းဆိုင်ရာအမှားခံနိုင်ရည်;
• ကွန်ရက်အမှားခံနိုင်မှု (ချိန်ခွင်လျှာများ၊ BGP);
• အသုံးပြုပြီး တီထွင်ထားသော ဆော့ဖ်ဝဲလ်၏ အမှားအယွင်းကို ခံနိုင်ရည်ရှိသည်။

တည်ငြိမ်သော အလုပ်ချိန်အားလုံး။

source: www.habr.com