Vishal Kathuria Zookeeper use at Facebook Project Zeus – Goals Tao Design Tao Workload simulator Early results of Zookeeper testing Zookeeper Improvements HDFS ◦ For location of the name node ◦ Name node leader election ◦ 75K temporary (permanent in future) clients HBase ◦ For mapping of regions to region servers, location of ROOT node ◦ Region server failure detection and failover ◦ After UDBs more to HBase, ~100K permanent clients Titan ◦ Mapping of user to Prometheus web server within a cell ◦ Leader election of Prometheus web server ◦ Future: Selection of the Hbase geo-cell Ads ◦ Leader Election Scribe ◦ Leader election of scribe aggregators Future customers ◦ TAO Sharding ◦ MySQL Leader Election ◦ Search “Make Zookeeper awesome” ◦ Zookeeper works at Facebook scale ◦ Zookeeper is one of the most reliable services at Facebook Solve pressing infrastructure problems using ZooKeeper ◦ Shard Manager for Tao ◦ Generic Shard Management capability in Tupperware ◦ MySQL HA Project is 5 weeks old Initial sharing of ideas with the community ◦ Ideas not yet whetted or proven through prototypes Shard Map ◦ ◦ ◦ ◦ Based on ranges instead of consistent hash Stored in ZooKeeper Accessed by clients using Aether Populated by Eos Dynamically updated based on load information Scale requirements for a single cluster 24,000 Web machines ◦ Read only clients 6,000 Tao server machines ◦ Read/Write clients About 20 clusters site wide Shard Map is 2-3 MB of data Clients ◦ Read the shard map of local cluster after connection ◦ Put a watch on the shard map ◦ Refresh shard map after watch fires Follower Servers Leader Servers ◦ These servers are clients of the leader servers ◦ Also read their own shard map ◦ Read their own shard map and of all of their followers Shard Manager - Eos ◦ Periodically updates the shard map 3 node zookeeper ensemble ◦ 8 core ◦ 8G RAM Clients – 20 node cluster ◦ Web class machines ◦ 12 G RAM Using Zookeeper ensemble per cluster model Assumptions ◦ 40K connections ◦ Small number of clients joining/leaving at any time ◦ Rare updates to the shard map – once every 10 minutes Result ◦ Zookeeper worked well in this Cluster Powering Up ◦ 25K Clients simultaneously trying to connect ◦ Slow response time It took some clients 560s to connect and get data Cluster powering down ◦ 25 K clients simultaneously disconnect ◦ System Temporarily Unresponsive The disconnect requests filled zookeeper queues System would not accept any more new connections or requests After a short time, the disconnect requests were processed and the system became responsive again Rolling Restart of ZooKeeper Nodes Startup/Shutdown of entire cluster ◦ With active clients ◦ Without active clients Result ◦ No corruptions or system hangs noticed so far Client connect/disconnect is a persisted update involving all nodes The ping and connection timeout handling is done by the leader for all connections Single thread handling connect requests and data requests Zookeeper is implemented as a single threaded pipeline. ◦ All reads are serialized ◦ Low read throughput ◦ Uses only 3 cores at full load Non persisted sessions with local session tracking ◦ Hacked a prototype to test potential ◦ Initial test runs very encouraging Dedicated connection creation thread ◦ Prototyped, test runs in progress Multiple threads for deserializing incoming requests Dedicated parallel pipeline for read only clients