私有云概念

私有云概念

原文地址： http://blogs.technet.com/b/privatecloud/archive/2010/12/20/private-cloud-concepts.aspx

本文是陈述构成全面私有云方法的 上下文、 原则和概念的系列文章的一部分。每篇文章都提供了下一篇文章的基础，因此最好依次阅读。

以下概念是支持这些原则并促进 (Microsoft) 私有云构成的抽象或战略。它们由一条或多条原则指导，并直接为此类原则提供支持。

实现可用性的全面方法

为了实现不间断可用性的理念，必须在实现可用性的过程中采用一种全面的方法。传统上，可用性是衡量 IT 服务交付成功与否的主要指标，通过度量正常运行时间的百分比（例如，99.99% 的可用性）的服务水平目标进行定义。然而，仅仅通过可用性目标定义服务交付成功会造成“越多越好”的错误假设，无法考虑使用者实际需要的可用性程度。

在将可用性作为成功指标的背后，有两种基本假设。首先，任何服务中断的长度都足以引起使用者的注意；其次，每次出现中断时都会对业务造成严重的负面影响。此外还可合理假设，恢复服务所需的时间越长，对业务造成的影响就越大。

有两种主要因素会影响可用性。首先是通过平均故障间隔时间 (MTBF) 度量的可靠性。MTBF 用于测量服务中断之间的时间。第二是通过恢复服务的平均时间 (MTRS) 度量的弹性。MTRS 度量从服务中断开始起至服务恢复时的总耗时。实际上，通常需要人为干预来检测和响应事件，这限制了 MTRS 的降低。因此，组织通常通过关注 MTBF 来实现可用性目标。通过更高的可靠性实现更高的可用性需要追加冗余硬件方面的投资，并且会使实现和维护此硬件的成本呈指数级增长。

在传统数据中心内，MTRS 平均超过一个小时，而动态数据中心能够在短短几秒之内从故障中恢复。与故障的自动化检测和响应以及基础架构内的警告状态相结合，能够大幅降低 MTRS（从 IaaS 的角度）。因此，弹性的大幅提升可降低可靠性因素的重要性。可用性（正常运行时间的分钟数/年）不再是 IT 服务交付成功与否的主要度量指标。对于可用性以及不可用性的业务影响的认识成为成功的指标。

利用全面的方法，即可使用软件工具取代物理冗余的传统模型，从而实现更高级别的可用性和弹性。

传统数据中心中的 MTRS 和 MTBF 与动态数据中心的对比

物理硬件的同质化

物理硬件的同质化是推动可预测性的关键概念。底层基础架构必须为托管的工作负荷提供一致的体验，以便实现可预测性。这种一致性是通过底层服务器、网络和存储的同质化实现的。

从硬件层到虚拟化的服务抽象使“服务器 SKU 差异化”成为物理结构以外的一种逻辑。这消除了物理服务器级别的差异化需求。更高的计算组件同质化将使可变性大幅降低。这种可变性的降低将提高基础架构的可预测性，从而改进服务质量。

最终目标在于同质化计算、存储和网络层，使服务器之间不再存在差别。换句话说，所有服务器都将采用相同的处理器和内存；所有服务器都连接到相同的存储资源和网络。这意味着任何虚拟化服务的运行和功能均在所有物理服务器上保持一致，因此可将服务从即将发生故障或已经发生故障的物理服务器无缝地重新定位到另一台物理服务器，而不会使服务行为发生任何变化。

可想而知，物理基础架构的全面同质化是不可行的。尽管推荐将同质化作为战略，如果这种做法不可行，至少应尽可能地将计算组件标准化。

资源池化

利用共享的计算资源池是关键。这种资源池是一组共享资源，包括计算、存储和网络，构成了托管虚拟化工作负荷的结构。这些资源的子集将按需分配给客户，并在不在需要时重新返回给池。理想情况下，资源池应尽可能同质化和标准化。

虚拟基础架构

虚拟化就是将硬件组件抽象为逻辑实体。尽管虚拟化的实现方式在各基础架构组件（服务器、网络和存储）内各有不同，但收益通常相同，包括在资源管理任务中缩短或消除停机时间、提高可移植性、简化资源管理和获得共享资源的能力。虚拟化是其他概念的催化剂，比如弹性基础架构、共享资源的分区和资源池化。基础架构组件的虚拟化需要无缝集成，以便提供流畅的基础架构，保证能够处理需求的增加和减少，并提供各组件的全局或分区资源池。

结构管理

“结构”这个术语应用于资源池的集合。结构管理是一种高于虚拟化的抽象级别，采用与虚拟化抽象物理硬件相同的方法，结构管理将服务从特定虚拟机监控程序和网络交换机中抽象出来。结构管理可视为业务流程引擎，负责管理使用者工作负荷（共同交付服务的一个或多个虚拟机）的生命周期。结构管理对应于服务请求（例如，配置一个新虚拟机或一组虚拟机）、系统管理事件（例如，根据警告或故障移动/重启虚拟机）和服务管理策略（例如，向使用者工作负荷添加另一个虚拟机，以响应负载）。

传统上，服务器、网络和存储是独立管理的，往往以各项目为基础进行管理。为了确保弹性，我们必须能够自动检测硬件组件是否以更低的容量运行或者是否发生了故障。这就要求理解所有共同交付服务的硬件组件以及这些组件彼此之间的关系。结构管理提供了对于这种彼此之间的关系的理解，以便确定组件故障影响了哪些服务。这使结构管理系统能够确定是否需要采取自动化响应操作来防止中断，或者快速将发生故障的服务恢复到结构中的另一个主机之上。

从提供商的角度来看，结构管理系统是确定可用保留容量和现有结构资源健康状况的关键所在。这也确保了服务能够满足使用者所需的指定服务水平。

弹性基础架构

弹性基础架构的概念支持无限容量。弹性基础架构允许按需分配资源，更重要的是，还允许在不再需要资源时将其返回资源池。在不再需要容量时缩减的能力常常被忽视或重视不足，从而导致服务器消耗更多资源并导致缺乏资源使用优化。有必要使用基于使用情况的定价来鼓励使用者对其资源使用情况负责。自动化或基于客户请求的触发器可确定何时分配或回收计算资源。

实现弹性基础架构要求 IT 与业务之间的密切协调，需要在容量管理工作中充分理解和合理规划峰值使用和增长率模式。

共享资源的分区

通过共享资源来优化使用是一项关键原则，但同时也有必要了解何时需要对这些共享资源进行分区。尽管完全共享的基础架构能提供最佳的成本和敏捷性优化，但可能存在一些法规要求、业务驱动因素或多租户问题，要求不同级别的资源分区。分区战略可在多层实施，比如物理隔离或网络分区。与冗余性相似，堆栈中发生这种隔离的级别越低，其成本就越高。分区战略可能需要额外的硬件和保留容量，比如隔离资源池。最终，业务将需要平衡与分区战略相关的风险和成本，基础架构将需要能够提供一种安全的方法来隔离基础架构和网络流量，同时依然受益于共享资源的优化。

资源衰减

将基础架构资源视为单一资源池处理允许基础架构中存在小型硬件故障，不会对整体容量产生严重影响。传统上，硬件是使用事件模型处理的，出现故障后将立即修复或更换硬件。通过利用资源池的概念，可采用维护模型处理硬件。由于“衰减”的原因，只有在发生故障的资源池达到一定比例之后，服务才会受到影响并且事件才会发生。可将故障资源纳入定期维护计划，或者在资源池达到一定的衰减阈值时进行处理，而不必采用逐台服务器进行更换的方式。

衰减模型要求提供商在更换基础架构组件之前确定能够接受的“衰减”量。这种方法支持可预测性更高的维护周期，并可降低与紧急组件更换相关的成本。

服务分类

服务分类是推动可预测性和鼓励使用者行为的重要概念。每个服务类别都在提供商的服务目录中定义，描述可用性、弹性、可靠性、性能和成本的服务水平。每个服务都必须满足针对其分类的预定义要求。这些合格要求反映了应用程序处理弹性与基础架构提供弹性两种方法之间的成本差异。

分类允许使用者选择其最适合其需求的价格和质量的服务。分类还允许提供商采用标准化方法来交付服务，降低复杂性、提高可预测性，从而提高服务交付的水平。

成本透明

成本透明是采用服务提供商的方法来交付基础架构的基本概念。在传统数据中心中，无法确定特定服务占用了多少比例的共享资源，比如基础架构。这使得针对市场的基准测试服务成为不可能实现的任务。通过服务分类和消费建模来定义成本基础架构，将能够获得利用共享资源的真实成本的更准确的视图。这允许企业公平地对比内部服务与市场服务，支持制定更明智的投资决策。

成本透明也会刺激服务所有者思考服务的退役。在传统数据中心中，服务可能不再使用，但往往不会考虑如何将不再使用的服务退役。利用率低下的服务的长期支持和维护成本可能隐藏在数据中心的成本模型之中。可为企业提供各服务的每月使用成本，激励服务所有者退役不再使用的服务，从而降低成本。

基于使用的定价

这种概念表示根据您的使用情况付费，而非无论使用量如何都保持均一的固定费用。在传统定价模型中，使用者的成本基于根据硬件和软件的资本成本和运作服务的支出所得出的纯成本。在这种模型中，可以根据实际使用情况为服务采用较高或较低的定价。在基于使用的定价模型中，使用者的成本能够更准确地体现其使用情况。

使用的单位在服务类别中定义，应尽可能准确地反映使用基础架构服务的实际成本，确保连续可用性所需的保留容量数量以及所鼓励的用户行为。