Fusion-io ioDrive Duo Enterprise PCIe သုံးသပ်ချက်

StorageReview ရဲ့ စမ်းသပ်မှုပရိုတိုကောနဲ့ enterprise lab ဖွံ့ဖြိုးတိုးတက်မှု နှစ်ခုလုံးမှာ စဉ်ဆက်မပြတ်တိုးတက်မှုရဲ့ တစ်စိတ်တစ်ပိုင်းအနေနဲ့၊ ကျွန်တော်တို့ အရင်က ပြန်လည်သုံးသပ်ခဲ့တဲ့ ပထမမျိုးဆက် flash drive တွေကို ပြန်လည်လေ့လာသုံးသပ်နေပါတယ်။ အစောပိုင်း PCIe flash storage device တွေရဲ့ ပြန်လည်သုံးသပ်ချက်တွေက ဒုတိယမျိုးဆက် PCIe storage card တွေနဲ့ application accelerator တွေရဲ့ သုံးသပ်ချက်အသစ်တွေကို မထုတ်ပြန်ခင်မှာ ကျွန်တော်တို့ရဲ့ enterprise review လုပ်ငန်းစဉ်ကို ပြန်လည်ပြုပြင်ပြီး ပြန်လည်ချိန်ညှိဖို့ အခွင့်အရေးပေးခဲ့ပါတယ်။ enterprise storage ဝယ်သူနဲ့ ပိုသက်ဆိုင်တဲ့ စမ်းသပ်ပရိုတိုကောတွေကို ပိုမိုလေ့လာနေချိန်မှာပဲ စက်မှုလုပ်ငန်းဦးဆောင်သူတွေဆီကနေ ပထမနဲ့ ဒုတိယမျိုးဆက်ကတ်တွေကို ထောက်ပံ့ပေးပြီး ပြီးခဲ့တဲ့လတွေအတွင်း ပြန်လည်ပြင်ဆင်ထားတဲ့ စမ်းသပ်နည်းလမ်းကို ကျွန်တော်တို့ ဖြတ်သန်းနေခဲ့ပါတယ်။ ဒီသုံးသပ်ချက်မှာ၊ 640GB Fusion ioDrive Duo နဲ့ ထပ်မံလုပ်ဆောင်နေပါတယ် - ဒီတစ်ခါတော့ Windows နဲ့ Linux နှစ်ခုလုံးမှာ ပိုမိုရှုပ်ထွေးတဲ့ စမ်းသပ်ချက်တွေကို အသုံးပြုထားပါတယ်။

StorageReview အဖွဲ့သည် လုပ်ငန်းသိုလှောင်မှုကို မည်သို့အကဲဖြတ်သည်ဆိုသည့်အချက်သည် လုပ်ငန်းခေါင်းဆောင်များနှင့် အဓိကမိတ်ဖက်များထံမှ စဉ်ဆက်မပြတ်ထည့်သွင်းမှုများကြောင့် ဆက်လက်တိုးတက်ပြောင်းလဲနေပါသည်။ ဤပူးပေါင်းဆောင်ရွက်မှုချဉ်းကပ်မှုသည် ဤကဲ့သို့သော ပြန်လည်သုံးသပ်ချက်ရလဒ်ကို ပိုမိုအသေးစိတ်ကျစေပြီး လုပ်ငန်းတစ်ခုလုံးနှင့် သက်ဆိုင်စေသည်။ ထုတ်လုပ်သူများနှင့် နီးကပ်စွာလုပ်ဆောင်ခြင်းဖြင့် ကျွန်ုပ်တို့၏သုံးသပ်ချက်များတွင် စမ်းသပ်မှုအကြံဉာဏ်အသစ်များကို စဉ်ဆက်မပြတ်ထည့်သွင်းနိုင်ပြီး အခြားနည်းဖြင့် လျစ်လျူရှုထားနိုင်သည့်အရာများကို လွှမ်းခြုံနိုင်စေပါသည်။ အောက်တွင် စာဖတ်သူများသည် ioDrive Duo ကို အသေးစိတ်အချက်အလက်များအထိ ခွဲခြမ်းစိတ်ဖြာရန် ရည်စူးထားသော ဇယား ၇၀ ကျော်ကို တွေ့ရှိနိုင်ပါသည်။ ၎င်းတွင် တီထွင်ဆဲ application-level benchmarks စီးရီးအသစ်များပင် မပါဝင်ပါ။ အသေးစိတ်အချက်အလက်များသည် အချို့အတွက် အလွန်အကျွံဖြစ်နေပုံရသော်လည်း သိုလှောင်မှုပြဿနာကို ဖြေရှင်းရန် သီးခြားကိရိယာတစ်ခု လိုအပ်သူများအတွက် ဤအသေးစိတ်အချက်အလက်များသည် အရေးကြီးပါသည်။ စာဖတ်သူများအဆင်ပြေစေရန်အတွက် သုံးသပ်ချက်တစ်ခုလုံးကို အောက်တွင် အမြဲတမ်းကဲ့သို့ စာမျက်နှာတစ်ခုတည်းတွင် တင်ထားပါသည်။

ioDrive ရဲ့ စွမ်းဆောင်ရည်ကို မပြောခင်မှာ Fusion-io ရဲ့ flash storage နဲ့ ပုံမှန် SSD တို့ရဲ့ အဓိက ကွာခြားချက်အချို့ကို မီးမောင်းထိုးပြဖို့ အရေးကြီးပါတယ်။ SSD တွေပေါ်က Flash (Solid State Drive ဆိုတဲ့ နာမည်အတိုင်း) တွေကို SATA ဒါမှမဟုတ် SAS interface ရဲ့ နောက်ကွယ်မှာ ဝှက်ထားပြီး NAND ကို compatibility အကြောင်းပြချက်တွေကြောင့် ဖုံးကွယ်ထားပါတယ်။ ioDrive ထုတ်ကုန်နဲ့ဆိုရင် user တွေဟာ SSD ထက် latency နည်းပါးပြီး overall performance ပိုကောင်းတဲ့ flash memory storage tier ကို အသုံးပြုခွင့် ရရှိပါတယ်။ ဒီလိုဖြစ်ရတဲ့ အကြောင်းရင်းတွေကတော့ architecture နဲ့ ioDrive က host system နဲ့ interface လုပ်ပုံကြောင့်ပါ။

Enterprise PCIe SSD တစ်ခုမှာ block-device controller များစွာနဲ့ ကတ်တစ်ခုတည်းပေါ်မှာ device များစွာကို RAID လုပ်ဖို့ chip တစ်ခုထပ်ထည့်ထားလေ့ရှိပေမယ့် Fusion-io ကတော့ ကွဲပြားတဲ့ ချဉ်းကပ်မှုတစ်ခုကို လုပ်ဆောင်ပါတယ်။ Fusion ioMemory ဟာ processor လိုမျိုး NAND Flash နဲ့ interface လုပ်ပြီး system memory နဲ့ interact လုပ်ပါတယ်။ ဒါကို PCIe ကနေ တိုက်ရိုက်ဆက်သွယ်တဲ့ Fusion-io ရဲ့ NAND controller (FPGA) နဲ့ host system မှာ install လုပ်ထားတဲ့ Fusion-io ရဲ့ driver ဒါမှမဟုတ် Virtual Storage Layer software ပေါင်းစပ်အသုံးပြုပြီး device ကို traditional block-device အဖြစ်ပြောင်းလဲပေးပါတယ်။ Fusion-io ရဲ့ Virtual Storage Layer ဒါမှမဟုတ် VSL မှတစ်ဆင့် software ဟာ block device ကို compatibility အတွက် emulate လုပ်ပေမယ့် မကြာသေးခင်က Fusion-io က application အချို့အတွင်း native access (kernel block layer ကိုကျော်ပြီး) ခွင့်ပြုတဲ့ SDK တစ်ခုကို ထုတ်ပြန်ခဲ့ပါတယ် ။

IoMemory သည် VSL drivers များအလုပ်လုပ်ရန်အတွက် system resources များကို သုံးစွဲသောကြောင့် ရိုးရာနည်းလမ်းမဟုတ်ပါ။ host CPU ကို အသုံးချပြီး system memory တွင် footprint ကိုလည်း ဖန်တီးပေးပါသည်။ Fusion-io ၏ အဆိုအရ ဤ architecture သည် RAM ၏ architecture နှင့် ပိုမိုဆင်တူသောကြောင့် ioMemory ဟု အမည်ပေးထားသည်။ အကျိုးကျေးဇူးများတွင် ဖိုင်တည်နေရာရှာဖွေမှုများကို ပိုမိုမြန်ဆန်စွာ ပြုလုပ်နိုင်ပြီး ioMemory သည် CPU ကို ထိမှန်သော်လည်း ၎င်း၏အသုံးပြုမှုသည် အလွန်ထိရောက်ပြီး transactional latency ကို လျှော့ချခြင်းဖြင့် စွမ်းဆောင်ရည်ကို အမှန်တကယ် မောင်းနှင်ပါသည်။ စီမံခန့်ခွဲမှုအရ နောက်ထပ် core architecture အကျိုးကျေးဇူးတစ်ခုမှာ Fusion-io သည် FPGA ကို NAND controller အဖြစ် အသုံးပြုသောကြောင့် bug fixes များနှင့် performance enhancements များကို ဖြေရှင်းနိုင်သည့် အလွန်နိမ့်သော software/firmware updates များကို ခွင့်ပြုသည်။ ၎င်းသည် controller အသစ်တစ်ခု တည်ဆောက်ခြင်းဖြင့်သာ အခြေခံပြောင်းလဲမှုများကို ပြုလုပ်နိုင်သည့် standard SSD controllers များနှင့် ဆန့်ကျင်ဘက်ဖြစ်သည်။

Fusion-io ioDrive Duo သတ်မှတ်ချက်များ

• Single Level Cell (SLC)
  • 320GB ioDrive Duo SLC
    • ၁.၅GB/s ဖတ်ရှုမှု bandwidth (၆၄kB)
    • ၁.၁GB/s ရေးသားမှု bandwidth (၆၄kB)
    • ၁၈၅,၀၀၀ ဖတ်ရှုမှု IOPS (၅၁၂-ဘိုက်)
    • ၂၇၈,၀၀၀ ရေးသား IOPS (၅၁၂-ဘိုက်)
    • ဝင်ရောက်ချိန် နှောင့်နှေးမှု 0.026ms (512-byte)
  • 640GB ioDrive Duo SLC
    • ၁.၅GB/s ဖတ်ရှုမှု bandwidth (၆၄kB)
    • ၁.၁GB/s ရေးသားမှု bandwidth (၆၄kB)
    • ၁၈၅,၀၀၀ ဖတ်ရှုမှု IOPS (၅၁၂-ဘိုက်)
    • ၂၇၈,၀၀၀ ရေးသား IOPS (၅၁၂-ဘိုက်)
    • ဝင်ရောက်ချိန် နှောင့်နှေးမှု 0.026ms (512-byte)
• Multi Level Cell (MLC)
  • 640GB ioDrive Duo MLC
    • ၁.၅GB/s ဖတ်ရှုမှု bandwidth (၆၄kB)
    • ၁.၁GB/s ရေးသားမှု bandwidth (၆၄kB)
    • ၁၈၅,၀၀၀ ဖတ်ရှုမှု IOPS (၅၁၂-ဘိုက်)
    • ၂၇၈,၀၀၀ ရေးသား IOPS (၅၁၂-ဘိုက်)
    • ဝင်ရောက်ချိန် နှောင့်နှေးမှု 0.029ms (512-byte)
  • 1.28TB ioDrive Duo MLC
    • ၁.၅GB/s ဖတ်ရှုမှု bandwidth (၆၄kB)
    • ၁.၁GB/s ရေးသားမှု bandwidth (၆၄kB)
    • ၁၈၅,၀၀၀ ဖတ်ရှုမှု IOPS (၅၁၂-ဘိုက်)
    • ၂၇၈,၀၀၀ ရေးသား IOPS (၅၁၂-ဘိုက်)
    • ဝင်ရောက်ချိန် နှောင့်နှေးမှု 0.03ms (512-byte)
• PCI-Express 2.0x8
• OS ကိုအသုံးပြုပုံများ
  • မိုက်ခရိုဆော့ဖ်: ဝင်းဒိုး ၆၄-ဘစ် မိုက်ခရိုဆော့ဖ် XP/Vista/Win7/Server 2003/2008/2008 R2
  • Linux: RHEL 5/6; SLES 10/11; OEL 5/6; CentOS 5/6; Debian Squeeze; Fedora 15/16; openSUSE 12; Ubuntu 10/11
  • UNIX: Solaris 10 U8/U9/U10 x64; OpenSolaris 2009.06 x64; OSX 10.6/10.7, HP-UX* 11i
  • Hypervisor များ- VMware ESX 4.0/4.1/ESXi 4.1/5.0၊ Hyper-V ပါဝင်သော Windows 2008 R2၊ Hyper-V Server 2008 R2
• လည်ပတ်မှုအပူချိန်: 0-55C
• ငါးနှစ်အာမခံ သို့မဟုတ် အမြင့်ဆုံးခံနိုင်ရည်ကို အသုံးပြုထားသည်
• VSL ဗားရှင်းကို ပြန်လည်သုံးသပ်ထားသည်- ၃.၁.၁

ဒီဇိုင်းနှင့်တည်ဆောက်ပါ

Fusion ioDrive Duo သည် Full-Height Half-Length x8 PCI-Express ကတ်တစ်ခုဖြစ်ပြီး main interface board နှင့် ချိတ်ဆက်ထားသော ioDimms နှစ်ခုပါရှိသည်။ PCI-Express ကတ်သည် စက်ပိုင်းဆိုင်ရာအားဖြင့် x8 device တစ်ခုဖြစ်သော်လည်း Gen1 platform များတွင် bandwidth အတွက် 8-lanes ကိုအသုံးပြုပြီး PCIe Gen2 system များတွင် 4-lanes သာလိုအပ်သည်။ ကတ်တစ်ခုစီသည် PCIe ချိတ်ဆက်မှု၏ 4 lanes ကိုအသုံးပြုသည့် ထူးခြားသော 320GB ioMemory device တစ်ခုကို ကိုယ်စားပြုသည်။ ဒီဇိုင်းသည် အလွန်ကျစ်လစ်ပြီး သန့်ရှင်းသပ်ရပ်ပြီး ကတ်၏နောက်ကျောဘက်တွင် ခိုင်ခံ့သော support bracket ပါဝင်သည်။ ၎င်းသည် ကြမ်းတမ်းသောလည်ပတ်မှုအခြေအနေများတွင် အလုပ်လုပ်နိုင်စေရန်နှင့် လှပသောအသွင်အပြင်ကို ပေးစွမ်းသည်။

MLC-based ioDrive Duo ရဲ့ အဓိကအချက်ကတော့ ioDimms နှစ်ခုပါ။ တူညီတဲ့ ioDimm တစ်ခုစီဟာ သူ့ရဲ့ကိုယ်ပိုင် Xilinx Virtex-5 FPGA နဲ့ 400GB MLC NAND pool ပါတဲ့ ioDrive တစ်ခုကို ကိုယ်စားပြုပါတယ်။ ကျွန်တော်တို့ သုံးသပ်ခဲ့တဲ့ ioDrive Duo မှာ Samsung NAND ကို အသုံးပြုခဲ့ပေမယ့် Fusion-io က ထုတ်လုပ်သူနဲ့ မသက်ဆိုင်ပါဘူး။ NAND ကို device တစ်ခုစီမှာ double-stacked 16GB chip ၂၅ ခု ခွဲထားပြီး stock formatting နဲ့ 320GB ကို အသုံးပြုနိုင်ပါတယ်။ အဲဒီအချိုးက stock over-provisioning levels ကို 20% အထိ မြင့်တက်စေပြီး enterprise flash devices အများစုနဲ့ ညီမျှပါတယ်။ Fusion-io က background activities တွေအတွက် user-capacity ကို လဲလှယ်ခြင်းအားဖြင့် customization နဲ့ performance တိုးမြှင့်နိုင်အောင် over-provisioning levels တွေကို ပြုပြင်နိုင်စွမ်းလည်း ပေးစွမ်းပါတယ်။

လုပ်ဆောင်ချက်ရှုထောင့်မှကြည့်လျှင် ioDrives အားလုံးတွင် ပါဝါဖွင့်ချိန်မှ ပါဝါပိတ်ချိန်အထိ drive ၏အခြေအနေကိုပြသသည့် ညွှန်ပြချက် LED များပါရှိသည်။ active ဖြစ်နေသော LED များပေါ် မူတည်၍ ကတ်၏ အောက်ပါမုဒ်များကို ပြသပေးလိမ့်မည်။

• ပါဝါပိတ်ပါ
• ပါဝါဖွင့်ပါ (ဒရိုက်ဘာ မတင်ရသေးပါ၊ စက်ပစ္စည်း မချိတ်ဆက်ထားပါ)
• ပါဝါဖွင့်ပါ (ဒရိုက်ဘာတင်ပြီးပါပြီ၊ စက်ပစ္စည်းမချိတ်ဆက်ထားပါ)
• တက်ကြွသောရေးသားမှုလုပ်ဆောင်ချက်
• တက်ကြွသော စာဖတ်ခြင်း လှုပ်ရှားမှု
• တည်နေရာပြတိုင်

ပိုမိုရိုးရာနည်းလမ်းအတွက် ioDrive Duo တွင် စံ HDD Activity LED ချိတ်ဆက်မှုလည်း ပါဝင်သည်။ ဤချိတ်ဆက်မှုသည် ကွန်ပျူတာ case ၏ ရှေ့တွင်တပ်ဆင်ထားသော HDD activity light ကို ioDrive Duo နှင့် ချိတ်ဆက်နိုင်စေပါသည်။

ioDrive Duo မှာ အပူစုပ်စက် သုံးခုပါဝင်ပြီး passively cooled ဖြစ်ပါတယ်။ forced-cooling server environment မှာ အလုပ်လုပ်ဖို့ ဒီဇိုင်းထုတ်ထားပါတယ်။ ဒီအပူစုပ်စက်တွေက ioDimm တစ်ခုစီမှာရှိတဲ့ Xilinx Virtex-5 FPGA တစ်ခုအပြင် device နှစ်ခုလုံးကို single PCIe slot နဲ့ ချိတ်ဆက်ပေးတဲ့ PCIe-switch ကိုလည်း အအေးပေးပါတယ်။ Fusion-io က ပတ်ဝန်းကျင်အပူချိန် 55C အောက်ရှိတဲ့ 300LFM လေစီးဆင်းမှုကို အကြံပြုထားပါတယ်။ ပျက်စီးမှုကို ကာကွယ်ဖို့အတွက် ioDrive ကို internal temperature 78C ရောက်ပြီး 85C မှာ power off ဖြစ်ရင် performance ကို ထိန်းညှိပေးဖို့ ဒီဇိုင်းထုတ်ထားပါတယ်။ ဒီကတ်တွေကို workstation environment အတွက် ဒီဇိုင်းထုတ်ထားတာ မဟုတ်ဘူးဆိုတာ သတိပြုသင့်ပါတယ်။ ဘာလို့လဲဆိုတော့ workstation တွေမှာ stock configuration တွေမှာ PCIe add-on တွေအတွက် cooling support မပေးထားလို့ပါ။ အဲဒီဈေးကွက်တွေကို ဖြေရှင်းဖို့အတွက် Fusion-io က ioFX ကို မကြာသေးခင်က ကြေညာခဲ့ပါတယ် ။ active cooling ပါတဲ့ single ioDimm တစ်ခုပါ။

Fusion “Duo” ioMemory devices များနှင့် ယှဉ်ပြိုင် PCIe solutions အများစုကြား နောက်ထပ်ကွာခြားချက်တစ်ခုမှာ ၎င်းတို့သည် အပြည့်အဝစွမ်းဆောင်ရည်ကို ထိန်းသိမ်းရန်အတွက် x8 PCIe 2.0 ချိတ်ဆက်မှုမှ ယေဘုယျအားဖြင့် ပံ့ပိုးပေးထားသည်ထက် ပိုမိုသော ပါဝါလိုအပ်ခြင်းဖြစ်သည်။ PCIe 2.0 လျှပ်စစ်သတ်မှတ်ချက်သည် x8 ချိတ်ဆက်မှုမှ 25w ကို ထုတ်ယူခွင့်ပြုပြီး မြင့်မားသောရေးသားမှုအခြေအနေများတွင် ioDrive Duo ကဲ့သို့သော twin-ioDimm မော်ဒယ်များသည် ကျော်လွန်နိုင်သည်။ ၎င်းတို့သည် အပိုပါဝါမပေးဘဲ သတ်မှတ်ချက်နှင့် ကိုက်ညီမည်ဖြစ်သော်လည်း အပြည့်အဝရေးသားမှုစွမ်းဆောင်ရည်မှာ အကန့်အသတ်ရှိလိမ့်မည်။ ဤပြဿနာကို ဖြေရှင်းရန် Fusion-io သည် ဖြေရှင်းချက်နှစ်ခုကို ပေးဆောင်သည်။ တစ်ခုမှာ external power adapter လိုအပ်ပြီး နောက်တစ်ခုမှာ ၎င်းကို ပံ့ပိုးပေးသော စနစ်များတွင် ကတ်ကို 25 watts ထက်ပို၍ ထုတ်ယူခွင့်ပြုခြင်းဖြစ်သည်။ တပ်ဆင်မှုအတွက် မည်သည့်ရွေးချယ်မှုသည် အသင့်တော်ဆုံးဖြစ်သည်ကို ဆုံးဖြတ်ရန်အတွက် Fusion-io တွင် tier one server အများစုအတွက် server configuration လမ်းညွှန်ချက်တစ်ခုရှိပြီး အကောင်းဆုံး case setup ညွှန်ကြားချက်များကို ပေးပါသည်။

အသုံးပြုသူရဲ့ဒေတာကိုကာကွယ်ဖို့အတွက် Fusion-io မှာ အဓိကလုပ်ဆောင်ချက်နှစ်ခုပါဝင်ပါတယ်။ ပထမအချက်အနေနဲ့ Fusion-io ထုတ်ကုန်တွေမှာ မမျှော်လင့်ထားတဲ့ ပါဝါပြတ်တောက်မှုတွေမှာ ဒေတာတည်ငြိမ်မှုကိုသေချာစေမယ့် ပါဝါဖြတ်တောက်မှုလုပ်ဆောင်ချက်တွေပါဝင်ပါတယ်။ NAND die ချို့ယွင်းမှုလိုမျိုး ရှားရှားပါးပါး ချို့ယွင်းမှုမျိုးတွေအတွက် ပထမမျိုးဆက် Fusion-io စက်ပစ္စည်းတွေမှာ NAND ဗိသုကာရဲ့ အားသာချက်တစ်ခုကတော့ Flashback redundancy ဖြစ်ပြီး စက်ပစ္စည်းတစ်ခုလုံးကို မပျက်စီးစေဘဲ NAND တစ်ခုတည်း ချို့ယွင်းမှုကို ခွင့်ပြုပေးပါတယ်။ ဒုတိယမျိုးဆက် မော်ဒယ်တွေမှာ Adaptive Flashback ပါဝင်ပြီး NAND ချို့ယွင်းမှုများစွာကို ပံ့ပိုးပေးပါတယ်။

Software များ

Fusion-io သည် ကောင်းမွန်စွာ ပြင်ဆင်ထားသော အလိုလိုသိနိုင်သော ဆော့ဖ်ဝဲလ်များစွာကို ပေးဆောင်ရာတွင် ဦးဆောင်နေပြီး သိုလှောင်မှုရောင်းချသူ အနည်းငယ်သာ ၎င်းတို့သည် ဆော့ဖ်ဝဲလ်တစ်ခုခု ပေးဆောင်ပါက ကိုက်ညီမှု မရှိပါ။ Fusion-io သည် GUIs နှင့် console applications နှစ်မျိုးလုံးမှတစ်ဆင့် အဓိက operating system အားလုံးရှိ ioMemory devices များကို အပြည့်အဝ စီမံခန့်ခွဲရန် utilities များကို ပေးဆောင်ပါသည်။ over-provisioning ကို အလွယ်တကူ စီမံခန့်ခွဲနည်းများ အပါအဝင် user capacity ကို လဲလှယ်ခြင်းဖြင့် စွမ်းဆောင်ရည်ရရှိရန်၊ drive stats များကို စောင့်ကြည့်ခြင်း၊ card ၏ လုပ်ဆောင်နေသည့်အရာများကို စက္ကန့်တိုင်း live streaming data များအထိ စီမံခန့်ခွဲမှု features များ ပါဝင်သည်။ အခြား PCIe storage ထုတ်လုပ်သူ မည်သည့်ကုမ္ပဏီမှ ဤအဆင့် drive management support ကို ပေးဆောင်ရန် နီးစပ်ခြင်း မရှိပါ။ အသုံးပြုရလွယ်ကူမှု ဤအဆင့်ကို ပေးဆောင်ရန် နီးစပ်ခြင်း မရှိပါ။

ioSphere Low-Level Format (High-Performance Mode သို့ Over-Provisioning)

ioSphere software ရဲ့ စိတ်ဝင်စားဖွယ်အကောင်းဆုံး စွမ်းရည်တွေထဲက တစ်ခုကတော့ ioMemory device ကို ထိမှန်တဲ့ activity အမျိုးအစားကို မြင်နိုင်ခြင်းပါပဲ။ ဒီအချက်အလက်တွေမှာ bandwidth နဲ့ I/O activity ကနေ လက်ရှိ device အပူချိန်၊ ကျန်ရှိနေတဲ့ device endurance ဒါမှမဟုတ် VSL drivers တွေအသုံးပြုတဲ့ system resources အထိ ပါဝင်ပါတယ်။

ioSphere တိုက်ရိုက်ဖျော်ဖြေမှု ထုတ်လွှင့်ခြင်း

ပိုမိုအသေးစိတ်အချက်အလက်များကိုကြည့်ရှုရန်အတွက် လက်ရှိရွေးချယ်ထားသော ioMemory device ၏ သတ်မှတ်ချက်များအပြည့်အစုံကို ပရင့်ထုတ်ထားသော စာမျက်နှာတစ်ခုလည်းရှိပါသည်။ ၎င်းသည် device သို့ သို့မဟုတ် ၎င်းမှ ထုတ်လွှင့်သော အချက်အလက်စုစုပေါင်းပမာဏမှစ၍ PCIe bus မှတစ်ဆင့် လက်ရှိပါဝါဆွဲယူမှုအထိ မည်သည့်အရာမဆို ဖြစ်နိုင်သည်။

ioShpere တစ်သက်တာအသုံးပြုမှုအချက်အလက်

သင့်အချက်အလက်များကိုရယူရန် GUI သို့မဟုတ် console interface ကိုနှစ်သက်သည်ဖြစ်စေ၊ သင့် ioDrive Duo ကို setup လုပ်ရန်နှစ်သက်သည်ဖြစ်စေ၊ Fusion-io သည် polling drive status မှ drive ကို format လုပ်ခြင်းအထိ အရာအားလုံးကိုကိုင်တွယ်ရန် console-based utilities အပြည့်အစုံကိုလည်း ပေးဆောင်ပါသည်။ ဤ utilities အားလုံးကို operating system များစွာတွင်အလုပ်လုပ်ရန် setup လုပ်ထားသောကြောင့် မည်သည့် platform ကိုအသုံးပြုနေသည်ဖြစ်စေ Fusion-io ထုတ်ကုန်ကိုစီမံခန့်ခွဲရန် အပို OS တစ်ခုကို load လုပ်ရန်မလိုအပ်ပါ။

Fusion-io Command Line အခြေအနေ (အခြေခံ)

နောက်ခံနှင့် နှိုင်းယှဉ်နိုင်သော အရာများကို စမ်းသပ်ခြင်း

Enterprise hardware ကို စမ်းသပ်တဲ့အခါ၊ ပတ်ဝန်းကျင်ဟာ အကဲဖြတ်ဖို့အသုံးပြုတဲ့ စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်တွေလိုပဲ အရေးကြီးပါတယ်။ StorageReview မှာ ကျွန်ုပ်တို့စမ်းသပ်တဲ့ device တွေဟာ နောက်ဆုံးမှာ ဦးတည်သွားမယ့် data center အများစုမှာတွေ့ရတဲ့ hardware နဲ့ infrastructure တွေကို ပေးဆောင်ပါတယ်။ ၎င်းမှာ enterprise server တွေအပြင် networking၊ rack space၊ power conditioning/monitoring နဲ့ device တစ်ခုရဲ့ စွမ်းဆောင်ရည်ကို အကဲဖြတ်ဖို့အတွက် အတန်းအစားတူ comparable hardware လိုမျိုး သင့်လျော်တဲ့ infrastructure equipment တွေ ပါဝင်ပါတယ်။ ကျွန်ုပ်တို့စမ်းသပ်နေတဲ့ equipment ရဲ့ ထုတ်လုပ်သူက ကျွန်ုပ်တို့ရဲ့ review တွေကို ငွေပေးချေတာ ဒါမှမဟုတ် ထိန်းချုပ်တာ မရှိပါဘူး။ သက်ဆိုင်ရာ comparable တွေကို ကျွန်ုပ်တို့ရဲ့ lab မှာရှိတဲ့ product တွေကနေ ကျွန်ုပ်တို့ရဲ့ ဆုံးဖြတ်ချက်အရ ရွေးချယ်ပါတယ်။

StorageReview Enterprise စမ်းသပ်ပလက်ဖောင်း-

Lenovo ThinkServer RD240

• ၂ x Intel Xeon X5650 (2.66GHz, 12MB Cache)
• Windows Server 2008 Standard Edition R2 SP1 64-Bit နှင့် CentOS 6.2 64-Bit
• Intel 5500+ ICH10R ချစ်ပ်ဆက်
• မှတ်ဉာဏ် - 8GB (2 x 4GB) 1333Mhz DDR3 မှတ်ပုံတင်ထားသော RDIMM များ

640GB Fusion-io ioDrive Duo

• ထုတ်ဝေသည့်ခုနှစ်: ၂ နာရီခွဲ၊ ၂၀၁၁
• NAND အမျိုးအစား: MLC
• ထိန်းချုပ်ကိရိယာ: 2 x ကိုယ်ပိုင်
• စက်ပစ္စည်းမြင်နိုင်စွမ်း- JBOD၊ OS ပေါ်မူတည်၍ software RAID
• Fusion-io VSL ဝင်းဒိုး: 3.1.1
• Fusion-io VSL Linux 3.1.1

300GB LSI WarpDrive SLP-300

• ထုတ်ဝေသည့်ခုနှစ်: ၂ နာရီခွဲ၊ ၂၀၁၁
• NAND အမျိုးအစား: SLC
• ထိန်းချုပ်ကိရိယာ: LSI SandForce SF-1500 မှတစ်ဆင့် LSI SAS2008 PCIe မှ SAS Bridge အထိ 6 x LSI
• စက်ပစ္စည်း မြင်နိုင်စွမ်း- ပြင်ဆင်ထားသော ဟာ့ဒ်ဝဲ RAID0
• LSI ဝင်းဒိုး: ၂.၁၀.၅၁.၀
• LSI Linus: မူရင်း CentOS 6.2 ဒရိုက်ဘာ

1.6TB OCZ Z-Drive R4

• ထုတ်ဝေသည့်ခုနှစ်: ၂ နာရီခွဲ၊ ၂၀၁၁
• NAND အမျိုးအစား: MLC
• ထိန်းချုပ်ကိရိယာ: custom OCZ VCA PCIe မှ SAS Bridge မှတစ်ဆင့် 8 x LSI SandForce SF-2200
• စက်ပစ္စည်း မြင်နိုင်စွမ်း- ပြင်ဆင်ထားသော ဟာ့ဒ်ဝဲ RAID0
• OCZ Windows ဒရိုက်ဘာ: 1.3.6.17083
• OCZ Linux ဒရိုက်ဘာ: 1.0.0.1480

စံ ဓာတုဗေဒဆိုင်ရာ စံနှုန်းများ

ဤသုံးသပ်ချက်၏ စံပေါင်းစပ် IOMeter စမ်းသပ်မှုအပိုင်းကို ကျွန်ုပ်တို့ အပိုင်းနှစ်ပိုင်းခွဲထားပါသည်။ ပထမအပိုင်းမှာ ကျွန်ုပ်တို့၏ စံနိမ့်သော queue-depth စမ်းသပ်မှုများဖြစ်ပြီး၊ ၎င်းကို worker တစ်ဦးလျှင် 4 ဦး (manager နှစ်ဦးပေါ်တွင် စုစုပေါင်း worker 4 ဦး ဖြန့်ကျက်ထားသည်) တွင် လုပ်ဆောင်ပါသည်။ ကနဦးစမ်းသပ်မှုများသည် single-user ပတ်ဝန်းကျင်များနှင့် ပိုမိုကိုက်ညီသော်လည်း၊ ဒုတိယပိုင်းတွင် queue depth range မြင့်မားခြင်းသည် I/O request များကို စီထားသည့် server တွင် card မှ မြင်တွေ့ရမည့်အရာနှင့် ပိုမိုဆင်တူပါသည်။

ကျွန်ုပ်တို့ရဲ့ ပထမဆုံးစမ်းသပ်မှုက စဉ်ဆက်မပြတ် burst အခြေအနေမှာ straight-line sequential read နဲ့ write speeds တွေကို ကြည့်ရှုပါတယ်။ Fusion-io က 640GB MLC-based ioDrive Duo မှာ read speed 1.5GB/s နဲ့ write speed 1.0GB/s ရှိတယ်လို့ ဖော်ပြထားပါတယ်။

ကျွန်ုပ်တို့သည် တစ်စက္ကန့်လျှင် 1,584MB ဖတ်ရှုမှုနှင့် တစ်စက္ကန့်လျှင် 1,045MB ရေးသားမှုတို့၏ အဆင့်ဆင့်လွှဲပြောင်းမှုစွမ်းဆောင်ရည်ကို တိုင်းတာခဲ့ပါသည်။

နောက်တစ်ခုအနေနဲ့ IOMeter မှာ 2MB ပမာဏရှိတဲ့ large-block random transfer တွေကို ကြည့်ပါမယ်။

2MB ကျပန်းလွှဲပြောင်းမှုဖြင့် ioDrive Duo သည် ဖတ်ရှုမှုအမြန်နှုန်း 1,589MB/s နှင့် ရေးသားမှုအမြန်နှုန်း 1046MB/s ကို ထိန်းသိမ်းထားနိုင်သည်။

ကျွန်ုပ်တို့၏ နောက်ထပ်စမ်းသပ်မှုတွင် စုစုပေါင်းလုပ်သားလေးဦးစီတွင် တန်းစီအနက် ၁ ခုစီရှိသော တန်းစီအနက်နည်းသော ကျပန်း 4K လွှဲပြောင်းမှုအမြန်နှုန်းများကို လေ့လာသည်။

queue depth နည်းတဲ့အခါမှာတောင် Fusion ioDrive Duo ဟာ အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို ပေးစွမ်းနိုင်ပြီး 189MB/s read နဲ့ 366MB/s write ဒါမှမဟုတ် 48,403 IOPS read နဲ့ 93,740 IOPS write speeds ရှိပါတယ်။

စွမ်းဆောင်ရည်နှင့် latency တို့သည် ဒွန်တွဲနေသောကြောင့်၊ ကျွန်ုပ်တို့၏ low queue depth 4K random transfer test အတွင်း ပျမ်းမျှနှင့် အမြင့်ဆုံး latency ကို ကြည့်ရှုခဲ့သည်။ Fusion ioDrive Duo သည် ပျမ်းမျှ response time 0.0422ms ဖြင့် အမြင့်ဆုံး response 2.08ms ရရှိခဲ့သည်။

ကျွန်ုပ်တို့၏ ပေါင်းစပ်စံနှုန်းများ၏ နောက်ထပ်တစ်ဝက်မှာ ramped tests များဖြစ်ပြီး၊ အစောပိုင်း queue depth level မှ worker တစ်ဦးလျှင် အများဆုံး 64 (ထိရောက်သော QD=256) သို့မဟုတ် 128 (ထိရောက်သော QD=512) အထိ စွမ်းဆောင်ရည်ကို လွှမ်းခြုံထားသည်။ ဤအပိုင်းတွင် ကျွန်ုပ်တို့၏ server profile tests များလည်း ပါဝင်ပြီး အစကတည်းက enterprise ထုတ်ကုန်များသည် လိုအပ်ချက်များသော ရောနှော server load များအောက်တွင် မည်မျှကောင်းမွန်စွာ စွမ်းဆောင်ရည်ရှိသည်ကို ပြသရန် ဒီဇိုင်းထုတ်ထားသည်။

ioDrive Duo ရဲ့ ကျပန်း 4K read performance ကိုကြည့်မယ်ဆိုရင် LSI WarpDrive နဲ့ OCZ Z-Drive R4 နှစ်ခုလုံးရဲ့ မြန်နှုန်းထက် နှစ်ဆနီးပါး မြင့်မားတဲ့ queue depth ၁ နဲ့ ၂ မှာ ထိန်းသိမ်းထားနိုင်ပြီး ပြိုင်ဘက်မော်ဒယ်နှစ်ခုလုံးက ကျော်လွန်သွားခင်မှာ lead က queue depth ၄ မှာ လျှောကျသွားခဲ့ပါတယ်။ ဒီစမ်းသပ်မှုစွမ်းဆောင်ရည်မှာ queue depth ၆၄ မှာ အမြင့်ဆုံး 140,000 IOPS read ရှိခဲ့ပေမယ့် queue depth ၈ နဲ့အထက်မှာတော့ 120,000 IOPS အထက် မြန်နှုန်းကို ထိန်းသိမ်းထားနိုင်ခဲ့ပါတယ်။

ramped 4K random write test သို့ပြောင်းလဲလိုက်သောအခါ ioDrive Duo သည် အလားတူစွမ်းဆောင်ရည်ပရိုဖိုင်ကိုပြသခဲ့ပြီး queue အနက်နိမ့်သော အခြားပြိုင်ဘက်မော်ဒယ်များကို အနိုင်ယူခဲ့သည်။ ဤစမ်းသပ်မှုတွင် ioDrive Duo ၏စွမ်းဆောင်ရည်သည် queue အနက် ၄ တွင် IOPS ရေးသားမှုအမြန်နှုန်း ၂၂၄,၀၀၀ ဖြင့် အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး queue အနက် ၈ မှ ၆၄ အကြားတွင် IOPS ၂၀၁,၀၀၀ မှ ၂၁၀,၀၀၀ အကြားတွင် ရှိနေသည်။

ကျွန်ုပ်တို့ရဲ့ နောက်ဆုံး standard synthetic benchmarks အုပ်စုဟာ IOMeter မှာရှိတဲ့ ကျွန်ုပ်တို့ရဲ့ server profiles တွေကို အသုံးပြုပြီး scaled performance ကို ကြည့်ရှုပါတယ်။ ဒီစမ်းသပ်မှုတွေက worker တစ်ဦးလျှင် queue depth နည်းတဲ့နေရာကနေ အများဆုံး 128 အထိ (effective QD=512) စွမ်းဆောင်ရည်ကို တိုင်းတာပါတယ်။ ဒီအပိုင်းကို burst conditions တွေမှာ မတူညီတဲ့ တောင်းဆိုမှုများတဲ့ mixed workloads တွေအောက်မှာ enterprise ထုတ်ကုန်တွေ ဘယ်လောက်ကောင်းကောင်း စွမ်းဆောင်ရည်ပြလဲဆိုတာကို ပြသဖို့ ဒီဇိုင်းထုတ်ထားပါတယ်။ ကျွန်ုပ်တို့ရဲ့ enterprise-focused mixed workloads တွေမှာ ioDrive Duo ဟာ File Server စမ်းသပ်မှုကလွဲရင် queue depth 1 နဲ့ 2 မှာ ဦးဆောင်နေပြီး အမြင့်ဆုံး queue depth မှာ တခြား drives တွေထက် နောက်ကျကျန်နေခဲ့ပါတယ်။

စီးပွားရေးလုပ်ငန်းဆိုင်ရာ လက်တွေ့ကမ္ဘာ စံနှုန်းများ

ကျွန်ုပ်တို့၏ enterprise trace သည် Microsoft Exchange mail-server ပတ်ဝန်းကျင်ကို လွှမ်းခြုံထားသည်။ ကျွန်ုပ်တို့၏ StorageReview mail server ၏ လုပ်ဆောင်ချက်ကို ရက်အတော်ကြာ မှတ်တမ်းတင်ထားသည်။ ဤ server hardware တွင် Dell Perc 5/I integrated controller ရှိ RAID5 ရှိ 73GB 10k SAS hard drive သုံးခုဖြင့် လည်ပတ်နေသော Windows Server 2003 R2 ပတ်ဝန်းကျင်ကို အသုံးပြုသည့် Dell PowerEdge 2970 ပါဝင်သည်။ trace တွင် 95% read load နှင့် 5% write traffic မြင့်မားသော transfer request ငယ်များစွာ ပါဝင်သည်။

PCIe စက်ပစ္စည်းအချို့သည် အမြင့်ဆုံးစွမ်းဆောင်ရည်ရရှိရန် ဝန်ပိုမိုမြင့်မားရန် လိုအပ်သောကြောင့် trace playback အတွက် Light နှင့် Heavy profile နှစ်မျိုးလုံးကို ထည့်သွင်းထားပါသည်။ ဤတွင် weaker profile တွင် effective queue depth ကို 8 အထိ ကန့်သတ်ထားပြီး Heavy profile တွင် 48 အထိ တိုးမြှင့်ထားပါသည်။

ထိရောက်သော queue အနက်ကို ၈ အထိ ကန့်သတ်ထားပြီး၊ ၎င်းသည် လှုပ်ရှားမှုနည်းပါးသော အခြေအနေများကို ကိုယ်စားပြုသောကြောင့်၊ ioDrive Duo သည် ကျွန်ုပ်တို့၏ Mail Server trace playback စမ်းသပ်မှုတွင် ပျမ်းမျှ 969MB/s အမြန်နှုန်းဖြင့် အမြင့်ဆုံး transfer speed များကို ပေးဆောင်ခဲ့သည်။ ၎င်းသည် LSI WarpDrive မှ ပျမ်းမျှ 508MB/s သို့မဟုတ် OCZ Z-Drive R4 မှ တူညီသော အခြေအနေများတွင် 625MB/s နှင့် နှိုင်းယှဉ်ပါက နှိုင်းယှဉ်နိုင်သည်။ ခွင့်ပြုထားသော queue အနက်ကို ၄၈ အထိ တိုးချဲ့လိုက်သောအခါ၊ Z-Drive R4 သည် ပျမ်းမျှ 1,327MB/s အမြန်နှုန်းဖြင့် ထိပ်ဆုံးနေရာသို့ ရောက်ရှိခဲ့ပြီး၊ ioDrive Duo သည် 1,227MB/s အမြန်နှုန်းဖြင့် ဒုတိယနေရာတွင် ရပ်တည်ခဲ့ပြီး WarpDrive SLP-300 သည် 830MB/s အမြန်နှုန်းဖြင့် နောက်ကျကျန်နေခဲ့သည်။

queue depth တိုးလာတာနဲ့အမျှ transfer rate တွေ တိုးလာတာနဲ့အမျှ response time တွေကို ထိခိုက်စေနိုင်တယ်ဆိုတဲ့ အပေးအယူတစ်ခုကတော့ ကျန်ရှိနေတဲ့ I/O တွေ တိုးလာတာနဲ့အမျှပါပဲ။ load ပေါ့ပါးတဲ့အချိန်မှာ ioDrive Duo ဟာ response time 0.06ms နဲ့ 969MB/s ရှိတဲ့ transfer speed ကို ထိန်းသိမ်းထားနိုင်ခဲ့ပါတယ်။ Z-Drive R4 ဟာ transfer speed 1,327MB/s နဲ့ သာလွန်ဖို့အတွက် response time က 3.5 ဆ တိုးလာပြီး 0.21ms အထိ ရှိလာခဲ့ပြီး WarpDrive ကတော့ 830MB/s ရှိတဲ့ transfer rate အတွက် 0.45ms ရှိတဲ့ ပျမ်းမျှ response ရှိခဲ့ပါတယ်။

Enterprise Synthetic Workload ခွဲခြမ်းစိတ်ဖြာခြင်း (စတော့ရှယ်ယာဆက်တင်များ)

PCIe သိုလှောင်မှု ဖြေရှင်းချက်များကို ကျွန်ုပ်တို့ ကြည့်ရှုပုံသည် ရိုးရာ burst သို့မဟုတ် steady-state စွမ်းဆောင်ရည်ထက် ပိုမိုနက်ရှိုင်းပါသည်။ ရှည်လျားသောကာလတစ်ခုအတွင်း ပျမ်းမျှစွမ်းဆောင်ရည်ကို ကြည့်ရှုသောအခါ၊ ထိုကာလအတွင်း စက်ပစ္စည်းမည်သို့လုပ်ဆောင်ပုံအသေးစိတ်အချက်အလက်များကို သင်မေ့သွားပါလိမ့်မည်။ flash စွမ်းဆောင်ရည်သည် အချိန်ကြာလာသည်နှင့်အမျှ များစွာကွဲပြားသောကြောင့်၊ ကျွန်ုပ်တို့၏ benchmarking လုပ်ငန်းစဉ်အသစ်သည် စုစုပေါင်း throughput၊ ပျမ်းမျှ latency၊ peak latency နှင့် စက်ပစ္စည်းတစ်ခုစီ၏ preconditioning အဆင့်တစ်ခုလုံးတွင် standard deviation အပါအဝင် စွမ်းဆောင်ရည်ကို ခွဲခြမ်းစိတ်ဖြာပါသည်။ high-end enterprise ထုတ်ကုန်များတွင် latency သည် throughput ထက် မကြာခဏပိုအရေးကြီးပါသည်။ ဤအကြောင်းကြောင့်၊ ကျွန်ုပ်တို့၏ Enterprise Test Lab မှတစ်ဆင့် ကျွန်ုပ်တို့ထည့်သွင်းထားသော စက်ပစ္စည်းတစ်ခုစီ၏ စွမ်းဆောင်ရည်အပြည့်အစုံကို ပြသရန် ကျွန်ုပ်တို့သည် ကြိုးစားအားထုတ်ပါသည် ။

Windows နှင့် Linux လည်ပတ်မှုစနစ်နှစ်ခုလုံးတွင် မတူညီသော driver set တစ်ခုအောက်တွင် device တစ်ခုစီ မည်သို့လုပ်ဆောင်သည်ကိုပြသရန် စွမ်းဆောင်ရည်နှိုင်းယှဉ်ချက်များကိုလည်း ထည့်သွင်းထားပါသည်။ Windows အတွက်၊ မူလပြန်လည်သုံးသပ်ချိန်တွင် နောက်ဆုံးပေါ် driver များကို အသုံးပြုပြီး၊ ထို့နောက် device တစ်ခုစီကို 64-bit Windows Server 2008 R2 ပတ်ဝန်းကျင်အောက်တွင် စမ်းသပ်ပါသည်။ Linux အတွက်၊ Enterprise PCIe Application Accelerator တစ်ခုချင်းစီက ပံ့ပိုးပေးသော 64-bit CentOS 6.2 ပတ်ဝန်းကျင်ကို အသုံးပြုပါသည်။ ဤစမ်းသပ်မှုနှင့်ပတ်သက်သည့် ကျွန်ုပ်တို့၏ အဓိကရည်မှန်းချက်မှာ OS စွမ်းဆောင်ရည် မည်သို့ကွာခြားသည်ကို ပြသရန်ဖြစ်သည်၊ အဘယ်ကြောင့်ဆိုသော် ထုတ်ကုန်စာရွက်တွင် operating system တစ်ခုကို compatible အဖြစ် စာရင်းသွင်းထားခြင်းသည် ၎င်းတို့အားလုံး၏ စွမ်းဆောင်ရည်သည် အမြဲတမ်းတူညီသည်ဟု မဆိုလိုသောကြောင့်ဖြစ်သည်။

စမ်းသပ်ထားသော စက်ပစ္စည်းအားလုံးကို အစမှအဆုံးအထိ တူညီသော စမ်းသပ်မှုမူဝါဒအောက်တွင် လုပ်ဆောင်ပါသည်။ လက်ရှိတွင်၊ တစ်ဦးချင်း workload တစ်ခုချင်းစီအတွက်၊ ရောင်းချသူမှ ထောက်ပံ့ပေးသောကိရိယာများကို အသုံးပြု၍ စက်ပစ္စည်းများကို လုံခြုံစွာဖျက်ပစ်ပြီး၊ တူညီသော workload ဖြင့် steady-state သို့ ကြိုတင်ပြင်ဆင်ပြီးဖြစ်သည်။ စက်ပစ္စည်းကို thread တစ်ခုလျှင် ၁၆ ခုပါသော queue ဖြင့် thread ၁၆ ခု၏ လေးလံသောဝန်အောက်တွင် စမ်းသပ်မည်ဖြစ်ပြီး၊ ထို့နောက် အသုံးပြုမှုအနည်းငယ်နှင့် လေးလံသောအသုံးပြုမှုအောက်တွင် စွမ်းဆောင်ရည်ကိုပြသရန် thread/queue depth profile များစွာတွင် သတ်မှတ်ထားသောကြားကာလများတွင် စမ်းသပ်မည်ဖြစ်သည်။ 100% read activity ရှိသော စမ်းသပ်မှုများအတွက်၊ ကြိုတင်ပြင်ဆင်ခြင်းသည် 100% write သို့ပြောင်းသွားသော်လည်း တူညီသော workload ဖြင့်ဖြစ်သည်။

ကြိုတင်အခြေအနေပြင်ဆင်ခြင်းနှင့် မူလတည်ငြိမ်အခြေအနေစမ်းသပ်မှုများ-

• ပမာဏ (ဖတ်+ရေး IOPS စုစည်းမှု)
• ပျမ်းမျှ နှောင့်နှေးမှု (ဖတ်+ရေး နှောင့်နှေးမှု အတူတကွ ပျမ်းမျှ)
• အများဆုံး နှောင့်နှေးမှု (အမြင့်ဆုံး ဖတ်ရန် သို့မဟုတ် ရေးရန် နှောင့်နှေးမှု)
• နှောင့်နှေးမှု စံသွေဖည်မှု (ဖတ်+ရေး စံသွေဖည်မှုကို ပျမ်းမျှပေါင်းစပ်ထားသည်)

ဤအချိန်တွင် Enterprise Synthetic Workload Analysis တွင် လက်တွေ့ကမ္ဘာလှုပ်ရှားမှုကို ထင်ဟပ်စေရန် ကြိုးစားနိုင်သည့် ဘုံပရိုဖိုင်လေးခု ပါဝင်သည်။ ၎င်းတို့ကို ကျွန်ုပ်တို့၏ ယခင် benchmark များနှင့် ဆင်တူမှုအချို့ရှိစေရန်အပြင် အများဆုံး 4K read နှင့် write speed ကဲ့သို့သော ကျယ်ပြန့်စွာထုတ်ဝေထားသော တန်ဖိုးများနှင့် နှိုင်းယှဉ်ရန်အတွက် ဘုံအခြေခံတစ်ခုအပြင် enterprise drive များအတွက် အသုံးများသော 8K 70/30 တို့ကို ရွေးချယ်ခဲ့ခြင်းဖြစ်သည်။ transfer size အမျိုးမျိုးကို ပေးဆောင်သည့် ရိုးရာ File Server နှင့် Webserver အပါအဝင် legacy mixed workloads နှစ်ခုကိုလည်း ကျွန်ုပ်တို့ ထည့်သွင်းထားသည်။ ဤနောက်ဆုံးနှစ်ခုကို ကျွန်ုပ်တို့၏ဆိုက်တွင် မိတ်ဆက်ပြီးသည်နှင့် ထိုအမျိုးအစားများတွင် application benchmark များဖြင့် အဆင့်လိုက်ဖယ်ရှားပြီး synthetic workloads အသစ်များဖြင့် အစားထိုးသွားမည်ဖြစ်သည်။

• 4K
  • ၁၀၀% ဖတ်ရန် သို့မဟုတ် ၁၀၀% ရေးသားရန်
  • ၁၀၀% ၁၂၈K
• ၈K ၇၀/၃၀
  • ၇၀% ဖတ်၊ ၃၀% ရေးသား
  • ၁၀၀% ၁၂၈K
• ဖိုင်ဆာဗာ
  • ၇၀% ဖတ်၊ ၃၀% ရေးသား
  • 10% 512b၊ 5% 1k၊ 5% 2k၊ 60% 4k၊ 2% 8k၊ 4% 16k၊ 4% 32k၊ 10% 64k
• ဝက်ဘ်ဆိုက်
  • 100% ဖတ်ပါ။
  • ၂၂% ၅၁၂ခ၊ ၁၅% ၁ထောင်၊ ၈% ၂ထောင်၊ ၂၃% ၄ထောင်၊ ၁၅% ၈ထောင်၊ ၂% ၁၆ထောင်၊ ၆% ၃၂ထောင်၊ ၇% ၆၄ထောင်၊ ၁% ၁၂၈ထောင်၊ ၁% ၅၁၂ထောင်

၆ နာရီကြာ thread ၁၆ ခုနှင့် queue ၁၆ ခု၏ လေးလံသောဝန်အောက်တွင် ၁၀၀% 4K write activity ကိုကြည့်လျှင် Fusion ioDrive Duo သည် ကျွန်ုပ်တို့၏ Lenovo ThinkServer RD240 တွင် အမြင့်ဆုံး transfer speeds ကို ပေးဆောင်သည်ကို တွေ့ရှိရသည်။ ၎င်းသည် Windows Server 2008 R2 64-bit နှင့် CentOS 6.2 နှစ်ခုလုံးအတွက် မှန်ကန်ပြီး Windows စွမ်းဆောင်ရည်ထက် အနည်းငယ်သာ ဦးဆောင်နေပါသည်။ နောက်တစ်ခုမှာ 16TB OCZ Z-Drive R4 ဖြစ်သော်လည်း Windows တွင်သာ ရှိသည်။ CentOS 6.2 [1.0.0.1480] အတွက် OCZ driver သည် thread အရေအတွက် မည်သို့ပင်ရှိစေကာမူ မြင့်မားသော queue depth request များကို ကောင်းစွာ တုံ့ပြန်မည်မဟုတ်ဘဲ စမ်းသပ်မှု၏ ဤအဆင့်တစ်လျှောက်လုံးတွင် IOPS 7,600 ခန့် မြန်နှုန်းကို ထိန်းသိမ်းထားနိုင်ခဲ့သည်။ နောက်တစ်ခုမှာ LSI WarpDrive SLP-300 ဖြစ်ပြီး Windows နှင့် Linux နှစ်ခုလုံးတွင် အလွန်ဆင်တူသော throughput ကို ပေးဆောင်သည်။

ကျွန်ုပ်တို့ရဲ့ 4K 100% write preconditioning စမ်းသပ်မှုကာလအတွင်း ပျမ်းမျှ latency ကိုကြည့်မယ်ဆိုရင် အမြန်ဆုံးနဲ့ အနှေးဆုံး drive က OCZ Z-Drive R4 ပါ။ Windows environment မှာ driver လုံးဝအလုပ်လုပ်တဲ့ အချိန်မှာ ပျမ်းမျှ latency က Fusion ioDrive Duo ဒါမှမဟုတ် LSI WarpDrive ထက် အများကြီးပိုမြန်ပါတယ်။ စွမ်းဆောင်ရည်အတော်လေးညံ့ဖျင်းတဲ့ Linux environment မှာ ဒီအမျိုးအစားထဲက တခြား device တွေထက် အဆပေါင်းများစွာ မြင့်မားပါတယ်။

4K 100% write preconditioning စမ်းသပ်မှုအတွင်း interval တစ်ခုလျှင် အများဆုံး latency output ကို လေ့လာကြည့်လျှင် impact controller နှင့် NAND သည် heavy-write environment တွင် မည်မျှအရေးပါသည်ကို သင်စတင်မြင်တွေ့နိုင်ပါသည်။ MLC NAND ပါသည့် Fusion ioDrive Duo သည် peak latency spikes များအရ SLC-based LSI WarpDrive နှင့် MLC-based OCZ Z-Drive R4 အကြားတွင် ရှိနေသည်။ Windows နှင့် Linux နှစ်မျိုးလုံး၏ စွမ်းဆောင်ရည်ကို နှိုင်းယှဉ်ကြည့်လျှင် Windows environment တွင် Linux ထက် ပိုမိုတသမတ်တည်းရှိသော output ကို ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရပြီး spikes နည်းပါးသော်လည်း spikes များစွာနည်းပါးခဲ့သည်။ Windows ရှိ MLC-based Z-Drive R4 တွင် ကျွန်ုပ်တို့၏ဇယားစကေးထက် များစွာမြင့်မားသော spikes များရှိပြီး Linux စွမ်းဆောင်ရည်မှာ တည်ငြိမ်သော်လည်း IOPS စွမ်းဆောင်ရည်နိမ့်ကျမှုတွင် လေးလံစွာတာဝန်ယူထားခြင်းမရှိပါ။ LSI WarpDrive သည် Windows တွင် ၎င်း၏အကောင်းဆုံးစွမ်းဆောင်ရည်ကို ပေးဆောင်ခဲ့ပြီး latency curve ပိုမိုချောမွေ့သော်လည်း 1,000ms ကျော် spike တစ်ခုသာ ရရှိခဲ့သည်။

သတ်မှတ်ထားတဲ့ storage product တစ်ခုရဲ့ အမြင့်ဆုံး latency performance ကို ထည့်သွင်းစဉ်းစားတဲ့အခါ၊ မကြာခဏ ဖုံးကွယ်ထားတဲ့နေရာကတော့ I/O ထောင်ပေါင်းများစွာ ဒါမှမဟုတ် သန်းပေါင်းများစွာထဲက ဘယ်နှစ်ခုဟာ response value မြင့်မားစွာရှိလဲဆိုတာပါပဲ။ ဒါကြောင့် အမြင့်ဆုံး peak latency ကိုကြည့်ရှုဖို့ peak latency တစ်ခုတည်းမဟုတ်ဘဲ latency ပြောင်းလဲမှုကိုလည်း ပြသတဲ့ standard deviation ကိုပါ စောင့်ကြည့်ဖို့ အရေးကြီးပါတယ်။ drive တစ်ခုမှာ တန်ဖိုးအားလုံးကို ပျမ်းမျှထုတ်ပြီး average latency အတော်လေးနည်းနေရင်တောင်၊ သင်အသုံးပြုနေတဲ့ application ပေါ်မူတည်ပြီး လက်မခံနိုင်ဘူးလို့ ယူဆနိုင်တဲ့ I/O ပမာဏ အတော်အတန်များနေနိုင်ပါတယ်။

SLC NAND ဖွဲ့စည်းမှုဖြင့် LSI WarpDrive သည် Windows ပတ်ဝန်းကျင်တွင် အဓိကပြသသည့် latency standard deviation အလွန်ကောင်းမွန်သော အခြေအနေကို ထိန်းသိမ်းထားနိုင်ခဲ့သည်။ Fusion ioDrive Duo သည် WarpDrive တွင်တွေ့ရှိရသော ပုံစံကဲ့သို့ အတော်လေး တသမတ်တည်းရှိသော်လည်း standard deviation ၏ အထက်အပိုင်းအခြားသို့ ရောက်ရှိခဲ့သည်။ ၎င်း၏ driver စွမ်းဆောင်ရည်ကို နှိုင်းယှဉ်ကြည့်လျှင် ဤစမ်းသပ်မှုတွင် Linux တွင် တသမတ်တည်း ပိုမိုမြန်ဆန်ခဲ့သည်။ OCZ Z-Drive R4 သည် ကျွန်ုပ်တို့၏ စမ်းသပ်မှုကာလအတွင်း latency output ပိုမိုမြင့်မားသော်လည်း steady-state သို့ရောက်ရှိသွားသည်နှင့် တစ်ခါတစ်ရံတွင် ညီမျှလာသော်လည်း latency မြင့်မားသော အချိန်ကာလများ ရှိနေဆဲဖြစ်သည်။

ကြိုတင်ပြင်ဆင်မှုစမ်းသပ်မှုများပြီးဆုံးသွားသည်နှင့် ကျွန်ုပ်တို့၏ မူလစမ်းသပ်မှုနမူနာယူခြင်းကို ချက်ချင်းစတင်ခဲ့သည်။ တည်ငြိမ်သောအခြေအနေတွင်၊ ဤအုပ်စုတွင် အမြင့်ဆုံး throughput ရှိသော PCIe storage device မှာ Windows ရှိ OCZ Z-Drive R4 ဖြစ်သည်။ ၎င်းသည် အမြင့်ဆုံး 229,811 IOPS read နှင့် 56,978 IOPS write speed ကိုတိုင်းတာခဲ့သည်။ နောက်တစ်ခုမှာ Fusion ioDrive Duo ဖြစ်ပြီး 140,230 IOPS read နှင့် 42,644 IOPS write ကိုတိုင်းတာခဲ့သည်။ ioDrive Duo ၏ Windows စွမ်းဆောင်ရည်သည် write စွမ်းဆောင်ရည်တွင် အနည်းငယ်ကျဆင်းသွားသော်လည်း ၎င်းအောက်တွင်သာရှိသည်။ LSI WarpDrive SLP-300 သည် Windows တွင် ၎င်း၏အပြင်းထန်ဆုံး 4K write speed ကိုပေးစွမ်းခဲ့ပြီး 120,502 IOPS read နှင့် 35,015 IOPS write ကိုတိုင်းတာခဲ့သည်။

မြင့်မားသော 4K ဖတ်ရှုမှုနှင့် 4K ရေးသားမှု၏ steady-state တိုင်းတာမှုတွင် Windows တွင် ၎င်း၏ထိပ်တန်း throughput speeds ရှိသော OCZ Z-Drive R4 သည် ပျမ်းမျှ latency 4.49ms ဖတ်ရှုမှုနှင့် 1.11ms ရေးသားမှုဖြင့် ရှေ့ဆုံးမှ ရပ်တည်ခဲ့သည်။ Fusion ioDrive Duo သည် Linux တွင် 6.00ms နှင့် Windows တွင် 6.25ms နှင့် OS နှစ်ခုလုံးတွင် 1.82ms ရေးသားမှုဖြင့် ဒုတိယနေရာတွင် ရပ်တည်ခဲ့သည်။ ထို့နောက်တွင် Windows တွင် 7.31ms ဖတ်ရှုမှုနှင့် Linux တွင် 7.32ms ဖတ်ရှုမှုအမြန်နှုန်းဖြင့် WarpDrive တွင် ရပ်တည်ခဲ့ပြီး Windows တွင် 2.12ms နှင့် Linux တွင် 2.71ms ရေးသားမှုအမြန်နှုန်းဖြင့် ရပ်တည်ခဲ့သည်။

ကျွန်ုပ်တို့၏ steady-state စမ်းသပ်မှု၏ sampling time အတွင်း peak latency ကိုကြည့်လျှင် SLC-based LSI WarpDrive သည် Windows နှင့် Linux နှစ်မျိုးလုံးတွင် အနိမ့်ဆုံး သို့မဟုတ် အကောင်းဆုံးနေရာတွင် ရှိနေပြီး Windows တွင် Fusion ioDrive Duo သည် 426.15ms peak read နှင့် 170.09ms peak write ဖြင့် ဒုတိယနေရာတွင် ရပ်တည်ခဲ့ပြီး Linux တွင် 1,208ms peak read နှင့် 156.91ms peak write ဖြင့် ဒုတိယနေရာတွင် ရပ်တည်ခဲ့သည်။ Windows တွင် OCZ Z-Drive R4 သည် Windows တွင် 1,889ms read နှင့် 5,299ms write ဖြင့် အမြင့်ဆုံး အမြင့်ဆုံး စံချိန်များကို ရရှိခဲ့သည်။

ကျွန်ုပ်တို့၏ steady-state 4K read and write test ကာလတစ်လျှောက် standard deviation ကိုကြည့်လျှင် read and write activity နှစ်မျိုးလုံးအတွက် ကျွန်ုပ်တို့၏ 4K test တွင် အတည်ငြိမ်ဆုံး PCIe Application Accelerator မှာ Windows ရှိ LSI WarpDrive ဖြစ်သည်။ 4K write performance တသမတ်တည်းရှိမှုအရ အဆင့်သတ်မှတ်ချက်တွင် Windows ရှိ OCZ Z-Drive R4 သည် ဒုတိယနေရာတွင် ရှိပြီး Linux ရှိ WarpDrive၊ Linux ရှိ ioDrive Duo၊ ထို့နောက် Windows ရှိ ioDrive Duo တို့ အသီးသီးရပ်တည်လျက်ရှိသည်။ ဖတ်ရှုမှုအမြန်နှုန်း တသမတ်တည်းရှိမှုအရ အဆင့်သတ်မှတ်ချက်တွင် ioDrive Duo ၏ Windows နှင့် Linux နှစ်မျိုးလုံး၏ စွမ်းဆောင်ရည်သည် SLC-based WarpDrive ပြီးနောက်၊ ထို့နောက် Linux ရှိ WarpDrive၊ ထို့နောက် Windows ရှိ Z-Drive R4 တို့ အသီးသီးရပ်တည်လျက်ရှိသည်။

နောက်ထပ် preconditioning စမ်းသပ်မှုသည် ကျွန်ုပ်တို့၏ 4K စမ်းသပ်မှုတွင် 100% write activity နှင့် နှိုင်းယှဉ်ပါက ပိုမိုလက်တွေ့ကျသော read/write workload spread ဖြင့် အလုပ်လုပ်ပါသည်။ ဤနေရာတွင် 8K transfers များ၏ 70% read နှင့် 30% write mix ရှိပါသည်။ thread ၁၆ ခုနှင့် queue ၁၆ ခုပါဝင်သော ၆ နာရီကာလအတွင်း ကျွန်ုပ်တို့၏ 8K 70/30 mixed workload ကိုကြည့်လျှင် Fusion ioDrive Duo သည် ကျွန်ုပ်တို့၏ Lenovo ThinkServer တွင် အမြင့်ဆုံး peak transfer speeds ကို ပေးဆောင်နေဆဲဖြစ်ကြောင်း တွေ့ရှိရပါသည်။ ၎င်းသည် Windows Server 2008 R2 64-bit နှင့် CentOS 6.2 ပတ်ဝန်းကျင်နှစ်ခုလုံးအတွက် မှန်ကန်ပြီး Windows စွမ်းဆောင်ရည်ထက် အနည်းငယ်သာလွန်နေပါသည်။ နောက်တစ်ခုမှာ Windows တွင်သာရှိသော်လည်း 16TB OCZ Z-Drive R4 ဖြစ်သည်။ နောက်တစ်ခုမှာ Windows ပတ်ဝန်းကျင်တွင် ပိုမိုမြင့်မားသောစွမ်းဆောင်ရည်ကို ပေးဆောင်သည့် LSI WarpDrive SLP-300 ဖြစ်သည်။

8K 70/30 စမ်းသပ်မှုမှာ ပျမ်းမျှ latency ကို ပြောင်းကြည့်လိုက်ရင် driver set တွေကြားက ကွာခြားချက်က ပိုသိသာလာပါတယ်။ Fusion ioDrive Duo မှာ Linux နဲ့ Windows နှစ်ခုလုံးမှာ စွမ်းဆောင်ရည် အတူညီဆုံးဖြစ်ပေမယ့် Linux driver set ရဲ့ အနားသတ်က steady-state ကို ရောက်တဲ့အခါ ပိုသိသာလာပါတယ်။ LSI WarpDrive မှာ driver set တွေကြားက ပျမ်းမျှ latency ကွာခြားမှု သိသာထင်ရှားပြီး Windows driver က အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို ပေးစွမ်းပါတယ်။ Windows မှာရှိတဲ့ OCZ Z-Drive R4 မှာ အုပ်စုထဲမှာ ပျမ်းမျှ latency အနိမ့်ဆုံးဖြစ်ပြီး အမြန်ဆုံး throughput နဲ့ လက်တွဲသွားပါတယ်။ ဒါပေမယ့် Linux စွမ်းဆောင်ရည်ကတော့ Linux မှာ ပျမ်းမျှ 46ms လောက်ရှိပြီး Windows မှာတော့ 6ms လောက်ရှိပါတယ်။

ioDrive Duo၊ WarpDrive နှင့် Z-Drive R4 တို့၏ အမြင့်ဆုံးတုံ့ပြန်မှုအချိန်များကို ကြည့်လျှင်၊ ကျွန်ုပ်တို့၏ 4K စမ်းသပ်မှုတွင် ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသော ባህሪያየትအများစုသည် read activity ပါဝင်သည့် ကျွန်ုပ်တို့၏ 8K 70/30 workload တွင် အကျိုးသက်ရောက်ခဲ့သည်။ ဤစမ်းသပ်မှုတွင် Fusion-io ioDrive Duo သည် အနိမ့်ဆုံးအမြင့်ဆုံး latency curve ဖြင့်စတင်ခဲ့ပြီး နှစ်နာရီအကြာတွင် drive သည် steady state သို့ပြောင်းလဲလာသည်နှင့်အမျှ အနည်းငယ်မြင့်တက်လာခဲ့သည်။ ထိုအချိန်တွင် ၎င်းသည် Windows ရှိ WarpDrive ထက် မြင့်မားခဲ့ပြီး ဤအုပ်စုရှိ drive များထဲတွင် အနိမ့်ဆုံး curve ရှိသည်။ Windows နှင့် Linux ရှိ ioDrive Duo အကြား driver ကွာခြားချက်များကို ကြည့်လျှင်၊ Linux driver တွင် အမြင့်ဆုံး peaks များရှိခဲ့သော်လည်း စမ်းသပ်မှု၏ နောက်ပိုင်းတစ်ဝက်တွင် curve နိမ့်ကျစွာ (ပိုမြန်သော) curve ကို ထိန်းသိမ်းထားသည်။ အခြားတစ်ဖက်တွင် Windows ရှိ Z-Drive R4 တွင် အမြင့်ဆုံး peaks များရှိခဲ့သော်လည်း 100% write workload တွင် ၎င်း၏အပြုအမူနှင့် နှိုင်းယှဉ်ပါက ယေဘုယျအားဖြင့် ငြိမ်သက်သွားခဲ့သည်။

8K 70/30 workload ရဲ့ ကျွန်ုပ်တို့ရဲ့ preconditioning phase မှာ standard deviation profile က စမ်းသပ်မှုကြာချိန်တစ်လျှောက် ကတ်တွေရဲ့ စွမ်းဆောင်ရည်နဲ့ ပတ်သက်ပြီး စိတ်ဝင်စားစရာကောင်းတဲ့ ကွာခြားချက်တွေကို ပြသခဲ့ပါတယ်။ WarpDrive က Windows မှာ အမြန်ဆုံး response time တွေကို အဆက်မပြတ်ရခဲ့ပေမယ့် Linux မှာတော့ သူ့ရဲ့ latency performance က အနည်းငယ်သာ လိုအပ်နေခဲ့ပါတယ်။ ioDrive Duo က Linux မှာ အကောင်းဆုံးရလဒ်ကို ပြသခဲ့ပြီး OCZ Z-Drive R4 ကတော့ 100% write 4K စမ်းသပ်မှုနဲ့ ယှဉ်ရင် ဒီစမ်းသပ်မှုမှာ latency standard deviation profile ကို အများကြီး တိုးတက်ကောင်းမွန်အောင် ပြုလုပ်ပေးခဲ့ပါတယ်။

ကျွန်ုပ်တို့ 100% 4K write test မှာ လုပ်ဆောင်ခဲ့တဲ့ fixed 16 thread, 16 queue max workload နဲ့ နှိုင်းယှဉ်ရင်၊ ကျွန်ုပ်တို့ရဲ့ mixed workload profile တွေက thread/queue combination အမျိုးမျိုးမှာ စွမ်းဆောင်ရည်ကို ချိန်ညှိပေးပါတယ်။ ဒီစမ်းသပ်မှုတွေမှာ ကျွန်ုပ်တို့ရဲ့ workload intensity ကို 2 threads နဲ့ 2 queue ကနေ 16 threads နဲ့ 16 queue အထိ တိုးချဲ့ထားပါတယ်။ အထူးဆန်းဆုံး profile ကတော့ OCZ Z-Drive R4 ဖြစ်ပြီး Windows စွမ်းဆောင်ရည်နဲ့ Linux စွမ်းဆောင်ရည်ကို နှိုင်းယှဉ်ပြထားပါတယ်။ Windows မှာ အမြန်ဆုံးဖြစ်နေချိန်မှာ Linux မှာ အနှေးဆုံးဖြစ်ပြီး ကျွန်ုပ်တို့စမ်းသပ်ခဲ့တဲ့ driver မှာ queue depth scaling ပြဿနာရှိပါတယ်။ thread နဲ့ queue depth နည်းတဲ့အချိန်မှာ ioDrive Duo ဟာ LSI SandForce-powered WarpDrive နဲ့ Z-Drive R4 ထက် စွမ်းဆောင်ရည်မှာ အားကောင်းစွာ ဦးဆောင်နေပါတယ်။ ဒါပေမယ့် queue depth တိုးလာတာနဲ့အမျှ တခြား card တွေက သူ့ရဲ့စွမ်းဆောင်ရည်နဲ့ ကိုက်ညီအောင် ဒါမှမဟုတ် သာလွန်အောင် လုပ်ဆောင်နိုင်ခဲ့ပါတယ်။ Windows နဲ့ Linux driver environment တွေကို နှိုင်းယှဉ်ကြည့်မယ်ဆိုရင် ioDrive Duo ဟာ workload တစ်လျှောက်လုံးမှာ စွမ်းဆောင်ရည်မှာ အတော်လေး ညီမျှမှုရှိပါတယ်။

thread နှင့် queue activity အဆင့်အမျိုးမျိုး၏ ကျယ်ပြန့်သော span တစ်လျှောက် ပျမ်းမျှပြီးစီးမှု latency ကို နှိုင်းယှဉ်ကြည့်လျှင် Windows ရှိ Z-Drive R4 သည် queue depth load မြင့်မားသောအခါတွင် ၎င်းကို ကျော်လွန်သွားသည်အထိ အများစုတွင် WarpDrive သည် အနိမ့်ဆုံး response time များကို ထိန်းသိမ်းထားနိုင်ခဲ့သည်။ ioDrive Duo သည် Windows နှင့် Linux နှစ်မျိုးလုံးတွင် တူညီသောစွမ်းဆောင်ရည်ကို ပေးစွမ်းခဲ့ပြီး ၎င်း၏ အမြင့်ဆုံး output level တွင် ကွာဟချက်အနည်းငယ်သာရှိသောကြောင့် Linux driversset သို့ ဦးဆောင်နိုင်ခဲ့သည်။

ကျွန်ုပ်တို့ရဲ့ 8K 70/30 workload တစ်လျှောက်မှာ အမြင့်ဆုံး latency ကိုကြည့်တာက စိတ်ဝင်စားစရာပါပဲ၊ ဘာလို့လဲဆိုတော့ thread နဲ့ queue count နည်းရင်တောင် drive တွေက အမြင့်ဆုံး peak response time တွေကို မြင်တွေ့နေရဆဲဖြစ်လို့ပါ။ Linux မှာရှိတဲ့ ioDrive Duo က workload အများစုမှာ 1,000ms အထိ တသမတ်တည်း အမြင့်ဆုံးရောက်ရှိခဲ့ပြီး Windows driver ကတော့ အတော်လေး တည်ငြိမ်ပါတယ်။ ဒီစမ်းသပ်မှုမှာ Windows မှာရှိတဲ့ ioDrive Duo ဟာ 16T/16Q load အထိ အနိမ့်ဆုံး peak response time တွေနဲ့ ထွက်ပေါ်လာခဲ့ပြီး WarpDrive ကလည်း နောက်မှာ ရှိနေပါတယ်။

ရံဖန်ရံခါ မြင့်မားသော မြင့်တက်မှုများသည် စိတ်ပျက်စရာကောင်းပုံရသော်လည်း၊ standard deviation latency plot ကိုကြည့်လျှင် Linux ရှိ Z-Drive R4 မှလွဲ၍ အခြား device အားလုံး၏ latency profile ကို ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသည်။ အမြင့်ဆုံး load များအထိ Windows ရှိ ioDrive Duo သည် အနိမ့်ဆုံး standard deviation ကို ထိန်းသိမ်းထားနိုင်ပြီး Linux driver သည် အနည်းငယ်နောက်ကျကျန်ခဲ့ပြီး၊ ထို့နောက် WarpDrive နှင့် Windows ရှိ Z-Drive R4 တို့က နောက်မှလိုက်လာခဲ့သည်။

File Server workload ဟာ device တစ်ခုချင်းစီကို ထိခိုက်စေတဲ့ transfer-size spectrum ပိုကြီးတဲ့အတွက် static 4k ဒါမှမဟုတ် 8k workload အတွက် အခြေချမယ့်အစား drive ဟာ 512b ကနေ 64K အထိ request တွေကို ကိုင်တွယ်ဖြေရှင်းရပါမယ်။ ဒီအပိုင်းမှာ Windows မှာရှိတဲ့ Z-Drive R4 ဟာ burst နဲ့ steady-state စွမ်းဆောင်ရည် အမြင့်ဆုံးနဲ့ ထင်ရှားပြီး ioDrive Duo က ဒုတိယနေရာမှာ ရှိနေပါတယ်။ Burst mode မှာ Windows မှာရှိတဲ့ ioDrive Duo ဟာ ပိုမိုမြင့်မားတဲ့ မြန်နှုန်းတွေကို ပေးစွမ်းနိုင်ခဲ့ပြီး drive ဟာ steady-state ထဲရောက်သွားတဲ့အခါ Linux စွမ်းဆောင်ရည်နဲ့ ပြောင်းလဲသွားခဲ့ပါတယ်။ WarpDrive ကတော့ burst နဲ့ steady-state mode နှစ်မျိုးလုံးမှာ Windows စွမ်းဆောင်ရည် ပိုမိုမြင့်မားတာကြောင့် ဒုတိယနေရာမှာ ရပ်တည်ခဲ့ပါတယ်။

File Server Preconditioning စမ်းသပ်မှုအပေါ် ပျမ်းမျှ latency ကိုကြည့်လျှင် Z-Drive R4 သည် Windows ရှိ ioDrive Duo နှင့် WarpDrive ထက် များစွာအသာရခဲ့သည်။ ioDrive သည် Linux နှင့် Windows စွမ်းဆောင်ရည်ကြားတွင် ကွာခြားချက် အလွန်နည်းပါးပြီး WarpDrive သည် OS များကြားတွင် ကွာဟချက် ပိုမိုကြီးမားသည်ကို ပြသခဲ့သည်။

drive တစ်ခုစီရဲ့ preconditioning phase မှာ အမြင့်ဆုံး latency ကိုကြည့်မယ်ဆိုရင် LSI WarpDrive ဟာ Windows ထက် 400ms နီးပါး ခုန်တက်သွားတာကြောင့် အားနည်းချက်တချို့ကို ပြသခဲ့ပါတယ်။ Linux ရဲ့ ioDrive Duo ဟာ Windows ထက် ပိုများပေမယ့် စမ်းသပ်မှုကာလအတွင်းမှာ အများစုဟာ စမ်းသပ်မှုမှာ အနိမ့်ဆုံးဖြစ်ပြီး Windows ဘက်မှာတော့ high-latency spikes မရှိသလောက်ပါပဲ၊ ဒါပေမယ့် ပျမ်းမျှအားဖြင့်တော့ ပိုများပါတယ်။ MLC-based OCZ Z-Drive R4 ဟာ File Server preconditioning လုပ်ငန်းစဉ်အများစုမှာ မြန်ဆန်စွာ လည်ပတ်ခဲ့ပြီး စမ်းသပ်မှုရဲ့ ပထမတစ်နာရီအတွင်းမှာ 10,000-40,000ms ကျော် spikes တွေရှိခဲ့ပါတယ်။

ကျွန်ုပ်တို့၏ file Server preconditioning စမ်းသပ်မှုမှတစ်ဆင့် လုပ်ဆောင်သော device များ၏ standard deviation ကို စစ်ဆေးကြည့်လျှင်၊ အံ့သြစရာအကောင်းဆုံး ကွာခြားချက်ကို LSI WarpDrive တွင် တွေ့ရှိခဲ့ပြီး Windows စွမ်းဆောင်ရည်နှင့် နှိုင်းယှဉ်ပါက စမ်းသပ်မှုကြာချိန်တစ်လျှောက်လုံး Linux I/O response time သိသိသာသာ မြင့်တက်လာခဲ့သည်။ ioDrive Duo တွင်လည်း drive သည် steady-state သို့ရောက်ရှိသောအခါ အလားတူပြောင်းလဲမှုကို တွေ့ရှိခဲ့ပြီး လမ်းကြောင်းနှစ်ခုလုံး ကွဲလွဲသွားပြီး Windows တုံ့ပြန်မှုမှာ အုပ်စုဖွဲ့မှု နည်းပါးလာခဲ့သည်။ အလုံးစုံပြောရလျှင် ဤအပိုင်းတွင် အကောင်းဆုံးစွမ်းဆောင်ရည်ရှိသော drive မှာ Windows အောက်ရှိ LSI WarpDrive ဖြစ်ပြီး စမ်းသပ်မှုတစ်လျှောက်လုံးတွင် flatest standard deviation curve ကို ထိန်းသိမ်းထားခဲ့သည်။

ကျွန်ုပ်တို့၏ ကြိုတင်ပြင်ဆင်ခြင်းလုပ်ငန်းစဉ်သည် 16T/16Q မြင့်မားသော ဝန်အောက်တွင် ပြီးဆုံးသွားသည်နှင့်၊ လုပ်ဆောင်ချက်အဆင့်အမျိုးမျိုးတွင် File Server စွမ်းဆောင်ရည်ကို ကျွန်ုပ်တို့ လေ့လာခဲ့ပါသည်။ Fusion-io ioDrive Duo သည် thread နှင့် queue အရေအတွက်နည်းပါးသောအခြေအနေများတွင် အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို ထိန်းသိမ်းထားနိုင်ခဲ့ပြီး မြင့်မားသော I/O အဆင့်များတွင် throughput တွင် OCZ Z-Drive R4 သာ သာလွန်ခဲ့ပါသည်။

ကျွန်ုပ်တို့ရဲ့ ကွဲပြားတဲ့ load စမ်းသပ်မှုအပေါ် ပျမ်းမျှ latency ကို ခွဲခြမ်းစိတ်ဖြာကြည့်တဲ့အခါ Z-Drive R4 ဟာ ပျမ်းမျှအားဖြင့် အမြန်ဆုံး response time တွေနဲ့ ထိပ်ဆုံးမှာ ရှိနေပါတယ်။ thread-count တစ်ခုချင်းစီမှာ outstanding queue level တိုးလာတာနဲ့အမျှ Windows driver မှာ throughput အနည်းငယ်နိမ့်ပေမယ့် ioDrive Duo ရဲ့ latency ကတော့ Linux ဘက်မှာ မြင့်တက်လာခဲ့ပါတယ်။

ကျွန်ုပ်တို့ရဲ့ မူလ File Server စမ်းသပ်မှုကာလအတွင်း အများဆုံး latency ကိုကြည့်မယ်ဆိုရင် Linux မှာရှိတဲ့ ioDrive ဟာ thread/queue count နိမ့်တဲ့နဲ့ မြင့်တဲ့အဆင့်တွေမှာ 1,000ms spikes တွေ ပိုများနေဆဲပါ။ ဒါပေမယ့် Windows ဗားရှင်းကတော့ 16T/16Q workload အထိ အနိမ့်ဆုံး တသမတ်တည်းရှိတဲ့ အများဆုံး response time တွေကို ပေးစွမ်းခဲ့ပါတယ်။

ioDrive Duo နှင့် WarpDrive နှစ်ခုလုံး၏ File Server standard deviation profile သည် queue depths မြင့်မားသည်အထိ Windows နှင့် Linux နှစ်ခုလုံးတွင် အတော်လေး တင်းကျပ်စွာ တည်ရှိနေပါသည်။ ioDrive Duo တွင် Windows စွမ်းဆောင်ရည် ပြန့်ကျဲနေသည့် 16T/16Q အဆင့်တွင် Linux driver သည် ပိုမိုကောင်းမွန်သော တည်ငြိမ်မှုကို ထိန်းသိမ်းထားနိုင်ခဲ့သည်။

ကျွန်ုပ်တို့ရဲ့ နောက်ဆုံး workload ဟာ စမ်းသပ်ဗားရှင်းရဲ့ preconditioning phase ကို အဓိက output နဲ့ ခွဲခြမ်းစိတ်ဖြာပုံမှာ အတော်လေးထူးခြားပါတယ်။ 100% read activity နဲ့ ဒီဇိုင်းထုတ်ထားတဲ့ workload တစ်ခုအနေနဲ့ သင့်တော်တဲ့ preconditioning step မရှိဘဲ device တစ်ခုချင်းစီရဲ့ စစ်မှန်တဲ့ read performance ကို ပြသဖို့ ခက်ခဲပါတယ်။ conditioning workload ကို စမ်းသပ် workload နဲ့ အတူတူပဲထားရှိဖို့အတွက် pattern ကို 100% write ဖြစ်အောင် ပြောင်းပြန်လုပ်ထားပါတယ်။ ဒီအကြောင်းကြောင့် preconditioning chart တွေဟာ နောက်ဆုံး workload နံပါတ်တွေထက် အများကြီးပိုသိသာထင်ရှားပါတယ်။ ဒီလိုခက်ခဲတဲ့အခြေအနေတွေအောက်မှာ OCZ Z-Drive R4 ဟာ burst ကနေ steady state အထိ အမြင့်ဆုံး throughput ကို ထိန်းသိမ်းထားနိုင်ပြီး ioDrive Duo က ဒုတိယနေရာမှာရှိပြီး WarpDrive က တတိယနေရာမှာရှိပါတယ်။

100% write Web Server preconditioning လုပ်ငန်းစဉ်အတွင်း ပျမ်းမျှ latency အရ Linux ရှိ ioDrive Duo သည် Windows driverset ထက် response time အနည်းငယ်နိမ့်သော အားသာချက်ရှိကြောင်း ပြသခဲ့သည်။ LSI WarpDrive သည် ပျမ်းမျှ response time အတူတူပင် ပြသခဲ့ပြီး Z-Drive R4 သည် Windows နှင့် Linux စွမ်းဆောင်ရည်အကြား ကွာခြားချက်ကြီးမားသည်။

Web Server preconditioning curve မှာ အမြင့်ဆုံး latency ကိုကြည့်မယ်ဆိုရင် Z-Drive R4 ဟာ အမြင့်ဆုံး peak တွေရှိခဲ့ပေမယ့် level ကျသွားတဲ့အခါ high-latency spikes တွေ နည်းပါးသွားတယ်လို့ သိရပါတယ်။ ioDrive Duo ရဲ့ Linux စွမ်းဆောင်ရည်က throughput နဲ့ average response time တွေမှာ အားသာချက်ရှိပေမယ့် ဒီစမ်းသပ်မှုမှာ အမြင့်ဆုံး spikes တွေထဲက တစ်ခုဖြစ်ပြီး 1,200ms အထိ ရောက်ရှိခဲ့ပြီး Windows driver ကတော့ ယေဘုယျအားဖြင့် 300-400ms range မှာ spikes တွေ ရှိခဲ့လို့ တည်ငြိမ်မှုရှိပါတယ် (1,600ms ကျော် spike တစ်ခုမှလွဲ၍)။

SLC-based LSI WarpDrive သည် Windows ရှိ Web Server preconditioning လုပ်ငန်းစဉ်တစ်လျှောက် အနိမ့်ဆုံး standard deviation profile ကို ထိန်းသိမ်းထားနိုင်ခဲ့ပြီး Z-Drive R4 သည် ငြိမ်သက်သွားသည်နှင့် နောက်ကျကျန်နေခဲ့ပြီး ၎င်း၏ Linux driver ပါသည့် WarpDrive နှင့် ထို့နောက် Linux နှင့် Windows ရှိ ioDrive Duo တို့ နောက်တွင် ရှိနေသည်။

ကြိုတင်ပြင်ဆင်မှုလုပ်ငန်းစဉ်ပြီးနောက် 100% read Web Server workload သို့ ပြန်လည်ပြောင်းလဲလိုက်သောအခါ OCZ Z-Drive R4 သည် Windows စွမ်းဆောင်ရည်တွင် အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို ပေးဆောင်ခဲ့ပြီး အမြင့်ဆုံးအချိန်တွင် throughput speed ၏ နှစ်ဆကျော်ရှိသည်။ တစ်ချိန်တည်းမှာပင်၊ Windows တွင် အမြင့်ဆုံးစွမ်းဆောင်ရည်ကို ပေးဆောင်ခဲ့သည့်အချိန်နှင့် တူညီသောအချက်များတွင် အနှေးဆုံးဖြစ်သော ၎င်း၏ Linux စွမ်းဆောင်ရည်နှင့် နှိုင်းယှဉ်လျှင် ioDrive Duo သည် အမြန်ဆုံးအမြန်နှုန်းဖြင့် ပြန်လည်ရောက်ရှိလာခဲ့သော်လည်း queue depth မြင့်တက်လာသည်နှင့် Z-Drive R4 မှ လျင်မြန်စွာ ကျော်တက်သွားခဲ့သည်။

ioDrive Duo နှင့် WarpDrive နှစ်ခုစလုံးသည် Web Server ပျမ်းမျှ latency စမ်းသပ်မှုတွင် အတူတကွ နီးကပ်စွာ ရှိနေခဲ့သော်လည်း Windows တွင် R4 သည် နှစ်ခုစလုံးကို အလွယ်တကူ အနိုင်ယူနိုင်ခဲ့သည်။

1,000ms အတိုင်းအတာရှိ latency spikes မြင့်မားမှုအချို့သည် read-intensive Web Server စမ်းသပ်မှုတွင် ရှိနေသည်ကို မြင်တွေ့ရခြင်းမှာ အံ့သြစရာကောင်းသော်လည်း၊ Linux ရှိ ioDrive Duo တွင် ဤအပြုအမူကို အများဆုံးတွေ့ရသော်လည်း၊ စမ်းသပ်မှု၏ မတူညီသောအချိန်များတွင် စက်ပစ္စည်းသုံးခုလုံးတွင် သတိပြုမိခဲ့သည်။

Web Server activity ရဲ့ standard deviation plot က ioDrive Duo ဟာ queue depth rate မြင့်မားတဲ့အခါ response time တွေ တသမတ်တည်း မြင့်မားပြီး 16T/16Q မှာ အမြင့်ဆုံးရောက်ရှိနေတာကို ပြသခဲ့ပါတယ်။ ဒါဟာ အမြင့်ဆုံး workload တွေအထိ Windows စွမ်းဆောင်ရည်က တင်းကျပ်နေချိန်ပါ။ LSI WarpDrive ဟာ Linux ဘက်ခြမ်းမှာ latency က စတင်ခဲ့တဲ့အထိ အတော်လေး flat profile ကို ထိန်းသိမ်းထားနိုင်ခဲ့ပါတယ်။

Enterprise Synthetic Workload Analysis (High-performance Mode)

ဤသုံးသပ်ချက်တွင်ပါရှိသော PCIe Application Accelerators သုံးခုအနက် Fusion-io ioDrive Duo တစ်ခုတည်းသာ စွမ်းဆောင်ရည်မြှင့်တင်ရန်အတွက် sector အရွယ်အစား သို့မဟုတ် အသုံးပြုသူမြင်နိုင်သော format လုပ်ထားသော space ကိုပြောင်းလဲနိုင်သည့်နည်းလမ်းကို ပေးဆောင်ပါသည်။ drive ၏အစိတ်အပိုင်းတစ်ခုကို ပိုင်းခြားပြီး အခြားထုတ်ကုန်များနှင့် အသုံးမပြုနိုင်သော်လည်း ထိုလုပ်ငန်းစဉ်သည် အလိုလိုနားလည်လွယ်မှုမရှိပါ။ အချို့က စွမ်းဆောင်ရည်တိုးတက်မှုအတွက် စွမ်းရည်ကို လဲလှယ်သည့်အခါ သက်ရောက်မှုများကိုပင် မသိရှိကြပါ။

ဒီသုံးသပ်ချက်ရဲ့ အများစုဟာ ioDrive Duo ရဲ့ stock capabilities တွေကို အဓိကထားပေမယ့် ကျန်တဲ့အပိုင်းကတော့ high-performance mode နဲ့ stock configuration အကြား စွမ်းဆောင်ရည် ဘယ်လိုကွာခြားလဲဆိုတာကို သိရှိဖို့ ကျွန်တော်တို့ရဲ့ Synthetic Workload Analysis အသစ်ကို ပြန်လည်လေ့လာသုံးသပ်ထားပါတယ်။ device တစ်ခုကို 320GB stock size နဲ့ ioDrive Duo မှာ RAW NAND နဲ့ user-visible ကြားမှာ 20% over-provisioning အဆင့်ရှိပါတယ်။ ioDrive Duo ကို high-performance mode ကို format လုပ်ခြင်းအားဖြင့် အဲဒီ capacity ကို 256GB ဒါမှမဟုတ် 36% over-provisioning အထိ ကျဆင်းစေပြီး စုစုပေါင်း capacity ကို 640GB ကနေ 512GB အထိ ကျဆင်းစေပါတယ်။ ရရှိနိုင်တဲ့ capacity အများအပြားကို လဲလှယ်လိုက်ပေမယ့် steady-state performance ကို ဘယ်လောက်ထိ သက်ရောက်မှုရှိလဲဆိုတာကို အံ့သြမိပါတယ်။ အချို့ကိစ္စတွေမှာ performance ကို နှစ်ဆကျော် မြင့်တက်သွားတာကို တွေ့ရပါတယ်။

ioDrive Duo ကို high-performance mode မှာထားတဲ့အခါ 4K 100% write burst speeds တွေက ~257k IOPS မှာ အတူတူပဲရှိနေပေမယ့် steady-state performance ကွာခြားချက်ကတော့ သိသိသာသာပါပဲ။ stock configuration မှာရှိတဲ့ ioDrive Duo က preconditioning phase ရဲ့အဆုံးမှာ 41-42k IOPS throughput speeds တွေကို ထိန်းသိမ်းထားနိုင်ခဲ့ပေမယ့် high-performance mode က 90,000 IOPS အထိ levels တွေကို မြှင့်တင်ပေးခဲ့ပါတယ်။ အဲဒါက user-capacity အချို့ကို စွန့်လွှတ်လိုက်ခြင်းအားဖြင့် ၂ ဆ ခုန်တက်သွားတာထက်တောင် ပိုများပါတယ်။

ပိုမိုမြန်ဆန်သော throughput နှင့်အတူ 4K ရေးသားမှုကြိုတင်ပြင်ဆင်ခြင်းအဆင့်တွင် latency သည် ထက်ဝက်လျော့ကျသွားသည်။

4K ရေးသားမှုကြိုတင်ပြင်ဆင်မှုစမ်းသပ်မှု၏ အများဆုံး latency ပရိုဖိုင်ကိုကြည့်သောအခါ၊ ဤတစ်ကြိမ်တွင် များစွာနိမ့်သော်လည်း ባህሪያትများစွာသည် အတူတူပင်ကျန်ရှိနေခဲ့သည်။ Windows 4K latency သည် မူလက အနည်းငယ်ပိုမိုမြင့်မားသော်လည်း Linux ပတ်ဝန်းကျင်တွင်တွေ့ရသော high-latency spikes များနည်းပါးခဲ့သည်။ drive ကို high-performance mode သို့ format လုပ်သောအခါ Windows profile တွင် jitter ပိုမိုရှိနေသော်လည်း Linux profile သည် ပိုမိုကောင်းမွန်သောတည်ငြိမ်မှုရှိပြီး ယခင်ကတွေ့မြင်ခဲ့ရသော high-latency spikes များမရှိပါ။

ioDrive Duo ရဲ့ မြင့်မားတဲ့စွမ်းဆောင်ရည်မုဒ်မှာ သိသိသာသာတိုးတက်မှုကိုပြသတဲ့ အထင်ရှားဆုံးဇယားကတော့ latency standard deviation profile ပါ။ background GC activity အတွက် နေရာလွတ်တိုးလာတာနဲ့အမျှ 4K 100% write load အပြည့်အောက်မှာ standard deviation ဟာ အရင်က 25-30ms မှ 2-5ms အထိ လျော့ကျသွားပါတယ်။

ကျွန်ုပ်တို့၏ steady-state 4K 100% read နှင့် write ရမှတ်များကို stock နှင့် high performance mode များအကြား နှိုင်းယှဉ်ကြည့်လျှင်၊ read performance တွင် တိုးတက်မှုကို မတွေ့ရှိခဲ့ပါ။ ၎င်းသည် ယေဘုယျအားဖြင့် steady-state write speeds များကိုသာ တိုးတက်ကောင်းမွန်စေပြီး read သို့မဟုတ် write burst speeds များကို သက်ရောက်မှုမရှိပါ။ ဤကိစ္စတွင် 100% 4K read performance သည် 140,000 IOPS ကျော်တွင်သာ ရှိနေပြီး steady-state write performance သည် 40.9-42.6K မှ 90.4-91K IOPS အထိ ခုန်တက်သွားခဲ့သည်။

ကြိုတင်ပြင်ဆင်မှုအဆင့်တွင် ကျွန်ုပ်တို့ မူလက တွေ့ရှိခဲ့သည့် 4K ရေးသားမှု latency တိုးတက်မှုသည် stock mode တွင် 6-6.25ms နှင့် နှိုင်းယှဉ်ပါက high-performance mode ioDrive Duo တွင် ပျမ်းမျှ 2.80-2.82ms အထိ ရှိသည်။

4K ဖတ်ရှုမှုပျမ်းမျှတုံ့ပြန်မှုအချိန် သိသိသာသာကျဆင်းခြင်း သို့မဟုတ် throughput တိုးလာခြင်းကို ကျွန်ုပ်တို့ မတိုင်းတာနိုင်သော်လည်း၊ မြင့်မားသောစွမ်းဆောင်ရည်ဖြင့် ပြင်ဆင်သတ်မှတ်ထားသော ioDrive Duo သည် အမြင့်ဆုံးဖတ်ရှုမှုတုံ့ပြန်မှုများကို များစွာနိမ့်ကျစေခဲ့သည်။ အမြင့်ဆုံး 4K ရေးသားမှုတုံ့ပြန်မှုအချိန်များလည်း သိသိသာသာကျဆင်းသွားခဲ့သည်။

over-provisioning mode နှစ်ခုကြား standard deviation ကွာခြားချက်မှာ နေ့နှင့်ညဖြစ်ပြီး high-performance ioDrive Duo သည် ယခင် 25.6-31.6ms နှင့် 1.70-1.76ms တိုင်းတာခဲ့သည်။

ကျပန်း 4K ရေးသားစွမ်းဆောင်ရည်မှာ စွမ်းဆောင်ရည်မြင့်တက်လာတာက အထင်ကြီးစရာကောင်းပေမယ့် ioDrive Duo ဟာ read activity ရောနှောပါဝင်တဲ့ workload တစ်ခုမှာ ဘယ်လိုပြောင်းလဲသွားမလဲဆိုတာကို ကျွန်တော်တို့ ပိုစိတ်ဝင်စားခဲ့ပါတယ်။ ကျွန်တော်တို့ရဲ့ 8K 70/30 preconditioning စမ်းသပ်မှုမှာ throughput ဟာ high performance mode မှာ 76K IOPS မတိုင်ခင် 51-53k IOPS အတိုင်းအတာကနေ သိသိသာသာ တိုးတက်လာခဲ့ပါတယ်။ formatting configuration တွေကြားမှာ burst speeds တွေက အတော်လေးဆင်တူပေမယ့် over-provisioned ioDrive Duo ဟာ steady-state ကို ပိုမြန်မြန်ကျဆင်းသွားပါတယ်။

8K 70/30 workload မှာရှိတဲ့ latency ကိုကြည့်လိုက်ရင် high performance mode မှာ ioDrive Duo မှာရှိတဲ့ Linux နဲ့ Windows driver အကြား အလယ်အလတ်ကွာခြားချက်တွေ ပျောက်ကွယ်သွားပါတယ်။ ပျမ်းမျှ latency ဟာ သိသိသာသာကျဆင်းသွားပြီး preconditioning လုပ်ငန်းစဉ်တစ်လျှောက်လုံးမှာ အလွန်တသမတ်တည်းရှိနေခဲ့ပါတယ်။

throughput နှင့် average latency တိုးတက်မှုများသည် အရေးကြီးသော်လည်း၊ ioDrive Duo ၏ configuration ကိုပြောင်းလဲသောအခါ အာရုံစိုက်ရမည့် နောက်ထပ်အချက်တစ်ခုမှာ peak latency ဖြစ်သည်။ ဤကိစ္စတွင်၊ အပို over-provisioned space သည် drive ကို background တွင် နေရာအလုံအလောက်ပေးခဲ့ပြီး spike configuration တွင် ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသော max latency jump အများစုကို ဖိနှိပ်ပေးခဲ့သည်။ ထိုသို့ပြောသော်လည်း ၎င်းတို့သည် လုံးဝပျောက်ကွယ်သွားခြင်းမဟုတ်သော်လည်း activity အများစုသည် များစွာနိမ့်ကျသောအဆင့်သို့ ကျဆင်းသွားခဲ့သည်။

latency standard deviation ကိုကြည့်မယ်ဆိုရင် ioDrive Duo ကို over-provisioning space ထပ်ပေးတဲ့အခါ ဘယ်လောက်ကြီးမားတဲ့သက်ရောက်မှုရှိလဲဆိုတာကို အပြည့်အစုံမြင်နိုင်ပါတယ်။ standard deviation ဟာ preconditioning လုပ်ငန်းစဉ်တစ်လျှောက်လုံး 2ms ဝန်းကျင်မှာရှိနေပြီး 8-12ms ပဲရှိပါတယ်။

ioDrive Duo သည် ကျွန်ုပ်တို့၏ အဓိက throughput စမ်းသပ်မှုများတွင် 2T/2Q နှင့် 16T/16Q အကြား ဝန်ကို ပြောင်းလဲသည့် စွမ်းဆောင်ရည် အကျိုးကျေးဇူးများကို ဆက်လက်ပြသခဲ့သည်။

ioDrive Duo စတော့ရှယ်ယာကို high-performance mode များနှင့် နှိုင်းယှဉ်သောအခါ ကျွန်ုပ်တို့၏ 8K 70/30 workload တွင် ပျမ်းမျှ latency ကွာခြားချက်များကို ကြည့်လျှင် thread count တစ်ခုစီတွင် queue depths မြင့်မားမှုတွင် အထင်ရှားဆုံးဖြစ်သည်။

8K 70/30 ကြိုတင်အခြေအနေစမ်းသပ်မှု၏ အမြင့်ဆုံးနှောင့်နှေးမှုအဆင့်တွင် ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသည့်အတိုင်း၊ စမ်းသပ်မှုကာလအတွင်း အမြင့်ဆုံးအထွတ်အထိပ်များစွာကျန်ရှိနေသော်လည်း ၎င်းတို့အနက် နည်းပါးခဲ့သည်။

ဘုတ်အဖွဲ့တစ်လျှောက် latency standard deviation ကို နှိုင်းယှဉ်ကြည့်လျှင်၊ over-provisioning သည် queue-depth load များ တိုးလာသည့် အချို့တွင် အကြီးမားဆုံး သက်ရောက်မှုရှိခဲ့ပြီး 8T/16Q ကဲ့သို့သော နေရာများတွင်မူ မည်သည့်ပြောင်းလဲမှုမျှ မတွေ့ရှိခဲ့ပါ။

Fusion ioDrive Duo သည် over-provisioning ပမာဏကို တိုးမြှင့်ခြင်းဖြင့် စုစုပေါင်း throughput တွင် တိုးတက်မှု သိပ်မတွေ့ရပါ။ 100% 4K write သို့မဟုတ် 8K 70/30% workload တွင် တွေ့ရှိရသော သိသိသာသာ ခုန်တက်မှုနှင့် နှိုင်းယှဉ်ပါက တိုးတက်မှုမှာ အသင့်အတင့်သာ ရှိသော်လည်း စွမ်းဆောင်ရည်မှာ ဆက်လက်တိုးတက်နေဆဲဖြစ်သည်။

File Server ကြိုတင်အခြေအနေစမ်းသပ်မှုကာလအတွင်း ပျမ်းမျှ latency သည် ioDrive Duo သည် steady-state စွမ်းဆောင်ရည်နှင့်နီးကပ်လာသည်နှင့်အမျှ 7-7.5ms ခန့်မှ 6ms ကျော်အထိ တိုးတက်လာခဲ့သည်။

Fusion ioDrive Duo မှာ throughput ဒါမှမဟုတ် average latency မှာ သိသာထင်ရှားတဲ့ တိုးတက်မှု မတွေ့ရပေမယ့် stock over-provisioning configuration မှာ တွေ့ရတဲ့ high-latency spikes အများစုကို နှိမ်နင်းနိုင်ခဲ့ပါတယ်။ အကြီးမားဆုံး တိုးတက်မှုကတော့ Windows driver မှာ ဖြစ်ပြီး၊ အရင်က 225-250ms အကွာအဝေးနဲ့ ယှဉ်ရင် steady state မှာ peak latency ceiling 50-75ms လောက်ကို ထိန်းသိမ်းထားနိုင်ခဲ့ပါတယ်။

File Server ကြိုတင်အခြေအနေစမ်းသပ်မှုတွင် latency standard deviation ကို ခွဲခြမ်းစိတ်ဖြာကြည့်ရာတွင်၊ over-provisioning တိုးမြှင့်ခြင်းသည် drive သည် steady-state အနီးသို့ရောက်သည်နှင့် flutter ကို အနည်းဆုံးဖြစ်အောင်ထိန်းထားပေးခဲ့သည်။ Linux latency standard deviation သည် သိပ်မတိုးတက်ခဲ့သော်လည်း Windows standard deviation သည် 12-14ms မှ 3ms အောက်သို့ ကျဆင်းသွားခဲ့သည်။

Fusion ioDrive Duo ၏ over-provisioning တိုးမြှင့်ခြင်းက ကတ်အား thread နှင့် queue depth ပေါင်းစပ်မှုအများစုတွင် စွမ်းဆောင်ရည် 5,000 IOPS ခန့် တိုးမြှင့်နိုင်စေပြီး queue depth load မြင့်မားလာသည့်အခါ အများဆုံးတိုးလာပါသည်။

နှောင့်နှေးမှု (latency) ကို နယ်ပယ်နှစ်ခုလုံးတွင် တိုးတက်ကောင်းမွန်လာစေပြီး Windows ရှိ Fusin ioDrive Duo သည် 16T/16Q load တွင် အကြီးမားဆုံးတိုးတက်မှုကို ရရှိခဲ့ပြီး အနှေးဆုံးမှ အမြန်ဆုံးသို့ ရောက်ရှိသွားခဲ့သည်။

File Server workload ရဲ့ အမြင့်ဆုံး latency ကို နှိုင်းယှဉ်ကြည့်မယ်ဆိုရင် ioDrive Duo ဟာ Linux မှာ သိသိသာသာ ငြိမ်သက်သွားပြီး အရင်က 1,000ms အမြင့်ဆုံးတွေ အတော်များများ ဆုံးရှုံးသွားပါတယ်။ ဒီတစ်ခါတော့ Windows စမ်းသပ်မှုမှာ 1,000ms အမြင့်ဆုံး တစ်ခုတည်းသာ ရှိခဲ့ပါတယ်။

ဘုတ်အဖွဲ့တစ်လျှောက် စံသွေဖည်မှု ကောင်းမွန်သော ပမာဏ ကျဆင်းသွားခဲ့ပြီး ioDrive Duo သည် အလွန်အကျွံ ပံ့ပိုးပေးမှု မြင့်တက်လာခြင်းနှင့်အတူ မည်မျှ ငြိမ်သက်သွားသည်ကို ပြသနေသည်။

ကျွန်ုပ်တို့ရဲ့ Web Server preconditioning curve ဟာ Web Server activity ရဲ့ အကောင်းဆုံးကိုယ်စားပြုမှုမဟုတ်ပေမယ့်၊ အမှန်တကယ်တော့ 100% write မှာတော့ ပြောင်းပြန်ပါပဲ။ over-provisioning တိုးလာခြင်းက ဘယ်လောက်အကျိုးသက်ရောက်မှုရှိနိုင်လဲဆိုတာကို ပြသနေပါတယ်။ စုစုပေါင်း throughput ဟာ OCZ Z-Drive R4 ထက်တောင် ကျော်လွန်သွားခဲ့ပါတယ်။

ကျွန်ုပ်တို့၏ Web Server preconditioning စမ်းသပ်မှုကာလအတွင်း ပျမ်းမျှ latency ကို ယခင်က 20ms ကျော်မှ high-performance mode တွင် 10ms ကျော်အထိ ထက်ဝက်လျှော့ချခဲ့သည်။

latency မြင့်မားသော မြင့်တက်မှုအားလုံးနီးပါးကို over-provisioning တိုးမြှင့်ခြင်းဖြင့် နှိမ်နင်းနိုင်ခဲ့ပြီး Linux စွမ်းဆောင်ရည်မှာ အများဆုံးတိုးတက်ကောင်းမွန်လာခဲ့သည်။

Web Server ကြိုတင်ပြင်ဆင်မှုအပိုင်း၏ ကာလအတွင်း Latency standard deviation သည် သိသိသာသာ တိုးတက်လာခဲ့ပြီး Linux ဘက်ခြမ်းတွင် အကြီးမားဆုံးပြောင်းလဲမှုမှာ stock performance နှင့် နှိုင်းယှဉ်ပါက curve သည် flat နီးပါးဖြစ်သည်။

Web Server profile ကို 100% read သို့ ပြန်ပြောင်းလိုက်သောအခါ၊ stock နှင့် ဤ workload တွင် over-provisioning တိုးလာခြင်းကြား throughput speed တွင် အနည်းငယ်သာ တိုးတက်မှုရှိသည် သို့မဟုတ် လုံးဝမရှိသည်ကို ကျွန်ုပ်တို့ တွေ့ရှိခဲ့ရသည်။ သို့သော် over-provisioning သည် write နှင့်ဆက်စပ်သော စွမ်းဆောင်ရည်ကိုသာ အကျိုးပြုသောကြောင့် ၎င်းသည် အံ့သြစရာမဟုတ်ပါ။

ပျမ်းမျှ latency သည် ဘုတ်အဖွဲ့တစ်ခုလုံးတွင် အတူတူနီးပါးဖြစ်ပြီး၊ အလွန်အကျွံ provisioning ပြုလုပ်ခြင်းဖြင့် တိုးတက်မှုလက္ခဏာ အနည်းငယ်သာ ပြသခဲ့သည်။

throughput နှင့် ပျမ်းမျှ latency တိုးတက်မလာသော်လည်း၊ over-provisioning အဆင့်များ မြင့်တက်လာသောအခါ ဤ 100% read Web Server ပရိုဖိုင်တွင် high-latency response time များ လုံးဝပျောက်ကွယ်သွားပါသည်။

ioDrive Duo ကို High-Performance mode မှာထားရင် ကျွန်ုပ်တို့ရဲ့ Web Server profile မှာ peak latency လျော့ကျသွားသလိုပဲ၊ latency standard deviation ကလည်း Linux စမ်းသပ်မှုမှာ အများကြီးကျဆင်းသွားပေမယ့် Windows စမ်းသပ်မှုမှာတော့ အနည်းငယ်သာတိုးတက်မှုရှိခဲ့ပါတယ်။

ကောက်ချက်

ioDrive Duo ကို ပြန်လည်လေ့လာကြည့်မယ်ဆိုရင် ထူးခြားတဲ့အချက်တွေ အများကြီးရှိပါတယ်။ Fusion-io ဟာ ဒီ storage နည်းပညာရဲ့ အစောပိုင်း ရှေ့ဆောင်ကုမ္ပဏီတစ်ခုဖြစ်ပြီး storage နဲ့ ပတ်သက်ပြီး အဓိက ဉာဏပစ္စည်းပိုင်ဆိုင်မှုတွေ အများကြီးပိုင်ဆိုင်ထားတာကြောင့် အလုံးစုံ package က ဒီလောက်တင်းကျပ်တာ အံ့သြစရာတော့ မဟုတ်ပါဘူး၊ ဒါပေမယ့် တိကျမှုအဆင့်ကတော့ ချီးကျူးထိုက်ပါတယ်။ အရင်မျိုးဆက်နည်းပညာတွေလိုပဲ စွမ်းဆောင်ရည်ပိုင်းမှာ တိကျမှုတစ်ခုတည်းတင် မဟုတ်ပါဘူး၊ ကောင်းကောင်းအလုပ်လုပ်ပါတယ်။ ဒါပေမယ့် packaging ကနေ software interface အထိ၊ ကျွန်တော်တို့ စမ်းသပ်ခဲ့တဲ့ Windows နဲ့ Linux ဗားရှင်းတွေ အပါအဝင် သူတို့ရဲ့ support လုပ်ထားတဲ့ platform အများစုမှာ တသမတ်တည်း စွမ်းဆောင်ရည်အထိ နေရာတိုင်းမှာ ချောမွေ့တဲ့ ခံစားချက်အရ တိကျမှုရှိပါတယ်။ လက်ရှိ ioDrive Duo ကို ပထမဆုံးထွက်ရှိချိန်ကတည်းက software update အကြိမ်ပေါင်းများစွာ ပြုလုပ်ခဲ့ပေမယ့် drive ကို ၂၀၀၉ ခုနှစ် အစောပိုင်းမှာ ထွက်ရှိခဲ့တာ ထောက်ရှုရင် သက်တမ်းက အရမ်းနည်းပါတယ်။

MLC-based drive အတွက် ioDrive Duo ဟာ သူ့ရဲ့ အနီးကပ်ဆုံးပြိုင်ဘက်လို့ ယူဆရတဲ့ SLC-based LSI WarpDrive နဲ့ ယှဉ်ရင် အလွန်ကောင်းမွန်ပါတယ်။ Enterprise Application Acceleration segment အတွက် တိကျစွာ ဒီဇိုင်းထုတ်ထားတဲ့ ထုတ်ကုန်တွေအနေနဲ့ မော်ဒယ်နှစ်ခုစလုံးဟာ OS platform အများအပြားမှာ workload အများအပြားနဲ့ ထူးချွန်ပါတယ်။ စမ်းသပ်မှုတိုင်းလိုလိုမှာ ioDrive Duo ဟာ တည်ငြိမ်တဲ့ စွမ်းဆောင်ရည်ကို ပေးစွမ်းနိုင်ပေမယ့် အမြင့်ဆုံး latency အရ SLC-NAND ပါတဲ့ WarpDrive ဟာ MLC-equipped 640GB ioDrive Duo ထက် ပိုကောင်းပါတယ်။ MLC-based OCZ Z-Drive R4 နဲ့ နှိုင်းယှဉ်ကြည့်တဲ့အခါ ဒီထုတ်ကုန်နှစ်ခုလုံးကို မတူညီတဲ့ ဈေးကွက်တွေအတွက် ဘယ်လိုဒီဇိုင်းထုတ်ထားလဲဆိုတာ မြင်သာပါတယ်။ Z-Drive ဟာ ဈေးနှုန်းသက်သာတဲ့ consumer grade NAND နဲ့ newer-generation controller တွေကြောင့် မြန်နှုန်းမြင့်မားပြီး စွမ်းရည်မြင့်မားပေမယ့် သူ့ရဲ့ peak latency နဲ့ standard deviation ကတော့ ioDrive Duo ဒါမှမဟုတ် WarpDrive ထက် ပိုပြီး မကိုက်ညီပါဘူး။ Z-Drive ရဲ့ အားသာချက်တွေက read-heavy ဘက်မှာ ပိုရှိပြီး ioDrive Duo နဲ့ WarpDrive ကတော့ write-heavy environment မှာ သူတို့ရဲ့နေရာကို ရှာတွေ့ခဲ့ပါတယ်။ Windows ပြင်ပတွင် ဖြန့်ကျက်မှုများအတွက်၊ ioDrive Duo နှင့် WarpDrive နှစ်ခုစလုံးသည် Linux တွင် အလားတူစွမ်းဆောင်ရည်ကို ပေးဆောင်သော်လည်း၊ Z-Drive R4 ၏ စွမ်းဆောင်ရည်သည် ၎င်း၏ Windows ရမှတ်များနှင့် သိသိသာသာ ကွာခြားပြီး စွမ်းဆောင်ရည်တစ်လျှောက်လုံး အဆပေါင်းများစွာ နှေးကွေးသွားသည်။

ဟုတ်ပါတယ်၊ စတော့စွမ်းရည်ရှိတဲ့ ioDrive Duo မှာ အားနည်းချက်တွေ မရှိပါဘူး၊ steady-state မှာရှိနေချိန်မှာ low နဲ့ high queue depth စမ်းသပ်မှုတွေမှာ မကြာခဏ 1,000ms blips တွေ ဖြစ်ပေါ်တာကို ကြည့်ရင် သိနိုင်ပါတယ်။ ဒါပေမယ့် standard deviation တသမတ်တည်းရှိတာကြောင့်၊ အဲဒီ blips အများစုဟာ response rates မြင့်မားတာကို တသမတ်တည်း မတွေ့ရဘဲ အချိန်အနည်းငယ်သာ ဖြစ်ပျက်ခဲ့တာပါ။ platform ပေါ်မူတည်ပြီး နောက်ထပ် စိုးရိမ်စရာ အသေးအဖွဲလေးတစ်ခု ရှိပါတယ်၊ ဘာလို့လဲဆိုတော့ Linux ဟာ Windows စွမ်းဆောင်ရည်ထက် အနည်းငယ်သာ သာလွန်နေရင်တောင်မှပါ။ ဒါပေမယ့် နောက်ဆုံးမှာတော့ ဒီ latency စိုးရိမ်မှုတွေက SLC-based ioDrive Duo မှာ မပေါ်လာနိုင်ပါဘူး။ 300GB SLC configuration မှာပဲ ရနိုင်တဲ့ LSI WarpDrive နဲ့ ပိုနီးစပ်တဲ့ ပြိုင်ဘက်တစ်ယောက်အဖြစ် မြင်နိုင်ပါတယ်။

ioDrive Duo ကို high-performance mode မှာ စမ်းသပ်ကြည့်တဲ့အခါ ioDimm တစ်ခုကို 320GB ကနေ 256GB အထိ format ချလိုက်တဲ့အခါ စွမ်းဆောင်ရည်က အချို့ကိစ္စတွေမှာ နှစ်ဆထက်မက မြင့်တက်လာပါတယ်။ 4K random write performance က 40,000 IOPS ကနေ 90,000 IOPS အထိ မြင့်တက်လာပြီး တစ်ချိန်တည်းမှာပဲ peak latency က ကျောက်တုံးကြီးလို ကျဆင်းသွားပါတယ်။ မြန်နှုန်းနဲ့ latency နိမ့်တာကို ဦးစားပေးပြီး capacity ကို လဲလှယ်ချင်တဲ့ enterprise user တွေအတွက် Fusion-io က end-user အနေနဲ့ အဲဒီပြောင်းလဲမှုတွေ ပြုလုပ်ဖို့ လွယ်ကူတဲ့နည်းလမ်းကို ပေးစွမ်းပါတယ်။ user-space ကို ကိုယ်တိုင် partition လုပ်ပြီး section တစ်ခုကို အသုံးမပြုဘဲ ထားခဲ့မယ်ဆိုရင် ယှဉ်ပြိုင်နေတဲ့ PCIe solution တွေက ဒီလို performance configuration မျိုး မပေးနိုင်ပါဘူး။ application အားလုံးမှာ မဖြစ်နိုင်ပါဘူး။

Pros

• PCIe Application Accelerator ရောင်းချသူထံမှ software နှင့် hardware ၏ အပြည့်စုံဆုံးပေါင်းစပ်မှု
• Windows နှင့် Linux drivers များအကြား အနီးစပ်ဆုံး စွမ်းဆောင်ရည် ညီမျှမှု
• stock mode မှာ ကောင်းမွန်တဲ့ throughput နဲ့ latency ရှိပြီး high performance mode မှာ ပိုကောင်းလာပါတယ်။
• ကောင်းမွန်သော low-queue/low-thread count စွမ်းဆောင်ရည်

အားနည်းချက်များ

• အခြားဖြေရှင်းချက်များထက် ထည့်သွင်းခြင်းနှင့် ကနဦးစနစ်ထည့်သွင်းခြင်းသည် ပိုမိုခက်ခဲနိုင်သည် (ပြင်ပပါဝါလိုအပ်သည်၊ built-in OS driver ပံ့ပိုးမှုမရှိပါ)
• ioDrive ကို memory tier အနေနဲ့ တင်ပြဖို့အတွက် VSL footprint ကို အသုံးပြုပြီး system resource တွေ ပိုမိုလိုအပ်ပါတယ်။

အောက်ဆုံးလိုင်း

အသုံးပြုရလွယ်ကူမှုရှုထောင့်မှကြည့်လျှင် ioDrive Duo သည် PCIe Application Accelerator ကို အသုံးပြုသူထံ မည်သို့တင်ပြသင့်သည်ဆိုသည့် စံနှုန်းကို သတ်မှတ်ပေးပါသည်။ အသုံးပြုထားသော operating system မည်သို့ပင်ရှိစေကာမူ ပေးထားသော GUI နှင့် console management tools များအထိ အတွေ့အကြုံမှာ အတူတူပင်ဖြစ်သည်။ ပထမဆုံးနေ့မှစ၍ အသုံးပြုသူသည် OS မည်သို့ပင်ရှိစေကာမူ ioDrive Duo ၏ hardware status ကို ရယူခြင်း၊ format လုပ်ခြင်း သို့မဟုတ် ၎င်းတို့နှစ်သက်ရာ over-provisioning ပြုလုပ်ခြင်းတို့ကို ပြုလုပ်နိုင်ပြီး production တွင် ထည့်သွင်းနိုင်ပါသည်။ ioDrive Duo သည် enterprise storage ဈေးကွက်ရှိ အခြားမည်သည့်အရာထက်မဆို ပိုမိုအဆင့်မြင့်သော ပြီးပြည့်စုံသော ကမ်းလှမ်းချက်တစ်ခုဖြစ်သည်။

Fusion-io Duo ထုတ်ကုန်စာမျက်နှာ

ဤသုံးသပ်ချက်ကို ဆွေးနွေးပါ

အပ်ဒိတ် ၈/၁၇/၁၂ – ကျွန်ုပ်တို့၏ LSI Nytro WarpDrive သုံးသပ်ချက်ကို ဤ Fusion-io သုံးသပ်ချက်တွင် အသုံးပြုထားသော ဇယားများနှင့် တွဲ၍ တင်ထားပါသည်။