Часто в практике администрирования «1С:Предприятие» возникает классическая задача распределения ресурсов: на сервере крутятся несколько информационных баз (например, «1С:Бухгалтерия предприятия» и «1С:Управление торговлей»), и имеется общий пул программных лицензий (допустим, 10 штук). Нам необходимо жестко зафиксировать лимиты: сделать так, чтобы пользователи Бухгалтерии могли занять не более 3 лицензий, а пользователи Управления торговлей — остальные 7.
По умолчанию сервер 1С раздает лицензии из общего пула хаотично, по мере обращения пользователей. В этой статье мы подробно разберем пять практических методов решения этой задачи — от простых программных ограничений до сложных системных настроек на уровне кластера и операционной системы.
Это наиболее красивый и системный способ разделения лицензий на уровне платформы «1С:Предприятие». Однако стоит помнить, что полноценная фильтрация по имени информационной базы в требованиях назначения функциональности официально требует наличия корпоративных лицензий (КОРП). Если у вас ПРОФ-лицензии, этот механизм может работать с ограничениями.
Суть метода заключается в разнесении лицензий по разным рабочим серверам (хостам) одного кластера и принудительном закреплении баз за конкретными сервисами лицензирования. Разберем этот процесс по шагам:
Назначать, объект требования — Сервис лицензирования, а в поле «Имя ИБ» указываем имя нашей базы Бухгалтерии.Благодаря этой настройке, кластер при запросе лицензии для Бухгалтерии будет обращаться строго к первому серверу, а для УТ — ко второму, гарантируя соблюдение заданных лимитов.
Если мы работаем на лицензиях ПРОФ и не имеем возможности разворачивать многосерверный кластер, отличным выходом станет программное ограничение количества одновременно открытых сеансов. Чтобы не снимать типовые конфигурации с поддержки, реализуем это решение с помощью механизма расширений (файлы формата .cfe).
Проанализируем логику работы расширения. Нам нужно перехватить событие запуска системы и проверить текущее количество активных сеансов для данной базы. Выясним, как выглядит пример кода, который мы можем поместить в модуль расширения:
Процедура ПередНачаломРаботыСистемы(Отказ)
// Задаем лимит подключений для текущей базы
МаксимальныйЛимитСеансов = 3;
// Получаем список активных соединений информационной базы
ТекущиеСоединения = ПолучитьСоединенияИнформационнойБазы();
КоличествоАктивныхСеансов = 0;
Для Каждого Соединение Из ТекущиеСоединения Цикл
// Исключаем из подсчета фоновые задания и конфигуратор
Если Соединение.ИмяПриложения = "1CV8" Или Соединение.ИмяПриложения = "1CV8C" Тогда
КоличествоАктивныхСеансов = КоличествоАктивныхСеансов + 1;
КонецЕсли;
КонецЦикла;
// Проверяем превышение лимита
Если КоличествоАктивныхСеансов > МаксимальныйЛимитСеансов Тогда
ПоказатьПредупреждение(, "К сожалению, все свободные лицензии для этой базы заняты. Попробуйте войти позже.");
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Важное примечание: При подсчете активных сеансов обязательно отсекайте служебные фоновые задания, иначе регламентные процедуры платформы будут постоянно блокировать вход обычным пользователям. Данный метод хорош тем, что лимиты (например, 3 и 7) можно хранить в константах или специальном регистре сведений прямо внутри расширения и оперативно менять их без доработки кода.
Рассмотрим ситуацию, когда пользователи подключаются к информационным базам через тонкий клиент или веб-браузер по протоколам HTTP/HTTPS. В этом случае мы можем полностью отказаться от программирования в 1С и перенести задачу контроля лимитов на веб-сервер.
Разберем алгоритм настройки на примере веб-сервера Microsoft IIS:
Максимальное количество рабочих процессов или настроим лимиты одновременных подключений в свойствах самого сайта/виртуального каталога, установив значение равным 3.При таком подходе веб-сервер физически не пропустит лишние запросы к конкретной публикации, выдавая пользователям стандартную ошибку загрузки страницы при превышении лимита, а лицензии 1С будут расходоваться строго в рамках этих ограничений.
Если ваши базы файловые, а пользователи работают в терминальном режиме (RDP) на одном сервере, платформа по умолчанию ищет файлы лицензий (с расширением .lic) в общей папке C:\ProgramData\1C\licenses. Из-за этого лицензии достаются тем, кто успел запустить программу первым.
Мы можем обойти это поведение с помощью разграничения прав доступа NTFS в операционной системе Windows. Посмотрим, как это настроить:
Группа_Бухгалтерия и Группа_Продажи.C:\1C_Licenses\Buh и C:\1C_Licenses\Trade).Buh (вкладка «Безопасность») заберем права на чтение у всех пользователей, кроме администраторов и участников группы Группа_Бухгалтерия. Поместим туда файл лицензии на 3 пользователя.Trade сделаем то же самое, но доступ разрешим только группе Группа_Продажи. Поместим туда файл лицензии на 7 пользователей.1cescmn.cfg в каталоге установки 1С для каждой группы пользователей, прописав в них параметр DistTabs, указывающий на соответствующую папку с лицензиями.Теперь пользователи из отдела продаж физически не смогут перехватить лицензии бухгалтеров, так как у их учетных записей Windows просто не будет прав на чтение файлов лицензий из "бухгалтерской" папки.
Начиная с версии платформы 1С 8.3.18, администраторам доступен новый инструмент — Автономный сервер 1С. Это легковесная альтернатива полноценному кластеру серверов.
Мы можем развернуть два независимых экземпляра автономного сервера на одном физическом компьютере, назначив им разные сетевые порты. Каждому экземпляру в его файле конфигурации мы жестко прописываем путь к конкретному файлу программной лицензии. Один сервер будет обслуживать базу Бухгалтерии и распоряжаться пулом из 3 лицензий, а второй — базу УТ с пулом из 7 лицензий. Это современный и надежный способ изоляции ресурсов без необходимости покупки дорогостоящих лицензий КОРП.