为什么90%的AZ-104考生忽略虚拟机扩展集的这3个配置细节？

第一章：MCP AZ-104 虚拟机扩展集核心考点解析

虚拟机扩展集（Virtual Machine Scale Sets, VMSS）是 Microsoft Azure 中用于部署和管理大量相同配置虚拟机的核心服务，广泛应用于高可用性、自动伸缩和大规模应用部署场景。掌握其架构设计与管理操作是 AZ-104 认证考试的重点内容之一。

虚拟机扩展集的关键特性

• 统一管理：基于单一映像和配置批量创建和更新多台虚拟机
• 自动伸缩：根据 CPU 使用率、内存或自定义指标动态调整实例数量
• 高可用性：跨容错域和更新域分布实例，提升应用稳定性
• 负载均衡集成：默认与 Azure 负载均衡器或应用程序网关结合使用

通过 CLI 创建 VMSS 示例

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

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

上述命令将创建一个包含三台 Ubuntu 虚拟机的扩展集，启用 SSH 认证并关联负载均衡器。参数 --instance-count 指定初始实例数量，可后续通过自动伸缩规则调整。

自动伸缩策略配置要点

指标类型	触发条件	推荐操作
CPU 使用率	持续高于 70%	增加 2 个实例
内存使用率	持续低于 30%	减少 1 个实例
队列长度	每实例消息数 > 100	横向扩展

graph TD A[用户请求] --> B{负载增加} B -->|CPU > 70%| C[触发伸缩] C --> D[新增实例] D --> E[注册到负载均衡] E --> F[流量分发]

第二章：虚拟机扩展集配置细节深度剖析

2.1 扩展集实例分布策略的理论机制与配置实践

在分布式系统中，扩展集（Scaling Set）实例的分布策略直接影响系统的可用性与容错能力。合理的分布策略可避免单点故障，提升服务韧性。

分布策略的核心机制

通过将实例分散部署于不同的故障域（Fault Domain）和更新域（Update Domain），实现硬件级隔离。云平台通常基于拓扑感知调度器自动分配实例位置。

配置示例：Azure VMSS 反亲和性设置

{
  "properties": {
    "virtualMachineProfile": {
      "licenseType": "Windows_Server",
      "platformFaultDomainCount": 3
    },
    "singlePlacementGroup": false,
    "platformFaultDomainCount": 3
  }
}

上述配置启用多放置组并指定故障域数量，确保实例跨物理机架分布，降低集群级中断风险。参数 platformFaultDomainCount 控制最大故障域划分数，提升容错粒度。

策略选择对比

策略类型	适用场景	容错能力
随机分布	低一致性要求	中
拓扑感知分布	高可用系统	高

2.2 自动缩放规则设置中的指标选择与阈值优化

在自动缩放机制中，合理选择监控指标是确保系统弹性响应的关键。常见的性能指标包括CPU利用率、内存使用率、请求延迟和每秒请求数（QPS）。其中，CPU利用率是最广泛采用的指标。

核心指标对比

指标	适用场景	响应速度
CPU利用率	计算密集型服务	快
内存使用率	缓存类应用	中
QPS	Web服务器	慢

阈值配置示例

{
  "metric": "CPUUtilization",
  "threshold": 75,
  "comparisonOperator": "GreaterThanThreshold",
  "evaluationPeriods": 3
}

该规则表示连续3个周期内CPU利用率超过75%时触发扩容。过低的阈值可能导致频繁伸缩，过高则失去保护意义。建议结合历史负载数据，使用P95分位值设定初始阈值，并通过A/B测试逐步优化。

2.3 系统分配与用户分配托管标识的差异及应用

在Azure等云平台中，托管标识分为系统分配和用户分配两种类型。系统分配的托管标识与特定资源生命周期绑定，资源删除时标识自动清除。

核心差异对比

特性	系统分配	用户分配
生命周期	与资源绑定	独立存在
复用性	不可跨资源复用	可被多个资源共享

应用场景示例

{
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
  "name": "myUserManagedIdentity",
  "apiVersion": "2023-01-31"
}

该代码定义了一个用户分配托管标识。其优势在于可预先创建并授权，随后绑定至多个虚拟机或函数应用，实现权限集中管理。而系统分配标识适用于单一资源安全访问密钥保管库等场景，配置更简洁。

2.4 升级策略模式对比：滚动更新与手动更新实战演练

在Kubernetes中，服务升级的稳定性与可用性高度依赖于所选的更新策略。常见的两种方式为滚动更新（Rolling Update）和手动更新（Recreate），它们适用于不同的业务场景。

滚动更新配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

该配置确保升级期间至少有3个Pod可用，maxSurge表示可额外创建1个Pod用于过渡，maxUnavailable设为0保证服务不中断。

策略对比分析

策略类型	服务中断	回滚速度	适用场景
滚动更新	无	快	生产环境高频发布
手动更新	有	慢	调试或低频变更

2.5 健康探针集成与应用程序运行状况监控配置

在 Kubernetes 环境中，健康探针是保障服务高可用的核心机制。通过合理配置存活探针（livenessProbe）和就绪探针（readinessProbe），可实现对应用运行状态的精准监控。

探针类型与作用

• livenessProbe：判断容器是否运行正常，失败则重启容器
• readinessProbe：判断容器是否准备好接收流量，未就绪则从服务端点移除

YAML 配置示例

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

上述配置中，initialDelaySeconds 避免应用启动期间误判，periodSeconds 控制检测频率，HTTP 探针路径需由应用暴露标准健康接口。

第三章：常见配置误区与故障排查

3.1 错误配置导致扩缩容失败的典型场景分析

资源请求与限制设置不合理

当 Pod 的资源请求（requests）远小于实际使用量，或限制（limits）设置过高时，会导致调度不均或节点资源浪费，进而影响 Horizontal Pod Autoscaler（HPA）的判断。

• CPU 请求值过低，导致 HPA 无法准确感知负载压力
• 内存限制未设置，引发节点 OOM 或驱逐

HPA 配置示例

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: bad-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

上述配置中若容器未设置 CPU requests，则利用率计算失效，导致扩缩容不触发。Kubernetes 要求所有 metric 类型为 Utilization 的资源必须有明确 requests 值，否则指标无效。

3.2 托管磁盘一致性与映像版本管理陷阱

快照链与版本漂移问题

在频繁更新托管磁盘映像时，若未明确指定版本标签，可能导致部署实例引用了非预期的映像版本。这种“版本漂移”会破坏环境一致性，尤其在跨区域复制场景中更为显著。

一致性快照策略

使用 Azure CLI 创建快照时，应附加时间戳和语义化标签：

az snapshot create \
  --name disk-snap-20241001 \
  --resource-group myRG \
  --source /dev/disk/azure/scsi1/lun0 \
  --tags env=prod version=v1.7.3

该命令确保快照具备可追溯元数据。参数 --source 指定源磁盘路径，--tags 提供分类依据，便于自动化工具识别最新稳定版本。

• 避免依赖默认命名规则
• 实施基于策略的生命周期管理
• 定期清理陈旧映像以控制成本

3.3 网络安全组与负载均衡器联动配置验证

在云环境部署中，确保网络安全组（NSG）与负载均衡器（LB）正确联动是保障服务可用性与安全性的关键步骤。

配置验证流程

首先需确认负载均衡器前端端口与NSG入站规则匹配。例如，若LB监听80端口，则NSG必须允许目标为80端口的入站流量。

示例规则检查代码

{
  "securityRules": [
    {
      "name": "Allow-LB-HTTP",
      "direction": "Inbound",
      "protocol": "Tcp",
      "sourcePortRange": "*",
      "destinationPortRange": "80",
      "sourceAddressPrefix": "Internet",
      "destinationAddressPrefix": "10.0.0.0/24",
      "access": "Allow",
      "priority": 100
    }
  ]
}

上述JSON定义了一条允许来自互联网的HTTP流量通过NSG进入后端子网的规则。其中priority值需低于默认拒绝规则，确保优先匹配；destinationPortRange必须与LB配置一致。

验证连通性步骤

• 从外部网络发起对负载均衡器公共IP的HTTP请求
• 检查NSG流日志是否记录允许状态
• 确认后端虚拟机实际接收请求并返回响应

第四章：企业级部署最佳实践

4.1 多区域部署与可用性区域容灾规划

在构建高可用云原生系统时，多区域部署是保障业务连续性的核心策略。通过跨地理区域部署应用实例，可有效规避区域性故障带来的服务中断。

可用性区域的分布设计

现代云平台通常将一个地理区域划分为多个独立供电和网络的可用性区域（Availability Zones）。建议至少在三个可用区内部署关键服务，以实现故障隔离与负载均衡。

• 跨区域复制数据库以实现数据冗余
• 使用全局负载均衡器（如AWS Route 53或GCP Cloud Load Balancing）调度流量
• 定期执行灾难恢复演练验证切换流程

自动故障转移配置示例

apiVersion: v1
kind: Service
metadata:
  name: global-lb
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
# 配置多区域后端，云服务商将自动选择健康实例

该配置依赖云平台的跨区域负载均衡能力，将请求路由至最近且健康的实例，提升响应速度与容灾能力。

4.2 使用ARM模板实现扩展集基础设施即代码

Azure Resource Manager (ARM) 模板是声明式JSON文件，可用于在Azure中以一致、可重复的方式部署和管理资源。通过将虚拟机规模集（VMSS）定义为代码，可实现基础设施的版本控制与自动化部署。

ARM模板核心结构

一个典型的VMSS ARM模板包含参数、变量、资源和输出部分。以下示例展示了资源定义的关键片段：

{
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "apiVersion": "2023-07-01",
  "name": "[parameters('vmssName')]",
  "location": "[resourceGroup().location]",
  "properties": {
    "sku": {
      "name": "Standard_DS1_v2",
      "tier": "Standard",
      "capacity": 2
    },
    "virtualMachineProfile": { ... }
  }
}

其中，sku.capacity 控制实例数量，支持自动缩放策略联动。参数化设计使模板具备跨环境复用能力。

优势与实践建议

• 确保模板原子性，单一职责原则划分模块
• 结合Azure DevOps或GitHub Actions实现CI/CD流水线集成
• 使用嵌套模板提升可维护性，避免单文件臃肿

4.3 集成Azure Monitor与Log Analytics进行性能追踪

监控架构集成原理

Azure Monitor 收集来自云资源的遥测数据，通过 Log Analytics 工作区集中存储并查询。该集成支持实时性能分析与历史趋势追踪。

配置数据收集规则

使用 Azure 门户或 ARM 模板定义数据源，如下示例为通过 REST API 启用虚拟机日志收集：

{
  "properties": {
    "dataSources": {
      "performanceCounters": {
        "scheduledTransferPeriod": "PT1M",
        "performanceCounterConfiguration": [
          {
            "counterSpecifier": "\\Processor(_Total)\\% Processor Time",
            "unit": "Percent",
            "samplingFrequencyInSecs": 60
          }
        ]
      }
    }
  }
}

上述配置每分钟采集一次 CPU 使用率，samplingFrequencyInSecs 控制采样间隔，counterSpecifier 定义性能计数器路径。

查询与告警设置

在 Log Analytics 中使用 Kusto 查询语言分析数据：

• 查看最近 CPU 负载：Perf | where CounterName == "% Processor Time"
• 设置基于阈值的自动告警，响应性能异常

4.4 与Azure Policy结合实现合规性强制管控

Azure Policy 是 Azure 中用于实施组织治理和合规性控制的核心服务。通过将其与资源配置联动，可实现策略的自动执行与违规预警。

策略定义与赋值

可通过 JSON 定义策略规则，并绑定到管理组或订阅层级：

{
  "if": {
    "field": "location",
    "notEquals": "eastus"
  },
  "then": {
    "effect": "deny"
  }
}

上述策略阻止资源部署在非 eastus 区域。field 指定评估属性，effect 设置“deny”实现强制阻断，确保架构一致性。

合规性监控与修复

• Azure Policy 自动扫描资源配置并标记不合规项
• 支持通过修正任务（Remediation）批量修复历史资源
• 与 Azure Security Center 集成，增强安全基线管控

该机制实现了从“被动审计”向“主动防御”的演进，提升云环境整体可控性。

第五章：AZ-104考试策略与实操建议

制定高效学习路径

准备AZ-104考试需聚焦核心服务如虚拟网络、存储账户、Azure Active Directory和资源管理器。建议按模块划分学习周期，优先掌握高权重领域，例如Azure计算（30-35%）和网络（15-20%）。使用Microsoft Learn平台的官方学习路径，结合动手实验提升理解。

模拟真实考试环境

推荐使用Azure免费账户进行实操训练。创建资源组、部署VM并配置NSG规则时，记录每一步的PowerShell命令：

# 创建资源组
New-AzResourceGroup -Name "ExamRG" -Location "East US"
# 部署Ubuntu VM
New-AzVm `
  -ResourceGroupName "ExamRG" `
  -Name "TestVM" `
  -Location "East US" `
  -VirtualNetworkName "ExamVNet" `
  -SubnetName "default"

时间管理与题型应对

考试时长120分钟，共40-60题，包含单选、多选及案例分析。建议每题控制在90秒内，标记不确定题目后期复查。多选题注意“选择所有适用项”类提示，避免遗漏。

关键复习工具推荐

• Azure官方技能评估（https://learn.microsoft.com/azure/role-based-access-control/built-in-roles）
• John Savill’s AZ-104 Study Cram视频（YouTube高频考点解析）
• Whizlabs或Udemy上的模拟测试（至少完成5套完整题库）

故障排查实战要点

熟悉Azure Monitor、Log Analytics和Network Watcher工具链。例如，当VM无法访问公网时，应依次检查：

1. 网络安全组出站规则
2. 公共IP分配状态
3. 路由表下一跳配置
4. 是否启用IP转发