PowerScale: OneFS: latenza di autenticazione dovuta a query SID esterne non necessarie

I cluster interessati possono osservare quanto segue, anche se la portata e l'intensità dei sintomi possono variare in base ai singoli flussi di lavoro e alla configurazione:

• Durante la configurazione della sessione SMB, il completamento dell'autenticazione NTLM o Kerberos può richiedere 10-30 secondi, a volte anche di più.
• I flussi di lavoro NFS possono osservare blocchi o arresti dell'accesso ai file per lunghi periodi di tempo durante l'autenticazione.
• A causa dei timeout indotti dai ritardi di autenticazione, le applicazioni potrebbero segnalare timeout di connessione o errori di "server non risponde".
• In flussi di lavoro impegnati, le latenze di autenticazione composte possono esaurire i thread LSASS. Ciò, a sua volta, comporta che altre operazioni che si basano su LSASS diventino latenti in attesa che LSASS elabori le loro richieste.
• La visualizzazione di un token di mapping per un utente dimostra un grado anomalo di latenza.

Potrebbero essere presenti anche i seguenti messaggi di registro, anche se non sono indicativi esclusivamente del problema presente. Se presenti con la latenza di cui sopra, possono diventare sospetti. Questi messaggi sono presenti in /var/log/lsassd.log su un nodo.

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

Gli amministratori possono inoltre osservare un numero di query LDAP in uscita superiore al solito ai controller di dominio Active Directory.

I miglioramenti del codice in 9.12+ hanno introdotto ulteriori ricerche non necessarie per l'appartenenza a gruppi non locali di utenti che aggiungevano involontariamente 5-15 secondi di latenza per ricerca. Ciò è più pronunciato nei casi in cui si esamina l'appartenenza al gruppo di un utente che ha un numero elevato di appartenenze, incluse quelle della cronologia SID.

Un cluster può essere a rischio del problema se si verificano le seguenti condizioni:

1. Il cluster esegue OneFS 9.12 o versione successiva.
2. Sono presenti più provider di autenticazione.
3. È presente un numero eccessivo di messaggi in /var/log/lsassd.log sui nodi interessati che tentano di risolvere SID esterni come nomi.
4. La visualizzazione del token di mapping di un utente richiede cinque secondi o più.

Non esiste modo di sapere con certezza se un cluster rischia di riscontrare il problema, poiché questo è soggettivo per ogni singolo ambiente di autenticazione esterno. Detto questo, trovarsi a livello di codice interessato metterà significativamente un cluster a rischio del problema in aggiunta agli altri elementi elencati in precedenza.

Il rilascio della correzione è previsto in:
OneFS 9.15 - Versione metà/fine agosto 2026
OneFS 9.13.1.1 - Versione agosto 2026
OneFS 9.14.0.1 - Attualmente disponibile

Un modo per ridurre, ma non rimuovere completamente, la latenza sarebbe quello di ridurre il TTL negativo della cache e il numero di riscontri. Memcache memorizza nella cache le ricerche non riuscite per il SID del gruppo come utente, ma non viene elencato come voce negativa fino a cinque tentativi. Tenere presente che <la zona> deve essere definita per la zona di accesso applicabile a cui si desidera applicare queste modifiche con i comandi pertinenti.

NOTA: assicurarsi sempre di raccogliere i valori predefiniti per tutte le configurazioni di sistema o globali che si intende modificare prima di modificarle, in quanto possono variare tra i cluster.

Per modificare il numero di ricerche non riuscite necessarie per scrivere una voce nella cache negativa in una per una zona di accesso specificata:

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

Se il parametro precedente non esiste per le singole zone di accesso, lo stesso valore può essere modificato anche a livello globale.

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

Per estendere il TTL/durata della voce nella cache negativa a quattro ore, riducendo così la frequenza delle query:

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

Anche se il problema non viene completamente rimosso, i valori sopra indicati in cui viene modificata la configurazione riducono la frequenza della latenza potenziale a una volta ogni quattro ore. Dopo aver installato la patch con la correzione per il livello di codice appropriato, gli amministratori del cluster possono ripristinare i valori per le impostazioni precedenti a quelli impostati in precedenza.