Sun Cluster Support for Oracle Real Application Clusters のインストールと構成の計画に入る前に、以下の各質問に答えてください。『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「構成のワークシート」にあるデータサービスワークシートのスペースに、質問の答えを記入してください。
Oracle 10g を使用している場合は、Oracle RAC サーバーリソースは必要ありません。これらのリソースが Oracle 10g で必要でないのは、Oracle CRS が Oracle Real Application Clusters データベースインスタンスの起動と停止を行うためです。10g よりも前のバージョンの Oracle では、Sun Cluster でデータベースインスタンスの起動と停止を行えるように、これらのリソースが必要です。
Oracle Real Application Clusters (RAC) サーバーリソースのリソースグループとしてどれを使いますか。
Oracle Real Application Clusters データベースインスタンスごとに 1 つのリソースグループが必要です。そのリソースグループには、そのデータベースインスタンスの Oracle RAC サーバーリソースが含まれています。
この質問の回答は、「Oracle RAC サーバーリソースの登録と構成」の手順を実行する際に使用されます。
Oracle 10g を使用している場合は、Oracle リスナーリソースは必要ありません。これらのリソースが Oracle 10g で必要でないのは、Oracle CRS が Oracle Real Application Clusters データベースインスタンスの起動と停止を行うためです。10g よりも前のバージョンの Oracle では、Sun Cluster でデータベースインスタンスの起動と停止を行えるように、これらのリソースが必要です。
Oracle リスナーリソースのリソースグループとしてどれを使いますか。
この質問の回答は、「Oracle リスナーリソースの登録と構成」の手順を実行する際に使用されます。
リソースグループは、Real Application Clusters データベースインスタンスに対して Oracle リスナーがどのように構成されているかによって異なります。Real Application Clusters インスタンスに対して構成できるリスナーについては、Oracle のマニュアルを参照してください。次の各項で構成の例を説明します。
1 つのリスナーが 1 つの Real Application Clusters インスタンスだけをサポートします。このリスナーは、ノードの特定のインターネットプロトコル (IP) アドレスで待機します。リスナーをフェイルオーバーすることはできません。
この例では、リスナー リソースを次のように構成します。
リスナーリソースと RAC サーバーリソースを同じリソースグループに構成します。
このリソースグループは、1 つのノードだけでマスターされるようにします。
1 つのリスナーが、同じノードで動作するいくつかの Real Application Clusters インスタンスをサポートします。このリスナーは、Oracle の透過的なアプリケーションフェイルオーバー (TAF) と負荷均衡機能を使って、クライアント接続をすべての Real Application Clusters インスタンスに分散します。リスナーをフェイルオーバーすることはできません。
この例では、リスナー リソースを次のように構成します。
リスナーリソースをそれ独自のリソースグループ内に構成します。
このリスナーのリソースグループは、1 つのノードだけでマスターされるようにします。
リスナーのリソースグループと RAC サーバーのリソースグループとの間の依存関係を設定します。
フェイルオーバー可能な 1 つのリスナーが、同じノードで動作するいくつかの Real Application Clusters インスタンスをサポートします。リスナーが別のノードにフェイルオーバーされた場合でも、このリスナーは、ほかのノードで動作するいくつかの Real Application Clusters インスタンスをサポートします。
このリスナーは、Oracle の TAF と負荷均衡機能を使ってクライアント接続をすべての Real Application Clusters インスタンスに分散します。迅速にエラーを検出し、フェイルオーバー時間を短くするため、リスナーは LogicalHostname リソースにより表されるアドレス上で待機します。
この例では、リスナー リソースを次のように構成します。
同じリソースグループでリスナーリソースと LogicalHostname リソースを構成します。
このリソースグループは、Oracle Real Application Clusters が動作しているノードだけでマスターされるようにします。
詳細は、「Oracle リスナーリソース用の LogicalHostname リソース」を参照してください。
1 つのリスナーが、すべてのノードのすべての Real Application Clusters インスタンスをサポートします。このリスナーは、LogicalHostname リソースで表されるアドレスで待機します。この構成では、あるノードに障害が発生すると、そのアドレスがすぐに別のノードに渡されます。
マルチスレッドサーバー (MTS) を使用するように Real Application Clusters インスタンスを構成する場合は、この構成を使用できます。このような構成においては、init.ora ファイルの REMOTE_LISTENERS パラメータが、各ディスパッチャーが論理 IP アドレスのリスナーに登録されるように指定します。
すべてのクライアントが 1 つのリスナーを通して接続されます。リスナーは、各クライアント接続を最も負荷の軽いディスパッチャに切り替えます。最も負荷の軽いディスパッチャは、リスナーとは別のノード上にある可能性があります。
リスナーに異常が発生すると、リスナーの障害モニターがリスナーを再起動します。リスナーが動作しているノードに異常が発生すると、リスナーは別のノードで再起動されます。どちらの場合でも、ディスパッチャはリスナーが再起動された後に再登録されます。
クラスタ全体に対して 1 つのリスナーを使用している場合は、次のリソースを同じリソースグループとして構成する必要があります。
リスナーリソース
LogicalHostname リソース
詳細は、「Oracle リスナーリソース用の LogicalHostname リソース」を参照してください。
Oracle 10g を使用している場合は、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 メタデータサーバーごとに 1 つのリソースが必要です。
これらのリソースのためにどのリソースグループを使用しますか。
データベースファイルと関連ファイル用に複数のファイルシステムを使用する場合があります。詳細は、「SPARC: Sun StorEdge QFS 共有ファイルシステムを使用する場合の要件」を参照してください。
Oracle 10g を使用している場合は、Oracle CRS が Real Application Clusters データベースインスタンスを管理します。すべての共有ファイルシステムがマウントされたあとでのみ、これらのデータベースインスタンスを起動する必要があります。この要件を満たすには、そのほかのデータベースファイル用のファイルシステムがマウントされた後でのみ、Oracle CRS 投票ディスクが含まれるファイルシステムがマウントされるようにします。このような動作により、ノードがブートした場合、すべての Sun StorEdge QFS ファイルシステムがマウントされたあとでのみ Oracle CRS が起動します。
Sun Cluster で必要な順序でファイルシステムをマウントできるようにするには、次のように、ファイルシステムのメタデータサーバー用のリソースグループを構成します。
別のリソースグループでメタデータサーバー用のリソースを作成します。
Oracle CRS 投票ディスクを含むファイルシステムのリソースグループを、ほかのリソースグループに依存するよう設定します。
詳細は、Sun StorEdge QFS の以下のマニュアルを参照してください。
『Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide』
Sun StorEdge QFS and Sun StorEdge SAM-FS File System Administration Guide
これらの質問の回答は、「Oracle RAC サーバーリソースの登録と構成」の手順を実行する際に使用されます。
scrgadm ユーティリティーを使用して RAC フレームワークリソースグループを作成する計画である場合、このリソースグループにはどのような名前を割り当てますか。
scsetup ユーティリティーを使用して RAC フレームワークリソースグループを作成する場合は、この質問は省略してください。scsetup ユーティリティーは、リソースグループを作成するときに自動的に名前を割り当てます。
詳細は、「RAC フレームワークリソースグループの登録と構成」を参照してください。
クラスタファイルシステムの代わりにローカルファイルシステムを使用する場合のメリットとデメリットについては、「Oracle バイナリファイルおよび Oracle 構成ファイルのストレージ管理要件」を参照してください。