1. 高可用性概要およびベスト・プラクティス
  2. Oracle RACおよびClusterwareのベスト・プラクティス
  3. Oracle RACおよびClusterwareのベスト・プラクティスの概要

11 Oracle RACおよびClusterwareのベスト・プラクティスの概要

Oracle ClusterwareおよびOracle Real Application Clusters (RAC)は、クラスタ環境におけるOracleの戦略的な高可用性およびリソース管理データベース・フレームワークであり、Oracle MAA Silverリファレンス・アーキテクチャの不可欠な部分です。

Bronze MAAリファレンス・アーキテクチャにOracle RACを追加すると、Silver MAAリファレンス・アーキテクチャに昇格します。Silver MAAリファレンス・アーキテクチャは、リカバリ不能なデータベース・インスタンスまたはサーバー障害があった場合に、コールド再起動を待機できないデータベースまたはバックアップからのリストアを待機できないデータベースのために設計されています。

Silverリファレンス・アーキテクチャでは、ノードまたはインスタンスの障害およびほとんどのデータベースやシステムのソフトウェア更新について、停止時間ゼロとなる可能性があります。これは、Bronzeアーキテクチャでは実現できません。Silver MAAリファレンス・アーキテクチャについてさらに学習するには、「高可用性リファレンス・アーキテクチャ」を参照してください。

Oracle ClusterwareおよびOracle RACには、次の利点があります。

  • 高可用性フレームワークおよびクラスタ管理ソリューション
    • 仮想インターネット・プロトコル(VIP)アドレス、データベース、リスナー、サービスなどのリソースを管理します
    • Oracleデータベース・リソースおよびサード・パーティ・エージェントなどの非Oracleデータベース・リソース用のHAフレームワークを提供します

  • スケーラビリティと可用性を実現するアクティブ-アクティブ・クラスタリング

    • 高可用性 サーバーまたはデータベース・インスタンスが停止しても、機能しているインスタンスへの接続に影響はなく、停止したインスタンスへの接続は、Oracle RACクラスタ内の他のサーバーですでに実行され、オープンである機能しているインスタンスへすぐにフェイルオーバーされます
    • スケーラビリティおよびパフォーマンス Oracle RACは、容量の動的な追加や、複数のサーバーをまたぐ優先度の変更を必要とする大規模なアプリケーションや統合環境に最適です。個々のデータベースのインスタンスは、クラスタの1つ以上のノードで実行されます。同様に、データベース・サービスも、1つ以上のデータベース・インスタンスで使用可能です。追加のノード、データベース・インスタンスおよびデータベース・サービスを、オンラインでプロビジョニングできます。クラスタ間でワークロードを簡単に分散できるため、Oracle RACは、多数のデータベースを連結する際、Oracle Multitenantに最適なコンポーネントです。

次の表に、様々なOracle ClusterwareおよびReal Application Cluster構成のベスト・プラクティスを示します。

表11-1 Oracle RAC HAのユースケースおよびベスト・プラクティス

ユースケース ベスト・プラクティス
認定済および検証済のクラスタウェア・ソフトウェア・スタック

Oracle Clusterwareを使用して、サード・パーティ・クラスタウェアを回避します。

Oracle Database Clusterware管理およびデプロイメント・ガイドを参照してください

クラスタウェアは、すべてのOracle Exadataシステムに組み込まれています。
認定済および検証済のストレージ・アーキテクチャ

次のMAAの利点には、サード・パーティのボリューム・マネージャおよびクラスタ・ファイル・システムではなく、Oracle Automatic Storage Management (Oracle ASM)およびOracle ASMクラスタ・ファイル・システム(Oracle ACFS)を使用します。

  • すべてのディスクにわたって作業を分散させることによる、ホット・スポットの排除
  • ディスクおよびストレージをオンラインで追加および削除することによる、ストレージ容量のスケーリングおよび調整
  • データベース・ストレージを管理する簡略化された均一な方法(ASMCMD、ASMCA、ExaCLIまたはoeadacli)を提供することによる、複雑さの軽減
  • ASMディスク・グループ使用時の固有のデータ破損の検出および修復
  • 追加のドライバを必要としない統合されたOracle Grid Infrastructure (Clusterware +ASM)による、簡単な管理、パッチ適用およびメンテナンス

外部冗長性でASMを使用する場合は、基礎となるストレージおよびネットワークが単一点障害なしで可用性が高いことを確認してください。

ASMネイティブ冗長性を使用する場合、計画外停止やストレージ・ソフトウェアの更新時に最大限の保護を提供するために、高冗長性ディスク・グループの使用をお薦めします。デフォルトでは、Exadataデプロイメントでは、すべてのディスク・グループに対して高冗長性が使用されます(データとリカバリの宛先の両方)。

Oracle Automatic Storage Management Cluster File System (Oracle ACFS)は、マルチプラットフォームのスケーラブルなファイル・システムであり、Oracle Automatic Storage Management (Oracle ASM)の機能を拡張してすべてのカスタマ・ファイルをサポートし、非データベース・ファイルに活用できるストレージ管理テクノロジです。

これらのベスト・プラクティスは、すべてのOracle Exadataシステムに組み込まれています。

Oracle Automatic Storage Managementの概要を参照してください
認定済および検証済のネットワーク・アーキテクチャ

データベースおよびストレージ・ネットワーク・トポロジ全体に、単一点障害のない複数のネットワーク・パスがあることを確認します。

データベース・サービスに接続する場合は、組込みの仮想インターネット・プロトコル(VIP)アドレス、単一クライアント・アクセス名(SCAN)および結合されたクライアント・ネットワーク上に構成された複数のローカルSCANリスナーを使用します。

バックアップまたはData Guardトラフィックには、別個の高帯域幅の結合されたネットワークを使用します。

クラスタのインターコネクトとして使用されるプライベート・ネットワークの場合、Exadata以外の顧客は、結合されたネットワークを使用するかわりに、ネットワーク冗長性のためにOracle HAIPを使用することをお薦めします。結合構成には、異なるネットワーク・カードおよびスイッチ設定で動作が異なる様々な属性があります。結合設定が正しく構成および検証されているため、この推奨事項は、Exadata環境内のプライベート・クラスタのインターコネクトには適用されません。さらに、Exadataでは、可用性の高い結合されたネットワークを介してCLUSTER_INTERCONNECTパラメータを使用します。汎用システムでは、CLUSTER_INTERCONNECTと結合を使用せず、Oracle HAIPを使用してください。

クラスタ構成チェック

クラスタ検証ユーティリティ(CVU)を月次間隔で使用して、共有ストレージ・デバイス、ネットワーク構成、システム要件、Oracle Clusterwareなどの様々なクラスタおよびOracle RACコンポーネントを検証します。クラスタ検証ユーティリティのリファレンスを参照してください

包括的でプロアクティブなヘルス・チェックを実行し、Oracle RACまたはExadataのベスト・プラクティスに従っているかどうかを評価するには、ソフトウェア更新の前後に月次間隔で、Exadata RACシステムの場合にはexachkを、またはExadata以外のRACシステムにはorachkを使用します。

ORAchk - Health Checks for the Oracle Stack (Doc ID 1268927.2)およびOracle Exadata Database Machine exachk or HealthCheck (Doc ID 1070954.1)を参照してください。

exachkとorachkの両方にCVUチェックが含まれていることに注意してください。exachkでは、ストレージ、ネットワーク、クラスタウェア、ASMおよびデータベースについて、ソフトウェアと構成のベスト・プラクティスおよびクリティカル・アラートが対象となります。

構成に関する推奨事項をCVU、exachkまたはorachkから組み込みます。

データベース・ノードまたはインスタンスの障害による停止時間を短縮する

通常、ほとんどのユースケースではデフォルト設定で十分です。ノード検出およびインスタンス・リカバリを迅速化する必要がある場合は、FAST_START_MTTR_TARGETのより小さい値を評価します

FAST_START_MTTR_TARGETを減らすと、データベース・ライターのアクティビティが大幅に増加するため、I/O帯域幅を追加する必要があります。

Exadataシステムの場合、即時障害検出でリモート直接メモリー・アクセス(RDMA)を使用し、ほとんどのOracle RACクラスタで一般的に30秒かかる検出と比較して、サーバーの障害を2秒未満で迅速に確認できます。
ソフトウェア更新による停止時間を排除する

停止時間を回避するには、クラスタウェアまたはデータベース・ソフトウェアの更新(リリース更新など)にOracle RACローリング更新を使用します。

可能な場合にはホーム外ソフトウェア更新を使用するため、ロールバックおよびフォールバックのユースケースが簡略化されます。

ソフトウェア・ゴールド・イメージを使用して、データベースopatchユーティリティを実行する複雑さを排除します。

単一のOracle RACクラスタまたは複数のクラスタ上のデータベースのフリートの場合は、Oracle Fleet Patching and Provisioningを使用します
アプリケーションおよびプロセスをクラスタで高可用性にする

クラスタ内でアプリケーション、プロセスまたはサーバーに障害が発生した場合、中断をできるだけ短くしてユーザーに透過的にする必要があります。たとえば、サーバーでアプリケーションに障害が発生した場合、そのアプリケーションをクラスタ内の別のサーバーで再起動して、そのアプリケーションの使用に対する影響を最小限にするか、またはなくしてしまうことができることを意味します。同様に、クラスタ内のサーバーに障害が発生した場合、引き続きユーザーにサービスを提供するために、そのサーバーで実行されているすべてのアプリケーションおよびプロセスを別のサーバーにフェイルオーバーする必要があります。組込みのgeneric_applicationリソース・タイプを使用すると、Oracle Clusterwareはこれらのすべてのエンティティを管理して、高可用性、リソース・タイプ、カスタマイズ可能なスクリプト、アプリケーション・エージェント・プログラム、およびアプリケーションやプロセスに割り当てるリソース属性を確保できます。

Oracle Clusterwareを使用して、クラスタに存在するサード・パーティのリソースおよびエージェントを管理します。

Oracle Clusterwareを使用したアプリケーションの可用性の向上に関する項を参照してください
計画停止および計画外停止によるアプリケーションの停止時間を短縮する

クラスタウェア管理サービスおよびアプリケーションのベスト・プラクティスを活用して、アプリケーションの停止時間をなくします。

PDBのサービスを管理するには、SRVCTLを使用します。アプリケーションの接続にデフォルトのサービスを使用しないでください。高可用性のために、少なくとも1つの優先Oracle RACインスタンスおよび少なくとも1つの使用可能な追加のOracle RACインスタンスが必要です。

アプリケーションはHA高速アプリケーション通知(FAN)をサブスクライブし、必要に応じて応答およびフェイルオーバーするように構成する必要があります。

「アプリケーションの継続的なサービスの有効化」および継続的な可用性 - MAAソリューションの継続的なサービスのためのアプリケーション・チェックリストを参照してください
容量計画

アプリケーション・パフォーマンス要件を満たす十分なシステム・リソースがあることを確認するために、容量計画およびサイズ設定はデプロイメント前、およびその後は定期的に実行する必要があります。

容量計画では、データベースの増加または統合、追加のアプリケーション・ワークロード、追加のプロセス、または既存のシステム・リソースを損なうあらゆるものに対応する必要があります。

計画外停止または計画メンテナンス・イベント中にパフォーマンス要件がまだ満たされているかどうかを評価することも非常に重要です。