Symantec Encryption Management Server DMZ mode Cluster Members do not dynamically update their Replication Topology

Products

• Encryption Management Server
• Gateway Email Encryption

Issue/Introduction

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:

1. When a change occurs on Member 4 it will try to replicate the change to Member 1, even though Member 1 is unreachable. Hence, data will not replicate from Member 4 to Members 2 and 3.
2. When a change occurs on Member 3 it will replicate to Member 4 but will not replicate from Member 4 to Member 2.
3. When a change occurs on Member 2 it will replicate to Member 3 and will also replicate from Member 3 to Member 4.

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:

1. When a change occurs on Member 4 the change is replicated to Member 3 because there is 2-way replication between Members 3 and 4.  However, the change is still not replicated to Member 2.
2. When a change occurs on Member 3 it will replicate to Member 4 but will not replicate from Member 4 to Member 2.
3. When a change occurs on Member 2 it will replicate to Member 3 and will also replicate from Member 3 to Member 4.

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:

# pgprepctl topo

myUpstream: cluster_member_3.domain.dom/10.1.2.3

myDownstream: /10.1.2.1

Cause

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.

Resolution

This behavior should be considered when deciding whether to use DMZ mode.

Applies To

Observed with Symantec Encryption Management Server 3.3.2 MP1 but almost certainly applies to all 3.x releases.