ISA Server 效能最佳對策

Dd548175.community-sm(zh-tw,TechNet.10).gif本頁索引

簡介
容量策略
調整 ISA Server
微調 ISA Server 資源
微調 ISA Server 案例
微調 ISA Server 功能
瞭解工作負載
參考和其他資訊


Internet Security and Acceleration Server 2000 效能最佳對策白皮書

最後更新日期:2002 年 11 月

簡介

ISA Server 容量規劃的目標在於便於規劃 ISA Server 部署的軟硬體組態,以符合客戶特有的效能和容量需求。

關於 ISA Server 容量的典型問題可能是:「在具有 n 個使用者的組織中,我需要什麼硬體來支援 ISA Server?」下面會更詳細地剖析這個問題,解釋每一個部份:

硬體 (或資源) 指 ISA Server 電腦上由 ISA Server 使用的實際硬體元件,例如 CPU、RAM、網路和磁碟等。它有幾種可能的意義:

  • 電腦中的一或多個 CPU (升級)。
  • 一或多台電腦 (擴充)。
  • 組織實際或所需的網際網路連線頻寬。
  • 特殊用途的硬體,例如 SSL 加速器、RAID 磁碟等。

需要 指設定要使用的 ISA Server 組態的客戶需求。這裡舉出一些客戶需求的範例,對於計算正確的容量可能非常重要:

  • 建議使用何種網際網路存取原則?
  • 使用者是否必須經過 ISA Server 驗證?
  • 是否必須記錄 ISA Server 活動?
  • 是否建議使用任何協力廠商的 Web 或應用程式篩選器 (例如防毒軟體、內容篩選等)?

支援 ISA Server ISA Server 有數種案例,每個都有各自的效能/容量特性:防火牆、Web 快取、Web 發佈、伺服器發佈、周圍網路 (Perimeter Network)。客戶需要其中哪些功能?

組織 方面,不同的組織有不同的需要。銀行的網際網路存取模式和網際網路服務提供者 (ISP) 的模式就不同。例如,一組同質使用者通常比非同質群組消耗更少的 ISA Server 資源,因為前者的要求通常可以用快取達成。

n 個使用者 指的是預期的工作負載。使用者人數對正確的容量規劃可能過於模糊,因為這些使用者的一般平均網際網路使用模式很難知道。能提供更多資訊的測量標準是組織目前使用網際網路連線的頻寬。經常部署 ISA Server 的情況是組織已經使用某個防火牆或快取,而且網際網路連結有足夠的頻寬時。

用更廣義的名詞來重述上面的問題:由某個指定工作負載載入的指定 ISA Server 案例組態需要何種資源作為支援?本文件提供回答這個問題的必要方針。

首先先說明三個簡單的<容量策略>,分別適合不同廣泛範圍的客戶。容量策略可以識別客戶的容量需求,並提供自訂方針以用於需要區分容量的部署。建議所有的 ISA Server 使用者閱讀本章節。

下面的<調整 ISA Server>說明從目前需求成長到未來容量需要的方法。建議大型企業級的客戶閱讀本節。

接下來的幾個章節將會說明 ISA Server 效能微調:<微調 ISA Server 資源>、<微調 ISA Server 案例>和<微調 ISA Server 功能>。建議想要增加 ISA Server 部署容量、更有經驗的技術人員閱讀這些章節。另一個針對處理特定使用模式來增加容量的章節是<瞭解工作負載>。

容量策略

判斷 ISA Server 部署所需資源的第一步是瞭解客戶的容量需求。為了達成這個目的,有幾個合乎不同廣泛範圍客戶的策略。

一般而言,客戶可能會做以下評估:

  • 網際網路連結的網路頻寬。
  • 組織內的網際網路使用者人數。
  • Web 服務的存取次數 (每天) (通常在發佈案例中)。

在這幾點之中,ISA Server 容量規劃最有價值的評估標準是網際網路連線的頻寬,因為在大多數的案例中,這代表了客戶真正的網際網路容量需要,因為這是高效率使用的昂貴資源。

組織中的網際網路使用者數目並非容量規劃的良好標準,因為使用模式、網際網路使用原則等因素會讓每個組織間有很大的差異。

就其本身而言,存取次數也沒有用,但在很多情況下這指出客戶還有其他更有價值的標準,例如最高要求率、要求類型分布等。

所有的 ISA Server 容量規劃案例都可列入下列類別中:

  • 網際網路連線頻寬太低,成為 ISA Server 系統的障礙。這就適用於「單一入門級 ISA Server 電腦」策略。
  • 網際網路連線頻寬大於單一電腦的用量,並將 ISA Server 用於轉送/輸出分析的案例中。這就適用於「大型企業」策略。
  • 網際網路連線頻寬大於單一機器能夠填滿的量,並將 ISA Server 用於發佈案例。這就適用於「發佈」策略。

下列各章節會詳細說明這些策略。

單一入門級 ISA Server 電腦

單一 ISA Server 電腦容量策略適合在低網際網路連線頻寬的組織中輸出防火牆和轉送快取。根據最近網際網路使用的市場調查報告,大多數美國的企業網際網路連結都在 1 到 10 Mbps 頻寬的範圍內。這項事實就足以指出有一個或兩個處理器的入門級電腦就可以滿足大多數的 ISA Server 部署。

根據輸出防火牆的測試結果,在單一 Pentium III 733-MHz 處理器上執行的 ISA Server 防火牆服務使用百分之 70 的處理器能力時可以提供 25 Mbps 的處理量 (混合 HTTP 和資料流媒體) (這是 SecureNAT 用戶端最差情況下測出的處理量)。這表示對於 1.5 Mbps T1 網際網路連結而言,防火牆服務只會使用百分之 5 的 CPU 資源。

根據轉送快取的測試結果,具備單一 Pentium III 733-MHz 處理器的入門級 ISA Server 電腦每秒可以承受高達 660 個 HTTP 要求,快取命中率為百分之 35,非快取回應為百分之 50,平均回應大小為 7.6 KB,CPU 資源使用為百分之 75。這會導致約 39 Mbps 的伺服器處理量,但網際網路連結處理量只有 25 Mbps,根據的假設是系統硬體資源設計為最高 CPU 使用率 (詳細資訊請參閱<最大化 CPU 使用的系統設計>):

isprfp01

660 :每秒要求數。

65%:非快取命中率的要求百分比 (快取遺漏和非快取)。

7.6 x 1,024:7.6 KB 平均回應大小。

8/10242:從每秒位元組數轉換成每秒百萬位元數 (Mbps)。

如果網際網路連結為頻寬 1.5 Mbps 的私人專用 T1 連線,那麼系統將可以承受每秒最多 39 個要求,因為:

isprfp02

在這個要求率下,ISA Server 僅將使用百分之 5 到 10 的 CPU,其餘的 CPU 資源就可以用於在同一電腦上執行的處理序。在這樣的低 CPU 使用率之下,甚至在以 733-MHz Pentium III 處理器輸送 T1 連結時,於 ISA Server 整合模式中使用通透式快取,仍能保持百分之 50 到 70 的合理 CPU 使用率 (通透式快取效能的詳細資訊請參閱<微調用戶端>)。

單一入門級電腦策略適用的情況為網際網路連線頻寬夠低,可以由單一入門級電腦的能力加以滿足時。這個策略的行動方針很簡單:在自己選擇的入門級電腦上安裝和設定 ISA Server,準備工作完成

這個策略也適用於有多個分公司的大型企業,每個分支都有獨立的低頻寬網際網路連結。在這個案例中,將每個分支視為一個小組織,只要單一入門級 ISA Server 電腦就足以完全利用自己獨立的網際網路連線。

接著要判斷電腦效能能力和其支援的網際網路連線頻寬之間的關係。下表顯示每個案例中使用百分之 100 網際網路連線時 Pentium III 733-MHz 處理器的 CPU 使用 (請注意處理量在網際網路連結上)。

表 1   受限於網路系統的 CPU 使用

 75% CPU 使用率的網際網路 Mbps1.5 Mbps (T1) 時的 CPU 資源佔用百分比4.5 Mbps 時的 CPU 資源佔用百分比15 Mbps 時的 CPU 資源佔用百分比45 Mbps (T3) 時的 CPU 資源佔用百分比
輸出/輸入防火牆 (SecureNAT 用戶端) 2941238115
輸出防火牆 (防火牆用戶端) 61261956
轉送快取2541345134
反向快取71251648
整合式防火牆/快取3241136107

「75% CPU 使用率的網際網路 Mbps」欄陳述 Pentium III 733-MHz 處理器可以支援的網際網路頻寬,下四欄指出完全使用該指定頻寬的網際網路連線時估計的 CPU 使用層級。根據這個表格,對於大多數網際網路連結,所有的案例都可以在這類硬體上執行。就高階來說 (T3 連結),Pentium 4 機器將可滿足需要。

大型企業

對於大型企業規模的站點,例如 Microsoft 在 Redmond 的總公司,情況就更為複雜。這個案例的 ISA Server 容量策略需要更精密的規劃,因為網際網路頻寬夠大,可以將效能瓶頸移到系統的 CPU 資源。這個策略適合用於轉送和反向快取,以及防火牆案例。

對於需要完全使用連線的機器數目,網際網路連線頻寬仍有上限,而這個最大值對於大多數容量估計可能都夠用。此外,容量需求會隨著時間增長,因此規劃最大網路容量是良好的保守估計。這也需要規劃將來的成長,方法是啟用簡單的處理能力升級。<調整 ISA Server>說明硬體調整技術、它們的效能特性和其他調整的益處。

如需更正確地規劃 ISA Server 容量,關鍵在於瞭解工作負載。<瞭解工作負載>一節說明數個可以使用的方法。不過在很多案例中,瞭解工作負載或許不可行,因為資源有限或無法取得資訊 (例如在建立新的大規模 ISA Server 系統時)。對於組織之間工作負載變化不大的轉送案例 (輸出防火牆和轉送快取),瞭解工作負載或許並沒有益處。

發佈

發佈案例和轉送案例不同處在於網際網路連結要負責用戶端和伺服器之間的連線。每天服務數百萬次點擊的大型網站會使用每秒可以服務數千個要求的網際網路連結。ISA Server 在這裡並非用於加速,而是從裝載的網站中卸載可快取的回應。然而,如果網際網路連結低於 70 Mpbs,發佈案例就可以使用單一電腦策略來處理。另一方面,大型網站 (即時服務的連結最大為 70 Mbps) 在 ISA Server 部署到兩台機器的陣列上時,可以獲益於已啟用的改良容錯度。對於防火牆伺服器發佈案例,單一 Pentium III 733-MHz 電腦的最大處理量為 29 Mbps。

但對於大型發佈網站,容量策略則類似大型企業。同樣的,從考慮到最大網際網路頻寬的保守估計開始,加上硬體調整策略,大多數大規模客戶可能就有足夠的處理能力。

但在發佈案例中則和轉送案例不同,工作負載的變化由於內容特性的差異而更大了許多。這會導致應付相同要求率的網站之間有很大的容量差異。如果保守估計的硬體價格太高,根據瞭解工作負載而取得更正確的估計後,說不定就能大幅降低硬體價格。

調整 ISA Server

有兩個方法可以增加系統的 CPU 能力。一個方法是在電腦中加入更多處理器 (假設電腦已有多處理器盒),這稱為升級 (Scaling-up) 處理器能力。另一個方法加入另一台電腦 (假設電腦已排列在叢集中),這稱為擴充 (Scaling-out)

ISA Server 同時支援升級和擴充,下列各節會詳細說明這兩種情況。

升級

Windows 2000 和 Windows .NET 設計為實作對稱式多處理 (SMP)。有了對稱式多處理,作業系統可以在任何可用的處理器上執行執行緒。因此,在需要額外處理能力以增加系統的處理量能力時,SMP 讓應用程式可以使用多個處理器。

然而,由於其他的硬體資源,例如所有處理器共用的記憶體和 I/O 裝置,在多處理器電腦系統中將處理器的數目加倍,並不一定會讓應用程式可以處理的交易數量加倍1。相反的,很少有應用程式可以達到線性調整。取決於案例,ISA Server 的調整係數為 1.6 到 1.7。

擴充

有幾個方法可以擴充 ISA Server 系統。

  • 使用高層級網路交換硬體裝置。這些切換通常稱為 L4/7 切換 (第 4 層到第 7 層),因為它們根據網路層資訊 (TCP) 或甚至應用程式層資訊 (HTTP) 提供封包交換。這些層中可用的資訊可以提供更複雜的負載平衡,依照 IP 來源/目的、URL、內容類型等等。因為它們實作為硬體器具,因此處理量相對很高,而且高度可用而可靠,但十分昂貴。大多數切換可以啟用容錯,偵測伺服器停機的狀況。
  • 使用 DNS 遞迴名稱解析,伺服器叢集可以在 DNS 中被指定相同的名稱。DNS 會循環整個清單,回應該名稱的查詢。這個解決方案並不昂貴 (事實上是免費的),但有很多缺點。一個主要的問題是負載並不需要平均分布在叢集中的伺服器之間。另一個問題是沒有提供容錯。
  • 使用 Windows 網路負載平衡。網路負載平衡 (Network Load Balancing) 的原理是和叢集中所有的伺服器共用 IP 位址,每個傳送到這個 IP 的封包都由所有的伺服器檢視。然而,依照某個共用的雜湊函式,每個封包僅由其中一個伺服器處理。網路負載平衡在作業系統層級實作。提供平均分布的負載平衡,並支援容錯 (叢集中的其他伺服器可以偵測到發生故障的伺服器,並在它們之間分散其負載)。但是它需要一些 CPU 處理負荷 (大約為通用 ISA Server 案例的百分之 10 到 15),而且會限制叢集中的成員數目 (建議的最大值約為 12 台機器)。網路負載平衡僅在 Windows Advanced Server 上提供。
  • 對於快取案例,ISA Server 支援快取陣列通訊協定 (CARP),這是一個快取負載平衡通訊協定。它不僅在伺服器之間分散負載,也分散快取的內容。每個要求都送到叢集中的特定機器,因此後續的點擊可以由該機器處理。CARP 僅在 ISA Server Enterprise Edition 中提供。

升級和擴充

調整是為了增加系統的容量。每個調整方法都有自己的優缺點,對 ISA Server 來說也要依照案例。決定要使用的調整方法時,應該要納入下面的考量:

  • 效能係數:加入另一個處理器/機器後,可以增加多少處理量?
  • 系統成本:指購買系統最開始的成本,不可和「擁有成本」混淆。
  • 系統管理:指管理系統的複雜程度。這和系統的擁有成本有直接的關係。
  • 容錯:是系統用來啟用高可用性和可靠度的方法。
  • 系統升級:是用來增加系統處理能力的方法。升級成本也是重要的考量。

下面列出判斷要使用升級還是擴充時要考慮的幾個得失因素。

  1. 效能

    單一多處理器機器的調整係數一般低於機器叢集的調整係數。這意味著單一機器或許比數個處理裝置更好,但到了某個規模上就無法提供大多數叢集的高調整係數所能提供的效能增加。

  2. 系統成本和擁有成本

    一般而言,單一機器就算有很多處理器,和數台電腦的叢集比較來,更容易組態和維護。另一方面,多處理器的電腦比單一處理器的電腦貴得多 (一般而言,就算以處理器為單位還是比較貴)。

  3. 單點失敗和容錯

    單一機器部署的可用性比多機器叢集更容易受到硬體失敗的影響。系統主機板或磁碟控制器的失敗將導致整個系統當機,需要修理。對硬體負載平衡解決方案來說也是如此。

  4. 升級

    如果在機器中有空的處理器插槽 (或硬體負載平衡切換中有可用的連接埠),升級單一機器解決方案就非常簡單容易。空間都填滿後,必須更換整個盒子,升級費用就很昂貴。在多機器叢集中,加入另一台機器就比較複雜,但平均購買費用則便宜得多。

下表摘要說明上述內容。

表 2   ISA Server 調整選項

 升級擴充   
  L4/7 切換DNS網路負載平衡CARP
效能 (調整係數)1.6 – 1.7,取決於機器架構 (更大的 L2 快取會增加調整係數) 221.8 (叢集中的 1-8 台機器) 從 1.5 開始,並漸進到達 2
系統成本MP 機器成本較高,特別是 4P 以上的2。非常昂貴 $15,000-$100,000每台機器都需要 Windows 2000 Advanced Server需要 ISA Server Enterprise Edition (EE)
系統管理單一機器管理需要數台機器上的管理,加上額外的切換管理數台機器的管理和 ISA Server 集中式陣列管理 (EE)數台機器的管理和 ISA Server 集中式陣列管理 (EE)數台機器的管理和 ISA Server 集中式陣列管理 (EE)
容錯原生硬體 切換偵測到發生故障的機器並載入其他機器故障機器的相互偵測故障機器的相互偵測
系統升級加入另一個處理器:必須有可用的空插槽加入另一台機器:需要空連接埠和切換上有額外的頻寬加入另一台機器和加入項目到 DNS加入另一台機器:請注意太多可能會降低調整係數 加入另一台機器:幾乎是無限制的規模。
案例全部 全部 全部 全部僅轉送快取

微調 ISA Server 資源

容量規劃的第一步是判斷需要滿足效能需求的電腦系統類型。系統組態並開始執行後,下一步是讓系統發揮最高的效能。對於 ISA Server 而言,這意味著設計合適的硬體資源讓系統完全利用 CPU 能力 (單一入門級 ISA Server 電腦策略是這個概念的一個例外,因為網際網路頻寬比最慢的 CPU 可以填滿的還要低很多)。下一節詳細說明這個概念。

大型企業規模部署需要的進階主題包括微調資源、微調案例和微調功能。對大多數單一入門級電腦部署來說,不需要微調 ISA Server 以促進效能。

最大化 CPU 使用的系統設計

ISA Server 容量取決於 CPU、網路、磁碟和記憶體硬體資源。每個資源都有容量限制,雖然所有的資源消耗程度都在限制以下,系統整體的功能十分正常,符合效能目標。達到其中一個限制時效能會顯著下降,導致瓶頸。在這種情況下,就稱系統被限制在該資源上。在整體系統效能中每個瓶頸都有自己的症狀,可以協助偵測出容量不足的資源。這個短缺需要增加失敗資源的容量。

每種資源都有自己的價格,在今日的電腦市場中,CPU 是電腦最昂貴的資源。因此,也是最後才要增加的資源。這個邏輯解釋了為什麼需要設計出一個最大化 CPU 使用的系統:在達到完全的 CPU 使用前確定系統將沒有效能瓶頸。換句話說,如果 CPU 的能力足以承受預期的負載,就不會出現瓶頸。為了達到這個目的,所有其他資源都必須有適當的容量。下面各節說明如何設計最大化 CPU 的系統以在每個資源中都有適當的容量、如何監視每個資源,以及如何疑難排解每個資源中的瓶頸。

判斷 CPU 容量

就像大多數伺服器應用程式滿足無數的用戶端請求,ISA Server 效能也獲益於更大的處理器快取、更高的 CPU 速度和改善的處理器架構。這裡的方針針對判斷 ISA Server 系統應使用的 CPU (按照它們對效能的影響排序):

  1. L2/L3 快取大小。處理大量資料需要經常存取記憶體。L2/L3 快取會改善大型記憶體提取的效能。
  2. CPU 速度。和在大多數應用程式中相同,ISA Server 獲益於更快的 CPU。然而,增加 CPU 速度並不確保效能的線性增加。由於大量和頻繁記憶體存取的影響,等待 CPU 循環時,增加 CPU 速度可能會導致更多浪費的閒置記憶體。從 Intel 733-MHz Pentium III 增加到 933-MHz 處理器時就實際觀察到這個現象。
  3. 改善的架構。和在其他大多數應用程式中相同,ISA Server 獲益於改善架構的 CPU。Intel Pentium 4 系統提供的效能比 Pentium III 更好。ISA Server 容量測試顯示,比較 1.7-GHz Pentium 4 處理器和 733-MHz Pentium III 處理器時,防火牆測試改善了百分之 20,而快取測試改善了百分之 45。

CPU 瓶頸的特徵是 \Processor\% Processor Time 效能計數器數字很高,而網路介面卡和磁碟 I/O 仍保持低於容量的情況。在這種情況下 (也就是理想的 CPU 最大化系統),達到百分之 100 意味著必須升級 CPU。除了之前單一 CPU 的升級方針外,也可能使用更多 CPU 增加能力。在<升級和擴充>一節中討論了 CPU 調整選項。如果 ISA Server 似乎卡在更高的回應次數,但 CPU 百分比很低,瓶頸應該發生在別處。

判斷網路容量

連線上每個網路週邊設備都有自己的容量限制。這些包括了用戶端和伺服器 NIC,以及互相連接它們的路由器、切換和集線器。適當的網路容量意味著這些網路裝置都沒有達到飽和。確保所有網路裝置上的實際負載都低於最大容量就需要監視網路活動。

適當的網路容量是工作負載參數的函式。例如,請考慮轉送快取,在 100 Mbps 的快速乙太網路連結上將用戶端連接到 ISA Server。使用到百分之 75 (尖峰網路使用的建議值),這個連結要求每秒 1,200 個 HTTP 回應的要求速率,平均大小為 8 KB,這是依照:

Dd548175.ISPRFP03(zh-tw,TechNet.10).gif


如果在尖峰負載時平均要求速率為每分鐘每個使用者 6 個要求,那麼每秒總共 1,200 個 HTTP 要求要應付 12,000 個使用者的要求:

isprfp04

之前的結果是平均回應大小 (8 KB) 和平均使用者要求速率 (每分鐘 6 個要求) 的函式,會依不同的工作負載而變化。

在轉送快取案例中到網際網路的網路連結通常比較低,但還好只有一部分的回應流量會經過這條線傳輸。例如,如果命中率是百分之 40,那麼前例中的 12,000 個同時使用者建立的處理量為:

Dd548175.ISPRFP05(zh-tw,TechNet.10).gif


在百分之 75 的網路容量傳輸 45 Mbps 時,網際網路連結實際頻寬的建議值為 60 Mbps。在大多數情況下,網際網路連結頻寬是實際值,因為這是一種昂貴的資源,組織一定會有效率地使用。在前例中,使用百分之 75 尖峰處理量的 T3 連結 (45 Mbps) 會帶來每秒 900 個要求的尖峰要求率:

isprfp06

監視網路活動可用效能計數器 \Network Interface\Bytes Total/sec 來達成。如果其值超過網路卡最大頻寬的百分之 75,您將需要考慮增加網際網路連結頻寬。

判斷磁碟容量

磁碟效能由數個因素決定:案例、命中率、尖峰要求率和工作集大小。

磁碟容量和防火牆案例無關 (它們僅將磁碟用於小型記錄活動)。對於快取,轉送和反向的工作負載係數不同,建立出完全不同的快取微調原則。

微調轉送快取的磁碟

在轉送快取中,使用命中率和尖峰要求率來判斷需要的磁碟數目。例如,如果 ISA Server 電腦使用 15,000 RPM 磁碟機 (每秒 150 次 I/O),那就需要 3 個磁碟來支援尖峰負載的每秒 900 個要求,命中率為百分之 40,這是依照:

Dd548175.ISPRFP07(zh-tw,TechNet.10).gif


建議使用相同類型和同等容量的磁碟,不要將磁碟用於其他用途。如果使用 RAID 存放子系統,將其組態為 RAID-0 (沒有容錯)。如果您要儲存磁碟,並將一個磁碟用於兩個系統檔案和 ISA Server 快取,您可以這麼做,但是系統上不可執行其他重度使用磁碟資源的應用程式。

決定磁碟數目後,可以微調磁碟快取的總數以取得最高的可能命中率。可依照下面的程序進行這件工作:

  1. 從大約是總 (已格式化) 磁碟空間百分之 50 的快取大小開始。在每個磁碟上設定相等的快取大小。
  2. 在尖峰負載時間監視命中率。
  3. 用某個係數增加磁碟容量。如果命中率很低,選擇更大的係數 (百分之 50),如果不高,選擇百分之 20。
  4. 再度監視命中率 (確定在第二天進行)。如果大幅增加 (不只是幾個百分比),回到步驟 3。不然就算完成了,您的命中率會逐漸接近真正的命中率。

微調反向快取的磁碟

在反向快取中,工作集大小和轉送快取工作集大小比起來非常小,因此嘗試將它整個放到記憶體中時才有意義。然而,ISA Server 用和在轉送快取案例中相同的方式使用磁碟快取,但如果記憶體快取夠大,能夠保留整個工作集,希望只將磁碟快取物件讀取一次到記憶體中。

工作集的大小是快取裝載的網站中可快取物件的總量。磁碟快取的大小建議是工作集的兩倍以保留所有可快取的物件,並佔用磁碟配置和快取重新整理原則中的片段3。對於 1 GB 大小的工作集,2 GB 的磁碟快取就夠了。

因為大多數的快取提取都來自記憶體快取 (如果夠大的話,請參閱下一節<判斷記憶體容量>中說明如何微調記憶體快取容量),磁碟讀取率很小。在大多數情況下,單一磁碟就足夠服務這些提取,不會變成瓶頸。

判斷記憶體容量

ISA Server 記憶體用於:

  • 存放網路通訊端 (大多數來自未分頁集區)
  • 內部資料結構
  • 擱置的要求物件
  • 磁碟快取目錄結構
  • 記憶體快取

(最後兩個僅適用於快取案例)

微調防火牆記憶體

在防火牆案例中,限制記憶體係數是未分頁集區的大小,為總記憶體大小的函式。根據 Microsoft 知識庫 (Microsoft Knowledge Base) 文件 Q126402,未分頁集區大小的最小值和最大值為:

表 3   根據實體記憶體大小的最小和最大未分頁集區值

實體記憶體 (MB)128256512102420484096
最小未分頁集區值 48163264128
最大未分頁集區值50100200256256256

測試顯示入門級機器需要 256 MB 就夠了,高階機器則需要 1024 MB。這些量也將可以存放完整的工作集容量。

微調快取記憶體

在快取案例中,記憶體用於:

  1. 擱置的要求物件。擱置的要求物件數目事實上是到 ISA Server 的連線數目,每個連線都需要約 15 KB。因此對於 10,240 個連線,Web Proxy 記憶體工作集有 10,000 x 15 KB = ~150 MB 配置給擱置的要求物件。
  2. 為每個快取的物件包含 32 個位元組的快取目錄。快取目錄的大小直接由快取大小和平均回應大小決定。例如,保存 5,000,000 個物件 (每個 10 KB) 的 50 GB 快取需要 32 x 5,000,000 = 153 MB。
  3. 記憶體快取。記憶體快取的目的是直接從記憶體服務常見的快取物件,降低提取磁碟快取的次數。記憶體快取的影響在轉送和反向快取之間非常不同。在反向快取中,ISA Server 裝載資料量有限的網站。在這種情況下,就可以將所有可快取的內容載入記憶體快取,完全消除存取磁碟的需要,因為這會對效能造成劇烈的影響。在轉送快取中,可快取的內容幾乎沒有限制,因為不管記憶體快取有多大,總會有可觀比例的點擊將從磁碟快取服務。因此,在轉送快取中,記憶體快取大小對效能的影響有限。

在預設情況下,記憶體快取是實體記憶體總大小的百分之 50,而且可以組態。微調記憶體快取大小是一個反覆實驗的過程。首先,必須要夠大,以最大化來自記憶體的點擊 (效能計數器 \ISA Server 快取\記憶體使用率百分比 (%) 測量記憶體提取和總記憶體提取之間的比率)。然而,配置太多記憶體給 ISA Server 記憶體可能會導致不想要的硬體分頁錯誤,因為沒有留下足夠的實體記憶體來保留全部剩下的部份。

硬體分頁錯誤會導致嚴重的效能降低。加入更多記憶體或減少記憶體快取的大小就可以解決這個狀況。

考慮到之前的資訊,建議使用下面的微調快取記憶體大小處理序:

  1. 微調磁碟快取大小 (判斷磁碟容量)。
  2. 預估需要的記憶體為下列各項的加總:
    1. 擱置的要求物件 (15 KB * 尖峰時間建立的連線)。
    2. 快取目錄大小 (32 * 快取中的 URL)。
    3. 記憶體快取大小,應該設為工作集大小的一倍到兩倍,以備反向快取。在轉送快取中,將記憶體快取設為儘可能最大的大小,但不造成硬體分頁錯誤。判斷新 ISA Server 系統需要的記憶體時,將實體記憶體的百分之 10 到 50 保留給記憶體快取。
    4. 系統記憶體每個連線將需要約 2 KB,加上額外的 50 MB 用於啟動 (50 MB + 2 KB * 尖峰時間建立的連線)。
    5. 至少 100 MB 給其他在系統中執行的處理序。
  3. 在步驟 2 中,將記憶體快取設定為計算出總記憶體的預估百分比。如果硬體系統的記憶體超過步驟 2 中所需的,就可以再度增加記憶體快取的百分比。目的在於在尖峰時間使用所有的實體記憶體,不執行硬體分頁錯誤。
  4. 據此監視記憶體使用和變更記憶體快取大小。資訊效能計數器為:
    
    \ISA Server Cache\Memory Cache Allocated Space (KB)
    \ISA Server Cache\Memory URL Retrieve Rate (URL/sec)
    \ISA Server Cache\Memory Usage Ratio Percent (%)
    \ISA Server Cache\URLs in Cache
    \Memory\Pages/sec
    \Memory\Pool Nonpaged Bytes
    \Memory\Pool Paged Bytes
    \Process(W3PROXY)\Working Set
    \TCP\Established Connections
    
    

和之前解釋的一樣,記憶體未正確微調最重要的證據是當 \Memory\Pages/sec 在尖峰負載時很大 (超過 10)。如果發生這種情況,要做的第一件事是降低記憶體快取大小,然後判斷是否需要更多的記憶體。

使用 /3 GB boot.ini 參數

對於記憶體超過 2 GB 的大型系統,Windows 2000 Advanced Server 提供 3 GT RAM 微調功能,將處理序記憶體空間分出 3 GB 給應用程式記憶體,1 GB 給系統記憶體。這個功能讓處理序可以獲益於超過 2 GB RAM 的使用者空間,啟用方式是將參數 /3GB 加入 boot.ini 檔案 (如需詳細資訊,請參閱 Microsoft 知識庫 (Microsoft Knowledge Base) 文章 171793)。

這個功能對 ISA Server 也有益處,特別是裝載大型網站的反向快取 (例如有大型工作集者)。然而,使用這個功能會降低未分頁集區的最大大小 (128 MB,而不是 256 MB),因而影響同時 TCP 連線的最大數目。

微調 ISA Server 案例

本節說明案例專有的效能微調方面。

微調防火牆案例

所有防火牆案例中主要的效能提升器是核心模式資料激發 (KMDP)。KMDP 的啟用方式是選取 [IP routing] (依預設為停用)。然而,啟用 KMDP 不保證將其用於所有的通訊協定。此外,為某些通訊協定啟用 KMDP 不保證可以為使用者模式資料激發帶來合乎預期的效能提升。為了讓 KMDP 發揮最大的效能,建議將之為工作負載中需要最大容量的通訊協定啟用。

這裡舉出目前所通行需要最大容量的通訊協定範例:

  • HTTP:HTTP 是使用最廣泛的通訊協定,佔百分之 70 到 80 的網際網路流量。由於 HTTP 為單一通道通訊協定,其中資料和控制項標頭通過相同的 TCP 連線,KMDP 用於 HTTP 的時機僅有:
    1. 輸出防火牆用戶端 (也稱為 Remote WinSock 或簡寫成 RWS ),以及
    2. 如果沒有應用程式篩選器連接到 HTTP 連接埠 (這需要停用預設為已啟用的 HTTP 重新導向篩選器)。也建議停用 HTTP 重新導向篩選器,以便改善快取效能,因為這會停用通透式快取 (關於微調轉送快取效能,請參閱下一節)。
  • FTP:FTP 常用於大型檔案傳輸。在 ISA Server 中,如果啟用了 IP 路由,FTP 應用程式篩選器 (依預設已啟用) 資料通道總是使用 KMDP。
  • 資料流媒體 :傳輸音訊和視訊的通訊協定集合。ISA Server 內建的資料流媒體應用程式篩選器支援 MMS (Microsoft Media Streaming)、PNM (Real Media 的 Progressive Network Media) 和 RTSP (Real Time Streaming Protocol –網際網路標準)。所有這些通訊協定都使用 UDP 上的次要資料通道 (或 TCP,用於不良傳輸線上的失敗替換),因此可以使用 KMDP。

    下表摘要說明所有傳輸/用戶端/篩選器組態中 ISA Server 的效能測試結果。

    表 4   ISA Server 資料流媒體處理量

    Dd548175.ISPRFP08(zh-tw,TechNet.10).gif


    根據此表格,KMDP 提供的效能優於 UMDP,但利用 KMDP 的組態比較少使用。UDP 是伺服器和用戶端的偏好傳輸方法,但需要資料流媒體應用程式篩選器在作用中,這會導致大多數其他案例 (TCP、RWS) 和 UMDP 一起執行。一個不錯的例外狀況是 HTTP 上的資料流媒體資料,可以在 KMDP 中執行以用於 RWS 用戶端 (請參閱前面有關 HTTP 的解釋)。

所有其他通訊協定,雖然有些很受歡迎 (例如郵件通訊協定、DNS、ICMP 等等),和表格中的通訊協定比起來容量都很低,因此改善它們的效能並沒有顯著的影響。

微調快取案例

轉送和反向快取有不同的工作負載,使用的原因也不同。因此,效能微調考量也就彼此差異,如下面各節的解釋。

微調轉送快取

轉送快取用於減少回應時間和降低網際網路連線的頻寬 (實際上這是降低網路存取成本並改善服務品質的目的)。因此,轉送快取最終的效能目標在於最大化命中率。幸運的是,這個目標和 ISA Server 設計相符,其中點擊 (從快取服務) 成本低於 (就整體資源利用而言) 遺漏 (從網路服務)。

根據這個原理闡述,要得到最大的效能益處,要做的事就是留出足夠的磁碟存放來最大化命中率 4 (如需詳細資訊,請參閱<判斷磁碟容量>一節)。判斷磁碟快取組態同時包括總大小 (對於最大化命中率) 和磁碟數目 (以確認每個磁碟的點擊數目不超過磁碟可以處理的最大 I/O 率)。

一旦決定了磁碟組態,下一步就是定義記憶體快取的大小。在預設情況下,ISA Server 設定記憶體快取為總實體記憶體的百分之 50。這個值足以應付大部份的情況、在某些情況中會有危險,在其他一些情況中可能根本無用。如需詳細資訊,請參閱<判斷記憶體容量>。

快取效能的一個重要提示:如果您的系統不繫結到網際網路網路頻寬上 (請參閱<單一入門級 ISA Server 電腦>),而且 ISA Server 系統的設計根據<最大化 CPU 使用的系統設計>,那麼強烈建議組態使用者瀏覽器以使用企業 Web Proxy (ISA Server) 來使用外顯 Proxy 快取。在 Microsoft Internet Explorer 5 和更新版本中,Web Proxy 可以手動或自動由企業原則設定。如需達成這個目標的詳細資料,請參閱 Advantages of Using MS Internet Explorer 5 in Your Business (在企業中使用 MS Internet Explorer 5 的優點)。

微調 Web 發佈

Web 發佈 (反向快取) 是用來減少 Web 存取回應的時間,並降低後端 Web 伺服器的卸載 (改善服務品質同時降低 CPU 成本)。和在轉送快取中一樣,這意味著最大化命中率。但這裡的基本差異是工作集小得多,在大多數情況下可以包含在實體記憶體中。

因此,在這個情況下,最初的重點是「判斷記憶體容量」。磁碟容量並非關鍵,因為即使大型網站也可以在數 GB 大的單一磁碟上保存所有的靜態資料。

另一件要考慮的事是連線到內部網路的網路卡頻寬。雖然連入連線頻寬可能很大 (因為要服務網際網路),內部頻寬可能會很小。這是因為一般命中率在百分之 80 到 90 的範圍內,意味只有百分之 10 到 20 的回應流量從後端 Web 伺服器處理5。這都表示內部網路卡可以有更小的最大頻寬,就可能降低網路基礎結構的成本。

微調 ISA Server 功能

微調用戶端

微調用戶端對 ISA Server 效能有最大的影響。

遵循這些改善效能的方針:

  • 輸出防火牆可以獲益於 RWS 防火牆用戶端 (和 SecureNAT 用戶端相比較),特別是高流量的通訊協定,例如 HTTP、FTP 和資料流媒體 (預期 KMDP 可以增加兩三倍的效能)。
  • 轉送快取比通透式快取快得多。這是因為前者的用戶端用外顯方式連接到 ISA Server,提供更高的連線保持活動率,也會降低同時連線的總數。因此,建議讓所有的內部 Web 瀏覽器直接和 ISA Server 互動 (方法是根據整個企業的原則組態中央瀏覽器安裝,或使用網際網路瀏覽器中的網際網路自動設定偵測)。
  • 在這些情況下,ISA Server 上資料流媒體用戶端的負載將比較低:
    1. 如果啟用資料流媒體篩選器,將播放程式設定為把 HTTP 上的媒體用於有 RWS 的用戶端,或將 UDP 用於 SecureNAT 用戶端。
    2. 如果停用資料流媒體,將只有 RWS 用戶端能夠播放媒體,這時最好要組態 TCP 傳輸上的媒體。

微調原則

微調 ISA Server 原則的效能方針為:

  • 最小化規則的數目 (因為規則處理會以線性方式和規則數目一起成長)。例如,使用指定大型目的集的單一規則比為每個目的使用一個規則有效率。
  • 偏好允許規則多於拒絕規則 (因為所有的拒絕規則都會在允許規則前檢查,找到第一個可用的允許規則時就會終止規則檢查)。
  • 建立連線時會評估防火牆原則,因此和在連線上傳輸的資料有微不足道的負荷關係。快取原則會在每個要求上評估,因此其負荷比起防火牆原則評估要大得多。
  • 避免可能的 DNS 查詢問題。確認目的集中所有的目的地名稱都可以解析,有可能的話也設定附近的 DNS。

微調驗證

對於調整驗證效能,要考慮下列問題:

  • 防火牆驗證僅和 RWS 有關,此時的負荷微不足道,因為會在每個工作階段檢查一次 (在工作階段中連線會開啟,並傳輸更多的封包)。
  • 快取驗證的檢查次數更頻繁,重新驗證率則取決於使用的驗證配置。驗證配置也會決定套用驗證時執行的實際處理量。下表指出可能性。

表 5   ISA Server 驗證效能

驗證配置強度執行驗證的時機 每次要求的負荷每批次的負荷
基本每次要求none
摘要每次/計數none
NTLM每個連線none
Kerberos每個連線none

  • 關於快取驗證效能要記住的另一件事是,它可以在 Web Proxy 接聽項層級上組態 (方法是在陣列內容的 [Outgoing/Incoming Web Requests] 上選取 [Ask unauthenticated users for identification]),或在規則層級上。如果所有 Web 存取都需要驗證,才選擇前者,不然請選擇第二個 (這實際上意味著,依照規則,將只在有需要時執行驗證)。

微調篩選器

篩選器使用額外的 CPU 循環,因此它們對效能有直接影響。在極端的情況中,篩選器可能需要更多資源,讓 ISA Server 的效能和在沒有篩選器時的效能完全不同。因此,建議要:

  • 衡量所使用篩選器的效能,將它們儘可能微調成最有效率的狀態。在可用的情況下,考慮使用 ISA Server 規則,而不是篩選器 (例如,使用存取規則目的集的網站封鎖可能證明比進行相同工作的 ISAPI 篩選器更有效率)。
  • 如果您開發了篩選器,將之最佳化以求最好的效能。對任何軟體來說都是如此,特別是任務中最關鍵的防火牆/Proxy 伺服器。
  • 嘗試避免將應用程式篩選器加入使用 KMDP (但沒有應用程式篩選器) 的通訊協定而造成降級 (例如,嘗試將次要資料通道保留在 KMDP 中)。

微調加密

對於防火牆,微調加密選項就等於微調 Windows VPN。如需關於 VPN 效能的資訊,請參閱<Windows 2000 VPN: Enterprise Performance with Server-Based Flexibility>報告。

對於快取案例,SSL (也稱為 HTTPS) 在轉送快取和 Web 發佈中的用法不同。在 Web 發佈中,ISA Server 擔任 SSL 終端機的功能,也就是它會執行 SSL 信號交換和用戶端加密,對後端伺服器也能進行同樣的工作。

在轉送快取中,ISA Server 只是一個通道,將封包從某一端移到另一端,不涉及加密/信號交換。因此,通道效能可以比得上處理從網際網路提取的未加密資料。

若要在 ISA Server 上 Web 發佈中微調 SSL,遵循這些方針:

  • HTTPS 連線的加密和傳輸相同資料的 HTTP 連線相比,需要約兩倍的 CPU 能力。建立 HTTPS 連線和建立 HTTP 連線相比,需要強度更為卓越的 CPU 能力。SSL 加速硬體的文獻和廣告報告 2 到 10 次效能改善,比較對象是軟體 PKI 實作。這會如何映像您的工作負載?這高度取決於每個連線傳輸的要求數目 (這個秘訣只適用於 Web 發佈)。
  • 反向快取中的 SSL 會加密和節目資料,就像真實網站中的 SSL 一樣。在 ISA Server 中,SSL 連線有兩個可能:
    1. 單向 SSL:用戶端和 ISA Server 使用 SSL 通訊,但 ISA Server 和後端 Web 伺服器使用一般 HTTP 通訊。
    2. 雙向 SSL:兩個通訊通道都使用 SSL,意味著 ISA Server 將解密來自後端網站的回應,並再度加密以傳送回應給用戶端 (使用不同的加密識別碼)。

    雙向 SSL 為每個要求執行的處理量是單向 SSL 執行的兩倍,因此雙向 SSL 的 CPU 使用也是單向 SSL 的兩倍。

    因此:

    • 如果有需要才使用雙向 SSL。請記住,ISA Server 和後端 Web 伺服器之間的第二個 SSL 通道會保全內部受保護網路上的通訊。
    • 請勿將所有 SSL 內容限制為不可快取。HTTPS 資料流就和 HTTP 一樣,包含很多可以在私用網頁中共用為點擊的物件 (影像、圖示等等)。如果通過 HTTPS 連線的公用資料變成可快取的,雙向 SSL 和單向 SSL 的負荷相比將只有少許的效能衝擊,因為這只會影響佔總流量小部份的快取遺漏。
    • 轉送快取案例中的 SSL 是通道通訊協定。因此不會快取內容。這會增加網際網路處理量 (和非加密傳輸相比的結果),但打開 SSL 通訊協定通道的處理負荷則遠遠小於解密資料。

瞭解工作負載

本節說明在有需要時 (大型企業和發佈策略) 瞭解工作負載的方法。一般來說,有兩個方法,取決於 ISA Server 是部署為現有系統的替換或附加元件,或是為新系統部署。在第一種情況下,現有系統可以提供有價值的資訊來源,例如 Web 和防火牆記錄,和估計工作負載的效能計數器。在第二種情況下,瞭解工作負載可能是一件困難的工作,或許需要建立和執行縮減 (scaled-down) 的原型。

從現有記錄和效能計數器學習

記錄提供計算工作負載參數的最佳可能來源。Web 快取伺服器通常會為每個 Web 交易記錄一個項目、詳細記載用戶端和伺服器名稱、IP、要求的 URL、回應大小、時間和狀態、回應是從快取還是從網際網路服務等等。防火牆也為連線進行相同的工作,並記錄每個連線的目的連接埠,就是實際上使用的通訊協定。

有些參數很容易計算:例如,平均回應大小、平均回應時間、命中率、可快取率和通訊協定分布。其他的比較難計算,這裡有幾個範例:

  • 工作集大小 (轉送快取):查看所有從快取服務的要求,並計算每個 URL 的點擊次數。用遞減歡迎度排序 URL 將建立出類似 Zipf 的分散,有顯著的中斷點,其左邊少數幾個 URL 有很多點擊數,右邊的很多 URL 則有很少的點擊數 (計劃分散提供找到中斷點的良好觀察點)。工作集大小是所有在中斷點左邊常用物件的累積大小。

    下圖是一個範例 (取自 2001 年 7 月 Microsoft Corporate Proxy 記錄之一):

    Dd548175.ISPRFP09(zh-tw,TechNet.10).gif


    這個範例顯示工作集在連續兩天內的行為模式。第一天工作集約有 4GB,第二天只有 3.3 GB (中斷點在 150,000 URL)。

  • 每個連線的要求數 (防火牆案例中的輸出 HTTP):請查看 Web 記錄,並數算每個用戶端和伺服器對之間的要求數。使用每個要求的時間,就可以判斷兩個連續要求之間經過的時間。因為 IE 會在連線閒置一分鐘後將之關閉,超過一分鐘的時間差異指出在其間已重新建立連線。時間差異小於一分鐘的連續要求則可能在相同的連線上傳送。此外,IE 會在每個目標上開啟兩個連線,因此每個連線的平均要求數為一分鐘閒置時間內的平均連線數除以二。

因為一天內網際網路的使用會有變化,在一週內一定要查看數個記錄,而且最好在一般的工作日時。

另一個不錯的資訊來源是即時監視計數器 (在 Windows 系統上也稱為效能計數器)。現有防火牆和快取伺服器通常會提供直接衡量相關事件的有用計數器。

從原型學習

也有要為尚未存在的系統部署 ISA Server 的案例。大多數這些案例屬於發佈策略類別,規劃要在將來提供新網站或新的 Web 服務。本文件的範圍是簡短說明模擬和塑造網站效能的可能性。如需 Web 容量規劃的其他資訊,請參閱
https://www.microsoft.com/technet/itsolutions/ecommerce/
maintain/optimize/capplan.mspx

參考和其他資訊

用於本文的市場調查報告為:Internet Connectivity Services: A Demand-Side View, 2001,報告編號 26023,作者:Steven T. Harris,2001 年 12 月 IDC。

Microsoft 將繼續和客戶分享資訊,希望能協助您更成功地部署和管理 ISA Server。

如需 ISA Server 的最新資訊,請造訪 http://www.microsoft.com/taiwan/isaserver/

如需其他 .NET Enterprise 伺服器的最新資訊,請造訪 http://www.microsoft.com/taiwan/net/

如需 Windows 2000 Professional 和 Windows 2000 Advanced Server 的最新資訊,請造訪 http://www.microsoft.com/taiwan/products/windows/

如需 Microsoft 產品關於 Microsoft 知識庫 (Microsoft Knowledge Base) 的支援資訊和自助工具,請造訪 http://support.microsoft.com/default.aspx?scid=fh;zh-tw;KBHOWTO

本文件中所包含的資訊代表 Microsoft Corporation 於發行日前針對該問題的觀點。由於 Microsoft 必須反應市場條件的變更,因此不應解釋為 Microsoft 的承諾。在發行日之後,Microsoft 不保證文件中任何資訊的正確性。

此白皮書僅供參考使用。Microsoft 對於本文件中各項資訊,不作任何明示或默示的保證。

使用者必須遵守所有適用的版權法律規定。即使沒有版權限制,在未取得 Microsoft Corporation 書面許可的情況下,不得任意複製本文件任一部份、將文件存放或導入擷取系統,或者透過任何方式或手段 (電子、機械、影印、記錄等等) 傳輸本文件。

本文件中可能述及 Microsoft 的專利、專利應用程式、商標、版權或其他智慧財產權。除非取得 Microsoft 明確書面授權聲明,否則本文件並未授與這些專利、商標、版權或其他智慧財產的授權。

?2001 Microsoft Corporation.All rights reserved.

Microsoft、Active Directory、Outlook 和 Windows 是 Microsoft Corporation 在美國和/或其他國家的註冊商標或商標。

本文中所提到的真實公司和產品名稱,可能係其專屬公司的商標。

1 加倍處理器的數目來加倍應用程式可以處理的交易數目就是線性調整。在加倍處理器數目時應用程式可以處理的交易數目之間的真實比率稱為調整係數。因此線性調整系統的調整係數為 2。

2 在使用兩個處理器時,有兩類機器 – 以桌面類別處理器 (例如 Pentium) 為基礎的工作站,和以伺服器類別處理器 (例如 Xeon) 為基礎的伺服器。前者比較便宜,被視為高階入門級,後者則經過微調,以提供更高的效能/容量給伺服器應用程式。

3 重新整理快取的物件時,相同物件的新舊副本會消耗磁碟空間一段時間。快取物件舊版本消耗的空間會解除配置,但直到被其他物件重新使用後才會送回 (取決於平均重新整理率)。

4 事實上,要做的第一件事是確認有足夠的 CPU 能力和內部網路頻寬來保留尖峰要求率,否則回應時間將由於 CPU 或網路資源短缺而降低到無法接受的層級。

5 這要先假設點擊、遺漏和不可快取的回應大小分散大概是相同的。
 


顯示: