Как пробросить ключ 1с на виртуальную машину
Хочу поделиться нашим годичным опытом при поиске решения для организации централизованного и упорядоченного доступа к ключам электронной защиты в нашей организации (ключи для доступа к площадкам для торгов, банковские, ключи защиты программного обеспечения и т.д.). В связи с наличием у нас филиалов, территориально весьма разнесенных друг от друга, и наличием в каждом из них по нескольку ключей электронной защиты — постоянно возникает необходимость в них, но в разных филиалах. После очередной суеты с потерянным ключом, руководство поставило задачу — решить эту проблему и собрать ВСЕ USB устройства защиты в одном месте, и обеспечить с ними работу не зависимо от места расположения сотрудника.
Итак, нам необходимо собрать в одном офисе все имеющиеся в нашей компании ключи банк клиентов, лицензий 1с (hasp), рутокены, ESMART Token USB 64K, и т.д. для последующей эксплуатации на удаленных физических и виртуальных машинах Hyper-V. Количество usb устройств – 50-60 и точно, что это не предел. Расположение серверов виртуализации вне офиса (датацентр). Расположение всех USB устройств в офисе.
Изучили существующие технологии централизованного доступа к USB устройствам и решили остановиться на технологии USB поверх IP (USB over IP). Оказывается, очень многие организации пользуются именно этим решением. На рынке есть как аппаратные средства проброса USB по IP, так и программные, но они нас не устраивали. По сему, далее речь пойдет только о выборе аппаратных USB over IP и в первую очередь о нашем выборе. Устройства из Китая (безымянные) мы тоже исключили из рассмотрения.
Наиболее описываемым на просторах интернета аппаратным решением USB over IP являются устройства производства США и Германии. Для детального изучения приобрели большой стоечный вариант этого USB over IP, рассчитанный на 14 портов USB, с возможностью монтажа в 19 дюймовую стойку и немецкий USB over IP, рассчитанный на 20 портов USB, так же с возможностью монтажа в 19 дюймовую стойку. К сожалению на большее количество портов устройств USB over IP у этих производителей не было.
Первое устройство весьма дорогое и интересное (в интернете полно обзоров), но есть очень большой минус — нет никаких систем авторизации для подключения USB устройств. Любой, кто установит приложение для подключения USB, получает доступ ко всем ключам. В дополнение, как показала практика, USB устройство «esmart token est64u-r1» непригодно для использования с устройством и, забегая вперед, с «немецким» на ОС Win7 – при подключении к нему перманентный BSOD.
Второе устройство USB over IP нам показалось интереснее. Устройство имеет большой набор настроек, связанных с сетевыми функциями. Интерфейс USB over IP логично разбит на разделы, так что первоначальная настройка была достаточно простой и быстрой. Но, как упоминалось ранее, возникли проблемы с подключением ряда ключей.
Изучая дальше аппаратные USB over IP натолкнулись на отечественных производителей. Модельный ряд включает 16, 32, 48 и 64 портовую версию с возможностью крепления в 19 дюймовую стойку. Описываемый производителем функционал был даже побогаче, чем у предыдущих приобретенных USB over IP. Изначально понравилось, что отечественный управляемый USB over IP концентратор обеспечивает двухступенчатую защиту USB устройств при совместном использовании USB по сети:
- Удаленное физическое включение и выключение USB устройств;
- Авторизацию для подключения USB устройств по логину, паролю и IP адресу.
- Авторизацию для подключения USB портов по логину, паролю и IP адресу.
- Журналирование как всех включений и подключений USB устройств клиентами, так и таких попыток (не правильный ввод пароля и т.д. ).
- Шифрование трафика (с чем в принципе было неплохо и на немецкой модели).
- Дополнительно подходило, что устройство, хоть и не дешевое, но в разы дешевле купленных ранее (особенно существенной становится разница при пересчете на порт, мы рассматривали 64-х портовый USB over IP).
Наименования и производителей USB over IP устройств не привожу (дабы не было рекламой), их достаточно просто найти в интернете.
Некоторое время назад слышал о запрете транслирования HASP ключей «1с:Предпрятия» в виртуальную среду. Причем насколько я помню это было не техническое, а юридичесское ограничение. Недавно услышал, что вроде бы как этот запрет снят, но есть одно но. При миграции виртуальной машины на другое физическое оборудование (например при автоматическом распределении виртуальных машин по некоторой распределенной системе) ключи HASP теряются. При этом во многом нивелируется сам смысл виртуализации (отвязывание софтверной части от железа).
Сталкивался ли кто нибудь с такой проблемой и возможно даже решил вопрос с трансляцией HASP USB ключей в виртуальные машины? Как сделать так, что бы при миграции виртуальной машины на другое оборудование ключи подтягивались в виртуальную машину с исходного физического оборудования?
Не совсем понятен вопрос.
но из опыт использования VMware ESXi 5 проблем подключением и отключением ключей не было. по крайней при переносе с физической машины на виртуальную.
Разве что в Hyper-V от Майкрософта есть сложности вообще в использовании USB-портов.
Используйте VMware ESXi 5 и будет вам счастье!
полностью согласен с karpigor, сфера без бубнов прекрасно транслирует хаспы в виртуальные машины развернутые на ней, в хипер-в так не получилось.
ооо! у меня была подобная трабла, поставил "USB over Network" и забыл, все автоматом приконекчивает в серваке с клиента на WinServ64xR2 виртуалки и ВМ и хайперви
обновите гипервизор до 2008r2sp1 - там возможность проброса портов в виртуалки с хостовой машины присутствует.
(7) maxim.klyuev, переискал все настройки гипервизора и поиск на Microsoft TechNet Search ничего не дал. Можешь подскажите где присутствует возможность проброса портов. Сам пользуюсь "USB over Network" .
использую FabuleTech USB Over Network - у клиентов прописан адрес сервера и все. меняй не меняй клиентское железо - железные ключи примаунтятся
Да ерунда это все. Esx, Esxi и прочие проги этого же производителя без проблем работают с усб. Так что если нет юридических заморочек то я проблем не вижу других.
mistermp3 пишет:
Некоторое время назад слышал о запрете транслирования HASP ключей «1с:Предпрятия» в виртуальную среду. Причем насколько я помню это было не техническое, а юридичесское ограничение. Недавно услышал, что вроде бы как этот запрет снят, но есть одно но. При миграции виртуальной машины на другое физическое оборудование (например при автоматическом распределении виртуальных машин по некоторой распределенной системе) ключи HASP теряются. При этом во многом нивелируется сам смысл виртуализации (отвязывание софтверной части от железа). Сталкивался ли кто нибудь с такой проблемой и возможно даже решил вопрос с трансляцией HASP USB ключей в виртуальные машины? Как сделать так, что бы при миграции виртуальной машины на другое оборудование ключи подтягивались в виртуальную машину с исходного физического оборудования?
Ключ для сервера транслируется? Или же Вы делаете трансляцию клиентских лицензий при использовании файлового варианта базы данных?
Здравствуйте, подскажите, пожалуйста, как правильно сделать?
Ситуация такая - есть физический сервер, на нем Windows Server 2016, с поднятой ролью Hyper-v.
Подняты 2 гостевые ОС:
1) Windows servr 2008R2 (На нее есть куча лицензий рдп) - планировал использовать как сервер 1c и терминальный сервер
2) Centos с Postgres
Столкнулся с проблемой - ключ закупили USB HASP HL Max, как я понял он не сетевой и должен быть физически воткунт в машину с сервером 1с.
Пробовал воткнуть ключ в хостовую машину Hyper-V и прокинуть в гостевую через софтину - usb over ethernet. Ключ подцепился, поработал часа 4 и перестал видеться.
Какие есть решения этой проблемы, кроме как отказаться от виртуализации и поднять все на одной физической машине с postgres под win?
(1)Мы использовали решение AnywhereUSB. Но дороговато выходит и тоже время от времени требует перезагрузки, примерно 2-3 раза в год.
Как вариант можно поставить 1С на хосте Hyper-V, а не на виртуальной машине, тогда и ключ не надо будет пробрасывать.
А зачем Вы Hyper-V решили использовать?
Мы решили данную ситуацию покупкой Gembird UNS-1 подобного, принцип интересный, устанавливается утилита и при втыкании в данное устройство определяется у всех в сети у кого установлена утилита. Точно модель скажу позже.
(1)Мы использовали решение AnywhereUSB. Но дороговато выходит и тоже время от времени требует перезагрузки, примерно 2-3 раза в год.
Как вариант можно поставить 1С на хосте Hyper-V, а не на виртуальной машине, тогда и ключ не надо будет пробрасывать.
А зачем Вы Hyper-V решили использовать?
(6) Тоже думаю над тем, что бы поставить 1С сервер на хостовую машину.
причин на hyper-v по сути несколько: Есть мощная железка, которая должна все тянуть и на ней win server 2016 std. Вторая причина - с постгресом мне под линуксом удобнее работать, как то никогда не приходилось его под вин ставить. Третья - думал поднять кластер hyper-v на двух машинах и таки образом резервировать.
Собственно по этому решил в тесте развернуть на Hyper-V - один сервер 2008r2, один Centos с postgres. Погонял тестом Гилева вчера, все печально 18 попугаев. Буду пробовать еще win 2016 std, может на нем шустрее чуть будет )
На выходных хочу попробовать развернуть на физическом железе с постгрес под win и попрбовать с постгрес под hyper-v, посмотреть сколько выдаст попугаев так и так.
vmware esxi особо пока не рассматривал, есть смысл тестить на ней?
(7)Гипервизор в любом случае свою долю от производительности хостов отъедает, по этому его ставят с учётом всех нужд и потребностей. Если кроме 1С и Постгри на мощной железяке не предвидится ещё чего-нибудь, то в Hyper-V я особого смысла не вижу.
Для кластера Hyper-V оборудование есть? Да и с USB ключом автоматическую миграцию 1С сервера соорудить получится только с AnywareUSB (или аналогом), вторым ключом или переключением его руками.
Vmware esxi вроде USB пробрасывает, но тут уже надо смотреть на предмет лицензий и возможности соорудить на ней кластер на имеющемся оборудовании.
(9)Как раз думал в hyper-v перекинуть еще две машины, которые ресурсов практически не едят, а место старинное железо в стойке занимает (
VMWare если не esxi то бюджет совсем конский получается (
Буду пробовать, для начала перенести сервер 1с на хостовую машину, а постгрес оставить в виртуалке. 1с на 50 пользователей всего, запас по железу пока есть.
Для кластера hyper-v оборудование есть. С ключом, в случае падения первого хоста, можно его переткнуть во второй?
(11)USB ключ переткнуть можно, но это будет ручная операция, что для кластера есть минус, который необходимо учитывать. С одной стороны можно обновлять серверы почти без перерывов в обслуживании, с другой стороны автоматического переключения на резерв у Вас не будет. По сравнению с одним старым серваком это прогресс, но и не полноценный кластер. Кластерная красотища требует затрат. :)
(18) Прошу прощения, не подскажите еще один момент?
Перенес сервер 1с, на хостовую физическую машину, установил на 10й рейд с сас винчесетрами (USB ключ подцепился, все окей).
Есть смысл установить 1с Сервер на рейд1 с ссд винчестерами, на котором стоит постгрес?
Попробовал установить postgres и 1с сервер на хостовую машину под windows, производительность по тесту Гилева особо не изменилась (было 28 попугаев, стало 29), если сравнивать с - сервер 1с на физической машине, а postgres под Hyper-v на Linux.
Буду пробовать процессоры еще турбобустом разогнать
(21)Желательно чтобы 1С сервер кеш свой держал на SSD. ТЖ и ЖР можно и на SAS RAID держать если аппаратный кеш на запись на нём не выключать совсем.
(22)понял, спасибо большое за помощь.
Буду пробовать кэш перенести на ссд, может пару попугаев выиграю.
(23)Перед переносом можно посмотреть загрузку кеша на тесте и прикинуть поможет ли перенос на SSD. А потом экспериментально подтвердить или опровергнуть гипотезу.
(24)Спасибо Вам за помощь ) Как что не крутил, не получается больше 20 попугаев выжать из 1С.
Думаю, в тесте все упирается в процессор (Xeon Silver 4114 2 шт, в режиме турбо при тесте частоту максимум видел 2800)
Пробовал и на хостовую машину установить сервер 1с и PG (база на ssd) под win - 18 попугаев
Пробовал на хостовой 1C Serv, PG на виртуалке - 18 попугаев.
Пробовал 1C Serv на виртуалке, PG на виртуалке - 15 попугаев.
Сегодня попробую сервер 1с поднять на старом сервере, там проц с частотой 3800, посмотрю как там с попугаями )
(25)Попугаи это конечно хорошо, но не в них счастье. У меня больше всего попугаев получалось на моей рабочей станции и файловой базе - больше 60. :) Но это не значит что она лучше чем сервер - подкинь туда базёнок и повесь пользователей от 10 шт и все попугаи разлетятся, а на сервере они ещё долго будут чирикать на том же уровне. Да и 18 попугаев вполне рабочий результат для 50 пользователей.
(26) Такая мысль у меня была )) Особенно когда увидел 60 попугаев у кого-то в тесте, на i3 с 8 гб и файловой бд - может Ваша и была? ))
База совсем пока пустая, вот мучаю попугаями сервак. У нас 1с внедрение только, пока и погонять особо нечего )
Буду наполнять, наблюдать.
Еще раз - большое спасибо за подсказки и поддержку и с наступающим ))
(1)по поводу хаба который я описал из прошлого поста, модели нигде на нем не написано, пункт о программе прикрепил скриншотом
Похожая проблема была. Периодически отваливались ключи (примерно раз в день).
Правда ситуация была немного другая: сам виртуальный сервер приложений 1С и ключи находились еще и в разных местах (удаленных частях города).
Все дело было в софте, который делал проброс USB.
Решалось перезапуском службы, которая этот проброс делала. Как побороть так и не нашли. Сделали задание, которое каждое утро перезапускало нужную службу.
В качестве решения предлагаю перейти на VMWare вместо Hyper-V. У неё нет проблем с пробросом любых ключей от любых приложений, в том числе токенов для клиент-банков.
Доплатите условные 2₽ и перейдите на программное лицензирование. После этого активируйте лицензии где Вам нравится. Hasp будет не нужен и всякие пробросы тоже. Меньше проблем и ошибок. Тем более, если ключ умрет вдруг 1с просто встанет.
(10) те кто покупали 1с говорят, что на электронные нельзя перейти. Еще говорят, что электронную лицензию 1с дает активировать 2-3 раза, после чего блокируют и надо покупать заново, не знаю на сколько это правда, но в тестовой среде получается особо не поиграть с ключами, если это так.
Спасибо за подсказку, в понедельник позвоню сам в 1с уточню, это решило бы много вопросов.
(12) Кто-то вам морочит голову.
Обменять USB на программные лицензии МОЖНО, если они приобретались отдельными комплектами, а не в составе основных поставок или "бандлов" с MS SQL.
По поводу ограничения количества активаций - это тоже не соответствует действительности. Для клиентских и серверных лицензий нет ограничений на количество активаций.
При изменении конфигурации компьютера можно будет получить новую лицензию по резервному пинкоду из входящего в поставку комплекта. Пользователю предоставляются от двух до пяти резервных пинкодов в зависимости от вида программного продукта. Так, по два резервных пинкода предоставляются: для лицензии на одно рабочее место, для многопользовательских лицензий во всех поставках и для лицензий на сервер. В поставках клиентских лицензий на 5, 10 и 20 рабочих мест предоставляется следующее количество резервных пинкодов для однопользовательских лицензий: на 5 рабочих мест – 3 резервных пинкода, на 10 рабочих мест – 4 резервных пинкода, на 20 рабочих мест – 5 резервных пинкодов.
Если резервные пинкоды также израсходованы, пользователи могут обратиться в Центр лицензирования за дополнительными пинкодами. Для этого им необходимо прислать по электронной почте запрос на получение лицензии, сформированный по пинкоду, вместо которого требуется получить дополнительный пинкод. В Центре лицензирования будут проанализированы параметры получения всех лицензий по пинкодам из данного комплекта поставки, и, если не будет выявлено нарушений Лицензионного соглашения, пользователю будет выслан по электронной почте дополнительный пинкод.
Здравствуйте!
Клиент хочет установить 1С на терминальный сервер (Win2008 R2) запущенный в виртуалке. Будут ли проблемы с ключом для 1С? Как правильнее сделать, поставить ключ и hasp на физическом сервере и чтоб все терминальные клиенты искали ключ по сети (не будет ли большая нагрузка на 100 Мбит. сеть?) или же добавить его на виртуальный сервер (возможно ли это?) чтоб нагрузка на сеть была меньше?
(1) nick-name, Если вариант файловый то будут тормоза хорошие, для виртуалки придётся выделять отдельный физический диск. В варианте клиент сервер у меня так уже несколько лет работает, пока не жалуются, HASP стоит на физическом сервере в настройках клиента прописан адрес сервера с ключом и отключены широковещательные рассылки.
Ничего сложного, нужны ключи лицензии для терминального сервера,(хотя для 8.2 доступны программные ключи) ставите платформу на виртуальный сервер, в настройках маршрутизации прокидываете локальную сеть на виртуальную машину, и у вас получиться виртуальный терминальный сервер
это я знаю. Меня интересует как ПРАВИЛЬНЕЕ сделать. Поставить hasp на ФИЗИЧЕСКИЙ сервер (вырастет нагрузка на сеть) или на виртуальный (будут ли какие нибудь проблемы с пробросом usb?)
Следует учитывать, что драйвер HASP пытается не работать, если обнаруживает терминальный сервер.
Видимо попытались заткнуть какую-то дыру. Это не очень получилось, но лучше ключ ставить туда,
где терминальные службы не видны.
У нас крутиться 1С 8.2 на виртуальном Win2008. Проблем никаких. Программный ключ пока не работает как надо, пришлось использовать стандартные ключи. Для проброса ключей используем: USB over Ethernet Client.
(23) 1996oks, что значит "не установлены платформы"? пользователи работают через терминал или браузер? или у вас клиент-серверный вариант и стоит сервер 1С, а пользователи заходят через тонкий клиент?
если использовать программку для проброса USB в виртуалку (например, упоминавшаяся выше FabulaTech USB over Network), то просто подключаете ключи к физической машине в сети, с неё пробрасываете usb-ключ в виртуальную машину и 1С будет видеть ключи, как будто они торчат в том же компьютере, где стоит сервер.
Используйте любую программу для проброса USB в виртуальную машину, не забудьте при этом добавить USB в самой виртуальной машине. есть правда одна проблема. в основном эти программы платные
USBoverLAN - как то так прога называется. Ключ - в физический комп, на виртуалке указывай физический сервер. Все работает - тип-топ=)
В Oracle VirtualBox 4 проброска USB работает из коробки. Запускал такую связку как вы описываете - проблем никаких с ключом не было.
Как вариант использовать программные ключи для 1С8.
Используйте vmware ESXi 5 и будет вам много счастья, там есть проброс USB. а вообще, почему не использовать сетевой хасп? нагрузка на сеть не будет большой, у меня сделано так было пока не обновил ESXi
использование чего то другого кроме Hyper-V не возможно по ряду причин. В наличии имеется ключ сетевой на 20 клиентов. Хотелось бы чтоб и он и Hasp LM крутились на виртуальном сервере. Поставить сетевой ключ на другую машину в сети не проблема, но все хочется сделать правильно.
Люди правду говорят, на терминальном сервере не всегда хорошо работает хасп.
а почему не поставить дрова и лиценс манагер на хостовой машине? насколько помню на Hyper-V вполне ставится все это.
у нас самих все на Hyper-V, но ключи проброшены в виртуалку отдельную (там все ключи и хасп и катран) с помощью USBoverNet. все прекрасно работает, ключ на 50 нагрузка на сеть незаметна.
(11) lohmatik, Ваша конфигурация нарушает лицензию Microsoft, хотя решение и имеет право жить.
(1) nick-name, Если у вас псевдо сервер и материнская плата не вполне поддерживает Intel VT-d, то используйте проброс usb при помощи usb over Ethernet, при этом ключ+проброс ставится на хост и на клиенте проброс, ваш терминальный серв будет видеть ключ как родной и эта схема не нарушает лицензионное соглашение в отличии от схемы с установкой менеджера лицензий на хост.
Вариант второй, у вас нормальный сервак и тогда Hyper-V должен без проблем пробрасывать USB в клиент и проблемы будут только со связкой терминал+ключ, не всегда почему то дружат.
Вариант третий, выделенный сервер лицензий, нагрузка на сеть будет минимальной, там трафик достаточно низкий, почти сравним с техническим трафиком самой сети, у вас если есть в сети открытые виндовые шары они больше сеть замусоривают.
(12) swiftblack, непонял.
можно поподробней в чем нарушение? я то считал что в данном моменте у нас все залицензированно.
некоректно то что на гипер ставится лиценс манагер? или то что у нас проброшено?
(18) lohmatik, У них в лицензии написанно, что если вы подымаете на W2k?(3/8)Standart\Enterprise
то хост машина служит только для управления виртуалками и все, ее как рабочию использовать ни под что нельзя, а на гипервизор темболее софт нельзя ставить.
Сами спецы по лицензированию мелкомягкого конечно говорят что можно поставить софт для проброски ключей в вирт, но не сам манагер лицензий.
Пробывал Я их гипервизор, возможности установки на него софта не увидел, может версия конечо совсем ранняя была.
(14) alex1218, Сам использую proxmox ve, производительность практически не отличается от реального железа, главное чтоб дисковый массив был нормальный, основная проблема в нем.
А какой смысл в серваке 1С на виртуалке я не пойму? тем более с ключами - значит лицуха, другое дело бы если боялись отдела К в гости.
(21) DeLLtRoy, Смысл в инкапсуляции задач и независимости от железа на котором все крутится, плюсом переезд на новый сервер занимает не более ночи, ито если баз много и они все большие, а то и того меньше, ну и как же без резервного копирования на лету.
Спасибо Вам большое, до кое чего я сама методом научного тыка дошла, а с Вашей помощью все стало на свои места. Спасибо!
Во многих компаниях в качестве основной платформы автоматизации используется 1С. Так повелось и у нас. Однако процесс становления платформы был произведен без должного подхода, в связи с чем сначала у нас было 5 ключей защиты на 95 лицензий, затем появилось еще 3 физических ключа на предоставление еще 50 клиентских лицензий для 3-х юридических лиц. Ситуация дурацкая, так как каждый ключ по нормальному требует отдельных хост, а подходящих для этого серверов становилось все меньше, а маячащее увеличение количества пользователей и, следовательно, покупки новых ключей, заставило меня задуматься над альтернативным решением, позволяющим избежать лишней информационной нагрузки на наши сервера и вообще сделать систему с ключами более гибкой и, желательно, более устойчивой.
Выбор системы
Система виртуализации
В качестве системы визуализации был выбран esxi 5.1. Выбран за неплохую поддержку переброски USB устройств и потому что кроме ESX я разбираюсь только в Hyper-V, переброску устройств который не поддерживает.
Для переброски USB устройств в ESX, железо гостевой системы должно быть не ниже версии 7. Тогда появится возможность добавить USB контроллер и примаппить USB устройство в гостевую систему. Еще есть момент по поводу поддержки. Официально VMware поддерживает только определенный список устройств. И он не очень то большой. Однако рядовые ключи защиты Aladdin, похоже, будут поддерживаться. Список поддерживаемых устройств есть на официальном сайте здесь. А описание требований и положений по береброске USB в гостевую систему есть также на официальном сайте, в базе знаний здесь.
Есть и альтернативные способы проброски USB ключей в виртуальную среду, да и в физическую тоже. Это устройства и ПО так называемое USB over IP. Программные продукты в данном случае не очень интересно рассматривать, а вот железные в этом случае неплохо себя показывают. Самый яркий представитель, всем известный AnywhereUSB с 14-ю портами. Устанавливается в стойку, имеет два интерфейса и два входа питания (имеет ли реально два блока питания, я не знаю :)). Устройство всем хорошо, но стоит в среднем 60 тысяч рублей, что плохо укладывалось в наш бюджет.
Итак, после тестов и проб, платформу виртуализации выбрали и отказались от использования других продуктов.
Операционная система и драйвера HASP
В качестве ОС я выбрал Debian. Почему? Да просто так. По сути в этой конфигурации можно взять любой любимый дистрибутив. Но Debian мне всегда нравится стабильностью и хорошим репозиторием.
Настройка и проверка
Какой-то дополнительной настройки все это не требует. Ключ начинает работать практически из коробки.
Проверяем. Для проверки работоспособности в комплекте имеется программа haspdemo . При успешной идентификации ключа и начала работы, программа выведет что-то подобное в консоль:
This is a simple demo program for the HASP4 key
Copyright © Aladdin Knowledge Systems Ltd.
LOCALHASP_ISHASP: Result: 1
Using Passwords 15213 — 28875
LOCALHASP_HASPSTATUS: API version number is 8.0
port number 201
Key type: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 is connected.
LOCALHASP_HASPNETSTATUS: connected key is HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (hex)
NETHASP_READBLOCK: Failed: Return status: 10
Главное поле: LOCALHASP_ISHASP : Result: 1 . Сообщающее, что все впорядке. Далее написано и про то, какой ключ вставлен.
This is a simple demo program for the HASP4 key
Copyright © Aladdin Knowledge Systems Ltd.
LOCALHASP_ISHASP: Failed: status = -100
При том по сути все равно что происходит с ключом, он может быть не вставлен, служба может быть не запущена или еще что-то. Я пока видел только два значения LOCALHASP_ISHASP. Это либо : Result: 1 , либо : Failed: status = -100 . И последнее всегда соответствовало неработоспособности, а первое всегда означало, что все ОК. Документации к этому пакету я не нашел, по этому узнать какие еще есть статусы не получилось.
С ключом разобрались. Надо не забывать, что в мониторе ключей ваш новоиспеченный ключ появится только тогда, когда с него будет взята хотя бы одна лицензия. Тогда aladdin monitor покажет ту информацию, которую он обычно показывает: это типа ключа, количество взятых лицензий, всего лицензий, кто именно забрал лицензию и таймаут.
Форсировать это достаточно просто, достаточно указать в клиентском nethasp.ini руками новый менеджер лицензий. Но о настройке клиента чуть-чуть позже.
С этого момента можно считать первоначальную задачу выполненной. Теперь мы можем создать параллельно несколько виртуалок, в количестве, соответствующем количеству имеющихся физических ключей. Ресурсы такие виртуалки потребляют, естественно, копеечные.
Проблемы и решения
Единая точка отказа
Первая проблема, которая создается и у всех на виду, это создание точки отказа. Если до этого ключи были распределены по различным серверам и отказ больше одного ключа практически исключен, то в данном случае отказ работы физического сервера может повлечь за собой отказ от работы всей системы 1С, т.к. клиенты будут отваливаться в течение, по-моему, 600 секунд и через непродолжительное время отвалятся все и не смогут вернуться в систему. Что последует за таким инцидентом можно не рассказывать. Вариантов решения два и направлены в разном направлении. Первое решение это использование отказоустойчивой конфигурации ESX. Однако это целесообразно, если в вашей компании эта система уже развернута и уже выполнен ряд требования для поддержания работоспособности при отказе любого компонента. Другое решение более тривиальное:
Мы создаем группу A записей в DNS нашей компании. Например, key1, key2, key3 и так далее. Вносим DNS имена в nethasp.ini клиентов, распространяем файл с помощью групповой политики. Таким образом мы получаем достаточно гибкую структуру доступа. В этом случае после обнаружения существенной проблемы с виртуальным сервером esx, можно оперативно переместить ключи на любые другие сервера, в т.ч. на рабочие станции любых сотрудников. Параллельно заменяем A записи на новые. В течение некоторого времени кеш на клиентах закончится и они снова смогут взять себе новую лицензию и продолжить работу.
Рекомендую прописать обратные DNS записи для ключей, иначе aladdin monitor не будет показывать имя хоста, а покажет только ID менеджера лицензий, что не очень удобно.
Если в вашей компании и во все используется широковещательный метод доставки ключей, то все упрощается и при перемещении ключа на другой хост в пределах широковещательного домена ни как не скажется на работе.
Отваливаются ключи
Есть такая, достаточно распространенная проблема. Ключи отваливаются. При том никакой особенной связи замечено не было. Это происходит на разные контроллерах, даже на разных хостовых системах. Когда я переносил ключи и временно разместил их в другом месте под управлением VMware Player, отваливание ключей происходило часто. Выражается это достаточно тривиально. При запросе haspdemo , появляется строка LOCALHASP_ISHASP : Failed: status = -100 . Хотя ключ вставлен и обнаруживается. dmseg показывает не до конца понятные строки: usb 2-2.1: usbfs: USBDEVFS_CONTROL failed cmd aksusbd rqt 192 rq 139 len 8 ret -110
Решается проблема также тривиально, как и выглядит — рестартом сервиса. Но осадочек остается и пока это не выполнить, сервер раздавать ключи не будет. Так как хочется, что бы система работала безотказно, было решено написать скрипт, который бы сам восстанавливал работу менеджера лицензий. Так, с помощью друга, был написан скрипт, который запускает haspdemo и пытается понять, нормальный ли статус возвращается или нет:
[ "`haspdemo | sed -n 's/^LOCALHASP_ISHASP.* \(\-\?7*\)$/\1/p'`" == "-100" ] && service haspd restart
Далее этот скрипт вставляется в запуск по CRON каждую минуту и все. Даже если в вашей системе не будет наблюдаться проблема отваливающихся портов, данный скрипт, думаю, не помешает.
Проблема обнаружения ключа клиентом
И такая есть проблема. Заключается она в том, что клиент после потери ключа может не захотеть взять новый ключ. Также это проблема может выражаться и в других проявлениях. Например, если вы заменили пути к ключам в файле nethasp.ini, то клиентское приложение может вполне бодро продолжать сообщать о том, что ключей никаких нет и не видел никогда. Если к такой реакции быть не готовым, то проблема становится очень неприятной и начинаешь судорожно проверять работу всей системы и крыть матом 1С-ников, ибо все работает, но вот ГлавБух или, как назло, Генеральный, войти в 1Ску сейчас не может по непонятной причине и ты чувствуешь себя идиотом, вместо того, что бы быстро решить проблему. Однако помогало пока довольно простое решение. Необходимо очистить кеш 1С из профиля пользователя. В свое время я находил отдельный файл, который отвечает за эту информацию, на забыл какой :(
Ключи могут просто перестать работать
Против отказа оборудования ни кто не застрахован. И эти жалкие ключи тоже могут перестать работать. И самое важное в данном случае узнать об этом как можно раньше. Для этого мы будем использовать систему мониторинга Zabbix. Безусловно, разворачивать ее только для мониторинга за ключами бессмысленно, однако если заббикс уже стоит, то почему бы не прикрутить к нему и мониторинг за состоянием ключей.
Для этого нам нужно прописать собственный скрипт в файл настроек агента. Ищем файл конфигурации установленного zabbix_agent, называется он zabbix_agentd.conf. Открываем его и добавляем строку
Бонус
- NH_SERVER_ADDR. Здесь мы указываем список DNS имет или IP адресов серверов с менеджером лицензий через запятую.
- NH_USE_BROADCAST. Ставим значение в Disabled.
- NH_TCPIP_METHOD. По-умолчанию используется метод UDP. Можно поменять на TCP, но в целом в этом нет серьезной необходимости.
Еще момент по поводу отображения ключей в aladdin monitor. Вопреки расхожему мнению, свободными лицензиями являются не только те лицензии, которые отсутствуют в виде занятых в aladdin monitor, но и те, у которых в поле Timeout стоит 0. Значения обычно пропадают в течение 36-и часов, но все равно лицензии считаются свободными.
В завершение
Долго думал, есть ли смысл в подобной статье, все-таки все это можно найти в интернете, однако посчитав время, которое я сам потратил, что бы собрать всю информацию, то подумал, что будет очень хорошо, если хотя бы кому-то эта статья окажется полезной и сэкономит время.
Читайте также: