IBM Power 服务器上动态逻辑分区操作的若干制约因素，第 1 部分: 处理器篇

核心提示：动态逻辑分区（DLPAR）技术是 IBM Power 服务器的一项重要的虚拟化特性，可以在分区运行的情况下动态调整逻辑分区资源的分配，IBM Power 服务器上动态逻辑分区操作的若干制约因素，第 1 部分: 处理器篇，从而满足不断变化的业务需求，DLPAR 操作的过程或者结果受到一些因素的制约或影响，本文探讨了处理器

动态逻辑分区（DLPAR）技术是 IBM Power 服务器的一项重要的虚拟化特性，可以在分区运行的情况下动态调整逻辑分区资源的分配，从而满足不断变化的业务需求。DLPAR 操作的过程或者结果受到一些因素的制约或影响，用户应该清楚的知道这些因素，才能在 DLPAR 操作出现问题的时候从容应对。本系列文章探讨了 Power 服务器逻辑分区上 DLPAR 操作的各种典型的制约或影响因素，使读者对 DLPAR 操作有更加深入的认识。

动态逻辑分区（DLPAR）技术是 IBM Power Systems 服务器（简称 Power 服务器）的一项重要的 PowerVM 虚拟化特性，允许用户在逻辑分区运行的情况下动态调整资源的分配，从而更加有效的利用硬件资源来满足不断变化的业务需求。Power 服务器在不同管理方式下对 DLPAR 的支持情况不同，从表 1 可见，HMC 和 IVM 管理平台均支持 DLPAR。DLPAR 还需要分区操作系统的支持，AIX、RHEL（Red Hat Enterprise Linux）和 SLES（SUSE LINUX Enterprise Server）等主流的企业级 Unix/Linux 均支持 DLPAR（如图 1 所示）。

HMC 和 IVM 提供了简单有效的 DLPAR 操作界面，帮助用户方便的动态调节资源分配。DLPAR 的操作过程虽然简单，却受到一些因素的制约或影响，比如操作系统的支持、系统当前的空闲资源、处理器或内存的最小值和最大值、适配器的期望和必需属性、自定义共享处理器池、可删除的逻辑内存块以及虚拟 SCSI 适配器和虚拟磁盘的添加顺序等等。用户应该清楚的知道这些制约因素，才能合理地规划服务器的资源以及逻辑分区配置，并在 DLPAR 操作出现问题的时候从容应对，确保业务的连续高效运行。

本系列文章探讨了 Power 服务器逻辑分区上不同类型的 DLPAR 操作过程的各种典型的制约或影响因素，使读者更好的认识 DLPAR 操作，在发现问题的时候分析问题所在，找到纠错的方法。文章不涉及 DLPAR 环境设置过程中出现的问题，如有需要，读者可以阅读参考资料 6。本系列文章分成三个部分，分别讨论了处理器、内存和适配器 DLPAR 操作的制约因素。本文是第一部分，介绍了操作系统支持的最大处理器数、系统空闲的处理单元、最小值和最大值、微分区、自定义共享处理器池和同时多线程等制约因素。为了更好的理解本系列文章，需要读者具备 HMC 和 IVM 上 DLPAR 操作的知识和经验。如果需要了解这些方面的知识，建议读者翻阅参考资料 1 和 2。

表 1. 不同管理方式对 DLPAR 的支持

	被 HMC 管理	被 IVM 管理	独立服务器
POWER6 服务器	支持 DLPAR	支持 DLPAR	不支持 DLPAR
POWER5 服务器	支持 DLPAR	支持 DLPAR	不支持 DLPAR
Open Power 服务器	支持 DLPAR	支持 DLPAR	不支持 DLPAR
基于 POWER 的刀片服务器	不支持该管理方式	支持 DLPAR	不支持 DLPAR

图 1. 操作系统对 DLPAR 的支持

操作系统支持的最大处理器数

每个操作系统都有一些限制条件，表 2 是 AIX 和 Linux 在 Power 架构上所支持的最大处理器数目。这里所说的处理器是指操作系统内核可用于调度的逻辑处理器，而不一定是物理处理器（“同时多线程”一节将介绍 Power 服务器上的处理器概念）。表中，理论值指内核设计所能允许的最大处理器数目，而验证值则经过了测试和验证。虽然可以使用大于验证值的理论值，但是为了避免出现意想不到的结果，在配置分区或者进行 DLPAR 操作的时候，建议把处理器的配置控制在验证值以下。

表 2. 操作系统在 Power 架构上所支持的最大处理器数目

版本	最大（逻辑）处理器数目
AIX5.2	32
AIX5.3 及以上	64
AIX6	64
RHEL4	64（经过验证的） / 128（理论上的）
RHEL5	128（经过验证的） / 128（理论上的）
SLES10	128
SLES11	1024

系统空闲的处理单元

显然，处理器 DLPAR 添加操作受到当前系统空闲的处理单元数目的限制。图 2 所示的是 HMC 上处理器 DLPAR 添加操作的界面，页面显示该系统可用的处理单元数是 9.5，因此添加操作不能使用超过 9.5 个处理单元。当然，该限制只适用于物理处理器，虚拟处理器不受影响。

图 2. HMC 上的处理器 DLPAR 添加操作界面

图 3 和图 4 显示了一个由 HMC 管理的 POWER6 实验系统的逻辑分区以及处理器资源分配情况。细心的读者可能发现，图 4 中可用的处理单元数是 7.5，而图 2 显示的是 9.5。为什么会出现这种不一致的现象呢？原因在于图 4 中的数值并不包含未激活分区所释放出来的空闲处理单元（分区 spikelp5 和 taplp2 处于未激活状态，释放出 2 个处理器）。由此可见，系统空闲的处理单元应该以 DLPAR 操作界面所显示的数值为准。

图 3. HMC 管理的 POWER6 实验系统


图 4. 实验系统的处理器资源

在 IVM 上，系统空闲的处理单元的计算方法有所不同。图 5 中，扣除 3 个分区激活时所占用的处理器，系统还剩余 0.2 个处理单元；但是，如果按照 HMC 上的计算方法，由于分区 galluslp2 处于未激活状态，因此系统空闲的处理单元数应该是 2.0。那么，究竟哪种计算方法才适用于 IVM 呢？图 6 中，试着通过 DLPAR 为分区 galluslp1 添加 0.3 个处理单元，结果 IVM 拒绝了该操作。从错误报告中可见，系统空闲的处理单元数不足。如果添加 0.2 个处理单元，则操作能够顺利进行。这说明在 IVM 上，即使分区处于未激活状态，所分配的处理单元仍旧被保留着。要使用未激活分区的处理单元，可以打开分区属性减少处理单元数，然后激活分区，再把分区关掉，此时分区所占用的部分处理单元就被释放出来了。

图 5. IVM 管理的 POWER5 实验系统


图 6. IVM 的处理器 DLPAR 操作界面

最小值和最大值

处理器 DLPAR 操作受到最小值和最大值的约束，处理器的期望值必须介于这两个值之间。在专用处理器模式下，必须满足如下关系：处理器的最小值 < = 期望的处理器数 < = 处理器的最大值。在共享处理器模式下，这种约束关系更加复杂，因为不仅有处理单元数值之间的约束关系，虚拟处理器数值之间的约束关系，还有两者之间的约束关系：

处理单元数之间的约束关系：处理单元的最小值 < = 期望的处理单元数 < = 处理单元的最大值

虚拟处理器数之间的约束关系：虚拟处理器的最小值 < = 期望的虚拟处理器数 < = 虚拟处理器的最大值

处理单元数和虚拟处理器数之间的约束关系：0.1 < = 处理单元数 / 虚拟处理器数 < = 1.0，处理单元和虚拟处理器的最小值、期望值和最大值这三组数值都必须满足该关系

HMC 遵循这些约束关系控制着用户的处理器 DLPAR 操作请求；但是在 IVM 中，这种约束关系更加复杂。从参考资料 2 中可知，处理器的最小值、期望值和最大值都有暂挂值和当前值。这样就存在两组上述的约束关系：第一组就是暂挂值约束关系，用于控制命令 chsyscfg 或 chhwres 对暂挂值的修改；第二组就是当前值约束关系，用于控制 DLPAR Manager 所执行的暂挂值到当前值的同步过程。

分区的当前处理器资源可以动态调整，约束 DLPAR 的最小值和最大值是否也可以动态修改呢？参考资料 2 中，命令 chsyscfg 或 chhwres 可以动态修改最小值和最大值的暂挂值，但是不能动态修改它们的当前值，只有当分区重启或者关闭时，暂挂值才被同步到当前值。HMC 上的最小值和最大值没有暂挂值和当前值之分，那么对它们的修改是否能马上生效呢？图 7 中，将分区概要文件中的最大处理器数从 4.0 修改成 5.0，在图 8 所示的界面中试着把已分配的处理单元数增加到新的最大值，结果 HMC 拒绝该操作。这说明，在 HMC 管理 POWER6 服务器中，处理器的最小值和最大值不能动态修改，要使修改后的值生效，必须先关闭然后再激活分区。

图 7. 修改 HMC 分区概要文件中处理器的最大值


图 8. 新的处理器最大值不能动态生效

微分区

专用处理器可以提高分区的计算性能，而微分区技术（如图 9 所示）中的共享处理器则能够更加充分的利用处理器资源，允许在相同数量处理器的情况下划分更多分区。微分区允许把一个处理器的计算能力分成 100 份来使用，Power 服务器通过固件调度处理器在不同分区之间共享处理周期，提升了系统的灵活性。在微分区中，最小的处理单元是 0.01 个物理处理器，因此 DLPAR 操作必须以 0.01 为单位进行增删（注意分区所允许的最少处理单元数目是 0.1）。专用处理器模式不受此约束，最小的操作单位是 1 个完整的物理处理器。

图 9. 微分区

自定义共享处理器池

共享处理器池是微分区技术的一部分，每个使用共享处理器的分区都必须属于且只能属于某个共享处理器池。在 HMC 管理的 POWER5 / Open Power 服务器和 IVM 管理的各种服务器中只支持一个默认的共享处理器池，用户无需为分区分配处理器池，所有使用共享处理器的分区都默认属于该处理器池。当某个分区变成未激活状态时，不论是专用还是共享处理器，都被加入该处理器池；当该分区被激活时，所需的处理器资源就从该处理器池中分配。可见，在单一共享处理器池的情况下，处理器池中的空闲资源等价于系统空闲的处理器资源，因此共享处理器池对 DLPAR 的限制作用同上。

在 HMC 管理的 POWER6 服务器中，这种情况发生了变化。图 10 中，除了默认的共享处理器池 0 外，还允许创建自定义的共享处理器池 1 – n，每个自定义的共享处理器池都有如下 3 个数值。所有处理器池是默认存在的，但是只有处理器池 0 是默认激活的，自定义的处理器池最初处于未激活状态，可以通过设置最大处理单元来激活处理器池，激活时不需要设置保留处理单元，默认的保留处理单元是 0。

已分配处理单元（Entitled Pool Capacity）：该数值不是处理器池的设置，它是处理器池中所有分区当前已分配的处理单元和保留处理单元的总和

保留处理单元（Reserved Pool Capacity）：处理器池的设置之一，根据处理器池中各分区的负载，用于透明的动态调整分区的计算能力

最大处理单元（Maximum Pool Capacity）：处理器池的设置之一，是处理器池所允许的最大处理单元数目，必须是整数个处理器，处理器池中的保留处理单元和已分配处理单元的和不能大于最大处理单元

图 10. 多共享处理器池

在 HMC 管理的 POWER6 实验系统上，通过如图 11 所示的服务器菜单打开共享处理器池管理器（如图 12 所示）。图 12 中总共有 64 个共享处理器池，其中包括默认处理器池。默认处理器池的“保留处理单元数”和“最大处理单元数”是不可设置的，自定义处理器池除了 SharedPool01 外，都处于未激活状态，SharedPool01 的最大处理单元数是 1。用户可以通过点击共享处理器池的名称（比如 SharedPool01），在打开的页面中修改处理器池的配置（如图 13 所示）。图 14 显示了各共享处理器分区的共享处理器池分配情况，用户可以通过点击分区名称，在图 15 所示的页面中动态修改分区的处理器池分配。

图 11. 打开共享处理器池管理器


图 12. 共享处理器池的设置


图 13. 修改共享处理器池的设置


图 14. 分区的共享处理器池分配


图 15. 修改分区的共享处理器池分配

图 14 中，共享处理器池 1 中仅有分区 spikelp2，由于该处理器池最大处理器数为 1，且 spikelp2 当前所分配的处理单元数为 0.5，因此该处理器池还有 0.5 个可用的处理单元。在图 16 所示的处理器 DLPAR 操作页面中，试着增加 0.6 个处理单元，即把已分配的处理单元修改成 1.1，使之大于处理器池的最大处理单元数。图 17 中，由于处理器池中已分配的处理单元不能大于最大的处理单元，因此 HMC 拒绝了上述 DLPAR 操作。由此可见，在进行处理器 DLPAR 添加操作时，除了系统空闲的处理单元和最小值 / 最大值等因素外，还需要注意共享处理器池的可用处理单元数。如果在进行 DLPAR 操作前处理器池中的可用处理单元不足，那么可以先增加处理器池的最大处理单元，而后再动态增加处理器资源。

图 16. 增加处理单元使之大于处理器池的最大处理单元


图 17. HMC 拒绝上述 DLPAR 操作

同时多线程

POWER 处理器从 POWER5 开始支持同时多线程，该技术使得同一个物理处理器可以被当作两个逻辑处理器来使用。图 18 说明了 Power 服务器的处理器概念，在共享处理器的情况下，通用的操作系统不能管理非整数个数的处理器，POWER Hypervisor 为分区操作系统提供了虚拟处理器，因此操作系统只要知道如何使用虚拟处理器即可，虚拟处理器到物理处理器的映射或者调度由 Hypervisor 来完成。在同时多线程激活的情况下，一个物理处理器或者虚拟处理器被当成两个逻辑处理器来使用，因此同时多线程是否激活影响着处理器 DLPAR 操作的结果。AIX 上的命令 smtctl （清单 1） 或者 Linux 上的命令 ppc64_cpu （清单 2）用于查看或修改同时多线程的状态，用户可以根据该状态以及逻辑处理器数目的变化来判断处理器 DLPAR 操作是否成功执行。

图 18. Power 服务器的处理器概念


清单 1. AIX 上同时多线程对处理器 DLPAR 操作结果的影响
　DLPAR　前，SMT　处于激活状态，分区有　10　个逻辑处理器　
　
　#　smtctl　|　grep　"SMT　is　currently"　
　
　SMT　is　currently　enabled.　
　
　#　bindprocessor　-q　
　
　The　available　processors　are:　0　1　2　3　4　5　6　7　8　9　
　
通过　DLPAR　把虚拟处理器增加到　6　个　
　
　#　bindprocessor　-q　
　
　The　available　processors　are:　0　1　2　3　4　5　6　7　8　9　10　11　
　
禁止　SMT　后，分区只剩　6　个逻辑处理器　
　
　#　smtctl　-m　off　-w　now　
　
　smtctl:　SMT　is　now　disabled.　
　
　#　bindprocessor　-q　
　
　The　available　processors　are:　0　1　2　3　4　5　
　
通过　DLPAR　把虚拟处理器减少到　5　个，分区只剩　5　个逻辑处理器　
　
　#　bindprocessor　-q　
　
　The　available　processors　are:　0　1　2　3　4　

清单 2. Linux 上同时多线程对处理器 DLPAR 操作结果的影响
　DLPAR　前，SMT　处于激活状态，分区有　10　个逻辑处理器　
　
　[root@spikelp2　~]#　ppc64_cpu　--smt　
　
　smt　is　on　
　
　[root@spikelp2　~]#　cat　/proc/cpuinfo　|　grep　"^processor"　|　wc　-l　
　
　10　
　
　[root@spikelp2　~]#　
　
通过　DLPAR　把虚拟处理器增加到　6　个　
　
　[root@spikelp2　~]#　cat　/proc/cpuinfo　|　grep　"^processor"　|　wc　-l　
　
　12　
　
　[root@spikelp2　~]#　
　
禁止　SMT　后，分区只剩　6　个逻辑处理器　
　
　[root@spikelp2　~]#　ppc64_cpu　--smt=off　
　
　[root@spikelp2　~]#　cat　/proc/cpuinfo　|　grep　"^processor"　|　wc　-l　
　
　6　
　
　[root@spikelp2　~]#　
　
通过　DLPAR　把虚拟处理器减少到　5　个，分区只剩　5　个逻辑处理器　
　
　[root@spikelp2　~]#　cat　/proc/cpuinfo　|　grep　"^processor"　|　wc　-l　
　
　5　
　
　[root@spikelp2　~]#　

结束语

DLPAR 是 Power 服务器的一项重要的虚拟化特性，可以在不关闭分区的情况下动态调整系统资源的分配，从而更加灵活有效的利用硬件资源来满足不断变化的业务需求。DLPAR 操作过程受到众多因素的制约或影响，了解这些因素才能更好的解决 DLPAR 过程中遇到的各种问题。本文探讨了处理器 DLPAR 操作的各种典型的制约因素，包括操作系统支持的最大处理器数、系统空闲的处理单元、最小值和最大值、微分区技术、自定义共享处理器池和同时多线程等。本系列文章的其它部分将介绍内存和适配器 DLPAR 操作过程中各种典型的制约因素。