Increasing Magic Pocket write throughput by removing our SSD cache disks

Dropbox · 2022 · 4. Điều chỉnh · Độ khó: Nâng cao — bài gốc

Bối cảnh

2017: Magic Pocket dùng ổ SMR (mật độ cao, nhưng nổi tiếng chậm khi ghi ngẫu nhiên). Mọi lượt ghi trực tiếp đi vào SSD làm write-back cache, ack ngay, rồi một tiến trình nền dồn xuống SMR thành ghi tuần tự.
Mật độ tăng (ổ 14–20 TB, >100 ổ mỗi host, 1,5–2 PB/host) nhưng mỗi host chỉ có một SSD, nên SSD thành trần throughput ghi. Ngay cả NVMe (15–20 Gbps) cũng thấp hơn nhiều so với tổng throughput của hàng trăm ổ đĩa.
Đầu 2020: nhiều SSD hỏng cùng lúc. Chúng được lắp cùng đợt, cùng mẫu ghi, nên cùng chạm giới hạn độ bền ghi một lúc, kéo theo một lượng sửa dữ liệu khổng lồ (rủi ro độ bền dữ liệu, dù cuối cùng không mất gì).
Thêm chi phí vận hành: mỗi thế hệ phần cứng phải kiểm định SSD, dự báo nguồn cung riêng; trung bình 8–10 SSD hỏng mỗi tháng.

Ý tưởng từ Hack Week 2021: bỏ hẳn SSD, ghi thẳng xuống SMR.
Storage engine vốn đã tổ chức block thành extent 1–2 GB chỉ ghi nối tiếp, hợp với SMR. Họ chỉ cần đổi định dạng extent: metadata của block được ghi chung (inline) với dữ liệu; khi khởi động thì quét extent để dựng index trong RAM.
Bỏ các workflow quản lý SSD trong control plane (format, phân vùng, phát hiện SSD hỏng).
Kiểm chứng: công cụ giả lập crash, ghi dở, bit rot để kiểm tra khả năng khởi động lại; chạy thử trên traffic nền trước; rollout dần từng nhóm host. Xong toàn fleet vào Q1/2022.

Load test ở đỉnh: throughput ghi gấp 2–2,5 lần, p95 ghi tốt hơn 15–20%.
Production (chạy dưới đỉnh): throughput ghi toàn fleet +15–20% mà không thêm máy.
Đánh đổi chấp nhận:
- p95 ghi ở chặng cuối xuống đĩa tăng 10–15% (SMR chậm hơn SSD), nhưng chỉ làm tổng latency ghi end-to-end tăng ~2%;
- bỏ cache đọc trong RAM cho block mới ghi, nên đọc block mới chậm hơn. p99 không bị ảnh hưởng đáng kể; nếu cần thì thêm lại cache.
Bỏ được một điểm hỏng chung, giảm số lần sửa phần cứng, đơn giản hoá thiết kế phần cứng.

Theo Dropbox: một quyết định đúng năm 2017 (SSD để bù cho SMR) đã thành nút thắt và thành điểm hỏng khi mật độ ổ tăng.

Một thành phần đúng ở mật độ này có thể thành nút thắt ở mật độ khác: thông số phần cứng thay đổi, kiến trúc phải xem lại.
Thiết bị cùng đợt, cùng tải sẽ hỏng cùng lúc. Dư thừa từ các bản giống hệt nhau không phải dư thừa thật.
Bỏ bớt một thành phần là một dạng tối ưu: đơn giản hơn, rẻ hơn, ít điểm hỏng hơn.
Đo cả latency end-to-end, không chỉ một chặng, để đánh giá đúng đánh đổi.