DR方式の選択

ブロック・ボリュームのバックアップおよびリストア

バックアップの主な目的は、ビジネスの継続性、ディザスタ・リカバリおよび長期的なアーカイブをサポートすることです。

ブロック・ボリューム・バックアップの一般的なユースケースを次に示します。

同じボリュームの複数のコピーを作成します。バックアップは、同じデータを含む必要がある多くのボリュームを持つインスタンスが必要な場合に役立ちます。
後で新しいボリュームにリストアできるようにスナップショットを取得する場合。
プライマリ・ボリュームで問題が発生した場合に備えて、データの信頼できるコピーを確保します。

バックアップ計画と目標を定義するときは、次の点を考慮してください。

頻度: データをバックアップする頻度。
リカバリ時間: バックアップがリストアされて、そのバックアップを使用するアプリケーションからアクセスできるように待機する時間。バックアップを作成する時間は、バックアップされるデータのサイズや、前回のバックアップから変更されたデータの量など、いくつかの要因によって異なります。
格納されるバックアップの数: 使用可能な状態にしておく必要があるバックアップの数と、不要になったバックアップの削除スケジュール。

バックアップを作成してバックアップからリストアする場合は、次のベスト・プラクティスを考慮してください。

バックアップを作成する前に、データに整合性があることを確認してください: ファイル・システムの同期、可能な場合はファイル・システムのアンマウントおよびアプリケーション・データの保存。ディスクのデータのみがバックアップされます。バックアップの作成中、バックアップ状態がREQUEST_RECEIVEDからCREATINGに変わったら、ボリュームへのデータの書込みを再開できます。バックアップの進行中は削除できません。
元のボリュームがアタッチされたコンピュート・インスタンスにリストアされたボリュームをアタッチする場合、一部のオペレーティング・システムでは同一ボリュームのリストアがサポートされていないことに注意してください。この制約を克服するには、ボリュームを復元する前にパーティションIDを変更します。オペレーティング・システムのパーティションIDを変更するステップは、オペレーティング・システムによって異なります。コンピュート・インスタンスのオペレーティング・システムのドキュメントを参照してください。
バックアップが正常に作成されたことを確認するまでは、元のボリュームを削除しないでください。

アプリケーションで複数のコンピュート・インスタンスにまたがる複数のボリュームを使用する場合は、ボリューム・グループ・バックアップを使用します。ボリューム・グループは、複数のインスタンス間で複数のボリュームを使用するアプリケーションのバックアップおよびクローンの作成プロセスを簡略化します。次の図に示すように、ボリューム・グループ・バックアップからボリュームのグループ全体をリストアできます。

図volume- backup- restore.pngの説明

パイロット・ライトの作成

パイロットライトという用語は、常に点灯し、家庭内の温度センサーによってトリガーされたときにすぐにヒーターを再起動するために使用できる従来のガス駆動ヒーター内の小さな炎を指します。DRのコンテキストでは、パイロット・ライトは、アプリケーションの重要なコア・コンポーネントで構成され、DRサイトにデプロイされ、最新のアプリケーション構成および重要なデータが含まれています。これらのコアパイロットライトコンポーネントは、障害発生時に本番サイズの環境を復元するために使用できます。

次に、DRサイトにおけるパイロットライトの重要なコンポーネントを示します。

データベース層
Oracle Cloud Infrastructure Databaseサービスでは、本番サイズのリソースを有効にせずに、DRサイト(可用性ドメイン、リージョンまたはその両方)にデータベース全体をプロビジョニングできます。DRがアクティブ化されると、データベース・サーバーを再起動せずに、サービスへの単一のREST APIコールを使用して、より多くのリソースを有効にできます。
アプリケーション層
DRサイトに1つのアプリケーション・サーバー(可用性ドメイン、リージョンまたは両方)のみをデプロイし、最新の構成をすべて含めます。Oracle Cloud Infrastructureのカスタム・イメージ機能を使用してOSおよびアプリケーションを定期的にバックアップし、これらのイメージを使用してDRサイトがアクティブ化されるときに新しいサーバーをプロビジョニングできます。

たとえば、本番サイトに8つのアプリケーション・サーバーが含まれている場合、DRサイトに1つのアプリケーション・サーバーのみをデプロイし、rsyncまたは別のツールを使用してプライマリ・サイトと同期したままにします。DRがアクティブ化されるときに残りの7つのサーバーをプロビジョニングするために使用できる、このサーバーからDRサイトに毎日カスタムイメージを作成します。
ネットワーク層
DRサイトのパイロット・ライトにある次のOracle Cloud Infrastructure機能およびサービスを使用します
- IPアドレス(プライベートおよびパブリック)
- DNSサービス
- ロード・バランシング・サービス

アクティブ・スタンバイの使用

アクティブ・スタンバイ(マウントされたスタンバイに対して)は、データベースのリカバリ中に読取り専用でオープンしているスタンバイです。アクティブ・スタンバイには、Active Data Guardの機能およびライセンスが必要です。

Active Data Guardでは、フィジカル・スタンバイを読取りおよびレポートに利用して、プライマリ上の潜在的なワークロードを削減できます。Active Data Guardは、物理データ破損の自動ブロック修復による包括的なデータ保護を提供し、書込みの損失や論理ブロック破損など、その他のタイプのデータ破損がないかチェックします。マウントされたスタンバイでは、物理ブロック破損の自動ブロック修復を除き、データ保護の多くのメリットを利用できます。スタンバイ・データベースにフェイルオーバーすると、通常、リカバリ時間(RTO)およびデータ損失(RPO)は、オープン読取り専用かどうかに関係なく非常に低くなります。

DR方法を選択するときは、対称リソースと非対称リソースのどちらを使用するかを考慮してください。

対称リソース: これは、スタンバイがプライマリ・システムと対称で、ロール遷移時にアプリケーションとデータベースのパフォーマンスが類似または同一になるように、推奨されるアーキテクチャです。また、スタンバイ・データベースに本番ワークロードに対応するための十分なリソースがあることも保証されるため、障害発生時にデータ損失を最小限に抑えることができます。アクティブ・スタンバイ・データベースとして、またはActive Data Guardオプションを指定してデプロイした場合、DR保護を提供している間、スタンバイは読取り専用でオープンされます。これにより、レポートおよび問合せをオフロードできます。
非対称リソース: このアーキテクチャは、スタンバイ環境のスケール・ダウン構成です。Active Data Guardでは、スタンバイが読取り専用になるため、スタンバイに作業をオフロードするのと同じ利点が得られます。ただし、フェイルオーバー後、プライマリに一致するようにシステムをスケール・アップしないかぎり、パフォーマンスは同じでない場合があります。

非対称または小規模なスタンバイ・システムでは、コストを削減するために計算、CPUおよびメモリーが少なくなる場合があります。トレードオフは、ロール推移またはフェイルオーバー・イベントの後に、以前のプライマリ・システムと一致するようにスケール・アップ(拡張)するか、パフォーマンスの低下または機能の低下を受け入れる必要があります。

コールド・スタンバイの使用

コールドスタンバイという用語は、プライマリ環境の冗長レプリカがDRサイトで配備されるDRシナリオを記述するために使用されます。コールド・スタンバイ環境は、プライマリ・システムに障害が発生した場合にのみアクティブ化されます。この方法では、スイッチオーバーのアクティブ化時間が明確に定義された本番継続性を提供します。

Oracle Cloud Infrastructureでは、このような環境を維持するコストを最小限に抑えるコールド・スタンバイ環境の自動(プログラム)デプロイメントがサポートされています。DRサイトで使用しているアクティブなリソースおよび永続ストレージに対してのみ請求されます。