Tại sao đừng để máy ảo “ngủ quên” sau khi Host reboot?
Làm admin hệ thống, chắc hẳn anh em đã từng nếm trải cảm giác “thốn” khi nhận thông báo server vật lý reboot đột ngột giữa đêm. Nếu host đang gánh 20-30 máy ảo (VM) mà phải log in vào từng con để nhấn Start thủ công thì thực sự là cực hình.
Vấn đề lớn nhất không phải là mệt, mà là thứ tự khởi động. Hãy tưởng tượng Web Server (vị trí số 3) bật lên và cố kết nối tới Database (vị trí số 1) khi Database còn đang load service. Kết quả là ứng dụng báo lỗi 500 trắng xóa màn hình ngay lập tức.
Từ kinh nghiệm vận hành cluster 8 host tại dự án thực tế, mình khẳng định Autostart là tính năng sống còn. Nó giúp chúng ta thiết lập thứ tự ưu tiên (Order) và độ trễ (Delay). Database lên trước, Backend API theo sau, cuối cùng mới là Frontend. Đây chính là quy trình “self-healing” chuẩn để hệ thống tự sống lại mà không cần bạn phải động tay.
Kích hoạt Autostart: Đừng để Host bị “ngộp”
Mặc định, VMware tắt tính năng này để tránh tình trạng tất cả VM cùng ùa lên một lúc. Khi đó, IOPS có thể vọt lên trên 10.000, gây nghẽn đĩa và quá tải CPU ngay lúc Host vừa boot.
Để bắt đầu, anh em thực hiện theo các bước sau:
- Truy cập VMware Host Client qua trình duyệt.
- Chọn mục Manage ở menu trái.
- Vào tab System và tìm đến Autostart.
- Nhấn Edit settings để bắt đầu cấu hình.
Tại bảng này, hãy đặc biệt chú ý 3 thông số then chốt:
- Start delay: Mình thường để 120 giây. Khoảng nghỉ này giúp VM trước đó kịp load xong OS và các dịch vụ nền trước khi con tiếp theo khởi động.
- Wait for heartbeat: Cực kỳ quan trọng. Nếu chọn Yes, ESXi sẽ đợi tín hiệu từ VMware Tools của VM rồi mới kích hoạt máy ảo kế tiếp. Cách này thông minh hơn nhiều so với việc chỉ đếm giây máy móc.
- Stop action: Hãy chọn Shut down. Đừng dùng Suspend nếu bạn muốn dữ liệu được ghi xuống đĩa an toàn.
Thiết lập thứ tự ưu tiên: Ưu tiên “đầu não” lên trước
Sau khi bật tính năng tổng, giờ là lúc bạn phân vai cho từng máy ảo. Không phải con VM nào cũng cần tự bật lại.
Thao tác trên giao diện Web
Trong màn hình Autostart, hãy chọn một VM quan trọng (như con SQL Server) và nhấn Configure.
- Autostart: Chuyển sang Enabled.
- Start order: Số càng nhỏ càng ưu tiên cao. Quy tắc vàng: DB là 1, App là 2, Web/LB là 3.
Mẹo nhỏ: Chỉ nên đưa các VM Production vào danh sách này. Những máy Dev/Test hoặc backup thì cứ để khởi động thủ công để tiết kiệm tài nguyên cho hệ thống lúc vừa hồi phục.
Dành cho anh em thích gõ lệnh (Automation)
Nếu bạn phải cấu hình cho cả một dàn Host, dùng SSH sẽ nhanh hơn nhiều. Để xem danh sách và ID của các VM, hãy dùng lệnh:
vim-cmd vmsvc/getallvmsSau đó, kiểm tra chuỗi thứ tự hiện tại bằng:
vim-cmd hostsvc/autostartmanager/get_autostartseqLưu ý “xương máu” khi chạy vCenter và HA Cluster
Đây là điểm mà nhiều anh em hay nhầm lẫn. Nếu Host ESXi nằm trong một Cluster có bật vSphere HA (High Availability), cấu hình Autostart tại cấp độ Host sẽ bị vô hiệu hóa.
Trong môi trường này, vSphere HA Orchestrator mới là bên nắm quyền điều khiển. Khi một host chết, HA sẽ tự động bật lại VM trên host khác. Lúc này, bạn phải vào vCenter, tìm mục VM Overrides hoặc VM Startup Priority để thiết lập thứ tự, thay vì chỉnh trực tiếp trên ESXi lẻ.
Ngoài ra, hãy đảm bảo 100% VM đã cài VMware Tools. Thiếu cái này, ESXi sẽ không nhận được “heartbeat” và toàn bộ quy trình Autostart sẽ bị chậm lại do phải đợi hết thời gian timeout.
Script kiểm tra trạng thái nhanh cho DevOps
Bạn có thể dùng đoạn Python nhỏ này để kiểm tra xem sau khi reboot, các VM đã lên đủ chưa và gửi cảnh báo về Telegram nếu cần:
from pyVim.connect import SmartConnect
import ssl
# Bỏ qua check SSL cho cert tự ký
scontext = ssl._create_unverified_context()
si = SmartConnect(host="192.168.1.100", user="root", pwd="password", sslContext=scontext)
for child in si.RetrieveContent().rootFolder.childEntity:
if hasattr(child, 'vmFolder'):
for vm in child.vmFolder.childEntity:
print(f"VM: {vm.name} -> Status: {vm.runtime.powerState}")Hy vọng những chia sẻ từ thực tế này giúp hệ thống của anh em vận hành trơn tru hơn, bớt cảnh phải “canh đêm” mỗi khi server vật lý dở chứng.
