通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 负载均衡器上的 Well-Architected 框架透视图

  • 项目

负载均衡过程将网络流量分配到一组或更多后端服务器。 Azure 负载均衡器是一种 Azure 本机服务，它为用户数据报协议（UDP）和传输控制协议（TCP）执行第 4 层负载均衡。 负载均衡器有助于为区域和全球部署提供低延迟和高可用性。

本文假设作为架构师，你已查看了 Azure 中 负载均衡选项，并为工作负荷选择了负载均衡器。 本文中的指南提供了映射到 Well-Architected 框架支柱原则的体系结构建议。

重要

如何使用本指南

每个部分都有一个 设计清单，该清单提供关注的体系结构区域以及本地化为技术范围的设计策略。

此外，还包括有助于具体化这些策略的技术功能的建议。 这些建议并不表示可用于负载均衡器及其依赖项的所有配置的详尽列表。 而是列出与设计视角相匹配的关键建议。 使用建议生成概念证明或优化现有环境。

演示关键建议的基础体系结构：
Azure 虚拟机基线体系结构。

技术范围

此审查重点讨论以下 Azure 资源的相互关联的决策：

  • 负载均衡器

本指南重点介绍标准负载均衡器 SKU。 基本负载均衡器和网关负载均衡器 SKU 不适用于本文。

负载均衡器引导流量的图表。

注释

对于 HTTP 应用程序，请考虑使用 Azure 应用程序网关或 Azure Front Door 而不是负载均衡器。 这些替代方法管理负载均衡，并提供 Web 应用程序防火墙（WAF）和传输层安全性（TLS）终止等功能。

有关详细信息，请参阅：

可靠性

可靠性支柱的目的是通过 建立足够的复原能力和从故障快速恢复来提供持续的功能。

可靠性设计原则 为各个组件、系统流和整个系统提供高级设计策略。

设计清单

根据可靠性设计评审核对清单开始实施您的设计策略。 确定其与业务需求的相关性，同时记住虚拟机（VM）的层和功能。 扩展策略以根据需要包含更多方法。

  • 了解Microsoft支持的保证的影响。 除了体系结构中的其他组件外，还要将服务级别协议（SLA）纳入工作负荷的可靠性目标。 请记住以下要点：

    • 如果负载均衡终结点无法连接到所有正常的后端服务器一整分钟，则该分钟被视为不可用。 但是，如果至少一个请求在同一分钟内成功，即使其他请求失败，该分钟也不会被视为停机时间。

    • 停机时间不包括源网络地址转换 （SNAT） 端口耗尽导致的分钟数。 确保配置系统以处理预期的连接数，并相应地开放端口。

  • 支持工作负荷体系结构中的区域冗余。 建议使用标准负载均衡器 SKU。 它具有可靠性功能，例如可用性区域支持、跨多个区域的流量分布，以及能够处理后端池中的更多实例。 这些特性有助于抵御区域、地区和单个 VM 实例级别的故障。 请注意限制，例如最大后端池大小。

    注释

    在负载均衡器中，可以管理负载均衡 VM 的数量，而不是负载均衡器实例数。 可以将负载均衡器实例配置为区域冗余，或者如果工作负荷需要在单个区域中并置 VM，则将其固定到某个区域。 前端 IP 地址的区域性或多区域配置决定了负载均衡冗余。

  • 支持工作负荷体系结构中的区域冗余。 可以将负载均衡器配置为全局负载均衡器。 在此设置中，负载均衡器具有一个静态的 anycast 公共 IP 地址，该地址可以广播到多个区域。 当客户端请求此 IP 地址时，其请求将转到最近的服务器实例。 负载均衡器连接到区域负载均衡器，以高效分配流量。

  • 评估网络堆栈中的更改以支持可靠的缩放。 考虑使用自动缩放规则横向扩展后端池。 请注意出站流量可能导致的 SNAT 端口耗尽。 若要解决此问题，请使用 Azure NAT 网关简化配置，但了解它缺少可用性区域冗余。 或者，使用负载均衡器来增加区域冗余。 有关详细信息，请参阅出站连接。

  • 缓解潜在故障。 执行故障模式分析和识别缓解措施。 下表显示了故障类型以及如何缓解故障。

    失败 缓解措施
    流量将路由到运行不正常的应用程序实例。 监控工作负载实例的健康状况。 实现 HTTP 运行状况探测，包括检查工作负荷依赖项。
    流量将路由到出现故障的区域。 在另一个区域中部署额外的实例。 添加全局负载均衡器以将流量重定向到新区域。
    工作负荷的用户群已扩展，以支持新区域中的用户，并且延迟较高。 应用程序现在遇到大量超时和故障。 在新区域中部署额外的实例，并将其添加到服务配置中。 作为全局负载均衡器，Azure 负载均衡器将流量路由到更靠近用户的地方。

  • 将流量路由到正常的实例。 您可以使用 HTTP 或 TCP 进行健康检查。 若要提供更丰富的状态响应，请考虑为运行状况检查创建 HTTP 终结点，即使对于非 HTTP 应用也是如此。 此方法特别适用于检查依赖项和数据库。 如果没有 HTTP 探测，负载均衡器依赖于 TCP 连接，这可能无法准确反映 VM 运行状况。

    可以在负载均衡器上配置运行状况探测。 有关详细信息，请参阅运行状况探测的设计指南。

建议

建议 益处
选择标准负载均衡器 SKU。
有关详细信息，请参阅 SKU 比较。		 此 SKU 支持可靠性功能，例如可用性区域和多区域负载均衡。
配置 规则 将前端 IP 地址映射到后端服务器的 IP 地址，以实现负载均衡。

后端地址池应至少有两个后端终结点进行负载均衡以实现冗余。		 规则是负载均衡算法的核心。 如果没有此配置，则禁用分发模式。
配置运行状况探测。

- 设置探测间隔和阈值。 请考虑检测故障的速度与终结点请求数之间的权衡。
- 评估是否要在所有实例都处于运行不正常状态时向实例发送流量。 可以使用此配置实现正常降级体验。 有关详细信息，请参阅 AllProbedUp。		 只有正常的后端池实例才会接收新连接。 此配置有助于保持高可用性和可靠性，因为它将流量从不正常的实例路由出去。
将专用和公共 IP 地址配置为 区域冗余。 IP 地址确定负载均衡器的区域冗余。 区域冗余有助于工作负荷承受区域性故障。 当一个区域发生故障时，服务可以故障转移到其余区域中的一个。

安全性

安全支柱的目的是为工作负载提供机密性、完整性和可用性保证。

安全设计原则 提供了一种高级别设计策略，通过应用于负载均衡器技术设计的方法来实现这些目标。

设计清单

根据面向安全性的设计评审清单启动设计策略，并确定漏洞和控制措施来改进安全态势。 扩展策略以根据需要包含更多方法。

  • 审查安全基线。 为了增强由 Azure 负载均衡器平衡负载的应用程序的安全态势，请查看负载均衡器 的安全基线。

  • 保护后端服务器。 在没有直接互联网暴露的虚拟网络中部署资源。 在虚拟网络前使用负载均衡器。 理想情况下，负载均衡器应具有防火墙功能。 对于 HTTP 应用程序，请考虑应用程序网关或 Azure Front Door。 对于非 HTTP 应用程序，请考虑使用专用 IP 地址（内部负载均衡器）的负载均衡器，并通过 Azure 防火墙路由流量，提高安全性。 有关详细信息，请参阅 内部负载均衡器。

    还可以将负载均衡器用作反向代理。 在这种情况下，负载均衡器具有使用 SNAT 的公共 IP 地址，该地址在隐藏资源的 IP 地址的同时公开资源。

    注释

    若要筛选发往后端服务器的流量，请使用包含前端和后端的子网上的网络安全组（NSG）。 不要直接将 NSG 应用到负载均衡器服务。 当 NSG 强制实施规则时，它们会考虑源端口、目标端口和源计算机和目标计算机的地址范围，而不是负载均衡器。

  • 私密连接设计。 负载均衡器适用于 Azure 专用链接。 如果跨虚拟网络分散应用程序资源，则可以连接不同虚拟网络中的资源。 使用虚拟网络对等互连或在内部负载均衡器前面放置专用链接。 “专用链接”选项提供更安全的访问，而无需公共 IP 地址。 它还限制来自非对等互连网络的访问。

    可以通过 基于角色的访问控制 授权专用链接，以仅限制对所需标识的访问。

  • 保护应用程序免受网络边缘的威胁。 对于使用负载均衡器作为入口点的设计，请在终结点级别实现流量检查。 此设计没有 WAF 等内置安全功能，因此必须添加额外的措施来帮助保护 HTTP 应用程序。 有关详细信息，请参阅 公共负载均衡器。 此外，请确保保护负载均衡器终结点免受分布式拒绝服务 （DDoS） 攻击。

  • 加密网络流量。 负载均衡器在第 4 层工作，完全支持对 TCP 和 UDP 流量进行负载均衡。 负载均衡器不支持安全套接字层（SSL）和 TLS 终止。 对于应用程序层的 HTTPS 负载均衡，请使用应用程序网关。

建议

建议 益处
将前端 IP 地址配置为虚拟网络中的专用 IP 地址。 此方法有助于确保前端 IP 地址和虚拟网络与直接互联网公开保持隔离。 内部负载均衡器无法接受来自 Internet 的传入流量，这可以减少潜在的攻击途径。
使用 Azure DDoS 防护保护公共负载均衡器。 DDoS 防护计划提供高级保护，包括监视终结点的威胁和滥用迹象的检测功能。

成本优化

成本优化侧重于 检测支出模式、优先考虑关键领域的投资，以及优化其他 以满足组织预算，同时满足业务需求。

成本优化设计原则 为实现这些目标提供高级设计策略，并在与负载均衡器及其环境相关的技术设计中做出权衡。

设计清单

根据投资的成本优化设计评审核对清单开始实施您的设计策略。 微调设计，使工作负荷与为工作负荷分配的预算保持一致。 设计应使用正确的 Azure 功能，监视投资，并查找随时间推移进行优化的机会。

  • 将负载均衡的费用纳入成本模型。 考虑主要因素，例如负载均衡器处理的数据量以及入站和出站负载均衡规则的数量。 若要进行精确的成本估算，请使用流量日志来衡量入站和出站流量需求。

  • 设置支出控制。 记录和分析负载均衡器成本。 若要有效管理成本，请使用 Microsoft成本管理创建预算 和配置警报。 成本可以根据记录的数据量和存储持续时间累积，这会影响带宽和存储费用。

  • 删除未使用的资源。 识别和删除未使用的负载均衡器实例。 分析日志以评估使用情况。 删除与后端 VM 不关联的负载均衡器实例。 检查流量日志以查找未充分利用的资源。

  • 优化流成本。 使用高效的协议和数据压缩来减少流量流量上的负载，并最大程度地降低成本。

    若要优化成本，可以减少规则数。 为了避免为每个终结点使用单独的 IP 地址和端口规则，可以在前端定义一条针对端口范围的规则，该规则连接到后端池。

    在后端流中实现优化。 例如，负载均衡器截获的多个数据库查询可能会增加每个查询的成本。 若要防止产生额外的成本，请考虑实现存储过程来合并查询序列。

  • 评估运营成本。 考虑资源费用和运营成本，例如维护、扩展和合规性。 负载均衡器规则可能会显著影响成本。 减少规则数，以优化财务和管理成本。

建议

建议 益处
使用 Azure 定价计算器估算成本。 可以将预期的流量使用情况转换为成本估算，这样就可以更轻松地规划和预算。
评估规则数并尽可能减少规则数。

评估是否可以使用一个规则来汇总一系列端口，而不是为单个 IP 地址定义多个规则。
例如，可以使用 入站 NAT 规则 将 IP 地址和端口映射到后端池而不是单个 VM。		 合并规则可优化成本并简化作。

纵向扩展或缩减时，可以添加或删除后端池中的 IP 地址，而无需更改任何规则。

卓越运营

卓越运营主要侧重于开发实践、可观测性和发布管理等过程。

卓越运营设计原则 提供了一个高级设计策略，以实现工作负载的运营需求目标。

设计清单

根据卓越运营设计评审清单来开始实施设计策略，以定义与负载均衡器相关的可观测性、测试和部署。

  • 使用基础结构即代码。 部署和配置负载均衡器以及其他网络组件，例如虚拟网络、网络对等互连、专用终结点和 NSG。 自行熟悉 Microsoft.Network loadBalancers 资源类型。

  • 对中心辐射型体系结构使用分层部署。 首先部署中心，因为它的更改频率低于辐射型网络中部署的工作负荷。 将负载均衡器与工作负载一起部署。 如果跨多个工作负荷重复使用单个负载均衡器，请考虑将其置于中心。

  • 实施全面的网络监视系统。 实施诊断功能，例如通过多维指标实现实时见解和警报、基于健康事件架构的资源日志，以及用于全面监视负载均衡器的 Azure Monitor Insights 仪表板。

建议

建议 益处
使用多维指标。

若要最大程度地减少过多的警报，请将聚合类型设置为 Average，并使用具有 95% 阈值的 5 分钟数据窗口。 有关详细信息，请参阅 为多维指标配置警报。 查看入站和出站可用性的示例。		 全面的实时洞察和警报配置可增强对问题的检测，并实现快速响应。
捕获资源日志。 负载均衡器条目取决于运行状况事件架构。 日志提供事件的详细记录，以便快速识别和解决问题。
使用内置的 Azure Monitor Insights 仪表板来监视负载均衡器。 可视化有助于做出明智的设计选择，并帮助你快速识别、诊断和解决问题。
在维护作期间，将 管理状态 设置为 Down，使后端实例退出轮换，而不会中断现有连接。 此配置有助于确保不会将新连接转发到后端实例，同时正常终止现有连接。 此管理状态配置有助于减少将 VM 从负载均衡轮换中取出以进行常规维护或补丁修复所需的开销和复杂性。

作为将后端实例移出轮换的替代选项，可以应用 NSG 来阻止来自负载均衡器运行状况探测器或客户端 IP 地址和端口的流量。 此选项会增加复杂性。

性能效率

性能效率就是通过管理容量来保持用户体验，即使负载增加也不例外。 该策略包括缩放资源、识别和优化潜在瓶颈，以及优化峰值性能。

性能效率设计原则 提供了一个高级设计策略，用于根据预期使用量实现这些容量目标。

设计清单

根据性能效率设计评审清单开始设计策略，根据负载均衡器的关键性能指标定义基线。

  • 确定网络性能目标。 负载均衡器对可以支持的流量没有限制。 但是，定义性能目标和容量计划时，应测试网络性能。

    使用压力测试来了解工作负荷的带宽要求。 在这些测试中包含负载均衡器。 如果具有多个 VM 的单个虚拟机规模集不够，则可以使用相同的负载均衡器添加另一个规模集。 如果 VM 接收请求的速度不够快，可能需要调整网络组件，例如添加更多负载均衡器。 但是，请考虑进行设计更改并优化工作负荷以更好地处理负载，而不是更改负载均衡器。

  • 在设计缩放策略时了解限制。 若要满足性能要求并缩放工作负荷，请从后端池添加或删除 VM。 标准负载均衡器中的单个后端池最多可以处理 5,000 个 VM。

    负载均衡器不应用吞吐量限制。 但 VM 和虚拟网络的吞吐量限制仍适用。 有关详细信息，请参阅 VM 网络带宽。

  • 快速处理请求。 标准负载均衡器具有一个层，该层根据流量与用户的地理邻近度将流量路由到后端终结点。

    负载均衡器还支持基于会话持久性的负载分发。 启用此功能时，来自同一客户端的请求始终定向到处理其以前的会话的同一后端服务器。

  • 收集数据以分析性能。 负载均衡器 多维指标 可以分析服务的性能。 配置警报以检测性能更改。 使用 Azure Monitor Insights 仪表板等工具可视化负载均衡器的状态。 确保资源运行状况功能监视运行状况，并随时了解性能问题和中断情况。

  • 优化网络流量。 不要在单独的步骤中多次处理相同的数据。 而是在批处理中执行所有必要的计算，然后保留数据。 此方法可降低延迟并最大程度地减少网络流量，从而提高整体性能。

建议

建议 益处
如果有全局用户，请在标准负载均衡器中选择 全局层。 此层的地理邻近分布模式为最靠近区域的终结点的用户请求提供服务，从而提高性能。
如果希望来自同一用户的请求定向到同一后端服务器，请评估是否应启用 会话持久性。

从可靠性的角度来看，我们不建议使用此方法。 如果使用此选项，应用程序应正常恢复，而不会中断用户会话。

还有负载均衡权衡，因为它限制了跨多个后端均匀分配流量的灵活性。		 会话持久性可以优化性能并维护用户会话的连续性，尤其是在应用程序依赖于本地维护状态信息时。 但有利弊。
在横向扩展期间，发送探测停止信号，直到应用程序完全初始化并准备好处理请求。

在横向缩减期间，为正在缩减的终结点上的新连接发送探测停止信号。 继续处理现有连接上的挂起请求。		 运行状况探测有助于优化缩放操作。 它们有助于确保在横向扩展期间，应用程序可以处理传入的负载。 在缩减操作之前，这些措施允许在不影响正在进行的操作的情况下顺利减少实例。

Azure 策略

Azure 提供了一组与负载均衡器及其依赖项相关的大量内置策略。 可以通过 Azure Policy 审核上述一些建议。 例如，可以检查以下情况：

  • 负载均衡器（不包括基本 SKU 负载均衡器）在其前端中为公共 IP 地址启用了复原功能。
  • 启用资源日志可以跟踪资源上发生的活动和事件，并提供对更改的可见性和见解。

若要进行全面的治理，请查看负载均衡器 和其他可能影响流量分发安全性的策略 Azure Policy 内置定义。

Azure 顾问建议

Azure 顾问是一名个性化的云顾问，可帮助你遵循最佳做法来优化 Azure 部署。 顾问建议与 Well-Architected 框架支柱保持一致。

有关详细信息，请参阅 Azure 顾问中的建议。