← На главную

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

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

Выясним причину некорректного распределения фоновых заданий

Проанализируем основные ошибки, которые приводят к тому, что фоновые задания игнорируют созданные правила распределения:

1. Не применены требования назначения функциональности: создание или изменение правил в консоли администрирования кластера не вступает в силу автоматически. После любых изменений необходимо явно выполнить команду применения требований. Обычный перезапуск службы кластера или ОС не всегда корректно перестраивает текущую схему распределения сервисов.
2. Неверно выбран объект требования: частая ошибка — назначение только объекта Сервис фоновых заданий. Данный сервис отвечает исключительно за управление расписанием и регистрацию заданий, но не исполняет их программный код. Непосредственное выполнение кода фонового задания происходит в рабочем процессе через соединение, поэтому настраивать нужно объект Клиентское соединение с ИБ.
3. Отсутствуют или некорректно заданы дополнительные параметры: фоновые задания запускаются с определенными типами инициализации. Если не указать дополнительный параметр, кластер применит правило ко всем клиентским сеансам без разбора.
4. Неправильный порядок правил в списке: проверка требований назначения функциональности выполняется кластером сверху вниз до первого совпадения. Если вверху списка расположено общее разрешающее правило, более специфичные правила ниже по списку просто не сработают.

Разберем по шагам правильную настройку требований назначения функциональности

Рассмотрим порядок настройки для сценария, при котором в кластере есть как минимум два рабочих сервера: Сервер_Фоновые (выделенный под регламентную нагрузку) и Сервер_Пользователи (для работы пользователей).

1. Настроим целевой сервер для фоновых заданий (Сервер_Фоновые):

   В свойствах рабочего сервера в ветке «Требования назначения функциональности» добавим правила в следующем порядке:

   1. Объект требования: Клиентское соединение с ИБ, Дополнительный параметр: BackgroundJob.ScheduledJob, Тип требования: Назначать. Это правило направляет регламентные задания на данный сервер.
   2. Объект требования: Клиентское соединение с ИБ, Дополнительный параметр: BackgroundJob.CommonModule, Тип требования: Назначать. Это правило переносит программные фоновые задания, запущенные через вызов ФоновыеЗадания.Выполнить().
   3. Объект требования: Любой объект требования, Дополнительный параметр: (пусто), Тип требования: Не назначать. Это правило запрещает запуск интерактивных пользовательских сеансов и других сервисов на выделенном сервере.
2. Настроим основные рабочие серверы (Сервер_Пользователи):

   Чтобы исключить выполнение тяжелых задач на серверах, где работают пользователи, добавим правила:

   1. Объект требования: Клиентское соединение с ИБ, Дополнительный параметр: BackgroundJob.ScheduledJob, Тип требования: Не назначать.
   2. Объект требования: Клиентское соединение с ИБ, Дополнительный параметр: BackgroundJob.CommonModule, Тип требования: Не назначать.
   3. Объект требования: Любой объект требования, Дополнительный параметр: (пусто), Тип требования: Авто (или Назначать). Это правило разрешает выполнение всех остальных функций кластера.

Применение требований: полное и частичное применение

После добавления и проверки порядка правил обязательно применим обновленную конфигурацию. В контекстном меню кластера серверов доступны два варианта применения:

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

Важные особенности и лицензионные требования

Проанализируем технические ограничения, о которых необходимо помнить при внедрении требований назначения функциональности:

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