作为移动到云计算环境的一部分，公司利用规划流程和工具来实现成本的下降，提高系统部署的速度并提高系统可用性。这些流程和工具为系统管理员提供他们管理环境和计划以便满足将来计划需求所需要的信息。

云计算的一个承诺就是虚拟化将会减少所需服务器的数量，这会导致在硬件、软件许可证、能源和维修上的减少。因此，关键是要识别满足计算机和用户预期需求所需的云基础设施的最佳数量。计算资源太少，来自用户的请求必须等待资源释放或拒绝那些请求直到更多的硬件被添加到环境中。计算资源太多，硬件成本和其他费用就会否定云计算的成本削减承诺。

为了成功的计划云环境，系统管理员应该能够回答以下五个问题：

1. 在数据中心中有多少可用容量？
2. 有多少可用容量目前正在使用？
3. 容量将在何时释放？
4. 新请求的预测是什么？
5. 投资回报是什么？

本文介绍的一些概念有助于您理解云计算容量和如何为其进行计算。本文还介绍了一种工具，即 IBM® Infrastructure Planner for Cloud Computing，它可以帮助您实现移动到云计算的关键目标。

了解云容量

云计算环境由包含了可被许多用户和应用程序共享的资源的物理服务器组成。每一个服务器都具有磁盘存储和一个或多个附带内存的中央处理单元。因为云计算是虚拟化的，所以全部 CPU、内存和磁盘存储的一部分被分配给每个用户请求。这种资源的部分分配确保了最大的灵活性。

例如，一些应用程序需要大量磁盘存储而无需很大 CPU 功率。其他的则具有相反的要求 — 大量的 CPU 使用和少量的存储。云计算允许用户为他们的应用程序指定所需系统的每个资源量。

中央计算：定义虚拟 CPU

在规划云计算环境时，请注意 系统 CPU 不同于 虚拟 CPU。通常很难比较现代系统的处理能力。例如，去年的系统制造最有可能具有比今年系统制造更慢的处理器。较新的系统还会具有多内核的 CPU。

要减轻准确的系统资源分配和容量规划的挑战，已经在等于 1GHz CPU 处理能力的云 CPU 单元上对云环境进行了标准化。例如，在用户请求两个 CPU 时，他们将获得两个 1GHz CPU 的处理能力。这意味着如果一个系统具有两个 CPU，每个具有四个核，则以 3GHz 运行将具有相当于 24 个 CPU 单元：

2 CPU x 4 内核 x 3GHz = 24 CPU 单元

此计算非常有帮助，因为用户可以计划他们所需 CPU 的数量且具有对性能的合理预期；管理员可更容易地在多个请求中共享由一个系统提供的资源。总 CPU 容量可通过添加环境中可用的 CPU 单元来进行计算。

请注意：在比较不同平台上的云 CPU 单元时，IBM PowerVM™ 处理器系统中的 1GHz CPU 的处理能力不同于基于 Intel® 处理器上的 1GHz。为了得到准确的结果，只能在同一个平台内比较这些处理器。

物理 CPU 具有什么样的影响？

系统内可用物理 CPU 的数量是容量规划要考虑的另一个考虑事项。一个云可能会具有 100 个可用的 CPU 单元，但是如果云中最强大的系统只有 20 个物理 CPU 单元，这将变成对虚拟机请求的限制。

通过内存和存储来平衡 CPU

请注意 CPU 能力并不是实现成功容量规划的唯一因素。在容量规划需要做出有关 CPU 数量的正确决定时，它也涉及到将 CPU 信息与每一个系统所购买的内存和磁盘存储数量相平衡。

例如，购买具有 24 个 CPU 单元处理能力、但是仅 2GB 内存的系统在云环境中是毫无意义的。在这种情况下，在用户请求带有两个 CPU 和 2GB 内存的虚拟机时，该服务器将全部分配来填补这一单一请求。22 个未分配的 CPU 单元将仍然不可用于其他用户，因此要闲置此请求。

在制定云环境的硬件采购时正确地平衡系统资源非常重要。

您如何请求您的 IT 服务会有影响？

容量规划的主要目标是确保 IT 容量在适当的时候具有合适的大小，无论那一刻是现在、明天或者从现在开始的 20 年。一个使容量规划更加有效的重要工具就是查看 IT 服务的请求到达数据中心的方式。

传统观点

在传统数据中心中，系统管理员从未来发展项目的软件工程师那里接收 IT 资源的请求。管理员通常会每周审查 IT 请求以便确定什么资源可用以及哪些项目具有最高的优先级。较高优先级的项目会首先获得请求的答复。

在许多情况下，传统的数据中心可以在从制定分配资源决策的那时起不超过三周的时间内满足高优先级请求。然而，如果需要购买 IT 资源，则该过程可能要花费几个月。

具有较低优先级的项目可能需要等待很长的时间，这取决于预算和资源的可用性。在一些情况下，这些低优先级项目的请求根本不可能得到满足！

鉴于这种冗长、不确定的流程，用户变得习惯于 请求尽可能多的计算资源。不幸的是，这些请求常常超过用户真实的需要。一旦供应，这些资源会被小心翼翼的保护着，即便是在项目结束时，这些资源也不会被释放，除非用户被迫这样做。在传统 IT 模式的限制下，这种态度是可以理解的。毕竟，当前以及未来项目的成功都依赖于充足的 IT 资源。

但是，这种传统模式的惨痛教训是明确的：在开发周期内过多的资源常常会晚到，影响生产率和竞争力。在项目结束时，那些相同的资源（现在由用户囤积）成为没有得到充分利用的，浪费的容量。

来自云的观点

云计算为我们提供了非常不同的场景：

• 开发人员可访问他们可以输入其 IT 资源请求的网站 — 服务器、软件、存储等。
• 用户可马上知道这些资源是否可用。
• 如果资源可用，则可马上提交请求并自动路由到云管理员以审批。
• 由于流程是自动化的，所以请求通常在一小时内得到满足。
• 在项目结束或即将结束时，使用云的开发人员不再囤积计算资源，且今后在必要时知道他们可以方便快捷地访问相同的资源。

对于未来的项目来说，使用云的开发人员将同样只请求他们需要的资源而不是像他们在传统 IT 资源交付时习惯于的过渡供应。此外，云用户通常必须指定项目结束日期；除非这个日期延长，则云资源会在此日期自动返回可用资源池。因此，即使用户不特意释放资源，它们依然可以供他人使用。

从管理员的观点来看，云环境将手动、耗时的流程变为一次单击式、自动审批流程。有关数据中心云基础设施和资源可用性的信息以近实时的方式提供，即使管理员即时了解环境的总容量且剩余资源。

确定资源需要

让我们使用一个通用开发组织情景来检查资源需要：

一家公司正在为它们的由 150 位软件工程师组成的开发和测试组织实现全新的云环境。100 位软件工程师开发软件，40 位执行软件质量保障，10 位负责运行并维护其生产环境。

多大的云才能满足该组织的计算请求？我们需要回答两个主要的信息（当然，每一个都分解成子单位信息）：用户的需求和系统资源。如下所示：