پرو ہوسٹر > بلاگ > انتظامیہ > LVM اور Matryoshka میں کیا مشترک ہے؟

LVM اور Matryoshka میں کیا مشترک ہے؟

دن اچھا ہو.
میں کمیونٹی کے ساتھ md RAID + LVM کا استعمال کرتے ہوئے KVM کے لیے ڈیٹا اسٹوریج سسٹم بنانے کا اپنا عملی تجربہ شیئر کرنا چاہتا ہوں۔

پروگرام میں شامل ہوں گے:

  • NVMe SSD سے md RAID 1 کی تعمیر۔
  • SATA SSD اور باقاعدہ ڈرائیوز سے md RAID 6 کو جمع کرنا۔
  • SSD RAID 1/6 پر TRIM/DSCARD آپریشن کی خصوصیات۔
  • ڈسک کے مشترکہ سیٹ پر بوٹ ایبل md RAID 1/6 سرنی بنانا۔
  • NVMe RAID 1 پر سسٹم کو انسٹال کرنا جب BIOS میں NVMe سپورٹ نہ ہو۔
  • LVM کیشے اور LVM پتلا کا استعمال۔
  • BTRFS سنیپ شاٹس کا استعمال کرتے ہوئے اور بیک اپ کے لیے بھیجیں/ وصول کریں۔
  • BTRFS طرز کے بیک اپ کے لیے LVM پتلے اسنیپ شاٹس اور thin_delta کا استعمال۔

اگر آپ دلچسپی رکھتے ہیں تو براہ کرم بلی دیکھیں۔

بیان۔

مصنف اس مضمون سے مواد/مثالیں/کوڈ/ٹپس/ڈیٹا استعمال کرنے یا استعمال نہ کرنے کے نتائج کی کوئی ذمہ داری برداشت نہیں کرتا۔ اس مواد کو کسی بھی طرح سے پڑھ کر یا استعمال کر کے، آپ ان اعمال کے تمام نتائج کی ذمہ داری قبول کرتے ہیں۔ ممکنہ نتائج میں شامل ہیں:

  • کرکرا تلی ہوئی NVMe SSDs۔
  • ریکارڈنگ کے وسائل کو مکمل طور پر استعمال کیا گیا اور SSD ڈرائیوز کی ناکامی۔
  • تمام ڈرائیوز پر موجود تمام ڈیٹا کا مکمل نقصان، بشمول بیک اپ کاپیاں۔
  • ناقص کمپیوٹر ہارڈ ویئر۔
  • وقت، اعصاب اور پیسہ ضائع کیا۔
  • کوئی اور نتائج جو اوپر درج نہیں ہیں۔

آئرن

دستیاب تھے:

Z2013 چپ سیٹ کے ساتھ تقریباً 87 کا مدر بورڈ، Intel Core i7/Haswell کے ساتھ مکمل۔

  • پروسیسر 4 کور، 8 تھریڈز
  • 32 جی بی ڈی ڈی آر 3 ریم
  • 1 x 16 یا 2 x 8 PCIe 3.0
  • 1 x 4 + 1 x 1 PCIe 2.0
  • 6 x 6 GBps SATA 3 کنیکٹر

SAS اڈاپٹر LSI SAS9211-8I IT/HBA موڈ میں چمکا۔ RAID فعال فرم ویئر کو جان بوجھ کر HBA فرم ویئر سے تبدیل کر دیا گیا ہے:

  1. آپ اس اڈاپٹر کو کسی بھی وقت باہر پھینک سکتے ہیں اور اسے کسی دوسرے سے بدل سکتے ہیں جو آپ کے سامنے آئے۔
  2. TRIM/Discard عام طور پر ڈسکوں پر کام کرتا ہے، کیونکہ... RAID فرم ویئر میں یہ کمانڈز بالکل بھی تعاون یافتہ نہیں ہیں، اور HBA، عام طور پر، اس بات کی پرواہ نہیں کرتا کہ بس پر کون سے کمانڈز منتقل ہوتے ہیں۔

ہارڈ ڈرائیوز - HGST Travelstar 8K7 کے 1000 ٹکڑے جس میں 1 فارم فیکٹر میں 2.5 TB کی گنجائش ہے، جیسا کہ لیپ ٹاپ کے لیے۔ یہ ڈرائیوز پہلے RAID 6 صف میں تھیں۔ نئے نظام میں ان کا بھی استعمال ہوگا۔ مقامی بیک اپ کو ذخیرہ کرنے کے لیے۔

اضافی طور پر شامل کیا گیا:

6 ٹکڑے SATA SSD ماڈل Samsung 860 QVO 2TB۔ ان SSDs کو بڑی مقدار کی ضرورت تھی، SLC کیش کی موجودگی، وشوسنییتا، اور کم قیمت مطلوب تھی۔ ڈسکارڈ/زیرو کے لیے سپورٹ درکار تھا، جسے ڈی ایم ایس جی میں لائن کے ذریعے چیک کیا جاتا ہے۔

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSD ماڈل Samsung SSD 2 EVO 970GB کے 500 ٹکڑے۔

ان SSDs کے لیے، آپ کی ضروریات کے لیے بے ترتیب پڑھنے/لکھنے کی رفتار اور وسائل کی گنجائش اہم ہے۔ ان کے لیے ریڈی ایٹر۔ لازمی طور پر. بالکل۔ بصورت دیگر، پہلے RAID سنکرونائزیشن کے دوران انہیں کرسپی ہونے تک بھونیں۔

StarTech PEX8M2E2 اڈاپٹر 2 x NVMe SSD کے لیے PCIe 3.0 8x سلاٹ میں نصب ہے۔ یہ، ایک بار پھر، صرف ایک HBA ہے، لیکن NVMe کے لیے۔ یہ سستے اڈاپٹر سے مختلف ہے کہ اس میں بلٹ ان PCIe سوئچ کی موجودگی کی وجہ سے اسے مدر بورڈ سے PCIe بفرکیشن سپورٹ کی ضرورت نہیں ہے۔ یہ PCIe کے ساتھ قدیم ترین نظام میں بھی کام کرے گا، چاہے یہ x1 PCIe 1.0 سلاٹ ہی کیوں نہ ہو۔ قدرتی طور پر، مناسب رفتار پر. وہاں کوئی چھاپے نہیں ہیں۔ بورڈ پر کوئی بلٹ ان BIOS نہیں ہے۔ لہذا، آپ کا سسٹم جادوئی طور پر NVMe کے ساتھ بوٹ کرنا نہیں سیکھے گا، اس ڈیوائس کی بدولت NVMe RAID بہت کم ہے۔

یہ جزو مکمل طور پر سسٹم میں صرف ایک مفت 8x PCIe 3.0 کی موجودگی کی وجہ سے تھا، اور، اگر 2 مفت سلاٹ ہیں، تو اسے آسانی سے دو پینی PEX4M2E1 یا اینالاگ سے تبدیل کیا جا سکتا ہے، جسے 600 کی قیمت پر کہیں بھی خریدا جا سکتا ہے۔ روبل

تمام قسم کے ہارڈ ویئر یا بلٹ ان چپ سیٹ/BIOS RAIDs کو مسترد کرنا جان بوجھ کر کیا گیا تھا، تاکہ تمام ڈیٹا کو محفوظ رکھتے ہوئے، SSD/HDD کو چھوڑ کر، پورے سسٹم کو مکمل طور پر تبدیل کرنے کے قابل ہو۔ مثالی طور پر، تاکہ آپ مکمل طور پر نئے/مختلف ہارڈ ویئر پر جاتے وقت انسٹال شدہ آپریٹنگ سسٹم کو بھی محفوظ کر سکیں۔ اہم بات یہ ہے کہ SATA اور PCIe بندرگاہیں ہیں۔ یہ ایک لائیو سی ڈی یا بوٹ ایبل فلیش ڈرائیو کی طرح ہے، صرف بہت تیز اور تھوڑا بڑا۔

ہنسی مذاقدوسری صورت میں، آپ جانتے ہیں کہ کیا ہوتا ہے - بعض اوقات آپ کو فوری طور پر لے جانے کے لیے پوری صف کو اپنے ساتھ لے جانے کی ضرورت ہوتی ہے۔ لیکن میں ڈیٹا کھونا نہیں چاہتا۔ ایسا کرنے کے لیے، تمام مذکورہ میڈیا معیاری کیس کے 5.25 خلیجوں میں آسانی سے سلائیڈز پر واقع ہیں۔

ٹھیک ہے، اور، یقیناً، لینکس میں ایس ایس ڈی کیشنگ کے مختلف طریقوں کے ساتھ تجربہ کرنے کے لیے۔

ہارڈ ویئر کے چھاپے بورنگ ہیں۔ اس کو چلاؤ. یہ یا تو کام کرتا ہے یا نہیں کرتا۔ اور mdadm کے ساتھ ہمیشہ آپشنز ہوتے ہیں۔

نرم

اس سے پہلے، Debian 8 Jessie کو ہارڈ ویئر پر انسٹال کیا گیا تھا، جو EOL کے قریب ہے۔ RAID 6 کو LVM کے ساتھ جوڑ بنانے والے مذکورہ HDDs سے جمع کیا گیا تھا۔ اس نے ورچوئل مشینیں kvm/libvirt میں چلائیں۔

کیونکہ مصنف کے پاس پورٹیبل بوٹ ایبل SATA/NVMe فلیش ڈرائیوز بنانے کا مناسب تجربہ ہے، اور ساتھ ہی، معمول کے مطابق آپٹ ٹیمپلیٹ کو نہ توڑنے کے لیے، Ubuntu 18.04 کو ٹارگٹ سسٹم کے طور پر منتخب کیا گیا تھا، جو پہلے ہی کافی حد تک مستحکم ہوچکا ہے، لیکن اس کے پاس ابھی بھی 3 سال باقی ہیں۔ مستقبل میں حمایت.

مذکورہ سسٹم میں وہ تمام ہارڈ ویئر ڈرائیورز شامل ہیں جن کی ہمیں باکس سے باہر ضرورت ہے۔ ہمیں کسی تھرڈ پارٹی سافٹ ویئر یا ڈرائیور کی ضرورت نہیں ہے۔

تنصیب کی تیاری

سسٹم کو انسٹال کرنے کے لیے ہمیں Ubuntu ڈیسک ٹاپ امیج کی ضرورت ہے۔ سرور سسٹم میں ایک قسم کا زبردست انسٹالر ہوتا ہے، جو حد سے زیادہ آزادی کو ظاہر کرتا ہے جسے UEFI سسٹم پارٹیشن کو کسی ایک ڈسک پر ہلا کر تمام خوبصورتی کو خراب کر کے غیر فعال نہیں کیا جا سکتا۔ اس کے مطابق، یہ صرف UEFI وضع میں نصب ہے۔ کوئی آپشن پیش نہیں کرتا۔

ہم اس سے خوش نہیں ہیں۔

کیوں؟بدقسمتی سے، UEFI بوٹ بوٹ سافٹ ویئر RAID کے ساتھ انتہائی ناقص مطابقت رکھتا ہے، کیونکہ... کوئی بھی ہمیں UEFI ESP پارٹیشن کے لیے تحفظات پیش نہیں کرتا ہے۔ انٹرنیٹ پر ایسی ترکیبیں موجود ہیں جو USB پورٹ میں ESP پارٹیشن کو فلیش ڈرائیو پر رکھنے کی تجویز کرتی ہیں، لیکن یہ ناکامی کا ایک نقطہ ہے۔ میٹا ڈیٹا ورژن 1 کے ساتھ سافٹ ویئر mdadm RAID 0.9 استعمال کرنے کی ترکیبیں ہیں جو UEFI BIOS کو اس پارٹیشن کو دیکھنے سے نہیں روکتی ہیں، لیکن یہ اس خوشگوار لمحے تک زندہ رہتی ہے جب BIOS یا کوئی اور ہارڈویئر OS ESP کو کچھ لکھتا ہے اور اسے دوسرے کے ساتھ ہم آہنگ کرنا بھول جاتا ہے۔ آئینہ

اس کے علاوہ، UEFI بوٹ NVRAM پر منحصر ہے، جو ڈسک کے ساتھ نئے سسٹم میں نہیں جائے گا، کیونکہ مدر بورڈ کا حصہ ہے۔

لہذا، ہم ایک نئے پہیے کو دوبارہ نہیں بنائیں گے۔ ہمارے پاس پہلے سے ہی ایک ریڈی میڈ، ٹائم ٹیسٹ شدہ دادا کی بائیک ہے، جسے اب Legacy/BIOS بوٹ کہا جاتا ہے، UEFI سے ہم آہنگ سسٹمز پر CSM کا قابل فخر نام ہے۔ ہم اسے شیلف سے اتاریں گے، اسے چکنا کریں گے، ٹائروں کو پمپ کریں گے اور گیلے کپڑے سے صاف کریں گے۔

اوبنٹو کا ڈیسک ٹاپ ورژن بھی لیگیسی بوٹ لوڈر کے ساتھ مناسب طریقے سے انسٹال نہیں کیا جا سکتا، لیکن یہاں، جیسا کہ وہ کہتے ہیں، کم از کم اختیارات موجود ہیں۔

اور اس طرح، ہم ہارڈ ویئر کو جمع کرتے ہیں اور سسٹم کو Ubuntu Live بوٹ ایبل فلیش ڈرائیو سے لوڈ کرتے ہیں۔ ہمیں پیکجز ڈاؤن لوڈ کرنے کی ضرورت ہوگی، لہذا ہم آپ کے لیے کام کرنے والا نیٹ ورک ترتیب دیں گے۔ اگر یہ کام نہیں کرتا ہے، تو آپ ضروری پیکجوں کو فلیش ڈرائیو پر پہلے سے لوڈ کر سکتے ہیں۔

ہم ڈیسک ٹاپ ماحول میں جاتے ہیں، ٹرمینل ایمولیٹر لانچ کرتے ہیں، اور ہم جاتے ہیں:

#sudo bash

کیسے…؟اوپر کی سطر سوڈو کے بارے میں ہولی وار کے لیے کینونیکل ٹرگر ہے۔ سی بیоزیادہ مواقع آتے ہیں اورоزیادہ ذمہ داری. سوال یہ ہے کہ کیا آپ اسے اپنے اوپر لے سکتے ہیں؟ بہت سے لوگوں کا خیال ہے کہ اس طرح سوڈو کا استعمال کم از کم محتاط نہیں ہے۔ البتہ:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

ZFS کیوں نہیں...؟جب ہم اپنے کمپیوٹر پر سافٹ ویئر انسٹال کرتے ہیں، تو ہم بنیادی طور پر اپنا ہارڈ ویئر اس سافٹ ویئر کے ڈویلپرز کو ڈرائیو کرنے کے لیے دیتے ہیں۔
جب ہم اپنے ڈیٹا کی حفاظت کے ساتھ اس سافٹ ویئر پر بھروسہ کرتے ہیں، تو ہم اس ڈیٹا کو بحال کرنے کی لاگت کے برابر قرض لیتے ہیں، جو ہمیں کسی دن ادا کرنا پڑے گا۔

اس نقطہ نظر سے، ZFS فیراری ہے، اور mdadm+lvm زیادہ سائیکل کی طرح ہے۔

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

پھر BTRFS کیوں...؟آپریٹنگ سسٹم کو بوٹ کرنے کے لیے، ہمیں ایک فائل سسٹم کی ضرورت ہے جو Legacy/BIOS GRUB میں سپورٹ ہو آف دی باکس، اور ساتھ ہی ساتھ لائیو سنیپ شاٹس کو بھی سپورٹ کرتا ہو۔ ہم اسے /boot پارٹیشن کے لیے استعمال کریں گے۔ اس کے علاوہ، مصنف اس FS کو / (root) کے لیے استعمال کرنے کو ترجیح دیتا ہے، یہ یاد رکھنا نہیں بھولتا کہ کسی دوسرے سافٹ ویئر کے لیے آپ LVM پر علیحدہ پارٹیشن بنا سکتے ہیں اور انہیں ضروری ڈائریکٹریز میں ماؤنٹ کر سکتے ہیں۔

ہم اس FS پر ورچوئل مشینوں یا ڈیٹا بیس کی کوئی تصویر محفوظ نہیں کریں گے۔
یہ FS صرف سسٹم کے اسنیپ شاٹس کو آف کیے بغیر بنانے کے لیے استعمال کیا جائے گا اور پھر ان سنیپ شاٹس کو بھیجیں/وصول کر کے بیک اپ ڈسک میں منتقل کریں گے۔

اس کے علاوہ، مصنف عام طور پر کم از کم سافٹ ویئر کو براہ راست ہارڈ ویئر پر رکھنے اور دیگر تمام سافٹ ویئر کو ورچوئل مشینوں میں چلانے کو ترجیح دیتا ہے جیسے کہ GPUs اور PCI-USB ہوسٹ کنٹرولرز کو IOMMU کے ذریعے KVM میں فارورڈ کرنا۔

ہارڈ ویئر پر صرف وہی چیزیں رہ جاتی ہیں جو ڈیٹا اسٹوریج، ورچوئلائزیشن اور بیک اپ ہیں۔

اگر آپ ZFS پر زیادہ اعتماد کرتے ہیں، تو اصولی طور پر، مخصوص ایپلی کیشن کے لیے وہ قابل تبادلہ ہیں۔

تاہم، مصنف جان بوجھ کر بلٹ ان مررنگ/RAID اور فالتو خصوصیات کو نظر انداز کرتا ہے جو ZFS، BRTFS اور LVM میں موجود ہیں۔

ایک اضافی دلیل کے طور پر، BTRFS کے پاس بے ترتیب تحریروں کو ترتیب وار تحریروں میں تبدیل کرنے کی صلاحیت ہے، جس کا HDD پر سنیپ شاٹس/بیک اپس کی مطابقت پذیری کی رفتار پر انتہائی مثبت اثر پڑتا ہے۔

آئیے تمام آلات کو دوبارہ اسکین کریں:

#udevadm control --reload-rules && udevadm trigger

آئیے ارد گرد ایک نظر ڈالتے ہیں:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7

ڈسک لے آؤٹ

NVMe SSD

لیکن ہم انہیں کسی بھی طرح سے نشان زد نہیں کریں گے۔ اسی طرح، ہمارا BIOS ان ڈرائیوز کو نہیں دیکھتا ہے۔ لہذا، وہ مکمل طور پر سافٹ ویئر RAID پر جائیں گے۔ ہم وہاں سیکشنز بھی نہیں بنائیں گے۔ اگر آپ "کینن" یا "اصولی طور پر" کی پیروی کرنا چاہتے ہیں، تو ایک بڑا پارٹیشن بنائیں، جیسے HDD۔

SATA HDD

یہاں کوئی خاص چیز ایجاد کرنے کی ضرورت نہیں۔ ہم ہر چیز کے لیے ایک سیکشن بنائیں گے۔ ہم ایک پارٹیشن بنائیں گے کیونکہ BIOS ان ڈسکوں کو دیکھتا ہے اور ان سے بوٹ کرنے کی کوشش بھی کر سکتا ہے۔ ہم بعد میں ان ڈسکوں پر بھی GRUB انسٹال کریں گے تاکہ سسٹم اچانک ایسا کر سکے۔

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part

SATA SSD

یہیں سے چیزیں ہمارے لیے دلچسپ ہوتی ہیں۔

سب سے پہلے، ہماری ڈرائیوز 2 ٹی بی سائز کی ہیں۔ یہ MBR کے لیے قابل قبول حد کے اندر ہے، جسے ہم استعمال کریں گے۔ اگر ضروری ہو تو، GPT کے ساتھ تبدیل کیا جا سکتا ہے. GPT ڈسکوں میں ایک مطابقت کی پرت ہوتی ہے جو MBR-مطابقت رکھنے والے سسٹمز کو پہلے 4 پارٹیشنز دیکھنے کی اجازت دیتی ہے اگر وہ پہلے 2 ٹیرا بائٹس کے اندر موجود ہوں۔ اہم بات یہ ہے کہ ان ڈسکوں پر بوٹ پارٹیشن اور بائیوس_گرب پارٹیشن شروع میں ہونا چاہیے۔ یہاں تک کہ یہ آپ کو GPT Legacy/BIOS ڈرائیوز سے بوٹ کرنے کی اجازت دیتا ہے۔

لیکن یہ ہمارا معاملہ نہیں ہے۔

یہاں ہم دو حصے بنائیں گے۔ پہلا سائز 1 GB ہوگا اور RAID 1 /boot کے لیے استعمال ہوگا۔

دوسرا RAID 6 کے لیے استعمال کیا جائے گا اور ڈرائیو کے آخر میں ایک چھوٹی سی غیر مختص جگہ کے علاوہ باقی تمام خالی جگہ لے لے گا۔

یہ غیر نشان زدہ علاقہ کیا ہے؟نیٹ ورک کے ذرائع کے مطابق، ہمارے SATA SSDs میں 6 سے 78 گیگا بائٹس کے سائز میں متحرک طور پر قابل توسیع SLC کیش موجود ہے۔ ڈرائیو کی ڈیٹا شیٹ میں "گیگا بائٹس" اور "گیبی بائٹس" کے درمیان فرق کی وجہ سے ہمیں 6 گیگا بائٹس "مفت" ملتی ہیں۔ باقی 72 گیگا بائٹس غیر استعمال شدہ جگہ سے مختص کی گئی ہیں۔

یہاں یہ واضح رہے کہ ہمارے پاس ایس ایل سی کیش ہے، اور اسپیس 4 بٹ ایم ایل سی موڈ میں موجود ہے۔ جس کا ہمارے لیے مؤثر طریقے سے مطلب ہے کہ ہر 4 گیگا بائٹ خالی جگہ کے لیے ہمیں صرف 1 گیگا بائٹ SLC کیش ملے گا۔

72 گیگا بائٹس کو 4 سے ضرب دیں اور 288 گیگا بائٹس حاصل کریں۔ یہ وہ خالی جگہ ہے جسے ہم نشان زد نہیں کریں گے تاکہ ڈرائیوز کو SLC کیشے کا مکمل استعمال کرنے کی اجازت دی جا سکے۔

اس طرح، ہم مجموعی طور پر چھ ڈرائیوز سے 312 گیگا بائٹس تک ایس ایل سی کیش حاصل کریں گے۔ تمام ڈرائیوز میں سے، 2 کو RAID میں فالتو پن کے لیے استعمال کیا جائے گا۔

کیشے کی یہ مقدار ہمیں حقیقی زندگی میں بہت کم ہی ایسی صورت حال کا سامنا کرنے کی اجازت دے گی جہاں تحریر کیش میں نہیں جاتی ہے۔ یہ QLC میموری کی سب سے افسوسناک خرابی کی بہت اچھی طرح تلافی کرتا ہے - لکھنے کی انتہائی کم رفتار جب ڈیٹا کو کیشے کو نظرانداز کرتے ہوئے لکھا جاتا ہے۔ اگر آپ کا بوجھ اس سے مطابقت نہیں رکھتا ہے، تو میں تجویز کرتا ہوں کہ آپ ڈیٹا شیٹ سے TBW کو مدنظر رکھتے ہوئے اس بارے میں سخت سوچیں کہ اس طرح کے بوجھ کے تحت آپ کا SSD کتنی دیر تک چلے گا۔

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part

صفوں کی تشکیل

سب سے پہلے، ہمیں مشین کا نام تبدیل کرنے کی ضرورت ہے۔ یہ ضروری ہے کیونکہ میزبان کا نام سرنی کے نام کا حصہ ہے کہیں mdadm کے اندر اور کہیں کسی چیز کو متاثر کرتا ہے۔ بے شک، صفوں کا نام بعد میں رکھا جا سکتا ہے، لیکن یہ ایک غیر ضروری قدم ہے۔

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0

NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

کیوں - فرض کریں - صاف ...؟صفوں کو شروع کرنے سے بچنے کے لیے۔ RAID کی سطح 1 اور 6 دونوں کے لیے یہ درست ہے۔ اگر یہ ایک نئی صف ہے تو ہر چیز ابتدا کے بغیر کام کر سکتی ہے۔ مزید برآں، تخلیق کے بعد SSD صف کو شروع کرنا TBW وسائل کا ضیاع ہے۔ ہم TRIM/DISCARD کا استعمال کرتے ہیں جہاں ممکن ہو SSD arrays کو "شروع" کرنے کے لیے۔

SSD arrays کے لیے، RAID 1 DISCARD کو باکس سے باہر سپورٹ کیا جاتا ہے۔

SSD RAID 6 DISCARD arrays کے لیے، آپ کو اسے کرنل ماڈیول پیرامیٹرز میں فعال کرنا چاہیے۔

یہ صرف اس صورت میں کیا جانا چاہئے جب اس سسٹم میں لیول 4/5/6 صفوں میں استعمال ہونے والے تمام SSDs کو discard_zeroes_data کے لیے ورکنگ سپورٹ حاصل ہو۔ بعض اوقات آپ کو عجیب و غریب ڈرائیوز ملتی ہیں جو کرنل کو بتاتی ہیں کہ یہ فنکشن سپورٹ ہے، لیکن درحقیقت یہ وہاں نہیں ہے، یا فنکشن ہمیشہ کام نہیں کرتا۔ اس وقت، سپورٹ تقریبا ہر جگہ دستیاب ہے، تاہم، غلطیوں کے ساتھ پرانی ڈرائیوز اور فرم ویئر موجود ہیں. اس وجہ سے، DISCARD سپورٹ RAID 6 کے لیے بطور ڈیفالٹ غیر فعال ہے۔

دھیان دیں، درج ذیل کمانڈ NVMe ڈرائیوز پر موجود تمام ڈیٹا کو "زیروز" کے ساتھ "شروع" کر کے تباہ کر دے گی۔

#blkdiscard /dev/md0

اگر کچھ غلط ہو جاتا ہے تو، ایک قدم کی وضاحت کرنے کی کوشش کریں۔

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

اتنا بڑا کیوں...؟chunk-size کو بڑھانے سے بلاکس میں chunk-size تک کے بے ترتیب پڑھنے کی رفتار پر مثبت اثر پڑتا ہے۔ ایسا اس لیے ہوتا ہے کیونکہ مناسب سائز یا اس سے چھوٹے کا ایک آپریشن مکمل طور پر ایک ڈیوائس پر مکمل کیا جا سکتا ہے۔ لہذا، تمام آلات سے IOPS کا خلاصہ کیا جاتا ہے۔ اعداد و شمار کے مطابق، 99% IO 512K سے زیادہ نہیں ہے۔

RAID 6 IOPS فی تحریر ہمیشہ ایک ڈرائیو کے IOPS سے کم یا اس کے برابر۔ جب، ایک بے ترتیب پڑھنے کے طور پر، IOPS ایک ڈرائیو کے مقابلے میں کئی گنا زیادہ ہو سکتا ہے، اور یہاں بلاک کا سائز کلیدی اہمیت کا حامل ہے۔
مصنف کو ایک ایسے پیرامیٹر کو بہتر بنانے کی کوشش کرنے کا نقطہ نظر نہیں آتا ہے جو RAID 6 بائی ڈیزائن میں خراب ہے اور اس کے بجائے بہتر کرتا ہے کہ RAID 6 کس چیز میں اچھا ہے۔
ہم RAID 6 کے ناقص بے ترتیب تحریر کی تلافی ایک NVMe کیشے اور پتلی فراہم کرنے والی چالوں سے کریں گے۔

ہم نے ابھی تک RAID 6 کے لیے DISCARD کو فعال نہیں کیا ہے۔ اس لیے ہم ابھی اس صف کو "شروع" نہیں کریں گے۔ ہم OS کو انسٹال کرنے کے بعد یہ کام بعد میں کریں گے۔

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

NVMe RAID پر LVM

رفتار کے لیے، ہم روٹ فائل سسٹم کو NVMe RAID 1 پر رکھنا چاہتے ہیں جو کہ /dev/md0 ہے۔
تاہم، ہمیں اب بھی دیگر ضروریات، جیسے سویپ، میٹا ڈیٹا اور LVM-cache اور LVM-thin میٹا ڈیٹا کے لیے اس تیز صف کی ضرورت ہوگی، لہذا ہم اس صف پر ایک LVM VG بنائیں گے۔

#pvcreate /dev/md0
#vgcreate root /dev/md0

آئیے روٹ فائل سسٹم کے لیے ایک پارٹیشن بناتے ہیں۔

#lvcreate -L 128G --name root root

آئیے رام کے سائز کے مطابق تبادلہ کرنے کے لیے ایک پارٹیشن بناتے ہیں۔

#lvcreate -L 32G --name swap root

OS کی تنصیب

مجموعی طور پر، ہمارے پاس سسٹم کو انسٹال کرنے کے لیے سب کچھ ضروری ہے۔

اوبنٹو لائیو ماحول سے سسٹم انسٹالیشن وزرڈ لانچ کریں۔ عام تنصیب۔ صرف تنصیب کے لیے ڈسکوں کو منتخب کرنے کے مرحلے پر، آپ کو درج ذیل کی وضاحت کرنے کی ضرورت ہے:

  • /dev/md1، - ماؤنٹ پوائنٹ /بوٹ، FS - BTRFS
  • /dev/root/root (aka /dev/mapper/root-root)، - ماؤنٹ پوائنٹ / (روٹ)، FS - BTRFS
  • /dev/root/swap (aka /dev/mapper/root-swap)، - سویپ پارٹیشن کے طور پر استعمال کریں
  • بوٹ لوڈر کو /dev/sda پر انسٹال کریں۔

جب آپ BTRFS کو روٹ فائل سسٹم کے طور پر منتخب کرتے ہیں، تو انسٹالر خود بخود / (root) کے لیے "@" اور /home کے لیے "@home" کے نام سے دو BTRFS والیوم بنائے گا۔

آئیے انسٹالیشن شروع کریں...

تنصیب ایک موڈل ڈائیلاگ باکس کے ساتھ ختم ہو جائے گی جو بوٹ لوڈر کو انسٹال کرنے میں غلطی کی نشاندہی کرتا ہے۔ بدقسمتی سے، آپ معیاری ذرائع کا استعمال کرتے ہوئے اس ڈائیلاگ سے باہر نکلنے اور انسٹالیشن جاری رکھنے کے قابل نہیں ہوں گے۔ ہم سسٹم سے لاگ آؤٹ ہوتے ہیں اور دوبارہ لاگ ان ہوتے ہیں، جس کا اختتام صاف اوبنٹو لائیو ڈیسک ٹاپ پر ہوتا ہے۔ ٹرمینل کھولیں، اور دوبارہ:

#sudo bash

انسٹالیشن جاری رکھنے کے لیے کروٹ ماحول بنائیں:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

آئیے chroot میں نیٹ ورک اور میزبان نام کو ترتیب دیں:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

آئیے کروٹ ماحول میں چلتے ہیں:

#chroot /mnt/chroot

سب سے پہلے، ہم پیکجز فراہم کریں گے:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

آئیے چیک کریں اور ان تمام پیکجوں کو ٹھیک کریں جو سسٹم کی نامکمل تنصیب کی وجہ سے ٹیڑھے طریقے سے انسٹال ہوئے تھے۔

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

اگر کچھ کام نہیں کرتا ہے، تو آپ کو پہلے /etc/apt/sources.list میں ترمیم کرنے کی ضرورت ہوگی۔

آئیے TRIM/DISCARD کو فعال کرنے کے لیے RAID 6 ماڈیول کے پیرامیٹرز کو ایڈجسٹ کریں:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

آئیے اپنی صفوں کو تھوڑا سا موافقت کریں:

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

وہ کیا تھا..؟ہم نے udev قواعد کا ایک سیٹ بنایا ہے جو درج ذیل کام کرے گا:

  • RAID 2020 کے لیے بلاک کیشے کا سائز 6 کے لیے مناسب ہونے کے لیے سیٹ کریں۔ پہلے سے طے شدہ قدر، ایسا لگتا ہے، لینکس کی تخلیق کے بعد سے تبدیل نہیں ہوا ہے، اور کافی عرصے سے کافی نہیں ہے۔
  • صفوں کی جانچ/ مطابقت پذیری کی مدت کے لیے کم از کم IO محفوظ کریں۔ یہ آپ کی صفوں کو بوجھ کے نیچے دائمی ہم آہنگی کی حالت میں پھنسنے سے روکنے کے لیے ہے۔
  • صفوں کی جانچ/مطابقت کے دوران زیادہ سے زیادہ IO کو محدود کریں۔ یہ ضروری ہے تاکہ SSD RAIDs کو سنکرونائز کرنا/چیک کرنا آپ کی ڈرائیوز کو کرکرا نہ کر دے۔ یہ خاص طور پر NVMe کے لیے سچ ہے۔ (ریڈی ایٹر کے بارے میں یاد رکھیں؟ میں مذاق نہیں کر رہا تھا۔)
  • ڈسکوں کو APM کے ذریعے سپنڈل روٹیشن (HDD) کو روکنے سے منع کریں اور ڈسک کنٹرولرز کے لیے نیند کا ٹائم آؤٹ 7 گھنٹے مقرر کریں۔ اگر آپ کی ڈرائیوز یہ کر سکتی ہیں تو آپ APM کو مکمل طور پر غیر فعال کر سکتے ہیں (-B 255)۔ پہلے سے طے شدہ قدر کے ساتھ، ڈرائیوز پانچ سیکنڈ کے بعد رک جائیں گی۔ پھر OS ڈسک کیشے کو دوبارہ ترتیب دینا چاہتا ہے، ڈسکیں دوبارہ گھوم جائیں گی، اور سب کچھ دوبارہ شروع ہو جائے گا۔ ڈسکس میں سپنڈل گردشوں کی ایک محدود زیادہ سے زیادہ تعداد ہوتی ہے۔ اس طرح کا ایک سادہ ڈیفالٹ سائیکل آپ کی ڈسکوں کو چند سالوں میں آسانی سے مار سکتا ہے۔ تمام ڈسک اس کا شکار نہیں ہیں، لیکن ہماری "لیپ ٹاپ" ہیں، مناسب ڈیفالٹ سیٹنگز کے ساتھ، جو RAID کو منی MAID کی طرح دکھاتی ہیں۔
  • ڈسک پر ریڈہیڈ انسٹال کریں (گھومنے والی) 1 میگا بائٹ - دو لگاتار بلاکس/چنک RAID 6
  • خود ہی صفوں پر ریڈہیڈ کو غیر فعال کریں۔

آئیے ترمیم کریں /etc/fstab:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
ایسا کیوں ہے..؟ہم UUID کے ذریعہ /boot پارٹیشن کو تلاش کریں گے۔ سرنی کا نام نظریاتی طور پر تبدیل ہوسکتا ہے۔

ہم باقی حصوں کو LVM ناموں سے /dev/mapper/vg-lv اشارے میں تلاش کریں گے، کیونکہ وہ بالکل منفرد طریقے سے پارٹیشنز کی شناخت کرتے ہیں۔

ہم LVM کے لیے UUID استعمال نہیں کرتے کیونکہ LVM والیوم کا UUID اور ان کے سنیپ شاٹس ایک جیسے ہو سکتے ہیں۔Mount /dev/mapper/root-root.. دو بار؟جی ہاں. بالکل۔ BTRFS کی خصوصیت۔ اس فائل سسٹم کو مختلف سب وولز کے ساتھ کئی بار نصب کیا جا سکتا ہے۔

اسی خصوصیت کی وجہ سے، میں تجویز کرتا ہوں کہ کبھی بھی فعال BTRFS والیوم کے LVM سنیپ شاٹس نہ بنائیں۔ ریبوٹ کرنے پر آپ کو سرپرائز مل سکتا ہے۔

آئیے mdadm config کو دوبارہ تخلیق کریں:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

آئیے LVM کی ترتیبات کو ایڈجسٹ کریں:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

وہ کیا تھا..؟ہم نے مقبوضہ جگہ کے 90% حجم کے 5% تک پہنچنے پر LVM پتلے تالابوں کی خودکار توسیع کو فعال کر دیا ہے۔

ہم نے LVM کیشے کے لیے کیشے بلاکس کی زیادہ سے زیادہ تعداد میں اضافہ کیا ہے۔

ہم نے LVM کو LVM والیوم (PV) تلاش کرنے سے روک دیا ہے:

  • ایل وی ایم کیشے (سی ڈیٹا) پر مشتمل آلات
  • LVM کیشے کا استعمال کرتے ہوئے کیش کردہ آلات، کیشے کو نظرانداز کرتے ہوئے ( _corig)۔ اس صورت میں، کیشڈ ڈیوائس کو ابھی بھی کیش کے ذریعے اسکین کیا جائے گا (صرف )۔
  • ایل وی ایم کیشے میٹا ڈیٹا (سیمیٹا) پر مشتمل آلات
  • VG میں تمام آلات نام کی تصاویر کے ساتھ۔ یہاں ہمارے پاس ورچوئل مشینوں کی ڈسک امیجز ہوں گی، اور ہم نہیں چاہتے کہ میزبان پر LVM گیسٹ OS سے تعلق رکھنے والے حجم کو چالو کرے۔
  • VG میں تمام آلات نام کے بیک اپ کے ساتھ۔ یہاں ہمارے پاس ورچوئل مشین امیجز کی بیک اپ کاپیاں ہوں گی۔
  • وہ تمام آلات جن کا نام "gpv" کے ساتھ ختم ہوتا ہے (مہمان کا جسمانی حجم)

LVM VG پر خالی جگہ خالی کرتے وقت ہم نے DISCARD سپورٹ کو فعال کیا ہے۔ محتاط رہیں. اس سے SSD پر LVs کو حذف کرنے میں کافی وقت لگے گا۔ یہ خاص طور پر SSD RAID 6 پر لاگو ہوتا ہے۔ تاہم، منصوبے کے مطابق، ہم پتلی پروویژننگ کا استعمال کریں گے، اس لیے یہ ہمارے لیے بالکل بھی رکاوٹ نہیں بنے گا۔

آئیے initramfs امیج کو اپ ڈیٹ کریں:

#update-initramfs -u -k all

گرب کو انسٹال اور کنفیگر کریں:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

کون سی ڈسک کا انتخاب کرنا ہے؟وہ تمام جو sd* ہیں۔ سسٹم کو کسی بھی ورکنگ SATA ڈرائیو یا SSD سے بوٹ کرنے کے قابل ہونا چاہیے۔

انہوں نے os-prober کیوں شامل کیا ..؟ضرورت سے زیادہ آزادی اور چنچل ہاتھوں کے لیے۔

اگر RAIDs میں سے ایک انحطاطی حالت میں ہو تو یہ صحیح طریقے سے کام نہیں کرتا ہے۔ یہ پارٹیشنز پر OS کو تلاش کرنے کی کوشش کرتا ہے جو اس ہارڈ ویئر پر چلنے والی ورچوئل مشینوں میں استعمال ہوتے ہیں۔

اگر آپ کو اس کی ضرورت ہو تو، آپ اسے چھوڑ سکتے ہیں، لیکن مندرجہ بالا تمام چیزوں کو ذہن میں رکھیں۔ میں آن لائن شرارتی ہاتھوں سے چھٹکارا پانے کے لیے ترکیبیں تلاش کرنے کی تجویز کرتا ہوں۔

اس کے ساتھ ہم نے ابتدائی تنصیب مکمل کر لی ہے۔ نئے نصب شدہ OS میں ریبوٹ کرنے کا وقت آگیا ہے۔ بوٹ ایبل لائیو سی ڈی/یو ایس بی کو ہٹانا نہ بھولیں۔

#exit
#reboot

SATA SSDs میں سے کسی کو بوٹ ڈیوائس کے طور پر منتخب کریں۔

SATA SSD پر LVM

اس مقام پر، ہم پہلے ہی نئے OS میں بوٹ کر چکے ہیں، نیٹ ورک کو کنفیگر کر چکے ہیں، مناسب ہے، ٹرمینل ایمولیٹر کھول چکے ہیں، اور لانچ کر چکے ہیں:

#sudo bash

آئیے جاری رکھیں۔

SATA SSD سے صف کو "شروع کریں":

#blkdiscard /dev/md2

اگر یہ کام نہیں کرتا ہے، تو کوشش کریں:

#blkdiscard --step 65536 /dev/md2
SATA SSD پر LVM VG بنائیں:

#pvcreate /dev/md2
#vgcreate data /dev/md2

ایک اور وی جی کیوں..؟درحقیقت، ہمارے پاس پہلے سے ہی ایک وی جی ہے جس کا نام روٹ ہے۔ کیوں نہیں سب کچھ ایک VG میں شامل کریں؟

اگر ایک VG میں کئی PVs ہیں، تو VG کو صحیح طریقے سے فعال کرنے کے لیے، تمام PVs کا موجود ہونا ضروری ہے (آن لائن)۔ استثنا LVM RAID ہے، جسے ہم جان بوجھ کر استعمال نہیں کرتے ہیں۔

ہم واقعی چاہتے ہیں کہ اگر RAID 6 arrays میں سے کسی میں ناکامی (ڈیٹا نقصان کو پڑھیں) تو آپریٹنگ سسٹم عام طور پر بوٹ ہو جائے گا اور ہمیں مسئلہ حل کرنے کا موقع فراہم کرے گا۔

ایسا کرنے کے لیے، تجرید کی پہلی سطح پر ہم ہر قسم کے جسمانی "میڈیا" کو الگ الگ VG میں الگ کر دیں گے۔

سائنسی طور پر، مختلف RAID صفوں کا تعلق مختلف "قابل اعتبار ڈومینز" سے ہے۔ آپ کو ان کے لیے ایک VG میں گھس کر ان کے لیے ناکامی کا ایک اضافی عام نقطہ نہیں بنانا چاہیے۔

"ہارڈ ویئر" کی سطح پر LVM کی موجودگی ہمیں مختلف RAID arrays کے ٹکڑوں کو مختلف طریقوں سے جوڑ کر من مانی طور پر کاٹنے کی اجازت دے گی۔ مثال کے طور پر - چلائیں ساتھ ساتھ bcache + LVM پتلا، bcache + BTRFS، LVM cache + LVM پتلا، کیش کے ساتھ ایک پیچیدہ ZFS کنفیگریشن، یا ان سب کو آزمانے اور موازنہ کرنے کے لیے کوئی اور جہنمی مرکب۔

"ہارڈ ویئر" کی سطح پر، ہم اچھے پرانے "موٹی" LVM والیوم کے علاوہ کچھ استعمال نہیں کریں گے۔ اس اصول کی رعایت بیک اپ پارٹیشن ہو سکتی ہے۔

مجھے لگتا ہے کہ اس لمحے تک، بہت سے قارئین نے پہلے ہی گھونسلے کی گڑیا کے بارے میں کچھ شک کرنا شروع کر دیا تھا.

SATA HDD پر LVM

#pvcreate /dev/md3
#vgcreate backup /dev/md3

نیا وی جی دوبارہ..؟ہم واقعی چاہتے ہیں کہ اگر وہ ڈسک ارے جو ہم ڈیٹا بیک اپ کے لیے استعمال کریں گے ناکام ہو جاتا ہے، تو ہمارا آپریٹنگ سسٹم معمول کے مطابق کام کرتا رہے گا، جبکہ نان بیک اپ ڈیٹا تک رسائی کو معمول کے مطابق برقرار رکھے گا۔ لہذا، VG ایکٹیویشن کے مسائل سے بچنے کے لیے، ہم ایک علیحدہ VG بناتے ہیں۔

LVM کیشے کو ترتیب دیا جا رہا ہے۔

آئیے اسے کیشنگ ڈیوائس کے طور پر استعمال کرنے کے لیے NVMe RAID 1 پر ایک LV بنائیں۔

#lvcreate -L 70871154688B --name cache root

اتنی کم کیوں ہے...؟حقیقت یہ ہے کہ ہمارے NVMe SSDs میں SLC کیش بھی ہے۔ 4-بٹ MLC میں خالی جگہ کی وجہ سے 18 گیگا بائٹس "مفت" اور 3 گیگا بائٹ ڈائنامک۔ ایک بار جب یہ کیش ختم ہو جائے گا، NVMe SSDs کیشے کے ساتھ ہمارے SATA SSD سے زیادہ تیز نہیں ہوں گے۔ دراصل، اس وجہ سے، ہمارے لیے LVM کیش پارٹیشن کو NVMe ڈرائیو کے SLC کیشے کے سائز سے دوگنا بڑا بنانا کوئی معنی نہیں رکھتا۔ استعمال شدہ NVMe ڈرائیوز کے لیے، مصنف 32-64 گیگا بائٹس کیشے بنانا مناسب سمجھتا ہے۔

دی گئی پارٹیشن سائز 64 گیگا بائٹس کیشے، کیشے میٹا ڈیٹا، اور میٹا ڈیٹا بیک اپ کو منظم کرنے کے لیے درکار ہے۔

مزید برآں، میں نوٹ کرتا ہوں کہ گندے سسٹم کے بند ہونے کے بعد، LVM پورے کیشے کو گندے کے طور پر نشان زد کر دے گا اور دوبارہ ہم آہنگ ہو جائے گا۔ مزید یہ کہ، جب بھی اس ڈیوائس پر lvchange استعمال کیا جائے گا تب تک یہ دہرایا جائے گا جب تک کہ سسٹم دوبارہ شروع نہ ہوجائے۔ لہذا، میں مناسب اسکرپٹ کا استعمال کرتے ہوئے فوری طور پر کیشے کو دوبارہ بنانے کی تجویز کرتا ہوں۔

آئیے SATA RAID 6 پر ایک LV بنائیں تاکہ اسے کیشڈ ڈیوائس کے طور پر استعمال کریں۔

#lvcreate -L 3298543271936B --name cache data

صرف تین ٹیرا بائٹس کیوں..؟تاکہ، اگر ضروری ہو تو، آپ کچھ دیگر ضروریات کے لیے SATA SSD RAID 6 استعمال کر سکتے ہیں۔ کیشڈ اسپیس کا سائز متحرک طور پر بڑھایا جا سکتا ہے، فلائی پر، سسٹم کو روکے بغیر۔ ایسا کرنے کے لیے، آپ کو عارضی طور پر کیشے کو روکنے اور دوبارہ فعال کرنے کی ضرورت ہے، لیکن LVM-cache over کا مخصوص فائدہ، مثال کے طور پر، bcache یہ ہے کہ یہ فلائی پر کیا جا سکتا ہے۔

آئیے کیشنگ کے لیے ایک نیا VG بنائیں۔

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

آئیے کیشڈ ڈیوائس پر ایک LV بنائیں۔

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

یہاں ہم نے فوری طور پر /dev/data/cache پر تمام خالی جگہ لے لی تاکہ دیگر تمام ضروری پارٹیشنز فوری طور پر /dev/root/cache پر بن جائیں۔ اگر آپ نے غلط جگہ پر کوئی چیز بنائی ہے تو آپ اسے pvmove کے ذریعے منتقل کر سکتے ہیں۔

آئیے کیشے کو بنائیں اور فعال کریں:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

اس قدر ٹکڑا کیوں..؟عملی تجربات کے ذریعے، مصنف یہ جاننے کے قابل تھا کہ بہترین نتیجہ حاصل کیا جاتا ہے اگر LVM کیشے بلاک کا سائز LVM پتلے بلاک کے سائز سے موافق ہو۔ مزید یہ کہ، سائز جتنا چھوٹا ہوگا، ترتیب بے ترتیب ریکارڈنگ میں اتنی ہی بہتر کارکردگی دکھاتی ہے۔

64k کم از کم بلاک سائز ہے جس کی اجازت LVM پتلی کے لیے ہے۔

لکھنے میں محتاط رہیں..!جی ہاں. اس قسم کی کیشے کیشڈ ڈیوائس پر لکھنے کی مطابقت پذیری کو موخر کرتی ہے۔ اس کا مطلب یہ ہے کہ اگر کیش گم ہو جاتا ہے، تو آپ کیشڈ ڈیوائس پر ڈیٹا کھو سکتے ہیں۔ بعد میں، مصنف آپ کو بتائے گا کہ اس خطرے کی تلافی کے لیے NVMe RAID 1 کے علاوہ کون سے اقدامات کیے جا سکتے ہیں۔

اس کیشے کی قسم کو جان بوجھ کر RAID 6 کی ناقص تحریری کارکردگی کی تلافی کے لیے منتخب کیا گیا تھا۔

آئیے چیک کریں کہ ہمیں کیا ملا:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

صرف [cachedata_corig] /dev/data/cache پر واقع ہونا چاہیے۔ اگر کچھ غلط ہے تو pvmove استعمال کریں۔

اگر ضروری ہو تو آپ ایک کمانڈ کے ساتھ کیشے کو غیر فعال کر سکتے ہیں:

#lvconvert -y --uncache cache/cachedata

یہ آن لائن کیا جاتا ہے۔ LVM آسانی سے کیشے کو ڈسک سے ہم آہنگ کرے گا، اسے ہٹا دے گا، اور cachedata_corig کا نام تبدیل کر کے cachedata میں ڈال دے گا۔

LVM پتلا ترتیب دینا

آئیے تقریباً اندازہ لگاتے ہیں کہ LVM پتلے میٹا ڈیٹا کے لیے ہمیں کتنی جگہ کی ضرورت ہے:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

4 گیگا بائٹس تک راؤنڈ: 4294967296B

دو سے ضرب کریں اور LVM PV میٹا ڈیٹا کے لیے 4194304B شامل کریں: 8594128896B
آئیے NVMe RAID 1 پر LVM پتلا میٹا ڈیٹا اور اس کی بیک اپ کاپی رکھنے کے لیے ایک علیحدہ پارٹیشن بنائیں:

#lvcreate -L 8594128896B --name images root

کس لیے..؟یہاں سوال پیدا ہوسکتا ہے: LVM پتلا میٹا ڈیٹا کو الگ سے کیوں رکھیں اگر یہ NVMe پر ابھی بھی کیش کیا جائے گا اور تیزی سے کام کرے گا۔

اگرچہ یہاں رفتار اہم ہے، لیکن یہ بنیادی وجہ سے بہت دور ہے۔ بات یہ ہے کہ کیشے ناکامی کا ایک نقطہ ہے۔ اس کے ساتھ کچھ ہو سکتا ہے، اور اگر LVM پتلا میٹا ڈیٹا کیش کیا جاتا ہے، تو یہ سب کچھ مکمل طور پر ختم ہو جائے گا۔ مکمل میٹا ڈیٹا کے بغیر، پتلی جلدوں کو جمع کرنا تقریباً ناممکن ہوگا۔

میٹا ڈیٹا کو علیحدہ غیر کیشڈ، لیکن تیز، والیوم میں منتقل کرکے، ہم کیش کے نقصان یا بدعنوانی کی صورت میں میٹا ڈیٹا کی حفاظت کی ضمانت دیتے ہیں۔ اس صورت میں، کیش کے نقصان کی وجہ سے ہونے والے تمام نقصان کو پتلی جلدوں کے اندر مقامی کیا جائے گا، جو کہ ریکوری کے طریقہ کار کو وسعت کے حکم سے آسان بنائے گا۔ زیادہ امکان کے ساتھ، یہ نقصانات FS لاگز کا استعمال کرتے ہوئے بحال کیے جائیں گے۔

مزید برآں، اگر پہلے پتلی والیوم کا سنیپ شاٹ لیا گیا تھا، اور اس کے بعد کیشے کو کم از کم ایک بار مکمل طور پر ہم آہنگ کیا گیا تھا، تو، LVM پتلی کے اندرونی ڈیزائن کی وجہ سے، کیش کے نقصان کی صورت میں اسنیپ شاٹ کی سالمیت کی ضمانت دی جائے گی۔ .

آئیے ایک نیا VG بنائیں جو پتلی فراہمی کے لیے ذمہ دار ہو گا:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
آئیے ایک پول بنائیں:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
کیوں -Z yاس موڈ کا اصل مقصد کیا ہے اس کے علاوہ - جگہ کو دوبارہ تقسیم کرتے وقت ایک ورچوئل مشین سے ڈیٹا کو دوسری ورچوئل مشین میں لیک ہونے سے روکنے کے لیے - 64k سے چھوٹے بلاکس میں بے ترتیب تحریر کی رفتار کو بڑھانے کے لیے زیرونگ کا بھی استعمال کیا جاتا ہے۔ پتلی والیوم کے پہلے سے غیر مختص کردہ علاقے پر 64k سے کم کوئی بھی تحریر کیشے میں 64K کنارے سے منسلک ہو جائے گی۔ یہ آپریشن کو مکمل طور پر کیش کے ذریعے انجام دینے کی اجازت دے گا، کیشڈ ڈیوائس کو نظرانداز کر کے۔

آئیے LVs کو متعلقہ PVs میں منتقل کریں:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

آؤ دیکھیں:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

آئیے ٹیسٹ کے لیے ایک پتلی والیوم بنائیں:

#lvcreate -V 64G --thin-pool thin-pool --name test images

ہم ٹیسٹ اور نگرانی کے لیے پیکجز انسٹال کریں گے:

#apt-get install sysstat fio

اس طرح آپ حقیقی وقت میں ہماری اسٹوریج کنفیگریشن کے رویے کا مشاہدہ کر سکتے ہیں:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

اس طرح ہم اپنی ترتیب کو جانچ سکتے ہیں:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

احتیاط سے! وسیلہ!یہ کوڈ 36 مختلف ٹیسٹ چلائے گا، ہر ایک 4 سیکنڈ تک چلتا ہے۔ آدھے ٹیسٹ ریکارڈنگ کے لیے ہیں۔ آپ NVMe پر 4 سیکنڈ میں بہت کچھ ریکارڈ کر سکتے ہیں۔ 3 گیگا بائٹس فی سیکنڈ تک۔ لہذا، تحریری ٹیسٹ کا ہر رن آپ سے 216 گیگا بائٹس تک کا SSD ریسورس کھا سکتا ہے۔

پڑھنا اور لکھنا مخلوط؟جی ہاں. پڑھنے اور لکھنے کے الگ الگ ٹیسٹ چلانے کا مطلب ہے۔ مزید برآں، اس بات کو یقینی بنانا سمجھ میں آتا ہے کہ تمام کیچز کو ہم آہنگ کیا گیا ہے تاکہ پہلے کی گئی تحریر پڑھنے کو متاثر نہ کرے۔

پہلی لانچ کے دوران اور بعد میں کیشے اور پتلی والیوم کے بھرنے کے دوران نتائج بہت مختلف ہوں گے، اور اس بات پر بھی منحصر ہے کہ آیا سسٹم آخری لانچ کے دوران بھرے ہوئے کیشز کو ہم آہنگ کرنے میں کامیاب ہوا یا نہیں۔

دوسری چیزوں کے علاوہ، میں پہلے سے ہی مکمل پتلی والیوم پر رفتار کی پیمائش کرنے کی تجویز کرتا ہوں جہاں سے ابھی ایک سنیپ شاٹ لیا گیا تھا۔ مصنف کے پاس یہ مشاہدہ کرنے کا موقع تھا کہ پہلا سنیپ شاٹ بنانے کے فوراً بعد بے ترتیب تحریریں کس طرح تیزی سے تیز ہوتی ہیں، خاص طور پر جب کیش ابھی مکمل طور پر بھرا نہ ہو۔ یہ کاپی آن رائٹ رائٹ سیمنٹکس، کیشے کی سیدھ اور پتلی والیوم بلاکس کی وجہ سے ہوتا ہے، اور یہ حقیقت کہ RAID 6 پر ایک بے ترتیب تحریر RAID 6 سے بے ترتیب پڑھنے میں بدل جاتی ہے اور اس کے بعد کیش پر لکھنا ہوتا ہے۔ ہماری کنفیگریشن میں، RAID 6 سے بے ترتیب پڑھنا لکھنے سے 6 گنا (صف میں SATA SSDs کی تعداد) تک تیز ہے۔ کیونکہ CoW کے لیے بلاکس ایک پتلے تالاب سے ترتیب وار مختص کیے جاتے ہیں، پھر ریکارڈنگ، زیادہ تر حصے کے لیے، بھی ترتیب وار میں بدل جاتی ہے۔

یہ دونوں خصوصیات آپ کے فائدے کے لیے استعمال کی جا سکتی ہیں۔

کیشے "مربوط" سنیپ شاٹس

کیشے کے نقصان/نقصان کی صورت میں ڈیٹا کے ضائع ہونے کے خطرے کو کم کرنے کے لیے، مصنف نے اس معاملے میں ان کی سالمیت کی ضمانت کے لیے اسنیپ شاٹس کو گھومنے کی مشق متعارف کرانے کی تجویز پیش کی ہے۔

سب سے پہلے، کیونکہ پتلی والیوم میٹا ڈیٹا ایک غیر محفوظ شدہ ڈیوائس پر رہتا ہے، میٹا ڈیٹا مستقل رہے گا اور ممکنہ نقصانات کو ڈیٹا بلاکس کے اندر الگ کر دیا جائے گا۔

درج ذیل اسنیپ شاٹ کی گردش کا چکر کیشے کے نقصان کی صورت میں اسنیپ شاٹس کے اندر موجود ڈیٹا کی سالمیت کی ضمانت دیتا ہے:

  1. نام <name> کے ساتھ ہر پتلی والیوم کے لیے، نام <name>.cached کے ساتھ ایک سنیپ شاٹ بنائیں
  2. آئیے ہجرت کی حد کو ایک معقول اعلی قیمت پر سیٹ کریں: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
  3. لوپ میں ہم کیشے میں گندے بلاکس کی تعداد چیک کرتے ہیں: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' جب تک ہم صفر حاصل نہیں کرتے۔ اگر صفر بہت لمبے عرصے سے غائب ہے، تو اسے عارضی طور پر کیش کو رائٹ تھرو موڈ میں تبدیل کرکے بنایا جا سکتا ہے۔ تاہم، ہمارے SATA اور NVMe SSD arrays کے ساتھ ساتھ ان کے TBW وسائل کی رفتار کی خصوصیات کو مدنظر رکھتے ہوئے، آپ یا تو کیش موڈ کو تبدیل کیے بغیر اس لمحے کو تیزی سے پکڑ سکیں گے، یا آپ کا ہارڈویئر اپنے تمام وسائل کو مکمل طور پر کھا جائے گا۔ چند دنوں کے. وسائل کی حدود کی وجہ سے، نظام اصولی طور پر، ہر وقت 100% تحریری بوجھ سے کم رہنے سے قاصر ہے۔ ہمارے NVMe SSDs 100% تحریری بوجھ کے تحت وسائل کو مکمل طور پر ختم کر دیں گے۔ دن کے 3-4. SATA SSDs صرف دو گنا لمبے عرصے تک چلیں گے۔ لہذا، ہم فرض کریں گے کہ زیادہ تر بوجھ پڑھنے پر جاتا ہے، اور ہمارے پاس نسبتاً قلیل مدتی بہت زیادہ سرگرمیاں ہوتی ہیں اور لکھنے کے لیے اوسطاً کم بوجھ ہوتا ہے۔
  4. جیسے ہی ہم نے صفر پکڑا (یا بنایا)، ہم نے <name>.cached کا نام بدل کر <name>.committed کر دیا۔ پرانا <name>.committed حذف کر دیا گیا ہے۔
  5. اختیاری طور پر، اگر کیشے 100% بھرا ہوا ہے، تو اسے اسکرپٹ کے ذریعے دوبارہ بنایا جا سکتا ہے، اس طرح اسے صاف کیا جا سکتا ہے۔ آدھے خالی کیشے کے ساتھ، نظام لکھتے وقت بہت تیزی سے کام کرتا ہے۔
  6. منتقلی کی حد کو صفر پر سیٹ کریں: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata یہ عارضی طور پر کیشے کو مرکزی میڈیا کے ساتھ مطابقت پذیر ہونے سے روک دے گا۔
  7. ہم انتظار کرتے ہیں جب تک کہ کافی تبدیلیاں کیشے میں جمع نہ ہوں۔ #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' یا ٹائمر بند ہو جائے گا.
  8. ہم دوبارہ دہراتے ہیں۔

ہجرت کی دہلیز میں مشکلات کیوں...؟بات یہ ہے کہ حقیقی عملی طور پر، ایک "بے ترتیب" ریکارڈنگ دراصل مکمل طور پر بے ترتیب نہیں ہوتی۔ اگر ہم 4 کلو بائٹ سائز کے سیکٹر پر کچھ لکھتے ہیں، تو اس بات کا بہت زیادہ امکان ہے کہ اگلے چند منٹوں میں ایک ہی یا پڑوسی (+- 32K) سیکٹر میں سے کسی ایک میں ریکارڈ بنایا جائے گا۔

مائیگریشن تھریشولڈ کو صفر پر سیٹ کرکے، ہم SATA SSD پر رائٹ سنکرونائزیشن کو ملتوی کرتے ہیں اور کیشے میں ایک 64K بلاک میں کئی تبدیلیاں جمع کرتے ہیں۔ یہ SATA SSD کے وسائل کو نمایاں طور پر بچاتا ہے۔

کوڈ کہاں ہے..؟بدقسمتی سے، مصنف خود کو باش اسکرپٹ کی ترقی میں ناکافی طور پر قابل سمجھتا ہے کیونکہ وہ 100 فیصد خود سکھایا ہوا ہے اور "گوگل" سے چلنے والی ترقی پر عمل کرتا ہے، اس لیے اس کا خیال ہے کہ اس کے ہاتھ سے نکلنے والا خوفناک کوڈ کسی کو استعمال نہیں کرنا چاہیے۔ اور

میرا خیال ہے کہ اس شعبے کے پیشہ ور افراد اگر ضروری ہو تو، اوپر بیان کردہ تمام منطق کو آزادانہ طور پر بیان کر سکیں گے، اور، شاید، یہاں تک کہ خوبصورتی سے اسے ایک سسٹمڈ سروس کے طور پر ڈیزائن کر سکیں گے، جیسا کہ مصنف نے کرنے کی کوشش کی ہے۔

اس طرح کی ایک سادہ اسنیپ شاٹ روٹیشن اسکیم ہمیں نہ صرف ایک سنیپ شاٹ کو SATA SSD پر مکمل طور پر مطابقت پذیر رکھنے کی اجازت دے گی، بلکہ یہ ہمیں thin_delta یوٹیلیٹی کا استعمال کرتے ہوئے یہ جاننے کی بھی اجازت دے گی کہ اس کی تخلیق کے بعد کون سے بلاکس کو تبدیل کیا گیا تھا، اور اس طرح نقصان کو مقامی طور پر تبدیل کیا گیا تھا۔ اہم جلدوں، بہت وصولی کو آسان بنانے .

libvirt/KVM میں TRIM/DSCARD

کیونکہ ڈیٹا سٹوریج کو KVM چلانے والے libvirt کے لیے استعمال کیا جائے گا، پھر یہ ایک اچھا خیال ہوگا کہ ہم اپنے VMs کو نہ صرف خالی جگہ لینے کے لیے سکھائیں، بلکہ اسے خالی کرنے کے لیے بھی جو اب ضرورت نہیں ہے۔

یہ ورچوئل ڈسکوں پر TRIM/DISCARD سپورٹ کی تقلید کرکے کیا جاتا ہے۔ ایسا کرنے کے لیے، آپ کو کنٹرولر کی قسم کو virtio-scsi میں تبدیل کرنے اور xml میں ترمیم کرنے کی ضرورت ہے۔

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

مہمان OS سے اس طرح کے ڈسکارڈز کو LVM کے ذریعہ درست طریقے سے پروسیس کیا جاتا ہے، اور بلاکس کو کیشے اور پتلی پول دونوں میں صحیح طریقے سے آزاد کیا جاتا ہے۔ ہمارے معاملے میں، یہ بنیادی طور پر تاخیر سے ہوتا ہے، جب اگلا سنیپ شاٹ حذف کرتے ہیں۔

BTRFS بیک اپ

کے ساتھ ریڈی میڈ اسکرپٹ استعمال کریں۔ انتہائی احتیاط اور اپنے خطرے پر. مصنف نے یہ کوڈ خود لکھا ہے اور صرف اپنے لیے۔ مجھے یقین ہے کہ بہت سے تجربہ کار لینکس صارفین کے پاس اسی طرح کے ٹولز ہیں، اور کسی اور کی کاپی کرنے کی ضرورت نہیں ہے۔

آئیے بیک اپ ڈیوائس پر ایک والیوم بنائیں:

#lvcreate -L 256G --name backup backup

آئیے اسے BTRFS میں فارمیٹ کریں:

#mkfs.btrfs /dev/backup/backup

آئیے ماؤنٹ پوائنٹس بنائیں اور فائل سسٹم کے روٹ سب سیکشن کو ماؤنٹ کریں:

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

آئیے بیک اپ کے لیے ڈائریکٹریز بنائیں:

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

آئیے بیک اپ اسکرپٹس کے لیے ایک ڈائرکٹری بنائیں:

#mkdir /root/btrfs-backup

آئیے اسکرپٹ کو کاپی کریں:

بہت سارے خوفناک بیش کوڈ۔ اپنی ذمہ داری پر استعمال کریں۔ مصنف کو ناراض خط نہ لکھیں...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF

یہ بھی کیا کرتا ہے..؟BTRFS اسنیپ شاٹس بنانے اور BTRFS بھیجنے/حاصل کرنے کا استعمال کرتے ہوئے انہیں دوسرے FS میں کاپی کرنے کے لیے سادہ کمانڈز کا ایک سیٹ پر مشتمل ہے۔

پہلی لانچ نسبتاً طویل ہو سکتی ہے، کیونکہ... شروع میں، تمام ڈیٹا کاپی کیا جائے گا. مزید لانچیں بہت تیز ہوں گی، کیونکہ... صرف تبدیلیاں کاپی کی جائیں گی۔

ایک اور اسکرپٹ جسے ہم کرون میں ڈالیں گے:

کچھ اور بیش کوڈ#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF

یہ کیا کرتا ہے..؟بیک اپ FS پر درج BTRFS والیومز کے انکریمنٹل سنیپ شاٹس بناتا اور ہم آہنگ کرتا ہے۔ اس کے بعد، یہ 60 دن پہلے بنائی گئی تمام تصاویر کو حذف کر دیتا ہے۔ لانچ کے بعد، درج شدہ جلدوں کے تاریخ کے اسنیپ شاٹس /backup/btrfs/back/remote/ ذیلی ڈائریکٹریز میں ظاہر ہوں گے۔

آئیے کوڈ پر عمل درآمد کے حقوق دیتے ہیں:

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

آئیے اسے چیک کریں اور اسے کرون میں ڈالیں:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup

LVM پتلا بیک اپ

آئیے بیک اپ ڈیوائس پر ایک پتلا پول بنائیں:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

آئیے ddrescue انسٹال کرتے ہیں، کیونکہ... اسکرپٹ اس ٹول کو استعمال کریں گے:

#apt-get install gddrescue

آئیے اسکرپٹس کے لیے ایک ڈائرکٹری بنائیں:

#mkdir /root/lvm-thin-backup

آئیے اسکرپٹس کو کاپی کریں:

اندر سے بہت سی جھڑپیں...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF

یہ کیا کرتا ہے...؟پتلی اسنیپ شاٹس میں ہیرا پھیری کرنے اور thin_delta کے ذریعے موصول ہونے والے دو پتلے اسنیپ شاٹس کے درمیان فرق کو ddrescue اور blkdiscard کا استعمال کرتے ہوئے کسی دوسرے بلاک ڈیوائس پر سنکرونائز کرنے کے لیے کمانڈز کے ایک سیٹ پر مشتمل ہے۔

ایک اور اسکرپٹ جسے ہم کرون میں ڈالیں گے:

تھوڑا سا اور بش#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF

یہ کیا کرتا ہے...؟درج کردہ پتلی جلدوں کے بیک اپ بنانے اور ہم آہنگ کرنے کے لیے پچھلی اسکرپٹ کا استعمال کرتا ہے۔ اسکرپٹ درج شدہ جلدوں کے غیر فعال سنیپ شاٹس چھوڑ دے گا، جو آخری ہم آہنگی کے بعد سے تبدیلیوں کو ٹریک کرنے کے لیے درکار ہیں۔

اس اسکرپٹ میں ترمیم کی جانی چاہیے، پتلی جلدوں کی فہرست بتاتے ہوئے جن کے لیے بیک اپ کاپیاں بنائی جانی چاہئیں۔ دیئے گئے نام صرف مثالی مقاصد کے لیے ہیں۔ اگر آپ چاہیں تو ایک اسکرپٹ لکھ سکتے ہیں جو تمام جلدوں کو ہم آہنگ کر دے گا۔

آئیے حقوق دیتے ہیں:

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

آئیے اسے چیک کریں اور اسے کرون میں ڈالیں:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

پہلی لانچ طویل ہوگی، کیونکہ... تمام استعمال شدہ جگہ کو کاپی کرکے پتلی والیوم کو مکمل طور پر ہم آہنگ کیا جائے گا۔ LVM پتلے میٹا ڈیٹا کی بدولت، ہم جانتے ہیں کہ اصل میں کون سے بلاکس استعمال میں ہیں، لہذا صرف اصل میں استعمال شدہ پتلی والیوم بلاکس ہی کاپی کیے جائیں گے۔

LVM پتلی میٹا ڈیٹا کے ذریعے ٹریکنگ کو تبدیل کرنے کی بدولت اس کے بعد کے رنز ڈیٹا کو بتدریج کاپی کریں گے۔

آئیے دیکھتے ہیں کیا ہوا:

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t

اس کا گھونسلے کی گڑیا سے کیا تعلق؟

غالباً، یہ دیکھتے ہوئے کہ LVM LV منطقی حجم دیگر VGs کے لیے LVM PV فزیکل والیوم ہو سکتا ہے۔ LVM گھونسلے کی گڑیا کی طرح تکراری ہو سکتا ہے۔ یہ LVM کو انتہائی لچک دیتا ہے۔

PS

اگلے مضمون میں، ہم ہوم ڈیسک ٹاپس، ہوم انٹرنیٹ اور P2P نیٹ ورکس کا استعمال کرتے ہوئے کئی براعظموں میں فالتو پن کے ساتھ جیو ڈسٹری بیوٹڈ اسٹوریج/vm کلسٹر بنانے کی بنیاد کے طور پر بہت سے ملتے جلتے موبائل اسٹوریج سسٹمز/KVM کو استعمال کرنے کی کوشش کریں گے۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں