从AIX移植到Solaris案例分析

介绍

这份文档记录了一个真实系统项目移植的过程，包括项目的前期分析和具体项目中遇到的技术问题。希望通过这份文档分享移植到Solaris的经验。

 

项目背景

该项目移植的系统是某机构的关键核心数据中转系统。该系统是一个运行在IBM AIX 5L上的一个C/S架构的应用系统，主要使用C语言实现。系统比较庞大，C源程序代码近30多万行。其应用架构使用了BEA的Tuxedo中间件，所有程序服务部署为Tuxedo Server。其后台数据库使用IBM DB2。该系统作为核心系统，用户对它的健壮性，可靠性非常高，现在用户决定将整体平台移植到Solaris上，希望能够通过异构的系统来达到更好的可靠性。整个项目的开发和系统集成测试委托独立软件开发商(ISV)。Sun公司作为原厂商对这个项目提供相应的技术支持。

 

移植流程

整个移植项目的步骤分为：项目技术分析，项目规划，系统移植，系统测试，系统调优，性能测试和调优。整个过程如下图所示：

 

首先我们对项目进行技术分析，判断项目理论上的可行性。这是非常重要的一个步骤，因为从一个平台上迁移到另一个平台还是存在一定的风险。为了尽可能的保护后期的投入，必须根据用户的需求，从技术上分析项目的可行方案。如果技术分析通过，则需要现代项目管理方式，制定出一份项目计划，从中确定项目需求，实施计划和所需资源。接着是系统移植，得到一份可以运行的系统。然后是安排系统测试，包括系统完整性测试 (System Integration Test – SIT)和用户测试 (User Acceptance Test – UAT)，确保移植后的系统能够正确工作。最后就是针对系统性能的测试和调优，让系统达到可交付的性能。

 

项目技术分析

在这个阶段中主要是对各种技术难点，比如第三方软件的依赖程度，对操作系统的依赖程度进行判断及预测。并且通过这种技术分析，确定在移植目标系统上系统整体方案。主要考虑的是以下技术点：32位还是64位，CPU类型选择，Endian，第三方依赖库，操作系统的选择，编译器的选择还有代码分析。

32位/64位

该系统在AIX上是64 (LP64数据模型)位运算，对Solaris和Sun公司64位服务器来说亦不是问题。

CPU

根据原先用户的机型，我们选择基于UltraSPARC IV+机器。UltraSPARC IV+是Sun面向数值计算的一款64位双核CPU，在保持原有的功耗和价格，它的性能却是UltraSPARC IV的2.5倍。

而且UltraSPARC IV+做为RISC芯片和IBM的Power芯片一样，都兼容Big Endian。这点方便了我们移植工作。

Endian

Endian是指CPU处理数据的字节序，其中有Big Endian和Little Endian两种不同的处理方式。系统移植的时候，如果数据处理字节序不一样的话，就要注意源代码是否依赖某一种数据处理方式。如前所述，由于我们采用了UltraSPARC IV+，和原来系统一样都是Big Endian。

 

* IBM Power 4是可以接受Big Endian和Little Endian模式，但是上层的操作系统AIX 5L只支持Big Endian。

 

第三方依赖库

在技术分析中最为重要的就是根据系统所依赖的第三方软件在Solaris上是否有相应的版本和认证。经过查证，该系统除了前面所说的IBM DB2和BEA Tuxedo，没有依赖其它第三方库，所有其它功能比如日志，外界通信等都是直接自己实现。原先期望是采用Solaris最新版本Solaris 10，后来发现BEA Tuxedo虽没有问题，但是系统所使用的IBM DB2版本是8.1，其正式支持的Solaris版本最高是Solaris 9。由于这个原因，确定移植目标系统使用Solaris 9。

操作系统

如前所述，最后选择Solaris 9 SPARC版本。Solaris 9是Sun公司2002年发布的操作系统的版本，它支持众多UNIX系统标准：IEEE Std 1003.1 (POSIX.1)，IEEE Std 1003.2 (POSIX.2)，Single UNIX Specification, Version 3等。这些对标准的支持也是用户选择Solaris的一个重要的原因。

编译器

编译器的选择也是非常重要的一个环节。在Solaris 9 SPARC版本上可以选择的C编译器有GCC和Sun Studio。GCC作为GNU的开发工具，适用的平台范围广，非常适合跨平台应用程序的开发。Sun Studio作为Sun出品的开发工具，毋庸置疑，能够编译出发挥UltraSPARC机器最佳性能的可执行码。同时我们不仅要考虑目标移植系统的可选编译器，还要考虑原系统平台使用的编译器。

 

原先在AIX平台上使用的是IBM Visual Age开发工具，并且软件开发商曾为了确保代码的可移植性，使用GCC编译过一个分支版本。现在看来，这个尝试是非常明智的，减少了移植的风险。

 

但是对于C和C++程序来说，绝对不能忽略某些第三方开发库对于编译器都有要求。尤其一些商业的开发库，不仅会对不同的操作系统每个版本进行认证，而且只针对指定编译器提供官方支持。比如使用BEA Tuxedo和IBM DB2在Solaris上支持的编译器都是Forte Developer (Sun Studio先前版本) 和Sun Studio。根据查找BEA Tuxedo和IBM DB2支持的文档，两者所支持Sun Studio编译器版本列表的交集是Forte Developer 6.2。Forte Developer 6.2是Sun公司2001年推出的一套开发工具，现在除了一个HPC特别版，Forte Developer 6.2已经停止销售了。

 

不过目前Sun公司最新的开发工具Sun Studio版本是11，它符合ISO C99和C98规范，不仅提供更好的优化和多核CPU(UltraSPARC IV+, UltraSPARC T1, AMD Opteron等)的支持，而且也提供对旧版本的兼容。Sun为了保护用户，软件开放商的投入，承诺高版本的Sun Studio可以使用低版本的Sun Studio或者Forte Developer编译出来的链接库或者对象文件。也就是说，Forte Developer 6.2可以使用的开发库，Sun Studio 11也可以使用。所以最后我们确定选择使用Sun Studio 11。

 

代码分析

通过代码分析，判断代码可能存在的兼容性问题会对后面的具体移植，系统编译帮助非常大。目前系统代码主要是shell脚本，DB2脚本和C源程序。

 

Shell脚本移植性主要是依赖具体的Shell解释器和解释器的版本。这次系统中Shell 脚本使用的是Bourne Shell。正好可以使用Scriptran来检查，结果工具没有发现问题，在后续的移植中也得到验证。

 

* Sun公司提供一个Scriptran工具，它是针对Bourne Shell脚本的检查工具，能够检查脚本中哪些命令，参数或者系统依赖路径Solaris不支持。

 

因为使用同一个版本的DB2和指定支持的系统，所以判断DB2脚本兼容性应该能够得到保证。

 

C源程序是否能够兼容目标系统Solaris和Sun Studio是一个潜在风险。因为C/C++程序的跨平台性最主要的障碍是编译器和操作系统还有某些功能实现技术差异。即使存在相应的编译器标准，UNIX标准，但是很难保证系统没有使用编译器或者AIX特别的扩展功能。

虽然用户曾经使用GCC编译过某个分支版本，这只能说明该系统C代码的跨平台性不错，没有使用编译器特有的属性或扩展。

 

针对这个问题，我们可以通过AIX-Solaris Migration Kit工具做一个代码分析。

 

* Sun公司针对系统移植提供一个代码分析工具AIX-Solaris Migration Kit，它能够自动解析C/C++, COBOL代码，检查出代码移植中已知可预见的问题：比如操作系统的扩展，某些函数的不兼容。该工具分析后会以HTML报告的形式列出所有未知的函数及有问题的代码，并给出解决办法和相应的时间预测。目前该工具未正式发布，我们使的是Beta版本。

 

下面是这次移植中，AIX-Solaris Migration Kit