SecureTransport Cluster Models Overview – Part 3

In Part 1 of my series on SecureTransport Cluster Models Overview, I introduced the reasons to consider clustering a SecureTransport MFT environment and an overview of the different clustering models.

In Part 2, SecureTransport Cluster Models Overview,  we dug into the Standard Cluster model and the three modes in which it can be configured: active-active, active-passive, and active-passive (legacy).

In this installment, I will cover our flagship Enterprise Cluster model and provide a summary of the different clustering models.

Enterprise Cluster

The Enterprise Cluster is our flagship clustering model and addresses the most demanding enterprise high-availability and scalability requirements. It was introduced with SecureTransport 5.0.

Enterprise Clustering addresses many of the limitations inherent in the Standard Cluster model.

The Enterprise-Cluster can scale linearly and has been tested with up to 20 servers making it able to support extremely high file transfer volumes.

This performance can be attributed to the use of an external third-party database to store the configuration data, Event Queue table, and Sentinel link data and the use of a high-performance in-memory cache management layer.

For the third-party database, originally Oracle and Microsoft SQL Server were supported. However, with SecureTransport  5.5, support for PostgreSQL has been added, lowering the cost of entry for Axway’s highest performant clustering model.

The database is shared across all the SecureTransport servers in the cluster eliminating the need to synchronize configuration data, the Event Queue, and Sentinel link data.

The Enterprise Cluster does not work like the Standard Cluster model where a primary server dispatches work to the secondary server(s).

Instead, each server pulls jobs from the shared database’s Event Queue to process based on its own workload. This prevents an individual server from being overloaded by a primary server as can occur in the Standard Cluster active-active model.

Important distinction

Another important distinction is that servers can be removed or added to the Enterprise Cluster transparently without requiring any manual synchronization effort or impacting the current processing.

When a server is added to the cluster, it automatically registers itself. As an example, operating system patches can be applied to the servers in the cluster in a rolling fashion without requiring any production outage.

Like the Standard Cluster, the Scheduler and Folder Monitors only run on one server. If that server goes down, the next oldest Transaction Manager unsuspends its own Scheduler and Folder Monitors and so on.

Benefits

The primary benefits of the Enterprise Cluster model over the Standard Cluster are:

• Scales linearly up to 20 servers thus providing unmatched high availability and scalability.
• All File Tracking data is written to the shared common database, so all File Tracking activity is available from ANY server in the cluster from both the UI and via REST APIs. Unlike the Standard Cluster model, there is no need to collect the data individually for each server or to search multiple servers to be able to locate a file transfer to retry.
• Servers can be added to or removed from the cluster without impacting processing and requiring no manual synchronization effort. This allows for operating system patches to be applied in a rolling fashion.
  • Note that SecureTransport product patches do require stopping the entire cluster to patch the first node. The first node can then be restarted, and the patch applied to subsequent nodes, restarting each node as the patch is applied.

In the next blog, we will discuss a method for Zero Down Time Patches and Upgrades available with the Enterprise Cluster model.

• Full support for a passive Disaster Recovery site.

Some considerations with this model include:

• Requires a third-party database
  • Note that the addition of PostgreSQL support in SecureTransport version 5.5 helps mitigate this as it is available at no cost.
• Requires an administrator for the third-party database.
• For optimum availability, it is desirable to cluster the database.
• Additional infrastructure (load balancer[s]), performant shared file system, additional servers for each SecureTransport server, and Edge).
• Additional licensing cost vs Standard Cluster.

Summary of SecureTransport Cluster Models

The following table summarizes the different SecureTransport cluster models to help you determine which model makes the most sense for you.

In Part 4 of this blog, I will cover Disaster Recovery, Edge server considerations in a clustered environment, and a couple of other tidbits.