この記事では、 Azure ランディング ゾーンの設計領域で説明されているビジネス継続性とディザスター リカバリー (BCDR) に関する考慮事項と推奨事項について詳しく説明します。 Oracle Exadata Database Serviceを使用して、Oracle Database@Azureの Oracle Maximum Availability Architecture(MAA) の原則を組み込んでいます。
Oracle Database@Azureで実行される Oracle データベースの回復性アーキテクチャを構築するための最初のステップは、ソリューションの可用性要件を特定することです。 計画されたイベントや計画外のイベントなど、さまざまなレベルの障害に対して、目標復旧時間 (RTO) と目標復旧時点 (RPO) を設定することが重要です。 RTOは、アプリケーションまたはビジネスが中断後に許容できる最大ダウンタイムを定義します。 RPO は、アプリケーションまたはビジネスが許容できるデータ損失の最大期間を指定します。 BCDR 設計を開始する前に、この前提条件に対処する必要があります。 ソリューションの要件を確立したら、RTO と RPO に合わせて Oracle Database@Azure 環境を設計できます。
詳細については、 DR 戦略の設計方法に関する Microsoft Azure Well-Architected Framework のガイドラインを参照してください。
設計に関する考慮事項
Oracle Exadata Database@Azureサービスは、リージョン内の2つの異なる可用性ゾーンで使用できます。 この可用性により、サービスの信頼性と DR を確保できます。 Oracle Exadata Database@Azureのデプロイ場所を確認するには、Azure ポータルで仮想マシン (VM) クラスターを確認します。
Oracle Exadata Database@Azureとそのコア・コンポーネントは、インスタンスを作成するアベイラビリティ・ゾーンに限定されます。 このサービスは、複数のゾーンをカバーしたり、複数のリージョンにまたがるわけではありません。 複数ゾーンまたは複数リージョンのレジリエンスを実現するために、新しいOracle Exadata Database@Azureインスタンスをターゲットの可用性ゾーンまたはリージョンにデプロイできます。
Oracle Exadata Database@Azureは、高可用性(HA)のためのOracle Real Application ClustersやDRのためのOracle Data Guardなど、ネイティブのOracleテクノロジを提供します。 Data Guard と Active Data Guard は、DR アーキテクチャでサポートされています。
Oracle Exadata Database@Azureは、デフォルトでデータベース・インスタンスおよびハードウェア・レベルの障害に対するHAを提供します。 このアーキテクチャは、 MAA シルバー レベルと一致しています。 計画的な保守作業はローリング方式で行うことができます。 ただし、デフォルトのシングルゾーンアーキテクチャでは、サイトまたは地域の障害に対するフォールトトレランスはゼロです。
このソリューションでは、DR の Data Guard 構成が自動化されます。 この設定は、別の可用性ゾーンまたはリージョンに別のOracle Exadata Database@Azureデプロイメントを要求することで、サイトの障害から保護するのに役立ちます。
プライマリとスタンバイの Oracle Exadata Database@Azure インスタンス間のネットワーク接続は、Azure ネットワークと Oracle Cloud Infrastructure (OCI) ネットワークを介して確立できます。 既定では、この接続のプライマリ ルートは Azure を経由します。
Oracle Exadata Database@Azureで使用可能な3つのバックアップ・オプションは次のとおりです。
OCI管理バックアップ: このオプションには、Oracle Database Autonomous Recovery ServiceとOracle Cloud Infrastructure Object Storageの2つの統合ソリューションが含まれています。 これらのソリューションは、OCIコンソールを介して管理されます。
Autonomous Recovery Serviceは、厳しいRTOおよびRPO要件を持つエンタープライズ・レベルのミッションクリティカルなワークロード向けに設計されています。 これは、サービスレベル契約を通じて可用性を提供します。 詳細は、 Oracle Platform as a ServiceおよびInfrastructure as a Serviceパブリック・クラウド・サービスのピラー・ドキュメントを参照してください。
OCI Object Storageは、RTOまたはRPO要件がそれほど厳しくないワークロードに適した汎用バックアップ・ソリューションです。
これらのソリューションにより、事前定義された保持期間でデータベースバックアップの自動スケジューリングと管理が可能になります。 詳細は、 Oracle 専用インフラストラクチャ上の Exadata Database Service でのデータベースのバックアップとリカバリの管理を参照してください。
自己管理型バックアップ: Oracle Exadata Database@Azure は、Azure Blob Storage、Azure Files (プライベート エンドポイント経由)、Azure NetApp Files などの Azure Storage サービスにデータベース バックアップをストリームするように構成できます。
このオプションには、手動設定と継続的なメンテナンスが必要です。
Microsoft以外のバックアップソリューション: Azure Marketplace で入手できる Microsoft 以外のバックアップ ソリューション ( Commvault など) を使用して、データベース バックアップを管理および格納できます。
設計に関する推奨事項
特定の要件に合わせて調整された回復力のあるアーキテクチャを構築するには、Oracle Exadata Database@Azureに関する次のBCDRの推奨事項を検討してください。
Data Guardを使用して少なくとも2つのOracle Exadata Database@Azureインスタンスを構成して、単一サイトの障害から保護する必要があります。 この設定は、 MAA ゴールド スタンダードに準拠しています。
マルチゾーン BCDR
マルチゾーン BCDR アーキテクチャは、単一リージョンのデータ所在地の要件を満たしながら、マルチゾーン冗長性を備えたゼロまたはほぼゼロの RPO を必要とするお客様に推奨されます。
このソリューションには、同じリージョン内の異なる可用性ゾーンにセカンダリOracle Exadata Database@Azureデプロイメントが含まれています。 データベース、クラスタ、またはアベイラビリティー・ゾーンの障害に対するレジリエンスを確保するには、セカンダリ・インスタンスにあるスタンバイ・データベースを実装します。 この設定により、サイトレベルの障害に対する保護が提供されます。
Data Guard REDO転送モード: Data Guard REDO転送モードは、アプリケーション・サービスおよびRPO要件に応じて構成します:
データの整合性とデータ損失ゼロ: データの整合性とデータ損失ゼロが最優先事項である場合は、最大可用性モード (SYNC) を使用します。 このモードでは、スタンバイ・データベースにデータが同期的にレプリケートされるため、データが失われることはありません。
システムパフォーマンス: システム・パフォーマンスが重要で、わずかなデータ損失が許容される場合は、最大パフォーマンス・モード (ASYNC) を使用してください。 このモードでは非同期レプリケーションが使用されるため、RPO は 0 よりわずかに大きくなります (またはゼロに近くなります)。
対称スタンバイインスタンスを維持します。 プライマリ・データベースと同等のリソースを持つ対称スタンバイ・インスタンスを維持して、スイッチオーバーおよびフェイルオーバー操作中に一貫したパフォーマンスを確保する必要があります。 または、最小限のリソースでスタンバイ・データベースを構成し、スイッチオーバーまたはフェイルオーバー後に必要に応じてVMクラスタを動的にスケール・アップすることもできます。 ただし、このアプローチでは、スケーリング操作とそのデータベース レベルでの反映に余分な時間が追加される可能性があります。
フェイルオーバー操作の自動化:Oracle Data Guard Fast-Start Failover を使用してフェイルオーバー操作を自動化し、RTO を最小限に抑え、エラーを減らします。
注
Fast-Start フェールオーバーはマネージド サービスではないため、手動で構成する必要があります。
この設定では、Data Guard の Fast-Start フェールオーバーを有効にするために、Oracle Data Guard オブザーバーを実行する追加の VM が必要です。 これらのオブザーバVMは、データベースとレプリケーションのステータスを監視し、フェイルオーバープロセスを自動化します。
フェイルオーバーが発生した場合に対称DRアーキテクチャが必要な場合は、セカンダリOracle Exadata Database@Azureデプロイメントが構成されている場所にオブザーバー・インスタンスを配置する必要があります。
マルチリージョン BCDR
マルチリージョンBCDR戦略の場合は、サービスが使用可能な別のリージョンにスタンバイ・データベースを配置したセカンダリOracle Exadata Database@Azureデプロイメントを実装します。 この設定により、リージョン全体の停止に対する保護が提供されます。
アプリケーション要件とプライマリ リージョンとセカンダリ リージョン間のネットワーク待機時間に基づいて、リージョン DR の非同期的にレプリケートするように Data Guard を構成します。 詳細については、「 Azure ネットワークラウンドトリップ待機時間の統計」を参照してください。
注
Automated Data Guard では、リージョン間デプロイの最大パフォーマンス モード (ASYNC) 構成のみが許可されます。
- マルチゾーンおよびマルチリージョンの BCDR の推奨事項は、データベース サービスの回復性に重点を置いています。 全体的なワークロードの回復性を確保するには、Azure Virtual Machine Scale Sets、Azure Site Recovery、Azure Front Door などの Azure サービスと機能を使用して、可用性ゾーンまたはリージョン間で堅牢なアーキテクチャを設計することを検討してください。
拡張 BCDR シナリオ
ローカル・スタンバイ・データベースとリモート・スタンバイ・データベース
堅牢なサービス可用性とリージョンの停止に対するレジリエンスの要件に対処するために、ミッションクリティカルなワークロードに複数のスタンバイ・データベースを実装することをお薦めします。
Oracle Exadata Database@Azureデプロイメント上のローカル・スタンバイ・データベースは、同じリージョン内の異なる可用性ゾーンに存在します。 このセットアップは、SYNC Data Guard レプリケーションを通じてデータ損失ゼロのフェイルオーバー要件に対処することで、遅延の影響を受けやすいアプリケーションに対して実行可能なソリューションを提供します。 この戦略により、アプリケーションのスループットや全体的な応答時間に影響を与えることなく、サービスの可用性を確保できます。
異なるリージョンにあるOracle Exadata Database@Azureインスタンス上のリモート・スタンバイ・データベースは、リージョンのDR要件に対応します。
このアーキテクチャは、ミッションクリティカルなワークロードに最適で、少なくとも3つのOracle Exadata Database@Azureデプロイメントが必要です。
注
フェイルオーバー・シナリオのために対称的な構成が必要な場合は、Oracle Exadata Database@Azureのセカンダリ・リージョンの別の可用性ゾーン内に追加のスタンバイ・データベースを配置します。
Data Guard Far Sync のアーキテクチャ
Data Guard Far Sync 構成を使用して、任意の距離でデータ損失ゼロのレプリケーションを実装する要件を満たすことができます。 このアプローチには、REDOログを同期的に送信するために、プライマリOracle Exadata Database@Azureデプロイメントに近い、基本的に同じリージョン内の別の可用性ゾーンに 遠隔同期インスタンス を配置することが含まれます。 その後、遠隔同期インスタンスは、これらのログを別のリージョンのセカンダリOracle Exadata Database@Azureデプロイメントで実行されるスタンバイ・データベースに非同期に転送します。 この設定により、リージョン間のレプリケーションデータ損失が実質的にゼロになります。
フェイルオーバーが発生した場合に対称DRアーキテクチャを探す場合は、セカンダリOracle Exadata Database@Azureデプロイメントが構成されている別の可用性ゾーンに遠隔同期インスタンスを配置します。
注
Far Sync アーキテクチャには Active Data Guard ライセンスが必要であり、手動で構成する必要があります。
バックアップに関する推奨事項
BCDR 要件の唯一のソリューションとしてバックアップを使用する予定の場合は、RTO はデータベースのサイズと使用するバックアップ方法に基づいているため、レプリケーション シナリオと比較して高くなることに注意してください。
Azure 内でデータをバックアップします。 データとバックアップを Azure に残すことを義務付ける組織の要件を満たすには、次のソリューションを検討してください。
Azure で Autonomous Recovery Service (ARS) を使用します。 バックアップ ポリシーの構成中に、Azure で ARS を使用するために、 データベースと同じクラウド プロバイダーにバックアップ データを格納する ことを選択します。
ストレージサービスを使用する: Blob Storage、Azure Files、Azure NetApp Files などのストレージ サービスを使用して、データベース サーバー上のネットワーク ファイル システム (NFS) ポイントとしてストレージをマウントし、Oracle Recovery Manager (RMAN) バックアップをストレージにストリーミングします。
長期バックアップ保持: 組織で長期的なバックアップ保持が必要な場合は、Azure Storage への自己管理型 RMAN バックアップを構成できます。
ストレージバックアップ構成: バックアップをストレージ・サービスに構成する場合は、次の推奨事項を考慮してください。
cron ジョブでスケジュールします。 データベース・ノード・レベルで cron ジョブを使用して、バックアップ戦略に基づいて特定の時間にバックアップをスケジュールします。
バックアップのレプリケート: ゾーン冗長ストレージや geo 冗長ストレージなど、Azure の基になるストレージ レプリケーション機能を使用して、バックアップをレプリケートします。
バックアップおよび復元操作: Oracle Exadata Database@Azure VMを手動でバックアップして、誤って削除または破損した場合に重要なファイルをリストアします。 詳細は、 Oracle Exadata Cloud Computeノードのバックアップおよびリストア操作(ドキュメントID 2809393.1)を参照してください。
その他の推奨事項
Azure 内にデータを保持します。 データを Azure 内にのみ保持する必要がある場合は、Data Guard トラフィックを Azure ネットワーク経由でルーティングし、バックアップを Azure に保持するように構成します。
DRのテスト: フェイルオーバーとスイッチオーバーの操作をテストして、実際の災害シナリオで機能することを確認します。
Oracle Fast-Start Failoverを使用して、可能な場合はフェイルオーバー操作を自動化し、エラーを最小限に抑えます。
Oracle Application Continuityを使用して、アプリケーション・レイヤーでの停止をシームレスにマスキングします。
リアルタイムのデータとレプリケーション: アクティブ/アクティブ環境の場合は、 Oracle GoldenGate を使用してリアルタイムのデータ統合およびレプリケーション機能を使用することを検討してください。 競合解決を効果的に処理するには、アプリケーションレベルの認識が必要です。
注
GoldenGate はこのソリューションに含まれていないため、追加のライセンス コストが発生する可能性があります。
中断を最小限に抑えます。 ワークロードの中断を最小限に抑えるには、オフピーク時に計画メンテナンスをスケジュールします。 可能であれば、ローリング方式の更新を使用して、シームレスなプロセスを確保します。
Infrastructure as Code (IaC) を使用します。 インフラストラクチャの自動化の信頼性を高めるには、IaCを使用して初期のOracle Exadata Database@AzureインスタンスおよびVMクラスタをデプロイします。 Oracle Database@Azure の自動化の詳細については、 Terraform モジュールまたは OpenTofu モジュールを使用した Oracle Database@Azure のクイックスタートを参照してください。
Azure 検証済みモジュールを使用して、Oracle Exadata Database@Azure インスタンスと VM クラスターをデプロイします。 詳細については、次のリソースを参照してください。
IaCを使用して、OCIコンソールでデータベースをデプロイします。 IaC を使用して、同じデプロイを DR サイトにレプリケートし、人為的エラーのリスクを最小限に抑えることができます。