Volume riêng, hạn mức IOPS chưa đủ bảo đảm cô lập hiệu năng trên Ceph 

Việc thiết lập giới hạn IOPS theo volume kiểm soát được ngưỡng I/O tối đa nhưng chưa giải quyết được bài toán quan trọng đối với kiến trúc sư hệ thống: độ trễ đã cam kết có bị phá vỡ khi tenant khác đột ngột tăng I/O, hoặc khi cụm lưu trữ đang chạy tác vụ phục hồi hệ thống? Trong mô phỏng dưới đây, P99 tăng hơn ba lần chỉ vì hoạt động của tenant bên cạnh dù lượng request của tenant không thay đổi. 

Với Ceph RBD - lớp lưu trữ khối nền tảng cho máy ảo, trọng tâm đánh giá phải dịch chuyển từ thông số tĩnh sang năng lực cô lập hiệu năng: mức độ ảnh hưởng chéo giữa các tenant lớn đến đâu, và đâu là bằng chứng kỹ thuật cho thấy hệ thống đáp ứng được request này? 

Từ đột biến IOPS đến định vị điểm nghẽn cục bộ 

Tại FPT Cloud, khi lượng request từ client tăng đột biến, việc đầu tiên chúng tôi làm là xem request đang phân bố như thế nào giữa các tenant. Kết quả thường thấy: một tenant chiếm phần lớn năng lực đáp ứng của cụm. Nhưng biết tenant nào đứng đầu mới là bước khoanh vùng, chưa trả lời vì sao volume của tenant khác lại chậm. Mức sử dụng trung bình thấp của toàn cụm vẫn có thể che khuất bởi một điểm nghẽn cục bộ. Để quy ra được nguyên nhân, bắt buộc phải đối chiếu chéo (correlate): nếu lượng request của tenant A không đổi nhưng độ trễ tăng đúng lúc tenant B tăng mạnh I/O, đó mới là dấu hiệu của tranh chấp tài nguyên. 

Theo thuật toán phân phối CRUSH của Ceph, các pool có thể đặt dữ liệu trên cùng những OSD. Chia volume vào pool khác nhau vì thế chưa chứng minh đường I/O đã được phân tách hay chưa. Cần phân biệt tranh chấp tài nguyên với lỗi ngầm (gray failure) ở thiết bị hoặc máy chủ lưu trữ: những bất thường mà các cơ chế giám sát đang dùng chưa phát hiện được đầy đủ. Trong những trường hợp chúng tôi từng kiểm tra, hệ thống vẫn hoạt động nhưng thao tác ghi đĩa không hoàn thành, trong khi thiết bị không xuất hiện log lỗi. Khi đó phải điều tra theo hướng đường I/O bị treo (hung I/O), không mặc nhiên quy cho tenant khác. 

Chẩn đoán đúng hai trường hợp này quyết định cách xử lý: throttling chỉ giảm được tranh chấp; với một đường I/O đang treo, nó không có tác dụng. 

Giới hạn IOPS theo volume chưa mô tả tổng nhu cầu của một tenant 

Tại FPT Cloud, giới hạn IOPS cho volume máy ảo được thực thi ở lớp quản lý máy ảo (hypervisor) theo từng loại storage khách hàng lựa chọn. Cơ chế này kiểm soát lượng I/O đẩy xuống từ tầng frontend; nó không tự bảo đảm mức độ delay cụ thể khi backend lưu trữ chịu áp lực hoặc gặp bất thường. Khi đánh giá dịch vụ, kiến trúc sư cần tách hai thứ: hạn mức được cấp là mức trần, còn năng lực phục vụ thực tế mới quyết định độ trễ. 

Giới hạn theo volume cũng chưa cho biết tổng nhu cầu của tenant: khách hàng dùng nhiều volume cùng lúc có thể tạo tổng lượng I/O lớn dù từng volume đều nằm trong hạn mức. Bài kiểm thử vì vậy cần bao gồm số lượng volume và mức truy xuất đồng thời (queue depth) đại diện cho hệ thống thực tế. 

Chỉ số IOPS cần được đọc cùng I/O size và thông lượng. Mức 2.000 IOPS ở kích thước 4 KiB tương đương khoảng 7,81 MiB/s; ở kích thước 1 MiB, con số là 2.000 MiB/s, cao gấp 256 lần. Lượng dữ liệu này mới ở phía client, chưa gồm overhead nội bộ của cụm như replication hay erasure coding. Các cơ chế này khuếch đại lượng ghi xuống thiết bị, nên cùng một kích thước, thao tác ghi tốn backend hơn thao tác đọc. 

Điểm thực thi giới hạn QoS phải được xác định theo từng kiến trúc dịch vụ. Cơ chế giới hạn tại hypervisor khác với QoS tích hợp trong librbd, vốn áp dụng theo từng image trong từng tiến trình. Nếu hệ thống cho phép vượt hạn mức tức thời, báo cáo cần ghi cả chính sách burst và cửa sổ đo để giải thích các đỉnh I/O trên biểu đồ. 

Recovery và backfill làm thay đổi điều kiện phục vụ I/O 

Recovery (đồng bộ dữ liệu giữa các bản sao) và backfill (quét, đồng bộ toàn bộ nội dung một PG thay vì đồng bộ dựa trên PG log) tiêu thụ tài nguyên song song với I/O của ứng dụng. Ở OSD, bộ lập lịch mClock phân bổ tài nguyên bằng mức dành trước (reservation), trọng số (weight) và mức trần (limit). Tài liệu Ceph Tentacle phân loại request thành ba nhóm: client I/O, background recovery và background best-effort (gồm backfill). Các nhóm này phân chia workload theo loại tác vụ, không tương ứng với từng tenant. 

Người vận hành phải xử lý một đánh đổi: ưu tiên workload cho client I/O thì kéo dài thời gian phục hồi cụm, ưu tiên phục hồi cụm thì làm tăng độ trễ phía client. Báo cáo kiểm thử vì vậy cần ghi cả P95/P99 phía client, tiến độ phục hồi và thời gian các PG liên quan trở lại trạng thái active+clean. 

Kinh nghiệm của chúng tôi qua các lần nâng cấp Ceph: không suy hành vi từ tên profile, mà xác nhận lại đường đi của I/O mỗi khi đổi phiên bản hoặc kiểu pool. Khi phân tích sự cố, cần tách giai đoạn cụm thay đổi trạng thái PG (như peering) khỏi giai đoạn hệ thống đã tiếp tục phục vụ và đang đồng bộ dữ liệu. Một số trạng thái PG chặn I/O; độ trễ tăng ngay sau sự cố phải được đối chiếu với trạng thái cụm để tránh nhầm với tranh chấp tài nguyên do recovery hoặc backfill. 

Giới hạn đầu vào không bảo đảm P99: phân tích qua mô hình M/M/1 

Mô hình hàng đợi M/M/1 dưới đây tách riêng quan hệ giữa lượng request và năng lực phục vụ. 

Lưu ý: đây là mô phỏng lý thuyết, không mô phỏng thuật toán mClock, không phải benchmark Ceph hay số liệu FPT Cloud. 

Các giả định của mô hình xử lý tuần tự (FIFO): 

• Tenant A gửi trung bình 2.000 requests/giây, giữ nguyên giữa các kịch bản. Requests của A và B đến theo hai quá trình Poisson độc lập; thời gian phục vụ theo phân bố mũ, mọi requests cùng phân bố chi phí xử lý. 

• Năng lực phục vụ trung bình, ký hiệu μ, là 10.000 requests/giây. Mỗi request có thêm thành phần độ trễ cố định 1 ms nằm ngoài tài nguyên dùng chung. 

• Một nhóm kịch bản giả định μ giảm còn 7.000 requests/giây, mô hình hóa việc năng lực phục vụ suy giảm. Mức giảm 30% chọn để khảo sát, không đại diện cho mức suy giảm của Ceph khi recovery/backfill. 

• Giới hạn B được mô hình hóa bằng cách giảm số requests B được nhận vào tài nguyên. Mô hình không tính thời gian B chờ tại bộ giới hạn (throttler). 

• Mỗi kịch bản chạy 5 lần với các seed từ 20261012 đến 20261016, bỏ 60 giây khởi động (warm-up), đo 300 giây, thu khoảng 3 triệu requests A qua 5 lần chạy. Bảng là trung vị của từng chỉ số; mọi độ trễ thuộc A. 

Dù lượng request của A không đổi, P99 của A tăng hơn ba lần (từ 1,77 lên 5,69 ms) khi B tăng mức I/O. Độ trễ trung bình 2,01 ms cũng không cho thấy khoảng 13,7% requests A đã vượt 3 ms. 

Giả định SLO của A là P99 không vượt 3 ms. Khi μ bằng 10.000, giới hạn mức nhận của B ở 4.000 requests/giây giúp đạt mục tiêu. Khi μ giảm còn 7.000, cùng hạn mức đó không còn giữ được SLO: P99 của A lên khoảng 5,67 ms, gấp khoảng 2,6 lần so với khi μ còn nguyên. Muốn đưa P99 về khoảng 2,54 ms, phải siết mức nhận của B xuống 2.000; mô hình chưa đo trải nghiệm của B tại bộ giới hạn, nên kết quả này không chứng minh cả hai tenant đều được phục vụ đúng cam kết. 

Có thể đối chiếu kết quả với công thức M/M/1. Với μ, λA và λB tính theo requests/giây, độ trễ P99 theo ms là: 

P99 (ms) = 1 + 1.000 × ln(100) / (μ - λA - λB) 

Công thức hợp lệ khi tổng lượng requests đến nhỏ hơn μ. Trung vị P99 của 5 lần chạy lệch dưới 1,6% so với giá trị tính theo công thức ở cả năm kịch bản. Với SLO 3 ms như giả định, công thức đòi phần chênh giữa μ và tổng lượng requests đến khoảng 2.300 requests/giây trở lên; đây là dư địa theo mô hình, không phải mức dự phòng áp thẳng cho cụm thật. 

Mô hình chủ động lược bỏ kích thước I/O, cache, topology, replication và cơ chế đa hàng đợi; μ cũng được giữ cố định thay vì tái hiện diễn biến recovery/backfill. Kết quả minh họa một điều: hiệu quả của bất kỳ hạn mức QoS nào phụ thuộc vào năng lực phục vụ còn lại của hệ thống; nó không cung cấp bộ tham số để áp thẳng cho cụm Ceph thực tế. 

Áp dụng vào hệ thống của bạn 

Trước khi tin một cam kết cô lập, kiến trúc sư nên yêu cầu nhà cung cấp trả lời bằng văn bản ba câu hỏi: 

• Hạn mức được thực thi ở đâu: hypervisor, librbd hay một lớp khác? 

• Hạn mức áp theo từng volume hay cộng gộp theo tenant? 

• Chính sách giữ hiệu năng thế nào khi cụm đang recovery hoặc backfill? 

Câu trả lời cho ba câu này quyết định con số IOPS trên bảng thông số có ý nghĩa gì với mục tiêu hiệu năng của bạn. Trả lời trên giấy là bước đầu; bước tiếp theo là kiểm chứng: thiết kế bài đo đi qua đúng tài nguyên, đọc bằng chứng từ hai phía của ranh giới ảo hóa, và để kết quả đo dẫn tới quyết định. Đó là nội dung bài tiếp theo: bộ bảy điều kiện kiểm thử trước khi thống nhất cam kết hiệu năng lưu trữ đa tenant.

Vũ Văn Quang 

Chuyên gia, Trung tâm Phát triển Dịch vụ Hạ tầng Cloud, FPT Cloud