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

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

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

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

Fornecer threads de conexão suficientes

Grandes sistemas de cache HPC fazem várias solicitações de conexão para um destino de armazenamento. Por exemplo, se o seu destino de armazenamento usa o módulo Ubuntu Linux nfs-kernel-server , o número padrão de threads de daemon 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 um cache HPC médio 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.

Verificar configurações de porta

O Cache HPC do Azure precisa de acesso de leitura/gravação a várias portas UDP/TCP no sistema de armazenamento NAS 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 do seu data center para verificar essa configuração.

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

Em geral, o cache precisa acessar essas 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 em uma tabela. (Use o endereço IP do seu sistema no lugar do <> storage_IP termo.)

Você pode emitir este comando a partir de qualquer cliente Linux que tenha a infraestrutura NFS instalada. Se você 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

Certifique-se de que todas as portas retornadas pela rpcinfo consulta permitam tráfego irrestrito da sub-rede do Cache HPC do Azure.

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

Verifique as configurações de squash raiz

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

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

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

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

  A política de acesso para cliente padrão não esmaga a raiz.

• Na exportação de armazenamento - Você pode configurar seu sistema de armazenamento para reatribuir solicitações de entrada da raiz para um UID (ID de usuário) não privilegiado.

Se a exportação do sistema de armazenamento esmagar root, você deverá atualizar a regra de acesso do cliente de cache HPC para esse destino de armazenamento para também esmagar root. Caso contrário, você pode ter problemas de acesso ao tentar ler ou gravar no sistema de armazenamento back-end por meio do cache HPC.

Esta tabela ilustra o comportamento para 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.

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

Verificar o acesso em caminhos de diretório

Para sistemas NAS que exportam diretórios hierárquicos, verifique se o Cache HPC do Azure 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 estas:

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

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

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

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

Um sistema NAS com exportações hierárquicas pode fornecer identificadores de arquivo diferentes para o mesmo arquivo se o arquivo for recuperado de exportações diferentes. 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 identificadores de arquivo diferentes (um para e outro para <mount2>/payroll/2011.txt <mount3>/2011.txt).

O sistema de armazenamento back-end mantém aliases internos para identificadores de arquivo, mas o Cache HPC do Azure não pode dizer quais identificadores de arquivo em sua referência de índice o 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 são o mesmo arquivo.

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

Ajustar as restrições de tamanho de pacotes VPN

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

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

• Use sniffers de pacotes em ambos os lados da VPN para detetar quais pacotes são transferidos com êxito.

• Se sua VPN permitir comandos ping, você pode testar o envio de um pacote de tamanho normal.

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

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

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

  • -M do - Não fragmentar
  • -c 1 - Envie apenas um pacote
  • -s 1472 - Defina o tamanho da carga útil para 1472 bytes. Esta é a carga útil de tamanho máximo para um pacote de 1500 bytes depois de contabilizar 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 de tamanho de pacote.

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

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

Verifique o estilo de segurança da ACL

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

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 usam ACLs, o Cache HPC do Azure precisa rastrear valores específicos do usuário adicionais para controlar o acesso a arquivos. Isso é feito ativando um cache de acesso. Não há um controle voltado para o usuário para ativar o cache de acesso, mas você pode abrir um tíquete de suporte para solicitar que ele seja habilitado para os destinos de armazenamento afetados em seu sistema de cache.

Próximos passos

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