CompleteFTP Enterprise MFT provides support for clustering of multiple servers across different machines (from 7.0). Native clustering is not supplied, but in combination with a hardware or software load balancer (e.g. Microsoft NLB) load balancing and failover can be achieved.
What CompleteFTP Enterprise supplies is synchronized and instantaneous server configurations across the cluster. A server instance is designated as the primary server, and configuration changes made on the primary are instantly propagated to all the secondary servers in the cluster. Hence the most suitable architecture is an active/active cluster setup - in an active/passive cluster, configuration changes cannot be propagated to the dormant machine. A single instance of the CompleteFTP Manager can control all the servers in the cluster. An architecture diagram is shown below:
The diagram shows three clients connecting to a cluster via a router. This could be be done via any supported protocol, such as FTPS, SFTP or HTTPS. The router would be capable of load-balancing and/or failover control. It directs incoming requests to one of the three servers. The way in which it selects the server depends on how it's configured. The three servers are all running CompleteFTP and are configured to all be capable of responding to the same requests. One of the servers is set to be the primary from within CompleteFTP. All configuration changes must be made via this server. It is responsible for distributing configuration changes to the secondaries. This is done in near-real-time. While CompleteFTP takes responsibility for synchronizing configuration changes between the three servers, it does not synchronize the files on the Hard Disk-Drive (HDD) - this is left to Windows DFS. The Windows DFS (Distributed File-System) is a feature of Windows Server 2008/2012 that synchronizes files and directories between server instances in near-real-time.
The diagram above shows an architecture where user's files are store locally on each server. Below is an architecture where files are on network storage:
DFS is now not required on the CompleteFTP servers since no user-files need to be synchronized between them.
In situations where load is very high it may be preferable to minimize load on the primary node. In this case the following architecture could be used:
The main motivation for this is to reduce the load on the primary node. The primary node is more important than the secondaries since it's a central point for synchronization of configuration data for the following reasons: it's the node to which the administration console (CompleteFTP Manager) must connect in order to make configuration changes it is responsible for distributing those changes to the secondaries it is the node from which a secondary that is booting up will request a configuration update. While this architecture is preferable to the other architectures, it is by no means essential - it is only marginally better.
One important caveat relates to HTTP/S. As each HTTP/S session is local to each CompleteFTP server, the load balancer will need to ensure all connections from the same external IP address are directed to the same CompleteFTP instance in the cluster. A future release will replicate HTTP/S session caches across the cluster, alleviating this requirement for the load balancer.