五步搞定从 Unisys 大型机迁移到 AWS

本文要点

• 运行大型机应用工作负荷时，可以选择 AWS 这样的云服务提供商，这是得到验证的。
• 要充分发挥 Unisys 大型机应用和数据的价值，最有效方法是革命性地迁移到 AWS 的现代化框架中，并尽可能地重用应用的原始代码。
• 要迁移大型机上的应用，需完成一个发现、设计、现代化、测试和实现的循环过程。
• 一些大型机迁移工具可让已有代码继续发挥作用，只是需要替换其中的一些组件，并对数据存储做重新考虑。

大型机之困境

当你面对一台 Unisys 大型机时，你也许会认为它无法使用云计算。虽然你希望能发挥云计算可提供的所有优点，但是你并不认为这是可行的。在你看来，可能是因为云计算并不能处理你的交易工作负荷，或许是因为架构间的差异大到无法进行转换，甚至仅是认为这是非常难以实现的。我过去也是这样认为的，直到最近才转变了自己的看法。鉴于已有 AWS 这样的云服务器提供商提供服务，云计算已经快速步入成熟，并且已证明可运行大型机应用的工作负荷。在 AWS 和大型机专家的帮助下，我编写了一份“迁移Unisys 工作负荷到AWS 的参考架构”。在阐述是什么改变了我的想法之前，我将简要介绍一下Unisys 大型机的历史及云计算的演进情况。

Unisys 大型机

Unisys 的根源可追溯到 1886 年。American Arithmometer 公司（此后更名成 Burroughs Corporation，并发展成今天的 Unisys 公司）最初创立于 1910 年，当时称为 Sperry Gyroscope 公司。人们将开发了首个通用计算机这一荣誉授予了 Unisys 及其前期企业，当时的计算机称为 BINAC 和 UNIVAC。这在十九世纪四十年代末期和五十年代早期是一个引人注目的成就，计算机的出现永久地改变了世界。

在 Burroughs 和 Sperry 合并创立 Unisys 公司时，两个企业分别具有各自的大型机生产线，并且每条生产线具有各自的忠实客户基础。曾有人试图统一这两个架构及各自的技术，但是这两个完全不同的新系统在当时依然存活下来。Unisys ClearPath Libra 大型机源自于 Burroughs 生产线，而 ClearPath Dorado 源自于 Sperry 的生产线。虽然这两个大型机系统在技术上存在着明显的差异，但是它们在很多方面上是非常相似的，并且具有大量相同的基础特性。

在当时没有人认识到，计算架构的进步和小型化将会导致今天计算机无处不在这一事实。计算机存在于人们视线所及的任何地方，汽车、智能手机、平板电脑，甚至是冰箱、微波炉即烤箱等厨房设备。人人拥有的智能手机使得早期的大型机看上去就像是孩子的玩具，它们的计算能力和速度远超过了它们的祖先，生产成本只是后者的九牛一毛。计算机在如此短的时间内就取得了令人难以置信的进步。

进入云计算时代

快进到 1996 年，彼时我们开始听说一个称为“云计算”的革命性新数据处理形式。我们中的不少人，包括我自己在内，对此在一定程度上持有怀疑态度。尽管我们认为云计算是一个有意义的理念，但是我们认为它只不过是另一个昙花一现的趋势，因此采取了等等看的态度。我们中的不少人认为这一理念正如其它所谓的“革命”那样，一旦下一个计算趋势闪亮登场就会最终落败。当然，我们这些使用大型机的人认定了云计算对大型机计算的影响甚微。

但是到了 2000 年中期，很明显云计算的羽翼丰满了。它并未象很多之前的其它 IT 趋势一样不了了之。虽然当时云计算依然尚不成熟，但是它已无疑地被证明是一种可靠的、成本效益好的计算方式，这至少对部分人是具有优点的。Salesforce.com 等一些企业开始以服务的形式提供 CRM 等商业功能。要实现对客户数据及交互的追踪，或是营销活动的管理和自动化，用户不再需要去投资硬件和软件。他们只需支付合理的费用，就可以通过标准的互联网浏览器设置账户去实现完成所有这些功能。用户不再需要购买和管理服务器，不再需要跟踪软件的许可，也不再需要规划并管理升级。云计算是真实存在的，它切实地提供了一些优点。

当云计算遇上大型机

在 2006 年，Amazon 推出了 Amazon Web Services（AWS）的架构即服务（IaaS）解决方案 Elastic Compute Cloud（EC2）。随后，Microsoft 于 2008 年推出了 Microsoft Azure 平台即服务（PaaS）产品。看上去，这巩固了云计算的地位，使得云计算不仅是 CRM 这样特定商业需求的解决方案，它可以被用于运行几乎任何类型的 Windows、Linux 或 Unix 应用。你可以采用“按使用付费”的模型，将现有的应用工作负荷和开发活动迁移到 AWS 或 Azure 云环境。你不再需要维护昂贵的数据中心或主机代管设施，不再需要做昂贵的应用升级以适合你扩展业务，甚至可以通过云复制满足你的备份和灾难恢复需求，无需昂贵的远程镜像设备！这是多么好呀！

即便如此，那些使用大型机的人依然认为，这个大铁块所能实现的需求是无法被云计算满足的。我指的是，即便是大量交易需求本身，就足以成为一件企业需求不可能成功实现的事情，更不用说让敏感数据驻留在云中“某处”所带来的隐含安全需求问题。我承认我也持有同样的观点，这种负罪感一直持续到 2010 年的最后一个晚上。

豁然开朗

我曾在 Amazon 上做过网购，我惊讶于仅需要一台笔记本和一个安全的 Wi-Fi 连接，就可以舒适地坐在沙发上随时购买如此琳琅满目的商品，全球范围内的上百万人都是这样做的。这触动了我。我此前从未在 Amazon 上购买过任何东西，虽然它一直在提供着服务。Amazon 已可靠、快速和安全地完成了上百万笔的交易，这是全天候的服务。完全不需要大型机。

这件事启发了我，使我顿悟到，云已经准备好去完成大型机的工作负荷。我感觉自己像个傻瓜，很明显云一直存在于我的眼前。近十年中的大部分时间中，我一直致力于迁移大型机应用到开放系统，那么迁移到 AWS 又会如何？这是一个大型的、分布的开发系统环境。事实上，比起很多企业，这些企业压榨已有的网络和应用中的最后一点能力，为的是避免一些不可回避的费用、复杂性和升级风险。云也许会更为稳定和安全。迁移 Unisys 大型机到开发系统是已被验证的、可降低费用和风险的解决方案，并对移动设备等现代技术开放了有价值的业务功能和数据。现在大型机市场应将云看做是一种唯一可行的替代解决方案。

AWS 已准备好运行大型机工作负荷

到 2015 年，我看到 Unisys 大型机提供商开始转变态度。他们已经看到了大量云计算的成功案例和优点，了解到数据安全是可以管理，并且存在大量的交易吞吐量。我们开始收到越来越多的来自 Unisys 提供商的咨询，他们想要逐渐开始试水云计算。虽然他们可能现在尚未准备好，但是他们已经认识到云计算是必须应了解的，云计算的优点是如此的令人信服，以至于不能被忽视。

同时，Unisys 开发了兼容 x86 的支撑基础，允许大型机用户在标准的开放系统硬件上运行已有的 ClearPath Libra（Burroughs）和 Dorado（Sperry）工作负荷。虽然这一做法有可能更进一步移植到 AWS，但是应用依然运行在陈旧且私有的操作系统和数据库平台，熟练编程资源的规模正在快速地萎缩。此外，该方法并没有完全地利用上 AWS 平台。尽管其它应用可以通过复制或实时转换访问 DMS、DMSII 或 RDMS 数据，但是这种做法将会增添一层复杂度，增加了实现上的和单点故障的风险。对于集成其它应用到遗留业务功能并以无状态服务方式进行处理，这些问题同样存在。

最有效利用 Unisys 大型机应用和数据价值的方法，就是向 AWS 的现代系统框架转型迁移，尽可能多地重用原始应用的源代码。相比于重写或是软件包替换而言，这类方法的更改最小，降低了项目的代价和风险，并获得了与新技术集成的优点，开拓了所有那些利用了 20 到 30 年投资的新市场。最重要的一点是，一旦迁移完成，应用将在维持其现代化版本的同时，对已有用户提供大体上类似于前代版本的应用版本，用户多年的宝贵经验也可以重用，并传递给新的开发人员。但是问题在于，大多数 Unisys 应用提供商长期以来一直都聚焦于大型机，并不知道应该从何处着手，或是如何开始。我们当然不能因噎废食。下面，本文将给出一些指导意见。

迁移 Unisys 应用到 AWS 的五个步骤

前文提到，我投身于迁移大型机应用到开放系统这一工作已有一段时间了。这是得到验证的解决方案、技术和方法，并在过去的数十年间得到了很好的优化。扩展该方法到基于开放系统技术的 AWS 并非难事。这只是添加了一些新成分的同一方法，如下图所示。

(点击放大图像)

1. 发现。你要做的第一件事情，就是对你环境中的所有应用、语言、数据库、网络、平台和过程做编目并分析，对应用和所有外部集成点的相互关系建立文档。尽可能地使用自动分析，并将所有事情导入到中央代码库中。就我的项目而言，我使用全部这些数据去构建自动化转换引擎中的迁移规则。这些规则将在整个项目过程中得到更新和优化。
2. 设计。分析全部的源代码、数据结构、最终的状态需求和 AWS 云组件，设计并架构解决方案。设计应该考虑到一些细节问题，例如 AWS 组件的类型和实例、事务负载、批处理需求、编程语言转化和替换，并对未来的需求做出规划。你应选择一些大型机迁移工具，最好选择那些需要你去做最小量更改的工具，因为这样的工具会大大降低项目的代价和风险。你需要设计客户开发的解决方案，以适合那些未被仿真工具满足的需求。COBOL 几乎总是要被迁移的，但是诸如 Algol、MASM、AB Suite（也称为 LINC）、BIS（也称为 MAPPER）此类将需要加以替换。一些功能可能会被目标操作系统或是其他的目标平台组件替换，因此应该做一些分析，以发现其间的差距。此处正是你需要定义自己的数据迁移策略之处，可能最好是将这些数据转换为关系数据。层次化数据应使用转换工具或是 ETL 程序转换为关系数据。
3. 现代化。该过程将对源代码做大量更改，这是一个迭代且自动化的过程。如果被更改的代码得以顺利编译，那么就可以进入单元测试了。如果无法编译，就需要开发人员审查其中错误，找到修正之处，更新迁移规则，并再次运行程序。在很多情况下，错误修正也可以应用于修正其它程序中的同一错误，规模经济在这里发挥了作用。一旦经历了现代化过程，程序将变得更为快速和准确。对于开发人员编写源代码去替换那些无法迁移到 AWS 的遗留组件，以及数据专家构建并验证新的数据库，这也同样适用。静态数据一旦得以验证，就可以和代码迁移和开发一起并行地迁移到目标数据库和文件系统。对于那些频繁发生变化的动态数据，将会在切换到生产系统期间进行迁移。
4. 测试。好的一面是，你只需要关注那些发生了更改的代码。我在前文中已经讨论了此话题，指出我们并不需要对每一行代码进行测试，因为其中的绝大部分并未发生更改。测试应侧重于数据方法、那些可能受到使用 ASCII/EBCDIC 影响的排序例程、为适应数据类型改变而更改的代码、新开发的代码等。不好的一面是，大多数遗留应用很少具有测试脚本，也缺乏完备的文档。不需要做大量的测试并不意味着测试很容易实现。你可能将需要在测试脚本上花费一些时间和资源。但这是个实实在在的投资，因为这些脚本可重用于测试那些要迁移到 AWS 的应用。你还需要执行负载测试和压力测试，以确保你的应用已为处理大量数据准备好了。
5. 实现。一旦需要迁移的应用得到了测试、验证并优化，就可以启动对这些应用的部署过程。现实中很多部署活动在前期过程是并发启动的，包括创建并配置 AWS 组件实例、安装并配置大型机仿真软件、迁移静态数据，以及其它的架构或框架上的活动。在某些情况下，实现这些过程需要复制环境，或者更改已有环境的用途。这取决于应用和数据的特性，以及任何可能具有的企业标准或喜好。在迁移和验证动态数据后，就可以结束向生产环境模式的切换了。

参考架构

一种表述方式是使用文字描述实现过程。但如果让我来表述，那么对状态前后做可视化展示可使事情更加清晰。下图展示了一个 Unisys ClearPath Libra 系统是如何映射到 AWS 的：

(点击放大图像)

类似地，下图展示了一个Unisys ClearPath Dorado 系统是如何映射到AWS 的：

(点击放大图像)

仔细观察

鉴于每个系统都是独特的，并且每个提供商都具有自身独特的需求和标准，上图应该被视为是一种通用指南。为让读者能仔细观察AWS 组件，并了解Unisys 大型机组件是如何映射到这些组件上的，下面我们将从更高层面对这一过程加以描述。谨记，我并非是要去挖掘一些细枝末节，而是要给出一种高层次上的介绍。其中存在太多可能的配置，这不是一篇文章能全面覆盖的。

云环境

Amazon Virtual Private Cloud（VPC）可从配置上逻辑隔离部分 AWS，用于在自己定义的虚拟网络中启动和管理 AWS 资源。这一部分 AWS 是你在 AWS 中的一个私有区域。你可以将其想象为对 AWS 中所有系统的一道屏障。其中，你对自己的虚拟网络环境具有完全的控制，包括自己的 IP 地址范围部分、子网的创建，以及路由表和网关的配置。你可以在自己的 VPC 中使用 IPv5 和 IPv6，实现安全并轻易地访问资源和应用。

计算资源

Elastic Compute Cloud（EC2）提供了 AWS 中的安全、可伸缩的计算能力，并以应用基础的形式提供。它是一种容器，支持操作系统、大型机模拟器、应用可执行程序和其它组成应用的支撑软件。你可以分离部分支撑软件为独立的 EC2 实例，或者在同一个实例中运行所有软件，这取决于你自身的特定需求。你可以具有一个专用于 COBLO 的 EC2，而另一个 EC2 专用于在线应用。你也可以按应用而分离 EC2。这同样取决于你的特定环境。

存储

Elastic Block Storage（EBS）可被看成是一个用于存储数据的硬盘驱动器，针对的是大规模的数据。EBS 是运行迁移后应用的 EC2 实例的首选存储“设备”。另一种存储服务是 Simple Storage Service（S3）。EC2 实例通过 API 连接 S3，访问并存储对象数据。S3 可作为分析的大批量数据的仓储或是“数据湖”。AWS 还提供了 Amazon Glacier（并未显示在上图中），它是一种低代价且可靠的服务，可用于备份和归档任何类型的数据。这些服务以及其它一些没有提及的服务组合在一起，可满足任何大型机应用的存储需求。AWS 存储服务是灵活可靠的。S3 服务设计用于交付 99.999999999% 的持久性，并扩展到全球范围内的数十亿对象，因此你大可放心，你的数据是安全的，并且可以扩展到未来或许需要的任何层次。

数据库

Amazon 的 Relational Database Service（RDS）提供了所有关系数据的存放之处，其中还包括任何被转化为关系数据的纯文本文件。所有的 DMS 和 DMSII 数据将被转化为关系数据，并迁移到 RDS。RDMS 数据也将被迁移到此处。该容器针对数据库性能做了优化，更具成本效益，并且容量规模可变，它在设计上就是用于降低耗时的数据库管理任务。RDS 提供了多种常用的数据库引擎，包括 Microsoft SQL Server、Oracle、PostgreSQL、MySQL 和 MariaDB。你也可以考虑将你的关系数据迁移到 Amazon Aurora。这是一种兼容 MySQL 的数据库，并针对 AWS 做了优化，在执行上可比 MySQL 快五倍。对已有的遗留数据库和应用的分析，将会给出迁移你的数据到 Aurora 或是其它 AWS 中的 RDBMS 时所需的所有更改。

负载均衡

具有大量交易的应用需要一种能平衡负载的机制。Amazon 的 Elastic Load Balancing（ELB）正是实现此功能的。它将流入的应用流自动分布到多个 EC2 实例上，以达成迁移应用中的容错。它提供了将流量平均地路由到应用的负载均衡能力，并保持应用的高效执行。

安全

在 AWS 环境中，你可以采用 LDAP（Lightweight Directory Access Protocol）访问和维护分布式目录信息服务。虽然还有其它实现技术可选，但它是映射遗留应用中用户 ID、密码、权限等的最可能方式。将 LDAP 服务宿主在一个小型独立 EC2 实例上，通常会简化独立维护应用。但是这需要对你的遗留安全环境做全面的检查，以确定如何最好地在迁移后系统中架构并配置安全。AWS 的 Identity and Access Management（IAM）使你可以创建并管理 AWS 用户和组，并使用权限去允许和禁止它们对 AWS 资源的访问。这是针对 AWS 架构的安全，而非应用层面的安全。

监控

每个 IT 系统都需要加以监控。CloudWatch 是一种监控服务，用于运行部署在 AWS 遗留应用中的 AWS 云资源。使用该工具可以收集并追踪度量、监控日志文件、设置报警并自动地对 AWS 资源中的更改做出响应。这些数据将用于快速地解决问题，并保持你的迁移应用运行平稳，正如你当前在大型机上所做的一样。还有其它一些由第三方提供的云监控工具。

源代码控制

正如在大型机上有控制当前的应用源代码并管理应用版本的产品和过程，在 AWS 中你也需要具有类似的工具集。AWS CodeCommit 是一种完全受控的源代码控制服务，提供了安全和私有的 Git 代码库。它无需操作自己源代码控制系统，或是担心是否有扩展架构的需要。CodeCommit 存储迁移后应用源代码和二进制文件、新的源代码和二进制文件以及其它任何想要归档的文件。

这并非高深莫测的科学，而是挑战

将 Unisys 大型机应用迁移到 AWS 看上去像是一个不可能完成的艰巨任务。它的确是一个挑战，但是一旦加以细致地规划、管理和执行，你将会受益匪浅。你不仅可以节省一些按使用付费模型的费用，而且当你的大型机应用已完全部署在 AWS 上，你将可自由地使用上所有最新的技术（例如移动技术、增强现实技术等）去集成那些经验证的业务逻辑，并扩展你的想法到新的市场、客户和合作者。

市场和技术并不会止步不前，它们时常会得到改进。使用由 AWS 等云服务商所提供的技术和服务，智能商业可以以令人惊讶的速度去适应市场的需求，超越竞争对手。考虑到这一点，将大型机应用程序迁移到云端更像是一件必须要做的事情，而非是一件奢侈品。

如果你想深入了解此话题，对此我曾做过一些深入的研究，内容提供于《Unisys 迁移到AWS 的参考架构》报告中。

本文作者简介

Craig Marble是 Astadia 的高级总监，负责遗留系统的现代化项目。Craig 已在信息技术产业界具有 25 年工作经验，主要关注遗留系统的现代化项目。 Astadia 是一家为扩展业务到云环境提供顾问服务的金牌云技术公司。要了解更多信息， 可访问并关注 Astadia 在 LinkedIn/Astadia 、 Facebook/AstadiaInc 和 @AstadiaInc 的主页。

查看英文原文： 5 Steps to Migrate Unisys Mainframes to AWS