※ 本記事は、Nilay Panchalによる”Introducing Backup-Based Disaster Recovery: A low-cost DR option for databases with higher RTO tolerance“を翻訳したものです。

クラウド・ディザスタ・リカバリ（DR）戦略をよく考えれば、ビジネスの財務と運用の評判に大きなメリットがあります。クラウドまたはオンプレミスでアプリケーションまたはプラットフォームを実行している場合、ディザスタ・リカバリ設定を行うことは、データを安全に保ち、あらゆる種類の停止が発生した場合のダウンタイムを最小限に抑えるために重要です。次の点に注意してください。:

1. ディザスタ・リカバリは、データ損失に対するセーフティ・ネットを提供します。自然災害やサイバー攻撃などの災害が発生した場合、データ損失は重大なリスクです。障害時リカバリを構成すると、障害の発生前にデータベースを以前の状態にリストアできます。つまり、すべてのデータが失われるわけではなく、最初から作業を開始せずに迅速に再開できます。

2. 停止時間の最小化: DR設定では、データベースが停止したときの状況をカバーし、業務に重大な影響を及ぼさないようにし、データベースを以前の状態に回復して、ダウンタイムを最小限に抑え、ビジネスの継続性を確保します。

3. ネット費用対効果: ビジネスのダウンタイムのコストは、ディザスタ・リカバリ計画に投資するよりもはるかに重要です。安定したDR計画を立てることで、収益の損失、生産性の低下、ダウンタイムによるその他の費用を回避できます。

4. コンプライアンス要件: 多くの業界では、障害回復およびバックアップ計画に関する特定のコンプライアンス要件があります。優れたディザスタ・リカバリ・サービスにより、これらの要件を満たすことができます。

このようなリスクから保護するために、Autonomous Database（ADB）は、Autonomous Data Guard（AuDG）のスタンバイを提供します。これは、前のブログ投稿でお読みになった可能性があります。前の投稿で詳細に説明されているように、AuDGは、ビジネス・クリティカルなシステムでADBで使用可能な障害時リカバリ・サービスの最高レベルです。お客様からのフィードバックをいただき、素晴らしいユーザーからお届けいたしました。現在利用可能な2番目のディザスタ・リカバリ・タイプを、AuDGより低コストで提供していますが、リカバリ時間は長く、クリティカルでない非本番システムの場合はバックアップベースのディザスタ・リカバリです。名前が示すように、バックアップベースのDRは、AuDGのような物理的なリフレッシュ・スタンバイを提供することではなく、データベースに使用可能な最新のバックアップおよびREDOログを使用してデータベースをインスタンス化することによる停止からのリカバリを提供します。

これは、Autonomous Data Guardとは異なり、単にスタンバイしているバックアップ・コピーで追加のCPU使用量に対して請求されないことも意味し、このDRオプションのコストを大幅に削減します。ローカル・バックアップ・コピーはデータベースの自動バックアップを使用するため、追加コストは発生しません。クロスリージョン（リモート）バックアップ・コピーは、リモート・リージョンにレプリケートされるバックアップ・データに使用されたストレージの2倍（2x）に対してのみ請求されます（OCPUベースのデータベースのデータベース・ストレージとして請求され、ECPUベースのデータベースのバックアップ・ストレージとして請求されます）。

より詳細な情報と、この新しい障害時リカバリ機能の使用方法を学習しながら、障害時リカバリの用語について詳しく説明します。:

ディザスタ・リカバリ（DR）ピア: 相互にピアリング（リンクおよびレプリケート）される2つ以上のデータベース。ADBでは、ピアはプライマリ（ソース・データベース）、Autonomous Data Guard Standby（リフレッシュ、プライマリの物理コピー）またはバックアップ・コピーです。

スイッチオーバー: プライマリ・ピアとDRピアの間で役割の切り替えをトリガーできるユーザー操作です。スタンバイ/バックアップ・コピーはプライマリ・ロールを引き継ぎ、プライマリはスタンバイ/バックアップ・コピーに切り替わります。スイッチオーバーは、データ損失が保証されない場合にのみ成功するため、障害時リカバリ設定のテスト中に推奨される操作です。

フェイルオーバー: これは、プライマリとDRピア・データベースの間でロールを切り替えるためにトリガーできるユーザー操作です。ただし、スイッチオーバーとは異なり、フェイルオーバーをトリガーすると、データ損失が発生する場合があります。通常、実際の障害時にはフェイルオーバーをお薦めします。

プライマリまたはソース・データベース: ユーザーまたはアプリケーションからの読取りおよび書込みにアクティブに使用されているメイン・データベース。

Autonomous Data Guardスタンバイ・データベース: プライマリ・データベースからデータを常にパッシブにリフレッシュ（レプリケート）するプライマリ・データベースのレプリカ。このスタンバイ・データベースは、プライマリに障害が発生した場合に使用されます。

バックアップ・コピー: これは、バックアップベースのディザスタ・リカバリで今日導入された新しいタイプのディザスタ・リカバリ・ピアです。このタイプのピアはフィジカル・スタンバイ・データベースではなく、単にソース（プライマリ）データベースから格納されたバックアップのセットであり、スイッチオーバーまたはフェイルオーバー時に新しいデータベースをインスタンス化するために使用されます。

ローカル（同じリージョン）ピア: このタイプのディザスタ・リカバリ・ピアは、ローカルの停止（ローカライズされたディスク破損やネットワーク障害など）からシステムを保護します。ローカル・ピアは、プライマリ・データベースとは異なるアベイラビリティ・ドメイン（AD）、複数のADを持つリージョン、または1つのADのみを持つリージョン内の異なるExadataマシンにあります。

リモート（クロスリージョン）ピア: このタイプのディザスタ・リカバリ・ピアは、地域の完全な停止（自然災害や完全なリージョン・ネットワーク停止など）からシステムを保護します。リモート・ピアはプライマリ・データベースとは異なるリージョンにあります。

目標復旧地点（RPO）: データ損失に対する組織の最大許容範囲。その後、ビジネス業務に大きな影響を与え、通常は数分で表現されます。低い方が良い。

目標復旧時間（RTO）: ビジネス業務に深刻な影響を与え始めるサービスの使用不可（または停止時間）に対する組織の最大許容範囲。通常は数分で表現されます。低い方が良い。

ADBでのディザスタ・リカバリ・オプションの表示および管理

最もシンプルなユーザー・エクスペリエンスを実現するために、新しいバックアップベースのディザスタ・リカバリは、以前のAutonomous Data Guardオプションとほぼ同じように見え、Oracleによって完全に管理されています。つまり、わずか数回のクリックで数分間待つだけで、完全に機能するバックアップベースのディザスタ・リカバリ・ソリューションを利用できます。

データベース・インスタンスのリストから選択したデータベース名をクリックして、Oracle CloudのAutonomous Databaseコンソールに移動する方法はすでにわかっています。下にスクロールして「Disaster Recovery」タブを選択し、障害回復ピアを表示します。

ディザスタ・リカバリ設定の一部として、1つのローカル・ピアと1つのクロスリージョン（リモート）ピアを指定することもできます。各ピアは、バックアップ・コピーまたはAutonomous Data Guard Standbyのいずれかです。

AuDGがすでに有効になっていないすべてのデータベースには、デフォルトでローカルのバックアップベースのディザスタ・リカバリが付属しており、アクションは必要ありません。これは、ADBがすでにローカル（同じリージョン）バックアップを自動的に取得しているためで、ADBはこれらのバックアップを利用するため、ローカル・バックアップ・コピーを有効にするための追加コストはありません。

AuDGと同様に、ローカル・バックアップ・コピーへのスイッチオーバー/フェイルオーバーはシームレスで、データベースに接続するためにウォレットまたは接続文字列を変更する必要はありません。

ローカルDRオプションをAuDGにする場合は、「DRタイプの更新」を選択し、データベースのRTO/RPO要件に従ってローカルDRピアをAutonomous Data Guardに更新できます。非常に重要な本番システムでは、Autonomous Data Guardでデータベースを使用する必要があります。

ADBターゲットがドキュメントに表示できる完全なRTOおよびRPOサービス・レベル目標。

バックアップベースのディザスタ・リカバリが有効な場合、RTOはデータベースのサイズに基づきます。SLOターゲットは次のとおりです。:

ローカルおよびクロスリージョンのバックアップ・コピー: RTO = (1hr + 1hr per 5TB) mins, RPO = 1 min

Autonomous Data Guardスタンバイを有効にすると、SLOターゲットは次のようになります。:

ローカル・スタンバイ・データベース: RTO = 2 mins, RPO = 1 min

クロスリージョン・スタンバイ・データベース: RTO = 15 mins, RPO = 1 min

ローカル・バックアップ・コピーに加えて、「ピア・データベースの追加」を選択してクロスリージョン・バックアップ・コピーを追加することもできます。リモートの有料リージョンを選択します（テナンシはリモート・リージョンにサブスクライブされている必要があります）。リモート・ピアを追加するときに、アクセス・コントロール・リスト（ACL）またはプライベート・エンドポイントを適用する場合は、オプションでピア（VCN、サブネットなど）にリージョン固有のネットワーキング詳細を指定できます。また、VCN間でプライベート・ピア・データベースに接続する場合は、オプションでソース・リージョンとリモート・リージョンのVirual Cloud Networks（VCN）をピアリングすることもできます。

クロスリージョン・バックアップ・コピーへのスイッチオーバー/フェイルオーバー後に、リモート・ピアに接続するには、リモート・ピアのウォレットまたは接続文字列を使用する必要があります。詳細は、リモート・ピアの接続文字列/ウォレットに関するドキュメントをお読みください。同様に、リモート・データベースのDatabase Actionsからそれぞれのデータベース・ツールURL（APEX、OML、ORDSなど）を使用します。

ローカルDRピア・オプションと同様に、データベースのRTO/RPO要件に従って、Autonomous Data Guardをリモート・ピアとして選択できます。非常に重要な本番システムでは、Autonomous Data Guardでデータベースを使用する必要があります。

データベースを保護するために必要なのはそれだけです。これで、バックアップベースのピアが緑色になるまでプロビジョニング状態になり、「スタンバイ」状態で使用できるようになります。プライマリ・データベースのサイズによっては、必要なバックアップのコピーに数分または時間かかる場合があります。

プライマリおよびバックアップ・コピーとしてのピアのロールと、識別可能なディザスタ・リカバリ・タイプ（バックアップベースまたはAutonomous Data Guard）に注意してください

DRが設定されたので、ディザスタ・タイプのシナリオで使用したり、Autonomous Databaseディザスタ・リカバリ・ピアに対してアプリケーション/中間層をテストしたりする機能を次のすべて説明します。

スイッチオーバー – DRピアに切り替えたりテストしたりするための、データ損失のない保証された第1防御線

ピアがプロビジョニングされると、データベース・コンソールおよび「ディザスタ・リカバリ」タブのメニュー・オプションに「スイッチオーバー」オプションが表示されますが、ピア・データベースは両方とも正常です（「使用可能」、「スタンバイ」または「停止」状態）。「スイッチオーバー」ボタンをクリックし、ローカル・ピアまたはリモート・ピアを選択すると、ロールの変更が実行され、プライマリ・データベースとバックアップ・コピーの間でロールが切り替えられ、データ損失は保証されません。バックアップ・コピーを使用すると、データベースのサイズによっては、バックアップベースのDRで数分または数時間かかる場合があります（上からRTOを覚えておいてください）。この時点で、格納されたバックアップからデータベースがインスタンス化されるためです。

AuDGと同様に、クロスリージョン（リモート）ピアに切り替えるには、リモート・リージョン・ピアからスイッチオーバーをトリガーします。

スイッチオーバーによってデータ損失が保証されないため、障害シナリオではまずスイッチオーバーを試行することをお薦めします。スイッチオーバーが失敗した場合にのみフェイルオーバーに頼ります。また、スイッチオーバーを使用して、ディザスタ・リカバリ構成およびこのロール変更動作に対してアプリケーションをテストすることをお薦めします。

フェイルオーバー – 主要な停止が原因でプライマリ・データベースが停止すると、ディザスタ・リカバリ・ピアによって保護

障害が発生し、プライマリ・データベースが停止した場合は、スタンバイにフェイルオーバーできます。フェイルオーバーは、DRピアが使用可能であり、「スタンバイ」状態である間、ロール変更です。プライマリがアクセス不可の場合、または停止のためにスイッチオーバーが失敗した場合、プライマリデータベースからピアに切り替わります。ここでのUIでは、フェイルオーバーを試行する前に、まずスイッチオーバーを試行することをお薦めします。フェイルオーバー・オプションが表示されるのは、スイッチオーバーが失敗した場合のみです。APIのコール中、必要に応じてスイッチオーバーまたはフェイルオーバーをトリガーできます。

フェイルオーバー中、システムは可能なかぎりデータを自動的に回復し、潜在的なデータ損失を最小限に抑えますが、前述のとおり、数秒または数分のデータ損失が発生する可能性があります。通常、フェイルオーバーは実際の障害シナリオでのみ実行し、可能なかぎり早くデータベースをオンラインに戻すため、数分間潜在的なデータ損失を受け入れます。

AuDGと同様に、クロスリージョン（リモート）ピアにフェイルオーバーするには、リモート・リージョン・ピアからスイッチオーバーをトリガーします。また、バックアップコピーのRTOが大幅に長いため、ローカル AuDGのように、バックアップベースの障害回復ではローカルDRの自動フェイルオーバーは提供されません。設定で自動フェイルオーバーが必要な場合は、Autonomous Data Guardを使用します。

スイッチオーバーまたはフェイルオーバーが完了し、スイッチオーバー元のリージョンまたはマシンが使用可能になると、再度、接続された以前のプライマリ更新が自動的に表示され、障害回復ピアとして使用できるようになり、必要に応じてスイッチオーバーまたはフェイルオーバーして戻すことができます。

データベース・コンソールの「作業リクエスト」タブで、障害時リカバリの設定（およびその他のADBアクション）の進行状況およびアクションを追跡できます。

前述のとおり、データベースUIコンソールのすべてのオプションについて説明します。もちろん、Oracleの残りのクラウド・プラットフォームと同様に、自動化ニーズに応じていつでもスクリプト化できる、スイッチオーバーやフェイルオーバーなど、前述のすべてのアクションに対するAutonomous Database APIがあります。DRピアの操作が通知されるように、有用なイベントをサブスクライブすることもできます。公式のドキュメントを参照して、バックアップ・コピーおよびスタンバイ・データベースに関するすべての詳細を確認します。バックアップベースのディザスタ・リカバリは、Autonomous JSON DatabaseとAPEXサービスといった他のAutonomousワークロード・タイプでも使用できます。

結論として、バックアップベースのディザスタ・リカバリでは、Autonomous Databaseのディザスタ・リカバリと非常に信頼性の高いストーリーに、クリティカルでアクセス可能な部分が追加されています。データベースで有効にすることで、データを保護し、ダウンタイムを最小限に抑え、ビジネスの継続性を確保できます。これは、データの損失やダウンタイムのリスクを回避し、コンプライアンス要件を満たしながら安心して遵守するためのコスト効率の高い方法です。

この新しい低コストのディザスタ・リカバリ・オプションがあれば、言い訳はできません。Autonomus Databaseのすべてのユーザーは、この使いやすい機能を使用し、ローカルおよび地域の障害に対して適切に保護する必要があります。

私の書いたものが好きですか? Twitterでフォローしてください!