VM環境におけるハードウェアとソフトウェアのライセンスキー

I am working with a vendor who is supplying a server-based application which requires licensing for activation. There are two options, software-based licensing and hardware (USB-dongle) based activation. What are the pros and cons to using hardware or software license keys in an environment where the application software is running on a VMware based server? The USB hardware license key will be plugged into one of these: https://www.digi.com/products/usb/anywhereusb

ライセンスされている2つのアプリケーションがあります。 ベンダー:Iconicsソフトウェア:GENESIS32 SCADAプラットフォーム ベンダー:Rockwell Automationソフトウェア:FactoryTalk(RSLinx)

これが、ベンダーがハードウェアキーを好む理由として挙げた理由です。

ハードウェアキーはソフトウェアキーよりも安定しています。   特にVM環境では。ソフトウェアキーは通常添付されています   コンピュータのハードドライブまたはNIC ID。この番号が変わるたびに   (ハードドライブの故障、VMの再設定など)ライセンスが失われ、   製造元の支援を受けて再ロードする必要があります。今日の   ライセンスはインターネットを介して行われ、ほとんどのサーバーにはありません   インターネットへのアクセス、ライセンス問題への対応が大きな問題となっています。   頭痛。ハードウェアキーはVMには適していません。   VMに常駐します。画像障害または他のサーバーがある場合   失敗した場合は、新しいイメージをコピーして、ライセンスキーをポイントしてください。   あなたは立ち上がって走っています。

8
nl ru de
ソフトウェアベンダは誰ですか?
追加された 著者 Pedro,
@ewwhiteベンダ/ソフトウェア情報で更新されました。
追加された 著者 Kumquats,

4 答え

The hardware keys add an extra point of failure. I've seen them break. When they do break, you can't log into your card swipe system and give new people access to the building. sigh

あなたが選択を持っている場合は常にソフトウェアキーに行きます。たとえば、FlexLM(最も一般的なライセンスサーバーの1つ)はお尻の痛みですが、起動して実行すれば、心配する必要はありません。ハードウェアキーでは、キーの失敗、USBAnywhereの失敗、USBAnywhereソフトウェアの失敗などを心配する必要があります。

私はそれらのUSBAnywhereデバイスを使用しました、そしてそれらはかなりしっかりしています、しかし私はまだ10回のうち10回のソフトウェアキーを好むでしょう。

12
追加された

See: Cross platform support for network attached USB hubs?

他のすべてと同じ、あなたはソフトウェアキーの柔軟性を望みます。 USBドングルを使用してこの作業を実行すると、システムの移植性が低下し、それほどメリットがありません。

多くのソフトウェア製造業者は、人々が完全に仮想化しており、vMotionのような機能を活用したいという事実に気付いています。ソフトウェアベースのライセンススキームの選択肢がある場合は、それを使用してください。

5
追加された

ソフトウェアキーは通常、ハードドライブまたはコンピュータのNIC IDに添付されています。   コンピューター。この数値が変わるたびに(ハードドライブの障害、VM)   再構成など)ライセンスが失われたため、リロードする必要があります。   メーカーの協力を得て。

コンピューターのNIC ID(MACアドレスとも呼ばれる)は、VM環境では変更しないでください。さらに、ライセンスファイル内のMACアドレスと一致するようにMACアドレスを割り当てることもできます。 MACアドレスは通常、オペレーティングシステムで偽造される可能性があります(私はLinux上でそれを行います)。

ハードドライブのハードコードされたIDを当てにしているライセンスサーバーはトラブルを求めています - ドライブの故障は避けられない、RAIDアレイは一般的です、そしてそれは時々ドライブを交換するのが普通です。

USBドングルは他の何よりも故障しやすいと思われます。

私たちは約20のライセンスサーバーを管理しています、そしてそれらのすべてはMACアドレスかより簡単なメカニズムに頼ります。

4
追加された
まあ、私は「すべきではない」と言った。そうではありません:)確かに起こり得ますが、VMイメージは別のVMに移動されたとしても同じMACであるべきです。
追加された 著者 Anders Lindén,
そうではありません。 NICは、少なくとも特定の状況下では、VM環境で変わる可能性があります。フェイルオーバー後に問題が発生するライブマイグレーションサーバー(Hyper V)があります。私たちの場合は、設定ファイルでMACを指定して問題を解決しようとしています。動作するはずですが、私は今のところ心配するべき他の問題があります。
追加された 著者 jrab227,

あなたの質問はVMware環境にあると思いますが、一般的な質問はHyper-Vを含む他の仮想化プラットフォームに関連していると思います。

私は最近、ハードウェアのUSBベースのライセンスキーに依存するサービスを実行しているエージングサーバーを仮想化し、それらがHyper-V環境でネイティブに機能しないことを発見しました。 『Hyper-V導入ガイド』には次のように記載されています。

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

仮想マシンのCOMポートを名前付きパイプに接続できますが、実際のシリアルポートには接続できません。どうやらこれは主にデバッグ機能です。 KernelProのUSB over EthernetなどのCOMポートリダイレクタを使って、仮想マシンからシリアルポートへのアクセスを提供することができます。

さらに、ライセンスキーをホストサーバーにインストールする場合は、ライセンスキー用のソフトウェアとドライバーをWindow Server、およびこの場合はServer Coreにインストールすることをサポートする必要があります。

ワークステーションにライセンスキーとソフトウェアをインストールし、それをそのサイトの「ライセンスサーバー」として使用することになりました。これは今このソフトウェアを壊すことができる約10の異なることを追加します。ソフトウェアベースのライセンスキーは私に多くの悩みを救ったであろう、そして私はより信頼できる解決策であると思う。

1
追加された