TL; DR
Falha em um nó em um cluster ctdb + samba ao interagir com um compartilhamento interrompe a conexão compartilhada.
-
aqui e aqui declara que há trabalho em andamento para tornar isso possível
-
aqui afirma que já é possível com o Samba 3.0 (atualmente usando 4.7)
Minha configuração
3 nós executando o ceph + cephfs
2 desses nós executando o CTDB & Samba
1 cliente (não é um dos 3 servidores)
É uma configuração do Laboratório, portanto, apenas um nic por servidor = nó, uma sub-rede e todos os componentes do Ceph mais o Samba nos mesmos servidores. Estou ciente de que este não é o caminho a seguir.
O problema
Eu quero hospedar um compartilhamento de arquivo Samba em cluster na parte superior do Ceph com ctdb. Eu segui a documentação do CTDB ( link ) e partes disso: link .
O cluster está rodando e um compartilhamento é acessível, legível e gravável em ambos os nós, meu smb.conf tem a seguinte aparência:
[global]
netbios name = CEPHFS
workgroup = SIMPLE
clustering = yes
idmap config * : backend = autorid
idmap config * : range = 1000000-1999999
log file = /var/log/samba/smb.log
# Set files creation permissions
create mask = 664
force create mode = 664
# Set directory creation mask
directory mask = 2775
force directory mode = 2775
[public]
comment = public share
path = /mnt/mycephfs/testshare
public = yes
writeable = yes
only guest = yes
ea support = yes
O CTDB gerencia o Samba e relata os dois nós como OK.
Mas quando eu leio ou escrevo para um dos nós através do IP público e deixo ele falhar (reiniciando o ctdb), a leitura ou gravação falha. Uma segunda tentativa de gravação é bem-sucedida (o IP público é recebido pelo outro host com êxito).
Mas o CTDB deve poder fazer isso de acordo com o link - > IP Takeover?
Eu tenho um tcpdump do novo servidor (aquele assumindo o ip público) enviando um tcp RST para meu cliente após o cliente enviar retransmissões para o servidor.
Alguma ideia, qual poderia ser o problema?
PS: Estou mais do que feliz em lhe fornecer mais informações (arquivo de configuração ctdb, configuração de firewall, pcap, qualquer que seja;)), mas isso é tempo suficiente ....
Editar:
Testado também com o GlusterFS como back-end de armazenamento em um ambiente virtualizado e um cliente Windows 10. Precisava de um kernel share modes = No , usando o glosa vfs.