EFT Enterprise can be configured in an active-active cluster configuration, known as EFT High Availability (HA). In an HA deployment, two or more EFT installations can be configured in an active-active cluster with a shared configuration. EFT acts as its own cluster manager and requires a network load balancer (NLB) to distribute incoming protocol traffic. EFT HA nodes process file transfers at the network level as the NLB directs traffic to it, and can process Folder Monitor and Timer Event Rules in a round-robin fashion (i.e., executing the event actions on the first node, then the second, and so on until it comes back to the first node in the list). An example 3-node deployment is shown below. Having at least 3 nodes allows you to take down one node for maintenance and still have 2 active nodes for HA.

You can also install EFT HA in a DR environment:

For best results, before beginning an HA installation, please review all of the information below and refer to the references linked.

Consider the facts below before creating an HA cluster




Event Rules:

Auditing and Reporting:


Non-High Availability mode vs. High Availability mode EFT


Non-High Availability mode

High Availability mode


Searches for FTP.CFG’s in different folders, tries FTP.BAK’s to handle broken configuration, etc. Always creates "clean" configuration if no FTP.CFG/FTP.BAK is loaded.

Loads only <PATH>\FTP.CFG. Creates "clean" configuration only if no FTP.CFG present in the <PATH> folder. Fails to start if cannot load existing <PATH>\FTP.CFG.


Updated FTP.CFG with latest settings

Does not update FTP.CFG

Authentication managers


Globalscape, NTAD, and LDAP

User database refresh


Not allowed

PCI cleanup (administrator/user remove/disable for inactivity and send Password Expiration Notifications)

Nightly timer

+ Every time server deals with user/administrator (user/administrator connection, exposing user/administrator to GUI/COM etc.)

Nightly timer

Client Expiration

Every time when server deals with user (user connection, exposing user to GUI/COM etc.)

Nightly timer

Turning off Autosave and using "ApplyChanges"  via COM


Not allowed

GUI/COM connection

Always allowed

Only one node at a time is allowed to serve GUI/COM connection

Saving changes made by administrator to FTP.CFG

Background task accumulating changes and saving settings

Only one node can be administered at a time. As soon as you log off of the node on which you've made changes and then log on to second node, those changes would be updated on the second node.

Server restore from backup



Trial state

FTP.CFG + registry (duplicated)


OTP passwords for clients


Not allowed

Legacy password hashes


Not allowed

User lock state

Continues after service restart

Breaks after service restart

Invalid login history

Continues after service restart

Resets on service restart

Related topics