If a Symantec Encryption Management Server cluster contains DMZ mode cluster members, the DMZ mode cluster members do not dynamically update their cluster topology if a cluster member becomes unreachable. Internal (non-DMZ) cluster members do dynamically update their replication topology if a member becomes unreachable.
For example, in a 4 member cluster with 2 DMZ mode members hosting private keys, the topology may be as follows when all members are reachable:
If Member 1 becomes unreachable owing to, for example, a network issue then Member 2 will dynamically update its state and therefore use the following replication topology:
However, Members 3 and 4 are DMZ mode members and will therefore not update their topology; they will behave as if Member 1 is still reachable. This means that:
In summary, replication will be significantly degraded and therefore unreliable.
If the DMZ cluster members do not host private keys, the replication topology is normally more complex. Replication is therefore usually less degraded when an internal cluster member is unreachable.
For example, if a 4 member cluster with 2 DMZ members was configured so that the DMZ members did not host private keys, the replication topology might look like this. Note the 2-way replication between Members 3 and 4 and between Members 1 and 2:
If Member 1 is unreachable then the topology on Member 2 will be updated dynamically but it will not be updated on Members 3 and 4. The new topology on Member 2 will be as follows:
Members 3 and 4 will behave as if Member 1 is still reachable. This means that:
In summary, replication is still degraded but not as severely as when the DMZ cluster members host private keys.
No error message is seen. However, if Member 1 is unreachable, Member 4 will show no hostname for Member 1 when the pgprepctl topo command is run:
This behavior is by design. DMZ mode cluster members cannot initiate replication. In practice this means that their clustering topology is permanently fixed and they cannot update their topology dynamically in response to a change in the number of reachable cluster members.
This behavior should be considered when deciding whether to use DMZ mode.
Observed with Symantec Encryption Management Server 3.3.2 MP1 but almost certainly applies to all 3.x releases.