Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In the existing client implementation, a static server list is provided to the ZooKeeper constructor while creating a client object. If the server list contains host names, then the name to IP mapping is performed only once. The server list as well as the resolved IP addresses remains unchanged. With dynamic reconfiguration [1],[2] of ZooKeeper servers 1, 2, ZooKeeper clients need a way to determine the most up-to-date server list.

...

A client can potentially resolve the new server list by periodically querying an external resource. For example, the ZooKeeper client library can take a reference to a HTTP URL (that records the server list) and periodically refresh the list from the URL. Other than In addition to high availability of the resource, there three main questions to answer:

...

There are many options for external resource (HTTP, DNS, NFS, LDAP, virtual IP, etc). From security mechanisms view point; there are many solutions as well and some of them could require tedious setup. Even if we resolve this problem, the processing of updating a resource is not simple. The process that updates the external resources must ensure that only the most recent server list gets recorded at the resource. We may need to address the failure of the update process as well. Suppose we could add the capability in the client library to record a union of the old and new server configuration at the URL, perform the reconfiguration, and then update the URL to with the most modified server list. The However, the client library would then also need to handle failures that may occur in this 3-step process. Further, if the application performs concurrent reconfigurations (which is supported by the server), then the client library would need to resolve race conditions to ensure that the result of last successful configuration is correctly recorded. In order to synchronize updates, the client library would need the external resource to support some atomic primitives (e.g., for locking and fencing).

After pondering upon solutions for a bitConsidering the complexity of the problem, in the first version, we propose to not implement any mechanisms to update the external resource in the client or server libraries. The ZooKeeper application would need to implement its own mechanism to update the URL. We expect that in most cases the change in ZooKeeper configuration will be an administrative process. Therefore, the Administrator can ensure that the URL is kept up-to-date. When we gain more experience in the future, we could consider adding this part the client library, if necessary.

To narrow down the lookup mechanisms, we propose two additional ways We propose to use two additional lookup mechanisms (as proposed in ZOOKEEPER-390):

  1. HTTP URL
  2. File URL that could potentially point to a path exported by a remote file server

...

The optional path at the end of the connection string specifies the chroot. Note that to allow applications to be compiled with the new library without any modification, the current connection string format will also be supported in addition to the URL. If existing ZooKeeper applications do not require dynamic membership or periodic refresh mechanism mechanisms and prefer to use the host:port connection string format, then the application's clients will work with the new version without any modifications to the clients. Existing ZooKeeper constructors remain unchanged.

...

  1. A new optional property “version” will added to the configuration file. The version number indicates the reconfiguration version number and should match the version number returned by ZooKeeper.getConfig() (see [1],[2] for further details). The version number, when specified, will be used to ensure that the client will be choose the new server list only if the version number of the list is higher than the current version number.
  2. The “server.x=host:serverPort:electionPort” property will be changed to “server.x=host:serverPort:electionPort:clientPort”.

...

The client will refresh from the URL every (n + r) seconds. In addition, the client will trigger a refresh (by waking up the refresh thread) if m successive connection attempts to m servers fail. The default value of m will be set to (s/3 + 1), where s is the size of the server list. The value can be set by “zookeeper.refreshAfterNumFailure” system property. If the application wishes to refresh every time the client disconnects from the server then this property can be assigned a value 0.

...

Note that this allows the application to update the server list (in a best effort manner) by using watches. The application can set a watch on the configuration znode (/zookeeper/config) that records the last committed server configuration. Once the watch is triggered, the application can read the configuration and call resetServerList(serverConfig).

D. Future Extensions

  • Tool A tool to update a password protected HTTP URL.
  • Avoid URL refresh from the same server JVM for each client. This problem is similar to implementing shared sessions.
  • Support for DNS based discovery at the client?
  • For applications that want to use protocols other than file or URL, we could provide a callback mechanism. When the client library needs to retrieve the server list, it will invoke the callback method in the application. It will be responsibility of the application to discover the server list.
  • For applications do not have external web server or file server to record the configuration, we can implement the solution using virtual IPs described in ZOOKEEPER-1031.

...

Wiki Markup
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="0697095e0a668f78-999f7e1f-4dae40b9-b3369039-5a25a24819ac0a8322f6fccc"><ac:parameter ac:name="">107</ac:parameter></ac:structured-macro> \[1\]  JIRA for dynamic cluster membership. [https://issues.apache.org/jira/browse/ZOOKEEPER-107]

Wiki Markup
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="211735ce800156aa-b6806559-4de14634-8b71b8c1-163a96ba852447851b7c497a"><ac:parameter ac:name="">107wiki</ac:parameter></ac:structured-macro> \[2\] Cluster Membership design. [https://cwiki.apache.org/confluence/display/ZOOKEEPER/ClusterMembership]