Oracle Exadata Database Service on Exascale Infrastructureの準備

3 Oracle Exadata Database Service on Exascale Infrastructureの準備

OCIおよびサイト、ネットワークおよびストレージの要件を確認して、データ・センターでOracle Exadata Database Service on Exascale Infrastructureを準備およびデプロイします。

Oracle Exadata Database Service on Exascale InfrastructureのOracle Cloud Infrastructure (OCI)要件
Oracle Cloud Infrastructureの使用を開始するための基本的な概念を学習します。
Oracle Exadata Database Service on Exascale Infrastructureインスタンスのネットワーク設定
このトピックでは、VCNの推奨構成と、Oracle Exadata Database Service on Exascale Infrastructureインスタンスに関連するいくつかの要件について説明します。

Oracle Exadata Database Service on Exascale InfrastructureのOracle Cloud Infrastructure (OCI)要件

Oracle Cloud Infrastructureを使用して開始する基本概念について学習します。

Oracle Exadata Database Service on Exascale Infrastructureは、Oracle Cloud Infrastructure (OCI)コントロール・プレーンによって管理されます。 Oracle Exadata Database Service on Exascale InfrastructureリソースがOCIテナンシにデプロイされます。

Oracle Exadata Database Service on Exascale Infrastructureインフラストラクチャをプロビジョニングする前に、Oracle Exadata Database Service on Exascale Infrastructureを使用するには、Oracle Cloud Infrastructureテナンシを有効にする必要があります。詳細は、この文書の情報を確認してください。

次のタスクは、すべてのOCIデプロイメントに共通です。関連するトピックのリンクを参照して、関連するOracle Cloud Infrastructureドキュメントを検索します。

OCIの使用開始。
OCIを初めて使用する場合は、「OCIスタート・ガイド」に従って基本概念を学びます。
テナンシの設定。
OracleがOCIでテナンシを作成したら、企業の管理者は、いくつかの設定タスクを実行し、クラウド・リソースおよびユーザーの組織計画を設定する必要があります。このトピックの情報を使用すると、作業を開始できます。
リージョンの管理
このトピックでは、リージョン・サブスクリプションの管理の基本について説明します。
コンパートメントの管理
このトピックでは、コンパートメントの操作の基本について説明します。
ユーザーの管理
このトピックでは、ユーザーの操作の基本について説明します。
グループの管理
このトピックでは、グループの使用の基本について説明します。

Oracle Exadata Database Service on Exascale Infrastructureに必須のIAMポリシー
Oracle Exadata Database Service on Exascale Infrastructureシステムをプロビジョニングするためのアイデンティティ・アクセス管理(IAM)ポリシーを確認します。

Oracle Exadata Database Service on Exascale Infrastructureに必要なIAMポリシー

Oracle Exadata Database Service on Exascale Infrastructureシステムをプロビジョニングするためのアイデンティティ・アクセス管理(IAM)ポリシーを確認します。

「ポリシー」は、リソースへのアクセス権のタイプを指定するIAM文書です。これは様々な方法で使用されます:

ポリシー言語で記述された個々の文
Oracle Cloud ID (OCID)が割り当てられている、単一の名前付きポリシー・ドキュメント内の文のコレクション
組織がリソースへのアクセスを制御するために使用するポリシーの全体的な本文

「コンパートメント」は、組織の管理者によって権限が付与された特定のグループのみがアクセスできる関連リソースのコレクションです。

Oracle Cloud Infrastructureを使用するには、管理者が記述したポリシーで、コンソール、ソフトウェア開発キット(SDK)、コマンドライン・インタフェース(CLI)またはその他のツールを使用したREST APIのいずれを使用しているかにかかわらず、必要なアクセスのタイプを付与されている必要があります。アクションを実行しようとしたときに、権限がない、または許可されていないというメッセージが表示された場合は、テナンシ管理者に、付与されているアクセスのタイプと作業するコンパートメントを確認してください。

管理者向け: 「データベース管理者によるDBシステムの管理」のポリシーにより、指定したグループはデータベースおよび関連するデータベース・リソースに対してすべてのことを実行できます。

ポリシーを初めて使用する場合は、「ポリシーの開始」および「共通ポリシー」を参照してください。データベースのポリシーの書込みをより深くする場合は、「データベース・サービスの詳細」を参照してください。

Exadata Cloud@Customerリソースに固有のポリシーの記述の詳細は、「Oracle Exadata Database Service on Exascale Infrastructureのポリシー詳細」を参照してください。

Oracle Exadata Database Service on Exascale Infrastructureインスタンスのネットワーク設定

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

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

VCNとサブネット
Oracle Exadata Database Service on Exascale Infrastructure VMクラスタを起動するには、Virtual Cloud Networkと2つ以上のサブネットが必要です。
オブジェクト・ストレージへのノード・アクセス: 静的ルート
データベースをバックアップし、Oracle Exadata Database Service on Exascale Infrastructureインスタンスでクラウド・ツールにパッチを適用および更新できるようにするには、Oracle Cloud Infrastructure Object Storageへのアクセスを構成する必要があります。
VCNのサービス・ゲートウェイ
VCNはバックアップ用のObject StorageとOS更新用のOracle YUMリポジトリの両方へのアクセスを必要とします。
Oracle Exadata Database Service on Exascale Infrastructureのセキュリティ・ルール
この項では、Oracle Exadata Database Service on Exascale Infrastructureで使用するセキュリティ・ルールをリストします。
セキュリティ・ルールの実装方法
ネットワーク・サービスを使用してVCN内にセキュリティ・ルールを実装する方法について学習します。
Oracle Database Autonomous Recovery Serviceのネットワーク要件
Oracle Database Autonomous Recovery Serviceには、データベース仮想クラウド・ネットワーク(VCN)内のバックアップおよびリカバリ操作専用の登録済リカバリ・サービス・サブネットが必要です。

親トピック: Oracle Exadata Database Service on Exascale Infrastructureの準備

VCNおよびサブネット

Oracle Exadata Database Service on Exascale Infrastructure VMクラスタを起動するには、Virtual Cloud Networkと2つ以上のサブネットが必要です。

Oracle Exadata Database Service on Exascale Infrastructure VMクラスタを起動するには、Virtual Cloud Network(少なくとも2つのサブネット)があり、使用するDNSリゾルバのタイプを選択する必要があります:

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

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

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

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

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

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

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

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

「図network_exa_public_client.pngの説明」

次を設定できます:

サブネット:
- 「パブリック」クライアント・サブネット(「パブリック」は、サブネット内のリソースが任意にパブリックIPアドレスを持つことができることを意味します)。
- 「プライベート」バックアップ・サブネット(「プライベート」は、サブネット内のリソースがパブリックIPアドレスを持つことができず、インターネットからの受信接続を受信できないことを意味します)。
VCNのゲートウェイ:
- 「インターネット・ゲートウェイ」 (クライアント・サブネットで使用)。
- 「サービス・ゲートウェイ」 (バックアップ・サブネットで使用する場合)。
ルート表:
- 0.0.0.0/0のルートおよびターゲット=インターネット・ゲートウェイを持つ、パブリック・クライアント・サブネットのカスタム・ルート表。
- プライベート・バックアップ・サブネットのカスタム・ルート表は、サービスCIDRラベルのルート・ルール(「サービス・ゲートウェイの概要」および使用可能なサービスCIDRラベルの下のCIDRラベル、およびターゲット=サービス・ゲートウェイを参照)で区切ります。
「セキュリティ・ルール」: Exadata仮想マシンのコンピュート・ノードとの間で必要なトラフィックを有効にします。
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アドレス空間の要件

2つのサブネットを含むVCNを作成し、VMクラスタのサイズに対して十分なアドレスがあることを確認する必要があります。

ノート:

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

複数のリージョンにVMクラスタ(したがって、VCN)を設定する場合は、VCNのIPアドレス空間が重複しないようにしてください。これは、Oracle Data Guardを使用して障害リカバリを設定する場合に重要です。

クライアント・サブネットの場合、各ノードには4つのIPアドレスが必要で、さらに3つのアドレスが単一クライアント・アクセス名(SCANs)用に予約されています。バックアップ・サブネットの場合、各ノードに3つのアドレスが必要です。ネットワーキング・サービスでは、各サブネットに3つのIPアドレスを予約しています。

次の式を使用して、変数nがVMクラスタ内のVMの数であるIPアドレスの最小数を計算します:

クライアント・アドレスの最小数= 4*n+6

バックアップ・アドレスの最小数= 3*n+3

ノート:

サブネットに必要な最小領域(たとえば、 /28ではなく少なくとも/25)を割り当てると、サブネットの使用可能な領域に対する予約済アドレスの相対的な影響を減らすことができます。将来の成長を計画するには、VMクラスタをスケール・アップする際に必要となるアドレスを追加します。これは、即時に必要になるようにプロビジョニングする予定のVMの数だけではありません。

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

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

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

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

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

Oracle Exadata Database Service on Exascale 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、サブネットおよびOracle Exadata Database Service on Exascale Infrastructureインスタンスの短縮名

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

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

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

VCNドメイン・ラベル
サブネット・ドメイン・ラベル
Oracle Exadata Database Service on Exascale 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デプロイメントは失敗します。

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

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

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

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

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

親トピック: DNS: VCN、サブネットおよびOracle Exadata Database Service on Exascale Infrastructureインスタンスの短縮名

プライベート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とサブネット

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

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

注意:

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

ノート:

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

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

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

親トピック: Oracle Exadata Database Service on Exascale Infrastructureインスタンスのネットワーク設定

Object Storage IP割当て

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

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

Oracle Exadata Database Service on Exascale 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コマンドの実行直後に有効になります。
Oracle Exadata Database Service on Exascale Infrastructureインスタンスのeachコンピュート・ノードで前述のステップを繰り返します。

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

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

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

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

親トピック: Oracle Exadata Database Service on Exascale Infrastructureインスタンスのネットワーク設定

オプション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>オブジェクト・ストレージに設定してセキュリティ・ルールを設定します。「セキュリティ・ルール」を参照してください。クライアント・サブネットには、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 Exascale Infrastructureのセキュリティ・ルール

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

セキュリティ・ルールは、仮想マシンのクライアント・ネットワークおよびバックアップ・ネットワークで許可されるトラフィックのタイプを制御します。ルールは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システム・リソースはプロビジョニングに失敗します。

クライアント・イングレス・ルール3: クライアント・サブネット内からのトラフィックへのパッチ適用を許可

ステートレス: いいえ(すべてのルールはステートフルである必要があります)
ソース・タイプ: CIDR
ソースCIDR: クライアント・サブネットCIDR
IPプロトコル: TCP
ソース・ポート範囲: すべて
宛先ポート範囲: 7085
説明: オプションで、ルールのわかりやすい説明を追加します。たとえば: サブネット内のExadataフリート更新プライベート・エンドポイントへのアクセスを許可します。

Oracle DatabaseおよびOracle Grid Infrastructureパッチ適用に必要なIAMポリシー

データベースおよびOracle Grid Infrastructureを管理するユーザーまたはグループに、サブネット、仮想ネットワーク・インタフェース・カード(vNICs)およびプライベートIPアドレス(プライベートIP)にアクセスするためのIdentity and Management (IAM)ポリシーを付与します。たとえば、グループadmin-groupがコンパートメントABCを管理するとします。その場合は、次のポリシーを設定します:

グループadmin-groupがコンパートメントABCのサブネットを使用することを許可
グループadmin-groupがコンパートメントABCでvNICsを使用できるようにします
グループadmin-groupにコンパートメントABCのprivate-ipsの使用を許可

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

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

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

親トピック: Oracle Exadata Database Service on Exascale Infrastructureインスタンスのネットワーク設定

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

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

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

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

関連トピック

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

親トピック: Oracle Exadata Database Service on Exascale 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 Exascale 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 Exascale Infrastructureのセキュリティ・ルール

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

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

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

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

サービス・ゲートウェイの作成時に、「Oracle Services Networkのすべての<region>サービス」というサービス・ラベルを有効にします。これにはモニタリング・サービスが含まれます。
インスタンスを含むサブネットのルーティングを設定する場合は、「ターゲット・タイプ」を「サービス・ゲートウェイ」に設定し、「宛先サービス」を「Oracle Services Networkのすべての<region>サービス」に設定してルート・ルールを設定します。

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

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

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

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

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

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

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

親トピック: Oracle Exadata Database Service on Exascale Infrastructureインスタンスのネットワーク設定

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

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

クライアント・ネットワーク用のNSGを作成します。そのNSGに次のセキュリティ・ルールを追加します:
- 「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」にリストされているルール
- 「特にクライアント・ネットワークに必要なルール」にリストされているルール
バックアップ・ネットワーク用に別のNSGを作成します。そのNSGに次のセキュリティ・ルールを追加します:
- 「クライアント・ネットワークとバックアップ・ネットワークの両方に必要なルール」にリストされているルール
- 「特にクライアント・ネットワークに必要なルール」にリストされているルール
データベース管理者は、「Exadata Database Service on Exascale Infrastructure」でExadataインスタンスを作成するときに、複数のネットワーク・コンポーネント(使用するVCNおよびサブネットなど)を選択する必要があります:
- クライアント・サブネットを選択すると、使用するNSGも選択できます。クライアント・ネットワークのNSGを選択します。
- バックアップ・サブネットを選択すると、使用する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へのサービス・ゲートウェイを作成します。自動更新および構成メタデータにはサービス・ゲートウェイが必要です。

関連トピック

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

親トピック: Oracle Exadata Database Service on Exascale 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のネットワーク要件