[
https://issues.apache.org/jira/browse/ZOOKEEPER-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354473#comment-14354473
]
Robert Kamphuis commented on ZOOKEEPER-2107:
--------------------------------------------
I think that 1506 is about the zookeeper servers and how they will be
reconnecting to replaced server instances.
My proposed change in this 2107 is about the zookeeper client code linking with
the application and how the connect-string is resolved to ip addresses.
Also: as 1506 is now over 2 years old, I have switched to use ip addresses
directly in the zoo.cf. With that configuration, I can terminate one of the
zookeeper servers, get a replacement and re-assign the elastic IP to the
replacement instance. The rest of the zookeeper ensemble can reconnect to the
replacement instance after a few minutes and it will join the ensemble. This
method does require a specific security group setup to work as you will need to
add each of the zookeeper elastic ips to the security group. That is a
manageable one off configuration to do, and has been used in our production
setup for 9 months.
The 2107 is all about the application-servers and its connection to the
zookeeper cluster. I do not want to use for the apps the same way as with the
zookeeper ensemble, as it will require dynamic adding and removing each and
every applications IP to the security group plus some extra latency and minor
cost. The fix in 2107 enables people using AWS to implement a trivial
HostProvider which does the DNS lookup on next() and thus it will be able
reconnect to replaced instances without any session expiries and restarts.
> zookeeper client should support custom HostProviders
> ----------------------------------------------------
>
> Key: ZOOKEEPER-2107
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2107
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
> Affects Versions: 3.5.0
> Reporter: Robert Kamphuis
> Fix For: 3.5.1
>
> Attachments: enable-custom-hostprovider_in_zookeeper-client3.patch
>
>
> The zookeeper client currently contains a StaticHostProvider and no means to
> replace it with your own implementation of the existing HostProvider
> interface. It would be great if the zookeeper client would enable you to
> create an instance with your own implementation of the HostProvider
> interface.
> We have been testing this change with our implementation of HostProvider
> which does the name to ip lookup at the time of finding the next() server to
> connect to. In our AWS based deployments, this enables that applications can
> actually connect to swapped out zookeeper-servers which typically get a new
> ip address. With the current StaticHostProvider in practice you will need to
> restart the application to see the replaced zookeeper as the application
> continues to try to connect to the old no longer existing IP address.
> With this little change plus a straightforward implementation of the
> HostProvider interface (our LateResolvingHostProvider), we can replace the
> zookeeper servers one at a time, re-assigning the elastic ips we use for the
> zookeeper servers, and have the application servers re-connect to the
> zookeeper cluster including the replaced ones without any downtime and
> without having to rely on the elastic ips for client to zookeeper-server
> connections. The reason for not using elastic-ips in the connect-strings but
> use the names which map to the (changing) private ips is to be able to rely
> on security-groups to control access.
> While this seems very specific for AWS, this anyway seems a generic
> improvement for other deployments where the mapping from server name to IP
> address is not static.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
