Nâng cấp kernel Azure làm hỏng khởi động MongoDB do không tương thích rseq

Một buổi sáng bình thường đã biến thành sự cố khẩn cấp cho một nhóm phát triển khi ứng dụng của họ ngừng phản hồi mà không có bất kỳ thay đổi nào về mã nguồn hay cấu hình gần đây. Nguyên nhân gốc rễ được xác định là do việc nâng cấp kernel Linux tự động được thực hiện bởi Azure trong một cửa sổ bảo trì, dẫn đến xung đột với instance MongoDB đang chạy.

Chuyện gì đã xảy ra

Sự cố bắt đầu khi người dùng báo cáo các lỗi kết nối, thúc đẩy nhóm kỹ thuật điều tra trạng thái máy ảo Azure của họ. Khi đăng nhập, họ phát hiện dịch vụ MongoDB ở trạng thái lỗi, thoát ngay lập tức sau các lần thử khởi động với mã thoát cho thấy thất bại nhanh chóng trong vòng 35 đến 48 mili giây. Các log ứng dụng tiêu chuẩn không cung cấp thông tin hữu ích, chỉ hiển thị một lần tắt sạch sẽ từ nhiều ngày trước đó, buộc nhóm phải tìm hiểu sâu hơn vào các journal cấp hệ thống.

Bằng cách lọc journal hệ thống để tìm các lỗi nghiêm trọng (fatal errors), nhóm đã phát hiện một thông báo lỗi cụ thể stating rằng MongoDB không thể khởi động trên các phiên bản kernel Linux 6.19 trở lên do một vấn đề không tương thích đã biết. Nền tảng Azure đã âm thầm nâng cấp kernel của VM lên phiên bản 7.0.0-1014-azure, vốn dựa trên dòng kernel 6.19+ gây ra vấn đề. Điều này kích hoạt một khối an toàn cứng nhắc trong MongoDB phiên bản 8.0.29, ngăn chặn cơ sở dữ liệu khởi động để tránh nguy cơ hỏng hóc dữ liệu hoặc mất ổn định liên quan đến lệnh gọi hệ thống rseq.

Chi tiết chính

• Nguyên nhân: Azure tự động nâng cấp kernel Linux trên VM trong một cửa sổ bảo trì theo lịch trình.
• Không tương thích: MongoDB 8.x từ chối khởi động trên kernel Linux 6.19 trở lên do các vấn đề với lệnh gọi hệ thống rseq.
• Xác định lỗi: Vấn đề được xác nhận qua log journalctl, không phải qua log ứng dụng MongoDB tiêu chuẩn.
• Các biện pháp khắc phục thất bại: Thay đổi quyền file, xóa file khóa và nâng cấp MongoDB lên phiên bản 8.0.32 đều không giải quyết được vấn đề.
• Giải pháp: Nhóm đã khởi động vào một kernel cũ hơn, tương thích (6.17.0-1022-azure) bằng cách sửa đổi cấu hình GRUB.
• Phòng ngừa: Các gói kernel đã được ghim (pinned) bằng cách sử dụng apt-mark hold để ngăn chặn các nâng cấp tự động trong tương lai cho đến khi có bản vá chính thức.

Bối cảnh

Hệ thống Linux sử dụng một bootloader gọi là GRUB (Grand Unified Bootloader) để chọn phiên bản kernel cần tải khi máy chủ khởi động. Các nhà cung cấp đám mây như Azure thường cài đặt các kernel mới trong quá trình bảo trì nhưng vẫn giữ lại các phiên bản cũ trên đĩa. Theo mặc định, GRUB chọn kernel mới nhất, điều này có thể dẫn đến hành vi không mong muốn nếu kernel mới có vấn đề tương thích với phần mềm đã cài đặt. Lệnh gọi hệ thống rseq (restartable sequences) là một tối ưu hóa hiệu suất trong các kernel Linux mới hơn mà một số ứng dụng, bao gồm cả MongoDB, có thể chưa hỗ trợ đầy đủ hoặc xung đột ở các phiên bản cụ thể.

Trình quản lý gói như apt sử dụng các meta-package như linux-azure để trỏ tới image kernel mới nhất khả dụng. Khi các meta-package này được cập nhật, hệ thống sẽ cài đặt kernel mới nhất và cập nhật GRUB để khởi động nó theo mặc định. Quản trị viên có thể ghi đè hành vi này bằng cách chỉ định thủ công phiên bản kernel trong cấu hình GRUB hoặc bằng cách "giữ" (hold) các gói cụ thể để ngăn chúng được cập nhật tự động.

Tại sao điều này quan trọng

Sự cố này nhấn mạnh rủi ro của việc phụ thuộc vào các bản cập nhật hạ tầng tự động mà không có giám sát đầy đủ hoặc quy trình kiểm soát thay đổi. Đối với các nhóm chạy phần mềm tự lưu trữ (self-hosted), một bản nâng cấp kernel âm thầm có thể phá vỡ các dịch vụ quan trọng qua đêm, dẫn đến thời gian chết đáng kể và nỗ lực khắc phục sự cố. Việc thiếu khả năng hiển thị ngay lập tức đối với các thay đổi cấp hạ tầng có nghĩa là các sự cố có thể trông bí ẩn, lãng phí thời gian quý báu vào các bước gỡ lỗi không liên quan như kiểm tra quyền hạn hoặc log ứng dụng.

Hơn nữa, nó nhấn mạnh tầm quan trọng của việc hiểu chuỗi phụ thuộc giữa các thành phần hệ điều hành và phần mềm ứng dụng. Ngay cả các phiên bản cơ sở dữ liệu ổn định, hỗ trợ dài hạn cũng có những ràng buộc cứng nhắc về phiên bản kernel. Nếu không quản lý chủ động các bản cập nhật kernel, các tổ chức có nguy cơ gặp phải các khối tương tự khi các nhà cung cấp đám mây đẩy các phiên bản OS nền mới. Điều này đặc biệt liên quan đến các công ty vừa và nhỏ có thể không có đội ngũ kỹ sư độ tin cậy trang web (SRE) chuyên dụng để quản lý các chi tiết cấp thấp này.

Bạn có thể làm gì

• Giám sát phiên bản kernel: Thường xuyên kiểm tra phiên bản kernel đã cài đặt và đang hoạt động trên VM của bạn bằng cách sử dụng uname -r và dpkg --list | grep linux-image.
• Ghim các gói quan trọng: Sử dụng apt-mark hold trên các meta-package kernel để ngăn chặn các bản nâng cấp tự động có thể gây ra xung đột.
• Cấu hình thời gian chờ GRUB: Đặt GRUB_TIMEOUT khác không trong /etc/default/grub để cho phép lựa chọn kernel thủ công trong quá trình khởi động nếu cần.
• Xác minh tính tương thích: Trước khi cho phép cập nhật kernel, hãy kiểm tra ghi chú phát hành (release notes) cho các ứng dụng cốt lõi của bạn (như MongoDB) để tìm các vấn đề không tương thích kernel đã biết.
• Cải thiện cảnh báo: Triển khai giám sát cảnh báo về các lỗi khởi động dịch vụ và lỗi journal hệ thống, không chỉ các kiểm tra sức khỏe cấp ứng dụng.
• Tài liệu hóa các bước khôi phục: Giữ một runbook để hoàn tác phiên bản kernel qua GRUB, bao gồm các lệnh để cập nhật bootloader và khởi động lại an toàn.