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.
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.
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.
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.
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.
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.