Kiểm chứng cô lập hiệu năng trên Ceph trước khi nghiệm thu 

Bài trước đã chỉ ra giới hạn IOPS chưa phải cam kết cô lập: hiệu quả của hạn mức phụ thuộc năng lực phục vụ còn lại của hệ thống. Trong mô phỏng của bài đó, hạn mức giữ nguyên nhưng năng lực phục vụ suy giảm, P99 vẫn tăng khoảng 2,6 lần. Câu hỏi tiếp theo thực tế hơn: trước khi thống nhất cam kết hiệu năng, kiểm chứng thế nào, và bằng chứng nào mới đủ tin? Bài viết này đưa bảy điều kiện kiểm thử, cách đọc số liệu từ hai phía và cách ra quyết định khi đã có kết quả. 

Bài kiểm thử phải đi qua đúng tài nguyên cần đánh giá 

Để kiểm chứng cơ chế QoS, luồng I/O của tenant A và B phải cùng đi qua vùng tài nguyên chia sẻ. Nếu hai volume nằm trên các nhóm OSD khác nhau, báo cáo cần chỉ rõ chúng còn dùng chung những thành phần nào: máy chủ vật lý, thiết bị DB/WAL hay đường mạng. 

Vị trí nút thắt (bottleneck) không chỉ do loại thiết bị quyết định. Trên hạ tầng all-flash NVMe, điểm nghẽn có thể xuất hiện ở CPU của tiến trình OSD hoặc ở mạng trước khi chạm trần ổ đĩa, tùy kiểu I/O và cấu hình. Vì vậy chuỗi số liệu CPU theo OSD và theo máy chủ là bắt buộc; thiết bị vẫn phải đo, không loại trừ chỉ vì hệ thống dùng NVMe. Nếu kiến trúc đã chủ động tách tài nguyên từ thiết kế, PoC chỉ cần xác nhận SLO trên đúng mô hình triển khai; không cần ép hai volume dùng chung OSD để giả lập một tranh chấp không tồn tại trong phương án cung cấp dịch vụ. 

Kịch bản tham chiếu có thể cho A đọc ngẫu nhiên (random read) 4 KiB ở mức 2.000 IOPS, song song với B chạy lần lượt hai kiểu ghi, mỗi kiểu một bài đo riêng: ghi ngẫu nhiên block nhỏ (ví dụ 4 KiB) và ghi tuần tự (sequential write) khối 1 MiB. Kịch bản này minh họa phương pháp, không phải cấu hình hay kết quả kiểm thử của FPT Cloud; thông số thực tế cần thay bằng đặc tả workload của ứng dụng. 

Trước khi đo, cần chuẩn bị sẵn dữ liệu trên volume và loại giai đoạn khởi động khỏi số liệu; đồng thời ghi rõ chính sách cache. Nếu phần lớn yêu cầu được phục vụ từ cache phía hypervisor, kết quả không phản ánh năng lực phục vụ của cụm backend. Với ứng dụng yêu cầu ghi bền vững, bài kiểm thử bắt buộc tái hiện hành vi flush hoặc fsync tương ứng. 

Bảng trên mới trả lời câu hỏi đo gì, trong tình huống nào: đó là khung kế hoạch kiểm thử, chưa phải tiêu chuẩn nghiệm thu. Muốn nghiệm thu được, hai bên phải chốt trước bốn nhóm ngưỡng: 

• Đặc điểm I/O và số volume đồng thời đại diện cho hệ thống thật. 

• Mức IOPS hoàn thành, P95/P99 và tỷ lệ lỗi, timeout chấp nhận được. 

• Điểm đo và cửa sổ tính percentile. 

• Điều kiện áp dụng riêng khi recovery hoặc backfill. 

Không cần một ngưỡng chung cho mọi khách hàng, nhưng cần một mẫu để mỗi bên điền yêu cầu của mình. Trong mỗi phép so sánh, chỉ thay đổi đúng một biến; cấu hình máy ảo, tập dữ liệu, chính sách cache và công cụ phát I/O giữ nguyên. Báo cáo phải phân biệt tốc độ dự định phát, tốc độ thực gửi (submission) và tốc độ hoàn thành (completion). Nếu công cụ phát I/O chỉ gửi yêu cầu tiếp theo sau khi yêu cầu trước có phản hồi, hệ thống chậm sẽ tự làm giảm tốc độ phát, khiến độ trễ đo được trông ổn hơn thực tế, hiện tượng này gọi là coordinated omission. Khi mục tiêu là mô phỏng nguồn yêu cầu đến độc lập, phải kiểm tra công cụ duy trì được lịch phát và tính cả thời gian chờ trước khi gửi. 

Với kịch bản recovery/backfill, báo cáo cần timestamp bắt đầu, các thời điểm chuyển trạng thái PG (degraded, recovering, backfilling, remapped) và thời điểm các PG liên quan trở lại active+clean. Tiến độ phục hồi và thời gian hoàn tất là hai số khác nhau, cần ghi riêng. Nếu dừng đo trước khi phục hồi hoàn tất, trạng thái cụm tại thời điểm dừng phải được ghi rõ. 

Bằng chứng phải nối được metrics máy ảo với trạng thái hạ tầng 

Kiểm tra tham số giới hạn tĩnh chỉ xác nhận được chính sách có đang được áp hay không. Muốn phân tích mức cô lập, kiến trúc sư cần chuỗi số liệu theo thời gian (time-series) bao trùm trước, trong và sau giai đoạn biến động. 

Trong trao đổi với khách hàng, đội IaaS gửi ảnh chụp từ dashboard giám sát để giải thích ngưỡng giới hạn đang áp dụng. Khi khách báo suy giảm hiệu năng, chúng tôi kiểm tra lượng yêu cầu được phục vụ có suy giảm hay không. Muốn đánh giá sâu hơn về cô lập, các số đo này phải được đặt cạnh độ trễ và tỷ lệ lỗi của cùng volume, trong cùng khoảng thời gian. 

Một volume vẫn hoàn thành lượng I/O tương đương trước đó nhưng thời gian chờ tăng lên thì ứng dụng vẫn có thể đã bị ảnh hưởng. Kiểm tra hạn mức và kiểm tra độ trễ vì thế phải đi cùng nhau. 

Ở tầng frontend (máy ảo), báo cáo cần IOPS thực tế, thông lượng, phân bố độ trễ, số lỗi, timeout và số lần thử lại. Nếu P99 chỉ tính trên các yêu cầu thành công, phạm vi lấy mẫu phải được công bố kèm tỷ lệ I/O thất bại. Với fio, cần phân tách slat (độ trễ trước khi gửi), clat (độ trễ hoàn thành) và lat (tổng độ trễ). Percentile phải được tính từ mẫu hoặc histogram; lấy trung bình cộng các mẫu độ trễ theo thời gian để suy ra P99 là sai về phương pháp. 

Ở tầng backend (lưu trữ), số liệu phải gắn với nhóm OSD thực sự phục vụ các volume đang kiểm thử: mức sử dụng CPU, I/O thiết bị vật lý, độ trễ xử lý, băng thông mạng, trạng thái PG và lưu lượng recovery/backfill. Số trung bình toàn cụm không thay thế được số đo tại thành phần đang nghẽn. 

Hồ sơ cấu hình đi kèm cần ghi điểm thực thi QoS (hypervisor hay librbd), phạm vi (theo volume hay tenant), loại storage, phiên bản phần mềm và chính sách hàng đợi. Với mClock, phân tích phải dựa trên cấu hình runtime đang hiệu lực tại OSD, không phải giá trị khai báo. Nhà cung cấp có thể ẩn danh khách hàng, nhưng bằng chứng vẫn phải cho phép đối chiếu biến động độ trễ của volume với trạng thái tài nguyên phục vụ nó. 

Chấp nhận mức cô lập dựa trên kết quả phục vụ đồng thời 

Kết quả kiểm thử cần dẫn đến quyết định cụ thể: 

• A chạy riêng không đạt SLO: kiểm tra đường phục vụ và xem hệ thống có đáp ứng nổi đặc tả workload của A không; lúc này chưa có cơ sở quy cho tenant khác. 

• A chạy riêng đạt SLO nhưng suy giảm khi B hoạt động trong ngưỡng cho phép: phân định giữa thiếu năng lực phục vụ đồng thời và lỗi của cơ chế điều phối hoặc thực thi QoS. 

• Cả hai đạt SLO ở trạng thái bình thường nhưng vi phạm trong recovery/backfill: tính lại phần năng lực dự trữ (headroom) cho trạng thái suy giảm và xem lại chính sách tác vụ nền. 

Kết luận về mức cô lập chỉ có hiệu lực trong phạm vi đã kiểm thử: các tenant tham gia, đặc điểm I/O và những điều kiện vận hành đã đưa vào bài đo. Một PoC hai tenant chưa đủ xác nhận mọi tenant trên toàn dịch vụ đều giữ được SLO. Trong phạm vi đó, nếu chất lượng của A chỉ giữ được bằng cách khiến B không còn đáp ứng mức đã thỏa thuận, cơ chế phân bổ chưa giải quyết được bài toán phục vụ đồng thời. vì vậy baseline và bộ chỉ số khi chạy đồng thời phải thu cho cả A lẫn B, như bảng điều kiện yêu cầu. 

Trước khi thay đổi ranh giới tài nguyên, kiến trúc sư cần số đo chỉ ra gốc rễ nằm ở năng lực backend, cơ chế QoS hay một thành phần dùng chung còn ẩn. Số đo đó là cơ sở để chọn giữa tinh chỉnh QoS, bổ sung năng lực và tách tài nguyên, đồng thời là mốc đối chiếu sau khi áp dụng thay đổi. 

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

1. Lập baseline cho các volume quan trọng trước khi cần đến nó. Chọn các volume phục vụ dịch vụ có SLO nội bộ, ghi lại IOPS hoàn thành, thông lượng và P95/P99 ở cả giờ thấp điểm lẫn cao điểm từ số liệu giám sát sẵn có. 

2. Rút đặc tả I/O thật của ứng dụng từ chính số liệu đó: phân bố I/O size, tỷ lệ read/write, queue depth, số volume active cùng lúc. Đây là bộ số để điền vào bốn nhóm ngưỡng ở trên để phân biệt một PoC đo đúng workload của anh chị với một PoC chạy công cụ bằng tham số mặc định. 

3. Gửi nhà cung cấp bảng bảy điều kiện kèm ngưỡng đã điền: hỏi rõ điều kiện nào họ có số liệu sẵn, điều kiện nào cần dựng lab chung, và thống nhất điểm đo cùng cửa sổ tính percentile. 

4. Sau khi thống nhất cam kết, đưa lên dashboard giám sát P95/P99 theo volume đặt cạnh IOPS hoàn thành của chính volume đó, và đặt cảnh báo cho tổ hợp “P99 vượt baseline trong khi lượng I/O của mình không tăng”, vì đó là dấu hiệu sớm của ảnh hưởng từ bên ngoài volume. Khi có cảnh báo, hãy yêu cầu nhà cung cấp chuỗi số liệu hai phía trong cùng khoảng thời gian như mục bằng chứng đã nêu. 

Vũ Văn Quang 

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