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

Exadata Cloud Serviceインスタンスを設定するには、仮想クラウド・ネットワーク(VCN)と他のネットワーキング・サービス・コンポーネントを設定する必要があります。このトピックでは、VCNの推奨構成と、Exadata Cloud Serviceインスタンスに関連するいくつかの要件について説明します。

VCNとサブネット

Exadata Cloud Serviceインスタンスを起動するには、次のものが必要です:

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

    • クライアント・サブネット
    • バックアップ・サブネット
ノート

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

一般に、リージョン内のすべての可用性ドメインにまたがるリージョナル・サブネットの使用をお薦めします。かわりにAD固有のサブネット を使用する場合は、クライアント・サブネットとバックアップ・サブネットの両方が同じ可用性ドメイン内に存在する必要があります。Exadata Cloud Serviceインスタンスについて知っておくべき重要なことは、2つのサブネットに作成するリソースが同じ可用性ドメイン内に存在する必要があることです。詳細は、VCNおよびサブネットの概要を参照してください。

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

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

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

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

次を設定できます:

重要

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

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

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

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

次を設定できます:

IPアドレス空間の要件

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

Exadata Cloud Serviceインスタンス用に作成する2つのサブネットは、192.168.128.0/20と重複しないようにしてください。

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

ヒント

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

(3アドレス* 2ノード) + SCAN用の3つとサブネット内に予約されている3つ= 12

 
/28 (16 IPアドレス) (2アドレス* 2ノード) +サブネット内に予約された3 = 7 /29 (8 IPアドレス)
ハーフ・ラック (3 * 4ノード) + 3 + 3 = 18 /27 (32 IPアドレス) (2 * 4ノード) + 3 = 11 /28 (16 IPアドレス)
フル・ラック (3* 8ノード) + 3 + 3 = 30 /27 (32 IPアドレス) (2 * 8ノード) + 3 = 19 /27 (32 IPアドレス)
フレキシブル・インフラストラクチャ・システム(X8M以上) データベース・ノード当たり3つのアドレス(最小2ノード) + SCAN用の3つとサブネット内に予約済3 データベース・ノードに必要なIPアドレスの合計数によって決定される最小サイズ データベース・ノード当たり2アドレス(最小2ノード) +サブネットで予約された3 データベース・ノードに必要なIPアドレスの合計数によって決定される最小サイズ

VCN作成ウィザード: 本番用ではない

コンソールの「ネットワーキング」セクションには、VCNと関連リソースを作成する便利なウィザードが含まれています。インスタンスを起動しようとするだけの場合に役立つことがあります。ただし、このウィザードではパブリック・サブネットとインターネット・ゲートウェイが自動的に作成されます。本番ネットワークでこれを使用しない場合もあるため、ウィザードを使用するかわりにVCNと他のリソースを個別に作成することをお薦めします。

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

ノード間の通信には、VCNではインターネットおよびVCNリゾルバを使用する必要があります。これにより、ノードへのホスト名の割当て、およびVCN内のリソースごとのこれらのホスト名のDNS解決が可能になります。これにより、データベースのSCANのラウンド・ロビン解決が可能になります。データベースのバックアップ、パッチ適用およびExadata Cloud Serviceインスタンス上のクラウド・ツールの更新に必要な重要なサービス・エンドポイントも解決できます。インターネットおよびVCNリゾルバは、VCNにおけるDNSのデフォルトの選択です。詳細は、仮想クラウド・ネットワークのDNSおよびDHCPオプションを参照してください。

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

  • VCNドメイン・ラベル
  • サブネット・ドメイン・ラベル
  • Exadata Cloud Serviceインスタンスのクラウド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間

Oracleでは、プライベートDNSリゾルバを使用して、オンプレミス・ホストとVCNリソースが相互に通信するときにホスト名を使用できるようにすることをお薦めします。プライベート・リゾルバの作成および使用の詳細は、プライベートDNSリゾルバを参照してください。リファレンス・アーキテクチャについては、Oracleアーキテクチャ・センターのVCNでのプライベートDNSの使用を参照してください。

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

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

重要

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

Oracle Cloud Infrastructure Object Storageでは、すべてのリージョンについてCIDRブロックIP範囲134.70.0.0/17が使用されます。この範囲は、2018年4月および年5月に導入されました。

2018年6月1日時点で、オブジェクト・ストレージでは次の廃止されたIP範囲はサポートされなくなりました。新しい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 Serviceインスタンスのコンピュート・ノードにSSH接続します。

    ssh -i <private_key_path> opc@<node_ip_address>
  2. opcとしてログインし、ルート・ユーザーに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 Serviceインスタンスコンピュート・ノードで前述のステップを繰り返します。

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

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

前述のオプション1オプション2のどちらを使用するかに応じて、サービス・ゲートウェイを異なる方法で使用します。次の2つの項を参照してください。

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

サービス・ゲートウェイオブジェクト・ストレージへのアクセスのみに使用するようにバックアップ・サブネットを構成します。リマインダとして、オプション1のダイアグラムを示します:

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

通常は、次の処理を行う必要があります:

  • VCNでサービス・ゲートウェイを設定するためのタスクを実行し、OCI <region> Object StorageというサービスCIDRラベルを明示的に有効にします。
  • ルーティングを更新するタスクで、バックアップ・サブネットのカスタム・ルート表にルート・ルールを追加します。宛先サービスには、OCI <region> Object Storage およびターゲット=サービス・ゲートウェイを使用します。
  • サブネットのセキュリティ・ルールを更新するタスクで、バックアップ・ネットワークのネットワーク・セキュリティ・グループ(NSG)またはカスタム・セキュリティ・リストに対してタスクを実行します。宛先サービスをOCI <region> Object Storageに設定したセキュリティ・ルールを設定します。特にバックアップ・ネットワークに必要なルールを参照してください。
オプション2: オブジェクト・ストレージとYUMリポジトリの両方へのサービス・ゲートウェイ・アクセス

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

重要

サービス・ゲートウェイを介するOracle YUMサービスへのアクセス情報については、この既知の問題を参照してください。

リマインダとして、オプション2のダイアグラムを示します:

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

通常は、次の処理を行う必要があります:

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

オプション2のサービス・ゲートウェイの使用に関する追加の詳細を次にいくつか示します:

  • クライアント・サブネットとバックアップ・サブネットの両方がサービス・ゲートウェイを使用しますが、異なるサービスにアクセスします。サービス・ゲートウェイに対して、OCI <region> Object Storageサービス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インスタンスのセキュリティ・ルール

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

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

ノート

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

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

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

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

ノート

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

このルールによって、VCNのホストでPath MTU Discoveryフラグメンテーション・メッセージを受信できるようになります。これらのメッセージにアクセスできない場合、VCN内のホストで、VCN外のホストとの通信に問題がある可能性があります。

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

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

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

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

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

重要

  • X8Mシステムの場合、Oracleでは、クライアント・サブネット上のすべてのポートをイングレスおよびエグレス・トラフィック用に開くことをお薦めします。これは、システムにデータベース・サーバーを追加するための要件です。
  • クライアント・イングレス・ルール1および2は、クライアント・サブネット内から開始された接続のみを対象とします。VCNの外部に常駐するクライアントがある場合は、かわりに「ソースCIDR」がクライアントのパブリックIPアドレスに設定されている、同様の2つのルールを追加設定することをお薦めします。
  • クライアント・イングレス・ルール3および4とクライアント・エグレス・ルール1および2では、クライアント・ネットワーク内のTCPおよびICMPトラフィックが許可され、ノードの相互通信が有効になります。ノード間でTCP接続に失敗した場合、ExadataクラウドVMクラスタまたはDBシステム・リソースはプロビジョニングに失敗します。
クライアント・イングレス・ルール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トラフィックを許可する
  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • 宛先タイプ: CIDR
  • 宛先CIDR: 0.0.0.0/0
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 22
  • 説明: ルールの説明(オプション)。
クライアント・エグレス・ルール2: すべてのエグレス・トラフィックを許可する(Oracle YUMリポジトリへの接続を許可する)

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

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

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

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

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

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

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

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

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

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

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

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

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

  3. データベース管理者がExadata Cloud Serviceインスタンスを作成する場合は、複数のネットワーク・コンポーネント(たとえば、使用する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プロトコル: すべて