Brocade Communications Systems RFS6000 System Reference Manual page 308

5
Configuring controller redundancy and clustering
After sending the command to other members, the cluster-management protocol (at WS1) waits for
a response from the members of the redundancy group. Upon receiving a response from each
member, WS1 updates the user's screen and allows the user to enter/execute the next command.
The wait time required to collect responses from other controllers is predefined, so if any one or
more members does not respond to a given command within the defined interval, the command
originating controller displays whatever responses have been collected and ignores the delayed
responses. This time-based response mechanism eliminates the possibility of indefinite response
hangs and allows for quicker redundancy group configuration.
There is no fixed master-slave relationship between members. Typically, a controller can be
considered a master for the command it originates. Responding members can be considered
slaves with respect to that command.
This virtual master-slave relationship makes this design unique when compared to existing
centralized management systems. Having a virtual master-slave relationship eliminates a single
point of failure, since a user can make use of any controller as the group centralized management
entity (using the cluster-management context).
NOTE
When using the redundancy feature make sure that UDP traffic on port 51515 is open between the
redundant controllers.
To view status and membership data and define a redundancy group configuration, refer to the
following:
•
•
•
•
•
294
Configuring redundancy settings
Reviewing redundancy status
Configuring redundancy group membership
Redundancy group license aggregation rules
Managing clustering using the Web UI
Brocade Mobility RFS6000 and RFS7000 System Reference Guide
53-1001858-01