一位客户配置 Active Memory Sharing 的经历.docx
《一位客户配置 Active Memory Sharing 的经历.docx》由会员分享，可在线阅读，更多相关《一位客户配置 Active Memory Sharing 的经历.docx（18页珍藏版）》请在冰豆网上搜索。
一位客户配置ActiveMemorySharing的经历
一位客户配置ActiveMemorySharing的经历
2009年9月23日
分享一位客户参与IBM®EarlyShipProgramforActiveMemorySharingonPOWER6™的经历。
了解这位客户如何在非生产AIX®实验室环境中配置和部署AMS。
您可以通过访问"IBMPower系列主机虚拟化专题”来了解其它的相关虚拟化文章：
∙IBMPower系列主机虚拟化专题
简介
我很幸运地参加了IBM的EarlyShipProgram（ESP）forActiveMemorySharing（AMS）onPOWER6。
本文介绍我如何在自己的非生产AIX实验室环境中配置ActiveMemorySharing。
我还要涉及AMS的性能考虑因素。
我希望本文能够帮助别人开始使用这种新的PowerVM™虚拟化技术。
我工作的组织参加了ESPforAMS。
因此，我们有机会先于别人（IBM之外的人员）几个月测试AMS。
既然AMS已经可供AIX和POWER6客户使用了，我认为应该与AIX社区分享我的经历。
参与beta测试计划是很棒的经历。
我们可以访问beta代码和文档。
我们还能够打开PMR，报告在测试期间发现的bug。
还有一个专门为ESP客户开办的论坛，我们可以在这里提出问题，从AMS开发人员那里直接得到回答。
IBM要求我们在非生产系统上测试AMS，定期提供报告，向开发人员提供性能、功能性和易用性方面的反馈。
回页首
概述
AMS是IBM对POWER6平台上的PowerVM虚拟化技术的一项改进。
这是一些客户一直盼望的特性。
它是构成完全虚拟化的AIX和POWER环境的最后一种技术。
AMS智能化地在逻辑分区（LPAR）之间转移内存，从而提高内存的利用率和灵活性。
这个概念与共享处理器池和微分区非常相似。
它允许在POWER6系统上使用超过预定量的内存，让系统（POWERHypervisor™）能够把内存分配给需要内存的地方。
不再需要DLPAR操作了！
当然，您需要了解AMS的工作方式，以及它如何与AIX上的虚拟内存和分页功能相互作用。
幸运的是，现有的性能工具已经得到改进，有助于监视和管理AMS系统。
那么，我们为什么需要AMS？
假设一个环境中有一台p6570，它有256GB内存，部署了32个AIXLPAR，分配给每个LPAR8GB内存。
所有内存都已经分配，不能由其他LPAR共享。
我们有未分配的处理器单元，可以使用它们建立更多LPAR，但是因为所有内存都被占用了，实际上无法这样做。
对于这种情况，通常的应对措施是激活更多内存（使用CUoD），或者购买并安装更多物理内存。
但是，如果其他LPAR能够共享一个LPAR上“未使用”或“空闲”的内存，当那个LPAR确实需要内存时交还内存，不是更好吗？
但是，如何查明LPAR是否确实需要所有内存呢？
由于AIX内存优化，这常常是个难以完成的任务。
执行一些工作负载分析，发现不会同时使用所有LPAR。
这是一个非生产系统，运行一套用于SAP/Oracle的开发和测试环境。
现在知道，尽管LPAR可能会占用分配给它们的所有内存，但是实际上它们不会同时使用所有内存。
是否可以重新分配“空闲”内存，把内存部署到确实需要内存的其他地方？
可以：
使用AMS就能够实现这个目标。
回页首
ActiveMemorySharing（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发挥作用，需要一个称为PagingVirtualI/OServer（VIOS）的新设备。
PagingVIOS设备为共享内存池提供分页服务，为共享内存的LPAR管理Hypervisor分页空间。
当在多个LPAR之间动态地管理内存时，Hypervisor必须使用分页设备存储共享内存池的物理内存不能储存的过剩内存。
这就引出了内存预订问题。
用AMS配置内存预订有三种方式。
第一种称为Nonover-commit。
在这种情况下，共享池中的真实内存量足够多，超过了配置的逻辑内存总量（例如，有四个LPAR，每个需要8GB，而共享池配置了32GB内存。
共享内存池足够满足LPAR的需要）。
第二种方法是Logicalover-commit。
在给定的时刻，“正在使用的”逻辑内存量等于池中的物理内存量。
因此，配置的逻辑内存总量可以大于池中的物理内存量。
但是，工作集（workingset）不会超过池中的物理内存量。
稍后详细讨论工作集。
在这种配置中，LPAR上正在使用的内存（工作集）位于物理内存中，而LPAR的逻辑内存的其余部分驻留在PagingVIOS上的分页设备上。
对于这种方法，一定要注意“正在使用的”内存和“配置的”内存之间的差异：
“配置的”逻辑内存可以超过内存池的大小，但是任何时候“正在使用的”内存不能超过内存池的大小。
最后一种配置是Physicalover-commit。
在这种情况下，所有LPAR的工作集内存需求可以超过池中的物理内存量。
因此，逻辑内存必须由池中的物理内存和PagingVIOS上的分页设备共同支持。
在发生“过量使用”时，Hypervisor使用VIOS上的分页设备存储过剩的逻辑内存。
那么，应该选用哪种方法呢？
如何判断哪些LPAR适合配置AMS？
这取决于工作负载需求。
从本质上说，任何不会达到其物理内存消耗上限的工作负载都适合配置AMS。
我喜欢采用Logicalover-commit方法。
这种方法最适合在不同时间到达峰值而平均内存使用量（工作集）比较低的工作负载，不太适合稳定的工作负载。
通常情况下，非生产性的开发和测试环境具有这些特征。
另外，故障转移或“备用”LPAR（例如用于PowerHA集群的LPAR）也非常适合AMS，这些LPAR用于提供冗余，只在发生故障转移/接管时需要资源。
为了决定最合适的方法，需要理解系统的工作集需求的概念。
工作集是系统上工作负载实际使用或需要的内存。
在把专有内存LPAR迁移到AMS之前，可以使用AIX性能工具（比如svmon）判断专有内存LPAR中使用的内存量。
Physicalovercommit方法适合那些使用大量AIX文件缓存、对I/O延迟不敏感（比如文件服务器、打印服务器或网络应用程序）而且在大多数时候不活跃的工作负载。
NIM服务器也是合适的AMS候选目标，因为它不经常使用，只用于安装AIX系统和执行维护。
根据我的测试，我建议对于具有以下特征的生产系统仍然使用专有的内存：
服务质量要求高，内存使用量稳定，需要可预测的性能，持续保持高CPU利用率，内存带宽要求高。
因此，我不会在我的生产环境中部署AMS。
其他一些环境也可能不适合使用AMS，例如StressandVolumeTesting系统。
回页首
我的工作负载适合吗？
在我的实验室环境中，必须判断我的工作负载是否适合共享内存池。
我有两个使用专有内存的现有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处理器的IBMPowerSystem
∙为了支持ActiveMemorySharing，需要启用企业版PowerVM
∙固件级别340_070
∙HMCversion7.3.4（用于HMC管理的系统）
∙VirtualI/OServerVersion2.1.0.1-FP20.0
∙AIX6.1TL3
∙Micro-partitiononly
∙VirtualI/Oonly
我的非生产实验室环境由一台JS22™刀片服务器组成，它有16GB内存和四个POWER6处理器。
这台刀片服务器上配置了一个VIOS（IVM）和两个AIX6.1LPAR。
ESP计划为我提供了要安装的beta代码，代码在我的JS22、VIOS和AIXLPAR上启用AMS。
我把这个实验室环境升级到提供的beta级别：
∙把刀片服务器的固件升级到EA340_043_039。
∙把刀片服务器上的VIOS升级到2.1.0.1-FP-20.0。
∙对VIOS和AIXLPAR应用AMSefixes。
∙应用启用AMS所需的VET代码。
两个LPAR都是现有的系统（使用专有内存），使用现有的工作负载。
第一个LPARbxaix85运行一个SAP/Oracle实例。
另一个LPARbxaix86运行三个应用程序：
SAP/Oracle、Wily和OracleGridControl，每个应用程序驻留在一个WorkloadPartition（WPAR）中。
这两个LPAR的工作集大约为9.3GB，这与池的大小相适应。
我运行了svmonc–G，观察正在使用的内存量，以此判断工作集。
请参考图3。
图3.svmon的输出显示LPAR上正在使用的专有内存量
LPAR工作集偶尔会增长，略微超过池的大小。
这很适合测试AMS及其性能。
我的目标是把这些现有的LPAR从专有内存迁移到共享内存并监视它们的性能。
回页首
配置ActiveMemorySharing
为了在我的实验室中配置AMS，我执行了以下步骤：
∙在VIOS上使用lsvet命令确认已经成功地激活了AMSVET代码。
请参考图4。
图4.确认已经启用了AMS
∙定义一个共享内存池。
使用IntegratedVirtualizationManager（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的topascec输出
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上修改AMSLoanPolicy。
在默认情况下，只借出文件缓存页面。
可以根据您需要的内存页面借用程度修改策略。
请参考图25。
图25.共享内存LPAR上的vmo设置
回页首
AMS已经实现了！
现在怎么办？
构成虚拟化环境的最后一种技术ActiveMemorySharing已经出现了。
我们可以让AIXPOWER系统根据工作负载和需要自动地调整内存分配。
不再需要DLPAR操作了！
顺便说一句，AMS支持用DLPAR调整内存，所以仍然可以动态地增加和减少LPAR的内存，只是现在分配的是逻辑内存而不是物理内存。
因为在虚拟化内存环境中有性能调优和监视方面的差异，我们还有许多要学习的东西。
需要重新审视监视AIX内存的传统方法，要考虑AMS和逻辑内存的影响。
与共享处理刚出现时一样，现在需要再次调整看待虚拟化资源监视和管理的视角，这一次要从内存的角度考虑问题。
在我的环境中，还有几个方面需要测试，比如为AMS配置双VIOS、在启用了AMS的系统上执行LivePartitionMobility以及对PowerHA（HACMP）集群使用AMS。
我希望尽快找时间完成这些测试，然后向AIX社区提交报告。
如果别人已经做了这些事，请告诉我！
回页首
结束语
我希望本文对AMS的简要介绍能够帮助您考虑如何部署和迁移到这种新技术。
AMS可能会大大提高在POWER6和PowerVM技术方面的投资的回报，降低总成本。
在系统之间共享内存有助于降低成本，提供更高效的内存部署方法。
如果您打算在自己的环境中使用AMS，那么首先要考虑如何迁移到共享内存分区。
首先采取最基本的步骤，比如：
∙把HMC升级到最新级别。
∙升级POWER6的固件。
∙把VIO服务器升级到version2.1。
∙把所有AIX系统升级到AIX6.1。
∙为迁移到AMS制定迁移战略。
找出适合配置AMS的系统。
例如，可以先从几个非生产性系统开始。
测试它们，直到您对性能满意了。
然后，重复这个过程，迁移更多系统，直到您需要虚拟化的所有内存都已经虚拟化了。
目前还应该考虑参加关于AMS以及最新POWER6和AIX技术的培训。
升级会员 