负载均衡器的可靠性

项目
09/09/2024

本文包含负载均衡器的特定可靠性建议以及有关通过可用性区域与跨区域灾难恢复和业务连续性实现的负载均衡器区域复原能力的详细信息。

有关 Azure 可靠性的体系结构概述，请参阅《Azure 可靠性》。

可靠性建议

本部分包含针对实现复原能力和可用性的建议。每个建议可归入以下两个类别之一：

运行状况项涵盖配置项目和构成 Azure 工作负载的主要组件的正确功能等方面，例如 Azure 资源配置设置、对其他服务的依赖项等。
风险项涵盖可用性和恢复要求、测试、监视、部署和其他项目（如果未解决，则会增加环境中出现问题的可能性）等方面。

可靠性建议优先级矩阵

每项建议都根据以下优先级矩阵进行标记：

映像	优先级	说明
	高	需要立即修复。
	中	在 3-6 个月内修复。
	低	需要审查。

可靠性建议摘要

类别	优先级	建议
可用性		确保标准负载均衡器是区域冗余的
		确保后端池至少包含两个实例
系统效率		对生产工作负荷使用 NAT 网关而不是出站规则
		使用标准负载均衡器 SKU

可用性

确保标准负载均衡器是区域冗余的

在支持可用性区域的区域中，应使用区域冗余部署标准负载均衡器。区域冗余负载均衡器允许可在区域故障后继续使用的单个前端 IP 地址处理流量。无论区域是什么，都可以使用前端 IP 访问所有（未受影响的）后端池成员。如果一个可用性区域发生故障，只要区域中的其余区域保持正常，数据路径就能继续运行。有关详细信息，请参阅区域冗余负载均衡器。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

确保后端池至少包含两个实例

在后端部署具有至少两个实例的负载均衡器。单个实例可能会导致单一故障点。为了实现扩展，可能需要将负载均衡器与虚拟机规模集配对。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

系统效率

对生产工作负荷使用 NAT 网关而不是出站规则

出站规则将固定数量的 SNAT 端口分配给后端池中的每个虚拟机实例。这种分配方法可能会导致 SNAT 端口耗尽，尤其遇到流量模式不均衡导致特定虚拟机发送更高的传出连接量的情况。对于生产工作负荷，建议将标准负载均衡器或任何子网部署与 Azure NAT 网关结合使用。 NAT 网关在子网的所有虚拟机实例中动态分配 SNAT 端口，进而降低 SNAT 端口耗尽的风险。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

使用标准负载均衡器 SKU

标准 SKU 负载均衡器支持可用性区域和区域复原能力，而基本 SKU 则不支持。当某个区域出现故障时，区域冗余的标准负载均衡器不会受到影响，并且部署能够承受区域中的区域故障。此外，标准负载均衡器支持跨区域负载均衡，确保应用程序不会受到区域故障的影响。

注意

基本负载均衡器没有服务级别协议 (SLA)。

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

可用性区域支持

Azure 可用性区域是每个 Azure 地区内的至少三个在物理上独立的数据中心组。每个区域中的数据中心都配备了独立的电源、冷却系统和网络基础结构。在本地区域发生故障的情况下，设计可用性区域，以便一个区域受到影响时，其余两个区域支持区域服务、容量和高可用性。

故障范围包括软件和硬件故障，以及地震、洪水和火灾等事件。容错是通过 Azure 服务的冗余和逻辑隔离来实现的。有关 Azure 中可用性区域的详细信息，请参阅地区和可用性区域。

已启用 Azure 可用性区域的服务旨在提供适当级别的可靠性和灵活性。可以通过两种方式进行相关配置。可以采用区域冗余配置，实现跨区域自动复制，也可以采用区域性配置，将实例固定到特定区域。还可以将这些方法结合。有关区域与区域冗余体系结构的详细信息，请参阅有关使用可用性区域和地区的建议。

Azure 负载均衡器支持可用性区域方案。可以使用标准负载均衡器通过将资源与局部区域相适应并分布到多个局部区域来提高整个方案的可用性。请查看本文档来了解这些概念和基本场景设计指导。

尽管建议部署具有区域冗余的负载均衡器，但负载均衡器可以为区域冗余的、区域的或非区域的。负载均衡器的可用性区域选择与其前端 IP 的区域选择同义。对于公共负载均衡器，如果负载均衡器前端中的公共 IP 是区域冗余的，则负载均衡器也是区域冗余的。如果负载均衡器前端中的公共 IP 具有区域性，则负载均衡器也将指定到同一区域。若要为负载均衡器配置局部区域相关属性，请选择所需的相应前端类型。

注意

并不需要为每个区域创建一个负载均衡器，而是只需一个具有多个与相应后端池关联的前端（区域性或区域冗余）的负载均衡器即可达到目的。

先决条件

若要将可用性区域与负载均衡器配合使用，需要在支持可用性区域的区域中创建负载均衡器。若要查看哪些地区支持可用性区域，请参阅支持的地区列表。
对于负载均衡器和公共 IP 使用标准 SKU，以支持可用性区域。
不支持基本 SKU 类型。
若要创建资源，需要具有网络参与者角色或更高级别的角色。

限制

创建后，资源的区域无法更改、更新或创建。
创建后，无法将资源从“局部区域”更新为“区域冗余”，反之亦然。

区域冗余的负载均衡器

在具有可用性区域的地区中，标准负载均衡器可以是区域冗余的，流量由单个 IP 地址提供。单个前端 IP 地址可以在区域故障中存活。不管局部区域是什么，都可以使用前端 IP 访问所有（未受影响的）后端池成员。最多有一个可用性区域可能会发生故障，而数据路径可以幸存，但前提是地区中的剩余区域保持正常。

前端的 IP 地址由多个可用性区域中多个独立的基础结构部署同时提供。在未受该局部区域的故障影响的其他局部区域中，任何重试或重建都会成功。

该图描绘了一个区域冗余标准负载均衡器，该负载均衡器将三个不同区域中的流量定向到区域冗余配置中的三个不同子网。

注意

VM 1、2 和 3 可以属于同一子网，不一定必须位于单独的区域中，如图所示。

负载均衡器后端池中的成员（例如区域虚拟机）通常与单个区域关联。生产工作负载的常见设计是使用多个区域资源。例如，将区域 1、2 和 3 中的虚拟机放在具有区域冗余前端的负载均衡器的后端中就符合这种设计原则。

区域负载均衡器

可以选择将某个前端指定为保证位于单个局部区域，这称为局部区域性前端。在这种情况下，地区中的单个区域为所有入站或出站流提供服务。前端的运行状态取决于该局部区域。区域（保证前端所在的区域除外）中发生故障不会影响数据路径。可以使用局域性前端来按可用性区域公开 IP 地址。

此外，支持在每个局部区域中直接为负载均衡的终结点使用局部区域性前端。可以使用此配置来按局部区域负载均衡的终结点公开 IP 地址，以单独监视每个局部区域。对于公共终结点，可将其与流量管理器等 DNS 负载均衡产品相集成，并使用单个 DNS 名称。

该图描绘了三个区域冗余标准负载均衡器，每个负载均衡器都将一个区域中的流量定向到区域配置中的三个不同子网。

对于公共负载均衡器前端，需将 zones 参数添加到公共 IP。此公共 IP 由相应规则使用的前端 IP 配置引用。

对于内部负载均衡器前端，需将 zones 参数添加到内部负载均衡器前端 IP 配置。局部区域性前端保证子网中的某个 IP 地址位于特定的局部区域。

非区域负载均衡器

也可以使用“无区域”前端在非区域配置中创建负载均衡器。在这些方案中，公共负载均衡器将使用公共 IP 或公共 IP 前缀，内部负载均衡器将使用专用 IP。此选项不保证冗余。

注意

从基本 SKU 升级到标准 SKU 的所有公共 IP 地址都属于“无区域”类型。了解如何在 Azure 门户中升级公共 IP 地址。

SLA 改进

由于可用性区域在物理上是独立的，并且提供不同的电源、网络和冷却，因此可以提高 SLA（服务级别协议）。有关详细信息，请参阅[联机服务的服务级别协议 (SLA)](https://www.azure.cn/support/legal/sla/)。

创建启用可用性区域的资源

若要了解如何使用负载均衡器对一个区域中或多个区域中的 VM 进行负载均衡，请参阅快速入门：创建公共负载均衡器以对 VM 进行负载均衡。

注意

创建后，资源的区域无法更改、更新或创建。
创建后，无法将资源从“局部区域”更新为“区域冗余”，反之亦然。

容错

虚拟机可以故障转移到群集中的另一台服务器，而 VM 的操作系统将在新服务器上重启。应参考灾难恢复的故障转移过程，在恢复规划中收集虚拟机，并运行灾难恢复演练，以确保其容错解决方案能够成功。

有关详细信息，请参阅站点恢复过程。

区域故障体验

局部区域冗余并不意味着数据平面或控制平面不会受到冲击。局部区域冗余流可以使用任何局部区域，而你的流将使用 Azure 区域中所有正常的局部区域。在发生局部区域故障时，使用正常局部区域的流量流不受影响。

发生局部区域故障时使用了该局部区域的流量流可能会受影响，但应用程序可以恢复。在 Azure 融合各方力量从局部区域故障中恢复并重新传输数据后，流量将继续传入 Azure 区域中正常的局部区域。

请查看 Azure 云设计模式来改善应用程序在故障情况下的复原能力。

多个前端

使用多个前端可以在多个端口和/或 IP 地址上对流量进行负载均衡。在设计体系结构时，请务必考虑区域冗余如何与多个前端交互。如果目标是始终使每个前端都能够灵活应对故障，则分配为前端的所有 IP 地址都必须是区域冗余的。如果一组前端旨在与单个区域关联，那么这组前端的每个 IP 地址都必须与该特定区域关联。每个区域中不需要负载均衡器。每个区域前端或一组区域前端可与后端池中的虚拟机相关联，这些虚拟机是该特定可用性区域的一部分。

安全部署技术

请查看 Azure 云设计模式来改善应用程序在故障情况下的复原能力。

迁移到可用性区域支持

如果某个地区已扩充为具有可用性区域，则任何现有 IP（例如，用于负载均衡器前端的 IP）都将保持非区域性。为确保体系结构可以利用新区域，建议创建新的前端 IP。创建后，可以将现有的非区域前端替换为新的区域冗余前端。若要了解如何将 VM 迁移到可用性区域支持，请参阅将负载均衡器迁移到可用性区域支持。

跨区域灾难恢复和业务连续性

灾难恢复 (DR) 是指从会导致故障时间和数据丢失的高影响事件（例如自然灾害或部署失败）中恢复。不管灾难的原因是什么，最好的补救措施就是一个定义全面且经过测试的 DR 计划，以及一个主动支持 DR 的应用程序设计。在开始考虑创建灾难恢复计划之前，请参阅设计灾难恢复策略的建议。

在 DR 方面，Azure 使用共同责任模型。在共担责任模型中，Azure 会确保基线基础结构和平台服务可用。同时，许多 Azure 服务不会自动复制数据，也不会从失败区域回退以交叉复制到另一个启用的区域。对于这些服务，你负责设置适用于工作负载的灾难恢复计划。大多数在 Azure 平台即服务 (PaaS) 产品/服务上运行的服务都提供支持 DR 的功能和指导，你可以使用特定于服务的功能来支持快速恢复，从而帮助制定 DR 计划。

Azure 标准负载均衡器支持跨区域负载均衡，来实现如下所述的异地冗余高可用性方案：

源自多个区域的传入流量。
即时全局故障转移到下一个最佳区域部署。
将负载跨区域分配到延迟超低的最近 Azure 区域。
可在单个终结点后面进行纵向扩展/缩减。
静态任意播全局 IP 地址
客户端 IP 保留
无需接受培训即可在现有负载均衡器的基础上构建解决方案

跨区域负载均衡器的前端 IP 配置是静态的，将播发到大多数 Azure 区域。

跨区域负载均衡器示意图。

注意

跨区域负载均衡器上负载均衡规则的后端端口应与区域标准负载均衡器上负载均衡规则/入站 NAT 规则的前端端口相匹配。

多区域地理位置中的灾难恢复

区域冗余

通过将跨区域负载均衡器无缝链接到现有区域负载均衡器来配置区域冗余。

如果一个区域出现故障，则会将流量路由到下一个最近的正常运行的区域负载均衡器。

跨区域负载均衡器的运行状况探测每 5 秒收集一次有关每个区域负载均衡器可用性的信息。如果一个区域负载均衡器的可用性降到了 0，跨区域负载均衡器将检测到故障。然后，会将区域负载均衡器取出轮换列表。

全局区域流量视图的示意图。

超低延迟

地理邻近性负载均衡算法基于用户和区域部署的地理位置。

从客户端启动的流量将进入最近的参与区域，并通过 Microsoft 全球主干网络进入最近的区域部署。

例如，你有一个跨区域负载均衡器，并在 Azure 区域中有一个标准负载均衡器：

中国东部
中国北部

如果流从张家口启动，则流量将进入中国北部。此区域是距离张家口最近的参与区域。流量会路由到最近的区域负载均衡器，即中国北部。

Azure 跨区域负载均衡器使用地理邻近性负载均衡算法来做出路由决策。

使用多个区域负载均衡器计算地理邻近性时，将使用配置的区域负载均衡器负载分配模式来做出最终路由决策。

有关详细信息，请参阅配置 Azure 负载均衡器的分配模式。

可在单个终结点后面进行纵向扩展/缩减

向客户公开跨区域负载均衡器的全局终结点时，可以在全局终结点后面添加或删除区域部署，而不会发生中断。

静态任意播全局 IP 地址

跨区域负载均衡器附带静态公共 IP，这可以确保 IP 地址保持不变。若要详细了解静态 IP，请参阅此文

客户端 IP 保留

跨区域负载均衡器是第 4 层直通网络负载均衡器。此直通模式保留数据包的原始 IP。原始 IP 可用于虚拟机上运行的代码。这种 IP 保留可让你应用特定于 IP 地址的逻辑。

浮动 IP

可以在全局 IP 级别和区域 IP 级别配置浮动 IP。有关详细信息，请访问 Azure 负载均衡器的多个前端

请务必注意，在 Azure 跨区域负载均衡器上配置的浮动 IP 独立于后端区域负载均衡器上的浮动 IP 配置运行。如果在跨区域负载均衡器上启用了浮动 IP，则需要将相应的环回接口添加到后端 VM。

运行状况探测

在决定将流量分配到何处时，Azure 跨区域负载均衡器可利用后端区域负载均衡器的运行状况。如果用户在其区域负载均衡器上设置了运行状况探测，跨区域负载均衡器的运行状况检查将每 5 秒自动执行一次。

后续步骤

Azure 中的可靠性
详细了解 Azure 负载均衡器。

通过