Ngày 7 tháng 10 năm 2025, dịch vụ email của Hostinger gặp gián đoạn do sự cố kỹ thuật trong hạ tầng lưu trữ. Một số người dùng không thể nhận email và truy cập hộp thư. Toàn bộ dữ liệu người dùng vẫn được đảm bảo toàn vẹn trong suốt quá trình xử lý. Báo cáo postmortem kỹ thuật chi tiết được công bố ngày 9 tháng 10 năm 2025.
Chuyện gì đã xảy ra?
Sự cố bắt nguồn từ cụm lưu trữ Ceph. Nguyên nhân gốc là hiện tượng BlueFS allocator fragmentation khi khối lượng thao tác với đối tượng nhỏ (small objects) và ghi metadata tăng đột biến, dẫn tới một số OSD daemon không thể khởi tạo ổn định dù còn dung lượng vật lý khả dụng. Đây là tình huống allocator rơi vào trạng thái cạn khối liên tiếp (contiguous block exhaustion), không phải tình huống “out of disk space” thông thường, khiến OSD lặp lại vòng crash loop.
Timeline sự cố
- 09:17 UTC, 7/10: Hệ thống giám sát (monitoring) phát cảnh báo bất thường từ một OSD node, đội kỹ sư lập tức vào điều tra.
- 09:25: Nhiều OSD bắt đầu flap, hệ thống tạm thời vô hiệu auto-out để tránh rebalance làm tăng tải.
- 09:30: OSD rơi vào crash loop, kiểm tra loại trừ lỗi phần cứng và dung lượng đĩa.
- 10:42–10:45: Log xác nhận lỗi tại lớp BlueStore allocator, đội ngũ thử nhiều biện pháp khôi phục và kiểm tra filesystem, chưa tác động đến người dùng ở thời điểm này.
- 11:00: Kích hoạt Statuspage để cập nhật công khai.
- 13:12: Đưa ra giả thuyết metadata quá phân mảnh, quyết định mở rộng dung lượng cho RocksDB metadata.
- 13:55–15:10: Triển khai bổ sung NVMe device cho các OSD, bắt đầu quá trình migrate RocksDB metadata sang NVMe.
- 16:30: OSD đầu tiên khởi động thành công sau khi migrate, xác nhận hướng khắc phục hợp lệ, tiến hành trên các OSD còn lại.
- 19:17: Cụm Ceph ổn định, bắt đầu đưa dịch vụ trở lại.
- 20:07: Hệ thống email khôi phục đầy đủ, toàn bộ email trong queue bắt đầu được phát tới hộp thư người dùng.
- 00:29 UTC, 8/10: Hoàn tất xử lý backlog, toàn bộ email được deliver thành công.
Ảnh hưởng
- Một số người dùng không thể nhận email đến và truy cập hộp thư trong thời gian khắc phục.
- Không có mất dữ liệu: Ceph vẫn duy trì tính toàn vẹn dữ liệu thông qua replication và journaling. Quá trình khắc phục chỉ tập trung vào di trú và tối ưu metadata, không liên quan đến rebuild dữ liệu người dùng.
Biện pháp khắc phục và cải tiến
- Ưu tiên tính toàn vẹn dữ liệu: mọi thao tác phục hồi được thực hiện theo quy trình thận trọng, xác thực từng bước trước khi rollout diện rộng.
- Giải quyết đúng nút thắt cổ chai (bottleneck): bổ sung NVMe riêng cho RocksDB metadata trên toàn bộ OSD node, cải thiện I/O throughput và giảm tải xử lý metadata.
- Cải thiện giám sát: bổ sung metric theo dõi mức độ fragmentation và tình trạng allocator để phát hiện sớm điều kiện bất thường.
- Minh bạch và chia sẻ: công khai cập nhật trên Statuspage, phát hành báo cáo postmortem kỹ thuật, đồng thời cộng tác với cộng đồng Ceph để chia sẻ kinh nghiệm và đóng góp upstream patch.
Phản ứng từ cộng đồng
Bản postmortem chi tiết và cách quản trị sự cố theo nguyên tắc “data safety first” được cộng đồng đánh giá tích cực. Người dùng ghi nhận việc phục hồi có trình tự, ưu tiên bảo toàn dữ liệu, đồng thời áp dụng cải tiến hạ tầng sau sự cố.
DevOps VietNam facts: Sự cố lưu trữ phân tán không phải lúc nào bắt nguồn từ việc hết dung lượng vật lý, mà nhiều khi xuất phát từ fragmentation trong allocator metadata. Cần giám sát allocator fragmentation và tách metadata sang NVMe ngay từ giai đoạn thiết kế. Một thay đổi đúng điểm nghẽn có thể quyết định tốc độ phục hồi dịch vụ mà không cần đến data rebuild.
