test

Sun Java Enterprise System 5 インストール計画ガイド

第 2 章 実装の仕様の作成

配備アーキテクチャーは、Java ES ソリューションの上位レベルの技術的記述であり、ソリューションをインストールおよび設定するために必要なすべての情報が含まれているわけではありません。この章では、配備アーキテクチャーを分析し、一連の実装仕様を作成する手順について説明します。実装仕様を作成するのは、ソリューションをインストールおよび設定するために必要な補足情報の作成作業を準備するためです。

この章では、実装仕様に関する次の内容を説明します。

配備アーキテクチャーの分析

図 2–1 は、一般的な配備アーキテクチャーの例です。この配備アーキテクチャーは、ポータルと通信サービスを提供する Java ES ソリューションを定義します。このアーキテクチャーでは、Access Manager を使用して、通信サービスへのシングルサインオンを実現しています。また、Portal Server と Communications Express の両方を使用して、メッセージングサービスとカレンダーサービスをエンドユーザーに提供しています。このアーキテクチャーには、Communications Suite のコンポーネントが含まれています。

図 2–1 配備アーキテクチャーの例

16 台のコンピュータと、それらのコンピュータに分散された Java ES コンポーネントを示します。

図 2–1 には、次のものを含めて、ソリューションについての多くの情報が含まれます。

配備アーキテクチャー例のこれらの特性は、ソリューションがどのようにインストールおよび設定されるかに影響します。インストールの計画を始めるにあたり、まず同じようにして配備アーキテクチャーを分析し、何台のコンピュータシステムを監視するか、各コンピュータシステムに何個のコンポーネントインスタンスをインストールするか、どの冗長性戦略を利用するか、などを決定します。

コンピュータハードウェアおよびオペレーティングシステム仕様の作成

配備アーキテクチャーで定義される情報に加えて、ソリューションで使用する各コンピュータのオペレーティングシステムを指定する必要があります。また、インストール先のハードウェアに関して追加の情報を作成する必要もあります。そのための決定はサービス品質要件に基づいて行われ、サービス品質要件を満たすために必要なハードウェアおよびオペレーティングシステムに関する最善の推測に相当します。

図 2–1 で示した配備アーキテクチャーのサービス品質要件を満たすために、表 2–1 のオペレーティングシステム仕様およびコンピュータハードウェア仕様が作成されました。

表 2–1 サンプル配備アーキテクチャーのコンピュータハードウェア/OS 仕様

コンピュータシステム 

ハードウェアモデル 

CPU の数 

RAM (G バイト) 

ディスク数 

オペレーティングシステム 

mscs01 

mscs02 

Sun Fire V440 Server 

4 

16 

4 

Solaris 9 

commx01 

commx02 

Sun Fire V240 Server 

2 

4 

2 

4 

Solaris 10 

ds01 

ds02 

Sun Fire V240 Server 

2 

8 

4 

Solaris 10 

am01 

am02 

Sun Fire V240 Server 

2 

8 

4 

Solaris 10 

ms-mmp01 

ms-mmp02 

Sun Fire V240 Server 

2 

4 

2 

Solaris 10 

ms-mtai01 

ms-mtai02 

Sun Fire V240 Server 

2 

4 

2 

Solaris 10 

ms-mtao01 

ms-mtao02 

Sun Fire V240 Server 

2 

4 

2 

Solaris 10 

ps01 

ps02 

Sun Fire V440 Server 

4 

16 

4 

Solaris 10 

protect 

Sun Fire V240 

2 

4 

2 

Solaris 10 

ソリューションで使用するコンピュータシステムについても、同様の情報を作成する必要があります。

ヒント –

コンピュータハードウェア/OS 仕様が完成すれば、コンピュータシステムを設定できるようになります。メモリーやディスクドライブをインストールし、オペレーティングシステムをインストールすることで、Java ES コンポーネントをシステムにインストールできるようになります。

ネットワーク接続仕様の作成

配備アーキテクチャーには、ソリューションで使用するすべてのハードウェアを相互接続するために必要な情報の多くが含まれます。ネットワークを接続するために必要な追加情報の作成を支援するために、図 2–2 の例のようなネットワーク接続仕様を準備する必要があります。

図 2–2 ネットワーク接続仕様の例

表 2–1 にテキスト形式でリストされたコンピュータの詳細な接続図。

配備アーキテクチャー例のネットワーク接続仕様では、配備アーキテクチャー図にはない次の情報を追加しています。

ソリューションに必要な接続についても、同様の情報を作成する必要があります。

ヒント –

ネットワーク接続仕様が完成したら、ネットワークが接続可能になり、Java ES コンポーネントのインストールと設定の準備ができたことになります。

ユーザー管理仕様の作成

Java ES ソリューションのインストールおよび設定のプロセスによって、LDAP ディレクトリが設定されます。Java ES をインストールおよび設定すると LDAP スキーマと LDAP ディレクトリツリーの両方が作成されます。スキーマとディレクトリツリーの詳細は、インストールと設定のプロセスで入力する値によって決定されます。このため、インストール計画には、Java ES ソリューションをサポートするスキーマおよびディレクトリ構造の仕様を作成することが含まれます。

ディレクトリツリー構造とスキーマは、ソリューションが提供するサービスに対応している必要があります。ここでは、利用可能なオプションの基本的な説明と、各オプションがサポートするサービスを示します。ただし、この節の主な目的は、Java ES ソリューションをサポートするスキーマおよびディレクトリツリー構造を作成するために、Java ES インストーラおよび Java ES 設定ツールのための入力値を選択する方法について説明することです。

スキーマの選択およびディレクトリツリーの設計については、『Sun Java System Directory Server Enterprise Edition 6.0 Deployment Planning Guide 』などの追加資料を参照してください。

ソリューションの LDAP スキーマの指定

Directory Server を使用する Java ES ソリューションは、スキーマ 1 およびスキーマ 2 として知られる、標準 LDAP スキーマの 2 つのバージョンのいずれかを使用できます。ユーザー管理仕様では、ソリューションでスキーマ 1 とスキーマ 2 のどちらを使用するかを指定します。

スキーマ 2 は、Access Manager の使用と、Access Manager のシングルサインオン機能をサポートします。Access Manager を使用するソリューションでは、スキーマ 2 を使用する必要があります。

インストールプロセスでは、指定されたスキーマのディレクトリを次のように設定します。

ソリューションによっては、スキーマを拡張するための次の手順が必要な場合があります。

LDAP スキーマ仕様は、ソリューションで使用されるスキーマと、ソリューションによって必要とされるすべてのスキーマ拡張を識別します。

ソリューションのディレクトリツリー構造の指定

Java ES ソリューションの LDAP ディレクトリは、ソリューションでユーザーデータを組織化する必要性に応じて、簡単な場合もあれば複雑な場合もあります。LDAP ディレクトリはその性質上、構造的には柔軟です。Java ES ではディレクトリの構造は特に定められていませんが、ディレクトリツリー構造がインストールと設定のプロセスを通じて実装されます。ディレクトリツリーは、インストールと設定のプロセスの開始前に設計する必要があります。

インストールと設定のプロセスでは、次のようにしてディレクトリツリー構造が確立されます。

  1. インストーラを実行して Directory Server をインストールするためには、ディレクトリのベースサフィックス (ルートサフィックスまたはルート DN とも呼ばれる) の入力値が必要です。Java ES インストーラは、入力値を使用してディレクトリのベースサフィックスを確立します。ディレクトリツリーにベースサフィックス名を指定する必要があります。

    ヒント –

    Messaging Server または Calendar Server を使用しない、ディレクトリツリーが単純なソリューションでは、ユーザーおよびグループのデータをベースサフィックスの直下に保存できます。

  2. Messaging Server (Communications Suite コンポーネント) の設定ウィザードを実行して Messaging Server インスタンスを作成するためには、LDAP 組織 DN の入力値が必要です。設定ウィザードによってディレクトリツリーが分岐され、ウィザードでの DN 入力を使用して LDAP 組織が作成されます。この組織は、Messaging Server インスタンスによって管理される電子メールドメインを表します。ウィザードでは、ユーザーおよびグループデータ用に Messaging Server インスタンスが使用する電子メールドメイン組織も設定します。インストール計画には、電子メールドメイン組織の DN も含まれます。このプロセスによって作成されるディレクトリツリー構造の例については、図 2–3 を参照してください。この例では、インストーラによって作成されるベースサフィックスは o=examplecorp です。Messaging Server の設定ウィザードによって作成される電子メールドメイン組織は、o=examplecorp.com,o=examplecorp です。

  3. Calendar Server、Communications Express、Instant Messaging、および Delegated Administrator (Communicaitons Suite コンポーネント) の設定ウィザードでは、LDAP DN の入力値が必要となります (ウィザードでの表示名は異なる場合がある)。ソリューションでシングルサインオンを使用する場合、すべての設定ウィザードで同じ値が入力されます。入力値は、Messaging Server のウィザードによって作成される電子メールドメイン組織です。この設定では、すべてのコンポーネントがユーザーデータの保存および検索場所として同じ LDAP 組織を使用する、という結果になります。ユーザーに関するすべての情報を単一のディレクトリエントリに保存でき、Access Manager のシングルサインオン機能を使用できます。

図 2–3 は、このプロセスによって作成されるディレクトリツリー構造の例を示したものです。この例では、Java ES インストーラによってベースサフィックス o=examplecorp が確立され、Messaging Server の設定ウィザードによって組織 o=examplecorp.com,o=examplecorp が追加されました。この組織は、examplecorp.com という名前の電子メールドメインを表します。電子メールドメインのユーザーデータは ou=people,o=examplecorp.com,o=examplecorp に保存されます。ソリューション内のほかの Java ES コンポーネントも、ユーザーデータを ou=people,o=examplecorp.com,o=examplecorp から検索するように設定されます。

図 2–3 LDAP ディレクトリツリーの例

本文で説明された LDAP ツリーを図示します。

ソリューションで図 2–3 に示したディレクトリツリーが必要な場合は、ベースサフィックスの名前と、電子メールドメインを表す組織がユーザー管理仕様に追加されます。

ディレクトリツリーの例には 1 つのメールドメインのみが含まれます。多くのソリューションでは、ユーザーデータを組織化するために、これよりも複雑なツリーが必要です。同じインストールと設定のための基本手順で、より複雑なディレクトリ構造を確立できます。たとえば、ソリューションで必要な場合には、複数の電子メールドメインをサポートするようにディレクトリを設定できます。

複数の電子メールドメインを確立するには、Messaging Server の複数のインスタンスを設定します。各インスタンスは 1 つの電子メールドメインを管理します。例については、『Sun Java Enterprise System 2005Q4 Deployment Example: Telecommunications Provider Scenario 』を参照してください。

ソリューションがディレクトリとの対話に Access Manager を使用する場合、Java ES ソリューションでほかの LDAP ディレクトリを使用することが可能です。使用するディレクトリサーバーは、LDAP バージョン 3 (LDAP v3) 準拠のディレクトリサーバーである必要があります。