پدې مقاله کې ، زه به د داسې وضعیت په اړه وغږیږم چې پدې وروستیو کې زموږ د VPS کلاوډ کې د یو سرور سره پیښ شوی ، کوم چې ما د څو ساعتونو لپاره سټمپ پریښود. زه د شاوخوا 15 کلونو راهیسې د لینکس سرورونو تنظیم او حل کوم ، مګر دا قضیه زما په عمل کې هیڅ مناسب نه ده - ما ډیری غلط انګیرنې وکړې او مخکې لدې چې زه وکولی شم د ستونزې لامل په سمه توګه وټاکم او حل یې کړم یو څه نا امید شوم. .
لومړى
موږ د منځنۍ اندازې کلاوډ چلوو، کوم چې موږ په معیاري سرورونو کې د لاندې ترتیب سره جوړوو - 32 کور، 256 GB رام او د 4500TB PCI-E Intel P4 NVMe ډرایو. موږ واقعیا دا ترتیب خوښوو ځکه چې دا د VM مثال ډول کچې کې د سم محدودیت چمتو کولو سره د IO سر په اړه اندیښنې ته اړتیا له مینځه وړي. ځکه چې NVMe Intel اغیزمن فعالیت لري، موږ کولی شو په ورته وخت کې د صفر IOWAIT سره بیک اپ سرور ته ماشینونو ته د IOPS بشپړ چمتو کول او بیک اپ ذخیره چمتو کړو.
موږ یو له هغه پخوانیو مومنانو څخه یو چې د VM حجمونو ذخیره کولو لپاره هایپر کنورګډ SDN او نور سجیلا ، فیشني ، ځوان شیان نه کاروو ، په دې باور دي چې سیسټم څومره ساده دی ، د "اصلي گرو" په شرایطو کې د ستونزو حل کول اسانه دي. غرونو ته.» د پایلې په توګه، موږ د VM حجمونه د QCOW2 بڼه کې په XFS یا EXT4 کې ذخیره کوو، کوم چې د LVM2 په سر کې ځای پرځای شوي.
موږ مجبور یو چې د QCOW2 د هغه محصول لخوا وکاروو چې موږ یې د آرکیسټریشن لپاره کاروو - Apache CloudStack.
د بیک اپ ترسره کولو لپاره ، موږ د حجم بشپړ عکس د LVM2 سنیپ شاټ په توګه اخلو (هو ، موږ پوهیږو چې د LVM2 سنیپ شاټ ورو دي ، مګر د Intel P4500 دلته هم زموږ سره مرسته کوي). موږ یې کوو lvmcreate -s .. او په مرسته dd موږ د بیک اپ کاپي د ZFS ذخیره کولو سره ریموټ سرور ته لیږو. دلته موږ لاهم یو څه پرمختللی یو - په هرصورت ، ZFS کولی شي ډیټا په کمپریس شوي شکل کې زیرمه کړي ، او موږ کولی شو ژر تر ژره دا په کارولو سره بحال کړو DD یا د انفرادي VM حجمونه په کارولو سره ترلاسه کړئ mount -o loop ....
تاسو کولی شئ، البته، د LVM2 حجم بشپړ عکس نه لرې کړئ، مګر د فایل سیسټم نصب کړئ
ROاو پخپله د QCOW2 عکسونه کاپي کړئ ، په هرصورت ، موږ د دې حقیقت سره مخ شو چې XFS له دې څخه خراب شو ، او سمدستي نه ، مګر په غیر متوقع ډول. موږ واقعیا دا نه خوښوو کله چې هایپروایزر د اونۍ په پای کې ، د شپې یا رخصتیو کې ناڅاپه د غلطیو له امله "چپ" کوربه کوي چې روښانه نده چې کله به پیښ شي. له همدې امله، د XFS لپاره موږ د سنیپ شاټ نصب کول نه کارووROد حجمونو ایستلو لپاره، موږ په ساده ډول د LVM2 ټول حجم کاپي کوو.
د بیک اپ سرور ته د بیک اپ سرعت زموږ په قضیه کې د بیک اپ سرور فعالیت لخوا ټاکل کیږي ، کوم چې د نه منلو وړ ډیټا لپاره شاوخوا 600-800 MB / s دی؛ یو بل محدودونکی د 10Gbit / s چینل دی چې ورسره بیک اپ سرور وصل دی. کلستر ته.
پدې حالت کې ، د 8 هایپروایسر سرورونو بیک اپ کاپي په ورته وخت کې یو بیک اپ سرور ته اپلوډ کیږي. په دې توګه، د بیک اپ سرور ډیسک او د شبکې فرعي سیسټمونه، ورو وي، د هایپروایسر کوربه ډیسک فرعي سیسټمونو ته اجازه نه ورکوي چې ډیر بار کړي، ځکه چې دوی په ساده ډول د پروسس کولو توان نلري، ووایه، 8 GB/sec، کوم چې د هایپروایزر کوربه کولی شي په اسانۍ سره. توليدول، جوړول.
د پورته کاپي کولو پروسه د نورو کیسې لپاره خورا مهم دي ، پشمول د توضیحاتو - د ګړندي Intel P4500 ډرایو کارول ، د NFS کارول او شاید د ZFS په کارولو سره.
د بیک اپ کیسه
په هر هایپروایزر نوډ کې موږ د 8 GB اندازې کوچنۍ SWAP برخه لرو، او موږ پخپله د هایپروایزر نوډ په کارولو سره "رول آوټ" کوو. DD د حوالې عکس څخه. په سرورونو کې د سیسټم حجم لپاره، موږ په LSI یا HP هارډویر کنټرولر کې 2xSATA SSD RAID1 یا 2xSAS HDD RAID1 کاروو. په عموم کې، موږ هیڅ پروا نه کوو چې دننه څه دي، ځکه چې زموږ د سیسټم حجم په "نږدې یوازې لوستل" حالت کې کار کوي، پرته له SWAP. او له هغه ځایه چې موږ په سرور کې ډیری رام لرو او دا 30-40٪ وړیا دی، موږ د SWAP په اړه فکر نه کوو.
د بیک اپ پروسه. دا دنده داسې ښکاري:
#!/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 سره یو شمیر میراثي نوډونه لرو، د دوی لپاره دا اړونده ده، نو دوی حرکت کوي لکه څنګه. په ټوله کې، دا یوازې د کوډ یوه زړه پورې ټوټه ده چې بې ګټې تشریح کوي ionice د داسې یو ترتیب په صورت کې.
بیرغ ته پام وکړئ iflag=direct لپاره DD. موږ د بفر کیچ په واسطه مستقیم IO کاروو ترڅو د لوستلو پرمهال د IO بفرونو غیر ضروري ځای په ځای کولو مخه ونیسو. په هرصورت، oflag=direct موږ نه ځکه چې موږ د دې کارولو پرمهال د ZFS فعالیت مسلو سره مخ شوي یو.
موږ دا سکیم د څو کلونو لپاره پرته له ستونزو څخه په بریالیتوب سره کاروو.
او بیا یې پیل وکړ... موږ وموندله چې د نوډونو څخه یو یې نور ملاتړ شوی نه و، او پخوانی د 50٪ IOWAIT سره روان و. کله چې هڅه وکړو پوه شو چې ولې کاپي نه کیږي، موږ د لاندې پدیدې سره مخ شو:
Volume group "images" not foundموږ د "Intel P4500 پای ته رسیدلی" په اړه فکر کول پیل کړل ، په هرصورت ، مخکې لدې چې د ډرایو ځای په ځای کولو لپاره سرور بند کړئ ، دا لاهم اړین و چې بیک اپ ترسره کړئ. موږ د LVM2 بیک اپ څخه د میټاډاټا په بحالولو سره LVM2 فکس کړ:
vgcfgrestore imagesموږ یو بیک اپ پیل کړ او دا د تیلو انځور مو ولیدل:
یوځل بیا موږ ډیر غمجن وو - دا روښانه وه چې موږ نشو کولی داسې ژوند وکړو، ځکه چې ټول VPS به رنځ وي، پدې معنی چې موږ به هم رنځ ولرو. څه پیښ شوي په بشپړ ډول ناڅرګند دي - iostat د رحم وړ IOPS او لوړ IOWAIT وښودل. د "راځئ چې د NVMe ځای په ځای کړو" پرته بل هیڅ نظر نه و ، مګر یو بصیرت یوازې په وخت کې رامینځته شو.
ګام په ګام د وضعیت تحلیل
تاریخي مجله. څو ورځې دمخه ، پدې سرور کې دا اړینه وه چې د 128 GB رام سره لوی VPS رامینځته کړي. داسې بریښي چې کافي حافظه شتون ولري ، مګر د خوندي اړخ لپاره ، موږ د سویپ برخې لپاره بل 32 GB تخصیص کړ. VPS جوړ شو، په بریالیتوب سره خپله دنده بشپړه کړه او پیښه هیره شوه، مګر د SWAP ویش پاتې شو.
د ترتیب کولو ځانګړتیاوې. د ټولو کلاوډ سرورونو لپاره پیرامیټر vm.swappiness ډیفالټ ته ټاکل شوی و 60. او SWAP په SAS HDD RAID1 کې رامینځته شوی.
څه پیښ شوي (د مدیرانو په وینا). کله چې بیک اپ DD د لیکلو ډیری ډاټا تولید کړي، کوم چې NFS ته د لیکلو دمخه په RAM بفرونو کې ځای پرځای شوي. د سیسټم اصلي، د پالیسۍ لخوا الرښوونه swappiness، د VPS حافظې ډیری پاڼې د سویپ ساحې ته حرکت کوي ، کوم چې په ورو HDD RAID1 حجم کې موقعیت درلود. دا د دې لامل شوی چې IOWAIT خورا قوي وده وکړي ، مګر د IO NVMe له امله نه ، مګر د IO HDD RAID1 له امله.
ستونزه څنګه حل شوه. د 32GB سویپ برخه غیر فعاله شوې وه. دې 16 ساعته وخت واخیست؛ تاسو کولی شئ په جلا توګه ولولئ چې څنګه او ولې SWAP دومره ورو ورو بندیږي. ترتیبات بدل شوي دي swappiness سره مساوي ارزښت ته 5 ټول په ورېځ کې
دا څنګه کیدای نشي؟. لومړی ، که SWAP په SSD RAID یا NVMe وسیلې کې و ، او دوهم ، که چیرې د NVMe وسیله نه وي ، مګر یو ورو وسیله چې دومره ډیټا به تولید نکړي - په زړه پورې ، ستونزه رامینځته شوې ځکه چې NVMe خورا ګړندی دی.
له هغې وروسته، هرڅه د پخوا په څیر کار پیل کړ - د صفر IOWAIT سره.
سرچینه: www.habr.com