Sử dụng xiRAID làm tầng OSD backend cho Ceph

1. Tổng quan.

Nếu dùng xiRAID làm tầng OSD backend trong Ceph (thay vì cắm thẳng từng ổ NVMe), thì ta có thể tận dụng tối đa hiệu năng của các ổ NVMe bằng cách gom nhóm (RAID 0 hoặc RAID 10), sau đó expose ra như 1 ổ lớn cho Ceph sử dụng làm OSD.

❓ Tại sao không cắm NVMe thẳng làm OSD luôn?

• Ceph OSD chỉ khai thác tốt nếu có dung lượng ổ lớn + khả năng song song cao.
• Một ổ NVMe đơn → nhanh nhưng không đủ “volume” để Ceph tối ưu luồng I/O.
• Nếu dùng nhiều ổ NVMe riêng biệt làm nhiều OSD:
  • Tốn RAM, CPU (vì mỗi OSD = 1 process nặng)
  • Cực khó quản lý
  • Không tận dụng được RAID 0 hoặc RAID 10 để gộp tốc độ

💡 Giải pháp: Dùng xiRAID để nhóm ổ NVMe → tạo 1 thiết bị RAID tốc độ cao → gán cho Ceph làm OSD

🔧 Sơ đồ mô tả hệ thống (bằng ký tự)

          +----------------------------+
          |        Ceph Cluster        |
          |                            |
          |   +--------------------+   |
          |   |        OSD         |   |
          |   |   (1 disk exposed) |   |
          |   +--------------------+   |
          +-------------|--------------+
                        |
                        v
          +----------------------------+
          |        xiRAID Layer        | ← tạo RAID 0 / RAID 10
          |   (gộp nhiều ổ NVMe lại)   |
          +-------------|--------------+
                        |
        +---------------+---------------+
        |        |              |        |
        v        v              v        v
     +------+  +------+      +------+  +------+
     | NVMe |  | NVMe |  ..  | NVMe |  | NVMe |
     +------+  +------+      +------+  +------+

💥 Lợi ích của mô hình này

📌 Gợi ý cấu hình

• 4 ổ NVMe → dùng xiRAID RAID 10 → tạo 1 disk RAID → gán cho OSD.0
• 8 ổ NVMe → chia làm 2 nhóm RAID 10 → tạo 2 OSD lớn (OSD.0, OSD.1)
• Với 3 node Ceph: cứ mỗi node 2 OSD (RAID 10) là hiệu năng rất mạnh.

Nếu bạn dùng Ceph + NVMe trong môi trường Proxmox, Kubernetes hay OpenStack, đây là giải pháp tối ưu nhất hiện tại về performance vs stability.

2. Vấn đề PGs khi áp dụng giải pháp này.

Khi dùng xiRAID để gom nhiều ổ NVMe lại thành 1 OSD → số lượng OSD ít lại → số lượng PG cũng sẽ ít hơn, vì:

PGs (Placement Groups) trong Ceph được phân bổ trên OSD, nên ít OSD → ít nơi để dàn PGs ra.

🧠 Vậy điều này có làm giảm hiệu năng không?

👉 Câu trả lời là: KHÔNG hẳn. Và trong nhiều trường hợp vẫn rất khả thi cho High Performance Storage.

🔍 Chi tiết lý do:

Mỗi OSD xiRAID có sức mạnh “to hơn” rất nhiều

Khi bạn dùng RAID 10 (ví dụ: 4 ổ NVMe) → hiệu năng tổng hợp IOPS, throughput và resiliency vượt trội hơn một OSD cắm 1 ổ đơn lẻ:

→ Một OSD xiRAID có thể gánh khối lượng công việc của 3–4 OSD thường mà vẫn ổn.

Số PG thấp nhưng vẫn được phân bố hợp lý

• Theo khuyến nghị của Ceph, PG count chỉ cần đạt từ ~50-100 PGs/OSD là đủ tốt.
• Quan trọng là dàn trải PGs đều giữa các OSD, không phải cứ nhiều PG là tốt.
• Ví dụ: 3 node, mỗi node có 2 OSD (RAID 10), tổng 6 OSD:
  • Với 1024 PGs cho một pool → trung bình mỗi OSD chỉ chứa ~170 PGs → vẫn hiệu quả.

Ít OSD = ít CPU + RAM hơn, dễ tuning hơn

• Mỗi OSD daemon (process) tốn khoảng ~1-2GB RAM và một ít CPU.
• Nếu bạn có 24 ổ NVMe mà chia từng ổ làm OSD:
  • Sẽ có 24 OSD → tiêu tốn ~30–50GB RAM + nhiều CPU xử lý.
• Nếu bạn gộp thành 6 OSD (RAID 10):
  • Chỉ cần ~12GB RAM, rất dễ tối ưu và tuning.

Ceph mạnh hơn với ít OSD nhưng chất lượng cao

• Ceph từ phiên bản Nautilus trở đi có rất nhiều cải tiến về PG autoscaler → giúp tự cân đối số lượng PG theo OSD.
• Chất lượng OSD (hiệu năng, ổn định) còn quan trọng hơn số lượng.

✅ Tổng kết

3. Ví dụ này mình sẽ triển khai cho một hạ tầng 30 node, trong đó 25 là node lưu trữ (storage) mỗi node có 12 ổ NVMe 14TB, đây là một cluster Ceph quy mô lớn và rất lý tưởng cho các workload AI/ML.

🧠 Tóm tắt thông tin:

• Tổng cộng: 30 nodes
  • 25 storage nodes: mỗi node 12 ổ NVMe 14TB
  • 5 controller nodes: chỉ chứa disk OS, không dùng làm OSD
• Tổng số ổ lưu trữ: 25 x 12 = 300 NVMe
• Sử dụng 1 pool chung cho các dự án AI

✅ Gợi ý kiến trúc Ceph với xiRAID (RAID 10)

Chúng ta sẽ nhóm 12 NVMe trên mỗi node thành 3 nhóm RAID 10, mỗi nhóm gồm 4 ổ → tạo ra 3 xiRAID per node → tương đương 3 OSD/node.

🔢 Tổng số OSD toàn cluster:

25 nodes x 3 OSD/node = 75 OSD

🔧 Ceph cấu hình sơ bộ

📊 Tổng dung lượng usable ước lượng:

300 ổ x 14TB = 4200TB raw
→ RAID10: usable ~50% → còn ~2100TB usable cho Ceph
→ Ceph replica 3 → usable ~1/3 → 700TB usable

Tuy nhiên, khi dùng RAID10 rồi mới vào Ceph thì replica=2 cũng có thể được, giúp tăng usable lên khoảng ~1PB (replica 2 vẫn an toàn vì RAID10 bên dưới đã redundancy rồi).

📘 ASCII sơ đồ cluster Ceph Storage dùng xiRAID

                           ╔══════════════════════════════╗
                           ║        5x Controller Nodes   ║
                           ║  - Monitor / MGR / MDS / RGW ║
                           ╚══════════════════════════════╝

                                  ⇵ Network: 25/40Gbps ⇵

┌─────────────────────────────────────────────────────────────────────┐
│                         25x Storage Nodes (OSD)                    │
├─────────────────────────────────────────────────────────────────────┤
│ Node-01                                                            │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐                 │
│  │ RAID10 (4x) │  │ RAID10 (4x) │  │ RAID10 (4x) │  => 3 OSD/node  │
│  └─────────────┘  └─────────────┘  └─────────────┘                 │
├─────────────────────────────────────────────────────────────────────┤
│ Node-02                                                            │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐                 │
│  │ RAID10 (4x) │  │ RAID10 (4x) │  │ RAID10 (4x) │                 │
│  └─────────────┘  └─────────────┘  └─────────────┘                 │
├─────────────────────────────────────────────────────────────────────┤
│ ... (Tương tự đến Node-25)                                         │
└─────────────────────────────────────────────────────────────────────┘

Tổng: 25 nodes x 3 OSD = 75 OSD → chạy 1 Ceph Pool dùng cho AI

🚀 Ưu điểm thiết kế này cho AI workloads:

🔄 Tuỳ chọn mở rộng:

• Nếu cần tăng IOPS, bạn có thể chia 12 NVMe thành 6 RAID1 (2 ổ/RAID) → được 6 OSD/node → 150 OSD toàn cluster
  • Phù hợp khi workload có nhiều random IO nhỏ (training + inference song song)
  • Giảm usable capacity một chút nhưng tăng concurrency

4. Gợi ý CRUSH Rule và Failure Domain.

Trong Ceph, CRUSH rule được sử dụng để xác định cách mà Ceph phân phối dữ liệu trên các OSD và failure domain được sử dụng để chỉ ra cách Ceph phân chia các OSD để đảm bảo tính High Availability khi có sự cố.

4.1. CRUSH Rule

• Failure Domain:
  • Trong hạ tầng của bạn, có thể chia thành các failure domain như:
    • Host: Nếu một node bị lỗi, tất cả OSD trên node đó sẽ mất.
    • Rack: Nếu bạn có rack khác nhau, việc phân tán OSD giữa các rack sẽ giúp tránh trường hợp toàn bộ rack bị lỗi.
    • Datacenter: Nếu bạn phân phối các node vào nhiều datacenter, failure domain có thể là datacenter.
• CRUSH Rule:

Để tối ưu, bạn cần tạo các CRUSH rules cho mỗi failure domain, ví dụ:

# Rule để phân phối OSD trong từng host (failure domain = host)
rule ai_host_rule {
    rule_id 1
    id 1
    min_size 1
    step take host
    step chooseleaf firstn 0 type osd
    step emit
}

# Rule cho rack
rule ai_rack_rule {
    rule_id 2
    id 2
    min_size 2
    step take rack
    step chooseleaf firstn 0 type osd
    step emit
}

# Rule cho datacenter
rule ai_dc_rule {
    rule_id 3
    id 3
    min_size 2
    step take datacenter
    step chooseleaf firstn 0 type osd
    step emit
}

Sử dụng ai_host_rule cho các ứng dụng có yêu cầu cao về độ trễ thấp và ai_rack_rule hoặc ai_dc_rule cho việc phân phối dữ liệu giữa các địa điểm vật lý để đảm bảo tính toàn vẹn khi có sự cố.

4.2. Failure Domain

• Host: Mỗi node Ceph sẽ đóng vai trò là failure domain riêng biệt. Việc phân phối các OSD trên các node khác nhau sẽ bảo vệ bạn khỏi việc mất dữ liệu khi một node bị lỗi.
• Rack: Nếu bạn có nhiều rack, thì việc sử dụng rack làm failure domain sẽ giúp tránh trường hợp cả rack bị lỗi và làm ảnh hưởng đến tất cả OSD trong rack đó.
• Datacenter: Dành cho những hệ thống lớn, bạn sẽ chia các OSD vào các datacenter khác nhau.

4.3. PG Calculator.

Để tính toán số lượng Placement Groups (PG) phù hợp, chúng ta cần dựa vào số lượng OSD và số lượng replicas. Công thức cơ bản để tính số PG trong Ceph là:

PGs = (OSDs x 100) / (replica size)

Trong trường hợp cụ thể của bạn:

• OSD = 75 (25 nodes x 3 OSD/node)
• Replica size = 3 (do bạn muốn có redundancy cao)
• PG per OSD = 100 (mặc định trong Ceph)

Áp dụng công thức:

PGs = (75 x 100) / 3 = 2500 PGs

Điều chỉnh số lượng PGs

• Nếu muốn tối ưu hiệu suất: Sử dụng PGs là bội số của 2^n (8, 16, 32, 64…). Ví dụ, với 2500 PGs, bạn có thể điều chỉnh xuống 2048 hoặc 4096 PGs cho sự phân bổ dữ liệu tốt hơn.

Cách tính PGs cho số lượng pool:

• Nếu bạn có nhiều pool, hãy tính toán PG cho mỗi pool dựa trên công thức trên.

5. Config Ceph Pool Tối Ưu Cho AI (RBD hay CephFS)

5.1. Ceph Block Devices (RBD)

RBD (RADOS Block Device) là lựa chọn tối ưu nếu bạn cần lưu trữ các volumes block cho các máy ảo hoặc container và rất hiệu quả trong việc sử dụng cho AI training với các dataset lớn. Cấu hình RBD pool:

• Dung lượng của mỗi OSD phải đủ lớn để chứa các block volume.

• Replication size = 3, min_size = 2.

ceph osd pool create rbd_pool 128 128
ceph osd pool set rbd_pool size 3
ceph osd pool set rbd_pool min_size 2
ceph osd pool set rbd_pool pg_num 2048
ceph osd pool set rbd_pool pgp_num 2048

Ưu điểm:

Cung cấp khả năng mở rộng IOPS cực cao cho các volume cần read/write nhanh.

Dễ dàng tạo các snapshot, clones cho các model/training set.

5.2 Ceph Filesystem (CephFS)

CephFS là lựa chọn tuyệt vời nếu bạn cần lưu trữ file hoặc dữ liệu với yêu cầu quản lý và truy cập file lớn, như trong các hệ thống lưu trữ dataset AI có thể chia sẻ cho nhiều node hoặc ứng dụng khác.

Cấu hình CephFS pool:

ceph osd pool create rbd_pool 128 128
ceph osd pool set rbd_pool size 3
ceph osd pool set rbd_pool min_size 2
ceph osd pool set rbd_pool pg_num 2048
ceph osd pool set rbd_pool pgp_num 2048

Ưu điểm:

Thích hợp với các workload cần file sharing và random access vào các dataset.

Phù hợp nếu bạn cần lưu trữ dataset phân mảnh nhỏ và sử dụng trong các thuật toán inference.

Như vậy:

• CRUSH Rules và Failure Domain: Tối ưu cho AI yêu cầu phân phối giữa các node, rack hoặc datacenter, đảm bảo khả năng High Availability và giảm độ trễ.
• PG Calculator: Với 75 OSD, bạn cần khoảng 2500 PG để đảm bảo phân phối tốt dữ liệu. Hãy điều chỉnh PGs sao cho phù hợp với bội số của 2^n (2048, 4096).
• Config Ceph Pool:
  • RBD nếu bạn cần volume block nhanh và hiệu quả.
  • CephFS nếu cần lưu trữ dataset dưới dạng file và chia sẻ chúng giữa các node.

6. Tổng kết.

Nếu bạn dùng VM Hosting, Video Streaming, NVMe Ceph RBD backend, hoặc AI/ML workloads thì mô hình ít OSD chất lượng cao này đang được rất nhiều công ty lớn áp dụng (Meta, Dropbox, OVHcloud…).