了解 System p™ virtualization PowerVM™ 企業版的動態分區遷移特性。看看如何將動態分區遷移特性應用到 DB2® 部署中，以及它如何幫助您遷移 AIX® 和 Linux® 分區，並且將一個物理服務器中的應用程序托管到另一個兼容的物理服務器。動態分區遷移可以實現硬件維護、固件更新、系統維護，以及應用程序的動態服務器整合等工作在不停機的情況下進行。您還將了解存儲網絡區域（Storage Area Network，SAN）和 DB2 的設置、配置、最佳實踐和性能。
簡介
System p 虛擬化技術提供了一組豐富的平台部署特性。這些特性涵蓋簡單的資源分離（resource isolation）和各種強大的高級功能，包括服務器資源分區、自動動態資源重分配和工作負載管理。
動態分區遷移是基於 POWER6™ 處理器的系統的新特性，旨在實現兼容系統之間的邏輯分區遷移（LPAR 或分區）。動態分區遷移使用了一個簡單的自動化過程，該過程從原服務器將移動 LPAR 的運行狀態（屬於移動 LPAR 的主內存頁面）和配置信息（例如虛擬網絡接口、虛擬 Small Computer System Interface (SCSI) 接口或 LPAR 配置文件）傳遞給目標服務器，這個過程不會中斷被托管的操作系統、網絡連接和應用程序。
動態分區遷移使管理員能夠更好地在數據中心控制系統資源。它提高了工作負載部署和管理的靈活性。而在以前，由於維護時窗有限，應用程序可用性的要求嚴格，或者服務級別協議不允許應用程序停止，因此很難實現這種靈活性。
遷移過程可以在關閉狀態下的分區執行，也可以在一個活動分區中執行。可以使用兩種遷移類型：
靜止遷移 邏輯分區被關閉並遷移到目標系統。 活動遷移 執行分區遷移時可以提供服務，而且不會中斷用戶活動。
在過去執行維護活動需要停機，但是現在不會中斷服務。活動包括（但不限於）：
預防性硬件維護
硬件升級
需要在服務器之間重新分配分區的服務器整合
DB2 V9.5 是行業領先的信息管理平台。DB2 V9.5 的設計目標是利用 System p 虛擬化技術。一些新的特性使 DB2 非常適合虛擬化環境，例如主機動態資源感知（host dynamic-resource awareness）、配置參數在線調優和自調優內存管理（STMM）。
實現動態分區遷移的先決條件
本文要求您了解 System p 虛擬化概念、存儲管理、網絡管理知識，並具備基本的系統管理技能。
動態分區遷移在操作系統級別、固件級別、DB2 數據存儲布局和網絡接口方面有特殊的要求。在設置遷移時，無論它是活動的還是靜止的，都需要提前仔細安排部署。有時候通過采取額外的步驟可以使某個分區具有遷移資格，例如使用動態邏輯分區（DLPAR）操作刪除物理適配器（非虛擬適配器）。
只有滿足以下需求時，分區才可以執行遷移。對邏輯分區執行遷移一般需要滿足以下要求：
使用同一個硬件管理控制台（Hardware Management Console，HMC）控制的兩個基於 POWER6 處理器的系統。支持一個可選的冗余 HMC 配置。
目標系統的可用內存和處理器的數量至少要和遷移分區當前使用數量相同。在使用分區配置文件啟動後，DLPAR 操作可能會在運行時改變分區資源（包括內存、處理器和適配器）。因此，分區資源的當前數量可能不同於分區配置文件中指定的 “理想” 數量。
一個分區可以具有多個配置文件。在操作系統啟動時，系統管理員選擇用來啟動分區的配置文件。通常，分區配置文件指定了操作系統啟動時的資源需求，例如內存數量、處理器權限、適配器等等。分區文件還指定了最小和最大內存量，以及虛擬處理器的數量和處理器權限。
操作系統、應用程序（DB2）安裝、DB2 實例數據和 DB2 表數據必須位於外部存儲子系統上的 Virtual I/O 存儲中。
遷移分區的所有網絡和磁盤訪問必須通過一個或多個 Virtual I/O Servers (ViOS) 進行虛擬化。
在進行遷移時，遷移分區不會使用其他的物理適配器，例如串口 I/O 適配器、SCSI 適配器等。如果有任何物理適配器屬於進行遷移的分區，那麼遷移前的驗證階段將會失敗。
兩個系統上的 ViOS 都必須配置一個共享的 Ethernet 適配器，通過它橋接遷移分區使用的 Ethernet 網絡。
兩個系統上的 ViOS 必須能夠向遷移分區使用的所有存儲資源提供虛擬訪問。
圖 1 展示了實現遷移的總體結構。每個基於 POWER6 的系統都配置了一個 VIOS 分區。遷移分區只能通過虛擬適配器訪問網絡和磁盤資源。目標系統上的 ViOS 被連接到同一個網絡，並配置為訪問遷移分區使用的相同存儲。
圖 1. 分區遷移基礎架構
動態分區遷移配置
本節提供動態分區遷移的配置設置參考清單。一般而言，檢驗該清單中的條目的一個方法是導航到各自的 Property 屏幕。例如，對於 Systems 清單中的條目，導航到 System -> Property screen。對於 ViOS 分區，則導航到它的 Property 屏幕。紅皮書 PowerVM Live Partition Mobility on IBM System p（參見 參考資料）詳細介紹了檢驗和修改這些設置的方法。
系統
源服務器和目標服務器必須至少位於基於 POWER6 處理器架構的系統中。兩個系統必須使用同一個 HMC 控制。動態分區遷移要求使用 HMC Version 7.3.2 或更高版本。
源系統和目標系統的內存區域大小，也稱為邏輯內存塊（LMB）大小，必須相同。可以在 HMC 上進行檢驗，方法是導航到主機系統的 PropertIEs 屏幕的 Memory 選項卡。參見下面的 圖 2。
要實現遷移，目標系統不能使用電池作為電源。
目標系統必須與主機遷移分區具有相同數量的內存和處理器（在活動分區配置文件已經指定）。
圖 2. 在 HMC 上檢驗系統內存區域（LMB）大小
ViOS 分區
在源系統和目標系統上至少要安裝一個版本為 1.5 的 ViOS 發行版或更高版本。
在源系統和目標系統 VIOS 上必須同時啟用分區屬性 “Mover service partition” (MSP) 。啟用方法有二個：在創建 ViOS 分區配置文件時選擇復選框，或在稍後導航到分區屬性並選擇復選框，如 圖 3 所示。
對於啟用了 MSP 的 ViOS，必須定義和配置一個 Virtual Asynchronous Service Interface (VASI) 設備，將它作為一個有效的 MSP 替補。
遷移分區使用的虛擬磁盤需要使用設備備份；它們不應屬於 ViOS 上的任何邏輯卷組的一部分。
圖 3. 啟用或檢查 mover service partition 的狀態
遷移分區
AIX 5.3 technology level 07 或更高。
確保建立了 Resource Monitoring and Control (RMC) 連接。
需要在遷移分區中禁用冗余錯誤路徑報告。
遷移分區不能有任何必要的虛擬串口適配器，為 HMC 預留的兩個除外。
遷移分區不應屬於分區工作負載組的一部分。分區工作負載組是一個邏輯分區的集合，其中的資源由一個工作負載管理應用程序統一管理。
工作負載管理應用程序可以平衡邏輯分區組內的內存和處理器資源，並且不需要 HMC 的介入。
遷移分區不能使用 BarrIEr Synchronization Register (BSR) 陣列。
遷移分區不能使用大內存頁（16GB）。然而可以使用 64KB 和 16MB 大小的 AIX 頁面。
遷移分區沒有物理或專用的 I/O 適配器和設備。
遷移分區不能配置有任何邏輯主機 Ethernet 適配器（LHEA）設備。
主機 Ethernet 適配器（HEA）是物理 Ethernet 適配器，它直接集成到托管系統中的系統（GX+ 總線）中。HEA 為 Ethernet 連接提供高吞吐量、低延遲和虛擬化支持。HEA 與其他類型的物理 Ethernet 適配器具有相同的用途。例如，可以使用 HEA 建立到一個邏輯分區的控制台連接。
外部存儲
遷移分區用作虛擬磁盤的存儲區域網絡（SAN）磁盤必須分配給源和目標虛擬 I/O 邏輯分區。
ViOS 上的共享物理卷的 reserve_policy 屬性必須設置為 no_reserve。
物理卷必須具有相同的惟一標識符、物理標識符或一個 IEEE 卷屬性。這可以通過 AIX lsattr 命令進行檢驗。
VIOS 在每次啟動時必須能夠准確地識別物理卷，即使這時 SAN 進行了重新配置或適配器發生改變。由於 SAN 進行了重新配置，物理卷屬性可能在系統重啟後會發生改變，例如名稱、地址和位置。然而，ViOS 必須能夠識別出這是同一個設備並更新虛擬設備映射。
要將物理卷作為虛擬設備導出，物理卷必須使用惟一標識符（UDID）、物理標識符（PVID）或 IEEE 卷屬性其中之一。
遷移分區必須能夠通過 ViOS 訪問存儲區域。
目標 ViOS 必須具有足夠的空閒的虛擬槽（slot）來創建托管遷移分區所需的虛擬 SCSI 適配器。
遷移分區必須同時從源環境和目標環境訪問 SAN 中相同的物理存儲。
網絡方面的注意事項
在源 VIOS 和目標 ViOS 上必須同時配置一個共享 Ethernet 適配器。
在遷移分區上必須配置一個虛擬 Ethernet 適配器。
實際遷移
從最終用戶的角度來看，活動遷移過程只需在 HMC 圖形用戶界面上單擊幾下。而在幕後，需要做大量工作將移動 LPAR 狀態和配置信息從源系統傳遞到目標系統（包括移動 LPAR 中配置的數千兆內存），同時保持 LPAR 的所有服務可以正常工作，並維護源系統和目標系統之間的一致性。一次活動遷移包括：
一個驗證階段，確保達到遷移標准。驗證階段實際上檢驗是否滿足上面列出的先決條件。
在目標系統中創建新的 LPAR。
在兩個 VIO 服務器上設置 MSP。
在目標 VIO 服務器上設置虛擬 SCSI 適配器。
從源系統將內存復制到目標系統。
在源系統中暫停 LPAR 並在目標系統上重新運行。
從源 VIO 服務器刪除虛擬 SCSI。
通知遷移分區和 VIO 服務器遷移完成。
從源系統刪除 LPAR。
測試計劃
測試計劃列出了測試環境和測試用例。
測試環境
下表列出了概念證明中使用的系統、存儲和軟件。
表 1. 環境
硬件 系統：兩個系統，每個 System p 570 使用 4x 4.7 GHz POWER6 內核和 IBM PowerVM 企業版
使用的內核數：4
使用的內存：9 GB
固件版本：EM320_031
HMC 版本：V7R3.2.0.0
磁盤特征：
磁盤數：28 RAID5 FCP LUN。196 外部磁盤（140 個用於保存數據 + 56 個用於保存事務日志）
類型，大小，速度：FCP，18 GB，15 000 RPM
軟件 操作系統：AIX 5L v5.3 TL07，64 位內核數據庫：DB2 9.5 for AIX，64 位
工作負載 特征：在線事務處理（OLTP）數據庫大小：~100 GB
測試用例
測試用例的設計目的是在活動遷移中理解以下 DB2 性能特征。DB2 服務器實例在進行遷移時將繼續為客戶機提供服務。
在遷移各個階段的性能影響。
觀察執行活動遷移期間客戶機或終端用戶感受到的吞吐量。
在目標服務器上多長時間重新恢復一次原始吞吐量。
遷移階段的負載影響。
遷移設置
圖 4 展示了 DB2 使用的設置和動態分區遷移的性能特征。在整個測試過程中，圍繞最佳實踐進行的設置可以確保簡化管理並提供高性能吞吐量。如前所述，遷移的准備過程需要謹慎的存儲和網絡規劃。
圖 4. DB2 動態分區遷移的硬件設置
硬件設置
本節介紹了要啟動活動遷移所需的系統、存儲和網絡設置。
上面的 圖 4 中的系統 #1 被作為源系統。LPAR（運行一個 DB2 服務器實例）最初在該系統中定義。系統 #2 被設置為接收一個遷移 DB2 服務器 LPAR。DB2 服務器 LPAR 沒有任何屬於它的物理資源（包括物理適配器或邏輯磁盤）。這是實現成功遷移的主要要求。所需的網絡和存儲接口分別是一個共享 Ethernet 適配器（SEA）和一個虛擬 SCSI。DB2 網絡客戶機通過 SEA 連接到 DB2 服務器，而 DB2 服務器數據則使用虛擬 SCSI 適配器斷開 DS4500 的托管。
存儲系統使用一個 SAN 交換機連接，以便連接到目標系統和源系統。配置 SAN 存儲的重要一步是確保恰當地聲明全球通用端口號（worldwide port numbers，WWPN），以便目標系統和源系統可以訪問數據（但是，在任何時刻，只能有一個系統訪問存儲系統）。啟用動態分區遷移配置 詳細介紹了設置和配置步驟。
PowerVM 企業版是一個獨立頒發許可的需要支付費用的特性，必須在兩個系統上啟用該特性才能實現分區遷移。AIX 操作系統的最低需求為版本 5.3 technology level 07。還需要特定的最低要求的 HMC 和固件版本。有關該環境的完整細節請參見 測試環境。
您必須將 AIX 操作系統安裝到由 SAN 存儲設備備份的虛擬存儲上，因為這樣 AIX 安裝介質（具體指 rootvg）就會隨遷移分區一起移動。
要減少遷移的延遲時間，建議在源系統和目標系統兩端使用高速網絡基礎設施，例如 Gigabit 或 10 Gigabit 接口。要改善網絡吞吐量，如果可以的話，使用相同的高速 Ethernet 交換機連接源系統和目標系統以及 HMC，如 圖 4 所示。
DB2 設置
正如需要在 SAN 存儲上安裝 AIX 一樣，DB2 安裝位置、DB2 實例目錄、DB2 編目和所有其他存儲（包括 DB2 表空間容器）也必須位於 SAN 存儲。DB2 數據庫不能使用本地存儲設備。
確保 DB2 實例沒有使用任何物理網絡適配器、磁盤適配器或設備。遷移不能使用屬於移動 LPAR 的物理適配器。物理適配器在遷移前 可以通過 DLPAR 操作刪除。如果 DB2 正在訪問這類設備，那麼刪除操作 DLPAR 將會失敗，從而造成遷移驗證失敗。避免這種情況的最佳方法是遵守一條規則：不要使用屬於 LPAR 的物理適配器。所有適配器（網絡、存儲）必須是虛擬適配器。
如果 LPAR 使用大 AIX 內存頁（16GB 頁面大小），則不支持分區遷移。必須確保 DB2 沒有使用 AIX 的大內存頁配置；例如，使用 DB2 注冊變量 DB2_LARGE_PAGE_MEM=DB:16GB。分區遷移支持 AIX 4KB、64KB 和 16MB 頁面大小（受 DB2 支持）。
DB2 數據庫管理器配置參數 INSTANCE_MEMORY 控制 DB2 實例使用的內存的數量。如果遷移的目的是為了目標系統上的 DB2 實例分配更多的內存（通過在遷移後執行 DLPAR 操作來向托管 DB2 的 LPAR 添加更多內存），在遷移後需要注意 INSTANCE_MEMORY 配置參數，以便能夠在目標系統上使用更多的內存。其他 DB2 配置無需修改。
遷移分析
本節將討論遷移性能、LPAR 暫停/恢復時間、工作負載強度影響和資源需求。
活動遷移性能配置文件
圖表 1 中的陰影區域顯示了移動 LPAR 何時開始遷移。源系統上的移動 LPAR 的執行最終暫停（使用綠色表示）。隨後執行一個恢復操作（紅色陰影區域），處於源系統中的暫停操作和目標系統上的恢復操作之間。
圖表 1. DB2 活動遷移的性能配置文件
注意，內存復制超過了目標系統中移動 LPAR 的恢復執行點。當 LPAR 暫停時，最近修改的內存頁沒有被復制到目標系統。當程序訪問仍然處於源系統上的內存頁時，內存頁將按照需求從源系統分頁。因此，程序可以在目標系統上繼續執行，而不需等待剩余的所有內存頁被復制完。
圖表 1 還顯示出，只要移動 LPAR 重新開始執行，將繼續處理數據庫事務，並且將在幾秒內達到完全性能。所需時間取決於工作負載。
下面的表 2 總結了活動遷移的各個階段花費的時間。這裡顯示的時間只用於演示目的，不具有代表性。時間完全取決於工作負載、工作負載類型、DB2 內存消耗、存儲系統等等。
表 2. DB2 動態分區遷移總結
事件 時間（mm:ss） 遷移前驗證和狀態傳輸（內存副本） 03:15 總遷移時間（“Begin migration” 和 “End migration” 標記之間消耗的時間） 03:24
整個遷移過程只使用了 3 分 24 秒。這個時間是 LPAR 中有關內存量的函數，以及遷移過程中內存頁的更新頻率。總遷移時間可以進一步劃分為兩個主要活動：狀態傳輸使用了 3 分鐘 15 秒，暫停/恢復持續時間大約為 9 秒。目標系統幾乎立即實現了原始吞吐量（“Begin migration” 標記處或之前的吞吐量）。
如 圖表 1 所示，事務吞吐量在狀態傳輸階段受到了影響。在 “Begin migration” 和 “Suspend on source system” 標記之間平均吞吐量下降了大約 12%。
需要重新強調一下，這裡提到的所有性能分析指標和使用的時間都僅供演示使用。對於不同的環境，這些數據會產生很大的變化。
下一小節將討論結合不同的 ViOS 配置的情況下，在移動 LPAR 中使用不同級別負載的測試結果。
加載場景
下一組測試將檢驗在遷移時進行 LPAR 加載的效果。根據 DB2 客戶機的數量，會產生三種加載級別。產生的平均 DB2 事務吞吐量大約為 1500、1800 和 2200 事務/秒（TPS），如圖表 2 所示。
圖表 2. 分區加載對遷移配置文件的影響
這裡沒有對 LPAR、AIX 或 DB2 配置做其他修改。加載量顯然會影響遷移性能指標，包括總遷移時間、狀態傳輸時間和暫停/恢復時間。表 3 詳細分析了這些指標。
表 3. 工作負載強度對動態分區遷移的影響
事件 低 中 高 遷移前驗證和狀態傳輸（內存副本） 02:16 02:33 03:15 暫停/恢復持續時間 00:09 00:09 00:09 總遷移時間（“Begin migration” 和 “End migration” 標記之間流逝的時間） 02:25 02:42 03:24
處理器消耗
本節將查看活動遷移操作各個階段的處理器消耗行為。下面的圖表 3 展示了與 圖表 1 相同的運行場景，但是這裡展示的是每個涉及到的分區的處理器利用情況。每個 ViOS（位於源系統和目標系統上）被配置為一個專用的 LPAR，使用一個處理器和 512MB 的物理內存。DB2 LPAR 被配置為使用 2 個處理器、9GB 物理內存的專用 LPAR。
圖表 3. 活動遷移操作期間 ViOS 和 DB2 LPAR 的處理器利用情況
在 “Begin migration” 活動之前，DB2 LPAR 處理器利用率為 85% 左右。觸發遷移後，DB2 LPAR 處理器利用率稍微增長，提高至 87% 左右，並且一直保持這個水平，直到 “End migration” 標記。DB2 分區處理器利用率有輕微的增長，是因為 DB2 分區參與到狀態傳輸中。將其與 圖表 1 比較，在相同的時間中，DB2 吞吐量開始逐漸下降，在圖表中的時間標記 120 處降至最低。在 120 標記後，DB2 吞吐量保持在同一水平（與遷移前相比，下降了大約 12%）。
在遷移前，源 VIOS 服務於 DB2 磁盤和網絡 I/O 請求，因此它的處理器利用率為 18% 左右。由於目標系統上沒有進行其他活動，因此 VIOS 處理器利用率為 0%。在 120 標記以後，兩個系統上的 VIOS 處理器利用率都大幅度增加，因為它們都執行狀態傳輸操作。源 ViOS 除了執行狀態傳輸操作外，仍然服務於 DB2 磁盤和網絡 I/O，因此使處理器利用率猛增至 90%。
同時，目標 VIOS 處理器從 0% 增長至 60% 左右，並一直保持在該水平，直到完成狀態傳輸操作。在執行完暫停/恢復操作後，目標系統 VIOS 處理器利用率將增至 95%，源 ViOS 表現出類似的趨勢，DB2 LPAR 也是一樣。
注意，在 “End migration” 事件後，VIOS 處理器利用率開始逆轉。目標系統 VIOS 處理器利用率和源系統 ViOS 處理器利用率保持在同一水平，因為現在目標系統在為 DB2 客戶機服務，反之亦然。
要減少總的活動遷移持續時間，必須恰當地設置 VIOS 的大小。建議您使用共享的專用容量的分區類型，或者使用一個無上限的共享式處理器 VIOS 分區。要獲得初始的處理容量，將 VIOS 分區類型設置為無上限的共享式處理器 VIOS 分區。試運行一個峰值負載，執行活動遷移，並記錄 VIOS 允許實現的容量使用率（例如，使用 VIOS viostat 命令）。為了防止意外，向已記錄的允許實現的峰值容量添加 10% 的空閒容量。如果使用共享式專用分區，則向上取整這個值。如果將 VIOS 設置為無上限的共享式處理器分區類型，則將 ViOS 無上限容量設置為最高值，並在上面的步驟中計算允許實現的容量。
結束語
動態分區遷移使管理員能夠更好地控制數據中心的資源使用情況。遷移過程可以在關閉狀態下的分區執行，也可以在一個活動分區中執行。可以使用兩種遷移類型。如果使用靜止遷移，邏輯分區被關閉並遷移到目標系統。如果使用活動遷移，執行分區遷移時可以提供服務，而且不會中斷用戶活動。
在過去執行維護活動需要停機，但是現在不會中斷服務。活動包括（但不限於）：預防性硬件維護、硬件升級、需要在服務器之間重新分配分區的服務器整合。
需要獨立購買許可的 PowerVM 企業版來支持遷移。PowerVM 企業版包括動態分區遷移、共享專用容量、微分區、ViOS 等。
本文詳細分析了在 DB2 9.5 中運行 PowerVM 企業版動態分區遷移特性。DB2 9.5 實例托管了一個 OLTP 工作負載。DB2 實例為多個客戶機服務，超過 2000 事務/每秒（TPS）吞吐率被遷移到另一個系統。客戶機網絡連接仍然保持完整，應用程序可能會出現幾秒鐘的暫停。
致謝
本文的一些內容取自 Horace Tong 以前的工作，因此在這裡向他表示感謝；同時感謝 Sunil Kamath 和 Peter KokosIElis 在 DB2 設置和配置方面提供的幫助；Rich Bassemir 對本文進行了審校；而 Pete Jordan 提供了實驗支持以及系統和存儲應用方面的管理幫助。
