بہت ساری مفت RAM، NVMe Intel P4500 اور سب کچھ انتہائی سست ہے - ایک سویپ پارٹیشن کے ناکام اضافے کی کہانی

اس مضمون میں، میں ایک ایسی صورت حال کے بارے میں بات کروں گا جو حال ہی میں ہمارے VPS کلاؤڈ میں سرورز میں سے ایک کے ساتھ پیش آیا، جس نے مجھے کئی گھنٹوں تک اسٹمپ کر دیا۔ میں تقریباً 15 سالوں سے لینکس سرورز کو ترتیب دے رہا ہوں اور اس کا ازالہ کر رہا ہوں، لیکن یہ معاملہ میرے پریکٹس میں بالکل بھی فٹ نہیں آتا ہے - میں نے کئی غلط مفروضے بنائے اور اس سے پہلے کہ میں مسئلے کی صحیح وجہ کا تعین کر سکوں اور اسے حل کر سکوں، میں تھوڑا مایوس ہو گیا۔ .

پریامبل

ہم درمیانے درجے کے کلاؤڈ کو چلاتے ہیں، جسے ہم درج ذیل کنفیگریشن کے ساتھ معیاری سرورز پر بناتے ہیں - 32 کور، 256 جی بی ریم اور ایک 4500TB PCI-E Intel P4 NVMe ڈرائیو۔ ہمیں واقعی یہ ترتیب پسند ہے کیونکہ یہ VM مثال کی قسم کی سطح پر صحیح پابندی فراہم کرکے IO اوور ہیڈ کے بارے میں فکر کرنے کی ضرورت کو ختم کرتا ہے۔ کیونکہ NVMe انٹیل P4500 متاثر کن کارکردگی ہے، ہم بیک وقت مشینوں کو مکمل IOPS پروویژننگ اور بیک اپ سٹوریج صفر IOWAIT والے بیک اپ سرور کو فراہم کر سکتے ہیں۔

ہم ان پرانے ماننے والوں میں سے ایک ہیں جو 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 جی بی/سیکنڈ پر کارروائی کرنے کے قابل نہیں ہیں، جسے ہائپر وائزر میزبان آسانی سے کر سکتے ہیں۔ پیداوار

مندرجہ بالا کاپی کرنے کا عمل مزید کہانی کے لیے بہت اہم ہے، بشمول تفصیلات - تیز رفتار Intel P4500 ڈرائیو کا استعمال کرتے ہوئے، NFS کا استعمال کرتے ہوئے اور شاید ZFS کا استعمال کرتے ہوئے۔

بیک اپ کہانی

ہر ہائپر وائزر نوڈ پر ہمارے پاس 8 جی بی سائز کا ایک چھوٹا SWAP پارٹیشن ہے، اور ہم خود ہی ہائپر وائزر نوڈ کا استعمال کرتے ہوئے "رول آؤٹ" کرتے ہیں۔ DD حوالہ تصویر سے سرورز پر سسٹم والیوم کے لیے، ہم LSI یا HP ہارڈویئر کنٹرولر پر 2xSATA SSD RAID1 یا 2xSAS HDD RAID1 استعمال کرتے ہیں۔ عام طور پر، ہمیں اس کی کوئی پرواہ نہیں ہے کہ اندر کیا ہے، کیونکہ ہمارے سسٹم کا حجم "تقریباً صرف پڑھنے والے" موڈ میں کام کرتا ہے، سوائے SWAP کے۔ اور چونکہ ہمارے پاس سرور پر کافی RAM ہے اور یہ 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 کے ساتھ کئی لیگیسی نوڈس ہیں، ان کے لیے یہ متعلقہ ہے، اس لیے وہ آگے بڑھ رہے ہیں۔ AS IS. مجموعی طور پر، یہ کوڈ کا صرف ایک دلچسپ ٹکڑا ہے جو فضولیت کی وضاحت کرتا ہے۔ 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 جی بی ریم کے ساتھ ایک بڑا وی پی ایس بنانا ضروری تھا۔ ایسا لگتا تھا کہ کافی میموری موجود ہے، لیکن محفوظ ہونے کے لیے، ہم نے سویپ پارٹیشن کے لیے ایک اور 32 جی بی مختص کیا۔ 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