PowerScale: OneFS: Authenticatielatentie als gevolg van onnodige externe SID-query's

Getroffen clusters kunnen het volgende waarnemen, hoewel het bereik en de intensivering van de symptomen kunnen variëren afhankelijk van de afzonderlijke workflows en configuratie:

• Tijdens het instellen van SMB-sessies kan het 10 tot 30 seconden duren voordat NTLM- of Kerberos-authenticatie is voltooid, soms langer.
• NFS-workflows kunnen tijdens de verificatie waarnemen dat de toegang tot bestanden gedurende langere tijd vastloopt of vastloopt.
• Als gevolg van time-outs die worden veroorzaakt door de vertragingen in de verificatie, kunnen applicaties time-outs van de verbinding of de fout dat de server niet reageert, melden.
• Bij drukke workflows kunnen de samengestelde verificatielatenties LSASS-threads uitputten. Dit leidt er op zijn beurt toe dat andere activiteiten die afhankelijk zijn van LSASS latent worden terwijl ze wachten tot LSASS hun verzoeken verwerkt.
• Het weergeven van een toewijzingstoken voor een gebruiker toont een abnormale mate van latentie.

De volgende logboekberichten kunnen ook aanwezig zijn, hoewel ze niet uitsluitend een indicatie zijn van het aanwezige probleem. Wanneer ze aanwezig zijn met de bovenstaande latentie, kunnen ze verdacht worden. Deze berichten zijn aanwezig in /var/log/lsassd.log op een knooppunt.

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

Beheerders kunnen ook meer dan gebruikelijke uitgaande LDAP-query's naar Active Directory-domeincontrollers waarnemen.

Codeverbeteringen in 9.12+ introduceerden extra onnodige lookups voor niet-lokaal groepslidmaatschap van gebruikers die onbedoeld 5-15 seconden latentie per lookup toevoegden. Dit is meer uitgesproken in gevallen waarin wordt gekeken naar het groepslidmaatschap van een gebruiker met een groot aantal lidmaatschappen, waaronder die van SID History.

Een cluster loopt risico op het probleem als aan de volgende voorwaarden wordt voldaan:

1. Het cluster is op OneFS 9.12 of hoger.
2. Er zijn meerdere authenticatieproviders aanwezig.
3. Er zijn een buitensporig aantal berichten in /var/log/lsassd.log op getroffen knooppunten die externe SID's als namen proberen op te lossen.
4. Het bekijken van het toewijzingstoken van een gebruiker duurt vijf seconden of langer.

Er is geen manier om met zekerheid te weten of een cluster het risico loopt op het probleem, omdat dit subjectief is voor elke afzonderlijke externe authenticatieomgeving. Dat gezegd hebbende, zal een cluster aanzienlijk risico lopen op het probleem als het zich op het getroffen codeniveau bevindt, naast de andere hierboven genoemde items.

De oplossing wordt verwacht voor release in:
OneFS 9.15 - release midden/eind augustus 2026
OneFS 9.13.1.1 - release augustus 2026
OneFS 9.14.0.1 - momenteel beschikbaar

Een manier om de latentie te verminderen, maar niet volledig te verwijderen, is het verminderen van de negatieve cache-TTL en het aantal hits. Memcache slaat de mislukte zoekopdrachten voor de groeps-SID als gebruiker op in de cache, maar dat wordt pas na vijf pogingen als een negatieve vermelding vermeld. Houd er rekening mee dat <> zone moet worden gedefinieerd voor de toepasselijke toegangszone waarop u deze wijzigingen wilt toepassen met de relevante opdrachten.

Opmerking: zorg er altijd voor dat u de standaardwaarden verzamelt voor alle systeem- of algemene configuraties die u wilt wijzigen voordat u ze wijzigt, aangezien deze per cluster kunnen verschillen.

Ga als volgt te werk om het aantal mislukte lookups te wijzigen dat nodig is om een vermelding naar de negatieve cache te schrijven naar één voor een opgegeven toegangszone:

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

Als de bovenstaande parameter niet bestaat voor afzonderlijke toegangszones, kan dezelfde waarde ook globaal worden gewijzigd.

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

Ga als volgt te werk om de TTL/levensduur van het negatieve cache-item te verlengen tot vier uur, waardoor de frequentie van query's wordt verminderd:

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

Hoewel het probleem niet volledig wordt opgelost, wordt met de bovenstaande waarden waarnaar de configuratie wordt gewijzigd, de frequentie van de potentiële latentie teruggebracht tot eens in de vier uur. Na het installeren van de patch met de oplossing voor het juiste codeniveau, kunnen clusterbeheerders de waarden voor de bovenstaande instellingen terugzetten naar de waarden die eerder zijn ingesteld.