Best Practices: Environmental Requirements for Symantec Encryption Management Server clustering (AKA PGP Server)

Products

Encryption Management Server Desktop Email Encryption Drive Encryption Endpoint Encryption File Share Encryption Gateway Email Encryption PGP Command Line PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK

Issue/Introduction

Symantec Encryption Management Server (AKA PGP Server) uses clustering for redundancy and additional functionality.

This article will go over the best practices to help you have reliable clustering and for best performance.

For more information on Clustering, see the following article:

153721 - Creating a Cluster with Symantec Encryption Management Server

Resolution

Typically, the PGP Server will cluster just fine without having to really worry about anything on the network. As long as port 444 is open in both directions between the servers, the servers will typically function just fine.

In scenarios where you may be encountering some odd behaviors, check the below to see if adhering to these best practices can help ensure a healthy cluster with optimal performance.

Section 1 of 7: Disk Space Requirements
Section 2 of 7: Network Requirements
Section 3 of 7: Name Resolution Requirements
Section 4 of 7: SSL Certificate Requirements
Section 5 of 7: Directory Synchronization Requirement
Section 6 of 7: Database Schema Requirement
Section 7 of 7: VMTools and Time Requirements

Important Note on Cluster Size

The PGP Server supports a max of 6 cluster nodes. For more information on this, see the following article:

153476 - How many PGP Servers are supported in a cluster (Symantec Encryption Management Server)?

Section 1 of 7: Disk Space Requirements

1. Make sure the joiner server has at least 4-5 times the space as the size of the backups. If your backups of the Sponsor server are 50GBs, and you want to add a cluster member, then the size of the joiner server should be 250GBs. However; disk sizing requirements should also be based on the needs of a server. If the PGP server is going to be processing email, Symantec Encryption recommends using a disk size of 800GBs to ensure there is plenty of space and will not need to be resized later on. This will also ensure that the join process of cluster members will not be inhibited by space limitations. If you are going to manage the PGP Clients only, a hard drive of 100GBs is typically sufficient.

Section 2 of 7: Network Requirements

1.Network interface subnets & broadcast domain
Each server should have only one network interface on each subnet. It is not recommended to have multiple network interfaces on the same broadcast domain per server.
For more information on this, see the following article:

155389 - PGP Universal Server configuration with Multiple Interfaces on the same subnet: WARNING

2.Server-to-server connectivity

Each server must be able to connect to all other servers on port 444. This requirement may require adjusting firewall or router configurations.

3.Telnet
It is helpful to have telnet available and allowed between the servers over port 444. This is used for troubleshooting network connectivity issues between servers. This may require adjusting firewall or router configurations.

4.MTU size
When using MPLS (MultiProtocol Label Switching) or a VPN tunnel you MUST lower the MTU (Maximum Transmission Unit) instead of 1500. This is best if done in increments of 8. A recommendation would be 1396. But make sure you research what is required for your MTU settings to be lowered. If this is not done clustering may fail or perform slowly as packet headers can be stripped.

5. Network Latency
Network latency is a consideration when working with any solution that requires network connectivity to function. For the PGP Server, as with any network solution, the lower the latency the better the results. Having a network latency around 20ms should not pose any potential clustering problems as long as no packets are being dropped this is an acceptable level of latency.

Around the 50ms mark is where you may want to start to be concerned and look to see if improvements can be made, but generally, no severe issues should be observed. In general terms, network latency above 100ms is considered poor and should be reviewed for increased throughput.

Section 3 of 7: Name Resolution Requirements

1. Unique server names
Each cluster member MUST a unique Fully Qualified Domain Name (FQDN).

2. Hostname is Fully Qualified Domain Name
The FQDN should be entered as the server's hostname. (This can be modified after install: System => Network => Hostname).

3. Name resolution required
Each cluster member MUST be able to resolve the FQDN of all cluster members using DNS. This requirement may require adjusting firewall, router or DNS configurations.

4. Reverse DNS required
The IP address returned for each clustering FQDN MUST have a corresponding PTR record in DNS resolving back to the FQDN. This means each clustering interface should have two entries (one forward and one reverse) in DNS.

TIP: DNS needs to be reliable for clustering to work when using FQDNs. If this is not available, then IP addresses is a better option to use for the clustering service. In some environments where DNS could potentially be changed, using IP addresses will ensure clustering will not be affected.

5. No network address translation (NAT)

The IP address obtained for each server's FQDN MUST be consistent across the cluster. Using network address translation, NAT, between cluster members is NOT supported.

6. DNS Round Robin/Load Balancers
Load Balancers and DNS Round Robin is not supported for the clustering service for port 444. In other words, clustering must be done server-to-server over port 444. See the following article for more information on this topic:

156803 - Using DNS Round Robin and Load Balancers and Reverse Proxies with Encryption Management Server

Section 4 of 7: SSL Certificate Requirements

1.SSL certificate required
Each server needs an SSL certificate, and the name on the certificate should match the FQDN of the clustering interface.

2.Current SSL Certificate
Each SSL certificate MUST be current rather than expired.

3.Trusted certificates (including possible root certificate update for Symantec)
Each SSL certificate MUST be from a recognized certificate authority. Also verify that the Root and Intermediate CA certificates that your client certificate is issued under is imported into the Trusted Keys section of the Symantec Encryption Management Server (previously PGP Universal Server). For more information on using TLS certificates with Symantec Encryption Management Server, see the following article:

180416 - How to Install an SSL Certificate for Encryption Management Server

4.Self-signed certificates must be trusted
If you are using self-signed certificates, you will want to export the public portion of each server's certificate and then import that into the Trusted Keys store on each server.

Section 5 of 7: Directory Synchronization Requirement

1. LDAP servers reachable on all cluster members
When using Directory Synchronization, at least one LDAP server from each configured directory has to be reachable on each of the hosts. Each server has to be able to query all configured directories. These queries are not forwarded through the clustering connection.

Load balancer Requirement

1. No load balancing for cluster interfaces
Network connections to the clustering interface (and FQDN) MUST NOT go through any sort of load balancer (either as the gateway or during later network routing). This may require additional network interfaces configured on the server and static routes setup to route your traffic through multiple gateways. This requires assistance from Symantec Technical Support.

For more information on load balancers with PGP Server, see the following article:

156803 - Using DNS Round Robin and Load Balancers and Reverse Proxies with Encryption Management Server

Section 6 of 7: Database Schema Requirement

1. Matching database schema
The database schema must match between all cluster members. If you have schema errors reported in the logs please contact Symantec Encryption Support to resolve this issue.

Section 7 of 7: VMTools and Time Requirements

1. VMware tools
Starting with Symantec Encryption Management Server 10.5, VMware tools are installed natively and no further action is needed.

Older versions of the PGP server required installing these vmware tools. Symantec recommends upgrading to the supported versions of the encryption server to continue to receive support.

2. Consistent time between cluster members
All cluster members MUST have consistent time configuration. (It is usually easiest to configure all server to use a single NTP server.) Using an NTP server may require adjusting firewall or router configurations.

3. NTP or VMware time sync (not both)
The PGP Encryption Server needs to have the same time on each of the cluster servers. If you have configured "Local time", it's possible there could be clock skew, such as the following cluster log entry:

Using an NTP server is a good idea to ensure the PGP Server are all going to have the same time.

Note: If you are running in VMWare you may not be able to use both NTP and VMWare Time Sync.
Either deactivate time sync or do not use NTP. See the following article for information on time as it relates to Symantec Encryption Management Server:

153447 - Encryption Management Server shows incorrect time

See the PGP server Product Documentation portal for more information on other important topics.