ディザスタ・リカバリ
適切に設計したディザスタ・リカバリ(DR)計画を使用すると、障害から迅速にリカバリし、継続的にユーザーにサービスを提供できます。
DRは、障害に対する準備および障害からのリカバリのプロセスです。障害とは、ネットワークの停止から機器やアプリケーションの障害、自然災害に至るまで、アプリケーションをリスクにさらすあらゆるイベントです。自動車事故がいつ起きるかを予測できないように、ディザスタ・リカバリがいつ必要になるかを予測することはほとんど不可能です。障害がいつ発生するかを制御できないのであれば、次善の策はリカバリ・プロセスを制御できるようにすることです。
適切に設計したDR計画を使用すると、障害から迅速にリカバリし、ビジネス継続性を実現できます。組織がワークロードをクラウドに移行する際には、レジリエンスのあるオンプレミス・システムをクラウドに構築する方法に関する見解をわかりやすく説明する必要があります。Oracle Cloud Infrastructure (OCI)は、クラウドのワークロードを迅速、確実かつ安全にリカバリできるように、可用性が高くセキュアでスケーラブルなインフラストラクチャおよびサービスを提供しています。
従来のオンプレミス・エンタープライズ・アプリケーションでは複数層または3層アーキテクチャが一般的であるため、3層エンタープライズ・アプリケーションを例にとり、OCI DR機能および信頼性と自己回復性のあるクラウド・トポロジのベスト・プラクティスを使用してアプリケーションの障害からのレジリエンスを高める方法を示します。次の図は、ウォーム・スタンバイDR構成のエンタープライズ・アプリケーションの例を示しています。
DRの概念
DRの計画における最初のステップでは、リカバリ時間目標(RTO)とリカバリ・ポイント目標(RPO)を決定します。
RTOは、障害が発生してから特定のアプリケーションをリストアする必要があるターゲット時間です。通常、クリティカルなアプリケーションであればあるほど、RTOは低くなります。
RPOは、アプリケーションがデータ損失を許容できる、障害が発生してからその障害がビジネスに影響を与え始めるまでの期間です。
障害発生後のアプリケーションのリカバリを保証する、コスト効率の高い計画を構築するには、リカバリのターゲット時間とデータ損失の許容量の両方を考慮する必要があります。
詳細は、クラウド・トポロジを障害から保護するためのベスト・プラクティスを参照してください。
DRアプローチの選択
アプリケーションによってクリティカルの度合が異なります。選択するDRソリューションは、可用性、データ耐久性、RTO、RPOなど、考えられる多くの要件に依存します。
複数層エンタープライズ・アプリケーションをOCIにデプロイする際に使用するOCI DR機能を決定するには、次の表のDR方法を評価してください。
DR方法 | RPO | RTO | コスト |
---|---|---|---|
バックアップおよびリストア | 時間 | 時間 | $ |
パイロット・ライト | 分 | 分 | $$ |
ウォーム・スタンバイ | 秒 | 分 | $$$ |
アクティブ/アクティブ | ほぼゼロ | ゼロの可能性あり | $$$$ |
DRおよび高可用性(HA)のシナリオでは、リージョンとリージョン内の可用性ドメインの両方を考慮してください。リージョンは限定された地理的領域で、可用性ドメインはリージョン内に配置された1つ以上のデータ・センターです。DR計画でDRサイトを物理的に離れた場所に置く必要がある場合、複数の領域を使用すると、この目標を達成できます。
このエンタープライズ・アプリケーションの例では、リージョンの停止に耐えることができるが、リージョンが影響を受けてもある程度のダウンタイムには対処できるようにする必要があります。これらの理由から、ここでは複数のリージョンへのウォーム・スタンバイ・デプロイメントを選択しました。
フル・スタックDRによるDRオーケストレーションの管理
フル・スタック・ディザスタ・リカバリ(DR)は、多くの異なるシステムのDR操作を編成するためのシンプルで一貫性のあるインタフェースを提供するOCIネイティブ・サービスです。これにより、IT操作で認可されたユーザーは、基礎となるリカバリ・プロセスを理解しなくてもフェイルオーバーまたはスイッチオーバーをトリガーしやすくなります。
Full Stack DRは、OCI向けのOracle初の真のディザスタ・リカバリ・アズ・ア・サービス(DRaaS)ソリューションであり、単なるオーケストレーション・エンジンではありません。Full Stack DRは、スケーラビリティに優れた拡張性の高いDR管理サービスで、世界中のどこからでも、2つのOCIリージョン間のクリティカルなビジネス・システムとクリティカルでないビジネス・システムのテスト、移行、リカバリに必要なステップを1回のクリックで完全に自動化します。
企業が大規模なリカバリに直面する問題
貴社には、OCIテナンシでホストされているミッションおよびビジネス・クリティカルなアプリケーションがほんの一部しかありません。To complicate things, every one of these Oracle or non-Oracle applications has a different recovery process with different recovery point and recovery time objectives.また、各異なるアプリケーション・スタックのリカバリ・プロセスは複雑になる可能性があり、最も上級の技術専門家が十分に注意を払う必要があります。
IT組織には、おそらく1日または2日に1つまたは2つの異なるアプリケーションを回復するスキルと決意があり、会社の最も上級のITスペシャリストからの全面的な労力です。しかし、IT組織が、複数のシステムを同時にリカバリする見込みに直面した場合はどうなりますか。
フル・スタックDRで大規模なリカバリが容易
Full Stack DRは、多数のシステムを同時にリカバリする必要がある場合に、最も熟練した技術エキスパートが関与することなく、DRワークフローを大規模に処理するように設計されています。Full Stack DRは、OCIコンソールを通じて一貫性のあるシンプルな方法を使用して、DR操作の実行方法と監視方法を正規化します。
Full Stack DR organizes various applications into independent protection groups without changing anything about the way you’ve installed and configured your existing Oracle and non-Oracle applications in OCI.Full Stack DRでは、アプリケーション・スタックの1つのコンポーネントのみをリカバリすることも、1回のクリックでアプリケーション・スタック全体をリカバリすることもできます。必要な操作を選択できます。
Full Stack DR、DR計画の準備状況を検証
Full Stack DRは、組み込みの完全に自動化されたDR準備状況チェックにより、重要なビジネス・システムが予期しないサービスの中断に備えていることを検証するのに役立ちます。事前チェック機能は、DR操作中にFull Stack DRがステップスルーするタスクのリストに自動的に追加されます。
事前チェックは無停止であり、本番システムを妨げることなく、いつでも実行できます。DR計画の健全性を検証するには、ネットワーク、ストレージ、コンピュート、Oracleデータベース、およびDR計画に追加したカスタム・スクリプトがどこに存在し、準備ができているかを確認します。
あらゆるデプロイメント・アーキテクチャを管理する柔軟性
柔軟性は、Full Stack DRの設計の背後にある重要な概念です。ビジネス・システムごとに異なるリカバリ・ソリューションが必要です。したがって、Full Stack DRは、技術的およびビジネスニーズに合った方法で個々のビジネスシステムを回復するために必要な方法に準拠しています。ディザスタ・リカバリ用にビジネス・システムをインストールおよびデプロイする方法はユーザー次第です。
オラクルのDRaaSソリューションは、VMフェイルオーバー、パイロット・ライト、コールド・スタンバイ、ウォーム・スタンバイ、ホット・スタンバイ、アクティブ/アクティブのいずれかにデプロイされているかに関係なく、個々のビジネス・システムごとに異なる方法でリカバリを管理できます。デプロイメントを処理し、リカバリを処理します。
Full Stack DRの詳細
Full Stack DR gives you the power and flexibility to implement DR for Oracle or non-Oracle applications in OCI the way you want, not the way we want.
DR設計に関する考慮事項
実装するDR方法に応じて、考慮すべきことがたくさんあります。
DR機能のバックグラウンド情報は、Oracle CloudのDR機能を参照してください。この例では、ウォーム・スタンバイ・メソッドと、リージョン間デプロイメントの2番目のリージョンを含むウォーム・スタンバイの実装に必要なOCIリソースを確認します。
ネットワーキング
それぞれのリージョンで仮想クラウド・ネットワーク(VCN)およびサブネットのネットワーク基盤を作成した後、DRを構成するには、ネットワーク接続を容易にするために異なるリージョン内のVCNをピアリングする必要があります。
コンピュート
2つのリージョン内のコンピュート・インスタンスに対してアプリケーションを実行するには、両方のリージョンでコンピュート・イメージを使用可能にする必要があります。DRのリージョンで、ウォーム・スタンバイを保守するための最小限の設定をデプロイします。次に、容量予約を使用して、DRリージョンがプライマリになったときにすべてのVMを実行するために必要な残りの容量を予約します。詳細は、コンピュート・サービスの概要およびコンピュート・インスタンスのベスト・プラクティスを参照してください。
ストレージ
OCIは、ブロック・ボリューム、ファイル・ストレージおよびオブジェクト・ストレージを含む一連のストレージ・サービスを提供し、データの複数のコピーを維持することで、組込みの冗長性と高可用性機能を提供します。これらのストレージ・サービスは、クロス・リージョン・ディザスタ・リカバリ用に構成できるネイティブ・レプリケーションも提供します。
オブジェクト・ストレージは、信頼性とコスト効率の高いデータ耐久性を実現する、インターネット規模の高パフォーマンス・ストレージ・プラットフォームです。Object Storageは、リージョン別サービスであり、リージョン内のすべての可用性ドメインで使用できます。オブジェクト・ストレージ・レプリケーションは、DRの目的でリージョン間で構成できます。
ブロック・ボリュームには、ディザスタ・リカバリに役立つ完全管理型の非同期レプリケーション機能があります。リカバリ時間目標(RTO)が1分未満の場合は、ボリュームおよびボリューム・グループを別のリージョンにレプリケートできます。自動バックアップ機能を使用して、ボリュームおよびボリューム・グループに対してクラッシュ整合性のあるバックアップを生成することもできます。これらのバックアップは、別のリージョンに自動的にコピーできます。
OCIの他のストレージ・サービスと同様に、File Storageには、別の可用性ドメインおよびリージョンに非同期でレプリケートするためのレプリケーション機能が組み込まれています。ファイル・ストレージのクローニング機能を使用すると、ターゲット側のデータがほぼ瞬時に(RTO)使用可能になります。DRの完全な操作性を実現するために、レプリケーションでは、メインファイルシステムデータを使用してスナップショットもレプリケートされます。
データベース
高可用性設計は、ノードまたはネットワーク障害などのIaaS障害イベントの場合にアプリケーションの可用性を確保することを目的としています。データベースDRシナリオでは、リージョン全体または可用性ドメインに影響を与えることが多いプライマリ・データベースへの重大な停止および避けられない停止による重要なビジネス・データの損失を防止します。
Maximum Availability Architecture (MAA)は、Oracle高可用性テクノロジ、データ保護およびディザスタ・リカバリ・テクノロジを統合して使用するために、Oracleのエンジニアによって何年にもわたって開発された一連のベスト・プラクティスおよびリファレンス・アーキテクチャです。
DR設計の主な考慮事項は、アプリケーションが許容できるデータ損失の量であるRPO (回復ポイント目標)と、システムがオンラインに戻る前にアプリケーションが許容できる最大回復時間であるRTO (回復時間目標)です。これらに基づいて、MAAはコストと複雑さの増加とともに定義する様々なカテゴリがあります。これらはブロンズ、シルバー、オーラス、ゴールド、プラチナに分類され、それぞれが複雑さと回復力を徐々に高めています。これらは、MAAで指定されたDR参照アーキテクチャの基礎となります。
最大可用性アーキテクチャ(MAA)層 | コア・アーキテクチャ | リカバリ・ポイント目標(RPO) | リカバリ時間目標(RTO) | Oracle Autonomous Database Serverless(ADB-S) | Oracle Autonomous Database on Dedicated Exadata Infrastructure (ADB-DおよびADB-C@C) | Oracle Base Database Service (VM) | 専用インフラストラクチャ上のOracle Exadata Database Service (ExaDB- D) | Oracle Exadata Database Service on Cloud@Customer(ExaDB-C@C) |
---|---|---|---|---|---|---|---|---|
ブロンズ | ローカル・バックアップとレプリケート・バックアップを備えた単一インスタンス | 最終バックアップ | 時間 | 即時利用可能 | 即時利用可能 | 即時利用可能 | 即時利用可能 | 即時利用可能 |
SILVER | ローカル・バックアップおよびレプリケートされたバックアップを使用するRAC | 最終バックアップ | 時間(計画メンテナンスではゼロ) | 即時利用可能 | 即時利用可能 | 2つのノードにすぐに使用できます(EE Extreme Performanceが必要) | 即時利用可能 | 即時利用可能 |
オーラス | リフレッシュ可能PDB | 最終リフレッシュ | 分 | + Autonomous Data Guard | オプションです | オプションです | オプションです | オプションです |
ゴールド | (アクティブ) Data Guardを介したクロスサイト・アクティブ/パッシブ・レプリケーションを使用するデータベース | ゼロ | 秒 | 適用されません。 | + Data Guard | + Data Guard (標準DGの場合はEE/EE HP、アクティブDGの場合はEE EPが必要) | + Data Guard | + Data Guard |
PLATINUM | クロスサイト・アクティブ/アクティブ・レプリケーションを使用するデータベース(GoldenGate経由) | ゼロ | ゼロ | + GoldenGate | + GoldenGate | + GoldenGate | + GoldenGate | + GoldenGate |
このDR設計および戦略では、Oracleデータベースでのデータ損失の防止について説明します。堅牢なDR戦略では、アプリケーションの継続的な可用性のための構成にも対応する必要があります。
MAAの基礎を形成する主な技術は次のとおりです。
- Recovery Manager (RMAN)
- リフレッシュ可能プラガブル・データベースの(PDB)
- Data GuardおよびActive Data Guard
- Autonomous Data Guard
- OCI Golden Gate
モニタリング
OCIモニタリングでは、クラウド・リソースをアクティブおよびパッシブでモニターして、可用性の向上と一貫したサービス・レベルを実現します。OCIステータス通知を購読し、サービス・ヘルス・ダッシュボードを確認していることを確認します。例については、Oracle Cloud Infrastructureで実行されているアプリケーションのエンドツーエンド・モニタリングを参照してください。
詳細の参照
ソリューション・プレイブック:
- Learn more about automating recovery for Oracle & non-Oracle applications
- 障害からのクラウド・トポロジの保護について学習
- Oracle Enterprise Performance Managementをクラウドにデプロイするためのインフラストラクチャの設計(DRアーキテクチャ: 複数のリージョン)
- クラウドのVMware SDDCを障害から保護
- CommvaultをデプロイしてクラウドのVMware SDDCを障害から保護
- ZertoをデプロイしてクラウドのVMware SDDCを障害から保護
- VeeamをデプロイしてクラウドのVMware SDDCを障害から保護
- ActifioをデプロイしてクラウドのVMware SDDCを障害から保護
リファレンス・アーキテクチャ:
- パイロットライト・ディザスタ・リカバリ(DR)トポロジの設計
- Data Guardを使用した複数のリージョンへのExadata Cloud Serviceのデプロイ
- RackWareを使用したクロスリージョン・ディザスタ・リカバリ・ソリューションのデプロイ
- テナンシ間のクロスリージョン・プライベート接続の構成
ドキュメントおよびその他のリソース: