高可用性和災害復原
System Center – Operations Manager 伺服器和功能可能會失敗，因而影響 Operations Manager 功能。 故障期間遺失的資料量和喪失的功能，會因每個故障案例而異。 這取決於失敗功能的角色，以及復原失敗功能所需的時間長度。
高可用性
高可用性需求可藉由將備援建置至 Operations Manager 作業和數據倉儲資料庫的管理群組、網關和管理伺服器，以及特定工作負載來解決。 這些工作負載包括網路裝置監視、跨平台監視，以及先前由根管理伺服器所管理的管理群組特定工作負載。
多部伺服器、單一管理群組組態可以使用 SQL Server Always On 來提供 Operations Manager 資料庫的高可用性和服務持續性。 管理伺服器容錯是由至少有兩部管理伺服器，以及使用資源集區來監視 UNIX 伺服器、Linux 伺服器和網路裝置來提供。 代理程式型 Windows 伺服器可以設定為主要和次要管理伺服器，以在管理伺服器失敗時重新導向代理程序通訊。
RMS 模擬器也可以移至另一部管理伺服器，如果裝載 RMS 模擬器的管理伺服器變得無法使用。
Operations 控制台連線可藉由設定數據存取服務的高可用性來提供高可用性。 這可以藉由安裝Microsoft網路負載平衡 （NLB） 或使用硬體型負載平衡器或 DNS 別名來完成。 一或多個管理伺服器會新增為 NLB 集區的成員，並在開啟其中一個控制台時，參考負載平衡管理伺服器的 DNS 中註冊的虛擬名稱。
注意
Operations Manager Web 主控台伺服器不支援網路負載平衡器。
您可跨越信任界限部署多個閘道伺服器，為跨越信任界限的代理程式提供備援路徑。 如同代理程式可在主要管理伺服器和一或多個次要管理伺服器之間容錯移轉，代理程式也可以在閘道伺服器之間容錯移轉。 此外，也可使用多個閘道伺服器來分散管理無代理程式管理的電腦和受管理的網路裝置的工作負載。
除了提供代理程式-閘道容錯移轉的備援之外，如果有多台管理伺服器可用，也可將閘道伺服器設定為在管理群組中的管理伺服器間容錯移轉。
雖然 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） 的一部分。 AlwaysOn 可用性群組的次要複本會位於非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 數據存取、System Center 組態管理和Microsoft監視代理程式服務應該停止，並設定為手動或停用，且只在災害復原案例中啟動。
如果管理伺服器支援整合（透過直接裝載在管理伺服器上或從 VMM、Orchestrator 或 Service Manager 等其他 System Center 產品所裝載的連接器），則必須根據整合組態和復原步驟順序，規劃使用手動或自動復原步驟。 這可確保在需要實作災害復原計劃時擷取和管理伺服器上的任何其他相依性。
如果某個月台離線，代理程式將會故障轉移至另一個站台中的管理伺服器，假設代理程式的故障轉移設定允許此設定。 重新設定 Windows 代理程式，只快取主要數據中心的管理伺服器，以管理伺服器，以防止它們嘗試故障轉移至次要數據中心的管理伺服器，這隻會延遲復原和報告。 如果您使用腳本以自動化方式部署代理程式（例如 VBScript 或更好的版本，PowerShell）在安裝期間進行預先設定，或者，如果您從控制台推送代理程式，請在部署后再次使用以企業組態管理解決方案管理的腳本方法，再次完成此作業。
Operations Manager 可以部署在 Azure 虛擬機上作為替代災害復原選項，以維護管理群組的持續性。 此外，也必須在 Azure 中的虛擬機上部署 SQL Server，而不是在混合式設定中，因為管理伺服器與裝載 Operations Manager 資料庫的 SQL Server 之間的延遲將對管理群組的效能產生負面影響。
請考慮監視範圍、網路拓撲和網路連線至 Microsoft Azure（也就是站對站 VPN 或 ExpressRoute）、整合點（也就是 ITSM 解決方案、其他 System Center 產品、第三部分附加元件等等）、控制台存取、法規或相關法律或原則等等，以在 Azure IaaS 或其他公用雲端提供者內正確架構此案例。