How Facebook deals with PCIe faults to keep our data centers running reliably

Meta · 2021 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Data center của Facebook (2021) có hàng triệu linh kiện PCIe (ASIC tăng tốc video và inference, GPU, NIC, SSD), nhiều nhà cung cấp, nhiều bản firmware, chạy các ứng dụng có mức chịu lỗi khác nhau. Lỗi có thể từ phần cứng, firmware hay phần mềm; nhiều lỗi chỉ làm chậm chứ không làm hỏng hẳn.

Thay đổi chính

• Công cụ: PCIcrawler (mã nguồn mở, đọc topology và lỗi AER, xuất JSON cho máy đọc), MachineChecker (đánh giá máy có đủ tiêu chuẩn production không; chạy định kỳ như service trên toàn fleet), dịch vụ parse dmesg và SEL ghi tốc độ lỗi corrected theo các cửa sổ 10 phút tới 1 ngày, FBAR (auto-remediation: rút máy lỗi khỏi production và tạo yêu cầu sửa phần cứng mà không cần người), Scuba để phân tích.
• Phân loại lỗi:
  • Lỗi uncorrected (fatal hay nonfatal): một lần là đủ đánh dấu hỏng; theo Meta thay linh kiện (đôi khi cả bo mạch) là cách hiệu quả nhất.
  • Lỗi corrected: theo định nghĩa không ảnh hưởng chức năng, nhưng tốc độ lỗi vượt ngưỡng thì gây chậm không chấp nhận được với một số ứng dụng. Ngưỡng được xác định bằng cách tương quan lỗi với stall hệ thống trong Scuba, riêng cho từng nền tảng, lưu trong Configerator để chỉnh dễ.
  • Link speed/width bị hạ (chạy 1/2, 1/4, 1/8 mức mong đợi): máy vẫn chạy nên khó thấy nếu không có công cụ tự động; tính tốc độ mong đợi từ khả năng của cả hai đầu link và so với hiện tại. Phần lớn sửa được bằng cắm lại linh kiện, nên thử trước khi đánh dấu hỏng.
• Quy trình theo bậc: cắm lại → nếu cùng linh kiện trên cùng máy lỗi lặp lại quá số lần trong một khoảng thời gian sau số lần cắm lại định trước thì tự đánh dấu hỏng và thay → thay linh kiện không được thì thay bo mạch. Có thể giới hạn khắc phục cho trường hợp đã biết (ví dụ chỉ nâng firmware). Khắc phục thất bại đủ nhiều thì tự tạo ticket sửa kèm vị trí, model, nhà cung cấp.
• Theo dõi xu hướng sửa chữa: một lần, dữ liệu Scuba chỉ ra lỗi hạ link là do một bản firmware của một nhà cung cấp; làm việc với họ để phát hành bản sửa.
• Giới hạn tốc độ (rate limit) ở nhiều chỗ cho khắc phục và sửa chữa, làm lưới an toàn để bug trong code không rút hay huỷ cấp phát hàng loạt máy, gây sự cố.
• Kết quả theo Meta: đã sửa vài nghìn máy và linh kiện; mỗi tuần phát hiện và khắc phục lỗi PCIe trên hàng trăm máy.

Vì sao

• Ở quy mô hàng triệu linh kiện, lỗi lẻ là chuyện thường ngày; chỉ xử lý được bằng phát hiện, phân loại và khắc phục tự động, người chỉ vào khi cần tay thay phần cứng.

Bài học cho SWE

• Lỗi "đã tự sửa" (corrected) vẫn là tín hiệu: theo dõi tốc độ, ngưỡng theo từng nền tảng, xác định ngưỡng bằng tương quan với tác động thật (Observability và monitoring).
• Khắc phục theo bậc từ rẻ tới đắt, ghi lịch sử để nhận ra "kẻ tái phạm" (Tự động hoá vận hành và auto-remediation).
• Mọi automation có quyền rút máy phải có rate limit để một bug không biến thành sự cố toàn fleet; cùng ý với Monzo 2020, Twilio và OpenAI 2018 trong Tự động hoá vận hành và auto-remediation.
• Gom dữ liệu sửa chữa để thấy nguyên nhân chung (một bản firmware) mà từng ca lẻ không lộ ra.

Liên quan

• Cùng công ty: Meta 2014 · Meta 2025 · Meta 2025 · Meta 2026
• Tự động hoá vận hành và auto-remediation · Observability và monitoring