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 的数值。

回页首

创建 Multiple Shared-Processor Pools 配置实例

配置一个共享 CPU 池

我们首先通过浏览器登陆 Power 服务器的 HMC。

登陆到 HMC 以后，选择我们要进行多共享 CPU 池配置的服务器 , 然后依次选选择“配置”->“虚拟资源”->“管理共享处理器池”

在接下来的配置界面中，我们可以看到一共有 64 的共享 CPU 池，其中的 default pool，即默认共享 CPU 池的参数是无法被修改的：

鼠标点击 Default pool，得到如下的提示：

尝试修改 default pool 的参数：

因此，default pool 的参数是在其创建的时候配置，我们在此处只能对 user-defined Shared-Processor Pool（1~63）进行配置。

在下图中，我们可以看到 SharedPool02~ SharedPool63 的“保留处理器单元数”和“最大处理器单元数”均为 0，说明这些共享 CPU 池目前并没有被配置和使用。

下面，我们将对 Shared-Processor Pool2 进行配置，

点击下图中“SharePool02”：

在下图中，我们可以对 “池名称”、“保留处理器单元数”和“最大处理器单元数”三项参数进行设置，通常情况下“池名称”不进行修改，使用默认名字即可。

在本例中，我们分别将“保留处理器单元数”和“最大处理器单元数”设置为 0.11 和 2.

需要注意的是: “保留处理器单元数”（Reserved processing units）我们可以以颗粒度为 1/100 个 CPU 进行设置。但是“最大处理器单元数”（MAX processing unit）的数值我们只能被设置成整数个 CPU( 最大数量为 256)。由于“保留处理器单元数”的数值是预先分配的，因此这个数值要设置成可以达到的数值。例如，目前 Power 服务器可用于分配的 CPU 只有 2 个，我们如果将“保留处理器单元数”设置为 3 的话，将会有类似如下告警产生 :

按照上面的方面，成功配置完 SharePool02 的参数并点击“确定”以后，在列表中我们可以看到共享 CPU 池 Shared Pool02 的参数：

接下来，我们将查看 CPU 池与微分区映射关系的配置，还是在上图所示的界面上，点击“分区”标签：

上图中，我们可以看到所有的微分区都属于 DefaultPool0 或者 SharedPool01 两个共享 CPU 池。

下面，我们创建一个新的微分区，并将这个分区的 CPU 指向 SharedPool02。

创建一个隶属于 SharedPool02 的微分区

回到 HMC 界面，点击“创建逻辑分区”->”AIX 或 Linux 分区”，如下图，将分区的名称设置为“Test”

将分区的概要文件命名为“Normal”，然后点击“下一步”按钮：

下图中的选项是最为关键的，一个分区是否为“微分区”则在此处确定。

在这里，我们选择“共享”处理器。设置完以后，点击“下一步”按钮。

在下图中，我们将设置微分区 CPU 的相关参数并选择共享 CPU 所隶属的共享 CPU 池。

我们选择刚刚创建的共享 CPU 池 SharePool02。由于之前我们已经将共享 CPU 池 SharePool02 的“最大处理器单元数”设置为 2，因此此处，微分区“Test”的“期望处理单元”、“最大处理单元”的数值均不能大于 2。我们分别将其设置为 1,2。

对于微分区虚拟 CPU 的设置，我们可以根据实际的性能需要进行设置；为了使微分区的 CPU 资源可以根据需要进行自动调整，我们可以选择分区为“不受限”（uncapped），权重取中间值：128（取值范围 0~255,255 的级别最高）

在接下来的步骤中，需要对微分区的内存、I/O 的配置。由于这些配置与普通 LPAR 配置无异，因此本文不再进行详细描述。

微分区成功配置以后，我们在 HMC 的控制界面中可以看到其信息 :

下面，我们将微分区激活：

此时，我们再次选择 HMC 上的选择配置 ->虚拟资源 -> 管理共享处理器池，查看多共享 CPU 池的状态。
在下图中选择“分区”标签，以便我们查看 Shared Pool02 与分区的对应关系 :

此时，我们可以看到，名字为“Test”的微分区隶属于 Shared Pool02 共享 CPU 池。

微分区隶属的共享 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）

将下图中“池名称”选项选则为“SharedPool01”，然后点击“确定”按钮 :

过了大约 6 秒钟以后，将出现如下的告警 :

这时，我们需要修改 Shared Pool01 的“最大处理器单元数”，以便我们可以将 Test 分区迁至这个共享 CPU 池：

我们将 Shared Pool01 的“最大处理器单元数”由 12 修改为 14，将“保留处理器单元数”由 6 减少到 4 时：

然后进行确认：

此时，我们再度进行 Test 微分区的共享 CPU 池迁移，和上面一样，我们点击“分区”标签，然后点击 Test（6）分区，然后将微分区的共享 CPU 池选成 SharedPool1：

过了大概 6 秒钟以后，迁移完成：

此时，我们已经看到，Test（6）分区已经隶属于 SharePool01 分区。但是，此时我们的工作还没有完成。我们还需要手动修改 Test 分区的概要文件：

然后保存退出。

删除一个共享 CPU 池

一个共享 CPU 池中可能包含 1 个或者多个微分区。如果一个共享 CPU 池不再使用，我们可以将其删除。删除的步骤是首先将这个共享 CPU 池中的微分区迁移走或者删除，使其不包含任何微分区。

我们以 Shared Pool02 为例，按照之前我们讲到的方法，查看共享 CPU 池与微分区的映射关系：

可以看出，共享 CPU 池 Shared Pool02 中不包含任何微分区。

确认完这一点以后，我们选择将 Shared Pool02 的“保留处理器单元数”与“最大处理单元数”都设置为 0：

大概 3 秒钟以后，修改完成，Shared Pool02 中的 CPU 资源已经被释放：

我们通过这种方法，可以删除一个不再使用的共享 CPU 池。

回页首

总结

如本文所讲，通过 HMC 进行 Multiple Shared-Processor Pools 的实施是非常方便的。通过 Multiple Shared-Processor Pools 功能，我们可以更好地实现 IT 资源的“按需分配”。通过这个功能，我们也可以将业务所需要 CPU 处理能力的颗粒度变得的更高，更好减少客户 IT 设备的闲置资源，从而降低客户的 IT 成本。

参考资料

• 通过参考 《IBM PowerVM Virtualization Introduction and Configuration》，了解虚拟化的更多信息。
  
  
• 通过参考 《PowerVM Virtualization Managing and Monitoring》，了解虚拟化的更多信息。
  
  
• “System p 中的虚拟化”（developerWorks，2007 年 12 月）：利用虚拟化的优势，可以最大程度地利用您的各种资源。虚拟化是一种现代方法，从 POWER4 开始，在所有的 System p™ 服务器中都提供了这种方法。本文介绍了物理和逻辑分区，特别是关于如何实现逻辑分区的内容。
  
  
• “Power Systems 虚拟化简介”（developerWorks，2009 年 12 月）：本文向您详细地介绍了 Power System 虚拟化相关的技术和亮点，让您对这些最新的虚拟化技术有一个全面的了解。
  
  
• “PowerVM 磁盘虚拟化”（developerWorks，2010 年 11 月）：PowerVM 是 IBM 的 Power Systems 虚拟化技术，它现在提供两种对通过 Virtual I/O Server (VIOS) 访问存储设备的连接进行虚拟化的方法。可以使用 Virtual SCSI (vSCSI) 和 N_Port ID Virtualization (NPIV) 访问存储设备。本文介绍一个混合的概念，即同时使用 vSCSI 和 NPIV 实现虚拟服务器。
  
  
• “Power7 虚拟化管理中的强大功能 - 分区的挂起和恢复”（developerWorks，2011 年 9 月）：本文主要介绍了 Power7 虚拟化管理中的一个新功能，分区的挂起和恢复，首先是基本原理和概念的阐述，然后对系统状态转换进行了描述，最后给出了具体实施中的操作步骤。
  
  
• AIX and UNIX 专区：developerWorks 的“AIX and UNIX 专区”提供了大量与 AIX 系统管理的所有方面相关的信息，您可以利用它们来扩展自己的 UNIX 技能。
  
  
• AIX and UNIX 新手入门：访问“AIX and UNIX 新手入门”页面可了解更多关于 AIX 和 UNIX 的内容。
  
  
• AIX and UNIX 专题汇总：AIX and UNIX 专区已经为您推出了很多的技术专题，为您总结了很多热门的知识点。我们在后面还会继续推出很多相关的热门专题给您，为了方便您的访问，我们在这里为您把本专区的所有专题进行汇总，让您更方便的找到您需要的内容。
  
  
• AIX and UNIX 下载中心：在这里你可以下载到可以运行在 AIX 或者是 UNIX 系统上的 IBM 服务器软件以及工具，让您可以提前免费试用他们的强大功能。
  
  
• IBM Systems Magazine for AIX 中文版：本杂志的内容更加关注于趋势和企业级架构应用方面的内容，同时对于新兴的技术、产品、应用方式等也有很深入的探讨。IBM Systems Magazine 的内容都是由十分资深的业内人士撰写的，包括 IBM 的合作伙伴、IBM 的主机工程师以及高级管理人员。所以，从这些内容中，您可以了解到更高层次的应用理念，让您在选择和应用 IBM 系统时有一个更好的认识。
  
  

关于作者

为本文评分

评论

回页首

内容

• Multiple Shared-Processor Pools 基本概念
• Multiple Shared-Processor Pools 实现的条件
• Multiple Shared-Processor Pools 的参数
• 创建 Multiple Shared-Processor Pools 配置实例
• 总结
• 参考资料
• 关于作者
• 评论