INTRODUCTION
Failover, as it applies to Strategy Intelligence Server, is a strategy by which user sessions and history list jobs are automatically transferred from a failed Strategy Intelligence Server cluster node to another backup node. The goal of failover is to maximize availability of the Strategy Intelligence Server. Failover is a key feature in a scalable system. Two levels of failover are described below:
The following things are checked before another node in the cluster takes over the work from the failed node:
Automatic session re-routing - In order for a failover to be seamless for the end-user, automatic session re-routing is provided, such that user sessions on failed cluster nodes are automatically re-routed to other available nodes. If a Strategy Intelligence Server cluster node fails while running a request, end-users will receive an error message; but subsequent requests will run seamlessly through an available cluster node. To ensure that session re-routing does not ask the end-user to provide their login credentials again, users must enable the "Allow automatic login if session is lost" setting found under the Security section on the Web Administration Page as seen below:
Report cache sharing - Strategy provides report cache sharing in 3-tier and 4-tier modes
What is project failover?
Project failover support within a cluster is similar to system failover support. However, project failover only works in an asymmetrical cluster. For example, one server in a cluster is hosting project A and another server in the cluster is running projects B and C. If the first server becomes unavailable, the other server can begin running all three projects. Project failover support ensures that projects remain available even if hardware or an application fails.
Project failover is triggered when the number of nodes running a given project reaches zero due to node failure. At that point, the system automatically loads any projects that were on the failed system onto another server in the cluster to maintain the availability of those projects. Once the failed server recovers, the system reloads the original project onto the recovered server. It also removes the project from the server that had temporarily taken over.
What is project failover latency?
The amount of time taken before the project is loaded on one of the surviving nodes of the cluster to maintain minimum level availability. Latency parameters can be set via the Intelligence Server Configuration Editor (under Projects ->General).
The latency parameters only take effect in case of an unexpected shutdown of a node. If the node is manually shutdown, there will not be any project failover and therefore the parameters will not apply.
Refer to the following technote if you need a detailed description of the latency failover parameters:KB14393: What role do Project Failover Latency and Configuration Recovery Latency play in MicroStrategy Intelligence Server configuration
How does Strategy Intelligence Server failover History Lists?
Strategy Intelligence Server creates a backup of history lists on disk. Strategy Intelligence Server provides History List (Inbox) synchronization but to be able to synchronize history lists, each cluster node must be able to access the history list folders on all other nodes. History Lists are synchronized across all cluster nodes in a manner similar to report caches. Each Strategy Intelligence Server node retains in memory the location of all history list messages of users with active sessions on that node. When a history list message is created on one cluster node, the existence and location of this message is broadcast to the other cluster nodes. The other cluster nodes then update their memory with this new information. When a cluster node receives a request for an inbox message that resides in the hard disk of a remote cluster node, the cluster node will access the remote hard disk to retrieve the inbox message.
For a more detailed explanation of history list synchronization, see Strategy Knowledge Base document:
KB6058: How and when does MicroStrategy Intelligence Server cluster synchronize user History List or Inbox?
If a Strategy Intelligence Server node failure occurs in the middle of a job execution, the surviving node will proceed to run the unfinished history list job. This job failover is possible only because the history lists are synchronized across all nodes in the cluster.
Additionally, the surviving node will append the history list messages from the failed node to its own list of messages.
Note: Each node in the cluster has a partial list of History List messages for each user based on where the message was created. When a user logs in, the user's History List is updated with messages from all the nodes in the cluster.
For clarity, the following sequence of events occurs during history list failover:
What happens to an in-flight request if a Web server node fails?
If a Web Server node fails while a report request is in-flight to the Web Server, then the behavior will be dependent on the Web clustering software being used. Most clustering software will simply re-route the http request to another Web server within the cluster. Because Strategy Web is designed to be stateless, the new Web server will be able to process the user's request.
On the Intelligence Server side, the job will continue executing. When the Web client browser requests the status of the executing report, the client request will be re-routed by the Web clustering software to another available Web server node. The new Web server node will be able to connect to the Strategy Intelligence Server and process the client request.
What happens to an in-flight request if a Strategy Intelligence Server node fails?
In a 4-tier environment, if an in-flight request has not yet reached a Strategy Intelligence Server cluster node when the node fails, then Strategy Web will automatically re-route the request to an available node within the cluster. However, if the in-flight request has reached the Intelligence Server, then we have the following scenarios:
What happens to time-based subscriptions when a Strategy Intelligence Server node fails?
In Strategy 9.x, time-based subscriptions are load balanced, so they are not limited to the primary node. If the node running a time-based subscripton fails, the job that belongs to future upcoming time trigger will be balanced to the remaining nodes seamlessly. The jobs already running on the failed node will only be re-executed on one of the surviving nodes if that subscription has a history list association with it, otherwise it ill be canceled.
In Strategy 8.x, time-based subscriptions only run on the primary node of the cluster. When this node fails, one of the other nodes in the cluster resumes the responsibility of the primary node and executes the remaining subscriptions. If the primary node fails during an in-flight time-based subscripton request, the job will failover to the new primary node only if this subscription has a history list association with it.
What happens to event-based subscriptions when a Strategy Intelligence Server node fails?
Event based subscriptions run on the node where the event is triggered. So if this node fails, job will be re-executed if there is a history list association to it, otherwise it will be canceled.
In Strategy 9.x, event-based subscriptions are also load balanced, so they are not limited to the triggered node. If the node running the event-based subscription fails, the job will failover to the whichever node Strategy Web re-routes the user session to and will only be re-executed if this subscription has a history list association with it.
Summary
In the event of a Strategy Intelligence Server failure, job re-execution on the surviving node is based on whether or not that job has a history list message associated to it and the Session Failover is based on Strategy Web failing over.
Failover is only supported for an unexpected Intelligence Server failure and not for a manual shutdown of the Intelligence Server.
For information on clustering configuration, refer to the following Strategy Knowledge Base documents;
KB6022: MicroStrategy Intelligence Server Cluster Configuration Guide
KB16018: MicroStrategy Intelligence Server Clustering FAQ
KB4759: MicroStrategy Intelligence Server cluster load balancing FAQ
