发展大型机与扩展其他的后端IT平台不同。随着分布式计算的发展，如果容量规划人员发现当前服务器已经达到计算瓶颈，他们会往机架上添加更多的服务器作为解决方案。

然而，因为涉及到成本问题，大型机的容量规划更为谨慎和严格。开启新的处理器，甚至增加逻辑分区（LPAR）CPU上限，都能对大型机的硬件和软件成本产生巨大的影响。

在使用过程中，IBM大型机几乎为主机的每个使用周期都提供了诸如System Management Facility和Resource Management Facility这样的工具。同时，IBM借助Central Processing Complexes（CPC）来控制IT组织可以使用的处理器和微代码，从而简化大型机的升级过程。这种配置允许授权的IT部门使用IBM授权的一段微代码来执行“客户启动升级”（Customer Initiated Upgrade，CIU）。Capacity on Demand（CoD）对于永久升级是可行的，而On/Off Capacity on Demand（OOCoD）更适合临时升级。IT组织若需要动态的主机容量规划，则必须与IBM签署合同并具备已经安装的能容量升级记录。

z/OS操作系统容量规划管理的进阶

适用于z/OS 1.9或更高版本的Capacity Provisioning Manager（CPM）更好地实现了动态调整，允许依据工作负载的性能自动增加或删除容量。通过CPM，安装装置可以自行定义策略，如果工作负载的性能不佳，管理软件则根据该策略调用OOCoD以增加容量。当需求恢复至正常水平，CPM则削减容量。

CPM之所以能够做出这些决策，要归功于其与z/OS的工作负载管理器（WLM）接口。通过WLM，CPM监视工作负载以及满足性能目标的过程。然而，如果工作负载缺少标记，CPM将查看CPU和其他信息。它将综合考虑所有的因素，如果认为额外的容量不能起到帮助作用，它很可能不调用OOCOD，并降低有关工作负载的优先级。

CPM的规则涉及很多方面。随着最大和最小容量的变化，用户可以在每天不同的时间为不同的工作负载定义规则和阈值，以满足对额外容量的需求。更重要的是，当高峰时节过去，不再需要的容量会被关闭。

CPM依靠数百万服务单位（MSU）的常规处理器来管理容量。它是如何实现的？这取决于大型机用户的设置和软硬平台的实现。对于专门的处理器容量，CPM会随着zIIPs和zAAPs的上线或离线而发生变化。

z/OS 2.2版本升级

IBM的z/OS 2.2版本操作系统的升级包含了许多惊喜，正逐步地推动着z/OS的发展，这些惊喜包括Capacity Provisioning Manager、单指令多数据流指令以及zIIP处理器同时多线程技术等的拓展。

CPM功能拓展到硬件

依靠额外增加的容量，z/OS 2.2操作系统的发布将Capacity Provisioning功能拓展到硬件层面，按照处理器类型由CPC来监控该类处理器的忙闲。当CPU使用率超过一定的阈值，CPM将在线分配更多的引擎给需要它们的逻辑分区。当工作负载的短缺结束时，Capacity Provisioning Manager则会将多余的引擎移开。

针对这种引擎的辅助功能，CPM规则将CPC的逻辑名称组合在一起，就像定义盒子中的支持构件那样，放入配置域。在该策略中，用户定义使用条件，即为容量设置增减阈值和次数。这些条件不能用于管理定义和组容量。除了CPU使用情况，它们不考虑其他瓶颈。

CPC级别的动态容量不涉及WLM或工作负载是否能满足目标。由于CPM只关注处理器的忙闲，不重要的工作负载，如批处理文件，可能会引发较高的CPC利用率，从而增加容量调用，即使用户并不需要。然而，与过去的大型机技术相比，IBM设计这个方案是为了更积极地满足容量使用的峰值情况。

CPM值得信赖吗？

CPM对于管理具有高度变动性的工作负载是一个不错的解决方案。如果平台不具备此种平衡能力，要么导致容量过剩，要么尽早按照未来的需求对容量进行规划。

归结起CPM的缺陷，那就是成本，这也似乎是大型机绕不开的话题。大多数软件厂商，包括IBM在内，都基于处理容量进行报价。因此，动态主机容量规划的第一步是确保软件供应商的合同，在CPM增加马力时，成本不会大幅增加。对于某些软件，容量规划人员也必须将此因素考虑在内，深夜5分钟左右的峰值成本可能有整月成本那么多。

一切因素归根结底都要依靠规划。