| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
この章には、次の項目が含まれます。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
この項に記載されているベスト・プラクティスは、Oracle Real Application Clusters(Oracle RAC)を使用したOracle Database 12cに適用されます。これらのベスト・プラクティスは、第4章「Oracle Databaseの構成」および第5章「Oracle Clusterwareを使用したOracle Databaseの構成」に説明されている構成ベスト・プラクティスを基盤としています。各ベスト・プラクティスは、Oracle RACとData Guard MAAを使用したOracle Database 12c環境のData Guardで使用される場合、プライマリ・データベースとスタンバイ・データベースで同一です。一部のベスト・プラクティスでは、停止時間を短縮または排除するためにシステム・リソースを大量に使用することがあります。これにより、パフォーマンス・サービス・レベルが影響を受ける可能性があるため、これらのベスト・プラクティスを本番環境で実装する前に必ずテスト環境でその影響を評価してください。
|
関連項目: 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
インスタンス・リカバリは障害インスタンスからREDOスレッドをリカバリするプロセスです。インスタンス・リカバリは、データベースにアクセスするすべてのインスタンスに障害が発生した場合に実行されるクラッシュ・リカバリとは異なります。クラッシュ・リカバリは、単一インスタンスのOracleデータベースを使用するインスタンスに障害が発生した場合に実行される唯一のタイプのリカバリです。
Oracle RACを使用している場合、稼働を続けるいずれかのインスタンスのSMONプロセスが、障害インスタンスのインスタンス・リカバリを実行します。
Oracle RACと単一インスタンス環境の両方で、チェックポイントは、平均リカバリ時間(MTTR)の制限に使用される内部メカニズムです。チェックポイントは、バッファ・キャッシュからディスクに使用済バッファを書き込むプロセスです。チェックポイントの数を増やすと、障害後のリカバリに必要とされるREDOは少なくなります。目的は同じですが、MTTRの調整に使用されるパラメータおよびメトリックは、単一インスタンス環境とOracle RAC環境で異なります。
単一インスタンス環境では、クラッシュ・リカバリで必要とする秒数にFAST_START_MTTR_TARGET初期化パラメータを設定できます。クラッシュ・リカバリ時間には、データベースの起動、マウント、リカバリおよびオープンに要する時間が含まれます。
Oracleには、現在のシステムが達成しているMTTRターゲットと、所定のI/O容量において達成可能なMTTRターゲットを把握するのに役立ついくつかの方法が用意されています。
|
関連項目: 詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Oracle ClusterwareとOracle Real Application Clustersを使用して計画外停止時の可用性を最適化するためのベスト・プラクティス』を参照してください。 |
FAST_START_PARALLEL_ROLLBACKパラメータでは、REDO適用後に実行されるトランザクション・リカバリで使用されるプロセスの数が判断されます。トランザクション・リカバリの最適化は、計画外の障害の発生後に効率的なワークロードを確保するために重要です。システムのCPU負荷が高くなければ、このパラメータをHIGHに設定することがベスト・プラクティスです。これにより、Oracleでは、トランザクション・リカバリ用にCPU_COUNTの4倍(4 X CPU_COUNT)のパラレル・プロセスを使用します。このパラメータのデフォルト設定はLOW、またはCPU_COUNTの2倍(2 X CPU_COUNT)です。パラメータは、次のように設定します。
ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK=HIGH SCOPE=BOTH;
さらに重要なことに、システムがCPUバウンド状態ではないことに加えて、FAST_START_PARALLEL_ROLLBACKをHIGHに設定するためにI/Oバウンドでない必要があるため、計画外の障害の発生後にデータベースのワークロードは影響を受けません。
FAST_START_PARALLEL_ROLLBACKがHIGHに設定された場合、CPUが多数あるシステムでは、IOPS速度を大幅に上げること可能なパラレル・リカバリ・スレーブが大量に生成されます。その場合、FAST_START_PARALLEL_ROLLBACKをHIGHに設定する前に、システムがI/Oに関する問題を抱えていない必要があります。
|
関連項目: パラレルDMLおよびパラレルDDLのリソース使用率に影響するパラメータの詳細は、『Oracle Database VLDBおよびパーティショニング・ガイド』を参照してください。 |
非同期I/Oの使用は、すべてのOracleデータベースで推奨されるベスト・プラクティスです。詳細は、4.1.7項「DISK_ASYNCH_IO初期化パラメータの設定」を参照してください。
パブリック・トラフィック、Oracle RACインターコネクトおよびI/Oには、冗長専用接続を使用して十分な帯域幅を確保します。
Oracle用語で拡張クラスタは、ノードが2つの物理的な場所に分けられている、2つ以上のノード構成を指します。拡張クラスタおよびその他のOracle RAC構成には、1つのファイバに基づく個別の専用チャネルが必要になる場合があります。または、オプションで高密度波長分割多重方式(DWDM)を構成して、リピータを使用せずにサイト間で通信することや、サイト間を遠く離す(10km超)ことができます。ただし、デメリットとして、DWDMは非常にコストがかかる可能性があります。
|
関連項目: ネットワーク・ハードウェア要件の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。 |
Oracle RAC One Nodeは、クラスタ内の1つのノードで実行されるOracle Real Application Clusters(Oracle RAC)データベースの単一インスタンスで、同じクラスタ内の他のノードにフェイルオーバーまたは移行するオプションがあります。このオプションによって、Oracleでのデータベース統合の柔軟性が向上します。フェイルオーバーによる保護で高可用性を実現しながら、多くのデータベースを最小限のオーバーヘッドで1つのクラスタに統合でき、オンラインでのローリング・パッチ適用、オペレーティング・システムおよびOracle Clusterwareのローリング・アップグレードも可能になります。
|
関連項目: Oracle RAC One Nodeの管理の詳細は『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照 |
Oracle RACの拡張クラスタは、サイト障害からの非常に高速なリカバリを実現し、すべてのサイトのすべてのノードで単一のデータベース・クラスタの一部としてアクティブにトランザクションを処理できるアーキテクチャです。拡張クラスタでは、ローカルのOracle RACクラスタより高い可用性を得ることができますが、各サイトは通常同じ都市圏内に存在するため、このアーキテクチャでは組織の障害時リカバリ要件をすべて満たすことができない可能性があります。
この項に記載されているベスト・プラクティスは、拡張クラスタでのOracle RACを使用したOracle Database 11gに適用されるもので、6.1項「Oracle RACを使用したOracle Databaseの構成」に説明されているベスト・プラクティスを基盤としています。
拡張クラスタ環境でOracle RACデータベースを構成する場合は、次のベスト・プラクティスを使用します。
|
関連項目:
|
典型的なOracle RACアーキテクチャは、主に単一のデータ・センターに存在するスケーラビリティおよび可用性ソリューションとして設計されています。Oracle RACの拡張クラスタを構成およびデプロイするには、クラスタの各ノードを遠く離して配置します。拡張クラスタ環境でOracle RACデータベースを構成する場合は、次の作業が必要です。
サイトAにノードの一方のセットを、サイトBにノードのもう一方のセットを構成します。
両方のサイトに均等にクラスタ・ワークロードを分散し、設計上追加の競合や待機時間が発生しないようにします。たとえば、クライアント・コンポーネントはサイトAに、サーバー・コンポーネントはサイトBに配置するなどして、クライアントとサーバーのアプリケーション・ワークロードを両方のサイトにわたり実行することは避けます。
ほとんどの拡張クラスタには、2つのストレージ・システムのみが存在します(各サイトに1つ)。通常の処理では、各ノードは一定の間隔でディスク・ハートビートの書込みと読取りを行いますが、ハートビートが完了できない場合、影響のあるすべてのノードがクラスタから削除されます。これによってプロセスの再起動と、メンバーとしての安全な共有リソースへのアクセスの再試行が強制的に行われます。したがって、投票ディスクの大部分を保持するサイトは、クラスタ全体の潜在的なシングル・ポイント障害となります。可用性を確保するため、いずれかのサイトに障害が発生した場合や、サイト間に通信障害が発生した場合に備え、調停機能を保持する第3のサイトを追加する必要があります。
場合によっては、拡張クラスタで第3の投票ディスクをサポートするため、標準のNFSも使用できます。クォーラム・ディスクは、ネットワーク上の任意の場所で、低価格なローエンドの標準的なNFSマウント・デバイス上に構成できます。NFS投票ディスクは、本番環境に属する専用サーバー上に配置することをお薦めします。
拡張クラスタを使用し、第3のサイトを構成しない場合、2つのサイトのどちらがプライマリ・サイトか認識する必要があります。その後、プライマリ・サイトに障害が発生したら、セカンダリ・サイトを手動で再起動する必要があります。
|
注意: Oracle Clusterwareでは、NFS、iSCSI、Direct Attached Storage(DAS)、Storage Area Network(SAN)およびNetwork Attached Storage(NAS)がサポートされます。システムでNFSがサポートされていない場合は、他の方法を使用します。たとえば、WindowsシステムではiSCSIを使用できます。 |
|
関連項目: 詳細は、次のWebサイトのテクニカル記事『標準NFSを使用した、拡張クラスタ構成のための第3の投票ファイルのサポート』を参照してください。
|
拡張クラスタでは、データ・センターが待機時間と複雑性を低減するのに十分なほど近接していれば、サーバーおよびサイト障害に対して最高レベルの可用性が提供されます。拡張クラスタのサイト間の推奨距離は、都市圏内です。ノード間およびストレージ間の待機時間が長いと、パフォーマンスおよびスループットに深刻な影響を与える可能性があります。パフォーマンス・テストを実行して、待機時間の影響を評価する必要があります。一般的に、50km以下の距離が推奨されます。
テストにより、Oracle RACクラスタ・ノード間の距離(最大ケーブル長)による構成への一般的な影響が次のように判明しました。
10km未満の距離には、通常のネットワーク・ケーブルを使用できます。
距離が10km以上の場合は、高密度波長分割多重方式(DWDM)リンクが必要です。DWDMまたはCWDMを使用する場合、どちらか一方の側で専用スイッチを使用して直接接続する必要があります。
10から50kmの距離には、距離によるパフォーマンスへの影響を最小限に抑えるため、ストレージ・エリア・ネットワーク(SAN)・バッファ・クレジットが必要です。そうしない場合、距離によるパフォーマンスの低下が深刻なものになる可能性があります。
50kmを超える距離の場合、デプロイの影響を示す十分な証拠はまだ存在しません。対応可能なワークロードのタイプや、選択した距離によるパフォーマンスへの影響を識別するには、より多くのテストが必要です。
その他の考慮事項として、それぞれ必要な冗長性を持っている別々のチャネルで、インターコネクト、SANおよびIPネットワーキングを保持する必要があります。冗長な接続は、ケーブルが切断される可能性があるため、同じダーク・ファイバ(使用する場合)、スイッチ、経路または建物の入り口でさえ共有しない必要があります。
Oracle Clusterwareを使用するため、VIPがあるサイトから別のサイトにフェイルオーバーできるように、パブリック・ネットワークが存在するサイト間に単一のサブネットを設定する必要があります。
Oracle ASM標準冗長性または高冗長性が構成されたディスク・グループで、ホスト・ベースのミラー化を使用して、ストレージ・アレイの障害がアプリケーションとデータベースの可用性に影響を与えないようにします。
2つのストレージ・アレイにわたり内部的にミラー化を実行するOracle ASMを使用したホスト・ベースのミラー化をお薦めします。Oracle ASMでミラー化を実装すると、システムの書込みI/Oがディスクの両方のセットに伝播されるアクティブ/アクティブ・ストレージ環境が提供され、各ディスクはその場所にかかわらず単一のディスク・セットとして認識されます。アレイ・ベースのミラー化は、ただ1つのストレージ・サイトのみがアクティブとなるため、使用しないでください。この場合、アーキテクチャがそのシングル・ポイント障害に対して脆弱となり、リカバリ時間が長期化します。
Oracle ASMボリューム・マネージャには、柔軟なホスト・ベースのミラー化冗長性オプションがあります。外部冗長性を使用して、ミラー化保護機能をハードウェアRAIDストレージ・サブシステムに依存することもできます。Oracle ASMの標準冗長性および高冗長性オプションでは、それぞれ二重および三重のミラー化を使用できます。
|
注意: アレイ・ベースのミラー化は、Oracle RAC拡張クラスタで使用できます。このアプローチを使用すると、2つのミラー・サイトがアクティブ・パッシブ構成になり、1つのサイトに障害が発生すると完全な停止状態となります。残りのミラー・サイトが起動されれば、サービスが使用可能になります。このような理由から、HAの観点ではアレイ・ベースのミラー化は推奨されません。2つのアクティブ・サイトで作業するには、ホスト・ベースのミラー化をお薦めします。 |
Oracle Databaseリリース11g以上では、読取りI/Oがリモート障害グループから不要な読取りをせずにローカル・ストレージにアクセスする優先読取り機能がOracle ASMに含まれます。Oracle ASM障害グループの拡張クラスタを構成する場合、特定のノードがそのノードに最も近い障害グループのエクステント(セカンダリ・エクステントも含む)からデータを読み取るように指定できます。この構成は、パフォーマンスに関してリモート・ノードのアクセスが非対称な拡張クラスタにおいて特に有効であり、可用性の向上とネットワーク負荷の低減につながります。優先読取り障害グループの使用は、拡張クラスタで最も役立ちます。
ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータの値は、特定のインスタンスで優先的に読み取る必要のある障害グループを指定したカンマ区切りの文字列リストです。このパラメータは、インスタンス固有であり、通常はクラスタ化されたOracle ASMインスタンスでのみ使用します。その値には、ノードごとに異なる値を指定できます。たとえば、次のようになります。
diskgroup_name1.failure_group_name1, ...
|
関連項目:
|
拡張クラスタ・アーキテクチャを実装する場合、次のことにも留意してください。
ネットワーク、ストレージおよび管理のコストは増加します。
書込みパフォーマンスにより、ネットワーク待機時間のオーバーヘッドが発生します。ワークロード・パフォーマンスをテストして、オーバーヘッドの影響を評価します。
Oracle Data Guardなしで単一データベースを使用するため、データ破損またはデータ障害に対する保護はありません。
拡張クラスタで使用されるOracleリリース、オペレーティング・システムおよびクラスタウェアは、すべて拡張クラスタの存続可能性に影響します。
サイト間のデータをミラー化する場合、次のことに留意してください。
ホスト・ベースのミラー化には、アクティブ/アクティブ・ミラー(およびプライマリ/プライマリ・サイト構成)を可能にするクラスタ化された論理ボリューム・マネージャが必要です。クラスタ化された論理ボリューム・マネージャには、Oracle ASMを使用することをお薦めします。
アレイ・ベースのミラー化では、アクティブ/パッシブ・ミラー(およびプライマリ/セカンダリ構成)を使用できます。
拡張クラスタでは、次のような障害に対する追加の破壊テストが必要です。
サイト障害
通信障害
完全な障害時リカバリのため、リモートData Guardスタンバイ・データベースで拡張クラスタを強化します。このアーキテクチャには、次の特徴があります。
プライマリ・データベースの独立した物理レプリカを維持します。
局地的災害からデータを保護します。
データ破損および他の潜在的障害からデータを保護します。
ローリング・データベース・アップグレードおよびパッチ・セット・アップグレードを実行するためのオプションを提供します。
