数据中心容量管理并不是什么新鲜事，但整个数据中心业界所采取的方式则是不断发展渐近式的。虚拟化技术正带来下一个进化步骤，随之而来的则是下一波的容量管理工具。

现代数据中心正在经历一个新的问题。智能工作负载管理(IWM)问题意味着容量管理不再是确保应用程序性能的充分解决方案了。

本文中，我们将帮助广大读者朋友们详细了解当传统的容量管理无法奏效时，如何借助一款实时的控制系统来解决此问题。

自从基于服务器的计算出现以来，容量管理作为一门运营学科就已经存在了，其甚至可以追溯到大型主机的时代。支持这一学科的商品化工具也已经存在了30多年了，每一代的服务器平台均创造了其独特的要求。而随着数据中心从大型机发展到中端计算，并从客户端服务器向虚拟化方向发展，业界对于容量管理工具的需求也在逐步发展。

虚拟化技术尤其带来了智能工作负载管理(IWM)的问题，其中容量管理不再是确保应用程序性能的充分解决方案。特别是：现代数据中心的传统容量管理解决方案面临着以下几大根本缺点：

传统平台不适合实时操作

中央指数分析迫使传统平台批量执行，因此无法适应不断变化的应用程序需求。

传统平台完全依赖于历史数据，因此无法应对不可预测的应用程序需求模式。

传统平台的生产建议在执行之前经常被淘汰。

传统平台依赖于历史数据，但这不适用于云原生本机应用程序工作负载。

传统平台侧重于基础设施，忽略应用程序的性能

传统平台使用不恰当的的分析算法，专注于基础设施的利用率，而不考虑应用程序的性能

传统平台没有将工作负载需求与基础设施的供应相关联的语义来确保应用程序的性能

保证现代数据中心应用程序的性能需要一款能够解决智能工作负载管理问题的实时控制系统。而随着虚拟化技术的出现，软件定义的数据中心的设计并不包括这一系统。

定义容量管理

市场调研机构Gartner所定义的容量管理工具如下：

IT基础架构—容量管理工具可以生成基础架构—容量相关的报告，能够执行历史数据分析和容量相关分析，并具备IT和业务场景规划能力。

这些工具的特点在于它们具备与来自各种领域的专用工具(例如实时性能监控工具)的数据集成在一起的功能的广泛性;能够为各种不同类型的基础设施组件提供预测、咨询和自动化;深入分析有助于基础设施绩效的潜在因素;并提供对于假设情景及其与在线分析处理(OLAP)业务报告工具的集成支持。

容量管理工具的目标可以用来回答以下问题：

我所在的企业是否有足够的基础设施容量能力来支持我目前和将来的工作负载呢?如果没有，那么我何时必须获得额外的容量以及什么类型的容量?

改变我企业基础设施的容量或配置将会产生什么影响?在不同环境之间迁移工作负载的最佳方式是什么?

容量管理简史

容量管理工具最初是为了支持IBM大型主机而开发的。主要的驱动因素是源于大型主机的硬件过于昂贵，因此需要消耗大量的精力用来确定需要多少硬件。

随着中档服务器的出现，容量管理开始不再被强调。虽然确定企业究竟应该购买多少硬件仍然很重要，但是两大趋势使得这一点地重要性已经不那么突显了。首先，硬件设备变得越来越便宜，因此购买精确度的容量变得不那么重要。第二，虽然主机在单台服务器上运行了许多应用程序，但是中档系统往往是在每台服务器运行单个应用程序。这简化了规划的过程，减少了对复杂工具的需求。

接下来，从中端UNIX系统到基于Wintel平台的客户端-服务器系统的转变，再次改变了动态。服务器的价格开始下滑，而大多数服务器仍然是单一应用程序。这继续削弱了容量管理工具的价值。

随着虚拟化技术的出现，容量管理问题开始看起来更像是主机问题。借助虚拟化技术，在同一台服务器上运行多款应用程序再次成为常态。另外，虽然单台服务器的成本持续下降，服务器的数量却大幅增加。

尽管如此，据Gartner的调研显示，截至2014年，仍然只有不到5%的企业正在使用IT基础架构容量管理工具。他们进一步估计，到2018年，只有30%的企业将采用这些工具——复合年增长率只有5%。鉴于该类别的工具是成熟的，显而易见的问题是：“为什么该工具在当今企业的采用普及率这么低呢?此外，鉴于这种低渗透普及率，为什么采用增长得如此缓慢呢?”

容量管理与工作负载管理

随着虚拟化技术的出现，虽然多款应用程序能够在单台服务器上同时执行，但它们不能够再在单个操作系统实例中执行。虚拟管理程序处理的是资源共享而不是操作系统。故而问题的范围从计算资源扩展到包括存储和网络资源。

此外，需要确保应用程序性能所需的智能工作负载管理功能不在管理程序层中。虽然容量管理仍然是有用的规划工作，但对于绩效保证的虚拟管理程序来说，这并不足够。

确保现代数据中心的应用程序性能

任何运营团队的主要目标都是要确保其应用程序的性能，同时最大限度地利用所需的基础架构资源。在现代数据中心运营中所进行的每项活动包括配置、监控、容量管理和自动化都支持这一主要目标。

虽然有人声称，自动化补充的容量管理可以解决智能工作负载管理问题，但这是不准确的。的确，容量管理是确定未来容量需求和规划迁移的有用工具，但如果将增加自动化作为事后考虑，并不能为保证应用程序的性能提供适当的平台。智能工作负载管理的缺陷不会超出管理程序层。采用这种方法的解决方案有以下缺陷：

1、他们使用专注于基础设施利用的不恰当的分析算法，而不考虑应用程序的性能。

2、它们完全依赖于历史数据，因此无法处理所遇到的不可预测的需求模式的应用程序。

3、他们的强力分析迫使他们执行批量分析，并定期自动执行，从而妨碍了他们对不断变化的需求做出反应。

4、他们所提出的建议经常在被执行之前淘汰

5、它们依赖于历史数据，这不适用于云原生本机应用程序工作负载。

最近，其中一些容量管理工具增加了根据其分析生成建议的能力，并在某些情况下，可以通过脚本或与外部业务流程系统集成来处理这些建议。

然而，在所有情况下，这种容量管理工具所使用的分析集中在提高基础设施的利用率，而不是确保应用程序的性能。这是非常有问题的，因为在不考虑性能的情况下，重新配置基础架构的效率可能会导致严重的应用程序性能问题。

当涉及到虚拟机的安置时，容量管理解决方案依赖于二进制装箱算法(bin-packing algorithm)，其中利用率峰值与峰谷相匹配，以便优化所讨论的基础架构的密度。采用这种不复杂的方法会有几大根本性的问题。

无法实时执行

在计算理论中，装箱算法被归类为一种组合NP-hard(非确定性多项式，non-deterministic polynomial)问题。这意味着解决问题的方案非常计算密集，因此，依赖于装箱算法的分析必须以批量的方式连续地实时运行。故而由分析产生的自动化动作是周期性执行的，而不是持续执行。这就类似于在文件系统本身内置写入优化之前如何进行磁盘碎片整理。

这种方法的核心问题是，其根本无法保证应用程序的性能，因为只有实时自动化才可以通过不断配置基础设施的供应来满足当前的应用程序需求，进而应对波动的应用程序需求。

不能处理不可预测的需求

因为分析是批量定期运行的，所以它们只是基于历史数据，因此只有未来的需求密切反映历史需求，那么这些数据才是准确的。

虽然这种方法对于定期的容量管理可能是足够的，但可能完全不适合实时应用程序的性能控制。许多现代应用程序具有不可预测的需求模式，使得依据历史数据进行分析是不足的。

例如，虚拟桌面工作负载没有一致的历史数据。即使传统的事务处理应用程序也会遇到不可预测的需求峰值，正是这些场景对业务流程产生了负面影响。为了使分析引擎能够确保应用程序的性能，其必须考虑到历史和当前的实时工作负载需求。

此外，由于自动化操作(如布局决策)只能定期执行，并且无法解决不可预测的需求，因此他们必须依靠净空分配(headroom allocation)来允许足够的备用容量处理意外的峰值需求。这种净空分配实际上降低了底层基础设施的有效利用率，并不是处理波动需求的充分解决方案。使用净空分配方法，必须选择留下足够的未使用的容量来处理任何预期的尖峰或风险的性能问题。而适当的解决方案则能够实时响应需求波动，消除了过度配置和带来性能风险之间的困难选择。

不能规模化缩放

因为装箱算法是NP-hard，添加了多个维度，所以不容易规模化缩放。事实上，在基础架构领域，随着算法的扩展，不仅仅是要考虑计算，而是考虑到存储、网络和应用程序、执行分析所需的时间和资源呈指数级增长。因此，不仅算法不能规模化缩放，而且还不能实时转换为执行，因此无法保证应用程序的性能。最后，跨多个域是非常困难的——不仅仅是计算，而且还包括网络、存储和应用程序。

自动化是事后的想法

传统的容量管理工具早于软件定义的数据中心诞生，最初并没有考虑到自动化。因此，执行分析，制定行动计划以及执行行动计划是独立执行的阶段。通常情况下，通过脚本或第三方协调器实现自动化，这使得解决方案的部署、配置和维护大大复杂化了。另外，由于自动化只能在完成分析后发生，所以无法实时执行。

不可靠的行动计划

容量管理工具所产生的操作计划会遭致一个致命的错误——它们可能而且往往是无法使用的。因为分析是从历史数据中批量运行的，所以它们生成的所有操作都是基于这样的假设：当执行操作时，环境处于与捕获数据分析时相同的状态。因此，如果环境在捕获数据的时间与执行操作的时间之间以任何方式发生了变化，则这些操作无效。

此外，因为所有操作是相互依赖的，所以单个更改(例如移动的虚拟机)可能使整个操作计划无效。当分析正在执行时，这种变化可能会发生(由于算法的计算强度，通常需要几个小时)，甚至在操作计划本身正在执行的过程中发生。事实上，如果在尝试执行操作计划之前无法确定是否发生了任何无效的变化，这会使得情况进一步加剧。因此，在动态变化的基础设施中执行生成的操作计划的任何尝试都是不可靠的。

不适用于云原生工作负载

最后，基于历史数据分析的批量容量管理完全不适用于云本地原生工作负载。越来越多的应用程序正在使用在容器中部署的微服务来水平扩展。这些基于容器的微服务根据应用程序的需求不断创建和破坏，因此，历史数据不足以用来执行批量容量分 析。传统的批量容量管理完全不适用于云本地原生工作负载，这意味着在不久的将来，它们将面临淘汰。事实上，云本地原生工作负载只能由一个实时控制系统来管理。

结论

正如我们所看到的，容量管理工具不适合保证应用程序的性能，因为它们无法实时执行、无法处理不可预测的需求、不能规模化扩展、生成根本不可靠的操作计划、并且完全不适用于云本地原生工作负载。

确保现代数据中心应用性能所需要的是一款实时的控制系统，以解决智能工作负载的管理问题，随着虚拟化技术的出现，这些问题在软件定义数据中心的设计中被忽略了。