Kubernetes တွင်သိုလှောင်မှု- OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

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

ရိုးရိုးသားသားပြောရရင် ကျွန်တော် စွန့်စားပြီး စွန့်စားခဲ့တယ်။ Kubernetes (အနည်းဆုံးတော့ လောလောဆယ်)။ ငါသုံးမယ်။ Heroku. အဘယ်ကြောင့်? သိုလှောင်မှုကြောင့်။ Kubernetes ကိုယ်တိုင်ထက် သိုလှောင်မှု ပိုမိုများပြားလာမည်ဟု ဘယ်သူက ထင်မည်နည်း။ ငါသုံးတယ်။ Hetzner တိမ်တိုက်စျေးမကြီးတဲ့အတွက်ကြောင့် စွမ်းဆောင်ရည်က ကောင်းမွန်ပြီး အစကတည်းက ကျွန်တော်ဟာ အစုအဝေးတွေကို အသုံးပြုပြီး ဖြန့်ကျက်ထားခဲ့ပါတယ်။ မွေးမြူရေးသမား. အရာအားလုံးကို ကိုယ်တိုင်လေ့လာလိုသောကြောင့် ကျွန်ုပ်သည် Google/Amazon/Microsoft/DigitalOcean စသည်ဖြင့် စီမံခန့်ခွဲထားသော Kubernetes ဝန်ဆောင်မှုများကို မကြိုးစားခဲ့ပါ။ ငါလည်း ချွေတာတယ်။

ဒါကြောင့် ဖြစ်နိုင်တဲ့ Kubernetes stack ကို အကဲဖြတ်တဲ့အခါ ဘယ်သိုလှောင်ခန်းကို ရွေးရမလဲဆိုတာကို ဆုံးဖြတ်ဖို့ အချိန်တော်တော်ကြာအောင် ကြိုးစားခဲ့ရပါတယ်။ စျေးနှုန်းကြောင့်သာမဟုတ်ဘဲ open source ဖြေရှင်းနည်းများကို ပိုနှစ်သက်သော်လည်း ၎င်းတို့တွင် အကန့်အသတ်များရှိသည့် အခမဲ့ဗားရှင်းများရှိသောကြောင့် မစပ်စုဘဲ အခပေးရွေးချယ်စရာအချို့ကို စူးစမ်းရှာဖွေခဲ့သည်။ မတူညီသောရွေးချယ်စရာများကို နှိုင်းယှဉ်ကြည့်သောအခါတွင် မကြာသေးမီက စမ်းသပ်မှုများမှ နံပါတ်အချို့ကို ကျွန်ုပ်မှတ်သားထားပြီး Kubernetes သိုလှောင်မှုအကြောင်း လေ့လာနေသူများအတွက် ၎င်းတို့ စိတ်ဝင်စားဖွယ်ကောင်းပါသည်။ ကျွန်ုပ်သည် Kubernetes ကို လောလောဆယ် နှုတ်ခွန်းဆက်စကား ပြောဖူးသော်လည်း၊ ကျွန်တော်လည်း ဖော်ပြချင်ပါတယ်။ CSI ယာဉ်မောင်းHetzner Cloud volumes များကို တိုက်ရိုက်ပေးစွမ်းနိုင်သော်လည်း ကျွန်ုပ် မစမ်းကြည့်ရသေးပါ။ အထူးသဖြင့် node ချို့ယွင်းမှုများနှင့် အခြားအလားတူ အခြေအနေများတွင် မည်သည့် node တွင်မဆို ဆက်တိုက် volumes များကို လျင်မြန်စွာ ထည့်သွင်းနိုင်ခြင်းကြောင့် cloud ဆော့ဖ်ဝဲသတ်မှတ်ထားသော သိုလှောင်ခန်းသို့ ကြည့်ရှုခဲ့သည်။ အချို့သောဖြေရှင်းချက်များသည် အချိန်နှင့်တပြေးညီ လျှပ်တစ်ပြက်ရိုက်ချက်များနှင့် ဆိုက်ပြင်ပအရန်ကူးယူမှုများကို ပေးစွမ်းနိုင်ပြီး အဆင်ပြေသည်။

ကျွန်ုပ်သည် သိုလှောင်မှုဖြေရှင်းချက် 6-7 ကို စမ်းသပ်ခဲ့သည်-

OpenEBS

ငါပြီးသားပြောခဲ့သကဲ့သို့ ယခင်ပို့စ်တစ်ခုတွင်စာရင်းထဲမှ ရွေးချယ်စရာအများစုကို စမ်းသပ်ပြီးနောက်၊ ကျွန်ုပ်သည် OpenEBS တွင် စတင်အခြေချခဲ့သည်။ OpenEBS သည် တပ်ဆင်အသုံးပြုရန် အလွန်လွယ်ကူသော်လည်း ရိုးရိုးသားသား ပြောရလျှင် ဝန်ခံထားသော ဒေတာအစစ်အမှန်ဖြင့် စမ်းသပ်ပြီးနောက် ၎င်း၏စွမ်းဆောင်ရည်အတွက် ကျွန်တော် စိတ်ပျက်မိပါသည်။ ၎င်းသည် open source ဖြစ်ပြီး၊ developer များသည် ၎င်းတို့ဘာသာဖြစ်သည်။ အားမနာပါနဲ့ အကူအညီလိုတဲ့အခါ အမြဲကူညီတတ်တယ်။ ကံမကောင်းစွာဖြင့်၊ ၎င်းသည် အခြားရွေးချယ်စရာများနှင့် နှိုင်းယှဉ်ပါက အလွန်ညံ့ဖျင်းသောကြောင့် စမ်းသပ်မှုများကို ပြန်လည်လုပ်ဆောင်ရမည်ဖြစ်ပါသည်။ OpenEBS တွင် လောလောဆယ်တွင် သိုလှောင်မှုအင်ဂျင် 3 ခုရှိသော်လည်း cStor အတွက် စံရလဒ်များကို ကျွန်ုပ်တင်နေပါသည်။ Jiva နှင့် LocalPV အတွက် နံပါတ်များ ကျွန်ုပ်တွင် မရှိသေးပါ။

အတိုချုပ်ပြောရလျှင် Jiva သည် အနည်းငယ်မြန်ပြီး LocalPV သည် ယေဘုယျအားဖြင့် မြန်ဆန်သည်၊၊ disk benchmark ထက် တိုက်ရိုက်မဆိုးပါ။ LocalPV ၏ပြဿနာမှာ ၎င်းကိုပြင်ဆင်ထားသည့် node တွင်သာ အသံအတိုးအကျယ်ကို ဝင်ရောက်ကြည့်ရှုနိုင်ပြီး ပြန်လည်ပုံတူခြင်းလုံးဝမရှိပါ။ မှတစ်ဆင့် အရန်ကူးယူရာတွင် ပြဿနာအချို့ရှိနေသည်။ ရွက်လှေ node အမည်များ မတူညီသောကြောင့် အစုအသစ်တစ်ခုတွင် အရန်ကူးခြင်းအကြောင်းပြောလျှင် cStor ရှိသည်။ Velero အတွက် ပလပ်အင်Velero-Restic ဖြင့် ဖိုင်အဆင့် မိတ္တူကူးခြင်းထက် ပိုအဆင်ပြေသည့် အချိန်အတွင်း လျှပ်တစ်ပြက်ရိုက်ချက်များကို ဆိုက်ပြင်ပတွင် မိတ္တူကူးနိုင်သည်။ ကျွန်တော်ရေးခဲ့သည် script ပေါင်းများစွာအရန်သိမ်းမှုများကို စီမံခန့်ခွဲရန်နှင့် ပြန်လည်ရယူရန် ပိုမိုလွယ်ကူစေရန် ဤပလပ်အင်ဖြင့်။ ခြုံပြီးပြောရရင် OpenEBS ကို အရမ်းကြိုက်ပေမယ့် သူ့ရဲ့စွမ်းဆောင်ရည်ကို...

Rook

Rook သည် open source လည်းဖြစ်ပြီး၊ ၎င်းသည် မတူညီသော backends များဖြင့် ရှုပ်ထွေးသောသိုလှောင်မှုစီမံခန့်ခွဲခြင်းလုပ်ငန်းဆောင်တာများကို လုပ်ဆောင်ပေးသည့် သိုလှောင်မှုစီစဉ်ပေးသူဖြစ်ပြီး၊ ဥပမာအားဖြင့် စာရင်းရှိအခြားရွေးချယ်စရာများနှင့် ကွဲပြားပါသည်။ ceph, EdgeFS နှင့် အခြားအရာများသည် အလုပ်ကို အလွန်ရိုးရှင်းစေသည်။ လွန်ခဲ့တဲ့လအနည်းငယ်က ကျွန်တော်စမ်းကြည့်တုန်းက EfgeFS နဲ့ ပြဿနာရှိခဲ့ပြီး Ceph နဲ့ အဓိက စမ်းသပ်ခဲ့ပါတယ်။ Ceph သည် ပိတ်ဆို့သိုလှောင်မှုကို ပေးစွမ်းရုံသာမက S3/Swift နှင့် ဖြန့်ဝေထားသော ဖိုင်စနစ်နှင့် တွဲဖက်အသုံးပြုနိုင်သည့် အရာဝတ္ထုသိုလှောင်မှုလည်း ပါဝင်သည်။ Ceph နှင့်ပတ်သက်ပြီး ကျွန်တော်နှစ်သက်သည်မှာ ဒေတာအများအပြားကို ဒစ်ခ်များစွာတွင် ဖြန့်ကျက်ပေးနိုင်သောကြောင့် volume သည် ဒစ်တစ်ခုတည်းတွင် အံဝင်ခွင်ကျမဖြစ်နိုင်သော disk space ပိုများနိုင်သည်။ အဆင်ပြေတယ်။ နောက်ထပ်ထူးခြားချက်တစ်ခုကတော့ သင်က disk တွေကို အစုလိုက်အပြုံလိုက်ထည့်လိုက်တာနဲ့ disks အားလုံးမှာ ဒေတာတွေကို အလိုအလျောက် ပြန်လည်ဖြန့်ဝေပေးပါတယ်။

Ceph တွင် လျှပ်တစ်ပြက်ရိုက်ချက်များ ရှိသော်လည်း ကျွန်ုပ်သိသလောက်၊ ၎င်းတို့ကို Rook/Kubernetes တွင် တိုက်ရိုက်အသုံးမပြုနိုင်ပါ။ မှန်ပါတယ်၊ ကျွန်တော် ဒီထဲကို နက်နက်နဲနဲ မဝင်ခဲ့ပါဘူး။ သို့သော် ဆိုက်ပြင်ပတွင် အရန်ကူးယူမှုများ မရှိသောကြောင့် သင်သည် Velero/Restic နှင့် တစ်ခုခုကို အသုံးပြုရမည်ဖြစ်ပြီး၊ သို့သော် အချိန်နှင့်တပြေးညီ လျှပ်တစ်ပြက်ရိုက်ချက်များမဟုတ်ဘဲ ဖိုင်အဆင့် အရန်သိမ်းဆည်းမှုများသာ ရှိပါသည်။ Rook နဲ့ ပတ်သက်ပြီး ကျွန်တော် တကယ်ကြိုက်ခဲ့တာက Ceph နဲ့ အလုပ်လုပ်ရတာ ဘယ်လောက်လွယ်လဲ - ရှုပ်ထွေးတဲ့အရာတွေအားလုံးကို ဖုံးကွယ်ထားပြီး ပြဿနာဖြေရှင်းခြင်းအတွက် Ceph နဲ့ တိုက်ရိုက်စကားပြောနိုင်တဲ့ Tools တွေကို ပေးထားပါတယ်။ ကံမကောင်းစွာဖြင့်၊ Ceph volumes ၏ ဖိစီးမှုစမ်းသပ်မှုအတွင်း၊ ကျွန်ုပ်သည် ပြဿနာများ ဆက်ရှိနေပါသည်။ ဒီပြဿနာCeph သည် မတည်မငြိမ်ဖြစ်စေသည်။ ၎င်းသည် Ceph ကိုယ်တိုင်၌ ချို့ယွင်းချက်ဟုတ်မဟုတ် သို့မဟုတ် Rook က Ceph စီမံခန့်ခွဲပုံတွင် ပြဿနာရှိမရှိ ရှင်းရှင်းလင်းလင်း မသိရသေးပါ။ မန်မိုရီဆက်တင်များကို တွေးခေါ်ကြည့်မိတော့ ပိုကောင်းလာသော်လည်း ပြဿနာကို လုံးလုံးမဖြေရှင်းနိုင်ခဲ့ပါ။ Ceph သည် အောက်ဖော်ပြပါ စံနှုန်းများတွင် တွေ့ရသည့်အတိုင်း လျောက်ပတ်သော စွမ်းဆောင်ရည်ရှိသည်။ ကောင်းမွန်တဲ့ ဒက်ရှ်ဘုတ်လည်း ပါရှိပါတယ်။

Rancher Longhorn

Longhorn ကို အရမ်းကြိုက်တယ်။ ကျွန်တော့်အမြင်အရတော့ ဒါက အလားအလာရှိတဲ့ အဖြေတစ်ခုပါ။ မှန်ပါသည်၊ developer များကိုယ်တိုင် (Rancher Labs) က ၎င်းသည် လုပ်ငန်းခွင်ပတ်ဝန်းကျင်အတွက် မသင့်လျော်သေးကြောင်း ဝန်ခံပြီး ယင်းက ဖော်ပြသည်။ ၎င်းသည် open source ဖြစ်ပြီး လျောက်ပတ်သော စွမ်းဆောင်ရည် ရှိသည် (၎င်းတို့ကို optimized မလုပ်ရသေးသော်လည်း)၊ သို့သော် volume များသည် pod သို့ ချိတ်ဆက်ရန် အလွန်အချိန်ယူရပြီး အဆိုးဆုံးအခြေအနေများတွင်၊ အထူးသဖြင့် ကြီးမားသော အရန်သိမ်းမှုကို ပြန်လည်ရယူပြီးနောက် သို့မဟုတ် အဆင့်မြှင့်တင်ပြီးနောက် 15-16 မိနစ်ကြာပါသည်။ အလုပ်ဝန်။ ၎င်းတွင် ဤလျှပ်တစ်ပြက်ရိုက်ချက်များ၏ လျှပ်တစ်ပြက်ရိုက်ချက်များနှင့် ဆိုက်ပြင်ပမှ အရန်ကူးများပါရှိသော်လည်း ၎င်းတို့သည် volumes များနှင့်သာ သက်ဆိုင်သောကြောင့် အခြားအရင်းအမြစ်များကို မိတ္တူကူးရန်အတွက် Velero ကဲ့သို့သော အရာတစ်ခု လိုအပ်နေသေးသည်။ အရန်သိမ်းခြင်းနှင့် ပြန်လည်ရယူခြင်းသည် အလွန်ယုံကြည်စိတ်ချရသော်လည်း မတော်တရော် နှေးကွေးသည်။ အလေးအနက်ပြောရရင် မယုံနိုင်လောက်အောင် နှေးကွေးပါတယ်။ Longhorn တွင် အလယ်အလတ်ဒေတာပမာဏတစ်ခုဖြင့် အလုပ်လုပ်သောအခါ CPU အသုံးပြုမှုနှင့် စနစ် load သည် မကြာခဏ တိုးတတ်ပါသည်။ Longhorn ကိုစီမံခန့်ခွဲရန် အဆင်ပြေသော ဒက်ရှ်ဘုတ်တစ်ခုရှိသည်။ Longhorn ကို ကြိုက်တယ် လို့ ပြောပြီးပြီ ၊ ဒါပေမယ့် အလုပ် တော့ လိုအပ် ပါတယ် ။

StorageOS

StorageOS သည် စာရင်းတွင် ပထမဆုံး အခပေး ထုတ်ကုန်ဖြစ်သည်။ ၎င်းတွင် အကန့်အသတ်ရှိသော သိုလှောင်မှုပမာဏ 500GB ရှိသော developer ဗားရှင်းတစ်ခုပါရှိသော်လည်း node အရေအတွက်အပေါ် ကန့်သတ်ချက်မရှိဟု ကျွန်ုပ်မထင်ပါ။ မှန်ကန်စွာမှတ်မိပါက 125 TB အတွက် ကုန်ကျစရိတ်သည် တစ်လလျှင် $1 မှ စတင်သည်ဟု အရောင်းဌာနက ပြောပါသည်။ အခြေခံ ဒက်ရှ်ဘုတ်နှင့် အဆင်ပြေသော CLI ပါရှိသော်လည်း စွမ်းဆောင်ရည်နှင့် ပတ်သက်၍ ထူးဆန်းသည်မှာ တစ်ခုခုတော့ ဖြစ်နေသည်- အချို့သော စံနှုန်းများတွင် ၎င်းသည် အတော်လေး ကောင်းမွန်သော်လည်း volume stress test တွင် ကျွန်ုပ်သည် မြန်နှုန်းကို လုံးဝမကြိုက်ပါ။ ယေဘုယျအားဖြင့်တော့ ဘာပြောရမှန်းမသိဘူး။ ဒါကြောင့် ကျွန်တော် သိပ်နားမလည်ခဲ့ပါဘူး။ ဤနေရာတွင် ဆိုက်ပြင်ပ မိတ္တူကူးယူမှုများ မရှိတော့ဘဲ အတွဲများကို အရန်ကူးရန်အတွက် Restic နှင့် Velero ကို အသုံးပြုရပါမည်။ ထုတ်ကုန်က အခကြေးငွေရတဲ့အတွက် ထူးဆန်းပါတယ်။ developer များသည် Slack နှင့် ဆက်သွယ်ရန် စိတ်အားထက်သန်ခြင်းမရှိပါ။

ရော်ဘင်

သူတို့ရဲ့နည်းပညာဒါရိုက်တာကနေ Reddit မှာ Robin အကြောင်း လေ့လာခဲ့တယ်။ ကျွန်တော် သူ့အကြောင်း တစ်ခါမှ မကြားဖူးဘူး။ အခမဲ့ဖြေရှင်းနည်းတွေကို ရှာနေပေမယ့် ရော်ဘင်က အခကြေးငွေရတာကြောင့် ဖြစ်နိုင်ပါတယ်။ ၎င်းတို့တွင် သိုလှောင်မှု 10TB နှင့် node သုံးခုပါသော အခမဲ့ဗားရှင်းတစ်ခုရှိသည်။ ယေဘုယျအားဖြင့်၊ ထုတ်ကုန်သည်အတော်လေးသင့်လျော်ပြီးကောင်းမွန်သောအင်္ဂါရပ်များရှိသည်။ ကောင်းမွန်တဲ့ CLI တစ်ခုရှိပါတယ်၊ ဒါပေမယ့် အအေးဆုံးအချက်ကတော့ အပလီကေးရှင်းတစ်ခုလုံးကို လျှပ်တစ်ပြက်ရိုက်ပြီး အရန်ကူးနိုင်တာ (အရင်းအမြစ်ရွေးချယ်မှုမှာ ဒါကို Helm releases သို့မဟုတ် “flex apps” လို့ခေါ်ပါတယ်)၊ volumes နဲ့ အခြားအရင်းအမြစ်များအပါအဝင် သင် Velero မပါဘဲ လုပ်ဆောင်နိုင်ပါတယ်။ အသေးစိတ်အသေးစိတ်တစ်ခုအတွက်မဟုတ်ပါက၊ အကယ်၍ သင်သည် (သို့မဟုတ် Robin တွင်ခေါ်ထားသည့်အတိုင်း) ပြန်လည်ထူထောင်မည်ဆိုပါက၊ အစုအဖွဲ့အသစ်တစ်ခုပေါ်ရှိ အက်ပလီကေးရှင်းတစ်ခုအား ပြန်လည်ရယူပါက၊ ဥပမာ၊ ဘေးအန္တရာယ်မှ ပြန်လည်ထူထောင်ရေးကိစ္စတွင် ပြန်လည်ထူထောင်ရေး၊ ဟုတ်ပါတယ်၊ အလုပ်လုပ်ပါတယ်၊ ဒါပေမယ့် လျှောက်လွှာကို အရန်သိမ်းဖို့ တားမြစ်ထားပါတယ်။ developer များက အတည်ပြုထားသောကြောင့် ဤဖြန့်ချိမှုတွင် ၎င်းသည် ရိုးရိုးရှင်းရှင်း မဖြစ်နိုင်ပါ။ အထူးသဖြင့် အခြားသော အားသာချက်များ (ဥပမာ၊ မယုံနိုင်လောက်အောင် မြန်ဆန်သော အရန်သိမ်းဆည်းမှုများနှင့် ပြန်လည်ရယူခြင်း) ကို ထည့်သွင်းစဉ်းစားရန်၊ အထူးသဖြင့် ပေါ့ပေါ့ပါးပါး၊ ထူးဆန်းသည်ဟု ဆိုရပေမည်။ developer များသည် နောက်ထွက်ရှိမှုတွင် အရာအားလုံးကို ပြုပြင်ပေးမည်ဟု ကတိပြုပါသည်။ စွမ်းဆောင်ရည်သည် ယေဘူယျအားဖြင့် ကောင်းမွန်သော်လည်း ထူးထူးခြားခြားတစ်ခု သတိပြုမိသည်- အကယ်၍ host နှင့် ချိတ်ဆက်ထားသော volume တွင် စံနှုန်းကို တိုက်ရိုက် run ပါက၊ read speed သည် pod အတွင်းမှ တူညီသော volume ကို run သည်ထက် များစွာ ပိုမြန်ပါသည်။ အခြားရလဒ်အားလုံးသည် တူညီသော်လည်း သီအိုရီအရ ကွာခြားမှု မရှိသင့်ပါ။ ၎င်းတို့က ၎င်းကို လုပ်ဆောင်နေသော်လည်း ပြန်လည်ရယူခြင်းနှင့် အရန်သိမ်းဆည်းခြင်းဆိုင်ရာ ပြဿနာအတွက် ကျွန်ုပ်စိတ်မကောင်းဖြစ်မိသည် - နောက်ဆုံးတွင် သင့်လျော်သောဖြေရှင်းချက်ကို ရှာတွေ့ပြီဟု ထင်မှတ်ကာ နေရာပို သို့မဟုတ် ဆာဗာများ လိုအပ်သည့်အခါတွင်ပင် ၎င်းအတွက် ပေးဆောင်ရန် ဆန္ဒရှိနေပါသည်။

နင်

ဒီမှာပြောစရာအများကြီးမရှိပါဘူး။ ဤသည်မှာ အခကြေးငွေပေးရသည့် ထုတ်ကုန်တစ်ခုဖြစ်ပြီး အညီအမျှ အေးပြီး ဈေးကြီးသည်။ စွမ်းဆောင်ရည်က ရိုးရှင်းပါတယ်။ ဤသည်မှာ ယခုအချိန်အထိ အကောင်းဆုံးညွှန်ပြချက်ဖြစ်သည်။ Google ၏ GKE Marketplace တွင်ဖော်ပြထားသည့်အတိုင်း ဈေးနှုန်းသည် node တစ်ခုလျှင် တစ်လလျှင် $205 မှစတင်သည်ဟု Slack မှပြောပါသည်။ တိုက်ရိုက်ဝယ်ရင် ပိုသက်သာမလားမသိဘူး။ မည်သို့ပင်ဆိုစေကာမူ ကျွန်ုပ်မတတ်နိုင်ပါ၊ ထို့ကြောင့် ဆော့ဖ်ဝဲရေးသားသူလိုင်စင် (1 TB နှင့် 3 nodes အထိ) သည် Kubernetes တွင် လက်တွေ့အားဖြင့် အသုံးမဝင်သည့်အတွက် အလွန်စိတ်ပျက်မိပါသည်။ အစမ်းသုံးကာလအဆုံးတွင် အသံအတိုးအကျယ်လိုင်စင်ကို ဆော့ဖ်ဝဲအင်ဂျင်နီယာထံ အလိုအလျောက် အဆင့်နှိမ့်ပေးမည်ဟု မျှော်လင့်ခဲ့သော်လည်း ထိုသို့ဖြစ်မလာပါ။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာလိုင်စင်ကို Docker နှင့်သာ တိုက်ရိုက်အသုံးပြုနိုင်ပြီး Kubernetes တွင် ဖွဲ့စည်းမှုပုံစံသည် အလွန်ခက်ခဲပြီး အကန့်အသတ်ရှိသည်။ ဟုတ်ပါတယ်၊ ငါက open source ကိုကြိုက်တယ်၊ ဒါပေမယ့် ငါ့မှာ ပိုက်ဆံရှိရင် Portworx ကို ငါသေချာပေါက် ရွေးလိမ့်မယ်။ ယခုအချိန်အထိ ၎င်း၏စွမ်းဆောင်ရည်သည် အခြားရွေးချယ်စရာများနှင့် နှိုင်းယှဉ်ခြင်းမရှိပေ။

Linstor

စာဖတ်သူတစ်ယောက်က Linstor ကိုစမ်းသုံးကြည့်ဖို့ အကြံပြုတဲ့အခါ ပို့စ်ကို ထုတ်ဝေပြီးနောက် ဒီအပိုင်းကို ထည့်လိုက်တယ်။ ကျွန်တော်စမ်းကြည့်တော့ ကြိုက်တယ်။ ဒါပေမယ့် နက်နက်နဲနဲ တူးဖို့ လိုပါသေးတယ်။ အခု ကျွန်တော်ပြောနိုင်တာက စွမ်းဆောင်ရည်က မဆိုးပါဘူး (ကျွန်တော် အောက်မှာ စံနှုန်းရလဒ်တွေကို ထည့်ထားပါတယ်)။ အခြေခံအားဖြင့်၊ ကျွန်ုပ်သည် အပေါ်မှမပါဘဲ ဒစ်ခ်နှင့် တိုက်ရိုက်တူညီသော စွမ်းဆောင်ရည်ကို ရရှိခဲ့သည်။ (Porworx သည် drive benchmark ထက် တိုက်ရိုက် ပိုမိုကောင်းမွန်သော နံပါတ်များ အဘယ်ကြောင့် ရှိသည်ကို မမေးပါနှင့်။ ကျွန်တော် မပြောတတ်ပါ။ မျက်လှည့်ဖြင့် ထင်ပါသည်။) ထို့ကြောင့် Linstor သည် အလွန်ထိရောက်ပုံရသည်။ တပ်ဆင်ရန် သိပ်မခက်သော်လည်း အခြားရွေးချယ်စရာများကဲ့သို့ မလွယ်ကူပါ။ ပထမဦးစွာ ကျွန်ုပ်သည် Linstor (kernel module နှင့် tools/services) ကို ထည့်သွင်းပြီး Kubernetes ၏ အပြင်ဘက်ရှိ လျှပ်တစ်ပြက် ပံ့ပိုးမှုနှင့် လျှပ်တစ်ပြက် ပံ့ပိုးမှုအတွက် LVM ကို စီစဉ်သတ်မှတ်ကာ၊ ထို့နောက် Kubernetes မှ သိုလှောင်မှုအသုံးပြုရန် လိုအပ်သော အရင်းအမြစ်များကို ဖန်တီးပါ။ CentOS မှာ အလုပ်မလုပ်တဲ့အတွက် Ubuntu ကို သုံးရတာကို မကြိုက်ပါဘူး။ ကြောက်မက်ဘွယ်မဟုတ်ပေ၊ သို့သော် အနည်းငယ် စိတ်အနှောင့်အယှက်ဖြစ်စရာ၊ အကြောင်းမှာ စာရွက်စာတမ်း (နည်းလမ်းအားဖြင့် အလွန်ကောင်းမွန်သည်) သည် သတ်မှတ်ထားသော Epel repositories များတွင် ရှာမတွေ့နိုင်သော ပက်ကေ့ဂျ်များစွာကိုဖော်ပြထားသောကြောင့်ဖြစ်သည်။ Linstor တွင် လျှပ်တစ်ပြက်ရိုက်ချက်များ ရှိသော်လည်း ဆိုက်ပြင်ပ အရန်ကူးခြင်းမျိုး မဟုတ်ဘဲ၊ ထို့ကြောင့် အတွဲများကို အရန်ကူးရန်အတွက် Restic နှင့် Velero ကို ထပ်မံအသုံးပြုခဲ့ရပါသည်။ ဖိုင်အဆင့် မိတ္တူကူးခြင်းအစား လျှပ်တစ်ပြက်ရိုက်ချက်များကို ပိုနှစ်သက်သည်၊ သို့သော် ဖြေရှင်းချက်သည် စွမ်းဆောင်ရည်ရှိပြီး ယုံကြည်စိတ်ချရပါက ၎င်းကို သည်းခံနိုင်သည်။ Linstor သည် open source ဖြစ်သော်လည်း အခကြေးငွေဖြင့် ပံ့ပိုးပေးထားသည်။ ကျွန်ုပ်မှန်ကန်စွာနားလည်ပါက၊ သင့်တွင် ထောက်ပံ့ရေးစာချုပ်မရှိပါက ကန့်သတ်ချက်များမရှိဘဲအသုံးပြုနိုင်သော်လည်း ၎င်းကိုရှင်းလင်းရန်လိုအပ်ပါသည်။ Linstor သည် Kubernetes အတွက် မည်ကဲ့သို့ စမ်းသပ်ထားသည်ကို ကျွန်ုပ်မသိပါ၊ သို့သော် သိုလှောင်မှုအလွှာသည် Kubernetes ၏ အပြင်ဘက်တွင်ရှိပြီး ယမန်နေ့က ဖြေရှင်းချက်မပေါ်ခဲ့သဖြင့် ၎င်းကို လက်တွေ့အခြေအနေတွင် စမ်းသပ်ထားပြီးဖြစ်ကောင်းဖြစ်နိုင်သည်။ ကျွန်ုပ်ကို စိတ်ပြောင်းပြီး Kubernetes သို့ ပြန်သွားရန် ဤနေရာတွင် ဖြေရှင်းချက်ရှိပါသလား။ ကျွန်တော်မသိပါဘူး။ ကျွန်ုပ်တို့သည် ပိုမိုနက်ရှိုင်းစွာ တူးဆွပြီး ပုံတူပွားမှုကို လေ့လာရန် လိုအပ်နေသေးသည်။ ကြည့်ကျတာပေါ့။ ဒါပေမယ့် first impression ကောင်းတယ်။ ပိုမိုလွတ်လပ်ပြီး အရာသစ်များကို လေ့လာရန် Heroku အစား ကျွန်ုပ်၏ကိုယ်ပိုင် Kubernetes အစုအဝေးများကို အသုံးပြုလိုသည်မှာ သေချာပါသည်။ Linstor သည် အခြားသူများကဲ့သို့ တပ်ဆင်ရန် မလွယ်ကူသောကြောင့်၊ ၎င်းနှင့်ပတ်သက်သည့် ပို့စ်တစ်ခုကို မကြာမီ ရေးပါမည်။

စံနှုန်းများ

ကံမကောင်းစွာဖြင့်၊ နှိုင်းယှဉ်မှုနှင့်ပတ်သက်၍ မှတ်သားစရာများစွာကို ကျွန်ုပ်ရေးမည်မဟုတ်သောကြောင့်၊ ကျွန်ုပ်တွင် အခြေခံ fio စံသတ်မှတ်ချက်များမှ ရလဒ်များနှင့် တစ်ခုတည်းသော node အစုအဝေးများအတွက်သာ ရှိပါသည်၊ ထို့ကြောင့် ကျွန်ုပ်တွင် ထပ်တူပြုထားသော ဖွဲ့စည်းမှုများအတွက် နံပါတ်များ မရှိသေးပါ။ ဒါပေမယ့် ဒီရလဒ်တွေကနေ ရွေးချယ်စရာတစ်ခုစီကနေ ဘာကိုမျှော်လင့်ရမလဲဆိုတဲ့ အကြမ်းဖျင်း စိတ်ကူးရနိုင်တယ်၊ ဘာကြောင့်လဲဆိုတော့ တူညီတဲ့ cloud ဆာဗာတွေ၊ 4 cores၊ 16 GB RAM နဲ့ စမ်းသပ်ထားတဲ့ volumes အတွက် နောက်ထပ် 100 GB disk နဲ့ နှိုင်းယှဉ်ထားလို့ပါပဲ။ ဖြေရှင်းချက်တစ်ခုစီအတွက် စံနှုန်းများကို သုံးကြိမ်လုပ်ဆောင်ခဲ့ပြီး ပျမ်းမျှရလဒ်ကို တွက်ချက်ကာ ထုတ်ကုန်တစ်ခုစီအတွက် ဆာဗာဆက်တင်များကို ပြန်လည်သတ်မှတ်ခဲ့သည်။ ဤအရာအားလုံးသည် သိပ္ပံနည်းကျမဟုတ်ပါ၊ သင့်အား ယေဘူယျအကြံဥာဏ်တစ်ခုပေးရန်သာဖြစ်သည်။ အခြားစမ်းသပ်မှုများတွင် ကျွန်ုပ်သည် စာဖတ်ခြင်းနှင့် စာရေးခြင်းအား စမ်းသပ်ရန်အတွက် အသံအတိုးအကျယ်မှ 38 GB ဓာတ်ပုံနှင့် ဗီဒီယိုများကို ကူးယူခဲ့သော်လည်း ဖြစ်ချင်တော့ နံပါတ်များကို မသိမ်းဆည်းခဲ့ပါ။ အတိုချုပ်ပြောရရင် Portworkx က ပိုမြန်တယ်။

အသံအတိုးအကျယ် စံညွှန်းအတွက် ဤဖော်ပြချက်ကို ကျွန်ုပ်အသုံးပြုခဲ့သည်-

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

ကျွန်ုပ်သည် သင့်လျော်သောသိုလှောင်မှုအတန်းအစားဖြင့် အသံအတိုးအကျယ်ကို ဦးစွာဖန်တီးခဲ့ပြီး နောက်ကွယ်မှ fio နှင့် အလုပ်အား လုပ်ဆောင်ခဲ့သည်။ စွမ်းဆောင်ရည်ကို ခန့်မှန်းဖို့ 1 GB ကိုယူခဲ့ပြီး သိပ်အကြာကြီးမစောင့်ပါဘူး။ ဤသည်မှာ ရလဒ်များဖြစ်သည်-

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

ကောက်ချက်

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

source: www.habr.com