Как настроить запуск регламентного задания 1С на конкретном сервере кластера?

← На главную

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

Проанализируем ситуацию: у нас есть кластер из двух или более рабочих серверов. Мы хотим, чтобы фоновое задание, например, по сложной обработке данных, выполнялось исключительно на SERVER-02, а SERVER-01 в это время продолжал обслуживать пользователей без дополнительной нагрузки. Попытки указать имя сервера в свойствах задания часто не дают нужного эффекта, так как планировщик заданий 1С может перераспределять задачи по своему усмотрению. Рассмотрим надежный способ решения этой задачи.

Основное решение: проверка имени сервера внутри кода задания

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

Разберем по шагам, как это реализовать.

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

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

Написание кода с проверкой

Теперь напишем сам код. В качестве примера создадим процедуру ВыполнитьСложныеРасчетыНаВыделенномСервере.


Процедура ВыполнитьСложныеРасчетыНаВыделенномСервере(Ключ) Экспорт
    
    // Имя целевого сервера, на котором должно выполняться задание.
    // Это имя должно точно соответствовать сетевому имени сервера.
    ИмяЦелевогоСервера = "SERVER-02";
    
    // Получаем имя компьютера, на котором в данный момент выполняется код.
    ИмяТекущегоСервера = ИмяКомпьютера();
    
    // Сравниваем имена серверов. 
    // Важно: используем функцию ВРЕГ() или НРЕГ() для регистронезависимого сравнения,
    // чтобы избежать ошибок из-за разного написания имени сервера (например, "server-02" и "SERVER-02").
    Если ВРег(ИмяТекущегоСервера) <> ВРег(ИмяЦелевогоСервера) Тогда
        
        // Если мы находимся не на целевом сервере, просто завершаем процедуру.
        // Основной код задания не будет выполнен.
        Возврат;
        
    КонецЕсли;
    
    // ===================================================================
    // ЗДЕСЬ НАЧИНАЕТСЯ ОСНОВНОЙ КОД ВАШЕГО РЕГЛАМЕНТНОГО ЗАДАНИЯ
    // Этот блок кода выполнится ТОЛЬКО на сервере "SERVER-02"
    // ===================================================================
    
    // ...
    // Например, выполнение тяжелых запросов, формирование отчетов, обмен данными и т.д.
    // ...
    
    ЗаписьЖурналаРегистрации("Регламентное задание",
                            УровеньЖурналаРегистрации.Информация, , ,
                            "Сложные расчеты успешно выполнены на сервере " + ИмяТекущегоСервера);
                            
КонецПроцедуры

Разбор ключевых моментов кода
Рассмотрим подробнее, что делает каждая часть этого кода:
- Процедура ... (Ключ) Экспорт: Сигнатура процедуры. Экспорт делает ее доступной для вызова извне модуля, а параметр Ключ необходим для того, чтобы платформа могла корректно запустить задание и передать в него служебную информацию.
- ИмяКомпьютера(): Это встроенная функция языка 1С. Когда она выполняется в серверном контексте (что и происходит в регламентном задании), она возвращает сетевое имя компьютера, на котором работает данный рабочий процесс (rphost). Это именно то, что нам нужно для идентификации сервера.
- Если ВРег(ИмяТекущегоСервера) <> ВРег(ИмяЦелевогоСервера) Тогда ...: Это ядро нашего решения. Мы сравниваем текущее имя сервера с тем, которое мы задали как целевое. Очень важно использовать функции приведения к одному регистру (ВРег, НРег, Верх, Низк), так как в разных местах операционной системы или настроек 1С имя сервера может быть указано в разном регистре.
- Возврат;: Этот оператор немедленно прекращает выполнение процедуры. Если условие в Если истинно (то есть мы не на целевом сервере), то основной полезный код задания просто не будет выполнен. При этом с точки зрения планировщика задание отработает штатно, без ошибок.
Настройка регламентного задания
После того как код готов, остается только настроить само регламентное задание в конфигураторе. В свойстве задания Имя метода укажите имя вашей процедуры в формате ИмяОбщегоМодуля.ИмяПроцедуры. В нашем примере это будет МоиОбщиеМодули.ВыполнитьСложныеРасчетыНаВыделенномСервере.

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

Что важно помнить?

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

Настройки в консоли кластера: В консоли администрирования серверов 1С у регламентных заданий есть свойство "Требуется назначение" и возможность указать предпочтительный сервер. Эти настройки работают иначе. Они скорее являются рекомендацией для планировщика и не дают стопроцентной гарантии, что задание не будет запущено на другом сервере, если предпочтительный будет недоступен или перегружен. Программная проверка лишена этого недостатка.
Отказоустойчивость: Продумайте, что должно произойти, если ваш целевой сервер SERVER-02 станет недоступен. В представленном варианте задание просто не будет выполняться нигде. Если требуется обеспечить выполнение на резервном сервере, можно усложнить логику проверки, добавив список допустимых серверов с приоритетами.

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

← На главную