機械翻訳について

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

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

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

親トピック: Exadata Cloud Infrastructureの準備

VCNおよびサブネット

Exadata Cloud Infrastructureインスタンスを起動するには、Virtual Cloudネットワークおよび少なくとも2つのサブネットが必要です:

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

  • Exadata Cloud Infrastructureインスタンスが必要なリージョンのVCN
  • VCN内に少なくとも2つのサブネット。 2つのサブネットは次のとおりです:
    • クライアントのサブネット
    • バックアップ・サブネット
  • 使用するDNS名の解決メソッドを選択します。 「VCNのDNSの選択肢」を参照してください

ノート:

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

クライアント・サブネットは、IPv4またはIPv4/IPv6デュアル・スタック・ネットワークで構成できます。

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

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

関連トピック

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

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

このオプションは、概念の証明または開発作業を行う場合に便利です。

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

network_exa_public_client.pngの説明は以下のとおりです
「図network_exa_public_client.pngの説明」

次を設定できます:

ノート:

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

親トピック: VCNとサブネット

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

Oracleでは、本番システム用にプライベート・サブネットを推奨しています。

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

network_exa_private_client.pngの説明は以下のとおりです
「図network_exa_private_client.pngの説明」

次を設定できます:

親トピック: VCNとサブネット

IPアドレス空間の要件

特に、「Exadataクラウド・インフラストラクチャ」 VMクラスタ(およびVCN)が複数のリージョンにある場合、IPアドレスは重複できません。

複数のリージョンで「Exadataクラウド・インフラストラクチャ」 VMクラスタ(つまり、VCN)を設定する場合は、VCNのIPアドレス領域が重複しないようにします。 これは、Oracle Data Guardを使用して障害リカバリを設定する場合に重要です。

Exadata X8以下の場合、「Exadataクラウド・インフラストラクチャ」 VMクラスタ用に作成する2つのサブネットは、192.168.128.0/20と重複できません。

Exadata X8M、X9MおよびX11Mの場合、IPアドレス100.64.0.0/10はインターコネクト用に予約されているため、クライアントまたはバックアップVCNsおよびデータベース・クライアントには使用しないでください。

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

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

ノート:

ネットワーキング・サービスでは、各サブネットに3つのIPアドレスを予約しています。 サブネットに必要な最小領域(たとえば、 /28ではなく少なくとも/25)を割り当てると、サブネットの使用可能な領域に対する予約済アドレスの相対的な影響を減らすことができます。

親トピック: VCNとサブネット

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

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

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

親トピック: VCNとサブネット

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

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

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

親トピック: VCNとサブネット

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

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

インターネットおよびVCNリゾルバは、データベースのSCANsのラウンド・ロビン解決を可能にします。 また、データベースのバックアップ、パッチ適用およびExadata Cloud Infrastructureインスタンスでのクラウド・ツールの更新に必要な重要なサービス・エンドポイントを解決できます。 インターネットおよびVCNリゾルバは、VCNのDNSに対するVCNのデフォルト選択です。 詳細は、「Virtual CloudネットワークのDNS」および「DHCPオプション」を参照してください。

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

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

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

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

たとえば:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

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

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

ホスト名プレフィクスの要件:

  • 推奨最大: 12 characters. 詳細は、次のセクションの「例」「VCNおよびサブネット・ドメイン・ラベルの要件」を参照してください。
  • 文字列「ローカル・ホスト」にはできません

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

  • 推奨最大: それぞれ14文字。 基礎となる実際の要件は、合計28文字「両方のドメイン・ラベルで」です(ラベル間の期間を除く)。 たとえば、これら両方が許容可能です: subnetad1.verylongvcnphxまたはverylongsubnetad1.vcnphx。 わかりやすくするために、それぞれ14文字にすることをお薦めします。
  • ハイフンまたはアンダースコアは使用できません。

  • 推奨: VCNドメイン・ラベルにリージョン名を含め、サブネット・ドメイン・ラベルに可用性ドメイン名を含めます。

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

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

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

親トピック: VCNとサブネット

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

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

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

親トピック: VCNとサブネット

プライベートDNSの構成

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

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

親トピック: VCNとサブネット

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

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

注意:

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

ノート:

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

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

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

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

Object Storage IP割当て

Oracle Cloud Infrastructure Object Storageは、すべてのリージョンにCIDRブロックIP範囲134.70.0.0/16を使用します。

2018年6月1日時点で、Object Storageでは次の廃止されたIP範囲はサポートされなくなりました。 Oracleでは、新しいIP範囲を採用した後、アクセス制御リスト、ファイアウォール・ルールおよびその他のルールからこれらの古いIPアドレスを削除することをお薦めします。

「中止」 IP範囲は次のとおりです:

  • ドイツ中部(フランクフルト): 130.61.0.0/16
  • 英国南部(ロンドン): 132.145.0.0/16
  • 米国東部(アッシュバーン): 129.213.0.0/16
  • 米国西部(フェニックス): 129.146.0.0/16

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

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

  1. Exadata Cloud Infrastructureインスタンスのコンピュート・ノードにSSH接続します。 

    ssh -i <private_key_path> opc@<node_ip_address>

  2. opcとしてログインし、rootユーザーにsudoを実行します。 ルート・ユーザー・プロファイルを起動するには、ハイフン付きのsudo su -を使用します。 

    
login as: opc
			
[opc@dbsys ~]$ sudo su -

  3. BONDETH1インタフェース用に構成されたゲートウェイを特定します。 

    [root@dbsys ~]# grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-bondeth1 |awk -F"=" '{print $2}'


10.0.4.1

  4. BONDETH1の次の静的ルールを/etc/sysconfig/network-scripts/route-bondeth1ファイルに追加します: 

    10.0.X.0/XX dev bondeth1 table 211
default via <gateway> dev bondeth1 table 211
134.70.0.0/17 via <gateway_from_previous_step> dev bondeth1

  5. インタフェースを再起動します。 

    
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;

    前述のステップのファイル変更は、ifdownおよびifupコマンドの実行直後に有効になります。

  6. Exadata Cloud Infrastructureインスタンスのeachコンピュート・ノードで前述のステップを繰り返します。

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

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

VCNが、バックアップ用のOracle Services Networ k(特にObject Storage)、OS更新用のOracle YUMリポジトリ、IAM (Identity and Access Management)およびOCI Vault (KMS統合)にアクセスできることを確認します。

ノート:

VCNにOracle Services Networkへの接続がない場合、新しいVMクラスタのプロビジョニングが失敗し、既存のVMクラスタの管理性も影響を受ける可能性があります。

「Option1: インターネット・ゲートウェイを使用したパブリック・クライアント・サブネット」または「オプション2: プライベート・サブネット」のどちらを使用するかに応じて、サービス・ゲートウェイを様々な方法で使用します。 次の2つの項を参照してください。

関連トピック

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

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

サービス・ゲートウェイをオブジェクト・ストレージへのアクセスのみに使用するようにバックアップ・サブネットを構成します。

次に、オプション1のダイアグラムを示します:

この図は、パブリック・クライアント・サブネットを使用するネットワーク設定を示しています。

通常、次の作業が必要です:

  • VCNでサービス・ゲートウェイを設定するためのタスクを実行し、特にOCI <region> Object StorageというサービスCIDRラベルを有効にします。
  • ルーティングを更新するタスクで、バックアップ・サブネットのカスタム・ルート表にルート・ルールを追加します。 宛先サービスの場合は、OCI <region> Object Storageおよびtarget = the service gatewayを使用します。
  • サブネットのセキュリティ・ルールを更新するタスクで、バックアップ・ネットワークのネットワーク・セキュリティ・グループ(NSG)またはカスタム・セキュリティ・リストに対してタスクを実行します。 宛先サービスをOCI <region> Object Storageに設定して、セキュリティ・ルールを設定します。 「特にバックアップ・ネットワークに必要なルール」を参照してください。

関連トピック

親トピック: VCNのサービス・ゲートウェイ

オプション2: クライアント・サブネットとバックアップ・サブネットの両方に対するOCIサービスへのサービス・ゲートウェイ・アクセス

Oracle Services Networkへのアクセスにサービス・ゲートウェイを使用するようにクライアント・サブネットとバックアップ・サブネットの両方を構成します。これには、バックアップ用のオブジェクト・ストレージ、OS更新用のOracle YUMリポジトリ、IAM (Identity and Access Management)およびOCI Vault (KMS統合)が含まれます。

ノート:

サービス・ゲートウェイを介したOracle YUMサービスへのアクセスの詳細は、この「既知の問題」を参照してください。

次に、オプション2の図を示します:

このイメージは、プライベート・クライアント・サブネットを使用するネットワーク設定を示しています。

通常、次の作業が必要です:

  • VCNでサービス・ゲートウェイを設定するためのタスクを実行し、特にAll <region> Services in Oracle Services NetworkというサービスCIDRラベルを有効にします。
  • 各サブネットのルーティングを更新するタスクで、各サブネット・カスタム・ルート表にルールを追加します。 宛先サービスの場合は、All <region> Services in Oracle Services Networkおよびtarget = the service gatewayを使用します。
  • サブネットのセキュリティ・ルールを更新するタスクで、バックアップ・ネットワークのネットワーク・セキュリティ・グループ(NSG)またはカスタム・セキュリティ・リストに対してタスクを実行します。 宛先サービスをOCI <region> Object Storageに設定して、セキュリティ・ルールを設定します。 「Oracle Exadata Cloud Serviceのセキュリティ・ルール」 「Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール」を参照してください。 クライアント・サブネットには、YUMリポジトリへのアクセスを対象とする広範囲のエグレス・ルールがすでに存在します。

オプション2のサービス・ゲートウェイの使用の詳細は、次のとおりです:

  • クライアント・サブネットとバックアップ・サブネットの両方がサービス・ゲートウェイを使用しますが、異なるサービスにアクセスします。 サービス・ゲートウェイのOCI <region> Object Storage service CIDRラベルとAll <region> Services in Oracle Services Networkの両方を有効にすることはできません。 両方のサブネットのニーズに対応するには、サービス・ゲートウェイのAll <region> Services in Oracle Services Networkを有効にする必要があります。 VCNでは、1つのサービス・ゲートウェイのみを使用できます。
  • 特定のサービス・ゲートウェイをターゲットとするすべてのルート・ルールでは、ルールの宛先として、CIDRブロックではなく有効なサービスCIDRラベルを使用する必要があります。 つまり、オプション2では、両方のサブネットのルート表で、サービス・ゲートウェイ・ルールにAll <region> Services in Oracle Services Networkを使用する必要があります。
  • ルート・ルールとは異なり、セキュリティ・ルールでは、任意のサービスCIDRラベル(VCNにサービス・ゲートウェイがあるかどうかにかかわらず)またはCIDRブロックをルールのソースCIDRまたは宛先CIDRとして使用できます。 したがって、バックアップ・サブネットにはAll <region> Services in Oracle Services Networkを使用するルート・ルールがありますが、サブネットにはOCI <region> Object Storageを使用するセキュリティ・ルールを設定できます。 Exadata Cloud Serviceインスタンスのセキュリティ・ルールを参照してください。

関連トピック

親トピック: VCNのサービス・ゲートウェイ

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

この項では、「Exadataクラウド・インフラストラクチャ」で使用するセキュリティ・ルールを示します。

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

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

ノート:

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

ノート:

ゼロ・トラスト・パケット・ルーティングを使用してデータベース・サービスのネットワークを制御する予定で、同じVCN内にData Guardピアを構成する場合は、VCNおよびData Guard構成内のすべてのVMクラスタに同じZPRセキュリティ属性が必要です。 異なるVCNまたは異なるリージョンにあるData Guardピアは、ZPR構成のCIDRで指定する必要があります。

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

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

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

一般イングレス・ルール1: あらゆる場所からSSHトラフィックを許可

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IPプロトコル: SSH
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 22

一般イングレス・ルール2: Path MTU Discoveryフラグメンテーション・メッセージを許可

このルールによって、VCNのホストでパスMTU検出の断片化メッセージを受信できるようになります。 これらのメッセージにアクセスできない場合、VCN内のホストで、VCN外のホストとの通信に問題がある可能性があります。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IPプロトコル: ICMP
  • タイプ: 3
  • コード: 4

一般イングレス・ルール3: VCN内の接続エラー・メッセージを許可

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

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: IPv4: VCNのIPv4 CIDR、IPv6: VCNのIPv6 CIDR
  • IPプロトコル: ICMP
  • タイプ: ALL
  • コード: すべて

一般エグレス・ルール1: すべてのエグレス・トラフィックを許可

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IPプロトコル: すべて

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

クライアント・ネットワークに対して重要なセキュリティ・ルールは次のとおりです。

重要:

  • クライアント・イングレス・ルール1および2は、クライアント・サブネット内で開始された接続のみに対応します。 「VCNの外部」が存在するクライアントがある場合、Oracleでは、「ソースCIDR」がクライアントのパブリックIPアドレスに設定されている2つのadditional類似ルールを設定することをお薦めします。
  • クライアント・ネットワーク構成のクライアント・エグレス・ルール1および2では、TCPおよびICMPトラフィックが許可され、クライアント・ネットワーク内のセキュアなノード間通信が可能になります。 これらのルールは、ノード間の重要なTCP接続を容易にするため、重要です。 ノード間でTCP接続が失敗した場合、Exadata Cloud VMクラスタ・リソースのプロビジョニングは正常に完了しません。

クライアント・イングレス・ルール1: クライアント・サブネット内からのONSおよびFANトラフィックを許可

最初のルールが推奨され、Oracle Notification Services (ONS)でFast Application Notification (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: クライアント・サブネット内のSSH TCPトラフィックを許可

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 22
  • 説明: ルールの説明(オプション)。

クライアント・エグレス・ルール2: すべてのエグレス・トラフィックを許可(Oracle YUMリポジトリへの接続を許可)

クライアント・エグレス・ルール2は、Oracle YUMリポジトリへの接続を許可するため重要です。 このトピックの一般エグレス・ルール(および「デフォルト・セキュリティ・リスト」)では冗長です。 これはオプションですが、一般会計ルール(またはデフォルトのセキュリティ・リスト)が誤って変更された場合に備えてお薦めします。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IPプロトコル: すべて
  • 説明: ルールの説明(オプション)。

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

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

バックアップ・エグレス・ルール: オブジェクト・ストレージへのアクセスを許可

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: サービス

  • 宛先サービス:

    • OCI <region>オブジェクト・ストレージというサービスCIDRラベル
    • クライアント・ネットワークにOracle YUMリポジトリへのアクセス権がない場合は、Oracle Services Networkのすべての<region>サービスというサービスCIDRラベルを使用
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 443 (HTTPS)
  • 説明: ルールの説明(オプション)。

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

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

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

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

関連トピック

親トピック: Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール

一般イングレス・ルール1: あらゆる場所からSSHトラフィックを許可
  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IPプロトコル: SSH
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 22
一般イングレス・ルール2: Path MTU Discoveryフラグメンテーション・メッセージを許可

このルールによって、VCNのホストでパスMTU検出の断片化メッセージを受信できるようになります。 これらのメッセージにアクセスできない場合、VCN内のホストで、VCN外のホストとの通信に問題がある可能性があります。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: 0.0.0.0/0 (IPv4), ::/0 (IPv6)
  • IPプロトコル: ICMP
  • タイプ: 3
  • コード: 4
一般イングレス・ルール3: VCN内の接続エラー・メッセージを許可

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

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

お客様がデータ・プレーン・ゲストVMイベントの通知を有効にした場合、デフォルトのエグレス・ルールで十分です。

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

クライアント・ネットワークに対して重要なセキュリティ・ルールは次のとおりです。

ノート:

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

親トピック: Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール

クライアント・イングレス・ルール1: クライアント・サブネット内からのONSおよびFANトラフィックを許可

最初のルールが推奨され、Oracle Notification Services (ONS)でFast Application Notification (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プロトコル: すべて
  • 説明: ルールの説明(オプション)。

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

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

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

関連トピック

親トピック: Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール

バックアップ・エグレス・ルール: オブジェクト・ストレージへのアクセスを許可
  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: サービス

  • 宛先サービス:

    • OCI <region>オブジェクト・ストレージというサービスCIDRラベル
    • クライアント・ネットワークにOracle YUMリポジトリへのアクセス権がない場合は、Oracle Services Networkのすべての<region>サービスというサービスCIDRラベルを使用
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 443 (HTTPS)
  • 説明: ルールの説明(オプション)。

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

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

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

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

  • サービス・ゲートウェイの作成時に、「Oracle Services Networkのすべての<region>サービス」というサービス・ラベルを有効にします。 イベント・サービスが含まれます。

  • インスタンスを含むサブネットのルーティングを設定する場合は、「ターゲット・タイプ」を「サービス・ゲートウェイ」に設定し、「宛先サービス」を「Oracle Services Networkのすべての<region>サービス」に設定してルート・ルールを設定します。

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

親トピック: Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール

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

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

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

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

  • サービス・ゲートウェイの作成時に、「Oracle Services Networkのすべての<region>サービス」というサービス・ラベルを有効にします。 これにはモニタリング・サービスが含まれます。

  • インスタンスを含むサブネットのルーティングを設定する場合は、「ターゲット・タイプ」を「サービス・ゲートウェイ」に設定し、「宛先サービス」を「Oracle Services Networkのすべての<region>サービス」に設定してルート・ルールを設定します。

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

親トピック: Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール

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

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

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

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

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

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

ネットワーク・セキュリティ・グループ(NSG)を使用する場合は、次のプロセスをお薦めします:

  1. クライアント・ネットワーク用のNSGを作成します。 そのNSGに次のセキュリティ・ルールを追加します:

  2. バックアップ・ネットワーク用に別のNSGを作成します。 そのNSGに次のセキュリティ・ルールを追加します:

  3. データベース管理者が「Exadata Cloud Infrastructureインスタンスの作成」の場合は、複数のネットワーク・コンポーネント(たとえば、使用するVCNおよびサブネット)を選択する必要があります:
    • クライアント・サブネットを選択するときに、使用する1つまたは複数のNSGも選択できます。 クライアント・ネットワークNSGが選択されていることを確認します。
    • また、バックアップ・サブネットを選択するときに、使用する1つまたは複数のNSGを選択できます。 バックアップ・ネットワークNSGが選択されていることを確認します。

かわりに、一般ルールに対して別のNSGを作成できます。 次に、データベース管理者がクライアント・ネットワークに使用するNSGを選択する場合、一般NSGとクライアント・ネットワークNSGの両方を選択してください。 同様に、バックアップ・ネットワークでは、一般NSGとバックアップ・ネットワークNSGの両方が選択されます。

親トピック: セキュリティ・ルールの実装方法

セキュリティ・リストを使用する場合

セキュリティ・リストを使用することを選択する場合は、次のプロセスをお薦めします:

セキュリティ・リストを使用することを選択する場合は、次のプロセスをお薦めします:

  1. 必要なセキュリティ・ルールを使用するようにクライアント・サブネットを構成します:

    1. クライアント・サブネットのカスタム・セキュリティ・リストを作成し、「特にクライアント・ネットワークに必要なルール」にリストされているルールを追加します。

    2. 次の2つのセキュリティ・リストをクライアント・サブネットに関連付けます:

  2. 必要なセキュリティ・ルールを使用するようにバックアップ・サブネットを構成します:

    1. バックアップ・サブネットのカスタム・セキュリティ・リストを作成し、「特にバックアップ・ネットワークに必要なルール」にリストされているルールを追加します。

    2. 次の2つのセキュリティ・リストをバックアップ・サブネットに関連付けます:

後でデータベース管理者がExadata Cloud Serviceインスタンスを作成するときに、いくつかのネットワーク・コンポーネントを選択する必要があります。 すでに作成および構成したクライアント・サブネットおよびバックアップ・サブネットを選択すると、それらのサブネットで作成されたノードに対してセキュリティ・ルールが自動的に適用されます。

警告:

デフォルト・セキュリティ・リストからデフォルト・エグレス・ルールを削除しないでください。 その場合、クライアント・サブネットのセキュリティ・リストに次の置換エグレス・ルールを含めてください:

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0
  • IPプロトコル: すべて

親トピック: セキュリティ・ルールの実装方法

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

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

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

関連トピック

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

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

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

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

関連トピック

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