インストールと設定のプロセスの目標は、配備アーキテクチャーに記述された分散システムを実現することです。分散システムは、複数のコンピュータ上で実行され、互いに連携して動作するコンポーネントインスタンスで構成されます。正しく機能する分散システムを構築するには、複数のコンピュータにコンポーネントインスタンスをインストールし、コンポーネントインスタンス間の相互動作を確立する基本設定を実行する必要があります。
インストールと設定の手順は、Java ES インストーラの動作と、個別のコンポーネントの要件によって決定されます。正しく機能する分散システムを確実に実現するためには、インストーラを適切に使用する、また、ソリューションで使用されるコンポーネントの要件を考慮したインストール計画を作成する必要があります。計画では、コンポーネントインスタンスのインストールと基本設定の実行の正しい順序を記述する必要があります。計画ではさらに、コンポーネントインスタンスを相互動作させるための設定値を指定する必要もあります。
この節では、インストール計画の作成時に考慮する必要のある主な問題について説明します。
本稼働 Java ES ソリューションに求められるサービス品質要件は、結果として複数のコンピュータにコンポーネントインスタンスを配置するアーキテクチャーになります。たとえば、信頼性のあるメッセージングサービスを実現するために、2 台の異なるコンピュータに Messaging Server の 2 つのインスタンスを配置し、負荷分散を使用して 2 つのインスタンス間にフェイルオーバー関係を確立するアーキテクチャーが必要になる場合があります。
ただし、Java ES インストーラは一度に 1 台のコンピュータ上でしか動作しません。したがって、分散ソリューションをインストールするときは、ソリューションで使用されるすべてのコンピュータ上で個別にインストーラを実行する必要があります。
多くの場合、1 台のコンピュータに 1 つまたは複数のコンポーネントをインストールしたあと、設定ウィザードを実行して基本設定を実行します。通常は、1 台のコンピュータ上でインストールと設定を完了してから、別のコンピュータにコンポーネントの別のセットをインストールして設定する作業に進みます。分散コンポーネントインスタンスをインストールして設定するために、図 3–1 に示すような一連のタスクを実行する場合があります。
インストールプロセスの目標は、複数のコンポーネントインスタンスが相互に連携して動作するシステムを実現することです。コンポーネントをインストールして基本設定を実行するとき、コンポーネントインスタンスを相互動作させるための設定値を指定します。
相互動作のための設定値には、あるコンポーネントインスタンスが別のコンポーネントインスタンスと通信するために使用する URL やポート番号などの値や、あるコンポーネントインスタンスが別のコンポーネントインスタンスへのアクセスを承認するために使用する管理者アカウント ID やパスワードなどが含まれます。たとえば、ソリューションで Access Manager を使用する場合、まず Directory Server インスタンスなどの LDAP リポジトリをインストールして設定する必要があります。次に、Access Manager インスタンスをインストールして設定するとき、準備した LDAP ディレクトリを検索する場所をインスタンスに知らせる設定値を指定する必要があります。
Java ES インストーラは、ソリューションで使用されているほかのコンピュータにどのようなコンポーネントがインストールされているかについては認識しません。たとえば、Access Manager をインストールするとき、適切な LDAP ディレクトリが位置している場所をインストーラは認識していません。インストールと設定のプロセスを確実に成功させるためには、それぞれのコンピュータにどのコンポーネントをインストールするかを事前に計画する必要があります。ソリューションにコンポーネントを追加するたびに、ほかのコンピュータにすでにインストールされているコンポーネントと相互動作させるための設定を行います。
図 3–2 に示すような、一連のインストールおよび設定タスクを実行する場合があります。
ソリューションのアーキテクチャーがどのようなものであれ、コンポーネントの設定と、正しく相互動作する分散ソリューションの実現のために必要なすべての設定値を含むインストール計画を作成する必要があります。
Java ES コンポーネントの中には、ほかのコンポーネントをまずインストールして設定してからでないと、インストールと設定ができないものがあります。依存性が発生する理由はいくつかあります。
一部のコンポーネントは、ほかの特定のコンポーネントがインストールおよび設定されていないと正しく機能しません。たとえば、Communications Express インタフェースには、メッセージングサービスまたはカレンダサービス、あるいはその両方によって提供されるデータが必要です。Communications Express の設定手順では、すでに動作しているメッセージングサービスやカレンダサービスと Communications Express が相互動作できるようにするために、URL の入力を要求されます。この依存性のため、Communications Express をインストールして設定する前に、Messaging Server または Calendar Server、あるいはその両方をインストールして設定する必要があります。
多くのコンポーネントでは、認証と承認のために LDAP ディレクトリが必要です。これらのコンポーネントのインスタンスをインストールして設定する手順では、LDAP ディレクトリサービスの URL の入力を要求されます。この依存性のため、LDAP ディレクトリサービスを使用するコンポーネントよりも先に、Directory Server (またはそれ以外のアイデンティティーリポジトリ) をインストールする必要があります。
一部のコンポーネントは、既存のコンポーネントの設定を変更します。たとえば、Access Manager をインストールして設定すると、LDAP ディレクトリスキーマが変更されます。ソリューションで Access Manager を使用する場合、Access Manager のインストールよりも先に LDAP ディレクトリをインストールして設定することを指定する必要があります。
多くの Java ES コンポーネントは Web アプリケーションです。これらのコンポーネントは、正しく機能させるためには Web コンテナに配備する必要があります。そのようなコンポーネントをインストールして設定する前に、Web コンテナをインストールして実行しておく必要があります。Web Server、Application Server、または一部のサードパーティー製 Web コンテナを使用できますが、Web アプリケーションコンポーネントをインストールする時点で Web コンテナがそのコンピュータ上に存在している必要があります。
ソリューションで Web Server または Application Server を使用する場合、Java ES インストーラは Web コンテナと Web アプリケーションコンポーネントを同時にインストールでき、Web アプリケーションコンポーネントを Web コンテナに自動的に配備できます。
コンポーネントの中には、Sun Cluster ソフトウェアによって提供される高可用性クラスタにインストールされるものがあります。そのようなコンポーネントをインストールして設定する前に、Sun Cluster ソフトウェアをインストールして実行させておく必要があります。また、該当するコンポーネント用の Sun Cluster エージェントをインストールして設定しておく必要もあります。
これらの依存性には、ソリューションレベルのものとローカルのものがあることに注意してください。インストール計画を作成するときは、システムレベルの依存性とローカルの依存性を分けて考えます。次の例で違いを説明します。
Directory Server に対する Access Manager の依存性はシステムレベルの依存性です。Access Manager をインストールするとき、Directory Server の 1 つまたは複数のインスタンスによって提供されるディレクトリサービスの URL を指定します。Directory Server のインストールと設定が完了すると、ソリューション内のすべてのコンポーネントでディレクトリサービスを利用できるようになります。このタイプの依存性は、コンポーネントインスタンスのインストールと設定に関するソリューションレベルのシーケンスを決定します。Directory Server は Access Manager よりも先にインストールおよび設定されます。インストール計画において、ソリューションレベルの依存性は、インストールと設定のステップの全体的なシーケンスを決定します。
Web コンテナに対する Access Manager の依存性はローカル依存性です。この依存性を満たすには、Access Manager を実行するコンピュータに Web コンテナをインストールする必要があります。ただしこの Web コンテナは、ソリューション全体に対してサービスを提供するものではありません。分散ソリューションでは、Web コンテナは複数のコンピュータにインストールされるのが一般的です。各 Web コンテナは、それぞれ異なるコンポーネントをローカルでサポートします。したがって分散ソリューションでは、Web コンテナをインストールする 1 つの決まった場所は存在せず、インストールシーケンスの中で Web コンテナをインストールするポイントも特に決まっていません。
ソリューションのインストール計画を作成するために、ソリューションを記述してコンポーネント間の依存性を識別する配備アーキテクチャーを分析します。計画では、すべての依存性を満たすシーケンスでコンポーネントをインストールおよび設定する必要があります。一般に、全体的なインストールシーケンスはソリューションレベルの依存性を基にして作成します。その後、それぞれのコンピュータ上に存在する可能性があるローカルの依存性を考慮します。
コンポーネントの依存性のリストを表 3–1 に示します。これらの依存性への対処方法については、「インストール計画の作成」の個別コンポーネントの説明を参照してください。
表 3–1 Java ES コンポーネントの依存性
依存性 |
依存性の性質 |
ローカルである必要性 |
|
---|---|---|---|
Directory Server |
設定データを格納するため。ユーザーデータを格納し、検索を可能にするため |
なし |
|
J2EE Web コンテナ (次のいずれか): -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server |
Access Manager はこれらの Web コンテナのいずれかに配備される必要がある |
あり |
|
Access Manager |
Access Manager サービスを提供するため |
なし |
|
J2EE Web コンテナ (次のいずれか): -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server |
Access Manager SDK はこれらの Web コンテナのいずれかに配備される必要がある |
あり |
|
Directory Server |
設定ディレクトリを提供するため |
なし |
|
信頼性のある非同期メッセージングを提供するため |
あり |
||
Application Server インスタンス間の負荷分散を提供するため |
あり |
||
Application Server 間のフェイルオーバーをサポートするセッション状態を格納するため |
あり |
||
認証と承認に使われるユーザーデータを格納するため |
なし |
||
Calendar Server で使用するための LDAP ディレクトリを準備する |
なし |
||
ソリューションでシングルサインオンを使用する場合に必要 |
なし |
||
電子メール通知を提供するため |
なし |
||
LDAP スキーマを管理するため。カレンダサービスのユーザーをプロビジョニングするため |
なし |
||
-Application Server -Web Server |
Communications Express は Web コンテナに配備される必要がある |
あり |
|
アドレス帳などのユーザーデータを格納するため |
なし |
||
Communications Express 用の LDAP ディレクトリを準備するため |
なし |
||
認証および承認サービスとシングルサインオンを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する |
あり |
||
基盤のメッセージングサービスを提供するため |
なし |
||
基盤のカレンダサービスを提供するため |
なし |
||
J2EE Web コンテナ (次のいずれか): -Application Server -Web Server |
Delegated Administrator はこれらの Web コンテナのいずれかに配備される必要がある |
あり |
|
Directory Server |
Delegated Administrator で扱う LDAP データを格納するため |
なし |
|
Directory Preparation Tool |
Delegated Administrator 用の LDAP ディレクトリを準備するため |
なし |
|
Access Manager または Access Manager SDK のどちらか |
Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する |
あり |
|
Directory Server |
Directory Preparation Tool は、Java ES の通信コンポーネントで使用するディレクトリを準備する |
あり |
|
Administration Server |
Directory Proxy Server を設定するため |
なし |
|
Directory Server |
基盤の LDAP ディレクトリサービスを提供するため |
なし |
|
Administration Server |
Directory Server を設定するため |
なし |
|
High Availability Session Store |
なし | ||
Directory Server |
ユーザー、会議室、およびニュースチャネルのデータを格納するため |
なし |
|
Access Manager または Access Manager SDK (オプション) |
Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する |
あり |
|
J2EE Web コンテナ (次のいずれか): -Application Server -Web Server (Instant Messenger クライアントリソースの配信に必要) |
Instant Messenger クライアントリソースの配布とダウンロードをサポートするため |
あり |
|
Calendar Server (オプション、カレンダポップアップ機能を使用する場合) |
Calendar Server ポップアップをサポートするため |
なし |
|
Messaging Server (オプション、インスタントメッセージのオフライン配信を使用する場合) |
電子メールメッセージとしてのインスタントメッセージのオフライン配信をサポートするため |
なし |
|
Message Queue |
なし | ||
Directory Server |
設定データを格納するため。認証および承認のためのユーザーデータを格納および検索するため |
なし |
|
Administration Server |
Directory Server 設定ディレクトリに設定データを格納するため |
あり |
|
Directory Preparation Tool |
Messaging Server 用の LDAP ディレクトリを準備するため |
なし |
|
Access Manager (ソリューションでシングルサインオンを使用する場合) |
シングルサインオンの認証および承認サービスを提供するため |
なし |
|
Delegated Administrator (オプション) |
ユーザーおよびグループのデータを管理するため。ディレクトリスキーマを管理するため |
なし |
|
-Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server |
Portal Server はこれらの Web コンテナのいずれかに配備される必要がある |
あり |
|
Directory Server |
認証と承認に使われるユーザーデータを格納するため |
なし |
|
Access Manager または Access Manager SDK |
Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する |
あり |
|
Communications Express |
ポータルデスクトップ用のメッセージングおよびカレンダチャネルを提供するため |
なし |
|
Portal Server |
基盤のポータルサービスを提供するため |
あり |
|
Access Manager または Access Manager SDK のどちらか |
Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する |
あり |
|
Service Registry |
Application Server |
あり |
|
Sun Cluster ソフトウェア |
なし | ||
Sun Cluster |
Sun Cluster ノードにインストールされているコンポーネントを認識するため |
あり |
|
Web Server |
Web アプリケーションへのリモートアクセスを提供するため |
あり |
|
Web Server |
なし |
本稼働環境での使用を想定したほとんどのソリューションでは、何らかの種類の冗長化を利用します。冗長性戦略では、コンポーネントの複数のインスタンスを使って 1 つのサービスを提供します。冗長化はサービス品質要件を満たすために利用されます。たとえば、スループットを増強してパフォーマンス要件を満たす目的や、シングルポイント障害を回避して信頼性要件を満たす目的で冗長化を使用します。
Java ES コンポーネントのインスタンス冗長化のために利用できる戦略は 3 つあります。負荷分散、Sun Cluster ソフトウェアによるクラスタリング、および、Directory Server マルチマスターレプリケーションです。ここでは、これらの戦略のそれぞれに対して推奨されるインストールおよび設定手順の概略を示します。
負荷分散は、ハードウェアまたはソフトウェアのどちらかで実装できます。負荷分散をもっとも効果的にセットアップするには、負荷分散されるコンポーネントの 1 つのインスタンスをインストールおよび設定したあと、最初のインスタンスによって提供されるサービスがロードバランサを通じて利用可能なことをテストします。サービスが利用可能なことを検証したあと、配備アーキテクチャーで必要されているコンポーネントの追加インスタンスをインストールし、設定します。このように段階化されたインストールと設定のアプローチにより、設定に伴う問題の診断と解決が容易になります。
クラスタリングは複数の手順で実装されます。最初のステップでは、Sun Cluster ソフトウェアをインストールし、クラスタを確立および設定します。次のステップでは、クラスタ内で実行するコンポーネントをインストールします。たとえば、図 2–1 に示されたクラスタを実装するための最初のステップでは、コンピュータ mscs01 および mscs02 上に Sun Cluster ソフトウェアをインストールし、クラスタを確立および設定します。2 番目のステップでは、Messaging Server と Calendar Server をインストールし、設定します。最後の 3 番目のステップでは、Sun Cluster Agents for Messaging Server および Sun Cluster Agents for Calendar Server をインストールし、設定します。それぞれの Sun Cluster Agents が設定されると、クラスタノードは Messaging Server と Calendar Server のインスタンスを認識します。
Directory Server マルチマスターレプリケーションも、複数のステップで実装されます。最初のステップでは、すべての Directory Server インスタンスをインストール、設定、および検証します。2 番目のステップでは、1 つを除いたすべての Directory Server インスタンスをシャットダウンします。3 番目のステップでは、ソリューション内のほかのコンポーネントをインストールおよび設定します。スキーマまたはディレクトリ構造への変更は、実行中の 1 つの Directory Server インスタンスに対して行われます。最終ステップでは、ソリューション内のすべてのコンポーネントインスタンスがインストール、設定、および検証されたあと、Directory Server のほかのインスタンスを再起動し、レプリケーション機能を使って同期とフェイルオーバーを設定します。これにより、変更および更新されたディレクトリデータがすべての Directory Server インスタンスにコピーされます。
配備アーキテクチャーでこれらの冗長性戦略のいずれかを使用するとき、コンポーネントの複数のインスタンスをインストールし、単独のサービスとして動作するようそれらのインスタンスを設定するための計画を作成する必要があります。
Instant Messaging コンポーネントには、独立したインストールと設定が可能なサブコンポーネントを持つものもあります。たとえば Messaging Server には、Message Transfer Agent、Message Multiplexor (MMP)、Messenger Express Multiplexor (MEM)、および Message Store の 4 つのサブコンポーネントがあります。サービス品質要件を満たすために、配備アーキテクチャーでこれらのサブコンポーネントを別々のコンピュータシステムに配置する場合があります。たとえば、図 2–1 のサンプルアーキテクチャーでは、MEM のインスタンスをコンピュータシステム CX1 および CX2 上に、発信側 Message Transfer Agent をコンピュータシステム MTA1 および MTA2 上に、着信側 Message Transfer Agent をコンピュータシステム MTA3 および MTA4 上に、MMP をコンピュータシステム MMP1 および MMP2 上に、メッセージストアをコンピュータシステム STR1 および STR2 上にそれぞれ配置します。
表 3–2 は、独立でのインストールが可能なサブコンポーネントを持つ Java ES コンポーネントのリストです。ソリューションの配備アーキテクチャーを分析し、ソリューションで分散サブコンポーネントを使用するかどうかを決定します。ソリューションで分散サブコンポーネントを使用する場合、適切なコンピュータシステム上に正しい順序でサブコンポーネントをインストールし、サブコンポーネントが相互動作するように設定する計画を作成する必要があります。分散サブコンポーネントの設定の詳細については、「インストール計画の作成」の個別コンポーネントの説明を参照してください。
表 3–2 サブコンポーネントを持つコンポーネント
コンポーネント |
サブコンポーネント |
---|---|
Instant Messaging Multiplexor Instant Messaging リソース Instant Messaging Server |
|
Message Transfer Agent (MTA) Message Store Messaging Multiplexor (MMP) Messenger Express Multiplexor (MEM) |
サブコンポーネントは個別にインストール可能です。配備アーキテクチャーで分散サブコンポーネントが必要な場合、各コンピュータ上でインストーラを実行し、アーキテクチャーで指定されたサブコンポーネントを選択します。インストーラまたは設定ウィザードで要求される入力値は、完全なコンポーネントに対して指定する値の一部です。インストーラによって設定されないコンポーネントについては、設定ウィザードを起動し、コンピュータ上で設定するサブコンポーネントを選択し、設定ウィザードが要求する入力値を指定します。
ほとんどの Java ES ソリューションには Directory Server が含まれます。ソリューションのインストールと設定には、ディレクトリスキーマとディレクトリツリー構造の両方を確立する入力値が必要です。インストール計画では、正しい LDAP スキーマとディレクトリツリー構造を作成する入力値をリストする必要があります。
LDAP スキーマとディレクトリツリー構造は、インストール計画を開始する前に指定します。仕様の例については、「ユーザー管理仕様の作成」を参照してください。
LDAP スキーマは、次のインストールおよび設定プロセスによって確立されます。
Directory Server をインストールすると、スキーマ 1 のディレクトリが自動的に確立されます。スキーマを選択するための入力は不要です。
Access Manager をインストールすると、ディレクトリが自動的に変更され、そのディレクトリがスキーマ 2 に変換されます。スキーマを選択するための入力は不要です。
Directory Preparation Tool を実行すると、Messaging Server、Calendar Server、および Communications Express で使用するためのスキーマが拡張されます。Directory Preparation Tool は、スキーマ 1 ディレクトリとスキーマ 2 ディレクトリの両方を拡張します。Directory Preparation Tool に対する入力値はインストール計画にリストされます。
Delegated Administrator を実行すると、スキーマが拡張され、特定のサービスに対してユーザーを承認および認証するために使われるオブジェクトクラスと属性が追加されます。入力値は、ソリューションが提供するサービスの内容によって異なります。入力値はインストール計画にリストされます。入力値の詳細については、「Delegated Administrator 用の手順をインストール計画に追加する」を参照してください。
インストールと設定のプロセスでは、基本ディレクトリツリー構造も確立されます。
Directory Server をインストールすると、ベースサフィックス (ディレクトリツリーのルート) が作成されます。ベースサフィックスは、Java ES インストーラが Directory Server をインストールするときに必要な入力値です。インストール計画では、インストールプロセスのための入力値の 1 つとしてベースサフィックスを指定します。
Messaging Server をインストールして設定すると、ディレクトリツリーが分岐して LDAP 組織が作成されます。この組織は、Messaging Server インスタンスによって管理される電子メールドメインを表します。組織の名前は、Messaging Server の設定ウィザードで必須の入力です。インストール計画では、Messaging Server の設定プロセス用の入力値の 1 つとして組織 DN を指定します。
Calendar Server、Communications Express、Delegated Administrator、および Instant Messaging のインストールと設定では、これらのコンポーネントがユーザーデータを検索するディレクトリ構造内の場所を指定します。LDAP DN は各コンポーネントの設定ウィザードの必須入力であり、インストール計画では各設定ウィザード用の入力値として DN を指定します。ソリューションで Access Manager シングルサインオンを使用する場合、これらのコンポーネントがすべて同じ場所 (Messaging Server の設定ウィザードで作成された組織) にユーザーデータを保存するように設定する必要があります。これら全コンポーネントの設定ウィザードで、同じ LDAP DN が入力されます。インストール計画では、すべての設定ウィザードに対する入力値の 1 つとして組織 DN を指定します。
LDAP ベースサフィックスおよび電子メール組織の名前は、ユーザー管理仕様をもとに決定され、インストール計画に追加されます。ユーザー管理仕様の詳細については、「ユーザー管理仕様の作成」を参照してください。インストール計画への LDAP ベースサフィックスの追加については、表 3–5を参照してください。インストール計画への電子メールドメインの追加については、表 3–9、表 3–10、表 3–11、表 3–13、および表 3–14 を参照してください。
ここでは、インストール計画に影響する Java ES インストーラの一部の動作について説明します。
Java ES インストーラは、コンポーネントソフトウェアを一度に 1 台のコンピュータにインストールします。つまり、ほとんどのソリューションにおいて、インストーラが複数回実行されることになります。インストール計画では、インストーラを実行する回数を指示する必要があります。ここでは、ソリューションをインストールおよび設定するためにインストーラを実行する回数を、配備アーキテクチャーの分析に基づいて決定する方法について説明します。
ソリューションの中には 1 台のコンピュータにのみインストールされるものがあり、そのようなソリューションのインストール計画は、インストーラを 1 回だけ実行するための手順を定義します。インストーラの実行が 1 回で済むのは次のようなソリューションです。
Java ES の機能を評価する目的で、多数のコンポーネントを 1 台のコンピュータにインストールする。
確立済みのソリューションに 1 つのコンポーネントインスタンスを追加する。これには、既存のコンポーネントに対する依存性を持つコンポーネントインスタンスの追加が含まれます。
ほとんどのソリューションは、複数のコンピュータに分散されます。そのようなソリューションのインストール計画では、ソリューション全体をインストールおよび設定するために、複数回のインストーラ実行を記述する必要があります。そのようなソリューションを分析するには、次のガイドラインを使用します。
1 台のコンピュータ上のコンポーネントの組み合わせの大半は、1 回のインストーラ実行でインストールできます。これは特に、インストーラが「今すぐ設定」モードで動作する場合に当てはまります。「今すぐ設定」モードでは、インストーラは Web コンテナと、そのコンテナ内で実行されるコンポーネントの両方をインストールできるからです。これらの場合、インストール計画では、そのコンピュータ上での 1 回のインストーラ実行と、そのコンピュータに対して指定されたすべてのコンポーネントの選択を記述します。
一部のコンポーネントは、「今すぐ設定」モードでもインストーラによる設定はできません。そのようなコンポーネントをコンピュータにインストールするとき、設定プロセスはそれぞれのコンポーネントに対して設定ウィザードを実行することによって完了します。それらのコンポーネントを、インストーラによって設定されるコンポーネントと組み合わせてインストールする場合には、まずインストーラが実行されます。インストーラの実行後、インストーラによって設定されないコンポーネントに対して設定ウィザードを実行することによってプロセスを完了します。これらの場合、インストール計画では、インストーラの実行と、複数の設定ウィザード実行の正しいシーケンスを記述する必要があります。
コンポーネントの組み合わせによっては、1 台のコンピュータ上でインストーラを複数回実行しないとインストールできない場合があります。そのような組み合わせには、次のものがあります。
Web コンテナを含む一部のコンポーネントの組み合わせ。Web Server または Application Server を「あとで設定」モードでインストールする場合、Web サーバー内で実行されるコンポーネントは、先に Web Server または Application Server のインスタンスを設定および検証してからでないとインストールできません。ソリューションでサードパーティー製の Web コンテナを使用する場合、Java ES コンポーネントをインストールする前に、当該製品のインストーラを使用して Web コンテナをインストールし、起動し、検証する必要があります。インストール計画では、各コンピュータ上での複数回のインストーラ実行を記述する必要があります。
Sun Cluster ソフトウェアを使用するコンポーネントの組み合わせ。クラスタにインストールされるコンポーネントがクラスタファイルシステム上にインストールされる場合、先に Sun Cluster ソフトウェアをインストールし、クラスタファイルシステムを作成してからでないと、クラスタノードにほかのコンポーネントをインストールできません。インストール計画では、各コンピュータ上での複数回のインストーラ実行を記述する必要があります。
この節の目的は、インストール計画では時として、1 台のコンピュータ上でのインストーラと設定ウィザードの実行、または、1 台のコンピュータ上での複数回のインストーラ実行を記述しなければならないという概念を紹介することです。さまざまなコンポーネントの組み合わせに対する実際のインストール手順の詳細については、「インストール計画の作成」を参照してください。
インストーラは、「今すぐ設定」と「あとで設定」の 2 つの異なるモードで動作します。2 つのモードの違いは次の点です。
「今すぐ設定」モードでは、インストーラは全部ではなく一部のコンポーネントの実行可能インスタンスを設定します。「今すぐ設定」モードで設定されるコンポーネントは、インストーラが完了した時点で起動と検証が可能になります。インストーラの実行後、残りのコンポーネントの実行可能インスタンスが、コンポーネント製品の設定ウィザードを実行することによって作成されます。インストーラによって設定されるコンポーネントについては、インストーラで設定値を入力する必要があります。必要な設定値は、インストーラを実行するための指示の一部としてインストール計画にリストします。インストーラの実行後に設定されるコンポーネントについては、設定値は設定ウィザードの必須入力です。必要な設定値は、設定ウィザードを実行するための指示の一部としてリストされます。
「今すぐ設定」モードの重要な特長の 1 つは、Web コンテナと、その Web コンテナ内で動作するコンポーネントを同時にインストールできることです。コンポーネントはインストーラによって自動的に Web コンテナに配備されます。
「あとで設定」モードでは、インストーラはコンポーネントソフトウェアのファイルをコンピュータにコピーしますが、実行可能なインスタンスは作成しません。インスタンスはインストーラの実行後に、コンポーネント製品の設定ウィザードを実行することによって作成されます。設定値は設定ウィザードの必須入力であり、設定ウィザードを実行するための指示の一部としてリストされます。
選択した設定オプションは、インストールセッション全体に適用されます。一部のコンポーネントに対して別の設定オプションを選択する必要がある場合、追加のインストールセッションを実行しなければならない場合があります。
インストーラでは、依存性と互換性に関するいくつかのチェックが実行されます。ローカルにインストールされる項目のチェックだけが可能です。たとえば、ソリューションでリモートの Directory Server インスタンスを使用している場合、インストーラでは、リモートの Directory Server がインストール中の Access Manager と互換性があるかどうかのチェックを行うことはできません。完全に新規のソリューションをインストールおよび設定している場合。確立済みのソリューションに新しいコンポーネントを追加している場合や、既存のコンポーネントの周囲に Sun Java System を構築している場合、そのことが問題となる可能性があります。たとえば、すでに Directory Server を使用しており、Access Manager、Messaging Server、Calendar Server、および Communications Express を使用するソリューションを既存の Directory Server の周囲に構築している場合、コンポーネント間の互換性が問題となります。
コンポーネントの依存性チェック。Java ES インストーラは、ローカルホスト上でのみ、インストールするように選択したほかのコンポーネントに必要なコンポーネントを除外しないようにします。分散ソリューションでは、インストーラは、リモートコンポーネントの存在を検証するためのリモートホストのチェックは行いません。リモートコンポーネントに互換性があり、適切な稼働状態にあることを確認する必要があります。
アップグレード。Application Server および Message Queue が Solaris OS とともにすでにインストールされているときを除いて、Java ES インストーラはコンポーネントのアップグレードを行いません。この場合、インストーラは、インストールの間に Application Server および Message Queue をアップグレードするかどうかをユーザーに問い合わせます。
Java ES インストーラは、共有コンポーネントのアップグレードを行います。このトピックの詳細については、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「既存ホストの調査」を参照してください。
この節では、一部のソリューションで発生するいくつかの固有の問題を、詳細な情報の参照先とともに示します。
表 3–3 考慮する必要のあるインストールの問題
ソリューションに必要なもの |
ガイドラインまたは指示 |
---|---|
Solaris 10 ゾーンの使用 |
Solaris 10 ゾーンへのインストールを予定している場合、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Solaris 10 ゾーン」を参照してください。 |
Directory Server 暗号化の使用 |
Directory Server インスタンス上での LDAPS (SSL over LDAP) の設定 注意: Directory Server 暗号化が必要な場合、Directory Server のインストール時に Administration Server をインストールする必要があります。 |
サードパーティー製 Web コンテナ (BEA WebLogic Server または IBM WebSphere Application Server) を Portal Server および Access Manager と組み合わせて使用できます。これらのコンテナは、コンテナに依存する Java ES コンポーネントをインストールする前にインストールして実行する必要があります。 Access Manager SDK に対してサードパーティー製 Web コンテナを使用するには、インストール後に Access Manager SDK を手動で設定する必要があります。『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「コンテナの設定を使用する Access Manager SDK の例」を参照してください。 注意: Portal Server は、Solaris OS 上ではサードパーティー製 Web コンテナのみを使用できます。 注意: Access Manager と Portal Server では同じ種類の Web コンテナを使用することが推奨されます。 |
|
Apache Web Server は、Application Server の負荷分散プラグインで使用することができます。この場合、Apache Web Server は、このサーバーに依存する Java ES コンポーネントをインストールする前にインストールし、実行する必要があります。詳細については、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「インストール前提条件」を参照してください。 |
|
LDAP スキーマ 1 に基づくインストール例については、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Calendar-Messaging Schema 1 の例」で説明しています。スキーマ 1 配備については、Access Manager を使用できません。 |
|
シングルサインオンをセットアップする手順は、『Sun Java Enterprise System 2005Q1 Deployment Example Series: Evaluation Scenario』の第 8 章「Configuring and Using Single Sign-On」に記載されています。シングルサインオンを行うには Access Manager が必要です。 |
|
HADB を使用した高可用性の設定 |
高可用性のための HADB の設定例は、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Web とアプリケーションサービスの例」に記載されています。 |
Application Server 負荷分散 |
Application Server の負荷分散プラグインの使用方法を含む例は、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Web とアプリケーションサービスの例」に掲載されています。 |
非ルート所有権 |
Application Server または Web Server に対して非ルート所有権が必要な場合、次のいずれかの例を参照してください。 『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「非ルートユーザーとして実行するように設定された Access Manager の例」または |