O failover do NFS falha com identificadores de arquivos antigos durante a migração de recursos

Question

Correndo em um pequeno problema aqui, eu configurei dois servidores (Centos 6) com o Glusterfs e um diretório compartilhado entre eles, eu mudei o diretório nfs para a pasta compartilhada do Gluster e criei um symlink em ambas as caixas. As máquinas podem se comunicar por meio de nomes de host e a replicação do Gluster é manipulada por meio de outra placa ethernet entre os servidores.

O problema que estou tendo, é que mesmo que os recursos executem failover corretamente (embora pareça vir para cima e para baixo algumas vezes durante o failover), recebo handles nfs obsoletos no cliente. Abaixo está minha configuração crm; O que estou fazendo de errado?

A montagem nfs no cliente é o mais simples possível.

node GlusterFS01 
node GlusterFS02 
primitive ClusterIP ocf:heartbeat:IPaddr2 \ 
        params ip="10.10.10.167" cidr_netmask="24" clusterip_hash="sourceip" \ 
        op monitor interval="5s" 
primitive exportfs ocf:heartbeat:exportfs \ 
        params fsid="0" directory="/GlusterFS/Files" \
        options="rw,sync,no_subtree_check,no_root_squash" \ 
        clientspec="10.10.10.0/24" \        
        wait_for_leasetime_on_stop="false" \ 
        op monitor interval="5s" \ 
        op start interval="0s" timeout="240s" \ 
        op stop interval="0s" timeout="100s" \ 
        meta is-managed="true" target-role="Started" 
primitive nfs lsb:nfs \ 
        meta target-role="Started" \ 
        op monitor interval="5s" timeout="5s" 
colocation sitewithnfs inf: ClusterIP exportfs nfs 
order nfsorder inf: exportfs ClusterIP nfs 
property $id="cib-bootstrap-options" \ 
        dc-version="1.1.10-14.el6_5.2-368c726" \ 
        cluster-infrastructure="classic openais (with plugin)" \ 
        expected-quorum-votes="2" \ 
        stonith-enabled="false" \ 
        no-quorum-policy="ignore" \ 
last-lrm-refresh="1395246465" \ 
        default-resource-stickiness="100" 
rsc_defaults $id="rsc-options" \ 
        resource-stickiness="100" 

Obrigado pelo seu tempo.

Update1: Eu decidi que estava supercomplicando tudo. Depois de uma ligação com Florian, ele me convenceu a simplificar. Estou compartilhando o nfs diretamente do Gluster, e só tenho o recurso ip sendo manipulado pelo corosync / pacemaker. Solução muito mais simples e adapta-se às minhas necessidades.

No entanto, vou dizer que Dok estava completamente correto em sua avaliação e sugestões, mesmo que eu não tenha conseguido colocá-lo em funcionamento 100% no ambiente de produção (até o pensamento é trabalhado nos testes).

    

Answer 1

colocation sitewithnfs inf: ClusterIP exportfs nfs

order nfsorder inf: exportfs ClusterIP nfs

Primeiramente, acredito que você queira iniciar o nfsd antes da exportação.

Adicionar o parâmetro unlock_on_stop="true" ao agente de recursos exportfs também pode ajudar, mas o que realmente fez a diferença em meus testes foi parar o IP virtual primeiro durante os failovers. Eu não tenho certeza do porquê, mas suspeito que isso tenha a ver com o fechamento das conexões antes de tentar parar as exportações.

Além disso, lembro-me de haver problemas com "conjuntos de recursos" (ou seja, restrições de ordenação e de colocação com mais de dois recursos) em versões mais antigas do marca-passo. Em vez disso, sugiro remover suas restrições de ordenação e de colocalização e substituí-las por um único grupo de recursos da seguinte forma:

group g_nfs nfs exportfs ClusterIP

P.S. O agente de recursos exportfs deve manipular todas as exportações. Seu arquivo / etc / exports deve estar vazio.