VPS স্টোরেজে RAID 10 কী এবং কেন ব্যবহৃত হয়

RAID 10 কী এবং VPS host-গুলো কেন এটি ব্যবহার করে

ভার্চুয়ালাইজড NVMe (non-volatile memory express) drive-এর নিচে অধিকাংশ VPS host যে storage layout ব্যবহার করে, সেটি হলো RAID 10। প্রচলিত two-copy layout-এ প্রতিটি drive-এর একটি করে partner-এ mirror তৈরি করা হয়। এরপর ওই mirrored pair-গুলোর মধ্যে data stripe করা হয়। একটি drive নষ্ট হলেও array বন্ধ হয় না। মেরামতের সময় set-এর অন্য সব drive পড়ে recalculation করার বদলে, সচল partner থেকে সরাসরি copy করা হয়।

RAID-এর অর্থ হলো redundant array of independent disks। এর একমাত্র কাজ হলো কোনো disk নষ্ট হলে বা বদলানোর সময় machine-কে service চালু রাখতে সাহায্য করা। এটি availability-এর বিষয়। Availability নিরাপত্তা নয়।

RAID আপনার write-এর প্রতিলিপি তৈরি করে। rm -rf /srv একটি write। mirror-এর উভয় half একই millisecond-এ directory-টি মুছে ফেলে, তবুও পরে array নিজেকে clean হিসেবে report করে।

এই বাক্যটি মনে রাখুন। এই পৃষ্ঠার বাকি অংশে প্রতিটি level কোন ধরনের failure সামলাতে পারে এবং প্রতিটি write-এর জন্য তার কী খরচ হয়, তা ব্যাখ্যা করা হয়েছে। শেষের section-গুলোতে আপনার মালিকানাধীন machine-এ array-এর status দেখার command এবং RAID যে failure কখনো সামলাতে পারে না, তা দেখানো হয়েছে।

হোস্টিং ক্রেতারা বাস্তবে যে স্তরগুলোর মুখোমুখি হন: 1, 5, 6 এবং 10

একটি plan page-এ একটি সংখ্যা লেখা থাকে এবং সেখানেই ব্যাখ্যা শেষ হয়। এই সংখ্যা দুটি প্রশ্নের উত্তর দেয়: কতগুলো drive নষ্ট হতে পারে, এবং প্রতিটি write-এর জন্য কী খরচ হয়।

RAID 1 হলো একটি mirror। দুটি drive-এ অভিন্ন block থাকে। প্রতিটি write উভয় drive-এ যায়। যেকোনো একটি drive read পরিবেশন করতে পারে। একটি drive নষ্ট হলেও data loss হয় না, এবং raw capacity-এর অর্ধেক ব্যবহারযোগ্য থাকে। কোনো parity গণনা করতে হয় না, তাই write path সংক্ষিপ্ত।

RAID 5 হলো প্রতি stripe-এ একটি parity block-সহ striping। nটি drive থাকলে n-1টি drive-এর সমান capacity পাওয়া যায়, এবং array ঠিক একটি drive failure সহ্য করতে পারে। Parity কোনো একটি dedicated drive-এ থাকে না। এটি সব drive-এর মধ্যে ঘুরে ঘুরে বিতরণ হয়, তাই প্রতিটি drive-এ data এবং parity দুটোই থাকে।

RAID 6 প্রতিটি stripe-এ দ্বিতীয়, স্বাধীন parity block যোগ করে, যেগুলো সাধারণত P এবং Q নামে লেখা হয়। একই সময়ে যেকোনো দুটি drive নষ্ট হলেও এটি টিকে থাকে। এর গুরুত্ব ধারণার চেয়ে বেশি, কারণ প্রথম drive repair করার সময়ই দ্বিতীয় failure সবচেয়ে বেশি ঘটে।

RAID 10 হলো mirror-গুলোর একটি stripe। Drive-গুলো জোড়ায় জোড়ায় mirror করা হয়, এবং data জোড়াগুলোর মধ্যে ছড়িয়ে দেওয়া হয়। Usable capacity raw total-এর অর্ধেক, RAID 1-এর মতোই, তবে এর সঙ্গে striping-এর parallelism যুক্ত থাকে।

এটিকে RAID 1+0 হিসেবেও লেখা হয়, যা সঠিক বর্ণনা: প্রথমে mirror, তারপর mirror-গুলোর মধ্যে stripe। RAID 0+1 হলো বিপরীত ক্রম—প্রথমে stripe, তারপর দুটি stripe mirror করা। এটি খারাপ, কারণ একটি drive failure পুরো একটি stripe-কে service-এর বাইরে নিয়ে যায় এবং repair-এর সময় অন্য পুরো পাশটি copy করতে হয়।

Linux একটি আলাদা বিষয়, যা জানা দরকার। Kernel-এর raid10 দুটি স্তর পরপর বসানো কোনো কাঠামো নয়; এটি একটি একক personality। তাই এটি বিজোড় সংখ্যক drive-এ চলতে পারে এবং এর এমন layout (near, far, offset) আছে, যা nested setup দিয়ে প্রকাশ করা যায় না। এ কারণেই Linux box-এর status line-এ দুটি array-এর নাম না দিয়ে 2 near-copies লেখা থাকে।

[
  {
    "label": "RAID 1 (eight copies)",
    "usable_tb": 1,
    "worst_case_drives_lost": 7,
    "best_case_drives_lost": 7
  },
  {
    "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 drive ব্যবহার করলে RAID 5-এ 7 TB এবং RAID 10-এ 4 TB usable space পাওয়া যায়। এই পার্থক্য বাস্তব অর্থের; এ কারণেই parity বারবার প্রস্তাব করা হয়। RAID 6 যেকোনো বিন্যাসে 2টি failure সহ্য করে। RAID 10 কেবল 1টি failure নিশ্চিতভাবে সহ্য করে, কারণ বিপজ্জনক দ্বিতীয় failure হলো ইতিমধ্যে নষ্ট হওয়া drive-এর জোড়ার drive-এ হওয়া failure। কোনো দুটি failure একই জোড়ায় না পড়লে এটি সর্বোচ্চ 4টি failure সহ্য করতে পারে; এটি design property নয়, বরং ভাগ্য।

প্রতিটি write-এ প্রতিটি level-এর খরচ

একটি mirror-এ write করলে একই সময়ে উভয় member-এ দুটি write পাঠানো হয়। একটি parity stripe-এ write করা বেশি কাজের, কারণ ওই stripe-এর parity block আর সঠিক থাকে না এবং সেটি পুনর্গণনা করতে হয়।

read-modify-write-এর ক্ষেত্রে controller প্রথমে পুরোনো data এবং পুরোনো parity পড়ে। তাই cache-বিহীন single-block overwrite RAID 5-এ read, read, write, write-এ পরিণত হয়। RAID 6 দুটি parity block বজায় রাখে, তাই read-modify-write হয়ে যায় read, read, read, write, write, write। Linux parity গণনার জন্য অপরিবর্তিত data পড়ে reconstruct-write-ও ব্যবহার করে। তিনটি drive-এর RAID 5-এ ওই overwrite-এ একটি data read এবং দুটি write লাগতে পারে; চারটি drive-এর RAID 6-এ একটি data read এবং তিনটি write লাগতে পারে। Four এবং six হলো read-modify-write-এর operation count; প্রতিটি ছোট random 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, fixed mirror pairs)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

Cache-বিহীন single-block read-modify-write-এর জন্য RAID 6-এ 6টি device operation লাগে। একই overwrite-এর জন্য দুই-copy RAID 10-এ লাগে 2টি। এই count latency-এর পার্থক্যকে কম করে দেখায়। দুটি mirror write parallel-এ পাঠানো হয়, তাই guest-কে দুটির মধ্যে যেটি ধীর, সেটির জন্য অপেক্ষা করতে হয়। read-modify-write path-এ এমন একটি read থাকে, যা শেষ না হওয়া পর্যন্ত নতুন parity গণনা করা যায় না। তাই guest-কে ধারাবাহিকভাবে প্রথমে একটি read এবং পরে একটি write-এর জন্য অপেক্ষা করতে হয়। ব্যস্ত host-এ ওই read অন্য সবার I/O-এর পেছনে queue-তে অপেক্ষা করে।

একটি গুরুত্বপূর্ণ ব্যতিক্রম আছে। কোনো write পুরো একটি stripe পূরণ করার মতো বড় হলে পুরোনো data পড়ার প্রয়োজন হয় না, কারণ stripe-এর প্রতিটি block প্রতিস্থাপিত হচ্ছে। Memory-তে থাকা data থেকেই parity গণনা করা যায়। ফলে RAID 5-এ প্রতি stripe-এ একটি parity write এবং RAID 6-এ দুটি parity write-এ overhead নেমে আসে; preread-এর প্রয়োজন হয় না। এ কারণেই sequential benchmark-এ RAID 5 ভালো দেখায়, কিন্তু অনেক tenant-এর ছোট write-এর mixed load-এ খারাপ আচরণ করে। আপনি যে pattern বাস্তবে চালান, সেটিই পরীক্ষা করুন: VPS disk সঠিকভাবে benchmark করা বলতে বাস্তবসম্মত queue depth-এ random I/O বোঝায়, একটি বড় dd নয়।

কেন rebuild-ই সবচেয়ে ঝুঁকিপূর্ণ ধাপ

সম্পূর্ণ RAID 5 rebuild-এ বাকি সব drive-এর তথ্য ব্যবহার করে অনুপস্থিত drive পুনর্গঠন করতে হয়। তাই আট-drive-এর উদাহরণে এটি শুরু থেকে শেষ পর্যন্ত 7টি সচল drive পড়ে। নির্দিষ্ট দুই-copy mirror pair ব্যবহার করলে RAID 10 rebuild পড়ে 1টি drive: নষ্ট drive-এর mirror partner, আর কিছু নয়। অন্যান্য Linux RAID10 layout-এ copy ভিন্নভাবে ছড়ানো থাকে। তিন-device near layout-এর কোনো member পুনর্গঠন করতে বাকি দুই member পড়তে হয়।

এতে দুটি খরচ হয়। প্রথমটি সময়, কারণ rebuild-এর গতি সচল drive, reconstruction-এর কাজ এবং recovery speed target দ্বারা সীমাবদ্ধ। দ্বিতীয়টি load। Parity rebuild সচল drive-গুলোর মধ্যে I/O ছড়িয়ে দেয়। নির্দিষ্ট mirror pair ব্যবহার করলে RAID 10 rebuild এই I/O একটি pair-এর ওপর কেন্দ্রীভূত করে। তবে shared controller এবং host resource অন্য pair-গুলোকেও প্রভাবিত করে।

একই সময়ে correctness-এর ঝুঁকিও থাকে। একটি dead drive-সহ RAID 5 array-তে আর কোনো redundancy থাকে না। তাই সচল drive-এর যেকোনো জায়গায় unreadable sector থাকলে সেটি আর পুনরুদ্ধার করা যায় না। Rebuild-ই এমন একটি operation যা প্রতিটি sector পড়ে, এমনকি যেগুলো এক বছরেও কেউ ব্যবহার করেনি। প্রকাশিত datasheet-এর তথ্য অনুযায়ী, consumer hard drive-এ পড়া প্রতি 10^14 bit-এ প্রায় একটি unrecoverable read error হতে পারে। Enterprise NVMe drive-এ এই হার 10^17 bit-এ একটি বা তার চেয়েও ভালো। এগুলো vendor specification, measurement নয়। তবে এই অনুপাত ব্যাখ্যা করে কেন RAID 5 rebuild ব্যর্থ হবে—এই পুরোনো সতর্কতা বড় spinning disk নিয়ে লেখা হয়েছিল এবং NVMe-তে কেন তা অনেক কম প্রযোজ্য। Load-এর যুক্তি যেকোনো medium-এর ক্ষেত্রেই প্রযোজ্য।

Rebuild শুরু হওয়ার আগে scrub চালিয়ে latent error খুঁজে বের করুন। Debian এবং Ubuntu, উভয়ই md array-এর জন্য periodic scrub সরবরাহ করে। Release অনুযায়ী mechanism ভিন্ন, তাই আপনার system-এ কোনটি আছে তা পরীক্ষা করে হাতে একটি pass চালান।

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-এ শূন্যের বেশি সংখ্যা থাকলে দুই half-এর মধ্যে অমিল আছে। Kernel কোনটি সঠিক তা বলতে পারে না, কারণ কোনো copy-তেই checksum থাকে না। কিছু mismatch ক্ষতিকর নয়। Swap partition এ ধরনের mismatch-এর সাধারণ উৎস, কারণ kernel এমন একটি page লিখতে পারে যা একই সময়ে পরিবর্তিত হয়ে যায়। Data array-এ count বাড়তে থাকলে তদন্ত করা উচিত। তবে শুধু এই count দেখে কোন drive বদলাতে হবে তা নির্ধারণ করা যায় না।

NVMe-এর জন্য VPS provider-গুলো কেন RAID 10 মানসম্মত করেছে

একটি hypervisor node-এ একটি মাত্র workload চলে না। এতে কয়েক ডজন অসংলগ্ন guest চলে, এবং তাদের I/O পরস্পর interleave হয়ে ছোট ছোট write-এর stream হিসেবে আসে; তাদের মধ্যে কোনো locality থাকে না। parity read-modify-write cycle-এর খরচ সবচেয়ে বেশি হয় ঠিক এই pattern-এ। একটি shared node সারাদিন এই pattern-এই কাজ করে।

এর সঙ্গে rebuild-এর আচরণ বিবেচনা করলে পছন্দটি স্পষ্ট হয়। parity node-এ একটি drive নষ্ট হলে বেঁচে থাকা drive-গুলো জুড়ে reconstruction-এর কাজ বাড়ে। নির্দিষ্ট mirror pair থাকলে RAID 10 node-এ একটি drive নষ্ট হওয়ার rebuild I/O শুধু একটি pair-এ যোগ হয়, আর অন্য activity চললে Linux MD recovery ধীর করে। Provider-গুলো এমন latency বিক্রি করে যা হঠাৎ বেড়ে যায় না। তাই তারা capacity দিয়ে এর মূল্য দেয়: raw NVMe-এর অর্ধেক mirror-এর জন্য বরাদ্দ হয়।

Drive-এর আকারও একই দিকে প্রভাব ফেলে। Drive বড় হলে rebuild window দীর্ঘ হয়। RAID 5-এ এই সময়ে reconstruction অতিরিক্ত load তৈরি করে এবং কোনো redundancy অবশিষ্ট থাকে না। RAID 6 আরও একটি drive failure-এর বিরুদ্ধেও সুরক্ষা বজায় রাখে। Virtualisation-এর জন্য ZFS deployment-এ wide raidz-এর বদলে mirrored vdev-এর pool ব্যবহারের কারণও একই: mirror resilver শুধু বাস্তবে ব্যবহৃত block-গুলো copy করে, তাও একটি pair-এ।

তবে এর কোনোটিই RAID 10-কে সব ক্ষেত্রে সঠিক পছন্দ বানায় না। একটি backup target-এ দীর্ঘ sequential run হিসেবে write হয় এবং খুব কম read করা হয়। তাই সেখানে RAID 6 বেশি কার্যকর। এটি দুটি failure সহ্য করতে পারে এবং অধিকাংশ capacity ফিরিয়ে দেয়। সিদ্ধান্ত workload-এর ওপর নির্ভর করে, সংখ্যার ওপর নয়। আজ যে plan বেছে নিচ্ছেন, সেখানে ওপরের layout-এর চেয়ে medium সাধারণত বেশি গুরুত্বপূর্ণ। উভয় ক্ষেত্রেই SATA SSD থেকে NVMe-তে পরিবর্তন যেকোনো RAID পার্থক্যের চেয়ে বড়।

/proc/mdstat পড়বেন যেভাবে

যে মেশিনে array-এর মালিক আপনি, সেখানে এগুলো চালান: একটি dedicated server, বাড়ির একটি মেশিন, অথবা নিজের তৈরি array-সহ দুটি সংযুক্ত volume থাকা একটি VPS। নিজের output পড়ুন। নিচের block-গুলো উদাহরণ হিসেবে লেখা, যাতে আপনার পাওয়া 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 চলমান kernel যে md module-গুলো load করেছে, সেগুলোর তালিকা দেয়। সেখানে raid10 দেখা গেলে শুধু বোঝায় যে code available; এর বেশি কিছু নয়।
• md0 : active raid10 হলো array device, এর state এবং এর level।
• এর পরের নামগুলো হলো member। square bracket-এর সংখ্যাটি array metadata-তে device-এর index; এটি line-এর অবস্থান নয় এবং সব সময় device-এর slot-ও নয়।
• drive প্রতিস্থাপনের পরে নতুন member সাধারণত যে slot পূরণ করেছে, তার চেয়ে বেশি index ধরে রাখে। তাই nvme4n1p3[4] slot 2-তে থাকতে পারে। mdadm --detail তার RaidDevice column-এ প্রকৃত slot দেখায়, তাই পার্থক্যটি গুরুত্বপূর্ণ হলে সেটিই ব্যবহার করুন।
• কোনো member-এর পরে (F) থাকলে সেটি faulty। (S) মানে spare: device উপস্থিত, idle অবস্থায় আছে এবং কোনো কিছু ব্যর্থ হওয়ার অপেক্ষায় আছে।
• 3906764800 blocks super 1.2 হলো 1 KiB block-এ usable size, এর পরে metadata format থাকে।
• 512K chunks 2 near-copies হলো stripe chunk size এবং RAID 10 layout। এখানে এটি প্রতিটি block-এর দুটি copy পাশাপাশি রাখে।
• [4/4]-এ প্রথমে array যত member প্রত্যাশা করে, তারপর বর্তমানে যত member sync অবস্থায় আছে, সেই সংখ্যা থাকে।
• [UUUU]-এ slot-এর ক্রম অনুযায়ী প্রতি slot-এর জন্য একটি করে character থাকে। U হলো চালু এবং sync অবস্থায় থাকা slot। _ হলো এমন slot, যেখানে কোনো কার্যকর device নেই।
• bitmap: হলো write intent bitmap। কোন region-এ write চলছিল, এটি তা record করে। ফলে কোনো member সংযোগ বিচ্ছিন্ন হয়ে আবার ফিরে এলে পুরো drive নয়, শুধু ওই region-গুলো 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]

দুটি bracket একসঙ্গে পড়ুন। [4/3] জানায় যে চারটি slot-এর একটি কোনো data দিচ্ছে না। [UU_U] জানায় কোনটি, কারণ underscore হলো তৃতীয় character এবং slot zero থেকে গণনা করা হয়; তাই slot 2 down। failed drive এখনও সংযুক্ত থাকা অবস্থায় (F) flag শুধু device-টির নাম দেখায়। drive-টি মেশিন থেকে খুলে নিলে line থেকে নামটি চলে যায়, কিন্তু underscore থেকে যায়।

এই অবস্থাতেও array service দিতে থাকে। RAID 10-এ এটি প্রায় পূর্ণ গতিতেও service দিতে পারে। তাই ব্যবহার করে সাধারণত সমস্যা বোঝা যায় না। কোনো monitoring ব্যবস্থা আপনাকে জানাবে।

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 পড়ে। releases-এর মধ্যে unit name পরিবর্তিত হয়েছে, তাই অনুমান না করে শেষের command দিয়ে এটি খুঁজে নিন। --test run করলে সঙ্গে সঙ্গে প্রতিটি array-এর জন্য একটি করে message পাঠানো হয়। এর পরে inbox খালি থাকলে mail path-এ সমস্যা আছে। অর্থাৎ আপনি যে 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 হলো consistency pass; এর মধ্যে initial pass এবং unclean shutdown থেকে recovery-ও রয়েছে। check হলো উপরে চালানো scrub। বন্ধনীর ভেতরের জোড়াটি 1 KiB block-এ progress দেখায়, যা per-device total-এর বিপরীতে গণনা করা হয়। finish হলো বর্তমান গতির ভিত্তিতে kernel-এর estimate। Linux MD recovery speed target হিসেবে /proc/sys/dev/raid/speed_limit_min এবং speed_limit_max ব্যবহার করে। প্রতি-array override থাকে sync_speed_min এবং sync_speed_max-এ। প্রতি device-এ default maximum target হলো 200,000 KiB/s। এই target-গুলো production I/O-কে অগ্রাধিকার দিতে recovery-এর গতি কমায়; এগুলো কঠোর speed cap নয়।

/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 প্রতিস্থাপনের জন্য চারটি command লাগে। শেষ command-টিই check।

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

এক বা দুই second-এর মধ্যে recovery line দেখা উচিত। Replacement partition-টি mdadm --detail থেকে পাওয়া Used Dev Size-এর চেয়ে অন্তত সমান বড় হতে হবে। সামান্য ছোট partition-ও not large enough to join array-এর মতো message দিয়ে প্রত্যাখ্যাত হবে। Add করার আগে নতুন drive-এ পুরোনোটির সঙ্গে মিল রেখে partition তৈরি করুন।

VPS-এর ভেতর থেকে আপনি যা দেখতে পান এবং যা পান না

বেশিরভাগ গেস্ট সিস্টেম হোস্টের RAID দেখতে পায় না, এবং এটি পরিকল্পিতভাবেই করা হয়েছে। হাইপারভাইজার আপনাকে একটি ভার্চুয়াল ডিস্ক প্রদান করে। সেই ডিস্কটি NVMe ড্রাইভের কোনো RAID 10 পুল থেকে তৈরি নাকি একটি মাত্র ড্রাইভের ওপর অবস্থিত, তা হোস্টের বৈশিষ্ট্য এবং এটি আপনার গেস্ট সিস্টেমের ভেতর দেখা যায় না।

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

systemd-detect-virt কমান্ডটি KVM গেস্টের ক্ষেত্রে kvm প্রদর্শন করে, কন্টেইনারের ক্ষেত্রে lxc-এর মতো কন্টেইনার টাইপ দেখায় এবং বেয়ার মেটাল সার্ভারে none প্রদর্শন করে। KVM গেস্টের ক্ষেত্রে আপনি সাধারণত lsblk-এ একটি মাত্র vda বা sda দেখতে পাবেন এবং /proc/mdstat-এ কোনো অ্যারে (array) থাকবে না, কারণ গেস্টের ভেতরে এগুলোর অস্তিত্ব নেই।

কন্টেইনার-ভিত্তিক VPS-এর ক্ষেত্রে এই তথ্য নির্ভরযোগ্য নয়। কন্টেইনারগুলো হোস্টের কার্নেল শেয়ার করে এবং /proc-এর কিছু অংশ নেমস্পেসড (namespaced) থাকে না, তাই সেখানে যা দেখা যায় তা আপনার স্লাইসের পরিবর্তে হোস্টের বর্ণনা হতে পারে। এর কোনোটিকেই আপনার স্টোরেজ সম্পর্কিত তথ্য হিসেবে গণ্য করবেন না। আপনার স্টোরেজ লেআউট কেমন তা জানতে প্রোভাইডারকে জিজ্ঞাসা করুন এবং যদি এটি আপনার জন্য গুরুত্বপূর্ণ হয়, তবে লিখিত উত্তর নিন।

আপনি ভেতর থেকে যা পরীক্ষা করতে পারেন তা হলো আপনাকে দেওয়া ডিস্কটির আচরণ। আপনার VPS ডিস্কটি সত্যিই NVMe কি না তা যাচাই করা অংশে এমন কমান্ডগুলো আলোচনা করা হয়েছে যা প্রকৃত তথ্য প্রদান করে এবং একটি SSD VPS-এ আসলে কী থাকে অংশে প্ল্যান পেজে দেওয়া লেবেলের দাবিগুলো বিশ্লেষণ করা হয়েছে।

আপনার কি VPS-এর ভেতরে RAID চালানো উচিত?

সাধারণত না, এর কারণ হলো failure domains। আপনি যদি একটি VPS-এ দুটি volume যুক্ত করে mdadm দিয়ে সেগুলোকে mirror করেন, তবে উভয় volume-ই একই physical array, একই node এবং একই power supply-এর পেছনে থাকতে পারে। এতে আপনি যে redundancy আগে থেকেই পাচ্ছিলেন, তার জন্য প্রতিটি write-এর খরচ দ্বিগুণ করবেন, অথচ একটি বড় ধরনের ব্যর্থতায় আপনি উভয় copy-ই হারাবেন।

এটি তখনই করা সার্থক যখন provider নিশ্চিত করে যে volume-গুলো আলাদা failure domain-এ রয়েছে, অথবা আপনি যখন এমন dedicated server ব্যবহার করছেন যেখানে আপনি সরাসরি drive-গুলোকে নির্দেশ করতে পারেন। অন্যথায়, এই পরিশ্রম এমন backup-এর পেছনে ব্যয় করা ভালো যা মেশিন থেকে বাইরে রাখা যায়।

RAID আপনাকে যা থেকে সুরক্ষা দেয় না

RAID শুধুমাত্র একটি ঘটনার ক্ষেত্রে কাজ করে: যখন একটি ড্রাইভ সঠিকভাবে কাজ করা বন্ধ করে দেয়। নিচে উল্লিখিত প্রতিটি কাজই একটি বৈধ রাইট (write) হিসেবে গণ্য হয়, তাই অ্যারে সেটিকে প্রতিটি কপিতে প্রয়োগ করে এবং নিজেকে সুস্থ হিসেবে রিপোর্ট করে।

• ডিলিট করা (Deletion): ভুল ডিরেক্টরিতে rm -rf চালানো, অথবা এমন কোনো deploy script যেখানে পাথের কোনো ভেরিয়েবল সেট করা নেই। অ্যারে এটিকে একটি বৈধ রাইট হিসেবে দেখে এবং তা দুইবারই কার্যকর করে।
• র‍্যানসমওয়্যার (Ransomware): এনক্রিপশন হলো এক ধরনের রাইট অপারেশন। একটি সুস্থ অ্যারে মিররের উভয় অংশেই এনক্রিপ্ট করা ভার্সনটি সংরক্ষণ করে।
• ত্রুটিপূর্ণ অ্যাপ্লিকেশন (A broken application): এমন কোনো বাগ যা আপনার ডাটাবেসে আবর্জনা (garbage) লেখে, তা রিডান্ড্যান্ট ড্রাইভেও একই আবর্জনা লিখে ফেলে।
• পুরো নোড (The whole node): কোনো হোস্ট ফেইল করলে, অথবা ভুলবশত কোনো অ্যাকাউন্ট সাসপেন্ড হলে। একটি অ্যারে নিখুঁত অবস্থায় থেকেও দুর্গম (unreachable) হতে পারে।
• আপনি নিজে, এক সপ্তাহ পরে: সোমবার আপনি যে ফাইলটি ডিলিট করেছেন, তা সোমবারই প্রতিটি ড্রাইভ থেকে মুছে গেছে। শুধুমাত্র তার আগের কোনো কপিই তা ফিরিয়ে আনতে পারে।

একই স্টোরেজে স্ন্যাপশট রাখাও এর সমাধান নয়। এগুলো ডিলিট হওয়া থেকে রক্ষা করতে সাহায্য করে, কিন্তু যে অ্যারেতে এগুলো থাকে, সেই অ্যারে নষ্ট হয়ে গেলে স্ন্যাপশটও নষ্ট হয়ে যায়। ব্যাকআপকে ব্যাকআপ হিসেবে গণ্য করার মূল বৈশিষ্ট্য হলো এটি অন্য কোথাও সংরক্ষিত থাকা। restic ব্যবহার করে এনক্রিপ্ট করা অফ-সার্ভার ব্যাকআপ হলো এই পৃষ্ঠার অন্য অর্ধেক: একটি ড্রাইভ নষ্ট হয়ে গেলেও অ্যারে আপনাকে সার্ভিস চালু রাখতে সাহায্য করে, আর যখন কোনো রাইট অপারেশনের কারণে ক্ষতি হয় যা অ্যারে সানন্দে সম্পন্ন করেছে, তখন restic আপনার ডাটা ফিরিয়ে আনে।

FAQ

RAID 10 ব্যবহার করলে কি backup-এর আর প্রয়োজন নেই?

না। RAID 10 এমন একটি drive নষ্ট হয়ে যাওয়া থেকে সুরক্ষা দেয়, যা আর কাজ করে না। এটি mirror-এর উভয় অংশে প্রতিটি বৈধ write প্রয়োগ করে। তাই কোনো deletion বা ransomware চালানো হলে একই মুহূর্তে redundant drive-এও তা প্রয়োগ হয়। এরপর array নিজেকে clean হিসেবে report করে, কারণ তার দৃষ্টিতে কোনো ত্রুটি ঘটেনি। আপনার এখনও machine-এর বাইরে সংরক্ষিত copy প্রয়োজন। সেগুলো কাজ করছে কি না নিশ্চিত করতে মাঝে মাঝে একটি copy restore করাও প্রয়োজন।

VPS provider-রা RAID 5 বা RAID 6-এর বদলে RAID 10 কেন বেছে নেয়?

এর দুটি কারণ আছে। দুটিই small random write-এর সঙ্গে সম্পর্কিত। Uncached single-block read-modify-write নতুন parity গণনা করার আগে পুরোনো data এবং parity read করে। এতে RAID 5-এ 4টি operation এবং RAID 6-এ 6টি operation লাগে। দুই-copy mirror-এ লাগে 2টি। Reconstruct-write-এর ক্ষেত্রে অপরিবর্তিত data ব্যবহার করা হয়। Full-stripe write-এ পুরোনো data বা পুরোনো parity আগে read করার প্রয়োজন হয় না। Full RAID 5 rebuild-এ এরপরও প্রতিটি surviving drive শুরু থেকে শেষ পর্যন্ত read করতে হয়। Conventional RAID 10-এ surviving partner থেকে copy করা হয়। অন্য Linux RAID10 layout-এ একাধিক source member ব্যবহার করা হয়। অন্য activity চললে Linux MD recovery ধীর করে দেয়। এর বিনিময়ে provider-দের capacity-এর অর্ধেক ছাড়তে হয়: raw NVMe-এর অর্ধেক।

/proc/mdstat-এ [U_] বা [UU_U] বলতে কী বোঝায়?

প্রতিটি character array-এর একটি slot নির্দেশ করে। এগুলো slot-এর ক্রমে থাকে এবং প্রতিটি slot-এর জন্য একটি করে character থাকে। U বোঝায়, ওই slot-এ একটি up এবং in-sync member আছে। _ বোঝায়, ওই slot-এ কোনো working member নেই। দুই-drive mirror-এ [U_] বোঝায়, দ্বিতীয় slot down এবং আর কোনো redundancy অবশিষ্ট নেই। এর সঙ্গে সামনে থাকা pair-টি একসঙ্গে পড়ুন। সেখানে [4/3] জানায় যে array চারটি member প্রত্যাশা করছে এবং তিনটি member পেয়েছে। Slot-এর ক্রম mdadm --detail-এর RaidDevice column-এর সঙ্গে মেলে। এটি line-এ device name যে ক্রমে দেখা যায়, তার সঙ্গে মেলে না।

একটি RAID 10 array কতটি drive হারাতে পারে?

Fixed mirror pair-সহ conventional two-copy RAID 10 যে কোনো pattern-এ একটি drive হারাতে পারে। এর বেশি হলে failure কোথায় ঘটেছে, তার ওপর ফল নির্ভর করে। প্রতিটি mirror pair তার দুই member-এর মধ্যে একটি হারাতে পারে। তাই আট-drive array-তে কোনো দুইটি failure একই pair-এ না হলে সর্বোচ্চ চারটি failure সহ্য করা যায়। কিন্তু দুইটি failure একই pair-এ হলে array দুইটি failure-এই নষ্ট হয়ে যায়। Guaranteed সংখ্যাকে ভিত্তি করে পরিকল্পনা করুন। এই সংখ্যা একটি। এর বেশি সংখ্যাকে protection নয়, বরং সৌভাগ্য হিসেবে বিবেচনা করুন।

VPS-এর ভেতরে mdadm ব্যবহার করে দুটি volume mirror করা উচিত কি?

সাধারণত না। একই VPS-এ সংযুক্ত দুটি volume প্রায়ই একই host-এর একই physical array-এ থাকে। তাই এগুলো mirror করলে প্রতিটি write-এর cost দ্বিগুণ হয়, কিন্তু host-এর নিজস্ব RAID ইতিমধ্যে যে failure থেকে সুরক্ষা দেয়, তার বাইরে আর কোনো সুরক্ষা পাওয়া যায় না। Provider যদি নথিভুক্ত করে যে volume দুটি পৃথক failure domain-এ রয়েছে, কেবল তখনই এটি করা যুক্তিযুক্ত। অন্যথায় machine-এর বাইরে রাখা backup তৈরিতে এই প্রচেষ্টা ব্যয় করুন।