Windows 2000 Web 伺服器高可用性最佳做法

#1 引用回覆回覆

發表時間：2003-02-11 10:31:08

IP:61.218.xxx.xxx 未訂閱

本頁索引

簡介

選擇伺服器可用性目標

Web 應用程式設計的最佳做法

Web 伺服器部署計劃

管理 Web 伺服器

伺服器失敗與復原的最佳做法

附錄

摘要
作業系統 Tim Hodgkins 撰稿 Microsoft Corporation 發行日期：2001 年 10 月 摘要要達到 Web 伺服器的高可用性，需要有設計優良與充分測試的應用程式、充分測試過的伺服器硬體，以及嚴格的伺服器監控與管理。本文檢驗在採用 Microsoft 技術下，組織可採行以達成單一伺服器 99.99% 可用性的策略與技術。銘謝 Katie Beers、Reza Baghai、Wael Bahaa-El-Din、Mario Garzia、Björn Levidow Matthew Kerner、Ram Papatla、Michael Risse、Microsoft Corporation。簡介要達到 Web 伺服器的高可用性，需要有設計優良與充分測試的應用程式、充分測試過的伺服器硬體，以及嚴格的伺服器監控與管理。自從 Windows 2000 作業系統上市以來，Microsoft 與十家外部知名的網路公司和五個 Microsoft 機構合作，測量並改善其個別網站的可用性。我們從這些寶貴的合作關係中學到了很多，其中最重要的是了解作業行為如何影響伺服器的可用性。本文檢驗在採用 Microsoft 技術下，組織可採行以達成單一伺服器 99.99% 可用性的策略與技術。第一節中定義可用性與可靠性的一般性詞彙、描述伺服器可用性變數間的關係，以及列出 Microsoft 所開發用來協助組織測量其伺服器可用性與可靠性的工具。下一節將討論達成單一伺服器 99.99% 可用性的第一個步驟—設計與建置 Web 應用程式的最佳做法。這一節主要是針對 Web 應用程式開發人員所撰寫，但是當 Web 伺服器管理員在進行 Web 伺服器疑難排解時，也會發覺本章節相當的實用。這一節主要在分享建置良好的元件與Active Server Page® (ASP) 處理序的最佳做法，另外還附加資料庫連結的討論。本文的第三個章節主要在探討達成單一伺服器 99.99% 可用性的下一個步驟—建置與部署高可用性的伺服器。這個章節列出 Web 伺服器管理員應該在部署前後針對確保伺服器穩定性執行哪些步驟。廣泛的執行應用程式與硬體相容性測試及調整，可以維持 Web 伺服器高度的可用性。這個章節最後還包含容錯與負載平衡技術的討論。最後一節是針對 Web 伺服器管理員所撰寫，探討組織管理 Web 伺服器時可用的最佳做法，討論 Microsoft 主要的伺服器管理工具。接著討論組織可採用以減少伺服器停工時間的主動式最佳做法，例如偵錯祕訣、Hotfix 與安全性更新。本文將討論實際的客戶問題狀況，並且提供組織可用來識別與解決一般性問題的建議。下列清單是您的組織可用來改善 Web 伺服器可靠性與可用性的十個最佳建議：

如果您使用 Visual Basic 開發應用程式，請使用 VBCHKW2K 公用程式來驗證適當的編譯設定。
充分地測試軟硬體與 Windows 2000 之間的相容性。
盡量使用共用處理序 ASP 網頁。
盡量使用共用處理序 COM 元件。
使用 Web Capacity Analysis Tool 與 HTTP 監視器對應用程式做壓力測試。
記錄並追蹤 Web 伺服器的部署計劃。
安裝並使用 IIS 5 Recycle Tool 來增加 Web 伺服器的可用性。
在 Hotfix 與安全性更新發行後，進行其適用性的評估與排定優先順序，然後記錄並追蹤此處理序。
使用 HFCheck 與 QFECheck 以確認所有伺服器的標準作業系統安裝。
選擇伺服器可用性的目標，並使用 Microsoft 工具來追蹤達到該目標的進度。

在本文接下來的內容中會針對這裡提到的問題與建議提供詳細的客戶案例與程式碼範例，藉此讓您的組織瞭解與改善 Web 伺服器的可用性與可靠性。注意本文重點在於伺服器可用性與網站或其他服務可用性間的對立。本文討論的所有工具與最佳做法的重點都在測量與改善單一伺服器的可用性。在高可用性與可靠性的個別伺服器上增加容錯設定與網路負載平衡 (NLB)，將可成為高可用性的網站。 選擇伺服器可用性目標 可用性與可靠性詞彙這個章節定義本文所用的可用性與可靠性詞彙。 可靠性—在一般 (或所述的) 環境條件下作業，產品 (系統) 在特定時間內執行預定功能的可能性。¹ 本文中，個別伺服器的可用性取決於計算伺服器兩次關閉間的標準時間。關閉間的標準時間一般是指兩次重新開機之間的標準時間，就是關閉伺服器的平均時間值。雖然所有重新開機的狀況並不是導因於錯誤，但所有的重新開機都會導致停工時間，從可靠性的角度來看可視為錯誤。伺服器可以執行數日不需要重新開機，所以關閉間的標準時間通常是以數日為單位進行報告。 關閉間的標準時間 —伺服器關閉間的平均時間。以下列公式來計算 (假設是 24x7 的生產伺服器): 執行時期 — 當伺服器執行特定作業系統版本時，Windows 事件記錄所涵蓋的時間總和。因為需要相當長的執行時期來評估可用性，所以執行時期通常以年度為度量單位來表示。 可用性 — 伺服器在一般作業條件下 (當需要時) 執行預定功能的可能性，通常是以百分比表示。假設是 24x7 的生產伺服器，可用性是以下列公式來計算： 還原標準時間 — 停工期間的運算標準。還原標準時間的度量單位是分鐘。與時間相關聯的伺服器可用性一般而言，網站是為了服務全球的網際網路讀者。這表示掌管網站的伺服器必須是每周 7 天每天 24 小時全時段都可使用。由此可知，我們可以使用可用性度量資訊來計算伺服器可承受多少的停工時間，而還能達到要求的可用性目標。表格 1 顯示在一般性使用的可用性等級中，單一伺服器可用性與停工時間的關係。停工時間欄列出在單一伺服器仍能滿足其可用性目標狀況下，單一伺服器一年內被允許的最長停工時間。最後兩欄顯示，要滿足單一伺服器可用性目標為平均停工時間 5 分鐘與 10 分鐘時，每年所允許的最多關閉時間。例如，為達成單一伺服器 99.9% 可用性，伺服器每年停工時間不能多於 8.76 小時。以伺服器關閉而言，可換算成每年 50 次關閉而每次修復時間 5 分鐘，或是每年 25 次關閉而每次修復時間 10 分鐘。 表格 1 比較可用性與停工時間

單一伺服器可用性 (%)	關閉間標準時間 (天)	最長復原標準時間 (分鐘)
99.9%	60	86.5
99.95%	60	43.2
99.99%	60	8.6
99.999%*	60	.9

注意如果關閉間標準時間為60天時，不可能達成單一伺服器 99.999% 可用性目標，因為伺服器開機時間會超過 9 分鐘的最長復原標準時間。這次所研究知名網站的 Web 伺服器的復原標準時間都介於 5 到 10 分鐘之間。如果組織可以很快地進行失敗的排解疑難，並讓 Web 伺服器回復執行，則可達到復原標準時間。表格 3 詳述復原標準時間為 10 分鐘時，要達成可用性目標所允許的最短關閉間標準時間。表格 3 的計算包含計劃中的與不在計劃中的關閉。如果組織選擇扣除維護視窗期間所發生的關閉，必須重新計算可用性度量資訊，移除計劃中的維護停工時間。 表格 3 最短關閉間標準時間

Maximizing ASP Performance ASP-資料庫最佳做法
對 Web 開發人員而言，使用 ADO (ActiveX Data Objects) 與 ASP 在 Microsoft SQL Server 上擷取資料可能是一項挑戰。因為越來越多的 Web 應用程式是做為與資料庫溝通的介面，所以了解讓開發的效能、延展性與強固性最佳化的方法很重要。如果計劃要用 IIS 中的 Web 應用程式來呼叫資料庫元件，請使用下列的準則與最佳做法： 使用 ADO 時，永遠關閉資料錄集與連接。 如果「開啟」連接，則使用此連接之後再將它「關閉」。如此一來，可以安全地將此連接交給另一個執行緒以處理不同的命令。如果伺服器負載變輕，則連接共用會自動調整回來，而讓使用同一伺服器的其他程式有較佳的效能。如果伺服器負載變重，則共用區可以會視需要加大。選擇不使用連接共用則會造成閒置連接，這樣會浪費伺服器和網路資源。此外，您也會發現如果多重並行執行緒使用同一個連接時，可能會發生執行緒的問題。

Q176056： ADO/ASP Scalability FAQ

晚開 – 早關。 需要 ADO 物件時才將其開啟，並且在使用完後立即關閉。這樣做會縮短資料庫安排資源的時間，並且使資料庫連接盡快釋放回連接共用以允許新的連接。

25+ ASP Tips to Improve Performance and Style

不要在執行陳述式時傳遞參數給命令物件。傳遞參數給命令物件將會迫使 ADO 處理額外的處理工作，也會對所傳遞的參數做出假設。下列程式碼範例展示了傳遞參數至命令物件的不良做法。

Set DB = Server.CreateObject ("ADODB.Connection") 
    DB.Open "Provider=SQLOLEDB;Data 
    Source=dsnTest;Database=dbTest;john;Password=doe;" 
    Set RS = DB.Execute ("GetCustomerByLastName @LastName='Smith'")
    RS.Close 
    DB.Close 
    Set RS = Nothing 
    Set DB = Nothing

比較好的做法是明確地宣告命令物件的參數，如以下的程式碼範例所示。

Set DB = Server.CreateObject ("ADODB.Connection") 
    DB.Open "Provider=SQLOLEDB;Data 
    Source=dsnTest;Database=dbTest;john;Password=doe;" 
    Set cmdTemp = Server.CreateObject ("ADODB.Command") cmdTemp.ActiveConnection = DB 
    cmdTemp.CommandText = "GetCustomerByLastName" 
    cmdTemp.CommandType = adCmdStoredProc 
    Set params = cmdTemp.Parameters 
    params.Append cmdTemp.CreateParameter ("RETURN_VALUE", adInteger, 
    adParamReturnValue, 0) 
    params.Append cmdTemp.CreateParameter ("@LastName", adVarChar, adParamInput, 
    15) 
    cmdTemp ("@LastName") = "Smith" 
    Set RS = cmdTemp.Execute
    RS.Close 
    DB.Close 
    Set RS = Nothing 
    Set DB = Nothing 
    Set cmdTemp = Nothing

一定要使用 Server.CreateObject。 使用 Server.CreateObject 讓 ASP 可以追蹤物件執行個體。伺服器部分導致在 Transaction Server 套件中建立物件，而資源被置入共用區。伺服器端指令碼使用 CreateObject 與 GetObject 函數而不使用 Server.CreateObject，將導致無法存取 ASP 內建的物件也無法加入交易。使用 CreateObject 與 GetObject 會在個別執行緒上附加新物件，如此一來，將會比使用Server.CreateObject 的連接共用功能更快消耗可用的系統資源。

ASP Component Guidelines

不要重複使用資料錄集或命令變數，應該建立新的資料錄集或命令變數。 重複使用資料錄集或命令變數可能會增加程式集在 ADO 中產生錯誤的風險。「命令物件」不是設計以這種方式使用的。

Q197449： Problems Reusing ADO Command Object on Multiple Recordsets

設定資料來源的 ODBC 設定時，盡量使用系統 DSN (而不要用檔案 DSN)。系統 DSN 比檔案 DSN 快三倍。 不要把 ADO 連接放入工作階段物件中。 如果把 ADO 物件放入工作階段，不僅會產生延展性限制與執行緒問題，而且還會對 Web 伺服器與資料庫造成負荷。如果連接儲存在 Session 變數則會消除連接共用，因為存放於 Session 物件的變數會保留給整個使用者工作階段。如果連接是由多個用戶端共用，而且資源是在有需要時才使用，則連接共用是有效益的。儲存於 Session 變數的 Connection 物件只服務於建立此 Session 的使用者，而且這個 Connection 在 Session 結束之前都不會被釋放到共用區。

如果 Session 物件在遠端電腦上執行，則使用 TCP/IP 通訊端連接 SQL Server。 TCP/IP 通訊端不需要 NT 信任連線，也不需要遵從標準 SQL 安全性，繞過使用具名管道進入遠端電腦的相關驗證問題 (請參閱以下資訊)。如果 SQL Server 在另一台電腦上，TCP/IP 通訊端能提供更快的連線。

Top Ten Tips:Accessing SQL Through ADO and ASP

如果 SQL Server 在本機 (與 ASP 在同一部電腦) 執行，則使用具名管道。 使用網路具名管道預設需要信任連線。當用戶端嘗試經由網路具名管道連線，SQL Server Windows NT 的電腦不僅會執行安全性檢查，並且還會驗證用戶端的電腦帳戶，這樣做需要往返適當的網域控制站一趟。如果 SQL Server 與網域控制站的路徑無法使用，可能就無法建立連線。如果 SQL Server 是在與執行 IIS 和 ASP 相同的電腦上執行，則使用本機具名管道連線而不使用網路具名管道連線。這種方式的簡單作法是在 global.asa 檔案中，將 SQL Server 連接字串的關鍵字 SERVER=machinename 變更為 SERVER=。這樣做可以避免為了驗證而必須往返網域控制站，而節省寶貴的網路頻寬。

Q207671： How to： Accessing Network Files from IIS Application

確定已在每個 ASP 網頁建立連線物件。 以每個 ASP 網頁為單位來建立或刪除 Connection 物件，而不要將物件儲存在 Session 變數，以善用連接共用的功能。刪除網頁的物件會將連線釋放回共用區以重複使用。資源共用可減少伺服器負載，也可在初始連線建立後，減少使用者的資料庫連線時間。在 ISAPI 複雜的狀況中，經由使用最佳化的連接共用實作後，Microsoft Performance Group 測量到介於 30% 到 40% 的 CPU 使用量改善。這個測量使用 TPC-C 與 TPC-W 等效能基準。

Top Ten Tips:Accessing SQL Through ADO and ASP

如需有關 Web 應用程式開發的詳細連結與資源，請參閱〈附錄〉。 Web 伺服器部署計劃 當設計與建置完成 Web 應用程式後，下一步就是建置與測試裝載新應用程式的 Web 伺服器。除了 Windows 2000 所需的安裝步驟之外，還需要確認所用的支援應用程式與硬體實體都與 Windows 2000 相容。以下章節將描述為確認高可用性伺服器平台所必須做的重要計劃。應用程式相容性安裝或升級為 Windows 2000 的第一個步驟，就是確認用於支援業務的應用程式可以與 Windows 2000 相容。Microsoft 經由與外部客戶合作發現，與 Windows 2000 不相容的應用程式是主要的問題來源，這不僅會造成非志願的停工時間，而且還會減低伺服器可用性。不相容的應用程式所產生的相關問題範圍很廣，像是無法啟動應用程式、記憶體流失與存取違規。 Microsoft 提供名為「Windows 2000 完備性分析程式」的線上工具，可用於產生報表來詳細描述指定伺服器上已知的軟硬體相容性問題請注意，本工具中並未提到任何其他廠商的相容性問題，特別是您自行建置與部署的應用程式。 最佳做法 - 升級為 Windows 2000 之前，請先使用下列文章中的資訊來識別並解決應用程式的相容性問題。「Search for Compatible Software Applications Wizard」與「Microsoft 完備性分析程式」允許您搜尋與不同版本的 Windows 2000 相容的應用程式。「Windows Application Compatibility Toolkit」包含文件與工具，可以用來協助 Microsoft Windows 客戶診斷和解決應用程式相容性，例如，一般相容性問題白皮書與許多最佳測試做法，還有協助解決相容性問題的工具。

硬體相容性升級為或安裝 Windows 2000 時考慮硬體的相容性也相當重要。Microsoft 經由根本原因分析，出現藍色螢幕等許多失敗事件肇因於失敗的篩選器驅動程式與不相容的 BIOS。根據與 Microsoft Reliability Team 合作的許多網路公司回報，在安裝 Windows 2000 時，某些狀況下會遇到非預期的停止畫面 (藍色螢幕)，這是因為 Windows 2000 媒體中沒有該 SCSI 裝置的驅動程式。幸運的是，Microsoft 提供了許多的資源，以協助您在生產環境中安裝 Web 伺服器之前，找出並解決硬體的不相容性。上一個章節中提到的「Windows 2000 完備性分析程式」工具也可以協助判定伺服器上潛在的硬體相容性問題。另一個方法是，如果您由 Windows NT 4.0 升級為 Windows 2000，則可於插入 Windows 2000 安裝光碟片之後，在命令列執行 winnt32 /checkupgradeonly，以找出與伺服器設定相關的相容性問題。除了 Microsoft 提供的工具與資源之外，與伺服器廠商直接聯絡以判定其產品與 Windows 2000 的相容性也是非常的重要。通常硬體廠商會發行經過測試與認證與 Windows 2000 相容的 BIOS 更新版與儲存裝置驅動程式的更新版。 最佳做法 – 在安裝 Windows 2000 之前，先使用下列的連結來確認硬體與驅動程式與 Windows 2000 的相容性。「Search for Compatible Hardware Devices and Computers Wizard」允許您在升級或安裝 Windows 2000 之前，先判定伺服器與硬體是否與 Windows 2000 相容。部分的搜尋結果中包含製造商提供的 Windows 2000 驅動程式下載連結。

Windows 2000 部署的考慮事項當您確信伺服器硬體與應用程式都與 Windows 2000 相容，下一步就是將 Windows 2000 部署至 Web 伺服器。您必須考慮數個選項以決定使用何種部署方法對業務環境最有利。接下來的幾個章節的內容敘述必須遵循的伺服器建置程序以確保高可用性平台。一般而言，建置伺服器應該包含下列步驟：

判定硬體需求 (磁碟機設定、記憶體等)
判定應用程式需求 (其他的軟體、指令碼環境等)
識別安裝選項 (映像基底、指令碼安裝、Whistler 中的 RIS)
判定執行磁碟複製 (如果可用) 之前是否需要任何 OS 設定
記錄一致、可重複執行的安裝方法

以下為上述步驟的詳細說明。 步驟 1 - 判定硬體需求與標準平台 經由與許多不同的客戶合作讓 Microsoft 更加肯定，選擇並遵循標準平台讓系統管理員能更容易地執行作業系統安裝、應用程式安裝與疑難排解。下列範例是關於一般硬體平台的決策類型：

硬碟應該如何分割？
硬碟或光碟機是否應該重新對應至不同的磁碟機代號？
Web 伺服器應該使用單一處理器或多個處理器？

最佳做法 – 運用 Web Server Capacity Planning 文件來幫助您解答上述問題，以及其他與硬體功能性計劃相關的問題。從硬體的角度來看，最佳的功能性計劃策略是先仔細地觀察使用狀況、監視其模式，然後依照監視的結果來增減資源。

Web Server Capacity Planning

步驟 2 - 判定應用程式需求 在大部分的狀況下，Web 應用程式涉及許多部分，而這些部分又位於不同的伺服器上。這樣通常使得 Web 伺服器上必須安裝其他的軟體。例如，Web 應用程式在電子商務交易的狀況下，通常會使用資料庫來尋找檢查您銀行帳戶餘額的方向。為了滿足這個需求，您必須檢驗資料庫連線方法與網路最佳化等設定，以確保軟體元件間的成功整合。 最佳做法 - 計劃伺服器建置時不僅要記錄需要哪些應用程式，還要記錄這些應用程式的安裝方法，以及支援這些應用程式所需的其他設定。例如，如果您預計會在Web 應用程式中使用 SQL 資料庫，則需要安裝與設定 ODBC 以符合應用程式的需求。這個資訊在自動化安裝或排解安裝疑難時十分重要。 步驟 3 – 識別安裝選項 安裝執行 Windows 2000 Server 與 Windows 2000 Advanced Server 的伺服器時有三個主要的選項。這些選項為：

自主式 (Unattended) 安裝時使用可開機光碟片與回應檔案
自主式 (Unattended) 安裝時使用網路分享與回應檔案
使用 Sysprep 磁碟映像安裝

上述的安裝選項各有其優缺點，各點詳細描述於下列表格 4

------
︿︿

系統時間：2024-06-30 14:55:40

聯絡我們 | Delphi K.Top討論版

本站聲明

1. 本論壇為無營利行為之開放平台，所有文章都是由網友自行張貼，如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權，而損及您的利益，請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨，是藍是綠本站無權干涉，但這裡不是政治性論壇！