hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "ZooKeeper/FAQ" by PatrickHunt
Date Fri, 12 Feb 2010 18:11:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The "ZooKeeper/FAQ" page has been changed by PatrickHunt.
http://wiki.apache.org/hadoop/ZooKeeper/FAQ?action=diff&rev1=9&rev2=10

--------------------------------------------------

  
  The second option, preferable for many users, is to do a "rolling restart". In this case
you upgrade one server in the ZooKeeper ensemble at a time; bring down the server, upgrade
the code/configuration/etc..., then restart the server. The server will automatically rejoin
the quorum, update it's internal state with the current ZK leader, and begin serving client
sessions. As a result of doing a rolling restart, rather than a full restart, the administrator
can monitor the ensemble as the upgrade progresses, perhaps rolling back if any issues are
encountered.
  
+ 
+ <<BR>>
+ <<Anchor(7)>>
+ '''7. [[#7|How do I size a ZooKeeper ensemble (cluster)?]]'''
+ 
+ In general when determining the number of ZooKeeper serving nodes to deploy (the size of
an ensemble) you need to think in terms of reliability, and not performance.
+ 
+ Reliability:
+ 
+ A single ZooKeeper server (standalone) is essentially a coordinator with no reliability
(a single serving node failure brings down the ZK service).
+ 
+ A 3 server ensemble (you need to jump to 3 and not 2 because ZK works based on simple majority
voting) allows for a single server to fail and the service will still be available.
+ 
+ So if you want reliability go with at least 3. We typically recommend having 5 servers in
"online" production serving environments. This allows you to take 1 server out of service
(say planned maintenance) and still be able to sustain an unexpected outage of one of the
remaining servers w/o interruption of the service.
+ 
+ Performance:
+ 
+ Write performance actually _decreases_ as you add ZK servers, while read performance increases
modestly: http://bit.ly/9JEUju
+ 
+ See [[http://bit.ly/4ekN8G|this page]] for a survey Patrick Hunt (http://twitter.com/phunt)
did looking at operational latency with both standalone server and an ensemble of size 3.
You'll notice that a single core machine running a standalone ZK ensemble (1 server) is still
able to process 15k requests per second. This is orders of magnitude greater than what most
applications require (if they are using ZooKeeper correctly - ie as a coordination service,
and not as a replacement for a database, filestore, cache, etc...)
+ 

Mime
View raw message