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:
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.
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.
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.
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.
UD1 → reboot → wait 30min
UD2 → reboot → ...
Kết quả: không mất tất cả VM cùng lúc
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.
FD1: Rack B (power-B, switch-B)
FD2: Rack C (power-C, switch-C)
Power-A lỗi → chỉ FD0 bị ảnh hưởng
3. Availability Zones & Scaling Strategies
- • 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
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.
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.
- 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.
- 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.
- • Metric: CPU% > 75% trong 5 phút
- • Action: Tăng 2 instance
- • Cooldown: 5 phút (không scale tiếp)
- • Max instances: 10
- • Metric: CPU% < 25% trong 10 phút
- • Action: Giảm 1 instance
- • Cooldown: 10 phút
- • Min instances: 2
- • 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
Bài Tập Thực Hành (Lab)
Tạo Availability Set và 2 VM Ubuntu trong cùng Set
# 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
Tạo VM Scale Set (Uniform) với Load Balancer
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
Cấu hình Autoscale — Scale Out khi CPU > 70%, Scale In khi CPU < 30%
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"
Manual Scale Test — Tăng instance count và xác nhận Load Balancer phân phối đều
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
Cleanup — Dọn dẹp toàn bộ tài nguyên Lab 22
# 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!"
Kết Quả Đầu Ra
Phân biệt planned/unplanned/unexpected downtime và chọn đúng giải pháp bảo vệ
Tạo Availability Set với đúng fault/update domain count, triển khai 2+ VM đạt SLA 99.95%
Nắm zone architecture, so sánh với Availability Set, biết khi nào dùng zones để đạt 99.99%
Chọn đúng chiến lược scale cho từng tình huống workload cụ thể
Tạo VMSS Uniform với Load Balancer, cài extension trên toàn bộ instance đồng loạt
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.
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.
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.
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.
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.
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.
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.
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.
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.
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ử.