Thực tế: Snapshot không đơn giản là ‘chụp ảnh rồi thôi’
Mình đang quản lý một Lab nhỏ với khoảng 15 máy ảo (VM) chạy Proxmox. Đây là nơi mình thường xuyên thử nghiệm từ Docker, K8s đến SQL Server. Không ít lần, chỉ một cú Enter sai trong cấu hình Network đã khiến VM mất kết nối hoàn toàn. Những lúc đó, Snapshot giống như một nút ‘Undo’ thần thánh, giúp mình quay về trạng thái ổn định chỉ trong chưa đầy 30 giây.
Nhưng hãy cẩn thận, Snapshot không phải là Backup. Chụp snapshot khi database đang xử lý 500 transaction/giây mà không có cơ chế bảo vệ là cách nhanh nhất để làm hỏng (corrupt) file dữ liệu. Ngoài ra, việc ‘ngâm’ snapshot quá lâu sẽ khiến Disk Latency tăng vọt. Hệ thống lúc này phải gánh thêm các file Delta, khiến tốc độ xử lý trì trệ thấy rõ.
Chuẩn bị: Cầu nối giữa Host và Guest
Để snapshot thực sự an toàn, Host và Guest cần phải ‘hiểu’ nhau. Nếu thiếu cầu nối, Host sẽ chụp ảnh đĩa một cách mù quáng. Nó mặc kệ hệ điều hành bên trong đang dở dang các tiến trình ghi quan trọng.
1. Cài đặt QEMU Guest Agent
Chỉ mất khoảng 30 giây để cài đặt trên các máy ảo Linux (Ubuntu/Debian):
sudo apt update && sudo apt install qemu-guest-agent -y
sudo systemctl start qemu-guest-agent
sudo systemctl enable qemu-guest-agentSau khi cài, bạn cần bật ‘QEMU Guest Agent’ trong phần Options của VM trên giao diện Proxmox. Nếu dùng virsh, hãy kiểm tra lại file cấu hình XML. Thiếu bước này, tính năng ‘Quiesce’ (tạm dừng ghi đĩa để đảm bảo nhất quán) sẽ hoàn toàn vô tác dụng.
Cấu hình chuyên sâu: Nhất quán dữ liệu và tối ưu hiệu suất
Chiến thuật Snapshot ‘sạch’ (Consistency)
Khi thao tác qua dòng lệnh KVM, hãy luôn thêm flag --quiesce. Lệnh này yêu cầu Guest Agent thực hiện fsfreeze. Nó sẽ tạm dừng mọi hoạt động ghi, đẩy sạch dữ liệu từ RAM xuống storage rồi mới chụp. Kết quả là bạn có một bản sao hoàn hảo, an toàn cho cả các ứng dụng nhạy cảm như MySQL hay PostgreSQL.
virsh snapshot-create-as --domain my-vm-name \
--name "pre-update-snapshot" \
--description "Chụp trước khi nâng cấp web server" \
--live --quiesceXử lý Snapshot Chain: Khi ‘phanh’ ổ đĩa bị mòn
Mỗi snapshot QCOW2 tạo ra một file delta mới. Hãy tưởng tượng bạn có 10 bản snapshot, dữ liệu sẽ bị phân mảnh qua 10 lớp file khác nhau. Trong các bài test thực tế, một VM có chuỗi snapshot dài trên 5 lớp có thể bị giảm từ 20% đến 30% tốc độ đọc ghi (IOPS).
Nguyên tắc vàng của mình: **Luôn xóa hoặc Merge snapshot trong vòng 48-72 giờ**. Snapshot chỉ dùng để thử nghiệm nhanh. Nếu mọi thứ đã ổn định, hãy dùng blockcommit để gộp dữ liệu về file gốc, giải phóng tài nguyên cho hệ thống:
# Gộp dữ liệu từ snapshot vào đĩa gốc một cách an toàn
virsh blockcommit my-vm-name vda --active --pivot --verboseLưu ý đặc biệt với ZFS trên Proxmox
ZFS là một ‘quái vật’ về hiệu suất nhờ cơ chế Redirect-on-Write. Việc snapshot diễn ra gần như tức thời. Tuy nhiên, nó cực kỳ ngốn dung lượng nếu VM có biến động dữ liệu lớn, ví dụ như các server ghi log liên tục vài GB mỗi ngày.
- Mẹo nhỏ: Luôn kiểm tra dung lượng Pool bằng lệnh
zpool list. Đừng để Pool vượt quá 80% dung lượng, nếu không hiệu suất ZFS sẽ giảm thảm hại.
Giám sát và Phục hồi: Luôn ở thế chủ động
Đừng đợi đến khi máy lỗi mới kiểm tra snapshot. Mình thường dùng một script đơn giản để liệt kê các bản snapshot ‘hết hạn’ (quá 3 ngày) để dọn dẹp định kỳ.
# Kiểm tra danh sách snapshot hiện có
virsh snapshot-list --domain my-vm-nameTrên Proxmox, hãy quan sát tab Snapshots. Nếu thấy ‘cây’ snapshot bắt đầu phân nhánh chằng chịt, đó là tín hiệu báo động. Bạn nên Rollback về bản chuẩn nhất hoặc xóa bớt các nhánh phụ để tối ưu không gian lưu trữ.
Quy trình Rollback an toàn
Khi sự cố xảy ra, lệnh sau sẽ đưa hệ thống về trạng thái an toàn trong tích tắc:
virsh snapshot-revert --domain my-vm-name --snapshotname pre-update-snapshotNgay sau khi phục hồi, hãy kiểm tra các dịch vụ cốt lõi như Nginx hay Database. Nếu bạn đã tuân thủ việc dùng --quiesce khi chụp, tỷ lệ lỗi dịch vụ sau khi rollback gần như bằng không. Làm chủ được kỹ thuật này, mình tự tin hơn hẳn khi triển khai các thay đổi lớn trên hệ thống mà không lo sợ sự cố bất ngờ.
