一位客戶配置 Active Memory Sharing 的經歷

轉載：http://www.ibm.com/developerworks/cn/aix/library/au-pwr6_ams/

分享一位客戶參與 IBM® Early Ship Program for Active Memory Sharing on POWER6™ 的經歷。瞭解這位客戶如何在非生產 AIX® 實驗室環境中配置和部署 AMS。

簡介

我很幸運地參加了 IBM 的 Early Ship Program (ESP) for Active Memory Sharing (AMS) on POWER6。本文介紹我如何在自己的非生產 AIX 實驗室環境中配置 Active Memory Sharing。我還要涉及 AMS 的性能考慮因素。我希望本文能夠幫助別人開始使用這種新的 PowerVM™ 虛擬化技術。

我工作的組織參加了 ESP for AMS。因此，我們有機會先於別人（IBM 之外的人員）幾個月測試 AMS。既然 AMS 已經可供 AIX 和 POWER6 客戶使用了，我認爲應該與 AIX 社區分享我的經歷。

參與 beta 測試計劃是很棒的經歷。我們可以訪問 beta 代碼和文檔。我們還能夠打開 PMR，報告在測試期間發現的 bug。還有一個專門爲 ESP 客戶開辦的論壇，我們可以在這裏提出問題，從 AMS 開發人員那裏直接得到回答。

IBM 要求我們在非生產系統上測試 AMS，定期提供報告，向開發人員提供性能、功能性和易用性方面的反饋。

回頁首

概述

AMS 是 IBM 對 POWER6 平臺上的 PowerVM 虛擬化技術的一項改進。這是一些客戶一直盼望的特性。它是構成完全虛擬化的 AIX 和 POWER 環境的最後一種技術。

AMS 智能化地在邏輯分區 (LPAR) 之間轉移內存，從而提高內存的利用率和靈活性。這個概念與共享處理器池和微分區非常相似。它允許在 POWER6 系統上使用超過預定量的內存，讓系統（POWER Hypervisor™）能夠把內存分配給需要內存的地方。不再需要 DLPAR 操作了！

當然，您需要了解 AMS 的工作方式，以及它如何與 AIX 上的虛擬內存和分頁功能相互作用。幸運的是，現有的性能工具已經得到改進，有助於監視和管理 AMS 系統。

那麼，我們爲什麼需要 AMS？假設一個環境中有一臺 p6 570，它有 256GB 內存，部署了 32 個 AIX LPAR，分配給每個 LPAR 8GB 內存。所有內存都已經分配，不能由其他 LPAR 共享。我們有未分配的處理器單元，可以使用它們建立更多 LPAR，但是因爲所有內存都被佔用了，實際上無法這樣做。對於這種情況，通常的應對措施是激活更多內存（使用 CUoD），或者購買並安裝更多物理內存。

但是，如果其他 LPAR 能夠共享一個 LPAR 上 “未使用” 或 “空閒” 的內存，當那個 LPAR 確實需要內存時交還內存，不是更好嗎？但是，如何查明 LPAR 是否確實需要所有內存呢？由於 AIX 內存優化，這常常是個難以完成的任務。執行一些工作負載分析，發現不會同時使用所有 LPAR。這是一個非生產系統，運行一套用於 SAP/Oracle 的開發和測試環境。現在知道，儘管 LPAR 可能會佔用分配給它們的所有內存，但是實際上它們不會同時使用所有內存。

是否可以重新分配 “空閒” 內存，把內存部署到確實需要內存的其他地方？可以：使用 AMS 就能夠實現這個目標。

回頁首

Active Memory Sharing (AMS)

在本節中，我要簡要概述 AMS 的工作方式。但是，我鼓勵您閱讀與 AMS 相關的 IBM 官方文檔。

在過去，每個 LPAR 擁有自己的內存。任何未使用的內存都被浪費了。如果內存使用量過大，那麼 AIX 會把內存頁面交換到分頁空間（磁盤）。爲了處理這些情況，AIX 管理員可以使用 DLPAR 刪除一些內存（如果可以判斷出實際內存使用量的話），把這些內存重新分配給另一個 LPAR；或者，如果有空閒（未分配的）內存，可以使用 DLPAR 把它分配給 LPAR。請參考圖 1。

圖 1. 具有專有物理內存的 LPAR

通過使用 AMS，Hypervisor 可以自動地控制內存分配。系統的物理內存被放在一個 “共享內存池” 中。給 LPAR 分配 “邏輯” 共享內存。但是，LPAR 相信內存是真實的，所以這一變化對於系統是透明的。可以根據需要給 LPAR 分配內存。可以使用未使用的內存建立更多 LPAR 或把它們分配給需要它們的 LPAR。LPAR 和 Hypervisor 相互協作，判斷什麼時候和什麼地方應該共享內存。請參考圖 2。

圖 2. 具有共享 “邏輯” 內存的 LPAR

要想讓 AMS 發揮作用，需要一個稱爲 Paging Virtual I/O Server (VIOS) 的新設備。Paging VIOS 設備爲共享內存池提供分頁服務，爲共享內存的 LPAR 管理 Hypervisor 分頁空間。當在多個 LPAR 之間動態地管理內存時，Hypervisor 必須使用分頁設備存儲共享內存池的物理內存不能儲存的過剩內存。這就引出了內存預訂問題。

用 AMS 配置內存預訂有三種方式。

第一種稱爲 Non over-commit。在這種情況下，共享池中的真實內存量足夠多，超過了配置的邏輯內存總量（例如，有四個 LPAR，每個需要 8GB，而共享池配置了 32GB 內存。共享內存池足夠滿足 LPAR 的需要）。

第二種方法是 Logical over-commit。在給定的時刻，“正在使用的” 邏輯內存量等於池中的物理內存量。因此，配置的邏輯內存總量可以大於池中的物理內存量。但是，工作集（working set） 不會超過池中的物理內存量。稍後詳細討論工作集。在這種配置中，LPAR 上正在使用的內存（工作集）位於物理內存中，而 LPAR 的邏輯內存的其餘部分駐留在 Paging VIOS 上的分頁設備上。對於這種方法，一定要注意 “正在使用的” 內存和 “配置的” 內存之間的差異：“配置的” 邏輯內存可以超過內存池的大小，但是任何時候 “正在使用的” 內存不能超過內存池的大小。

最後一種配置是 Physical over-commit。在這種情況下，所有 LPAR 的工作集 內存需求可以超過池中的物理內存量。因此，邏輯內存必須由池中的物理內存和 Paging VIOS 上的分頁設備共同支持。在發生 “過量使用” 時，Hypervisor 使用 VIOS 上的分頁設備存儲過剩的邏輯內存。

那麼，應該選用哪種方法呢？如何判斷哪些 LPAR 適合配置 AMS？這取決於工作負載需求。從本質上說，任何不會達到其物理內存消耗上限的工作負載都適合配置 AMS。

我喜歡採用 Logical over-commit 方法。這種方法最適合在不同時間到達峯值而平均內存使用量（工作集 ）比較低的工作負載，不太適合穩定的工作負載。通常情況下，非生產性的開發和測試環境具有這些特徵。另外，故障轉移或 “備用” LPAR（例如用於 PowerHA 集羣的 LPAR）也非常適合 AMS，這些 LPAR 用於提供冗餘，只在發生故障轉移/接管時需要資源。

爲了決定最合適的方法，需要理解系統的工作集需求的概念。工作集是系統上工作負載實際使用或需要的內存。在把專有內存 LPAR 遷移到 AMS 之前，可以使用 AIX 性能工具（比如 svmon）判斷專有內存 LPAR 中使用的內存量。

Physical over commit 方法適合那些使用大量 AIX 文件緩存、對 I/O 延遲不敏感（比如文件服務器、打印服務器或網絡應用程序）而且在大多數時候不活躍的工作負載。NIM 服務器也是合適的 AMS 候選目標，因爲它不經常使用，只用於安裝 AIX 系統和執行維護。

根據我的測試，我建議對於具有以下特徵的生產系統仍然使用專有的內存：服務質量要求高，內存使用量穩定，需要可預測的性能，持續保持高 CPU 利用率，內存帶寬要求高。因此，我不會在我的生產環境中部署 AMS。其他一些環境也可能不適合使用 AMS，例如 Stress and Volume Testing 系統。

回頁首

我的工作負載適合嗎？

在我的實驗室環境中，必須判斷我的工作負載是否適合共享內存池。我有兩個使用專有內存的現有 LPAR。在把它們轉換爲共享內存 LPAR 之前，我做了一些研究。每個 LPAR 有 4GB 的專有內存。LPAR1 在大多數時候相當空閒，根據它的工作集，它並不需要 4GB 的內存。LPAR2（也有 4GB 的內存）比較忙，有時候需要更多內存，偶爾會把頁面交換到分頁空間。它可以通過使用更多內存而獲益。

因此在我的 AMS 環境中，我決定給每個 LPAR 增加一些額外的邏輯內存，以便應付負載高峯。給 LPAR1 分配 6GB 的共享內存，給 LPAR2 分配 8GB。給共享內存池配置 12GB 物理內存，而分配給 LPAR 的邏輯內存總量爲 14GB。邏輯內存總量大於共享內存池。根據每個 LPAR 的工作負載，這種配置應該適合大多數情況。

在大多數情況下，這兩個 LPAR 可以很好地在內存池中共存。如果這兩個 LPAR 的工作集總和小於或等於池的大小，那麼不會發生過量使用。如果工作集略微大於池大小，那麼在 Hypervisor 跨 LPAR 重新平衡內存使用量時，會發生一些分頁操作。如果 LPAR 的工作集比池大很多，那麼會發生大量分頁操作，性能會顯著下降。因此，在遷移到 AMS 之前，瞭解工作負載是非常重要的。

AMS 與 AIX 虛擬內存管理器和 Hypervisor 協作管理內存分配。如果所有 LPAR 的工作負載略微大於池，那麼 Hypervisor 會要求 AIX 幫助決定可以釋放什麼地方的頁面。AIX 可以根據需要把頁面借給 Hypervisor。在分配內存時，Hypervisor 會優待內存需求高的 LPAR。

如果池被過量使用，Hypervisor 會主動地從 LPAR 偷頁面。如果這會顯著影響性能，可能應該考慮在池中增加更多物理內存。

回頁首

準備和計劃

如果計劃在環境中使用 AMS，就必須確保系統具備以下硬件、AIX 版本、VIOS 版本、固件級別和虛擬化配置：

• 基於 POWER6 處理器的 IBM Power System
• 爲了支持 Active Memory Sharing，需要啓用企業版 PowerVM
• 固件級別 340_070
• HMC version 7.3.4（用於 HMC 管理的系統）
• Virtual I/O Server Version 2.1.0.1-FP20.0
• AIX 6.1 TL3
• Micro-partition only
• Virtual I/O only

我的非生產實驗室環境由一臺 JS22™ 刀片服務器組成，它有 16GB 內存和四個 POWER6 處理器。這臺刀片服務器上配置了一個 VIOS (IVM) 和兩個 AIX 6.1 LPAR。ESP 計劃爲我提供了要安裝的 beta 代碼，代碼在我的 JS22、VIOS 和 AIX LPAR 上啓用 AMS。我把這個實驗室環境升級到提供的 beta 級別：

• 把刀片服務器的固件升級到 EA340_043_039。
• 把刀片服務器上的 VIOS 升級到 2.1.0.1-FP-20.0。
• 對 VIOS 和 AIX LPAR 應用 AMS efixes。
• 應用啓用 AMS 所需的 VET 代碼。

兩個 LPAR 都是現有的系統（使用專有內存），使用現有的工作負載。第一個 LPAR bxaix85 運行一個 SAP/Oracle 實例。另一個 LPAR bxaix86 運行三個應用程序：SAP/Oracle、Wily 和 Oracle Grid Control，每個應用程序駐留在一個 Workload Partition (WPAR) 中。

這兩個 LPAR 的工作集大約爲 9.3GB，這與池的大小相適應。我運行了 svmon c–G，觀察正在使用的內存量，以此判斷工作集。請參考圖 3。

圖 3. svmon 的輸出顯示 LPAR 上正在使用的專有內存量

LPAR 工作集偶爾會增長，略微超過池的大小。這很適合測試 AMS 及其性能。我的目標是把這些現有的 LPAR 從專有內存遷移到共享內存並監視它們的性能。

回頁首

配置 Active Memory Sharing

爲了在我的實驗室中配置 AMS，我執行了以下步驟：

• 在 VIOS 上使用 lsvet 命令確認已經成功地激活了 AMS VET 代碼。請參考圖 4。

  圖 4. 確認已經啓用了 AMS

• 定義一個共享內存池。使用 Integrated Virtualization Manager (IVM) 界面執行所有 AMS 配置。

  我決定共享內存池大小爲 12GB。在配置池之前，可用的池大小爲 0MB。請參考圖 5。

  圖 5. 在創建池之前共享內存池大小爲零

  用 IVM 界面定義池非常簡單。請參考圖 6。

  圖 6. 用於創建共享內存的 IVM 界面

  我指定 12GB 作爲池大小，選擇 rootvg 作爲 VIOS 分頁設備的位置。我建議使用高性能的 SAN 磁盤作爲 VIOS 分頁設備，但是對於我的 beta 測試，使用 rootvg 就夠了。請參考圖 7。

  圖 7. 定義共享內存池

  定義了池之後，我在 IVM 和 VIOS 上查看它的設置。注意，我還把最大大小改爲 16GB，這樣的話，如果需要，可以動態地增加共享內存池的大小。請參考圖 8 和圖 9。

  圖 8. 共享內存池設置

  圖 9. VIOS 上的共享內存和分頁池視圖

• 下一步是把現有的專有內存 LPAR 遷移到共享內存 LPAR。爲此，首先需要關閉每個 LPAR 並把配置信息由 dedicated 改爲 shared。請參考圖 10、11 和 12。

  圖 10. 在修改配置信息之前必須關閉 LPAR

  圖 11. 在 LPAR 的內存配置信息中選擇 Shared

  圖 12. LPAR 的共享內存配置設置

  在遷移到共享內存時，IVM 自動地爲每個 LPAR 創建一個 VIOS 分頁設備。它創建的分頁設備的大小等於共享內存池的最大內存值。請參考圖 13。

  圖 13. IVM 創建的分頁設備

  從 VIOS 查看 AMS 分頁設備。請參考圖 14。

  圖 14. AMS 分頁設備

• 作爲共享內存分區重新啓動 LPAR 之後，我使用 lparstat 和 vmstat 查看 LPAR 的共享內存設置。請參考圖 15 和圖 16。

  圖 15. 共享內存 LPAR 的 lparstat 輸出

  I/O 標稱內存代表任意時刻一個分區在 I/O 映射方面保證可以使用的最大物理內存量。分區被分配權值，權值決定分配內存時的優先次序。更多信息請參考 IBM 文檔。

  圖 16. 共享內存 LPAR 的 vmstat 輸出

回頁首

監視 AMS

現有的 topas 和 vmstat 等工具已經改進了，可以報告正在使用的物理內存、Hypervisor 分頁速率、Hypervisor 分頁速率延遲以及 AIX 借給 Hypervisor 的內存量。可以使用這些工具監視 AMS 性能和活動。請參考圖 17。

圖 17. 共享內存 LPAR 的 topas cec 輸出

pmem 是給定時刻從共享內存池分配給共享內存分區的物理內存（以 GB 爲單位）。更多信息請參考 IBM 文檔。

svmon 工具也是 AMS 感知的，可以顯示分配給 LPAR 的內存量。請參考圖 18。

圖 18. 共享內存 LPAR 的 svmon 輸出

回頁首

AMS 的運行效果

在下面的示例中，可以觀察到一個 LPAR 由於工作負載增加需要更多內存。內存自動地從一個 LPAR 重新分配給另一個 LPAR。內存根據需要借給繁忙的 LPAR。不需要管理員交互，AMS 活動對於系統是透明的。

內存已經從 bxaix85 借給 bxaix86。正在使用的內存爲 4GB (pmem)，借出 2GB 內存 (loan)。請參考圖 19。

圖 19. 內存已經從 bxaix85 借給 bxaix86

圖 20. bxaix86 空閒

在 bxaix85 上啓動工作負載。它借給 bxaix86 的內存又被收回。隨着時間的推移，借出的內存量 (loan) 下降，這個 LPAR 上使用的內存量 (pmem) 增加。請參考圖 21。

圖 21. 在 bxaix85 上啓動工作負載

現在，這兩個 LPAR 的工作集大於共享內存池大小。由於要把內存還給 bxaix85，在 bxaix86 上發生 Hypervisor 分頁（hpi 和 hpit）。bxaix86 上使用的內存量 (pmem) 從 8GB 下降到略超過 6GB。

圖 22. bxaix86 上使用的內存量

一旦 bxaix85 已經有了完成工作所需的內存，在 bxaix86 上的 Hypervisor 分頁（hpi 和 hpit）就停止了。請參考圖 23。

圖 23. bxaix86 上的 Hypervisor 分頁停止

當 bxaix85 完成它的工作負載之後，在 bxaix86 上啓動一個作業。內存再次從 bxaix85 借給 bxaix86。隨着時間的推移，bxaix85 上使用的內存量 (pmem) 下降，借出的內存量 (loan) 增加。請參考圖 24。

圖 24. bxaix85 上使用的內存量 (pmem) 下降

可以使用 vmo 在 LPAR 上修改 AMS Loan Policy。在默認情況下，只借出文件緩存頁面。可以根據您需要的內存頁面借用程度修改策略。請參考圖 25。

圖 25. 共享內存 LPAR 上的 vmo 設置

回頁首

AMS 已經實現了！現在怎麼辦？

構成虛擬化環境的最後一種技術 Active Memory Sharing 已經出現了。我們可以讓 AIX POWER 系統根據工作負載和需要自動地調整內存分配。不再需要 DLPAR 操作了！順便說一句，AMS 支持用 DLPAR 調整內存，所以仍然可以動態地增加和減少 LPAR 的內存，只是現在分配的是邏輯內存而不是物理內存。

因爲在虛擬化內存環境中有性能調優和監視方面的差異，我們還有許多要學習的東西。需要重新審視監視 AIX 內存的傳統方法，要考慮 AMS 和邏輯內存的影響。與共享處理剛出現時一樣，現在需要再次調整看待虛擬化資源監視和管理的視角，這一次要從內存的角度考慮問題。

在我的環境中，還有幾個方面需要測試，比如爲 AMS 配置雙 VIOS、在啓用了 AMS 的系統上執行 Live Partition Mobility 以及對 PowerHA (HACMP) 集羣使用 AMS。我希望儘快找時間完成這些測試，然後向 AIX 社區提交報告。如果別人已經做了這些事，請告訴我！

回頁首

結束語

我希望本文對 AMS 的簡要介紹能夠幫助您考慮如何部署和遷移到這種新技術。AMS 可能會大大提高在 POWER6 和 PowerVM 技術方面的投資的回報，降低總成本。在系統之間共享內存有助於降低成本，提供更高效的內存部署方法。

如果您打算在自己的環境中使用 AMS，那麼首先要考慮如何遷移到共享內存分區。首先採取最基本的步驟，比如：

• 把 HMC 升級到最新級別。
• 升級 POWER6 的固件。
• 把 VIO 服務器升級到 version 2.1。
• 把所有 AIX 系統升級到 AIX 6.1。
• 爲遷移到 AMS 制定遷移戰略。找出適合配置 AMS 的系統。例如，可以先從幾個非生產性系統開始。測試它們，直到您對性能滿意了。然後，重複這個過程，遷移更多系統，直到您需要虛擬化的所有內存都已經虛擬化了。

目前還應該考慮參加關於 AMS 以及最新 POWER6 和 AIX 技術的培訓。