src/docs/src/documentation/content/xdocs/zookeeperObservers.xml - zookeeper - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!--
   Copyright 2002-2004 The Apache Software Foundation

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
 -->

 <!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN"
 "http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
 <article id="bk_GettStartedGuide">
   <title>ZooKeeper Observers</title>

   <articleinfo>
     <legalnotice>
       <para>Licensed under the Apache License, Version 2.0 (the "License"); you
 	may not use this file except in compliance with the License. You may
 	obtain a copy of the License
 	at <ulink url="http://www.apache.org/licenses/LICENSE-2.0">http://www.apache.org/licenses/LICENSE-2.0</ulink>.</para>

       <para>Unless required by applicable law or agreed to in writing, software
       distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
       WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
       License for the specific language governing permissions and limitations
       under the License.</para>
     </legalnotice>

     <abstract>
       <para>This guide contains information about using non-voting servers, or
       observers in your ZooKeeper ensembles.</para>
     </abstract>
   </articleinfo>

   <section id="ch_Introduction">
     <title>Observers: Scaling ZooKeeper Without Hurting Write Performance
       </title>
     <para>
       Although ZooKeeper performs very well by having clients connect directly
       to voting members of the ensemble, this architecture makes it hard to
       scale out to huge numbers of clients. The problem is that as we add more
       voting members, the write performance drops. This is due to the fact that
       a write operation requires the agreement of (in general) at least half the
       nodes in an ensemble and therefore the cost of a vote can increase
       significantly as more voters are added.
     </para>
     <para>
       We have introduced a new type of ZooKeeper node called
       an <emphasis>Observer</emphasis> which helps address this problem and
       further improves ZooKeeper's scalability. Observers are non-voting members
       of an ensemble which only hear the results of votes, not the agreement
       protocol that leads up to them. Other than this simple distinction,
       Observers function exactly the same as Followers - clients may connect to
       them and send read and write requests to them. Observers forward these
       requests to the Leader like Followers do, but they then simply wait to
       hear the result of the vote. Because of this, we can increase the number
       of Observers as much as we like without harming the performance of votes.
     </para>
     <para>
       Observers have other advantages. Because they do not vote, they are not a
       critical part of the ZooKeeper ensemble. Therefore they can fail, or be
       disconnected from the cluster, without harming the availability of the
       ZooKeeper service. The benefit to the user is that Observers may connect
       over less reliable network links than Followers. In fact, Observers may be
       used to talk to a ZooKeeper server from another data center. Clients of
       the Observer will see fast reads, as all reads are served locally, and
       writes result in minimal network traffic as the number of messages
       required in the absence of the vote protocol is smaller.
     </para>
   </section>
   <section id="sc_UsingObservers">
     <title>How to use Observers</title>
     <para>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:
     </para>
     <programlisting>
       peerType=observer
     </programlisting>

     <para>
       This line tells ZooKeeper that the server is to be an Observer. Secondly,
       in every server config file, you must add :observer to the server
       definition line of each Observer. For example:
     </para>

     <programlisting>
       server.1:localhost:2181:3181:observer
     </programlisting>

     <para>
       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:</para>
     <programlisting>
       $ bin/zkCli.sh -server localhost:2181
     </programlisting>
     <para>
       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 <emphasis>ls</emphasis> to query
       the ZooKeeper service.
     </para>
   </section>

   <section id="ch_UseCases">
     <title>Example use cases</title>
     <para>
       Two example use cases for Observers are listed below. In fact, wherever
       you wish to scale the number of clients of your ZooKeeper ensemble, or
       where you wish to insulate the critical part of an ensemble from the load
       of dealing with client requests, Observers are a good architectural
       choice.
     </para>
     <itemizedlist>
       <listitem>
 	<para> As a datacenter bridge: Forming a ZK ensemble between two
 	datacenters is a problematic endeavour as the high variance in latency
 	between the datacenters could lead to false positive failure detection
 	and partitioning. However if the ensemble runs entirely in one
 	datacenter, and the second datacenter runs only Observers, partitions
 	aren't problematic as the ensemble remains connected. Clients of the
 	Observers may still see and issue proposals.</para>
       </listitem>
       <listitem>
 	<para>As a link to a message bus: Some companies have expressed an
 	interest in using ZK as a component of a persistent reliable message
 	bus. Observers would give a natural integration point for this work: a
 	plug-in mechanism could be used to attach the stream of proposals an
 	Observer sees to a publish-subscribe system, again without loading the
 	core ensemble.
 	</para>
       </listitem>
     </itemizedlist>
   </section>
 </article>
	<?xml version="1.0" encoding="UTF-8"?>
	<!--
	Copyright 2002-2004 The Apache Software Foundation

	Licensed under the Apache License, Version 2.0 (the "License");
	you may not use this file except in compliance with the License.
	You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN"
	"http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
	<article id="bk_GettStartedGuide">
	<title>ZooKeeper Observers</title>

	<articleinfo>
	<legalnotice>
	<para>Licensed under the Apache License, Version 2.0 (the "License"); you
	may not use this file except in compliance with the License. You may
	obtain a copy of the License
	at <ulink url="http://www.apache.org/licenses/LICENSE-2.0">http://www.apache.org/licenses/LICENSE-2.0</ulink>.</para>

	<para>Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
	WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
	License for the specific language governing permissions and limitations
	under the License.</para>
	</legalnotice>

	<abstract>
	<para>This guide contains information about using non-voting servers, or
	observers in your ZooKeeper ensembles.</para>
	</abstract>
	</articleinfo>

	<section id="ch_Introduction">
	<title>Observers: Scaling ZooKeeper Without Hurting Write Performance
	</title>
	<para>
	Although ZooKeeper performs very well by having clients connect directly
	to voting members of the ensemble, this architecture makes it hard to
	scale out to huge numbers of clients. The problem is that as we add more
	voting members, the write performance drops. This is due to the fact that
	a write operation requires the agreement of (in general) at least half the
	nodes in an ensemble and therefore the cost of a vote can increase
	significantly as more voters are added.
	</para>
	<para>
	We have introduced a new type of ZooKeeper node called
	an <emphasis>Observer</emphasis> which helps address this problem and
	further improves ZooKeeper's scalability. Observers are non-voting members
	of an ensemble which only hear the results of votes, not the agreement
	protocol that leads up to them. Other than this simple distinction,
	Observers function exactly the same as Followers - clients may connect to
	them and send read and write requests to them. Observers forward these
	requests to the Leader like Followers do, but they then simply wait to
	hear the result of the vote. Because of this, we can increase the number
	of Observers as much as we like without harming the performance of votes.
	</para>
	<para>
	Observers have other advantages. Because they do not vote, they are not a
	critical part of the ZooKeeper ensemble. Therefore they can fail, or be
	disconnected from the cluster, without harming the availability of the
	ZooKeeper service. The benefit to the user is that Observers may connect
	over less reliable network links than Followers. In fact, Observers may be
	used to talk to a ZooKeeper server from another data center. Clients of
	the Observer will see fast reads, as all reads are served locally, and
	writes result in minimal network traffic as the number of messages
	required in the absence of the vote protocol is smaller.
	</para>
	</section>
	<section id="sc_UsingObservers">
	<title>How to use Observers</title>
	<para>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:
	</para>
	<programlisting>
	peerType=observer
	</programlisting>

	<para>
	This line tells ZooKeeper that the server is to be an Observer. Secondly,
	in every server config file, you must add :observer to the server
	definition line of each Observer. For example:
	</para>

	<programlisting>
	server.1:localhost:2181:3181:observer
	</programlisting>

	<para>
	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:</para>
	<programlisting>
	$ bin/zkCli.sh -server localhost:2181
	</programlisting>
	<para>
	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 <emphasis>ls</emphasis> to query
	the ZooKeeper service.
	</para>
	</section>

	<section id="ch_UseCases">
	<title>Example use cases</title>
	<para>
	Two example use cases for Observers are listed below. In fact, wherever
	you wish to scale the number of clients of your ZooKeeper ensemble, or
	where you wish to insulate the critical part of an ensemble from the load
	of dealing with client requests, Observers are a good architectural
	choice.
	</para>
	<itemizedlist>
	<listitem>
	<para> As a datacenter bridge: Forming a ZK ensemble between two
	datacenters is a problematic endeavour as the high variance in latency
	between the datacenters could lead to false positive failure detection
	and partitioning. However if the ensemble runs entirely in one
	datacenter, and the second datacenter runs only Observers, partitions
	aren't problematic as the ensemble remains connected. Clients of the
	Observers may still see and issue proposals.</para>
	</listitem>
	<listitem>
	<para>As a link to a message bus: Some companies have expressed an
	interest in using ZK as a component of a persistent reliable message
	bus. Observers would give a natural integration point for this work: a
	plug-in mechanism could be used to attach the stream of proposals an
	Observer sees to a publish-subscribe system, again without loading the
	core ensemble.
	</para>
	</listitem>
	</itemizedlist>
	</section>
	</article>