تمام گهڻي مفت ريم، NVMe Intel P4500 ۽ هر شيءِ انتهائي سست آهي - هڪ ادل بدلي ورهاڱي جي ناڪامي اضافو جي ڪهاڻي

هن آرٽيڪل ۾، مان هڪ اهڙي صورتحال بابت ڳالهائيندس جيڪو تازو ٿي چڪو آهي اسان جي VPS ڪلائوڊ ۾ هڪ سرور سان، جنهن مون کي ڪيترن ئي ڪلاڪن تائين اسٽمپ ڪري ڇڏيو. مان اٽڪل 15 سالن کان لينڪس سرورز کي ترتيب ڏيڻ ۽ ان کي حل ڪري رهيو آهيان، پر اهو معاملو منهنجي عمل ۾ بلڪل به نٿو اچي - مون ڪيترائي غلط مفروضا ڪيا ۽ ٿورو مايوس ٿي ويو آهيان ان کان اڳ جو آئون مسئلي جي صحيح سبب کي طئي ڪرڻ ۽ ان کي حل ڪرڻ جي قابل ٿي سگهان. .

ٿي سگھي ٿو

اسان هلون ٿا هڪ وچولي-سائيز ڪلائوڊ، جنهن کي اسين معياري سرور تي ٺاهيندا آهيون هيٺين ترتيب سان - 32 ڪور، 256 GB ريم ۽ هڪ 4500TB PCI-E Intel P4 NVMe ڊرائيو. اسان واقعي هن تشڪيل کي پسند ڪندا آهيون ڇاڪاڻ ته اها VM مثال جي قسم جي سطح تي صحيح پابندي فراهم ڪندي IO اوور هيڊ بابت پريشان ٿيڻ جي ضرورت کي ختم ڪري ٿي. ڇو ته NVMe Intel P4500 شاندار ڪارڪردگي آهي، اسان هڪ ئي وقت مڪمل IOPS فراهم ڪري سگهون ٿا مشينن کي فراهم ڪرڻ ۽ بيڪ اپ اسٽوريج کي صفر IOWAIT سان بيڪ اپ سرور ڏانهن.

اسان انهن پراڻن مومنن مان هڪ آهيون جيڪي هائپر ڪنورجڊ SDN ۽ ٻيون سجيل، فيشنيبل، نوجوان شيون استعمال نٿا ڪن VM حجمن کي ذخيرو ڪرڻ لاءِ، يقين رکون ٿا ته سسٽم جيترو سولو هوندو، اوترو ئي آسان هوندو ان کي حل ڪرڻ جي حالتن ۾ ”مکيه گرو ٿي ويو آهي. جبلن ڏانهن." نتيجي طور، اسان 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

اسان سوچڻ شروع ڪيو "انٽيل P4500 لاءِ آخر اچي ويو آهي"، جڏهن ته، ڊرائيو کي تبديل ڪرڻ لاءِ سرور کي بند ڪرڻ کان اڳ، اهو اڃا به ضروري هو ته هڪ بيڪ اپ انجام ڏيو. اسان هڪ LVM2 بيڪ اپ مان ميٽا ڊيٽا بحال ڪندي LVM2 کي مقرر ڪيو:

vgcfgrestore images

اسان هڪ بيڪ اپ شروع ڪيو ۽ هن آئل پينٽنگ کي ڏٺو:

ٻيهر اسان ڏاڍا اداس هئاسين - اهو واضح هو ته اسان هن وانگر جيئرو نه رهي سگهون ٿا، ڇو ته سڀئي وي پي ايس متاثر ٿيندا، جنهن جو مطلب آهي ته اسان کي پڻ ڏک ٿيندو. ڇا ٿيو مڪمل طور تي واضح ناهي - iostat ڏٺل IOPS ۽ اعلي IOWAIT. "اچو ته NVMe کي تبديل ڪريون" کان سواءِ ٻيو ڪو به خيال نه هو، پر هڪ بصيرت صرف وقت ۾ ٿي.

قدم بہ قدم صورتحال جو تجزيو

تاريخي رسالو. ڪجهه ڏينهن اڳ، هن سرور تي 128 GB ريم سان هڪ وڏو VPS ٺاهڻ ضروري هو. اتي ڪافي يادگيري ٿي لڳي، پر محفوظ پاسي تي، اسان هڪ ٻيو 32 GB مختص ڪيو سوپ ورهاڱي لاء. VPS ٺاهي وئي، ڪاميابيء سان پنهنجو ڪم مڪمل ڪيو ۽ واقعو وساري ويو، پر SWAP ورهاڱي رهي.

ڪنفيگريشن جون خاصيتون. سڀني ڪلائوڊ سرورز لاءِ پيٽرول vm.swappiness ڊفالٽ تي مقرر ڪيو ويو 60. ۽ SWAP SAS HDD RAID1 تي ٺاهي وئي.

ڇا ٿيو (ايڊيٽرن جي مطابق). جڏهن بيڪ اپ DD تمام گهڻي لکڻ واري ڊيٽا پيدا ڪئي، جيڪا NFS ڏانهن لکڻ کان اڳ رام بفرز ۾ رکيل هئي. سسٽم جو بنيادي، پاليسي طرفان هدايت ڪئي وئي آهي swappiness، وي پي ايس ميموري جي ڪيترن ئي صفحن کي ادل واري علائقي ڏانهن منتقل ڪري رهيو هو، جيڪو سست HDD RAID1 حجم تي واقع هو. انهي جي ڪري IOWAIT تمام گهڻو وڌي رهيو آهي، پر IO NVMe جي ڪري نه، پر IO HDD RAID1 جي ڪري.

ڪيئن مسئلو حل ڪيو ويو. 32GB سوپ ورهاڱي کي بند ڪيو ويو. ان ۾ 16 ڪلاڪ لڳا؛ توهان الڳ الڳ پڙهي سگهو ٿا ته ڪيئن ۽ ڇو SWAP ايترو سست بند ٿئي ٿو. سيٽنگون تبديل ڪيون ويون آهن swappiness جي برابر قدر تائين 5 سڀ بادل مٿان.

ائين ڪيئن نه ٿي سگهيو؟. پهرين، جيڪڏهن SWAP هڪ SSD RAID يا NVMe ڊوائيس تي هئا، ۽ ٻيو، جيڪڏهن ڪو NVMe ڊوائيس نه هو، پر هڪ سست ڊيوائس جيڪو ڊيٽا جي اهڙي مقدار پيدا نه ڪندو - ستم ظريفي طور تي، مسئلو اهو ٿيو ڇو ته NVMe تمام تيز آهي.

ان کان پوء، هر شيء اڳ وانگر ڪم ڪرڻ شروع ڪيو - صفر IOWAIT سان.

جو ذريعو: www.habr.com