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 при ответе контроллера домена.

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

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

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

Временное решение 1.
Существует несколько способов предотвратить появление этих сообщений в журналах. Поскольку проблема возникает при нескольких одновременных попытках открытия канала lsarpc, самый простой способ уменьшить количество сообщений — уменьшить количество необходимых операций поиска SID.

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

[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 или SID для каждого соединения)

Если заданы биты 0 и 1 (0x3 в качестве значения), то потерянные идентификаторы SID разрешается хранить в списках контроля доступа файловой системы (по умолчанию это запрещено). Было бы предложено изменить значение с 0x3 на 0x11, это включается на битах 0,1 и 3. Это означает, что неизвестные SID хранятся без сопоставления unix и просматриваются только в кэшах secmap и глобальных SID. Если установлено значение 0x8 или другая комбинация, в которой биты 0 и 1 отключены, то потерянные идентификаторы безопасности не разрешается сохранять и вносить изменения в этот параметр не нужно.

Если вы хотите изменить параметр, можно выполнить следующую команду:

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

Это, вероятно, уменьшит количество инцидентов, но может полностью устранить, а может и не устранить.

Временное решение 2.
Верный способ избавиться от этих ошибок в журналах — вернуть поведение связи контроллера домена к состоянию, которое было до появления новых кодов (это означает, что мы взаимодействуем только с контроллерами домена в SMB1).

Если вы хотите вернуться к протоколу SMB1 для обмена данными по постоянному току (старое поведение VNX), обратитесь в службу поддержки Dell и укажите эту статью базы знаний.