从 Amazon Web Services (AWS) 网络负载均衡器迁移到 Azure 负载均衡器

如果当前使用的是 AWS 网络负载均衡器 (NLB)，并计划将工作负载迁移到 Azure，本指南可帮助你了解迁移过程、功能映射和最佳做法。 在 Azure 上，Azure 负载均衡器提供低延迟的第 4 层负载均衡功能，使你能够管理流向应用程序的 TCP 和 UDP 流量。 你将了解如何评估当前环境、规划和准备迁移，以及如何在保持应用程序可用性和性能的同时完成转换。

你的成就

按照本指南操作，你需要：

• 将 AWS 网络负载均衡器功能映射到 Azure 负载均衡器功能
• 为成功迁移准备环境
• 在最短的停机时间内规划和执行迁移
• 验证迁移的工作负荷是否符合性能和可靠性要求
• 了解如何实现体系结构的迭代，以在未来实现增强

本文使用游戏平台场景来演示适用于许多高性能工作负载的常见模式，例如多协议负载平衡、可用区冗余和客户端 IP 保留。

示例场景：游戏平台多协议负载均衡迁移

在此示例中，多人游戏平台使用 AWS 网络负载均衡器 (NLB) 同时处理来自游戏客户端的 TCP 和 UDP 流量。 工作负载的体系结构包括在 EC2 实例上运行的会话管理服务和部署在 EC2 实例中的实时游戏数据服务。前者在端口 7777 上基于 TCP 处理玩家身份验证和游戏大厅，后者在端口 7778 上基于 UDP 处理低延迟游戏数据包。 AWS NLB 为游戏分析和反作弊系统提供静态 IP 地址、跨可用区负载均衡和客户端 IP 保留。 此设置支持工作负载的核心游戏功能，即以低延迟处理实时多人游戏，同时在多个可用区确保可靠性。

体系结构概述

此体系结构示例展示了 AWS 和 Azure 中的常见网络负载均衡功能，包括多协议支持、静态 IP 地址、跨可用区分发和客户端 IP 保留。 目标是将此体系结构从 AWS 网络负载均衡器迁移到 Azure 负载均衡器，同时保持大致相当的功能和性能。 在我们的体系结构图中，TCP 流量表示游戏会话管理服务，UDP 流量表示实时游戏数据服务。

下面是 AWS 中工作负载的体系结构：

以下是同一游戏平台工作负载在迁移到 Azure 后的体系结构：

这两种体系结构提供等效的功能：

• 高可用性部署：跨多个可用区分发资源，以实现容错
• 网络隔离：虚拟网络具有针对负载均衡器和应用程序层的专用子网
• 多协议支持：使用特定于协议的后端池同时处理 TCP 和 UDP 流量
• 静态 IP 地址：使用一致的外部终结点地址建立客户端连接
• 跨可用区负载均衡：跨可用区进行基于哈希的流量分发（分发取决于客户端连接模式和会话持久性设置）
• 客户端 IP 保留：为分析和反作弊系统保留原始客户端 IP 地址
• 低延迟：针对低延迟场景进行了优化，最大限度地降低了处理开销；实际延迟取决于网络拓扑、VM 性能、数据中心设计和地理邻近度
• 高吞吐量：对于具有适当 VM 大小和配置的标准负载均衡器，可支持每秒数百万个并发连接和请求；实际容量取决于 SKU、VM 网络限制和优化
• 高级运行状况监视：全面的 TCP 和 HTTP/HTTPS 运行状况探测（UDP 服务需要在备用端口上进行 TCP 或 HTTP 运行状况检查）
• 网络安全控制：控制网络层之间的流量流的安全组/规则
• 自动缩放集成：根据流量需求和资源利用率自动缩放
• 全面的监视：详细的指标、访问日志和运行状况监视，用于故障排除和优化

生产环境注意事项

此次迁移被设计为直接转换迁移。 使用此方法，可以与现有的 AWS 设置并行构建 Azure 基础结构。 此方法可最大限度地降低批量迁移用户的复杂性，并在出现问题时实现快速回滚。 因此，在 DNS 直接转换期间遇到短暂的停机时间，但整个迁移过程旨在最大程度地减少服务中断。

估计的停机时间：

• DNS 传播时间：300 秒 TTL 的情况下为 5-15 分钟
• 会话中断：在直接转换期间，现有会话可能会中断
• 服务可用性：在切换期间，服务无法使用 DNS 名称解析。 只要服务不会同时迁移，单个服务仍可通过 IP 地址使用。

建议的维护时段：

• 持续时间：低流量期间为 1-2 小时
• 缓冲时间：额外增加 30 分钟，以应对不可预见的问题
• 回滚时间：15-30 分钟（视需要而异）

步骤 1：评估

在从 AWS 网络负载均衡器迁移到 Azure 负载均衡器之前，请务必评估现有体系结构并确定需要映射或替换的功能。 此评估有助于确保迁移过程顺利进行并维护游戏平台的功能。

直接功能映射

从 AWS NLB 到 Azure 负载均衡器的平台功能映射如下所示：

功能不匹配和策略

如果工作负载使用的 NLB 功能无法在 Azure 负载均衡器中直接解决，请考虑使用以下策略来达到类似的结果。

• 使用其他 Azure 服务直接进行功能替换：将 AWS NLB 功能替换为 Azure 负载均衡器等效功能，同时保留核心功能。 此方法优先考虑最少的中断，并使用本机 Azure 集成确保安全、监视和性能优化。

• 体系结构增强方法：将迁移作为超越 AWS NLB 功能的现代化升级机会，整合用于 HTTP(S) API 的 Azure 应用程序网关、用于全球分发的 Azure 流量管理器以及用于实现 CDN 和 DDoS 防护的 Azure Front Door。

最后，如果没有直接的 Azure 负载均衡器等效功能，你需要决定是否需要 AWS NLB 功能，并相应地调整工作负载。

代理协议支持

AWS NLB 功能：AWS NLB 提供代理协议 v2 支持，具体表现为：

• 将会保留客户端 IP 信息并通过协议标头将其传递到后端目标
• 将启用客户端 IP 可见性，即使直接客户端 IP 保留不可用
• 适用于负载均衡器链接场景和特定网络配置

Azure 负载均衡器方法：Azure 负载均衡器没有直接代理协议支持，但可通过以下方式提供等效功能：

• 应用程序级解决方案：实现自定义标头或应用程序逻辑，以在需要时跟踪客户端信息
• Azure 应用程序网关集成：对于基于 HTTP 的 API，请使用提供 X-Forwarded-For 标头的应用程序网关

前面的代理协议支持演示了功能严重不匹配的一个例子。 除此之外，还有其他功能也可能在 Azure 负载均衡器中没有一一对应的等效功能。 在迁移之前，请评估当前在 AWS NLB 中使用的功能，并确定它们是否具有直接等效项或是否需要替代策略。

步骤 2：准备

通过详细评估，可以发现对源端资源进行调整的机会，从而简化迁移过程，并提升迁移后的运营效率。 此步骤重点介绍对 AWS NLB 配置和相关服务的针对性调整，以确保工作负载在 Azure 上的兼容性和性能。

源服务配置

成功的迁移需要详细记录现有的 AWS NLB 配置和依赖服务，以确保顺利过渡到 Azure 负载均衡器。

特定于协议的负载均衡规则记录

• 记录现有的 AWS NLB 侦听器配置和目标组设置，以确保实现等效的 Azure 负载均衡器规则。 请使用 AWS CLI 负载均衡器命令收集针对 TCP 和 UDP 协议的详细配置信息。
• 根据 AWS NLB 目标组文档，导出所有路由配置、运行状况检查设置和客户端 IP 保留配置。
• 记录跨可用区负载均衡设置和静态 IP 配置，以确保等效的 Azure 可用区冗余和静态公共 IP 设置。

运行状况检查配置映射

根据 Azure 负载均衡器运行状况探测配置指南，将 AWS NLB 运行状况检查配置映射到 Azure 负载均衡器运行状况探测等效配置。 这可确保 TCP 服务运行状况监视功能在迁移后继续正常运行，并以适合工作负载的间隔为 UDP 服务（在备用端口上使用 TCP 或 HTTP 探测）实施适当的备用运行状况检查策略。

建立性能基线

• 捕获当前性能指标，包括延迟百分位数（P50、P95、P99）、并发连接数、吞吐量和数据包丢失率
• 记录当前缩放模式和峰值负载特征
• 记录分析和安全系统的客户端 IP 保留要求

依赖项变更

通过更新依赖服务和配置来准备好迁移，以确保与 Azure 负载均衡器兼容。

应用程序更改

• 使用 Azure 负载均衡器运行状况探测为服务配置基于 TCP/HTTP/HTTPS 的运行状况监视。
• 使用负载均衡器指标配置与 Azure Monitor 的日志记录集成。

DNS 配置更改

• 将域记录上的 DNS TTL 值减少到 300 秒（或减少到 60 秒，以满足最短停机时间要求），以更快完成直接转换。
• 如果计划使用 Azure DNS，请根据 Azure DNS 配置指南创建指向 Azure 负载均衡器静态公共 IP 地址的 A 记录。 此更改可在迁移直接转换期间实现快速 DNS 传播，同时对活动会话的影响最小。

后端池更新

• 为 TCP 和 UDP 服务配置跨多个可用区的后端池成员
• 使用 Azure 虚拟机规模集实现基于应用程序指标的自动缩放服务
• 实现可用区分发策略，以在发生可用区故障期间保持性能

环境更改

通过部署必要的基础结构并配置安全性和监视组件来支持迁移的工作负荷来准备 Azure 环境。 此准备有助于确保平稳过渡，并充分减少迁移过程中的潜在问题。

Azure 资源预配

• 在按照负载均衡器部署指南进行直接转换之前，请使用基础结构即代码部署 Azure 负载均衡器、虚拟机和虚拟机规模集。
• 在直接转换之前，请配置静态公共 IP 地址和可用区冗余，以确保平台稳定性。
• 在生产环境直接转换之前，请在并行环境中实现充分的测试和验证。

网络安全组

• 为您的流量要求设置网络安全组（NSG），以匹配 AWS 安全组规则。
• 使用 Azure DDoS 防护服务为工作负载配置 DDoS 防护。
• 在迁移之前、期间和迁移后保持安全状况。

监视配置

• 配置 Azure 负载均衡器运行状况事件日志 指南。 根据迁移计划，可以设置监视
• 使用 Azure 负载均衡器标准诊断设置仪表板和警报规则，包括延迟监视、并发连接和运行状况探测状态。

更改顺序和依赖项

以下列表概述了在迁移过程中要实现的一系列逻辑更改。 此序列可确保在配置开始之前提供所有依赖服务，从而在整个迁移过程中保留功能。 将其视为迁移当天的预检清单。

更改的一般流程是部署基础结构、迁移服务，然后配置负载均衡规则、运行状况探测和监视。 此序列可确保在配置开始之前提供所有依赖服务，从而在整个迁移过程中保留用户体验。

虽然具体步骤可能因体系结构而异，但常规顺序如下：

1. Azure 基础结构部署 - 首先部署采用静态 IP 的负载均衡器和 VM，因为这是后续配置步骤所必需的。
2. 运行状况探测配置 - 根据负载均衡器运行状况探测指南为匹配 AWS 运行状况检查行为的两种协议类型配置运行状况探测。
3. 特定于协议的规则配置 - 使用适当的后端池分别为 TCP 和 UDP 流量配置单独的负载均衡规则。
4. DNS 准备 - 减小 TTL 值并为域准备 DNS 记录更新。 在服务切换时，此步骤至关重要，能够最大程度地减少用户断线。
5. 应用程序服务迁移 - 将服务迁移到 Azure VM 和规模集。 这可以与 Azure 基础结构部署并行完成，以节省时间。
6. 监视设置 - 为特定于应用程序的指标配置 Azure Monitor 仪表板和警报，这些指标包括延迟、连接和运行状况。

通常，迁移过程涉及部署和配置新的负载均衡器基础结构，然后迁移应用程序服务，然后配置监视。

步骤 3：评估

完成环境准备并进行必要的更改后，下一步是评估迁移计划并定义验证标准。 此步骤可确保所有功能均在迁移完成后按预期运行。

验证条件

在迁移规划过程中，必须定义衡量迁移成功的验证标准。 这些标准将有助于确保所有功能均在迁移完成后按预期运行。

成功条件定义

根据评估部分确定的原始 AWS NLB 功能制定验证标准：

功能条件

• 多协议路由准确性：TCP 和 UDP 流量将根据协议和端口路由到正确的后端池
• 服务运行状况：所有服务都将报告跨可用区的正常状态
• 多可用区分发：流量通过自动故障转移在可用区之间正确分发
• 连接处理：会话在基础结构更改和缩放事件期间保持连接性

性能条件

• 延迟基线：响应时间在 AWS NLB 基线的上下 5% 以内
• 吞吐量容量：处理与 AWS NLB 相当的每秒并发连接数和请求数
• 连接建立：建立新会话时的延迟满足要求
• 抖动最小化：一致的数据包传送计时，带来流畅的体验

可靠性条件

• 会话连续性：会话在可用区故障和缩放事件期间保持连接
• 高可用性：满足所需的运行时间 SLA，并在几秒钟内发生自动故障转移
• 特定于平台的 SLA：满足特定于平台的用户体验要求
• 安全功能：欺诈检测系统的客户端 IP 跟踪功能正常运行

工作负载验证方法

定义用于验证为工作负载建立的成功标准的方法。 其中包括自动化和手动测试方法，以确保全面覆盖所有功能。

自动测试

• 创建涵盖所有功能的综合自动化测试，这些功能包括：
  • 针对 TCP 和 UDP 流量的多协议负载均衡验证
  • 使用适当的工具针对基线指标进行的性能和负载测试
  • 有关实时要求的延迟和抖动测试
  • 负载条件下的连接故障转移和缩放场景测试

手动验证清单

• 跨 TCP 和 UDP 服务测试客户端连接
• 验证会话创建、操作和终止流
• 测试客户端 IP 保留方面的安全系统功能
• 在峰值负载条件下验证实时性能
• 在可用区故障和缩放事件期间测试会话持久性
• 验证分析和监视数据收集

步骤 4：流程

在你的迁移计划已经制定完成，且准备工作也已全部结束之后，你就能够继续推进了。 按照以下的详细步骤，可以在迁移当天顺利执行迁移，同时最大限度地减少对活动会话的影响。

迁移执行

迁移的执行涉及一系列步骤，旨在确保从 AWS NLB 顺利过渡到 Azure 负载均衡器。 此流程包括最终验证、并行测试、DNS 直接转换、直接转换后验证和 AWS 资源停用。

最终验证和测试

在直接转换之前验证 Azure 负载均衡器配置和服务运行状况：

• 使用适当的客户端测试 TCP 和 UDP 终结点
• 验证针对不同服务类型的多协议路由
• 确认多可用区后端池分发和服务故障转移
• 使用现实场景验证跨多个可用区的服务功能
• 测试负载下的高可用性和可用区故障转移场景
• 将性能指标与 AWS NLB 基线进行比较，包括延迟和抖动指标
• 验证浮动 IP (DSR) 来宾操作系统配置和网络安全预检查（配置环回接口，根据需要启用弱主机，并允许 NSG/防火墙中的负载均衡器探测 IP 168.63.129.16）

DNS 直接转换执行

执行从 AWS NLB 到 Azure 负载均衡器的 DNS 直接转换。 更新域 DNS 记录以指向 Azure 负载均衡器静态公共 IP 地址，并使用 DNS 监视工具监视 DNS 传播。

直接转换后验证

在直接转换之后的步骤中，可以通过确保所有服务均正常运行且性能满足实时要求来证实迁移成功。

功能验证：

• 验证这两种协议的所有服务路由均正常进行
• 验证安全系统的客户端 IP 保留功能
• 测试会话创建、操作和终止流
• 验证 TCP 服务的运行状况探测行为，以及 UDP 服务的备用运行状况检查方法

性能验证：

• 根据 AWS NLB 基线监视响应时间和延迟
• 验证吞吐量容量是否满足并发会话要求
• 测试抖动和数据包丢失率以确保实时质量

AWS 资源停用

验证成功后，停用 AWS 资源：

• 使用生产流量监视 Azure 负载均衡器 24-48 小时
• 验证不会再将流量路由到 AWS NLB
• 备份 AWS NLB 配置以用于回滚功能
• 终止 AWS NLB 和关联的基础结构资源
• 根据 DNS TTL、流量模式和回滚策略确定监视窗口（通常为 24-72 小时，可根据需要延长以覆盖高峰流量时段）

一般来说，如果在定义的监视期内所有成功标准均得到一致满足，并且与 AWS NLB 基线相比未出现性能下降，则认为迁移成功。 在最终停用之前，请根据需要延长监视时间，以覆盖高峰时段和周末流量模式。

迭代优化

迁移后，请专注于优化 Azure 负载均衡器配置并验证性能、路由准确性和高可用性。 此迭代优化过程可确保迁移的工作负载满足根据 Azure 负载均衡器的 Azure 架构良好的框架服务指南在评估步骤中建立的所有成功标准。

迭代改进过程

迁移过程是迭代的，应根据性能反馈和测试进行调整，直到满足成功标准：

性能优化循环

1. 基线度量：将 Azure 负载均衡器指标与 AWS NLB 基线进行比较，包括延迟、抖动和连接指标
2. 瓶颈识别：识别路由、协议处理或后端通信中的性能差距
3. 配置优化：调整负载均衡器设置、后端探测间隔、连接限制和特定于应用程序的参数
4. 验证测试：使用模拟负载重新测试性能并衡量改进情况
5. 监视调整：更新特定于应用程序的 KPI 的监视阈值和警报规则

路由准确性优化

1. 流量模式分析：监视 TCP 和 UDP 的实际请求路由模式与预期模式
2. 协议规则优化：优化 TCP 和 UDP 路由规则以处理边缘情况和连接模式
3. 错误率分析：识别和修复导致会话错误或断开连接的路由规则
4. 用户体验验证：确保会话在两种服务类型之间无缝运行

高可用性验证

1. 流量分发验证：确认流量在两种协议下均可跨可用区正确分发
2. 故障转移过程测试：在高峰负载期间验证可用区之间的自动故障转移
3. 恢复功能：测试能否在发生可用区故障时快速恢复，同时维持活动的会话
4. 运行状况检查的准确性：确保运行状况检查能够正确识别服务问题，而不会发生误报

关键结论

在将使用 AWS 网络负载均衡器的工作负载迁移到 Azure 时，需要仔细规划和系统地执行，以获得满足实时要求的等效功能和性能。 关键成功因素包括：

评估和规划：在流程的早期将 AWS NLB 功能映射到 Azure 负载均衡器等效功能。 请特别注意高性能平台的多协议支持、客户端 IP 保留和低延迟要求。

使用 Azure 集成：利用 Azure 静态公共 IP 实现一致的终结点、利用 Azure Monitor 实现可观察性以及利用虚拟机规模集实现服务自动缩放，以满足工作负载中的功能性和非功能性要求。

在直接转换之前进行充分测试：使用模拟工具进行并行测试，以验证所有功能。 基于 AWS 环境建立基线指标，并确保 Azure 负载均衡器满足或超出性能预期（包括延迟、抖动和连接处理）。

规划最短停机时间：事先减小 DNS TTL 值，并并行准备所有基础结构。 实际的直接转换只涉及 DNS 更改，可最大限度地减少会话中断和用户影响。

迁移后监视和优化：使用迭代改进过程来优化性能、路由准确性和高可用性。 Azure 负载均衡器提供广泛的监视功能，可根据实际流量模式逐渐优化你的配置。

特定于平台的注意事项：侧重于延迟敏感型优化、多协议流量处理、安全系统的客户端 IP 保留，以及用于实现高可用性的可用区冗余。 Azure 负载均衡器可提供任务关键型平台所需的企业级可靠性和性能，但实际延迟性能取决于数据中心设计和网络拓扑。

后续步骤