本文件已封存並已停止維護。

對應 Operations Manager 2007 設計的需求

更新日期: 2010年8月

適用於: Operations Manager 2007 R2, Operations Manager 2007 SP1

將需求對應到設計

在上一節,您已完成了下列三項工作:

  • 收集商業需求,以便規劃要實作哪些 Operations Manager 功能。

  • 收集 IT 需求,以便規劃管理群組拓撲。

  • 清查公司目前進行監視的方式,以便著手設定 Operations Manager。

本節將引導您進行設計決策,將收集到的所有資訊和知識對應到實際的設計上。這將針對伺服器角色和元件,套用規模調整和容量規劃的最佳作法。其中包括稽核收集服務 (ACS)、管理伺服器、RMS、無代理程式例外狀況監視 (AEM)、閘道伺服器和集合用戶端監視。

管理群組設計

所有 Operations Manager 2007 實作均包含至少一個管理群組,而由於 Operations Manager 2007 具備延展性,對於某些實作來說,單一管理群組可能已經足夠。視公司的需求而定,可能需要立即增加額外的管理群組,或者是日後再慢慢增加。將 Operations Manager 服務散發到多個管理群組的過程稱為分割。

本節將說明哪些情況需要多個管理群組的一般準則。<管理群組組合>一節將說明規劃個別管理群組的組合,例如判定伺服器大小以及將 Operation Manager 角色散發到管理群組中的伺服器。

單一管理群組

請以規劃 Active Directory 網域相同的方式來規劃 Operations Manager 管理群組:一開始先建立單一的管理群組,然後視需要再增加。單一 Operations Manager 2007 R2 管理群組可依下列建議的上限來調整規模:

  • 一台管理伺服器最多可管理 3,000 個代理程式。

  • 在一個管理群組中,只需三到五台管理伺服器便可因應大多數的延展性、備援和災害復原需求。

  • 50 個 Operations 主控台可同時開啟。

  • 一台閘道伺服器最多可管理 1,500 個代理程式。

  • 一台專用管理伺服器最多可管理 25,000 台應用程式錯誤監視 (AEM) 電腦。

  • 一個專用管理群組最多可管理 100,000 台 AEM 電腦。

  • 一台管理伺服器最多可管理 2,500 個集合監視代理程式。

  • 一個管理群組最多可管理 10,000 個集合監視代理程式。

  • 一個管理群組總共可管理 6000 個代理程式以及 UNIX 或 Linux 電腦 (含 50 個開啟的主控台)

  • 一個管理群組總共可管理 10,000 個代理程式以及 UNIX 或 Linux 電腦 (含 25 個開啟的主控台)

  • 一台專用管理伺服器最多可監視 500 台UNIX 或 Linux 電腦

  • 一台專用閘道伺服器最多可監視 100 台 UNIX 或 Linux 電腦

  • 一台專用管理伺服器最多可監視 3000 個 URL

  • 一個專用管理群組最多可監視 12,000 個 URL

  • 一個代理程式可監視 50 個 URL

如需 Operations Manager 2007 SP1 的建議上限,請按一下這個連結。

當您考量上述限制,再配合透過使用 Operations Manager 角色來控制 Operations 主控台資料存取權限所提供的安全性領域,單一管理群組其實具備高度延展性,在大部分的情況下足以適用。

多個管理群組和分割

雖然單一管理群組具備延展性,但如果您的需求符合下列任何案例,就需要多個管理群組:

  • 生產和前置生產功能—在 Operations Manager 中,最佳作法是同時有生產實作和前置生產實作。生產實作可用來監視生產應用程式,而前置生產實作和生產環境沒有太多的互動。前置生產管理群組可在管理組件功能移轉至生產環境之前,用以測試及微調這些功能。此外,有些公司會為新架設且仍在燒機階段,尚未投入正式生產的伺服器設置臨時的環境。前置生產管理群組可用來監視臨時環境,在投入生產前先確定這些伺服器的健全狀況。

  • 專用的 ACS 功能—如果您的需求包括需要收集 Windows 稽核安全性記錄檔事件,則將會實作稽核收集服務 (ACS)。如果貴公司的安全性需求強制要求控制及管理 ACS 功能的系統管理群組必須不同於其他生產環境的系統管理群組,那麼實作專用支援 ACS 功能的管理群組會有所助益。

  • 災害復原功能—Operations Manager 2007 會將所有和 Operations Manager 資料庫的互動記錄在交易記錄檔中,然後再將交易記錄檔提交到資料庫。這些交易記錄檔可傳送至其他 Microsoft SQL Server 2005 SP1 或更新版本或 Microsoft SQL Server 2008 SP1 伺服器,並提交至該處的 OperationsManager 資料庫複本。這種技術稱為記錄傳送。目的地 (或容錯移轉) 管理群組不一定得是完整填入和作用中的管理群組。它可以只包含一個 Root Management Server (RMS),以及一個 SQL Server 2005 SP1 或更新版本或 SQL Server 2008 SP1 伺服器。若必須執行容錯移轉,來源管理群組中的其他管理伺服器必須變更登錄後重新開機,以成為容錯移轉管理群組的成員。

  • 增加容量—Operations Manager 2007 對於單一管理群組可支援的代理程式數目並無限制。根據您使用的硬體以及管理群組的監視負載 (部署的管理組件越多,表示監視負載越高) 而定,您可能需要多個管理群組來維持一定的效能。

  • 合併檢視—當使用多個管理群組來監視環境時,需要有機制來提供合併檢視,以檢視各群組的監視和警示資料。若要這麼做,您可部署一個額外的管理群組 (它不一定要具備任何監視功能) 來存取所有其他管理群組中的資料。這些管理群組可藉由這種方式連線。這個用來提供資料合併檢視的管理群組稱為本機管理群組,而提供資料給它的其他管理群組則稱為連線管理群組

  • 安裝的語言—所有安裝 Operations Manager 伺服器角色的伺服器都必須安裝相同的語言。也就是說,您不能使用英文版的 Operations Manager 2007 安裝 RMS,卻使用日文版部署 Operations 主控台。如果需要使用多種語言來監視,每一種語言的操作員都必須額外配置管理群組。

  • 安全性和系統管理—為求安全性和系統管理而分割管理群組的概念,和透過 Active Directory 組織單位或網域委派系統管理權限給不同管理群組的概念類似。公司中可能有多個不同的 IT 群組,每個群組各有負責的領域,這可能是某個地理區域或事業單位。例如,以一家控股公司為例,就可能是其中一個子公司。若系統管理權限委派完全交由總公司的 IT 群組統籌執行,在每個地區實作管理群組結構會很有用。這些地區的管理群組接著可以設為「連線」管理群組,連線到總公司 IT 資料中心的「本機」管理群組。

上述案例說明應該可以清楚地讓您了解在 Operations Manager 的基礎結構下,需要多少管理群組。下節將說明管理群組內的伺服器角色散發,以及這些系統的規模調整需求。

管理群組組合

在管理群組中,Operations Manager 伺服器元件的編排方式幾乎沒有限制。它們可以全部安裝在同一台伺服器 (閘道伺服器角色除外) 上,或是以各種不同的組合方式分散在多台伺服器。有些角色可安裝到高可用性叢集服務 (先前稱為 MSCS) 容錯移轉叢集,同時也可安裝多台管理伺服器,讓代理程式能在伺服器之間進行容錯移轉。您應根據 IT 需求和最佳化目標,選擇散發 Operations Manager 伺服器元件的方式和使用的伺服器類型。

伺服器角色相容性

Operations Manager 2007 管理群組可提供許多服務。這些服務可分散至特定伺服器,從而將伺服器歸類為特定的角色。並非所有伺服器角色和服務都可以共存。下表將列出角色間的相容性和相依性,以及該角色是否可安裝於容錯移轉叢集:

 

伺服器角色 與其他角色相容 需求 可置於仲裁容錯移轉叢集

操作資料庫

SQL

稽核收集服務 (ACS) 資料庫

SQL

報表資料倉儲資料庫

SQL

報表

專用 SQL Server Reporting Services 執行個體,不在網域控制站上

Root Management Server

與管理伺服器或閘道伺服器角色不相容

管理伺服器

與 Root Management Server 不相容

系統管理員主控台

Windows XP、Windows Vista、Windows Server 2003 和 Windows Server 2008

N/A

ACS 收集器

可與閘道伺服器和稽核資料庫合併

閘道伺服器

只能與 ACS 收集器合併;須為網域成員

Web 主控台伺服器

 

N/A

代理程式

自動部署到管理群組中的 Root Management Server 和管理伺服器中

N/A

上述所有建議均基於下列假設:

  • 磁碟子系統的數量是根據磁碟機每秒每磁碟機可承受 125 個隨機 I/O 操作計算而得。許多磁碟機都能承受更高的 I/O 速率,所以您的設定需要的磁碟機數量就可以少一點。

  • 在同時部署 RMS 和管理伺服器的管理群組中,所有代理程式都應使用管理伺服器作為主要和次要管理伺服器,不可以使用 RMS 作為主要和次要管理伺服器。

  • 無代理程式例外監控指引是假設每台機器每週約當機一到兩次,而 CAB 檔案的大小平均為 500 KB。

  • 集合用戶端監視只包含現成可用的用戶端專用管理組件,包括 Windows Vista、Windows XP 和 Information Worker 管理組件。

  • 代理程式和伺服器間所有連線的速率為 100 Mbps 或更快的速率。

可用性

為解決資料庫、RMS、管理伺服器和閘道伺服器的高可用性需求,您可以將備援建置到管理群組。

  • 資料庫—Operations Manager 2007 中使用的所有資料庫都需要 Microsoft SQL Server 2005 SP1 或更新版本或 Microsoft SQL Server 2008 SP1 或更新版本,這可安裝在 MSCS 仲裁節點容錯移轉設定中。

    note附註
    如需叢集服務的詳細資訊,請參閱 Windows Server 2003 和 Windows Server 2008 線上說明。

  • RMS—System Center 資料存取服務和 System Center 管理設定服務只能在 RMS上執行,因此它們會成為管理群組中的單一失敗點。由於 RMS 扮演著非常關鍵的角色,因此若您的需求包含高可用性,也應將 RMS 安裝在其本身的雙節點容錯移轉叢集。如需如何設定 RMS 叢集的完整詳細資訊,請參閱《Operations Manager 2007 部署指南》。

  • 管理伺服器—在 Operations Manager 中,管理群組中的代理程式可向該群組的任一管理伺服器報告。因此,若有超過一台以上的管理伺服器可用,將為代理程式/伺服器通訊提供備援路徑。最佳作法是在 RMS 之外再另部署一或二台管理伺服器,接著使用「代理程式指派」和「容錯移轉精靈」將代理程式指派到管理伺服器,讓 RMS 不再負責處理代理程式。

  • 閘道伺服器—閘道伺服器可作為管理伺服器和位於管理伺服器 Kerberos 信任界限外的代理程式之間的通訊媒介。如果任何一方與主要伺服器通訊中斷,代理程式可以像在管理伺服器之間一樣,在閘道伺服器之間進行容錯移轉。同樣地,閘道伺服器也可以設定在管理伺服器之間進行容錯移轉,以提供從代理程式到管理伺服器的完整路徑備援。請參閱《Operations Manager 2007 部署指南》,以取得如何部署此設定的程序。

成本

散發的管理群組伺服器角色越多,支援該設定所需的資源就越多。其中包括硬體、環境、授權、操作以及維護費用等。若設計時以成本控制作為最佳化目標,就會朝單一伺服器實作或盡量減少角色散發的方向規劃,這麼做會減少備援,而且可能降低效能。

效能

若是以效能作為最佳化的目標,服務等級會提高,但會需要增加設定的分散程度和較高階的硬體。成本就會相對地提高。

主控台散發和存取點位置

當安裝報表元件和報表伺服器時,Operations 主控台可直接和 RMS 通訊。規劃 RMS 和資料庫伺服器的位置,以及設定和 Operations 主控台的關係,是影響效能的關鍵。請確定這些元件位於網路上相鄰的位置。

元件散發和平台規模建議

下列表格提供 Operations Manager 2007 R2 的元件散發及平台規模建議。如需 Operations Manager 2007 SP1 的元件散發與平台規模建議,請按一下這個連結。在這些表格中,DB 代表 SQL 資料庫伺服器,DW 代表 SQL 資料庫伺服器,RS 代表報表伺服器,RMS 代表 Root Management Server,而 MS 代表管理伺服器。本文稍後會介紹基本 ACS 設計和規劃。

單一伺服器,單機式案例

 

受監視裝置的數目 伺服器角色和設定

15 至 250 台 Windows 電腦,200 台 UNIX 或 Linux 電腦

DB、DW、RS、RMS;

4 磁碟 RAID 0+1,8 GB RAM,四處理器

多台伺服器,小型案例

 

受監視裝置的數目 伺服器角色和設定 伺服器角色和設定

250 至 500 台 Windows 電腦,500 台 UNIX 或 Linux 電腦

DB、DW、RS;

4 磁碟 RAID 0+1,4 GB RAM,雙處理器

RMS;

雙磁碟 RAID 1,4 GB RAM,雙處理器

多台伺服器,中型案例

為提供備援,您可部署多台管理伺服器,每台伺服器均使用所述最低設定。為提供資料庫和 RMS 伺服器高可用性,您可將它們部署到一個叢集中,每個節點均使用所述最低設定,同時連接外部共用磁碟機存取叢集資源。

 

受監視裝置的數目 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定

500 至 750 台 Windows 電腦,500 台 UNIX 或 Linux 電腦

DB;

4 磁碟 RAID 0+1,4 GB RAM,雙處理器

MS;

雙磁碟 RAID 1,4 GB RAM,雙處理器

DW、RS;

4 磁碟 RAID 0+1 (資料),雙磁碟 RAID 1 (記錄檔),4 GB RAM,雙處理器

RMS;

雙磁碟 RAID 1,8 GB RAM,雙處理器

多台伺服器,大型案例

為提供備援,您可部署多台管理伺服器,每台伺服器均使用所述最低設定。為提供資料庫和 RMS 伺服器高可用性,您可將它們部署到一個叢集中,每個節點均使用所述最低設定,同時連接外部共用磁碟機存取叢集資源。

 

受監視裝置的數目 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定

750 至 1000 台 Windows 電腦、Unix 或 Linux 電腦

DB;

4 磁碟 RAID 0+1 (資料),雙磁碟 RAID 1 (記錄檔),8 GB RAM,雙處理器

DW;

4 磁碟 RAID 0+1 (資料),雙磁碟 RAID 1 (記錄檔),8 GB RAM,四處理器。附註:您可使用具有類似效能的 RAID 5 設定來滿足 DW 的儲存需求。

RS;

雙磁碟 RAID 1,4 GB RAM,雙處理器

RMS;

雙磁碟 RAID 1,8 GB RAM,雙處理器

MS;

雙磁碟 RAID 1,4 GB RAM,四處理器

多台伺服器,企業

為提供備援,您可部署多台管理伺服器,每台伺服器均使用所述最低設定。為提供資料庫和 RMS 伺服器高可用性,您可將它們部署到一個叢集中,每個節點均使用所述最低設定,同時連接外部共用磁碟機存取叢集資源。

 

受監視裝置的數目 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定 伺服器角色與設定

1,000 至 3,000 台 Windows 電腦,500 台 UNIX 或 Linux 電腦

DB;

8 磁碟 RAID 0+1 (資料),雙磁碟 RAID 1 (記錄檔),8 GB RAM,四處理器

DW;

8 磁碟 RAID 0+1 (資料),雙磁碟 RAID 1 (記錄檔),8 GB RAM,四處理器

RS;

雙磁碟 RAID 1,4 GB RAM

四處理器

RMS;

4 磁碟 RAID 0+1,12 GB RAM,64 位元四處理器

MS;

4 磁碟 RAID 0+1,8 GB RAM,四處理器

3,000 至 6,000 台 Windows 電腦、UNIX 或 Linux 電腦

DB;

14 磁碟 RAID 0+1 (資料),雙磁碟 RAID 1 (記錄檔),16 GB RAM,四處理器

DW;

14 磁碟 RAID 0+1 (資料),雙磁碟 RAID 1 (記錄檔),16 GB RAM,四/雙處理器。請注意,您可使用具有類似效能的 RAID 5 設定來滿足 DW 的儲存需求。

RS;

雙磁碟 RAID 1,4 GB RAM,四處理器

RMS;

4 磁碟 RAID 0+1,16 GB RAM,四處理器

MS;

2 磁碟 RAID 0+1,8 GB RAM,四處理器

元件指導方針和最佳作法

除了上述規模設定指引外,規劃每一個 Operations Manager 伺服器元件時,還有額外的考量事項及最佳作法。

Root Management Server 指導方針與最佳作法

對於 RMS 而言,最關鍵的資源在於 RAM 和 CPU,因為 RMS 執行的許多作業都需要使用大量的記憶體,而會有過度分頁的問題。影響 RMS 負載的因素包括:

  • 管理群組中的代理程式數目—由於 RMS 必須計算管理群組中所有代理程式的設定,因此不論代理程式傳送的操作資料量多寡,增加代理程式的數目就會增加 RMS 所需的記憶體。

  • 執行個體空間的變更速率—執行個體空間是指 Operations Manager 維護的資料,以描述管理群組中所有受監視的電腦、服務和應用程式。如果這些資料變更頻繁,RMS 就需要額外的資源以針對受影響的代理程式計算設定更新。當您將其他管理組件匯入管理群組時,執行個體空間的變更速率也會提高。新增代理程式到管理群組也會暫時提高執行個體空間的變更速率。

  • 同時執行的 Operations 主控台和其他 SDK 用戶端的數目—其他 SDK 用戶端包括 Web 主控台和許多與 Operations Manager 進行通訊的協力廠商工具。因為 SDK 服務主控於 RMS 上,所以每個額外的連線都會使用記憶體和 CPU。

調整 RMS 規模的一些最佳作法如下:

  • 使用 64 位元硬體和作業系統—使用 64 位元硬體可以輕易地將記憶體提高到 4 GB 以上。即使您目前的部署不需要超過 4 GB RAM,使用 64 位元硬體可讓您有擴充空間,以因應日後的需求改變。

  • 限制或減少 RMS 所管理的代理程式數目—在代理程式數目較少的管理群組中,通常可以讓代理程式直接向 RMS 報告。這樣會減少安裝所需硬體的整體成本。不過,隨著代理程式數量增加,您就必須考慮限制代理程式直接向 RMS 報告。將代理程式的工作負載移轉給其他管理伺服器可以減少 RMS 的硬體需求,而且也可提升管理群組的效能和可靠性。

  • 使用高頻寬的網路連線來連接 Operations Manager 資料庫和資料倉儲—RMS 會經常與 Operations Manager 資料庫和資料倉儲通訊。一般而言,與代理程式和 RMS 間的連線相較,這些 SQL 連線會耗用較多的頻寬,而且對網路延遲也更敏感。因此,您通常應確定 RMS、OperationsManager 資料庫和資料倉儲資料庫位於相同的區域網路。

作業資料庫指導方針與最佳作法

如同所有資料庫應用程式,作業資料庫效能受磁碟子系統效能的影響甚鉅。由於所有 Operations Manager 資料都必須經過 OperationsManager 資料庫,所以磁碟的傳輸速度越快,效能越好。CPU 和記憶體也會影響效能。影響 OperationsManager 資料庫負載的因素包括:

  • 資料收集的速度—RMS 會經常與作業資料庫和資料倉儲通訊。一般而言,與代理程式和 RMS 間的連線相較,這些 SQL 連線會耗用較多的頻寬,而且對網路延遲也更敏感。因此,您通常應確定 RMS、OperationsManager 資料庫和資料倉儲資料庫位於相同的區域網路。

  • 執行個體空間的變更速度—執行個體空間是指 Operations Manager 維護的資料,以描述管理群組中所有受監視的電腦、服務和應用程式。相對於將新的操作資料寫入資料庫,更新 OperationsManager 資料庫中資料的成本相對較高。此外,當執行個體空間資料變更時,RMS 會對 OperationsManager 資料庫進行額外的查詢,以計算設定與群組變更。當您將其他管理組件匯入管理群組時,執行個體空間的變更速率也會提高。新增代理程式到管理群組也會暫時提高執行個體空間的變更速率。

  • 同時執行的 Operations 主控台與其他 SDK 用戶端—每個開啟的 Operations 主控台執行個體都會從 OperationsManager 資料庫讀取資料。查詢這些資料會耗用大量的磁碟活動以及 CPU 和 RAM。主控台在事件檢視、狀態檢視、警示檢視和效能資料檢視中顯示大量的操作資料時,會對資料庫施加最大負載。為取得最大延展性,請考慮限制檢視的範圍,僅包含必要的資料。

以下為調整 OperationsManager 資料庫伺服器規模的一些最佳作法:

  • 選擇適合的磁碟子系統—OperationsManager 資料庫的磁碟子系統是整體管理群組延展性與效能最關鍵的元件。資料庫的磁碟區通常應為 RAID 0+1 加上適合的磁針數。RAID 5 通常不適合此元件,因為它會降低效能以最佳化儲存空間。由於為 OperationsManager 資料庫選擇磁碟子系統的主要因素是效能而非整體儲存空間,因此 RAID 0+1 是較適合的選擇。當您的延展性需求不超過單一磁碟機的輸送量時,RAID 1 通常是較理想的選擇,因為它可以提供容錯而不會影響效能。

  • 資料檔案和交易記錄檔的位置—對於小規模的部署,通常將 SQL 資料檔案和交易記錄檔合併在單一實體磁碟區上最具成本效益,因為交易記錄檔產生的活動量並不會很高。不過,隨著代理程式數量增加,您應考慮將 SQL 資料檔案和交易記錄檔放在不同的實體磁碟區上。這可讓交易記錄檔磁碟區在執行讀取和寫入時更有效率。這是因為工作負載大部分都是循序寫入。單一雙磁針的 RAID 1 磁碟區可以處理大量的循序寫入,應足以適用於大部分的部署,即使部署的規模非常大。

  • 使用 64 位元硬體與作業系統—使用大量 RAM 對 OperationsManager 資料庫通常很有利,以這種方式來降低此伺服器上執行的磁碟活動量,是較具成本效益的做法。使用 64 位元硬體可以輕易地將記憶體提高到 4 GB 以上。即使您目前的部署不需要超過 4 GB RAM,使用 64 位元硬體可讓您有擴充空間,以因應日後的需求改變。

  • 使用具電池備援能力的寫入快取磁碟控制卡—根據測試顯示,磁碟控制卡的寫入快取功能有助於減輕 OperationsManager 資料庫的工作負載。在磁碟控制卡上設定讀取快取及寫入快取時,建議您將 100% 的快取配置給寫入快取。當使用寫入快取磁碟控制卡搭配任何資料庫系統時,請務必確定它們具有電池備援系統,以防止電源中斷時造成資料遺失。

資料倉儲指導方針和最佳作法

在 Operations Manager 2007 中,資料會以接近即時的方式寫入資料倉儲。這會讓它的負載相當於 OperationsManager 資料庫電腦上的負載。由於它是 SQL Server,因此磁碟子系統對於整體效能而言最為重要,其次是記憶體和 CPU。Operations Manager 報表服務也會對資料倉儲伺服器施加稍微不同的負載。影響資料倉儲負載的因素包括:

  • 資料插入速度—為提高報表的效率,資料倉儲除了有限的原始資料量外,還會計算和儲存彙總資料。執行這項額外工作意味著將操作資料收集到資料倉儲的成本,會略高於收集到 OperationsManager 資料庫的成本。相對於在 OperationsManager 資料庫上進行處理,這項額外的成本通常會藉由降低在資料倉儲上處理探索資料的成本來抵銷。

  • 同時執行報表的使用者數量—由於報表通常會摘述大量的資料,所以每位報表使用者都會對系統加諸龐大的負載。同時執行報表的數量以及執行的報表類型,都會影響整體容量需求。一般而言,查詢大日期範圍或大量物件的報表通常需要較多的系統資源。

以下為調整資料倉儲伺服器規模的一些最佳作法:

  • 選擇適合的磁碟子系統—由於資料倉儲是管理群組整體資料流程不可或缺的一部分,為資料倉儲選擇適合的磁碟子系統就變得格外重要。如同 OperationsManager 資料庫,RAID 0+1 通常是最佳選擇。一般而言,資料倉儲的磁碟子系統應類似於 OperationsManager 資料庫的磁碟子系統。

  • 資料檔案和交易記錄檔的位置—如同 OperationsManager 資料庫,當您增加代理程式的數目時,分開放置 SQL 資料和交易記錄檔通常是較理想的選擇。如果 OperationsManager 資料庫和資料倉儲位於同一台實體電腦上,而您要想分開放置資料和交易記錄檔,則必須將 OperationsManager 資料庫的交易記錄檔放在與資料倉儲不同的實體磁碟區,才能發揮效益。只要磁碟區的大小合適,OperationsManager 資料庫和資料倉儲的資料檔案可共用相同的實體磁碟區。

  • 使用 64 位元硬體與作業系統—使用大量 RAM 對資料倉儲通常很有利,以這種方式來降低此伺服器上磁碟活動量,是較具成本效益的做法。使用 64 位元硬體可以輕易地將記憶體提高到 4 GB 以上。即使您目前的部署不需要超過 4 GB RAM,使用 64 位元硬體可讓您有擴充空間,以因應日後的需求改變。

  • 使用資料倉儲專用的伺服器硬體—雖然小規模部署通常可將 OperationsManager 資料庫與資料倉儲合併在同一台實體電腦上,但是隨著代理程式的數目增加,可將兩者分開,因此傳入的操作資料也會隨之增加。如果將資料倉儲和報表伺服器分開,也能獲得較佳的報表效能

  • 使用具電池備援能力的寫入快取磁碟控制卡—根據測試顯示,磁碟控制卡的寫入快取功能有助於減輕資料倉儲的工作負載。在磁碟控制卡上設定讀取快取及寫入快取時,建議您將 100% 的快取配置給寫入快取。當使用寫入快取磁碟控制卡搭配任何資料庫系統時,請務必確定它們具有電池備援系統,以防止電源中斷時造成資料遺失。

管理伺服器指導方針和最佳作法

管理伺服器上的負載主要是來自操作資料收集以及資料插入 OperationsManager 與資料倉儲資料庫。值得注意的是,管理伺服器會直接執行這些作業,而不依靠 RMS。管理伺服器通常是在記憶體中執行資料佇列,而非依賴速度較慢的磁碟,因此可提升效能。管理伺服器最重要的資源是 CPU,但是測試顯示它們通常不需要高階硬體。影響管理伺服器負載的因素包括:

  • 操作資料的收集速度—由於操作資料收集是管理伺服器執行的主要活動,此速度對於整體伺服器使用率而言影響最大。不過,根據測試顯示,管理伺服器在中低使用率下,通常可維持高操作資料處理速度。影響操作資料收集速度的主要因素,在於管理群組中部署了哪些管理組件。

以下為調整管理伺服器規模的一些最佳作法:

  • 請勿使用過大的管理伺服器硬體—多數情況下,使用標準公用程式伺服器就足以因應管理伺服器執行的工作。依照本文硬體指導方針的指示應該足以適用於大部分的工作負載。

  • 代理伺服器與管理伺服器的比例不得超過 3,000 比 1—實際的伺服器效能會視收集的操作資料量而定,但是根據測試顯示,管理伺服器在支援包含大量操作資料傳入的 2,000 個代理程式時,通常不會有問題。每台管理伺服器上有 2,000 個代理伺服器是根據測試經驗所得的指導方針,並非硬性限制。您可能會發現,在您的環境中,單一管理伺服器可支援的代理程式數目會較高或較低。

  • 若要達到最大的 UNIX 或 Linux 電腦與管理伺服器比例 (500:1),請使用專用的管理伺服器進行跨平台監視。

  • 在每個管理群組中使用最少的管理伺服器數以符合備援需求—部署多台管理伺服器的主要原因,應該是為了提供備援和災害復原,而非延展性。根據測試,大部分的部署所需的管理伺服器數目不超過三到五台就能滿足其需求。

閘道伺服器指導方針和最佳作法

閘道伺服器會轉送位於 Kerberos 信任界限兩邊的管理伺服器和代理程式之間的通訊。閘道伺服器使用憑證式驗證來執行與管理伺服器之間的相互驗證;在進行驗證時會使用單一連線,而非像代理程式和管理伺服器之間在進行驗證時使用的多連線。這讓管理不受信任網域的憑證式驗證變得更輕鬆而且易於管理。影響閘道伺服器負載的因素包括:

  • 操作資料收集的速度—影響閘道負載的主要因素是操作資料收集的速度。此速度會隨著向閘道報告的代理程式數目以及在管理群組中部署的管理組件數目而改變。

以下為調整閘道伺服器規模的一些最佳作法:

  • 閘道伺服器有助於管理頻寬使用率—從效能的角度而言,在低頻寬的環境中,建議使用閘道來最佳化頻寬使用率,因為它會對與管理伺服器間的所有通訊執行某種程度的壓縮。

  • 代理程式與閘道伺服器的比例不超過 1,500 比 1—根據測試顯示,當發生長時間 (數小時) 斷電造成閘道無法與管理伺服器通訊的情況時,每台閘道伺服器的代理程式數目若超過 1,000 個,將會對其復原能力有不利影響。如果您需要讓更多代理程式向閘道報告,請考慮使用多台閘道伺服器。如果您要讓每台閘道伺服器的代理程式數目超過 1,500 個,強烈建議您先測試系統,確定在閘道與管理伺服器間長時間中斷後,閘道能夠快速清空其佇列 (如果閘道復原時間對您的環境而言很重要的話)。

  • 如果閘道以及與閘道連線的代理程式數目龐大,請使用專用的管理伺服器—讓所有閘道連線至單一管理伺服器,而無其他代理程式連線至這台管理伺服器。如此當發生長時間斷電的情況時,就可加快其復原的速度。

應用程式錯誤監視指導方針和最佳作法

AEM 使用的管理伺服器會從錯誤報告用戶端接收資料,然後將它儲存至檔案共用。如果檔案共用位於本機,則會影響管理伺服器。

以下為進行 AEM 規劃時的一些最佳作法:

  • 檔案共用的磁碟儲存體可位於本機或網路接附儲存 (NAS),或是存放區域網路 (SAN) 裝置。

  • AEM 使用的磁碟應與資料倉儲或 OperationsManager 資料庫使用的磁碟分開。

  • 如果在分散式檔案系統 (DFS) 上設定存放區,則應停用 DFS 複寫功能。

  • 請勿將閘道伺服器作為 AEM 收集器使用。

 

受監視裝置的數目 AEM 檔案共用的管理伺服器

0 至 10,000

200 GB 磁碟 (雙磁碟機 RAID 1),4 GB RAM,雙處理器

10,000 至 25,000

500 GB 磁碟 (雙磁碟機 RAID 1),8 GB RAM,四處理器

URL 監視指導方針和最佳作法

URL 監視可藉由代理程式或管理伺服器的健全狀況服務來執行。如果您以管理伺服器監視 1000 個以上的 URL,應該將健全狀況服務版本儲存區分頁大小從預設的 5120 頁增加為 10240 頁。此項作業可在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Persistence Version\Store Maximum 中完成。由於執行 URL 監視的管理伺服器將會在 CPU 和磁碟資源上造成大量的負荷,因此建議您使用電池備援的快取控制卡。

集合用戶端監視指導方針和最佳作法

集合健全狀況監視的執行是藉由從多台電腦收集事件和效能資料,然後依系統群組彙總資料,以進行報告和分析。例如,從不同類型硬體上的 Windows XP 和 Windows Vista 用戶端收集個別記憶體效能資料。集合健全狀況監視會彙總這些資料並針對特定系統群組的記憶體效能提供報表,例如依作業系統或硬體廠商。比起冗長的個別系統效能報表,這麼做可以讓整體效能分析變得更加輕鬆。集合監視模式也可以針對集體 (而非個別) 產生警示或監視。

集合用戶端監視管理組件包括:Information Worker、Windows Client、Windows XP、Windows Vista、Network Address Protocol 和其他針對用戶端的管理組件。

每個用戶端都由一個代理程式監視,通常會定期產生摘要事件,然後使用這些事件來計算用戶端母體的集合健全狀況。由於針對個別代理程式發出警示的功能會停用,因此在用戶端上執行的代理程式不會產生任何警示資料。

視部署的管理組件數目和代理程式流量而定,每台管理伺服器可管理多達 3,000 到 4,000 個代理程式管理的用戶端。

規劃集合監視用戶端首展時,每批次核准的代理程式不應超過 1,000 個,以便代理程式能與最新設定進行同步處理。

設計稽核收集服務

本節將提供概要指引,協助您著手規劃 ACS 實作。

ACS 不是獨立的解決方案。ACS 只能受現有的管理群組主控,因為它的代理程式是整合在 Operations Manager 代理程式中並隨其一起安裝,而且 ACS 收集器只能安裝在管理伺服器或閘道伺服器上。ACS 資料庫和 ACS 報表等其他元件可安裝在與其他 OperationsManager 資料庫和報表元件相同的 SQL Server 2005 伺服器或執行個體上。不過,基於效能、容量和安全性考量,您可能會選擇將這些元件安裝在專用硬體上。

設計決策

規劃 ACS 實作時,需要進行四項重要的設計決策。當您進行決策時,請記得 ACS 收集器伺服器與其 ACS 資料庫具有一對一關係。ACS 資料庫一次只能有一個 ACS 收集器餵送資料給它,而每個 ACS 收集器則需要有專屬的 ACS 資料庫。管理群組中可有多個 ACS 收集器/資料庫組;不過,如何將多個 ACS 資料庫的資料整合到單一資料庫中,目前仍無立即可用的程序。

第一項必須進行的決策就是,是否要部署專門用來支援 ACS 的管理群組,或是將 ACS 部署至同時提供健全狀況監視和警示服務的管理群組。以下是這兩種 ACS 部署案例的特色。

  • ACS 受生產管理群組主控的案例:

    • 擴充使用 ACS—由於 ACS 會從啟用 ACS 轉寄站的系統收集所有安全性事件,因此使用 ACS 可能會產生大量資料。除非提供專用硬體給 ACS 收集器和資料庫角色,否則處理這些資料可能會降低主控管理群組的效能,特別是在資料庫層。

    • 不需要另外的系統管理和安全性—由於 ACS 受管理群組主控,因此在管理群組中具有系統管理控制權的人員,在 ACS 中也將擁有系統管理權限。如果根據商業、法規/稽核以及 IT 需求,ACS 必須在非生產 IT 控制之下,則將 ACS 部署到生產管理群組的案例就不在考慮之列。

  • ACS 受專用管理群組主控的案例:

    • 需要另外的系統管理和安全性—如果另有系統管理群組負責公司的稽核和安全性控制,建議受專用管理群組主控的 ACS 由稽核/安全性群組管理。

第二項必須進行的決策是,是否要將 ACS 報表部署至與 Operations Manager 2007 報表元件相同的 SQL Server 2005 Reporting Services 執行個體。以下是這兩種案例的特色。

  • ACS 報表與 Operations Manager 報表整合:

    • 所有報表均使用單一主控台—當 ACS 報表與 Operations Manager 報表一起安裝時,ACS 報表是透過 Operations Manager Operations 主控台存取的。

    • 通用安全性模型—當 Operations Manager 2007 報表安裝到 SQL Server 2005 Reporting Services 時,它會覆寫預設安全性模型,以 Operations Manager 角色型安全性模型取代之。ACS 報表與此模型相容。被指派報表操作員角色的所有使用者只要同時具有 ACS 資料庫的所需權限,就能夠存取 ACS 報表。

    note附註
    如果稍後解除安裝 Operations Manager 報表,您必須使用安裝媒體的 SupportTools 目錄中的 ResetSRS.exe 公用程式,手動還原原始的 SRS 安全性模型。

  • ACS 報表安裝在專用 SQL Server Reporting Services 執行個體:

    • ACS 和 Operations Manager 報表使用不同的主控台—安裝在專用 SRS 執行個體時,ACS 報表是透過安裝時建立的 SRS 網站存取的。這可讓您更有彈性地設定資料夾結構和使用 SRS 報表設計工具。

    • 不同的安全性模型—由於使用專用 SRS 執行個體,您可以視商業和 IT 需求建立安全性角色,以控制 ACS 報表的存取。請注意,您仍然必須授與 ACS 資料庫的必要權限。

第三項必須進行的設計決策是要部署多少 ACS 收集器/資料庫組來支援環境。單一 ACS 收集器/資料庫組可支援持續事件收集和插入的速率並非絕對的數字。此速率會視資料庫伺服器所連接的儲存子系統的效能而定。例如,低階 SAN 解決方案通常可支援每秒最多 2,500 至 3,000 個安全性事件。但 ACS 收集器卻不限於此,根據觀察,每秒可支援高達 20,000 個安全性事件。以下是影響每秒產生之安全性事件數的因素:

  • 稽核原則設定—稽核原則越嚴格,受稽核機器產生的安全性事件數量就越多。

  • 啟用 ACS 轉寄站之機器的角色,根據預設稽核原則,網域控制站會產生最多安全性事件。成員伺服器次多,工作站最少。

 

機器角色 高負載情況下每秒產生之未篩選安全性事件的估計數字

Windows Server 2003 網域控制站

每秒 40 個事件

Windows Server 2003 成員伺服器

每秒 2 個事件

工作站

每秒 0.2 個事件

  • 使用上表的估計數字,單一高階 ACS 收集器/資料庫組可支援多達 150 個網域控制站、3,000 個成員伺服器或 20,000 個工作站 (需套用適當的 ACS 收集器篩選器)。

  • 網路上的使用者活動量—如果網路是由執行大量交易的高階使用者所使用,如 Microsoft 內部的情況,就會產生較多的事件。如果網路使用者執行的交易相對較少,例如像是零售點或倉庫等情況,安全性事件應該會較少。

  • ACS 收集器篩選器設定—ACS 會從受監視機器的安全性事件記錄檔收集所有安全性事件。在收集到的所有事件當中,您可能只對其中一部分的事件有興趣。ACS 能夠讓您篩選掉不需要的事件,只有需要的事件才會經由收集器處理,然後插入到 ACS 資料庫。隨著篩選的數量增加,處理和插入 ACS 資料庫的事件將變少。

最後一項必須進行的設計決策是 ACS 資料庫要使用的 SQL Server 2005 或 SQL Server 2008 版本。ACS 支援使用 SQL Server 2005 Standard 版本和 SQL Server 2005 Enterprise 版本或 SQL Server 2008 Standard 或 Enterprise 版本。使用哪種版本,將對系統在日常資料庫維護期間的行為造成影響。維護期間,時間戳記不在資料保留排程 (資料保留時間通常設定為 14 天) 的資料庫分割將從資料庫卸除。如果使用 SQL Server Standard 版本,安全性事件插入會暫停,事件將排入 ACS 收集器上的佇列,直到維護完成。如果使用 SQL Server Enterprise 版本,會繼續插入已處理的安全性事件,但速率只有一般速率的 30% 至 40%。這是為什麼您應謹慎挑選日常資料庫維護時間的原因之一,請選擇網路上的使用者和應用程式活動最少的時間。

調整稽核收集服務規模

本節可協助您判斷需要的磁碟、ACS 收集器及 ACS 資料庫數量,藉此在部署 ACS 硬體元件之前先行調整其規模。

Important重要事項
若要有效地的調整 ACS 的規模,您必須判斷 ACS 磁碟 I/O 所需的磁碟數量和 ACS 資料庫大小。這些值的計算程序詳細記載於<調整 ACS 大小>一節。每個 ACS 收集器必須具有專屬的 ACS 資料庫。單一 ACS 收集器的能力取決於資料插入資料庫的速率,而此速率則取決於儲存子系統的效能。單一磁碟陣列能支援的磁碟越多,ACS 收集器的效能也越好。

Tip秘訣
ACS 支援使用 SQL Server 2005 Standard Edition 和 SQL Server 2005 Enterprise Edition,然而您使用的版本會影響日常資料庫維護期間的系統效能。在資料庫維護期間,時間戳記超出 14 天預設資料保留排程的資料庫分割將從資料庫卸除。如果使用 SQL Server 2005 Standard Edition,安全性事件插入會暫停,而且事件將排入 ACS 收集器中的佇列,直到維護完成。如果使用 SQL Server 2005 Enterprise Edition,安全性事件插入仍會繼續進行,但速率只有一般速率的 30% 至 40%。因此,您應該謹慎挑選日常資料庫維護的時間範圍,並選取網路中使用者活動和應用程式活動最少的時間。

調整 ACS 大小

ACS 收集器的數量、ACS 資料庫的大小調整及資料庫磁碟子系統的大小調整完全取決於轉寄到資料庫的安全性事件數量 (每秒測量到的事件數量)。執行 ACS 大小調整計算可產生三項結果:

  1. 需要的 ACS 收集器數量

  2. 需要幫資料庫配置的空間大小

  3. 用來支援預期之資料庫輸送量所需的磁碟數量

在理想狀況下,您可以安裝試驗的 ACS 收集器來測量傳入的事件速率,藉此判斷組織中電腦產生的安全性事件數量。如果您有試驗的 ACS 收集器,便能監視 ACS Collector\Incoming Event per Sec 效能監視計數器。不過,如果您沒有試驗的 ACS 收集器,則能使用下文中的調整大小指導方針和指令碼範例來產生類似的結果。

請遵循下列程序利用每秒產生的事件數指令碼來測量組織中所有電腦每秒產生的事件數量。判斷出事件數量後,您便可以使用此數字來計算處理 I/O 需要的磁碟數量及 ACS 資料庫大小總計,如後續各小節所述。

預估所有電腦每秒產生的事件數量

  1. 識別執行類似功能的電腦群組 (例如,網域控制站、成員伺服器及桌上型電腦)。

  2. 針對組織中的所有電腦,計算每個群組中的電腦數量。

  3. 在每個群組的至少一台電腦上執行每秒產生的事件數指令碼一節中的指令碼範例,並持續執行 48 小時以便記錄資料。執行指令碼的電腦即代表所屬群組中的所有電腦。

  4. 將資料記錄在試算表中以供彙總及分析之用。

  5. 根據收集到的資料,識別使用率達到尖峰的時間。

  6. 對於每部用來收集資料的電腦,先判斷使用率尖峰期每秒發生的事件數量,然後再將該數值乘以該電腦代表之群組中的電腦數量。請針對每個群組重複此步驟。

  7. 將上一個步驟得出的值加總在一起,以判斷組織中所有電腦每秒產生的事件數量。

    在以下各節中,您將使用這個總值來計算處理 I/O 所需的磁碟數量和 ACS 資料庫的大小總計。

計算處理 I/O 所需的磁碟數量根據 Microsoft 執行的測試,對於 ACS 資料庫記錄,每個事件預估的平均邏輯磁碟 I/O 數為 1.384,而 ACS 資料庫則為 0.138。不過,這些值可能會因為環境不同而有些微差異。本測試假設每分鐘的磁碟轉數 (RPM) 和邏輯磁碟 I/O 之間的比率為 1:1,並且使用 RAID 0+1 設定。

您可以使用以下公式來計算處理 I/O 所需的磁碟數量。

記錄磁碟機:

[交易記錄檔每個事件的平均磁碟 I/O數] * [所有電腦每秒的事件數] / [磁碟 RPM] * 60 秒/分鐘 = [需要的磁碟機數] * 2 (用於 RAID 1)

上述變數的值請見下表。

 

變數

交易記錄檔每個事件的平均邏輯磁碟 I/O 數

1.384

所有電腦每秒的預估事件數

使用指令碼和「預估所有電腦每秒產生的事件數量」程序進行預估

磁碟 RPM

因磁碟裝置而異

資料庫磁碟機:

[資料庫檔案每個事件的平均磁碟 I/O數] * [所有電腦每秒的事件數] / [磁碟機 RPM] * 60 秒/分鐘 = [需要的磁碟機數] * 2 (用於 RAID 1)

上述變數的值請見下表。

 

變數

資料庫檔案每個事件的平均邏輯磁碟 I/O 數

0.138

所有電腦每秒的預估事件數

使用指令碼和「預估所有電腦每秒產生的事件數量」程序進行預估

磁碟 RPM

因磁碟裝置而異

如果處理事件 I/O 所需的磁碟數超出磁碟陣列能容納的磁碟數,您便需要將事件分派到多個收集器。

計算 ACS 資料庫大小總計
若要判斷 ACS 資料庫的大小總計,請使用下列公式:

[所有電腦每秒的事件數] * [0.4 KB (事件的大小)] * 60 秒 *60 分鐘 * 24 小時 /1024 MB /1024 GB /1024 TB * [保留期間 (將事件保存在資料庫的天數)] = 資料庫的大小總計

稽核收集服務指導方針和最佳作法

ACS 系統的整體效能主要受到 ACS 資料庫及其磁碟子系統的效能影響。假設每秒有數千個事件連續插入資料庫,再加上高峰期可能達到每秒數萬個事件,影響不言可喻。若有大量受監視裝置 (包括網域控制站),14 天累積在 ACS 資料庫的資料量很容易就會超過 1 個 TB。以下是針對 ACS 的一些最佳作法:

  • 針對收集器和 SQL Server 使用 64 位元硬體和作業系統,以及一套高效能 SAN 解決方案。

  • 將資料庫檔案與交易記錄檔分開來。

  • 在可能情況下,使用專用硬體來主控 ACS。

  • 使用條件嚴格的篩選器,減少干擾性安全性事件插入資料庫。

  • 謹慎規劃 Windows 稽核原則,只有相關的事件才會記錄到受監視的系統。

  • 只有在必要的系統上啟用 ACS 轉寄站。

  • 設定給安全性事件記錄檔足夠的空間,這樣一來,若與 ACS 收集器的通訊中斷,安全性事件記錄檔不會自動覆蓋來覆寫先前的事件,造成事件資料遺失。

 
顯示: