Problemas de nomes DNS do Zookeeper com eleições de líderes ao migrar do Windows para o Debian

Question 1

Ok, então tenho uma ideia do que está acontecendo aqui. Vi o mesmo problema ao tentar configurar um cluster Spring-XD de 3 nós no Vagrant, em VMs Linux.

Esta configuração funcionou:

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

Mas este não:

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

A "arma fumegante" era esta linha no meu registro do zookeeper:

26/11/2015 20:48:31,439 [myid:1] - INFO [Thread-2:QuorumCnxManager$Listener@504] - Minha porta de ligação eleitoral: spring-xd-1/127.0.0.1:3888

Então, por que o Zookeeper estava vinculando a porta eleitoral na interface de loopback? Bem...

Meu /etc/hostsem uma das VMs ficou assim:

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

Eu removi o nome do host da 127.0.0.1entrada /etc/hostse devolvi o serviço zookeeper em todos os 3 nós, eBAM!tudo surgiu rosas. Então, agora o arquivo host em cada máquina fica assim:

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

Suponho que você não viu o problema no Windows porque o arquivo hosts ( C:\Windows\System32\drivers\etc\hosts) não possui entradas por padrão. Você deve conseguir reproduzir o problema no Windows adicionando uma 127.0.0.1linha semelhante a ele.

~~Estou chamando isso de bug do Zookeeper. Editar o arquivo hosts foi bom o suficiente para provar o problema e corrigi-lo no Vagrant, mas eu não recomendaria isso para nenhum ambiente "real".~~

EDITAR:De acordo comhttp://ccl.cse.nd.edu/operações/condor/hostname.shtml, este parece ser um problema bastante comum com aplicativos em cluster no Linux e recomenda a edição do arquivo hosts conforme descrevi acima. No entanto, oDocumentação do Zookeeper sobre configuração de clusternão menciona isso.

Answer

Ok, então tenho uma ideia do que está acontecendo aqui. Vi o mesmo problema ao tentar configurar um cluster Spring-XD de 3 nós no Vagrant, em VMs Linux.

Esta configuração funcionou:

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

Mas este não:

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

A "arma fumegante" era esta linha no meu registro do zookeeper:

26/11/2015 20:48:31,439 [myid:1] - INFO [Thread-2:QuorumCnxManager$Listener@504] - Minha porta de ligação eleitoral: spring-xd-1/127.0.0.1:3888

Então, por que o Zookeeper estava vinculando a porta eleitoral na interface de loopback? Bem...

Meu /etc/hostsem uma das VMs ficou assim:

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

Eu removi o nome do host da 127.0.0.1entrada /etc/hostse devolvi o serviço zookeeper em todos os 3 nós, eBAM!tudo surgiu rosas. Então, agora o arquivo host em cada máquina fica assim:

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

Suponho que você não viu o problema no Windows porque o arquivo hosts ( C:\Windows\System32\drivers\etc\hosts) não possui entradas por padrão. Você deve conseguir reproduzir o problema no Windows adicionando uma 127.0.0.1linha semelhante a ele.

~~Estou chamando isso de bug do Zookeeper. Editar o arquivo hosts foi bom o suficiente para provar o problema e corrigi-lo no Vagrant, mas eu não recomendaria isso para nenhum ambiente "real".~~

EDITAR:De acordo comhttp://ccl.cse.nd.edu/operações/condor/hostname.shtml, este parece ser um problema bastante comum com aplicativos em cluster no Linux e recomenda a edição do arquivo hosts conforme descrevi acima. No entanto, oDocumentação do Zookeeper sobre configuração de clusternão menciona isso.

Question 2

Provavelmente esse problema foi causado pela configuração do nó hostnamecomo 127.0.0.1in /etc/hosts. Neste caso, ZK será vinculado leader|election portsao 127.0.0.1endereço.

O parâmetro de configuração quorumListenOnAllIPs=truedeve solucionar esse problema e vincular-se election|leader portsao 0.0.0.0.

Mais opções e seu impacto podem ser encontradas emGuia de administração ZK

É sempre bom verificarCódigo fonte.

Answer

Provavelmente esse problema foi causado pela configuração do nó hostnamecomo 127.0.0.1in /etc/hosts. Neste caso, ZK será vinculado leader|election portsao 127.0.0.1endereço.

O parâmetro de configuração quorumListenOnAllIPs=truedeve solucionar esse problema e vincular-se election|leader portsao 0.0.0.0.

Mais opções e seu impacto podem ser encontradas emGuia de administração ZK

É sempre bom verificarCódigo fonte.

Problemas de nomes DNS do Zookeeper com eleições de líderes ao migrar do Windows para o Debian

Responder1

Responder2

informação relacionada