John Joyner describes the RMS emulator role in System Center 2012 Operations Manager and its benefits in a disaster recovery scenario.
Operations Manager (OpsMgr) is the infrastructure monitoring engine in System Center, one of eight management products in the System Center 2012 suite. Visually, OpsMgr is the least changed member of the new System Center 2012 family, with a user interface (UI) little different from the current release, Operations Manager 2007 R2. Under the hood, there are a few significant changes in the new release, in particular how OpsMgr management servers are deployed and maintained. The most significant is perhaps the "removal of the RMS" in System Center 2012 Operations Manager.
Say goodbye to the RMS Cluster
In previous releases of OpsMgr, there was one key management server called the Root Management Server (RMS). The RMS services could only be made highly available by using Failover Clustering technology. The requirement to field a cluster for the RMS added cost and complexity to larger-scale and highly available OpsMgr deployments. (Not to mention wasted server capacity on the standby node of the RMS cluster.) Additionally, the RMS and/or RMS cluster constituted a single point of failure for the management group.
The architectural bottlenecks and weaknesses of the RMS are substantially addressed in the System Center 2012 Operations Manager release. OpsMgr will now utilize a pool of co-equal management servers for almost all functions previously performed by only the RMS. However, one management server in the pool is still flagged for the RMS emulator (RMSE) role and some management pack functions may still be single-threaded through the RMSE. Which functions — that will depend on the RMSE role — vary according to the application management packs imported to your management group.
What the RMS emulator does
It's important to understand what the RMS emulator does, so that you can architect your System Center 2012 Operations Manager management group correctly. In summary, the RMSE runs management pack functions specifically targeted to the Root Management Server class. These may be classified as "legacy" management packs, because newer management packs will not target the RMS class. In order to not break existing management packs that target the RMS specifically, the RMS emulator class and role were created in System Center 2012 OpsMgr.
Although only a few management packs do target the RMS class directly today, in any particular environment, business critical management packs from other Microsoft teams and third-party vendors could be in the "legacy" category, and thereby have a dependence on the OpsMgr management server running the RMSE role. To see which discoveries, monitors, rules and tasks target the RMS class, filter on the text "root management server" in management pack object views in the Authoring space of the OpsMgr 2007 R2 console. Importing the same management packs into System Center 2012 OpsMgr will target those management pack objects to the RMS emulator class.
System Center 2012 OpsMgr console, Authoring space: Discoveries targeted at the RMS emulator (click to enlarge).Figure A shows that even a System Center 2012 OpsMgr management group running current management packs may have some objects, such as discoveries for Hyper-V guest computers and Active Directory (AD) topology, targeted to the RMSE class. In the event of failure and/or permanent loss of the RMSE, management pack functions targeting the RMSE will stop working until you promote a surviving management server to RMSE, which is fast and simple to do using PowerShell. This assumes your management group has at least two management servers, the minimum number necessary to have fault tolerance in the RMSE role.
To assess the importance of the RMSE role to a prospective System Center 2012 OpsMgr deployment: identify and evaluate the management pack objects in your current OpsMgr 2007 R2 environment that are targeted to the Root Management Server class. If the product teams or vendors involved do not release updated management packs, the same RMS targeting will occur in System Center 2012 OpsMgr. Alternatively, in a lab or demo deployment of System Center 2012 OpsMgr, import the latest version of all management packs you intend to run in production on the new version of OpsMgr, and evaluate the management pack objects targeted to the Root Management Server Emulator class.
Recovery from disaster
A large benefit of System Center 2012 OpsMgr is freedom from having to deploy cluster services to achieve a highly available RMS. In the event you lose the management server running the RMS emulator role, expect to follow disaster recovery (DR) steps similar to these:
- Promote another management server to the RMS emulator role using PowerShell. Here are the two PowerShell commands to be run to designate a management server as the RMSE:
$MS = get-SCOMManagementServer -Name <FQDN of Management Server>
- Install a new Windows Server operating system on a computer with the same name and IP address as the original RMS emulator.
- Delete the failed management server name from the Management Servers list in the OpsMgr console Administration space. (You can't join the rebuilt management server to the management group without performing this step.)
- Install the OpsMgr management server role on the rebuilt computer, following the procedure to install an additional management server to the management group.
- Promote the original RMS emulator back into that role using PowerShell as in step 1.
Acknowledgements, to learn more
Cameron Fuller @ System Center Central: http://www.systemcentercentral.com/BlogDetails/tabid/143/IndexID/91085/Default.aspx