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

Amazon 架构

摘要： 当你面对一台Unisys大型机时，你或许会认为它是无法使用云计算的。但是AWS等服务提供商所提供的服务已使云计算快速步入成熟。现在云计算已经成为运行大型机应用工作负荷的可选方案。

作者： Craig Marble

审校： Richard Seroter

正文：

本文要点

• 运行大型机应用工作负荷时，可以选择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