Bài 04 — Cluster, vMotion, HA, DRS (Capstone)

Đây là bài cuối cùng của chặng — gắn tất cả lại với nhau. Bài 01-03 bạn đã có ESXi, vCenter, Network, Storage. Giờ là lúc dạy cụm hệ thống tự vận hành:

• VM tự di chuyển giữa các host (vMotion)
• VM tự restart khi host die (HA)
• Cluster tự cân bằng tải (DRS)
• Snapshot/clone/template làm lifecycle dễ dàng

Đây là phần biến VMware từ "tốt hơn server vật lý" thành "infrastructure thật sự thông minh". Sau bài này, bạn sẽ hiểu vì sao enterprise sẵn sàng trả license vSphere Enterprise Plus đắt đỏ.

Bài chia 5 phần lớn:

• A. VM Lifecycle: Template, Clone, Content Library
• B. Migration: vMotion, Storage vMotion, Cross-vCenter, EVC
• C. Snapshot & Replication
• D. Resource Management: CPU/RAM, Reservation/Limit/Share
• E. Cluster, HA, DRS

---

Phần A — VM Lifecycle: Template, Clone, Content Library

4 view chính trong vSphere Client

Trước khi đi vào lifecycle, recap nhanh navigation vSphere Client. Bên trái có 4 inventory view ứng với 4 icon:

┌─────────────────────────────────────────────────┐
│  vSphere Client                                  │
│  ┌──┬──┬──┬──┐                                  │
│  │🖥│📦│💾│🌐│   ← 4 icon                         │
│  └──┴──┴──┴──┘                                  │
│   1  2  3  4                                     │
└─────────────────────────────────────────────────┘

Icon	View	Hiển thị
1. Hosts and Clusters	🖥	Datacenter → Cluster → Host → VM. Dùng khi quản lý hardware, resource.
2. VMs and Templates	📦	Datacenter → Folder → VM/Template. Dùng khi quản lý VM theo logic (department, app).
3. Storage	💾	Datacenter → Datastore Cluster → Datastore. Dùng khi quản lý storage.
4. Networking	🌐	Datacenter → Network/vSwitch. Dùng khi quản lý network.

→ Cùng 1 VM hiển thị ở cả 4 view, chỉ khác cách tổ chức.

Khi đọc tài liệu hoặc video tutorial, để ý người ta đang ở view nào — context khác nhau hoàn toàn.

---

4 cách tạo VM (recap)

Đã nhắc qua Bài 01, recap:

1. Tạo VM mới từ ISO — slow, dùng cho VM đầu tiên.
2. Deploy từ OVA/OVF — file đóng gói có sẵn.
3. Clone từ VM hiện tại — copy VM đang chạy.
4. Deploy từ Template — chuẩn nhất cho production.

3 cách sau nhanh hơn 100x so với cài từ ISO.

---

Template — VM chuẩn để nhân bản

Template là một máy ảo chuẩn (đã cài OS, đã update, đã hardening, đã optimize) — dùng làm "khuôn" để clone ra nhiều VM cùng spec.

Workflow

1. Tạo VM mới (từ ISO)
   - Cài OS
   - Update patch
   - Cài VMware Tools
   - Cài common tool (vim, curl, htop...)
   - Disable unnecessary service
   - Hardening (firewall, SSH key, etc.)
        │
        ▼
2. Convert VM → Template
   (VM không chạy được nữa, chỉ làm template)
        │
        ▼
3. Deploy nhiều VM mới từ template:
   - VM-Web-01 (giống template)
   - VM-Web-02 (giống template)
   - VM-DB-01  (giống template)
   - ...
        │
        ▼
4. Mỗi VM chỉ cần customize riêng:
   - Hostname
   - IP
   - Hostname-specific config

Convert giữa VM và Template

   ┌─────────────┐    Convert to Template    ┌──────────────┐
   │  VM thường  │────────────────────────►│  Template    │
   │  (chạy được)│                          │ (không chạy) │
   └─────────────┘◄─────────────────────────└──────────────┘
                    Convert to VM
   
   ┌─────────────┐    Clone to Template     ┌──────────────┐
   │  VM thường  │────────────────────────►│  Template    │
   │  (giữ nguyên)│      (tạo bản copy)     │ (mới)        │
   └─────────────┘                          └──────────────┘

• Convert to Template — VM hiện tại biến thành template (không clone, chuyển kiểu).
• Convert to VM — template trở lại thành VM bình thường để sửa.
• Clone to Template — tạo template mới, giữ VM gốc.

Workflow update template

Template cần update (vd: security patch tháng 9):

1. Template → Convert to VM
2. Power on VM → vào update patch
3. Shutdown VM
4. VM → Convert to Template

Hoặc Clone to Template từ VM đã update → giữ template cũ làm version trước.

File của Template

Template có file riêng:

• <name>.vmtx — template config (thay vì .vmx của VM).
• Disk file .vmdk + -flat.vmdk — vẫn vậy.

---

Guest OS Customization

Tính năng cho phép tự động thay đổi sau khi deploy từ template:

• Computer name (hostname)
• Network (IP, DNS, gateway)
• Windows Security Identifier (SID) — quan trọng cho domain join
• License key (Windows)

Đây là magic của template-based deployment — clone xong tự setup hostname/IP, không cần vào tay từng VM.

Setup

vCenter → Menu → Policies and Profiles → VM Customization Specifications
   → New Specification
   → Choose Linux/Windows
   → Fill in: computer name pattern, network config, etc.

Sau đó, khi deploy VM từ template, có option "Customize this VM" → chọn spec đã tạo → apply.

Deploy template "Linux-CentOS-9-base" → 10 VM
  Each VM:
    Computer name:  web-01, web-02, ..., web-10 (auto increment)
    IP:             192.168.32.101, .102, ..., .110
    Gateway:        192.168.32.1
    DNS:            192.168.32.10

→ 30 phút deploy 10 VM thay vì 5 tiếng cài tay từng máy.

---

Content Library

Content Library là kho chứa OVA/OVF/template/ISO chia sẻ giữa nhiều vCenter.

                Content Library Master (Datacenter A)
                          │
                ┌─────────┼─────────┐
                ▼         ▼         ▼
            vCenter A  vCenter B  vCenter C
             (Hà Nội)  (Sài Gòn)  (Singapore)
                
   Mọi vCenter pull về cùng template, ISO, OVA

3 loại library

Loại	Vai trò
Local Library	Chỉ vCenter local thấy. Storage nằm trên datastore.
Published Library	Local library + publish ra ngoài (sites khác subscribe).
Subscribed Library	Subscribe vào Published Library → auto-sync content.

Workflow

1. Tạo Local Library ở vCenter chính → upload template/ISO/OVA vào.
2. Convert thành Published Library → có URL public.
3. Tại vCenter khác: tạo Subscribed Library, trỏ vào URL → auto pull content về.

→ Update template ở 1 chỗ → tự sync ra mọi vCenter.

Use case: Multi-region company muốn 1 chuẩn template chung. Update 1 chỗ, mọi region nhận được.

---

Chỉnh sửa VM — Hot Add / Hot Plug

Có thể chỉnh hardware mà không cần tắt VM (gọi là "hot add"). Nhưng có giới hạn:

Hardware	Tăng nóng (VM chạy)?	Giảm nóng?
CPU	✅ (cần bật Hot Plug + OS support)	❌ phải tắt VM
RAM	✅ (cần Hot Plug + OS support)	❌ phải tắt VM
Disk	✅ tăng dung lượng	❌ không giảm được
Network Card	✅ thêm/bớt thoải mái	✅

⚠️ Bật Hot Plug:

• Trong VM Settings → CPU/Memory → Hot Plug → Enable.
• Phải bật TRƯỚC khi power on lần đầu — đang chạy thì không bật được.
• Guest OS phải support (modern Windows/Linux đều OK).

Disk tăng nóng

Tăng disk size ở vCenter:

VM → Edit Settings → Disk → tăng từ 50GB → 100GB

⚠️ Chưa xong! Cần vào trong guest OS để extend partition + filesystem:

# Linux
sudo growpart /dev/sda 1
sudo xfs_growfs /          # XFS
# hoặc resize2fs /dev/sda1  # ext4

# Windows
diskmgmt.msc → Extend Volume

Đây là lỗi kinh điển — admin tăng disk ở vCenter, nghĩ là xong, vào VM thấy vẫn cũ.

---

Remove vs Delete VM

2 thao tác rất khác nhau:

• Remove from Inventory — chỉ xóa VM khỏi vCenter, file vẫn còn trên datastore. Có thể re-register sau.
• Delete from Disk — xóa sạch file trên datastore. Không khôi phục.

→ Luôn double-check trước khi click Delete. Sai = mất VM.

---

Phần B — Migration: vMotion

vMotion — "phép thuật" của VMware

vMotion là tính năng chuyển máy ảo từ host này sang host khác mà VM vẫn đang chạy.

Đây là feature đỉnh của VMware — đã hơn 15 năm, vẫn là chuẩn mực cho moving workload.

Demo lần đầu thấy vMotion

Mình demo cho 1 khách lần đầu:

• VM Linux đang ping 8.8.8.8 liên tục trong console.
• Click chuột → Migrate → chọn host khác → Finish.
• 30 giây sau, VM đã chạy trên host khác.
• ping không mất gói nào.

Khách: "Mày làm trò gì vậy? VM ở đâu vậy?"

Đó là moment "wow" kinh điển. Trước vMotion, muốn move app phải tắt — downtime. vMotion = zero downtime move.

---

2 loại migration

Theo trạng thái VM:

• Hot migration — VM đang chạy.
• Cold migration — VM đã tắt.

Theo cái gì được di chuyển:

• Compute (vMotion) — chuyển VM từ host này sang host khác. Storage không đổi.
• Storage (Storage vMotion) — chuyển file VM từ datastore này sang datastore khác. Host không đổi.
• Compute + Storage — chuyển cả host lẫn datastore cùng lúc.

---

vMotion (Compute) — cơ chế

1. VM đang chạy trên Host A (RAM, CPU active)
   Storage: shared datastore
        │
        ▼
2. Click Migrate → Host B
        │
        ▼
3. ESXi bắt đầu copy RAM của VM
   (Pre-copy phase, multiple rounds)
   
   Round 1: Copy toàn bộ RAM (chậm)
   Round 2: Copy các page đã thay đổi từ round 1
   Round 3: Copy page đã thay đổi từ round 2
   ...
   (Đến khi delta page < threshold)
        │
        ▼
4. Switchover (~1 second pause):
   - Freeze VM trên Host A
   - Copy nốt RAM còn lại
   - Resume VM trên Host B
        │
        ▼
5. VM tiếp tục chạy trên Host B
   (network connection vẫn giữ, qua VMkernel port vMotion)

Key insight: vMotion KHÔNG copy disk — chỉ copy memory state. Disk phải dùng chung (shared datastore).

Yêu cầu vMotion

• Shared datastore — cả 2 host phải thấy datastore của VM.
• VMkernel port với vMotion enabled trên cả 2 host.
• Network 10Gb+ cho vMotion VMkernel (cho VM RAM lớn).
• CPU compatibility — CPU 2 host phải tương thích (hoặc dùng EVC, xem dưới).
• License vSphere với vMotion — Standard trở lên.

Khi nào dùng vMotion?

• Maintenance host — move VM đi để bảo trì.
• Performance — host quá tải, move sang host rảnh.
• Hardware refresh — chuyển VM sang server mới mà không downtime.
• Patching ESXi — update, rồi move VM về.

---

Storage vMotion — chuyển datastore

Storage vMotion chuyển file VM từ datastore này sang datastore khác mà VM vẫn chạy.

Cách hoạt động

VM trên Host A, datastore Old
        │
        ▼
1. Click Storage Migrate → datastore New
        │
        ▼
2. ESXi copy folder VM:
   - .vmx → New
   - -flat.vmdk → New  (chunk bằng chunk)
   - .nvram, .log → New
        │
        ▼
3. Mirror Driver kích hoạt:
   - Mọi write từ VM được mirror ra CẢ datastore Old + New
   - Đảm bảo data luôn sync giữa 2 bên trong quá trình copy
        │
        ▼
4. Khi copy xong + 2 bên giống nhau:
   - Switch VM sang dùng datastore New
   - Xóa file ở datastore Old
        │
        ▼
5. VM tiếp tục chạy, file đã ở New

Thời gian phụ thuộc:

• Kích thước disk VM.
• Tốc độ đọc của datastore Old + tốc độ ghi của datastore New (chậm nhất quyết định).
• VM disk activity (nếu app ghi nhiều, mirror tốn thêm thời gian).

Có thể chuyển luôn dạng disk

Trong wizard Storage vMotion, có option:

• Same format — giữ nguyên.
• Thin Provision — convert sang thin.
• Thick Provision Eager Zeroed — convert sang thick eager.
• Thick Provision Lazy Zeroed — convert sang thick lazy.

→ Cách convert disk type không cần tắt VM.

Use case Storage vMotion

• Storage retire — di tản VM trước khi tắt SAN cũ.
• Performance migration — chuyển từ HDD sang SSD datastore.
• Capacity balancing — datastore A đầy, move sang B.

---

Cross-vCenter vMotion

Move VM giữa 2 vCenter khác nhau (không chỉ giữa các host trong 1 vCenter).

Điều kiện

• Enhanced Linked Mode (ELM) giữa 2 vCenter (Bài 02).
• Network L2 stretched hoặc dùng NSX giữa 2 site.
• Storage: shared cross-site hoặc dùng cả Storage vMotion.

Use case

• Datacenter migration — di chuyển workload từ DC A sang DC B.
• Hybrid cloud — move VM giữa on-prem vCenter và VMware Cloud on AWS.
• DR failover — move VM sang DR site khi disaster.

---

EVC — Enhanced vMotion Compatibility

Vấn đề: vMotion yêu cầu CPU 2 host phải tương thích. Nếu host cũ có CPU Intel Xeon E5 (cũ) và host mới có Xeon Gold (mới hơn) → vMotion fail vì CPU instruction set khác nhau.

Giải pháp: EVC — feature giả lập CPU đời thấp hơn cho toàn cluster.

Cluster có:
   Host A: Intel Xeon Gold (Cascade Lake)    ← mới
   Host B: Intel Xeon E5 v4 (Broadwell)      ← cũ

Bật EVC cluster, chọn level "Broadwell":
   → Host A "che" các CPU feature mới hơn Broadwell
   → Cả 2 host expose cùng feature set
   → vMotion OK

Cách bật EVC

Cluster → Edit → VMware EVC
   → Enable EVC for Intel
   → Choose CPU mode: chọn đời CPU thấp nhất trong cluster
   → Save

⚠️ Hạ chế: mất các CPU instruction mới (AVX-512, etc.) → VM không dùng được performance feature mới.

→ Đánh đổi: vMotion compatibility ↔ performance optimization. Production thường chấp nhận trade-off này.

---

Phần C — Snapshot & Replication

Snapshot là gì

Snapshot là chụp nhanh trạng thái hiện tại của máy ảo. Khi xảy ra sự cố, rollback về trạng thái lúc snapshot.

⚠️ Snapshot KHÔNG phải backup. Quan trọng đến mức phải lặp lại.

Snapshot có thể chụp 3 thứ

1. Cấu hình VM (luôn có) — .vmx state.
2. Trạng thái memory (RAM) — tùy chọn, snapshot khi VM đang chạy. Cần thêm dung lượng = RAM của VM.
3. Trạng thái ổ cứng — snapshot disk (luôn có).

Tạo snapshot khi VM running:
  ✅ Memory snapshot → có thể rollback về trạng thái RAM
     (tốn dung lượng = RAM, slower create)
  
Tạo snapshot khi VM off:
  Memory snapshot không áp dụng (VM không có state)
  Chỉ disk snapshot

File của snapshot

Khi tạo snapshot, các file mới xuất hiện trong folder VM:

[datastore]/web-server/
  ├── web-server.vmx                  (config gốc, KO đổi)
  ├── web-server-flat.vmdk             (disk gốc, chuyển sang READ-ONLY)
  ├── web-server.vmdk                  (disk descriptor gốc)
  ├── web-server-Snapshot1.vmsn       ← config state khi snap
  ├── web-server-Snapshot1.vmem       ← memory state (nếu chọn)
  ├── web-server-000001.vmdk          ← descriptor snapshot 1
  ├── web-server-000001-delta.vmdk    ← DATA THAY ĐỔI sau snap 1
  └── ...

Quan trọng:

• File -delta.vmdk (VMFS5) hoặc -sesparse.vmdk (VMFS6) chứa toàn bộ thay đổi sau khi snapshot.
• Disk gốc -flat.vmdk chuyển sang read-only.
• Mọi write mới đi vào delta file.

Cơ chế Copy-On-Write

Trước snapshot:
   VM ──ghi──► -flat.vmdk (RW)
   
Sau snapshot:
   VM ──ghi──► -000001-delta.vmdk (RW, mới)
                     │
                     ▼
            -flat.vmdk (READ-ONLY)
            (giữ nguyên trạng thái lúc snap)
   
   Đọc data block X:
     - Block X có trong delta? → đọc từ delta
     - Không? → đọc từ -flat.vmdk gốc

Snapshot chuỗi (chain)

Nếu tạo nhiều snapshot:

Snap 1: VM ─► 000001-delta ─► flat (RO)
        
Snap 2: VM ─► 000002-delta ─► 000001-delta (RO) ─► flat (RO)
        
Snap 3: VM ─► 000003-delta ─► 000002-delta (RO) ─► 000001-delta (RO) ─► flat (RO)

Mỗi snapshot mới = thêm 1 mắt xích. Đọc data đi qua nhiều file → chậm dần.

Rủi ro của snapshot

1. Chuỗi dài = chậm. Sau 5 snapshot, VM I/O chậm 30-50%.

2. Mắt xích hỏng = không power on được VM. Lỗi 1 delta file → cả chain broken.

3. Đầy disk datastore. Snapshot phình to theo thời gian (mọi write tích lũy). 1 VM 100GB có thể tạo snapshot 50GB sau 1 tuần.

4. Memory snapshot tốn dung lượng. VM 32GB RAM → snapshot tốn thêm 32GB.

Quy tắc vàng

• Không quá 3 snapshot/VM cùng lúc.
• Không giữ snapshot > 72 giờ. Dùng xong xóa.
• KHÔNG snapshot Domain Controller (Windows AD) — gây inconsistent USN, mất sync domain.
• KHÔNG snapshot DB transactional mà không quiesce (DB phải biết để flush log).

Xóa snapshot

Khi xóa snapshot, ESXi:

1. Merge delta file vào snapshot trước đó (hoặc disk gốc).
2. Xóa delta file.
3. VM tiếp tục chạy với chuỗi ngắn hơn.

Trước: VM ─► snap3 ─► snap2 ─► snap1 ─► flat
Xóa snap1:
  - Merge snap1-delta vào flat
  - Result: VM ─► snap3 ─► snap2 ─► flat (đã merge snap1)

Quá trình merge tốn I/O nhiều, có thể mất giờ với snapshot lớn.

Snapshot Consolidation

Đôi khi xóa snapshot xong, delta file vẫn còn (do lỗi merge, datastore đầy, etc.). VM sẽ báo:

"Configuration issues: Virtual machine disks consolidation needed."

→ Click Consolidate → ESXi cố gắng merge lại các delta còn sót.

⚠️ Bắt buộc consolidate khi báo cảnh báo — bỏ qua sẽ tích tụ delta, đầy disk.

---

vSphere Replication & Backup

vSphere Replication (free)

Lập lịch đồng bộ VM giữa 2 site. Free, không cần license.

Cần:

• Cài thêm vSphere Replication Appliance (VM, tải về free).
• Cấu hình replication: source VM → target site.
• Set RPO (Recovery Point Objective): 5 phút - 24 giờ.

→ Disaster recovery cơ bản. Production thường dùng tool chuyên (Veeam, Zerto, SRM).

Backup vs Snapshot vs Replication

Feature	Snapshot	Replication	Backup
Mục đích	Test rollback ngắn	DR cross-site	Long-term restore
Vị trí	Cùng datastore	Khác site	External storage
Recovery	Rollback nhanh	Failover site	Restore file
Thời gian giữ	< 72h	RPO-based	Tháng/năm

→ 3 thứ khác nhau, cần CẢ BA cho production hoàn chỉnh.

---

Phần D — Resource Management

CPU và RAM trong ảo hóa — concepts

Cần hiểu kỹ trước khi config:

Physical CPU layers

1 server vật lý:
   ┌─────────────────────────────────────────┐
   │  2 sockets (khe gắn CPU)                 │
   │  ┌────────────┐    ┌────────────┐       │
   │  │  CPU 1     │    │  CPU 2     │       │
   │  │  10 cores  │    │  10 cores  │       │
   │  │  × 2 HT    │    │  × 2 HT    │       │
   │  └────────────┘    └────────────┘       │
   └─────────────────────────────────────────┘

Tính toán:
   Sockets: 2
   Cores total: 2 × 10 = 20 physical cores (pCPU)
   Hyper-Threading: 20 × 2 = 40 logical cores (lCPU)

3 layer:

• Socket — khe vật lý gắn CPU.
• Physical Core (pCPU) — core CPU thực.
• Logical Core (lCPU) — với Hyper-Threading bật, mỗi pCPU = 2 lCPU.

vCPU mapping

vCPU map với logical CPU. Tối đa 1 VM có thể có vCPU = logical CPU của host.

Host: 40 logical CPU
1 VM tối đa: 40 vCPU (mà thực tế không nên gần limit)

Tốc độ tính toán

Host: 2 socket × 10 core × 2.0 GHz = 40 GHz total physical compute
VM: 4 vCPU × 2.0 GHz = 8 GHz max compute (lý thuyết)

Khuyến cáo CPU cho VM

VMware khuyến cáo:

• Bắt đầu với 2 vCPU, tăng nếu cần.
• Không cấp dư vCPU. Cấp nhiều quá có thể phản tác dụng (CPU ready time tăng do scheduling phức tạp).
• Theo dõi CPU usage trong guest — nếu < 70%, có thể giảm vCPU.

Socket vs Core layout — best practice đã đổi

Khi VM có nhiều vCPU (vd: 4 vCPU), VMware cho phép chọn cách phân bổ:

• 4 socket × 1 core (cũ, recommend trước vSphere 6.7).
• 1 socket × 4 core (modern, recommend từ vSphere 6.7+).
• 2 socket × 2 core.

Khuyến cáo modern: ít socket, nhiều core per socket. Lý do:

• NUMA awareness — guest OS thấy ít NUMA node = scheduler tốt hơn cho workload.
• OS licensing — nhiều OS (Windows Server, Oracle) tính license per socket. Ít socket = ít license cost.
• Modern apps assume modern CPU topology (1 socket × nhiều core).

⚠️ Lưu ý: tài liệu cũ hơn (pre-6.7) khuyến cáo nhiều socket. Hardware/license modern → ngược lại.

Memory layer

Host: 128 GB RAM

ESXi overhead:       ~ 8 GB  (system, vmkernel)
VM-1 (8 GB):         8 GB
VM-2 (4 GB):         4 GB
VM-3 (10 GB):        10 GB
─────────────────────────
Used:                30 GB
Free:                98 GB

→ Track Free RAM của host. < 10% = bắt đầu nguy hiểm (balloon, swap).

Memory Overcommit

VMware cho phép cấp tổng RAM VM > RAM host vật lý (overcommit):

Host 32GB RAM
5 VM × 8GB = 40 GB cấp cho VM (overcommit 25%)

Trong thực tế: VM ít khi dùng hết RAM cấp → OK
Khi VM dùng nhiều thật:
  → VMware Tools balloon driver "lấy lại" RAM idle
  → Nếu không đủ, swap memory ra disk (CHẬM)

Monitor ballooning:

• esxtop → memory tab → MCTLSZ column = balloon active size.
• Balloon > 0 = host đang thiếu RAM, đang nén VM.
• Production tránh để ballooning kéo dài.

---

Reservation, Limits, Shares

3 cơ chế VMware cho phép admin fine-tune resource cho từng VM.

1. Reservation — khoanh vùng tài nguyên

Reservation = lượng resource đảm bảo cho VM, kể cả khi host thiếu.

VM1 set CPU Reservation = 2 GHz:
  → Host phải dành 2 GHz cho VM1
  → Không VM nào có thể "ăn" vào 2 GHz này
  → Kể cả khi VM1 không dùng đến 2 GHz

• ✅ Đảm bảo SLA cho VM critical.
• ❌ Lãng phí — resource bị "khóa" dù VM không dùng.

2. Limit — chặn trên

Limit = lượng resource tối đa VM được phép dùng.

VM2 set CPU Limit = 4 GHz:
  → Dù host còn rảnh nhiều, VM2 không vượt 4 GHz
  → "Bóp" performance để dành cho VM khác

• Use case: VM noisy (process bug ngốn CPU) → set limit để không ảnh hưởng VM khác.
• Use case: Multi-tenant — tenant trả tiền plan 4 vCPU, set limit để fair use.

3. Shares — ưu tiên khi cạnh tranh

Shares chỉ có tác dụng KHI host thiếu tài nguyên (cạnh tranh).

Host CPU bị overcommit, có 4 VM đang đòi CPU:
   VM1: Shares = 1000
   VM2: Shares = 2000
   VM3: Shares = 5000
   VM4: Shares = 6000  (off → không tính)
   ─────────────────────
   Tổng on:    8000
   
   Phân chia CPU theo tỷ lệ shares:
     VM1: 1000/8000 = 12.5%   ← thứ 3
     VM2: 2000/8000 = 25%     ← thứ 2
     VM3: 5000/8000 = 62.5%   ← ưu tiên cao nhất

• Low / Normal / High preset (Normal = 1000 shares).
• Custom: gõ số.

⚠️ Shares chỉ active khi thiếu resource. Lúc host rảnh, mọi VM dùng thoải mái — shares không matter.

Khi nào dùng gì

Use case	Reservation	Limit	Shares
VM critical, SLA cao	✅		✅ High
VM dev/test ưu tiên thấp		✅	✅ Low
Noisy neighbor		✅
Multi-tenant fair		✅	✅
Production thông thường			✅ Normal (default)

---

Monitoring tài nguyên

Trong guest OS

# Linux
top, htop, vmstat
free -m
df -h, iostat

# Windows
Task Manager
Performance Monitor

vCenter Performance Charts

VM → Monitor → Performance
   → CPU usage, Memory usage, Disk I/O, Network
   → Realtime hoặc Historical (1d, 1w, 1m, 1y)

CLI: esxtop / resxtop

esxtop = htop của ESXi, chạy trên ESXi host:

ssh root@esxi-host
esxtop

# Trong esxtop:
c = CPU mode
m = Memory mode
n = Network mode
d = Disk adapter
v = VM disk

resxtop = remote esxtop, chạy từ máy client.

Production: monitor liên tục qua vCenter alarms + tool ngoài (Grafana, Datadog, etc.).

---

Alarms — cảnh báo tự động

Alarm = trigger condition + action.

Alarm Definitions

vCenter có hàng trăm alarm sẵn:

• VM CPU usage > 90%
• Datastore usage > 75%
• Host hardware health = warning
• vCenter service down

Alarm Rules

Custom alarm rules:

Trigger:
  Condition:  VM Memory usage > 80%
  Duration:   for 5 minutes

Action:
  Send email to:  admin@cty.com
  SNMP trap
  Run script
  Power off VM (extreme)

Reset Rules

Khi metric trở lại bình thường, alarm tự reset (hoặc manual reset).

Cấu hình email

vCenter → Configure → Mail
  SMTP Server:  smtp.cty.com:587
  Sender:       vcenter@cty.com
  Auth:         username/password

→ Sau đó alarm có thể gửi email tự động.

---

Phần E — Cluster, HA, DRS

Cluster — quản lý nhiều host như một

Cluster là tập hợp nhiều ESXi host được quản lý chung, cho phép bật các tính năng cao cấp.

                    Cluster "Production"
   ┌─────────────────────────────────────────────────────┐
   │                                                       │
   │   ┌──────────┐  ┌──────────┐  ┌──────────┐          │
   │   │  ESXi 1  │  │  ESXi 2  │  │  ESXi 3  │          │
   │   │  128 GB  │  │  128 GB  │  │  128 GB  │          │
   │   │  40 vCPU │  │  40 vCPU │  │  40 vCPU │          │
   │   └──────────┘  └──────────┘  └──────────┘          │
   │                                                       │
   │   Cluster tổng:                                       │
   │   - 384 GB RAM pool                                   │
   │   - 120 vCPU pool                                     │
   │   - Có thể bật: HA, DRS, vSAN, EVC                   │
   └─────────────────────────────────────────────────────┘

Tạo Cluster

vCenter → Datacenter → New Cluster
   Name: prod-cluster
   ☑ Enable vSphere DRS
   ☑ Enable vSphere HA
   ☐ Enable vSAN (nếu có)
   → Create

Sau đó add host vào cluster (kéo thả).

---

vSphere HA — Bảo vệ VM khỏi host die

HA (High Availability): khi host gặp sự cố, VM tự động restart trên host khác trong cluster.

⚠️ HA KHÔNG phải zero-downtime — VM bị restart (mất state). Khác vMotion (zero downtime, giữ state).

Cluster có 3 host (HA enabled):
   Host A chạy: VM1, VM2, VM3
   Host B chạy: VM4, VM5
   Host C chạy: VM6
        │
        ▼  Host A die (mất power, network, hang)
        │
   HA phát hiện sau ~30s
        │
        ▼
   HA chọn host nào còn rảnh resource:
     VM1, VM2 → restart trên Host B
     VM3      → restart trên Host C
        │
        ▼
   Sau ~1-2 phút, VM trở lại operational
   (đã mất state — coi như power cycle)

Yêu cầu HA

• License (vSphere Standard trở lên).
• Cluster với ≥ 2 host, tối đa 64.
• ≥ 2 shared datastore (cho heartbeat).
• vCenter (để config + monitor).
• Network heartbeat stable giữa các host.

Kiến trúc HA — FDM, Master/Slave

┌─────────────────────────────────────────────────────────┐
│                      Cluster                             │
│                                                          │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │
│   │   Host 1     │  │   Host 2     │  │   Host 3     │ │
│   │              │  │              │  │              │ │
│   │  FDM Master  │  │  FDM Slave   │  │  FDM Slave   │ │
│   │  (đầu tàu)   │  │              │  │              │ │
│   └──────┬───────┘  └──────┬───────┘  └──────┬───────┘ │
│          │                 │                 │           │
│          │ heartbeat       │                 │           │
│          ├─────────────────┼─────────────────┤           │
│          │                 │                 │           │
│          ▼                 ▼                 ▼           │
│   ┌────────────────────────────────────────────────┐    │
│   │       Shared Datastore (heartbeat files)        │    │
│   └────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────┘
            │
            ▼
       ┌──────────┐
       │ vCenter  │ ← Master nói chuyện với vCenter
       └──────────┘

Khi bật HA, vCenter cài service Fault Domain Manager (FDM) lên mọi host trong cluster.

Bầu cử Master:

• Khi cluster start, FDM trên các host bầu chọn 1 master host (host có datastore nhiều nhất, MOID thấp nhất).
• Các host còn lại là slave.

Nhiệm vụ Master:

• Quản lý sự kiện HA — host die thì kích hoạt failover.
• Giữ danh sách VM đang chạy trên cluster.
• Giám sát slave qua heartbeat.
• Nói chuyện với vCenter qua management port.

Nhiệm vụ Slave:

• Gửi trạng thái VM của chính nó về master.
• Giám sát master (để biết master còn sống).
• Theo dõi bản thân (memory, CPU, network).

Khi master die:

• Slave phát hiện (không heartbeat) → bầu master mới.
• Master mới reboot các VM của host vừa die.

Heartbeat Datastores

Network heartbeat có thể không tin cậy (vd: network partition). Vì vậy HA dùng datastore heartbeat làm backup:

Mỗi host tạo 1 file log trên datastore:
   /vmfs/volumes/datastore1/.vSphere-HA/HOST-A-heartbeat
   /vmfs/volumes/datastore1/.vSphere-HA/HOST-B-heartbeat
   ...

Master kiểm tra:
  - Slave còn ping qua network? (heartbeat 1)
  - Slave còn update file timestamp trên datastore? (heartbeat 2)
  
Cả 2 mất → host đó thực sự die → trigger HA failover.

⚠️ Bắt buộc ≥ 2 heartbeat datastore để có redundancy.

HA Failure Scenarios

Scenario 1: Host hardware die

Host A mất power.

• Slave (Host B, C) không thấy heartbeat của Host A trong 30s.
• Master kiểm tra datastore heartbeat → cũng không update.
• Confirm Host A die → restart VM của Host A trên host khác.
• Downtime: 1-2 phút.

Scenario 2: Host bị hang (treo)

Host A không die nhưng treo (kernel panic, hardware glitch).

• Tương tự scenario 1 — không heartbeat → HA trigger.
• ⚠️ Edge case: host hang một phần (CPU OK, network die) → có thể trigger split brain nếu config sai.

Scenario 3: Network Isolation

Host A mất kết nối network (cáp lỏng, switch port die), nhưng host vẫn chạy.

• Host A không ping được default gateway → tự coi là isolated.
• Hành động khi isolated (do admin config):
  • Leave powered on (default) — VM vẫn chạy, chờ network back.
  • Power off — tắt VM (để host khác restart).
  • Shutdown — graceful shutdown.

⚠️ Default "Leave powered on" có thể gây split-brain nếu VM được restart trên host khác — 2 VM cùng IP. Production thường set "Power off" để an toàn.

→ Best practice: teaming 2 NIC cho management network, hoặc 2 VMkernel port khác subnet, để giảm rủi ro network isolation.

Scenario 4: All Paths Down (APD)

Storage path die — host mất kết nối tới datastore.

• HA detect APD → restart VM trên host khác (nếu host khác còn thấy datastore).

Scenario 5: Permanent Device Loss (PDL)

Storage device bị xóa khỏi storage backend (admin xóa LUN).

• Khác APD: APD = "đường mạng die", PDL = "thiết bị thật sự gone".
• HA cũng trigger restart.

HA Config — Failures and Responses

Cluster → Edit Settings → vSphere HA → Failures and Responses

Host Failure Response:
   ◉ Restart VMs    (default)
   ◯ Disable

Response to Host Isolation:
   ◯ Leave powered on
   ◉ Power off and restart VMs  (production recommend)
   ◯ Shutdown and restart VMs

Datastore with PDL:
   ☑ Power off and restart VMs

Datastore with APD:
   ☑ Power off and restart VMs
   Delay: 3 minutes (chờ trước khi action)

VM Monitoring:
   ◉ Disabled
   ◯ VM Monitoring Only       (restart VM nếu VMware Tools heartbeat fail)
   ◯ VM and Application Monitoring (cần app HA-aware)

Admission Control

Admission Control = đảm bảo cluster CÒN ĐỦ resource để failover khi host die.

Logic: nếu Host A die và VM của nó restart trên Host B+C → còn đủ RAM/CPU không?

3 policies:

1. Slot Policy (cũ, có tác dụng với Reservation)

• Tính "slot size" theo VM có Reservation cao nhất.
• Đảm bảo còn đủ slot cho VM lúc failover.
• Chỉ work khi VM có Reservation.

2. Cluster Resource Percentage (recommend)

• Reserve % CPU + % RAM cho failover.
• Vd: cluster 3 host, reserve 33% = đủ để 1 host die.
• vCenter tự tính dựa số host được phép die (Host Failures Cluster Tolerates).

Cluster 3 host, mỗi host 100GB RAM = 300GB total
Host Failures = 1:
  Reserve 1/3 = 100GB cho failover
  → VM chỉ được dùng 200GB
  → VM thử cấp > 200GB sẽ FAIL (admission denied)

3. Dedicated Failover Host

• Chỉ định host cụ thể làm "spare" — không VM nào chạy.
• Đợi khi cần failover.
• ❌ Lãng phí (1 host idle).
• ✅ Đảm bảo 100% có host backup.

⚠️ Quá khắt khe admission control → không cấp được VM mới mặc dù host còn rảnh. Production cần balance.

---

DRS — Distributed Resource Scheduler

DRS = tự cân bằng tải CPU/RAM giữa các host trong cluster bằng vMotion.

Trước DRS:
   Host A: 90% CPU, 95% RAM  ← quá tải
   Host B: 30% CPU, 40% RAM
   Host C: 25% CPU, 35% RAM

DRS phát hiện imbalance, vMotion VM:
        │
        ▼
   Host A: 60% CPU, 65% RAM  ← balanced
   Host B: 55% CPU, 60% RAM
   Host C: 50% CPU, 55% RAM

Automation Levels

3 mức tự động:

Level	Behavior
Manual	DRS chỉ recommend, admin click apply.
Partially Automated	Auto place VM khi tạo mới, nhưng cân bằng phải manual.
Fully Automated	Auto vMotion theo migration threshold. Recommend production.

Migration Threshold

Conservative ←─────────────────────────► Aggressive
Level 1      Level 2      Level 3      Level 4    Level 5
"Strict"                                        "Moderate"
                                                "OK to migrate often"

• Level 1 — chỉ migrate khi imbalance nghiêm trọng.
• Level 3 — default, balance giữa stable và optimization.
• Level 5 — migrate aggressively, có thể spam vMotion.

DRS Rules

Có thể đặt affinity/anti-affinity rules cho DRS:

Affinity (giữ chung)

Rule: "Keep together"
   VM-AppServer-01  
   VM-AppServer-02  ← cả 2 phải cùng host (low latency)

Anti-Affinity (tách ra)

Rule: "Separate"
   VM-DB-Master     
   VM-DB-Slave      ← phải ở host khác nhau (HA — không die cùng lúc)

Use case anti-affinity: HA pair, cluster nodes, redundant services.

DRS yêu cầu

• License Enterprise (DRS không có ở Standard).
• vMotion enabled.
• Cluster có ≥ 2 host.

---

Capstone Story — đêm Black Friday

Năm 2021, mình quản hệ thống e-commerce cho 1 khách. Black Friday traffic dự đoán tăng 10x.

Trước đó 1 tuần, mình:

• Setup cluster 6 host (vs 3 host bình thường) — temporary scale.
• Bật DRS Fully Automated + Migration Threshold 4.
• Bật HA với Admission Control: Resource Percentage 25% (chịu được 1.5 host die).
• Setup Storage vMotion automation — datastore đầy 80% sẽ trigger.
• Cài monitoring + alarm cho mọi metric.

Đêm Black Friday, 11h tối:

• Traffic tăng đột biến → 50+ VM web/app/cache.
• DRS làm việc liên tục, vMotion VM giữa các host để cân bằng.
• Mình ngủ.

3h sáng, alarm nổ:

"Host esxi-04 lost connection"

Vào kiểm tra: Host 4 hardware fail (PSU die). 18 VM trên đó.

HA tự work:

• 30s sau khi mất heartbeat → confirm host die.
• Admission Control xác nhận còn đủ resource (vì có 6 host).
• 18 VM được restart trên 5 host còn lại.
• DRS sau đó tự rebalance.
• 2 phút từ lúc host die → VM trở lại operational.

Sáng hôm sau:

• 1 host die không ai biết (ngoại trừ alarm).
• Customer trải nghiệm: vài giây HTTP 500, sau đó OK.
• Total revenue lost: ~$200 (so với ~$50,000 nếu downtime kéo dài).

Bài học:

1. HA + DRS là gold combo. HA xử lý disaster, DRS optimize hàng ngày. Cả 2 cùng work = magic.

2. Capacity planning đúng = HA work được. Nếu cluster đã 95% load, host die = không đủ resource failover.

3. Test failover trước peak time. Mình đã pull cáp 1 host trước Black Friday để verify HA work. Tự tin lúc go-live.

4. Anti-affinity cho HA pair. Db-master và db-slave phải ở host khác nhau. Mình set rule, DRS giữ đúng.

5. Admission Control không quá strict. Reserve 25% là sweet spot — đủ failover, không lãng phí.

6. Monitor + alarm 24/7. Mình ngủ nhưng alarm không ngủ. Email + SMS khi critical.

---

Lab Capstone — full cluster setup

Lab 1: Tạo Cluster với HA + DRS

1. vCenter → Datacenter → New Cluster
   Name: lab-cluster
   ☑ vSphere DRS — Fully Automated, Level 3
   ☑ vSphere HA — default settings
   → Create

2. Drag 3 ESXi host vào cluster.
3. Wait for FDM service install on each host.

Lab 2: Test vMotion

1. Create VM "test-vm" trên Host 1.
2. Power on, ping continuously trong VM:
   ping 8.8.8.8 -t   # Windows
   ping 8.8.8.8       # Linux
   
3. Right-click VM → Migrate → Compute resource only → chọn Host 2.
4. Confirm.
5. Observe ping — không mất gói (hoặc mất 1-2 gói).

Lab 3: Test HA Failover

⚠️ Chỉ làm trong lab, không production!

1. Power on VM trên Host 1.
2. Pull cáp network (hoặc shutdown rough) Host 1.
3. Đợi 30-60s.
4. vCenter detect Host 1 down.
5. VM được restart trên Host 2 hoặc 3.
6. Total downtime: ~1-2 phút.

Lab 4: Test DRS Rules

1. Tạo 2 VM: web-01, web-02.
2. Cluster → Configure → VM/Host Rules → Add
   Type: Separate Virtual Machines
   Members: web-01, web-02
3. Power on cả 2.
4. DRS sẽ tự đặt 2 VM trên 2 host khác nhau.

Lab 5: Snapshot lifecycle

1. Power on VM, login.
2. Take Snapshot "before-update":
   ☑ Snapshot memory
   ☐ Quiesce guest (cần VMware Tools)
3. Trong VM: `apt update && apt upgrade -y` (simulate update).
4. Test app — giả sử fail.
5. Revert to Snapshot → VM về trạng thái before-update.
6. Delete snapshot khi confirm OK.

Lab 6: Resource Pool + Shares

1. Cluster → New Resource Pool "Production"
   CPU Shares: High
   Memory Shares: High
2. New Resource Pool "Test"
   CPU Shares: Low
3. Move VM vào pool tương ứng.
4. Stress test → quan sát Production VM ưu tiên.

---

Pitfalls

1. HA không phải zero-downtime — VM restart, mất state. vMotion mới là zero-downtime.

2. Snapshot quá nhiều / lâu → I/O chậm, datastore đầy, chain fail. Quy tắc: max 3, < 72h.

3. Snapshot Domain Controller / DB → corruption, inconsistent state. Dùng backup tool chuyên.

4. vMotion fail vì CPU không tương thích → bật EVC.

5. Storage vMotion fail vì datastore không share → check VMkernel port + datastore access.

6. Disk grow trong vCenter nhưng quên extend trong guest OS → guest vẫn thấy size cũ.

7. HA Admission Control quá strict → không tạo được VM mới dù host rảnh.

8. Network Isolation "Leave powered on" → có thể gây split-brain. Production set Power off.

9. Không có 2 heartbeat datastore → HA không reliable khi network mất. Bắt buộc ≥ 2.

10. DRS Fully Automated với Level 5 → vMotion liên tục, ăn băng thông. Level 3 là sweet spot.

11. Convert template thành VM để update, quên convert lại → template "biến mất", deploy fail.

12. EVC bật mode quá thấp → mất hết CPU feature mới. Chọn mode thấp nhất CHỈ ĐỦ cho compatibility.

13. Resource Pool Shares hiểu lầm → "1 VM share High" không có nghĩa là VM ưu tiên. Shares chỉ matter khi cạnh tranh.

14. Quên consolidate snapshot → delta file tích tụ → đầy disk → VM treo.

15. Reservation quá cao → host không boot được VM khác (resource bị khóa). Cẩn thận với Reservation.

---

Tóm tắt

Phần A — VM Lifecycle

• Template = VM chuẩn để clone. 4 cách tạo VM: ISO / OVA-OVF / Template / Clone.
• Guest OS Customization = auto setup hostname/IP/SID sau deploy.
• Content Library = share template/ISO cross-vCenter (Local / Published / Subscribed).
• Hot Add: CPU/RAM tăng nóng (cần Hot Plug bật). Disk tăng nóng + extend trong guest. Card mạng add bất cứ lúc nào.
• Remove from Inventory ≠ Delete from Disk. Sau là vĩnh viễn.

Phần B — Migration

• vMotion — chuyển VM giữa host (RAM copy, disk shared). Zero-downtime.
• Storage vMotion — chuyển datastore (qua mirror driver). Có thể convert thin↔thick.
• Cross-vCenter vMotion — cần ELM + network stretched.
• EVC — giả lập CPU đời thấp để cluster heterogeneous vMotion được.

Phần C — Snapshot

• Snapshot ≠ Backup. Chỉ test rollback ngắn hạn.
• Mỗi snap tạo -delta.vmdk (VMFS5) hoặc -sesparse.vmdk (VMFS6). Disk gốc thành READ-ONLY.
• Chain dài = chậm + risk. Max 3 snap, < 72h.
• Không snap Domain Controller, DB transactional không quiesce.
• vSphere Replication free cho DR cơ bản.

Phần D — Resource Management

• vCPU map logical CPU. Cấp vừa đủ, đừng over-provision.
• Memory overcommit OK, nhưng monitor ballooning.
• 3 cơ chế: Reservation (đảm bảo), Limit (chặn trên), Shares (priority khi cạnh tranh).
• Shares chỉ active khi thiếu resource.
• Monitor: vCenter Performance Chart + esxtop + Alarms.

Phần E — Cluster, HA, DRS

• Cluster = group host, enable HA/DRS/vSAN.
• HA = restart VM khi host die. Master/Slave với FDM, heartbeat network + datastore.
• HA scenarios: host die, isolation, APD, PDL — config response cho từng case.
• Admission Control = đảm bảo còn resource failover. Recommend Cluster Resource Percentage.
• DRS = auto vMotion balance. Fully Automated + Level 3 cho production.
• DRS Rules — affinity (keep together), anti-affinity (separate). Quan trọng cho HA pair.

---

🎓 Kết thúc Chặng 5 — Virtualization với VMware vSphere

Đi qua 4 bài:

1. Bài 01 — Ảo hóa & ESXi: cài hypervisor, tạo VM đầu tiên, hiểu Type 1/2, hardware ảo.
2. Bài 02 — vCenter Server: quản lý tập trung, SSO, RBAC, backup, vCenter HA.
3. Bài 03 — Network & Storage: vSwitch, port group, VMkernel, VMFS, vSAN, RDM.
4. Bài 04 — Cluster, HA, DRS: capstone — cluster tự vận hành.

Từ 1 server vật lý → infrastructure tự cân bằng + tự khôi phục.

Bạn đã sẵn sàng cho

• Container (chặng tiếp): hiểu VM thật sự là gì → thấy container "khác" thế nào. Pattern (image, runtime, network) có nét tương đồng nhưng implementation rất khác.
• Cloud (AWS/Azure/GCP): EC2 = VM, EBS = VMDK, VPC = vSwitch, AutoScaling = DRS. Concept giống, scale lớn hơn.
• Kubernetes: K8s scheduler = DRS, Pod failure = HA, PersistentVolume = VMFS/vSAN. K8s là VMware-of-containers.
• Multi-cloud / Hybrid: VMware Cloud on AWS, Azure VMware Solution — vSphere chạy trên cloud. Skill này transfer 100%.

Lời khuyên đi tiếp

1. Đừng vội bỏ vSphere để học K8s. Hiểu VM trước → K8s nhìn vào dễ hơn 10 lần. Concept scheduler, networking, storage abstraction — gốc rễ ở VMware.

2. Lab nested ESXi liên tục. VMware skill chỉ vững khi tay quen. Mỗi tuần dành 2 tiếng break/fix lab.

3. Đọc VMware blog + docs. Bộ doc của VMware (docs.vmware.com) thuộc loại tốt nhất ngành IT. Đọc cuối tuần.

4. Cert VCP-DCV nếu định làm chuyên VMware. Cert có giá trị thật trong job market.

5. Học PowerCLI — automation VMware. 80% admin task script được, tiết kiệm 10x thời gian.

6. Hiểu trade-off cloud vs on-prem. VMware vẫn chiếm 70% enterprise — không sắp chết như thiên hạ nói.

Chặng tiếp theo là Container & Docker. Nếu hôm nay bạn dựng được vSphere cluster — bạn đã có nền tảng vững nhất để hiểu container.

Chúc bạn build được infrastructure mà 3h sáng host die vẫn ngủ được! 🚀

— Minh Hưng