← На главную

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

Понимание архитектуры системы СЛК

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

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

Почему лицензии тратятся при каждом запуске?

Рассмотрим ключевые причины такого поведения:

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

Как управлять лицензиями и что делать администратору

Чтобы лучше понимать, куда уходят лицензии, воспользуемся инструментарием, встроенным в сервер СЛК:

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

Тайм-аут возврата лицензий: Важно помнить, что при закрытии 1С лицензия не всегда возвращается в пул мгновенно. Существует понятие «тайм-аут возврата лицензии». Если пользователь часто открывает и закрывает базы, лицензии могут оставаться «занятыми» на сервере в течение определенного времени, даже если процесс 1С уже завершен.

Рекомендации по оптимизации

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

• Анализ потребностей: Если ваша работа предполагает частое открытие нескольких баз одновременно, необходимо рассчитать общее количество лицензий исходя из формулы: Максимальное количество баз умножить на Количество пользователей.
• Мониторинг через консоль: Всегда проверяйте текущее состояние через консоль сервера СЛК. Это поможет понять, является ли расход лицензий обоснованным (реально запущенные базы) или результатом зависших сессий.
• Информирование пользователей: Обучите пользователей закрывать неиспользуемые базы, чтобы освобождать лицензии для коллег, так как система защиты не всегда корректно определяет «активность» окна 1С.

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