自从基于服务器的计算出现以来，容量管理作为一门运营学科已经存在多年了，其甚至可追溯到大型主机时代。而鉴于每一代的服务器平台都会创造自己独特的要求，这使得支持这一学科的相关商业工具也已经存在30多年了。伴随着数据中心从大型主机发展到中端计算，又从客户端服务器向虚拟化方向发展，使得数据中心业界对于容量管理工具的需求也在逐步发展。
虚拟化技术的普及采用尤其带来了智能工作负载管理(IWM)的问题，使得容量管理不再是确保应用程序性能的充分解决方案了。特别是当将传统的容量管理解决方案用于现代数据中心时，会面临以下一系列的根本缺陷：
传统的平台不足以应付现代数据中心实时的运营操作
中央指数分析迫使传统的容量管理解决方案需要批量执行，使得这些解决方案无法适应不断变化的应用程序需求。
传统的容量管理解决方案完全依赖于历史数据，因此无法应对不可预测的应用程序的需求模式。
这些传统的容量管理解决方案所给出的生产的建议甚至往往在被执行之前就已经被淘汰了。
这些传统的容量管理解决方案依赖于历史数据，故而不适用于云原生(cloud-native)应用程序工作负载。
传统平台仅侧重于基础设施，同时还忽略了应用程序的性能
这些传统的容量管理解决方案使用不适合的分析算法，专注于基础设施利用率，而不考虑应用程序性能。
传统的容量管理解决方案没有将工作负载需求与基础设施供应相关联的语义来确保应用程序的性能。
确保现代数据中心的应用程序性能需要一款能够解决智能工作负载管理问题的实时控制系统。但伴随着虚拟化技术兴起而出现的软件定义的数据中心的设计并不包括这个系统。
数据中心容量管理的定义
市场调研机构Gartner公司对容量管理工具做出了如下的定义：
“IT基础架构-容量管理工具可以生成与基础架构 -容量相关的报告，并能够执行历史数据分析和容量相关分析，同时具备IT和业务场景规划的能力。这些工具的特点在于它们能够广泛的与来自各个不同领域的专用工具(例如实时性能监视工具)的数据充分集成整合在一起的卓越功能;能够为各种各样的基础设施组件提供预测、咨询和自动化;能够对影响基础设施性能绩效的潜在因素进行深入的分析;以及他们对假设情景及其与在线分析处理(OLAP)业务报告工具的集成的支持。
容量管理工具的目标是为了解答以下问题：
我所在企业的数据中心是否具备足够的基础设施容量能力来支持企业当前和未来的工作负荷?如果没有，那么，我企业何时必须获得额外的容量;及什么类型的容量?
改变我所在企业的数据中心的基础架构的容量或配置将会产生什么影响?
在各种操作环境之间迁移工作负载的***方式是什么?
关于容量管理历史的简单回顾
容量管理工具最初是为支持IBM的大型主机而开发的。彼时，主要的驱动因素是大型主机的硬件成本过于昂贵，因此，业界花费了大量的精力以便准确地确定究竟需要多少硬件。
伴随着中档服务器的出现，容量管理的问题开始不再被业界突出强调。尽管确定具体应该采购多少硬件的问题仍然非常的重要，但是两大趋势使得这方面的问题不再是业界的突出重点难题了。首先，硬件的成本变得不那么昂贵，因此使得企业客户具体需要采购多少容量的精度变得不那么重要。第二，虽然主机在单台服务器上运行了多款应用程序，但中端系统往往是每台服务器上只运行单款应用程序。这简化了规划的过程，同时还减少了对复杂工具的需求。
接下来，从中端UNIX系统到基于Wintel平台的客户端-服务器系统的转变，再次改变了格局。服务器的价格开始下滑，且大多数服务器仍然是单一的应用程序。这继续削弱了容量管理工具的价值。
随着虚拟化技术的出现，容量管理问题开始看起来更像是大型主机的问题。借助虚拟化技术，使得企业客户在同一台服务器上运行多款应用程序再次成为常态。另外，虽然单台服务器的成本持续下降，但服务器的数量却大幅增加了。
根据Gartner公司在2014年的市场调研显示，仅不到5%的企业正在使用IT基础设施容量管理工具。他们进一步估计，到2018年，只有30%的企业将采用这些工具——年复合增长率只有5%。鉴于这一工具类别已然成熟，那么，一个显而易见的问题便是：“为什么数据中心业界对于该工具的普及采用率如此之低呢?”而由此引发的进一步思考是：“鉴于其在数据中心业界的普及采用率如此之低，为什么其普及采用的增长还如此缓慢呢?”
容量管理与工作负载管理
伴随着虚拟化技术的出现，尽管多款应用程序可以在单台服务器上同时执行，但这些应用程序并不是在单款操作系统实例中执行的。管理程序处理的是资源的共享而不是操作系统。这使得问题的范围从计算资源扩展到了包括存储和网络资源。
此外，确保应用程序性能所需的智能工作负载管理功能被排除在管理程序层之外。虽然容量管理仍然是一种有用的规划工作，但对于确保性能的管理程序来说，这并不是一个充分的补充。
在现代数据中心确保应用程序的性能
任何数据中心运营团队的主要目标都是确保其应用程序的性能，同时***限度地利用所需的基础架构资源。在现代数据中心运营中所进行的每项活动(包括配置、监控、容量管理和自动化)都是为了支持这一主要目标。
虽然有人声称，通过自动化补充的容量管理可以解决智能工作负载管理问题，但这是不正确的。的确，容量管理对于确定未来的容量需求和规划迁移是相当有用的，但是，事后考虑增加自动化并不能为确保应用程序的性能提供适当的平台。其并不能填补虚拟机管理程序层之外的智能工作负载管理的空白差距。采用这种方法的解决方案会带来以下方面的不足：
1、这些解决方案使用不适合的分析算法，仅仅只专注于基础设施的利用，而不考虑应用程序的性能。
2、这些解决方案完全依赖于历史数据，因此无法处理遇到不可预测的需求模式的应用程序。
3、这些解决方案的强力分析迫使他们需要批量执行分析，并定期自动化，从而妨碍了这些解决方案对不断变化的需求做出反应。
4、这些解决方案所提出的建议往往在被执行之前就已然被淘汰了。
5、这些解决方案依赖于历史数据，故而并不适用于云原生应用程序工作负载。
最近，一些容量管理工具增加了根据其分析生成建议的能力，在某些情况下，可以通过脚本或与外部业务流程系统集成来处理这些建议。
然而，在所有情况下，这种容量管理工具所使用的分析集中在提高基础设施利用率，而不是确保应用程序的性能。这是非常有问题的，因为重新配置基础架构以实现效率，而不考虑性能可能会导致严重的应用程序性能问题。
当涉及到虚拟机的安置时，容量管理解决方案依赖于一种装箱问题 (bin-packing)算法，其中利用率峰值与峰谷匹配，以便优化所讨论的基础设施的密度。这种不复杂的方法有几个基本问 题。
1、无法实时执行
在计算理论中，装箱算法被归类为一种组合的NP-hard(非确定性多项式，non-deterministic polynomial)问题。这意味着找到该问题的解决方案是属于非常计算密集型的，由此导致的结果是，依赖于装箱算法的分析必须以批量的方式连续地实时运行。因此，由分析产生的自动化操作是周期性的而不是持续执行的。这类似于在文件系统本身内置写入优化之前磁盘碎片整理是如何发生的。
这种方法的核心问题是，其根本无法确保应用程序的性能，因为只有实时自动化可以通过不断配置基础设施资源来满足当前应用程序的需求，进而应对波动的应用程序需求。
2、无法处理不可预测的需求
鉴于分析是批量定期运行的，它们只是基于历史数据，因此只有当未来的需求是紧密反映了历史需求时，那么这些数据才是准确的。
虽然这种方法对于定期的容量管理可能是已经足够了，但是却完全不适合实时应用程序的性能控制。许多现代应用程序具有不可预测的需求模式，故而仅仅依赖于历史数据分析是不足的。
例如，虚拟桌面工作负载并没有一致的历史数据。即使传统的交易处理应用程序也会遇到不可预测的需求峰值，正是这些情况对业务流程产生了负面影响。为了使分析引擎能够确保应用程序的性能，其必须充分考虑到历史和当前的实时工作负载的需求。
此外，由于自动化操作(如安置决策)只能定期执行，并且无法解决不可预测的需求，因此他们必须依靠净空分配(headroom allocation)来允许足够的备用容量来处理意外的需求峰值。这种净空分配实际上降低了底层基础设施的有效使用，并不是解决波动需求的充分解决方案。使用净空方法，企业数据中心必须选择留下足够的未使用容量来处理任何预期的需求高峰或风险的性能问题。适当的解决方案能够实时响应波动的需求，消除过度配置和或将带来性能风险之间的困难选择。
3、无法规模化的扩展缩放
由于bin-packing算法是NP-hard，其添加了多个维度，所以不容易实现规模化的扩展缩放。事实上，在基础架构领域，随着算法扩展到不仅仅考虑计算，而且需要考虑存储、网络和应用程序，执行分析所需的时间和资源也在呈指数级的增长。因此，不仅算法不规模化扩展缩放，其也不能实时转换为执行，因此无法保证应用程序的性能。***，跨越多个领域扩展是非常困难的——不仅仅是计算，而且好包括网络、存储和应用程序。
4、自动化属于事后的想法
传统的容量管理工具的出现早于软件定义的数据中心，故而其最初并没有考虑自动化的因素。因此，执行分析，操作计划的制定及执行是独立执行的阶段。通常情况下，自动化是通过脚本或第三方业务流程来实现的，这使得解决方案的部署、配置和维护大大复杂化了。另外，因为自动化只能在完成分析之后发生，所以不能实时执行。
5、操作执行计划不可靠
由容量管理工具所制定的操作执行计划会遭受到一些致命的困扰——这些操作执行计划可能而且通常是不可用的。因为分析是基于历史数据而批量运行的，所以由这些数据所生成的所有操作执行计划都是基于这样的假设前提：当执行操作时，环境处于与数据捕获分析时相同的状态。因此，如果环境在数据捕获的时间与执行动作的时间之间发生了任何方式额变化，则这些操作将是无效的。
此外，因为所有操作是相互依赖的，所以单个更改(例如一台迁移的虚拟机)可能会使得整个操作计划无效。这种变化可能会发生在(由于算法的计算密度，通常需要花费几个小时)分析正在执行时，甚至在行动计划本身正在执行的过程中。事实上，如果在尝试执行行动计划之前没有办法确定是否发生了任何无效的变更，这种状况将进一步加剧。 因此，在动态变化的基础设施中执行操作行动计划的任何尝试都是不可靠的。
6、不适用于云原生工作负载
***，基于历史分析的批量的容量管理完全不适用于云原生工作负载。越来越多的应用程序正在通过使用部署在容器(container)中的微服务来水平扩展。这些基于容器的微服务器将根据应用程序的需求而不断创建和实时销毁。因此，历史数据不足以执行批量容量分 析。传统的批量容量管理解决方案完全不适用于云原生工作负载，这意味着在不久的将来它们将面临淘汰。事实上，云原生工作负载只能由实时控制系统管理。
结论
正如我们所看到的，容量管理工具并不适合确保应用程序的性能，因为它们无法实时执行、无法处理不可预测的需求、不能规模化扩展缩放、生成的操作执行计划也根本不可靠，并且完全不适用于云原生工作负载。
确保现代数据中心应用程序性能所需要的是一款实时的控制系统，其可以解决随着虚拟化技术的出现，软件定义的数据中心的设计被被排除在外的智能工作负载的管理问题。
