ビジネス継続性とディザスター リカバリーを最適化する

Oracle リソースを Azure に移行する場合は、データベースの信頼性と、仮想マシン (VM)、仮想ネットワーク サブネット、ストレージ コンポーネント上の層の信頼性も考慮してください。

Oracle on Azure のサービスとしてのインフラストラクチャ (IaaS) は、最も要求の厳しい Oracle ワークロードの必要な回復性の目標を満たすことができます。 この記事のガイダンスを効果的に使用するには、まず、ビジネス要件に基づいて回復性の主要業績評価指標 (KPI) を定義します。 目標復旧時間 (RTO) と目標復旧ポイント (RPO) の要件をベースライン KPI として使用して、Azure 上の Oracle ワークロードに最適なアーキテクチャを決定します。

RTO は、障害、障害、または同等のイベントの後にアプリケーションが使用できなくなる最大時間です。

RPO は、障害、障害、または同等のイベントの後のデータ損失の最大量です。

データ保護のバックアップ方法

Azure IaaS 上の Oracle ワークロードの 3 つの Oracle データベース バックアップ方法は次のとおりです。

• ストリーミング バックアップ。 このメソッドには Oracle Recovery Manager (RMAN) を使用します。 RMAN は、バックアップをシーケンシャル テープ メディアにストリーム配信します。

  Azure のバックアップ先は次のとおりです。

  • Microsoft 以外の仮想テープ ライブラリ。Azure Marketplaceで確認できます。
  • ネットワーク ファイル システム プロトコル、Azure Files、Azure NetApp Filesを使用したAzure Blob Storageなど、ローカルおよびリモートのファイル共有。

• ストレージ レベルのスナップショット。 このメソッドには Azure Backup を使用します。 このメソッドは、データベース ファイルに使用するストレージの種類に依存します。 たとえば、Azure Premium SSD などの Azure マネージド ディスクを使用する場合、Azure Backupは Oracle データベースと統合されます。 Azure NetApp Filesを使用する場合は、バックアップやリージョン間レプリケーションなどのAzure NetApp Filesデータ保護機能Azure NetApp Files使用できます。

• VM レベルのバックアップ。 このメソッドには Azure Backup を使用します。

大規模なデータベースのバックアップをストリーミングする場合、データをコピーして復元するのにかかる時間が、RTO 要件を超える可能性があります。 ストレージ レベルのスナップショットは、そのシナリオに最適なオプションです。

Recommendations

• ストリーミング、ストレージ レベルのスナップショット、または両方の戦略に基づくバックアップ戦略を実装するかどうかを慎重に検討してください。

• バックアップ戦略が RTO と RPO の要件に及ぼす影響を評価します。

• 各オプションの文書化されたスループット制限に基づいて、RMAN バックアップで使用可能なストレージの宛先を分析します。 要件を満たすオプションを選択します。

• ストレージ レベルのスナップショットにAzure Backupを使用することを検討し、追加の保護のために、ペアのリージョンまたは可用性ゾーンにスナップショットを配置することを検討してください。

• データベースの復旧に必要なアーカイブ ログ バックアップを格納するには、さまざまなストレージ オプションを検討してください。 各オプションのパフォーマンス、レプリケーション、コストに関する考慮事項を検討してください。

• 運用環境で望ましくない驚きを防ぐために、バックアップと復元の計画を開発し、定期的にテストします。

サービス保護とビジネス継続性

このセクションでは、サービス保護とビジネス継続性 (BC) に関する考慮事項を実装することで、Azure IaaS 上の Oracle ワークロードの全体的な高可用性 (HA) とディザスター リカバリー (DR) を改善する方法について説明します。

次の推奨事項を組み込んでアーキテクチャの冗長性を向上させ、最終的にはサービスを利用できる時間を最大化します。 パッチ、更新プログラム、アップグレードなどの計画的な停止や、障害などの計画外の停止によるサービスのダウンタイムを最小限に抑えることを目的としています。 Azure と Oracle の機能を使用して、地理的な障害からの復旧を改善します。

Azure には、Oracle on IaaS アーキテクチャの個々のコンポーネントの高可用性に関する多くのオプションが用意されています。 たとえば、次のように操作できます。

• 可用性セットに VM をデプロイして、個別の障害ドメインと更新ドメインを保証します。
• 可用性ゾーンをCreateして、データセンターの障害から保護します。
• リージョン全体の障害から保護するために、さまざまなリージョンにデプロイを配置します。

さまざまな Azure ストレージ機能により、ローカル冗長ストレージ、ゾーン冗長ストレージ、geo 冗長ストレージなど、さまざまなストレージ冗長レベルが提供されます。 Azure IaaS で Oracle ワークロードのデプロイを計画するときは、各オプションを検討してください。

Oracle データベース サービス保護セットアップのツールである Oracle Data Guard を使用することもできます。 Data Guard はトランザクション ログを転送し、1 つ以上のスタンバイ データベースに適用します。 このプロセスでは、計画メンテナンスまたは障害シナリオがある場合にフェールオーバーできるプライマリ データベースの正確なコピーが保持されます。

Data Guard には、最大保護、最大可用性、最大パフォーマンスの 3 つのデータ レプリケーション モードがあります。 各レプリケーション モードでは、ログ トランスポート モードの異なる組み合わせと、セカンダリ データベース上のアプリケーションに対して異なるトランザクション保証が提供されます。

ゼロ待機時間やゼロ データ損失戦略など、戦略に応じて、同期構成または非同期構成を選択できます。 また、ダウンタイムの最大要件に応じて、高速開始フェールオーバーを実装することもできます。 1 分未満または 5 分未満で最大 4 時間の回復を提供する参照アーキテクチャを使用できます。 Oracle Database のEnterprise Editionには、Data Guard が含まれています。

Oracle GoldenGate は、2 つのデータベース間でデータをレプリケートし、マルチプライマリ シナリオを有効にするために使用できるもう 1 つのツールです。 GoldenGate は別途購入する必要があります。

Recommendations

• Azure IaaS 実装上の Oracle のさまざまなインフラストラクチャ コンポーネントの高可用性のために Azure が提供する機能について考えてみましょう。

• Data Guard for HA と DR を使用する場合は、要件を満たすデータベース保護モードを慎重に選択します。 たとえば、最大パフォーマンス モードでは、ソースへの影響は最小限に抑えられますが、データ損失の可能性が最も高くなります。 詳細については、「BCDR for Oracle on Azure Virtual Machines ランディング ゾーン アクセラレータ」および「Oracle Data Guard 保護モード」を参照してください。

• フェールオーバー プロセスを自動化することを検討してください。 たとえば、高速開始フェールオーバーを使用できます。

• フェールオーバー プロセスのテスト手順を確立し、問題を回避するために定期的なテストを実行します。

• HA と DR の要件を満たすために、可用性ゾーンなどの Azure ネイティブ機能と、Data Guard などの Oracle ネイティブ ツールを使用して、ソリューションを総合的に設計します。 次の 2 つの例では、Azure ネイティブ コンポーネントと Oracle ネイティブ コンポーネントを使用します。

パッシブ スタンバイを使用してフェールオーバーをCreateする

このセクションでは、パッシブ スタンバイを使用した 2 可用性ゾーンデプロイにおけるビジネスクリティカルな Oracle アプリケーションのフェールオーバー シナリオの例について説明します。

Oracle E-Business Suite などのビジネスクリティカルな Oracle アプリケーションには、障害防止が必要であるため、包括的なアーキテクチャが必要です。

この例では次のとおりです。

• 2 つの可用性ゾーンのデプロイがあります。 アプリケーション層では、パッシブ セカンダリ VM で Azure Site Recoveryを使用します。

• Data Guard の高速開始フェールオーバー機能を利用します。 最高の可用性を得るには、2 つのオブザーバーをインストールすることをお勧めします。 プライマリ オブザーバーは可用性ゾーン 1 にあり、セカンダリ オブザーバーは可用性ゾーン 2 にあります。 オブザーバーはトラフィックを監視および転送します。 プライマリ データベースが使用できない場合、オブザーバーはセカンダリ データベースに自動的にフェールオーバーします。 Data Guard は再実行同期を実行します。再実行同期の期間は、再実行の構成によって異なります。

• Data Guard が、最大可用性、最大パフォーマンス、最大 保護などのデータ保護モードに構成されている。 ワークロード要件のモードの選択の詳細については、「 Oracle Data Guard 保護モード」を参照してください。

次のアーキテクチャでは、ダウンタイムのしきい値を 5 分未満にすることを目的としています。

アクティブ スタンバイを使用してフェールオーバーをCreateする

このセクションでは、アクティブ スタンバイを使用した 2 可用性ゾーンデプロイにおけるビジネスクリティカルな Oracle アプリケーションのフェールオーバー シナリオの例について説明します。

次の点に注意してください。

• Web サーバー層、アプリケーション層、およびデータベース層は、独自の仮想ネットワーク サブネットに存在します。

• プライマリ データベースは可用性ゾーン 1 に存在します。

• Active Data Guard を使用してプライマリ データベースをアクティブ スタンバイにレプリケートするデータベースは、可用性ゾーン 3 に存在します。

次のアーキテクチャは、1 分未満のダウンタイムしきい値を目的としています。 このフェールオーバー シナリオにはアクティブ スタンバイ構成がありますが、読み取り専用の機能があります。

次のステップ