| Oracle Collaboration Suiteインストレーション・ガイド 10gリリース1（10.1.2） for HP-UX PA-RISC（64-bit） B25913-02 |
|
 戻る |
 次へ |
| Oracle Collaboration Suiteインストレーション・ガイド 10gリリース1（10.1.2） for HP-UX PA-RISC（64-bit） B25913-02 |
|
戻る |
次へ |
この章の内容は次のとおりです。
この項では、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.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アドレス。
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サービスにリクエストをルーティングするロード・バランサ
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アドレス。
この層には、Oracle Calendar Serverを除くOracle Collaboration Suiteアプリケーションのすべてのコンポーネントが含まれています。Oracle Calendar Serverは、複数のノードに別にインストールします。通常、アプリケーション層は非武装地帯（DMZ）に配置します。DMZはイントラネットとインターネットの間にあるネットワークの一部で、中立地帯とも呼ばれます。これにより、イントラネット内のホストの特定のサービスのみが、インターネット上のホストからアクセスできるようになります。このサブネットワークは特に、Webサーバーなどのパブリック・アクセス・サーバーに対して使用されます。ロード・バランサ仮想サーバーは、複数のアプリケーション層のフロントエンドを構成します。Oracle Collaboration Suite 10gアプリケーション層へのクライアント・リクエストに対し、アプリケーション・ノード全体でロード・バランサ仮想サーバーを使用したロード・バランシングが実行されます。
Oracleホームは、ハードウェア・クラスタの各ノードにインストールされます。すべてのOracleホームは、各ノードにある単一の共有oraInventoryを使用します。
アプリケーション層のハードウェア要件は、次のとおりです。
単一ノード
ローカル・ストレージ
Oracle Collaboration Suiteアプリケーション層ノードのフロントエンドとして機能し、リクエストをバランシングしてクラスタのアクティブ・ノードにルーティングするロード・バランサ
この項では、高可用性構成の特長と、Oracle Collaboration Suiteでサポートされている標準の高可用性構成の概要について説明します。構成の詳細は、『Oracle Collaboration Suite高可用性ガイド』を参照してください。
Oracle Collaboration Suiteでは、次の高可用性構成がサポートされています。
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層およびアプリケーション層に対するリクエストは、ロード・バランサの仮想サーバー名およびポートを経由してルーティングされます。
すべての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は、一般的な単一クラスタ・アーキテクチャ構成を示しています。
単一クラスタ・アーキテクチャのインストールの詳細は、第9章を参照してください。
このアーキテクチャは個別の層を複数のコンピュータに分割します。すべての層のノードを単一クラスタ・アーキテクチャで共有するのではなく、ハードウェア・クラスタ依存層や、ハードウェア・クラスタ上の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アーキテクチャ構成
同じ場所に配置されたIdentity Managementアーキテクチャのインストールの詳細は、第9章を参照してください。
この構成は、同じ場所に配置された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アーキテクチャ構成を示しています。
分散Identity Managementアーキテクチャのインストールの詳細は、第9章を参照してください。
すべての高可用性構成では、次の順序でコンポーネントをインストールします。
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 Calendar Server
Oracle Collaboration Suiteアプリケーション・コンポーネント
高可用性環境に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を選択した場合は、後続のインストールでも同じコンポーネントを選択する必要があります。
各インストールで異なるコンポーネントを選択した場合、クラスタ化は失敗します。
すべての高可用性構成に共通の要件は、次のとおりです。
これらの共通要件以外に、各構成にはそれぞれ固有の要件があります。詳細は、個々の章を参照してください。
クラスタ内の各ノードが、許可されたクラスタウェアを実行している必要があります。
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項を参照してください。
詳細は、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ディレクトリが存在していることを確認します。
この項の内容は次のとおりです。
OracleAS Metadata RepositoryデータベースにASMインスタンスを使用する場合は、次の推奨事項を考慮してください。
同じノードの複数のデータベース・ホームからOracleデータベース・インスタンスとともにASMを使用する場合は、データベース・ホームとは異なるOracleホームからASMインスタンスを実行する必要があります。
ASMホームは、すべてのクラスタ・ノードにインストールする必要があります。これにより、データベースのOracleホームを削除するときに、データベースで使用中のASMインスタンスを他のホームから誤って削除することを防止できます。
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を設定します。
詳細は、ロード・バランサのドキュメントを参照してください。
複数の中間層デプロイでは、複数のCalendar同期サーバー層が存在します。このため、この情報を格納する一元管理されたストレージの場所を各中間層が指し示す必要があります。このようにしないと、時間のかかる完全同期化が不必要に何回も行われることになります。
詳細は、『Oracle Collaboration Suiteデプロイメント・ガイド』の同期化情報のOracle Mobile Data Sync層およびストレージに関する項を参照してください。
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を使用する場合。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ポートのポート番号を指定しないでください。 |
このタイプの通信を設定するには、次の値を指定します。
HTTPリスナー: ポート: Oracle HTTP ServerのListenポートとして使用するポート番号を入力します。これは、httpd.confファイルのListenディレクティブの値になります。
SSL有効: このオプションは選択しないでください。インストーラでは、SSLポートとしてデフォルトのポート番号が使用されます。
HTTPロード・バランサ: ホスト名: HTTPリクエストを処理するようにロード・バランサに構成されている仮想サーバーの名前を入力します。
HTTPロード・バランサ: ポート: HTTP仮想サーバーがリスニングするポート番号を入力します。これは、httpd.confファイルのPortディレクティブの値になります。
SSL有効: このオプションは選択しないでください。
表8-1に、画面および構成ファイルの値を示します。
このタイプの通信を設定するには、次の値を指定します。
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に、画面および構成ファイルで指定される値を示します。
このタイプの通信を設定するには、次の値を指定します。
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に、画面および構成ファイルの値を示します。
この項では、Oracle Calendar ServerをCold Failover構成にインストールする方法を説明します。
Oracle Collaboration Suite高可用性アーキテクチャでは、Oracle Calendar ServerにCold Failover Cluster構成を使用します。Cold Failover Cluster構成には、アクティブ・ノードとパッシブ・ノードがあり、いずれのノードからでもアクセスできる共有ストレージがあります。
通常操作時に、アクティブ・ノードで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 |
高可用性環境にOracle Calendar Serverをインストールする前に、次の作業を実行します。
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_indexip_address
たとえば、lan0:2が使用可能な場合、次のコマンドを入力します。
/usr/sbin/ifconfig lan0:2 138.1.12.191
仮想IPアドレスが正しく構成されていることを確認します。
手順3に記載されている方法を使用して、手順5で作成したprimary_public_interface:available_indexエントリの新規エントリを確認します。
仮想ホスト名および仮想IPアドレスを使用して、他のノードからノードに接続します。たとえば、異なるノードから次のコマンドを両方入力すると、この手順で構成したノードにログインできます。
telnethostname.domaintelnetip_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 Server Cold Failover Clusterのいずれのノードからでもファイル・システムをマウントできること、ノードに障害が発生したときにいずれのノードからでもファイル・システムを修復可能であることを確認します。
いずれのノードからでもファイル・システムをマウントできることを確認するには、次の手順を実行します。
ノード1からファイル・システムを設定し、マウントします。
ノード1からファイル・システムをアンマウントします。
手順1と同じマウント・ポイントを使用して、ノード2からファイル・システムをマウントします。
ノード2からそのファイル・システムをアンマウントし、ノード1にマウントします。これは、ノード1からインストーラを実行するためです。
