Bài 03

Virtual Network & Storage

11 tháng 5, 2026 · 120 phút đọc

Bài 03 — Virtual Network & Storage

Đây là bài 03 của chặng. Bài 01-02 bạn đã có ESXi và vCenter. Giờ là lúc kết nối mọi thứ — network để VM giao tiếp, storage để chứa VM.

Đây là 2 thành phần mà nếu cấu hình sai, VM không chạy được hoặc chạy mà rất chậm. Production VMware admin dành 60% thời gian cho 2 thứ này. Bài này cover khá dài — chia 2 phần lớn:

  • Phần A — Virtual Network (Buổi 4 trong tài liệu)
  • Phần B — Storage (Buổi 5 + 6)

Phần A — Virtual Network

Vấn đề: VM giao tiếp như thế nào?

VM chạy bên trong ESXi. Card mạng vật lý cắm vào server vật lý. Làm sao VM dùng được card vật lý đó?

┌─────────────────────────────────┐
│            ESXi Host             │
│                                  │
│   ┌────┐  ┌────┐  ┌────┐         │
│   │VM 1│  │VM 2│  │VM 3│         │
│   └─┬──┘  └─┬──┘  └─┬──┘         │
│     │       │       │             │
│     ?       ?       ?             │  ← Làm sao kết nối?
│     │       │       │             │
│   ┌─┴───────┴───────┴───┐        │
│   │  Network Card vật lý │        │
│   │  (NIC vSphere host)  │        │
│   └────────┬─────────────┘        │
└────────────┼──────────────────────┘
             │
        Mạng vật

→ Cần virtual switch (vSwitch) — switch ảo bên trong ESXi, đóng vai trò cầu nối.


Kiến trúc Virtual Switch

┌────────────────────────────────────────────────────┐
│                  ESXi Host                          │
│                                                     │
│  ┌────┐  ┌────┐  ┌────┐    ┌─────────────┐         │
│  │VM 1│  │VM 2│  │VM 3│    │  vMotion    │         │
│  │vNIC│  │vNIC│  │vNIC│    │  (ESXi)     │         │
│  └─┬──┘  └─┬──┘  └─┬──┘    └──────┬──────┘         │
│    │       │       │              │                 │
│  ┌─┴───────┴───────┴──┐    ┌─────┴────────┐        │
│  │  Port Group        │    │ VMkernel Port│        │
│  │  "VM Network"      │    │  (cho ESXi)  │        │
│  │  VLAN 10           │    │  IP: 10.0.0.1│        │
│  └────────┬───────────┘    └──────┬───────┘        │
│           │                       │                  │
│  ┌────────┴───────────────────────┴───────┐         │
│  │       Virtual Switch (vSwitch0)         │         │
│  └────────┬─────────────────────┬──────────┘         │
│           │                     │                    │
│  ┌────────┴────────┐   ┌────────┴────────┐          │
│  │   Uplink Port   │   │   Uplink Port   │          │
│  │   (Physical NIC)│   │   (Physical NIC)│          │
│  │   vmnic0        │   │   vmnic1        │          │
│  └────────┬────────┘   └────────┬────────┘          │
└───────────┼─────────────────────┼────────────────────┘
            │                     │
       Switch vật lý         Switch vật lý
       (port 1)              (port 2)

3 khái niệm chính:

1. VM Port Group

Port Group là nhóm port ảo trên virtual switch mà VM kết nối vào, có VLAN ID.

  • VM connect vào port group → ăn theo VLAN ID của port group đó.
  • Nhiều VM trong cùng port group = cùng VLAN = thấy nhau ở Layer 2.
  • VM ở port group khác VLAN = không thấy nhau (trừ khi route qua Layer 3).
Port Group "Production" VLAN 10
   ├── VM1, VM2, VM3  (cùng VLAN 10, thấy nhau)

Port Group "DMZ" VLAN 20
   ├── VM-Web        (VLAN 20, không thấy production VM)

⚠️ vSwitch không tạo được VLAN mới — chỉ "ăn theo" VLAN đã có trên switch vật lý. Switch vật lý phải config trunk + cho phép VLAN ID đi qua.

2. VMkernel Port

VMkernel port là port ảo dành riêng cho ESXi (không phải cho VM), có địa chỉ IP.

Dùng cho các traffic của chính ESXi:

  • Management — vCenter quản lý ESXi qua đây.
  • vMotion — chuyển VM giữa các host.
  • Storage — kết nối iSCSI / NFS datastore.
  • vSAN — traffic vSAN giữa các host.
  • Fault Tolerance — sync VM giữa primary và secondary.

Mỗi traffic có thể có VMkernel port riêng hoặc dùng chung.

⚠️ Production: tách traffic. Management 1 VMkernel, vMotion 1 VMkernel, Storage 1 VMkernel — để tránh đụng băng thông.

3. Uplink Port

Uplink port là port vật lý (NIC vật lý) được gắn vào virtual switch. Đây là "đường ra" của switch ảo kết nối với network bên ngoài.

  • Mỗi vSwitch có thể có nhiều uplink (cho redundancy + load balancing).
  • ESXi đặt tên: vmnic0, vmnic1, vmnic2...

Standard 802.1Q

ESXi hỗ trợ chuẩn 802.1Q — chuẩn VLAN tagging. Nhờ đó:

  • 1 uplink (1 cáp vật lý) có thể carry nhiều VLAN (trunk mode).
  • Mỗi port group set VLAN ID khác nhau, dùng chung uplink.

Standard Switch vs Distributed Switch

VMware có 2 loại virtual switch:

Standard Switch (vSS)

  • Thuộc về 1 host duy nhất. Mỗi ESXi có vSwitch riêng.
  • Cấu hình lưu trên host đó.
  • Cluster 10 host → phải config vSS giống nhau 10 lần. Sai 1 chỗ là VM mất kết nối khi vMotion.
  • Có sẵn trong mọi license — kể cả free.

Distributed Switch (vDS)

  • Một switch duy nhất trải dài nhiều host. Cấu hình lưu trên vCenter, các host pull về.
  • Cấu hình 1 lần, áp dụng tất cả host trong cluster.
  • Khi vMotion VM giữa các host → port group config tự follow.
  • Yêu cầu license Enterprise Plus + vCenter (Standard Switch không cần vCenter).
Standard Switch:                Distributed Switch:

  Host A   Host B   Host C        Host A   Host B   Host C
   │        │        │             │        │        │
  [vSS]   [vSS]   [vSS]            └────[vDS]────┘
   │        │        │                     │
   │        │        │              (1 switch logic
  Config riêng từng host             trải 3 host)
                                      Config 1 ch

So sánh chi tiết

Tiêu chí Standard Switch Distributed Switch
Phạm vi 1 host Nhiều host
Quản lý Mỗi host riêng Tập trung qua vCenter
License Mọi version Enterprise Plus
Yêu cầu vCenter Không
Migrate VM Phải config trên host đích Tự động
Features nâng cao (NetFlow, LACP, PVLAN...) Không có

Khi nào chọn gì

  • Lab, setup nhỏ (1-3 host) → Standard Switch.
  • Production multi-host → Distributed Switch (nếu có license).
  • Production không có Enterprise Plus → Standard Switch + script tự động sync config.

Network Policies — chính sách cho switch ảo

Đây là phần base về vận hành — config sai network policy → VM mất kết nối hoặc bị tấn công.

MTU — Jumbo Frame

MTU (Maximum Transmission Unit) = kích thước tối đa 1 packet. Default 1500 bytes.

Production khuyến cáo MTU 9000 (jumbo frame) cho:

  • Storage traffic (iSCSI, NFS) — gói lớn = throughput cao hơn.
  • vMotion — copy memory nhanh hơn.
  • vSAN — cải thiện performance đáng kể.

⚠️ Toàn bộ đường đi phải support MTU 9000: vSwitch + uplink + switch vật lý + storage device. Sai 1 chỗ → packet fragment → chậm hơn cả 1500.

# Test MTU end-to-end:
vmkping -d -s 8972 <target-IP>
# -d: don't fragment
# -s 8972: packet size (9000 - 28 header)
# Phải ping OK, không thì MTU bị break đâu đó

Security policies

vSwitch có 3 security setting — production nên Reject hết:

Setting Accept (default) Reject (recommend)
Promiscuous Mode VM nhận được packet của port khác VM chỉ nhận packet của mình
MAC Address Changes Cho phép guest OS đổi MAC Chặn — guest không đổi MAC được
Forged Transmits Cho phép gói tin với MAC khác đi ra Chặn — chỉ MAC đăng ký mới gửi được

Giải thích từng cái:

  • Promiscuous Mode — VM "nghe lén" mọi traffic trên cùng port group. Use case: IDS/IPS VM (Snort, Suricata). Default tắt vì security risk.

  • MAC Address Changes — guest OS đổi MAC card mạng trong OS. Có thể dùng để bypass NAC. Production tắt.

  • Forged Transmits — gửi packet với source MAC khác MAC đăng ký với hypervisor. Dùng để spoof. Tắt.

Khi nào BẬT Promiscuous Mode:
  - VM chạy IDS/IPS, sniffer
  - VM chạy LB layer 2 (rare)

Khi nào BẬT MAC Changes / Forged Transmits:
  - Nested ESXi (ESXi trong ESXi cho lab)
  - Cluster software dùng floating MAC (Microsoft NLB)

Còn lại, mặc định tất cả là Reject trong production.

Traffic Shaping — bóp băng thông

Giới hạn băng thông cho từng port group (chống 1 VM ngốn hết bandwidth).

3 tham số:

  • Average Bandwidth — tốc độ trung bình cho phép (vd: 1000 kbps).
  • Peak Bandwidth — tốc độ tối đa burst (vd: 2000 kbps).
  • Burst Size — kích thước burst tích lũy được (vd: 1000 KB).

Cách hoạt động: VM được dùng tốc độ Average. Nếu chưa dùng hết → tích lũy "credit" tới Burst Size. Khi cần, có thể burst lên Peak Bandwidth trong một khoảng thời gian.

Tính khoảng burst:

Ví dụ:
  Average  = 1000 kbps  (≈ 125 KB/s)
  Peak     = 2000 kbps  (≈ 250 KB/s)
  Burst    = 1000 KB

→ Burst trong: 1000 KB / 250 KB/s ≈ 4 giây

(Đổi đơn vị: 1 KB = 8 Kb. Vd 1000 kbps = 125 KB/s.)

⚠️ Traffic shaping chỉ giới hạn outbound trên Standard Switch. Distributed Switch cho phép cả 2 chiều.

Teaming and Failover — gắn nhiều uplink

Quan trọng nhất của network policies. Cho phép:

  • Cân bằng tải traffic qua nhiều uplink.
  • Failover khi 1 uplink die.

Load Balancing Algorithms

4 thuật toán:

1. Route based on Originating Virtual Port (default)

  • Mỗi vNIC của VM được assign cố định vào 1 uplink (theo port ID).
  • VM1 → uplink 1, VM2 → uplink 2, VM3 → uplink 1, ...
  • Đơn giản, đủ cho hầu hết case.

2. Source MAC Hash

  • Hash MAC source → quyết định uplink nào.
  • VM có nhiều MAC (multi-NIC) → mỗi MAC qua uplink khác.
  • Tương tự virtual port nhưng dựa MAC.

3. IP Hash

  • Hash source IP + destination IP → quyết định uplink.
  • Cân bằng tải tốt hơn — 1 VM gửi tới nhiều destination khác nhau sẽ dùng cả các uplink.
  • ⚠️ Yêu cầu switch vật lý phải cấu hình LACP/LAG (link aggregation) với các port uplink. Setup phức tạp + ăn performance CPU.

4. Route based on Physical NIC Load (chỉ vDS)

  • vDS monitor load thực của từng uplink, route VM sang uplink ít tải.
  • Cân bằng tải động — thông minh nhất.
  • Chỉ Distributed Switch hỗ trợ.

Khi nào chọn gì

  • Default — Route based on Originating Virtual Port: 90% trường hợp.
  • IP Hash + LACP: cần throughput cao nhất, có switch vật lý support, sẵn sàng phức tạp.
  • NIC Load (vDS): production lớn có vDS, muốn auto-balance.

Network Failure Detection

Cách phát hiện uplink fail:

1. Link Status Only (default)

  • Chỉ check trạng thái cáp (cable plugged in?).
  • Nhanh, đơn giản.
  • ❌ Không phát hiện được lỗi xa hơn — vd: switch access port lên nhưng switch core die → traffic không đi được nhưng link vẫn UP.

2. Beacon Probing

  • ESXi chủ động gửi packet qua các uplink để check end-to-end.
  • Cần ≥ 3 uplink mới hoạt động.
  • Phát hiện được lỗi từ switch access tới switch core.
  • ✅ Tin cậy hơn.

⚠️ Beacon yêu cầu ≥ 3 uplink. Setup 2 uplink → bắt buộc dùng Link Status Only.

Failback

Khi uplink chết, traffic chuyển sang standby. Sau khi uplink primary sống lại:

  • Failback = Yes (default) — traffic quay về primary.
  • Failback = No — giữ ở standby, tránh "flap" lần thứ 2.

Failover Order — thứ tự uplink

Mỗi uplink được gán vào 1 trong 3 nhóm:

  • Active Adapter — uplink chính, mang traffic.
  • Standby Adapter — dự phòng, kích hoạt khi active die.
  • Unused — không dùng trong policy này (nhưng vẫn thuộc switch).
Ví dụ: Port group "Management"
  Active:   vmnic0
  Standby:  vmnic1
  Unused:   vmnic2, vmnic3 (dành cho port group khác)

Port group "vMotion"
  Active:   vmnic2
  Standby:  vmnic3
  Unused:   vmnic0, vmnic1

→ Tách traffic management và vMotion qua các uplink khác nhau, không đụng nhau.


Phần B — Storage

Datastore là gì

Datastore là nơi chứa máy ảo (chứa file .vmx, .vmdk, snapshot...).

ESXi không lưu VM trực tiếp lên disk thô — phải qua datastore (lớp abstraction). Datastore có thể là:

  • Disk vật lý local trên host.
  • Storage từ xa qua mạng SAN/NAS.
  • Pool storage tổng hợp từ nhiều host (vSAN).

4 loại Datastore

┌─────────────────────────────────────────────────────┐
│                  4 loại Datastore                    │
├──────────┬──────────────────────────────────────────┤
│  VMFS    │  File system của VMware                  │
│          │  Dùng cho: local disk, FC, FCoE, iSCSI   │
├──────────┼──────────────────────────────────────────┤
│  NFS     │  File system mạng (kết nối NAS server)   │
│          │  Dùng cho: NAS qua NFS protocol          │
├──────────┼──────────────────────────────────────────┤
│  vSAN    │  Tổng hợp disk của các host thành 1 pool │
│          │  Dùng cho: cluster có disk local         │
├──────────┼──────────────────────────────────────────┤
│  vVOLs   │  Virtual Volumes - object storage        │
│          │  Dùng cho: storage hỗ trợ vVOLs          │
└──────────┴──────────────────────────────────────────┘

VMFS và vSAN là file system VMware tạo ra. NFS dùng standard NFS protocol. vVOLs là kiến trúc mới hơn (object-based).


Local vs Shared Storage

                  ┌──────────────────┐
                  │     Storage      │
                  └─────────┬────────┘
                            │
              ┌─────────────┼─────────────┐
              ▼                           ▼
       ┌─────────────┐            ┌──────────────┐
       │   Local     │            │   Shared     │
       │   (DAS)     │            │  (mạng)      │
       └──────┬──────┘            └──────┬───────┘
              │                          │
        HDD / SSD              ┌─────────┴─────────┐
        gắn trực tiếp          ▼                   ▼
        vào host           ┌───────┐          ┌────────┐
                           │  SAN  │          │  NAS   │
                           └───────┘          └────────┘
                           Block            File storage
                           storage           SMB / NFS
                           FC/FCoE/          / FTP
                           iSCSI

Local Storage (DAS)

Direct Attached Storage — HDD/SSD gắn trực tiếp vào server vật lý.

  • Format thành: VMFS hoặc vSAN.
  • ✅ Nhanh (không qua network).
  • ❌ Không share giữa host → không vMotion / HA được.
  • Use case: cài ESXi, scratch space, vSAN contribute disk.

Shared Storage — SAN

Storage Area Network — hệ thống chuyên dụng truy cập block storage qua mạng SAN riêng.

Protocol:

  • FC (Fibre Channel) — chạy trên cáp quang riêng. Tốc độ cao (32 Gbps), latency thấp. Đắt.
  • FCoE (FC over Ethernet) — FC chạy trên Ethernet. Giá vừa phải.
  • iSCSI — block storage qua TCP/IP thông thường. Rẻ nhất, chậm nhất trong 3.

Format thành: VMFS.

Shared Storage — NAS

Network Attached Storage — file storage qua mạng IP thông thường.

Protocol:

  • NFS — Unix/Linux file system protocol.
  • SMB / CIFS — Windows protocol (ESXi không support trực tiếp).
  • FTP — old, không phù hợp datastore.

Format thành: NFS datastore.

Bảng matching: Storage type → Datastore type

Storage Protocol Datastore type
Local HDD/SSD direct VMFS (hoặc vSAN nếu là vSAN cluster)
SAN FC VMFS
SAN FCoE VMFS
SAN iSCSI VMFS
NAS NFS NFS
vVOLs-capable storage FC/Ethernet vVOLs
Cluster local disks (vSAN network) vSAN

VMFS — File system chính của VMware

VMFS (Virtual Machine File System) là file system do VMware tạo ra, optimize cho VM workload.

Đặc điểm

  • Cluster-aware — nhiều ESXi cùng đọc/ghi 1 LUN VMFS đồng thời (lock-free).
  • Dung lượng tối đa 64 TB per datastore.
  • Chứa VM files + virtual disks (.vmx, .vmdk, snapshot, log).
  • Overprovision — có thể chứa nhiều hơn dung lượng vật lý (qua thin provisioning).

VMFS 5 vs VMFS 6

Feature VMFS 5 VMFS 6
Block size 1 MB only 1 MB (default), automatic
Max disk size 62 TB 62 TB
Auto space reclaim Manual Automatic
4K native disk No Yes
Sub-blocks 8 KB 1 KB

⚠️ Không upgrade được VMFS 5 → VMFS 6. Phải tạo datastore mới VMFS 6 và migrate VM sang (Storage vMotion). VMFS 5 vẫn dùng được nhưng bỏ tính năng mới.

Tạo VMFS Datastore

Trong vSphere Client:

Datacenter → StorageNew Datastore
  → Type: VMFS
  → Name: datastore01
  → Disk: chọn LUN/disk available
  → VMFS version: VMFS 6 (recommend)
  → Partition: chọn full disk
  → Finish

Tăng dung lượng VMFS — không giảm được

⚠️ VMFS chỉ tăng dung lượng, không giảm được. Cần tính toán trước khi cấp.

2 cách tăng:

1. Extend — lắp thêm ổ cứng/LUN, gộp vào datastore hiện tại.

Datastore01 (2TB)
   ├── LUN_A (1TB)  ← ban đầu
   └── LUN_B (1TB)  ← extend thêm
   Tổng: 2TB2TB không đổi nếu extend từ free space cùng LUN

2. Expand — mở rộng LUN hiện tại (nếu storage backend cho phép resize), VMFS dãn theo.

LUN_A: 1TB2TB (resize ở storage backend)
   ↓
Datastore01: 1TB2TB (expand)

Expand đơn giản hơn extend (không cần thêm LUN mới). Nhưng phụ thuộc storage backend support resize.

Datastore Maintenance Mode

Khi cần bảo trì datastore (vd: storage backend nâng cấp, di chuyển):

  1. Put datastore vào Maintenance Mode.
  2. ⚠️ Yêu cầu: không có VM nào còn trên datastore — phải Storage vMotion hết VM đi trước.
  3. Sau khi maintenance xong → exit maintenance mode → có thể đặt VM trở lại.

Delete vs Unmount

2 thao tác khác nhau hoàn toàn:

  • Unmount — gỡ datastore khỏi vSphere Client. Data vẫn còn. Có thể Mount lại sau (dùng tiếp).
  • Delete — xóa sạch datastore, không khôi phục được. Data mất hoàn toàn.

Luôn unmount trước, kiểm tra kỹ, rồi mới delete. Sai = mất data.


Multipath Algorithms — dự phòng và cân bằng tải

Khi storage có nhiều đường đi tới host (vd: 2 FC switch, 2 HBA card), ESXi phải chọn đường nào dùng.

ESXi Host
  │
  ├── HBA 1 ──┬── SAN Switch A ──┬── Storage Array
  │           │                   │     LUN_01
  └── HBA 2 ──┴── SAN Switch B ──┘
              
4 đường đi ti LUN_01:
  - HBA 1Switch AStorage
  - HBA 1Switch BStorage  
  - HBA 2Switch AStorage
  - HBA 2Switch BStorage

ESXi cấu hình multipath policy quyết định dùng đường nào.

3 Multipath Policies

1. Round Robin (RR)thông minh nhất

  • Lựa chọn đường đi luân phiên (random) qua các path.
  • Khi 1 path fail → chuyển sang path còn lại.
  • Cân bằng tải tốt — dùng được mọi path đồng thời.
  • ✅ Failover nhanh.
  • Production khuyến cáo cho hầu hết storage hiện đại.

2. Fixed — đường cố định

  • Chọn 1 path cố định (preferred path).
  • Khi path đó fail → chuyển sang path khác.
  • Khi path preferred sống lại → chạy về preferred ngay.
  • ⚠️ Nguy cơ "flap" — preferred sống/chết liên tục → path chuyển qua chuyển lại.

3. MRU (Most Recently Used)default của VMware

  • Tương tự Fixed (1 path cố định) nhưng:
  • Khi preferred fail → chuyển sang path khác.
  • Khi preferred sống lại → KHÔNG chạy về preferred (giữ ở path hiện tại).
  • ✅ Tránh "flap" của Fixed.

So sánh

Policy Path dùng Khi 1 path fail Khi recovered
Round Robin Tất cả Chuyển N/A (đã dùng all)
Fixed 1 (preferred) Chuyển Quay về preferred
MRU (default) 1 Chuyển Giữ path hiện tại

→ Production modern: Round Robin. Legacy/specific storage: theo recommendation của vendor.


vSAN — Software-Defined Storage (Đào sâu)

vSAN tận dụng các đĩa cứng gắn trên host để tạo thành 1 hệ thống lưu trữ duy nhất. Đây là tech quan trọng nhất của VMware modern — thay thế hoàn toàn SAN array trong nhiều use case.

┌──────────────────────────────────────────────────────────┐
│              vSAN Cluster (3+ host)                      │
│                                                           │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐          │
│   │  Host A  │    │  Host B  │    │  Host C  │          │
│   │          │    │          │    │          │          │
│   │  SSD     │    │  SSD     │    │  SSD     │          │
│   │  HDD HDD │    │  HDD HDD │    │  HDD HDD │          │
│   └────┬─────┘    └────┬─────┘    └────┬─────┘          │
│        │               │               │                 │
│        └───────────────┼───────────────┘                 │
│                  vSAN Network                            │
│                  (10Gb+ riêng)                           │
│                        │                                  │
│              ┌─────────┴─────────┐                       │
│              │  vSAN Datastore   │                       │
│              │  (logic duy nhất) │                       │
│              └───────────────────┘                       │
└──────────────────────────────────────────────────────────┘

Khi dùng vSAN, các host chỉ thấy 1 datastore duy nhất — pool tổng hợp.

Ưu điểm

  • Tiết kiệm chi phí — không cần mua storage array riêng.
  • Vẫn dùng được vMotion, HA, snapshot đầy đủ.
  • Scale-out — thêm host = thêm dung lượng + performance.
  • VM Storage Policies — set redundancy/IOPS per VM (qua software).

Điều kiện setup vSAN

  • Tối thiểu 3 host vật lý (production khuyến cáo 4+).
  • 1 đường mạng riêng cho vSAN (10 Gbps khuyến cáo).
    • Tách hoàn toàn với client traffic.
    • vSAN replication ngốn rất nhiều băng thông.
  • Mỗi host có ổ cứng (HDD/SSD).
  • Mỗi host tối thiểu 1 ổ SSD (cho cache layer).
  • Card RAID phải support passthrough hoặc RAID 0 (vSAN tự quản lý disk, không cần RAID).
  • RAM cho vSAN: 8-32 GB (chiếm RAM host).

Kiến trúc 2 lớp: Cache + Capacity

vSAN OSA (Original Storage Architecture) chia disk thành 2 lớp:

┌─────────────────────────────────────────────────┐
│                  Host                            │
│                                                  │
│   ┌──────────────────────────────────────┐      │
│   │       Disk Group 1                   │      │
│   │                                       │      │
│   │   ┌─────────────────────┐            │      │
│   │   │   Cache Layer       │            │      │
│   │   │   1 × SSD (NVMe)    │            │      │
│   │   │   (write buffer +   │            │      │
│   │   │    read cache)      │            │      │
│   │   └──────────┬──────────┘            │      │
│   │              │ flush                  │      │
│   │              ▼                        │      │
│   │   ┌─────────────────────┐            │      │
│   │   │   Capacity Layer    │            │      │
│   │   │   1-7 × HDD/SSD     │            │      │
│   │   │   (data thật)        │            │      │
│   │   └─────────────────────┘            │      │
│   └──────────────────────────────────────┘      │
│                                                  │
│   (Có thể có nhiều Disk Group/host)              │
└─────────────────────────────────────────────────┘

Cache Layer:

  • 1 SSD (tốt nhất là NVMe) bắt buộc per disk group.
  • Vai trò: write buffer + read cache.
  • Hybrid: 70% write buffer + 30% read cache.
  • All-Flash: 100% write buffer (capacity SSD đã đủ nhanh để read).
  • Cache disk không được thay đổi sau setup — phải xóa cả disk group để thay.

Capacity Layer:

  • 1-7 disk (HDD hoặc SSD) per disk group.
  • Chứa data thật sau khi flush từ cache.

⚠️ Tài liệu của bạn ghi "1 disk group có ít nhất 8 ổ cứng" — đây là confusion. Chuẩn VMware: 1 cache disk + 1 đến 7 capacity disk (tối đa 8 disks). Setup phổ biến: 1 cache + 4 capacity.

2 loại Disk Group

Loại Cache Capacity Performance Cost
Hybrid SSD HDD Trung bình Rẻ
All-Flash SSD SSD Rất cao Đắt hơn

Production hiện nay đa số dùng All-Flash — SSD enterprise đã rẻ hơn nhiều, performance worth it.


vSAN Write Operation — đường đi của write

Hiểu flow này để debug performance:

1. Guest OS ghi data (vd: 4KB block)
        │
        ▼
2. ESXi nhận request, vSAN check policy của VM:
   "VM này có FTT=1 → cần 2 copy"
        │
        ▼
3. vSAN ghi PARALLEL:
   ┌──► Cache SSD của Host A (copy 1)
   └──► Cache SSD của Host B (copy 2)
        │
        ▼ (chờ cả 2 ACK)
4. Trả "write OK" cho guest OS
        │
        ▼
5. Background: cache flush xuống capacity layer
   Host A: cache SSD → capacity HDD/SSD
   Host B: cache SSD → capacity HDD/SSD

Write latency = chậm nhất của 2 cache SSD + network round-trip. Đó là lý do vSAN cần:

  • NVMe cache (latency μs).
  • 10Gb+ network (RTT thấp).

vSAN Read Operation

1. Guest OS đọc data
        │
        ▼
2. vSAN check object location:
   "Block X có ở host A (primary), host B (replica)"
        │
        ▼
3. Đọc từ host nào tốt hơn:
   - Hybrid: ưu tiên đọc từ cache nếu hit, không thì capacity
   - All-Flash: đọc thẳng capacity (SSD đã đủ nhanh)
   - Có thể đọc song song từ 2 replica để load balance
        │
        ▼
4. Trả data cho guest

→ All-Flash thường read nhanh hơn Hybrid vì không tốn cache lookup.


RAID Modes — Mirror vs Erasure Coding

Đây là phần ít người biết nhưng quyết định dung lượng usable của vSAN.

vSAN OSA hỗ trợ 2 RAID modes:

RAID 1 — Mirroring (default)

Tạo nhiều bản copy của data. Đơn giản nhất.

VM data block (1GB)
        │
        ▼ FTT = 12 copies
   ┌────┴────┐
   ▼         ▼
Host A    Host B
 1GB       1GB

Total usable: 1GB
Total raw consumed: 2GB
Storage efficiency: 50%
  • FTT = 1 → 2 copies → tốn 200% dung lượng.
  • FTT = 2 → 3 copies → tốn 300%.
  • ✅ Performance write tốt.
  • ❌ Tốn dung lượng.

RAID 5/6 — Erasure Coding (EC)

Chia data thành blocks + parity — giống RAID 5/6 truyền thống.

RAID 5 (FTT=1) - cần tối thiểu 4 host:

VM data block (1GB)
        │
        ▼ chia 3 data + 1 parity
   ┌────┬────┬────┬────┐
   ▼    ▼    ▼    ▼
Host  Host  Host  Host
 A    B    C    D
 D1   D2   D3   P
333MB 333  333  333

Total usable: 1GB
Total raw: 1.33GB
Storage efficiency: 75%
  • RAID 5 (FTT=1): cần 4+ host. Storage efficiency 75% (tiết kiệm 50% so với mirror).
  • RAID 6 (FTT=2): cần 6+ host. Storage efficiency 67%.
  • Tiết kiệm dung lượng nhiều.
  • ❌ Write performance kém hơn mirror (cần tính parity).
  • ❌ Chỉ All-Flash hỗ trợ (Hybrid không có).

Khi nào dùng gì

Workload RAID mode
VM critical, latency-sensitive (DB, app real-time) RAID 1 Mirror
File server, VDI, backup, archive RAID 5/6 Erasure Coding
Hybrid cluster Phải dùng RAID 1 (EC chỉ All-Flash)
Cluster < 4 host RAID 1 (EC cần 4+)

→ Production thường mix: critical VM dùng RAID 1, các VM khác dùng RAID 5.


VM Storage Policies — đào sâu

Mỗi VM trong vSAN có storage policy riêng, quyết định cách lưu data. Các thuộc tính:

1. Failures to Tolerate (FTT)

Số host/component die mà VM vẫn chạy được.

FTT RAID Mirror RAID EC Use case
0 1 copy N/A Test/dev, không quan trọng
1 (default) 2 copies RAID 5 (4+ host) Production VM thông thường
2 3 copies RAID 6 (6+ host) Mission-critical
3 4 copies N/A Cực kỳ critical

2. Failure Tolerance Method (FTM)

Chọn RAID mode:

  • RAID-1 (Mirroring) — Performance ưu tiên.
  • RAID-5/6 (Erasure Coding) — Capacity ưu tiên.

3. Number of Disk Stripes per Object (Stripe Width)

Phân tán data qua bao nhiêu disk để tăng IOPS.

Stripe Width = 1 (default): 
   Block A nằm trên 1 disk
   
Stripe Width = 4:
   Block A chia thành 4 phần, mỗi phần trên 1 disk khác
   → 4x IOPS song song
  • Default: 1 (đủ cho hầu hết workload).
  • Tăng lên 2-4 cho DB high-IOPS.
  • Max: 12.

4. IOPS Limit per Object

Giới hạn IOPS cho VM (chống 1 VM ngốn hết throughput).

IOPS Limit = 5000 → VM tối đa 5000 IOPS, vượt thì throttle.
0 = không giới hạn (default).

Use case: noisy neighbor, multi-tenant cluster.

5. Object Space Reservation (OSR)

% dung lượng được reserve cứng.

  • 0% (default — thin): không reserve, ăn dần khi VM ghi.
  • 100% (thick): reserve toàn bộ dung lượng VM lúc tạo.

Thin tiết kiệm space, thick đảm bảo VM không bao giờ thiếu space.

6. Flash Read Cache Reservation

% cache SSD reserved cho VM (chỉ Hybrid).

Default: 0 (share cache với mọi VM). Cao hơn = ưu tiên cho VM critical.

7. Disable Object Checksum

vSAN mặc định check checksum mọi block (bảo vệ silent data corruption). Tắt = nhanh hơn nhưng risk hơn. Production luôn để Enable.

8. Force Provisioning

Cho phép tạo VM kể cả khi không đủ host/disk để đáp ứng policy. Cẩn thận — VM sẽ ở trạng thái non-compliant cho đến khi đủ resource.

Ví dụ policy thực tế

Policy "Tier-1-Database":
  FTT:                  1
  FTM:                  RAID-1 Mirror   (performance)
  Stripe Width:         4               (parallel IOPS)
  IOPS Limit:           0               (unlimited)
  Reservation:          100%            (thick)
  Checksum:             Enable
   Cho VM database critical, performance ưu tiên

Policy "Tier-3-Archive":
  FTT:                  1
  FTM:                  RAID-5 EC      (tiết kiệm space)
  Stripe Width:         1
  IOPS Limit:           1000            (cap)
  Reservation:          0%              (thin)
   Cho VM archive, tiết kiệm dung lượng

→ Cùng vSAN datastore, nhiều VM, mỗi VM 1 policy. Magic của vSAN.


Failure Scenarios — vSAN xử lý như thế nào

Hiểu các kịch bản fail để design đúng:

Scenario 1: 1 disk capacity die

FTT = 1, RAID 1:
  Copy 1 ở Host A (disk X) → disk X die
  Copy 2 ở Host B (disk Y) → vẫn còn
  
vSAN:
  → VM tiếp tục chạy (đọc từ copy 2)
  → Background rebuild copy mới sang disk khác
  → 60 phút sau, FTT compliance restored

Scenario 2: 1 host die

Cluster 4 host, FTT = 1:
  Host A die → mất tt cả disk group trên host A
  
vSAN:
  → VM trên host A → vSphere HA restart trên host khác
  → Các VM khác: data có copy ở host khác → vẫn chạy
  → Background rebuild data thiếu sang host còn lại
  → Sau 60 phút (default CLOM repair delay), nếu host A chưa quay lại → bắt đầu rebuild

Scenario 3: 1 disk cache die

Cache disk die → CẢ disk group offline (mất tất cả capacity của group đó)

vSAN:
  → Tất cả VM data trên disk group đó: phải failover sang copy khác
  → Rebuild lại disk group sau khi thay cache

⚠️ Cache disk die nghiêm trọng hơn capacity die. Nên dùng NVMe enterprise + có disk group dự phòng (multi disk group per host).

Scenario 4: Network partition (split brain)

Network giữa host bị cắt → cluster chia 2 nhóm:
  Group A: 2 host
  Group B: 2 host
  
vSAN quorum:
  → Cần > 50% host để hoạt động
  → 2/4 = 50%, không đủ
  → Cluster bị "stuck" → cần witness/admin can thiệp

→ Đây là lý do production thường có Witness Host (xem Stretched Cluster).


vSAN Stretched Cluster — cross-site HA

Stretched Cluster = vSAN cluster trải dài 2 site (datacenter), bảo vệ khỏi disaster cả site.

┌─────────────────────────┐    ┌─────────────────────────┐
│       Site A             │    │       Site B             │
│       (Hà Nội)           │    │       (Sài Gòn)          │
│                          │    │                          │
│   ┌─────┐ ┌─────┐        │    │   ┌─────┐ ┌─────┐        │
│   │Host1│ │Host2│        │    │   │Host3│ │Host4│        │
│   └─────┘ └─────┘        │    │   └─────┘ └─────┘        │
└──────────┬───────────────┘    └───────────┬─────────────┘
           │                                 │
           │       <5ms RTT, 10Gb+           │
           └────────────┬────────────────────┘
                        │
                        ▼
              ┌──────────────────┐
              │   Witness Host   │   ← site th3 (cloud, branch office)
              │   (chỉ vote)     │
              └──────────────────┘

3 thành phần:

  • Site A (primary) — half cluster, các host vSAN data.
  • Site B (secondary) — half cluster, các host vSAN data, cross-replication với A.
  • Witness Host — site thứ 3, chỉ giữ metadata + vote (không data).

VM Storage Policy đặc biệt cho Stretched: PFTT (Primary FTT)SFTT (Secondary FTT):

  • PFTT — failure tolerance giữa các site (mirror cross-site).
  • SFTT — failure tolerance trong cùng site.

Ví dụ: PFTT=1 (mirror A↔B) + SFTT=1 (mirror within site) → max protection.

⚠️ Yêu cầu: <5ms RTT giữa 2 site, 10Gb+ network, license Enterprise Plus.


Deduplication & Compression — tiết kiệm dung lượng

vSAN All-Flash hỗ trợ 2 feature giảm dung lượng:

Deduplication

Loại bỏ block trùng lặp giữa các VM.

VM1 và VM2 đều cài Windows Server 2022:
  → Block giống nhau (system files)
  
Không dedup:
  Tổng disk: 2 × 50GB = 100GB

Với dedup:
  System blocks chỉ ghi 1 lần
  Tổng disk: ~60GB (giảm 40%)

Compression

Nén block trước khi ghi (LZ4 algorithm).

  • Tỉ lệ nén trung bình 1.5-2x cho text/code, 1.1x cho media.
  • CPU overhead ~5-10%.

Bật/tắt

Trong vSAN config: Services → Deduplication and compression → On/Off.

⚠️ Cluster-wide setting — apply hoặc tắt toàn cluster, không per VM. Bật tắt có thể trigger full rebuild data.

Khuyến cáo: All-Flash production → bật cả 2. Tiết kiệm 30-50% dung lượng. Hybrid không hỗ trợ.


vSAN OSA vs ESA (vSAN 8+)

vSAN từ version 8 có 2 architecture:

Original Storage Architecture (OSA)

  • Disk group: cache + capacity (như đã học).
  • Hybrid + All-Flash.
  • Tương thích ngược.
  • Hỗ trợ mọi version vSAN.

Express Storage Architecture (ESA) — mới từ vSAN 8

ESA:
  - KHÔNG có disk group concept
  - Mọi disk đều là "capacity" (single tier)
  - Tất cả disk phải là NVMe TLC SSD
  - Performance gấp 2-4x OSA
  - Native erasure coding (RAID 5 với 3 host, RAID 6 với 4 host)
  - Built-in compression always-on

Differences:

Feature OSA ESA
Disk hierarchy Cache + Capacity Single tier
Disk type HDD/SSD Chỉ NVMe TLC
Min host cho RAID 5 4 3
Min host cho RAID 6 6 4
Compression Optional Always on
Performance Tốt Rất tốt
Hardware cost Vừa Cao hơn

→ ESA là tương lai. Hardware mới mua production nên cân nhắc ESA.


Performance Tuning Tips

  1. NVMe cho cache layer (OSA) — latency μs, khác biệt rất lớn với SAS SSD.

  2. 10Gb minimum, 25Gb recommended cho vSAN network.

  3. Tách vSAN network qua physical NIC riêng — không share với client/vMotion.

  4. MTU 9000 trên vSAN network — improve throughput 10-15%.

  5. RDMA (RoCE) — nếu NIC support, bật RDMA cho vSAN → latency giảm 30%.

  6. Stripe Width tăng cho IOPS-heavy VM — DB, log server.

  7. All-Flash > Hybrid — chênh lệch cost ngày càng nhỏ, performance khác biệt.

  8. Monitor vsan-health-status — có dashboard built-in trong vCenter.

  9. Capacity utilization < 70% — vSAN cần free space cho rebuild + maintenance.

  10. Tránh single disk group per host — host die = mất nhiều data. Mỗi host 2-3 disk group recommended.


Virtual Volumes (vVOLs)

vVOLs là kiến trúc storage mới hơn — mỗi VM là 1 storage object trên storage array.

  • Storage array phải support vVOLs (Pure Storage, NetApp, Dell EMC...).
  • Kết nối qua FC hoặc Ethernet.
  • Khái niệm Storage Container thay cho LUN/datastore.
  • Storage policy giống vSAN nhưng apply ở storage array.

Production chưa phổ biến vì cần storage array vVOLs-capable. Skip nếu không có.


Raw Device Mapping (RDM)

RDM cho phép kết nối trực tiếp đĩa cứng (LUN) vào VM, không qua VMFS.

Bình thường:
  VM ──► .vmdk file ──► VMFS Datastore ──► LUN

RDM:
  VM ──► .vmdk mapping ──► RAW LUN (direct)

Cách hoạt động

  • Tạo ra 2 file:
    • vm-name.vmdk — descriptor (metadata).
    • vm-name-rdm.vmdkmapping file ánh xạ tới LUN thật.
  • VM truy cập LUN qua mapping file, không qua VMFS layer.

Đặc điểm

  • ⚠️ Xóa file .vmdk → mất kết nối VM-LUN, NHƯNG data ở LUN không mất. Lý do: data nằm ở raw LUN, không nằm trong file vmdk.
  • Re-attach LUN lại VM khác hoặc remap được.

Khi nào dùng RDM

  • VM cluster shared storage — Microsoft Cluster Service (MSCS), Oracle RAC. Cần shared raw block storage.
  • Application yêu cầu access disk trực tiếp — vd: backup tool, database performance đặc biệt.
  • SAN management software — quản lý LUN từ trong VM.

Production hiện đại ít dùng RDM — đa số case dùng VMFS hoặc vVOLs.


Fibre Channel (FC) — chuẩn enterprise

FC là protocol cao cấp cho SAN storage, dùng phổ biến trong enterprise.

Yêu cầu setup FC

3 thành phần:

  • Host — phải có HBA (Host Bus Adapter) FC card.
  • SwitchSAN Switch chuyên dụng cho FC (Brocade, Cisco MDS).
  • StorageFC storage array (Dell EMC, NetApp, HPE 3PAR/Primera).

Ưu/Nhược

✅ Ưu điểm:

  • Tốc độ truyền rất cao — 32 Gbps (FC Gen 7), so với Ethernet 10/25 Gbps.
  • Latency thấp — protocol optimize cho storage.
  • Reliability cao — dedicated network, không share traffic.

❌ Nhược:

  • Chi phí đầu tư cao — HBA, switch, cáp quang đều đắt.
  • Yêu cầu skill chuyên — zoning, masking phức tạp hơn TCP/IP.

→ Production enterprise lớn dùng FC. SMB thường dùng iSCSI (rẻ hơn, đủ dùng).


Câu chuyện thực tế

Năm 2020, mình setup vSAN cluster cho 1 ngân hàng. Plan: 4 host, mỗi host 2 SSD cache + 8 HDD capacity. Lý thuyết throughput rất cao.

Cài xong, test với 10 VM workload nhẹ → OK. Đưa lên production với 50 VM. 1 tuần sau, VM bắt đầu slow inexplicably.

esxtop trên host:

Disk latency: 200-500ms   ← Khủng khiếp. Bình thường < 10ms
Network rx/tx: bình thường
CPU: 60%

Disk latency cao đỉnh điểm 500ms — chậm hơn 50 lần bình thường. Nhưng disk SSD và HDD đều healthy, không SMART error.

3 ngày sau mới tìm ra: vSAN network chỉ 1 Gbps, không phải 10 Gbps như khuyến cáo.

Lúc setup, mình check trong cluster:

esxcfg-nics -l
# vmnic0  1000Mb/s  ← 1Gb
# vmnic1  1000Mb/s  ← 1Gb

Tưởng là OK vì có 2 NIC team. Nhưng vSAN với 50 VM ghi đồng thời cần băng thông khủng — 1Gb hoàn toàn không đủ.

50 VM × ~20 MB/s write trung bình = 1000 MB/s = 8 Gbps
→ 1 Gbps NIC bị nghẽn hoàn toàn → latency tăng đột biến

Fix: thay 10Gb card cho từng host (4 host × $500/card = $2000). Reconfig vSAN network. Disk latency giảm xuống 5-10ms. Performance gấp 50 lần.

Bài học:

  1. Đọc kỹ requirements vSAN. "Khuyến cáo 10Gb" không phải optional — là bắt buộc cho production.

  2. Test với production-like workload trước khi đưa thật. 10 VM test không phản ánh 50 VM thật.

  3. Monitor disk latency liên tục. Spike > 50ms = cảnh báo. > 200ms = critical.

  4. vSAN network phải riêng, không share với client traffic / vMotion.

  5. Đầu tư hardware đúng từ đầu rẻ hơn fix sau. $2000 NIC tiết kiệm cả tháng debug + customer impact.


Lab — thực hành

Lab 1: Tạo Standard Switch + Port Group

Trong vSphere Client → chọn host → Configure → Networking → Virtual switches → Add Networking:

1. Connection type: Virtual Machine Port Group for a Standard Switch
2. Select target device: New standard switch
3. Assign physical adapter: vmnic1 (uplink)
4. Connection settings:
   - Network label: "Production-Network"
   - VLAN ID: 10
5. Finish

Verify:

Networking → Virtual switches → thy vSwitch1 mới với uplink vmnic1

Lab 2: Mount NFS Datastore

Trên 1 NFS server (vd: Synology, FreeNAS, hoặc Linux server với nfs-server):

# Trên NFS server (Linux):
mkdir -p /export/vmware
echo "/export/vmware 192.168.32.0/24(rw,sync,no_root_squash)" >> /etc/exports
exportfs -ra

Trên vSphere Client:

Datacenter → Storage → New Datastore
  → Type: NFS
  → NFS version: NFS 3 (or 4.1)
  → Name: nfs-shared
  → Server: 192.168.32.50Folder: /export/vmware
  → Mount to: chọn host(s)

Verify datastore xuất hiện trong list.

Lab 3: Tạo VMFS Datastore từ local disk

(Cần host có disk trống chưa format.)

StorageNew Datastore
  → Type: VMFS
  → Name: local-vmfs
  → Disk: chọn disk available
  → VMFS version: VMFS 6Partition: full disk
  → Finish

Lab 4: Test Multipath với 1 LUN

StorageDatastoreManage pathsPath Selection PolicyRound Robin

Save → Datastore now uses RR for all paths.

Lab 5: Quan sát network policies

vSwitch → Edit Settings → Policies:
  → Security: thử toggle Promiscuous, MAC Changes, Forged Transmits
  → Traffic Shaping: bật, set 1000 kbps average
  → Teaming: thay load balancing algorithm

Test impact với traffic thật (iperf giữa 2 VM).


Pitfalls

  1. VLAN ID trên port group khác VLAN trunk switch vật lý → VM không thấy network. Confirm trunk config trước.

  2. Standard Switch không sync giữa các host → vMotion VM xong, port group khác config → VM mất kết nối. Production dùng Distributed Switch hoặc script sync.

  3. MTU 9000 không end-to-end → fragment → chậm hơn 1500. Test vmkping -d -s 8972 toàn đường.

  4. Promiscuous Mode để Accept ở production → security hole. Default phải Reject.

  5. Forged Transmits Accept trong khi không dùng Microsoft NLB → cho phép MAC spoofing.

  6. Beacon Probing với chỉ 2 uplink → không hoạt động (cần ≥ 3). Stick với Link Status Only.

  7. VMFS không giảm được dung lượng → cấp dư là mất luôn. Tính kỹ trước.

  8. Upgrade VMFS 5 → VMFS 6 không khả thi — phải Storage vMotion VM sang datastore VMFS 6 mới.

  9. Delete datastore thay vì Unmount → mất sạch data. Luôn Unmount + verify trước.

  10. vSAN network 1Gbps trong production → latency cao, performance kém. Bắt buộc 10Gb riêng.

  11. vSAN không có cache SSD → fail setup. Mỗi host tối thiểu 1 SSD.

  12. RDM nhầm với VMDK → xóa wrong file. Hiểu rõ trước khi đụng RDM.

  13. Multipath policy Fixed gây flap khi path không ổn định → traffic chuyển qua chuyển lại. Dùng MRU hoặc RR.

  14. iSCSI traffic chung VLAN với VM traffic → bottleneck + security risk. Tách VLAN riêng.


Tóm tắt

Virtual Network

  • vSwitch = bridge giữa VM và network vật lý. Có VM port group + VMkernel port + uplink port.
  • Standard Switch = 1 host. Distributed Switch = nhiều host (cần Enterprise Plus + vCenter).
  • VLAN ăn theo switch vật lý — vSwitch không tạo VLAN mới.
  • VMkernel port dùng cho ESXi: management, vMotion, storage, vSAN, FT.
  • MTU 9000 (jumbo frame) cho storage/vMotion — phải end-to-end.
  • Security: Reject hết (promiscuous, MAC change, forged transmits) — production default.
  • Load balancing 4 algorithm: Originating Virtual Port (default), Source MAC, IP Hash (cần LACP), NIC Load (vDS).
  • Beacon Probing cần ≥ 3 uplink. Link Status Only đủ cho 2 uplink.

Storage

  • 4 datastore types: VMFS, NFS, vSAN, vVOLs.
  • Storage taxonomy: Local (DAS) / SAN (FC/FCoE/iSCSI, block) / NAS (NFS, file).
  • VMFS = file system VMware, cluster-aware, max 64TB. Không giảm được dung lượng.
  • Extend (thêm disk) vs Expand (resize disk hiện tại). Expand đơn giản hơn.
  • Maintenance Mode cần không VM nào còn trên datastore.
  • Unmount ≠ Delete. Luôn Unmount trước.
  • Multipath: Round Robin (recommend), Fixed, MRU (default).
  • vSAN architecture 2 lớp: Cache (NVMe SSD) + Capacity (HDD/SSD). 1 disk group = 1 cache + 1-7 capacity.
  • vSAN cần 3+ host, 10Gb+ network riêng, RAID passthrough.
  • Write flow vSAN: ghi parallel ra N cache SSD theo FTT, sau đó flush xuống capacity.
  • 2 RAID modes vSAN: Mirror (RAID 1, perf, tốn space) vs Erasure Coding (RAID 5/6, tiết kiệm 50% space, cần All-Flash + 4-6 host).
  • VM Storage Policies: FTT, FTM, Stripe Width, IOPS Limit, Reservation, Checksum, Force Provisioning. Mỗi VM 1 policy.
  • Stretched Cluster: 2 site + Witness, PFTT (cross-site) + SFTT (within-site), cần <5ms RTT.
  • Dedup + Compression: chỉ All-Flash, tiết kiệm 30-50% dung lượng, cluster-wide.
  • vSAN ESA (v8+): single-tier NVMe only, performance gấp 2-4x OSA, RAID 5 chỉ 3 host.
  • RDM = VM access raw LUN trực tiếp. Dùng cho MSCS, Oracle RAC.
  • FC = enterprise SAN, 32Gbps, đắt nhưng tin cậy.

Bài tiếp: 04 — Cluster, vMotion, HA, DRS (Capstone). Khi mọi thứ tự động: HA tự restart VM, DRS tự cân bằng tải, vMotion không gián đoạn.

← Bài trước
Bài 02
Bài tiếp theo →
Bài 04
Zalo tư vấn