GlusterFS falha ao montar na inicialização com o Ubuntu 14.04

Question

Anteriormente eu perguntei sobre a montagem do GlusterFS na inicialização em um servidor Ubuntu 12.04 e a resposta foi que isso foi buggy em 12.04 e trabalhou em 14.04. Curioso eu tentei em uma máquina virtual em execução no meu laptop e em 14.04 funcionou. Como isso era crítico para mim, decidi atualizar meus servidores em execução para o 14.04 apenas para descobrir que o GlusterFS não está montando automaticamente os volumes do host local.

Este é um servidor Linode e o fstab tem esta aparência:

# <file system> <mount point>          <type>    <options>                 <dump>  <pass>
proc        /proc                        proc    defaults                       0       0
/dev/xvda   /                            ext4    noatime,errors=remount-ro      0       1
/dev/xvdb   none                         swap    sw                             0       0
/dev/xvdc   /var/lib/glusterfs/brick01   ext4    defaults                       1       2
koraga.int.example.com:/public_uploads /var/www/shared/public/uploads glusterfs defaults,_netdev 0 0

O processo de inicialização é semelhante a esse (em torno da parte de montagem da rede, que é a única falha):

 * Stopping Mount network filesystems                                    [ OK ]
 * Starting set sysctls from /etc/sysctl.conf                            [ OK ]
 * Stopping set sysctls from /etc/sysctl.conf                            [ OK ]
 * Starting configure virtual network devices                            [ OK ]
 * Starting Bridge socket events into upstart                            [ OK ]
 * Starting Waiting for state                                            [fail]
 * Stopping Waiting for state                                            [ OK ]
 * Starting Block the mounting event for glusterfs filesystems until the [fail]k interfaces are running
 * Starting Waiting for state                                            [fail]
 * Starting Block the mounting event for glusterfs filesystems until the [fail]k interfaces are running
 * Stopping Waiting for state                                            [ OK ]
 * Starting Signal sysvinit that remote filesystems are mounted          [ OK ]
 * Starting GNU Screen Cleanup                                           [ OK ]

Acredito que o arquivo de log /var/log/glusterfs/var-www-shared-public-uploads.log contenha a principal pista para o problema, pois é o único que é realmente diferente entre esse servidor, onde a montagem não está funcionando, e meu servidor virtual local, onde está:

[2014-07-10 05:51:49.762162] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.1 (/usr/sbin/glusterfs --volfile-server=koraga.int.example.com --volfile-id=/public_uploads /var/www/shared/public/uploads)
[2014-07-10 05:51:49.774248] I [socket.c:3561:socket_init] 0-glusterfs: SSL support is NOT enabled
[2014-07-10 05:51:49.774278] I [socket.c:3576:socket_init] 0-glusterfs: using system polling thread
[2014-07-10 05:51:49.775573] E [socket.c:2161:socket_connect_finish] 0-glusterfs: connection to 192.168.134.227:24007 failed (Connection refused)
[2014-07-10 05:51:49.775634] E [glusterfsd-mgmt.c:1601:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to connect with remote-host: koraga.int.example.com (No data available)
[2014-07-10 05:51:49.775649] I [glusterfsd-mgmt.c:1607:mgmt_rpc_notify] 0-glusterfsd-mgmt: Exhausted all volfile servers
[2014-07-10 05:51:49.776284] W [glusterfsd.c:1095:cleanup_and_exit] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_transport_notify+0x23) [0x7f6718bf3f83] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_clnt_notify+0x90) [0x7f6718bf7da0] (-->/usr/sbin/glusterfs(+0xcf13) [0x7f67192bbf13]))) 0-: received signum (1), shutting down
[2014-07-10 05:51:49.776314] I [fuse-bridge.c:5475:fini] 0-fuse: Unmounting '/var/www/shared/public/uploads'.

O status do volume é:

Volume Name: public_uploads
Type: Distribute
Volume ID: 52aa6d85-f4ea-4c39-a2b3-d20d34ab5916
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: koraga.int.example.com:/var/lib/glusterfs/brick01/public_uploads
Options Reconfigured:
auth.allow: 127.0.0.1,192.168.134.227
client.ssl: off
server.ssl: off
nfs.disable: on

Se eu executar mount -a após a inicialização, o volume será montado corretamente:

koraga.int.example.com:/public_uploads on /var/www/shared/public/uploads type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)

Alguns arquivos de log relacionados mostram isso:

/var/log/upstart/mounting-glusterfs-_var_www_shared_public_uploads.log :

start: Job failed to start

/var/log/upstart/wait-for-state-mounting-glusterfs-_var_www_shared_public_uploadsstatic-network-up.log :

status: Unknown job: static-network-up
start: Unknown job: static-network-up

mas no meu servidor de testes, ele mostra exatamente o mesmo, então, não acho que isso seja relevante.

Alguma idéia do que está errado agora?

Atualização : Eu tentei a mudança de WAIT_FOR de rede estática para rede e ainda não funcionou, mas todas as mensagens [de falha] na inicialização desapareceram. Estes são os contidos dos arquivos de log sob estas condições:

/var/log/glusterfs/var-www-shared-public-uploads.log contém:

wait-for-state stop/waiting

/var/log/upstart/wait-for-state-mounting-glusterfs-_var_www_shared_public_uploadsstatic-network-up.log contém:

start: Job is already running: networking

/var/log/glusterfs/var-www-shared-public-uploads.log contém:

[2014-07-11 17:19:38.000207] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.1 (/usr/sbin/glusterfs --volfile-server=koraga.int.example.com --volfile-id=/public_uploads /var/www/shared/public/uploads)
[2014-07-11 17:19:38.029421] I [socket.c:3561:socket_init] 0-glusterfs: SSL support is NOT enabled
[2014-07-11 17:19:38.029450] I [socket.c:3576:socket_init] 0-glusterfs: using system polling thread
[2014-07-11 17:19:38.030288] E [socket.c:2161:socket_connect_finish] 0-glusterfs: connection to 192.168.134.227:24007 failed (Connection refused)
[2014-07-11 17:19:38.030331] E [glusterfsd-mgmt.c:1601:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to connect with remote-host: koraga.int.example.com (No data available)
[2014-07-11 17:19:38.030345] I [glusterfsd-mgmt.c:1607:mgmt_rpc_notify] 0-glusterfsd-mgmt: Exhausted all volfile servers
[2014-07-11 17:19:38.030984] W [glusterfsd.c:1095:cleanup_and_exit] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_transport_notify+0x23) [0x7fd9495b7f83] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_clnt_notify+0x90) [0x7fd9495bbda0] (-->/usr/sbin/glusterfs(+0xcf13) [0x7fd949c7ff13]))) 0-: received signum (1), shutting down
[2014-07-11 17:19:38.031013] I [fuse-bridge.c:5475:fini] 0-fuse: Unmounting '/var/www/shared/public/uploads'.

Atualização 2 : eu também tentei isso no arquivo inicial:

start on (started glusterfs-server and mounting TYPE=glusterfs)

mas o computador não conseguiu inicializar (não sei por que ainda).

    

Answer 1

Consegui fazer isso funcionar através de uma combinação de respostas neste segmento e neste: GlusterFS está falhando ao montar na inicialização

Como por @Dan Pisarski edite /etc/init/mounting-glusterfs.conf para ler:

exec start wait-for-state WAIT_FOR=networking WAITER=mounting-glusterfs-$MOUNTPOINT

Como por @ dialt0ne altere /etc/fstab para ler:

[serverip]:[vol]  [mountpoint]  glusterfs  defaults,nobootwait,_netdev,backupvolfile-server=[backupserverip],direct-io-mode=disable  0       0

Works For Me (tm) no Ubuntu 14.04.2 LTS

    

Answer 2

Eu tive o mesmo problema na AWS no Ubuntu 12.04. Aqui estão algumas coisas que você pode fazer para mim:

• adicione mais tentativas de busca em seu fstab

Isso permitirá que você tente novamente o servidor volfile enquanto a rede estiver indisponível.

• adicione um servidor volfile de backup em seu fstab

Isso permitirá que você monte o sistema de arquivos a partir de outro membro do servidor gluster se o principal estiver inativo por algum motivo.

• adicione nobootwait no seu fstab

Isso permite que a instância continue inicializando enquanto este sistema de arquivos não estiver montado.

Uma entrada de amostra do meu fstab atual é:

10.20.30.40:/fs1 /example glusterfs defaults,nobootwait,_netdev,backupvolfile-server=10.20.30.41,fetch-attempts=10 0 2

Eu não testei isso em 14.04, mas funciona bem para minhas 12.04 instâncias.

    

Answer 3

É um bug

Este é realmente um bug (a rede estática não é um trabalho, é um sinal de evento).

Além disso, usar o trabalho de rede como sugerido em outras respostas não é a solução mais correta.

Então, criei este relatório de erros e enviei um patch para este problema.

Como solução alternativa, você pode aplicar a minha solução proposta (no final desta resposta) e usar a opção _netdev no seu fstab.

Uma explicação melhor é mostrada acima também, mas você pode pular esta explicação se quiser.

Explicação

Este é um bug no mounting-glusterfs.conf . Pode aumentar desnecessariamente 30 segundos na inicialização em um servidor Ubuntu, ou até mesmo travar o processo de inicialização.

Devido a esse bug, o processo mountall acha que a montagem falhou (você verá erros de "Falha na montagem" em /var/log/boot.log ). Portanto, quando não estiver usando os sinalizadores nobootwait / nofail em /etc/fstab , o bug pode travar o processo de montagem (e o processo de inicialização também). Ao usar os sinalizadores nobootwait / nofail , o bug aumentará o tempo de inicialização em aproximadamente 30 segundos.

O erro é causado pelos seguintes erros:

• Não há necessidade de esperar que a rede esteja ativa. O próprio Ubuntu tem o sinalizador _netdev mount que repetirá a montagem para cada vez que uma interface for ativada;
• No entanto, é necessário aguardar o daemon GlusterFS Server (para montagens usando localhost);
  • Isso foi implementado em um commit antigo no upstream do GlusterFS projeto. No entanto, esse commit foi sobrescrito;
• Está errado usar a tarefa upstart wait-for-state para aguardar um sinal. Está acostumado a esperar por um trabalho. static-network-up é um sinal de evento e não um trabalho;
  • É por isso que o "trabalho desconhecido: rede estática" é registrado;
• Está errado, ao esperar que um trabalho seja iniciado, não passando o WAIT_STATE=running env var porque não é o padrão em wait-for-state .

Solução

/etc/init/mounting-glusterfs.conf :

author "Louis Zuckerman <[email protected]>"
description "Block the mounting event for glusterfs filesystems until the glusterfs-server is running"

instance $MOUNTPOINT

start on mounting TYPE=glusterfs
task
script
  if status glusterfs-server; then
    start wait-for-state WAIT_FOR=glusterfs-server WAIT_STATE=running \
        WAITER=mounting-glusterfs-$MOUNTPOINT
  fi
end script

PS: Use também a opção _netdev no seu fstab.

    

Answer 4

Eu me deparei com isso também, e quero começar essa resposta com a afirmação de que eu não sou um especialista nessa área, então é possível que haja uma solução melhor para isso!

Mas o problema parece ser que rede estática é um evento, não o nome de um trabalho iniciante. No entanto, o script wait-for-state espera que um nome de job seja passado como valor WAIT_FOR. Assim, o erro de "trabalho desconhecido" como você descobriu acima.

Para resolver o problema, alterei o /etc/init/mounting-glusterfs.conf, alterando:

exec start wait-for-state WAIT_FOR=static-network-up WAITER=mounting-glusterfs-$MOUNTPOINT

para:

exec start wait-for-state WAIT_FOR=networking WAITER=mounting-glusterfs-$MOUNTPOINT

networking é o nome de um job atual (/etc/init/networking.conf) e acredito no trabalho que tipicamente emite rede estática.

Essa mudança funcionou para mim no Ubuntu 14.04.

    

Answer 5

Obrigado pela explicação detalhada, acho que entendo muito mais do que antes. A última solução está quase funcionando. Os problemas (na verdade, um, desde o primeiro implica o segundo):

• compartilhamentos locais ( 127.0.0.1:/share ) ainda não montados
• mounted TYPE=glusterfs nunca satisfeito, portanto, os serviços que dependem do estado TYPE=glusterfs montado

/etc/fstab :

127.0.0.1:/control-share /mnt/glu-control-share glusterfs defaults,_netdev 0 0

/etc/init/mounting-glusterfs.conf : copiado de cima

/etc/init/salt-master.conf :

description "Salt Master"

start on (mounted TYPE=glusterfs
          and runlevel [2345])
stop on runlevel [!2345]
limit nofile 100000 100000
...

O compartilhamento local deve ser montado manualmente, ou por algum automatismo, o mestre de sal deve ser iniciado manualmente após todas as reinicializações.

Notado depois: o script WAIT acima em mounting-glusterfs ... bloqueia todo o procedimento de inicialização, parece que o estado do servidor glusterfs nunca chega a ser executado.

    

Answer 6

Gerenciei isso com uma solução muito simples:

1. adicione o ponto de montagem ao / etc / fstab

   gluster:/VOLUME_NAME/local/mount/point glusterfs defaults,_netdev 0 0
   

2. adicione uma linha ao seu /etc/rc.local , assim será:

   mount -a
   exit 0
   

Agora, todos os volumes glusterfs seriam montados em uma inicialização.