【MCP AZ-104负载均衡实战指南】：掌握Azure负载均衡器配置核心技巧

第一章：Azure负载均衡器概述与核心概念

Azure负载均衡器是微软Azure平台提供的高可用性网络服务，用于在多个虚拟机实例之间分配入站或出站流量，从而提升应用程序的可靠性与可扩展性。它工作在传输层（OSI第4层），支持TCP和UDP协议，并可根据配置的规则将请求智能分发到后端资源池中的健康实例。

基本架构与组件

Azure负载均衡器由以下几个核心组件构成：

• 前端IP配置：定义接收外部流量的公共或内部IP地址。
• 后端池：包含处理请求的虚拟机或虚拟机规模集实例。
• 负载均衡规则：指定如何将流量从前端IP映射到后端池，包括协议、端口和探测机制。
• 探测（Probe）：用于监控后端实例健康状态的机制，确保仅将流量发送至正常运行的节点。

负载均衡类型

Azure提供两种类型的负载均衡器：

1. 公共负载均衡器：面向互联网的流量入口，通常用于对外暴露Web应用。
2. 内部负载均衡器：在虚拟网络内部使用，适用于微服务间通信或数据库集群访问。

特性	公共负载均衡器	内部负载均衡器
IP类型	公共IP	私有IP
访问范围	互联网	虚拟网络内部
典型用途	Web服务器前端	应用中间层服务

配置示例：创建基本负载均衡规则

以下是一个通过Azure CLI创建负载均衡规则的代码示例：

# 创建负载均衡规则，将前端80端口映射到后端80端口
az network lb rule create \
  --resource-group MyResourceGroup \
  --lb-name MyLoadBalancer \
  --name HttpRule \
  --protocol tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name FrontendIP \
  --backend-pool-name BackendPool \
  --probe-name HttpProbe

该命令建立一条基于TCP的转发规则，并关联已定义的前端IP、后端池和健康探测。

第二章：Azure标准负载均衡器配置实践

2.1 理解Azure负载均衡器类型与工作原理

Azure负载均衡器是实现高可用性和横向扩展的关键服务，主要分为**公共负载均衡器**和**内部负载均衡器**两种类型。前者用于分发来自互联网的流量，后者服务于虚拟网络内的流量分发。

负载均衡器工作模式

它基于五元组（源IP、源端口、目标IP、目标端口、协议）进行哈希计算，决定流量转发至哪个后端实例。支持TCP、UDP和HTTP(S)协议，并通过健康探针监控后端资源状态。

• 公共负载均衡器：面向公网提供服务，需绑定公共IP地址
• 内部负载均衡器：部署在虚拟网络内，用于内部应用层通信

配置示例：后端池规则

{
  "frontendIPConfiguration": {
    "id": "/subscriptions/.../publicIP"
  },
  "backendAddressPool": {
    "id": "/subscriptions/.../backendPool"
  },
  "protocol": "Tcp",
  "frontendPort": 80,
  "backendPort": 80
}

上述JSON定义了一条负载均衡规则，将前端端口80的TCP流量分发到后端池中实例的80端口。frontendIPConfiguration指定入站IP，backendAddressPool定义目标虚拟机集合。

2.2 创建标准负载均衡器实例并配置前端IP

在Azure中创建标准负载均衡器时，首先需定义其基本属性，包括名称、区域和SKU类型。通过Azure门户或CLI均可完成初始化操作。

创建负载均衡器实例

使用Azure CLI命令创建负载均衡器：

az network lb create \
  --resource-group myResourceGroup \
  --name myLoadBalancer \
  --sku Standard \
  --vnet-name myVNet \
  --subnet mySubnet

上述命令创建了一个标准层的负载均衡器，并自动关联指定的虚拟网络与子网。参数--sku Standard确保启用高可用性和出站连接能力。

配置前端IP配置

前端IP用于接收入站流量。可通过以下命令绑定公共IP：

az network lb frontend-ip create \
  --lb-name myLoadBalancer \
  --name myFrontendIP \
  --resource-group myResourceGroup \
  --public-ip-address myPublicIP

该配置将公共IP地址myPublicIP绑定至负载均衡器前端，使其可对外提供服务。前端IP是后续配置负载均衡规则和NAT规则的基础。

2.3 配置后端池与健康探针实现高可用

在构建高可用的负载均衡架构时，合理配置后端池（Backend Pool）与健康探针（Health Probe）是确保服务稳定性的关键步骤。

后端池配置

后端池包含一组虚拟机或容器实例，负责处理客户端请求。通过将多个实例加入同一池中，实现流量的自动分发。

健康探针机制

健康探针定期向后端实例发送检测请求，判断其运行状态。以下为探针配置示例：

{
  "intervalInSeconds": 10,
  "path": "/health",
  "protocol": "http",
  "port": 80,
  "unhealthyThreshold": 3
}

该配置表示每10秒发起一次HTTP请求至/health路径，连续3次失败则标记实例为不可用，触发流量切换。

• 探针路径应返回200状态码以标识健康
• 间隔时间需权衡检测精度与系统开销
• 阈值设置避免因瞬时波动误判故障

2.4 定义负载均衡规则与出站规则详解

在现代云网络架构中，负载均衡规则决定了入站流量如何分发至后端实例，而出站规则则控制虚拟机访问外部网络的行为。合理配置这两类规则是保障服务高可用与网络安全的关键。

负载均衡规则配置

负载均衡规则基于协议、前端端口、后端端口和会话持久性等参数定义流量转发策略。例如：

{
  "protocol": "Tcp",
  "frontendPort": 80,
  "backendPort": 8080,
  "enableFloatingIP": false,
  "idleTimeoutInMinutes": 4,
  "loadDistribution": "Default"
}

上述配置将前端80端口的TCP流量转发至后端8080端口。`idleTimeoutInMinutes` 控制连接空闲超时时间，`loadDistribution` 可设为“Default”、“SourceIP”或“SourceIPProtocolPort”，影响哈希分发方式。

出站规则的作用

出站规则显式定义SNAT（源网络地址转换）行为，确保后端实例能安全访问公网。典型规则包括前端IP、后端池、出站端口数等。

参数	说明
Allocated Outbound Ports	每个虚拟机分配的出站端口数量
Frontend IP	用于SNAT的公网IP地址
Backend Pool	应用该规则的实例集合

2.5 使用NSG和路由表保障负载均衡网络连通性

在Azure虚拟网络中，网络安全组（NSG）和自定义路由表是确保负载均衡器前后端通信畅通的关键组件。NSG用于控制子网或网卡级别的流量进出，通过配置规则允许健康探测、客户端访问及后端服务通信。

关键NSG入站规则示例

{
  "direction": "Inbound",
  "protocol": "Tcp",
  "sourcePortRange": "*",
  "destinationPortRange": "80",
  "access": "Allow",
  "priority": 1010,
  "description": "Allow HTTP traffic to backend servers"
}

该规则允许来自负载均衡器健康探测和客户端的HTTP流量进入后端VM。优先级需合理设置，避免被高优先级拒绝规则覆盖。

路由表与下一跳类型

目标地址前缀	下一跳类型	说明
10.0.1.0/24	Virtual Appliance	指向防火墙设备
0.0.0.0/0	Internet	默认出站路由

自定义路由可引导流量经过NVA进行安全检查，同时确保负载均衡健康探测可达性。

第三章：基于场景的负载均衡策略设计

3.1 Web应用多实例流量分发方案设计

在高并发Web系统中，为实现多实例间的负载均衡与高可用性，通常采用反向代理结合负载均衡策略进行流量分发。主流方案包括基于DNS的全局负载均衡与基于Nginx或HAProxy的七层调度。

负载均衡算法选择

常用算法包括轮询、加权轮询、IP哈希和最少连接数。针对会话保持需求，IP哈希可确保同一客户端请求始终路由至同一后端实例。

• 轮询：请求依次分配给各实例
• 加权轮询：根据实例性能分配不同权重
• IP哈希：基于客户端IP计算目标节点

Nginx配置示例

upstream web_backend {
    ip_hash;                    # 启用IP哈希策略
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080;
}
server {
    location / {
        proxy_pass http://web_backend;
    }
}

上述配置中，ip_hash确保会话一致性；weight=3表示首台服务器承担约三倍于次机的流量，适用于异构硬件环境下的资源适配。

3.2 跨区域部署中的负载均衡最佳实践

在跨区域部署中，全局负载均衡（GSLB）是确保高可用与低延迟的核心机制。通过DNS级流量调度，可将用户请求导向最优区域。

基于延迟的路由策略

采用Anycast或GeoDNS技术，依据客户端地理位置和网络延迟选择最近的服务节点。

健康检查与故障转移

定期对各区域后端服务执行主动探测，自动屏蔽异常实例并重新分配流量。

• 启用跨区域冗余：至少部署两个活跃区域
• 使用加权轮询：根据区域容量动态调整流量比例

// 示例：多区域服务注册与权重配置
serviceConfig := &LoadBalancerConfig{
    Regions: map[string]*RegionConfig{
        "us-east": {Weight: 60, Healthy: true},
        "eu-west": {Weight: 40, Healthy: true},
    },
    HealthCheckInterval: 10 * time.Second,
}

上述配置实现按权重分发请求，并每10秒检测一次后端健康状态，确保故障时快速切换。

3.3 故障转移与冗余架构中的角色分析

在高可用系统中，故障转移与冗余机制依赖于明确的角色划分，常见包括主节点（Primary）、副本节点（Replica）和仲裁节点（Quorum）。这些角色协同保障服务连续性。

核心角色职责

• 主节点：处理所有写请求，维护最新数据状态；
• 副本节点：异步或同步复制主节点数据，准备接管服务；
• 仲裁节点：在脑裂场景中投票决定新主节点，避免单点误判。

基于心跳的故障检测示例

func monitorHeartbeat(node string, timeout time.Duration) {
    select {
    case <-pingChannel:
        log.Printf("%s is alive", node)
    case <-time.After(timeout):
        log.Printf("%s is down, triggering failover", node)
        initiateFailover(node)
    }
}

该函数通过监听心跳通道或超时触发故障转移。参数timeout需根据网络延迟合理设置，过短易误判，过长影响恢复速度。

角色切换流程

主节点正常 → 副本节点同步 → 心跳丢失 → 选举新主 → 重定向流量

第四章：监控、诊断与性能优化

4.1 利用Azure Monitor监控负载均衡器性能指标

Azure Monitor 是监控 Azure 资源性能的核心服务，可用于实时采集负载均衡器的关键指标，如数据包丢弃率、后端连接数和健康探测状态。

关键性能指标

• Packets Dropped：反映网络拥堵或安全策略拦截情况
• Backend Connection Count：衡量后端实例负载压力
• Health Probe Status：指示后端实例的可用性

配置诊断设置

通过 Azure CLI 启用负载均衡器日志收集：

az monitor diagnostic-settings create \
  --resource /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Network/loadBalancers/myLB \
  --name lbMonitorLogs \
  --metrics '[{"category": "AllMetrics","enabled": true}]' \
  --logs '[{"category": "LoadBalancerProbeHealthStatus","enabled": true}]'

该命令将所有性能指标和健康探针日志发送至 Log Analytics 工作区，便于后续查询与告警配置。参数 --metrics 指定采集指标类别，--logs 启用详细运行日志。

4.2 使用连接监视器排查通信故障

连接监视器（Connection Monitor）是诊断跨网络通信问题的核心工具，能够主动探测端到端的连通性并收集延迟、丢包等关键指标。

创建连接监视器实例

通过 Azure CLI 可快速部署监控任务：

az network watcher connection-monitor create \
  --resource-group myRG \
  --name cm1 \
  --source-resource vm1 \
  --destination-address 10.0.0.4

该命令在指定资源组中创建名为 cm1 的监视器，从 vm1 主动探测目标 IP 地址，持续跟踪网络路径健康状态。

关键监控指标

• 往返延迟（RTT）：反映通信响应速度
• 丢包率：判断网络稳定性的重要依据
• TCP 连接成功率：验证端口可达性

结合多点探测与历史趋势分析，可精准定位防火墙阻断、路由错误或链路拥塞等问题。

4.3 日志分析与常见问题诊断技巧

日志级别识别与过滤

系统日志通常包含 DEBUG、INFO、WARN、ERROR 等级别。定位问题时应优先关注 ERROR 和 WARN 级别日志，快速缩小排查范围。

1. ERROR：表示严重错误，需立即处理
2. WARN：潜在问题，可能影响稳定性
3. INFO：正常流程记录，用于行为追踪

典型异常日志示例

2023-10-05T14:23:11Z ERROR [pid:1234] Failed to connect to database: dial tcp 10.0.0.1:5432: connect: connection refused

该日志表明服务启动时无法连接数据库。关键信息包括： - 时间戳：定位事件发生时间； - 错误类型：网络连接被拒； - 目标地址：10.0.0.1:5432，可进一步使用 telnet 或 nc 测试连通性。

4.4 负载均衡器性能调优建议与容量规划

连接处理优化

负载均衡器在高并发场景下需调整最大连接数和超时设置。以 Nginx 为例，可通过以下配置提升性能：

worker_connections 10240;
keepalive_timeout 65;
client_header_timeout 10s;

上述参数分别设置单个工作进程支持的最大连接数、长连接保持时间及客户端请求头超时，有效减少重复握手开销。

容量评估模型

合理规划需基于 QPS 和平均响应时间估算节点数量：

指标	值
预期QPS	50,000
平均延迟	20ms
单实例吞吐	10,000 QPS

根据表格，至少需要5个负载均衡节点实现冗余与横向扩展。

第五章：AZ-104认证考试要点与实战总结

核心考试域覆盖

AZ-104考试聚焦于Azure管理员的核心职责，涵盖四大关键领域：

• 管理Azure身份与访问（Azure AD、RBAC）
• 配置与管理虚拟网络（VNet、NSG、Private Endpoint）
• 部署与管理虚拟机（VM规模集、可用性区域）
• 备份与监控资源（Recovery Services、Log Analytics）

实战场景：自动化部署VM

在真实环境中，使用ARM模板可实现一致且可重复的部署。以下为简化模板片段示例：

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vmName": { "type": "string", "defaultValue": "web-vm" }
  },
  "resources": [
    {
      "type": "Microsoft.Compute/virtualMachines",
      "name": "[parameters('vmName')]",
      "apiVersion": "2023-03-01",
      "location": "[resourceGroup().location]",
      "properties": {
        "hardwareProfile": { "vmSize": "Standard_B2s" },
        "storageProfile": {
          "imageReference": {
            "publisher": "Canonical",
            "offer": "UbuntuServer",
            "sku": "18.04-LTS",
            "version": "latest"
          }
        }
      }
    }
  ]
}

常见故障排查策略

问题类型	诊断工具	解决方案
VM无法远程连接	连接 troubleshooter	检查NSG入站规则是否开放SSH/RDP端口
磁盘性能低下	Metric Alerts + Monitor	升级至Premium SSD并启用缓存

成本优化建议

图表：资源利用率趋势分析 X轴：时间（周）｜ Y轴：CPU平均使用率（%） 显示连续三周利用率低于20%的VM实例，建议迁移至低配型号或启用自动关机策略。