VPS storage కోసం RAID 10 అంటే ఏమిటి?

RAID 10 అంటే ఏమిటి, VPS hostలు దీన్ని ఎందుకు ఉపయోగిస్తాయి

RAID 10 అనేది virtualised NVMe (non-volatile memory express) drivesపై చాలా VPS hostలు ఉపయోగించే storage layout. ఇది ప్రతి driveను ఒక భాగస్వామి driveపై mirror చేసి, ఆ mirrored pairs మధ్య dataను stripe చేస్తుంది. ఒక drive విఫలమైనా array ఆగదు. Repair సమయంలో setలోని మిగిలిన ప్రతి driveను చదివి మళ్లీ లెక్కించాల్సిన అవసరం ఉండదు. బతికి ఉన్న భాగస్వామి drive నుంచి సాధారణంగా copy చేస్తే సరిపోతుంది.

RAID అంటే redundant array of independent disks. దీని ఒకే పని disk విఫలమైనప్పుడు లేదా దాన్ని మార్చుతున్నప్పుడు కూడా machine సేవలను కొనసాగించడం. ఆ పని availabilityకు సంబంధించినది. Availability అనేది safety కాదు.

RAID మీ writesను replicate చేస్తుంది. rm -rf /srv కూడా ఒక write. Mirrorలోని రెండు భాగాలు అదే millisecondలో directoryని తొలగిస్తాయి. అయినప్పటికీ array తరువాత కూడా తనను తాను cleanగా చూపిస్తుంది.

ఆ వాక్యాన్ని గుర్తుంచుకోండి. ఈ పేజీలోని మిగిలిన భాగాలు ప్రతి level ఏ పరిస్థితులను తట్టుకుంటుందో, ప్రతి writeపై దానికి మీకు అయ్యే ఖర్చు ఏమిటో వివరిస్తాయి. చివరి sectionsలో మీ సొంత machineలో array స్థితిని చూడటానికి ఉపయోగించే commands, అలాగే RAID ఎప్పుడూ పరిష్కరించలేని failure గురించి ఉన్నాయి.

హోస్టింగ్ కొనుగోలుదారు వాస్తవంగా ఎదుర్కొనే స్థాయులు: 1, 5, 6 మరియు 10

ప్లాన్ పేజీలో ఒక సంఖ్యను పేర్కొని అక్కడితో ఆపేస్తారు. ఆ సంఖ్య రెండు ప్రశ్నలకు సమాధానం ఇస్తుంది: ఎన్ని drives విఫలమైనా వ్యవస్థ కొనసాగుతుంది, అలాగే ప్రతి write కు ఎంత వ్యయం ఉంటుంది.

RAID 1 ఒక mirror. రెండు drives లో ఒకే blocks ఉంటాయి. ప్రతి write రెండు drives కు వెళ్తుంది. Read ను ఏ drive అయినా అందించగలదు. ఒక drive విఫలమైనా data loss ఉండదు; raw capacity లో సగం మాత్రమే ఉపయోగించగలము. Parity లెక్కించాల్సిన అవసరం లేదు కాబట్టి write path చిన్నగా ఉంటుంది.

RAID 5 అనేది ప్రతి stripe కు ఒక parity block తో చేసే striping. n drives ఉంటే, వాటిలో n-1 drives సామర్థ్యానికి సమానమైన capacity లభిస్తుంది; array ఖచ్చితంగా ఒక drive failure ను తట్టుకుంటుంది. Parity ఒకే dedicated drive లో ఉండదు. అది అన్ని drives మధ్య మారుతూ ఉంటుంది. అందువల్ల ప్రతి drive data మరియు parity రెండింటినీ కలిగి ఉంటుంది.

RAID 6 ప్రతి stripe కు రెండవ, స్వతంత్ర parity block ను జోడిస్తుంది. వీటిని సాధారణంగా P మరియు Q అని రాస్తారు. ఒకేసారి ఏ రెండు drives విఫలమైనా ఇది తట్టుకుంటుంది. ఇది వినిపించేంతకంటే ముఖ్యమైన విషయం, ఎందుకంటే మొదటి drive ను repair చేస్తున్న సమయంలోనే రెండవ failure ఎక్కువగా సంభవిస్తుంది.

RAID 10 అనేది mirrors యొక్క stripe. Drives ను జంటలుగా mirror చేస్తారు, తరువాత ఆ జంటల మధ్య data ను పంపిణీ చేస్తారు. Usable capacity raw total లో సగం ఉంటుంది. ఇది RAID 1 కు సమానం, అయితే దానికి striping యొక్క parallelism కూడా ఉంటుంది.

దీనిని RAID 1+0 అని కూడా రాస్తారు. అదే సరైన వివరణ: ముందుగా mirror చేసి, తరువాత mirrors పై stripe చేయడం. RAID 0+1 లో క్రమం తారుమారుగా ఉంటుంది: ముందుగా stripe చేసి, తరువాత ఆ రెండు stripes ను mirror చేస్తారు. ఇది తక్కువ ప్రయోజనకరం, ఎందుకంటే ఒక drive failure మొత్తం stripe ను సేవకు దూరం చేస్తుంది. Repair సమయంలో మొత్తం మరో వైపు copy చేయాలి.

Linux ఒక ప్రత్యేక సందర్భం. తెలుసుకోవాల్సిన విషయం ఇది. Kernel యొక్క raid10 రెండు layers ను వరుసగా అమర్చిన నిర్మాణం కాకుండా ఒకే personality గా పనిచేస్తుంది. అందువల్ల ఇది బేసి సంఖ్యలో drives పై కూడా నడుస్తుంది. Nested setup లో వ్యక్తపరచలేని layouts (near, far, offset) కూడా దీనిలో ఉన్నాయి. అందుకే 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 usable space, RAID 10 కింద 4 TB usable space లభిస్తుంది. ఈ తేడా వాస్తవమైన ఖర్చు తేడా. అందుకే parity పరిష్కారంగా పదేపదే ప్రతిపాదించబడుతుంది. ఏ విధమైన pattern లోనైనా RAID 6 2 failures ను తట్టుకుంటుంది. RAID 10 మాత్రం 1 మాత్రమే హామీ ఇస్తుంది, ఎందుకంటే ఇప్పటికే విఫలమైన drive కు జతగా ఉన్న drive పై రెండవ failure సంభవించడమే ప్రమాదకరం. ఏ రెండు failures ఒకే జంటలో సంభవించనప్పుడు ఇది గరిష్ఠంగా 4 failures ను తట్టుకుంటుంది. అయితే అది design property కాదు; అదృష్టంపై ఆధారపడుతుంది.

ప్రతి write కు ప్రతి level అయ్యే ఖర్చు

mirror కు చేసే write ఒకేసారి రెండు members కు జారీ చేసే రెండు writes గా మారుతుంది. parity stripe కు చేసే write మరింత పని కలిగిస్తుంది, ఎందుకంటే ఆ stripe లోని parity block ఇక సరైనది కాదు, దాన్ని మళ్లీ లెక్కించాలి.

కొత్త block ను మాత్రమే ఉపయోగించి controller parity ని మళ్లీ లెక్కించలేదు. ముందుగా పాత 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
  }
]

ఒక చిన్న random write కు RAID 6లో 6 device operations, RAID 10లో 2 device operations అవసరం. అయితే ఈ సంఖ్యలు latency లోని తేడాను తక్కువగా చూపుతాయి. రెండు mirror writes parallel గా పంపబడతాయి. కాబట్టి guest, ఆ రెండింటిలో నెమ్మదైనది పూర్తయ్యే వరకు వేచి ఉంటుంది. parity మార్గంలో, కొత్త parity లెక్కించడానికి ముందుగా ఒక read పూర్తవ్వాలి. అందువల్ల guest ముందుగా read కోసం, తరువాత write కోసం వరుసగా వేచి ఉంటుంది. Host busy గా ఉన్నప్పుడు ఆ read, ఇతరుల I/O వెనుక queue లో వేచి ఉంటుంది.

దీనికి ఒక ముఖ్యమైన మినహాయింపు ఉంది. ఒక write మొత్తం stripe ను నింపేంత పెద్దదిగా ఉంటే పాత data అవసరం లేదు, ఎందుకంటే stripe లోని ప్రతి block భర్తీ అవుతుంది. ఇప్పటికే memory లో ఉన్న data నుంచి parity లెక్కించబడుతుంది. అప్పుడు ఖర్చు ఒక అదనపు write కు తగ్గుతుంది. అందుకే sequential benchmark లో RAID 5 బాగానే కనిపిస్తుంది. కానీ అనేక tenants నుంచి వచ్చే చిన్న writes తో కూడిన mixed load లో అది సరిగా పనిచేయదు. మీరు వాస్తవంగా నడిపే pattern ను పరీక్షించండి: VPS disk ను సరిగ్గా benchmark చేయడం అంటే వాస్తవిక queue depth తో random I/O పరీక్షించడం, ఒక పెద్ద dd పరీక్షించడం కాదు.

పునర్నిర్మాణం ఎందుకు ప్రమాదకరమైన భాగం

Parity rebuild సమయంలో మిగిలిన మొత్తం డేటాను ఉపయోగించి తప్పిపోయిన drive ను పునర్నిర్మించాలి. అందువల్ల మొదటి block నుంచి చివరి block వరకు 7 మిగిలిన drives ను చదవాలి. RAID 10 rebuild 1 మాత్రమే చదువుతుంది: పనిచేయని drive కు mirror partner అయిన drive ను మాత్రమే చదువుతుంది.

దీని వల్ల రెండు ఖర్చులు వస్తాయి. మొదటిది సమయం. Rebuild వేగం slowest surviving drive వేగం మరియు దానిపై జరిగే parity లెక్కలతో పరిమితం అవుతుంది. రెండవది load. Parity set లోని ప్రతి drive మొత్తం rebuild వ్యవధిలో busyగా ఉంటుంది. అందువల్ల అది పూర్తయ్యే వరకు ఆ node పైని ప్రతి guest కు latency పెరుగుతుంది. RAID 10లో ఒక జత మాత్రమే busyగా ఉంటుంది. మిగిలిన జతలు సాధారణ వేగంతో సేవలు అందిస్తాయి.

అదే సమయంలో data correctnessకు కూడా ప్రమాదం ఉంటుంది. ఒక drive పనిచేయని RAID 5 arrayలో redundancy మిగలదు. అందువల్ల surviving driveలో ఎక్కడైనా unreadable sector ఉంటే దాన్ని ఇక recover చేయలేరు. Rebuild సమయంలో ప్రతి sector చదవబడుతుంది. ఒక సంవత్సరం నుంచి ఎవరూ ఉపయోగించని sectorలు కూడా చదవబడతాయి. ప్రచురిత datasheet గణాంకాల ప్రకారం, consumer hard driveలో ప్రతి 10^14 bits చదివినప్పుడు దాదాపు ఒక unrecoverable read error సంభవించవచ్చు. Enterprise NVMe driveలో ఇది ప్రతి 10^17 bitsకు ఒకటి లేదా అంతకంటే మెరుగ్గా ఉండవచ్చు. ఇవి కొలతలపై ఆధారపడిన గణాంకాలు కాకుండా vendor specifications. అయినప్పటికీ, ఈ నిష్పత్తి పాత spinning disks పెద్దవిగా ఉన్న కాలంలో RAID 5 rebuild విఫలమవుతుందని హెచ్చరిక ఎందుకు వచ్చిందో వివరిస్తుంది. NVMeలో ఆ హెచ్చరిక ఎందుకు చాలా తక్కువగా వర్తిస్తుందో కూడా ఇది చూపిస్తుంది. Loadకు సంబంధించిన సమస్య ఏ mediumలోనైనా ఉంటుంది.

Rebuild ప్రారంభం కాకముందే latent errors ను scrub ద్వారా గుర్తించండి. Debian మరియు Ubuntu, md arrays కోసం periodic scrub అందిస్తాయి. ఈ విధానం releases మధ్య మారుతుంది. అందువల్ల మీ వద్ద ఏ విధానం ఉందో పరిశీలించి, ఆ తర్వాత చేతితో ఒక 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లో zero కంటే ఎక్కువ సంఖ్య ఉంటే, దాని రెండు భాగాలు పరస్పరం సరిపోలడం లేదని అర్థం. ఏ copy సరైనదో kernel చెప్పలేకపోతుంది, ఎందుకంటే ఏ copyలోనూ checksum ఉండదు. కొన్ని mismatches హానికరం కావు. సాధారణంగా swap partitions ఇందుకు కారణమవుతాయి. Kernel ఒక pageను రాస్తున్న సమయంలో అది మారిపోవచ్చు. Data arrayలో count పెరుగుతుంటే ఆ driveను replace చేయాలి.

NVMe కోసం VPS providerలు RAID 10 ను ఎందుకు ప్రామాణీకరిస్తాయి

ఒక hypervisor node ఒక్క workload ను మాత్రమే నడపదు. అది పరస్పర సంబంధం లేని డజన్ల కొద్దీ guests ను నడుపుతుంది. వాటి I/O పరస్పరంగా కలిసిన చిన్న writes stream గా వస్తుంది. ఈ writes మధ్య locality ఉండదు. parity read-modify-write cycle కు అత్యధిక ఖర్చు వచ్చే pattern ఇదే. shared node లో రోజంతా కనిపించే pattern కూడా ఇదే.

Rebuild ప్రవర్తనను కూడా పరిగణనలోకి తీసుకుంటే ఎంపిక స్పష్టమవుతుంది. parity node లో ఒక drive విఫలమైతే ఆ box లోని ప్రతి guest గంటల తరబడి నెమ్మదిస్తుంది. RAID 10 node లో ఒక drive విఫలమైతే ఒక్క pair మాత్రమే నెమ్మదిస్తుంది. Copy drive వేగంతో sequential గా నడుస్తుంది. Providers latency పెరగకుండా ఉండే సేవను విక్రయిస్తారు. అందుకోసం capacity ను వినియోగిస్తారు: raw NVMe లో సగం mirror కోసం కేటాయించబడుతుంది.

Drive పరిమాణాలు కూడా ఇదే దిశగా ప్రభావితం చేస్తాయి. Drives పెద్దవిగా మారిన కొద్దీ rebuild window ఎక్కువవుతుంది. parity లో ఆ window సమయంలో ప్రతిదీ నెమ్మదిగా ఉంటుంది, ఏదీ protected గా ఉండదు. Virtualisation కోసం ZFS deployments wide raidz కు బదులుగా mirrored vdevs pools ను ఉపయోగించడానికి ఇదే కారణం. Mirror resilver ఒక pair లో వాస్తవంగా ఉపయోగంలో ఉన్న blocks ను మాత్రమే copy చేస్తుంది.

దీంతో ప్రతి సందర్భంలో RAID 10 సరైనదని అర్థం కాదు. Backup target కు దీర్ఘమైన sequential runs గా writes వస్తాయి, reads అరుదుగా జరుగుతాయి. అందువల్ల అక్కడ RAID 6 మెరుగైన ఎంపిక. ఇది రెండు failures ను తట్టుకుంటుంది, అలాగే capacity లో ఎక్కువ భాగాన్ని తిరిగి అందిస్తుంది. నిర్ణయం workload ఆధారంగా తీసుకోవాలి, సంఖ్య ఆధారంగా కాదు. ఈరోజు మీరు ఎంచుకుంటున్న plan కోసం, పైభాగంలో ఉన్న layout కంటే medium సాధారణంగా ముఖ్యమైనది. ఏ RAID layout లోనైనా SATA SSD నుంచి NVMe కు మారడం వల్ల కలిగే వ్యత్యాసం, RAID మధ్య ఉన్న ఏ వ్యత్యాసం కంటే ఎక్కువగా ఉంటుంది; SATA SSD నుంచి NVMe కు మార్పు దీనికి ఉదాహరణ.

/proc/mdstat ను ఎలా చదవాలి

మీకు చెందిన array ఉన్న యంత్రంలో వీటిని అమలు చేయండి: dedicated server, ఇంటి వద్ద ఉన్న machine లేదా మీరు స్వయంగా రెండు volumes జతచేసి ఏర్పాటు చేసిన VPS. మీ స్వంత output ను చదవండి. మీరు పొందే output ఆకృతితో సరిపోల్చుకోగలిగేలా కింది blocks ఉదాహరణలుగా పూర్తిగా చూపించబడ్డాయి.

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

నాలుగు drives కలిగిన ఆరోగ్యకరమైన 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 ద్వారా running kernel లో load అయిన md modules జాబితా కనిపిస్తుంది. అక్కడ raid10 కనిపించడం అంటే ఆ code అందుబాటులో ఉందని మాత్రమే; అంతకంటే మరేమీ కాదు.
• md0 : active raid10 array device, దాని state మరియు level ను చూపిస్తుంది.
• దాని తరువాతి పేర్లు members. Square brackets లోని సంఖ్య array metadata లో ఆ device కు ఉన్న index. అది line లోని స్థానం కాదు, ఎల్లప్పుడూ దాని slot కూడా కాదు.
• Drive replacement తర్వాత కొత్త member సాధారణంగా అది భర్తీ చేసిన slot కంటే ఎక్కువ index ను ఉంచుకుంటుంది. అందువల్ల nvme4n1p3[4] slot 2లో ఉండవచ్చు. mdadm --detail తన RaidDevice column లో అసలు slot ను చూపిస్తుంది. తేడా ముఖ్యమైనప్పుడు దానినే ఉపయోగించండి.
• Member తర్వాతి (F) అంటే అది faulty అని అర్థం. (S) అంటే spare: అందుబాటులో ఉంది, idleగా ఉంది, ఏదైనా విఫలమయ్యే వరకు వేచి ఉంది.
• 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కు ఒక character చొప్పున, slot క్రమంలో చూపిస్తుంది. U అంటే ఆ slot upలో ఉండి syncలో ఉందని అర్థం. _ అంటే ఆ slotలో పనిచేస్తున్నది ఏదీ లేదని అర్థం.
• bitmap: write intent bitmap. ఏ regionsలో 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లో ఒకటి data అందించడం లేదని అర్థం. అది ఏదో [UU_U] చూపిస్తుంది. Underscore మూడవ character కాబట్టి, slotsను zero నుంచి లెక్కించినప్పుడు slot 2 downలో ఉంది. Failed drive ఇంకా attach అయి ఉన్నప్పుడు మాత్రమే (F) flag ఆ device పేరును చూపిస్తుంది. దాన్ని machine నుంచి తీసేస్తే line నుంచి ఆ పేరు మాయమవుతుంది, కానీ underscore అలాగే ఉంటుంది.

ఇవన్నీ జరిగినప్పటికీ array సేవలను అందిస్తూనే ఉంటుంది. RAID 10లో ఇది తరచుగా దాదాపు పూర్తి speedతో సేవలను అందిస్తుంది. అందువల్ల సాధారణంగా ఉపయోగిస్తున్నప్పుడు ఎవరూ గుర్తించరు. దీన్ని మీకు తెలియజేసే monitoring అవసరం.

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

mdadm package, /etc/mdadm/mdadm.conf నుంచి MAILADDR ను చదివే monitor daemonను install చేస్తుంది. Releases మధ్య unit name మారింది. కాబట్టి ఊహించకుండా చివరి commandతో దాన్ని కనుగొనండి. --test run ప్రతి arrayకు వెంటనే ఒక message పంపుతుంది. దాని తర్వాత inbox ఖాళీగా ఉంటే mail path విఫలమైందని అర్థం. మీరు నిజంగా చూడాల్సిన message కూడా అదే విధంగా పోయి ఉండేది.

Replacement 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. Parenthesesలోని జత, ప్రతి deviceకు ఉన్న totalతో పోల్చిన 1 KiB blocksలో progressను చూపిస్తుంది. finish ప్రస్తుత speed ఆధారంగా kernel ఇచ్చే estimate. ఆ speedను /proc/sys/dev/raid/speed_limit_min మరియు speed_limit_max పరిమితం చేస్తాయి. Rebuild production I/Oను అడ్డుకోకుండా ఉండేందుకు ఈ limits ఉంటాయి.

/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ను భర్తీ చేయడానికి నాలుగు commands అవసరం. చివరిది 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

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 driveలతో రూపొందించిన 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 లో అవి ఉండవు.

Container ఆధారిత VPS లో ఈ సమాచారం నమ్మదగినది కాదు. Containers host kernel ను పంచుకుంటాయి. /proc లోని కొన్ని భాగాలు namespace చేయబడవు. అందువల్ల అక్కడ మీరు చదివేది మీకు కేటాయించిన భాగం కంటే host ను వివరిస్తుండవచ్చు. ఈ సమాచారాన్ని మీ స్వంత storage గురించి వాస్తవంగా పరిగణించవద్దు. Layout ఏమిటో provider ను అడగండి. అది మీకు ముఖ్యమైతే సమాధానాన్ని లిఖితపూర్వకంగా పొందండి.

మీకు ఇచ్చిన disk యొక్క ప్రవర్తనను మాత్రం VPS లోపల నుంచి పరిశీలించవచ్చు. మీ 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 కు ఖర్చు రెట్టింపు అవుతుంది. అయినా ముఖ్యమైన ఒకే failure వల్ల రెండు copies ను కోల్పోతారు.

ఆ volumes వేర్వేరు failure domains లో ఉన్నాయని provider documentation స్పష్టంగా చెబితే RAID ఉపయోగకరంగా ఉంటుంది. మీరు drives పై నేరుగా నియంత్రణ కలిగిన dedicated server ఉపయోగిస్తున్నప్పుడు కూడా ఇది సముచితం. ఇతర సందర్భాల్లో, machine వెలుపలికి వెళ్లే copies పై కృషి చేయడం మరింత ప్రయోజనకరం.

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లో చెత్త data రాసే bug, అదే చెత్త dataను redundant driveలోనూ రాస్తుంది.
• మొత్తం node. విఫలమైన host, లేదా పొరపాటున suspend చేసిన account. array పూర్తిగా సక్రమంగా ఉండి, అదే సమయంలో అందుబాటులో లేకపోవచ్చు.
• ఒక వారం తరువాత మీరే. Mondayన తొలగించిన file, Mondayనే ప్రతి drive నుంచి తొలగిపోతుంది. అప్పటికి ముందు తీసిన copy మాత్రమే దాన్ని తిరిగి తీసుకురాగలదు.

అదే storageపై ఉన్న snapshots కూడా పరిష్కారం కావు. అవి deletionకు సహాయపడతాయి, కానీ అవి ఉన్న arrayతో పాటే నశిస్తాయి. backupను backupగా చేసే లక్షణం అది వేరే చోట ఉండటమే. resticతో encrypted off-server backups ఈ పేజీలోని మరో భాగం: dead drive ఉన్నప్పటికీ array మీ సేవలను కొనసాగిస్తుంది, కానీ array సంతోషంగా అమలు చేసిన write వల్ల నష్టం జరిగినప్పుడు restic మీ dataను తిరిగి పొందుతుంది.

FAQ

RAID 10 ఉంటే backups అవసరం ఉండవా?

లేదు. పని చేయడం ఆపిన drive నుంచి RAID 10 రక్షణ కల్పిస్తుంది. Mirror లోని రెండు భాగాలకు ప్రతి చెల్లుబాటు అయ్యే write ను ఒకేసారి వర్తింపజేస్తుంది. అందువల్ల deletion లేదా ransomware run జరిగినా, అదే క్షణంలో redundant drive‌కూ చేరుతుంది. ఆ తర్వాత array తనను తాను clean గా చూపిస్తుంది, ఎందుకంటే దాని దృష్టిలో ఏదీ విఫలం కాలేదు. Machine వెలుపల ఉండే copies మీకు ఇంకా అవసరం. అవి పనిచేస్తున్నాయని నిర్ధారించడానికి అప్పుడప్పుడు ఒక copy ను restore చేయాలి.

VPS providers RAID 5 లేదా RAID 6 బదులుగా RAID 10 ను ఎందుకు ఎంచుకుంటారు?

రెండు కారణాలు ఉన్నాయి. రెండూ small random writes కు సంబంధించినవే. కొత్త parity ను లెక్కించడానికి ముందుగా పాత data మరియు పాత parity ను చదవాలి. అందువల్ల small write కు RAID 5లో 4 operations, RAID 6లో 6 operations అవసరం అవుతాయి. Mirror లో మాత్రం 2 operations మాత్రమే అవసరం. Parity rebuild సమయంలో మిగిలిన ప్రతి drive ను మొదటి నుంచి చివరి వరకు చదవాలి. అందువల్ల node లోని ప్రతి guest గంటల పాటు నెమ్మదిస్తుంది. RAID 10 rebuild లో ఒక drive నుంచి మరో drive కు మాత్రమే copy చేస్తుంది. మిగిలిన pairs ప్రభావితం కావు. దీనికి providers capacity తో చెల్లించాలి: raw NVMeలో సగం capacity మాత్రమే ఉపయోగించగలరు.

/proc/mdstat లో [U_] లేదా [UU_U] అంటే ఏమిటి?

ప్రతి character array లోని ఒక slot ను సూచిస్తుంది. అవి slot order లో ఉంటాయి. ప్రతి slot కు ఒక character ఉంటుంది. U అంటే ఆ slot లో పనిచేస్తున్న, sync లో ఉన్న member ఉంది. _ అంటే ఆ slot లో పనిచేస్తున్న member ఏదీ లేదు. రెండు-drive mirror లో [U_] అంటే రెండవ slot down అయింది, redundancy ఇక లేదు. దీన్ని ముందు ఉన్న pair తో కలిపి చదవాలి. ఆ pair array నాలుగు members ను ఆశిస్తున్నదని, ప్రస్తుతం మూడు members ఉన్నాయని [4/3] ద్వారా చూపిస్తుంది. Slot order, mdadm --detail లోని RaidDevice column కు అనుగుణంగా ఉంటుంది. Line లో device names కనిపించే order కు అది అనుగుణంగా ఉండదు.

RAID 10 array ఎన్ని drives ను కోల్పోవచ్చు?

ఏ pattern లోనైనా ఒక drive ను కోల్పోవచ్చు. అంతకంటే ఎక్కువ failures ఎక్కడ సంభవించాయనే దానిపై ఆధారపడి ఉంటుంది. ప్రతి mirror pair లోని రెండు members లో ఒకదాన్ని కోల్పోవచ్చు. అందువల్ల ఎనిమిది-drive array లో ఒకే pair కు చెందిన రెండు drives fail కాకపోతే నాలుగు failures వరకు తట్టుకోగలదు. రెండు failures ఒకే pair ను తాకితే, రెండవ failure వద్ద array పనిచేయదు. హామీగా లభించే సంఖ్య ఒకటి కాబట్టి దాని ఆధారంగా planning చేయాలి. దాని కంటే ఎక్కువను protection గా కాకుండా అదృష్టంగా పరిగణించాలి.

నా VPS లో mdadm ఉపయోగించి రెండు volumes ను mirror చేయాలా?

సాధారణంగా వద్దు. ఒకే VPS కు attach చేసిన రెండు volumes తరచుగా ఒకే host లోని ఒకే physical array పై ఉంటాయి. అప్పుడు ప్రతి write ఖర్చు రెట్టింపు అవుతుంది. Host యొక్క స్వంత RAID ఇప్పటికే రక్షించలేని దేనినీ ఇది రక్షించదు. ఆ volumes వేర్వేరు failure domains లో ఉన్నాయని provider documentation ద్వారా నిర్ధారించినప్పుడు మాత్రమే ఇది ఉపయోగకరంగా ఉంటుంది. లేకపోతే machine వెలుపలికి వెళ్లే backups కోసం ఆ ప్రయత్నం చేయండి.