Don’t Fluster the Cluster

Ben and Jerry’s recently introduced a new flavor called Clusterfluff, described as “peanut butter ice cream with caramel cluster pieces, peanut butter and marshmallow swirls”.  Yummy.  But today, let’s talk about a different cluster: SAP BusinessObjects Business Intelligence, also known as SAP BusinessObjects Enterprise.

A cluster in SAP BusinessObjects Enterprise is defined as a system with multiple Central Management Servers (CMS) that work together by sharing a common system, or CMS, database.  Each CMS is typically on its own physical device, known as a node.  SAP BusinessObjects enthusiasts who take the BOE330 training class, Designing and Deploying a Solution, get to team up with their fellow students and create clusters in class.  Let’s discuss using Microsoft Windows; however, the same principles apply to Linux/Unix.

I recently encountered a BI system with a poorly devised cluster.  It was the second time that I’ve seen this ill-advised configuration on the XI platform, so it seemed worth writing about.  Especially since SAP BusinessObjects Business Intelligence 4.0 continues the server architecture of the past few versions.  In both of my situations, each physical server, or node, was built with a “new” install.  Once the installation was completed, the second CMS was stopped and reconfigured to point to the same system database as the first CMS, as shown in the illustration below (click image to enlarge).

Each node has an identical configuration.  There’s two of everything.  Two Central Management Servers.  Two Crystal Reports Processing Servers.  Two Web Intelligence Processing Servers.  And, sigh, two Input File Repository Servers, or iFRS.  There are two Output File Repository Servers, or oFRS, as well.  Each file repository server points to local storage on the node, which is a significant flaw that could lead to corruption of the cluster.

In a SAP BusinessObjects cluster, only one FRS is actively working even when all FRS in the cluster are enabled.  Just like many of your coworkers, the rest of the FRS sit around doing nothing in a passive state waiting for the active FRS to fail.  All FRS connect with the CMS upon startup.  The active FRS is the one that contacts the CMS first.

So how can the cluster become corrupted?  Let’s assume that the iFRS on node 1 becomes active.  When a report is published to the system, it is stored on the iFRS default location, which is the C: drive on node 1.  The CMS database contains an InfoObject containing the physical path to the report.

Next, let’s assume that the iFRS on node 1 fails.  The iFRS on node 2 becomes active.  When Sally in accounting logs into InfoView to view a month-end report, the processing server will fetch the report from the active iFRS on node 2.  However, because the report was originally written to the C: drive on node 1, Sally will receive an error and call the Business Intelligence help desk.  The cluster, sadly, has become fluffed.

A better solution would be to disable the iFRS and oFRS on node 2, guaranteeing that the iFRS and oFRS on node 1 are always active and that all documents are stored locally on node 1.  This configuration is shown in the following illustration (click image to enlarge).

You might argue that this configuration is not fault tolerant.  And it isn’t.  However, neither was the first configuration.  Disabling the second iFRS and oFRS is the first step to preventing additional corruption.

The best solution is to create a file system that both nodes can share, as shown in the illustration below (click image to enlarge).

Each FRS is configured in the Central Management Console (CMC) to use the shared space, typically by specifying a UNC path.  Since the shared space is on a different device, the File Repository Servers will need to run using a domain account rather than the default Microsoft Windows Local System account.  This account is specified in the Central Configuration Manager (CCM), either directly on the File Repository Server (XI R2) or vicariously through the SIA (XI 3.x).  Be sure that separate directories are created to distinguish the Input File Repository from the Output File Repository; however, both can share a common parent directory, as they do in the default out-of-the-box configuration.

There are other design considerations for a truly fault-tolerant BI architecture, such as failover in the web application server tier.  But that will have to wait until a future discussion.  In the meantime, I hope you will enjoy a pint of Ben and Jerry’s Clusterfluff ice cream.  And inspect your BI system to insure proper configuration.

What are your experiences with SAP BusinessObjects clustering?  Share your thoughts (and favorite bookmarks).