段階的な戦略を使用したOracle Database@Azureへのビジネス・クリティカル・アプリケーションの移行

オンプレミスのデータベースとアプリケーションをクラウドに移行し、段階的またはハイブリッドな戦略でダウンタイムを最小限に抑え、クラウドベースのアプリケーションからオンプレミス・データベースへのシームレスな接続を実現します。適切に構造化された計画により、データ・センターの出口が加速し、リスクが軽減され、信頼性が維持されます。ハイブリッドの2フェーズ・アプローチにより、安定性を維持しながらスムーズな移行が可能になります。

オンプレミスのデータベースとアプリケーションをクラウドに移行する場合、シームレスな移行を実現するために、いくつかの課題に対処する必要があります。段階的な移行やハイブリッド・クラウド・ソリューションなどのダウンタイムを最小限に抑え、特に重要なビジネス・ワークロードに対してアプリケーションの稼働時間を維持する移行戦略を選択します。オンプレミス・データベースに接続するクラウドにすでに存在するアプリケーションも、接続の問題を回避するために移行計画で考慮されるようにします。アプリケーションがクラウドにあるがデータベースがオンプレミスであるSaaSアプリケーションの場合、両方のコンポーネントを含む包括的な戦略を保証します。これらの課題に積極的に取り組んで、移行を円滑に行い、重要なビジネス・アプリケーションの信頼性を維持します。また、適切に構造化された戦略により、データ・センターの出口を迅速化し、移行リスクを軽減し、重要なビジネス・アプリケーションの信頼性を確保できます。

Oracle Database@Azureは、Microsoft Azure内のアプリケーション・ワークロードにデータベースを近づけることで、オンプレミスのExadataまたはOracle Real Application Clusters (Oracle RAC)への依存を排除します。この統合により、データベースとアプリケーションの両方を同じデータ・センターでホストできるため、レイテンシが軽減され、物理インフラストラクチャへの依存が最小限に抑えられます。

多くの場合、この設定を実装するには、重要な業務を中断することなく、ターゲット・アーキテクチャを確立するための慎重に設計されたソリューションが必要です。ディザスタ・リカバリ環境またはスタンバイ環境を通じてビジネス継続性を確保するために、多くのミッションクリティカルなワークロードが複数のリージョンにデプロイされます。このアプローチは、ハイブリッドの2フェーズ移行戦略をサポートし、運用安定性を維持しながらシームレスな移行を可能にします。

開始する前に

始める前に、次のことを考慮してください。

  • Oracle Data Guardでファスト・スタート・フェイルオーバーを無効にして、移行中にプライマリ・リージョンとスタンバイ・リージョン間のスムーズで制御された遷移を確保します。
  • OCI Database Migrationは、ZDMやOCI Migrationなどのオンラインおよびオフラインのユース・ケースに対して、検証済みのクロスバージョン、フォルト・トレラント、および増分Oracle DatabaseとMySQL移行を提供します。
  • このリファレンス・アーキテクチャは、リージョン間デプロイメントを使用したアクティブ/スタンバイ構成のOracle Gold Maximum Availability Architecture (MAA)モデルに従い、自己回復性を高めます。このリファレンス・アーキテクチャは、MAA Platinumを使用するように拡張できます。MAA Platinumでは、Oracle Data Guardを使用して可用性ゾーン間で同期レプリケーションを介してローカル高可用性が実現され、リージョン間のディザスタ・リカバリは非同期レプリケーションで実装されます。

アーキテクチャ

このアーキテクチャでは、最小限のダウンタイムでオンプレミスのOracle DatabaseをOracle Database@AzureのOracle Exadata Database Serviceに移行するための段階的なアプローチの概要を示します。

この戦略を簡略化するために、現在の状態、将来の状態および移行フェーズの3つの重要な側面に分類します。

このリファレンス・アーキテクチャには、4つの主要コンポーネントがあります(図の青い数字でマークされています)。
数字 コンポーネント 説明
1 オンプレミスのプライマリ・データ・センター 移行前に、データベースおよびアプリケーションをプライマリ・システムとしてホストします。
2 オンプレミス・スタンバイ・データ・センター スタンバイ・システムをメンテナンスし、オンプレミスのプライマリ・データベースをレプリケートします。
3 Azureプライマリ・リージョン Oracle Database@Azureでアプリケーションおよびデータベースを実行し、移行後のプライマリ・システムになります。
4 Azureスタンバイ・リージョン Oracle Data Guardを使用してプライマリ・リージョンをレプリケートする障害時リカバリ・サイト。

logical-architecture-diagram.pngの説明が続きます
図logical-architecture-diagram.pngの説明

論理アーキテクチャ図oracle.zip

現在の状態

既存の設定では、プライマリ・データ・センター(1)とスタンバイ・データ・センター(2)の両方がオンプレミスでホストされ、アプリケーション・ワークロードおよびデータベースがサポートされます。プライマリ・データ・センターはすべてのリクエストを処理し、スタンバイ・データ・センターはOracle Data Guardを使用して非同期レプリケーションを維持します。これにより、予期しない障害が発生した場合にスタンバイ・システムがフェイルオーバーの準備ができ、高可用性が保証されます。

将来の状態

将来のアーキテクチャは現在の設定を反映しますが、2つのAzureリージョン(プライマリ・リージョン(3)とスタンバイ・リージョン(4)にまたがってクラウドで完全にホストされます。データベースはOracle Database@Azure Exadataサービスに移行され、Oracle Cloud Infrastructure (OCI)ネットワークを介してOracle Data Guardを介して管理されるプライマリ・データベースとスタンバイ・データベース間で非同期レプリケーションが行われます。

オンプレミス・データ・センターとAzureの間のセキュアな接続のために、Azureファイアウォールは、Azureのセキュアな仮想WAN (vWAN)ハブ内にデプロイされます。

移行フェーズ

移行は、制御された信頼性の高い移行を確保するための2フェーズ・アプローチに従います。

フェーズ1– オンプレミス・スタンバイからAzureへの移行およびスイッチオーバー

このフェーズでは、オンプレミス・スタンバイ・システム(2)がAzure (3)に移行されます。完了すると、プライマリ(1)およびスタンバイ(3)のロールがスワップされ、Azureが新しいプライマリ・リージョンになります。

  1. Azure ExpressRouteを使用して、オンプレミスとAzure間の接続を確立します。
  2. セキュリティのためにAzureセキュア・ハブ、AzureファイアウォールおよびvWANを構成します(まだ配置されていない場合)。
  3. Azureのプライマリ・リージョンにOracle Exadata Cloud Infrastructureをプロビジョニングしてから、次のようにします:
    1. Oracle Exadata仮想マシン(VM)クラスタを設定し、ターゲット・データベースを作成します。
    2. プライマリ・データベースでアーカイブ・ログおよび強制ロギングを有効にします(まだ有効になっていない場合)。
  4. リスナー用にOracle Netを構成し、検出用にTNS名を構成します。
  5. サービスからリストアして、Azureのプライマリ・リージョン(3)にスタンバイ・データベースを設定します。
  6. スイッチオーバーを実行し、Azureデータベース(3)を新しいプライマリにします。
  7. アプリケーションをAzureプライマリ・リージョン(3)に移行し、DNSルートを更新します。
  8. Data Guard構成を確認し、レプリケーション・ステータスをモニターします。

フェーズ2– Azureでのスタンバイの確立およびオンプレミスの廃止

このフェーズでは、スタンバイ・システム(4)がAzureに設定され、オンプレミス・リソース(1および2)が廃止されます。

  1. Oracle Database@Azureを使用して、スタンバイ・リージョン(4)にOracle Exadata Cloud Infrastructureをプロビジョニングします。
  2. Oracle Exadata VMクラスタを設定し、スタンバイ・データベースを作成します。
  3. Oracle Data Guardを有効にして、プライマリ・リージョン・データベース(3)をスタンバイ・データベース(4)に関連付けます。
  4. プライマリ・データベースとスタンバイ・データベース間のハブアンドスポーク・トポロジ内のローカル・ピアリングとリモート・ピアリングを活用して、高スループットのレプリケーションにOCIネットワーキングを使用します。
  5. アプリケーション・ワークロードをAzureスタンバイ・リージョン(4)に移行します。
  6. オンプレミス・リソースとの同期を停止してから、プライマリ(1)およびスタンバイ(2)データ・センターからオンプレミス・アプリケーションおよびデータベース・リソースを廃止します。

次の図は、このリファレンス・アーキテクチャを示しています。


physical-architecture-diagram.pngの説明が続きます
図physical-architecture-diagram.pngの説明

物理アーキテクチャ図 oracle.zip

Microsoft Azureには、次のコンポーネントが用意されています。

  • Azureリージョン

    Azureリージョンは、可用性ゾーンと呼ばれる1つ以上の物理Azureデータ・センターが存在する地理的領域です。リージョンは他のリージョンから独立しており、長距離の場合は(国または大陸にまたがって)分離できます。

    AzureおよびOCIリージョンは、ローカライズされた地理的領域です。Oracle Database@Azureの場合、AzureリージョンがOCIリージョンに接続され、Azureの可用性ゾーン(AZ)がOCIの可用性ドメイン(AD)に接続されます。距離とレイテンシを最小限に抑えるために、AzureとOCIリージョンのペアが選択されます。

  • Azure可用性ゾーン

    Azureアベイラビリティ ゾーンは、Azureリージョン内で物理的に分離された場所であり、独立した電力、冷却、およびネットワークを提供することで、高可用性と回復力を確保するように設計されています。

  • Azure VNet

    Microsoft Azure Virtual Network(VNet)は、Azureのプライベート・ネットワークの基本的な構成要素です。VNetを使用すると、Azure仮想マシン(VM)などの多くのタイプのAzureリソースが、相互に、インターネットおよびオンプレミス・ネットワークと安全に通信できます。

  • Azure委任サブネット

    サブネット委任とは、Microsoftがマネージド・サービス(特にPlatform-as-a-Service (PaaS)サービス)を仮想ネットワークに直接注入できることです。これにより、外部サービスが外部PaaSサービスであっても、外部サービスが仮想ネットワーク・リソースとして機能するように、サブネットを仮想ネットワーク内の外部管理対象サービスのホームとして指定または委任できます。

  • Azure VNIC

    Azureデータ・センターのサービスには、物理ネットワーク・インタフェース・カード(NIC)があります。仮想マシン・インスタンスは、物理NICに関連付けられた仮想NIC (VNIC)を使用して通信します。各インスタンスには、起動時に自動的に作成およびアタッチされるプライマリVNICがあり、インスタンスの存続期間中に使用できます。

  • Azure仮想ネットワーク・ゲートウェイ

    Azure Virtual Network Gatewayは、Azure仮想ネットワークとオンプレミス ネットワーク間のセキュアなクロス オンプレミス接続を確立します。これにより、データ・センターとAzureにまたがるハイブリッド・ネットワークを作成できます。

  • Azure仮想WAN

    Microsoft Azure Virtual WAN(VWAN)は、多くのネットワーク、セキュリティ、ルーティング機能をまとめて単一の運用インタフェースを提供するネットワークサービスです。

  • Azureセキュア・ハブ

    Azureセキュア ハブ(Secure Virtual Hub)は、Azure Firewall Managerによって管理されるセキュリティおよびルーティング ポリシーで強化された Azure Virtual WANハブです。トラフィック・ガバナンスと保護のためのネイティブ・セキュリティ・サービスを統合することで、ハブアンドスポークおよび推移的なネットワーク・アーキテクチャの作成を簡素化します。この設定により、トラフィックのルーティングが自動化され、ユーザー定義ルート(UDR)が不要になります。組織はセキュアなハブを使用して、仮想ネットワーク、支店、インターネット間のトラフィックをフィルタリングおよび保護し、堅牢なセキュリティを確保し、ネットワーク管理を合理化できます。

  • Azureファイアウォール・マネージャ

    Azure Firewall Managerは、複数のリージョンおよびサブスクリプションにまたがる Azure Firewallの導入と構成を簡素化する一元化されたセキュリティ管理サービスです。これにより、階層的なポリシー管理が可能になり、グローバル・ファイアウォール・ポリシーとローカル・ファイアウォール・ポリシーを一貫して適用できるようになります。Azure Virtual WAN (vWAN)と安全なハブと統合されている場合、Azure Firewall Managerは、ユーザー定義ルート(UDR)を必要とせずにトラフィック ルーティングとフィルタリングを自動化することで、セキュリティを強化します。この統合により、仮想ネットワーク、支店、インターネット間のトラフィックが安全に管理および監視され、堅牢で合理化されたネットワーク・セキュリティ・ソリューションが提供されます。

  • Azure ExpressRoute

    Azure ExpressRouteは、オンプレミスのデータ・センターとMicrosoft Azureの間のプライベート接続を可能にするサービスで、パブリック・インターネットをバイパスします。これにより、一貫したレイテンシにより、セキュリティ、信頼性、および高速化を実現できます。ExpressRoute接続は、ポイント・ツー・ポイント・イーサネット、任意のツー・アニー(IP VPN)または仮想クロスコネクトなどの様々な方法を使用して、接続プロバイダを介して確立できます。オンプレミスのデータ・センターと統合する場合、ExpressRouteを使用すると、ネットワークをクラウドにシームレスに拡張できるため、ハイブリッド・クラウドのシナリオ、ディザスタ・リカバリおよびデータ移行が容易になり、パフォーマンスとセキュリティが向上します。

Oracle Cloud Infrastructureでは、次のコンポーネントが提供されます:

  • リージョン

    Oracle Cloud Infrastructureリージョンは、可用性ドメインをホストする1つ以上のデータ・センターを含むローカライズされた地理的領域です。リージョンは他のリージョンから独立しており、長距離の場合は(国または大陸にまたがって)分離できます。

  • 可用性ドメイン

    可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、ある可用性ドメインでの障害は、リージョン内の他の可用性ドメインに影響を与えないでください。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義ネットワークです。従来のデータ・センター・ネットワークと同様に、VCNsではネットワーク環境を制御できます。VCNには重複しない複数のCIDRブロックを含めることができ、VCNの作成後にそれらを変更できます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。

  • ルート表

    仮想ルート表には、通常ゲートウェイを介して、サブネットからVCN外部の宛先にトラフィックをルーティングするルールが含まれます。

  • セキュリティ・リスト

    サブネットごとに、サブネット内外で許可されるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。

  • ネットワーク・セキュリティ・グループ(NSG)

    NSGは、クラウド・リソースの仮想ファイアウォールとして機能します。Oracle Cloud Infrastructureのゼロトラスト・セキュリティ・モデルでは、VCN内のネットワーク・トラフィックを制御します。NSGは、単一のVCN内の指定されたVNICのセットにのみ適用されるイングレスおよびエグレス・セキュリティ・ルールのセットで構成されます。

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Serviceは、Oracleデータベースを保護するOracle Cloudサービスです。OCIデータベースのバックアップ自動化と強化されたデータ保護機能により、すべてのバックアップ処理およびストレージ要件をOracle Database Autonomous Recovery Serviceにオフロードできるため、バックアップ・インフラストラクチャのコストと手動管理オーバーヘッドが削減されます。

  • Exadata Database Service

    これにより、クラウド内でExadataの機能を活用できます。Oracle Exadata Database Serviceは、パブリック・クラウドで専用に最適化されたOracle Exadataインフラストラクチャ上に、実績のあるOracle Database機能を提供します。Oracle Databaseのすべてのワークロードに組み込まれたクラウド自動化、柔軟なリソーススケーリング、セキュリティ、高速パフォーマンスにより、管理を簡素化し、コストを削減できます。

  • Oracle Database@Azure

    Oracle Database@Azureは、Microsoft Azureデータ・センターにデプロイされたOracle Cloud Infrastructure (OCI)で実行されているOracle Databaseサービス(Oracle Exadata Database Service on Dedicated InfrastructureおよびOracle Autonomous Database Serverless)です。このサービスは、OCIで機能と価格を同等に提供します。Azure Marketplaceでサービスを購入します。

    Oracle Database@Azureは、Oracle Exadata Database Service、Oracle Real Application Clusters (Oracle RAC)およびOracle Data GuardテクノロジをAzureプラットフォームに統合します。ユーザーは、AzureコンソールおよびAzure自動化ツールでサービスを管理します。サービスはAzure Virtual Network(VNet)にデプロイされ、Azure Identity and Access Managementシステムと統合されます。OCIおよびOracle Databaseの汎用メトリックおよび監査ログは、Azureでネイティブに利用できます。このサービスでは、ユーザーにAzureサブスクリプションとOCIテナンシが必要です。

    Autonomous Databaseは、Oracle Exadataインフラストラクチャ上に構築されており、自己管理、自己保護、自己修復が可能なため、手動のデータベース管理や人的エラーを排除できます。Autonomous Databaseでは、大規模言語モデル(LLM)と導入場所の選択肢を使用して、組み込みのAI機能を使用して、あらゆるデータでスケーラブルなAI搭載アプリを開発できます。

    Oracle Exadata Database ServiceとOracle Autonomous Database Serverlessはどちらも、ネイティブのAzure Portalを介して簡単にプロビジョニングされるため、より広範なAzureエコシステムにアクセスできます。

  • Data Guard

    Oracle Data GuardおよびOracle Active Data Guardは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する包括的なサービスのセットを提供し、本番のOracleデータベースを中断することなく使用できるようにします。Oracle Data Guardは、インメモリー・レプリケーションを使用して、これらのスタンバイ・データベースを本番データベースのコピーとしてメンテナンスします。計画停止または計画外停止により本番データベースが使用できなくなった場合、Oracle Data Guardはいずれかのスタンバイ・データベースを本番ロールに切り替えることで、停止に伴うダウンタイムを最小化できます。Oracle Active Data Guardは、ほとんどの読取りワークロードをスタンバイ・データベースにオフロードする追加機能を提供し、高度なデータ保護機能も提供します。

  • ローカル・ピアリング

    ローカル・ピアリングを使用すると、VCNを同じリージョン内の別のVCNとピアリングできます。ピアリングとは、インターネットを横断するトラフィックやオンプレミス・ネットワークを介したルーティングなしで、VCNsがプライベートIPアドレスを使用して通信することを意味します。

  • リモート・ピアリング

    リモート・ピアリングでは、異なるVCNs内のリソースがプライベートIPアドレスを使用して通信できます。リモート・ピアリングにより、異なるリージョン内の別のVCNと通信する必要があるインスタンスに対してインターネット・ゲートウェイまたはパブリックIPアドレスが不要になります。

  • ハブ仮想クラウド・ネットワーク

    A hub virtual cloud network (VCN) acts as a central point for managing and routing traffic between multiple VCNs, both within the same region and across different regions.ローカル・ピアリング・ゲートウェイ(LPG)を使用すると、ハブVCNは、同じリージョン内の複数のスポークVCNsに接続され、効率的な通信と集中管理が容易になります。リージョン間の接続には、リモート・ピアリング・グループ(RPG)が使用されます。このグループでは、各VCNがDynamic Routing Gateway (DRG)にアタッチされ、リモート・ピアリング接続(RPC)が確立されます。この設定は、Oracle Data Guardトラフィックのルーティングに特に役立ちます。これにより、REDOログおよびその他の同期データが、あるリージョンのプライマリ・データベースから別のリージョンのスタンバイ・データベースに効率的に転送されるため、データの一貫性と高可用性が維持されます。

オンプレミス・システムには次のコンポーネントがあります。

  • プライマリ・データ・センター

    アプリケーションとOracleデータベースをホスティングするオンプレミス・データ・センターは、事業運営の主要サイトとして機能し、高いパフォーマンスとデータの可用性を確保します。ディザスタ・リカバリとビジネス継続性を強化するために、このプライマリ・データ・センターは、多くの場合、異なる地理的リージョンに配置されるスタンバイ・データ・センターに関連付けられています。スタンバイ・データ・センターは、Oracle Data Guardを使用してOracleデータベースの同期コピーを保持します。これにより、プライマリ・データベースからスタンバイ・データベースに変更が継続的にレプリケートされます。プライマリ・サイトで障害または障害が発生した場合、スタンバイ・データ・センターは迅速に引き継ぎ、ダウンタイムとデータ損失を最小限に抑えることで、中断のない業務を確実に行うことができます。

  • スタンバイ・データ・センター

    スタンバイ・データ・センターは、予期しない状況でのビジネス継続性を確保するために設計されたディザスタ・リカバリ戦略の重要なコンポーネントです。プライマリ・アプリケーションとOracle Databaseのレプリカをホストし、Oracle Data Guardなどのテクノロジを介して同期を維持します。プライマリ・データ・センターで障害または障害が発生した場合、スタンバイ・データ・センターはシームレスに操作を引き継ぎ、ダウンタイムとデータ損失を最小限に抑えることができます。この設定により、ビジネス・プロセスが引き続き円滑に実行され、中断に対する回復力がもたらされ、ユーザーと顧客のサービスの可用性が維持されます。

  • データベース

    オンプレミスのデータ・センターでホストされるOracleデータベースは、ビジネス・データの格納と管理において重要な役割を果たします。重要な事業運営を処理し、データの整合性と可用性を確保するためのセキュアで高パフォーマンスな環境を提供します。この設定により、組織はデータ・インフラストラクチャを完全に制御し、特定のニーズを満たすように構成をカスタマイズし、規制要件に準拠できます。Oracleの堅牢なデータベース機能を活用することで、企業はトランザクションを効率的に処理し、レポートを生成し、意思決定プロセスをサポートできます。

  • アプリケーション

    Oracleデータベースの上にオンプレミス・データ・センターで実行されるアプリケーションは、事業運営に不可欠です。これらのアプリケーションは、堅牢で信頼性の高いOracleデータベースを活用して、トランザクションの処理、顧客データの管理、重要なビジネス・インサイトの生成を行います。安全かつ管理された環境で運用することで、高いパフォーマンス、データの整合性、および規制基準へのコンプライアンスを確保できます。この設定により、企業は特定のニーズに合わせてインフラストラクチャをカスタマイズでき、日々の業務と戦略的な意思決定のための安定した基盤が提供されます。

レコメンデーション

次の推奨事項を開始点として使用します。 実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。

パフォーマンス

ディザスタ・リカバリ(DR)レプリケーションには、OCIネットワークを強くお薦めします。OCIの高パフォーマンス・ネットワーク・インフラストラクチャにより、低レイテンシで高帯域幅の接続が保証されます。これは、プライマリ・データベースとスタンバイ・データベース間の効率的なデータ・レプリケーションおよび同期に不可欠です。Oracle Data GuardとOracle Database@AzureのOCIネットワーキングを活用することで、パフォーマンス、セキュリティ、信頼性を大幅に向上させることができます。

この設定により、REDOログおよびクリティカル・データの高速かつセキュアな送信が可能になり、フェイルオーバー・シナリオでのデータ損失とダウンタイムが最小限に抑えられるため、DRが強化されます。さらに、ネットワーク暗号化や高度なアクセス制御など、OCIに組み込まれたセキュリティ機能により、機密データの堅牢な保護が提供されます。

OCIネットワーキングをOracle Database@Azureと統合することで、企業は、ビジネスの継続性と運用効率を高める、シームレスで自己回復性のある可用性の高いデータベース・アーキテクチャを実現できます。

考慮事項

このリファレンス・アーキテクチャをデプロイする場合は、次の点を考慮してください。

  • ビジネス継続性

    Oracle Database Autonomous Recovery ServiceをOracle Data Guardと統合すると、プライマリおよびスタンバイ・データベースの設定に対する包括的で回復力のあるデータ保護戦略が作成されます。Oracle Data Guardは、プライマリ・データベースの障害発生時に引き継ぐことができる同期スタンバイ・データベースを維持することで、高可用性とディザスタ・リカバリを保証し、停止時間およびデータ損失を最小限に抑えます。

    これを補完するOracle Database Autonomous Recovery Serviceは、データ損失ゼロの保護とリアルタイム・リカバリ機能を備えたフルマネージドの一元化されたバックアップ・ソリューションを提供します。この組み合わせにより、リアルタイム・レプリケーションと堅牢なバックアップ・メカニズムの両方を通じて継続的なデータ保護が保証され、データの整合性とビジネス継続性が向上します。

  • 可用性

    Active Data Guardとともに、リージョン内の異なる可用性ゾーン(AZ)にまたがる複数のOracle Databaseインスタンスをデプロイすることで、高可用性およびディザスタ・リカバリ機能が大幅に改善されます。AZは相互に分離され、一方の障害が他方に影響を与えないようにします。複数のAZにデータベース・インスタンスを分散することで、停電やハードウェアの問題など、ローカライズされた障害に関連するリスクを軽減できます。

    Active Data Guardは、プライマリ・データベースのリアルタイム同期レプリカを維持することで、この設定をさらに強化し、プライマリ・インスタンス障害が発生した場合にシームレスなフェイルオーバーを可能にします。このアプローチにより、継続的なデータ保護、ダウンタイムの最小化、および堅牢なディザスタ・リカバリ戦略が保証され、ミッションクリティカルなアプリケーションに回復力のあるインフラストラクチャが提供されます。

  • スループット

    オンプレミスからAzureにデータベースを移行する場合、スムーズで効率的な転送を実現するために、Azure ExpressRouteの帯域幅を考慮することが重要です。たとえば、100 GBの小規模なデータベースを移行する場合、200 Mbps ExpressRoute回線は、最適な条件とオーバーヘッドがないと仮定して、約1時間10分で転送を処理できます。ただし、1TBの大きいデータベースの場合、同じ200 Mbps回線には約11時間40分かかります。1Gbps回路にアップグレードすると、この時間が約2時間20分に大幅に短縮されます。帯域幅全体が消費されないように適切に計画します。そうしないと、オンプレミスとクラウド間で通信する他のアプリケーションが影響を受ける可能性があります。

詳細の参照

Oracle Databaseと関連ツールについてさらに学習するには、次のリソースを参照してください。

このリファレンス・アーキテクチャを実装するには、次のデプロイメント・リソースを確認します。

次の追加リソースを確認します。

確認

  • 作成者: Neeraj Tyagi, Thomas Van Buggenhout
  • コントリビュータ: Emiel Ramakers, John Sulyok