Аппаратные и программные лицензионные ключи в среде виртуальных машин

8

Я работаю с поставщиком, который поставляет серверное приложение, для активации которого требуется лицензирование. Существует два варианта: программное лицензирование и аппаратная (USB-ключ) активация. Каковы преимущества и недостатки использования аппаратных или программных лицензионных ключей в среде, где прикладное программное обеспечение работает на сервере на базе VMware? Аппаратный лицензионный ключ USB будет подключен к одному из них: https://www.digi.com/products/usb/anywhereusb

Есть два приложения, которые лицензируются: Поставщик: Программное обеспечение Iconics: Платформа GENESIS32 SCADA. Поставщик: Программное обеспечение Rockwell Automation: FactoryTalk (RSLinx).

Вот причина, по которой поставщик отдает предпочтение аппаратным ключам:

Мы обнаружили, что аппаратные ключи более стабильны, чем программные ключи, особенно в среде виртуальных машин. Программные ключи обычно прикрепляются к жесткому диску или идентификатору сетевой карты компьютера. При каждом изменении этого числа (сбой жесткого диска, перенастройка виртуальной машины и т. Д.) Лицензия теряется и ее необходимо перезагрузить с помощью производителя. Сегодняшнее лицензирование осуществляется через Интернет, и большинство серверов не имеют доступа к Интернету, поэтому решение проблем лицензирования стало основной головной болью. Аппаратные ключи хорошо работают для виртуальных машин, потому что они не находятся на виртуальной машине. Если у вас есть сбой образа или другой сбой сервера, вы можете скопировать новый образ, указать лицензионный ключ, и все готово.

virtual-machines licensing

— Шейн Веалти
источник

Кто является поставщиком программного обеспечения?

— ewwhite

@ewwhite Обновлено с информацией о поставщике / программном обеспечении.

— Шейн Веалти

12

Аппаратные ключи добавляют дополнительную точку отказа. Я видел, как они сломались. Когда они ломаются, вы не можете войти в свою систему считывания карт и дать новым людям доступ к зданию. вздох

Всегда используйте программный ключ, если у вас есть выбор. Например, FlexLM (один из наиболее распространенных серверов лицензий) - это настоящая боль в заднице, но как только он запущен, вам не о чем беспокоиться. С аппаратным ключом вам нужно беспокоиться о сбое ключа, сбое USBAnywhere, сбое программного обеспечения USBAnywhere и т. Д.

Я использовал эти устройства USBAnywhere, и они были довольно надежными, но я все равно предпочел бы программные ключи 10 из 10 раз.

— MDMarra
источник

5

Смотрите: Кроссплатформенная поддержка для сетевых концентраторов USB?

При прочих равных вам нужна гибкость программного ключа. Выполнение этих действий с использованием USB-ключа снижает мобильность вашей системы и не дает больших преимуществ.

Многие производители программного обеспечения осознали тот факт, что люди становятся полностью виртуальными и хотят использовать свои возможности, подобные vMotion. Если вам предоставляется опция для программной схемы лицензирования, используйте ее!

— ewwhite
источник

4

Программные ключи обычно прикрепляются к жесткому диску или идентификатору сетевой карты компьютера. При каждом изменении этого числа (сбой жесткого диска, перенастройка виртуальной машины и т. Д.) Лицензия теряется и ее необходимо перезагрузить с помощью производителя.

Идентификатор NIC компьютера (также известный как MAC-адрес) не должен изменяться в среде виртуальной машины. Кроме того, вы часто можете назначить MAC-адрес для соответствия MAC-адресу в файле лицензии. MAC-адрес обычно можно обмануть в операционной системе (я делаю это в Linux).

Сервер лицензий, использующий жестко закодированный идентификатор жесткого диска, вызывает проблемы: сбои дисков неизбежны, RAID-массивы встречаются часто, и время от времени заменять диски обычно.

Казалось бы, USB-ключ будет более подвержен сбоям, чем что-либо еще.

Мы управляем около 20 серверами лицензий, и все они используют MAC-адрес или более простой механизм.

— Стефан Ласевский
источник

1

Не совсем верно. NIC может измениться в среде VM, по крайней мере, при определенных обстоятельствах. У меня есть сервер живой миграции (Hyper V), который вызывает проблемы после отработки отказа. В нашем случае мы пытаемся решить эту проблему, указав MAC в наших конфигурационных файлах. Должно работать, но у меня есть другие проблемы, о которых нужно беспокоиться.

— Бессонница

Ну, я сказал "не должен". не "не будет" :) Это, безусловно, может произойти, но образ виртуальной машины должен иметь тот же MAC, даже если он перемещен на другую виртуальную машину.

— Стефан Ласевский,

1

Я понимаю, что ваш вопрос относится к среде VMware, но я думаю, что общий вопрос относится к другим платформам виртуализации, включая Hyper-V.

Недавно я виртуализировал устаревший сервер, на котором работала служба, зависящая от аппаратных ключей лицензирования на основе USB, и обнаружил, что они не работают изначально в среде Hyper-V. В Руководстве по развертыванию Hyper-V сказано следующее:

No access to a physical COM port is available from a virtual machine.

Вы можете подключить COM-порт вашей виртуальной машины к именованным каналам, но, очевидно, не к действительным последовательным портам. По-видимому, это прежде всего функция отладки. Вы можете предоставить доступ виртуальной машине к последовательному порту, используя переадресацию COM-порта, такую как KernelPro USB через Ethernet.

Кроме того, программное обеспечение и драйверы для лицензионного ключа должны поддерживать установку на Window Server, а в нашем случае на Server Core, если вы хотите, чтобы лицензионный ключ был установлен на хост-сервере.

В итоге я установил лицензионный ключ и программное обеспечение на рабочую станцию, а затем использовал его в качестве «сервера лицензирования» этого сайта. Это добавляет около десяти разных вещей, которые теперь могут сломать это программное обеспечение. Лицензионный ключ на основе программного обеспечения избавил бы меня от многих проблем, и я подозреваю, что это более надежное решение.