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

機械翻訳について

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

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

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

「VCNとサブネット」
Exadata Cloud Infrastructureインスタンスを起動するには、Virtual Cloudネットワークおよび少なくとも2つのサブネットが必要です:
「オブジェクト・ストレージへのノード・アクセス: 静的ルート」
データベースをバックアップし、「Exadataクラウド・インフラストラクチャ」インスタンスでクラウド・ツールにパッチを適用および更新できるようにするには、Oracle Cloud Infrastructure Object Storageへのアクセスを構成する必要があります。
「VCNのサービス・ゲートウェイ」
VCNはバックアップ用のObject StorageとOS更新用のOracle YUMリポジトリの両方へのアクセスを必要とします。
「Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール」
この項では、「Exadataクラウド・インフラストラクチャ」で使用するセキュリティ・ルールを示します。
「セキュリティ・ルールの実装方法」
ネットワーク・サービスを使用してVCN内にセキュリティ・ルールを実装する方法について学習します。
「Oracle Database Autonomous Recovery Serviceのネットワーク要件」
Oracle Database Autonomous Recovery Serviceには、データベース仮想クラウド・ネットワーク(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 Cloud Infrastructureインスタンスの場合、ネットワーキングはクラウドVMクラスタ・リソースで構成されます。

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

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

「オプション1: インターネット・ゲートウェイを使用したパブリック・クライアント・サブネット」
このオプションは、概念の証明または開発作業を行う場合に便利です。
「オプション2: プライベート・サブネット」
Oracleでは、本番システム用にプライベート・サブネットを推奨しています。
「IPアドレス空間の要件」
特に、「Exadataクラウド・インフラストラクチャ」 VMクラスタ(およびVCN)が複数のリージョンにある場合、IPアドレスは重複できません。
「オブジェクト・ストアにアクセスするための静的ルートの構成」
バックアップ・トラフィックをバックアップ・インタフェース(BONDETH1)にルーティングするには、クラスタ内のコンピュート・ノードのeachで静的ルートを構成する必要があります。
「Exadata Cloud InfrastructureインスタンスのDNSの設定」
DNSでは、IPアドレスのかわりにホスト名を使用して、Exadata Cloud Infrastructureインスタンスと通信できます。
「DNS: VCN、サブネットおよびExadata Cloud Infrastructureインスタンスの短縮名」
インターネットおよびVCNリゾルバは、ノードへのホスト名の割当て、およびVCN内のリソースによるそれらのホストのDNS解決を可能にします。
「DNS: オンプレミス・ネットワークとVCNの間」
Oracleでは、オンプレミス・ホストとVCNリソースが相互に通信する場合にホスト名を使用できるようにプライベートDNSリゾルバを使用することをお薦めします。
「プライベートDNSの構成」
プライベートDNSを使用するために必要な前提条件。

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

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

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

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

「図network_exa_public_client.pngの説明」

次を設定できます:

サブネット:
- 「パブリック」クライアント・サブネット(「パブリック」は、サブネット内のリソースが任意にパブリックIPアドレスを持つことができることを意味します)。
- 「プライベート」バックアップ・サブネット(「プライベート」は、サブネット内のリソースがパブリックIPアドレスを持つことができず、インターネットからの受信接続を受信できないことを意味します)。
VCNのゲートウェイ:
- 「インターネット・ゲートウェイ」 (クライアント・サブネットで使用)。
- 「サービス・ゲートウェイ」 (バックアップ・サブネットで使用)。また、「オプション1: OCIサービスへのサービス・ゲートウェイ・アクセス」を参照してください。
ルート表:
- 0.0.0.0/0のルートおよびターゲット=インターネット・ゲートウェイを持つ、パブリック・クライアント・サブネットのカスタム・ルート表。
- プライベート・バックアップ・サブネットのカスタム・ルート表は、サービスCIDRラベルのルート・ルール(「サービス・ゲートウェイの概要」および使用可能なサービスCIDRラベルの下のCIDRラベル、およびターゲット=サービス・ゲートウェイを参照)で区切ります。また、「オプション1: OCIサービスへのサービス・ゲートウェイ・アクセス」を参照してください。
「セキュリティ・ルール」: Exadata仮想マシンのコンピュート・ノードとの間で必要なトラフィックを有効にします。「Oracle Exadata Database Service on Dedicated Infrastructureのセキュリティ・ルール」を参照してください。
Exadata Cloud Serviceインスタンスのコンピュート・ノードの「オブジェクト・ストレージへのノード・アクセス: 静的ルート」 (バックアップ・サブネット経由でOCIサービスにアクセスできるようにするため)。

ノート:

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

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

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

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

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

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

「図network_exa_private_client.pngの説明」

次を設定できます:

サブネット:
- 「プライベート」クライアント・サブネット。
- 「プライベート」バックアップ・サブネット。
VCNのゲートウェイ:
- (クライアント・サブネットで使用するため)オンプレミス・ネットワークに対するFastConnectまたはIPSec VPNを使用した「動的ルーティング・ゲートウェイ(DRG)」。
- 「サービス・ゲートウェイ」バックアップ用のオブジェクト・ストレージ、OS更新用のYUM、IAM (Identitiy Access Management)およびOCI Vault (KMS Integration)などのOCIサービスにバックアップおよびクライアント・サブネットが使用する場合は、「オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイ・アクセス」も参照してください。
- 「NATゲートウェイ」 (optional)サービス・ゲートウェイでサポートされていないパブリック・エンドポイントに到達するためにクライアント・サブネットで使用されます。
ルート表:
- 次のルールが適用されたプライベート・クライアント・サブネットのカスタム・ルート表:
  - オンプレミス・ネットワークCIDR、およびターゲット=DRGのルール。
  - 「Oracle Services Networkのすべての<region>サービス」という「サービスCIDRラベル」のルール、およびターゲット=サービス・ゲートウェイ。「Oracle Servicesネットワーク」は、Oracleサービス用に予約されているOracle Cloud Infrastructureの概念的なネットワークです。このルールによって、クライアント・サブネットがOSの更新のためにリージョンのOracle YUMリポジトリにアクセスできるようになります。また、「オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイ・アクセス」を参照してください。
  - オプションで、0.0.0.0/0,およびターゲット= NATゲートウェイのルールを指定します。
- 1つのルールが使用される、プライベート・バックアップ・サブネットの個別のカスタム・ルート表:
  - クライアント・サブネットと同じルール: 「Oracle Services Networkのすべての<region>サービス」という「サービスCIDRラベル」に対して、targetはサービス・ゲートウェイです。このルールは、バックアップ・サブネットがバックアップのためにリージョンのObject Storageにアクセスできるようにします。
「セキュリティ・ルール」: Exadataノードとの間の必要なトラフィックを有効にします。「Exadata Cloud Serviceインスタンスのセキュリティ・ルール」を参照してください。
オプションで、他のOCIサービス(VMクラスタ、仮想マシン)にコンピュート・ノード上の「静的ルート」を追加して、サービスがバックアップ・サブネットでのみアクセス可能であり、NATゲートウェイを使用する場合など、クライアント・サブネットからアクセス可能である場合にアクセスできるようにします。

親トピック: 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では、インターコネクトにIPアドレス(100.106.0.0/16および100.107.0.0/16)が使用されます。

次の表に、各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クラスタまたは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 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を使用するために必要な前提条件。

DBシステム・プロビジョニングを起動する前に、プライベート・ビューおよびプライベート・ゾーンを作成する必要があります。詳細は、「プライベート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割当て

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

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

Exadata Cloud Infrastructureインスタンスのコンピュート・ノードにSSH接続します。
```
ssh -i <private_key_path> opc@<node_ip_address>
```
opcとしてログインし、rootユーザーにsudoを実行します。ルート・ユーザー・プロファイルを起動するには、ハイフン付きのsudo su -を使用します。
```
login as: opc
			
[opc@dbsys ~]$ sudo su - 
```

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

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


10.0.4.1

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

インタフェースを再起動します。
```
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;
```
前述のステップのファイル変更は、ifdownおよびifupコマンドの実行直後に有効になります。
Exadata Cloud Infrastructureインスタンスのeachコンピュート・ノードで前述のステップを繰り返します。

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

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

VCNはバックアップ用のObject StorageとOS更新用のOracle YUMリポジトリの両方へのアクセスを必要とします。

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

「オプション1: OCIサービスへのサービス・ゲートウェイ・アクセス」
サービス・ゲートウェイをオブジェクト・ストレージへのアクセスにのみ使用するように、「バックアップ・サブネット」を構成します。
「オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイ・アクセス」
オブジェクト・ストレージとOracle YUMリポジトリの両方を含む、Oracle Services Networkへのアクセスにサービス・ゲートウェイを使用するように「クライアント・サブネットとバックアップ・サブネットの両方」を構成します。

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

関連トピック

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

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

オブジェクト・ストレージとOracle YUMリポジトリの両方を含む、Oracle Services Networkへのアクセスにサービス・ゲートウェイを使用するように「クライアント・サブネットとバックアップ・サブネットの両方」を構成します。

ノート:

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

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

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

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

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

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

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

関連トピック

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

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

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

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

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

ノート:

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

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

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

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

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

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

重要:

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

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

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

「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」
このトピックでは、VCNのホストに不可欠な接続性を有効にする、いくつかの一般ルールがあります。
「特にクライアント・ネットワークに必要なルール」
クライアント・ネットワークに対して重要なセキュリティ・ルールは次のとおりです。
「特にバックアップ・ネットワークに必要なルール」
次のセキュリティ・ルールは、バックアップ・ネットワークにとって重要です。これは、DBシステムがサービス・ゲートウェイを介してObject Storageと通信できるようにするためです(また、クライアント・ネットワークにアクセス権がない場合に、オプションでOracle YUMリポジトリと通信することもできます)。
「イベント・サービスに必要なルール」
コンピュート・インスタンス・メトリックをイベント・サービスに送信するには、コンピュート・インスタンスにパブリックIPアドレスまたはサービス・ゲートウェイが必要です。
「モニタリング・サービスに必要なルール」
コンピュート・インスタンス・メトリックをモニタリング・サービスに送信できるようにするには、コンピュート・インスタンスにパブリックIPアドレスまたはサービス・ゲートウェイが必要です。

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

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

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

「一般イングレス・ルール1: あらゆる場所からSSHトラフィックを許可」
「一般イングレス・ルール2: Path MTU Discoveryフラグメンテーション・メッセージを許可」
「一般イングレス・ルール3: VCN内の接続エラー・メッセージを許可」
このルールにより、VCN内のホストは接続エラー・メッセージを相互に受信できるようになります。
「一般エグレス・ルール1: すべてのエグレス・トラフィックを許可」

関連トピック

デフォルト・セキュリティ・リスト

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

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

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

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

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

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

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

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

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

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

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

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

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

ノート:

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

「クライアント・イングレス・ルール1: クライアント・サブネット内からのONSおよびFANトラフィックを許可」
最初のルールが推奨され、Oracle Notification Services (ONS)でFast Application Notification (FAN)イベントについて通信できるようになります。
「クライアント・イングレス・ルール2 : クライアント・サブネット内からのSQL*NETトラフィックを許可」
これは、SQL*NETトラフィックに関するルールであり、次の場合に必要です:
「クライアント・エグレス・ルール1: クライアント・サブネット内のすべてのTCPトラフィックを許可」
このルールは、前述のSQL*NETトラフィック用です。
「クライアント・エグレス・ルール2: すべてのエグレス・トラフィックを許可(Oracle YUMリポジトリへの接続を許可)」
クライアント・エグレス・ルール3は、Oracle YUMリポジトリへの接続を許可するため重要です。

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

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

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

関連トピック

デフォルト・セキュリティ・リスト

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

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

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

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

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

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

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

コンピュート・インスタンス・メトリックをイベント・サービスに送信するには、コンピュート・インスタンスにパブリック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)を使用する場合は、次のプロセスをお薦めします:

クライアント・ネットワーク用のNSGを作成します。そのNSGに次のセキュリティ・ルールを追加します:
- 「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」にリストされているルール
- 「特にクライアント・ネットワークに必要なルール」にリストされているルール
バックアップ・ネットワーク用に別のNSGを作成します。そのNSGに次のセキュリティ・ルールを追加します:
- 「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」にリストされているルール
- 「特にクライアント・ネットワークに必要なルール」にリストされているルール
データベース管理者が「Exadata Cloud Infrastructureインスタンスの作成」の場合は、複数のネットワーク・コンポーネント(たとえば、使用するVCNおよびサブネット)を選択する必要があります:
- クライアント・サブネットを選択するときに、使用する1つまたは複数のNSGも選択できます。クライアント・ネットワークNSGが選択されていることを確認します。
- また、バックアップ・サブネットを選択するときに、使用する1つまたは複数のNSGを選択できます。バックアップ・ネットワークNSGが選択されていることを確認します。

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

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

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

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

必要なセキュリティ・ルールを使用するようにクライアント・サブネットを構成します:
1. クライアント・サブネットのカスタム・セキュリティ・リストを作成し、「特にクライアント・ネットワークに必要なルール」にリストされているルールを追加します。
2. 次の2つのセキュリティ・リストをクライアント・サブネットに関連付けます:
  - VCN 「デフォルト・セキュリティ・リスト」とそのすべてのデフォルト・ルール。これには、VCNが自動的に付属します。デフォルトでは、「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」のルールが含まれます。
  - クライアント・サブネット用に作成した新しいカスタム・セキュリティ・リスト。
必要なセキュリティ・ルールを使用するようにバックアップ・サブネットを構成します:
1. バックアップ・サブネットのカスタム・セキュリティ・リストを作成し、「特にバックアップ・ネットワークに必要なルール」にリストされているルールを追加します。
2. 次の2つのセキュリティ・リストをバックアップ・サブネットに関連付けます:
  - VCN 「デフォルト・セキュリティ・リスト」とそのすべてのデフォルト・ルール。これには、VCNが自動的に付属します。デフォルトでは、「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」のルールが含まれます。
  - バックアップ・サブネット用に作成した新しいカスタム・セキュリティ・リスト。

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

警告:

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

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

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

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

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

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

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

関連トピック

リカバリ・サービスの構成

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

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

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

ナビゲーション・メニューを開きます。「ネットワーク」をクリックし、「仮想クラウド・ネットワーク」を次にクリックします。
バックアップするデータベース・サービスが配置されているVCNを選択します。
表示された「仮想クラウド・ネットワーク詳細」ページの「リソース」で、「サービス・ゲートウェイ」をクリックします。
「サービス・ゲートウェイの作成」をクリックし、次の詳細を指定します。
1. 名前: サービス・ゲートウェイのわかりやすい名前。一意である必要はありません。機密情報の入力は避けてください。
2. コンパートメント: サービス・ゲートウェイを作成するコンパートメント(現在作業しているコンパートメントと異なる場合)。
3. サービス: ドロップダウン・リストからサービスCIDRラベルAll <region> Services in Oracle Services Networkを選択します。
4. タグ: (詳細オプション)リソースを作成する権限がある場合は、そのリソースにフリー・フォーム・タグを適用する権限もあります。定義済のタグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、「リソース・タグ」を参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
「サービス・ゲートウェイの作成」をクリックします。

ゲートウェイが作成されるまで待ってから、次のステップに進みます。
「リソース」の下で、「ルート表」をクリックします。

ルート表の関連付け: 特定のVCNルート表をこのゲートウェイに関連付けることができます。ルート表を関連付けた後、ゲートウェイには常にルート表が関連付けられている必要があります。現在のルート表のルールを変更するか、別のルート表に置き換えることができます。
リカバリ・サービスのサブネットで使用される「ルート表」名をクリックします。
表示された「ルート表詳細」ページで、「ルート・ルール」セクションの「ルート・ルールの追加」をクリックします。

特定のサービスCIDRラベルに対してサービス・ゲートウェイを構成する場合、そのラベルを宛先として、ターゲットをサービス・ゲートウェイとして指定するルート・ルールも作成する必要があります。これは、ゲートウェイにアクセスする必要があるサブネットごとに行います。
表示される「ルート・ルールの追加」ダイアログで、次の詳細を入力します:
1. ターゲット・タイプ: サービス・ゲートウェイ
2. 宛先サービス: ゲートウェイに対して有効になっているサービスCIDRラベル。 All <region> Services in Oracle Services Network
3. ターゲット・サービス・ゲートウェイ: ステップ4で指定した名前を選択します。
4. 説明: ルールの説明(オプション)。
「ルート・ルールの追加」をクリックします。

関連トピック

Resource Tags

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