ASP 的容量管理

 

Microsoft 企业服务白皮书

发布日期：2000 年 9 月

感谢以下人员的参与

Unisys Corporation：Jeroen Bom、Joe Helm、Kelly Millsaps、Hilda Willems

Microsoft Corporation：Kathryn Rupchock、Kent Sarff

摘要

本白皮书系有关 Microsoft®企业服务 (ES) 框架的系列文章之一。要了解该系列出版物的完整清单，请访问 ES 站点：http://www.microsoft.com/enterpriseservices/。

本白皮书描述了应用程序服务提供方 (ASP) 的容量管理。凡阅读本白皮书的读者，均应首先阅读“Microsoft Operations Framework Executive Overview”白皮书，该白皮书包含有关该主题的重要背景信息。

引言

摘要

本白皮书论述并实际列举了数据中心容量管理的最佳做法， 着重讨论了 ASP 的常见问题。其中包含了有关 Microsoft® Windows® 2000、Microsoft® Internet Information Server 5.0、Microsoft® Exchange 2000 Server 和 Microsoft® SQL Server™ 7.0 方面的信息，但在此论述的方法和最佳做法并不仅限于这些产品。

本白皮书中还包括与服务供应、技术基本结构、计费过程和 ASP 环境中服务级别管理相关的容量管理的最佳方式。

读者对象

此白皮书针对两类读者：它对资源管理人员和技术人员均颇具实用价值。本书的开头部分以非技术方法定义了容量管理； 而其它部份技术性较强，专门面向 ASP 的开发人员及技术人员。尽管此白皮书面向两类不同的读者，但整个文档对双方应很有价值。

Microsoft 操作框架和企业服务

Microsoft 操作框架 (MOF) 是最佳做法、原则和模式的集合。它为在 Microsoft 产品和技术上实现任务关键型产品系统的可靠性、可用性、支持性和管理性提供了全面的技术指导。

MOF 是组成企业服务框架的三个框架之一。每个 ES 框架都针对信息技术 (IT) 生命周期中的一个不同而必不可少的阶段。每个框架对各自领域内成功执行所需要的人员、过程和技术，都提供了有益和详细的信息。其它两个 ES 框架为 Microsoft 准备工作框架 (MRF) 和 Microsoft 解决方案框架 (MSF)。下图描述了各个框架如何用于企业服务。

企业服务框架

“Microsoft 准备工作框架”协助 IT 组织做好使用 Microsoft 产品和技术的个人和集体的准备工作。该指南包括评估和准备工作计划工具、学习指导图、与准备工作相关的白皮书、自我调节进度的培训、课程、认证考试和准备工作事件。

“Microsoft 解决方案框架”为项目生命周期的规划、建立和部署阶段提供指南。指南涉及企业结构、应用程序开发、组件设计和基本结构部署等各方面，其形式有：白皮书、部署指南、加速解决方案、解决方案工具包、案例分析以及课件。

“Microsoft 操作框架”包括一系列全面的操作指南，其形式包括白皮书、操作指南、评估工具、操作工具包、最佳做法、案例研究，以及在当今复杂的分布式 IT 环境中为有效的管理系统进行人员、过程和技术安排的支持工具。

Microsoft 操作框架概述

为企业对消费者 (B2C) Web 站点提供高层次的可用性和可靠性不仅需要良好的技术，还需要完善的操作进程。Microsoft 在行业经验和最佳做法基础之上，创建了建立和运行这些进程所需的知识库。本文档是封装在 MOF 中的知识库的一部分。该框架基于两个重要的概念：服务解决方案和 IT 服务管理。

服务解决方案

服务解决方案指 IT 为客户提供的能力或业务功能。服务解决方案的示例如下：

• 提供应用程序服务
• 电子商务
• 消息传递
• 知识管理

基于当前应用程序托管和外购的趋势，MOF 非常支持“将软件作为一种服务解决方案来提供”。

IT 服务管理

IT 服务管理由客户维护特定服务解决方案所需的功能组成。IT 服务管理功能的示例包括：

• 帮助台
• 问题管理
• 应急规划

MOF 支持使用定义明确的服务管理功能 (SMF)，来协助 IT 操作提供以业务为中心的服务解决方案。这些服务管理功能提供一致的策略、过程、标准和最佳做法，可将其应用于当今 IT 环境中存在的整套服务解决方案中。

MOF 过程模型（如下所示）显示了服务管理功能适用的方面。

如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

MOF 过程模型

容量管理是优化阶段的一部分。此阶段认识到成功运行 IT 操作是在激烈竞争的市场中获得商业成功的先决条件。优化过程针对操作的两个具体因素：

• 商务服务的可靠性
• 成本

容量对 ASP 而言是一笔巨大的开销，但如果未及时提供适当的容量，则会付出更高的代价，因为这样 ASP 就不能满足客户的要求。容量管理过程的目标就是：确保以节约成本、及时有效的方式，安装适当的容量来满足客户的需求。此过程正不断探索优化现有和将来的资源需求。容量管理人员根据此优化结果确定新版本，并重新开始 MOF 过程。容量管理人员 应该积极地定期规划和执行优化措施。这是MOF 过程模型建议的做法，并通过提供审阅里程碑和指导来提供帮助。

有关 Microsoft 操作框架过程模块的详细信息，请参见 http://www.microsoft.com/enterpriseservices/MOF.htm。

基于行业最佳做法的 MOF - ITIL

MOF 注意到，英国中央计算机与电信局 (Central Computer and Telecommunications Agency, CCTA) 的 IT Infrastructure Library (ITIL) 中很好的记录了 IT 服务管理的当前行业最佳做法。

CCTA 是英国政府的一个行政部门，它针对服务管理和操作中信息技术的应用，开发和制订最佳做法建议及指导方针。为实现此目标，CCTA 在全球范围内追踪领先的 IT 公司的项目，记录与验证 IT 服务管理方面的最佳做法。

MOF 将这些合作行业标准与运行在 Microsoft 平台上的具体指导方针相结合，运用到多种商业方案中。MOF 扩展了 ITIL 操作规程，使其能支持分布式 IT 环境和当前行业方向，如应用程序托管、移动设备计算和基于 Web 的事务性和电子商务系统。

ASP 的容量管理概述

目标

容量管理负责保证用于提供 ASP 解决方案的 IT 容量（如应用程序资源、物理基本结构等）能够符合 ASP 客户的进一步需要； 确保能够对现有资源进行优化使用，并以最经济有效和及时的方式完成升级过程。

为什么容量管理对 ASP 至关重要

任何一个 ASP 供应商都不想让其客户有不好的体验。如果 ASP 没有足够容量根据协议服务水平为其所有客户提供服务，那客户就会饱受响应缓慢、超时和错误、以及受损的应用程序的困绕。

一旦客户有了糟糕的体验，他们通常会转向其它可以满足其要求的 ASP。为避免出现这种情况，ASP 必须建立一个既能处理普通级别的需要，又可满足高级级别及更高要求的基本结构。在容量管理中，可以巧妙使用操作支持系统 (OSS) 来监视现有资源的使用，从而使 ASP 解决方案能根据规定的级别来执行。

如果执行无误，容量管理就可以计算出需要使用多少计算机硬件来处理客户希望某个 ASP 解决方案满足的请求。这些计算可以帮助找到 ASP 解决方案设计中的“薄弱环节”和引起性能降低的资源瓶颈。通过增加硬件或重新设计解决方案资源要求，ASP 可以消除这些薄弱环节，从而全面提高解决方案的性能。

容量管理可以帮助 ASP 人员积极探索基本结构的未来改进之处，以便有足够的能力处理客户对系统日益增长的要求。当容量管理工具实现自动操作且通常足以应用于多个应用程序时，ASP 对人为干预的依赖会减少，提高客户的满意度，并增强 ASP 模型的财务活力。

ASP 应何时执行容量管理

容量规划应是所有 ASP 永远关注的问题。只要用户数量、解决方案的复杂程度或服务器的容量/配置发生了显著变化，ASP 就应该花些时间来重新计算站点的容量。根据客户的需求，ASP 可能需要增加特定 IT 资源的容量。依照 MOF 过程模型，ASP 应按设定的时间间隔执行检查，评估当前容量的测量标准和限制。可能影响客户需求的因素包括：

• 季节需求（例如，在夏季冰激淋销售量增加，从而造成需求峰值高于冬季）。
• 促销活动（如新产品上市）。
• 节假日（在节假日前几周销售量增加，从而造成 ASP 系统需求量的增加）。

ASP 应采取什么样的容量管理方法

ASP 解决方案的生存能力在很大程度上取决于它良好的容量管理。

ASP 解决方案的成功取决于所交付的解决方案能良好运行，并满足客户的需求。通常，用户对 ASP 站点有三个要求：

1. 质量。按服务级别协议 (SLA) 中明确要求的质量向客户交付产品。
2. 速度（和执行/实施时间成反比）。提供及时的管理资源，以满足 SLA 中明确标明的解决方案要求。
3. 价格（以较低成本为佳）。最佳的和可预计的成本。

事先进行容量管理可确保客户需要的质量、速度和价格等尺度之间的平衡。应牢记一个经验法则是：ASP 客户可以根据自己的需要满足任意两种尺度，但却无法三者兼顾。例如，在短时间内快速实现新功能（速度）和高质量的产品（质量）必须以高成本为代价（价格）。此外，客户可以廉价（价格）求得快速实施（速度），但产品会存在缺憾（不能确保质量）。

因容量管理所涉及技术的深度和广度而使其非常复杂。因此，要求负责容量管理的人员必须具备下列领域的丰富专业知识：

• 应用程序的供应（客户端/服务器，Web 服务器或瘦客户端服务器）
• 多租赁（专用资源与共享资源）
• 资源管理（服务供应，计费和需求高峰）
• 服务交付容量（服务器、技术基本结构、网络、物理基本结构）
• 人员（个人工作量、技术冗余、高峰需求可用性等）
• 服务级别管理（SLA、运行、报告、更改控制等）
• 最佳做法

有关容量管理的详细信息，请参阅“E-Commerce Technical Readiness Capacity Planning”白皮书， http://www.microsoft.com/technet/ecommerce/capplan.asp 。

ASP 容量管理的基本概念

容量管理是指衡量 ASP 按照约定的、可接受的速度为客户交付解决方案能力的过程。

该过程包括：

• 监视客户当前对 IT 资源的需求并对客户将来的需求情况作出预测。
• 影响客户需求，可能需要与 SLA 配合来解决高峰使用时的效果问题。
• 将客户需求转换为资源需求和对将来资源需求的预测结果（一般说来，为满足将来难以确定的资源高峰需求，多增设一些容量不失为明智之举。无法满足客户需求所造成的损失将远远大于增设这些容量的成本）。
• 监视 ASP 服务的性能和吞吐量。
• 监视支持的基本结构组件的性能并进行调整，以有效使用现有资源。
• 创建使 ASP 能够提供 SLA 中规定的高质量服务的容量规划。

容量管理平衡：

• 供求平衡 — 即确保可用资源（处理能力和储存）符合销售给客户的 ASP 解决方案的需求，无论是现在还是将来。
• 成本和容量平衡 — 即必须确保用户所购买的处理能力，不仅在满足业务需求方面价格合理，而且还可最大程度地利用资源。

通过统计访问特定 ASP 解决方案的用户数量，可以计算最简单的 ASP 容量测量标准，它与每个用户对该解决方案的各个组件所施负载相关。这种基本计算可用于根据支持当前和未来使用水平的需要，调节所需的容量限制资源（CPU、RAM、磁盘空间和网络带宽）。

详细操作信息，请访问 http://www.itil.co.uk/ ，查阅“IT 基本结构库”的“容量管理”章节，或者参阅 ITIL 中的 Capacity Management 一书 (ISBN 0 11 330544 3)。

与其它 MOF 层面的关系

容量管理与其它 MOF 层面密切相关。它本身是 MOF 过程模型优化部分的关键因素。但容量管理与模型的更改、操作和支持组件有密切的联系，并为所有操作性能和容量问题提供支持。主要的联系描述如下：

MOF 更改阶段

MOF 操作阶段

MOF 支持阶段

MOF 优化阶段

MOF 基本概念

• 服务级别管理。容量管理支持服务级别管理，以确保性能和容量目标能够满足新的和变化的客户需求。
• 成本管理。容量管理确保以最经济有效的方式获取和利用所需的资源。
• 应急规划。容量管理确定所用恢复选项需要的容量。定义所需的基本软硬件配置应根据请求情况来提供必需的性能和吞吐量水平。
• 可用性管理。性能和容量问题会导致资源不可用（无法接受的低性能和不可用具有相同的影响）。因此，容量和可用性管理有着相同的目标并互为补充。
• 帮助台及故障转移和恢复（事故管理）。这些层面可确保容量管理获取有关容量和性能方面的事故信息。容量管理通过解决和记载与容量相关的事故来支持这些层面。
• 问题管理。容量管理对确定、诊断和解决与容量相关的问题起到了专家支持的作用。
• 监视/测量。容量管理（同样适于所有其它优化层面）定义一个测量标准，用来对结果进行分析。它定义受到监控的阈值，使性能稳定在规定的水平之内。
• 系统和网络管理。容量管理规定了超出阈值范围后必须采取的操作。此时将采用自动和非自动执行的 OSS 解决方案。
• 更改管理。容量管理评定更改对现有容量的影响，并根据需求的变化确定其它的资源要求。
• 版本管理。容量管理有助于确定分发策略，尤其有助于用于分发的网络。
• 配置管理。对资源和需求的任何更改将反映在配置管理数据库 (CMDB) 的配置项中。

容量管理的输入、子进程和输出

输入

很多信息源与 ASP 容量管理进程相关。其中一些信息如下所述：

• 新技术的外部供应商。
• ASP 的业务策略和规划。
• ASP 的技术策略、规划和当前预算。
• 和性能不佳相关的事故和问题的帮助台、故障转移与恢复及问题管理层面
• 服务级别管理操作，包括 SLA 和服务级别要求的详细内容。
• 更改管理操作，包括超前更改计划并需评估所有更改对客户需求及基本结构容量的影响。
• MOF 操作层面，包括所有需要运行的工作安排、有关不同解决方案之间差异和解决方案性能测量的信息。

子进程

容量管理由多个子进程组成，其中包括各种行为。容量管理的子进程包括：

• 需求管理。此子进程负责确保考虑、规划和适时实施 IT 服务将来的 ASP 业务需求。容量管理人员通过分析各种 ASP 解决方案当前的资源应用情况，并生成趋势和预测结果来实现这一点。这些未来的需求情况来自客户管理对当前和未来客户需求情况的不断研究。
• 工作量管理。此子进程负责将客户需求转化为 ASP 解决方案（用于创建实际解决方案的各种应用程序）组件的工作量，以此分析确定所需的资源。该过程将当前和将来两种需求转换为工作量。
• 资源管理。该子进程着重管理 IT 基本结构的单个资源。从工作量可以确定目前和将来所需的资源。它负责确保以适时和经济有效的方式获得和实施所有资源。
• 性能管理（和 MOF 监控/测量层面密切相关）。此子进程主要用来管理客户所用 ASP 解决方案的性能和解决方案所依据的主要资源的性能。它负责确保所有 ASP 解决方案的性能监控，正如 SLA 的目标中所详细描述的那样。还负责确保主要资源的性能监控。记录、分析和报告所有收集的数据。容量管理人员会根据需要确保解决方案符合业务的需求。

  分析收集的数据，将其用于执行调整操作并建立配置文件。在这些配置文件中可以确定和设置阈值及警报。当出现意外报告或发出警报时，需要据此进行分析、报告并纠正所发生的现象。理想情况下，阈值和警报设置得低于 SLA 目标值。这样可使容量管理在 SLA 中的目标遭到破坏之前采取纠正措施。

输出

容量管理的输出由其它服务管理过程和机构中的其它部门用于该过程中的其它部分。

• 在容量管理过程内部。例如，监测和收集到的数据作为性能管理的一部分，将用来确定所需升级的软、硬件，并根据变化的客户需求和预测确定升级的时间。
• 通过其它服务管理过程。例如，容量管理过程可确定新的服务级别要求，并通过确定何时需要进行软、硬件升级或购买新设备的财务预算，来辅助成本管理过程。
• 通过 IT 部门的其它小组。例如，IT 操作需要对服务的运行时间计划实施容量管理建议的所有更改，从而确保最高效、充分地利用可用资源。

有关输入、子进程和输出的详细信息，可访问 http://www.itil.co.uk/ 中的 IT Infrastructure Library。

ASP 的 OSS/BSS 与容量管理的关系

业务支持系统

ASP 向其客户交付业务解决方案。ASP 有很多联机业务支持系统 (BSS) 向客户通告有关协议服务级别和其它客户的信息（如性能和计费信息）。容量管理负责向用户交付协议确定的 (SLA) 性能。这意味着容量管理负责向 BBS 提交和性能相关的信息。

操作支持系统

为了监测业务解决方案的操作，ASP 设立了很多联机操作支持系统。OSS 的重要功能之一是监测业务解决方案和资源的性能。如果性能的阈值和资源使用级别超出范围，OSS 将发出警报并/或采取纠正措施。容量管理将定义这些阈值，以便在发出警报时采取保护措施（如调整和/或要求新增资源）。

OSS/BSS 相关性

OSS 和 BSS 互相高度依存。通过 BSS 报告给客户的信息来自于 OSS 的测量结果。这些测量结果被加以转换，随后通过 BSS 根据 SLA 定义的测量标准向客户通告服务质量。同时，如果客户通过 BSS 通知 ASP 需求发生变化，该请求将影响此客户所需的资源数量。更改将对 OSS 的设置产生影响。

Microsoft MAPS 框架使 ASP 可自动供应解决方案。它是 ASP 服务解决方案供应和资源管理的可扩展框架。在本文最后的“ASP 容量管理策略”部分，列举了此框架的实例。

供应和管理 ASP 服务

客户关系管理

客户关系管理的内容是发展及培养客户和 ASP 之间良好的职业工作关系。客户关系管理人员必须介入 MOF 的所有其它层面。例如，客户关系管理人员在 SLA 协商期间促进 ASP 与客户之间的互动，并参与解决客户对所提供服务的不满。

服务管理

MOF 的一个基本概念是服务管理。服务管理用于提供和支持适合 ASP 客户业务需求的 IT 服务。ASP 的容量管理取决于服务管理中大多数过程的正确运行（请参见“与其它 MOF 层面的关系”一节）。

客户关系管理和服务管理是息息相关的。但是，服务管理的重点在于提供规定的服务，侧重于操作和战术问题，而客户关系管理则主要管理策略级别以下的关系。客户关系管理还提供有关未来性能需求的成本反馈。

对容量管理而言二者缺一不可。为了规划将来的需求，必须将任何（可能的）更改或请求尽早通告容量管理人员。

有关客户关系管理和服务管理之间联系的详细信息，请参见 http://www.itil.co.uk/ 上的 IT Infrastructure Library。

ASP 解决方案的供应

对于 ASP来说，供应解决方案就如同将产品投入市场。自动化解决方案的客户注册、配置和持续的用户管理能力，有助于保证托管服务方面的收益能力。相反，没有自动操作和预期设定过程，可能就无法在服务平台的客户增多时请求添加操作人员，从而扩展 ASP 的功能使其满足市场的需要。这已成为许多公司面临的最大制约：无法迅速补充技术团队并吸引高素质的人才，从而制约了 ASP 的成功。

为此，供应可定义为在收到客户对 ASP 目录中某个或多个解决方案的订单后所执行的工作流。解决方案的供应与客户关系管理过程和服务管理过程（尤其是更改管理）相互关联。

在解决方案供应期间，ASP 和客户将创建一个服务级别协议。SLA 是 ASP 与其客户职业关系的基础。SLA 用来定义 ASP 必须向客户提供的解决方案，及该解决方案的执行方式。它规定了 ASP 必须执行的服务级别，并说明 ASP 和客户之间如何相互沟通 SLA 相关的信息项。

更改管理

管理更改是维护系统正常运行和完整性的重要方面。更改控制过程提供了批准更改并对请求的更改进行全面考虑的机会。在该过程中，可以进行需求评估、及时订购资源并调整容量规划。

更改控制提供了一个已定义的框架，用于说明更改发生的方式和时间。这样可以降低未经评估 ASP 环境更改对需求和资源的影响而造成的风险。

已定义的更改和目的

更改请求应包括对要执行的工作或要进行的更改的书面定义。其中应包括更改的目的，更改将产生的结果和更改生效的时机。在此定义中，可用性和容量过程将确定对容量的影响。

风险评估

更改管理应就对现有容量和现有需求所要进行的更改进行风险评估。风险评估的范围可以从无风险到高风险，它将是更改是否被批准的关键因素。

批准过程

批准过程将在上述信息基础上进行。如果提交者使用标准化格式，会便于批准机构更加高效地完成批准过程。为提交者提供一份完整的范例也将有助于该过程的进行。提交次数和处理时间指南应提供给所有批准人员。优先处理的更改或那些需要在指定处理时间之前生效的更改，应使用相同的格式，但批准过程会加快处理。

验证更改的步骤

有关验证实施的更改是否按照预期方式运行的步骤信息应该提供给批准机构。随后，将根据结果执行预先定义的操作（例如，如果更改不能正确工作，则可能需要执行回退操作）。

支持过程

帮助台可通知容量管理有关容量和性能方面的事件信息。容量管理通过解决和记录与容量相关的事件来支持故障转移和恢复操作。通过问题管理、容量管理进行协调为故障转移和恢复操作提供辅助恢复的诊断脚本和诊断工具。例如，可在帮助台上访问实时性能和容量监测工具。结果，容量管理将通过自动警报或记录已知错误，确保支持过程获取任何可能发生的性能或容量问题。

合作伙伴责任

ASP 通常主要依靠合作伙伴提供所有或部分服务。在客户和 ASP 之间，客户可能需要其它供应商才能建立与 ASP 的连接。在客户的角度，他可能不了解供应链中的哪一个供应商负责服务的端对端性能。因此很必要在 SLA 内说明责任范围。

服务质量的测量标准和监测

容量管理是监测质量并在可能情况下改进质量的过程。因此服务质量的测量标准非常重要。例如，过程的成功（与否）可以通过生成下列服务质量测量报告加以衡量：

业务预测

技术

经济有效

规划和实施适当的服务容量

• 减少由于性能不佳而发生事故的数量
• 减少由于容量不足而造成的业务损失
• 实施符合服务级别要求的新服务
• 按容量管理建议操作
• 减少不必要的购买
• 在营业期内没有不可调整的明显超容量
• 准确预测计划支出
• 监测性能及所有服务和组件吞吐量的能力
• 新技术的实施符合业务的需求（时间、成本和功能）
• 没有因陈旧技术的支持和性能问题违反 SLA
• 适时生成负载预测
• 业务趋势的准确预测
• 将业务规划合并到容量规划中

容量管理为这些服务质量测量标准中的每一项定义目标并监测其落实情况。过程所有者必须改进和管理该过程，使规定目标在确定的时间框架内实现。

容量管理等式

根据高峰使用情况确定所需资源。如果 ASP 可以满足客户高峰使用时间的需要，那么非高峰时间就一定不成问题。

容量管理等式分为三步。首先，对需求进行评估。其次，计算负载。最后，计算所需的资源量。此计算的简单示例如下。

第 1 步：需求计算

总需求量 = 当前用户数量 x 单个用户需求单位

第 2 步：工作量计算

工作量 A = 总需求量 x 应用程序 A 每个需求单位的工作量

工作量 B = 总需求量 x 应用程序 B 每个需求单位的工作量

第 3 步：资源计算

所需的 MB 存储量 = 工作量 A x 每个工作量 A 单元所需的 MB + 工作量 B x 每个工作量 B 单位所需的 MB

所需的 CPU 功能 = 工作量 A x 每个工作量 A 单位所需的 CPU 功能 + 工作量 B x 每个工作量 B 单位所需的 CPU 功能

所需的网络带宽 = 工作量 A x 每个工作量 A 单位所需的网络带宽 + 工作量 B x 每个工作量 B 单位所需的网络带宽

本例假设两个应用程序都托管在一台计算机上。反向计算将表明在高峰时间该应用程序可容纳多少用户。

通过此方法，ASP 管理员可以非常简便地计算出应用程序可支持的用户数量。

从该等式可得出两种推论：

1. 降低每个用户对应用程序的负载可增加支持用户的数量。这一点通过规划、编制和配置应用程序以充分高效利用资源得以实现。
2. 增加过程限制的资源（如 RAM、网络带宽、许可权和服务器）可以增加支持用户的数量。

系统升级意味着扩充现有资源的容量。系统升级的实例包括为现有服务器增加更多的处理器、RAM 或磁盘空间。

扩大规模意味着增加更多的资源如服务器、网络连接或人员。

需求和资源高峰

此等式虽然看上去简单，但单个用户的需求并不总是发生在同一时刻。由于资源负载是单个用户需求的结果，因此资源的需求将因时间而不同。下图举例说明了为用户提供协议性能所需的总负载量。

ASP 解决方案的性能取决于对资源的需求情况。如果 ASP 同意为其客户提供特定的服务性能，则基本机构的设计必须在高峰时间也能满足这种性能。

如果在高峰时间没有足够的容量，那么最简单的方法就是将工作重新安排到高峰时间以外去做。另外一个非常常见的方法就是通过提高高峰时间的服务花费来干预客户行为，从而减少在该时间段的服务需求。

报告

容量管理报告应涉及以下几方面：

• 当前需求和这种需求如何转换为资源
• 高峰需求
• 未来需求、工作量和资源预测
• 未来性能预测
• 目前资源所支持的用户数量
• 在用户数量（负载）增加情况下的可扩展选项
• 在应用程序复杂性增加情况下的可扩展选项
• 容量更改监测
• 潜在的瓶颈问题

该报告应阐明任何容量决定。例如：

• 若要增加所提供应用程序的复杂性，就需增加每个用户对硬件的负载并始终维持支持的用户数，这样硬件容量也必须增加。它支持决定进行系统升级或扩大规模。
• 为支持更多的用户，必须简化应用程序（减少资源需求）或增加资源容量。此时应调整应用程序使其尽量少用限定的资源（RAM、网络带宽、磁盘空间等）。

结果反馈

确定网站容量并将其与当前和未来性能联系起来，这一点只是容量管理的一半。ASP 管理员必须对报告结果作出明确的抉择。否则，如果不对站点容量进行更改，使其与客户需求保持同步，就会导致性能降低并造成用户不满。

对容量管理结果反馈的一般步骤包括：

• 直接按容量管理报告建议实施。
• 将报告转给站点内容开发人员，作为其更改或开发未来内容的指导。
• 必要时，明确阐述应用程序硬件的升级规划。
• 预测未来发展对容量的影响。
• 预测未来的升级费用。

客户便携性

客户便携性测量标准用于确定客户想要停止 ASP 的服务并将其数据移植回自己的数据中心或其它 ASP 处的方便程度。

大多数 ASP 为客户提供称为“数量折扣”的服务，客户可在延长时间段内购买合同服务。合同期越长，折扣越大。

对专有数据的控制、访问和保密是潜在 ASP 客户面临的几种最大风险。ASP 必须为客户创建合同规定的机会以便于客户终止关系并恢复所有数据。ASP 要与需要解决数据便携性问题的客户合作，最终需提供一种比较完善并且更具强制性的服务。

客户便携性问题对容量管理的不利之处，在于 ASP 在投资支持客户容量管理所需的基本结构时承担的风险。ASP 需要控制客户终止服务合同所带来的风险。一套编写完善的 SLA 将包含确保客户便携性的条款，同时制定提前终止处罚，协助强制客户的忠实性和管理 ASP 投资风险。通常通过监测和 SLA 相关的 ASP 性能来达成这些矛盾对象之间的平衡。如果 ASP 在满足 SLA 中所定义的客户需求方面相去甚远，则关系终止的罚金相对较低。相反，如果 ASP 符合或超过了客户在 SLA 中规定的要求，则关系终止罚金相对很高。

从长计议

容量管理最简单的问题是有关 ASP 是否可以为客户排队或甚至“不为其服务”。如果不允许，则只能选择超容量。不符合客户需求所花费的费用将远远高于增加容量的成本（例如，由于容量不足导致的公开中断在信誉方面的损失比安装附加容量的花费更多）。

ASP 解决方案交付

ASP 解决方案交付选项

在当今 ASP 市场中交付应用程序内容有三种方法。每一种方法相对于容量管理都有其优势和弱势，它们会影响如下所述的交付和支持平台。

客户端/服务器。此方法合并了某些可在客户端和服务器上执行的应用程序功能。此类应用程序分发的一个实例就是通过远程程序调用 (RPC) 的 MAPI 与 Microsoft Exchange 服务器连接的 Microsoft® Outlook®。

瘦客户端服务器。 此方法合并了集中化的服务器应用程序资源负载，并提供了多种客户端访问选项。它仅将屏幕刷新传输到客户端，并将鼠标/键盘输入/输出 (I/O) 传输到服务器，以此来最大限度地减小网络带宽需求。此类应用程序的一个实例是从 Microsoft Windows 2000 服务器通过终端服务分发的 Microsoft Office 2000，它通过任何“远程桌面协议”(RDP) 客户端进行访问。

Web 托管。此方法合并了集中化的服务器应用程序资源负载，但也可使用客户端资源。通常，唯一的客户端要求就是 Web 浏览器，它用来正确地跨平台分发应用程序。此类应用程序分发的一个实例就是从 Web 浏览器通过 HTTP （包括 HTML、DHTML 和 XML 内容）访问的 Microsoft Exchange 2000。

1. 优点：应用程序配置集中在服务器上，可进行单点管理，对网络应用的要求较低，最低的客户端配置要求，对客户端资源要求较低，可以跨平台分发，管理相对容易，相对减少了软件授权成本，升级/规模扩充也相对容易。
2. 缺点：这种分发方法相对较新，需要较强的技术性，且供不应求。
1. 优点：应用程序配置集中在服务器上，管理点集中，网络使用要求较低，客户端配置要求和客户端资源要求也较低。
2. 缺点：并非所有的应用程序都完全适和通过终端服务托管，服务器配置可能较为复杂，对服务器资源要求较高，系统升级选项受限（支持扩大规模）。
1. 优点：为企业中的多种资源分发处理能力。这是基于 Exchange 客户的宝贵经验。
2. 缺点：在服务器和所有客户端上都要存在应用程序配置要求。

当前有大量的已部署客户端/服务器应用程序。瘦客户端服务器应用程序在过去的几年中应用大大增长。应用程序的 Web 托管由于其管理简便、可扩展性和成本因素也有增长的势头。

Microsoft 已创建了 Microsoft .NET 平台，用来创建和部署商务 Internet 应用程序和平台，其中包括对开发高效应用程序平台至关重要的多种动态内容。

有关详细信息，请查阅 Microsoft .NET 网页，网址为： http://www.microsoft.com/net/ 。

要对此类体系结构执行容量管理操作，需考虑以下几个方面：

• 和应用程序服务器相连的用户数量。
• 应用程序功能的复杂性。

  和所有服务器和网络有关的硬件容量包括：

  • CPU 功能（所有级别的 IIS 服务器，应用程序服务器，SQL 服务器等）
  • 内存应用（所有级别的 IIS 服务器，应用程序服务器，SQL 服务器等）
  • 磁盘速度（所有级别的 IIS 服务器，应用程序服务器，SQL 服务器等）
  • 网络应用（局域网 [LAN] 和 Internet）

ASP 容量管理策略

ASP 资源概况

简而言之，ASP 必须在服务协议的基础上确定资源要求，以创建、管理和支持在不断变化的环境下提供相应服务质量的应用程序。这也就是说，ASP 将使用 SLA 来确定和预测提供以下所需服务的资源要求。

如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

使用 SLA 来确定资源需求

确定要监测什么资源，如何监测资源应用以及如何管理资源需求，这些是在动态 ASP 环境下预先供应所需服务的必要因素。本章节将着重分析这些问题。

容量限制资源的鉴定

鉴定容量限制资源的第一步是查看 SLA 的范围。ASP 通常提供包括负责以下某些方面的解决方案：

• 应用程序解决方案交付基本结构
• 网络连接
• 应用程序的客户接口

各个 ASP 提供服务各不相同。实际上，为了满足特定客户的不同需求或应用程序的不同要求，即使在一个 ASP 内部，服务也可能不同。以下章节就上述各个主题进行资源事项的探讨。

应用程序解决方案交付基本结构资源

不管使用何种 ASP 解决方案交付选项，为便于容量规划必须监测四种基本资源。这些资源包括处理器、内存 (RAM)，磁盘阵列/子系统和网络。其中的每个问题都在下列 ASP 环境中明确论述：

• 处理器。指定硬件的处理器应用。任何处理器，如果其使用已超过百分之 80，即意味着存在容量限制问题。通常不使用单线程的应用程序进程， 因为这意味着对相关事务只能访问一个处理器。一个编写不佳的应用程序进程完全可能导致一个处理器保持百分之百的应用，而在同一分区中的其它 31 个处理器却根本未被使用。这种情况意味着应用程序应重新编码。
• 内存。应监测所有独立分配的内存分区的内存应用情况。内存不足是 ASP 面临的最常见的资源瓶颈之一。内存应用问题的征兆常常首先表现为处理器和磁盘阵列使用处于峰值，这是由于这些资源为了缓存磁盘阵列和可用 RAM 之间的虚拟内存而被过度使用的原因。
• 磁盘阵列。 磁盘阵列瓶颈通常表现为可用磁盘空间不足，或者是某特定阵列中的主轴超负荷使用。
• 网络。对 ASP 模型网络的这一层而言，“网络”指 ASP 局域网 (LAN) 的所有资源。它包括单个网卡的使用，网络等待时间和可用带宽，以及 ASP 局域网中交换机和路由器的性能。

每种资源可通过各种具体方式进行监测。通常操作系统和磁盘子系统提供了便于详细监测这些资源的机制。与这些资源相关的重要测量标准的详细信息，请查看本文的“容量限制资源的测量和积极管理”部分。

网络连接

在此处，网络连接是指客户局域网和 ASP 局域网之间的一切。有些 ASP 直接提供和管理这一线路。也有一些 ASP 通过与其他供应商的合作间接管理该线路。甚至还有一些 ASP 根本不控制此线路。

不管 ASP 是否控制此线路的管理，该线路都必须进行监测。客户与 ASP 之间的连接是 ASP 交付模型的关键部分。如果 ASP 的服务通过公用网络提供，此线路的带宽就会始终处于其他用户的争用之中。SLA 应说明 ASP 管理此线路的程度。

与网络连接相关的最为重要的测量标准为网络等待时间。ASP 必须能够监测网络等待时间和使用情况，并且提供测量数据达到降低应用程序性能或妨碍整个应用程序功能的阈值时的防备措施。

客户接口

客户接口定义为客户局域网内部的一切。对于一般的公司客户，它包括应用程序接口（浏览器、瘦客户端或客户端应用程序）和公司局域网内部的网络资源（网卡、交换机和路由器）。

和网络连接部分所述相似，ASP 对此组件具有不同程度的责任和控制，包括直接完全控制到间接完全控制直至不控制。

SLA 应说明 ASP 管理此客户接口的程度。通过浏览器访问的应用程序可能与授权客户全权负责客户接口的 SLA 相关。

和网络连接相似，容量管理的主要测量标准之一的客户接口，是网络延迟的另一因素。延迟是客户局域网内部资源网络带宽瓶颈的症状。

ASP 需要能够确定网络延迟的原因。网络延迟的原因可能发生在 ASP 的局域网、网络连接或客户局域网中。

容量限制资源的测量和积极管理

在应用程序服务供应中所需监测的基本资源，包括应用程序解决方案交付基本结构、网络连接和客户端接口组件，它们已在前面章节中详细论述。SLA 应明确规定 ASP 的责任范围。ASP 应能够监测容量限制的资源，不管它是否由 ASP 直接管理。如果没有所有相关资源的性能测量标准，就不可能了解性能瓶颈或预先管理资源要求。

和限制资源相关的特定数据随应用程序分发体系结构（客户端服务器、瘦客户端服务器和基于 Web 的体系结构）而稍有变化。容量限制资源测量和管理方法的详细技术分析，请参见以下内容，它们建立在各个应用程序体系结构的基础上。

客户端服务器

Microsoft Windows 2000 Performance Tuning， http://www.microsoft.com/WINDOWS2000/guide/platform/performance/reports/perftune.asp

瘦客户端服务器

Microsoft Windows 2000 Terminal Services Capacity and Scaling， http://www.microsoft.com/windows2000/library/technologies/terminal/tscaling.asp

Terminal Server Capacity Planning Tools， http://www.microsoft.com/WINDOWS2000/library/resources/reskit/tools/hotfixes/tscpt-o.asp

Citrix NFuse 和 Citrix MetaFrame， http://www.citrix.com/products/imanage/default.htm

Web 托管

E-Commerce Technical Readiness Capacity Planning， http://www.microsoft.com/technet/ecommerce/capplan.asp

Art and Science of Web Server Tuning with Microsoft Internet Information Services 5.0， http://www.microsoft.com/technet/iis/iis5tune.asp

Microsoft Site Server 3.0 Commerce Edition， http://www.microsoft.com/technet/commerce/usagepre.asp

资源管理

确定资源要求的三个因素：

• 用户数量。当更多的用户访问该应用程序时，容量必须增加，否则性能就会降低。如前所述，用户需要有一些余量（超容量），来适应意想不到的使用高峰。
• 应用程序复杂性。当应用程序变得更为复杂时，就会导致服务器要对每个用户做更多的工作，从而减少相关资源的容量。相反，ASP 管理员有时可以通过一些方法来增加容量，它们包括简化应用程序的资源要求、消除高负荷强度的处理器、减少图形或内存功能以全面减小应用程序的资源需求。
• 服务器容量和软、硬件配置。通过升级计算基本结构，管理员可以增加容量，来容纳更多的用户或更为复杂的应用程序内容，或者同时满足两者的需要。由于个别客户对多余空间的需求，资源也可能出现超容量。虽然不可能直接计算所需容量的准确数字，但给出一定比例的超容量仍不失为预防例外情况的明智之举。

完备的日志记录

根据定义，供应进程将导致服务交付平台状态的改变。必须忠实记录平台的所有变化，才能确保该进程的可靠性和可再现性。日志记录应包括已成功完成操作的详细信息、标识操作完成或失败时间的时间戳信息、操作发起者的身份、操作的目标帐户或行为，以及操作中遇到的反常状态。

从财务角度出发，此记录对 ASP 的收益率非常重要。计费过程从成功为公司提供服务开始，对每个成功获得特定服务的用户收取费用。缺少准确的记录信息可能导致计费收入的损失，甚至更糟的是为客户提供了错误的计费信息。向客户收取未成功提供的服务费会降低客户对 ASP 操作能力的信任。而这又将制约更广泛服务的采用，并/或影响客户的忠诚度。

如果保留所有的记录数据，在一、两天内将会用掉 ASP 的所有存储，客户将不再有任何可用容量。因此定义记录保留时间非常重要。例如，每 10 分钟对特定 OSS 系统的毫秒测量进行一次合并计算。此后，便不再需要计算中所用的数据，所占存储空间将被清空。10 分钟的数据，再次被合并到报告和图形中。报告创建后，10 分钟数据的存储空间也将清空。

安全

在许多情况下，供应服务需要管理员级别权限或安全环境，它不适于分配给非技术性的客户用户管理员。供应体系结构应符合策略的实施和基于角色的安全性，并允许客户在 ASP 所定义的策略基础上调用操作。由于在不同业务主题和目标客户段的 ASP 大大不同，因此他们必须能够迅速更换策略而不需在供应框架中另行开发。

为了确保完善的安全模型实施，同时又支持集团代表机构（如客户用户管理员和/或客户支持代表）的需求，请求者和基于角色机构对特定用户对象（读、写、浏览等）调用特定操作的安全环境必须是供应框架的一部分。

可扩展支持多种服务

ASP 服务交付平台的本质和使产品和技术迅速投入市场的需求要求供应体系结构能够满足多种服务、服务规划和策略。供应无法针对特定应用程序，因为这样会限制灵活性并需要在每次添加应用程序或新服务时重新编码。理想情况下，设计合理的供应框架应允许定义服务，且供应组件了解如何以动态方式与要在供应中添加的特定应用程序进行交互编程，而不需修改框架本身。

与其它供应/工作流过程和系统集成

应用程序的供应、组织和用户可能只是较大过程中的一部分，此过程在收到客户订单后开始实施。从订单着手，可能需要订购、安装和配置硬件，部署和/或配置网络设备，在计费和客户服务系统中建立记录，为服务交付平台中的事件管理和监测基本结构添加应用程序和硬件。可能需要订购和/或分配存储、配置备份资源、以可重复和可预测方式执行其它操作的主机。

应用程序供应框架必须能够接受客户服务和计费系统的请求，以更改用户和机构的服务属性，更改主要信息（如口令），根据所定义的安全性和服务策略支持机构的代表，并允许 ASP 完成客户自身管理策略的灵活定义。这对 ASP 尤其重要，因为推出日常用户管理任务任务（诸如添加和删除用户，更改密码及使用户可以执行特定的添加值服务）为客户提供所需的控制级别，同时大大降低了 ASP 进行客户管理的成本。

如果任务种类繁多（有些是计划性并自动执行的，有些是密集资源型的） — 供应工作流能够将提供的客户服务合理集成于整个过程至关重要。

资源管理：链接丢失

可重复、可预测结果也需要实时的可供应的可用资源信息。没有相应的保护措施，减少了人为干预以提供服务所需的自动处理，也可能导致主要资源如存储、CPU 和内存的过量预订。为某机构按照特定服务级别供应一定数量用户，需要数据中心的可预测资源量。资源管理所起的主要作用是对可用资源、模型应用程序/服务级别要求进行监测并在这些参数的基础上选择资源最有效的设置。应用程序可以用所需资源的“相关性”树视图形式表示，其中包括那些可供应的资源（磁盘和备份存储）以及其它的静态资源（CPU 处理）。

集成的供应体系结构

下图说明了 Exchange 2000、Windows 2000 和 Microsoft® Active Directory® 服务集成供应体系结构。（图中的 SCO 代表服务配置对象。）

如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。

有关详细信息，请查询“Integration of Provisioning and Billing for ASP-Hosted Microsoft® Exchange 2000 Server”白皮书， http://www.microsoft.com/ISN/downloads/Provisioning%20and%20Billing%20Integration%20for%20ASP-Hosted%20Exchange%2020002.doc

多租赁

概述

从单一资源（共享目录、共享服务器、共享数据库等）托管多个客户称为多租赁。多租赁的对立面是专用资源（专用 Active Directory，专用服务器等）。

ASP 为客户提供的最具价值的服务之一就是降低了有关管理、维护和支持应用程序的成本。ASP 之所以能够部分提供这种价值，是由于资源成本分布在多个客户之中。

ASP 容量管理的一个重要作用是完全了解可被多个客户共享的资源。多数客户对共享技术能力（人员）和典型的 ASP 环境感到非常满意，前提是他们相信 ASP 能够维持其产品的机密性。目前已有对该问题进行管理的法律案例和完善的失败补救方案。ASP 面对的挑战确实有些复杂。为了最大化成本效益并为客户提供有价值的服务，ASP 不仅可以共享经验丰富的人员，还可在客户之间共享硬件资源。ASP 和其客户需要了解与共享资源相关的基本风险和收益。以下章节将讨论此问题，它对 SLA 的设计和 ASP 管理员如何管理容量选项非常重要。

专用硬件

某些 ASP 仅在对个别客户专用的硬件上创建服务。

某些客户由于其产品的机密性比与其它 ASP 客户共享硬件节省成本更为重要，因而选用专用硬件。

该解决方案比其它解决方案花费要多，但能最大程度地为客户提供安全性，并减少 ASP 承担的责任。专用的硬件需求相对于其容量管理而言对 ASP 管理员的要求最为严格，它需要更多的应用程序资源（服务器 [所有层次]、备份实用工具等），更多的物理基本设施（数据中心房产、电源、冷却等）和更多的人员。

共享硬件

ASP 将在共享硬件上建立相应的解决方案。和专用硬件相比，它较为便宜，但客户承担的风险可能相对较大。

共享硬件有两种完全不同的模型，专用实例和共享实例。相对于专用硬件，每一种都为 ASP 管理员在容量管理上提供了更大的灵活性。

专用实例：此模型与多个客户共享与应用程序平台相关的物理硬件。它通过将同一服务器上的特定资源专用于与个别客户相关的特定功能而降低安全风险。

它通过一种叫做分区的技术实现。分区使特定服务器资源（处理器、内存、磁盘阵列、网络接口）对某个应用程序或进程专用。这样可以通过创建虚拟或逻辑计算机，有效地将服务器或其它资源的一部分专用于特定客户。

此模型需要特殊硬件和软件来支持资源分区。和完全专用硬件相比，它较为经济，且和共享实例相比相对安全。此模型和专用硬件模型相比，ASP 管理员对容量的管理较为灵活。理想的操作系统和硬件支持动态分区，此时资源可以动态分配给比较空闲的瓶颈（处理器、内存、磁盘、网络接口等），而不需中断其它进程的服务。Microsoft Windows 2000 Datacenter Server 支持在经认证的硬件上动态分区。动态分区是一个强有力的容量管理工具，ASP 可以充分利用它为其客户提供便利。

共享实例：此模型与多个客户共享与应用程序平台相关的物理硬件。它不将特定资源专用于个别客户。某些应用程序可以在此模型中运行，并具有合理的安全性。无疑，有些应用程序或应用程序类型不需要很高的安全性。

此解决方案比其它解决方案费用要低，但客户承担的风险最大。共享硬件的共享实例相对于其它模型简化了大多数选项的容量管理。

SLA 注意事项

在使用共享硬件时必须要考虑的因素之一就是 SLA。ASP 提供指定服务的费用与客户所需的可用性和性能要求密切相关。

在多个客户共享特定硬件资源的情况下，ASP 必须使整个资源满足要求最高的客户。因此，ASP 应确保所有共享指定资源的客户都需要 SLA（规定了相关的测量标准）中类似的服务。

例如，第五个客户可能需要相同平台中当前由四个客户共享的应用程序，这四个客户要求如各自 SLA 所规定的那样，服务中断在 24 小时之内得以解决。如果第五个客户的 SLA 要求服务中断在 2 小时之内解决，则整个应用程序平台必须设法满足第五位客户的需求。这会明显增加 ASP 在管理平台方面的成本。可能在某些情况下，上述方案是使 ASP 以最经济有效的方式来支持五位客户的方法。ASP 需要对服务要求和多个客户共享平台产生的成本非常敏感。

混合解决方案（专用和共享硬件）

为了最为经济有效地部署应用程序平台，有些解决方案可能混合了专用和共享硬件两种组件。ASP 通常在交付多层次应用程序时采用此类型的解决方案。安全限制层次利用专用硬件，而敏感层次较低的则使用共享资源。

机密性、集成性和可用性

共享资源时的问题之一是客户数据的机密性、集成性和可用性。必须特别小心以确保对 ASP 环境的更改根本不会造成此方面的破坏。否则可能导致对客户机密的泄露，在最糟的情况下甚至还可能导致丢掉客户。MOF 的“ASP 的安全管理”白皮书详尽论述了这一主题。

ASP 的最佳做法

概述

此白皮书旨在作为最佳做法指南，并为开发 ASP 容量管理最佳做法提供更多建议。

阶段性实施

逐步实施容量更改是一种完善的进行容量管理的最佳做法。具体地说，通过尽量减少一次更改变量的数目，解决问题会变得容易得多。

灵活掌握规模，降低总拥有成本

全球性的 ASP 应从提供产品服务的一开始就从大处着手规划。通过考虑与容量供应相关的关键问题，许多过程可以自动执行。利用策略驱动的目录结构（如 Microsoft Active Directory）可能是执行所需业务过程的一个重要部分。应预测到多个国家客户众多的调整规模要求，并将其作为产品的基本功能；减少“一次性”自定义需求的需要，因为这种操作会增加费用并使应用程序的交付、可管理性和可支持性变得复杂。

当设计具有可升级容量管理基本结构的 ASP 解决方案时，一些重要的注意事项包括：

• 服务供应和计费过程的集成。
• 应用程序和服务语言的支持（unicode 或多字节字符集）。
• 计费过程中的货币转换（欧元问题）。
• 客户所在地的法律要求。
• 文化敏感问题。

有关此主题的详细信息，请访问 ASP Consortium 和 Microsoft 站点， http://www.aspindustry.org/members/BestPractices/DeliveryModel.cfm

http://www.microsoft.com/ISN/downloads/Best%20Practices%20Documentation%20for%20ASPs.zip

有关容量规划的关键技术

使用适合和支持现有及未来技术的技术，是创建具有成长性并能适应不断变化客户需求的容量管理 ASP 基本结构的重要部分。ASP 在容量管理中应采用的一些技术包括如下：

• 网络负载平衡 (NLB)。允许 ASP 调整群集中多个节点或主机 TCP/IP 服务的容量。同时还支持滚动升级（升级不需中断服务）。
• 群集。 用来供 ASP 控制意外风险，也可用作活动配置中的容量工具，其中所有节点都参与响应服务请求。

  基于策略的网络 (PBN)。该技术可以允许 ASP 设置以下策略用于容量管理中：

  • 创建允许降低某些资源的性能从而在负载变化时保持其它资源性能的服务质量策略。
  • 优先考虑基于网络通信的用户、计算机或进程。
• 启用目录的网络 (DEN)。 可以通过允许 ASP 将所有的对象信息储存在单个目录中，将该技术用于容量管理。
• 动态分区。允许 ASP 随时为需要资源的应用程序分配系统资源。这些相同的资源可以随后重新分配。通常的使用方法是在营业时间内当需求量较大时为消息应用程序分配一个分区，而在随后当夜晚维护操作形成需求高峰时为数据库操作分配同一分区。

ASP 应确保该解决方案创建在便于使用这些技术的平台上。在兼容硬件上执行时，Microsoft Windows 2000 Datacenter Server 是支持下列功能的经济选择：

• 可达 32 个 NLB 节点，四个活动群集
• PBN
• 支持由 Microsoft 和 Cisco 提交的 DEN 当前分布式管理任务组规范的计划
• 对四个处理器分区中多达 32 个处理器进行动态分区

它使 Windows 2000 Datacenter Server 成为 ASP 最为灵活的容量管理平台之一。

案例研究：Trey Research

关于 Trey Research

Trey Research 是一家新型的全球性生物工程研究机构（虚拟），根据美国食品及药物管理局 (FDA) 要求，该公司在每个星期五提供参加有争议的新药试验的所有病人的病情记录。该公司主要由硕士和博士组成，但缺乏称职的 IT 工作人员。

三年前，Trey Research 的病情记录提交应用程序（名为 TrialMed）发生全面的系统崩溃，暴露了其应急规划运行不良的状况，其中包括备份和恢复。这起事故令 Trey Research 花费四个多星期重新手工输入所有的数据，以恢复到符合 FDA 管理要求的状态。

为了集中精力保证其核心能力，也为了避免 FDA 可能对其采取的惩罚措施，Trey Research 转向一家 ASP，请他们提供包括托管 TrialMed 应用程序在内的多种服务。

这家 ASP 为 Trey Research 提供的服务详细地记录在服务级别协议 (SLA) 中。与 TrialMed 应用程序相关的 SLA 非常全面，涉及各种服务的提供，如容量管理、备份、网络吞吐量、安全、更改管理、报告和应急规划。

SLA 中有关 TrialMed 组件的容量管理

对于与病情记录相关的任何内容，工作成果的机密性都是一个关键问题，因此 Trey Research 要求与交付 TrialMed 应用程序关联的所有硬件为该应用程序独自专用。

SLA 通过一些术语来定义容量管理，其中包括容量监测、供应以及如何控制容量事故。

SLA 中有关 TrialMed 组件的应急规划

由于 TrialMed 应用程序是遵守 FDA 规范的关键性环节，因此应急规划规定该应用程序必须能在四小时之内完全恢复。

问题

两方面的问题极大地提高了对 TrialMed 应用程序的需求。首先，正在进行的最大的、也是最重要的临床药物试验通过了 FDA 的一项检测，参加实验的病人数量增长了三倍。病人数量的变化使需要的存储量成三倍增长，同时也使 TrialMed 应用程序资源的负荷成三倍增长。其次，FDA 规定有所更改，更改要求在报告过程中包括更多的数据。这个报告方面的变化成倍地增加了 TrialMed 应用程序资源的负荷。

根据 SLA 规定，Trey Research 已经预计到了 FDA 规定的更改，并已完成了供应过程。ASP 与 Trey Research 一起，已经预计了规定更改所需增加的容量，外加一些冗余容量，以满足系统所用容量的增长。Trey Research 没有预料到在关键的药物研究中病人数量三倍的增长对该应用程序的全面要求。

在任务异常繁重的报告流程中，规定更改造成的负载和参与人数增长造成的负载相加，导致出现了一个需求高峰。而这样的需求高峰进而导致性能大大降低，应用程序的超时错误使得某些数据输入失败。

ASP 发现了这一容量问题，并根据 SLA 中建立的事故报告协议将该问题通知客户。此时，Trey Research 才告诉这家 ASP 病人数量的增长。Trey Research 无法根据 SLA 获得所需的资源。因为这家 ASP 刚刚完成了容量的重大升级（因 FDA 规定更改引起），硬件中剩余的附加容量远远不能满足所需资源三倍增长的要求（在组合高峰期由病人数量的增加而引起）。尽管不符合 SLA 中规定的供应要求，这家 ASP 还是提议增加一个可用性较低的服务器以增强处理能力，作为一个临时解决方案（可用性限制要求每个永久性解决方案都必须具备可用性高的群集服务器）。

经过两周的无故障运行后，Trey Research 同意这家 ASP 的客户经理购买这台临时服务器，因为这台服务器已经配置好了，并能满足当时的需要。

在使用的第三周，就在执行提交任务的一个星期五，这台“临时”服务器失败了。这就导致无法支持剩余应用程序资源的需求，该应用程序随之失败。

这家 ASP 的恢复小组发现这台服务器是一个低可用性解决方案，并与以前的客户有着相关的恢复准则 — 72 小时完全恢复。为节省库存空间，这家 ASP 与分销商之间达成协议，即在 24 小时内提供这台设备的部件。ASP 在 12 小时后收到了分销商运来的主板，并在两小时之后恢复了这台服务器。

这一事件致使 Trey Research 未能满足 FDA 的要求，此后 FDA 冻结了他们的药物研究达 30 天之久，对其进行调查。Trey Research 花了几十万美金在 FDA 调查期间维护必要的资源。该药物最终延迟上市造成的机会错失，估计损失达数百万美元。

原因何在

为了临时补救因 Trey Research 不符合 SLA 供应过程而导致的问题，ASP 在另一个客户废弃的可用性较低的服务器上建立了 TrialMed 应用程序。由于这并不作为一种长期的解决方案，而只是对事故的权宜之计，因此随后没有实施供应的一般准则和该应用程序的更改管理，并且容量管理人员同意使用该解决方案。Trey Research 购买该附加服务器后，希望该服务器的运行能够符合 SLA。此购买没有实行更改管理，因为实际上服务器已经在运行。容量管理没有专门进行有关该解决方案的任何风险评估。

事故检测。立即检测出促使使用临时服务器的初始事件，并执行了 SLA 中确定的适当操作。

事件管理。当确定需求高峰的原因后，ASP 通过提供临时的低可用性解决方案，尽可能挽救这种情形，以“阻止事态继续”。ASP 在产品中临时性安装了不相符的容量。

容量管理。 直到出现最初容量事故，ASP 才供应与 SLA 中指定的应用程序相关的容量。由于未向 ASP 通知病人数量的增长，Trey Research 无法执行适当的容量供应过程，并引发最初的事件。

一旦 Trey Research 选择将临时解决方案永久化，ASP 就没有再评估临时解决方案以执行 SLA 中规定的更改管理过程，而最终导致了对容量要求的违背。

服务级别管理。 由于 Trey Research 违反了 SLA 供应过程，在最初的容量事故中没有满足 SLA 的容量部分。

低可用性服务器的失败所引起的第二次事故导致 ASP 无法满足 SLA 的要求。产生的对剩余应用程序资源的负载导致无法满足 SLA。

小结。 与这组事故相关的事件序列如下所述：

1. Trey Research 未能遵守应用程序容量供应过程，导致发生容量性能事故。
2. ASP 根据 SLA 确定该容量事故并对其进行管理。
3. ASP 为处理紧急事件提供临时解决方案，未能遵循 SLA 中定义的更改管理过程。
4. ASP 和 Trey Research 未能执行 SLA 中定义的更改管理过程，并允许应用程序配置的“临时状态”永久化。
5. 将临时解决方案确定为永久资源后，ASP 没有执行更改管理过程，在容量规范内配置永久解决方案。
6. 服务器失败。
7. ASP 无法满足 SLA。
8. 对剩余的应用程序资源生成负载导致无法承受的需求高峰，致使 ASP 不能满足 SLA。

这类问题的解决

该问题是由 ASP 和 Trey Research 不合理的规划行为所造成的。因而他们共同承担该问题的责任。SLA 没有通过适当的详细措施确定如何在运行稳定之后管理由容量问题引发的紧急状况。以至于 ASP 出于好意采取的措施仅在短期内帮助了客户，但从长远来讲，证明对双方都造成了巨大的损失。

假如 SLA 已明确规定了如何处理这类状况，那么该问题本来是可以妥善管理、对双各方都有利。一旦将临时解决方案确定为永久解决方案后，只要遵循涉及到容量管理的 SLA 更改管理指导方针，就可以避免随后的失败。

此外，SLA 应当说明 SLA 内部本身没有包含的任何问题的管理过程。通常这正是设计更改管理过程所要包括的内容。本案例中，所有参与者都不清楚 SLA 的更改管理部分才是紧急问题管理的权威机构。

对于 ASP 来说，通过可用的任何方法来努力管理紧急状况并不少见。重要的是，临时解决方案只是临时的。决不允许将临时修补变成产品资源。当 ASP 为了处理客户造成的紧急状况而出于诚意采取合理的措施时，SLA 应确保 ASP 不承担继起的责任。

ASP 管理员需要遵循他们自己的供应过程。支持某个应用程序的容量并不局限于帮助该应用程序运行的服务器资源。容量概念还包括确保物理基本设施（电源、冷却、数据中心房产等等）和人员能够支持增长的负载，并确实具有适当的可用性。容量的供应和一般更改管理始终应包括一个认证过程，以确保平台满足 SLA 中定义的所有适用的要求。

利用规模调整技术也可帮助管理这类问题。如果 ASP 在实施该解决方案时，在 SLA 中规定了共享硬件的专用实例，则该平台可利用动态分区。在这样的方案中，支持增长的需求所必需的资源已分配给了 TrialMed 应用程序。而且，如果 Trey Research 为满足提交的最后期限总是在星期五达到需求高峰，则资源可以根据需要实现动态分配。当 Trey Research 不需要这些资源的时候，还可以将其分配给其他客户。如 Microsoft Windows 2000 Datacenter Server 这样支持该技术的产品能够通过规模调整为 ASP 及其客户提供更大的实惠。

小结

为 ASP 和客户提供价值

容量管理是 ASP 可利用的一种有利措施，可以在面对潜在的客户时使自己从竞争者当中脱颖而出。各个 ASP 之间的最大区别最终表现在是否提供一贯的高服务质量和能否获得全面的客户满意。决定 ASP 容量管理的三个关键因素是：规划高质量的 SLA 文档的技巧；服务供应和计费系统的集成；根据 SLA 为客户生成有意义的性能报告的能力。容量管理是 ASP 确保实现为客户所提供价值的一个密不可分部分。

其它信息

课程

有关当前课程的信息，请访问 http://www.microsoft.com/。MOF 课程正在编写中，很快就能提供。

首字母缩写词

AD：

 

Active Directory

 

ASP：

 

应用程序服务提供方

 

BSS：

 

业务支持系统

 

CMDB：

 

配置管理数据库

 

CRM：

 

客户关系管理

 

DEN：

 

启用目录的网络

 

ESf：

 

企业服务框架

 

GC：

 

全局编录

 

ITIL：

 

IT Infrastructure Library

 

MOF：

 

Microsoft 操作架构

 

MRF：

 

Microsoft 准备工作架构

 

MSF：

 

Microsoft 解决方案架构

 

NLB：

 

网络负载平衡

 

OSS：

 

操作支持系统

 

PBN：

 

基于策略的网络

 

QoS：

 

服务质量

 

SLA：

 

服务级别协议

 

SLR：

 

服务级别要求

 

WMI：

 

Windows 管理规范

 

书目

下列书籍为本白皮书的参考书目或推荐读物，它们有助于进一步理解此处包含的概念：

Availability Management，IT Service Management Forum/CCTA, ITIMF Ltd., ISBN 0 11 330551 6。

Capacity Management，IT Service Management Forum/CCTA, ITIMF Ltd., ISBN 0 11 330544 3。

Contingency Planning，IT Service Management Forum/CCTA, ITIMF Ltd., ISBN 0 11 330524 9。

Service Level Management，IT Service Management Forum/CCTA, ITIMF Ltd., ISBN 0 11 330521 4。

参考资料

Art and Science of Web Server Tuning with Microsoft Internet Information Services 5.0， http://www.microsoft.com/technet/iis/iis5tune.asp

ASP Consortium， http://www.aspindustry.org/

Best practices（最佳做法）， http://www.aspindustry.org/members/BestPractices/DeliveryModel.cfm , http://www.microsoft.com/ISN/downloads/Best Practices Documentation for ASPs.zip

E-Commerce Technical Readiness Capacity Planning（电子商务技术准备工作的容量规划）， http://www.microsoft.com/technet/ecommerce/capplan.asp

Integration of Provisioning and Billing for ASP-Hosted Microsoft® Exchange 2000 Server（ASP 托管 Microsoft® Exchange 2000 Server 供应和计费集成）， http://www.microsoft.com/ISN/downloads/Provisioning and Billing Integration for ASP-Hosted Exchange 20002.doc

ITIL Library， http://www.itil.co.uk/

Microsoft 企业服务框架出版物， http://www.microsoft.com/enterpriseservices/

Microsoft Operations Framework process model（Microsoft 操作架构过程模型）， http://www.microsoft.com/enterpriseservices/MOF.htm

Microsoft Site Server 3.0 Commerce Edition， http://www.microsoft.com/technet/commerce/usagepre.asp

Microsoft Windows 2000 Active Directory Sizer 工具， http://www.microsoft.com/WINDOWS2000/downloads/deployment/sizer/default.asp

Microsoft Windows 2000 Performance Tuning（Microsoft Windows 2000 性能调节）， http://www.microsoft.com/WINDOWS2000/guide/platform/performance/reports/perftune.asp

Microsoft Windows 2000 Terminal Services Capacity and Scaling（Microsoft Windows 2000 终端服务容量和缩放）， http://www.microsoft.com/windows2000/library/technologies/terminal/tscaling.asp

http://www.microsoft.com/WINDOWS2000/library/resources/reskit/tools/hotfixes/tscpt-o.asp

Microsoft .NET Enterprise Servers， http://www.microsoft.com/net/

Microsoft Windows Management Instrumentation（Microsoft Windows 管理规范）， http://www.microsoft.com/ISN/downloads/Operations for ASPs.zip

终端服务器容量规划工具， http://www.microsoft.com/WINDOWS2000/library/resources/reskit/tools/hotfixes/tscpt-o.asp

附录 A：容量管理工具

示例

容量管理工具的一些示例包括：

• Microsoft Windows 2000 工具

  Windows 2000 Active Directory Sizer 是一个非常有用的工具，可帮助预测 Active Directory 的容量要求。有关该工具以及该工具本身的详细信息，可通过 Microsoft 的 Web 站点获得。

  http://www.microsoft.com/WINDOWS2000/downloads/deployment/sizer/default.asp

  Microsoft Windows 管理规范 (WMI) 是容量管理中的一个相当有用的工具。请参见 Microsoft Web 站点以获取详细信息。

  http://www.microsoft.com/ISN/downloads/Operations for ASPs.zip

• 瘦客户机服务器

  Citrix Installation Management Services (IMS) 允许多个企业资源复制应用程序数据。IMS 并不在五个 Windows 2000/Citrix MetaFrame 1.8 上都安装新的应用程序，而是将对单个服务器的更改内容复制到该企业内的所有其它已配置的服务器上。

• Web 托管

  Web 容量分析工具 (WCAT) 是随 IIS 资源工具包一起发行的，也可以通过 TechNet 获得。其中包含几个帮助测试 HTTP 中心负载的脚本。

附录 B：ASP SLA 容量指导方针

SLA 容量管理组件

SLA 定义 ASP 与其客户之间的关系。SLA 有许多组件，几乎针对业务关系的所有可能的方面。对 ASP 的容量管理最重要的三种 SLA 组件如下所述：

• 应用程序解决方案交付基本结构
• 网络连接
• 客户接口

应用程序解决方案交付基本结构 SLA

应用程序解决方案交付基本结构 SLA 的设计目的在于定义一些基本的问题，讨论为什么样的服务提供多大的服务量。这些服务的范围涵盖了 ASP 的 LAN 上的所有内容。它应当相对于所提供的服务量，以及在需求高峰时性能降低的可接受测量标准的有关信息来解决容量更改管理问题。

网络连接 SLA

网络连接 SLA 的设计目的在于确定性能测量标准和 ASP 与其客户之间网络连接的相关服务级别。该服务可以由同一个 ASP 作为其它服务来管理（直接管理或通过对客户透明的合作关系管理），也可以由单独的提供方来管理。

客户接口 SLA

客户接口 SLA 的设计目的在于解决客户 LAN 内的所有问题。某些情况下，ASP 可能只通过一般的方法（Web 浏览器）来支持应用程序的分发，将该组件的支持和管理留给了内部客户资源，因为它分量不大。而在其它情况下，ASP 服务的该组件可能既完整又复杂。客户接口 SLA 应适当地陈述这些问题。

SLA 的通用性

在每个 SLA 中，不但应说明如何管理 SLA 范围内各种问题，还要说明如何管理没有具体说明或记录的情况。无论 SLA 写得多好，ASP 环境总是在动态变化之中，很可能发生不期的事故。要确保存在管理这种可能性的过程。通常，这是一个全面更改管理策略的组件，不仅包括容量管理，而且包括完整的 ASP/客户关系。

从客户的角度来看，只用一个帐单就付清与提供 ASP 服务相关的所有开支，那是很理想的，即使其中涉及到多个服务提供方。为满足这种客户目标，许多 ASP 与其他 ASP、电信公司和区域技术服务提供方合作，以创建客户角度的单一服务。要确保在所有合作方之间都有符合总体 SLA 的各个 SLA。例如，如果 ASP 与客户之间有一种合作关系，这种关系规定了一定的网络延迟罚金，那么与提供该服务组件的合作伙伴之间的 SLA 中的罚金应确保等于或大于前面的罚金。

以下列出了以容量管理为中心的参数，有助于考虑基于容量的 SLA 的细节：

应用程序解决方案交付基本结构 SLA 的考虑事项：

网络连接 SLA 的考虑事项：

• 服务在 ASP 的范围之内或之外
• 确定源于网络连接容量事件的机制
• 网络可用性
• 网络吞吐量
• 冗余
• 附加服务的带宽供应/计费条件
• 滞后时间/延迟
• 多租赁考虑事项
• 容量性能测量标准的监测和报告准则
• 不履行的处罚
• 计划的中断（可能对某些容量供应是必需的）
• 事件管理机制
• 服务条件的终止
• 服务量的初始状态
• 服务供应的更改管理控制
• 应用程序可用性和性能（并行用户、在负载高峰时可接受的性能降低，等等）
• 应用程序解决方案交付平台和体系结构
• 附加服务的供应/计费条件
• 多租赁考虑事项
• 容量性能测量标准的监测和报告准则
• 不履行的处罚
• 计划的中断（可能对某些容量供应是必需的）
• 容量减少机制
• 容量事件管理机制
• 服务条件的终止

有关该主题的详细信息，可通过 ASP Consortium 获得，网址为： http://www.aspindustry.org/members/BestPractices/DeliveryModel.cfm ， http://www.aspindustry.org/members/BestPractices/sla.cfm

有关“企业服务”的信息，请访问 http://microsoft.com/enterpriseservices/

© 2000 Microsoft Corporation。版权所有。

本文档所包含的信息代表了在发布之日，Microsoft Corporation 对所讨论问题的当前看法。因为 Microsoft 必须顺应不断变化的市场条件，故该文档不应理解为 Microsoft 一方的承诺，Microsoft 不保证所给信息在发布之日以后的准确性。

本文档仅供参考。在本文档中，MICROSOFT 不做任何明示的或暗示的保证。

Microsoft、BackOffice、MS-DOS、Outlook、PivotTable、PowerPoint、Microsoft Press、Visual Basic、Windows、Windows NT 和 Office 徽标均为 Microsoft 在美国和/或其它国家（或地区）的注册商标或商标。

本文例举到的公司、组织、产品、人员和事件均属虚构。决不意指任何实际的公司、组织、产品、人和事件。