Symanec Encryption Desktop clients cannot connect to the Symantec Encryption Management Server when one server is unavailable, even though there are two or more Encryption Management Servers in a cluster.
Web Email Protection messages may not be visible when logging in to an inbox.
Two or more Encryption Management Servers in a cluster.
By default, the Encryption Desktop installation file downloaded from Encryption Management Server contains the FQDN (fully qualified domain name) of the server from which the installation file is downloaded.
During the enrollment process, the client is bound to a single Encryption Management Server. If that server is unavailable, the client will not be able to connect.
For Web Email Protection, if a user logs in to one FQDN, and was redirected to a cluster node that has not received the clustered data yet.
In a clustered environment, a FQDN that can resolve to more than one Encryption Management Server is required in order to provide fail over for clients. For example, the FQDN might be keys.example.com.
This FQDN is specified in the Symantec Encryption Server text box in the Consumers / Groups / Download client page of the admin console.
Because the clients connect to the server over a secure channel, each Encryption Management Server in the cluster requires an SSL certificate with a Common Name that matches the FQDN to which the clients connect. For example, the certificate Common Name might be keys.example.com.
Symantec recommends that cluster replication should be configured to use network Interface 1 and that each interface used for clustering should have a unique SSL certificate. See TECH157115 for further information. For example, in a three member cluster consisting of sems1.example.com, sems2.example.com and sems3.example.com, Interface 1 of sems1 would have a certificate with the Common Name sems1.example.com, Interface 1 of sems2 would have a certificate with the Common Name sems2.example.com and Interface 1 of sems3 would have a certificate with the Common Name sems3.example.com.
Since Interface 1 is used for replication and each server has a unique certificate assigned to Interface 1, client communications need to be handled by a different Interface, usually Interface 2.. The same SSL certificate needs to be assigned to all servers that handle client traffic because the clients need to trust it. For example, all servers might have the certificate for keys.example.com assigned to Interface 2.
Round Robin for the purpose makeshift load balancing is not supported. See TECH232699 for further details. Therefore, DNS can be used to point the FQDN to which the clients connect to a specific server in the cluster. If that server becomes unavailable, DNS can be updated to point the FQDN to another server in the cluster. For example, keys.example.com might point to Interface 2 of sems1 which has an IP of 10.10.10.11. If sems1 is unreachable, the DNS entry might be changed to point to Interface 2 of sems2 which has an IP of 10.10.10.12.
As an alternative to DNS, a load balancer can be used. However, the load balancer must not be configured to use Round Robin, even though it is the default for most load balancers. Depending on the specific load balancer, the following methods can be used in order of preference:
Ordered List or First Alive
This is where the servers are listed in a specific order. For example, with three servers it might be: 10.10.10.11, 10.10.10.12, 10.10.10.13.
Clients will always be directed to the first host in the list unless it is unavailable, in which case clients will be directed to the second host and so on.
This method is available with some load balancers from, for example, Cisco and IBM.
Weighted Round Robin or Ratio
This is where each host in the list is given a weighting so that traffic is not distributed evenly to each of them.
The host with the highest weighting receives the most requests. For example, the load balancer vendor may allow weightings between 1 and 10 to be used. The server with a weighting of 10 will receive ten times more traffic than the server with a weighting of 1.
By giving one server in the cluster the maximum weighting and the other servers the minimum weighting, an acceptable load distribution profile can be achieved. For example, 10.10.10.11 might be given a weighting of 10 and both 10.10.10.12 and 10.10.10.13 given a weighting of 1. This would mean that 10.10.10.11 received the vast majority of the traffic.
This method is available with many load balancers from, for example, Cisco, F5, Citrix and IBM.
In all cases, the so-called "sticky bit" or "persistence" should be set so that clients do not connect to a different server during their session.
Imported Document ID: TECH193552
Subscribing will provide email updates when this Article is updated. Login is required.