Oracle Cloud Infrastructureドキュメント

フル・スタックDR請求詳細

Full Stack DRサービスが、DR保護グループに追加されたメンバー・タイプごとに、いくつかのサンプル計算を含む請求を計算する方法を学習します。

DR構成に対する請求の計算方法(関連するDR保護グループのペアの場合)

  1. フル・スタックDRでは、割当て済CPU (OCPUまたはECPU)のみが料金の計算の基礎として使用されます。ストレージ、ネットワーキングおよびその他のリソース使用は、Full Stack DRでは請求されません。
  2. 合計請求額は、関連するペアのDR保護グループの両方に追加されたすべての個々のメンバーに対するCPUベースの請求コストの合計です。
  3. DR保護グループの関連メンバーのCPU使用率は、次の表で説明する方法を使用して計算されます。
  4. 以下の詳細およびサンプル計算を実行した後、このWebサイトを参照して、原価見積計算をロードします。これを使用して、DR構成の料金を見積もります。

手数料が発生するメンバー・リソース

フル・スタックDRでは、割当て済CPU (OCPUまたはECPU)のみが料金の計算の基礎として使用されます。リソースが実行中か停止中かに関係なく、DR保護グループのコンピュート・メンバーまたはデータベース・メンバーに対してフル・スタックDRの料金が発生します。たとえば、スタンバイ・リージョンに存在する非移動コンピュート・インスタンスは、DR操作が実行されていなくてもフル・スタックDRの時間単位の料金が累積されるまで、常に停止状態になります。

料金が発生するOCIリソース

フル・スタックDR料金は、次のOCI IaaSおよびPaaSリソース・タイプに対して発生します。
  • Autonomous Database
    • Oracle Autonomous Database Serverless(データ・ウェアハウス)
    • Oracle Autonomous Database Serverless(トランザクション処理)
  • Autonomous Container Database
    • 専用Exadataインフラストラクチャ上のAutonomous Database
  • Database
    • ベース・データベース
    • 専用インフラストラクチャ上のExadata Database
    • Cloud@Customer上のExadata Database
    • Exascaleインフラストラクチャ上のExadata Database
  • コンピュート・インスタンス(移動)
  • コンピュート・インスタンス(非移動)
  • Oracle Kubernetesエンジン(OKE)
次のOCI IaaSおよびPaaSリソース・タイプでは、フル・スタックDR料金は発生しません:
  • ブロック・ストレージ(ブート・ボリュームを含む)
  • ファイル・ストレージ
  • オブジェクト・ストレージ
  • ロード・バランサ
  • ネットワーク・ロード・バランサ
次のフル・スタックDR料金は発生しません:
  • Oracle applications
  • Oracle applications以外

プロセッサ消費量の決定

次の表に、Full Stack DRの時間単位の料金が発生する様々なOCIメンバー・リソース・タイプについて、OCPUおよびECPUの消費量がどのように決定されるかを示します。ほとんどのOCIリソース・タイプのプロセッサ消費量を決定することは、個々のリソースについて、OCIコンソールの詳細ページに表示される内容に基づいてまっすぐです。ただし、Oracle Exadataなどの一部のリソースでは、個々のデータベースのプロセッサ消費量が表示されません。これは、VMクラスタによって消費されるCPUの総計から導出されます。

表A-9プロセッサの消費量の決定

メンバー・タイプ CPUのタイプ 計算のベース
コンピュート・インスタンス(移動) OCPU コンピュート・インスタンスに割り当てられたOCPU数。コンピュート・インスタンスのOCIドキュメント・ページの「シェイプ構成」セクションを参照してください。
コンピュート・インスタンス(非移動) OCPU コンピュート・インスタンスに割り当てられたOCPU数。コンピュート・インスタンスのOCIドキュメント・ページの「シェイプ構成」セクションを参照してください。
データベース: Oracleベース・データベース OCPU ベース・データベースに関連付けられたデータベース・システム(DB System)に割り当てられたCPUコア数。ベース・データベースのOCIドキュメント・ページの「一般情報」セクションを参照してください。
データベース:
  • Oracle Exadata Database on Dedicated Infrastructure
  • Oracle Exadata Database on Cloud@Customer
  • Oracle Exadata Database on Exascale Infrastructure
 ECPUまたはOCPU (レガシー)

このデータベースをホストするVMクラスタ(tc)のECPUまたはOCPUの合計数を、そのVMクラスタにプロビジョニングされているデータベースの合計数で割った値(ti)は、データベース・インスタンス当たりのCPUに等しくなります(to)。この導出平均CPU数は概算です。

式: (tc/ti) =to

次に例を示します:
  • tc = Exadata VMクラスタに割り当てられた合計ECPUまたはOCPU: 64
  • ti = クラスタ内のデータベース・インスタンスの合計数: 4
  • to = データベース・インスタンス当たりのECPUまたはOCPU: 16
Autonomous Database:
  • サーバーレス・データウェアハウス
  • サーバーレス・トランザクション処理
ECPUまたはOCPU (レガシー) インスタンスに割り当てられたECPU/OCPUの合計数は、OCIコンソールの各Autonomous Serverlessデータベース・インスタンスのリソース詳細ページの「リソース割当て」セクションに「ECPU/OCPU数」と表示されます。
Autonomous Container Database:
  • 専用Exadataインフラストラクチャ上のAutonomous Database
  • Autonomous Database on Exadata Cloud@Customer
 ECPUまたはOCPU (レガシー)

インスタンスに割り当てられたECPU/OCPUの合計数は、OCIコンソールの各Autonomous Container Databaseインスタンスのリソース詳細ページの「リソース割当て」セクションにECPU/OCPU数として表示されます。

Oracle Kubernetesクラスタ(OKE) OCPU

計算は、両方のリージョンのOKEクラスタの各ノード・プールに割り当てられたノード・プール・サイズおよびOCPUの数量によって異なります。OKEクラスタには、複数のノード・プールを含めることができます。したがって、各リージョンの合計OCPUは、そのリージョン内のすべてのノード・プールの結果の合計です。

プライマリOKEクラスタ(nps)のノード・プール・サイズに、そのノード・プール(npo)に割り当てられたOCPUの数を乗算します。プライマリ・リージョンの各ノード・プール(pnsn+*pnon+)に対してこの計算を実行し、それぞれの結果を合計してプライマリ・リージョン(poc)の合計OCPU数に達します。

スタンバイOKEクラスタ(sns)のノード・プール・サイズに、そのノード・プールに割り当てられたOCPUの数を乗算します(sno)。プライマリ・リージョンの各ノード・プール(snsn+*snon+)に対してこの計算を実行し、各ノード・プールの結果を合計します。

プライマリ・リージョンからの合計OCPU数(poc)およびスタンバイ・リージョンからの合計OCPU数(soc)を追加して、OKEの合計OCPU数(to)に到達します

式: ∑(pnsn+*pnon+) + ∑(snsn+*snon+) = to

次に例を示します:

  1. プライマリ・リージョンの合計OCPUの計算
    • nps1 = ノード・プール1のサイズ: 10
    • npo1 = ノード・プール1のOCPU数: 2
    • nps2 = ノード・プール2のサイズ: 5
    • npo2 = ノード・プール2 OCPU数: 2
    • poc = プライマリ・リージョンの合計OCPU数は30です
  2. スタンバイ・リージョンの合計OCPUの計算
    • nps1 = ノード・プール1のサイズ: 10
    • npo1 = ノード・プール1のOCPU数: 2
    • nps2 = ノード・プール2のサイズ: 5
    • npo2 = ノード・プール2 OCPU数: 2
    • soc = スタンバイ・リージョンの合計OCPU数: 30
  3. 両方のリージョンの合計OCPU数の計算
    • ポック= 30
    • soc = 30
    • to = OKEの合計OCPU数: 60

コストエスティメータ

Oracleは、Full Stack DR製品ページで、使いやすいコスト見積りツールを提供します。

フル・スタック・ディザスタ・リカバリでは、コンピュート、ストレージ、ネットワーク、データベース、アプリケーションなどのOCIリソースはインストール、構成またはデプロイされません。フル・スタック・ディザスタ・リカバリを調整するディザスタ・リカバリ戦略の設計を担当し、フル・スタック・ディザスタ・リカバリのワークフロー外ですべてのOCI IaaSおよびPaaSリソースを作成、構成およびデプロイする責任も負います。したがって、フル・スタック・ディザスタ・リカバリの使用を開始する前に、両方のリージョンにデプロイされるリソースをすでに把握しておく必要があります。つまり、いずれかのOCIリージョンにOCIリソースを実際にデプロイする前に、コスト見積り機能を使用できます。

考慮事項:

  • DR操作後にリソースが存在する場所を計算する必要はありません。現在の通常の操作状態にあるリソースについて検討します。
  • プライマリ・リージョンの場合、メンバーまたはプライマリDR保護グループのメンバーになるリソースによって消費されるOCPUおよびECPUの合計を追加します。
  • スタンバイ・リージョンの場合は、メンバーまたはスタンバイDR保護グループのメンバーになるリソースによって消費されるOCPUおよびECPUの合計を追加します。スタンバイ保護グループのメンバーとして、チャージ可能なリソースがある場合とない場合があります。たとえば、コンピュートを移動するリカバリのみをオーケストレーションする場合、スタンバイ保護グループでCPUを消費するメンバー・リソースがない可能性があります。
例1: 移動コンピュートのみを含むアプリケーション・スタック

次の例は、2つのOCIリージョンにデプロイされた架空のビジネス・システムを示しています。アプリケーション・スタックの一部であるIaaSおよびPaaSサービスに応じて、すべての顧客に異なるものがあります。この例では、コンピュートのみおよびデータベースなしの移動コストを見積もる方法を示します。

コスト見積りには、各リージョンのIaaSおよびPaaSリソースのOCPUおよびECPUの合計数をプラグインする6つのフィールドが含まれています。

次の表に、原価見積機能で入力する6つのフィールドを示します。フィールドの値は、2つのOCIリージョンにまたがるディザスタ・リカバリ用にデプロイされた架空のアプリケーション・スタックを表す次の表に示す詳細に基づいています。

表A-10プライマリOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
12 0 0

表A-11スタンバイOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
0 0 0

表A-12メトリック合計

OCIフル・スタックDR (OCPU) OCIフルスタックDR(ECPU)
12 0

プライマリDR保護グループのCPU

プライマリ・リージョン(リージョン1)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

次の表に、プライマリ・リージョンに存在する、またはプライマリ・リージョンに存在するIaaSおよびPaaSリソースの例を示します。次の表の最後の行のCPU合計は、上のコスト試算ツールの例に示されている数字です。

プライマリDR保護グループのCPU

表A-13プライマリDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server01 4    
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server02 8    
プライマリ ロード・バランサ
  • バックエンド・セット1がアクティブです
  • バックエンド・セット2がアクティブです
 MyLoadBalancerRegion1 請求なし 請求なし 請求なし
プライマリ ブロック・ボリューム・グループ
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01のブート・ボリュームが含まれます。
  • MyApp01Server02のブート・ボリュームが含まれます。
 MyVG00 請求なし 請求なし 請求なし
プライマリ ファイル・システム
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01およびMyApp01Server02にマウントされた/myscriptsのファイル・システムが含まれます。
 myscripts 請求なし 請求なし 請求なし
プライマリ プライマリ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   12 0 0

スタンバイDR保護グループのCPU

スタンバイ・リージョン(リージョン2)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

この例では、常に単一のリージョンにのみ存在する移動コンピュートのみが含まれます。したがって、スタンバイ保護グループにはチャージ可能なメンバー・リソースがないため、スタンバイ・リージョンのフル・スタック・ディザスタ・リカバリの料金は発生しません。

スタンバイDR保護グループのCPU

表A-14スタンバイDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
スタンバイ ロード・バランサ
  • バックエンド・セット1はアクティブではなく、移入されていません
  • バックエンド・セット2notはアクティブであり、移入されていません
 MyLoadBalancerRegion2 請求なし 請求なし 請求なし
スタンバイ スタンバイ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   0 0 0

例2: コンピュートとデータベースを移動するアプリケーション・スタック

次の例は、2つのOCIリージョンにデプロイされた架空のビジネス・システムを示しています。アプリケーション・スタックの一部であるIaaSおよびPaaSサービスに応じて、すべての顧客に異なるものがあります。この例では、コンピュートと2つのOracle Databasesの移動コストを見積もる方法を示します。

コスト見積りには、各リージョンのIaaSおよびPaaSリソースのOCPUおよびECPUの合計数をプラグインする6つのフィールドが含まれています。次の表に、原価見積機能で入力する6つのフィールドを示します。フィールドの値は、2つのOCIリージョンにまたがるディザスタ・リカバリ用にデプロイされた架空のアプリケーション・スタックを表す次の表に示す詳細に基づいています。

プライマリOCIリージョン/保護グループ

表A-15プライマリOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
12 16 16
スタンバイOCIリージョン/保護グループ

表A-16スタンバイOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
0 16 16
メトリック合計

表A-17メトリック合計

OCIフル・スタックDR (OCPU) OCIフルスタックDR(ECPU)
44 32

プライマリDR保護グループのCPU

プライマリ・リージョン(リージョン1)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

次の表に、プライマリ・リージョンに存在する、またはプライマリ・リージョンに存在するIaaSおよびPaaSリソースの例を示します。次の表の最後の行のCPU合計は、上のコスト試算ツールの例に示されている数字です。

プライマリDR保護グループのCPU

表A-18プライマリDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server01 4    
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server02 8    
プライマリ Oracle Database
  • Exadata VMクラスタ
  • プライマリ・ロールのData Guard
  • VMクラスタに割り当てられている合計64個のOCPU
  • VMクラスタでプロビジョニングされた4つのデータベース
  • データベース当たり16 OCPU: (64/4 = 各データベース当たり16 OCPU)
 MyExaDatabase03   16  
プライマリ Autonomous Database
  • 専用インフラストラクチャ
  • プライマリ・ロールでのAutonomous Data Guard
 MyADB01     16
プライマリ ロード・バランサ
  • バックエンド・セット1がアクティブです
  • バックエンド・セット2がアクティブです
 MyLoadBalancerRegion1 請求なし 請求なし 請求なし
プライマリ ブロック・ボリューム・グループ
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01のブート・ボリュームが含まれます。
  • MyApp01Server02のブート・ボリュームが含まれます。
 MyVG00 請求なし 請求なし 請求なし
プライマリ ファイル・システム
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01およびMyApp01Server02にマウントされた/myscriptsのファイル・システムが含まれます。
 myscripts 請求なし 請求なし 請求なし
プライマリ プライマリ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   12 16 16

スタンバイDR保護グループのCPU

スタンバイ・リージョン(リージョン2)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

この例では、常に単一のリージョンにのみ存在する移動コンピュートのみが含まれます。したがって、スタンバイ保護グループにはチャージ可能なメンバー・リソースがないため、スタンバイ・リージョンのフル・スタック・ディザスタ・リカバリの料金は発生しません。

スタンバイDR保護グループのCPU

表A-19 スタンバイDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
スタンバイ Oracle Database
  • 合計64 OCPUのExadata VMクラスタ
  • プライマリ・ロールのData Guard
  • VMクラスタに割り当てられている合計64個のOCPU
  • VMクラスタでプロビジョニングされた4つのデータベース
  • データベース当たり16 OCPU: (64/4 = 各データベース当たり16 OCPU)
 MyExaDatabase03   16  
スタンバイ Autonomous Database
  • 専用インフラストラクチャ
  • スタンバイ・ロールのData Guard
 MyADB01     16
スタンバイ ロード・バランサ
  • バックエンド・セット1はアクティブではなく、移入されていません
  • バックエンド・セット2はアクティブではなく、移入されていません
 MyLoadBalancerRegion2 請求なし 請求なし 請求なし
スタンバイ スタンバイ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   0 16 16

例3: 移動および移動しないコンピュートを含むアプリケーション・スタック

次の例は、2つのOCIリージョンにデプロイされた架空のビジネス・システムを示しています。アプリケーション・スタックの一部であるIaaSおよびPaaSサービスに応じて、すべての顧客に異なるものがあります。

この例では、移動コンピュートと非移動コンピュートの両方が両方のリージョンのDR保護グループのメンバーである場合に、Full Stack DRの価格を設定する方法を示します。これは、OCIコンソールでOracle Databaseサービスを使用するのではなく、コンピュート・インスタンスにOracle DatabaseおよびData Guardを手動でインストールすることを選択したユースケースも示しています。これは、非移動コンピュートを使用する理由と方法を示す単純な例ですが、Full Stack Disaster Recovery内のOracleデータベースの組込みサポートを利用していません。

この例では、合計4つのコンピュート・インスタンスを使用しています。

  • 2つの標準コンピュート・インスタンスは、リージョン間の移動を許容するアプリケーションの「移動」サーバーとして機能します。
    • これらのサーバーにインストールされる可能性のあるアプリケーションの例としては、バイナリまたは構成ファイルでステートフル、リージョン固有、ハードコードされた値を保持せず、別のIPアドレスとマイナーを持つ別のリージョンでの起動を容易に許容できるもの、または起動時の構成ファイルの変更がないものがあります。
    • これらのコンピュート・インスタンスは、プライマリDR保護グループのメンバーのみになります。
  • 1つの標準コンピュート・インスタンスは、移動しないアクティブなアプリケーション・サーバーとして機能します。
    • このコンピュート・インスタンスはリージョン1にのみ存在し、リージョン2には存在しません。
    • アプリケーションはリージョン1にインストールされ、実行されています。
    • このコンピュート・インスタンスは、プライマリDR保護グループのメンバーのみになります。
  • 1つの標準コンピュート・インスタンスは、移動しない非アクティブなアプリケーション・サーバーとして機能します。
    • このコンピュート・インスタンスはリージョン2にのみ存在し、リージョン1には存在しません。
    • アプリケーションはインストールされていますが、リージョン2では実行されていません。
    • このコンピュート・インスタンスは、スタンバイDR保護グループのメンバーのみになります。

コスト見積りには、各リージョンのIaaSおよびPaaSリソースのOCPUおよびECPUの合計数をプラグインする6つのフィールドが含まれています。次の表に、原価見積機能で入力する6つのフィールドを示します。フィールドの値は、2つのOCIリージョンにまたがるディザスタ・リカバリ用にデプロイされた架空のアプリケーション・スタックを表す次の表に示す詳細に基づいています。ユーザーがインストールおよび管理するデータベースに関連するコストはありません。かわりに、データベースおよびData Guardをホストする仮想マシンによって消費されるOPCUによってコストが考慮されます。

プライマリOCIリージョン/保護グループ

表A-20プライマリOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
14 16 0
スタンバイOCIリージョン/保護グループ

表A-21スタンバイOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
2 16 0
メトリック合計

表A-22メトリック合計

OCIフル・スタックDR (OCPU) OCIフルスタックDR(ECPU)
48 0

プライマリDR保護グループのCPU

プライマリ・リージョン(リージョン1)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

次の表に、プライマリ・リージョンに存在する、またはプライマリ・リージョンに存在するIaaSおよびPaaSリソースの例を示します。次の表の最後の行のCPU合計は、上のコスト試算ツールの例に示されている数字です。

プライマリDR保護グループのCPU

表A-23プライマリDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server01 4    
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server02 8    
プライマリ コンピュート・インスタンス(非移動)
  • お客様は、Oracle Siebel CRM、PeopleSoft、JD Edwards EnterpriseOne、Oracle E-business SuiteなどのOracleアプリケーションをインストールおよび管理できます。
  • アプリケーションをアクティブに実行中
 MyApp02Server01 2    
プライマリ Oracle Database
  • MyApp02Server01で実行されているOracleアプリケーションのプライマリ・データベース
  • Exadata VMクラスタ
  • プライマリ・ロールのData Guard
  • VMクラスタに割り当てられている合計64個のOCPU
  • VMクラスタでプロビジョニングされた4つのデータベース
  • データベース当たり16 OCPU: (64/4 = 各データベース当たり16 OCPU)
 MyExaDatabase03   16  
プライマリ ロード・バランサ
  • バックエンド・セット1がアクティブです
  • バックエンド・セット2がアクティブです
 MyLoadBalancerRegion1 請求なし 請求なし 請求なし
プライマリ ブロック・ボリューム・グループ
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01のブート・ボリュームが含まれます。
  • MyApp01Server02のブート・ボリュームが含まれます。
 MyVG00 請求なし 請求なし 請求なし
プライマリ ファイル・システム
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01およびMyApp01Server02にマウントされた/myscriptsのファイル・システムが含まれます。
 myscripts 請求なし 請求なし 請求なし
プライマリ プライマリ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   14 16 0
スタンバイDR保護グループのCPU

スタンバイ・リージョン(リージョン2)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

この例では、常に単一のリージョンにのみ存在する移動コンピュートのみが含まれます。したがって、スタンバイ保護グループにはチャージ可能なメンバー・リソースがないため、スタンバイ・リージョンのフル・スタック・ディザスタ・リカバリの料金は発生しません。

スタンバイDR保護グループのCPU

表A-24スタンバイDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
スタンバイ コンピュート・インスタンス(非移動)
  • お客様は、Oracle Siebel CRM、PeopleSoft、JD Edwards EnterpriseOne、Oracle E-business SuiteなどのOracleアプリケーションをインストールおよび管理できます。
  • アプリケーションはインストールされていますが、実行されていません
 MyApp02Server02 2 0 0
スタンバイ Oracle Database
  • MyApp02Server02で実行されているOracleアプリケーションのスタンバイ・データベース
  • Exadata VMクラスタ
  • スタンバイ・ロールのData Guard
  • VMクラスタに割り当てられている合計64個のOCPU
  • VMクラスタでプロビジョニングされた4つのデータベース
  • データベース当たり16 OCPU: (64/4 = 各データベース当たり16 OCPU)
 MyExaDatabase03   16  
スタンバイ ロード・バランサ
  • バックエンド・セット1はアクティブではなく、移入されていません
  • バックエンド・セット2notはアクティブであり、移入されていません
 MyLoadBalancerRegion2 請求なし 請求なし 請求なし
スタンバイ スタンバイ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   2 16 0

例4: OKE、データベース、コンピュートおよび非移動コンピュートを含むアプリケーション・スタック

次の例は、2つのOCIリージョンにデプロイされた架空のビジネス・システムを示しています。アプリケーション・スタックの一部であるIaaSおよびPaaSサービスに応じて、すべての顧客に異なるものがあります。

この例では、Oracle Kubernetes Engineクラスタ(OKE)でホストされるワーカー・ノードを含むビジネス・システムのFull Stack DRの価格設定、および両方のリージョンのDR保護グループのメンバーとしての移動および移動以外のコンピュートの設定方法を示します。これは、リソース・プランニング、財務、倉庫管理、サプライ・チェーン管理、顧客関係管理、営業ポータルなど、OracleまたはOracle以外のアプリケーションのアプリケーション・スタックをホストする可能性のあるビジネス・システムのより一般的なデプロイメント・アーキテクチャの小規模な例です。The moving compute might be used to host Oracle or non-Oracle applications that can function with minimal modifications when brought up in a different region.非移動コンピュートは通常、機能しないOracleまたは非Oracle applicationsをホストするため、または別のリージョンで起動したときにまったく機能するように簡単に変更するために使用されます。Examples of applications that might be installed on non-moving compute are Oracle applications such as PeopleSoft, JD Edwards EnterpriseOne, Oracle Siebel CRM, Oracle E-Business Suite, Oracle WebLogic Server, and so on.これらのアプリケーションは、プライマリ・リージョンの仮想マシンにインストールしてアクティブに実行し、インストールする必要がありますが、スタンバイ・リージョンで実行されている仮想マシンではアクティブではありません。

この例では、合計4つの標準コンピュート・インスタンス、4つのOKEワーカー・ノード、および1つのDR計画実行でリカバリされるAutonomous Database、ベース・データベースおよびExadataを含む複数の異なるOracleデータベースを使用します。

  • 2つの標準コンピュート・インスタンスは、リージョン間の移動を許容するアプリケーションの「移動」サーバーとして機能します。
    • これらのサーバーにインストールされる可能性のあるアプリケーションの例としては、バイナリまたは構成ファイルでステートフル、リージョン固有、ハードコードされた値を保持せず、別のIPアドレスとマイナーを持つ別のリージョンでの起動を容易に許容できるもの、または起動時の構成ファイルの変更がないものがあります。
    • これらのコンピュート・インスタンスは、プライマリDR保護グループのメンバーのみになります。
  • 1つの標準コンピュート・インスタンスは、移動しないアクティブなアプリケーション・サーバーとして機能します。
    • このコンピュート・インスタンスはリージョン1にのみ存在し、リージョン2には存在しません。
    • アプリケーションはリージョン1にインストールされ、実行されています。
    • このコンピュート・インスタンスは、プライマリDR保護グループのメンバーのみになります。
  • 1つの標準コンピュート・インスタンスは、移動しない非アクティブなアプリケーション・サーバーとして機能します。
    • このコンピュート・インスタンスはリージョン2にのみ存在し、リージョン1には存在しません。
    • アプリケーションはインストールされていますが、リージョン2では実行されていません。
    • このコンピュート・インスタンスは、スタンバイDR保護グループのメンバーのみになります。
  • リカバリが必要なアプリケーション・ワークロードをホストするOKEクラスタ内の4つのワーカー・ノード。
    • プライマリ・リージョンOKEクラスタ内の4つのワーカー・ノード(常にプライマリDR保護グループのメンバーのまま)。
    • スタンバイ・リージョンOKEクラスタ内の4つのワーカー・ノード(常にスタンバイDR保護グループのメンバーのまま)。
  • Data Guardを使用する4つのOCI Oracleデータベースは、さまざまなアプリケーションをサポートするOCIコンソールを使用してすでに有効になっています。
    • 4つのプライマリ・データベースは、プライマリDR保護グループのメンバーのみになります。
    • 4つのスタンバイ・データベースは、スタンバイDR保護グループのメンバーのみになります。

コスト見積りには、各リージョンのIaaSおよびPaaSリソースのOCPUおよびECPUの合計数をプラグインする6つのフィールドが含まれています。次の表に、原価見積機能で入力する6つのフィールドを示します。フィールドの値は、2つのOCIリージョンにまたがるディザスタ・リカバリ用にデプロイされた架空のアプリケーション・スタックを表す次の表に示す詳細に基づいています。

プライマリOCIリージョン/保護グループ

表A-25プライマリOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
22 24 20
スタンバイOCIリージョン/保護グループ

表A-26 スタンバイOCIリージョン/保護グループ

合計コンピュート・メンバーOCPU 合計データベース・メンバーOCPU 合計データベース・メンバーECPU
10 24 20

メトリック合計

表A-27 メトリック合計

OCIフル・スタックDR (OCPU) 合計データベース・メンバーOCPU
80 40

プライマリDR保護グループのCPU

プライマリ・リージョン(リージョン1)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

次の表に、プライマリ・リージョンに存在する、またはプライマリ・リージョンに存在するIaaSおよびPaaSリソースの例を示します。次の表の最後の行のCPU合計は、上のコスト試算ツールの例に示されている数字です。

表A-28プライマリDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server01 4    
プライマリ コンピュート・インスタンス(移動)
  • お客様がOracle以外のアプリケーションをインストールおよび管理
  • カスタマ・ポータル用のApache Webサーバー
  • アプリケーションをアクティブに実行中
 MyApp01Server02 8    
プライマリ コンピュート・インスタンス(非移動)
  • お客様は、Oracle Siebel CRM、PeopleSoft、JD Edwards EnterpriseOne、Oracle E-business SuiteなどのOracleアプリケーションをインストールおよび管理できます。
  • アプリケーションをアクティブに実行中
 MyApp02Server01 2    
プライマリ OKEクラスタ: 4つのワーカー・ノード(それぞれ2 OCPU) MyOKECluster01 8    
プライマリ Oracle Database:
  • ベース・データベース
  • プライマリ・ロールのData Guard
 MyEEDatabase01   8  
プライマリ Oracle Database:
  • MyApp02Server01で実行されているOracleアプリケーションのプライマリ・データベース
  • Exadata VMクラスタ
  • プライマリ・ロールのData Guard
  • VMクラスタに割り当てられている合計64個のOCPU
  • VMクラスタでプロビジョニングされた4つのデータベース
  • データベース当たり16 OCPU: (64/4 = 各データベース当たり16 OCPU)
 MyExaDatabase03   16  
プライマリ Autonomous Database
  • 専用インフラストラクチャ
  • プライマリ・ロールでのAutonomous Data Guard
 MyADB01     16
プライマリ Autonomous Database
  • サーバーレス・インフラストラクチャ
  • プライマリ・ロールでのAutonomous Data Guard
 MyADW01     4
プライマリ ロード・バランサ
  • バックエンド・セット1がアクティブです
  • バックエンド・セット2がアクティブです
 MyLoadBalancerRegion1 請求なし 請求なし 請求なし
プライマリ ブロック・ボリューム・グループ
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01のブート・ボリュームが含まれます。
  • MyApp01Server02のブート・ボリュームが含まれます。
 MyVG00 請求なし 請求なし 請求なし
プライマリ ブロック・ボリューム・グループ:
  • アクティブ
  • リージョン2にレプリケートされました
  • /u02 onMyApp02Server01のブロック・ボリュームが含まれます。
  • リカバリ中にregion2のMyApp02Server02で/u02に再マウントされます。
 MyVG01 請求なし 請求なし 請求なし
プライマリ ファイル・システム:
  • アクティブ
  • リージョン2にレプリケートされました
  • MyApp01Server01およびMyApp01Server02にマウントされた/myscriptsのファイル・システムが含まれます。
 myscripts 請求なし 請求なし 請求なし
プライマリ プライマリ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   22 24 20

スタンバイDR保護グループのCPU

スタンバイ・リージョン(リージョン2)のDR保護グループのメンバーであるコンピュート・インスタンスまたはデータベースによって消費されたすべてのCPUを合計します。

スタンバイ・リージョンに現在存在するメンバー・リソースのみを含めます。DR操作後にリソースが存在する場所を計算する必要はありません。現在の通常の動作状態にあるリソースを追加するだけです。プライマリ・リージョン内の移動コンピュートは、スタンバイDR保護グループのメンバーとして含まれないため、スタンバイ・リージョン内の移動コンピュートに対するOCPU料金はありません。

表A-29スタンバイDR保護グループのCPU

DR保護グループ メンバー・リソース 説明 コンピュートOCPU数 データベースOCPU数 データベースECPU数
スタンバイ コンピュート・インスタンス(非移動)
  • お客様は、Oracle Siebel CRM、PeopleSoft、JD Edwards EnterpriseOne、Oracle E-business SuiteなどのOracleアプリケーションをインストールおよび管理できます。
  • アプリケーションはインストールされていますが、実行されていません
 MyApp02Server02 2    
スタンバイ OKEクラスタ: 4つのワーカー・ノード(それぞれ2 OCPU) MyOKECluster01 8    
スタンバイ Oracle Database:
  • ベース・データベース
  • スタンバイ・ロールのData Guard
, 		MyEEDatabase01   8  
スタンバイ Oracle Database:
  • MyApp02Server02で実行されているOracleアプリケーションのスタンバイ・データベース
  • Exadata VMクラスタ
  • スタンバイ・ロールのData Guard
  • VMクラスタに割り当てられている合計64個のOCPU
  • VMクラスタでプロビジョニングされた4つのデータベース
  • データベース当たり16 OCPU: (64/4 = 各データベース当たり16 OCPU)
 MyExaDatabase03   16  
スタンバイ Autonomous Database:
  • 専用インフラストラクチャ
  • スタンバイ・ロールのData Guard
 MyADB01     16
スタンバイ Autonomous Database:
  • サーバーレス・インフラストラクチャ
  • スタンバイ・ロールのData Guard
 MyADW01     4
スタンバイ ロード・バランサ:
  • バックエンド・セット1はアクティブではなく、移入されていません
  • バックエンド・セット2notはアクティブであり、移入されていません
 MyLoadBalancerRegion2 請求なし   請求なし
スタンバイ スタンバイ・リージョンのメンバー・リソースのすべてのOCPUおよびECPUの合計   10 24 20

親トピック: リファレンス