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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Controller केवल नए block से parity को फिर से compute नहीं कर सकता। उसे पहले पुराने data block और पुराने parity block की आवश्यकता होती है। इसलिए RAID 5 पर एक छोटा random write, read, read, write, write में बदल जाता है। RAID 6 में बनाए रखने के लिए एक दूसरा syndrome होता है, इसलिए वही write, read, read, read, write, write, write में बदल जाता है।

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

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

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

Rebuild सबसे खतरनाक हिस्सा क्यों है

Parity rebuild को बाकी सभी ड्राइव्स से गायब ड्राइव का पुनर्निर्माण करना पड़ता है, इसलिए यह पहले ब्लॉक से आखिरी ब्लॉक तक 7 जीवित ड्राइव्स को पढ़ता है। RAID 10 rebuild केवल 1 को पढ़ता है: मृत ड्राइव का मिरर पार्टनर, और कुछ नहीं।

इसके दो परिणाम होते हैं। पहला समय है, क्योंकि rebuild की गति सबसे धीमी जीवित ड्राइव और उसके ऊपर होने वाली parity गणनाओं द्वारा सीमित होती है। दूसरा लोड है। Parity सेट की हर ड्राइव पूरी अवधि के दौरान व्यस्त रहती है, इसलिए उस नोड पर मौजूद हर guest को rebuild खत्म होने तक अधिक latency का सामना करना पड़ता है। RAID 10 में केवल एक जोड़ी व्यस्त रहती है और बाकी जोड़ियाँ अपनी सामान्य गति से काम करती हैं।

इसी अवधि में डेटा की शुद्धता का जोखिम भी होता है। एक मृत ड्राइव वाले RAID 5 array में कोई redundancy नहीं बचती, इसलिए किसी जीवित ड्राइव पर मौजूद unreadable sector अब recover नहीं किया जा सकता। Rebuild वह प्रक्रिया है जो हर sector को पढ़ती है, यहाँ तक कि उन्हें भी जिन्हें एक साल से किसी ने नहीं छुआ। प्रकाशित datasheet के आंकड़े बताते हैं कि consumer hard drive में 10^14 bits पढ़ने पर लगभग एक unrecoverable read error होता है, और enterprise NVMe drive में 10^17 या उससे बेहतर। ये आंकड़े vendor द्वारा दिए गए हैं, न कि मापे गए, लेकिन यह अनुपात बताता है कि RAID 5 rebuild के विफल होने की पुरानी चेतावनी बड़ी spinning disks के बारे में क्यों लिखी गई थी, और NVMe पर यह खतरा बहुत कम क्यों है। लोड का तर्क किसी भी माध्यम पर लागू होता है।

Rebuild के दौरान आने वाली त्रुटियों से पहले ही उन्हें खोजने के लिए scrubbing का उपयोग करें। Debian और Ubuntu में md arrays के लिए periodic scrub की सुविधा होती है, और यह mechanism 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

sync_action, pass पूरा होने पर idle पर वापस चला जाता है, और mismatch_cnt को 0 पढ़ना चाहिए। Mirror पर शून्य से अधिक संख्या का मतलब है कि दोनों हिस्से सहमत नहीं हैं और kernel यह नहीं बता सकता कि कौन सा सही है, क्योंकि किसी भी कॉपी में checksum नहीं होता। कुछ mismatches हानिरहित होते हैं, और swap partitions इसका सामान्य स्रोत हैं: kernel एक ऐसा page लिख सकता है जो उसके नीचे बदल जाता है। Data array पर बढ़ती संख्या का मतलब है कि ड्राइव को बदलने की आवश्यकता है।

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

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

रीबिल्ड (rebuild) व्यवहार को जोड़ें और चुनाव स्पष्ट हो जाता है। पैरिटी नोड पर एक विफल ड्राइव बॉक्स पर मौजूद हर गेस्ट को घंटों के लिए धीमा कर देती है। RAID 10 नोड पर एक विफल ड्राइव केवल एक जोड़ी को धीमा करती है, और कॉपी प्रक्रिया ड्राइव की गति पर क्रमिक रूप से चलती है। प्रदाता ऐसी लेटेंसी बेच रहे हैं जो स्पाइक न करे, इसलिए वे इसे क्षमता के साथ खरीदते हैं: कच्ची NVMe का आधा हिस्सा मिररिंग में चला जाता है।

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

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

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

इन्हें उस मशीन पर चलाएं जहां आप array के स्वामी हैं: एक dedicated server, घर पर रखा कोई box, या दो attached volumes वाला VPS जिसे आपने स्वयं assemble किया है। अपना output स्वयं पढ़ें। नीचे दिए गए blocks उदाहरण हैं, जिन्हें इस तरह लिखा गया है ताकि आप अपने द्वारा प्राप्त output के स्वरूप का मिलान कर सकें।

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

एक healthy चार-drive वाला RAID 10 कुछ इस तरह का output देता है।

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

unused devices: <none>

उसका हर हिस्सा जानकारी प्रदान करता है।

• Personalities उन md modules की सूची देता है जिन्हें running kernel ने load किया है। वहां raid10 का दिखना केवल यह दर्शाता है कि code उपलब्ध है, इससे अधिक कुछ नहीं।
• md0 : active raid10 array device, उसकी स्थिति और उसके level को दर्शाता है।
• उसके बाद के नाम members हैं। square brackets में दी गई संख्या array metadata में device का index है, न कि line पर उसकी स्थिति और न ही हमेशा उसका slot।
• Drive बदलने के बाद, नया member आमतौर पर उस slot से बड़ा index रखता है जिसे वह भरता है, इसलिए nvme4n1p3[4] slot 2 में हो सकता है। mdadm --detail अपने RaidDevice column में वास्तविक slot को print करता है, इसलिए जब अंतर महत्वपूर्ण हो तो उसका उपयोग करें।
• member के बाद (F) का अर्थ है faulty। (S) का अर्थ है spare: मौजूद, idle, किसी चीज़ के fail होने की प्रतीक्षा में।
• 3906764800 blocks super 1.2 1 KiB blocks में उपयोग योग्य आकार है, उसके बाद metadata format है।
• 512K chunks 2 near-copies stripe chunk size और RAID 10 layout है, जो यहां प्रत्येक block की दो copies को एक-दूसरे के बगल में रखता है।
• [4/4] उन members की संख्या है जिनकी array अपेक्षा करती है, उसके बाद वर्तमान में sync हो रहे members की संख्या है।
• [UUUU] प्रति slot एक character है, slot के क्रम में। U एक ऐसा slot है जो up है और sync में है। _ एक ऐसा slot है जिसमें कुछ भी काम नहीं कर रहा है।
• bitmap: write intent bitmap है। यह record करता है कि किन क्षेत्रों में लिखा जा रहा था, ताकि जो member बाहर हो जाता है और वापस आता है, वह पूरी drive के बजाय केवल उन क्षेत्रों को 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] कहता है कि चार में से एक slot योगदान नहीं दे रहा है। [UU_U] बताता है कि कौन सा, क्योंकि underscore तीसरा character है और slots को शून्य से गिना जाता है, इसलिए slot 2 down है। (F) flag device का नाम केवल तब तक बताता है जब तक failed drive जुड़ी हुई है। उसे मशीन से बाहर निकालें और line से नाम गायब हो जाएगा, जबकि 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 install करता है जो /etc/mdadm/mdadm.conf से MAILADDR को पढ़ता है, और unit का नाम releases के बीच बदल गया है, इसलिए अनुमान लगाने के बजाय अंतिम command के साथ इसे खोजें। --test run प्रत्येक array के लिए तुरंत एक message भेजता है। उसके बाद एक खाली inbox का मतलब है कि mail path broken है, इसलिए वह 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 है जिसे आपने ऊपर trigger किया था। कोष्ठक में दी गई जोड़ी प्रति-device कुल के मुकाबले 1 KiB blocks में प्रगति है, और finish वर्तमान गति पर kernel का अनुमान है। वह गति /proc/sys/dev/raid/speed_limit_min और speed_limit_max द्वारा सीमित है, और ये सीमाएं इसलिए मौजूद हैं ताकि rebuild production 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

अपने स्वामित्व वाली array पर drive बदलना चार commands का काम है, और अंतिम 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 line एक या दो second के भीतर दिखाई देनी चाहिए। replacement partition कम से कम mdadm --detail के Used Dev Size जितना बड़ा होना चाहिए, और थोड़ा सा भी छोटा partition not large enough to join array के रूप में एक message के साथ अस्वीकार कर दिया जाता है। नई drive को जोड़ने से पहले उसे पुरानी drive से मेल खाने के लिए partition करें।

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) को मिरर के दोनों हिस्सों में लागू करता है, इसलिए कोई भी डिलीशन या रैनसमवेयर का हमला उसी क्षण रिडंडेंट ड्राइव तक पहुँच जाता है। इसके बाद ऐरे (array) खुद को 'क्लीन' रिपोर्ट करता है, क्योंकि इसके दृष्टिकोण से कुछ भी विफल नहीं हुआ है। आपको अभी भी मशीन से बाहर बैकअप की प्रतियां रखने की आवश्यकता है, और यह साबित करने के लिए कि वे काम कर रहे हैं, समय-समय पर एक बैकअप को रिस्टोर करके देखना भी जरूरी है।

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

इसके दो कारण हैं, और दोनों छोटे रैंडम राइट्स से संबंधित हैं। पैरिटी राइट (parity write) के लिए नई पैरिटी की गणना करने से पहले पुराने डेटा और पुरानी पैरिटी को वापस पढ़ना पड़ता है। इसलिए एक छोटे राइट की लागत RAID 5 पर 4 ऑपरेशंस और RAID 6 पर 6 ऑपरेशंस होती है, जबकि मिरर पर यह केवल 2 होती है। इसके अलावा, पैरिटी रीबिल्ड के दौरान हर जीवित ड्राइव को शुरू से अंत तक पढ़ा जाता है, जिससे नोड पर मौजूद सभी गेस्ट्स की गति घंटों तक धीमी हो जाती है। इसके विपरीत, RAID 10 रीबिल्ड में एक ड्राइव को दूसरी ड्राइव पर कॉपी किया जाता है और अन्य जोड़ों को प्रभावित नहीं किया जाता है। प्रदाता इसके लिए क्षमता (capacity) की कीमत चुकाते हैं: कुल रॉ NVMe का आधा हिस्सा।

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

प्रत्येक अक्षर ऐरे में एक स्लॉट को दर्शाता है, स्लॉट के क्रम में, प्रति स्लॉट एक अक्षर। U का अर्थ है कि उस स्लॉट में एक सदस्य मौजूद है जो अप (up) है और सिंक (sync) में है। _ का अर्थ है कि उस स्लॉट में कोई भी कार्यशील सदस्य नहीं है। दो ड्राइव वाले मिरर पर [U_] का अर्थ है कि दूसरा स्लॉट डाउन है और अब कोई रिडंडेंसी नहीं बची है। इसे इसके सामने वाले जोड़े के साथ पढ़ें, जहाँ [4/3] बताता है कि ऐरे चार सदस्यों की अपेक्षा करता है और उसके पास तीन हैं। स्लॉट का क्रम mdadm --detail के RaidDevice कॉलम से मेल खाता है, न कि उस क्रम से जिसमें डिवाइस के नाम लाइन पर दिखाई देते हैं।

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

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

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

आमतौर पर नहीं। एक VPS से जुड़े दो वॉल्यूम अक्सर एक ही होस्ट पर एक ही फिजिकल ऐरे पर स्थित होते हैं। इसलिए उन्हें मिरर करने से हर राइट की लागत दोगुनी हो जाती है और यह ऐसी किसी भी चीज से सुरक्षा नहीं देता जिसे होस्ट का अपना RAID पहले से कवर नहीं कर रहा है। यह केवल तब उपयोगी है जब प्रदाता यह दस्तावेज दे कि वॉल्यूम अलग-अलग फेल्योर डोमेन (failure domains) में स्थित हैं। अन्यथा, उस प्रयास को उन बैकअप्स में लगाएं जो मशीन से बाहर रखे जाते हैं।