Pasos súper detallados de ZooKeeper para construir un clúster

Construye un clúster de Zookeeper

1.1 Requisitos de construcción

El clúster real debe implementarse en diferentes servidores, pero cuando probamos, iniciamos muchas máquinas virtuales al mismo tiempo. La memoria será abrumadora, por lo que generalmente construimos un pseudo clúster , lo que significa que todos los servicios se basan en una máquina virtual. Distinguir por puerto.

Aquí necesitamos un clúster Zookeeper de tres nodos (pseudo clúster).

1.2 Preparación

Vuelva a implementar una máquina virtual como servidor de prueba para nuestro clúster.

(1) Instale JDK [Este paso se omite]

(2) Cargue el paquete comprimido de Zookeeper en el servidor

(3) Descomprima Zookeeper, cree un directorio / usr / local / zookeeper-cluster y copie el Zookeeper descomprimido en los siguientes tres directorios

/ 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) Cree el directorio de datos y cambie el nombre del archivo zoo_sample.cfg bajo conf a 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) Configure dataDir y clientPort de cada Zookeeper como 2181 2182 2183 respectivamente

Modificar /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

Modificar /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

Modificar /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 Configurar el clúster

(1) Cree un archivo myid en el directorio de datos de cada cuidador del zoológico con los contenidos 1, 2 y 3. Este archivo es para registrar el ID de cada servidor.

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) Configure el puerto de acceso del cliente (clientPort) y la lista de IP del servidor de clúster en zoo.cfg de cada cuidador del zoológico.

La lista de IP del servidor de clúster es la siguiente

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

Explicación: servidor. ID del servidor = dirección IP del servidor: puerto de comunicación entre servidores: puerto de votación entre servidores

Puerto predeterminado para la comunicación entre el cliente y el servidor: 2181

Puerto predeterminado para la comunicación entre servidores: 2881

El puerto predeterminado para votar entre servidores: 3881

El servicio AdminService en ZooKeeper ocupa el puerto 8080 de forma predeterminada

La elección se basa en el tamaño del número de identificación del servidor aquí

1.4 Iniciar el clúster

Iniciar un clúster es iniciar cada instancia por separado.

/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

Después del inicio, verificamos el estado de ejecución de cada instancia.

/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

Primero consulta el primer servicio, el modo es seguidor significa seguidor (desde)

Luego consulta el segundo servicio, Mode es líder, lo que significa que es el líder (maestro)

** Razón: ** Hay dos servidores que pueden ejecutarse. Está satisfecho de que el número de servidores ejecutables es mayor que la mitad del número total de servidores en el clúster, y dado que el ID del segundo servidor es el más grande en este vez, el primero votó por el segundo y el segundo votó por usted mismo, por lo que el número 2 se convierte en líder

La tercera consulta es el seguidor (de)

Razón: el servidor recién agregado no afectará al líder existente

1.5 Simular excepción de clúster

(1) Primero que nada, probemos qué sucede si el servidor esclavo cuelga. Detenga el servidor 3, observe los números 1 y 2, y descubra que el estado no ha cambiado.

/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

Se concluye que el clúster de 3 nodos, el servidor esclavo está inactivo y el clúster es normal.

(2) Detengamos el servidor n. ° 1 (servidor esclavo) nuevamente, verifiquemos el estado del n. ° 2 (servidor maestro) y descubramos que ha dejado de ejecutarse.

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

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

A partir de esto, se concluye que en un clúster de 3 nodos, 2 servidores esclavos están inactivos y el servidor maestro no se puede ejecutar. Porque el número de máquinas ejecutables no supera la mitad del número total de clústeres.

(3) Iniciamos de nuevo el servidor N ° 1 y descubrimos que el servidor N ° 2 comenzó a funcionar normalmente nuevamente. Y sigue siendo el líder.

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

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

(4) También iniciamos el servidor n. ° 3, paramos el servidor n. ° 2 y observamos el estado del servidor n. ° 1 y n. ° 3 después de parar.

/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

Descubrió que el servidor 3 se convirtió en el nuevo líder.

A partir de esto, hemos llegado a la conclusión de que cuando el servidor principal del clúster deja de funcionar, los otros servidores del clúster realizarán automáticamente el estado de elección y luego generarán un nuevo líder.

(5) Después de reiniciar el servidor No. 2, ¿se convertirá el servidor No. 2 en el nuevo líder nuevamente?

/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

Descubriremos que el servidor 2 sigue siendo un seguidor (servidor esclavo) después de que se inicia, el servidor 3 sigue siendo el líder (servidor maestro) y no ha sacudido el liderazgo del servidor 3.

De esto hemos concluido que cuando se produce el líder, se agrega un nuevo servidor al clúster nuevamente, y el líder actual no se verá afectado.