RAID 10 là gì? Vì sao VPS dùng RAID 10 cho NVMe

RAID 10 là gì và vì sao nhà cung cấp VPS sử dụng nó

RAID 10 là bố cục lưu trữ được hầu hết nhà cung cấp VPS sử dụng trên các ổ NVMe (non-volatile memory express) ảo hóa. RAID 10 mirror từng ổ với một ổ đối tác, sau đó stripe dữ liệu trên các cặp mirror đó. Một ổ có thể hỏng mà array vẫn tiếp tục hoạt động. Việc rebuild chỉ là sao chép dữ liệu từ ổ đối tác còn hoạt động, thay vì tính toán lại bằng cách đọc mọi ổ khác trong bộ.

RAID là viết tắt của redundant array of independent disks. Nhiệm vụ duy nhất của RAID là giữ cho máy tiếp tục phục vụ khi một ổ bị hỏng hoặc đang được thay thế. Nhiệm vụ đó là availability, không phải safety.

RAID nhân bản các lần ghi của bạn. rm -rf /srv cũng là một lần ghi. Cả hai nửa của mirror đều xóa directory trong cùng một mili giây, nhưng array vẫn báo trạng thái clean sau đó.

Hãy ghi nhớ câu này. Phần còn lại của trang này giải thích mỗi cấp RAID có thể chịu được lỗi nào và mỗi lần ghi khiến bạn mất chi phí gì. Các phần cuối chứa những command dùng để đọc trạng thái của array trên máy do bạn sở hữu, cùng với lỗi mà RAID chưa bao giờ xử lý được.

Các cấp RAID mà người mua hosting thực tế sẽ gặp: 1, 5, 6 và 10

Trang gói dịch vụ thường chỉ nêu một con số rồi dừng lại. Con số đó trả lời hai câu hỏi: có thể mất bao nhiêu drive, và mỗi lần ghi phải trả giá như thế nào.

RAID 1 là mirror. Hai drive chứa các block giống hệt nhau. Mỗi lần ghi đều được gửi đến cả hai drive. Drive nào cũng có thể phục vụ thao tác đọc. Một drive có thể hỏng mà không mất dữ liệu, và chỉ một nửa dung lượng thô có thể sử dụng. Không có parity phải tính toán nên đường ghi ngắn.

RAID 5 là striping với một parity block cho mỗi stripe. Với n drive, bạn có dung lượng tương đương n-1 drive, và array chịu được đúng một lỗi. Parity không nằm trên một drive chuyên dụng. Nó luân phiên trên tất cả drive, nên mỗi drive đều chứa cả data và parity.

RAID 6 thêm một parity block độc lập thứ hai vào mỗi stripe, thường được gọi là P và Q. Nó chịu được trường hợp bất kỳ hai drive cùng hỏng. Điều này quan trọng hơn tưởng tượng, vì lỗi thứ hai thường xảy ra trong lúc repair lỗi đầu tiên.

RAID 10 là một stripe gồm các mirror. Các drive được mirror theo từng cặp, rồi data được phân bổ trên các cặp đó. Dung lượng sử dụng bằng một nửa tổng dung lượng thô, giống RAID 1, nhưng có thêm khả năng xử lý song song của striping.

Bạn cũng sẽ thấy cách viết RAID 1+0. Đây là mô tả chính xác: mirror trước, rồi stripe trên các mirror. RAID 0+1 làm theo thứ tự ngược lại: stripe trước, rồi mirror hai stripe. Cách này kém hơn, vì một drive hỏng sẽ khiến toàn bộ một stripe không còn phục vụ được, và quá trình repair phải copy toàn bộ phía còn lại.

Linux là một trường hợp đặc biệt đáng biết. raid10 của kernel là một personality duy nhất thay vì hai layer xếp chồng, nên nó chạy được trên số drive lẻ và có các layout (near, far, offset) mà cấu hình lồng nhau không thể biểu diễn. Vì vậy, dòng trạng thái trên một máy Linux hiển thị 2 near-copies thay vì gọi tên hai 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
  }
]

Tám drive 1 TB cho 7 TB dung lượng sử dụng được với RAID 5 và 4 TB với RAID 10. Chênh lệch đó tương đương chi phí thực tế, và đó là lý do parity luôn được đề xuất. RAID 6 chịu được 2 lỗi theo bất kỳ mô hình nào. RAID 10 chỉ đảm bảo 1, vì lỗi thứ hai nguy hiểm là lỗi xảy ra trên drive ghép cặp với drive đã hỏng. Trong trường hợp không có hai lỗi cùng xảy ra trên một cặp, nó chịu được tối đa 4, nhưng đó là may mắn chứ không phải đặc tính thiết kế.

Chi phí của mỗi cấp trên từng lần ghi

Ghi vào mirror là 2 lần ghi, được phát hành đồng thời đến cả 2 thành viên. Ghi vào một parity stripe tốn nhiều công việc hơn, vì parity block của stripe đó không còn đúng và phải được tính lại.

Controller không thể tính lại parity chỉ từ block mới. Trước tiên, nó cần data block cũ và parity block cũ. Vì vậy, một lần ghi ngẫu nhiên nhỏ trên RAID 5 trở thành read, read, write, write. RAID 6 phải duy trì thêm một syndrome, nên cùng lần ghi đó trở thành 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
  }
]

Một lần ghi ngẫu nhiên nhỏ tốn 6 thao tác trên device khi dùng RAID 6 và 2 khi dùng RAID 10. Các con số này chưa phản ánh đầy đủ khác biệt về latency. Hai lần ghi vào mirror được gửi song song, nên guest phải chờ thao tác chậm hơn trong 2 thao tác. Với parity path, một lần read phải hoàn tất trước khi có thể tính parity mới, nên guest phải chờ một lần read rồi một lần write theo thứ tự. Trên host bận, lần read đó phải xếp hàng sau I/O của mọi tác vụ khác.

Có một ngoại lệ quan trọng. Một lần ghi đủ lớn để lấp đầy toàn bộ stripe không cần data cũ, vì mọi block trong stripe đều bị thay thế. Parity được tính từ dữ liệu đã có trong memory, và chi phí giảm xuống còn 1 lần ghi bổ sung. Đây là lý do RAID 5 có vẻ hoạt động tốt trong sequential benchmark nhưng hoạt động kém khi chịu mixed load gồm các lần ghi nhỏ từ nhiều tenant. Hãy kiểm tra đúng pattern bạn thực sự chạy: benchmark ổ đĩa VPS đúng cách nghĩa là random I/O với queue depth thực tế, không phải một dd lớn.

Vì sao rebuild là giai đoạn nguy hiểm

Parity rebuild phải tái tạo drive bị thiếu từ toàn bộ dữ liệu trên các drive còn lại, nên nó đọc 7 drive còn hoạt động, từ block đầu tiên đến block cuối cùng. RAID 10 rebuild chỉ đọc 1: mirror partner của drive bị hỏng, không đọc thêm drive nào khác.

Điều này dẫn đến 2 chi phí. Thứ nhất là thời gian, vì thời gian rebuild bị giới hạn bởi drive còn hoạt động chậm nhất và phần tính toán parity. Thứ hai là tải. Mọi drive trong một parity set đều bận trong toàn bộ khoảng thời gian đó, nên mọi guest trên node đều có latency cao hơn cho đến khi rebuild kết thúc. Với RAID 10, chỉ một cặp drive bận; các cặp còn lại vẫn phục vụ ở tốc độ bình thường.

Trong cùng khoảng thời gian đó còn có rủi ro về tính toàn vẹn dữ liệu. RAID 5 có một drive bị hỏng sẽ không còn redundancy, nên một sector không thể đọc được trên bất kỳ drive còn hoạt động nào cũng không thể khôi phục. Rebuild là thao tác đọc mọi sector, kể cả những sector không được truy cập trong suốt một năm. Các con số trong datasheet được công bố cho thấy một hard drive dành cho người dùng phổ thông có thể gặp gần 1 lỗi đọc không thể khôi phục trên mỗi 10^14 bit đã đọc, còn enterprise NVMe drive là 1 lỗi trên mỗi 10^17 bit hoặc tốt hơn. Đây là thông số của vendor chứ không phải kết quả đo thực tế, nhưng tỷ lệ này giải thích vì sao cảnh báo cũ rằng RAID 5 rebuild sẽ fail thường nói về các đĩa quay dung lượng lớn, và vì sao cảnh báo đó ít đúng hơn nhiều với NVMe. Lập luận về tải vẫn đúng với mọi loại thiết bị lưu trữ.

Hãy phát hiện lỗi tiềm ẩn trước khi rebuild bằng cách scrub. Debian và Ubuntu có cơ chế scrub định kỳ cho md array, nhưng cơ chế này khác nhau giữa các release, nên hãy kiểm tra hệ thống đang dùng cơ chế nào rồi trigger một pass thủ công.

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 quay về idle khi pass kết thúc, và mismatch_cnt phải hiển thị 0. Giá trị lớn hơn 0 trên một mirror có nghĩa là 2 nửa không khớp nhau và kernel không thể xác định bản nào đúng, vì không bản sao nào có checksum. Một số mismatch không gây hại; swap partition là nguồn thường gặp nhất, vì kernel có thể ghi một page rồi page đó thay đổi ngay bên dưới. Counter tăng trên data array là dấu hiệu cần thay drive.

Vì sao nhà cung cấp VPS thường chọn RAID 10 cho NVMe

Một node hypervisor không chỉ chạy một workload. Nó chạy hàng chục guest không liên quan đến nhau, với I/O đến xen kẽ thành một luồng gồm các lần ghi nhỏ và không có tính cục bộ giữa chúng. Đây chính xác là kiểu tải khiến chu kỳ đọc–sửa đổi–ghi của parity tốn kém nhất, và cũng là kiểu tải mà một node dùng chung phải xử lý cả ngày.

Xét thêm cách rebuild hoạt động thì lựa chọn trở nên rõ ràng. Khi một drive hỏng trên node dùng parity, mọi guest trên máy đều chậm đi trong nhiều giờ. Khi một drive hỏng trên node RAID 10, chỉ một cặp bị ảnh hưởng, còn quá trình sao chép chạy tuần tự theo tốc độ của drive. Nhà cung cấp đang bán độ trễ ổn định, không tăng đột biến, nên họ đánh đổi bằng dung lượng: một nửa dung lượng NVMe thô được dành cho mirror.

Dung lượng drive lớn hơn cũng đẩy lựa chọn theo hướng đó. Drive càng lớn thì thời gian rebuild càng dài. Với parity, đó là khoảng thời gian mọi thứ chậm và không có gì được bảo vệ. Đây cũng là lý do các hệ thống ZFS cho môi trường ảo hóa dùng pool gồm các mirrored vdev thay vì raidz có độ rộng lớn: quá trình resilver của mirror chỉ sao chép các block thực sự đang được sử dụng trên một cặp.

Điều này không có nghĩa RAID 10 luôn là lựa chọn đúng. Backup target thường được ghi thành các chuỗi tuần tự dài và hiếm khi được đọc, nên RAID 6 phù hợp hơn. RAID 6 chịu được 2 lỗi và trả lại phần lớn dung lượng. Workload mới là yếu tố quyết định, không phải con số. Với một plan bạn chọn hôm nay, loại medium thường quan trọng hơn layout bên trên nó, và bước chuyển từ SATA SSD sang NVMe lớn hơn mọi khác biệt RAID trên cả hai loại.

Cách đọc /proc/mdstat

Chạy các lệnh này trên máy có array do bạn quản lý: dedicated server, máy tại nhà hoặc VPS có 2 volume được gắn và tự bạn lắp vào array. Hãy đọc output của chính máy bạn. Các khối bên dưới là ví dụ, được ghi đầy đủ để bạn có thể đối chiếu cấu trúc output thực tế.

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

RAID 10 gồm 4 drive khỏe mạnh thường in ra nội dung gần giống như sau.

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>

Mỗi phần trong output này đều chứa thông tin.

• Personalities liệt kê các md module mà kernel đang chạy đã load. Việc raid10 xuất hiện ở đó chỉ có nghĩa là code đã khả dụng, không có ý nghĩa nào khác.
• md0 : active raid10 là thiết bị array, trạng thái và level của array.
• Các tên theo sau là các member. Số trong dấu ngoặc vuông là index của thiết bị trong metadata của array, không phải vị trí của thiết bị trên dòng và cũng không phải lúc nào cũng là slot.
• Sau khi thay drive, member mới thường giữ index cao hơn slot mà nó thay thế, nên nvme4n1p3[4] có thể nằm ở slot 2. mdadm --detail in slot thực trong cột RaidDevice của nó, vì vậy hãy dùng cột này khi sự khác biệt có ý nghĩa.
• (F) sau một member có nghĩa là member đó bị lỗi. (S) có nghĩa là spare: đã có mặt, đang idle và chờ một thành phần bị lỗi.
• 3906764800 blocks super 1.2 là dung lượng có thể sử dụng, tính bằng block 1 KiB, sau đó là định dạng metadata.
• 512K chunks 2 near-copies là kích thước chunk của stripe và layout RAID 10. Trong ví dụ này, layout giữ 2 bản sao của mỗi block cạnh nhau.
• [4/4] là số member mà array yêu cầu, sau đó là số member hiện đang đồng bộ.
• [UUUU] là 1 ký tự cho mỗi slot, theo thứ tự slot. U là slot đang hoạt động và đã đồng bộ. _ là slot không có thành phần nào đang hoạt động.
• bitmap: là write intent bitmap. Nó ghi lại các vùng đang được ghi, để member bị mất kết nối rồi hoạt động trở lại chỉ cần resync các vùng đó thay vì toàn bộ drive.

Ý nghĩa của [4/3] và [UU_U] khi có lỗi

Array ở trạng thái degraded sẽ hiển thị như sau.

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]

Hãy đọc 2 cặp dấu ngoặc cùng nhau. [4/3] cho biết 1 trong 4 slot không đóng góp dữ liệu. [UU_U] cho biết slot nào bị ảnh hưởng, vì dấu gạch dưới là ký tự thứ 3 và các slot được đánh số từ 0, nên slot 2 đang down. Cờ (F) chỉ định danh thiết bị khi drive bị lỗi vẫn còn được gắn trong máy. Khi rút drive đó khỏi máy, tên sẽ biến mất khỏi dòng output, còn dấu gạch dưới vẫn giữ nguyên.

Array vẫn tiếp tục phục vụ trong tình trạng này. Với RAID 10, tốc độ thường vẫn gần bằng tốc độ đầy đủ, nên bạn có thể không nhận ra bằng cảm nhận thông thường. Bạn cần một cơ chế khác để phát hiện lỗi.

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

Package mdadm cài một monitor daemon đọc MAILADDR từ /etc/mdadm/mdadm.conf. Tên unit đã thay đổi giữa các bản release, vì vậy hãy dùng lệnh cuối cùng để tìm tên thay vì đoán. Lệnh --test gửi ngay 1 message cho mỗi array. Nếu inbox vẫn trống sau khi chạy lệnh, mail path đang bị lỗi. Khi đó message bạn thực sự cần sẽ cũng bị mất theo cách tương tự.

Khi replacement đang được rebuild, một dòng tiến độ sẽ xuất hiện bên dưới 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

recovery là quá trình rebuild lên replacement drive. resync là lần kiểm tra consistency đầu tiên trên array mới tạo. check là scrub mà bạn đã kích hoạt ở trên. Cặp số trong ngoặc là tiến độ tính bằng block 1 KiB so với tổng số block trên mỗi thiết bị, còn finish là thời gian ước tính của kernel dựa trên tốc độ hiện tại. Tốc độ này bị giới hạn bởi /proc/sys/dev/raid/speed_limit_min và speed_limit_max. Các giới hạn này nhằm tránh để quá trình rebuild chiếm hết tài nguyên I/O của production.

/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

Thay drive trên array do bạn quản lý cần 4 lệnh. Lệnh cuối cùng là bước kiểm tra.

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

Dòng recovery sẽ xuất hiện trong vòng 1 hoặc 2 giây. Partition thay thế phải có kích thước ít nhất bằng Used Dev Size trong mdadm --detail. Nếu partition nhỏ hơn dù chỉ một chút, nó sẽ bị từ chối với message có dạng not large enough to join array. Hãy partition drive mới để khớp với drive cũ trước khi thêm nó vào array.

Bạn có thể và không thể thấy gì từ bên trong VPS

Hầu hết guest không thể thấy RAID của host. Đây là thiết kế có chủ ý. Hypervisor cung cấp cho bạn một virtual disk. Đĩa đó được tạo từ một pool RAID 10 gồm các ổ NVMe hay nằm trên một ổ duy nhất là thuộc tính của host, và không hiển thị bên trong guest.

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

systemd-detect-virt in kvm trên KVM guest, một loại container như lxc trên container và none trên bare metal. Trên KVM guest, bạn thường chỉ thấy một vda hoặc sda trong lsblk và không thấy array nào trong /proc/mdstat, vì bên trong guest không có array.

Trên VPS chạy bằng container, thông tin này không đáng tin cậy. Container dùng chung kernel của host, và một phần của /proc không được tách namespace. Vì vậy, thông tin bạn đọc được có thể mô tả host thay vì phần tài nguyên của bạn. Không nên xem bất kỳ thông tin nào trong đó là sự thật về storage của chính bạn. Hãy hỏi provider về layout và yêu cầu trả lời bằng văn bản nếu thông tin này quan trọng với bạn.

Bạn có thể kiểm tra từ bên trong là hành vi của disk được cấp cho mình. Kiểm tra disk VPS có thực sự là NVMe hay không trình bày các lệnh cho kết quả thực tế, còn VPS SSD thực sự bao gồm những gì giải thích những gì nhãn trên trang gói dịch vụ đang cam kết.

Có nên chạy RAID bên trong VPS không?

Thường là không, vì vấn đề nằm ở failure domain. Nếu bạn gắn hai volume vào một VPS rồi mirror chúng bằng mdadm, cả hai volume có thể nằm trên cùng một physical array, cùng một node và dùng chung một power supply. Bạn sẽ tốn gấp đôi chi phí cho mỗi lần ghi để có mức redundancy mà mình vốn đã có, nhưng vẫn mất cả hai bản sao khi xảy ra đúng một lỗi quan trọng đó.

Việc này đáng làm nếu provider xác nhận các volume nằm trong những failure domain riêng biệt, hoặc nếu bạn dùng dedicated server có các drive mà bạn có thể trực tiếp quản lý. Nếu không, hãy tập trung vào việc tạo các bản sao được lưu bên ngoài máy.

RAID không bảo vệ bạn khỏi những gì

RAID chỉ xử lý một sự cố: một drive ngừng hoạt động đúng cách. Mọi thao tác bên dưới đều là thao tác ghi hợp lệ, nên array áp dụng chúng cho mọi bản sao và vẫn báo trạng thái healthy.

• Xóa dữ liệu. rm -rf trong sai thư mục, hoặc deploy script có biến chưa được set trong một path. Array thấy đây là thao tác ghi hợp lệ và thực hiện nó hai lần.
• Ransomware. Mã hóa là thao tác ghi dữ liệu. Array đang hoạt động bình thường sẽ lưu phiên bản đã mã hóa trên cả hai nửa mirror.
• Ứng dụng bị lỗi. Bug ghi dữ liệu rác vào database của bạn cũng ghi đúng dữ liệu rác đó vào drive dự phòng.
• Toàn bộ node. Một host bị lỗi hoặc một account bị suspend do nhầm lẫn. Array có thể hoàn toàn nguyên vẹn nhưng đồng thời không thể truy cập.
• Chính bạn, một tuần sau. File bạn xóa vào thứ Hai đã biến mất khỏi mọi drive ngay trong ngày thứ Hai. Chỉ bản sao được tạo trước thời điểm đó mới khôi phục được file.

Snapshot trên cùng storage cũng không phải cách giải quyết. Snapshot giúp xử lý việc xóa dữ liệu, nhưng sẽ mất cùng array nơi chúng được lưu. Điều làm cho một bản backup thực sự là backup là nó nằm ở nơi khác. Backup được mã hóa ngoài server bằng restic là nửa còn lại của trang này: array giúp bạn tiếp tục cung cấp dịch vụ khi một drive hỏng, còn restic khôi phục dữ liệu khi sự cố là một thao tác ghi mà array vẫn chấp nhận.

FAQ

RAID 10 có nghĩa là tôi không cần backup phải không?

Không. RAID 10 bảo vệ trước lỗi khiến một drive ngừng hoạt động. Mọi thao tác ghi hợp lệ đều được áp dụng cho cả hai nửa của mirror, nên thao tác xóa hoặc ransomware cũng đến drive dự phòng trong cùng một thời điểm. Sau đó array vẫn báo trạng thái sạch, vì theo góc nhìn của nó không có gì bị lỗi. Bạn vẫn cần các bản sao được lưu bên ngoài máy, và vẫn cần thỉnh thoảng restore một bản để xác nhận chúng hoạt động.

Vì sao nhà cung cấp VPS chọn RAID 10 thay vì RAID 5 hoặc RAID 6?

Có hai lý do, đều liên quan đến thao tác ghi ngẫu nhiên nhỏ. Khi ghi parity, hệ thống phải đọc lại data cũ và parity cũ trước khi tính parity mới. Vì vậy, một thao tác ghi nhỏ tốn 4 thao tác trên RAID 5 và 6 trên RAID 6, trong khi mirror chỉ tốn 2. Khi rebuild parity, hệ thống phải đọc toàn bộ từng drive còn hoạt động từ đầu đến cuối. Việc này làm chậm mọi guest trên node trong nhiều giờ. Trong khi đó, RAID 10 chỉ copy dữ liệu từ một drive sang một drive và không ảnh hưởng đến các cặp còn lại. Nhà cung cấp phải đánh đổi bằng dung lượng: chỉ sử dụng được một nửa dung lượng NVMe thô.

[U_] hoặc [UU_U] trong /proc/mdstat có nghĩa là gì?

Mỗi ký tự đại diện cho một slot trong array, theo thứ tự slot, mỗi slot có một ký tự. U nghĩa là slot đó chứa một member đang hoạt động và đã đồng bộ. _ nghĩa là slot đó không có gì đang hoạt động. [U_] trên một mirror gồm hai drive nghĩa là slot thứ hai đã down và array không còn redundancy. Hãy đọc nó cùng với cặp ký tự phía trước, trong đó [4/3] cho biết array mong đợi bốn member nhưng hiện chỉ có ba. Thứ tự slot khớp với cột RaidDevice của mdadm --detail, không phải thứ tự xuất hiện của các device name trên dòng đó.

Một array RAID 10 có thể mất bao nhiêu drive?

Một drive, với mọi kiểu lỗi. Nếu mất nhiều hơn thì còn tùy các lỗi rơi vào đâu. Mỗi mirror pair có thể mất một trong hai member. Vì vậy, một array gồm tám drive có thể chịu được tối đa bốn lỗi nếu không có hai lỗi nào cùng nằm trong một pair, nhưng sẽ hỏng khi có hai lỗi nếu cả hai cùng rơi vào một pair. Hãy lập kế hoạch dựa trên số lượng chắc chắn được bảo vệ là một, và xem mọi khả năng vượt quá con số đó là may mắn chứ không phải cơ chế bảo vệ.

Có nên mirror hai volume bên trong VPS bằng mdadm không?

Thường là không. Hai volume gắn vào một VPS thường nằm trên cùng một physical array của cùng một host. Vì vậy, việc mirror khiến chi phí của mọi thao tác ghi tăng gấp đôi nhưng không bảo vệ được trước sự cố nào mà RAID của host chưa xử lý. Chỉ nên làm vậy khi nhà cung cấp xác nhận các volume nằm trong các failure domain riêng biệt. Nếu không, hãy dành công sức đó cho các bản backup được lưu bên ngoài máy.