ဆိုက်ဘာပန့်ခ်ဖြင့် အရသာခံနိုင်သော cloud ဝန်ဆောင်မှုတစ်ခု ဖန်တီးမှုသမိုင်း

သင် IT တွင် အလုပ်လုပ်သည်နှင့်အမျှ စနစ်များတွင် ၎င်းတို့၏ စရိုက်လက္ခဏာများ ရှိနေသည်ကို သင်စတင်သတိထားမိသည်။ ၎င်းတို့သည် ပြောင်းလွယ်ပြင်လွယ်၊ အသံတိတ်၊ ထူးဆန်းသော၊ တင်းမာနိုင်သည်။ ဆွဲဆောင်နိုင်သည် သို့မဟုတ် တွန်းလှန်နိုင်သည်။ တစ်နည်းမဟုတ်တစ်နည်း၊ သင်သည် ၎င်းတို့နှင့် “ညှိနှိုင်း” ရန်၊ “တွင်းပေါက်များ” အကြား လေ့ကျင့်မှုနှင့် ၎င်းတို့၏ အပြန်အလှန်ဆက်သွယ်မှု ကွင်းဆက်များ တည်ဆောက်ရန် လိုအပ်သည်။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် cloud ပလပ်ဖောင်းတစ်ခုကို တည်ဆောက်ရခြင်း၏ ဂုဏ်အသရေရှိခဲ့ပြီး ယင်းအတွက် ကျွန်ုပ်တို့နှင့် လုပ်ဆောင်ရန် စနစ်ခွဲနှစ်ခုကို “ဆွဲဆောင်” ရန် လိုအပ်ပါသည်။ ကံကောင်းထောက်မစွာ၊ ကျွန်ုပ်တို့တွင် “API ဘာသာစကား”၊ တိုက်ရိုက်လက်များနှင့် စိတ်အားထက်သန်မှုများစွာရှိသည်။

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

ကြောင်မှကြိုဆိုပါတယ်။

လမ်း၏အစ

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

လိုအပ်ချက်များစွာလည်း ရှိခဲ့သည်-

• ဝန်ဆောင်မှုသည် အဆင်ပြေသော ကိုယ်ပိုင်အကောင့်တစ်ခု လိုအပ်ပါသည်။
• ပလက်ဖောင်းကို လက်ရှိငွေပေးချေမှုစနစ်တွင် ပေါင်းစည်းရပါမည်။
• ဆော့ဖ်ဝဲလ်နှင့် ဟာ့ဒ်ဝဲ- OpenStack + Tungsten Fabric (Open Contrail)၊ ကျွန်ုပ်တို့၏ အင်ဂျင်နီယာများသည် “ချက်ပြုတ်ခြင်း” ကို ကောင်းစွာ သင်ယူခဲ့ကြပါသည်။

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

• Python + Flask + Swagger + SQLAlchemy - လုံးဝ standard Python set တစ်ခု။
• ရှေ့တန်းအတွက် Vue.js;
• Celery ကို AMQP ကို ​​အသုံးပြု၍ အစိတ်အပိုင်းများနှင့် ဝန်ဆောင်မှုများအကြား အပြန်အလှန်အကျိုးသက်ရောက်မှုကို ပြုလုပ်ရန် ဆုံးဖြတ်ခဲ့သည်။

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

ဒီတော့ ငါတို့ရဲ့ အသိအကျွမ်းကို စလိုက်ရအောင်။

Silent Bill - ငွေတောင်းခံခြင်း။

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

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

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

ဆော့ဖ်ဝဲလ် API ၏ဖော်ပြချက်ဖြင့် သုံးသပ်ပါက ဤပြဿနာကို ဖြေရှင်းရန် ဖြစ်နိုင်သေးသော်လည်း၊ ကျွန်ုပ်တို့တွင် reverse engineering လုပ်ရန် အချိန်မရှိသောကြောင့် ကျွန်ုပ်တို့သည် ယုတ္တိဗေဒကို အပြင်သို့ထုတ်ကာ RabbitMQ ၏ထိပ်တွင် အလုပ်တန်းတစ်ခုကို စီစဉ်ခဲ့သည်။ ဝန်ဆောင်မှုတစ်ခုပေါ်ရှိ လုပ်ဆောင်ချက်ကို ဖောက်သည်သည် ၎င်း၏ကိုယ်ရေးကိုယ်တာအကောင့်မှ စတင်လုပ်ဆောင်သည်၊ နောက်ကွယ်ရှိ Celery “တာဝန်” အဖြစ်သို့ ပြောင်းလဲကာ ငွေပေးချေမှုနှင့် OpenStack ဘက်တွင် လုပ်ဆောင်သည်။ ဆလရီသည် အလုပ်များကို စီမံခန့်ခွဲရန်၊ ထပ်ခါတလဲလဲ စုစည်းရန်နှင့် အခြေအနေကို စောင့်ကြည့်ရန် အတော်လေး အဆင်ပြေစေသည်။ ဥပမာအားဖြင့် "တရုတ်နံနံ" အကြောင်းပိုမိုဖတ်ရှုနိုင်သည်။ ဒီမှာ.

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

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

နောက်ပြဿနာတစ်ခုကတော့ တိတ်ဆိတ်မှုပါပဲ။

Billy သည် API တောင်းဆိုချက်အချို့အတွက် "Ok" ကို တိတ်တဆိတ်ဖြေသည်။ ဥပမာအားဖြင့်၊ စမ်းသပ်မှုအတွင်း ကတိပြုထားသော ငွေပေးချေမှုများ ပြုလုပ်သောအခါ (ထိုအရာသည် နောက်ပိုင်းတွင် ပိုမို) ဖြစ်လာသည်။ တောင်းဆိုချက်များကို မှန်ကန်စွာ လုပ်ဆောင်ခဲ့ပြီး မည်သည့်အမှားအယွင်းမျှ မတွေ့ခဲ့ရပါ။

UI မှတဆင့်စနစ်နှင့်အလုပ်လုပ်စဉ်မှတ်တမ်းများကိုလေ့လာခဲ့ရသည်။ ငွေတောင်းခံခြင်းကိုယ်တိုင်က အလားတူတောင်းဆိုမှုများကို လုပ်ဆောင်ပြီး နယ်ပယ်ကို သတ်သတ်မှတ်မှတ်အသုံးပြုသူတစ်ဦးသို့ ပြောင်းလဲကာ su parameter တွင် ၎င်းကို ဖြတ်သန်းသွားကြောင်း တွေ့ရှိရပါသည်။

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

ထို့ကြောင့် အကျဉ်းချုပ်ပြောရလျှင် အပြန်အလှန်ဆက်ဆံရေးအဆင့်တွင် ကျွန်ုပ်တို့ကြုံတွေ့ရသည့် အဓိကပြဿနာများသည် သီးခြားစနစ်တစ်ခု၏ အကောင်အထည်ဖော်မှုအင်္ဂါရပ်များနှင့် သက်ဆိုင်သည်-

• တစ်နည်းမဟုတ်တစ်နည်းဖြင့် ကျွန်ုပ်တို့ကို အကျိုးသက်ရောက်စေသော စာရွက်စာတမ်းမရှိသော “အင်္ဂါရပ်များ”
• ပိတ်ထားသောရင်းမြစ် (ငွေတောင်းခံခြင်းကို C++ ဖြင့်ရေးသားထားသည်) ရလဒ်အနေဖြင့် - "အစမ်းသုံးခြင်းနှင့်အမှား" မှလွဲ၍ အခြားမည်သည့်နည်းဖြင့် ပြဿနာ 1 ကိုဖြေရှင်းရန်မဖြစ်နိုင်ပါ။

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

• နည်းပညာပိုင်းဆိုင်ရာ ပံ့ပိုးမှု module - သင့်ကိုယ်ရေးကိုယ်တာအကောင့်မှ တောင်းဆိုချက်များကို ဝန်ဆောင်မှုဖောက်သည်များအတွက် ပွင့်လင်းမြင်သာစွာ ငွေတောင်းခံခြင်းသို့ “proxied” ပေးထားပါသည်။
• ဘဏ္ဍာရေး module - လက်ရှိဖောက်သည်များအား ပြေစာများထုတ်ပေးခြင်း၊ ဖြတ်ထုတ်မှုများပြုလုပ်ခြင်းနှင့် ငွေပေးချေမှုစာရွက်စာတမ်းများထုတ်ပေးခြင်းတို့ ပြုလုပ်နိုင်စေပါသည်။
• ဝန်ဆောင်မှုထိန်းချုပ်မှု module - ဤအတွက်ကျွန်ုပ်တို့သည်ကျွန်ုပ်တို့၏ကိုယ်ပိုင်လက်ကိုင်ကိုအကောင်အထည်ဖော်ရန်ရှိသည်။ စနစ်၏ ချဲ့ထွင်နိုင်မှုသည် ကျွန်ုပ်တို့လက်ထဲသို့ ရောက်ရှိလာပြီး ဝန်ဆောင်မှု အမျိုးအစားသစ်တစ်ခုအား ဘီလီအား “သင်ပေး” ပါသည်။
  နည်းနည်းတော့ အလုပ်ရှုပ်နေပေမယ့် တစ်နည်းနည်းနဲ့ ဘီလီနဲ့ ကျွန်တော် ပြေလည်သွားမယ်လို့ ထင်ပါတယ်။

အဖြိုက်နက်ကွင်းများအတွင်း လမ်းလျှောက်ခြင်း - Tungsten Fabric

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

၎င်းသည် ယခင်က OpenContrail ၊ Tungsten Fabric (TF) နှင့် မိတ်ဆွေဖွဲ့ခဲ့သော ဒုတိယစနစ်၏ ဒိုမိန်းဖြစ်သည်။ ၎င်း၏တာဝန်မှာ သုံးစွဲသူများအနေနှင့် ကျွန်ုပ်တို့အား ဆော့ဖ်ဝဲလ်မှ စုပ်ယူမှုတစ်ခု ပံ့ပိုးပေးသည့် ကွန်ရက်ပစ္စည်းများကို စီမံခန့်ခွဲရန်ဖြစ်သည်။ TF - SDN သည် ကွန်ရက်စက်ပစ္စည်းများနှင့် လုပ်ဆောင်ခြင်း၏ ရှုပ်ထွေးသောယုတ္တိကို ဖုံးအုပ်ထားသည်။ ဥပမာ- နည်းပညာနဲ့ ပတ်သက်တဲ့ ဆောင်းပါးကောင်းတစ်ပုဒ်ရှိတယ်၊ ဒီမှာ.

စနစ်အား Neutron ပလပ်အင်မှတစ်ဆင့် OpenStack (အောက်တွင် ဆွေးနွေးထားသည်) နှင့် ပေါင်းစပ်ထားသည်။

OpenStack ဝန်ဆောင်မှုများ၏ အပြန်အလှန်အကျိုးပြုမှု။

စစ်ဆင်ရေးဌာနက ကောင်လေးတွေက ဒီစနစ်ကို မိတ်ဆက်ပေးတယ်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုများ၏ ကွန်ရက်အစုအဝေးကို စီမံခန့်ခွဲရန် စနစ်၏ API ကို အသုံးပြုပါသည်။ ၎င်းသည် ကျွန်ုပ်တို့အား ကြီးလေးသောပြဿနာများ သို့မဟုတ် အဆင်မပြေမှုများကို မဖြစ်ပေါ်စေသေးပါ (ကျွန်တော် OE မှ ယောက်ျားများအတွက် စကားမပြောနိုင်ပါ)၊ သို့သော် အပြန်အလှန်ဆက်သွယ်မှုတွင် ထူးထူးခြားခြားအချို့ရှိနေပါသည်။

ပထမအချက်မှာ ဤကဲ့သို့ ဖြစ်သည်- SSH မှတစ်ဆင့် ချိတ်ဆက်သောအခါတွင် instance console သို့ data အများအပြားထွက်ရန်လိုအပ်သည့် command များသည် ရိုးရိုးရှင်းရှင်း “hang up” ချိတ်ဆက်မှုဖြစ်ပြီး VNC မှတဆင့် အရာအားလုံးသည် မှန်ကန်စွာအလုပ်လုပ်ပါသည်။

ပြဿနာနှင့် မရင်းနှီးသောသူများအတွက်၊ ၎င်းသည် ရယ်စရာကောင်းနေပုံရသည်- ls /root မှန်ကန်စွာအလုပ်လုပ်သည်၊ ဥပမာ၊ အပေါ်မှ "freezes" သည် လုံးဝဖြစ်သည်။ ကံကောင်းထောက်မစွာ၊ ကျွန်ုပ်တို့သည် ယခင်က အလားတူပြဿနာများကို ကြုံတွေ့ခဲ့ဖူးသည်။ ၎င်းကို တွက်ချက်သည့်နေရာများမှ router များသို့ လမ်းကြောင်းပေါ်တွင် MTU ကို ချိန်ညှိခြင်းဖြင့် ဆုံးဖြတ်ခဲ့သည်။ စကားမစပ်၊ ဒါက TF ပြဿနာမဟုတ်ပါဘူး။

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

ကျွန်ုပ်တို့သည် စီမံခန့်ခွဲသူအဆင့်မှ Openstack နှင့် လုပ်ဆောင်ခဲ့ပြီး ထို့နောက် လိုအပ်သောအသုံးပြုသူအဆင့်သို့ ပြောင်းရွှေ့ခဲ့သည်။ SDN သည် လုပ်ဆောင်ချက်များကို လုပ်ဆောင်ပေးသော အသုံးပြုသူ၏ နယ်ပယ်ကို "hijack" လုပ်ပုံပေါ်သည်။ အမှန်မှာ TF နှင့် OpenStack ကိုချိတ်ဆက်ရန်အတွက် တူညီသောစီမံခန့်ခွဲသူအကောင့်ကိုအသုံးပြုပါသည်။ အသုံးပြုသူသို့ပြောင်းသည့်အဆင့်တွင်၊ "မှော်" ပျောက်ကွယ်သွားသည်။ စနစ်နှင့်အလုပ်လုပ်ရန် သီးခြားအကောင့်တစ်ခုဖန်တီးရန် ဆုံးဖြတ်ခဲ့သည်။ ၎င်းသည် ကျွန်ုပ်တို့အား ပေါင်းစပ်လုပ်ဆောင်နိုင်စွမ်းကို ချိုးဖျက်ခြင်းမပြုဘဲ လုပ်ဆောင်နိုင်စေခဲ့သည်။

Silicon Lifeforms - OpenStack

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

OpenStack သည် ကျွန်ုပ်တို့၏ပလပ်ဖောင်း၏ အဓိကအချက်ဖြစ်သည်။

OpenStack တွင် လက်ရှိကျွန်ုပ်တို့သည် Nova၊ Glance နှင့် Cinder ကို အတက်ကြွဆုံးအသုံးပြုနေသည့် စနစ်ခွဲများစွာရှိသည်။ ၎င်းတို့တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင် API ရှိသည်။ Nova သည် ကွန်ပျူတာဆိုင်ရာ အရင်းအမြစ်များနှင့် သာဓကများ ဖန်တီးခြင်းအတွက် တာဝန်ရှိသည်၊ Cinder သည် volumes များနှင့် ၎င်းတို့၏ လျှပ်တစ်ပြက်ရိုက်ချက်များကို စီမံခန့်ခွဲရန် တာဝန်ရှိသည်၊ Glance သည် ၎င်းတို့အပေါ် OS နမူနာများနှင့် မှတ်တမ်းပုံစံများကို စီမံခန့်ခွဲသည့် ရုပ်ပုံဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။

ဝန်ဆောင်မှုတစ်ခုစီသည် ကွန်တိန်နာတစ်ခုတွင်လည်ပတ်နေပြီး မက်ဆေ့ချ်ပွဲစားသည် "ယုန်ဖြူ" ဖြစ်သည် - RabbitMQ။

ဒီစနစ်က ကျွန်တော်တို့ကို မမျှော်လင့်ထားတဲ့ ဒုက္ခအများဆုံးပေးခဲ့တယ်။

ဆာဗာသို့ အပိုအသံပမာဏတစ်ခုကို ချိတ်ဆက်ရန် ကြိုးစားသောအခါတွင် ပထမပြဿနာမှာ မကြာလှပေ။ Cinder API သည် ဤတာဝန်ကို လုပ်ဆောင်ရန် ပြတ်ပြတ်သားသား ငြင်းဆိုခဲ့သည်။ ပို၍တိကျစွာပြောရလျှင်၊ သင်သည် OpenStack ကိုယ်တိုင်ယုံကြည်ပါက၊ ချိတ်ဆက်မှုကို တည်ဆောက်ထားသော်လည်း virtual server အတွင်းရှိ disk device မရှိပါ။

ကျွန်ုပ်တို့သည် လမ်းလွှဲရန် ဆုံးဖြတ်ပြီး Nova API မှ အလားတူလုပ်ဆောင်ချက်ကို တောင်းဆိုခဲ့သည်။ ရလဒ်မှာ စက်သည် မှန်ကန်စွာချိတ်ဆက်ပြီး ဆာဗာအတွင်း ဝင်ရောက်နိုင်ခြင်းကြောင့်ဖြစ်သည်။ Block-storage သည် Cinder ကို မတုံ့ပြန်သည့်အခါ ပြဿနာဖြစ်ပေါ်ပါသည်။

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

တဖန်၊ OpenStack ကိုယ်တိုင်က ၎င်းသည် ချိတ်ဆက်မှုကို ဖျက်ဆီးလိုက်ကြောင်း “ကျိန်ဆို” ခဲ့ပြီး ယခု သင်သည် သီးခြား volume ဖြင့် မှန်ကန်စွာ လုပ်ဆောင်နိုင်ပြီဖြစ်သည်။ သို့သော် API သည် disk ပေါ်တွင် လုပ်ဆောင်ချက်များကို အတိအကျ မလုပ်ဆောင်လိုပါ။

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

OpenStack သည် ၎င်း၏ကိုယ်ပိုင်အပြန်အလှန်ယုတ္တိဗေဒနှင့် တန်ဆာဆင်ထားသော API ပါရှိသော အတော်လေးရှုပ်ထွေးသောစနစ်များဖြစ်သည်။ ကျွန်ုပ်တို့အား မျှမျှတတအသေးစိတ်အချက်အလက်များဖြင့် ထောက်ကူပေးထားပြီး၊ ဟုတ်ပါတယ်၊ အစမ်းမှားခြင်း (အဲဒါမရှိရင် ဘယ်မှာလဲ)။

စမ်းသပ်ပြေး

ကျွန်ုပ်တို့သည် ပြီးခဲ့သည့်နှစ် ဒီဇင်ဘာလတွင် စမ်းသပ်ပစ်လွှတ်မှုကို ပြုလုပ်ခဲ့သည်။ အဓိကတာဝန်မှာ နည်းပညာဘက်ခြမ်းနှင့် UX ဘက်မှ တိုက်ခိုက်ရေးမုဒ်တွင် ကျွန်ုပ်တို့၏ပရောဂျက်ကို စမ်းသပ်ရန်ဖြစ်သည်။ ပရိသတ်များကို ရွေးချယ်ဖိတ်ကြားခဲ့ပြီး စမ်းသပ်မှုကို ပိတ်ခဲ့သည်။ သို့သော်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝဘ်ဆိုက်တွင် စမ်းသပ်ခွင့်ကို တောင်းဆိုရန် ရွေးချယ်ခွင့်ကိုလည်း ချန်ထားခဲ့သည်။

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

ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် ပရောဂျက်အပေါ် စိတ်ဝင်စားမှုကို အနည်းငယ်လွဲမှားစွာ အကဲဖြတ်ခဲ့ပြီး စမ်းသပ်နေစဉ်အတွင်း တွက်ချက်မှုအမှတ်အသားများကို လျင်မြန်စွာ ထည့်သွင်းရမည်ဖြစ်ပါသည်။ အစုအဖွဲ့တစ်ခုအတွက် ဖြစ်ရိုးဖြစ်စဉ်တစ်ခု၊ သို့သော် ဤနေရာတွင်လည်း ကွဲလွဲချက်အချို့ရှိသည်။ TF ၏ သီးခြားဗားရှင်းတစ်ခုအတွက် စာရွက်စာတမ်းသည် vRouter နှင့် စမ်းသပ်ထားသည့် kernel ၏ သီးခြားဗားရှင်းကို ညွှန်ပြသည်။ မကြာသေးမီက kernels များဖြင့် node များကိုဖွင့်ရန် ဆုံးဖြတ်ခဲ့သည်။ ရလဒ်အနေဖြင့် TF သည် nodes များမှ လမ်းကြောင်းများကို မရရှိခဲ့ပါ။ စေ့တွေကို အမြန်ပြန်လှန်ရတယ်။

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

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

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

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

ဆက်ခံရဖို့

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

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

ကျွန်ုပ်တို့သည် စနစ်များကို ဆွဲဆောင်နိုင်နေပြီဖြစ်သည်။ ဘီလ်သည် ရေတွက်ခြင်း၊ ငွေပေးချေခြင်းနှင့် အသုံးပြုသူတောင်းဆိုချက်များကို ၎င်း၏ဗီရိုအတွင်းမှ စနစ်တကျ ကိုင်တွယ်သည်။ tungsten fields ၏ “မှော်ပညာ” သည် ကျွန်ုပ်တို့အား တည်ငြိမ်သော ဆက်သွယ်မှုကို ပေးသည်။ OpenStack သာလျှင် တစ်ခါတစ်ရံတွင် "'WSREP သည် အပလီကေးရှင်းအသုံးပြုရန်အတွက် node ကို မပြင်ဆင်ရသေးပါ။ ဒါ​ပေမယ့်​ ဒါဟာ လုံးဝခြားနားတဲ့ ဇာတ်​လမ်းပါပဲ...

ကျွန်ုပ်တို့သည် မကြာသေးမီက ဝန်ဆောင်မှုကို စတင်ခဲ့သည်။
ကျွန်ုပ်တို့၏အသေးစိတ်အချက်အလက်များကို သင်ရှာဖွေနိုင်ပါသည်။ က်ဘ်ဆိုက်.

CLO ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့

အသုံးဝင်သောလင့်များ

OpenStack

• https://docs.openstack.org/nova/latest/
• https://docs.openstack.org/keystone/latest/
• https://docs.openstack.org/cinder/latest/
• https://docs.openstack.org/glance/latest/

အဖြိုက်နက်ထည်

• http://docs.tungsten.io/en/latest/user/getting-started/index.html
• https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

source: www.habr.com