Community Articles
Find and share helpful community-sourced technical articles
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.
Labels (1)
Master Guru

The NiFi S2S protocol is used by NiFi's Remote Process Group (RPG) components to distribute FlowFiles from one Nifi instance to another. When the target NiFi is a a Nifi cluster, load-balancing of the FlowFie delivery is done across all nodes in the target NiFi Cluster.

The default way this works (and only way it works in versions of NiFi previous to Apache NiFi 1.2.0 or HDF 3.0) is as follows:

  1. The RPG regularly communicates with target NiFi cluster to get load status information about each node in the cluster. This information includes the number of currently connected nodes in the target cluster, each nodes hostname and port information, and number of total queued FlowFiles on each target NiFi node.
  2. The Source NiFi uses this information to determine a data distribution strategy for its source FlowFiles it has queued. - - - Let's assume a 4 node target NiFi cluster all reporting a zero queue count. - Each node will then be scheduled to receive 25% of the data. This means a distribution pattern of node1, node2, node3, and then node4. - Now lets assume the same 4 node target cluster; however, node 1 and node 2 report having a queue of FlowFiles that results in the following: - Node 1 and Node 2 would get 16.67% of the data while node 3 and node 4 get 33.33% of the data. This results in a distribution pattern of node1, node2, node3, node4, node3, and then node 4. So Nodes 3 and 4 get twice the opportunity to receive data over nodes 1 and 2.
  3. Once distribution pattern is determined, the RPG connects to first node and starts transferring data from incoming queue to that node for 500 milliseconds or until queue is empty. Next run of RPG will start sending to next node in pattern and so on.

As you can see by this default distribution model, the data may not always be distributed as desired. The reason this transfer was implemented this way was for performance reasons. However, when working with very small FlowFiles or when a better network connection exist between one target node then another, the load-balancing will be less then ideal.

With the introduction of HDF 3.0 (Apache NiFi 1.2.0). additional configuration options where added to the RPG to control the number of FlowFiles (count), amount of data (size), and/or length of transaction time (duration) per RPG port connection. This gives users the ability to fine tune their RPG connection to achieve better load-balancing results when dealing with lighter volume dataflows, network performance differences between nodes, etc...

These new configuration options can be set as follows:

16578-screen-shot-2017-06-26-at-123632-pm.png

16579-screen-shot-2017-06-26-at-123708-pm.png

16580-screen-shot-2017-06-26-at-123744-pm.png

Each input and output port configurations will need to be set individually.

Of course setting Count to a value of 1 sounds like a good way to achieve really good load-balancing, but it will cost you in performance since only one FlowFile will be sent in each transaction. So there will be extra overhead introduced do to the volume of new connections being opened and closed. So you may find yourself playing around with these settings to achieve your desired load-balancing to performance ratio.

----------------

How do I get better load-balancing in older version of NiFi?

The RPG will send data based on what is currently in the incoming queue per transaction. By limiting the size of that queue, you can control the max number of FlowFiles that will transfer per transaction. You can set size of object back pressure thresholds on those incoming queues to limit the number of FlowFiles queued at any given time. This will cause FlowFiles to queue on the next upstream connection in the dataflow. If a source processor is feeding the RPG directly, try putting an updateAttribute processor between that source processor and the RPG so you have two connections. As each RPG execution runs and transfers what is on the queue, the queue will be refilled for the next transaction.

2,990 Views
Don't have an account?
Coming from Hortonworks? Activate your account here
Version history
Revision #:
2 of 2
Last update:
‎08-17-2019 12:16 PM
Updated by:
 
Contributors
Top Kudoed Authors