規劃管理群組設計

重要

此版本的 Operations Manager 已終止支援。 我們建議您 升級至 Operations Manager 2022。

概觀

管理群組由單一操作資料庫、一或多部管理伺服器，以及一個或多個受監視的代理程式和裝置所組成。 連線管理群組允許從單一主控台檢視和編輯警示和其他監視資料。 您也可以從本機管理群組啟動工作，以便在已連線之管理群組的受管理物件上執行。

最簡單的 Operations Manager 實作是單一管理群組。 其他每個群組至少需要有自己的操作資料庫和管理伺服器。 每個群組也必須使用自己的組態設定、管理組件，以及與其他監視和 ITSM 解決方案的整合，個別維護。

分散式管理群組實作將構成 99 % Operations Manager 部署的基礎。 它可讓功能和服務散發到多部伺服器上，以提供延展性以及部分功能的備援。 它可以包含所有 Operations Manager 伺服器角色，並支援使用閘道伺服器跨信任界限監視裝置。

下圖代表分散式管理群組拓撲的其中一個可能選項。

注意

Operations 控制台與資料庫之間沒有直接通訊。 所有通訊都會透過 TCP 5724 連接埠，導向至特定管理伺服器，然後在設定 SQL Server 資料庫引擎執行個體期間，使用 TCP 1433 上的 OLE DB 或 SQL 系統管理員指定的使用者定義連接埠，導向至資料庫伺服器。 不過，應用程式診斷控制台 (與 Web 控制台共置) ，以及裝載作業和數據倉儲資料庫的 SQL Server 之間有直接通訊。

您在環境中部署的管理群組可以與 Microsoft Operations Management Suite (OMS) 整合，而且利用 Log Analytics，您可以進一步相互關聯、可視化及處理效能、事件和警示。 這讓您能夠跨整個數據集執行自定義搜尋，以便讓系統與應用程式之間、裝載於內部部署或雲端的數據相互關聯，以提升可見度。

Operations Manager 的整合可延伸到其他產品，例如 BMC Remedy、IBM Netcool 或組織所使用的其他企業管理解決方案。 如需有關如何使用這些解決方案規劃互通性的詳細資訊，請參閱與其他管理解決方案整合。

管理群組元件

管理伺服器

在 Operations Manager 2007 中，Root Management Server (RMS) 是管理群組中專業的管理伺服器類型，而且是管理群組中安裝的第一部管理伺服器。 RMS 是掌管管理群組設定、管理和與代理程式通訊，以及與管理群組中操作資料庫和其他資料庫通訊的焦點。 RMS 也提供做為 Operations 主控台的目標，以及 Web 主控台的慣用目標。 在 System Center 2012 R2 – Operations Manager 中，Root Management Server 角色已移除，而且所有管理伺服器現在都是對等。 此設定繼續存在於 System Center 2016 - Operations Manager 和更新版本中。

RMS 不再是單一失敗點，因為所有管理伺服器都會裝載先前僅由 RMS 裝載的服務。 角色會散發到所有管理伺服器。 如果其中一台管理伺服器無法使用，其負責的部分就會自動重新分配。 RMS 模擬器角色針對以 RMS 為目標的管理組件提供回溯相容性。 如果您沒有先前以 RMS 為目標的任何管理元件，則不需要使用 RMS 模擬器。

管理群組可包含多部管理伺服器，以提供額外的容量和不間斷的可用性。 當您將兩部或多部管理伺服器新增至管理群組時，管理伺服器便會自動成為三個預設資源集區的一部分，而工作量則會分散到集區的成員上。 若是自訂定義的資源集區，則要以手動方式新增成員。 當資源集區的成員失敗時，資源集區中的其他成員將會接管該成員的工作負載。 新增管理伺服器時，新的管理伺服器會自動從資源集區中的現有成員挑選一些工作。 檢閱 資源集區設計考慮 ，以深入瞭解其運作方式，以及影響設計計劃的建議。

如果因為任何原因而無法使用管理伺服器，依賴該管理伺服器的代理程式預設將會自動容錯移轉至另一部管理伺服器。 選取管理伺服器的數量和位置時，如果高可用性是必要條件，則應該考慮這個容錯移轉功能。

代理程式會連線至管理伺服器，以便與其他所有 Operations Manager 元件進行通訊。 管理伺服器所執行部分工作就是採用代理程式所傳送之操作資料，並將其插入至操作資料庫和資料倉儲的程序。

一般管理伺服器將處理大約 3,000 個代理程式。 實際的伺服器效能會根據所收集的操作資料量而有所不同，但是，即使有相當大量的操作資料，每部管理伺服器通常還是可以支援 3,000 個代理程式。

每個管理群組的管理伺服器數目上限沒有限制。 不過，在解決延展性、高可用性和災害復原限制之後，最好盡可能使用最少的管理伺服器。

管理伺服器與 Operations Manager 資料庫和資料倉儲之間應該具備量好的網路連線，因為它們經常會將大量資料傳送至這些存放區。 一般而言，這些 SQL Server 連線會耗用比較多的頻寬，而且對於網路延遲會比較敏感。 因此，所有管理伺服器都應該與操作資料庫和資料倉儲資料庫位於相同的區域網路，而且永遠不可部署到整個廣域網路。 管理伺服器與裝載 Operations Manager 資料庫的 SQL Server 執行個體之間的延遲應小於 10 毫秒。

閘道伺服器

Operations Manager 必須先在代理程式和管理伺服器之間執行相互驗證，彼此才能交換資訊。 為了保護兩者之間的驗證程序安全，程序會經過加密。 當代理程式與管理伺服器位於同一個 Active Directory 網域或已建立信任關係的不同 Active Directory 網域中，它們會使用 Active Directory 所提供的 Kerberos V5 驗證機制。 當代理程式和管理伺服器不在相同的信任界限內時，必須使用其他機制來滿足安全的相互驗證需求。

當防火牆將代理程式與管理伺服器分開，或代理程式位於個別不受信任的網域時，就會使用網關伺服器。 閘道伺服器是當做代理程式與管理伺服器之間的 Proxy。 如果沒有閘道伺服器，代理程式仍然可使用管理伺服器執行憑證驗證，但是必須核發 X.509 憑證並使用 MOMCertImport.exe 工具在每個代理程式上安裝 X.509 憑證，且每個代理程式都必須能夠透過防火牆存取管理伺服器。 如果代理程式與閘道伺服器位於相同網域中，或兩者位於一個受信任的網域中，則它們可以使用 Kerberos 驗證。 在此情況下，只有閘道伺服器與連線的管理伺服器將會需要憑證。 這包括監視在 Microsoft Azure 基礎結構即服務中執行的虛擬機， (IaaS) ，以及 Operations Manager (，也就是混合式雲端監視) 未加入支援 Operations Manager 管理群組的角色，或已在 Azure IaaS 中部署 Operations Manager， (具有 SQL Server 的虛擬機裝載操作資料庫和裝載管理伺服器角色的一或多部虛擬機) ，並監視不受信任的內部部署工作負載。

以下顯示的是監視 Azure IaaS 資源的範例 Operations Manager 部署。

以下是在 Azure IaaS 中裝載的 Operations Manager 部署範例。

通常閘道伺服器不會用於管理頻寬使用率，因為從代理程式傳送到管理伺服器的整體數據量與閘道伺服器是否使用類似。 網關伺服器的預定目的是減少管理不受信任網域中代理程序憑證所需的工作，並減少必須透過防火牆允許的通訊路徑數目。

• 每個閘道伺服器有超過 2,000 個代理程式可能會對復原的能力造成負面影響，以防發生持續性中斷，而使閘道伺服器無法與管理伺服器通訊。 如果需要超過 2,000 個代理程式，建議使用多部閘道伺服器。 或者，如果閘道伺服器復原時間是一個問題，就是測試系統，以確保閘道伺服器能夠在閘道伺服器與管理伺服器之間持續中斷之後，快速清空其佇列。 此外，閘道伺服器上的傳入佇列已滿之後，佇列中的資料會根據其優先順序遭到捨棄，也就是說，在此案例中，閘道伺服器持續中斷可能會導致資料遺失。
• 當大量代理程式透過閘道伺服器連線時，請考慮為所有閘道伺服器使用專用的管理伺服器。 讓所有閘道伺服器都連線到單一管理伺服器，而沒有連線到它的其他代理程式，在發生持續中斷時，可以加速復原時間。 管理伺服器上有效的負載是向管理伺服器直接報告或透過閘道伺服器報告的代理程式總數。
• 若要防止閘道伺服器起始與管理伺服器的通訊，包括設定為在多個管理伺服器之間故障轉移以取得高可用性，網關核准工具包含 /ManagementServerInitiatesConnection 命令行自變數。 在 DMZ 或其他網路環境中部署系統，而且通訊僅能從內部網路起始時，這可讓 Operations Manager 符合客戶的安全性原則。

Web 主控台伺服器

Web 主控台會提供管理群組的介面，此介面可透過網頁瀏覽器存取。 它沒有 Operations 控制台的完整功能，而且只能存取 [監視] 和 [我的工作區] 檢視。 Web 主控台可以存取屬於動作的所有監視資料和工作，而且這些動作可以針對受監視的電腦，從 Operations 主控台執行。 在 Web 主控台中存取資料與在 Operations 主控台中存取內容具有相同的限制。

報表伺服器

System Center - Operations Manager 的報告會安裝在您使用) 的 Operations Manager 版本支援的 SQL Server Reporting Services (上，而 Operations Manager 報表支援的唯一有效 Reporting Services 組態是原生模式。

注意

安裝 System Center - Operations Manager Reporting Services 時，可整合 SQL Reporting Services 執行個體的安全性與 Operations Manager 角色型安全性。 請勿在相同的 SQL Server 實例中安裝任何其他 Reporting Services 應用程式。

Operations Manager 報表伺服器元件可以安裝在執行 SQL Server 2014 或 2016 Reporting Services 的同一部伺服器或不同電腦上。 為了獲得最佳效能，特別是在具有大量、平行報表產生使用者的企業環境中，互動式或排程報表同時處理時，您必須相應增加，以處理更多並行使用者和較大的報表執行負載。 建議 Operations Manager 報表服務不會共置在裝載數據倉儲資料庫的相同 SQL Server，並安裝在專用系統上。

操作資料庫

操作資料庫是一種 SQL Server 資料庫，可保留管理群組的所有操作資料，組態資訊和監視規則。 Operations Manager 資料庫是管理群組的單一失敗來源，因此可以使用支援的叢集設定，讓它成為高可用性。

為了使這個資料庫維持一致的大小，Operations Manager 中的清理設定裡面的資料可以保留在其中的時間長度。 根據預設，這段期間是七 (7) 天。

報表資料倉儲資料庫

報表資料倉儲是一種 SQL Server 資料庫，可收集並儲存長期報表的操作資料。 此資料會從收集要報告之資料的規則，以及操作資料庫中的資料同步處理程序直接寫入。 資料倉儲的維護 (包括彙總、清理和最佳化) 是由 Operations Manager 自動執行。

下表會反白顯示預設資料類型，以及最初設定資料倉儲資料庫之後的保留期間。

資料集	彙總類型	保留期間 (以天為單位)
警示	Raw	400
用戶端監視	Raw	30
用戶端監視	每日	400
事件	Raw	100
效能	Raw	10
效能	每小時	400
效能	每日	400
狀態	Raw	180
狀態	每小時	400
狀態	每日	400

資料倉儲可能會提供多個管理群組。 這可讓單一報表併入整個組織所有電腦中的資料。

資料倉儲資料庫如同 Operations Manager 資料庫，可以針對高可用性而進行叢集處理。 如果未叢集，則應該仔細監視，以便快速解決任何問題。

ACS 收集器

ACS 收集器負責接收並處理從 ACS 轉寄站傳來的事件，再將此資料傳送到 ACS 資料庫。 此處理包括反組譯數據，使其可以分散到 ACS 資料庫中的數個數據表，將數據備援降至最低並套用篩選，讓不必要的事件不會新增至 ACS 資料庫。

ACS 資料庫

ACS 資料庫是一個中央存放庫，用來存放 ACS 部署中稽核原則所產生的事件。 ACS 資料庫可以與 ACS 收集器位在同一部電腦上，但為獲得最佳效能，應將兩者各自安裝在專用的伺服器上。 根據預設，資料會保留 14 天。

ACS 轉寄站

在 ACS 轉寄站上執行的服務包含在 Operations Manager 代理程式中。 此服務為預設安裝，但在 Operations Manager 代理程式安裝時尚未啟用。 您可以使用 [啟用稽核收集] 工作，或使用 PowerShell，一次對多部代理程式電腦啟用此服務。 啟用此服務後，所有的安全性事件將會傳送到 ACS 收集器和本機安全性記錄中。

設計考量

決定要實作單一還是多個管理群組時，應該將下列因素納入考量︰

• 增加的容量。 Operations Manager 對於單一管理群組可支援的代理程式數目沒有內建的限制。 根據您使用的硬體和管理群組的監視負載 (部署的管理組件越多表示監視負載越高) 而定，您可能需要多個管理群組，才能維持可接受的效能。
• 彙總檢視。 當多個管理群組用於監視環境時，需要有一個機制來提供其監視和警示資料的彙總檢視。 部署可存取其他所有管理群組中所有資料的額外管理群組 (不一定具備任何監視責任) 可以達到此目的。 這些管理群組則會被視為已連線。 用來提供資料的彙總檢視的管理群組稱為本機管理群組，而為本機管理群組提供資料的其他管理群組則稱為已連線的管理群組。
• 安全性和系統管理。 基於安全性和系統管理理由分割管理群組的概念類似於將系統管理授權單位委派給不同系統管理群組。 您的公司可能包含多個 IT 群組，各有其本身的責任區域。 此區域可能是特定的地理區域或業務部門。 例如，如果是控股公司，此區域可以是其中一個子公司。 雖然存在從集中式 IT 群組完整委派系統管理授權的這種類型，但是在每個區域實作管理群組結構可能比較實用。 接著，這些管理群組可以設定為位於集中式 IT 資料中心之本機管理群組的已連線的管理群組。
• 安裝的語言。 在其上安裝 Operations Manager 伺服器角色的所有伺服器都必須以相同的語言安裝。 也就是說，您無法使用英文版的 Operations Manager 2012 R2 來安裝管理伺服器，然後使用日文版本部署 Operations 控制台。 如果監視必須跨越多個語言，每個操作員語言將需要一個額外的管理群組。
• 生產與生產階段前功能。 在 Operations Manager 中，建議使用生產實作來監視生產應用程式，以及與生產環境進行最少互動的生產前實作。 在移轉至生產環境之前，生產階段前管理群組會用於測試和微調管理元件功能。 此外，有些公司會採用預備環境，供伺服器使用，其中新建置的伺服器在投入生產之前，會先置於調試期。 生產階段前管理群組可用來監視預備環境，以確保在生產推出之前伺服器的健康情況。
• 專用的 ACS 功能。 如果您的需求包括收集 Windows 稽核安全性記錄事件或 UNIX/Linux 安全性事件的需求，您將實作稽核收集服務 (ACS) 。 如果您公司的安全性需求規定 ACS 功能由非管理生產環境其餘部分的系統管理群組所控制和管理，實作專門支援 ACS 功能的管理群組可能會很有幫助。
• 嚴重損壞修復功能。 在 Operations Manager 中，與 Operations Manager 資料庫的所有互動都會先記錄在交易記錄檔內，再認可至資料庫。 這些事務歷史記錄可以傳送至執行 Microsoft SQL Server 的另一部伺服器，並認可至該處的 Operations Manager 資料庫複本。 此功能是在相同管理群組中兩部 SQL Server 之間提供 Operations Manager 操作資料庫備援的一個選項。 需要執行受控制的容錯移轉時，管理群組中的管理伺服器需要變更登錄，才能參考次要 SQL Server 並與其進行通訊。 您可以部署故障轉移管理群組，其符合主要管理群組 (管理元件、覆寫、通知訂閱、安全性 ) 等的確切組態，且代理程式會設定為向這兩個管理群組報告。 如果整個主要管理群組因故無法使用，則監視環境不會停機。 此解決方案可確保管理群組的服務能夠持續，而且不會遺漏任何操作監視。

在生產環境中部署 System Center Operations Manager 之前，請規劃管理群組的設計。 在規劃階段，瞭解 IT 服務元件 (，也就是基礎結構和應用層級) ，以及支援它們的系統和裝置數目、如何整合及支援您的事件和問題管理程式，以及如何將不同事件呈報支援層級、工程、服務取用者和管理的數據可視化。

已連線的管理群組

在多個地理位置都具備伺服器的許多企業都需要集中監視這些伺服器。 下圖所示的已連線的管理群組設定是一組專為建立階層式系統管理基礎結構而設計的工作流程。

此設定可以用於實現集中化監視。 其設計目的是要支援檢視警示和監視數據，以及針對已連線管理群組的 Managed 物件起始工作。

連線 Operations Manager 管理群組時，您可以維持管理群組集中監視功能，同時：

• 比使用單一管理群組監視更大量的管理物件。
• 根據邏輯業務單位 (如「行銷單位」) 或實體位置 (如羅馬) 來區隔監視活動。

當您連線管理群組時，您不會部署任何新的伺服器;相反地，您會允許本機管理群組存取連線管理群組中的警示和探索資訊。 如此一來，您就可以在單一 Operations 主控台中檢視和處理來自多個管理群組的所有警示和其他監視資料。 此外，您還可以在連線管理群組的受監視電腦上執行工作。 若要了解如何連接管理群組，請參閱在 Operations Manager 中連接管理群組。

安裝的語言

Operations Manager 管理群組只支援一種安裝的語言。 如果您需要監視的整體 IT 環境有多種安裝的語言，每種語言就需要獨立的管理群組。