Solução de problemas: problemas no Gateway de Arquivos

Verifique se o gateway não está tentando usar um controlador de domínio somente leitura (RODC) para ingressar no domínio.

Verifique se o gateway está configurado para usar os servidores DNS corretos.

Por exemplo, se você estiver tentando unir uma instância de gateway do Amazon EC2 a um Active Directory AWS gerenciado, verifique se a opção DHCP definida para sua VPC do EC2 especifica os servidores DNS do AWS Active Directory gerenciados.

Os servidores DNS configurados por meio do conjunto de opções DHCP da VPC são fornecidos para todas as instâncias do EC2 na VPC. Se quiser especificar um servidor DNS para um gateway individual, você pode fazer isso usando o console local do EC2 desse gateway.

Em relação a gateways on-premises, você especifica um servidor DNS usando o console local da VM.

Verifique a conectividade da rede do gateway executando os comandos a seguir no prompt de comando no console local do gateway. Substitua as variáveis destacadas pelo nome de domínio e endereços IP reais da sua implantação.

dig -d ExampleDomainName
ncport -d ExampleDomainControllerIPAddress -p 445
ncport -d ExampleDomainControllerIPAddress -p 389

Verifique se sua conta de serviço do Active Directory tem as permissões necessárias. Para acessar mais informações, consulte Requisitos de permissão da conta de serviço do Active Directory.

Verifique se o gateway se associa à unidade organizacional (UO) correta.

A adesão a um domínio cria uma conta de computador do Active Directory no contêiner de computadores padrão (que não é uma OU), usando a ID do gateway do gateway como nome da conta (por exemplo, SGW-1234ADE). Não é possível personalizar o nome dessa conta.

Se seu ambiente do Active Directory tiver uma UO designada para novos objetos de computador, você deverá especificar essa UO ao ingressar no domínio.

Se você encontrar erros de acesso negado ao tentar ingressar na UO designada, consulte o administrador do domínio do Active Directory. Talvez o administrador precise pré-preparar a conta do computador do gateway para que ele possa ingressar no domínio. Para acessar mais informações, consulte Como soluciono problemas ao associar meu Gateway de Arquivos do Storage Gateway a um domínio para autenticação do Microsoft Active Directory?.

Verifique se o nome do host do seu gateway pode ser resolvido no DNS executando o comando a seguir no prompt de comando, no console local do gateway. Substitua a variável destacada pelo nome de host real do gateway.

dig -d ExampleHostName -r A

Se você configurou um nome de host personalizado para seu gateway, deverá adicionar manualmente um DNS A-record que aponte para seu endereço IP.

Verifique se a latência da rede entre o gateway e o controlador de domínio está razoavelmente baixa. A consulta para ingressar em um domínio poderá expirar se o gateway não receber uma resposta do controlador de domínio em 20 segundos.

Se você unir o gateway ao domínio usando o comando JoinDomain CLI, poderá adicionar o --timeout-in-seconds sinalizador para aumentar o tempo limite para no máximo 3.600 segundos.

Confirme se o usuário do Active Directory que você está usando para associar o gateway ao domínio tem os privilégios necessários para isso.

Se a métrica IndexFetch for maior que 0 quando você executar um comando ls ou navegar por diretórios, o Gateway de Arquivos foi iniciado sem informações sobre o conteúdo do diretório afetado e precisou acessar o FSx para Windows File Server. Os esforços subsequentes para listar o conteúdo desse diretório deverão ocorrer com mais rapidez.

Se a métrica IndexEviction for maior que 0, significa que o Gateway de Arquivos atingiu o limite do que pode gerenciar em seu cache no momento. Nesse caso, o Gateway de Arquivos precisa liberar espaço de armazenamento do diretório acessado há mais tempo para listar um novo diretório. Se isso ocorrer com frequência e houver um impacto no desempenho, entre em contato Suporte.

Discuta Suporte o conteúdo do sistema de arquivos relacionado ao Amazon FSx e as recomendações para melhorar o desempenho com base no seu caso de uso.

Se essa foi uma reinicialização atual ou uma atualização de software, verifique a métrica IOWaitPercent. Essa métrica mostra a porcentagem de tempo em que a CPU fica ociosa quando há uma I/O solicitação de disco pendente. Em alguns casos, isso pode ser alto (10 ou mais) e pode ter aumentado depois que o servidor foi reinicializado ou atualizado. Nesses casos, o Gateway de Arquivos pode estar sendo limitado por um disco raiz lento à medida que ele recria o cache de índice para RAM. É possível resolver esse problema usando um disco físico mais rápido para o disco raiz.

Caso a métrica MemUsedBytes seja igual ou quase igual à métrica MemTotalBytes, o Gateway de Arquivos está ficando sem RAM disponível. Verifique se o Gateway de Arquivos tem pelo menos a RAM mínima necessária. Se já tiver, pense em adicionar mais RAM ao Gateway de Arquivos com base na workload e no caso de uso.

Se o compartilhamento de arquivos for SMB, o problema também pode ser devido ao número de clientes SMB conectados ao compartilhamento de arquivos. Para ver o número de clientes conectados em determinado momento, verifique a métrica SMBV(1/2/3)Sessions. Se houver muitos clientes conectados, talvez seja necessário adicionar mais RAM ao Gateway de Arquivos.

Caso a métrica CachePercentDirty seja 80 ou mais, significa que o Gateway de Arquivos está gravando dados mais depressa no disco do que consegue fazer upload deles para o Amazon FSx para Windows File Server. Pense em aumentar a largura de banda para upload do seu Gateway de Arquivos, adicionar um ou mais discos de cache, reduzir a velocidade de gravação do cliente ou aumentar a capacidade de throughput do Amazon FSx para Windows File Server associado.

Se a métrica CachePercentDirty estiver baixa, confira a métrica IoWaitPercent. Caso IoWaitPercent seja maior que 10, pode ser que o Gateway de Arquivos esteja sendo limitado pela velocidade do disco de cache local. Recomendamos discos de unidade de estado sólido (SSD) local para o cache, de preferência NVM Express (NVMe). Se esses discos não estiverem disponíveis, tente usar vários discos de cache de discos físicos separados para melhorar o desempenho.

Se a métrica CachePercentDirty for 90% ou mais, o Gateway de Arquivos não poderá aceitar novas gravações em disco porque não há espaço disponível suficiente no disco de cache. Para ver a rapidez com que seu Gateway de Arquivos está fazendo upload para o FSx para Windows File Server, visualize a métrica CloudBytesUploaded. Compare essa métrica com a métrica WriteBytes, que mostra a rapidez com que o cliente está gravando arquivos no Gateway de Arquivos. Se o cliente SMB estiver gravando no Gateway de Arquivos mais rápido do que consegue fazer upload para o FSx para Windows File Server, adicione mais discos de cache para cobrir, no mínimo, o tamanho do trabalho de backup. Ou aumente a largura de banda de upload.

Se a cópia de um arquivo grande, como um trabalho de backup falhar, mas a métrica CachePercentDirty for inferior a 80%, o Gateway de Arquivos poderá estar atingindo um tempo limite de sessão no lado do cliente. Para SMB, você pode aumentar esse tempo limite usando o PowerShell comando. Set-SmbClientConfiguration -SessionTimeout 300 A execução desse comando define o tempo limite para 300 segundos.