Oracle EPM 11.1.1.3 – Essbase Clustering for High Availability

Its been almost a couple of weeks since i last blogged due to a flurry of events like Open-World, Training Days, Client Engagements etc. Getting the materials completed took most of my time and since then i haven't had a chance to blog. But now that the busiest part of the year is behind me, i am looking forward to blog more frequently in the near future. One of the things that i have been planning on blogging recently is the High Availability features in the EPM 11 stack. I will split this into a series of entries over this month and the next. The first one that we shall look at today is Essbase clustering.

Clustering of Essbase servers can be very critical if you have a mission critical reporting system that requires to be online almost all the time. There are 2 kinds of clustering that Oracle supports for Essbase

1. Horizontal Clustering – This is a normal clustering scenario wherein we have an exact replica of the Essbase server spread across multiple machines and each machine is in active state (active-active).

2. Vertical Clustering – This is clustering scenario which is similar to Horizontal clustering wherein instead of having multiple instances, multiple instances of Essbase are created on the same machine (adding more hardware). If you compare this with BI EE, BI EE does not support this clustering architecture yet.

At a high level, the Essbase clustering architecture is given below

The idea is to have multiple Essbase servers being served in turns by the Provider Services. For complete high availability scenario, the Provider Services itself can be clustered so that there is no single point of failure. The Provider services clustering is very similar to Presentation Services clustering in BI EE. In a BI EE cluster, multiple presentation services write to a common shared web catalog. Similarly, in the case of Provider services, multiple web instances share a common cluster definition stored in a shared directory. This blog entry will focus only on the Essbase server clustering using a single provider services.

Scenario: We basically have 2 instances of Essbase running on 2 separate machines. One machine hosting one of the Essbase Servers and a corresponding provider services. Another machine hosting another Essbase server with no provider services. To cluster both the servers we shall start with logging into the Essbase Administration console and then adding both the servers under the Essbase Server node.

Once these Essbase Servers have been added, the next step is to add a Provider Services under the Provider Services node.

One of the advantages of Essbase clustering is the fact that it allows clustering at database level. That is, one has the ability to either include all the applications to be part of a cluster or only certain necessary ones. In our case, lets add both the Essbase Servers to the Essbase Cluster node.

While specifying the name for the cluster, ensure that you have a name without any spaces in them. Also, in our example, we shall just add the SampEast Application(from both servers) to the cluster

Whenever new applications/servers are added/removed from a cluster, the provider services need to be restarted (but they can be enabled/disabled after adding them without a restart)

Clustering capability can be leveraged only by those applications that can connect through Provider Services. So, if you have a smart-view client or an external application using JAPI, then clustering can be leveraged. To test our cluster, lets login to Smart-view using the provider services. While adding the Essbase Server, instead of the actual Essbase Server names use the cluster name that we gave above.

As you see we now have the application/database that we added under the cluster being displayed by Smart-View through the provider services. Now, lets create a report using this database and check where the session gets created.

As you see the first session gets created in the first Essbase Server. Now lets open up another instance of the Smart-View client and create the same report. You will notice that Smart-View pushes this new session to the other essbase server

Also, as another test, lets kill the first essbase server and then try running both the reports(both instances of Smart-View) again. You will notice that, both the sessions will now have moved to the valid & live Essbase Server.

Though it works out of the box and is quite good, it has certain drawbacks. Lets look at them one by one.

1. Write backs directly from Smart-view are not supported. If you try to write-back to a database cell, an error message would pop-up denoting the fact that write-backs are not supported in a clustered mode.

The only work around is to connect to the servers directly (without the provider services cluster) and then write-back on them. But the end user will have to ensure that both the servers are kept in sync manually. So, this cannot be used in Hyperion Planning apps.

2. Essbase Add-in cannot leverage the clusters.

3. Security across the nodes should exactly be the same. Both the nodes should have same security setup (native authentication or shared services authentication)

Apart from the above 3 limitations, every other individual essbase feature can be leveraged and hence all of them will be in a highly available mode. It is easy to add new nodes and remove them as and when necessary. In future, we shall see how to go about clustering Provider Services, OpenLDAP and Hyperion Workspace. All the clustering topics that i am planning to cover will all be based on active-active clustering mode. Active-Passive clustering is also supported though it is typically achieved through an external software solution (to keep machines in sync through some background process). Hence i will not be covering the latter.