ယခုအချိန်အထိ Microsoft ၏ Azure cloud ဝန်ဆောင်မှု၏ on-premise အကောင်အထည်ဖော်မှုဖြစ်သော Microsoft Azure Stack HCI အကြောင်းကို ကျွန်ုပ်တို့ နက်နက်ရှိုင်းရှိုင်း လေ့လာ ပြီးပါပြီ ။ Azure Stack HCI ကို အကောင်းဆုံးကမ္ဘာနှစ်ခုလုံး၏ အမျိုးအစား platform အဖြစ် ရှုမြင်နိုင်ပါသည်။ ၎င်းတွင် Azure Monitor၊ Azure Security Center၊ Azure Update Management၊ Azure Network Adapter နှင့် Azure Site Recovery ကဲ့သို့သော Azure မှ စီမံခန့်ခွဲမှု tools အားလုံးပါဝင်ပြီး on-prem data များကို ထည့်သွင်းထားပြီး သတ်မှတ်ထားသော စည်းမျဉ်းများနှင့် ကိုက်ညီပါသည်။ Azure Stack HCI ကို software defined architecture၊ Azure services နှင့် hardware ဟူ၍ အပိုင်းသုံးပိုင်း ခွဲခြားထားသည်။
“ Microsoft Azure Stack HCI မှာ Hardware ရဲ့ အရေးပါမှု ” ဆောင်းပါးမှာ အသေးစိတ်ဖော်ပြထားတဲ့အတိုင်း မှန်ကန်တဲ့ hardware ကို ရွေးချယ်ခြင်းဟာ အရေးကြီးပါတယ်။ Azure Stack HCI ကို ဖြန့်ကျက်ဖို့အတွက် ပထမခြေလှမ်းကတော့ အသိအမှတ်ပြု hardware ရောင်းချသူကို ရှာဖွေဖို့ပါပဲ။ ဒီကိစ္စမှာတော့ DataON ပါ။ DataON ဟာ Microsoft နဲ့ Intel နှစ်ခုလုံးနဲ့ နှစ်ပေါင်းများစွာ ခိုင်မာတဲ့ မိတ်ဖက်ဆက်ဆံရေး ရှိခဲ့ပြီး Intel Select configuration မှာ Azure Stack HCI အတွက် hardware layout မှာ ဒီမိတ်ဖက်ဆက်ဆံရေးကို အပြည့်အဝ အကောင်အထည်ဖော်နိုင်ခဲ့ပါတယ်။ Intel နဲ့ မိတ်ဖက်ဆက်ဆံရေးရဲ့ စိတ်ဝင်စားစရာကောင်းတဲ့ ရှုထောင့်တစ်ခုကတော့ ကုမ္ပဏီရဲ့ PMEM (နဲ့ သူ့ရဲ့ နောက်ဆုံးပေါ် processor တွေ) ကို Azure Stack HCI နဲ့ အသုံးချနိုင်စွမ်းပါပဲ။
DataON HCI Intel Select ဖြေရှင်းချက်များကို များစွာသောကိစ္စများတွင် configure လုပ်ပြီး ၎င်းတို့၏ကိုယ်ပိုင် rack တွင် ပို့ဆောင်ပေးထားပြီး ချက်ချင်းဖြန့်ကျက်ရန် အသင့်ဖြစ်နေပါသည်။ ဤပေးပို့မှုနည်းလမ်းသည် လက်ရှိ IT အခြေခံအဆောက်အအုံ အကန့်အသတ်ရှိသော သို့မဟုတ် မရှိသည့် edge တွင် အထူးအသုံးဝင်ပါသည်။ StorageReview lab တွင်၊ ကျွန်ုပ်တို့သည် အောက်တွင်ဖော်ပြထားသည့်အတိုင်း storage နှင့် compute node လေးခု၊ domain controller နှင့် switch များကို ဖြန့်ကျက်ခဲ့ပါသည်။
တည်ဆောက်ခြင်းနှင့်ဒီဇိုင်းဆွဲခြင်း
ကျွန်ုပ်တို့သုံးသပ်ခဲ့သော Microsoft Azure Stack HCI cluster ကို DataON HCI-224 All Flash NVMe platform ပေါ်တွင်တည်ဆောက်ထားသည်။ ဤဆာဗာများသည် 2U အရွယ်အစားရှိပြီး ရှေ့တွင် 24-NVMe bays များပါရှိသောကြောင့် PCIe-based components များအတွက် နောက်ဘက်တွင် တိုးချဲ့မှုများစွာကို ပေးစွမ်းသည်။ matte-black drive caddies များနှင့်မတူဘဲ labeling သည် မြင့်မားသောကြောင့် လဲလှယ်ရန်အချိန်ရောက်လာပါက သီးခြား drives များကို အလွယ်တကူရှာဖွေနိုင်သည်။ အရာအားလုံးကို labeled လုပ်ထားပြီး ၎င်းသည် သိပ်မထူးဆန်းသော်လည်း labeling ၏အတိုင်းအတာမှာ များပြားသည်။ ကျွန်ုပ်တို့၏ deployment တွင် node တစ်ခုစီ (1 မှ 4) ကို labeled လုပ်ထားပြီး datacenter တွင် deploy နှင့် manage လုပ်ရန်လွယ်ကူစေသည့် အခြားအရာများစွာရှိသည်။
ကျွန်ုပ်တို့၏ configuration တွင် NVMe SSD ၄၈ ခု သို့မဟုတ် node တစ်ခုလျှင် ၁၂ ခု ပါရှိသည်။ ၎င်းတို့တွင် 375GB Intel Optane P4800X SSD လေးခုနှင့် Intel P4510 2TB SSD ရှစ်ခု ပါဝင်သည်။
နောက်ဘက်မှာ dual-port 100G Mellanox Connect-X 5 NIC နှစ်ခုပါရှိပြီး cluster network traffic အတွက် Mellanox 100G switches (SN2100) နှစ်ခုမှတစ်ဆင့် fully redundant connection ကို ပံ့ပိုးပေးပါတယ်။ ကျွန်တော်တို့ရဲ့ စတူဒီယိုဓာတ်ပုံတွေမှာ deployment stage မှာ error ကင်းတဲ့ cabling ဖြစ်အောင် သင့်တော်တဲ့ network cable ရဲ့ အဆုံးတစ်ဖက်စီမှာ label အပြည့်အစုံပါတဲ့ ချိတ်ဆက်မှုအားလုံးကို မပြသထားပါဘူး။
ဒီ့မတိုင်ခင်မှာ ဒီလိုစာရွက်စာတမ်းအဆင့်နဲ့ ဖြေရှင်းချက်တစ်ခုမှ label ထဲမှာ မပါဝင်ခဲ့ဖူးပါဘူး။ Microsoft နဲ့ DataON တို့က Azure Stack ကို တပ်ဆင်ရာမှာ လွယ်ကူတဲ့ လုပ်ငန်းစဉ်တစ်ခု ဖြစ်စေတာကြောင့် ဖောက်သည်တွေ ချက်ချင်း အလုပ်လုပ်နိုင်ပါတယ်။ ကြိုးတစ်ချောင်းချင်းစီကို သီးခြားအသုံးပြုမှုအတွက် အရောင်ကုဒ်တွေနဲ့ အမှတ်အသားပြုထားပြီး အဆုံးတစ်ခုစီကို ဘယ်နေရာကို ရောက်သွားမလဲဆိုတာကို အမှတ်အသားပြုထားပါတယ်။ DataON က ဖောက်သည်တွေကို ပေးအပ်တဲ့ စိတ်ကြိုက်စာရွက်နဲ့ ပေါင်းစပ်လိုက်တဲ့အခါ အမှားအယွင်းကင်းတဲ့ တပ်ဆင်မှုကို အာမခံပါတယ်။ ကျွန်တော်တို့ရဲ့ တပ်ဆင်မှုမှာ စနစ်ကို ပို့ဆောင်ခြင်းမပြုမီ IP လိပ်စာတွေနဲ့ ကြိုတင် configure လုပ်ထားပြီး စီမံခန့်ခွဲမှုအတွက် IP လိပ်စာတွေနဲ့ IPMI လိပ်စာတွေကို label လုပ်ထားပါတယ်။
စီမံခန့်ခွဲမှုနှင့် အသုံးပြုနိုင်မှု
Windows Server မှာ လည်ပတ်နေတဲ့ Hyper-V ဆိုင်ကို ဝယ်ယူသူတွေအတွက် Microsoft Azure Stack HCI ဟာ လွယ်ကူတဲ့ အသွင်ကူးပြောင်းမှုတစ်ခု ဖြစ်ပါလိမ့်မယ်။ တူညီတဲ့ စီမံခန့်ခွဲမှုကိရိယာတွေ အများအပြား ရှိနေပြီး၊ အများစုဟာ ပိုမိုပေါင်းစပ်ပြီး ရိုးရှင်းတဲ့ workflow ကို ပေးဆောင်ပါတယ်။ ကျွန်ုပ်တို့ရဲ့ ပြန်လည်သုံးသပ်ချက် လုပ်ငန်းစဉ်မှာ DataOn HCI Cluster ကို စီမံခန့်ခွဲဖို့ Windows Failover Cluster Manager နဲ့ workloads တွေကို စောင့်ကြည့်ပြီး သူတို့ရဲ့ စွမ်းဆောင်ရည်ကို ကြည့်ရှုဖို့ Windows Admin Center နှစ်ခုလုံးကို အသုံးပြုခဲ့ပါတယ်။
node တစ်ခုထဲသို့ Microsoft Remote Desktop (RDP) session တစ်ခုဝင်ရောက်ခြင်းဖြင့် node level ကို ဦးစွာကြည့်ရှုပြီးနောက် Windows Failover Cluster Manager ကို ကျွန်ုပ်တို့ကြည့်ရှုခဲ့ပါသည်။ ၎င်းသည် node-level management capabilities များအပြင် cluster-level visibility နှစ်မျိုးလုံးကို ပေးစွမ်းသည်။ ဤ access အမျိုးအစားသည် Windows Admin Center မှ နေ့စဉ်စောင့်ကြည့်ခြင်းကို လုပ်ဆောင်မည့် ကနဦး deployment အတွက် ပိုမိုအာရုံစိုက်မည်ဖြစ်သည်။
ပထမဦးစွာ၊ ကျွန်ုပ်တို့၏ cluster တစ်ခုကို နှိပ်ပြီး ၎င်းနှင့်ပတ်သက်သည့် အထွေထွေအချက်အလက်များ၊ ၎င်းကို configure လုပ်နိုင်စွမ်းနှင့် resource များကို ကြည့်ရှုခြင်းတို့ကို ရယူပါသည်။ ၎င်းသည် ရွေးချယ်ထားသော cluster ၏ အကျဉ်းချုပ်မြင်ကွင်းကို ပေးစွမ်းပြီး ပြဿနာများရှိနေသည့်နေရာကို မြင်တွေ့နိုင်ပြီး သတ်မှတ်ထားသောနေရာများသို့ စတင်ဝင်ရောက်ကြည့်ရှုနိုင်စေပါသည်။
နောက်တစ်ခုက failover roles တွေပါ။ ဒီမှာ cluster မှာ run နေတဲ့ Hyper-V VM အားလုံးကို မြင်နိုင်ပါတယ်။ cluster ကို stress testing အတွက် ကျွန်တော်တို့အသုံးပြုခဲ့တဲ့ vmfleet VM အများအပြားကို ပြသထားပါတယ်။
ကွန်ရက်များက မည်သည့် cluster network များ ရရှိနိုင်သည်နှင့် တစ်ခုချင်းစီ၏ အခြေအနေကို ကြည့်ရှုနိုင်စေပါသည်။ cluster network တစ်ခုကို ရွေးချယ်ခြင်းဖြင့် ၎င်းနှင့်ဆက်စပ်နေသော အခြေခံ network card နှင့် ၎င်း၏ IP address ကို မြင်တွေ့နိုင်စေပါသည်။
storage option အောက်မှာ Disks, Pools, နဲ့ Enclosures တွေရှိပါတယ်။ Disks အတွက် virtual disks တွေကို နှိပ်ပြီး status, assign လုပ်ထားတဲ့နေရာ, owner node, disk number, partition style, နဲ့ capacity စတဲ့ အချက်အလက်တွေကို ရယူနိုင်ပါတယ်။ အသုံးပြုသူတွေဟာ Pool ID, name, နဲ့ description - Virtual Disk ID, name, and description, health and operational status, and resiliency စတဲ့ အချက်အလက်တွေကို ပိုမိုနက်ရှိုင်းစွာ လေ့လာနိုင်ပါတယ်။
Pool များသည် အလားတူဖြစ်ပြီး အခြေအနေ၊ ကျန်းမာရေး၊ ပိုင်ရှင် node၊ လည်ပတ်မှုအခြေအနေများနှင့် အလုံးစုံစွမ်းရည်ကဲ့သို့သော အချို့သော storage pool များ၏ အချက်အလက်များအပြင် အခမဲ့နှင့် အသုံးပြုပြီးသော နေရာလွတ်များလည်း ပါဝင်သည်။
Nodes အောက်တွင်၊ cluster ရှိ node အားလုံးနှင့် ၎င်းတို့၏ status ကို အလွယ်တကူ မြင်နိုင်သည်။
ညာဘက်မှာ failover disk တွေကို ပြောင်းပြီး အောက်ခြေမှာရှိတဲ့ node တစ်ခုအတွက် သီးခြား disk ကို ကြည့်နိုင်ပါတယ်။
တူညီသော sidebar မှလည်း ပေးထားသော node အတွက် network ကို ကြည့်ရှုနိုင်သည်။
Windows Failover Cluster Manager ဟာ ပိုပြီး “အသေးစိတ်အချက်အလက်တွေကို အခြေခံတဲ့” စီမံခန့်ခွဲမှုကိရိယာတစ်ခုဖြစ်ပေမယ့်၊ အသုံးပြုသူတွေဟာ Windows Remote Desktop ကနေတစ်ဆင့် server ကိုယ်တိုင် (ဒါမှမဟုတ် cluster နဲ့ ချိတ်ဆက်ထားတဲ့ တခြား server) နဲ့ ချိတ်ဆက်ပြီး အလုပ်လုပ်ဖို့ လိုအပ်ပါတယ်။ ဒီစီမံခန့်ခွဲမှုပုံစံဟာ အသုံးပြုမှုအများစုအတွက် ကောင်းမွန်ပေမယ့် Microsoft က Windows Admin Center လို့ခေါ်တဲ့ platform အသစ်တစ်ခုနဲ့ အရာအားလုံးကို ပိုမိုလွယ်ကူအောင် လုပ်ဆောင်ပေးခဲ့ပါတယ်။ Failover Cluster Manager နဲ့မတူဘဲ၊ Windows Admin Center ဟာ Web Browser ကို အခြေခံထားပြီး အလုပ်ခွင်မှာရှိတဲ့ မည်သည့်ကွန်ပျူတာ (သို့) တက်ဘလက်ကနေမဆို ချိတ်ဆက်ရ ပိုမိုလွယ်ကူစေပါတယ်။ ဒါ့အပြင် ခေတ်မီပြီး အလှအပနဲ့ ခံစားချက်ကို ပေးစွမ်းတာကြောင့် နေ့စဉ်စောင့်ကြည့်ခြင်းကို ပိုမိုပျော်စရာကောင်းတဲ့ အလုပ်တစ်ခု ဖြစ်စေပါတယ်။ Failover Cluster Manager က အလားတူအတိုင်းအတာအထိ မပေးနိုင်တဲ့ activity monitoring ကို ပိုမိုအာရုံစိုက်ပြီး အချက်အလက်အများစုကို လေ့လာကြည့်ရှုနိုင်ပါတယ်။
Windows Admin Center ကို cluster တစ်ခုနဲ့ ချိတ်ဆက်ပြီးတာနဲ့ လုပ်ဆောင်ချက်တွေကို ကြည့်ရှုစီမံခန့်ခွဲဖို့အတွက် သတ်မှတ်ထားတဲ့ နေရာတွေကို လေ့လာနိုင်ပါတယ်။ ဒီမှာ VM တွေ အသုံးပြုနေတဲ့ အရင်းအမြစ်တွေရဲ့ အလုံးစုံကို ခြေရာခံပေးတဲ့ overall cluster compute performance information ကို ကျွန်တော်တို့ မြင်တွေ့နိုင်ပါတယ်။
Windows Admin Center ဟာ လုပ်ဆောင်ချက်တွေကို ကြည့်ရှုဖို့အတွက် အရမ်းကောင်းပေမယ့် သင့်ရဲ့ cluster ထဲက VM တွေနဲ့ အပြန်အလှန် ဆက်သွယ်နိုင်ပါတယ်။ အောက်မှာ vmfleet VM အများအပြားကို ဖွင့်ပြထားပါတယ်။
အသုံးပြုသူများသည် သတ်မှတ်ထားသော VM များအကြောင်း အချက်အလက်များကိုလည်း လေ့လာနိုင်သည်။
အခန်းကဏ္ဍများအောက်တွင်၊ အခန်းကဏ္ဍများအပေါ် ရှုမြင်ပုံ အနည်းငယ်ကွဲပြားသော်လည်း အဓိကအချက်အလက်အများစုမှာ အတူတူပင်ဖြစ်သည်။
setting အောက်မှာ အသုံးပြုသူတွေဟာ Azure အတွက် extension တွေကို download လုပ်၊ install လုပ်၊ update လုပ်နိုင်ပါတယ်။
Windows Admin Center မှတစ်ဆင့် compute နှင့် storage ကို ပိုမိုသေချာစွာကြည့်ရှုရန် Hyper-Converged Cluster Manager ထဲသို့လည်း ဝင်ရောက်နိုင်ပါသည်။ server အရေအတွက်၊ drive များ၊ VM များ၊ volume များအပြင် CPU၊ memory နှင့် storage အသုံးပြုမှုကဲ့သို့သော အထွေထွေအချက်အလက်များပါရှိသော Dashboard ကို ကျွန်ုပ်တို့ ဖွင့်လှစ်ထားပါသည်။ Dashboard ၏အောက်ခြေတွင် သတ်မှတ်ထားသော အချိန်ဘောင်၊ IOPS နှင့် latency အဖြစ် ပိုင်းခြားထားသော cluster စွမ်းဆောင်ရည်ရှိသည်။
compute အောက်တွင်၊ admin များသည် cluster မှ server ကိုဖယ်ရှားခြင်းအပါအဝင် စီမံခန့်ခွဲမှုအတွက် server များကိုကိုယ်တိုင်လေ့လာနိုင်သည်။ ဤနေရာတွင် uptime၊ location၊ domain၊ ထုတ်လုပ်သူ၊ မော်ဒယ်၊ serial number၊ OS name၊ version နှင့် build number ကဲ့သို့သော အသုံးပြုထားသော server အကြောင်း အထွေထွေအချက်အလက်များပါရှိသည်။ ထို့အပြင် user များသည် server တစ်ခုနှင့်သက်ဆိုင်သော performance ကိုကြည့်ရှုနိုင်သည်။
Volumes tab ကို နှိပ်လိုက်ခြင်းအားဖြင့် cluster ရှိ volume အားလုံး၏ အကျဉ်းချုပ်သို့ အသုံးပြုသူများအား ယူဆောင်လာပါသည်။ volume များ၏ ကျန်းမာရေးကို အရောင်ကုဒ်ဖြင့် ဖော်ပြထားပါသည်။ ကျန်းမာသောအတွက် အစိမ်းရောင်၊ အရေးကြီးသောအတွက် အနီရောင်နှင့် သတိပေးချက်အတွက် အဝါရောင်တို့ဖြစ်သည်။ volume အားလုံးအတွက် စွမ်းဆောင်ရည်ကိုလည်း အချိန်ဘောင်နှင့် IOPS၊ latency နှင့် throughput အဖြစ် ခွဲခြားထားသည်။
volume တစ်ခုတည်းထဲကို တူးဆွကြည့်ခြင်းအားဖြင့် status၊ file system၊ path၊ fault domain awareness၊ total size၊ used size၊ resiliency နှင့် footprint အပါအဝင် volume ၏ သီးခြား properties များကို ရရှိမည်ဖြစ်သည်။ ဤနေရာတွင် ပိတ် သို့မဟုတ် ဖွင့်နိုင်သော optional features (deduplication နှင့် compression အပြင် integrity checksums) များ ရှိပါသည်။ capacity ကို graphically ပြသထားပြီး used နှင့် available ကို ပြသထားသည်။ ထို့အပြင် performance ကို ကျွန်ုပ်တို့ မြင်တွေ့ရပါသည်။
Drives tab အောက်မှာ စနစ်ထဲက drive အားလုံးရဲ့ အကျဉ်းချုပ်ကို ရရှိပါတယ်။ ဒီမှာ drive အရေအတွက် စုစုပေါင်းနဲ့ volume တွေနဲ့ အရောင်တူ alerts တွေ ရှိမရှိကို တွေ့ရပါတယ်။ capacity ကိုလည်း ကြည့်နိုင်ပါတယ်- အသုံးပြုပြီးသား၊ ရရှိနိုင်တဲ့ နဲ့ reserve ပါ။
Inventory ကို နှိပ်လိုက်တဲ့အခါ drive အားလုံးရဲ့ စာရင်းနဲ့ အသေးစိတ်အချက်အလက်တွေ အများကြီးကို ရရှိပါတယ်။ အသေးစိတ်အချက်အလက်တွေမှာ drive ရဲ့ အခြေအနေ၊ မော်ဒယ်၊ စွမ်းရည် အရွယ်အစား၊ အမျိုးအစား၊ ဘာအတွက် အသုံးပြုသလဲ နဲ့ အသုံးပြုထားတဲ့ storage ပမာဏတွေ ပါဝင်ပါတယ်။
ကျွန်ုပ်တို့သည် drive တစ်ခုတည်းကို အသေးစိတ်လေ့လာနိုင်ပြီး status၊ location၊ size၊ type၊ used for၊ manufacturer၊ model၊ serial number၊ firmware version နှင့် ၎င်းတွင်ရှိသော storage pool ကဲ့သို့သော properties များကို ကြည့်ရှုနိုင်ပါသည်။ သီးခြား drive အတွက် အသုံးပြုထားသော capacity ပမာဏနှင့် ရရှိနိုင်သော capacity ပမာဏကို IOPS၊ latency နှင့် throughput တို့တွင် ၎င်း၏စွမ်းဆောင်ရည်ကို ကျွန်ုပ်တို့ မြင်တွေ့နိုင်ပါသည်။
စွမ်းဆောင်ရည်အောက်တွင် drive latency နှင့် error စာရင်းအင်းများကိုလည်း မြင်တွေ့နိုင်ပါသည်။
performance
Microsoft Azure Stack ဂေဟစနစ်အတွင်းရှိ စွမ်းဆောင်ရည်သည် Storage Spaces ခေတ်ကတည်းက ထင်ရှားကျော်ကြားခဲ့သော အားသာချက်တစ်ခုဖြစ်သည်။ ထိုအချက်ကို ထည့်သွင်းစဉ်းစားခြင်းဖြင့် ဤပလက်ဖောင်းသည် ဈေးကွက်ရှိ အခြား HCI ဖြေရှင်းချက်များနှင့် မည်မျှကောင်းမွန်သည်ကို အသုံးပြုသူများ မြင်တွေ့နိုင်စေရန်အတွက် ဤသုံးသပ်ချက်တွင် အဖြစ်များသော benchmarking workloads အချို့ကို ကျွန်ုပ်တို့ ကြည့်ရှုခဲ့ပါသည်။ ထိုအချက်ကို ထည့်သွင်းစဉ်းစားခြင်းဖြင့် Microsoft ဖြေရှင်းချက်သည် မည်သည့်အလားအလာကို ပေးဆောင်နိုင်သည်ကို ပြသရန် ကျပန်း small-block အရွယ်အစားများအပြင် large-block transfers များကို အလေးပေးရန် workloads များကို အသုံးပြုခဲ့ပါသည်။ ကျွန်ုပ်တို့၏ Azure Stack HCI သုံးသပ်ချက်တွင် စွမ်းဆောင်ရည် benchmarks အတွက် vmfleet ကို အသုံးပြုခဲ့ပြီး VMware သို့မဟုတ် bare-metal Linux တွင် vdbench ကို အသုံးပြုခဲ့ပါသည်။
ဤနေရာတွင် စွမ်းဆောင်ရည်အတွက်၊ ကျွန်ုပ်တို့သည် စနစ်ကို 2-way mirror နှင့် 3-way mirror နှစ်မျိုးလုံးဖြင့် စမ်းသပ်ခဲ့သည်။ mirror ဆိုသည်မှာ ဒေတာကာကွယ်မှုနည်းလမ်း (မိတ္တူနှစ်ခု သို့မဟုတ် မိတ္တူသုံးခု) ကို ရည်ညွှန်းသည်။ မိတ္တူများလေလေ၊ အသုံးပြုသူများသည် စွမ်းရည်အချို့ ဆုံးရှုံးမည်မှာ ထင်ရှားပါသည်။ စွမ်းဆောင်ရည်ရှုထောင့်မှကြည့်လျှင် 3-way သည် parallelism တိုးလာခြင်းဖြင့် ပိုမိုကောင်းမွန်သော ဖတ်ရှုမှုများကို ဖြစ်ပေါ်စေသင့်ပြီး 2-way သည် network traffic သုံးဆလျော့နည်းပြီး write performance အတွက် ပိုကောင်းပါသည်။
ကျွန်ုပ်တို့ရဲ့ 4K random test အတွက်၊ 2-way mirror ဟာ ပျမ်းမျှ latency 247µs မှာ 2,204,296 IOPS read throughput နဲ့ ပျမ်းမျှ latency 3.69ms မှာ 564,601 IOPS write throughput ကို တွေ့ရှိခဲ့ရပါတယ်။ 3-way မှာတော့ ပျမ်းမျှ latency 170µs မှာ 2,302,610 IOPS read throughput ကို တွေ့ရှိခဲ့ပြီး write အတွက် ပျမ်းမျှ latency 9.12ms မှာ 338,538 IOPS throughput ကို တွေ့ရှိခဲ့ပါတယ်။ ဒီအချက်တွေထဲက အချို့ကို နားလည်နိုင်ဖို့ VMware ရဲ့ vSAN ဟာ node တစ်ခုစီမှာ Optane SSD နှစ်လုံးနဲ့ NVMe Capacity SSD လေးလုံး အသုံးပြုပြီး 521K IOPS တိုင်းတာခဲ့ပြီး 4K read အမြင့်ဆုံးမှာ 202K IOPS write တိုင်းတာခဲ့ပါတယ်။
နောက်တစ်ခုအနေနဲ့ ကျွန်တော်တို့ရဲ့ 32K sequential benchmark ကို ကြည့်ကြရအောင်။ read အတွက် 2-way hit 42.59GB/s နဲ့ 3-way hit 39.48GB/s ကို တွေ့ခဲ့ရပါတယ်။ write အတွက် HCI က 2-way အတွက် 13.8GB/s နဲ့ 3-way အတွက် 7.19GB/s ပေးခဲ့ပါတယ်။
ကျွန်ုပ်တို့၏ အစဉ်လိုက်လုပ်ဆောင်မှုဖြင့် ဆက်လက်လုပ်ဆောင်ခြင်းဖြင့် 64K စမ်းသပ်မှုများသို့ ဆက်လက်သွားပါမည်။ ဤနေရာတွင် 2-way hit 39.5GB/s read နှင့် 15.24GB/s write နှင့် 3-way hit 46.47GB/s read နှင့် 7.72GB/s write တို့ဖြစ်သည်။ vSAN နှင့် နှိုင်းယှဉ်ပါက read bandwidth ကွာခြားချက်များသည် နီးကပ်စွာပင် မရှိပါ။ ၎င်း၏ စမ်းသပ်မှုများတွင် bandwidth သည် 64K blocksize ဖြင့် 5.3GB/s ကျော်သာ ရှိသည်။ Write bandwidth တွင်လည်း အလားတူကွာခြားချက်ရှိပြီး vSAN သည် 2.55GB/s ဖြင့် အမြင့်ဆုံးရရှိခဲ့သည်။
ကျွန်ုပ်တို့ရဲ့ နောက်ထပ် benchmark ကတော့ ရောနှောထားတဲ့ read/write performance ပါတဲ့ SQL ပါ။ ဒီမှာ 2-way က ပျမ်းမျှ latency 324µs မှာ 1,959,921 IOPS ရှိပြီး throughput ရှိခဲ့ပါတယ်။ 3-way က ပျမ်းမျှ latency 185µs ရှိတဲ့ 1,929,030 IOPS ရှိပါတယ်။ SQL workload ကတော့ Azure Stack HCI က သူ့ရဲ့အစွမ်းသတ္တိကို ပြသနိုင်တဲ့ နောက်ထပ်နေရာတစ်ခုဖြစ်ပြီး IOPS ၂ သန်းအောက်သာ တိုင်းတာနိုင်ပြီး တူညီတဲ့ workload profile မှာရှိတဲ့ VMware ရဲ့ vSAN က 321k IOPS တိုင်းတာနိုင်ခဲ့ပါတယ်။
SQL 90-10 မှာ 2-way က 1,745,560 IOPS နဲ့ ပျမ်းမျှ latency 411µs ရှိခဲ့ပြီး 3-way မှာ 1,547,388 IOPS နဲ့ latency 285µs ရှိခဲ့ပါတယ်။
SQL 80-20 အတွက်၊ 2-way သည် latency အတွက် 581µs တွင် 1,530,319 IOPS throughput ရှိသည်။ 3-way သည် 1,175,469 IOPS နှင့် latency အတွက် 681µs ရှိသည်။
သတ်မှတ်ချက်များ
နောက်တစ်ခုကတော့ ကျွန်တော်တို့ရဲ့ SPECsfs 2014 SP2 benchmark ပါ။ ဒီစမ်းသပ်မှုအသစ်တစ်ခုပါ။ SPECsfs ဟာ file server ရဲ့ throughput နဲ့ response time ကို တိုင်းတာပေးတဲ့ benchmark suite တစ်ခုပါ။ benchmark က vendor platform အမျိုးမျိုးမှာ စွမ်းဆောင်ရည်ကို နှိုင်းယှဉ်ဖို့အတွက် စံသတ်မှတ်ထားတဲ့ နည်းလမ်းတစ်ခုကို ပေးပါတယ်။ benchmark ဟာ scale တစ်ခုသတ်မှတ်ပြီး benchmark ရဲ့ သတ်မှတ်ချက်တွေအတွက် point latency က အရမ်းများလွန်းတဲ့အထိ တိုးတိုးလေးလုပ်ဆောင်ပါတယ်။ ဒီမှာ 11ms ကျော်လွန်တဲ့အထိ လုပ်ဆောင်နိုင်တဲ့ scale နဲ့ server က latency နံပါတ်ကို မအောင်မြင်တဲ့အခါ bandwidth ကို ဘယ်လိုတိုင်းတာမလဲဆိုတာကို ကြည့်ပါမယ်။
ဒုတိယပိုင်းမှာ bandwidth ဘာကြောင့်ရပ်တန့်သွားတယ်ဆိုတာကို ပိုမိုရှင်းလင်းစွာဖော်ပြပေးမှာဖြစ်လို့ latency ကို အရင်ဆုံးလေ့လာကြည့်ပါမယ်။ 2-way နဲ့ 3-way နှစ်ခုလုံးအတွက် scale နဲ့ latency တွေကို အောက်ကဇယားမှာဖော်ပြထားပါတယ်။
| SPECsfs နှောင့်နှေးမှု (ms) | ||
|---|---|---|
| စကေး | DataON HCI-224 ၃-လမ်းမှန် | DataON HCI-224 ၃-လမ်းမှန် |
| 100 | 0.243 | 0.262 |
| 200 | 0.329 | 0.371 |
| 300 | 0.466 | 0.499 |
| 400 | 0.636 | 0.699 |
| 500 | 0.753 | 0.896 |
| 600 | 0.953 | 1.083 |
| 700 | 1.113 | 1.314 |
| 800 | 1.326 | 1.557 |
| 900 | 1.501 | 1.826 |
| 1000 | 1.88 | 2.167 |
| 1100 | 2.061 | 2.807 |
| 1200 | 2.323 | 4.64 |
| 1300 | 2.749 | 8.557 |
| 1400 | 5.47 | 10.449 |
| 1500 | 8.616 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) |
| 1600 | 10.485 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) |
| 1700 | 11.069 | |
| 1800 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) | |
| 1900 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) | |
မြင်တွေ့ရသည့်အတိုင်း configuration နှစ်ခုစလုံးသည် 250µs အနီးတွင်စတင်ခဲ့ပြီး 2-way သည် အနည်းငယ်နိမ့်ကျပြီး တစ်လျှောက်လုံး ထိုအတိုင်းရှိနေသည်။ 1500 scale တွင် 3-way သည် 11.285ms သို့ရောက်ရှိခဲ့ပြီး 262µs မှ 10.45ms အတွင်း ချို့ယွင်းခဲ့သည်။ 2-way သည် 1800 scale တွင် 11.7ms အထိ ချို့ယွင်းခဲ့ပြီး 243µs မှ 11.07ms အတွင်း ချို့ယွင်းခဲ့သည်။
နောက်ဇယားတွင် build တစ်ခုစီတွင် configuration တစ်ခုစီအတွက် bandwidth ကိုပြသထားပြီး၊ အထက်တွင် ပျက်ကွက်မှုကို latency ဖြင့် ဖော်ပြထားသည်။
| SPECsfs Bandwidth (KB/s) | ||
| စကေး | DataON HCI-224 ၃-လမ်းမှန် | DataON HCI-224 ၃-လမ်းမှန် |
| 100 | 300897 | 300880 |
| 200 | 600372 | 600857 |
| 300 | 901672 | 902964 |
| 400 | 1202779 | 1203106 |
| 500 | 1504492 | 1503394 |
| 600 | 1805952 | 1806455 |
| 700 | 2105973 | 2108432 |
| 800 | 2408183 | 2406171 |
| 900 | 2710895 | 2707106 |
| 1000 | 3007499 | 3009280 |
| 1100 | 3308648 | 3308168 |
| 1200 | 3608244 | 3610219 |
| 1300 | 3910414 | 3888303 |
| 1400 | 4212976 | 4026720 |
| 1500 | 4513454 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) |
| 1600 | 4587183 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) |
| 1700 | 4621067 | |
| 1800 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) | |
| 1900 | ၄၅၆၉၈၂၄ (ပျက်ကွက်) | |
bandwidth အတွက်၊ configuration နှစ်ခုစလုံးသည် 300MB/s intervals များဖြင့် neck-in-neck ဖြင့် လည်ပတ်ခဲ့ပြီး 3-way သည် ၎င်း၏ final passing bandwidth 4.02GB/s ဖြင့် latency ကို မအောင်မြင်ခဲ့ဘဲ 2-way သည် ၎င်း၏ final passing bandwidth 4.62GB/s ရှိသည်။
ကောက်ချက်
Microsoft storage-centric stack မှာ ကျွန်တော်တို့ ဒီလောက်ထိ နက်နက်ရှိုင်းရှိုင်း လေ့လာနေတာ အတော်ကြာပါပြီ။ ပြန်လာရတာ ဝမ်းသာပါတယ်။ Microsoft Azure Stack HCI solution ကို ပြန်လည်အမည်ပြောင်းလဲထားတဲ့ Microsoft ဟာ အခြေခံကျပြီး လျှော့တွက်လို့မရတဲ့ အရာတစ်ခုကို လုပ်ဆောင်ခဲ့ပါတယ်။ Microsoft ဟာ သူတို့ရဲ့ HCI solution ကို စွမ်းဆောင်ရည်ကို လျော့ကျစေမယ့် ဘာမှထပ်မတင်ဘဲ လုပ်ဆောင်ရတာ အလွန်ရိုးရှင်းအောင် ပြုလုပ်ထားပါတယ်။ ကျွန်တော်တို့ရဲ့ ကိန်းဂဏန်းတွေအရ ကျွန်တော်တို့ စမ်းသပ်နေတဲ့ DataON cluster ဟာ အလွန်ကောင်းမွန်တဲ့ ကိန်းဂဏန်းတွေကို ရရှိခဲ့ပြီး အလယ်အလတ်ဈေးကွက် 4-node HCI cluster မှာ အမြန်ဆုံးဖြစ်ပါတယ်။ တရားမျှတစွာပြောရရင် DataON ရဲ့ နောက်ဆုံးပေါ်နဲ့ အကောင်းဆုံး hardware ကိုတောင် ကျွန်တော်တို့ စမ်းသပ်နေတာ မဟုတ်ပါဘူး။ ဒီ config ဟာ Intel Optane DC SSD တွေနဲ့ ပြီးပြည့်စုံပေမယ့် DataON ဟာ Intel Xeon 2nd Generation CPU တွေ၊ persistent memory နဲ့ ပိုမိုမြန်ဆန်တဲ့ networking တို့ကို အားသာချက်ယူထားတဲ့ ပိုမိုမြန်ဆန်တဲ့ solution တွေကို ပေးစွမ်းပါတယ်။ Azure Stack HCI solution မှာ စွမ်းဆောင်ရည်တွေ ပိုရနိုင်တာက စိတ်လှုပ်ရှားစရာပါပဲ၊ ဒါပေမယ့် ဒီ solution ဟာ low-cost edge ဒါမှမဟုတ် SMB solution အတွက် switchless configure လုပ်နိုင်တဲ့ two node HCI လောက်သေးငယ်တဲ့ deployment တွေအထိ scale down လုပ်လို့ရတယ်ဆိုတာ မမေ့ဖို့လည်း အရေးကြီးပါတယ်။
စွမ်းဆောင်ရည်နံပါတ်များကို လေ့လာကြည့်လျှင် Microsoft Azure Stack HCI cluster သည် မယုံနိုင်လောက်အောင် I/O နှင့် bandwidth များစွာကို ပေးစွမ်းနိုင်ခဲ့သည်။ လေးထောင့်နယ်ပယ်တွင်၊ ကျွန်ုပ်တို့သည် 3-way mirror configuration ဖြင့် 4K random read 2.3M IOPS ကျော်နှင့် 4K random write 338k IOPS ကျော်ကို တိုင်းတာနိုင်ခဲ့သည်။ ပိုမိုကောင်းမွန်သော write စွမ်းဆောင်ရည် လိုအပ်ပါက 2-way mirror configuration သည် 4K random write speeds ကို 564k IOPs အထိ မြှင့်တင်ပေးနိုင်သည်။ သို့သော် bandwidth ကိုကြည့်လျှင် Microsoft Azure Stack သည် အမှန်တကယ်ထွန်းတောက်သည်။ ကျွန်ုပ်တို့၏ 64K block sequential transfer workload တွင်၊ 2-way mirror သည် 39.5GB/s read နှင့် 15.24GB/s write တိုင်းတာခဲ့ပြီး 3-way mirror သည် 46.47GB/s read နှင့် 7.72GB/s write တိုင်းတာခဲ့သည်။ ၎င်းသည် ယခင် HCI cluster များမှ ကျွန်ုပ်တို့တိုင်းတာခဲ့သည်ထက် များစွာကျော်လွန်ပါသည်။
အလုံးစုံပြောရရင် Microsoft ရဲ့ Azure Stack HCI solution ဟာ တပ်ဆင်ရလွယ်ကူမှု၊ စီမံခန့်ခွဲရလွယ်ကူမှုနဲ့ အလွန်ကောင်းမွန်တဲ့စွမ်းဆောင်ရည်တွေ နှစ်မျိုးလုံးရှိကြောင်း သက်သေပြခဲ့ပါတယ်။ solution ရဲ့ မိတ်ဖက်တစ်ယောက်အနေနဲ့ DataON ဟာ turn-key build ကို ပေးစွမ်းရာမှာ ထူးချွန်ခဲ့ပြီး၊ နောက်ဆုံးမှာ အချိန်တိုအတွင်း လည်ပတ်နိုင်တဲ့ configuration မှာ ရှင်းလင်းတဲ့ညွှန်ကြားချက်တွေနဲ့အတူ built-in-to-spec hardware ကို ပေးစွမ်းခဲ့ပါတယ်။ ဖောက်သည်တွေဟာ ဝါယာကြိုးချိတ်ဆက်မှုကိုတောင် ကျော်သွားနိုင်တာကြောင့် ဒါဟာ သီးခြားလိုအပ်ချက်ပေါ်မှာ မူတည်ပါတယ်။ ဘယ်လိုပဲဖြစ်ဖြစ် Azure Stack HCI ဟာ Intel Optane၊ Intel NVMe SSD တွေနဲ့ Mellanox 100G networking တွေနဲ့ ပေါင်းစပ်ထားတာဟာ အံ့မခန်းအင်အားစုတစ်ခုဖြစ်ကြောင်း သက်သေပြခဲ့ပါတယ်။
အမေဇုံ