本指南通过Azure网络设计指南提供了一个有序的阅读路径,用于将本地工作负荷迁移到Azure基础结构即服务(IaaS),而无需重新构建应用程序。 按照编号的步骤从头开始构建网络,在每个阶段做出正确的决策。
Overview
直接迁移是指将现有本地部署的工作负载迁移到 Azure 虚拟机 (VM) 上,而只需对应用程序架构做极少改动。 应用程序保留其现有的通信模式、依赖项和配置。 在 Azure 中构建的网络必须支持这些现有模式,同时利用 Azure 原生的安全和连接服务。
目标体系结构是一种中心辐射型拓扑,其中包含集中式共享服务。 单个中心虚拟网络(VNet)将VPN 网关或 ExpressRoute 连接托管回本地,Azure Bastion用于安全 VM 访问,Azure 防火墙用于集中流量检查和 DNS 转发。 辐射虚拟网络承载你迁移后的工作负载虚拟机,这些虚拟机默认彼此隔离,并通过中心网络连接,以实现跨工作负载通信。
此阅读路径介绍五个阶段中的 10 篇基本文章。 每篇文章都基于你在上一步中做出的决策。 最后,你有一个生产就绪的网络设计,它支持迁移的工作负载,具有深层防御安全性和连接性。
先决条件
- 阅读Azure 网络规划和设计概述,以了解可用服务和指南结构。
- 完成现有本地网络的清单:IP 范围、子网、防火墙规则、DNS 区域和应用程序间流量流(你将参考基础文章中的此清单:VNet 和子网、IP 地址规划和 NSG 配置)。
- 确定计划首先迁移的工作负载。 在迁移完整资产之前,先从试点组开始。
- 记录本地连接要求:带宽到Azure、延迟敏感度和故障转移预期。
阅读路径
按顺序处理这些阶段。 每个阶段都基于上一阶段的决策。
阶段 1:基础
从三篇基础文章开始。 这些决定塑造了后面的一切。
1. 虚拟网络和子网
创建托管已迁移 VM 的 VNet。 将现有网段映射到Azure子网。 重点关注子网隔离边界:哪些工作负载共享一个子网,哪些工作负载需要各自独立的子网,以及根据虚拟机数量每个子网需要多少个 IP 地址。
2. IP 地址规划
避免 IP 与本地环境重叠。 为每个 VNet 分配一个 /16 无类别域间路由(CIDR)地址池,以为未来增长预留空间。 如果本地范围与Azure保留地址或其他Azure订阅重叠,请在迁移之前规划重新寻址策略。
将现有防火墙规则映射为网络安全组(NSG)。 将本地访问控制列表(ACL)转换为具有默认拒绝状态的 NSG 规则。 使用应用程序安全组(ASG)按角色对 VM 进行分组,而不是管理单个 IP 地址。
阶段 2:拓扑
4. 轮辐式拓扑
中心辐射拓扑是多工作负载直接迁移的默认拓扑。 将共享服务放置在中心 VNet 中:VPN 网关、Azure Bastion、Azure 防火墙和 DNS 转发器。 每个工作负荷都拥有一个与中心建立对等互连的辐射型 VNet。 各辐射分支通过中心防火墙进行通信,从而实现对流量的集中控制。
阶段 3:连接
5. 混合连接
连接到本地环境的 VPN 网关 或 Azure ExpressRoute 是最关键的迁移依赖项。 如果没有此连接,迁移的 VM 无法访问他们依赖的本地服务,并且用户无法访问迁移的应用程序。 根据清单中记录的流量模式调整网关带宽大小。
6. 开发人员和管理员访问权限
Azure Bastion 可为已迁移的 VM 提供安全的远程桌面协议(RDP)和安全外壳协议(SSH)访问,而无需将其暴露到公共互联网。 在中心 VNet 中部署 Bastion,以便所有辐射虚拟网络共享同一个接入点。 用这项托管服务替换现有的跳板机基础架构。
阶段 4:安全性
在迁移期间保留旧的 DNS 命名行为。 迁移的 VM 需要解析本地主机名,而本地系统需要解析Azure托管的名称。 为双向转发配置Azure DNS专用解析程序。 保留现有的 DNS 命名约定,以避免应用程序重新配置。
8. 出站互联网访问
通过中心防火墙集中所有出站 Internet 流量。 关闭辐射型 VNet 上的默认出站访问,并使用用户定义路由 (UDR) 将出站流量通过 Azure 防火墙 进行路由。 此方法反映了现有的本地模型,其中外围防火墙控制所有 Internet 绑定的流量。
9. Azure 防火墙
在中心 VNet 中部署 Azure 防火墙,以集中控制东西向(辐射网络之间)和南北向(出站)流量。 将本地防火墙策略转换为Azure 防火墙规则。 对非 HTTP 流量使用网络规则,对以完全限定域名 (FQDN) 为目标的 HTTP/HTTPS 流量筛选使用应用规则。
阶段 5:操作
10. 网络监视和可观测性
设置 Azure 网络观察程序 和 连接监视器 以验证迁移基线。 验证连接路径是否按预期工作。 在迁移生产工作负荷之前,测量Azure VM 与本地系统之间的延迟,并建立性能基准。
条件文章
并非每个直接迁移都需要相同的一组文章。 根据具体要求包括以下文章:
| 条件 | 文章 | 何时应包含 |
|---|---|---|
| 面向 Internet 的应用程序 | Internet 入口 | 必须可从 Internet 访问已迁移的应用程序 |
| 需要第 7 层 (L7) 负载均衡 | 应用程序交付和性能 | 你的工作负载需要 Azure 应用程序网关 或 Azure Front Door |
| 公共 Web 应用程序 | Web 应用程序防火墙 | 迁移的应用程序为公共 HTTP/HTTPS 流量提供服务 |
| 公网 IP 暴露 | DDoS 保护 | 您对具有公共终结点的资源有正常运行时间要求 |
| 需要多区域支持 | 多区域网络 | 需要灾难恢复或主动-主动部署 |
| 跨区域连接 | 跨区域和多云连接 | 其他区域或其他云也在范围内 |
| 分支级传输 | Azure 虚拟 WAN | 您拥有多个分支机构或连接边缘节点 |
| PaaS 组件 | PaaS 专用访问 | 某些工作负荷组件迁移到 Azure PaaS 服务 |
| 大型 VNet 资产 | 集中式网络管理 | 此次迁移将形成一个需要集中治理的多 VNet 环境 |
总结
通过遵循此学习路径,你设计了一个具有集中式共享服务的中心辐射网络,建立了与本地环境之间的 VPN 或 ExpressRoute 连接,部署了 Azure 防火墙 以实现集中流量检查,配置了用于名称解析的 DNS 转发,通过 Azure Bastion 保护对 VM 的访问,并设置了监控来验证迁移结果。 此体系结构支持迁移的工作负载,同时提供集中的安全性和操作可见性。
后续步骤
- 迁移和现代化网络路径:如果下一阶段涉及采用 PaaS 服务或容器
- 设计阶段一目了然:Azure 网络设计的通用分阶段摘要
- Azure 网络规划和设计概述:按功能浏览所有可用服务