Màn hình đen lúc 2 giờ sáng: Khi máy chủ không thể khởi động
Đó là lúc 2 giờ sáng thứ Ba khi bảng điều khiển giám sát của tôi chuyển sang màu đỏ. Một máy chủ cơ sở dữ liệu production đã được lên lịch cập nhật kernel và khởi động lại định kỳ, nhưng nó không bao giờ phản hồi (ping) lại. Tôi đăng nhập vào bảng điều khiển IPMI và thấy thông báo mà mọi quản trị viên hệ thống đều khiếp sợ: Bạn đang ở chế độ emergency mode. Sau khi đăng nhập, hãy gõ "journalctl -xb" để xem log hệ thống.
Vấn đề là gì? Chỉ là một lỗi đánh máy đơn giản trong file /etc/fstab. Sáng hôm đó, tôi đã thêm một ổ đĩa sao lưu 2TB. Vì tôi không kiểm tra lại dòng lệnh đã nhập, toàn bộ hệ thống đã bị treo trong quá trình khởi động khi không tìm thấy ổ đĩa đó. Đây là thực tế đầy rủi ro trong quản trị Linux. File /etc/fstab là xương sống trong cấu hình lưu trữ của bạn, nhưng chỉ một ký tự đặt sai chỗ cũng có thể khiến toàn bộ hạ tầng của bạn ngoại tuyến.
Tại sao /etc/fstab lại là “điểm yếu chí tử” (Single Point of Failure)
File /etc/fstab (File System Table) cho kernel Linux biết phân vùng nào cần mount và cách xử lý chúng. Trong quá trình khởi động, systemd sẽ đọc file này để xây dựng cây hệ thống file. Nếu một thiết bị được liệt kê bị thiếu hoặc các tham số không chính xác, quá trình khởi động thường sẽ dừng lại. Điều này giúp ngăn hệ thống chạy trong trạng thái không nhất quán hoặc tránh rủi ro hỏng dữ liệu.
Hầu hết các lỗi bắt nguồn từ ba sai lầm phổ biến:
- Tên thiết bị không ổn định: Sử dụng
/dev/sdb1thay vì UUID. Nếu bạn đổi cáp SATA hoặc thêm ổ cứng USB,sdb1có thể trở thànhsdc1, khiến việc mount thất bại. - Vấn đề về thời gian phản hồi mạng: Cố gắng mount một ổ đĩa chia sẻ NFS trước khi ngăn xếp mạng (network stack) được khởi tạo hoàn toàn. Theo mặc định, hệ thống sẽ đợi một phản hồi có thể không bao giờ tới.
- Lỗi cú pháp: Quên một cột hoặc viết sai chính tả tùy chọn mount như
defaults.
Cấu trúc của một dòng trong /etc/fstab
Mọi dòng trong /etc/fstab đều tuân theo cấu trúc sáu cột nghiêm ngặt. Sự chính xác ở đây là bắt buộc.
# <hệ thống file> <điểm mount> <loại> <tùy chọn> <dump> <pass>
UUID=abc-123 /data ext4 defaults 0 2- File System: Đây là mã định danh duy nhất cho phân vùng (UUID là tiêu chuẩn vàng).
- Mount Point: Thư mục nơi ổ đĩa xuất hiện (ví dụ:
/mnt/storage). - Type: Định dạng của ổ đĩa, chẳng hạn như
ext4,xfs, hoặcnfs. - Options: Các thiết lập hành vi cụ thể như
rw(đọc-ghi) hoặcnoexec(ngăn thực thi file thực thi). - Dump: Một cờ sao lưu cũ. Hãy đặt giá trị này là
0. - Pass: Xác định thứ tự kiểm tra
fsck. Sử dụng1cho root,2cho các ổ đĩa vật lý khác, và0cho các ổ đĩa chia sẻ qua mạng.
Tuyệt chiêu chuyên gia: Sử dụng UUID cho lưu trữ cục bộ
Hãy ngừng sử dụng các đường dẫn thiết bị như /dev/sda1. Chúng thay đổi linh hoạt và rất nguy hiểm. Thay vào đó, hãy sử dụng Universally Unique Identifier (UUID), mã này sẽ giữ nguyên ngay cả khi bạn chuyển ổ cứng sang một cổng khác. Tìm UUID của bạn bằng cách chạy lệnh:
lsblk -fDòng cấu hình của bạn sẽ trông như thế này:
UUID=550e8400-e29b-41d4-a716-446655440000 /storage ext4 defaults 0 2Mount ổ đĩa mạng NFS mà không lo treo máy khi khởi động
Các mount NFS nổi tiếng là hay làm hỏng quá trình khởi động. Nếu máy chủ từ xa bị sập, máy khách của bạn có thể đứng ở màn hình trống trong 90 giây (thời gian timeout mặc định) — hoặc thất bại hoàn toàn. Để giữ cho hệ thống của bạn ổn định, hãy sử dụng các cờ _netdev và nofail.
_netdev: Buộc hệ thống phải đợi cho đến khi mạng hoạt động trước khi cố gắng mount.nofail: Cho phép hệ thống hoàn tất khởi động ngay cả khi thiếu ổ đĩa.
# Mount NFS an toàn
192.168.1.50:/exports/data /mnt/nfs_share nfs defaults,_netdev,nofail 0 0Tăng hiệu suất với Tmpfs
Nếu ứng dụng của bạn ghi hàng nghìn file tạm thời nhỏ, như dữ liệu session hoặc cache, đừng lãng phí chu kỳ ghi của SSD. Hãy sử dụng tmpfs để lưu trữ các file đó trong RAM. Điều này có thể giảm độ trễ đáng kể và kéo dài tuổi thọ cho phần cứng của bạn.
# Mount /tmp vào RAM với giới hạn 2GB
tmpfs /tmp tmpfs rw,size=2G,nodev,nosuid 0 0Nguyên tắc vàng: Đừng bao giờ khởi động lại mà không kiểm tra
Sau khi quản lý một đội ngũ hơn 50 máy chủ Linux, tôi đã học được rằng việc khởi động lại ngay sau khi chỉnh sửa fstab là một trò cá cược. Bạn có thể xác minh các thay đổi của mình một cách an toàn trong khi hệ thống vẫn đang chạy. Đầu tiên, hãy unmount ổ đĩa mục tiêu, sau đó chạy:
sudo mount -aLệnh này hướng dẫn hệ thống thử mount mọi mục được liệt kê trong /etc/fstab. Nếu có lỗi cú pháp hoặc UUID không chính xác, bạn sẽ thấy thông báo lỗi ngay lập tức trong shell hiện tại. Nếu lệnh không trả về kết quả gì, cấu hình của bạn là hợp lệ và bạn có thể an tâm khởi động lại.
Khôi phục: Thoát khỏi chế độ Emergency Mode
Nếu bạn thấy mình bị mắc kẹt trong Emergency Mode, đừng hoảng sợ. Việc khắc phục thường chỉ mất hai phút:
- Nhập mật khẩu root để truy cập vào shell.
- Remount phân vùng root dưới dạng đọc-ghi:
mount -o remount,rw / - Mở file:
nano /etc/fstab. - Vô hiệu hóa dòng bạn vừa thêm bằng cách đặt dấu
#ở đầu dòng. - Lưu, thoát và gõ
reboot.
Tóm tắt các tùy chọn mount khuyến nghị
| Loại lưu trữ | Tùy chọn khuyến nghị |
|---|---|
| SSD/HDD nội bộ | defaults |
| Ổ cứng USB ngoài | defaults,nofail |
| Chia sẻ NFS/Samba | _netdev,nofail,x-systemd.automount |
| Dữ liệu nhạy cảm | defaults,nosuid,nodev,noexec |
Làm chủ /etc/fstab không chỉ là về việc mount ổ đĩa; đó là về việc xây dựng một hệ thống có thể tồn tại qua những sự cố phần cứng nhỏ. Bằng cách ưu tiên UUID, sử dụng nofail cho các phân vùng không quan trọng và luôn kiểm tra bằng mount -a, bạn có thể đảm bảo máy chủ của mình luôn trực tuyến — ngay cả khi có sự cố xảy ra lúc 2 giờ sáng.
