你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
大型机应用程序迁移策略
当大多数团队将应用程序从大型机环境迁移到 Azure 时，他们通常遵循务实的方法：尽可能随时随地重复使用。 然后，启动分阶段部署，在其中重写或替换应用程序。
应用程序迁移通常涉及以下一种或多种策略：
重新托管： 从大型机移动现有代码、程序和应用程序。 重新编译代码，以在云实例中托管的大型机模拟器中运行。 此方法通常首先将应用程序移至基于云的仿真器，然后将数据库迁移到基于云的数据库。 此策略需要一些工程和重构，以及数据和文件转换。
或者，可以使用传统的托管提供程序重新托管。 云的主要优点之一是外包基础结构管理。 查找托管大型机工作负荷的数据中心提供商。 此模型可以购买一段时间，减少供应商锁定，并产生临时成本节省。
停用： 停用迁移前不再需要的应用程序。
重新生成：一些组织选择使用现代技术完全重写程序。 鉴于此方法增加了成本和复杂性，它并不像直接迁移方法那样普遍。 通常在此类迁移后，使用代码转换引擎开始替换模块和代码是有意义的。
替换：此方法将大型机功能替换为云中的等效功能。 软件即服务（SaaS）是一个选项。 借助 Saas，你将使用专为企业关注而创建的解决方案，例如财务、人力资源、制造或企业资源规划。 此外，许多特定于行业的应用程序现在可用于解决以前解决的自定义大型机解决方案的问题。
首先规划要最初迁移的工作负荷，然后确定移动关联应用程序、旧代码库和数据库的要求。
Azure 中的大型机仿真
Azure 服务可以模拟传统的大型机环境。 然后，可以重复使用现有的大型机代码和应用程序。 可以模拟常见的服务器组件，例如联机事务处理（OLTP）、批处理和数据引入系统。
OLTP 系统
许多大型机都有 OLTP 系统，这些系统为大量用户处理数千或数百万次更新。 这些应用程序通常使用事务处理和屏幕窗体处理软件，例如客户信息控制系统 (CICS)、信息管理系统 (IMS) 和终端接口处理器 (TIP)。
将 OLTP 应用程序移动到 Azure 时，大型机事务处理（TP）监视器的模拟器可以使用 Azure 上的虚拟机（VM）作为基础结构即服务（IaaS）运行。 Web 服务器还可以实现屏幕处理和表单功能。 将此方法与数据库 API（例如 ActiveX 数据对象（ADO）、开放数据库连接性（ODBC）和 Java 数据库连接性（JDBC）相结合，以便进行数据访问和事务。
时间约束的批量更新
许多大型机系统每月或每年更新数百万个帐户记录，例如银行、保险和政府中使用的记录。 大型机通过提供高吞吐量数据处理系统来处理这些类型的工作负荷。 大型机批处理作业通常本质上是串行的，取决于大型机主干提供的每秒输入和输出操作（IOPS），以获取性能。
基于云的批环境使用并行计算和高速网络来提高性能。 如果需要优化批性能，Azure 提供了各种计算、存储和网络选项。
数据引入系统
大型机从零售业、金融服务业、制造业和其他处理解决方案中获取大批量数据。 使用 Azure，可以使用简单的命令行实用工具（例如 AzCopy ）将数据复制到存储位置或从存储位置复制数据。 还可以使用Azure 数据工厂服务，从不同的数据存储引入数据，以及创建和计划数据驱动的工作流。
除了仿真环境，Azure 还提供可以增强现有大型机环境的平台即服务 (PaaS) 和分析服务。
将 OLTP 工作负荷迁移到 Azure
直接迁移方法是将现有应用程序快速迁移到 Azure 的无代码选项。 每个应用程序都按原样迁移，从而提供云的优势，无需进行代码更改的风险或成本。 在 Azure 上使用用于大型机事务处理 (TP) 监视器的仿真器支持此方法。
TP 监视器可从各种供应商处获得，并在虚拟机上运行，这是 Azure 上的基础结构即服务 (IaaS) 选项。 下图显示了 IBM Z/OS 大型机上由 IBM DB2（关系数据库管理系统（DBMS）支持的联机应用程序的前后。 用于 z/OS 的 DB2 使用虚拟存储访问方法 (VSAM) 文件来存储数据，并使用索引顺序访问方法 (ISAM) 来处理平面文件。 此体系结构还使用 CICS 进行事务监视。
在 Azure 上，仿真环境运行 TP 管理器和使用 JCL 的批处理作业。 在数据层中，DB2 替换为Azure SQL 数据库，不过也可以使用 Microsoft SQL Server、DB2 LUW 或 Oracle 数据库。 仿真器支持 IMS、VSAM 和 SEQ。 大型机的系统管理工具替换为在 VM 中运行的 Azure 服务和其他供应商提供的软件。
Web 服务器通常实现屏幕处理和表单输入功能，你可以将其与数据库 API（如 ADO、ODBC 和 JDBC）结合使用，以便进行数据访问和事务。 要使用的 Azure IaaS 组件的确切阵容取决于你喜欢的操作系统。 例如：
基于 Windows 的 VM：用于屏幕处理和业务逻辑的 Internet Information Server (IIS) 以及 ASP.NET。 使用 ADO.NET 进行数据访问和事务处理。
基于 Linux 的 VM： 基于 Java 的应用程序服务器，例如 Apache Tomcat 进程屏幕处理和基于 Java 的业务功能。 使用 JDBC 进行数据访问和事务处理。
将批工作负荷迁移到 Azure
Azure 中的批操作与大型机上的典型批环境不同。 大型机批处理作业通常是串行的，并且取决于大型机主干提供的 (IOPS) 以提高性能。 基于云的批环境使用并行计算和高速网络来提高性能。
要使用 Azure 优化批性能，请考虑计算、存储、网络以及监视选项，如下所示。
计算
使用：
具有最高时钟速度的 VM。 大型机应用程序通常是单线程的，大型机 CPU 具有较高的时钟速度。
具有较大内存容量的 VM 允许缓存数据和应用程序工作区域。
如果应用程序支持多线程，具有更高密度 vCPU 的 VM 可以利用多线程处理。
并行处理，因为 Azure 可以轻松横向扩展以进行并行处理，为批运行提供更多的计算能力。
存储
使用：
Azure 高级 SSD 或 Azure 超级磁盘存储适用于最大的可用 IOPS。
使用多个磁盘进行条带化，以在每个存储大小中获得更多 IOPS。
对存储进行分区以在多个 Azure 存储设备上分配 I/O。
网络
- 使用 Azure 加速网络以尽量降低延迟。
监视
- 使用监视工具、 Azure Monitor、 Application Insights 和 Azure 日志。 这些工具可帮助你监视超高性能的批处理运行并减少瓶颈。
迁移开发环境
云的分布式体系结构依赖于一组不同的开发工具，这些工具提供了新式做法和编程语言的优点。 为了简化这种转换，请结合旨在模拟 IBM z/OS 环境的其他工具使用开发环境。 以下列表显示 Microsoft 和其他供应商提供的选项：
| 组件 | Azure 选项 |
|---|---|
| z/OS | Windows、Linux 或 Unix |
| CICS | Azure 服务由 Micro Focus、Oracle、GT Software (Fujitsu)、TmaxSoft、Raincode 和 NTT 数据提供，或使用 Kubernetes 重写 |
| IMS | Micro Focus 和 Oracle 所提供的 Azure 服务 |
| 汇编程序 | Raincode 和 TmaxSoft 提供的 Azure 服务；或 COBOL、C 或 Java，或映射到操作系统函数 |
| JCL | JCL、PowerShell 或其他脚本工具 |
| COBOL | COBOL、C 或 Java |
| Natural | Natural、COBOL、C 或 Java |
| Fortran 和 PL/I | Fortran、PL/I、COBOL、C 或 Java |
| REXX 和 PL/I | REXX、PowerShell 或其他脚本工具 |
将数据库和数据迁移
应用程序迁移通常涉及重新托管的数据层。 可以将 SQL Server、开放源代码和其他关系数据库迁移到 Azure 上的完全托管解决方案。 可以将 Azure SQL 托管实例、Azure Database for PostgreSQL 和 Azure Database for MySQL 与 Azure 数据库迁移服务配合使用。
例如，如果大型机数据层使用以下项，则可以进行迁移：
IBM DB2 数据库或 IMS 数据库，请在 Azure 上使用 Azure SQL 数据库、SQL Server、DB2 LUW 或 Oracle Database。
VSAM 和其他平面文件，使用适用于 Azure SQL 数据库、SQL Server、DB2 LUW 或 Oracle 的索引顺序访问方法 (ISAM) 平面文件。
Generation Date Groups (GDG)，迁移到 Azure 上使用命名约定的文件和提供与 GDG 类似功能的文件扩展名的文件。
IBM 数据层包括一些也必须迁移的关键组件。 例如，迁移数据库时，还要迁移池中包含的数据集合（每个数据集合都包含 dbextents，其中 dbextents 是 z/OS VSAM 数据集）。 迁移必须包括标识存储池中数据位置的目录。 此外，迁移计划必须考虑数据库日志，其中包含对数据库执行操作的记录。 数据库可以有一个、两个（双日志或备用日志）日志或四个（双日志和备用日志）日志。
数据库迁移还包含以下组件：
- 数据库管理器：提供对数据库中数据的访问。 在 z/OS 环境中，数据库管理器可在其自己的分区中运行。
- 应用程序请求程序：在将请求传递到应用程序服务器之前，接受来自应用程序的请求。
- 联机资源适配器：包括用于 CICS 事务的应用程序请求程序组件。
- Batch 资源适配器：Z/OS 批应用程序的实现应用程序请求程序组件。
- 交互式 SQL （ISQL）： 以 CICS 应用程序和接口的形式运行，允许用户输入 SQL 语句或运算符命令。
- CICS 应用程序：使用 CICS 中的可用资源和数据源在 CICS 的控制下运行。
- Batch 应用程序：运行流程逻辑而无需与用户进行交互式通信，例如，生成大量数据更新或从数据库生成报告。
优化 Azure 的规模和吞吐量
一般来说，大型机纵向扩展，而云横向扩展。若要优化在 Azure 上运行的大型机样式应用程序的缩放和吞吐量，请务必了解大型机如何分离和隔离应用程序。 A z/OS 大型机使用名为逻辑分区 (LPAR) 的功能来隔离和管理单个实例上特定应用程序的资源。
例如，大型机可能会对具有关联 COBOL 程序的 CICS 区域使用一个 LPAR，对 DB2 使用另一个 LPAR。 其他 LDR 通常用于开发、测试和过渡环境。
在 Azure 上，更常见的做法是使用单独的 VM 来实现这一目的。 Azure 体系结构通常为应用层部署 VM、为数据层部署单独一组 VM、为开发部署另一组 VM 等。 可以使用适用于该环境的最适合的 VM 类型和功能来优化每个处理层。
此外，每一层还可以提供适当的灾难恢复服务。 例如，生产和数据库 VM 可能需要热或温恢复，而开发和测试 VM 支持冷恢复。
下图显示了使用主站点和辅助站点进行 Azure 部署的可能性。 在主站点中，生产、暂存和测试 VM 部署高可用性。 辅助站点用于备份和灾难恢复。
执行到 Azure 的分阶段迁移
将解决方案从大型机移动到 Azure 可能涉及 暂 存迁移。 首先移动一些应用程序，而另一些应用程序则暂时或永久保留在大型机上。 此方法通常需要让应用程序和数据库在大型机与 Azure 之间互操作的系统。
常见方案是将应用程序移至 Azure，同时将应用程序使用的数据保存在大型机上。 特定软件使 Azure 上的应用程序能够访问大型机中的数据。 幸运的是，广泛的解决方案提供 Azure 和现有大型机环境之间的集成、对混合场景的支持以及随时间推移的迁移。 Microsoft 合作伙伴、独立软件供应商和系统集成商可以在过程中为你提供帮助。
一个选项是 Microsoft Host Integration Server。 此解决方案提供 Azure 中应用程序所需的分布式关系数据库体系结构（DRDA）。 它允许应用程序访问保留在大型机上的 DB2 中的数据。 大型机到 Azure 集成的其他选项包括 IBM、Attunity、Codit 和其他供应商提供的解决方案以及开放源代码选项。
合作伙伴解决方案
如果你正在考虑大型机迁移，合作伙伴生态系统会有所帮助。
Azure 为当前在大型机上运行的系统提供了经过验证的、高度可用且可缩放的基础结构。 某些工作负载可以相对轻松地迁移。 可以重新托管依赖于旧系统软件的其他工作负荷，例如 CICS 和 IMS。 使用合作伙伴解决方案，并随着时间的推移将其迁移到 Azure。 无论做出何种选择，Microsoft 和我们的合作伙伴都可以帮助你优化 Azure，同时维护大型机系统软件功能。
了解详细信息
有关更多信息，请参见以下资源：