Во многих компаниях в качестве основной платформы автоматизации используется 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 мне всегда нравится стабильностью и хорошим репозиторием.
В качестве драйверов берется достаточно популярный пакет от компании Etersoft. Взять скомпилированный пакет для своего дистрибутива можно на FTP сервере компании: ftp.etersoft.ru/pub/Etersoft/HASP/stable.
После установки пакета появляется служба haspd, которая и управляет работой ключа.
Настройка и проверка
Какой-то дополнительной настройки все это не требует. Ключ начинает работать практически из коробки.
Проверяем. Для проверки работоспособности в комплекте имеется программа 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)
LOCALHASP_ENCODEDATA: OK.
53 C1 F1 AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F [S.......51....]
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [.....")..~.V.p{c]
23 B4 9B E6 | 2F 17 | | [#…/.]
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.* \(\-\?[0-9]*\)$/\1/p'`" == "-100" ] && service haspd restart
Далее этот скрипт вставляется в запуск по CRON каждую минуту и все. Даже если в вашей системе не будет наблюдаться проблема отваливающихся портов, данный скрипт, думаю, не помешает.
Проблема обнаружения ключа клиентом
И такая есть проблема. Заключается она в том, что клиент после потери ключа может не захотеть взять новый ключ. Также это проблема может выражаться и в других проявлениях. Например, если вы заменили пути к ключам в файле nethasp.ini, то клиентское приложение может вполне бодро продолжать сообщать о том, что ключей никаких нет и не видел никогда. Если к такой реакции быть не готовым, то проблема становится очень неприятной и начинаешь судорожно проверять работу всей системы и крыть матом 1С-ников, ибо все работает, но вот ГлавБух или, как назло, Генеральный, войти в 1Ску сейчас не может по непонятной причине и ты чувствуешь себя идиотом, вместо того, что бы быстро решить проблему. Однако помогало пока довольно простое решение. Необходимо очистить кеш 1С из профиля пользователя. В свое время я находил отдельный файл, который отвечает за эту информацию, на забыл какой :(
Ключи могут просто перестать работать
Против отказа оборудования ни кто не застрахован. И эти жалкие ключи тоже могут перестать работать. И самое важное в данном случае узнать об этом как можно раньше. Для этого мы будем использовать систему мониторинга Zabbix. Безусловно, разворачивать ее только для мониторинга за ключами бессмысленно, однако если заббикс уже стоит, то почему бы не прикрутить к нему и мониторинг за состоянием ключей.
Для этого нам нужно прописать собственный скрипт в файл настроек агента. Ищем файл конфигурации установленного zabbix_agent, называется он zabbix_agentd.conf. Открываем его и добавляем строку
UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed 's/^.* \(\-\?[0-9]*\)$/\1/g'
Это позволит по команде собрать цифровое значение в поле LOCALHASP_ISHASP. В самом заббиксе все добавляется уже примитивно, создаем Item для нужного хоста или шаблона, в качестве Type указываем Zabbix agent, в качестве параметра key указываем hasp.status. Тип значения — float. При желании создаем триггер, по которому вам будет присылаться письмо или смска о том, что ключ не работает. Триггер этот лучше настроить таким образом, что бы требовал как минимум 2х срабатываний и покрывал время, которое требуется скрипту автовосстановления, который описывался выше, иначе будут появляться ложные сообщения о проблемах с ключем.
При верной настройке только при полной неработоспособности ключа вам будет приходить уведомление о проблемах.
Бонус
Для меня оказалось сюрпризом, но многие действительно не знают, что можно заставить клиентские части 1С искать ключи по указанным IP адресам, используя TCP или UDP соединение. Действительно, многие настраивают инфраструктуру так, что бы в каждом широковещательном домене было достаточное количество ключей. Это дикость. Для тех, кто еще не в курсе вот краткая инструкция:
Для управления доступа к hasp ключу, на клиенте есть файл nethasp.ini. Находится он в папке \conf каталога 1С. Нас интересует секция [NH_TCPIP]. В этом разделе нам нужно раскомментировать или создать следующие параметры:
NH_SERVER_ADDR. Здесь мы указываем список DNS имет или IP адресов серверов с менеджером лицензий через запятую.
NH_USE_BROADCAST. Ставим значение в Disabled.
NH_TCPIP_METHOD. По-умолчанию используется метод UDP. Можно поменять на TCP, но в целом в этом нет серьезной необходимости.
Еще момент по поводу отображения ключей в aladdin monitor. Вопреки расхожему мнению, свободными лицензиями являются не только те лицензии, которые отсутствуют в виде занятых в aladdin monitor, но и те, у которых в поле Timeout стоит 0. Значения обычно пропадают в течение 36-и часов, но все равно лицензии считаются свободными.
В завершение
Долго думал, есть ли смысл в подобной статье, все-таки все это можно найти в интернете, однако посчитав время, которое я сам потратил, что бы собрать всю информацию, то подумал, что будет очень хорошо, если хотя бы кому-то эта статья окажется полезной и сэкономит время.
*Админка под Win*