Я работаю с поставщиком, который предоставляет серверное приложение, для активации которого требуется лицензия. Существует два варианта: лицензирование на основе программного обеспечения и активация на основе оборудования (USB-ключ). Каковы плюсы и минусы использования аппаратных или программных лицензионных ключей в среде, где прикладное программное обеспечение работает на сервере на базе VMware? Лицензионный ключ USB-оборудования будет вставлен в один из них: https://www.digi.com/products/usb/anywhereusb
Лицензируются два приложения: Производитель: Iconics Software: платформа GENESIS32 SCADA Производитель: Rockwell Automation Software: FactoryTalk (RSLinx)
Вот почему производитель отдает предпочтение аппаратным ключам:
Мы обнаружили, что аппаратные ключи более стабильны, чем программные, особенно в среде виртуальных машин. Программные ключи обычно прикрепляются к жесткому диску или идентификатору сетевой карты компьютера. Каждый раз, когда это число изменяется (сбой жесткого диска, перенастройка виртуальной машины и т. Д.), Лицензия теряется, и ее необходимо повторно загрузить с помощью производителя. Сегодняшнее лицензирование осуществляется через Интернет, и большинство серверов не имеют доступа в Интернет, поэтому решение вопросов лицензирования стало большой головной болью. Аппаратные ключи хорошо подходят для виртуальных машин, потому что они не находятся на виртуальной машине. Если у вас сбой образа или другой сбой сервера, вы можете скопировать новый образ, указать на лицензионный ключ, и все готово.
Аппаратные ключи добавляют дополнительную точку отказа. Я видел, как они ломались. Когда они сломаются, вы не сможете войти в систему смахивания карт и предоставить новым людям доступ в здание. вздох
Всегда используйте программный ключ, если у вас есть выбор. Например, FlexLM (один из наиболее распространенных серверов лицензий) - настоящая головная боль, но как только он заработает, вам не о чем беспокоиться. Имея аппаратный ключ, вы должны беспокоиться о сбое ключа, отказе USBAnywhere, сбое программного обеспечения USBAnywhere и т. Д.
Я использовал эти устройства USBAnywhere, и они оказались довольно надежными, но я все же предпочел бы программные ключи в 10 случаях из 10.
Видеть: Кроссплатформенная поддержка сетевых USB-концентраторов?
При прочих равных вам нужна гибкость программного ключа. Использование USB-ключа снижает портативность вашей системы и не дает больших преимуществ.
Многие производители программного обеспечения осознали тот факт, что люди переходят на полностью виртуальные системы и хотят использовать свои возможности, подобные vMotion. Если есть возможность использовать схему лицензирования на основе программного обеспечения, используйте ее!
Программные ключи обычно прикрепляются к жесткому диску или идентификатору сетевой карты компьютера. Каждый раз, когда это число изменяется (сбой жесткого диска, перенастройка виртуальной машины и т. Д.), Лицензия теряется, и ее необходимо повторно загрузить с помощью производителя.
Идентификатор сетевого адаптера компьютера (также известный как MAC-адрес) не должен изменяться в среде виртуальной машины. Кроме того, вы часто можете назначить MAC-адрес, соответствующий MAC-адресу в файле лицензии. MAC-адрес обычно можно подделать в операционной системе (я делаю это в Linux).
Сервер лицензий, который полагается на жестко запрограммированный идентификатор жесткого диска, запрашивает проблемы - отказы дисков неизбежны, массивы RAID - обычное дело, и время от времени заменять диски - это нормально.
Казалось бы, USB-ключ будет более подвержен сбоям, чем что-либо еще.
Мы управляем примерно 20 лицензионными серверами, и все они используют MAC-адрес или более простой механизм.
Я понимаю, что ваш вопрос относится к среде VMware, но я думаю, что общий вопрос актуален и для других платформ виртуализации, включая Hyper-V.
Недавно я виртуализировал устаревший сервер, на котором выполнялась служба, зависящая от аппаратных ключей лицензирования на основе USB, и обнаружил, что они изначально не работают в среде Hyper-V. В руководстве по развертыванию Hyper-V сказано следующее:
No access to a physical COM port is available from a virtual machine.
Вы можете подключить COM-порт вашей виртуальной машины к именованным каналам, но не к фактическим последовательным портам. Видимо это в первую очередь функция отладки. Вы жестяная банка обеспечить доступ виртуальной машины к последовательному порту с помощью переадресации COM-порта, например USB over Ethernet в KernelPro.
Кроме того, программное обеспечение и драйверы для лицензионного ключа должны поддерживать установку на Window Server и, в нашем случае, на Server Core, если вы хотите, чтобы лицензионный ключ был установлен на хост-сервере.
В итоге я установил лицензионный ключ и программное обеспечение на рабочую станцию, а затем использовал их в качестве «сервера лицензирования» того сайта. Это добавляет около десяти разных вещей, которые теперь могут сломать это программное обеспечение. Программный лицензионный ключ избавил бы меня от многих проблем, и я подозреваю, что это более надежное решение.