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 o Azure HPC Cache de adicionar um sistema de armazenamento NFS como um destino de armazenamento.

Este artigo inclui detalhes sobre como verificar as 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 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.

Forneça encadeamentos de conexão suficientes

Sistemas de cache HPC 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 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 um HPC Cache 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 as configurações da porta

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

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

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

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

Você pode emitir esse comando de qualquer cliente Linux que tenha a infraestrutura do 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

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

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.

Verificar as configurações de root squash

As configurações de root squash poderão interromper o acesso a arquivos 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 do HPC Cache correspondentes são apropriadas.

O Root Squash impede que solicitações enviadas pelo superusuário root local no cliente sejam enviadas como usuário root para o sistema de armazenamento de back-end. Ele reatribui solicitações do usuário root para um ID de usuário (UID) sem privilégios, como 'nobody'.

O "Root squash" pode ser configurado em um sistema de Cache HPC nestas localizações.

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

  A política de acesso ao 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 uma UID (ID de usuário sem privilégios).

Se o seu sistema de armazenamento realizar exportação com supressão de permissões de root, você deverá atualizar a regra de acesso do cliente do Cache HPC para esse destino de armazenamento também suprimir as permissões de root. 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 root squash quando uma requisição do cliente é emitida como UID 0 (root). O cenário marcado com * não é recomendado porque pode causar problemas de acesso.

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

Verificar o acesso em caminhos de diretório

Para sistemas NAS que exportam diretórios hierárquicos, verifique se o HPC Cache 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 é filho de /ifs/accounting, e /ifs/accounting é em si um filho de /ifs.

Se você adicionar a payroll exportação 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 HPC Cache do Azure precisa ter acesso suficiente a /ifs para 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 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 <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 HPC Cache do Azure não pode informar quais identificadores de arquivo em seu índice referenciam 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 elas são o mesmo arquivo.

Para evitar a colisão de arquivos que pode ocorrer em múltiplas exportações, o HPC Cache do Azure monta automaticamente a exportação mais superficial disponível no caminho (/ifs no exemplo) e usa o identificador de arquivo dessa exportação. Se várias exportações usarem o mesmo caminho base, o HPC Cache do Azure precisará de acesso a esse caminho.

Ajustar restrições de tamanho de pacote VPN

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

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

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

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

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

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

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

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

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

Em alguns casos, a alteração da configuração de MTU para o Azure HPC Cache 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 de back-end que interagem com o cache. Leia Definir configurações adicionais do Azure HPC Cache para obter detalhes.

Verificar as configurações de segurança da ACL

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

Se o sistema relatar seu 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, o HPC Cache do Azure precisa rastrear valores adicionais específicos do usuário para controlar o acesso a arquivos. Isso é feito habilitando 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óximas Etapas 

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