Active Directory Domain Services 的容量規劃

  • 發行項

本主題最初由 Microsoft 專案經理 Ken Brumfield 撰寫，提供 Active Directory Domain Services (AD DS) 容量規劃的相關建議。

容量規劃的目標

容量規劃與效能事件的疑難排解不同。 兩者關係密切，但大不相同。 容量規劃的目標是：

  • 正確實作及操作環境
  • 盡可能縮短效能問題的疑難排解所耗費的時間。

在容量規劃中，組織可能會設定尖峰時段的處理器使用率不超過 40% 的基準目標，以符合用戶端效能需求，並因應升級資料中心硬體所需的時間。 另一方面，為了接收異常效能事件的通知，監視警示閾值可能會設定為 90% (間隔為在 5 分鐘)。

差別在於，在持續超過容量管理閾值時 (一次性事件不列入考量)，新增容量 (也就是新增更多或更快的處理器) 或在多部伺服器間調整服務，將是解決方案。 效能警示閾值表示用戶端體驗當下正受到影響，需立即執行相關步驟來解決問題。

打個比方：容量管理是為了防止車禍 (防禦性駕駛、確保刹車正常運作等等)，而效能疑難排解則是警察、消防隊和緊急醫療人員在車禍發生後所做的工作。 本文討論的是 Active Directory 式的「防禦性駕駛」。

過去幾年來，擴大系統的容量規劃指引有很大的變化。 系統架構中的下列變更，使得關乎設計和調整服務的基本假設面臨挑戰：

  • 64 位元伺服器平台
  • 虛擬化
  • 日漸重視耗電量
  • SSD 儲存體
  • 雲端案例

此外，方法逐漸從以伺服器為基礎的容量規劃轉變為以服務為基礎的容量規劃。 Active Directory Domain Services (AD DS) 是許多 Microsoft 和第三方產品作為後端使用的成熟分散式服務，他們仰賴此一重大產品進行正確規劃，以確保其他應用程式執行所需的容量。

容量規劃指引的基準需求

本文具有下列基準需求：

  • 讀者已閱讀並熟悉 Windows Server 2012 R2 的效能微調指導方針。
  • Windows Server 平台是以 x64 為基礎的架構。 但是，即使您的 Active Directory 環境安裝於 Windows Server 2003 x86 (其支援週期現已結束)，且目錄資訊樹狀結構 (DIT) 的大小不到 1.5 GB，可輕易保留在記憶體中，本文中的指導方針仍適用。
  • 容量規劃是一個持續的過程，您應定期檢閱環境是否符合預期。
  • 隨著硬體成本的變更，最佳化會跨多個硬體生命週期持續進行。 例如，記憶體會變便宜、每個核心的成本會下降，或不同儲存體選項的價格會變更。
  • 規劃一天之中的尖峰時段。 建議您為此設置 30 分鐘或一小時的查看間隔。 設置的間隔太長，實際的尖峰可能不會呈現，間隔太短則可能會因為「暫時性尖峰」而失真。
  • 規劃企業在硬體生命週期各階段的成長。 這可能包括以交錯的方式升級或新增硬體的策略，或每三到五年進行一次全面更新。 無論如何，都需要「推測」Active Directory 上的負載會有何種程度的增長。 若收集了歷程記錄資料，將有助於進行這項評估。
  • 規劃容錯。 得出估計值 N 後，請規劃包含 N – 1、N – 2、N – x 的案例。

    • 根據組織的需求新增其他伺服器，以確保一或多部伺服器的損失不會超過最大尖峰容量估計值。

    • 同時請考量成長計劃與容錯計劃必須整合。 例如，如果需要一個 DC 來支援負載，但預估下一年的負載將會加倍，而總共需要兩個 DC，則將沒有足夠的容量可支援容錯。 解決方案的第一步是使用三個 DC。 如果預算吃緊，也可以規劃在 3 或 6 個月後再新增第三個 DC。

      注意

      新增 Active Directory 感知應用程式可能會對 DC 負載造成明顯影響，無論負載來自應用程式伺服器還是用戶端。

容量規劃週期的三步驟程序

在容量規劃中，請先決定需要何種服務品質。 例如，假設某個核心資料中心支援較高層級的並行，而需為使用者和取用應用程式提供更一致的體驗，因而需要更加關注備援性，並盡可能減少系統和基礎結構瓶頸。 相對而言，少數使用者的衛星站點就不需要相同層級的並行或容錯。 因此，衛星辦公室可能不需要那麼多關注來最佳化基礎硬體和基礎結構，而可能會節省成本。 此處的所有建議和指引都是針對最佳效能而提供的，且對於需求較低的案例，可以選擇性地放寬。

接下來的問題是：該選擇虛擬化還是實體？ 從容量規劃的觀點來看，答案沒有對錯；只有一組不同的變數需要處理。 虛擬化案例可選擇下列兩個選項之一：

  • 每個主機一個客體的「直接對應」(其中，只有從伺服器抽象化實體硬體的過程是虛擬化的)
  • 「共用主機」

在測試和生產案例中，可以將「直接對應」案例視同實體主機。 但「共用主機」則伴隨著諸多考量，稍後將詳細說明。 「共用主機」案例意味著 AD DS 也會競爭資源，因此有其相關的懲罰和微調考量。

基於這些考量，容量規劃週期將是反覆進行的三步驟程序：

  1. 測量現有的環境、判斷目前系統瓶頸的所在位置，並取得規劃所需容量不可或缺的環境基本資訊。
  2. 根據步驟 1 中列出的準則，判斷所需的硬體。
  3. 監視並驗證實作的基礎結構是否在規格內運作。 在此步驟中收集到的部分資料，將成為下一個容量規劃週期的基準。

運用程序

為達到最佳效能，請確定下列主要元件均正確選取，並依據應用程式負載進行調整：

  1. 記憶體
  2. 網路
  3. 儲存體
  4. 處理器
  5. Net Logon

AD DS 的基本儲存體需求和精心撰寫的用戶端軟體的正常運作，可讓具有多達 10,000 到 20,000 個使用者的環境無需大量投資於實體硬體方面的容量規劃，因為幾乎任何新式伺服器類別系統都能處理這些負載。 但您仍可參考下表的摘要說明，了解如何評估現有環境以選取正確硬體。 後續幾節會詳細分析各個元件，以協助 AD DS 管理員使用基準建議和環境特定準則來評估其基礎結構。

一般情況下︰

  • 任何以目前資料為準的大小調整，都僅適用於目前的環境。
  • 隨著硬體生命週期的推移，任何估計值應該都會需要增加。
  • 決定是要立即擴增大小並成長為較大的環境，還是隨著生命週期的推移新增容量。
  • 對於虛擬化，所有相同的容量規劃準則和方法都適用，但必須為任何與網域相關的項目新增虛擬化的額外負荷。
  • 容量規劃就像任何嘗試預測的事物一樣，不是準確的科學。 不要預期會有精確度 100% 的完美計算。 此處的指引是最精簡的建議：新增容量以進一步提高安全性，並持續驗證環境是否與目標保持一致。

資料收集摘要表

新環境

元件 估計值
儲存體/資料庫大小 每個使用者 40 KB 到 60 KB
RAM 資料庫大小
基本作業系統建議
第三方應用程式
網路 1 GB
CPU 每個核心 1000 個並行使用者

高階評估準則

元件 評估準則 規劃考量
儲存體/資料庫大小 儲存體限制中標題為「為透過磁碟重組釋放的磁碟空間啟用記錄」的小節
儲存體/資料庫效能
  • "LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read," "LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Write," "LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer"
  • "LogicalDisk(<NTDS Database Drive>)\Reads/sec," "LogicalDisk(<NTDS Database Drive>)\Writes/sec," "LogicalDisk(<NTDS Database Drive>)\Transfers/sec"
  • 儲存體有兩個問題有待解決
    • 可用空間；基於現今主軸型和 SSD 型儲存體的大小，這與大部分的 AD 環境無關。
    • 可用的輸入/輸出 (IO) 作業 – 這在許多環境中常被忽略。 但是，僅評估沒有足夠的 RAM 可將整個 NTDS 資料庫載入記憶體中的環境，則十分重要。
  • 儲存體可能是複雜的主題，且需要硬體廠商專業知識以適當調整大小。 在更複雜的案例中 (例如 SAN、NAS 和 iSCSI 案例) 尤為如此。 但一般而言，儲存體的每 GB 成本通常與每 IO 成本直接相反：
    • RAID 5 的每 GB 成本低於 RAID 1，但 RAID 1 的每 IO 成本較低
    • 主軸型硬碟的每 GB 成本較低，但 SSD 的每 IO 成本較低
  • 重新啟動電腦或 Active Directory Domain Services 服務之後，可延伸儲存引擎 (ESE) 快取會是空的，且在快取暖化期間，效能會受制於磁碟。
  • 在大部分的環境中，AD 是磁碟隨機模式的讀取密集 I/O，因此快取和讀取最佳化策略的許多優勢都無從發揮。 此外，AD 的記憶體快取遠大於多數的儲存體系統快取。
RAM
  • 資料庫大小
  • 基本作業系統建議
  • 第三方應用程式
  • 儲存體是電腦中最慢的元件。 可駐留在 RAM 中內容的越多，需要進入磁碟的就越少。
  • 請確定已配置足夠的 RAM 來儲存作業系統、代理程式 (防毒軟體、備份、監視)、NTDS 資料庫，以及一段時間的增長。
  • 若在環境中將 RAM 數量最大化不符合成本效益 (例如衛星位置) 或不可行 (DIT 太大)，請參考「儲存體」一節，以確定儲存體的大小適當。
網路
  • “Network Interface(*)\Bytes Received/sec”
  • “Network Interface(*)\Bytes Sent/sec”
  • 一般而言，從 DC 傳送的流量會遠超過傳送至 DC 的流量。
  • 由於交換的乙太網路連線是全雙工的，因此輸入和輸出網路流量必須單獨調整大小。
  • 合併 DC 數目將會增加用來將用戶端要求的回應傳送回每個 DC 的頻寬量，但對於整個網站來說，這足夠接近線性。
  • 如果移除衛星位置 DC，別忘了將衛星 DC 的頻寬新增至中樞 DC，並使用該頻寬來評估會有多少 WAN 流量。
CPU
  • “Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read”
  • “Process(lsass)\% Processor Time”
  • 將儲存體視為瓶頸排除後，請補足所需的計算能力。
  • 雖然不是完全線性，但特定範圍 (例如站台) 內所有伺服器使用的處理器核心數目，可用來測量支援用戶端負載總計所需的處理器數目。 新增在範圍內的所有系統間維護目前服務層級所需的最小值。
  • 處理器速度的變更 (包括電源管理相關變更) 會影響衍生自現行環境的數值。 一般而言，我們無法精確評估從 2.5 GHz 處理器轉換為 3 GHz 處理器將如何減少所需的 CPU 數目。
NetLogon
  • “Netlogon()\Semaphore Acquires”
  • “Netlogon()\Semaphore Timeouts”
  • “Netlogon(*)\Average Semaphore Hold Time”
  • Net Logon 安全通道/MaxConcurrentAPI 只會對使用 NTLM 驗證和/或 PAC 驗證的環境產生影響。 Windows Server 2008 之前的作業系統版本依預設會開啟 PAC 驗證。 這是用戶端設定，因此在所有用戶端系統上關閉此設定之前，DC 會受到影響。
  • 具有重大跨信任驗證的環境 (包括樹系內信任)，若未正確調整大小，會有更大的風險。
  • 伺服器合併會增加跨信任驗證的並行性。
  • 需要因應激增 (例如叢集容錯移轉)，因為使用者集體對新的叢集節點重新進行驗證。
  • 個別用戶端系統 (例如叢集) 也需要微調。

規劃

長期以來，社群對於調整 AD DS 大小的建議就是「根據資料庫大小來增加 RAM」。 在大多數情況下，這項建議就是多數環境都需要關注的一切。 但是，自 AD DS 在 1999 年推出以來，使用 AD DS 的生態系統已擴增不少，AD DS 環境本身也是如此。 雖然計算能力提升，並且從 x86 架構轉換為 x64 架構，效能調整的細微層面對於在實體硬體上執行 AD DS 的許多客戶而言已顯得無關緊要，但虛擬化的增長卻對給比之前更多的受眾重新帶來了微調問題。

因此，下列指引將說明如何判斷及規劃 Active Directory 即服務的需求，無論是部署在實體、虛擬/實體組合還是純虛擬化案例中。 因此，我們會將評估細分為四個主要元件：儲存體、記憶體、網路和處理器。 簡言之，為了讓 AD DS 達到最大效能，目標是要盡可能接近處理器限制。

RAM

簡單地說，可在 RAM 中快取內容的越多，需要進入磁碟的就越少。 若要將伺服器的可擴縮性最大化，RAM 的數量下限應為目前資料庫大小、SYSVOL 大小總計、作業系統建議數量，以及廠商的代理程式 (防毒軟體、監視、備份等) 建議的總和。 應新增額外的容量，以因應伺服器存留期內的成長。 根據針對環境變化所做的資料庫成長估計，這將會受到環境影響。

若在環境中將 RAM 數量最大化不符合成本效益 (例如衛星位置) 或不可行 (DIT 太大)，請參考「儲存體」一節，以確定儲存體已適當設定。

調整記憶體大小的必然結果，是調整分頁檔的大小。 在與其他涉及記憶體的相同內容中，目標是要盡可能避免進入速度較慢的磁碟。 因此，問題應從「應如何調整分頁檔大小？」 轉換到「需要多少 RAM 才能將分頁最小化？」 後一個問題的答案將在本節的其餘部分概略說明。 因此，有關調整分頁檔大小的多數討論都保留在常規作業系統建議的領域，以及需要為系統配置記憶體傾印 (與 AD DS 效能無關)。

正在評估

網域控制站 (DC) 所需的 RAM 數量實際上很複雜，原因如下：

  • 嘗試使用現有系統來測量需要多少 RAM 時很可能會發生錯誤，因為 LSASS 在記憶體壓力條件下會進行修剪，而不自然地減少需求。
  • 主觀事實是，個別 DC 只需快取其用戶端的「感興趣」的內容。 這表示，需要在只有 Exchange Server 的站台中的 DC 上快取的資料，與需要在僅驗證使用者的 DC 上快取的資料，有很大的不同。
  • 逐案評估每個 DC 的 RAM 讓人心力交瘁，且所需工作會隨著環境而不同。
  • 建議背後的準則將有助於做出明智的決策：
  • 可在 RAM 中快取內容的越多，需要進入磁碟的就越少。
  • 到目前為止，儲存體是電腦中最慢的元件。 存取主軸型和 SSD 儲存媒體上的資料，速度會比存取 RAM 中的資料慢 1,000,000 倍。

因此，若要將伺服器的可擴縮性最大化，RAM 的數量下限應為目前資料庫大小、SYSVOL 大小總計、作業系統建議數量，以及廠商的代理程式 (防毒軟體、監視、備份等) 建議的總和。 新增額外的容量，以因應伺服器存留期內的成長。 這將會基於資料庫成長估計而受到環境影響。 不過，對於使用者不多的衛星位置，這些需求可以放寬，因為這些網站不需要那麼多快取即可因應大部分的要求。

若在環境中將 RAM 數量最大化不符合成本效益 (例如衛星位置) 或不可行 (DIT 太大)，請參考「儲存體」一節，以確定儲存體的大小適當。

注意

調整大小記憶體時的必然結果，是調整分頁檔的大小。 由於目標是要盡可能避免進入速度較慢的磁碟，因此問題應從「應如何調整分頁檔大小？」 轉換到「需要多少 RAM 才能將分頁最小化？」 後一個問題的答案將在本節的其餘部分概略說明。 因此，有關調整分頁檔大小的多數討論都保留在常規作業系統建議的領域，以及需要為系統配置記憶體傾印 (與 AD DS 效能無關)。

RAM 的虛擬化考量

避免過度使用主機上的記憶體。 最佳化 RAM 數量背後的基本目標，是要盡可能縮短移至磁碟所耗費的時間。 在虛擬化案例中，配置給客體的 RAM 比實體機器上存在的還要多時，就會出現過度使用記憶體的狀況。 這本身並不是問題。 當所有客體主動使用的記憶體總計超過主機上的 RAM 數量，且基礎主機開始分頁時，這才會構成問題。 當網域控制站聯繫 NTDS.dit 以取得資料，或網域控制站聯繫分頁檔以取得資料，或主機聯繫磁碟以取得客體認為位於 RAM 中的資料，效能將會受到磁碟限制。

計算摘要範例

元件 估計記憶體 (範例)
基本作業系統建議的 RAM (Windows Server 2008) 2 GB
LSASS 內部工作 200 MB
監視代理程式 100 MB
防毒 100 MB
資料庫 (通用類別目錄) 8.5 GB
讓備份得以執行的緩衝，系統管理員可順利登入不受影響 1 GB
總數 12 GB

建議值：16 GB

經過一段時間後可以設想，資料庫中會新增更多資料，而伺服器可能會在 3 到 5 年內進入生產階段。 基於 33% 的成長估計值，16 GB 將是放入實體伺服器中的合理 RAM 數量。 在虛擬機器中，由於可輕易修改設定，且 RAM 可新增至 VM，因此從 12 GB 開始，並預計在未來進行監視和升級，是合理的。

網路

正在評估

本節的重點並非評估複寫流量的相關需求 (這著重在周遊 WAN 的流量，將在 Active Directory 複寫流量中完整說明)，而是評估所需的總頻寬和網路容量，包括用戶端查詢、群組原則應用程式等等。 針對現有的環境，可以使用效能計數器 "Network Interface(*)\Bytes Received/sec" 和 "Network Interface(*)\Bytes Sent/sec" 來收集這些資料。 網路介面計數器的取樣間隔為 15、30 或 60 分鐘。 採樣間隔較小，通常太不穩定而無法進行適當的測量；若間隔較大，則每日尖峰將過於平滑。

注意

一般而言，DC 上的多數網路流量都是輸出流量，因為 DC 會回應用戶端查詢。 因此我們將焦點放在輸出流量上，但也建議評估輸入流量的每個環境。 相同的方法可用來解決及檢閱輸入網路流量需求。 如需詳細資訊，請參閱知識庫文章 929851：在 Windows Vista 和 Windows Server 2008 中，TCP/IP 的預設動態連接埠範圍已變更。

頻寬需求

規劃網路可擴縮性涵蓋兩個不同的類別：流量的數量，以及來自網路流量的 CPU 負載。 與本文的其他主題相比，這些案例都很簡單明瞭。

在評估必須支援多少流量時，AD DS 在網路流量方面有兩種獨特的容量規劃類別。 其一是在網域控制站之間周遊的複寫流量，這在 Active Directory 複寫流量中有完整說明，但也與 AD DS 目前的版本有關。 其二是站台內用戶端對伺服器流量。 一個較簡單的規劃案例是，站台內流量主要接收來自用戶端的小型要求，相對於傳回給用戶端的大量資料。 對於站台中每個伺服器最多 5,000 名使用者的環境，100 MB 通常即已足夠。 對於任何超過 5,000 名使用者的環境，則建議使用 1 GB 網路介面卡和接收端調整 (RSS) 支援。 若要驗證此案例 (尤其是伺服器合併的案例)，請查看站台中所有 DC 的 Network Interface(*)\Bytes/sec、並將其加總，然後除以網域控制站的目標數目，以確保有足夠的容量。 為此，最簡單的方式是使用 Windows 可靠性和效能監視器 (先前稱為 Perfmon) 中的 [堆疊區域] 檢視，確定所有計數器均調整為相同。

請考量下列範例 (也稱為驗證一般規則是否適用於特定環境的極複雜方法)。 相關假設如下：

  • 目標是盡可能減少伺服器的耗用資源。 在理想情況下，會由一部伺服器承擔負載，並部署另一部伺服器以供備援之用 (N + 1 案例)。
  • 在此案例中，目前的網路介面卡僅支援 100 MB，且位於交換環境中。 N 案例 (失去 DC) 中的目標網路頻寬使用率上限為 60%。
  • 每部伺服器約有 10,000 個連線的用戶端。

從圖表中的資料獲得的知識 (Network Interface(*)\Bytes Sent/sec)：

  1. 工作日從 5:30 左右開始增加，在晚上 7:00 開始減少。
  2. 最忙碌的尖峰時段是早上 8:00 到早上 8:15，在最忙碌的 DC 上每秒傳送超過 25 個位元組。

    注意

    所有效能資料都是歷程記錄資料。 因此，8:15 的尖峰資料點會顯示從 8:00 到 8:15 的負載。

  3. 凌晨 4:00 之前會有尖峰，最繁忙的 DC 每秒傳送超過 20 個位元組，這可能表示來自不同時區的負載或背景基礎結構活動 (例如備份)。 由於早上 8:00 的尖峰超出此活動的範圍，因此並不相關。
  4. 站台中有五個網域控制站。
  5. 每個 DC 的最大負載約為 5.5 MB/秒，佔 100 MB 連線的 44%。 使用這項資料，可估算出早上 8:00 到早上 8:15 之間的總頻寬為 28 MB/秒。

    注意

    請注意，網路介面傳送/接收計數器是以位元組為單位，而網路頻寬則以位元測量。 100 MB ÷ 8 = 12.5 MB、1 GB ÷ 8 = 128 MB。

結論：

  1. 目前這個環境在 60% 的目標使用率下符合 N+1 容錯層級。 使一個系統離線，會將每部伺服器的頻寬從大約 5.5 MB/秒 (44%) 轉變為大約 7 MB/秒 (56%)。
  2. 根據先前所述合併至一部伺服器的目標，這超過了最大目標使用率，和理論上 100 MB 連線的可能使用率。
  3. 使用 1 GB 連線時，這代表總容量的 22%。
  4. 在 N + 1 案例的正常作業條件下，用戶端負載會相對平均地分散在每部伺服器，大約 14 MB/秒，或總容量的 11%。
  5. 為了確保在 DC 無法使用期間有足夠的容量，每部伺服器的正常作業目標約為 30% 的網路使用率，或每部伺服器 38 MB/秒。 容錯移轉目標為 60% 的網路使用率或每部伺服器 72 MB/秒。

簡言之，系統的最終部署必須有 1 GB 網路介面卡，並連線至將支援上述負載的網路基礎結構。 另請注意，鑒於產生的網路流量，來自網路通訊的 CPU 負載可能會產生重大影響，並限制 AD DS 的最大可擴縮性。 這個相同的程序可用來估計 DC 的輸入通訊量。 但是，鑒於輸出流量遠高於輸入流量，這對多數環境而言其實是學術上的練習。 在每部伺服器超過 5,000 名使用者的環境中，確保 RSS 的硬體支援是很重要的。 對於高網路流量的案例，中斷負載的平衡可能是瓶頸。 這可以透過 CPU 上未均勻分佈的 Processor(*)% Interrupt Time 偵測出來。 已啟用 RSS 的 NIC 可降低此限制，並提高可擴縮性。

注意

類似的方法可用來估計合併資料中心或淘汰衛星位置的網域控制站時所需的額外容量。 只要收集用戶端的輸出和輸入流量，即獲得 WAN 連結上現有的流量。

在某些情況下，由於流量速度較慢 (例如，憑證檢查未能符合 WAN 上的主動逾時)，可能會產生比預期更多的流量。 因此，WAN 大小調整和使用率應為反覆持續進行的程序。

網路頻寬的虛擬化考量

對實體伺服器很容易提出建議：支援超過 5000 名使用者的伺服器，應使用 1 GB。 一旦多個客體開始共用基礎虛擬交換器基礎結構，則需格外留意，以確保主機有足夠的網路頻寬可支援系統上的所有客體，因此需要更加嚴謹。 這其實就是確保網路基礎結構會擴展到主機電腦中。 這無涉於網路是否包含以虛擬機器客體形式在透過虛擬交換器傳輸網路流量的主機上執行的網域控制站，或是否直接連線至實體交換器。 虛擬交換器只是上行連結需對傳輸的資料量提供支援的元件之一。 因此，連結至交換器的實體主機實體網路介面卡應有能力支援 DC 負載，以及共用連線至實體網路介面卡之虛擬交換器的其他所有客體。

計算摘要範例

系統 尖峰頻寬
DC 1 6.5 MB/秒
DC 2 6.25 MB/秒
DC 3 6.25 MB/秒
DC 4 5.75 MB/秒
DC 5 4.75 MB/秒
總數 28.5 MB/秒

建議值：72 MB/秒 (28.5 MB/秒除以 40%)

目標系統計數 總頻寬 (如前所述)
2 28.5 MB/秒
產生的正常行為 28.5 ÷ 2 = 14.25 MB/秒

一如往常，我們假設經過一段時間後，用戶端負載將會增加，我們應盡可能為此成長進行規劃。 建議的規劃容量會預想網路流量的估計成長率達到 50%。

儲存體

儲存體規劃由兩個元件組成：

  • 容量 (或儲存體大小)
  • 績效

大量的時間和文件都花在規劃容量上，效能往往完全被忽視。 基於目前的硬體成本，大部分的環境都不夠大，以至於兩者實際上都可能是問題，而「根據資料庫大小來增加 RAM」的建議通常會涵蓋其餘部分，儘管對較大環境中的衛星位置而言，可能會是濫用。

調整大小

評估儲存體

相較於 13 年前 Active Directory 導入時，4 GB 和 9 GB 磁碟機是最常見的磁碟機大小，除了最大的環境以外，Active Directory 的大小調整對所有環境而言都不是問題。 使用 180 GB 範圍內的最小可用硬碟大小時，整個作業系統、SYSVOL 和 NTDS.dit 都可輕易安置在一個磁碟機上。 因此，建議不用在此領域進行大量投資。

唯一要考量的建議是，確保有 110% 的 NTDS.dit 大小可供使用，以便啟用磁碟重組。 此外，必須因應硬體生命週期內的增長。

首要考量是評估 NTDS.dit 和 SYSVOL 的大小。 經過這些測量，後續即可為固定磁碟和 RAM 配置調整大小。 由於這些元件的成本 (相對) 較低，因此計算不需太過嚴格精確。 如需如何評估現有環境和新環境的相關內容，請參閱資料儲存體系列文章。 具體來說，請參閱下列文章：

  • 針對現有的環境 –儲存體限制一文中標題為「為透過磁碟重組釋放的磁碟空間啟用記錄」的小節。

  • 針對新環境 – 標題為 Active Directory 使用者和組織單位的成長估計值的文章。

    注意

    這些文章以 Windows 2000 中的 Active Directory 發行時所做的資料大小估計為基礎。 使用的物件大小應反映環境中物件的實際大小。

檢閱具有多個網域的現有環境時，資料庫大小可能會有所不同。 若是如此，請使用最小的通用類別目錄 (GC) 和非 GC 大小。

資料庫大小可能會隨著作業系統版本而異。 DC 若是執行 Windows Server 2003 等舊版作業系統，其資料庫大小會比執行 Windows Server 2008 R2 等更新作業系統的 DC 還小，特別是在 Active Directory 資源回收筒或認證漫遊等功能啟用時。

注意

  • 對於新的環境請注意，Active Directory 使用者和組織單位的成長估計值指出 100,000 名使用者 (在相同網域中) 會耗用約 450 MB 的空間。 請注意，填入的屬性可能會對總數量產生巨大影響。 第三方和 Microsoft 產品 (包括 Microsoft Exchange Server 和 Lync) 都會在許多物件上填入屬性。 最好根據環境中的產品組合進行評估，但除了最大的環境以外，可能不值得投入大量時間和精力對環境進行計算和測試的精確估計。
  • 請確定可將 110% 的 NTDS.dit 大小作為可用空間，以便啟用離線磁碟重組，並規劃在三到五年的硬體生命週期內進行擴增。 有鑑於儲存體成本低廉，估計儲存體大小為 DIT 大小的 300% 作為儲存體配置，就足以因應成長以及離線重組的潛在需求。

儲存體的虛擬化考量

如果在單一磁碟區上配置的多個虛擬硬碟 (VHD) 檔案使用了至少 210% 的固定大小磁碟 (100% 的 DIT + 110% 的可用空間)，請增加 DIT 大小以確實保留足夠的空間。

計算摘要範例

在評估階段收集的資料 大小
NTDS.dit 大小 35 GB
允許離線磁碟重組的修飾詞 2.1 GB
所需的儲存體總計 73.5 GB

注意

這是在 SYSVOL、作業系統、分頁檔、暫存檔、本機快取資料 (例如安裝程式檔案) 和應用程式所需的儲存體以外，額外需要的儲存體。

儲存體效能

評估儲存體的效能

作為任何電腦內最慢的元件，儲存體可能會對用戶端體驗產生最大的負面影響。 對於無法提供 RAM 大小調整建議的大型環境而言，在規劃儲存體時忽略效能可能會有極嚴重的後果。 此外，儲存體技術的複雜性和多樣性限制了將作業系統、記錄和資料庫放置於個別實體磁碟上的長期最佳做法在有用的案例中的適用性，因而提高了失敗的風險。 這是因為長期以來的最佳做法是基於「磁碟」是專用主軸的假設，而這允許隔離 I/O。 隨著下列項目的導入，使其成立的這項假設已不再相關：

  • RAID
  • 新的儲存體類型和虛擬化與共用儲存體案例
  • 存放區域網路 (SAN) 上的共用主軸
  • SAN 或網路連結儲存體上的 VHD 檔案
  • 固態硬碟
  • 分層式儲存架構 (即 SSD 儲存層快取較大的主軸型儲存體)

具體而言，共用儲存體 (RAID、SAN、NAS、JBOD (即儲存空間)、VHD) 都能夠被放置在後端儲存體上的其他工作負載超額使用/多載。 這也衍生了另一項挑戰，即 SAN/網路/驅動程式問題 (實體磁碟與 AD 應用程式之間的一切) 可能導致節流和/或延遲。 需釐清的是，這些並非「不良」設定，而是更複雜的設定，要求每個元件必須全程正常運作，因此需格外注意，以確保可接受效能。 如需更詳細的說明，請參閱本文件稍後附錄 C 中的「SAN 簡介」小節和附錄 D。 此外，雖然固態硬碟沒有旋轉磁碟 (硬碟) 一次只能處理一個 IO 的限制，但仍有 IO 限制，並且允許多載/超額使用 SSD。 簡言之，無論基礎儲存體架構和設計為何，所有儲存體效能工作的最終目標都是要確保有每秒輸入/輸出作業 (IOPS) 所需的數量可用，且這些 IOPS 在可接受的時間範圍內發生 (如本文件其他章節所述)。 對於具有本機連結儲存體的案例，請參閱附錄 C，以取得如何設計傳統本機儲存體案例的基本概念。 這些準則通常適用於更複雜的儲存層，也有助於與支援後端儲存體解決方案的廠商對話。

  • 若有多種儲存體選項可供選擇，建議利用硬體支援小組或廠商的專業知識，以確保特定解決方案符合 AD DS 的需求。 下列數值是提供給儲存體專家使用的資訊。

若環境中的資料庫太大而無法保留在 RAM 中，請使用效能計數器來判斷需要支援多少 I/O：

  • LogicalDisk(*)\Avg Disk sec/Read (例如，如果 NTDS.dit 儲存在 D:/ 磁碟機上，則完整路徑會是 LogicalDisk(D:)\Avg Disk sec/Read)
  • LogicalDisk(*)\Avg Disk sec/Write
  • LogicalDisk(*)\Avg Disk sec/Transfer
  • LogicalDisk(*)\Reads/sec
  • LogicalDisk(*)\Writes/sec
  • LogicalDisk(*)\Transfers/sec

應以 15/30/60 分鐘的間隔取樣，以對目前環境的需求進行基準測試。

評估結果

注意

重點是從資料庫中讀取，因為這通常是最要求嚴苛的元件；替換 LogicalDisk(<NTDS Log>)\Avg Disk sec/Write 和 LogicalDisk(<NTDS Log>)\Writes/sec)，可將相同的邏輯套用至寫入記錄檔：

  • LogicalDisk(<NTDS>)\Avg Disk sec/Read 可指出目前的儲存體大小是否足夠。 如果結果大致等於磁碟類型的磁碟存取時間，則 LogicalDisk(<NTDS>)\Reads/sec 是有效的量值。 檢查後端儲存體的製造商規格，但 LogicalDisk(<NTDS>)\Avg Disk sec/Read 的適當範圍大致為：
    • 7200 – 9 到 12.5 毫秒 (ms)
    • 10,000 – 6 到 10 毫秒
    • 15,000 – 4 到 6 毫秒
    • SSD – 1 到 3 毫秒

    • 注意

      提供的建議指出儲存體效能下降了 15 毫秒到 20 毫秒 (視來源而定)。 上述值與其他指引之間的差異在於，上述值是正常作業範圍。 其他建議是疑難排解指引，用以識別用戶端體驗何時大幅下降且顯而易見。 如需更深入的說明，請參閱附錄 C。

  • LogicalDisk(<NTDS>)\Reads/sec 是正在執行的 I/O 數量。
    • 如果 LogicalDisk(<NTDS>)\Avg Disk sec/Read 在後端儲存體的最佳範圍內，則可以直接使用 LogicalDisk(<NTDS>)\Reads/sec 來調整儲存體的大小。
    • 如果 LogicalDisk(<NTDS>)\Avg Disk sec/Read 不在後端儲存體的最佳範圍內，則需根據下列公式新增額外的 I/O：(LogicalDisk(<NTDS>)\Avg Disk sec/Read) ÷ (Physical Media Disk Access Time) × (LogicalDisk(<NTDS>)\Avg Disk sec/Read)

考量：

  • 請注意，如果伺服器設定了不足量的 RAM，這些值在規劃之中將會不正確。 值將錯誤地偏高，且仍可作為最壞情況的案例使用。
  • 具體來說，新增/最佳化 RAM 會降低讀取 I/O 數量 (LogicalDisk(<NTDS>)\Reads/Sec。這表示儲存體解決方案可能不像最初計算時那麼可靠。 可惜的是，任何比這種概論更具體的內容都取決於用戶端負載，我們無法提供一般指引。 最佳選項是在最佳化 RAM 之後調整儲存體大小。

效能的虛擬化考量

與先前所有虛擬化討論類似，此處的關鍵是確保基礎共用基礎結構可支援 DC 負載，以及使用基礎共用媒體的其他資源及其所有路徑。 無論實體網域控制站與其他伺服器或應用程式是否在 SAN、NAS 或 iSCSI 基礎結構上共用相同的基礎媒體，無論是對 SAN、NAS 或 iSCSI 基礎結構使用傳遞存取的客體共用了基礎媒體，還是客體使用位於本機共用媒體或 SAN、NAS 或 iSCSI 基礎結構上的 VHD 檔案，都是如此。 規劃練習旨在確保基礎媒體能夠支援所有取用者的總負載。

此外，從客體的觀點來看，因為必須周遊額外的程式碼路徑，因此必須經由主機來存取任何儲存體將會對效能造成影響。 當然，儲存體效能測試指出虛擬化會對主機系統的處理器使用率造成影響 (請參閱附錄 A：CPU 大小調整準則)，這顯然會受到客體要求的主機資源影響。 這有助於進行與虛擬化案例中的處理需求有關的虛擬化考量 (請參閱處理的虛擬化考量)。

更複雜的是，有各種不同的儲存體選項可供使用，且分別會對效能造成不同影響。 從實體移轉至虛擬時的一項安全性估計，是使用乘數 1.10 來調整 Hyper-V 上虛擬化客體的不同儲存體選項，例如傳遞儲存體、SCSI 介面卡或 IDE。 在不同儲存案例之間傳輸時需要進行的調整，與儲存體是本機、SAN、NAS 還是 iSCSI 無關。

計算摘要範例

確認正常作業條件下，狀況良好的系統所需的 I/O 數量：

  • 尖峰時段 15 分鐘期間的 LogicalDisk(<NTDS Database Drive>)\Transfers/sec
  • 若要確認超過基礎儲存體容量的儲存體所需的 I/O 數量：

    所需的 IOPS = (LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read ÷ <Target Avg Disk sec/Read>) × LogicalDisk(<NTDS Database Drive>)\Read/sec

計數器 值
Actual LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer .02 秒 (20 毫秒)
Target LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer .01 秒
可用 IO 變更的乘數 0.02 ÷ 0.01 = 2
值名稱 值
LogicalDisk(<NTDS Database Drive>)\Transfers/sec 400
可用 IO 變更的乘數 2
尖峰時段所需的 IOPS 總計 800

若要確認快取所需的暖化速度：

  • 確認暖化快取可接受的時間上限。 這是從磁碟載入整個資料庫所需花費的時間，或者，若是無法在 RAM 中載入整個資料庫，則是指填入 RAM 的時間上限。
  • 確認資料庫的大小，不含空白字元。 如需詳細資訊，請參閱評估儲存體。
  • 將資料庫大小除以 8 KB；這會是載入資料庫所需的 IO 總數。
  • 將 IO 總數除以已定義時間範圍內的秒數。

請注意，計算的速率雖然正確，如果 ESE 未設定為具有固定快取大小，先前載入的頁面將會被收回，而 AD DS 會依預設使用可變快取大小，而使其不精確。

要收集的資料點 值
暖化可接受的時間上限 10 分鐘 (600 秒)
資料庫大小 2 GB
計算步驟 公式 結果
計算資料庫的大小 (以頁面為單位) (2 GB × 1024 × 1024) = 資料庫的大小 (以 KB 為單位) 2,097,152 KB
計算資料庫中的頁數 2,097,152 KB ÷ 8 KB = 頁數 262,144 個頁面
計算完全暖化快取所需的 IOPS 262,144 個頁面÷ 600 秒 = 所需的 IOPS 437 IOPS

加工業

評估 Active Directory 處理器使用量

對大部分的環境而言，在依照「規劃」一節的說明適當調整儲存體、RAM 和網路功能後，管理處理容量將是值得關注的環節。 評估所需的 CPU 容量有兩項挑戰：

  • 環境中的應用程式是否在共用服務基礎結構中妥善運作，並且在「建立更有效率的 Microsoft Active Directory 應用程式」一文中標題為「追蹤昂貴且低效的搜尋」的小節中有所討論，或從下層 SAM 呼叫移轉至 LDAP 呼叫。

    在較大的環境中這一點很重要，因為程式碼不當的應用程式可能導致 CPU 負載波動、從其他應用程式「竊取」大量 CPU 時間、不自然地提高容量需求，以及對 DC 不平均地分配負載。

  • 由於 AD DS 是具有多種不同潛在用戶端的分散式環境，因此，基於使用模式和利用 AD DS 的應用程式類型或數量，估計「單一用戶端」的費用會受到環境影響。 簡言之，就像網路區段一樣，為了廣泛的適用性，最好從評估環境中所需總容量的觀點來解決問題。

對於現有環境，如同先前討論的儲存體大小調整，會假設儲存體現已有適當大小，因此處理器負載的相關資料是有效的。 在此重申，請務必確保儲存體的效能並非系統中的瓶頸。 若有瓶頸存在，且處理器正在等候，在移除瓶頸後，閒置狀態就會消失。 根據定義，隨著處理器等候狀態的移除，CPU 使用率將會增加，因為不再需要等候資料。 因此，請收集效能計數器 "Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read" 和 "Process(lsass)\% Processor Time"。 如果 "Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read" 超過 10 到 15 毫秒 (這是 Microsoft 支援用來排解儲存體相關效能問題的一般閾值)，則 "Process(lsass)\% Processor Time" 中的資料會人為降低。 如前所述，建議取樣間隔為 15、30 或 60 分鐘。 採樣間隔較小，通常太不穩定而無法進行適當的測量；若間隔較大，則每日尖峰將過於平滑。

簡介

進行網域控制站的容量規劃時，最需要關注和了解的是處理能力。 在調整系統大小以確保最大效能時，總是會有一個環節出現瓶頸，而在大小適當的網域控制站中，這會是處理器。

類似於就個別站台來檢閱環境需求的網路區段，對於所需的計算容量也必須執行相同的作業。 不同於網路區段 (其可用的網路技術遠遠超出正常需求)，請更加專注於 CPU 容量的大小調整。 與任何中等規模的環境相同；只要有超過數千名並行使用者，都可能對 CPU 造成龐大負載。

遺憾的是，由於利用 AD 的用戶端應用程式有很大的差異，因此個別 CPU 的一般使用者估計無法一體適用於所有環境。 具體而言，計算需求會受到使用者行為和應用程式設定檔的影響。 因此，各個環境必須個別調整大小。

目標網站行為設定檔

如前所述，在規劃整個網站的容量時，目標是要以 N + 1 容量進行設計，如此，當一個系統在尖峰時段失效時，將能夠以合理的品質水準繼續提供服務。 這表示在 "N" 案例中，所有主機在尖峰時段的負載應小於 100% (最好小於 80%)。

此外，如果站台中的應用程式和用戶端使用最佳做法來尋找網域控制站 (也就是使用 DsGetDcName 函式)，則基於多項因素，用戶端應相對平均地散發，且出現輕微的暫時性尖峰。

在下一個範例中，我們做了下列假設：

  • 站台中的五個 DC 各有四個 CPU。
  • 在正常作業條件 ("N + 1") 下，上班時間的目標 CPU 使用量總計為 40%，其他條件 ("N") 下則為 60%。 在非上班時間，目標 CPU 使用量為 80%，因為預期備份軟體和其他維護應會取用所有可用的資源。

CPU usage chart

分析圖表 (Processor Information(_Total)\% Processor Utility) 中每個 DC 的資料：

  • 負載大致上相對平均分配，若用戶端使用 DC 定位器，且搜尋撰寫得當的話，這是可預期的。

  • 有一些 5 分鐘尖峰達到 10%，有些則高達 20%。 一般而言，除非是導致超出容量計劃目標，否則並不值得研究。

  • 所有系統的尖峰時段大致都介於早上 8:00 到早上 9:15 之間。 若從早上 5:00 左右平穩過渡到下午 5:00 左右，通常表示業務週期。 在下午 5:00 到凌晨 4:00 之間，逐框案例中 CPU 使用率的隨機尖峰將超出容量規劃考量。

    注意

    在妥善管理的系統上，前述尖峰可能是備份軟體執行、完整的系統防毒掃描、硬體或軟體清查、軟體或修補程式部署等等。 由於是落在尖峰使用者業務週期外，因此不會超過目標。

  • 由於每個系統的使用率約為 40%，且所有系統都有相同數量的 CPU，因此若有一個系統失敗或離線，其餘系統將會以估計的 53% 執行 (系統 D 的 40% 負載平均分配並新增至系統 A 和系統 C 現有的 40% 負載)。 基於許多原因，此線性假設並非完全準確，但有足夠的精確度可供量測之用。

    替代案例 – 以 40% 使用率執行的兩個網域控制站：一個網域控制站失敗時，另一個網域控制站的預估 CPU 為 80%。 這遠遠超出上述容量計劃的閾值，並且開始嚴格限制上述負載設定檔中 10% 到 20% 的預留空間量，這表示在「N」案例期間，尖峰會將 DC 提升到 90% 至 100%，且絕對會降低回應能力。

計算 CPU 需求

"Process\% Processor Time" 效能物件計數器會加總應用程式的所有執行緒耗費在 CPU 上的總時間量，然後除以已經過的總系統時間量。 其影響在於多 CPU 系統上的多執行緒應用程式可能會超過 100% 的 CPU 時間，且在解譯上可能會迥異於 "Processor Information\% Processor Utility"。 實際上，"Process(lsass)\% Processor Time" 可以看做是為了支援程序的需求而必須 100% 執行的 CPU 計數。 值為 200% 表示需要 2 個 CPU，每個各 100%，才能支援完整的 AD DS 負載。 雖然從 CPU、電源和耗電量方面花費的成本來看，以 100% 容量執行的 CPU 是最符合成本效益的，但基於附錄 A 中詳述的一些原因，當系統未以 100% 執行時，多執行緒系統提供的回應能力會較優異。

若要因應用戶端負載的暫時性尖峰，建議將尖峰時段 CPU 設為系統容量的 40% 到 60%。 使用前述範例，這表示 AD DS (lsass 程序) 負載需要 3.33 (60% 目標) 到 5 (40% 目標) 個 CPU。 應根據基礎作業系統和其他必要代理程式 (例如防毒、備份、監視等等) 的需求，新增額外的容量。 雖然代理程式的影響需就個別環境進行評估，但可以算出單一 CPU 的估計值介於 5% 到 10% 之間。 在目前的範例中，這表示尖峰時段需要 3.43 (60% 目標) 到 5.1 (40% 目標) 個 CPU。

為此，最簡單的方式是使用 Windows 可靠性和效能監視器 (Perfmon) 中的 [堆疊區域] 檢視，確定所有計數器均調整為相同。

假設：

  • 目標是盡可能減少伺服器的耗用資源。 在理想情況下，會由一部伺服器承擔負載，並新增另一部伺服器以供備援之用 (N + 1 案例)。

Processor time chart for lsass process (over all processors)

從圖表中的資料獲得的知識 (Process(lsass)\% Processor Time)：

  • 工作日從 7:00 左右開始增加，並在下午 5:00 減少。
  • 最忙碌的尖峰時段上午 9:30 到上午 11:00。

    注意

    所有效能資料都是歷程記錄資料。 9:15 的尖峰資料點會顯示從 9:00 到 9:15 的負載。

  • 早上 7:00 之前會有尖峰，這可能表示來自不同時區的負載或背景基礎結構活動 (例如備份)。 由於早上 9:30 的尖峰超出此活動的範圍，因此並不相關。
  • 站台中有三個網域控制站。

在最大負載時，lsass 會耗用大約一個 CPU 的 485%，或 4.85 個 100% 執行的 CPU。 根據稍早的算式，這表示站台需要將大約 12.25 個 CPU 用於 AD DS。 新增前述背景程序 5% 到 10% 的建議，這表示替換目前的伺服器大約需要 12.30 到 12.35 個 CPU，才能支援相同的負載。 現在必須考量環境在成長方面的預估。

調整 LDAP 權數的時機

在某些情況下，應考慮微調 LdapSrvWeight。 在容量規劃的內容中，當應用程式或使用者負載不均衡，或基礎系統在功能方面不均衡時，即應執行此作業。 在容量規劃外執行此作業的原因，不在本文的討論之列。

微調 LDAP 權數有兩個常見原因：

  • 對於使用者或應用程式載入行為未平均分配的環境而言，PDC 模擬器是會產生影響的因素之一。 由於某些工具和動作是以 PDC 模擬器為目標 (例如群組原則管理工具)，在驗證失敗後再次嘗試、建立信任等作業中，PDC 模擬器上的 CPU 資源可能會比站台中其他位置的資源更頻繁使用。
    • 只有在 CPU 使用率有明顯差異時，調整此項目才有效果，可藉以減少 PDC 模擬器上的負載並增加其他網域控制站上的負載，從而使負載分佈更均勻。
    • 在此情況下，請為 PDC 模擬器設定 50 到 75 之間的 LDAPSrvWeight。
  • 站台中的伺服器具有不同的 CPU 計數 (和速度)。 例如，假設有兩部八核心伺服器和一部四核心伺服器。 最後一部伺服器的處理器數目是其他兩部伺服器的一半。 這表示，若用戶端負載平均分佈，四核心主機的平均 CPU 負載會增加至八核心主機的兩倍左右。
    • 例如，兩個八核心主機會以 40% 的使用率執行，而四核心主機則以 80% 的使用率執行。
    • 此外，請考量在此案例中失去一個八核心主機的影響，特別是四核心主機現在會超載的事實。

範例 1 - PDC

系統 使用預設值的使用率 新的 LdapSrvWeight 估計的新使用率
DC 1 (PDC 模擬器) 53% 57 40%
DC 2 33% 100 40%
DC 3 33% 100 40%

這裡的重點是，如果 PDC 模擬器角色被站台中的另一個網域控制站轉移或佔用，新的 PDC 模擬器將會大幅增加。

使用目標站台行為設定檔一節中的範例時，我們假設站台中的三個網域控制站都有四個 CPU。 正常情況下，如果其中一個網域控制站有八個 CPU，將會如何？ 將會有兩個網域控制站，使用率分別為 40% 和 20%。 雖然還不差，但平衡負載有機會更好一點。 請利用 LDAP 權數完成此作業。 範例案例如下：

範例 2 - 不同的 CPU 計數

系統 Processor Information\ % Processor Utility(_Total)
使用預設值的使用率		 新的 LdapSrvWeight 估計的新使用率
4-CPU DC 1 40 100 30%
4-CPU DC 2 40 100 30%
8-CPU DC 3 20 200 30%

不過，請謹慎處理這些案例。 如上所示，理論上的計算數據看起來很漂亮。 但在本文中，規劃 "N + 1" 案例至關重要。 您必須計算一個 DC 離線在各種情況下的影響。 在前述負載均勻分佈的案例中，為了確保在 "N" 案例期間的負載為 60%，且負載均衡分配於所有伺服器上，比率會保持不變，以達到正常分佈。 觀察 PDC 模擬器微調案例，一般而言，只要使用者或應用程式負載未達平衡，效果就會大不相同：

系統 微調的使用率 新的 LdapSrvWeight 估計的新使用率
DC 1 (PDC 模擬器) 40% 85 47%
DC 2 40% 100 53%
DC 3 40% 100 53%

處理的虛擬化考量

在虛擬化環境中需要完成兩層容量規劃。 在主機層級，如同先前針對網域控制站處理列出的業務週期識別，必須識別尖峰時段的閾值。 由於主機電腦在 CPU 上排程客體執行緒，與在實體機器的 CPU 上取得 AD DS 執行緒，採用的是相同的基本準則，因此建議在基礎主機上達到 40% 到 60% 的相同目標。 下一層是客體層，由於執行緒排程的準則並未變更，客體內的目標仍維持在 40% 到 60% 的範圍內。

在直接對應的案例中，每部主機一個客體，為此完成的所有容量規劃都必須新增至基礎主機作業系統的需求 (RAM、磁碟、網路)。 在共用主機案例中，測試顯示對基礎處理器的效率有 10% 的影響。 這表示，如果站台在 40% 的目標下需要 10 個 CPU，則建議在所有 "N" 客體間配置 11 個虛擬 CPU。 在實體伺服器和虛擬伺服器混合分佈的站台中，修飾詞僅適用於 VM。 例如，如果站台具有 "N + 1" 案例，則一部具有 10 個 CPU 的實體或直接對應的伺服器，大約相當於主機上具有 11 個 CPU 的一個客體 (為網域控制站保留 11 個 CPU)。

在支援 AD DS 負載所需的 CPU 數量分析和計算過程中，與可購買的實體硬體相對應的 CPU 數目不一定會明確對應。 虛擬化不需要四捨五入。 虛擬化可減少將計算容量新增至站台所需的工作，因為 CPU 可輕易新增至 VM。 但仍然需要精準評估所需的計算能力，以便在需要將額外的 CPU 新增至客體時能夠使用基礎硬體。 照例，請記得為需求的增長做好規劃和監視。

計算摘要範例

系統 尖峰 CPU
DC 1 120%
DC 2 147%
Dc 3 218%
目前使用的 CPU 總計 485%
目標系統計數 總頻寬 (如前所述)
40% 的目標下所需的 CPU 4.85 ÷ .4 = 12.25

因為很重要所以再三強調，請記得做好增長的規劃。 假設未來三年會增長 50%，此環境在這三年間將需要 18.375 個 CPU (12.25 × 1.5)。 替代計劃是在第一年後加以審視，並視需要增加額外的容量。

NTLM 的跨信任用戶端驗證負載

評估跨信任用戶端驗證負載

許多環境可能會有一或多個透過信任連線的網域。 若要求在另一個未使用 Kerberos 驗證的網域中進行身分識別驗證，必須使用網域控制站的安全通道，將信任周遊至另一個網域控制站 (可能位於目的地網域中，或位於目的地網域路徑中的下一個網域)。 網域控制站可使用安全通道對受信任網域中的網域控制站進行的並行呼叫數目，由名為 MaxConcurrentAPI 的設定所控制。 對於網域控制站，可藉由下列兩種方法之一來確保安全通道能夠處理負載量：微調 MaxConcurrentAPI，或在樹系內建立捷徑信任。 若要測量個別信任的流量，請參閱如何使用 MaxConcurrentApi 設定執行 NTLM 驗證的效能微調。

在資料收集期間，這和所有其他案例一樣，必須在一天的尖峰忙碌時段收集，資料才有效用。

注意

樹系內和樹系間案例可能會導致驗證周遊多個信任，且每個階段都需要微調。

規劃

根據預設，有許多應用程式會使用 NTLM 驗證，或在特定設定案例中加以使用。 應用程式伺服器的容量不斷增長，且為越來越多的有效用戶端提供服務。 另一個趨勢是，用戶端僅在限定時間內保持開啟的工作階段，而傾向於定期重新連線 (例如電子郵件提取同步)。 高 NTLM 負載的另一個常見範例，是需要存取網際網路以進行驗證的 Web Proxy 伺服器。

這些應用程式可能因 NTLM 驗證而產生大量負載，這可能會對 DC 造成重大壓力，尤其是在使用者和資源位於不同網域時。

有許多方法可用來管理跨信任負載，這些方法實際上會搭配使用，而不是在單獨的案例中使用。 可能的選項包括：

  • 尋找使用者在其所屬的相同網域中取用的服務，藉以減少跨信任用戶端驗證。
  • 增加可用的安全通道數目。 這與樹系內和跨樹系流量有關，稱為捷徑信任。
  • 微調 MaxConcurrentAPI 的預設設定。

若要在現有的伺服器上微調 MaxConcurrentAPI，請使用下列方程式：

New_MaxConcurrentApi_setting ≥ (semaphore_acquires + semaphore_time-outs) × average_semaphore_hold_time ÷ time_collection_length

如需詳細資訊，請參閱知識庫文章 2688798：如何使用 MaxConcurrentApi 設定調整 NTLM 驗證的效能。

虛擬考量

無，這是作業系統微調設定。

計算摘要範例

資料類型 值
旗號取得 (最小值) 6,161
旗號取得 (最大值) 6,762
旗號逾時 0
平均旗號保留時間 0.012
收集持續時間 (秒) 1:11 分鐘 (71 秒)
公式 (取自 KB 2688798) ((6762 – 6161) + 0) × 0.012 /
MaxConcurrentAPI 的最小值 ((6762 – 6161) + 0) × 0.012 ÷ 71 = .101

在此期間內，此系統可接受預設值。

監視是否符合容量規劃目標

在本文中，我們討論了規劃和調整是為了實現使用率目標。 下圖摘要說明為確保系統可在適當的容量閾值內運作而須監視的建議閾值。 請記住，這些不是效能閾值，而是容量規劃閾值。 超過這些閾值的伺服器將正常運作，但此時請開始驗證所有應用程式是否都能正常運作。 如果前述應用程式運作良好，則應開始評估硬體升級或其他設定變更。

類別 效能計數器 間隔/取樣 目標 警告
處理器 Processor Information(_Total)\% Processor Utility 60 分鐘 40% 60%
RAM (Windows Server 2008 R2 或更早版本) Memory\Available MB < 100 MB N/A < 100 MB
RAM (Windows Server 2012) Memory\Long-Term Average Standby Cache Lifetime(s) 30 分鐘 必須經過測試 必須經過測試
網路 Network Interface(*)\Bytes Sent/sec

Network Interface(*)\Bytes Received/sec

 30 分鐘 40% 60%
儲存體 LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read

LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Write

 60 分鐘 10 毫秒 15 毫秒
AD 服務 Netlogon(*)\Average Semaphore Hold Time 60 分鐘 0 1 秒

附錄 A：CPU 大小調整準則

定義

處理器 (微處理器) - 讀取和執行程式指令的元件

CPU – 中央處理器

多核心處理器 – 相同積體電路上的多個 CPU

多 CPU – 多個 CPU，不在相同的積體電路上

邏輯處理器 – 從作業系統的觀點來看，是一個邏輯運算引擎

這包括超執行緒、多核心處理器上的一個核心，或單一核心處理器。

由於現今的伺服器系統有多個處理器、多個多核心處理器，以及超執行緒，因此這項資訊已概括涵蓋這兩種案例。 因此，將使用邏輯處理器一詞，因為它代表可用運算引擎的作業系統和應用程式層面。

執行緒層級平行處理原則

每個執行緒都是獨立的工作，因為每個執行緒都有其本身的堆疊和指令。 由於 AD DS 是多執行緒，而且可以使用如何使用 Ntdsutil.exe 在 Active Directory 中檢視和設定 LDAP 原則來調整可用執行緒數目，因此可在多個邏輯處理器間適當調整。

資料層級平行處理原則

這涉及在一個程序中的多個執行緒之間共用資料 (在只有 AD DS 程序的情況下)，以及在多個程序中的多個執行緒之間共用資料 (一般而言)。 為避免過度簡化此情況，這意味著對資料所做的任何變更，都會在執行上述執行緒以及更新共用記憶體的所有核心之間，反映於各個不同快取層級 (L1、L2、L3) 中的所有執行中執行緒上。 在寫入作業期間，效能可能會降低，且必須使所有不同的記憶體位置達成一致，才會繼續進行指令處理。

CPU 速度與多重核心的考量

一般經驗法則是，較快的邏輯處理器可縮短處理一系列指令所需的時間，而較多邏輯處理器則意味著可以同時執行更多工作。 隨著案例在本質上變得更加複雜，而需考量如何從共用記憶體擷取資料、等待資料層級平行處理原則，以及管理多個執行緒的額外負荷等事項，這些經驗法則將會崩解。 這也是多核心系統的可擴縮性並非線性的原因。

請試著以下列比喻考量這些事項：設想一條高速公路上，每輛汽車代表一個執行緒，每個車道代表一個核心，速度限制代表時脈速度。

  1. 如果高速公路上只有一輛車，那麼有兩條車道還是 12 條車道並無差別。 只要在限速內，那輛車想開多快都行。
  2. 假設執行緒所需的資料無法立即提供。 就這個比喻來說，就是一段道路封閉了。 如果高速公路上只有一輛車，在車道重新開放之前，速限並不重要 (資料擷取自記憶體)。
  3. 隨著汽車數量增加，管理這些汽車的額外負荷也會增加。 比較道路幾乎空無一人 (例如深夜) 和交通繁忙 (例如下午三點左右，但非尖峰時間) 時的駕駛經驗和所需的注意力。 此外，試想在雙車道和六車道的高速公路上行駛時所需的注意力有何不同；對前者只需注意另一個車道的駕駛者在做什麼，後者則需注意許多駕駛者的行為。

    注意

    下一節將延伸關於尖峰時間案例的比喻：回應時間/系統忙碌對效能有何影響。

因此，與更多或更快的處理器有關的特定資訊會非常容易受到應用程式行為的影響，這對於 AD DS 而言，多半會隨著環境而不同，甚至會隨著環境內的伺服器而不同。 正因如此，本文稍早的參考才未過度講求精確，並且在在計算中包含安全邊界。 在做出預算驅動的購買決策時，建議先將處理器使用量最佳化為 40% (或環境所需的數值)，再考慮購買更快速的處理器。 隨著處理器增加而進行更多同步處理，增加處理器所帶來的實質線性優勢將會減少 (處理器數目加倍時，提供的額外計算能力會不到 2 倍)。

注意

此概念與阿姆達爾定律和古斯塔夫森定律有關。

回應時間/系統忙碌對效能有何影響

等候理論是對排隊的數學研究。 在等候理論中，會以下列方程式表示「利用法則」：

U k = B ÷ T

其中，U k 是使用率百分比，B 是忙碌的時間量，而 T 是觀察系統的總時間。 轉譯成 Windows 的內容時，這表示處於執行中狀態的 100 奈秒 (ns) 間隔執行緒數目除以指定時間間隔內的可用 100-ns 間隔數目。 這正是計算 % Processor Utility 的公式 (請參閱處理器物件和 PERF_100NSEC_TIMER_INV)。

等候理論也提供公式 N = U k ÷ (1 – U k)，根據使用率來估計等候項目的數目 (N 是佇列的長度)。 依據所有使用率間隔繪製其圖表，可估計在任何指定的 CPU 負載下，佇列到達處理器所需的時間。

Queue length

可以看到，在 50% 的 CPU 負載之後，佇列中平均始終會有一個其他項目在等候，而在 CPU 使用率約 70% 之後，此數目會明顯快速增加。

回到本節稍早使用的駕駛比喻：

  • 假設「下午三點左右」的忙碌時間會落在 40% 至 70% 的範圍。 交通量達到一定程度，駕駛選擇車道的能力未受到太多限制，而路上雖然很可能有其他駕駛者，但要找出與其他車輛的安全差距並不「費力」。
  • 駕駛會發現，隨著交通接近尖峰時間，道路系統也接近 100% 的容量。 變換車道可能會變得很有挑戰性，因為車輛彼此太過接近，因此必須謹慎行事。

這就是為什麼將長期平均容量保守估計為 40% 可為負載的異常尖峰保留餘裕，無論上述尖峰是暫時性的 (例如，執行幾分鐘的不當編碼查詢)，還是常見的負載異常高載 (週末過後的第一個早晨)。

以上敘述將 % Processor Time 計算視同「利用法則」是一種簡化，以方便一般讀者理解。 對於較注重數學正確性的人：

  • 轉譯 PERF_100NSEC_TIMER_INV
    • B =「閒置」執行緒在邏輯處理器上耗費的 100-ns 間隔數目。 PERF_100NSEC_TIMER_INV 計算中 "X" 變數的變更
    • T = 指定時間範圍內的 100-ns 間隔總數。 PERF_100NSEC_TIMER_INV 計算中 "Y" 變數的變更。
    • U k = 以「閒置執行緒」或 % Idle Time 計算的邏輯處理器使用率百分比。
  • 數學計算：
    • U k = 1 – %Processor Time
    • %Processor Time = 1 – U k
    • %Processor Time = 1 – B / T
    • %Processor Time = 1 – X1 – X0 / Y1 – Y0

將概念運用到容量規劃

上述算式可能會使確認系統中所需的邏輯處理器數目顯得極為複雜。 正因如此，調整系統大小的方法才會著重於根據目前的負載來判斷最大目標使用率，並計算達到目標所需的邏輯處理器數目。 此外，邏輯處理器速度對於效能、快取效率、記憶體一致性需求、執行緒排程和同步處理會有顯著影響，而不完全平衡的用戶端負載則會對因伺服器而異的效能產生重大影響。 由於計算能力的成本相對較便宜，嘗試分析和判斷所需的 CPU 數目更像是學術活動，而不是提供商業價值。

百分之四十並非嚴格的硬性需求，而是合理的開始。 Active Directory 的各種取用者需要不同層級的回應能力。 在某些情況下，環境可用 80% 或 90% 的使用率作為持續平均值執行，因為存取處理器增加的等候時間對用戶端效能不會有明顯影響。 再次重申，系統中有許多區域比系統中的邏輯處理器慢得多，包括存取 RAM、存取磁碟，以及透過網路傳輸回應。 這些項目全都必須一併調整。 範例：

  • 將更多處理器新增至以 90% 磁碟限制執行的系統，可能不會大幅改善效能。 系統更深入的分析可能會發現許多執行緒甚至未進入處理器，因為它們正在等候 I/O 完成。
  • 解決磁碟限制問題可能意味著先前花費大量時間等候的執行緒將不再等候 I/O，因而增加對 CPU 時間的競爭，也就是說，上一個範例中的 90% 使用率會達到 100% (因為無法更高了)。 這兩個元件必須一併調整。

    注意

    系統若具有 "Turbo" 模式，Processor Information(*)\% Processor Utility 則可能超過 100%。 在此情況下，CPU 會短暫超過額定處理器速度。 請參閱 CPU 製造商文件和計數器說明，以取得更詳細的深入解析。

討論整體系統使用率考量時，也會談到將網域控制站當作虛擬化客體的話題。 回應時間/系統忙碌對效能有何影響適用於虛擬化案例中的主機和客體。 正因如此，在只有一個客體的主機中，網域控制站 (通常是任何系統) 的效能與在實體硬體上幾乎相同。 如前所述，將額外的客體新增至主機會增加基礎主機的使用率，進而增加取得處理器存取權的等候時間。 簡言之，必須同時在主機和客體層級上管理邏輯處理器使用率。

延伸先前的比喻，高速公路仍是實體硬體，客體 VM 則比喻為公車 (將乘客載往其所需目的地的快捷巴士)。 設想下列四個案例：

  • 現在是離峰時間，一名乘客登上幾乎是空車的公車，公車在幾乎淨空的道路上行駛。 由於沒有混雜的交通狀況，乘客可以像自駕一樣快速到達目的地，十分輕鬆。 乘客的乘車時間仍然受到速度限制。
  • 現在是離峰時間，公車幾乎是空的，但路上大部分的車道都封閉了，因此高速公路仍塞車。 乘客搭乘幾乎空蕩蕩的公車，行駛在塞車的道路上。 雖然乘客在公車上沒有太多競爭，但總行程時間仍然由車外的交通狀況決定。
  • 現在是尖峰時間，因此高速公路和公車都很擁擠。 不僅行程時間拉長，上下車也是人擠人宛如噩夢，且高速公路的路況也不是很好。 增加更多的公車 (為客體新增邏輯處理器) 不表示行程可以更順暢或節省時間。
  • 最後一個案例的比喻可能有點誇大：公車客滿，但路上沒塞車。 雖然乘客仍然很難上下車，但行程在公車上路後很有效率。 這是新增更多公車 (為客體新增邏輯處理器) 可改善客體效能的唯一案例。

由此可較容易地推斷出，道路使用率在 0% 到 100% 之間和公車利用率在 0% 到 100% 之間，存在著影響程度各異的多種案例。

基於與上述佇列數量相同的原因，將上述 40% CPU 的準則作為主機和來賓的合理目標，是恰當的著手點。

附錄 B：不同處理器速度的相關考量，以及處理器電源管理對處理器速度的影響

在處理器選取的相關章節中，假設處理器在收集資料的整個過程以 100% 的時脈速度執行，且更換系統將有相同的速度處理器。 儘管這兩種假設在實務上都是錯誤的，尤其是 Windows Server 2008 R2 和更新版本 (預設電源計劃是平衡)，但此方法仍不失為有效的保守方法。 雖然潛在的錯誤率可能會增加，但只會增加安全邊際，因為處理器速度也會增加。

  • 例如，在需要 11.25 個 CPU 的案例中，如果處理器在收集資料時以半速執行，則比較精確的估計值可能是 5.125 ÷ 2。
  • 時脈速度加倍，不保證指定時段內發生的處理量就會加倍。 這是因為處理器在 RAM 或其他系統元件上等候的時間量可能會維持不變。 最終效果是，較快的處理器在等候擷取資料時可能會有較高的閒置時間百分比。 同樣地，建議固定使用分母的最小公倍數，採取保守策略，不要試圖透過假設處理器速度之間的線性比較來計算可能錯誤的精確度。

或者，如果替換硬體中的處理器速度低於目前的硬體，則可以安全地按比例增加對所需處理器的估計值。 例如，計算出需要 10 個處理器才能維持站台中的負載，而目前的處理器以 3.3 Ghz 執行，替換處理器將以 2.6 Ghz 執行，則速度降低 21%。 在此情況下，12 個處理器會是建議的數量。

也就是說，這種變化不會改變容量管理處理器使用率目標。 由於處理器時脈速度會根據所需的負載動態調整，因此，在較高負載下執行系統，將會產生 CPU 在較高的時脈速度狀態下花費更多時間的情況，最終目標是在尖峰時以 100% 時脈速度狀態達到 40% 的使用率。 只要低於此值都能省電，因為 CPU 速度在非尖峰期間會受到節流。

注意

選項之是在收集資料時關閉處理器上的電源管理 (將電源計劃設定為高效能)。 這會更準確地呈現目標伺服器上的 CPU 耗用量。

為了調整對各種處理器的估計，排除上述其他系統瓶頸，過去可以安全地假設，將處理器速度加倍，可完成的工作量也會加倍。 現今，處理器的內部架構在處理器之間已有很大的差異，若要以更安全的方法來測量所使用的並非擷取資料的處理器有何影響，應使用 Standard Performance Evaluation Corporation 的 SPECint_rate2006 基準測試。

  1. 尋找使用中和計劃使用的處理器的 SPECint_rate2006 分數。

    1. 在 Standard Performance Evaluation Corporation 的網站上選取 [結果]、醒目提示 CPU2006，然後選取 [搜尋所有 SPECint_rate2006 結果]。
    2. 在 [簡易要求] 底下，輸入目標處理器的搜尋準則，例如 Processor Matches E5-2630 (baselinetarget) 和 Processor Matches E5-2650 (baseline)。
    3. 尋找要使用的伺服器和處理器設定 (若沒有完全相符的項目，則尋找接近的項目)，並記下 [結果] 和 [核心數] 資料行中的值。

  2. 若要確認修飾詞，請使用下列方程式：

    ((目標平台的每核心分數值)× (基準平台的每核心 MHz))÷ ((基準每核心分數值)× (目標平台的每核心 MHz))

    使用上述範例：

    (35.83 × 2000) ÷ (33.75 × 2300) = 0.92

  3. 將估計的處理器數目乘以修飾詞。 在上述案例中，從 E5-2650 處理器轉換為 E5-2630 處理器，乘以計算的 11.25 CPU x 0.92 = 需要 10.35 個處理器。

附錄 C：作業系統與儲存體互動的基本知識

回應時間/系統忙碌對效能有何影響中列出的等候理論概念也適用於儲存體。 必須熟悉作業系統處理 I/O 的方式，才能運用這些概念。 在 Microsoft Windows 作業系統中，會為每個實體磁碟建立一個佇列，以保存 I/O 要求。 不過，我們必須詳加說明實體磁碟。 陣列控制器和 SAN 會將主軸彙總為單一實體磁碟呈現給作業系統作為。 此外，陣列控制器和 SAN 可以將多個磁碟彙總為一個陣列集，然後將此陣列集分割成多個「分割區」，繼而以多個實體磁碟的形式呈現給作業系統 (參考下圖)。

Block spindles

在此圖中，兩個主軸會鏡像並分割為資料儲存體的邏輯區域 (資料 1 和資料 2)。 作業系統會將這些邏輯區域視為個別的實體磁碟。

雖然可能令人十分困惑，但本附錄會使用下列術語來識別不同的實體：

  • 主軸 – 實際安裝在伺服器中的裝置。
  • 陣列 – 由控制器彙總的主軸集合。
  • 陣列分割區 – 彙總陣列的資料分割
  • LUN – 參考 SAN 時所使用的陣列
  • 磁碟 – 被作業系統視為單一實體磁碟的項目。
  • 分割區 – 作業系統視為實體磁碟的邏輯資料分割。

作業系統架構考量

作業系統會為觀察到的每個磁碟建立第一個先進/先出 (FIFO) I/O 佇列；此磁碟可能代表主軸、陣列或陣列分割區。 從作業系統的觀點來看，在處理 I/O 方面，作用中佇列越多越好。 FIFO 佇列是序列化的，這表示所有對儲存體子系統發出的 I/O，都必須按照要求到達的順序進行處理。 藉由將作業系統觀察到的每個磁碟與主軸/陣列相互關聯，作業系統現在會針對每個唯一的磁碟集維護 I/O 佇列，藉此消除磁碟間稀缺 I/O 資源的爭用，並將 I/O 需求隔離至單一磁碟。 例外狀況是，Windows Server 2008 導入了 I/O 優先順序的概念，設計為使用「低」優先權的應用程式會脫離此正常順序，並置於次要地位。 未特別編碼為使用「低」優先權的應用程式，會預設為「正常」。

簡單儲存子系統簡介

從簡單的範例 (電腦內部的單一硬碟) 開始，將會提供逐元件的分析。 將其分解為主要儲存子系統元件後，系統包含：

  • 1 – 10,000 RPM Ultra Fast SCSI HD (Ultra Fast SCSI 的傳輸速率為 20 MB/秒)
  • 1 – SCSI 匯流排 (纜線)
  • 1 – Ultra Fast SCSI 介面卡
  • 1 – 32 位元 33 MHz PCI 匯流排

識別元件之後，可以計算可傳輸系統的資料量，或可以處理多少 I/O。 請注意，可以傳輸系統的 I/O 數量和資料數量相互關聯，但並不相同。 此相互關聯取決於磁碟 I/O 是隨機還是循序，以及區塊大小。 (所有資料都會以區塊的形式寫入磁碟，但不同的應用程式使用不同的區塊大小。)以個別元件為基礎：

  • 硬碟 – 平均 10,000 RPM 的硬碟有 7 毫秒 (ms) 的搜尋時間和 3 毫秒的存取時間。 搜尋時間是讀取/寫入磁頭移至盤碟上某個位置所耗費的平均時間。 存取時間是磁頭位於正確位置後，對磁碟讀取或寫入資料所需的平均時間。 因此，在 10,000-RPM HD 中讀取唯一資料區塊的平均時間，會構成共計每一區塊大約 10 毫秒 (或 .010 秒) 搜尋和存取時間。

    每次磁碟存取都需要將磁頭移至磁碟上的新位置時，讀取/寫入行為稱為「隨機」。 因此，若所有 I/O 都是隨機的，則 10,000-RPM HD 每秒大約可處理 100 個 I/O (IOPS) (公式是每秒 1000 毫秒除以每個 I/O 10 毫秒，或 1000/10=100 IOPS)。

    或者，若所有 I/O 來都自 HD 上的相鄰磁區，則稱為循序 I/O。 循序 I/O 沒有搜尋時間，因為第一個 I/O 完成時，讀取/寫入磁頭會位於儲存在 HD 上的下一個資料區塊開頭。 因此，10,000-RPM HD 每秒大約能夠處理 333 個 I/O (每秒 1000 毫秒除以每個 I/O 3 毫秒)。

    注意

    此範例不會反映磁碟快取，其中通常會保留一個磁柱的資料。 在此情況下，第一個 I/O 需要 10 毫秒，磁碟會讀取整個磁柱。 所有其他循序 I/O 的需求都從快取支應。 因此，磁碟內快取或許可改善循序 I/O 效能。

    到目前為止，硬碟的傳輸率並不重要。 無論硬碟是 20 MB/秒的 Ultra Wide 還是 160 MB/秒的 Ultra3，10,000-RPM HD 可處理的實際 IOPS 數量都是大約 100 個隨機 I/O 或大約 300 個循序 I/O。 區塊大小隨著寫入磁碟機的應用程式而變更時，每個 I/O 提取的資料量都不同。 例如，如果區塊大小為 8 KB，則 100 個 I/O 作業會對硬碟讀取或寫入共計 800 KB。 不過，如果區塊大小為 32 KB，則 100 個 I/O 會對硬碟讀取/寫入 3,200 KB (3.2 MB)。 只要 SCSI 傳輸速率超過傳輸的總資料量，「更快的」傳輸速率磁碟機就無法帶來任何效益。 如需比較，請參閱下表。

    描述 7200 RPM 9 毫秒搜尋，4 毫秒存取 10,000 RPM 7 毫秒搜尋，3 毫秒存取 15,000 RPM 4 毫秒搜尋，2 毫秒存取
    隨機 I/O 80 100 150
    循序 I/O 250 300 500
    10,000 RPM 磁碟機 8 KB 區塊大小 (Active Directory Jet)
    隨機 I/O 800 KB/秒
    循序 I/O 2400 KB/秒

  • SCSI 背板 (匯流排) – 了解「SCSI 背板 (匯流排)」(或在此案例中的帶狀纜線) 對儲存子系統的輸送量有何影響，這取決於對區塊大小的了解。 基本上，若 I/O 位於 8 KB 區塊中，匯流排可以處理多少 I/O？ 在此案例中，SCSI 匯流排為 20 MB/秒 (或 20480 KB/秒)。 20480 KB/秒除以 8 KB 區塊，算出 SCSI 匯流排最多約可支援 2500 個 IOPS。

    注意

    下表中的圖表顯示範例。 多數已連結的存放裝置目前都使用 PCI Express，可提供更高的輸送量。

    SCSI 匯流排的每個區塊大小支援的 I/O 2 KB 區塊大小 8 KB 區塊大小 (AD Jet) (SQL Server 7.0/SQL Server 2000)
    20 MB/秒 10,000 2,500
    40 MB/秒 20,000 5,000
    128 MB/秒 65,536 16,384
    320 MB/秒 160,000 40,000

    依據此圖表可以判斷，在顯示的案例中無論如何使用，匯流排都絕不會成為瓶頸，因為主軸最大值為 100 I/O，遠低於上述任何閾值。

    注意

    假設的前提是 SCSI 匯流排的效率為 100%。

  • SCSI 介面卡 – 若要判斷可處理的 I/O 數量，必須查看製造商的規格。 將 I/O 要求導向至適當的裝置需要某種類型的處理，因此可以處理的 I/O 數量取決於 SCSI 介面卡 (或陣列控制器) 處理器。

    在此範例中，假設可以處理 1,000 個 I/O。

  • PCI 匯流排 – 這是常被忽略的元件。 在此範例中，這不會是瓶頸；但隨著系統擴大，將可能成為瓶頸。 參考數據是，以 33Mhz 運作的 32 位元 PCI 匯流排理論上可以傳輸 133 MB/秒的資料。 方程式如下：

    32 位元÷ 8 位元/位元組 × 33 MHz = 133 MB/秒。

    請注意，這是理論限制；實際上只能達到約最大值的 50%，但在某些高載案例中，可在短時間內達到 75% 的效率。

    66Mhz 64 位元 PCI 匯流排可支援理論最大值 (64 位元÷ 8 位元/位元組 × 66 Mhz) = 528 MB/秒。此外，任何其他裝置 (例如網路介面卡、第二個 SCSI 控制器等等) 都會減少可用頻寬，因為頻寬是共用的，裝置會競爭有限的資源。

在分析此儲存子系統的元件後，主軸是可要求的 I/O 數量 (因而可傳輸系統的資料量) 的限制因素。 具體來說，在 AD DS 案例中，即每秒 100 個隨機 I/O，增量為 8 KB，存取 Jet 資料庫時總計每秒 800 KB。 或者，專門配置給記錄檔的主軸會受到下列關於輸送量上限的限制：每秒 300 個循序 I/O，增量為 8 KB，總計每秒 2400 KB (2.4 MB)。

分析完簡單的設定後，下表顯示儲存子系統中的元件變更或新增時會在何處出現瓶頸。

備註 瓶頸分析 磁碟 Bus 介面卡 PCI 匯流排
這是新增第二個磁碟之後的網域控制站設定。 磁碟設定顯示 800 KB/秒的瓶頸。 新增 1 個磁碟 (總計=2)

I/O 是隨機的

4 KB 區塊大小

10,000 RPM HD

 總計 200 個 I/O
總計 800 KB/秒。
新增 7 個磁碟之後，磁碟設定仍顯示 3200 KB/秒的瓶頸。 新增 7 個磁碟 (總計=8)

I/O 是隨機的

4 KB 區塊大小

10,000 RPM HD

 總計 800 個 I/O。
總計 3200 KB/秒
將 I/O 變更為循序後，網路介面卡因限制為 1000 IOPS，而成為瓶頸。 新增 7 個磁碟 (總計=8)

I/O 是循序的

4 KB 區塊大小

10,000 RPM HD

 每秒可對磁碟讀取/寫入 2400 個 I/O，控制器限制為 1000 IOPS
將網路介面卡替換為支援 10,000 IOPS 的 SCSI 介面卡後，瓶頸會回到磁碟設定上。 新增 7 個磁碟 (總計=8)

I/O 是隨機的

4 KB 區塊大小

10,000 RPM HD

升級 SCSI 介面卡 (現在支援 10,000 個 I/O)

 總計 800 個 I/O。
總計 3,200 KB/秒
將區塊大小增加到 32 KB 後，匯流排由於僅支援 20 MB/秒，將會成為瓶頸。 新增 7 個磁碟 (總計=8)

I/O 是隨機的

32 KB 區塊大小

10,000 RPM HD

 總計 800 個 I/O。 可對磁碟讀取/寫入 25,600 KB/秒 (25 MB/秒)。

匯流排僅支援 20 MB/秒
升級匯流排並新增更多磁碟後，磁碟仍是瓶頸。 新增 13 個磁碟 (總計=14)

新增第二個具有 14 個磁碟的 SCSI 介面卡

I/O 是隨機的

4 KB 區塊大小

10,000 RPM HD

升級至 320 MB/秒的 SCSI 匯流排

 2800 個 I/O

11,200 KB/秒 (10.9 MB/秒)
將 I/O 變更為循序後，磁碟仍是瓶頸。 新增 13 個磁碟 (總計=14)

新增第二個具有 14 個磁碟的 SCSI 介面卡

I/O 是循序的

4 KB 區塊大小

10,000 RPM HD

升級至 320 MB/秒的 SCSI 匯流排

 8,400 個 I/O

33,600 KB\秒

(32.8 MB\秒)
新增更快速的硬碟後，磁碟仍是瓶頸。 新增 13 個磁碟 (總計=14)

新增第二個具有 14 個磁碟的 SCSI 介面卡

I/O 是循序的

4 KB 區塊大小

15,000 RPM HD

升級至 320 MB/秒的 SCSI 匯流排

 14,000 個 I/O

56,000 KB/秒

(54.7 MB/秒)
將區塊大小增加到 32 KB 後，PCI 匯流排會成為瓶頸。 新增 13 個磁碟 (總計=14)

新增第二個具有 14 個磁碟的 SCSI 介面卡

I/O 是循序的

32 KB 區塊大小

15,000 RPM HD

升級至 320 MB/秒的 SCSI 匯流排

 14,000 個 I/O

448,000 KB/秒

(437 MB/秒) 是對主軸的讀取/寫入限制。

PCI 匯流排支援 133 MB/秒 的理論最大值 (最高效率為 75%)。

RAID 簡介

陣列控制器導入時，儲存子系統的性質並未大幅變更，只是取代了計算中的 SCSI 介面卡。 變更的是使用各種陣列層級 (例如 RAID 0、RAID 1 或 RAID 5) 時對磁碟讀取和寫入資料的成本。

在 RAID 0 中，資料會等量分割到 RAID 集合中的所有磁碟上。 這表示在讀取或寫入作業期間，會對每個磁碟提取或推送部分資料，而增加可在相同時段內傳輸系統的資料量。 因此，每個主軸 (同樣假設 10,000-RPM 磁碟機) 每秒可以執行 100 個 I/O 作業。 可支援的 I/O 總數，是 N 個主軸乘以每個主軸每秒 100 個 I/O (即 100*N IOPS)。

Logical d: drive

在 RAID 1 中，資料會在一對主軸間進行鏡像處理 (複製)，以供備援之用。 因此，在執行讀取 I/O 作業時，可以從集合中的兩個主軸讀取資料。 這樣可以有效讓兩個磁碟的 I/O 容量在讀取作業期間都可供使用。 請注意，寫入作業在 RAID 1 中沒有效能優勢。 其原因是，為了備援，必須將相同的資料寫入兩個磁碟機。 這雖然不會耗費更多時間，因為兩個主軸同時寫入資料，但由於兩個主軸都被重複資料佔用，一個寫入 I/O 作業本質上會阻止兩個讀取作業。 因此，每個寫入 I/O 都會消耗兩個讀取 I/O。 您可以依據這項資訊建立公式，以確認發生的 I/O 作業總數：

讀取 I/O + 2 × 寫入 I/O = 已取用的可用磁碟 I/O 總計

已知讀取與寫入的比例和主軸數目時，可從前述方程式導出下列方程式，以識別陣列可支援的最大 I/O：

每個主軸的最大 IOPS × 2 個主軸 × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] = IOPS 總計

RAID 1+ 0 在讀取和寫入費用方面的行為與 RAID 1 完全相同。 不過，I/O 現在會等量分割到每個鏡像集。 If

每個主軸的最大 IOPS × 2 個主軸 × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] = I/O 總計

在 RAID 1 集合中，當 RAID 1 集合的多重性 (N) 等量分割時，可處理的 I/O 總計會變成 N × 每個 RAID 1 集合的 I/O：

N × {每個主軸的最大 IOPS × 2 個主軸 × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] } = IOPS 總計

在 RAID 5 中有時稱為 N + 1 RAID，資料會等量分割到 N 個主軸，且同位資訊會寫入置 "+ 1" 主軸。 不過，在執行寫入 I/O 時，RAID 5 的成本遠比 RAID 1 或 1 + 0 昂貴。 每當有寫入 I/O 提交至陣列時，RAID 5 就會執行下列程序：

  1. 讀取舊資料
  2. 讀取舊同位
  3. 寫入新資料
  4. 寫入新同位

由於作業系統提交至陣列控制器的每個寫入 I/O 要求都需要四個 I/O 作業才能完成，因此提交的寫入要求完成的所需時間是單一讀取 I/O 的四倍。 若要從作業系統的觀點導出公式，以將 I/O 要求轉換為在主軸上發生的要求：

讀取 I/O + 4 × 寫入 I/O = I/O 總計

在 RAID 1 中也是一樣，已知讀取與寫入的比例和主軸數目時，可從前述方程式導出下列方程式，以識別陣列可支援的最大 I/O (主軸的總數不包含挪移至同位的「磁碟機」)：

每個主軸的 IOPS × (主軸 – 1) × [(%Reads + %Writes) ÷ (%Reads + 4 × %Writes)] = IOPS 總計

SAN 簡介

隨著儲存體子系統漸趨複雜，當 SAN 導入環境之中，前述基本準則都不變，但對於所有連線至 SAN 的系統，都需考量其 I/O 行為。 由於使用 SAN 的主要優點之一，是內部或外部連結的儲存體可提供額外的備援量，因此現在的容量規劃必須考量到容錯需求。 此外，還導入了其他需要評估的元件。 將 SAN 細分成元件組件：

  • SCSI 或光纖通道硬碟
  • 儲存單位通道背板
  • 儲存單位
  • 存放控制器模組
  • SAN 交換器
  • HBA
  • PCI 匯流排

為任何系統設計備援時，都會包含額外的元件以因應可能的失敗。 進行容量規劃時，請務必將備援元件排除於可用的資源外。 例如，如果 SAN 有兩個控制器模組，則應使用一個控制器模組的所有 I/O 容量來獲取系統可用的總 I/O 輸送量。 這是因為當一個控制器失敗時，所有已連線的系統所要求的整個 I/O 負載，都必須由其餘控制器來處理。 所有容量規劃都是針對尖峰使用期進行的，因此備援元件不應包含在可用資源中。此外，計劃的尖峰使用率應確保系統飽和度不超過 80% (以因應高載或異常系統行為)。 同樣地，備援 SAN 交換器、儲存單位和主軸不應納入 I/O 計算中。

分析 SCSI 或光纖通道硬碟的行為時，分析行為的方法仍與先前說明的相同。 雖然每個通訊協定都各有某些優缺點，但個別磁碟的限制因素屬於硬碟的機械限制。

分析儲存單位上的通道與計算 SCSI 匯流排上的可用資源完全相同，或等同於頻寬 (例如 20 MB/秒) 除以區塊大小 (例如 8 KB)。 這與先前簡單範例的不同之處，是彙總了多個通道。 例如，假設有 6 個通道，每個通道都支援 20 MB/秒的最大傳輸速率、I/O 和資料傳輸可用的總量為 100 MB/秒 (這是正確數據，而非 120 MB/秒)。 同樣地，容錯是此計算的重要部分，如果失去一整個通道，系統就只剩下 5 個正常運作的通道。 因此，為了確保在發生失敗時仍能持續達到效能預期，所有儲存體通道的總輸送量不應超過 100 MB/秒 (假設負載和容錯平均分配於所有通道)。 將其轉換成 I/O 設定檔的過程，取決於應用程式的行為。 在 Active Directory Jet I/O 的案例中，這大約相當於每秒 12,500 個 I/O (100 MB/秒÷ 每個 I/O 8 KB)。

接下來，必須取得控制器模組製造商的規格，以了解每個模組可支援的輸送量。 在此範例中，SAN 有兩個控制器模組，各支援 7,500 個 I/O。 如果不需要備援，系統的總輸送量可能是 15,000 IOPS。 在計算失敗時的輸送量上限時，限制將是一個控制器的輸送量 (或 7,500 IOPS)。 此閾值遠低於所有儲存體通道可支援的 12,500 IOPS (假設區塊大小為 4 KB) 上限，因此成為目前分析中的瓶頸。 同樣出於規劃目的，規劃所需的最大 I/O 將是 10,400 I/O。

資料離開控制器模組時，會經由光纖通道連線以 1 GB/秒 (或每秒 1 Gb) 的速率傳輸。 將其與其他計量相互關聯時，1 GB/秒會變成 128 MB/秒 (1 GB/秒 ÷ 8 位元/位元組)。 這已超過儲存單位中所有通道的總頻寬 (100 MB/秒)，因此不會成為系統的瓶頸。 此外，由於這只是兩個通道的其中之一 (用於備援的額外 1 GB/秒光纖通道連線)，如果一個連線失敗，其餘連線仍有足夠的容量來處理所需的所有資料傳輸。

在路由至伺服器時，資料很可能會通過 SAN 交換器。 由於 SAN 交換器必須處理傳入的 I/O 要求，並將其轉送至適當的連接埠，因此，交換器會限制可處理的 I/O 數量，但需以製造商規格來確認具體限制為何。 例如，如果有兩個交換器，分別可處理 10,000 IOPS，則總輸送量將是 20,000 IOPS。 同樣地，容錯是一個問題，如果一個交換器失敗，系統的總輸送量將是 10,000 IOPS。 正常作業下的使用率不應超過 80%，因此應以使用不超過 8000 個 I/O 作為目標。

最後，安裝在伺服器中的 HBA，在其可處理的 I/O 數量方面也會有限制。 一般都會安裝第二個 HBA 以供備援之用，但就像 SAN 交換器一樣，計算可處理的最大 I/O 時，N – 1 HBA 的總輸送量就是系統的最大可擴縮性。

快取考量

快取是可在儲存系統的任何時間點大幅影響整體效能的元件之一。 快取演算法的相關詳細分析不在本文的討論之列；不過，關於磁碟子系統上快取的一些基本敘述值得說明：

  • 快取確實改善了持續的循序寫入 I/O，因其允許將許多較小的寫入作業緩衝處理到較大的 I/O 區塊中，並以較少、但較大的區塊取消暫存至儲存體。 這會減少隨機 I/O 總計和循序 I/O 總計，從而為其他 I/O 提供更多資源可用性。

  • 快取不會改善儲存體子系統的持續寫入 I/O 輸送量。 它僅允許寫入進行緩衝處理，直到主軸能夠認可資料。 當儲存子系統中所有可用的主軸 I/O 長時間飽和時，快取終將會填滿。 若要清空快取，必須配置足夠的高載間隔時間或額外的主軸，以提供足夠的 I/O 來支援快取排清。

    較大的快取只能緩衝處理較多資料。 這表示可因應較長的飽和期間。

    在正常運作的儲存體子系統中，作業系統將會有較高的寫入效能，因為只需將資料寫入快取中。 一旦基礎媒體的 I/O 飽和，快取就會填滿，寫入效能會回復到磁碟速度。

  • 快取讀取 I/O 時，快取最有利的情況是將資料循序儲存在磁碟上，且快取可以預先讀取 (假設下一個磁區包含下一個要求的資料)。

  • 若讀取 I/O 是隨機的，磁碟機控制器上的快取就不太可能提升可從磁碟中讀取的資料量。 如果作業系統或應用程式型快取大小超過硬體型快取大小，則不會有任何提升。

    在 Active Directory 的案例中，快取僅受限於 RAM 的數量。

SSD 考量

SSD 與主軸型硬碟完全不同。 但仍有兩項關鍵準則存在：「可以處理多少 IOPS？」 和「這些 IOPS 的延遲性為何？」 相較於主軸型硬碟，SSD 可處理較高的 I/O 數量，且延遲可能較低。 一般而言，截至撰寫本文時，雖然 SSD 的每 GB 成本相對較昂貴，但在每 I/O 成本方面則非常便宜，且在儲存體效能方面也很值得考慮。

考量：

  • IOPS 和延遲很大程度都取決於製造商的設計，在某些情況下觀察到的效能不如主軸型技術。 簡言之，應檢閱並驗證個別磁碟機的製造商規格，且不假設任何一般性。
  • IOPS 類型的數值可能有很大的差異，具體取決於是讀取還是寫入。 一般而言，AD DS 服務主要以讀取為基礎，受到的影響會比少於一些其他應用程式案例。
  • 「可寫入次數」– 這是 SSD 硬碟最終會耗盡的概念。眾多製造商以不同方式因應此一挑戰。 至少對於資料庫磁碟機，以讀取為主的 I/O 設定檔可讓您淡化此問題的重要性，因為資料不會高度變動。

摘要

思考儲存時，可將其想像成住家中的管路。 想像資料儲存媒體的 IOPS 是住家的主排水管。 如果堵塞 (如管道底部) 或受限 (受損或太小)，當使用水量過多時 (有太多客人)，水就會流回家中的所有水槽。 這完全類似於共用環境；在此環境中，一或多個系統會利用 SAN/NAS/iSCSI 上的共用儲存體與相同的基礎媒體。 對於不同的案例，可以用不同的方法來解決：

  • 損毀或太小的排水管需要換新或修理。 這就像是在整個基礎結構中新增硬體，或使用的共用儲存體來轉散發系統。
  • 「堵塞」的管道通常意味著需要識別並消除一或多個問題。 在儲存體案例中，這可能是儲存體或系統層級備份、在所有伺服器間同步處理的防毒軟體掃描，以及在尖峰時段執行的同步磁碟重組軟體。

在任何管路設計中，會有多個排水管匯集到主排水館。 如果這些排水管或連接處有任何一個被堵塞，將只有該連接處後面的部分會停止流動。 在儲存體案例中，這可能是多載交換器 (SAN/NAS/iSCSI 案例)、驅動程式相容性問題 (錯誤的驅動程式/HBA 韌體/storport.sys 組合)，或備份/防毒軟體/磁碟重組。 若要確認儲存「管道」是否夠大，必須測量 IOPS 和 I/O 大小。 將其全部連接在一起，以確保有足夠的「管道口徑」。

附錄 D - 儲存體疑難排解的相關討論 - 在環境中提供至少與資料庫大小一樣多的 RAM，並非可行的選項

建議您了解為何會有這些建議，以利因應儲存技術的變化。 這些建議是基於兩個原因而提供的。 第一個原因是隔離 IO，讓作業系統主軸上的效能問題 (也就是分頁) 不會影響到資料庫和 I/O 設定檔的效能。 第二個原因是，AD DS 的記錄檔 (和大部分的資料庫) 本質上都是循序的，而主軸型硬碟和快取在與循序 I/O 搭配使用時，效能優勢會遠高於高隨機 I/O 模式的作業系統和幾乎完全隨機 I/O 模式的 AD DS 資料庫磁碟機。 藉由將循序 I/O 隔離至個別的實體磁碟機，可以增加輸送量。 現今的儲存體選項產生的挑戰是，支撐這些建議的基本假設已不再成立。 在許多虛擬化儲存體案例中 (例如 iSCSI、SAN、NAS 和虛擬磁碟映像檔)，基礎儲存媒體會在多部主機間共用，因而完全否定了「IO 隔離」和「循序 I/O 最佳化」這兩個層面。 事實上，這些案例使得型態更加複雜，因為其他存取共用媒體的主機可能會降低對網域控制站的回應能力。

在規劃儲存體效能時，有三個類別需要考量：冷快取狀態、暖快取狀態，和備份/還原。 冷快取狀態會發生在像是網域控制站最初重新開機，或是 Active Directory 服務重新啟動而 RAM 中沒有 Active Directory 資料之類的情況下。 暖快取狀態是指網域控制站處於穩定狀態，且資料庫使用快取的情況。 請務必留意，因為兩者會驅動截然不同的效能設定檔，而且，若快取是冷快取，以足夠的 RAM 來快取整個資料庫對於效能並沒有幫助。 我們可以用下列比喻來考量這兩個案例的效能設計：將冷快取暖化是「短跑衝刺」，而執行具有暖快取的伺服器則是「馬拉松」。

無論是冷快取還是暖快取，都會出現儲存體將資料從磁碟移至記憶體的速度有多快這個問題。 將快取變暖是指，隨著時間的推移，重複使用資料的查詢增多、快取命中率提高，以及需要移至磁碟的頻率降低，效能因而改善。 移至磁碟對效能的負面影響也因而減少。 在等待快取暖化並增長至系統允許的大小上限時，任何效能下降都只是暫時性的。 討論可以歸結為從磁碟中擷取資料的速度，並且是 Active Directory 可用 IOPS 的簡單量值，受到基礎儲存體可用 IOPS 的影響。 從規劃的觀點來看，由於暖化快取和備份/還原都是在特殊情況下發生的、通常發生在非工作時間，且會受到 DC 負載的影響，因此除非這些活動排定於非尖峰時間，否則沒有一般建議可供使用。

多數情況下，AD DS 主要是讀取 IO，比例通常是 90% 讀取/10% 寫入。 讀取 I/O 往往是使用者體驗的瓶頸，再加上寫入 IO，就會導致寫入效能下降。 由於 NTDS.dit 的 I/O 主要是隨機的，快取能夠為讀取 IO 提供的效益通常很低，因此，為讀取 I/O 設定檔正確設定儲存體愈形重要。

在正常作業的情況下，儲存體規劃目標是要盡可能縮短 AD DS 的要求從磁碟傳回的等候時間。 其實質意義就是，待處理和擱置的 I/O 數目小於或等於通往磁碟的路徑數目。 有多種方式可進行此測量。 在效能監視案例中，通常會建議 LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read 少於 20 毫秒。 所需的作業閾值必須要低得多，最好盡可能接近儲存體的速度，範圍在 2 到 6 毫秒 (.002 到 .006 秒) 間，視儲存體類型而定。

範例：

Storage latency chart

分析圖表：

  • 左側的綠色橢圓形 – 延遲穩定保持在 10 毫秒。 負載從 800 IOPS 增加到 2400 IOPS。 這是基礎儲存體處理 I/O 要求的絕對速度下限。 這取決於儲存體解決方案的具體內容。
  • 右側的暗紅色橢圓形 – 從離開綠色圓圈到資料收集結束，輸送量保持平穩，而延遲則持續增加。 這表示當要求數量超過基礎儲存體的實體限制時，要求耗費在佇列中等候傳送至儲存體子系統的時間就越長。

運用這項知識：

  • 對查詢大型群組成員資格的使用者有何影響 – 假設這需要從磁碟中讀取 1 MB 的資料，則 I/O 數量及其所需時間可按如下方式來評估：
    • Active Directory 資料庫頁面的大小為 8 KB。
    • 至少需從磁碟中讀取 128 個頁面。
    • 假設未快取任何內容，依下限 (10 毫秒) 至少需要 1.28 秒的時間才能從磁碟中載入資料，以將其傳回至用戶端。 在 20 毫秒 (這是建議的最大值) 時，儲存體的輸送量早已超過最大值，需要 2.5 秒的時間才能從磁碟中取得資料，以將其傳回給使用者。
  • 快取會以何種速率進行暖化 – 假設用戶端負載會將此儲存體範例的輸送量最大化，快取將以每個 IO 2400 IOPS × 8 KB 的速率進行暖化。 或者，以大約 20 MB/秒的速度，每隔 53 秒將大約 1 GB 的資料庫載入 RAM 中。

注意

當元件積極讀取或寫入磁碟時 (例如，當系統進行備份或 AD DS 執行記憶體回收時)，觀察到短時間的延遲增加是很正常的。 在計算之外，請提供額外的餘裕來處理這些定期事件。 目標是提供足夠的輸送量來因應這些情況，而不影響正常功能。

如您所見，根據儲存體設計，快取能以多快的速度暖化，有其實體限制。 暖化快取的是傳入的用戶端要求，其速率可達基礎儲存體所能提供的速度。 在尖峰時段執行指令碼以「預熱」快取，將會與實際用戶端要求所驅動的負載之間形成競爭。 這可能會對用戶端優先需要的資料造成傳遞上的負面影響，因為根據設計，這會對稀缺的磁碟資源形成競爭，原因是人為嘗試暖化快取時，將會載入與聯繫 DC 的用戶端無關的資料。