При эксплуатации клиент-серверных информационных баз 1С часто возникает задача ограничить количество одновременных подключений. Это может быть связано с лицензионными ограничениями (например, количество купленных рабочих мест), требованиями безопасности или необходимостью снижения нагрузки на сервер. Рассмотрим подробно несколько эффективных способов решения этой задачи, начиная от архитектурных настроек кластера и заканчивая программными методами.
Этот метод является наиболее надежным с точки зрения системного администрирования, так как он позволяет разделить потоки лицензирования на уровне кластера 1С. Проанализируем ситуацию: если у нас есть общий сервер приложений, он раздает лицензии всем базам. Чтобы ограничить конкретную базу, мы можем создать для нее выделенный программный контур.
Разберем этот процесс по шагам:
В современных версиях платформы 1С (начиная с 8.3.7) реализован мощный механизм внешнего управления сеансами. Проанализируем его работу: в свойствах каждой информационной базы в кластере можно указать Адрес внешнего управления сеансами. Это URL-адрес веб-сервиса, к которому сервер 1С будет обращаться при каждой попытке создания сеанса.
Рассмотрим алгоритм взаимодействия:
Это самый гибкий метод, так как он позволяет реализовать сложную логику: например, ограничивать сеансы в зависимости от времени суток, конкретных учетных записей или даже состояния оплаты подписки.
Если база является типовой и мы не хотим вносить изменения в основную конфигурацию, чтобы не усложнять процесс обновления, воспользуемся механизмом расширений. Мы можем перехватить событие начала работы системы и программно проверить количество текущих сеансов. Чтобы дополнительно упростить эксплуатацию подобных систем, можно автоматизировать архивирование и обновление типовых баз 1С по расписанию.
Проанализируем пример кода, который можно разместить в модуле управляемого приложения расширения:
&НаКлиенте
Процедура ПередНачаломРаботыСистемы(Отказ)
// Вызываем серверный метод для подсчета активных сеансов
КоличествоСеансов = ПолучитьТекущееКоличествоСеансовСервер();
МаксимальныйЛимит = 10; // Установите нужное ограничение
Если КоличествоСеансов > МаксимальныйЛимит Тогда
Сообщить("Превышено максимальное количество одновременных подключений к базе (макс: " + МаксимальныйЛимит + ")");
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
На стороне сервера нам необходимо использовать функцию ПолучитьСеансыИнформационнойБазы(). Рассмотрим пример реализации серверной функции:
&НаСервереБезКонтекста
Функция ПолучитьТекущееКоличествоСеансовСервер()
// Получаем массив всех активных сеансов для данной базы
ВсеСеансы = ПолучитьСеансыИнформационнойБазы();
// В ряде случаев нужно отфильтровать фоновые задания,
// чтобы они не занимали пользовательские лимиты
Счетчик = 0;
Для Каждого ТекущийСеанс Из ВсеСеансы Цикл
Если ТекущийСеанс.ИмяПриложения = "1CV8" Или ТекущийСеанс.ИмяПриложения = "1CV8C" Или ТекущийСеанс.ИмяПриложения = "WebClient" Тогда
Счетчик = Счетчик + 1;
КонецЕсли;
КонецЦикла;
Возврат Счетчик;
КонецФункция
Важно: При использовании этого метода нужно учитывать, что сам сеанс уже считается созданным в момент выполнения этого кода, поэтому текущий пользователь всегда входит в число ВсеСеансы.
Когда база опубликована на веб-сервере (например, Apache под Debian), мы можем использовать инструменты самого веб-сервера для ограничения нагрузки. Выясним причину, по которой это эффективно: каждый веб-клиент или тонкий клиент через HTTP создает соединения с процессами веб-сервера.
Мы можем отредактировать файл конфигурации публикации default.vrd или настройки самого Apache. В Apache можно ограничить количество одновременных подключений к конкретному каталогу с помощью модуля mod_limitipconn или через директивы управления процессами:
MaxClients (или MaxRequestWorkers в новых версиях) — ограничивает общее число одновременных запросов..vrd файле позволяет ограничить количество одновременных вызовов к расширению 1С.Однако помните, что этот метод является грубым — он не "выкидывает" пользователя из 1С корректно, а просто блокирует сетевой трафик, что может приводить к зависанию сессий в самой 1С. Для оперативного решения этой проблемы можно использовать веб-приложение для мониторинга и принудительного удаления зависших сеансов 1С.
Для системных администраторов Linux удобным решением будет написание небольшого скрипта на Bash, который будет работать в связке с утилитой rac (Remote Administration Client). Рассмотрим сценарий работы такого скрипта:
cron) запрашивает список сеансов у кластера для конкретной базы: rac session --infobase="ID-базы" list.rac session --infobase="ID-базы" terminate --session="ID-сеанса".Этот метод не предотвращает вход, но позволяет оперативно реагировать на превышение лимитов в автоматическом режиме без изменения программного кода базы. В качестве альтернативы консольной утилите RAC в Linux-окружении можно использовать графическую консоль администрирования кластера 1С под Linux.
Проанализируем ситуацию с файловыми базами, опубликованными через веб-сервер. В данном случае у нас нет кластера 1С и сервера приложений, который мог бы управлять сеансами. Здесь единственным надежным способом (кроме программного кода внутри базы) остается ограничение количества потоков самого веб-сервера.
В настройках Apache для виртуального хоста, где опубликована файловая база, следует жестко ограничить количество рабочих процессов (ThreadsPerChild или MaxConnectionsPerChild), чтобы сумма всех возможных потоков соответствовала вашему лицензионному ограничению. Однако это решение требует тонкой настройки, чтобы не заблокировать работу служебных механизмов платформы.
Резюме: Если база типовая и вы не хотите менять код, лучшим выбором будет Способ 1 (Функциональные требования) или Способ 2 (Внешнее управление). Если вы готовы к минимальной разработке — используйте Способ 3 (Расширения), так как он обеспечивает наиболее дружелюбный интерфейс для конечного пользователя при отказе в доступе.