Clustering Essbase Administration Services

In an EPM Planning environment, there must only be one Essbase Administration Services (EAS) Server in any given environment.  One of the most common mistakes when it comes to implementing an EPM planning environment involves EAS and not Planning.  Many architects try to load balance EAS, or install more than one for fault tolerance, or just for convenience and install EAS wherever they install Essbase.  In fact, if you read the latest documentation in 11.1.2, the High Availability and Disaster Recovery guide says you can use Weblogic Clustering for high availability.  Years of practical field experience and support cases say otherwise.  

The problem is one of functionality. Specifically the functionality in Business Rules (HBR) and its relationship with Hyperion Planning.  In almost every Hyperion Planning environment, Business Rules are in use.  Calc Manager has simply not gained enough momentum yet.  The functional problem that requires only one EAS server is around how Planning and HBR communicate.  In business rules a rule is assigned to a "Location".  These are usually in the format > PlanningServer/PlanningApplication/Cube.  They are seeded into HBR as applications become "active", and can then be assigned.

If you have installed or administered Hyperion Planning, you know there are two Planning services, or components, that have to be running. The first is the Planning Web Application itself.  The other, the Hyperion RMI Registry.  Planning notifies HBR that a location is available or "active" when someone logs into a planning application for the first time by sending a message through the RMI registry service to the HBR server.  It knows where the HBR server is because it's stored as a property in the HBRServer.properties file found either on the file system (pre 11.x) or in the EPM System Registry.

When there are more than one EAS servers it will only notify the EAS server registered in the HBRServer.properties file. The properties file stores only one server name. The result is business rule development on any EAS server but the registered EAS server lacks the functionality to assign planning locations to business rules. Even if the EAS servers share a repository, the second server might be able to see the locations, because it shares the same schema, but the locations can fail to connect because the RMI connectivity fails.

If you are not using HBR you may be able to install multiple EAS servers in an environment.  But consider EAS as an administrative tool, and not an end user tool.  It does not support any functionality that requires high availability.  If you want to install the admin client on every Essbase server that makes sense, but there should not be a need for more than one EAS server. If you are using HBR a single EAS server is a must, so why architect yourself into a situation that can limit functionality should your client decide to use HBR down the road.

Author: Mike Turner