Exadata Cloud Infrastructureインスタンスのネットワーク設定

このトピックでは、VCNの推奨構成と、Exadata Cloud Infrastructureインスタンスに関連するいくつかの要件について説明します。

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

VCNおよびサブネット

Exadata Cloud Infrastructureインスタンスを起動するには、仮想クラウド・ネットワークと少なくとも2つのサブネットが必要です:

Exadata Cloud Infrastructureインスタンスを起動するには、仮想クラウド・ネットワークと少なくとも2つのサブネットがあり、使用するDNSリゾルバのタイプを選択する必要があります:

  • Exadata Cloud Infrastructureインスタンスを配置するリージョン内のVCN
  • VCNに少なくとも2つのサブネット。2つのサブネットは次のとおりです:

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

ノート

新規Exadata Cloud Infrastructureリソース・モデルを使用するExadata Cloud Infrastructureインスタンスの場合、ネットワーキングはクラウドVMクラスタ・リソースで構成されます。

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

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

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

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

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

network_exa_public_client.pngの説明が続きます

次を設定します:

ノート

重要 パブリック・サブネットに関連付けられているルート表上のターゲットとしてサービス・ゲートウェイを使用するルート・ルールの構成の詳細は、この既知の問題を参照してください。

オプション2: プライベート・サブネット

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

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

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アドレス空間の要件

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

Exadata Cloud Infrastructure VMクラスタ(つまりVCN)を複数のリージョンで設定する場合は、VCNのIPアドレス領域が重複していないことを確認してください。これは、Oracle Data Guardでディザスタ・リカバリを設定する場合に重要です。

Exadata X8以下の場合、Exadata Cloud Infrastructure VMクラスタ用に作成する2つのサブネットは、192.168.128.0/20と重複しないようにする必要があります。

Exadata X8MおよびX9Mでは、インターコネクトにIPアドレス(100.106.0.0/16および100.107.0.0/16)が使用されます。

次の表に、各VMクラスタ・サイズのExadata VMインフラストラクチャに応じて必要な最小サブネット・サイズを示します。クライアント・サブネットでは、各ノードが4つのIPアドレスを必要とし、さらに、3つのアドレスが単一クライアント・アクセス名(SCAN)用に予約されています。バックアップ・サブネットでは、各ノードに3つのアドレスが必要です。

ラック・サイズ クライアント・サブネット: 必要なIPアドレス数 クライアント・サブネット: 最小サイズ ノート バックアップ・サブネット: 必要なIPアドレス数 バックアップ・サブネット: 最小サイズ ノート
VMクラスタ当たりのベース・システムまたはクォータ・ラック (4アドレス * 2ノード) + 3 (SCAN用) = 11 /28 (16 IPアドレス) 3アドレス * 2ノード = 6 /28 (16 IPアドレス)
VMクラスタ当たりのハーフ・ラック (4 * 4ノード) + 3 = 19 /27 (32 IPアドレス) 3 * 4ノード = 12 /28 (16 IPアドレス)
VMクラスタ当たりのフル・ラック (4* 8ノード) + 3 = 35 /26 (64 IPアドレス) 3 * 8ノード = 24 /27 (32 IPアドレス)
VMクラスタごとの柔軟なインフラストラクチャ・システム(X8M以上) データベース・ノード当たり4アドレス(最小2ノード) + 3 (SCAN用) データベース・ノードに必要なIPアドレスの合計数によって決まる最小サイズ。 データベース・ノード当たり3アドレス(最小2ノード) データベース・ノードに必要なIPアドレスの合計数によって決まる最小サイズ。
ノート

ネットワーキング・サービスでは、各サブネットに3つのIPアドレスを予約しています。サブネットに必要な最小容量より大きい容量を割り当てると(例: /28のかわりに最低/25)、これらの予約済アドレスがサブネットの使用可能領域に与える相対的な影響を軽減できます。

オブジェクト・ストアにアクセスするための静的ルートの構成

Exadata Cloud Infrastructureインスタンス内のすべてのトラフィックは、デフォルトではデータ・ネットワークを介してルーティングされます。バックアップ・トラフィックをバックアップ・インタフェース(BONDETH1)にルーティングするには、クラスタ内のコンピュート・ノードで静的ルートを構成する必要があります。

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

Exadata Cloud Infrastructureインスタンス用のDNSの設定

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

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

DNS: VCN、サブネットおよびExadata Cloud Infrastructureインスタンスの短縮名

ノードが通信するには、VCNでInternet and VCN Resolverを使用する必要があります。インターネットおよびVCNリゾルバでは、ノードへのホスト名の割当て、およびVCN内のリソース別のDNS解決が可能です。

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

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

  • VCNドメイン・ラベル
  • サブネット・ドメイン・ラベル
  • Exadata Cloud InfrastructureインスタンスのクラウドVMクラスタまたはDBシステム・リソースのホスト名接頭辞

これらの値は、ノードの完全修飾ドメイン名(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の間

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

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

プライベートDNSの構成

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

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

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

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

注意:

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

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

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

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

オブジェクト・ストレージIP割当て

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

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

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

前述のオプション1: インターネット・ゲートウェイを使用したパブリック・クライアント・サブネットとオプション2: プライベート・サブネットのどちらを使用するかによって、サービス・ゲートウェイの使用方法は異なります。次の2つの項を参照してください。

オプション1: OCIサービスへのサービス・ゲートウェイ・アクセス

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

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

この項では、Exadata Cloud Infrastructureで使用するセキュリティ・ルールをリストします。

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

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

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

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

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

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

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

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

ノート

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0
  • 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コンソールで、Object Storageへのサービス・ゲートウェイを作成します。自動更新および構成メタデータにはサービス・ゲートウェイが必要です。

  1. ナビゲーション・メニューを開きます。「ネットワーキング」をクリックし、「Virtual Cloud Networks」をクリックします。
  2. バックアップするデータベース・サービスが配置されているVCNを選択します。
  3. 表示された「Virtual Cloudネットワークの詳細」ページの「リソース」で、「サービス・ゲートウェイ」をクリックします。
  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. 「ルート・ルールの追加」をクリックします。