Clustering is when a group of several servers work together to accomplish a task or function, appearing as a single unit to clients. The primary purpose is to provide resilience – a server in the cluster may fail but clients should ideally not even be aware of it.
For secure file servers, the goal of clustering is to have a group of servers that seamlessly provide various network services such as FTPS, SFTP, and HTTPS to clients. As far as clients are concerned, they shouldn’t need to know about the cluster. They connect using the supplied IP address, and whatever server they connect to will have their files available.
There are two critical components that CompleteFTP does not provide: the load balancer, and the filesystem synchronization. The load balancer might be a router or firewall, or perhaps some specialized software. Its purpose is to provide external clients with an IP address, and then distribute their requests to whatever machine it wishes. It should make no difference to the client which machine it is – which is why file synchronization is important. If at one point the client uploads a file, when they return the following day and are connected to a different server, they still need access to the same file. So the files need to be synchronized between the servers in the cluster. Typically, this functionality is supplied by Microsoft’s Distributed File System (DFS) or a similar product.
What CompleteFTP provides is synchronization of server configurations. Providing the servers are arranged in a cluster and can communicate, all configuration changes made on the primary server are propagated to the secondary servers in the cluster. This means, for example, if users are added on the primary, they will end up on the secondaries as well.
There are two possible cluster arrangements : active/active and active/passive.
Assuming a two server cluster, in the active/active scenario, both servers are actively used by clients, which are directed to a particular server by the load balancer or similar technology. Any changes made on the primary are immediately sent to the secondary. In a server failure scenario, the load balancer should detect that a server in the cluster is down and redirect all requests to the server that is still functioning correctly.
In the active/passive scenario, only one server, the primary, is actively used. The secondary server is a fail-over option for when the primary server goes down unexpectedly. If that occurs, again all requests will be redirected to the secondary. It is possible for the secondary server to not even be running unless there’s a requirement for it, although it should be periodically started so that it can synch its configuration with primary and ensure it is functioning correctly.