[Blog] Xây dựng hệ thống lưu trữ Ceph 20PiB đạt tốc độ 100GB/s

1. Tổng quan

Trong bài viết này, mình muốn chia sẻ lại kinh nghiệm triển khai một cluster Ceph có dung lượng 20PiB và tốc độ truyền tải đạt gần 100GB/s – một trong những cluster lưu trữ mạnh mẽ nhất mà mình từng xây dựng.

Hệ thống này được thiết kế để phục vụ hàng trăm compute node với yêu cầu cao về throughput, dung lượng lưu trữ lớn, tích hợp với Kubernetes và OpenStack.

2. Ceph là gì?

Ceph là hệ thống lưu trữ phân tán mã nguồn mở, phổ biến trong các private cloud, hỗ trợ ba loại lưu trữ:

• CephFS (filesystem): cho phép mount trực tiếp trên các server.
• RBD (RADOS Block Device): thay thế cho các giải pháp SAN.
• RGW (RADOS Gateway): hỗ trợ S3 và Swift API.

Ceph hỗ trợ hai loại chính để đảm bảo tính sẵn sàng:

• Replication: Dữ liệu được lưu trữ theo dạng sao chép (mặc định là 3 bản).
• Erasure Coding: Mã hóa dữ liệu thành các phần nhỏ (chunk) + phần dự phòng (parity) giúp tiết kiệm dung lượng.

3. Yêu cầu hệ thống

• Tốc độ xử lý dữ liệu tổng thể (throughput): ~100GB/s (tương đương 5PB/ngày).
• Dung lượng lưu trữ thực: 20PiB.
• Có thể mount như một file system.
• Tích hợp với Kubernetes (dùng volume).
• Khả năng chịu lỗi cao (nhiều ổ cứng/host bị lỗi cùng lúc).
• Chi phí tối ưu.

4. Kiến trúc tổng quan Ceph cluster

+----------------------------------------------------+
|                  Spine Switches (2)                |
+---------------+--------------------+---------------+
                |                    |
       +--------+--------+  +--------+--------+
       |  Leaf Switch 1  |  |  Leaf Switch 2  |
       +--------+--------+  +--------+--------+
                |                    |
    +-----------+--------------------+--------+
    |         OSD Servers (40 nodes)          |
    +-----------+--------------------+--------+
                |                    |
        +-------+--------------------+--------+
        |  Disk Enclosures (40 enclosures)    |
        +-------------------------------------+

5. Chi tiết phần cứng

• Racks: 10
  • OSD Servers: 40 nodes
  • Disk Enclosures: 40 enclosures
• MON Servers: 5 nodes
• Switch: 4 Leaf + 2 Spine (Mellanox SN4600C)
• Server: Dell R740xd
  • Ổ cứng lưu trữ: 14TB Ultrastar DC HC530 (WD), tốc độ ~250MB/s
  • Ổ cứng metadata: Dell 1.6TB NVMe
• Network:
  • Card mạng Mellanox ConnectX-6 2x100GbE/IB
  • Switch SN4600C (64-port, Spectrum-3)
  • Cáp mini-SAS x2/enclosure
  • PCIe 3.0 x8 cho HBA → băng thông ~15GB/s/server
• Disk:
  • Tất cả 120 HDD đều trên 2 thiết bị DAS (Disk Enclosures). Không có HDD trên server (node).
  • Có 4 ổ NVMe SSD trong server dùng cho: Metadata pool, DB/WAL device trong BlueStore (giúp tăng tốc truy cập).

• RAM/OSD: Mỗi node có 124 OSD:
  • 120 OSD từ HDD (qua 2 enclosures DAS).
  • 4 OSD từ NVMe SSD (metadata or DB/WAL).

Như vậy 124 OSD/node, nên trang bị ít nhất 256GB RAM cho node đó, và lý tưởng là 384–512GB để có hiệu suất ổn định.

Sau này khi lên cụm, bạn hãy benchmard hoặc khi chạy thực tế bạn có thể xem sử dụng RAM thực tế per OSD bằng lệnh dưới.

ceph daemon osd.X perf dump | jq '.bluestore.cache'
# hoặc dùng `dump_mempools`

Bạn cũng có thể kiểm tra memory limit hiện tại:

ceph config get osd.X osd_memory_target

6. Tối ưu hiệu suất

6.1. CPU

Ban đầu, mỗi máy chủ được kết nối trực tiếp với 2 thiết bị lưu trữ DAS (Disk Enclosures), mỗi enclosure chứa 60 ổ cứng HDD enterprise.

Server sử dụng CPU Intel Xeon Gold 6244, có:

• 8 cores, 16 threads,
• Tổng cộng 16 vCPU.

Tổng cộng mỗi server phải chạy 124 OSD daemon:

• 120 OSD cho HDD (2 enclosures × 60 ổ đĩa),
• 4 OSD cho SSD NVMe (metadata).

Vấn đề phát sinh:

Ngay cả khi chưa có truy cập từ phía client, CPU đã sử dụng > 60%

=> Nghĩa là không còn nhiều tài nguyên để xử lý thêm.

Giải pháp:

Chuyển sang dùng Intel Xeon Gold 6258R, mỗi con có: 28 cores, 56 threads.

Là bản rebrand giá rẻ của dòng cao cấp Xeon Platinum 8280 (giá cũ $10.000, giờ chỉ ~$3.950).

CPU này có PassMark ~63.059 điểm → đủ sức xử lý hơn 60 OSD daemon/node.

6.2. Tối ưu IO disk

Các ổ cứng WD Ultrastar 14TB 7200rpm:

• Hỗ trợ đọc/ghi tuần tự (sequential) lên tới 250MB/s mỗi ổ.
• Mỗi disk enclosure có 60 ổ => Tốc độ tổng: 250MB/s × 60 = 15.000MB/s = 15GB/s

Đây là giới hạn lý thuyết về throughput của cả enclosure.

6.3. PCIe 3.0 x8 (Kết nối từ HBA vào CPU)

Các HBA (Host Bus Adapter) gắn vào khe PCIe 3.0 x8, mỗi khe có:

• Băng thông tối đa 7.880MB/s (gần 8GB/s).
• Mỗi server có 2 card HBA => Tổng throughput: 7.880MB/s × 2 = ~15.760MB/s = ~15GB/s

Phù hợp với throughput của ổ cứng như tính ở trên => không bị nghẽn ở mức PCIe.

6.4. mini-SAS & Multipath (Kết nối tới enclosure)

Mỗi mini-SAS cable có:

• 4 kênh truyền (lanes),
• Mỗi kênh: 12 Gbps => Tổng: 48Gbps = 6GB/s mỗi cáp.

Mỗi enclosure được kết nối:

• 2 cáp mini-SAS từ 2 HBA card trên mỗi server.
• Tổng throughput qua 2 cáp mini-SAS: 6GB/s × 2 = 12GB/s

Với multipath, mỗi ổ đĩa đi qua 2 đường khác nhau => tăng độ sẵn sàng và đảm bảo redundancy.

Như vậy

• mini-SAS là node thắt nhẹ nhất (12GB/s).
• Tuy nhiên, tổng thể vẫn tương thích tốt với throughput từ ổ cứng và network (100GbE).

Luồng dữ liệu trong một server Ceph OSD sẽ như sau: ổ đĩa → HBA → PCIe → CPU → card mạng → mạng.

                      [Ổ đĩa HDD (x60/enclosure)]
                                   │
                        ╭──────────┴──────────╮
                        │    mini-SAS Cable   │  (2 sợi cáp/Enclosure)
                        ╰──────────┬──────────╯
                                   │
                           [HBA Adapter x2]
                                   │
                      ╭────────────┴────────────╮
                      │    PCIe 3.0 x8 Slots    │  (~7.88 GB/s mỗi khe)
                      ╰────────────┬────────────╯
                                   │
                          [CPU Intel Xeon 6258R]
                                   │
                     ╭─────────────┴─────────────╮
                     │         RAM/Cache         │
                     ╰─────────────┬─────────────╯
                                   │
                     ╭─────────────┴─────────────╮
                     │   Mellanox NIC (2x100GbE) │
                     ╰─────────────┬─────────────╯
                                   │
                          [Switch Leaf → Spine]
                                   │
                  [Network cluster Ceph toàn hệ thống]

Luồng hoạt động như sau:

• Dữ liệu được ghi hoặc đọc từ 60 ổ đĩa trong enclosure.
• Dữ liệu truyền qua 2 cáp mini-SAS, mỗi cáp cung cấp ~6GB/s => tổng ~12GB/s.
• Cáp kết nối đến 2 HBA adapter, gắn vào 2 khe PCIe 3.0 x8, cung cấp băng thông tổng ~15GB/s.
• CPU xử lý yêu cầu của OSD daemon, quản lý IO, erasure coding và trao đổi metadata.
• Card mạng Mellanox ConnectX-6 2x100GbE truyền dữ liệu ra ngoài qua bonding (active-active).
• Dữ liệu đi qua switch leaf sang spine, rồi tới các node khác (client, MON, MDS, v.v.).

6.5. Network

Trong một cluster Ceph lớn, nơi mà băng thông mạng lên tới hàng trăm gigabit mỗi giây, việc cấu hình network đúng cách là yếu tố then chốt để đạt hiệu suất cao và ổn định. Phần này sẽ giải thích các tinh chỉnh như MTU (Jumbo Frames), bonding, VLAN và tối ưu về IRQ/NUMA.

6.5.1 Jumbo Frames

Mặc định:

• MTU (Maximum Transmission Unit) mặc định của Ethernet là 1500 bytes.
• Nếu phải truyền lượng dữ liệu lớn, gói nhỏ khiến CPU load tăng do cần xử lý nhiều gói hơn → giảm hiệu suất.

Tinh chỉnh:

• Đặt MTU = 9000 trên các server (giá trị “jumbo frame”) → tăng lượng dữ liệu truyền trong mỗi gói.
• Trên các thiết bị Mellanox, MTU có thể lên tới 9144 → tối đa hóa hiệu suất phần cứng.

6.5.2. Cấu hình network cho MON node và OSD node

MON Node (Monitor Server):

• Chỉ sử dụng mạng public (quản lý + giao tiếp client).
• Sử dụng bonding 2 card mạng vật lý theo chuẩn 802.3ad (LACP – Link Aggregation Control Protocol).
• transmit-hash-policy: layer3+4 => cân bằng tải dựa trên IP + cổng (IP+Port).

Ví dụ cấu hình netplan:

# /etc/netplan/01-netcfg.yaml on MON nodes:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: false
      dhcp6: false
      addresses: [ 10.101.77.41/22 ]
      routes:
      - to: 10.100.148.0/22
        via: 10.101.79.254
    ens1:
      match:
        macaddress: b8:59:9f:d9:c4:e4
      set-name: ens1
    ens8:
      match:
        macaddress: b8:59:9f:d9:c6:30
      set-name: ens8
  bonds:
    bond1:
      mtu: 9000
      dhcp4: false
      dhcp6: false
      interfaces: [ ens1, ens8 ]
      addresses: [ 10.101.69.41/22]
      nameservers:
        addresses: [10.100.143.21, 10.100.143.22]
      gateway4: 10.101.71.254
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

OSD Node (Data Node):

• Dùng 2 mạng song song:
  • Public: cho MON/client.
  • Cluster backend: giữa các OSD với nhau => cực kỳ quan trọng với Ceph.
• Do đó, ngoài cấu hình bond như trên, OSD còn có VLAN riêng biệt cho backend:

Ví dụ cấu hình netplan:

# /etc/netplan/01-netcfg.yaml on OSD nodes:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: false
      dhcp6: false
      addresses: [ 10.101.77.1/22 ]
      routes:
      - to: 10.100.148.0/22
        via: 10.101.79.254
    ens1:
      match:
        macaddress: b8:59:9f:d9:c6:18
      set-name: ens1
    ens8:
      match:
        macaddress: b8:59:9f:d9:c6:1c
      set-name: ens8
  bonds:
    bond1:
      mtu: 9000
      dhcp4: false
      dhcp6: false
      interfaces: [ ens1, ens8 ]
      addresses: [ 10.101.69.1/22]
      nameservers:
        addresses: [10.100.143.21, 10.100.143.22]
      gateway4: 10.101.71.254
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4
  vlans:
    bond1.2072:
      mtu: 9000
      id: 2072
      link: bond1
      addresses: [ 10.101.73.1/22 ]

=> Tách VLAN giúp phân luồng traffic giữa nội bộ Ceph và mạng ngoài, tránh nhiễu.

6.5.3. Tối ưu NUMA và IRQ affinity cho Mellanox NIC

Vấn đề:

• Mỗi CPU socket có RAM riêng và khe PCIe riêng.
• Card mạng Mellanox gắn vào một khe PCIe (gắn trên socket A chẳng hạn).
• Ubuntu mặc định dùng irqbalance => tự động rải ngắt (IRQ) lên toàn bộ CPU.

Điều này khiến network IRQ có thể bị xử lý trên socket B, làm dữ liệu phải đi qua QPI bus giữa socket A và B, gây độ trễ và tiêu tốn băng thông liên CPU (~65GB/s).

Giải pháp:

Vô hiệu hóa irqbalance:

systemctl disable irqbalance

Kích hoạt script Mellanox để gán IRQ theo NUMA node chứa card mạng:

systemctl enable set_irq_affinity_bynode

Giúp đảm bảo ngắt mạng được xử lý ngay trên CPU gần card mạng, giảm độ trễ và tăng hiệu suất.

6.6. Tối ưu TCP/IP Stack

Mục tiêu:

• Tăng hiệu suất network.
• Tránh nghẽn socket TCP.
• Giảm rủi ro ngắt kết nối do quá tải kết nối.

Socket buffer tuning (rmem/wmem)

Trong hệ thống network tốc độ cao 100GbE, mặc định của Linux về buffer TCP là quá nhỏ.

Tác dụng:

• Tăng khả năng nhận/gửi dữ liệu qua TCP socket,
• Giảm packet drop, tăng throughput.

Sửa file /etc/sysctl.conf:

net.core.rmem_max = 4194304        # 4MB
net.core.wmem_max = 4194304
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 65536 4194304

6.7. Tối ưu nf_conntrack

NF_conntrack là gì?

nf_conntrack là bảng trạng thái kết nối trong Netfilter, theo dõi kết nối TCP/UDP.

Tại sao phải chỉnh nó?

• Mặc định chỉ vài trăm ngàn kết nối => dễ tràn khi có hàng ngàn OSD và client cùng hoạt động.
• Nếu đầy dẫn đến mất kết nối, log báo lỗi nf_conntrack: table full.

Tác dụng:

• Tối ưu nhiều socket kết nối đồng thời.
• Tăng khả năng xử lý IO cường độ cao.

net.netfilter.nf_conntrack_max = 1524288

Các tối ưu khác trong /etc/sysctl.conf

Các tham số khác cải thiện hệ thống cho môi trường Ceph lớn:

Đây là config /etc/sysctl.conf của mình, hãy tham khảo nhé.

# /etc/sysctl.conf
kernel.pid_max = 4194303
kernel.threads-max=2097152
vm.max_map_count=524288

vm.min_free_kbytes=2097152
vm.vfs_cache_pressure=10
vm.zone_reclaim_mode=0
vm.dirty_ratio=80
vm.dirty_background_ratio=3

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=1
net.core.netdev_max_backlog=250000
net.ipv4.tcp_max_syn_backlog=100000
net.ipv4.tcp_max_tw_buckets=2000000
net.ipv4.tcp_tw_reuse=1
net.core.rmem_max=4194304
net.core.wmem_max=4194304
net.core.rmem_default=4194304
net.core.wmem_default=4194304
net.core.optmem_max=4194304
net.ipv4.tcp_rmem=4096 87380 4194304
net.ipv4.tcp_wmem=4096 65536 4194304
net.ipv4.tcp_low_latency=1
net.ipv4.tcp_adv_win_scale=1
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_syncookies=0
net.core.somaxconn=5000
net.ipv4.tcp_ecn=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_fin_timeout=10

net.netfilter.nf_conntrack_max=1524288
net.nf_conntrack_max=1524288

6.8. Tối ưu RX/TX Buffers NIC (Layer-2)

• RX/TX buffer là bộ nhớ cache của phần cứng ở trong card mạng.
• Nếu quá nhỏ => mất gói => giảm tốc độ.

Khuyến nghị:

ethtool -G ethX rx 8192 tx 8192

6.9. Multipath (kết nối ổ đĩa đa đường)

• Trong hệ thống dùng disk enclosure (JBOD), mỗi ổ đĩa có thể thấy qua nhiều đường (multi-path).
• Mặc định Multipath ở chế độ manual failback, không tận dụng đồng thời.

Dưới đây là cấu hình nên sử dụng:

defaults {
  path_selector "service-time 0"
  failback immediate
  path_checker tur
  rr_weight uniform
}

• path_selector = service-time 0: Cân bằng hiệu quả theo thời gian đáp ứng I/O → active-active.
• failback = immediate: Nếu path chính hồi phục, dùng lại ngay.
• Tăng throughput lên 12GB/s thay vì 6GB/s nếu chỉ active-standby.

6.10. Lọc LVM để tránh lỗi mount sai thiết bị

Có thể xảy ra xung đột nếu LVM nhận diện thiết bị đơn ví dụ /dev/sdaa thay vì thiết bị qua multipath là /dev/mapper/mpathaa.

Giải pháp: Sửa file /etc/lvm/lvm.conf

filter = [ "a|/dev/sd.*[1-9]$|", "a|/dev/mapper/mpath*|", "a|/dev/nvme[0-9]n*|", "r|.*|" ]

Tác dụng của config trên sẽ làm cho LVM chỉ làm việc với thiết bị qua multipath hoặc NVMe.

7. Swapfile lớn để chống OOM (Out-of-Memory)

• Mặc định Ubuntu chỉ tạo swap 2GB.
• Với Ceph, OSD hoặc MDS có thể ngốn nhiều RAM, khi RAM đầy sẽ bị OOM killer giết process → mất dữ liệu.

Giải pháp:

Swap = 200GB

8. Crontab theo dõi sự cố (Alerting scripts)

Thiết lập các script chạy định kỳ 1 phút:

=> Tự động cảnh báo (ví dụ qua Slack), giúp phản ứng sớm với sự cố.

9. Cấu hình Erasure Coding (EC)

Tối ưu profile Ceph:

• Phiên bản: Ceph Reef (v18.2.7)
• Erasure coding: 10+4 (host failure domain) → an toàn khi mất 1 rack (vì có 4 host/rack).
• MDS: Dùng 1 active MDS do lỗi khi dùng đa MDS với rsync.
• Memory target: Giữ mặc định 4MB.
• Scrubbing: Không thay đổi.

Sử dụng cấu hình Erasure Coding kiểu 10+4:

• 10 phần dữ liệu (data chunks),
• 4 phần kiểm lỗi (parity chunks),
• Tổng cộng: 14 OSD chứa mỗi object.

Cấu trúc tương tự như Facebook sử dụng trong hạ tầng lưu trữ.

Sử dụng crush failure domain = host:

Tức là mỗi chunk nằm trên một host khác nhau, để tăng khả năng chống mất dữ liệu khi một máy chủ bị lỗi.

Không dùng 7+3 với rack domain.

Ban đầu mình muốn dùng 7+3 (7 data + 3 parity), đặt theo crush failure domain = rack (tức mỗi chunk nằm ở rack khác nhau).

Nhưng gặp lỗi xuất hiện 1 OSD bị “stale” (mất kết nối kéo dài, Ceph không đồng bộ được).

Điều này khiến mất cân bằng hoặc mất dữ liệu, nên nhóm bỏ qua phương án 7+3.

Tính toán xác suất lỗi ổ cứng sử dụng phân phối Poisson – thường được dùng để ước lượng xác suất xảy ra của các sự kiện hiếm (như lỗi ổ đĩa) trong một khoảng thời gian nhất định.

Giả định lỗi ổ cứng là độc lập, ta tính được xác suất lỗi nhiều ổ cùng lúc bằng phân phối Poisson.

Sử dụng công thức phân phối Poisson tính xác suất xảy ra lỗi:

Tính được:

Điều này giúp mình tự tin chọn EC 10+4, vì có thể chịu lỗi tới 4 ổ đĩa / 4 node mà không mất dữ liệu.

Metadata pool được cấu hình replication 5x

Không dùng erasure coding cho metadata vì:

• Metadata cần phản hồi nhanh, dung lượng nhỏ.
• Dùng replication (5 bản sao) sẽ an toàn và hiệu quả hơn.

OSD memory target = 4MB (mặc định)

• Không thay đổi tham số osd_memory_target, để ở mặc định: 4MB/OSD
• Tham số này dùng để điều chỉnh mức sử dụng RAM cho OSD trước khi dùng tới BlueStore cache trimming.

10. Ubuntu thay vì CentOS

• IBM tuyên bố dừng CentOS 8 → mình chuyển sang Ubuntu 22.04.
• Cấu hình LVM, multipath khác nhẹ nhưng hoạt động ổn định.

11. Một số lưu ý

Việc nghẽn cổ chai thực sự không phải CPU, PCIe hay network – mà là cách Ceph ghi dữ liệu.

Tốc độ mạng thì sao?

• Mỗi server có 2 card mạng 100Gbps, tổng lý thuyết là 200Gbps, tương đương 25GB/s.
• Tuy nhiên, vì chia sẻ giữa 2 mạng (public + cluster), thực tế xử lý được ~12GB/s cho lưu lượng Ceph.

=> Mạng KHÔNG phải là giới hạn.

Thế còn tốc độ đọc/ghi ổ cứng thì sao?

• Ổ cứng cơ HDD đọc/ghi tuần tự (sequential) rất nhanh, đạt ~250MB/s mỗi ổ.
• Nhưng Ceph không ghi theo kiểu tuần tự — đây là điểm mấu chốt.

Ceph và cách ghi dữ liệu:

Mặc định trong Ceph:

• Dữ liệu người dùng được chia thành object – mặc định mỗi object là 4MB.
• Nếu bạn dùng erasure coding kiểu 10+4, Ceph sẽ:
  • Chia 4MB thành 10 phần data (400KB mỗi phần),
  • Thêm 4 phần parity,
  • Tổng cộng ghi 14 phần (400KB/OSD) → trên 14 OSD khác nhau.

Vấn đề:

• 400KB là kích thước rất nhỏ đối với ổ HDD cơ học.
• Ổ cứng HDD có thời gian seek trung bình ~4ms (để đầu đọc đến đúng vị trí trên đĩa).
• Khi ghi từng khối 400KB ngẫu nhiên, tốc độ hiệu quả giảm mạnh.

Nếu mỗi lần seek + ghi mất 4ms:
=> 1 giây ghi được 250 lần → 250 × 400KB = 100MB/s
=> Thấp hơn nhiều so với 250MB/s nếu ghi tuần tự.

Benchmark ổ cứng bằng iostat

• Lệnh iostat -xk 1 cho thấy cột cuối (%util) luôn gần 100%.
• Điều này nghĩa là HDD luôn bận, chờ seek + ghi → I/O bị nghẽn tại tầng đĩa.

Giải pháp:

• Tăng kích thước objecttừ từ 4MB → 16MB.
• Khi đó:
  • Mỗi chunk của 10+4 erasure code sẽ là 1.6MB thay vì 400KB,
  • Ít seek hơn, hiệu suất mỗi lần ghi cao hơn.

Kết quả: Throughput tăng ~1.5 lần.

Bài học rút ra

Trong hệ thống lưu trữ dùng ổ HDD + erasure coding, yếu tố quan trọng nhất ảnh hưởng đến hiệu suất không phải là tốc độ lý thuyết của thiết bị, mà là “pattern ghi” (I/O pattern).

12. So sánh Replication vs Erasure Coding

13. Ưu điểm và nhược điểm của hệ thống

Ưu điểm

• Dung lượng lưu trữ lớn (20PiB)
• Throughput cực cao (~100GB/s)
• Tích hợp sâu với Kubernetes
• Kiến trúc mạng & lưu trữ tối ưu cho phân tán
• Fault-tolerant tới cấp rack
• Tối ưu CPU, IO và network stack triệt để

Nhược điểm

• Cấu hình ban đầu phức tạp.
• Erasure coding gây giảm hiệu suất ghi random.
• Đòi hỏi phần cứng cao cấp (CPU, NIC, SSD…)
• Cần chỉnh nhiều config kernel, sysctl, network…
• Một số bug tồn tại trong phiên bản Ceph mới (đa MDS)

14. Lời khuyên khi triển khai hệ thống Ceph lớn

• Tính toán kỹ object size và chunk size phù hợp với workload.
• Đầu tư phần cứng cân bằng: CPU mạnh, RAM đủ, NIC nhanh.
• Sử dụng Jumbo Frames nếu switch & card hỗ trợ.
• Tối ưu IRQ/Numa để tránh tắc nghẽn PCIe ↔ CPU.
• Triển khai monitoring & alerting từ đầu.
• Test từng thành phần (CPU load, disk IO, netperf) trước khi production.

15. Kết luận

Ceph là một lựa chọn mạnh mẽ cho các hệ thống lưu trữ phân tán với nhu cầu lớn về throughput và dung lượng. Tuy nhiên, để đạt hiệu suất tối đa như ví dụ 20PiB/100GB/s này, cần đầu tư rất nhiều vào phần cứng, kiến trúc mạng và tối ưu hệ thống ở mọi cấp độ.

Bài học quan trọng nhất là: hiểu rõ workload của mình trước khi thiết kế hệ thống và đừng ngại đầu tư thời gian vào việc trải nghiệm ở môi trường lab.

Hy vọng bài viết này sẽ hữu ích cho các bạn đang tìm hiểu hoặc chuẩn bị triển khai cluster Ceph ở quy mô lớn.

Trích: Hà Hoàng Đăng – System Administrator tại Công Ty Cổ Phần Mắt Bão