CMS Cluster Summary and the CMSClusterMembers Registry Key
A “CMS Cluster” is a group of Business Objects XI Central Management Servers (abbreviated CMS, which is a BO service\daemon) that are interrelated and connected so that they may work in conjunction to manage the various other BO servers and provide most of the basic functionality of Business Objects. Clustering them allows for greater capacity management (each Central Management Server can generally support about 500 to 600 concurrent users, based on usage) and fail-over capability. In other words, having a CMS cluster consisting of at least 2 CMS is a VERY intelligent design decision for any Business Objects XI environment requiring any fault tolerance.
Creating a CMS cluster is not too complicated, but for now outside the scope of this article. You should understand that pretty much every other BO service will benefit by being aware of this CMS Cluster. The cluster name is defined in the specifications of each server’s CCM configuration (BusinessObjects XI R2) or that of its Server Intelligence Agent (Business Objects XI 3.X). The way that the BO server is aware of the members of the CMS cluster is through server operating system registry key. The name and path of this key on the Windows OS is:
HKEY_LOCAL_MACHINE\SOFTWARE\
One thing important to note about this key is that it is self-maintained. If a CMS is joined or removed from the CMS Cluster than the other BO servers running on a node will communicate with the CMS Cluster and update the registry key to reflect the valid members of the CMS Cluster. Now this is not exactly real-time updating, but rather it occurs at start-up of the BO server (I mean a service, such as Web Intelligence Report Server) or even at enabling of a disabled server.
Reflecting on what I’ve just written I a reminded that it is a good thing to create a CMS Cluster that only contains one CMS. There are no negative impacts that I know of and this allows for scalability as you can easily add in a CMS to the cluster with this already configured.
Hi Nikita, yes, “serverconfig.sh” is really the only method. You must have at least one CMS running and you should run the command from the machine that has the node/SIA (which must be stopped completely).
Nice Web site !! I fixed half of my problems reading your site !! Thanks a lot for that.. Looking forward for some more threads from you on BI 4.0
My question is , do we need to add CMSClusterMembers on servers where no CMS running , only pure WEBI configured?
A little background is , we are having 4 servers == 2 holding CMS and remaining 2 having job and webi services. We have added CMSClusterMembers in servers which are having CMS.Do we need to add them in servers which dont have CMS?
Thanks,
PK
Hello BO_MONK, thank you for the compliments and appreciation. I really do need to start writing mroe about BI 4.0.
Regarding the system design question, you are describing a prefered architecture. If possible I always recommend that a cluster have two CMS (for high-availability reasons). Most systems don’t need more than two CMS since each CMS can effectively manage up to 500 concurrent user sessions. Too many CMS in the cluster can introduce instability and degrade performance with all of the cross-talk which additional CMS introduces. Therefore in a Business Objects system consisting of 4 machines it is recommended to have two running CMS and the rest running report and job servers. By the way, I would put the Input and Output File Repository Servers (FRS) on the same machine as the CMS. You could also put any Event Servers and Destination Job Servers with the CMS as well.