[
https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes updated GEODE-7565:
--------------------------------------------
Description:
There is a problem with Geode WAN replication when GW receivers are configured
with the same hostname-for-senders and port on all servers. [ 1 ]
The problem experienced is that shutting down one server is stopping
replication to this cluster until the server is up again. This is because Geode
incorrectly assumes there are no more alive servers when just one of them is
down, because since they share hostname-for-senders and port, they are treated
as one same server.
Our proposal consists on expanding internal data in locators with enough
information to distinguish servers in the beforementioned use case. The same
intervention is likely needed in the client pools and possibly elsewhere in the
source code.
----
[ 1 ] : The reason for such a setup is deploying Geode cluster on a Kubernetes
cluster where all GW receivers are reachable from the outside world on the same
VIP and port. Other kinds of configuration (different hostname and/or different
port for each GW receiver) are not cheap from OAM and resources perspective in
cloud native environments and also limit some important use-cases (like
scaling).
Link to thread in DEV mailing list:
[https://markmail.org/thread/6qakx67rxiokdsec]
was:
There is a problem with Geode WAN replication when GW receivers are configured
with the same hostname-for-senders and port on all servers. [ 1 ]
The problem experienced is that shutting down one server is stopping
replication to this cluster until the server is up again. This is because Geode
incorrectly assumes there are no more alive servers when just one of them is
down, because since they share hostname-for-senders and port, they are treated
as one same server.
Our proposal consists on expanding internal data in locators with enough
information to distinguish servers in the beforementioned use case. The same
intervention is likely needed in the client pools and possibly elsewhere in the
source code.
----
[ 1 ] : The reason for such a setup is deploying Geode cluster on a Kubernetes
cluster where all GW receivers are reachable from the outside world on the same
VIP and port. Other kinds of configuration (different hostname and/or different
port for each GW receiver) are not cheap from OAM and resources perspective in
cloud native environments and also limit some important use-cases (like
scaling).
Link to thread in DEV mailing list:
[https://markmail.org/thread/qmpgo3n3evyuhg5b|http://example.com]
> Wrong management of receivers with same hostname-for-senders
> ------------------------------------------------------------
>
> Key: GEODE-7565
> URL: https://issues.apache.org/jira/browse/GEODE-7565
> Project: Geode
> Issue Type: Improvement
> Components: wan
> Reporter: Alberto Bustamante Reyes
> Assignee: Alberto Bustamante Reyes
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> There is a problem with Geode WAN replication when GW receivers are
> configured with the same hostname-for-senders and port on all servers. [ 1 ]
> The problem experienced is that shutting down one server is stopping
> replication to this cluster until the server is up again. This is because
> Geode incorrectly assumes there are no more alive servers when just one of
> them is down, because since they share hostname-for-senders and port, they
> are treated as one same server.
> Our proposal consists on expanding internal data in locators with enough
> information to distinguish servers in the beforementioned use case. The same
> intervention is likely needed in the client pools and possibly elsewhere in
> the source code.
> ----
> [ 1 ] : The reason for such a setup is deploying Geode cluster on a
> Kubernetes cluster where all GW receivers are reachable from the outside
> world on the same VIP and port. Other kinds of configuration (different
> hostname and/or different port for each GW receiver) are not cheap from OAM
> and resources perspective in cloud native environments and also limit some
> important use-cases (like scaling).
>
> Link to thread in DEV mailing list:
> [https://markmail.org/thread/6qakx67rxiokdsec]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
