In this section, we will look at configuration options that are mostly used with an ensemble of ZooKeeper servers. A ZooKeeper ensemble or cluster of replicated ZooKeeper servers should be configured optimally to avoid scenarios such as split-brain. A split-brain scenario might happen due to network portioning where two different servers of the same ensemble might pose as leaders and cause inconsistencies.
The following configuration options are available with an ensemble of ZooKeeper servers:
electionAlg: This option is used to choose a leader in a ZooKeeper ensemble. A value of 0 corresponds to the original UDP-based version, 1 corresponds to the non-authenticated UDP-based version of fast leader election, 2 corresponds to the authenticated UDP-based version of fast leader election, and 3 corresponds to the TCP-based version of fast leader election. Currently, algorithm 3 is the default. The implementations of leader election 0, 1, and 2 are now deprecated, and fast leader election is the only one used. Available options are as followsinitLimit: This refers to the amount of time, measured in ticks, to allow followers to connect with the leader.initLimitshould be set depending on the network speed (and hops) between the leader and follower and based on the amount of data to be transferred between the two. If the amount of data stored by ZooKeeper is huge due to a large number of znodes and the amount of data stored in them, or if the network bandwidth is low,initLimitshould be increased.syncLimit: This is the amount of time measured in ticks to allow followers to sync with a leader. If the followers fall too far behind the leader due to server load or network problems, they are dropped. However, the amount of data stored by ZooKeeper has no effect on the synchronization time between the leader and follower. Instead,syncLimitdepends on network latency and throughput.leaderServes: By default, the server in an ensemble that runs in the leader mode also accepts client connections. However, in a loaded and busy ensemble with an update-heavy workload, we can configure the leader server to not accept client connections. This can be configured using thezookeeper.leaderServesJava system property. This can aid in coordinating write updates at a faster rate and, hence, can lead to increased write throughput.cnxTimeout: This refers to the timeout value for opening connections for leader election notifications. This parameter is only applicable with leader election algorithm 3 –fast leader election. The default value is5seconds.server.x=[hostname]:port1[:port2]: This parameter is used to define servers in the ZooKeeper ensemble. When the ZooKeeper server process starts up, it determines its identity by looking for themyidfile in the data directory. Themyidfile contains the server number in ASCII; this should be the same as x inserver.x of the configuration parameter. This parameter can be further explained as follows:- There are two TCP port numbers:
port1andport2. The first port is used to send transaction updates, and the second one is for leader election. The leader election port is only necessary ifelectionAlgis 1, 2, or 3 (default). In Chapter 1, A Crash Course in Apache ZooKeeper, we saw how to use different port numbers to test multiple servers on a single machine. - It is very important that all servers use the same
server.x configuration for proper connection to happen between them. Also, the list of servers that make up ZooKeeper servers that is used by the clients must match the list of ZooKeeper servers that each ZooKeeper server has.
- There are two TCP port numbers:
ZooKeeper allows for the flexible configuration of quorums within the ensemble. We can form hierarchical quorums by classifying the ZooKeeper servers into groups. This is particularly useful for forming a ZooKeeper ensemble that spans multiple data centers. An ensemble across data centers helps in ensuring a high availability of the service during disaster scenarios. The following options are useful for forming such groups in an ensemble:
group.x=nnnnn[:nnnnn]: This enables a hierarchical quorum construction. x is a group identifier and nnnnn corresponds to server identifiers. Groups must be disjoint, and the union of all the groups must be the ZooKeeper ensemble.weight.x=nnnnn: This is used to assign weight to servers in a group when forming quorums. It corresponds to the weight of a server when voting for leader election and for the atomic broadcast protocol Zookeeper Atomic Broadcast (ZAB). By default, the weight of a server is1. Assigning more weight to a server allows it to form a quorum with other servers more easily.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.