Oracle Collaboration Suiteインストレーション・ガイド 10gリリース1(10.1.1)for HP-UX PA-RISC(64-bit) B25362-01 |
|
![]() 戻る |
![]() 次へ |
この章の内容は次のとおりです。
この項では、Oracle Collaboration Suiteでサポートされている高可用性構成の概要について説明します。
この項の内容は次のとおりです。
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アドレス。
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サービスにリクエストをルーティングするロード・バランサ
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アドレス。
この層には、Oracle Calendarを除くOracle Collaboration Suiteアプリケーションのすべてのコンポーネントが含まれています。Oracle Calendarは、複数のノードに別にインストールします。通常、アプリケーション層は非武装地帯(DMZ)に配置します。ロード・バランサ仮想サーバーは、複数のアプリケーション層のフロントエンドを構成します。Oracle Collaboration Suite 10gアプリケーション層へのクライアント・リクエストに対し、アプリケーション・ノード全体でロード・バランサ仮想サーバーを使用したロード・バランシングが実行されます。
Oracleホームは、ハードウェア・クラスタの各ノードにインストールされます。すべてのOracleホームは、各ノードにある単一の共有oraInventory
を使用します。
アプリケーション層のハードウェア要件は、次のとおりです。
単一ノード
ローカル・ストレージ
ロード・バランサ仮想サーバー
この項では、Oracle Collaboration Suiteでサポートされている一般的な高可用性構成の概要について説明します。構成の詳細は、『Oracle Collaboration Suiteデプロイメント・ガイド』を参照してください。
Oracle Collaboration Suiteでは、次の高可用性構成がサポートされています。
各高可用性構成の相違点については、10.1.2.4項を参照してください。
すべての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は、一般的な単一クラスタ・アーキテクチャ構成を示しています。
単一クラスタ・アーキテクチャのインストールの詳細は、第11章を参照してください。
このアーキテクチャでは、単一クラスタ・アーキテクチャのようにノードが共有されるのではなく、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アーキテクチャのインストールの詳細は、第12章を参照してください。
この構成は、同じ場所に配置された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アーキテクチャ構成を示しています。
分散Identity Managementアーキテクチャのインストールの詳細は、第13章を参照してください。
すべての高可用性構成では、次の順序でコンポーネントをインストールします。
Oracle Collaboration Suiteデータベース
Identity Managementコンポーネント
Identity Managementコンポーネントを分散する場合は、次の順序でインストールします。
Oracle Internet DirectoryおよびOracle Directory Integration and Provisioning
Oracle Application Server Single Sign-OnおよびOracle Delegated Administration Services
Oracle Collaboration Suiteアプリケーション・コンポーネント
高可用性環境に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を選択した場合は、後続のインストールでも同じコンポーネントを選択する必要があります。
各インストールで異なるコンポーネントを選択した場合、クラスタ化は失敗します。
すべての高可用性構成に共通の要件は、次のとおりです。
これらの共通要件以外に、各構成にはそれぞれ固有の要件があります。詳細は、個々の章を参照してください。
クラスタ内の各ノードが、許可されたクラスタウェアを実行している必要があります。
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
クラスタ内のすべてのノードの/etc/group
ファイルに、使用するオペレーティング・システム・グループが含まれていることを確認します。oraInventory
ディレクトリ用に1つ、データベース管理用に1つまたは2つのグループが必要です。グループ名とグループIDは、すべてのノードで同じである必要があります。
詳細は、2.6項を参照してください。
Oracle Collaboration Suiteをインストールするときのログイン名とする必要のあるoracle
オペレーティング・システム・ユーザーに、次の特性があることを確認します。
oinstall
グループとosdba
グループに属していること。oinstall
グループはoraInventory
ディレクトリ用であり、osdba
グループはデータベース管理グループです。詳細は、2.6項を参照してください。
リモート・ディレクトリに対する書き込み権限があること。
高可用性構成のOracle Collaboration Suiteをインストールするすべてのノードに、既存のoraInventory
ディレクトリが存在しないことを確認します。
この確認は、インストーラでoraInventory
ディレクトリの場所の入力が求められるようにするために行います。既存のoraInventoryディレクトリの場所は、インストールしようとしているOracle Collaboration Suiteインスタンスに最適とはかぎりません。たとえば、oraInventory
ディレクトリを共有ストレージ上に設定します。インストーラで既存のoraInventory
ディレクトリが検出された場合は、自動的にそのディレクトリが使用され、場所の入力は求められません。
インストーラで検出されるoraInventory
ディレクトリがノードにあるかどうかを確認するには、次の手順を実行します。
各ノードで、/var/opt/oracle/oraInst.loc
ファイルの有無を確認します。
ノードにこのファイルが含まれていない場合、そのノードにはインストーラが使用するoraInventory
ディレクトリはありません。次のノードの確認に移ることができます。
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
ディレクトリが存在していることを確認します。
この項の内容は次のとおりです。
Identity Management構成をインストールする前に、次のタスクを設定する必要があります。
Identity Managementコンポーネントを実行するすべてのノードで、Oracleホームに同じフルパスを使用します。これは推奨ですが、必須ではありません。
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を実行するノードから、これらの仮想サーバー名にアクセスできる必要があります。
この手順は、ロード・バランサ上に構成されたLDAP仮想サーバーにのみ適用されることに注意してください。ロード・バランサ上に構成されたHTTP仮想サーバーには適用されません。
インストールを開始する前に、リクエストをノード1のみに送るようにLDAP仮想サーバーを構成します。1つのノードでのインストールを完了した後、そのノードを仮想サーバーに追加できます。
たとえば、3つのノードがある場合は、次の手順を実行します。
リクエストをノード1のみに送るようにLDAP仮想サーバーを構成します。
ノード1にIdentity Managementコンポーネントをインストールします。
ノード2にIdentity Managementコンポーネントをインストールします。
ノード2をLDAP仮想サーバーに追加します。
ノード3にIdentity Managementコンポーネントをインストールします。
ノード3をLDAP仮想サーバーに追加します。
ロード・バランサに、HTTPトラフィックに対するCookie永続性を設定します。具体的には、/oiddas/
で始まるURIに対するCookie永続性を設定します。これはOracle Delegated Administration ServicesのURIです。ロード・バランサにURIレベルのCookie永続性を設定できない場合は、HTTPトラフィックに対するCookie永続性を設定します。いずれの場合も、ブラウザ・セッションが期限切れになった場合は失効するようにCookieを設定します。
詳細は、ロード・バランサのドキュメントを参照してください。
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へのログイン時に必要です。
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 ポートのポート番号を指定しないでください。
|
このタイプの通信を設定するには、次の値を指定します。
HTTPリスナー: ポート: Oracle HTTP ServerのListen
ポートとして使用するポート番号を入力します。これは、httpd.conf
ファイルのListen
ディレクティブの値になります。
SSL有効: このオプションは選択しないでください。インストーラでは、SSLポートとしてデフォルトのポート番号が使用されます。
HTTPロード・バランサ: ホスト名: HTTPリクエストを処理するようにロード・バランサに構成されている仮想サーバーの名前を入力します。
HTTPロード・バランサ: ポート: HTTP仮想サーバーがリスニングするポート番号を入力します。これは、httpd.conf
ファイルのPort
ディレクティブの値になります。
SSL有効: このオプションは選択しないでください。
表10-2に、画面および構成ファイルの値を示します。
このタイプの通信を設定するには、次の値を指定します。
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に、画面および構成ファイルで指定される値を示します。
このタイプの通信を設定するには、次の値を指定します。
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に、画面および構成ファイルの値を示します。
この項では、Oracle Calendar ServerをCold Failover構成にインストールする方法を説明します。
Oracle Collaboration Suite高可用性アーキテクチャでは、Oracle CalendarにCold Failover Cluster構成を使用します。Cold Failover Cluster構成には、アクティブ・ノードとパッシブ・ノードがあり、いずれのノードからでもアクセスできる共有ストレージがあります。
通常操作時に、アクティブ・ノードでOracle Calendar Serverプロセスを実行し、クライアントからのリクエストを管理します。アクティブ・ノードに障害が発生した場合は、フェイルオーバー・イベントが発生します。パッシブ・ノードが処理を引き継いでアクティブ・ノードになります。パッシブ・ノードでは、共有ストレージをマウントしてプロセスが実行されます。
高可用性環境にOracle Calendar Serverをインストールする前に、次の作業を実行します。
Cold Failover Clusterでは、クラスタ内の各ノードでハードウェア・ベンダーのクラスタウェアが実行されている必要があります。Oracle Cluster Ready Servicesを実行する場合も、ハードウェア・ベンダーのクラスタウェアが必要です。Cold Failover Clusterでは、ハードウェア・ベンダーのクラスタウェアを使用しないでOracle Cluster Ready Servicesを実行することはできません。
クラスタウェアが実行されていることを確認するには、クラスタウェアの該当するコマンドを使用します。
Oracle Calendar Server Cold Failover Cluster構成の各ノードには、独自の物理インターネット・プロトコル(IP)アドレスが関連付けられています。また、クラスタ内のアクティブ・ノードには、仮想ホスト名および仮想IPアドレスが関連付けられています。これにより、クライアントは、仮想ホスト名を使用してCold Failover Clusterにアクセスできます。
仮想ホスト名および仮想IPアドレスは、ハードウェア・クラスタを含むサブネットのコンテキストでは任意の有効なホスト名およびIPアドレスです。
注意: 仮想ホスト名と仮想IPアドレスは、アクティブ・ノードにのみマッピングします。仮想ホスト名および仮想IPアドレスをアクティブ・ノードとセカンダリ・ノードの両方に同時にマッピングしないでください。現在のアクティブ・ノードでフェイルオーバーが発生した場合にのみ、セカンダリ・ノードからアクティブ・ノードになったノードに仮想ホスト名および仮想IPアドレスをマッピングします。 |
次の例では、vhost.mydomain.com
という仮想ホスト名を138.1.12.191
という仮想IPを使用して構成しています。
注意: この手順を実行する前に、システム管理者またはネットワーク管理者にすべての必要な手順を確認するように依頼してください。この手順を実行すると、クラスタ・ノードのネットワーク設定が再構成され、ネットワーク実装の違いによって手順が変わる場合があります。 |
仮想ホスト名とIPアドレスを、ネットワークのDNSに登録します。
たとえば、vhost.mydomain.com
/138.1.12.191
ペアをDNSに登録します。
アクティブ・ノードの/etc/hosts
ファイルに次の行を追加します。
ip_address hostname.domain hostname
次に例を示します。
138.1.12.191 vhost.mydomain.com vhost
プライマリ・パブリック・ネットワーク・インタフェースを確認します。
通常、HP-UXでイーサネットのカプセル化に使用するプライマリ・パブリック・ネットワーク・インタフェースはlan0
です。ノードの物理ホスト名の値がAddress
であるプライマリ・パブリック・ネットワーク・インタフェースを確認するには、次のコマンドを使用します。
/usr/bin/netstat -i
プライマリ・パブリック・ネットワーク・インタフェースに使用可能な索引番号を検索します。
前の手順と同じコマンドを使用して、プライマリ・パブリック・ネットワーク・インタフェースへの追加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:0
はlan0
と同じです。
root
ユーザーとして、プライマリ・パブリック・ネットワーク・インタフェースに仮想IPアドレスを追加します。
注意: このインタフェースのNETMASKおよびBROADCASTの値には、プライマリ・パブリック・ネットワーク・インタフェース(例ではlan0 )に使用される値と同じ値を使用する必要があります。最後のnetmask オプションおよびbroadcast オプションが含まれるように、この手順の/usr/sbin/ifconfig コマンドを変更します。
|
前の手順で確認した使用可能な索引番号を使用して、次のコマンドを入力します。
/usr/sbin/ifconfigprimary_public_interface
:available_index
ip_address
たとえば、lan0:2
が使用可能な場合、次のコマンドを入力します。
/usr/sbin/ifconfig lan0:2 138.1.12.191
仮想IPアドレスが正しく構成されていることを確認します。
手順3に記載されている方法を使用して、手順5で作成したprimary_public_interface:available_index
エントリの新規エントリを確認します。
仮想ホスト名および仮想IPアドレスを使用して、他のノードからノードに接続します。たとえば、異なるノードから次のコマンドを両方入力すると、この手順で構成したノードにログインできます。
telnethostname.domain
telnetip_address
たとえば、次のように入力します。
telnet vhost.mydomain.com telnet 138.1.12.191
アクティブ・ノードに障害が発生した場合は、セカンダリ・ノードが処理を引き継ぎます。クラスタウェア・エージェントを使用して障害が発生したノードからセカンダリ・ノードに仮想IPをマッピングしない場合は、手動でマッピングする必要があります。障害が発生したノードから仮想IPのマッピングを削除し、セカンダリ・ノードにマッピングします。
注意: 障害が発生したノードがオフラインの場合または再起動された場合は、このノードには仮想ホスト名または仮想IPアドレスが構成されていないため、最初の手順は不要です。 |
障害が発生したノードで、root
ユーザーとして仮想IPアドレスを削除します。次のコマンドを入力します。
/usr/sbin/ifconfig configured_interface down
たとえば、仮想IPアドレスにlan0:2
が構成されている場合、次のコマンドを入力します。
/usr/sbin/ifconfig lan0:2 down
注意: 仮想IPアドレスが削除されたことを確認するには、前述の手順の手順3でのコマンドを使用します。 |
セカンダリ・ノードで、仮想IPアドレスを追加します。
セカンダリ・ノードでは、前述の手順の手順2〜6に従って、セカンダリ・ノードに仮想IPアドレスを追加し、確認します。
ハードウェア・クラスタには共有ストレージがある場合でも、この共有ストレージにファイル・システムを作成し、Oracle Calendar Server Cold Failover Clusterの両方のノードがこのファイル・システムをマウントできるようにする必要があります。このファイル・システムは、次のディレクトリ用に使用します。
インフラストラクチャのOracleホーム・ディレクトリ
oraInventory
ディレクトリ
ディスク領域要件の詳細は、2.1項を参照してください。
共有ストレージを管理するためにクラスタでボリューム・マネージャを実行する場合は、ボリューム・マネージャのドキュメントでボリュームを作成する手順を参照してください。ボリュームを作成した後、そのボリュームにファイル・システムを作成できます。
ボリューム・マネージャがない場合は、共有ディスクに直接ファイル・システムを作成できます。ハードウェア・ベンダーでこの方法がサポートされていることを確認します。また、Oracle Calendar Cold Failover Clusterのいずれのノードからでもファイル・システムをマウントできること、ノードに障害が発生したときにいずれのノードからでもファイル・システムを修復可能であることを確認します。
いずれのノードからでもファイル・システムをマウントできることを確認するには、次の手順を実行します。
ノード1からファイル・システムを設定し、マウントします。
ノード1からファイル・システムをアンマウントします。
手順1と同じマウント・ポイントを使用して、ノード2からファイル・システムをマウントします。
ノード2からそのファイル・システムをアンマウントし、ノード1にマウントします。これは、ノード1からインストーラを実行するためです。
OracleAS Metadata RepositoryデータベースにASMインスタンスを使用する場合は、次の推奨事項を考慮してください。
同じノードの複数のデータベース・ホームからOracleデータベース・インスタンスとともにASMを使用する場合は、データベース・ホームとは異なるOracleホームからASMインスタンスを実行する必要があります。
ASMホームは、すべてのクラスタ・ノードにインストールする必要があります。これにより、データベースのOracleホームを削除するときに、データベースで使用中のASMインスタンスを他のホームから誤って削除することを防止できます。
図10-4に、Oracle Calendar Serverの高可用性構成を示します。
図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をインストールするには、次の項目で説明する手順を実行します。
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ホーム・ディレクトリ以外のディレクトリを入力します。 例: 「OK」をクリックします。 |
4. |
UNIXグループ名 (拡張インストールのみ) |
この画面は、コンピュータに最初にOracle製品をインストールする場合にのみ表示されます。 インベントリ・ディレクトリの書込み権限を付与するオペレーティング・システム・グループを入力します。 例: 「次へ」をクリックします。 |
5. |
orainstRoot.shの実行 (拡張インストールのみ) |
この画面は、コンピュータに最初にOracle製品をインストールする場合にのみ表示されます。 別のシェルで 「続行」をクリックします。 |
6. |
ファイルの場所の指定 (拡張インストールのみ) |
必要に応じて、ソース・ディレクトリのフルパスを「ソース」の「パス」フィールドに入力します。 名前: このOracleホームを識別する名前を入力します。名前は最大16文字で、空白を使用することはできません。 例: インストール先パス: インストール先のディレクトリのフルパスを入力します。これがOracleホームです。ディレクトリが存在しない場合は、インストーラによって作成されます。ディレクトリをあらかじめ作成する場合は、 例: 「次へ」をクリックします。 |
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スーパーユーザーの場合は、ユーザー名に |
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の実行 |
注意: このダイアログ・ボックスが表示されるまで、
|
20. |
コンフィギュレーション・アシスタント |
この画面には、コンフィギュレーション・アシスタントの進捗状況が表示されます。コンフィギュレーション・アシスタントによって、コンポーネントが構成されます。 |
21. |
インストールの終了 |
「終了」をクリックしてインストーラを終了します。 |
次の問題に対しては、インストール後の手順を実行する必要があります。
root.sh
スクリプトの実行中に、chmod:
の警告が表示される場合があります。この警告は、対応するset-ID
がemtgtctl2
で無効にされているために表示されます。これは、set-ID
がexecute
権限を必要とするためです。
警告を無視してインストール・プロセスを続行してください。