Site iconAxway Blog

MFT SecureTransport Cluster Models Part 1

  • Bob Barrett
    • SecureTransport Cluster models

    SecureTransport Cluster models

    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:

    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:

    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,

    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:

    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.   

    Discover more! Amplify Managed File Transfer facts: What you need to know.

    Click Here
    Exit mobile version