※ 本記事は、Gregory Kingによる”OCI Full Stack Disaster Recovery expands its built-in capabilities for database and storage“を翻訳したものです。

2024年10月22日

Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery (DR)は、OCIでOracleデータベースおよびストレージ・サービスに7つの新機能が導入され、組み込み機能を引き続き拡張しています。これらの高度に期待される追加機能は、コンピュート、ストレージ、データベース、およびロード・バランサの完全に自動化されたフェイルオーバー、スイッチオーバーおよびディザスタ・リカバリ・ドリルのための、OCIサービスのより包括的なカバレージを提供します。

このブログ投稿では、新機能の概要を説明し、Full Stack DRがディザスタ・リカバリ保護グループ(DRPG)と呼ぶものに、リソースをメンバーとして追加するために必要な基本概念について説明します。

Full Stack DRがサポートするOCIストレージ・サービス

Full Stack DRでは、最近Object Storageが、ディザスタ・リカバリ操作中にサービスが自動的に管理できる新しいネイティブ・リソース・タイプとして導入されました。Full Stack DRは、次のすべてのOCIストレージ・サービスのリカバリを調整するようになりました:

  • Block Storage
  • File Storage
  • Object Storage

サポートされているOCIデータベース・サービス

Full Stack DRでは、他の4つのOCI Oracle Databaseサービスに対する組込みサポートも導入されました。お客様は、次のリストにあるOracleデータベースのOracle Cloudコンソールを使用してAutonomous Data GuardまたはData Guardを構成でき、Full Stack DRは、各データベース・サービスが提供するOCIネイティブAPIを使用してリカバリを編成し、Data Guardを使用してフェイルオーバーおよびスイッチオーバーをトリガーします。次のリストにあるリンクをクリックすると、新機能の詳細を確認できます。

  • Autonomous Database Serverless
  • Autonomous Dedicated Infrastructure
  • Autonomous Dedicated Cloud@Customer
  • Oracle Base Database Service
  • Oracle Exadata Database Service on Dedicated
  • Oracle Exadata Database Service on Cloud@Customer
  • Oracle Exadata Database Service on Exascale Infrastructure (詳細)

サポートされているすべてのデータベース・サービスでは、各リージョンのDRPGに複数のプライマリ・データベースとスタンバイ・データベースを追加できます。お客様は、特定のアプリケーション・スタックで必要に応じて、異なるデータベース・サービスを同じDR保護グループと計画に混在させ、一致させることができます。

たとえば、2つのBase Database、3つのAutonomous Dedicated Infrastructure上のデータベース、および3つのExascale上のExadataデータベースを含めることができます(特定のビジネス・システムに必要な場合)。各データベースのすべてのリカバリ・ステップは、作成されたフェイルオーバーまたはスイッチオーバー・ディザスタ・リカバリ計画に自動的に事前移入されます。

ディザスタ・リカバリ・ドリルのAutonomous Databaseスナップショット・スタンバイ

Autonomous Database Serverlessは、最初からFull Stack DRに組み込まれたリソース・タイプです。Autonomous Database Serverlessエンジニアリング・チームが、スナップショット・スタンバイ、フル・クローンおよびリフレッシュ可能なクローンを作成および管理するためのAPIの追加に取り組んでいます。

Full Stack DRでは、スタンバイ・リージョンのディザスタ・リカバリ・ドリルの一部として、これらのAutonomous Data Guardスタンバイ・オプションのいずれかを選択できるようになりました。Autonomous Database Transaction ProcessingデータベースまたはDRPGのメンバーであるデータ・ウェアハウス・データベースのオプションを選択できます。

スタンバイ・スナップショット機能は、Autonomous Dedicated InfrastructureおよびAutonomous Dedicated Cloud@Customerでも使用できますが、これらのOCIサービスは、現在、リフレッシュ可能クローンまたはフル・クローンをサポートしていません。

データベース管理者はコマンドラインを使用してExadataおよびBase Database as a Service (DBaaS)のスナップショット・スタンバイを作成できますが、スナップショット・スタンバイを作成および管理するOCI APIは、これらのサービスではまだ使用できません。そのため、Full Stack DRでは、ディザスタ・リカバリ・ドリルの実行時に、スタンバイ・リージョンのデータベースの読取り/書込みコピーを設定するために必要なステップを使用して、ディザスタ・リカバリ・ドリルを自動的に事前移入することはできません。DBaaSエンジニアリングは、将来、スナップショット・スタンバイ機能の拡張機能を提供することに重点を置いていますが、これらの重要なAPIが、障害時リカバリ・ドリルにテスト用にスタンバイ・リージョンにデータベースを自動的に設定するステップを事前移入するために使用できるタイミングをお知らせします。

Autonomous DatabaseコンソールからFull Stack DRへのリンク

Autonomous Database Serverlessのこの新機能は、昨年8月に本番環境にリリースされ、OCI DatabaseサービスとOCI Disaster Recovery as a Service (DRaaS)とFull Stack DRとの緊密な統合に向けた注目に値するステップです。この新機能の詳細は、Suraj Rameshの投稿「OCI Autonomous Databaseは、OCIコンソールのADB ServerlessページからFull Stack DRに関するより多くのインサイトを提供」を参照してください。

Screenshot 1: Autonomous Database console integration with Full Stack DR
スクリーンショット1: Autonomous Database ServerlessコンソールでのFull Stack DR統合

これらの新機能がFull Stack DRでどのように機能するか

すべてのOCIサービス、コンピュート、ストレージ、データベース、およびネットワーキングは、まず、通常のOCIサービスを使用して、Full Stack DRワークフローの外部で作成およびデプロイされます。たとえば、両方のリージョンにオブジェクト・ストレージ・バケットを作成し、オブジェクト・ストレージ・サービスを使用してリージョン間レプリケーションを有効にします。

同様に、サポートされているすべてのOracle Databasesは、必要なデータベースのOCIサービス・コンソールを使用して、Full Stack DRワークフローの外部にプロビジョニングされます。Autonomous Data GuardまたはData Guardも、選択したデータベースに対してOCIコンソールで有効化または構成されます。これは、Full Stack DRに何かを追加する前に、すべてのOCIサービスがデプロイされる方法です。

OCIリソース・タイプの増加するポートフォリオから選択

必要なコンピュート、ブロック・ストレージ、ファイル・ストレージ、オブジェクト・ストレージ、データベースおよびロード・バランサの任意の数と組合せをFull Stack DR保護グループに追加します。追加する内容は完全にユーザー次第で、ビジネス・システムまたはアプリケーション・スタックに含まれるOCIリソースに完全に依存します。

次のスクリーンショット2では、Full Stack DRの第一級オブジェクトとなったストレージとデータベースを紹介しています。第一級オブジェクトには、DR計画を事前に移入するために必要なインテリジェンスが組み込まれており、特定のリソースのリカバリを調整するために必要なすべてのステップを備えています。

Screenshot 2: built-in resource types
スクリーンショット2: 組込みリソース・タイプ

DR保護グループへの既存のリソースの追加

単一のビジネス・システムまたはアプリケーション・スタックには、常に2つのDR保護グループがあります。これらは、2つの異なるリージョンまたは可用性ドメインに作成され、ピアとして相互に関連付けられます。

通常、ビジネス・システムには、各リージョンで実行中または存在するOCIリソースがあります。たとえば、プライマリ・データベースでは、スタンバイ・リージョンまたは可用性ドメインにスタンバイ・データベースがあります。したがって、スクリーンショット3に示すように、任意の数のプライマリ・データベースが、プライマリ・ロールを持つDR保護グループにメンバーとして追加されます。次に、対応するすべてのスタンバイ・データベースが、スタンバイ・ロールでDR保護グループに追加されます。

Screenshot 3: DR Protection Group members
スクリーンショット3: DR保護グループ・メンバー

すべてのOCIリソースに対応するオブジェクトがスタンバイ・リージョンにあるわけではありません。詳細は、ドキュメントをお読みください。

スタンバイDR保護グループでのDR計画の作成

次のスクリーンショット4に示すように、スタンバイ・ロールを持つ3つの基本的なDR計画をDR保護グループに常に作成します。プライマリとスタンバイの役割は、リージョンではなくDR保護グループの機能です。役割は流動的であるため、生産として地域を考え、そのピアを「DR」と考える習慣を身につけることをお勧めします。Full Stack DRでは、保護グループのロールが自動的に変更されるため、DR計画でリカバリの実行が完了した後、リカバリを実行する準備が整います。

region1がプライマリで、region2がスタンバイの場合、次のスクリーンショットに示すように、3つのDR計画をregion2に作成します。これらのDR計画は、ワークロードをregion1からregion2に移行するために使用されます。

Screenshot 4: DR Plan types
スクリーンショット4: DR計画タイプ

Autonomous Dedicated Database、Autonomous Database Cloud@Customer、Object Storageなど、サポートされている各リソース・タイプには、DR計画の生成に必要な組込みのインテリジェンスがあり、次のスクリーンショット5に示すように、適切なリカバリ・ステップが正しい順序で事前に移入されています。

Screenshot 5: Basic DR Plan showing basic built-in Plan Groups
スクリーンショット5: 基本的な組込み計画グループを示すDR計画

当社の顧客の多くは、上記のスクリーンショット5に示すように、Full Stack DRが組み込みの計画グループの使用を自動化することに非常に満足していますが、目標は、特定のビジネスシステムの回復の100%を自動化することです。完全自動化の目的は、次のスクリーンショット6に示すように、必要なことを実行するために基本的なDR計画をカスタマイズするために、さらに作業が必要です。

Full Stack DRには、アプリケーション用のインテリジェント・モジュールが組み込まれていません。これは、現在、リカバリを管理するためのOCIネイティブAPIを提供するOracleまたはOracle Applications以外が存在しないためです。Data Guard、ブロック・ストレージ、ファイル・ストレージ、オブジェクト・ストレージ、およびオラクルがサポートするその他のOCIサービスには、自動リカバリの調整に必要なネイティブOCI APIが用意されています。

Full Stack DRは、スクリーンショット6に示すように、拡張可能なフレームワークを通じてユーザー定義の計画グループとステップを任意のDR計画に追加することで、ほぼすべてのOracleまたはOracle以外のアプリケーションのリカバリを引き続き調整できます。計画の変更の詳細は、OCIディザスタ・リカバリのドキュメントを参照してください。

Screenshot 6: DR Plan showing custom user-defined Plan Groups
スクリーンショット6: カスタム・ユーザー定義プラン・グループを示すDR計画

スイッチオーバーをテスト計画に事前設定し、ロールをスタンバイに変更

DR計画がregion2で完全に準備できたら、region1に同じ3つのDR計画を作成します。DR計画をそこで作成するには、Region1がスタンバイ・ロールを継承する必要があります。ワークロードがregion2に移動されるように、region2でスイッチオーバー計画を実行します。これにより、region1がスタンバイ・リージョンになります。region1に同じ3つの計画を作成して、Full Stack DRにワークロードをregion1に戻す方法があるようにします。

本番環境に影響を与えずにDR計画を頻繁にテスト

DRドリルと定期的な事前チェックは、DR計画の整合性と実行可能性を確保するための非常に重要なツールです。事前チェックは実行にコストがかかりません。また、リカバリの成功に影響を与える、環境内のわずかな不整合や変更も検出します。

DRドリルは、本番ワークロードへの影響を気にすることなく実行できます。このタイプのDR計画では、本番ワークロードへの影響ゼロで、スタンバイ・リージョンの本番コンピュート、ストレージ、データベースおよびロード・バランサのバックエンド・セットのコピーがハイドレートされます。

もっと知りたいですか?

OCI Full Stack Disaster Recoveryをまだ実際にご覧になっていない場合は、Oracle Cloud Infrastructureのアカウント・チームに今すぐデモンストレーションを設けてください。ドキュメント、価格、チュートリアル、顧客成功事例、ハンズオン・ラボなどの詳細は、Full Stack Disaster Recoveryをご覧ください。