Почему постоянно появляется окно «Блокировка работы с внешними ресурсами» в кластере 1С и как это исправить?

При переходе на работу в многосерверном кластере «1С:Предприятия» администраторы и пользователи часто сталкиваются с неприятной проблемой. Время от времени у пользователей с полными правами начинает всплывать предупреждающее окно: «Блокировка работы с внешними ресурсами» с сообщением о том, что информационная база была перемещена. Даже если администратор регулярно нажимает кнопку «Информационная база перемещена», через некоторое время окно возвращается снова.

Если рядовые пользователи по незнанию нажмут соседнюю кнопку «Оставить заблокированной», это приведет к моментальной остановке критически важных процессов: рассылки почты, обмена данными с банками и сайтами, а также выполнения регламентных заданий. В этой статье мы подробно разберем, почему возникает эта ошибка в многосерверной архитектуре, как ее правильно устранить штатными средствами БСП (Библиотеки стандартных подсистем), а также проанализируем популярную архитектурную ошибку с развертыванием двух независимых кластеров 1С для одной базы СУБД.

---

Почему возникает блокировка работы с внешними ресурсами на кластере из нескольких серверов?

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

Рассмотрим внутренний алгоритм работы этой защиты:

1. При первом запуске или при явном подтверждении перемещения базы система фиксирует текущие параметры окружения и записывает их в константу ПараметрыБлокировкиРаботыСВнешнимиРесурсами (хранится в виде структуры в ХранилищеЗначения).
2. Среди сохраняемых параметров присутствуют: уникальный идентификатор базы данных СУБД, строка соединения, имя локального компьютера и, что критично в нашем случае, имя рабочего сервера 1С в кластере.
3. При каждом последующем старте любого сеанса или фонового процесса БСП считывает текущие параметры среды и сравнивает их с эталоном из константы.

Выясним причину сбоя на многосерверном кластере:

В кластере, состоящем из нескольких рабочих серверов (например, 1c1 и 1c2), нагрузка динамически распределяется. Сессия пользователя или регламентное задание может быть запущено на сервере 1c1, а при следующем входе или перераспределении нагрузки — на сервере 1c2.

Когда фоновое задание или сеанс запускается на сервере 1c2, БСП видит, что текущее имя рабочего сервера отличается от записанного в константе (где было сохранено 1c1). Система мгновенно расценивает это как запуск базы на другом оборудовании (копирование базы) и блокирует работу с внешними ресурсами, требуя подтверждения от администратора. В журнале регистрации при этом фиксируются постоянные записи о смене сохраненного имени компьютера с 1c1 на 1c2 и обратно.

---

Как правильно решить проблему (штатные способы БСП)

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

Способ 1. Отключение проверки имени сервера через пользовательский интерфейс

Это самый простой и быстрый способ, доступный администратору системы непосредственно в момент появления предупреждения:

1. Дождитесь появления окна предупреждения «Информационная база перемещена...».
2. Обратите внимание на правый верхний угол формы предупреждения — там находится кнопка «Еще». Нажмите на нее.
3. В выпадающем меню снимите флажок «Проверять имя сервера».
4. После этого нажмите на стандартную кнопку «Информационная база перемещена».

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

Способ 2. Отключение проверки через функции для технического специалиста

Если окно в данный момент не вывелось на экран, но вы хотите превентивно отключить проверку имени сервера, выполните следующие шаги:

1. Запустите сеанс под пользователем с полными правами.
2. Перейдите в главное меню, выберите раздел «Функции для технического специалиста» (в старых версиях платформы — «Все функции»).
3. В списке констант найдите Параметры блокировки работы с внешними ресурсами.
4. Откройте форму редактирования этой константы.
5. Снимите флаг «Проверять имя сервера» и сохраните изменения.

Способ 3. Программное отключение проверки через внешнюю обработку

Если вам необходимо автоматизировать этот процесс (например, при развертывании баз из скриптов или при автоматическом обновлении), мы можем воспользоваться программным интерфейсом БСП. Проанализируем пример кода, который можно запустить во внешней обработке:

// Программный вызов метода БСП для отключения проверки имени сервера
Если ОбщегоНазначения.ПодсистемаСуществует("СтандартныеПодсистемы.РегламентныеЗадания") Тогда
    МодульБлокировки = ОбщегоНазначения.ОбщийМодуль("БлокировкаРаботыСВнешнимиРесурсами");
    МодульБлокировки.УстановитьПроверкуИмениСервераВПараметрыБлокировки(Ложь);
КонецЕсли;

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

---

Анализ смежной проблемы: Использование двух независимых кластеров 1С для одной базы СУБД

Рассмотрим еще одну критическую ситуацию, часто возникающую из-за попыток повысить производительность системы неквалифицированными специалистами. Речь идет о сценарии, когда для работы с одной и той же физической базой данных на сервере СУБД (например, MS SQL или PostgreSQL) создают **два независимых кластера 1С** (на разных физических серверах или даже на одном сервере, но на разных портах).

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

• Регламентные задания работают некорректно, дублируются или зависают.
• При входе пользователей или обновлении конфигурации постоянно возникают ошибки вида «база не найдена», «сеанс отсутствует» или конфликты блокировок.

Проанализируем технические причины этих сбоев:

1. Несогласованность кэша метаданных. Каждый кластер 1С активно кэширует структуру метаданных, таблицу активных сеансов и конфигурацию в оперативной памяти своих рабочих процессов rphost. Два независимых кластера никак не обмениваются между собой состоянием кэша. Когда один кластер вносит изменения в базу данных или обновляет динамическую конфигурацию, второй кластер продолжает использовать устаревший кэш в своей памяти. Это гарантированно приводит к разрушению структуры данных, ошибкам динамического обновления и регулярным вылетам пользователей.
2. Конфликт планировщиков регламентных заданий. Запуск фоновых процессов координируется менеджерами кластеров rmngr. Информация о регламентных заданиях хранится в СУБД в таблице _ScheduledJobs. Когда два независимых менеджера кластера одновременно пытаются читать эту таблицу, назначать время запуска и выполнять одни и те же задания, в СУБД возникают жесткие взаимоблокировки (Deadlocks). Задания либо выполняются параллельно в двух кластерах одновременно (что может привести к дублированию проводок или писем), либо аварийно завершаются.

Как организовать работу правильно?

Для повышения производительности необходимо использовать строго **один логический кластер 1С**, в который будут объединены несколько рабочих серверов. Распределение нагрузки в едином кластере настраивается через **Требования назначения функциональности (ТНФ)** в консоли администрирования кластера:

• Для серверов общего назначения (например, 1c1 и 1c2) мы задаем требования на обслуживание только клиентских соединений.
• Для выделенного сервера под регламентные задания (например, 1c3) мы настраиваем требование выполнять только сервис регламентных заданий. Для этого в консоли администрирования создается требование с типом объекта требования «Сервис фоновых заданий» и действием «Выполнять». На остальных серверах для этого сервиса устанавливается действие «Не выполнять».

Такой подход обеспечивает централизованное управление сеансами, единый кэш метаданных и гарантирует корректную работу планировщика задач без конфликтов блокировок в СУБД.