第 2 章「実装の仕様の作成」の説明に従って実装仕様を作成すると、インストール計画を準備するために必要な情報が用意されます。インストール計画では、Java ES ソリューションのインストールと設定に必要なすべての手順を記述します。インストール計画では、特定の Java ES ソリューションの実装に必要なすべての手順を記述します。
この章では、インストール計画を準備する方法について説明します。最初に、配備アーキテクチャーおよび実装仕様内の情報の定義を行います。ここには、Java ES ソリューションの配備状態を記述します。これらのドキュメントに記載されている情報を分析し、Java ES インストーラと設定ウィザードを使用して仕様書に記述したソリューションを実装する方法を決定します。
この章では、インストール計画の作成方法について説明します。この章で扱う内容は次のとおりです。
インストールと設定のプロセスの目標は、配備アーキテクチャーに記述された分散システムを実現することです。分散システムは、複数のコンピュータ上で実行され、互いに連携して動作するコンポーネントインスタンスで構成されます。正しく機能する分散システムを構築するには、複数のコンピュータにコンポーネントインスタンスをインストールし、コンポーネントインスタンス間の相互動作を確立する基本設定を実行する必要があります。
インストールと設定の手順は、Java ES インストーラの動作と、個別のコンポーネントの要件によって決定されます。正しく機能する分散システムを確実に実現するためには、インストーラを適切に使用する、また、ソリューションで使用されるコンポーネントの要件を考慮したインストール計画を作成する必要があります。計画では、それぞれのコンポーネントインスタンスのインストールと基本設定の実行の正しい順序を記述する必要があります。計画ではさらに、コンポーネントインスタンスを相互動作させるための設定値を指定する必要もあります。
この節では、インストール計画の作成時に考慮する必要のある主な問題について説明します。
本稼働 Java ES ソリューションに求められるサービス品質要件は、結果として複数のコンピュータにコンポーネントインスタンスを配置するアーキテクチャーになります。たとえば、信頼性のあるポータルサービスを実現するために、2 台の異なるコンピュータに Portal Server の 2 つのインスタンスを配置し、負荷分散を使用して 2 つのインスタンス間にフェイルオーバー関係を確立するアーキテクチャーが必要になる場合があります。
ただし、Java ES インストーラは一度に 1 台のコンピュータ上でしか動作しません。したがって、分散ソリューションをインストールするときは、ソリューションで使用されるすべてのコンピュータ上で個別にインストーラを実行する必要があります。
多くの場合、1 台のコンピュータに 1 つまたは複数のコンポーネントをインストールしたあと、設定ウィザードを実行して基本設定を実行します。通常は、1 台のコンピュータ上でインストールと設定を完了してから、別のコンピュータにコンポーネントの別のセットをインストールして設定する作業に進みます。分散コンポーネントインスタンスをインストールして設定するために、図 3–1 に示すような一連のタスクを実行する場合があります。
Java ES コンポーネントの中には、ほかのコンポーネントをまずインストールして設定してからでないと、インストールと設定ができないものがあります。依存性が発生する理由はいくつかあります。
一部のコンポーネントは、ほかの特定のコンポーネントがインストールおよび設定されていないと正しく機能しません。たとえば、Access Manager を適切に動作させるためには、LDAP ディレクトリによって提供される、ユーザーとサービスについての情報にアクセス可能である必要があります。Access Manager のインストールと設定の手順では、Access Manager が、すでに動作しているディレクトリサービスと相互動作するために URL の入力が必要です。この依存性のため、Directory Server をインストールおよび設定してから、Access Manager をインストールおよび設定する必要があります。
一部のコンポーネントは、既存のコンポーネントの設定を変更します。たとえば、Access Manager をインストールして設定すると、LDAP ディレクトリスキーマが変更されます。ソリューションで Access Manager を使用する場合、Access Manager のインストールよりも先に LDAP ディレクトリをインストールして設定することを指定する必要があります。
多くの Java ES コンポーネントは Web アプリケーションです。これらのコンポーネントは、正しく機能させるためには 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 よりも先にインストールし設定する必要があります。インストール計画において、ソリューションレベルの依存性は、インストールと設定のステップの全体的なシーケンスを決定します。まず Directory Server をインストールし、そのあと、Access Manager などの、ディレクトリサービスに依存するコンポーネントを追加するよう計画できます。
Web コンテナに対する Access Manager の依存性はローカル依存性です。この依存性を満たすには、Access Manager を実行するコンピュータに Web コンテナをインストールする必要があります。ただしこの Web コンテナは、ソリューション全体に対して Web コンテナを提供するものではありません。分散アーキテクチャーで Access Manager とは異なるコンピュータ上に Portal Server をインストールすると指定されている場合は、両方のコンピュータに 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 コンテナのいずれかに配備される必要がある |
可能 |
|
Access Manager Distributed Authentication |
Access Manager |
基本的な Access Manager サービスを提供するため |
不可 |
J2EE Web コンテナ、次のいずれか -Application Server -Web Server -BEA WebLogic Server -IBM WebSphere Application Server |
Access Manager SDK はこれらの Web コンテナのいずれかに配備される必要がある |
可能 |
|
Access Manager セッションフェイルオーバー |
Access Manager |
基本的な Access Manager サービスを提供するため |
不可 |
Message Queue |
信頼性のある非同期メッセージングを提供するため |
不可 |
|
信頼性のある非同期メッセージングを提供するため |
可能 |
||
Application Server インスタンス間の負荷分散を提供するため |
可能 |
||
Application Server 間のフェイルオーバーをサポートするセッション状態を格納するため |
可能 |
||
Directory Server |
基盤の LDAP ディレクトリサービスを提供するため |
不可 |
|
なし | |||
High Availability Session Store |
なし | ||
Java DB |
なし | ||
Message Queue |
Directory Server (省略可能) |
管理されたオブジェクトと持続メッセージを格納するため |
不可 |
-Application Server -Web Server |
クライアントとメッセージブローカ間の HTTP トランスポートをサポートするため |
不可 |
|
Sun Cluster (省略可能) |
高可用性ソリューションでの Message Queue の使用をサポートするため |
不可 |
|
-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 へのアクセスを提供する |
可能 |
|
Service Registry Client |
コンパイルのために必要なライブラリを提供するため |
不可 |
|
Portal Server |
基盤のポータルサービスを提供するため |
不可 |
|
Access Manager または Access Manager SDK のどちらか |
Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する |
可能 |
|
Rewriter プロキシ |
Portal Server |
基盤のポータルサービスを提供するため |
不可 |
Netlet プロキシ |
Portal Server |
基盤のポータルサービスを提供するため |
不可 |
Service Registry |
Application Server |
必要なコンテナサービスを提供するため |
可能 |
Service Registry クライアント |
必要なクライアントインタフェースを提供するため |
可能 |
|
Service Registry クライアント |
なし | ||
Sun Cluster ソフトウェア |
なし | ||
Sun Cluster |
基本的なクラスタサービスを提供するため |
可能 |
|
Sun Cluster Geographic Edition |
Sun Cluster |
基本的なクラスタサービスを提供するため |
可能 |
Web Server |
Web Server で実行する Web アプリケーションへのリモートアクセスを提供するため |
可能 |
|
Directory Server (省略可能) |
認証と承認に使われるユーザーデータを格納するため |
不可 |
|
Web Server |
Directory Server (省略可能) |
認証と承認に使われるユーザーデータを格納するため |
不可 |
インストールと設定のプロセスの目標は、複数のコンポーネントインスタンスが相互に連携して動作するシステムを実現することです。一度に 1 台のコンピュータにコンポーネントをインストールし、基本設定を行うため、ほかのコンピュータ上のコンポーネントと正常に相互動作するような設定値をあらかじめ決定しておく必要があります。
相互動作のための設定値は、あるコンポーネントインスタンスが別のコンポーネントインスタンスと通信するために使用する URL やポート番号などの値が含まれます。たとえば、ソリューションで Access Manager を使用する場合、まず Directory Server インスタンスなどの LDAP リポジトリをインストールして設定する必要があります。次に、Access Manager インスタンスをインストールし設定するときに、すでにインストールおよび設定済みの LDAP ディレクトリと相互動作するように Access Manager を設定する値を指定する必要があります。
Java ES インストーラは、ソリューションで使用されているほかのコンピュータにどのようなコンポーネントがインストールされているかについては認識しません。たとえば、Access Manager をインストールするとき、適切な LDAP ディレクトリが位置している場所をインストーラは認識していません。インストールと設定のプロセスを確実に成功させるためには、Access Manager インスタンスおよび Directory Server インスタンス間での正常な相互動作につながるインストールと設定の値を、あらかじめ決定しておく必要があります。これらの値をインストール計画に含めます。そのあと、コンポーネントをインストールし設定するときに、計画に入れた値を入力すれば、互いに相互動作するコンポーネントが正常に設定されます。
図 3–2 に示すような、一連のインストールおよび設定タスクを実行する場合があります。
ソリューションのアーキテクチャーがどのようなものであれ、コンポーネントの設定と、正しく相互動作する分散ソリューションの実現のために必要なすべての設定値を含むインストール計画を作成する必要があります。
本稼働環境での使用を想定したほとんどのソリューションでは、何らかの種類の冗長化を利用します。冗長性戦略では、コンポーネントの複数のインスタンスを使って 1 つのサービスを提供します。冗長化はサービス品質要件を満たすために利用されます。たとえば、スループットを増強してパフォーマンス要件を満たす目的や、シングルポイント障害を回避して信頼性要件を満たす目的で冗長化を使用します。
Java ES コンポーネントのインスタンス冗長化のために利用できる戦略は 3 つあります。負荷分散、Sun Cluster ソフトウェアによるクラスタリング、および、Directory Server レプリケーションです。ここでは、これらの戦略のそれぞれに対して推奨されるインストールおよび設定手順の概略を示します。
負荷分散は、ハードウェアまたはソフトウェアのどちらかで実装できます。負荷分散をもっとも効果的にセットアップするには、負荷分散されるコンポーネントの 1 つのインスタンスをインストールおよび設定したあと、最初のインスタンスによって提供されるサービスがロードバランサを通じて利用可能なことをテストします。サービスが利用可能なことを検証したあと、配備アーキテクチャーで必要されているコンポーネントの追加インスタンスをインストールし、設定します。このように段階化されたインストールと設定のアプローチにより、設定に伴う問題の診断と解決が容易になります。
クラスタリングは複数の手順で実装されます。最初のステップでは、Sun Cluster ソフトウェアをインストールし、クラスタを確立および設定します。次のステップでは、クラスタ内で実行するコンポーネントをインストールします。たとえば、図 2–1 に示されたクラスタを実装するための最初のステップでは、コンピュータ STR1 および STR2 上に Sun Cluster ソフトウェアをインストールし、クラスタを確立および設定します。2 番目のステップでは、Messaging Server と Calendar Server をインストールし、設定します。最後の 3 番目のステップでは、Messaging Server および Calendar Server の Sun Cluster データサービスをインストールし、設定します。それぞれの Sun Cluster データサービスが設定されると、クラスタノードは Messaging Server と Calendar Server のインスタンスを認識します。
Directory Server レプリケーションも、複数のステップで実装されます。たとえば、マルチマスターレプリケーションを実装する場合、最初のステップは、すべての Directory Server インスタンスのインストール、設定、および検証です。2 番目のステップでは、1 つを除いたすべての Directory Server インスタンスをシャットダウンします。3 番目のステップでは、ソリューション内のほかのコンポーネントをインストールおよび設定します。スキーマまたはディレクトリ構造への変更は、実行中の 1 つの Directory Server インスタンスに対して行われます。最終ステップでは、ソリューション内のすべてのコンポーネントインスタンスがインストール、設定、および検証されたあと、Directory Server のほかのインスタンスを再起動し、レプリケーション機能を使って同期とフェイルオーバーを設定します。これにより、変更および更新されたディレクトリデータがすべての Directory Server インスタンスにコピーされます。
配備アーキテクチャーでこれらの冗長性戦略のいずれかを使用するときは、コンポーネントの複数のインスタンスをインストールし、単独のサービスとして動作するようそれらのインスタンスを設定する手順を、インストール計画に含める必要があります。
ほとんどの Java ES ソリューションには Directory Server が含まれます。Directory Server でソリューションをインストールし設定する場合は、ディレクトリスキーマとディレクトリツリー構造の両方を設定する値を入力します。インストール計画では、正しい LDAP スキーマとディレクトリツリー構造を作成する入力値をリストする必要があります。
LDAP スキーマとディレクトリツリー構造は、インストール計画を開始する前に指定します。インストール計画には、インストーラを実行して指定したスキーマとディレクトリ構造を作成するときに入力する値を含めます。スキーマとディレクトリツリー仕様の例は、「ユーザー管理仕様の作成」を参照してください。
LDAP スキーマは、次のインストールおよび設定プロセスによって確立されます。
Directory Server をインストールすると、スキーマ 1 のディレクトリが自動的に確立されます。スキーマを選択するための入力は不要です。
Access Manager をインストールすると、ディレクトリが自動的に変更され、そのディレクトリがスキーマ 2 に変換されます。スキーマを選択するための入力は不要です。
Communications Suite コンポーネントが含まれるソリューションでは、Directory Preparation Tool を実行すると、Messaging Server、Calendar Server、および Communications Express で使用するためのスキーマが拡張されます。Directory Preparation Tool は、スキーマ 1 ディレクトリとスキーマ 2 ディレクトリの両方を拡張します。Directory Preparation Tool に対する入力値はインストール計画にリストされます。
Communications Suite コンポーネントが含まれるソリューションでは、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 ベースサフィックスおよび電子メール組織の名前を、ユーザー管理仕様をもとに決定し、インストール計画に追加します。ユーザー管理仕様の詳細については、「ユーザー管理仕様の作成」を参照してください。
ここでは、インストール計画に影響する 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 コンテナを使用する場合、Web ベースの Java ES コンポーネントをインストールする前に、Web コンテナをインストールし、起動し、検証する必要があります。インストール計画には、各コンピュータ上での複数回のインストーラ実行の手順を記述する必要があります。
Sun Cluster ソフトウェアを使用するコンポーネントの組み合わせ。クラスタにインストールされるコンポーネントがクラスタファイルシステム上にインストールされる場合、先に Sun Cluster ソフトウェアをインストールし、クラスタファイルシステムを作成してからでないと、クラスタノードにほかのコンポーネントをインストールできません。インストール計画には、各コンピュータ上での複数回のインストーラ実行の手順を記述する必要があります。
この節の目的は、インストール計画では時として、1 台のコンピュータ上でのインストーラと設定ウィザードの実行、または、1 台のコンピュータ上での複数回のインストーラ実行を記述しなければならないという概念を紹介することです。さまざまなコンポーネントの組み合わせに対する実際のインストール手順の詳細については、「インストール計画の作成」を参照してください。
インストーラは、「今すぐ設定」と「あとで設定」の 2 つの異なるモードで動作します。2 つのモードの違いは次の点です。
「今すぐ設定」モードでは、インストーラは全部ではなく一部のコンポーネントの実行可能インスタンスを設定します。「今すぐ設定」モードで設定されるコンポーネントは、インストーラが完了した時点で起動と検証が可能になります。インストーラの実行後、残りのコンポーネントの実行可能インスタンスが、コンポーネントの設定ウィザードを実行することによって作成されます。インストーラによって設定されるコンポーネントについては、インストール計画にインストーラの実行時に入力する設定値を記述する必要があります。インストーラの実行後に設定されるコンポーネントについては、インストール計画に、設定ウィザードの実行手順と、設定ウィザードの実行時に入力する設定値を記述する必要があります。
「今すぐ設定」モードの重要な特長の 1 つは、Web コンテナと、その Web コンテナ内で動作するコンポーネントを同時にインストールできることです。コンポーネントはインストーラによって自動的に Web コンテナに配備されます。
「あとで設定」モードでは、インストーラはコンポーネントソフトウェアのファイルをコンピュータにコピーしますが、実行可能なインスタンスは作成しません。インスタンスは、インストーラの実行後に、コンポーネント設定ウィザードを実行することによって作成します。インストール計画には、設定ウィザードの実行手順と、設定ウィザードの実行時に入力する設定値を記述する必要があります。
選択した設定オプションは、インストールセッション全体に適用されます。「今すぐ設定」モードと「あとで設定」モードで一部のコンポーネントをコンピュータ上にインストールしたい場合は、インストーラを複数回実行する必要があります。
Java ES インストーラでは、依存性と互換性に関するいくつかのチェックが実行されます。ただし、インストーラでチェックできるのはローカルコンピュータのみです。たとえば、分散ソリューションで Access Manager をインストールする場合、インストーラでは、インストールする Access Manager との互換性がリモート Directory Server にあるかどうかのチェックを行うことはできません。
同じ Java ES リリースのすべてのコンポーネントを含む完全に新規のソリューションをインストールし設定する場合、互換性が問題になることは考えられません。確立済みのソリューションに新しいコンポーネントを追加している場合や、既存のコンポーネントの周囲に Java ES ソリューションを構築している場合、そのことが問題となる可能性があります。たとえば、すでに Directory Server を使用しており、Access Manager と Portal Server を使用するソリューションを既存の Directory Server の周囲に構築している場合、コンポーネント間の互換性が問題となります。新しいコンポーネントのインストールと設定を開始する前に、コンポーネントの互換性を確認する必要があります。
コンポーネントの依存性チェック。Java ES インストーラは、ローカルホスト上でのみ、インストールするように選択したほかのコンポーネントに必要なコンポーネントを除外しないようにします。分散ソリューションでは、インストーラは、リモートコンポーネントの存在を検証するためのリモートホストのチェックは行いません。この場合、リモートコンポーネントに互換性があり、適切な稼働状態にあることを確認する必要があります。
アップグレード。Java ES インストーラは、インストールされている Application Server、Message Queue、HADB、および Java DB と、インストールするコンポーネントとの互換性をチェックし、インストール時にコンポーネントをアップグレードするかどうかをユーザーに問い合わせます。
Java ES インストーラは、共有コンポーネントのアップグレードを行います。このトピックの詳細については、『Sun Java Enterprise System 5 インストールガイド (UNIX 版)』の「既存ホストの調査」を参照してください。
この節では、一部のソリューションで発生するいくつかの固有の問題を、詳細な情報の参照先とともに示します。
表 3–2 考慮する必要のあるインストールの問題
ソリューションに必要なもの |
ガイドラインまたは取扱説明書 |
---|---|
Solaris 10 ゾーンの使用 |
Solaris 10 ゾーンへのインストールを予定している場合、付録 A 「Java ES と Solaris 10 ゾーン」を参照してください。 |
Directory Server 暗号化の使用 |
Directory Server インスタンス上で LDAPS (SSL over LDAP) を設定します。 |
サードパーティー製 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 5 インストールガイド (UNIX 版)』の「コンテナの設定を使用する Access Manager SDK の例」を参照してください。 注意: Portal Server は、Solaris OS 上ではサードパーティー製 Web コンテナのみを使用できます。 注意: Access Manager と Portal Server では同じ種類の Web コンテナを使用することが推奨されます。 |
|
Apache Web Server は、Application Server の負荷分散プラグインで使用することができます。この場合、Apache Web Server は、このサーバーに依存する Java ES コンポーネントをインストールする前にインストールし、実行する必要があります。 |
|
スキーマ 1 配備については、Access Manager を使用できません。 |
|
シングルサインオンを行うには Access Manager が必要です。 |
|
HADB を使用した高可用性の設定 |
高可用性のための HADB の設定手順の概要は、『Sun Java Enterprise System 5 インストールガイド (UNIX 版)』の「Web とアプリケーションサービスの例」に記載されています。 |
Application Server 負荷分散 |
Application Server の負荷分散プラグインの使用手順の概要は、『Sun Java Enterprise System 5 インストールガイド (UNIX 版)』の「Web とアプリケーションサービスの例」に掲載されています。 |
非ルート所有権 |
Application Server または Web Server に対して非ルート所有権が必要な場合は、『Sun Java Enterprise System 5 インストールガイド (UNIX 版)』の「root 以外のユーザーでのインストール例」を参照してください。 |
配備アーキテクチャーと実装仕様では、ソリューションの最終状態を記述します。配備アーキテクチャーでは、何個のコンポーネントインスタンスがインストールされるか、コンポーネントインスタンスがどのコンピュータシステムにインストールされるか、および、コンポーネントインスタンスがどのように相互動作するかを示します。配備アーキテクチャーで記述された状態に到達するために、ソリューション全体のインストールと設定が完了するまで、ソリューション内のコンピュータシステムの 1 台ずつにコンポーネントインスタンスをインストールして設定する必要があります。インストール計画では、ソリューション内のすべてのコンポーネントインスタンスを正しい順序でインストールして設定するための手順を定義する必要があります。
インストールおよび設定計画を作成するには、コンポーネントの依存性やそのほかのインストールの問題に関する知識を、Java ES の配備アーキテクチャーおよび実装仕様に応用する必要があります。ソリューション内のコンポーネントインスタンスをインストールして設定する正しいシーケンスと、コンポーネントインスタンスの相互動作を実現する正しい設定入力値を決定する必要があります。
この節では、配備アーキテクチャーと一連の仕様を分析して、インストール計画を作成する方法について説明します。通常は、次のような手順で作業を開始します。
計画を記録するためのテキストファイル、空白の紙、またはそのほかのメディアを開きます。
配備アーキテクチャーで、各コンピュータシステム上のコンポーネントを検証し、どのようなコンポーネント依存性が存在するかを判断します。
ほかのコンポーネントへの依存性を持たないコンポーネントインスタンスを識別します。そのようなインスタンスは通常、Directory Server のインスタンスです。インストール計画の作成は、指定されたコンピュータシステムにそのようなコンポーネントインスタンスをインストールするための手順の定義から始めます。そのようなコンピュータシステムと、それらのシステムにインストールされるコンポーネントインスタンスを記録して、インストール計画を開始します。
それらのコンピュータシステム上のコンポーネントインスタンスについて、対象のソリューションにおける正しいインストール/設定値を決定します。これらの設定値をインストール計画に追加します。
残りのコンポーネントの中で、Directory Server にのみ依存性を持つコンポーネントを特定します。それらは通常、Access Manager が動作するコンピュータシステムです。次に、それらのコンピュータシステムをインストール計画にリストします。
コンポーネントの依存性の順序で仕様の分析を続けます。必要な設定値を決定し、それらのコンポーネントインスタンスを計画に記録します。
たとえば、このプロセスを使用して、図 2–1 に示した配備アーキテクチャーを分析する場合、表 3–3 のようなインストール計画を作成します。
表 3–3 は、インストール計画の最初の 8 つのステップを示したものです。この計画の構造を明確にするために、個別の設定値についてはリストしていません。この計画では、次のことに注意します。
計画では、ソリューション内のコンピュータを、コンポーネントインスタンスがインストールおよび設定される順序に従ってリストします。
インストールのシーケンスは、ソリューションレベルの依存性とローカル依存性の両方を適用することによって決定されます。ソリューションレベルの依存性の適用により、Directory Server、Access Manager、Messaging Server、そして Calendar Server という基本シーケンスが決定されます。このシーケンスにローカルの Communications Express 依存性を適用することにより、コンピュータ AM1 および AM2 上に Web Server のインスタンスが、コンピュータ mscs01 および mscs02 上に Sun Cluster ソフトウェアおよび Sun Cluster エージェントが追加されます。
計画には、Java ES ソリューションで採用されるすべての冗長性戦略に対応する、概略のインストール手順と設定手順が含まれます。DS1 および DS2 に対するタスクのリストは、Directory Server マルチマスターレプリケーションに対する計画の例です。AM1 および AM2 に対するタスクのリストは、負荷分散されるコンポーネントに対する計画の例です。STR1 および STR2 に対するタスクのリストは、Sun Cluster 設定で動作するコンポーネントに対する計画の例です。
STR1 および STR2 に対するタスクは、1 台のコンピュータに複数のコンポーネントをインストールして設定する例を提供します。最初のインストーラ実行で、Sun Cluster コアコンポーネントがインストールされます。Sun Cluster コアコンポーネントを設定したあと、再度インストーラを実行して Messaging Server と Calendar Server をインストールします。これらのコンポーネントは、それぞれの依存性に従って順番に設定されます。コンピュータ上での 3 回目のインストーラ実行では、Messaging Server と Calendar Server の存在に応じて、Sun Cluster Agents for Messaging Server および Sun Cluster Agents for Calendar Server がインストールされます。