The fail-safety of the SEPPmail Secure E-Mail Gateway can be increased by the formation of a cluster.
The SEPPmail Secure E-Mail Gateway has an integrated cluster functionality based on the CARP protocol (see also http://de.wikipedia.org/wiki/Common_Address_Redundancy_Protocol).
To form a cluster, at least two SEPPmail Secure E-Mail Gateways monitoring each other are required. If one system fails or no longer responds to monitoring requests, the second system takes over its function. If the failed system is available again or if it responds to monitoring requests again, it resumes its original task.
This function can be mapped with up to nine SEPPmail Secure E-Mail Gateways, which guarantees a very high level of failure safety.
The high-availability cluster can be mapped with both SEPPmail Secure E-Mail Gateways on a hardware basis as well as based on virtualised appliances. A mixed operation of both systems is also possible.
Function of a high-availability cluster
In this method, one or more virtual IP addresses with different priorities are assigned to a cluster. Each cluster member system has its own unique IP address, irrespective of the assigned virtual cluster IP address. This unique IP address can be used to address each cluster member system specifically.
Example:
The following figure shows the virtual cluster IP address of cluster 10.10.0.1. In our example, the cluster member systems have the IP addresses 10.10.0.9 and 10.10.0.10.

Figure 2 - Schematic representation of a high-availability cluster
The cluster itself is addressed by other systems, for example, an internal email server or an upstream email relay server (gateway) via the configured virtual IP address(es). In the example above, this is the IP address 10.10.0.1.
If the cluster itself is addressed via its cluster IP address, the cluster member system with the highest priority is always the one to react to the addressed virtual cluster IP address. All other cluster member systems with a lower priority do not respond to the cluster virtual IP address as long as a cluster member system with a higher priority is available.
If the cluster member system with the highest priority fails, a cluster member system with the next highest priority automatically assumes the virtual cluster IP address, including the function of the failed cluster member system.
The priorities are arranged in the following order:
1. Primary
2. Secondary
3. Backup
The priority of the corresponding cluster member system is to be set up in System Advanced view IP ALIAS addresses Priority).