MicroStrategy - Disastar Recovery

MicroStrategy - Disastar Recovery

MicroStrategy provides clustering mechanism for HA. But that does not safegaurd your BI system. And it always need some additional care to make sure your BI system is available or at least you can recover the system to a stable state in a short period of time.  This is quiet a generic statement, the "short time" depends on your business decision, its can be half an hour to days.. How critical is it to have this system back online, is also another business question you should consider beforing planning an disaster recovery.  You will however need to adopt additional process to safe gaurd your system.

How do we get started :-

You will fist need to identify the failure points. And then take appropriate measures to handle those situations. This is the findemental of a disastar recovery plan.

Possible failure points:-

• Intelligence Server
• Web Server
• Network
• Database (WH)
• Database (MetaData)

You can generally classify service failure into two 1. System Failure, 2. Software failure.  The procedures to follow for these two kinds of failure are different. In case of a hardware failure, you are will need to find a new hardware and restore your system, where as in case of software failure you will need to start troubleshooting and initiate recovery process.

Hardware Failure :-

If your hard disk is good, you can find an alternate server and swap the hard disk. However if the hard disk has failed, then you will need to rebuild the system. Rebuilding a system is a major process and almost all companies have some standard way of doing it. Some might use PXE boot and other might even have a even more simple process like doing an update on a web page.

The fastest way to restore your Intelligence Server is to  archive the Microstrategy folders, Cache folder, and your Inbox (history list), tnsnames.ora, third party library (if you use)  and then untar it on the new system. That will need you keep a latest copy of the files in an archive format. You can use tar command in linux for doing that.

The same goes principle goes for your web server, if you are using apache tomcat.  Just keep a archive of the apache install directory. Untar it on the new system and you are ready to go. Provided you have dependecies like java installed on the new system. The other dependencies like java will be installed as part of OS reimage. Hence you dont need to take backup of these binaries in your archive.

The process to restore the system is simple and easy, Ofcourse if you have planned for it.

Restore Process :-

• IServer
• backup the following directories using tar
• MSTR installation directory
• Cache and Inbox
• tnsnames.ora referenced in your odbc.ini file
• Web Server (apache tomcat)
• Backup the entire install directory  excluding the workdir and logs
• Reimage a new hardware with the same OS image used for IS and Web server
• Copy the archive files to the new server and untar it.
• If you are just replacing the broken hardware with the newer one, this is all you will need to do.
• In case if you moving to a new system, and there is change in hostname, you will need to reconfigure the web and other changes might be needed.

Software Failure:-

Here you have an option to migrate the services to another server. This concept is called cluster. MSTR supports clustering of upto four Intelligence Server.  You can configure the cluster to work as load balancing or for high availability. MSTR will take care of migrating the project to another server in case one node fails.

Generally production environment is built like this. Iservers run on linux, and web servers run on apache tomcat on a linux system. You can either cluster two tomcat server. Or run them as independent server and add a vip and load balance using the load balancer. The load balancer will detect if there is a server failure and reroute the request to the other node.

Colo Failure:-

How do we safegaurd from a colo failure. It's not extremely rare to see a colo outage, imagine if the backbone and backup backbone for outgoing connection fails, your colo is unaccessible. The way to safegaurd from such a failure is totally different from the above two scenarios. You need to have greater budget, since it not only involves building a replica of the BI systems, but also your data warehouse. Remember all your data is coming from the WH and if the WH is residing in the colo which is considered as failed.

Build a similar system in the backup location and let it be online. If your BI URL is x.company.com, you can name your backup BI as xbackup.company.com. Make sure your backup BI is working fine. Now the most important factor is , dont let users know about the backup URL. Secondly apply all the productin changes to backup systesm, like hotfix, plugin, configuration changes etc. When the primary fails, just make a DNS change and point your primary URL to the backup. Users might see a small lag due to colo change, but thats usually negligable. You can create your own system to monitor the primary url and do this failover automatic. You can include your business rules on when to do a failover and how many reattempts to make before you do a  failover.