MFT SecureTransport Cluster Models Part 1

As a Presales Architect, I am often making recommendations to prospective and current Managed File Transfer customers regarding the SecureTransport architecture that will best fit their needs and budget.  

The goal of this blog series is to help educate prospective customers, current customers, consulting resources, and fellow architects on the key differentiators, pros, and cons of each cluster model.

As this is an extensive topic, I will loosely split the blog into the following installments:

• Part 1: Overview of Clustering Models in SecureTransport
• Part 2: Standard Cluster overview
• Part 3: Enterprise Cluster, Disaster Recovery (all architectures) and Summary Comparison
• Part 4: What’s Next

Axway SecureTransport is Axway’s enterprise-class-hub Managed File Transfer (MFT) solution for secure file transfer. SecureTransport allows organizations to control and manage the transfer of files inside and outside of the corporate firewall in support of mission-critical business processes while satisfying policy and regulatory compliance requirements.

To meet customers’ availability, scalability, and budget requirements, Axway SecureTransport can be licensed and deployed with three primary architectures: single-server installation, Standard Cluster (active-active, and two different active-passive modes available), and Enterprise Cluster.

Overview of SecureTransport Cluster Models

The primary reasons to consider clustering are increased availability, increased scalability, or both. Each cluster model and cluster mode (for Standard cluster) addresses these reasons to differing degrees and each have their pros and cons and that is much of what we will cover in this blog. The choice of which cluster model and mode to use is dependent on your:

• Availability requirements
• Scalability requirements
• Infrastructure
• Availability of a shared file system and the expertise to administer it
• Availability of an external MS SQL Server or Oracle database and the expertise to administer it
• Disaster Recovery environment requirements
• Budget

Deployment models 

Axway SecureTransport has three deployment models:

1. Single server installation
2. Standard Cluster
   1. Active-active mode
   1. Active-passive mode
   1. Active-passive (legacy) mode
3. Enterprise Cluster

Companies who are more budget-sensitive and have less stringent availability and scalability requirements may be perfectly suited to a non-clustered single SecureTransport server environment. The next step up would be one of the three modes of the Standard Cluster. 

Additional costs incurred in the Standard Cluster are primarily due to additional hardware requirements for extra servers, load-balancer(s), and a shared file system. The Enterprise Cluster is the latest clustering model introduced and provides the highest levels of availability and scalability to satisfy the most stringent customer requirements.

However, it requires an external Oracle or Microsoft SQL Server database and has a higher licensing cost than the Standard Cluster. 

The Standard Cluster was the first clustering model introduced and for many years was the only clustering model available until Enterprise Cluster was introduced in SecureTransport 5.0.  

The Standard Cluster can be configured in one of three modes: active-active, active-passive, or active-passive legacy.  The Enterprise Cluster is always active-active although some customers have chosen to install it with only a single server (typically because they prefer to use a Microsoft SQL Server or Oracle database).

The following diagram shows a typical deployment of an active-active Standard Cluster:

Figure 1: Active-Active Standard Cluster

Both Standard Cluster and Enterprise Cluster are implemented within the SecureTransport software itself and require no third-party clustering software to be deployed. This is commonly referred to as application-level clustering and has the benefit of being independent of platform, operating system, and third-party software vendors. 

Note that a supported shared file system is required for all models except for Standard Cluster active-passive (legacy).

And a load balancing solution for the inbound client protocol connections is also typically used. For incoming connections from external partners, the load balancing solution is typically placed in front of the SecureTransport Edges deployed in the DMZ.  

Similarly, for inbound connections from internal systems, a load balancing solution is often placed in front of the SecureTransport servers in the secure zone.

Configuration & operation of SecureTransport

From an operational and end-user perspective, the configuration and operation of SecureTransport are largely identical regardless of what deployment model is used.  

 For example,

• User Account creation and the related creation of Certificates, Transfer Sites, Routes, and Subscriptions remain unchanged
• Creation of Route Templates, Applications, Schedules, etc. remain unchanged
• Edge configuration and operations remain unchanged
• Set up of file-based permissions and restrictions remain unchanged
• File Tracking remains unchanged (with a couple of caveats that will be discussed)
• API calls remain unchanged (with a couple of caveats that will be discussed)
• End-user experience whether via SecureTransport Web Client or a supported server or client protocol remains unchanged.

Inbound client protocol connections to SecureTransport are always handled on the Edge-SecureTransport server pair on which they land regardless of the cluster model or mode.  

Similarly, outbound client protocol sessions initiated by SecureTransport also remain on the SecureTransport server-Edge pair from which it is originally initiated.

Furthermore,  common across all cluster models and modes are that, at any given time, the System Scheduler and Folder Monitor only run on a single server. The Scheduler adds job tasks for scheduled file transfers and maintenance applications into the Event Queue table.

From there, depending upon the cluster model, the events will either be executed on the Primary node or possibly executed on another node (active-active models).

The Standard Cluster is the first SecureTransport clustering model that was introduced. There are three modes in which Standard Cluster can be deployed in:

• Active-active
• Active-passive
• Active-passive (legacy)

All three modes use an embedded mySQL database that is located on each server (similar to a single server installation). Read the six benefits of adopting a digitalized MFT.

In the next part of this series, I will introduce the Standard Cluster and dig into the three modes in which it can be deployed.