Информационная база исправна, сервер 1С запущен, СУБД отвечает. Пользователи всё равно не могут войти: платформа не получила лицензию.
Перезапускать весь контур при таком отказе бессмысленно. Сначала нужно выяснить, где выдаются лицензии, какие ключи задействованы и кто восстановит их после сбоя.
Администратору стоит собрать эти сведения до замены оборудования или отказа лицензирующего узла. Тогда он сможет оценить систему контроля лицензий на своей инфраструктуре, а не по общей демонстрации.
Почему исправная база остаётся недоступной
Лицензирование стоит в цепочке подключения отдельно от базы и СУБД. Поэтому работа может остановиться без повреждения данных и отказа серверных служб.
По описанию архитектуры в материале IP-Way, клиентская лицензия нужна для запуска платформы и работы с базами. Серверная лицензия нужна серверу 1С в клиент-серверном варианте.
Пользователь в такой схеме подключается к серверу 1С, а не к файлу базы. Сервер проверяет лицензию при подключении клиента к рабочему процессу.
| Что проверили | Что работает | Что могло отказать | Что видит пользователь |
|---|---|---|---|
| Информационная база | Файлы базы или данные в СУБД доступны | Лицензия клиента либо сервера | Сообщение об отсутствии лицензии |
| Сервер 1С | Агент и рабочие процессы запущены | Служба или узел лицензирования | База есть в списке, но вход не проходит |
| СУБД | Сервер принимает соединения | Выдача лицензии до начала сеанса | Ошибка появляется до открытия базы |
| Лицензирующий узел | Остальной контур не сообщает об отказе | Программная лицензия, HASP или служба | Пользователи одновременно теряют доступ |
Вывод: состояние сервера 1С и СУБД не показывает, сможет ли новый сеанс получить лицензию.
Сначала отделите сбой лицензирования от других отказов. Для этого сопоставьте сообщение платформы с состоянием клиента, кластера и СУБД. Такой порядок помогает не спутать лицензию с ситуацией, когда 1С не проходит один из этапов запуска.
Вебинар СКУЛ уже прошёл: что было в программе
Инфостарт анонсировал вебинар «СКУЛ: как увидеть реальную загрузку лицензий 1С и сократить затраты» на 24 сентября, 11:00 МСК. Участие объявили бесплатным.
Дата мероприятия уже прошла. Подтверждённого адреса записи в материалах нет, поэтому искать её стоит на странице анонса или у организаторов.
Программа охватывала четыре задачи: фактическую загрузку лицензий, централизованный учёт, восстановление после сбоев и планирование закупок. Организаторы также заявили демонстрацию СКУЛ, разбор кейса и оценку экономического эффекта.
Отдельный пункт программы — различия между базовой и расширенной поставками СКУЛ. Без записи нельзя проверить, какие функции показали и насколько подробно раскрыли восстановление.
Вебинар вели три спикера. Павел Рожин — технический директор «Гринтех», Евгений Алаев руководит там инженерными практиками и технологическими платформами. Родион Гущин руководит группой продаж Инфостарта.
Состав спикеров показывает два угла программы: устройство системы и её покупку. При просмотре записи эти части лучше разделять. Сначала проверяйте технический сценарий, потом считайте расходы.
Какие сведения собрать до выбора системы контроля
Учёт начинается не с установки нового продукта. Сначала нужно описать действующую схему так, чтобы другой администратор смог найти каждый ключ и восстановить доступ.
Программная лицензия активируется на конкретном компьютере или сервере и хранится в файлах. Это указано в техническом разборе IP-Way. Перенос виртуальной машины или замена оборудования может изменить параметры, к которым привязана активация.
Аппаратная лицензия хранится в USB-ключе HASP. Материал 1C-Expert указывает, что такой ключ подключают к одному серверу в конкретный момент времени.
Одного перечня лицензий мало. Нужны места активации, владельцы ключей, загрузка и порядок реакции на отказ.
| Объект контроля | Что зафиксировать | Зачем это нужно | Риск при сбое |
|---|---|---|---|
| Программная лицензия | Машину активации и комплект резервных ПИН-кодов | Найти лицензию после замены узла | Администратор ищет сведения во время простоя |
| Аппаратный ключ HASP | Сервер и физический USB-порт | Быстро проверить ключ и его подключение | Ключ переносят между узлами без записи |
| Клиентские лицензии | Число активных сеансов и доступный остаток | Отличить нехватку лицензий от отказа службы | Новые пользователи не входят, хотя старые работают |
| Серверная лицензия | Узел, где её получает сервер 1С | Проверить клиент-серверное подключение | Кластер запущен, но новые сеансы не создаются |
| Ответственный сотрудник | Имя, контакты и доступ к данным активации | Не искать владельца во время отказа | Восстановление ждёт человека с ПИН-кодами |
| Порядок реактивации | Проверенную последовательность действий | Вернуть доступ после замены оборудования | Команда впервые изучает процедуру при аварии |
Вывод: реестр должен отвечать не только на вопрос «сколько лицензий куплено», но и на вопрос «как вернуть каждую лицензию».
Не храните ПИН-коды в самой таблице, доступной всей ИТ-службе. В реестре достаточно указать защищённое хранилище и сотрудника с доступом.
Для технической схемы пригодится отдельное руководство по работе лицензирующего узла. Если лицензия уже потерялась после замены оборудования, переходите к веткам восстановления программной лицензии и HASP.
Что считать фактической загрузкой лицензий
Количество купленных лицензий не равно числу одновременных сеансов. Для закупки нужен профиль загрузки: сколько лицензий занято в рабочие часы и когда возникает дефицит.
Материал 1C-Expert связывает сетевой менеджер лицензий с отслеживанием активных сеансов. Утилита HASP Diagnostic Tool показывает серийный номер ключа и доступный остаток.
Эти данные стоит смотреть в динамике. Один снимок в середине дня не покажет пик при закрытии месяца, массовом обмене или начале смены.
В исследовании нет методики, по которой СКУЛ считает загрузку. Поэтому нельзя утверждать, что система измеряет пик, среднее значение или длительность занятого сеанса.
На демонстрации стоит запросить определения. Что считается активным сеансом, как система обрабатывает разрывы связи и за какой период строит отчёт — без этих ответов график не помогает принять решение.
Также нужен способ связать событие с конкретным узлом. Иначе администратор увидит нехватку лицензий, но продолжит искать её среди нескольких серверов вручную.
Когда отдельный инструмент не нужен
При одном сервере 1С и небольшой нагрузке IP-Way не рекомендует выделять отдельный сервер лицензирования. В такой схеме реестр лицензий и проверенная инструкция могут закрыть основную часть риска.
Это не означает, что контроль не нужен. Нужно знать место активации, расположение HASP и порядок восстановления после замены оборудования.
Отдельный инструмент имеет смысл, когда ручной реестр перестаёт отражать текущую схему. Такое происходит при нескольких узлах, распределённых ключах и строгих требованиях к непрерывной работе.
| Схема | Что можно контролировать вручную | Где начинается риск | Что проверять в отдельном инструменте |
|---|---|---|---|
| Один сервер 1С | Место активации, HASP, ответственный | Документ устарел после замены сервера | Экспорт реестра и история изменений |
| Несколько серверов 1С | Перечень лицензий по узлам | Лицензии распределены иначе, чем записано | Привязка сеансов и лицензий к узлам |
| Виртуальная инфраструктура | Текущий хост каждой машины | Миграция меняет видимую конфигурацию | События переноса и состояние активации |
| Несколько площадок | Локальные таблицы администраторов | Нет общей картины и единого владельца | Централизованный учёт и разграничение доступа |
| Контур с требованием непрерывной работы | Регламент восстановления | Регламент существует только на бумаге | Проверяемая процедура возврата лицензий |
Вывод: отдельная система нужна не из-за числа серверов самого по себе, а из-за потери управляемости между узлами и администраторами.
В исследовании нет порога по числу пользователей или лицензий. Назначать его без методики нельзя. Решение принимают по сложности схемы и цене простоя, а не по круглой цифре.
Чужой крупный контур не служит готовым шаблоном
В опубликованном на Инфостарте разборе 1CRetail описан контур из шести серверов приложений и одного сервера лицензирования. На момент миграции в 2022 году он обслуживал 5500 пользователей.
Перенос на новый сервер лицензирования занял полтора месяца. Эти данные относятся к конкретному кластеру, поэтому переносить срок на небольшую компанию нельзя.
Кейс показывает другое: лицензирование мигрируют как отдельную подсистему. Нужно учесть размещение ключей, зависимости между узлами и порядок переключения пользователей.
Для малого контура работа может свестись к проверке реестра и пробной реактивации. Для распределённой схемы понадобится отдельный план миграции с владельцами каждого этапа.
Какие вопросы задать по СКУЛ
Не начинайте с вопроса о снижении затрат. Сначала выясните, видит ли система всю цепочку получения лицензии и помогает ли восстановить её после отказа.
Попросите показать вашу типовую схему: сервер 1С, программную лицензию, аппаратный ключ и несколько клиентских сеансов. Если демонстрация охватывает только сводную панель, технический риск остаётся неразобранным.
Проверьте четыре операции:
- Найти узел, который выдал лицензию конкретному сеансу.
- Увидеть остаток лицензий и историю загрузки.
- Зафиксировать перенос или реактивацию лицензии.
- Восстановить реестр после отказа самого контрольного узла.
Организаторы вебинара принимали вопросы по инфраструктуре заранее. Для записи этот канал может быть уже закрыт, но подготовленный вопрос пригодится на следующей демонстрации.
Если ответ зависит от нескольких площадок, виртуализации и распределения ключей, одной общей презентации мало. Тогда запросите разбор лицензирования в вашем серверном контуре и заранее передайте схему без секретов и ПИН-кодов.
Чек-лист перед просмотром записи или новой демонстрацией
За полчаса до просмотра соберите факты о своей схеме. Без них презентация продукта останется набором экранов, которые нельзя сопоставить с инфраструктурой.
- Отметьте место активации каждой программной лицензии.
- Запишите сервер и USB-порт каждого ключа HASP.
- Сверьте купленные лицензии с текущими активными сеансами.
- Назовите сотрудника, который проведёт реактивацию.
- Проверьте порядок действий после замены оборудования.
- Сформулируйте один вопрос по отказу конкретного лицензирующего узла.
Схема готова к сбою, когда администратор знает источник каждой лицензии и порядок возврата доступа. СКУЛ стоит оценивать по этой цепочке, а не по обещанию сократить расходы.