加快绿色 IT 发展，应用程序迁移和重托管的实用指南-2

look_w

服务器和应用程序资格进一步完善您的潜在迁移候选对象列表。
转换规划和可行性研究

• 定义服务器复杂性以评估迁移工作量在将一个服务器或一组服务器识别为迁移到虚拟化目标环境的潜在候选对象后，接下来的一个重要步骤就是对服务器进行分类，分为简单、中等、复杂或非常复杂，具体取决于服务器硬件和软件各种参数研究， 提供了一个选择条件示例：
  图 3. 基于服务器类型的迁移复杂性简单服务器在单一 OS 实例中仅托管一个应用程序或应用程序的某一块，比如，基于 Wintel 的单核或多核 CPU 服务器仅托管一个在 WebSphere 环境中运行的 Web 应用程序。
  中等服务器可以托管 2 到 3 个单独的应用程序，但不需要定义多个虚拟机 (VM)，仍然在一个 OS 实例下运行，比如，运行一个应用程序多个实例的服务器，诸如，在同一个 OS 下运行的 WebSphere Application Server (WAS)、DB2 和 IBM Http Server (IHS) 前端，通常可在开发和测试环境中可以看到。
  复杂服务器通常是指含有多个 CPU 的服务器，可能定义了独立逻辑分区 (LPAR)。每个 LPAR 都有其自己的 OS 副本或多个 VM，这些 VM 都有独立 OS 副本，并托管共享相同系统资源（比如，网络 I/O）的多个或不相关的应用程序。一个示例是有多个 LPAR 的 System p®，运行独立 AIX、p-Linux OS、或其他 OS 和 VMs，并运行多个共享同一网络 I/O 的应用程序。
  非常复杂服务器通常是指具有多个有独立 LPAR 的 CPU，每个 CPU 都有其自己的 OS 副本或多个有独立 OS 副本的 VM，并托管多个共享相同系统资源（比如，网络 I/O）的不相关应用程序，通过硬件或软件负载共享或故障转移与其他独立服务器聚合。例如，运行一个独立的 p-Linux 或 AIX 的 OS 并且托管 DB2 数据与 HACMP 集群的多个 LPAR。
  
• 定义应用程序复杂性以评估应用程序迁移的工作量仅从服务器复杂性定义可能并不能完全理解迁移工作，因为服务器可能较简单，但是产品、技术或运行的应用程序可能比较复杂。从应用程序的角度对复杂性进行分类对于理解迁移同样重要。 表示应用程序复杂性范围，从简单到非常复杂。
  图 4. 基于应用程序类型的迁移复杂性简单应用程序
  
  • 数据库，如果其中包括：
    • 较小的数据库
    • Intra-Data Center (DC) 迁移
    • 有单个实例实现的服务器
    • 有 2 个应用程序所有者的服务器
    • 没有本机语言代码来避免代码矫正的数据库
    • 有周末停用窗口可供使用的应用程序
  • WAS/Java 应用程序，如果其中包括：
    • 更小的 JVM 或单个 JVM 实现
    • WAS AS-IS 移动，例如 WAS 6.1.x 到 6.1.x，WAS 5.1 到 6.0.x，6.1 到 7.0.x（没有 API 变更）
    • 仅有 2 个应用程序所有者的应用程序服务器
    • 没有本机语言代码（例如，C/C++）来避免代码矫正的应用程序
  • IHS，如果它是：
    • 多数是静态页面，比如 HTML、图像、JavaScript 以及少量 CGI 脚本、Perl 模块、或直接调用数据库和硬编码 IP 依赖项
  • Domino® 如果它是：
    • .NSF 数据库中的一个独立应用程序，与外部数据源或脚本无交互。
  中等应用程序总是以个案为基础，根据卷、用户基础、架构、中间件产品，以及所有这些的综合在简单和复杂之间进行评估。例如，WebSphere Commerce (WCS) 无需任何自定义 JSP 或自定义模块从 WCS 6.x 迁移到 6.x，就是一个中等迁移，但是从自定义 JSP 或程序模块增加，以及版本从 5.5/5.6 升级到 6.x 那一刻开始，就趋向于复杂或非常复杂迁移，具体取决于评估分析工作。
  
  • 中等复杂迁移的其他示例包括：
    • 需要代码重写但却只需将一个 API 从 1.4.2 更改到 1.5（JRE 版本）的简单 J2EE 应用程序迁移
    • 类型 2 到类型 4 驱动程序的更改
    • 使用数据库或 Java 连接外部数据源 [包括 Lotus Enterprise Integrator® (LEI) 的使用] 的 Domino 应用程序
    • 使用适用于目标环境的工具开发的自定义应用程序（需要较少移植）
  复杂应用程序
  
  • 带分区数据库或大型的数据库（跨 DC 迁移）。指标可能包括：
    • 1TB 以上的存储设备附加到该服务器
    • 数据库需要支持 365x24x7 小型维护窗口
    • 目前实现灾难恢复 (Disaster Recovery, DR) 数据库
    • 数据仓储数据库需要高 CPU/IO 资源
    • 带多个实例的服务器，比如在框上有 3 个或以上的实例
  • WAS/Java 应用程序：WAS 版本 4.0 或 5.0 迁移到 6.0/6.1/7.0（由于架构更改），使用最小的定制实现 WCS 5.5/5.6 到 6.x 的迁移，无需定制使用 PDM 或 WCM 实现门户迁移。
  • IHS：静态内容和动态内容的混合，大型应用程序后端与复杂重写规则和复杂后端调用的依赖关系，CGI/Perl 脚本与目录或外部 Perl 模块的依赖关系，以不良编码标准编写的 CGI 代码（需要重写）
  • Domino®：第三方应用程序代码或扩展器，在门户网站中使用的 Domino 元素，使用低级别 Domino API 或 OS API，将一个中等复杂的 Domino 应用程序从 Windows® 移到 Linux（或 System z 上的 Linux）。       通常，如果一个应用程序目前正在实施 DR，可以认为迁移是复杂的，第三方应用程序代码，自定义代码有数以千计的模块需要移植，但是如果使用同一个开发环境，自定义代码需要变更开发环境（比如，Visual Age to GNU 工具套件）
    
  非常复杂
  • Databases：从 AIX 迁移到 zOS 的 DB2 数据库，这类迁移需要大量重写实现文件系统更改，DPF 数据量超过 1TB，跨数据库集成，比如，ORACLE 到 DB2, Informix 到 DB2，zLinux 上不支持 DB2 扩展器的迁移。
  • WebSphere：目前，运行在旧版 WebSphere（比如 WAS 3.5 或 4.0）上的应用程序，需要大量代码重写以便将应用程序代码部署在 WAS 7.0 中，WebSphere Process Server 中使用 WebSphere Integration Developer (WID) 的大量工作流定制。

通常，一个复杂应用程序有一个以某种语言开发的自定义程序，这在不同 OS 中不受支持，在独立语言中代码重写是必须的，应用程序需要使用多个自定义 API 程序，或者自定义应用程序需要使用特定于当前环境的 API 或库。
Wave 规划：在一个组中迁移 在  中，实际迁移复杂性级别由应用程序和服务器复杂性共同决定。
图 5. 协调服务器复杂性和应用程序复杂性服务器/应用程序迁移通常通过一个在服务器迁移规划中确定的 wave 方法进行。确定适合筛选阶段的服务器/应用程序之后，在 wave 中使用高级别预测时间表分配迁移。Wave 项目启动后，服务器和应用程序复杂性将依据迁移的总体复杂性导出一个迁移时间表，与硬件/服务器和应用程序二进制文件/数据相关。
本文不涉及其他 wave 规划流程，比如，应用程序排序，应用程序优先级、财年结算或企业冻结，因为这些只特定于各个项目。
形成一个 wave 后，wave 项目经理就为迁移项目准备了项目计划。项目经理将咨询客户团队，对系统测试和用户验收测试所需的工作量做出评估。从项目计划角度来看，各个阶段如下（如 表 2 所示）：

• 解决方案启动和规划：执行可行性研究并制定关键技术决策。确定目标环境。
• 执行和控制：创建一个详细计划来执行和控制每个合格应用程序的迁移。
• 投入使用并关闭：最后，将新环境投入使用，随即关闭项目。

表 2. Wave 规划阶段 解决方案启动 & 规划执行 & 控制上线 & 关闭

• 检查并确认材料。咨询资产主体。
• 确定环境、区域并显示障碍。
• 确定目标环境和操作平台。
• 未来或目标架构。

• 完成详细规划，执行和控制每个合格应用程序的技术迁移。
• 咨询并通知资产主体。