Почему при запуске баз 1С возникает ошибка «Поставщик именованных каналов: Не удалось открыть соединение с SQL Server [53]»?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При обслуживании кластера 1С:Предприятия с большим числом информационных баз (50 и более), расположенных на выделенном сервере СУБД Microsoft SQL Server, администраторы периодически сталкиваются с внезапным аварийным завершением сеансов. Ошибка сопровождается системным сообщением: «Сеанс работы завершен администратором. Соединение с сервером баз данных разорвано администратором. Microsoft SQL Server Native Client 11.0: Поставщик именованных каналов: Не удалось открыть соединение с SQL Server [53] (HRESULT=80004005, SQLSTATE=08001, native=53)».

При этом наблюдается странное поведение: если проблемную информационную базу удалить из кластера 1С (без физического удаления с SQL-сервера) и добавить заново, она успешно запускается, но спустя 10–15 минут ошибка воспроизводится вновь. Выясним причину этой неполадки и разберем по шагам, как правильно настроить серверную инфраструктуру.

В чем кроется истинная причина ошибки?

Проанализируем ситуацию: код ошибки [53] в терминах операционной системы Windows расшифровывается как ERROR_BAD_NETPATH («Сетевой путь не найден»). Упоминание Поставщика именованных каналов (Named Pipes) часто вводит в заблуждение, заставляя искать проблему в именованных каналах или общей памяти (Shared Memory).

На самом деле данная ошибка является маскировочной. По умолчанию клиентский сетевой драйвер SQL Server сначала инициирует подключение по основному протоколу TCP/IP. Если соединение завершается неудачей (по таймауту, отсутствию свободных портов или сбросу сессии межсетевым экраном), драйвер выполняет автоматический откат (fallback) к следующему сконфигурированному протоколу — Named Pipes. Для работы именованных каналов по сети требуется протокол SMB (порт TCP 445). Поскольку сетевой экран этот служебный трафик блокирует, попытка также проваливается, и в журнал 1С выводится ошибка именно последнего опрошенного протокола. Истинный сбой происходит на этапе установки или удержания TCP-соединения.

Почему ошибка проявляется именно при большом пуле баз и через 10–15 минут:

  1. Блокировка или тихий сброс сессий брандмауэром (TCP Idle Timeout). Межсетевые экраны со stateful-фильтрацией отслеживают активность TCP-сессий. Если к конкретной базе запросы не поступают в течение 10–15 минут, брандмауэр молча закрывает соединение в таблице трансляций без отправки RST-пакетов. Пул соединений процесса rphost считает соединение открытым, отправляет запрос, получает отказ по таймауту и производит аварийный сброс.
  2. Исчерпание динамических портов (TCP Port Exhaustion). Кластер из 50+ баз под нагрузкой рабочих процессов rphost генерирует огромное количество кратковременных TCP-соединений. После закрытия порт переходит в состояние TIME_WAIT на 4 минуты. При стандартных настройках Windows диапазон свободных портов быстро заканчивается, новые сессии не могут открыться, и драйвер аварийно пытается уйти в Named Pipes.
  3. Блокировка службы SQL Server Browser. Если СУБД использует динамические порты или именованный экземпляр, сервер 1С обращается к службе SQL Browser по протоколу UDP 1434. Блокировка этого порта межсетевым экраном приводит к невозможности определить целевой порт СУБД.

Шаг 1. Корректная настройка брандмауэра на сервере СУБД

Полное отключение брандмауэра помогает локализовать сетевую проблему, но снижает безопасность контура. Вместо полного отключения защиты создадим целевые входящие правила на сервере Microsoft SQL Server.

  1. Откроем Брандмауэр Защитника Windows в режиме повышенной безопасности на сервере СУБД.
  2. В разделе «Правила для входящих подключений» создадим правило для порта: протокол TCP, порт 1433 (или нестандартный статический порт, назначенный вашему экземпляру).
  3. Если используется именованный экземпляр (например, SQLSRV\INST1), создадим правило для протокола UDP, порт 1434 (служба SQL Server Browser).
  4. В свойствах правила на вкладке «Область» (Scope) строго ограничим удаленные IP-адреса, разрешив доступ только с IP-адресов серверов кластера 1С.

Шаг 2. Принудительная фиксация протокола TCP/IP

Чтобы исключить нежелательные попытки драйвера переключаться на Named Pipes при задержках в сети, зафиксируем TCP/IP принудительно на уровне параметров подключения к базе данных.

Рассмотрим подробнее: в консоли администрирования кластера серверов 1С откроем свойства проблемной информационной базы. В поле «Сервер баз данных» укажем явный сетевой протокол и порт:

  1. Вариант с префиксом протокола: tcp:ИмяСервера,1433 или tcp:192.168.1.50,1433
  2. Вариант с прямым указанием порта: ИмяСервера,1433

Также зафиксируем протокол на уровне операционной системы самого сервера 1С с помощью утилиты настройки сетевых библиотек клиента SQL:

  1. Запустим утилиту cliconfg.exe из каталога C:\Windows\System32\ (для 64-разрядного сервера 1С) и из C:\Windows\SysWOW64\ (для 32-разрядного).
  2. На вкладке «Общие» (General) переместим протокол TCP/IP на первое место по приоритету, либо полностью отключим протокол Именованные каналы (Named Pipes).
  3. На вкладке «Псевдонимы» (Alias) добавим алиас для сервера SQL: выберем сетевую библиотеку TCP/IP, укажем имя сервера и порт 1433.

Шаг 3. Тонкая настройка сетевого стека Windows под высокую нагрузку

При наличии более 50 баз на одном кластере сетевой стек Windows на сервере 1С требует оптимизации для предотвращения исчерпания сокетов. Разберем по шагам параметры реестра:

  1. Запустим редактор реестра regedit и перейдем в ветку: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  2. Создадим параметр MaxUserPort с типом DWORD и установим значение 65534 (в десятичной системе). Это расширит пул доступных клиентских исходящих портов.
  3. Создадим параметр TcpTimedWaitDelay с типом DWORD и установим значение 30 (в десятичной системе). Это уменьшит время удержания закрытого соединения в состоянии TIME_WAIT со стандартных 240 секунд до 30 секунд, высвобождая сокеты для новых подключений.

Альтернативно настройку пула портов можно выполнить в командной строке от имени администратора:

netsh int ipv4 set dynamicport tcp start=1025 num=64510

Шаг 4. Оптимизация параметров рабочих процессов кластера 1С

Если в кластере работает более 50 информационных баз, запуск всех баз в рамках одного-двух процессов rphost перегружает пул потоков и соединений. Для изоляции сбоев настроим кластер:

  1. Откроем консоль администрирования серверов 1С:Предприятия.
  2. В свойствах кластера найдем параметр «Количество ИБ на один процесс». По умолчанию он не ограничен. Установим значение в диапазоне от 4 до 8.
  3. В результате кластер автоматически создаст несколько рабочих процессов rphost и равномерно распределит базы между ними. Если в одной из баз зависнет пул сетевых дескрипторов к SQL, это не приведет к падению сеансов в остальных 40–50 базах.

Шаг 5. Обновление сетевого провайдера СУБД

Обратим внимание на используемый драйвер в тексте ошибки: Microsoft SQL Server Native Client 11.0 (SQLNCLI11). Данный компонент давно объявлен устаревшим и может некорректно обрабатывать восстановление разорванных сессий на современных версиях Windows Server.

Платформа 1С:Предприятие 8.3 поддерживает актуальный драйвер Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL). Установка на сервере 1С драйвера версии 18 или 19 обеспечивает более стабильную работу пула соединений, устойчивость к кратковременным разрывам связи и корректное информирование платформы о сетевых таймаутах.

← На главную