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

第 3 章 インストール計画の準備

第 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 に示すような一連のタスクを実行する場合があります。

図 3–1 分散インストール手順の例

コンピュータ 01 上で、Messaging Server および Calendar Server をインストールし、Messaging Server を設定し、Calendar Server を設定します。コンピュータ 02 上で同じ手順を繰り返します。

コンポーネントの依存関係

Java ES コンポーネントの中には、ほかのコンポーネントをまずインストールして設定してからでないと、インストールと設定ができないものがあります。依存性が発生する理由はいくつかあります。

これらの依存性には、ソリューションレベルのものとローカルのものがあることに注意してください。インストール計画を作成するときは、ソリューションレベルの依存性とローカルの依存性を分けて考えます。次の例で違いを説明します。

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 コンポーネントの依存性

製品コンポーネント

依存性 

依存性の性質 

ローカルである必要性 

Access Manager

Directory Server 

設定データを格納するため。ユーザーデータを格納し、検索を可能にするため 

不可 

 

J2EE Web コンテナ、次のいずれか 

-Application Server 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

Access Manager はこれらの Web コンテナのいずれかに配備される必要がある 

可能 

Access Manager SDK

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

Message Queue

信頼性のある非同期メッセージングを提供するため 

可能 

 

Web Server (オプション)

Application Server インスタンス間の負荷分散を提供するため 

可能 

 

High Availability Session Store (オプション)

Application Server 間のフェイルオーバーをサポートするセッション状態を格納するため 

可能 

Directory Proxy Server

Directory Server 

基盤の LDAP ディレクトリサービスを提供するため 

不可 

Directory Server

なし 

   

High Availability Session Store 

なし 

   

Java DB 

なし 

   

Message Queue 

Directory Server (省略可能) 

管理されたオブジェクトと持続メッセージを格納するため 

不可 

 

J2EE Web コンテナ (次のいずれか、省略可能):

-Application Server 

-Web Server 

クライアントとメッセージブローカ間の HTTP トランスポートをサポートするため 

不可 

 

Sun Cluster (省略可能) 

高可用性ソリューションでの Message Queue の使用をサポートするため 

不可 

Portal Server

J2EE Web コンテナ (次のいずれか):

-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 Secure Remote Access

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 Agents

Sun Cluster 

基本的なクラスタサービスを提供するため 

可能 

Sun Cluster Geographic Edition 

Sun Cluster 

基本的なクラスタサービスを提供するため 

可能 

Web Proxy Server

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 に示すような、一連のインストールおよび設定タスクを実行する場合があります。

図 3–2 コンポーネントの相互動作のための設定

コンピュータ 01: Directory Server。コンピュータ 02: Access Manager をインストールし、コンピュータ 01 上の Directory Server インスタンスと相互動作するように設定します。

ソリューションのアーキテクチャーがどのようなものであれ、コンポーネントの設定と、正しく相互動作する分散ソリューションの実現のために必要なすべての設定値を含むインストール計画を作成する必要があります。

冗長性戦略

本稼働環境での使用を想定したほとんどのソリューションでは、何らかの種類の冗長化を利用します。冗長性戦略では、コンポーネントの複数のインスタンスを使って 1 つのサービスを提供します。冗長化はサービス品質要件を満たすために利用されます。たとえば、スループットを増強してパフォーマンス要件を満たす目的や、シングルポイント障害を回避して信頼性要件を満たす目的で冗長化を使用します。

Java ES コンポーネントのインスタンス冗長化のために利用できる戦略は 3 つあります。負荷分散、Sun Cluster ソフトウェアによるクラスタリング、および、Directory Server レプリケーションです。ここでは、これらの戦略のそれぞれに対して推奨されるインストールおよび設定手順の概略を示します。

配備アーキテクチャーでこれらの冗長性戦略のいずれかを使用するときは、コンポーネントの複数のインスタンスをインストールし、単独のサービスとして動作するようそれらのインスタンスを設定する手順を、インストール計画に含める必要があります。

LDAP スキーマと LDAP ディレクトリツリーの構造

ほとんどの Java ES ソリューションには Directory Server が含まれます。Directory Server でソリューションをインストールし設定する場合は、ディレクトリスキーマとディレクトリツリー構造の両方を設定する値を入力します。インストール計画では、正しい LDAP スキーマとディレクトリツリー構造を作成する入力値をリストする必要があります。

LDAP スキーマとディレクトリツリー構造は、インストール計画を開始する前に指定します。インストール計画には、インストーラを実行して指定したスキーマとディレクトリ構造を作成するときに入力する値を含めます。スキーマとディレクトリツリー仕様の例は、「ユーザー管理仕様の作成」を参照してください。

LDAP スキーマは、次のインストールおよび設定プロセスによって確立されます。

  1. Directory Server をインストールすると、スキーマ 1 のディレクトリが自動的に確立されます。スキーマを選択するための入力は不要です。

  2. Access Manager をインストールすると、ディレクトリが自動的に変更され、そのディレクトリがスキーマ 2 に変換されます。スキーマを選択するための入力は不要です。

  3. Communications Suite コンポーネントが含まれるソリューションでは、Directory Preparation Tool を実行すると、Messaging Server、Calendar Server、および Communications Express で使用するためのスキーマが拡張されます。Directory Preparation Tool は、スキーマ 1 ディレクトリとスキーマ 2 ディレクトリの両方を拡張します。Directory Preparation Tool に対する入力値はインストール計画にリストされます。

  4. Communications Suite コンポーネントが含まれるソリューションでは、Delegated Administrator を実行すると、スキーマが拡張され、特定のサービスに対してユーザーを承認および認証するために使われるオブジェクトクラスと属性が追加されます。入力値は、ソリューションが提供するサービスの内容によって異なります。入力値をインストール計画に記述します。

インストールと設定のプロセスでは、基本ディレクトリツリー構造も確立されます。

  1. Directory Server をインストールすると、ベースサフィックス (ディレクトリツリーのルート) が作成されます。ベースサフィックスは、Java ES インストーラが Directory Server をインストールするときに必要な入力値です。インストール計画では、インストールプロセスのための入力値の 1 つとしてベースサフィックスを指定します。

  2. Messaging Server をインストールして設定すると、ディレクトリツリーが分岐して LDAP 組織が作成されます。この組織は、Messaging Server インスタンスによって管理される電子メールドメインを表します。組織の名前は、Messaging Server の設定ウィザードで必須の入力です。インストール計画では、Messaging Server の設定プロセス用の入力値の 1 つとして組織 DN を指定します。

  3. Calendar Server、Communications Express、Delegated Administrator、および Instant Messaging のインストールと設定では、これらのコンポーネントがユーザーデータを検索するディレクトリ構造内の場所を指定します。LDAP DN は各コンポーネントの設定ウィザードの必須入力であり、インストール計画では各設定ウィザード用の入力値として DN を指定します。ソリューションで Access Manager シングルサインオンを使用する場合、これらのコンポーネントがすべて同じ場所 (Messaging Server の設定ウィザードで作成された組織) にユーザーデータを保存するように設定する必要があります。これら全コンポーネントの設定ウィザードで、同じ LDAP DN が入力されます。インストール計画では、すべての設定ウィザードに対する入力値の 1 つとして組織 DN を指定します。

LDAP ベースサフィックスおよび電子メール組織の名前を、ユーザー管理仕様をもとに決定し、インストール計画に追加します。ユーザー管理仕様の詳細については、「ユーザー管理仕様の作成」を参照してください。

Java ES インストーラの動作

ここでは、インストール計画に影響する Java ES インストーラの一部の動作について説明します。

インストーラはローカルである

Java ES インストーラは、コンポーネントソフトウェアを一度に 1 台のコンピュータにインストールします。ほとんどのソリューションは分散構成であり、インストーラを複数回実行する必要があります。インストール計画には、インストールの実行のたびに行う手順を含める必要があります。ここでは、アーキテクチャーを実装するためにインストーラを実行する必要がある回数を、配備アーキテクチャーの分析に基づいて決定する方法について説明します。

ソリューションの中には 1 台のコンピュータにのみインストールされるものがあり、そのようなソリューションのインストール計画は、インストーラを 1 回だけ実行するための手順を定義します。インストーラの実行が 1 回で済むのは次のようなソリューションです。

ほとんどのソリューションは、複数のコンピュータに分散されます。そのようなソリューションのインストール計画では、ソリューション全体をインストールおよび設定するために、複数回のインストーラ実行を記述する必要があります。そのようなソリューションを分析するには、次のガイドラインを使用します。

この節の目的は、インストール計画では時として、1 台のコンピュータ上でのインストーラと設定ウィザードの実行、または、1 台のコンピュータ上での複数回のインストーラ実行を記述しなければならないという概念を紹介することです。さまざまなコンポーネントの組み合わせに対する実際のインストール手順の詳細については、「インストール計画の作成」を参照してください。

インストーラの動作モード

インストーラは、「今すぐ設定」と「あとで設定」の 2 つの異なるモードで動作します。2 つのモードの違いは次の点です。

選択した設定オプションは、インストールセッション全体に適用されます。「今すぐ設定」モードと「あとで設定」モードで一部のコンポーネントをコンピュータ上にインストールしたい場合は、インストーラを複数回実行する必要があります。

インストーラの互換性チェック

Java ES インストーラでは、依存性と互換性に関するいくつかのチェックが実行されます。ただし、インストーラでチェックできるのはローカルコンピュータのみです。たとえば、分散ソリューションで Access Manager をインストールする場合、インストーラでは、インストールする Access Manager との互換性がリモート Directory Server にあるかどうかのチェックを行うことはできません。

同じ Java ES リリースのすべてのコンポーネントを含む完全に新規のソリューションをインストールし設定する場合、互換性が問題になることは考えられません。確立済みのソリューションに新しいコンポーネントを追加している場合や、既存のコンポーネントの周囲に Java ES ソリューションを構築している場合、そのことが問題となる可能性があります。たとえば、すでに Directory Server を使用しており、Access Manager と Portal Server を使用するソリューションを既存の Directory Server の周囲に構築している場合、コンポーネント間の互換性が問題となります。新しいコンポーネントのインストールと設定を開始する前に、コンポーネントの互換性を確認する必要があります。

インストールに関するその他の問題

この節では、一部のソリューションで発生するいくつかの固有の問題を、詳細な情報の参照先とともに示します。

表 3–2 考慮する必要のあるインストールの問題

ソリューションに必要なもの 

ガイドラインまたは取扱説明書 

Solaris 10 ゾーンの使用 

Solaris 10 ゾーンへのインストールを予定している場合、付録 A 「Java ES と Solaris 10 ゾーン」を参照してください。

Directory Server 暗号化の使用 

Directory Server インスタンス上で LDAPS (SSL over LDAP) を設定します。 

Access Manager でのサードパーティー製 Web コンテナの使用

サードパーティー製 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 の使用

Apache Web Server は、Application Server の負荷分散プラグインで使用することができます。この場合、Apache Web Server は、このサーバーに依存する Java ES コンポーネントをインストールする前にインストールし、実行する必要があります。 

スキーマ 1 LDAP の使用

スキーマ 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 の配備アーキテクチャーおよび実装仕様に応用する必要があります。ソリューション内のコンポーネントインスタンスをインストールして設定する正しいシーケンスと、コンポーネントインスタンスの相互動作を実現する正しい設定入力値を決定する必要があります。

この節では、配備アーキテクチャーと一連の仕様を分析して、インストール計画を作成する方法について説明します。通常は、次のような手順で作業を開始します。

  1. 計画を記録するためのテキストファイル、空白の紙、またはそのほかのメディアを開きます。

  2. 配備アーキテクチャーで、各コンピュータシステム上のコンポーネントを検証し、どのようなコンポーネント依存性が存在するかを判断します。

  3. ほかのコンポーネントへの依存性を持たないコンポーネントインスタンスを識別します。そのようなインスタンスは通常、Directory Server のインスタンスです。インストール計画の作成は、指定されたコンピュータシステムにそのようなコンポーネントインスタンスをインストールするための手順の定義から始めます。そのようなコンピュータシステムと、それらのシステムにインストールされるコンポーネントインスタンスを記録して、インストール計画を開始します。

  4. それらのコンピュータシステム上のコンポーネントインスタンスについて、対象のソリューションにおける正しいインストール/設定値を決定します。これらの設定値をインストール計画に追加します。

  5. 残りのコンポーネントの中で、Directory Server にのみ依存性を持つコンポーネントを特定します。それらは通常、Access Manager が動作するコンピュータシステムです。次に、それらのコンピュータシステムをインストール計画にリストします。

  6. コンポーネントの依存性の順序で仕様の分析を続けます。必要な設定値を決定し、それらのコンポーネントインスタンスを計画に記録します。

たとえば、このプロセスを使用して、図 2–1 に示した配備アーキテクチャーを分析する場合、表 3–3 のようなインストール計画を作成します。

表 3–3 は、インストール計画の最初の 8 つのステップを示したものです。この計画の構造を明確にするために、個別の設定値についてはリストしていません。この計画では、次のことに注意します。

表 3–3 サンプル配備アーキテクチャーのインストール計画要約

コンピュータ 

インストールと設定のタスク 

DS1

  1. このコンピュータ上で Java ES インストーラを実行します。ユーザー管理仕様で指定された設定値を使用して、Directory Server インスタンスをインストールおよび設定します。

  2. Directory Server インスタンスを起動し、検証します。

DS2 

  1. このコンピュータ上で Java ES インストーラを実行します。ユーザー管理仕様で指定された設定値を使用して、Directory Server インスタンスをインストールおよび設定します。

  2. Directory Server インスタンスを起動し、検証します。

  3. 両方の Directory Server インスタンスに対してロードバランサが正しく機能していることを検証します。

  4. DS2 内の Directory Server インスタンスを停止します。DS1 上の Directory Server インスタンスはそのまま実行させておきます。

AM1 

  1. このコンピュータ上で Java ES インストーラを実行します。Access Manager インスタンスをインストールおよび設定します。Access Manager インスタンスは、負荷分散される Directory Server インスタンスによって作成される論理ディレクトリサービスと相互動作するように設定します。

  2. Access Manager インスタンスを起動し、検証します。

  3. 負荷分散のために Access Manager インスタンスを設定します。

AM2 

  1. このコンピュータ上で Java ES インストーラを実行します。Access Manager インスタンスをインストールおよび設定します。Access Manager インスタンスは、負荷分散される Directory Server インスタンスによって作成される論理ディレクトリサービスと相互動作するように設定します。

  2. Access Manager インスタンスを起動し、検証します。

  3. 負荷分散のために Access Manager インスタンスを設定します。

  4. Access Manager コンソールを使用して、Access Manager に対するディレクトリエントリを変更します。

  5. 2 つの Access Manager インスタンスが、処理が負荷分散されて正しく機能していることを検証します。

STR1 

  1. Java ES インストーラを実行します。Sun Cluster コアコンポーネントをインストールします。

  2. Sun Cluster 設定用にコンピュータを準備します。このステップには、Sun Cluster ソフトウェアによって使用されるファイルシステムの作成とマウントが含まれます。

  3. Sun Cluster の設定ウィザードを実行します。クラスタを確立および設定します。

STR2 

  1. Java ES インストーラを実行します。Sun Cluster コアコンポーネントをインストールします。

  2. Sun Cluster 設定用にコンピュータを準備します。このステップには、Sun Cluster ソフトウェアによって使用されるファイルシステムの作成とマウントが含まれます。

  3. Sun Cluster の設定ウィザードを実行します。クラスタを確立および設定します。

  4. STR1 および STR2 上で NTP (Network Timing Protocol) の設定を完了します。

  5. quorom デバイスを (両方のコンピュータに接続された) クラスタに追加します。

  6. クラスタファイルシステムとリソースグループを作成し、仮想ホスト名と IP アドレスを設定します。

  7. クラスタのフェイルオーバー機能を検証します。

STR1 

  1. Java ES インストーラを実行します。Messaging Server および Calendar Server をインストールします。

  2. コンピュータ DS1 上で Directory Server Preparation Tool を実行します。

  3. Messaging Server の設定ウィザードを実行して、Messaging Server のインスタンスを作成します。ユーザー管理仕様に従って LDAP ディレクトリツリー内にブランチを作成する設定値を指定します。負荷分散された Access Manager インスタンスおよび負荷分散された Directory Server インスタンスと相互動作するように Messaging Server インスタンスを設定する設定値を指定します。

  4. シングルサインオン用に Messaging Server を設定します。

  5. Messaging Server インスタンスを起動し、検証します。

  6. Calendar Server の設定ウィザードを実行して、Calendar Server のインスタンスを作成します。Messaging Server の設定によってユーザーおよびグループデータ用に作成された LDAP ブランチを使用するようにインスタンスを設定する設定値を指定します。負荷分散された Access Manager インスタンスおよび負荷分散された Directory Server インスタンスと相互動作するように Calendar Server インスタンスを設定する設定値を指定します。

  7. コンピュータ STR2 上で、Calendar Server のユーザー、ユーザーグループ、およびディレクトリを作成します。

  8. Calendar Server の設定ファイルを編集します。コンピュータの IP アドレスの代わりに仮想 IP アドレスを使用するように設定パラメータを設定します。

  9. シングルサインオン用に Calendar Server を設定します。

  10. Calendar Server インスタンスを起動し、検証します。

STR1 

  1. Java ES インストーラを実行します。Sun Cluster Agent for Messaging Server および Sun Cluster Agent for Calendar Server をインストールします。

  2. Messaging Server エージェントを使用して、Messaging Server リソースを作成および有効化します。

  3. Messaging Server リソースの、STR1 から STR2 へのフェイルオーバーを検証します。

  4. Calendar Server エージェントを使用して、Calendar Server リソースを作成および有効化します。

  5. Calendar Server リソースの、STR1 から STR2 へのフェイルオーバーを検証します。

STR2 

mscs01 上で設定したインスタンスは、共有インスタンスとして自動的に認識されます。