O que faria com que as operações de movimentação / exclusão de arquivos do NFS falhassem?

Question

Desculpe pela pergunta terrivelmente vaga.

Eu tenho um servidor de médio a grande porte no qual todos os meus usuários de engenharia estão conectados. Este é um sistema de 256GB de 32 núcleos que hospeda 19 sessões de Xvnc, além da infinidade de ferramentas, sessões de login e de tal forma implícitas por essa base de usuários. Todos os usuários são configurados via NIS e possuem diretórios pessoais no NFS. Vários processos automatizados também estão usando usuários definidos pelo NIS e sistemas de arquivos montados pelo NFS.

O computador em questão está rodando o CentOS 6.5, e o servidor de arquivos envolvido é um NetApp.

Ocasionalmente, depois que o computador está funcionando há algum tempo, as pessoas ficam com problemas intermitentes ao excluir algo; o erro é ao longo das linhas de "dispositivo / recurso ocupado". lsof não revela nada no item (arquivo ou diretório) em questão; depois de algum tempo indeterminado (geralmente menos do que o necessário para encontrar um administrador e fazer com que ele examine o problema), o problema desaparece e o item pode ser excluído.

Por volta da mesma época, um dos processos automatizados que usam o SVN obtém erros como este:

svn: E155009: Failed to run the WC DB work queue associated with '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images', work item 930 (file-install doc/verif/verification_environment/learning/images/my-sequence.uml 1 0 1 1)
svn: E000018: Can't move '/home/local-user/tartarus/project8/.svn/tmp/svn-j3XrNq' to '/home/local-user/tartarus/project8/doc/verif/verification_environment/learning/images/my-sequence.uml': Invalid cross-device link

Se tentarmos remover o arquivo incorreto, obteremos:

rm: cannot remove 'project8/doc/verif/verification_environment/learning': Device or resource busy

Pesquisando o "link inválido entre dispositivos" leva a muita discussão sobre versões svn e não suporta gravações em dispositivos diferentes, o que é irrelevante para nós, pois isso geralmente funciona e não estamos executando repositórios svn de versão cruzada. Ou repositórios entre dispositivos, uma vez que o diretório .svn está no mesmo dispositivo (nfs-mounted) de onde a cópia de trabalho está.

A reinicialização do computador faz com que o problema desapareça por semanas ou meses - no meu caso atual, o computador acabou de completar 185 dias de tempo de atividade. Mas os engenheiros não estão dispostos a reiniciar seu mundo com mais frequência do que o necessário.

Nós excluímos o servidor de arquivos como uma causa, pois outros computadores não têm o mesmo problema, a menos que o problema esteja sendo manifestado no sistema principal. Ou seja, podemos duplicar o fato de que os arquivos não podem ser movidos / renomeados se o sistema principal não puder movê-los / renomeá-los, no entanto, outros computadores nunca manifestam independentemente esse comportamento.

As opções de montagem para os sistemas de arquivos NFS são: rw,intr,sloppy,addr=10.17.0.199

Eu acho que isso tem que ser um valor do kernel em algum lugar que está sendo preenchido, seja como um efeito colateral de alguma coisa que os engenheiros estão rodando ou como um estouro devido a uma carga temporária.

Não são arquivos totais abertos, porque esse limite é de 25 milhões de arquivos e esse computador está chegando a 200 mil arquivos.

Alguém sabe para o que eu deveria estar olhando?

    

Answer 1

Resposta curta: Seu NFS local não acredita que um arquivo ou diretório esteja lá. (sim, você meio que suspeitou disso)

O NFS é uma tecnologia antiga. Não foi feito para arquivos de alto acesso, que mudam rapidamente. Para sistemas dinâmicos de arquivos compartilhados, tente uma solução em cluster como OCFS2 (my fave) ou gluster (meh, Dark Side).

Vários anos atrás nós tínhamos 4 servidores montando um NFS comum e encontramos repetidamente que um servidor criaria um arquivo que os outros servidores não poderiam ver. Os 4 servidores eram servidores de aplicativos da web. Um usuário iniciaria uma ação para que um servidor criasse um pacote e atualizasse uma linha no banco de dados com o caminho NFS para o arquivo quando concluído. O navegador do usuário continuaria checando de volta a cada 10 segundos para ver se o trabalho estava pronto, e se era o download do arquivo. Você pode ver o problema chegando - o servidor atualizaria a linha no banco de dados que o arquivo estava lá, mas outro servidor obteria a solicitação do navegador do usuário - ele iria ler o arquivo e obter os erros "arquivo não encontrado".

Como você disse, no momento em que um administrador olhou para ele, o arquivo estava lá. Levamos semanas de vários de nós engenheiros cavando e cavando para encontrar o problema. Basicamente, executamos um loop de suspensão de 10 segundos que obteria o último caminho de arquivo criado, conforme indicado no banco de dados, e tentaria inserir o arquivo em um log. Consistentemente, o sistema que criou o arquivo pôde vê-lo, mas os outros não conseguiram por um determinado período de tempo. Esse intervalo de tempo foi maior à medida que a carga nos servidores aumentou.

Os chefes de cabelos pontudos não queriam mudar o NFS subjacente para um sistema de arquivos em cluster, então, em vez disso, nós também tínhamos o servidor de trabalho salvo que "ele" era o criador do arquivo no banco de dados. A solicitação do usuário continuaria tentando até que o trabalho fosse concluído e a solicitação chegasse ao servidor que criou o arquivo para que ele estivesse sempre lá para leitura. Sim, eu sei. Kludge. Mas isso é o que você obtém quando decide manter a tecnologia antiga - você tem que se mexer para fazer as coisas funcionarem. A tecnologia antiga é o primeiro kludge e tudo feito para trabalhar com ele é apenas mais kludge. Bem-vindo de volta aos anos 80 e ao FS Headroom da Max.

O NFS não mantém todos os clientes em sincronia com todas as alterações em tempo real. Assim, você constantemente se depara com condições em que um cliente cria um arquivo / diretório e outro não pode vê-lo, ou onde um cliente exclui um arquivo / diretório e outros clientes acham que ainda está lá (até tentar usá-lo - oops ).

Nós tentamos todos os tipos de truques para fazer com que os sistemas ressincronizassem o cache do cliente antes de tentar ler o arquivo. Não está acontecendo.

Minha recomendação: traga seu FS para este século. (experimente o capacitor de fluxo a 88 mph)

    

Answer 2

apenas uma observação:

o erro E155009 / E000018 também se aplica a movimentações locais entre dispositivos:

svn: E155009: Failed to run the WC DB work queue associated with '/first-device/mounted-device', work item 1219 (file-install /first-device/mounted-device/file-to-move-to 1 0 1 1)
svn: E000018: Can't move '/first-device/.svn/tmp/svn-v2KRIt' to '/first-device/mounted-device/file-to-move-to': Invalid cross-device link

Como tal, não é específico do NFS.