ヘッダーをスキップ
Oracle Collaboration Suiteインストレーション・ガイド
10gリリース1(10.1.1)for HP-UX PA-RISC(64-bit)
B25362-01
  目次
目次
索引
索引

戻る
戻る
次へ
次へ
 

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

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

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

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

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

10.1.1 高可用性の一般原則の理解

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

10.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です。

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

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

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

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

  • ベンダーのクラスタウェアまたはOracle Cluster Ready Services(あるいはその両方)をインストールしたハードウェア・クラスタ。

  • Oracle Real Application Clustersのデータベース・ファイルとCRSのレジストリおよびquorumデバイス用の共有ストレージ。Oracle Databaseファイルは、RAWデバイス、ネットワーク接続ストレージ(NAS)、OCFS for Linuxに格納できます。または、Oracle自動ストレージ管理(ASM)を使用できます。

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

10.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層のハードウェア要件は、次のとおりです。

  • 単一ノード

  • ローカル・ストレージ

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

10.1.1.3 Oracle Calendar

Oracle Calendarには、すべてのCalendar関連データを格納するファイル・システム・レベルのデータベースが含まれています。このデータベースはOracle Databaseではありません。したがって、Oracle Databaseと同じ高可用性機能は提供されません。

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

OracleホームとoraInventoryは、ハードウェア・クラスタの専用の共有ストレージに配置します。このOracleホームには、他のコンポーネントのOracleホームとは別のoraInventoryを使用します。これにより、共有ファイル・システムのフェイルオーバーが発生した場合は、同じマウント・ポイントを使用してoraInventoryもフェイルオーバーされます。

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

  • ベンダーのクラスタウェアをインストールしたハードウェア・クラスタ。Linuxの場合、Oracle Cluster Ready ServicesとRed Hat Cluster Managerは共存できません。このため、フェイルオーバーを手動で行うか、またはOracle CalendarをOracle Real Application Clustersデータベースとは別のクラスタに配置する必要があります。

  • Calendar ServerのORACLE_HOMEおよびoraInventoryディレクトリ用の共有ストレージ。

  • 仮想IPアドレス。

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

この層には、Oracle Calendarを除くOracle Collaboration Suiteアプリケーションのすべてのコンポーネントが含まれています。Oracle Calendarは、複数のノードに別にインストールします。通常、アプリケーション層は非武装地帯(DMZ)に配置します。ロード・バランサ仮想サーバーは、複数のアプリケーション層のフロントエンドを構成します。Oracle Collaboration Suite 10gアプリケーション層へのクライアント・リクエストに対し、アプリケーション・ノード全体でロード・バランサ仮想サーバーを使用したロード・バランシングが実行されます。

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

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

  • 単一ノード

  • ローカル・ストレージ

  • ロード・バランサ仮想サーバー

10.1.2 高可用性構成の概要

この項では、Oracle Collaboration Suiteでサポートされている一般的な高可用性構成の概要について説明します。構成の詳細は、『Oracle Collaboration Suiteデプロイメント・ガイド』を参照してください。

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

各高可用性構成の相違点については、10.1.2.4項を参照してください。

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

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

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

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

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

  • 共有ディスク: 通常、Oracle Collaboration Suiteは共有ディスクにインストールします。すべてのノードから共有ディスクにアクセスできますが、共有ディスクをマウントするノードは常に1つのみです。ただし、Oracle Collaboration Suiteデータベースは、共有ディスクにはインストールせず、常にいずれか1つのノードによってマウントされます。また、Oracle Real Application Clustersデータベースを実行しているすべてのノードから共有ディスクへの同時アクセスが可能である必要があります。

  • ハードウェア・クラスタ。これはベンダー固有のクラスタウェアまたはOracle Cluster Ready Services(あるいはその両方)です。

  • ロード・バランサ。すべてのアクティブ・ノードに対するリクエストのロード・バランシングを実行するには、ロード・バランサが必要です。ロード・バランサを必要とするのは、Identity Managementおよびアプリケーション関連のリクエストのみです。アプリケーション層に対するリクエストは、仮想IPアドレスを経由してルーティングされます。Oracle Real Application Clusterデータベースに対するリクエストは、Oracle Netを経由し、クラスタ・ノードの仮想IPアドレスを使用してルーティングされます。

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

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

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

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

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

このアーキテクチャでは、単一クラスタ・アーキテクチャのようにノードが共有されるのではなく、Oracle Collaboration Suiteデータベース層とIdentity Management層が分離されます。このアーキテクチャはデフォルトのソリューションではありません。Oracle Collaboration Suiteを複数回インストールし、インストール後の構成を手動で実行する必要があります。

同じ場所に配置されたIdentity Managementアーキテクチャは、高可用性構成でIdentity Managementコンポーネントをインストールするために使用します。

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

同じ場所に配置されたIdentity Managementアーキテクチャ構成の特徴は、次のとおりです。

  • アクティブ・ノード: アクティブ・ノードがすべてのリクエストを処理します。アクティブ・ノードに障害が発生した場合は、パッシブ・ノードがアクティブ・ノードになります。1つのノードに障害が発生した場合は、残りのノードがすべてのリクエストを処理します。

  • 共有ディスク: 通常、Oracle Collaboration Suiteは共有ディスクにインストールします。すべてのノードから共有ディスクにアクセスできますが、共有ディスクをマウントするノードは常に1つのみです。ただし、Oracle Collaboration Suiteデータベースは、共有ディスクにはインストールせず、常にいずれか1つのノードによってマウントされます。また、Oracle Real Application Clustersデータベースを実行しているすべてのノードから共有ディスクへの同時アクセスが可能である必要があります。

  • ハードウェア・クラスタ。これはベンダー固有のクラスタウェア、またはOracle Real Application Clustersを使用する場合はOracle Cluster Ready Servicesのいずれかです。

  • ロード・バランサ。ハードウェア・ロード・バランサは、Identity Management層を配置したノードのフロントエンドであり、Identity Managementのトラフィックのロード・バランシングを実行します。

  • 非クラスタ・サーバー。Identity Management層には複数の非クラスタ・サーバーが必要です。

  • 仮想IPおよび仮想ホスト名: ノード用の仮想IPと仮想ホスト名を設定する必要があります。仮想ホスト名はインストール時に指定します。Active Failover Cluster構成では、クライアントからOracle Collaboration Suiteへのアクセスに仮想ホスト名が使用されます(たとえば、URLで使用されます)。仮想IPおよび仮想ホスト名は、アクティブ・ノードを指します。アクティブ・ノードに障害が発生した場合、仮想IPおよび仮想ホスト名は、他のアクティブ・ノードを指すように切り替えられます。

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

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

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

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

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

この構成は、同じ場所に配置されたIdentity Managementアーキテクチャと類似していますが、Identity Managementコンポーネント、Oracle Internet DirectoryおよびOracle Application Server Single Sign-Onを非武装地帯の複数の非クラスタ・サーバーに分散する点が異なります。

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

分散Identity Managementアーキテクチャ構成の特徴は、次のとおりです。

  • アクティブ・ノード: アクティブ・ノードがすべてのリクエストを処理します。

  • 共有ディスク: 通常、Oracle Collaboration Suiteは共有ディスクにインストールします。アクティブ・ノードおよびパッシブ・ノードが共有ディスクにアクセスできますが、共有ディスクをマウントするノードは常に1つ(アクティブ・ノード)のみです。

  • ハードウェア・クラスタ。これはベンダー固有のクラスタウェア、またはOracle Real Application Clustersを使用する場合はOracle Cluster Ready Servicesのいずれかです。

  • ロード・バランサ。すべてのアクティブ・ノードに対するリクエストのロード・バランシングを実行するには、ロード・バランサが必要です。インストール時に、ロード・バランサに構成される仮想サーバー名を入力します。実行時に、クライアントからOracleAS Cluster(Identity Management)構成へのアクセスに仮想サーバー名が使用されます。ロード・バランサによって、適切なノードにリクエストが送信されます。

  • 非クラスタ・サーバー。Oracle Internet DirectoryおよびOracle Application Server Single Sign-Onの両方に使用する複数の非クラスタ・サーバーが必要です。

  • 仮想IPおよび仮想ホスト名: ノード用の仮想IPと仮想ホスト名を設定する必要があります。仮想ホスト名はインストール時に指定します。Active Failover Cluster構成では、クライアントからOracle Collaboration Suiteへのアクセスに仮想ホスト名が使用されます(たとえば、URLで使用されます)。仮想IPおよび仮想ホスト名は、アクティブ・ノードを指します。アクティブ・ノードに障害が発生した場合、仮想IPおよび仮想ホスト名は、他のアクティブ・ノードを指すように切り替えられます。

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

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

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

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

10.1.2.4 相違点の要約

表10-1に、各高可用性構成の相違点を示します。

表10-1 各高可用性構成の相違点


単一クラスタ・アーキテクチャ 同じ場所に配置されたIdentity Managementアーキテクチャ 分散Identity Managementアーキテクチャ

ノード構成

アクティブ-アクティブ

アクティブ-アクティブ

アクティブ-アクティブ

ハードウェア・クラスタ

あり

あり

あり

仮想ホスト名

なし

あり

あり

ロード・バランサ

あり

あり

あり

共有ストレージ

あり

あり

あり

非クラスタ・サーバー

なし

あり(Identity Management層で使用)

あり


10.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 Collaboration Suiteアプリケーション・コンポーネント

10.1.4 高可用性構成の要件

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

  • データベースの要件

    既存のOracle Real Application Clustersデータベースが必要です。メタデータ・リポジトリ作成アシスタントを使用して、このデータベースにOracleAS Metadata Repositoryをインストールします。

  • OracleAS Metadata Repositoryの要件

    最初のノードでインストールを実行する場合は、どのOracle Internet Directoryにも登録されていないOracleAS Metadata Repositoryを1つ指定する必要があります。この指定は、インストーラによってチェックされます。OracleAS Metadata RepositoryがすでにOracle Internet Directoryに登録されていることがインストーラで確認された場合は、インストールが2番目以降のノードに対して行われており、最初のノードにインストールしたときに作成されたクラスタを追加しようとしているとみなされます。そのため、既存のクラスタ名とOracle Internet Directoryの接続情報を入力するように求められます。

  • コンポーネントの要件

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

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

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

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

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


注意:

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

10.1.4.1 ノードの最小数の確認

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

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

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

HP-UXでのHP Serviceguardのチェック

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

# /usr/sbin/cmviewcl

このコマンドの出力ではクラスタが表示され、クラスタのステータスがupであることが示されます。クラスタ内の各ノードも表示されます。次の例では、2つのノードを含むクラスタのステータスを示します。

CLUSTER      STATUS
iAS_Cluster  up

   NODE         STATUS       STATE        GMS_STATE
   oappsvr1     up           running      halted
   oappsvr2     up           running      halted

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

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

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

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

Oracle Collaboration Suiteをインストールするときのログイン名とする必要のあるoracleオペレーティング・システム・ユーザーに、次の特性があることを確認します。

  • oinstallグループとosdbaグループに属していること。oinstallグループはoraInventoryディレクトリ用であり、osdbaグループはデータベース管理グループです。詳細は、2.6項を参照してください。

  • リモート・ディレクトリに対する書き込み権限があること。

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

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

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

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

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

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

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

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

    # su
    Password: root_password
    # /var/opt
    # mv oracle oracle.orig
    
    

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

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

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

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

10.2.1 インストール前の手順

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

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

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

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

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

10.2.1.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を実行するノードから、これらの仮想サーバー名にアクセスできる必要があります。

10.2.1.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仮想サーバーに追加します。

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

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

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

10.2.2 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へのログイン時に必要です。

10.2.3 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を使用する場合。10.2.3.1項を参照してください。

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

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


注意:

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

10.2.3.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有効: このオプションは選択しないでください。

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

表10-2 ケース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>

10.2.3.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に設定されます。

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

表10-3 ケース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

10.2.3.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
    
    

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

表10-4 ケース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>

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

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

10.3.1 Oracle Calendarの高可用性構成

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

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

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

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

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

Cold Failover Clusterでは、クラスタ内の各ノードでハードウェア・ベンダーのクラスタウェアが実行されている必要があります。Oracle Cluster Ready Servicesを実行する場合も、ハードウェア・ベンダーのクラスタウェアが必要です。Cold Failover Clusterでは、ハードウェア・ベンダーのクラスタウェアを使用しないでOracle Cluster Ready Servicesを実行することはできません。

クラスタウェアが実行されていることを確認するには、クラスタウェアの該当するコマンドを使用します。

10.3.2.2 仮想ホスト名と仮想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. プライマリ・パブリック・ネットワーク・インタフェースを確認します。

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

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

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

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

    Name     Mtu     Network      Address            Ipkts     Opkts
    
    lan0:1   1500    datacenter1  www2.mydomain.com  1050265   734793
    lan1*    1500    none         none               0         0
    lan0     1500    datacenter1  www1.mydomain.com  39783928  41833023
    lo0      4136    loopback     localhost          1226188   1226196
    
    

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

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


    注意:

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

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

    /usr/sbin/ifconfig primary_public_interface:available_index ip_address
    
    

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

    /usr/sbin/ifconfig lan0:2 138.1.12.191
    
    
  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のマッピングを削除し、セカンダリ・ノードにマッピングします。


注意:

障害が発生したノードがオフラインの場合または再起動された場合は、このノードには仮想ホスト名または仮想IPアドレスが構成されていないため、最初の手順は不要です。

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

    /usr/sbin/ifconfig configured_interface down
    
    

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

    /usr/sbin/ifconfig lan0:2 down
    
    

    注意:

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

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

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

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

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

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

  • oraInventoryディレクトリ

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

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

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

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

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

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

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

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


注意:

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

10.3.2.4 自動ストレージ管理(ASM)に関する推奨事項の確認

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

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

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

10.3.3 Oracle Calendarのインストール

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

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

図10-4の説明は次を参照
「図10-4 Oracle Calendarの高可用性構成」の説明

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

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

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

  • 両方のノードからストレージ・デバイスにアクセスできます。この共有ストレージ・デバイスにインフラストラクチャをインストールします。

通常操作時は、1つのノード(ノード1)がアクティブ・ノードとして動作します。アクティブ・ノードは、共有ストレージをマウントしてインフラストラクチャにアクセスし、Oracle Collaboration Suite 10gインフラストラクチャ・プロセスを実行し、すべてのリクエストを処理します。

アクティブ・ノードがなんらかの理由で停止した場合は、クラスタウェアによってOracle Collaboration Suiteインフラストラクチャ・プロセスが他のノード(ノード2)にフェイルオーバーされ、ノード2がアクティブ・ノードになります。アクティブ・ノードになったノード2は、共有ストレージをマウントし、プロセスを実行し、すべてのリクエストを処理します。

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

仮想ホスト名は、インフラストラクチャにアクセスする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

Oracle Application Server Cold Failover Cluster構成にOracle Calendarをインストールするには、次の項目で説明する手順を実行します。

10.3.3.1 Oracle Calendar ServerのCold Failover Cluster構成へのインストール

Oracle CalendarをCold Failover Cluster構成にインストールする前に、仮想IPアドレスとホスト名がインストール・ノードで有効になっていることを確認します。

Oracle CalendarをCold Failover Cluster構成にインストールするには、表10-5の手順を実行します。

表10-5 Oracle Calendar ServerのCold Failover Cluster構成へのインストール

手順 画面 操作

1.

なし

インストーラを起動します。3.4「Oracle Universal Installerの起動」を参照してください。

2.

インストール方法の選択

「拡張インストール」を選択します。

注意: 基本インストールおよび拡張インストールの詳細は、1.7項を参照してください。

「次へ」をクリックします。

3.

インベントリ・ディレクトリと資格証明の指定

(拡張インストールのみ)

この画面は、コンピュータに最初にOracle製品をインストールする場合にのみ表示されます。

インベントリ・ディレクトリのフルパスを入力してください: インストーラのファイルのディレクトリのフルパスを入力します。製品ファイルのOracleホーム・ディレクトリ以外のディレクトリを入力します。

例: /private/oracle/oraInventory

「OK」をクリックします。

4.

UNIXグループ名

(拡張インストールのみ)

この画面は、コンピュータに最初にOracle製品をインストールする場合にのみ表示されます。

インベントリ・ディレクトリの書込み権限を付与するオペレーティング・システム・グループを入力します。

例: dba

「次へ」をクリックします。

5.

orainstRoot.shの実行

(拡張インストールのみ)

この画面は、コンピュータに最初にOracle製品をインストールする場合にのみ表示されます。

別のシェルでrootユーザーとしてorainstRoot.shスクリプトを実行します。このスクリプトは、oraInventoryディレクトリにあります。

「続行」をクリックします。

6.

ファイルの場所の指定

(拡張インストールのみ)

必要に応じて、ソース・ディレクトリのフルパスを「ソース」の「パス」フィールドに入力します。

名前: このOracleホームを識別する名前を入力します。名前は最大16文字で、空白を使用することはできません。

例: OH_apptier_10_1_1

インストール先パス: インストール先のディレクトリのフルパスを入力します。これがOracleホームです。ディレクトリが存在しない場合は、インストーラによって作成されます。ディレクトリをあらかじめ作成する場合は、rootユーザーとして作成するのではなく、oracleユーザーとして作成します。

例: /private/oracle/OH_apptier_10_1_1

「次へ」をクリックします。

7.

ハードウェアのクラスタ・インストール・モードの指定

(拡張インストールのみ)

この画面は、コンピュータがハードウェア・クラスタの一部である場合にのみ表示されます。

Oracle Collaboration Suiteアプリケーションをインストールしている場合、ハードウェア・クラスタはOracle Collaboration Suiteアプリケーションに対してサポートされていないため、「ローカル・インストール」を選択します。

「次へ」をクリックします。

8.

インストールする製品の選択

(拡張インストールのみ)

「Oracle Collaboration Suiteアプリケーション」を選択して、Oracle Collaboration Suiteアプリケーションをインストールします。

追加の言語をインストールする必要がある場合は、「製品の言語」をクリックします。詳細は、1.8項を参照してください。

「次へ」をクリックします。

9.

構成するコンポーネントの選択

(拡張インストールのみ)

インストール時に構成するコンポーネントを選択します。インストールの最後に選択したコンポーネントが自動的に起動されます。

注意: インストール後でも、任意のコンポーネントを構成できます。詳細は、8.7項を参照してください。

「次へ」をクリックします。

10.

Oracle Internet Directoryへの登録

(拡張インストールのみ)

ホスト: Oracle Internet Directoryが実行されるコンピュータの名前を入力します。

ポート: Oracle Internet Directoryがリスニングするポート番号を入力します。ポート番号が不明な場合は、8.5項を参照してください。

SSLを使用してOracle Internet Directoryに接続: Oracle Collaboration SuiteのコンポーネントでSSLのみを使用してOracle Internet Directoryに接続する場合は、このオプションを選択します。

「次へ」をクリックします。

11.

Oracle Internet Directoryのユーザー名およびパスワードの指定

(拡張インストールのみ)

ユーザー名: Oracle Internet Directoryにログインするためのユーザー名を入力します。

パスワード: ユーザーのパスワードを入力します。

「次へ」をクリックします。

注意: Oracle Internet Directoryスーパーユーザーの場合は、ユーザー名にcn=orcladminを使用します。

12.

OracleAS Metadata Repository

(拡張インストールのみ)

データベース接続文字列: このアプリケーション層インスタンスに使用するOracleAS Metadata Repositoryを選択します。インストーラによって、選択したOracleAS Metadata Repositoryにこのインスタンスが登録されます。

「次へ」をクリックします。

13.

コンポーネント用のデータベースの選択

(拡張インストールのみ)

この画面には、「構成するコンポーネントの選択」画面で選択した各コンポーネントに対して使用されるデータベースが表示されます。

「次へ」をクリックします。

注意: Oracle Collaboration Suiteデータベースの複数のインスタンスがOracle Internet Directoryで使用可能になっている場合は、「データベース名」列をクリックし、各コンポーネントに対して適切なデータベースをドロップダウン・リストから選択します。ただし、「次へ」をクリックして次の画面に移動すると、選択内容が保持されないことがあります。選択内容を保持するには、各コンポーネントで必要なデータベースを選択してから、「データベース名」列をもう一度クリックする必要があります。

14.

ポート構成オプションの指定

(拡張インストールのみ)

Oracle Collaboration Suite用ポートの構成方法を選択します。

「次へ」をクリックします。

注意: 手動でポートを構成する場合、ポートごとにポートの値を指定する必要があります。

15.

管理パスワードおよびインスタンス名の指定

(拡張インストールのみ)

インスタンス名: Oracle Collaboration Suite管理アカウントのOracleASインスタンスの名前を指定します。

管理パスワード: Oracle Collaboration Suite管理アカウントの初期パスワードを指定します。

パスワードの確認: パスワードを確認します。

「次へ」をクリックします。

16.

Oracle Calendar Serverホストのエイリアス

(拡張インストールのみ)

ホストまたはエイリアス: Calendar Serverインスタンスのホスト・アドレスまたは別名を指定します。

「次へ」をクリックします。

注意: 後でCalendar Serverインスタンスを移動したり、ホスト名を変更する場合は、ホスト名のかわりに別名を使用することをお薦めします。別名が構成されていない場合は、ホスト名を指定します。

17.

サマリー

選択内容を確認し、「インストール」をクリックします。

18.

インストールの進捗状況

この画面には、インストールの進捗状況が表示されます。

19.

root.shの実行

注意: このダイアログ・ボックスが表示されるまで、root.shスクリプトは実行しないでください。

  1. このダイアログが表示されたら、rootユーザーとして別のシェルでroot.shスクリプトを実行します。スクリプトは、このインスタンスのOracleホーム・ディレクトリにあります。

  2. 「OK」をクリックします。

20.

コンフィギュレーション・アシスタント

この画面には、コンフィギュレーション・アシスタントの進捗状況が表示されます。コンフィギュレーション・アシスタントによって、コンポーネントが構成されます。

21.

インストールの終了

「終了」をクリックしてインストーラを終了します。


10.3.3.2 インストール後の手順の実行

次の問題に対しては、インストール後の手順を実行する必要があります。

root.shスクリプト実行中のchmodの警告

root.shスクリプトの実行中に、chmod:の警告が表示される場合があります。この警告は、対応するset-IDemtgtctl2で無効にされているために表示されます。これは、set-IDexecute権限を必要とするためです。

警告を無視してインストール・プロセスを続行してください。

10.3.3.3 Oracle Collaboration Suiteアプリケーションのインストール

他のノード(インフラストラクチャを実行していないノード)にアプリケーション層をインストールして実行できます。インストール時に、共有ストレージ・デバイスにインストールされたOracle Collaboration Suite 10gインフラストラクチャからサービスを使用するようにアプリケーション層を設定します。