VNX: DOMAIN_CONTROLLER_NOT_FOUND після оновлення коду, який підтримує зв'язок захищеного каналу SMB2

Код був оновлений до однієї з перерахованих вище версій.

Після оновлення до одного з наступних кодів у журналах почали з'являтися повідомлення про помилки, які вказують на те, що контролер домену не працює:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Повідомлення виглядає так:

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

Усі вищезазначені коди додано в нову функцію, яка дозволяє серверу NAS або перейменнику даних обмінюватися даними з контролерами домену в SMB2. До появи цього коду всі комунікації контролера домену оброблялися в SMB1 (хоча клієнти все ще могли спілкуватися з нами в SMB2/SMB3).
З переходом на SMB2 наші команди не всі серіалізуються для контролерів домену. Схоже, що це призводить до того, що деякі команди виконуються одночасно паралельно.
Прикладом може служити спроба відкрити іменований lsarpc канал з іменем.

У цьому повідомленні про помилку важливо зазначити службу, до якої ми намагаємося прив'язатися:

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

З повідомлення про помилку ми можемо бачити, що він намагається відкрити LSA (виділено червоним). Ось тут і виникає проблема. Ми намагаємося відкрити трубу з іменем lsarpc кілька разів одночасно, перш ніж отримати відповідь від постійного струму. Перший запит успішний, але наступні не вдається. Ми бачимо повідомлення про збої із зазначенням STATUS_PIPE_NOT_AVAILABLE і записуємо повідомлення про DOMAIN_CONTROLLER_NOT_FOUND в журнали.

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

2017-06-28 14:37:45: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened
2017-06-28 14:37:47: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened

Якщо виникнуть питання про те, чи відповідає проблема проблемі, це можна підтвердити за допомогою трасування пакетів. У трасуванні ми побачимо кілька одночасних запитів на відкриття lsarpc до отримання відповіді на будь-який з них, після чого перший з них буде успішним, а наступні зазнають невдачі з STATUS_PIPE_NOT_AVAILABLE, коли DC відповість.

Ця проблема зазвичай виникає переважно в системах, які вимагають багато пошуків SID на контролері домену. Якщо у середовищі є осиротілі SID, воно має тенденцію реєструвати набагато більше цих помилок. Це пов'язано з обсягом трафіку, який надсилається до постійного струму, і кожного разу, коли ми звертаємося до ACL, ми повинні надсилати запит до постійного струму, щоб запитати ідентичність будь-яких SID, яких у нас немає в кеші SID. Осиротілі SID ніколи не зберігаються у кеші SID, і їх намагаються знайти кожного разу, збільшуючи кількість відкриттів, які нам потрібно виконати з каналом lsarpc з іменем.

Оскільки перша відкрита спроба вдається, це подія, яка не має жодного впливу, і ці повідомлення можна ігнорувати.

Постійне виправлення:
Інженери знають про проблему і працюють над її вирішенням у майбутньому випуску коду. Це не руйнівна проблема, і її можна спокійно ігнорувати. Однак, якщо ви все-таки хочете спробувати зменшити або видалити повідомлення, є кілька доступних обхідних шляхів.

Спосіб вирішення проблеми 1:
Є кілька способів спробувати зупинити появу цих повідомлень у журналах. Оскільки проблему спричиняють декілька одночасних відкритих спроб на каналі lsarpc, найпростішим способом зменшити кількість повідомлень є зменшення кількості потрібних пошуків SID.

Осиротілі SID спричиняють ці надмірні пошуки. Наступний параметр може бути змінений, щоб змусити пошуковиків дивитися на кеш secmap на наявність невідомих sid і повинен зменшити кількість трафіку, що йде до DC:

[nasadmin@CS0 ~]$ server_param server_2 -f cifs -i acl.mappingErrorAction -v
server_2 :
name                    = acl.mappingErrorAction
facility_name           = cifs
default_value           = 8
current_value           = 8
configured_value        = 8
user_action             = none
change_effective        = immediate
range                   = (0,31)
description             = Define rules for an unknown SID/UID/GID mapping

detailed_description
Defines the rules for unknown mapping between SID/UID/GID on ACL settings. Two kinds of errors might occur: the SID set in the ACL is unknown to the Domain Controllers we are using, or the username is not yet mapped to a UID/GID. 0x01: Stores unknown sid. 0x02: Stores sid with no UNIX mapping. 0x04: Enables debug traces. 0x08: Only do lookup in cache (secmap or globalSid cache or per connection SID cache) 0x08 is HIGHLY RECOMMENDED WITH OPTION=0x01. 0x10: Disable log displayed when an unknown SID resolution takes too much time.Maximum value = 0x1F Refer to param cifs.acl.retryAuthSID

Це виливається в наступну інформацію:
Bit0 = Зберігає невідомий sid.
Bit1 = Зберігає sid без відображення UNIX.
Bit2 = Включає трасування налагодження.
Bit3 = Шукати лише в кеші (secmap або globalSid cache або за з'єднанням кеш SID)

Якщо встановлено біти 0 і 1 (0x3 як значення), то осиротілі SID дозволяється зберігати в списках керування доступом до файлової системи (за замовчуванням це не так). Було б запропоновано змінити значення з 0x3 на 0x11, при цьому включається біт 0,1 і 3. Це означає, що ви зберігаєте невідомі SID без відображення Unix і шукайте лише в secmap та глобальних кешах SID. Якщо встановлено значення 0x8 або інша комбінація, де біти 0 і 1 відключені, то сироти sid зберігати не допускається і ніяких змін в цей параметр вносити не потрібно.

Якщо ви хочете змінити параметр, можна виконати наступну команду:

server_param server_2 -f cifs -m acl.mappingErrorAction -v 11

Це, ймовірно, зменшує кількість випадків, але може повністю їх усунути, а може і не усунути.

Спосіб вирішення проблеми 2:
Надійний спосіб позбутися цих помилок у журналах — повернути поведінку зв'язку постійного струму до того, якою вона була до появи нових кодів (це означає, що ми спілкуємося лише з контролерами домену в SMB1).

Якщо ви хочете повернутися до SMB1 для зв'язку постійного струму (стара поведінка VNX), зверніться до служби підтримки Dell і зверніться до цієї статті бази знань.