很多大型應用程序開發和維護帳戶，當考慮到要將核心應用程序和數據庫遷移到一個新環境時，您會不知所措，不知道從哪里開始，如何規劃和實現遷移，以及如何避開過程中的陷阱。缺乏對標準方法論或指導方針的認識，增加了將應用程序從一個平臺快速和高效地遷移到另一個平臺的評估困難。

本文探討高度成功的 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. 樣例工作負載分布模型

服務器和應用程序資格

進一步完善您的潛在遷移候選對象列表。

轉換規劃和可行性研究

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。

2. 定義應用程序復雜性以評估應用程序遷移的工作量

   僅從服務器復雜性定義可能并不能完全理解遷移工作，因為服務器可能較簡單，但是產品、技術或運行的應用程序可能比較復雜。從應用程序的角度對復雜性進行分類對于理解遷移同樣重要。圖 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) 的大量工作流定制。
3. 數據庫，如果其中包括：
   • 較小的數據庫
   • Intra-Data Center (DC) 遷移
   • 有單個實例實現的服務器
   • 有 2 個應用程序所有者的服務器
   • 沒有本機語言代碼來避免代碼矯正的數據庫
   • 有周末停用窗口可供使用的應用程序

通常，一個復雜應用程序有一個以某種語言開發的自定義程序，這在不同 OS 中不受支持，在獨立語言中代碼重寫是必須的，應用程序需要使用多個自定義 API 程序，或者自定義應用程序需要使用特定于當前環境的 API 或庫。#p#

Wave 規劃：在一個組中遷移

在 圖 5 中，實際遷移復雜性級別由應用程序和服務器復雜性共同決定。

圖 5. 協調服務器復雜性和應用程序復雜性
 

服務器/應用程序遷移通常通過一個在服務器遷移規劃中確定的 wave 方法進行。確定適合篩選階段的服務器/應用程序之后，在 wave 中使用高級別預測時間表分配遷移。Wave 項目啟動后，服務器和應用程序復雜性將依據遷移的總體復雜性導出一個遷移時間表，與硬件/服務器和應用程序二進制文件/數據相關。

本文不涉及其他 wave 規劃流程，比如，應用程序排序，應用程序優先級、財年結算或企業凍結，因為這些只特定于各個項目。

形成一個 wave 后，wave 項目經理就為遷移項目準備了項目計劃。項目經理將咨詢客戶團隊，對系統測試和用戶驗收測試所需的工作量做出評估。從項目計劃角度來看，各個階段如下（如 表 2 所示）：

1. 解決方案啟動和規劃：執行可行性研究并制定關鍵技術決策。確定目標環境。
2. 執行和控制：創建一個詳細計劃來執行和控制每個合格應用程序的遷移。
3. 投入使用并關閉：最后，將新環境投入使用，隨即關閉項目。
   表 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)。
• 備用方案：
  1. 首先，使用 OS 和 WAS 中間件構建開發環境，然后應用克隆技術創建測試和生產環境
  2. 使用 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 環境更具經濟吸引力。
• 備用方案：
  1. 在 AIX 中構建所有服務器內置組件，是虛擬化的，因為源平臺是 AIX。這涉及的遷移相關風險最小
  2. 在 Linux 中構建所有服務器內置組件，是虛擬化的，因為它對客戶來說最具經濟效益。
  3. 在 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 環境。
• 備用方案：
  1. Poughkeepsie
  2. 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 計算以下內容：

  1. 所需目標服務器數量
  2. 每個目標服務器的信息
     1. 虛擬機數量
     2. 每個目標服務器中需要虛擬化的源服務器列表
     3. CPU、內存、網絡、磁盤空間和磁盤 I/O 的虛擬化
  3. 所需物理空間（機架單位）
  4. 硬件和虛擬軟件成本
• 流行的第三方分級工具
  1. VMware Capacity Planner

     和其他工具不一樣，VMware Capacity Planner 是一個托管應用程序服務，只能用于目標 VMware 環境。它在網絡上安裝大量組件來收集和管理數據。然后將數據發回 VMware 進行分析。最大缺陷是沒有軟件所有權，不能用于正在進行的工作。供應商分析完成后，通常為用戶呈現一個提供不同配置以實現虛擬化目標的場景。Capacity Planner 服務可從 VMware 渠道合作伙伴處獲取，包括咨詢公司、硬件供應商、軟件供應商和其他折扣店。

  2. Novell PlateSpin PowerRecon

     Novell 的 PowerRecon 工具集成了遠程數據收集、工作負載分析以及規劃和場景比較功能以實現服務器整合。它將自動分析以下工作負載：CPU、磁盤、內存和網絡。

  3. CiRBA

     CiRBA 可以通過分析 CPU、內存、IO、日常開支和存儲來粗略估計硬件分級作為始點。

  4. VMware Guided Consolidation

     此內置工具是針對于較小 IT 環境的 Virtual Infrastructure 3 (VI3) 的一部分。

     它對選中的系統組進行分析，給出最佳服務器虛擬化建議，并執行物理到虛擬 (Physical-to-Virtual, P2V) 轉換。

框架布局目標拓撲：

遷移的另一個重要方面，特別是在虛擬環境中，就是設計和制定目標拓撲決策，以及將 Virtual Machine (VM) 來賓分布到正確的框架或物理容器。

應用程序棧和依賴性分析：

容量規劃練習和依賴性考慮應在解決方案設計階段進行討論和決定。考慮在適當應用程序棧中出現的各種部署因素。這里列出了一些部署因素，進行單獨討論：

1. 軟件棧版本：例如，WAS 6.0 應用程序對 VS WAS 7.0 應用程序。WAS 支持生命周期不同，其維護或修復程序包發布頻率也不相同。
2. 安全性：對應用程序進行分組需要 4 級數據安全性，在一個獨立框架中比較 SSO 與非 SSO 認證，以維護更好的職責分離和隔離。
3. 性能和吞吐量：應用程序需要較快地響應 SLA，應用程序要求較高地內存占用以維持所需性能，比如，與一個需要 256 到 512 MB 大小的 JVM 堆的簡單應用程序相比，需要 2GB 堆的 JVM 可能會成為一個專用應用程序服務器。
4. 可擴展性：可擴展來升級的共享應用程序，該應用程序計劃在即將發布的版本中引入 Web 服務，準災難恢復應用程序，以及其他類別。
5. 可用性：基于 SLA。
6. 災難恢復 (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 命令構成，用來檢查映像參數。

示例：

1. 卷組、卷、文件系統以及掛載點是否已經建立并按照構建表單的規定配置了嗎？
    
2. 文件系統是否已根據構建表單規定正確建立了嗎？

#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 列列出了活動或可交付成果，即遷移、轉換以及其他計劃中的任務，也列出了每個任務的所有者、目標和完成日期，以及完成狀態。在遷移階段，作為以最佳實踐，遷移工程師在每個工作日結束后更新該檢查清單以反映任務和可交付成果的當前狀態。彩色編碼方案（綠色、黃色和紅色）有助于形象地顯示識別該項目在任何給定時間的健康狀況。

結束語

本文介紹了應用程序遷移的概念，同時指導您如何規劃、準備和最終實施這些活動。現在您對整個遷移過程，需要的主要架構決策，工作產品準備應該有一個比較清楚的了解，并知道了如何避開此過程中的陷井。