ライセンス マネージメント システムはライセンスの消費ポリシーをライセンスプールに適合させる手段を装備しています。 このポリシーはそれぞれの使用のシナリオに従い効率的にチェックアウトされるライセンスの数を決定します。例えば、同じアプリケーションを同じワークステーションで2回リクエストしているユーザーは単一のライセンスかあるいは複数のライセンスをライセンスプールから消費できます。
例１： Flexera Flexnet のパブリッシャー (FlexLM)
FlexLMではこのポリシーはFlexLM のライセンスファイルにあるDUP_GROUP の属性によって設定されます。 オプションとなる DUP_GROUP flags は以下の通りです。
Site, None, U (user), H (Host), D (Display), V (Vendor) UHDVのすべての組み合わせは可で、DUP_MASK はロジカルかこの組み合わせです。 例えば、 DUP_GROUP=UHD は同じホストおよびディスプレイ上のユーザーが複数のフィーチャーをリクエストしている場合、追加のライセンスを消費できないことを意味します。
例２： Reprise RLM
Reprise RLM ではこのポリシーはライセンスファイルにある‘share’ の属性によって設定されます。 1つのライセンスはプロセス間で同じusername（ユーザー名）(U), hostname（ホスト名） (H), あるいは ISV-defined data (I), またはそれらのあらゆる組み合わせで共有されます。 さらに、共有されたライセンスの最大数は ‘share’ の属性で特定されることも可能です。例えば、 share=U:3 は１ユーザーがホストマシン上で単一のライセンスを消費しながら、ライセンスのある最大3つのフィーチャーのアプリケーションを開くことができることを意味します。
消費ポリシーの制御
弊社の経験から、ソフトウェアの製作者(‘vendors’) は単一のライセンスを消費しながら別のワークステーション上での複数のセッションの要請を想定しません。 その結果、ユーザーは別のホストマシン上の複数のライセンスを不注意にもチェックアウトし、組織内のライセンス使用を非最適化しかねません。 複数のライセンス マネージメント システムがあり、それぞれが消費ポリシーの設定方法を持っていることはこの非最適化をさらに悪化させかねません。
OpenLMのソリューション
OpenLM はこの問題を処理する直観で理解できる方法を提供します。つまり、各ベンダーは “Vendor policy”に属するかもしれません。 この属性はユーザーごとに単一のあるいは複数のライセンスがチェックアウトされるかどうかを決定します。 さらに、OpenLM のアラートシステム はユーザーがライセンス消費ポリシーに反し、同じフィーチャーのライセンスを同時に消費する場合はシステムアドミニストレーターへの通知用の内蔵アラートを提供します。
OpenLMをまだ使用していない方はフリーダウンロードのページよりダウンロードしてください。
BrokerとAgentはオプショナルです。
試用にあたりいかなる場合でもご購入の義務は生じませんのでお気軽にお試しください。
