This article describes the offline behavior when a Primary or Secondary PGP Server becomes unavailable.
For information on what the PGP Desktop client does if the PGP server goes offline, see the following article:
153217 - Symantec Encryption Desktop Offline Behavior (PGP Desktop)
If a PGP server is unavailable for a time, there are critical features that may not be available. This risk can be reduced by using Load Balancing so that if one PGP server goes down, the load balancer will redirect the PGP Desktop client to the other server that is still online. For more information on this topic, see the following articles:
This document describes the behavior of Primary and Secondary PGP Servers when the server becomes unavailable or disconnected from the network.
When you have two or more PGP Servers operating in your organization, you can configure them to synchronize with each other; this arrangement is called a cluster.
In a cluster, one of the PGP Servers is designated as the Primary server for the cluster; all other cluster members are designated as Secondary servers. The Secondary servers in a cluster synchronize their users, keys, managed domains, and policies with the Primary server. Cached keys found in the mail flow are also replicated across the cluster.
The benefits of clustering include lower overhead (spreading the system load between the PGP 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, including the Primary server.
Primary Server VS Sponsor Server
The following text describes the behavior of a Primary server when the server becomes unavailable. There is actually no difference between a Primary and Secondary servers unless you specify. When a PGP server is in a cluster, they all act as a "Primary", and it all depends on which services the PGP Server is hosting. If one server does not host all services, then you may consider that server to be your "Primary", although this nomenclature does not align exactly with the PGP Server because once the server enters a cluster, it has the capability to do everything another server has in every way and it is up to you to customize the services available.
If you do have all services enabled on all PGP Servers, then they are all considered "Primary" servers. When a Primary Server in a PGP Server cluster is unavailable or disconnected, the synchronization of users, keys, managed domains, and policies will not occur with other Secondary servers in the cluster. A Secondary cluster server cannot do everything the other server did if the services were not previously enabled and if all data, such as Web Email Protection were replicated across the clusters. For example, in "DMZ Mode", you can choose not to replicate PGP Private keys. If the server that has private keys goes down, this will drastically change the landscape for availability so special consideration should be made.
Secondary Server(s)
The following text describes the behavior of a Secondary server when the server becomes unavailable. When "Secondary" server is mentioned, that means a PGP Server that may not have all of the data that other nodes have. They are ultimately simply "Cluster Members" and need to be taken into consideration and really all nodes are "Primary", but with added or removed services depending on what the configuration is that you choose.
When a Secondary cluster member becomes unavailable and disconnected from the Primary, it will not receive synchronized data.
Once a cluster member becomes available again, a resynchronizing of data should occur and depending on how long the cluster member was down, could take several hours, particularly if PGP Web Messenger is in High Availability Mode. All services on the Secondary are stopped while resynchronization occurs.
Note: High Availability Mode replicates new PGP Server Web Messenger user accounts on all clustered universal servers running the service. All external user account information exists on all members of the cluster. If a cluster member is not functioning, PGP Universal Web Messenger users will still be able to use the service. It is best to have Web Email Protection enabled on all cluster members for redundancy and the replication option set to "All" |
If you need more information on what happens with the PGP Desktop client if the PGP server goes down or cannot be reached, see the following article:
153217 - Symantec Encryption Desktop Offline Behavior (PGP Desktop)