Часто возникает ситуация, когда в компании куплено лицензий с запасом, например 50, а работает всего 40 пользователей, но система все равно сообщает о нехватке лицензий. Причина оказывается в том, что некоторые сотрудники открывают программу в нескольких окнах или вкладках браузера. Давайте разберемся, почему так происходит и как можно оптимизировать расход лицензий.
Основной вопрос звучит так: если пользователь запустил 2-3 сеанса с одной базой, он занимает 2-3 лицензии?
Короткий ответ — да. При использовании программных лицензий, активированных на сервере «1С:Предприятия», система по умолчанию работает по модели «один сеанс — одна лицензия». Для сервера 1С каждый новый запуск тонкого клиента или открытие новой вкладки веб-клиента — это отдельное подключение (сеанс), требующее своей лицензии. Сервер не анализирует, принадлежат ли эти сеансы одному и тому же человеку. Проанализируем ситуацию и рассмотрим несколько способов решения этой проблемы.
Самый надежный, но и самый затратный способ — изменить то, как лицензии раздаются пользователям. Вместо одного большого пула лицензий на сервере, можно выделить персональные лицензии для самых активных пользователей.
Установка локальных однопользовательских лицензий (вам может пригодиться инструмент для просмотра программных лицензий).
Суть метода в том, чтобы часть лицензий из общего серверного пакета установить непосредственно на компьютеры пользователей, которые чаще всего работают в нескольких окнах («многоокошечники»).
Преимущества:
Недостатки:
Это хорошее компромиссное решение, если у вас есть 5-10 сотрудников, которые являются основной причиной нехватки лицензий.
Если покупка новых лицензий или переход на локальные не вариант, можно доработать конфигурацию, чтобы она сама следила за количеством сеансов. Этот подход требует навыков программирования.
Можно добавить проверку при запуске системы, которая не позволит пользователю открыть второй экземпляр программы.
Посмотрим на алгоритм:
АктивныеСеансыПользователей с полями: Пользователь, Компьютер, ВремяНачалаСеанса, IDСеанса.ПриНачалеРаботыСистемы, прописываем логику:
Процедура ПриНачалеРаботыСистемы()
// Получаем текущие параметры
ТекущийПользователь = ИмяПользователя();
ИмяКомпьютера = ИмяКомпьютера();
// Проверяем, есть ли уже активный сеанс для этой пары Пользователь-Компьютер
// Здесь должна быть функция, которая ищет в нашем регистре сведений
// запись о другом активном сеансе этого же пользователя.
// Важно также предусмотреть очистку "зависших" записей от сеансов,
// которые завершились некорректно.
Если ЕстьАктивныйСеанс(ТекущийПользователь, ИмяКомпьютера) Тогда
// Если сеанс найден, выводим сообщение и блокируем работу
Предупреждение("Вы уже работаете в программе с этого компьютера. Запуск второго сеанса запрещен.");
ЗавершитьРаботуСистемы(Ложь); // Завершаем новый сеанс
Возврат;
КонецЕсли;
// Если дублирующего сеанса нет, записываем информацию о новом сеансе
// в наш регистр сведений.
ЗаписатьНовыйСеанс(ТекущийПользователь, ИмяКомпьютера, ...);
КонецПроцедуры
При завершении работы системы (событие ПриЗавершенииРаботыСистемы) необходимо удалять запись из регистра.
Важный нюанс: как быть с "зависшими" сеансами? Если сеанс завершился аварийно (пропало соединение, выключили свет), запись в регистре останется. Поэтому при входе нового пользователя нужно не просто проверять наличие записи, но и анализировать сеансы на сервере 1С. Если сеанс, указанный в регистре, на самом деле уже неактивен, запись нужно удалить и позволить пользователю войти.
Это более продвинутый и надежный метод. Он заключается в создании регламентного задания, которое будет периодически "прибираться" на сервере, завершая лишние сеансы.
Для этого используется RAS (Remote Administration Server) — сервер администрирования кластера 1С.
Разберем по шагам:
1C:Enterprise 8.3 RAS service.Примерная логика кода может выглядеть так:
// Код выполняется в фоновом задании на сервере
// Укажите данные для подключения к кластеру
АдресRAS = "localhost:1545"; // Порт агента сервера
ИмяКластера = "МойКластер"; // Имя вашего кластера
// Подключаемся к серверу администрирования
RASConnection = Новый COMОбъект("RAS1C.RASConnection");
RASConnection.Connect(АдресRAS);
// Получаем кластер
Кластер = RASConnection.GetClusters().Get(ИмяКластера);
// Получаем список сеансов
ВсеСеансы = Кластер.GetSessions();
// Группируем сеансы по пользователям
// ... код для группировки сеансов ...
// Например, используем структуру, где ключ - имя пользователя,
// а значение - массив его сеансов.
// Проходим по каждому пользователю
Для Каждого Пользователя Из СгруппированныеСеансы Цикл
// Если у пользователя больше одного сеанса
Если Пользователя.Сеансы.Количество() > 1 Тогда
// Сортируем сеансы по времени начала (от старых к новым)
// ... код для сортировки ...
// Удаляем все сеансы, кроме последнего
Для сч = 0 По Пользователя.Сеансы.Количество() - 2 Цикл
СеансДляУдаления = Пользователя.Сеансы[сч];
Кластер.TerminateSession(СеансДляУдаления.SessionID);
КонецЦикла;
КонецЕсли;
КонецЦикла;
Этот метод эффективно борется как с умышленно открытыми дублями, так и с "зависшими" сеансами, освобождая лицензии в автоматическом режиме.
Платформа 1С имеет встроенные механизмы, которые могут помочь, хоть и не решают проблему кардинально.
Завершение сеанса при бездействии.
В настройках информационной базы (в консоли администрирования кластера серверов 1С) можно установить тайм-ауты для неактивных сеансов. Например, если пользователь не совершал никаких действий в программе в течение 60 минут, его сеанс будет автоматически завершен, а лицензия освободится.
Это помогает бороться с ситуациями, когда пользователи уходят домой, оставив 1С открытой. Однако это не поможет, если пользователь активно работает в двух окнах одновременно.
Перезапуск службы агента сервера.
Это довольно радикальный метод, который можно использовать для "очистки" всех зависших сеансов. Настраивается перезапуск службы Агент сервера 1С:Предприятия по расписанию, например, раз в несколько часов в нерабочее время. При перезапуске все активные сеансы будут принудительно завершены. Метод грубый, но иногда эффективный для борьбы с накопленными "зомби"-сеансами.
Проблема "один пользователь — много лицензий" является штатным поведением серверного лицензирования 1С. Выбор решения зависит от ваших ресурсов и специфики работы:
Часто наилучший результат дает комбинация этих методов: например, выделить локальные лицензии самым активным пользователям и настроить регламентное задание для очистки "зависших" сеансов для всех остальных.