RAID 10 para sa VPS storage: paliwanag

Ano ang RAID 10, at bakit ito ginagamit ng mga VPS host

Ang RAID 10 ang storage layout na karaniwang ginagamit ng mga VPS host sa ilalim ng mga virtualised na NVMe (non-volatile memory express) drive. Nire-replicate nito ang bawat drive sa isang partner, pagkatapos ay hina-hati nito ang data sa mga pares na iyon ng mirror. Maaaring masira ang isang drive nang hindi tumitigil ang array. Ang repair ay simpleng pagkopya mula sa gumaganang partner, sa halip na recalculation na kailangang magbasa sa lahat ng iba pang drive sa set.

Ang RAID ay nangangahulugang redundant array of independent disks. Iisa ang tungkulin nito: panatilihing nagse-serve ang machine habang sira o pinapalitan ang isang disk. Ang tungkuling iyon ay availability, at hindi nangangahulugang safety ang availability.

Nire-replicate ng RAID ang iyong mga write. rm -rf /srv ay isang write. Parehong nade-delete ang directory sa magkabilang bahagi ng mirror sa parehong millisecond, at nagrereport pa rin ang array na malinis ito pagkatapos.

Panatilihin ang pangungusap na iyon. Tatalakayin sa natitirang bahagi ng page na ito kung ano ang kayang lampasan ng bawat level at kung magkano ang kapalit nito sa bawat write. Sa mga huling seksyon makikita ang mga command para basahin ang status ng array sa machine na pagmamay-ari mo, pati ang failure na hindi kailanman kayang saklawin ng RAID.

Mga level na aktuwal na nakikita ng hosting buyer: 1, 5, 6, at 10

Naglalagay ng numero ang isang plan page at hanggang doon na lang. Sinasagot ng numerong iyon ang dalawang tanong: ilang drive ang maaaring masira, at magkano ang katumbas ng bawat write.

Ang RAID 1 ay mirror. Magkaparehong block ang hawak ng dalawang drive. Parehong drive ang pinagsusulatan sa bawat write. Maaaring gamitin ang alinmang drive para sa read. Maaaring masira ang isang drive nang walang data loss, at kalahati ng raw capacity ang magagamit. Walang parity na kailangang kalkulahin, kaya maikli ang write path.

Ang RAID 5 ay striping na may isang parity block sa bawat stripe. Kung may n drive, makukuha mo ang capacity ng n-1 sa mga ito, at makakayanan ng array ang eksaktong isang failure. Hindi nakalagay ang parity sa isang dedicated drive. Iniikot ito sa lahat ng drive, kaya bawat drive ay naglalaman ng data at parity.

Nagdagdag ang RAID 6 ng ikalawang independent parity block sa bawat stripe, na karaniwang tinatawag na P at Q. Nakakayanan nito ang sabay na pag-fail ng alinmang dalawang drive. Mas mahalaga ito kaysa sa unang tingin, dahil kadalasang dumarating ang ikalawang failure habang nire-repair ang una.

Ang RAID 10 ay stripe ng mga mirror. Pinagmi-mirror ang mga drive nang pares, at ikinakalat ang data sa mga pares. Kalahati ng raw total ang usable capacity, katulad ng RAID 1, pero may dagdag na parallelism mula sa striping.

Makikita mo rin itong isinusulat bilang RAID 1+0, na siyang tapat na paglalarawan: mirror muna, saka mag-stripe sa mga mirror. Ang RAID 0+1 ang kabaligtarang order: stripe muna, saka i-mirror ang dalawang stripe. Mas mahina ito, dahil kapag nag-fail ang isang drive, mawawala sa serbisyo ang buong stripe at kailangang kopyahin ng repair ang buong kabilang side.

Natatanging kaso ang Linux na mahalagang malaman. Ang raid10 ng kernel ay iisang personality sa halip na dalawang magkapatong na layer, kaya gumagana ito sa odd number ng mga drive at mayroon itong mga layout (near, far, offset) na hindi kayang ipahayag ng nested setup. Kaya sinasabi sa status line ng isang Linux box ang 2 near-copies sa halip na pangalanan ang dalawang array.

[
  {
    "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
  }
]

Ang walong 1 TB drive ay nagbibigay ng 7 TB na usable space sa RAID 5 at 4 TB sa RAID 10. Totoong pera ang diperensiyang iyon, at iyon ang dahilan kung bakit patuloy na inirerekomenda ang parity. Nakakayanan ng RAID 6 ang 2 failure sa kahit anong pattern. 1 lamang ang garantisado ng RAID 10, dahil ang mapanganib na ikalawang failure ay ang tumama sa partner ng drive na unang nasira. Nakakayanan nito ang hanggang 4 kapag walang dalawang failure na magkapareha ng pares, pero swerte iyon at hindi katangian ng disenyo.

Magkano ang gastos ng bawat level sa bawat write

Ang write sa mirror ay dalawang write na sabay na ipinapadala sa dalawang member. Mas maraming trabaho ang write sa parity stripe dahil nagiging mali ang parity block ng stripe na iyon at kailangan itong muling kalkulahin.

Hindi maaaring muling kalkulahin ng controller ang parity mula sa bagong block lamang. Kailangan muna nito ang lumang data block at lumang parity block. Kaya ang isang maliit na random write sa RAID 5 ay nagiging read, read, write, write. May pangalawang syndrome na kailangang i-maintain ang RAID 6, kaya ang parehong write ay nagiging 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
  }
]

Ang isang maliit na random write ay nagkakahalaga ng 6 device operations sa RAID 6 at 2 sa RAID 10. Hindi lubos na ipinapakita ng mga bilang ang pagkakaiba sa latency. Sabay na ipinapadala ang dalawang mirror write, kaya hinihintay ng guest ang mas mabagal sa dalawa. Sa parity path, may read na kailangang matapos bago makalkula ang bagong parity, kaya sunod-sunod na hinihintay ng guest ang read at pagkatapos ay ang write. Sa isang busy na host, pumipila ang read na iyon kasunod ng I/O ng iba.

May mahalagang exception. Ang write na sapat ang laki para punan ang isang buong stripe ay hindi nangangailangan ng lumang data dahil pinapalitan ang bawat block sa stripe. Kinakalkula ang parity mula sa nasa memorya na, at bumababa ang gastos sa isang dagdag na write. Ito ang dahilan kung bakit mukhang maayos ang RAID 5 sa isang sequential benchmark ngunit hindi maganda ang performance nito sa mixed load ng maliliit na write mula sa maraming tenant. I-test ang pattern na aktuwal mong ginagamit: ang tamang pag-benchmark ng VPS disk ay nangangahulugan ng random I/O sa realistic na queue depth, hindi isang malaking dd.

Bakit mapanganib ang rebuild

Kailangang buuin muli ng parity rebuild ang nawawalang drive gamit ang lahat ng iba pang drive, kaya binabasa nito ang 7 natitirang drive mula sa unang block hanggang sa huli. Ang RAID 10 rebuild ay bumabasa ng 1: ang mirror partner ng nasirang drive, at wala nang iba.

Dalawang gastos ang dulot nito. Una ang oras, dahil nakadepende ang rebuild sa pinakamabagal na natitirang drive at sa parity calculations na idinadagdag dito. Ikalawa ang load. Abala ang bawat drive sa parity set sa buong panahon ng rebuild, kaya mas mataas ang latency na nararanasan ng bawat guest sa node hanggang matapos ito. Sa RAID 10, isang pares lamang ang abala at gumagana ang iba pang pares sa normal nilang bilis.

May risk din sa data integrity sa parehong panahong ito. Kapag may isang nasirang drive ang RAID 5 array, wala na itong natitirang redundancy, kaya hindi na mare-recover ang unreadable sector sa alinmang natitirang drive. Ang rebuild ang operasyong nagbabasa sa bawat sector, pati sa mga sector na walang nakabasa sa loob ng isang taon. Ayon sa mga inilathalang datasheet, maaaring magkaroon ang consumer hard drive ng humigit-kumulang isang unrecoverable read error sa bawat 10^14 bits na nabasa, at ang enterprise NVMe drive ng isa sa bawat 10^17 o mas mababa pa ang error rate. Mga specification ito ng vendor at hindi mga aktuwal na measurement, pero ipinapaliwanag ng ratio kung bakit ang dating babalang mabibigo ang RAID 5 rebuild ay tumutukoy sa malalaking spinning disk, at kung bakit mas mahina ito sa NVMe. Nalalapat ang argumento tungkol sa load sa anumang uri ng storage medium.

Hanapin ang latent errors bago ito gawin ng rebuild sa pamamagitan ng scrubbing. May periodic scrub ang Debian at Ubuntu para sa md arrays, at nagkakaiba ang mechanism sa bawat release, kaya tingnan kung alin ang gamit mo at saka manu-manong mag-trigger ng 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

Bumabalik ang sync_action sa idle kapag natapos ang pass, at dapat basahin ng mismatch_cnt ang 0. Ang bilang na higit sa zero sa isang mirror ay nangangahulugang hindi nagtutugma ang dalawang bahagi at hindi matukoy ng kernel kung alin ang tama, dahil walang checksum ang alinmang kopya. Hindi nakapipinsala ang ilang mismatch, at karaniwang pinagmumulan nito ang swap partitions: maaaring magsulat ang kernel ng page na nagbabago habang ginagamit ito. Ang tumataas na bilang sa isang data array ay indikasyong dapat palitan ang drive.

Bakit RAID 10 ang karaniwang ginagamit ng mga VPS provider para sa NVMe

Hindi iisang workload ang pinapatakbo ng isang hypervisor node. Pinapatakbo nito ang dose-dosenang guest na walang kaugnayan sa isa’t isa, at dumarating ang kanilang I/O nang magkakahalo bilang stream ng maliliit na write na walang locality sa pagitan ng mga ito. Ito mismo ang pattern kung saan pinakamalaki ang gastos ng parity read-modify-write cycle. Ito rin ang pattern na nararanasan ng isang shared node sa buong araw.

Idagdag ang behavior habang nagre-rebuild, at nagiging malinaw ang pagpili. Kapag pumalya ang isang drive sa parity node, bumabagal ang bawat guest sa server nang ilang oras. Kapag pumalya ang isang drive sa RAID 10 node, isang pares lang ang bumabagal, at tumatakbo ang pagkopya nang sequential sa bilis ng drive. Nagbebenta ang mga provider ng latency na hindi biglang tumataas, kaya capacity ang kapalit nito: kalahati ng raw NVMe ang napupunta sa mirror.

Pareho ring nagtutulak sa direksiyong ito ang laki ng mga drive. Habang lumalaki ang mga drive, humahaba ang rebuild window. Sa parity, ito ang panahong mabagal ang lahat at walang proteksiyon ang data. Ito rin ang dahilan kung bakit ang mga ZFS deployment para sa virtualisation ay gumagamit ng mga pool ng mirrored vdev sa halip na malalawak na raidz: isang mirror resilver ang kumokopya lamang ng mga block na aktuwal na ginagamit, sa isang pares.

Hindi ibig sabihin nito na RAID 10 ang tamang pagpili sa lahat ng sitwasyon. Ang backup target ay sinusulatan sa mahahabang sequential run at bihirang basahin, kaya mas praktikal doon ang RAID 6. Nakakayanan nito ang dalawang failure at naibabalik ang malaking bahagi ng capacity. Ang workload ang nagpapasya, hindi ang bilang. Para sa planong pinipili mo ngayon, karaniwang mas mahalaga ang medium kaysa sa layout sa ibabaw nito, at mas malaki ang diperensiya ng paglipat mula SATA SSD papuntang NVMe kaysa sa anumang pagkakaiba ng RAID sa alinman sa mga ito.

Paano basahin ang /proc/mdstat

Patakbuhin ang mga ito sa machine kung saan ikaw ang may-ari ng array: isang dedicated server, isang box sa bahay, o isang VPS na may dalawang volume na ikaw mismo ang nag-assemble. Basahin ang sarili mong output. Mga halimbawa ang mga block sa ibaba, na isinulat nang buo para maikumpara mo ang anyo ng makukuha mong output.

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

Ganito ang halos itsura ng output ng isang healthy na four-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>

May impormasyong dala ang bawat bahagi nito.

• Inililista ng Personalities ang mga md module na ni-load ng tumatakbong kernel. Ibig sabihin lang ng paglitaw ng raid10 roon ay available ang code, at wala nang iba.
• Ang md0 : active raid10 ay ang array device, ang state nito, at ang level nito.
• Ang mga pangalan pagkatapos nito ang mga member. Ang numero sa square brackets ay index ng device sa array metadata, hindi ang posisyon nito sa linya at hindi rin palaging ang slot nito.
• Pagkatapos palitan ang isang drive, karaniwang mas mataas ang index ng bagong member kaysa sa slot na pinunan nito, kaya maaaring nasa slot 2 ang nvme4n1p3[4]. Inililimbag ng mdadm --detail ang aktuwal na slot sa column nitong RaidDevice, kaya iyon ang gamitin kapag mahalaga ang pagkakaibang ito.
• Ang (F) pagkatapos ng isang member ay nangangahulugang faulty. Ang (S) ay nangangahulugang spare: present, idle, at naghihintay na may mag-fail.
• Ang 3906764800 blocks super 1.2 ay ang usable size sa 1 KiB blocks, na sinusundan ng metadata format.
• Ang 512K chunks 2 near-copies ay ang stripe chunk size at ang RAID 10 layout. Sa halimbawang ito, pinananatili nito ang dalawang kopya ng bawat block na magkatabi.
• Ang [4/4] ay ang bilang ng mga member na inaasahan ng array, na sinusundan ng bilang na kasalukuyang in sync.
• Ang [UUUU] ay isang character para sa bawat slot, ayon sa pagkakasunod ng mga slot. Ang U ay slot na up at in sync. Ang _ ay slot na walang gumaganang device.
• Ang bitmap: ay ang write intent bitmap. Itinatala nito kung aling mga region ang sinusulatan, kaya kapag nag-disconnect at muling bumalik ang isang member, ang mga region na iyon lang ang isi-sync nito sa halip na ang buong drive.

Ano ang ibig sabihin ng [4/3] at [UU_U] kapag may problema

Ganito ang hitsura ng isang 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]

Basahin nang magkasama ang dalawang bracket. Sinasabi ng [4/3] na hindi nag-aambag ang isa sa apat na slot. Sinasabi ng [UU_U] kung alin iyon, dahil pangatlong character ang underscore at nagsisimula sa zero ang numbering ng mga slot, kaya down ang slot 2. Tinutukoy ng (F) flag ang device habang nakakabit pa ang failed drive. Kapag inalis mo ito sa machine, mawawala ang pangalan sa linya, pero mananatili ang underscore.

Patuloy na naghahatid ang array sa kabila ng lahat ng ito. Sa RAID 10, madalas ay halos full speed pa rin ang performance nito, kaya hindi ito napapansin batay sa aktuwal na paggamit. Kailangan ng external na paraan para maipaalam ito sa iyo.

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

Nag-i-install ang mdadm package ng monitor daemon na nagbabasa ng MAILADDR mula sa /etc/mdadm/mdadm.conf. Nagbago ang unit name sa pagitan ng mga release, kaya hanapin ito gamit ang huling command sa halip na manghula. Nagpapadala ang --test run ng isang message para sa bawat array kaagad. Kapag walang laman ang inbox pagkatapos nito, sira ang mail path. Ibig sabihin, ganoon din sana mawawala ang message na talagang kailangan mong matanggap.

Kapag nire-rebuild ang isang replacement, may lalabas na progress line sa ilalim ng array.

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

Ang recovery ay rebuild papunta sa replacement drive. Ang resync ay ang unang consistency pass sa bagong gawang array. Ang check ay ang scrub na na-trigger mo sa itaas. Ang pair sa parentheses ay ang progress sa 1 KiB blocks kumpara sa per-device total, at ang finish ay ang estimate ng kernel sa kasalukuyang speed. Nililimitahan ng /proc/sys/dev/raid/speed_limit_min at speed_limit_max ang speed na iyon. Nariyan ang mga limit na ito para hindi maubos ng rebuild ang resources na kailangan ng 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

Ang pagpapalit ng drive sa array na pagmamay-ari mo ay apat na command, at ang huli ang verification.

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

Dapat lumitaw ang recovery line sa loob ng isa o dalawang segundo. Kailangang hindi bababa sa laki ng Used Dev Size mula sa mdadm --detail ang replacement partition. Ang partition na kahit bahagyang mas maliit ay ire-reject na may message na may anyong not large enough to join array. I-partition ang bagong drive para tumugma sa luma bago mo ito idagdag.

Ano ang makikita at hindi makikita mula sa loob ng VPS

Hindi nakikita ng karamihan sa mga guest ang RAID ng host, at sinadya iyon. Isang virtual disk ang ibinibigay sa iyo ng hypervisor. Katangian ng host kung ang disk na iyon ay mula sa RAID 10 pool ng mga NVMe drive o nasa isang drive lamang. Hindi ito lumalabas sa loob ng guest.

systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstat

systemd-detect-virt ay nagpi-print ng kvm sa KVM guest, ng uri ng container gaya ng lxc sa container, at ng none sa bare metal. Sa KVM guest, karaniwan mong makikita ang isang vda o sda sa lsblk, at walang array sa /proc/mdstat, dahil walang array sa loob ng guest.

Sa container-based VPS, hindi mapagkakatiwalaan ang resulta. Ibinabahagi ng mga container ang kernel ng host, at hindi naka-namespace ang ilang bahagi ng /proc. Kaya maaaring ilarawan ng makikita mo roon ang host, hindi ang slice na inilaan sa iyo. Huwag ituring na katotohanan tungkol sa sarili mong storage ang alinman dito. Tanungin ang provider kung ano ang layout, at hingin ang sagot nang nakasulat kung mahalaga ito sa iyo.

Ang maaari mong suriin mula sa loob ay ang aktuwal na behavior ng disk na ibinigay sa iyo. Saklaw ng Pagsuri kung talagang NVMe ang disk ng iyong VPS ang mga command na nag-uulat ng aktuwal na impormasyon, at saklaw ng kung ano talaga ang kasama sa SSD VPS kung ano ang ipinapangako ng label sa plan page.

Magpatakbo ka ba ng RAID sa loob ng iyong VPS?

Karaniwang hindi, at ang dahilan ay ang failure domains. Kung mag-attach ka ng dalawang volume sa isang VPS at i-mirror ang mga ito gamit ang mdadm, maaaring nasa iisang physical array, iisang node, at iisang power supply ang dalawang volume. Dodoble ang cost ng bawat write para sa redundancy na mayroon ka na, pero mawawala pa rin ang dalawang kopya kapag nangyari ang failure na mahalaga.

Makatuwiran ito kapag nakadokumento ang provider na nasa magkahiwalay na failure domain ang mga volume, o kapag dedicated server ang gamit mo at ikaw ang pumipili ng mga drive. Kung hindi, mas kapaki-pakinabang ang effort sa paggawa ng mga kopyang nasa labas ng machine.

Hindi pinoprotektahan ng RAID

Isang event lang ang tinutugunan ng RAID: ang drive na hindi na gumagana nang tama. Valid na write ang lahat ng nasa ibaba, kaya inilalapat ito ng array sa bawat copy at itinuturing nitong healthy ang sarili nito.

• Deletion. rm -rf sa maling directory, o isang deploy script na may unset variable sa path. Nakikita ng array na legal na write ito at ginagawa ito nang dalawang beses.
• Ransomware. Ang encryption ay isang writing operation. Iniimbak ng healthy array ang encrypted na bersyon sa magkabilang bahagi ng mirror.
• Sirang application. Kapag may bug na nagsusulat ng maling data sa database mo, isinusulat din ang parehong maling data sa redundant drive.
• Buong node. Isang host na nag-fail, o isang account na nasuspinde dahil sa pagkakamali. Maaaring perfect ang array pero hindi pa rin ito ma-access.
• Ikaw, makalipas ang isang linggo. Ang file na dinelete mo noong Monday ay wala na sa bawat drive noong araw ding iyon. Copy lang na ginawa bago iyon ang makapagbabalik nito.

Hindi rin solusyon ang snapshots sa parehong storage. Nakakatulong ang mga ito laban sa deletion, pero nawawala rin ang mga ito kapag nawala ang array na pinaglalagyan nila. Ang katangiang nagpapaging backup sa isang backup ay nasa ibang lokasyon ito. Ang Encrypted off-server backups gamit ang restic ang kabilang bahagi ng page na ito: pinananatili kang nagsi-serve ng array kapag namatay ang isang drive, at ibinabalik ng restic ang data mo kapag ang pinsala ay isang write na maayos namang tinanggap ng array.

FAQ

Ibig bang sabihin ba ng RAID 10 na hindi ko na kailangan ng backups?

Hindi. Pinoprotektahan ng RAID 10 laban sa drive na tumitigil sa paggana. Inilalapat nito ang bawat valid na write sa dalawang bahagi ng mirror, kaya ang deletion o ransomware run ay sabay na nakakarating sa redundant drive. Itinuturing pa rin ng array na maayos ang sarili nito pagkatapos, dahil sa pananaw nito ay walang nag-fail. Kailangan mo pa rin ng mga kopyang nasa labas ng machine, at kailangan mo pa ring mag-restore paminsan-minsan upang mapatunayan na gumagana ang mga ito.

Bakit RAID 10 ang pinipili ng mga VPS provider kaysa RAID 5 o RAID 6?

Dalawang dahilan, at parehong may kinalaman sa maliliit na random write. Kailangang basahin muna ang lumang data at lumang parity bago makalkula ang bagong parity, kaya ang isang small write ay nagkakahalaga ng 4 operations sa RAID 5 at 6 sa RAID 6, kumpara sa 2 sa isang mirror. Sa parity rebuild, binabasa ang bawat surviving drive mula simula hanggang dulo. Dahil dito, bumabagal nang ilang oras ang bawat guest sa node. Samantala, sa RAID 10, isang drive lang ang kino-copy sa isa pang drive at hindi naaapektuhan ang ibang pair. Kapalit nito sa provider ang kapasidad: kalahati ng raw NVMe.

Ano ang ibig sabihin ng [U_] o [UU_U] sa /proc/mdstat?

Ang bawat character ay isang slot sa array, ayon sa pagkakasunod ng mga slot, at tig-isang character bawat slot. Ibig sabihin ng U ay may member sa slot na iyon na up at naka-sync. Ibig sabihin ng _ ay walang gumaganang member sa slot na iyon. Sa two-drive mirror, ibig sabihin ng [U_] ay down ang second slot at wala nang natitirang redundancy. Basahin ito kasama ng pair na nasa unahan nito. Ipinapakita ng [4/3] na umaasa ang array sa apat na member at tatlo lang ang mayroon. Ang pagkakasunod ng mga slot ay tumutugma sa column na RaidDevice ng mdadm --detail, hindi sa pagkakasunod ng paglitaw ng mga device name sa line.

Ilang drive ang maaaring mawala sa isang RAID 10 array?

Isa, anuman ang pattern. Kapag higit pa roon, nakadepende ito sa kung saan nangyari ang mga failure. Maaaring mawalan ang bawat mirror pair ng isa sa dalawang member nito. Kaya kayang mabuhay ng isang eight-drive array ang hanggang apat na failure kung walang dalawang failure na nasa iisang pair. Ngunit magfa-fail ito sa dalawang failure kung parehong tumama sa iisang pair. Magplano batay sa garantisadong bilang, na isa, at ituring na suwerte lamang ang anumang higit pa rito sa halip na proteksiyon.

Dapat ko bang i-mirror ang dalawang volume sa loob ng VPS ko gamit ang mdadm?

Karaniwan, hindi. Madalas na nasa iisang physical array sa iisang host ang dalawang volume na nakakabit sa isang VPS. Dahil dito, dodoble ang gastos ng bawat write at wala itong pinoprotektahan na hindi pa sakop ng sariling RAID ng host. Sulit lamang ito kapag idinokumento ng provider na nasa magkahiwalay na failure domain ang mga volume. Kung hindi, ilaan ang effort sa backups na umaalis sa machine.