oracle cloud infrastructure での 災害復旧のベスト …...3 | best practices for disaster...

25
Oracle Cloud Infrastructure での 災害復旧のベスト・プラクティス ORACLE WHITE PAPER | 2019 1

Upload: others

Post on 25-Jun-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

Oracle Cloud Infrastructureでの

災害復旧のベストプラクティス

O R A C L E W H I T E P A P E R | 2 0 1 9 年 1 月

2 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

免責事項

以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供

を唯一の目的とするものでありいかなる契約にも組み込むことはできませんマテリアルや

コード機能を提供することをコミットメント(確約)するものではないため購買決定を行う際

の判断材料になさらないで下さいオラクル製品に関して記載されている機能の開発リリース

および時期については弊社の裁量により決定されます

改訂履歴

このホワイトペーパーには初版発行以来次の改訂が加えられています

更新日 改訂内容

2019年 1月 4日 フォルトドメインに関する情報を追加

ストレージサービスにおけるデータの耐久性に関する情報を追加

可用性ドメインを 1つ含む単一リージョンの DR戦略を追加

リージョン間でのデータベースの同期に関する情報を追加

2018年 8月 31日 初版発行

Oracle Cloud Infrastructureホワイトペーパーの最新版はhttpscloudoraclecomiaastechnical-

resourcesでご覧いただけます

3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

目次

免責事項 2

改訂履歴 2

概要 5

災害復旧の概念 5

Oracle Cloud Infrastructureでの DRの基盤となるサービス 5

リージョン可用性ドメインおよびフォルトドメイン 5

コンピュート 7

ストレージ 7

ネットワーキング 8

データベース 9

Oracle Cloud Infrastructureでの一般的な災害シナリオ 9

アプリケーション障害 9

ネットワーク障害 10

データセンター障害 10

リージョン障害(自然災害) 10

DRのためのデプロイメント戦略 10

可用性ドメインを 1つ含む単一リージョン 10

複数の可用性ドメインを含む単一リージョン 11

クロスリージョン 12

災害復旧ソリューション 14

バックアップとリストア 14

パイロットライト 16

4 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ 17

災害復旧のためのデータベース戦略 17

Active Data Guard 17

Oracle GoldenGate 20

Active Data Guardと GoldenGateの両方を使用 23

災害復旧のプランニング 23

自動化 23

障害検出 23

災害復旧のテスト 24

結論 24

参考資料 24

5 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

概要

災害復旧(DR)とはアプリケーションを災害から保護するプロセスです災害とはアプリケー

ションを危険にさらす出来事のことでありネットワークの停止から機器の障害や自然災害まで

多岐にわたります予期しない災害が発生した場合でも適切に設計されたDRプランがあれば

可能なかぎり迅速にアプリケーションをリカバリするとともにユーザーへのサービス提供を継

続することができます

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで高速なアプリケーションのDRを実現しま

すこのホワイトペーパーではOracle Cloud InfrastructureでのアプリケーションDRを設計し

実装する方法についてのベストプラクティスを概説します

災害復旧の概念

DRのプランニングを理解するにはよく使われる2つの用語を理解することが重要ですそれは

リカバリ時間目標(RTO)とリカバリポイント目標(RPO)です

RTOとは災害発生後アプリケーション機能をリストアするのに必要な目標時間で

すRTOの目的はどの程度迅速に災害から復旧する必要があるかを評価することで

す一般にアプリケーションの重要性が高ければ高いほどRTOは短くなります

RPOとはアプリケーションが耐えられるデータ損失の許容期間ですRPOの目的

は災害シナリオにおいてアプリケーションが失っても大丈夫なデータの量を示すこと

です

災害後もアプリケーションが存続することを保証しかつコスト効果にも優れたDRプランを策定

するにはRTOとRPOの両方を考慮しなければなりませんRTOとRPO両方の目的を達成し

てアプリケーションを災害から効果的にリカバリできるようにしてください

Oracle Cloud InfrastructureでのDRの基盤となるサービス

Oracle Cloud InfrastructureでのDRソリューションを設計し実装するにはOracle Cloud

Infrastructureのどの機能やサービスに信頼性が高くセキュアでコスト効果に優れたDRを実現す

る機能が組み込まれているかを知ることが重要です

リージョン可用性ドメインおよびフォルトドメイン

Oracle Cloud Infrastructureのリージョンとはいくつかの可用性ドメインで構成される局地的な

地域です可用性ドメインにはいくつかのフォルトドメインがあります

6 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

リージョンは相互に独立しており膨大な距離で隔てられて国や大陸をまたがる場合も

ありますアプリケーションを異なるリージョンにデプロイすればリージョン全体に

及ぶ事象(大規模な気象状況や地震など)のリスクを軽減することができます

可用性ドメインとはリージョン内に位置する 1つ以上のデータセンターです可用

性ドメインは相互に分離されフォルトトレラントで複数の可用性ドメインが同時

に障害を起こすことはほぼありません可用性ドメインは電源や冷却装置内部可用性

ドメインネットワークなどの物理インフラストラクチャを共有しないためある可用

性ドメインに影響を及ぼす障害が他の可用性ドメインに影響を及ぼす可能性は低くなり

ますリージョン内の可用性ドメインは低レイテンシ高帯域幅のネットワークで相

互に接続されています可用性ドメイン間のこの予測可能な暗号化された相互接続は

高可用性(HA)と DRの両方を実現するための構成要素となります

フォルトドメインとは可用性ドメイン内のハードウェアとインフラストラクチャを

グループ化したものです各可用性ドメインに 3つのフォルトドメインが含まれてい

ますフォルトドメインによってインスタンスを分散させ単一の可用性ドメイン内

の同じ物理ハードウェアにインスタンスが集中するのを避けることができますそのた

めあるフォルトドメインに影響を及ぼすハードウェア障害やメンテナンスイベン

トが他のフォルトドメイン内のインスタンスに影響を及ぼすことはありません新規

インスタンスのフォルトドメインを運用開始時に指定することもフォルトドメイ

ンが自動的に選択されるようにすることも可能です

7 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

コンピュート

Oracle Cloud Infrastructure Computeサービスはパフォーマンス柔軟性およびコントロールを

備えたベアメタルと仮想マシン両方のコンピュートインスタンスを提供しますこのサービ

スの原動力となるのがオラクルによるインターネット規模の次世代インフラストラクチャで

最も要求の厳しいアプリケーションやワークロードをクラウド上で開発実行できるように設計

されています

DRの観点からコンピュートインスタンスは複数の可用性ドメインまたはフォルトドメイン

にまたがるようにデプロイしてアプリケーションを停止から保護することをお薦めします

Computeサービスではイメージのインポートエクスポート機能を使用してカスタムイメー

ジをテナント間やリージョン間で共有することができます

ストレージ

Oracle Cloud Infrastructure Object Storageサービスはインターネット規模の高パフォーマンス

なストレージプラットフォームで信頼性が高くコスト効率のよいデータ耐久性を提供しま

すObject Storageを使用するとデータの格納や取出しを直接インターネットからあるいは

クラウドプラットフォーム内から安全かつセキュアに行うことができますこのプラット

フォームは柔軟性に優れているので小さく始めてシームレスに拡張することができパフォー

マンスやサービスの信頼性の低下を感じさせることはありません

Object Storageに格納されたデータはバックアップの必要がありませんObject Storageは本質

的に耐久性の高いストレージプラットフォームですすべてのオブジェクトがリージョン内の

複数のストレージサーバーに重複して格納されますチェックサムを使用してデータの整合性

が常に監視され破損したデータは自動的に修復されますこうしたオブジェクトストレージ

固有の耐久性特性により従来のバックアップの必要性はほぼなくなりますObject Storageは

信頼性が高く999の可用性を実現できるように設計されています

Storage Gatewayはオンプレミスのアプリケーションをオラクルのクラウドに接続できるよう

にするクラウドストレージゲートウェイですコスト効果の高いバックアップソリュー

ションとしてStorage Gatewayを使用しOracle Cloud Infrastructure Archive Storageにファイ

ルを移動することができます個別のファイルを移動することも圧縮済または無圧縮のzipアー

カイブやtarアーカイブを移動することも可能ですデータのセカンダリコピーを格納するとい

うのがStorage Gatewayの理想的なユースケースですStorage Gatewayを使用すると従来の

アプリケーションのデータを耐久性の高いオブジェクトストレージに移動できますデータの

リカバリが必要になった場合はStorage Gatewayの新しいインスタンスが作成されてデータ

を簡単にリカバリできます

Oracle Cloud Infrastructure Block Volumesサービスではブロックストレージボリュームを

動的にプロビジョニングし管理することが可能ですボリュームの作成アタッチ接続移

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 2: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

2 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

免責事項

以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供

を唯一の目的とするものでありいかなる契約にも組み込むことはできませんマテリアルや

コード機能を提供することをコミットメント(確約)するものではないため購買決定を行う際

の判断材料になさらないで下さいオラクル製品に関して記載されている機能の開発リリース

および時期については弊社の裁量により決定されます

改訂履歴

このホワイトペーパーには初版発行以来次の改訂が加えられています

更新日 改訂内容

2019年 1月 4日 フォルトドメインに関する情報を追加

ストレージサービスにおけるデータの耐久性に関する情報を追加

可用性ドメインを 1つ含む単一リージョンの DR戦略を追加

リージョン間でのデータベースの同期に関する情報を追加

2018年 8月 31日 初版発行

Oracle Cloud Infrastructureホワイトペーパーの最新版はhttpscloudoraclecomiaastechnical-

resourcesでご覧いただけます

3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

目次

免責事項 2

改訂履歴 2

概要 5

災害復旧の概念 5

Oracle Cloud Infrastructureでの DRの基盤となるサービス 5

リージョン可用性ドメインおよびフォルトドメイン 5

コンピュート 7

ストレージ 7

ネットワーキング 8

データベース 9

Oracle Cloud Infrastructureでの一般的な災害シナリオ 9

アプリケーション障害 9

ネットワーク障害 10

データセンター障害 10

リージョン障害(自然災害) 10

DRのためのデプロイメント戦略 10

可用性ドメインを 1つ含む単一リージョン 10

複数の可用性ドメインを含む単一リージョン 11

クロスリージョン 12

災害復旧ソリューション 14

バックアップとリストア 14

パイロットライト 16

4 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ 17

災害復旧のためのデータベース戦略 17

Active Data Guard 17

Oracle GoldenGate 20

Active Data Guardと GoldenGateの両方を使用 23

災害復旧のプランニング 23

自動化 23

障害検出 23

災害復旧のテスト 24

結論 24

参考資料 24

5 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

概要

災害復旧(DR)とはアプリケーションを災害から保護するプロセスです災害とはアプリケー

ションを危険にさらす出来事のことでありネットワークの停止から機器の障害や自然災害まで

多岐にわたります予期しない災害が発生した場合でも適切に設計されたDRプランがあれば

可能なかぎり迅速にアプリケーションをリカバリするとともにユーザーへのサービス提供を継

続することができます

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで高速なアプリケーションのDRを実現しま

すこのホワイトペーパーではOracle Cloud InfrastructureでのアプリケーションDRを設計し

実装する方法についてのベストプラクティスを概説します

災害復旧の概念

DRのプランニングを理解するにはよく使われる2つの用語を理解することが重要ですそれは

リカバリ時間目標(RTO)とリカバリポイント目標(RPO)です

RTOとは災害発生後アプリケーション機能をリストアするのに必要な目標時間で

すRTOの目的はどの程度迅速に災害から復旧する必要があるかを評価することで

す一般にアプリケーションの重要性が高ければ高いほどRTOは短くなります

RPOとはアプリケーションが耐えられるデータ損失の許容期間ですRPOの目的

は災害シナリオにおいてアプリケーションが失っても大丈夫なデータの量を示すこと

です

災害後もアプリケーションが存続することを保証しかつコスト効果にも優れたDRプランを策定

するにはRTOとRPOの両方を考慮しなければなりませんRTOとRPO両方の目的を達成し

てアプリケーションを災害から効果的にリカバリできるようにしてください

Oracle Cloud InfrastructureでのDRの基盤となるサービス

Oracle Cloud InfrastructureでのDRソリューションを設計し実装するにはOracle Cloud

Infrastructureのどの機能やサービスに信頼性が高くセキュアでコスト効果に優れたDRを実現す

る機能が組み込まれているかを知ることが重要です

リージョン可用性ドメインおよびフォルトドメイン

Oracle Cloud Infrastructureのリージョンとはいくつかの可用性ドメインで構成される局地的な

地域です可用性ドメインにはいくつかのフォルトドメインがあります

6 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

リージョンは相互に独立しており膨大な距離で隔てられて国や大陸をまたがる場合も

ありますアプリケーションを異なるリージョンにデプロイすればリージョン全体に

及ぶ事象(大規模な気象状況や地震など)のリスクを軽減することができます

可用性ドメインとはリージョン内に位置する 1つ以上のデータセンターです可用

性ドメインは相互に分離されフォルトトレラントで複数の可用性ドメインが同時

に障害を起こすことはほぼありません可用性ドメインは電源や冷却装置内部可用性

ドメインネットワークなどの物理インフラストラクチャを共有しないためある可用

性ドメインに影響を及ぼす障害が他の可用性ドメインに影響を及ぼす可能性は低くなり

ますリージョン内の可用性ドメインは低レイテンシ高帯域幅のネットワークで相

互に接続されています可用性ドメイン間のこの予測可能な暗号化された相互接続は

高可用性(HA)と DRの両方を実現するための構成要素となります

フォルトドメインとは可用性ドメイン内のハードウェアとインフラストラクチャを

グループ化したものです各可用性ドメインに 3つのフォルトドメインが含まれてい

ますフォルトドメインによってインスタンスを分散させ単一の可用性ドメイン内

の同じ物理ハードウェアにインスタンスが集中するのを避けることができますそのた

めあるフォルトドメインに影響を及ぼすハードウェア障害やメンテナンスイベン

トが他のフォルトドメイン内のインスタンスに影響を及ぼすことはありません新規

インスタンスのフォルトドメインを運用開始時に指定することもフォルトドメイ

ンが自動的に選択されるようにすることも可能です

7 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

コンピュート

Oracle Cloud Infrastructure Computeサービスはパフォーマンス柔軟性およびコントロールを

備えたベアメタルと仮想マシン両方のコンピュートインスタンスを提供しますこのサービ

スの原動力となるのがオラクルによるインターネット規模の次世代インフラストラクチャで

最も要求の厳しいアプリケーションやワークロードをクラウド上で開発実行できるように設計

されています

DRの観点からコンピュートインスタンスは複数の可用性ドメインまたはフォルトドメイン

にまたがるようにデプロイしてアプリケーションを停止から保護することをお薦めします

Computeサービスではイメージのインポートエクスポート機能を使用してカスタムイメー

ジをテナント間やリージョン間で共有することができます

ストレージ

Oracle Cloud Infrastructure Object Storageサービスはインターネット規模の高パフォーマンス

なストレージプラットフォームで信頼性が高くコスト効率のよいデータ耐久性を提供しま

すObject Storageを使用するとデータの格納や取出しを直接インターネットからあるいは

クラウドプラットフォーム内から安全かつセキュアに行うことができますこのプラット

フォームは柔軟性に優れているので小さく始めてシームレスに拡張することができパフォー

マンスやサービスの信頼性の低下を感じさせることはありません

Object Storageに格納されたデータはバックアップの必要がありませんObject Storageは本質

的に耐久性の高いストレージプラットフォームですすべてのオブジェクトがリージョン内の

複数のストレージサーバーに重複して格納されますチェックサムを使用してデータの整合性

が常に監視され破損したデータは自動的に修復されますこうしたオブジェクトストレージ

固有の耐久性特性により従来のバックアップの必要性はほぼなくなりますObject Storageは

信頼性が高く999の可用性を実現できるように設計されています

Storage Gatewayはオンプレミスのアプリケーションをオラクルのクラウドに接続できるよう

にするクラウドストレージゲートウェイですコスト効果の高いバックアップソリュー

ションとしてStorage Gatewayを使用しOracle Cloud Infrastructure Archive Storageにファイ

ルを移動することができます個別のファイルを移動することも圧縮済または無圧縮のzipアー

カイブやtarアーカイブを移動することも可能ですデータのセカンダリコピーを格納するとい

うのがStorage Gatewayの理想的なユースケースですStorage Gatewayを使用すると従来の

アプリケーションのデータを耐久性の高いオブジェクトストレージに移動できますデータの

リカバリが必要になった場合はStorage Gatewayの新しいインスタンスが作成されてデータ

を簡単にリカバリできます

Oracle Cloud Infrastructure Block Volumesサービスではブロックストレージボリュームを

動的にプロビジョニングし管理することが可能ですボリュームの作成アタッチ接続移

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 3: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

目次

免責事項 2

改訂履歴 2

概要 5

災害復旧の概念 5

Oracle Cloud Infrastructureでの DRの基盤となるサービス 5

リージョン可用性ドメインおよびフォルトドメイン 5

コンピュート 7

ストレージ 7

ネットワーキング 8

データベース 9

Oracle Cloud Infrastructureでの一般的な災害シナリオ 9

アプリケーション障害 9

ネットワーク障害 10

データセンター障害 10

リージョン障害(自然災害) 10

DRのためのデプロイメント戦略 10

可用性ドメインを 1つ含む単一リージョン 10

複数の可用性ドメインを含む単一リージョン 11

クロスリージョン 12

災害復旧ソリューション 14

バックアップとリストア 14

パイロットライト 16

4 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ 17

災害復旧のためのデータベース戦略 17

Active Data Guard 17

Oracle GoldenGate 20

Active Data Guardと GoldenGateの両方を使用 23

災害復旧のプランニング 23

自動化 23

障害検出 23

災害復旧のテスト 24

結論 24

参考資料 24

5 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

概要

災害復旧(DR)とはアプリケーションを災害から保護するプロセスです災害とはアプリケー

ションを危険にさらす出来事のことでありネットワークの停止から機器の障害や自然災害まで

多岐にわたります予期しない災害が発生した場合でも適切に設計されたDRプランがあれば

可能なかぎり迅速にアプリケーションをリカバリするとともにユーザーへのサービス提供を継

続することができます

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで高速なアプリケーションのDRを実現しま

すこのホワイトペーパーではOracle Cloud InfrastructureでのアプリケーションDRを設計し

実装する方法についてのベストプラクティスを概説します

災害復旧の概念

DRのプランニングを理解するにはよく使われる2つの用語を理解することが重要ですそれは

リカバリ時間目標(RTO)とリカバリポイント目標(RPO)です

RTOとは災害発生後アプリケーション機能をリストアするのに必要な目標時間で

すRTOの目的はどの程度迅速に災害から復旧する必要があるかを評価することで

す一般にアプリケーションの重要性が高ければ高いほどRTOは短くなります

RPOとはアプリケーションが耐えられるデータ損失の許容期間ですRPOの目的

は災害シナリオにおいてアプリケーションが失っても大丈夫なデータの量を示すこと

です

災害後もアプリケーションが存続することを保証しかつコスト効果にも優れたDRプランを策定

するにはRTOとRPOの両方を考慮しなければなりませんRTOとRPO両方の目的を達成し

てアプリケーションを災害から効果的にリカバリできるようにしてください

Oracle Cloud InfrastructureでのDRの基盤となるサービス

Oracle Cloud InfrastructureでのDRソリューションを設計し実装するにはOracle Cloud

Infrastructureのどの機能やサービスに信頼性が高くセキュアでコスト効果に優れたDRを実現す

る機能が組み込まれているかを知ることが重要です

リージョン可用性ドメインおよびフォルトドメイン

Oracle Cloud Infrastructureのリージョンとはいくつかの可用性ドメインで構成される局地的な

地域です可用性ドメインにはいくつかのフォルトドメインがあります

6 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

リージョンは相互に独立しており膨大な距離で隔てられて国や大陸をまたがる場合も

ありますアプリケーションを異なるリージョンにデプロイすればリージョン全体に

及ぶ事象(大規模な気象状況や地震など)のリスクを軽減することができます

可用性ドメインとはリージョン内に位置する 1つ以上のデータセンターです可用

性ドメインは相互に分離されフォルトトレラントで複数の可用性ドメインが同時

に障害を起こすことはほぼありません可用性ドメインは電源や冷却装置内部可用性

ドメインネットワークなどの物理インフラストラクチャを共有しないためある可用

性ドメインに影響を及ぼす障害が他の可用性ドメインに影響を及ぼす可能性は低くなり

ますリージョン内の可用性ドメインは低レイテンシ高帯域幅のネットワークで相

互に接続されています可用性ドメイン間のこの予測可能な暗号化された相互接続は

高可用性(HA)と DRの両方を実現するための構成要素となります

フォルトドメインとは可用性ドメイン内のハードウェアとインフラストラクチャを

グループ化したものです各可用性ドメインに 3つのフォルトドメインが含まれてい

ますフォルトドメインによってインスタンスを分散させ単一の可用性ドメイン内

の同じ物理ハードウェアにインスタンスが集中するのを避けることができますそのた

めあるフォルトドメインに影響を及ぼすハードウェア障害やメンテナンスイベン

トが他のフォルトドメイン内のインスタンスに影響を及ぼすことはありません新規

インスタンスのフォルトドメインを運用開始時に指定することもフォルトドメイ

ンが自動的に選択されるようにすることも可能です

7 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

コンピュート

Oracle Cloud Infrastructure Computeサービスはパフォーマンス柔軟性およびコントロールを

備えたベアメタルと仮想マシン両方のコンピュートインスタンスを提供しますこのサービ

スの原動力となるのがオラクルによるインターネット規模の次世代インフラストラクチャで

最も要求の厳しいアプリケーションやワークロードをクラウド上で開発実行できるように設計

されています

DRの観点からコンピュートインスタンスは複数の可用性ドメインまたはフォルトドメイン

にまたがるようにデプロイしてアプリケーションを停止から保護することをお薦めします

Computeサービスではイメージのインポートエクスポート機能を使用してカスタムイメー

ジをテナント間やリージョン間で共有することができます

ストレージ

Oracle Cloud Infrastructure Object Storageサービスはインターネット規模の高パフォーマンス

なストレージプラットフォームで信頼性が高くコスト効率のよいデータ耐久性を提供しま

すObject Storageを使用するとデータの格納や取出しを直接インターネットからあるいは

クラウドプラットフォーム内から安全かつセキュアに行うことができますこのプラット

フォームは柔軟性に優れているので小さく始めてシームレスに拡張することができパフォー

マンスやサービスの信頼性の低下を感じさせることはありません

Object Storageに格納されたデータはバックアップの必要がありませんObject Storageは本質

的に耐久性の高いストレージプラットフォームですすべてのオブジェクトがリージョン内の

複数のストレージサーバーに重複して格納されますチェックサムを使用してデータの整合性

が常に監視され破損したデータは自動的に修復されますこうしたオブジェクトストレージ

固有の耐久性特性により従来のバックアップの必要性はほぼなくなりますObject Storageは

信頼性が高く999の可用性を実現できるように設計されています

Storage Gatewayはオンプレミスのアプリケーションをオラクルのクラウドに接続できるよう

にするクラウドストレージゲートウェイですコスト効果の高いバックアップソリュー

ションとしてStorage Gatewayを使用しOracle Cloud Infrastructure Archive Storageにファイ

ルを移動することができます個別のファイルを移動することも圧縮済または無圧縮のzipアー

カイブやtarアーカイブを移動することも可能ですデータのセカンダリコピーを格納するとい

うのがStorage Gatewayの理想的なユースケースですStorage Gatewayを使用すると従来の

アプリケーションのデータを耐久性の高いオブジェクトストレージに移動できますデータの

リカバリが必要になった場合はStorage Gatewayの新しいインスタンスが作成されてデータ

を簡単にリカバリできます

Oracle Cloud Infrastructure Block Volumesサービスではブロックストレージボリュームを

動的にプロビジョニングし管理することが可能ですボリュームの作成アタッチ接続移

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 4: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

4 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ 17

災害復旧のためのデータベース戦略 17

Active Data Guard 17

Oracle GoldenGate 20

Active Data Guardと GoldenGateの両方を使用 23

災害復旧のプランニング 23

自動化 23

障害検出 23

災害復旧のテスト 24

結論 24

参考資料 24

5 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

概要

災害復旧(DR)とはアプリケーションを災害から保護するプロセスです災害とはアプリケー

ションを危険にさらす出来事のことでありネットワークの停止から機器の障害や自然災害まで

多岐にわたります予期しない災害が発生した場合でも適切に設計されたDRプランがあれば

可能なかぎり迅速にアプリケーションをリカバリするとともにユーザーへのサービス提供を継

続することができます

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで高速なアプリケーションのDRを実現しま

すこのホワイトペーパーではOracle Cloud InfrastructureでのアプリケーションDRを設計し

実装する方法についてのベストプラクティスを概説します

災害復旧の概念

DRのプランニングを理解するにはよく使われる2つの用語を理解することが重要ですそれは

リカバリ時間目標(RTO)とリカバリポイント目標(RPO)です

RTOとは災害発生後アプリケーション機能をリストアするのに必要な目標時間で

すRTOの目的はどの程度迅速に災害から復旧する必要があるかを評価することで

す一般にアプリケーションの重要性が高ければ高いほどRTOは短くなります

RPOとはアプリケーションが耐えられるデータ損失の許容期間ですRPOの目的

は災害シナリオにおいてアプリケーションが失っても大丈夫なデータの量を示すこと

です

災害後もアプリケーションが存続することを保証しかつコスト効果にも優れたDRプランを策定

するにはRTOとRPOの両方を考慮しなければなりませんRTOとRPO両方の目的を達成し

てアプリケーションを災害から効果的にリカバリできるようにしてください

Oracle Cloud InfrastructureでのDRの基盤となるサービス

Oracle Cloud InfrastructureでのDRソリューションを設計し実装するにはOracle Cloud

Infrastructureのどの機能やサービスに信頼性が高くセキュアでコスト効果に優れたDRを実現す

る機能が組み込まれているかを知ることが重要です

リージョン可用性ドメインおよびフォルトドメイン

Oracle Cloud Infrastructureのリージョンとはいくつかの可用性ドメインで構成される局地的な

地域です可用性ドメインにはいくつかのフォルトドメインがあります

6 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

リージョンは相互に独立しており膨大な距離で隔てられて国や大陸をまたがる場合も

ありますアプリケーションを異なるリージョンにデプロイすればリージョン全体に

及ぶ事象(大規模な気象状況や地震など)のリスクを軽減することができます

可用性ドメインとはリージョン内に位置する 1つ以上のデータセンターです可用

性ドメインは相互に分離されフォルトトレラントで複数の可用性ドメインが同時

に障害を起こすことはほぼありません可用性ドメインは電源や冷却装置内部可用性

ドメインネットワークなどの物理インフラストラクチャを共有しないためある可用

性ドメインに影響を及ぼす障害が他の可用性ドメインに影響を及ぼす可能性は低くなり

ますリージョン内の可用性ドメインは低レイテンシ高帯域幅のネットワークで相

互に接続されています可用性ドメイン間のこの予測可能な暗号化された相互接続は

高可用性(HA)と DRの両方を実現するための構成要素となります

フォルトドメインとは可用性ドメイン内のハードウェアとインフラストラクチャを

グループ化したものです各可用性ドメインに 3つのフォルトドメインが含まれてい

ますフォルトドメインによってインスタンスを分散させ単一の可用性ドメイン内

の同じ物理ハードウェアにインスタンスが集中するのを避けることができますそのた

めあるフォルトドメインに影響を及ぼすハードウェア障害やメンテナンスイベン

トが他のフォルトドメイン内のインスタンスに影響を及ぼすことはありません新規

インスタンスのフォルトドメインを運用開始時に指定することもフォルトドメイ

ンが自動的に選択されるようにすることも可能です

7 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

コンピュート

Oracle Cloud Infrastructure Computeサービスはパフォーマンス柔軟性およびコントロールを

備えたベアメタルと仮想マシン両方のコンピュートインスタンスを提供しますこのサービ

スの原動力となるのがオラクルによるインターネット規模の次世代インフラストラクチャで

最も要求の厳しいアプリケーションやワークロードをクラウド上で開発実行できるように設計

されています

DRの観点からコンピュートインスタンスは複数の可用性ドメインまたはフォルトドメイン

にまたがるようにデプロイしてアプリケーションを停止から保護することをお薦めします

Computeサービスではイメージのインポートエクスポート機能を使用してカスタムイメー

ジをテナント間やリージョン間で共有することができます

ストレージ

Oracle Cloud Infrastructure Object Storageサービスはインターネット規模の高パフォーマンス

なストレージプラットフォームで信頼性が高くコスト効率のよいデータ耐久性を提供しま

すObject Storageを使用するとデータの格納や取出しを直接インターネットからあるいは

クラウドプラットフォーム内から安全かつセキュアに行うことができますこのプラット

フォームは柔軟性に優れているので小さく始めてシームレスに拡張することができパフォー

マンスやサービスの信頼性の低下を感じさせることはありません

Object Storageに格納されたデータはバックアップの必要がありませんObject Storageは本質

的に耐久性の高いストレージプラットフォームですすべてのオブジェクトがリージョン内の

複数のストレージサーバーに重複して格納されますチェックサムを使用してデータの整合性

が常に監視され破損したデータは自動的に修復されますこうしたオブジェクトストレージ

固有の耐久性特性により従来のバックアップの必要性はほぼなくなりますObject Storageは

信頼性が高く999の可用性を実現できるように設計されています

Storage Gatewayはオンプレミスのアプリケーションをオラクルのクラウドに接続できるよう

にするクラウドストレージゲートウェイですコスト効果の高いバックアップソリュー

ションとしてStorage Gatewayを使用しOracle Cloud Infrastructure Archive Storageにファイ

ルを移動することができます個別のファイルを移動することも圧縮済または無圧縮のzipアー

カイブやtarアーカイブを移動することも可能ですデータのセカンダリコピーを格納するとい

うのがStorage Gatewayの理想的なユースケースですStorage Gatewayを使用すると従来の

アプリケーションのデータを耐久性の高いオブジェクトストレージに移動できますデータの

リカバリが必要になった場合はStorage Gatewayの新しいインスタンスが作成されてデータ

を簡単にリカバリできます

Oracle Cloud Infrastructure Block Volumesサービスではブロックストレージボリュームを

動的にプロビジョニングし管理することが可能ですボリュームの作成アタッチ接続移

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 5: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

5 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

概要

災害復旧(DR)とはアプリケーションを災害から保護するプロセスです災害とはアプリケー

ションを危険にさらす出来事のことでありネットワークの停止から機器の障害や自然災害まで

多岐にわたります予期しない災害が発生した場合でも適切に設計されたDRプランがあれば

可能なかぎり迅速にアプリケーションをリカバリするとともにユーザーへのサービス提供を継

続することができます

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで高速なアプリケーションのDRを実現しま

すこのホワイトペーパーではOracle Cloud InfrastructureでのアプリケーションDRを設計し

実装する方法についてのベストプラクティスを概説します

災害復旧の概念

DRのプランニングを理解するにはよく使われる2つの用語を理解することが重要ですそれは

リカバリ時間目標(RTO)とリカバリポイント目標(RPO)です

RTOとは災害発生後アプリケーション機能をリストアするのに必要な目標時間で

すRTOの目的はどの程度迅速に災害から復旧する必要があるかを評価することで

す一般にアプリケーションの重要性が高ければ高いほどRTOは短くなります

RPOとはアプリケーションが耐えられるデータ損失の許容期間ですRPOの目的

は災害シナリオにおいてアプリケーションが失っても大丈夫なデータの量を示すこと

です

災害後もアプリケーションが存続することを保証しかつコスト効果にも優れたDRプランを策定

するにはRTOとRPOの両方を考慮しなければなりませんRTOとRPO両方の目的を達成し

てアプリケーションを災害から効果的にリカバリできるようにしてください

Oracle Cloud InfrastructureでのDRの基盤となるサービス

Oracle Cloud InfrastructureでのDRソリューションを設計し実装するにはOracle Cloud

Infrastructureのどの機能やサービスに信頼性が高くセキュアでコスト効果に優れたDRを実現す

る機能が組み込まれているかを知ることが重要です

リージョン可用性ドメインおよびフォルトドメイン

Oracle Cloud Infrastructureのリージョンとはいくつかの可用性ドメインで構成される局地的な

地域です可用性ドメインにはいくつかのフォルトドメインがあります

6 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

リージョンは相互に独立しており膨大な距離で隔てられて国や大陸をまたがる場合も

ありますアプリケーションを異なるリージョンにデプロイすればリージョン全体に

及ぶ事象(大規模な気象状況や地震など)のリスクを軽減することができます

可用性ドメインとはリージョン内に位置する 1つ以上のデータセンターです可用

性ドメインは相互に分離されフォルトトレラントで複数の可用性ドメインが同時

に障害を起こすことはほぼありません可用性ドメインは電源や冷却装置内部可用性

ドメインネットワークなどの物理インフラストラクチャを共有しないためある可用

性ドメインに影響を及ぼす障害が他の可用性ドメインに影響を及ぼす可能性は低くなり

ますリージョン内の可用性ドメインは低レイテンシ高帯域幅のネットワークで相

互に接続されています可用性ドメイン間のこの予測可能な暗号化された相互接続は

高可用性(HA)と DRの両方を実現するための構成要素となります

フォルトドメインとは可用性ドメイン内のハードウェアとインフラストラクチャを

グループ化したものです各可用性ドメインに 3つのフォルトドメインが含まれてい

ますフォルトドメインによってインスタンスを分散させ単一の可用性ドメイン内

の同じ物理ハードウェアにインスタンスが集中するのを避けることができますそのた

めあるフォルトドメインに影響を及ぼすハードウェア障害やメンテナンスイベン

トが他のフォルトドメイン内のインスタンスに影響を及ぼすことはありません新規

インスタンスのフォルトドメインを運用開始時に指定することもフォルトドメイ

ンが自動的に選択されるようにすることも可能です

7 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

コンピュート

Oracle Cloud Infrastructure Computeサービスはパフォーマンス柔軟性およびコントロールを

備えたベアメタルと仮想マシン両方のコンピュートインスタンスを提供しますこのサービ

スの原動力となるのがオラクルによるインターネット規模の次世代インフラストラクチャで

最も要求の厳しいアプリケーションやワークロードをクラウド上で開発実行できるように設計

されています

DRの観点からコンピュートインスタンスは複数の可用性ドメインまたはフォルトドメイン

にまたがるようにデプロイしてアプリケーションを停止から保護することをお薦めします

Computeサービスではイメージのインポートエクスポート機能を使用してカスタムイメー

ジをテナント間やリージョン間で共有することができます

ストレージ

Oracle Cloud Infrastructure Object Storageサービスはインターネット規模の高パフォーマンス

なストレージプラットフォームで信頼性が高くコスト効率のよいデータ耐久性を提供しま

すObject Storageを使用するとデータの格納や取出しを直接インターネットからあるいは

クラウドプラットフォーム内から安全かつセキュアに行うことができますこのプラット

フォームは柔軟性に優れているので小さく始めてシームレスに拡張することができパフォー

マンスやサービスの信頼性の低下を感じさせることはありません

Object Storageに格納されたデータはバックアップの必要がありませんObject Storageは本質

的に耐久性の高いストレージプラットフォームですすべてのオブジェクトがリージョン内の

複数のストレージサーバーに重複して格納されますチェックサムを使用してデータの整合性

が常に監視され破損したデータは自動的に修復されますこうしたオブジェクトストレージ

固有の耐久性特性により従来のバックアップの必要性はほぼなくなりますObject Storageは

信頼性が高く999の可用性を実現できるように設計されています

Storage Gatewayはオンプレミスのアプリケーションをオラクルのクラウドに接続できるよう

にするクラウドストレージゲートウェイですコスト効果の高いバックアップソリュー

ションとしてStorage Gatewayを使用しOracle Cloud Infrastructure Archive Storageにファイ

ルを移動することができます個別のファイルを移動することも圧縮済または無圧縮のzipアー

カイブやtarアーカイブを移動することも可能ですデータのセカンダリコピーを格納するとい

うのがStorage Gatewayの理想的なユースケースですStorage Gatewayを使用すると従来の

アプリケーションのデータを耐久性の高いオブジェクトストレージに移動できますデータの

リカバリが必要になった場合はStorage Gatewayの新しいインスタンスが作成されてデータ

を簡単にリカバリできます

Oracle Cloud Infrastructure Block Volumesサービスではブロックストレージボリュームを

動的にプロビジョニングし管理することが可能ですボリュームの作成アタッチ接続移

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 6: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

6 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

リージョンは相互に独立しており膨大な距離で隔てられて国や大陸をまたがる場合も

ありますアプリケーションを異なるリージョンにデプロイすればリージョン全体に

及ぶ事象(大規模な気象状況や地震など)のリスクを軽減することができます

可用性ドメインとはリージョン内に位置する 1つ以上のデータセンターです可用

性ドメインは相互に分離されフォルトトレラントで複数の可用性ドメインが同時

に障害を起こすことはほぼありません可用性ドメインは電源や冷却装置内部可用性

ドメインネットワークなどの物理インフラストラクチャを共有しないためある可用

性ドメインに影響を及ぼす障害が他の可用性ドメインに影響を及ぼす可能性は低くなり

ますリージョン内の可用性ドメインは低レイテンシ高帯域幅のネットワークで相

互に接続されています可用性ドメイン間のこの予測可能な暗号化された相互接続は

高可用性(HA)と DRの両方を実現するための構成要素となります

フォルトドメインとは可用性ドメイン内のハードウェアとインフラストラクチャを

グループ化したものです各可用性ドメインに 3つのフォルトドメインが含まれてい

ますフォルトドメインによってインスタンスを分散させ単一の可用性ドメイン内

の同じ物理ハードウェアにインスタンスが集中するのを避けることができますそのた

めあるフォルトドメインに影響を及ぼすハードウェア障害やメンテナンスイベン

トが他のフォルトドメイン内のインスタンスに影響を及ぼすことはありません新規

インスタンスのフォルトドメインを運用開始時に指定することもフォルトドメイ

ンが自動的に選択されるようにすることも可能です

7 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

コンピュート

Oracle Cloud Infrastructure Computeサービスはパフォーマンス柔軟性およびコントロールを

備えたベアメタルと仮想マシン両方のコンピュートインスタンスを提供しますこのサービ

スの原動力となるのがオラクルによるインターネット規模の次世代インフラストラクチャで

最も要求の厳しいアプリケーションやワークロードをクラウド上で開発実行できるように設計

されています

DRの観点からコンピュートインスタンスは複数の可用性ドメインまたはフォルトドメイン

にまたがるようにデプロイしてアプリケーションを停止から保護することをお薦めします

Computeサービスではイメージのインポートエクスポート機能を使用してカスタムイメー

ジをテナント間やリージョン間で共有することができます

ストレージ

Oracle Cloud Infrastructure Object Storageサービスはインターネット規模の高パフォーマンス

なストレージプラットフォームで信頼性が高くコスト効率のよいデータ耐久性を提供しま

すObject Storageを使用するとデータの格納や取出しを直接インターネットからあるいは

クラウドプラットフォーム内から安全かつセキュアに行うことができますこのプラット

フォームは柔軟性に優れているので小さく始めてシームレスに拡張することができパフォー

マンスやサービスの信頼性の低下を感じさせることはありません

Object Storageに格納されたデータはバックアップの必要がありませんObject Storageは本質

的に耐久性の高いストレージプラットフォームですすべてのオブジェクトがリージョン内の

複数のストレージサーバーに重複して格納されますチェックサムを使用してデータの整合性

が常に監視され破損したデータは自動的に修復されますこうしたオブジェクトストレージ

固有の耐久性特性により従来のバックアップの必要性はほぼなくなりますObject Storageは

信頼性が高く999の可用性を実現できるように設計されています

Storage Gatewayはオンプレミスのアプリケーションをオラクルのクラウドに接続できるよう

にするクラウドストレージゲートウェイですコスト効果の高いバックアップソリュー

ションとしてStorage Gatewayを使用しOracle Cloud Infrastructure Archive Storageにファイ

ルを移動することができます個別のファイルを移動することも圧縮済または無圧縮のzipアー

カイブやtarアーカイブを移動することも可能ですデータのセカンダリコピーを格納するとい

うのがStorage Gatewayの理想的なユースケースですStorage Gatewayを使用すると従来の

アプリケーションのデータを耐久性の高いオブジェクトストレージに移動できますデータの

リカバリが必要になった場合はStorage Gatewayの新しいインスタンスが作成されてデータ

を簡単にリカバリできます

Oracle Cloud Infrastructure Block Volumesサービスではブロックストレージボリュームを

動的にプロビジョニングし管理することが可能ですボリュームの作成アタッチ接続移

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 7: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

7 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

コンピュート

Oracle Cloud Infrastructure Computeサービスはパフォーマンス柔軟性およびコントロールを

備えたベアメタルと仮想マシン両方のコンピュートインスタンスを提供しますこのサービ

スの原動力となるのがオラクルによるインターネット規模の次世代インフラストラクチャで

最も要求の厳しいアプリケーションやワークロードをクラウド上で開発実行できるように設計

されています

DRの観点からコンピュートインスタンスは複数の可用性ドメインまたはフォルトドメイン

にまたがるようにデプロイしてアプリケーションを停止から保護することをお薦めします

Computeサービスではイメージのインポートエクスポート機能を使用してカスタムイメー

ジをテナント間やリージョン間で共有することができます

ストレージ

Oracle Cloud Infrastructure Object Storageサービスはインターネット規模の高パフォーマンス

なストレージプラットフォームで信頼性が高くコスト効率のよいデータ耐久性を提供しま

すObject Storageを使用するとデータの格納や取出しを直接インターネットからあるいは

クラウドプラットフォーム内から安全かつセキュアに行うことができますこのプラット

フォームは柔軟性に優れているので小さく始めてシームレスに拡張することができパフォー

マンスやサービスの信頼性の低下を感じさせることはありません

Object Storageに格納されたデータはバックアップの必要がありませんObject Storageは本質

的に耐久性の高いストレージプラットフォームですすべてのオブジェクトがリージョン内の

複数のストレージサーバーに重複して格納されますチェックサムを使用してデータの整合性

が常に監視され破損したデータは自動的に修復されますこうしたオブジェクトストレージ

固有の耐久性特性により従来のバックアップの必要性はほぼなくなりますObject Storageは

信頼性が高く999の可用性を実現できるように設計されています

Storage Gatewayはオンプレミスのアプリケーションをオラクルのクラウドに接続できるよう

にするクラウドストレージゲートウェイですコスト効果の高いバックアップソリュー

ションとしてStorage Gatewayを使用しOracle Cloud Infrastructure Archive Storageにファイ

ルを移動することができます個別のファイルを移動することも圧縮済または無圧縮のzipアー

カイブやtarアーカイブを移動することも可能ですデータのセカンダリコピーを格納するとい

うのがStorage Gatewayの理想的なユースケースですStorage Gatewayを使用すると従来の

アプリケーションのデータを耐久性の高いオブジェクトストレージに移動できますデータの

リカバリが必要になった場合はStorage Gatewayの新しいインスタンスが作成されてデータ

を簡単にリカバリできます

Oracle Cloud Infrastructure Block Volumesサービスではブロックストレージボリュームを

動的にプロビジョニングし管理することが可能ですボリュームの作成アタッチ接続移

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 8: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

8 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

動を必要に応じて行いストレージとアプリケーションの要件を満たすことができますこの

サービスのバックアップ機能を使用するとデータのポイントインタイムバックアップをブ

ロックボリューム上に作成できますこの機能によりボリュームの予備のコピーが作成され

るのでDRを同じリージョン内で問題なく完了させることができます手動バックアップを実行

することもポリシー主導の自動バックアップを実装することも可能です

データの耐久性を確保する目的でデータの複数のコピーが可用性ドメイン内の複数のストレー

ジサーバーに重複して格納されます可用性ドメインが障害を起こしたり使用できなくなっ

たりした場合の影響から保護するために通常のバックアップをリモートリージョンに作成し

ておくことをお薦めします

Oracle Cloud Infrastructure File Storageサービスは耐久性とスケーラビリティに優れたエン

タープライズクラスの分散型ネットワークファイルシステムを提供しますFile Storage

は幅広いユースケースにわたってエンタープライズファイルシステムを必要とするアプ

リケーションやユーザーのニーズを満たすよう設計されていますデータは業界をリードする

データ保護技術とベストプラクティスを実装した高可用性インフラストラクチャの各可用性ド

メイン内で耐久性を確保するためにレプリケートされます可用性ドメインの障害から保護す

るためにファイルシステムスナップショットの通常のバックアップを作成しておくことを

お薦めします

ネットワーキング

ネットワーキングはDRソリューションの重要なコンポーネントですOracle Cloud Infrastructure

にはアプリケーションDR要件を満たすネットワーク関連サービスおよび機能がいくつか用意さ

れています

仮想クラウドネットワーク(VCN)はOracleデータセンターに設定するソフトウェア定義の

ネットワークでお客様が選択可能なファイアウォールルールと特定の種類の通信ゲートウェ

イを備えていますサブネットはパブリックかプライベートかインスタンスがパブリックIPア

ドレスを取得するかどうかなどをお客様が制御できますVCNはインターネットにアクセスす

るように設定できますまたVCNをOracle Cloud Infrastructureのパブリックサービス(Object

Storageなど)オンプレミスネットワークまたは別のVCNにプライベートに接続することも可

能です

予約済のパブリックIPアドレスを使用するとフェイルオーバーまたはフェイルバックが発生し

た場合にIPアドレスの割当てを解除して別のインスタンスに割り当てなおすことができるの

でDRプロセスがシンプルになります

Oracle Cloud Infrastructure FastConnectではオンプレミスのデータセンターとオラクルのク

ラウドインフラストラクチャの間に専用のプライベート接続を簡単に確立できます

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 9: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

9 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

FastConnectはインターネットベースの接続よりも高帯域幅のオプションと信頼性が高く一貫

したネットワーキング体験を提供します

Oracle Cloud Infrastructure Load Balancingサービスは1つのエントリポイントからVCNか

らアクセス可能な複数のサーバーへの自動トラフィック分散を実現しますこのサービスには

お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロビジョニングされ

た帯域幅によるロードバランサが用意されていますロードバランサを使用すると問題の

あるアプリケーションサーバーからのトラフィックが自動的に排除されメンテナンスの際に

手動でサービスから除去する必要がなくなるためメンテナンス期間を短縮できます

データベース

Oracle Cloud Infrastructure Databaseサービスは数種類のOracleデータベースを提供しますそ

のためニーズに適したデータベースシステムの運用を迅速に開始できますお客様はデータ

ベースで提供される機能や操作を自由に利用できますがインフラストラクチャはオラクルが所

有し管理します

Databaseサービスはサイズ価格パフォーマンスが異なる数種類のDBシステムをサポート

しています各種システムの詳細は次のリンクを参照してください

Exadata DBシステム

ベアメタルおよび仮想マシン DBシステム

オラクルの Autonomous Data Warehouseは事前構成されたフルマネージド型のデータウェ

アハウス環境を提供しますAutonomous Data Warehouseはビジネスインテリジェンスア

プリケーションの実行用に設計されておりビジネスに関する重要なインサイトを発見するのに

役立ちます

Oracle Cloud Infrastructureでの一般的な災害シナリオ

DRソリューションの設計とプランニングの際には考えられる災害シナリオをあらゆる側面から

検討してくださいこの項ではDRソリューションの設計と実装に役立つようにいくつかの一

般的な災害シナリオについて説明します

アプリケーション障害

アプリケーションの障害は基礎となるインフラストラクチャの障害やソフトウェアまたはハー

ドウェアの構成の変更に関連した問題が原因で発生しますDRソリューションの設計に監視機能

を組み込みアプリケーション障害が検出されてアラートが送信されるようにすることが重要で

すお客様の要件によってDRソリューションはアプリケーションのデータと構成の単純なバッ

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 10: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

10 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

クアップから多様な障害をシームレスに軽減する完全にアクティブ-アクティブのフェイルオー

バー設定まで多岐にわたります

ネットワーク障害

DRについてはクラウド環境で発生する可能性のあるネットワークの停止を考慮してください

たとえばIPSec VPNを使用してオンプレミスのデータセンターをOracle Cloud Infrastructure

に接続する場合このIPSec VPN接続のネットワークパフォーマンスまたは停止の問題が発生

する可能性がありますそこで複数のIPSec VPN接続を設定するかFastConnect接続とIPSec

VPN接続を両方使用してネットワーク接続の冗長性を十分に確保することをお薦めします

データセンター障害

予期しない事象がデータセンター全体(可用性ドメイン)に影響を及ぼす可能性がありますDR

ソリューションの設計ではこの種の障害に備えたプランを策定してくださいリージョン内に

複数の可用性ドメインがある場合複数の可用性ドメインにまたがるようにアプリケーションを

デプロイして特定のデータセンターで起こりうる問題に対応することをお薦めしますリー

ジョン内に可用性ドメインが1つしかない場合はリージョン障害についての推奨事項を考慮し

てください(次の項を参照)

リージョン障害(自然災害)

稀なことではありますが自然災害によってOracle Cloud Infrastructureリージョン全体がサービ

スを停止してしまう可能性がありますこのシナリオはDR設計における最も重大な問題の1つ

ですこのシナリオではDRソリューションとして複数のOracle Cloud Infrastructureリージョン

を使用することをお薦めしますDR要件(RTOとRPO)に応じてデータを別のリージョンにバッ

クアップまたはレプリケートするか完全にアクティブ-アクティブのスタンバイを別のリージョ

ンに設定することができます

DRのためのデプロイメント戦略

前の項で説明した考えられる災害からアプリケーションを保護するにはRTOとRPOの要件に基

づいてアプリケーションデプロイメント戦略を定義することが重要ですこの項ではDRソ

リューションの設計用に様々なデプロイメント戦略を示します

可用性ドメインを1つ含む単一リージョン

可用性ドメインを1つ含むリージョンでは複数のフォルトドメインにまたがるようにアプリ

ケーションをデプロイして予期しないハードウェア障害やハードウェアメンテナンスのため

の計画停止からアプリケーションを保護することができますただし可用性ドメイン全体の障

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 11: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

11 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

害が発生した場合このデプロイメントでは保護できません可用性ドメインを1つ含むリー

ジョンでの効果的なDRソリューションとしてはリモートリージョンへのレプリケーションを

お薦めします

たとえば稼働中のプライマリリージョンとは別のリモートリージョンにブロックボ

リュームをバックアップしますブロックボリュームのバックアップを別のリージョンに定期

的にコピーすることでプライマリリージョンが災害の影響を受けた場合でもリモート

リージョンにあるアプリケーションと関連データを再構築することができ大幅なデータ損失は

発生しませんリモートリージョンのボリュームバックアップを新しいインスタンスによっ

てリストアしてアクセスし新しいリージョンにアプリケーション機能をリストアすることがで

きます

詳細は「クロスリージョン」の項を参照してください

複数の可用性ドメインを含む単一リージョン

アプリケーションの重要性によってはアプリケーションを単一リージョンにデプロイすること

もできます各リージョンに複数の可用性ドメインがあるため複数の可用性ドメインにまたが

るようにアプリケーションをデプロイして単一の可用性ドメインで起こりうる障害に対応する

ことができますDRソリューションの設計でOracle Cloud Infrastructure Load Balancerサービス

を使用してアプリケーションのダウンタイムを最小限に抑えることをお薦めしますアプリ

ケーションスタックにデータベースコンポーネントが含まれている場合はプライマリ

データベースとは異なる可用性ドメインにスタンバイDBシステムをデプロイして両者の間に

Data Guardを設定することをお薦めしますまたOracle Cloud Infrastructure Object Storageへ

のデータベースのバックアップを設定してアプリケーションデータをさらに保護することも

お薦めします

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 12: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

12 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

次の図はこのデプロイメントを示しています

リージョン全体の障害が発生した場合単一リージョンのデプロイメントでは完全な保護を提供

できないことを考慮に入れてください

クロスリージョン

ミッションクリティカルなアプリケーションにはDRソリューションとしてクロスリージョン

設計を検討してくださいOracle Cloud Infrastructureは複数のOracle Cloud Infrastructureの

リージョンの間に堅牢な高パフォーマンスのバックボーンを提供しますリモートVCNピアリン

グを使用することでリージョンをまたがった異なるVCNの間にセキュアで信頼性の高い接続を

確立できます

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 13: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

13 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

たとえばリージョンをまたがってのデータ保護を実現するにはrsyncを使用してファイル

システムまたはスナップショットデータを別のリージョンに非同期にコピーします

Oracle Database on Oracle Cloud Infrastructureにあらかじめ用意されている機能を使用して

リージョンをまたがってデータ保護を実現することもできますたとえば次の図に示すよう

にOracle Database on Oracle Cloud Infrastructureを使用した3層アプリケーションをデプロイ

できます

アプリケーションおよびWeb層の各ノードがデータベースノードのいずれかと通信します

Oracle Cloud InfrastructureはRACとExadataをサポートしているため単一の可用性ドメイン内

でも高い可用性を得ることができます局部的な障害がデータベースで発生した場合はActive

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 14: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

14 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardを使用してリージョン内またはリージョンをまたがって他の可用性ドメイン内にあ

る同等のデータベースと同期します

災害復旧ソリューション

この項ではDR設計をプランニングする際に検討すべきいくつかのDRソリューションを説明し

ます

バックアップとリストア

バックアップの第一の用途はビジネス継続性災害復旧および長期アーカイブをサポートする

ことですバックアップスケジュールを決定する場合バックアップのプランと目標は次の点

を考慮したものでなければなりません

頻度 データをバックアップする頻度

リカバリ時間 バックアップがリストアされてそれを使用するアプリケーションからア

クセスできるようになるまで待てる時間バックアップが完了するまでの時間はバッ

クアップするデータのサイズや最終バックアップ以降に変更されたデータの量などい

くつかの要因によって変わりますが一般的には 2~3分です

格納するバックアップの数 利用可能な状態にしておく必要のあるバックアップの数と

不要になったバックアップの削除スケジュール一度に作成できるバックアップは 1つ

のみですバックアップが進行中の場合それが完了するまで別のバックアップは作成

できません格納できるバックアップの数の詳細は「ブロックボリュームの機能と

制限」を参照してください

バックアップを使用する一般的なユースケースを次に示します

同じボリュームのコピーを複数作成する多数のボリュームを含む多数のインスタンス

を作成する必要があり各ボリュームのデータ編成が同一でなければならない場合

バックアップはきわめて便利です

後で新しいボリュームにリストアできる作業のスナップショットを作成する

ボリュームの予備のコピーを作成しプライマリコピーに問題が発生した場合に備え

ブロックボリュームのバックアップを作成する際のベストプラクティス

バックアップを作成する際およびバックアップからリストアする際には次のベストプラク

ティスを考慮してください

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 15: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

15 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

バックアップを作成する前にデータを一貫した状態にしますファイルシステムを

同期し可能であればファイルシステムをアンマウントしてアプリケーション

データを保存しますバックアップされるのはディスク上のデータのみですバック

アップを作成する際にはバックアップ状態が REQUEST_RECEIVEDから CREATING

に変化した後でボリュームへのデータの書込みを再開することができますバック

アップが進行している間バックアップ対象のボリュームは削除できません

元々のボリュームがアタッチ済みである状態でリストアされているボリュームをアタッ

チする場合一部のオペレーティングシステムでは同一のボリュームのリストアが許

可されないことを考慮してくださいこの問題を解決するにはボリュームをリストア

する前にパーティション IDを変更しますオペレーティングシステムのパーティショ

ン IDを変更する方法はオペレーティングシステムによって異なります手順につい

てはオペレーティングシステムのドキュメントを参照してください

作成したバックアップが正常に完了したことが確認できるまで元のボリュームは削除

しないでください

アプリケーションが複数のコンピュートインスタンスにまたがる複数のボリュームで構成さ

れている場合はボリュームグループのバックアップ機能を使用してボリュームのバックアッ

プとリストアを実行しますこの機能は既存の単一ボリュームのバックアップおよびリストア

機能(すでにブロックストレージボリュームで利用可能)を使用し拡張することによりア

プリケーションのバックアップを作成管理リストアするためのエンドツーエンドのソリュー

ションを提供しますこの機能により複数のインスタンス上で複数のストレージボリューム

を使用して実行されているエンタープライズアプリケーションのバックアップとクローンを作

成するプロセスが簡素化されますその後ボリュームグループのバックアップからボリュー

ムのグループ全体をリストアできます

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 16: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

16 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

パイロットライト

パイロットライトという言葉は昔ながらのガスヒーターの種火を指します種火は常に点

いているので屋内の温度センサーによって作動したときにすばやくヒーターに点火することが

できます同じ概念がパイロットライトDRにも当てはまりアプリケーション所有者によって

DRがアクティブ化されると本番規模の環境全体(ヒーター)がデプロイされますパイロット

ライトはDRサイトにデプロイされて最新のアプリケーション構成と重要なデータをすべて維

持するアプリケーションの重要なコアコンポーネントですDRサイトにおけるパイロット

ライトの重要なコンポーネントを次に示します

データベース層

Oracle Cloud Infrastructure DatabaseサービスはCPUのスケーリングという独自の機能を提供

しますこれを使用するとDRサイト(可用性ドメインまたはリージョンあるいはその両方)に

データベース全体をプロビジョニングしつつ本番規模のCPUの一部を有効化しないでおくこと

ができますDRがアクティブになったらサービスへのREST APIコールを1回行うだけで追加

のCPUを有効化することができデータベースサーバーの再起動は必要ありません

アプリケーション層

最新の構成のすべてを手元で維持できるDRサイト(可用性ドメインまたはリージョンあるいは

その両方)にアプリケーションサーバーを1つだけデプロイしますOracle Cloud Infrastructure

のカスタムイメージ機能を使用してアプリケーションのOSを定期的にバックアップしDRサ

イトがアクティブになったらそのイメージを使用して新しいサーバーをプロビジョニングする

ことができますたとえば本番サイトにアプリケーションサーバーが8つある場合DRサイ

トにはアプリケーションサーバーを1つだけデプロイしrsyncまたは別のツールを使用してプ

ライマリサイトと同期した状態を維持しますDRサイトのこのサーバーからカスタムイメー

ジを毎日作成しDRがアクティブになったらこのカスタムイメージを使用して残りの7つの

サーバーをプロビジョニングすることができます

ネットワーキング層

パイロットライトDRソリューションではOracle Cloud Infrastructureで次のサービスを使用し

ます

IPアドレス(プライベートおよびパブリック)

DNSサービス

ロードバランササービス

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 17: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

17 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

ウォームスタンバイ

ウォームスタンバイとはDRサイトで常に実行されている完全な本番環境のスケールダウン版

ですウォームスタンバイソリューションはパイロットライトソリューションを拡大

したものです一部のサービスがDRサイトで常に実行されており残りのサービスの起動中に

ワークロードの引継ぎを開始できるためDRのアクティブ化にかかる時間が短縮されますこの

ソリューションは本番の負荷全体を引き継げる規模ではなくテストや品質保証内部使用など

の非本番作業に使用できます

他のクラウドプロバイダと同様にOracle Cloud Infrastructureでは従来の水平スケーリングが

可能でありウォームスタンバイDR構成の主要な要素となっていますただしソリューショ

ンでデータベースシャーディングをデプロイしていないかぎりデータベースを水平方向にス

ケーリングするのは容易ではありませんOracle Cloud InfrastructureにはCPUスケーリングの

機能がありますこれによりDatabaseサービスを2つ以上のOCPUとともにデプロイしDRサ

イトをアクティブ化した時点で追加のOCPUを有効にすることができますこの機能が適用され

るのはベアメタルおよびExadataデータベースシェイプのみですこの非侵襲型の機能に

よりデータベースを再起動しなくても追加のCPUがほぼ瞬時に(30秒以内に)使用可能になり

ます

災害復旧のためのデータベース戦略

Oracle Active Data GuardとOracle GoldenGateはオラクルのソフトウェアポートフォリオに

おける2つの戦略的機能です

Active Data Guardはシンプルかつ経済的な方法で Oracle Databaseのデータ保護と可

用性を実現しますそのために本番コピーの正確な物理レプリカをリモート拠点で維

持しますがこのレプリカはレプリケーションがアクティブの間読取り専用でオープ

ンされます

GoldenGateはマルチマスターレプリケーションハブスポークデプロイメント

およびデータ変換をサポートする高度な論理レプリケーション製品ですGoldenGate

は異種ハードウェアプラットフォームも含めありとあらゆるレプリケーション要

件に対応する柔軟な選択肢をお客様に提供します

Active Data Guard

Data Guardは1つ以上のスタンバイデータベースを作成維持管理監視することで本

番のOracleデータベースが災害やデータ破損に耐えられるようにする包括的なサービス群を提

供しますData Guardはこれらのスタンバイデータベースをトランザクション的に一貫し

た本番データベースのコピーとして維持します計画停止または計画外停止によって本番データ

ベースが使用できなくなるといずれかのスタンバイデータベースを本番ロールに切り替え

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 18: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

18 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

て停止に伴うダウンタイムを最小限に抑えることができますData Guardを従来のバックアッ

プリストアおよびクラスタ技術と併用することで高度なデータ保護とデータ可用性を実現で

きます

Data Guardの利点

Active Data Guardには次のような利点があります

物理レプリケーションの保護スタンバイデータベースは読取り専用でオープンされ

るのでデータの一貫性が保護されます

完全な Oracle Databaseのシンプルかつ高速な一方向レプリケーションデフォルト構

成が大半のワークロードに対応しているため管理オーバーヘッドはほとんど発生しま

せん

制限なしOracle Data Guard Redo Applyはすべての Oracle機能をサポートしすべ

てのデータおよびストレージタイプPLSQLパッケージDDLを透過的にレプリ

ケートするので特別な配慮は不要です

最善のデータ保護メモリーから直接レプリケーションを行うことでプライマリ

データベースで発生する IO破損からスタンバイデータベースを分離しますプライ

マリデータベースまたはスタンバイデータベースで単独で発生する書込み損失に

よるサイレントな破損を検出しますプライマリデータベースまたはスタンバイ

データベースで単独で発生する物理ブロックの破損を自動的に検出して修復します

同期方式によるデータ損失ゼロの保護か非同期方式によるデータ損失がほぼゼロの保

護かを選択可能

読取り専用のワークロードやバックアップを同期された物理スタンバイにオフロードす

ることでROIを簡単に改善可能

バックアップの透過性Oracle Data Guardのプライマリデータベースとスタンバイ

データベースはお互いの正確な物理的に正確なコピーですRMANバックアップは互

換性があります

単一コマンドにより物理スタンバイデータベースを読取り書込みモードでオープン

しているテストシステムとして変換2番目のコマンドにより物理スタンバイ

データベースに変換して戻しプライマリデータベースと再度同期しますプライマ

リデータは常に保護されます

Oracle Data Guard Brokerのコマンドラインまたは Oracle Enterprise Manager Cloud

Controlによる全構成の統合管理統合された自動データベースクライアントフェイ

ルオーバー

単一ノードデータベースまたは複数ノードデータベース(Real Application Cluster)の

構成をサポート

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 19: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

19 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Data Guardの構成モード

Data Guardは次の保護モードをサポートしています

最大保護 この保護モードはプライマリデータベースで障害が発生した場合にデータ損失

ゼロを実現しますデータ損失を確実に防止するため障害発生時にプライマリデータベース

が1つ以上のスタンバイデータベースのスタンバイREDOログにREDOストリームを書き込めな

い場合プライマリデータベースは停止します

最大可用性 この保護モードはプライマリデータベースの可用性を低下させない範囲で可能

な最高レベルのデータ保護を提供します最大保護モードと同じくトランザクションのリカバ

リに必要なREDOがローカルのオンラインREDOログと1つ以上のトランザクション的に一貫し

たスタンバイデータベースのスタンバイREDOログに書き込まれるまでトランザクションは

コミットされません最大保護モードとは異なり障害発生時にプライマリデータベースがリ

モートのスタンバイREDOログにREDOストリームを書き込めない場合でもプライマリデータ

ベースは停止しませんそのかわりに障害が解消しREDOログファイルの相違がすべて解

決されるまでプライマリデータベースは最大パフォーマンスモードで稼働します相違が

すべて解決されるとプライマリデータベースは最大可用性モードでの稼働を自動的に再開し

ます

最大パフォーマンス この保護モード(デフォルト)はプライマリデータベースのパフォーマン

スに影響を与えない範囲で可能な最高レベルのデータ保護を提供しますこれを実現するため

にトランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに非

同期に書き込まれたときにそのトランザクションがコミットされるようにしています十分な

帯域幅を持つネットワークリンクが使用されている場合このモードはプライマリデータ

ベースのパフォーマンスへの影響を最小限に抑えながら最大可用性モードに迫るレベルのデー

タ保護を提供します

Oracle Cloud InfrastructureでのData Guard構成のベストプラクティス

3種類のData Guard構成はすべてOracle Cloud Infrastructureで完全にサポートされています

ただし本番環境の停止はリスクが高いためData Guard構成で最大保護モードを使用すること

はお薦めしません

2つの可用性ドメイン間(同じリージョン)では最大可用性モードをSYNCモードで使用し2つの

リージョン間では最大可用性モードをASYNCモードで使用することをお薦めしますこのアーキ

テクチャではデータ損失をまったく発生させずに最善のRTOとRPOを得ることができます

このアーキテクチャはデイジーチェーンモードで構築することをお薦めしますデイジー

チェーンモードの場合プライマリデータベースが別の可用性ドメイン内の最初のスタンバ

イデータベースにREDOログをSYNCモードで送ると最初のスタンバイデータベースはそ

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 20: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

20 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

のREDOログを別のリージョンにASYNCモードで送りますこの方法であればプライマリ

データベースがREDOログの送信作業を2回行うことはなくなるため本番ワークロードにパ

フォーマンスの影響が及ぶのを避けることができます

次の図はOracle Cloud InfrastructureでのData Guardの推奨アーキテクチャを示しています

この構成には次の利点があります

リージョン内でデータ損失が発生しない

別のリージョンでスタンバイを維持するためのオーバーヘッドが本番データベースにか

からない

ビジネス上の理由で必要な場合はDRサイトでのラグを構成可能

本番データベースに追加のオーバーヘッドをかけずに異なるリージョンに複数のスタ

ンバイを構成可能典型的なユースケースは CDNアプリケーションです

Oracle GoldenGate

Oracle GoldenGateは異種IT環境におけるリアルタイムのデータ統合およびレプリケーション

のための包括的なソフトウェアパッケージですこの製品セットを使用すると業務用エン

タープライズシステムと分析用エンタープライズシステムの間の高可用性ソリューション

リアルタイムデータ統合トランザクションチェンジデータのキャプチャデータレプ

リケーション変換検証が可能になります

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 21: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

21 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle GoldenGateはレプリケーションがアクティブの場合にレプリカデータベースを読取

り書込みモードでオープンする必要があるときに使用します次のようなシナリオが考えられま

マルチマスターの双方向レプリケーションサブセットレプリケーション多対 1レ

プリケーションクロスエンディアンレプリケーションデータ変換などの高度なレ

プリケーション要件

双方向レプリケーションを使用したゼロダウンタイムが求められるメンテナンスおよ

び移行

Data Guardでサポートされていないクロスプラットフォーム移行(クロスエンディア

ンプラットフォーム移行など)

プライマリデータベースとライブスタンバイデータベースが異なるオペレーティ

ングシステム上にあるか異なる種類の場合(DB2MySQLから Oracleなど)

新しいバージョンの Oracle Databaseから古いバージョンの Oracle Databaseにレプリ

ケートする場合(Oracle Database 11gから Oracle Database 10gなど)

GoldenGateの構成モード

GoldenGateは次のトポロジをサポートしておりOracle Cloud Infrastructureで完全にサポートさ

れています

一方向

双方向

ピアツーピア

ブロードキャスト

統合

カスケード

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 22: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

22 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Oracle Cloud InfrastructureでのGoldenGate構成のベストプラクティス

GoldenGateはトランザクションレベルでデータをレプリケートするので2つのサイト間の

データ一貫性を維持するために競合の検出および解決(CDR)を実装することをお薦めします競

合は即座に識別され自動スクリプトで処理されます

GoldenGateを主にDRの目的で使用しておりレプリケーションが一方向のみの場合2つのリー

ジョン間のData Guardを追加してプライマリインスタンスとData Guardインスタンスの間で

強力なデータ一貫性を確保できるデータ損失ゼロのソリューションを提供することをお薦めしま

すこの構成にはGoldenGate抽出をプライマリデータベースから実行する際のオーバーヘッ

ドが軽減される利点もあります

次の図はこの推奨アーキテクチャを示しています

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 23: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

23 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

Active Data GuardとGoldenGateの両方を使用

前の項で述べたようにActive Data GuardとGoldenGateは相互排他的ではありません次のシ

ナリオではこの2つのソリューションを併用できます

ミッションクリティカルな OLTPデータベースの災害からの保護とデータベースロー

リングアップグレードの目的でActive Data Guardスタンバイを使用します

GoldenGateを使用してエンタープライズデータウェアハウスの ETL更新用に

Data Guardプライマリデータベースから(または GoldenGateの ALOモードを使用し

てスタンバイデータベースから)データを抽出します

GoldenGateのサブセットレプリケーションを使用して多くのデータソースから中

央のオペレーショナルデータストア(ODS)にデータを抽出変換集約します

ODSは企業にとって大きな収益源となるミッションクリティカルなアプリケーショ

ンシステムをサポートしていますActive Data Guardスタンバイデータベースを使

用して ODSを保護し最適なデータの保護と可用性を実現します

GoldenGateのマルチマスターレプリケーションを使用してそれぞれ異なる地域に位

置している複数のデータベースを同期しますGoldenGateの各コピーに停止が発生し

た場合にデータ損失ゼロのフェイルオーバーを可能にする専用のローカル同期 Data

Guardスタンバイデータベースがあります

災害復旧のプランニング

DRプランニングの一環として次の各ステップを検討し様々なDRシナリオへの準備を万全な

ものとしてください

自動化

自動化により再デプロイメントに要する時間を大幅に短縮しRTOとRPOの目標を改善するこ

とができますまたDRプロセスでの一貫性が確保され人的エラーが最小限に抑えられます

Oracle Cloud Infrastructureには自動化スクリプトの開発用にいくつかのSDKとCLIが用意され

ていますさらにOracle Cloud InfrastructureはTerraformテンプレートによるクラウド環境全体

のプロビジョニングと再構築をサポートするTerraformプロバイダも提供しています

障害検出

どのようなDRソリューションでもクラウド環境内の障害を検出するための信頼性が高くタイム

リーな方法が必要ですアプリケーションスタック内ではアプリケーションの状態を監視で

きなければなりませんOracle Cloud InfrastructureにはOracle Cloud Infrastructureサービスの

状態が表示されるサービスヘルスダッシュボードが用意されていますサービスヘルス

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 24: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

24 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE

イベントをサブスクライブするとOracle Cloud Infrastructureサービスの状態に関する最新情報

を受け取ることができます

災害復旧のテスト

DRソリューションに問題がないことを確認するためにDRテストを定期的に実施する必要があ

りますテストはDRプランの潜在的な不備を特定しDRソリューションの有効性を証明する

のに役立ちますアプリケーションへの影響を最小限に抑えるにはテスト期間を慎重に選ぶ必

要がありますまたテスト中に障害が発生した場合正常な状態にリストアできなければなり

ません

結論

Oracle Cloud Infrastructureは可用性とスケーラビリティに優れたクラウドインフラストラク

チャおよびサービスを提供し信頼性が高くセキュアで効果的なアプリケーションのDRを実現し

ますこのホワイトペーパーではいくつかの一般的な災害シナリオとDRソリューションのデ

プロイメント戦略について概説していますまたOracle Cloud Infrastructureでのアプリケー

ションDRソリューションを設計し実装する方法についてのベストプラクティスを示していま

参考資料

Oracle Maximum Availability Architecture (MAA)

o 概要

o ベストプラクティス

o ホワイトペーパー

Disaster Recovery to the Oracle Cloud white paper

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom

Page 25: Oracle Cloud Infrastructure での 災害復旧のベスト …...3 | BEST PRACTICES FOR DISASTER RECOVERY IN ORACLE CLOUD INFRASTRUCTURE 目次 免責事項 2 改訂履歴 2 概要

Oracle Corporation World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone +16505067000

Redwood Shores CA 94065 USA Fax +16505067200

Copyright copy2019 Oracle andor its affiliatesAll rights reserved本文書は情報提供のみを目的として提供されておりここに記載さ

れている内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述に

よる明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる

他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によっ

て直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることな

くいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません

Oracleおよび Javaはオラクルおよびその関連会社の登録商標ですその他の社名商品名等は各社の商標または登録商標である

場合があります

IntelIntel XeonはIntel Corporationの商標または登録商標ですすべてのSPARCの商標はライセンスをもとに使用しSPARC

International Incの商標または登録商標ですAMDOpteronAMDロゴAMD OpteronロゴはAdvanced Micro Devices Incの

商標または登録商標ですUNIXはThe Open Groupの登録商標です0119

Best Practices for Disaster Recovery in Oracle Cloud Infrastructure

2019年 1月

著者 Shan Guptaおよび Changbin Gong

C O N N E C T W I T H U S

blogsoraclecomoracle

facebookcomoracle

twittercomoracle

oraclecom