Créer un cluster Zookeeper
Répertoire d'articles
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
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)
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
La troisième requête est le suiveur (de)
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
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
À 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
(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
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
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é.