ODSAの災害復旧のベストプラクティス：Exadata DatabaseとBase Databaseサービス (2023/01/16)

https://blogs.oracle.com/cloud-infrastructure/post/odsa-dr-best-practices-exadata-base

投稿者： Andrea Marchesini | Director of Product Management OCI Multicloud Platform

Oracle Database Service for Microsoft Azure（ODSA）は、Oracle Cloud Infrastructure（OCI）内のエンタープライズグレードのOracle Databaseサービスを、Azureのような使い慣れた操作で簡単にプロビジョニング、アクセス、および運用できるようにする、オラクルが管理するサービスです。この新しいODSAサービスは、OCI-Azure Interconnectを促進し、OCIで稼働するデータベースへのAzureアプリケーションの設定、管理、および接続を簡素化します。

エンタープライズグレードのソリューションを設計する際に考慮すべき最も重要な点の1つは、災害が発生した場合でも高い可用性とビジネスの継続性を確保することです。災害とは、事故や自然災害、分散型ネットワークの停止など、突発的かつ計画外の出来事で、広大な地域に大きな損害や損失をもたらすことです。よく設計された災害復旧ソリューションは、システム障害につながる災害が発生した場合、被害や混乱を軽減し、できるだけ早くスムーズに復旧させるために役立ちます。

この記事は、Oracle Autonomous Database、Exadata Databaseサービス、Base Databaseサービス、リージョンおよびクロスリージョンアーキテクチャなど、最も一般的なODSAシナリオのディザスタリカバリのベストプラクティスについて説明するシリーズの最初の記事です。このブログでは、異なるクラウドリージョン間でのディザスタリカバリのためのODSAのベストプラクティスに焦点を当て、フェイルオーバーが発生した場合にExadata DatabaseサービスまたはBase Databaseサービスに基づくアプリケーションスタックとデータベース層の両方がサービスを継続できるようにするためのガイドラインをいくつか紹介します。

ODSA使用時のディザスターリカバリーの検討事項

災害発生時に組織の要件を満たす展開戦略を特定するために、以下の例を含め、主な検討事項を確認してみましょう。

データベース層とアプリケーション層の両方について、RTO（復旧時間目標）とRPO（復旧時点目標）の期待値
プライマリおよび災害復旧リージョン間のレイテンシ、およびリージョンとアプリケーションの最終ユーザーまたは消費者間のレイテンシ
アプリケーションのデータに関するデータレジデンシー要件と規制を考慮し、最も適切なフェイルオーバークラウド領域を選択

これらの要件を満たすには、最も適切なクラウドリージョンのロケーションを特定し、選択することが重要です。

OCIとAzureは、世界中にいくつかの相互接続されたリージョンを持っており、出版時点で12、新しいロケーションが計画されています。現在のリージョン一覧は、ドキュメントで確認することをお勧めします。ODSA にはあらかじめ定義されたフェイルオーバーリージョンはありませんが、表 2 は、考慮事項および OCI interregion latency dashboard が提供するレイテンシーデータに基づいて、望ましいフェイルオーバーリージョンを示しています。

図1：OCIクラウドリージョン

Geographic region	Primary cloud regions	Preferred disaster recovery regions
Asia Pacific (APAC)	OCI Japan East (Tokyo)–Azure Tokyo	OCI Singapore (Singapore)–Azure Singapore
		OCI South Korea Central (Seoul)–Azure Seoul
	OCI Singapore (Singapore)–Azure Singapore	OCI Japan East (Tokyo)–Azure Tokyo
		OCI South Korea Central (Seoul)–Azure Seoul
	OCI South Korea Central (Seoul)–Azure Seoul	OCI Singapore (Singapore)–Azure Singapore
		OCI Japan East (Tokyo)–Azure Tokyo
Europe, Middle East, Africa (EMEA)	OCI Germany Central (Frankfurt)–Azure Frankfurt 1 & 2	OCI Netherlands Northwest (Amsterdam)–Azure Amersterdam2
		OCI UK South (London)–Azure London
	OCI Netherlands Northwest (Amsterdam)–Azure Amersterdam2	OCI Germany Central (Frankfurt)–Azure Frankfurt 1 & 2
		OCI UK South (London)–Azure London
	OCI UK South (London)–Azure London	OCI Germany Central (Frankfurt)–Azure Frankfurt 1 & 2
		OCI Netherlands Northwest (Amsterdam)–Azure Amersterdam2
	OCI South Africa Central (Johannesburg)–Azure Johannesburg	OCI Germany Central (Frankfurt)–Azure Frankfurt 1 & 2
		OCI UK South (London)–Azure London
Latin America (LATAM)	OCI Brazil Southeast (Vinhedo)–Azure Campinas	OCI US West (Phoenix)–Azure Phoenix
		OCI US West (San Jose)–Azure Silicon Valley
North America (NA)	OCI Canada Southeast (Toronto)–Azure Canada Central	OCI US East (Ashburn)–Azure Washington DC 1 & 2
		OCI US West (Phoenix)–Azure Phoenix
	OCI US East (Ashburn)–Azure Washington DC 1 & 2	OCI US West (Phoenix)–Azure Phoenix
		OCI US West (San Jose)–Azure Silicon Valley
	OCI US West (Phoenix)–Azure Phoenix	OCI US East (Ashburn)–Azure Washington DC 1 & 2
		OCI US West (San Jose)–Azure Silicon Valley
	OCI US West (San Jose)–Azure Silicon Valley	OCI US West (Phoenix)–Azure Phoenix
		OCI US East (Ashburn)–Azure Washington DC 1 & 2

表1：望ましいフェイルオーバーリージョン

ODSAを使用したクロスリージョンの災害復旧設計

プライマリおよびディザスタリカバリ地域を特定し、アプリケーション層とデータベース層の両方をプライマリまたは本番環境上にプロビジョニングした後、ソリューションのディザスタリカバリプランを定義することができます。クロスリージョンアプローチは、地域全体が利用できなくなるような災害事象や、低遅延の相互接続ネットワークリンクの障害が発生した場合、稀に回復力を提供します。

提案するソリューションについて、以下の仮定のもとで議論する。

プライマリー環境とディザスターリカバリー環境は、いずれもODSAが有効なリージョンでホスティングされている（表1参照）。
Azure上で動作するアプリケーション層とOCI上で動作するデータベース層の両方が、いつでも同じ地理的位置に配備されている。

これらの要件は、ODSA機能を適用した災害復旧アーキテクチャを一貫して設計し、災害発生時でも常にアプリケーションスタックとデータベース層の間のレイテンシーを最小にするための容易な道筋を提供することを意図しています。このアーキテクチャは、最も一般的なシナリオに対して効果的なソリューションを提供します。しかし、OCI や Azure Interconnection を採用することで、より明確なアーキテクチャを実現することができます。

図2は、OCIとAzureの間でリージョンをまたいだスプリットスタックソリューションのディザスターリカバリー能力を示しています。

図2：OCIとAzure間のリージョンをまたぐスプリットスタックソリューションのディザスターリカバリー機能

Azure上のアプリケーション層

1. 適切なTNS接続文字列を使用してアプリケーションを接続します。接続の確立方法によって、障害発生後にアプリケーションがフェイルオーバー先に効率的に再接続できるかが決まります。以下のTNS接続文字列は、すべてのOracleドライバー12.2以降に推奨されています。

ALIAS =(DESCRIPTION = 

     (CONNECT_TIMEOUT=90)  (RETRY_COUNT=20)(RETRY_DELAY=3) (TRANSPORT_CONNECT_TIMEOUT=3)  

       (ADDRESS_LIST = 

              (LOAD_BALANCE=on) 

              ( ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521))) 

           (ADDRESS_LIST = 

               (LOAD_BALANCE=on) 

              ( ADDRESS = (PROTOCOL = TCP)(HOST=secondary-scan)(PORT=1521)))       

          (CONNECT_DATA=(SERVICE_NAME = gold-cloud)))

具体的な数値は調整可能ですが、この例で引用した数値は妥当な出発点です。詳細は、「MAAソリューションの継続的サービスのためのアプリケーションチェックリスト」を参照してください。

2. Azure バックボーンネットワーク接続を使用して、プライマリ Azure リージョンから災害復旧リージョンにアプリケーション層をレプリケートします。プライマリおよびディザスタリカバリリージョンの同期を維持するためのツールや処理は、アプリケーションのコンポーネントや関係するAzureサービスおよびリソースによって異なる場合があります。例として、Azureストレージの移行と同期には、SMB Azureファイル共有をサポートするRoboCopyやAzCopy、Linuxベースのrsync、またはAzureBackupなど、いくつかのオプションを検討することができます。詳細と包括的な分析については、Azure上のディザスタリカバリとストレージアカウントのフェイルオーバーを参照してください。

3. Azure Traffic ManagerまたはOCI DNS Traffic Managementを設定して、エンドユーザーが自動化の助けを借りて、別のAzureリージョンに構成されたセカンダリ/またはスタンバイアプリケーションにシームレスに接続できるようにする。Azureでアプリケーションのフェイルオーバーを検出し、OCIでデータベースのスイッチオーバーを開始するためのスクリプト形式の自動プロセスを設定します。

OCI上のデータベース層

ODSAコンソールを介して、災害復旧リージョンにセカンダリデータベースをプロビジョニングします。
Oracle Cloud Consoleにログインし、プライマリーリージョンとディザスターリカバリーリージョン間のプライベートリモート仮想クラウドネットワーク（VCN）ピアリング接続をセットアップします。OCIリージョン間のトラフィックは、OCIバックボーンネットワーク接続を経由します。
Oracle Data Guard で使用する物理スタンバイデータベースを手動でセットアップし、リモート VCN ピアリングを介して OCI リージョン間でプライマリデータベースとスタンバイデータベースを同期させます。
Oracle Data Guard 構成の場合、FSFO（Fast-Start Failover）を有効にして、プライマリデータベースが失われた場合に、OCI の災害復旧リージョンにあるスタンバイデータベースへブローカーが自動的にフェイルオーバーできるようにします。
FSFOは、自動フェイルオーバーが発生する前と後にカスタムアクションを実行することができます。そのため、フェイルオーバー成功後に実行されるコールアウト後のスクリプトで、Azure上で動作するアプリケーション層の切り替えを開始するプロセスを設定することができます。

まとめ

災害への備えは簡単なことではありません。さまざまなビジネス要件と利用可能なアーキテクチャを考慮し、それらの側面を実行可能な災害復旧計画に取り込む包括的なアプローチが必要です。今回紹介したシナリオは、シンプルかつ効果的なフェイルオーバーとOracle Cloud InfrastructureおよびAzure環境でのディザスタリカバリ構成を使用して、アプリケーションデプロイに最適なディザスタリカバリ手法を選択するためのガイドラインを提供します。

詳しくは、以下の資料をご覧ください。