Thanks for your answer Dan! We have checked that setting "0.0.0.0" in
DirectChannel and in GMSHealthMonitor seems to solve our problem. I created PR
to check if using "0.0.0.0" could have an impact and all public test cases
seems to work fine in that case (https://github.com/apache/geode/pull/5946).
Next step will be the implementation of an option to allow a user to set
"0.0.0.0" address in these classes.
BR/
Alberto Bustamante
De: Dan Smith
Enviado: jueves, 21 de enero de 2021 0:48
Para: dev@geode.apache.org
Asunto: Re: Different binding addresses for traffic & membership
I've been looking into the code a little bit to see if this is possible. I'm
not sure it is right now.
Here's some pointers at where to look at. Most of the magic is happening in
JGroupsMessenger. JGroupsMessenger wraps jgroups, which we are using to UDP
messaging related to membership.
The first thing that happens is that JGroupsMessenger.init creates a jgroups
configuration. It does some string replacement on the jgroups-config.xml file
that is checked. It puts the configured bind-address into that configuration.
When JGroupsMessenger.start() is called jgroups will bind to that address.
Right after that, JGroupsMessenger calls establishLocalAddress, which takes the
IP address that jgroups just bound to and creates our local MemberIdentifier.
Later in GMSJoinLeave.attemptToJoin, it sends that local address to the
coordinator. Assuming the join is successful, the coordinator will send out a
view that includes that MemberIdentifier.
I was really hoping that just setting a bind address of "0.0.0.0" would do the
right thing in this case. But it looks like jgroups won't let you bind to that
address. I don't currently see a way to get a different address in the
MemberIdentifier than the one that jgroups is listening on right now.
Besides the UDP port that jgroups is listening on, there are a couple of other
TCP ports used for peer-to-peer messaging. GMSHealthMonitor also starts
listening on the same local address returned from jgroups. And the
DirectChannel class I think also eventually ends up creating a server socket
that listens on the same bind-address. That one might be ok with "0.0.0.0".
-Dan
PS - there is a lot more information on membership on the wiki if it is
helpful, but I don't think it gets into this level of detail about what address
gets used -
https://cwiki.apache.org/confluence/display/GEODE/Membership+Manager+and+Messaging.
From: Aaron Lindsey
Sent: Wednesday, January 20, 2021 2:51 PM
To: dev@geode.apache.org
Subject: Re: Different binding addresses for traffic & membership
> Is there any way to configure a bind address to be used only for membership?
To your first question, I asked around but I’m not aware of anything like what
you are looking for. What you are describing does seem like it could become a
common setup on Kubernetes, but I personally haven’t tried using Geode with
Istio and Envoy. Please share what you learn!
> I thought that it will be interesting to take a look at how the membership
> works (how the distributed system is created), to check if at some point I
> could decouple how the value of "bind-address" parameter is used to configure
> binding and to indicate other members that they can reach the new member at
> that hostname. Any comment about what I should check first is welcome.
Maybe someone with more experience in the membership code could comment on this?
Aaron
> On Jan 20, 2021, at 9:07 AM, Alberto Bustamante Reyes
> wrote:
>
> It seems this is not a trendic topic... 🙂 Let me share my approach by the
> moment, maybe this will receive more comments:
>
> I thought that it will be interesting to take a look at how the membership
> works (how the distributed system is created), to check if at some point I
> could decouple how the value of "bind-address" parameter is used to configure
> binding and to indicate other members that they can reach the new member at
> that hostname. Any comment about what I should check first is welcome.
>
> Thanks!
>
> BR/
>
> Alberto Bustamante
>
>
>
>
>
>
> De: Alberto Bustamante Reyes
> Enviado: martes, 19 de enero de 2021 1:45
> Para: dev@geode.apache.org
> Asunto: Different binding addresses for traffic & membership
>
> Hi geode-devs,
>
> I have a question related with Geode & Kubernetes:
> We would like to use Istio with Geode. For that, a sidecar container (Envoy)
> has to be added in each Geode pod. That sidecar container intercepts and
> handles all incoming and outgoing traffic for that pod. One of the
> requirements set by Istio towards applications trying to integrate with it is
> that the application listening ports need to be bound to either localhost or
> 0.0.0.0 address (which listens on all interfaces).
>
> Geode binds the locator and server traffic port by default to 0.0.0.0, but
> the me
