Làm sao để máy ảo không “giành giật” tài nguyên của nhau?
Bạn đã bao giờ gặp cảnh Host ESXi vẫn còn dư 40% CPU nhưng các máy ảo (VM) bên trong lại giật lag chưa? Với dân quản trị ảo hóa, nỗi sợ lớn nhất không phải là server sập, mà là hệ thống chạy “rùa bò” mà không rõ nguyên nhân. Vấn đề thường không nằm ở phần cứng thiếu hụt, mà ở cách chúng ta phân bổ tài nguyên chưa hợp lý.
Hồi mới chuyển từ lab cá nhân sang quản trị cụm vSphere doanh nghiệp, mình từng mắc sai lầm kinh điển: Over-provisioning. Mình cứ nghĩ tống thật nhiều vCPU vào là máy ảo sẽ mạnh. Kết quả là chỉ số CPU Ready Time tăng vọt trên 15%, các VM tranh giành tài nguyên khủng khiếp và cả hệ thống đình trệ. Bài viết này mình sẽ mổ xẻ cách dùng Shares, Reservations, Limits để bạn không đi vào vết xe đổ đó.
Bối cảnh: Tại sao cấu hình mặc định là chưa đủ?
Mặc định, vSphere chia sẻ tài nguyên khá công bằng theo kiểu “ai đến trước, phục vụ trước”. Tuy nhiên, thực tế không phải VM nào cũng quan trọng như nhau. Một Database Server phục vụ hàng ngàn user chắc chắn phải được ưu tiên hơn một Print Server hay Web Test.
Nếu bỏ qua việc cấu hình, bạn sẽ sớm đối mặt với hiện tượng “Noisy Neighbor” (Hàng xóm ồn ào). Chỉ cần một VM bị lỗi loop CPU hoặc bị DDoS, nó sẽ kéo sập hiệu suất của tất cả các VM khác đang chạy chung trên Host đó.
Kích hoạt vũ khí hạng nặng: vSphere DRS
Để quản lý tài nguyên hiệu quả, bạn cần vCenter Server và các Host ESXi được gom vào một Cluster. Đặc biệt, hãy bật vSphere DRS (Distributed Resource Scheduler). Tính năng này giúp vCenter tự động di lý (vMotion) các VM từ Host đang quá tải sang Host rảnh hơn.
- Truy cập vSphere Client, chọn Cluster của bạn.
- Vào mục Configure, chọn vSphere DRS.
- Nhấn Edit và chuyển trạng thái sang On.
Lưu ý nhỏ: Nếu bạn dùng ESXi bản Free, bạn vẫn chỉnh được Shares/Limits cho từng VM nhưng sẽ thiếu đi khả năng cân bằng tải tự động của Resource Pools.
Mổ xẻ bộ ba: Shares, Reservations và Limits
Hiểu rõ bản chất ba thông số này là chìa khóa để làm chủ hiệu suất hệ thống.
1. Reservations (Mức cam kết tối thiểu)
Đây là lượng tài nguyên mà ESXi cam kết giữ riêng cho VM. Nếu Host không còn đủ 2GB RAM để đáp ứng mức Reservation bạn đặt, VM đó sẽ không thể khởi động.
Lời khuyên: Chỉ đặt Reservation cho các ứng dụng cực kỳ nhạy cảm như SQL Server hoặc Oracle. Đừng lạm dụng cho mọi VM vì nó sẽ làm mất đi khả năng “over-commit” – ưu điểm lớn nhất của ảo hóa.
2. Limits (Mức trần tối đa)
Limits là giới hạn cứng. Dù Host có đang rảnh rỗi 90%, VM cũng không được phép dùng quá con số này.
Cảnh báo: Mình cực kỳ hạn chế đặt Limit cho RAM. Khi VM chạm trần RAM, ESXi sẽ ép nó dùng cơ chế swap dữ liệu xuống ổ cứng. Lúc này, tốc độ truy xuất sẽ giảm từ nano giây (RAM) xuống mili giây (Disk), khiến VM gần như treo cứng.
3. Shares (Độ ưu tiên tương đối)
Shares chỉ có tác dụng khi xảy ra tranh chấp tài nguyên (Contention). Khi Host bị nghẽn, VM nào có số Shares cao hơn sẽ được ưu tiên xử lý trước.
Ví dụ, nếu bạn đặt VM Database là High và VM Web là Normal, khi CPU quá tải, Database sẽ được cấp tài nguyên gấp đôi Web. Đây là cách điều tiết thông minh nhất vì nó không gây lãng phí khi hệ thống rảnh rỗi.
Tối ưu Disk I/O với Storage I/O Control (SIOC)
Đừng chỉ nhìn vào CPU/RAM. Disk I/O mới là nút thắt cổ chai phổ biến nhất khiến hệ thống bị khựng. Khi một VM chạy quét virus, nó có thể chiếm hết băng thông ổ cứng, đẩy latency (độ trễ) lên trên 50ms, làm các VM khác đứng hình.
Hãy bật Storage I/O Control (SIOC) trên Datastore để giải quyết vấn đề này:
- Vào danh sách Datastores, chọn Datastore mục tiêu.
- Vào Configure -> General.
- Tại Datastore Capabilities, bật Storage I/O Control.
Sau khi bật, hãy chỉnh Shares cho ổ cứng của từng VM. Với các DB Server, mình thường để Shares mức 2000, trong khi các server phụ chỉ để 500 hoặc 1000.
Đọc các chỉ số “biết nói” qua esxtop
Để biết thiết lập có hiệu quả không, bạn cần nhìn vào số liệu thực tế. Hãy SSH vào Host và gõ lệnh esxtop.
- Nhấn ‘c’ xem CPU: Chú ý cột %RDY. Nếu con số này > 10%, VM của bạn đang “xếp hàng” quá lâu. Hãy giảm bớt vCPU của các VM khác hoặc tăng Shares cho nó.
- Nếu %MLMTD > 0: VM đang bị kẹt bởi chính mức Limit bạn đặt. Hãy nới lỏng giới hạn nếu VM đang chậm.
- Nhấn ‘m’ xem RAM: Nhìn cột SWCUR. Nếu số này lớn hơn 0, VM đang phải swap dữ liệu ra đĩa. Bạn cần cấp thêm RAM ngay lập tức.
Kiểm tra nhanh bằng PowerCLI
Nếu quản lý hàng trăm VM, bạn không thể check từng cái bằng tay. Đoạn script này sẽ liệt kê nhanh các VM đang bị đặt Limit cứng:
Get-VM | Get-VMResourceConfiguration | Where-Object {$_.CPULimitMhz -ne -1 -or $_.MemLimitMB -ne -1} |
Select-Object VM, CPULimitMhz, MemLimitMB | Format-Table -AutoSize
Quy tắc vàng từ kinh nghiệm thực tế
Sau nhiều năm vận hành, mình đúc kết được vài nguyên tắc sống còn:
- Càng ít vCPU càng tốt: Một VM có 2 vCPU chạy 80% tải thường mượt hơn VM có 8 vCPU nhưng chỉ chạy 10% tải. Điều này giúp giảm áp lực cho bộ lập lịch (CPU Scheduler).
- Ưu tiên Shares thay vì Limits: Hãy để hệ thống tự điều tiết linh hoạt thay vì bóp nghẹt nó bằng các con số cứng nhắc.
- Luôn có khoảng thở cho Host: Đừng bao giờ dùng quá 90% RAM của Host. Hãy để dành ít nhất 10% cho các tiến trình hệ thống của ESXi.
Hy vọng những chia sẻ này giúp bạn tự tin hơn khi tối ưu môi trường ảo hóa. Nếu bạn gặp chỉ số %RDY cao bất thường mà không rõ cách xử lý, hãy để lại bình luận phía dưới nhé!
