Posted inVMware

Cấu hình vCenter Server High Availability (vCenter HA): Loại Bỏ Single Point of Failure Cho Hệ Thống vSphere

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

Sau khi vCenter bị down đúng lúc đang trình demo cho khách hàng — toàn bộ datacenter mất khả năng quản lý tập trung trong 45 phút — mình quyết định không bao giờ để tình huống đó xảy ra lần nữa. vCenter HA là thứ mình nên cấu hình từ ngày đầu, không phải sau khi có incident.

Bài này viết dựa trên kinh nghiệm triển khai vCenter HA trên production với VCSA 8.0.2, sau 6 tháng vận hành thực tế — bao gồm cả một lần failover ngoài kế hoạch lúc 2 giờ sáng.

Quick Start — Bật vCenter HA trong 5 phút

Trước khi đi sâu vào lý thuyết, đây là cách nhanh nhất để kiểm tra môi trường của bạn có đủ điều kiện không:

Kiểm tra điều kiện tiên quyết

  • vCenter Server Appliance (VCSA) 6.5 trở lên — không hỗ trợ Windows vCenter
  • License vSphere Enterprise Plus hoặc vSphere+
  • Tối thiểu 3 ESXi host để phân tán 3 node HA lên các host riêng biệt
  • Dải IP riêng cho HA network, tách biệt management network

Các bước cấu hình nhanh

  1. Đăng nhập vSphere Client → click vào vCenter Server của bạn trong inventory
  2. Vào Configure → vCenter HA
  3. Click Set Up vCenter HA
  4. Chọn Basic — wizard tự động tạo Passive node và Witness node
  5. Điền IP cho HA network, Passive node, Witness node
  6. Click Finish — đợi khoảng 30–45 phút để clone và sync

Vậy là xong phần thiết lập cơ bản. Nhưng nếu bạn muốn hiểu thực sự đang xảy ra gì bên dưới — và tại sao nên test failover trước khi đưa vào production — thì đọc tiếp.

Kiến trúc vCenter HA hoạt động như thế nào

vCenter HA tạo ra một cụm 3 node từ VCSA của bạn:

  • Active node: VCSA hiện tại, xử lý toàn bộ workload quản lý vSphere
  • Passive node: Bản clone của Active, nhận stream dữ liệu real-time qua HA network, luôn sẵn sàng thay thế
  • Witness node: Node “trọng tài” nhỏ gọn (2 vCPU, 8GB RAM), chỉ dùng để phá thế tie-break khi xảy ra split-brain

Khi Active bị lỗi, Passive tự động promote thành Active mới — thường trong vòng 4–8 phút, không cần thao tác thủ công. VIP (Virtual IP) của vCenter chuyển sang Passive, mọi client kết nối lại bình thường.

Mạng HA — Điểm dễ bỏ sót nhất

Phần mình thấy nhiều người cấu hình sai nhất là mạng. vCenter HA cần hai mạng riêng biệt:

  • Management network: Mạng thông thường đã có sẵn
  • HA network: Mạng riêng cho replication heartbeat — băng thông cao, độ trễ thấp

Nếu dùng chung một mạng, VCHA vẫn chạy được nhưng khả năng phát hiện lỗi chậm hơn và replication có thể bị ảnh hưởng khi mạng management bận. Tách riêng ra, mọi thứ sẽ ổn định hơn nhiều.

Phân bổ tài nguyên cho 3 node

Active và Passive có cùng specs vì Passive là bản clone. Witness thì nhẹ hơn nhiều:

# Thông số mặc định Witness node
vCPU: 2
RAM: 8 GB
Disk: ~10 GB (chỉ lưu metadata, không lưu data thực)

Mình hay khuyến nghị: đặt 3 node trên 3 ESXi host vật lý khác nhau, lý tưởng nhất là trên 3 rack hoặc nguồn điện độc lập. Nếu cả cụm cùng nằm trên một rack mất điện — HA cũng không cứu được.

Cấu hình nâng cao

Advanced mode: Tự kiểm soát node placement

Thay vì chọn Basic, dùng Advanced khi bạn cần:

  • Tự chỉ định Passive và Witness lên host cụ thể (tránh DRS tự di chuyển)
  • Dùng datastore riêng cho từng node
  • Cấu hình IP thủ công theo subnet hiện có của tổ chức

Kiểm tra trạng thái VCHA qua API

# Lấy session token
SESSION=$(curl -sk -X POST \
  -u [email protected]:YourPassword \
  https://vcenter.lab.local/api/session \
  -H "Content-Type: application/json" | tr -d '"')

# Kiểm tra health state của VCHA cluster
curl -sk \
  https://vcenter.lab.local/api/vcenter/vcha/cluster \
  -H "vmware-api-session-id: $SESSION" | python3 -m json.tool

Output trả về mode hiện tại (ENABLED/DISABLED/MAINTENANCE), active node IP, và health state. Mình tích hợp cái này vào Nagios để alert khi cluster không ở trạng thái HEALTHY.

Test failover chủ động — Bắt buộc trước khi production

Đây là bước mình bắt buộc thực hiện ngay sau khi setup xong, trước khi bàn giao:

# Kích hoạt failover thủ công qua vSphere Client:
# Configure → vCenter HA → Initiate Failover

# Hoặc qua VCHA CLI trên Active node (SSH vào VCSA)
/usr/lib/vmware-vcha/bin/vcha-vmafd-util --mode FAILOVER

Lần đầu mình test, phát hiện firewall chặn port 8182 giữa Passive và Witness — thứ chỉ xuất hiện khi thực sự trigger failover, không phải lúc setup. Nếu không test trước, sẽ phát hiện ra vào đúng lúc cần nhất.

Tips thực tế từ 6 tháng production

1. Script monitoring health tự động

#!/bin/bash
# Chạy mỗi 5 phút qua cron để monitor VCHA health
VCENTER="vcenter.lab.local"
SESSION=$(curl -sk -X POST -u admin:pass \
  https://$VCENTER/api/session \
  -H "Content-Type: application/json" | tr -d '"')

STATUS=$(curl -sk \
  https://$VCENTER/api/vcenter/vcha/cluster \
  -H "vmware-api-session-id: $SESSION" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('health_state','UNKNOWN'))")

if [ "$STATUS" != "HEALTHY" ]; then
  echo "ALERT: vCenter HA status is $STATUS" | \
    mail -s "[CRITICAL] vCHA Alert" [email protected]
fi

2. Quy trình update đúng cách

Khi patch vCenter, phải làm đúng thứ tự — sai bước là mất vài tiếng restore:

  1. Vào Configure → vCenter HA → Enter Maintenance Mode
  2. Update Active node qua VAMI (https://vcenter:5480)
  3. Verify hoạt động bình thường sau update
  4. Exit Maintenance Mode — VCHA tự đồng bộ Passive

Nếu update khi đang ở ENABLED mode và VCSA restart giữa chừng, có nguy cơ split-brain. Mình đã gặp trường hợp này một lần và mất 2 tiếng để restore lại trạng thái cụm.

3. HA network bandwidth thực tế

Trong môi trường với khoảng 200 VM, replication traffic thường ở mức 50–100 Mbps khi idle và spike lên 300–400 Mbps sau khi có thay đổi lớn như deploy hàng loạt VM hoặc vMotion đồng thời. Đảm bảo HA network tối thiểu 1 Gbps, tốt nhất 10 Gbps nếu môi trường lớn.

4. Backup VCSA vẫn cần thiết song song

vCenter HA bảo vệ khỏi host failure nhưng không thay thế được backup. Nếu database VCSA bị corrupt — cả Active lẫn Passive đều corrupt vì sync real-time. Vẫn phải schedule backup định kỳ:

# Cấu hình backup qua VCSA VAMI
https://vcenter.lab.local:5480
# → Backup → Schedule Backup
# Hỗ trợ: FTP, FTPS, HTTP, HTTPS, SCP

5. So sánh với Proxmox khi mình migrate lab cá nhân

Khi migrate từ VMware sang Proxmox cho lab cá nhân để cắt chi phí license, mình nhận ra một điểm thú vị: Proxmox dùng cluster quorum (Corosync) ở tầng hypervisor, nhưng Proxmox VE Manager — lớp quản lý — vẫn là single point of failure trừ khi bạn tự dựng HA riêng cho nó. Chính sự so sánh này giúp mình hiểu rõ tại sao VMware tích hợp sẵn HA cho management layer: đó là thứ enterprise thực sự cần khi SLA không cho phép vCenter down dù chỉ 30 phút.

Khi nào không cần vCenter HA

Không phải môi trường nào cũng cần:

  • Lab nhỏ, dev/test không có SLA cam kết
  • Chỉ có 1–2 ESXi host, không đủ để phân tán 3 node an toàn
  • Budget không cho phép license Enterprise Plus

Trong các trường hợp đó, backup VCSA đầy đủ với RTO chấp nhận được — restore từ backup mất 1–2 tiếng — là giải pháp thực tế hơn. Nhưng nếu bạn đang vận hành datacenter với SLA 99.9%+, thì vCenter HA là thứ đáng đầu tư từ ngày đầu, không phải sau khi có sự cố.

Share:
Tags: