Jan 16, 2014

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.