Defining System Redundancy

In addition to the scalability built in to OpsMgr, redundancy is built in to the components of the environment. Proper knowledge of how to deploy OpsMgr redundancy and place OpsMgr components correctly is important to the understanding of OpsMgr redundancy.

The main components of OpsMgr can be made redundant through the following methods:

• Management Servers—Management servers are automatically redundant and agents failover and failback automatically between them. Simply install additional management servers for redundancy. In addition, the Root Management Server (RMS) acts as a management server and participates in the fault tolerance.

• SQL databases—The SQL database servers hosting the databases can be made redundant using SQL clustering, which is based on Windows clustering. This supports failover and failback.

• Root Management Server—The RMS can be made redundant using Windows clustering. This supports failover and failback.

Having multiple management servers deployed across a management group enables an environment to achieve a certain level of redundancy. If a single management server experiences downtime, another management server within the management group takes over the responsibilities for the monitored servers in the environment. For this reason, it might be wise to include multiple management servers in an environment to achieve a certain level of redundancy if high uptime is a priority.

The first management server in the management group is called the Root Management Server. Only one RMS can exist in a management group, and it hosts the SDK and Configuration service. All OpsMgr consoles communicate with the management server, so its availability is critical. In large-scale environments, the RMS should leverage Microsoft Cluster technology to provide high availability for this component.