VPS storage साठी RAID 10 म्हणजे काय?

RAID 10 म्हणजे काय आणि VPS host ते का वापरतात

virtualised NVMe (non-volatile memory express) drives अंतर्गत बहुतेक VPS host वापरत असलेली storage layout म्हणजे RAID 10. प्रत्येक drive ची प्रतिमा त्याच्या partner drive वर ठेवली जाते आणि त्यानंतर त्या mirrored pairs मध्ये data striping केले जाते. एक drive निकामी झाला तरी array बंद पडत नाही. Repair करण्यासाठी set मधील इतर सर्व drives वाचून पुन्हा गणना करण्याऐवजी जिवंत partner drive वरून साधी copy केली जाते.

RAID म्हणजे redundant array of independent disks. त्याचे एकच काम आहे: एखादा disk निकामी असताना किंवा बदलला जात असताना machine कडून सेवा सुरू ठेवणे. हे काम availability चे आहे; availability म्हणजे safety नाही.

RAID तुमच्या writes ची replication करते. rm -rf /srv हा एक write आहे. Mirror चे दोन्ही भाग त्याच millisecond मध्ये directory गमावतात आणि त्यानंतरही array स्वतःची स्थिती clean असल्याचे दाखवते.

हे वाक्य लक्षात ठेवा. या पृष्ठाच्या उर्वरित भागात प्रत्येक level कोणत्या failure मधून टिकतो आणि प्रत्येक write वर त्याची किंमत काय असते हे स्पष्ट केले आहे. शेवटच्या sections मध्ये तुमच्या मालकीच्या machine वर array ची स्थिती पाहण्यासाठी commands दिले आहेत. RAID ने कधीही संरक्षित न केलेला failure देखील तिथे स्पष्ट केला आहे.

होस्टिंग खरेदीदाराला प्रत्यक्षात आढळणारे स्तर: 1, 5, 6 आणि 10

प्लॅनच्या पृष्ठावर एक संख्या दिली जाते आणि माहिती तिथेच थांबते. ती संख्या दोन प्रश्नांची उत्तरे देते: किती drives निकामी होऊ शकतात आणि प्रत्येक write operation ची किंमत काय असते.

RAID 1 हा mirror आहे. दोन drives मध्ये एकसारखे blocks असतात. प्रत्येक write दोन्ही drives वर केली जाते. कोणताही drive read पुरवू शकतो. एक drive निकामी झाला तरी data loss होत नाही आणि raw capacity पैकी निम्मी capacity वापरता येते. Parity मोजावी लागत नसल्यामुळे write path लहान असतो.

RAID 5 मध्ये striping आणि प्रत्येक stripe साठी एक parity block असतो. n drives असल्यास त्यांपैकी n-1 drives इतकी capacity मिळते आणि array नेमका एक drive निकामी झालेला सहन करू शकतो. Parity एका dedicated drive वर ठेवली जात नाही. ती सर्व drives वर फिरत्या पद्धतीने ठेवली जाते. त्यामुळे प्रत्येक drive वर data आणि parity दोन्ही असतात.

RAID 6 प्रत्येक stripe मध्ये दुसरा स्वतंत्र parity block जोडतो. हे blocks सामान्यतः 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 निकामी झाल्यावर संपूर्ण stripe service बाहेर जाते आणि repair साठी दुसऱ्या संपूर्ण बाजूची copy करावी लागते.

Linux हे जाणून घेण्यासारखे विशेष प्रकरण आहे. Kernel मधील raid10 ही दोन थरांची रचना नसून एकच 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
  }
]

Eight 1 TB drives मुळे RAID 5 अंतर्गत 7 TB usable space आणि RAID 10 अंतर्गत 4 TB usable space मिळते. हा फरक प्रत्यक्ष खर्चावर परिणाम करतो आणि म्हणून parity चा प्रस्ताव वारंवार दिला जातो. RAID 6 कोणत्याही pattern मध्ये 2 failures सहन करते. RAID 10 फक्त 1 failures ची हमी देते, कारण धोकादायक दुसरा failure आधीच निकामी झालेल्या drive च्या जोडीदार drive वर होतो. कोणत्याही दोन failures एकाच जोडीमध्ये नसतील, तर ते 4 failures पर्यंत सहन करू शकते. हे design property नसून केवळ योगायोग आहे.

प्रत्येक write साठी प्रत्येक स्तराची किंमत

Mirror वर केलेला write म्हणजे एकाच वेळी दोन्ही members कडे पाठवलेले दोन writes. 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 असा होतो.

[
  {
    "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 समांतरपणे पाठवले जातात. त्यामुळे guest ला दोन्हीपैकी जो धीमा असेल त्याची प्रतीक्षा करावी लागते. Parity path मध्ये नवीन parity मोजण्यापूर्वी read पूर्ण होणे आवश्यक असते. त्यामुळे guest ला आधी read आणि त्यानंतर write, अशा क्रमाने प्रतीक्षा करावी लागते. व्यस्त host वर हा read इतर सर्वांच्या I/O मागे queue मध्ये थांबतो.

याला एक महत्त्वाचा अपवाद आहे. संपूर्ण stripe भरण्याइतका मोठा write असल्यास जुन्या data ची गरज नसते, कारण stripe मधील प्रत्येक block बदलला जात असतो. Memory मध्ये आधीपासून असलेल्या माहितीवरून parity मोजला जातो आणि खर्च एका अतिरिक्त write पर्यंत कमी होतो. म्हणून RAID 5 sequential benchmark मध्ये चांगले दिसते, पण अनेक tenants कडून येणाऱ्या लहान writes च्या mixed load खाली खराब कामगिरी करते. प्रत्यक्षात चालणारा pattern तपासा: VPS disk चे योग्य benchmarking म्हणजे वास्तववादी queue depth वर random I/O, एक मोठा dd नव्हे.

पुनर्बांधणीचा टप्पा धोकादायक का आहे

Parity rebuild मध्ये उर्वरित सर्व डेटावरून गहाळ drive पुन्हा तयार करावा लागतो. त्यामुळे तो पहिल्या block पासून शेवटच्या block पर्यंत 7 surviving drives वाचतो. RAID 10 rebuild मध्ये 1 वाचले जातात: मृत drive चा mirror partner आणि दुसरे काहीही नाही.

यातून दोन खर्च निर्माण होतात. पहिला खर्च वेळेचा असतो. Rebuild हा सर्वांत धीम्या surviving drive च्या वेगाने आणि त्यावर होणाऱ्या parity गणनेने मर्यादित असतो. दुसरा खर्च load चा असतो. Parity set मधील प्रत्येक drive संपूर्ण कालावधीत व्यस्त राहतो. त्यामुळे तोपर्यंत त्या node वरील प्रत्येक guest ला जास्त latency जाणवते. RAID 10 मध्ये केवळ एक pair व्यस्त असतो. इतर pairs नेहमीच्या वेगाने सेवा देतात.

याच कालावधीत correctness चा धोकाही असतो. एक drive dead झालेल्या RAID 5 array मध्ये redundancy शिल्लक राहत नाही. त्यामुळे surviving drive वरील कुठलाही unreadable sector आता recover करता येत नाही. Rebuild ही प्रत्येक sector वाचणारी एकमेव operation आहे. यात वर्षभर कोणीही access न केलेले sectors देखील वाचले जातात. प्रकाशित datasheet आकडेवारीनुसार, consumer hard drive मध्ये वाचलेल्या प्रत्येक 10^14 bits मागे जवळपास एक unrecoverable read error येऊ शकतो. Enterprise NVMe drive मध्ये हे प्रमाण 10^17 bits मागे एक किंवा त्याहून चांगले असते. हे vendor specifications आहेत, measurements नाहीत. तरीही हे प्रमाण स्पष्ट करते की RAID 5 rebuild fail होईल असा जुना इशारा मोठ्या spinning disks संदर्भात का दिला गेला आणि NVMe वर तो तुलनेने कमी लागू का होतो. Load संबंधीचा मुद्दा कोणत्याही माध्यमावर लागू होतो.

Rebuild सुरू होण्यापूर्वी latent errors शोधण्यासाठी scrubbing करा. Debian आणि Ubuntu md arrays साठी periodic scrub देतात. Releases नुसार mechanism वेगळी असते. त्यामुळे तुमच्याकडे कोणती mechanism आहे ते तपासा आणि त्यानंतर manually एक 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 पेक्षा मोठी संख्या असल्यास त्याचे दोन halves जुळत नाहीत. कोणती copy योग्य आहे हे kernel सांगू शकत नाही, कारण कोणत्याही copy मध्ये checksum नसतो. काही mismatches निरुपद्रवी असतात. Swap partitions हा त्यांचा नेहमीचा स्रोत आहे. Kernel एखादा page लिहीत असताना तो page बदलू शकतो. Data array वरील count वाढत असल्यास drive replace करणे आवश्यक आहे.

NVMe साठी VPS provider RAID 10 ला प्रमाण का देतात

Hypervisor node वर एकच workload चालत नाही. त्यावर परस्पर असंबंधित अनेक guests चालतात. त्यांच्या I/O विनंत्या एकमेकांत मिसळलेल्या stream म्हणून येतात आणि त्यात locality नसलेल्या लहान writes असतात. Parity च्या read-modify-write cycle साठी हा सर्वाधिक खर्चिक pattern आहे. Shared node वर दिवसभर हाच pattern असतो.

Rebuild चे वर्तन लक्षात घेतल्यावर निवड स्पष्ट होते. Parity node मधील एखादा drive fail झाल्यास त्या मशीनवरील प्रत्येक guest अनेक तास मंदावतो. RAID 10 node मधील एखादा drive fail झाल्यास फक्त एका pair वर परिणाम होतो. Copy drive च्या वेगाने sequential पद्धतीने चालते. Providers अशी latency विकतात जी अचानक वाढत नाही. त्यामुळे ते capacity च्या बदल्यात हा वेग निवडतात: raw NVMe पैकी निम्मी capacity mirror साठी वापरली जाते.

Drive चा आकारही याच दिशेने परिणाम करतो. Drives मोठे होत गेल्यावर rebuild window अधिक लांबते. Parity मध्ये याच कालावधीत सर्वकाही मंद असते आणि कोणताही डेटा संरक्षित नसतो. Virtualisation साठी ZFS deployments मध्ये wide raidz ऐवजी mirrored vdevs चे pools वापरण्याचे हेच कारण आहे. Mirror resilver फक्त प्रत्यक्ष वापरात असलेले blocks, एका pair वर, copy करते.

यामुळे प्रत्येक ठिकाणी RAID 10 योग्य ठरते असे नाही. Backup target वर डेटा लांब sequential runs मध्ये लिहिला जातो आणि क्वचित वाचला जातो. त्यामुळे तिथे RAID 6 अधिक चांगला पर्याय आहे. तो दोन failures सहन करतो आणि बहुतेक capacity उपलब्ध ठेवतो. निवड workload ठरवतो, drive ची संख्या नाही. आज निवडत असलेल्या plan साठी वरच्या layout पेक्षा medium सहसा अधिक महत्त्वाचा असतो. तसेच SATA SSD वरून NVMe कडे झालेली झेप कोणत्याही RAID मधील फरकापेक्षा मोठी असते.

/proc/mdstat कसे वाचावे

ही कमांड्स ज्या मशीनवरचा array तुमच्या मालकीचा आहे तिथे चालवा: dedicated server, घरातील मशीन किंवा तुम्ही स्वतः जोडलेल्या दोन volumes असलेला VPS. तुमचा स्वतःचा output वाचा. खालील blocks उदाहरणे आहेत. तुम्हाला मिळणाऱ्या output ची रचना त्यांच्याशी जुळवता यावी म्हणून ती पूर्ण लिहिली आहेत.

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

निरोगी four-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>

या output मधील प्रत्येक भाग माहिती देतो.

• Personalities मध्ये running kernel ने load केलेले md modules दिसतात. तिथे raid10 दिसणे म्हणजे code उपलब्ध आहे, एवढेच.
• md0 : active raid10 हा array device, त्याची state आणि त्याचा level दाखवतो.
• त्यानंतरची नावे members ची आहेत. square brackets मधील number हा array metadata मधील device चा index असतो. तो line मधील position नसतो आणि नेहमी slot देखील दर्शवत नाही.
• drive replace केल्यानंतर नवीन member साधारणपणे तो भरत असलेल्या slot पेक्षा higher index ठेवतो. त्यामुळे nvme4n1p3[4] slot 2 मध्ये असू शकतो. mdadm --detail त्याच्या RaidDevice column मध्ये वास्तविक slot दाखवतो. फरक महत्त्वाचा असेल तेव्हा तोच वापरा.
• member नंतरचे (F) म्हणजे तो faulty आहे. (S) म्हणजे spare: तो उपस्थित आहे, idle आहे आणि काहीतरी fail होण्याची वाट पाहत आहे.
• 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 order मध्ये असतात. U म्हणजे slot कार्यरत असून 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] सांगतो की चारपैकी एक slot योगदान देत नाही. [UU_U] कोणता slot आहे ते सांगतो. Underscore हा तिसरा character आहे आणि slots ची numbering zero पासून सुरू होते, त्यामुळे slot 2 down आहे. Failed drive अजून attached असतानाच (F) flag त्या device चे नाव दाखवतो. Drive मशीनमधून काढल्यावर ते नाव line मधून नाहीसे होते, परंतु underscore तसाच राहतो.

या स्थितीतही array सेवा देत राहतो. RAID 10 मध्ये तो अनेकदा जवळपास full speed ने सेवा देतो. त्यामुळे प्रत्यक्ष वापरातून ही समस्या लक्षात येत नाही. याबद्दल तुम्हाला कोणीतरी कळवणे आवश्यक आहे.

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

mdadm package एक monitor daemon install करतो. तो /etc/mdadm/mdadm.conf मधून MAILADDR वाचतो. Releases नुसार unit name बदलले आहे. त्यामुळे अंदाज लावण्याऐवजी शेवटची command वापरून ते शोधा. --test run केल्यावर प्रत्येक array साठी लगेच एक message पाठवला जातो. त्यानंतर inbox रिकामा असल्यास mail path तुटलेला आहे. त्यामुळे तुम्हाला प्रत्यक्ष महत्त्वाचा message देखील त्याच प्रकारे हरवला असता.

Replacement 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 मधील pair हा 1 KiB blocks मध्ये per-device total च्या तुलनेत progress दाखवतो. finish हा सध्याच्या speed वरचा kernel चा अंदाज आहे. ही speed /proc/sys/dev/raid/speed_limit_min आणि speed_limit_max यांनी cap केली जाते. Rebuild मुळे production I/O ला पुरेशी resources मिळू नयेत म्हणून हे caps असतात.

/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 replace करण्यासाठी चार commands लागतात. शेवटची command check करते.

sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat

Recovery line एक किंवा दोन seconds मध्ये दिसली पाहिजे. Replacement partition mdadm --detail मधील Used Dev Size इतकीच किंवा त्यापेक्षा मोठी असली पाहिजे. त्यापेक्षा किंचितही छोटी partition not large enough to join array स्वरूपाच्या message सह reject केली जाते. नवीन drive add करण्यापूर्वी त्याची partition जुना drive जशी आहे तशीच तयार करा.

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, lxc सारखा container type container वर आणि bare metal वर none दाखवतो. KVM guest वर तुम्हाला साधारणपणे lsblk मध्ये एकच vda किंवा sda दिसतो. /proc/mdstat मध्ये कोणतेही array दिसत नाहीत, कारण guest च्या आत कोणतेही array नसतात.

container आधारित VPS वर हे output विश्वासार्ह नसते. Containers host kernel आणि /proc चे काही भाग सामायिक करतात. त्या भागांना namespaces लागू नसल्यामुळे तिथे दिसणारी माहिती तुमच्या slice ऐवजी host चे वर्णन करू शकते. त्यामुळे तुमच्या स्वतःच्या storage बद्दल यापैकी कोणतीही माहिती निश्चित तथ्य मानू नका. Layout काय आहे हे provider ला विचारा. हा तपशील तुमच्यासाठी महत्त्वाचा असल्यास उत्तर लेखी घ्या.

तुम्हाला दिलेल्या disk चे behaviour तुम्ही आतून तपासू शकता. तुमच्या VPS चा disk खरोखर NVMe आहे का हे तपासणे या दुव्यात वास्तविक माहिती देणारे commands दिले आहेत. SSD VPS मध्ये प्रत्यक्षात काय समाविष्ट असते या दुव्यात plan page वरील label नेमका कोणता दावा करते हे स्पष्ट केले आहे.

तुमच्या VPS मध्ये RAID चालवावे का?

सहसा नाही. याचे कारण failure domains हे आहे. तुम्ही एका VPS ला दोन volumes जोडून mdadm वापरून त्यांचे mirroring केले, तरी दोन्ही volumes एकाच physical array वर, एकाच node वर आणि एकाच power supply मागे असू शकतात. तुम्ही redundancy साठी प्रत्येक write ची किंमत दुप्पट कराल, पण ही redundancy आधीपासूनच उपलब्ध असेल. आणि महत्त्वाच्या एकाच failure मुळे दोन्ही copies तरीही गमावू शकता.

Provider ने volumes स्वतंत्र failure domains मध्ये असल्याचे स्पष्टपणे नमूद केले असेल, किंवा drives वर थेट नियंत्रण असलेल्या dedicated server वर तुम्ही काम करत असाल, तर हे करणे योग्य ठरू शकते. अन्यथा मशीनच्या बाहेर ठेवलेल्या copies वर प्रयत्न करणे अधिक उपयुक्त ठरेल.

RAID कशापासून संरक्षण करत नाही

RAID एका घटनेपासून संरक्षण करते: योग्य प्रकारे काम करणे थांबवणारी drive. खालील प्रत्येक कृती वैध write आहे. त्यामुळे array ती प्रत्येक प्रतिकृतीवर लागू करते आणि स्वतःची स्थिती निरोगी असल्याचे दाखवते.

• Deletion. चुकीच्या directory मधील rm -rf किंवा path मध्ये unset variable असलेली deploy script. Array ला हा वैध write दिसतो आणि तो दोनदा करते.
• Ransomware. Encryption म्हणजे write करणे. निरोगी array encrypted आवृत्ती mirror च्या दोन्ही भागांवर साठवते.
• बिघडलेले application. तुमच्या database मध्ये निरर्थक data लिहिणारा bug तोच निरर्थक data redundant drive वरही लिहितो.
• संपूर्ण node. एखादा host fail होणे किंवा एखादे account चुकून suspend होणे. Array पूर्णपणे योग्य स्थितीत असू शकते आणि त्याच वेळी unreachable असू शकते.
• तुमची स्वतःची चूक, एका आठवड्यानंतर. तुम्ही सोमवारी delete केलेली file सोमवारीच प्रत्येक drive वरून नाहीशी होते. त्यापूर्वी घेतलेली copyच ती परत आणू शकते.

त्याच storage वरचे snapshots हेदेखील उपाय नाहीत. ते deletion विरुद्ध मदत करतात, पण ज्या array वर ते असतात त्याच्यासोबत नष्ट होतात. Backup ला backup बनवणारा गुणधर्म म्हणजे ते दुसरीकडे असणे. restic वापरून encrypted off-server backups हा या पानाचा दुसरा भाग आहे: मृत drive असतानाही array सेवा सुरू ठेवते, आणि array ने सहज स्वीकारलेला write नुकसानाचे कारण ठरल्यास restic तुमचा data परत मिळवून देते.

FAQ

RAID 10 म्हणजे मला backups ची गरज नाही का?

नाही. RAID 10 काम करणे थांबवलेल्या drive पासून संरक्षण देते. ते mirror च्या दोन्ही भागांवर प्रत्येक वैध write लागू करते. त्यामुळे deletion किंवा ransomware run झाल्यास त्याचा परिणाम त्याच क्षणी redundant drive वरही होतो. त्यानंतर array स्वतःला clean दाखवते, कारण तिच्या दृष्टीने काहीही बिघडलेले नसते. तरीही मशीनबाहेर ठेवलेल्या copies आवश्यक आहेत. त्या कार्यरत आहेत हे सिद्ध करण्यासाठी अधूनमधून एक copy restore करणेही आवश्यक आहे.

VPS providers RAID 5 किंवा RAID 6 ऐवजी RAID 10 का निवडतात?

यामागे दोन कारणे आहेत. दोन्ही small random writes शी संबंधित आहेत. Parity write साठी नवीन parity मोजण्यापूर्वी जुना data आणि जुनी parity पुन्हा read करावी लागते. त्यामुळे small write साठी RAID 5 वर 4 operations आणि RAID 6 वर 6 operations लागतात. Mirror वर याच कामासाठी 2 operations लागतात. Parity rebuild दरम्यान उरलेल्या प्रत्येक drive वरील संपूर्ण data सुरुवातीपासून शेवटपर्यंत read केला जातो. त्यामुळे अनेक तास 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 सोबत वाचा. त्यामध्ये [4/3] array ला चार members अपेक्षित आहेत आणि त्यापैकी तीन उपलब्ध आहेत असे दर्शवते. Slot order हा mdadm --detail मधील RaidDevice column शी जुळतो. तो line वर device names दिसतात त्या क्रमाशी जुळेलच असे नाही.

RAID 10 array किती drives गमावू शकते?

कोणत्याही pattern मध्ये एक drive. त्यापेक्षा जास्त failure झाल्यास परिणाम failures कुठे झाले यावर अवलंबून असतो. प्रत्येक mirror pair मधील दोन members पैकी एक गमावला तरी array चालू राहते. त्यामुळे आठ drives असलेली array कोणत्याही दोन failures एकाच pair मध्ये नसतील, तर चार failures पर्यंत टिकते. दोन्ही failures एकाच pair मध्ये झाल्यास दोन failures वरच ती निकामी होते. हमखास उपलब्ध असलेल्या संरक्षणावर, म्हणजे एका failure वर, नियोजन करा. त्यापेक्षा जास्त failures हे संरक्षण नसून केवळ योगायोग समजा.

माझ्या VPS मधील दोन volumes mdadm वापरून mirror करावेत का?

सहसा नाही. एका VPS ला जोडलेले दोन volumes अनेकदा त्याच host वरील त्याच physical array वर असतात. त्यामुळे प्रत्येक write चा खर्च दुप्पट होतो, पण host च्या स्वतःच्या RAID ने आधीच दिलेल्या संरक्षणापेक्षा अतिरिक्त संरक्षण मिळत नाही. Provider ने volumes स्वतंत्र failure domains मध्ये असल्याचे स्पष्टपणे documented केले असेल, तरच हे करणे उपयुक्त ठरते. अन्यथा हा प्रयत्न मशीनबाहेर ठेवलेल्या backups साठी करा.