RAID và dRAID

1. Tổng quan

Bạn có thể đã quen với RAID truyền thống, nhưng khi làm việc với hàng chục đến hàng trăm ổ đĩa, bạn sẽ thấy RAIDZ trở nên kém hiệu quả. Đó là lúc ZFS dRAID tỏa sáng.

Mục tiêu bài viết

• So sánh RAIDZ và dRAID trong ZFS
• Phân tích điểm giống và khác
• Cách dữ liệu được ghi, parity được tính
• Ưu/nhược điểm rõ ràng cho từng giải pháp

RAIDZ vs dRAID

2. Cơ chế logic hoạt động

RAIDZ: Striping cố định theo thứ tự

RAIDZ giống như viết dữ liệu thành từng dải (strip), mỗi dải gồm nhiều block và parity.

Ghi 1 block vào RAIDZ (ví dụ RAIDZ2 với 6 ổ):

| Disk 1 | Disk 2 | Disk 3 | Disk 4 | Disk 5 | Disk 6 |
|--------|--------|--------|--------|--------|--------|
|  D0    |  D1    |  D2    |  D3    |  P0    |  P1    |

• Dữ liệu D0-D3 là 4 phần của block
• P0, P1 là parity (2 parity → RAIDZ2)
• Ghi xong stripe → tiếp tục sang strip tiếp theo

Hạn chế là nếu Disk 1 hỏng → chỉ các disk còn lại liên quan phải hoạt động → tốc độ rebuild thấp.

ZFS dRAID: Striping logic, rải đều toàn bộ ổ

• dRAID chia ổ đĩa thành các nhóm cấu trúc logic và mọi block được rải ngẫu nhiên trên toàn bộ ổ.
• Trong ZFS dRAID, không có ổ nào được “gán cố định” là ổ dữ liệu hay ổ parity.
• Mỗi ổ đĩa đều có thể chứa cả data thật và parity, tùy vào stripe/block đang ghi.

Ghi 1 block vào dRAID2 (có 8 ổ):

| Disk 1 | Disk 2 | Disk 3 | Disk 4 | Disk 5 | Disk 6 | Disk 7 | Disk 8 |
|--------|--------|--------|--------|--------|--------|--------|--------|
|  D0    |  P0    |  D1    |  D2    |  D3    |  P1    |  -     |  -     |

• Dữ liệu & parity được rải ngẫu nhiên theo nhóm
• Không theo thứ tự cố định → tối ưu I/O
• Khi rebuild: tất cả ổ cùng tham gia → rất nhanh

3. Ví dụ thực tế khi ghi 1 block dữ liệu

RAIDZ2 (6 ổ đĩa)

Block cần ghi: "ZFSROCKS"

→ Chia ra: D0="ZFS", D1="ROC", D2="KS", tính parity → P0, P1

Ghi như sau:
| Disk 1 | Disk 2 | Disk 3 | Disk 4 | Disk 5 | Disk 6 |
|--------|--------|--------|--------|--------|--------|
|  D0    |  D1    |  D2    |   -    |  P0    |  P1    |

→ Nếu Disk 2 hỏng, chỉ cần Disk 1, 3, 5, 6 để phục hồi D1.

Nhược điểm nếu nhiều block cùng rơi vào nhóm Disk 1–3 → I/O bottleneck.

dRAID2 (8 ổ đĩa)

Giả sử bạn có cấu hình:

draid2:6d:0s:8c

→ Tổng 8 ổ đĩa
→ Mỗi stripe: 6 mảnh dữ liệu + 2 mảnh parity

Ghi File A → Tạo Stripe A

Disk 1: Data A.0
Disk 2: Data A.1
Disk 3: Data A.2
Disk 4: Data A.3
Disk 5: Parity A.0
Disk 6: Data A.4
Disk 7: Parity A.1
Disk 8: Data A.5

→ Tại đây: Disk 5 và Disk 7 chứa parity cho File A

Ghi File B → Tạo Stripe B (phân phối khác)

Disk 1: Parity B.0
Disk 2: Data B.0
Disk 3: Data B.1
Disk 4: Data B.2
Disk 5: Data B.3
Disk 6: Parity B.1
Disk 7: Data B.4
Disk 8: Data B.5

Giờ đây: Disk 1 và Disk 6 chứa parity cho File B
Disk 5 và 7 lại chứa dữ liệu thật

Lợi ích:

• Ghi đồng đều toàn bộ ổ
• Khi một ổ chết → rebuild từ tất cả ổ khác
• Không có “ổ đĩa nóng” (hot disk)

4. Trả lời 1 câu hỏi mình nhận được liên quan đến hiệu năng của RAIDZ và dRaid.

Nếu 1 file được chia thành 8 mảnh (gồm 6 dữ liệu + 2 parity) → ghi lên 8 ổ, thì dù random hay tuần tự, 8 ổ vẫn hoạt động, thì tốc độ có gì khác nhau?

Câu hỏi đặt ra là tại sao dRAID vẫn nhanh hơn về tổng thể?

Trả lời ngắn gọn như sau:

Khi xử lý 1 file nhỏ, đúng là RAIDZ và dRAID có thể tương đương. Nhưng khi hệ thống xử lý nhiều file cùng lúc, hoặc thực hiện rebuild, scrub, hoặc ghi đồng thời, thì phân phối ngẫu nhiên của dRAID làm hệ thống hoạt động hiệu quả hơn.

Phân tích chi tiết:

– Với 1 file nhỏ duy nhất:

• Đúng hoàn toàn với nhận định trên, sẽ không có lợi thế rõ rệt giữa RAIDZ và dRAID trong một request đơn lẻ.
  • Dù là RAIDZ hay dRAID, nếu file chia thành 6 data + 2 parity → 8 ổ tham gia.
  • Cả 2 mô hình đều phải truy cập 8 ổ đĩa cùng lúc.
  • Do đó tốc độ đọc/ghi 1 file đơn lẻ là tương đương.

– Nhưng trong thực tế, hệ thống không chỉ ghi 1 file:

• Khi ghi nhiều file, đặc biệt là:
  • Ghi đồng thời nhiều file nhỏ (workload 4K IOPS)
  • Ghi nhiều file lớn song song
  • Scrub, resilver, rebuild
• RAIDZ: các file thường rơi vào các nhóm đĩa giống nhau (do strip tuyến tính)
  → Dẫn đến một vài ổ bị “nóng” (hot disk), gây nghẽn.
• dRAID: mỗi block phân phối ngẫu nhiên hợp lý trên toàn bộ ổ
  → Các file rải đều trên hệ thống
  → Tất cả ổ cùng làm việc → I/O đồng đều hơn

→ Đây là lý do dRAID vượt trội về hiệu suất tổng thể, đặc biệt khi hệ thống lớn (24, 60, 100+ ổ đĩa).

Khi xảy ra lỗi ổ đĩa (rebuild):

• RAIDZ:
  • Chỉ các ổ nằm trong cùng một stripe với ổ hỏng mới tham gia rebuild.
  • Nếu 1 ổ hỏng → chỉ 6–8 ổ hoạt động → rebuild chậm.
• dRAID:
  • Phân phối parity logic đều trên toàn bộ ổ.
  • Khi 1 ổ hỏng → tất cả các ổ còn lại đều tham gia rebuild.

→ Hiệu quả rebuild của dRAID vượt trội, đặc biệt với nhiều ổ đĩa.

Ví dụ.

Giả sử có 8 ổ đĩa: Disk 1–8

File A: chia 6 data + 2 parity

🟠 RAIDZ (tuần tự):

Stripe 1 (File A): [D0][D1][D2][D3][P0][P1]       → Disk 1–6
Stripe 2 (File B):           [D0][D1][D2][P0][P1]  → Disk 3–7
Stripe 3 (File C):                    [D0][D1][D2][P0][P1] → Disk 5–8

⛔ Lặp lại → Disk 5–6–7–8 bị “nóng” do bị chọn nhiều lần
⛔ Nếu nhiều file cùng lúc → bottleneck tại vài ổ

🔵 dRAID (ngẫu nhiên logic):

File A: [D0 on D1], [D1 on D3], [D2 on D6], [D3 on D8], [P0 on D2], [P1 on D4]
File B: [D0 on D2], [D1 on D5], [D2 on D7], [D3 on D1], [P0 on D4], [P1 on D6]
File C: [D0 on D3], [D1 on D6], [D2 on D8], [D3 on D2], [P0 on D5], [P1 on D7]

✅ Mỗi file được rải khác nhau
✅ Tổng thể ổ đĩa bận đều nhau, không bị nghẽn tại vài ổ cụ thể
✅ Khi rebuild → tất cả 7 ổ còn lại tham gia khôi phục dữ liệu ổ bị lỗi

• Sự khác biệt giữa RAIDZ và dRAID không nằm ở việc ghi 1 file, mà là ở:
  • Phân phối nhiều file
  • Cân bằng hệ thống
  • Hiệu suất khi có lỗi (rebuild)

5. ZFS dRAID hỗ trợ những cấp RAID nào?

ZFS dRAID không hỗ trợ tất cả các cấp RAID truyền thống, nhưng nó tương đương logic với một số cấp:

dRAID dùng số parity để xác định cấp tương đương:

• draid1 = RAIDZ1 = RAID 5
• draid2 = RAIDZ2 = RAID 6
• draid3 = RAIDZ3 = RAID 7 (ít phổ biến hơn)

dRAID yêu cầu:

• Ít nhất: số ổ ≥ data + parity + spares
• Trong đó:
  • data: số ổ chứa dữ liệu
  • parity: số ổ chứa parity (draid1 = 1, draid2 = 2, v.v.)
  • spares: số virtual spares (logic spare disk)

Ví dụ:

zpool create pool1 draid2:8d:2s:12c /dev/sd[b-m]

Vì có parity, nên dRAID luôn có khả năng phục hồi khi 1 hoặc nhiều ổ đĩa hỏng.

dRaid không bắt buộc dùng disk spare vật lý như RAID truyền thống.

dRAID sử dụng virtual spares: bạn khai báo số spare logic (vd: 2s)
→ Khi một ổ hỏng, hệ thống tự động “di chuyển” dữ liệu sang vùng logic spare này → rebuild nhanh mà không cần gắn thêm ổ thật.

Nếu bạn có ổ spare vật lý → vẫn có thể dùng, nhưng không bắt buộc.

So sánh đơn giản RAID 5 vs dRAID1:

Số đĩa tối thiểu để tạo một vdev dRAID được tính theo công thức dưới.

Số disk tối thiểu = số mảnh dữ liệu + số mảnh parity + số virtual spare

Đây là ví dụ cấu hình “bèo” nhất cho dRAID

draid1:2d:0s:3c

• draid1 → 1 parity (tương đương RAID 5)
• 2d → 2 mảnh dữ liệu / stripe
• 0s → không có virtual spare
• 3c → 3 ổ đĩa

→ Đây là cấu hình dRAID tối thiểu có thể chạy được về mặt kỹ thuật.

Thực tế khuyên dùng từ 4 đĩa trở lên, nhưng tại sao thực tế nên dùng 4 đĩa trở lên?

❌ Cùng phân tích với cấu hình 3-disk.

• Không có spare → không thể rebuild nếu 1 disk lỗi mà không thay đĩa.
• Không hiệu quả với dRAID, vốn thiết kế để chạy với nhiều đĩa song song.
• Sẽ mất dung lượng lớn cho parity trong tổng số đĩa.

✅ Cấu hình “tối thiểu thực tế” nên là:

Ví dụ tốt hơn:

draid1:2d:1s:4c

• 2 mảnh dữ liệu
• 1 parity
• 1 virtual spare
• 4 ổ đĩa

Tại sao nên có 1 virtual spare?

• Khi 1 ổ hỏng → rebuild ngay lập tức vào vùng virtual spare
• Không cần thao tác thủ công
• Hệ thống vẫn “healthy” cho đến khi bạn thay đĩa thật

Tóm gọn lại như sau.

ZFS dRAID cần ít nhất 3 ổ để chạy, nhưng cấu hình tối thiểu nên dùng là 4 ổ đĩa trở lên nếu bạn muốn hệ thống an toàn và rebuild tự động.

Đây là 1 ví dụ cấu hình 9 disk.

draid2:6d:1s:9c

Một số ví dụ khác.

• dRAID1 (1 parity): 1d + 1p = 2 disk → Nhưng không thực tế
• Thực tế tối thiểu hợp lý:
  • draid1:2d:0s:3c → 3 disk
  • draid2:4d:0s:6c → 6 disk
  • draid2:6d:1s:9c → 9 disk

→ Tức là bạn phải chỉ rõ đủ số disk tương ứng với số data + parity + spare, nếu không ZFS sẽ từ chối tạo pool.

7. Vậy muốn scale up (thêm ổ) thì làm sao?

ZFS hoạt động theo kiến trúc sau:

Pool = tập hợp các vdev
→ Bạn không mở rộng vdev, bạn thêm vdev mới vào pool.

Ví dụ:

Bạn tạo pool tank từ 1 vdev dRAID:

zpool create tank draid2:8d:2s:12c /dev/sd[a-l]

Sau 1 năm, bạn cần thêm dung lượng → bạn thêm 1 vdev mới:

zpool add tank draid2:8d:2s:12c /dev/sd[m-x]

→ Pool tank giờ có 2 vdev → tăng dung lượng, IOPS tăng theo.

Cân bằng I/O sẽ tự động phân phối giữa các vdev khi ghi dữ liệu mới.

Nhưng lưu ý:

Kết luận.

Mẹo khi thiết kế dRAID:

• Hãy lập kế hoạch trước về số ổ bạn sẽ dùng cho 1 vdev.
• Đặt cấu trúc draidX:Nd:Ns:Nc hợp lý cho số lượng ổ và dự phòng.
• Nếu muốn mở rộng về sau → cứ thêm vdev mới (giống thêm RAID group mới).

8. Kết luận khi nào dùng RAIDZ vs dRAID?

9. Tổng kết

RAIDZ tốt cho đơn giản, dRAID tốt cho mở rộng. DRAID phân phối dữ liệu thông minh hơn, rebuild nhanh hơn và cân bằng toàn hệ thống tốt hơn – đặc biệt trong môi trường có nhiều ổ đĩa.