OCI Full Stack Disaster Recovery、データベースとストレージの組み込み機能を拡張 (2024/09/24)

OCI Full Stack Disaster Recovery、データベースとストレージの組み込み機能を拡張 (2024/09/24)

https://blogs.oracle.com/cloud-infrastructure/post/oci-full-stack-dr-capabilities-database-storage

投稿者: Gregory King | Senior principal product manager for OCI Full Stack Disaster Recovery


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


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



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


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


  • ブロックストレージ
  • ファイル・ストレージ
  • オブジェクト・ストレージ



サポートされているOCI Databaseサービス


Full Stack DRでは、他の4つのOCI Oracle Databaseサービスに対する組込みサポートも導入されました。お客様は、次のリストにあるOracle Databaseの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 Database、および3つのExadata DatabaseをExascaleに含めることができます(特定のビジネス・システムに必要な場合)。各データベースのすべてのリカバリ・ステップは、作成されたフェイルオーバーまたはスイッチオーバー・ディザスタ・リカバリ計画に自動的に事前移入されます。



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


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


Full Stack DRでは、スタンバイ・リージョンのディザスタ・リカバリ・ドリルの一部として、これらのAutonomous Data Guardスタンバイ・オプションのいずれかを選択できるようになりました。Autonomous Database Transaction Processing Databaseまたは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サーバーレス・ページからFull Stack DRに関するより多くのインサイトを提供します。


スクリーンショット1: Autonomous Databaseサーバーレス・コンソールでの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計画を事前移入するために必要なインテリジェンスが組み込まれており、特定のリソースのリカバリを調整するために必要なすべてのステップを備えています。


スクリーンショット2: 組込みリソース・タイプ



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


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


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


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


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



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


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


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


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


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


スクリーンショット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ディザスタ・リカバリのドキュメントを参照してください。


スクリーンショット6: カスタム・ユーザー定義プラン・グループを示すDR計画


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


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



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


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


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



もっと知りたいですか?


Full Stack Disaster Recoveryをまだ実際にご利用になっていない場合は、Oracleアカウント・チームに今すぐFull Stack DR製品管理のデモンストレーションを設定してください。

Customer success stories

Documentation

Hands-on labs

OHC tutorials explaining how to automate recovery for applications

YouTube Playlists

コメント

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

Oracle APEXのInteractive Gridで、Oracle Formsと比較して、重複行の検証を制御/通過させる方法 (2022/07/21)

Oracle APEX 24.1の一般提供の発表 (2024/06/17)