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 do Amazon EC2 Gateway a um Active Directory AWS gerenciado, verifique se a opção DHCP definida para sua EC2 VPC especifica os servidores DNS gerenciados do AWS Active Directory.

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

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

Verifique a conectividade de 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 obter 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 associação a um domínio criará uma conta de computador do Active Directory no contêiner de computadores padrão (que não é uma UO) usando o ID 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 de computador do gateway para que ele possa ingressar no domínio. Para obter 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 de 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 o gateway, deverá adicionar manualmente um registro A de DNS que aponte para seu endereço IP.

Verifique se a latência de 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 JoinDomainCLI, poderá adicionar o --timeout-in-seconds sinalizador para aumentar o tempo limite para um máximo de 3.600 segundos.

Verifique 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 fazer isso.

Se a IndexFetch métrica for maior que 0 quando você executa um ls comando ou navega pelos diretórios, seu gateway de arquivos começou sem informações sobre o conteúdo do diretório afetado e precisou acessar o S3 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 é 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 com Suporte o conteúdo do sistema de FSx arquivos relacionado da Amazon 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.

Se a CachePercentDirty métrica for 80 ou maior, seu File Gateway está gravando dados em disco mais rápido do que pode fazer o upload dos dados FSx para o Amazon for Windows File Server. Considere 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 taxa de transferência do Amazon FSx for 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 locais de unidade de estado sólido (SSD) para seu cache, preferencialmente 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á sendo carregado para o S3 para Windows File Server, veja CloudBytesUploaded a métrica. 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 seu gateway de arquivos mais rápido do que pode fazer o upload para o S3 para Windows File Server, adicione mais discos de cache para cobrir, no mínimo, o tamanho da tarefa 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.