ヘッダーをスキップ

Oracle Collaboration Suiteインストレーション・ガイド 10gリリース1（10.1.2） for AIX 5L Based Systems（64-bit） B25916-02 |
| 目次 | 索引

戻る | 次へ |

# 8 高可用性環境でのOracle Collaboration Suiteのインストール

この章の内容は次のとおりです。

- 8.1項「高可用性構成の理解: 概要と共通の要件」

- 8.2項「高可用性環境でのOracle Collaboration Suiteのインストール準備」

- 8.3項「高可用性環境でのOracle Calendar Serverのインストール」

## 8.1 高可用性構成の理解: 概要と共通の要件

この項では、Oracle Collaboration Suiteでサポートされている高可用性構成の概要について説明します。

この項の内容は次のとおりです。

- 8.1.1項「高可用性の一般原則の理解」

- 8.1.2項「高可用性構成」

- 8.1.3項「高可用性構成のインストール順序」

- 8.1.4項「高可用性構成の要件」

### 8.1.1 高可用性の一般原則の理解

Oracle Collaboration Suiteの高可用性ソリューションのインストールには、次の主要コンポーネントが含まれています。

- Oracle Collaboration Suiteデータベース層

- Identity Managementサービス

- Oracle Calendar Server

- Oracle Collaboration Suiteアプリケーション層

#### 8.1.1.1 Oracle Collaboration Suiteデータベース層

Oracle Collaboration Suiteデータベース層は、Oracle Database 10gに基づいて構築され、Oracle Collaboration Suiteのスキーマ情報およびOracleAS 10gリリース2（10.1.2）Metadata Repositoryのリポジトリとして機能します。Oracle Collaboration Suiteからインストールした場合、データベースのデフォルトのバージョンは10.1.0.4.2です。

この層のプロセスは、データベース・インスタンスのプロセスとデータベース・リスナーです。

高可用性環境では、このデータベースをアクティブ-アクティブ構成でOracle Real Application Clustersデータベースに配置することをお薦めします。

Oracle Collaboration SuiteデータベースのOracleホームは、ハードウェア・クラスタの各ノードにインストールされます。各ノードには固有の`oraInventory`があり、これはそのノード上の他のOracleホームに共有されています。

Oracle Collaboration Suiteデータベース層のハードウェア要件は、次のとおりです。

- Oracle Cluster Ready Servicesがインストールされたハードウェア・クラスタ。

- Oracle Real Application Clustersのデータベース・ファイルとCRSクラスタ・レジストリおよび投票ディスク用の共有ストレージ。Oracle Databaseファイルは、RAWデバイスまたはネットワーク接続ストレージ（NAS）に格納できます。または、Oracle自動ストレージ管理（ASM）を使用できます。

- 各クラスタ・ノードの仮想IPアドレス。

#### 8.1.1.2 Identity Managementサービス

Identity Management層は、次の要素で構成されています。

- Oracle Internet Directory層

  Oracle Internet Directory層は、データベース層またはOracleAS Single Sign-On層と同じ場所に配置したり、別の場所に配置できます。同じ場所に配置するということは同じコンピュータに配置することを表し、多くの場合は同じOracleホームを共有します。

  この層の主要プロセスは、Oracle Internet DirectoryおよびOracle Directory Integration and Provisioningのプロセスです。

  高可用性環境では、この層の複数のインスタンスを配置するか、または使用可能な任意のコンピュータにサービスをフェイルオーバーするように配置を設計することをお薦めします。この層をアクティブ-アクティブ構成で配置するには、ハードウェア・ロード・バランサが必要です。

- OracleAS Single Sign-On層

  この層は、Oracle Internet Directory層と同じ場所に配置したり、別の場所に配置できます。同じ場所に配置するということは同じコンピュータに配置することを表し、多くの場合は同じOracleホームを共有します。また、通常は、OracleAS Single Sign-OnとOracle Delegated Administration Servicesのサービスを同じ場所に配置します。

  この層の主要プロセスは、Oracle HTTP ServerとOC4Jのインスタンスです。OC4Jインスタンスでは、OracleAS Single Sign-OnおよびOracle Delegated Administration Servicesアプリケーションをホスティングします。

  高可用性環境では、この層の複数のインスタンスを配置するか、または使用可能な任意のコンピュータにサービスをフェイルオーバーするように配置を設計することをお薦めします。この層をアクティブ-アクティブ構成で配置するには、ハードウェア・ロード・バランサが必要です。

Oracleホームはハードウェア・クラスタの各ノード上にあります。すべてのOracleホームは、各ノードにある単一の共有`oraInventory`を使用します。

Identity Management層のハードウェア要件は、次のとおりです。

- 単一ノード

- ローカル・ストレージ

- ノードのフロントエンドとして機能し、Oracle Identity Managementクラスタの全ノードでIdentity Managementサービスにリクエストをルーティングするロード・バランサ

#### 8.1.1.3 Oracle Calendar Server

Oracle Calendar Serverには、すべてのCalendar関連データを格納するファイル・システム・レベルのデータベースが含まれています。このデータベースはOracle Databaseではありません。したがって、Oracle Databaseと同じ高可用性機能は提供されません。このOracle CalendarのインストールにはOracle Calendar Serverコンポーネントのみが含まれ、Oracle Collaboration Suiteアプリケーション層でデプロイされるOracle Calendarアプリケーション・システムは含まれません。

Oracle Collaboration Suiteの高可用性ソリューションを保証するため、Oracle Calendar Server（カレンダ・ノードごとに1つのサーバー）は、シングル・ポイント障害の発生場所であるCold Failover Cluster上に配置されます。このCold Failover Clusterのインストールには、Oracleホーム・ツリー用の共有ストレージが必要です。Oracle Calendar Serverのファイル・システム・データベースは、Oracleホーム・ディレクトリ・ツリーに含まれています。Cold Failover Clusterを使用するには、仮想IPアドレスと仮想ホストが必要です。

Oracle Calendar Serverのハードウェア要件は、次のとおりです。

- ハードウェア・クラスタ。

- Oracle Calendar Serverの`ORACLE_HOME`ディレクトリ用の共有ストレージ。

- 仮想IPアドレス。

#### 8.1.1.4 Oracle Collaboration Suiteアプリケーション層

この層には、Oracle Calendar Serverを除くOracle Collaboration Suiteアプリケーションのすべてのコンポーネントが含まれています。Oracle Calendar Serverは、複数のノードに別にインストールします。通常、アプリケーション層は非武装地帯（DMZ）に配置します。DMZはイントラネットとインターネットの間にあるネットワークの一部で、中立地帯とも呼ばれます。これにより、イントラネット内のホストの特定のサービスのみが、インターネット上のホストからアクセスできるようになります。このサブネットワークは特に、Webサーバーなどのパブリック・アクセス・サーバーに対して使用されます。ロード・バランサ仮想サーバーは、複数のアプリケーション層のフロントエンドを構成します。Oracle Collaboration Suite 10gアプリケーション層へのクライアント・リクエストに対し、アプリケーション・ノード全体でロード・バランサ仮想サーバーを使用したロード・バランシングが実行されます。

Oracleホームは、ハードウェア・クラスタの各ノードにインストールされます。すべてのOracleホームは、各ノードにある単一の共有`oraInventory`を使用します。

アプリケーション層のハードウェア要件は、次のとおりです。

- 単一ノード

- ローカル・ストレージ

- Oracle Collaboration Suiteアプリケーション層ノードのフロントエンドとして機能し、リクエストをバランシングしてクラスタのアクティブ・ノードにルーティングするロード・バランサ

### 8.1.2 高可用性構成

この項では、高可用性構成の特長と、Oracle Collaboration Suiteでサポートされている標準の高可用性構成の概要について説明します。構成の詳細は、『Oracle Collaboration Suite高可用性ガイド』を参照してください。

Oracle Collaboration Suiteでは、次の高可用性構成がサポートされています。

- 単一クラスタ・アーキテクチャ

- 同じ場所に配置されたIdentity Managementアーキテクチャ

- 分散Identity Managementアーキテクチャ

Oracle Collaboration Suiteの高可用性構成の特長は次のとおりです。

- 共有ストレージ: すべてのノードに共有ストレージへのアクセス権が必要です。Oracle Calendar Serverのインストールの場合、`ORACLE_HOME`を含む共有ディスクをマウントするノードは常に1つのみです。Oracle Real Application Clustersデータベースを実行しているすべてのノードから、Oracle Collaborationデータベースを含む共有ストレージへの同時アクセスが可能である必要があります。Oracle Mobile Data Sync機能を使用する場合は、ここでもOracle Collaboration Suiteアプリケーション層の共有ストレージが必要です。

- ハードウェア・クラスタ: ハードウェア・クラスタは、複数のコンピュータによるデータ、ソフトウェアまたは周辺機器への共有アクセスを可能にする、ハードウェア・アーキテクチャです。ハードウェア・クラスタはOracle Real Application Clustersで必要です。Oracle Real Application Clustersはこのようなアーキテクチャを利用して、物理的に1つのデータベースを共有する複数のデータベース・インスタンスを実行します。各ノードのデータベース・インスタンスは高速のネットワーク・インターコネクトを使用して互いに通信します。

- 非クラスタ・サーバー: Identity Management層およびOracle Collaboration Suiteアプリケーション層には複数の非クラスタ・サーバーが必要です。最小の単一クラスタ・アーキテクチャはハードウェア・クラスタ・ノードで構成されているため、これは適用されません。

- ロード・バランサ: すべてのアクティブ・ノードに対するリクエストのロード・バランシングを実行するには、ロード・バランサが必要です。ロード・バランサを必要とするのは、Identity Managementおよびアプリケーション関連のリクエストです。Identity Management層およびアプリケーション層に対するリクエストは、ロード・バランサの仮想サーバー名およびポートを経由してルーティングされます。

#### 8.1.2.1 単一クラスタ・アーキテクチャ

すべてのOracle Collaboration Suite高可用性コンポーネント、Oracle Collaboration Suiteデータベース、Identity Management、Oracle Calendar Serverおよびアプリケーションを単一クラスタにインストールする最小構成です。このアーキテクチャはデフォルトのソリューションではありません。Oracle Collaboration Suiteを複数回インストールし、インストール後の構成を手動で実行する必要があります。

このアーキテクチャでは、Oracle Collaboration SuiteデータベースはRAC上にインストールされ、Identity Managementおよびアプリケーションの両方がアクティブ-アクティブ高可用性構成として構成されます。Oracle Calendar Serverは前述したとおりCold Failover Cluster構成でインストールされます。

単一クラスタ・アーキテクチャ構成の特徴は、次のとおりです。

- アクティブ・ノード: 単一クラスタ・アーキテクチャ構成では、すべてのノードがアクティブです。つまり、すべてのノードがリクエストを処理できます。1つのノードに障害が発生した場合は、残りのノードがすべてのリクエストを処理します。

- 共有ディスク: 通常、Oracle Collaboration Suiteは共有ディスクにインストールします。すべてのノードから共有ディスクにアクセスできますが、共有ディスクをマウントするノードは常に1つのみです。ただし、Oracle Collaboration Suiteデータベース（Oracle Calendar Server Cold Failover Cluster構成と同じクラスタにインストールされている場合）は、Oracle Calendar Serverの共有ストレージとは別の共有ストレージに配置する必要があります。また、Oracle Real Application Clustersデータベースを実行しているすべてのノードから共有ディスクへの同時アクセスが可能である必要があります。

- ハードウェア・クラスタ: ベンダー固有のクラスタウェアまたはOracle Cluster Ready Services（あるいはその両方）です。

- ロード・バランサ: すべてのアクティブ・ノードに対するリクエストのロード・バランシングを実行するには、ロード・バランサが必要です。ロード・バランサを必要とするのは、Identity Managementおよびアプリケーション関連のリクエストです。Identity Management層およびアプリケーション層に対するリクエストは、ロード・バランサの仮想サーバー名およびポートを経由してルーティングされます。

図8-1は、一般的な単一クラスタ・アーキテクチャ構成を示しています。

図8-1 一般的な単一クラスタ・アーキテクチャ構成

「図8-1 一般的な単一クラスタ・アーキテクチャ構成」の説明

単一クラスタ・アーキテクチャのインストールの詳細は、第9章を参照してください。

#### 8.1.2.2 同じ場所に配置されたIdentity Managementアーキテクチャ

このアーキテクチャは個別の層を複数のコンピュータに分割します。すべての層のノードを単一クラスタ・アーキテクチャで共有するのではなく、ハードウェア・クラスタ依存層や、ハードウェア・クラスタ上のOracle Real Application ClustersデータベースおよびOracle Calendar Server Cold Failover Clusterを安全なイントラネット内に配置します。Identity Management層およびOracle Collaboration Suiteアプリケーション層は、DMZに存在する一連の非クラスタ・コンピュータに分割されます。「同じ場所に配置された」という言葉は、Identity Management層がOracle Internet Directory層およびOracle Single Sign-On層の両方を1つの`ORACLE_HOME`に配置していることを指しています。このアーキテクチャはデフォルトのソリューションではありません。Oracle Collaboration Suiteを複数回インストールし、インストール後の構成を手動で実行する必要があります。

このアーキテクチャでは、Identity ManagementおよびOracle Collaboration Suiteデータベースをアクティブ-アクティブ高可用性構成として構成します。

図8-2は、一般的な同じ場所に配置されたIdentity Managementアーキテクチャ構成を示しています。

図8-2 一般的な同じ場所に配置されたIdentity Managementアーキテクチャ構成

「図8-2 一般的な同じ場所に配置されたIdentity Managementアーキテクチャ構成」の説明

同じ場所に配置されたIdentity Managementアーキテクチャのインストールの詳細は、第9章を参照してください。

#### 8.1.2.3 分散Identity Managementアーキテクチャ

この構成は、同じ場所に配置されたIdentity Managementアーキテクチャに類似しています。このアーキテクチャでも、個別の層を複数のコンピュータに分割します。ハードウェア・クラスタ依存層や、ハードウェア・クラスタ上のOracle Real Application ClustersデータベースおよびOracle Calendar Server Cold Failover Clusterを安全なイントラネット内に配置します。同じ場所に配置されたアーキテクチャと異なるのは、Identity Managementコンポーネント、Oracle Internet DirectoryおよびOracle Application Server Single Sign-OnをDMZの複数の非クラスタ・サーバーに個別にインストールして分散する点です。このため、分散Identity Managementアーキテクチャと呼ばれています。このアーキテクチャはデフォルトのソリューションではありません。Oracle Collaboration Suiteを複数回インストールし、インストール後の構成を手動で実行する必要があります。

このアーキテクチャでは、Oracle Internet DirectoryおよびOracle Application Server Single Sign-Onが1つのアクティブ-アクティブ高可用性構成を共有します。ただし、Oracle Collaboration Suiteデータベースの高可用性構成は、アクティブ-アクティブまたはアクティブ-パッシブとすることができます。

図8-3は、一般的な分散Identity Managementアーキテクチャ構成を示しています。

図8-3 一般的な分散Identity Managementアーキテクチャ構成

「図8-3 一般的な分散Identity Managementアーキテクチャ構成」の説明

分散Identity Managementアーキテクチャのインストールの詳細は、第9章を参照してください。

### 8.1.3 高可用性構成のインストール順序

すべての高可用性構成では、次の順序でコンポーネントをインストールします。

1. Oracle Collaboration Suiteデータベース

2. Identity Managementコンポーネント

   Identity Managementコンポーネントを分散する場合は、次の順序でインストールします。

   1. Oracle Internet DirectoryおよびOracle Directory Integration and Provisioning

   2. Oracle Application Server Single Sign-OnおよびOracle Delegated Administration Services

3. Oracle Calendar Server

4. Oracle Collaboration Suiteアプリケーション・コンポーネント

### 8.1.4 高可用性構成の要件

高可用性環境にOracle Collaboration Suiteをインストールする場合は、次の要件に注意してください。

- データベースの要件

  Oracle Cluster Ready Services（CRS）をインストールしておく必要があります。その次にOracle Collaboration Suiteインストーラを実行する際は、「クラスタ・インストール」を選択します。これによって、Oracle Collaboration Suiteインフラストラクチャも含めてOracle Collaboration Suite Real Application Clustersデータベースがインストールされます。

- コンポーネントの要件

  インストーラによってIdentity Management構成のコンポーネントがクラスタ化されます。そのため、「構成オプションの選択」画面では、クラスタ内のすべてのノードに対して同じコンポーネントを選択する必要があります。

  たとえば、ノード1へのインストール対象としてOracle Internet Directory、OracleAS Single Sign-OnおよびOracle Delegated Administration Servicesを選択した場合は、後続のインストールでも同じコンポーネントを選択する必要があります。

  各インストールで異なるコンポーネントを選択した場合、クラスタ化は失敗します。

すべての高可用性構成に共通の要件は、次のとおりです。

- ノードの最小数の確認

- クラスタウェアが実行中であることの確認

- グループがすべてのノードで同様に定義されていることの確認

- oracleユーザーのプロパティの確認

- すべてのノードでの以前にインストールされたOracleの有無の確認

これらの共通要件以外に、各構成にはそれぞれ固有の要件があります。詳細は、個々の章を参照してください。

注意: 使用する高可用性構成に固有の要件以外に、第2章に示す要件も満たしている必要があります。

#### 8.1.4.1 ノードの最小数の確認

高可用性構成には、2つ以上のノードが必要です。1つのノードに障害が発生した場合は、2つ目のノードが処理を引き継ぎます。

#### 8.1.4.2 クラスタウェアが実行中であることの確認

クラスタ内の各ノードが、許可されたクラスタウェアを実行している必要があります。

AIXでのIBM HACMPのチェック

次のコマンドを入力し、IBM HACMPが実行していることを確認します。

    $ /usr/bin/lssrc -ls grpsvcs

このコマンドの出力では、クラスタ内のノード数と等しい`プロバイダ数`が`CLSTRMGR_``cluster_id`に示される必要があります。

#### 8.1.4.3 グループがすべてのノードで同様に定義されていることの確認

クラスタ内のすべてのノードの`/etc/group`ファイルに、使用するオペレーティング・システム・グループが含まれていることを確認します。`oraInventory`ディレクトリ用に1つ、データベース管理用に1つまたは2つのグループが必要です。グループ名とグループIDは、すべてのノードで同じである必要があります。

詳細は、2.6項を参照してください。

#### 8.1.4.4 oracleユーザーのプロパティの確認

詳細は、2.6項を参照してください。

#### 8.1.4.5 すべてのノードでの以前にインストールされたOracleの有無の確認

高可用性構成のOracle Collaboration Suiteをインストールするすべてのノードに、既存の`oraInventory`ディレクトリが存在しないことを確認します。

この確認は、インストーラで`oraInventory`ディレクトリの場所の入力が求められるようにするために行います。既存の`oraInventory`ディレクトリの場所は、インストールしようとしているOracle Collaboration Suiteインスタンスに最適とはかぎりません。たとえば、`oraInventory`ディレクトリを共有ストレージ上に設定します。インストーラで既存の`oraInventory`ディレクトリが検出された場合は、自動的にそのディレクトリが使用され、場所の入力は求められません。

インストーラで検出される`oraInventory`ディレクトリがノードにあるかどうかを確認するには、次の手順を実行します。

1. 各ノードで、`/etc/oraInst.loc`ファイルの有無を確認します。

   ノードにこのファイルが含まれていない場合、そのノードにはインストーラが使用する`oraInventory`ディレクトリはありません。次のノードの確認に移ることができます。

2. `oraInst.loc`ファイルが含まれているノードで、`oracle`ディレクトリの名前を別の名前に変更し、インストーラで検出されないようにします。これにより、インストーラで`oraInventory`ディレクトリの場所の入力を求められます。

   次の例では、`oracle`ディレクトリの名前を`oracle.orig`に変更しています（これは、`root`で実行する必要があります）。

       # su
       Password: root_password
       # /etc
       # mv oracle oracle.orig

インストーラを実行してOracle Collaboration Suiteをインストールするときに、インストーラによって新しい`/etc/oracle`ディレクトリが作成され、そのディレクトリに新しいファイルが作成されます。`oracle`ディレクトリと`oracle.orig`ディレクトリの両方が必要な場合があります。いずれかを削除したり、一方をもう一方の名前に変更しないでください。

インストーラでは、`/etc/oracle`ディレクトリとそのファイルを使用します。製品を削除または拡張する場合などは、インストーラを実行する前に、正しい`oracle`ディレクトリが存在していることを確認します。

## 8.2 高可用性環境でのOracle Collaboration Suiteのインストール準備

この項の内容は次のとおりです。

- 8.2.1項「自動ストレージ管理（ASM）に関する推奨事項の確認」

- 8.2.2項「Identity Managementのインストール前の手順」

- 8.2.3項「Oracle Internet Directoryのパスワード」

- 8.2.4項「Oracle HTTP ServerのSSLポートおよび非SSLポートの構成」

### 8.2.1 自動ストレージ管理（ASM）に関する推奨事項の確認

OracleAS Metadata RepositoryデータベースにASMインスタンスを使用する場合は、次の推奨事項を考慮してください。

- 同じノードの複数のデータベース・ホームからOracleデータベース・インスタンスとともにASMを使用する場合は、データベース・ホームとは異なるOracleホームからASMインスタンスを実行する必要があります。

- ASMホームは、すべてのクラスタ・ノードにインストールする必要があります。これにより、データベースのOracleホームを削除するときに、データベースで使用中のASMインスタンスを他のホームから誤って削除することを防止できます。

### 8.2.2 Identity Managementのインストール前の手順

Identity Management構成をインストールする前に、次のタスクを設定する必要があります。

- Oracleホーム・ディレクトリに対する同じパスの使用（推奨）

- すべてのノードの時計の同期化

- ロード・バランサの仮想サーバー名およびポートの構成

- リクエストを最初にノード1に送るためのLDAP仮想サーバーの構成

- ロード・バランサのCookie永続性の設定

- CalendarのOracle Mobile Data Syncに対する共有ストレージの構成

#### 8.2.2.1 Oracleホーム・ディレクトリに対する同じパスの使用（推奨）

Identity Managementコンポーネントを実行するすべてのノードで、Oracleホームに同じフルパスを使用します。これは推奨ですが、必須ではありません。

#### 8.2.2.2 すべてのノードの時計の同期化

すべてのノードのシステム時計を同期化します。

#### 8.2.2.3 ロード・バランサの仮想サーバー名およびポートの構成

2つの仮想サーバー名および関連ポートを指定してロード・バランサを構成します。

- LDAP接続用の仮想サーバー名を構成します。この仮想サーバーに、2つのポートを構成する必要があります。1つはSSL接続用、もう1つは非SSL接続用です。

  注意: LDAP仮想サーバーに対して構成したポートが、Oracle Internet Directoryをインストールするノードで使用できることを確認します。 インストーラによって、Oracle Internet Directoryは、LDAP仮想サーバーに構成されているポート番号を使用するように構成されます。つまり、すべてのノードのOracle Internet DirectoryとLDAP仮想サーバーが同じポート番号を使用するようになります。

- HTTP接続用の仮想サーバー名を構成します。この仮想サーバーについても、2つのポートを構成する必要があります。1つはSSL接続用、もう1つは非SSL接続用です。

  注意: HTTP仮想サーバー用のポートは、Oracle HTTP Serverの`Listen`ポートとは別のポートにできます。

インストーラで仮想サーバー名およびポート番号の入力を求められます。

また、仮想サーバー名がIPアドレスに関連付けられており、DNSの一部であることを確認します。Oracle Collaboration Suiteを実行するノードから、これらの仮想サーバー名にアクセスできる必要があります。

#### 8.2.2.4 リクエストを最初にノード1に送るためのLDAP仮想サーバーの構成

この手順は、ロード・バランサ上に構成されたLDAP仮想サーバーにのみ適用されることに注意してください。ロード・バランサ上に構成されたHTTP仮想サーバーには適用されません。

インストールを開始する前に、リクエストをノード1のみに送るようにLDAP仮想サーバーを構成します。1つのノードでのインストールを完了した後、そのノードを仮想サーバーに追加できます。

たとえば、3つのノードがある場合は、次の手順を実行します。

1. リクエストをノード1のみに送るようにLDAP仮想サーバーを構成します。

2. ノード1にIdentity Managementコンポーネントをインストールします。

3. ノード2にIdentity Managementコンポーネントをインストールします。

4. ノード2をLDAP仮想サーバーに追加します。

5. ノード3にIdentity Managementコンポーネントをインストールします。

6. ノード3をLDAP仮想サーバーに追加します。

#### 8.2.2.5 ロード・バランサのCookie永続性の設定

ロード・バランサに、HTTPトラフィックに対するCookie永続性を設定します。具体的には、`/oiddas/`で始まるURIに対するCookie永続性を設定します。これはOracle Delegated Administration ServicesのURIです。ロード・バランサにURIレベルのCookie永続性を設定できない場合は、HTTPトラフィックに対するCookie永続性を設定します。いずれの場合も、ブラウザ・セッションが期限切れになった場合は失効するようにCookieを設定します。

詳細は、ロード・バランサのドキュメントを参照してください。

#### 8.2.2.6 CalendarのOracle Mobile Data Syncに対する共有ストレージの構成

複数の中間層デプロイでは、複数のCalendar同期サーバー層が存在します。このため、この情報を格納する一元管理されたストレージの場所を各中間層が指し示す必要があります。このようにしないと、時間のかかる完全同期化が不必要に何回も行われることになります。

詳細は、『Oracle Collaboration Suiteデプロイメント・ガイド』の同期化情報のOracle Mobile Data Sync層およびストレージに関する項を参照してください。

### 8.2.3 Oracle Internet Directoryのパスワード

Identity Management構成では、Oracle Internet Directoryを複数のノードにインストールします。インストールごとに、「インスタンス名とias_adminパスワードの指定」画面でインスタンスのパスワードを入力します。

最初のインストールで指定したパスワードが、クラスタ内の最初のOracle Internet Directoryのみでなく、すべてのOracle Internet Directoryのインストールで、`cn=orcladmin`ユーザーおよび`orcladmin`ユーザーのパスワードとして使用されます。

つまり、いずれのノードのOracle Internet Directoryにアクセスする場合も、最初のインストールで入力したパスワードを使用する必要があります。

Oracle Internet Directoryにアクセスするには、次の手順を実行します。

- Oracle Delegated Administration Servicesへのログイン（URL: `http://``hostname``:``port``/oiddas`）

- Oracle Application Server Single Sign-Onへのログイン（URL: `http://``hostname``:``port``/pls/orasso`）

- Oracle Directory Managerを使用したOracle Internet Directoryへの接続

インストールで入力したパスワードは、Application Server Controlへのログイン時に必要です。

### 8.2.4 Oracle HTTP ServerのSSLポートおよび非SSLポートの構成

Identity Management構成をインストールする場合は、インストーラに「HTTPロード・バランサのホストおよびリスニング・ポートの指定」画面が表示されます。

この画面には、次の2つのセクションがあります。

- ロード・バランサのセクションでは、ロード・バランサのHTTP仮想サーバー名とポート番号を指定します。また、ポートがSSLリクエスト用か非SSLリクエスト用かも指定します。

- Oracle HTTP Serverのセクションでは、Oracle HTTP Serverの`Listen`ポートとして使用するポート番号を指定します。また、ポートがSSLリクエスト用か非SSLリクエスト用かも指定します。

  仮想サーバーとOracle HTTP Serverの`Listen`ポートには、異なるポート番号を使用できます。

この画面では、クライアント、ロード・バランサおよびOracle HTTP Server間の通信の種類（SSLまたは非SSL）を設定できます。3つのケースが考えられます。

- ケース1: クライアントとロード・バランサ間の通信にHTTPを使用し、ロード・バランサとOracle HTTP Server間の通信にもHTTPを使用する場合。8.2.4.1項を参照してください。

- ケース2: クライアントとロード・バランサ間の通信にHTTPS（セキュアHTTP）を使用し、ロード・バランサとOracle HTTP Server間の通信にもHTTPSを使用する場合。8.2.4.2項を参照してください。

- ケース3: クライアントとロード・バランサ間の通信にHTTPSを使用し、ロード・バランサとOracle HTTP Server間の通信にHTTPを使用する場合。8.2.4.3項を参照してください。

注意: このダイアログ・ボックスで指定した値によって、`staticports.ini`ファイルに指定した値がオーバーライドされます。このため、`staticports.ini`ファイルには、Oracle HTTP Serverの`Listen`ポートのポート番号を指定しないでください。

#### 8.2.4.1 ケース1: クライアントとロード・バランサの通信にHTTPを使用し、ロード・バランサとOracle HTTP Serverの通信にもHTTPを使用する場合

このタイプの通信を設定するには、次の値を指定します。

HTTPリスナー: ポート: Oracle HTTP Serverの`Listen`ポートとして使用するポート番号を入力します。これは、`httpd.conf`ファイルの`Listen`ディレクティブの値になります。

SSL有効: このオプションは選択しないでください。インストーラでは、SSLポートとしてデフォルトのポート番号が使用されます。

HTTPロード・バランサ: ホスト名: HTTPリクエストを処理するようにロード・バランサに構成されている仮想サーバーの名前を入力します。

HTTPロード・バランサ: ポート: HTTP仮想サーバーがリスニングするポート番号を入力します。これは、`httpd.conf`ファイルの`Port`ディレクティブの値になります。

SSL有効: このオプションは選択しないでください。

表8-1に、画面および構成ファイルの値を示します。

表8-1 ケース1: 画面および構成ファイルの値

画面上の値 | 構成ファイルに指定される値
--- | ---
HTTPリスナー: ポート: 8000 SSL有効: 選択しない HTTPロード・バランサ: ポート: 80 SSL有効: 選択しない | `httpd.conf`内
    Port 80
    Listen 8000
`ssl.conf`内
    Port <default port number assigned by installer>
    Listen <default port number assigned by installer>

#### 8.2.4.2 ケース2: クライアントとロード・バランサの通信にHTTPSを使用し、ロード・バランサとOracle HTTP Serverの通信にもHTTPSを使用する場合

このタイプの通信を設定するには、次の値を指定します。

HTTPリスナー: ポート: Oracle HTTP Serverでリスニングするポート番号を入力します。これは、`ssl.conf`ファイルの`Listen`ディレクティブの値になります。

SSL有効: このオプションを選択します。

HTTPロード・バランサ: ホスト名: HTTPSリクエストを処理するようにロード・バランサに構成されている仮想サーバーの名前を入力します。

HTTPロード・バランサ: ポート: HTTP仮想サーバーがリスニングするポート番号を入力します。これは、`ssl.conf`ファイルの`Port`ディレクティブの値になります。

SSL有効: このオプションを選択します。

インストーラによって、`opmn.xml`のOracle HTTP Serverセクションにある`ssl-enabled`行が`true`に設定されます。

表8-2に、画面および構成ファイルで指定される値を示します。

表8-2 ケース2: 画面および構成ファイルの値

画面上の値 | 構成ファイルに指定される値
--- | ---
HTTPリスナー: ポート: 90 SSL有効: 選択する HTTPロード・バランサ: ポート: 443 SSL有効: 選択する | `httpd.conf`内
    Port <default port number assigned by installer>
    Listen <default port number assigned by installer>
`ssl.conf`内
    Port 443
    Listen 90

#### 8.2.4.3 ケース3: クライアントとロード・バランサの通信にHTTPSを使用し、ロード・バランサとOracle HTTP Serverの通信にはHTTPを使用する場合

このタイプの通信を設定するには、次の値を指定します。

HTTPリスナー: ポート: Oracle HTTP Serverでリスニングするポート番号を入力します。これは、`httpd.conf`ファイルの`Listen`ディレクティブの値になります。

SSL有効: このオプションは選択しないでください。

HTTPロード・バランサ: ホスト名: HTTPSリクエストを処理するようにロード・バランサに構成されている仮想サーバーの名前を入力します。

HTTPロード・バランサ: ポート: HTTP仮想サーバーがリスニングするポート番号を入力します。これは、`httpd.conf`ファイルの`Port`ディレクティブの値になります。

SSL有効: このオプションを選択します。

インストーラによって次の行が変更されます。

- インストーラによって、`opmn.xml`のOracle HTTP Serverセクションにある`ssl-enabled`行が`true`に設定されます。

- インストーラによって`httpd.conf`に次の行が追加されます。

      LoadModule certheaders_module libexec/mod_certheaders.so
      SimulateHttps on

表8-3に、画面および構成ファイルの値を示します。

表8-3 ケース3: 画面および構成ファイルの値

画面上の値 | 構成ファイルに指定される値
--- | ---
HTTPリスナー: ポート: 9000 SSL有効: 選択しない HTTPロード・バランサ: ポート: 443 SSL有効: 選択する | `httpd.conf`内
    Port 443
    Listen 9000
`ssl.conf`内
    Port <default port number assigned by installer>
    Listen <default port number assigned by installer>

## 8.3 高可用性環境でのOracle Calendar Serverのインストール

この項では、Oracle Calendar ServerをCold Failover構成にインストールする方法を説明します。

- 8.3.1項「Oracle Calendar Serverの高可用性構成」

- 8.3.2項「高可用性環境にOracle Calendar Serverをインストールするときのインストール前の手順」

### 8.3.1 Oracle Calendar Serverの高可用性構成

Oracle Collaboration Suite高可用性アーキテクチャでは、Oracle Calendar ServerにCold Failover Cluster構成を使用します。Cold Failover Cluster構成には、アクティブ・ノードとパッシブ・ノードがあり、いずれのノードからでもアクセスできる共有ストレージがあります。

通常操作時に、アクティブ・ノードでOracle Calendar Serverプロセスを実行し、クライアントからのリクエストを管理します。アクティブ・ノードに障害が発生した場合は、フェイルオーバー・イベントが発生します。パッシブ・ノードが処理を引き継いでアクティブ・ノードになります。パッシブ・ノードでは、共有ストレージをマウントしてプロセスが実行されます。

図8-4に、Oracle Calendar Serverの高可用性構成を示します。

図8-4 Oracle Calendar Serverの高可用性構成

「図8-4 Oracle Calendar Serverの高可用性構成」の説明

図8-4は次の内容を示しています。

- 2つのノードがクラスタウェアを実行しています。

- 各ノードにストレージ・デバイスが配置されています。

- 両方のノードからストレージ・デバイスにアクセスできます。

通常操作時は、1つのノード（ノード1）がアクティブ・ノードとして動作します。アクティブ・ノードは、共有ストレージをマウントしてOracle Calendar Serverにアクセスし、Oracle Calendar Serverプロセスを実行し、すべてのリクエストを処理します。

アクティブ・ノードがなんらかの理由で停止した場合は、クラスタウェアによってOracle Calendar Serverプロセスが他のノード（ノード2）にフェイルオーバーされ、ノード2がアクティブ・ノードになります。アクティブ・ノードになったノード2は、共有ストレージをマウントし、プロセスを実行し、すべてのリクエストを処理します。これは、クラスタウェアが自動的に検知してプロセス、VIPおよび共有ストレージをフェイルオーバーするようなパッケージがセットアップされている場合のみです。デフォルトのOCSのインストールでは、プロセス、VIPおよび共有ストレージを手動でフェイルオーバーする必要があります。

これらのノードは、仮想アドレスを使用することによって、クライアントに対して1台のコンピュータとして表示されます。アプリケーション層コンポーネントを含むクライアントがOracle Calendar Serverにアクセスするには、クラスタに関連付けられた仮想アドレスを使用します。仮想アドレスは、アクティブ・ノード（通常操作時はノード1、ノード1が停止した場合はノード2）に関連付けられます。クライアントは、いずれのノード（ノード1またはノード2）がリクエストを処理しているかを知る必要はありません。

仮想ホスト名は、Oracle Calendar ServerにアクセスするURLで使用します。たとえば、`vhost.mydomain.com`が仮想ホスト名である場合、Oracle HTTP ServerおよびApplication Server ControlのURLは、次のようになります。

次の項目のURL | URLの例
--- | ---
Oracle HTTP Serverの「ようこそ」ページ | `http://vhost.mydomain.com:7777`
セキュア・モードのOracle HTTP Server | `https://vhost.mydomain.com:4443`
Application Server Control | `http://vhost.mydomain.com:1156`

### 8.3.2 高可用性環境にOracle Calendar Serverをインストールするときのインストール前の手順

高可用性環境にOracle Calendar Serverをインストールする前に、次の作業を実行します。

- 8.3.2.1項「仮想ホスト名と仮想IPアドレスのマッピング」

- 8.3.2.2項「両方のノードからマウントできるファイル・システムの設定」

#### 8.3.2.1 仮想ホスト名と仮想IPアドレスのマッピング

Oracle Calendar Server Cold Failover Cluster構成の各ノードには、独自の物理インターネット・プロトコル（IP）アドレスが関連付けられています。また、クラスタ内のアクティブ・ノードには、仮想ホスト名および仮想IPアドレスが関連付けられています。これにより、クライアントは、仮想ホスト名を使用してCold Failover Clusterにアクセスできます。

仮想ホスト名および仮想IPアドレスは、ハードウェア・クラスタを含むサブネットのコンテキストでは任意の有効なホスト名およびIPアドレスです。

注意: 仮想ホスト名と仮想IPアドレスは、アクティブ・ノードにのみマッピングします。仮想ホスト名および仮想IPアドレスをアクティブ・ノードとセカンダリ・ノードの両方に同時にマッピングしないでください。現在のアクティブ・ノードでフェイルオーバーが発生した場合にのみ、セカンダリ・ノードからアクティブ・ノードになったノードに仮想ホスト名および仮想IPアドレスをマッピングします。

次の例では、`vhost.mydomain.com`という仮想ホスト名を`138.1.12.191`という仮想IPを使用して構成しています。

注意: この手順を実行する前に、システム管理者またはネットワーク管理者にすべての必要な手順を確認するように依頼してください。この手順を実行すると、クラスタ・ノードのネットワーク設定が再構成され、ネットワーク実装の違いによって手順が変わる場合があります。

1. 仮想ホスト名とIPアドレスを、ネットワークのDNSに登録します。

   たとえば、`vhost.mydomain.com`/`138.1.12.191`ペアをDNSに登録します。

2. アクティブ・ノードの`/etc/hosts`ファイルに次の行を追加します。

       ip_address hostname.domain hostname

   次に例を示します。

       138.1.12.191    vhost.mydomain.com    vhost

3. プライマリ・パブリック・ネットワーク・インタフェースを確認します。

   通常、AIXでイーサネットのカプセル化に使用するプライマリ・パブリック・ネットワーク・インタフェースは`eth0`です。ノードの物理ホスト名の値が`Address`であるプライマリ・パブリック・ネットワーク・インタフェースを確認するには、次のコマンドを使用します。

       /usr/bin/netstat -i

4. プライマリ・パブリック・ネットワーク・インタフェースに使用可能な索引番号を検索します。

   前の手順と同じコマンドを使用して、プライマリ・パブリック・ネットワーク・インタフェースへの追加IPアドレスに使用可能な索引番号を確認します。

   `/usr/bin/netstat -i`コマンドの出力が次のとおりで、前の手順で`en0`がプライマリ・パブリック・インタフェースと判別された場合、`en0:2`を追加IPアドレスとして使用できます。

       Name     Mtu     Network      Address            Ipkts     Opkts

       en0:1   1500    datacenter1  www2.mydomain.com  1050265   734793
       en1*    1500    none         none               0         0
       en0     1500    datacenter1  www1.mydomain.com  39783928  41833023
       eo0      4136    loopback     localhost          1226188   1226196

   索引番号として`0`は使用しないでください。通常、`interface``:0`は、ほとんどのシステムでインタフェースと同じになるためです。たとえば、AIXでは`en0:0`は`en0`と同じです。

5. `root`ユーザーとして、プライマリ・パブリック・ネットワーク・インタフェースに仮想IPアドレスを追加します。

   注意: このインタフェースのNETMASKおよびBROADCASTの値には、プライマリ・パブリック・ネットワーク・インタフェース（例では`en0`）に使用される値と同じ値を使用する必要があります。最後の`netmask`オプションおよび`broadcast`オプションが含まれるように、この手順の`ifconfig`コマンドを変更します。

   前の手順で確認した使用可能な索引番号を使用して、次のコマンドを入力します。

       /usr/sbin/ifconfig primary_public_interface ip_address alias up

   たとえば、`en0:2`が使用可能な場合、次のコマンドを入力します。

       /usr/sbin/ifconfig en0:2 138.1.12.191 alias up

6. 仮想IPアドレスが正しく構成されていることを確認します。

   1. 手順3に記載されている方法を使用して、手順5で作成した`primary_public_interface:available_index`エントリの新規エントリを確認します。

   2. 仮想ホスト名および仮想IPアドレスを使用して、他のノードからノードに接続します。たとえば、異なるノードから次のコマンドを両方入力すると、この手順で構成したノードにログインできます。

          telnet hostname.domain
          telnet ip_address

      たとえば、次のように入力します。

          telnet vhost.mydomain.com
          telnet 138.1.12.191

フェイルオーバー時

アクティブ・ノードに障害が発生した場合は、セカンダリ・ノードが処理を引き継ぎます。クラスタウェア・エージェントを使用して障害が発生したノードからセカンダリ・ノードに仮想IPをマッピングしない場合は、手動でマッピングする必要があります。障害が発生したノードから仮想IPのマッピングを削除し、セカンダリ・ノードにマッピングします。

1. 障害が発生したノードで、`root`ユーザーとして仮想IPアドレスを削除します。次のコマンドを入力します。

       /usr/sbin/ifconfig configured_interface delete ip_address

   たとえば、仮想IPアドレスに`en0:1`が構成されている場合、次のコマンドを入力します。

       /usr/sbin/ifconfig en0 delete 138.1.12.191

   注意: 仮想IPアドレスが削除されたことを確認するには、前述の手順の手順3でのコマンドを使用します。

2. セカンダリ・ノードで、仮想IPアドレスを追加します。

   セカンダリ・ノードでは、前述の手順の手順2〜6に従って、セカンダリ・ノードに仮想IPアドレスを追加し、確認します。

#### 8.3.2.2 両方のノードからマウントできるファイル・システムの設定

ハードウェア・クラスタには共有ストレージがある場合でも、この共有ストレージにファイル・システムを作成し、Oracle Calendar Server Cold Failover Clusterの両方のノードがこのファイル・システムをマウントできるようにする必要があります。このファイル・システムは、次のディレクトリ用に使用します。

- インフラストラクチャのOracleホーム・ディレクトリ

- `oraInventory`ディレクトリ

ディスク領域要件の詳細は、2.1項を参照してください。

共有ストレージを管理するためにクラスタでボリューム・マネージャを実行する場合は、ボリューム・マネージャのドキュメントでボリュームを作成する手順を参照してください。ボリュームを作成した後、そのボリュームにファイル・システムを作成できます。

ボリューム・マネージャがない場合は、共有ディスクに直接ファイル・システムを作成できます。ハードウェア・ベンダーでこの方法がサポートされていることを確認します。また、Oracle Calendar Server Cold Failover Clusterのいずれのノードからでもファイル・システムをマウントできること、ノードに障害が発生したときにいずれのノードからでもファイル・システムを修復可能であることを確認します。

いずれのノードからでもファイル・システムをマウントできることを確認するには、次の手順を実行します。

1. ノード1からファイル・システムを設定し、マウントします。

2. ノード1からファイル・システムをアンマウントします。

3. 手順1と同じマウント・ポイントを使用して、ノード2からファイル・システムをマウントします。

4. ノード2からそのファイル・システムをアンマウントし、ノード1にマウントします。これは、ノード1からインストーラを実行するためです。

注意: Oracle Calendar Server Cold Failover Clusterでファイル・システムをマウントするノードは、常に1つのみである必要があります。クラスタのすべてのノードのファイル・システム構成ファイルには、ノード再起動時またはグローバル・マウント・コマンドの実行時にファイル・システムを自動マウントするエントリが含まれないようにする必要があります。たとえば、UNIXプラットフォームでは、`/etc/fstab`ファイルにこのファイル・システムのエントリを含めないでください。