Quite often we will have distributed services running on multiple servers (especially masters, for e.g.: Active/Passive Namenode of HDFS). Zookeeper can keep track of the multiple servers associated with a distributed service and ensure that it serves the clients of that service with High Availability and Fault Tolerance. Zookeeper service handles the following functions in a distributed environment.
- Synchronization – Typically used in case client applications should get same data from all the servers on which Zookeeper is running. If one of the follower is behind the leader and client request goes to that follower, the follower will first synchronize and then serve the client.
- Configuration Management – not used by typical Big Data Services. We can manage configuration of any application using Zookeeper.
- Grouping and Naming Registry – Used in Micro Services for Service registry or discovery.
- Leader Election – e.g.: HBase, Leader for Kafka Topic partitions etc
Design Goals
You can run zkCli.sh command to get details about services Zookeeper is managing. Make sure to create softlink for java executable so that zkCli.sh can run.
- Simple
- ZooKeeper allows distributed processes to coordinate with each other through a shared hierarchal namespace which is organized similarly to a standard file system.
- The namespace consists of data registers – called znodes, in ZooKeeper parlance
- znodes are similar to files and directories in Linux file system.
- Information is typically stored in memory and transaction logs are generated in files, but as it grows snapshot of this information will be persisted in the file system.
- Replicated
- Zookeeper itself is deployed on multiple hosts and manages itself.
- Zookeeper cluster is also called as an ensemble. Typically ensemble will be either 3 nodes or 5 nodes or 7 nodes.
- The servers that make up the ZooKeeper service must all know about each other.
- They maintain an in-memory image of the state, along with transaction logs and snapshots in a persistent store.
- As long as a majority of the servers are available, the ZooKeeper service will be available.
- Clients connect to a single ZooKeeper server.
- The client maintains a TCP connection through which it sends requests, gets responses, gets watch events, and sends heartbeats.
- If the TCP connection to the server breaks, the client will connect to a different server.
- Ordered
- ZooKeeper stamps each update with a number that reflects the order of all ZooKeeper transactions.
- Subsequent operations can use the order to implement higher-level abstractions, such as synchronization primitives.
- Fast
- It is especially fast in “read-dominant” workloads.
- ZooKeeper applications run on thousands of machines, and it performs best where reads are more common than writes, at ratios of around 10:1.
Data Model and Hierarchical Namespace
Now let us run zkCli.sh command and understand how the services are represented.
- Whenever a service is registered with Zookeeper, you will see an entry under /.
- It is called as znode
- Each znode might have children and they will have a path associated with it similar to the file system hierarchy.
- We will see these details when services such HDFS, YARN, HBase etc are added to the cluster later.