THE INFORMATION IN THIS ARTICLE APPLIES TO:

• EFT v7 and later

DISCUSSION

NOTE: This article refers to NetApp as the shared storage, but can apply to any shared storage mechanism (Windows share, NetApp Filer, EMC Isilon, *nix Samba share, NAS or SAN, etc.). Certain devices have an upper limit on the number of simultaneous connections supported. This article provides details of how many connections EFT might use when processing Folder Monitor event that involve network storage, such as NetAppp Filer. See also NetApp NAS tuning to work with EFT Enterprise in HA mode.

For Folder Monitor Rules in an HA cluster, only ONE of the nodes participating in any event rule will be the "Master." That master will have one long-lived handle to the NetApp filer open when you choose "Change Notify" – this is the real-time alerting system where every new file added to the folder under observation triggers the rule. This "change notify" must keep a file handle (technically, a directory handle) open on the remote NetApp filer so that it can register for notifications coming from NetApp, and those notifications must arrive such that they refer to that handle. This handle is kept open as long as the Folder Monitor is running.

The "Check Health" and "Sweep" features of any Folder Monitor event rule will also create threads to control their respective logic, but they open and close handles as needed, at the interval specified in FM Event Rule configuration. Thus, they will also add file operations to the NetApp filer, but short-lived ones.

Finally, as any event rule is dispatched and action sequences are followed, the actions themselves might open and close handles to process the observed file.

As an example, let's assume I have one (1) Folder Monitor rule monitoring a share on NetApp Filer. I configure "Notify, "Check Health," and "Sweep" to all be on (health and sweep both set to 15 minutes). Finally, this rule is load balanced between nodes A and B.

The action sequence of this FM event is simple:

1. When File Change Does Equal to Added
2. Copy file over SFTP to some remote destination
3. Move the file to an Archive location in some other folder on that same NetApp Filer.

When the EFT cluster nodes start up, one of them will be elected "Master" for this rule. Let's assume that "A" wins that election.

At that point,

• "A" has one (1) long-lived file handle open for folder change notifications.
• "A" will periodically open and close a file handle to ensure that Change Notify is working; so it will open and close a handle once every 15 minutes.
• "A" will periodically open a handle to the folder and scan the directory contents to see if anything is present which has not been properly processed (if any such item exists, it dispatches the event to fire on that file). This opens a directory handle and performs directory listing, then closes the handle once every 15 minutes.

So, with a quiet file system on NetApp, we have only 1 active connection to NetApp, and 2 periodic, short lived connections.

NOW, when files are added to the observed folder, "A" will detect the change for each newly added file, and dispatch the event evenly among "A" and "B" (this is the round-robin load balancing).

For each such file that dispatches an event, one of the two nodes will perform the action sequence, which will involve opening a file handle on NetApp, reading all the data, and closing the handle (step 1); then opening the file handle on NetApp, opening the destination file handle on NetApp other folder, and reading all contents from first handle and writing to second handle ... then close both handles.

Thus, for each file that is dispatched for processing, NetApp will get one handle opened/closed; followed by two handles opened/closed.

Because of the FolderMonitorWorkerThread limit, there will be an upper limit on simultaneous Event Rule action sequences that be executed by any one node. Let's assume we set the registry value to "64." This means that when lots and lots of files are added to the folder under observation, we should reach a peak of 64x1 (for step one) and then 64x2 (for step two) handles active simultaneously. Thus, at most we would have 128 additional file handles to NetApp per node in this case, for a total of 128x2 = 256 additional handles (in addition to the 1 long lived and 2 periodic handles previously mentioned).

Since Folder Monitor Worker Thread Pool is a per-site configuration, that peak of "128 additional handles" would be the most that any one site could exercise under the configuration mentioned.

But adding more Folder Monitors will add up to 3 more per Event Rule (1 long lived for "notify" and up to 2 for Health Check and Sweep).

Thus, if we had 100 FM Event rules configured just like above, we might achieve a peak open handle count against NetApp filer of 100 x 3 = 300 + 256 = 556

But there is some variability in that that Check Health and Sweep threads probably do not operate simultaneously against NetApp all the time; however, under worst case scenario they would, and thus the above math should be the ceiling of handle utilization for those Folder Monitor event rules.