File Storage NAS:Solucionar problemas de acesso de leitura e gravação de arquivos

Servidor sem resposta durante acesso simultâneo a arquivos

Causa: Um bug no driver de kernel SMB do Linux causa esse problema. Ao montar um sistema de arquivos usando SMB 2,1 ou 3,0, os clientes podem falhar ao enviar os pacotes SMB BreakAck esperados em alguns cenários de acesso simultâneo, fazendo com que o servidor pare de responder por 35 segundos.

Solução 1: Monte o sistema de arquivos usando SMB 2,0.

Solução 2: Siga estas etapas.

1. Execute o seguinte comando para desativar oplocks ao carregar o módulo CIFS:

   # modprobe cifs enable_oplocks=0

2. Execute o seguinte comando para desativar oplocks após carregar o módulo CIFS:

   # echo 0 > /sys/module/cifs/parameters/enable_oplocks

3. Execute o seguinte comando para verificar o status dos oplocks:

   # cat /sys/module/cifs/parameters/enable_oplocks

   Na saída, Y indica ativado e N indica desativado.

   Nota

   • Para aplicar as alterações, desmonte e remonte o sistema de arquivos SMB.

   • Para tornar as alterações permanentes, crie o arquivo /etc/modprobe.d/cifs.conf e adicione a linha options cifs enable_oplocks=0.

Impossibilidade de criar links simbólicos

Causa

O sistema de arquivos SMB foi montado no Linux sem a opção mfsymlinks ou usando a versão de protocolo 2,0.

Solução

Ao montar um sistema de arquivos SMB no Linux, use a versão de protocolo 2,1 ou 3,0 e adicione a opção mfsymlinks. Veja abaixo um exemplo do comando de montagem. Para descrições dos parâmetros no exemplo, consulte Descrições de parâmetros do comando de montagem SMB (Linux).

sudo mount -t cifs //file-system-id.region.nas.aliyuncs.com/myshare /mnt -o vers=2.1,guest,uid=0,gid=0,dir_mode=0755,file_mode=0755,mfsymlinks,cache=strict,rsize=1048576,wsize=1048576

Ponto de montagem SMB sem resposta

Causa

Em distribuições Linux com kernel anterior a 3.10.0-514, o driver de kernel SMB pode falhar em cenários de acesso simultâneo, tornando o ponto de montagem inacessível. O log do kernel contém mensagens semelhantes às seguintes:

...
[<ffffffffc03c9bc1>] cifs_oplock_break+0x1f1/0x270 [cifs]
[<ffffffff810a881a>] process_one_work+0x17a/0x440
[<ffffffff810a8d74>] rescuer_thread+0x294/0x3c0
...

Solução

• Remonte o sistema de arquivos com a opção cache=none. Isso pode afetar o desempenho.

• Atualize o sistema operacional da instância ECS que executa Linux.

Erro "Bad file descriptor" ao copiar arquivos grandes

Causa

Esse problema ocorre devido a uma falha temporária de rede ou de backend. Os clientes SMB em algumas distribuições Linux, como SUSE, têm suporte limitado para esse tipo de failover.

Solução

A tabela a seguir lista as versões recomendadas de sistemas operacionais Linux para NAS SMB.

Caracteres chineses ilegíveis nos clientes

Sintoma

Ao gravar caracteres chineses (por exemplo, em nomes ou conteúdo de arquivos) de um cliente Linux para um sistema de arquivos NAS, eles podem aparecer ilegíveis em um cliente Windows, e vice-versa.

Causa

Por padrão, os clientes Windows usam o conjunto de caracteres GBK para codificação e decodificação de chinês, enquanto os clientes Linux usam o conjunto de caracteres UTF-8. Cada plataforma codifica dados usando seu próprio conjunto de caracteres. Quando uma plataforma lê dados gravados pela outra, a incompatibilidade entre os conjuntos de caracteres causa falha na decodificação e o conteúdo aparece ilegível.

Solução

Para evitar problemas de incompatibilidade entre plataformas, recomendamos montar sistemas de arquivos NAS via SMB em clientes Windows e via NFS em clientes Linux.

Operações de arquivo lentas no Windows com NFS

Causa

No Windows, o NFS apresenta problemas de compatibilidade entre semânticas sensíveis e insensíveis a maiúsculas e minúsculas. O desempenho da criação de arquivos em um diretório degrada significativamente à medida que o tamanho do diretório aumenta. Isso acontece porque o sistema precisa percorrer o diretório sempre que um arquivo é criado. Quando o diretório contém cerca de 100.000 entradas, uma única varredura pode levar mais de 10 segundos.

Solução

Modifique os parâmetros de montagem adicionando a opção -o casesensitive=yes para evitar a varredura do diretório. O comando a seguir fornece um exemplo:

mount -o nolock -o mtype=hard -o timeout=60 -o casesensitive=yes \\file-system-id.region.nas.aliyuncs.com\! Z:

Substitua a letra da unidade Z: e o endereço do ponto de montagem file-system-id.region.nas.aliyuncs.com de acordo com seu ambiente.

Como resolver o erro invalid device ao renomear um arquivo em um sistema de arquivos NFS a partir de um cliente Windows?

A renomeação de um arquivo retorna o erro invalid device se você montou um subdiretório do sistema de arquivos NFS. Para resolver isso, monte o diretório raiz do sistema de arquivos. Para obter mais informações, consulte Etapa 2: Montar um sistema de arquivos NAS de uso geral que usa NFS.

Latência de criação de arquivos no NFS

• Sintoma:

  A ECS-1 criou o arquivo abc, mas há um atraso antes que a ECS-2 possa vê-lo. O atraso às vezes é de 1 segundo, podendo chegar a 1 minuto. Por que isso acontece?

• Causa:

  Isso é causado pelo Lookup Cache e é um comportamento esperado por um período T. Por exemplo, a ECS-2 acessa o caminho do arquivo antes que a ECS-1 crie o arquivo abc. Isso faz com que a ECS-2 receba uma resposta de 'arquivo não encontrado', e um registro indicando que o arquivo abc não existe é armazenado em cache. Dentro do período T, como o FileAttr ainda não expirou, quando a ECS-2 acessa o caminho do arquivo novamente, ela recupera o registro em cache indicando que o arquivo abc não existe.

• Solução:

  Para garantir que a ECS-2 veja o arquivo imediatamente após a ECS-1 criá-lo, use uma das seguintes soluções:

  • Solução 1: Desative o cache de lookup negativo na ECS-2 para evitar o armazenamento em cache de arquivos inexistentes. Esta solução tem a menor sobrecarga.

    Ao montar o sistema de arquivos, adicione a opção lookupcache=positive. O valor padrão é lookupcache=all. O comando a seguir fornece um exemplo:

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,lookupcache=positive file-system-id.region.nas.aliyuncs.com:/ /mnt

  • Solução 2: Desative todos os caches na ECS-2. Esta solução pode degradar severamente o desempenho. Escolha esta solução apenas se sua carga de trabalho exigir.

    Ao montar o sistema de arquivos, adicione a opção actimeo=0. O comando a seguir fornece um exemplo:

    sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

Latência de gravação de dados no NFS

• Sintoma:

  A ECS-1 atualiza um arquivo chamado abc. No entanto, quando a ECS-2 lê o arquivo imediatamente depois, ainda obtém o conteúdo antigo. Por que isso acontece?

• Causa:

  Este problema tem duas causas principais:

  • Depois que a ECS-1 grava dados no arquivo abc, os dados não são liberados imediatamente para o servidor. Em vez disso, o cliente primeiro armazena os dados em seu page cache. Os dados só são liberados quando o aplicativo chama fsync ou close.

  • A ECS-2 possui um cache de arquivos e pode não recuperar imediatamente o conteúdo mais recente do servidor. Por exemplo, se a ECS-2 tiver armazenado os dados em cache quando a ECS-1 atualizar o arquivo abc, a ECS-2 ainda usará o conteúdo em cache ao ler o arquivo novamente.

• Solução:

  Para garantir que a ECS-2 leia imediatamente os dados mais recentes após a ECS-1 atualizar um arquivo, use uma das seguintes soluções:

  • Solução 1: Use a consistência close-to-open (CTO). Para garantir a CTO, depois que a ECS-1 atualizar o arquivo, ela deve chamar close ou fsync. Antes de ler o arquivo, a ECS-2 deve reabri-lo e então efetuar a leitura.

  • Solução 2: Desative todos os caches tanto na ECS-1 quanto na ECS-2. Esta solução pode degradar severamente o desempenho. Escolha-a apenas se sua carga de trabalho exigir.

    • Desative o cache na ECS-1. Ao montar o sistema de arquivos, adicione a opção noac para garantir que todos os dados gravados sejam persistidos imediatamente. O comando a seguir fornece um exemplo:

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,noac file-system-id.region.nas.aliyuncs.com:/ /mnt

      Nota

      • Se a chamada fsync for feita após a conclusão da operação de gravação na ECS-1, ou se você usar gravações síncronas, poderá substituir noac por actimeo=0 para obter um desempenho ligeiramente melhor.

      • A opção noac equivale a especificar actimeo=0 e forçar todas as gravações a serem síncronas.

    • Desative o cache na ECS-2. Ao montar o sistema de arquivos, adicione a opção actimeo=0 para ignorar todos os caches. O comando a seguir fornece um exemplo:

      sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,actimeo=0 file-system-id.region.nas.aliyuncs.com:/ /mnt

Proprietários de arquivos diferentes em instâncias ECS diferentes

Em um sistema de arquivos, a identidade do usuário é identificada por um UID ou GID, não por um nome de usuário. O nome de usuário exibido como proprietário em uma instância ECS é derivado desse UID.

Por exemplo, na instância ECS 1, o usuário admin cria um arquivo chamado admin_on_machine1. Na instância ECS 2, o usuário admin cria um arquivo chamado admin_on_machine2. Ao executar o comando ll na instância ECS 1 para visualizar os arquivos, a saída é mostrada na figura a seguir: Ao executar o comando ll na instância ECS 2, a saída é mostrada na figura a seguir: Os resultados da consulta nas duas instâncias ECS mostram que o mesmo arquivo tem nomes de usuário proprietários diferentes.

Em seguida, execute o comando id em cada instância para consultar as informações do usuário admin. Na instância ECS 1, o UID do usuário admin é 505, conforme mostrado na figura a seguir: Na instância ECS 2, o UID do usuário admin é 2915, conforme mostrado na figura a seguir: Se você executar o comando stat admin_on_machine1 admin_on_machine2, a saída mostrará que os dois arquivos pertencem a UIDs diferentes, conforme mostrado na figura a seguir:

Exceções decorrentes de gravações simultâneas em arquivos de log

Sintoma

O Apsara File Storage NAS fornece acesso compartilhado a arquivos com um namespace unificado para vários clientes. No entanto, quando vários processos ou clientes gravam simultaneamente no mesmo arquivo (por exemplo, um arquivo de log), cada processo mantém seu próprio descritor de arquivo e contexto de deslocamento de gravação. O protocolo NFS não possui semântica de anexação atômica, o que pode levar a problemas de corrupção de dados, como sobrescritas e intercalações.

Solução

• (Recomendado) Configure diferentes processos ou clientes para gravar em arquivos distintos dentro do mesmo sistema de arquivos e, em seguida, mescle os arquivos para análise subsequente. Essa abordagem evita problemas de concorrência e não requer bloqueios de arquivo, portanto, não impacta o desempenho.

• Para cenários que envolvem anexações simultâneas ao mesmo arquivo, como um arquivo de log, você pode usar um bloqueio de arquivo e o mecanismo seek para garantir atomicidade e consistência de gravação. No entanto, esse método pode degradar significativamente o desempenho. A seção a seguir fornece uma breve visão geral para referência.

Como usar flock e seek

Como o protocolo NFS não fornece semântica de anexação atômica, gravações simultâneas no final do mesmo arquivo, como um arquivo de log, podem facilmente sobrescrever umas às outras. No Linux, você pode usar os mecanismos flock e seek para simular anexações atômicas em um sistema de arquivos NFS e proteger gravações de anexação simultâneas.

Siga estas etapas:

1. Chame fd=open(filename, O_WRONLY | O_APPEND | O_DIRECT) para abrir o arquivo no modo de anexação e especifique O_DIRECT para ignorar o page cache. Isso retorna o descritor de arquivo fd.

2. Chame flock(fd, LOCK_EX|LOCK_NB) para tentar adquirir um bloqueio de arquivo. Se a chamada falhar (por exemplo, porque o bloqueio já está mantido), ela retornará um erro. Você pode então tentar novamente ou tratar o erro.

3. Após adquirir o bloqueio, chame lseek(fd, 0, SEEK_END) para mover o deslocamento de gravação atual de fd para o final do arquivo.

4. Realize uma operação de gravação normal. Os dados são gravados no final do arquivo, e o bloqueio de arquivo impede que gravações simultâneas se sobrescrevam.

5. Após concluir a operação de gravação, chame flock(fd, LOCK_UN) para liberar o bloqueio de arquivo.

Por que o comando ls retorna um erro 523 quando executado em um sistema de arquivos NFS no sistema operacional Linux?

Sintoma

Ao executar o comando ls em um sistema de arquivos NFS a partir de um cliente Linux, a seguinte mensagem de erro é retornada.

Causa

Se você executar o comando ls em um diretório do sistema de arquivos enquanto operações rename simultâneas ocorrem nele, um erro 523 será retornado.

Solução

Aguarde um momento e tente novamente a operação. Se o erro persistir, envie um ticket.

Falhas na montagem de sistema de arquivos SMB

Sintoma

Se você usar sistemas de arquivos NFS e SMB e falhar ao montar um sistema de arquivos NFS usando o comando net use, também poderá encontrar problemas ao tentar montar o sistema de arquivos SMB correto.

Solução

Verifique se você está montando o sistema de arquivos correto, interrompa temporariamente a operação de montagem e tente novamente após 5 minutos. Se a operação ainda falhar, envie um ticket.

Diretório montado visível apenas para o Administrator

Esse problema ocorre devido ao mecanismo de isolamento de usuários no Windows. Um diretório montado por um usuário não fica visível na sessão de outro usuário.

Para habilitar o compartilhamento entre vários usuários, crie um link de diretório. Por exemplo, execute o seguinte comando para criar um diretório chamado myshare na unidade C:

mklink /D C:\myshare \\xxxxxxx-xxxx.cn-beijing.nas.aliyuncs.com\myshare\

Baixo desempenho do SMB em clientes Linux

Se um sistema de arquivos SMB apresentar baixo desempenho, solucione o problema com base nas seguintes causas potenciais.

• Causa 1: O throughput máximo de um sistema de arquivos SMB escala linearmente com sua capacidade de armazenamento.

  Solução: Use a ferramenta fio para testar o desempenho do sistema de arquivos SMB. Para obter mais informações, consulte Testar o desempenho de um sistema de arquivos NAS.

• Causa 2: A largura de banda de rede de uma única instância ECS que executa Linux é baixa.

  Solução: Use várias instâncias ECS que executam Linux para alcançar o desempenho geral desejado do sistema de arquivos.

• Causa 3: O cache do lado do cliente para o sistema de arquivos SMB está desativado.

  Solução: Ao montar um sistema de arquivos SMB, cache=none indica que o cache está desativado. A opção padrão ou cache=strict indica que o cache está ativado. Execute o comando sudo mount | grep cifs para verificar se a opção correta está sendo usada.

• Causa 4: O tamanho de E/S para o cliente SMB não está definido corretamente.

  Solução: Ajuste os valores de rsize e wsize com base nos requisitos do seu negócio. O valor padrão é 1048576.

• Causa 5: As especificações de CPU ou memória da instância ECS que executa Linux são muito baixas, ou muitos recursos estão ocupados por outros serviços.

  Solução: Selecione especificações adequadas para a instância ECS que executa Linux e verifique os recursos usados por outros aplicativos no sistema para garantir que os requisitos de CPU e memória sejam atendidos. Execute o comando top para verificar o uso de CPU e memória.

• Causa 6: A opção atime é usada para montagem.

  Solução: Se o seu negócio não for altamente sensível aos tempos de acesso a arquivos (atime), não use a opção atime ao montar o sistema de arquivos.

• Causa 7: O cenário de servidor web envolve leituras frequentes de um grande número de arquivos pequenos, gravações pouco frequentes e notificações de gravação.

  Solução: Configure um mecanismo de cache específico para o servidor web, como Apache, no cliente, ou entre em contato com a equipe do Alibaba Cloud NAS para habilitar a aceleração para cenários de servidor web.

Como resolver o erro Permission denied ao acessar um sistema de arquivos SMB a partir do Linux?

Causa: Esse erro pode ocorrer se valores incorretos para UID, GID, file_mode ou dir_mode forem usados no comando de montagem.

Solução: Verifique se as opções de montagem, como UID, GID, file_mode e dir_mode, estão definidas corretamente. Para obter mais informações, consulte Montar um sistema de arquivos SMB.

Alteração da caixa (maiúsculas/minúsculas) de nomes de arquivos no SMB

Os sistemas de arquivos SMB não diferenciam maiúsculas de minúsculas, o que é consistente com os sistemas Windows. No entanto, você não pode renomear um arquivo alterando apenas a caixa do nome.

Como solução alternativa, primeiro renomeie o arquivo para um nome diferente e, em seguida, renomeie-o para o nome desejado com a caixa correta.

Impossibilidade de alterar proprietário e modo de arquivo

Não é possível alterar dinamicamente o proprietário ou o modo de arquivos e diretórios. Esses atributos só podem ser especificados ao montar o sistema de arquivos. Para obter mais informações, consulte Montar um sistema de arquivos SMB.

O que gera arquivos com a extensão .nfs? Como excluí-los?

Quando você exclui um arquivo aberto em um aplicativo, o sistema cria um arquivo temporário com o sufixo .nfs. O sistema exclui automaticamente esse arquivo quando o processo do aplicativo é encerrado.

Como resolver o erro bind conn to session failed on NFSv4 server ao acessar arquivos em um diretório de sistema de arquivos NAS?

• Causa

  Esse erro ocorre porque o Apsara File Storage NAS não suporta NFSv4.1. O sistema relata esse erro se você tentar montar um sistema de arquivos usando NFSv4.1.

• Solução

  Remonte o sistema de arquivos usando NFSv3 ou NFSv4.0 com base no seu cenário de negócios. Para obter mais informações, consulte Notas de uso para montagem de sistema de arquivos.

Problemas de sincronização de dados com NFS

Sintoma

Quando vários clientes montam o mesmo sistema de arquivos NAS, as alterações de dados feitas em um cliente podem não ser imediatamente visíveis em outros clientes.

Causa

Por padrão, o kernel do sistema operacional mantém atributos de arquivos e diretórios e cria um cache de metadados para reduzir a necessidade de chamadas de procedimento remoto NFSPROC_GETATTR.

Solução

Execute o seguinte comando de montagem para desativar o cache de atributos de arquivos e diretórios.

mount -t nfs4 -o noac file-system-id.region.nas.aliyuncs.com:/ /mnt

Substitua file-system-id.region.nas.aliyuncs.com pelo endereço do ponto de montagem do sistema de arquivos e /mnt pelo caminho local no servidor onde deseja montar o sistema de arquivos.

Contêiner grava no NAS antigo após remontagem

Causa

Se você montar um sistema de arquivos NAS em uma instância ECS e, em seguida, mapear o diretório de montagem para um contêiner usando um volume local (HostPath), as informações de montagem do contêiner tornam-se independentes da instância ECS host. Consequentemente, se você desmontar o diretório NAS original no host ou montar um novo, o contêiner em execução continuará usando o sistema de arquivos NAS antigo.

Solução

Após montar o novo sistema de arquivos NAS na instância ECS, reinicie o Pod do contêiner.

Arquivos não visíveis após reinicialização do servidor

Se o sistema de arquivos ainda existir, esse problema geralmente ocorre porque o servidor não está configurado para montar automaticamente o sistema de arquivos NAS após a reinicialização.

Para montar manualmente o sistema de arquivos NAS novamente, consulte Notas de uso para montagem de sistema de arquivos.

Para configurar a montagem automática do sistema de arquivos NAS após uma reinicialização, consulte os seguintes tópicos:

• Montar automaticamente um sistema de arquivos NFS em um sistema Linux

• Montar automaticamente um sistema de arquivos SMB em um sistema Windows

Migração e cópia de arquivos lentas com SMB no Linux

Se você descartou problemas de desempenho do sistema de arquivos, a lentidão pode dever-se à falta de concorrência no seu processo de migração ou cópia. Use as seguintes ferramentas open-source para migração ou cópia paralela.

• GNU Parallel

  Selecione um número apropriado de threads com base nos recursos do sistema. Exemplo: find * -type f | parallel --will-cite -j 10 cp {} /mnt/smb/ &

• Fpart

• Fpsync

• multi

Erro "Disk quota exceeded"

• Causa

  O uso de armazenamento ou a contagem de arquivos no diretório de destino excedeu o limite restritivo de cota. Como resultado, as operações de gravação falham e uma mensagem de erro como Disk quota exceeded é retornada. Essas operações incluem aumentar o comprimento do arquivo, criar arquivos ou diretórios e mover arquivos para o diretório.

• Solução

  1. Para resolver isso, libere espaço excluindo dados ou aumente o limite de capacidade do diretório. Para obter mais informações, consulte Editar uma cota de usuário.

  2. Após liberar espaço, realize uma operação de gravação de teste no diretório afetado, como criar e gravar dados em um arquivo de teste. Isso aciona uma atualização assíncrona do cache de cotas. Após confirmar que a operação de gravação de teste foi bem-sucedida, reinicie seus serviços.

Erro "Permission denied" ao acessar NFS

Siga estas etapas para configurar AnonymousGid e AnonymousUid para o seu sistema.

1. Faça login na instância ECS onde o sistema de arquivos está montado.

2. Abra o Prompt de Comando e execute o comando regedit para abrir o Editor do Registro.

3. Acesse .

4. Clique com o botão direito em uma área em branco, selecione e crie as duas entradas de registro a seguir.

   • AnonymousGid, com valor de 0.

   • AnonymousUid, com valor de 0.

5. Reinicie a instância ECS.

6. Remonte o sistema de arquivos NAS de uso geral que usa NFS.

   mount -o nolock -o mtype=hard -o timeout=60 \\file-system-id.region.nas.aliyuncs.com\! Z:

   Substitua a letra da unidade Z: e o nome de domínio do ponto de montagem file-system-id.region.nas.aliyuncs.com pelos seus valores reais.

7. Execute o comando mount para verificar se o sistema de arquivos foi montado com sucesso.

   Após a conclusão da montagem, a saída deve incluir mount=hard, locking=no e um valor de timeout de 10 ou superior. Caso contrário, a montagem falhou.

   

Modificação de permissões do diretório raiz com chown

Não é possível modificar as permissões de um diretório raiz do NAS.

Para controlar permissões em um diretório NAS montado localmente, monte um subdiretório. Por exemplo, se você montar o diretório raiz do NAS em /data, não poderá usar chown para alterar o proprietário e o grupo do diretório /data. Se você montar um subdiretório do NAS, que deve ser criado antecipadamente, no diretório local /data, poderá usar chown para alterar o proprietário e o grupo do diretório /data. Observe que, para criar um subdiretório no NAS, você deve primeiro montar o diretório raiz do NAS e então criar o subdiretório. Para obter informações sobre como criar e montar um subdiretório, consulte Como criar e montar um subdiretório NAS em um sistema Linux?.