Sun Cluster Data Service for Oracle Real Application Clusters ガイド (Solaris OS 版)

インストール前の考慮事項

Oracle Real Application Clusters は、複数のノードで同時に動作することができる、拡張性をもつアプリケーションです。Sun Cluster Support for Oracle Real Application Clusters は、Oracle Real Application Clusters を Sun Cluster ノードで実行できるようにするパッケージ群です。さらに、このデータサービスでは、Sun Cluster コマンドを使って Oracle Real Application Clusters を管理できます。


注 –

Oracle の以前のバージョンでは、このアプリケーションは 「Oracle Parallel Server」 と呼ばれていました。本書では、特に断りがない限り、「Oracle Real Application Clusters」 への言及は Oracle Parallel Server にも適用されるものとします。


このデータサービスには障害監視機能がありますが、この機能は、Sun Cluster ユーティリティで Oracle Real Application Clusters リソースの状態を監視できるようにするためだけのものです。このデータサービスには、Oracle Real Application Clusters ソフトウェアに自動障害回復機能と同様の機能があるため、自動障害回復機能はありません。

ハードウェアとソフトウェアの要件

インストールを始める前に、以下に説明するハードウェアとソフトウェアの要件に注意してください。

Sun Cluster フレームワーク要件

Sun Cluster Support for Oracle Real Application Clusters をインストールするためには、クラスタに最初のクラスタフレームワークがすでにインストールされ、クラスタが動作している必要があります。クラスタソフトウェアの初期インストールの詳細については、『Sun Cluster ソフトウェアのインストール (Solaris OS 版) 』を参照してください。

Oracle Real Application Clusters データベースのストレージ管理要件

Sun Cluster ソフトウェアの共有ディスクアーキテクチャを使用するためには、Oracle Real Application Clusters を構成する必要があります。この構成では、データベースに同時にアクセスする Oracle Real Application Clusters の複数のインスタンス間で、単一のデータベースを共有します。クラスタノード間の共有リソースに対するアクセスは、UNIX Distributed Lock Manager (Oracle UDLM) によって制御されます。

これらの要件を満たすために、以下のストレージ管理スキームのどれかを使用します。

ソフトウェアライセンス要件

ソフトウェアを使用するために必要なライセンスを取得して、インストールしているかを確認します。ライセンスのインストールが不正であったり不完全であったりすると、ノードが正しく起動しないことがあります。

たとえば、クラスタ機能を備えた VxVM を使用している場合、以下のコマンドのうちの 1 つを実行して、 Volume Manager クラスタ機能のライセンスをインストールしてあることを確認してください。

サポートされているトポロジ要件

Sun Enterprise Services の購入先に、 Sun Cluster Support for Oracle Real Application Clusters で現在サポートされているトポロジー、クラスタインターコネクト、ストレージ管理スキーマ、およびハードウェア構成について確認します。

パッチのインストール要件

Solaris オペレーティングシステム、Sun Cluster、Oracle、および使用するボリュームマネージャ用の適用できるソフトウェアパッチをインストールしてあることを確認します。Sun Cluster Support for Oracle Real Application Clusters パッチをインストールする必要がある場合は、データサービスパッケージをインストールしたあとでこれらのパッチを加えてください。

Oracle バイナリファイルと Oracle 構成ファイルの場所

Oracle バイナリファイルおよび Oracle 構成ファイルは、次のいずれかの場所にインストールできます。

Oracle バイナリファイルと Oracle 構成ファイルにローカルディスクを使用する場合

Oracle バイナリファイルと Oracle 構成ファイルを個別のクラスタノード上に置くと、後でデータサービスをシャットダウンせずに Oracle アプリケーションをアップグレードできます。

この場合の短所は、Oracle バイナリファイルと Oracle 構成ファイルの複数のコピーを維持し、管理しなければならない点です。

Oracle バイナリファイルと Oracle 構成ファイルに共有ファイルシステムを使用する場合

Oracle システムの保守を簡単にするために、Oracle バイナリファイルと Oracle 構成ファイルを共有ファイルシステムにインストールできます。次の共有ファイルシステムがサポートされています。

Oracle バイナリファイルと Oracle 構成ファイルを共有ファイルシステム上に置く場合、維持管理するコピーは 1 つだけです。しかし、Oracle アプリケーションをアップグレードするには、クラスタ全体でデータサービスを停止する必要があります。アップグレードする場合に多少の停止時間が生じても構わない場合は、Oracle バイナリファイルと Oracle 構成ファイルの 1 つのコピーを共有ファイルシステム上に置きます。

Sun StorEdge QFS 共有ファイルシステムを使用する場合の要件

Oracle Real Application Clusters に関連するすべてのファイルを Sun StorEdge QFS 共有ファイルシステムに格納できます。

次に示すように、これらのファイルをいくつかのファイルシステムに分散して置きます。

Sun StorEdge QFS 共有ファイルシステムの作成方法については、Sun StorEdge QFS の次のマニュアルを参照してください。

クラスタファイルシステムを使用するための要件

クラスタファイルシステムには、Oracle Real Application Clusters に関連する次のファイルだけを格納できます。


注 –

クラスタファイルシステムに、データファイル、コントロールファイル、オンラインの再実行ログファイルを格納しないでください。


保存された再実行ログファイルに書き込む際の入出力性能は、保存された再実行ログファイルのデバイスグループがどこにあるかによって異なります。パフォーマンスを最適にするために、保存された再実行ログファイル用のプライマリのデバイスグループは、Oracle Real Application Clusters データベースインスタンスと同じノード上に置くようにしてください。このデバイスグループには、データベースインスタンスの保存された再実行ログを保持するファイルシステムが含まれています。

クラスタファイルシステムの作成方法については、以下のマニュアルを参照してください。

構成計画に関する質問

Sun Cluster Support for Oracle Real Application Clusters のインストールと構成の計画に入る前に、以下の各質問に答えてください。『Sun Cluster 3.1 データサービスの計画と管理』の「構成ワークシート」にあるデータサービスワークシートのスペースに、質問の答えを記入してください。

Oracle RAC サーバーリソースのリソースグループ

Oracle Real Application Clusters (RAC) サーバーリソースのリソースグループとしてどれを使いますか。

Oracle Real Application Clusters データベースインスタンスごとに 1 つのリソースグループが必要です。そのリソースグループには、そのデータベースインスタンスの Oracle RAC サーバーリソースが含まれています。

この質問の回答は、「Oracle RAC サーバーリソースの登録と構成」の手順を実行する際に使用されます。

Oracle リスナーリソースのリソースグループ

Oracle リスナーリソースのリソースグループとしてどれを使いますか。

この質問の回答は、「Oracle リスナーリソースの登録と構成」の手順を実行する際に使用されます。

リソースグループは、Real Application Clusters データベースインスタンスに対して Oracle リスナーがどのように構成されているかによって異なります。Real Application Clusters インスタンスに対して構成できるリスナーについては、Oracle のマニュアルを参照してください。次の各項で構成の例を説明します。

1 つの Real Application Clusters インスタンスに 1 つのリスナー

1 つのリスナーが 1 つの Real Application Clusters インスタンスだけをサポートします。このリスナーは、ノードの特定のインターネットプロトコル (IP) アドレスで待機します。リスナーをフェイルオーバーすることはできません。

この例では、リスナー リソースを次のように構成します。

いくつかの Real Application Clusters インスタンスに 1 つのリスナー (フェイルオーバー不可)

1 つのリスナーが、同じノードで動作するいくつかの Real Application Clusters インスタンスをサポートします。このリスナーは、Oracle の透過的なアプリケーションフェイルオーバー (TAF) と負荷均衡機能を使って、クライアント接続をすべての Real Application Clusters インスタンスに分散します。リスナーをフェイルオーバーすることはできません。

この例では、リスナーリソースを次のように構成します。

いくつかの Real Application Clusters インスタンスに 1 つリスナー (フェイルオーバー可能)

フェイルオーバー可能な 1 つのリスナーが、同じノードで動作するいくつかの Real Application Clusters インスタンスをサポートします。リスナーが別のノードにフェイルオーバーされた場合でも、このリスナーは、ほかのノードで動作するいくつかの Real Application Clusters インスタンスをサポートします。

このリスナーは、Oracle の TAF と負荷均衡機能を使ってクライアント接続をすべての Real Application Clusters インスタンスに分散します。エラー検出やフェイルオーバーを短時間で行なうために、リスナーは、LogicalHostname リソースで表されるアドレスで待機します。

この例では、リスナー リソースを次のように構成します。

詳細は、「Oracle リスナーリソース用の LogicalHostname リソース」を参照してください。

クラスタ全体に 1 つのリスナー

1 つのリスナーが、すべてのノードのすべての Real Application Clusters インスタンスをサポートします。このリスナーは、LogicalHostname リソースで表されるアドレスで待機します。この構成では、あるノードに障害が発生すると、そのアドレスがすぐに別のノードに渡されます。

マルチスレッドサーバー (MTS) を使用するように Real Application Clusters インスタンスを構成する場合は、この構成を使用できます。このような構成においては、init.ora ファイルの REMOTE_LISTENERS パラメータを使って、各ディスパッチャがロジカル IP アドレスのリスナーに登録されるように指定します。

すべてのクライアントが 1 つのリスナーを通して接続されます。リスナーは、各クライアント接続を最も負荷の軽いディスパッチャに切り替えます。最も負荷の軽いディスパッチャは、リスナーとは別のノード上にある可能性があります。

リスナーに異常が発生すると、リスナーの障害モニターがリスナーを再起動します。リスナーが動作しているノードに異常が発生すると、リスナーは別のノードで再起動されます。どちらの場合でも、ディスパッチャはリスナーが再起動された後に再登録されます。

クラスタ全体に対して 1 つのリスナーを使用している場合は、次のリソースを同じリソースグループとして構成する必要があります。

詳細は、「Oracle リスナーリソース用の LogicalHostname リソース」を参照してください。

Oracle リスナーリソース用の LogicalHostname リソース

Oracle リスナーリソースではどの LogicalHostname リソースを使用しますか。

この質問の回答は、「Oracle リスナーリソースの登録と構成」の手順を実行する際に使用されます。

Oracle Real Application Clusters のインスタンスを実行しているクラスタノードに異常がある場合には、クライアントアプリケーションが行おうとしている操作を、別のインスタンスで再試行される前にタイムアウトにする必要がある場合があります。TCP/IP ネットワークのタイムアウトが頻繁に起きる場合、クライアントアプリケーションで障害を検出するのに長時間かかることがあります。通常、クライアントアプリケーションでこの種の障害を検出するのに必要な時間は、3 分から 9 分です。

このような状況の場合、クライアントアプリケーションは、Sun Cluster LogicalHostname リソースで表されるアドレスで待機しているリスナーリソースに接続できます。そのためには、LogicalHostname リソースとリスナーリソースを別々のリソースグループとして構成する必要があります。このリソースグループは、Oracle Real Application Clusters が動作しているノードだけでマスターされるようにします。ノードに異常があると、LogicalHostname リソースとリスナーリソースが含まれているリソースグループは、Oracle Real Application Clusters が動作している有効な別のノード にフェイルオーバーされます。 LogicalHostname リソースのフェイルオーバーにより、新しい接続を Oracle Real Application Clusters の他のインスタンスにつなげることができます。

Sun StorEdge QFS 共有ファイルシステムのリソース

Sun StorEdge QFS 共有ファイルシステムを使用する場合は、次の質問に答えてください。

詳細は、Sun StorEdge QFS の以下のマニュアルを参照してください。

この質問の回答は、「Oracle RAC サーバーリソースの登録と構成」の手順を実行する際に使用されます。

システム構成ファイルの場所

システム構成ファイルをどこに置きますか。

クラスタファイルシステムの代わりにローカルファイルシステムを使用する場合の長所と短所については、「Oracle バイナリファイルと Oracle 構成ファイルの場所」を参照してください。