Business Objects Edge doesn’t support distribute installation for cluster, which is different from Business Objects Enterprise. However, this doesn’t mean that the user cannot benefit from clustering ability with BO Edge. In this post I will share with you how to cluster BO Edge with Microsoft Configuring Service.
Background
One customer has purchased Business ObjectsEdge XI3.1 standard edition, and they want us to cluster it for High Availability (HA). That’s, when one machine crashes (to be more specific, whenthe WAS such as Tomcat or any server of BO Edge crashes, when the OS crashes orwhen the network is down), the other machine can be started to take the responsibility immediately and automatically.
Well, this is very easy to do if they were using BO Enterprise. As you know, Business Objects Enterprise has clustering ability with itself by installing BOE on multiple machines and pointing to the same CMS, either for High Availability or for Load Balance. However, it’s not the case with BO Edge, as you cannot install it on different machines while pointing to the same CMS.
Solution
The solution is to install BO Edge on multiple machines separately, each has its own CMS name but pointing to the same database and FileStore, and then configuring them as a cluster using Microsoft Clustering Service (MSCS), a service of Microsoft Windows.
From the end user’s perspective, they access InfoView or CMC through the cluster name. When using Designer or Web Intelligence Rich Client, they enter the cluster name as the CMS.
Aside from MSCS, you can also use some other ways to achieve the same goal. For example, you can use some hardware such as F5 (http://www.f5.com/) or software such as Apache for load balance, which provides a virtual IP and dispatches user requests to any node based on its performance. In our case, MSCS is chosen just because the customer has purchased Microsoft Windows 2008 Server with MSCS.
So briefly, we need configure MSCS to make multiple machines a cluster, install BO Edge on each of the machine (node),pointing different installations to the same CMS / Audit databases and Input /Output FileRepository, and register BO services to the cluster so that MSCS can listen to and control those services.
Steps
In the rest of this post, I’ll show youeach step we have went through in clustering BO Edge using MSCS. If you have the same requirement but run into some problem on any step, feel free to ask mefor more information.
1. Configure cluster for the machines with the same hardware & software configuration using MSCS.
This step should be done by some Windows experts. After installation, you can check the nodes from Start - All Programs –Administrative Tools – Failover Cluster Management. For details about how to configure MSCS, refer to google or Microsoft website such as http://msdn.microsoft.com/en-us/library/ms952401.aspx.
Briefly, the theory with MSCS is that, only the services on one node are running (active) at a time. All the other machines are also powered on but their services are stopped. When the currently active node encounters some problems and cannot serve, MSCS observers it (by listening to its “heart beat”) and automatically switches to another node. The services on that nodeare then started automatically. As a result, there may be some delay between the time when some services on the active node are down and the time when all services on another node are up. The delay is the sum of the time required bythe MSCS to find out that the active node is down and to start up all the services on another node.
In our case, the OS is Windows 2008 Server R2, 64-bit, with4 * 2.4G CPU and 32G Physical Memory. The delay is 1 minute or so.
2. Install BO Edge on each machine one by one.
In our case, 2 machines are used to install BO Edge forfail over. Whether BO is installed on the primary or the secondary node first doesn't matter. Before installation, disable the other nodes first, through Start– All Programs - Administrative Tools. It’s not required to shutdown that machine.
During installation, the default SIA (Server Intelligence Agent) node name is the machine name (such as pedbbo01, pedbbo02) and you need change it to a general name so that it’s not specific to any node. For example, change it to CompanyBOEdge, which is HFBOE in ourcase.
In our case, the CMS and the Audit databases are on Oracle11 server. So during installation, choose “Advanced” and select Oracle as your database. The properties for both the CMS and the Audit databases should be the same for BO Edge in both machines – that’s, CMS on two machines share the same Oracle table space, with the same user id (for example, B3OLPADM for CMS andB3OLPADT for Audit).
After installation of one machine, don’t make any change through CMC or CCM. Go on to install BO Edge on each other node.
Do not go on with the following steps until BO Edge has been successfully installed on all the nodes.
3. Update FileStore.
For data consistency, both installations of BO Edge should share the same FileStore by pointing to the same folders for Input / OutputFile Repository Server. By the way, during installation, we have already configured the two installations of BO Edge to share the same table spaces for CMS and audit across both installations.
To make the FileStores (both Input and Output) share the same path for the 2 machines, follow the steps below:
a. Copy folder FileStore of eithernode.
b. Paste it in a cluster disk (forexample, Z:/FileStore).
c. Update the path info of theInput and the Output FileRepositoryServer through CMC.
You can then logon to CMC of the other node. You will find that the paths of the Input / OutputFileRepositoryServer has been automatically updated to the folder in thecluster disk.
4. Change startup type from Automaticto Manual for Tomcat and SIA in both machines.
BO Edge contains 2 windows services, Tomcat and SIA. We change their startup types to Manual because with clustering using MSCS, only one node is up at a time and so it is with the BO services. As a result, we don’t want BO services to start up automatically on each node.
5. Register services of Tomcat and SIA to the cluster.
Much time is spent in this step. The steps are illustrated below.
a. Create a Service for SIA
First, right-click the cluster name in Failover Cluster Management and select “Configure a Service or Application”, as displayed in Figure1:
Figure 1. Create a Service for SIA
In the “Select Service or Application” step, select “GenericService” in the wizard and click Next, as displayed in Figure 2:
Figure 2. Select Generic Service as Service type
Then you will see a list of Windows services of that machine, the same as you see when running “services.msc” from the command line.In this step, select SIA in the “Select Service” tab.
In the “Client Access Point” step, enter a name for theservice to something like “HFBOE” and type a IP, which is an virtual IP addressfor the end user such as 10.70.1.113, as illustrated in Figure 3:
Figure 3. Enter a virtual IP for client access
In the “Select Storage” step , select the cluster disk “Z:”which has been configured in the first step.
b. Add Resources for Tomcat
In the previous steps we have configured SIA as a Service. In BO Edge, service Tomcat should depend on SIA so in this step, we are to add Tomcat as a resource for service SIA. To do this, select the service you have just created and click “Add a resource” to the right, as demonstrated in Figure 4:
Figure 4. Add a resource for Tomcat to SIA
And select “Generic Service” in the context menu (forTomcat). No special configuration here.
c. Add Dependency
In this step we are to define the dependency order. That’s,what resource should be ready before another can be started. In our case, the dependency order should be : Service name -> IP -> Cluster Disk -> SIA-> Tomcat, meaning that the IP service and the Cluster Disk should be ready before SIA can be started, and then Tomcat.
In the following paragraphs of this section, we will show you what we did in our case to configure the dependencies and some other properties of each resource or service.
For the ApacheTomcat, select the service HFBOE and then resource “Tomcat”, right-click it and switch to the Dependencies tab to make it depend on SIA, as displayed inFigure 5:
Figure 5. Resource Tomcat should depend on SIA
And its Policy tab should be similar to Figure 6 below:
Figure 6. Policy tab of resource Tomcat
For SIA, right-click it and switch to the General tab. Remember to check “Use Network Name forcomputer name”, as displayed in Figure 7:
Figure 7. Select "Use Network name for computer name" for SIA
You may google for the meaning of this option and why wecheck it here.
In its Dependencies tab, make it depend on the service “HFBOE”and Cluster Disk “Z:”, as displayed in Figure 8:
Figure 8. SIA should depend on the Cluster Disk and the service
For your information, its “Advanced Policies” tab should be similar to what’s displayed in Figure 9 below:
Figure 9. Advanced policies for SIA
For the Cluster Disk, similarly, open its Properties tab and make it depend on the “HFBOE” service as displayed in Figure 10 below.
Figure 10. Cluster Disk should depend on the service.
And in its “Policies” tab, select “If resource fails, do not restart” which means that on failure of this resource(Cluster Disk), switch to the other node without trying to restart it in thesame node. This is very important during the configuration. You can refer to Figure11 to have a look:
Figure 11. Do not restart Cluster Disk if it fails
As to the “HFBOE” service itself, in its “Properties” tab, make it depend on the IP Address which is also a resource, as displayed in Figure 12:
Figure 12. The service itself depends on resource IP Address
Also please select both nodes as the Preferred Owners, as displayed in Figure 13:
Figure 13. Select both nodes as Preferred owners for the service
After this step, the end user should be able to access the BI portals of InfoView and CMC, or the CMS through some client tools such as Designer, Query as a Web Service or Web Intelligence Rich Client, with the cluster name or the virtual ip as the CMS name. MSCS will redirect the user to the active node, of which the user is unaware. What’s more, when one machine crashes due to a power off or network problem, MSCS will automatically activate the other node and consequently start up Server Intelligent Agent and Tomcat of it.
6. Test HA
Before testing, validate the configuration through “Validate a Configuration…” command as displayed inFigure 14:
Figure 14. Validate the configuration before testing it
When the validationpasses, there’re 3 ways to test HA:
a. Move service to the other node.
In this way you manually move the BO Edge services (Tomcatand SIA) from one node to the other, to test whether they can be stopped and started automatically by MSCS.
b. Disconnect public cable
This way is to simulate the scenario when a network problem has occurred to the currently active node. That’s, when the machine cannot be reached over the network. To test this, find the public cable of the active node and simply pull it out.
If the configuration is OK, MSCS will detect this and switch to the other node automatically.
c. Power off
This way is to simulate the scenario when the currently active machine crashes or has been shutdown accidentally. To test this, shutdown the active node and see if BO services can be started automatically on another node.
If the configuration is OK, MSCS will detect the power off accident and switch to the other node automatically.
Still have problem with BO Edge cluster? Feel free to email me at ray.li@byinsight.com.
8 Comments
