在缺乏合适的工具的前提下，实施IT服务优化将会是相当棘手的。
商品化服务器的服务器虚拟化一直是最为被企业组织所迅速采用的技术之一。现如今，传统且低效的“一台物理服务器搭配一种应用程序”的模式正在迅速的让位于虚拟服务器之间共享资源池。这不仅可以帮助企业组织节省数据中心的电源、冷却和占地空间等资源，还可以帮助企业通过避免对某些物理服务器实施过度配置来节省资金。虚拟化技术提供了一种更为灵活的解决方案，使得企业可以根据不断变化的实际需求来重新分配资源。
![]()
服务器虚拟化的概念固然有诸多显著的优势。但是，与生活中的许多事物一样，其不仅仅只有一面。资源的虚拟化为基础架构堆栈添加了一个新的抽象层。这一层应该使虚拟化解决方案变得更加灵活和高效，但同时也使得IT服务优化变得更为复杂。对于要求苛刻且性能至关重要的应用程序而言，这可能会导致服务等级协议的中断和违规。在实施或更新虚拟化策略时，记住这一点非常重要。
在本文中，我们将与广大读者朋友们共同讨论如何在复杂的虚拟环境中优化IT服务。
在讨论服务器虚拟化对容量管理和IT服务优化方面所带来的挑战时，我们需要对构成灵活虚拟化环境的机制有一个共同的理解。从概念上讲，其使用的是三种机制：
1、资源虚拟化：将分组资源集中到池中，由一款虚拟管理程序分配给不同的虚拟机。
2、动态资源调度：虚拟机管理程序具备根据当前需求自动分配资源，并将资源引导到相应虚拟机的能力。
3、无缝迁移：具备跨不同物理服务器进行资源调度的能力，使服务器集群或服务器场成为一个大型资源池。
通过使用这些机制，可以帮助企业解决计算环境中的一些传统的容量管理的难题。在“一款应用程序搭配一台物理服务器”的商品化平台时代，企业通常不得不为高峰时期的应用程序需求进行配置。而如果一般正常的需求水平比高峰期低得多，则大部分资源在大部分时间都没有使用。更糟的是，根据事件的周期性，高峰可能是数周或数月才有一次。在虚拟化环境中，可以在多个不同的虚拟机之间以及在多台物理主机之间共享需要用于峰值使用的额外动态空间，这一切对虚拟机中运行的应用程序都是完全透明的。结合旨在优化峰值时间需求的管理活动，动态的资源调度可以特别有效地防止过度配置。
但是，服务器虚拟化和动态资源是否能够彻底消除对容量管理的需求呢?显然不是，如下我们将做详细讨论。
挑战难题
一个典型的服务器虚拟化项目首先挑选从易于上手的地方开始，先易后难。从持续活动水平较低的商品化应用程序迁移到虚拟环境中开始着手。由于这些商品化工作负载通常运行在较老的基础设施上，性能较差，而且由于大多数资源对资源的要求可能不是特别高，所以在性能和服务质量方面有了初步的提升。这肯定了将工作负载迁移到虚拟服务器的决定，重点在于减少了物理主机的数量。
最终，当所有的较为容易的工作都已经被完成后，继续这个过程并且涉及更复杂的工作负载便是很自然的了。尽管服务器虚拟化从长远来看应该是为了节省资金，但实施虚拟化战略通常需要在新的基础架构上进行一些初步的前期投资。在许多情况下，企业IT部门所面临的情况是，为了实现合理和及时的投资回报，这些前期投资需要在大量的应用程序和服务之间共享。这将导致更多的工作负载，如电子邮件、数据库和ERP系统。他们在资源消耗方面要求更高，而且关键性要求也更高。这种应用程序的可用性和吞吐量都非常重要。他们可能会支持企业的核心流程，或直接面对客户。这意味着您企业需要特别小心如何操作和管理这些服务。确保您企业现在和可预见的将来有足够的容量能力。
容量管理的一个重要方面是对每项工作负载或应用程序进行恰当的描述，在分析一项工作负载时，有些方面非常重要：
资源的利用——该工作负载将使用什么资源，以及对资源的使用程度如何?
在线还是批量——该工作负载是否是在线情况下使用(在这种情况下，单个交易的响应时间便至关重要);抑或还是批量情况下使用(在这种情况下，总吞吐量则更为重要)
线性分布与指数分布——在暴露于强度增加的情况下，工作负载的性能如何?
工作负载的稳定性——工作负载是否始终维持相同的活动水平，还是会偶尔爆发更多的活动?
周期性与随机性——这些活动高峰是可预测的还是随机发生的?
综合所有这些信息的配置文件将为您企业提供关于如何管理特定工作负载以及资源需求的好主意，帮助您了解工作负载的特点。 当您开始在同一个物理资源上混合使用多个工作负载(这可能是您企业首先实施虚拟化的原因之一)，事情会变得更复杂一些。 如前所述，动态资源调度通常被用作解决容量需求变化的单一机制，无论是在一台物理主机内还是跨多台主机。但资源调度的效率和实用性在很大程度上取决于工作负载的特点。对于资源需求适中的一组工作负载通常很容易在不同主机之间进行平衡和迁移。但是，如果您开始将它们与更苛刻的工作负载混合在一起，那么您企业的选择会突然受到严格限制。
我曾经在伦敦举行的Gartner数据中心峰会上提出的一个类比似乎越来越受到人们的青睐，该类比说明了在尝试混合和匹配各种工作负载时可能出现的问题。在该峰会的演讲上，我建议使用类似俄罗斯方块的Block(块)来象征不同工作负载之间的不规则性。对资源需求适度的简单工作负载将由基本的两件式块来表示。更高的资源需求和更高的复杂性将导致该区块向各个方向扩张。
块越大，对称越少，将它们整合起来就越困难。无法将块组合转换为资源不足的工作负载，但无法迁移到其他主机。突然之间，在虚拟化环境中实现灵活性的两大关键机制变得无法使用。即使您企业能够将它们结合起来，大的不对称块也很可能导致白色空间碎片化和资源利用率低于您企业原先计算和计划的。
基于动态资源调度和无缝工作负载迁移的虚拟化环境的服务优化策略仅仅假定完全的移动性和工作负载的自由混合。但在许多情况下，事实证明这太简单了。除了具有不同的“工作负载人员”之外，由技术或商业环境所施加的其他一些限制也会产生影响(专门或专有的硬件配置、合同义务，有关数据分段的安全策略，变更管理程序等)。
总而言之，这表明需要更彻底的方法来实施企业级的虚拟化策略。为了让更多的要求和重要的工作负载虚拟化，单单依靠被动资源调度和工作负载的迁移机制是不够的。为确保服务得到***交付，需要在部署工作负载的布局和迁移策略之前进行调查和分析。
有哪些选择?
预测一项工作负载的容量需求的不同方法及其与其他工作负载共存的方法大致可以分为三类。
评估
这一类的方法严重依赖于“常识”和以往的经验。服务器虚拟化和整合方案的选择方法通常是将工作负载堆栈在一起，直到达到预定的阈值。但为了在这方面取得成功，您企业需要充分理解如下方面：
哪些指标与评估有关?
这些指标的正确阈值是多少?
企业如何使不同年代或不同指标的平台标准化?
当工作负载堆叠时，如何解释非线性的性能变化?
如果您企业对于上述任何信息的理解错误，都会导致做出不正确的预测。
评估和质量预测是基于观点和直觉，而不是硬性的事实。这类的工具集中在使程序更简单。在一天的工作结束时，对于质量的预测仍然取决于上述问题的答案。在大多数情况下，非线性增长等一些方面甚至没有得到解决。
分析建模
另一种预测工作负载混合的执行情况的方法是通过使用分析队列网络求解器。系统的队列网络(Queueing Network)模型便于分析模型求解器可以在数学上计算出排队延迟将在何处发生以及发生了多少排队延迟。在模型用于预测目的之前，其是根据服务器如何在实际中使用的经验研究来校准的。
在描述系统的模型中表示了对服务器性能十分重要的所有对象。
一旦建立了模型，就可以通过改变交易密度或在不同模型之间迁移工作负载来评估不同的场景。预测的交易的响应时间或吞吐量将告诉企业方案是否成功。可以把重点放在花费在排队上的时间和花费在系统上的时间之间的相对差异来消除对于每种交易类型明确的阈值的需要。这种关系的一个简单的经验法则会为企业提供一个关于配置场景状态的好主意。
这种类型的分析建模为优化混合工作负载环境提供了一个具有预测性，快速和可重复的过程。通过分析建模，结果的质量对执行它的个体的依赖性较小。同时也避免了假定性能随着工作负载堆栈而线性降级的常见错误。
综合负载测试
这里的目标是产生尽可能接近现实场景的综合交易。为了使事情正确，您企业需要仔细检查操作环境，以找到正确的事务组合和并发性，根据这些事务开发可重复的测试用例，并对与生产环境相同的设备执行冗长的性能测试(这可能会迫使您企业在并行测试环境中进行投资)。另外，您企业需要根据每种交易类型的响应时间来定义成功标准。
如果执行正确，负载测试能够提供高度的准确性。但是在大多数情况下，其成本和较长的测试周期是不合理的。在重要的服务上线之前，可能更适合“一生一次”的质量保证活动，而不是重复的IT服务优化练习。
那么您企业究竟应该选择哪种方法呢?最重要的是至少有一套切实可行的战略，而不仅仅只是依靠框架的反应机制来进行容量能力管理。在建立之后，***选择通常是采用不同方法的混合。您企业可能不想花太多时间来分析较不重要的实用程序应用程序，就像您企业无法承担快速简单分析关键业务服务的风险一样。有一个全面的工具箱，让您选择正确的方法以适合不同的情况是非常重要的。
结论
商品化服务器虚拟化供应商们希望您相信，他们的平台中内置的反应式性能管理技术是您企业获得***性能所需的全部。事实上，诸如动态资源调度和迁移等被动技术是有帮助的，但它们并不是一套完整的解决方案，并不一定能够使IT服务优化变得更加容易。从虚拟化环境中增加的复杂性实际上会使得确保从系统中获得所有的东西变得更加困难。
一个“足够大”的虚拟资源池不是轻而易举就能实现的。如果您企业不注意您所托管的工作负载的特征，那么您可能会过度配置应用程序或使应用程序资源不足。
为了确保工作负载能够相互高效地运行(或者类似俄罗斯方块的形状将能够彼此贴合)需要进行一些认真的分析。您企业需要了解很多有关底层应用程序的资源需求，才能知道一款工作负载是否会干扰另一款工作负载，进而造成不必要的资源争用和排队延迟。因此，特别是对于关键工作负载而言，进行一些仔细的前期分析是合理的，而不是简单地将各种工作负载扔到您企业的系统上，然后寄希望于动态资源调度和迁移能够快速高效地将所有事情整合在一起。
正如我们前面提到的，通过前期规划“评估”实现的优化工作负载布置通常需要将工作负载堆栈在一起，直到达到预定的阈值。这是大多数可用于调查数据中心和识别虚拟化可能性的工具所使用的技术。其结果是便宜且容易获得的，但仅仅只是粗略的估计。该估计本身并不会帮助您企业达到***性能。
“分析建模”并不像预测那样快速、简单、成本便宜，但是却非常接近我们的目的。(通过“分析建模”，我们特别指的是使用分析排队网络求解器进行建模，不太复杂的分析数学模型可能更好地被认为是“估计”工具。)建立分析建模比负载测试(或模拟建模)更简单，而且比估计更准确。
如果综合负载和底层系统配置是生产环境的代表的话，那么“负载测试”可以非常准确。然而，需要花费更多的时间和费用以便更接近于达到匹配生产负载和基础设施。在大多数情况下，使用这种技术来优化虚拟化环境中的IT服务是不现实的。然而，如果运行较小的测试，然后使用分析建模来预测在更令人印象深刻的系统配置中更大的负载可能发生的情况，则可能是一个有用的折衷方案。
总之，依靠IT服务优化的被动资源调度和工作负载迁移机制是不够的。在商品化的服务器虚拟化环境中运行要求苛刻的应用程序时，您企业需要做的工作更多。最明智的解决方案是提前计划，确保布置和迁移策略的设计能够保证工作负载能够高效地一起运行。估算工具对于简单工作负载的临时凑合分析是很好的。负载测试可能是非常有价值的，特别是当您企业推出全新的应用程序工作负载时，但是，用于优化在虚拟化环境中运行的关键应用程序的***全面技术则是使用排队网络解析器的分析建模。
