Initial ZooKeeper and cluster creation instance

Initial ZooKeeper and cluster creation instance

What is zookeeper?

Zookeeper, a collaborative service for distributed applications, is an open-source implementation of Google's Chubby and a Distributed Coordination Service of Hadoop. It contains a simple primitive set, the service is used for Distributed Application collaboration, so that distributed applications can implement services such as synchronization, configuration maintenance, and cluster-based or named services based on these interfaces.

Zookeeper is a cluster composed of multiple services, one leader and multiple follower. Each server stores a copy of data, and global data is consistent. distributed read/write and update request forwarding are implemented by the leader.

Requests are updated in the order in which they are sent. Update requests from the same client are executed in sequence. Data Update is atomic. A data update is either successful or failed, and the data is globally unique, no matter which server the client is connected to, the data tries to be consistent.

Why use zookeeper?

Most distributed applications require a master, Coordinator, or controller to Manage Sub-processes (such as resources and task allocation) that are physically distributed. Currently, most applications need to develop private coordination programs, A general mechanism is lacking. it is a waste of repeated compilation of Coordination programs, and it is difficult to form a common and scalable coordinator. ZooKeeper: provides a general distributed lock Service to coordinate distributed applications.

How zookeeper works

The core of zookeeper is atomic broadcasting. This mechanism ensures synchronization between various servers. The protocol for implementing this mechanism is called Zab protocol. the Zab protocol has two modes: recovery mode and broadcast mode.

1. after the service is started or the leader crashes, Zab enters the recovery mode. When the leader is elected and most servers are synchronized with the leader status, the recovery mode is over. state synchronization ensures that the leader and server have the same system status.

2. once the leader has synchronized the status with most follower, it can broadcast messages, that is, entering the broadcast status. at this time, when a server is added to the zookeeper service, it will start in recovery mode, send the leader, and synchronize the status with the leader. When the synchronization ends, it will also participate in broadcasting messages.

Note:

The broadcast mode must ensure that proposal is processed in order, so zk uses an incremental transaction ID (zxid) to ensure that. zxid is added to all proposals. in the implementation, zxid is a 64-bit number, and its 32-bit height is the epoch used to identify whether the leader relationship has changed. Each time a leader is selected, it will have a new epoch. 32-bit low is an incremental count.

When the leader crashes or the leader loses most of the follower, zk enters the recovery mode. In the recovery mode, a new leader needs to be elected to restore all servers to a correct state.

The zookeeper service remains in the Broadcast State until the leader crashes or the leader loses most of the followers support.

The Broadcast mode is very similar to the 2 pc (two-phrase commit two-phase commit) in distributed transactions. That is, the leader initiates a resolution and is voted by followers, the leader calculates the voting result and determines whether to pass the resolution. If it executes the resolution (transaction), it will not do anything.

Leader Election

After each Server is started, it will ask the other Server who it wants to vote, the server replies the recommended leader id and the zxid of the last transaction based on its status (each server recommends itself when the system starts). After receiving all Server replies, calculate the Server with the largest zxid and set the Server information to the Server to be voted next time. the server that obtains the most votes in the calculation process is the winner. If more than half of the votes are received, the server is selected as the leader. otherwise, continue the process until the leader is elected. the leader will start to wait for the server connection. The Follower connects to the leader and sends the largest zxid to the leader. The Leader determines the synchronization point based on the zxid of the follower. After the synchronization is completed, the follower will be notified that it is in, after receiving the uptodate message, Follower can accept the client request again for service.

Zookeeper Data Model

Hierarchical directory structure, naming complies with common file system specifications

Each node is called znode in zookeeper and has a unique path ID.

Node Znode can contain data and subnodes, but EPHEMERAL nodes cannot have subnodes.

The data in Znode can have multiple versions. For example, if a path contains multiple data versions, the data in the query path must contain versions.

The client application can set a monitor on the node. The node does not support partial read/write, but one-time complete read/write.

Zoopkeeper provides a good distributed cluster management mechanism, which is a hierarchical directory tree-based data structure and effectively manages nodes in the tree, A variety of distributed data management models can be designed.

Zookeeper Node

Znode has two types: Short (ephemeral) and persistent (persistent)

The Znode type is determined at creation and cannot be modified later.

When the client session of a short znode ends, zookeeper deletes the short znode. A short znode cannot have a subnode.

Persistent znode does not depend on client sessions. It is deleted only when the client explicitly wants to delete the persistent znode.

Znode has four types of directory nodes: PERSISTENT, PERSISTENT_SEQUENTIAL, EPHEMERAL, and EPHEMERAL_SEQUENTIAL.

Znode can be monitored, including the modification of data stored in this directory node and the change of the sub-node directory. Once changed, the monitoring client can be notified, this function is the most important feature of zookeeper for applications,

This feature enables centralized configuration management, cluster management, and distributed locks.

Zookeeper role

Leader is responsible for initiating voting and making resolutions, and updating the system status.

Learner, including follower and observer ).

Follower is used to accept client requests and want the client to return results to participate in the voting process

The Observer can accept client connections and forward write requests to the leader. However, the observer only synchronizes the status of the leader without voting. The observer aims to expand the system and increase the reading speed.

Client, the requester

Watcher

Watcher is a core function in ZooKeeper. Watcher can monitor data changes of directory nodes and subdirectory changes. Once these statuses change, the server will notify all Watcher sets on this directory node, so that every client will soon know that the status of the directory node that it is concerned with has changed, and then respond accordingly.

You can set the observed operations: exists, getChildren, getData

Operations that can trigger observation: create, delete, setData

When znode changes in some way, the "watch" mechanism can notify the client.

You can set the observation for the "operation" of the ZooKeeper service. Other operations of the service can trigger the observation.

For example, the client can call the exists operation on a client and set an observation on it. If the znode does not exist at this time, exists returns false, if this znode is created by another client, this observation will be triggered and the previous client will be notified.

Zookeeper cluster Construction

Zookeeper not only provides services on a single machine, but also supports multi-host cluster creation to provide services. In fact, Zookeeper also supports another pseudo cluster mode, that is, you can run multiple Zookeeper instances on a physical machine.

Zookeeper achieves high availability through replication. As long as more than half of the machines in the collection are available, it can ensure the service continues.

Cluster Disaster Tolerance:

As long as there are two available three machines, you can select the leader and provide external services (2n + 1 machine, can accommodate n machines ).

Zookeeper pseudo-distributed environment construction:

1. Go to the Zookeeper official website to download the latest Zookeeper version.

[Root @ localhost zookeeper-cluster] # pwd
/Export/search/zookeeper-cluster
[Root @ localhost zookeeper-cluster] # ls
Zookeeper-3.4.6.tar.gz
[Root @ localhost zookeeper-cluster] #
[Root @ localhost zookeeper-cluster] # tar-zxvf zookeeper-3.4.6.tar.gz
# Create the first cluster node
[Root @ localhost zookeeper-cluster] # Music zookeeper-3.4.6 zookeeper-3.4.6-node1
[Root @ localhost zookeeper-cluster] # cd zookeeper-3.4.6-node1
[Root @ localhost zookeeper-3.4.6-node1] # pwd
/Export/search/zookeeper-cluster/zookeeper-3.4.6-node1
# Create a data storage path
[Root @ localhost zookeeper-3.4.6-node1] # mkdir data
[Root @ localhost zookeeper-3.4.6-node1] # cd ../
# Create the second and third cluster nodes
[Root @ localhost zookeeper-cluster] # cp zookeeper-3.4.6-node1 zookeeper-3.4.6-node2-R
[Root @ localhost zookeeper-cluster] # cp zookeeper-3.4.6-node1 zookeeper-3.4.6-node3-R
[Root @ localhost zookeeper-cluster] # ls
Zookeeper-3.4.6-node1 zookeeper-3.4.6-node2 zookeeper-3.4.6-node3 zookeeper-3.4.6.tar.gz
[Root @ localhost zookeeper-cluster] # zookeeper-3.4.6-node1/conf/cd/
[Root @ localhost conf] # ls
Configuration. xsl log4j. properties zoo_sample.cfg
# Create a zoo. cfg file
[Root @ localhost conf] # cp zoo_sample.cfg zoo. cfg

2. Configure the zoo. cfg file:

# Zookeeper-3.4.6-node1 Configuration
TickTime = 2000
InitLimit = 10
SyncLimit = 5
ClientPort = 2181
DataDir =/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data
Server.1 = localhost: 2887: 3887
Server .2 = localhost: 2888: 3888
Server.3 = localhost: 2889: 3889

# Zookeeper-3.4.6-node2 Configuration
TickTime = 2000
InitLimit = 10
SyncLimit = 5
ClientPort = 2182
DataDir =/export/search/zookeeper-cluster/zookeeper-3.4.6-node2/data
Server.1 = localhost: 2887: 3887
Server .2 = localhost: 2888: 3888
Server.3 = localhost: 2889: 3889

# Zookeeper-3.4.6-node3 Configuration
TickTime = 2000
InitLimit = 10
SyncLimit = 5
ClientPort = 2183
DataDir =/export/search/zookeeper-cluster/zookeeper-3.4.6-node3/data
Server.1 = localhost: 2887: 3887
Server .2 = localhost: 2888: 3888
Server.3 = localhost: 2889: 3889

Parameter description:

Ticktime= 2000:
TickTime is the interval between the Zookeeper server or between the client and the server to maintain the heartbeat, that is, each tickTime will send a heartbeat;

InitLimit = 10:
The initLimit configuration item is used to configure Zookeeper to accept the client (the client mentioned here is not the client that the user connects to the Zookeeper server, but the Follower server connected to the Leader in the Zookeeper server cluster) the maximum heartbeat interval that can be tolerated during connection initialization.
When the length of the heartbeat exceeds 10 (tickTime), the Zookeeper server does not receive the response from the client, which indicates that the connection to the client fails. The total length is 10*2000 = 20 seconds;

SyncLimit = 5:
The syncLimit configuration item identifies the length of time for sending a message, request, and response between the Leader and Follower. the maximum length of a message length is 5*2000 = 10 seconds;

DataDir =/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data
DataDir, as its name implies, is the directory where Zookeeper saves data. By default, Zookeeper stores the log files that write data in this directory;

ClientPort = 2181
The clientPort is the port on which the client connects to the Zookeeper server. Zookeeper listens to the port and accepts the client's access requests;

Server.1 = localhost: 2887: 3887
Server .2 = localhost: 2888: 3888
Server.3 = localhost: 2889: 3889
Server. A = B: C: D:
A is A number indicating the number of the server, and B indicates the IP address of the server.
The first port of C is used for information exchange between cluster members, indicating the port on which the server exchanges information with the Leader server in the cluster.
D is used for election leader when the leader fails.

3. Create a ServerID ID

Except for zoo. the cfg configuration file also needs to be configured in cluster mode. This file is under the dataDir directory, and there is A data in this file that is the value of A, in the above configuration file zoo. create a myid file in the dataDir path configured in cfg

[Root @ localhost zookeeper-cluster] # cat/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data/myid
1
[Root @ localhost zookeeper-cluster] # cat/export/search/zookeeper-cluster/zookeeper-3.4.6-node2/data/myid
22
[Root @ localhost zookeeper-cluster] # cat/export/search/zookeeper-cluster/zookeeper-3.4.6-node3/data/myid
3

4. Start zookeeper

[Root @ localhost zookeeper-cluster] #/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/bin/zkServer. sh start
JMX enabled by default
Using config:/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/bin/../conf/zoo. cfg
Starting zookeeper... STARTED
[Root @ localhost zookeeper-cluster] #/export/search/zookeeper-cluster/zookeeper-3.4.6-node2/bin/zkServer. sh start
JMX enabled by default
Using config:/export/search/zookeeper-cluster/zookeeper-3.4.6-node2/bin/../conf/zoo. cfg
Starting zookeeper... STARTED
[Root @ localhost zookeeper-cluster] #/export/search/zookeeper-cluster/zookeeper-3.4.6-node3/bin/zkServer. sh start
JMX enabled by default
Using config:/export/search/zookeeper-cluster/zookeeper-3.4.6-node3/bin/../conf/zoo. cfg
Starting zookeeper... STARTED

5. Check whether the cluster is started.

[Root @ localhost zookeeper-cluster] # echo stat | nc localhost 2181
[Root @ localhost zookeeper-cluster] # echo stat | nc localhost 2182
[Root @ localhost zookeeper-cluster] # echo stat | nc localhost 2183
# Or
[Root @ localhost zookeeper-cluster] #/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/bin/zkCli. sh
[Root @ localhost zookeeper-cluster] #/export/search/zookeeper-cluster/zookeeper-3.4.6-node2/bin/zkCli. sh
[Root @ localhost zookeeper-cluster] #/export/search/zookeeper-cluster/zookeeper-3.4.6-node3/bin/zkCli. sh

Precautions for deploying pseudo clusters:

Three servers are deployed on one machine. Note that if multiple servers are deployed on one machine, each machine has a different clientPort.

For example, server.1 is 2181, server.2 is 2182, and server.3 is 2183.

The only thing to note in the last few lines is

The number server. X corresponds to the number in data/myid. You have written 1, 2, 3 to the myid files of the three servers respectively. Therefore, zoo. cfg in each server is configured with server.1, server.2, and server.3.

-------------------------------------- Split line --------------------------------------

Ubuntu 14.04 installs distributed storage Sheepdog + ZooKeeper

CentOS 6 installs sheepdog VM distributed storage

ZooKeeper cluster configuration

Use ZooKeeper to implement distributed shared locks

Distributed service framework ZooKeeper-manage data in a distributed environment

Build a ZooKeeper Cluster Environment

Test Environment configuration of ZooKeeper server cluster

ZooKeeper cluster Installation

This article permanently updates the link address: