Cluster architecture rules

The architecture of a cluster, including the appointment of masters, is governed by numerous rules.

• A node must be a registered member of the cluster before it can be promoted to a master. The only exception is the primary master when there are no other nodes in the cluster.
• At a minimum, you must specify a primary master for the cluster.
• You must activate the product on the primary master of the cluster before any other node. If you use the internal runtime database in a Security Access Manager for Mobile cluster, activate Security Access Manager for Mobile on the secondary master before the other nodes.

  Ensure that the product is activated on the masters before it is activated on any of the individual nodes in the cluster.

• The primary and secondary masters of the cluster must be activated at the highest level of all the nodes in the cluster. If any node in the cluster is activated with Security Access Manager for Web, the primary and secondary masters must also be activated with Security Access Manager for Web. Similarly, if any node in the cluster is activated with Security Access Manager for Mobile, the primary and secondary masters must also be activated with Security Access Manager for Mobile. Activation levels are validated when:
  • A node joins the cluster. Such validation is to ensure that the primary and secondary masters are activated to at least the same level.
  • A new primary or secondary master is set. Such validation is to ensure that the activation level of the new master is at least at the same level as the current primary master.
• You cannot specify a master without first specifying each of the prior masters. For example, you must specify the secondary master before you can specify a tertiary master.
• You cannot specify a tertiary master without also specifying a quaternary master.
• If you specify a secondary master, you must also specify the master external reference entity (ERE).
• If you specify a quaternary master, you must also specify the replica ERE.
• You can modify the cluster policy on the primary master only, unless you are promoting a local node to primary master in a disaster recovery situation.
  Note: If the primary master is unavailable when this policy change is made, it is not aware of the newly appointed primary master.

  When it restarts, the original primary master attempts to resume responsibility as the primary master and reset the cluster configuration to the last known state before it failed. That is, the primary master that was promoted during disaster recovery is demoted back to its original role in the cluster.

  To avoid this situation and retain the new primary master, you can use either of the following approaches:

  • Reinstall and then configure the failed primary master.
  • Reconfigure the failed primary master while it is isolated from the rest of the network.

  After this reconfiguration, the old primary can join the cluster again.