高可用性ベア・メタル・データベースのデプロイ

Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。Data Guardでは、Data Guard Brokerコマンドライン・インタフェース(DGMGRL CLI)またはOracle Enterprise Managerを使用して、またはファスト・スタート・フェイルオーバー(FSFO)オブザーバとして機能するように計算ノードを構成して、プライマリ・データベースをスタンバイ・データベースに手動でフェイルオーバーできます。オブザーバは、フェイルオーバーを自動的に開始し、障害が発生したプライマリ・データベースをスタンバイ・データベースとして自動的に回復できます。FSFOオブザーバをデプロイメントに含めると、データベース・フェイルオーバーが必要なときに手動で介入する必要がなくなります。

アーキテクチャ

このリファレンス・アーキテクチャでは、2つのベア・メタルDBシステムをデプロイする方法と、2つのリージョンのOracle Cloud InfrastructureにデプロイされたOracle Database 12 cリリース2 (12.2)のFSFOを構成するために必要なインフラストラクチャ・コンポーネントを示します。

このクラウド・データベース・アーキテクチャは、Oracle E-Business Suite、JD EdwardsおよびPeopleSoftを含む多くのアプリケーションの回復可能なデータベース層として使用できます。

次の図は、この参照アーキテクチャを示しています。

ha-db.pngの説明が続きます
図ha-db.pngの説明
  • リージョン

    Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。地域は他の地域から独立しており、広く離れた距離(国間または大陸間)にすることもできます。

  • 可用性ドメイン

    可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。アベイラビリティ・ドメインは、電源や冷却などのインフラストラクチャや内部アベイラビリティ・ドメイン・ネットワークを共有しません。したがって、ある可用性ドメインで障害が発生しても、リージョン内の他の可用性ドメインには影響しません。

    可用性ドメインはアーキテクチャ・ダイアグラムに表示されません。

  • フォルト・ドメイン

    フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各可用性ドメインには、独立した電源とハードウェアを持つ3つのフォルト・ドメインがあります。リソースを複数のフォルト・ドメインに分散する場合、アプリケーションでは、フォルト・ドメイン内の物理サーバー障害、システム・メンテナンスおよび電源障害を許容できます。

    フォルト・ドメインはアーキテクチャ・ダイアグラムに表示されません。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定するカスタマイズ可能なソフトウェア定義ネットワークです。従来のデータ・センター・ネットワークと同様に、VCNではネットワーク環境を完全に制御できます。VCNには、VCNの作成後に変更できる複数の重複しないCIDRブロックを含めることができます。VCNは、リージョンまたは可用性ドメインにスコープ指定できるサブネットにセグメント化できます。各サブネットは、VCN内の他のサブネットと重複しない連続したアドレス範囲で構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックまたはプライベートにできます。

  • セキュリティ・リスト

    サブネットごとに、サブネット内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。

  • オブザーバ

    オブザーバは、ベア・メタルDBシステムで実行されているOracle DatabaseのFSFOを開始するために必要なOracle Databaseソフトウェアがインストールおよび構成されているコンピュート・ノードです。FSFOのベスト・プラクティスは、プライマリ・データベースまたはスタンバイ・データベースとは異なるデータ・センターにあるホストでオブザーバ・プロセスを実行することです。このベスト・プラクティスを満たすために、このリファレンス・アーキテクチャでは3つのオブザーバ・ノードをデプロイします。この設定には、Oracle Databaseリリース12.2以上が必要です。

  • プライマリおよびスタンバイDBシステム

    これらのベア・メタルDBシステムには、Data Guardレプリケーション用に構成されたOracle Database 12 cリリース2 (12.2)があります。

推奨事項

実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。開始点として次の推奨事項を使用してください。

  • DBシステム・シェイプ

    この参照アーキテクチャでは、DBシステムにBM.Standard2.52ベア・メタル・シェイプを使用します。このシェイプには、51.2 TBのローカルにアタッチされたNVMe SSDが低レイテンシで含まれます。ベア・メタル・シェイプを選択したのは、複数のデータベース・ホームおよびデータベースを作成できるためです。

  • コンピュート・シェイプ

    この参照アーキテクチャでは、オブザーバ・ノードにVM.Standard2.1コア仮想マシン(VM)シェイプを使用します。オブザーバ・ノードは、DGMGRL CLIに組み込まれた低フットプリントのOracle Call Interfaceクライアントです。このアーキテクチャには、1コアVMシェイプで十分です。

  • VCN

    VCNを作成する場合、VCNのサブネットにアタッチする予定のリソースの数に基づいて、必要なCIDRブロックの数と各ブロックのサイズを決定します。標準のプライベートIPアドレス空間内にあるCIDRブロックを使用します。

    プライベート接続を設定する予定の他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ内)と重複しないCIDRブロックを選択します。

    VCNを作成した後、CIDRブロックを変更、追加および削除できます。

    サブネットを設計する際には、トラフィック・フローとセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。

    リージョナル・サブネットを使用します。

  • セキュリティ・リスト

    セキュリティ・リストを使用して、サブネット全体に適用されるイングレス・ルールおよびエグレス・ルールを定義します。たとえば、この参照アーキテクチャでは、プライベート・サブネット全体に対してICMPを内部的に使用できます。

  • Cloud Guard

    Oracleが提供するデフォルト・レシピをクローニングおよびカスタマイズして、カスタム検出およびレスポンダ・レシピを作成します。これらのレシピを使用すると、警告を生成するセキュリティ違反のタイプと、それらに対して実行できるアクションを指定できます。たとえば、可視性がパブリックに設定されているオブジェクト・ストレージ・バケットを検出できます。

    Cloud Guardをテナンシ・レベルで適用して、最も広範な範囲をカバーし、複数の構成を維持する管理上の負担を軽減します。

    管理リスト機能を使用して、特定の設定をディテクタに適用することもできます。

  • セキュリティ・ゾーン

    最大限のセキュリティを必要とするリソースの場合、Oracleではセキュリティ・ゾーンを使用することをお薦めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーン内のリソースは、パブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーン内のリソースを作成および更新する場合、Oracle Cloud Infrastructureはセキュリティ・ゾーン・レシピ内のポリシーに対して操作を検証し、いずれかのポリシーに違反する操作を拒否します。

注意事項

この参照アーキテクチャをデプロイする場合は、次の点を考慮してください。

  • パフォーマンス

    アプリケーションのワークロードに最適なパフォーマンスを得るには、アプリケーションおよびData Guard構成をサポートするのに十分なコアがプライマリのベア・メタルDBシステムにあることを確認します。

  • 可用性

    オブザーバ・ノードのいずれかがオフラインになった場合でもFSFOが自動的に発生するように、オブザーバ・ノードは複数の可用性リージョンにデプロイされます。フェイルオーバーが発生すると、スタンバイ・データベースがプライマリ・データベースになります。

  • コスト

    必要に応じて、ベア・メタルDBシステムのCPUのサイズを設定します。BM.DenseIO2.52シェイプでは、複数のコアから始めて52コアまでスケール・アップできます。ダウンタイムなしでコアを動的にスケール・アップすることもできます。