Аппаратный ключ защиты HASP и 1С (занятие нескольких лицензий с одного ПК)
Сталкивался ли кто-нибудь с такой проблемой?
Сначала опишу топологию нашей системы работы с 1С и ключами:
У нас имеется 7 аппаратных usb ключей защиты hasp. 5 ключей на 20х, 1 ключ на 10х, 1 ключ на 50х. Все они установлены на разных компьютерах в сети, также на каждом их них установлен Менеджер лицензий, который их раздает. В Алладин-мониторе все эти ключи видно, все ок.
Имеются базы 1С (много, около 50), расположенные на разных серверах приложений (всего 4 сервера приложений). В настройках всех баз свойство "Разрешить выдачу лицензий сервером 1с предприятия" установлено в "НЕТ".
При такой схеме, согласно документации, на одном компьютере можно открывать неограниченное количество сеансов 1С (одной базы либо разных, не имеет значения), и все они будут занимать РОВНО ОДНУ лицензию с одного ключа.
На компьютерах пользователей в nethasp.ini в параметре NH_SERVER_ADDR = прописаны адреса всех машин, где установлены ключи (через запятую).
Флаг "Использовать аппаратную лицензию (ключ защиты)" в настройках запуска клиентов установлен.
Пользователи в работе могут открывать как несколько сеансов одной базы, так и несколько сеансов разных баз, это нужно для работы, т.к. в одном сеансе может идти какая-то загрузка, в другом они смотрят в это время отчеты, вводят документы. То есть чаще все работают именно с 2-3 базами, нежели с одной или одним сеансом. Это важно, т.к. именно в этом случае у нас проявляется проблема, описанная ниже.
Теперь конкретно о проблеме:
Столкнулись вдруг с нехваткой лицензий. А количество сочетаний "пользователь+компьютер" у нас гарантированно меньше суммарного кол-ва лицензий (10 + 20*5 + 50 = 160 лицензий).
Стали разбираться и выяснили, что у нас очень много случаев, когда несколько 1С, будучи запущенных на одной машине (именно локально, про терминальные сеансы речи не идет), занимают БОЛЕЕ ОДНОЙ ЛИЦЕНЗИИ с одного либо нескольких ключей, чего при наших настройках и видах ключей быть не должно. Напомню, ключи аппаратные, раздача ключей сервером запрещена.
Также у нас есть терминальные сервера, через которые пользователи тоже работают с 1с. Но в этом случае, если человек открыл 1 сеанс 1С локально и 1 сеанс на терминале занимается 2 лицензии, тут вопросов нет.
Примеры скринов с алладина во вложении. Там видно, что в моменте один адрес (192.168.8.103) занимает либо 2 лицензии (скрин 1) с одного ключа, либо 2 лицензии с разных ключей (скрин 2 и 3). При этом на этой машине просто запускались последовательно два раза 2 базы 1с, в разном порядке.
Сначала опишу топологию нашей системы работы с 1С и ключами:
У нас имеется 7 аппаратных usb ключей защиты hasp. 5 ключей на 20х, 1 ключ на 10х, 1 ключ на 50х. Все они установлены на разных компьютерах в сети, также на каждом их них установлен Менеджер лицензий, который их раздает. В Алладин-мониторе все эти ключи видно, все ок.
Имеются базы 1С (много, около 50), расположенные на разных серверах приложений (всего 4 сервера приложений). В настройках всех баз свойство "Разрешить выдачу лицензий сервером 1с предприятия" установлено в "НЕТ".
При такой схеме, согласно документации, на одном компьютере можно открывать неограниченное количество сеансов 1С (одной базы либо разных, не имеет значения), и все они будут занимать РОВНО ОДНУ лицензию с одного ключа.
На компьютерах пользователей в nethasp.ini в параметре NH_SERVER_ADDR = прописаны адреса всех машин, где установлены ключи (через запятую).
Флаг "Использовать аппаратную лицензию (ключ защиты)" в настройках запуска клиентов установлен.
Пользователи в работе могут открывать как несколько сеансов одной базы, так и несколько сеансов разных баз, это нужно для работы, т.к. в одном сеансе может идти какая-то загрузка, в другом они смотрят в это время отчеты, вводят документы. То есть чаще все работают именно с 2-3 базами, нежели с одной или одним сеансом. Это важно, т.к. именно в этом случае у нас проявляется проблема, описанная ниже.
Теперь конкретно о проблеме:
Столкнулись вдруг с нехваткой лицензий. А количество сочетаний "пользователь+компьютер" у нас гарантированно меньше суммарного кол-ва лицензий (10 + 20*5 + 50 = 160 лицензий).
Стали разбираться и выяснили, что у нас очень много случаев, когда несколько 1С, будучи запущенных на одной машине (именно локально, про терминальные сеансы речи не идет), занимают БОЛЕЕ ОДНОЙ ЛИЦЕНЗИИ с одного либо нескольких ключей, чего при наших настройках и видах ключей быть не должно. Напомню, ключи аппаратные, раздача ключей сервером запрещена.
Также у нас есть терминальные сервера, через которые пользователи тоже работают с 1с. Но в этом случае, если человек открыл 1 сеанс 1С локально и 1 сеанс на терминале занимается 2 лицензии, тут вопросов нет.
Примеры скринов с алладина во вложении. Там видно, что в моменте один адрес (192.168.8.103) занимает либо 2 лицензии (скрин 1) с одного ключа, либо 2 лицензии с разных ключей (скрин 2 и 3). При этом на этой машине просто запускались последовательно два раза 2 базы 1с, в разном порядке.
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Кардинальный способ решения проблемы - обменять имеющийся букет ключей на один, больше всего вам подходит ключ на 300 лицензий. Тогда наверняка все проблемы сразу решатся - исключается захват нескольких лицензий с разных серверов, да и почти двукратный запас по лицензиям повысит стабильность работы.
Недостаток у этого решения только один - шестизначная сумма доплаты за такой обмен. ;)
Главное - не надеяться, что этот зоопарк разрулится "сам собой" - в этом случае будете иметь... то, что сейчас уже имеете.
На компьютерах пользователей в nethasp.ini в параметре NH_SERVER_ADDR = прописаны адреса всех машин, где установлены ключи (через запятую).
Как вариант решения: вручную распределить пользователей по серверам, оставив каждому только один (по возможности) сервер HASP. В крайнем случае - два. Короче, минимизировать количество серверов в NH_SERVER_ADDR. При этом должно сократиться количество проблемных пользователей - по крайней мере, никто не будет откусывать лицензии с "чужих" серверов.
Кардинальный способ решения проблемы - обменять имеющийся букет ключей на один, больше всего вам подходит ключ на 300 лицензий. Тогда наверняка все проблемы сразу решатся - исключается захват нескольких лицензий с разных серверов, да и почти двукратный запас по лицензиям повысит стабильность работы.
Недостаток у этого решения только один - шестизначная сумма доплаты за такой обмен. ;)
Главное - не надеяться, что этот зоопарк разрулится "сам собой" - в этом случае будете иметь... то, что сейчас уже имеете.
(1)
NH_SESSION = х ( х=секунда) - если за указанное время первый сервер указанный в NH_SERVER_ADDR про тупил ( не ответил) , то опрашивается следующий по порядку из NH_SERVER_ADDR и если он ответил то займет лицензию на нем.
ИМХО - корректнее получать лицензии через сервер , и настроить сервер на правильное получение клиентских лицензий от HLM
На компьютерах пользователей в nethasp.ini в параметре NH_SERVER_ADDR = прописаны адреса всех машин, где установлены ключи (через запятую)
- так все верно :)
NH_SESSION = х ( х=секунда) - если за указанное время первый сервер указанный в NH_SERVER_ADDR про тупил ( не ответил) , то опрашивается следующий по порядку из NH_SERVER_ADDR и если он ответил то займет лицензию на нем.
ИМХО - корректнее получать лицензии через сервер , и настроить сервер на правильное получение клиентских лицензий от HLM
(2)
Так клиент 1С при запуске (если уже один клиент запущен) всё-равно пытается еще получить лицензию, обходя список ключей из NH_SERVER_ADDR? Ведь первый запуск клиента 1С на ПК должен занять лицензию, и уже последующие запуски (при аппаратном ключе) не должны их занимать? Следовательно, почему второй запущенный клиент начинает цикл по обходу ключей и занятию лицензии? Я вот это не могу понять..
Через сервер нам не подходит, т.к. в основном пользователи работают с 2, 3, 4 и даже 5 базами одновременно (или в 3х окнах с одной базой), и раздача по принципу 1сеанс = минус одна лицензия нам не подходит.
Так клиент 1С при запуске (если уже один клиент запущен) всё-равно пытается еще получить лицензию, обходя список ключей из NH_SERVER_ADDR? Ведь первый запуск клиента 1С на ПК должен занять лицензию, и уже последующие запуски (при аппаратном ключе) не должны их занимать? Следовательно, почему второй запущенный клиент начинает цикл по обходу ключей и занятию лицензии? Я вот это не могу понять..
Через сервер нам не подходит, т.к. в основном пользователи работают с 2, 3, 4 и даже 5 базами одновременно (или в 3х окнах с одной базой), и раздача по принципу 1сеанс = минус одна лицензия нам не подходит.
(3)
А что тут понимать? Откуда он должен брать инфу о полученной в другом сеансе лицензии? И почему обязан это делать? Каждый раз как в первый получает.
Во время сеанса тоже переспросить может. Но переспрашивает с сервера, на котором уже получал лицензию в этом сеансе.
Список серверов лицензий через запятую как пул лицензий и не работал никогда. Народ обычно жестко закреплял конкретных пользователей за конкретными серверами. И периодический перезапуск службы лицензий настраивал.
ЗЫ. То есть все предельно просто и примитивно. Клиент не анализирует занятые им лицензии на всех серверах. Он просто достукивается куда получилось по списку. И если на этом сервере лицензия ему уже выдавалась, то она будет переиспользована. Нет - выдадут новую. Все. Больше никакого ума там нет.
почему второй запущенный клиент начинает цикл по обходу ключей и занятию лицензии? Я вот это не могу понять..
А что тут понимать? Откуда он должен брать инфу о полученной в другом сеансе лицензии? И почему обязан это делать? Каждый раз как в первый получает.
Во время сеанса тоже переспросить может. Но переспрашивает с сервера, на котором уже получал лицензию в этом сеансе.
Список серверов лицензий через запятую как пул лицензий и не работал никогда. Народ обычно жестко закреплял конкретных пользователей за конкретными серверами. И периодический перезапуск службы лицензий настраивал.
ЗЫ. То есть все предельно просто и примитивно. Клиент не анализирует занятые им лицензии на всех серверах. Он просто достукивается куда получилось по списку. И если на этом сервере лицензия ему уже выдавалась, то она будет переиспользована. Нет - выдадут новую. Все. Больше никакого ума там нет.
(5)
Судя по документации и схемам типа той, что у меня на скрине при втором (третьем и тд) запуске клиента 1С на данной машине, 1сина пробует получить лицензию из ключа ХАСП, чья лицензия была получена пользователем при последнем подключении (а вовсе не из ключа, который идет первым по порядку в настроечном файле). И вот тут возможно у меня проблема и возникает - если этот ключ быстро не пинганулся (из-за того, что не выставлен таймаут NH_SESSION , то она видимо пытается взять лицензию с другого, уже идя по порядку в файле).
Судя по документации и схемам типа той, что у меня на скрине при втором (третьем и тд) запуске клиента 1С на данной машине, 1сина пробует получить лицензию из ключа ХАСП, чья лицензия была получена пользователем при последнем подключении (а вовсе не из ключа, который идет первым по порядку в настроечном файле). И вот тут возможно у меня проблема и возникает - если этот ключ быстро не пинганулся (из-за того, что не выставлен таймаут NH_SESSION , то она видимо пытается взять лицензию с другого, уже идя по порядку в файле).
Прикрепленные файлы:
(7) Может и так. Это непринципиально. Сути это не меняет. Заставить несколько серверов лицензий работать как единый пул - невозможно. Штатно ,во всяком случае. При разного рода накладках "висяки" будут появляться так или иначе.
Вы можете либо сгладить проблему, настроив периодический перезапуск служб лицензий, либо закрепить пользователей за серверами. А лучше и то и другое. Потому что иногда "висяки" появляются и на одном сервере. Уж не помню точно ситуации, которые к такому приводят.
Вы можете либо сгладить проблему, настроив периодический перезапуск служб лицензий, либо закрепить пользователей за серверами. А лучше и то и другое. Потому что иногда "висяки" появляются и на одном сервере. Уж не помню точно ситуации, которые к такому приводят.
(7) ну именно это вам и написал в (2) :) Запустили 1С первый раз опросил сервер первый из NH_SERVER_ADDR = хх.хх.хх.1;хх.хх.хх.2 , получил лицензию.. запускаете еще раз он опросил это хх.хх.хх.1 а он тупит или недоступен :) не получилось "присоединиться к уже полученной" и ... опрашивает х.хх.хх.2 и получает :)
(2)
Поясню еще немного
10.2.5.3.2. Многопользовательский клиентский ключ, доступный по сети через HASP License Manager
Обеспечивает одновременную работу стольких компьютеров, на сколько пользователей имеется ключ. На одном компьютере возможен запуск произвольного количества экземпляров системы в режиме 1С:Предприятие или Конфигуратор.
Количество лицензий ограничено общим количеством доступных лицензий со всех компьютеров в сети, на которых установлен и настроен HASP License Manager.
То есть заход в неограниченное кол-во клиентов 1С с одного ПК должен занимать одну лицензию.
Поясню еще немного
10.2.5.3.2. Многопользовательский клиентский ключ, доступный по сети через HASP License Manager
Обеспечивает одновременную работу стольких компьютеров, на сколько пользователей имеется ключ. На одном компьютере возможен запуск произвольного количества экземпляров системы в режиме 1С:Предприятие или Конфигуратор.
Количество лицензий ограничено общим количеством доступных лицензий со всех компьютеров в сети, на которых установлен и настроен HASP License Manager.
То есть заход в неограниченное кол-во клиентов 1С с одного ПК должен занимать одну лицензию.
Вы выяснили, какие именно клиенты выбирают лицензии?
Если которые подключаются в терминале, то это распространённая проблема, т.к. довольно часто при закрытии терминального сеанса лицензия не освобождается и при следующем подключении клиент забирает ещё одну лицензию.
Если же проблема наблюдается у обычных клиентов, то сразу сказать сложно, надо смотреть насколько стабильно работают, нет ли вылетов. Скорее проблема в большом количестве ключей.
Если которые подключаются в терминале, то это распространённая проблема, т.к. довольно часто при закрытии терминального сеанса лицензия не освобождается и при следующем подключении клиент забирает ещё одну лицензию.
Если же проблема наблюдается у обычных клиентов, то сразу сказать сложно, надо смотреть насколько стабильно работают, нет ли вылетов. Скорее проблема в большом количестве ключей.
(11)
У обычных клиентов - точно, анализировали айпи, занявшие лицензии, на разных ключах на предмет дублей (или затроений). На терминале тоже, возможно, есть, но таких пользователей в общей массе меньше, плюс сложнее анализировать, т.к. нужно разделять просто два разных сеанса терминальных и дублирующий захват лицензии (а в мониторе эти ситуации выглядят одинаково, как два подряд идущих айпи терминального сервера).
Причем у обычных клиентов она наблюдается даже без всяких вылетов: просто открываешь вторую базу (при уже открытой 1с первой базы) и оп -в алладине занимается еще одна лицензия (на этом же ключе либо на другом). Но выдача лиц. сервером отключена, 100%.
У обычных клиентов - точно, анализировали айпи, занявшие лицензии, на разных ключах на предмет дублей (или затроений). На терминале тоже, возможно, есть, но таких пользователей в общей массе меньше, плюс сложнее анализировать, т.к. нужно разделять просто два разных сеанса терминальных и дублирующий захват лицензии (а в мониторе эти ситуации выглядят одинаково, как два подряд идущих айпи терминального сервера).
Причем у обычных клиентов она наблюдается даже без всяких вылетов: просто открываешь вторую базу (при уже открытой 1с первой базы) и оп -в алладине занимается еще одна лицензия (на этом же ключе либо на другом). Но выдача лиц. сервером отключена, 100%.
(19) Если броадкаст не был отключён, то прописывать IP компьютеров с ключами смысла не имело, клиенты находили ключи по броадкасту, а не по IP.
Присвоить имена тоже бывает полезно, но можно получить и обратный эффект, учитывея, что у вас 7 ключей, а максимальное количество имен, которое можно указать в nethasp.ini - это 6 штук.
Я бы советовал отключить броадкаст и попробовать закрепить клиентов за одним конкретным ключом, а не прописывать всё 7 IP в одном nethasp.ini.
Присвоить имена тоже бывает полезно, но можно получить и обратный эффект, учитывея, что у вас 7 ключей, а максимальное количество имен, которое можно указать в nethasp.ini - это 6 штук.
Я бы советовал отключить броадкаст и попробовать закрепить клиентов за одним конкретным ключом, а не прописывать всё 7 IP в одном nethasp.ini.
(20)
У нас несколько подсетей, и клиенты одной подсети без явного прописанного айпи ключей в нетхасп.ини, видели только ключи своей подсети. Например, ключ на 192.168.8.14, то клиенты 192.168.8.ХХХ видят только его и другие ключи на 192.168.8.ХХХ, а ключ на 192.168.2.ХХХ не видят. С прописанным айпи видели.
Так а насчет имен - их имеет смысл указывать в настроечных файлах машин, где стоит ключ, только одновременно с указанием этого же имени или имен в NH_SERVER_NAME на клиентских ини-файах? Или можно только ограничиться указанием их на серверах, просто чтобы были разные? Как вы верно подметили - да, на клиенте можно макс перечень из 6 имен написать, а у нас 7 пока.
У нас несколько подсетей, и клиенты одной подсети без явного прописанного айпи ключей в нетхасп.ини, видели только ключи своей подсети. Например, ключ на 192.168.8.14, то клиенты 192.168.8.ХХХ видят только его и другие ключи на 192.168.8.ХХХ, а ключ на 192.168.2.ХХХ не видят. С прописанным айпи видели.
Так а насчет имен - их имеет смысл указывать в настроечных файлах машин, где стоит ключ, только одновременно с указанием этого же имени или имен в NH_SERVER_NAME на клиентских ини-файах? Или можно только ограничиться указанием их на серверах, просто чтобы были разные? Как вы верно подметили - да, на клиенте можно макс перечень из 6 имен написать, а у нас 7 пока.
(21)
Да, вы правы, броадкаст нужно отключать, если нужно будет закрепить клиентов за каким-то конкретным ключом и запретить доступ к остальным, указать где искать можно и без отключения. Но при нескольких ключах широковещание все же лучше отключать, т.к. на поиск ключей по всей сети уходит время.
В общем случае можно задать имя сервера в nhsrv.ini без указания этого имени в nethasp.ini на клиентах и должно работать, а вот если указывать, то указанное имя должно совпадать с IP.
Будет ли влиять то, что у вас ключи в разных подсетях - сказать не могу.
У нас несколько подсетей, и клиенты одной подсети без явного прописанного айпи ключей в нетхасп.ини, видели только ключи своей подсети. Например, ключ на 192.168.8.14, то клиенты 192.168.8.ХХХ видят только его и другие ключи на 192.168.8.ХХХ, а ключ на 192.168.2.ХХХ не видят.
Да, вы правы, броадкаст нужно отключать, если нужно будет закрепить клиентов за каким-то конкретным ключом и запретить доступ к остальным, указать где искать можно и без отключения. Но при нескольких ключах широковещание все же лучше отключать, т.к. на поиск ключей по всей сети уходит время.
Так а насчет имен - их имеет смысл указывать в настроечных файлах машин, где стоит ключ, только одновременно с указанием этого же имени или имен в NH_SERVER_NAME на клиентских ини-файах?
В общем случае можно задать имя сервера в nhsrv.ini без указания этого имени в nethasp.ini на клиентах и должно работать, а вот если указывать, то указанное имя должно совпадать с IP.
Будет ли влиять то, что у вас ключи в разных подсетях - сказать не могу.
(15) В теории да, если лицензии клиенты получают сами, а не от сервера, то при нескольких ключах проблемы должны быть только с таймингом, а вот если лицензии раздает сервер 1С или модуль веб-сервера, то в документации довольно ясно описано, что один сервер может раздать лицензии максимум с двух ключей одной серии, одного локального + одного по сети.
Объединение ключей у нас как-то было вообще с минимальной какой-то доплатой (кол-во правда было существенно меньше), как-то программные лицензии меняли на HASP с доплатой в разнице лицензий. Самый идеальный вариант - 1 HASP, перезапуск службы и все остальное это костыли если разобраться. Попробуйте узнать ценник замены для начала - там стоимость может будет смешной...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот