Clustering MicroStrategy Intelligence Servers - How To

Why do we need clustering?

A computer cluster is primarily more then two similar computers working together to serve a single purpose providing more performance and availability to the user. The computers in a cluster are generally linked together on a LAN but they can be geographically apart systems as well. The clustering technique enables a system to provide a number of benefits to the system. Although the importance of each benefit may vary per organization basis but in our opinion the "High Availability" of the system is at the fore front.

Test Environment for this post

Before I jump into the details of how to go about clustering the intelligence server, I will explain the test environment that I have set up for the clustering experiment.

I have three MicroStrategy 9.x installations running on virtual machines. Two virtual machines host only the intelligence server (named MSTR_IS1 & MSTR_IS2) while the third one (MSTR_IS3_WS) hosts the intelligent server as well as the Web Server + MicroSrategy Web. All machines are pointing towards their own tutorial metadata and are functioning in isolation.

I will perform the necessary configuration to cluster the three Intelligence Servers and then test the configuration through Web & Desktop access.

Preparing your environment for Clustering

There are a number of configurations that should be performed before multiple Intelligent servers are clustered. I am saying "should be performed" because MicroStrategy will not impose these configurations as a prerequisite to clustering. Lets walk through each configuration.

All Intelligent Servers point to a single Metadata

All intelligent servers that are to be made part of the cluster must be configured to point to the same metadata. A single metadata is required so that a consistent picture of the project is portrayed to the user and the state can be shared between multiple intelligent servers.

I have moved the tutorial metadata to a PostgreSQL database server and have updated all Intelligence Servers' metadata connections to point towards the PostgreSQL server. So now I have three independently running Intelligence Servers but pointing to same metadata.

I believe that rather then having all intelligent servers pointing to a single metadata database it may be possible to have instances of metadata hosted on different database servers and synced in real time. But more about that in a later post.

Report Cache sharing needs to be configured

Report caches are utilized by Intelligent Server to send back results of already executed reports rather then re-sending SQL to the Data warehouse. In a single Intelligent Server environment the report cache is stored locally on the machine running the Intelligent Server, but in case of a clustered environment the cache must be shared across the intelligent servers so that all cache requests execute successfully and return consistent data. There are two options to report cache sharing.

History Files sharing needs to be configured

Cluster Configuration

Now that our environment is ready for clustering lets perform the actual clustering configuration which is a straight forward process.

Join Cluster for Intelligence Server

For joining your Intelligent Servers to the cluster open up MicroStrategy Desktop and connect to the first Intelligent Server. Under the "Administration>System Administration" Node select "Cluster Node". In the right pane you should be able to see your current Intelligent Server name. I right clicked and selected Join Cluster.

I typed in the name(you can also type the IP) of the target intelligence server which in my case was MSTR1.



Clicking OK displays the following screen which describes which intelligent servers are part of the cluster. I repeated the process for my third intelligent server as well thus adding MSTR1, MSTR2 & MSTR3 to the cluster.

Prior to getting the success screen there was an instance where I got the following error which basically highlighted that their is a compatibility mismatch with the target server.

I was surprised because both servers had same configurations. The only thing was that MSTR2 installation was not restarted after activation. Sure enough after restarting the process worked like a charm.

Configuring MicroStrategy Web for the clustered Intelligence Servers

Now that my intelligent servers were clustered, it was time to let my web server know about the intelligent server cluster. For that I navigated to MicroStrategy Web Administrator for adding the intelligence servers to the web. The MicroStrategy Web Administrator showed that none of the servers are connected. So I typed in the IP of the first intelligence server (aka MSTR1) and clicked Add.

Which takes the screen to the connection properties screen. I made sure that I had selected "Automatically connect to Intelligence Server......" so that when ever any of intelligence server or web server went down they auto connected on coming back live.

Interestingly when intelligence servers are clustered adding one of the intelligence server to the web automatically adds others as well (or this is what happened in my case). So once I clicked OK I was able to see all the intelligence servers connected to the web.

Now it was time to login into the MicroStrategy environment and take a look at the projects. I logged into to see two different MicroStrategy Tutorial projects which was not what I expected. It appeared that one of the intelligence server was not added to the cluster.

After adding MSTR2 to the cluster again I was able to see a single project which should be the intended behavior.

A Quick Test

So now that the environment was clustered and running satisfactorily it was time to run a quick test to see clustering in action. So I logged onto the Web, executed a report and killed the intelligence server on which the report was running. Well to be honest I was slightly disappointed as the MicroStrategy Web displayed the following where as I was expecting a seamless transfer to the next available Intelligence Server and re-execution of the report.

Not so, because the current executing report returns an error and subsequently takes you to a session lost page. But with-in a minute (should be less then a second I guess if I were using actual server machines) I was able to click home and login to the project again with out providing my credentials.