If you are familiar with implementing OpsMgr, you have probably dealt with failover and DRP scenarios.
In OpsMgr you have several options to DRP: SQL replication, SQL cluster , SCOM cluster and SQL log shipping. generally I prefer log-shipping.
The idea behind log-shipping is to install a SCOM hierarchy with two (or more) servers: one is of course is the RMS and the others are MS.
In the case of a failure we stop the services on the RMS server and change the active DB. some scenarios may ask you to activate the SQL standby database and reverse the log-shipping.
Going through this procedure can be quite intimidating (there are plenty of space for mistakes) you will need to change setting in the registry, run SQL script maybe change some DNS or NLB settings or run some command lines.
Now for a little confession, recently I started working with Opalis (I had done several POC’s with it and love it ) the product is flexible ,allows changes and custom code to be run. (you can run a .NET script, trigger DLL . for me WOW!)
I was sitting in my office thinking about things that can be done with Opalis. me and my colleagues have talked several times about using Opalis as a failover tool for SCOM, so I have decided to create a policy to handle failover OpsMgr servers…
here is what I done:
Let’s take a look at the main policy (the main workflow):
In order to achieve successful transfer between the servers we need to perform the following tasks:
1) Stop the Operations Manager services on the RMS and MS – this will stop the application from writing data to the database, making sure that we do not loss data during the transfer.
2) Start a log shipping cycle
3) Perform a restore with no recovery to the target database in order to take it out of standby mode.
4) Run a script (we will talk latter about why we need to do it with a script) to change registry settings so that the RMS and MS will know the new database’s location.
5) Run a SQL script to change the active database.
6) Disable all SQL replication jobs from the RMS to the MS.
7) Reverse the log shipping direction so we could return the role back to the RMS if we need to.
8) Run command line to let the MS know that it is now RMS.
In Part 2 I will start a deep-dive into the tasks, explaining how I have implemented each and every one.