Oracle Cloud Infrastructureドキュメント

Exadata DBシステムのネットワーク設定

Exadata DBシステムを設定する前に、仮想クラウド・ネットワーク(VCN)およびその他のネットワーキングの保守コンポーネント」を設定する必要があります。 このトピックでは、VCNおよびExadata DBシステムのいくつかの関連要件の推奨構成について説明します。

VCNおよびサブネット

Exadata DBシステムを起動するには、次が必要です:

  • DBシステムが必要なリージョン内のVCN
  • VCNには少なくとも2つのサブネットがあります。 2つのサブネットは次のとおりです:

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

一般に、Oracleはリージョン内のすべての可用性ドメインにまたがるリージョンのサブネットを使用することをお薦めします。 かわりに、AD固有のサブネットを使用する場合は、クライアントとバックアップの両方のサブネットが同じ「可用性ドメイン」内にある必要があります。 DBシステムに関する重要な点は、2つのサブネット内に作成するリソースが同じ「可用性ドメイン」内にあることです。 詳細は、「リージョンのサブネットについて」を参照してください。

各サブネットのカスタム・ルート表を作成します。 また、Exadataコンピュート・ノートのクライアント・ネットワークおよびバックアップ・ネットワークとの間のトラフィックを制御するセキュリティ・ルールも作成します。 詳細は、これらのアイテムを参照してください。

オプション1: インターネット・ゲートウェイでのパブリック・クライアント・サブネット

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

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

次を設定します:

重要

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

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

Oracleでは、本番システムに対してこのオプションが推奨されています。 両方のサブネットはプライベートであり、インターネットから到達することはできません。 次の図および説明を参照してください。

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

次を設定します:

IPアドレス・スペースの要件

複数のリージョンでExadata DBシステム(およびVCNs)を設定している場合は、VCNsのIPアドレス領域が重複していないことを確認してください。 これは、Oracle Data Guardで障害リカバリを設定する場合に重要です。

Exadata DBシステムに作成する2つのサブネットは、192.168.128.0/20と重ならないようにしてください。

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

ヒント

ネットワーキング・サービス「予約されている各サブネット内の3つのIPアドレス」
サブネットの領域を最小必要数(たとえば、/28ではなく少なくとも/25)よりも大きくすると、使用可能なサブネット領域への予約されているアドレスの相対的な影響を抑えることができます。

ラック・サイズ クライアント・サブネット: 必須IPアドレス数 クライアント・サブネット: 最小サイズ バックアップ・サブネット: 必須IPアドレス数 バックアップ・サブネット: 最小サイズ
基本システムまたはクオータ・ラック

(2 addresses * 2 nodes) + 3 for SCANs + 3 reserved in subnet = 10

 

/28 (16 IPアドレス) (1 address * 2 nodes) + 3 reserved in subnet = 5 /29 (8 IPアドレス)
ハーフ・ラック (2 * 4 nodes) + 3 + 3 = 14 /28 (16 IPアドレス) (1 * 4 nodes) + 3 = 7 /29 (8 IPアドレス)
フル・ラック (2* 8 nodes) + 3 + 3 = 22 /27 (32 IPアドレス) (1 * 8 nodes) + 3 = 11 /28 (16 IPアドレス)

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

コンソールネットワーキング・セクションには、関連するリソースとともにVCNを作成する便利なウィザードがあります。 インスタンスの起動を試行するのみの場合に便利です。 ただし、ウィザードによってアドレス範囲が自動的に選択され、パブリック・サブネットおよびインターネット・ゲートウェイが作成されます。 この動作は本番ネットワークでは必要としない場合があるため、Oracleでは、ウィザードではなく、VCNおよびその他のリソースを単独で作成することをお薦めします。

DNS: VCN、サブネットおよびDBシステムのショート名

通信するノードの場合、VCNは「インターネットおよびVCNリゾルバ」を使用する必要があります。 これにより、ノードへのホスト名の割当て、およびVCNのリソースによるホスト名のDNS解決が可能になります。 これにより、データベースSCANsのラウンド・ロビン解決が有効になります。 また、Exadata DBシステムでのデータベースのバックアップ、パッチ適用およびクラウド・ツールの更新に必要な重要なサービス・エンドポイントの解決も可能です。 InternetおよびVCN Resolverは、VCNのDNSのVCNデフォルト選択です。 詳細は、「あなたの仮想クラウド・ネットワークのDNS」および「DHCPオプション」も参照してください。

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

  • VCNドメイン・ラベル
  • サブネット・ドメイン・ラベル
  • Exadata DBシステムのホスト名接頭辞

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

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

例えば:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

この例では、Exadata 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文字です
  • 文字列localhostは指定できません

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

  • 推奨最大: 14文字ごと。 実際の要件は、28文字「両方のドメイン・ラベルにわたる」(ラベル間の期間を除く)の合計です。 たとえば、これらの両方が許可されます。: subnetad1.verylongvcnphxまたはverylongsubnetad1.vcnphx 簡易化するために、推奨事項はそれぞれ14文字です。
  • ハイフンなし。
  • おすすめ: VCNドメイン・ラベルにリージョン名を含め、サブネット・ドメイン・ラベルに「可用性ドメイン」名を含めます。

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

通常、FQDNは最大合計制限63文字を持っています。

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

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

オンプレミス・ホストとVCNリソースが相互に通信する際にホスト名を使用できるようにするために、次の2つのオプションがあります:

  • カスタムDNSサーバーとしてなるようにVCNにインスタンスを設定します。 Oracle Terraformプロバイダを使用したこのシナリオの実装例については、「ハイブリッドDNS構成」を参照してください。
  • ホスト名の手動解決を管理します。

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

データベースのバックアップ、パッチ適用およびExadata DBシステムでのクラウド・ツールの更新には、Oracle Cloud Infrastructure Object Storageへのアクセスが必要です。 このアクセス権を持つVCNの設定方法(たとえば、サービス・ゲートウェイを使用)に関係なく、クラスタ内の各コンピュート・ノード上で、静的ルートをオブジェクト・ストレージに構成する必要があります。 これが必要なのは、デフォルトでは、Exadata DBシステム内のすべてのトラフィックがデータ・ネットワークを介してルーティングされるためです。 バックアップ・インタフェース(BONDETH1)ではなく、オブジェクト・ストレージのトラフィックを転送する必要があります。

重要

Exadata DBシステムの「各コンピュート・ノード」オブジェクト・ストレージ・アクセスの静的ルートを構成する必要があります。
そうしないと、データベース、パッチ、または更新ツールをシステムにバックアップしようとすると失敗することがあります。

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

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

VCNは、バックアップの場合はオブジェクト・ストレージ、OSの更新の場合はOracle YUMリポジトリの両方にアクセスする必要があります。

前述の「オプション1」または「オプション2」のどちらを使用するかによって、サービス・ゲートウェイは様々な方法で使用します。 次の2つのセクションを参照してください。

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

Exadataシステムのセキュリティ・ルール

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

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

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

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

セキュリティ・リストを使用してセキュリティ・ルールを実装する場合: 次のルールは、デフォルトで「デフォルト・セキュリティ・リスト」に含まれています。

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

クライアント・ネットワークに固有のルールが必要です

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

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

重要

前述の2つのクライアント・イングレス・ルールは、クライアント・サブネット内から開始された接続のみに対応します。
VCN外にあるクライアントがある場合は、そのクライアントのパブリックIPアドレスにソースCIDRが代わりに設定されている、2つの追加の同様なルールを設定することをお薦めします。

次の4つのルール(2イングレス、2エグレス)により、クライアント・ネットワーク内部のTCPおよびICMPトラフィックが可能になり、ノード間で通信できるようになります。 ノード間でTCP接続に失敗すると、Exadata DBシステムはプロビジョニングに失敗します。

クライアント・イングレス・ルール3: クライアント・サブネット内のすべてのTCPトラフィックを許可
クライアント・イングレス・ルール4: クライアント・サブネット内のすべてのICMPトラフィックを許可
クライアント・エグレス・ルール1: クライアント・サブネット内のすべてのTCPトラフィックを許可
クライアント・エグレス・ルール2: クライアント・サブネット内のすべてのICMPトラフィックを許可

次のエグレス・ルールは、Oracle YUM reposへの接続を可能にするため重要です。 「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」 (および「デフォルト・セキュリティ・リスト」)の一般的なエグレス・ルールとの冗長性があります。 オプションですが、一般的なエグレス・ルール(またはデフォルトのセキュリティ・リスト)を誤って変更する場合にお薦めします。

クライアント・エグレス・ルール3: すべてのエグレス・トラフィックを許可

バックアップ・ネットワークにルールが特に必要です

次のセキュリティ・ルールは、DBシステムとサービス・ゲートウェイを介して「オブジェクト・ストレージ」との通信を可能にするため、バックアップ・ネットワークにとって重要です。また、クライアント・ネットワークにアクセス権がない場合は、オプションとしてOracle YUM reposと通信できます。 「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」 (および「デフォルト・セキュリティ・リスト」)の一般的なエグレス・ルールとの冗長性があります。 オプションですが、一般的なエグレス・ルール(またはデフォルトのセキュリティ・リスト)を誤って変更する場合にお薦めします。

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

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

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

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

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