[
https://issues.apache.org/jira/browse/ZOOKEEPER-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562317#comment-14562317
]
Ruslan Dautkhanov commented on ZOOKEEPER-1031:
----------------------------------------------
>> Implementation issues:
>> 1. The old ZK leader that has lost leadership should be able to somehow give
>> up the virtual IP address. Otherwise, it could >> lead to collisions. One
>> solution is to self reboot. A system property can be used to specify ways to
>> unplumb the cluster IP
Something like Single Client Access Name ("SCAN" from Oracle terminology) could
solve this issue.
The way SCAN works - it's just a DNS name that resolves to three (or more)
virtual IP addresses.
So it gives both HA and load balancing.
Each of the ZK servers may take one virtual IP address, and so ZK client
connects to first IP in the list (if client will
be aware that DNS can respond multiple IPs to one DNS name), if it does not
work - try next one and so on.
If ZK client will just rely on OS to do DNS name resolution, then it will still
work as DNS servers or OS will give
IPs in round-robin fashion.
Now if ZK client always must talk only to active leader, then ZK server that
client happened to talk to is not leader,
then ZK server can just send response who is the active leader.
It works very similar in Oracle database "clouds" (or RAC clusters) - SCAN
listeners who received connection request redirect clients to a database
instance that is less loaded (in case of ZK it might be just ZK-leader or any
other
logic that makes sense for ZK).
Oracle Single Access Client Name explained -
http://www.oracle.com/technetwork/products/clustering/overview/scan-129069.pdf
> Introduce virtual cluster IP and start that cluster IP on the host running ZK
> leader
> ------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1031
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1031
> Project: ZooKeeper
> Issue Type: Wish
> Components: leaderElection, quorum
> Affects Versions: 3.3.3
> Reporter: Vishal Kher
> Priority: Minor
> Fix For: 4.0.0
>
>
> It would be useful to enable a way to specify a virtual (floating) IP for the
> ZK cluster (say in zoo.cfg). The ZK leader will start this IP on one of its
> interfaces. If the leadership changes, the cluster IP will be taken over by
> the new leader. This IP can be used to identify the ZK leader and send
> administrative commands/query to the leader. For example,
> - a ZK client can get the list of ZK servers in the configuration by sending
> a request to the server running this IP address. The client just needs to
> know one IP address. Availability of cluster automatically ensures
> availability of
> the IP address.
> - To reconfigure ZK configuration, a client can send reconfig request to the
> server on this IP and keep retrying until the request succeeds or fails.
> Implementation issues:
> 1. The old ZK leader that has lost leadership should be able to somehow give
> up the virtual IP address. Otherwise, it could lead to collisions. One
> solution is to self reboot. A system property can be used to specify ways to
> unplumb the cluster IP
> 2. Cross-platform support.
> 3. Refreshing ARP caches
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
