VPS storage کے لیے RAID 10 کیا ہے؟

RAID 10 کیا ہے، اور VPS hosts اسے کیوں چلاتے ہیں

RAID 10 وہ storage layout ہے جسے زیادہ تر VPS hosts virtualised NVMe (non-volatile memory express) drives کے تحت چلاتے ہیں۔ یہ ہر drive کی ایک copy اس کے partner پر بناتا ہے، پھر ان mirrored pairs میں data stripe کرتا ہے۔ ایک drive خراب ہو جائے تو array بند نہیں ہوتا، اور repair surviving partner سے سادہ copy کے ذریعے ہوتی ہے، نہ کہ ایسی recalculation کے ذریعے جس میں set کی ہر دوسری drive پڑھی جائے۔

RAID کا مطلب redundant array of independent disks ہے۔ اس کا ایک ہی کام ہے: disk کے خراب یا replace کیے جانے کے دوران machine کو service فراہم کرتے رہنے دینا۔ یہ availability ہے، اور availability safety نہیں ہے۔

RAID آپ کی writes replicate کرتا ہے۔ rm -rf /srv ایک write ہے۔ Mirror کے دونوں halves اسی millisecond میں directory حذف کر دیتے ہیں، اور اس کے بعد بھی array خود کو clean report کرتا ہے۔

یہ جملہ یاد رکھیں۔ اس page کا باقی حصہ بتاتا ہے کہ ہر level کن خرابیوں کے باوجود کام کرتا رہتا ہے اور ہر write پر اس کی کیا لاگت آتی ہے۔ آخری sections میں ان commands کی وضاحت ہے جن سے آپ اپنی ملکیت والی machine پر array کا status پڑھ سکتے ہیں، اور اس failure کی بھی جس سے RAID نے کبھی تحفظ نہیں دیا۔

ہوسٹنگ خریدار کو عملاً نظر آنے والی سطحیں: 1، 5، 6 اور 10

پلان کا صفحہ ایک نمبر لکھ کر رک جاتا ہے۔ یہ نمبر دو سوالوں کا جواب دیتا ہے: کتنی drives ناکام ہو سکتی ہیں، اور ہر write کی لاگت کیا ہے۔

RAID 1 ایک mirror ہے۔ دو drives میں یکساں blocks موجود ہوتے ہیں۔ ہر write دونوں drives پر جاتی ہے۔ کوئی بھی drive read فراہم کر سکتی ہے۔ ایک drive ناکام ہو جائے تو data loss نہیں ہوتا، اور raw capacity کا نصف قابل استعمال رہتا ہے۔ parity calculate نہیں کرنی پڑتی، اس لیے write path مختصر ہوتا ہے۔

RAID 5 میں ہر stripe کے لیے ایک parity block کے ساتھ striping ہوتی ہے۔ n drives کے ساتھ آپ کو n-1 drives کے برابر capacity ملتی ہے، اور array بالکل ایک failure برداشت کر سکتا ہے۔ parity کسی ایک dedicated drive پر نہیں رہتی۔ یہ تمام drives کے درمیان گردش کرتی ہے، اس لیے ہر drive میں data اور parity دونوں ہوتے ہیں۔

RAID 6 ہر stripe میں ایک اضافی، آزاد parity block شامل کرتا ہے، جسے عموماً P اور Q لکھا جاتا ہے۔ یہ بیک وقت کسی بھی دو drives کی ناکامی برداشت کر سکتا ہے۔ یہ اہمیت میں بظاہر جتنا لگتا ہے اس سے زیادہ اہم ہے، کیونکہ دوسری ناکامی اکثر پہلی drive کی repair کے دوران ہوتی ہے۔

RAID 10 mirrors کا ایک stripe ہے۔ drives کو جوڑوں میں mirror کیا جاتا ہے، اور data ان جوڑوں کے درمیان تقسیم کیا جاتا ہے۔ قابل استعمال capacity raw total کا نصف ہوتی ہے، جو RAID 1 کے برابر ہے، جبکہ اس کے ساتھ striping کی parallelism بھی ملتی ہے۔

آپ اسے RAID 1+0 کے طور پر بھی دیکھیں گے، جو درست وضاحت ہے: پہلے mirror، پھر mirrors کے درمیان stripe۔ RAID 0+1 اس کی الٹ ترتیب ہے: پہلے stripe، پھر دونوں stripes کا mirror۔ یہ کم بہتر ہے، کیونکہ ایک drive کی ناکامی سے ایک پوری stripe سروس سے باہر ہو جاتی ہے اور repair کے لیے دوسرے پورے حصے کو copy کرنا پڑتا ہے۔

Linux ایک ایسا خاص معاملہ ہے جسے جاننا مفید ہے۔ kernel کا raid10 دو تہہ دار layers کے بجائے ایک single personality ہے، اس لیے یہ drives کی طاق تعداد پر چل سکتا ہے اور اس میں ایسے layouts (near، far، offset) موجود ہیں جنہیں nested setup بیان نہیں کر سکتا۔ اسی لیے Linux box کی status line دو arrays کے نام دینے کے بجائے 2 near-copies دکھاتی ہے۔

[
  {
    "label": "RAID 1 (four mirrored pairs)",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  },
  {
    "label": "RAID 5",
    "usable_tb": 7,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 1
  },
  {
    "label": "RAID 6",
    "usable_tb": 6,
    "worst_case_drives_lost": 2,
    "best_case_drives_lost": 2
  },
  {
    "label": "RAID 10",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  }
]

آٹھ 1 TB drives سے RAID 5 کے تحت 7 TB اور RAID 10 کے تحت 4 TB قابل استعمال جگہ ملتی ہے۔ یہ فرق حقیقی مالی لاگت رکھتا ہے، اور اسی لیے parity بار بار تجویز کی جاتی ہے۔ RAID 6 کسی بھی pattern میں 2 failures برداشت کر سکتا ہے۔ RAID 10 صرف 1 کی ضمانت دیتا ہے، کیونکہ خطرناک دوسری failure اس drive کے partner پر ہوتی ہے جو پہلے ہی ناکام ہو چکی ہو۔ جب کوئی دو failures ایک ہی pair میں نہ ہوں تو یہ زیادہ سے زیادہ 4 failures برداشت کر سکتا ہے، لیکن یہ design property کے بجائے محض اتفاق ہے۔

ہر write پر ہر level کی لاگت

Mirror پر write دراصل دو writes ہوتی ہیں، جو دونوں members کو بیک وقت بھیجی جاتی ہیں۔ Parity stripe پر write زیادہ کام کرتی ہے، کیونکہ اس stripe کا parity block اب غلط ہو جاتا ہے اور اسے دوبارہ compute کرنا پڑتا ہے۔

Controller صرف نئے block سے parity دوبارہ compute نہیں کر سکتا۔ اسے پہلے پرانا data block اور پرانا parity block درکار ہوتا ہے۔ اسی لیے RAID 5 پر ایک چھوٹی random write کا سلسلہ read، read، write، write بن جاتا ہے۔ RAID 6 میں برقرار رکھنے کے لیے دوسرا syndrome بھی ہوتا ہے، اس لیے یہی write read، read، read، write، write، write بن جاتی ہے۔

[
  {
    "label": "RAID 1 (2 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  },
  {
    "label": "RAID 5 (8 drives)",
    "write_ops_per_host_write": 4,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 6 (8 drives)",
    "write_ops_per_host_write": 6,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 10 (8 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

RAID 6 پر ایک چھوٹی random write کی لاگت 6 device operations اور RAID 10 پر 2 device operations ہوتی ہے۔ یہ تعداد latency کے فرق کو کم ظاہر کرتی ہے۔ دونوں mirror writes متوازی طور پر بھیجی جاتی ہیں، اس لیے guest کو دونوں میں سے سست write کا انتظار کرنا پڑتا ہے۔ Parity path میں ایک read شامل ہوتی ہے جو نیا parity compute کرنے سے پہلے مکمل ہونی چاہیے، اس لیے guest پہلے read اور پھر write کا مسلسل انتظار کرتا ہے۔ مصروف host پر یہ read دوسرے تمام users کے I/O کے پیچھے queue میں چلی جاتی ہے۔

اس میں ایک اہم استثنا ہے۔ جو write پوری stripe بھرنے کے لیے کافی بڑی ہو، اسے پرانے data کی ضرورت نہیں ہوتی، کیونکہ stripe کا ہر block تبدیل کیا جا رہا ہوتا ہے۔ Parity پہلے سے memory میں موجود data سے compute کی جاتی ہے، اور لاگت ایک اضافی write تک کم ہو جاتی ہے۔ اسی لیے RAID 5 sequential benchmark میں ٹھیک دکھائی دیتا ہے، لیکن متعدد tenants کی چھوٹی writes کے mixed load میں خراب کارکردگی دیتا ہے۔ وہی pattern test کریں جو آپ حقیقت میں چلاتے ہیں: VPS disk کی درست benchmarking کا مطلب realistic queue depth پر random I/O ہے، نہ کہ ایک بڑی dd۔

تعمیر نو تعمیر کا خطرناک مرحلہ کیوں ہے

Parity rebuild کو باقی تمام drives سے missing drive دوبارہ تشکیل دینی ہوتی ہے، اس لیے یہ پہلے block سے آخری block تک 7 surviving drives پڑھتی ہے۔ RAID 10 rebuild صرف 1 پڑھتی ہے: dead drive کا mirror partner، اور کچھ نہیں۔

اس کے نتیجے میں دو اخراجات سامنے آتے ہیں۔ پہلا وقت ہے، کیونکہ rebuild کی رفتار سب سے سست surviving drive اور اس کے علاوہ parity calculations سے محدود ہوتی ہے۔ دوسرا load ہے۔ Parity set کی ہر drive پورے rebuild window کے دوران مصروف رہتی ہے، اس لیے اس node پر موجود ہر guest کو rebuild مکمل ہونے تک زیادہ latency محسوس ہوتی ہے۔ RAID 10 میں صرف ایک pair مصروف ہوتا ہے، جبکہ دوسرے pairs معمول کی رفتار سے سروس دیتے ہیں۔

اسی window کے دوران data correctness کا خطرہ بھی موجود ہوتا ہے۔ ایک dead drive والے RAID 5 array میں کوئی redundancy باقی نہیں رہتی، اس لیے surviving drive پر کہیں بھی unreadable sector اب recover نہیں ہو سکتا۔ Rebuild وہ واحد operation ہے جو ہر sector پڑھتی ہے، ان sectors کو بھی جنہیں ایک سال سے کسی نے استعمال نہیں کیا۔ شائع شدہ datasheet figures کے مطابق consumer hard drive میں پڑھے گئے ہر 10^14 bits پر تقریباً ایک unrecoverable read error ہو سکتا ہے، جبکہ enterprise NVMe drive میں یہ شرح ہر 10^17 bits یا اس سے بہتر ہے۔ یہ vendor specifications ہیں، measurements نہیں، لیکن یہ ratio واضح کرتا ہے کہ RAID 5 rebuild کے fail ہونے کی پرانی warning بڑی spinning disks کے بارے میں کیوں لکھی گئی تھی، اور NVMe پر یہ warning بہت کم متعلقہ کیوں ہے۔ Load کا یہ مسئلہ ہر medium پر برقرار رہتا ہے۔

Rebuild سے پہلے latent errors تلاش کرنے کے لیے scrubbing کریں۔ Debian اور Ubuntu، md arrays کے لیے periodic scrub فراہم کرتے ہیں، لیکن mechanism releases کے درمیان مختلف ہوتا ہے۔ اس لیے پہلے معلوم کریں کہ آپ کے پاس کون سا mechanism موجود ہے، پھر ہاتھ سے ایک pass trigger کریں۔

systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt

Pass مکمل ہونے پر sync_action واپس idle ہو جاتا ہے، اور mismatch_cnt کو 0 پڑھنا چاہیے۔ Mirror پر zero سے زیادہ number کا مطلب ہے کہ دونوں halves میں اختلاف ہے اور kernel یہ نہیں بتا سکتا کہ کون سی copy درست ہے، کیونکہ دونوں copies میں checksum موجود نہیں ہوتا۔ کچھ mismatches بے ضرر ہوتے ہیں، اور swap partitions اس کی عام وجہ ہیں: kernel ممکن ہے ایسا page لکھے جو اسی دوران تبدیل ہو جائے۔ Data array پر بڑھتا ہوا count اس drive کو replace کرنے کا اشارہ ہے۔

NVMe کے لیے VPS فراہم کنندگان RAID 10 کو معیاری کیوں بناتے ہیں

ایک hypervisor node صرف ایک workload نہیں چلاتا۔ یہ درجنوں غیر متعلقہ guests چلاتا ہے، اور ان کی I/O ایک دوسرے میں ملی ہوئی چھوٹی writes کے stream کی صورت میں آتی ہے، جن کے درمیان کوئی locality نہیں ہوتی۔ یہی وہ pattern ہے جس میں parity کا read-modify-write cycle سب سے زیادہ لاگت پیدا کرتا ہے، اور shared node پر یہ pattern پورا دن موجود رہتا ہے۔

Rebuild کا رویہ بھی شامل کریں تو انتخاب واضح ہو جاتا ہے۔ parity node پر drive ناکام ہونے سے اس box کے ہر guest کی رفتار کئی گھنٹوں تک کم ہو جاتی ہے۔ RAID 10 node پر drive ناکام ہونے سے صرف ایک pair متاثر ہوتا ہے، اور copy drive کی رفتار سے sequentially چلتی ہے۔ Providers ایسی latency فروخت کر رہے ہیں جو اچانک نہیں بڑھتی، اس لیے وہ capacity کے ذریعے اس کی قیمت ادا کرتے ہیں: raw NVMe کا نصف mirror کے لیے مختص ہو جاتا ہے۔

Drive sizes بھی اسی سمت اثر ڈالتی ہیں۔ Drives جتنی بڑی ہوں، rebuild window اتنی طویل ہوتی ہے، اور parity میں یہی وہ مدت ہوتی ہے جس کے دوران ہر چیز سست ہوتی ہے اور کوئی چیز محفوظ نہیں ہوتی۔ یہی وجہ ہے کہ virtualisation کے لیے ZFS deployments میں wide raidz کے بجائے mirrored vdevs کے pools استعمال کیے جاتے ہیں: mirror resilver صرف زیرِ استعمال blocks کو ایک pair پر copy کرتا ہے۔

اس کا مطلب یہ نہیں کہ ہر جگہ RAID 10 ہی درست انتخاب ہے۔ Backup target پر طویل sequential runs میں writes ہوتی ہیں اور اسے کم ہی read کیا جاتا ہے، اس لیے وہاں RAID 6 بہتر انتخاب ہے۔ یہ دو failures برداشت کرتا ہے اور زیادہ تر capacity واپس فراہم کرتا ہے۔ فیصلہ workload کرتا ہے، تعداد نہیں۔ آج جس plan کا انتخاب کرنا ہو، اس میں عموماً اوپر کے layout سے زیادہ medium اہم ہوتا ہے، اور SATA SSD سے NVMe تک کی چھلانگ دونوں میں RAID کے کسی بھی فرق سے بڑی ہوتی ہے۔

/proc/mdstat کو کیسے پڑھیں

یہ کمانڈز ایسی مشین پر چلائیں جس کے array کے آپ مالک ہوں: dedicated server، گھر کا box، یا ایسا VPS جس میں آپ نے خود دو attached volumes assemble کیے ہوں۔ اپنا output پڑھیں۔ نیچے دیے گئے blocks مثالیں ہیں، تاکہ آپ اپنے output کی ساخت سے مطابقت کر سکیں۔

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

صحت مند چار-drive RAID 10 عموماً اس سے ملتا جلتا output دیتا ہے۔

Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

اس کی ہر تفصیل معلومات فراہم کرتی ہے۔

• Personalities ان md modules کی فہرست دیتا ہے جو running kernel نے load کیے ہیں۔ وہاں raid10 کا ظاہر ہونا صرف یہ بتاتا ہے کہ code available ہے، اس سے زیادہ کچھ نہیں۔
• md0 : active raid10 array device، اس کی state اور اس کا level بتاتا ہے۔
• اس کے بعد آنے والے نام members کے ہیں۔ square brackets میں موجود number array metadata میں device کا index ہے؛ یہ line پر اس کی position نہیں، اور ہمیشہ اس کا slot بھی نہیں ہوتا۔
• drive replacement کے بعد نیا member عموماً اس slot سے زیادہ index رکھتا ہے جسے وہ fill کرتا ہے، اس لیے nvme4n1p3[4] slot 2 میں موجود ہو سکتا ہے۔ mdadm --detail اپنے RaidDevice column میں حقیقی slot دکھاتا ہے، اس لیے فرق اہم ہو تو اسی کو استعمال کریں۔
• member کے بعد (F) کا مطلب faulty ہے۔ (S) کا مطلب spare ہے: موجود، idle، اور کسی failure کا انتظار کر رہا ہے۔
• 3906764800 blocks super 1.2 usable size کو 1 KiB blocks میں، پھر metadata format دکھاتا ہے۔
• 512K chunks 2 near-copies stripe chunk size اور RAID 10 layout بتاتا ہے۔ یہاں ہر block کی دو copies ایک دوسرے کے ساتھ رکھی جاتی ہیں۔
• [4/4] پہلے array کے متوقع members کی تعداد، پھر اس وقت sync میں موجود members کی تعداد بتاتا ہے۔
• [UUUU] slot order میں ہر slot کے لیے ایک character دکھاتا ہے۔ U ایسا slot ہے جو up اور sync میں ہے۔ _ ایسا slot ہے جس میں کوئی working device نہیں۔
• bitmap: write intent bitmap ہے۔ یہ ان regions کو record کرتا ہے جن پر write جاری تھی، تاکہ باہر ہونے والا member واپس آنے پر پوری drive کے بجائے صرف انہی regions کو resync کرے۔

جب کوئی خرابی ہو تو [4/3] اور [UU_U] کا مطلب

degraded array اس طرح دکھائی دیتا ہے۔

md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]

دونوں brackets کو ایک ساتھ پڑھیں۔ [4/3] بتاتا ہے کہ چار slots میں سے ایک contribution نہیں دے رہا۔ [UU_U] بتاتا ہے کہ کون سا slot ہے، کیونکہ underscore تیسرا character ہے اور slots کی numbering zero سے شروع ہوتی ہے؛ اس لیے slot 2 down ہے۔ (F) flag صرف اس وقت device کا نام دکھاتا ہے جب failed drive ابھی attached ہو۔ اسے machine سے نکالنے پر یہ نام line سے غائب ہو جاتا ہے، جبکہ underscore برقرار رہتا ہے۔

array اس حالت میں بھی service فراہم کرتا رہتا ہے۔ RAID 10 میں یہ اکثر تقریباً full speed پر service دیتا ہے، اسی لیے محسوس کر کے خرابی کا پتا نہیں چلتا۔ آپ کو کوئی monitoring mechanism چاہیے۔

grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i md

mdadm package ایک monitor daemon install کرتا ہے جو /etc/mdadm/mdadm.conf سے MAILADDR پڑھتا ہے۔ unit name releases کے درمیان تبدیل ہو چکا ہے، اس لیے اندازہ لگانے کے بجائے اسے آخری command سے تلاش کریں۔ --test command ہر array کے لیے فوراً ایک message بھیجتی ہے۔ اگر اس کے بعد inbox خالی ہو تو mail path broken ہے، اور جس message کی آپ کو واقعی ضرورت ہے وہ بھی اسی طرح ضائع ہو جاتا۔

جب replacement drive rebuild ہو رہی ہو تو array کے نیچے progress line ظاہر ہوتی ہے۔

md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [==>..................]  recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/sec

recovery replacement drive پر rebuild ہے۔ resync نئے بنائے گئے array پر پہلی consistency pass ہے۔ check وہ scrub ہے جسے آپ نے اوپر trigger کیا تھا۔ parentheses میں موجود جوڑا 1 KiB blocks میں progress کو per-device total کے مقابل دکھاتا ہے، اور finish موجودہ speed پر kernel کا estimate ہے۔ اس speed کو /proc/sys/dev/raid/speed_limit_min اور speed_limit_max limit کرتے ہیں۔ یہ limits اس لیے موجود ہیں تاکہ rebuild production I/O کو starve نہ کرے۔

/dev/md0:
           Version : 1.2
     Creation Time : Tue Mar 10 09:14:22 2026
        Raid Level : raid10
        Array Size : 3906764800 (3.64 TiB 4.00 TB)
     Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Wed Aug  5 11:02:41 2026
             State : clean, degraded, recovering
    Active Devices : 3
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 1

            Layout : near=2
        Chunk Size : 512K

    Rebuild Status : 12% complete

              Name : storage:0
            Events : 4184

    Number   Major   Minor   RaidDevice State
       0     259        3        0      active sync set-A   /dev/nvme0n1p3
       1     259        7        1      active sync set-B   /dev/nvme1n1p3
       4     259       11        2      spare rebuilding    /dev/nvme4n1p3
       3     259       15        3      active sync set-B   /dev/nvme3n1p3

اپنے array پر drive replace کرنا چار commands کا عمل ہے، اور آخری command verification کے لیے ہے۔

sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat

recovery line ایک یا دو seconds کے اندر ظاہر ہو جانی چاہیے۔ replacement partition کم از کم mdadm --detail کے Used Dev Size جتنی بڑی ہونی چاہیے۔ اس سے معمولی سی چھوٹی partition not large enough to join array جیسی message کے ساتھ reject ہو جاتی ہے۔ نئی drive کو add کرنے سے پہلے اسے پرانی drive کے مطابق partition کریں۔

VPS کے اندر سے آپ کیا دیکھ سکتے ہیں اور کیا نہیں دیکھ سکتے

زیادہ تر guest host کا RAID نہیں دیکھ سکتے، اور یہ ڈیزائن کا حصہ ہے۔ hypervisor آپ کو ایک virtual disk فراہم کرتا ہے۔ یہ disk NVMe drives کے RAID 10 pool سے بنی ہے یا ایک ہی drive پر موجود ہے، یہ host کی خصوصیت ہے اور guest کے اندر ظاہر نہیں ہوتی۔

systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstat

systemd-detect-virt ایک KVM guest پر kvm، container پر lxc جیسی container type، اور bare metal پر none دکھاتا ہے۔ KVM guest پر عموماً lsblk میں ایک واحد vda یا sda نظر آتا ہے، اور /proc/mdstat میں کوئی arrays نہیں ہوتیں، کیونکہ guest کے اندر کوئی arrays موجود نہیں ہوتیں۔

container-based VPS پر یہ output قابلِ اعتماد نہیں ہوتا۔ Containers host kernel کا اشتراک کرتے ہیں، اور /proc کے کچھ حصے namespace کے ذریعے الگ نہیں کیے جاتے۔ اس لیے وہاں نظر آنے والی معلومات آپ کے حصے کے بجائے host کی وضاحت کر سکتی ہیں۔ ان معلومات میں سے کسی کو بھی اپنی storage کے بارے میں حتمی حقیقت نہ سمجھیں۔ Provider سے layout کے بارے میں پوچھیں، اور اگر یہ معاملہ آپ کے لیے اہم ہے تو جواب تحریری شکل میں حاصل کریں۔

آپ اندر سے دی گئی disk کا رویہ جانچ سکتے ہیں۔ یہ جانچنا کہ آیا آپ کی VPS disk واقعی NVMe ہے میں وہ commands شامل ہیں جو حقیقی معلومات فراہم کرتی ہیں، جبکہ SSD VPS میں حقیقتاً کیا شامل ہوتا ہے میں بتایا گیا ہے کہ plan page پر موجود label کا دعویٰ کیا ہے۔

کیا آپ کو اپنے VPS کے اندر RAID چلانا چاہیے؟

عام طور پر نہیں، اور اس کی وجہ failure domains ہیں۔ اگر آپ ایک VPS کے ساتھ دو volumes منسلک کر کے انہیں mdadm کے ذریعے mirror کریں، تو ممکن ہے کہ دونوں volumes ایک ہی physical array، ایک ہی node اور ایک ہی power supply کے پیچھے موجود ہوں۔ آپ redundancy کے لیے ہر write کی لاگت دوگنی کریں گے، حالانکہ یہ redundancy پہلے ہی دستیاب تھی، اور پھر بھی اس واحد failure کی صورت میں دونوں copies کھو دیں گے جو واقعی اہم ہے۔

یہ اقدام اس وقت مفید ہے جب provider دستاویزات میں واضح کرے کہ volumes الگ failure domains میں موجود ہیں، یا جب آپ dedicated server استعمال کر رہے ہوں جس کی drives پر آپ خود RAID لاگو کر سکیں۔ بصورت دیگر، یہ کوشش ایسی copies بنانے پر صرف کرنا زیادہ مفید ہے جو machine سے باہر موجود ہوں۔

RAID آپ کو کن چیزوں سے محفوظ نہیں رکھتا

RAID صرف ایک واقعے سے نمٹتا ہے: ایسی drive جو درست طور پر کام کرنا بند کر دے۔ ذیل کی ہر کارروائی ایک درست write ہے، اس لیے array اسے ہر copy پر لاگو کرتا ہے اور خود کو healthy ظاہر کرتا ہے۔

• حذف ہونا۔ غلط directory میں rm -rf، یا path میں unset variable والی deploy script۔ array اسے ایک جائز write سمجھتا ہے اور یہ کارروائی دو مرتبہ کرتا ہے۔
• Ransomware۔ Encryption بھی writing ہے۔ ایک healthy array encrypted version کو mirror کے دونوں حصوں پر محفوظ کرتا ہے۔
• خراب application۔ database میں garbage لکھنے والا bug وہی garbage redundant drive پر بھی لکھ دیتا ہے۔
• پورا node۔ ایسا host جو fail ہو جائے، یا ایسا account جسے غلطی سے suspend کر دیا جائے۔ array بالکل درست بھی ہو سکتا ہے اور اسی وقت ناقابل رسائی بھی۔
• آپ خود، ایک ہفتے بعد۔ پیر کو حذف کی گئی file پیر ہی کو ہر drive سے ختم ہو جاتی ہے۔ صرف اس سے پہلے بنائی گئی copy ہی اسے واپس لا سکتی ہے۔

اسی storage پر موجود snapshots بھی حل نہیں ہیں۔ یہ deletion کے خلاف مدد دیتے ہیں، لیکن جس array پر رہتے ہیں اسی کے ساتھ ختم ہو جاتے ہیں۔ backup کو backup بنانے والی خصوصیت یہ ہے کہ وہ کسی اور جگہ موجود ہو۔ سرور سے باہر encrypted backups with restic اس صفحے کا دوسرا حصہ ہے: array dead drive کے باوجود سروس جاری رکھتا ہے، اور restic اس وقت آپ کا data واپس لاتا ہے جب نقصان ایسی write کی وجہ سے ہوا ہو جسے array نے بلا جھجھک قبول کیا تھا۔

FAQ

کیا RAID 10 کا مطلب ہے کہ مجھے backups کی ضرورت نہیں؟

نہیں۔ RAID 10 اس drive کے خلاف تحفظ فراہم کرتا ہے جو کام کرنا بند کر دے۔ یہ ہر درست write کو mirror کے دونوں حصوں پر لاگو کرتا ہے، اس لیے deletion یا ransomware کا run اسی لمحے redundant drive تک بھی پہنچ جاتا ہے۔ اس کے بعد array خود کو clean ظاہر کرتا ہے، کیونکہ اس کے نقطۂ نظر سے کچھ ناکام نہیں ہوا۔ آپ کو اب بھی ایسی copies درکار ہیں جو machine سے باہر محفوظ ہوں، اور کبھی کبھار ایک copy restore کر کے یہ ثابت کرنا بھی ضروری ہے کہ وہ کام کرتی ہے۔

VPS providers، RAID 5 یا RAID 6 کے بجائے RAID 10 کیوں منتخب کرتے ہیں؟

اس کی دو وجوہات ہیں، اور دونوں کا تعلق small random writes سے ہے۔ parity write کے لیے نئی parity calculate کرنے سے پہلے پرانا data اور پرانی parity دوبارہ read کرنا پڑتی ہے۔ اس لیے RAID 5 پر ایک small write کی لاگت 4 operations اور RAID 6 پر 6 operations ہوتی ہے، جبکہ mirror پر یہ لاگت 2 operations ہے۔ parity rebuild کے دوران ہر surviving drive کو ابتدا سے انتہا تک read کرنا پڑتا ہے۔ اس سے node پر موجود ہر guest کئی گھنٹوں تک سست ہو جاتا ہے۔ اس کے برعکس RAID 10 rebuild میں ایک drive کا data دوسری drive پر copy ہوتا ہے اور باقی pairs متاثر نہیں ہوتے۔ Providers اس کا معاوضہ capacity سے ادا کرتے ہیں: raw NVMe کا نصف۔

/proc/mdstat میں [U_] یا [UU_U] کا کیا مطلب ہے؟

ہر character array کے ایک slot کی نمائندگی کرتا ہے۔ یہ slots ترتیب کے مطابق دکھائے جاتے ہیں اور ہر slot کے لیے ایک character ہوتا ہے۔ U کا مطلب ہے کہ اس slot میں موجود member up اور in sync ہے۔ _ کا مطلب ہے کہ اس slot میں کچھ بھی فعال نہیں ہے۔ دو-drive mirror میں [U_] کا مطلب ہے کہ دوسرا slot down ہے اور redundancy باقی نہیں رہی۔ اسے اس سے پہلے موجود pair کے ساتھ پڑھیں، جہاں [4/3] بتاتا ہے کہ array کو چار members درکار ہیں اور اس وقت تین موجود ہیں۔ Slot order، mdadm --detail کے RaidDevice column کے مطابق ہوتا ہے، نہ کہ اس ترتیب کے مطابق جس میں device names اس line پر ظاہر ہوتے ہیں۔

RAID 10 array کتنی drives کھو سکتا ہے؟

کسی بھی pattern میں ایک drive۔ اس سے زیادہ failures کی صورت میں نتیجہ اس بات پر منحصر ہوتا ہے کہ failures کہاں واقع ہوئے ہیں۔ ہر mirror pair اپنے دو members میں سے ایک کو کھو سکتا ہے۔ اس لیے آٹھ-drive array اس وقت تک چار failures برداشت کر سکتا ہے جب کسی دو failures کا تعلق ایک ہی pair سے نہ ہو۔ اگر دونوں failures ایک ہی pair میں ہوں تو array دو failures پر ناکام ہو جاتا ہے۔ منصوبہ بندی guaranteed تعداد، یعنی ایک failure، کے مطابق کریں۔ اس سے زیادہ کو protection نہیں بلکہ اتفاق سمجھیں۔

کیا مجھے اپنے VPS کے اندر mdadm سے دو volumes کو mirror کرنا چاہیے؟

عام طور پر نہیں۔ ایک VPS سے منسلک دو volumes اکثر اسی host پر موجود ایک ہی physical array میں رہتے ہیں۔ اس لیے mirroring ہر write کی لاگت دوگنی کر دیتی ہے اور ایسے کسی failure سے تحفظ نہیں دیتی جس سے host کا اپنا RAID پہلے ہی تحفظ نہ دے رہا ہو۔ یہ صرف اس وقت مفید ہے جب provider دستاویز میں تصدیق کرے کہ volumes الگ failure domains میں موجود ہیں۔ بصورت دیگر یہ کوشش ایسی backups پر صرف کریں جو machine سے باہر محفوظ ہوں۔