Chapter 5 Administering Groups
DCR Mode Changes and Group behavior
5-10
User Guide for CiscoWorks Common Services
78-16571-01
You can see:
•
CS@bundle-sun280r1 (The local CS group of the Slave)
•
RME@bundle-pc12 (Application group pertaining to the Master)
•
RME@bundle-sun280r1 (Application group pertaining to the Slave)
Say you create a sub group under CS@master hostname. In S, you can see this
subgroup under CS@slave hostname.
However, if you create a sub group in M under RME@master hostname, this sub
group appears in S under RME@master hostname, and not under RME@slave
hostname.
In a cluster if you have M as the Master, and S1 and S2 as M’s slaves, and you
want to evaluate S1’s groups from S2, you need to import the certificate of S1 to
S2 and vice versa.
DCR Mode Changes and Group behavior
The DCR modes have a bearing on how groups are displayed in the Groups UI.
Also the DCR mode decides whether you can perform any operation on the
groups.
In Standalone mode, the groups you create in the CS Groups UI is propagated to
the application Group instances of the applications installed in the same machine.
To perform operations on application groups, you should launch Groups UI from
the application.
In Slave mode, the CS group admin UI is disabled. You cannot create any CS
groups when the machine is in Slave mode. The UI is enabled automatically when
the mode changes to Master or Standalone.
So, in a cluster that has several Slaves and a Master, if you need to create CS
group, you need to go to the CS Groups UI in the Master and create the group.
The group you create there will be synchronized with the Slaves.
The following table gives details of DCR mode changes and implications on
Groups.
