MODULE 22 Compute 20–25% đề thi

Virtual Machine Availability

Bảo trì & downtime types, Availability Sets (update/fault domain), Availability Zones, vertical vs horizontal scaling, VM Scale Sets và cấu hình autoscale để đảm bảo SLA cao nhất cho ứng dụng Azure.

Lý Thuyết Cốt Lõi

1. Bảo Trì & Loại Downtime trong Azure VM

Hiểu nguyên nhân downtime giúp chọn đúng giải pháp availability. Azure có 3 tình huống gây VM restart nằm ngoài tầm kiểm soát của bạn:

Planned Maintenance

Azure cập nhật phần mềm host/hypervisor định kỳ. Thường không gây reboot — live migration chuyển VM sang host mới chỉ mất vài giây. Azure thông báo trước qua Service Health.

Unplanned Maintenance

Hardware vật lý lỗi đột ngột (CPU, RAM, disk host, switch). Azure tự động di chuyển VM sang hardware khỏe — VM restart. Không có thông báo trước.

Unexpected Downtime

Rack lỗi, mất điện datacenter, thiên tai. VM có thể down trong thời gian dài hơn. Availability Zones bảo vệ khỏi tình huống này bằng cách tách biệt datacenter vật lý.

Giải pháp Bảo vệ khỏi SLA Ghi chú
Single VM + Premium SSD Planned maintenance 99.9% Không redundant
Availability Set Planned + Unplanned (rack level) 99.95% Trong 1 datacenter
Availability Zones Planned + Unplanned + datacenter failure 99.99% Tách datacenter vật lý

2. Availability Sets — Update Domain & Fault Domain

Availability Set là logical grouping đảm bảo VM được phân tán trên nhiều physical hardware. VM phải được tạo vào Availability Set ngay từ đầu — không thể thêm sau.

Update Domain (UD)

Nhóm VM sẽ được reboot cùng lúc khi Azure thực hiện planned maintenance. Tối đa 20 UD (mặc định 5). Azure reboot từng UD một, đợi 30 phút trước khi sang UD kế tiếp.

UD0 → reboot → wait 30min
UD1 → reboot → wait 30min
UD2 → reboot → ...
Kết quả: không mất tất cả VM cùng lúc
Fault Domain (FD)

Nhóm VM dùng chung power supply và network switch. Tối đa 3 FD (mặc định 3, tùy region có thể là 2). Nếu rack lỗi điện, chỉ 1 FD bị ảnh hưởng.

FD0: Rack A (power-A, switch-A)
FD1: Rack B (power-B, switch-B)
FD2: Rack C (power-C, switch-C)
Power-A lỗi → chỉ FD0 bị ảnh hưởng
Best practice: Đặt ít nhất 2 VM trong Availability Set để đạt SLA 99.95%. Load Balancer đặt trước Availability Set để phân phối traffic. Tất cả VM trong set phải cùng role (không trộn web + DB vào 1 set).

3. Availability Zones & Scaling Strategies

Availability Zones
  • • Mỗi zone = 1 hoặc nhiều datacenter vật lý độc lập trong region
  • • Nguồn điện, làm mát, mạng riêng biệt
  • • Tối thiểu 3 zones/region (không phải mọi region đều có)
  • • Khoảng cách < 2ms giữa các zone trong cùng region
  • • Deploy VM vào Zone 1, 2, 3 để đạt SLA 99.99%
  • • Zone-redundant Load Balancer/storage đi kèm
Availability Set vs Zones
Tiêu chí Set Zones
SLA 99.95% 99.99%
Phạm vi 1 datacenter Multi-DC
Chi phí thêm Không Egress phí zone
Region support Mọi region Chọn lọc
Vertical Scaling (Scale Up/Down)

Thay đổi size của VM hiện có — thêm CPU/RAM bằng cách chọn size lớn hơn. Cần deallocate VM (thường gây downtime ngắn). Giới hạn bởi size lớn nhất Azure có.

Khi nào dùng:

DB server cần thêm RAM; ứng dụng không scale out được (single-instance license); tăng tạm thời trước sự kiện lớn.

Horizontal Scaling (Scale Out/In)

Thêm/bớt số lượng VM instance — nhiều VM nhỏ thay vì 1 VM lớn. Không downtime. Cần ứng dụng stateless hoặc dùng shared storage. VM Scale Sets tự động hóa.

Khi nào dùng:

Web tier, API gateway, stateless microservice; workload có traffic biến động theo giờ/ngày.

4. VM Scale Sets & Cấu Hình Autoscale

VM Scale Sets (VMSS) cho phép tạo và quản lý nhóm VM giống hệt nhau từ cùng 1 image. Hỗ trợ autoscale dựa trên metrics hoặc schedule. Tích hợp sẵn với Load Balancer và Application Gateway.

Orchestration Modes
  • Uniform: Tất cả instance cùng model, tối ưu cho workload đồng nhất (web tier, batch). Instance count lên đến 1,000.
  • Flexible: Mỗi instance có thể cấu hình riêng, kết hợp VM thông thường. Instance count lên đến 1,000. Hỗ trợ Availability Zones.
Upgrade Policy
  • Automatic: Azure cập nhật instance ngẫu nhiên — risk cao hơn.
  • Rolling: Cập nhật từng batch nhỏ, giữ số lượng instance healthy tối thiểu. Khuyến nghị cho production.
  • Manual: Bạn tự trigger upgrade từng instance — kiểm soát tuyệt đối.
Autoscale — Cấu hình quy tắc tự động scale
Scale-Out Rule (thêm VM)
  • • Metric: CPU% > 75% trong 5 phút
  • • Action: Tăng 2 instance
  • • Cooldown: 5 phút (không scale tiếp)
  • • Max instances: 10
Scale-In Rule (bớt VM)
  • • Metric: CPU% < 25% trong 10 phút
  • • Action: Giảm 1 instance
  • • Cooldown: 10 phút
  • • Min instances: 2
Schedule-based Scale
  • • Giờ cao điểm (8-18h): 5 instance
  • • Giờ thấp điểm (18-8h): 2 instance
  • • Cuối tuần: 1 instance
  • • Kết hợp metric + schedule
Flapping (ping-pong scale): Xảy ra khi scale-out và scale-in kích hoạt liên tục. Ngăn bằng cách đặt cooldown đủ dài (5–15 phút), ngưỡng scale-out > scale-in không chồng chéo, và dùng metric trung bình nhiều instance thay vì từng instance riêng lẻ.

Bài Tập Thực Hành (Lab)

Lab 22-A: Availability Set + 2 VM Lab 22-B: Tạo VMSS Uniform Lab 22-C: Cấu hình Autoscale Lab 22-D: Test Scale Out
1

Tạo Availability Set và 2 VM Ubuntu trong cùng Set

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell
# Biến môi trường
RG="rg-az104-m22"
LOCATION="southeastasia"
AS_NAME="avset-web-m22"
VNET="vnet-m22"

# Tạo Resource Group
az group create \
  --name $RG \
  --location $LOCATION \
  --tags Course=AZ-104 Module=22 Environment=Lab

# Tạo VNet
az network vnet create \
  --resource-group $RG \
  --name $VNET \
  --address-prefix 10.22.0.0/16 \
  --subnet-name subnet-web \
  --subnet-prefix 10.22.1.0/24

# Tạo Availability Set (3 Fault Domains, 5 Update Domains)
az vm availability-set create \
  --resource-group $RG \
  --name $AS_NAME \
  --platform-fault-domain-count 3 \
  --platform-update-domain-count 5 \
  --location $LOCATION

# Tạo VM 1 trong Availability Set
az vm create \
  --resource-group $RG \
  --name vm-web-m22-01 \
  --availability-set $AS_NAME \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --vnet-name $VNET \
  --subnet subnet-web \
  --admin-username azureadmin \
  --generate-ssh-keys \
  --storage-sku Premium_LRS \
  --tags Course=AZ-104 Module=22 Role=WebServer

# Tạo VM 2 trong cùng Availability Set
az vm create \
  --resource-group $RG \
  --name vm-web-m22-02 \
  --availability-set $AS_NAME \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --vnet-name $VNET \
  --subnet subnet-web \
  --admin-username azureadmin \
  --generate-ssh-keys \
  --storage-sku Premium_LRS \
  --tags Course=AZ-104 Module=22 Role=WebServer

# Kiểm tra fault domain và update domain assignment
az vm availability-set show \
  --resource-group $RG \
  --name $AS_NAME \
  --query "virtualMachines[].id" -o table
Verify Portal: Portal → rg-az104-m22 → avset-web-m22 → xác nhận 2 VM xuất hiện, mỗi VM được gán Fault Domain khác nhau (FD0 và FD1) và Update Domain khác nhau (UD0 và UD1).
2

Tạo VM Scale Set (Uniform) với Load Balancer

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell
RG="rg-az104-m22"
LOCATION="southeastasia"
VMSS_NAME="vmss-web-m22"

# Tạo VMSS Uniform với 2 instance ban đầu
# --lb tự động tạo Standard Load Balancer
# --upgrade-policy-mode Rolling để update an toàn
az vmss create \
  --resource-group $RG \
  --name $VMSS_NAME \
  --image Ubuntu2204 \
  --vm-sku Standard_B2s \
  --instance-count 2 \
  --vnet-name vnet-m22 \
  --subnet subnet-web \
  --admin-username azureadmin \
  --generate-ssh-keys \
  --storage-sku Premium_LRS \
  --upgrade-policy-mode Rolling \
  --lb "$VMSS_NAME-lb" \
  --backend-pool-name "$VMSS_NAME-bepool" \
  --lb-sku Standard \
  --orchestration-mode Uniform \
  --location $LOCATION \
  --tags Course=AZ-104 Module=22

# Cài Nginx trên tất cả instance qua Custom Script Extension
az vmss extension set \
  --resource-group $RG \
  --vmss-name $VMSS_NAME \
  --name CustomScript \
  --publisher Microsoft.Azure.Extensions \
  --version 2.1 \
  --settings '{"commandToExecute":"apt-get update && apt-get install -y nginx && systemctl enable nginx && systemctl start nginx"}'

# Mở port 80 để test
az vmss update-instances \
  --resource-group $RG \
  --name $VMSS_NAME \
  --instance-ids "*"

# Xem Public IP của Load Balancer
az network public-ip show \
  --resource-group $RG \
  --name "${VMSS_NAME}-lb-publicip" \
  --query ipAddress -o tsv 2>/dev/null || \
az network public-ip list \
  --resource-group $RG \
  --query "[0].ipAddress" -o tsv
Verify Portal: Portal → rg-az104-m22 → vmss-web-m22 → Instances → xác nhận 2 instance đang chạy. Vào Load Balancer → Frontend IP → mở trình duyệt với IP đó → thấy trang Nginx mặc định.
3

Cấu hình Autoscale — Scale Out khi CPU > 70%, Scale In khi CPU < 30%

Bash— Linux/macOS/Cloud Shell, KHÔNG chạy CMD
RG="rg-az104-m22"
VMSS_NAME="vmss-web-m22"

# Lấy Resource ID của VMSS
VMSS_ID=$(az vmss show \
  --resource-group $RG \
  --name $VMSS_NAME \
  --query id -o tsv)

# Tạo autoscale profile với metric rules
cat > /tmp/autoscale-m22.json << EOF
{
  "location": "southeastasia",
  "profiles": [
    {
      "name": "AutoScaleProfile-Web",
      "capacity": {
        "minimum": "2",
        "maximum": "8",
        "default": "2"
      },
      "rules": [
        {
          "metricTrigger": {
            "metricName": "Percentage CPU",
            "metricResourceUri": "$VMSS_ID",
            "timeGrain": "PT1M",
            "statistic": "Average",
            "timeWindow": "PT5M",
            "timeAggregation": "Average",
            "operator": "GreaterThan",
            "threshold": 70
          },
          "scaleAction": {
            "direction": "Increase",
            "type": "ChangeCount",
            "value": "2",
            "cooldown": "PT5M"
          }
        },
        {
          "metricTrigger": {
            "metricName": "Percentage CPU",
            "metricResourceUri": "$VMSS_ID",
            "timeGrain": "PT1M",
            "statistic": "Average",
            "timeWindow": "PT10M",
            "timeAggregation": "Average",
            "operator": "LessThan",
            "threshold": 30
          },
          "scaleAction": {
            "direction": "Decrease",
            "type": "ChangeCount",
            "value": "1",
            "cooldown": "PT10M"
          }
        }
      ]
    }
  ],
  "targetResourceUri": "$VMSS_ID"
}
EOF

# Áp dụng autoscale setting
az monitor autoscale create \
  --resource-group $RG \
  --resource $VMSS_ID \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name "autoscale-web-m22" \
  --min-count 2 \
  --max-count 8 \
  --count 2

# Thêm scale-out rule
az monitor autoscale rule create \
  --resource-group $RG \
  --autoscale-name "autoscale-web-m22" \
  --condition "Percentage CPU > 70 avg 5m" \
  --scale out 2 \
  --cooldown 5

# Thêm scale-in rule
az monitor autoscale rule create \
  --resource-group $RG \
  --autoscale-name "autoscale-web-m22" \
  --condition "Percentage CPU < 30 avg 10m" \
  --scale in 1 \
  --cooldown 10

echo "Autoscale profile đã tạo. Kiểm tra Portal → vmss-web-m22 → Scaling"
Verify Portal: Portal → vmss-web-m22 → Scaling → xác nhận autoscale "autoscale-web-m22" đang bật (Enabled), hiển thị 2 rules: scale-out CPU >70% và scale-in CPU <30%. Min=2, Max=8, Default=2.
4

Manual Scale Test — Tăng instance count và xác nhận Load Balancer phân phối đều

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell
RG="rg-az104-m22"
VMSS_NAME="vmss-web-m22"

# Xem số instance hiện tại
az vmss show \
  --resource-group $RG \
  --name $VMSS_NAME \
  --query sku.capacity -o tsv

# Manual scale lên 4 instance (bỏ qua autoscale tạm thời để test)
az vmss scale \
  --resource-group $RG \
  --name $VMSS_NAME \
  --new-capacity 4

# Đợi instance mới provision
az vmss wait \
  --resource-group $RG \
  --name $VMSS_NAME \
  --updated

# Liệt kê tất cả instance và trạng thái
az vmss list-instances \
  --resource-group $RG \
  --name $VMSS_NAME \
  --query "[].{ID:instanceId, Name:name, State:provisioningState, PowerState:powerState}" \
  -o table

# Lấy Public IP của LB và test
LB_IP=$(az network public-ip list \
  --resource-group $RG \
  --query "[?contains(name,'vmss-web-m22')].ipAddress" \
  -o tsv | head -1)

echo "Load Balancer IP: $LB_IP"
echo "Test bằng curl (mỗi request có thể tới instance khác nhau):"
for i in {1..5}; do
  curl -s --connect-timeout 5 "http://$LB_IP" | grep -o "Welcome to nginx" || echo "Request $i: timeout"
done
Verify Portal: Portal → vmss-web-m22 → Instances → xác nhận 4 instances đều ở trạng thái "Running". Vào Load Balancer → Backend pools → xác nhận 4 NIC được liệt kê trong backend pool với trạng thái Healthy.
5

Cleanup — Dọn dẹp toàn bộ tài nguyên Lab 22

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell
# Xóa toàn bộ Resource Group (kéo theo VMSS, LB, Availability Set, VNet, VM...)
az group delete --name rg-az104-m22 --yes --no-wait

echo "Resource Group rg-az104-m22 đang được xóa ở background."
echo "VMSS với 4 instance = 4x chi phí VM — luôn cleanup sau khi học!"
Lưu ý quan trọng: Standard Load Balancer tốn phí ngay cả khi không có traffic. VMSS với nhiều instance scale out = nhiều VM đang chạy song song. Luôn xóa RG hoặc scale về 0 instance sau khi học để tránh phí phát sinh ngoài ý muốn.

Kết Quả Đầu Ra

Phân tích downtime scenarios

Phân biệt planned/unplanned/unexpected downtime và chọn đúng giải pháp bảo vệ

Thiết lập Availability Set

Tạo Availability Set với đúng fault/update domain count, triển khai 2+ VM đạt SLA 99.95%

Hiểu Availability Zones

Nắm zone architecture, so sánh với Availability Set, biết khi nào dùng zones để đạt 99.99%

Phân biệt Vertical vs Horizontal

Chọn đúng chiến lược scale cho từng tình huống workload cụ thể

Triển khai VM Scale Sets

Tạo VMSS Uniform với Load Balancer, cài extension trên toàn bộ instance đồng loạt

Cấu hình Autoscale rules

Tạo metric-based autoscale, điều chỉnh threshold, cooldown để tránh flapping

Ứng Dụng Thực Tế

Tình huống 1: Sàn thương mại điện tử — Traffic đột biến ngày Black Friday

Platform bán hàng online của VN với 500,000 user đồng thời trong giờ cao điểm, bình thường chỉ 50,000. Cần scale nhanh mà không gây downtime hay mua thừa server quanh năm.

Giải pháp

VMSS Uniform cho web tier (stateless): min=5, max=50 instance Standard_D4s_v5. Schedule-based: tăng lên 20 instance từ 8h ngày Black Friday. Metric-based bổ sung: CPU >75% thêm 5 instance.

Triển khai

Application Gateway (WAF) trước VMSS để chặn bot. Database tier dùng Availability Zones (3 replicas SQL). Session state lưu vào Azure Cache for Redis — không lưu local để scale out được.

Lợi ích

Zero downtime khi traffic tăng 10x. Chi phí chỉ tăng khi cần — không mua server dư. SLA 99.99% cho database layer nhờ Availability Zones. Scale in tự động sau sự kiện tiết kiệm 80% chi phí.

Tình huống 2: Hệ thống HIS bệnh viện — Uptime 24/7 cho phần mềm quản lý bệnh nhân

Phần mềm quản lý hồ sơ bệnh nhân chạy trên 2 VM, không được phép down ngay cả khi Azure bảo trì. Dữ liệu phải an toàn tuyệt đối.

Giải pháp

2 VM app server trong Availability Set (2 FD, 2 UD) — Azure không reboot cả 2 cùng lúc. VM DB (SQL Server) dùng AlwaysOn AG với 2 node trong 2 Availability Zones — failover tự động <30 giây.

Triển khai

Internal Load Balancer phân phối traffic giữa 2 app VM. Azure Site Recovery nhân bản toàn bộ VM sang region thứ 2 (East Asia) — DR cho thảm họa region-wide. Backup hàng ngày qua Recovery Services Vault.

Lợi ích

Availability Set đảm bảo SLA 99.95% — ít hơn 4.4 giờ downtime/năm. Zone-redundant DB đạt 99.99%. Site Recovery RPO <30 giây, RTO <2 giờ. Đáp ứng yêu cầu kiểm toán Bộ Y tế về bảo toàn dữ liệu bệnh nhân.

Tình huống 3: Startup fintech — API gateway xử lý thanh toán real-time

API thanh toán cần xử lý 10,000 TPS giờ cao điểm (7-9 PM), 500 TPS giờ thấp điểm. Chi phí là ưu tiên hàng đầu — không muốn trả tiền cho capacity không dùng.

Giải pháp

VMSS Flexible cho payment API: Schedule scale-out lên 15 instance từ 18:30, scale-in về 2 instance lúc 22:00. Metric-based bổ sung: Network In bytes > threshold để bắt các spike bất ngờ. Standard_F4s_v2 (compute optimized) cho throughput cao.

Triển khai

Zone-redundant VMSS (spread qua 3 Availability Zones) — đạt SLA 99.99% cho payment gateway. Upgrade policy Rolling (batch size 20%) — zero downtime khi deploy version mới. Health probe HTTP /health trả 200 mới đưa vào LB pool.

Lợi ích

Chi phí infrastructure giảm 65% so với mua cố định 15 VM — chỉ trả 13 instance-hours/ngày thay vì 15*24=360. Deployment không gián đoạn dịch vụ. SLA phù hợp yêu cầu NAPAS về tỷ lệ uptime thanh toán điện tử.

Zalo