ヘッダーをスキップ
Oracle Database高可用性ベスト・プラクティス
11gリリース1(11.1)
B54839-01
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

2.5 拡張クラスタでのOracle RACを使用したOracle Database 11gの構成

Oracle RACの拡張クラスタは、サイト障害からの非常に高速なリカバリを実現し、すべてのサイトのすべてのノードで単一のデータベース・クラスタの一部としてアクティブにトランザクションを処理できるアーキテクチャです。拡張クラスタでは、ローカルのOracle RACクラスタより高い可用性を得ることができますが、各サイトは通常同じ都市圏内に存在するため、このアーキテクチャでは組織の障害時リカバリ要件をすべて満たすことができない可能性があります。

この項に記載されているベスト・プラクティスは、拡張クラスタでのOracle RACを使用したOracle Database 11gに適用されるもので、2.4項「Oracle RACを使用したOracle Database 11gの構成」に説明されているベスト・プラクティスを基盤としています。

拡張クラスタ環境でOracle RACデータベースを構成する場合は、次のベスト・プラクティスを使用します。


関連項目:


2.5.1 拡張クラスタのサイトへのワークロードの均等な分散

典型的なOracle RACアーキテクチャは、主に単一のデータ・センターに存在するスケーラビリティおよび可用性ソリューションとして設計されています。Oracle RACの拡張クラスタを構成およびデプロイするには、クラスタの各ノードを遠く離して配置します。拡張クラスタ環境でOracle RACデータベースを構成する場合は、次の作業が必要です。

  • サイトAにノードの一方のセットを、サイトBにノードのもう一方のセットを構成します。

  • 両方のサイトに均等にクラスタ・ワークロードを分散し、設計上追加の競合や待機時間が発生しないようにします。たとえば、クライアント・コンポーネントはサイトAに、サーバー・コンポーネントはサイトBに配置するなどして、クライアントとサーバーのアプリケーション・ワークロードを両方のサイトにわたり実行することは避けます。

2.5.2 都市圏での近接性を保持するノードの構成

拡張クラスタでは、データ・センターが待機時間と複雑性を低減するのに十分なほど近接していれば、サーバーおよびサイト障害に対して最高レベルの可用性が提供されます。拡張クラスタのサイト間の推奨距離は、都市圏内です。ノード間およびストレージ間の待機時間が長いと、パフォーマンスおよびスループットに深刻な影響を与える可能性があります。パフォーマンス・テストを実行して、待機時間の影響を評価する必要があります。一般的に、50km以下の距離が推奨されます。

テストにより、Oracle RACクラスタ・ノード間の距離(最大ケーブル長)による構成への一般的な影響が次のように判明しました。

  • 10km未満の距離には、通常のネットワーク・ケーブルを使用できます。

  • 距離が10km以上の場合はDWDMリンクが必要です。

  • 10〜50kmの距離には、距離によるパフォーマンスへの影響を最小限に抑えるため、ストレージ・エリア・ネットワーク(SAN)・バッファ・クレジットが必要です。そうしない場合、距離によるパフォーマンスの低下が深刻なものになる可能性があります。

  • 50kmを超える距離の場合、デプロイの影響を示す十分な証拠はまだ存在しません。対応可能なワークロードのタイプや、選択した距離によるパフォーマンスへの影響を識別するには、より多くのテストが必要です。

2.5.3 ASM標準冗長性または高冗長性でのホスト・ベースのストレージ・ミラー化の使用

ASM標準冗長性または高冗長性が構成されたディスク・グループで、ホスト・ベースのミラー化を使用して、ストレージ・アレイの障害がアプリケーションとデータベースの可用性に影響を与えないようにします。

2つのストレージ・アレイにわたり内部的にミラー化を実行するASMを使用したホスト・ベースのミラー化をお薦めします。ASMでミラー化を実装すると、システムの書込みI/Oがディスクの両方のセットに伝播されるアクティブ/アクティブ・ストレージ環境が提供され、各ディスクはその場所にかかわらず単一のディスク・セットとして認識されます。アレイ・ベースのミラー化は、ただ1つのストレージ・サイトのみがアクティブとなるため、使用しないでください。この場合、アーキテクチャがそのシングル・ポイント障害に対して脆弱となり、リカバリ時間が長期化します。

ASMボリューム・マネージャには、柔軟なホスト・ベースのミラー化冗長性オプションがあります。外部冗長性を使用して、ミラー化保護機能をハードウェアRAIDストレージ・サブシステムに依存することもできます。ASMの標準冗長性および高冗長性オプションでは、それぞれ二重および三重のミラー化を使用できます。

Oracle Databaseリリース11g以上では、読取りI/Oがリモート障害グループから不要な読取りをせずにローカル・ストレージにアクセスする優先読取り機能がASMに含まれます。ASM障害グループの拡張クラスタを構成する場合、特定のノードがそのノードに最も近い障害グループのエクステント(セカンダリ・エクステントも含む)からデータを読み取るように指定できます。この構成は、パフォーマンスに関してリモート・ノードのアクセスが非対称な拡張クラスタにおいて特に有効であり、可用性の向上とネットワーク負荷の低減につながります。優先読取り障害グループの使用は、拡張クラスタで最も役立ちます。

ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータの値は、特定のインスタンスで優先的に読み取る必要のある障害グループを指定したカンマ区切りの文字列リストです。このパラメータは、インスタンス固有であり、通常はクラスタ化されたASMインスタンスでのみ使用します。その値には、ノードごとに異なる値を指定できます。たとえば、次のようになります。

diskgroup_name1.failure_group_name1, ...

関連項目:

ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータで優先読取り障害グループを構成する方法の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

2.5.4 クォーラム・ディスクをホストするための第3の投票ディスクの追加

クォーラム(投票)・ディスクをメイン・サイト(データ・センター)とは別の場所でホストするために第3のサイトに第3の投票ディスクを追加します脚注7

ほとんどの拡張クラスタには、2つのストレージ・システムのみが存在します(各サイトに1つ)。通常の処理では、各ノードは一定の間隔でディスク・ハートビートの書込みと読取りを行いますが、ハートビートが完了できない場合、強制再起動により、影響のあるすべてのノードがクラスタから削除されます。したがって、投票ディスクの大部分を保持するサイトは、クラスタ全体の潜在的なシングル・ポイント障害となります。可用性を確保するため、いずれかのサイトに障害が発生した場合や、サイト間に通信障害が発生した場合に備え、調停機能を保持する第3のサイトを追加する必要があります。

状況によっては、標準のNFSを使用して、低価格なローエンドの標準的なNFSマウント・デバイス上で第3の投票ディスクをサポートすることもできます。詳細は、Oracle Technology Network(OTN)のホワイト・ペーパー(http://www.oracle.com/technology/products/database/clustering/pdf/thirdvoteonnfs.pdf)を参照してください。

拡張クラスタを使用し、第3のサイトを構成しない場合、一方のサイトをプライマリ・サイトに、他方をセカンダリ・サイトにする必要があります。その後、プライマリ・サイトに障害が発生したら、セカンダリ・サイトを手動で再起動する必要があります。

2.5.5 拡張クラスタに関する追加のデプロイメントの考慮事項

拡張クラスタ・アーキテクチャを実装する場合、次のことにも留意してください。

  • ネットワーク、ストレージおよび管理のコストは増加します。

  • 書込みパフォーマンスにより、ネットワーク待機時間のオーバーヘッドが発生します。ワークロード・パフォーマンスをテストして、オーバーヘッドの影響を評価します。

  • Oracle Data Guardなしで単一データベースを使用するため、データ破損またはデータ障害に対する保護はありません。

  • 拡張クラスタで使用されるOracleリリース、オペレーティング・システムおよびクラスタウェアは、すべて拡張クラスタの存続可能性に影響します。

  • サイト間のデータをミラー化する場合、次のことに留意してください。

    • ホスト・ベースのミラー化には、アクティブ/アクティブ・ミラー(およびプライマリ/プライマリ・サイト構成)を可能にするクラスタ化された論理ボリューム・マネージャが必要です。クラスタ化された論理ボリューム・マネージャには、ASMを使用することをお薦めします。

    • アレイ・ベースのミラー化では、アクティブ/パッシブ・ミラー(およびプライマリ/セカンダリ構成)を使用できます。

  • このソリューションでは、ストレージの完全コピーが2つ(サイトごとに1つ)必要なので、ストレージ・コストは大変高価です。

  • 拡張クラスタでは、次のような障害に対する追加の破壊テストが必要です。

    • サイト障害

    • 通信障害

  • 完全な障害時リカバリのため、リモートData Guardスタンバイ・データベースで拡張クラスタを強化します。このアーキテクチャには、次の特徴があります。

    • プライマリ・データベースの独立した物理レプリカを維持します。

    • 局地的災害からデータを保護します。

    • データ破損および他の潜在的障害からデータを保護します。

    • ローリング・データベース・アップグレードおよびパッチ・セット・アップグレードを実行するためのオプションを提供します。



脚注の説明

脚注7: 拡張クラスタで第3の投票ディスクをサポートするには、標準のNFSを使用します。クォーラム・ディスクは、ネットワーク上の任意の場所で、低価格なローエンドの標準的なNFSマウント・デバイス上に構成できます。NFS投票ディスクは、本番環境に属する専用サーバー上に配置することをお薦めします。標準のネットワーク・ファイル・システム(NFS)を使用して、拡張クラスタ構成で第3の投票ディスクをサポートする方法の詳細は、Oracle Real Application ClustersのWebサイト(http://www.oracle.com/technology/products/database/clustering/index.html)にあるホワイト・ペーパーを参照してください。