一位客户配置 Active Memory Sharing 的经历
分享一位客户参与 IBM® Early Ship for on ™ 的经历。了解这位客户如何在非生产 AIX® 实验室环境中配置和部署 AMS。
简介
我很幸运地参加了 IBM 的 Early Ship (ESP) for (AMS) on 。本文介绍我如何在自己的非生产 AIX 实验室环境中配置 。我还要涉及 AMS 的性能考虑因素。我希望本文能够帮助别人开始使用这种新的 ™ 虚拟化技术。
我工作的组织参加了 ESP for AMS。因此，我们有机会先于别人（IBM 之外的人员）几个月测试 AMS。既然 AMS 已经可供 AIX 和 客户使用了，我认为应该与 AIX 社区分享我的经历。
参与 beta 测试计划是很棒的经历。我们可以访问 beta 代码和文档。我们还能够打开 PMR，报告在测试期间发现的 bug。还有一个专门为 ESP 客户开办的论坛，我们可以在这里提出问题，从 AMS 开发人员那里直接得到回答。
IBM 要求我们在非生产系统上测试 AMS，定期提供报告，向开发人员提供性能、功能性和易用性方面的反馈。
回页首
概述
AMS 是 IBM 对 平台上的 虚拟化技术的一项改进。这是一些客户一直盼望的特性。它是构成完全虚拟化的 AIX 和 POWER 环境的最后一种技术。
AMS 智能化地在逻辑分区 (LPAR) 之间转移内存，从而提高内存的利用率和灵活性。这个概念与共享处理器池和微分区非常相似。它允许在 系统上使用超过预定量的内存，让系统（POWER ™）能够把内存分配给需要内存的地方。不再需要 DLPAR 操作了！
当然，您需要了解 AMS 的工作方式，以及它如何与 AIX 上的虚拟内存和分页功能相互作用。幸运的是，现有的性能工具已经得到改进，有助于监视和管理 AMS 系统。
那么，我们为什么需要 AMS？假设一个环境中有一台 p6 570，它有 256GB 内存，部署了 32 个 AIX LPAR，分配给每个 LPAR 8GB 内存。所有内存都已经分配，不能由其他 LPAR 共享。我们有未分配的处理器单元，可以使用它们建立更多 LPAR，但是因为所有内存都被占用了，实际上无法这样做。对于这种情况，通常的应对措施是激活更多内存（使用 CUoD），或者购买并安装更多物理内存。
但是，如果其他 LPAR 能够共享一个 LPAR 上 “未使用” 或 “空闲” 的内存，当那个 LPAR 确实需要内存时交还内存，不是更好吗？但是，如何查明 LPAR 是否确实需要所有内存呢？由于 AIX 内存优化，这常常是个难以完成的任务。执行一些工作负载分析，发现不会同时使用所有 LPAR。这是一个非生产系统，运行一套用于 SAP/ 的开发和测试环境。现在知道，尽管 LPAR 可能会占用分配给它们的所有内存，但是实际上它们不会同时使用所有内存。
是否可以重新分配 “空闲” 内存，把内存部署到确实需要内存的其他地方？可以：使用 AMS 就能够实现这个目标。
回页首
(AMS)
在本节中，我要简要概述 AMS 的工作方式。但是，我鼓励您阅读与 AMS 相关的 IBM 官方文档。
在过去，每个 LPAR 拥有自己的内存。任何未使用的内存都被浪费了。如果内存使用量过大，那么 AIX 会把内存页面交换到分页空间（磁盘）。为了处理这些情况，AIX 管理员可以使用 DLPAR 删除一些内存（如果可以判断出实际内存使用量的话），把这些内存重新分配给另一个 LPAR；或者，如果有空闲（未分配的）内存，可以使用 DLPAR 把它分配给 LPAR。请参考图 1。
图 1. 具有专有物理内存的 LPAR
通过使用 AMS， 可以自动地控制内存分配。系统的物理内存被放在一个 “共享内存池” 中。给 LPAR 分配 “逻辑” 共享内存。但是，LPAR 相信内存是真实的，所以这一变化对于系统是透明的。可以根据需要给 LPAR 分配内存。可以使用未使用的内存建立更多 LPAR 或把它们分配给需要它们的 LPAR。LPAR 和 相互协作，判断什么时候和什么地方应该共享内存。请参考图 2。
图 2. 具有共享 “逻辑” 内存的 LPAR
要想让 AMS 发挥作用，需要一个称为 I/O (VIOS) 的新设备。 VIOS 设备为共享内存池提供分页服务，为共享内存的 LPAR 管理 分页空间。当在多个 LPAR 之间动态地管理内存时， 必须使用分页设备存储共享内存池的物理内存不能储存的过剩内存。这就引出了内存预订问题。
用 AMS 配置内存预订有三种方式。
第一种称为 Non over-。在这种情况下，共享池中的真实内存量足够多，超过了配置的逻辑内存总量（例如，有四个 LPAR，每个需要 8GB，而共享池配置了 32GB 内存。共享内存池足够满足 LPAR 的需要）。
第二种方法是 over-。在给定的时刻，“正在使用的” 逻辑内存量等于池中的物理内存量。因此，配置的逻辑内存总量可以大于池中的物理内存量。但是，工作集（ set） 不会超过池中的物理内存量。稍后详细讨论工作集。在这种配置中，LPAR 上正在使用的内存（工作集）位于物理内存中，而 LPAR 的逻辑内存的其余部分驻留在 VIOS 上的分页设备上。对于这种方法，一定要注意 “正在使用的” 内存和 “配置的” 内存之间的差异：“配置的” 逻辑内存可以超过内存池的大小，但是任何时候 “正在使用的” 内存不能超过内存池的大小。
最后一种配置是 over-。在这种情况下，所有 LPAR 的工作集 内存需求可以超过池中的物理内存量。因此，逻辑内存必须由池中的物理内存和 VIOS 上的分页设备共同支持。在发生 “过量使用” 时， 使用 VIOS 上的分页设备存储过剩的逻辑内存。
那么，应该选用哪种方法呢？如何判断哪些 LPAR 适合配置 AMS？这取决于工作负载需求。从本质上说，任何不会达到其物理内存消耗上限的工作负载都适合配置 AMS。
我喜欢采用 over- 方法。这种方法最适合在不同时间到达峰值而平均内存使用量（工作集 ）比较低的工作负载，不太适合稳定的工作负载。通常情况下，非生产性的开发和测试环境具有这些特征。另外，故障转移或 “备用” LPAR（例如用于 集群的 LPAR）也非常适合 AMS，这些 LPAR 用于提供冗余，只在发生故障转移/接管时需要资源。
为了决定最合适的方法，需要理解系统的工作集需求的概念。工作集是系统上工作负载实际使用或需要的内存。在把专有内存 LPAR 迁移到 AMS 之前，可以使用 AIX 性能工具（比如 svmon）判断专有内存 LPAR 中使用的内存量。
over 方法适合那些使用大量 AIX 文件缓存、对 I/O 延迟不敏感（比如文件服务器、打印服务器或网络应用程序）而且在大多数时候不活跃的工作负载。NIM 服务器也是合适的 AMS 候选目标，因为它不经常使用，只用于安装 AIX 系统和执行维护。
根据我的测试，我建议对于具有以下特征的生产系统仍然使用专有的内存：服务质量要求高，内存使用量稳定，需要可预测的性能，持续保持高 CPU 利用率，内存带宽要求高。因此，我不会在我的生产环境中部署 AMS。其他一些环境也可能不适合使用 AMS，例如 and 系统。
回页首
我的工作负载适合吗？
在我的实验室环境中，必须判断我的工作负载是否适合共享内存池。我有两个使用专有内存的现有 LPAR。在把它们转换为共享内存 LPAR 之前，我做了一些研究。每个 LPAR 有 4GB 的专有内存。LPAR1 在大多数时候相当空闲，根据它的工作集，它并不需要 4GB 的内存。LPAR2（也有 4GB 的内存）比较忙，有时候需要更多内存，偶尔会把页面交换到分页空间。它可以通过使用更多内存而获益。
因此在我的 AMS 环境中，我决定给每个 LPAR 增加一些额外的逻辑内存，以便应付负载高峰。给 LPAR1 分配 6GB 的共享内存，给 LPAR2 分配 8GB。给共享内存池配置 12GB 物理内存，而分配给 LPAR 的逻辑内存总量为 14GB。逻辑内存总量大于共享内存池。根据每个 LPAR 的工作负载，这种配置应该适合大多数情况。
在大多数情况下，这两个 LPAR 可以很好地在内存池中共存。如果这两个 LPAR 的工作集总和小于或等于池的大小，那么不会发生过量使用。如果工作集略微大于池大小，那么在 跨 LPAR 重新平衡内存使用量时，会发生一些分页操作。如果 LPAR 的工作集比池大很多，那么会发生大量分页操作，性能会显著下降。因此，在迁移到 AMS 之前，了解工作负载是非常重要的。
AMS 与 AIX 虚拟内存管理器和 协作管理内存分配。如果所有 LPAR 的工作负载略微大于池，那么 会要求 AIX 帮助决定可以释放什么地方的页面。AIX 可以根据需要把页面借给 。在分配内存时， 会优待内存需求高的 LPAR。
如果池被过量使用， 会主动地从 LPAR 偷页面。如果这会显著影响性能，可能应该考虑在池中增加更多物理内存。
回页首
准备和计划
如果计划在环境中使用 AMS，就必须确保系统具备以下硬件、AIX 版本、VIOS 版本、固件级别和虚拟化配置：
我的非生产实验室环境由一台 JS22™ 刀片服务器组成，它有 16GB 内存和四个 处理器。这台刀片服务器上配置了一个 VIOS (IVM) 和两个 AIX 6.1 LPAR。ESP 计划为我提供了要安装的 beta 代码，代码在我的 JS22、VIOS 和 AIX LPAR 上启用 AMS。我把这个实验室环境升级到提供的 beta 级别：
两个 LPAR 都是现有的系统（使用专有内存），使用现有的工作负载。第一个 LPAR 运行一个 SAP/ 实例。另一个 LPAR 运行三个应用程序：SAP/、Wily 和 Grid ，每个应用程序驻留在一个 (WPAR) 中。
这两个 LPAR 的工作集大约为 9.3GB，这与池的大小相适应。我运行了 svmon c–G，观察正在使用的内存量，以此判断工作集。请参考图 3。
图 3. svmon 的输出显示 LPAR 上正在使用的专有内存量
LPAR 工作集偶尔会增长，略微超过池的大小。这很适合测试 AMS 及其性能。我的目标是把这些现有的 LPAR 从专有内存迁移到共享内存并监视它们的性能。
回页首
配置
为了在我的实验室中配置 AMS，我执行了以下步骤：
回页首
监视 AMS
现有的 topas 和 等工具已经改进了，可以报告正在使用的物理内存、 分页速率、 分页速率延迟以及 AIX 借给 的内存量。可以使用这些工具监视 AMS 性能和活动。请参考图 17。
图 17. 共享内存 LPAR 的 topas cec 输出
pmem 是给定时刻从共享内存池分配给共享内存分区的物理内存（以 GB 为单位）。更多信息请参考 IBM 文档。
svmon 工具也是 AMS 感知的，可以显示分配给 LPAR 的内存量。请参考图 18。
图 18. 共享内存 LPAR 的 svmon 输出
回页首
AMS 的运行效果
在下面的示例中，可以观察到一个 LPAR 由于工作负载增加需要更多内存。内存自动地从一个 LPAR 重新分配给另一个 LPAR。内存根据需要借给繁忙的 LPAR。不需要管理员交互，AMS 活动对于系统是透明的。
内存已经从 借给 。正在使用的内存为 4GB (pmem)，借出 2GB 内存 (loan)。请参考图 19。
图 19. 内存已经从 借给
图 20. 空闲
在 上启动工作负载。它借给 的内存又被收回。随着时间的推移，借出的内存量 (loan) 下降，这个 LPAR 上使用的内存量 (pmem) 增加。请参考图 21。
图 21. 在 上启动工作负载
现在，这两个 LPAR 的工作集大于共享内存池大小。由于要把内存还给 ，在 上发生 分页（hpi 和 hpit）。 上使用的内存量 (pmem) 从 8GB 下降到略超过 6GB。
图 22. 上使用的内存量
一旦 已经有了完成工作所需的内存，在 上的 分页（hpi 和 hpit）就停止了。请参考图 23。
图 23. 上的 分页停止
当 完成它的工作负载之后，在 上启动一个作业。内存再次从 借给 。随着时间的推移， 上使用的内存量 (pmem) 下降，借出的内存量 (loan) 增加。请参考图 24。
图 24. 上使用的内存量 (pmem) 下降
可以使用 vmo 在 LPAR 上修改 AMS Loan 。在默认情况下，只借出文件缓存页面。可以根据您需要的内存页面借用程度修改策略。请参考图 25。
图 25. 共享内存 LPAR 上的 vmo 设置
回页首
AMS 已经实现了！现在怎么办？
构成虚拟化环境的最后一种技术 已经出现了。我们可以让 AIX POWER 系统根据工作负载和需要自动地调整内存分配。不再需要 DLPAR 操作了！顺便说一句，AMS 支持用 DLPAR 调整内存，所以仍然可以动态地增加和减少 LPAR 的内存，只是现在分配的是逻辑内存而不是物理内存。
因为在虚拟化内存环境中有性能调优和监视方面的差异，我们还有许多要学习的东西。需要重新审视监视 AIX 内存的传统方法，要考虑 AMS 和逻辑内存的影响。与共享处理刚出现时一样，现在需要再次调整看待虚拟化资源监视和管理的视角，这一次要从内存的角度考虑问题。
在我的环境中，还有几个方面需要测试，比如为 AMS 配置双 VIOS、在启用了 AMS 的系统上执行 Live 以及对 (HACMP) 集群使用 AMS。我希望尽快找时间完成这些测试，然后向 AIX 社区提交报告。如果别人已经做了这些事，请告诉我！
回页首
结束语
我希望本文对 AMS 的简要介绍能够帮助您考虑如何部署和迁移到这种新技术。AMS 可能会大大提高在 和 技术方面的投资的回报，降低总成本。在系统之间共享内存有助于降低成本，提供更高效的内存部署方法。
如果您打算在自己的环境中使用 AMS，那么首先要考虑如何迁移到共享内存分区。首先采取最基本的步骤，比如：
目前还应该考虑参加关于 AMS 以及最新 和 AIX 技术的培训。
