PowerScale: OneFS: latência de autenticação devido a consultas externas desnecessárias de SID

Os clusters afetados podem observar o seguinte, embora o escopo e a intensificação dos sintomas possam variar de acordo com a configuração e os fluxos de trabalho individuais:

• Durante a configuração da sessão do SMB, a autenticação NTLM ou Kerberos pode levar de 10 a 30 segundos para ser concluída, às vezes mais.
• Os fluxos de trabalho do NFS podem observar paralisações ou paralisações de acesso ao arquivo por longos períodos durante a autenticação.
• Devido a tempos de espera excedidos induzidos pelos atrasos de autenticação, os aplicativos podem relatar tempos limite de conexão ou erros de "servidor não respondendo".
• Em fluxos de trabalho ocupados, as latências de autenticação compostas podem esgotar os threads do LSASS. Isso, por sua vez, faz com que outras operações que dependem do LSASS fiquem latentes enquanto aguardam que o LSASS processe suas solicitações.
• A exibição de um token de mapeamento para um usuário demonstra um grau anormal de latência.

As seguintes mensagens de log também podem estar presentes, embora não sejam exclusivamente indicativas do problema. Quando apresentam a latência acima, eles podem se tornar suspeitos. Essas mensagens estão presentes em /var/log/lsassd.log em um nó.

Unknown SID <SID> in file provider, trying to resolve as name
Unknown SID <SID> in NIS provider, trying to resolve as name
Unknown SID in LDAP provider, trying to resolve as name

Os administradores também podem observar consultas LDAP de saída mais altas do que as usuais para controladores de domínio do Active Directory.

Os aprimoramentos de código no 9.12+ introduziram pesquisas adicionais desnecessárias para membros de grupos não locais de usuários que, involuntariamente, adicionaram de 5 a 15 segundos de latência por pesquisa. Isso é mais pronunciado nos casos em que se analisa a associação de grupo de um usuário que tem um grande número de associações, incluindo aquelas do histórico de SID.

Um cluster pode estar em risco do problema se as seguintes condições forem verdadeiras:

1. O cluster está executando o OneFS 9.12 ou posterior.
2. Há vários provedores de autenticação presentes.
3. Há um número excessivo de mensagens em /var/log/lsassd.log nos nós afetados tentando resolver SIDs externos como nomes.
4. A visualização do token de mapeamento de um usuário leva cinco segundos ou mais.

Não há como saber definitivamente se um cluster correrá o risco de enfrentar o problema, pois isso é subjetivo a cada ambiente de autenticação externa individual. Dito isso, estar no nível de código afetado colocará significativamente um cluster em risco do problema, além dos outros itens listados acima.

A correção está projetada para ser lançada em:
OneFS 9.15 - lançamento em meados de/final de agosto de 2026
OneFS 9.13.1.1 - versão agosto de 2026
OneFS 9.14.0.1 - Disponível no momento

Um meio de reduzir, mas não remover completamente, a latência seria reduzir o TTL de cache negativo e a contagem de ocorrências. O memcache armazena em cache as pesquisas com falha do SID do grupo como usuário, mas isso não é listado como uma entrada negativa até cinco tentativas. Observe que <a zona> deve ser definida para a zona de acesso aplicável à qual você deseja aplicar essas alterações com os comandos relevantes.

NOTA: sempre colete os valores padrão de qualquer sistema ou configurações globais que você planeja modificar antes de alterá-los, pois eles podem variar entre os clusters.

Para modificar o número de pesquisas com falha necessárias para gravar uma entrada no cache negativo em uma para uma zona de acesso especificada:

# isi_gconfig registry.Services.lsass.Parameters.Zones.<zone>.NegCacheHitsThreshold=1

Se o parâmetro acima não existir para zonas de acesso individuais, o mesmo valor também poderá ser alterado globalmente.

isi_gconfig registry.Services.lsass.Parameters.NegCacheHitsThreshold=1

Para estender o TTL/vida útil da entrada de cache negativa para quatro horas, reduzindo assim a frequência de consultas:

# isi zone zones modify <Zone> --negative-cache-entry-expiry=4H

Embora não remova totalmente o problema, os valores acima para os quais a configuração é alterada reduzem a frequência de latência potencial para uma vez a cada quatro horas. Depois de instalar o patch com a correção para o nível de código apropriado, os administradores de cluster podem reverter os valores das configurações acima de volta para o que foram definidos anteriormente.