Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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