В процессе администрирования крупных инфраструктур 1С системные администраторы часто сталкиваются с необходимостью развертывания нескольких независимых служб (агентов) сервера 1С на одном физическом сервере или виртуальной машине. Типичный сценарий: на первом сервере крутится высоконагруженная торговая база (например, «1С:Управление торговлей»), требующая стабильной и проверенной версии платформы, а на втором сервере работают конфигурации «1С:Бухгалтерия» или «1С:Зарплата и управление персоналом», которые необходимо оперативно обновлять под меняющееся законодательство, из-за чего приходится регулярно обновлять и версию платформы 1С.
В такой конфигурации неизбежно возникает проблема «зависших» и неактивных сеансов пользователей. Они занимают лицензии, блокируют выполнение регламентных заданий и мешают монопольному обновлению баз данных. Если бы сервер 1С был один, задача решалась бы простым скриптом или обработкой. Но когда серверов два, стандартные методы начинают конфликтовать из-за различия версий платформы и используемых библиотек. В этой статье мы подробно разберем, как элегантно обойти это ограничение и настроить автоматическое завершение сеансов для нескольких разнородных серверов 1С.
Рассмотрим классический способ программного отключения сеансов через встроенный язык 1С. Для этого обычно используется COM-соединение с агентом сервера через объект V83.COMConnector. Нам необходимо подключиться к агенту, получить список кластеров, авторизоваться, найти нужную базу и завершить «спящие» сеансы. Однако здесь возникает главная загвоздка.
Компонента COM-соединителя comcntr.dll регистрируется в операционной системе Windows глобально. При регистрации последней установленной платформы в системном реестре перезаписываются пути к этой DLL. Когда ваше фоновое задание пытается создать объект V83.COMConnector для подключения к серверу старой версии платформы, операционная система все равно пытается вызвать новую версию зарегистрированной библиотеки. Возникает критический конфликт версий, приводящий к ошибкам подключения вида «Несовпадение версий клиента и сервера».
Давайте подробно проанализируем три проверенных способа решения этой проблемы: от классической настройки COM+ до использования утилит администрирования RAS/RAC и встроенных механизмов самой платформы 1С.
Если мы хотим оставить логику завершения сеансов внутри самой системы 1С (например, запускать обработку по расписанию через регламентное задание), нам потребуется использовать COM-соединение. Чтобы решить проблему конфликта версий библиотек, мы настроим изолированные приложения в службе компонентов Windows (COM+).
Этот подход позволяет зарегистрировать разные версии comcntr.dll под уникальными именами (ProgID). Разберем этот процесс по шагам:
dcomcnfg в строке запуска (Win+R).1C_COM_8_3_19) и установите способ активации «Библиотечное приложение» (Library Application).comcntr.dll, который находится в каталоге установки конкретной платформы (например, C:\Program Files\1cv8\8.3.19.XXXX\bin\comcntr.dll).1C_COM_8_3_23 и указав DLL из папки версии 8.3.23).regedit) найдите созданные GUID компонентов и переименуйте их ProgID на уникальные, например V83.COMConnector.19 и V83.COMConnector.23.После проведения этих настроек мы можем безопасно обращаться к конкретной версии COM-соединителя прямо из кода 1С. Рассмотрим пример программного кода, который подключается к нужному агенту сервера, находит неактивные сеансы и завершает их:
// Выбираем нужный COM-соединитель в зависимости от обслуживаемой базы
Соединитель = Новый COMОбъект("V83.COMConnector.19");
// Подключаемся к агенту конкретного сервера (указываем адрес и порт)
СоединениеСАгентом = Соединитель.ConnectAgent("localhost:1540");
Кластеры = СоединениеСАгентом.GetClusters();
Для Каждого Кластер Из Кластеры Цикл
// Проводим авторизацию в кластере
СоединениеСАгентом.Authenticate(Кластер, "", "");
// Получаем список информационных баз в кластере
БазыДанных = СоединениеСАгентом.GetInfoBases(Кластер);
Для Каждого ТекущаяБаза Из БазыДанных Цикл
// Проверяем, что работаем с целевой базой данных
Если ВРег(ТекущаяБаза.Name) = ВРег("Trade_Prod") Тогда
// Получаем все активные сеансы информационной базы
Сеансы = СоединениеСАгентом.GetInfoBaseSessions(Кластер, ТекущаяБаза);
ТекущееВремя = ТекущаяДата();
Для Каждого Сеанс Из Сеансы Цикл
// Исключаем фоновые задания и системные подключения
Если Сеанс.AppID = "1CV8" Или Сеанс.AppID = "1CV8C" Тогда
// Вычисляем время простоя в секундах (например, 2 часа = 7200 секунд)
ВремяБездействия = ТекущееВремя - Сеанс.LastActiveAt;
Если ВремяБездействия > 7200 Тогда
// Завершаем неактивный или зависший сеанс пользователя
СоединениеСАгентом.TerminateSession(Кластер, Сеанс);
КонецЕсли;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецЦикла;
КонецДля;
Важное примечание: Динамическая регистрация библиотек через вызов утилиты regsvr32 непосредственно перед выполнением кода (как предлагали некоторые участники в Сообщении №8) крайне не рекомендуется на рабочих серверах. Операционная система Windows кэширует запущенные COM-процессы в службе dllhost.exe. Из-за этого принудительное перерегистрирование библиотек без перезапуска процессов кэша (или без опасной команды taskkill /f /im dllhost.exe) все равно приведет к падению сессий или обращению к неверной версии DLL.
Самым надежным, масштабируемым и независимым от Windows-специфики методом является администрирование через связку утилит RAS (Remote Administration Server) и RAC (Remote Administration Client). Этот инструмент поставляется фирмой 1С штатно и не зависит от COM-технологий, разрядности операционной системы или кэширования библиотек.
Для каждого из двух установленных серверов 1С запускается своя служба RAS. Каждая служба жестко привязана к конкретной версии платформы и слушает свой сетевой порт (например, сервер №1 слушает порт 1545, а сервер №2 — порт 2545).
Давайте настроим автоматизацию с помощью внешнего скрипта. Мы можем написать сценарий на OneScript, PowerShell или простом CMD-файле и запускать его через Планировщик задач Windows. Рассмотрим логику работы такого скрипта по шагам:
rac.exe из каталога нужной версии платформы.Пример команды для получения списка сессий через консоль:
rac session --cluster=<ID_Кластера> list --infobase=<ID_Базы> localhost:1545
Пример команды для принудительного удаления зависшей сессии:
rac session --cluster=<ID_Кластера> terminate --session=<ID_Сеанса> localhost:1545
Этот способ полностью исключает конфликты платформ на уровне операционной системы, так как обращение идет по сетевым сокетам напрямую к службе администрирования соответствующей версии.
Если ваши конфигурации работают на современных версиях платформы «1С:Предприятие», у нас есть отличная новость: разработчики фирмы 1С внедрили долгожданные встроенные механизмы борьбы с «зависшими» и неактивными пользователями.
Рассмотрим два важнейших механизма, которые избавляют от необходимости писать сложные внешние скрипты:
Давайте посмотрим, какие параметры мы можем настроить напрямую в интерфейсе системы без программирования:
Подводя итог, выберем оптимальную стратегию работы в зависимости от вашей текущей архитектуры:
Если ваши базы данных развернуты на старых версиях платформ (ниже 8.3.26), используйте Решение №2 (RAS/RAC) как наиболее стабильное и не подверженное системным сбоям Windows. Если по соображениям безопасности или архитектуры вы обязаны запускать очистку сеансов регламентным заданием изнутри самой 1С, настройте изоляцию библиотек в среде COM+ (Решение №1).
Если же вы планируете переход или уже работаете на современных версиях платформы (8.3.26+), обязательно задействуйте Решение №3 (Встроенные механизмы). Это позволит отказаться от костылей, внешних скриптов и сторонних утилит, переложив задачу контроля активности пользователей на саму платформу 1С.