PowerScale : OneFS : latence d’authentification due à des requêtes SID externes inutiles

Les clusters affectés peuvent observer ce qui suit, bien que l’étendue et l’intensification des symptômes puissent varier en fonction des workflows et de la configuration individuels :

• Lors de la configuration d’une session SMB, l’authentification NTLM ou Kerberos peut prendre 10 à 30 secondes, parfois plus.
• Les workflows NFS peuvent observer des blocages ou des blocages d’accès aux fichiers pendant de longues périodes lors de l’authentification.
• En raison des délais d’expiration induits par les délais d’authentification, les applications peuvent signaler des délais d’expiration de connexion ou des erreurs « le serveur ne répond pas ».
• Dans les workflows chargés, les latences d’authentification combinées peuvent épuiser les threads LSASS. Par conséquent, d’autres opérations s’appuient sur LSASS pour devenir latentes en attendant que LSASS traite leurs demandes.
• L’affichage d’un jeton de mappage pour un utilisateur démontre un degré anormal de latence.

Les messages de journal suivants peuvent également être présents, bien qu’ils ne soient pas exclusivement indicatifs du problème présent. Lorsqu’ils sont présents avec la latence ci-dessus, ils peuvent devenir suspects. Ces messages sont présents dans /var/log/lsassd.log sur un nœud.

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

Les administrateurs peuvent également observer des requêtes LDAP sortantes plus élevées que d’habitude sur les contrôleurs de domaine Active Directory.

Les améliorations apportées au code dans la version 9.12+ ont introduit des recherches supplémentaires inutiles pour l’appartenance à un groupe non local d’utilisateurs qui ajoutaient involontairement 5 à 15 secondes de latence par recherche. Cela est plus prononcé dans les cas où l’on examine l’appartenance à un groupe d’un utilisateur qui a un grand nombre d’appartenances, y compris celles de SID History.

Un cluster peut être exposé à ce problème si les conditions suivantes sont remplies :

1. Le cluster exécute OneFS 9.12 ou une version supérieure.
2. Plusieurs fournisseurs d’authentification sont présents.
3. Il y a un nombre excessif de messages dans /var/log/lsassd.log sur les nœuds affectés qui tentent de résoudre les SID externes en tant que noms.
4. L’affichage du jeton de mappage d’un utilisateur prend cinq secondes ou plus.

Il n’existe aucun moyen de savoir avec certitude si un cluster risque de rencontrer le problème, car cela dépend de chaque environnement d’authentification externe. Cela dit, le fait d’être au niveau du code concerné expose considérablement un cluster au risque du problème en plus des autres éléments répertoriés ci-dessus.

Le correctif devrait être publié dans :
OneFS 9.15 - Sortie mi/fin août 2026
OneFS 9.13.1.1 - Sortie août 2026
OneFS 9.14.0.1 - Actuellement disponible

Un moyen de réduire, mais pas de supprimer complètement, la latence consiste à réduire la TTL négative du cache et le nombre de correspondances. Memcache met en cache les recherches en échec pour le SID du groupe en tant qu’utilisateur, mais celui-ci n’est répertorié en tant qu’entrée négative qu’après cinq tentatives. Notez que <Zone> doit être définie pour la zone d’accès applicable à laquelle vous souhaitez appliquer ces modifications avec les commandes appropriées.

REMARQUE : Veillez toujours à collecter les valeurs par défaut pour toutes les configurations système ou globales que vous envisagez de modifier avant de les modifier, car elles peuvent varier d’un cluster à l’autre.

Pour modifier le nombre d’échecs de recherche nécessaires à l’écriture d’une entrée dans le cache négatif à un pour une zone d’accès spécifiée :

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

Si le paramètre ci-dessus n’existe pas pour les zones d’accès individuelles, la même valeur peut également être modifiée globalement.

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

Pour étendre la TTL/durée de vie de l’entrée de cache négative à quatre heures, réduisant ainsi la fréquence des requêtes :

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

Bien que le problème ne soit pas entièrement résolu, les valeurs ci-dessus utilisées par la configuration réduisent la fréquence de latence potentielle à une fois toutes les quatre heures. Après avoir installé le correctif avec le correctif pour le niveau de code approprié, les administrateurs de cluster peuvent rétablir les valeurs des paramètres ci-dessus à ce qui a été précédemment défini.