SSD Nodes Learn 🎉 VPS $5.50/மாதம் முதல்
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-13

RAID 10 என்றால் என்ன? VPS சேமிப்பகத்தில் இதன் அவசியம்

RAID 1, 5, 6 மற்றும் 10 நிலைகளின் செயல்பாடுகள், rebuild செலவு மற்றும் VPS ஹோஸ்ட்கள் ஏன் NVMe-க்கு RAID 10-ஐ தேர்வு செய்கின்றன என்பதை அறியுங்கள். /proc/mdstat வாசிப்பது எப்படி?

RAID 10 என்றால் என்ன, VPS ஹோஸ்ட்கள் ஏன் இதைப் பயன்படுத்துகின்றன

RAID 10 என்பது மெய்நிகராக்கப்பட்ட NVMe (non-volatile memory express) டிரைவ்களில் பெரும்பாலான VPS ஹோஸ்ட்கள் பயன்படுத்தும் சேமிப்பக அமைப்பாகும். இது ஒவ்வொரு டிரைவையும் அதன் இணையான டிரைவில் பிரதிபலிக்கிறது (mirror), பின்னர் அந்த ஜோடிகளுக்கு இடையே தரவுகளைப் பிரித்து எழுதுகிறது (stripe). ஒரு டிரைவ் செயலிழந்தாலும் array நிறுத்தப்படாது; பழுதுபார்ப்பு என்பது மற்ற டிரைவ்களை வாசித்து கணக்கிடுவதற்குப் பதிலாக, எஞ்சியிருக்கும் இணையான டிரைவிலிருந்து தரவை நேரடியாக நகலெடுப்பதாகும்.

RAID என்பது redundant array of independent disks என்பதன் சுருக்கமாகும். இதற்கு ஒரே ஒரு பணிதான் உள்ளது: ஒரு வட்டு செயலிழந்திருக்கும்போதோ அல்லது மாற்றப்படும்போதோ கணினியைத் தொடர்ந்து இயங்க வைப்பது. அந்தப் பணி 'கிடைக்கும் தன்மை' (availability) சார்ந்தது, ஆனால் கிடைக்கும் தன்மை என்பது 'பாதுகாப்பு' (safety) அல்ல.

RAID உங்கள் எழுதும் செயல்பாடுகளை (writes) நகலெடுக்கிறது. rm -rf /srv என்பது ஒரு எழுதும் செயல்பாடு. மிரர் செய்யப்பட்ட இரண்டு பகுதிகளிலும் ஒரே மில்லி விநாடியில் கோப்பு நீக்கப்படும், அதன் பிறகும் அந்த array தன்னைச் சரியாக இருப்பதாகவே காட்டும்.

இந்த வாக்கியத்தை நினைவில் கொள்ளுங்கள். இந்தப் பக்கத்தின் மீதமுள்ள பகுதிகள், ஒவ்வொரு RAID நிலையும் எத்தகைய பாதிப்புகளைத் தாங்கும் மற்றும் ஒவ்வொரு எழுதும் செயல்பாட்டிற்கும் அது எவ்வளவு செலவை (performance cost) ஏற்படுத்தும் என்பதை விளக்குகின்றன. கடைசிப் பிரிவுகள், நீங்கள் வைத்திருக்கும் கணினியில் ஒரு array-ன் நிலையைச் சரிபார்க்கத் தேவையான கட்டளைகளையும், RAID ஒருபோதும் ஈடுசெய்ய முடியாத தோல்விகளையும் விவரிக்கின்றன.

Hosting வாங்குபவர் உண்மையில் சந்திக்கும் நிலைகள்: 1, 5, 6 மற்றும் 10

ஒரு திட்டப் பக்கம் (plan page) ஒரு எண்ணைக் குறிப்பிட்டு அதோடு நிறுத்திவிடும். அந்த எண் இரண்டு கேள்விகளுக்குப் பதிலளிக்கிறது: எத்தனை drives செயலிழக்க முடியும், மற்றும் ஒவ்வொரு write-க்கும் என்ன செலவாகும்.

RAID 1 என்பது ஒரு mirror ஆகும். இரண்டு drives ஒரே மாதிரியான blocks-ஐ வைத்திருக்கும். ஒவ்வொரு write-ம் இரண்டுக்கும் செல்லும். எந்த drive-ம் read-ஐ வழங்க முடியும். தரவு இழப்பின்றி ஒரு drive செயலிழக்கலாம், மேலும் மூலத் திறனில் (raw capacity) பாதி பயன்படுத்தக்கூடியதாக இருக்கும். கணக்கிடுவதற்கு parity இல்லாததால், write பாதை குறுகியது.

RAID 5 என்பது ஒரு stripe-க்கு ஒரு parity block கொண்ட striping ஆகும். n எண்ணிக்கையிலான drives இருந்தால், n-1 drives-ன் திறன் கிடைக்கும், மேலும் array சரியாக ஒரு செயலிழப்பைத் தாங்கும். Parity ஒரு குறிப்பிட்ட drive-ல் மட்டும் இருக்காது. அது அனைத்திலும் சுழலும், எனவே ஒவ்வொரு drive-ம் தரவு மற்றும் parity இரண்டையும் கொண்டிருக்கும்.

RAID 6 ஒவ்வொரு stripe-க்கும் இரண்டாவது, சுதந்திரமான parity block-ஐச் சேர்க்கிறது, இது பொதுவாக P மற்றும் Q என எழுதப்படும். இது ஒரே நேரத்தில் இரண்டு drives செயலிழந்தாலும் தாங்கும். இது கேட்பதை விட முக்கியமானது, ஏனெனில் முதல் செயலிழப்பைச் சரிசெய்யும்போதே பெரும்பாலும் இரண்டாவது செயலிழப்பு ஏற்படுகிறது.

RAID 10 என்பது mirrors-ன் ஒரு stripe ஆகும். Drives ஜோடிகளாக mirror செய்யப்படுகின்றன, மேலும் தரவு அந்த ஜோடிகளுக்கு இடையே பரப்பப்படுகிறது. பயன்படுத்தக்கூடிய திறன் மொத்த மூலத் திறனில் பாதி, இது RAID 1-க்கு சமமானது, அதனுடன் striping-ன் இணையாகச் செயல்படும் திறன் (parallelism) கூடுதலாகக் கிடைக்கிறது.

இது RAID 1+0 என்றும் எழுதப்படுவதைக் காண்பீர்கள், இதுவே சரியான விளக்கம்: முதலில் mirror, பின்னர் அந்த mirrors-க்கு இடையே stripe. RAID 0+1 என்பது மற்றொரு வரிசை, முதலில் stripe செய்துவிட்டு பின்னர் இரண்டு stripes-ஐ mirror செய்வது. இது மோசமானது, ஏனெனில் ஒரு drive செயலிழந்தால் முழு stripe-ம் சேவையிலிருந்து வெளியேறிவிடும், மேலும் பழுதுபார்ப்பதற்கு மறுபக்கத்திலுள்ள அனைத்தையும் நகலெடுக்க வேண்டியிருக்கும்.

Linux ஒரு தனித்துவமான சூழல், இதைப் புரிந்துகொள்வது அவசியம். Kernel-ன் raid10 என்பது இரண்டு அடுக்குகளைக் கொண்டதற்குப் பதிலாக ஒரு ஒற்றைப் பண்பைக் கொண்டது, எனவே இது ஒற்றைப்படை எண்ணிக்கையிலான drives-ல் இயங்குகிறது மற்றும் இதற்கு nested setup-ஆல் வெளிப்படுத்த முடியாத layouts (near, far, offset) உள்ளன. இதனால்தான் Linux box-ல் உள்ள status line இரண்டு arrays-ஐக் குறிப்பிடுவதற்குப் பதிலாக 2 near-copies என்று கூறுகிறது.

ChartEight 1 TB drives: usable capacity and drives lost before data loss
The data behind this chart
[
  {
    "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 எந்தவொரு அமைப்பிலும் 2 செயலிழப்புகளைத் தாங்கும். RAID 10 1 செயலிழப்புகளை மட்டுமே உறுதி செய்கிறது, ஏனெனில் ஏற்கனவே செயலிழந்த drive-ன் ஜோடி மீது விழும் இரண்டாவது செயலிழப்பு ஆபத்தானது. எந்த இரண்டு செயலிழப்புகளும் ஒரே ஜோடியைப் பாதிக்காதபோது இது 4 வரை தாங்கும், இது வடிவமைப்பின் பண்பை விட அதிர்ஷ்டத்தையே சார்ந்தது.

ஒவ்வொரு write-க்கும் ஒவ்வொரு நிலையின் செலவு

ஒரு mirror-க்கு செய்யப்படும் write என்பது இரண்டு write-களாகும், இவை இரண்டு உறுப்பினர்களுக்கும் ஒரே நேரத்தில் அனுப்பப்படும். ஒரு parity stripe-க்கு செய்யப்படும் write அதிக வேலைப்பளுவைக் கொண்டது, ஏனெனில் அந்த stripe-க்கான parity block இப்போது தவறாகிவிடும், அதை மீண்டும் கணக்கிட வேண்டும்.

controller-ஆல் புதிய block-ஐ மட்டும் வைத்துக்கொண்டு parity-ஐ மீண்டும் கணக்கிட முடியாது. அதற்கு முதலில் பழைய data block மற்றும் பழைய parity block தேவை. எனவே, RAID 5-ல் செய்யப்படும் ஒரு சிறிய random write என்பது read, read, write, write என மாறுகிறது. RAID 6-ல் பராமரிக்க இரண்டாவது syndrome இருப்பதால், அதே write என்பது read, read, read, write, write, write என மாறுகிறது.

ChartDevice operations per small random write, and drives read during a rebuild
The data behind this chart
[
  {
    "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
  }
]

ஒரு சிறிய random write-க்கு RAID 6-ல் 6 device operations-ம், RAID 10-ல் 2 device operations-ம் செலவாகின்றன. இந்த எண்ணிக்கை latency-ல் உள்ள வித்தியாசத்தை முழுமையாகக் காட்டவில்லை. இரண்டு mirror write-களும் இணையாக (parallel) செல்வதால், guest இரண்டில் எது மெதுவாக முடிகிறதோ அதற்காகக் காத்திருக்கும். parity பாதையில் ஒரு read உள்ளது, புதிய parity-ஐ கணக்கிடுவதற்கு முன்பு அது முடிவடைய வேண்டும், எனவே guest ஒரு read-க்காகவும், பின் ஒரு write-க்காகவும் வரிசையாகக் காத்திருக்கும். பிஸியான host-ல் அந்த read மற்ற அனைவரின் I/O-க்கும் பின்னால் வரிசையில் நிற்கும்.

இதில் ஒரு முக்கியமான விதிவிலக்கு உள்ளது. ஒரு முழு stripe-ஐ நிரப்பும் அளவுக்குப் பெரிய write-க்கு பழைய data தேவையில்லை, ஏனெனில் stripe-ல் உள்ள ஒவ்வொரு block-ம் மாற்றப்படுகிறது. நினைவகத்தில் (memory) ஏற்கனவே உள்ளவற்றிலிருந்து parity கணக்கிடப்படுகிறது, இதனால் செலவு ஒரு கூடுதல் write-ஆகக் குறைகிறது. இதனால்தான் sequential benchmark-ல் RAID 5 சரியாகத் தெரிவதும், பல பயனர்களிடமிருந்து வரும் சிறிய write-கள் கலந்த சுமையின் கீழ் மோசமாகச் செயல்படுவதும் நிகழ்கிறது. நீங்கள் உண்மையில் இயக்கும் pattern-ஐச் சோதிக்கவும்: VPS disk-ஐ முறையாக benchmarking செய்தல் என்பது ஒரு பெரிய dd அல்ல, மாறாக யதார்த்தமான queue depth-ல் random I/O-வைச் சோதிப்பதாகும்.

மறுசீரமைப்பு (rebuild) ஏன் ஆபத்தானது

ஒரு parity rebuild, விடுபட்ட drive-ஐ மற்ற அனைத்து drive-களிலிருந்தும் மீண்டும் உருவாக்க வேண்டும். எனவே, இது முதல் block முதல் கடைசி block வரை 7 எண்ணிக்கையிலான இயங்கும் drive-களை வாசிக்கும். RAID 10 rebuild 1 எண்ணிக்கையிலான drive-களை மட்டுமே வாசிக்கும்: செயலிழந்த drive-ன் mirror partner-ஐ மட்டும் வாசித்தால் போதுமானது, மற்றவை தேவையில்லை.

இதன் விளைவாக இரண்டு சிக்கல்கள் ஏற்படுகின்றன. முதலாவது நேரம், ஏனெனில் rebuild செயல்முறை மிகவும் மெதுவாக இயங்கும் drive மற்றும் அதன் மேலுள்ள parity கணக்கீடுகளைச் சார்ந்து இருக்கும். இரண்டாவது சுமை (load). ஒரு parity set-ல் உள்ள அனைத்து drive-களும் இந்த முழு காலத்திலும் பிஸியாக இருக்கும், எனவே rebuild முடியும் வரை அந்த node-ல் உள்ள அனைத்து guest-களும் அதிக latency-ஐ உணரும். RAID 10-ல் ஒரு ஜோடி மட்டுமே பிஸியாக இருக்கும், மற்ற ஜோடிகள் வழக்கமான வேகத்தில் இயங்கும்.

அதே காலக்கட்டத்தில் தரவு சரியாக இருப்பதிலும் ஆபத்து உள்ளது. ஒரு drive செயலிழந்த RAID 5 array-ல் redundancy இருக்காது. எனவே, எஞ்சியிருக்கும் drive-களில் ஏதேனும் ஒரு sector-ஐ வாசிக்க முடியாவிட்டால், அந்தத் தரவை மீட்க முடியாது. Rebuild என்பது ஒவ்வொரு sector-ஐயும் வாசிக்கும் ஒரு செயல்முறை, ஒரு வருடமாக யாரும் தொடாத sector-களையும் இது வாசிக்கும். உற்பத்தியாளர்களின் தரவுத்தாள்களின்படி, ஒரு consumer hard drive-ல் 10^14 bits வாசிக்கும்போது ஒரு unrecoverable read error ஏற்பட வாய்ப்புள்ளது, enterprise NVMe drive-களில் இது 10^17 அல்லது அதற்கும் மேலாக இருக்கும். இவை உற்பத்தியாளர்களின் விவரக்குறிப்புகள் மட்டுமே, அளவீடுகள் அல்ல. இருப்பினும், பெரிய spinning disks-களில் RAID 5 rebuild தோல்வியடையும் என்ற பழைய எச்சரிக்கை ஏன் எழுப்பப்பட்டது என்பதையும், NVMe-ல் ஏன் அந்த ஆபத்து குறைவு என்பதையும் இந்த விகிதம் விளக்குகிறது. சுமை (load) தொடர்பான வாதம் எந்த ஊடகத்திலும் பொருந்தும்.

Rebuild செய்வதற்கு முன்பே, scrubbing மூலம் மறைந்திருக்கும் பிழைகளைக் கண்டறியவும். Debian மற்றும் Ubuntu-வில் md array-களுக்காக அவ்வப்போது scrub செய்யும் வசதி உள்ளது. இது ஒவ்வொரு release-க்கும் மாறுபடும், எனவே உங்களுடைய 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

sync_action முடிந்ததும் idle நிலைக்குத் திரும்பும், மேலும் mismatch_cnt-ன் மதிப்பு 0 என்று இருக்க வேண்டும். ஒரு mirror-ல் பூஜ்ஜியத்திற்கு மேல் எண் இருந்தால், அந்த இரண்டு பகுதிகளும் ஒத்துப்போகவில்லை என்று அர்த்தம். எந்தப் பிரதிக்கும் checksum இல்லாததால், எது சரியானது என்று kernel-ஆல் சொல்ல முடியாது. சில முரண்பாடுகள் பாதிப்பில்லாதவை, swap partitions-ல் இது பொதுவாக நடக்கும்: kernel ஒரு page-ஐ எழுதும் போது, அதன் அடியில் மாற்றம் ஏற்படலாம். ஒரு data array-ல் இந்த எண்ணிக்கை அதிகரித்துக்கொண்டே சென்றால், அந்த drive-ஐ மாற்ற வேண்டிய நேரம் வந்துவிட்டது என்று அர்த்தம்.

VPS வழங்குநர்கள் ஏன் NVMe-க்கு RAID 10-ஐ தரநிலையாகப் பயன்படுத்துகிறார்கள்

ஒரு hypervisor node ஒரே ஒரு workload-ஐ மட்டும் இயக்குவதில்லை. இது தொடர்பில்லாத பல டஜன் guest-களை இயக்குகிறது. அவற்றின் I/O, சிறிய அளவிலான தரவுகளைத் தொடர்ந்து எழுதும் (small writes) ஒரு ஓட்டமாக, எந்தவிதமான locality-யும் இன்றி ஒன்றோடொன்று கலந்து வருகிறது. இந்தச் சூழலில் தான் parity read-modify-write சுழற்சி அதிகச் சுமையை ஏற்படுத்துகிறது; ஒரு பகிரப்பட்ட node-ல் நாள் முழுவதும் இந்தச் செயல்பாடே நடக்கிறது.

Rebuild செயல்பாட்டைக் கருத்தில் கொண்டால், ஏன் இந்தத் தேர்வு செய்யப்படுகிறது என்பது தெளிவாகும். Parity node-ல் ஒரு drive செயலிழந்தால், அந்த box-ல் உள்ள அனைத்து guest-களின் வேகமும் பல மணிநேரங்களுக்குக் குறையும். ஆனால், RAID 10 node-ல் ஒரு drive செயலிழந்தால், ஒரு ஜோடி மட்டுமே பாதிக்கப்படும்; மேலும், அந்தத் தரவு நகலெடுக்கும் பணி drive-ன் வேகத்தில் வரிசையாக (sequentially) நடக்கும். வழங்குநர்கள் latency அதிகரிக்காத சேவையை வழங்க விரும்புகிறார்கள், எனவே அவர்கள் கூடுதல் capacity-ஐ முதலீடு செய்கிறார்கள்: மொத்த NVMe கொள்ளளவில் பாதி mirror-க்காக ஒதுக்கப்படுகிறது.

Drive-ன் அளவுகளும் இதே முடிவை எடுக்கத் தூண்டுகின்றன. Drive-களின் அளவு அதிகரிக்க அதிகரிக்க, rebuild செய்ய எடுக்கும் காலமும் அதிகரிக்கிறது. Parity முறையில், அந்த rebuild காலத்தில் தான் கணினி மெதுவாக இயங்கும், அதே சமயம் தரவுகளுக்குப் பாதுகாப்பும் இருக்காது. இதனாலேயே, virtualization-க்கான ZFS deployments-ல் wide raidz-க்கு பதிலாக mirrored vdev-களின் pools பயன்படுத்தப்படுகின்றன: ஒரு mirror resilver செயல்பாட்டில், பயன்பாட்டில் உள்ள blocks மட்டுமே ஒரு ஜோடியில் நகலெடுக்கப்படுகின்றன.

இதன் பொருள் RAID 10 எல்லா இடங்களிலும் சரியானது என்று அர்த்தமல்ல. ஒரு backup target-ல் நீண்ட sequential runs மூலம் தரவுகள் எழுதப்படுகின்றன, அவை அரிதாகவே வாசிக்கப்படுகின்றன; எனவே அங்கு RAID 6 சிறந்த தேர்வாகும். இது இரண்டு தோல்விகளைத் தாங்கும் திறன் கொண்டது மற்றும் அதிகப்படியான capacity-ஐ வழங்குகிறது. எண்களை விட workload-தான் தீர்மானிக்கிறது. நீங்கள் இன்று தேர்ந்தெடுக்கும் ஒரு திட்டத்திற்கு, layout-ஐ விட medium முக்கியமானது; SATA SSD-லிருந்து NVMe-க்கு மாறுவது, எந்தவொரு RAID மாற்றத்தை விடவும் பெரிய தாக்கத்தை ஏற்படுத்தும்.

/proc/mdstat-ஐ வாசிப்பது எப்படி

நீங்கள் array-ஐ நிர்வகிக்கும் ஒரு machine-ல் இவற்றை இயக்கவும்: ஒரு dedicated server, வீட்டில் உள்ள ஒரு கணினி, அல்லது நீங்கள் நீங்களாகவே கட்டமைத்த இரண்டு volumes கொண்ட VPS. உங்கள் output-ஐ நீங்களே வாசியுங்கள். கீழே உள்ள தொகுதிகள் உதாரணங்கள்; உங்கள் திரையில் தோன்றும் வெளியீட்டுடன் ஒப்பிட்டுப் பார்க்க இவை உதவும்.

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

சரியான நிலையில் உள்ள நான்கு drive-களைக் கொண்ட RAID 10 அமைப்பு இதைப் போன்ற வெளியீட்டைத் தரும்.

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 modules-ஐப் பட்டியலிடுகிறது. raid10 அங்கு காணப்பட்டால், அந்த code கிடைக்கிறது என்று அர்த்தம், அவ்வளவுதான்.
  • md0 : active raid10 என்பது array device, அதன் நிலை மற்றும் அதன் level ஆகியவற்றைக் குறிக்கிறது.
  • அதற்குப் பின் வரும் பெயர்கள் அதன் உறுப்பினர்கள் (members). சதுர அடைப்புக்குறிக்குள் உள்ள எண், array metadata-வில் அந்த device-ன் index ஆகும்; இது வரியில் உள்ள இடத்தையோ அல்லது எப்போதும் அதன் slot-ஐயோ குறிப்பதில்லை.
  • ஒரு drive-ஐ மாற்றிய பிறகு, புதிய உறுப்பினர் வழக்கமாக அது நிரப்பும் slot-ஐ விட அதிக index-ஐ வைத்திருக்கும், எனவே nvme4n1p3[4] என்பது slot 2-ல் இருக்கலாம். mdadm --detail அதன் RaidDevice column-ல் உண்மையான slot-ஐக் காட்டும், எனவே வித்தியாசம் முக்கியமாக இருக்கும்போது அதைப் பயன்படுத்தவும்.
  • ஒரு உறுப்பினருக்குப் பின் வரும் (F) என்பது அது பழுதடைந்துள்ளது என்பதைக் குறிக்கும். (S) என்பது spare: அதாவது அது உள்ளது, ஆனால் சும்மா இருக்கிறது, ஏதேனும் பழுதடையும் வரை காத்திருக்கிறது.
  • 3906764800 blocks super 1.2 என்பது 1 KiB blocks-ல் பயன்படுத்தக்கூடிய அளவு, அதைத் தொடர்ந்து metadata format உள்ளது.
  • 512K chunks 2 near-copies என்பது stripe chunk size மற்றும் RAID 10 layout ஆகும்; இது ஒவ்வொரு block-ன் இரண்டு பிரதிகளை அருகருகே வைத்திருக்கும்.
  • [4/4] என்பது array எதிர்பார்க்கும் உறுப்பினர்களின் எண்ணிக்கை, அதைத் தொடர்ந்து தற்போது sync-ல் உள்ள எண்ணிக்கை உள்ளது.
  • [UUUU] என்பது ஒவ்வொரு slot-க்கும் ஒரு குறியீடு, slot வரிசையில் இருக்கும். U என்பது சரியாக இயங்கும் மற்றும் sync-ல் உள்ள slot. _ என்பது எவ்வித செயல்பாடும் இல்லாத slot.
  • bitmap: என்பது write intent bitmap. இது எந்தெந்த பகுதிகள் எழுதப்படுகின்றன என்பதைப் பதிவு செய்யும், இதனால் ஒரு உறுப்பினர் வெளியேறி மீண்டும் வரும்போது முழு drive-க்கும் பதிலாக அந்த குறிப்பிட்ட பகுதிகள் மட்டும் resync ஆகும்.

ஏதேனும் தவறு நடக்கும்போது [4/3] மற்றும் [UU_U] எதைக் குறிக்கின்றன

பழுதடைந்த 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]

இரண்டு அடைப்புக்குறிகளையும் சேர்த்து வாசிக்கவும். [4/3] என்பது நான்கு slot-களில் ஒன்று செயல்படவில்லை என்று கூறுகிறது. [UU_U] என்பது எது என்று காட்டுகிறது, ஏனெனில் underscore மூன்றாவது குறியீடாக உள்ளது மற்றும் slot-கள் பூஜ்ஜியத்திலிருந்து எண்ணப்படுகின்றன, எனவே slot 2 பழுதடைந்துள்ளது. (F) flag, பழுதடைந்த drive இன்னும் இணைக்கப்பட்டிருக்கும் வரை மட்டுமே அந்த device-ன் பெயரைக் காட்டும். அதை machine-லிருந்து அகற்றிவிட்டால், அந்தப் பெயர் வரியிலிருந்து மறைந்துவிடும், ஆனால் underscore அப்படியே இருக்கும்.

இவை அனைத்திலும் array தொடர்ந்து இயங்கும், RAID 10-ல் இது பெரும்பாலும் முழு வேகத்திலேயே இயங்கும், அதனால்தான் யாரும் இதை உணர்வதில்லை. ஏதேனும் ஒன்று உங்களுக்குத் தெரிவிக்க வேண்டும்.

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

mdadm package ஒரு monitor daemon-ஐ நிறுவுகிறது, அது /etc/mdadm/mdadm.conf-லிருந்து MAILADDR-ஐ வாசிக்கும். releases-க்கு இடையே unit-ன் பெயர் மாறியுள்ளதால், ஊகிப்பதற்குப் பதிலாக கடைசி command மூலம் அதைக் கண்டறியவும். --test இயக்கம் ஒவ்வொரு array-க்கும் உடனடியாக ஒரு செய்தியை அனுப்பும். அதற்குப் பிறகு inbox காலியாக இருந்தால், mail path பழுதடைந்துள்ளது என்று அர்த்தம், எனவே உங்களுக்குத் தேவையான முக்கியமான செய்தியும் அதேபோல் தொலைந்திருக்கும்.

மாற்றீடு (replacement) rebuilding ஆகும்போது, array-க்குக் கீழே ஒரு progress வரி தோன்றும்.

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 என்பது ஒரு மாற்று drive-ல் நடக்கும் rebuild ஆகும். resync என்பது புதிதாக உருவாக்கப்பட்ட array-ல் நடக்கும் முதல் consistency pass ஆகும். check என்பது நீங்கள் மேலே தூண்டிய scrub ஆகும். அடைப்புக்குறிக்குள் உள்ள ஜோடி, per-device total-க்கு எதிராக 1 KiB blocks-ல் உள்ள முன்னேற்றம் ஆகும், மேலும் finish என்பது தற்போதைய வேகத்தில் kernel-ன் மதிப்பீடு ஆகும். அந்த வேகம் /proc/sys/dev/raid/speed_limit_min மற்றும் speed_limit_max மூலம் கட்டுப்படுத்தப்படுகிறது, rebuild-ஆல் production I/O பாதிக்கப்படக்கூடாது என்பதற்காகவே இந்தக் கட்டுப்பாடுகள் உள்ளன.

Rebuild-ன் போது ஒரு முழுமையான mdadm --detail
/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

Number column என்பது /proc/mdstat-ல் அடைப்புக்குறிக்குள் அச்சிடப்பட்ட metadata index ஆகும். RaidDevice column என்பது slot, இது [UU_U] string-ல் உள்ள இடமாகும். இவை இங்கே மாறுபடுகின்றன, ஏனெனில் device 4, slot 2-ல் இருந்த drive-ஐ மாற்றியது. set-A மற்றும் set-B ஆகியவை ஒவ்வொரு mirror-ன் இரண்டு பாதிகளையும் குறிக்கின்றன, எனவே ஒரே ஜோடியில் உள்ள set-A மற்றும் set-B உறுப்பினர்கள் ஒரே தரவை வைத்திருக்கும், அவற்றை ஒன்றாக இழக்கக்கூடாது.

உங்களுக்குச் சொந்தமான array-ல் ஒரு drive-ஐ மாற்றுவது நான்கு command-களை உள்ளடக்கியது, கடைசி command சரிபார்ப்பிற்கானது.

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 வரி ஒன்று அல்லது இரண்டு வினாடிகளுக்குள் தோன்ற வேண்டும். மாற்று partition, mdadm --detail-லிருந்து Used Dev Size-ஐ விடப் பெரியதாக இருக்க வேண்டும், சற்றே சிறியதாக இருந்தாலும் not large enough to join array என்ற வடிவத்தில் ஒரு செய்தியுடன் அது நிராகரிக்கப்படும். புதிய drive-ஐச் சேர்ப்பதற்கு முன், பழைய drive-க்கு ஏற்ப அதை partition செய்யவும்.

VPS-க்குள் உங்களால் எதைப் பார்க்க முடியும், எதைப் பார்க்க முடியாது

பெரும்பாலான விருந்தினர் (guest) கணினிகளால் host-ன் RAID-ஐப் பார்க்க முடியாது, இது வடிவமைப்பிலேயே அவ்வாறு செய்யப்பட்டுள்ளது. Hypervisor உங்களுக்கு ஒரு virtual disk-ஐ மட்டுமே வழங்குகிறது. அந்த disk, NVMe drives கொண்ட RAID 10 தொகுப்பிலிருந்து பிரிக்கப்பட்டதா அல்லது ஒரே ஒரு 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 வகையையும், bare metal-ல் none-ஐயும் காட்டும். KVM guest-ல் பொதுவாக lsblk-ல் ஒரே ஒரு vda அல்லது sda மட்டுமே தெரியும். guest-க்குள் arrays எதுவும் இல்லாததால், /proc/mdstat-ல் எந்த arrays-ம் காட்டப்படாது.

Container அடிப்படையிலான VPS-ல் கிடைக்கும் தகவல்கள் நம்பகமானவை அல்ல. Containers-கள் host kernel-ஐப் பகிர்ந்துகொள்வதால், /proc-ன் சில பகுதிகள் namespaced செய்யப்படுவதில்லை. எனவே, அங்கு நீங்கள் வாசிக்கும் தகவல்கள் உங்கள் slice-ஐ விட host-ஐப் பற்றியதாக இருக்கலாம். உங்கள் storage-ஐப் பொறுத்தவரை எதையும் உண்மையாகக் கருத வேண்டாம். உங்கள் storage அமைப்பு என்னவென்று service provider-இடம் கேட்டுத் தெரிந்துகொள்ளுங்கள்; அது உங்களுக்கு முக்கியமென்றால், அதை எழுத்துப்பூர்வமாகப் பெற்றுக்கொள்ளுங்கள்.

உங்களுக்கு வழங்கப்பட்ட disk-ன் செயல்பாட்டை மட்டும் உங்களால் உள்ளிருந்து சரிபார்க்க முடியும். உங்கள் VPS disk உண்மையில் NVMe தானா என்பதைச் சரிபார்த்தல் பகுதியில் உண்மையான தகவல்களைத் தரும் கட்டளைகள் விளக்கப்பட்டுள்ளன. SSD VPS-ல் உண்மையில் என்ன உள்ளடங்கியுள்ளது பகுதியில், திட்டப் பக்கத்தில் (plan page) குறிப்பிடப்பட்டுள்ள லேபிள்களின் உண்மைத்தன்மை விளக்கப்பட்டுள்ளது.

உங்கள் VPS-க்குள் RAID-ஐ இயக்க வேண்டுமா?

பொதுவாகத் தேவையில்லை. இதற்கான காரணம் failure domains ஆகும். நீங்கள் இரண்டு volumes-ஐ ஒரே VPS-ல் இணைத்து mdadm மூலம் mirror செய்தால், அந்த இரண்டு volumes-ம் ஒரே physical array-ல், ஒரே node-ல், ஒரே power supply-ன் பின்னால் இருக்கக்கூடும். நீங்கள் ஏற்கனவே பெற்றிருக்கும் redundancy-க்காக ஒவ்வொரு write-க்கும் செலவை இரண்டு மடங்காக்குவீர்கள்; ஆனால், முக்கியமான ஒரு failure ஏற்படும்போது இரண்டு பிரதிகளையும் இழக்க நேரிடும்.

Volumes வெவ்வேறு failure domains-ல் இருப்பதாக உங்கள் provider ஆவணப்படுத்தியிருந்தால், அல்லது நீங்கள் drives-ஐ நேரடியாகக் குறிப்பிடக்கூடிய dedicated server-ல் இருந்தால் மட்டுமே இதைச் செய்வது பயனுள்ளது. மற்றபடி, இந்த முயற்சியை அந்த machine-ஐ விட்டு வெளியே செல்லும் பிரதிகளில் (backups) முதலீடு செய்வது அதிகப் பலன் தரும்.

RAID எவற்றிலிருந்து உங்களைப் பாதுகாக்காது

RAID ஒரே ஒரு நிகழ்வை மட்டுமே கையாள்கிறது: ஒரு drive சரியாகச் செயல்படாமல் நின்றுவிடுவது. கீழே உள்ள அனைத்தும் முறையான write செயல்பாடுகள் என்பதால், array அவற்றை ஒவ்வொரு நகலிலும் செயல்படுத்தி, தன்னை ஆரோக்கியமானதாகவே காட்டிக்கொள்ளும்.

  • நீக்கம் (Deletion). தவறான directory-ல் rm -rf செய்வது, அல்லது path-ல் variable-ஐ set செய்யாத ஒரு deploy script. Array இதை ஒரு முறையான write-ஆகக் கருதி, இரண்டு இடங்களிலும் செயல்படுத்திவிடும்.
  • Ransomware. Encryption என்பது ஒரு write செயல்பாடு. ஆரோக்கியமான array ஒன்று, mirror-ன் இரண்டு பகுதிகளிலும் encrypted செய்யப்பட்ட கோப்பையே சேமிக்கும்.
  • பழுதடைந்த application. உங்கள் database-ல் குப்பையான தரவுகளை எழுதும் ஒரு bug, அதே குப்பையை redundant drive-லும் எழுதிவிடும்.
  • முழு node-ம் செயலிழத்தல். ஒரு host செயலிழப்பது அல்லது தவறுதலாக ஒரு account முடக்கப்படுவது. ஒரு array மிகச்சரியாக இருந்தாலும், அதை அணுக முடியாமல் போகலாம்.
  • நீங்கள் செய்த தவறு. திங்கட்கிழமை நீங்கள் நீக்கிய கோப்பு, திங்கட்கிழமையே அனைத்து drive-களிலிருந்தும் நீக்கப்பட்டுவிடும். அதற்கு முன்னால் எடுக்கப்பட்ட ஒரு நகல் மட்டுமே அதை மீட்டெடுக்க உதவும்.

ஒரே storage-ல் எடுக்கப்படும் snapshots-ம் இதற்குத் தீர்வாகாது. அவை நீக்கத்தைத் தடுக்க உதவலாம், ஆனால் அவை எந்த array-ல் இருக்கின்றனவோ, அந்த array பழுதடைந்தால் அவையும் அழிந்துவிடும். ஒரு backup-ஐ உண்மையான backup-ஆக மாற்றுவது, அது வேறொரு இடத்தில் இருப்பதுதான். restic மூலம் server-க்கு வெளியே encrypted செய்யப்பட்ட backups என்பது இந்தப் பக்கத்தின் மற்றொரு பகுதி: ஒரு drive பழுதடைந்தாலும் array தொடர்ந்து சேவையை வழங்கும், அதே சமயம் array மகிழ்ச்சியுடன் செய்த ஒரு write செயல்பாட்டினால் தரவு சேதமடைந்தால், restic அதை மீட்டெடுத்துத் தரும்.

FAQ

RAID 10 இருந்தால் எனக்கு backup தேவையில்லையா?

தேவை. ஒரு drive செயலிழந்தால் RAID 10 அதிலிருந்து பாதுகாக்கும். இது ஒவ்வொரு சரியான write-ஐயும் mirror-ன் இரண்டு பகுதிகளிலும் ஒரே நேரத்தில் பதிவு செய்யும். எனவே, ஒரு கோப்பை நீக்கினாலோ அல்லது ransomware தாக்குதல் நடந்தாலோ, அது உடனடியாக redundant drive-லும் பிரதிபலிக்கும். array-ன் பார்வையில் எந்தப் பிழையும் நடக்காததால், அது தொடர்ந்து இயங்கும். எனவே, machine-க்கு வெளியே தனிப்பட்ட backup-கள் அவசியம்; மேலும், அவை சரியாக வேலை செய்கின்றனவா என்பதை அவ்வப்போது restore செய்து சரிபார்க்க வேண்டும்.

VPS வழங்குநர்கள் ஏன் RAID 5 அல்லது RAID 6-க்கு பதிலாக RAID 10-ஐத் தேர்ந்தெடுக்கிறார்கள்?

இதற்கு இரண்டு காரணங்கள் உள்ளன, இரண்டுமே சிறிய random write செயல்பாடுகளைச் சார்ந்தவை. parity write செய்யும்போது, புதிய parity-ஐக் கணக்கிடுவதற்கு முன்பு பழைய தரவுகளையும் பழைய parity-யையும் மீண்டும் படிக்க வேண்டும். இதனால், ஒரு சிறிய write-க்கு RAID 5-ல் 4 செயல்பாடுகளும், RAID 6-ல் 6 செயல்பாடுகளும் தேவைப்படுகின்றன. ஆனால், mirror-ல் இதற்கு 2 மட்டுமே தேவை. மேலும், parity rebuild செய்யும்போது அனைத்து drive-களையும் முழுமையாகப் படிக்க வேண்டியிருக்கும், இது node-ல் உள்ள அனைத்து guest-களின் வேகத்தையும் பல மணிநேரம் குறைக்கும். மாறாக, RAID 10 rebuild-ல் ஒரு drive-லிருந்து மற்றொன்றுக்குத் தரவு நகலெடுக்கப்படும், மற்ற ஜோடிகள் பாதிக்கப்படாது. இதற்குப் பதிலாக, வழங்குநர்கள் சேமிப்புத் திறனில் பாதியை (raw NVMe-ல் 50%) இழக்கிறார்கள்.

/proc/mdstat-ல் [U_] அல்லது [UU_U] என்பதன் பொருள் என்ன?

ஒவ்வொரு குறியீடும் array-ல் உள்ள ஒரு slot-ஐக் குறிக்கும். U என்பது அந்த slot-ல் உள்ள drive சரியாக இயங்கி sync-ல் இருப்பதைக் குறிக்கும். _ என்பது அந்த slot-ல் எந்த drive-ம் வேலை செய்யவில்லை என்பதைக் குறிக்கும். இரண்டு drive கொண்ட mirror-ல் [U_] என்பது இரண்டாவது slot செயலிழந்துள்ளதையும், redundancy இல்லை என்பதையும் குறிக்கும். இதை அதன் முன்னால் உள்ள ஜோடியுடன் சேர்த்துப் பார்க்க வேண்டும்; உதாரணமாக, [4/3] என்பது array-க்கு நான்கு உறுப்பினர்கள் தேவை, ஆனால் மூன்று மட்டுமே உள்ளன என்பதைக் குறிக்கும். slot வரிசை என்பது mdadm --detail-ன் RaidDevice column-ஐப் பொறுத்தது, வரியில் உள்ள device பெயர்களின் வரிசையை அல்ல.

RAID 10 array-ல் எத்தனை drive-கள் செயலிழந்தால் தாங்கும்?

எந்தவொரு அமைப்பிலும் ஒரு drive செயலிழந்தால் தாங்கும். அதற்கு மேல், செயலிழப்பு எந்தெந்த drive-களில் நிகழ்கிறது என்பதைப் பொறுத்தது. ஒவ்வொரு mirror ஜோடியிலும் ஒரு drive செயலிழந்தால் தாங்கும். எனவே, எட்டு drive கொண்ட array-ல், ஒவ்வொரு ஜோடியிலும் தலா ஒரு drive என மொத்தம் நான்கு drive-கள் செயலிழந்தாலும் தாங்கும். ஆனால், ஒரே ஜோடியில் இரண்டு drive-கள் செயலிழந்தால் array முழுமையாக முடங்கிவிடும். எனவே, ஒரு drive வரை மட்டுமே பாதுகாப்பு உண்டு என்று திட்டமிடுங்கள்; அதற்கு மேல் நடப்பது அதிர்ஷ்டமே தவிர பாதுகாப்பு அல்ல.

எனது VPS-க்குள் mdadm மூலம் இரண்டு volume-களை mirror செய்ய வேண்டுமா?

பொதுவாகத் தேவையில்லை. ஒரு VPS-ல் இணைக்கப்பட்டுள்ள இரண்டு volume-களும் பெரும்பாலும் ஒரே host-ல் உள்ள ஒரே physical array-ல் தான் இருக்கும். எனவே, அவற்றை mirror செய்வது ஒவ்வொரு write செயல்பாட்டின் செலவையும் இரட்டிப்பாக்கும், ஆனால் host-ன் RAID ஏற்கனவே வழங்கும் பாதுகாப்பைத் தாண்டி இது எதையும் வழங்காது. அந்த volume-கள் வெவ்வேறு failure domain-களில் இருப்பதாக வழங்குநர் உறுதிப்படுத்தினால் மட்டுமே இதைச் செய்யலாம். இல்லையெனில், அந்த முயற்சியை machine-க்கு வெளியே backup எடுப்பதில் செலவிடுவது சிறந்தது.