В 1С не хватает лицензий: как посчитать подключения и найти лишние сеансы

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

Что значит «нет свободных лицензий» и почему лицензий часто хватает

Эту заявку я получаю в десятке самых частых. Утром бухгалтер звонит: «1С не пускает, пишет, что нет свободной лицензии». Директор сразу думает про деньги: нас стало больше, надо докупать. Я прошу его подождать десять минут. За эти десять минут в большинстве случаев становится ясно, что людей в базе работает на семь человек меньше, чем сеансов. Если вам нужна помощь с базами и серверной частью, у нас есть настройка 1С на сервере с PostgreSQL, но саму диагностику лицензий вы вполне можете сделать сами по этой статье.

Сначала важно понять, что именно вы видите. Сообщение «нет свободных лицензий» означает, что платформа нашла источник лицензий, но все места в нём заняты. Это принципиально отличается от ситуации, когда лицензия вообще не найдена: не виден сервер лицензий, не вставлен ключ, слетела привязка программной лицензии после замены железа. Второй случай я разбирал отдельно, в статье про программные ключи и сервер лицензий. Здесь речь только о первом: лицензии есть, но их съели.

Отсюда и порядок действий, который я держу в голове. Первым делом считаем, сколько сеансов занято и кем. Вторым — определяем, какие из них настоящие. Третьим — аккуратно освобождаем лишние. И только четвёртым шагом, если после уборки пик всё равно упирается в потолок, говорим о покупке. Когда этот порядок нарушают, получаются два типичных сценария: докупили десять лицензий, а проблема осталась, потому что виноват один зависший сеанс-интеграция; или, наоборот, годами выгоняли людей из базы, хотя компания давно выросла.

Не делайте одного: не перезапускайте сервер 1С «чтобы всё сбросилось». Да, сеансы пропадут и лицензии освободятся. Но вы получите прерванные проводки у тех, кто работал в этот момент, и ровно ту же картину через три дня, потому что причина осталась на месте.

Как посчитать занятые лицензии: один сеанс — одна лицензия

Базовое правило сформулировано в руководстве администратора 1С: один сеанс — одна лицензия. Не один пользователь, а один сеанс. Если сотрудник открыл базу с рабочего компьютера и забыл об этом, а потом зашёл с ноутбука в переговорке, он занял два места. Для клиент-серверной базы это нормальная работа лицензирования, а не сбой. Именно из-за него число людей в офисе и число занятых лицензий расходятся.

Теперь о том, что считается отдельным потребителем. Исключение из правила — локальная защита: с локальным ключом HASP или однопользовательской программной лицензией на компьютере, к которому она привязана, можно запускать сколько угодно копий клиента. Терминальный сеанс считается одним рабочим местом: для многопользовательского ключа через менеджер лицензий — по сеансу, для программной лицензии место определяется номером сеанса Windows. Веб-клиент и тонкий клиент через веб-сервер занимают по лицензии на сеанс. COM-соединение ищет лицензию в определённом порядке: локальные клиентские, затем локальные серверные, затем сетевые и в конце клиентские лицензии на сервере 1С или веб-сервере. Отдельно в вопросах и ответах 1С подчёркнуто: средства, которые уменьшают число пользователей, напрямую обращающихся к 1С, не уменьшают число нужных лицензий. Иначе говоря, обмен через промежуточный сервис не делает его бесплатным.

С веб-сервисами будьте осторожны. В руководстве администратора сказано, что для них клиентские лицензии не нужны, но в клиент-серверном режиме нужна серверная. А в ответах на частые вопросы по лицензированию написано, что каждый одновременный пользователь, который обращается к информационной базе, должен иметь отдельную клиентскую лицензию. Формулировки отличаются, и я бы не стал решать этот вопрос по догадке: если у вас много интеграций с сайтом или кассами, спросите у поставщика лицензий письменно и сохраните ответ.

Для аппаратных ключей есть ещё один способ посмотреть реальную картину. В руководстве упомянут монитор Aladdin: лицензии, у которых в столбце Timeout стоит 0, считаются занятыми. Это относится к ключам HASP, программные лицензии так не смотрят, их состояние видно в консоли кластера, о которой дальше.

• один сеанс — одна лицензия, пользователи и компьютеры сами по себе не считаются
• терминальный сеанс — одно рабочее место
• локальный ключ или однопользовательская программная лицензия — сколько угодно копий клиента на этом компьютере
• COM-соединение и интеграции тоже потребляют места, и посредник их не отменяет
• по веб-сервисам правила читаются неоднозначно: проверяйте у поставщика лицензий

Где посмотреть занятые лицензии: консоль кластера и rac

Самое надёжное место для клиент-серверной базы — консоль администрирования серверов 1С:Предприятия. Раскрываете нужный кластер, переходите в ветку «Сеансы» либо в «Информационные базы» и выбираете базу. Вы увидите список сеансов: информационная база, номер сеанса, время начала, последняя активность, компьютер, пользователь, приложение, язык, рабочий сервер, порт, процесс ОС, соединение и статистика вызовов. В свойствах сеанса есть поле «Лицензия», там показано, какая именно клиентская лицензия используется этим сеансом. Это поле я смотрю, когда нужно понять, какой из источников (ключ или программная лицензия) раздаёт места.

Список надо отсортировать по пользователю и по времени последней активности. Два сеанса одного человека видны сразу. Сеанс, у которого последняя активность была вчера вечером, а запущен он с вашего терминального сервера, почти наверняка висит после обрыва соединения. Приложение в списке тоже говорит многое: обычный клиент, веб-клиент, Конфигуратор, COM-соединение, фоновое задание. Если вам нужна полная картина по работе консоли и служб, у меня есть отдельный материал про управление кластером через rac.

Если консоль под рукой не всегда, можно работать из командной строки. Утилита rac ходит на сервер администрирования ras. По умолчанию ras слушает порт 1545, а агент кластера, если не указать иначе, ищется на localhost:1540. Запуск, как он описан в руководстве:

./ras cluster --daemon --port=1545 localhost:1540

Дальше узнаём идентификатор кластера и смотрим сеансы. Подкоманды такого вида встречаются в практике администраторов 1С, но точный набор параметров зависит от версии платформы, поэтому сверьтесь со справкой на своём сервере (rac help session):

rac cluster list
rac session --cluster=<идентификатор кластера> list

Если кластер защищён паролем администратора, rac потребует аутентификацию, и тогда добавляются параметры --cluster-user и --cluster-pwd. Без них вы получите ошибку о том, что администратор кластера не аутентифицирован. Для регулярных проверок такую команду удобно завернуть в скрипт и отдавать результат в мониторинг. У нас так сделано в мониторинге 1С в Zabbix: считаем число сеансов и сравниваем с числом лицензий, чтобы узнать о проблеме раньше пользователей.

Какие сеансы лишние и как их безопасно завершить

В моей практике лишние сеансы делятся на пять семейств, и у каждого своя причина. Первое — зависшие сеансы после обрыва RDP. Человек закрыл крышку ноутбука, сеть пропала, терминальный сеанс остался в состоянии «отключён», а вместе с ним остался клиент 1С. Второе — дубли: один сотрудник работает с двух устройств. Третье — забытый Конфигуратор. Разработчик или сопровождающий открыл базу в режиме конфигуратора вечером в пятницу и ушёл. Четвёртое — интеграции: обмен с сайтом, кассами, банком через COM или веб-сервисы, каждая такая сессия занимает место на всё время работы. Пятое — тестовые подключения подрядчиков, о которых давно забыли.

Как завершать. Выберите сеанс в консоли и используйте команду «Удалить» из контекстного меню. В руководстве есть прямое предупреждение: завершение активного пользовательского сеанса может привести к потере данных, а выполнить его может только администратор кластера. Поэтому перед удалением смотрю на последнюю активность и, если человек может быть в середине документа, сначала звоню ему. С сеансами в состоянии «отключён» и ночными сеансами этого не требуется. Через rac то же самое делается подкомандой terminate с идентификатором сеанса, но параметры сверяйте со справкой своей версии.

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

Для постоянного решения у платформы теперь есть встроенный механизм. В версии 8.3.26 появилась возможность завершать сеансы после периода бездействия клиента, заданного администратором, с предупреждением и обратным отсчётом, после которого пользователь может нажать «Продолжить». Настройка находится в параметрах информационной базы. Помните оговорку: при завершении по таймауту несохранённые данные теряются, так что время ставьте с запасом и объясните сотрудникам, что это не сбой. На более старых платформах такой функции нет, и тогда выручают политики Windows на отключённые сеансы RDS и аккуратные регламентные скрипты. По этой теме у нас есть материал про терминальные кластеры 1С.

• RDP-сеанс «отключён», а клиент 1С в нём ещё жив: завершать после проверки активности
• два сеанса одного пользователя: оставить рабочий, второй закрыть
• Конфигуратор, открытый ночью или на выходных: спросить владельца и закрыть
• сервис обмена или интеграция: не убивать вслепую, сначала выяснить владельца
• подключения подрядчиков: закрыть и отозвать доступ

Разбор: «ОргГрад», 40 рабочих мест и 30 лицензий

Организационный консалтинг «ОргГрад»: 40 рабочих мест, из них в 1С одновременно работает не больше 25 человек. Лицензий куплено на 30 одновременных пользователей (комплект 20 и 10). Платформа 8.3.24, клиент-серверный вариант, база на PostgreSQL, пользователи заходят через терминальный сервер. Жалоба: по понедельникам около девяти утра часть сотрудников получает «нет свободных лицензий», и директор уже готов был заказывать ещё десять.

Я зашёл в консоль кластера в 9:10, пока ошибка воспроизводилась. В базе было ровно 30 сеансов. Разобрал их по пользователям и приложениям. Настоящих людей оказалось 22. Ещё 5 сеансов висели от сотрудников, у которых RDP был в состоянии «отключён» с пятницы: люди уходили, не выходя из системы, и терминальный сервер держал сеансы. Два места занимали два окна Конфигуратора, оставленные подрядчиком в пятницу вечером: Конфигуратор тоже потребляет клиентскую лицензию. Ещё одно место съедал сервис обмена с сайтом, который по ошибке подключался как обычный клиент и не закрывал соединение.

Сделали три вещи. Сеансы RDP в состоянии «отключён» закрыли и ограничили срок их жизни политикой на терминальном сервере. Подрядчику вернули порядок: Конфигуратор только по заявке и только в рабочее окно. Обмен с сайтом перевели на отдельную учётную запись и ограничили его время жизни, а потом сверили с поставщиком, на каком основании он занимает место. На всё ушло два рабочих дня плюс неделя наблюдения. В итоге пик на следующей неделе составил 26 сеансов из 30, и запас в четыре места закрыл рост штата на ближайший год.

Докупка в итоге не потребовалась, но я не считаю это универсальным выводом. Если бы после уборки пик стоял на 30, пришлось бы считать ресурсы дальше. Тут помогает ещё одна находка того же клиента: мы настроили в Zabbix простой триггер на число сеансов, и теперь директор видит запас заранее, а не в понедельник по звонку. Как читать нагрузку на такую базу, я писал в разборе терминального сервера под 1С для бухгалтерии.

Что делать, если после чистки лицензий всё равно не хватает

Бывает и так: вы всё выгнали, пик по-прежнему упирается в потолок. Тогда посчитайте честно. Возьмите две недели наблюдений за числом одновременных сеансов в рабочие часы, исключите технические (конфигураторы, интеграции, которые можно перевести на экономные схемы) и сравните максимум с числом лицензий. Если максимум стабильно выше 90 процентов лицензий, запас нужен. Лицензии покупают комплектами, и их нельзя делить. По разъяснениям 1С, обмен (например, комплектов на 5 и на 10 пользователей на один на 20) делается через партнёра и только для аппаратных ключей, стоимость возвращаемых лицензий засчитывается. С программными лицензиями обмен не нужен: вы просто докупаете ещё одну, а с платформы 8.2 ключи и программные лицензии могут работать вместе.

Важный нюанс: докупка выполняется через партнёра 1С, а активация новых пин-кодов привязана к вашей регистрации. Если регистрационные данные записаны на бывшего подрядчика, начните с них, а не с покупки. И отдельно проверьте настройку информационной базы про выдачу лицензий сервером 1С:Предприятия: от неё зависит, получают ли клиенты места от сервера, или каждый ищет их на своей стороне.

Резюме моих приоритетов. Первое — наблюдение, чтобы знать пик. Второе — уборка зависших сеансов и политика на RDP, это бесплатно. Третье — разведение технических подключений и интеграций. И только после этого покупка. Если не хотите разбираться сами, мы можем провести такую диагностику за день: подключимся, снимем картину по сеансам и скажем, сколько лицензий вам нужно на самом деле.

Частые вопросы