Oracle Database@MulticloudでのExadata Databaseを使用したリージョン間DRのためのOCIネットワーキングの構築 (2026/05/18)

Oracle Database@MulticloudでのExadata Databaseを使用したリージョン間DRのためのOCIネットワーキングの構築 (2026/05/18)

https://www.ateam-oracle.com/odbx-cross-region-ha

投稿者：Catalin Andrei | Master Principal Cloud Architect

顧客がOracle Database@Multicloud上のExadata Databaseのリージョン間災害復旧の計画を開始する際、通常はデータベース層から議論が始まります。Data Guard、保護モード、スイッチオーバー、フェイルオーバー、および復旧目標が、初期の設計セッションで中心的な議題となる傾向があります。

Data Guardの設定時には、アクティブデータベースとスタンバイデータベース間の接続が確立されている必要があります。

アーキテクチャは図面上で見れば単純明快ですが、2つのリージョンにわたって一貫性のある構築を行うには、細部への注意が必要です。ハブのVCN、LPG、DRG、リモートピアリング接続、ルーティングテーブル、NSGはすべて整合していなければなりません。ルートが1つ欠けていたり、ピアリング手順が1つでも不完全だったりすると、完璧なDR設計が長時間のトラブルシューティング作業に変わってしまう可能性があります。

この解決策の一部を実行するには、3つの実際的な方法があります。

  1. OCI Web UIで構築する
  2. Terraformで構築する
  3. OCI Cloud Shellスクリプトを使用して構築します。

OCI Web UIで構築する

OCIコンソールは、すべてのオブジェクトを自分で作成できるため、設計を理解する上で最も直接的な方法です。トポロジーを学ぶことが目的であれば、ここが最適な出発点となります。Oracleのリファレンス実装をリージョンごとにステップバイステップで追っていくことで、ハブVCN、LPG、DRGアタッチメント、ルーティングテーブルがどのように連携しているかを正確に確認できます。

欠点は複雑さではなく、繰り返し作業である。

これは実験室規模であれば問題なく対応できます。しかし、再現性、監査可能性、あるいは確実なロールバック経路が必要になると、状況は大きく変わります。

UIの実装手順については、このリファレンスアーキテクチャで詳しく説明されています。

Terraformで構築する

ネットワーク設計をインフラストラクチャ・アズ・コードとして記述したい場合、Terraformは最適な選択肢です。レビューが容易になり、バージョン管理も簡単になり、環境間での展開も容易になります。チームが既にTerraformを使用している場合、長期的にはこのオプションが最も理にかなっていると言えるでしょう。

また、OCIネットワーキングがより広範なランディングゾーンやプラットフォームエンジニアリングモデルの一部である場合にも適しています。

その代償として、より包括的なIaCワークフローが導入されることになります。これは一部のチームにとっては強みとなりますが、OCI Cloud Shellとの連携を維持し、迅速な開発を望むチームにとっては、必要以上に複雑に感じられるかもしれません。

Terraformスクリプトは、マルチクラウド製品管理の公式GitHubリポジトリにあります。

OCI Cloud Shellスクリプトを使用して構築します。

Terraformは理想的なインフラストラクチャ・アズ・コードソリューションですが、プロジェクトによってはCI/CDプロセスに従うのが複雑になりすぎる場合があり、顧客はクラウドネイティブツールを使用してインフラストラクチャを実装する、よりシンプルなソリューションを必要としています。

このGitHubリポジトリには、Oracle Database@Multicloud環境におけるExadataのリージョン間災害復旧（DR）の実装に焦点を当てたスクリプトバンドルが含まれています。

このバンドルは、リージョン間DRアーキテクチャにおけるOCIネットワークタスクのみに特化しています。OCI CLI、Bash、およびOCI Cloud Shellで既に利用可能な標準Pythonを使用します。すべてのファイルを単一のフォルダに保持し、1つの設定ファイルを読み込み、1つのログファイルを書き込み、ロールバック用のタイムスタンプ付き状態ファイルを生成します。

実際には、セットアップスクリプトは入力値を検証し、Exadata VCNが想定されるコンパートメントに存在することを確認し、CIDRによってクライアントサブネットとバックアップサブネットを検出し、ハブVCNを作成し、LPGを作成してピアリングし、DRGとRPCを作成してピアリングし、ルーティングテーブルを更新し、リージョン間Oracle Netアクセス用のNSGを作成します。ロールバックスクリプトは、セットアップによって作成されたアーティファクトのみを削除し、部分的な障害が発生した場合でも安全に動作するように設計されています。

それは良い中間的な道と言えるでしょう。

  • フルTerraformワークフローよりも軽量
  • 手動コンソール作業よりも再現性が高い
  • リファレンスアーキテクチャに十分近いので、トラブルシューティングは直感的に行える。

このバンドルの価値は、DRGやLPGを作成できる点にあるのではありません。OCIコンソールでも既にそれらの機能は利用できます。

真の価値はガードレールにある。

  • 作成開始前の検証
  • 設定されたサブネットが欠落しているか曖昧な場合の明確な障害動作
  • 決定論的な命名
  • 明示的なピアリング検証
  • Exadata VCN、ハブVCN、およびDRGレイヤーを横断するルーティングプログラミング
  • ロールバックのための段階的な状態キャプチャ
  • セットアップによって作成されたものだけを削除するクリーンアップ

それは、災害復旧業務において重要な運用規律の一例である。

どちらの選択肢を選ぶべきでしょうか？

パターンを学習する場合は、Web UIから始めましょう。

再現性のあるプラットフォームを構築するのであれば、Terraformは長期的に見てより優れた選択肢となるでしょう。

Cloud Shellから簡単に実行でき、ネットワークに焦点を絞った実用的なOCIネイティブの自動化パスをお探しなら、このスクリプトバンドルは非常に適しています。

最後に

リージョンをまたいだ災害復旧は、単にフェイルオーバーの仕組みだけの問題ではありません。必要な時に、すべての経路が準備できているかどうかが重要なのです。

だからこそ、このネットワーク層は、時として見過ごされがちなほど、もっと注目されるべきなのです。OCI接続が正しく構築され、検証されれば、DR設計のデータベース側の基盤ははるかに強固なものになります。そして、まさにこの点において、クラウドシェルの自動化バンドルが真価を発揮するのです。

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

イメージ
ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
続きを読む

OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27)

イメージ
OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27) https://www.ateam-oracle.com/post/granular-routing-control-with-custom-route-tables-in-oci 投稿者： Achinthya Gopinath | Principal Cloud Architect OCIでは、カスタムVCNルート表をVNIC上の個々のVNICまたは特定のIPアドレスに割り当てることができるため、ルーティングの柔軟性を高める強力な新機能が導入されました。この更新により、異なるトラフィック・ルーティング・ポリシーを必要とするインスタンスに対して個別のサブネットを作成する必要がなくなります。 概要: 以前は、VCNルート表はサブネット・レベルでのみ割り当てられていました。つまり、同じサブネット内の異なるインスタンスで異なるルーティング・ルールが必要な場合は、別々のサブネットを作成し、ネットワーク設計に複雑さを加える必要がありました。 この機能により、次のことができるようになりました。 •    カスタムVCNルート表をVNICまたはVNICの特定のIPアドレスに割り当てます。 •    プライマリIPアドレスとセカンダリIPアドレスの両方にルーティング・ポリシーを適用します。 •    階層ルート表のプリファレンスを有効にします。このプリファレンスは、使用するルート表を決定する構造化アプローチに従います。 ルーティングに関する考慮事項: •    一度にトラフィック・ルーティングを決定するために使用されるルート表は1つのみです。 •    ルート表がIPアドレスに関連付けられている場合は、他のルート表よりも優先されます。 •    IPアドレス/VNICにルート表がない場合は、階層内の次に使用可能なルート表(VNICレベルまたはサブネット・レベル)が使用されます。 詳細の選択プロセス: 1.    VNICのIPアドレスにルート表が関連付けられている場合、その表はIPアドレスからのトラフィックのルーティングに使用されます。 2.  ...
続きを読む