ExascaleインフラストラクチャでのOracle Exadata Database Serviceの準備

OCIに加え、サイト、ネットワークおよびストレージの要件を確認して、Oracle Exadata Database ServiceをExascale Infrastructureに準備し、データ・センターにデプロイします。

Oracle Exadata Database Service on Exascale InfrastructureのOracle Cloud Infrastructure (OCI)要件

Oracle Cloud Infrastructureの使用を開始するための基本的な概念について学習します。

Oracle Exadata Database Service on Exascale Infrastructureは、Oracle Cloud Infrastructure (OCI)コントロール・プレーンによって管理されます。Oracle Exadata Database Service on Exascale InfrastructureリソースはOCIテナンシにデプロイされます。

ExascaleインフラストラクチャでOracle Exadata Database Serviceをプロビジョニングするには、Oracle Cloud InfrastructureテナンシでExascaleインフラストラクチャでOracle Exadata Database Serviceを使用する必要があります。詳細は、このドキュメントの情報を確認してください。

次のタスクは、すべてのOCIデプロイメントで共通です。関連トピックのリンクを参照して、関連するOracle Cloud Infrastructureドキュメントを確認してください。

  • OCIの開始。

    OCIを初めて使用する場合は、OCIスタート・ガイドに従って、開始するための基本的な概念について学習します。

  • テナンシの設定。

    OracleがOCIでテナンシを作成した後、会社の管理者は、いくつかの設定タスクを実行し、クラウド・リソースおよびユーザーの組織計画を確立する必要があります。このトピックの情報は、作業の開始に役立ちます。

  • リージョンの管理

    このトピックでは、リージョン・サブスクリプションの管理の基本について説明します。

  • コンパートメントの管理

    このトピックでは、コンパートメントの作業の基本について説明します。

  • ユーザーの管理

    このトピックでは、ユーザーの作業の基本について説明します。

  • グループの管理

    このトピックでは、グループの作業の基本について説明します。

Exascaleインフラストラクチャ上のOracle Exadata Database Serviceに必要なIAMポリシー

Oracle Exadata Database Service on Exascale Infrastructureシステムをプロビジョニングするためのアイデンティティ・アクセス管理(IAM)ポリシーを確認します。

ポリシーは、リソースに対して誰がどのタイプのアクセス権を持つかを指定するIAMドキュメントです。これは様々な方法で使用されます:
  • ポリシー言語で記述された個々のステートメント
  • Oracle Cloud ID (OCID)が割り当てられている、単一の名前付きポリシー・ドキュメントに含まれるステートメントのコレクション
  • 組織がリソースへのアクセスを制御するために使用する各ポリシーの全体

コンパートメントは、組織の管理者から権限を付与された特定のグループのみがアクセスできる関連リソースのコレクションです。

Oracle Cloud Infrastructureを使用するには、管理者が記述するポリシーで、コンソールを使用するか、ソフトウェア開発キット(SDK)、コマンドライン・インタフェース(CLI)またはその他のツールでREST APIを使用するかにかかわらず、必要なタイプのアクセス権が付与されている必要があります。アクションを実行しようとして、権限がない、または認可されていないというメッセージが表示された場合は、付与されているアクセスのタイプと作業するコンパートメントをテナンシ管理者に確認してください。

管理者の場合: 「データベース管理者がDBシステムを管理できるようにします」というポリシーにより、指定したグループがデータベースおよび関連データベース・リソースに対してすべてのことを実行できます。

ポリシーを初めて使用する場合は、「ポリシーの開始」および「共通ポリシー」を参照してください。データベースのポリシーの記述を詳細に調査する場合は、「データベース・サービスの詳細」を参照してください。

Exadata Cloud@Customerリソースに固有のポリシーの記述の詳細は、「Exascaleインフラストラクチャ上のOracle Exadata Database Serviceのポリシー詳細」を参照してください。

Exascaleインフラストラクチャ・インスタンス上のOracle Exadata Database Serviceのネットワーク設定

このトピックでは、VCNの推奨構成と、Exascale Infrastructureインスタンス上のOracle Exadata Database Serviceの関連要件について説明します。

Exascaleインフラストラクチャ・インスタンスにOracle Exadata Database Serviceを設定する前に、仮想クラウド・ネットワーク(VCN)と他のネットワーキング・サービス・コンポーネントを設定する必要があります。

VCNおよびサブネット

ExascaleインフラストラクチャVMクラスタでOracle Exadata Database Serviceを起動するには、Virtual Cloudネットワークと少なくとも2つのサブネットが必要です。

ExascaleインフラストラクチャVMクラスタでOracle Exadata Database Serviceを起動するには、Virtual Cloudネットワーク(少なくとも2つのサブネット)があり、使用するDNSリゾルバのタイプを選択する必要があります:

  • ExascaleインフラストラクチャVMクラスタ上のOracle Exadata Database Serviceが必要なリージョンのVCN
  • VCNに少なくとも2つのサブネット。2つのサブネットは次のとおりです:

    • クライアントのサブネット
    • バックアップ・サブネット・
  • 使用するDNS名前解決の方法を選択します。VCNのDNSの選択肢を参照してください

一般的に、Oracleでは、リージョン内のすべての可用性ドメインにまたがるリージョナル・サブネットを使用することをお薦めします。詳細は、VCNおよびサブネットの概要を参照してください。

サブネットごとにカスタム・ルート表を作成します。Exadataコンピュート・ノード(クラウドVMクラスタ・リソースの場合、ノードは仮想マシンと呼ばれます)のクライアント・ネットワークおよびバックアップ・ネットワークとのトラフィックを制御するためのセキュリティ・ルールも作成します。これらの項目の詳細を次に示します。

オプション1: インターネット・ゲートウェイを使用したパブリック・クライアント・サブネット

このオプションは、概念実証または開発作業を行う際に役立ちます。

インターネット・ゲートウェイをVCNとともに使用する場合、またはパブリック・ネットワークのみで実行され、データベースへのアクセスが必要なサービスがある場合は、この設定を本番で使用できます。次の図および説明を参照してください。

network_exa_public_client.pngの説明が続きます
図network_exa_public_client.pngの説明

設定するもの:

  • サブネット:

    • パブリック・クライアント・サブネット(パブリックとは、サブネット内のリソースが任意でパブリックIPアドレスを持つことができることを意味します)。
    • プライベート・バックアップ・サブネット(プライベートとは、サブネット内のリソースがパブリックIPアドレスを持つことができず、インターネットからの着信接続を受信できないことを意味します)。
  • VCNのゲートウェイ:

  • ルート表:

    • 0.0.0.0/0およびターゲット = インターネット・ゲートウェイのルートを含むパブリック・クライアント・サブネットのカスタム・ルート表。
    • サービスCIDRラベル(CIDRラベルについては、サービス・ゲートウェイの概要および使用可能なサービスCIDRラベルを参照)、およびターゲット = サービス・ゲートウェイのルート・ルールを含むプライベート・バックアップ・サブネットの個別のカスタム・ルート表。
  • Exadata仮想マシンのコンピュート・ノードとの間で必要なトラフィックを有効化するセキュリティ・ルール
  • Exadata Cloud Serviceインスタンスのコンピュート・ノード上のオブジェクト・ストレージへのノード・アクセス: 静的ルート(バックアップ・サブネットを介したOCIサービスへのアクセスを有効にするため)。
ノート

パブリック・サブネットに関連付けられているルート表でサービス・ゲートウェイをターゲットとして使用するルート・ルールを構成する方法の詳細は、この既知の問題を参照してください。
オプション2: プライベート・サブネット

本番システムにはプライベート・サブネットをお薦めします。

どちらのサブネットもプライベートであるため、インターネットからはアクセスできません。次の図および説明を参照してください。

network_exa_private_client.pngの説明が続きます
図network_exa_private_client.pngの説明

設定するもの:

  • サブネット:

    • プライベート・クライアント・サブネット。
    • プライベート・バックアップ・サブネット。
  • VCNのゲートウェイ:

  • ルート表:

    • 次のルールを含む、プライベート・クライアント・サブネットのカスタム・ルート表:

      • オンプレミス・ネットワークのCIDRおよびターゲット = DRGのルール。
      • サービスCIDRラベルOracle Services Networkのすべての<region>サービスでターゲット = サービス・ゲートウェイのルール。Oracle Services Networkは、Oracleサービス用に予約されているOracle Cloud Infrastructureの概念的なネットワークです。このルールによって、クライアント・サブネットがOSの更新のためにリージョンのOracle YUMリポジトリにアクセスできるようになります。また、オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイ・アクセスも参照してください。
      • オプションで、0.0.0.0/0、およびターゲット = NATゲートウェイのルール。
    • 1つのルールを含む、プライベート・バックアップ・サブネットの別のカスタム・ルート表:
      • クライアント・サブネット用と同じルール: サービスCIDRラベルOracle Services Networkのすべての<region>サービスで、ターゲット = サービス・ゲートウェイ用。このルールは、バックアップ・サブネットがバックアップのためにリージョンのオブジェクト・ストレージにアクセスできるようにします。
  • Exadataノードとの間で必要なトラフィックを有効化するセキュリティ・ルールExadata Cloud Serviceインスタンスのセキュリティ・ルールを参照してください。
  • オプションで、他のOCIサービス(VMクラスタ、仮想マシン)へのコンピュート・ノード上の静的ルートを追加し、サービスが、NATゲートウェイを使用するなどのクライアント・サブネットを介してではなく、バックアップ・サブネット上でのみ到達可能な場合、アクセスを可能にします。
IPアドレス空間の要件

2つのサブネットを含むVCNを作成し、VMクラスタのサイズに対して十分なアドレスがあることを確認する必要があります。

ノート

特にExadata Cloud Infrastructureインスタンス(つまりVCN)が複数のリージョンにある場合、IPアドレスは重複できません。

複数のリージョンにVMクラスタ(したがってVCN)を設定する場合は、VCNのIPアドレス空間が重複しないようにしてください。これは、Oracle Data Guardでディザスタ・リカバリを設定する場合に重要です。

クライアント・サブネットでは、各ノードが4つのIPアドレスを必要とし、さらに、3つのアドレスが単一クライアント・アクセス名(SCAN)用に予約されています。バックアップ・サブネットでは、各ノードに3つのアドレスが必要です。ネットワーキング・サービスでは、各サブネットに3つのIPアドレスを予約しています。

次の式を使用して、変数nがVMクラスタ内のVMの数であるIPアドレスの最小数を計算します。

クライアント・アドレスの最小数= 4*n+6

バックアップ・アドレスの最小数= 3*n+3

ノート

サブネットに必要な最小容量より大きい容量を割り当てると(例: /28のかわりに少なくとも/25)、これらの予約済アドレスがサブネットの使用可能領域に与える相対的な影響を軽減できます。将来の拡張を計画するには、VMクラスタをスケール・アップする際に必要となるアドレスを追加します。これは、即時に必要になるようにプロビジョニングする予定のVMの数のみではありません。
オブジェクト・ストアにアクセスするための静的ルートの構成
Exascale Infrastructureインスタンス上のOracle Exadata Database Service内のすべてのトラフィックは、デフォルトではデータ・ネットワークを介してルーティングされます。バックアップ・トラフィックをバックアップ・インタフェース(BONDETH1)にルーティングするには、クラスタ内のコンピュート・ノードで静的ルートを構成する必要があります。

手順については、オブジェクト・ストレージへのノード・アクセス: 静的ルートを参照してください。

Exascaleインフラストラクチャ・インスタンス上のOracle Exadata Database ServiceのDNSの設定

DNSを使用すると、IPアドレスのかわりにホスト名を使用してExadata Cloud Infrastructureインスタンスと通信できます。

仮想クラウド・ネットワークのDNSで説明されているように、Internet and VCN Resolver (VCNに組み込まれたDNS機能)を使用できます。クライアント・サブネットのDNS名前解決にはVCN Resolverを使用することをお薦めします。Exadataインスタンスでのデータベースのバックアップ、クラウド・ツールのパッチ適用および更新に必要なSwiftエンドポイントが自動的に解決されます。

DNS: Exascaleインフラストラクチャ・インスタンス上のVCN、サブネットおよびOracle Exadata Database Serviceの短縮名
ノードが通信するには、VCNでInternet and VCN Resolverを使用する必要があります。インターネットおよびVCNリゾルバにより、ノードへのホスト名の割当て、およびVCN内のリソースごとのこれらのホストのDNS解決が可能になります。

インターネットおよびVCNリゾルバにより、データベースのSCANのラウンドロビン解決が有効になります。Oracle Exadata Database Service on Exascale Infrastructureインスタンスでのデータベースのバックアップ、クラウド・ツールのパッチ適用および更新に必要な重要なサービス・エンドポイントも解決できます。Internet and VCN Resolverは、VCN内のDNSに対するVCNのデフォルトの選択肢です。詳細は、仮想クラウド・ネットワークのDNSおよびDHCPオプションを参照してください。

VCN、サブネットおよびExadataを作成する場合、VCNのDNSに関連して次の識別子を慎重に設定する必要があります:

  • VCNドメイン・ラベル
  • サブネット・ドメイン・ラベル
  • Exascaleインフラストラクチャ・インスタンスのクラウドVMクラスタまたはDBシステム・リソース上のOracle Exadata Database Serviceのホスト名接頭辞

これらの値は、ノードの完全修飾ドメイン名(FQDN)を構成します:

<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

例:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

この例では、クラウドVMクラスタまたはDBシステムの作成時に、ホスト名の接頭辞としてexacsを割り当てます。データベース・サービスによって、ハイフンと、5文字の文字列、末尾のノード番号が自動的に追加されます。例:

  • ノード1: exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
  • ノード2: exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
  • ノード3: exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
  • その他

ホスト名の接頭辞の要件:

  • 推奨最大文字数: 12文字。詳細は、「VCNおよびサブネット・ドメイン・ラベルの要件」のを参照してください。
  • 文字列localhostにすることはできません

VCNおよびサブネット・ドメイン・ラベルの要件:

  • 推奨最大文字数: それぞれ14文字。基礎となる実際の要件は、両方のドメイン・ラベルで合計28文字です(ラベル間のピリオドは除く)。たとえば、subnetad1.verylongvcnphxまたはverylongsubnetad1.vcnphxのどちらも使用できます。簡単にするために、推奨はそれぞれ14文字です。
  • ハイフンやアンダースコアは使用できません。
  • 推奨: VCNのドメイン・ラベルにリージョン名を含め、サブネットのドメイン・ラベルに可用性ドメイン名を含めます。

  • 一般に、FQDNの最大合計制限は63文字です。安全な一般ルールを次に示します:

    <12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com

VCNおよびサブネットの作成時、前述の最大値は強制されません。ただし、ラベルが最大を超えると、Exadataデプロイメントは失敗します。

DNS: オンプレミス・ネットワークとVCNの間

プライベートDNSリゾルバを使用して、オンプレミス・ホストとVCNリソースが相互に通信するときにホスト名の使用を有効にすることをお薦めします。

プライベート・リゾルバの作成および使用の詳細は、プライベートDNSリゾルバを参照してください。リファレンス・アーキテクチャについては、Oracle Architecture CenterのVCNでのプライベートDNSの使用を参照してください。

プライベートDNSの構成

プライベートDNSを使用するために必要な前提条件を確認します。

  • DBシステム・プロビジョニングを起動する前に、プライベート・ビューおよびプライベート・ゾーンを作成する必要があります。詳細は、プライベートDNSリゾルバを参照してください
  • 別のDNSサーバーへの転送は、事前にDNSコンソールで設定する必要があります。これを行うには、VCNのリゾルバに移動し、エンドポイントを作成してからルールを作成します。詳細は、Virtual Cloud NetworkのDNSを参照してください。
  • プライベートゾーンの名前は4つを超えるラベルを持つことはできません。たとえば、a.b.c.dは許可されますが、a.b.c.d.eは許可されません。
  • VCNのリゾルバにプライベート・ビューを追加する必要もあります。詳細は、「リゾルバへのプライベート・ビューの追加」を参照してください。
  • プライベートDNS機能を使用してExadata VMクラスタをプロビジョニングする場合、ExadataはExadata VMクラスタのコンパートメントにリバースDNSゾーンを作成する必要があります。コンパートメントにタグまたはタグのデフォルトが定義されている場合は、タグの管理に関連する追加のポリシーが必要です。詳細は、次を参照してください:

オブジェクト・ストレージへのノード・アクセス: 静的ルート

データベースをバックアップし、Oracle Exadata Database Service on Exascale Infrastructureインスタンスでクラウド・ツールにパッチを適用および更新できるように、OracleではAutonomous Recovery Serviceを構成することをお薦めします。そのアクセスによってVCNを構成する方法(たとえば、サービス・ゲートウェイを使用して)にかかわらず、オブジェクト・ストレージを使用する場合は、クラスタ内の各コンピュート・ノードでオブジェクト・ストレージへの静的ルートを構成する必要もあります。これは、自動バックアップを使用しない場合にのみ必要です。バックアップAPIを使用してカスタマイズされたバックアップを使用する場合は、オブジェクト・ストレージ宛のトラフィックをバックアップ・インタフェース(BONDETH1)を介してルーティングする必要があります。コンソール、APIまたはCLIで作成された自動バックアップを使用する場合は、これは必要ありません。
ノート

2025年8月6日以降、FRA、PHXまたはNRTリージョンで作成されたテナンシの場合、データベースで自動バックアップを有効にすると、Autonomous Recovery Serviceが唯一のバックアップ先になります。

警告:

コンソール、APIまたはCLIを使用して自動バックアップを作成していない場合は、Exascaleインフラストラクチャ・インスタンス上のOracle Exadata Database Serviceの各コンピュート・ノードでオブジェクト・ストレージ・アクセスの静的ルートを構成する必要があります。そうしないと、システムでのデータベースのバックアップ、およびツールのパッチ適用または更新の試行が失敗する可能性があります。
ノート

データベースの最初の自動バックアップを有効にすると、サービスで静的ルート構成が自動的に実行されます。

データベースを作成する前にサービスにパッチを適用する場合は、GIまたはDBホームにパッチを適用できるように、手動の静的ルートが必要です。

他のサービス(IAM、KMS)にクライアント・サブネットを介してアクセスできず、バックアップ・サブネットのみが設定を使用してリージョン内のすべてのサービスにアクセスする場合、他のサービス(IAM、KMS)にアクセスするために静的ルートが必要になることもあります。

オブジェクト・ストレージIP割当て
オブジェクト・ストレージ・アクセス用の静的ルートを構成するには

VCNのサービス・ゲートウェイ

VCNはバックアップ用のオブジェクト・ストレージとOS更新用のOracle YUMリポジトリの両方へのアクセスを必要とします。

オプション1: OCIサービスへのサービス・ゲートウェイ・アクセス
オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイ・アクセス

Oracle Exadata Database Service on Exascale Infrastructureのセキュリティ・ルール

この項では、Exascaleインフラストラクチャ上のOracle Exadata Database Serviceで使用するセキュリティ・ルールをリストします。

セキュリティ・ルールは、仮想マシンのクライアント・ネットワークおよびバックアップ・ネットワークで許可されるトラフィック・タイプを制御します。ルールは3つのセクションに分かれています。

これらのルールを実装するには、様々な方法があります。詳細は、セキュリティ・ルールの実装方法を参照してください。
ノート

X8MおよびX9Mシステムの場合、クライアント・サブネット上のすべてのポートをイングレスおよびエグレス・トラフィック用に開くことをお薦めします。これは、システムにデータベース・サーバーを追加するための要件です。

クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール

VCNのホストに不可欠な接続性を有効にする、いくつかの一般ルールがあります。

セキュリティ・リストを使用してセキュリティ・ルールを実装する場合、デフォルトで次のルールがデフォルトのセキュリティ・リストに含まれることに注意してください。特定のセキュリティ・ニーズを満たすようにリストを更新または置換してください。Oracle Cloud Infrastructure環境内でネットワーク・トラフィックが適切に機能するには、2つのICMPルール(一般イングレス・ルール2および3)が必要です。VCN内のリソースと通信する必要があるホスト間のトラフィックのみが許可されるように、一般イングレス・ルール1 (SSHルール)と一般エグレス・ルール1を調整します。

特にクライアント・ネットワークに必要なルール

クライアント・ネットワークには、次のセキュリティ・ルールが重要です。

ノート

  • クライアント・イングレス・ルール1および2は、クライアント・サブネット内から開始された接続のみをカバーします。VCNの外部に存在するクライアントがある場合、かわりにソースCIDRがクライアントのパブリックIPアドレスに設定された2つの同様のルールを追加設定することをお薦めします。
  • クライアント・イングレス・ルール3および4とクライアント・エグレス・ルール1および2では、クライアント・ネットワーク内のTCPおよびICMPトラフィックを許可し、ノードが相互に通信できるようにします。ノード間でTCP接続に失敗した場合、ExadataクラウドVMクラスタまたはDBシステム・リソースはプロビジョニングに失敗します。

クライアント・イングレス・ルール3: クライアント・サブネット内からのトラフィックへのパッチ適用を許可する

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: クライアント・サブネットのCIDR
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 7085
  • 説明:オプションで、ルールのわかりやすい説明を追加します。例: 「サブネット内のExadataフリート更新プライベート・エンドポイントへのアクセスを許可します。」

Oracle DatabaseおよびOracle Grid Infrastructureのパッチ適用に必要なIAMポリシー

データベースおよびOracle Grid Infrastructureを管理するユーザーまたはグループに、サブネット、仮想ネットワーク・インタフェース・カード(vNICs)およびプライベートIPアドレス(プライベートIP)にアクセスするためのIdentity and Management (IAM)ポリシーを付与します。たとえば、グループadmin-groupがコンパートメントABCを管理するとします。その場合は、次のポリシーを設定します。

  • グループadmin-groupにコンパートメントABCのサブネットの使用を許可します
  • グループadmin-groupがコンパートメントABCでvNICsを使用することを許可します
  • グループadmin-groupにコンパートメントABCのprivate-ipsの使用を許可します

特にバックアップ・ネットワークに必要なルール

次のセキュリティ・ルールは、DBシステムがサービス・ゲートウェイを介してオブジェクト・ストレージと(また、クライアント・ネットワークにアクセス権がない場合にはオプションでOracle YUMリポジトリと)通信できるようにするため、バックアップ・ネットワークにとって重要です。このトピック(およびデフォルトのセキュリティ・リスト)の一般エグレス・ルールと重複しています。これはオプションですが、一般エグレス・ルール(またはデフォルトのセキュリティ・リスト)が誤って変更された場合に備えて推奨されます。

クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール

このトピックでは、VCNのホストに不可欠な接続性を有効にする、いくつかの一般ルールを示します。

セキュリティ・リストを使用してセキュリティ・ルールを実装する場合、デフォルトで次のルールがデフォルトのセキュリティ・リストに含まれることに注意してください。特定のセキュリティ・ニーズを満たすようにリストを更新または置換してください。Oracle Cloud Infrastructure環境内でネットワーク・トラフィックが適切に機能するには、2つのICMPルール(一般イングレス・ルール2および3)が必要です。VCN内のリソースと通信する必要があるホスト間のトラフィックのみが許可されるように、一般イングレス・ルール1 (SSHルール)と一般エグレス・ルール1を調整します。

一般イングレス・ルール1: 任意の場所からのSSHトラフィックを許可する
一般イングレス・ルール2: Path MTU Discovery断片化メッセージを許可する
一般イングレス・ルール3: VCN内の接続エラー・メッセージを許可する

このルールにより、VCN内のホストが接続エラー・メッセージを相互に受信できるようになります。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: IPv4: VCNのIPv4 CIDR、IPv6: VCNのIPv6 CIDR
  • IPプロトコル: ICMP
  • タイプ: すべて
  • コード: すべてのコード
一般エグレス・ルール1: すべてのエグレス・トラフィックを許可する
特にクライアント・ネットワークに必要なルール

クライアント・ネットワークには、次のセキュリティ・ルールが重要です。

ノート

  • X8Mシステムの場合、クライアント・サブネット上のすべてのポートをイングレスおよびエグレス・トラフィック用に開くことをお薦めします。これは、システムにデータベース・サーバーを追加するための要件です。
  • クライアント・イングレス・ルール1および2は、クライアント・サブネット内から開始された接続のみをカバーします。VCNの外部に存在するクライアントがある場合、かわりにソースCIDRがクライアントのパブリックIPアドレスに設定された2つの同様のルールを追加設定することをお薦めします。
  • クライアント・イングレス・ルール3および4とクライアント・エグレス・ルール1および2では、クライアント・ネットワーク内のTCPおよびICMPトラフィックを許可し、ノードが相互に通信できるようにします。ノード間でTCP接続に失敗した場合、ExadataクラウドVMクラスタまたはDBシステム・リソースはプロビジョニングに失敗します。
クライアント・イングレス・ルール1: クライアント・サブネット内からのONSおよびFANトラフィックを許可する

最初のルールが推奨され、Oracle Notification Services (ONS)で高速アプリケーション通知(FAN)イベントについて通信できるようになります。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: IPv4: クライアント・サブネットのIPv4 CIDR、IPv6: クライアント・サブネットのIPv6 CIDR
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 6200
  • 説明: ルールの説明(オプション)。
クライアント・イングレス・ルール2: クライアント・サブネット内からのSQL*NETトラフィックを許可する

これは、SQL*NETトラフィックに関するルールであり、次の場合に必要です:

  • データベースへのクライアント接続を有効にする必要がある場合
  • Oracle Data Guardを使用する予定の場合
  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: IPv4: クライアント・サブネットのIPv4 CIDR、IPv6: クライアント・サブネットのIPv6 CIDR
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 1521
  • 説明: ルールの説明(オプション)。
クライアント・エグレス・ルール1: クライアント・サブネット内のすべてのTCPトラフィックを許可する

これは、前述のSQL*NETトラフィックに関するルールです。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 接続先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0 (IPv4)、::/0 (IPv6)
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲:22
  • 説明: ルールの説明(オプション)。
クライアント・エグレス・ルール2: すべてのエグレス・トラフィックを許可する(Oracle YUMリポジトリへの接続の許可)

クライアント・エグレス・ルール3は、Oracle YUMリポジトリへの接続を許可するため重要です。

これは、一般エグレス・ルール1: すべてのエグレス・トラフィックを許可する(およびデフォルト・セキュリティ・リスト内)と重複しています。これはオプションですが、一般エグレス・ルール(またはデフォルトのセキュリティ・リスト)が誤って変更された場合に備えて推奨されます。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 接続先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0 (IPv4)、::/0 (IPv6)
  • IPプロトコル:すべて
  • 説明: ルールの説明(オプション)。
特にバックアップ・ネットワークに必要なルール

次のセキュリティ・ルールは、DBシステムがサービス・ゲートウェイを介してオブジェクト・ストレージと(また、クライアント・ネットワークにアクセス権がない場合にはオプションでOracle YUMリポジトリと)通信できるようにするため、バックアップ・ネットワークにとって重要です。

これは、一般エグレス・ルール1: すべてのエグレス・トラフィックを許可すると重複しています。これはオプションですが、一般エグレス・ルール(またはデフォルトのセキュリティ・リスト)が誤って変更された場合に備えて推奨されます。

イベント・サービスに必要なルール

コンピュート・インスタンス・メトリックをイベント・サービスに送信できるようにするには、コンピュート・インスタンスにパブリックIPアドレスまたはサービス・ゲートウェイが必要です。

コンピュート・インスタンスがコンピュート・インスタンス・メトリックをイベント・サービスに送信できるようにするには、デフォルトのエグレス・ルールで十分です。

インスタンスにパブリックIPアドレスがない場合は、仮想クラウド・ネットワーク(VCN)上にサービス・ゲートウェイを設定します。サービス・ゲートウェイにより、インスタンスは、トラフィックがインターネットを経由することなく、コンピュート・インスタンス・メトリックをイベント・サービスに送信できます。イベント・サービスにアクセスするためのサービス・ゲートウェイの設定に関する特別な注意事項を次に示します:

  • サービス・ゲートウェイを作成する場合は、「Oracle Services Networkのすべての<region>サービス」というサービス・ラベルを有効にします。これには、イベント・サービスが含まれます。
  • インスタンスが含まれるサブネットのルーティングを設定するときに、「ターゲット・タイプ」「サービス・ゲートウェイ」に、「宛先サービス」「Oracle Services Networkのすべての<region>サービス」に設定して、ルート・ルールを設定します。

    詳細な手順は、Oracle Servicesへのアクセス: サービス・ゲートウェイを参照してください。

モニタリング・サービスに必要なルール

コンピュート・インスタンス・メトリックをモニタリング・サービスに送信できるようにするには、コンピュート・インスタンスにパブリックIPアドレスまたはサービス・ゲートウェイが必要です。

コンピュート・インスタンスがコンピュート・インスタンス・メトリックをモニタリング・サービスに送信できるようにするには、デフォルトのエグレス・ルールで十分です。

インスタンスにパブリックIPアドレスがない場合は、仮想クラウド・ネットワーク(VCN)上にサービス・ゲートウェイを設定します。サービス・ゲートウェイにより、インスタンスは、トラフィックがインターネットを経由することなく、コンピュート・インスタンス・メトリックをモニタリング・サービスに送信できます。モニタリング・サービスにアクセスするためのサービス・ゲートウェイの設定に関する特別な注意事項を次に示します:

  • サービス・ゲートウェイを作成する場合は、「Oracle Services Networkのすべての<region>サービス」というサービス・ラベルを有効にします。これには、モニタリング・サービスが含まれています。
  • インスタンスが含まれるサブネットのルーティングを設定するときに、「ターゲット・タイプ」「サービス・ゲートウェイ」に、「宛先サービス」「Oracle Services Networkのすべての<region>サービス」に設定して、ルート・ルールを設定します。

    詳細な手順は、Oracle Servicesへのアクセス: サービス・ゲートウェイを参照してください。

セキュリティ・ルールの実装方法

ネットワーク・サービスを使用してVCN内にセキュリティ・ルールを実装する方法について学習します。

ネットワーキング・サービスでは、2つの方法でVCN内にセキュリティ・ルールを実装できます:

2つの方法の比較については、セキュリティ・リストとネットワーク・セキュリティ・グループの比較を参照してください。

ネットワーク・セキュリティ・グループを使用する場合
セキュリティ・リストを使用する場合

Oracle Database Autonomous Recovery Serviceのネットワーク要件

Oracle Database Autonomous Recovery Serviceには、データベース仮想クラウド・ネットワーク(VCN)内のバックアップおよびリカバリ操作専用の登録済リカバリ・サービス・サブネットが必要です。

バックアップにリカバリ・サービスを使用するには、リカバリ・サービスの構成で説明されているステップに従います。

オブジェクト・ストレージへのサービス・ゲートウェイの作成

OCIコンソールで、オブジェクト・ストレージへのサービス・ゲートウェイを作成します。サービス・ゲートウェイは、自動化の更新および構成メタデータに必要です。

ノート

2025年8月6日以降、FRA、PHXまたはNRTリージョンで作成されたテナンシの場合、データベースで自動バックアップを有効にすると、Autonomous Recovery Serviceが唯一のバックアップ先になります。
  1. ナビゲーション・メニューを開きます。「ネットワーキング」をクリックし、「Virtual Cloud Networks」をクリックします。
  2. バックアップするデータベース・サービスが配置されているVCNを選択します。
  3. 表示された「Virtual Cloud Network Details」ページの「Resources」で、「Service Gateways」をクリックします。
  4. 「サービス・ゲートウェイの作成」をクリックし、次の詳細を指定します。
    1. 名前: サービス・ゲートウェイの記述名。これは一意である必要があります。機密情報を入力しないでください。
    2. コンパートメント: サービス・ゲートウェイを作成するコンパートメント(現在作業しているコンパートメントと異なる場合)。
    3. サービス: ドロップダウン・リストから、サービスCIDRラベルAll <region> Services in Oracle Services Networkを選択します。
    4. タグ: (拡張オプション)リソースを作成する権限がある場合、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済タグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
  5. 「サービス・ゲートウェイの作成」をクリックします。

    ゲートウェイが作成されるまで待ってから、次のステップに進みます。

  6. 「リソース」で、「ルート表」をクリックします。

    ルート表関連付け:特定のVCNルート表をこのゲートウェイに関連付けることができます。ルート表を関連付けた場合、ゲートウェイにはその後、常に関連付けられたルート表が必要です。現在のルート表のルールを変更することも、別のルート表に置換することもできます。

  7. リカバリ・サービスのサブネットで使用されているルート表名をクリックします。
  8. 表示される「ルート表の詳細」ページで、「ルート・ルール」セクションの「ルート・ルールの追加」をクリックします。

    特定のサービスCIDRラベルにサービス・ゲートウェイを構成する場合は、そのラベルを宛先とし、サービス・ゲートウェイをターゲットとして指定したルート・ルールを作成する必要もあります。ゲートウェイにアクセスする必要があるサブネットごとに、この操作を行います。

  9. 表示された「ルート・ルールの追加」ダイアログで、次の詳細を入力します:
    1. ターゲット・タイプ: サービス・ゲートウェイ
    2. 宛先サービス: ゲートウェイに対して有効になっているサービスCIDRラベル。All <region> Services in Oracle Services Network
    3. ターゲット・サービス・ゲートウェイ: ステップ4で指定した名前を選択します。
    4. 説明: ルールの説明(オプション)。
  10. 「ルート・ルールの追加」をクリックします。

ExaDB-DとExaDB-XS間のクロスサービス相互運用性: Data Guard、バックアップおよびリストア

データベース・サービス全体でクロスサービスOracle Data Guardグループを作成できるようになりました。

この機能を使用すると、次の構成のクロスサービス・バックアップおよびリストア機能を確立できます。  

  • ExaDB-XSまたはExaDB-Dに1つ以上のスタンバイ・データベースがあるExaDB-D上のプライマリ・データベース。
  • ExaDB-DまたはExaDB-XSに1つ以上のスタンバイ・データベースがあるExaDB-XS上のプライマリ・データベース。
ノート

このリリースの時点では、Exadata Database Service on Dedicated InfrastructureとExadata Database Service on Exascale Infrastructure間のクロスサービスOracle Data Guardは、Oracle Database 23aiリリースでのみ構成できます。

この機能により、テナンシ全体でデータベース・サービスの可能性を活用できます。

ノート

最大可用性を確保するために、Oracleでは、ピアVMクラスタをプライマリVMクラスタとは異なるExadataインフラストラクチャに配置することをお薦めします。

スタンバイ・データベース構成オプション

スタンバイ・データベースを追加する場合、次の詳細を指定できます。

  • ピアVMクラスタの詳細:ターゲットがExaDB-Dの場合は、Exadataインフラストラクチャを選択できます。
  • ターゲット・サービスの選択: ExaDB-DまたはExaDB-XSのいずれかを選択します。デフォルトでは、Data Guardグループを開始するサービスが選択されています。選択したリージョンでサービスを使用できない場合は、「このリージョンではサービスを使用できません」というメッセージが表示されて無効になります。
  • Data Guardタイプ:グループはData GuardまたはActive Data Guardで構成でき、各スタンバイ・データベースには異なるタイプを設定できます。
  • Data Guardグループの制限:プライマリ・データベースは1つのData Guardグループに制限されます。
  • スタンバイ・データベースの作成:一度に追加できるスタンバイ・データベースは1つのみです。ただし、スタンバイ・データベースは、次のカテゴリのいずれでも番号に制限なく作成できます。
    • 同じサービス内
    • サービス全体
    • 同じ可用性ドメイン(AD)内
    • 同じリージョン内の複数のアベイラビリティ・ドメイン
    • 地域を超えて

クロスサービスのプライマリ・データベースとスタンバイ・データベースの主な考慮事項

  • プライマリ・データベースとスタンバイ・データベースの両方が同じキー管理ソリューションを使用する必要があります。
  • Data Guardは、次のルールに従って、同期または非同期トランスポート・タイプで最大パフォーマンスまたは最大可用性保護モードで構成できます。
    • 最初のスタンバイ・データベースの場合:
      • 非同期転送では、デフォルトで「最大パフォーマンス」モードになります。
      • 保護モードと転送タイプは変更できません。
    • 2番目以降のスタンバイ・データベースの場合:
      • 最初のスタンバイから保護モードを継承します。
      • デフォルトは非同期トランスポートです。
      • 保護モードと転送タイプは変更できません。

Data Guard構成の表示および編集

  • プライマリ・データベース・ページかスタンバイ・データベース・ページかに関係なく、Data Guardグループの一部であるすべてのデータベースをData Guardグループ表に表示します。
  • Data Guard構成を編集して更新します:
    • Data Guardタイプ:スタンバイ・データベースごとに異なる場合があります。これは、スタンバイ・データベースからのみ変更できます。
    • データベース管理者パスワード:任意のデータベースから編集できます。
    • 保護モード:プライマリ・データベースまたは任意のスタンバイ・データベースから、「最大パフォーマンス」と「最大可用性」を切り替えることができます。
    • トランスポート・タイプ:非同期と同期を切り替えることができるのは、スタンバイ・データベースからのみです。
ノート

保護モードが「最大可用性」に設定されている場合、少なくとも1つのスタンバイ・データベースで同期トランスポートが使用されていることが検証されます。見つからない場合は、次のエラーメッセージが表示されます。

データ損失ゼロを実現するには、少なくとも1つのスタンバイと同期トランスポートが必要です。同期トランスポートを使用するスタンバイをプライマリ・データベースと同じサービスに配置することをお薦めします。」

データベースのスイッチオーバーおよびフェイルオーバー

  • スイッチオーバー(任意のスタンバイ・データベース)
    • スイッチオーバーは、メジャー・バージョンまたはリリース更新(RU)チェックを適用せずに実行されます。ただし、スタンバイ・データベースにノード数、メモリーまたはサービス・タイプの異なる非対称構成がある場合、警告が表示されます。
  • フェイルオーバー(任意のスタンバイ・データベース)
    • フェイルオーバーは、メジャー・バージョンまたはリリース更新(RU)チェックを適用せずに実行されます。ただし、スタンバイ・データベースにノード数、メモリーまたはサービス・タイプの異なる非対称構成がある場合、警告が表示されます。

データベースのバックアップおよびリストア・オプション

ノート

2025年8月6日以降、FRA、PHXまたはNRTリージョンで作成されたテナンシの場合、データベースで自動バックアップを有効にすると、Autonomous Recovery Serviceが唯一のバックアップ先になります。

  • スケジュールされたバックアップと自動バックアップ
    • 自動バックアップは、プライマリ・データベース、スタンバイ・データベースまたはその両方でスケジュールできます。
    • Object StorageバックアップとRecovery Serviceバックアップの両方がサポートされています。
    • プライマリ・データベースとスタンバイ・データベースの両方にバックアップが構成されている場合は、同じバックアップ保存先タイプを使用する必要があります。
  • ExaDB-XS内の同じデータベースのインプレース・リストア
    ExaDB-XSの同じデータベースから作成されたバックアップを使用して、データベースをリストアおよびリカバリします。
    • プライマリ・データベースで取得されたバックアップを使用してプライマリをリストアします。
    • スタンバイ・データベースで取得されたバックアップを使用してスタンバイをリストアします。
  • ExaDB-XS内のピア・データベースのインプレース・リストア
    リカバリ・サービスでソース・データベースからのバックアップを使用して、ピア・データベース(バックアップが構成されていない)をリストアおよびリカバリします。
    • シナリオ1:スタンバイ・バックアップを使用してプライマリをリストアします。
      • プライマリ・データベース: ExaDB-XS (バックアップが構成されていません)
      • スタンバイ・データベース: ExaDB-XS (リカバリ・サービスに構成されたバックアップ)
    • シナリオ2:プライマリ・バックアップを使用してスタンバイをリストアします。
      • プライマリ・データベース: ExaDB-XS (リカバリ・サービスに構成されたバックアップ)
      • スタンバイ・データベース: ExaDB-XS (バックアップは構成されていません)
  • サービス間でのピア・データベースのインプレース・リストア
    リカバリ・サービスで反対のサービス(ExaDB-DまたはExaDB-XS)のソース・データベースからのバックアップを使用して、ExaDB-XSまたはExaDB-Dでデータベースをリストアおよびリカバリします。
    • シナリオ1: ExaDB-Dからのバックアップを使用して、ExaDB-XSのピア・データベースをリストアします。
      • ユースケース1:スタンバイ・バックアップを使用してプライマリをリストアします。
      • ユースケース2:プライマリ・バックアップを使用してスタンバイをリストアします。
    • シナリオ2: ExaDB-XSからのバックアップを使用して、ExaDB-Dでピア・データベースをリストアします。
      • ユースケース1:スタンバイ・バックアップを使用してプライマリをリストアします。
      • ユースケース2:プライマリ・バックアップを使用してスタンバイをリストアします。

アウトオブプレース・リストア(新しいデータベースの作成)

  • ExaDB-XS内同じサービスからのバックアップを使用して、ExaDB-XSに新規データベースを作成できます。
    • リストア範囲:
      • 同じ可用性ドメイン(AD)
      • 同じリージョン内の別のAD
      • 別のリージョン
    • バックアップの保存先としてオブジェクト・ストレージまたはリカバリ・サービスをサポートします。
  • サービス全体
    • シナリオ1: ExaDB-XSからのバックアップを使用したExaDB-Dでの新規データベースの作成
      • ソース: ExaDB-XS (データベースおよびバックアップ)
      • ターゲット: ExaDB-D (任意のリージョンまたはAD)
      • バックアップ保存先:オブジェクト・ストレージまたはリカバリ・サービス
    • シナリオ2: ExaDB-Dからのバックアップを使用したExaDB-XSでの新規データベースの作成
      • ソース: ExaDB-D (データベースおよびバックアップ)
      • ターゲット: ExaDB-XS (任意のリージョンまたはAD)
      • バックアップ保存先:オブジェクト・ストレージまたはリカバリ・サービス