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

look_w

规划和设计作为规划和设计阶段的一部分，您和客户应该总结此服务器和应用程序行为以实现迁移。根据评估，设计一个技术解决方案。
应用程序评估客户的应用程序评估通过问卷调查，紧接一个关键利益涉众和应用程序团队技术机组成员会议的形式进行的。准备一个应用程序资产问卷调查 (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)，可能还需要单独问卷调查。
技术解决方案设计技术解决方案设计是转换管理程序最关键阶段之一，因为存库输入验证、服务器和应用程序行为，以及客户会议成果都将反馈到应用程序解决方案设计中。
在 Technical Solution Design (TSD)（一个基于 Excel 的工作产品）中捕获的解决方案设计关键活动有：

• 解决方案的高度概括。
• 特定于 TSD 假设和已确定风险的记录。
• 解决方案描述，包括架构设计和应用程序影响。
• 一个包含所有源服务器信息的表格。
• 一个应用程序到服务器的映射表，对于每个应用程序及服务器（应用程序在上面执行）都包含一个条目。这是一个多对多的关系。
• 一个包含所有目标服务器信息的表。
• 一个目标环境描述和说明。
• 一个解决方案描述，包含架构决策和备案考量。
• 特定假设和风险。

某一架构决策场景图解在进行技术解决方案设计时，需要将目标环境、目标平台、目标拓扑结构，以及与目标环境的兼容性方面考虑到关键架构决策中。以下 3 个示例是：

示例 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 利用率。