概述
本文評價了 Microsoft® Solution for Internet Business（MSIB）2.0 版的性能和容量、可擴展性和可用性等特征，并為檢驗和測量這些特征提供了一個流程。 您可以利用這一流程判斷用戶負載如何影響硬件資源以及資源如何變成性能的瓶頸。 您可以將這些信息用于：
- 評估增添資源的性能。
- 確定哪些資源可以滿足更大的容量需求。
- 計算某一特定硬件配置的最大能力。
本文中用于計算 MSIB 2.0 站點容量的方法被稱為交易成本分析（TCA）。 如需了解對 TCA 過程更為深入的討論，可以參見以下網址上的 Capacity Planning Using Transaction Cost Analysis Methodology ： http://go.microsoft.com/fwlink/?LinkId=9498。
本文假設：
- 您是一位 IT 人士，對 MSIB 2.0所用的所有軟件和硬件技術都有實際工作經驗。 本文特別著重介紹了 Microsoft Internet Security and Acceleration ( ISA ) Server、SQL Server ®2000、SharePoint? Portal Server 和帶 MSIB 2.0 的 IIS 5.0 組件的 Windows® 2000 Advanced Server。
- 您對 MSIB 2.0 的基礎和企業部署都比較熟悉。
如需了解關于 MSIB 2.0 及其相關組件以及其基準和企業部署方面的更多信息，可參見下面地址處的 MSIB Overview http://www.microsoft.com/china/technet/itsolutions/techguide/mso/msib/default.mspx.
本文分成三個部分論述。 下表介紹了這三個部分
|
標題 |
描述 |
| 第一部分 — 性能和容量規劃 |
提供了監控 MSIB 2.0 站點性能的信息，以及將這些性能數據用于容量規劃特別是如何利用 TCA 方法在您的 MSIB 2.0 站點上進行容量規劃等信息。 本部分還介紹了 MSIB 項目組如何利用這種方法改善了 MSIB 2.0 站點的代碼以及軟硬件配置的。 |
| 第二部分 — MSIB 2.0 站點的性能和可擴展性 |
由于 MSIB 2.0 站點的可擴展性與其性能和可用性是緊密相關的，因此在整個文章中都為您提供了如何縮放您的 MSIB 2.0 站點的信息。 不過，在“ MSIB 2.0 的性能和可擴展性”這一部分中對 MSIB 項目組實現站點代碼和實際 MSIB 2.0 部署所需的吞吐量和可擴展性需求所采用的步驟給出了介紹。 |
| 第三部分 — MSIB 2.0 站點的可用性 |
介紹了軟硬件可用性方法是如何在該解決方案中工作的，討論了用于測試和分析一次部署的可用性的方法，并為更加精確地計算可用性提供了一個數學分析。 |
執行摘要
根據本文所搜集的數據，對運行企業和基本部署的 MSIB 2.0 解決方案的性能和容量、可擴展性和可用性等方面可以得出以下幾個結論：
性能和容量
- 在企業部署中的 Web 服務器為兩處理器 1.4 千兆赫茲 （GHz）的，在六天零 19 個小時的期間內，每臺服務器的處理能力都維持在每秒 82.88 次請求的級別上， CPU 的利用率約為百分之75左右。 這相當于預定使用方案中所定的 3027 名并發模擬用戶的情況。
- 在基準部署中的 Web 服務器為兩處理器 1.4 千兆赫茲 （GHz）的，在六天零 20 個小時的期間內，每臺服務器的處理能力都維持在每秒 92.43 次請求的級別上， CPU 的利用率約為百分之75左右。 這相當于預定使用方案中所定的 3376 名并發模擬用戶的情況。
- 一臺四處理器的帶足夠的驅動器容量的 1.4 GHz SQL 服務器在用于數據庫存儲的時候可以支持大約七臺 Web 服務器的網上需求。 在本文所述的測試中，Microsoft? SQL Server 2000 Enterprise Edition Server 內包括了所有的 MSIB 數據庫。 在本文所述的使用概況和站點概況下， MSIB 項目組進行了測試，結果表明 SQL 服務器上的 磁盤吞吐量需求并未在性能上產生瓶頸。 這是因為 Web 服務器上的請求都是高度緩存的。 要決定一個實際站點需要的確切配置和 SQL 服務器數量，必需要利用準確的客戶數據進行更為詳細的交易成本分析 （TCA）。如需了解關于進行詳細 TCA 的信息，參見“Capacity Model for Internet Transactions and Using Transaction”用于站點容量規劃的成本分析，地址在 http://go.microsoft.com/fwlink/?LinkId=9498。
可擴展性
- 在 SQL 服務器等支持數據層服務器適當增加不致造成瓶頸的時候，可以使用網絡負載均衡(NLB) 服務對多臺 Web 服務器進行線性升級。
可用性
- MSIB 2.0 的企業部署計算得到的系統可用性為 99.616%，這一結果是通過測量群集要素的故障切換和恢復時間得出的。 這一可用性計算結果意味著每個服務器群集的平均無故障時間為一星期。 如果目標平均無故障時間 ( MTTF) 增加到一個月，那么系統計算得到的可用性為 99.910%。
第一部分——性能和容量規劃
這一部分提供了關于監控 MSIB 2.0 站點的信息以及根據這些性能數據利用交易成本分析(TCA)方法進行容量規劃的信息。 對 MSIB 2.0 進行容量規劃的目的是利用可接受的響應時間支持交易吞吐量，而同時將主機平臺的總擁有成本降到最小。 傳統的解決方案常常試圖從一般基準測試的測量結果進行推論得到使用成本。 然而，更為有效的方法是基于交易成本分析（TCA）的。 本部分還介紹了 MSIB 2.0 項目組如何利用 TCA 方法改善了 MSIB 2.0 站點的代碼以及軟硬件配置的。
本部分包括：
- 性能監控
- 交易成本分析
- 性能監控
MSIB 2.0 Web 站點是圍繞著企業級內容易管理 Web 站點的概念設計的。 本站點是為那些希望利用類似功能創建站點的企業設計的快速上市的平臺。 與大多數軟件情況類似，該站點尚未得到完全優化，總有改進的余地。 您應當利用以下的性能計數器監控您的 MSIB 2.0 站點的性能。
關鍵性能的計數器
很多性能目標都是內置于 Microsoft Windows? 2000 操作系統及其他 Microsoft 應用程序和服務中的。 您利用性能計數器可以跟蹤這些目標的性能。
MSIB 項目組利用以下的性能計數器分析 MSIB 2.0 站點的性能。 下面給出的性能計數器是以如下格式編寫的： 性能目標\ 性能計數器
|
性能計數器 |
描述 |
| ASP.Net\請求的執行時間 | 測量處理一個 ASP.NET 腳本所花的時間。 如果計數器的數值顯著增大或者請求的執行時間超過了一秒鐘，那么該系統就是在超過其最優能力工作。 為 MSIB 站點設計的頁面在一秒之內可以很好地工作。 |
| ASP.Net \請求/秒 |
每秒鐘請求一個 ASP.NET 腳本的次數。 |
| ASP.Net \請求的等待時間 |
測量一個對 ASP.NET 頁面的新請求在開始被處理之前等待的時間。 |
| 內存\可用兆字節數 |
以兆字節(MB)測量服務器上可以用于運行過程的內存大小。 如果可用內存過低，服務器將開始把內存分頁到磁盤。 計數器的絕對最小編號為四，不過還是建議維持服務器內存的空間以獲得最佳性能。 |
| 內存\頁面/秒 |
測量正在對硬盤進行的實際內存請求。 計數器的大編號是一種關鍵指標，表明您的系統缺乏內存資源或者是一個實施不良的解決方案。 |
| 網絡接口\字節總數 |
代表某一網絡適配器網路吞吐量的總數。 如果您的服務器中包含了多個您想監控的網絡適配器，那么您必需要為每個網絡適配器單獨配置一個計數器實例。 這是用于跟蹤網路吞吐量的關鍵計數器。 |
| NTDS\NTLM 身份驗證/秒 |
每秒鐘進行的 NT LAN Manager (NTLM)身份驗證次數。 |
| 物理磁盤\ %磁盤時間， |
這三個計算器是用來跟蹤磁盤子系統中的活動的。 磁盤子系統很容易成為任何系統中的瓶頸。 在前端 Web 服務器上，磁盤利用率應當是非常低的，這是因為一個頁面所用的內容和圖像應當能夠在文件系統的高速緩存中很好地匹配。 基本的磁盤活動是日志文件，在 Windows 2000 中對日志文件進行了很好地調整以便獲得高性能。
相反，SQL 服務器則廣泛采用了物理磁盤子系統。 對于快速的 Microsoft SQL Server 2000 計算機來說為 SQL 服務器規劃和校準這一子系統尤其關鍵。 |
| 物理磁盤\ 磁盤讀取/秒， | |
| 以及 物理磁盤\ 磁盤寫/秒 處理器\%處理器時間 | |
| SQL 服務器：數據庫\交易/秒 |
表示每秒鐘為數據庫發起的交易數量。 這一計數器是后端 SQL 服務器活動的關鍵指標。 |
| 系統\上下文轉換/秒 |
表示系統從一個線程切換到另一個線程的次數。 如果該計數器增加到每處理器 5000 以上，這表示服務器和/或應用程序的對稱多重處理(SMP)的可擴展性較差。 Windows 2000 和 Microsoft Commerce Server 2002 的組件都可以很好地縮放。 |
| Web 服務\Get 請求/秒 |
表示每秒鐘使用 Web 服務試圖發起的 HTTP GET 請求速度。 這是用于判斷吞吐量的關鍵計數器。 |
如需了解關于性能計算器的更多信息，參見 Windows 2000 Server 幫助中的“性能目標和計數器”部分。
如需了解建議用于監控您的 ISA 服務器性能的性能計數器的信息，參見 http://go.microsoft.com/fwlink/?LinkId=14746。
交易成本分析
這一部分介紹了 MSIB 項目組用以為 MSIB 2.0 站點計算交易成本分析(TCA)的使用概況和站點概況，并總結了 MSIB 項目組在典型的企業和基準 MSIB 2.0 部署中進行的交易成本分析(TCA)得到的操作成本。 此外，該部分還介紹了如何使用 TCA 方法在 MSIB 2.0 站點上進行容量規劃。 從最開始的意義上說，利用該分析方法的最符合邏輯的地方是在銷售階段中決定許可證數量的時候。
部分包括：
- 使用和站點概況
- 操作成本摘要
- 使用 TCA 方法進行容量規劃
- 使用和站點概況
本部分介紹了 MSIB 項目組用以為 MSIB 2.0 站點計算交易成本分析 (TCA) 的在線使用概況、 MSIB 使用概況和站點概況。 要執行一個 MSIB 2.0 站點的 TCA ，您必須首先創建一個使用概況和站點概況。 然后您才能夠利用 TCA 方法計算您的站點容量，這種方法將在本文后面的部分加以介紹。 編制使用概況的過程在“Commerce Server 2002 Creating a Usage Profile for Site Capacity Planning”中有詳細介紹，地址在 http://go.microsoft.com/fwlink/?LinkId=9498。
在線使用概況
在線概括描述了在線時 MSIB 2.0 站點的使用情況。 這一概括不包括 MSIB 2.0 站點離線時可能發生的任何操作。 下表列出了本文中 MSIB 項目組所用的在線使用概括。 峰值乘數用于計算與平均負載有關的系統的最大容量。 如果每秒鐘的平均請求數量是 50 ，如果您的峰值乘數是 3 的話那么預期峰值將會是每秒鐘 150 次請求。 為了對實施 MSIB 2.0 進行容量規劃，您應當為系統的峰值容量做規劃。
| 描述 |
值 |
| 會話的平均時間 |
6 分鐘(360 秒) |
| 峰值乘數 | 3x 平均值 |
| 每個用戶每次訪問的請求數 | 6 |
MSIB 使用概況
下表列出了本文中 MSIB 項目組測試的 MSIB 2.0 操作使用概況。 這些測試值是通過分析 Web 站點信息流量得到的。 注意以下方面：
其中 分布權重 一欄給出拉某類操作占總請求數的百分比。
其中 標準化 一欄表示分布百分比乘以前表給出的每用戶每次訪問請求數得到的結果。 注意這一欄合計達6。
其中 每個操作的請求數 一欄給出了執行某一操作所用的用戶請求數量。 由于回帖或服務器重定向等原因，有些操作會產生多個 ASP.NET 請求。
其中 每個會話的請求數 一欄給出了用戶在每次會話中發起的對某一操作的請求數量。
站點概況
MSIB 項目組為本文進行的測試中所用的目錄數據庫包含了四種語言編寫的一百萬條項目。 搜索頁組是利用均勻分布方式在一萬個項目的子集中挑選的。 UPM 數據庫中包含了一百萬個用戶。 MSIB 項目組測試了一個有 100 條信道，每條信道 100 條記錄的 MSIB 2.0 站點。
操作成本摘要
本部分列出了用戶訪問 MSIB 2.0 站點時可以執行的每種操作的典型核心成本。 這些成本是根據 MSIB 企業部署和基準部署計算的，這些部署中使用的軟硬件配置如“附件 A -hardware and Network Topology Details”所述。 成本以 P4EM 描述，如本文前面部分“術語定義”所述。 注意，兩種部署下的 SQL P4MC 是一樣的。
下表給出的一些操作涉及到多個 ASP.NET 頁面或 HTML 請求和發布。 每一種成本都表示系統運行在最佳吞吐量下，在這些測試中前端 Web 服務器的 CPU 利用率采用百分之 85，計算得到了這些成本。
為了進行數學分析，在后面的方程中將會把該表看成一個矩陣。
| 操作 | 基礎部署 Web P4MC | 企業部署 Web P4MC | SQL P4MC | 描述 |
| 匿名瀏覽 |
11.56 |
11.08 |
1.950 |
這一組操作是由一位未登錄到 MSIB 站點的用戶進行的。 匿名用戶是通過產品目錄頁面進行瀏覽的。 |
| 匿名目錄搜索 |
28.65 |
28.65 |
28.00 |
這一組操作是由一位未登錄到 MSIB 2.0 站點的用戶進行的。 該匿名用戶發起一個請求并收到一個搜索響應。 |
| 匿名內容搜索 |
57.38 |
40.63 |
6.790 |
這一組操作是由一位未登錄到 MSIB 站點的用戶進行的。 該匿名用戶正在執行內容搜索功能。 |
| 匿名企業頁面 |
12.70 |
12.57 |
1.680 |
這一組操作是由一位未登錄到 MSIB 站點的用戶進行的。 該匿名用戶正在瀏覽內容管理服務器提供的模板和內容。 這一頁組包括豐富的產品記錄。 |
| 匿名主頁 |
11.54 |
10.52 |
3.080 |
這一操作是由一位未登錄到 MSIB 站點的用戶進行的。 這一操作由一位匿名用戶發起，該用戶請求進入 MSIB 2.0 站點的主頁。 |
| 瀏覽 |
19.69 |
24.38 |
2.800 |
這一組操作是由一位已登錄到 MSIB 站點的用戶進行的，該用戶正在瀏覽各種類頁面。 |
| 目錄搜索 |
31.99 |
31.99 |
106.21 |
這一組操作是由一位已經登錄到 MSIB 2.0 站點的用戶進行的，登錄之后該用戶搜索了一個目錄。 |
| 內容搜索 |
33.98 |
32.44 |
6.790 |
這一組操作是由一位已經登錄到 MSIB 2.0 站點的用戶進行的，登錄之后該用戶使用了 Microsoft 內容管理服務器(MCMS)的內容搜索功能。 |
| 企業頁面 |
18.52 |
21.57 |
104.77 |
這一操作是由一位已經登錄到 MSIB 站點的用戶進行的，登錄之后該用戶請求進入該 MSIB 2.0 站點的一個企業頁面。 |
| 主頁 |
20.64 |
24.34 |
2.800 |
這一操作是由一位已登錄到 MSIB 站點的用戶進行的，登錄之后該用戶請求進入 MSIB 站點的主頁。 |
| 注冊新用戶 |
53.07 |
60.11 |
31.800 |
這一組操作是由一位在該站點新注冊的用戶執行的。 |
使用 TCA 方法進行容量規劃
本節提供了為 MSIB 2.0 站點進行容量規劃所用的數學計算方法。 您可以利用交易成本分析 (TCA) 方法將站點中的每項操作隔離開來，以便進行性能調節。 利用 TCA 方法您還可以利用不同的使用配置文件和類似的頁面組計算 Web 站點的容量。 類似地，當您要改變 Web 站點的單個頁面組的時候，您可以簡單計量一下與單個頁面組相關的新成本從而規劃其容量。
每用戶頻率的操作
The 每用戶頻率的操作 如下表所示。 這個頻率是根據定義的使用配置文件獲得的統計結果。 每秒鐘每位用戶的操作次數 一欄給出了每位并發用戶的操作頻率、或請求比率。
每秒鐘的請求頻率 = 每個會話的請求數/會話的平均時間
其中 每個會話的請求數 來自于 每個會話的請求數 一欄，位于 MSIB 使用配置文件 表中，而 會話的平均時間 來自于 聯機使用概況.
這樣一來，對于 匿名主頁 操作來說；
1.64 每個會話的請求數 / (6分鐘*60秒) =0.004556 每個用戶每秒鐘的請求數。.
頻率乘以成本
下一步是要將頻率乘以 Web CPU 和SQL CPU 等硬件資源的成本。 例如，一項操作的 CPU 成本是：
每個用戶每秒鐘的操作成本 ( 單位：P4EM ) = 頻率 * P4MC 成本
其中 頻率 來自于 上表的每秒鐘每位用戶的操作次數 一欄，而 P4MC 成本 來自于 本文操作成本摘要部分中表格的 Web P4MC 欄。 columns of the table in the Operation Costs Summary section of this document.
這樣一來，對于 匿名主頁 操作來說；
0.004556 每秒鐘每位用戶的操作次數 * 11.54 P4MC = 0.05258 P4EM
這樣就得到了每位并發用戶如下的成本矩陣：
根據 CPU 容量計算最大并發用戶數
下一步是要根據 CPU 容量按照如下方式計算最大并發用戶數：
一個系統的 CPU 容量 是用處理器數量乘以 CPU 的 MHz 定額得到的。 因此，對一臺安裝了兩個 2 GHz 處理器的計算機來說；
CPU 容量 = 2 x 2000 MHz = 4000 P4EM
The 工作載荷下的系統目標 CPU 容量 通常由 IT 部門決定。如果沒有這方面的標準可循，那么您應比照著平均的長期載荷對峰值載荷進行分析，據此決定這一目標值，確保 CPU 在100％容量以下運行。 假設一臺計算機在 85％ 的容量下運行，那么應該按照如下方式計算其目標 CPU 容量：
目標 CPU 容量 = 4000 P4EM 的 CPU 容量x0.85=3400 P4EM
為了 根據目標 CPU 容量和總用戶成本計算 Web 服務器的目標用戶容量， 在前表中找到每位并發用戶 Web CPU 的總成本（0.55000）。 然后將這一成本分成目標 CPU 容量。
目標用戶容量 = 目標 CPU 容量 每個用戶 Web CPU 總成本 Web CPU cost per user (基礎 Web P4EM)
= 3400/ 0.5500 = 6182 并發用戶
服務機會
您應當把交易成本分析（TCA）和可用性規劃看作是一種服務機會。 應當將本文祥述的步驟看作是用于管理 MSIB 2.0 站點可用性的最佳做法。
第二部分——MSIB 2.0 站點的性能和可擴展性
這一部分簡單介紹了 MSIB 項目組在實現站點代碼和實際 MSIB 2.0 部署所需的吞吐量和可擴展性需求時所采用的步驟。 這一部分并不介紹 ASP.NET 編碼做法、Microsoft Internet Information Services (IIS) 5.0 調節參數或 SQL 服務器的調節參數。
為了優化 MSIB 2.0 站點的性能，MSIB 開發組對以下內容做了調查：
- 分析 SQL 服務器
- 使用高速緩存方案
- 調節硬件
- 調節 IIS
- 橫向擴展 Web 群
分析 SQL 服務器
優化站點軟件性能和可擴展性的第一步就是分析后端 SQL 服務器的使用情況。 MSIB 項目組為站點內的每個頁面進行了一次 SQL Query Analyzer 追蹤。 以下是免費文本搜索頁面的輸出結果：
EventClass TextData CPU Reads Writes Duration SPID StartTime
SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05 11:07:16.513
SQL:BatchCompleted select * from CatalogGlobal where [CatalogName] =N'ANVIL0' 0 2 0 0 52 2000-12-05 11:07:16.513
SQL:BatchCompleted SET NO_BROWSETABLE ON 0 0 0 0 52 2000-12-05 11:07:16.513
SQL:BatchCompleted SELECT A.* FROM CatalogAttributes A, syscolumns SWHERE S.id = OBJECT_ID('ANVIL0_CatalogProducts') AND A.propertyname =S.name ORDER BY A.PropertyName 15 55 0 16 52 2000-12-05 11:07:16.513
SQL:BatchCompleted EXEC sp_GetResults_for_AllColumns N'ANVIL0', N'*',N'FREETEXT (*, N''testasdf'' )', '', 1,11,1,39 32 1147 0 76 52 2000-12-05 11:07:16.530
SQL:BatchCompleted EXEC sp_CheckCatalog '*', 'ANVIL0', 'FREETEXT (*,N''testasdf'' )' 0 29 0 0 52 2000-12-05 11:07:16.607
MSIB 項目組的第一項查詢優化措施就是在追蹤分析過程中發現的。 MSIB 項目組在頁面上查找重復的查詢并減少冗余的 Select 語句。 MSIB 項目組很好地跟蹤了目標的信息并對代碼重新排序，使得查詢操作只能進行由條件調用，從而完成了這一步驟。
接下來， MSIB 項目組從磁盤讀取的角度確定了最為昂貴的查詢。 為了簡化這些操作，MSIB 項目組嘗試著降低查詢操作的 I/O 復雜性。 例如，改變 Select * 語句，使其歸入隔離更好的返回子集中。
最后，MSIB 項目組通過 SQL 服務器調節向導重放了記錄下的跟蹤結果。 該向導建議對表格索引進行一些變更。 所有這些頁面級變更的組合降低了后端 SQL 服務器的負荷并因此改善了 MSIB 2.0 Web 站點的可擴展性。
在 SQL Server 服務器上，MSIB 項目組保留了與性能有關的所有默認配置。
使用高速緩存方案
提高吞吐量的下一步就是利用應用服務器中的高速緩存。 MSIB 項目組利用了以下的高速緩存方案以優化 MSIB 2.0 站點的性能。
頁面輸出高速緩存
Microsoft .NET Framework 系統內內置了頁面輸出高速緩存。 關于 MSIB 項目組如何使用這種功能的詳細情況在 MSIB Developers Guide 中有所介紹，該資料隨 MSIB 2.0 提供。 這種高速緩存方案對于未經個性化的頁面是有效的，例如那些未用個性化內容對象（PCO）顯示 Microsoft Content Management Server （MCMS）的頁面。
MCMS 服務器的性能
Microsoft Content Management Server (MCMS) 2002 可以在縱橫兩個方向上進行擴展。 目前正在編寫一份關于 MCMS 部署的文件，其中討論了各種可用于 MCMS 的高速緩存方法。 在編寫完成之后，可以從以下地址得到該文件 http://go.microsoft.com/fwlink/?LinkId=15170。如需了解關于 MCMS 2002 高速緩存的更多信息，參見 MCMS 2002 Help 中的“Optimizing MCMS Site Performance”。 如需了解關于利用 MCMS 2002 SCA 設置高速緩存屬性的更多信息，參見 MCMS 2002 Help 中的“Specifying cache properties”部分。 如需了解 MCMS 性能的更多信息，參見 MCMS 主頁，地址在 http://go.microsoft.com/fwlink/?LinkId=8426.
調節硬件
在進行性能分析的過程中，為 Web 服務器和 SQL 服務器選擇正確的硬件發揮著非常重要的作用。 此外知道如何為這些服務器選擇正確的硬件還能夠讓您為其他用戶提供相關硬件的建議。 這一部分介紹了 MSIB 項目組是如何為本文所述的測試選擇 SQL 服務器的。
Web 服務器
在為 Web 服務器選擇硬件的時候， MSIB 項目組考慮了以下幾個方面：
- 內存
- 磁盤子系統
- 網絡系統
- CPU
內存
MSIB 項目組為 Web 服務器配置了較大的隨機存取存儲器（RAM），所配容量超出了服務器運行任務所需的量。 為了確定服務器可以減少多少物理 RAM 內存，之后項目組計算了在工作負載下服務器的最大工作集。 一個典型部署所需的 RAM 數量取決于您為該部署對高速緩存和內存的需求。 不過，在大多數情況下，1GB 的物理 RAM 已經是足夠的了。
磁盤子系統
MSIB 站點前端 Web 服務器的磁盤子系統作為一個只讀設備，是用來存儲自舉分區和站點內容的。 這一子系統必需要有讀/寫設備才能進行文件分頁操作，不過如果有足夠的物理存儲器支持系統的話，這些操作都是最低限度的要求了。 Web 服務器確實是利用磁盤子系統寫事件日志和 Web 日志的。 這種操作已經由 Windows 2000 操作系統進行了很好的調節，很少需要超過一個內存芯片才能達到所需性能的。
網絡系統
Web 服務器上的網絡系統至少應當包括一塊 100BaseT 的網卡。 要實現更高的安全性、可管理性和可用性，服務器應該配備兩塊甚至三塊網卡。 在 MSIB 項目組的測試中，web 服務器的網路吞吐量并不足以用完一塊 100 兆位的網卡能力。
CPU
最后，應當為服務器選用當前最好的 CPU 和處理子系統。 在可以預見到的將來，這個特別的硬件子系統仍將是該服務器的瓶頸。 這是因為動態 Web 頁動態和過程全面的性質造成的。
確定適當的 CPU 數量是 Microsoft Server 每處理器許可計劃的一項要求。 要確定這一需求，需要對您的 MSIB 2.0 站點進行一次 TCA 分析，在本文前面的“使用 TCA 方法進行容量規劃”一部分對此做了介紹。
SQL 服務器
MSIB 項目組利用本部分介紹的指南建立起了 SQL 服務器，使之并未成為 MSIB 2.0 部署中的瓶頸。
在為 SQL 服務器選擇硬件的時候， MSIB 項目組考慮了以下幾個方面：
- 內存
- 磁盤子系統
- 數據庫
內存
大量的隨機存取存儲器（RAM）對于 SQL 服務器是有好處的，因此您應當依照數據庫的工作集權衡 RAM 的數量。 在運行的時候測試網絡的輸入/輸出 （I/O）。 SQL 服務器的處理負荷將是訪問 SQL 服務器數據庫的前端服務器數量以及負荷配置文件的正函數。
磁盤子系統
一般情況下， SQL 服務器最重要的調節選項就是安裝物理磁盤子系統。 為了獲得最佳性能，數據庫應當與它們在不同物理驅動器上的業務處理記錄分離開來。 您應當建立起所有的數據庫、業務處理記錄和 TempDB ，這樣才不致讓單個的磁盤子系統成為瓶頸。 在 MSIB 項目組的測試方案中，磁盤子系統并未成為一個問題。 不過，對于正在運行中的站點來說，您應當認真地將磁盤成本和交易聯系起來考慮，以便為增加的磁盤需求做好規劃。
數據庫
MSIB 2.0 的設計使其可以進行橫向擴展并為后端數據庫系統分區。 用于營銷、用戶配置文件管理、目錄、數據倉庫、交易、內容和管理的數據庫可以分離開來，放到物理 SQL 服務器數據庫中。 這樣一來您就能夠輕松地按照數據庫將部署系統分配到獨立的服務器或群集上去。 關于如何做到這一點的詳細介紹在隨 MSIB 2.0 附帶的 MSIB 2.0 部署指南中可以找到。
調節 IIS
為了進行本分析，MSIB 項目組對前端 web 服務器進行了最小限度的調節。 在默認 Web 站點的 Properties 頁面的 Performance 選項卡上，性能調節塊被改變為每天超過 100000 次命中的數值。 所有其他的設置都保持原狀。 如果您必需要在測試站點或實際站點中改變任何參數的話，那么請每次只改變一個，然后將新的結果與舊結果加以比較。
重要事項： 對這些參數中的任何一個進行不適當的改變可能會給站點管理帶來麻煩。
Web 群：MSIB 2.0 站點的擴展
如果所需的 CPU P4EM 比單臺服務器所能提供的能力大，那么 Web 群將需要用到多臺 Web 服務器。 出于可用性和可靠性的考慮，MSIB 項目組建議在任何部署中最少都要使用兩臺 Web 服務器。
第三部分 — MSIB 2.0 站點的可用性
可用性規劃和可擴展性規劃是非常類似的兩項工作。 可用性規劃的第一步就是要確定您的業務需求。 作為一項指導，建議您重新審查一下您現有站點的行為，然后將您的站點與競爭對手們的站點加以比較。 如需獲得各個競爭對手的可用性和頁面等待時間等信息的列表，參見 http://www.keynote.com，地址在 http://go.microsoft.com/fwlink/?LinkId=15046。
有兩個站點提供了全面的 Internet 性能和一般性能指導性原則，它們是www.mediametrix.com ，地址在 http://go.microsoft.com/fwlink/?LinkId=15045 和“http://Nielsen-netratings.com”，地址在 http://go.microsoft.com/fwlink/?LinkId=15043。
您可以按照不同級別的可用性部署 MSIB 2.0 解決方案。 應當在規劃階段中確定您的 MSIB 2.0 站點的可用性目標。
這一部分介紹了可用性，概述了可能會造成您的 MSIB 2.0 站點不可用的事件，提供了高可用性技術和建議，介紹了如何避免單點故障，并討論了 MSIB 2.0 企業部署的恢復模型。
本部分包括：
什么是可用性？
使站點不可用的三類事件
高可用性技術和建議
避免單點故障
MSIB 2.0 企業部署的恢復模型
確定預期的可用性
什么是可用性？
本文中使用了可用性的定義，因為它是 Internet 站點涉及到的一個概念。 可用性包括可靠性、故障恢復和故障幾個方面。 最常用的可用性計量標準之一就是“九的個數”�！斑@一數字可以轉換為某一系統可正常工作的時間百分比。 例如，一個運行時間百分比為 99.999 的系統可以說成其可用性為五個九。 下表給出了九的個數和時間之間的對應關系。
從運行時間的角度來看可用性
從上表可以看出，可接受運行時間為百分之 99.9 的系統平均每天只有 86.40 秒鐘或每月只有 43 分鐘是不可運行的。 要獲得更多個九的可用性，必需要對系統部署、軟件和解決方案實施的管理加以改進。 要預測一個系統何時甚至是隔多久會發生故障是非常困難的，因此要獲得更好的可靠性，一個關鍵的規劃方法是要縮短故障的恢復時間。 如果您的系統可以在 86.4 秒鐘之內從故障中恢復過來，那么系統即使每天發生一次故障，仍然能夠達到三個九的可用性。
從成功交易角度來看可用性
上述的可用性概念是作為運行時間的函數分析的，與此相反是將可用性作為成功交易的函數來分析可用性這個概念。 換句話說，如果某一個 Web 站點每天處理 100000 個請求，那么百分之 99.9 的可用性就意味著每天有 100 個請求是失敗的。 如果您將此作為衡量可用性的標準，那么在業務規劃中對可用性的要求就可能會發生變化。 例如，在一天之內一個 Web 站點的通信量是在改變的。 在凌晨兩點的時候，您的站點每小時的訪問次數可能還不到 100 。 如果您的站點在這期間發生故障，那么此時發生的失敗請求數量大約要比下午 5 點時少四倍，那個時候是一天中的峰值時刻，每小時的訪問次數為 400 次或更多。
使站點不可用的三類事件
有三類時間可能會造成您的 MSIB 2.0 站點無法工作，從而造成其不可用：人為錯誤、硬件故障和軟件故障。如果規劃不當的話，這些事件中的任何一個都可能會使站點的目標可用性無法實現。
人為錯誤
人為錯誤是最需要認真對待的一類事件。 在用戶和正在工作的站點交互作用的時候，他們可能會執行某些對站點管理造成不良影響的操作。 因此，強烈建議對管理操作首先在專門測試環境中加以測試然后再編寫腳本。 當新的管理操作第一次用于實際運行站點的時候，應當對其進行仔細監控，觀察其對整個系統的影響。 認真的規劃會有助于站點實現最高的可用性。 參見 MSIB Solutions Operations Guide 地址在 http://go.microsoft.com/fwlink/?LinkId=15047 ，其中介紹了可以減少人為錯誤的主意和最佳做法。
硬件故障
硬件故障可能會在任何時候發生。 這類故障包括環境故障，如天災和火災等。 在硬件實現的設計中將單點故障降到最低是降低這種風險的最安全方式。 在部署計劃階段中，MSIB 2.0 站點的實施人員應當編制一份硬件地圖，給出存儲器、網絡和軟件邏輯的所有連接點。 之后可以制定解決潛在單點故障的方案并進行成本和風險對比分析。 這方面可以有很多不同的解決方案，從自始至終對關鍵數據進行簡單磁帶備份到可以容災的系統防護系統不一而足。
軟件故障
軟件故障是可能導致您的站點無法工作的第三類事件。 為了避免因軟件故障造成總的功能損失，MSIB 2.0 使用了群集技術以提高可用性。 站點代碼和基本部件的設計允許在發生臨時故障的時候進行重試操作。 MSIB 2.0 解決方案中執行交易的部分利用了 Distributed Transaction Coordinator (DTC)、Microsoft Message Queue (MSMQ) 和交易以保證數據的完整性。
高可用性技術和建議
這一部分介紹了一些技術和建議，幫助您部署一個高可用性的 MSIB 2.0 站點。
本部分包括：
用于高可用性的群集和負載均衡技術
旨在獲得高可用性的軟件建議
旨在獲得高可用性的硬件建議
用于高可用性的群集和負載均衡技術
群集是指一組相互獨立的計算機，它們共同合作運行公共的一套應用程序或服務，對客戶端和應用程序來說像是單個系統一樣。 群集計算機在物理上通過網線連接到一起，在程序上則通過群集軟件連接到一起。 這些連接使得這些計算機可以使用單獨的計算機無法使用的一些問題解決功能，例如負載均衡和故障切換等。
負載均衡功能將負載在所有配置的服務器之間分配，防止某一臺服務器負載過度。 通過這種方式從而又讓您能夠逐步增大容量以滿足自己的需求。 故障切換功能可以自動將資源從故障的或脫機的群集服務器上轉移到正在運行的一臺服務器上，從而為用戶提供了恒定的支持。 這樣用戶就始終都可以訪問 MSIB 站點的資源了。 目前，Windows Clustering 可以提供如下的群集和負載均衡技術：
- 網絡負載均衡
- Microsoft 群集服務
- 組件負載均衡
網絡負載均衡
網絡負載均衡（NLB）技術可以把多達 32 臺運行 Windows 2000 Advanced Server 組合到經負載均衡的單個群集中，從而可以提供基于 TCP/IP 的應用和服務的可擴展性和高可用性。
在本文測試的 MSIB 2.0 企業部署中，MSIB 項目組利用 NLB 技術將下表所列的服務器群集了起來。
Microsoft 群集服務
在 Windows 2000 Advanced Server 中使用 Microsoft Cluster Service (MSCS) 您可以將兩臺服務器組合到一起作為一個服務器群集工作，確�？蛻舳耸冀K可以使用到任務關鍵性應用和資源。 服務器群集使得用戶和管理員可以把它們作為一個單一的系統而不是獨立的計算機，對服務器的某些資源或節點進行訪問。
在 MSIB 2.0 的企業部署中，MSIB 項目組使用了可感知群集的 Commerce Server 2002 和 SQL Server 2000 的組件。
Content Management Server 2002
Microsoft Content Management Server （MCMS）2002 不支持群集和故障切換。 特別需要指出的是，MCMS 2002 的組件在故障切換時數據庫連接斷開的時候不會自動重試操作。 這樣一來，在被動節點變為活動節點的過程中，指向啟用了 MCMS 的頁面的頁面請求將會產生 ODBC 錯誤。 當系統處于 DEBUG 模式時，或者當瀏覽器會話是發起自正在與數據庫斷開連接的 Web 服務器時，這些錯誤只會返回到客戶端的瀏覽器上。
注: 這些錯誤只是在 MCMS 站點的頁面請求失敗的時候發生。
Commerce Server 2002
關于如何群集每個 Microsoft Commerce Server 2002 組件的詳細介紹可以在 Planning for Reliability and High Availability 中找到，地址在 http://go.microsoft.com/fwlink/?LinkId=15044。
SQL Server
SQL Server 為 MSIB 解決方案主管運行數據庫、管理數據庫和數據倉庫。 另外，SQL Server 2000 還為報告和分析solution 提供了聯機分析處理（OLAP）引擎。
MSIB 2.0 解決方案中所有的服務器產品都要與一臺群集 SQL 服務器一起工作，因此在 MSIB 2.0 的企業部署中， MSIB 項目組實施了一個兩節點的群集。
如需了解群集選項和故障切換群集方面的詳細信息，參見 SQL Server 2000 Resource Kit 中的第 12 章。 MSIB 項目組為本文實施的群集選項在 MSIB 2.0 隨帶的 MSIB Deployment Guide 中有詳細介紹。
組件負載均衡
Microsoft Application Center 可以提供組件負載均衡（CLB）技術，供管理員創建一個服務器群集，對組件請求做出響應。
為了實現高可用性，MSIB 項目組未配置的組件
出于編寫本文的考慮， MSIB 項目組決定以單點故障（SPOF）配置實施本部分前面所述的幾個軟件組件。 這只不過是一個設計決策，并不能反映出使用 CLB 部署的組件能力。
在 MSIB 2.0 解決方案中，有多個 Microsoft Operations Manager Consolidator /Agent Manager 未被 MSIB 實施。 關于如何添加這項功能的詳細介紹可以在 Configuring Microsoft Operations Manager 2000 to Manage Complex Distributed Environments 一文中找到，地址在 http://go.microsoft.com/fwlink/?LinkId=15101.
此外，MSIB 項目組還沒有在一個高度可用的環境中實施 Commerce Server 2002 Direct Mailer 。 關于如何安裝這項功能的詳細介紹可以在 Planning for Reliability and High Availability 一文中找到，地址在 http://go.microsoft.com/fwlink/?LinkId=15102.
OLAP 解決方案同樣未被 MSIB 項目組以一種高度可用的方式加以安裝。 如需了解關于如何實現 OLAP 解決方案高可用性的方面的信息，參見 Creating Large-Scale ， Highly Available OLAP Sites 一文， http://go.microsoft.com/fwlink/?LinkId=15103.
旨在獲得高可用性的軟件建議
建議您在運行 IIS 5.0 的 Web 服務器上使用以下軟件將資源消耗問題降到最低程度，以免這些問題影響到您的 MSIB 2.0 部署的性能和可用性。
IIS5Recycle
IIS 5.0 Process Recycling Tool，IIS5Recycle 是作為一項服務運行在運行著 Windows 2000 和 Internet Information Services (IIS) 5.0 的計算機上的。 IIS5Recycle 的目的是要重復利用過程，在資源消耗問題影響到性能和可靠性之前將其影響降到最小程度。 這一工具可以根據存儲在 Windows 注冊表中的配置對 IIS 過程進行重復利用。 管理員還可以利用 IIS5Recycle 收集信息以便在排除故障過程和應用中使用。
在重復利用 IIS 過程之前， IIS5Recycle 會在啟用了 Windows Network Load Balancing （NLB）的系統中從群集（Web 群）中將 Web 服務器刪除掉。 每次把某一服務器從群集中刪除的時候，到這個 Web 服務器的連接也將會斷掉。 一旦連接號降至配置的閾值之下或已經達到了給定的時間， IIS 服務就得到了循環利用。
如需下載該工具及其隨帶的文檔，可參見 http://go.microsoft.com/fwlink/?LinkId=15077。
旨在獲得高可用性的硬件建議
MSIB 項目組為本文所用的 MSIB 2.0 企業部署方案中包括了以下旨在實現高可用性的硬件建議。
存儲系統
部署中所用的每臺服務器都有其相應的存儲需求。 為了消除單點故障，MSIB 項目組部署了一個存儲區域網（SAN）。 該 SAN 單元本身帶有冗余的驅動器、控制器和電源。 SAN 甚至還可以通過與另一個數據中心之間的遠程光纖連接將自身復制一份。 可以通過冗余的主機總線適配卡實現 SAN 的連接，這樣適配卡本身就不會成為一種單點故障了。
網絡系統
網絡可以具備幾個層次的冗余。 對非冗余服務器中的每塊網絡接口卡（NIC）都進行 分組目的是為了防止 NIC 本身成為一種單點故障（SPOF）。 在本文后面的部分中對單點故障以及如何避免的問題進行了討論。
為了避免因單個路由器故障造成的網絡停用，您可以部署冗余的路由器。 還可以在設計上使路由器最少有兩個到外部網絡，即 Internet 的連接。 這種層次上的設置不在 MSIB 2.0 版本介紹范圍之內。
服務器系統
如本文前面部分所述，為了實現高可用性，MSIB 項目組使用 NLB 和 Microsoft Cluster Service （MSCS）以群集的方式部署了物理服務器。
避免單點故障
這一部分中列出了 MSIB 2.0 部署中典型的單點故障并提供了用于解決每種 SPOF 的高可用性技術。
以下這些方面是 MSIB 2.0 部署中常見的故障點：
- 網絡
- 服務器硬件
- 磁盤子系統
- 應用程序
- 數據庫和數據庫連接
下表所列的技術可以用來在您的 MSIB 2.0 部署中提供高可用性，并且介紹了它們能夠解決哪些故障點。 這些高可用性技術可以解決本文前面介紹的問題。 建議您在部署 MSIB 2.0 site 站點的時候在較寬基礎結構的層次上（如附錄A“Hardware and Network Topology Details”給出的企業部署）采用這些技術。 在您的部署中遇到的單點故障越少，這種部署就更加具有高可用性。
典型的易發故障點和建議采用的解決方案
這一節詳細介紹了 MSIB 2.0 企業部署中典型的易出故障的點（如前表所列）并為避免這些故障提出了建議。
網絡
網絡是將所有的服務器、內聯網、Internet 和用戶連接到一起的結構。 沒有網絡連接的話，整個系統都會癱瘓。 網絡故障可能會由網絡硬件故障、套接字故障或遠程過程調用（RPC）連接造成的。
網絡硬件故障
網絡故障的主要原因有：
- 交換機/路由器故障
- 網絡接口卡 (NIC) 故障
- 電纜媒質故障，如網線故障等
建議采用的解決方案
建議采用的高可用性解決方案如下：
- 利用 TCP/IP 協議。
- 啟用路由和管理協議，如 Routing Information Protocol 2 (RIP2)、Open Shortest Path First (OSPF)和 Internet Control Message Protocol (ICMP)等。 啟用這些協議可能需要配置防火墻策略。
- 部署冗余的交換機、路由器、電纜和分組的網絡接口卡。
套接字故障
許多可感知網絡的應用程序都是利用傳輸控制協議（TCP）或用戶數據報協議（UDP）的套接字與運行在多個服務器之間的應用程序相互通信的。 要實現 Windows 2000 高可用性所需的通信協議為 TCP/IP 。 連接是利用 TCP 或 UDP 模式的套接字建立起來的。 TCP 套接字是一種狀態連接，用于需要數據的決定性定購和保證交付的情形（例如 SQL 查詢和 HTTP 查詢等）。 UDP 套接字是一種無狀態連接，用于定購和交付保證不是非常重要的情況下（如音頻流等）。
TCP 套接字是由 MSIB 2.0 所依賴的下列軟件使用的：
- SQL Server 2000
- Internet Information Server (IIS)
- SMTP Mail Server
- Agent 和 Consolidator /agent Manager 之間的 Microsoft Operations Manager (MOM)
以下的 MSIB 2.0 特性利用了 TCP 套接字：
- Commerce Server 2002 Direct Mail （用于通過 SMTP Server 發送郵件）
- User Profile System （用于連接到 LDAP 服務器：Active Directory?、Site Server 和第三方。還用于連接到 SQL Server）
UDP 套接字由 Commerce Server 2002 所依賴的以下軟件使用：
- Active Directory （最近的域控制器發現算法）
TCP/IP 套接字可能會因如下原因發生故障：
- 網絡故障
- 服務器故障
建議采用的解決方案
建議采用兩種 Windows 2000 高可用性解決方案：
- Microsoft 群集服務 (MSCS)。 這種解決方案適用于 SQL Server （工作于主機和發布者模式下）或 IIS （工作于主機和發布者模式下）。
- 用于 IIS Server 的網絡負載均衡（NLB）服務。 這種解決方案適用于 IIS Server （工作于橫向擴展模式）、SQL Server （工作于橫向擴展模式）、外部 SMTP Mail 服務器和 LDAP 服務器。
遠程過程調用（RPC）連接故障
RPC 連接是由訪問如下內容的應用程序使用的：
- 遠程資源（映射的驅動器、共享文件夾等）
- 遠程 COM+ 組件（通過 DCOM ）
以下的 MSIB 依賴項可能會用到 RPC 連接：
- 遠程 COM+ 應用程序
- 為 SQL 2000 Server 使用 Distributed Transaction Coordinator （DTC）的管道組件
- 用于目的地復制的 Application Center 源
RPC 連接可能會因為以下因素發生故障：
- 網絡故障
- 服務器故障
建議采用的解決方案
建議采用兩種 Windows 2000 高可用性解決方案：
- Microsoft Cluster Service (MSCS)
- Component Load Balancing (CLB) 服務
在故障切換期間，一個訪問群集遠程文件系統服務器的應用必需要執行如下的操作：
- 跟蹤文件或正被訪問的目錄路徑內的搜索位置
- 重新打開正在訪問的文件或目錄
- 從故障切換發生的地點開始繼續處理，從頭開始重新啟動處理過程，或返回穩態，令應用程序來決定解決方法
在故障切換期間，正在訪問遠程 COM+ 服務器（或 MSCS 或 CLB 群集）的應用程序必需要執行如下操作：
- 跟蹤處理點
- 重新初始化遠程 COM+ 對象
- 從故障切換發生之處開始繼續處理，從頭開始重新啟動處理過程，或返回穩態，令應用程序來決定解決方法
服務器硬件
應用程序、中間層和數據庫層都運行在物理服務器上。 盡管 Windows 平臺可以使用容錯系統，不過這些容錯系統往往比較昂貴，而且難以適應大范圍的商品市場。
因硬件故障導致的服務器故障有如下幾種方式：
- 隨機存取存儲器（損壞、耗盡）
- CPU （過熱引起的故障）
- 內部電源（保險絲故障、冗余電源完全失效）
- 母板（電子故障）
在每種情況下，任何一個底層服務器組件的故障都會導致整個服務器的故障。
建議采用的解決方案
為實現服務器硬件的高可用性，建議采用如下的 Windows 2000 解決方案：
- Microsoft 群集服務 (MSCS)。 這種解決方案適用于工作在主機或發布者模式下的服務器。 一般情況下，MSCS 需要對服務器進行讀/寫訪問，其中，客戶應用程序從服務器創建、更新和讀出數據。 一般情況下這種解決方案適用于 SQL Server 、Exchange Server 和 COM+ Server 。
- 網絡負載均衡(NLB)服務。 這種解決方案適用橫向擴展模式。 在這種模式下，多個數據庫服務器在一個單一的虛擬 IP 地址之下進行了負載均衡。 一般情況下這些數據庫服務器是作為主數據庫服務器的用戶工作的，這個數據庫服務器則作為一個數據發布者工作。 在一個數據庫服務器出現故障的時候， NLB 將該服務器從群集中刪除并將連接指向其他正常的服務器。
- 組件負載均衡(CLB) 服務。 這種解決方案適用于 COM+ 應用程序。 遠程 COM+ 組件是安裝在 CLB 服務上的。 在某一臺 COM+ 服務器出現故障的時候， CLB 能夠檢測到該故障并將請求指向功能正常的服務器上。
- 多臺服務器。 專門為 Active Directory Domain Controller 部署多臺服務器。 Active Directory 是通過復制其目錄存儲和在多個域控制器之間分布請求實現高可用性的。
- 硬件冗余。 使用內置硬件冗余的計算機系統，例如冗余電源等。
磁盤
磁盤子系統是由 MSIB 2.0 下列的依賴項使用的：
- IIS Server （包括 IIS 元數據庫、Web 站點內容：ASP ，HTML ，GIF ，PCF 等等。）
- Commerce Server 2002 Direct Mailer 用的 Mail Drop 文件夾
- 搜索內容的內容索引
文件/磁盤子系統可能會因為如下原因發生故障：
- 硬盤驅動器中物理磁頭失效
- 電子故障
- 硬盤驅動器中物理扇區損壞
建議采用的解決方案
在磁盤子系統這一個級別上，建議您使用以下技術中的一個或多個以確保實現高可用性：
- RAID 5
- RAID 1
- RAID 1 + 0
- 多個 SAN 光纖信道通道（交換機、總線和控制器等）
不過，一旦基礎設施級別上的容錯功能未能保護子系統，這種故障就會以文件丟失、目錄丟失或驅動器句柄的形式反映在操作系統（OS）級別上，引起對文件/磁盤子系統資源的后續訪問失敗。 如需了解關于 RAID 的更多信息，請在 Windows 2000 Help 中搜索 RAID 。
應用程序
Commerce Server 和 ISA 等應用程序都是由 MSIB 2.0 用以執行該解決方案所需的綜合軟件功能的。 由于應用程序是運行在平臺操作系統（OS）頂部的，因此存在很多引起故障的原因，包括：
- 磁盤子系統失效
- 網絡故障
- 二進制失效
- 服務器故障
建議采用的解決方案
建議采用兩種 Windows 2000 高可用性解決方案：
- Microsoft 群集服務。 這種解決方案適用于那些本身是服務而且支持這一功能的應用程序組件。
- 網絡負載均衡(NLB)。 這種解決方案適用于工作于橫向擴展模式下的 Search ，ISA ，MCMS 和 Commerce Server 2002 。 在這種模式下，多個應用服務器在一個單一的虛擬 IP 地址之下進行了負載均衡。 前端應用服務器上運行的組件為那些需要使用持續狀態的操作在后端數據庫服務器上維護著狀態。 在一個應用服務器出現故障的時候， NLB 將該服務器從群集中刪除并將連接指向其他正常的服務器。
- 解決方案部署中應當包括對構成應用程序的其他二進制代碼的備份。
數據庫
SQL Server 2000 由 MSIB 2.0 及其依賴項用于連接到數據庫上。 由于數據庫服務器是運行在平臺操作系統和服務頂部的，因此存在很多引起故障的原因，包括：
- 文件/磁盤系統失效
- 網絡故障
- 數據庫應用程序故障
- 服務器故障
建議采用的解決方案
建議采用兩種 Windows 2000 高可用性解決方案：
- Microsoft 群集服務 (MSCS)。 這種解決方案適用于 MSIB 數據庫服務器。 這種解決方案可以提供可靠性，不過卻不能提供額外的可擴展性，這是因為其工作負荷并不是分布式的。
- 網絡負載均衡(NLB)。 這種解決方案適用橫向擴展模式。 在這種模式下，多個數據庫服務器在一個單一的虛擬 IP 地址之下進行了負載均衡。 一般情況下這些數據庫服務器是作為主數據庫服務器的用戶工作的，這個數據庫服務器則作為一個數據發布者工作。 在一個數據庫服務器出現故障的時候， NLB 將該服務器從群集中刪除并將連接指向其他正常的服務器。
- 解決方案部署中應當包括對數據庫和構成數據庫的存儲過程的備份。
類似地，如果現有的計算機出現了硬件資源的瓶頸，那么您應當為 Web 群添加后端 SQL 服務器。 在添加了更多 SQL 服務器之后，構成 MSIB 2.0 解決方案的數據庫應當在 SQL 服務器中分離開來。
MSIB 2.0 企業部署的恢復模型
下圖給出了 MSIB 2.0 企業部署中典型的單點故障，下表介紹了 MSIB 2.0 企業部署是如何從單點故障中恢復過來的。 為了避免發生這些單點故障，建議您在投入實際運行之前在您的 MSIB 2.0 企業部署中采用本文前面介紹的高可用性技術。
注: 在下表中，所謂的可接受時限是指小于默認 ASP 超時時間的一個期間，在理想情況下為 15 秒鐘或更少。 為了進行本文所述的測試，所有的故障切換時間都由 MSIB 項目組進行了記錄。
| 單點故障 | 故障類型 | 檢定/描述 |
| 1(前端應用程序/Web 服務器) | 套接字 | 由 NLB 將 Web 服務器從群集中刪除，最終用戶不會感覺到出現了錯誤或者數據丟失。 |
| 網絡 |
由 NLB 將 Web 服務器從群集中刪除，最終用戶不會感覺到出現了錯誤或者數據丟失。 | |
| 2(前端搜索服務器) | 套接字 |
由 NLB 將 搜索服務器從群集中刪除，最終用戶不會感覺到出現了錯誤或者數據丟失。 |
| 網絡 |
由 NLB 搜索服務器從群集中刪除，最終用戶不會感覺到出現了錯誤或者數據丟失。 | |
| 3 和 4(防火墻之間的連接) | 套接字 | 在可接受時限之內平穩過渡到備份防火墻。 |
| 網絡 | 在可接受時限之內平穩過渡到備份防火墻。 | |
| 5和6(域控制器之間的連接) | 套接字 | 在可接受時限之內平穩過渡到備份的域控制器。 |
| 網絡 | 在可接受時限之內平穩過渡到備份的域控制器。 | |
| 7 和 8(前端 Web 和搜索服務器上的硬盤) |
磁盤 | NLB 將故障服務器從群集中刪除掉。 |
| 9 和 10 (Web 或搜索服務器失效) |
服務器 | NLB 將故障服務器從群集中刪除掉。 |
| 11(第二防火墻層上的硬盤) |
磁盤 | 由防火墻正確地將載荷傳遞到故障切換服務器上，不會給客戶端帶來數據損失或超時。 |
| 12(防火墻失效) |
服務器 | 由防火墻正確地將載荷傳遞到故障切換服務器上，不會給客戶端帶來數據損失或超時。 |
| 13(防火墻和數據庫群集之間的連接) | 套接字 | 為了測試這個連接，建議您對使用未經高速緩存的數據庫請求的 Web 頁面進行測試，以確保不會發生最終用戶可見的錯誤。 |
| 網絡 |
為了測試這個連接，建議您對使用未經高速緩存的數據庫請求的 Web 頁面進行測試，以確保不會發生最終用戶可見的錯誤。 | |
| 14和15 (到域控制器的連接) |
套接字 | 在可接受時限之內平穩過渡到備份的域控制器。 |
| 網絡 | 在可接受時限之內平穩過渡到備份的域控制器。 | |
| 16(Business Desk 計算機和 SQL Cluster 之間的連接) |
網絡 | 為了測試這一連接，建議您在幾種不同模塊中對幾種 Business Desk 功能進行測試，以確保不會發生任何錯誤，以至令系統處于一種部分失效的狀態。 |
| 17( MSCS 數據庫故障切換: 交易、內容、管理、運動） | 服務器 | 一個服務器錯誤會引起包括應用數據庫在內的 MSCS 故障切換。 為了核實這種錯誤狀態，建議您對使用未經高速緩存的數據庫請求的 Web 頁面執行 GET 操作，以確保不會發生最終用戶可見的錯誤。 系統會在被動節點變成活動節點之后重試請求，由 Web 頁面返回成功的請求。 |
| 18(SQL 群集上的硬盤故障：目錄、搜索、用戶) | 磁盤 | 一個系統磁盤錯誤會引起包括應用數據庫在內的 MSCS 故障切換。 為了檢驗這種錯誤狀態，建議您對使用未經高速緩存的數據庫請求的 Web 頁面執行 GET 操作，以確保不會發生最終用戶可見的錯誤。 系統會在被動節點變成活動節點之后重試請求，由 Web 頁面返回成功的請求。 |
| 19(域控制器故障) |
服務器 |
|
| 20(域控制器磁盤失效) | 磁盤 |
|
服務器故障切換恢復
前面的部分討論了如何利用網絡負載均衡（NLB）和 Microsoft Cluster Service （MSCS）消除單點故障。 這一部分的目的是要介紹，當您在企業部署種使用了 NLB 和MSCS 時，MSIB 2.0 是如何從故障種恢復過來的。
ISA 故障切換
在 ISA 服務器因服務器故障而出現故障的時候， NLB 軟件(運行在 ISA 服務器之上)將會把故障服務器從 NLB 群集中刪除掉。 在 ISA 服務器因連接、RPC 或磁盤故障而出現故障的時候，ISA 服務器會將自己從群集中脫離開。 最后的結果是，仍然正常的冗余服務器將會把所有的請求接管過來。
NLB 故障切換
當某一表示層服務器不能發送或響應心跳消息的時候，其他服務器將會進行收斂。 最后的結果是，仍然可對請求作出響應的表示服務器會為故障服務器處理所有的入站請求。 當某臺新的表示服務器試圖加入到該群集的時候，它將會發出一個意在收斂的心跳消息。 當所有的表示服務器都同意接受該成員的時候，將會對客戶端的工作量重新劃分。
SQL Server MSCS 數據庫故障切換
SQL Server 使用了一套共享的磁盤子系統，它可以以一個群集服務器的形式工作。 當群集中的某活動 SQL 服務器出現故障的時候，備用的 SQL 服務器將會接管故障服務器的負載，處理客戶請求，從同一共享盤上讀取和寫數據，如下圖所示。
確定預期的可用性
這一部分將介紹一個計算實例，MSIB 項目組為本文使用了這種計算方法以確定 MSIB 2.0 企業部署的可用性，也稱為預期的正常運行時間。 這一實例是根據 Microsoft Technical Report 中的Markov Model of Availability for Server Clusters 中的數學模型給出的，地址在 http://go.microsoft.com/fwlink/?LinkId=15127.
在這一模型中需要考慮五個 MSIB 2.0 企業部署的群集。 這五個群集都是由兩個節點/計算機構成的，它們必需能夠正常運行，令那些考慮要可用的系統真正可用。 出于這一分析的考慮，群集列舉如下：
1.面向 Internet 的防火墻 NLB 群集
2.Web NLB 群集
3.搜索 NLB 群集
4.內部防火墻 NLB 群集
5.SQL Server 群集
每個群集都有一個可用性，p n 其中，0n <=1。 整個系統的可用性由以下的計算得到：
p1 X p2 X p3 X p4 X p5
群集內每個節點的可用性可以通過帶入以下三個數值的平均測量值得到。
- 故障切換時間 是指從群集發現某一節點停止響應到將其從群集內刪除所花的時間。
- 平均恢復時間(MTTR) 是指將該要素重新引入群集所花的平均時間。
- 平均無故障時間(MTTF) 是最難測量的一個指標。 故障可能會按照一定的頻率發生，不過也可能是隨機發生的。 為了進行討論，在計算過程中允許您在可用性計算時對 MTTF 進行變動。 之所以這么做是為了幫助您判斷要確保特定數量的九的可用性，您的部署必需要滿足或必需要超過的 MTTF 。 這是本文計算可用性的方法與其他方法的根本差別。
MSIB 項目組首先切斷活動-活動群集中來自服務器/節點的基本網絡連接，然后再重新啟用這些連接，通過這種方法測量了企業部署的恢復時間和故障切換時間。 對于活動——被動 SQL 群集，項目組從群集管理控制臺執行了一個移動組命令。 如需了解關于如何測定恢復時間和故障切換時間的更多信息，參見“附件 C——Collecting Availability Data”。 請注意由 MSIB 項目組為本文所述測試部署的系統是按照 MSIB 2.0 隨帶的 MSIB 2.0 Deployment Guides 中所述的嚴格的設置和配置進行部署的。
頂級 ISA NLB 群集
頂級 ISA 網絡負載均衡（NLB）群集是一種雙節點的 NLB Web 服務器群集。 這一系統的可用性是根據服務器群集可用性的馬爾可夫模型（MMASC）計算的。 這一實例是根據 Microsoft Technical Report 中的Markov Model of Availability for Server Clusters 中的數學模型給出的，地址在 http://go.microsoft.com/fwlink/?LinkId=15127對這一群集來說，MSIB 項目組發現其平均故障切換時間為 3 分鐘，MTTR 時間為 9 分鐘 56 秒。
下表給出了根據搜集到的數據和節點的目標 MTTF 為一個活動-活動 2 節點群集計算得到的可用性。 MTTF 仍然無法輕松測到，因此該表給出了在目標 MTTF 處的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.8867%
下表給出了在 MTTF 為 30 天的條件下，計算得到的活動-活動 2 節點群集的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.9735%
注: 前面的兩張表格給出了一個節點和兩個節點情況下的故障切換實例。 對于以單個節點而非一個群集的形式運行的服務器來說，預計其 MTTF 大約為 2節點活動-活動群集的一半。
Web NLB 群集
頂級 Web 服務器 NLB 群集是一種雙節點的 NLB 服務器群集。 這種系統的可用性是根據 MMASC 計算的。 對這一層來說，MSIB 項目組發現其平均故障切換時間為 15 分鐘，MTTR 時間為 9 分鐘 2 秒。 下表給出了兩個不同的 MTTF ，并展示了 MTTF 數值是如何影響節點的總體可用性的。
下表給出了根據搜集到的數據，改變節點的 MTTF ，為一個活動-活動 2 節點群集計算得到的可用性。 MTTF 仍然無法輕松測到，因此該表給出了在目標 MTTF 處的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.9092%
下表給出了在 MTTF 為 30 天的條件下，計算得到的活動-活動 2 節點群集的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.9788%
注: 前面的兩張表格給出了一個節點和兩個節點情況下的故障切換實例。 對于以單個節點而非一個群集的形式運行的服務器來說，預計其 MTTF 大約為 2節點活動-活動群集的一半。
搜索 NLB 群集
頂級 搜索 NLB 群集也是一種雙節點的 NLB 服務器群集。 這種系統的可用性是根據 MMASC 計算的。 對這一層來說，MSIB 項目組發現其平均故障切換時間為 15 秒鐘，MTTR 時間為 4 分鐘 56 秒。 下表給出了兩個不同的 MTTF ，并展示了 MTTF 數值是如何影響節點的總體可用性的。
下表給出了根據搜集到的數據，改變節點的 MTTF ，為一個活動-活動 2 節點群集計算得到的可用性。 MTTF 仍然無法輕松測到，因此該表給出了在目標 MTTF 處的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.9498% 。
下表給出了在 MTTF 為 30 天的條件下，計算得到的活動-活動 2 節點群集的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.9883%
注: 前面的兩張表格給出了一個節點和兩個節點情況下的故障切換實例。 對于以單個節點而非一個群集的形式運行的服務器來說，預計其 MTTF 大約為 2節點活動-活動群集的一半。
中級 ISA NLB 群集
中級 ISA 網絡負載均衡（NLB）群集是一種雙節點的 NLB 服務器群集。 這種系統的可用性是根據 MMASC 計算的。 MSIB 項目組發現，這一層的平均故障切換時間為三分鐘，故障服務器重新加入群集需要六分鐘三十六秒的時間。 下表給出了兩個不同的 MTTF ，并展示了 MTTF 數值是如何影響節點的總體可用性的。
下表給出了根據搜集到的數據，改變節點的 MTTF ，為一個活動-活動 2 節點群集計算得到的可用性。 MTTF 仍然無法輕松測到，因此該表給出了在目標 MTTF 處的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.9197%
下表給出了在 MTTF 為 30 天的條件下，計算得到的活動-活動 2 節點群集的可用性。
使用 MMASC 方法，此 2 節點活動-活動群集計算得到的可用性為 99.9813%
注: 前面的兩張表格給出了一個節點和兩個節點情況下的故障切換實例。 對于以單個節點而非一個群集的形式運行的服務器來說，預計其 MTTF 大約為 2 節點活動-活動群集的一半。
SQL Server 群集
頂級 SQL 服務器 是一種雙節點的活動——被動 MSCS 群集。 這種系統的可用性是根據 MMASC 計算的。
注: 前面兩張表格是和介紹活動-活動群集的表格不同的，這是因為當群集某一成員發生故障的時候，活動——被動群集不能進行更多的工作。 這樣一來，最后一個節點進行故障切換的 MTTF 就等于前一個活動節點的值。
MSIB 項目組發現，這一層的平均故障切換時間為五分鐘，故障服務器重新加入群集需要八分鐘三十秒的時間。
下表展示了 MTTF 數值是如何影響群集的總體可用性的。
使用 MMASC 方法，此 2 節點活動——被動群集計算得到的可用性為 99.9504%
下表給出了在目標平均時間為 30 天的條件下，計算得到的活動-活動 2 節點群集的可用性。
使用 MMASC 方法，此 2 節點活動——被動群集計算得到的可用性為 99.9884%
整體可用性
如前所述，整個集成系統的可用性為以下計算的結果：
p1 X p2 X p3 X p4 X p5
對每個節點都以 MTTF 為一星期和一個月為條件進行計算。 利用這個方程， IT 專業人員可以建立起每個節點的目標 MTTF ，從而實現可測量的整系統可用性。 這樣一來您就能夠掌握主動，決定目標 MTTF 是多少，而不是必需要猜測為了滿足正常運行時間標準系統出現故障之后 MTTF 將會是多少。 這一分析確切地給出了要實現整系統可用性服務水平協議的要求哪些節點必需要加以改進。
下表總結了如本部分前面所述使用了同樣的 MTTF 向量的系統的整體可用性。
附錄 A ——硬件和網絡拓撲詳述
這一部分介紹了在進行本文所述的測試過程中 MSIB 項目組所用的硬件和網絡拓撲。 下圖給出了 MSIB 2.0 基礎部署的網絡圖。
下圖給出了 MSIB 2.0 企業部署的網絡圖。
這一部分介紹了在進行本文所述的測試過程中 MSIB 項目組所用的 Web 服務器的配置。
Web 服務器
CPU: 2 x 1.4-GHz Pentium 4
內存:1 GB
磁盤:18 GB
網絡:100BaseT
這一部分介紹了在進行本文所述的測試過程中 MSIB 項目組所用的搜索服務器的配置。
搜索服務器
CPU: 2 x 1.4-GHz Pentium 4
內存:1 GB
磁盤:18 GB
網絡:100BaseT
這一部分介紹了在進行本文所述的測試過程中 MSIB 項目組所用的 SQL Server 的配置。
SQL server
CPU: 4 x 1.4 GHz Pentium 4
內存:4 GB
磁盤:4 x 18 GB RAID 0
網絡:100BaseT
這一部分介紹了在進行本文所述的測試過程中 MSIB 項目組所用的 ISA 服務器的配置。
ISA 服務器
CPU: 2 x 550-MHz Pentium III
內存:1 GB
磁盤:18 GB
網絡:100 BaseT
附錄 B——許可計算
下表給出了 MSIB 項目組創建的兩個電子數據表。 以后可以從與本文所在的同一 Web 頁面上獲得這些表格。
文件名 用于
MSIB20_tca.xls
根據 TCA 方法計算所需的應用服務器和 SQL 服務器的數量。
MSIB 2 machine counts.xls
生成軟件許可成本。
附錄 C — 搜集可用性數據
當兩臺服務器利用網絡負載均衡（NLB）工作在活動-活動群集的模式下時，這對服務器的系統吞吐量情況將會和下圖類似。
X軸上標出了 4 個點，它們代表了與 NLB 故障切換和恢復過程有關的事件。
從 0：00 到第一個標識點（0:10），群集處于正常運行狀態，服務器 1 和服務器 2 分擔著同樣的負載或吞吐量。到了這一刻，服務器 1 出現故障，無法工作了。
從 0:10 到 0:26 ，到服務器 1 的所有請求都丟失了，這是因為群集還沒有發現服務器 1 出現故障了。 在這期間，群集是以不到一半的容量運行的。
在 0:26 秒的時候，群集發現了服務器 1 的故障，服務器 2 開始處理其請求。 此時服務器 2 是在兩倍的負荷工作的，不過仍然在其限額之內。
1:01 (圖中標注的第三個點）時，服務器 1 重新設定了 W3 SVC 服務，這一過程大約需要一分鐘的時間。
2:00 （圖中標注的第四個點）時，服務器 1 恢復過來并通過收斂過程重新加入到 NLB 群集中來。
在做可用性分析的時候，為了測量群集的恢復時間和故障切換時間，您需要監控兩個時間間隔長度：
- 點 1 和點 2 之間的時間長度，此為故障切換時間。
- 系統發現需要重新設置、進行重新設置并令服務器重新加入群集的過程所需的時間。 出于搜集可用性數據的考慮，您可以將點 2 和點 4 之間的時間作為平均恢復時間（MTTR）。
為了測量 MTTR ，您應當具備管理軟件或警告軟件，以檢測故障并完成故障恢復過程。 對 MSIB 來說，建議您利用 Microsoft Operations Manager （MOM）實現錯誤發現和解決的自動化。 如果您沒有用以自動檢測和故障恢復的解決方案，您應當將解決 IT 問題的平均時間作為 MTTR 。
本文中的信息，包括 URL 及其他 Internet Web 站點的引用，如有更改恕不另行通知。 除非另外指明，在本文例中提到的公司、單位、產品、域名、e-mail 地址、徽標、人員、地點和事件等都是虛構的，不與任何真實的公司、單位、產品、域名、e-mail地址、徽標、人員、地點和事件發生任何聯系，也不應從中做任何此類聯系方面的推斷。 用戶有責任遵守所有適用的版權法律。 在不限制版權所賦予權利的前提下，沒有 Microsoft Corporation 明確的書面允許，不得以任何形式或通過任何手段（電子的、機械的、影印、錄制或其他）或出于任何目的復制本文的任何部分或將其存儲或引入檢索系統，或進行傳播。
Microsoft 可能具有一些專利、專利申請、商標、版權或其他知識產權涉及到本文所述主題。 除非微軟公司通過書面許可協議明確提供，此文檔并沒有授予您對這些專利，商標，版權或其他知識產權的任何許可。
®1996-2003 Microsoft Corporation 。 保留所有權利。
文章來源于領測軟件測試網 http://www.k11sc111.com/