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?