高可用性與災害復原

重要

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

System Center – Operations Manager 伺服器和功能可能會失敗，而影響 Operations Manager 功能。 故障期間遺失的資料量和喪失的功能，會因每個故障案例而異。 這取決於失敗功能的角色，以及復原失敗功能所需的時間長度。

高可用性

高可用性需求的解決方式是，在 Operations Manager 操作和資料倉儲資料庫的管理群組、閘道和管理伺服器，以及特定工作負載中建置備援。 這些工作負載包括網路裝置監視、跨平台監視，以及先前由 Root Management Server 所管理的管理群組特定工作負載。

多部伺服器的單一管理群組設定可利用 SQL Server Always On，來提供 Operations Manager 資料庫的高可用性和服務持續性。 若要提供管理伺服器容錯，至少要有兩部管理伺服器，並使用資源集區監視 UNIX 伺服器、Linux 伺服器和網路裝置。 您可以使用主要及次要管理伺服器來設定代理程式型 Windows 伺服器，以便在管理伺服器失敗時，重新導向代理程式通訊。

如果裝載 RMS 模擬器的管理伺服器變成無法使用，RMS 模擬器也可以移到另一部管理伺服器。

您可以為資料存取服務設定高可用性，以將 Operations 主控台連線設為高可用性。 這可藉由安裝 Microsoft 網路負載平衡 (NLB) 或使用硬體型負載平衡器或 DNS 別名來完成。 系統會將一或多部管理伺服器新增為 NLB 集區的成員，因此在開啟任一主控台時，您會參考在 DNS 中登錄的負載平衡管理伺服器虛擬名稱。

注意

Operations Manager Web 控制台伺服器不支援網路 Load Balancer。

您可跨越信任界限部署多個閘道伺服器，為跨越信任界限的代理程式提供備援路徑。 如同代理程式可在主要管理伺服器和一或多個次要管理伺服器之間容錯移轉，代理程式也可以在閘道伺服器之間容錯移轉。 此外，也可使用多個閘道伺服器來分散管理無代理程式管理的電腦和受管理的網路裝置的工作負載。

除了提供代理程式-閘道容錯移轉的備援之外，如果有多台管理伺服器可用，也可將閘道伺服器設定為在管理群組中的管理伺服器間容錯移轉。

雖然 SQL Server Reporting Services 支援向外延展部署模型，可讓您執行多個共用單一報表伺服器資料庫的報表伺服器實例，但 Operations Manager 不支援。 Operations Manager 報告會在前端元件的安裝過程中安裝自定義安全性延伸模組，而前端元件無法跨 Web 伺服器數位進行複寫。

災害復原

災害復原是一種相關採取措施，這些措施是為確保在發生重大故障 (例如，裝載主要基礎結構的整個資料中心中斷) 時可以繼續執行作業。 這是在任何部署中都必須考慮的重要元素，以及規劃災害復原時所做的決策會影響 Operations Manager 如何繼續支持主動監視和報告重要 IT 服務的效能和可用性。 本節將著重在嚴重損壞修復和復原的建議策略，以及為確保順利復原而應該採取的步驟。

雖然 HA 和 DR 解決方案會提供系統失敗或系統遺失的保護，但不應該依賴它們來保護意外、非預期或惡意的數據遺失或損毀。 在這些情況下，備份複製或延遲的復寫複寫複本可能必須用於還原作業。 在許多情況下，還原作業是最適當的 DR 形式。 其中一個範例可能是低優先順序的報表資料庫或分析資料。 在許多情況下，在系統或應用程式層級啟用多站台 DR 的成本遠遠超過資料的價值。 如果資料的近期價值不高，且在發生嚴重失敗或站台 DR 時可延遲存取資料而不會嚴重影響業務，則建議您為 DR 使用簡單的備份和還原程序以節省成本。

了解停機時間的影響及容錯能力有助於做出為正確設計 Operations Manager 的架構而必須了解的決策，以及支援嚴重損壞修復所需的複雜程度和成本。 此外，請考量在不造成業務影響的情況下 IT 組織可以承受的監視資料遺失範圍。 這最好用兩個術語來描述：復原時間目標 (RTO) 和復原點目標 (RPO)。

Operations Manager 兩個最常見的嚴重損壞修復設計設定為：

• 建立部署至次要數據中心的重複管理群組，以調整和設定主要管理群組。
• 在次要資料中心部署額外的伺服器以支援操作和資料倉儲資料庫，並在冷待命組態中部署管理伺服器，但不加入管理群組，直到必須執行復原動作為止。

當停機時間沒有容錯時，部署重複的管理群組是一個選項;不過，這是最複雜的選項。 這兩者之間的設定必須一致，如此一來，當您進行切換時，監視、警示或回報、呈現的內容和最終呈報沒有任何差異。 與其他監視平臺或 ITSM 平臺整合，例如 System Center - Service Manager、補救或 ServiceNow 也必須存在，而且可能設定為主動/被動狀態，以避免重複事件、設定專案等等。 代理程式在兩個管理群組之間將是多重主目錄的，因此將會有重複的資料。

下圖是此設計案例的範例。

如果您的 Operations Manager 部署不需要立即復原，而且您想要避免重複管理群組的複雜性，您也可以在次要數據中心部署其他管理群元件，以保留管理群組的功能。 至少請考慮實作 SQL Server 2014 或 2016 Always On 可用性群組，以便在兩個或多個資料中心之間復原操作和資料倉儲資料庫，其中兩個節點的容錯移轉叢集執行個體 (FCI) 是在主要資料中心部署，而獨立 SQL Server 則是在次要資料中心部署，做為單一 Windows Server 容錯移轉叢集 (WSFC) 的一部分。 Always On 可用性群組的次要複本將會在非 FCI 獨立執行個體上，如下圖所示。

在此範例中，您必須使用相同的硬體設定和電腦名稱部署一或多部 Windows Server，並使用 /Recover 參數，重新安裝管理伺服器角色。 以下是一個範例：

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

如需詳細資訊，請參閱 從命令提示字元安裝 Operations Manager。

在這段期間，代理程式會將所收集的數據排入佇列 (警示、事件、效能等) ，直到他們能夠繼續與管理群組中的管理伺服器通訊為止。 此方法可避免安裝新的 SQL Server 執行個體，並從您上次已知良好的備份還原資料庫。 不過，在此復原案例中，由於您必須部署繼續最低監視功能所需的其他角色，所以返回可操作狀態可能會有較長的延遲。 如果這個方法無法接受，您可以在次要資料中心部署管理伺服器以進行待命復原。 將這些管理伺服器以「所有管理伺服器資源集區」、「通知」和「AD 指派」這三個主要資源集區的成員形式移除。 這也包含任何自訂資源集區 (可能包括裝載於主要資料中心的管理伺服器)，且必須在復原計劃期間繼續運作。 System Center Data Access、System Center Configuration Management，以及 Microsoft Monitoring Agent 服務應該停止，並設定為手動或停用，而且僅在嚴重損壞修復案例中啟動。

如果管理伺服器支援透過直接裝載於管理伺服器上的連接器，或從 VMM、Orchestrator 或 Service Manager) 等其他 System Center 產品進行整合 (，則必須根據整合組態和復原步驟順序，規劃使用手動或自動復原步驟。 這可確保針對需要實作災害復原規劃的情況，徹底掌握管理伺服器的其他任何相依性，並加以規劃。

如果一個網站離線，代理程式將會容錯移轉至另一個網站中的管理伺服器，並假設代理程式的容錯移轉設定允許這個動作。 將 Windows 代理程式重新設定為僅快取主要資料中心內應該管理它們的管理伺服器，以防止它們嘗試容錯移轉至次要資料中心的管理伺服器 (該管理伺服器僅會延遲復原和報告)。 如果您使用腳本以自動化方式手動部署代理程式， (例如 VBScript 或更好的方式，PowerShell) 在安裝期間預先設定，或者如果您從控制台推送代理程式，請再次使用以企業組態管理解決方案管理的腳本方法進行預先設定，即可完成此作業。

您可以在 Azure 虛擬機器上部署 Operations Manager，做為維持管理群組持續性的替代嚴重損壞修復選項。 也必須在 Azure 中的虛擬機上部署 SQL Server，而不是在混合式組態中，因為管理伺服器與裝載 Operations Manager 資料庫 SQL Server 之間的延遲會對管理群組的效能造成負面影響。

請考慮監視範圍、網路拓撲和 Microsoft Azure (，也就是站對站 VPN 或 ExpressRoute) 、整合點 (，也就是 ITSM 解決方案、其他 System Center 產品、第三部分附加元件等等) 、控制台存取、法規或相關法律或原則等等，以在 Azure IaaS 或其他公用雲端提供者內適當地建構此案例。