Set up an active/active cluster

You can set up a cluster of SecureTransport Server computers. When you set up a cluster, a shared secret file, called taeh file is used by each of the servers in the cluster for authentication purposes across servers and for encryption. The taeh file contains a randomly-generated data that secures the SecureTransport cookies exchanged during server administration. SecureTransport generates the shared taeh file as part of the installation process. Refer to the SecureTransport Installation Guide for more information.

Note When you install SecureTransport on your secondary computers, you have an opportunity to import the taeh file from the primary server. You can only import the taeh file on a secondary computer during the installation process.

To set up an active/passive cluster, see Manage an active/passive cluster.

  1. Make sure that the hosts file on each SecureTransport Server or SecureTransport Edge host operating system contains the hostnames and IP addresses of all servers with which it communicates: SecureTransport Server, SecureTransport Edge, and internal servers integrated with SecureTransport like LDAP, external database, Sentinel server, SSO server, ICAP server, etc.
  2. Select the computer that is to serve as the primary server.
  3. Make sure that the taeh file of the primary server is installed on all secondary computers.
  4. Set up the secondary servers as independent installations. Add licenses for all servers. For instructions, refer to the SecureTransport Installation Guide or see Server licenses.
  5. Generate an internal CA on each server. For instructions, refer to the SecureTransport Getting Started Guide or see Manage the internal CA.
  6. Exchange CA certificates between all servers in the cluster. For details, refer to the procedures for exporting and importing SecureTransport Server CA certificates in the SecureTransport Getting Started Guide or in Manage local certificates and certificate signing requests.
  7. Make sure that Transaction Manager (TM) servers are stopped on all computers.
  8. On the primary and all secondary servers, list the servers in the <FILEDRIVEHOME>/lib/admin/config/servers configuration file. List the primary server first and continue with the secondary servers in the order you want them promoted to primary server in the event of failover.
  9. Edit the file and add a line of following form for each server in the cluster:
  11. where:
    • is the FQDN or IP address of the computer
    • is the URL of the Administration Tool on that computer
  12. and the two fields are separated by a tab character.
  13. Note The <FILEDRIVEHOME>/lib/admin/config/servers file must be the same on all computer in your cluster. You can create it on one server and copy it to the others.

  14. On the primary server, generate a local certificate for encrypting cluster communications. For instructions, see Generate a self-issued server certificate.
  15. On the primary server, export the certificate in .p12 format protected with a password. For instructions, see Export a local certificate.
  16. Import the certificate on each secondary server. For instructions, see Import a local certificate.
  17. On the primary and all secondary servers, configure encryption for cluster communications. On the Server Configuration page, change the value of the Cluster.Crypto.Alias server configuration parameter to the alias of the certificate.
  18. On the primary server and all secondary servers, activate the cluster. On the Server Configuration page, change the value of the Cluster.mode parameter to active.
  19. Start the TM server on the primary server and wait until it promotes itself as a primary server. Start the TM server on all other servers in the cluster. For instructions, see Start and stop servers.
  20. Synchronize the secondary servers manually from the Administration Tool of the primary server. For instructions, see Requirements for synchronization.

During cluster operation, most configuration changes are synchronized dynamically. For more information, see Synchronization.

Configuration optimizations in case of increased transfers load

In case of increased transfer payload, you can configure the maximum number of threads for GeneralMessageProcessing in the SecureTransport Server Configuration by increasing the value of the following parameter:


By default this value is set to 4. For optimal performance, you can increase this value up to 100 or even more.

You have to apply this configuration across all nodes.

Related topics:

Related Links