{ISILON} OneFS: Desempenho de enumeração de compartilhamento ou autenticação SMB lenta intermitente; isi_cbind_d Atrasos de DNS

Os usuários podem enfrentar latência intermitente ou tempos de espera excedidos ao tentar acessar compartilhamentos armazenados em um cluster do Isilon; O acesso é restaurado sem intervenção em segundos/minutos.

A autenticação e/ou a enumeração de compartilhamento podem levar múltiplos de 5 segundos (por exemplo, 25 segundos, por exemplo) para serem concluídos, mas em intervalos periódicos (~15 minutos por nó precisamente). Um nó pode apresentar o problema, enquanto outros não. Além disso, ao usar o round-robin do SmartConnect, o problema pode parecer mais frequente à medida que cada nó apresenta esse problema independentemente um do outro.

NOTA: Este artigo da KB aborda uma possível causa para a autenticação lenta do SMB e a enumeração de compartilhamento; outras causas podem existir. A recomendação de resolução aqui é uma forma de descartar uma causa

provávelOs itens a seguir podem aparecer nos registros de isi_cbind_d na época dos problemas:
Que pode ser encontrado executando:

Por padrão, a cada 15 minutos, expiraremos nossa conexão AD LDAP DC proativamente. A expiração da conexão DC acontece no momento em que a conexão é usada (ou seja, durante a autenticação), o que iniciará o processo de:

1. Bloquear o Mutex de conexão do DC do AD (isso bloqueia todas as solicitações até que um novo DC seja selecionado)
2. Expirar a conexão existente
3. Enumerar uma lista de DCs aos quais se conectar (registro SRV DNS; _ldap._tcp.dc._msdcs.domain.com)
4. Resolver nomes DNS para o endereço IP da lista de DCs (pesquisas de DNS de registro A)
5. Enviar ping CLDAP para todos os DCs; Aguarde os respondedores mais rápidos (interrompa o envio/recebimento após 10 ms da primeira resposta)
6. Selecione de maneira inteligente entre os DC que respondem (semi-aleatório usando estatísticas históricas de DC)

É durante a fase de pesquisa de registro A do DNS (4, acima) que atrasos podem ser introduzidos. Por padrão, em um cluster Isilon que executa o OneFS 8.x, o cache DNS do groupnet está ativado (isi_cbind_d). Quando o isi_cbind_d (daemon de cache DNS) não consegue atender às pesquisas de DNS (ambos falham ao responder à solicitação e não conseguem entrar em contato com um DC externo), o resolvedor DNS do kernel fará failover para o próximo servidor DNS disponível via /etc/resolv.conf (ou, mais especificamente, para os servidores DNS configurados para o groupnet em questão), o que incorre em um tempo de espera excedido/atraso de 5 segundos para cada consulta de registro A.

O atraso total atribuído às pesquisas de DNS é igual a 5 vezes o número de registros A que precisamos resolver. Se a contagem de registros exceder 12 registros, isso acionará um tempo de espera excedido/redefinição de 60 segundos do client, erros que serão vistos no client relacionados à incapacidade de acessar o cluster/compartilhamento.

NOTA: O culpado mais comum nessa situação é atribuído a isi_cbind_d pesquisas de DNS, mas também pode ser o resultado de outros fatores também

Assumindo o seguinte:

1. O problema é corrigido automaticamente sem a intervenção dos administradores
2. Os atrasos atingem incrementos de 5 segundos
3. A frequência por nó é de ~15 minutos

O caminho mais rápido para resolução e validação é desabilitar o armazenamento em cache DNS para o groupnet em uso:
Como alternativa (se você preferir manter o cache DNS habilitado), uma redução seria reiniciar o serviço de cache DNS em todos os nós:
E verifique se ele foi reiniciado em todos os nós (com base no registro de data e hora de quando o processo foi iniciado):
Se o procedimento acima não resolver o problema, pode haver outros fatores em jogo, que exigiriam assistência do suporte do DellEMC Isilon.

As versões 8.0.0.6/8.0.1.3/8.1.0.2/8.1.1.1 do OneFS contêm a correção (ID 205142) de isi_cbind_d que é uma causa provável para as falhas de DNS descritas neste artigo da KB e, assim que disponíveis, o Isilon recomenda fazer upgrade para essa versão, momento em que o cache DNS poderá ser reativado.

Se o problema ainda persistir após o upgrade para as versões mencionadas acima ou se o armazenamento em cache DNS estiver definido como false no(s) groupnet(s), detalhes adicionais e coleta de dados podem ser necessários para determinar a causa exata.

Se houver alguma dúvida sobre esse problema e os caminhos relacionados à resolução, ou se precisar de assistência, entre em contato com o suporte do Isilon.

Artigos da KB relacionados: 502259 (as latências também podem ser vistas como resultado da falha em encontrar um GC; que também pode ser suscetível ao problema de isi_cbind_d descrito neste artigo da KB)