RAID 10 क्या है और VPS के लिए यह क्यों जरूरी है?

RAID 10 क्या है, और VPS होस्ट इसे क्यों चलाते हैं

RAID 10 वह स्टोरेज लेआउट है जिसे अधिकांश VPS होस्ट वर्चुअलाइज्ड NVMe (non-volatile memory express) ड्राइव्स पर चलाते हैं। इसके पारंपरिक दो-कॉपी लेआउट में, यह हर ड्राइव को उसके पार्टनर पर मिरर करता है, और फिर उन मिरर किए गए जोड़ों (pairs) पर डेटा को स्ट्राइप करता है। एक ड्राइव खराब होने पर भी ऐरे रुकता नहीं है, और इसकी मरम्मत में पूरे सेट की हर ड्राइव को पढ़ने के बजाय केवल जीवित पार्टनर से डेटा की सीधी कॉपी की जाती है।

RAID का अर्थ है redundant array of independent disks। इसका एक ही काम है: डिस्क खराब होने या बदले जाने के दौरान मशीन को चालू रखना। वह काम उपलब्धता (availability) है, और उपलब्धता सुरक्षा (safety) नहीं है।

RAID आपके राइट्स (writes) को रेप्लिकेट करता है। rm -rf /srv एक राइट है। मिरर के दोनों हिस्से एक ही मिलीसेकंड में डायरेक्टरी को डिलीट कर देते हैं, और उसके बाद भी ऐरे खुद को क्लीन रिपोर्ट करता है।

उस वाक्य को याद रखें। इस पेज का बाकी हिस्सा यह बताता है कि प्रत्येक लेवल किस तरह की विफलता को झेल सकता है और हर राइट पर इसकी क्या कीमत चुकानी पड़ती है। अंतिम सेक्शन में उन कमांड्स के बारे में बताया गया है जिनसे आप अपनी मशीन पर ऐरे का स्टेटस देख सकते हैं, और उस विफलता के बारे में बताया गया है जिसे RAID कभी कवर नहीं करता।

होस्टिंग खरीदार का सामना जिन स्तरों से होता है: 1, 5, 6 और 10

एक प्लान पेज केवल एक संख्या बताता है और वहीं रुक जाता है। यह संख्या दो सवालों के जवाब देती है: कितनी ड्राइव खराब हो सकती हैं, और हर write की लागत क्या है।

RAID 1 एक मिरर है। दो ड्राइव में समान ब्लॉक्स होते हैं। हर write दोनों पर जाती है। कोई भी ड्राइव read request पूरी कर सकती है। एक ड्राइव के खराब होने पर भी डेटा का नुकसान नहीं होता, और कुल raw capacity का आधा हिस्सा इस्तेमाल के योग्य होता है। इसमें गणना करने के लिए कोई parity नहीं होती, इसलिए write path छोटा होता है।

RAID 5 एक स्ट्राइप है जिसमें प्रति स्ट्राइप एक parity ब्लॉक होता है। n ड्राइव के साथ आपको n-1 ड्राइव जितनी क्षमता मिलती है, और ऐरे ठीक एक ड्राइव की विफलता को झेल सकता है। Parity किसी एक समर्पित ड्राइव पर नहीं रहती। यह सभी ड्राइव पर घूमती रहती है, इसलिए हर ड्राइव डेटा और parity दोनों रखती है।

RAID 6 प्रत्येक स्ट्राइप में एक दूसरा, स्वतंत्र parity ब्लॉक जोड़ता है, जिसे आमतौर पर P और Q के रूप में लिखा जाता है। यह एक साथ किन्हीं भी दो ड्राइव के खराब होने पर भी डेटा सुरक्षित रखता है। यह सुनने में जितना लगता है, उससे कहीं अधिक महत्वपूर्ण है, क्योंकि दूसरी विफलता अक्सर पहली विफलता की मरम्मत के दौरान ही आती है।

RAID 10 मिरर का एक स्ट्राइप है। ड्राइव को जोड़ों में मिरर किया जाता है, और डेटा को इन जोड़ों में फैलाया जाता है। इस्तेमाल योग्य क्षमता कुल raw capacity की आधी होती है, जो RAID 1 के समान है, साथ ही इसमें स्ट्राइपिंग का पैरेललिज्म भी मिलता है।

आप इसे RAID 1+0 के रूप में भी लिखा हुआ देखेंगे, जो कि इसका सही विवरण है: पहले मिरर करें, फिर मिरर के ऊपर स्ट्राइप करें। RAID 0+1 दूसरा क्रम है, जिसमें पहले स्ट्राइप किया जाता है और फिर दो स्ट्राइप्स को मिरर किया जाता है। यह खराब विकल्प है, क्योंकि एक ड्राइव के खराब होने से पूरी स्ट्राइप सेवा से बाहर हो जाती है और मरम्मत के लिए पूरी दूसरी साइड को कॉपी करना पड़ता है।

Linux एक विशेष मामला है जिसे जानना जरूरी है। कर्नेल का raid10 दो स्टैक्ड लेयर्स के बजाय एक एकल व्यक्तित्व है, इसलिए यह विषम संख्या में ड्राइव पर चलता है और इसमें ऐसे लेआउट (near, far, offset) होते हैं जिन्हें नेस्टेड सेटअप में व्यक्त नहीं किया जा सकता। यही कारण है कि Linux बॉक्स पर स्टेटस लाइन दो ऐरे का नाम लेने के बजाय 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 ड्राइव RAID 5 के तहत 7 TB और RAID 10 के तहत 4 TB इस्तेमाल योग्य स्थान देती हैं। यह अंतर वास्तविक धन का है, और यही कारण है कि parity का प्रस्ताव बार-बार दिया जाता है। RAID 6 किसी भी पैटर्न में 2 विफलताओं को झेल सकता है। RAID 10 केवल 1 की गारंटी देता है, क्योंकि खतरनाक दूसरी विफलता वह होती है जो पहले से खराब हो चुकी ड्राइव के पार्टनर पर आती है। यह 4 तक को झेल सकता है जब कोई भी दो विफलताएं एक ही जोड़े को प्रभावित न करें, जो कि डिजाइन की विशेषता के बजाय भाग्य पर निर्भर है।

प्रत्येक write पर हर स्तर की लागत

Mirror पर एक write का अर्थ है दो writes, जो एक ही समय पर दोनों members को जारी किए जाते हैं। Parity stripe पर write करना अधिक मेहनत का काम है, क्योंकि उस stripe के लिए parity block अब गलत हो गया है और उसे फिर से compute करना पड़ता है।

Read-modify-write के लिए, controller पहले पुरानी data और पुरानी parity को read करता है। RAID 5 पर एक uncached single-block overwrite तब read, read, write, write बन जाता है। RAID 6 दो parity blocks बनाए रखता है, इसलिए read-modify-write, read, read, read, write, write, write बन जाता है। Linux, parity compute करने के लिए अपरिवर्तित data को read करते हुए reconstruct-write का भी उपयोग करता है। तीन-drive वाले RAID 5 पर, उस overwrite में एक data read और दो writes लग सकते हैं; चार-drive वाले RAID 6 पर, एक data read और तीन writes। चार और छह read-modify-write की संख्याएं हैं, न कि हर छोटे 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
  }
]

एक uncached single-block read-modify-write की लागत RAID 6 पर 6 device operations है, जबकि दो-copy वाले RAID 10 पर उसी overwrite के लिए यह 2 है। ये संख्याएं latency में अंतर को कम करके दिखाती हैं। दोनों mirror writes समानांतर (parallel) रूप से बाहर जाते हैं, इसलिए guest दोनों में से धीमे वाले का इंतज़ार करता है। Read-modify-write path में एक read शामिल होता है जिसे नई parity compute होने से पहले पूरा होना चाहिए, इसलिए guest एक read और फिर एक write का इंतज़ार करता है, एक के बाद एक। एक व्यस्त host पर वह read बाकी सभी के I/O के पीछे कतार में लग जाता है।

इसका एक महत्वपूर्ण अपवाद है। एक write जो पूरी stripe को भरने के लिए पर्याप्त बड़ा हो, उसे पुरानी data की आवश्यकता नहीं होती, क्योंकि stripe का हर block बदला जा रहा होता है। Parity की गणना memory में पहले से मौजूद data से की जाती है, और overhead RAID 5 के लिए प्रति stripe एक parity write या RAID 6 के लिए दो तक गिर जाता है, जिसमें कोई prereads नहीं होते। यही कारण है कि RAID 5 sequential benchmark में ठीक दिखता है और कई tenants से आने वाले छोटे writes के मिश्रित load के तहत खराब व्यवहार करता है। उस pattern का परीक्षण करें जिसे आप वास्तव में चलाते हैं: VPS disk की सही benchmarking का अर्थ है यथार्थवादी queue depth पर random I/O, न कि एक बड़ा dd।

rebuild खतरनाक क्यों है

एक पूर्ण RAID 5 rebuild को बाकी सभी drives से missing drive को फिर से बनाना पड़ता है, इसलिए आठ-drive वाले उदाहरण में यह पहले block से आखिरी तक 7 surviving drives को read करता है। फिक्स्ड two-copy mirror pairs के साथ, एक RAID 10 rebuild केवल 1 को read करता है: dead drive का mirror partner, और कुछ नहीं। अन्य Linux RAID10 layouts copies को अलग तरह से फैलाते हैं: three-device near layout के एक member को rebuild करने पर दोनों surviving members read होते हैं।

इसके दो परिणाम होते हैं। पहला समय है, क्योंकि rebuild surviving drives, reconstruction कार्य और recovery speed के लक्ष्यों द्वारा सीमित होता है। दूसरा load है। एक parity rebuild I/O को surviving drives पर फैला देता है। फिक्स्ड mirror pairs के साथ, एक RAID 10 rebuild उस I/O को एक pair पर केंद्रित कर देता है; shared controller और host resources अभी भी अन्य pairs को प्रभावित करते हैं।

इसी अवधि में correctness का जोखिम भी होता है। एक dead drive वाले RAID 5 array में कोई redundancy नहीं बचती, इसलिए surviving drive पर कहीं भी एक unreadable sector अब recover नहीं किया जा सकता। rebuild वह एकमात्र operation है जो हर sector को read करता है, जिसमें वे sectors भी शामिल हैं जिन्हें एक साल से किसी ने touch नहीं किया है। प्रकाशित datasheet के आंकड़े बताते हैं कि एक consumer hard drive में प्रति 10^14 bits read पर लगभग एक unrecoverable read error होता है, और एक enterprise NVMe drive में प्रति 10^17 या उससे बेहतर। ये vendor specifications हैं, न कि measurements, लेकिन यह अनुपात बताता है कि RAID 5 rebuild के विफल होने की पुरानी चेतावनी बड़ी spinning disks के बारे में क्यों लिखी गई थी, और NVMe पर यह खतरा बहुत कम क्यों है। load का तर्क किसी भी medium पर लागू होता है।

rebuild के ऐसा करने से पहले, scrubbing द्वारा latent errors का पता लगाएँ। Debian और Ubuntu में md arrays के लिए एक periodic scrub शामिल होता है, और यह mechanism releases के बीच भिन्न होता है, इसलिए जाँचें कि आपके पास कौन सा है और फिर हाथ से एक 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

sync_action, pass पूरा होने पर idle पर वापस चला जाता है, और mismatch_cnt को 0 पढ़ना चाहिए। mirror पर शून्य से ऊपर की संख्या का मतलब है कि दोनों halves असहमत हैं और kernel यह नहीं बता सकता कि कौन सा सही है, क्योंकि किसी भी copy में checksum नहीं होता है। कुछ mismatches हानिरहित होते हैं, और swap partitions इसका सामान्य स्रोत हैं: kernel एक page लिख सकता है जो उसके नीचे बदल जाता है। data array पर बढ़ती संख्या जाँच की मांग करती है; केवल संख्या से उस drive की पहचान नहीं होती जिसे replace करना है।

VPS प्रदाता NVMe के लिए RAID 10 को मानक क्यों मानते हैं

एक हाइपरवाइजर नोड केवल एक वर्कलोड नहीं चलाता है। यह दर्जनों असंबंधित गेस्ट चलाता है, और उनका I/O छोटे-छोटे राइट्स के प्रवाह के रूप में आता है जिनमें आपस में कोई स्थानीयता (locality) नहीं होती। यह बिल्कुल वही पैटर्न है जहाँ पैरिटी (parity) के read-modify-write चक्र की लागत सबसे अधिक होती है, और एक साझा नोड पर दिन भर यही पैटर्न बना रहता है।

रीबिल्ड व्यवहार को जोड़ें तो यह चुनाव स्पष्ट हो जाता है। पैरिटी नोड पर एक ड्राइव के विफल होने से बची हुई सभी ड्राइव्स पर रिकंस्ट्रक्शन का काम बढ़ जाता है। फिक्स्ड मिरर पेयर्स के साथ, RAID 10 नोड पर एक ड्राइव के विफल होने से केवल एक पेयर पर रीबिल्ड I/O बढ़ता है, और जब अन्य गतिविधियाँ चल रही हों तो Linux MD रिकवरी को धीमा कर देता है। प्रदाता ऐसी लेटेंसी बेच रहे हैं जिसमें स्पाइक्स न हों, इसलिए वे इसे क्षमता (capacity) के साथ खरीदते हैं: कच्ची NVMe का आधा हिस्सा मिरर में चला जाता है।

ड्राइव का आकार भी इसी दिशा में दबाव डालता है। जैसे-जैसे ड्राइव बड़ी होती हैं, रीबिल्ड विंडो लंबी होती जाती है, और RAID 5 पर वह विंडो ऐसी होती है जहाँ रिकंस्ट्रक्शन लोड बढ़ाता है और कोई रिडंडेंसी नहीं बचती; RAID 6 एक और ड्राइव विफलता के खिलाफ सुरक्षा बनाए रखता है। यही कारण है कि वर्चुअलाइजेशन के लिए ZFS डिप्लॉयमेंट वाइड raidz के बजाय मिरर किए गए vdevs के पूल का उपयोग करते हैं: एक मिरर रिसिल्वर केवल उन ब्लॉक्स को कॉपी करता है जो वास्तव में उपयोग में हैं, और वह भी केवल एक पेयर पर।

इनमें से कोई भी बात RAID 10 को हर जगह सही नहीं बनाती। एक बैकअप टारगेट पर लंबे अनुक्रमिक (sequential) रन में लिखा जाता है और उसे शायद ही कभी पढ़ा जाता है, इसलिए वहाँ RAID 6 एक बेहतर विकल्प है। यह दो विफलताओं को झेल सकता है और अधिकांश क्षमता वापस देता है। वर्कलोड निर्णय लेता है, संख्या नहीं। आज आप जो प्लान चुन रहे हैं, उसके लिए माध्यम (medium) आमतौर पर उसके ऊपर के लेआउट से अधिक मायने रखता है, और SATA SSD से NVMe पर जाना किसी भी RAID अंतर से कहीं अधिक बड़ा बदलाव है।

/proc/mdstat को कैसे पढ़ें

इन्हें उस मशीन पर चलाएं जहां आप ऐरे (array) के स्वामी हैं: एक डेडिकेटेड सर्वर, घर पर रखा कोई बॉक्स, या दो अटैच्ड वॉल्यूम वाला VPS जिसे आपने स्वयं असेंबल किया है। अपना आउटपुट स्वयं पढ़ें। नीचे दिए गए ब्लॉक उदाहरण हैं, जिन्हें इस तरह लिखा गया है ताकि आप अपने प्राप्त आउटपुट के स्वरूप का मिलान कर सकें।

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

एक स्वस्थ चार-ड्राइव 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 उन md मॉड्यूल को सूचीबद्ध करता है जिन्हें रनिंग कर्नेल ने लोड किया है। वहां raid10 का दिखना केवल यह दर्शाता है कि कोड उपलब्ध है, इससे अधिक कुछ नहीं।
• md0 : active raid10 ऐरे डिवाइस, उसकी स्थिति और उसके लेवल को दर्शाता है।
• उसके बाद के नाम मेंबर्स हैं। कोष्ठक में दी गई संख्या ऐरे मेटाडेटा में डिवाइस का इंडेक्स है, न कि लाइन पर उसकी स्थिति और न ही हमेशा उसका स्लॉट।
• ड्राइव बदलने के बाद, नया मेंबर आमतौर पर उस स्लॉट की तुलना में उच्च इंडेक्स रखता है जिसे वह भरता है, इसलिए nvme4n1p3[4] स्लॉट 2 में हो सकता है। mdadm --detail अपने RaidDevice कॉलम में वास्तविक स्लॉट प्रिंट करता है, इसलिए जब अंतर मायने रखता हो तो उसका उपयोग करें।
• मेंबर के बाद (F) का अर्थ है कि वह खराब (faulty) है। (S) का अर्थ है स्पेयर: मौजूद, निष्क्रिय, किसी चीज के खराब होने की प्रतीक्षा में।
• 3906764800 blocks super 1.2 1 KiB ब्लॉक में उपयोग करने योग्य आकार है, उसके बाद मेटाडेटा फॉर्मेट है।
• 512K chunks 2 near-copies स्ट्राइप चंक साइज और RAID 10 लेआउट है, जो यहां प्रत्येक ब्लॉक की दो प्रतियां एक-दूसरे के बगल में रखता है।
• [4/4] उन मेंबर्स की संख्या है जिनकी ऐरे अपेक्षा करता है, उसके बाद वर्तमान में सिंक में मौजूद संख्या है।
• [UUUU] स्लॉट क्रम में, प्रति स्लॉट एक वर्ण है। U एक ऐसा स्लॉट है जो चालू है और सिंक में है। _ एक ऐसा स्लॉट है जिसमें कुछ भी काम नहीं कर रहा है।
• bitmap: राइट इंटेंट बिटमैप है। यह रिकॉर्ड करता है कि किन क्षेत्रों में लिखा जा रहा था, ताकि जो मेंबर बाहर हो जाता है और वापस आता है, वह पूरी ड्राइव के बजाय केवल उन क्षेत्रों को फिर से सिंक (resync) करे।

[4/3] और [UU_U] का अर्थ जब कुछ गलत हो

एक डिग्रेडेड (degraded) ऐरे ऐसा दिखता है।

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] कहता है कि चार में से एक स्लॉट योगदान नहीं दे रहा है। [UU_U] बताता है कि कौन सा, क्योंकि अंडरस्कोर तीसरा वर्ण है और स्लॉट शून्य से गिने जाते हैं, इसलिए स्लॉट 2 डाउन है। (F) फ्लैग डिवाइस का नाम केवल तब तक बताता है जब तक विफल ड्राइव जुड़ी हुई है। इसे मशीन से बाहर निकालें और नाम लाइन से गायब हो जाएगा, जबकि अंडरस्कोर बना रहेगा।

ऐरे इस पूरी प्रक्रिया के दौरान काम करता रहता है, और RAID 10 पर यह अक्सर लगभग पूरी गति से काम करता है, यही कारण है कि किसी को महसूस नहीं होता। किसी चीज को आपको सूचित करना होगा।

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

mdadm पैकेज एक मॉनिटर डेमन इंस्टॉल करता है जो /etc/mdadm/mdadm.conf से MAILADDR को पढ़ता है, और यूनिट का नाम रिलीज के बीच बदल गया है, इसलिए अनुमान लगाने के बजाय अंतिम कमांड के साथ इसे खोजें। --test रन तुरंत प्रति ऐरे एक संदेश भेजता है। उसके बाद एक खाली इनबॉक्स का मतलब है कि मेल पाथ टूटा हुआ है, इसलिए वह संदेश जिसकी आपको वास्तव में परवाह है, वह भी उसी तरह खो गया होगा।

जब कोई रिप्लेसमेंट रीबिल्ड हो रहा होता है, तो ऐरे के नीचे एक प्रोग्रेस लाइन दिखाई देती है।

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 एक रिप्लेसमेंट ड्राइव पर रीबिल्ड है। resync एक कंसिस्टेंसी पास है, जिसमें प्रारंभिक पास और अनक्लीन शटडाउन से रिकवरी शामिल है। check वह स्क्रब है जिसे आपने ऊपर ट्रिगर किया था। कोष्ठक में दी गई जोड़ी प्रति-डिवाइस कुल के मुकाबले 1 KiB ब्लॉक में प्रगति है, और finish वर्तमान गति पर कर्नेल का अनुमान है। Linux MD रिकवरी स्पीड टारगेट के रूप में /proc/sys/dev/raid/speed_limit_min और speed_limit_max का उपयोग करता है, जिसमें sync_speed_min और sync_speed_max में प्रति-ऐरे ओवरराइड्स होते हैं। डिफ़ॉल्ट अधिकतम टारगेट 200,000 KiB/s प्रति डिवाइस है; ये टारगेट रिकवरी को प्रोडक्शन I/O को प्राथमिकता देने देते हैं और ये हार्ड स्पीड कैप नहीं हैं।

/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

अपने स्वामित्व वाले ऐरे पर ड्राइव बदलना चार कमांड का काम है, और अंतिम कमांड चेक है।

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

रिकवरी लाइन एक या दो सेकंड के भीतर दिखाई देनी चाहिए। रिप्लेसमेंट पार्टीशन कम से कम mdadm --detail के Used Dev Size जितना बड़ा होना चाहिए, और थोड़ा सा भी छोटा पार्टीशन not large enough to join array के रूप में संदेश के साथ अस्वीकार कर दिया जाता है। नई ड्राइव को जोड़ने से पहले उसे पुरानी ड्राइव से मेल खाने के लिए पार्टीशन करें।

VPS के अंदर से आप क्या देख सकते हैं और क्या नहीं

अधिकांश guests 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 में कोई array नहीं होता, क्योंकि guest के अंदर ऐसा कुछ नहीं होता है।

Container आधारित VPS पर यह जानकारी विश्वसनीय नहीं होती है। Containers host kernel को साझा करते हैं और /proc के कुछ हिस्से namespaced नहीं होते हैं, इसलिए वहाँ आप जो पढ़ते हैं वह आपके slice के बजाय 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 आपके पास पहले से ही मौजूद थी, और फिर भी आप उस एक विफलता के कारण दोनों copies खो देंगे जो वास्तव में मायने रखती है।

यह तब करना उचित है जब प्रदाता यह document करता है कि volumes अलग-अलग failure domains में स्थित हैं, या जब आप किसी ऐसे dedicated server पर हों जहाँ आप drives को देख सकते हैं। अन्यथा, यह प्रयास उन copies पर अधिक प्रभावी होता है जो machine से बाहर जाती हैं।

RAID आपको किन चीजों से सुरक्षित नहीं रखता है

RAID केवल एक स्थिति को कवर करता है: जब कोई ड्राइव सही ढंग से काम करना बंद कर दे। नीचे दी गई सभी क्रियाएं वैध (valid) राइट ऑपरेशन हैं, इसलिए ऐरे (array) इन्हें हर कॉपी पर लागू करता है और खुद को स्वस्थ (healthy) रिपोर्ट करता है।

• डिलीशन (Deletion)। गलत डायरेक्टरी में rm -rf करना, या किसी पाथ में unset वेरिएबल वाले डिप्लॉय स्क्रिप्ट का चलना। ऐरे इसे एक वैध राइट मानता है और इसे दो बार निष्पादित करता है।
• रैनसमवेयर (Ransomware)। एन्क्रिप्शन एक राइट ऑपरेशन है। एक स्वस्थ ऐरे मिरर के दोनों हिस्सों पर एन्क्रिप्टेड वर्जन को स्टोर कर लेता है।
• एक खराब एप्लिकेशन (A broken application)। एक बग जो आपके डेटाबेस में कचरा (garbage) लिखता है, वही कचरा रिडंडेंट ड्राइव पर भी लिख देता है।
• पूरा नोड (The whole node)। एक होस्ट जो फेल हो जाए, या कोई अकाउंट जिसे गलती से सस्पेंड कर दिया गया हो। एक ऐरे पूरी तरह से सही हो सकता है और साथ ही पहुंच से बाहर भी।
• आप स्वयं, एक सप्ताह बाद। सोमवार को आपके द्वारा डिलीट की गई फाइल सोमवार को ही हर ड्राइव से गायब हो जाती है। केवल उससे पहले ली गई कॉपी ही उसे वापस ला सकती है।

एक ही स्टोरेज पर स्नैपशॉट (snapshots) भी इसका समाधान नहीं हैं। वे डिलीशन के खिलाफ मदद करते हैं, लेकिन जिस ऐरे पर वे रहते हैं, उसके साथ ही वे भी नष्ट हो जाते हैं। जो गुण एक बैकअप को 'बैकअप' बनाता है, वह यह है कि वह कहीं और मौजूद हो। restic के साथ एन्क्रिप्टेड ऑफ-सर्वर बैकअप इस पेज का दूसरा हिस्सा है: ऐरे आपको खराब ड्राइव के बावजूद सर्विस जारी रखने में मदद करता है, और जब नुकसान ऐसा 'राइट' हो जिसे ऐरे ने खुशी-खुशी स्वीकार कर लिया हो, तो restic आपके डेटा को वापस लाता है।

FAQ

क्या RAID 10 का मतलब है कि मुझे बैकअप की आवश्यकता नहीं है?

नहीं। RAID 10 किसी ड्राइव के काम करना बंद कर देने से सुरक्षा प्रदान करता है। यह प्रत्येक वैध write को मिरर के दोनों हिस्सों पर लागू करता है, इसलिए कोई भी deletion या ransomware हमला उसी क्षण redundant ड्राइव तक पहुँच जाता है। इसके बाद array खुद को clean रिपोर्ट करता है, क्योंकि इसके दृष्टिकोण से कुछ भी विफल नहीं हुआ है। आपको अभी भी ऐसी copies की आवश्यकता है जो मशीन से बाहर मौजूद हों, और आपको यह साबित करने के लिए कि वे काम करती हैं, समय-समय पर एक को restore करके देखना चाहिए।

VPS प्रदाता RAID 5 या RAID 6 के बजाय RAID 10 क्यों चुनते हैं?

इसके दो कारण हैं, और दोनों छोटे random writes से संबंधित हैं। एक uncached single-block read-modify-write, नई parity की गणना करने से पहले पुराने डेटा और parity को पढ़ता है, जिसकी लागत RAID 5 पर 4 operations और RAID 6 पर 6 होती है, जबकि दो-copy वाले मिरर पर यह 2 होती है। Reconstruct-write इसके बजाय अपरिवर्तित डेटा का उपयोग करता है, और full-stripe writes को पुराने डेटा या पुरानी parity को पहले से पढ़ने की आवश्यकता नहीं होती है। एक पूर्ण RAID 5 rebuild फिर हर surviving ड्राइव को शुरू से अंत तक पढ़ता है, जबकि fixed mirror pairs वाला पारंपरिक RAID 10 अपने surviving partner से copy करता है; अन्य Linux RAID10 लेआउट कई source members का उपयोग करते हैं। जब अन्य गतिविधियाँ हो रही होती हैं तो Linux MD रिकवरी को धीमा कर देता है। प्रदाता इसके लिए capacity के साथ भुगतान करते हैं: raw NVMe का आधा हिस्सा।

/proc/mdstat में [U_] या [UU_U] का क्या अर्थ है?

प्रत्येक character array में एक slot है, जो slot के क्रम में है, और प्रति slot एक character है। U का अर्थ है कि उस slot में एक member है जो up है और sync में है। _ का अर्थ है कि उस slot में कुछ भी काम नहीं कर रहा है। दो ड्राइव वाले मिरर पर [U_] का अर्थ है कि दूसरा slot down है और अब कोई redundancy नहीं बची है। इसे अपने सामने वाले pair के साथ पढ़ें, जहाँ [4/3] बताता है कि array चार members की अपेक्षा करता है और उसके पास तीन हैं। slot का क्रम mdadm --detail के RaidDevice कॉलम से मेल खाता है, न कि उस क्रम से जिसमें device के नाम लाइन पर दिखाई देते हैं।

एक RAID 10 array कितनी ड्राइव खो सकता है?

fixed mirror pairs वाले पारंपरिक दो-copy RAID 10 के लिए, एक, किसी भी पैटर्न में। इसके बाद यह इस पर निर्भर करता है कि विफलताएँ कहाँ होती हैं। प्रत्येक mirror pair अपने दो members में से एक को खो सकता है, इसलिए आठ ड्राइव वाला array चार विफलताओं तक जीवित रह सकता है यदि कोई भी दो एक ही pair साझा नहीं करते हैं, और यदि दोनों एक ही pair पर आ जाएँ तो यह दो विफलताओं पर ही नष्ट हो जाता है। गारंटीकृत संख्या, जो कि एक है, के आधार पर योजना बनाएँ और उससे आगे की किसी भी चीज़ को सुरक्षा के बजाय भाग्य समझें।

क्या मुझे mdadm के साथ अपने VPS के अंदर दो volumes को mirror करना चाहिए?

आमतौर पर नहीं। एक VPS से जुड़े दो volumes अक्सर एक ही host पर एक ही physical array पर स्थित होते हैं, इसलिए उन्हें mirror करने से हर write की लागत दोगुनी हो जाती है और यह ऐसी किसी चीज़ से सुरक्षा नहीं देता जिसे host के अपने RAID ने पहले ही कवर नहीं किया है। यह केवल तब करने योग्य है जब प्रदाता यह document करे कि volumes अलग-अलग failure domains में स्थित हैं। अन्यथा उस प्रयास को उन बैकअप में लगाएँ जो मशीन से बाहर जाते हैं।