As displayed in "Figure 3", the incoming and outgoing email data flow is separated by means of a static configuration in which, in addition to the physical IP addresses of the appliance, two additional, virtual IP addresses (IP alias addresses) are used. Here, two SEPPmail Secure E-Mail Gateways exist, which react to the two virtual IP addresses with opposite priority. This means that one system receives all incoming emails, while the other handles all outgoing emails.

 

In detail

 

Reliability

 

Each SEPPmail Secure E-Mail Gateway has its own physical IP address, through which only this system can be accessed. This address is typically used to configure the appliance individually and to synchronise appliances with each other (blue arrows "Figure1"). In "Figure 3", these are the IP addresses 10.10.0.9 and 10.10.0.10.

 

Additionally, two virtual IP addresses are set up in order to logically group the two SEPPmail Secure E-Mail Gateways in one group. In "Figure 3" these virtual IP addresses (groups) are displayed in different colours.

Here, the virtual IP address 10.10.0.1 (green) is addressed by the internal email server for sending outgoing emails. Since this virtual IP address is served primarily by the machine with the physical IP 10.10.0.9, the entire outgoing email traffic flows via this system in normal operation.

The virtual IP address 10.10.0.2 (orange) is addressed by the external email server or an upstream email relay (for example firewall) for receiving incoming emails. Since this virtual IP address is served primarily by the machine with the physical IP 10.10.0.10, the entire incoming email traffic flows via this system in normal operation.

 

Displayed in green "in Figure 3", the virtual IP address 10.10.0.1 is responsible for all outgoing emails. Here, the cluster member system with the IP address 10.10.0.9 is set up as primary and is always the first system to react if the virtual IP address 10.10.0.1 is addressed. The cluster member system with the IP address 10.10.0.10 is set up as secondary and only reacts if the cluster member primary – i.e. the system with the IP address 10.10.0.9 – is unavailable.

 

Displayed in orange "in Figure 3", the virtual IP address 10.10.0.2 is responsible for all incoming emails. Here, the cluster member system with the IP address 10.10.0.10 is set up as primary (contrary to the previous figure) and is thus always the first system to react if the virtual IP address 10.10.0.2 is addressed. The cluster member system with the IP address 10.10.0.9 is set up as secondary and only reacts if the cluster member primary – i.e. the system with the IP address 10.10.0.10 – is unavailable.

This means that, if a machine in this constellation fails, the respective other machine assumes its task. Based on the example shown in "Figure 3", this would mean that in the case of a failure of the system with the physical IP 10.10.0.9 – which is primarily responsible for the outgoing email traffic via the virtual IP address 10.10.0.1 – the secondary system configured for the virtual IP address 10.10.0.1 – i.e. the one with the IP 10.10.0.10 – would additionally assume the task of handling the outgoing email traffic.

 

Load balancing

 

To be able to overcome load peaks as they occur, the SEPPmail Secure E-Mail Gateway also offers the possibility in such an environment to transfer some of the workload of the primary system load to the secondary system once a defined load status has been reached (see also System Advanced view SMTP loadbalancer)

 

Summary

 

Each individual SEPPmail Secure E-Mail Gateway can be addressed via two different virtual IP addresses and reacts with different priorities, either as primary or as secondary. As a result, operation is still possible even if one cluster member system fails. The remaining cluster member system then takes over the tasks of the system that is no longer available, and will process all incoming and outgoing emails.

 

For the provision of the GINA technology, or its interface, another virtual cluster IP address 10.10.0.1 can be addressed. Depending on the cluster member priorities, the cluster member system with the IP address 10.10.0.9 will respond in the example of Figure 3 since this is set with the priority "Primary". If this system is unavailable, the cluster member system with the IP address 10.10.0.10 will respond since this is set with the priority "Secondary".

 

The setup of the virtual IP addresses and the assignment of priorities of the respective cluster member system is to be realised in System Advanced view IP ALIAS addresses.

 

Figure 3 - Schematic representation of the static distribution for incoming and outgoing emails