SecurityGateway's Clustering feature is designed to share your configuration between two or more SecurityGateway servers on your network. The steps below detail deployment considerations and how to configure clustering for SecurityGateway.
SecurityGateway's clustering feature makes it possible for you to use load balancing hardware or software to distribute your email load across multiple SecurityGateway servers, which can improve speed and efficiency by reducing network congestion and overload and by maximizing your email resources. It also helps to ensure redundancy in your email systems should one of your servers suffer a hardware or software failure.
Here are a number of things to consider when deciding whether or not to set up a SecurityGateway cluster on your network:
A SecurityGateway cluster will have a primary node and secondary nodes. One SecurityGateway server will be designated as Primary and all the others as Secondary.
- Each node in the cluster needs to be running the same version of SecurityGateway.
- Each node in the cluster requires its own SecurityGateway registration key. You cannot use the same key on multiple nodes.
- Each node in the cluster should be on the same network. The clustering system is not designed to have nodes that are geographically separate.
- All nodes in a cluster should be set to the same time zone, and set to the exact same time. Substantial differences in the system time on each node can cause problems.
- Configuration changes can be made from any node in the cluster. When a configuration change is made all other nodes will be notified of the change. Note, however, that the HELO Domain Name is a per-server setting and can therefore be set to a unique value on each server in the cluster.
- The primary node is responsible for maintenance tasks such as Bayesian learning.
SecurityGateway does not handle the routing of any traffic to or from specific nodes. We recommend that you use a third-party load balancer to handle the routing of traffic.
Sticky sessions in your load balancer is required so that all traffic from the same IP is routed to the same host. Sticky sessions is most important for those signing in to SecurityGateway's web-interface, so that if someone signs in to a specific server then all traffic for that session will be routed to that same server.
Shared Database and Folder Locations
In a SecurityGateway cluster, all servers share the same database and a specific set of folders. Therefore all nodes must be on the same network and all of the shared locations must be accessible to all nodes. Because the SecurityGateway service runs as the LocalSystem account by default, and because LocalSystem does not have access to any network resources, you must configure the service to use an account that has permission to access those network locations. See: Configuring SecurityGateway to Use Network Accessible Data Folders below.
In order to use Archiving with Clustering, your Archiving settings will need to be configured to use the Firebird Database Server and use network paths so that all nodes can access the Archive stores.
- HTTPS settings (including certificates) are per node and will need to be specified for any node added to the cluster. Certificates are stored on each node, not in the database. Therefore if you wish to use the same certificate on each node, you will need to manually import that certificate on each node and configure each SecurityGateway to use the certificate.
- The STARTTLS Whitelist and STARTTLS Required list configurations are shared.
- SecurityGateway's LetsEncrypt options do not support secondary nodes at this time.
Setting Up Clustering
Upgrading Your Database
If you wish to use Clustering and you've updated SecurityGateway to version 7.0 or later from an earlier version, then you will first need to use the included SGDBTool.exe to convert your SecurityGateway database file from Firebird 2.x to Firebird 3.x. If this is a new installation of SecurityGateway 7.0 or later, then you can skip this step, as your version is already using a Firebird 3.x database.
Follow these steps to upgrade your database:
- Stop the SecurityGateway service (click Stop SecurityGateway in the SecurityGateway Start Menu folder, or use the Services console).
- Open the Windows Command Prompt.
- Switch to your \SecurityGateway\App\ folder.
- Type: sgdbtool.exe -convertfb3, and press Enter.
This will save a backup copy of your Firebird 2.x database file as "SecurityGateway.fb2". Then it will restore your database using the Firebird 3.x runtime and save it as "SECURITYGATEWAY.FBD". If you are using Archiving then this will also upgrade any archiving database files.
Configuring SecurityGateway to Use Network Accessible Data Folders
All nodes in a SecurityGateway cluster share the same database and a common set of several folders. Therefore all nodes must be on the same network and you must ensure that the Windows Service for each node is configured to use an account that has permission to access the shared locations. You must also ensure that each node is properly configured to use those locations. If you need to move the contents of the shared folders to a new location in order to share them with all nodes, you must move them manually. SecurityGateway will not migrate existing files for you. The following shared folders are used and can be configured from both the Directories page and Clustering page (except for Bayesian Replication, which can only be configured from Clustering):
- Message Data (e.g. \\Share01\SecurityGateway\Messages\)
- Message Logs/SMTP Transcripts (e.g. \\Share01\SecurityGateway\Transcripts\)
- Attachments (e.g. \\Share01\SecurityGateway\Attachments\)
- Bayesian Learning Non-spam (e.g. \\Share01\SecurityGateway\BayesHam\)
- Bayesian Learning Spam (e.g. \\Share01\SecurityGateway\BayesSpam\)
- Bayesian Replication (e.g. \\Share01\SecurityGateway\BayesReplication) Note: This folder is unique to Clustering. It is the location to which the primary node copies its Bayesian database, and from which the other nodes replicate that data.
The database location and credentials are specified during installation, or by using SGDBTool.exe for existing installations (see: Configuring SecurityGateway to Use the External Database Server below).
If you are using the Archiving feature then you will also need to relocate your Archive Stores to a network accessible location, and each Archiving database file will need to be moved to the Firebird Database server. See: Using Archiving with Clustering below.
Setting up the Firebird 3 Database Server
In order to use Clustering, you must install the Firebird 3 database server at a network location accessible to each node in the cluster.
To set up your Firebird 3 server:
- Download the Firebird 3 Database Server.
- Run the installer on a machine that will be accessible to all nodes.
- Accept the License Agreement, and click Next.
- Read the information, and click Next.
- Choose a folder, and click Next.
- On Select Components, click Next.
- Choose a name for the Start Menu folder (or click Don't create a Start Menu folder), and click Next.
- Leave the Select Additional Tasks options set to the default values (i.e. SuperServer mode, Run as a Service, and Copy client library), and click Next.
- Type and Retype a SYSDBA password (the "SYSDBA" username and this password will be needed later), and click Next.
- Click Install
- Click Next
- Click Finish
Configuring SecurityGateway to Use the External Database Server
In a SecurityGateway cluster, each node must be configured to connect to the same database file, which must be located on the Firebird 3 database server you set up in the previous section. To set up SecurityGateway to use the external database server:
- On the Firebird server, create a folder for your database file (e.g. C:\Databases).
- Copy your primary SecurityGateway database file (i.e. \SecurityGateway\App\SECURITYGATEWAY.FBD) to that location.
- On your SecurityGateway server, open the Windows Command Prompt.
- Switch to your \SecurityGateway\App\ folder.
- Type: sgdbtool.exe -setdbconnect, and press Enter.
- For "Use embedded Firebird database Y/N?" type N, and Enter
- For "Enter Firebird Server IP", type the IP address of the Firebird server (e.g. 10.10.0.1), and press Enter.
- Press Enter for "Enter Firebird Server Port (default 3050)".
- For "Enter Firebird Database Path or Alias", type the full path to the database file that you copied to the Firebird server (e.g. C:\Databases\SECURITYGATEWAY.FBD), and press Enter.
- Press Enter for "Enter Firebird Database Username (default SYSDBA)".
- For "Enter Firebird Database Password (default masterkey)", type the password you created when installing the Firebird 3 server, and press Enter.
Your Primary SecurityGateway node should now be connected to the external database server.
Using Archiving with Clustering
To use Archiving with Clustering:
- Create a folder or folders on your Firebird Server for your Archiving database files (e.g. "c:\databases\Archives\Example.com," "..\Archives\company.com," etc.).
- Create network accessible folders for each of your Archive Store's Storage Locations.
- Copy all of your Archive Store files to these new locations.
- Edit each of your Archive Store storage locations to use UNC file paths, pointing to their new locations.
- Edit each of your Archive Stores to Connect to a Firebird database server instance, and enter the Database Path/Alias Name for each of the database files.
- Edit your Automatic Archive Store Creation settings as needed, setting UNC file paths and modifying macro usage to support Clustering.
Adding Nodes to Your Cluster
To add a new SecurityGateway installation to your cluster:
- Run the SecurityGateway installer on the machine to be used as the new node.
- During installation, choose the option to "connect to an external database server" and use the information you entered in the previous section.
- Proceed with the rest of the installation normally.
- Ensure that you are using the appropriate account credentials in the Windows Service section, and that you have configured the new server to use UNC file paths to connect to the shared data folders.
- Copy any necessary SSL certificates to the new machine.
Active/Active Database Replication
If you wish to use active/active database replication for your cluster, SecurityGateway does support that functionality, but it requires an external replication tool and its configuration is beyond the scope of this help file.