5.15. Scalable deployment operation

Overview

The problem

Each Email Gateway Security standalone or bundle instances have their own email history database. The email history database stores the information about email processing results and quarantine.

As a consequence, in standalone or bundle deployments, the exact instance that processed a particular email must be known, so that a certain email can be released from the quarantine, for example.

The separate email history databases are not synchronized.

images/inline/034c75058c3c8d14612d8a95bc942df288374574.png

Solution

In a scalable deployment Email Gateway Security instances work on a shared email history database. The database runs on the primary instance, and the secondary instances connect to the primary instance’s email history database.

With this solution all instances see the same database. It is irrelevant, on which instance an email history or quarantine operation is performed, all instances will see the same.

images/inline/59b1bcb9943771b5aa2658696fc2b3cf25e76db5.png

Email Gateway Instances must be installed in the scalable mode so that a scalable deployment can be set up. For details about the scalable mode installation see 3.3.1. Scalable deployment.

Limitations

Single point of failure

The email history database is a single point of failure in a scalable deployment. A potential workaround is to take regular backups of the shared email history database.

For details see section Backup and restore history database.

Quarantine reports

Settings > Quarantine reports and Settings > Alerts & Reports / Quarantine Reports are not available on a secondary instance of a scalable deployment. The quarantine reports must be configured on the primary instance.

For details see 4.13. Quarantine reports and 4.8. Alert, notification and quarantine report emails.

Dashboard

In a scalable deployment the Dashboard shows information about emails on all connected instances.

For Dashboard details see 5.1. Dashboard.

Email History

In a scalable deployment the Audit > Email History shows emails from all connected instances by default.

For Audit > Email History details see 5.2. Email History.

Processing information

The Processing information view shows the name of the actual instance where the particular email was processed.

Instance naming

For information about how to name instances see 4.1.1. Scalable deployment related registry configuration.

images/download/attachments/8464787/image-20210427-065845.png

Filtering

In a scalable deployment the Audit > Email History can be filtered for a particular instance, or multiple instances.

Example

To filter for emails processed by the actual instance only, select the name of this instance from the list of instances in the filter.

images/download/attachments/8464787/image-20210427-081034.png

Quarantine

Quarantine is a subset of email history. In a scalable deployment –similarly to Audit > Email History– quarantined items from all instances can be viewed and operated.

For Quarantine details see 5.3. Quarantine.

Example

In a scalable deployment an email can be released from the quarantine even if it was quarantined by an other instance.

Operations

Quarantine operations in a scalable deployment can be executed on emails irrelevant from on which instance the email was processed.

Filtering

In a scalable deployment the Quarantine can be filtered for a particular instance, or multiple instances similarly to Audit > Email History.

images/download/attachments/8464787/image-20210427-081712.png

Backup and restore history database

Single point of failure

The email history database is a single point of failure in case of scalable deployments.

To mitigate the single point of failure risk, an Email Gateway Security primary instance takes automatic backups of the email history database regularly.

The backup is taken in the beginning of the database optimization process that is executed at the time configured by the scheduled_db_optimization_time registry option.

For registry configuration details see 4.1. Registry configuration.

For details about how the backup is taken, and how to restore it, see 5.16. History database backup.