Using DNS Round Robin and Load Balancers with Encryption Management Server
Article ID: 156803
Updated On:
Products
Issue/Introduction
Load Balancers are a valuable and critical part of failover in any network infrastructure and using a Load Balancer with Symantec Encryption Management Server (SEMS) is no exception. When done properly, this can offer the failover that is needed in order to continue to have clients communicate with the server when one server may not be available.
When no load balancer is used, but there is a SEMS cluster configuration, the Symantec Encryption Desktop will enroll to a specific server. If that server is unavailable, then the clients will no longer be able to download policy or upload logging data to the server, even though there is a cluster.
Symantec Web Email Protection users may not see all their new messages when they log in if one server is not available, even though other nodes are working, so Load Balancers offer a critical part of resilience and availability in a network architecture.
This article is not intended to be a walkthrough for how to configure a Load Balancer, but will offer some guidance on what you can do to properly configure the Load Balancer so that if one of the SEMS nodes is unavailable, proper failover can occur.
Cause
By default, the Symantec 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 Symantec Encryption Management Server (SEMS). If that server is unavailable, the client will not be able to connect.
For Web Email Protection, a user may be directed to a cluster member that has not received the replicated data yet.
Important Note: If Load Balancers are not configured properly, this can cause unexpected behavior on SEMS, including Unhandled Exceptions. This is due to a user clicking on one link in their WEP inbox, and the LB redirects to a different server midstream. Symantec Enterprise Division recommends having SEMS be configured for only one node. If the node is unavailable, then redirect to other servers, but generally have only one SEMS be configured in the rotation.
Environment
Two or more Encryption Management Servers in a cluster.
Resolution
In a clustered environment, an FQDN that can resolve to more than one SEMS is required in order to provide fail over for SED clients. If one SEMS is not availble, the LB will redirect to the other server that is available.
For this reason, before you start enrolling clients*, establish a good name that the clients will connect to via the Load Balancer so that the Load Balancer will the redirect the traffic.
*This FQDN is specified in the Symantec Encryption Server text box in the Consumers / Groups / Download client page of the admin console, such as keys.domain.dom.
For example, if you have keys1.domain.dom for SEMS Node 1, and keys2.domain.dom for node 2, then when you download the client, configure the name "keys.domain.dom" and that will be the host the LB will be using. When the SED client is installed, it will reach out to keys.domain.dom; the load balancer will accept the connection and it will then redirect to either keys1 or keys2.
Similarly, if keys1 and keys2 host Web Email Protection, then the Load Balancer could be configured with "keys.domain.dom" and this is the host DNS will resolve to, and the Load Balancer will then direct traffic to keys1 or keys2 depending on the situation.
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 article 154069 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.
Important Note: 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. There are several methods to use persistence and your Load Balancer may have more or less of these features:
*Cookie Persistence - The Load Balancer provides a cookie value in the connection stream and when the client uses this, the LB will always be directed to a specific SEMS. This may or may not work in some environments so if cookie persistence is causing issues, look for a different method for persistence.
Note: SED/SEMS 10.5 may not support cookie-based persistence so be sure to test this before going to production.
*Source IP Persistence - The Load Balancer will review the source IP that connected to the SEMS and based on that source, it will always keep that source going to the same server.
*Duration based Persistence - This may keep the connection going to only one host for a certain amount of time and will not switch that connection for any other reason.
Consult your Load Balancer documentation and configuration options to choose which is best for you.
Round Robin for load balancing is not supported. See article 162371 for further details. A single Encryption Management Server can easily service tens of thousands of clients so the main advantage to having a cluster of Encryption Management Servers is high availability and not load distribution.
DNS can be used to point the FQDN that Encryption Desktop clients use to a specific Encryption Management Server. If that server becomes unavailable, DNS can be manually 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:
- Fail-over
- If you have two Encryption Management Servers, configure the load balancer to direct all traffic to one server and fail over to the other if the first is unavailable. Nearly all load balancers can do this.
- 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.
Feedback
