ODSAディザスタ・リカバリのベスト・プラクティス: Exadata DatabaseおよびBase Databaseサービス

※ 本記事は、Andrea Marchesiniによる”ODSA disaster recovery best practices: Exadata Database and Base Database services“を翻訳したものです。

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

エンタープライズ・グレードのソリューションを設計する際に考慮すべき最も重要な側面の1つは、障害発生時でも高可用性とビジネス継続性を確保することです。災害とは、事故、自然災害、分散型ネットワークの停止など、突然の計画外の出来事であり、広範囲の地理的領域で重大な損傷または損失を引き起こします。適切に設計されたディザスタ・リカバリ・ソリューションは、システム障害につながる障害発生時に、障害や混乱を減らし、できるだけ迅速に回復するのに役立ちます。

この記事は、Oracle Autonomous Database、Exadata Databaseサービス、Base Databaseサービス、地域およびクロスリージョン・アーキテクチャなど、最も一般的なODSAシナリオのディザスタ・リカバリのベスト・プラクティスについて説明するシリーズの最初のものです。このブログでは、Exadata Databaseサービスまたはベース・データベース・サービスに基づくアプリケーション・スタックとデータベース層の両方が、フェイルオーバーがトリガーされた場合に引き続きサービスを提供するよう、いくつかのガイドラインに従って、様々なクラウド・リージョンにわたる障害時リカバリに関するODSAのベスト・プラクティスに重点を置いています。

ODSAを使用する場合の障害時リカバリに関する考慮事項

次の例を含め、障害発生時の組織の要件を満たすデプロイメント戦略を特定するための主な考慮事項を確認します。:

• データベース層とアプリケーション層の両方に対する目標復旧時間（RTO）と目標復旧時点（RPO）の期待

• プライマリ・リージョンとディザスタ・リカバリ・リージョン間のレイテンシ、およびリージョンとアプリケーションの最終ユーザーまたはコンシューマ間のレイテンシ

• アプリケーション・データのデータ・レジデンシ要件と規制を考慮して、最も適切なフェイルオーバー・クラウド・リージョンを選択します。

最も適切なクラウド・リージョンの場所を特定して選択することは、これらの要件を満たす上で重要です。

世界中にOCIとAzureの相互接続された複数のリージョンがあります。公開時には12のロケーションがあり、新しいロケーションが計画されています。現在のリージョン・リストのドキュメントを確認することをお薦めします。ODSAには事前定義されたフェイルオーバー・リージョンはありませんが、表は、OCIリージョン間レイテンシ・ダッシュボードによって提供される考慮事項およびレイテンシ・データに基づく優先フェイルオーバー・リージョンを示しています。

表1: 優先フェイルオーバー・リージョン

ODSAを使用したクロスリージョン障害時リカバリ設計

プライマリ・リージョンとディザスタ・リカバリ・リージョンが識別され、アプリケーション・レイヤーとデータベース層の両方がプライマリ環境または本番環境にプロビジョニングされた後、ソリューションのディザスタ・リカバリ計画を定義できます。クロスリージョン・アプローチは、リージョン全体を使用できないようにする障害イベント、または低レイテンシの相互接続ネットワーク・リンクの失敗のまれなケースに回復性を提供します。

提案した解決策について、次の仮定で説明します。:

• プライマリ環境とディザスタ・リカバリ環境の両方が、ODSA対応のリージョンでホストされます（表1を参照）。

• Azureで実行されているアプリケーション・レイヤーとOCIで実行されているデータベース・レイヤーの両方が、いつでも同じ地理的な場所にデプロイされます。

これらの要件は、障害時でも、ODSA機能を適用して障害時リカバリ・アーキテクチャを一貫して設計し、アプリケーション・スタックとデータベース層の間の待機時間を常に最小限に抑えるための簡単なパスを提供することを目的としています。このアーキテクチャは、最も一般的なシナリオに対して効果的なソリューションを提供します。ただし、OCIおよびAzure Interconnectionを採用することで、より精通したアーキテクチャを実現できます。

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

Azure上のアプリケーション・レイヤー

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

   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ファイル共有、linuxベースのrsyncまたはAzureBackupをサポートするRoboCopyまたはAzCopyなど、いくつかの考慮事項があります。詳細および包括的な分析については、Azureの障害時リカバリおよびストレージ・アカウントのフェイルオーバーを参照してください。

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

OCI上のデータベース・レイヤー

1. ODSAコンソールを使用して、ディザスタ・リカバリ・リージョンにセカンダリ・データベースをプロビジョニングします。

2. Oracle Cloudコンソールにログインし、プライマリ・リージョンとディザスタ・リカバリ・リージョンの間にプライベート・リモート仮想クラウド・ネットワーク(VCN)ピアリング接続を設定します。OCIリージョン間のトラフィックは、OCIバックボーン・ネットワーク接続を経由します。

3. Oracle Data Guardで使用するフィジカル・スタンバイ・データベースを手動で設定し、リモートVCNピアリングを介してOCIリージョン間でプライマリ・データベースとスタンバイ・データベースを同期します。

4. Oracle Data Guard構成の場合は、ファスト・スタート・フェイルオーバー（FSFO）を有効にして、プライマリ・データベースが失われた場合に、ブローカがOCIディザスタ・リカバリ・リージョンのスタンバイ・データベースに自動的にフェイルオーバーできるようにします。

5. FSFOは、自動フェイルオーバーが発生する前後にカスタム・アクションを実行できます。そのため、フェイルオーバーの成功後に実行されるコールアウト後のスクリプトで、Azureで実行されているアプリケーション・レイヤーのスイッチオーバーを開始するようにプロセスを構成できます。

まとめ

災害の準備は簡単な作業ではありません。さまざまなビジネス要件と利用可能なアーキテクチャを考慮し、それらの側面を実用的な障害時リカバリ計画に包含する包括的なアプローチが必要です。ここで説明したシナリオは、シンプルで効果的なフェイルオーバーと、Oracle Cloud InfrastructureおよびAzure環境のディザスタ・リカバリ構成を使用して、アプリケーション・デプロイメントに最適なディザスタ・リカバリ・アプローチの選択に役立つガイドラインを提供します。

詳細は、次のリソースを参照してください。:

• Oracle Database Service for Microsoft Azureの開始

• 業界アナリストのコメントを読む

• Oracle Database Service for Microsoft Azureの発表

• Oracle Database Service for Microsoft Azureの技術概要

• Oracle Database Service for Azure

• Oracle Maximum Availability Architecture

• Oracle Data Guard

• Oracle Data Guard: 同期REDO転送のベスト・プラクティス

• Oracle GoldenGate

• Oracle GoldenGate Cloud service

• Oracle Global Data services (GDS)

• Ten design principles for Azure applications