很多大型应用程序开发和维护帐户，当考虑到要将核心应用程序和数据库迁移到一个新环境时，您会不知所措，不知道从哪里开始，如何规划和实现迁移，以及如何避开过程中的陷阱。缺乏对标准方法论或指导方针的认识，增加了将应用程序从一个平台快速和高效地迁移到另一个平台的评估困难。
本文探讨高度成功的 IBM Project Big Green，其目标是将大约 3900 个 IBM 内部服务器合并到约 300 个 System z Linux 环境中。本文旨在介绍所采用的整体方法，分享最佳实践和工具，提供指向服务器整合和虚拟化空间的初始指针。
尽管，本文重点关注从一个 UNIX平台到另一个 UNIX平台的同类迁移，但同样可用于其他迁移场景。本文是针对迁移工程师、迁移架构师和技术团队领导，同时也可以作为参考用于任何技术水平的任何迁移案例。
迁移过程概述
首先，我们了解一下术语工作负载：工作负载是在虚拟化或非虚拟化环境中运行在操作系统 (Operating System, OS) 上的一个应用程序或一组应用程序。一个工作负载包含一个运行在硬件上的OS，运行在 OS 层上的中间件，以及运行在中间件系统上的一组或类似组应用程序。数据库工作负载示例可以是：
- DB2或 Oracle 工作负载
- Web 应用程序工作负载，比如 Java™ 应用程序、WebSphere应用程序、Weblogic 应用程序，等等
- 前端工作负载，比如静态图像或页面
- 中间层应用程序工作负载，比如 WebSphere MQ、Message Broker、Web 服务，等等
将各种 UNIX 工作负载，比如 AIX、Solaris 或 x/Linux，迁移到 z/Linux（或其他平台）可能没有什么技术上的挑战。请记住，这类项目可能因为缺乏评估和合理规划而变得复杂。一个有条不紊的规划以及一个适当的阶段性方法将会巩固该转换过程。图 1 是一个典型迁移周期的整体阶段：
图 1. 迁移概览
任何迁移过程可大致分为：
- 发现阶段，涉及服务器库存和应用程序依赖性的发现
- 映射阶段，涉及创建迁移请求和目标拓扑
- 部署、迁移和配置阶段，涉及构建目标环境、应用程序部署和移植
- 测试阶段，迁移完成后在新环境中测试应用程序，然后投入使用
下述 图 2 提供显示特定子目录的迁移流。典型的迁移操作通常是以识别和盘点库存 开始的，这一过程扫描作用范围内的服务器并识别潜在迁移候选对象。潜在候选对象列表在以下服务器/应用程序资格 步骤中进一步细化。经过详细的可行性研究，选择最终迁移候选对象，然后进行逻辑分组以形成 waves。接着合格的服务器/应用程序的最终列表可带进称之为规划和设计 的下一阶段，在这一阶段制定详细的目标拓扑和迁移计划。详细设计定稿后，现在可以进入称为服务器/应用程序迁移 的实现阶段，这一阶段需要构建目标环境、迁移要迁移的应用程序，并对其进行彻底测试。完成迁移后，新服务器投入使用，退役旧服务器之后紧接着进入最终的后期生产 阶段。
图 2. 详细迁移阶段
现在，我们将深入研究每个阶段和活动以理解所涉及的步骤。#p#
识别和盘点库存
第一步是识别哪个服务器需要迁移。您还要清点每个服务器上的服务器和软件。
服务器识别
在迁移过程中，识别正确的资产集，比如要迁移的服务器，是非常重要的。按照项目架构师和转换项目办公室双方商定的工作负载管理规定，定义服务器作用范围或超出作用范围。在库存验证过程中，首要任务是盘点现有工作负载（是否基于 Intel 的、是否是大型机或其他平台）。IBM Tivoli® Application Dependency Discovery Manager (TADDM) 是一个非常有用的产品，有助于了解服务器、应用程序、网络设备、软件、配置文件、操作系统和其他 IT 基础架构组件之间的依赖关系。
您可以使用 表 1 中的样例工作负载分布模型，初始化目标环境的选择标准。源服务器的实际利用率（在 CPU、RAM、Network I/O 方面）以及作为被选中候选对象的比例隐藏在这一表述中。然而，该模型可以与给定的合适利用率指标同时使用，来决定一个服务器是否是一个迁移候选对象，或是否超出范围。
表 1. 样例工作负载分布模型
服务器和应用程序资格
进一步完善您的潜在迁移候选对象列表。
转换规划和可行性研究
- 定义服务器复杂性以评估迁移工作量
在将一个服务器或一组服务器识别为迁移到虚拟化目标环境的潜在候选对象后，接下来的一个重要步骤就是对服务器进行分类，分为简单、中等、复杂或非常复杂，具体取决于服务器硬件和软件各种参数研究，图 3 提供了一个选择条件示例：
图 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 表示应用程序复杂性范围，从简单到非常复杂。
图 4. 基于应用程序类型的迁移复杂性
简单应用程序
- 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) 的大量工作流定制。
- WAS/Java 应用程序，如果其中包括：
- 数据库，如果其中包括：
- 较小的数据库
- Intra-Data Center (DC) 迁移
- 有单个实例实现的服务器
- 有 2 个应用程序所有者的服务器
- 没有本机语言代码来避免代码矫正的数据库
- 有周末停用窗口可供使用的应用程序
通常，一个复杂应用程序有一个以某种语言开发的自定义程序，这在不同 OS 中不受支持，在独立语言中代码重写是必须的，应用程序需要使用多个自定义 API 程序，或者自定义应用程序需要使用特定于当前环境的 API 或库。#p#
Wave 规划：在一个组中迁移
在 图 5 中，实际迁移复杂性级别由应用程序和服务器复杂性共同决定。
图 5. 协调服务器复杂性和应用程序复杂性
服务器/应用程序迁移通常通过一个在服务器迁移规划中确定的 wave 方法进行。确定适合筛选阶段的服务器/应用程序之后，在 wave 中使用高级别预测时间表分配迁移。Wave 项目启动后，服务器和应用程序复杂性将依据迁移的总体复杂性导出一个迁移时间表，与硬件/服务器和应用程序二进制文件/数据相关。
本文不涉及其他 wave 规划流程，比如，应用程序排序，应用程序优先级、财年结算或企业冻结，因为这些只特定于各个项目。
形成一个 wave 后，wave 项目经理就为迁移项目准备了项目计划。项目经理将咨询客户团队，对系统测试和用户验收测试所需的工作量做出评估。从项目计划角度来看，各个阶段如下（如 表 2 所示）：
- 解决方案启动和规划：执行可行性研究并制定关键技术决策。确定目标环境。
- 执行和控制：创建一个详细计划来执行和控制每个合格应用程序的迁移。
- 投入使用并关闭：最后，将新环境投入使用，随即关闭项目。
表 2. Wave 规划阶段
#p#
规划和设计
作为规划和设计阶段的一部分，您和客户应该总结此服务器和应用程序行为以实现迁移。根据评估，设计一个技术解决方案。
应用程序评估
客户的应用程序评估通过问卷调查，紧接一个关键利益涉众和应用程序团队技术机组成员会议的形式进行的。准备一个应用程序资产问卷调查 (Application Assessment Questionnaire, AAQ) 工作产品以获取即将迁移的作用服务器/应用程序的服务器行为和应用程序行为。
AAQ 中用于用户数据捕获的关键属性有：
服务器行为：
- 服务器名 (FQDN)
- 集群 (yes/no)
- 集群服务器名
- 环境运行（生产/分阶/测试/开发）
- 服务器位置（城市/数据中心/主机环境）
- 服务器类型（Web/应用程序/数据库/混合）
- 网络域（内部/外部/DMZ）
- 服务器 IP 地址
- 硬件制造商
- 模型类型
- 处理器数量
- 内存信息
- 存储信息
- 物理/虚拟
- 服务器利用率
- 平均利用率
- 峰值利用率
- 峰值时间
- 服务器配置历史
应用程序行为：
- 在服务器上运行的应用程序名称是什么？
- 提供对该应用程序及其业务功能的简要描述。包括它所做的以及整个操作。
- 该应用程序是一个大型企业应用程序组的一个组件或一部分吗？
- 如果是，该应用程序和其他企业应用程序组 (Enterprise Application Group, EAG) 组件应用程序需要联锁吗（例如，该应用程序或其他 EGA 组件应用程序有紧密耦合的依赖项或功能，必须被视为其他项目活动的一个单元）？
- 该应用程序是内部开发的？还是从独立软件供应商处购买的现成的？选择一个：
- 定制/本土
- COTS- 无修改
- COTS- 细微修改
- COTS- 重大修改
- 主要应用程序软件供应商以及所用软件版本是什么？
- 该应用程序目前运行的平台是什么？（Windows、Linux、AIX、Solaris，或其他）
- 是首选平台吗？考虑或需要其他平台吗？
- 该应用程序所有签署文件（比如技术文件或 UAT）上的 Account Focal，DPE (Delivery Project Executive) 或者指定代理是谁？
- 提供的图纸或文档有助于全面了解应用程序的运行吗？
- 重大更改、升级、或规划的关键项目是针对该应用程序或其主服务器吗？
- 对该应用程序进行分类，选择一个：
- 单机应用程序
- 应用程序 & 数据库
- 基础架构 / 实用程序
- 单机 Web
- Web 应用程序 & 数据库
- 该应用程序使用一些常见（共享）服务吗？如果是，请详细描述（例如：防火墙、代理或重定向，认证、Lotus Notes® 复制、MQ Series、Web 认证）。通常，面向 Web 的应用程序可以显示所涉及的常见服务。
要获取网络信息和应用程序详细信息、及其未来策略和发展，还需要更多关键信息。此外，要获取部署在特定应用程序的特定软件的详细信息，比如数据库 (DB2) 中间件 (WebSphere Application Server) 以及消息传递 (WebSphere MQ)，可能还需要单独问卷调查。#p#
技术解决方案设计
技术解决方案设计是转换管理程序最关键阶段之一，因为存库输入验证、服务器和应用程序行为，以及客户会议成果都将反馈到应用程序解决方案设计中。
在 Technical Solution Design (TSD)（一个基于 Excel 的工作产品）中捕获的解决方案设计关键活动有：
- 解决方案的高度概括。
- 特定于 TSD 假设和已确定风险的记录。
- 解决方案描述，包括架构设计和应用程序影响。
- 一个包含所有源服务器信息的表格。
- 一个应用程序到服务器的映射表，对于每个应用程序及服务器（应用程序在上面执行）都包含一个条目。这是一个多对多的关系。
- 一个包含所有目标服务器信息的表。
- 一个目标环境描述和说明。
- 一个解决方案描述，包含架构决策和备案考量。
- 特定假设和风险。
某一架构决策场景图解
在进行技术解决方案设计时，需要将目标环境、目标平台、目标拓扑结构，以及与目标环境的兼容性方面考虑到关键架构决策中。以下 3 个示例是：
- 示例 1：Linux 虚拟环境中产品的兼容性
- 示例 2：Linux 环境的可移植性因素
- 示例 3：Linux 环境数据中心中的运营情况
示例 1：Linux 虚拟环境中产品的兼容性
- 主题范围：Linux 虚拟平台中兼容性的解决方案架构
- 问题或问题陈述：迁移的范围是构建一个 Linux 栈，该 Linux 栈将被复制到 3 个集群环境，但不限于：
- 开发
- 测试
- 生产
J2EE 应用程序将相继部署在这 3 个环境中。
- 假设：J2EE 容器是 WebSphere Application Server (WAS)。
- 备用方案：
- 首先，使用 OS 和 WAS 中间件构建开发环境，然后应用克隆技术创建测试和生产环境
- 使用 OS 和 WAS Hypervisor Edition 在 Linux 中间件上创建开发环境，然后应用克隆技术创建测试和生产环境
- 决策：与备用方案 2 一起使用。
- 理由：如果您使用 WAS Standard 或 Enterprise 版本构建 Linux OS，当前环境的主机名和 IP 地址的引用将在在安装过程中集成，并且耦合的更为紧密。从开发 Linux 映像中构建一个新克隆后，WAS 并不能在新的 Linux 内置映像中运行，因为它在很多地方，包括单元名和 WAS 配置文件中的其他地方，存储了旧的主机名和 IP 引用。删除配置文件以及创建一个新配置文件可能会增加迁移工作量。
为了避免这类问题，在 Linux 上选择 WAS Hypervisor 版本，因为它与当前环境不是紧耦合的，可以帮您减少编写代码和删除依赖项的手动操作。
示例 2：Linux 环境的可移植性因素
- 主题范围：平台选择上的解决方案架构示例。
- 问题或问题陈述：比较 AIX 和 Linux on System z 环境中迁移应用程序和后台数据库服务器。所有服务器应用程序和 DB2 后台组件目前都运行在非虚拟化 AIX 环境中。从可扩展性和运营成本角度来看，不管是在 Linux 还是在 AIX 上，客户都想将服务器移到一个虚拟环境以获取虚拟化的优势和一个更好的计算平台。
- 假设：Linux 虚拟化平台和 AIX 虚拟化平台都可用。Linux 定价模型比 AIX 环境更具经济吸引力。
- 备用方案：
- 在 AIX 中构建所有服务器内置组件，是虚拟化的，因为源平台是 AIX。这涉及的迁移相关风险最小
- 在 Linux 中构建所有服务器内置组件，是虚拟化的，因为它对客户来说最具经济效益。
- 在 AIX 中构建后台数据库，在 AIX 和 Linux 中构建前端组件，是虚拟化的。
- 决策：与备用方案 3 一起使用。
- 理由：DB2 组件对于 System z 上的 Linux 而言是最理想的，因为主机架构对于管理那些高 I/O 操作期望且 DB2 数据库后台本身就有比应用程序服务器组件更高的I/O 的工作负载来说装备更完善。然而，在 DB2 后台组件中客户也需要集群，这是在 AIX/pSeries 中保持 DB2 所必需的，因为：
- 相比在 zLinux 中新构建的 Tivoli Storage Automation (TSA) 和 DB2 HADR，HACMP 是一个成熟的集群工具，然而 TSA 在 z 测试系统上测试并不是很好。
- 对于 DB2 服务器来说，持续高峰值利用率（超过 75%）与 pSeries® 硬件创建一个密切的关系。拥有低 CPU 密集工作负载的 WAS 组件被认为适用于 System z 上的 Linux。
示例 3：Linux 环境数据中心的操作方面
- 主题范围：数据中心选择解决方案架构示例。
- 主题：操作模型和主机位置。在 Poughkeepsie Data Center 或 Boulder Data Center 中构建基础架构。
- 问题和问题陈述：从当前位于 Southbury 中的 IBM 数据中心将服务器工作负载迁移到 Poughkeepsie、NY 或 Boulder CO 中的新虚拟化 Linux 环境。
- 备用方案：
- Poughkeepsie
- Boulder
- 决策：。与备用方案 1 一起使用。
- 理由：
- 就未来发展模式而论，服务器容量（高级别）和存储容量需求与 z9 和 z10 可用性以及 Poughkeepsie 共享容量十分匹配。
- Southbury 和 Poughkeepsie 紧密邻接有助于减缓数据迁移。
- Southbury 和 Poughkeepsie 同时区优势使操作复杂性最小化。
关于容量规划和服务器分级需要注意的一点是：
应用容量管理技术来确定最优分配或在新整合服务器环境中对资源进行分级，以及确保预期工作负载的性能。目标服务器硬件的适当分级对于确保以下性能至关重要：
- 性能
- 未来发展
- 固结比
- 经济效益
图 6 显示了这些规划和分级因素的相互关系。
图 6. 容量规划和服务器分级因素
服务器分级是基于评估/库存盘点阶段执行的数据收集的。例如，您可以分析其当前硬件模型、CPU 性能指标，以及现有硬件中可用内核和芯片数量，然后再计算每个服务器的 RelativePerformance 值 (rPerf) 分级。查找以下关键项：
- 服务器制造
- 服务器模型
- CPU 数量
- CPU 内核
- CPU 速度
- CPU 利用率
- 已安装的 RAM
- 已使用的 RAM
- 已分配和使用的存储空间
评估是直接基于其他服务器的峰值 CPU 利用率，根据工作负载特征进行调整。服务器合并分级评估精确性取决于提供的输入。对于不准确的评估而言，最常见的是由于错误的当前服务器 CPU 利用率所导致的。每个单独服务器的峰值 CPU 利用率和跨所有服务器（分级所用的）的峰值需求模式对于一个好的评估来说是至关重要的。如果峰值负载是的免费的，那么它们可能发生在不同时段，服务器容量需求可能明显少于峰值并发时的容量需求。工作负载特征的变化也是一个重要的因素。工作负载特征变化可能会导致在分级结果中出现一个 4x 的差量。不正确的或不精确的输入使得分级结果无效。检查分级中使用的输入也是非常重要的，这些输入精确反映当前服务器的工作负载和 CPU 利用率。
正确收集峰值 CPU 利用率也是很重要的。它们表示的应该是 15 - 30 分钟峰值需求间隔的平均 CPU 利用率，而不是瞬时峰值。如果客户的平均 CPU 利用率数据是以 8 小时或一天为单位，可能需要应用峰均比 (peak-to-average ratio) 来正确反映峰间 CPU 利用率。
基准测试的分级参数包括：
- 应用程序
- 性能监控器
- 数据文件（数据集）和数据库
- 脚本（用户命令）或作业
- 工作集大小
- 终端模拟
- 用户群体大小
- 平均思考时间和思考时间分布
- 事务率
- 响应时间标准
- 操作方法论
最佳实践包括：
- IBM 使用来自调查问卷的信息作为分级输入
- 分级模拟将客户计划业务量转换成潜在工作负载
- 潜在生产的 CPU、内存和风险需求
- 实际工作负载的功能评估
- 理解分级指导方针、方法论和工具
- 验证/区别分级、容量规划、或性能分析练习和每个独立场景中所用的工具和方法论之间的分级请求，以及如何运用到此客户环境中
- 使用 IBM 分级工具（如果适用），或者 ISV 分级方法论/工具。确保使用最新版分级工具
- 理解微分区如何影响分级，并在输出结果中进行解释
- 提供动态余量和多个分级，包括增长预测
- 工具精确度：和预期的一样好 +/- 30%
- 获取一个容积数据点，确保是签字同意的，否则，可能触发一个多米诺效应，导致错误分级
- 考虑批处理的并行影响
分级工具参考：
- IBM 专有分级工具： VISIAN
VISIAN 是一个基于 Excel 的 IBM 内部工具，用于获取源服务器技术配置（比如 CPU 和内存的数量、类型和速度）、源服务器资源使用情况（比如 CPU 利用率，内存利用率和 NW 利用率等），并将虚拟化层特性、限制和日常开支都考虑在内。同时也支持 Mware ESX、MSVS、Virtual Iron 和 pSeries hypervisorsis。
VISIAN 计算以下内容：
- 所需目标服务器数量
- 每个目标服务器的信息
- 虚拟机数量
- 每个目标服务器中需要虚拟化的源服务器列表
- CPU、内存、网络、磁盘空间和磁盘 I/O 的虚拟化
- 所需物理空间（机架单位）
- 硬件和虚拟软件成本
- 流行的第三方分级工具
- VMware Capacity Planner
和其他工具不一样，VMware Capacity Planner 是一个托管应用程序服务，只能用于目标 VMware 环境。它在网络上安装大量组件来收集和管理数据。然后将数据发回 VMware 进行分析。最大缺陷是没有软件所有权，不能用于正在进行的工作。供应商分析完成后，通常为用户呈现一个提供不同配置以实现虚拟化目标的场景。Capacity Planner 服务可从 VMware 渠道合作伙伴处获取，包括咨询公司、硬件供应商、软件供应商和其他折扣店。
- Novell PlateSpin PowerRecon
Novell 的 PowerRecon 工具集成了远程数据收集、工作负载分析以及规划和场景比较功能以实现服务器整合。它将自动分析以下工作负载：CPU、磁盘、内存和网络。
- CiRBA
CiRBA 可以通过分析 CPU、内存、IO、日常开支和存储来粗略估计硬件分级作为始点。
- VMware Guided Consolidation
此内置工具是针对于较小 IT 环境的 Virtual Infrastructure 3 (VI3) 的一部分。
它对选中的系统组进行分析，给出最佳服务器虚拟化建议，并执行物理到虚拟 (Physical-to-Virtual, P2V) 转换。
- VMware Capacity Planner
框架布局目标拓扑：
迁移的另一个重要方面，特别是在虚拟环境中，就是设计和制定目标拓扑决策，以及将 Virtual Machine (VM) 来宾分布到正确的框架或物理容器。
应用程序栈和依赖性分析：
容量规划练习和依赖性考虑应在解决方案设计阶段进行讨论和决定。考虑在适当应用程序栈中出现的各种部署因素。这里列出了一些部署因素，进行单独讨论：
- 软件栈版本：例如，WAS 6.0 应用程序对 VS WAS 7.0 应用程序。WAS 支持生命周期不同，其维护或修复程序包发布频率也不相同。
- 安全性：对应用程序进行分组需要 4 级数据安全性，在一个独立框架中比较 SSO 与非 SSO 认证，以维护更好的职责分离和隔离。
- 性能和吞吐量：应用程序需要较快地响应 SLA，应用程序要求较高地内存占用以维持所需性能，比如，与一个需要 256 到 512 MB 大小的 JVM 堆的简单应用程序相比，需要 2GB 堆的 JVM 可能会成为一个专用应用程序服务器。
- 可扩展性：可扩展来升级的共享应用程序，该应用程序计划在即将发布的版本中引入 Web 服务，准灾难恢复应用程序，以及其他类别。
- 可用性：基于 SLA。
- 灾难恢复 (DR) 级别：Group Tier 1 和 Tier 2 应用程序来设计一个最优共享 DR 基础架构。
虚拟环境中的框架布局应用程序级分析：
从应用程序相关性角度来说，虚拟环境中的 VM 来宾决策布局是非常重要的，例如，更高 SLA 应用程序跨 VM 传播。您可以识别诸如数据处理、更高 I/O 驱动批处理作业、高容量事务处理、Web 呈现以及一年或一季度的峰值负载次数等应用程序功能需求，但不限于此。因此，您可以决定将其放置在正确的架构中以分配整个架构工作负载。
您可以分配超过 100% 的资源，这就是认购超额，一个虚拟化按需容量规划，来处理上限阈值建议的实际物理容量。这一决策得到并非所有 VM 同时都以峰值运行这一事实的支持，因此，处理器容量可用于解释过度的分配 。例如，一个批处理服务器类型工作负载的 Linux 映像可与事务服务器的其他 Linux 映像一起运行，超出了可用容量，因为批处理工作负载将在夜间活动而那时事务服务器是空闲的或半空闲的。因此，整个工作负载可以得到很好的平衡，满足超额认购。#p#
服务器和应用程序迁移
终于可以准备开始服务器和应用程序迁移了。
IT 环境构建
一旦解决方案设计完成，就可以开始目标环境构建工作了。编译一个通常称为 Build Sheet 的文档，包含细节和准目标映像规范。到此时，目标硬件分级、与用户 ID 相关的用户需求列表、文件系统及其他项目都应该完成了。
实际 IT 环境构建流程可通过使用 IBM Tivoli Provisioning Manager (TPM) 这类工具自动完成，或者可能是手工完成的。根据所采用的方法，构建表单可以是基于 Excel 的（适用于手动流程）或是指向自动部署工具（例如 TPM）的基于 Web 的自助式界面门户。
无论您采用何种方法，构建表单中的一些基本细节如下：
- 请求组详细信息
- 创建的日期
- 请求程序
- 源服务器概要
- 服务器数量
- CPU 总量
- 内存总量
- 目标服务器概要
- 服务器数量
- 所需 CPU 总量
- 所需内存总量
- 本地磁盘总量
- 管理信息
- 应用程序名称
- 客户
- 项目经理
- 主机和网络信息
- 主机
- 主机位置
- 主机架构
- 主要 IP 地址
- 完全资格域名
- 软件组件
- 操作系统
- 数据库
- 中间件
- 本地文件系统
- 挂载点类型
- 大小 (MB)
- 所有者
- 组
- 权限
- 卷
- 用户
- 名称
- 主要的
- 组
- 次要组
上述请求经过所有利益涉众检查之后，迁移团队将其提交给服务器构建团队，一旦服务器构建团队准备完成就可以开始处理映像。然后，迁移团队则开始执行迁移计划中概述的活动。#p#
应用程序迁移和单元测试
迁移活动开始之前，有必要记录迁移过程中涉及的所有步骤，这个阶段称之为迁移规划，迁移计划 需要的准备工作。迁移计划是一个非常详细的文档，介绍迁移团队依次执行的所有任务。它包括活动名称、活动所有者、开始日期和预期持续时间。迁移团队的每个成员都应执行此计划中提到的属于自己的任务。迁移计划将从而形成一个极佳的跟踪文档，基于电子表单的迁移计划通常具有以下部分：
- 封面：项目名、文档审批人、修订历史
- 服务器：迁移服务器名称
- 前期迁移：适用于迁移的各个软件的任务。
- 验证安装的 DB2 客户端/服务器
- 从源服务器获取表空间的详细列表
- 准备 DB2 备份和还原
- 在目标环境中创建 DB2 实例
- 迁移：每个软件的相关任务。环境设置和代码校正（设置用户配置文件、登录 shell、环境变量、校正应用程序脚本中的硬编码路径）也同时完成。DB2 任务示例包括关闭源环境中的数据库服务器，启动离线数据库备份，并将数据库恢复到目标服务器上。一旦应用程序正确安装完成并在新环境中运行时，展开环境验证测试/单元测试。
- 后期迁移：执行清理任务。删除迁移过程中创建的所有自定义脚本和临时用户 ID。
- 联系方式：列出了参与迁移活动的所有人的名字，及其联系方式
- 问题：（可选）记录迁移过程中面临的问题或相关注释。
服务器准备检查：（适用于生产环境和非生产环境）：
目标映像交付到迁移团队之后，需要在服务器映像上执行一系列检查以验证它们是否符合需求（构建表单中提到的）。这一步称之为服务器准备检查，由 UNIX 命令构成，用来检查映像参数。
示例：
- 卷组、卷、文件系统以及挂载点是否已经建立并按照构建表单的规定配置了吗？
- 文件系统是否已根据构建表单规定正确建立了吗？
- #df –h < filesystem>
常见检查分为用户、系统、存储、安装软件和具体说明。迁移工程师贯穿每个阶段，接受或拒绝它们。如果有较大的差异，映象将发送回基础架构团队进行更正。只有签字同意后，应用程序迁移才能开始。
前期迁移任务：
- 非生产环境：
在关闭源服务器和应用程序之前，通知用户即将停机。每个中间件专家执行一组关于软件（诸如 DB2、Lotus Domino 和 WebSphere MQ 之类）设置和配置的任务。与此同时，将应用程序二进制文件和文件系统从源服务器迁移到已启动的目标服务器。也是在此时，将用户主目录从源环境复制到目标环境。
将文件从源服务器转移到目标服务器的常用方法是 tarring，然后使用 ftp 模式复制文件，或者使用 rsync。
- 生产环境：
在生产环境中，正如之前提到的，执行了与设备和配置各种软件（诸如 DB2 或 Lotus Domino 之类）相关的任务。相反，在源环境中，应用程序文件和二进制文件将从最新迁移的开发服务器（服务器投入使用之后）中复制。正如在非生产环境中，用户主目录从相应生产源服务器中复制。
迁移任务（适用于生产环境和非生产环境）：
这是主要阶段，正如迁移计划中定义的，各个软件领域（诸如 DB2、Lotus Domino 或 WebSphere MQ 之类）的专家将在该阶段执行实际迁移任务。
- 迁移工程师验证目标环境中的应用程序文件系统和权限是否与源服务器中设置的一样。在此期间的关键活动有：
- 设置用户配置文件，登录 shells
- 设置应用程序环境变量
- 校正应用程序脚本中的硬编码路径
- 当应用程序正确安装到新环境中后，执行一些应用程序源代码矫正，正如可行性研究阶段和单元测试结果所确定的。执行代码矫正的主要原因是以下组件中发生了变更：
- 操作系统
- 编译器
- 软件版本
- UNIX 脚本
- 在提交新服务器之前进行彻底的单元测试，有助于应用程序团队进行用户验收测试。
注意：在生产环境中，代码矫正和移植工作的工作量和复杂程度几乎可以忽略不计，因为大多数工作在开发服务器中已经完成了。#p#
系统集成测试和用户验收测试
迁移工作完成后，安装和迁移到新环境中的应用程序都将移交给客户团队以进行验证和确认。在这个阶段，客户测试团队会执行应用程序级测试以检查业务功能是否被破坏，性能级别是否令人满意。客户团队可能关于测试过程中的某一问题或故障恢复咨询应用程序团队。
在测试阶段，Wave 项目经理或指定的评估工程师将担任协调角色，与客户团队一同执行下列操作：
- 每日从客户团队收集测试进展和缺陷状态，协助推动缺陷解决
- 每周向管理和项目办公室报告测试状态
- 协助测试依赖性、风险和问题。
然而，Wave 项目经理或指定的评估工程师将不再执行测试或验证结果，因为这通常是应用程序测试团队的职责。
服务器进入生产
对于非生产环境：
随着用户验收测试的完成，客户团队在新服务器上签字。后期迁移任务涉及删除在新服务器上临时安装的有助于迁移实现的自定义脚本和文件。
对于生产环境：
在生产环境中，一组全新的转换 活动现在开始执行。这涉及关闭源环境中的生产服务器，启用新环境中的生产服务器。在该转换过程中，用户会受到一定的影响，因为此活动通常是在应用程序维护窗口完成的，大多数都是在周末进行的，以最小化应用程序停机时间。
基于电子表单的转换计划通常由以下部分组成：
- 服务器列出将要转换的生产服务器名称。
- 前期转换列出的任务包括关闭源服务器准备工作，生产环境中安装的软件和应用程序文件的最后验证，源环境中的数据备份和目标环境中的数据恢复，URL 变更请求的提交等活动。
- 转换列出源环境中应用程序和批处理作业的实际停机顺序，在目标环境中启动它们，执行 URL/DNS 更改请求，进行最终测试，以及通知用户新系统的可用性。
- 后期转换列出终结的转换活动。处理与上游/下游生产环境变更协调的任务，完成所有其余文档任务，并监控新环境单元直至稳定。
- 回滚处理偶然的新环境上线失败，使用一个条件 (provision) 以返回之前的环境。这些步骤包括启动退出进程、启动旧环境中的软件和应用程序，运行批处理作业，以及重定向 URL/DNS 指回旧系统。
- 假设列出与转换相关的所有假设，比如：
- 数据移动之前目标环境上的所有程序、脚本和表
- 在目标环境中只有应用程序停机数据需要完成生产
- 完成的所有测试，以满足重定位到目标环境
- 联系方式参与转换过程的所有人名字，及其联系方式。
- 问题是可选的，在转换过程中面临的问题及相关注释的文档。
生产和非生产环境通用的：
健康检查
应用程序团队的责任是对应用程序执行健康检查，以确保所有一切可以跟得上项目进度。然后，基础架构团队在上线之前执行最终健康检查。这包括安全性批处理、监控和确保备份就绪。这可能需要 2 到 4 天，具体取决与有多少个映像参与，需要制定相应的计划。基础架构团队在上线会上给予赞扬说明这些项目是完整的。
后期生产
服务器投入生产后，迁移团队还需要执行 2 个最终步骤，提供保修期并退役 (sunset) 旧服务器。
后期转换保修
服务器投入生产之后，迁移团队通常监控新环境的性能，并随时准备解决问题。这通常持续 10 天到 2 周，称为保修期。在这段期间，客户有权要求迁移团队成员进行任何解答或故障恢复。保修期结束后，客户团队对所有维护和服务器维护负责。
退役和报废或改换用途
新非生产服务器和生产服务器投入运行，并完成一个预定义天数且没有出现任何重大问题或停机，旧服务器旧可以退役了，报废或者用作其他用途。
跟踪
在整个迁移过程中，跟踪项目阶段和端到端交付是必不可少的。鉴于这个原因，建议采用一个检查清单，通常称之为技术仪表板检查清单 (Technical Dashboard Checklist)，一个基于 Excel 的构件，包含 图 7 所示的条目。
图 7. 技术仪表板检查清单
在技术仪表板检查清单中，Item/Task 列列出了活动或可交付成果，即迁移、转换以及其他计划中的任务，也列出了每个任务的所有者、目标和完成日期，以及完成状态。在迁移阶段，作为以最佳实践，迁移工程师在每个工作日结束后更新该检查清单以反映任务和可交付成果的当前状态。彩色编码方案（绿色、黄色和红色）有助于形象地显示识别该项目在任何给定时间的健康状况。
结束语
本文介绍了应用程序迁移的概念，同时指导您如何规划、准备和最终实施这些活动。现在您对整个迁移过程，需要的主要架构决策，工作产品准备应该有一个比较清楚的了解，并知道了如何避开此过程中的陷井。
