AIX UNIX 本地迁移到 Azure Linux
此解决方案介绍如何从 IBM AIX Unix 平台迁移到 Azure 中的 Red Hat Enterprise Linux (RHEL)。 实际示例是面向大客户的“医疗健康与人类服务”应用程序。 低事务时间和延迟是旧系统和 Azure 系统的重要要求。 一项重要功能是在数据库中存储客户信息，该数据库可链接到包含相关图形图像的网络文件存储。 Azure 通过 Azure NetApp 文件满足此需求。
体系结构
下图显示了预迁移的本地 AIX 旧系统体系结构：
下载此体系结构的 Visio 文件。
网络设备提供大量网络路由和负载均衡层 (A)。
呈现层 (B) 在其自己的子网中使用三个 Java Web 前端计算机，该子网通过防火墙对网络流量进行分段。
防火墙 (C) 提供所有参与层和子系统之间的网络边界。 尽管防火墙是有效的，但它们也是管理负担。
系统向应用程序层 (D) 提供用户请求，其中包含三个 Web 应用程序服务器。
应用程序层调入 DB2 数据库和网络连接存储 (NAS)：
数据库 (E) 是 AIX 上的 DB2。 在高可用性/灾难恢复（HA/DR）群集中配置了三台 DB2 服务器。
应用程序将面向客户和用户的图片和 PDF 等二进制对象存储在 NAS 子系统 (F) 中。
管理服务器和 MQ 服务器 (G) 位于其自己的子网中，通过防火墙进行分段。
轻型目录访问协议 (LDAP) 标识管理服务 (H) 位于其自己的子网中，通过防火墙进行分段。
下图显示了 Azure RHEL 迁移后系统体系结构：
下载此体系结构的 Visio 文件。
数据流
Azure 系统中的流量通过 Azure ExpressRoute 和 Azure 流量管理器路由：
- ExpressRoute 为 Azure 虚拟网络提供安全且可靠的专用连接。 ExpressRoute 使用低延迟、高可靠性和速度，以及最高可达 100 Gbps 的带宽连接到 Azure。
- 流量管理器将面向公众的应用程序流量分发到 Azure 区域内。
网络管理层提供终结点安全、路由和负载均衡服务。 此层使用 Azure 负载均衡器和 Azure Web 应用程序防火墙。
Azure 应用程序服务充当表示层。 应用程序服务是适用于 .NET 或 Java 应用程序的平台即服务 (PaaS) 层。 可以在 Azure 区域内或跨 Azure 区域配置应用程序服务以实现可用性和可伸缩性。
此解决方案在其自己的虚拟网络中封装每个应用层，通过网络安全组进行分段。
可用性集和共享 Azure 存储在应用程序层级别为虚拟机 (VM) 提供高可用性和可伸缩性。 应用程序群集服务器共享事务状态，并根据需要纵向扩展 VM。
应用程序使用专用终结点连接在 Azure SQL 数据库中存储和访问数据。 SQL 数据库在业务连续性配置中运行，该配置为自动和跨地理 BCDR 提供异地复制和自动故障转移组。
Azure NetApp 文件提供了共享 NAS，可快速访问二进制数据并将其复制到次要区域。
次要区域为 BCDR 提供以下组件：
- Azure Site Recovery 在主动-被动配置中备份 VM 映像以进行 DR 故障转移。 Site Recovery 在次要区域中创建一致的 VM 映像副本，并使 VM 映像保持同步。
- SQL 数据库业务连续性配置使数据库事务保持一致。 SQL 数据库预配副本数据库，并使其与同步或异步数据复制保持同步。
该系统还包含以下组件：
管理虚拟网络中的一个或多个 VM 提供管理功能。
Azure 服务总线实现 MQ Series 基础结构，并为应用程序提供消息队列服务。 有关从 MQ Series 迁移到 Azure 服务总线的详细信息，请参阅从 ActiveMQ 迁移到 Azure 服务总线。
Microsoft Entra ID 为从旧 LDAP 服务迁移的所有 Azure 实体和标识提供标识和访问管理。
组件
Azure ExpressRoute 是一项服务，它通过连接提供商方便的专用连接将本地网络扩展到Microsoft云服务。 在此体系结构中，ExpressRoute 提供与 Azure 系统的安全、可靠的专用连接，低延迟和高速和带宽。
Azure 流量管理器 是基于域名系统（DNS）的流量负载均衡器，用于跨 Azure 区域分配流量。 在此体系结构中，流量管理器通过高可用性和快速响应跨 Azure 区域分发面向公众的应用程序流量。
Azure 负载均衡器 根据配置的负载均衡规则和运行状况探测在后端 VM 之间分配传入网络流量，从而支持高可用性。 负载均衡器在开放式系统互连 (OSI) 模型的第 4 层上运行。 在此体系结构中，负载均衡器与 Azure Web 应用程序防火墙配合使用，以提供替代旧网络设备的网络管理层。
Azure Web 应用程序防火墙 是一种云原生服务，可保护 Web 应用程序免受恶意攻击和漏洞。 在此体系结构中，它提供终结点安全性和保护，并取代了将旧版 AIX 系统中的网络流量分段的多个防火墙。
Azure 应用服务 是一项完全托管的 Web 托管服务，用于在可缩放且可靠的云基础结构上为任何平台部署企业 Web 应用。 在此体系结构中，应用服务充当呈现层。 它取代了 Java Web 前端计算机，并为 .NET 或 Java 应用程序提供 PAAS 功能。
Azure 虚拟机 是一项提供按需可缩放计算资源的服务。 虚拟机提供虚拟化的灵活性，而无需购买和维护物理硬件。 在此体系结构中，服务在具有共享存储的可用性集中托管应用程序层服务器。
- Azure 固态硬盘（SSD）托管磁盘 是 Azure VM 的块级存储卷。
- Azure 虚拟网络接口卡（NIC） 允许 Azure VM 与 Internet、Azure 和本地资源通信。 可以将多个虚拟 NIC 添加到一个 Azure VM，以便子 VM 可以具有其自己的专用网络接口设备和 IP 地址。
Azure 虚拟网络 是 Azure 专用网络的基础。 虚拟网络提供 Azure 基础结构优势，例如可伸缩性、可用性和隔离性。 在此体系结构中，虚拟网络使 Azure 资源（如 VM）能够安全地相互通信、Internet 和本地网络。
Azure 文件 在云中提供完全托管的文件共享，可通过行业标准服务器消息块 （SMB） 协议进行访问。 云和本地 Windows、Linux 和 macOS 部署可以同时装载 Azure 文件共享。 在此体系结构中，Azure 文件存储提供共享文件存储功能，作为已迁移应用程序的总体存储策略的一部分。
Azure SQL 数据库 是一个完全托管的数据库 PaaS，它始终在最新的 OS 和最稳定的 SQL Server 数据库引擎版本上运行，以提供最高的可用性。 在此体系结构中，SQL 数据库处理数据库管理功能，例如升级、修补、备份和监视，而无需用户参与。
Azure NetApp 文件 提供由 NetApp 提供支持的企业级 Azure 文件共享。 此体系结构使用 Azure NetApp 文件来帮助企业轻松迁移和运行基于文件的复杂应用程序，无需更改代码。
Azure Site Recovery 是 Azure 原生的 DR 服务。 在此体系结构中，Site Recovery 部署复制、故障转移和恢复过程，以帮助在计划内和计划外中断期间使应用程序保持运行。
Azure 服务总线是一种可靠的云消息传递服务，具有简单的混合集成。 在此体系结构中，服务总线为应用程序提供消息队列服务。
Microsoft Entra ID 是基于云的企业标识和从 Microsoft 访问管理服务。 在此体系结构中，Microsoft Entra 单一登录和多重身份验证可帮助用户登录和访问资源，同时提供网络安全攻击的保护。
备选方法
Azure 应用程序服务环境适用于需要规模大且必须进行隔离或安全网络访问的应用程序工作负载。 此功能提供完全隔离且专用的环境，从而安全地大规模运行应用程序服务。 应用程序服务环境可以托管以下类型的应用：
- Linux Web 应用，如当前示例中所示
- Windows Web 应用
- Docker 容器
- 移动应用
- Functions
方案详细信息
旧系统和云实现之间的一个不同之处在于处理网络分段。 旧系统使用防火墙对网络进行分段。 Azure 等云平台使用基于多个条件筛选流量的虚拟网络和网络安全组对网络进行分段。
系统之间的另一个不同之处在于其高可用性 (HA) 和灾难恢复 (DR) 模型。 在旧系统中，HA/DR 主要使用备份，但在某种程度上，在同一个数据中心内使用冗余服务器。 此配置提供适中的 DR，但几乎没有 HA 功能。 改进 HA/DR 是迁移到 Azure 平台的关键原因。 Azure 使用群集、共享存储和 Azure Site Recovery 来提供高级别的 HA/DR。
可能的用例
在 Azure 中从本地 IBM AIX 迁移到 RHEL 的关键原因可能包括以下因素：
更新了硬件并降低了成本。 本地旧硬件组件不断过时和失去支持。 云组件始终保持最新。 云中的逐月成本可能较低。
敏捷 DevOps 环境。 在本地 AIX 环境中部署合规性更改可能需要几周的时间。 可能必须多次设置类似的性能工程环境以测试更改。 在 Azure 云环境中，可以设置用户验收测试 (UAT)和开发环境（以小时为单位）。 可以通过新式且定义完善的 DevOps 持续集成和持续交付 (CI/CD) 管道来实现更改。
改进了业务连续性和灾难恢复 (BCDR)。 在本地环境中，恢复时间目标 (RTO) 可能很长。 在本地 AIX 环境示例中，通过传统备份和还原的 RTO 为两天。 迁移到 Azure 后，RTO 缩短为两小时。
注意事项
这些注意事项实现 Azure Well-Architected 框架的支柱，这是一组指导原则，可用于提高工作负荷的质量。 有关详细信息，请参阅 azure Well-Architected Framework
可靠性
可靠性可确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性的设计评审清单。
Azure NetApp 文件可以将文件存储保存在通过 Azure NetApp 文件卷的跨区域复制更新的次要区域中。 此 Azure 功能通过跨区域卷复制提供数据保护。 如果发生区域范围的服务中断，则可以对关键应用程序进行故障转移。 跨区域卷复制目前为预览版。
应用程序群集服务器根据需要纵向扩展 VM，从而提高 Azure 区域内的可用性。
安全性
安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全的设计评审清单。
此解决方案使用 Azure 网络安全组来管理 Azure 资源之间的流量。 有关详细信息，请参阅网络安全组。
尽可能按照 Azure 网络安全最佳做法进行操作。
对于 VM 或基础结构即服务 (IaaS) 安全性，请按照 Azure 中 IaaS 工作负载的最佳安全做法进行操作。
成本优化
成本优化是研究减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。
将 AIX 工作负载迁移到 Azure 中的 Linux 可能会节省大量成本。 可以消除硬件维护，降低设施成本，并通常将运营成本降低 8 到 10 倍。 Azure 可以根据需要为季节性或定期工作负载提供额外的容量，从而降低总体成本。
将 AIX 工作负载迁移到 Azure 还可以使用云原生服务降低成本。 示例包括：
- 将 Azure 应用程序服务用于表示层，而不是设置多个 VM。
- 使用 Azure 虚拟网络（而不是基于硬件的防火墙）对工作负载进行分段。
卓越运营
卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营的设计评审清单。
对于主动监视和管理，请考虑使用 Azure Monitor 来监视已迁移的 AIX 工作负载。
性能效率
性能效率是工作负荷的缩放能力，以满足用户以高效方式满足它的需求。 有关详细信息，请参阅 性能效率的设计评审清单。
Azure ExpressRoute 支持使用大量带宽的大规模实现，以进行初始复制或不断变化的数据复制。
基础结构管理（包括可伸缩性）是在 Azure 数据库中自动完成的。
可以通过添加更多应用程序服务器 VM 实例来横向扩展应用程序层。
此体系结构中的潜在瓶颈是存储和计算子系统。 请确保相应地选择存储和 VM SKU。
可用的 VM 磁盘类型包括超级磁盘、高级 SSD、标准 SSD 和标准硬盘驱动器（HDD）。 对于此解决方案，最好使用高级 SSD 或超级磁盘。
要估计来自 AIX 系统的 VM 的大小，请记住 AIX CPU 大约比大多数 x86 vCPU 快 1.4 倍。 此准则可能因工作负载而异。
将相互通信所需的多个 VM 放置在邻近放置组中。 定位彼此接近的 VM 可提供最低的通信延迟。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
首席作者：
- Jonathon Frost | 首席项目经理
后续步骤
- 将 AIX 工作负载迁移到 Azure：方法和最佳做法。
- AIX 到 Red Hat Enterprise Linux 战略迁移规划指南。
- 有关详细信息，请联系 legacy2azure@microsoft.com。