IBM PowerVM Multiple Shared-Processor Pools 配置实例
Multiple Shared-Processor Pools 基本概念
对 IBM PowerVM 有一定了解的朋友对 Shared-Processor Pool 应该有一定的了解，关于它的概念，我们不再详细叙述。在操作时，我们可以通过 HMC 创建共享 CPU 池，包括 VIOS 和 VIOC 的所有分区的 CPU 资源都可以源自这个 CPU 池。而隶属于共享 CPU 池的分区通常被成为“微分区”（Micro Partition）。采用共享 CPU 池的好处是不仅可以提高 CPU 资源的利用率，也可以实现分区之间 CPU 资源的“按需分配”。
多共享 CPU 池（Multiple Shared-Processor Pools）的技术在 POWER6 及以后的 Power 平台上可以实现。这个技术可以允许在一个 Power 服务器上创建一系列的共享 CPU 池，从而使 CPU 虚拟化颗粒度更高，资源利用率更高。
例如，我们可以将 CPU 使用率峰值不同的微分区放在同一个共享 CPU 池里，以保证每个微分区的业务能够 7x24 顺利运转，同时也避免 CPU 的空闲。
在多共享 CPU 池的技术中，一台 Power 服务器最多可以有 64 个共享 CPU 池，包括一个 default Shared-Processor Pool0 和 63 个 user-defined Shared-Processor Pooln（n 的取值范围是 1~63）
Multiple Shared-Processor Pools 实现的条件
PowerVM 版本要求
PowerVM SE 和 EE 版本。
处理器版本要求
POWER6 及以上 CPU。
VIOS 上处理器数量要求
Multiple Shared-Processor Pools 需要通过 VIOS 实现。这个功能对 VIOS 分配的 CPU、内存的数量没有特别的要求。但需要注意的是，如果 VIOS 分区的 CPU 也源自 Shared-Processor Pools，我们建议将 VIOS 分区设置为 Uncapped，并且将 weight 数值最高（255），这样，在 VIOS 处理能力不足的时候，它可以优先获取空闲的 CPU 处理能力，以便其他 Micro Partitions 可以正常工作。
其它硬件需求
需要 HMC。
AIX 操作系统版本要求
AIX 5.3 和 AIX6.1 以及 AIX7.1
Multiple Shared-Processor Pools 的参数
Maximum Pool Capacity
这个参数在创建共享 CPU 池的时候可以进行设置，它规定一个 CPU 共享池中可供微分区使用的最多 CPU，这个参数设置单位必须是整数个 CPU。
Reserved Pool Capacity
这个参数在创建共享 CPU 池的时候可以进行设置，这部分 CPU 资源共享会在 CPU 池创建时预留的，在正常情况下不分给微分区使用，只有当 Uncapped 的微分区 CPU 需求大于共享 CPU 池中的空闲 CPU 资源加上共享 CPU 池中其他微分区可供借用的空闲 CPU 资源时（需要参数设置，并非空闲的 CPU 资源都可被其他微分区借用），Reserved Pool Capacity 的 CPU 资源才被使用。
需要指出的是，除了默认的共享 CPU 池（default Shared-Processor Pool0），用户定义的共享 CPU 池（user-defined Shared-Processor Pooln）的 Maximum Pool Capacity 与 Reserved Pool Capacity 两个参数是可以动态调整的，这一点非常有用，也非常重要。我们在下面的试验中，会设置到对这两个参数的动态调整。
为了使您对多共享 CPU 池理解更为深刻，我们还需要介绍另外一个相关的概念：Entitled Pool Capacity。
Entitled Pool Capacity
共享 CPU 池的 Entitled Pool Capacity 的数值不能在创建共享 CPU 池的时候进行设置。它的数值等于所有微分区的 Entitled CPU 之和加上 Reserved Pool Capacity（这个数值通常设置为 0）的数值。一个共享 CPU 池的所有微分区能够获得到的 CPU 资源的总和加上共享 CPU 池的预留 CPU 资源的数值不能大于 Maximum Pool Capacity。
Entitled Pool Capacity 计算公式为：
所谓微分区（或者普通的 LPAR）的 Entitled CPU，我们可以理解成分区处于工作状态时实际得到的 CPU 资源。我们激活一个微分区的时候，它会尝试获取 CPU 资源，当分区可以获得到的 CPU 资源小于概要文件中设置的“最小处理单元”数量时（当其他参数条件允许的情况下，比如 VP 的数量足够 , 分区是 uncapped 的），分区将无法激活。
当微分区可以获得到的 CPU 资源大于等于概要文件中设置的“最小处理单元”数量，但小于概要文件中设置的“期望处理单元”，这个分区将以实际能够得到的 CPU 资源数量激活（当其他参数条件允许的情况下，比如 VP 的数量足够 , 分区是 uncapped 的）。
当微分区可以获得到的 CPU 资源大于等于概要文件中设置的“期望处理单元”时（当其他参数条件允许的情况下，比如 VP 的数量足够 , 分区是 uncapped 的），它将以“期望处理单元”设置的 CPU 数量启动。
当微分区以“期望处理单元”设置的 CPU 数量启动的时候（当其他参数条件允许的情况下，比如 VP 的数量足够，分区是 uncapped 的），如果此时微分区的 CPU 使用率非常高，CPU 非常繁忙（接近 100%）时，若微分区为 uncapped 分区（当其他参数条件允许的情况下，比如 VP 的数量足够），它将尝试从它所隶属的共享 CPU 池索取额外的 CPU 资源，从而使 Entitled CPU 的数值大于概要文件中设置的“期望处理单元”的数值。但是，能够获取的额外 CPU 资源数量的一个前提是额外获取到的 CPU 数量与“期望处理单元”的 CPU 数量总和不能大于微分区概要文件中“最大处理单元”设置的数量。
所以，简而言之，（当其他参数条件允许的情况下，比如 VP 的数量足够 , 分区是 uncapped 的）一个微分区的 Entitled CPU, 即微分区工作时实际获得到的 CPU 资源应该大于等于分区概要文件中设置的“最小处理单元”的数值但小于等于概要文件中设置的“最大处理单元。
例如在下图的例子中，有两个共享 CPU 池，分别成为“Production”和“Development”。以“Production”为例，Entitled pool capacity 的数值加上 Reserved pool capacity 的数值不能大于 Maximum pool capacity 的数值。
图 1.CPU Pool 配置案例
创建 Multiple Shared-Processor Pools 配置实例
配置一个共享 CPU 池
我们首先通过浏览器登陆 Power 服务器的 HMC。
登陆到 HMC 以后，选择我们要进行多共享 CPU 池配置的服务器 , 然后依次选选择“配置”->“虚拟资源”->“管理共享处理器池”
图 2. 选择“管理共享处理器池”
在接下来的配置界面中，我们可以看到一共有 64 的共享 CPU 池，其中的 default pool，即默认共享 CPU 池的参数是无法被修改的：
鼠标点击 Default pool，得到如下的提示：
图 3.DefaultPool 的状态
尝试修改 default pool 的参数：
图 4. 修改缺省池属性告警
因此，default pool 的参数是在其创建的时候配置，我们在此处只能对 user-defined Shared-Processor Pool（1~63）进行配置。
在下图中，我们可以看到 SharedPool02~ SharedPool63 的“保留处理器单元数”和“最大处理器单元数”均为 0，说明这些共享 CPU 池目前并没有被配置和使用。
图 5.SharedPool02~ SharedPool63 的状态
下面，我们将对 Shared-Processor Pool2 进行配置，
点击下图中“SharePool02”：
图 6.Shared-Processor Pool2 的状态
在下图中，我们可以对 “池名称”、“保留处理器单元数”和“最大处理器单元数”三项参数进行设置，通常情况下“池名称”不进行修改，使用默认名字即可。
在本例中，我们分别将“保留处理器单元数”和“最大处理器单元数”设置为 0.11 和 2.
图 7.Shared-Processor Pool2 的参数的修改
需要注意的是: “保留处理器单元数”（Reserved processing units）我们可以以颗粒度为 1/100 个 CPU 进行设置。但是“最大处理器单元数”（MAX processing unit）的数值我们只能被设置成整数个 CPU( 最大数量为 256)。由于“保留处理器单元数”的数值是预先分配的，因此这个数值要设置成可以达到的数值。例如，目前 Power 服务器可用于分配的 CPU 只有 2 个，我们如果将“保留处理器单元数”设置为 3 的话，将会有类似如下告警产生 :
图 8.Shared-Processor Pool2 修改时的告警信息
按照上面的方面，成功配置完 SharePool02 的参数并点击“确定”以后，在列表中我们可以看到共享 CPU 池 Shared Pool02 的参数：
图 9.Shared-Processor Pool2 修改完毕后的状态信息
接下来，我们将查看 CPU 池与微分区映射关系的配置，还是在上图所示的界面上，点击“分区”标签：
图 10.Shared-Processor Pools 与分区的映射关系
上图中，我们可以看到所有的微分区都属于 DefaultPool0 或者 SharedPool01 两个共享 CPU 池。
下面，我们创建一个新的微分区，并将这个分区的 CPU 指向 SharedPool02。
创建一个隶属于 SharedPool02 的微分区
回到 HMC 界面，点击“创建逻辑分区”->”AIX 或 Linux 分区”，如下图，将分区的名称设置为“Test”
图 11. 创建一个分区步骤 1
将分区的概要文件命名为“Normal”，然后点击“下一步”按钮：
图 12. 创建一个分区步骤 2
下图中的选项是最为关键的，一个分区是否为“微分区”则在此处确定。
在这里，我们选择“共享”处理器。设置完以后，点击“下一步”按钮。
图 13. 创建一个分区步骤 2
在下图中，我们将设置微分区 CPU 的相关参数并选择共享 CPU 所隶属的共享 CPU 池。
我们选择刚刚创建的共享 CPU 池 SharePool02。由于之前我们已经将共享 CPU 池 SharePool02 的“最大处理器单元数”设置为 2，因此此处，微分区“Test”的“期望处理单元”、“最大处理单元”的数值均不能大于 2。我们分别将其设置为 1,2。
图 14. 创建一个分区步骤 3
对于微分区虚拟 CPU 的设置，我们可以根据实际的性能需要进行设置；为了使微分区的 CPU 资源可以根据需要进行自动调整，我们可以选择分区为“不受限”（uncapped），权重取中间值：128（取值范围 0~255,255 的级别最高）
图 15. 创建一个分区步骤 4
在接下来的步骤中，需要对微分区的内存、I/O 的配置。由于这些配置与普通 LPAR 配置无异，因此本文不再进行详细描述。
微分区成功配置以后，我们在 HMC 的控制界面中可以看到其信息 :
图 16. 查看新创建分区的信息
下面，我们将微分区激活：
图 17. 激活新创建的分区
此时，我们再次选择 HMC 上的选择配置 ->虚拟资源 -> 管理共享处理器池，查看多共享 CPU 池的状态。
在下图中选择“分区”标签，以便我们查看 Shared Pool02 与分区的对应关系 :
在下图中选择“分区”标签，以便我们查看 Shared Pool02 与分区的对应关系 :
图 18. 查看 CPU Pool 的映射关系
此时，我们可以看到，名字为“Test”的微分区隶属于 Shared Pool02 共享 CPU 池。
图 19. 查看 CPU Pool 的映射关系
微分区隶属的共享 CPU 池迁移
在进行共享 CPU 池迁移之前，我们需要注意：将一个微分区指定给另外一个共享 CPU 池的时候，要确保这个迁移动作不会使这个共享 CPU 池的 Entitled Pool Capacity 超过 Maximum Pool Capacity, 否则将会报错，我们下面将会模拟这个故障现象。
首先，我们模拟一下共享 CPU 池的 Entitled Pool Capacity 超过 Maximum Pool Capacity 数值，造成迁移失败的情况。
我们对微分区“Test”与共享 CPU 池“Shared Pool01”的隶属关系进行修改，将 Test 微分区的共享 CPU 池修改为由“Shared Pool02”修改为“Shared Pool01”：
在下图中点击 Test（6）
图 20. 迁移 Test（6）分区步骤 1
将下图中“池名称”选项选则为“SharedPool01”，然后点击“确定”按钮 :
图 21. 迁移 Test（6）分区步骤 2
过了大约 6 秒钟以后，将出现如下的告警 :
图 22. 迁移 Test（6）分区告警信息
这时，我们需要修改 Shared Pool01 的“最大处理器单元数”，以便我们可以将 Test 分区迁至这个共享 CPU 池：
我们将 Shared Pool01 的“最大处理器单元数”由 12 修改为 14，将“保留处理器单元数”由 6 减少到 4 时：
图 23. 修改 SharedPool01 参数
然后进行确认：
图 24. 修改 SharedPool01 状态
此时，我们再度进行 Test 微分区的共享 CPU 池迁移，和上面一样，我们点击“分区”标签，然后点击 Test（6）分区，然后将微分区的共享 CPU 池选成 SharedPool1：
图 25. 迁移 Test（6）分区步骤 2
过了大概 6 秒钟以后，迁移完成：
图 26. 迁移 Test（6）分区步骤 3
此时，我们已经看到，Test（6）分区已经隶属于 SharePool01 分区。但是，此时我们的工作还没有完成。我们还需要手动修改 Test 分区的概要文件：
图 26. 迁移 Test（6）分区步骤 4
然后保存退出。
删除一个共享 CPU 池
一个共享 CPU 池中可能包含 1 个或者多个微分区。如果一个共享 CPU 池不再使用，我们可以将其删除。删除的步骤是首先将这个共享 CPU 池中的微分区迁移走或者删除，使其不包含任何微分区。
我们以 Shared Pool02 为例，按照之前我们讲到的方法，查看共享 CPU 池与微分区的映射关系：
图 27. 分区与 Shared Processor Pools 的对应关系
可以看出，共享 CPU 池 Shared Pool02 中不包含任何微分区。
确认完这一点以后，我们选择将 Shared Pool02 的“保留处理器单元数”与“最大处理单元数”都设置为 0：
图 28. 修改 Shared Pool02 参数
大概 3 秒钟以后，修改完成，Shared Pool02 中的 CPU 资源已经被释放：
图 29. 确认 Shared Pool02 状态
我们通过这种方法，可以删除一个不再使用的共享 CPU 池。
总结
如本文所讲，通过 HMC 进行 Multiple Shared-Processor Pools 的实施是非常方便的。通过 Multiple Shared-Processor Pools 功能，我们可以更好地实现 IT 资源的“按需分配”。通过这个功能，我们也可以将业务所需要 CPU 处理能力的颗粒度变得的更高，更好减少客户 IT 设备的闲置资源，从而降低客户的 IT 成本。