RAID 10 là gì? Vì sao VPS chọn RAID 10 cho NVMe

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

RAID 10 là layout lưu trữ mà hầu hết nhà cung cấp VPS sử dụng trên các ổ NVMe (non-volatile memory express) được ảo hóa. Trong layout hai bản sao thông thường, RAID 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 không dừng hoạt động. Quá trình sửa chữa chỉ cần copy dữ liệu từ ổ đối tác còn sống, thay vì tính toán lại bằng cách đọc mọi ổ khác trong array.

RAID là viết tắt của redundant array of independent disks. RAID chỉ có một nhiệm vụ: duy trì hoạt động của máy khi một ổ đĩa bị hỏng hoặc đang được thay thế. Nhiệm vụ đó là availability, không phải safety.

RAID replicate mọi write của bạn. rm -rf /srv là một write. 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 level có thể chịu được những lỗi nào và mỗi write khiến bạn tốn chi phí gì. Các phần cuối chứa những command để đọc trạng thái của array trên máy bạn sở hữu, cùng với lỗi mà RAID chưa bao giờ bảo vệ được.

Các cấp RAID mà người mua dịch vụ hosting thực 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 ổ đĩa, và mỗi lần ghi phải trả giá thế nào.

RAID 1 là mirror. Hai ổ đĩa chứa các block giống hệt nhau. Mỗi lần ghi đều được thực hiện trên cả hai ổ. Cả hai ổ đều có thể phục vụ thao tác đọc. Một ổ có thể hỏng mà không làm 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 đi của thao tác ghi ngắn.

RAID 5 là striping với một block parity cho mỗi stripe. Với n ổ đĩa, bạn có dung lượng tương đương n-1 ổ, và array chịu được chính xác một ổ hỏng. Parity không nằm trên một ổ chuyên dụng. Nó luân phiên trên tất cả các ổ, nên mỗi ổ đều chứa cả dữ liệu và parity.

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

RAID 10 là một stripe gồm các mirror. Các ổ đĩa được mirror theo từng cặp, rồi dữ liệu đượ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 tính 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, sau đó stripe trên các mirror. RAID 0+1 thực hiện 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 ổ hỏng sẽ khiến toàn bộ một stripe ngừng hoạt động 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 lớp xếp chồng, nên nó chạy được trên số lượng ổ đĩa 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, status line trên máy Linux hiển thị 2 near-copies thay vì gọi tên hai array.

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

Tám ổ đĩa 1 TB cho 7 TB dung lượng sử dụng với RAID 5 và 4 TB với RAID 10. Chênh lệch này là 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ỳ dạng 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 ổ ghép cặp với ổ đã hỏng. Nó chịu được tối đa 4 lỗi khi không có hai lỗi nào cùng rơi vào một cặp, 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 mỗi lần ghi

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

Với read-modify-write, controller trước tiên đọc data cũ và parity cũ. Một lần overwrite một block không có cache trên RAID 5 sẽ trở thành read, read, write, write. RAID 6 duy trì hai block parity, nên read-modify-write trở thành read, read, read, write, write, write. Linux cũng dùng reconstruct-write, tức là đọc các data không thay đổi để tính parity. Trên RAID 5 gồm ba drive, lần overwrite đó có thể cần một lần đọc data và hai lần ghi; trên RAID 6 gồm bốn drive, cần một lần đọc data và ba lần ghi. Bốn và sáu là số lần read-modify-write, không phải chi phí cố định cho mọi lần ghi ngẫu nhiên nhỏ.

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

Một lần read-modify-write một block không có cache tốn 6 thao tác trên device trên RAID 6, so với 2 cho cùng lần overwrite trên RAID 10 hai bản sao. Các con số này vẫn chưa phản ánh đầy đủ khác biệt về latency. Hai lần ghi vào mirror được thực hiện song song, nên guest phải chờ thao tác chậm hơn trong hai thao tác. Đường đi read-modify-write có một lần đọc phải hoàn tất trước khi parity mới được tính, nên guest phải chờ đọc rồi mới đến ghi, theo thứ tự lần lượt. Trên host đang bận, lần đọc đó phải xếp hàng sau I/O của mọi tenant 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 được thay thế. Parity được tính từ dữ liệu đã có trong memory, và overhead giảm xuống còn một lần ghi parity cho mỗi stripe trên RAID 5 hoặc hai lần trên RAID 6, không cần preread. Đây là lý do RAID 5 cho kết quả tốt trong benchmark tuần tự nhưng hoạt động kém dưới tải hỗn hợp 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 disk VPS đúng cách nghĩa là I/O ngẫu nhiên với queue depth thực tế, không phải một dd lớn duy nhất.

Phần rebuild là bước nguy hiểm

Một lần rebuild đầy đủ của RAID 5 phải tái tạo ổ đĩa bị thiếu từ toàn bộ dữ liệu trên các ổ còn lại. Vì vậy, trong ví dụ tám ổ đĩa, nó đọc 7 ổ còn hoạt động từ block đầu tiên đến block cuối cùng. Với các cặp mirror cố định gồm hai bản sao, rebuild RAID 10 chỉ đọc 1: ổ mirror của ổ đã hỏng, và không đọc gì khác. Các layout Linux RAID10 khác phân bố bản sao theo cách khác. Rebuild một member trong layout near ba thiết bị sẽ đọc cả hai member còn lại.

Có hai loại chi phí phát sinh. Thứ nhất là thời gian, vì tốc độ rebuild bị giới hạn bởi các ổ còn hoạt động, khối lượng công việc tái tạo và mục tiêu tốc độ recovery. Thứ hai là tải. Rebuild có parity phân tán I/O trên các ổ còn hoạt động. Với các cặp mirror cố định, rebuild RAID 10 tập trung I/O vào một cặp; tài nguyên dùng chung của controller và host vẫn ảnh hưởng đến các cặp khác.

Trong cùng khoảng thời gian đó còn có rủi ro về tính đúng đắn của dữ liệu. Array RAID 5 có một ổ đã hỏng thì không còn redundancy, nên một sector không thể đọc được ở bất kỳ ổ còn hoạt động nào cũng không thể recovery. Rebuild là thao tác duy nhất đọc mọi sector, kể cả những sector chưa ai truy cập trong một năm. Các số liệu 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 một lỗi đọc không thể recovery trên mỗi 10^14 bit được đọc, còn enterprise NVMe drive là một lỗi trên mỗi 10^17 bit hoặc tốt hơn. Đây là thông số do vendor công bố chứ không phải kết quả đo, nhưng tỷ lệ này giải thích vì sao cảnh báo cũ rằng rebuild RAID 5 sẽ fail được viết trong bối cảnh các hard disk dung lượng lớn, và vì sao cảnh báo đó ít đáng lo hơn nhiều trên NVMe. Lập luận về tải vẫn đúng với mọi loại medium.

Hãy tìm các lỗi tiềm ẩn trước khi rebuild phát hiện ra chúng 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. Vì vậy, hãy kiểm tra hệ thống đang dùng cơ chế nào rồi trigger một lượt scrub 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 lại idle khi lượt scrub hoàn tất, và mismatch_cnt phải hiển thị 0. Giá trị lớn hơn zero trên mirror có nghĩa là hai nửa không giống 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 phổ biến nhất, vì kernel có thể ghi một page và page đó thay đổi ngay bên dưới quá trình kiểm tra. Nếu count tăng trên data array, cần điều tra. Chỉ dựa vào count thì không thể xác định ổ đĩa nào cần thay thế.

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 đan xen thành một luồng gồm các lần ghi nhỏ và không có locality giữa chúng. Đây chính xác là kiểu tải khiến chu kỳ đọc-sửa-ghi của parity tốn chi phí nhất, và đó là kiểu tải mà một node dùng chung phải xử lý cả ngày.

Thêm hành vi khi rebuild, lựa chọn này càng rõ ràng. Khi một drive hỏng trên node dùng parity, hệ thống phải thực hiện công việc tái tạo trên các drive còn lại. Với các cặp mirror cố định, khi một drive hỏng trên node RAID 10, I/O rebuild chỉ dồn vào một cặp. Linux MD cũng giảm tốc độ khôi phục khi đang có hoạt động khác. Nhà cung cấp bán mức latency 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ùng cho mirror.

Dung lượng drive cũng dẫn đến lựa chọn tương tự. Drive càng lớn thì thời gian rebuild càng dài. Với RAID 5, đây là khoảng thời gian quá trình tái tạo làm tăng tải và hệ thống không còn redundancy. RAID 6 vẫn bảo vệ được khi thêm một drive nữa bị lỗi. ZFS dùng cho virtualisation cũng có lý do tương tự khi dùng pool gồm các mirrored vdev thay vì raidz có bề rộng lớn: 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. Nó 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 về RAID trên cả hai loại.

Cách đọc /proc/mdstat

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

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

Một RAID 10 khỏe với bốn drive thường in ra nội dung gần 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 đều chứa thông tin.

• Personalities liệt kê các md module mà kernel đang chạy đã load. raid10 xuất hiện ở đó nghĩa là code khả dụng, không nói thêm điều gì.
• md0 : active raid10 là thiết bị array, trạng thái và level của array.
• Các tên đứng sau đó là các member. Số trong ngoặc vuông là index của thiết bị trong metadata của array, không phải vị trí trên dòng và cũng không phải lúc nào 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, 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 nghĩa là member đó bị lỗi. (S) nghĩa là spare: đã có mặt, đang idle và chờ một thiết bị lỗi.
• 3906764800 blocks super 1.2 là dung lượng có thể sử dụng, tính theo block 1 KiB, sau đó là format metadata.
• 512K chunks 2 near-copies là kích thước stripe chunk và layout RAID 10. Trong ví dụ này, layout giữ hai 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à một 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ó thiết bị nào đang hoạt động.
• bitmap: là write intent bitmap. Nó ghi lại những region đang được ghi, để member bị ngắt rồi kết nối lại chỉ resync các region đó thay vì toàn bộ drive.

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

Array bị degraded sẽ có dạng 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 hai cặp ngoặc cùng nhau. [4/3] cho biết một trong bốn slot không đóng góp dữ liệu. [UU_U] cho biết slot nào, vì dấu gạch dưới là ký tự thứ ba và các slot được đánh số từ 0, nên slot 2 đang down. Flag (F) chỉ định danh thiết bị trong lúc drive lỗi vẫn còn được gắn vào máy. Khi rút drive đó khỏi máy, tên sẽ biến mất khỏi dòng này, 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, array thường vẫn chạy gần tốc độ đầy đủ, nên bạn có thể không nhận ra bằng cảm nhận thông thường. Cần có cơ chế khác để báo cho bạn.

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 release, vì vậy hãy tìm bằng lệnh cuối cùng thay vì đoán. Lệnh --test gửi ngay một message cho mỗi array. Nếu inbox không có message sau khi chạy lệnh, mail path đã bị lỗi. Message mà bạn thực sự cần sẽ cũng bị mất theo cách đó.

Khi replacement đang được rebuild, một dòng tiến trình 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à rebuild lên replacement drive. resync là consistency pass, bao gồm pass ban đầu và quá trình recovery sau khi shutdown không sạch. check là scrub mà bạn đã kích hoạt ở trên. Cặp số trong ngoặc là tiến trình tính theo block 1 KiB so với tổng dung lượng trên mỗi thiết bị, còn finish là thời gian ước tính của kernel ở tốc độ hiện tại. Linux MD dùng /proc/sys/dev/raid/speed_limit_min và speed_limit_max làm các mục tiêu tốc độ recovery, với các override theo từng array trong sync_speed_min và sync_speed_max. Mục tiêu tối đa mặc định là 200,000 KiB/s trên mỗi thiết bị; các mục tiêu này cho phép recovery nhường tài nguyên cho production I/O và không phải hard speed cap.

/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 mà bạn sở hữu cần bốn lệnh, và 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 một hoặc hai giây. Partition replacement phải có kích thước ít nhất bằng Used Dev Size lấy từ mdadm --detail. Partition nhỏ hơn dù chỉ một chút cũng 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 add nó.

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 sao?

Không. RAID 10 bảo vệ khi một drive ngừng hoạt động. Nó ghi mọi dữ liệu hợp lệ vào cả hai nửa của mirror, nên thao tác xóa hoặc ransomware chạy trên máy sẽ đồng thời tác động đến drive dự phòng. Sau đó array vẫn báo trạng thái clean, vì theo góc nhìn của nó thì không có thành phần nào 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 định kỳ restore một bản để xác nhận chúng dùng được.

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

Có 2 lý do, đều liên quan đến các thao tác ghi ngẫu nhiên nhỏ. Một thao tác đọc-sửa-ghi một block, khi không có cache, phải đọc dữ liệu cũ và parity trước khi tính parity mới. Chi phí là 4 thao tác trên RAID 5 và 6 trên RAID 6, so với 2 trên mirror hai bản sao. Reconstruct-write sử dụng dữ liệu không thay đổi, còn ghi full-stripe không cần đọc trước dữ liệu cũ hoặc parity cũ. Khi rebuild toàn bộ RAID 5, hệ thống phải đọc toàn bộ các drive còn sống từ đầu đến cuối. Trong khi đó, RAID 10 thông thường với các cặp mirror cố định sẽ copy từ thành viên mirror còn sống; các layout RAID10 khác của Linux sử dụng nhiều member nguồn. Linux MD giới hạn tốc độ recovery khi có hoạt động khác đang diễn ra. Nhà cung cấp phải đánh đổi bằng dung lượng: mất 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ự tương ứng với 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 đó hiện không có gì hoạt động. [U_] trên mirror hai drive nghĩa là slot thứ hai đã down và không còn redundancy. Hãy đọc chuỗi này cùng với cặp số ở phía trước. Cặp số đó cho biết qua [4/3] rằng array cần 4 member và hiện có 3 member. Thứ tự slot tương ứng với cột RaidDevice của mdadm --detail, không phải thứ tự xuất hiện của device name trên dòng đó.

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

Với RAID 10 thông thường gồm các cặp mirror cố định, array luôn chịu được 1 drive, bất kể vị trí lỗi. Nếu mất nhiều hơn, khả năng sống sót phụ thuộc vào vị trí các lỗi. Mỗi cặp mirror có thể mất 1 trong 2 member. Vì vậy, array 8 drive có thể chịu tối đa 4 lỗi nếu không có 2 lỗi nào nằm trong cùng một cặp, nhưng sẽ hỏng khi có 2 lỗi cùng rơi vào một cặp. Hãy lập kế hoạch dựa trên số lượng chắc chắn được bảo vệ, là 1, 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ệ.

Tôi có nên mirror 2 volume bên trong VPS bằng mdadm không?

Thường là không. 2 volume gắn vào một VPS thường nằm trên cùng một physical array trên cùng một host. Vì vậy, mirror chúng sẽ nhân đôi chi phí của mọi thao tác ghi 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 rõ rằng 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 đưa ra khỏi máy.