Project Failover and Latency

Project failover support in a cluster is similar to system failover support. 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 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 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.

Failover and latency take effect only when a server fails. If a server is manually shut down, its projects are not automatically transferred to another server, and are not automatically transferred back to that server when it restarts.

You can determine several settings that control the time delay, or latency period, in the following instances:

• After a machine fails, but before its projects are loaded onto to a different machine
• After the failed machine is recovered, but before its original projects are reloaded

To Set Project Failover Latency

1. In Developer, from the Administration menu, select Server, then select Configure MicroStrategy Intelligence Server.
2. Expand the Server Definition category, then select Advanced.
3. Enter the Project Failover Latency and Configuration Recovery Latency, and click OK.

When deciding on these latency period settings, consider how long it takes an average project in your environment to load on a machine. If your projects are large, they may take some time to load, which presents a strain on your system resources. With this consideration in mind, use the following information to decide on a latency period.

Project Failover Latency

You can control the time delay (latency) before the project on a failed machine is loaded on another node to maintain a minimum level of availability.

Latency takes effect only when a server fails. If a server is manually shut down, its projects are not automatically transferred to another machine.

Consider the following information when setting a latency period:

• Setting a higher latency period prevents projects on the failed server from being loaded onto other servers quickly. This can be a good idea if your projects are large and you trust that your failed server will recover quickly. A high latency period provides the failed server more time to come back online before its projects need to be loaded on another server.
• Setting a lower latency period causes projects from the failed machine to be loaded relatively quickly onto another server. This is good if it is crucial that your projects are available to users at all times.
• Disabling the latency period or the failover process:
  • If you enter 0 (zero), there is no latency period and thus there is no delay; the project failover process begins immediately.
  • If you enter -1, the failover process is disabled and projects are not transferred to another node if there is a machine failure.

Configuration Recovery Latency

When the conditions that caused the project failover disappear, the system automatically reverts to the original project distribution configuration by removing the project from the surrogate server and loading the project back onto the recovered server (the project's original server).

Consider the following information when setting a latency period:

• Setting a higher latency period leaves projects on the surrogate server longer. This is good idea if your projects are large and you want to be sure your recovered server stays online for a specific period before the project load process begins. A high latency period provides the recovered server more time after it comes back online before its projects are reloaded.
• Setting a lower latency period causes projects on the surrogate machine to be removed and loaded relatively quickly onto the recovered server. This is desirable if you want to reduce the strain on the surrogate server as soon as possible.

You can also disable the latency period:

• If you enter a 0 (zero), there is no latency period and thus there is no delay. The configuration recovery process begins immediately.
• If you enter a -1, the configuration recovery process is disabled and projects are never automatically reloaded onto the recovered server.