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

Azure NAT 网关的 Azure 架构良好的框架评审

Azure 应用程序网关
Azure 虚拟网络
Azure 专用链接

本文提供 Azure NAT 网关的最佳做法。 本指南基于卓越体系结构的五大支柱:成本优化、卓越运营、性能效率、可靠性和安全性。

我们假设你具备 Azure NAT 网关的应用知识,并且精通相应的功能。 作为复习,请查看完整的 Azure NAT 网关文档集。

NAT 代表网络地址转换。 请参阅网络地址转换简介

成本优化

应通过 Azure 专用链接或服务终结点(包括存储)访问 PaaS 服务,以避免使用 NAT 网关。 专用链接或服务终结点不需要遍历 NAT 网关来访问 PaaS 服务。 在将 NAT 网关与专用链接或服务终结点的成本进行比较时,此方法将降低已处理的每 GB 数据的费用。 使用专用链接或服务终结点还有其他安全优势。

性能效率

每个 NAT 网关资源最多提供 50 Gbps 的吞吐量。 可以将部署拆分成多个子网,然后就可以为每个子网或子网组分配一个 NAT 网关,以便进行横向扩展。

每个 NAT 网关公共 IP 地址提供 64,512 个 SNAT 端口。 最多可以为 NAT 网关分配 16 个 IP 地址。 IP 地址可以是单独的标准公共 IP 地址或/和公共 IP 前缀。 对于连接到同一目标终结点的连接,根据每个分配的出站 IP 地址,NAT 网关可以分别为 TCP 和 UDP 支持最多 50,000 个并发流。 有关详细信息,请查看以下有关源网络地址转换 (SNAT) 的部分。 TCP 代表传输控制协议,UDP 代表用户数据报协议。

SNAT 耗尽

  • NAT 网关资源的默认 TCP 空闲超时值为 4 分钟,最多可配置为 120 分钟。 如果将此设置更改为比默认值更大的值,则 NAT 网关绑定到流的时间会更长,可能导致在 SNAT 端口库存方面出现不必要的压力。
  • 原子请求(每个连接一个请求)是一个糟糕的设计选项,因为它限制了缩放,并且降低了性能和可靠性。 而是应该重复使用 HTTP/S 连接来减少连接数和关联的 SNAT 端口数。 连接重用将更好地允许应用程序进行缩放。 由于使用 TLS 时可以减少握手次数、开销和加密操作的成本,因此应用程序的性能将会提高。
  • 如果客户端不缓存域名系统 (DNS) 解析器的结果,DNS 查找可能会在卷上引入许多单独的流。 使用 DNS 缓存来减少流量并减少 SNAT 端口的数量。 DNS 是一种命名系统,可将域名映射到连接到互联网或专用网络的资源的 IP 地址。
  • UDP 流(例如 DNS 查找)在空闲超时期间使用 SNAT 端口。 UDP 空闲超时计时器固定为 4 分钟,不能更改。
  • 使用连接池来调整连接卷。
  • 切勿以静默方式丢弃 TCP 流,且不要依赖 TCP 计时器来清理流。 如果不让 TCP 显式关闭连接,则 TCP 连接将保持打开状态。 中间系统和终结点将使此连接处于使用状态,进而使 SNAT 端口对其他连接不可用。 此反模式可能会触发应用程序故障和 SNAT 耗尽。
  • 在对造成的影响了解不深的情况下,请不要更改与 OS 级别的 TCP 关闭相关的计时器值。 当某个连接的终结点不符合预期时,尽管 TCP 堆栈会恢复,但应用程序的性能可能会受负面影响。 更改计时器值通常意味着底层设计出现了问题。 如果底层应用程序有其他反模式,更改计时器值后,SNAT 耗尽问题也将变得更严重。

查看以下指南以提高服务的缩放和可靠性:

  • 探索将 TCP 空闲超时降低到较低值的效果。 4 分钟的默认空闲超时可以提前释放 SNAT 端口库存。
  • 考虑对长时间运行的操作使用异步轮询模式,以释放连接资源供其他操作使用。
  • 生存期较长的流(例如重复使用的 TCP 连接)应使用 TCP Keepalive 或应用层 Keepalive,以避免中间系统超时。只有在不得已的情况下才应增加空闲超时,这不一定可以解决根本原因。 较长的超时可以在超时时间过去时降低失败的频率,同时也会造成延迟和不必要的失败。 可以从连接的一端启用 TCP keepalive,使连接从两端保持活动状态。
  • 对于具有 UDP 流量的生存期较长的流,可以启用 UDP keepalive 以使连接处于活动状态。 请记住,在连接的一端启用的 UDP keepalive 仅使连接在一端保持活动状态。 必须在连接的两端启用 UDP keepalive,才能使连接处于活动状态。
  • 应使用正常重试模式,以避免在发生暂时性故障或故障恢复期间出现频繁重试/突发。 反模式(称为“原子连接”)是指为每个 HTTP 操作创建新的 TCP 连接。 原子连接会阻止应用程序正常缩放,并且会浪费资源。 始终通过管道将多个操作输送到同一连接。 应用程序将对事务速度和资源开销有利。 当应用程序使用传输层加密(例如 TLS)时,处理新连接的开销会很大。 有关更多最佳做法模式,请参阅 Azure 云设计模式

卓越运营

虽然 NAT 网关可以与 Azure Kubernetes 服务 (AKS) 一起使用,但它并不是作为 AKS 的一部分进行管理的。 如果将 NAT 网关分配给容器网络接口 (CNI) 子网,那么将使 AKS Pod 通过 NAT 网关传出流量。

当跨区域使用多个 NAT 网关时,请使用 Azure 公共 IP 前缀或 BYOIP 前缀使出站 IP 资产可管理。 不能将大于 16 个 IP 地址(/28 前缀大小)的 IP 前缀大小分配给 NAT 网关。

使用 Azure Monitor 警报来监视 SNAT 端口使用情况、处理或丢弃的数据包以及传输的数据量,并就其发出警报。 使用 NSG 流日志监视来自配置了 NAT 网关的子网中的虚拟机实例的出站流量。

当使用 NAT 网关配置子网时,NAT 网关将替换该子网上所有 VM 到公共 Internet 的所有其他出站连接。 NAT 网关的优先级高于具有或没有出站规则的负载均衡器,以及直接分配给 VM 的公共 IP 地址。 Azure 会跟踪流的方向,并且不会发生非对称路由。 将正确地转换入站发起的流量(例如负载均衡器前端 IP),并且将通过 NAT 网关与出站发起的流量分开转换。 这种隔离性使得入站和出站服务能够无缝共存。

建议将 NAT 网关作为默认设置,以便为虚拟网络启用出站连接。 与 Azure 中的其他出站连接技术相比,NAT 网关更高效且操作更加简单。 NAT 网关按需分配 SNAT 端口,并使用更高效的算法来防止 SNAT 端口重用冲突。 不要依赖资产的默认出站连接(一种反模式), 而是改为使用 NAT 网关资源显式定义它。

可靠性

NAT 网关资源在一个可用性区域中高度可用,并且跨越多个容错域。 NAT 网关可以部署到“无区域”,其中 Azure 将自动选择某个区域来放置 NAT 网关。 用户也可以将 NAT 网关隔离到特定区域。

无法提供可用性区域隔离,除非每个子网只有特定区域内的资源。 相反,请为部署 VM 的每个可用性区域部署子网,将区域 VM 与匹配的地区 NAT 网关对齐,并构建单独的区域堆栈。 例如,在可用性区域 1 中的虚拟机与同样仅在可用性区域 1 中的其他资源一起出现在子网上。 在可用性区域 1 中配置 NAT 网关,用于为该子网提供服务。 请参阅下图。

演示区域堆栈的定向流的示意图。

虚拟网络和子网跨区域中的所有可用性区域。 无需按可用性区域来划分它们以容纳区域性资源。

安全性

使用 NAT 网关时,单个虚拟机(或其他计算资源)不需要公共 IP 地址并且可以保持完全专用。 此类无公共 IP 地址的资源仍可访问虚拟网络之外的外部源。 还可以关联公共 IP 前缀,以确保将一组连续的 IP 用于出站连接。 可以基于此可预测 IP 列表配置目标防火墙规则。

一种常见的方法是设计具有第三方防火墙或代理服务器的仅限出站网络虚拟设备 (NVA) 方案。 当 NAT 网关部署到具有 NVA 虚拟机规模集的子网时,这些 NVA 将使用 NAT 网关地址(而不是负载均衡器的 IP 或单个 IP)进行出站连接。 要将此方案与 Azure 防火墙结合使用,请参阅将 Azure 防火墙与 Azure 标准负载均衡器集成

显示具有负载均衡器三明治和 NAT 网关的防火墙的示意图。

Microsoft Defender for Cloud 可以通过 NAT 网关监视任何可疑的出站连接。 这是 Microsoft Defender for Cloud 中的一项警报功能。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

若要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。

后续步骤