HA FAQ

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

Installation:

Configuration:

MSMQ or Unicast:

Microsoft Message Queueing (MSMQ) to distribute messages among nodes in the cluster is used by default. Unicast can be used instead of MSMQ. Refer to Unicast for details.

Event Rules:

Auditing and Reporting:

COM API:

Non-High Availability mode vs. High Availability mode EFT

Function

Non-High Availability mode

High Availability mode

Startup

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.

Shutdown

Updated FTP.CFG with latest settings

Does not update FTP.CFG

Authentication managers

GS, NTAD, ODBC, LDAP

Globalscape, NTAD, and LDAP

User database refresh

Allowed

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

Allowed

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

Allowed

Allowed

Trial state

FTP.CFG + registry (duplicated)

Registry

OTP passwords for clients

Allowed

Not allowed

Legacy password hashes

Allowed

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