很多大型應(yīng)用程序開發(fā)和維護帳戶，當(dāng)考慮到要將核心應(yīng)用程序和數(shù)據(jù)庫遷移到一個新環(huán)境時，您會不知所措，不知道從哪里開始，如何規(guī)劃和實現(xiàn)遷移，以及如何避開過程中的陷阱。缺乏對標(biāo)準(zhǔn)方法論或指導(dǎo)方針的認(rèn)識，增加了將應(yīng)用程序從一個平臺快速和高效地遷移到另一個平臺的評估困難。

本文探討高度成功的 IBM Project Big Green，其目標(biāo)是將大約 3900 個 IBM 內(nèi)部服務(wù)器合并到約 300 個 System z Linux 環(huán)境中。本文旨在介紹所采用的整體方法，分享最佳實踐和工具，提供指向服務(wù)器整合和虛擬化空間的初始指針。

盡管，本文重點關(guān)注從一個 UNIX平臺到另一個 UNIX平臺的同類遷移，但同樣可用于其他遷移場景。本文是針對遷移工程師、遷移架構(gòu)師和技術(shù)團隊領(lǐng)導(dǎo)，同時也可以作為參考用于任何技術(shù)水平的任何遷移案例。

遷移過程概述

首先，我們了解一下術(shù)語工作負(fù)載：工作負(fù)載是在虛擬化或非虛擬化環(huán)境中運行在操作系統(tǒng) (Operating System, OS) 上的一個應(yīng)用程序或一組應(yīng)用程序。一個工作負(fù)載包含一個運行在硬件上的OS，運行在 OS 層上的中間件，以及運行在中間件系統(tǒng)上的一組或類似組應(yīng)用程序。數(shù)據(jù)庫工作負(fù)載示例可以是：

• DB2或 Oracle 工作負(fù)載
• Web 應(yīng)用程序工作負(fù)載，比如 Java™ 應(yīng)用程序、WebSphere應(yīng)用程序、Weblogic 應(yīng)用程序，等等
• 前端工作負(fù)載，比如靜態(tài)圖像或頁面
• 中間層應(yīng)用程序工作負(fù)載，比如 WebSphere MQ、Message Broker、Web 服務(wù)，等等

將各種 UNIX 工作負(fù)載，比如 AIX、Solaris 或 x/Linux，遷移到 z/Linux（或其他平臺）可能沒有什么技術(shù)上的挑戰(zhàn)。請記住，這類項目可能因為缺乏評估和合理規(guī)劃而變得復(fù)雜。一個有條不紊的規(guī)劃以及一個適當(dāng)?shù)碾A段性方法將會鞏固該轉(zhuǎn)換過程。圖 1 是一個典型遷移周期的整體階段：

圖 1. 遷移概覽
 

任何遷移過程可大致分為：

• 發(fā)現(xiàn)階段，涉及服務(wù)器庫存和應(yīng)用程序依賴性的發(fā)現(xiàn)
• 映射階段，涉及創(chuàng)建遷移請求和目標(biāo)拓?fù)?/li>
• 部署、遷移和配置階段，涉及構(gòu)建目標(biāo)環(huán)境、應(yīng)用程序部署和移植
• 測試階段，遷移完成后在新環(huán)境中測試應(yīng)用程序，然后投入使用

下述 圖 2 提供顯示特定子目錄的遷移流。典型的遷移操作通常是以識別和盤點庫存 開始的，這一過程掃描作用范圍內(nèi)的服務(wù)器并識別潛在遷移候選對象。潛在候選對象列表在以下服務(wù)器/應(yīng)用程序資格 步驟中進一步細化。經(jīng)過詳細的可行性研究，選擇最終遷移候選對象，然后進行邏輯分組以形成 waves。接著合格的服務(wù)器/應(yīng)用程序的最終列表可帶進稱之為規(guī)劃和設(shè)計 的下一階段，在這一階段制定詳細的目標(biāo)拓?fù)浜瓦w移計劃。詳細設(shè)計定稿后，現(xiàn)在可以進入稱為服務(wù)器/應(yīng)用程序遷移 的實現(xiàn)階段，這一階段需要構(gòu)建目標(biāo)環(huán)境、遷移要遷移的應(yīng)用程序，并對其進行徹底測試。完成遷移后，新服務(wù)器投入使用，退役舊服務(wù)器之后緊接著進入最終的后期生產(chǎn) 階段。

圖 2. 詳細遷移階段
 
 

現(xiàn)在，我們將深入研究每個階段和活動以理解所涉及的步驟。#p#

識別和盤點庫存

第一步是識別哪個服務(wù)器需要遷移。您還要清點每個服務(wù)器上的服務(wù)器和軟件。

服務(wù)器識別

在遷移過程中，識別正確的資產(chǎn)集，比如要遷移的服務(wù)器，是非常重要的。按照項目架構(gòu)師和轉(zhuǎn)換項目辦公室雙方商定的工作負(fù)載管理規(guī)定，定義服務(wù)器作用范圍或超出作用范圍。在庫存驗證過程中，首要任務(wù)是盤點現(xiàn)有工作負(fù)載（是否基于 Intel 的、是否是大型機或其他平臺）。IBM Tivoli® Application Dependency Discovery Manager (TADDM) 是一個非常有用的產(chǎn)品，有助于了解服務(wù)器、應(yīng)用程序、網(wǎng)絡(luò)設(shè)備、軟件、配置文件、操作系統(tǒng)和其他 IT 基礎(chǔ)架構(gòu)組件之間的依賴關(guān)系。

您可以使用 表 1 中的樣例工作負(fù)載分布模型，初始化目標(biāo)環(huán)境的選擇標(biāo)準(zhǔn)。源服務(wù)器的實際利用率（在 CPU、RAM、Network I/O 方面）以及作為被選中候選對象的比例隱藏在這一表述中。然而，該模型可以與給定的合適利用率指標(biāo)同時使用，來決定一個服務(wù)器是否是一個遷移候選對象，或是否超出范圍。

表 1. 樣例工作負(fù)載分布模型

服務(wù)器和應(yīng)用程序資格

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

轉(zhuǎn)換規(guī)劃和可行性研究

1. 定義服務(wù)器復(fù)雜性以評估遷移工作量

   在將一個服務(wù)器或一組服務(wù)器識別為遷移到虛擬化目標(biāo)環(huán)境的潛在候選對象后，接下來的一個重要步驟就是對服務(wù)器進行分類，分為簡單、中等、復(fù)雜或非常復(fù)雜，具體取決于服務(wù)器硬件和軟件各種參數(shù)研究，圖 3 提供了一個選擇條件示例：

   圖 3. 基于服務(wù)器類型的遷移復(fù)雜性
    

   簡單服務(wù)器在單一 OS 實例中僅托管一個應(yīng)用程序或應(yīng)用程序的某一塊，比如，基于 Wintel 的單核或多核 CPU 服務(wù)器僅托管一個在 WebSphere 環(huán)境中運行的 Web 應(yīng)用程序。

   中等服務(wù)器可以托管 2 到 3 個單獨的應(yīng)用程序，但不需要定義多個虛擬機 (VM)，仍然在一個 OS 實例下運行，比如，運行一個應(yīng)用程序多個實例的服務(wù)器，諸如，在同一個 OS 下運行的 WebSphere Application Server (WAS)、DB2 和 IBM Http Server (IHS) 前端，通?？稍陂_發(fā)和測試環(huán)境中可以看到。

   復(fù)雜服務(wù)器通常是指含有多個 CPU 的服務(wù)器，可能定義了獨立邏輯分區(qū) (LPAR)。每個 LPAR 都有其自己的 OS 副本或多個 VM，這些 VM 都有獨立 OS 副本，并托管共享相同系統(tǒng)資源（比如，網(wǎng)絡(luò) I/O）的多個或不相關(guān)的應(yīng)用程序。一個示例是有多個 LPAR 的 System p®，運行獨立 AIX、p-Linux OS、或其他 OS 和 VMs，并運行多個共享同一網(wǎng)絡(luò) I/O 的應(yīng)用程序。

   非常復(fù)雜服務(wù)器通常是指具有多個有獨立 LPAR 的 CPU，每個 CPU 都有其自己的 OS 副本或多個有獨立 OS 副本的 VM，并托管多個共享相同系統(tǒng)資源（比如，網(wǎng)絡(luò) I/O）的不相關(guān)應(yīng)用程序，通過硬件或軟件負(fù)載共享或故障轉(zhuǎn)移與其他獨立服務(wù)器聚合。例如，運行一個獨立的 p-Linux 或 AIX 的 OS 并且托管 DB2 數(shù)據(jù)與 HACMP 集群的多個 LPAR。

2. 定義應(yīng)用程序復(fù)雜性以評估應(yīng)用程序遷移的工作量

   僅從服務(wù)器復(fù)雜性定義可能并不能完全理解遷移工作，因為服務(wù)器可能較簡單，但是產(chǎn)品、技術(shù)或運行的應(yīng)用程序可能比較復(fù)雜。從應(yīng)用程序的角度對復(fù)雜性進行分類對于理解遷移同樣重要。圖 4 表示應(yīng)用程序復(fù)雜性范圍，從簡單到非常復(fù)雜。

   圖 4. 基于應(yīng)用程序類型的遷移復(fù)雜性
    

   簡單應(yīng)用程序

   • WAS/Java 應(yīng)用程序，如果其中包括：
     • 更小的 JVM 或單個 JVM 實現(xiàn)
     • WAS AS-IS 移動，例如 WAS 6.1.x 到 6.1.x，WAS 5.1 到 6.0.x，6.1 到 7.0.x（沒有 API 變更）
     • 僅有 2 個應(yīng)用程序所有者的應(yīng)用程序服務(wù)器
     • 沒有本機語言代碼（例如，C/C++）來避免代碼矯正的應(yīng)用程序
   • IHS，如果它是：
     • 多數(shù)是靜態(tài)頁面，比如 HTML、圖像、JavaScript 以及少量 CGI 腳本、Perl 模塊、或直接調(diào)用數(shù)據(jù)庫和硬編碼 IP 依賴項
   • Domino® 如果它是：
     • .NSF 數(shù)據(jù)庫中的一個獨立應(yīng)用程序，與外部數(shù)據(jù)源或腳本無交互。

   中等應(yīng)用程序總是以個案為基礎(chǔ)，根據(jù)卷、用戶基礎(chǔ)、架構(gòu)、中間件產(chǎn)品，以及所有這些的綜合在簡單和復(fù)雜之間進行評估。例如，WebSphere Commerce (WCS) 無需任何自定義 JSP 或自定義模塊從 WCS 6.x 遷移到 6.x，就是一個中等遷移，但是從自定義 JSP 或程序模塊增加，以及版本從 5.5/5.6 升級到 6.x 那一刻開始，就趨向于復(fù)雜或非常復(fù)雜遷移，具體取決于評估分析工作。

   • 中等復(fù)雜遷移的其他示例包括：
     • 需要代碼重寫但卻只需將一個 API 從 1.4.2 更改到 1.5（JRE 版本）的簡單 J2EE 應(yīng)用程序遷移
     • 類型 2 到類型 4 驅(qū)動程序的更改
     • 使用數(shù)據(jù)庫或 Java 連接外部數(shù)據(jù)源 [包括 Lotus Enterprise Integrator® (LEI) 的使用] 的 Domino 應(yīng)用程序
     • 使用適用于目標(biāo)環(huán)境的工具開發(fā)的自定義應(yīng)用程序（需要較少移植）

   復(fù)雜應(yīng)用程序

   • 帶分區(qū)數(shù)據(jù)庫或大型的數(shù)據(jù)庫（跨 DC 遷移）。指標(biāo)可能包括：
     • 1TB 以上的存儲設(shè)備附加到該服務(wù)器
     • 數(shù)據(jù)庫需要支持 365x24x7 小型維護窗口
     • 目前實現(xiàn)災(zāi)難恢復(fù) (Disaster Recovery, DR) 數(shù)據(jù)庫
     • 數(shù)據(jù)倉儲數(shù)據(jù)庫需要高 CPU/IO 資源
     • 帶多個實例的服務(wù)器，比如在框上有 3 個或以上的實例
   • WAS/Java 應(yīng)用程序：WAS 版本 4.0 或 5.0 遷移到 6.0/6.1/7.0（由于架構(gòu)更改），使用最小的定制實現(xiàn) WCS 5.5/5.6 到 6.x 的遷移，無需定制使用 PDM 或 WCM 實現(xiàn)門戶遷移。
   • IHS：靜態(tài)內(nèi)容和動態(tài)內(nèi)容的混合，大型應(yīng)用程序后端與復(fù)雜重寫規(guī)則和復(fù)雜后端調(diào)用的依賴關(guān)系，CGI/Perl 腳本與目錄或外部 Perl 模塊的依賴關(guān)系，以不良編碼標(biāo)準(zhǔn)編寫的 CGI 代碼（需要重寫）
   • Domino®：第三方應(yīng)用程序代碼或擴展器，在門戶網(wǎng)站中使用的 Domino 元素，使用低級別 Domino API 或 OS API，將一個中等復(fù)雜的 Domino 應(yīng)用程序從 Windows® 移到 Linux（或 System z 上的 Linux）。

     通常，如果一個應(yīng)用程序目前正在實施 DR，可以認(rèn)為遷移是復(fù)雜的，第三方應(yīng)用程序代碼，自定義代碼有數(shù)以千計的模塊需要移植，但是如果使用同一個開發(fā)環(huán)境，自定義代碼需要變更開發(fā)環(huán)境（比如，Visual Age to GNU 工具套件）

   非常復(fù)雜
   • Databases：從 AIX 遷移到 zOS 的 DB2 數(shù)據(jù)庫，這類遷移需要大量重寫實現(xiàn)文件系統(tǒng)更改，DPF 數(shù)據(jù)量超過 1TB，跨數(shù)據(jù)庫集成，比如，ORACLE 到 DB2, Informix 到 DB2，zLinux 上不支持 DB2 擴展器的遷移。
   • WebSphere：目前，運行在舊版 WebSphere（比如 WAS 3.5 或 4.0）上的應(yīng)用程序，需要大量代碼重寫以便將應(yīng)用程序代碼部署在 WAS 7.0 中，WebSphere Process Server 中使用 WebSphere Integration Developer (WID) 的大量工作流定制。
3. 數(shù)據(jù)庫，如果其中包括：
   • 較小的數(shù)據(jù)庫
   • Intra-Data Center (DC) 遷移
   • 有單個實例實現(xiàn)的服務(wù)器
   • 有 2 個應(yīng)用程序所有者的服務(wù)器
   • 沒有本機語言代碼來避免代碼矯正的數(shù)據(jù)庫
   • 有周末停用窗口可供使用的應(yīng)用程序

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

Wave 規(guī)劃：在一個組中遷移

在 圖 5 中，實際遷移復(fù)雜性級別由應(yīng)用程序和服務(wù)器復(fù)雜性共同決定。

圖 5. 協(xié)調(diào)服務(wù)器復(fù)雜性和應(yīng)用程序復(fù)雜性
 

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

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

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

1. 解決方案啟動和規(guī)劃：執(zhí)行可行性研究并制定關(guān)鍵技術(shù)決策。確定目標(biāo)環(huán)境。
2. 執(zhí)行和控制：創(chuàng)建一個詳細計劃來執(zhí)行和控制每個合格應(yīng)用程序的遷移。
3. 投入使用并關(guān)閉：最后，將新環(huán)境投入使用，隨即關(guān)閉項目。
   表 2. Wave 規(guī)劃階段 

#p#

規(guī)劃和設(shè)計

作為規(guī)劃和設(shè)計階段的一部分，您和客戶應(yīng)該總結(jié)此服務(wù)器和應(yīng)用程序行為以實現(xiàn)遷移。根據(jù)評估，設(shè)計一個技術(shù)解決方案。

應(yīng)用程序評估

客戶的應(yīng)用程序評估通過問卷調(diào)查，緊接一個關(guān)鍵利益涉眾和應(yīng)用程序團隊技術(shù)機組成員會議的形式進行的。準(zhǔn)備一個應(yīng)用程序資產(chǎn)問卷調(diào)查 (Application Assessment Questionnaire, AAQ) 工作產(chǎn)品以獲取即將遷移的作用服務(wù)器/應(yīng)用程序的服務(wù)器行為和應(yīng)用程序行為。

AAQ 中用于用戶數(shù)據(jù)捕獲的關(guān)鍵屬性有：

服務(wù)器行為：

• 服務(wù)器名 (FQDN)
• 集群 (yes/no)
• 集群服務(wù)器名
• 環(huán)境運行（生產(chǎn)/分階/測試/開發(fā)）
• 服務(wù)器位置（城市/數(shù)據(jù)中心/主機環(huán)境）
• 服務(wù)器類型（Web/應(yīng)用程序/數(shù)據(jù)庫/混合）
• 網(wǎng)絡(luò)域（內(nèi)部/外部/DMZ）
• 服務(wù)器 IP 地址
• 硬件制造商
• 模型類型
• 處理器數(shù)量
• 內(nèi)存信息
• 存儲信息
• 物理/虛擬
• 服務(wù)器利用率
• 平均利用率
• 峰值利用率
• 峰值時間
• 服務(wù)器配置歷史

應(yīng)用程序行為：

• 在服務(wù)器上運行的應(yīng)用程序名稱是什么？
• 提供對該應(yīng)用程序及其業(yè)務(wù)功能的簡要描述。包括它所做的以及整個操作。
• 該應(yīng)用程序是一個大型企業(yè)應(yīng)用程序組的一個組件或一部分嗎？
• 如果是，該應(yīng)用程序和其他企業(yè)應(yīng)用程序組 (Enterprise Application Group, EAG) 組件應(yīng)用程序需要聯(lián)鎖嗎（例如，該應(yīng)用程序或其他 EGA 組件應(yīng)用程序有緊密耦合的依賴項或功能，必須被視為其他項目活動的一個單元）？
• 該應(yīng)用程序是內(nèi)部開發(fā)的？還是從獨立軟件供應(yīng)商處購買的現(xiàn)成的？選擇一個：
  • 定制/本土
  • COTS- 無修改
  • COTS- 細微修改
  • COTS- 重大修改
• 主要應(yīng)用程序軟件供應(yīng)商以及所用軟件版本是什么？
• 該應(yīng)用程序目前運行的平臺是什么？（Windows、Linux、AIX、Solaris，或其他）
• 是首選平臺嗎？考慮或需要其他平臺嗎？
• 該應(yīng)用程序所有簽署文件（比如技術(shù)文件或 UAT）上的 Account Focal，DPE (Delivery Project Executive) 或者指定代理是誰？
• 提供的圖紙或文檔有助于全面了解應(yīng)用程序的運行嗎？
• 重大更改、升級、或規(guī)劃的關(guān)鍵項目是針對該應(yīng)用程序或其主服務(wù)器嗎？
• 對該應(yīng)用程序進行分類，選擇一個：
  • 單機應(yīng)用程序
  • 應(yīng)用程序 & 數(shù)據(jù)庫
  • 基礎(chǔ)架構(gòu) / 實用程序
  • 單機 Web
  • Web 應(yīng)用程序 & 數(shù)據(jù)庫
• 該應(yīng)用程序使用一些常見（共享）服務(wù)嗎？如果是，請詳細描述（例如：防火墻、代理或重定向，認(rèn)證、Lotus Notes® 復(fù)制、MQ Series、Web 認(rèn)證）。通常，面向 Web 的應(yīng)用程序可以顯示所涉及的常見服務(wù)。

要獲取網(wǎng)絡(luò)信息和應(yīng)用程序詳細信息、及其未來策略和發(fā)展，還需要更多關(guān)鍵信息。此外，要獲取部署在特定應(yīng)用程序的特定軟件的詳細信息，比如數(shù)據(jù)庫 (DB2) 中間件 (WebSphere Application Server) 以及消息傳遞 (WebSphere MQ)，可能還需要單獨問卷調(diào)查。#p#

技術(shù)解決方案設(shè)計

技術(shù)解決方案設(shè)計是轉(zhuǎn)換管理程序最關(guān)鍵階段之一，因為存庫輸入驗證、服務(wù)器和應(yīng)用程序行為，以及客戶會議成果都將反饋到應(yīng)用程序解決方案設(shè)計中。

在 Technical Solution Design (TSD)（一個基于 Excel 的工作產(chǎn)品）中捕獲的解決方案設(shè)計關(guān)鍵活動有：

• 解決方案的高度概括。
• 特定于 TSD 假設(shè)和已確定風(fēng)險的記錄。
• 解決方案描述，包括架構(gòu)設(shè)計和應(yīng)用程序影響。
• 一個包含所有源服務(wù)器信息的表格。
• 一個應(yīng)用程序到服務(wù)器的映射表，對于每個應(yīng)用程序及服務(wù)器（應(yīng)用程序在上面執(zhí)行）都包含一個條目。這是一個多對多的關(guān)系。
• 一個包含所有目標(biāo)服務(wù)器信息的表。
• 一個目標(biāo)環(huán)境描述和說明。
• 一個解決方案描述，包含架構(gòu)決策和備案考量。
• 特定假設(shè)和風(fēng)險。

某一架構(gòu)決策場景圖解

在進行技術(shù)解決方案設(shè)計時，需要將目標(biāo)環(huán)境、目標(biāo)平臺、目標(biāo)拓?fù)浣Y(jié)構(gòu)，以及與目標(biāo)環(huán)境的兼容性方面考慮到關(guān)鍵架構(gòu)決策中。以下 3 個示例是：

• 示例 1：Linux 虛擬環(huán)境中產(chǎn)品的兼容性
• 示例 2：Linux 環(huán)境的可移植性因素
• 示例 3：Linux 環(huán)境數(shù)據(jù)中心中的運營情況

示例 1：Linux 虛擬環(huán)境中產(chǎn)品的兼容性

• 主題范圍：Linux 虛擬平臺中兼容性的解決方案架構(gòu)
• 問題或問題陳述：遷移的范圍是構(gòu)建一個 Linux 棧，該 Linux 棧將被復(fù)制到 3 個集群環(huán)境，但不限于：
  • 開發(fā)
  • 測試
  • 生產(chǎn)

  J2EE 應(yīng)用程序?qū)⑾嗬^部署在這 3 個環(huán)境中。

• 假設(shè)：J2EE 容器是 WebSphere Application Server (WAS)。
• 備用方案：
  1. 首先，使用 OS 和 WAS 中間件構(gòu)建開發(fā)環(huán)境，然后應(yīng)用克隆技術(shù)創(chuàng)建測試和生產(chǎn)環(huán)境
  2. 使用 OS 和 WAS Hypervisor Edition 在 Linux 中間件上創(chuàng)建開發(fā)環(huán)境，然后應(yīng)用克隆技術(shù)創(chuàng)建測試和生產(chǎn)環(huán)境
• 決策：與備用方案 2 一起使用。
• 理由：如果您使用 WAS Standard 或 Enterprise 版本構(gòu)建 Linux OS，當(dāng)前環(huán)境的主機名和 IP 地址的引用將在在安裝過程中集成，并且耦合的更為緊密。從開發(fā) Linux 映像中構(gòu)建一個新克隆后，WAS 并不能在新的 Linux 內(nèi)置映像中運行，因為它在很多地方，包括單元名和 WAS 配置文件中的其他地方，存儲了舊的主機名和 IP 引用。刪除配置文件以及創(chuàng)建一個新配置文件可能會增加遷移工作量。

  為了避免這類問題，在 Linux 上選擇 WAS Hypervisor 版本，因為它與當(dāng)前環(huán)境不是緊耦合的，可以幫您減少編寫代碼和刪除依賴項的手動操作。

示例 2：Linux 環(huán)境的可移植性因素

• 主題范圍：平臺選擇上的解決方案架構(gòu)示例。
• 問題或問題陳述：比較 AIX 和 Linux on System z 環(huán)境中遷移應(yīng)用程序和后臺數(shù)據(jù)庫服務(wù)器。所有服務(wù)器應(yīng)用程序和 DB2 后臺組件目前都運行在非虛擬化 AIX 環(huán)境中。從可擴展性和運營成本角度來看，不管是在 Linux 還是在 AIX 上，客戶都想將服務(wù)器移到一個虛擬環(huán)境以獲取虛擬化的優(yōu)勢和一個更好的計算平臺。
• 假設(shè)：Linux 虛擬化平臺和 AIX 虛擬化平臺都可用。Linux 定價模型比 AIX 環(huán)境更具經(jīng)濟吸引力。
• 備用方案：
  1. 在 AIX 中構(gòu)建所有服務(wù)器內(nèi)置組件，是虛擬化的，因為源平臺是 AIX。這涉及的遷移相關(guān)風(fēng)險最小
  2. 在 Linux 中構(gòu)建所有服務(wù)器內(nèi)置組件，是虛擬化的，因為它對客戶來說最具經(jīng)濟效益。
  3. 在 AIX 中構(gòu)建后臺數(shù)據(jù)庫，在 AIX 和 Linux 中構(gòu)建前端組件，是虛擬化的。
• 決策：與備用方案 3 一起使用。
• 理由：DB2 組件對于 System z 上的 Linux 而言是最理想的，因為主機架構(gòu)對于管理那些高 I/O 操作期望且 DB2 數(shù)據(jù)庫后臺本身就有比應(yīng)用程序服務(wù)器組件更高的I/O 的工作負(fù)載來說裝備更完善。然而，在 DB2 后臺組件中客戶也需要集群，這是在 AIX/pSeries 中保持 DB2 所必需的，因為：
  • 相比在 zLinux 中新構(gòu)建的 Tivoli Storage Automation (TSA) 和 DB2 HADR，HACMP 是一個成熟的集群工具，然而 TSA 在 z 測試系統(tǒng)上測試并不是很好。
  • 對于 DB2 服務(wù)器來說，持續(xù)高峰值利用率（超過 75%）與 pSeries® 硬件創(chuàng)建一個密切的關(guān)系。擁有低 CPU 密集工作負(fù)載的 WAS 組件被認(rèn)為適用于 System z 上的 Linux。

示例 3：Linux 環(huán)境數(shù)據(jù)中心的操作方面

• 主題范圍：數(shù)據(jù)中心選擇解決方案架構(gòu)示例。
• 主題：操作模型和主機位置。在 Poughkeepsie Data Center 或 Boulder Data Center 中構(gòu)建基礎(chǔ)架構(gòu)。
• 問題和問題陳述：從當(dāng)前位于 Southbury 中的 IBM 數(shù)據(jù)中心將服務(wù)器工作負(fù)載遷移到 Poughkeepsie、NY 或 Boulder CO 中的新虛擬化 Linux 環(huán)境。
• 備用方案：
  1. Poughkeepsie
  2. Boulder
• 決策：。與備用方案 1 一起使用。
• 理由：
  • 就未來發(fā)展模式而論，服務(wù)器容量（高級別）和存儲容量需求與 z9 和 z10 可用性以及 Poughkeepsie 共享容量十分匹配。
  • Southbury 和 Poughkeepsie 緊密鄰接有助于減緩數(shù)據(jù)遷移。
  • Southbury 和 Poughkeepsie 同時區(qū)優(yōu)勢使操作復(fù)雜性最小化。

關(guān)于容量規(guī)劃和服務(wù)器分級需要注意的一點是：

應(yīng)用容量管理技術(shù)來確定最優(yōu)分配或在新整合服務(wù)器環(huán)境中對資源進行分級，以及確保預(yù)期工作負(fù)載的性能。目標(biāo)服務(wù)器硬件的適當(dāng)分級對于確保以下性能至關(guān)重要：

• 性能
• 未來發(fā)展
• 固結(jié)比
• 經(jīng)濟效益

圖 6 顯示了這些規(guī)劃和分級因素的相互關(guān)系。
 

圖 6. 容量規(guī)劃和服務(wù)器分級因素
 

服務(wù)器分級是基于評估/庫存盤點階段執(zhí)行的數(shù)據(jù)收集的。例如，您可以分析其當(dāng)前硬件模型、CPU 性能指標(biāo)，以及現(xiàn)有硬件中可用內(nèi)核和芯片數(shù)量，然后再計算每個服務(wù)器的 RelativePerformance 值 (rPerf) 分級。查找以下關(guān)鍵項：

• 服務(wù)器制造
• 服務(wù)器模型
• CPU 數(shù)量
• CPU 內(nèi)核
• CPU 速度
• CPU 利用率
• 已安裝的 RAM
• 已使用的 RAM
• 已分配和使用的存儲空間

評估是直接基于其他服務(wù)器的峰值 CPU 利用率，根據(jù)工作負(fù)載特征進行調(diào)整。服務(wù)器合并分級評估精確性取決于提供的輸入。對于不準(zhǔn)確的評估而言，最常見的是由于錯誤的當(dāng)前服務(wù)器 CPU 利用率所導(dǎo)致的。每個單獨服務(wù)器的峰值 CPU 利用率和跨所有服務(wù)器（分級所用的）的峰值需求模式對于一個好的評估來說是至關(guān)重要的。如果峰值負(fù)載是的免費的，那么它們可能發(fā)生在不同時段，服務(wù)器容量需求可能明顯少于峰值并發(fā)時的容量需求。工作負(fù)載特征的變化也是一個重要的因素。工作負(fù)載特征變化可能會導(dǎo)致在分級結(jié)果中出現(xiàn)一個 4x 的差量。不正確的或不精確的輸入使得分級結(jié)果無效。檢查分級中使用的輸入也是非常重要的，這些輸入精確反映當(dāng)前服務(wù)器的工作負(fù)載和 CPU 利用率。

正確收集峰值 CPU 利用率也是很重要的。它們表示的應(yīng)該是 15 - 30 分鐘峰值需求間隔的平均 CPU 利用率，而不是瞬時峰值。如果客戶的平均 CPU 利用率數(shù)據(jù)是以 8 小時或一天為單位，可能需要應(yīng)用峰均比 (peak-to-average ratio) 來正確反映峰間 CPU 利用率。

基準(zhǔn)測試的分級參數(shù)包括：

• 應(yīng)用程序
• 性能監(jiān)控器
• 數(shù)據(jù)文件（數(shù)據(jù)集）和數(shù)據(jù)庫
• 腳本（用戶命令）或作業(yè)
• 工作集大小
• 終端模擬
• 用戶群體大小
• 平均思考時間和思考時間分布
• 事務(wù)率
• 響應(yīng)時間標(biāo)準(zhǔn)
• 操作方法論

最佳實踐包括：

• IBM 使用來自調(diào)查問卷的信息作為分級輸入
• 分級模擬將客戶計劃業(yè)務(wù)量轉(zhuǎn)換成潛在工作負(fù)載
• 潛在生產(chǎn)的 CPU、內(nèi)存和風(fēng)險需求
• 實際工作負(fù)載的功能評估
• 理解分級指導(dǎo)方針、方法論和工具
• 驗證/區(qū)別分級、容量規(guī)劃、或性能分析練習(xí)和每個獨立場景中所用的工具和方法論之間的分級請求，以及如何運用到此客戶環(huán)境中
• 使用 IBM 分級工具（如果適用），或者 ISV 分級方法論/工具。確保使用最新版分級工具
• 理解微分區(qū)如何影響分級，并在輸出結(jié)果中進行解釋
• 提供動態(tài)余量和多個分級，包括增長預(yù)測
• 工具精確度：和預(yù)期的一樣好 +/- 30%
• 獲取一個容積數(shù)據(jù)點，確保是簽字同意的，否則，可能觸發(fā)一個多米諾效應(yīng)，導(dǎo)致錯誤分級
• 考慮批處理的并行影響

分級工具參考：

• IBM 專有分級工具： VISIAN

  VISIAN 是一個基于 Excel 的 IBM 內(nèi)部工具，用于獲取源服務(wù)器技術(shù)配置（比如 CPU 和內(nèi)存的數(shù)量、類型和速度）、源服務(wù)器資源使用情況（比如 CPU 利用率，內(nèi)存利用率和 NW 利用率等），并將虛擬化層特性、限制和日常開支都考慮在內(nèi)。同時也支持 Mware ESX、MSVS、Virtual Iron 和 pSeries hypervisorsis。

  VISIAN 計算以下內(nèi)容：

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

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

  2. Novell PlateSpin PowerRecon

     Novell 的 PowerRecon 工具集成了遠程數(shù)據(jù)收集、工作負(fù)載分析以及規(guī)劃和場景比較功能以實現(xiàn)服務(wù)器整合。它將自動分析以下工作負(fù)載：CPU、磁盤、內(nèi)存和網(wǎng)絡(luò)。

  3. CiRBA

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

  4. VMware Guided Consolidation

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

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

框架布局目標(biāo)拓?fù)洌?/strong>