အခမဲ့ RAM များစွာ၊ NVMe Intel P4500 နှင့် အရာအားလုံးသည် အလွန်နှေးကွေးသည် - swap partition တစ်ခု၏ မအောင်မြင်သော ထပ်တိုးမှုဇာတ်လမ်း

ဤဆောင်းပါးတွင်၊ ကျွန်ုပ်၏ VPS cloud ရှိဆာဗာများထဲမှတစ်ခုနှင့် မကြာသေးမီက ဖြစ်ပွားခဲ့သော အခြေအနေတစ်ခုအကြောင်းကို ကျွန်ုပ်ပြောပါမည်။ ကျွန်ုပ်သည် Linux ဆာဗာများကို ပြင်ဆင်ခြင်းနှင့် ပြဿနာဖြေရှင်းနေသည်မှာ 15 နှစ်ခန့်ရှိပြီဖြစ်သော်လည်း ဤကိစ္စသည် ကျွန်ုပ်၏အလေ့အကျင့်နှင့် လုံးဝကိုက်ညီမှုမရှိပါ - ကျွန်ုပ်သည် မှားယွင်းသောယူဆချက်များစွာကို ပြုလုပ်ခဲ့ပြီး ပြဿနာ၏အကြောင်းရင်းကို မှန်ကန်စွာဆုံးဖြတ်၍ ဖြေရှင်းနိုင်ခြင်းမပြုမီ အနည်းငယ်စိတ်ပျက်သွားပါသည်။ .

နိဒါန်း

ကျွန်ုပ်တို့သည် အောက်ပါဖွဲ့စည်းပုံစနစ်ဖြင့် စံဆာဗာများပေါ်တွင် တည်ဆောက်ထားသည့် အလတ်စား cloud တစ်ခုကို လုပ်ဆောင်သည် - 32 cores၊ 256 GB RAM နှင့် 4500TB PCI-E Intel P4 NVMe drive တစ်ခု။ VM instance type အဆင့်တွင် မှန်ကန်သောကန့်သတ်ချက်ကို ပံ့ပိုးပေးခြင်းဖြင့် IO overhead နှင့်ပတ်သက်ပြီး စိတ်ပူစရာမလိုတော့သောကြောင့် ဤဖွဲ့စည်းပုံကို အလွန်နှစ်သက်ပါသည်။ NVMe Intel ကြောင့်ပါ။ P4500 အထင်ကြီးလောက်သော စွမ်းဆောင်ရည်ရှိပြီး၊ ကျွန်ုပ်တို့သည် စက်များအတွက် IOPS အပြည့်အ၀ စီမံဆောင်ရွက်ပေးခြင်းနှင့် အရန်သိုလှောင်မှု နှစ်ခုလုံးကို တစ်ပြိုင်နက် IOWAIT သုညဖြင့် အရန်ဆာဗာတစ်ခုသို့ ပံ့ပိုးပေးနိုင်ပါသည်။

ကျွန်ုပ်တို့သည် ပေါင်းစည်းထားသော SDN နှင့် အခြားသော ခေတ်ဆန်သော၊ ခေတ်ဆန်သော၊ လူငယ်အရာများကို သိမ်းဆည်းရန် VM အတွဲများကို သိမ်းဆည်းရန်အတွက် ခေတ်မီသော၊ ခေတ်မီသော၊ လူငယ်များအသုံးမပြုသော ယုံကြည်သူဟောင်းများထဲမှ တစ်ဦးဖြစ်ပြီး၊ စနစ်ပိုမိုရိုးရှင်းလေ၊ ပြဿနာဖြေရှင်းရန် လွယ်ကူလေလေ "ပင်မဆရာကြီးသွားပြီ။ တောင်တွေဆီကို။" ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် LVM2 ၏ထိပ်တွင်ဖြန့်ကျက်ထားသည့် XFS သို့မဟုတ် EXT4 တွင် VM အတွဲများကို QCOW2 ဖော်မတ်ဖြင့် သိမ်းဆည်းထားသည်။

စုစည်းမှုအတွက် ကျွန်ုပ်တို့အသုံးပြုသည့် ထုတ်ကုန်ဖြစ်သည့် Apache CloudStack မှလည်း QCOW2 ကို အသုံးပြုခိုင်းပါသည်။

အရန်ကူးယူရန်၊ ကျွန်ုပ်တို့သည် LVM2 လျှပ်တစ်ပြက်ရိုက်ချက်အဖြစ် အသံအတိုးအကျယ်ကို အပြည့်အ၀ယူပါသည် (ဟုတ်ကဲ့၊ LVM2 လျှပ်တစ်ပြက်ရိုက်ချက်များ နှေးကွေးသည်ကို ကျွန်ုပ်တို့သိသည်၊ သို့သော် Intel P4500 သည် ကျွန်ုပ်တို့ကို ဤနေရာတွင်လည်း ကူညီပေးသည်)။ ကျွန်တော်တို lvmcreate -s .. အကူအညီနှင့်အတူ dd အရန်မိတ္တူကို ZFS သိုလှောင်မှုရှိသော အဝေးထိန်းဆာဗာသို့ ပေးပို့ပါသည်။ ဤတွင် ကျွန်ုပ်တို့သည် အနည်းငယ်တိုးတက်နေသေးသည် - ပြီးနောက် ZFS သည် အချက်အလက်များကို ချုံ့ထားသောပုံစံဖြင့် သိမ်းဆည်းနိုင်ပြီး ၎င်းကို အသုံးပြု၍ လျှင်မြန်စွာ ပြန်လည်ရယူနိုင်သည်။ DD သို့မဟုတ် VM အတွဲများကို အသုံးပြု၍ တစ်ဦးချင်းရယူပါ။ mount -o loop ....

သင်သည် LVM2 volume ၏ ပုံအပြည့်အစုံကို မဖယ်ရှားနိုင်သော်လည်း၊ ဖိုင်စနစ်တွင် ထည့်သွင်းပါ။ RO QCOW2 ရုပ်ပုံများကို ၎င်းတို့ကိုယ်တိုင် ကူးယူပြီး၊ သို့သော်၊ XFS သည် ချက်ချင်းမဟုတ်သော်လည်း မှန်းလို့မရသောနည်းလမ်းဖြင့် ကျွန်ုပ်တို့ရင်ဆိုင်ခဲ့ရသည်။ စနေ၊ ည သို့မဟုတ် အားလပ်ရက်များတွင် မည်သည့်အချိန်တွင် ဖြစ်လာမည်ကို မရှင်းလင်းသော အမှားများကြောင့် hypervisor မှ ရုတ်တရက် "တုတ်" ကို လက်ခံကျင်းပသည့်အခါ ၎င်းကို ကျွန်ုပ်တို့ အမှန်တကယ် မကြိုက်ပါ။ ထို့ကြောင့် XFS အတွက် ကျွန်ုပ်တို့သည် လျှပ်တစ်ပြက်ရိုက်ထည့်ခြင်းကို မသုံးပါ။ RO volumes များကို ထုတ်ယူရန်၊ ကျွန်ုပ်တို့သည် LVM2 volume တစ်ခုလုံးကို ရိုးရိုးကူးယူပါသည်။

အရန်ဆာဗာသို့ အရန်ကူးယူခြင်း၏အမြန်နှုန်းကို 600-800 MB/s ခန့်ရှိသည့် အရန်ဆာဗာ၏စွမ်းဆောင်ရည်ဖြင့် ကျွန်ုပ်တို့၏အခြေအနေတွင် ဆုံးဖြတ်သည်၊ နောက်ထပ်ကန့်သတ်ချက်တစ်ခုမှာ အရန်ဆာဗာချိတ်ဆက်ထားသည့် 10Gbit/s ချန်နယ်ဖြစ်သည်။ အစုအဝေးသို့။

ဤကိစ္စတွင်၊ hypervisor ဆာဗာ 8 ခု၏ အရန်မိတ္တူများကို အရန်ဆာဗာတစ်ခုသို့ တစ်ပြိုင်နက် အပ်လုဒ်လုပ်ထားသည်။ ထို့ကြောင့်၊ အရန်ဆာဗာ၏ဒစ်နှင့် ကွန်ရက်ခွဲစနစ်များသည် နှေးကွေးခြင်းကြောင့် hypervisor hosts များ၏ disk ခွဲစနစ်များကို overload လုပ်ခြင်းအား ခွင့်မပြုပါ၊ အဘယ်ကြောင့်ဆိုသော် hypervisor hosts သည် လွယ်ကူစွာလုပ်ဆောင်နိုင်သည့် 8 GB/sec ဟူ၍ မလုပ်ဆောင်နိုင်သောကြောင့်၊ ဟင်းသီးဟင်းရွက်။

အထက်ဖော်ပြပါ ကူးယူခြင်းလုပ်ငန်းစဉ်သည် အသေးစိတ်အချက်အလက်များအပါအဝင် နောက်ထပ်ဇာတ်လမ်းအတွက် အလွန်အရေးကြီးသည် - မြန်ဆန်သော Intel P4500 drive ကိုအသုံးပြုကာ NFS ကိုအသုံးပြု၍ ZFS ကိုအသုံးပြုခြင်းဖြစ်နိုင်သည်။

အရန်ဇာတ်လမ်း

hypervisor node တစ်ခုစီတွင် ကျွန်ုပ်တို့တွင် 8 GB အရွယ်အစားရှိသော SWAP partition ငယ်တစ်ခုရှိပြီး၊ hypervisor node ကို ကိုယ်တိုင်အသုံးပြု၍ "ထုတ်" DD ရည်ညွှန်းပုံမှ ဆာဗာများရှိ စနစ်အသံအတိုးအကျယ်အတွက်၊ ကျွန်ုပ်တို့သည် LSI သို့မဟုတ် HP ဟာ့ဒ်ဝဲထိန်းချုပ်သူတွင် 2xSATA SSD RAID1 သို့မဟုတ် 2xSAS HDD RAID1 ကို အသုံးပြုပါသည်။ ယေဘုယျအားဖြင့်၊ ကျွန်ုပ်တို့သည် SWAP မှလွဲ၍ ကျွန်ုပ်တို့၏စနစ်အသံအတိုးအကျယ်ကို "ဖတ်ရန်သာ" မုဒ်တွင် လုပ်ဆောင်နေသောကြောင့် ကျွန်ုပ်တို့သည် အတွင်း၌ရှိသောအရာအားလုံးကို ဂရုမစိုက်ပါ။ ကျွန်ုပ်တို့တွင် ဆာဗာတွင် RAM များစွာရှိပြီး ၎င်းသည် 30-40% အခမဲ့ဖြစ်သောကြောင့်၊ ကျွန်ုပ်တို့သည် SWAP အကြောင်း မစဉ်းစားပါ။

Backup လုပ်ငန်းစဉ်. ဤတာဝန်သည် ဤကဲ့သို့ ဖြစ်သည်-

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

အာရုံစိုက်ပါ ionice -c3တကယ်တော့၊ ဤအရာသည် NVMe စက်များအတွက် လုံးဝ အသုံးမဝင်ပါ၊ ၎င်းတို့အတွက် IO အချိန်ဇယားကို အောက်ပါအတိုင်း သတ်မှတ်ထားသောကြောင့်၊

cat /sys/block/nvme0n1/queue/scheduler
[none] 

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

အလံကို သတိထားပါ။ iflag=direct အတွက် DD. စာဖတ်သည့်အခါ မလိုအပ်သော IO buffers များကို အစားထိုးခြင်းမှ ရှောင်ရှားရန် ကြားခံကက်ရှ်ကို ကျော်ဖြတ်ကာ တိုက်ရိုက် IO ကို အသုံးပြုပါသည်။ သို့သော်၊ oflag=direct ကျွန်ုပ်တို့ ၎င်းကိုအသုံးပြုသည့်အခါ ZFS စွမ်းဆောင်ရည်ပြဿနာများ ကြုံတွေ့ခဲ့ရသောကြောင့် မဟုတ်ပါ။

ကျွန်ုပ်တို့သည် ဤအစီအစဉ်ကို ပြဿနာမရှိဘဲ နှစ်အတော်ကြာအောင် အောင်မြင်စွာ အသုံးပြုနေပါသည်။

ပြီးမှ စတယ်။... ဆုံမှတ်များထဲမှ တစ်ခုကို အရန်သိမ်းတော့မည် မဟုတ်ကြောင်း ကျွန်ုပ်တို့ တွေ့ရှိခဲ့ပြီး၊ ယခင်တစ်ခုသည် အလွန်ကြီးမားသော IOWAIT 50% ဖြင့် လုပ်ဆောင်နေပါသည်။ ကူးယူခြင်း မဖြစ်ပေါ်ရခြင်းကို နားလည်ရန် ကြိုးစားသောအခါ၊ ကျွန်ုပ်တို့သည် အောက်ပါဖြစ်စဉ်ကို ကြုံတွေ့ခဲ့ရသည်-

Volume group "images" not found

ကျွန်ုပ်တို့သည် "Intel P4500 အတွက်အဆုံးသတ်ရောက်ပြီ" ဟုစဥ်းစားလာသော်လည်း၊ drive ကိုအစားထိုးရန်အတွက်ဆာဗာကိုမပိတ်မီ၊ အရန်ကူးယူရန် လိုအပ်နေသေးသည်။ ကျွန်ုပ်တို့သည် LVM2 အရန်သိမ်းဆည်းမှုမှ မက်တာဒေတာကို ပြန်ယူခြင်းဖြင့် LVM2 ကို ပြင်ဆင်ခဲ့သည်-

vgcfgrestore images

ကျွန်ုပ်တို့သည် အရန်ကူးယူထားပြီး ဤဆီဆေးပန်းချီကားကို တွေ့လိုက်ရသည်-

တစ်ဖန် ကျွန်ုပ်တို့ အလွန်ဝမ်းနည်းခဲ့ရသည် - VPS များအားလုံး ဒုက္ခရောက်မည်ဖြစ်သောကြောင့် ကျွန်ုပ်တို့လည်း ဤကဲ့သို့ မနေနိုင်သည်မှာ ထင်ရှားပါသည်။ ဖြစ်ပျက်ခဲ့တာကို ရှင်းရှင်းလင်းလင်း မသိရသေးပါဘူး။ iostat သနားစရာ IOPS နှင့် အမြင့်ဆုံး IOWAIT ကို ပြသခဲ့သည်။ "NVMe ကို အစားထိုးကြရအောင်" မှလွဲ၍ အခြား အကြံဥာဏ်များ မရှိသော်လည်း အချိန်မီ ထိုးထွင်းသိမြင်မှုတစ်ခု ဖြစ်ပေါ်ခဲ့သည်။

အခြေအနေကို တစ်ဆင့်ပြီးတစ်ဆင့် လေ့လာသုံးသပ်ခြင်း။

သမိုင်းမဂ္ဂဇင်း. အစောပိုင်းရက်အနည်းငယ်က၊ ဤဆာဗာတွင် 128 GB RAM ပါသော VPS ကြီးကိုဖန်တီးရန်လိုအပ်သည်။ မမ်မိုရီအလုံအလောက်ရှိပုံရသော်လည်း ဘေးကင်းစေရန်အတွက်၊ swap partition အတွက် နောက်ထပ် 32 GB ကို ခွဲဝေပေးခဲ့ပါသည်။ VPS ကို ဖန်တီးပြီး ၎င်း၏လုပ်ငန်းတာဝန်ကို အောင်မြင်စွာ ပြီးမြောက်ခဲ့ပြီး အဖြစ်အပျက်ကို မေ့သွားသော်လည်း SWAP အပိုင်းသည် ကျန်ရှိနေခဲ့သည်။

ဖွဲ့စည်းမှုအင်္ဂါရပ်များ. cloud ဆာဗာများအားလုံးအတွက် ကန့်သတ်ချက် vm.swappiness ပုံသေသတ်မှတ်ထားသည်။ 60. SAS HDD RAID1 တွင် SWAP ကိုဖန်တီးခဲ့သည်။

ဘာတွေ ဖြစ်ခဲ့သလဲ (အယ်ဒီတာများ အဆိုအရ). အရန်သိမ်းသောအခါ DD NFS သို့မရေးမီ RAM buffers တွင်ထည့်ထားသော write data အများအပြားကိုထုတ်လုပ်ခဲ့သည်။ စနစ်အခြေခံ၊ မူဝါဒဖြင့် လမ်းညွှန်သည်။ swappiness၊ နှေးကွေးသော HDD RAID1 အသံအတိုးအကျယ်ပေါ်ရှိ VPS မမ်မိုရီ၏ စာမျက်နှာအများအပြားကို swap ဧရိယာသို့ ရွှေ့နေပါသည်။ ယင်းကြောင့် IOWAIT သည် အလွန်ပြင်းထန်စွာ ကြီးထွားလာခဲ့သော်လည်း IO NVMe ကြောင့်မဟုတ်ဘဲ IO HDD RAID1 ကြောင့်ဖြစ်သည်။

ပြဿနာကို ဘယ်လိုဖြေရှင်းခဲ့လဲ။. 32GB လဲလှယ်မှုအပိုင်းကို ပိတ်ထားသည်။ ၎င်းသည် 16 နာရီကြာမြင့်သည်၊ မည်သို့နှင့် SWAP သည် ဤမျှနှေးကွေးစွာ ပိတ်သွားသည်ကို သင် သီးခြားဖတ်ရှုနိုင်ပါသည်။ ဆက်တင်များကို ပြောင်းလဲထားသည်။ swappiness နှင့်ညီမျှသောတန်ဖိုးတစ်ခုသို့ 5 တိမ်တိုက်တစ်ခုလုံး။

ဒါက ဘယ်လိုမှမဖြစ်နိုင်တာလဲ။. ပထမဦးစွာ၊ SWAP သည် SSD RAID သို့မဟုတ် NVMe စက်ပစ္စည်းတွင်ရှိနေပါက၊ ဒုတိယအနေဖြင့် NVMe စက်ပစ္စည်းမရှိပါက၊ သို့သော်ထိုကဲ့သို့သောဒေတာပမာဏကိုထုတ်လုပ်ပေးမည်မဟုတ်သည့်နှေးကွေးသောစက်ပစ္စည်းသည် - အံမခန်းဖြစ်ပြီး NVMe သည် မြန်ဆန်လွန်းသောကြောင့် ပြဿနာဖြစ်လာသည်။

ထို့နောက်တွင်၊ အရာအားလုံးသည် ယခင်အတိုင်းဖြစ်သည် - IOWAIT သုညဖြင့်စတင်ခဲ့သည်။

source: www.habr.com