VMware [Lab 10]: vSphere vMotion & Storage vMotion Migrations, Working with Snapshots, Controlling VM Resources

I. MÔ TẢ YÊU CẦU CỦA BÀI LAB
1. Mô tả sơ bộ
Bài thực hành Lab 10 tập trung vào việc làm chủ các công nghệ di chuyển máy ảo không gián đoạn dịch vụ (Zero-Downtime Migration) và kiểm soát tài nguyên chuyên sâu trên nền tảng VMware vSphere 8.0. Thay vì phải tắt máy ảo khi cần bảo trì phần cứng máy chủ hoặc nâng cấp tủ đĩa, bài lab hướng dẫn cách chuyển đổi tài nguyên tính toán qua vSphere vMotion, di chuyển ổ đĩa ảo qua Storage vMotion, quản lý các điểm phục hồi trạng thái hệ thống với Snapshots, và thiết lập chính sách phân bổ CPU/RAM thông qua cơ chế kiểm soát tài nguyên (Shares, Reservations, Limits).

2. Vấn đề kỹ thuật cần giải quyết​

• Gián đoạn dịch vụ khi bảo trì phần cứng vật lý (Scheduled Downtime): Khi cần thay RAM, nâng cấp CPU hoặc reboot máy chủ ESXi, doanh nghiệp không thể tắt hàng chục máy ảo đang phục vụ khách hàng. Cần cơ chế chuyển đổi máy ảo đang hoạt động sang một máy chủ khác mà người dùng cuối không nhận ra (Zero-Downtime).
• Nghẽn hiệu năng I/O hoặc bảo trì nâng cấp tủ đĩa SAN/NAS: Khi một Datastore bị quá tải dung lượng hoặc cần thay thế thiết bị lưu trữ, việc tắt máy ảo để copy hàng trăm GB đĩa ảo gây đình trệ hoạt động nghiêm trọng. Cần giải pháp di chuyển toàn bộ tệp đĩa .vmdk sang vùng nhớ mới khi máy ảo vẫn đang đọc ghi dữ liệu liên tục.
• Rủi ro khi thử nghiệm cập nhật hoặc vá lỗi phần mềm: Khi cài đặt các bản cập nhật hệ điều hành hoặc triển khai tính năng mới, phần mềm có thể gặp lỗi xung đột. Cần một điểm phục hồi tức thời (Point-in-Time State) để rollback hệ thống về trạng thái ổn định trước đó trong vài giây.
• Hiện tượng tranh chấp tài nguyên (Resource Contention / "Noisy Neighbor"): Trong môi trường ảo hóa dùng chung, một máy ảo bị lỗi hoặc chạy tác vụ nặng có thể ngốn sạch 100% CPU/RAM của máy chủ vật lý, khiến các máy ảo quan trọng (Database, Domain Controller) bị tê liệt. Cần cơ chế thiết lập hạn mức trần (Limits), mức cam kết tối thiểu (Reservations) và thứ tự ưu tiên (Shares) rõ ràng.

II. GIẢI PHÁP VÀ TRIỂN KHAI THỰC TẾ​

1. CẤU HÌNH HẠ TẦNG MẠNG VÀ THỰC NGHIỆM vSPHERE vMOTION
vMotion là công nghệ di chuyển tài nguyên tính toán (CPU, RAM, Register state) của máy ảo đang chạy từ ESXi host này sang ESXi host khác thông qua mạng IP mà không làm mất kết nối ứng dụng.
Bước 1.1: Chuẩn bị cổng VMkernel cho lưu lượng vMotion

• Mở vSphere Client -> chọn máy chủ esxi.uyenthy.local -> chọn tab Configure -> mục VMkernel adapters.

• Nhấp vào nút ADD NETWORKING...:
  • Select connection type: Chọn VMkernel Network Adapter -> bấm NEXT.

• Thực hiện tương tự trên các máy chủ còn lại.

• Bản chất kỹ thuật: Lưu lượng vMotion không mã hóa mặc định và truyền tải hàng GB dữ liệu RAM thô trong thời gian ngắn. Việc tách riêng IP Stack và card mạng VMkernel vMotion giúp bảo đảm băng thông cho quá trình di chuyển và tránh làm nghẽn mạng dịch vụ của máy ảo.

Bước 1.2: Kiểm tra tính sẵn sàng trước khi di chuyển

• Đảm bảo cả hai host đích và nguồn cùng kết nối tới Datastore dùng chung: iSCSI-Datastore-01, NFS-Datasore-01.

• Đảm bảo card mạng của máy ảo Ubuntu-Test gắn vào Switch đang hiện diện đồng bộ trên cả 2 host
• SSH vào host esxi, chạy lệnh kiểm tra kết nối tới interface vMotion của host esxi02

Xác nhận kết quả phản hồi thông suốt


Bước 1.3: Chuẩn bị cổng VMkernel cho lưu lượng vMotion

• Bật nguồn máy ảo Ubuntu-Test

• Trên vSphere Client, nhấp chuột phải vào Ubuntu-Test -> chọn Migrate...:

• Select migration type: Chọn Change compute resource only (Máy ảo giữ nguyên vị trí ổ đĩa trên Datastore, chỉ đổi host chạy).

• Select a compute resource: Chọn máy chủ đích esxi03.uyenthy.local (khung Compatibility checks báo trạng thái Compatibility checks succeeded).

• Select networks: Giữ nguyên VM-Network.

• Select vMotion priority: Chọn Schedule vMotion with high priority (recommended) để tốc độ migrate nhanh nhất

• Bấm FINISH.
• Quan sát bảng Recent Tasks: Tiến trình Relocate virtual machine chuyển sang trạng thái Completed với chi tiết Migrating Virtual Machine active state

• Máy ảo đổi host quản lý sang esxi03.uyenthy.local trên cây Inventory
• Cửa sổ dòng lệnh ping -t duy trì liên tục, chỉ có độ trễ tăng nhẹ ở mili-giây cuối khi vCenter đóng băng (freeze) và chuyển giao execution context sang host mới; tỷ lệ mất gói tin đạt chuẩn tuyệt đối: 0% packet loss

2. THỰC NGHIỆM vSPHERE STORAGE vMOTION (STORAGE MIGRATION)
Storage vMotion cho phép di chuyển các tệp đĩa ảo (.vmdk), tệp cấu hình (.vmx) và tệp log của máy ảo sang một Datastore mới mà không cần tắt nguồn máy ảo.

Bước 2.1: Khởi chạy trình di chuyển Storage vMotion

• Nhấp chuột phải vào máy ảo đang chạy Ubuntu-Test -> chọn Migrate...
• 1. Select migration type: Tích chọn Change storage only -> bấm NEXT.

• 2. Select storage:
  • Chọn Datastore đích: Chọn phân vùng.
  • Select virtual disk format: Có thể linh hoạt đổi định dạng đĩa (ví dụ chuyển từ Thick Provision Eager Zeroed sang Thin Provision để tiết kiệm dung lượng lưu trữ).
  • Bấm NEXT.

• 3. Ready to complete: Rà soát thông số -> bấm FINISH.

Bước 2.2: Bản chất kỹ thuật của Storage vMotion​

• Trong suốt quá trình di chuyển:
  1. ESXi sao chép toàn bộ khối dữ liệu tĩnh của đĩa nguồn sang đĩa đích.
  2. Để giải quyết các khối dữ liệu mới sinh ra khi máy ảo vẫn đang hoạt động, ESXi kích hoạt cơ chế vSphere Mirror Driver: Mọi thao tác ghi (Write I/O) của máy ảo được ghi song song xuống cả Datastore cũ và Datastore mới.
  3. Khi đĩa mới được đồng bộ 100%, ESXi chuyển hướng con trỏ đọc/ghi sang đĩa mới và tự động xóa bỏ file đĩa cũ trên Datastore ban đầu.

3. DI CHUYỂN ĐỒNG THỜI COMPUTE VÀ STORAGE
Tính năng này kết hợp đồng thời cả vSphere vMotion (chuyển đổi máy chủ tính toán) và Storage vMotion (chuyển đổi đĩa lưu trữ) trong một thao tác duy nhất khi máy ảo vẫn đang hoạt động (Powered On). Kỹ thuật này thường được áp dụng khi cần di chuyển máy ảo giữa hai cụm hoàn toàn độc lập, tách rời không gian lưu trữ và cụm host tính toán mà không cần chia sẻ chung Datastore ban đầu.

Bước 3.1: Quy trình thực hiện chi tiết trên vSphere Client

• Nhấp chuột phải vào máy ảo đang chạy -> chọn Migrate...
• Tích chọn tùy chọn thứ 3: Change both compute resource and storage -> NEXT

• Chọn máy chủ ESXi đích: Chọn esxi03.uyenthy.local -> Kiểm tra khung Compatibility checks báo trạng thái: Compatibility checks succeeded -> NEXT.

• Chọn Datastore đích -> Select virtual disk format: Có thể giữ nguyên định dạng hoặc chọn Thin Provision để tối ưu dung lượng -> NEXT.

• Chọn Port Group đích tương ứng trên switch -> NEXT

• Tích chọn Schedule vMotion with high priority (recommended) để vCenter ưu tiên cấp phát CPU thực thi nhanh nhất -> NEXT.
• Bấm FINISH

Bước 3.2: Cơ chế hoạt động của Shared-Nothing vMotion

• Quá trình này là sự phối hợp song song của hai cơ chế ngầm:
  1. Đồng bộ dữ liệu đĩa (Storage Phase): ESXi sử dụng vSphere Mirror Driver để sao chép toàn bộ khối dữ liệu đĩa .vmdk từ Datastore nguồn sang Datastore đích. Mọi thao tác ghi mới (Write I/O) của ứng dụng trong lúc copy sẽ được mirror đồng thời sang cả hai Datastore.
  2. Đồng bộ trạng thái bộ nhớ (Compute Phase): Khi đĩa đã sao chép được phần lớn dữ liệu, vCenter kích hoạt cơ chế vMotion: Bơm toàn bộ dữ liệu RAM và CPU state của máy ảo từ ESXi Host nguồn sang ESXi Host đích qua mạng VMkernel vMotion (172.20.11.0/24).
  3. Chuyển giao quyền thực thi (Cut-over Phase): vCenter đóng băng (freeze) máy ảo trong vài mili-giây, chuyển con trỏ đọc ghi sang Datastore mới và kích hoạt máy ảo chạy trên Host mới. Toàn bộ các gói tin mạng được chuyển tuyến tức thời sang cổng mới trên switch phân tán, bảo đảm 0% packet loss.
  4. Dọn dẹp: File đĩa cũ trên Datastore ban đầu tự động được xóa bỏ để giải phóng không gian lưu trữ.

4. LÀM VIỆC VỚI SNAPSHOTS
Snapshot lưu lại trạng thái hệ thống, cấu hình phần cứng và dữ liệu đĩa ảo tại một thời điểm cụ thể phục vụ mục đích thử nghiệm và phòng ngừa rủi ro.

Bước 4.1: Khởi tạo Snapshot

• Nhấp chuột phải vào máy ảo Ubuntu-Test -> chọn Snapshots -> chọn Take Snapshot...

• Cửa sổ cấu hình hiển thị:
  • Name: Nhập Before-Upgrade.
  • Description:
  • Snapshot the virtual machine's memory:
    • Tích chọn: Lưu toàn bộ trạng thái RAM (cho phép khôi phục máy về đúng khoảnh khắc đang chạy).
    • Bỏ chọn: Chỉ lưu trạng thái đĩa (thường dùng trước khi vá các gói phần mềm lớn).

• Bấm CREATE.

• Sau khi tạo snapshot, file đĩa gốc Ubuntu-Test-flat.vmdk bị khóa sang chế độ Read-only.
• Hệ thống sinh ra một file đĩa chênh lệch mới mang tên Ubuntu-Test-000001-delta.vmdk (hoặc -sesparse.vmdk). Mọi thao tác ghi mới của hệ điều hành kể từ thời điểm này sẽ chỉ được ghi vào file Delta.

Bước 4.2: Tạo dữ liệu thử nghiệm và Khởi tạo Snapshot thứ hai

• Mở Console hoặc SSH vào máy ảo Ubuntu-Test, thực hiện tạo thư mục và file dữ liệu thay đổi:

• Tiến hành tạo bản Snapshot thứ hai để ghi nhận mốc thời gian sau khi thay đổi dữ liệu:
  
  • Nhấp chuột phải vào máy ảo -> Snapshots -> chọn Take Snapshot....
  • Name: Nhập After-Update.
  • Description:
  • Bấm CREATE.

• Bản chất kỹ thuật: Hệ thống đóng băng file delta thứ nhất (000001) và tiếp tục sinh thêm file delta thứ hai (Ubuntu-Test-000002-delta.vmdk). Lúc này, cây lịch sử phân nhánh (Snapshot Tree) trong cửa sổ quản trị hiển thị rõ quan hệ phân cấp: Before-System-Upgrade -> After-Folder-Creation -> You are here

Bước 4.3: Thử nghiệm phục hồi trạng thái

• Nhấp chuột phải vào VM -> Snapshots -> chọn Manage Snapshots.
• Trong cây Snapshot Tree, nhấp chọn bản snapshot ban đầu Before-Updade -> bấm REVERT -> xác nhận REVERT.

• Kết quả: Con trỏ You are here nhảy về vị trí Before-Updade. Mở Console máy ảo kiểm tra lại bằng lệnh ls, thư mục test biến mất hoàn toàn.

Bước 4.4: Hợp nhất và xóa Snapshot an toàn

• Trong cửa sổ Manage Snapshots:
  • Nếu chọn xóa từng bản: Chọn snapshot cần xóa -> bấm DELETE.

• Bản chất kỹ thuật: vCenter thực hiện tiến trình hợp nhất (Consolidation): Đọc toàn bộ các block dữ liệu thay đổi trên chuỗi file delta (000001, 000002) và ghi tuần tự vào file đĩa gốc -flat.vmdk, sau đó giải phóng dung lượng và xóa các file delta.
• Cảnh báo vận hành: Không lạm dụng Snapshot quá 72 giờ và không dùng Snapshot thay thế Backup, vì file delta phình to sẽ làm suy giảm nghiêm trọng tốc độ đọc ghi (I/O) và có nguy cơ làm tràn dung lượng Datastore.

5. KIỂM SOÁT TÀI NGUYÊN MÁY ẢO (CONTROLLING VM RESOURCES)
Thực nghiệm này nhằm kiểm chứng cơ chế hoạt động của tham số CPU Shares khi xảy ra hiện tượng tranh chấp tài nguyên (Resource Contention). Bằng cách đặt hai máy ảo cùng chạy trên một ESXi Host, cấu hình một máy nhận mức Shares High và một máy nhận mức Shares Low, sau đó ép cả hai máy chạy hết công suất (100% vCPU), ta sẽ thấy ESXi ưu tiên phân bổ lượng chu kỳ xử lý thực tế (CPU Cycles / MHz) theo đúng tỷ lệ cổ phần đã định.

Bước 5.1: Chuẩn bị 2 máy ảo trên cùng một ESXi Host

• Đảm bảo hai máy ảo kiểm thử đều được đặt nằm trên cùng một máy chủ ESXi.
• Mỗi máy ảo được cấu hình cùng số lượng vCPU bằng nhau (ví dụ: đều có 1 vCPU hoặc 2 vCPU) để kết quả so sánh khách quan và chính xác.

Bước 5.2: Cấu hình CPU Shares
a. Cấu hình máy ảo thứ nhất

• Nhấp chuột phải vào máy ảo -> chọn Edit Settings...
• Mở rộng mục CPU:
  • Tại dòng Shares: Chuyển từ mặc định Normal sang High (giá trị tương ứng là 2000 shares cho mỗi vCPU).
  • Các mục Reservation và Limit: Để mặc định.
• Bấm OK.

a. Cấu hình máy ảo thứ hai

• Nhấp chuột phải vào máy ảo -> chọn Edit Settings...
• Mở rộng mục CPU:
  • Tại dòng Shares: Chuyển từ mặc định Normal sang Low (giá trị tương ứng là 500 shares cho mỗi vCPU).
  • Các mục Reservation và Limit: Để mặc định.
• Bấm OK.

Bước 5.3: Chạy Stress Test đẩy CPU cả 2 máy lên 100%

• Bật nguồn cả hai máy ảo.
• Mở 2 cửa sổ Web Console hoặc SSH đồng thời vào 2 máy ảo bằng tài khoản uyenthy.
• Cài đặt công cụ tạo tải CPU stress

Kích hoạt tải 100% CPU trên cả 2 máy cùng lúc:

• Trên cả 2 máy, chạy lệnh:

Bước 5.4: Quan sát và Xác minh kết quả trên vSphere Client

• Chọn từng máy ảo -> tab Monitor -> Performance:
• Kết quả quan sát thực tế ghi nhận:
  • Tại thời điểm chưa có tranh chấp (Idle/Tải nhẹ):
  • Tại thời điểm cả 2 máy cùng đạt 100% CPU (Xảy ra Contention):
    • ESXi CPU Scheduler phát hiện tổng nhu cầu CPU vượt quá năng lực vật lý của Core/Host.
    • Cơ chế Shares lập tức can thiệp:
      • Máy Ubuntu-Lab (CPU High - 2000 shares) được cấp phát khoảng ~80% lượng chu kỳ xử lý (MHz) thực tế.

• Shares chỉ có giá trị khi có tranh chấp (Contention-only): Khi tài nguyên nhàn rỗi, máy Low vẫn chạy hết tốc lực nếu nó cần. Shares không phải là Limit (không bóp cứng tài nguyên từ đầu).
• Giá trị thực tiễn trong doanh nghiệp: Trong môi trường ảo hóa dùng chung, ta cấu hình mức High Shares cho các máy chủ sản xuất sống còn (Database, Production Web, ERP) và mức Low Shares cho các máy chủ môi trường Dev/Test/Staging. Khi hệ thống quá tải đột ngột, vSphere sẽ tự động hy sinh hiệu năng của môi trường Test để dồn toàn bộ sức mạnh phần cứng phục vụ môi trường Production.

III. KẾT LUẬN

Bài lab số 10 khép lại chuỗi kỹ thuật vận hành trung tâm dữ liệu ảo hóa VMware vSphere:

1. Hiện thực hóa khả năng bảo trì Zero-Downtime: Làm chủ công nghệ vMotion và Storage vMotion, cho phép bảo trì máy chủ vật lý và tủ đĩa lưu trữ hoàn toàn trong suốt với người dùng cuối, duy trì cam kết thỏa thuận mức dịch vụ (SLA) cao nhất cho doanh nghiệp.
2. Quản trị an toàn thay đổi với Snapshots: Hiểu rõ bản chất file Delta Disk và quy trình Consolidation, sử dụng Snapshot đúng mục đích như một điểm tựa an toàn khi nâng cấp phần mềm mà không gây rủi ro suy giảm hiệu năng lưu trữ.
3. Tối ưu hóa và bảo vệ tài nguyên hệ thống: Áp dụng linh hoạt bộ ba tham số Shares, Reservations và Limits, bảo đảm các ứng dụng cốt lõi của doanh nghiệp luôn được cam kết đầy đủ phần cứng, đồng thời cô lập các ứng dụng thử nghiệm để hạ tầng luôn hoạt động ổn định và bền bỉ.