Как вынести фоновые задания 1С на отдельный сервер

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

Механизм реализуется штатными средствами платформы 1С:Предприятие 8.3 через требования назначения функциональности и требования назначения объектов. Никаких сторонних программ не требуется — достаточно консоли администрирования кластера и понимания того, какие задания куда должны попадать.

Материал рассчитан на файловые ограничения не учитывать: вынос возможен только в клиент-серверном варианте работы. Если база файловая, фоновые задания выполняются в процессе того клиента, который их запустил, и отдельный сервер здесь не поможет — сначала потребуется переход на сервер 1С с СУБД.

Когда вынос фоновых заданий действительно нужен

Не каждая база требует выделенного сервера. Если фоновых заданий немного и они короткие, накладные расходы на второй сервер не окупятся. Отдельная машина оправдана, когда наблюдаются конкретные симптомы: пользователи жалуются на «тормоза» в моменты запуска регламентных операций, обмены с сайтом или ЭДО занимают заметную долю процессорного времени, а длительные отчёты выполняются фоном и «съедают» память рабочих процессов.

Второй сценарий — требования к стабильности. Когда фоновое задание аварийно завершается или «отъедает» всю память рабочего процесса, страдают и пользовательские сеансы на том же процессе. Изоляция заданий на отдельном сервере ограничивает последствия сбоев.

Подготовка: что проверить перед настройкой

Перед внесением изменений убедитесь, что инфраструктура готова. Второй сервер должен быть добавлен в тот же кластер 1С, что и основной, с той же версией платформы. Различия версий платформы между рабочими серверами кластера недопустимы — кластер с ними просто не будет работать корректно.

Проверьте сетевую связность: выделенный сервер должен иметь доступ к серверу СУБД по тем же портам и с теми же учётными данными, что и основной. Частая ситуация — задание не стартует на новом сервере, потому что файрвол режет подключение к SQL Server или PostgreSQL.

Также оцените ресурсы выделенного сервера. Для фоновых заданий важны объём оперативной памяти и быстрый диск, если задания активно работают с временными файлами. Число рабочих процессов на нём обычно можно увеличить относительно основного сервера, поскольку задания менее чувствительны к задержкам, чем интерактивные сеансы.

Настройка требований назначения функциональности

Основной механизм выноса — требования назначения функциональности (ТНФ). Они задаются в консоли администрирования кластера: ветка «Рабочие серверы» → нужный сервер → «Требования назначения функциональности».

Логика настройки такова: на основном сервере создаётся требование, где объект требования — «Клиентское соединение с ИБ» или «Сервис сеансовых данных» работают как обычно, а для «Сервиса фоновых заданий» устанавливается тип требования «Не назначать». На выделенном сервере, наоборот, для сервиса фоновых заданий ставится «Назначать», а для клиентских соединений — «Не назначать», чтобы пользователи туда не попадали.

1. 1
   Откройте консоль администрирования серверов 1С и разверните нужный кластер
2. 2
   На основном рабочем сервере создайте ТНФ: объект требования — «Сервис фоновых заданий», тип требования — «Не назначать»
3. 3
   На выделенном сервере создайте ТНФ: «Сервис фоновых заданий» — «Назначать»
4. 4
   На выделенном сервере создайте ТНФ: «Клиентское соединение с ИБ» — «Не назначать», чтобы исключить попадание пользовательских сеансов
5. 5
   Убедитесь, что на каждом сервере присутствует требование «Любой объект требования» — «Назначать» с низким приоритетом, иначе часть сервисов может остаться без обработчика
6. 6
   Перезапуск кластера не требуется — требования применяются автоматически

Важно понимать приоритеты: требования с типом «Авто» применяются, если нет явных правил. Явные правила с «Назначать» и «Не назначать» имеют приоритет над «Авто». Если оставить на выделенном сервере только «Назначать» для фоновых заданий и не запретить клиентские соединения, кластер может направить туда и пользователей при нехватке других серверов.

Тонкая настройка через требования назначения объектов

Когда нужно распределять не все задания, а только часть, используются требования назначения объектов (ТНО). Они позволяют привязать выполнение конкретных регламентных заданий или фоновых заданий определённой информационной базы к конкретному рабочему серверу.

Типичный сценарий: в кластере несколько баз, и тяжёлые задания одной «большой» базы выносятся на отдельный сервер, а задания остальных баз остаются на общих. В ТНО указывается имя информационной базы и, при необходимости, имя регламентного задания, после чего задаётся сервер-исполнитель.

ТНО имеют приоритет над ТНФ. Это даёт гибкость, но и создаёт риск запутанной конфигурации: если правил много, становится трудно предсказать, где фактически выполнится задание. Документируйте каждое правило и держите их число минимальным.

Альтернативы и дополнительные приёмы

Если поднимать второй сервер нет возможности, частичного эффекта можно добиться иначе. Один из приёмов — увеличение числа рабочих процессов на существующем сервере и ограничение объёма памяти на процесс, чтобы тяжёлое задание не «утапливало» соседние сеансы. Другой приём — перенос расписания регламентных заданий на нерабочие часы: ночью и в выходные.

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

Сравнение вариантов

Отдельный рабочий сервер в кластере

Полная изоляция заданий, предсказуемая нагрузка. Требует дополнительного оборудования и лицензий на сервер 1С при превышении ограничений

Настройка ТНО без нового сервера

Распределение заданий между процессами существующего сервера. Дёшево, но не изолирует ресурсы физически

Перенос расписаний на нерабочее время

Нулевые затраты, но не подходит для обменов, которые должны работать в течение дня

Проверка результата

После настройки убедитесь, что задания действительно выполняются на выделенном сервере. Откройте консоль кластера, ветку «Сеансы» и «Соединения»: фоновые задания видны как сеансы типа «Фоновое задание», и в колонке рабочего сервера должно значиться имя выделенной машины.

Параллельно проверьте журнал регистрации: регламентные задания должны запускаться по расписанию и завершаться без ошибок. Если задания «молчат», чаще всего причина в том, что ни один сервер не удовлетворяет требованиям — например, на выделенном сервере забыли «Назначать», а на основном поставили «Не назначать».

Контрольные точки

Как проверить результат

Сеансы фоновых заданий в консоли кластера

Норма

Сеансы типа «Фоновое задание» привязаны к выделенному серверу

Тревожный признак

Задания выполняются на основном сервере или отсутствуют вовсе

Журнал регистрации по регламентным заданиям

Норма

Задания стартуют по расписанию и завершаются успешно

Тревожный признак

Ошибки запуска, задания не выполнялись дольше периода расписания

Нагрузка на основной сервер

Норма

CPU и память основного сервера перестали пиковать в моменты запуска заданий

Тревожный признак

Пики нагрузки сохраняются — задания не ушли с сервера

Типичные ошибки и ограничения

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

Перед выносом зафиксируйте базовые метрики: среднее время отклика базы в часы пик и длительность ключевых заданий. Без «до» невозможно доказать эффект «после» — и понять, если настройка что-то ухудшила.

Частые вопросы

Нужна ли отдельная лицензия 1С для второго сервера?

Лицензирование зависит от редакции сервера 1С и числа ядер. Серверная лицензия привязывается к аппаратной конфигурации, поэтому для дополнительной машины может потребоваться отдельная лицензия. Точные условия уточняйте в лицензионном соглашении вашей поставки — не планируйте инфраструктуру до этой проверки.

Можно ли выносить не все задания, а только конкретные?

Да, для этого служат требования назначения объектов: в правиле указывается информационная база и имя регламентного задания, после чего задаётся сервер-исполнитель. Такие правила имеют приоритет над общими требованиями назначения функциональности.

Что будет, если выделенный сервер выйдет из строя?

Если на других серверах для фоновых заданий стоит «Не назначать», задания остановятся до восстановления сервера. Чтобы обеспечить отказоустойчивость, оставьте на одном из рабочих серверов требование «Авто» вместо жёсткого запрета — тогда кластер сможет временно выполнять задания там.

Работает ли этот механизм в файловом варианте 1С?

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

Нужно ли перезапускать кластер после изменения требований?

Нет, требования назначения применяются без перезапуска службы агента сервера. Однако уже выполняющиеся задания не переносятся — они завершатся на прежнем сервере, а новые запуски пойдут по обновлённым правилам.

Как понять, что проблема именно в фоновых заданиях, а не в СУБД?

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