Cơn ác mộng khi máy chủ bỗng dưng “đứng hình”
Tôi từng quản lý một cơ sở dữ liệu production xử lý hơn 10.000 kết nối đồng thời thì hệ thống đột ngột mất tín hiệu. Không có cảnh báo, không có lỗi “Connection Refused”—chỉ là một sự im lặng đáng sợ. Sau khi reset cứng, tôi lục tìm trong /var/log/messages và /var/log/syslog nhưng không thấy gì cả. Các dòng log kết thúc vào lúc 14:02:15 và chỉ bắt đầu lại từ 14:05:40 sau khi khởi động lại. Ba phút mất tích đó chính là nơi chứa đựng câu trả lời.
Đây chính là sự ức chế mà Kernel Panic mang lại. Khi nhân Linux (kernel) gặp lỗi nghiêm trọng, nó sẽ đóng băng ngay lập tức để bảo vệ dữ liệu của bạn. Vì chính kernel bị hỏng, nó không thể ghi log theo cách thông thường. Bạn sẽ phải tự hỏi liệu bo mạch chủ trị giá 5.000 USD bị hỏng hay chỉ do một dòng code driver bị lỗi gây ra vụ crash. Sau khi quản lý hàng tá hệ thống lưu lượng cao, tôi hiểu rằng bạn không thể sửa những gì bạn không nhìn thấy. Kdump chính là công cụ giúp bạn nhìn thấy những điều đó.
Tại sao log thông thường lại vô dụng khi Kernel gặp sự cố
Để hiểu tại sao cần Kdump, bạn phải nhìn vào cấu trúc của một vụ crash. Khi một ứng dụng thông thường bị lỗi, kernel vẫn khỏe mạnh và sẽ ghi lại một bản core dump. Nhưng khi chính kernel bị crash, “bộ não” của hệ thống ngừng hoạt động. Nó không còn khả năng quản lý chu kỳ CPU hay I/O của đĩa cứng. Việc ghi một dòng log yêu cầu driver hệ thống tệp phải hoạt động. Nếu chính driver đó là nguyên nhân gây crash, việc cố gắng ghi log thậm chí có thể làm hỏng dữ liệu của bạn nặng nề hơn.
Hầu hết các lỗi panic bắt nguồn từ ba nguyên nhân cụ thể:
- Lỗi phần cứng: Một lỗi bit-flip trong thanh RAM 32GB hoặc sụt áp CPU.
- Các Module Kernel bị lỗi: Driver của bên thứ ba cho các card mạng (NIC) chuyên dụng hoặc GPU thường xuyên gây ra vấn đề này.
- Memory Deadlocks: Những tình huống hiếm gặp khi kernel cạn kiệt các cấu trúc bộ nhớ cụ thể cần thiết để duy trì hoạt động.
So sánh các phương pháp thu thập dữ liệu Crash
Tôi đã tìm hiểu nhiều cách để bắt các lỗi này trước khi chọn Kdump. Mỗi phương pháp đều có ưu và nhược điểm, nhưng hầu hết đều không khả thi trong môi trường đám mây hiện đại.
- Serial Console: Bạn kết nối hai máy qua cáp vật lý. Nó cực kỳ ổn định nhưng không thể áp dụng cho một VPS từ xa trong trung tâm dữ liệu cách đó hàng trăm cây số.
- Netconsole: Phương pháp này truyền log kernel qua giao thức UDP. Nó tốt hơn là không có gì, nhưng vì UDP không đảm bảo việc truyền nhận, bạn thường mất đi những gói tin quan trọng nhất—những gói được gửi ngay lúc hệ thống “vừa nằm xuống”.
- Kdump: Đây là tiêu chuẩn vàng. Nó sử dụng kexec để khởi động một “kernel thu thập” (capture kernel) thứ hai ngay sau khi crash. Vì kernel thứ hai này nằm trong một vùng RAM nhỏ đã được dự phòng riêng biệt mà kernel đầu tiên không thể chạm tới, nó vẫn ổn định để lưu lại toàn bộ trạng thái hệ thống (vmcore) vào đĩa cứng.
Thiết lập: Triển khai Kdump đúng cách
Kdump hoạt động mạnh mẽ vì nó không yêu cầu kernel đã bị crash hỗ trợ. Nó thay thế toàn bộ môi trường điều hành bằng một môi trường mới trong khi vẫn giữ nguyên bộ nhớ cũ để bạn điều tra. Đây là cách tôi cấu hình trên AlmaLinux, CentOS hoặc Ubuntu.
Bước 1: Cài đặt kexec-tools
Bạn cần gói kexec-tools để tải một kernel mới mà không cần thông qua quá trình khởi tạo phần cứng BIOS/UEFI đầy đủ.
# Dành cho RHEL/AlmaLinux/Fedora
sudo dnf install kexec-tools -y
# Dành cho Debian/Ubuntu
sudo apt update && sudo apt install kexec-tools -yNgười dùng Ubuntu: bạn có thể sẽ thấy một thông báo hỏi có muốn tự động bật Kdump hay không. Chọn ‘Yes’ để hệ thống tự xử lý các cấu hình dịch vụ cơ bản.
Bước 2: Cấp phát bộ nhớ cho Crash Kernel
Đây là bước mà hầu hết các cấu hình thường thất bại. Kernel thu thập cần RAM riêng biệt của nó. Mặc dù crashkernel=auto là một tùy chọn, tôi thấy nó không đáng tin cậy trên các hệ thống có RAM dưới 4GB. Tôi thích đặt một giá trị cố định như 256M.
Trên các hệ thống dựa trên RHEL, sử dụng tiện ích grubby để cập nhật các tham số khởi động:
sudo grubby --update-kernel=ALL --args="crashkernel=256M"Trên Ubuntu, bạn cần chỉnh sửa thủ công file /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash crashkernel=256M"Bạn phải khởi động lại máy ngay bây giờ. Hệ thống không thể dự phòng vùng bộ nhớ này khi kernel chính đang sử dụng nó.
sudo update-grub # Chỉ dành cho Ubuntu
sudo rebootBước 3: Xác định vị trí lưu bản Dump
Bây giờ, hãy cho Kdump biết nơi lưu file vmcore. Cấu hình này nằm trong /etc/kdump.conf (RHEL) hoặc /etc/default/kdump-tools (Ubuntu).
Đường dẫn mặc định là /var/crash//. Nếu phân vùng root của bạn gần đầy, hãy cân nhắc trỏ nó sang một ổ đĩa phụ. Một máy chủ RAM 64GB về lý thuyết có thể tạo ra file dump 64GB, mặc dù việc nén file sẽ giúp giảm dung lượng đáng kể.
Kiểm tra xem dịch vụ đã hoạt động chưa:
# Kiểm tra trạng thái trên RHEL
kdumpctl status
# Kiểm tra trạng thái trên Ubuntu
kdump-config statusNếu kết quả hiển thị “ready to kdump” hoặc “operational”, lưới bảo hiểm của bạn đã sẵn sàng.
Bước 4: Kích hoạt Panic thủ công để kiểm tra
Đừng đợi đến khi thảm họa thực sự xảy ra mới xem cấu hình có chạy không. Chúng ta có thể ép hệ thống crash bằng phím Magic SysRq. Cảnh báo: Việc này sẽ làm sập máy chủ của bạn ngay lập tức. Chỉ thực hiện việc này trong thời gian bảo trì đã lên lịch.
sudo sync
echo 1 | sudo tee /proc/sys/kernel/sysrq
echo c | sudo tee /proc/sysrq-triggerHệ thống sẽ treo, sau đó khởi động lại. Khi bạn đã truy cập lại được, hãy kiểm tra /var/crash/. Bạn sẽ thấy một thư mục có đóng dấu thời gian chứa file vmcore. Nếu nó ở đó, bạn đã thiết lập thành công.
Bước 5: Giải mã Vmcore
vmcore là một bản chụp nhị phân của RAM. Để đọc nó, bạn cần tiện ích crash và các ký hiệu gỡ lỗi (debug symbols) cho phiên bản kernel cụ thể của mình.
sudo dnf install crash -y
# Mở bản dump (đường dẫn sẽ thay đổi tùy theo mốc thời gian của bạn)
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/2023-10-27-10:30/vmcoreBên trong dấu nhắc crash>, hãy chạy lệnh log. Lệnh này sẽ in ra bộ đệm tin nhắn nội bộ của kernel. Hãy tìm những dòng cuối cùng; chúng thường chứa thông báo “Oops” và hàm cụ thể gây ra lỗi.
Những lời khuyên đắt giá từ thực tế
Tôi từng mất một tuần để truy tìm một “lỗi phần cứng” mà hóa ra lại là một bug nhỏ trong driver của card RAID. Kdump đã tìm ra nó trong năm phút. Nếu không có file vmcore đó, chúng tôi đã thay thế hàng ngàn đô la thiết bị phần cứng hoàn toàn bình thường.
Hãy ghi nhớ ba mẹo sau:
- Theo dõi dung lượng đĩa cứng: Sử dụng tùy chọn
core_collector makedumpfile -d 31trong cấu hình của bạn. Lệnh này sẽ loại bỏ các trang trống (zero pages) và bộ nhớ đệm (caches), thường giúp thu nhỏ bản dump 16GB xuống chỉ còn khoảng 300MB. - Cập nhật Kernel: Bất cứ khi nào bạn cập nhật kernel, hãy kiểm tra lại xem Kdump có còn hoạt động tốt không. Hầu hết các bản phân phối sẽ tự động hóa việc này, nhưng chạy lệnh
kdumpctl statussau khi cập nhật sẽ giúp tránh những bất ngờ không đáng có. - Kiểm tra khả năng nén: Nếu máy chủ của bạn có 128GB RAM, hãy đảm bảo phân vùng lưu crash có thể chứa được dữ liệu đã nén.
Bằng cách chuyển từ việc đoán mò sang gỡ lỗi dựa trên dữ liệu, bạn có thể xử lý các sự cố nghiêm trọng nhanh hơn và duy trì thời gian uptime hệ thống ở mức cao nhất.
