Essbase Clustering Part 1

Essbase clustering can be used in order to mitigate the risk of an Essbase server going down and affecting your Planning or Reporting application with it. When it comes to Essbase clustering, however, there is one commonly used method which is to use the Essbase clusters that can be configured via the main installation program.

These Essbase clusters are more like a “hot spare” configuration or active/passive. The problem with this approach is that you need to have two identical servers (ideally) but can only use one at a time not using any of the horsepower from the “passive” server.

In order to have a cluster of this type you will need to configure a Microsoft Cluster to monitor both servers, services and DNS entries. Configure a cluster disk (outside of the Essbase cluster) to store the Essbase data files (ARBORPATH) and configure opmn to monitor Essbase process running on both servers. Ideally, MCS will detect a down server and point the cluster name to the other server and switch the shared disk. Then OPMN will detect that Essbase is not running on the downed server and start it on the server that is still available.

Does this sound like a lot? There’s another option…

Another method of clustering is an active/active cluster, which can mitigate the risk of having only one Essbase server and also serve as a load balancer.The main “gotcha” for an active/active cluster is that you can not write back to it which is required for Planning applications. This is the reason this type of clusters is not as popular and is almost exclusively used with ASO reporting applications. Another gotcha of active/active clusters is that you have to build your cubes and load data on both servers. These need to be maintained in-sync in order to make sure that users being sent to one server see exactly the same as other servers in the cluster.

This method uses APS and the JAPI to establish server pools like so:

The main advantage for this setup is that you don’t have to configure any MS Clustering and you can treat each server individually with its own ARBORPATH’s. In EAS, each will show as an individual server with their own set of applications. On the downside, you will have to build each application on each server.

Again, this is most suitable for ASO applications or BSO apps that do not require write back (which rules out Planning) and can take advantage of the horse power of both servers at all times (unless a server goes down)

I will be writing two follow up posts on how to configure each type of cluster identified here.

That’s all folks!