应用程序迁移_加速绿色IT-关于应用程序迁移和重新托管的实用指南

应用程序迁移

许多大型应用程序开发和维护帐户都考虑到将核心应用程序和数据库迁移到新环境的问题，从哪里开始，如何计划和实施迁移以及如何避免过程中的陷阱就迷茫了。 缺乏对标准方法论或指南的了解，在为快速有效地将应用程序从一个平台迁移到另一个平台的估算形成困难。

本文探讨了非常成功的IBM Project Big Green，其目标是将大约3900台IBM内部服务器整合到大约30个System z Linux环境中。 本文的目的是介绍所采用的总体方法，共享最佳实践和工具，并提供指向服务器整合和虚拟化空间的初始指针。

尽管本文将重点讨论从一个UNIX®平台到另一个平台的类似迁移，但在其他迁移场景中同样有用。 它面向迁移工程师，迁移架构师和技术团队负责人，并且可以作为所有技能级别的任何迁移活动的参考。

迁移过程概述

首先，让我们了解术语工作负载 ：工作负载是在虚拟化或非虚拟化环境中的操作系统（OS）上运行的一个应用程序或一组应用程序。 工作负载包括在硬件上运行的OS，在OS层上运行的中间件以及在中间件系统上运行的一组或一组相似的应用程序。 数据库工作负载的示例可能是：

• DB2®或Oracle工作负载
• Web应用程序工作负载，例如Java™应用程序，WebSphere®应用程序，Weblogic应用程序或其他
• 前端工作负载为静态图像或页面
• 中间层应用程序工作负载，例如WebSphere MQ，Message Broker，Web服务等

将各种UNIX工作负载（例如AIX，Solaris或x / Linux）迁移到z / Linux（或任何平台）上，在技术上可能并不困难。 请记住，由于缺乏评估和适当计划的经验，这种参与可能会变得复杂。 有条不紊的准则以及适当分阶段的方法可以巩固转型过程。 图1捕获了典型迁移周期的总体阶段：

图1.迁移概述

任何迁移活动都可以大致分类：

• 发现阶段涉及发现服务器清单和应用程序依赖性
• Map阶段涉及创建迁移请求和目标拓扑
• 供应，迁移和配置阶段涉及构建目标环境，应用程序部署和移植
• 测试阶段在迁移后在新环境中测试应用程序，然后上线。

详细的迁移阶段：

1. 识别/库存
2. 服务器/应用程序资格
3. 规划设计
4. 服务器/应用程序迁移
5. 后期制作

下面的图2提供了迁移流程，其中显示了特定的子类别。 典型的迁移活动从服务器标识和清单开始 -该过程扫描范围内的服务器并识别潜在的迁移候选对象。 此潜在的候选者列表在以下步骤（ 服务器/应用程序资格认证 ）中进一步完善。 在进行了详细的可行性研究之后，选择最终的迁移候选对象并进行逻辑分组以形成波动。 然后，此合格服务器/应用程序的最终列表将进入下一个阶段，即计划和设计 ，在该阶段中您将执行详细的目标拓扑和迁移计划。 完成详细设计后，您现在进入称为服务器/应用程序迁移的实施阶段，在其中构建目标环境，迁移要迁移的应用程序并对其进行全面测试。 完成迁移后，新服务器将上线，最后的后期制作阶段将在您停用旧服务器之后进行。

图2.详细的迁移阶段

现在，我们将深入研究每个阶段和活动，以了解所涉及的步骤。

识别和盘点

第一步是确定要迁移的服务器。 您还将清点服务器和每台服务器上的软件。

服务器识别

在进行迁移时，确定正确的资产集（即用于迁移的服务器）非常重要。 根据商定的工作负载管理，在服务器范围内或服务器范围之外定义服务器是由项目架构师和转换计划办公室完成的。 在清单验证过程中，首要任务之一是盘点现有工作负载（如果基于Intel，大型机或其他平台）。 IBMTivoli®应用程序依赖性发现管理器（TADDM）是有用的产品，有助于了解服务器，应用程序，网络设备，软件，配置文件，操作系统和其他IT基础结构组件之间的依赖性。

您可以将表1中的示例工作负载分配模型用于目标环境的初始选择标准。 在此表示形式中，隐藏了源服务器在CPU，RAM，网络I / O方面的实际利用率以及要考虑的候选候选人百分比。 但是，可以将此模型与给定的合理利用率指标一起使用，以决定服务器是迁移的候选者还是范围外的候选者。

表1.样本工作量分配模型

亲和力：	服务器特征：	平台特点：
大型机	降低持续的CPU峰值和平均内存需求 高和/或事务性I / O 接近大型机中的其他数据	仅在大型机上可用的软件 大型机上应用程序的其他组件
英特尔	已经在Intel上虚拟化 少量孤立图片	仅在Intel上可用的软件 大型机上的Linux不能满足所有Linux的需求
AIX / UNIX	仅在AIX / UNIX上具有很高的持续CPU峰值 仅在AIX / UNIX上可用的软件	已经在AIX / UNIX上虚拟化

服务器和应用程序资格

进一步完善您的潜在候选清单。

转型计划和可行性研究

1. 定义服务器复杂度以估计迁移工作

   一旦将一台服务器或一组服务器确定为可迁移到虚拟化目标环境的潜在候选者，下一个重要步骤是根据服务器硬件和软件的各种参数将服务器分类为简单，中等，复杂或非常复杂研究。 图3提供了选择标准的示例：

   图3.基于服务器类型的迁移复杂性

   

   简单服务器仅在一个操作系统实例下托管一个应用程序或一个应用程序的一部分，例如托管在WebSphere环境中运行的单个Web应用程序的基于Wintel的单核或双核CPU服务器。

   中型服务器可以托管两个或三个独立的应用程序，但没有定义多个虚拟机（VM），并且仍在OS实例下运行，例如，运行多个应用程序实例的服务器，例如WebSphere Application Server（WAS）， DB2，同一操作系统下的IBM Http Server（IHS）前端，通常在开发和测试环境中找到。

   复杂服务器通常是具有多个CPU的服务器，这些CPU可能定义了单独的逻辑分区（LPAR）。 每个LPAR都有其自己的OS副本或多个VM，以及一个OS的单独副本，并承载共享系统相同资源（例如网络I / O）的多个或不相关的应用程序。 一个示例可能是具有多个LPAR的Systemp®，这些LPAR运行单独的AIX，p-Linux OS或其他OS和VM，并运行许多不同的应用程序，共享同一网络I / O。

   非常复杂的服务器通常具有多个CPU，这些CPU可以具有单独的LPAR，每个CPU都有其自己的OS副本，或者具有多个VM的VM具有单独的OS副本，并且托管多个不相关的应用程序，这些应用程序共享某些系统资源（例如网络I / O），并通过硬件或软件负载共享或故障转移与其他单独的服务器群集在一起。 例如，可能有多个LPAR运行带有HACMP集群的p-Linux或AIX托管DB2数据库的独立OS。

2. 定义应用程序的复杂性，以估计应用程序的迁移工作量

   服务器复杂性的定义可能无法完全理解迁移工作，因为服务器可能很简单，但是产品，技术或应用程序的运行可能很复杂。 从应用程序的角度来看，复杂性分类对于理解迁移同样重要。 图4指出了从简单到非常复杂的应用程序的复杂性范围。

   图4.基于应用程序类型的迁移复杂性

   

   简单的应用

   • 数据库，如果它们包括：
     • 较小的数据库
     • 数据内中心（DC）迁移
     • 具有单实例实施的服务器
     • 具有最多两个应用程序所有者的服务器
     • 没有本地语言代码的数据库，以避免代码补救
     • 周末中断窗口可用的应用程序
   • WAS / Java应用程序，如果它们包括：
     • 较小的JVM大小或单个JVM实现
     • WAS按原样移动，例如WAS 6.1.x至6.1.x，WAS 5.1至6.0.x，6.1至7.0.x（未更改API）
     • 仅具有两个应用程序所有者的应用程序服务器
     • 上面没有本机语言代码（例如C / C ++）的应用程序，以避免代码补救
   • 如果是IHS：
     • 通常是静态页面，例如HTML，图像，带有少量CGI脚本JavaScript，Perl模块，或通过硬编码IP直接调用数据库和依赖项
   • Domino®（如果是）：
     • .NSF数据库中的独立应用程序，不与外部数据源或脚本交互

   中型应用程序始终基于案例，因为在简单和复杂之间的评估取决于数量，用户群，体系结构，中间件产品以及所有这些的组合。 例如，在没有任何定制JSP或定制模块的情况下，从WCS 6.x到6.x的WebSphere Commerce（WCS）迁移是中等迁移，但是此刻定制JSP或程序模块的数量增加，并且版本从5.5 /从5.6到6.x，根据工作量估算分析，它趋向于复杂或非常复杂。

   • 中等复杂度迁移的其他示例包括：
     • 简单的J2EE应用程序迁移，需要重新编写代码，只是将API从1.4.2更改为1.5（JRE版本࿰