Observers: Making ZooKeeper Scale Even Further
December 15th, 2009 by Henry Robinson
http://www.cloudera.com/blog/2009/12/15/observers-making-zookeeper-scale-even-further/
Observers scale read performance too
Scaling the number of clients is an important use case for Observers, but in fact there are significant other advantages to having them in your cluster.
クライアント数のスケーリングが、Observers における重要なユースケースであるが、実際にそれらをクラスタ内に持つことで、他の重要なアドバンテージが生じる。
As an optimisation, ZooKeeper servers may serve read requests out of their local data stores, without going through the voting process. This puts read requests at a very slight risk of a ‘time-travel’ read, where an earlier value is read after a later value; but this only happens when a server fails. Indeed, in that case a client may issue a ’sync’ request that ensures the next value it reads is the most up-to-date.
クライアント数のスケーリングが、Observers における重要なユースケースであるが、実際にそれらをクラスタ内に持つことで、他の重要なアドバンテージが生じる。最適化の際に、 ZooKeeper サーバーは voting プロセスを介することなく、ローカルのデータストアにおける read リクエストを配分するだろう。それにより、read する値の順序が逆転する際の、 ‘time-travel’ read のリスクが最小になるとも見積もられるが、そのこと自体は、サーバーが失敗するときに起きるだけである。実際に、このようなケースでは、次に read される値が最新であることを保証する ‘sync’ read リクエストを、クライアントが発行する可能性がある。
Therefore Observers are a big performance improvement for read-heavy workloads. Writes go through the standard voting path, and so, by the same argument as for client scalability, increasing the number of voting servers in order to serve more reads will have a detrimental effect on write performance. Observers allow us to decouple read performance from write performance. This meshes well with many use cases for ZooKeeper, where most clients issues few writes but many reads.
したがって、Obdervers の存在により、負荷の大きな read ワークロードにおける大幅なパフォーマンスの改善がもたらされる。スタンダードな voting パスを介した write を用いた、また、クライアント･スケーラビリティを考慮した同一の引数を用いた、さらに多くの read をサポートするための voting サーバーの増加は、write パフォーマンスに弊害をもたらすだろう。Observers により、write パフォーマンスと read パフォーマンスの分離が実現される。つまり、大半のクライアントが、少量の write と大量の read を発行するという、ZooKeeper に多くみられるユースケースと調和する。
Observers enable WAN configurations
There’s yet more that Observers can do for you. Observers are excellent candidates for connecting clients to ZooKeeper across wide-area networks. There are three main reasons for this. In order to get good read performance, it is necessary to have your clients relatively near to a server so that round-trip latencies aren’t too high. However, splitting a ZooKeeper cluster between two datacenters is a very problematic design, due to the fact that ZooKeeper works best when the voting servers are able to communicate with each other at low latency – otherwise we get the slowdown problem I described earlier.
Observers は、さらに多くのものをもたらす。広域ネットワークをまたいで、ライアントと ZooKeeper を接続する際にも、Observers は有力な候補となる。これには、3 つの主な理由がある。Read のパフォーマンスを向上させるためには、ラウンドトリップのレイテンシーを過大にしないように、サーバーとクライアントを相対的に近づける必要がある。しかし、ZooKeeper クラスタを2つのデータセンター間で分けることは、きわめて問題の多いデザインとなる。なぜなら、voting サーバーが低いレイテンシーで相互に通信できるときに、ZooKeeper は適切に機能するという事実があるからだ。そうしないと、前述のようなスローダウンに遭遇してしまう。
Observers can be placed in every datacenter that needs to access a ZooKeeper cluster. Therefore the voting protocol doesn’t take place across a high-latency intra-datacenter link, and performance is improved. Also, two fewer messages that are sent between Observers and the Leader during the voting process than between a voting server and the Leader. This can help ease bandwidth requirements on write-heavy workloads from remote datacenters.
Observers は、ZooKeeper クラスタにアクセスする必要がある、すべてのデータセンターに配置できる。 したがって voting プロトコルが、データセンター内でレイテンシーの大きなリンクを引き起こすことはなく、また、パフォーマンスも改善されている。さらに、voting プロセスの際に、Oservers と Leader の間で交わされる 2つのメッセージは、voting サーバーと Leader間のメッセージと比べて少ない。それは、リモート･データセンターが要求する、過大な write ワークロードにおける、帯域幅に関する要件を緩和する。
Finally, since Observers can fail without affecting the voting cluster itself, there’s no risk to the availability of the service if the link between datacenters is severed. This is much more likely than the loss of internal rack-to-rack connections, so it is beneficial not to rely on such a link.
究極的には、voting クラスタ自身に影響を与えることなく、Observers を失敗させることができるため、データセンター間のリンクが切断されれも、対象となるサービスの可用性にリスクは生じない。 それは、内部における rack-to-rack 接続のダウンよりも起こり得ることであるため、こうりたリンクに依存しないというメリットがもたらされる。
How to get started with Observers
Observers are not yet part of a ZooKeeper release, so in order to start working with them you will have to download the source code from the Subversion trunk. The following is excerpted from the Observers user guide, found in docs/zooKeeperObservers.html in the source distribution.
現時点において、Observers は ZooKeeper リリースの一部となっていないため、それらを利用する場合には、Subversion トランクからソースコードをダウンロードする必要がある。 以下は、ソース･ディストリビューションの docs/zooKeeperObservers.html における、Observers ユーザーガイドからの抜粋である。
How to use Observers
Note that until ZOOKEEPER-578 is resolved, you must set electionAlg=0 in every server configuration file. Otherwise an exception will be thrown when you try to start your ensemble.
The reason: because Observers do not participate in leader elections, they rely on voting Followers to inform them of changes to the Leader. Currently, only the basic leader election algorithm starts a thread that responds to requests from Observers to identify the current Leader. Work is in progress on other JIRAs to bring this functionality to all leader election protocols.
Setting up a ZooKeeper ensemble that uses Observers is very simple, and requires just two changes to your config files. Firstly, in the config file of every node that is to be an Observer, you must place this line:
peerType=observer
This line tells ZooKeeper that the server is to be an Observer. Secondly, in every server config file, you must add
bserver to the server definition line of each Observer. For example:
server.1:localhost:2181:3181:observer
This tells every other server that server.1 is an Observer, and that they should not expect it to vote. This is all the configuration you need to do to add an Observer to your ZooKeeper cluster. Now you can connect to it as though it were an ordinary Follower. Try it out, by running:
bin/zkCli.sh -server localhost:2181
where localhost:2181 is the hostname and port number of the Observer as specified in every config file. You should see a command line prompt through which you can issue commands like ls to query the ZooKeeper service.
Future work
There’s more to be done with the Observers feature. In the short term we are working on making Observers fully compatible with all leader election algorithms that ship with ZooKeeper – we expect this to be finished within the next few days. Longer term, we are hoping to investigate performance optimisations such as batching and off-line reads for Observer-based clusters, to take advantage of the fact that Observers have no strict latency requirement to meet unlike a normal ZooKeeper server.
Observers の機能に関しては、さらに推進すべきものがある。 短期的には、ZooKeeper と共に出荷される、すべての leader election アルゴリズムとの完全な互換性を、Observers に持たせるための作業に注力する。あと数日の作業で、それが完了すると予想している。長期的には、観察者ベースのクラスタにおける、バッチ処理やオフライン read などの、パフォーマンスの最適化について調査したいと考えている。それが、標準的な ZooKeeper サーバーではあり得ない、レイテンシーに関する要件を緩和された、Observers のアドバンテージを証明する。
We hope that Observers will make it into the release of ZooKeeper 3.3.0, due early next year. We would be delighted to hear your feedback, either on the mailing lists, or via direct e-mail. ZooKeeper is always looking for contributors, and we’ve got plenty of interesting problems to solve, so do get in contact if you’d like to get involved and I’d be happy to help you get started.
2010 年の早期に予定されている、ZooKeeper 3.3.0のリリースに Observers を加えたいと考えている。メーリング･リストや、ダイレクトなメールによる、フィードバックを期待している。ZooKeeper は、常にコントリビュータを求めている。そして、解決すべきたくさんの興味深い課題を抱えている。そこに関与してもらえるなら、連絡をして欲しい。 あなたのスタートアップに、私は喜んで手を貸したい。
おわり
＜関連＞
Observers と ZooKeeper _1
The Anatomy of Hadoop I/O Pipeline _1
