Resolução de problemas na configuração do NAS e nos problemas com o destino de armazenamento NFS

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

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

Se a solução para o seu problema não estiver incluída aqui, por favor abra um ticket de suporte para que o Serviço e o Suporte da Microsoft possam trabalhar consigo para investigar e resolver o problema.

Garantir subprocessos de conexão suficientes

Grandes sistemas de cache HPC fazem múltiplos pedidos de ligação a um alvo de armazenamento. Por exemplo, se o seu destino de armazenamento usar o módulo do Ubuntu Linux nfs-kernel-server, o número padrão de threads de daemons do NFS pode 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 suportar uma cache HPC média ou grande.

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

Verifique as definições das portas

O Azure HPC Cache necessita de acesso de leitura/escrita a várias portas UDP/TCP no sistema de armazenamento NAS de back-end. Certifique-se de que estas portas são acessíveis no sistema NAS e também que o tráfego é permitido para essas portas através de quaisquer firewalls entre o sistema de armazenamento e a sub-rede de cache. Pode ser necessário trabalhar com os administradores de firewall e de rede do seu data center para verificar esta configuração.

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

Em geral, a cache precisa de acesso a estas portas:

Para aprender as portas específicas necessárias para o seu sistema, use o seguinte rpcinfo comando. Este comando abaixo lista as portas e formata os resultados relevantes numa tabela. (Use o endereço IP do seu sistema em vez do <termo storage_IP> .)

Pode emitir este comando a partir de qualquer cliente Linux que tenha infraestrutura NFS instalada. Se usar um cliente dentro da sub-rede do cluster, também pode 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

Certifique-se de que todas as portas devolvidas pela rpcinfo consulta permitem tráfego irrestrito da sub-rede da cache HPC do Azure.

Verifique estas definições tanto no próprio NAS como em quaisquer firewalls entre o sistema de armazenamento e a sub-rede de cache.

Verifique as definições de root squash

As definições de root squash podem interromper o acesso a ficheiros se estiverem mal configuradas. Deves verificar se as definições de cada exportação de armazenamento e das políticas de acesso ao cliente HPC Cache correspondentes são adequadas.

O "root squash" impede que pedidos enviados por um superutilizador root local no cliente sejam tratados como root por um sistema de armazenamento de back-end. Reatribui pedidos do root para um ID de utilizador (UID) não privilegiado, como 'nobody'.

O root squash pode ser configurado num sistema de cache HPC nestes locais:

• No Azure HPC Cache, utilize políticas de acesso ao cliente para configurar root squash para os clientes que correspondam a regras de filtro específicas. Uma política de acesso ao cliente faz parte do caminho de namespace de cada alvo de armazenamento NFS.

  A política de acesso ao cliente por defeito não elimina o root.

• Na exportação de armazenamento - Pode configurar o seu sistema de armazenamento para reatribuir as solicitações recebidas do utilizador root para um ID de utilizador sem privilégios (UID).

Se a exportação do sistema de armazenamento eliminar root, deve-se atualizar a regra de acesso do cliente HPC Cache para o alvo de armazenamento de modo a também eliminar root. Caso contrário, pode ter problemas de acesso ao tentar ler ou escrever no sistema de armazenamento de back-end através da Cache HPC.

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

(O UID 65534 é um exemplo; quando ativa o root squash numa política de acesso ao cliente, pode personalizar o UID.)

Verifique o acesso nos caminhos dos diretórios

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

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

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

A exportação /ifs/accounting/payroll é filha de /ifs/accounting, e /ifs/accounting é ela própria filha de /ifs.

Se adicionares a payroll exportação como um alvo de armazenamento do HPC Cache, a cache na verdade monta /ifs/ e acede ao diretório de salários daí. Portanto, o Azure HPC Cache precisa de acesso suficiente a /ifs para aceder ao /ifs/accounting/payroll export.

Este requisito está relacionado com a forma como a cache indexa os ficheiros e evita colisões de ficheiros, usando os controladores de ficheiros fornecidos pelo sistema de armazenamento.

Um sistema NAS com exportações hierárquicas pode fornecer diferentes handles de ficheiro para o mesmo ficheiro se este for recuperado de exportações diferentes. Por exemplo, um cliente poderia montar /ifs/accounting e aceder ao ficheiro payroll/2011.txt. Outro cliente monta /ifs/accounting/payroll e acede ao ficheiro 2011.txt. Dependendo de como o sistema de armazenamento atribui os handles de ficheiros, estes dois clientes podem receber o mesmo ficheiro com handles diferentes (um para <mount2>/payroll/2011.txt e outro para <mount3>/2011.txt).

O sistema de armazenamento back-end mantém aliases internos para os handles de ficheiros, mas o Azure HPC Cache não consegue identificar quais os handles de ficheiros no seu índice que referenciam o mesmo item. Portanto, é possível que a cache tenha diferentes escritas armazenadas no mesmo ficheiro e aplique as alterações incorretamente porque não sabe que são o mesmo ficheiro.

Para evitar esta possível colisão de ficheiros em múltiplas exportações, o Azure HPC Cache monta automaticamente a exportação mais superficial disponível no caminho (/ifs no exemplo) e utiliza o handle de ficheiro fornecido por essa exportação. Se múltiplas exportações usarem o mesmo caminho base, o Azure HPC Cache precisa de acesso a esse caminho.

Ajustar as restrições de tamanho dos pacotes VPN

Se tiver uma VPN entre a cache e o seu dispositivo NAS, a VPN pode bloquear pacotes Ethernet de tamanho completo de 1500 bytes. Pode ter este problema se as grandes trocas entre o NAS e a instância de cache HPC do Azure não forem concluídas, mas as atualizações mais pequenas funcionarem como esperado.

Não há uma forma simples de saber se o seu sistema tem este problema ou não, a menos que conheça os detalhes da configuração da sua VPN. Aqui estão alguns métodos que o podem ajudar a identificar este problema.

• Use analisadores de pacotes em ambos os lados da VPN para detetar quais são os pacotes transferidos com sucesso.

• Se a tua VPN permite comandos ping, podes testar o envio de um pacote de tamanho completo.

  Executa um comando ping pela VPN para o NAS com estas opções. (Use o endereço IP do seu sistema de armazenamento em vez do <valor storage_IP> .)

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

  Estas são as opções do comando:

  • -M do - Não fragmentar
  • -c 1 - Enviar apenas um pacote
  • -s 1472 - Definir o tamanho da carga útil para 1472 bytes. Esta é a carga útil de tamanho máximo para um pacote de 1500 bytes, tendo em conta a sobrecarga Ethernet.

  Uma resposta com sucesso tem o seguinte aspeto:

  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 há um problema no tamanho do pacote.

Para resolver o problema, pode ser necessário configurar o MSS clamping na VPN para que o sistema remoto detete corretamente o tamanho máximo do frame. Leia a documentação de parâmetros IPsec/IKE do VPN Gateway para saber mais.

Em alguns casos, alterar a definição de MTU para a cache HPC do Azure para 1400 pode ajudar. No entanto, se restringires a MTU na cache, também tens de restringir as definições da MTU para clientes e sistemas de armazenamento back-end que interagem com a cache. Leia Configurar definições adicionais de cache HPC do Azure para mais detalhes.

Verifique a configuração de segurança ACL

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

Se o seu sistema reportar o seu estilo de segurança como UNIX ou POSIX sem incluir o acrónimo "ACL", este problema não o afeta.

Para sistemas que utilizam ACLs, o Azure HPC Cache precisa de rastrear valores adicionais específicos do utilizador para controlar o acesso a ficheiros. Isto é feito ativando uma cache de acesso. Não existe um controlo voltado para o utilizador para ativar o cache de acesso, mas pode abrir um pedido de suporte para pedir que seja ativado para os destinos de armazenamento afetados no seu sistema de cache.

Passos seguintes

Se tiver um problema que não foi abordado neste artigo, contacte o suporte para obter ajuda especializada.