本文是这个系列的第三篇,将为大家介绍的是如何为新平台调整大型机应用程序,在前一篇文章中我们介绍了如何分解任务,尽量在迁移期间减少系统停机时间。 我们假设你已经完整地迁移了一系列大型机应用程序到新的平台上,并且在新的平台上运行情况良好。但不知你在新平台上的应用程序和在大型机上是否一模一样,用户的使用感受又如何?其实没有必要做到完全一样,因为Windows和Linux/Unix与z/OS的系统架构是完全不一样的,只需要借鉴和参考原始的大型机应用程序即可,但为了尽量减少对最终用户的影响,有必要在新平台上仔细调整一下应用程序,既要提供足够好的性能和可扩展性,以及良好的安全性,功能上又要与大型机版本……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
本文是这个系列的第三篇,将为大家介绍的是如何为新平台调整大型机应用程序,在前一篇文章中我们介绍了如何分解任务,尽量在迁移期间减少系统停机时间。
我们假设你已经完整地迁移了一系列大型机应用程序到新的平台上,并且在新的平台上运行情况良好。但不知你在新平台上的应用程序和在大型机上是否一模一样,用户的使用感受又如何?其实没有必要做到完全一样,因为Windows和Linux/Unix与z/OS的系统架构是完全不一样的,只需要借鉴和参考原始的大型机应用程序即可,但为了尽量减少对最终用户的影响,有必要在新平台上仔细调整一下应用程序,既要提供足够好的性能和可扩展性,以及良好的安全性,功能上又要与大型机版本大致相同。
为了调整迁移的大型机应用程序,你需要了解新的运行环境会对应用程序的运行有何影响,下面是Windows,Linux/Unix和z/OS之间的关键不同点,迁移后通常要进行这些方面的调整。
- Windows,Linux/Unix是客户端/服务器架构,z/OS是主/从架构;
- Windows,Linux/Unix和z/OS在安全架构上有很大的不同;
- Windows,Linux/Unix和z/OS在资源访问方法上有很大的不同,特别是I/O方面。
值得欣慰的是要弥补它们之间的这些差异从技术角度来讲并不困难,对目标平台调整的最佳实践是要预先知道这些问题,然后预留时间努力修复它们,那些想节省成本或想加快迁移速度的人可能想略过这一步,但往往最后会陷入迁移困境。
客户端/服务 vs. 主/从
z/OS操作系统(以及许多大型机应用程序)与外部世界的通信是“主/从”方式,当大型机需要输入信息时,只有哑终端可以用,因此传统的大型机应用程序一般都假设一次只有一个或几个应用程序实例在运行,它们的大部分时间都用于处理,而不是摄取最终用户的输入,它们的通信具有爆炸性,往往以大数据块提交和发送。
在Windows或Linux/Unix上,通常不会这么干,它们会以更频繁和更小的数据块进行通信,远程客户端可以向服务器发起输入,因此迁移后的应用程序可能会来不及响应最终用户请求,并且由于今天的网络架构越来越复杂,要准确找出网络中存在的瓶颈在哪可能比较困难。
安全调整
说这是一个安全问题有点危言耸听,相对于拒绝服务攻击和恶意软件这算不了什么,但迁移过程不得不面对Windows,Linux/Unix和z/OS之间关于安全访问控制方法的巨大差异,必须在不同的目标平台上进行适应性调整。
z/OS提供了一个成熟的专业的安全软件——资源访问控制程序——它可以对每个最终用户进行细粒度的安全控制,相反,Linux/Unix只提供了最原始的最简单的安全访问控制机制(只能为用户、用户所在组及管理员设置读、写和执行权限),基于这种简单的权限控制机制是不能实现细粒度访问控制的,Windows就更不用说了。
因此当你从z/OS迁移到Linux/Unix时,既要注意应用程序自身的功能要尽量保持与z/OS上的一致,又要保证在目标平台上的安全有充分的保障。虽说Linux/Unix和Windows的安全性不如z/OS那么完善,但目前这些平台也在这方面做出了很大改进,如SELinux就可以提供细粒度的访问控制了。此外,我们还必须分清风险小和无风险的概念,在进行功能测试和压力测试时,需要一并考虑这些因素,好的测试工具可以识别并告知你风险的存在。由于安全是个动态变化的东西,除了迁移过程中需要留心,在迁移完成后的日常维护和检查中,也应该注意。
I/O调整
多年来,大型机和Windows/Linux/Unix在处理系统资源(如处理器和存储)时有些越来越相似的趋势,但每个平台在处理I/O方面还是有些不同,z/OS提供了ISAM和VSAM,Linux/Unix提供了一个简单的不是很好扩展的面向文件的索引方案(与inode索引有关),Windows使用的方法与大型机类似,但只实现了其中的一部分。大型机I/O并不是由大型机编程语言来处理的,如果仅仅通过迁移工具简单的语言转换,到目标平台上有些特性也是无法得到支持的,这是平台之间结构的差异造成的。
要解决这个问题的最好办法是确保迁移工具转换生成的代码能够在Windows/Linux/Unix上有对应的I/O指令,否则,你需要逐个进行性能测试,然后找到有问题的I/O代码,并修复它们。
小结
提前了解目标平台的特性和差异对应用程序性能和安全的影响可以有效避免无知带来的痛苦,也可以避免给最终用户带来麻烦,这是标志着迁移成功的最后一步,如果应用程序在目标平台上运行得很好,性能和安全都与大型机不相上下,那就说明迁移是成功的,可以睡个安稳觉。
但是,很可能在不久的将来会有更大的挑战,因为未来很可能将这些应用全部迁移到内部云或外部云上,一般而言,大型机迁移并不能保证今后能顺利迁移到云中,应用程序还可能会从Windows迁移到Linux或者又迁移回大型机,未来的迁移还会涉及多个应用的整合和流程的重组,试想一下,如果你要整合刚刚收购的公司所使用的应用程序该如何下手?
在将来的迁移过程中,如果也有先见之明,能预先了解目标平台的特性和差异,能预知可能遇到的问题,那将会节省不少迁移时间。在本系列的第四篇文章中,我将会介绍一个相对简单的迁移方法,使得迁移的应用程序可以焕然一新,并能满足未来的需要。
翻译
相关推荐
-
何时采用直接入云模式?
尽管最终的目标是相同的,但将应用迁移到云中可以使用很多方法,包括重构以及直接迁移方式。
-
为你的云迁移战略找到最佳方式
将应用迁移到公有云时,大多数IT组织选择直接迁移方式或者对应用进行重构。尽管这两种方式都有各自优势,但在制订云迁移战略时,组织应该仔细选择。
-
AaaS云服务助力应用从x86迁移到ARM
如果你希望借力ARM服务器的发展,对原本基于x86处理器或其他芯片架构的应用程序进行移植,想法是对的!但这中间存在不少问题。
-
实例分析:印度某公司的数据中心整合计划
印度公司Escorts的IT团队决定整合数据中心和虚拟化,把四个数据中心整合在一个集中化的企业区域。他们的项目结果如何呢?