How to Cluster MicroStrategy Intelligence Server? - Part 2

 
This is second part of a 2 part blog post series on MicroStrategy Intelligence Server Clustering. In the first part we had looked at his what clustering is and how it works. In this part we would see how clustering is done.







Prerequisites for clustering I Servers

MicroStrategy prerequisites


  • MicroStrategy Intelligence Server license allowing clustering
  • Same version of I Server to be installed on all servers to be clustered
  • MicroStrategy projects on the clustered machines must be based on the same metadata
  • At least one project must be defined on the metadata
  • Any projects to be used by the cluster must be set to load at start-up
  • More than one I Server should not run on the same machine
  • Account on which I Server is running must have full control of cache and History list folders on all nodes
  • Same version of I Server to be installed on all servers to be clustered
  • Same I Server governance settings on both servers
  • MSTR Desktop on Windows machine to administer the cluster
  • Access to Cluster view of System Administration monitor in MSTR Desktop. Administration privilege to create a cluster
  • The computers to be clustered must have the same intra-cluster communication settings
  • The same caching method to be used for both result caches and file based History lists

Server prerequisites


  • Machines to be clustered must have the same version of OS
  • Identical hardware to be used for each node (for each of Load Balancing and System Configuration)
  • All nodes need to have their clocks synchronized
  • RDBMS containing warehouse and metadata must be on separate machines than the I Server
  • Machines to be clustered must use the same metadata repository
  • The required DSNs must be created and configured for I Server on both machines
  • Data Source Names (DSNs) pointing to the databases, both metadata and warehouse, must be created on all nodes with identical names for the DSNs

UNIX/LINUX prerequisites


  • All servers in a cluster must use the same server definition
  • Server must be up and running

Creating a Clustered I Server environment

For the steps mentioned below we have considered a 2 node I Server cluster.

Creating Cluster Cache and Cluster Inbox

Create two folders ‘ClusterCaches’ and ‘ClusterInbox’ under the Intelligence Server directory on both the I Server nodes (Node1 and Node2):

Mount the ‘ClusterCaches’ and ‘ClusterInbox’ directories created on each node on the other node. Please take note of the 'ClusterInbox' mount.
Directories of Node1 mounted in Node2:

Directories of Node2 mounted in Node1:


Joining the nodes in cluster

Log in to any one of the I Server nodes using the ‘Administrator’ id and follow the steps to join the nodes in cluster:


Applying the Load Balance Factor

Log in to any one clustered node and specify the load balance factor under I Server configuration


Configure I Server to use the Cluster Inbox

This configuration to be done for all the nodes in the cluster by logging to server using ‘Administrator’ id.


Configure MicroStrategy Projects to use the Cluster Caches

This configuration to be done for all the Projects connected to cluster nodes.

I Cluster impact on other MicroStrategy components and parameters

Once the I Server cluster configuration is completed, the Information Source Module in Narrowcast and MicroStrategy Web needs to be accordingly modified to connect to the I Server cluster

Configuration of Narrowcast


Narrowcast Segmentation and Fail Over:

For Narrowcast services, Segment Size is an important parameter which controls the number of jobs which are submitted to I Server for each service. The Segment Size defines the number of subscriptions per segment. For e.g., if for a particular service there are 100 subscriptions and the segment size is 20 then for the particular service there will be 5 segments generated.
Subscriptions with identical preference and authentication are grouped into ‘usersets’. Each subscription within an userset receives similar content. A single job is submitted per userset to I Server
In a clustered environment, in case of a sudden node failure, I Server job requests for subsequent segments are submitted to the still functional node.

Configuration of MicroStrategy Web

Database Connections

As discussed previously in a cluster environment load balancing is inherently done in terms of the number of user connections available at each node. Hence, there is a need to balance the number of database connections manually to optimize the number of requests hitting the database.

The Database (DB) Connection Monitor, like the other monitors, only shows the connections from the local node. The status and number of database connections may be monitored. The number of threads may be configured from the prioritization screen and may be dynamically changed on the fly. Changes made will not be reflected on other nodes even if the servers are using the same definition. The number of threads to connect to the Warehouse is determined at start time and is updated whenever the value in the metadata is changed from the local node.