PowerScale: OneFS: затримка автентифікації через непотрібні зовнішні SID-запити
Summary: У OneFS 9.12 та новіших версіях кластери з кількома налаштованими провайдерами автентифікації можуть спостерігати затримку під час автентифікації за допомогою протоколів. Це є наслідком непотрібних і дорогих запитів про інформацію про членство користувачів на зовнішніх SID. ...
Symptoms
Уражені кластери можуть спостерігати наступне, хоча масштаб і посилення симптомів можуть відрізнятися залежно від індивідуальних робочих процесів і конфігурації:
- Під час налаштування сесії 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.
Cause
Покращення коду в версії 9.12+ додали додаткові непотрібні пошуки для нелокального членства користувачів, що ненавмисно додавало затримку на 5-15 секунд на кожен пошук. Це особливо помітно у випадках, коли розглядають груповий склад користувача з великою кількістю учасників, включно з тими, що з SID History.
Кластер може опинитися під загрозою виникнення проблеми, якщо такі умови виконуються:
- Кластер працює на OneFS 9.12 або новішій версії.
- Існує кілька провайдерів автентифікації.
- У /var/log/lsassd.log надто багато повідомлень на впливових вузлах, які намагаються розв'язати зовнішні SID як імена.
- Перегляд токена карти користувача займає п'ять секунд або більше.
Неможливо точно сказати, чи буде кластер під загрозою зіткнення з проблемою, оскільки це суб'єктивно для кожного окремого зовнішнього середовища автентифікації. Втім, перебування на рівні впливового коду значно підвищить ризик для кластера цієї проблеми, окрім інших пунктів, перелічених вище.
Resolution
Виправлення очікується до випуску:
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
Хоча проблема не усувається повністю, наведені вище значення, на які змінюється конфігурація, зменшують частоту потенційної затримки до одного разу на чотири години. Після встановлення патчу з виправленням відповідного рівня коду адміністратори кластера можуть повернути значення вищезазначених налаштувань до попередніх встановлених значень.