Oracle Cloud Infrastructure မှာ compute၊ storage၊ networking၊ database နဲ့ load balancing အပါအဝင် ဝန်ဆောင်မှုအမျိုးမျိုး ပါဝင်ပါတယ်။ cloud-based data center တစ်ခု တည်ဆောက်ဖို့ လိုအပ်တဲ့ infrastructure အားလုံး ပါဝင်ပါတယ်။ ဒီသုံးသပ်ချက်နဲ့ ပတ်သက်ပြီး Oracle Cloud Infrastructure Compute အမျိုးအစားကို စိတ်ဝင်စားပါတယ်။ cloud provider အများစုလိုပဲ Oracle ဟာ virtualized compute instance တွေကို ပေးပေမယ့် တခြား virtual offering အများစုနဲ့ မတူဘဲ Oracle ဟာ latency နည်းတဲ့ application တွေအတွက် ~25TB အထိ NVMe storage ပါဝင်တဲ့ shapes တွေနဲ့ ပံ့ပိုးပေးနိုင်ပါတယ်။ အဲဒီလို ကောင်းမွန်ပေမယ့် Oracle ဟာ latency အလွန်အရေးကြီးတဲ့ mission-critical application တွေအတွက် အသင့်တော်ဆုံး industry ရဲ့ ပထမဆုံး high-performance bare-metal instance တွေကို ပေးဆောင်ခြင်းအားဖြင့် cloud compute စွမ်းဆောင်ရည်အတွက် အားသာချက်ကို ထပ်မံတိုးမြှင့်ထားပါတယ်။ instances တွေမှာ OCPU ၅၂ ခုအထိ၊ RAM ၇၆၈GB၊ dual 25GbE NIC တွေနဲ့ locally attached NVMe storage ၅၁TB အထိ ပါဝင်ပါတယ်။ ပိုမိုလိုချင်သူတွေအတွက် network attached NVMe block storage ၅၁၂TB အထိအပြင် GPU option တွေလည်း ရရှိနိုင်ပါတယ်။ Oracle compute ကမ်းလှမ်းချက်အားလုံးသည် ပြိုင်ဆိုင်မှုကို အနည်းဆုံးဖြစ်စေရန်နှင့် စွမ်းဆောင်ရည်ကို အမြင့်ဆုံးဖြစ်စေရန် ချိန်ညှိထားသော အဆင့်မြင့် optimized software-defined network တွင် လည်ပတ်ပါသည်။
ယခုအချိန်တွင် cloud ကမ်းလှမ်းမှုအမျိုးမျိုးရှိပြီး AWS၊ Google Cloud Platform နှင့် Microsoft Azure တို့ဖြင့် စာရင်းထိပ်ဆုံးတွင်ရှိသည်။ ဤ cloud ဝန်ဆောင်မှုပေးသူများသည် ကောင်းမွန်သော ထုတ်ကုန်များနှင့် ဝန်ဆောင်မှုများစွာကို ပေးဆောင်သော်လည်း ၎င်းတို့တွင် ပုံမှန်အားဖြင့် မရှိသည့်အရာတစ်ခုမှာ စွမ်းဆောင်ရည်ဖြစ်သည်။ cloud နှင့် on-premises တို့ကို နှိုင်းယှဉ်သောအခါ on-prem သည် cloud ထက် အမြဲတမ်းသာလွန်သည်။ Oracle သည် ၎င်း၏ cloud အခြေခံအဆောက်အအုံ ကမ်းလှမ်းမှုများဖြင့် ဤအမြင်ကို ပြောင်းလဲရန် ရှာဖွေနေသည်။
Oracle ရဲ့ compute ကမ်းလှမ်းချက်တွေမှာ on-prem storage ဒါမှမဟုတ် server တွေကနေ မျှော်လင့်ထားတဲ့ ကတိတွေ ပါရှိပါတယ်။ စွမ်းဆောင်ရည်၊ ရရှိနိုင်မှု၊ ဘက်စုံအသုံးပြုနိုင်မှုနဲ့ အုပ်ချုပ်မှု အပါအဝင်ပါ။ စွမ်းဆောင်ရည်ဘက်ခြမ်းက mission-critical application တွေအတွက် အမြင့်ဆုံးနဲ့ တသမတ်တည်း စွမ်းဆောင်ရည်ကို ပံ့ပိုးပေးပြီး မကြာသေးမီက ကြေညာခဲ့တဲ့ end-to-end cloud infrastructure SLA က ကျောထောက်နောက်ခံပြုထားပါတယ် ။ ဒီကမ်းလှမ်းချက်က DNS၊ load balancing၊ replication၊ backup၊ storage snapshots နဲ့ clustering အပါအဝင် multiple layer တွေမှာ ရရှိနိုင်မှုကို ပံ့ပိုးပေးပါတယ်။ compute ကမ်းလှမ်းချက်တွေက single core VM ကနေ 52-core single-tenant bare metal အထိ အမျိုးမျိုးရှိပြီး common workloads ကနေ HPC clusters အထိ အရာအားလုံးကို run နိုင်တဲ့ ဘက်စုံအသုံးပြုနိုင်မှုကို ပေးစွမ်းပါတယ်။ Oracle ရဲ့ bare metal instance တွေနဲ့ customer တွေဟာ on-prem server ရဲ့ isolation နဲ့ control ကို ရရှိပါတယ်။ ဘာလို့လဲဆိုတော့ သူတို့မှာ တခြား tenant တွေ မပါဝင်သလို Oracle-provider software လည်း မပါဝင်လို့ပါ။
Oracle Cloud မှ compute ကမ်းလှမ်းချက်များသည် bare metal instance၊ bare metal GPU instance နှင့် VM instance အပါအဝင် “ပုံသဏ္ဍာန်” အမျိုးမျိုးဖြင့် လာပါသည်။ ဤသုံးသပ်ချက်အတွက် ကျွန်ုပ်တို့သည် bare metal instance များကို ကြည့်ရှုသွားမည်ဖြစ်ပြီး Oracle ၏ အဆိုအရ IOPS ၅.၁ သန်းအထိ ပေးပို့နိုင်ပြီး mission-critical database application များ၊ HPC workloads နှင့် I/O intensive web application များကဲ့သို့သော အသုံးပြုမှုကိစ္စများအတွက်ဖြစ်သည်။ နှိုင်းယှဉ်ကြည့်ရန်၊ local NVMe storage (DenseIO) နှင့် network block storage (Standard) ပါရှိသော Oracle ၏ VM ပုံသဏ္ဍာန်များကိုလည်း ပြသပါမည်။
စီမံခန့်ခွဲမှု
Oracle Cloud Infrastructure အတွက် စီမံခန့်ခွဲမှု GUI သည် နားလည်ရလွယ်ကူပါသည်။ လိုအပ်ပါက အဓိကစာမျက်နှာတွင် လမ်းညွှန်ချက်များနှင့် အကူအညီများပါရှိသည်။ အပေါ်ဆုံးတွင် ငှားရမ်းခြင်း သို့မဟုတ် အကောင့်၊ အသုံးပြုနေသော ဒေသ (ကျွန်ုပ်တို့၏ကိစ္စတွင် us-ashburn-1)၊ Home (အဓိကစာမျက်နှာ)၊ Identity၊ Compute၊ Database၊ Networking၊ Storage၊ Audit နှင့် Email အတွက် tab များပါရှိသည်။ ကျွန်ုပ်တို့၏ စမ်းသပ်မှုအတွက် DenseIO2 နှင့် Standard2 ကို ပြသထားသည်။
ဤသုံးသပ်ချက်သည် Compute ဘက်ခြမ်းကို အဓိကထားသောကြောင့်၊ ထို tab အောက်တွင်ကြည့်လျှင် ကျွန်ုပ်တို့၏ စွမ်းဆောင်ရည်စမ်းသပ်မှုများအတွက် အသုံးပြုမည့် instance များကို မြင်တွေ့နိုင်ပါသည်။ instance တစ်ခုချင်းစီတွင် ၎င်း၏အမည်၊ ပုံသဏ္ဍာန်၊ ဒေသ၊ ရရှိနိုင်မှုဒိုမိန်းနှင့် ၎င်းကို ဖန်တီးခဲ့သည့်အချိန်တို့ ပါရှိသည်။ ဘယ်ဘက်ခြမ်းတွင်၊ အသုံးပြုသူများသည် “လည်ပတ်နေသည်” ကဲ့သို့သော အခြေအနေကို ရွေးချယ်ခြင်းဖြင့် စာရင်းကို ပြောင်းလဲနိုင်သည်။
ညာဘက်ခြမ်းက ellipsis ကို နှိပ်လိုက်ခြင်းအားဖြင့် instance တစ်ခုကို ပိုမိုနက်ရှိုင်းစွာ လေ့လာနိုင်ပါတယ်။ BM.DenseIO2.52 ကိုကြည့်မယ်ဆိုရင် instance လည်ပတ်နေသလား၊ လည်ပတ်နေသလားနဲ့ ပတ်သက်တဲ့ အသေးစိတ်အချက်အလက်တွေကို အလွယ်တကူ မြင်တွေ့နိုင်ပါတယ်။ tags တွေကိုလည်း ဒီမှာ ဆက်စပ်ကြည့်နိုင်ပါတယ်။ အချက်အလက်ရဲ့ အပေါ်ဆုံးမှာ custom image တစ်ခု ဖန်တီးနိုင်ခြင်း၊ instance ကို စတင်နိုင်ခြင်း၊ ရပ်တန့်နိုင်ခြင်း၊ reboot လုပ်နိုင်ခြင်း ဒါမှမဟုတ် terminate လုပ်နိုင်ခြင်း ဒါမှမဟုတ် tags တွေ ထည့်သွင်းနိုင်ခြင်းတွေ ပါဝင်ပါတယ်။ scroll down လုပ်ခြင်းအားဖြင့် block volumes တွေကိုလည်း attach လုပ်နိုင်ပါတယ်။
Networking tab အောက်မှာ Virtual Cloud Network ကိုသုံးနေတာကိုမြင်နိုင်သလို ဖန်တီးနိုင်ပါတယ်။ VCN အတွက် region, default route table, DNS domain နဲ့ ဘယ်အချိန်မှာ ဖန်တီးခဲ့လဲ စတဲ့ အချက်အလက်တွေရှိပါတယ်။ ညာဘက်က ellipsis က drill down, tags applying နဲ့ subnet တစ်ခုဖန်တီးဖို့ ခွင့်ပြုပါတယ်။
Storage tab အောက်မှာ အသုံးပြုသူတွေဟာ သူတို့ရဲ့ compartment ထဲက block volume တွေကို မြင်နိုင်ပြီး နောက်ထပ်ဖန်တီးနိုင်ပါတယ်။ block volume တွေကို ဖန်တီးတဲ့ရက်စွဲအလိုက် စာရင်းပြုစုထားပြီး အသုံးပြုသူတွေဟာ နောက်ထပ်အချက်အလက်တွေအတွက် drill down လုပ်နိုင်သလို၊ manual backup တွေ ဖန်တီးနိုင်သလို၊ instance ကနေ block volume ကို detach လုပ်နိုင်သလို၊ volume ကို ဖျက်နိုင်သလို၊ tag တွေကိုလည်း အသုံးပြုနိုင်ပါတယ်။
ထို့အပြင် Audit က ညွှန်ပြသည့်အတိုင်း ရက်စွဲနှင့် အချိန်အပိုင်းအခြားကို ရွေးချယ်ခြင်းဖြင့် ယခင်ဖြစ်ရပ်များကို လျင်မြန်စွာ ကြည့်ရှုနိုင်ပါသည်။ ၎င်းသည် လုပ်ငန်းများအား စီမံခန့်ခွဲမှု လိုက်နာမှုဆိုင်ရာ လိုအပ်ချက်များကို ဖြည့်ဆည်းပေးနိုင်ပြီး ဖြစ်ရပ်တိုင်း သို့မဟုတ် ပတ်ဝန်းကျင်ပြောင်းလဲမှုတိုင်းအတွက် အသုံးပြုသူနှင့် လုပ်ဆောင်ချက်ကို မှတ်တမ်းတင်နိုင်စေပါသည်။
performance
VDBench လုပ်ငန်းဝန်အား ခွဲခြမ်းစိတ်ဖြာခြင်း
ဤ Oracle Cloud instance များ၏ စွမ်းဆောင်ရည်ကို အကဲဖြတ်ရန်အတွက်၊ ကျွန်ုပ်တို့သည် platform တစ်ခုချင်းစီတွင် local install လုပ်ထားသော vdbench ကို အသုံးချခဲ့သည်။ ကျွန်ုပ်တို့၏ စမ်းသပ်မှုများကို local storage အားလုံးတွင် တစ်ပြိုင်နက်တည်း ဖြန့်ကျက်ထားသောကြောင့် BV (Block Volume) နှင့် NVMe storage နှစ်ခုလုံးရှိနေပါက၊ ကျွန်ုပ်တို့သည် တစ်ကြိမ်လျှင် အုပ်စုတစ်ခုစီကို စမ်းသပ်ခဲ့သည်။ storage အမျိုးအစားနှစ်မျိုးလုံးဖြင့်၊ ကျွန်ုပ်တို့သည် device တစ်ခုစီ၏ 12% ကို ခွဲဝေပေးပြီး data locality အသင့်အတင့်ဖြင့် အမြင့်ဆုံးစနစ်စွမ်းဆောင်ရည်ကို ကြည့်ရှုရန် ၎င်းတို့ကို စုပေါင်းအုပ်စုဖွဲ့ခဲ့သည်။
ဤ workloads များသည် “four corners” စမ်းသပ်မှုများ၊ common database transfer size စမ်းသပ်မှုများအပြင် မတူညီသော VDI ပတ်ဝန်းကျင်များမှ trace captures များအထိ မတူညီသော testing profile အမျိုးမျိုးကို ပေးဆောင်ပါသည်။ ဤစမ်းသပ်မှုအားလုံးသည် scripting engine ပါဝင်သော common vdBench workload generator ကို အသုံးပြုပြီး ကြီးမားသော compute testing cluster တစ်ခုပေါ်တွင် ရလဒ်များကို အလိုအလျောက်လုပ်ဆောင်ပြီး ဖမ်းယူပါသည်။ ၎င်းသည် flash arrays နှင့် individual storage devices များအပါအဝင် storage devices အမျိုးမျိုးတွင် တူညီသော workloads များကို ထပ်ခါတလဲလဲ လုပ်ဆောင်နိုင်စေပါသည်။
ကိုယ်ရေးအချက်အလက်
- 4K ကျပန်းဖတ်ရှုမှု- 100% ဖတ်ရှုမှု၊ 128 threads၊ 0-120% iorate
- 4K ကျပန်းရေးသားမှု- 100% ရေးသားမှု၊ 64 threads၊ 0-120% iorate
- ၆၄K စဉ်ဆက်မပြတ်ဖတ်ရှုမှု- ၁၀၀% ဖတ်ရှုမှု၊ ချည် ၃၂ ခု၊ ၀-၁၂၀% iorate
- ၆၄K အစဉ်လိုက်ရေးသားမှု- ၁၀၀% ရေးသားမှု၊ ၁၆ ချည်၊ ၀-၁၂၀% iorate
- ပေါင်းစပ်ဒေတာဘေ့စ်- SQL နှင့် Oracle
- VDI အပြည့်အဝ Clone နှင့် ချိတ်ဆက်ထားသော Clone Traces များ
ကျွန်ုပ်တို့သည် remote block devices (BV) နှင့် NVMe နှစ်ခုလုံးကို လေ့လာကြည့်ပါသည်။ စွမ်းဆောင်ရည် သိသိသာသာ ကွာခြားချက်ရှိသောကြောင့် ရလဒ်များကို ဇယားနှစ်ခုအဖြစ် ခွဲခြားထားပါသည် (latency သည် အလွန်ကွာခြားသောကြောင့် ဇယားများကို ဖတ်ရှုရန် အလွန်ခက်ခဲနိုင်ပါသည်)။ ဤသုံးသပ်ချက်အတွက် ကျွန်ုပ်တို့သည် BV တွင် standard နှင့် dense IO နှစ်မျိုးလုံးဖြင့် Bare Metal (BM) နှင့် VM configuration နှစ်ခုလုံးကို လေ့လာပြီး NVMe အတွက် dense IO ကိုသာ လေ့လာပါသည်။
BV ရဲ့ အမြင့်ဆုံး 4K read ကိုကြည့်မယ်ဆိုရင် run လေးခုစလုံးဟာ sub-millisecond latency နဲ့ စတင်ခဲ့ပါတယ်။ ပထမဆုံး ဖြုတ်ချခံရတဲ့ VM.Standard က 53K IOPS အောက်မှာပဲ ရှိပြီး latency 15ms နဲ့ 60,591 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ sub-millisecond latency ကို ချိုးဖျက်နိုင်တဲ့ နောက်တစ်ခုကတော့ VM.DenseIO ဖြစ်ပြီး standard နဲ့ အတူတူလောက်မှာ 1ms ကျော်သွားပေမယ့် latency 7.5ms နဲ့ 72,626 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ bare metal run နှစ်ခုစလုံးက DenseIO က sub-millisecond latency performance ကို 235K IOPS အထိ ရောက်ရှိခဲ့ပြီး latency 4.1ms နဲ့ 252,275 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.Standard က 1ms ကျော်မသွားခင် 250K IOPS အထိ ရောက်ရှိခဲ့ပြီး latency 4.05ms နဲ့ 258,329 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။
NVMe အတွက် အမြင့်ဆုံး 4K ဖတ်ရှုမှုစွမ်းဆောင်ရည်ကို ကြည့်မယ်ဆိုရင် လုပ်ဆောင်မှုနှစ်ခုစလုံးမှာ မီလီစက္ကန့်အောက် latency ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ 569,534 IOPS မှာ အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး latency 214μs ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ 4,419,490 IOPS မှာ အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး latency 174.6 μs သာရှိခဲ့ပါတယ်။
BV အတွက် random 4K write peak performance ကိုပြောင်းလိုက်တဲ့အခါ BM တွေထက် အများကြီးစောပြီး VM တွေက peak တက်သွားတာနဲ့ အတူတူပါပဲ။ VM.Standard က sub-millisecond latency ကို မကျော်ခင် 63K IOPS လောက်ရောက်ပြီး 5.3ms latency မှာ 77,229 IOPS အထိ ရောက်ခဲ့ပါတယ်။ VM.DenseIO က 1ms ကျော်မသွားခင် 69K IOPS လောက်ရောက်အောင် ပိုကောင်းတဲ့စွမ်းဆောင်ရည်နဲ့ 3.9ms latency နဲ့ 84,274 IOPS အထိ ရောက်ခဲ့ပါတယ်။ BM.DenseIO က latency 1ms ကျော်မသွားခင် 263K IOPS ရဲ့အထက်ကို ရောက်ပြီး 2.02ms latency နဲ့ 280,158 IOPS အထိ ရောက်ခဲ့ပါတယ်။ BM.Standard သည် အမြင့်ဆုံးစွမ်းဆောင်ရည်ရှိသော configuration ဖြစ်ပြီး sub-millisecond latency ကို မကျော်လွန်မီ 278K IOPS အထိ ရောက်ရှိခဲ့ပြီး latency 1.84ms ဖြင့် 280,844 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
NVMe ကို 4K write မှာထားရင် BM ဟာ VM ထက်သာလွန်ပြီး နှစ်ခုစလုံးမှာ sub-millisecond latency performance ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ 412,207 IOPS နဲ့ latency 141μs အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ 3,232,215 IOPS နဲ့ latency 125μs အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။
အစဉ်လိုက်လုပ်ဆောင်ရမယ့်အလုပ်ဆီ ဆက်သွားရအောင်၊ BV အတွက် 64K read ကို အရင်ဆုံးကြည့်ကြရအောင်။ VM.Standard နဲ့ VM.DenseIO နှစ်ခုစလုံးဟာ 1ms latency ကို 15.5K IOPS ဒါမှမဟုတ် 968MB/s လောက်မှာ ချိုးဖျက်နိုင်ခဲ့ပါတယ်။ ပြီးတော့ latency က 8.2ms အထိ တက်လာတာနဲ့အမျှ စွမ်းဆောင်ရည်က အတူတူပါပဲ။ BM.Standard နဲ့ BM.DenseIO နှစ်ခုစလုံးဟာ 37.5K IOPS ဒါမှမဟုတ် 2.35GB/s လောက်မှာ 1ms ကို ချိုးဖျက်နိုင်ခဲ့တာနဲ့ အလားတူတစ်ခုကို ထပ်မံတွေ့ရှိခဲ့ရပါတယ်။ config နှစ်ခုစလုံးဟာ 8.4ms latency မှာ 47K IOPS ဒါမှမဟုတ် 2.95GB/s လောက်ရဲ့ မြောက်ဘက်မှာ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။
NVMe sequential 64K read မှာ config နှစ်ခုစလုံးဟာ sub-millisecond latency အောက်မှာ ရှိနေခဲ့ပါတယ်။ VM.DenseIO ဟာ 39,512 IOPS (သို့) 2.5GB/s မှာ latency 403μs ရှိပြီး BM.DenseIO ကတော့ 323,879 IOPS (သို့) 20.2GB/s မှာ latency 361μs ရှိပါတယ်။
BV အတွက် 64K sequential writes ဖြင့်၊ VM.Standard နှင့် VM.DenseIO နှစ်ခုစလုံးသည် 12K IOPS သို့မဟုတ် 770MB/s စွမ်းဆောင်ရည်ဖြင့် 1ms latency ကို ချိုးဖျက်သည့် အလားတူဖြစ်စဉ်ကို ထပ်မံတွေ့ရှိရပါသည်။ နှစ်ခုစလုံးသည် 3.1ms latency တွင် 15.1K IOPS သို့မဟုတ် 943MB/s ဝန်းကျင်တွင် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM.Standard နှင့် BM.DenseIO နှစ်ခုစလုံးသည် 1ms latency ကို 42K IOPS သို့မဟုတ် 2.6GB/s ဖြင့် ချိုးဖျက်ခဲ့ပြီး BM.DenseIO သည် 2.6ms latency တွင် 46,768 IOPS သို့မဟုတ် 2.92GB/s ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM.Standard သည် 3.4ms latency တွင် 46,787 IOPS သို့မဟုတ် 2.92GB/s ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
NVMe အတွက် 64K sequential writes အတွက်၊ VM.DenseIO နှင့် BM.DenseIO နှစ်ခုစလုံးသည် မီလီစက္ကန့်အောက် latency စွမ်းဆောင်ရည်ကို ထပ်မံရရှိခဲ့သော်လည်း နှစ်ခုစလုံးသည် latency မြင့်တက်လာမှုကိုလည်း ကြုံတွေ့ခဲ့ရသည် (BM.DenseIO အတွက် စွမ်းဆောင်ရည် နောက်ဆုံးလျော့ကျမှုနှင့်အတူ)။ VM.DenseIO သည် 754μs အထိ မြင့်တက်လာပြီးနောက် latency 311μs ဖြင့် 25K IOPS သို့မဟုတ် 1.56GB/s တွင် အမြင့်ဆုံးသို့ ရောက်ရှိခဲ့သည်။ BM.DenseIO သည် ပိုမိုကောင်းမွန်သော အမြင့်ဆုံးစွမ်းဆောင်ရည် (latency 170μs တွင် 160,895 IOPS သို့မဟုတ် 10.1GB/s) ရှိခဲ့သော်လည်း နောက်ဆုံးတွင် latency မြင့်တက်လာခြင်းဖြင့် အချို့ကျဆင်းခဲ့ပြီး 132,192 IOPS သို့မဟုတ် 8.8GB/s ဖြင့် latency 310μs ဖြင့် အဆုံးသတ်ခဲ့သည်။
BV အတွက် ကျွန်တော်တို့ရဲ့ SQL workload မှာ VM.Standard ဟာ 50K IOPS ခန့်မှာ 1ms အထက်ကို ရောက်ရှိခဲ့တဲ့ ပထမဆုံး VM ဖြစ်ပြီး latency 3.4ms နဲ့ 73,259 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ 58K IOPS ခန့်မှာ 1ms latency ကျော်ခဲ့ပြီး latency 3.1ms နဲ့ 78,624 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM တွေနဲ့ဆိုရင် နှစ်ခုစလုံးဟာ 275K လောက်အထိ latency 1ms အောက်မှာပဲ ရှိနေခဲ့ပါတယ် (BM.DenseIO က နည်းနည်းပိုကြာအောင် လည်ပတ်နေပါတယ်)။ BM.Standard ဟာ 305,368 IOPS နဲ့ 1.7ms latency ရှိပြီး BM.DenseIO ဟာ 307,979 IOPS နဲ့ 1.35ms latency ရှိပါတယ်။
NVMe အတွက် SQL တွင် မီလီစက္ကန့်အောက် latency ရှိခဲ့ပြီး VM.DenseIO သည် 188,786 IOPS ဖြင့် 167μs ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM.DenseIO သည် 1,684,869 IOPS ဖြင့် latency 142μs ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
BV အတွက် SQL 90-10 benchmark မှာ VM နှစ်ခုစလုံးဟာ sub-millisecond latency စွမ်းဆောင်ရည်ကို 58K IOPS ခန့်နဲ့ ချိုးဖျက်နိုင်ခဲ့ပါတယ်။ VM.Standard ဟာ latency 3.5ms နဲ့ 71,691 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ latency 3.05ms နဲ့ 79,033 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM.Standard ဟာ 270K IOPS ခန့်နဲ့ 1ms latency ကို ချိုးဖျက်ခဲ့ပြီး latency 1.7ms နဲ့ 303,904 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO မှာ 290K IOPS ခန့်အထိ sub-millisecond latency ရှိပြီး latency 1.34ms နဲ့ 307,472 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။
NVMe SQL 90-10 အတွက် VM.DenseIO သည် 172,693 IOPS ဖြင့် latency 182μs ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM.DenseIO သည် 165μs ဖြင့် 1,328,437 IOPS ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
BV အတွက် SQL 80-20 benchmark မှာ VM.Standard ဟာ 1ms ကျော်မသွားခင် 54K IOPS လောက်အထိ ရောက်ရှိခဲ့ပြီး latency 3.4ms နဲ့ 72,204 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ 59K IOPS အထိ sub-millisecond latency ရှိပြီး 78,787 IOPS အထိ ရောက်ရှိခဲ့ပြီး latency 2.99ms အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.Standard ဟာ latency 1ms အောက်နဲ့ 280K IOPS အထိ ရောက်ရှိခဲ့ပြီး latency 1.6ms နဲ့ 300,014 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ 285K IOPS လောက်မှာ 1ms latency ကို ချိုးဖျက်နိုင်ခဲ့ပြီး 299,730 IOPS အထိ ရောက်ရှိခဲ့ပြီး စွမ်းဆောင်ရည် ကျဆင်းသွားခင်မှာ 1.3ms latency နဲ့ 299,730 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။
NVMe အတွက် SQL 80-20 benchmark မှာ VM.DenseIO ဟာ 144,010 IOPS နဲ့ latency 218μs အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ 1,114,056 IOPS နဲ့ latency 182μs အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပြီးနောက် စွမ်းဆောင်ရည် အနည်းငယ်ကျဆင်းသွားခဲ့ပါတယ်။
BV ပါဝင်တဲ့ ကျွန်တော်တို့ရဲ့ Oracle workload မှာ VM.Standard ဟာ sub-millisecond latency performance ရှိပြီး 52K IOPS လောက်ရောက်ပြီး 70,096 IOPS အထိ latency 3.4ms အထိ ရောက်ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ 1ms latency ကို 58K IOPS လောက်မှာ ချိုးဖျက်နိုင်ခဲ့ပြီး 75,000 IOPS အထိ latency 3.1ms အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.Standard ဟာ 1ms latency ကို 255K လောက်မှာ ချိုးဖျက်နိုင်ခဲ့ပြီး 280,599 IOPS အထိ latency 1.41ms အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO မှာ sub-millisecond latency ရှိပြီး 260K IOPS လောက်မှာ latency 1.3ms အထိ ရောက်ရှိခဲ့ပါတယ်။
NVMe ပါဝင်တဲ့ ကျွန်ုပ်တို့ရဲ့ Oracle workload က VM.DenseIO အတွက် 132,553 IOPS နဲ့ latency 257μs ရှိတဲ့ အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို ပြသခဲ့ပါတယ်။ BM.DenseIO မှာတော့ 1,043,104 IOPS နဲ့ latency 199μs ရှိခဲ့ပါတယ်။
Oracle 90-10 for BV မှာ VM.Standard ဟာ sub-millisecond latency ရှိပြီး 54K IOPS ကျော်တဲ့အထိ 72,533 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး latency 2.2ms ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ 1ms latency ကို 61K IOPS ခန့်မှာ ချိုးဖျက်နိုင်ခဲ့ပြီး latency 1.86ms နဲ့အတူ 76,908 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM နှစ်ခုစလုံးဟာ 1ms latency ကို မချိုးဖျက်ခင် 297K IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.Standard ဟာ latency 1.17ms နဲ့အတူ 305,771 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ latency 1.03ms နဲ့အတူ 297,509 IOPS အထိ အမြင့်ဆုံးစွမ်းဆောင်ရည်ရှိခဲ့ပါတယ်။
NVMe အတွက် Oracle 90-10 တွင် VM.DenseIO သည် အမြင့်ဆုံးစွမ်းဆောင်ရည် 133,330 IOPS နှင့် latency 163μs ရှိသည်။ BM.DenseIO သည် အမြင့်ဆုံးစွမ်းဆောင်ရည် 1,088,454 IOPS နှင့် latency 142μs ရှိသည်။
BV ပါဝင်တဲ့ Oracle 80-20 မှာ VM.Standard ဟာ 1ms အတွင်း 55K ခန့်အထိ ရောက်ရှိခဲ့ပြီး latency 2.14ms နဲ့ 74,032 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ VM.DenseIO ဟာ 51K ခန့်အထိ sub-millisecond latency ရှိပြီး latency 2ms နဲ့ 75,666 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM နှစ်ခုစလုံးဟာ 1ms မပြည့်ခင် 295K IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.Standard ဟာ latency 1.14ms နဲ့ 306,955 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ latency 893μs နဲ့ 295K IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။
NVMe ပါဝင်တဲ့ Oracle 80-20 မှာ VM.DenseIO ဟာ 108,483 IOPS နဲ့ latency 195μs အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ 956,326 IOPS နဲ့ latency 158μs အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။
နောက်တစ်ခုကတော့ VDI Full Clone ကို ကြည့်ခဲ့ပါတယ်။ BV နဲ့ boot လုပ်တဲ့အခါ VM.Standard က 40K IOPS အောက်လောက်မှာ 1ms ကို ချိုးဖျက်နိုင်ခဲ့ပြီး latency 4.2ms နဲ့ 56,057 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ VM.DenseIO က sub-millisecond latency နဲ့ 43K IOPS လောက်အထိ ရောက်ရှိခဲ့ပြီး latency 3.6ms နဲ့ 61,570 IOPS အထိ ရောက်ရှိခဲ့ပါတယ်။ BM နှစ်ခုစလုံးမှာ 200K IOPS threshold ကို ကျော်လွန်တဲ့အထိ sub-millisecond latency ရှိခဲ့ပါတယ်။ နှစ်ခုစလုံးဟာ latency 2.1 နဲ့ 220K IOPS လောက်အထိ ရောက်ရှိခဲ့ပြီး စွမ်းဆောင်ရည် ကျဆင်းသွားခဲ့ပါတယ်။
NVMe ဖြင့် Full Clone boot အတွက် VM.DenseIO သည် latency 235μs ဖြင့် 136K IOPS ခန့်တွင် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM.DenseIO သည် latency 213μs ဖြင့် 1,032,322 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
BV ဖြင့် VDI Full Clone Initial Log In ဖြင့် VM နှစ်ခုစလုံးသည် sub-millisecond latency ဖြင့် 41K IOPS ခန့်သို့ ရောက်ရှိခဲ့ပြီး VM.Standard သည် latency 3.7ms ဖြင့် 55,522 IOPS ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး VMDenseIO သည် 3.6ms latency ဖြင့် 59,560 IOPS ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM နှစ်ခုစလုံးသည် sub-millisecond latency ကို 203K IOPS ခန့်တွင် ချိုးဖျက်နိုင်ခဲ့သည် (standard သည် dense မတိုင်မီ ပြောင်းလဲသွားသည်)။ BM.Standard သည် 2.04ms latency ဖြင့် 225K IOPS ခန့်တွင် အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး BM.DenseIO သည် latency 1.8ms ဖြင့် 224,385 IOPS ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
NVMe ဖြင့် VDI Full Clone Initial Login အတွက် VM.Standard သည် latency 506μs ဖြင့် 59,883 IOPS ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM.DenseIO သည် latency 262μs ဖြင့် 467,761 IOPS ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
VDI Full Clone Monday Login with BV မှာ VM.Standard ဟာ sub-millisecond latency ရှိပြီး 36K IOPS နီးပါးလောက်သာရှိပြီး အမြင့်ဆုံး 50,685 IOPS နဲ့ latency 2.3ms ရှိပါတယ်။ VM.DenseIO ဟာ 38K IOPS ရဲ့ မြောက်ဘက်အထိ 1ms အောက်မှာ စွမ်းဆောင်ရည်ပြသခဲ့ပြီး 53,304 IOPS မှာ 2.2ms latency ရှိခဲ့ပါတယ်။ BM.Standard ဟာ 1ms latency ကို 205K IOPS လောက်မှာ ချိုးဖျက်ပြီး latency 1.5ms နဲ့ 224,764 IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ BM.DenseIO ဟာ 210K လောက်မှာ 1ms အထက်ကို ရောက်ရှိခဲ့ပြီး အမြင့်ဆုံး 220K IOPS ကျော်နဲ့ latency 1.2ms ရှိပါတယ်။
NVMe ဖြင့် VDI Full Clone Monday Login သည် VM.DenseIO ၏ အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို 44,384 IOPS ဖြင့် latency 356μs ဖြင့် ပြသခဲ့သည်။ BM.DenseIO သည် 356,691 IOPS ဖြင့် latency 252μs ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
ကျွန်ုပ်တို့ရဲ့ နောက်ဆုံးစမ်းသပ်မှုရွေးချယ်မှုကတော့ VDI Linked Clone ကိုကြည့်ပါတယ်။ BV နဲ့ boot test နဲ့ ပြန်စရင် VM.Standard ဟာ sub-millisecond latency ရှိပြီး 29K IOPS လောက်အထိ ရှိပြီး 2.4ms latency နဲ့ 38K IOPS လောက်အထိ အမြင့်ဆုံးရောက်ခဲ့ပါတယ်။ VM.DenseIO ဟာ 1ms ကိုကျော်မသွားခင် 32K IOPS လောက်အထိ ရောက်ရှိခဲ့ပြီး 2.16ms latency နဲ့ 38K IOPS လောက်အထိ အမြင့်ဆုံးရောက်ခဲ့ပါတယ်။ BM နှစ်ခုစလုံးဟာ 1ms latency မကျော်ခင် 100K IOPS လောက်အထိ ရောက်ရှိခဲ့ပါတယ်။ နှစ်ခုစလုံးဟာ 3ms latency နဲ့ 114K IOPS လောက် အမြင့်ဆုံးစွမ်းဆောင်ရည်ရှိခဲ့ပါတယ်။
VDI Linked Clone Boot for NVMe နဲ့ဆိုရင် VM.DenseIO အမြင့်ဆုံးရောက်ရှိမှုက 65,384 IOPS နဲ့ latency 238μs ရှိတာကို တွေ့ရပါတယ်။ BM.DenseIO က 555,004 IOPS နဲ့ latency 217μs ရှိတာကို တွေ့ရပါတယ်။
BV ဖြင့် Initial Login ဖြင့် VM နှစ်ခုစလုံးသည် 1ms latency ကို 28K IOPS ခန့်ဖြင့် ချိုးဖျက်နိုင်ခဲ့ပြီး VM.Standard သည် 36,682 IOPS ဖြင့် latency 1.6ms နှင့် VM.DenseIO သည် 38,525 IOPS ဖြင့် latency 1.6ms ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM နှစ်ခုစလုံးသည် 1ms latency ကို 132K IOPS ခန့်ဖြင့် ချိုးဖျက်နိုင်ခဲ့ပြီး BM.Standard သည် 140,848 IOPS ဖြင့် latency 1.3ms နှင့် BM.DenseIO သည် 139,883 IOPS နှင့် latency 1.2ms ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
NVMe ဖြင့် ကနဦးဝင်ရောက်မှုတွင် VM.DenseIO အတွက် 24,228 IOPS နှင့် 326μs နှင့် BM.DenseIO အတွက် 242,778 IOPS နှင့် 234μs အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို မြင်တွေ့ခဲ့ရသည်။
နောက်ဆုံးအနေနဲ့ VDI Linked Clone Monday Login with BV နဲ့ဆိုရင် VM.Standard ဟာ 27K IOPS အထိ sub-millisecond latency performance ရှိပြီး အမြင့်ဆုံး 39,874 IOPS နဲ့ latency 2.86ms ရှိပါတယ်။ VM.DenseIO ဟာ 25K IOPS မှာ 1ms ကို ချိုးဖျက်ပြီး အမြင့်ဆုံး 42,469 IOPS နဲ့ 3ms latency မှာ ရောက်ရှိခဲ့ပါတယ်။ BM နှစ်ခုစလုံးမှာ sub-millisecond latency ရှိပြီး နှစ်ခုစလုံးဟာ 146K IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး denseIO မှာ latency 1.6ms ရှိပြီး standard မှာ latency 1.76ms ရှိပါတယ်။
NVMe ဖြင့် VDI Linked Clone Monday Login ဖြင့် VM.DenseIO သည် 34,016 IOPS နှင့် latency 464μs တွင် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။ BM.DenseIO သည် 260,527 IOPS နှင့် latency 317μs တွင် အမြင့်ဆုံးရောက်ရှိခဲ့သည်။
ကောက်ချက်
Oracle ရဲ့ Cloud Infrastructure ဟာ Cloud ရဲ့ အဓိကပြဿနာတစ်ခုဖြစ်တဲ့ စွမ်းဆောင်ရည် ဒါမှမဟုတ် အားနည်းချက်ကို ဖြေရှင်းပေးပြီး bare metal instance တွေနဲ့ ဖြေရှင်းပေးပါတယ်။ Oracle ဟာ cloud မှာ မြင်တွေ့ရတဲ့ တခြားအရာတွေနဲ့ မတူတဲ့ စွမ်းဆောင်ရည်အတွက် bare metal နဲ့ virtual compute instance တွေအပြင် 25TB အထိ NVMe storage ပါဝင်တဲ့ NVMe ဗားရှင်းတွေကိုလည်း ပေးဆောင်ပါတယ်။ Oracle ရဲ့ ကိုးကားထားတဲ့ IOPS 5.1 million စွမ်းဆောင်ရည်ကို ရရှိဖို့အတွက် NVMe storage ထက်ပိုပြီး လိုအပ်ပါတယ်။ instance တွေမှာ OCPU 52 ခု၊ RAM 768GB၊ dual 25GbE NIC တွေနဲ့ locally attached NVMe storage 51TB အထိလည်း ပါဝင်ပါတယ်။ ဒီစွမ်းဆောင်ရည်အဆင့်ကို mission-critical database application တွေ၊ HPC workload တွေနဲ့ I/O intensive web application တွေလိုမျိုး use cases တွေအတွက် အဓိကအသုံးပြုပါတယ်။
စွမ်းဆောင်ရည်ပိုင်းမှာတော့ local NVMe storage (DenseIO) နဲ့ network block storage (Standard) နှစ်မျိုးလုံးကို အသုံးပြုပြီး bare metal (BM) နဲ့ VM shapes နှစ်မျိုးလုံးအတွက် VDBech စမ်းသပ်မှုတွေကို လုပ်ဆောင်ခဲ့ပါတယ်။ ရိုးရှင်းစွာပြောရရင် စွမ်းဆောင်ရည်က ကျွန်တော်တို့ကို အံ့အားသင့်စေခဲ့ပါတယ်။ စမ်းသပ်မှုတစ်ခုချင်းစီအတွက် DenseIO နဲ့ Standard အကြား latency ကွာခြားချက်က အရမ်းကောင်းတာကြောင့် ဇယားတွေကို set တစ်ခုတည်းမှာ ထားရင် ဖတ်ရခက်မှာဖြစ်လို့ chart set နှစ်ခုကို လုပ်ဆောင်ခဲ့ပါတယ်။ ဒီ instance တွေမှာ storage စွမ်းဆောင်ရည် ဘယ်လောက်ကောင်းလဲဆိုတာကို ကြည့်ရင် ရိုးရာ storage နဲ့ နှိုင်းယှဉ်ရင် ဈေးကွက်ထဲက အကောင်းဆုံး shared storage option အများစုနဲ့ ယှဉ်နိုင်ပေမယ့် cloud alternatives တွေနဲ့တော့ ယှဉ်နိုင်ပါတယ်။ iSCSI မှတစ်ဆင့် host လုပ်ပြီး backup လုပ်ထားတဲ့ attached BV တွေက latency နည်းပါးတဲ့အချိန်မှာ throughput နဲ့ bandwidth ရောနှောမှုအားကောင်းတာကို တွေ့ရပါတယ်။ ဒါကို ဆက်စပ်ပြောရရင် OCPU instance ၅၂ ခုမှာ BV ၃၂ ခု တပ်ဆင်ထားတဲ့ စမ်းသပ်မှုအများစုဟာ ကျွန်တော်တို့ရဲ့ lab မှာ စမ်းသပ်ထားတဲ့ all-flash storage array တွေရဲ့ စွမ်းဆောင်ရည်ထက် သာလွန်တာကို တွေ့ရပါတယ်။ အချို့က အနည်းငယ်ပိုမြန်နိုင်ပေမယ့် cloud instance တစ်ခုကို $250k+ AFA၊ FC switching နဲ့ multiple compute host တွေနဲ့ နှိုင်းယှဉ်ကြည့်မယ်ဆိုရင် အတော်လေး အထင်ကြီးစရာပါပဲ။
Oracle Cloud bare metal instance တွေကို အံ့မခန်းဖြစ်စေတာကတော့ locally attached NVMe storage ပါပဲ။ DenseIO2.8 မှာ device ၁ ခုရှိပြီး DenseIO2.52 မှာ device ၈ ခုရှိတာကြောင့် ဒီ instance တွေရဲ့ performance ကို IOPS သန်းပေါင်းများစွာနဲ့ တိုင်းတာနိုင်ပါတယ်။ NVMe SSD ၁ ခုပါတဲ့ instance က random 4K read speed 569k IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး ၈ ခုပါတဲ့ instance ကတော့ performance 4.4M IOPS အထိ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ Bandwidth ကလည်း ရယ်စရာမဟုတ်ပါဘူး။ instance အသေးက 2.5GB/s read အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး instance အကြီးက 20GB/s အထက်မှာ အမြင့်ဆုံးရောက်ရှိခဲ့ပါတယ်။ NVMe shapes တွေက locally attached storage တွေဖြစ်တာကြောင့် ကာကွယ်ဖို့လိုအပ်တဲ့ backup plan တစ်ခုရှိဖို့ သေချာအောင်လုပ်ပါ။
Oracle ဟာ cloud မှာ top-spec server တွေနဲ့ storage တွေကို တည်ဆောက်ထားပါတယ်။ သူတို့ရဲ့ bare metal instance တွေကို ယှဉ်နိုင်တဲ့ တစ်ခုတည်းသောအရာကတော့ ဒေသတွင်းမှာ host လုပ်ထားတဲ့ top-spec server တစ်ခုနဲ့ တခြား components တွေနဲ့ service တွေအားလုံးကို တည်ဆောက်ခြင်းပါပဲ။ cloud solution အားလုံးလိုပဲ Oracle က သင့်ရဲ့ instance တွေကို ဖွင့်ပိတ်လုပ်နိုင်ပြီး လိုအပ်သလို storage လိုအပ်ချက်တွေကို ချိန်ညှိပေးနိုင်တဲ့ flexibility ကို ပေးစွမ်းပါတယ်။ ဒီ instance တွေနဲ့ ပတ်သက်ပြီး ပေါ်လာမယ့် ထင်ရှားတဲ့ ပြဿနာကတော့ ကုန်ကျစရိတ်ပါပဲ။ Oracle Cloud ထဲမှာ instance တစ်ခုကို online မှာ ရရှိနိုင်ခြင်းရဲ့ လွယ်ကူမှုနဲ့ သင့်ရဲ့ data center မှာ နှိုင်းယှဉ်လို့ရတဲ့ hardware တွေကို setup လုပ်ဖို့အတွက် လိုအပ်တဲ့ ကြိုးစားအားထုတ်မှုနဲ့ ကုန်ကျစရိတ်က အဓိက ဆုံးဖြတ်ချက်ချရမယ့် အချက်ဖြစ်ကောင်းဖြစ်နိုင်ပါတယ်။ NVMe attached storage က ဈေးကြီးပေမယ့် ကျွန်တော်တို့ မြင်တွေ့ခဲ့ရတဲ့ performance benefits တွေကိုတော့ ငြင်းလို့မရပါဘူး။ data set ကြီးတွေမှာ processing time ကြောင့် ထိခိုက်ခံရတဲ့ လုပ်ငန်းတစ်ခုရှိရင် analytics လိုမျိုး workload တွေကို အပြီးသတ်ဖို့ ကျွန်တော်တို့သုံးခဲ့တဲ့ NVMe-based shapes တွေထက် ပိုလွယ်ကူပြီး ပိုမြန်တဲ့ ဖြေရှင်းချက်မရှိပါဘူး။ standard attached block shapes တွေက မကောင်းဘူးလို့ မဆိုလိုပါဘူး၊ NVMe shapes တွေက ကျန်တာတွေထက် သာလွန်လွန်းပါတယ်။ အဓိကအချက်ကတော့ မြင့်မားတဲ့စွမ်းဆောင်ရည်ရှိတဲ့ cloud ကနေ တိုင်းတာနိုင်တဲ့တန်ဖိုးကို ရရှိနိုင်တဲ့ ရှေ့ကိုမျှော်တွေးတတ်တဲ့ စီးပွားရေးလုပ်ငန်းတွေအနေနဲ့ Oracle ဘာတွေလုပ်ဆောင်နေလဲဆိုတာကို သေချာပေါက် အကဲဖြတ်သင့်ပါတယ်။ cloud ကိုသွားတဲ့အခါ ရွေးချယ်စရာတွေ အများကြီးရှိပေမယ့် Oracle Cloud bare metal instance တွေနဲ့ ကျွန်တော်တို့မြင်တွေ့ခဲ့ရတာလောက် မြန်ဆန်တာ မရှိပါဘူး၊ ဒါကြောင့် ဒီ solution တွေဟာ cloud services provider ကို ပေးအပ်တဲ့ ကျွန်တော်တို့ရဲ့ ပထမဆုံး Editor's Choice Award ရဲ့ ရှင်းလင်းပြတ်သားပြီး ထိုက်တန်တဲ့ ဆုရှင်တွေ ဖြစ်လာပါတယ်။
အမေဇုံ