VMware [Module 8]: Di chuyển máy ảo với vSphere vMotion và Storage vMotion, tạo Snapshots, kiểm soát tài nguyên CPU/RAM

I. Mở đầu
Trong công tác vận hành vSphere thực tế, ba phân mảng phát sinh nhiều sự cố ngầm nhất chính là: Migration (Di trú), Snapshot (Ảnh chụp trạng thái) và Resource Allocation (Phân bổ tài nguyên). Di trú thất bại thường do vướng cơ chế kiểm tra tương thích phần cứng; snapshot lạm dụng quá lâu sẽ làm suy giảm nghiêm trọng hiệu năng I/O của storage; còn tài nguyên CPU/RAM nếu cấu hình sai lệch có thể khiến một máy ảo đơn lẻ kéo sập hiệu năng của cả cụm cluster.

Báo cáo này phân tích chuyên sâu ba trục kỹ thuật then chốt:
  1. Bản chất, điều kiện tương thích và mô hình chi phí của vMotion và Storage vMotion.
  2. Cơ chế ghi đĩa (Copy-on-write delta), phân loại và các giới hạn kỹ thuật của Snapshot.
  3. Bộ ba điều phối tài nguyên tính toán gồm Reservation, Limit và Shares cùng cách phối hợp thực tế trong môi trường sản xuất.

II. Nội dung

1. vMotion và Storage vMotion: Bản chất và Cơ chế vận hành
Cả vMotion và Storage vMotion đều thuộc nhóm công nghệ "Live Migration" - di chuyển máy ảo khi dịch vụ và hệ điều hành khách vẫn đang hoạt động liên tục mà không gây gián đoạn (zero downtime). Điểm khác biệt cốt lõi nằm ở đối tượng tài nguyên được di dời.
1791530277891.png

1.1. So sánh bản chất kỹ thuật​

  • vMotion (Compute Migration): Di dời trạng thái thực thi trong bộ nhớ (vRAM) và chu kỳ tính toán (vCPU) của máy ảo từ host ESXi nguồn sang host ESXi đích. VM được hủy đăng ký ở host cũ và đăng ký lại ở host mới. Toàn bộ tệp đĩa ảo trên storage giữ nguyên vị trí.
  • Storage vMotion (Storage Migration): Di dời toàn bộ tệp tin của máy ảo (tệp đĩa .vmdk, file cấu hình .vmx, file snapshot) từ Datastore nguồn sang Datastore đích. Máy ảo vẫn tiếp tục chạy trên chính host ESXi hiện tại.
  • Shared-Nothing vMotion (Cross-Host and Cross-Datastore): Kết hợp cả hai thao tác trên cùng lúc. Thích hợp khi bảo trì toàn diện hoặc di chuyển máy ảo giữa các cụm cluster không chia sẻ chung storage.

1.2. Yêu cầu tương thích của vMotion​

vMotion đặt ra các tiêu chuẩn nghiêm ngặt về phần cứng và đường truyền:
  • Tương thích CPU (EVC - Enhanced vMotion Compatibility): Vi xử lý giữa host nguồn và đích phải tương thích về tập lệnh. Nếu hai thế hệ CPU quá xa nhau, vMotion sẽ bị chặn ngay tại bước kiểm tra tương thích (Compatibility Check). Kích hoạt tính năng EVC ở cấp độ Cluster sẽ chuẩn hóa tập lệnh của tất cả các host về một thế hệ CPU cơ sở chung, cho phép vMotion an toàn qua lại giữa các đời máy chủ khác nhau.
  • Băng thông mạng VMkernel: Lưu lượng vMotion truyền qua cổng VMkernel chuyên dụng. vSphere hỗ trợ mạng 1GbE hoặc 10GbE/25GbE trở lên. Khuyến cáo thực tế là sử dụng đường truyền tối thiểu 10GbE kết hợp tính năng Multi-NIC vMotion để rút ngắn thời gian đồng bộ vRAM.
  • Shared Storage: Trong vMotion tiêu chuẩn, cả host nguồn và host đích bắt buộc phải truy cập đồng thời vào cùng một Datastore chứa máy ảo (qua Fibre Channel, iSCSI hoặc NFS).

1.3. Yêu cầu và giới hạn của Storage vMotion​

  • Chế độ đĩa (Disk Mode): Đĩa ảo phải ở chế độ Persistent hoặc đĩa RDM chế độ ảo (Virtual Compatibility Mode). Không hỗ trợ RDM ở chế độ vật lý (Physical Mode).
  • Quyền truy cập host: Host ESXi đang chạy máy ảo bắt buộc phải mount và nhìn thấy được cả Datastore nguồn lẫn Datastore đích.
  • Hạn chế kích thước và phiên bản: Các đĩa ảo dung lượng lớn hơn 2TB không thể di trú từ VMFS5/VMFS6 sang VMFS3 (do VMFS3 không hỗ trợ địa chỉ hóa đĩa trên 2TB).
  • Trạng thái hệ thống: Không thực hiện Storage vMotion khi máy ảo đang cài đặt hoặc nâng cấp dở dang VMware Tools.
  • Chuỗi Snapshot dày đặc: Nếu máy ảo đang mang nhiều snapshot phức tạp, Storage vMotion sẽ chạy rất chậm và tiêu tốn nhiều tài nguyên I/O. Cần thực hiện gom đĩa (Consolidate) trước khi di trú storage.

1.4. Mô hình chi phí tài nguyên và giới hạn tác vụ đồng thời (Concurrency Limits)​

vCenter kiểm soát tài nguyên hệ thống thông qua mô hình chi phí định mức (Resource Cost). Mỗi tác vụ di trú tiêu hao một lượng điểm chi phí nhất định; khi tổng chi phí chạm ngưỡng tối đa (Maximum Cost Limit), các tác vụ tiếp theo sẽ phải nằm trong hàng đợi (Queued):

Tài nguyên hệ thốngTrọng số vMotionTrọng số Storage vMotionGiới hạn tối đa (Max Limit)
Host ESXi (Toàn bộ tác vụ)1 điểm4 điểm8 điểm / Host
Giao diện mạng (NIC 10GbE)1 điểmKhông áp dụng8 điểm / NIC
Datastore nguồn / đích1 điểm16 điểm128 điểm / Datastore

Ý nghĩa thực tế: Một host ESXi có hạn mức tối đa là 8 điểm. Do đó, một host chỉ có thể chạy tối đa:
  • 8 tác vụ vMotion đồng thời (8x1=8); hoặc
  • 2 tác vụ Storage vMotion đồng thời (2x4=8); hoặc
  • 1 Storage vMotion (4 điểm) kết hợp với 4 vMotion (4+4=8 điểm).

1.5. Quy trình thực hiện di trú qua vSphere Client​

  • Nhấp chuột phải vào máy ảo -> chọn Migrate.
  • Chọn loại hình di chuyển:
    • Change compute resource only (vMotion).
    • Change storage only (Storage vMotion).
    • Change both compute resource and storage (Shared-Nothing vMotion).
  • Chỉ định đối tượng đích (Host/Cluster đích hoặc Datastore/Storage DRS Cluster đích).
  • Đối với Storage vMotion: Cho phép đổi định dạng đĩa ảo (Same format as source, Thin Provision, Thick Provision).
  • Kiểm tra panel Compatibility để xác nhận không có cảnh báo đỏ, chọn độ ưu tiên (High Priority hoặc Normal Priority) và nhấn hoàn tất.

2. Kỹ thuật quản trị Snapshot máy ảo

2.1. Bản chất cơ học của Snapshot​

Snapshot lưu lại toàn bộ trạng thái hệ thống và dữ liệu của máy ảo tại một thời điểm xác định.
Cơ chế hoạt động của Snapshot dựa trên nguyên lý Copy-on-write biến thể:
  • Ngay khi lệnh tạo Snapshot được kích hoạt, tệp đĩa gốc (-flat.vmdk) được chuyển sang trạng thái chỉ đọc (Read-only).
  • vSphere tạo ra một tệp đĩa con dạng delta (-000001-delta.vmdk hoặc SESPARSE disk). Toàn bộ các thao tác ghi mới (Write I/O) từ hệ điều hành khách sẽ được chuyển hướng hoàn toàn vào tệp delta này.
  • Khi có nhiều snapshot kế tiếp nhau, một chuỗi phân cấp (Snapshot Chain) được hình thành. Khi đọc dữ liệu (Read I/O), hypervisor phải đọc ngược từ tệp delta mới nhất về tệp gốc nếu khối dữ liệu đó chưa bị ghi đè.

2.2. Hai chế độ chụp Snapshot​

1791530737077.png

  • Memory Snapshot (Chụp bộ nhớ RAM): vSphere tạo một tệp .vmsn có kích thước bằng dung lượng RAM cấp phát cho máy ảo để kết xuất (dump) toàn bộ bộ nhớ. Khi hoàn tác (Revert), máy ảo sẽ quay trở lại ngay lập tức trạng thái đang chạy mà không cần khởi động lại OS. Đổi lại, thời gian tạo snapshot lâu hơn và có thể phát sinh hiện tượng nghẽn tạm thời (stun time) khi vSphere ghi dữ liệu RAM xuống storage.
  • Quiesced Snapshot (Đóng băng tạm thời hệ thống tệp): Yêu cầu bắt buộc phải cài đặt VMware Tools. ESXi gửi chỉ thị cho VMware Tools gọi dịch vụ VSS (Volume Shadow Copy Service) trên Windows hoặc script trên Linux để tạm ngừng các tiến trình ứng dụng, xả toàn bộ dữ liệu bẩn từ cache RAM xuống đĩa cứng trước khi tạo delta disk. Chế độ này bảo đảm hệ thống tệp đạt trạng thái nhất quán ứng dụng (Application-consistent), tối ưu cho các tác vụ backup cơ sở dữ liệu.
Lưu ý: Hai tùy chọn Memory Snapshot và Quiesced Snapshot loại trừ lẫn nhau (mutually exclusive). Quản trị viên chỉ được chọn một trong hai.

2.3. Các giới hạn kỹ thuật và rủi ro vận hành​

  • VMware chính thức khuyến cáo: Tuyệt đối không sử dụng Snapshot như một giải pháp sao lưu (Backup) dài hạn.
    • Không hỗ trợ: Đĩa vật lý thô (Raw Device Mapping - Physical Mode), đĩa độc lập (Independent-Persistent hoặc Independent-Nonpersistent), và các máy ảo sử dụng PCI Passthrough (DirectPath I/O).
    • Hạn chế đĩa lớn: Với các đĩa ảo dung lượng trên 2TB, thời gian tạo và xóa snapshot kéo dài hơn đáng kể.
    • Suy giảm hiệu năng nghiêm trọng: Càng để snapshot lâu, tệp delta càng phình to (có thể bằng kích thước đĩa gốc). Chuỗi snapshot càng sâu, chỉ số IOPS càng giảm và độ trễ đọc/ghi càng tăng vọt. Ngoài ra, tệp delta phình to ngoài tầm kiểm soát có thể làm cạn kiệt dung lượng Datastore, khiến toàn bộ máy ảo trên Datastore đó bị treo cưỡng bức. Thời gian lưu giữ snapshot an toàn trong thực tế là không quá 24 đến 72 giờ.

2.4. Xóa và Hợp nhất Snapshot​

  • Delete vs. Delete All: Xóa một snapshot hoặc xóa toàn bộ chuỗi snapshot sẽ kích hoạt tiến trình ghi dồn (commit/merge) dữ liệu từ các tệp delta vào đĩa cha hoặc đĩa gốc -flat.vmdk, sau đó giải phóng dung lượng.
  • Mirror Driver: Từ vSphere 6.0 trở lên, VMware sử dụng driver dạng mirror để ghi song song các thay đổi phát sinh trong quá trình xóa snapshot, giúp tiến trình hợp nhất diễn ra trơn tru mà không làm đứng máy ảo.
  • Snapshot Consolidation: Đôi khi, tiến trình xóa snapshot hoàn tất nhưng file delta vẫn bị khóa hoặc hệ thống báo lỗi không xóa hết file rác trên Datastore. Giao diện vSphere Client sẽ hiện cảnh báo Virtual machine disks consolidation is needed. Lúc này, kỹ sư nhấp chuột phải vào máy ảo -> chọn Snapshots -> Consolidate để vCenter quét lại và gộp dứt điểm các chuỗi tệp delta còn sót lại.

3. Kiểm soát tài nguyên tính toán: Reservation, Limit và Shares
Để tránh tình trạng "máy ảo hàng xóm ồn ào" (noisy neighbor) tranh chấp tài nguyên, vSphere xây dựng cơ chế quản lý phân bổ CPU (tính bằng MHz) và RAM (tính bằng MB) dựa trên ba tham số:

Cơ chếĐịnh nghĩaĐơn vị đoThời điểm có hiệu lựcTác động phụ cần lưu ý
ReservationMức tài nguyên tối thiểu được hệ thống cam kết giữ chỗ độc quyền.MHz (CPU) / MB (RAM)Luôn luôn có hiệu lực (kể cả khi rảnh rỗi).Giảm độ linh hoạt của cụm; nếu tổng Reservation vượt quá dung lượng host, VM sẽ không thể bật nguồn.
LimitNgưỡng tài nguyên tối đa máy ảo được phép chạm tới.MHz (CPU) / MB (RAM)Luôn luôn có hiệu lực (áp trần cứng).Đặt Limit quá thấp sẽ bóp nghẹt hiệu năng; đặt Limit cho RAM ép VM phải đẩy dữ liệu ra swap file dù host vẫn còn RAM trống.
SharesTỷ trọng ưu tiên cạnh tranh tài nguyên.Điểm số tương đối (Numeric value)Chỉ có hiệu lực khi xảy ra tranh chấp (Contention).Không có ý nghĩa nếu tài nguyên trên host đang dư dả.

3.1. Cơ chế Reservation​

Nếu gán Reservation 4096 MB RAM cho một máy ảo, ESXi sẽ khóa cứng 4GB RAM vật lý cho máy ảo đó. Dù bên trong hệ điều hành khách chỉ sử dụng 500 MB RAM, 3.5 GB còn lại vẫn không được cấp phát cho bất kỳ máy ảo nào khác trên cùng host.

Reservation bảo vệ tuyệt đối các dịch vụ cốt lõi, nhưng nếu lạm dụng, nó sẽ phá vỡ cơ chế cấp phát vượt ngưỡng của ảo hóa và làm thu hẹp không gian điều phối của tính năng vSphere DRS.

3.2. Cơ chế Limit​

Limit thiết lập một "bức trần" nhân tạo. Ngay cả khi toàn bộ các máy ảo khác trên máy chủ đang ngủ và CPU của host còn dư tới 90%, một máy ảo bị áp Limit 2000 MHz cũng tuyệt đối không được sử dụng vượt quá con số này.

Đối với bộ nhớ, việc đặt Limit thấp hơn lượng RAM cấu hình của máy ảo sẽ buộc ESXi kích hoạt cơ chế hoán đổi đĩa xuống file .vswap, kéo tụt tốc độ đọc ghi của ứng dụng xuống mức báo động.

3.3. Cơ chế Shares​

Shares định nghĩa tỷ lệ phân chia tài nguyên tương đối khi các máy ảo cùng tranh giành CPU hoặc RAM bị quá tải:

Tỷ lệ tài nguyên nhận được = Shares của VMᵢ / ∑(Shares của toàn bộ các VM đang tranh chấp)

Mặc định, vSphere cung cấp ba mức định sẵn:
  • High: 2000 điểm cho mỗi vCPU / 20 điểm cho mỗi MB RAM.
  • Normal: 1000 điểm cho mỗi vCPU / 10 điểm cho mỗi MB RAM.
  • Low: 500 điểm cho mỗi vCPU / 5 điểm cho mỗi MB RAM.
Bản chất: Khi hệ thống bình thường, máy ảo cấu hình Low vẫn chạy hết công suất nếu cần. Nhưng khi CPU của host chạm ngưỡng 100%, máy ảo có Shares mức High sẽ nhận được lượng chu kỳ tính toán gấp đôi máy ảo mức Normal và gấp bốn lần máy ảo mức Low.

3.4. Mô hình phối hợp thực tế trong doanh nghiệp​

1791531201957.png

  • Hệ thống cơ sở dữ liệu sản xuất (Production DB): Đặt Reservation đủ mức tải tối thiểu để tránh bị hoán đổi bộ nhớ; Shares đặt mức High; Limit để Unlimited để sẵn sàng mở rộng khi có tải bùng phát.
  • Ứng dụng trung gian thông thường (App/Web Tier): Không đặt Reservation (hoặc đặt mức thấp); Shares để Normal; Limit để Unlimited.
  • Môi trường thử nghiệm (Dev/Test): Không đặt Reservation; Shares đặt mức Low; cấu hình Limit cụ thể để cô lập hoàn toàn, ngăn chặn các đoạn mã lỗi hoặc vòng lặp vô tận của lập trình viên làm cạn kiệt tài nguyên của hệ thống sản xuất.

III. Tổng kết
Quản trị di trú, ảnh chụp trạng thái và phân bổ tài nguyên là ba mắt xích kiểm soát sự ổn định dài hạn của cụm máy chủ vSphere. Mỗi công cụ mang một sứ mệnh kỹ thuật chuyên biệt:
  • vMotion và Storage vMotion xóa bỏ ranh giới vật lý cứng nhắc của phần cứng và tủ đĩa, cung cấp khả năng bảo trì hạ tầng linh hoạt với độ sẵn sàng cao. Việc tuân thủ cấu hình chuẩn tương thích CPU (EVC) và mô hình chi phí đồng thời là điều kiện tiên quyết để quá trình di trú luôn thông suốt.
  • Snapshot là cứu cánh an toàn ngắn hạn trước các đợt cập nhật phần mềm, vá lỗi hệ thống hay triển khai cấu hình rủi ro. Tuy nhiên, nó đòi hỏi kỷ luật vận hành nghiêm ngặt: phải xóa bỏ hoặc hợp nhất tệp delta trong vòng 24-72 giờ để bảo toàn chỉ số IOPS và dung lượng datastore.
  • Kiểm soát tài nguyên thông qua Reservation, Limit và Shares thể hiện tư duy kiến trúc của người quản trị: biết dùng Reservation để "bảo hộ sàn" cho ứng dụng sống còn, dùng Limit để "khoanh vùng trần" cho môi trường thử nghiệm, và dùng Shares để thiết lập "trật tự ưu tiên" công bằng khi hệ thống xảy ra tranh chấp.
Nắm vững bản chất cơ học phía sau các tính năng này giúp đội ngũ vận hành chuyển từ thế bị động xử lý sự cố sang chủ động kiểm soát rủi ro, duy trì hạ tầng ảo hóa ở trạng thái tối ưu và tin cậy nhất.
 
Back
Top