Não é possível montar o sistema de arquivos gfs2 no Debian Stretch, provavelmente dlm mis-config?

1

Estou experimentando o gfs2 no Debian Stretch e tendo algumas dificuldades. Eu sou um administrador do Linux razoavelmente experiente, mas novo no disco compartilhado e sistemas de arquivos paralelos.

Meu projeto imediato é montar um dispositivo exportado por iscsi formatado em gfs2 em vários clientes como um sistema de arquivos compartilhado. No momento, não estou interessado em HA ou esgrima, embora isso possa ser importante mais tarde.

A parte iscsi é boa, consigo fazer login no destino, formatá-lo como um sistema de arquivos xfs e também montá-lo em vários clientes e verificar se ele aparece com o mesmo blkid.

Para fazer o negócio gfs2, eu estou seguindo o esquema na página man do Debian "gfs2", modificado para minha configuração, e embelezado levemente por várias pesquisas e assim por diante.

A página do homem está aqui: link

O erro real é, quando tento montar meu sistema de arquivos gfs2, o comando mount retorna com

mount: mount(2) failed: /mnt: No such file or directory

... onde / mnt é o ponto de montagem desejado, o que certamente existir. (Se você tentar montar em um ponto de montagem inexistente erro é "montagem: ponto de montagem / errado não existe").

Relacionado, a cada tentativa de montagem, o dmesg reporta:

gfs2: can't find protocol lock_dlm

Eu rapidamente segui o caminho de assumir que o problema era que os pacotes Debian não forneciam "/sbin/mount.gfs2", e olhei para isso, mas acho que foi um palpite incorreto.

Eu tenho um cluster de cinco máquinas (de Raspberry Pis, no caso de ser importante), chamado, um tanto idiossincraticamente, pio, pi, pj, pk e pl. Todos eles têm endereços IP estáticos fixos e não há domínio.

Eu instalei os pacotes Debian gfs2, corosync e dlm-controld.

Para a etapa de corosync, minha configuração de corosync é (por exemplo, para pio, destinada a ser o mestre do cluster):

totem {
      version: 2
      cluster_name: rpitest
      token: 3000
      token_retransmits_before_loss_const: 10
      clear_node_high_bit: yes
      crypto_cipher: none
      crypto_hash: none
      nodeid: 17
      interface {
              ringnumber: 0
              bindnetaddr: 192.168.0.17
              mcastport: 5405
              ttl: 1
      }
}
nodelist { 
      node {
              ring0_addr: 192.168.0.17
              nodeid: 17
      }
      node {
              ring0_addr: 192.168.0.11
              nodeid: 1
      }
      node {
              ring0_addr: 192.168.0.12
              nodeid: 2
      }
      node {
              ring0_addr: 192.168.0.13
              nodeid: 3
      }
      node {
              ring0_addr: 192.168.0.14
              nodeid: 4
      }
}
logging {
      fileline: off
      to_stderr: no
      to_logfile: no
      to_syslog: yes
      syslog_facility: daemon
      debug: off
      timestamp: on
      logger_subsys {
              subsys: QUORUM
              debug: off
      }
}
quorum {
      provider: corosync_votequorum
      expected_votes: 5
}

Este arquivo está presente em todos os nós, com alterações específicas de nós apropriadas para os campos nodeid e bindnetaddr na seção totem.

A ferramenta corosync inicia sem erro em todos os nós e todos os Os nós também têm uma saída aparentemente sã do corosync-quorumtool, portanto:

root@pio:~# corosync-quorumtool 
Quorum information
------------------
Date:             Sun Apr 22 11:04:13 2018
Quorum provider:  corosync_votequorum
Nodes:            5
Node ID:          17
Ring ID:          1/124
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3  
Flags:            Quorate 

Membership information
----------------------
Nodeid      Votes Name
         1          1 192.168.0.11
         2          1 192.168.0.12
         3          1 192.168.0.13
         4          1 192.168.0.14
        17          1 192.168.0.17 (local)

O pacote dlm-controld foi instalado e /etc/dlm/dlm.conf criado com a seguinte configuração simples. Mais uma vez, estou pulando a esgrima por enquanto.

O arquivo dlm.conf é o mesmo em todos os nós.

enable_fencing=0

lockspace rpitest nodir=1
master rpitest node=17

Não estou certo se o nome "lockspace" do DLM deve corresponder ou não ao nome do cluster do corosync. Eu vejo o mesmo comportamento de qualquer maneira.

O serviço dlm-controld começa sem erros, e a saída de "dlm_tool status" aparece de forma sã:

root@pio:~# dlm_tool status
cluster nodeid 17 quorate 1 ring seq 124 124
daemon now 1367 fence_pid 0 
node 1 M add 31 rem 0 fail 0 fence 0 at 0 0
node 2 M add 31 rem 0 fail 0 fence 0 at 0 0
node 3 M add 31 rem 0 fail 0 fence 0 at 0 0
node 4 M add 31 rem 0 fail 0 fence 0 at 0 0
node 17 M add 7 rem 0 fail 0 fence 0 at 0 0

O sistema de arquivos gfs2 foi criado por:

mkfs -t gfs2 -p lock_dlm -j 5 -t rpitest:one /path/to/device

Em seguida, os relatórios "blkid / path / to / device":

/path/to/device: LABEL="rpitest:one" UUID=<stuff> TYPE="gfs2"

Parece o mesmo em todos os clientes iscsi.

Neste ponto, eu sinto que eu deveria ser capaz de montar o sistema de arquivos gfs2 em qualquer / todos os clientes, mas aqui é onde eu recebo o erro acima - o comando mount reporta um "nenhum arquivo ou diretório ", e o relatório dmesg e syslog" gfs2: não consegue encontrar o protocolo lock_dlm ".

Existem vários outros guias gfs2 por aí, mas muitos deles parecem ser específicos para RH / CentOS, e para outros esquemas de gerenciamento de clusters, além de corosync, como cman ou marca-passo. Esses não são necessariamente deal-breakers, mas é de grande valor para mim ter esse trabalho no Debian Stretch quase disponível.

Também parece provável que isso seja, provavelmente, um erro de configuração dlm bem simples, mas não consigo encontrar.

Dicas adicionais: quando tento "unir" um espaço de bloqueio via

dlm_tool join <name>

... Eu recebo uma saída do dmesg:

dlm cluster name 'rpitest' is being used without an application provided cluster name

Isso acontece independentemente de o espaço de bloqueio em que estou ingressando é "rpitest" ou não. Isso sugere que os nomes de clusters e os nomes de clusters são de fato a mesma coisa e / mas que o dlm evidentemente não está ciente da configuração do corosync?

    
por Andrew Reid 22.04.2018 / 18:44

1 resposta

1

Na documentação do Kconfig de config GFS2_FS_LOCKING_DLM :

Most users of GFS2 will require this. It provides the locking interface between GFS2 and the DLM, which is required to use GFS2 in a cluster environment.

Portanto, certifique-se de ativá-lo, caso contrário, os sistemas de arquivos criados com -p lock_dlm (o protocolo de bloqueio padrão em gfs2_mkfs ) não poderão ser usados (sem uma substituição de tempo de montagem). E o protocolo lock_nolock lock funciona apenas com montagens de nó único.

    
por 24.04.2018 / 08:09