PowerScale: OneFS: задержка проверки подлинности из-за ненужных внешних запросов SID

В затронутых кластерах могут наблюдаться перечисленные ниже признаки, хотя масштаб и интенсивность симптомов могут различаться в зависимости от конкретных рабочих процессов и конфигурации:

• Во время настройки сессии SMB аутентификация NTLM или Kerberos может занять 10–30 секунд, а иногда и дольше.
• Рабочие процессы NFS могут наблюдать зависание или зависание доступа к файлам в течение длительных периодов времени во время аутентификации.
• Из-за тайм-аутов, вызванных задержками аутентификации, приложения могут сообщать об истечении времени ожидания подключения или ошибках «сервер не отвечает».
• В загруженных рабочих процессах усложняющиеся задержки проверки подлинности могут исчерпать потоки LSASS. Это, в свою очередь, приводит к тому, что другие операции, полагающиеся на LSASS, становятся латентными, ожидая, пока LSASS обработает их запросы.
• При просмотре маркера сопоставления для пользователя демонстрируется аномальная степень задержки.

Также могут присутствовать следующие сообщения журнала, хотя они не являются единственными признаками существующей проблемы. При наличии вышеуказанной задержки они могут стать подозрительными. Эти сообщения присутствуют в /var/log/lsassd.log на узле.

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

Администраторы также могут наблюдать более высокий, чем обычно, исходящий объем запросов LDAP к контроллерам домена Active Directory.

Усовершенствования кода в версии 9.12+ добавили дополнительные ненужные поиски для нелокального членства пользователей в группе, что непреднамеренно увеличивало задержку в 5–15 секунд при поиске. Это становится более очевидным в тех случаях, когда просмотр членства пользователя в группе имеет большое количество членств, в том числе из истории SID.

Кластер может быть подвержен риску возникновения проблемы при выполнении следующих условий:

1. Кластер работает под управлением OneFS 8.2 или более поздней версии.
2. Существует несколько поставщиков проверки подлинности.
3. В /var/log/lsassd.log на затронутых узлах отображается чрезмерное количество сообщений, пытающихся разрешить имена внешним идентификаторам SID.
4. Просмотр токена сопоставления пользователя занимает не менее пяти секунд.

Невозможно точно узнать, будет ли кластер подвержен риску возникновения проблемы, так как это зависит от каждой отдельной внешней среды проверки подлинности. Тем не менее, нахождение на затронутом уровне кода значительно подвергнет кластер риску возникновения проблемы в дополнение к другим элементам, перечисленным выше.

Исправление планируется выпустить в следующих средах:
OneFS 9.15 — выпуск середина/конец августа 2026
г. OneFS 9.13.1.1 — выпуск в августе 2026
г. OneFS 9.14.0.1 — в настоящее время доступно

Одним из способов уменьшить, но не полностью устранить задержку, является уменьшение отрицательного TTL кэша и количества попаданий. Memcache кэширует неудачные поиски для SID группы от имени пользователя, но это не отображается как отрицательная запись до пяти попыток. Обратите внимание, что <Zone> должна быть определена для соответствующей зоны доступа, к которой вы хотите применить эти изменения, с помощью соответствующих команд.

ПРИМЕЧАНИЕ: Всегда проверяйте сбор значений по умолчанию для любых системных или глобальных конфигураций, которые вы планируете изменить, перед изменением этих конфигураций, так как они могут различаться в разных кластерах.

Чтобы изменить количество неудачных постановок, необходимых для записи записи в отрицательный кэш, в одну для указанной зоны доступа, выполните следующие действия.

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

Если приведенного выше параметра не существует для отдельных зон доступа, это же значение также может быть изменено глобально.

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

Чтобы увеличить TTL/срок жизни отрицательной записи кэша до четырех часов, тем самым уменьшив частоту запросов:

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

Несмотря на то, что проблема не устраняется полностью, указанные выше значения в конфигурации снижают частоту потенциальной задержки до одного раза в четыре часа. После установки исправления с исправлением для соответствующего уровня кода администраторы кластера могут вернуть ранее установленные значения вышеуказанных параметров.