ZooKeeper étapes très détaillées pour créer un cluster

Créer un cluster Zookeeper

1.1 Exigences de construction

Le vrai cluster doit être déployé sur différents serveurs, mais lorsque nous testons, nous démarrons un grand nombre de machines virtuelles en même temps. La mémoire sera écrasante, nous construisons donc généralement un pseudo cluster , ce qui signifie que tous les services sont basés sur une machine virtuelle., Distinguer par port.

Ici, nous avons besoin d'un cluster Zookeeper à trois nœuds (pseudo cluster).

1.2 Préparation

Redéployez une machine virtuelle en tant que serveur de test pour notre cluster.

(1) Installer JDK [Cette étape est omise]

(2) Téléchargez le package compressé Zookeeper sur le serveur

(3) Décompressez Zookeeper, créez un répertoire / usr / local / zookeeper-cluster et copiez le Zookeeper décompressé dans les trois répertoires suivants

/ usr / local / zookeeper-cluster / zookeeper-1

/ usr / local / zookeeper-cluster / zookeeper-2

/ usr / local / zookeeper-cluster / zookeeper-3

[root@localhost ~]# mkdir /usr/local/zookeeper-cluster
[root@localhost ~]# cp -r  apache-zookeeper-3.5.6-bin /usr/local/zookeeper-cluster/zookeeper-1
[root@localhost ~]# cp -r  apache-zookeeper-3.5.6-bin /usr/local/zookeeper-cluster/zookeeper-2
[root@localhost ~]# cp -r  apache-zookeeper-3.5.6-bin /usr/local/zookeeper-cluster/zookeeper-3

(4) Créez le répertoire de données et renommez le fichier zoo_sample.cfg sous conf en zoo.cfg

mkdir /usr/local/zookeeper-cluster/zookeeper-1/data
mkdir /usr/local/zookeeper-cluster/zookeeper-2/data
mkdir /usr/local/zookeeper-cluster/zookeeper-3/data

mv  /usr/local/zookeeper-cluster/zookeeper-1/conf/zoo_sample.cfg  /usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg
mv  /usr/local/zookeeper-cluster/zookeeper-2/conf/zoo_sample.cfg  /usr/local/zookeeper-cluster/zookeeper-2/conf/zoo.cfg
mv  /usr/local/zookeeper-cluster/zookeeper-3/conf/zoo_sample.cfg  /usr/local/zookeeper-cluster/zookeeper-3/conf/zoo.cfg

(5) Configurez dataDir et clientPort de chaque Zookeeper comme 2181 2182 2183 respectivement

Modifiez /usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg

vim /usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg

clientPort=2181
dataDir=/usr/local/zookeeper-cluster/zookeeper-1/data

Modifiez /usr/local/zookeeper-cluster/zookeeper-2/conf/zoo.cfg

vim /usr/local/zookeeper-cluster/zookeeper-2/conf/zoo.cfg

clientPort=2182
dataDir=/usr/local/zookeeper-cluster/zookeeper-2/data

Modifiez /usr/local/zookeeper-cluster/zookeeper-3/conf/zoo.cfg

vim /usr/local/zookeeper-cluster/zookeeper-3/conf/zoo.cfg

clientPort=2183
dataDir=/usr/local/zookeeper-cluster/zookeeper-3/data

1.3 Configurer le cluster

(1) Créez un fichier myid dans le répertoire de données de chaque gardien de zoo avec les contenus 1, 2 et 3. Ce fichier sert à enregistrer l'ID de chaque serveur

echo 1 >/usr/local/zookeeper-cluster/zookeeper-1/data/myid
echo 2 >/usr/local/zookeeper-cluster/zookeeper-2/data/myid
echo 3 >/usr/local/zookeeper-cluster/zookeeper-3/data/myid

(2) Configurez le port d'accès client (clientPort) et la liste d'adresses IP du serveur de cluster dans zoo.cfg de chaque gardien de zoo

La liste d'adresses IP du serveur de cluster est la suivante

vim /usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg
vim /usr/local/zookeeper-cluster/zookeeper-2/conf/zoo.cfg
vim /usr/local/zookeeper-cluster/zookeeper-3/conf/zoo.cfg

server.1=192.168.149.135:2881:3881
server.2=192.168.149.135:2882:3882
server.3=192.168.149.135:2883:3883

Explication: serveur. ID serveur = adresse IP du serveur: port de communication entre serveurs: port de vote entre serveurs

Port par défaut pour la communication client et serveur: 2181

Port par défaut pour la communication entre les serveurs: 2881

Le port par défaut pour voter entre les serveurs: 3881

Le service AdminService de ZooKeeper occupe le port 8080 par défaut

Le choix est basé sur la taille du numéro d'identification du serveur ici

1.4 Démarrez le cluster

Pour démarrer un cluster, il faut démarrer chaque instance séparément.

/usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh start
/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh start
/usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh start

Insérez la description de l'image ici

Après le démarrage, nous vérifions l'état de fonctionnement de chaque instance

/usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh status
/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh status
/usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh status

Première interrogation du premier service, le mode est suiveur signifie suiveur (de)

Insérez la description de l'image ici

Ensuite, interrogez le deuxième service, Mode est leader, ce qui signifie que c'est le leader (maître)

** Raison: ** Deux serveurs peuvent s'exécuter. Nous sommes convaincus que le nombre de serveurs exécutables est supérieur à la moitié du nombre total de serveurs dans le cluster et que l'ID du deuxième serveur est le plus important fois, le 1er a voté pour le 2ème et le 2ème Votez pour vous-même, donc le n ° 2 devient chef

Insérez la description de l'image ici

La troisième requête est le suiveur (de)

Insérez la description de l'image ici

Raison: le serveur nouvellement ajouté n'affectera pas le leader existant

1.5 Simuler une exception de cluster

(1) Tout d'abord, testons ce qui se passe si le serveur esclave raccroche: arrêtez le serveur 3, observez les numéros 1 et 2 et constatez que l'état n'a pas changé.

/usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh stop

/usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh status
/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh status

Insérez la description de l'image ici

On en conclut que le cluster de 3 nœuds, le serveur esclave est en panne et le cluster est normal

(2) Arrêtons à nouveau le serveur n ° 1 (serveur esclave), vérifions l'état du n ° 2 (serveur maître) et constatons qu'il a cessé de fonctionner.

/usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh stop

/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh status

Insérez la description de l'image ici

À partir de là, il est conclu que dans un cluster à 3 nœuds, 2 serveurs esclaves sont arrêtés et le serveur maître ne peut pas fonctionner. Parce que le nombre de machines exécutables ne dépasse pas la moitié du nombre total de clusters.

(3) Nous avons redémarré le serveur n ° 1 et avons constaté que le serveur n ° 2 a recommencé à fonctionner normalement. Et toujours le leader.

/usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh start

/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh status

Insérez la description de l'image ici

(4) Nous démarrons également le serveur n ° 3, arrêtons le serveur n ° 2 et observons l'état des n ° 1 et n ° 3 après l'arrêt.

/usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh start
/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh stop

/usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh status
/usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh status

Insérez la description de l'image ici

A découvert que le serveur 3 est devenu le nouveau leader

De cela, nous avons conclu que lorsque le serveur principal du cluster tombe en panne, les autres serveurs du cluster exécutent automatiquement l'état d'élection, puis génèrent un nouveau leader

(5) Après avoir redémarré le serveur n ° 2, le serveur n ° 2 redeviendra-t-il le nouveau leader?

/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh start

/usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh status
/usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh status

Insérez la description de l'image ici

Nous verrons que le serveur 2 est toujours un suiveur (serveur esclave) après son démarrage, le serveur 3 est toujours le leader (serveur maître), et il n'a pas ébranlé la direction du serveur 3.

De cela, nous avons conclu que lorsque le leader est produit, un nouveau serveur est à nouveau ajouté au cluster, et le leader actuel ne sera pas affecté.

Je suppose que tu aimes

Origine blog.csdn.net/weixin_49343190/article/details/112967154
conseillé
Classement