nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Clarke <>
Subject Re: Clustered Site-toSite
Date Wed, 25 Nov 2015 13:35:44 GMT
let me explain first how S2S works when connecting from one cluster to
another cluster.

I will start with the source cluster (this would be the cluster where you
are adding the Remote Process Group (RPG) to the graph).  The NCM has no
role in this cluster. Every Node in a cluster works independently form one
another, so by adding the RPG to the graph, you have added it to every
Node.  So Now the behavior of each Node is the same as as it would be if it
were a standalone instance with regards to S2S.  The URL you are providing
in that RPG would be the URL for the NCM of the target cluster (This URL is
not to the S2S port of the NCM, but to the same URL you would use to access
the UI of that cluster).  Now each Node in your "source" cluster is
communicating with the NCM of the destination cluster unaware at this time
that they are communicating with a NCM. These Nodes want to send their data
to the S2S port on that NCM. Now of course since the NCM does not process
any data, it is not going to accept any data from those Nodes.  The
"destination" NCM will respond to each of the "source" Nodes with the
configured, nifi.remote.input.socket.port=,
and the status for each of those "destination" Nodes.  Using that provided
information, the source Nodes can logically distribute the data to our the
"destination' Nodes.

When S2S fails beyond the initial URL connection, there are typically on a
few likely causes:
1. There is a firewall preventing communication between the source Nodes
and the destination Nodes on the S2S ports.
2. No value was supplied for on each of the
target Nodes.  When no value is provided whatever the "hostname" command
returns is what is sent.  In many cases this hostname may end up being
"localhost" or some other value that is not resolvable/reachable by the
"source" systems.

You can change the logging for S2S to DEBUG to see more detail about the
message traffic between the "destination" NCM and the "source" nodes by
adding the following lines to the logback.xml files.

<logger name="org.apache.nifi.remote" level="DEBUG"/>

Watch the logs on one of the source Nodes specifically to see what hostname
and port is being returned for each destination Node.


On Wed, Nov 25, 2015 at 7:59 AM, Matthew Clarke <>

> On Tue, Nov 24, 2015 at 1:38 PM, Edgardo Vega <>
> wrote:
>> Yeah the S2S port is set on all node.
>> What should the host be set to on each machine? I first set it to the NCM
>> ip on each machine in the cluster. Then I set the host to be the ip of
>> each
>> individual machine without luck.
>> The S2S port is open to the internet for the entire cluster for those
>> ports.
>> On Tue, Nov 24, 2015 at 1:35 PM, Matthew Clarke <
>> wrote:
>> > Did you configure the S2S port on all the Nodes in the cluster you are
>> > trying to S2S to?
>> >
>> > In addition to setting the port on those Nodes, you should also set the
>> S2S
>> > hostname.  The hostname entered should be resolvable and reachable by
>> the
>> > systems trying to S2S to that cluster.
>> >
>> > Thanks,
>> > Matt
>> >
>> > On Tue, Nov 24, 2015 at 1:29 PM, Edgardo Vega <>
>> > wrote:
>> >
>> > > Trying to get site to site working from one cluster to another. It
>> works
>> > is
>> > > the connection goes from cluster to single node but not clusted to
>> > > clustered.
>> > >
>> > > I was looking at jira and saw this ticket
>> > >
>> > >
>> > > Is this saying I am out of luck or is there some special config that I
>> > must
>> > > do to make this work?
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Cheers,
>> > >
>> > > Edgardo
>> > >
>> >
>> --
>> Cheers,
>> Edgardo

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message