essbase clustering

11
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.

Upload: nas4ru

Post on 13-Dec-2015

126 views

Category:

Documents


11 download

DESCRIPTION

Essbase Clustering

TRANSCRIPT

Page 1: Essbase Clustering

Essbase Clustering Part 1Essbase 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:

Page 2: Essbase Clustering

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)

Essbase Clustering Part 2: (Active/Passive Clusters)If you read my earlier post on Essbase clustering, you have realized that Essbase offers a couple of ways to cluster a server:

1. Active/Passive, which is best for BSO clusters as it supports write back

2. Active/Active, which is best for ASO clusters as it allows for load balancing as well

On this post, I will outline how to configure an Essbase active/passive cluster. 

What will you need:If you want to create your own cluster you will need:

1. Two servers

2. A load balancer (where you can configure a VIP, aka Virtual IP) and where it can "sense" when one node is not available to failover to the passive node.

3. A high speed shared disk (your cluster would not be much of a cluster if Essbase cannot access the database files)

4. Knowledge on how to install Hyperion

My SetupI'm using the latest version of Oracle EPM 11.1.2.3 and I'm installing it in two virtual machines using CentOS 6.5 Linux which is a RedHat variant and this way I don't have to mess around with Microsoft cluster services.

Page 3: Essbase Clustering

Now, for this demonstration, I'm using an NFS share for my shared repository in one of the servers and I'm not using a load balancer but in real life this would not be an ideal scenario.

Configuration Process on First NodeYou need to install your first Essbase node normally, as you would any other Essbase server. On the Essbase configuration step you need to specify the shared disk as the ARBORPATH and you can change the name of the cluster as you see fit:

As you can see from the screenshot above, I have called my cluster "EssbaseCluster-LAB" and changed the ARBORPATH to "/u01/SHARED/EssbaseServer/essbaseserver1".

After you have configured your first node you can move on to installing and configuring your second node.

Configuration Process on Second NodeYou need to install your second node normally but when it comes to configuring the Essbase part you will need to make a change. When you enter the configure Essbase task you will see the all the default values:

Page 4: Essbase Clustering

You will have to click on the "Assign To Existing Cluster" button on the top right corner so you can select the cluster that was previously configured and assign this node to it:

Page 5: Essbase Clustering

You can select the cluster from the drop down. Then when you click OK you will see that you cannot change the cluster name or the ARBORPATH as these need to be the same on both nodes.

Now you can continue with the configuration process and finish all tasks.

Post-configuration TasksAfter you installed and configured both Essbase nodes you are still not ready to use the cluster. You first need to make some changes to the opmn.xml file in order for opmn to sense when Essbase crashes on one server so it can bring up the Essbase process on the passive node. I followed the steps from the following Oracle Deployment Options Guide

You need to make the following changes in the opmn.xml on both nodes:

Add the topology:

Page 6: Essbase Clustering

Make sure that the port you use is the OPMN remote port (6712) and not the Essbase port (1423). This tells opmn the OPMN nodes in this cluster.

Add the service failover and weight directives. Now, make sure that the node you want to be primary has a higher value (101) than your passive node (100):

Active Node:

Passive Node:

Page 7: Essbase Clustering

You also need to make sure that the name of the cluster is in the ias-component ID directive as so:

Lastly, you have to set the "restart on death" to true. Now, this directive will tell OPMN to attempt to restart the active node's Essbase process on death before attempting to pass the baton to the passive node. If this directive is set to false, it will immediately attempt to activate the passive node's Essbase process and not attempt to restart it on the active node. I have set mine to 'false' as I want it to die immediately for test purposes and not attempt to restart Essbase.

Also, as you can see from the "restart" directive you can specify other parameters such as the number of retries and the timeout.

We are now finally ready to test our configuration and start Essbase on both nodes. As you start essbase, you will see that one node will have the opmn processes only and the other should have the opmn process as well as the ESSBASE process running:

Passive Node:

Page 9: Essbase Clustering

Failover TestSo now that it's all configured, you can test that the failover configuration works. To simulate, you can kill the ESSBASE process form the active node and you should see how it automagically starts the ESSBASE process on the passive node. This is where having a separate shared filesystem and a load balancer comes in handy. You would configure your Planning data source using the VIP from the load balancer instead either node. 

At the end, you should end up with something like the following depiction:

Hope this helps explaining how Essbase clusters work and are configured