Azure Virtual Machines ランディング ゾーン アクセラレータ上の Oracle のビジネス継続性とディザスター リカバリー

この記事は、 ビジネス継続性とディザスター リカバリー (BCDR) に関する Azure ランディング ゾーンの設計領域で定義されている考慮事項と推奨事項に基づいています。 この記事では、そのガイダンスに従い、Azure インフラストラクチャ仮想マシン (VM) での Oracle ワークロード デプロイの BCDR オプションに関する設計上の考慮事項とベスト プラクティスについて説明します。

Azure には、高可用性と回復性を備えたアーキテクチャを設計するために使用できるサービスが用意されています。 このガイドでは、Azure Virtual Machines ランディング ゾーン アクセラレータで Oracle データベースの高可用性とディザスター リカバリーを設計するのに役立つさまざまなオプションとベスト プラクティスについて説明します。 ソリューションのエンドツーエンドの高い可用性を実現するために、付随する Azure サービスを構成する方法についても説明します。

作業の開始

ワークロード環境用に回復性のあるアーキテクチャを構築するには、さまざまなレベルの障害に対する目標復旧時間 (RTO) と目標復旧時点 (RPO) に基づいて、ソリューションの可用性要件を決定します。 RTO は、インシデントの発生後に、アプリケーションが使用不可状態になる最大時間です。 RPO は、障害発生時のデータ損失の最大量です。 ソリューションの要件を決定したら、確立されたレベルの回復性と可用性を提供するようにアーキテクチャを設計します。

Oracle on Azure ワークロードでは、主に Oracle Data Guard が使用されます。これは、レプリケーション テクノロジを使用する Oracle Database Enterprise Edition の組み込み機能です。 Data Guard を使用して、高可用性とディザスター リカバリーのニーズを満たすことができます。 Data Guard には、最大パフォーマンス、最大可用性、最大保護の 3 つの保護モードがあります。 アーキテクチャ設計と、特定の RPO と RTO の要件に基づいて保護モードを選択します。

高可用性のためのワークロードの構成

Oracle ワークロードを実行する Azure Virtual Machines インスタンスでは、Azure Virtual Machine Scale Sets アーキテクチャ (特に柔軟なオーケストレーション モード) の恩恵を受けます。 高可用性構成では、凖リアルタイムのデータ レプリケーションと高速フェールオーバー機能が実現されます。 高可用性構成では、Azure データセンター レベルまたはリージョン レベルの障害に対する保護は実現されません。

適切な高可用性オプションの選択

次のフロー チャートを使用して、Oracle データベースに最適な高可用性オプションを選択します。

Data Guard を最大可用性モードで使用して高可用性を実現

最大可用性モードの Data Guard は、通常の操作に対してデータ損失の保証 (RPO=0) をゼロにして、最高の可用性を提供します。 Virtual Machine Scale Sets の柔軟なオーケストレーション内に作成される 2 つの Oracle データベース サーバーの高可用性構成では、障害ドメイン間に分散されたインスタンスに対して、サービス レベル アグリーメント (SLA) に 99.95% のサービス可用性が実現されます。 Azure では、 可用性ゾーンに分散されたインスタンスに対して 99.99% のサービス可用性が実現されます。 詳細については、「Virtual Machine Scale Sets の高可用性」を参照してください。

Azure での Data Guard の詳細な構成については、「Linux ベースの Azure VM に Oracle Data Guard を実装する」を参照してください。

Data Guard を最大保護モードで使用して高可用性を実現

トランザクション的に一貫性のあるデータベースのコピーが必要な場合は、Data Guard を最大保護モードで使用することを検討してください。 ただし、最大保護モードでは、スタンバイ データベースが使用できない場合、トランザクションを続行できません。 そのため、Virtual Machines Scale Sets の柔軟なオーケストレーションを使用しても、最大保護モードを使用すると SLA は 99.9% x 99.9% = 99.8% に低下します。 この構成ではデータ コピーの一貫性は確保されますが、必ずしも可用性が向上するとは限りません。

このアーキテクチャのその他の属性は最大可用性モードと同じです。 たとえば、RPO は 0 で RTO は 2 分以下です。

高可用性を実装する他の方法を検討する

次のセクションでは、高可用性に関する特別な考慮事項について説明します。

高可用性改善のために可用性ゾーンを使用する

Azure Availability Zones は同じ Azure リージョン内にある Azure データセンターです。 可用性ゾーンのラウンドトリップ待機時間は 2 ミリ秒未満です。 通常、可用性ゾーンはディザスター リカバリーの目的で使用しますが、高可用性を向上させるために使用できます。 その場合は、可用性ゾーンが提供する待機時間とスループットの量でソリューションを実行できることを確認する必要があります。

Virtual Machine Scale Sets の柔軟なオーケストレーションを使用する可用性ゾーンの利点は、VM の可用性 SLA が 99.99% に向上することです。

高可用性のために共有ストレージ クラスタリングを使用する

共有ストレージ クラスタリング テクノロジでは、ビジネス目標の達成に役立つ独自の属性を利用できます。 たとえば、共有ストレージを使用して Pacemaker と Corosync (PCS) クラスターを実装できます。 マネージド ディスク または Azure NetApp Files を PCS クラスター インスタンスの共有ストレージとして使用できます。 PCS クラスターはデータを複製しません。 これは、フェールオーバー間で変更されない静的 IP アドレスまたは IP ネットワーク名を持つ仮想 IP サービスを提供します。

近接通信配置グループを使用する

可能な限り待機時間を短くするには、VM どうしをできるだけ近づけます。 これらは 近接通信配置グループ内にデプロイできます。 近接通信配置グループは、Azure コンピューティング リソースが互いに物理的に近くに配置されるようにするための論理的なグループ化です。 近接通信配置グループは、短い待ち時間が必要なワークロードに役立ちます。

ディザスター リカバリー用にワークロードを構成する

ディザスター リカバリー アーキテクチャでは、Azure データセンターまたはリージョンに影響を与える障害、またはリージョン全体でアプリケーションの機能を妨げる障害に対する回復性が実現されます。 このようなシナリオでは、ワークロード全体を別のデータセンターまたはリージョンに移動する必要があります。

ソリューションの要件に基づいてディザスター リカバリー アーキテクチャを選択します。 RTO と RPO に基づいて要件を決定します。 ディザスター リカバリー アーキテクチャは例外的な障害ケースを対象としているため、フェールオーバー プロセスは手動で行われます。 高可用性設計では、フェールオーバー プロセスは自動的に行われます。 ディザスター リカバリー アーキテクチャでは RTO と RPO の要件が緩和されるため、コストが削減されます。

この記事では、プライマリ サーバーとセカンダリ サーバーの両方が Azure 上にあるシナリオを取り上げます。 ディザスター リカバリーの目的で、オンプレミスにプライマリ サーバーを配置し、Azure にセカンダリ サーバーを配置することもできます。 詳細については、「オンプレミスのプライマリ サイトと Azure のディザスター リカバリー サイト」を参照してください。

適切なディザスター リカバリー オプションを選択する

次のフロー チャートを使用して、Oracle データベースに最適なディザスター リカバリー オプションを選択します。

ディザスター リカバリーに Data Guard を使用する

Data Guard を使用して、ディザスター リカバリー サイトにデータをレプリケートできます。 そのサイトは、データ保護の要件に応じて、同じリージョンまたは異なるリージョンの別の可用性ゾーンとして使用します。 構成は運用サイトの可用性ゾーンの構造にも依存します。 ディザスター リカバリー シナリオでの Data Guard の実装は前に説明した高可用性シナリオと似ていますが、いくつかの重要な違いがあります。 次に例を示します。

• 高可用性シナリオでセカンダリ レプリカにフェールオーバーする場合は、要求を新しいプライマリ データベース インスタンスにリダイレクトするように Azure Load Balancer を構成します。

• ディザスター リカバリー サイトにフェールオーバーすると、ソリューション 全体 が新しいサイトにフェールオーバーされます。 待機時間の問題を回避するには、通常、アプリケーション サービスのフェールオーバーを構成する必要があります。

ディザスター リカバリー サイトが別のリージョンにある場合は、要件に応じてフェイルオーバー用にサイトを設計する必要があります。

1 つのデータセンター内の待機時間は、互いに遠く離れているデータセンター間の待機時間よりも短く、異なるリージョン間の待機時間よりもはるかに短くなります。 したがって、最も複雑度が低くコストのかからないオプションは、ディザスター リカバリー目的で Data Guard を最大パフォーマンス モードで使用することです。 最大パフォーマンス モードでデータ損失が発生する可能性が高すぎる場合は、Oracle Data Guard Far Sync メカニズムで最大可用性モードを使用できます。 ただし、Far Sync インスタンスは、プライマリ環境とスタンバイ環境で Active Data Guard ライセンスをトリガーします。 詳細については、「Oracle ライセンスの詳細」を参照してください。

さらに、Azure リージョンまたはデータセンター間でデータを送信する場合は、ディザスター リカバリー サイトに送信されるデータ (再実行ログなど) に対してエグレス コストが発生します。 データベース内のすべてのデータをレプリケートする必要がない場合は、Oracle Golden Gate ベースのレプリケーションを使用して、必要に応じて部分的なデータのみをレプリケートできるため、エグレス コストが下がります。

Azure での Data Guard の詳細な構成については、「Linux ベースの Azure Linux VM に Data Guard を実装する」を参照してください。

ディザスター リカバリーに Golden Gate を使用する

Golden Gate は、ソース データベースからターゲット データベースへ、または複数のプライマリ データベース間でのデータのリアルタイム レプリケーション、フィルタリング、および変換に使用できる論理レプリケーション ソフトウェアです。 この機能により、ソース データベースの変更がほぼリアルタイムでレプリケートされるため、ターゲット データベースは最新のデータで最新の状態に保たれます。

Golden Gate を使用して、ディザスター リカバリー構成でプライマリ データベースからセカンダリ データベースにデータをレプリケートできます。 Golden Gate は、データの一部のみを保護する必要がある場合に特に実用的です。 不要なデータのレプリケーションを回避するには、Golden Gate を使用してテーブルを選択的にレプリケートし、レプリケーション中にテーブル行を除外します。

Azure に Golden Gate を実装する方法の詳細なガイドについては、「Linux ベースの Azure VM に Golden Gate を実装する」を参照してください。

ディザスター リカバリーにバックアップを使用する

バックアップと復元はディザスター リカバリー アーキテクチャ向けの従来の方法です。 Azure 上の Oracle データベースのディザスター リカバリー方法としてのバックアップには、次の 2 つの主要なコンポーネントがあります。

• データベースからデータのバックアップを抽出して移動し、ディザスター リカバリー サイトに最新のデータがある状態にします。

• ディザスター リカバリー サイトで最新のデプロイメントを確保します。 サイトを更新するには、すべてのネットワーク コンポーネント、アプリケーション サーバー、および構成の同じデプロイメントをディザスター リカバリー サイトにレプリケートします。

データのレプリケートに使用できるバックアップ オプションは複数あります。 詳細については、「Azure 上の Oracle Database のバックアップ戦略」を参照してください。

ディザスター リカバリー サイトを維持するために、次のいずれかのアプローチを使用することを検討してください。

アプローチ 1: 余分なメンテナンス作業とコストを回避するために、ディザスター リカバリー サイトで物理的なデプロイメントを維持しないでください。 コードおよびサイト信頼性エンジニアリングのプラクティスとしてインフラストラクチャを使用して、リポジトリを開発および維持管理できます。 このリポジトリは、フェールオーバー時にディザスター リカバリー サイトに構成としてデプロイをレプリケートできます。 この方法では、フェイルオーバーが発生するまで物理リソースを使用しないため、コストが最適化されます。

アプローチ 2: 運用環境のスケーリングされたバージョンをデプロイして維持管理します。 小規模なワークロードに対して適切に機能し、フェイルオーバー時に必要に応じてスケールアップして本番環境の負荷に対応できる可能性のあるバージョンを用意します。 特に複雑なデプロイで、環境全体を作成するリスクを冒したくない場合や、RTO を低くするために迅速にフェイルオーバーする場合にこの方法がよく使用されます。

アプローチ 3: 最も高速な RTO とフェールオーバー時間のために、ディザスター リカバリー サイトにソリューション全体をデプロイして維持管理します。 この方法では、完全に冗長なインフラストラクチャを実行するため、コストが増加します。

ディザスター リカバリーを実装する他の方法を検討する

次のセクションでは、ディザスター リカバリーに関する特別な考慮事項について説明します。

Far Sync を使用する

Far Sync では高可用性機能は向上しませんが、Oracle データベースのゼロ データ損失保護機能を実現するために使用できます。 プライマリ データベースで障害が発生した場合、ワークロードでゼロ データ損失が求められる場合があります。 詳細については、「Azure 上の Oracle リファレンス アーキテクチャ」を参照してください。

適切なデータ レプリケーション テクノロジを選択する

この記事で紹介したテクノロジに加えて、2 つの Oracle データベース間でのデータ レプリケーションを容易にする任意のテクノロジを使用して、Azure 上の Oracle データベースの高可用性レプリカとディザスター リカバリー レプリカを維持できます。 選択するテクノロジでは、これらのカテゴリ全体のソリューション要件に対応している必要があります。

待機時間: 高可用性とディザスター リカバリーのためにプライマリ データベースからセカンダリ データベースに更新内容をレプリケートするのにかかる時間は、ソリューションの要件に準拠している必要があります。

帯域幅: 高可用性とディザスター リカバリーのためにデータをセカンダリ データベースにレプリケートするために必要な帯域幅の量とコスト。 Azure には、可用性ゾーン間の高速ネットワーク インフラストラクチャが用意されています。 ディザスター リカバリーの目的で他の Azure リージョンへのレプリケーションを検討する場合は、Azure データセンターを離れるデータの帯域幅とエグレス コストを考慮してください。

影響: レプリケーションがプライマリ データベース上のトランザクション処理に与える影響のレベルは、ソリューションの要件に準拠している必要があります。

データ損失: プライマリ データベースの突然の障害時に予想されるデータ損失の量は、ソリューションの要件に準拠している必要があります。

総保有コスト: Microsoft 以外のレプリケーション ソリューションの取得コストと、レプリケーション ソリューションの構成と保守に必要な労力を考慮してください。 これらの要素がソリューションの要件に準拠していることを確認します。

フェイルオーバー インスタンスを最適化する

Data Guard を高可用性モードまたは高保護モードで使用する場合、プライマリ サーバーに障害が発生したときにセカンダリ サーバーが自動的に起動するように自動フェイルオーバーを構成できます。 アプリケーション サーバーを適切に構成すると、フェールオーバー中にアプリケーションのダウンタイムがほとんど発生しないようにすることができます。

この実装では、フェールオーバー後にデータベースを同じように実行する必要があります。 そのため、プライマリ サーバーと同じ CPU、メモリ、入出力 (I/O) 容量を持つセカンダリ サーバーを構成する必要があります。 セカンダリサーバーで大容量を維持する必要があるため、Azure のコストと Oracle Database のライセンス コストが増加します。 通常、セカンダリ サーバーはユーザー要求を処理しません。

Azure では、可用性ゾーン内の VM に対して 99.9% の可用性が実現されます。 詳細については、「VM アップタイム SLA」を参照してください。 データ レプリケーション テクノロジを使用して、データベースのセカンダリ レプリカを同じ可用性ゾーン、異なる可用性ゾーン、または異なるリージョンに保持すると、セカンダリ容量を最適化できます。

このアプローチでは、セカンダリ データベースは、最新の状態を維持するために必要な容量で構成されます。 障害が発生すると、セカンダリ データベースはプライマリ データベースと同じ容量にサイズ変更されます。 この操作はエラーが発生した場合にのみ発生します。 そのため、通常の運用中はプライマリ サーバーのコストのごく一部に対してのみ支払いが発生します。 障害発生時にプライマリ データベースが動作しないため、他の Oracle データベース ライセンスは必要ありません。

セカンダリ データベースをレプリケーション先として運用するために必要な容量は、使用するレプリケーション テクノロジによって異なります。 基本的に、トランザクション オンライン トランザクション処理 (OLTP) システム上のワークロードには主に読み取り要求があります。 たとえば、OLTP アプリケーションでは、90% の読み取り操作と 10% の書き込み操作、または 95% の読み取り操作と5% の書き込み操作が一般的です。 データ レプリケーションは、基本的にソース データベースに要求を書き込む結果をレプリケートします。 このセットアップでは、プライマリ データベースの容量の 1/10 (読み取りが 90%、書き込みが 10% の比率の場合) でセカンダリ データベースが動作することが予想されます。

フェイルオーバー手順を自動化して、フェイルオーバー プロセス中にエンタープライズ標準を確実に満たすようにします。 エンドツーエンドのプロセスを効率化するサーバーサイズ変更操作を含めるようフェイルオーバー手順を構成できます。

サービス保護とデータ保護のためにネットワーク トポロジを構成する

高可用性とディザスター リカバリーを実現するには、復旧時間 (RTO) と潜在的なデータ損失 (RPO) と、他の Oracle ライセンス、VM サービス、およびデータ転送のコストとのバランスを取る財務およびビジネス上の意思決定を行う必要があります。 1 つの Azure VM でワークロードをホストすると、一般的なハードウェア障害に対する基本的な保護を低コストで実現できます。 ただし、1 つの VM で障害が発生すると、ダウンタイムとデータ損失が発生する可能性があります。 そのため、運用環境では、Data Guard を使用して別の VM でホストされている少なくとも 1 つのセカンダリ Oracle データベースを含めます。 要件に応じて、次の Data Guard 構成のうち 1 つ以上をデータ レプリケーションに使用します。

• 最適な RTO と RPO。 待機時間を最小限に抑えるには、セカンダリ Oracle データベースを、プライマリ データベースと同じ Virtual Machine Scale Sets の柔軟なオーケストレーション内および同じ可用性ゾーン内の別の VM に組み込みます。 この構成では、単一インスタンスの障害に対する高可用性と保護が実現されます。

• データセンター障害からのデータ保護。 セカンダリ Oracle データベースを 2 つ目の可用性ゾーンに配置して、高可用性セットアップを実現し、可用性ゾーン全体が失敗した場合の保護を実現します。 この構成では、プライマリ データベースとセカンダリ データベースの間に最大 2 ミリ秒の待機時間が発生する可能性があり、パフォーマンス、RTO、RPO に影響を与える可能性があります。

• リージョン障害からのデータ保護。 Azure リージョンの障害による潜在的なデータ損失から保護するために、セカンダリ データベースを別のリージョンに配置できます。 この構成では、リージョン間で 30 ミリ秒から 300 ミリ秒の待機時間が発生する可能性があるため、RTO と RPO の目標を満たせない可能性があります。 このソリューションは、高可用性ではなく、リージョンのディザスター リカバリーに最適です。

ビジネス継続性には、ワークロードのすべてのコンポーネントを含む統合アプローチが必要です。 ネットワーク インフラストラクチャは、Azure 上の任意のワークロードのプライマリ コンポーネントです。 ネットワーク インフラストラクチャは、高可用性またはディザスター リカバリー アーキテクチャに合わせる必要があります。 次のネットワーク インフラストラクチャ要素を考慮してください。

• Data Guard は高可用性を実現し、ほとんどのシナリオで一般的な障害に対して十分なサポートを提供します。 Virtual Machine Scale Sets の柔軟なオーケストレーションに VM を配置できます。 ネットワーク待機時間を短縮するには、1 つのソリューション内のすべてのサービスを同じ可用性ゾーン内に配置し、サービス間で同じ仮想ネットワークを共有する必要があります。

  さらに保護を強化するために、VM を 1 つの可用性ゾーンではなく別々の可用性ゾーンに戦略的に配置できます。 このアプローチにより、データセンターの障害時のダウンタイムを防ぐことができます。

• 保護を最大限に高める場合は、プライマリ データベース リージョンとは異なる Azure リージョンにセカンダリ データベースを配置できます。 継続的な更新を適用するには、Data Guard を使用してグローバル仮想ネットワーク ピアリングを実装できます。 このアプローチを使用して、Microsoft バックボーンを介してセカンダリ リージョンにデータ更新をプライベートに適用します。 リソースは、ゲートウェイ、余計なホップ、またはパブリック インターネットの経由なしで直接通信します。

  このネットワーク オプションにより、異なるリージョンのピアリングされた仮想ネットワーク間で帯域幅が広く待機時間の短い接続が実現します。 グローバル仮想ネットワーク ピアリングを使用して、プライマリ サイトを高速ネットワークを介して別のリージョンのディザスター リカバリー サイトに接続できます。

さまざまな障害タイプに対する回復性の概要

次のステップ

エンタープライズ規模のシナリオにおける Oracle on Virtual Machines ランディング ゾーン アクセラレータ セキュリティの設計に関する考慮事項について説明します。

Oracle on Virtual Machines ランディング ゾーン アクセラレータのセキュリティ ガイドライン