Clustering allows multiple PGP Universal Servers in an organization to synchronize with each other.
When you have two or more PGP Universal Servers operating in your organization, you can configure them to synchronize with each other; this arrangement is called a “cluster.” The benefits of clustering include lower overhead (spreading the system load between the PGP Universal Servers in the cluster means greater throughput) and the ability for email services to continue working even if one of the servers in the cluster goes down.
Servers in a cluster can all keep data replicated from the other servers in the cluster: users, keys, managed domains, and policies. For those servers running PGP Universal Web Messenger they can also replicate Web Messenger data.
Cluster members interact with each other as peers. Every server in a cluster can serve all types of requests, and any server can initiate persistent changes.
For the most part, cluster members all share the same database and configuration information -- changes on one are replicated to all the other cluster members. However, not all configuration settings are global, and it is possible to configure a cluster such that not all servers in the cluster provide all services.
The following settings and data are considered global and are replicated to all servers in the cluster:
- Consumers (internal and external users, devices, and their public keys and properties)
- Group configurations, the group's public key, and consumer policies
- Managed domains and mail settings (policies, dictionaries, archive servers, message templates)
- Directory synchronization settings
- Organization keys and certificates
- Ignition keys
- Trusted keys
- Configured keyservers
- Web Messenger data, if replication is enabled and if the target server has a valid license
- Learn Mode
- PGP Verified Directory data (though the service can be enabled or disabled on individual servers).
The following settings are not replicated:
- Server TLS/SSL certs
- Mail routes
- Mail proxies
As the administrator, you have some degree of control over what data is replicated to which cluster members:
- You can allow or prevent the private keys of internal users and groups from being replicated to individual servers.
- You can configure the Web Messenger service to run only on a subset of cluster members, which limits Web Messenger data replication to only those servers running Web Messenger. Further, you can configure Web Messenger data replication so that it is replicated only to a subset of the eligible cluster members. For example, if you have a cluster of four servers, three of which run Web Messenger, you can configure Web Messenger replication so that each user's mailbox is replicated to only one or two of the three eligible servers.
- You can choose to set the order in which each cluster member searches LDAP directories, or specify that all cluster members use the same search order.
Cluster members may reside either inside or outside an organization's inner firewall -- members outside the firewall are considered to reside in the DMZ. Cluster members in the DMZ cannot initiate contact with systems on the internal network; therefore, in order to add a cluster member that resides in the DMZ, a server on the internal network must be configured first, and can then initiate a join, acting as the "sponsoring" server for the server in the DMZ.