PowerScale: OneFS: latencia de autenticación debido a consultas SID externas innecesarias

Los clústeres afectados pueden observar lo siguiente, aunque el alcance y la intensidad de los síntomas pueden variar según los flujos de trabajo y la configuración individuales:

• Durante la configuración de la sesión de SMB, la autenticación NTLM o Kerberos puede tardar entre 10 y 30 segundos en completarse, a veces más.
• Los flujos de trabajo de NFS pueden observar bloqueos o estancamientos en el acceso a archivos durante períodos prolongados durante la autenticación.
• Debido a los tiempos de espera agotados inducidos por los retrasos de autenticación, las aplicaciones pueden informar tiempos de espera agotados de conexión o errores de "servidor que no responde".
• En flujos de trabajo ocupados, las latencias de autenticación de composición pueden agotar los subprocesos de LSASS. Esto, a su vez, hace que otras operaciones que dependen de LSASS se vuelvan latentes mientras esperan a que LSASS procese sus solicitudes.
• La visualización de un token de mapeo para un usuario demuestra un grado anormal de latencia.

Los siguientes mensajes de registro también pueden estar presentes, aunque no son indicativos exclusivos del problema presente. Cuando están presentes con la latencia anterior, pueden volverse sospechosos. Estos mensajes están presentes en /var/log/lsassd.log en 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

Los administradores también pueden observar más consultas de LDAP salientes de lo habitual a controladores de dominio de Active Directory.

Las mejoras de código en 9.12+ introdujeron búsquedas adicionales innecesarias para la pertenencia a grupos no locales de usuarios que agregaron involuntariamente de 5 a 15 segundos de latencia por búsqueda. Esto es más pronunciado en los casos en los que se observa la membresía de grupo de un usuario que tiene una gran cantidad de membresías, incluidas las del historial de SID.

Un clúster puede estar en riesgo de experimentar el problema si se cumplen las siguientes condiciones:

1. El clúster ejecuta OneFS 9.12 o superior.
2. Hay varios proveedores de autenticación presentes.
3. Hay una cantidad excesiva de mensajes en /var/log/lsassd.log en los nodos afectados que intentan resolver SID externos como nombres.
4. La visualización del token de mapeo de un usuario tarda cinco segundos o más.

No hay manera de saber con certeza si un clúster estará en riesgo de enfrentar el problema, ya que esto es subjetivo para cada entorno de autenticación externo individual. Dicho esto, estar en el nivel de código afectado pondrá significativamente a un clúster en riesgo de sufrir el problema, además de los otros elementos enumerados anteriormente.

Se proyecta la versión de la corrección en:
OneFS 9.15: lanzamiento a mediados/finales de agosto de 2026
OneFS 9.13.1.1: lanzamiento de agosto de 2026
OneFS 9.14.0.1: disponible actualmente

Un medio para reducir, pero no eliminar por completo, la latencia sería reducir el TTL de caché negativo y el recuento de aciertos. Memcache almacena en caché las búsquedas fallidas del SID de grupo como usuario, pero eso no se enumera como una entrada negativa hasta cinco intentos. Tenga en cuenta que <la zona> debe estar definida para la zona de acceso aplicable a la que desea aplicar estos cambios con los comandos pertinentes.

NOTA: Asegúrese siempre de recopilar los valores predeterminados de cualquier sistema o configuración global que planee modificar antes de cambiarlos, ya que pueden variar entre clústeres.

Para modificar la cantidad de búsquedas fallidas necesarias para escribir una entrada en la caché negativa en una para una zona de acceso especificada:

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

Si el parámetro anterior no existe para las zonas de acceso individuales, el mismo valor también se puede cambiar globalmente.

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

Para extender el TTL/vida útil de la entrada de caché negativa a cuatro horas, reduciendo así la frecuencia de las consultas:

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

Si bien no se elimina el problema por completo, los valores anteriores a los que se cambia la configuración reducen la frecuencia de latencia potencial a una vez cada cuatro horas. Después de instalar el parche con la corrección para el nivel de código correspondiente, los administradores de clústeres pueden revertir los valores de los ajustes anteriores a los que se establecieron anteriormente.