一位客户配置 Active Memory Sharing 的经历.docx

1、一位客户配置 Active Memory Sharing 的经历一位客户配置 Active Memory Sharing 的经历2009 年 9 月 23 日分享一位客户参与 IBM Early Ship Program for Active Memory Sharing on POWER6 的经历。了解这位客户如何在非生产 AIX 实验室环境中配置和部署 AMS。您可以通过访问IBM Power 系列主机虚拟化专题”来了解其它的相关虚拟化文章： IBM Power 系列主机虚拟化专题 简介我很幸运地参加了 IBM 的 Early Ship Program (ESP) for Active M

2、emory Sharing (AMS) on POWER6。本文介绍我如何在自己的非生产 AIX 实验室环境中配置 Active Memory Sharing。我还要涉及 AMS 的性能考虑因素。我希望本文能够帮助别人开始使用这种新的 PowerVM 虚拟化技术。我工作的组织参加了 ESP for AMS。因此，我们有机会先于别人（IBM 之外的人员）几个月测试 AMS。既然 AMS 已经可供 AIX 和 POWER6 客户使用了，我认为应该与 AIX 社区分享我的经历。参与 beta 测试计划是很棒的经历。我们可以访问 beta 代码和文档。我们还能够打开 PMR，报告在测试期间发现的 bu

3、g。还有一个专门为 ESP 客户开办的论坛，我们可以在这里提出问题，从 AMS 开发人员那里直接得到回答。IBM 要求我们在非生产系统上测试 AMS，定期提供报告，向开发人员提供性能、功能性和易用性方面的反馈。回页首概述AMS 是 IBM 对 POWER6 平台上的 PowerVM 虚拟化技术的一项改进。这是一些客户一直盼望的特性。它是构成完全虚拟化的 AIX 和 POWER 环境的最后一种技术。 AMS 智能化地在逻辑分区 (LPAR) 之间转移内存，从而提高内存的利用率和灵活性。这个概念与共享处理器池和微分区非常相似。它允许在 POWER6 系统上使用超过预定量的内存，让系统（POWER

4、Hypervisor）能够把内存分配给需要内存的地方。不再需要 DLPAR 操作了！ 当然，您需要了解 AMS 的工作方式，以及它如何与 AIX 上的虚拟内存和分页功能相互作用。幸运的是，现有的性能工具已经得到改进，有助于监视和管理 AMS 系统。那么，我们为什么需要 AMS？假设一个环境中有一台 p6 570，它有 256GB 内存，部署了 32 个 AIX LPAR，分配给每个 LPAR 8GB 内存。所有内存都已经分配，不能由其他 LPAR 共享。我们有未分配的处理器单元，可以使用它们建立更多 LPAR，但是因为所有内存都被占用了，实际上无法这样做。对于这种情况，通常的应对措施是激活更多

5、内存（使用 CUoD），或者购买并安装更多物理内存。 但是，如果其他 LPAR 能够共享一个 LPAR 上 “未使用” 或 “空闲” 的内存，当那个 LPAR 确实需要内存时交还内存，不是更好吗？但是，如何查明 LPAR 是否确实需要所有内存呢？由于 AIX 内存优化，这常常是个难以完成的任务。执行一些工作负载分析，发现不会同时使用所有 LPAR。这是一个非生产系统，运行一套用于 SAP/Oracle 的开发和测试环境。现在知道，尽管 LPAR 可能会占用分配给它们的所有内存，但是实际上它们不会同时使用所有内存。 是否可以重新分配 “空闲” 内存，把内存部署到确实需要内存的其他地方？可以：使用

6、 AMS 就能够实现这个目标。回页首Active Memory Sharing (AMS)在本节中，我要简要概述 AMS 的工作方式。但是，我鼓励您阅读与 AMS 相关的 IBM 官方文档。在过去，每个 LPAR 拥有自己的内存。任何未使用的内存都被浪费了。如果内存使用量过大，那么 AIX 会把内存页面交换到分页空间（磁盘）。为了处理这些情况，AIX 管理员可以使用 DLPAR 删除一些内存（如果可以判断出实际内存使用量的话），把这些内存重新分配给另一个 LPAR；或者，如果有空闲（未分配的）内存，可以使用 DLPAR 把它分配给 LPAR。请参考图 1。图 1. 具有专有物理内存的 LPAR

7、通过使用 AMS，Hypervisor 可以自动地控制内存分配。系统的物理内存被放在一个 “共享内存池” 中。给 LPAR 分配 “逻辑” 共享内存。但是，LPAR 相信内存是真实的，所以这一变化对于系统是透明的。可以根据需要给 LPAR 分配内存。可以使用未使用的内存建立更多 LPAR 或把它们分配给需要它们的 LPAR。LPAR 和 Hypervisor 相互协作，判断什么时候和什么地方应该共享内存。请参考图 2。图 2. 具有共享 “逻辑” 内存的 LPAR要想让 AMS 发挥作用，需要一个称为 Paging Virtual I/O Server (VIOS) 的新设备。Paging V

8、IOS 设备为共享内存池提供分页服务，为共享内存的 LPAR 管理 Hypervisor 分页空间。当在多个 LPAR 之间动态地管理内存时，Hypervisor 必须使用分页设备存储共享内存池的物理内存不能储存的过剩内存。这就引出了内存预订问题。用 AMS 配置内存预订有三种方式。 第一种称为 Non over-commit。在这种情况下，共享池中的真实内存量足够多，超过了配置的逻辑内存总量（例如，有四个 LPAR，每个需要 8GB，而共享池配置了 32GB 内存。共享内存池足够满足 LPAR 的需要）。第二种方法是 Logical over-commit。在给定的时刻，“正在使用的” 逻辑

9、内存量等于池中的物理内存量。因此，配置的逻辑内存总量可以大于池中的物理内存量。但是，工作集（working set） 不会超过池中的物理内存量。稍后详细讨论工作集。在这种配置中，LPAR 上正在使用的内存（工作集）位于物理内存中，而 LPAR 的逻辑内存的其余部分驻留在 Paging VIOS 上的分页设备上。对于这种方法，一定要注意 “正在使用的” 内存和 “配置的” 内存之间的差异：“配置的” 逻辑内存可以超过内存池的大小，但是任何时候 “正在使用的” 内存不能超过内存池的大小。最后一种配置是 Physical over-commit。在这种情况下，所有 LPAR 的工作集 内存需求可以超

10、过池中的物理内存量。因此，逻辑内存必须由池中的物理内存和 Paging VIOS 上的分页设备共同支持。在发生 “过量使用” 时，Hypervisor 使用 VIOS 上的分页设备存储过剩的逻辑内存。那么，应该选用哪种方法呢？如何判断哪些 LPAR 适合配置 AMS？这取决于工作负载需求。从本质上说，任何不会达到其物理内存消耗上限的工作负载都适合配置 AMS。 我喜欢采用 Logical over-commit 方法。这种方法最适合在不同时间到达峰值而平均内存使用量（工作集 ）比较低的工作负载，不太适合稳定的工作负载。通常情况下，非生产性的开发和测试环境具有这些特征。另外，故障转移或 “备用”

11、 LPAR（例如用于 PowerHA 集群的 LPAR）也非常适合 AMS，这些 LPAR 用于提供冗余，只在发生故障转移/接管时需要资源。为了决定最合适的方法，需要理解系统的工作集需求的概念。工作集是系统上工作负载实际使用或需要的内存。在把专有内存 LPAR 迁移到 AMS 之前，可以使用 AIX 性能工具（比如 svmon）判断专有内存 LPAR 中使用的内存量。 Physical over commit 方法适合那些使用大量 AIX 文件缓存、对 I/O 延迟不敏感（比如文件服务器、打印服务器或网络应用程序）而且在大多数时候不活跃的工作负载。NIM 服务器也是合适的 AMS 候选目标，因

12、为它不经常使用，只用于安装 AIX 系统和执行维护。根据我的测试，我建议对于具有以下特征的生产系统仍然使用专有的内存：服务质量要求高，内存使用量稳定，需要可预测的性能，持续保持高 CPU 利用率，内存带宽要求高。因此，我不会在我的生产环境中部署 AMS。其他一些环境也可能不适合使用 AMS，例如 Stress and Volume Testing 系统。回页首我的工作负载适合吗？在我的实验室环境中，必须判断我的工作负载是否适合共享内存池。我有两个使用专有内存的现有 LPAR。在把它们转换为共享内存 LPAR 之前，我做了一些研究。每个 LPAR 有 4GB 的专有内存。LPAR1 在大多数时候

13、相当空闲，根据它的工作集，它并不需要 4GB 的内存。LPAR2（也有 4GB 的内存）比较忙，有时候需要更多内存，偶尔会把页面交换到分页空间。它可以通过使用更多内存而获益。因此在我的 AMS 环境中，我决定给每个 LPAR 增加一些额外的逻辑内存，以便应付负载高峰。给 LPAR1 分配 6GB 的共享内存，给 LPAR2 分配 8GB。给共享内存池配置 12GB 物理内存，而分配给 LPAR 的逻辑内存总量为 14GB。逻辑内存总量大于共享内存池。根据每个 LPAR 的工作负载，这种配置应该适合大多数情况。 在大多数情况下，这两个 LPAR 可以很好地在内存池中共存。如果这两个 LPAR 的

14、工作集总和小于或等于池的大小，那么不会发生过量使用。如果工作集略微大于池大小，那么在 Hypervisor 跨 LPAR 重新平衡内存使用量时，会发生一些分页操作。如果 LPAR 的工作集比池大很多，那么会发生大量分页操作，性能会显著下降。因此，在迁移到 AMS 之前，了解工作负载是非常重要的。AMS 与 AIX 虚拟内存管理器和 Hypervisor 协作管理内存分配。如果所有 LPAR 的工作负载略微大于池，那么 Hypervisor 会要求 AIX 帮助决定可以释放什么地方的页面。AIX 可以根据需要把页面借给 Hypervisor。在分配内存时，Hypervisor 会优待内存需求高的

15、 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

16、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

17、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 cG，观察正在使用的内存量，以此判断工作集。请参考图 3。图 3. svmon 的

18、输出显示 LPAR 上正在使用的专有内存量LPAR 工作集偶尔会增长，略微超过池的大小。这很适合测试 AMS 及其性能。我的目标是把这些现有的 LPAR 从专有内存迁移到共享内存并监视它们的性能。回页首配置 Active Memory Sharing为了在我的实验室中配置 AMS，我执行了以下步骤： 在 VIOS 上使用 lsvet 命令确认已经成功地激活了 AMS VET 代码。请参考图 4。 图 4. 确认已经启用了 AMS 定义一个共享内存池。使用 Integrated Virtualization Manager (IVM) 界面执行所有 AMS 配置。 我决定共享内存池大小为 12G

19、B。在配置池之前，可用的池大小为 0MB。请参考图 5。图 5. 在创建池之前共享内存池大小为零用 IVM 界面定义池非常简单。请参考图 6。图 6. 用于创建共享内存的 IVM 界面我指定 12GB 作为池大小，选择 rootvg 作为 VIOS 分页设备的位置。我建议使用高性能的 SAN 磁盘作为 VIOS 分页设备，但是对于我的 beta 测试，使用 rootvg 就够了。请参考图 7。图 7. 定义共享内存池定义了池之后，我在 IVM 和 VIOS 上查看它的设置。注意，我还把最大大小改为 16GB，这样的话，如果需要，可以动态地增加共享内存池的大小。请参考图 8 和图 9。图 8.

20、共享内存池设置图 9. VIOS 上的共享内存和分页池视图 下一步是把现有的专有内存 LPAR 迁移到共享内存 LPAR。为此，首先需要关闭每个 LPAR 并把配置信息由 dedicated 改为 shared。请参考图 10、11 和 12。 图 10. 在修改配置信息之前必须关闭 LPAR图 11. 在 LPAR 的内存配置信息中选择 Shared图 12. LPAR 的共享内存配置设置在迁移到共享内存时，IVM 自动地为每个 LPAR 创建一个 VIOS 分页设备。它创建的分页设备的大小等于共享内存池的最大内存值。请参考图 13。图 13. IVM 创建的分页设备从 VIOS 查看 AM

21、S 分页设备。请参考图 14。图 14. AMS 分页设备 作为共享内存分区重新启动 LPAR 之后，我使用 lparstat 和 vmstat 查看 LPAR 的共享内存设置。请参考图 15 和图 16。 图 15. 共享内存 LPAR 的 lparstat 输出I/O 标称内存代表任意时刻一个分区在 I/O 映射方面保证可以使用的最大物理内存量。分区被分配权值，权值决定分配内存时的优先次序。更多信息请参考 IBM 文档。图 16. 共享内存 LPAR 的 vmstat 输出回页首监视 AMS现有的 topas 和 vmstat 等工具已经改进了，可以报告正在使用的物理内存、Hypervis

22、or 分页速率、Hypervisor 分页速率延迟以及 AIX 借给 Hypervisor 的内存量。可以使用这些工具监视 AMS 性能和活动。请参考图 17。图 17. 共享内存 LPAR 的 topas cec 输出pmem 是给定时刻从共享内存池分配给共享内存分区的物理内存（以 GB 为单位）。更多信息请参考 IBM 文档。svmon 工具也是 AMS 感知的，可以显示分配给 LPAR 的内存量。请参考图 18。图 18. 共享内存 LPAR 的 svmon 输出回页首AMS 的运行效果在下面的示例中，可以观察到一个 LPAR 由于工作负载增加需要更多内存。内存自动地从一个 LPAR 重

23、新分配给另一个 LPAR。内存根据需要借给繁忙的 LPAR。不需要管理员交互，AMS 活动对于系统是透明的。内存已经从 bxaix85 借给 bxaix86。正在使用的内存为 4GB (pmem)，借出 2GB 内存 (loan)。请参考图 19。图 19. 内存已经从 bxaix85 借给 bxaix86图 20. bxaix86 空闲在 bxaix85 上启动工作负载。它借给 bxaix86 的内存又被收回。随着时间的推移，借出的内存量 (loan) 下降，这个 LPAR 上使用的内存量 (pmem) 增加。请参考图 21。图 21. 在 bxaix85 上启动工作负载现在，这两个 LPA

24、R 的工作集大于共享内存池大小。由于要把内存还给 bxaix85，在 bxaix86 上发生 Hypervisor 分页（hpi 和 hpit）。bxaix86 上使用的内存量 (pmem) 从 8GB 下降到略超过 6GB。 图 22. bxaix86 上使用的内存量一旦 bxaix85 已经有了完成工作所需的内存，在 bxaix86 上的 Hypervisor 分页（hpi 和 hpit）就停止了。请参考图 23。图 23. bxaix86 上的 Hypervisor 分页停止当 bxaix85 完成它的工作负载之后，在 bxaix86 上启动一个作业。内存再次从 bxaix85 借给 b

25、xaix86。随着时间的推移，bxaix85 上使用的内存量 (pmem) 下降，借出的内存量 (loan) 增加。请参考图 24。图 24. bxaix85 上使用的内存量 (pmem) 下降可以使用 vmo 在 LPAR 上修改 AMS Loan Policy。在默认情况下，只借出文件缓存页面。可以根据您需要的内存页面借用程度修改策略。请参考图 25。图 25. 共享内存 LPAR 上的 vmo 设置回页首AMS 已经实现了！现在怎么办？构成虚拟化环境的最后一种技术 Active Memory Sharing 已经出现了。我们可以让 AIX POWER 系统根据工作负载和需要自动地调整内存

26、分配。不再需要 DLPAR 操作了！顺便说一句，AMS 支持用 DLPAR 调整内存，所以仍然可以动态地增加和减少 LPAR 的内存，只是现在分配的是逻辑内存而不是物理内存。因为在虚拟化内存环境中有性能调优和监视方面的差异，我们还有许多要学习的东西。需要重新审视监视 AIX 内存的传统方法，要考虑 AMS 和逻辑内存的影响。与共享处理刚出现时一样，现在需要再次调整看待虚拟化资源监视和管理的视角，这一次要从内存的角度考虑问题。在我的环境中，还有几个方面需要测试，比如为 AMS 配置双 VIOS、在启用了 AMS 的系统上执行 Live Partition Mobility 以及对 PowerHA

27、 (HACMP) 集群使用 AMS。我希望尽快找时间完成这些测试，然后向 AIX 社区提交报告。如果别人已经做了这些事，请告诉我！回页首结束语我希望本文对 AMS 的简要介绍能够帮助您考虑如何部署和迁移到这种新技术。AMS 可能会大大提高在 POWER6 和 PowerVM 技术方面的投资的回报，降低总成本。在系统之间共享内存有助于降低成本，提供更高效的内存部署方法。如果您打算在自己的环境中使用 AMS，那么首先要考虑如何迁移到共享内存分区。首先采取最基本的步骤，比如： 把 HMC 升级到最新级别。 升级 POWER6 的固件。 把 VIO 服务器升级到 version 2.1。 把所有 AIX 系统升级到 AIX 6.1。 为迁移到 AMS 制定迁移战略。找出适合配置 AMS 的系统。例如，可以先从几个非生产性系统开始。测试它们，直到您对性能满意了。然后，重复这个过程，迁移更多系统，直到您需要虚拟化的所有内存都已经虚拟化了。 目前还应该考虑参加关于 AMS 以及最新 POWER6 和 AIX 技术的培训。