Sun WorkShop インストールとライセンス ホーム目次前ページへ次ページへ索引

第 1 章

フローティングライセンスのライセンスサーバー構成

フローティングライセンスを使用する場合は、3 通りのライセンスサーバー構成が考えられます。 どのサーバー構成でも、複数の開発者が FLEXlm ライセンス管理ソフトウェアを使用して、ネットワーク上のライセンスされたソフトウェアに同時にアクセスすることができます。

ここでは、100 個のライセンスを管理するものとして、それぞれのライセンスサーバー構成の特長について考えてみましょう。

単一の独立サーバー構成

単一の独立サーバー構成は、開発者のマシン、ライセンスサーバー、アプリケーションサーバーがネットワーク上で近接している場合に適しています。 この構成がデフォルトであり、インストールと保守がもっとも簡単です。

図 1-1 に、単一の独立ライセンスサーバー構成の仕組みを示します。


図 1-1   単一のライセンスサーバーでライセンスを取得するプロセス

この例では、次のようにしてライセンスを取得しています。

  1. C++ の開発者がプログラムを再コンパイルするという例で説明します。 この開発者は、自分のデスクトップマシン (envoy) で作業しています。 envoy には、アプリケーションサーバー tools の Sun Visual WorkShop C++ がマウントされています。 ネットワーク上にはライセンスサーバー (lic1) が 1 台だけあり、開発者の所属する部門が購入した 10 個の RTU (使用権) を管理しています。

  2. 開発者がプログラムのコンパイルを開始すると、tools 上の Sun Visual WorkShop C++ は、lic1 にライセンストークンの要求を送ります。 lic1 に使用可能なトークンがある場合は、要求が受け入れられて、コンパイル作業が完了します。

  3. 同じグループの他の開発者によって 10 個のトークンがすべて使用されている場合、開発者の要求は自動的に待ち行列に入れられ、他のユーザーがトークンを解放してから、トークンを使用できるようになります。

例 : 単一の独立サーバー構成

A 社は、科学技術計算アプリケーションを開発する小規模企業です。 A 社では、最新リリースの Solaris を稼働した Sun ワークステーション 10 台を保有し、Sun WorkShop Professional C の RTU (使用権) 6 個を取得しています。 また、限られた資源を有効に利用するため、A 社の NFS サーバー sampson は、ライセンスサーバー兼アプリケーションサーバーに設定されています。 NFS サーバーは、全ユーザーが共通の作業領域として使用するファイルサーバーです。図 1-2に、A 社のネットワーク構成を示します。


図 1-2   NFS サーバーをライセンスサーバーとして使用

sampson は信頼性が高く、アップグレードもリブートも頻繁には行われないため、A 社のライセンストークン用サーバーとして適しています。 また、sampson には共通の開発領域があるため、障害が発生した場合にはすぐに通知されます。

例 : マルチプラットフォーム環境

B 社は、Solaris オペレーティング環境向けのビデオゲームを開発・販売しています。 主任開発者は、この会社の開発コードを Intel 版 Solaris マシンに移植することを決定し、 Pentium コンピュータと Sun Visual WorkShop C++ を購入しました。 さらに、Sun Visual WorkShop C++ を x86 マシンにローカルにインストールし、ライセンスパスワードを既存の SPARC ライセンスサーバー delight に追加し、再コンパイルの準備が整いました。図 1-3に、B 社のネットワーク構成を示します。


図 1-3   x86 アプリケーションサーバーと SPARC ライセンスサーバーを使用

複数の独立サーバー構成

複数の独立サーバー構成では、複数の独立したライセンスサーバーを設定し、どのサーバーからでもライセンストークンを取得することができます。 この構成は、中規模から大規模のソフトウェア開発環境がネットワーク上に分散している場合に適しています。 購入したライセンストークンの総数を複数のライセンスサーバーに分散させることにより、常にいくつかのライセンストークンを使用することができるようになります。 ただし、単一の独立ライセンスサーバーの場合と同様、電源が入っていないサーバーからライセンストークンを取得することはできません。

複数の独立サーバー構成では、ライセンスサーバーをネットワーク全体に効率的に配置することによって、ライセンス要求への応答性を最大限に高め、管理のオーバーヘッドを最小限に抑えることができます。 たとえば、RTU 100 個を購入した場合、10 台の独立サーバーにライセンストークンを 10 個ずつ分散させることができます。

図 1-4 に、複数の独立ライセンスサーバー構成の仕組みを示します。


図 1-4   複数の独立ライセンスサーバーでライセンスを取得するプロセス

この例では、次のようにしてライセンスを取得しています。

  1. C++ の開発者が、自分のデスクトップマシン envoy で、プログラムを再コンパイルしようとしています。 envoy には、アプリケーションサーバー tools の Sun Visual WorkShop C++ がマウントされています。 また、ネットワークには、デフォルトのサーバー lic1 に加えて、2 台のライセンスサーバー (lic2_ と lic3) が設定され、 それぞれに 10 個ずつライセンストークンがあります。

  2. 開発者がプログラムのコンパイルを開始すると、tools 上の Sun Visual WorkShop C++ は、lic1 にライセンストークンの要求を送ります。 lic1 に使用可能なトークンがある場合は、要求が受け入れられて、コンパイル作業が完了します。

  3. 同じグループの他の開発者によって、lic1 の 10 個のライセンストークンがすべて使用されている場合、tools は自動的に lic2 のトークンを探し、このサーバーにも使用できるライセンストークンがない場合には lic3 を探します。 それでもトークンを得られない場合には、開発者の要求は lic1 の待ち行列に入れられ、最初に解放されたトークンを取得することになります。

例 : 複数の独立サーバー構成

C 社は金融サービスのブローカーです。 業務の性質上、Sun WorkShop Professional C のライセンストークンが、常にいくつか使用可能であることが必要です。 この会社は SunTM WorkShopTM TeamWare と Sun Visual WorkShop C++ を購入しました。 3 台の大型サーバー (bull、bear、crash) をライセンスサーバーとして設定し、他の 2 台のサーバー (dollars と cents) をアプリケーションサーバーとして設定する計画です。

図 1-5 に、C 社のネットワーク構成を示します。


図 1-5   複数の独立ライセンスサーバーで 2 台のアプリケーションサーバーをサポート

この例では、ライセンストークンを bull、bear、crash 間に分散させたため、Sun WorkShop Professional C のトークンをほぼ常に使用できるようになりました。 また、ライセンスサーバーを使用できない場合に備えて、3 台のライセンスサーバーをそれぞれ異なるサブネットと電源装置に接続するという対策をとりました。 C 社は当初、重複サーバー構成 (「重複サーバー構成」を参照) を採用することも検討しましたが、すべてのトークンが「ほとんどの時間に利用可能」であるよりも、いくつかのライセンストークンが「常に必ず利用可能」である方が望ましいため、最終的に複数の独立サーバー構成を選択しました。

複数の独立ライセンスサーバーからなるサーバープールでは、ユーザーは、必要に応じて複数のライセンスサーバーを確認し、使用可能なライセンストークンを見つけることができます。 C 社のサーバープールは、次の手順に沿って設定されています。

1. ライセンス申請書に必要事項を記入します。

ライセンスサーバーごとに別々のライセンス申請書が必要です。 申請書の記入方法と送付先 (Sun ライセンス・パスワード・センター) については、『Sun WorkShop インストールガイド』の第 2 章を参照してください。
申請書が受理されると、ライセンス製品ごとにライセンスファイルが発行されます。

2. アプリケーションサーバー cents に、Sun WorkShop Professional C と Sun WorkShop TeamWare をインストールします。

インストール方法については、『Sun WorkShop インストールガイド』の第 3 章を参照してください。

3. アプリケーションサーバー dollars に、Sun WorkShop Professional C と Sun Visual WorkShop C++ をインストールします。

4. ライセンスサーバー bull に、FLEXlm ライセンス管理ソフトウェアをインストールします。

インストール方法については、『Sun WorkShop インストールガイド』の第 3 章を参照してください。

5. ライセンスサーバー bull に、Sun WorkShop Professional C のライセンスをインストールします。

インストール方法については、『Sun WorkShop インストールガイド』の第 3 章を参照してください。
/etc/opt/licenses/LIC_CONFIG_SCRIPT スクリプトをアプリケーションサーバーにコピーして実行すると、ルーターファイルが作成されます。 ルーターファイルの詳細については、第 2 章を参照してください。

6. ライセンスサーバー bull に、Sun Visual WorkShop C++ のライセンスをインストールします。

7. ライセンスサーバー bear に、FLEXlm ライセンス管理ソフトウェアをインストールします。

8. ライセンスサーバー bear に、Sun WorkShop Professional C のライセンスをインストールします。

9. ライセンスサーバー bear に、Sun WorkShop TeamWare のライセンスをインストールします。

10. ライセンスサーバー crash に、FLEXlm ライセンス管理ソフトウェアをインストールします。

11. ライセンスサーバー crash に、Sun WorkShop Professional C のライセンスをインストールします。

12. ライセンスサーバー crash に、Sun Visual WorkShop C++ のライセンスをインストールします。

13. アプリケーションサーバー dollars 上に install-dir/SUNWspro/license_dir/lic_router を作成し (すでに存在すれば、更新し)、ライセンスサーバー bull、bear、および crash をこの順序で記述します。

この例の場合、まず、アプリケーションサーバー dollars のいちばん近くにあるライセンスサーバー bull でライセンストークンを探し、見つからない場合は、その次に近くにある bear、crash の順に探していくことになります。 トークン検索時には、各ライセンスサーバーの /etc/opt/licenses/licenses_combined ファイルの SERVER 行に指定されている TCP ポート番号を使うようにします。 たとえば、3 台のライセンスサーバーすべてが TCP ポート 7588 を使用する場合、lic_router ファイルに次のように記述します。
7588@bull:7588@bear:7588@crash

14. アプリケーションサーバー cents 上に install-dir/SUNWspro/license_dir/lic_router を作成し (すでに存在すれば、更新し)、ライセンスサーバー crash、bear、および bull をこの順序で記述します。

アプリケーションサーバー cents にいちばん近いライセンスサーバーは crash なので、まず crash でトークンを探し、見つからない場合は bear、bull の順に探していきます。 トークン検索時には、各ライセンスサーバーの
/etc/opt/licenses/licenses_combined ファイルの SERVER 行に指定されている TCP ポート番号を使うようにします。 たとえば、3 台のライセンスサーバーすべてが TCP ポート 7588 を使用する場合、lic_router ファイルに次のように記述します。

7588@crash:7588@bear:7588@bull

これら 3 台のライセンスサーバーのいずれかに新しいライセンスを追加しても、ルーターファイルを更新する必要はありません。 ルーターファイルを更新するのは、新しいライセンスサーバーをネットワークに追加する場合だけです。

重複サーバー構成

重複サーバー構成では、3 台のサーバーが 1 台の論理サーバーとして機能するため、ライセンストークンをまとめて管理することができます。 この構成では、2 台の重複ライセンスサーバーが稼働していて、相互に連絡できることが必須です。 この条件が満たされない場合は、どのライセンストークンも使用できません。 このため、重複サーバー構成でトークンを使用するためには、サーバー 3 台のうち 2 台が必ず使用可能でなくてはなりません。 この構成の主な利点は、いずれかのトークンを使用できる場合には、すべてのトークンを使用できる可能性が高いということですが、管理面での負担は大きくなります。

重複サーバーのうちの 1 台は、ライセンストークンを発行するマスターサーバーです。 このため、他のサーバーよりも処理負荷が大きくなります。 マスターサーバーが利用できない場合は、構成中で次に使用できるサーバーがマスターサーバーになります。

図 1-6 に、重複ライセンスサーバー構成でのライセンスの取得プロセスを示します。


図 1-6   重複ライセンスサーバーでライセンスを取得するプロセス

この例では、次のようにしてライセンスを取得しています。

  1. C++ の開発者が、自分のデスクトップマシン envoy で、プログラムを再コンパイルしようとしています。 envoy には、アプリケーションサーバー tools の Sun Visual WorkShop C++ がマウントされています。 また、ネットワーク上には、マスターサーバー lic1、2 台の代替サーバー lic2 と lic3 を設置した重複サーバー構成を展開しています。 この重複サーバー構成が、開発者のグループが購入した 30 個のライセンストークンを仲介します。

  2. 開発者がプログラムのコンパイルを開始すると、tools 上からマウントされている Sun Visual WorkShop C++ は、lic1 にライセンストークンの要求を送ります。 サーバー lic1 はまず最初に lic2 の有無をチェックします。 lic2 が見つからなければ、次に lic3 を見つけようとします。 lic2 または lic3 が見つかり、ライセンストークンを使用できる場合は、要求が受け入れられて、コンパイル作業が完了します。

  3. 同じグループの他の開発者によって、30 個のライセンストークンがすべて使用されている場合は、開発者の要求は待ち行列に入れられ、最初に解放されたライセンストークンを取得することになります。 lic1 が lic2 と lic3 のどちらも確認できない場合 (両方のマシンが修理のために停止している場合など) には、ライセンストークンを使用することができません。lic1 が停止していても、lic2 と lic3 が使用できる場合には、すべてのライセンストークンを使用できます。

サン・マイクロシステムズ株式会社
Copyright information. All rights reserved.
 		ホーム   |   目次   |   前ページへ   |   次ページへ   |   索引