| Oracle Collaboration Suite高可用性構成 リリース2（9.0.4）for UNIX Systems 部品番号: B15729-01 |
|
 戻る |
 次へ |
この章では、Oracle Collaboration Suiteの配置における高可用性構成の概要について説明します。ここでは、次の内容について説明します。
図2-1に、Oracle Collaboration Suiteの配置における高可用性構成の例を示します。このドキュメントの残りの部分では、この構成例を使用して、高可用性配置を実現する手順について説明します。
このドキュメントでは、Oracleドメイン名oracle.comを例として使用します。必要に応じて、Oracleドメイン名を組織のドメイン名に変更する必要があります。
InfrastructureデータベースおよびOracle Internet Directoryコンポーネントは、イントラネット上の2ノード（ハードウェア、アクティブ/パッシブ）のコールド・フェイルオーバー・クラスタに配置されます。これらのコンポーネントがインストールされるノードには、仮想ホスト名があります。図2-1では、この仮想ホスト名はinfrahaです。InfrastructureデータベースおよびOracle Internet Directory層は、『Oracle9i Application Server Infrastructure: Improved Availability with Hardware Clusters』に説明されている手順を使用して設定します。このドキュメントでは、Oracle9i Application Server Cold Failover Clustersリリース9.0.2のSolarisへの実装が説明されています。次のURLでアクセスできます。
http://otn.oracle.co.jp/products/9ias/index.html
この設定では、1つのノードはアクティブ、もう1つのノードはパッシブです。パッシブ・ノードとは、オペレーティング・システムは稼働していても、Oracleアプリケーションは起動されていないノードです。Oracleホーム・ディレクトリは1つで、データベースのデータ・ファイルとともに共有ディスク・システム上に存在します。フェイルオーバーが必要な場合は、データベース・インスタンスとOracle Internet Directoryプロセスが、残存するノードにフェイルオーバーします。InfrastructureデータベースとOracle Internet Directoryのパッシブ・ノードは、Oracle Calendar ServerとOracle Filesドメイン・コントローラのアクティブ・ノードです。このノードには、固有の仮想ホスト名があります。
両方のノードが使用可能なときは、1つのノードがInfrastructureおよびOracle Internet Directoryコンポーネントでアクティブになり、もう1つのノードがOracle Calendar ServerおよびOracle Filesドメイン・コントローラ・コンポーネントでアクティブになります。一方のノードに障害が発生すると、他方のノードでInfrastructure、Oracle Internet Directory、Oracle Calendar ServerおよびOracle Filesドメイン・コントローラが実行されます。この残存するノードに、2つの仮想ホスト名が割り当てられます。
Oracle Calendar Serverにコールド・フェイルオーバーを設定するには、Oracle Calendar ServerおよびOracle Filesドメイン・コントローラ・コンポーネントをインストールするときに、Infrastructureに使用したものと同じ設定を使用します。Infrastructureと同様、1つのOracleホームが共有ディスク・システム上に存在します。Oracle Calendar Serverデータベースは、Oracleホーム・ディレクトリ・ツリー上にあるため、フェイルオーバーの発生時には、残存するノードからアクセス可能です。
通常モードでは、Oracle Calendar ServerおよびOracle Filesドメイン・コントローラ層は、Infrastructureと同じクラスタの、他方のノードで実行されます。図2-1では、Infrastructureが、仮想ホスト名infrahaを使用してinfra1で実行される場合、Oracle Calendar ServerおよびOracle Filesドメイン・コントローラは、仮想ホスト名caldchaを使用してinfra2で実行されます。この設計によって、クラスタの両方のノードが最適に使用されます。フェイルオーバーの発生時に、Oracle Calendar Server、Oracle Filesドメイン・コントローラ、InfrastructureおよびOracle Internet Directoryを同時に処理するのに必要なリソースを各ノードで確保する必要があります。フェイルオーバーが発生した場合は、両方の仮想ホスト名infrahaおよびcaldchaが、残存するノードに割り当てられます。Oracle Filesドメイン・コントローラ・プロセスは、Oracle Filesドメインを構成するノードを制御および管理します。
この場合、Oracle Filesドメイン・コントローラを中間層ノードに配置することもできます。
Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Service層をインストールするには、Infrastructureに、単一ノードのOracle Identity Managementのみのインストールを実行する必要があります。インストール時に、インストールするコンポーネントとして、Oracle9iAS Single Sign-OnとOracle Delegated Administration Serviceのみを選択します。通常、この層は非武装地帯（DMZ）にインストールされます。
可用性を確保するために、この層には最低2つのサーバーがあります。通常、これらのサーバーは、ハードウェア・クラスタの一部ではありません。どのサーバーにも、Oracle Delegated Administration ServiceおよびOracle9iAS Single Sign-Onサービスが用意されているため、機能的には同等です。1つのサーバーに障害が発生した場合は、他のサーバーで、引き続きサービスを使用できます。
この構成では、ロード・バランサの仮想サーバーが、Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Service層のフロントエンドになります。中間層またはエンドユーザーから、Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceへは、このOracle9iAS Single Sign-Onロード・バランシング・サーバーの仮想サーバー名を介してアクセスされます。これは、図2-1ではssolbです。この図では、Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceの受信HTTPトラフィックは、サーバーssomt1およびssomt2間で分散されます。
Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceコンポーネントを個別のノードに配置するかわりに、次の配置方法も選択できます。
Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceコンポーネントの中間層への配置
このような配置では、Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceコンポーネントは、個別のノードではなく、DMZ内の中間層コンポーネントと同じノードに配置されます。これによって、必要なサーバー数は半分に減ります。Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceコンポーネントが組織全体で使用される場合、中間層アプリケーションと組み合せることによって、なんらかの機能停止時に、企業のOracle9iAS Single Sign-Onの可用性が損なわれる場合があります。したがって、これは高可用性にとって最適な配置ではありません。
Oracle9iAS Single Sign-OnおよびOracle Delegated Administration ServiceコンポーネントのInfrastructure層への配置
このような配置では、Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceコンポーネントは、イントラネット上に配置されます。インターネット・アクセス用の構成が必要になります。
|
参照: Oracle9iAS Single Sign-OnおよびOracle Delegated Administration Serviceコンポーネントのインターネット・アクセスのための構成の詳細は、MetaLink Note No.255976.1を参照してください。 |
通常、Information Storage層は、イントラネット上のファイアウォールの後ろに配置されます。この層は、Oracle Real Application Clustersを使用します。デフォルトのインストールによって、Oracle Net接続時フェイルオーバーとインスタンス間の登録も設定されます。設定の詳細は、tnsnames.oraおよびlistener.oraファイルに記述されます。これらのファイルは、$ORACLE_HOME/network/adminディレクトリにあります。
|
参照: 『Oracle9i Net Services管理者ガイド』、『Oracle9i Real Application Clusters管理』 |
通常、中間層はDMZ内に配置されます。図2-1の設定では、ホストocsmt1およびocsmt2が中間層に対して使用されます。ロード・バランサの仮想サーバーocslbが、両方の中間層のフロント・エンドになります。
この層には、Oracle Calendar ServerとOracle Filesドメイン・コントローラを除く、すべてのOracle Collaboration Suiteアプリケーション・コンポーネントが格納されています。前述のとおり、これら2つのコンポーネントは、イントラネット上の独自の層に常駐します。この層は、サービス名strを使用して、Information Storageデータベースに接続します。
Oracle Collaboration Suiteのネットワーク計画は、Oracle Collaboration Suite高可用性ソリューションを設定する手順の主要な要素です。このようなソリューションに対する基本的な特徴は、適切に計画されたネットワークです。このネットワークでは、ピーク時のネットワーク・トラフィックに対応する十分な帯域幅と、ネットワークの可用性を向上させるネットワーク代替パスを備えています。
|
参照: 『Network Planning for Oracle Collaboration Suite』。次のURLでアクセスできます。 |
分散コールド・フェイルオーバー・クラスタの場合、通常のインストールでは、DMZ内のOracle9iAS Single Sign-OnおよびOracle Delegated Administration Service層にサーバーおよびロード・バランサが配置され、イントラネットにInfrastructureデータベースおよびOracle Internet Directory層が配置されます。このドキュメントで説明するインストールは、このような配置を使用しています。配置によっては、コンポーネントを分離するファイアウォールがない場合もあります。
ロード・バランサを使用すると、1つのサーバーの障害が重大なリソースの損失につながることを防止できます。1つのサーバーに障害が発生した場合、ロード・バランサは新しいリクエストを他のサーバーにルーティングします。また、シングル・ポイント障害の発生を防ぐために、ロード・バランサは冗長ペアで配置する必要があります。このドキュメントで説明する環境では、ロード・バランサ・ペア用にF5 BIG-IP Load Balancer Limitedが使用されます。
|
参照: ファイアウォールとロード・バランサの使用については、次のURLの『Oracle9i Application Server: Firewall and Load Balancer Architectures』を参照してください。
|
