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

 (ceph.io)
4 điểm bởi GN⁺ 2024-01-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • Clyso đã tiến hành burn-in test trước khi chuyển cụm Ceph dùng HDD sang triển khai NVMe 10PB, và đạt 1,0 TiB/s đọc trên một cụm đơn gồm 630 OSD
  • Phần cứng cuối cùng gồm 68 máy Dell PowerEdge R6615 với 10 NVMe mỗi node, nhưng bài kiểm thử hiệu năng cao nhất được thực hiện với 63 máy khả dụng và 630 OSD
  • Các nút thắt ban đầu được giải quyết bằng cách sửa CPU c-state trong BIOS, tranh chấp ánh xạ IOMMU của kernel, và vấn đề cờ biên dịch RocksDB trong gói upstream Ceph Ubuntu Deb; thời gian compaction giảm khoảng 3 lần và ghi ngẫu nhiên 4KB cải thiện 2 lần
  • Mức đỉnh với cấu hình nhân bản 3X là đọc 4MB 1025GiB/s, ghi 4MB 270GiB/s, đọc ngẫu nhiên 4KB 25,5M IOPS, ghi ngẫu nhiên 4KB 4,9M IOPS; còn erasure coding 6+2 đạt đọc 4MB 547GiB/s và ghi 387GiB/s
  • Rủi ro còn lại là hiện tượng một số PG rơi vào trạng thái active+clean+laggy khi ghi quy mô lớn khiến throughput giảm mạnh; để đạt throughput cao hơn với hơn 10 NVMe mỗi node cần mạng từ 200GbE trở lên

Thiết kế cụm NVMe Ceph 10PB

  • Khách hàng muốn chuyển cụm Ceph dùng HDD hiện có sang triển khai NVMe 10PB, và không có yêu cầu cụ thể cho RBD, RGW, CephFS
  • Điều kiện thiết kế bao gồm phân bổ trên 17 rack, không gian 4U mỗi rack, điện năng, làm mát, mật độ và ưu tiên nhà cung cấp
  • Các node mới phải được tích hợp vào cụm hiện có mà không gián đoạn dịch vụ, và mạng đã là cấu hình Ethernet tốc độ cao được triển khai sẵn
  • Đề xuất ban đầu là bố trí 34 node 2U hai socket trên 17 rack, nhưng cuối cùng cấu hình dựa trên Dell do Clyso thiết kế đã được chọn
    • Báo giá cuối cùng rẻ hơn cấu hình ban đầu khoảng 13%
    • Bộ nhớ trên mỗi OSD giảm, nhưng vẫn ở mức 12GiB mỗi OSD, và băng thông bộ nhớ nhanh hơn
    • Sử dụng cấu hình một socket, tổng tài nguyên CPU nhiều hơn, tổng throughput mạng lớn hơn, bộ xử lý AMD mới nhất và RAM DDR5
    • Dùng các node nhỏ hơn giúp giảm một nửa tác động của lỗi node lên quá trình phục hồi cụm

Phần cứng và cấu hình cơ bản

  • Thông số hệ thống như sau
    • Nodes: 68 × Dell PowerEdge R6615
    • CPU: 1 × AMD EPYC 9454P 48C/96T
    • Memory: 192GiB DDR5
    • Network: 2 × 100GbE Mellanox ConnectX-6
    • NVMe: 10 × Dell 15.36TB Enterprise NVMe Read Intensive AG
    • OS: Ubuntu 20.04.6 Focal
    • Ceph: Quincy v17.2.7 upstream Deb packages
  • Khách hàng muốn giới hạn mức tiêu thụ điện bổ sung mỗi rack ở khoảng 1000~1500W
    • Tổng TDP của 4 node mỗi rack được ước tính tối thiểu là 1120W, cộng thêm điện năng nền, đỉnh CPU và tổn hao do hiệu suất nguồn
    • Họ cho rằng nếu cần có thể giảm cTDP của bộ xử lý để tiết kiệm khoảng 100W mỗi rack
  • Máy chủ Dell 1U có cấu hình gần với thế hệ mới nhất của hệ thống dùng cho phòng lab hiệu năng upstream Ceph
    • Trong quá trình thử nghiệm, họ phát hiện một vấn đề hiệu năng không tồn tại trên phần cứng thế hệ trước nhưng ảnh hưởng tới phần cứng lần này

Phương pháp kiểm thử và lựa chọn benchmark

  • Burn-in test được thực hiện bằng cách triển khai cụm Ceph tạm thời bằng CBT và chạy kiểm thử FIO
  • OSD được đặt osd_memory_target là 8GB
    • Trong production, họ cho rằng có thể dùng osd_memory_target cao hơn
  • Khách hàng không cần kiểm thử workload block hoặc S3, nhưng họ dùng engine librbd của FIO thay vì RADOS bench
    • Với RADOS bench quy mô lớn, khó xác định số instance cần để bão hòa cụm, và trước đây từng cần nhiều pool đồng thời
    • Để so sánh với kết quả lab upstream hiện có, họ dùng cùng bài kiểm thử FIO dựa trên librbd
    • Việc FIO là công cụ quen thuộc và được tin cậy cũng được cân nhắc
  • Kiểm thử kernel RBD được bỏ qua
    • Engine librbd có thể tránh vấn đề mount point cũ khiến hệ thống phải reboot
    • Cụm này không có quyền truy cập IPMI, và thời hạn hoàn tất kiểm thử cũng rất gấp
    • Dựa trên các kiểm thử trước, nếu có đủ client thì tổng hiệu năng được kỳ vọng nhìn chung sẽ tương tự
  • Đối tượng kiểm thử bao gồm nhân bản 3X và erasure coding 6+2
  • msgr V2 được kiểm thử cả ở chế độ không mã hóa và chế độ secure
    • ms_client_mode = secure
    • ms_cluster_mode = secure
    • ms_service_mode = secure
    • ms_mon_client_mode = secure
    • ms_mon_cluster_mode = secure
    • ms_mon_service_mode = secure
  • FIO trước tiên ghi đầy volume RBD bằng các lệnh ghi lớn, rồi chạy các kiểm thử IO 4MB và 4KB, mỗi bài trong 300 giây
    • Khi chạy để debug thì rút xuống 60 giây
    • Các tiến trình nền như scrub, deep scrub, PG autoscaling, PG balancing bị vô hiệu hóa

Ảnh hưởng của số lượng PG tới hiệu năng

  • Các kiểm thử lab upstream trước đó xác nhận rằng số lượng PG có thể ảnh hưởng lớn tới hiệu năng
  • Ở số lượng PG thấp, clumpiness của phân bố ngẫu nhiên có thể ảnh hưởng tới hiệu năng, và một phần có thể được giảm nhẹ bằng balancing bổ sung
  • Trên các cụm nhanh, tranh chấp PG lock bên trong OSD cũng có thể đóng vai trò quan trọng với hiệu năng tổng thể
    • Vấn đề này không dễ giảm nhẹ ngoài việc tăng số lượng PG
  • Ngay cả trong bài kiểm thử chỉ dùng 60 OSD, hiệu năng đọc ngẫu nhiên của pool RBD nhân bản 3X vẫn mở rộng tới 16384 PG
    • Ghi đạt đỉnh sớm hơn, nhưng vẫn có lợi tới 2048 PG
  • Không nên áp dụng mù quáng số lượng PG cao vào production
    • Các giá trị mặc định của Ceph như độ dài PG log và PG stat update có thể ảnh hưởng
    • Cần xem xét lại liệu thông lệ 100 PG mỗi OSD trước đây còn phù hợp hay không

Vấn đề hiệu năng ban đầu và hành vi lạ

  • Họ có thể đăng nhập lần đầu vào phần cứng mới vào tuần sau Thanksgiving ở Mỹ, và kế hoạch ban đầu là burn-in validation trong 1–2 tuần rồi tích hợp vào cụm hiện có
  • Các kiểm thử hiệu năng mức thấp ban đầu trông có vẻ tốt
    • Kiểm thử mạng iperf gần đạt 200Gb/s mỗi node
    • Hiệu năng cơ bản của ổ NVMe trên một số node cũng có vẻ hợp lý
  • Hệ điều hành của cả 68 node đều bị triển khai nhầm lên 2 ổ OSD thay vì ổ boot Dell BOSS m.2 nội bộ
    • Thay vì kiểm thử dự kiến với 3 node và 30 OSD, họ phải kiểm thử chỉ với 8 NVMe mỗi node
  • Kết quả Ceph đầu tiên thấp hơn kỳ vọng rất nhiều, ngay cả khi tính đến số OSD bị giảm
    • Chỉ đọc ngẫu nhiên là gần mức có thể chấp nhận, nhưng vẫn chưa đủ
  • Khi thu hẹp xuống kiểm thử một node và một OSD, một mẫu bất thường xuất hiện
    • Hệ thống chạy tốt trong kiểm thử một OSD lại giảm hiệu năng sau kiểm thử 8 OSD
    • Sau đó, kiểm thử một OSD cũng duy trì hiệu năng kém trong vài giờ rồi mới phục hồi
    • Nếu không đưa kiểm thử nhiều OSD vào, hiệu năng tiếp tục duy trì ở mức cao
  • Khi chạy FIO trực tiếp lên ổ đĩa thì không tái hiện được vấn đề tương tự
  • Trong kiểm thử 8 OSD, một OSD cụ thể dùng CPU nhiều hơn hẳn các OSD khác
  • OSD wallclock profile cho thấy nhiều thời gian bị dùng ở io_submit, đây thường là mẫu thấy khi queue của ổ đĩa đầy và kernel bị block

Ba bản sửa

  • Chế độ hiệu năng BIOS và c-state

    • Bản sửa đầu tiên là vấn đề BIOS không ở chế độ maximum performance, khiến CPU c-state được bật
    • Ceph rất nhạy với độ trễ do chuyển đổi CPU c-state tạo ra
    • Khi tắt c-state bằng chế độ maximum performance, hiệu năng cải thiện 10~20%, nhưng vẫn chưa đủ cho mục tiêu

  • Tranh chấp IOMMU

    • Vấn đề thứ hai lộ ra trong perf profile phía kernel
    • Trong các lần chạy kém, nhiều thời gian bị dùng ở native_queued_spin_lock_slowpath và đường dẫn IOMMU DMA mapping
    • alloc_iova
    • iommu_dma_alloc_iova
    • iommu_dma_map_sg
    • nvme_map_data
    • nvme_queue_rq
    • Khi tắt IOMMU trong kernel, hiệu năng đọc/ghi 4MB của kiểm thử 8 node cải thiện đáng kể
    • Sau bản sửa này, vấn đề ghi ngẫu nhiên 4KB vẫn còn

  • Cờ biên dịch RocksDB

    • Vấn đề thứ ba là hiệu năng ghi ngẫu nhiên 4KB và RocksDB compaction thấp hơn kỳ vọng
    • Trong Ceph trước đây, triệu chứng tương tự liên quan tới hai nguyên nhân
    • Được biên dịch không có hỗ trợ TCMalloc
    • Được biên dịch không có các cờ cmake phù hợp và tối ưu hóa compiler
    • Gói upstream Ceph Ubuntu có bao gồm TCMalloc
    • Log build của gói Ubuntu 17.2.7 xác nhận RocksDB không được build với các cờ biên dịch đúng
    • Canonical và Gentoo đã sửa vấn đề này trong bản build riêng của họ
    • Người dùng Debian/Ubuntu cephadm dùng upstream container có vẻ không bị ảnh hưởng
    • Sau khi build gói custom 17.2.7 đã sửa, thời gian compaction giảm khoảng 3 lần và hiệu năng ghi ngẫu nhiên 4KB tăng 2 lần

Kiểm thử mở rộng trong tuần đầu năm 2024

  • Ngày 2 tháng 1, kiểm thử hiệu năng bị trì hoãn do phải xử lý sự cố quy mô lớn ở một cụm liên quan khác
  • Từ thứ Sáu, họ cấu hình lại CBT và các bài kiểm thử, lần này có thể dùng đủ 10 ổ mỗi node
  • Số lượng client FIO được tăng sao cho trung bình có khoảng 1 client FIO với io_depth 128 trên mỗi OSD
  • Kiểm thử 3 node đạt 63GiB/s ở đọc ngẫu nhiên 4MB
  • Kiểm thử 10 node đạt 213,5GiB/s
    • Gần như mở rộng tuyến tính so với 3 node, ở mức 98,4%
  • Khi đó chỉ 63 trong số 68 node là khả dụng
    • Đặt 32 node, 320 OSD ở một phía
    • Chạy 10 tiến trình FIO mỗi node trên 31 node client
  • Ở quy mô 320 OSD, họ đạt 635GiB/s đọc và hơn 15 triệu IOPS đọc ngẫu nhiên 4KB
  • Độ trễ trung bình và tail latency trông nhất quán trong các kiểm thử mở rộng
    • Việc tăng số lượng PG và client FIO cùng với OSD được xem là có ảnh hưởng
    • Bài kiểm thử ở trạng thái IO rất cao, và họ cho rằng đã đi vào điểm mà thêm IO không làm tăng hiệu năng mà chỉ tăng độ trễ

Đạt 1 TiB/s với 630 OSD

  • Vì không còn node client riêng cho kiểm thử toàn bộ dung lượng, các tiến trình FIO được đặt chung trên các node OSD
    • Có xác suất 1/63 client giao tiếp với OSD cục bộ, tạo một chút lợi thế mạng
    • Ngược lại, đặt client FIO chung trên node OSD có thể gây tổn thất hiệu năng
  • Việc triển khai CBT dựng 630 OSD trên 63 node mất khoảng 15 phút
  • Lần thử đầu tiên đạt khoảng 950GiB/s, rất gần 1 TiB/s
  • Sau đó họ giảm OSD shard và async messenger thread, đồng thời áp dụng Reef RocksDB tuning
    • Hiệu năng đọc giảm nhẹ, hiệu năng ghi cải thiện
    • Hiệu năng ghi ngẫu nhiên cải thiện gần 20%
    • Tác động lớn hơn có vẻ đến từ thay đổi shard/thread
  • Họ cũng thử tăng gấp đôi số PG và tăng lại số client
    • Đọc ngẫu nhiên 4MB cải thiện nhẹ cùng với tăng số client
    • IOPS đọc ngẫu nhiên nhỏ xấu đi
    • Với 8 FIO mỗi node, tổng 504 tiến trình, hiệu năng ghi tuần tự giảm mạnh
  • Khi 504 tiến trình FIO thực hiện ghi 4MB, một số PG rơi vào trạng thái active+clean+laggy
    • Dù throughput chỉ là một phần nhỏ so với khả năng của cụm, số PG laggy tăng dần theo thời gian
    • Cụm không phục hồi khỏi trạng thái này cho tới khi workload kết thúc
    • Theo tài liệu Ceph, ở trạng thái laggy, replica không kịp acknowledge lease mới từ primary, khiến IO tạm dừng
  • Cuối cùng, cấu hình Ceph mặc định gồm 8 shard, 2 thread mỗi shard, 3 msgr thread là phù hợp nhất cho đọc 4MB
  • Với điều kiện 256K PG, 630 OSD, 504 tiến trình client FIO, ceph -s hiển thị 1,0 TiB/s read
    • Cả 630 OSD đều ở trạng thái up/in
    • Tất cả 262145 PG đều ở trạng thái active+clean
    • Tác vụ đọc hiển thị là 266,15k op/s

Kết quả erasure coding 6+2

  • Cụm đích thực tế trước đây của khách hàng dùng cấu hình erasure coding 6+2, nên cần kiểm thử riêng
  • Họ chọn các giá trị PG, shard và client hoạt động tốt trong các kiểm thử trước để chạy kiểm thử EC
  • Do thấy async messenger thread hoạt động bận rộn, họ thử tăng số thread này lên trên giá trị mặc định
  • Với 4~5 async msgr thread, đạt hiệu năng sau
    • Đọc: hơn 500GiB/s
    • Ghi: gần 400GiB/s
  • Lý do đọc 6+2 EC chậm hơn nhân bản 3X là khác biệt về overhead mạng
    • Với nhân bản, primary OSD chỉ cần đọc dữ liệu cục bộ rồi gửi cho client, nên overhead mạng thực tế là 1X
    • Với 6+2 EC, primary phải đọc 5 trong 6 chunk từ replica để cấu thành object rồi gửi cho client
    • Tổng overhead mạng của yêu cầu xấp xỉ (1 + 5/6)X
  • Với ghi thì xu hướng ngược lại
    • Nhân bản 3X có tổng overhead mạng 3X vì object client gửi tới primary được primary gửi tiếp tới hai secondary
    • Với EC, chỉ cần gửi 7/8 chunk tới secondary, nên có hiệu năng nhanh hơn khi ghi lớn
  • IOPS của IO nhỏ là vấn đề riêng
    • Với đọc/ghi rất nhỏ, Ceph truy cập tất cả OSD tham gia PG của object đó
    • Ngay cả khi dữ liệu quan tâm chỉ nằm trong một chunk, nó vẫn lấy dữ liệu từ tất cả OSD tham gia stripe
    • Clyso đã khôi phục PR triển khai partial stripe reads cho erasure coding từ mùa hè 2023, và hiệu quả rất lớn
    • Hiện chưa rõ liệu có thể được merge vào Squid hay không

Ảnh hưởng của mã hóa msgr

  • Để đánh giá tác động nếu khách hàng dùng mã hóa cấp msgr, họ cũng kiểm thử msgr v2 encryption
  • Kết quả khi bật mã hóa ở cả nhân bản 3X và erasure coding 6+2 được so sánh với kết quả trước đó
  • Tác động lớn nhất xuất hiện ở đọc lớn
    • Giảm từ khoảng 1 TiB/s xuống khoảng 750GiB/s
  • Các hạng mục khác giảm hiệu năng nhẹ hơn nhưng nhất quán
  • Họ cũng muốn kiểm thử PG scaling và kernel RBD, nhưng phải bàn giao lại hệ thống cho khách hàng để re-imaging và tích hợp

Tóm tắt hiệu năng đỉnh cuối cùng

  • Các con số cao nhất đạt được trong kiểm thử như sau
Hạng mục 30 OSDs (3x) 100 OSDs (3x) 320 OSDs (3x) 630 OSDs (3x) 630 OSDs (EC62)
Co-located FIO No No No Yes Yes
4MB Read 63 GiB/s 214 GiB/s 635 GiB/s 1025 GiB/s 547 GiB/s
4MB Write 15 GiB/s 46 GiB/s 133 GiB/s 270 GiB/s 387 GiB/s
4KB Rand Read 1.9M IOPS 5.8M IOPS 16.6M IOPS 25.5M IOPS 3.4M IOPS
4KB Rand Write 248K IOPS 745K IOPS 2.4M IOPS 4.9M IOPS 936K IOPS
  • Sau khi kiểm thử kết thúc, toàn bộ phần cứng được re-imaging, và các OSD mới được triển khai vào cụm HDD hiện có của khách hàng
  • Quá trình di trú được kiểm soát bằng script upmap-remapped của Dan, và khoảng 80% dữ liệu hiện có được chuyển sang OSD dựa trên NVMe
  • Ban đầu, họ không áp dụng ngay toàn bộ tuning dùng trong kiểm thử, mà quyết định trước tiên xác nhận hoạt động của cụm với cấu hình phần lớn là mặc định
  • Dữ liệu kiểm thử có thể được dùng để tinh chỉnh thêm hệ thống nếu khách hàng gặp vấn đề hiệu năng trong tương lai

Vấn đề còn lại và giới hạn mở rộng

  • Vấn đề laggy PG xảy ra dưới tải ghi quy mô lớn cần được giải quyết
    • Tình huống Ceph sụp hiệu năng khi workload ghi tăng lên là không thể chấp nhận
  • Kiểm thử lần này xác nhận Ceph có thể bão hòa NIC 2×100GbE
  • Khi dùng hơn 10 ổ NVMe mỗi node, để tăng throughput hơn nữa cần 200GbE trở lên
  • IOPS phức tạp hơn
    • Số lượng PG có thể ảnh hưởng lớn
    • OSD threading model cũng đóng vai trò quan trọng
    • Ở nhiều triển khai, họ gặp bức tường khoảng 400K~600K IOPS đọc ngẫu nhiên mỗi node
  • Các điểm cần cải thiện được chỉ ra gồm giao diện giữa async msgr và kernel, cũng như cách OSD thread được đánh thức khi công việc mới vào shard queue
  • Họ từng sửa mã OSD để đạt kết quả tốt hơn ở tải cao, nhưng phải trả giá bằng độ trễ tệ hơn ở tải thấp
  • Việc cải thiện IOPS cần nhiều hướng tiếp cận và có thể phải viết lại một phần mã OSD threading

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-21
Ý kiến trên Hacker News

  • Ceph có một lịch sử thú vị
    Nó được các nhà sáng lập DreamHost tạo ra vì nhu cầu nội bộ, và DreamHost trên thực tế đã cung cấp các dịch vụ kiểu IaaS và PaaS như VPS, OS/cơ sở dữ liệu/máy chủ ứng dụng được quản lý từ trước khi các thuật ngữ IaaS và PaaS trở nên phổ biến trong ngành
    Sau đó Ceph được tách ra thành công ty riêng và được Red Hat mua lại
    https://en.wikipedia.org/wiki/DreamHost

    • Tôi vẫn là khách hàng của DreamHost, và còn nhớ các bài blog hay newsletter hồi đó kiểu “chúng tôi đang thử tạo một thứ tên là Ceph, có thể sẽ thành cái gì đó rất hay”
      Không có câu chữ marketing được trau chuốt để bán từng câu, chỉ là thời mọi người chia sẻ những thứ họ đang nghịch thử
      Theo tôi nhớ, đó là dự án ở đại học của một trong các nhà sáng lập, rồi các nhà sáng lập khác hỗ trợ và tham gia; tôi cũng biết Docker có nguồn gốc tương tự
    • Nói thêm một chút, đây cũng là thứ do Sage Weil, nhà sáng lập DreamHost, tạo ra khi đang học cao học tại UC Santa Cruz
      UCSC là nơi đã có nhiều nghiên cứu về lưu trữ rất tốt

  • Bài viết hay. CERN gần đây cũng đã đạt 1TB/s, nhưng không phải bằng Ceph mà bằng EOS(https://cern.ch/eos)
    https://www.home.cern/news/news/computing/exabyte-disk-stora...
    Tuy nhiên cụm EOS của chúng tôi có nhiều node hơn rất nhiều và phần lớn dùng HDD. CERN cũng dùng Ceph rộng rãi

    • Tuyệt vời. Tôi tò mò các bạn nhìn nhận Ceph thế nào. Về dài hạn có kế hoạch chuyển sang EOS không?

  • Tôi rất thích những thử nghiệm như thế này. Khi làm technical lead ở Cisco, tôi từng có cơ hội xa xỉ là dựng Kubernetes trên bare metal, tự tay thiết lập GlusterFS và Ceph để học và so sánh xem bên nào tốt hơn
    Nếu nhớ không nhầm thì khoảng năm 2017/2018, đúng là những ngày tháng đẹp. Bài này cũng rất hay

    • Để cải thiện thời gian phản hồi của Aerospike, tôi đã phải chạy cả đống benchmark so sánh không chỉ các loại instance AWS mà còn tốc độ của từng instance riêng lẻ trong cùng một loại
      Một số NVMe SSD đã được sử dụng nhiều hơn những cái khác nên tạo ra khác biệt, đúng là một công việc hết sức vô lý
    • À, người từng dùng Heketi đây rồi. Tôi cũng có trải nghiệm tương tự vào cùng thời điểm đó và thấy rất vui. Mọi thứ đều quá mới mẻ, và cũng đều hỏng hóc

  • Mong là ai đó thử thu nhỏ quy mô node xuống nữa. Hệ thống được mô tả ở đây có 10 ổ đĩa mỗi node và khoảng 300W/node, tức khoảng 30W mỗi ổ đĩa
    Overhead khá lớn, và để có được dù chỉ một chút dư thừa thì cũng cần khá nhiều dung lượng lưu trữ
    Nếu đầu tư kỹ thuật một chút, có lẽ có thể thu nhỏ toàn bộ xuống còn một phần mười. Kiểu như làm một máy tính bo mạch đơn nhỏ có 4 lane PCIe cho NVMe, 2x10GbE (2 socket SFP+), CPU ARM hoặc RISC-V đủ nhanh, rồi thêm eMMC hoặc khe SD để boot
    Như vậy có thể hạ xuống quy mô chỉ vài node, đồng thời giảm mức phơi nhiễm khi một lỗi đơn lẻ làm mất 10 ổ đĩa cùng lúc
    Có vẻ có thể nhét rất nhiều hệ thống kiểu này vào một enclosure 4U, và tùy chọn thêm 2 switch hoàn toàn độc lập trong cùng enclosure để gom các node nội bộ

    • Trước đây tôi từng chạy một cụm Ceph 5 node bằng nhiều chiếc ODROID-HC2
      Vì là bộ xử lý armhf nên cài đặt thật sự rất khổ, nhưng khi đã chạy được thì hoạt động tốt. Chỉ chậm vì có một NIC 1Gb duy nhất
      Lúc đó chỉ là để học
      [0] https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/
    • Có thể kiểm chứng khái niệm này rồi bằng giao diện module tính toán SODIMM của Nvidia
      Tôi sắp nhận hai chiếc ARM Turing RK1 7W, mỗi chiếc đạt 4GB/s qua PCIe 3x4, còn bo cluster Turing Pi 2 có thể gắn 4 chiếc theo form factor ITX
      Với tổng chi phí 820 USD, tôi kỳ vọng hơn 3Gbps mỗi watt
      Cho đến nay, các lane PCIe là nút thắt. Ngay cả SSD 2TB giá 90 USD cũng được ghi là 7GB/s trên PCIe 4x4, nên tôi vẫn chưa xem máy tính bo mạch đơn là lời giải tối ưu
      Dòng Ampere Altra có vẻ hỗ trợ PCIe 4x128 ở 40W, nên một blade 1U gắn mạng 100G có thể sẽ thú vị
      Tuy vậy, ngay cả trong homelab tôi cũng đã thấy nhiều lỗi liên quan đến ARM và các tối ưu hóa còn thiếu, nên có lẽ khó nói những giải pháp như vậy đã sẵn sàng cho datacenter
    • Khi các switch 100Gbps và giao diện 100Gbps giá rẻ ngày càng nhiều, 10Gbps đang dần trở nên lỗi thời
      Nếu muốn biện minh cho một cấu hình Ceph dùng giao diện 10Gbps hiện nay, nó phải thật sự nhỏ và rất rẻ
      Ở quy mô nhỏ đến mức đó, nhiều khả năng đặt lưu trữ NVMe cục bộ trên từng server sẽ tốt hơn
    • Nếu tính nhẩm hơi kỳ lạ thì cụm này xử lý khoảng 0,8Gbps mỗi watt
      Đại khái là 1TB/s × 8 bit/byte × 1024GB/TB ÷ 34 node ÷ 300W
      Một hệ thống ARM rất hiệu quả như Mac mini mới dùng khoảng 10W trong tác vụ tương tác và có thể xử lý mạng 10Gbps, tức khoảng 1Gbps mỗi watt tính theo dữ liệu
      Nói cách khác, cụm trong bài gốc xấp xỉ cùng mức bit/giây/watt với một hệ thống ARM rất hiệu quả
      Tôi không nghĩ dùng node nhỏ sẽ thực sự cải thiện hiệu suất năng lượng; ngược lại có khả năng còn tốn chi phí hơn. Hiệu năng trên mỗi watt của các server mạnh hiện nay khá tốt
      Dù sao thì đây là phần mềm mã nguồn mở chạy trên phần cứng phổ thông, nên bạn cũng có thể tự thử với vài trăm đô la
    • Nguồn kém hiệu quả chính trong cấu trúc này có lẽ là bộ điều khiển NVMe
      Khi hệ điều hành và thiết bị NVMe ở xa nhau, bộ điều khiển phải suy đoán ý định của yêu cầu để xử lý batching và wear leveling tốt nhất có thể, nên tự nhiên sẽ sinh ra kém hiệu quả
      Tính năng FDP (flexible data placement) mới là một nỗ lực giải quyết điều này bằng cách trao thêm quyền kiểm soát cho hệ điều hành
      Tốt nhất là kéo phần này lên phía hệ điều hành host, và phơi bày flash càng giống “một mảng transistor khổng lồ ngu ngốc gắn như thiết bị PCIe” càng tốt
      Nếu loại bỏ các lớp trừu tượng, có lẽ có thể cấu thành theo các đơn vị phần cứng kiểu Atom có NIC 100Gbps tích hợp và lượng flash tương ứng, để đạt mức song song hệ thống mong muốn

  • Hẳn đã có một thời điểm trong lịch sử khi tổng lượng dữ liệu số được lưu trữ trên toàn thế giới lần đầu đạt 1TiB
    Ngày đó gần như chắc chắn nằm trong vòng 60 năm qua
    Vậy mà giờ đây một server của một tổ chức khá tùy ý nào đó đang di chuyển lượng dữ liệu ấy mỗi giây. Không phải cấp quốc gia hay một dự án nghiên cứu siêu quốc gia gì cả

    • Tôi nhớ trước đây từng tính ra rằng PC desktop của mình có lẽ mạnh hơn toàn bộ máy tính trên Trái Đất cộng lại vào khoảng năm 1978
    • Ít nhất cũng phải hơn khoảng 20 năm trước. Tôi nhớ một sysadmin kỳ cựu từng kể chuyện quản lý petabyte trước năm 2003

  • Bài viết thú vị. Chúng tôi vận hành một cụm lưu trữ Ceph để duy trì cache layer Docker
    Sau khi chuyển từ EBS sang Ceph, chênh lệch throughput là cực lớn. Throughput ghi tăng từ 146MB/s và 3.000 IOPS lên 900MB/s và 30.000 IOPS
    Điểm hay nhất là gần như cứ thế chạy. Ngoại trừ thỉnh thoảng làm vài việc như filesystem trim thì hầu như không phải chăm sóc
    Đối với hệ thống cache, đó là một cải thiện khổng lồ
    [0] https://depot.dev/blog/cache-v2-faster-builds

    • Gần 10 năm trước tôi đã làm một việc rất tương tự. Với cùng tiêu chí hiệu năng, chi phí EBS đắt hơn cụm Ceph trên đĩa của node hơn 10 lần
      Cuối cùng khi chuyển sang rack riêng, chúng tôi lại giảm chi phí xuống gần một phần mười nữa, và nhờ có năng lực vận hành nội bộ nên cũng tự do hơn
    • Tôi tò mò không biết EBS có được host trên bare metal hay không. Còn Ceph thì đang host như thế nào: bare metal tự sở hữu/thuê, hay máy ảo EC2?
      Chỉ đọc blog thì tôi chưa thấy rõ ngay

  • Những vấn đề tệ nhất tôi gặp với lưu trữ động nội bộ cluster không phải là vấn đề I/O thuần túy
    Chúng nằm ở việc phần mềm storage controller của Kubernetes không xử lý tốt các vấn đề trong môi trường thực, chẳng hạn pod chết và PVC không attach cho đến khi hết một timeout rất dài, còn pod thì kẹt ở trạng thái ContainerCreating cho đến khi khóa PVC được nhả
    Những chuyện như vậy đã xảy ra trên nhiều cluster dùng rook/ceph và Longhorn

  • Tôi tò mò không biết có ai từng chạy Ceph trong homelab chưa. Lần cuối tôi tìm hiểu thì yêu cầu phần cứng khá cao

    • Yêu cầu vẫn còn cao. Từ góc nhìn của người đã triển khai cả môi trường production lẫn homelab, nếu không phải để tích lũy kinh nghiệm hoặc dựng demo thì tốt nhất không nên làm
      Khi chạy ổn thì rất tuyệt, nhưng khi có vấn đề thì sẽ trở thành một cơn đau đầu khủng khiếp
      Nếu bạn quan tâm đến bản thân lưu trữ phân tán, có những lựa chọn tốt hơn cho cấu hình homelab
      seaweedfs đã rất ổn định trong nhiều năm ở cả quy mô nhỏ lẫn quy mô rất lớn, và thực tế tôi đã chuyển cấu hình Ceph production sang nó
      Khi ở trong thế giới Kubernetes, Longhorn cũng ổn định
      GlusterFS vẫn ổn nếu bạn biết mình sẽ phải chấp nhận những gì khi dùng nó
    • Tôi đã dùng thử, và web UI, object storage, file storage rất ấn tượng
      Nhưng để đạt được hiệu năng khá là rất khó, và trong cluster nhỏ, metadata daemon có thể dừng khá dễ dàng
      Cuối cùng, khi hết vui, tôi quay lại dùng ZFS trên một máy đơn
    • Tôi có kinh nghiệm dùng Ceph cả trong công việc lẫn môi trường tương tự homelab
      Trước hết cần nhớ rằng Ceph là một hệ thống lưu trữ phân tán, nên việc có nhiều node là tiền đề cơ bản
      Để học thì có thể ảo hóa toàn bộ trên một máy đơn, nhưng nếu có các máy vật lý riêng thì tốt hơn nhiều
      Ceph, tương tự ZFS, ưa thích quyền truy cập vật lý vào đĩa
      Ngoài ra cần kết nối mạng đủ tốt. Tôi nghĩ đây là phần mọi người thường nghĩ đến khi nói về yêu cầu phần cứng cao của Ceph
      Lý tưởng nhất là tối thiểu 10GbE, và nếu muốn hiệu năng cao hơn thì cần hơn thế. Đặc biệt trong các tác vụ như backfill, lưu lượng mạng có thể rất lớn
      Nếu có thể kiếm thiết bị homelab giá rẻ thì 25Gbps cũng tốt, 50Gbps về mặt kỹ thuật gần như là ngõ cụt, còn 100Gbps thì hoạt động tốt
      Dù vậy, với homelab thì các mini PC hoặc NUC giá rẻ có 10GbE cũng đủ chạy, đồng thời mang lại hiệu năng và giá trị học tập chấp nhận được
      Bạn có thể cài Ceph trực tiếp trên bare metal, hoặc nếu muốn đi theo hướng Kubernetes cho homelab thì có thể dùng Rook(https://rook.io/)
      Hy vọng hữu ích; nếu có câu hỏi thêm thì cứ cho tôi biết
    • Phía Ceph có một bài blog về việc cài Ceph trên vài máy Raspberry Pi 4
      Ở mức đó thì khó có thể xem là phần cứng lớn được
      [1] https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberr...
    • Tôi đang chạy Ceph trong lab của mình. Nó dùng CPU khá nhiều, nhưng nếu bạn sẵn sàng chấp nhận mạng nhanh thì hoạt động tốt
      Tối thiểu 10Gb, tốt nhất là 40Gb trở lên; nếu dùng ổ đĩa quay thì nên có vài node, mỗi node ít nhất khoảng 6 ổ đĩa
      Nếu toàn bộ là SSD thì rất có thể có thể giảm số ổ đĩa trên mỗi node xuống nhiều

  • Tôi muốn xem 1TiB/s so với giới hạn lý thuyết của phần cứng thực tế như thế nào, nên đã thử tính toán
    Cụm này gồm 68 node, mỗi node là Dell PowerEdge R6615(https://www.delltechnologies.com/asset/en-us/products/server...)
    Cấu hình sử dụng là R6615 với 10 khay ổ U.2, và liên kết U.2 truyền dữ liệu qua 4 lane PCIe thế hệ 4. Mỗi lane PCIe là 16Gbit/s, và nhờ mã hóa 128b-132b, overhead khoảng 3% nên có thể xem là không đáng kể
    Vì vậy băng thông liên kết tối đa của một liên kết U.2 là 16×4=64Gbit/s, tức 8Gbyte/s. Tuy nhiên ổ U.2 NVMe được dùng, Dell 15.36TB Enterprise NVMe Read Intensive AG, có vẻ có thông lượng đọc 7Gbyte/s(https://www.serversupply.com/SSD%20W-TRAY/NVMe/15.36TB/DELL/...), nên liên kết U.2 8Gbyte/s không phải nút thắt
    Vì mỗi node có 10 ổ U.2, mỗi node có thể đạt tối đa 10×7=70Gbyte/s I/O đọc cục bộ
    Nhưng băng thông mạng của mỗi node chỉ là 200Gbit/s(2×100GbE Mellanox ConnectX-6), tức 25Gbyte/s. Điều đó có nghĩa là trong đọc từ xa, không thể dùng hết năng lực 70Gbyte/s của ổ đĩa và mạng là nút thắt
    Giả sử không có nút thắt mạng bổ sung, 68 node có thể cung cấp 68×25=1700Gbyte/s đọc qua mạng. Tác giả thực tế đã benchmark được 1TiB/s, chính xác là 1025GiB/s=1101Gbyte/s, tức khoảng 65% mức tối đa lý thuyết 1700Gbyte/s
    Khá ổn, nhưng nếu tất cả các node có thể đồng thời bão hòa hoàn toàn liên kết mạng 200Gbit/s thì về lý thuyết vẫn có thể tốt hơn một chút
    Khi đọc toàn bộ bài, tôi có ấn tượng rằng độ phức tạp của Ceph tạo gánh nặng khá lớn lên CPU. Chỉ riêng việc không biên dịch module với -O2(“Fix Three” mà tác giả liên kết: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453) mà trong workload I/O thuần túy “một số workload có thể chậm hơn tới 5 lần”(https://bugs.gentoo.org/733316) là điều khá bất ngờ
    Việc các thread OSD lãng phí CPU quá mức để giữ IOMMU spinlock cũng lạ. Tôi đồng ý với kết luận rằng mô hình threading của OSD chưa tối ưu
    Một benchmark tổng hợp tương đối đơn giản, 100% đọc, đáng lẽ không nên làm lộ tranh chấp threading. Nếu phần đó trong kiến trúc phần mềm Ceph được thiết kế tốt thì là vậy. Đây là vấn đề có thể sửa được, nên hy vọng các nhà phát triển Ceph sẽ ưu tiên cao hơn

    • Tôi muốn nói thêm rằng trước đây tôi chưa từng thấy vấn đề IOMMU trong Ceph
      Phòng lab Ceph upstream có thiết bị dùng thế hệ trước của cùng chassis 1U của Dell và bộ xử lý AMD Rome, với quy mô tương tự khoảng 30 OSD, đạt hiệu năng tương tự mà không gặp vấn đề này
      Khách hàng nói họ từng thấy vấn đề này trong datacenter của họ trước đây, và hy vọng có thể cùng AMD xác định nguyên nhân
      Mùa hè năm ngoái tôi đã làm một chút để tạm thời gia cố mô hình threading hiện tại của OSD. Chẳng hạn như double buffering khi handoff giữa async msgr và worker thread, đánh thức thread thích ứng
      Khi có tải, hiệu năng và hiệu quả có thể tăng đáng kể, nhưng cái giá là độ trễ tăng ở mức tải thấp. Về cơ bản Ceph rất chủ động đánh thức thread khi có I/O mới đi vào một shard cụ thể
      Tôi đã thảo luận với một nhà phát triển cốt lõi khác, và cả hai đều đi đến kết luận rằng đại tu toàn bộ mã threading sẽ hợp lý hơn
    • Benchmark này là I/O ngẫu nhiên. Đĩa có 4K random read IOPS “chỉ” hơn 1 triệu một chút, quy đổi ra khoảng 5GiB/s
      Nếu có 320 OSD thì khoảng 1.6TiB/s
      Ít nhất đó là con số tôi tìm được. Cũng không có nhiều bài review loại đĩa NVMe doanh nghiệp như thế này
      Dù vậy, con số này có vẻ khớp tốt với NIC. Ở quy mô này, phần lớn workload có khả năng trông giống I/O ngẫu nhiên ở tầng lưu trữ
    • Tôi nghĩ overhead PCIe TLP và lệnh NVMe giải thích sự khác biệt giữa 7GB/s và 8GB/s

  • Điều đáng ngạc nhiên là vì sao lại chọn node 1U khó làm mát hơn, cùng cấu hình 10 SSD/2×100Gb NIC
    Nếu dùng node 2U với 24 SSD và 2×200Gb hoặc 400Gb NIC thì có thể loại bỏ nút thắt mạng, đồng thời giảm điện năng nhờ quạt lớn hơn, chậm hơn và ít gói CPU hơn. Số core trên mỗi socket cũng có thể nhiều hơn
    Số node ít hơn sẽ làm phạm vi ảnh hưởng khi hỏng hóc lớn hơn, nhưng khoảng 34 node thì có lẽ không phải vấn đề quá lớn
    Nếu node ít hơn, có lẽ cũng có thể xây dựng một mạng phẳng hơn với khoảng 4 switch

    • Như đã nói, phạm vi ảnh hưởng khi hỏng hóc là yếu tố chính, và nói chung cũng giúp việc vá lỗi cũng như thay thế phần cứng đỡ nặng nề hơn
      Rack và switch đã có sẵn và cũng đang được dùng nhiều cho mục đích khác, nên không gian vật lý tăng thêm vì Ceph là rất nhỏ :)