【AZ-104高分秘籍】：掌握虚拟机扩展集，轻松应对考试与生产环境挑战

第一章：虚拟机扩展集的核心概念与考试要点

虚拟机扩展集（Virtual Machine Scale Sets，简称 VMSS）是云计算平台中用于部署和管理大量相同配置虚拟机的自动化服务。它支持弹性伸缩、高可用性和统一配置管理，广泛应用于需要横向扩展的工作负载场景，如Web前端集群、微服务架构和批处理任务。

核心特性与工作原理

VMSS 通过定义一个虚拟机模板来创建一组一致性实例，并可结合负载均衡器和自动缩放规则实现动态资源调配。所有实例共享相同的操作系统镜像和配置，更新时可通过滚动升级策略减少服务中断。

• 自动伸缩：基于CPU使用率、内存或自定义指标动态增减实例数量
• 高可用性：实例分布在多个容错域中，提升系统稳定性
• 集中管理：通过单一模板更新数百台虚拟机的配置

常用操作指令示例

在 Azure CLI 中创建一个基本的虚拟机扩展集：

# 创建资源组
az group create --name myResourceGroup --location eastus

# 创建虚拟机扩展集
az vmss create \
  --resource-group myResourceGroup \
  --name myScaleSet \
  --image Ubuntu2204 \
  --vm-sku Standard_B2s \
  --instance-count 3 \
  --admin-username azureuser \
  --generate-ssh-keys

上述命令将创建包含3个Ubuntu实例的扩展集，使用标准B型SKU并配置SSH访问。执行后系统会自动完成网络、负载均衡和实例初始化。

考试重点归纳

知识点	考察频率	备注
自动缩放策略配置	高频	需掌握基于指标和时间的触发条件
升级模式（手动/自动/滚动）	中频	理解各模式对服务可用性的影响
容错域与分布策略	中频	涉及高可用设计原则

第二章：虚拟机扩展集的架构与工作原理

2.1 理解虚拟机扩展集的底层架构设计

虚拟机扩展集（Virtual Machine Scale Sets, VMSS）是云平台中实现弹性伸缩的核心组件，其架构围绕统一配置管理与自动化扩缩容构建。

核心组件构成

VMSS 由协调节点、实例模板、负载均衡器和健康探针组成。所有虚拟机实例基于同一镜像与配置批量部署，确保一致性。

实例扩展示例

{
  "sku": {
    "name": "Standard_DS1_v2",
    "tier": "Standard",
    "capacity": 3
  },
  "properties": {
    "overprovision": true,
    "upgradePolicy": {
      "mode": "Automatic"
    }
  }
}

上述配置定义了初始容量为3个实例，启用超额预配以提升部署成功率，升级策略设为自动，便于无缝更新。

生命周期管理机制

• 实例通过共享的OS镜像快速启动
• 健康检查集成负载均衡器探测
• 故障实例自动替换，保障SLA

2.2 实践：通过Azure门户创建可伸缩的VMSS实例

登录门户并启动创建流程

登录 Azure 门户后，点击“创建资源”，搜索“虚拟机规模集”（Virtual Machine Scale Set），选择“创建”。在订阅和资源组中选择目标环境，输入实例名称与区域。

配置基础与网络设置

选择支持自动伸缩的 VM 大小（如 Standard_D2s_v3），配置身份验证方式。网络部分使用默认虚拟网络与负载均衡器，确保入站 NAT 规则开放所需端口。

{
  "sku": {
    "name": "Standard_D2s_v3",
    "tier": "Standard",
    "capacity": 2
  },
  "overprovision": true
}

该 JSON 片段定义了 VMSS 的 SKU 配置，其中 capacity 表示初始实例数量，overprovision 启用超额配置以提升部署成功率。

启用自动伸缩策略

在“扩展”选项卡中添加自动缩放规则，例如当 CPU 平均值超过 70% 时增加实例，低于 30% 时缩减。设定最小实例数为 2，最大为 10，实现弹性伸缩。

2.3 探究统一实例视图与规模集模型一致性

在云原生架构中，统一实例视图（Unified Instance View）与虚拟机规模集（VM Scale Set）模型的一致性保障是弹性伸缩稳定性的核心。为实现状态同步，系统需确保每个实例的元数据、配置策略与实际运行状态保持一致。

数据同步机制

通过周期性健康检查与事件驱动更新相结合的方式，平台实时校准实例状态。以下为伪代码示例：

// 检查并同步实例状态
func reconcileInstance(desiredState, currentState *Instance) bool {
    if desiredState.Image != currentState.Image {
        updateImage(currentState.ID, desiredState.Image)
    }
    return isConsistent(desiredState, currentState)
}

该函数对比期望状态与当前状态，若镜像不一致则触发更新操作，确保规模集中所有实例最终收敛至统一视图。

一致性验证维度

• 配置一致性：启动模板、扩展配置是否匹配
• 网络一致性：IP分配、安全组规则同步
• 健康状态一致性：探测结果与编排决策对齐

2.4 实战：配置自动缩放规则应对负载波动

在云原生环境中，应用负载常呈现周期性或突发性波动。为保障服务稳定性并优化资源成本，需配置自动缩放规则。

基于CPU使用率的水平伸缩

以下是一个Kubernetes HPA（Horizontal Pod Autoscaler）配置示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

该配置表示当CPU平均使用率超过70%时，自动增加Pod副本数，最多扩展至10个；最低维持2个副本以保证高可用。

多维度指标扩展策略

除CPU外，还可结合内存、自定义指标（如QPS）进行综合判断，提升扩缩容决策的准确性。

2.5 故障域、更新域与高可用性策略解析

在分布式系统设计中，故障域（Fault Domain）和更新域（Update Domain）是保障高可用性的核心概念。故障域指一组可能因单一故障事件同时失效的节点，通过将实例分布到多个故障域，可降低整体宕机风险。

高可用性架构中的域划分

Azure 和 AWS 等云平台通过硬件隔离实现故障域划分，例如同一机架或电源为一个故障域。更新域则确保升级维护时仅影响部分实例，避免服务中断。

• 故障域：物理隔离，防止单点硬件故障影响全局
• 更新域：滚动更新机制，保证服务持续可用

配置示例与参数说明

{
  "virtualMachineScaleSet": {
    "platformFaultDomainCount": 3,
    "platformUpdateDomainCount": 5
  }
}

上述配置表示系统划分为3个故障域和5个更新域。实例均匀分布，平台自动调度以最大化容错能力。故障域数量越多，物理隔离越强；更新域数量决定每次维护影响的实例比例，需权衡更新效率与服务稳定性。

第三章：网络与存储集成配置

3.1 虚拟机扩展集的网络规划与负载均衡集成

在部署虚拟机扩展集（VMSS）时，合理的网络规划是确保高可用性和横向扩展能力的关键。必须预先设计子网划分、IP地址分配策略，并将扩展集与Azure负载均衡器无缝集成。

网络架构设计要点

• 使用专用子网隔离VMSS实例流量
• 配置公共或内部负载均衡器以分发入站请求
• 通过NSG规则控制访问权限，保障网络安全

负载均衡器绑定配置示例

{
  "loadBalancerProfile": {
    "id": "/subscriptions/xxx/resourceGroups/rg1/providers/Microsoft.Network/loadBalancers/lb1",
    "properties": {
      "frontendIPConfigurations": [{
        "name": "LoadBalancerFrontEnd",
        "properties": {
          "subnet": {
            "id": "/subscriptions/xxx/resourceGroups/rg1/providers/Microsoft.Network/virtualNetworks/vnet1/subnets/subnet1"
          }
        }
      }]
    }
  }
}

该配置将VMSS关联至指定负载均衡器前端，确保新创建的实例自动加入后端池。其中 frontendIPConfigurations 定义了流量入口的IP和子网映射，实现动态伸缩时的无缝网络接入。

3.2 实践：为VMSS配置公共IP和NSG安全策略

在Azure虚拟机规模集（VMSS）部署中，合理配置公共IP与网络安全组（NSG）是保障服务可访问性与安全性的关键步骤。

分配公共IP地址

VMSS默认不为实例分配公共IP，需通过负载均衡器前端配置公网IP。使用CLI命令创建带公共IP的负载均衡器：

az network public-ip create \
  --resource-group myResourceGroup \
  --name myPublicIP \
  --sku Standard \
  --allocation-method Static

其中 --sku Standard确保与标准负载均衡器兼容， --allocation-method Static提供固定IP地址。

配置NSG安全策略

通过NSG定义入站规则，限制不必要的暴露。以下规则仅允许HTTPS和SSH访问：

优先级	协议	源端口	目标端口	操作
100	TCP	*	443	Allow
101	TCP	指定IP	22	Allow
999	*	*	*	Deny

最小权限原则下，明确放行必要端口，并拒绝所有其他流量。

3.3 数据磁盘与托管磁盘的最佳实践部署

在Azure环境中，合理配置数据磁盘与托管磁盘是保障虚拟机性能和数据持久性的关键。建议始终使用托管磁盘以简化存储管理并提升可用性。

选择合适的磁盘类型

根据工作负载需求选择SSD（如Premium_LRS）或HDD（如Standard_LRS）。高IOPS应用推荐使用Ultra磁盘。

磁盘类型	适用场景	最大IOPS
Premium SSD	生产数据库	75,000
Standard HDD	低频访问数据	500

自动化磁盘部署示例

az vm disk attach \
  --resource-group myRG \
  --vm-name myVM \
  --disk myDataDisk \
  --size-gb 1024 \
  --sku Premium_LRS

该命令将一个1TB的Premium SSD磁盘附加到指定虚拟机。参数 --sku定义了磁盘性能等级，确保与业务需求匹配。

第四章：自动化管理与运维实战

4.1 使用Azure CLI与PowerShell批量管理VMSS

在大规模云环境中，通过Azure CLI和PowerShell批量管理虚拟机规模集（VMSS）可显著提升运维效率。两者均支持脚本化操作，适用于自动化部署与持续维护。

常用CLI命令示例

# 创建5台实例的VMSS
az vmss create \
  --resource-group myRG \
  --name myScaleSet \
  --image Ubuntu2204 \
  --instance-count 5 \
  --authentication-type ssh

该命令通过 az vmss create一键部署包含网络、存储和负载均衡器的完整VMSS架构， --instance-count指定初始实例数量。

PowerShell批量操作

• Get-AzVmss：获取规模集配置
• Update-AzVmss：更新实例数量或SKU
• Stop-AzVmss：批量停止所有实例

结合 ForEach-Object可实现跨多个VMSS执行统一策略，适合多环境同步管理。

4.2 实践：通过自定义脚本扩展实现应用部署

在现代应用部署中，自定义脚本成为自动化流程的核心工具。通过编写可复用的脚本，可以统一部署逻辑、减少人为失误，并提升发布效率。

部署脚本的基本结构

一个典型的部署脚本包含环境准备、代码拉取、依赖安装和服务启动四个阶段。以下是一个 Bash 脚本示例：

#!/bin/bash
# deploy.sh - 应用部署脚本
set -e  # 出错即终止

APP_DIR="/opt/myapp"
GIT_REPO="https://github.com/user/myapp.git"

echo "1. 正在准备应用目录..."
mkdir -p $APP_DIR

echo "2. 正在拉取最新代码..."
git clone --depth=1 $GIT_REPO $APP_DIR

echo "3. 安装依赖..."
cd $APP_DIR && npm install

echo "4. 启动应用..."
pm2 start app.js --name myapp

该脚本使用 set -e 确保异常中断， git clone --depth=1 提升拉取效率，最后通过 PM2 守护进程运行应用。

脚本执行流程图

开始 → 创建目录 → 拉取代码 → 安装依赖 → 启动服务 → 结束

4.3 监控与诊断：集成Log Analytics与Application Insights

统一监控平台构建

Azure Monitor 通过集成 Log Analytics 和 Application Insights，实现应用层与基础设施层的统一监控。Application Insights 聚焦于应用性能管理（APM），而 Log Analytics 提供日志查询与分析能力。

数据采集配置

在 Azure 门户中启用 Application Insights 后，可通过连接字符串注入到应用中：

{
  "ApplicationInsights": {
    "ConnectionString": "InstrumentationKey=xxxxx;IngestionEndpoint=https://westus2-1.in.applicationinsights.azure.com/"
  }
}

该连接字符串包含采集端点和密钥，确保遥测数据安全传输至指定区域。

查询与告警示例

使用 Kusto 查询语言分析异常请求：

requests
| where success == false
| summarize count() by problemId, bin(timestamp, 1h)

此查询按小时统计各类失败请求，便于快速定位持续性故障。

4.4 滚动升级策略与健康探测机制应用

在Kubernetes中，滚动升级通过逐步替换旧Pod实例实现服务无中断更新。默认的 RollingUpdate策略允许配置 maxSurge和 maxUnavailable参数，控制升级过程中额外副本数与不可用实例上限。

健康探测配置示例

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

上述配置中，存活探针确保容器异常时自动重启，就绪探针控制流量分发时机，避免请求落入未准备完成的Pod。

升级策略参数对比

参数	作用	推荐值
maxSurge	允许超出期望副本数的最大数量	25%
maxUnavailable	升级期间允许不可用Pod比例	25%

第五章：从AZ-104考场到生产环境的跃迁路径

构建可复用的自动化部署模板

在通过AZ-104认证后，关键挑战是如何将考试中掌握的资源管理技能转化为生产级实践。使用Azure Resource Manager (ARM) 模板或Terraform可实现基础设施即代码（IaC）。以下是一个简化的Terraform配置片段，用于创建高可用虚拟机规模集：

resource "azurerm_virtual_machine_scale_set" "prod_vmss" {
  name                = "web-servers"
  resource_group_name = azurerm_resource_group.rg.name
  location            = "East US"
  sku {
    name     = "Standard_DS2_v2"
    tier     = "Standard"
    capacity = 3
  }
  upgrade_policy_mode = "Automatic"
  # 启用自动扩展和负载均衡集成
  health_probe_id = azurerm_lb_probe.web.id
}

实施基于角色的访问控制策略

生产环境中必须严格限制权限。建议采用最小权限原则，结合Azure Policy强制执行合规性。例如，可通过策略禁止在非生产组中创建公网IP。

• 定义自定义角色，仅允许虚拟机重启与日志读取
• 使用条件访问策略绑定MFA与设备合规性
• 定期审计RBAC分配，移除长期未使用的权限

建立监控与响应机制

部署Azure Monitor与Log Analytics是保障系统稳定的核心。通过Kusto查询语言（KQL）分析虚拟机CPU突增事件：

场景	查询语句
CPU > 90%持续5分钟	Perf | where CounterName == "% Processor Time" and InstanceName == "_Total" | summarize avg(CounterValue) by bin(TimeGenerated, 1m) | where avg_CounterValue > 90