Ceph: Hành trình hướng tới 1 TiB/s

Ceph: Hành trình tới 1TiB/s

• Bài viết ghi lại hành trình cải thiện hiệu năng của cụm Ceph, kể câu chuyện đạt được tốc độ xử lý dữ liệu 1TiB/s sau một quá trình gỡ lỗi kéo dài và tối ưu hóa hiệu năng.
• Chia sẻ nhiều vấn đề kỹ thuật khác nhau và cách giải quyết chúng trong quá trình công ty Clyso hỗ trợ xây dựng một cụm Ceph 10 petabyte dựa trên NVMe.
• Mạng của khách hàng rất nhanh, thuộc hàng cấu hình Ethernet nhanh nhất.

Lời cảm ơn

• Bày tỏ lời cảm ơn tới khách hàng của Clyso; nhờ sự hợp tác của họ mà có thể chia sẻ trải nghiệm này với cộng đồng Ceph.
• Cũng cảm ơn IBM/Red Hat và Samsung vì đã cung cấp phần cứng được dùng trong các bài kiểm thử so sánh.
• Gửi lời cảm ơn tới các cộng tác viên Ceph vì những nỗ lực nhằm biến Ceph thành một phần mềm tuyệt vời.

Cấu hình cụm

• Khách hàng đề xuất 34 node 2U dual-socket trải trên 17 rack, nhưng Clyso đã đề xuất nhiều cấu hình dùng các node nhỏ hơn.
• Cuối cùng, kiến trúc Dell được chọn để giảm chi phí, đồng thời cung cấp thông lượng bộ nhớ nhanh hơn, nhiều tài nguyên CPU hơn và thông lượng mạng cao hơn.
• Giảm một nửa tác động của việc node bị lỗi tới quá trình khôi phục của cụm.

Thiết lập kiểm thử

• Sử dụng CBT để triển khai một cụm Ceph tạm thời và chạy các bài kiểm thử FIO.
• Dùng các bài kiểm thử FIO dựa trên thư viện để chia cụm thành các đơn vị nhỏ và so sánh với các kết quả trước đó.
• Kiểm thử sao chép 3X và erasure coding 6+2, đồng thời kiểm thử message version 2 ở chế độ mã hóa và chế độ bảo mật.

Lưu ý về số lượng PG

• Thử nghiệm thực tế tác động của số lượng PG tới hiệu năng.
• Số lượng PG cao có thể tác động tích cực tới hiệu năng, nhưng trong môi trường sản xuất thực tế cần cân nhắc cùng các thiết lập khác.

Khởi đầu khó khăn

• Sau khi đăng nhập vào phần cứng lần đầu, việc hiệu năng thấp hơn kỳ vọng khiến quá trình xử lý sự cố trở nên khó khăn.
• Các bài kiểm thử hiệu năng ban đầu cho kết quả tốt, nhưng hiệu năng suy giảm khi kiểm thử với nhiều OSD.

Hành vi kỳ lạ

• Khi chạy nhiều tổ hợp kiểm thử OSD khác nhau, họ phát hiện các mẫu bất thường trong hiệu năng.
• Quan sát thấy hệ thống bị giảm hiệu năng sau các bài kiểm thử multi-OSD rồi vài giờ sau mới phục hồi trở lại.

Ba cách khắc phục

• Giải quyết vấn đề độ trễ do chuyển đổi CPU c-state, qua đó cải thiện hiệu năng đôi chút.
• Vô hiệu hóa IOMMU, giúp cải thiện hiệu năng đáng kể.
• Khắc phục vấn đề cờ biên dịch của RocksDB, giúp tăng gấp đôi hiệu năng ghi ngẫu nhiên 4K.

Tuần đầu tiên của năm 2024

• Không thể tập trung vào kiểm thử hiệu năng trong ngày đầu năm mới do sự cố quy mô lớn ở một cụm khác.
• Đến thứ Sáu thì tiếp tục kiểm thử hiệu năng và xác nhận rằng cụm hoạt động tốt ngay cả dưới tải cao.

Nụ cười của số phận

• Khi kết quả kiểm thử hiệu năng trở nên tốt hơn, họ xác nhận rằng cụm mở rộng tuyến tính.
• Đạt tốc độ xử lý dữ liệu 635GiB/s trên một cụm gồm 63 node.

Ngôi sao chết chỉ hoạt động một phần

• Do thiếu node client, họ phải chia sẻ các tiến trình FIO với các node OSD.
• Ngay cả với cấu hình như vậy, họ vẫn đạt hiệu năng gần 950GiB/s.

Chạm mốc 1TiB/s

• Điều chỉnh số lượng OSD shard và số lượng messenger thread để đạt tốc độ xử lý dữ liệu 1TiB/s.

Ngủ một chút; erasure coding

• Sau khi kiểm thử với sao chép 3X, họ cấu hình lại cụm sang erasure coding 6+2 mà khách hàng sẽ sử dụng rồi tiếp tục kiểm thử.
• Hiệu năng đọc vượt 500GiB/s, còn hiệu năng ghi đạt gần 400GiB/s.

Ý kiến của GN⁺:

1. Bài viết này mô tả chi tiết quá trình tối ưu hiệu năng của một cụm Ceph và mang lại góc nhìn kỹ thuật thông qua một trường hợp đạt hiệu năng cao bằng cách giải quyết các vấn đề phức tạp.
2. Bài viết cho thấy sự hợp tác với khách hàng, nỗ lực của các cộng tác viên cộng đồng, cùng nhiều chiến lược tối ưu hóa phần cứng và phần mềm khác nhau có thể tạo ra thành quả lớn trong thực tế như thế nào.
3. Bài viết này cung cấp thông tin hữu ích không chỉ cho các chuyên gia xử lý hệ thống lưu trữ dữ liệu quy mô lớn mà còn cho các kỹ sư quan tâm đến tối ưu hiệu năng.

[GN⁺]

Ý kiến Hacker News

• Tin CERN đạt 1 TB/s và lịch sử của Ceph
  • Một người dùng nhắc đến việc CERN đã đạt tốc độ 1TB/s thông qua cụm EOS, đồng thời giải thích rằng cụm này chủ yếu dùng HDD và có nhiều node hơn. Người này cũng chia sẻ lịch sử thú vị rằng Ceph được tạo ra tại Dreamhost vì nhu cầu nội bộ, sau đó được Redhat mua lại.
• Trải nghiệm của một cựu lãnh đạo kỹ thuật và thiện cảm với Ceph
  • Một người dùng hồi tưởng về thời làm lãnh đạo kỹ thuật tại Cisco, khi thiết lập Kubernetes trên bare metal và thử nghiệm với GlusterFS cùng Ceph, đồng thời nói rằng họ rất thích những thử nghiệm như vậy. Người này cũng khen bài viết được viết rất hay.
• Đề xuất thu nhỏ quy mô node
  • Một người dùng chỉ ra rằng mức tiêu thụ năng lượng trên mỗi node của hệ thống hiện tại là cao, và đề xuất cần có nỗ lực kỹ thuật để giảm kích thước node. Theo họ, như vậy sẽ cần ít node hơn và cũng giảm khả năng một lỗi đơn lẻ ảnh hưởng đến 10 ổ đĩa.
• Góc nhìn lịch sử về lượng dữ liệu số được lưu trữ
  • Một người dùng nhận xét rằng hẳn đã có một ngày nào đó trong vòng 60 năm qua khi lần đầu tiên trên toàn thế giới lưu trữ được 1TiB dữ liệu số, và bày tỏ sự kinh ngạc khi hiện nay con người có thể di chuyển từng ấy dữ liệu mỗi giây.
• Trải nghiệm cải thiện hiệu năng cache Docker qua cụm Ceph
  • Một người dùng chia sẻ rằng họ đang vận hành một cụm lưu trữ Ceph để duy trì Docker layer cache, và sau khi chuyển từ EBS sang Ceph thì throughput đã cải thiện đáng kể. Người này cho biết Ceph hầu như không cần bảo trì.
• Vấn đề của phần mềm storage controller trong Kubernetes
  • Một người dùng cho biết vấn đề lớn nhất liên quan đến dynamic storage trong Kubernetes không nằm ở I/O, mà xảy ra khi phần mềm storage controller gặp sự cố thực tế. Cụ thể, họ từng gặp tình trạng PVC chỉ được attach sau một thời gian rất dài khi dùng rook/ceph và Longhorn.
• Phân tích hiệu năng 1 TiB/s so với giới hạn lý thuyết của phần cứng
  • Một người dùng phân tích cách hiệu năng 1 TiB/s so với giới hạn lý thuyết của phần cứng và chỉ ra rằng mạng đang là nút thắt cổ chai. Họ cũng kết luận rằng độ phức tạp của Ceph đang tạo gánh nặng đáng kể lên CPU, và mô hình threading của OSD chưa được tối ưu, đồng thời hy vọng sẽ có cải tiến.
• Đề nghị so sánh Ceph với các object storage engine khác
  • Một người dùng nói rằng họ muốn xem các phép so sánh và benchmark giữa Ceph với những object storage engine khác như MinIO và Garage.
• Câu hỏi về mức độ phù hợp của Ceph cho lưu trữ cơ sở dữ liệu giao dịch và độ trễ IO
  • Một người dùng đặt câu hỏi liệu Ceph có phù hợp cho lưu trữ cơ sở dữ liệu giao dịch hay không, độ trễ IO ra sao, đồng thời bày tỏ mong muốn chuyển sang một hệ thống file rẻ hơn nhưng có thể cạnh tranh với các hệ thống như clustered file system của Oracle hoặc Veritas.