Solucionar problemas de configuração do NAS e problemas de destino de armazenamento NFS

  • Artigo

Este artigo fornece soluções para alguns erros de configuração comuns e outros problemas que podem impedir que o Azure HPC Cache adicione um sistema de armazenamento NFS como um destino de armazenamento.

Este artigo contém detalhes sobre como verificar portas e como habilitar o acesso necessário a um sistema NAS. Ele também contém informações detalhadas sobre problemas menos comuns que podem causar falha na criação do destino de armazenamento NFS.

Dica

Antes de usar este guia, leia pré-requisitos para destinos de armazenamento NFS.

Se a solução para seu problema não estiver incluída aqui, abra um tíquete de suporte para que o serviço e o suporte da Microsoft possam trabalhar com você para investigar e resolver o problema.

Fornecer threads de conexão suficientes

Sistemas de HPC Cache grandes fazem várias solicitações de conexão para um destino de armazenamento. Por exemplo, se o destino de armazenamento usar o módulo Ubuntu Linux nfs-kernel-server, o número padrão de threads de daemon NFS poderá ser tão baixo quanto oito. Aumente o número de threads para 128 ou 256, que são números mais razoáveis para dar suporte a uma HPC Cache média ou grande.

Você pode verificar ou definir o número de threads no Ubuntu usando o valor RPCNFSDCOUNT em /etc/init.d/nfs-kernel-server.

Configurações de verificação de porta

O Azure HPC Cache precisa de acesso de leitura/gravação a várias portas UDP/TCP no sistema de armazenamento NAS de back-end. Verifique se essas portas estão acessíveis no sistema NAS e também se o tráfego é permitido para essas portas por meio de firewalls entre o sistema de armazenamento e a sub-rede de cache. Talvez seja necessário trabalhar com administradores de firewall e de rede para que seu data center verifique essa configuração.

As portas são diferentes para sistemas de armazenamento de diferentes fornecedores, portanto, verifique os requisitos do seu sistema ao configurar um destino de armazenamento.

Em geral, o cache precisa de acesso a essas portas:

Protocolo Porta Serviço
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 mountd
TCP/UDP 4047 status

Para saber as portas específicas necessárias para seu sistema, use o comando a seguir rpcinfo. O comando a seguir lista as portas e formata os resultados relevantes em uma tabela. (Use o endereço IP do seu sistema no lugar do termo <storage_IP>).

É possível emitir esse comando de qualquer cliente Linux que tenha a infraestrutura de NFS instalada. Ao usar um cliente dentro da sub-rede do cluster, ele também poderá ajudar a verificar a conectividade entre a sub-rede e o sistema de armazenamento.

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

Verifique se todas as portas retornadas pela consulta rpcinfo permitem o tráfego irrestrito da sub-rede do Azure HPC Cache.

Verifique essas configurações no próprio NAS e também em todos os firewalls entre o sistema de armazenamento e a sub-rede de cache.

Verificar as configurações de squash raiz

As configurações de squash raiz poderão interromper o acesso ao arquivo se estiverem configuradas incorretamente. Você deve verificar se as configurações em cada exportação de armazenamento e nas políticas de acesso ao cliente HPC Cache correspondentes são apropriadas.

O squash raiz impede que as solicitações enviadas por uma raiz de superusuário local no cliente sejam enviadas para um sistema de armazenamento de back-end como raiz. Ele reatribui solicitações de raiz para uma UID (ID de usuário não privilegiada) como "ninguém".

Dica

Versões anteriores do Azure HPC Cache exigia sistemas de armazenamento NAS para permitir o acesso raiz do HPC Cache. Agora, você não precisa permitir o acesso raiz em uma exportação de destino de armazenamento, a menos que você queira que os clientes do HPC Cache tenham acesso raiz à exportação.

O squash raiz pode ser configurado em um sistema HPC Cache nestes locais:

  • No HPC Cache do Azure – Use as políticas de acesso de cliente para configurar o squash raiz para clientes que correspondem às regras de filtro específicas. Uma política de acesso de cliente faz parte de cada caminho de namespace de destino de armazenamento NFS.

    A política de acesso de cliente padrão não é o squash raiz.

  • Na exportação de armazenamento, você pode configurar seu sistema de armazenamento para reatribuir solicitações de entrada da raiz para uma UID (ID de usuário não privilegiada).

Se o sistema de armazenamento exportar squashes raiz, você deverá atualizar a regra de acesso do cliente ao HPC Cache para esse destino de armazenamento para também o squash raiz. Caso contrário, você poderá ter problemas de acesso ao tentar ler ou gravar no sistema de armazenamento de back-end por meio do HPC Cache.

Esta tabela ilustra o comportamento de diferentes cenários de squash raiz quando uma solicitação de cliente é enviada como UID 0 (raiz). O cenário marcado com * não é recomendado porque pode causar problemas de acesso.

Configuração UID enviada do cliente UID enviada do HPC Cache UID eficaz no armazenamento de back-end
nenhum squash raiz 0 (raiz) 0 (raiz) 0 (raiz)
squash raiz apenas no HPC Cache 0 (raiz) 65534 (ninguém) 65534 (ninguém)
*squash raiz apenas no armazenamento NAS 0 (raiz) 0 (raiz) 65534 (ninguém)
squash raiz no HPC Cache e NAS 0 (raiz) 65534 (ninguém) 65534 (ninguém)

(UID 65534 é um exemplo; quando você ativa o squash raiz em uma política de acesso de cliente, pode personalizar a UID.)

Verificar acesso em caminhos de diretório

Para sistemas NAS que exportam diretórios hierárquicos, verifique se o Azure HPC Cache tem acesso apropriado a cada nível de exportação no caminho para os arquivos que você está usando.

Por exemplo, um sistema pode mostrar três exportações como essas:

  • /ifs
  • /ifs/accounting
  • /ifs/accounting/payroll

A exportação /ifs/accounting/payroll é um filho de /ifs/accounting e /ifs/accounting é um filho de /ifs.

Se você adicionar a exportação payroll como um destino de armazenamento do HPC Cache, o cache realmente montará /ifs/ e acessará o diretório de folha de pagamento a partir daí. Portanto, o Azure HPC Cache precisa de acesso suficiente a /ifs acessar a exportação /ifs/accounting/payroll.

Esse requisito está relacionado à maneira como o cache indexa arquivos e evita colisões de arquivo, usando identificadores de arquivo que o sistema de armazenamento fornece.

Um sistema NAS com exportações hierárquicas pode fornecer diferentes identificadores de arquivo para o mesmo arquivo se o arquivo for recuperado de diferentes exportações. Por exemplo, um cliente pode montar /ifs/accounting e acessar o arquivo payroll/2011.txt. Outro cliente monta /ifs/accounting/payroll e acessa o arquivo 2011.txt. Dependendo de como o sistema de armazenamento atribui identificadores de arquivo, esses dois clientes podem receber o mesmo arquivo com diferentes identificadores de arquivo (um para <mount2>/payroll/2011.txt e um para <mount3>/2011.txt).

O sistema de armazenamento de back-end mantém aliases internos para identificadores de arquivo, mas o Azure HPC Cache não pode informar quais identificadores de arquivo em seu índice fazem referência ao mesmo item. Portanto, é possível que o cache possa ter gravações diferentes armazenadas em cache para o mesmo arquivo e aplicar as alterações incorretamente porque não sabe que elas são o mesmo arquivo.

Para evitar essa colisão de arquivo possível para arquivos em várias exportações, Azure HPC Cache monta automaticamente a exportação disponível mais superficial no caminho (/ifs, no exemplo) e usa o identificador de arquivo fornecido por essa exportação. Se várias exportações usarem o mesmo caminho base, Azure HPC Cache precisará de acesso a esse caminho.

Ajustar restrições de tamanho de pacote VPN

Se você tiver uma VPN entre o cache e o dispositivo NAS, a VPN poderá bloquear pacotes de Ethernet de 1500 bytes de tamanho completo. Você pode ter esse problema se grandes trocas entre o NAS e a instância do Azure HPC Cache não forem concluídas, mas as atualizações menores funcionarão conforme o esperado.

Não há uma maneira simples de dizer se o seu sistema tem esse problema, a menos que você saiba os detalhes da configuração de sua VPN. Seguem alguns métodos que podem ajudá-lo a verificar esse problema.

  • Use sniffers (farejadores) de pacotes nos dois lados da VPN para detectar quais pacotes são transferidos com êxito.

  • Se a sua VPN permitir comandos ping, você poderá testar o envio de um pacote de tamanho completo.

    Execute um comando ping na VPN para o NAS com essas opções. (Use o endereço IP do seu sistema de armazenamento no lugar do valor <storage_IP>.)

    ping -M do -s 1472 -c 1 <storage_IP>

    Seguem algumas opções no comando:

    • -M do – Não fragmentar
    • -c 1 – Enviar apenas um pacote
    • -s 1472 – Definir o tamanho da carga para 1472 bytes. Esse é o tamanho máximo da carga para um pacote de 1500 bytes, após a contabilização da sobrecarga de Ethernet.

    Uma resposta bem-sucedida tem a aparência a seguir:

    PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms

    Se o ping falhar com 1472 bytes, provavelmente haverá um problema com o tamanho do pacote.

Para corrigir o problema, talvez seja necessário configurar o MSS fixação MSS na VPN para fazer com que o sistema remoto detecte corretamente o tamanho máximo do quadro. Leia a Documentação de parâmetros de IPSec/IKE do Gateway de VPN para saber mais.

Em alguns casos, alterar a configuração de MTU do Azure HPC Cache para 1400 pode ajudar. No entanto, se restringir o MTU no cache, também deverá restringir as configurações de MTU para clientes e sistemas de armazenamento de back-end que interagem com o cache. Leia Definir configurações adicionais do Azure HPC Cache para obter detalhes.

Verificar o estilo de segurança da ACL

Alguns sistemas de NAS usam um estilo de segurança híbrido que combina ACLs (listas de controle de acesso) com segurança de POSIX ou UNIX tradicional.

Se o seu sistema relatar estilo de segurança como UNIX ou POSIX sem incluir o acrônimo "ACL", esse problema não afetará você.

Para sistemas que usam ACLs, Azure HPC Cache precisa rastrear valores adicionais específicos do usuário para controlar o acesso ao arquivo. Isso é feito por meio da habilitação de um cache de acesso. Não há um controle para o usuário que ative o cache de acesso, mas é possível abrir um tíquete de suporte para solicitar que ele seja habilitado para os destinos de armazenamento afetados em seu sistema de cache.

Próximas etapas

Se tiver um problema que não foi abordado neste artigo, entre em contato com o suporte para obter ajuda de especialistas.