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 過程模型（如下所示）顯示了服務管理功能適用的方面。

marginwidth="1" marginheight="0" src="images/ASPCAP02.GIF" frameborder="0" width="95%" height="305">
如果您的瀏覽器不支持內嵌框，請單擊此處在單獨的頁中查看。

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 站點有三個要求：

質量。按服務級別協議 (SLA) 中明確要求的質量向客戶交付產品。
速度（和執行/實施時間成反比）。提供及時的管理資源，以滿足 SLA 中明確標明的解決方案要求。
價格（以較低成本爲佳）。最佳的和可預計的成本。

事先進行容量管理可確保客戶需要的質量、速度和價格等尺度之間的平衡。應牢記一個經驗法則是：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 管理員可以非常簡便地計算出應用程序可支持的用戶數量。

從該等式可得出兩種推論：

降低每個用戶對應用程序的負載可增加支持用戶的數量。這一點通過規劃、編制和配置應用程序以充分高效利用資源得以實現。
增加過程限制的資源（如 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。

優點：應用程序配置集中在服務器上，可進行單點管理，對網絡應用的要求較低，最低的客戶端配置要求，對客戶端資源要求較低，可以跨平臺分發，管理相對容易，相對減少了軟件授權成本，升級/規模擴充也相對容易。
缺點：這種分發方法相對較新，需要較強的技術性，且供不應求。

優點：應用程序配置集中在服務器上，管理點集中，網絡使用要求較低，客戶端配置要求和客戶端資源要求也較低。
缺點：並非所有的應用程序都完全適和通過終端服務託管，服務器配置可能較爲複雜，對服務器資源要求較高，系統升級選項受限（支持擴大規模）。

優點：爲企業中的多種資源分發處理能力。這是基於 Exchange 客戶的寶貴經驗。
缺點：在服務器和所有客戶端上都要存在應用程序配置要求。

當前有大量的已部署客戶端/服務器應用程序。瘦客戶端服務器應用程序在過去的幾年中應用大大增長。應用程序的 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 來確定和預測提供以下所需服務的資源要求。

marginwidth="1" marginheight="0" src="images/ASPCAP04.GIF" frameborder="0" width="95%" height="150">
如果您的瀏覽器不支持內嵌框，請單擊此處在單獨的頁中查看。

使用 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 代表服務配置對象。）

marginwidth="1" marginheight="0" src="images/ASPCAP05.GIF" frameborder="0" width="95%" height="482">
如果您的瀏覽器不支持內嵌框，請單擊此處在單獨的頁中查看。

有關詳細信息，請查詢“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。

小結。 與這組事故相關的事件序列如下所述：

Trey Research 未能遵守應用程序容量供應過程，導致發生容量性能事故。
ASP 根據 SLA 確定該容量事故並對其進行管理。
ASP 爲處理緊急事件提供臨時解決方案，未能遵循 SLA 中定義的更改管理過程。
ASP 和 Trey Research 未能執行 SLA 中定義的更改管理過程，並允許應用程序配置的“臨時狀態”永久化。
將臨時解決方案確定爲永久資源後，ASP 沒有執行更改管理過程，在容量規範內配置永久解決方案。
服務器失敗。
ASP 無法滿足 SLA。
對剩餘的應用程序資源生成負載導致無法承受的需求高峯，致使 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/

本文檔所包含的信息代表了在發佈之日，Microsoft Corporation 對所討論問題的當前看法。因爲 Microsoft 必須順應不斷變化的市場條件，故該文檔不應理解爲 Microsoft 一方的承諾，Microsoft 不保證所給信息在發佈之日以後的準確性。

本文檔僅供參考。在本文檔中，MICROSOFT 不做任何明示的或暗示的保證。

Microsoft、BackOffice、MS-DOS、Outlook、PivotTable、PowerPoint、Microsoft Press、Visual Basic、Windows、Windows NT 和 Office 徽標均爲 Microsoft 在美國和/或其它國家（或地區）的註冊商標或商標。

本文例舉到的公司、組織、產品、人員和事件均屬虛構。決不意指任何實際的公司、組織、產品、人和事件。