Problemas de nombres DNS de Zookeeper con las elecciones de líder al migrar de Windows a Debian

Problemas de nombres DNS de Zookeeper con las elecciones de líder al migrar de Windows a Debian

Estoy migrando un clúster kafka/zookeeper en Windows a Debian Wheezy.

  • Versión de Java: 1.7.0_80
  • Versión de Debian: 7.9
  • Versión de Zookeeper: 3.3.5+dfsg1-2 0
  • Versión de Kafka: 2.10-0.8.2.1

Si configuro zookeeper en los servidores Debian con direcciones IP para los otros servidores Debian, todo funciona bien. Si en su lugar uso nombres DNS, la elección del líder falla en los servidores Debian.

En los servidores Debian, puedo buscar la IP de cualquiera de los otros servidores Debian usando el comando 'host', por lo que la resolución DNS funciona.

Todo está automatizado: creación del servidor, instalación de Debian, instalación de zookeeper, configuración de zookeeper; por lo que la ventana para errores de configuración manual es mínima y fácil de reproducir o cambiar.

Usarlo clientPortAddress=DNSNAMEno hace ninguna diferencia; todavía falla. No hay nada configurado en iptables. No hay ningún firewall entre estos servidores.

A continuación, los servidores 1 a 3 son servidores Windows 2012R2 y los servidores 4 a 6 son servidores Debian.

Esta configuración funciona:

 server.1=testkafka400:2888:3888
 server.2=testkafka401:2888:3888
 server.3=testkafka402:2888:3888
 server.4=10.1.132.152:2888:3888
 server.5=10.1.132.153:2888:3888
 server.6=10.1.132.154:2888:3888

Esta configuración no funciona:

 server.1=testkafka400:2888:3888
 server.2=testkafka401:2888:3888
 server.3=testkafka402:2888:3888
 server.4=testkafka403:2888:3888
 server.5=testkafka404:2888:3888
 server.6=testkafka405:2888:3888

Cuando uso los nombres DNS, obtengo el siguiente resultado, donde las excepciones simplemente se repiten. Tenga en cuenta que el siguiente registro proviene de una configuración de clúster que contienesoloServidores Debian, que utilizan nombres DNS, para realizar pruebas. Si cambio a IP, el grupo funciona y puede celebrar elecciones.

[2015-11-03 13:55:52,309] INFO Reading configuration from: /etc/zookeeper/config/zookeeper.properties (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
[2015-11-03 13:55:52,322] INFO Defaulting to majority quorums (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
[2015-11-03 13:55:52,344] INFO autopurge.snapRetainCount set to 3 (org.apache.zookeeper.server.DatadirCleanupManager)
[2015-11-03 13:55:52,344] INFO autopurge.purgeInterval set to 24 (org.apache.zookeeper.server.DatadirCleanupManager)
[2015-11-03 13:55:52,345] INFO Purge task started. (org.apache.zookeeper.server.DatadirCleanupManager)
[2015-11-03 13:55:52,454] INFO Purge task completed. (org.apache.zookeeper.server.DatadirCleanupManager)
[2015-11-03 13:55:52,472] INFO Starting quorum peer (org.apache.zookeeper.server.quorum.QuorumPeerMain)
[2015-11-03 13:55:52,581] INFO binding to port 0.0.0.0/0.0.0.0:2181 (org.apache.zookeeper.server.NIOServerCnxnFactory)
[2015-11-03 13:55:52,601] INFO tickTime set to 3000 (org.apache.zookeeper.server.quorum.QuorumPeer)
[2015-11-03 13:55:52,601] INFO minSessionTimeout set to -1 (org.apache.zookeeper.server.quorum.QuorumPeer)
[2015-11-03 13:55:52,601] INFO maxSessionTimeout set to -1 (org.apache.zookeeper.server.quorum.QuorumPeer)
[2015-11-03 13:55:52,601] INFO initLimit set to 20 (org.apache.zookeeper.server.quorum.QuorumPeer)
[2015-11-03 13:55:52,626] INFO Reading snapshot /etc/zookeeper/data/version-2/snapshot.0 (org.apache.zookeeper.server.persistence.FileSnap)
[2015-11-03 13:55:52,675] INFO My election bind port: testkafka403.prod.local/127.0.1.1:3888 (org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2015-11-03 13:55:52,713] INFO LOOKING (org.apache.zookeeper.server.quorum.QuorumPeer)
[2015-11-03 13:55:52,715] INFO New election. My id =  4, proposed zxid=0x100000014 (org.apache.zookeeper.server.quorum.FastLeaderElection)
[2015-11-03 13:55:52,717] INFO Notification: 1 (message format version), 4 (n.leader), 0x100000014 (n.zxid), 0x1 (n.round), LOOKING (n.state), 4 (n.sid), 0x1 (n.peerEpoch) LOOKING (my state) (org.apache.zookeeper.server.quorum.FastLeaderElection)
[2015-11-03 13:55:52,732] WARN Cannot open channel to 5 at election address testkafka404.prod.local/10.1.132.153:3888 (org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.SocketTimeoutException
at java.net.SocksSocketImpl.remainingMillis(SocksSocketImpl.java:111)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:368)
at org.apache.zookeeper.server.quorum.QuorumCnxManager.toSend(QuorumCnxManager.java:341)
at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.process(FastLeaderElection.java:449)
at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.run(FastLeaderElection.java:430)
at java.lang.Thread.run(Thread.java:745)
[2015-11-03 13:55:52,737] WARN Cannot open channel to 6 at election address testkafka405.prod.local/10.1.132.154:3888 (org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:368)
at org.apache.zookeeper.server.quorum.QuorumCnxManager.toSend(QuorumCnxManager.java:341)
at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.process(FastLeaderElection.java:449)
at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.run(FastLeaderElection.java:430)
at java.lang.Thread.run(Thread.java:745)
[2015-11-03 13:55:52,919] WARN Cannot open channel to 6 at election address testkafka405.prod.local/10.1.132.154:3888 (org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:368)
at org.apache.zookeeper.server.quorum.QuorumCnxManager.connectAll(QuorumCnxManager.java:402)
at org.apache.zookeeper.server.quorum.FastLeaderElection.lookForLeader(FastLeaderElection.java:840)
at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:762)

Realmente nos gustaría poder utilizar nombres DNS, pero ya no tenemos idea de dónde deberíamos empezar a buscar una solución. ¿Quizás nos perdimos instalar o activar una característica importante de Debian o Java?

Respuesta1

Bien, entonces tengo una idea de lo que está pasando aquí. Vi el mismo problema al intentar configurar un clúster Spring-XD de 3 nodos en Vagrant, en máquinas virtuales Linux.

Esta configuración funcionó:

server.1=172.28.128.3:2888:3888
server.2=172.28.128.4:2888:3888
server.3=172.28.128.7:2888:3888

Pero este no lo hizo:

server.1=spring-xd-1:2888:3888
server.2=spring-xd-2:2888:3888
server.3=spring-xd-3:2888:3888

La "prueba irrefutable" fue esta línea en mi registro de cuidador del zoológico:

2015-11-26 20:48:31,439 [myid:1] - INFORMACIÓN [Thread-2:QuorumCnxManager$Listener@504] - Mi puerto de enlace de elección: spring-xd-1/127.0.0.1:3888

Entonces, ¿por qué Zookeeper vinculaba el puerto de elección en la interfaz loopback? Bien...

Mi /etc/hostsen una de las máquinas virtuales se veía así:

127.0.0.1   spring-xd-1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

## vagrant-hostmanager-start
172.28.128.3    spring-xd-1
172.28.128.4    spring-xd-2
172.28.128.7    spring-xd-3
## vagrant-hostmanager-end

Eliminé el nombre de host de la 127.0.0.1línea /etc/hostsy reboté el servicio de cuidador del zoológico en los 3 nodos, y¡BAM!Todo salió color de rosa. Entonces, ahora el archivo host en cada máquina se ve así:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

## vagrant-hostmanager-start
172.28.128.3    spring-xd-1
172.28.128.4    spring-xd-2
172.28.128.7    spring-xd-3
## vagrant-hostmanager-end

Supongo que no vio el problema en Windows porque el archivo de hosts ( C:\Windows\System32\drivers\etc\hosts) no tiene entradas de forma predeterminada. Debería poder reproducir el problema en Windows agregándole una 127.0.0.1línea similar.

A esto lo llamo un error de Zookeeper. Editar el archivo de hosts fue lo suficientemente bueno como para demostrar el problema y solucionarlo en Vagrant, pero no lo recomendaría para ningún entorno "real".

EDITAR:De acuerdo ahttp://ccl.cse.nd.edu/operaciones/condor/hostname.shtml, este parece ser un problema bastante común con las aplicaciones agrupadas en Linux y recomienda editar el archivo de hosts como lo describí anteriormente. sin embargo, elDocumentación de Zookeeper sobre la configuración del clústerno lo menciona.

Respuesta2

Probablemente este problema se haya causado al configurar el nodo hostnameen 127.0.0.1. /etc/hostsEn este caso ZK se vinculará leader|election portsa 127.0.0.1la dirección.

El parámetro de configuración quorumListenOnAllIPs=truedebería solucionar este problema y vincularse election|leader portsa 0.0.0.0.

Más opciones y su impacto se pueden encontrar enguía de administración de ZK

Siempre es bueno comprobarcódigo fuente.

información relacionada