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

При масштабировании систем на базе 1С:Предприятие 8.3 часто возникает задача оптимизации ресурсов. Одной из наиболее эффективных методик является разделение нагрузки: выделение одних серверов под работу пользователей (клиентские соединения), а других — под тяжелые фоновые процессы. Однако при настройке требований назначения функциональности (ТНФ) администраторы часто сталкиваются с тем, что задания продолжают выполняться «где придется» или вовсе зависают — для контроля таких ситуаций есть мониторинг регламентных заданий с уведомлением в Telegram. Разберем пошагово, как правильно сконфигурировать кластер и избежать типичных ошибок.

Анализируем механизмы распределения нагрузки

Для начала проанализируем ситуацию: в кластере имеется несколько серверов (например, srv1, srv2 и srv3). Наша цель — сделать так, чтобы srv3 занимался только фоновыми задачами, а srv1 и srv2 обслуживали только пользователей. Основной инструмент для этого — консоль администрирования кластера и настройка требований назначения функциональности — для этой задачи отлично подойдёт удобная консоль администрирования кластера серверов 1С.

Важно понимать, что в терминах платформы 1С фоновые задания делятся на разные типы в зависимости от способа их запуска. Если мы укажем только один параметр, часть заданий может игнорировать наши правила. Основными параметрами (дополнительными значениями) для объекта Клиентское соединение с ИБ являются:

• BackgroundJob.CommonModule — фоновые задания, запускаемые программно из кода (например, через ФоновыеЗадания.Выполнить).
• BackgroundJob.ScheduledJob — регламентные задания, настроенные в конфигурации или через консоль (например, автоматическая загрузка курсов валют) — для удобной работы с ними есть обработка управления регламентными и фоновыми заданиями.

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

Рассмотрим порядок действий для сервера srv3, который должен стать целевым для фоновых процессов. Чтобы он принимал задания, нам нужно создать два разрешающих требования. Посмотрим на пример настройки:

Требование №1 (для программных вызовов):

• Объект требования: Клиентское соединение с ИБ
• Тип требования: Назначать
• Имя ИБ: не указывается (для всех баз)
• Значение дополнительного параметра: BackgroundJob.CommonModule

Требование №2 (для регламентных заданий):

• Объект требования: Клиентское соединение с ИБ
• Тип требования: Назначать
• Имя ИБ: не указывается
• Значение дополнительного параметра: BackgroundJob.ScheduledJob

Без второго пункта задания, инициированные планировщиком (регламентные), будут по-прежнему распределяться на другие серверы кластера, так как для них srv3 не будет иметь приоритета.

Ограничение клиентских серверов

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

На серверах srv1 и srv2 добавим следующие правила:

Объект: Клиентское соединение с ИБ
Тип: Не назначать
Доп. параметр: BackgroundJob.CommonModule

Объект: Клиентское соединение с ИБ
Тип: Не назначать
Доп. параметр: BackgroundJob.ScheduledJob

После внесения изменений в консоль управления кластером крайне важно выполнить команду «Применить требования назначения функциональности» (желательно полное применение). В некоторых случаях для корректной инициализации новых правил на уровне рабочих процессов rphost требуется перезапуск службы 1C:Enterprise 8.3 Server Agent.

Почему задания могут «виснуть» или не выполняться

Проанализируем ситуацию, когда требования настроены верно (задания «уходят» на srv3), но фактически не выполняются, оставаясь в статусе «Активно» бесконечно долго. Рассмотрим основные причины:

1. Сетевая доступность: Сервер srv3 должен иметь беспрепятственный доступ к серверу СУБД (SQL) и менеджеру кластера по всем рабочим портам (диапазон 1560-1591 по умолчанию). Если порт закрыт, рабочий процесс на srv3 не сможет инициализировать сеанс.
2. Лицензирование: Каждый рабочий сервер в кластере должен «видеть» программные или аппаратные лицензии. Если на srv3 нет доступа к ключу защиты, фоновое задание не запустится, так как для него не удастся выделить лицензию.
3. Права доступа Windows: Служба 1С на srv3 может быть запущена под другой учетной записью или не иметь доступа к сетевым ресурсам (шарам), темпам или внешним компонентам, которые используются в коде фонового задания.
4. Проблема маршалинга (сериализации): При выполнении ФЗ на другом сервере происходит передача данных. Если в параметрах задания передаются объекты, которые невозможно сериализовать в XDTO (например, специфические COM-объекты), задание может завершиться ошибкой или зависнуть при попытке передачи результата обратно.

Рекомендации по обслуживанию кэша

Выясним, что делать, если настройки ТНФ не подхватываются. Иногда менеджер кластера хранит старую карту распределения ресурсов в кэше. В такой ситуации рекомендуется:

• Остановить службу сервера 1С.
• Очистить папку snccntxt в каталоге данных сервера (обычно в srvinfo).
• Запустить службу заново.

Помните, что использование выделенного сервера для фоновых заданий — это мощный инструмент оптимизации производительности, но он требует тщательного контроля за идентичностью программного окружения на всех узлах кластера. Если на srv1 установлена какая-то библиотека или драйвер, а на srv3 ее нет — фоновые задания, использующие этот функционал, работать не будут. Для своевременного выявления сбоев в работе фоновых процессов пригодится мониторинг фоновых заданий с уведомлением в Telegram.