Communication between CMS's

by: Joe Roberts, Senior Consultant, BECP

Last month we talked about the CMS start up procedures and how it affects the Enterprise system, especially in relation to CORBA and the registration of services. This month I want to go a little more in depth concerning how CMS’s communicate with each other in a clustered environment.

What is a cluster?

The first question we have to answer is what is a cluster? A clustered Business Objects Enterprise environment is one that has one or more CMS’s that work together to provide management and security for the Enterprise implementation. The only real requirement to have a cluster is that the system database be installed on a client/server database platform like MS SQL Server, Oracle, DB2, MySQL etc. So it is possible to have a cluster of one. This is an important point because one CMS in a cluster acts just like multiple CMS’s in a cluster would. Adding a second or third CMS does not change or alter the basic behavior, it just extends it. So if you have a single CMS, using one of the database platforms mentioned above, you have a cluster.

The most common misconception is with the term “cluster”. Often this is misinterpreted as simply multiple machines running BOEXI processing services. Processing services (Page Servers, Job Servers, Web Intelligence Report Servers, etc) cannot be clustered, only CMS(s) can be clustered. Multiple servers running multiple processing services are load balanced and utilized independently. This process can create a certain level of Fault Tolerance or Fail Over but this is not clustering.

Why would I want more than one CMS?

Multiple CMS services allow you to increase capacity as well as provide fault tolerance and/or fail over to the system.

Increasing Capacity

This is usually the last reason to have multiple CMS’s in a cluster. Why? Typically a single CMS can handle 600 – 700 logged on users at a time. Since a single machine can only handle 50 – 100 report processes at a time (depending on configuration) you can see that multiple machines will have to be added to support report processing long before it will necessary to accommodate a larger number of logged on users.

Fault Tolerance

To provide fault tolerance you can create multiple CMS services on the same machine using the same system database. Fault tolerance means that if one CMS service should fail (fault) then the other CMS service would still be available to handle the load. This is often referred to as “Scaling up”.

Fail Over

Fail Over is similar to fault tolerance but instead of being service specific it is server specific. Fail Over allows the system to continue working in the event of a loss of an entire server. This is accomplished by creating multiple CMS services, using the same system database, on separate servers.

No matter what your reason or approach the important thing to remember is that the CMS functions in the same way in each case.

Cluster Communications

So if a cluster is just multiple CMS services using the same system database then how do they keep everything together?

If you will remember, last month we discussed the startup procedures for a CMS and the first step in the process was to connect to the system database and then try to establish communication with any other CMS’s. This connection is actually in the form of a thread that established direct communication to each other. Once this thread is established they will now “negotiate” with one another to manage and execute incoming requests. It doesn’t matter which CMS is initially contacted with the request, they will negotiate with each other and the most available CMS will handle the request. This negotiation process is true of all requests except CORBA Name Shell requests (see last month’s article). The first CMS in the cluster will always establish itself as the CORBA Name Server and handle all CORBA duties as long as it is active.

You next question should be:

If my web application designates a particular CMS (machine1) as its CMS server, what happens when that machine goes down?

Once again we fall back to the functionality of the CORBA Name Shell. If you will remember from last month the function of the Name Server is to distribute the list of available services with their name, IP address and port. This includes the web application server. When it establishes communication with its designated CMS, it receives a copy of the Name Shell list. If at any point in its normal routine it cannot communicate with that CMS it will roll over to the next CMS in the Name Shell list.

So what happens if the web application’s designated CMS is down when the application server first starts?

To accommodate this eventuality there is a, somewhat little documented, feature of the CORBA communication. That is that on first contact each service will create or update a registry key (HKEY_LOCAL_MACHINE/SOFTWARE/BUSINESS OBJECTS/SUITE 11.5/ENTERPRISE/CMSClusterMembers) that keeps track of all the CMS machines in the cluster. When the application server first starts, if it cannot communicate with its designated CMS, it will use this list until it finds an active CMS.

So, as you can see, it pretty much covers every contingency. There are, however, a few basic requirements for clustering that I will leave you with.

1. Each server that will be hosting a CMS must have:

a. The exact same operating system

b. The same type of CPU and same amount of memory

c. Same service packs and patches

d. Connect to the system database in the same manner

e. Use the same credentials for connecting to the system database

f. Be running under the same startup account

g. Be on the same subnet (remember the thread?)

2. If auditing is enable then:

a. All services must have auditing enabled

b. Must connect to the same auditing database

c. Must connect to the auditing database in the same manner

d. Must connect to the auditing database with the same credentials

3. The time on each server must be synchronized to be the same

If you adhere to these requirements and understand the process of clustering you should have no trouble running multiple CMS services and bring complete Fail Over and Fault Tolerance to you Enterprise environment.

Go to Top | Return to Newsletter Contents