Exadata Cloud Infrastructureインスタンスの作成

このトピックでは、Oracle Exadata Cloud Infrastructureインスタンスの作成方法について説明します。また、Oracle Cloud Infrastructure Object Storageサービスへの必要なアクセスの構成方法とDNSの設定方法についても説明します。

コンソールまたはAPIを使用してExadata Cloud Infrastructureインスタンスを作成する場合、Oracleデータベースをサポートするシステムがプロビジョニングされます。インフラストラクチャとともに、VMクラスタ、初期データベース・ホームおよびデータベースが作成されます。コンソールまたはOracle Cloud Infrastructure APIを使用して、いつでも追加のデータベース・ホームおよびデータベースを作成できます。サービスでは、顧客が指定したオプションおよびこのトピックで後述するいくつかのデフォルト・オプションに基づいて、初期データベースが作成されます。

作成されるリソース

Exadata Cloud InfrastructureインフラストラクチャおよびVMクラスタ・リソースを別々にプロビジョニングします。

  • クラウドExadataインフラストラクチャ・リソース: インフラストラクチャ・リソースは最上位(親)リソースです。インフラストラクチャ・レベルで、データベース・サーバーとストレージ・サーバーの数を制御します。また、Exadataシステム・メンテナンス・スケジュールもExadataインフラストラクチャ・レベルで制御します。
  • クラウドVMクラスタ・リソース: VMクラスタはインフラストラクチャ・リソースの子リソースで、Exadataクラウド・インフラストラクチャ・リソースとOracle Databaseの間のリンクを提供します。ネットワーキング、OCPU数、IORM (IORMについてを参照)およびOracle Grid Infrastructureは、VMクラスタ・レベルで構成および管理されます。クラウドVMクラスタを作成するには、VMクラスタを格納するための既存のクラウドExadataインフラストラクチャ・リソースが必要です。
ノート

  • Exadata Cloud Infrastructureでは、ハードウェア・シェイプ・ファミリの選択(X7、X8、X8MまたはX9M)に関係なく、新しいリソース・モデル(Exadataインフラストラクチャ・リソースとVMクラスタ・リソースに分かれた構成)を使用したExadata Cloud Infrastructureインスタンスのプロビジョニングのみがサポートされます。DBシステムのリソース・モデルおよびAPIは、Exadata Cloud Infrastructureでは非推奨です。
  • マルチVM対応インフラストラクチャは、インフラストラクチャでの最大8つのVMクラスタの作成をサポートします。>> X8M以上の世代のDBサーバーを持つExadataインフラストラクチャは、すべてのDBサーバー全体で最大8つのVMクラスタをサポートできます。インフラストラクチャ全体の最大クラスタ数は、DBサーバーごとに使用可能なリソースによって異なり、DBサーバーごとの最大VM制限に従います。詳細は、VMクラスタ・ノードのサブセット化の概要を参照してください。
  • マルチVM対応ではないExadata Cloud Serviceインフラストラクチャ・インスタンスでは、1つのクラウドVMクラスタのみがサポートされます

クラウドExadataインフラストラクチャ・インスタンスを作成するための前提条件

インフラストラクチャ・インスタンスを作成するには、SSHキー・ペア・キーおよび仮想クラウド・ネットワーク(VCN)が必要です。

  • 続行するには適切なIAMポリシーが必要です。Exadata Cloud Infrastructureに必要なIAMポリシーを参照してください
  • SSHを介したシステムへの接続に使用する予定のキー・ペアのOpenSSH形式の公開キー。読みやすいように短縮した公開キーの例を次に示します。

    ssh-rsa AAAAB3NzaC1yc2EAAAABJQAA....lo/gKMLVM2xzc1xJr/Hc26biw3TXWGEakrK1OQ== rsa-key-20160304

    詳細は、Linuxインスタンスでのキー・ペアの管理を参照してください。

  • システムの起動場所である正しく構成された仮想クラウド・ネットワーク(VCN)。関連するネットワーク・リソース(ゲートウェイ、ルート表、セキュリティ・リスト、DNSなど)も、システムの必要に応じて構成する必要があります。詳細は、Exadata Cloud Infrastructureインスタンスのネットワーク設定を参照してください。

初期データベースのデフォルト・オプション

デフォルト・オプションにより、コンソールでのExadata Cloud Infrastructureインスタンスの起動およびAPIの使用が簡略化されます。

次のデフォルト・オプションが初期データベースに使用されます:

  • コンソールの有効化: False
  • コンテナ・データベースの作成: バージョン11.2.0.4データベースの場合はFalse。それ以外の場合はtrue。
  • インスタンスのみ作成(スタンバイおよび移行の場合): False
  • データベース・ホームID: データベース・ホームを作成します
  • データベース言語: AMERICAN
  • データベース・サイズ・テンプレート: odb2
  • データベース・ストレージ: 自動ストレージ管理(ASM)
  • データベース・テリトリ: AMERICA
  • 一意のデータベース名: ユーザー指定のデータベース名およびシステムが生成した接頭辞(dbtst_phx1csなど)。
  • PDB管理者名: pdbuser(バージョン11.2.0.4データベースには適用されません。)

コンソールを使用したインフラストラクチャ・リソースの作成

クラウド・リソースの作成に必要なコンソール・タスク

  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします
  2. 「Oracle Exadata Database Service on Dedicated Infrastructure」で、「Exadataインフラストラクチャ」をクリックします。
  3. 「Exadata Cloud Infrastructureの作成」をクリックします。
  4. コンパートメント: Exadataインフラストラクチャのコンパートメントを選択します。
  5. 表示名: Exadataインフラストラクチャの表示名を入力します。この名前は一意である必要はありません。Oracle Cloud Identifier (OCID)は、クラウドExadataインフラストラクチャ・リソースを一意に識別します。機密情報を入力しないでください。
  6. 可用性ドメインの選択: Exadataインフラストラクチャが存在する可用性ドメイン。
  7. Exadata Cloud Infrastructureモデルの選択: 固定シェイプ・システム(クォータ、ハーフまたはフル・ラックのX7-2またはX8-2シェイプ)、またはスケーラブル・システム(X8M-2、X9M-2またはX11M)のいずれかを選択します。

    X11M: フレキシブルX11Mクラウド・インフラストラクチャ・モデルを選択した場合、初期Exadata Cloud Infrastructureインスタンスは、最小で2つのデータベース・サーバーと3つのストレージ・サーバー、最大で32個のデータベース・サーバーと64個のストレージ・サーバーを持つことができます。データベース・サーバーおよびストレージ・サーバー・タイプも選択する必要があります。これは、データベース・サーバー・タイプの場合はX11M、ストレージ・サーバー・タイプの場合はX11M-HCにデフォルト設定されます。プロビジョニング後、必要に応じてストレージ・サーバーまたはコンピュート・サーバー(あるいはその両方)を追加することで、サービス・インスタンスをスケールできます。

    X9M-2: フレキシブルX9M-2クラウド・インフラストラクチャ・モデルを選択した場合、初期Exadata Cloud Infrastructureインスタンスは、最小で2台のデータベース・サーバーと3台のストレージ・サーバー、最大で32台のデータベース・サーバーと64台のストレージ・サーバーを持つことができます。プロビジョニング後、必要に応じてストレージ・サーバーまたはコンピュート・サーバー(あるいはその両方)を追加することで、サービス・インスタンスをスケールできます。

    X8M-2: フレキシブルなX8M-2クラウド・インフラストラクチャ・モデルを選択した場合、最初のExadata Cloud Infrastructureインスタンスは、最小で2つのデータベース・サーバーと3つのストレージ・サーバー(X8クォータ・ラック・シェイプに相当)を、最大で32個のデータベース・サーバーと64個のストレージ・サーバーを持つことができます。プロビジョニング後、必要に応じてストレージ・サーバーまたはコンピュート・サーバー(あるいはその両方)を追加することで、サービス・インスタンスをスケールできます。

    X7およびX8: X7またはX8システムを選択した場合、クォータ、ハーフまたはフル・ラックのプロビジョニングを選択できます。ハードウェアおよび容量の詳細は、Exadataシェイプ構成を参照してください。

    Exadataベース: Exadataベース・シェイプは単一の構成で提供され、クォータ・ラック・システムのプロビジョニングにかわる経済的な選択肢を提供します。Exadataシェイプ構成を参照してください

  8. フレキシブル・シェイプ(X8M-2、X9M-2またはX11M)を選択した場合は、コンピュートおよびストレージ構成を指定します。データベース・サーバーは、最小2台から最大32台まで指定できます。ストレージ・サーバーは、最小3台から最大64台まで指定できます。
  9. タイム・ゾーンの選択: 次のいずれかを選択します:
    • UTC
    • 別のタイムゾーンの選択
    • (ブラウザ検出)タイムゾーン
  10. メンテナンスの構成

    「メンテナンスのプリファレンスの編集」をクリックして値を変更します

    「メンテナンスの構成」ページで、次を構成します:
    • メンテナンス・スケジュール・プリファレンス: Oracle管理スケジュール
      • メンテナンス方法の選択:
        • ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
        • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
      • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
        • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
          ノート

          カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。この時間内に、計画したアクションを実行できます。カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。カスタム・アクションが進行中の場合、顧客は2つのオプション(カスタム・アクション・タイムアウトの延長またはメンテナンス・ウィンドウの再開)を取得します。

          デフォルト: 15分

          最大: 120分

      • 「変更の保存」をクリックします。

        ノート

        次回のメンテナンス実行以降は、Oracleのスケジュールに従って実行されます。
    • 保守スケジュール作業環境:顧客管理スケジュール
      • メンテナンス・スケジュール:このインフラストラクチャのメンテナンス・プリファレンスを定義します。
        ノート

        変更は、次のメンテナンス実行から有効になります。
        • 保守作業環境の構成:各四半期の保守時間作業環境を定義します。1つの四半期に複数のプリファレンスを定義すると、Oracle Automationにより、その中の1つが選択され、インフラストラクチャのすべてのコンポーネントでメンテナンスが実行されます。

          2四半期ごとに少なくとも1か月を選択します。

        • スケジュールの指定: インフラストラクチャ・メンテナンスに対して希望する週、平日、開始時刻およびリード・タイムを選択します。
          • オプションです。「該当月の週」で、メンテナンスを実行する月の週を指定します。週は月の1日、8日、15日、22日から始まり、7日の期間があります。週の開始および終了は、曜日ではなくカレンダの日付に基づきます。28日より多くの日数を含む月の第5週には、メンテナンスをスケジュールできません。月の週を指定しない場合は、Oracleによって、中断が最小限になる週にメンテナンス更新が実行されます。
          • オプションです。「曜日」で、メンテナンスを実行する曜日を指定します。曜日を指定しない場合は、Oracleによって、中断が最小限になる週末の日にメンテナンス更新が実行されます。
          • オプションです。「1日の時間」で、メンテナンス実行を開始する時間を指定します。開始時間を指定しない場合は、Oracleによって、中断が最小限になる時間が選択されてメンテナンス更新が実行されます。
          • 「通知リード・タイム」で、メンテナンス・イベントの何週間前に通知メッセージを受信するかを指定します。リード・タイムにより、事前通知に必要な最短期間を考慮して、新しくリリースされるメンテナンス更新がスケジュールされます。
        • メンテナンス方法の選択:
          • ローリング: デフォルトでは、Exadataインフラストラクチャは、ローリング方式で更新されます(停止時間なしで一度に1つのサーバーが対象)。
          • 非ローリング: データベース・サーバーとストレージ・サーバーを同時に更新します。非ローリング・メンテナンス方法では、メンテナンス時間が最小化されますが、完全なシステム・ダウンタイムが発生します。
        • DBサーバーでメンテナンスを実行する前にカスタム・アクションを有効化: カスタム・アクションは、オラクル社の管理の範囲外で、追加のアクションを実行する場合にのみ有効にします。ローリング・ソフトウェア更新で構成されたメンテナンスの場合は、このオプションを有効化すると、各DBサーバーでメンテナンスを開始する前に、メンテナンスの実行は、タイムアウトが構成されたカスタム・アクションを強制的に待機することになります。非ローリング・ソフトウェア更新で構成されたメンテナンスの場合、メンテナンス実行は、すべてのDBサーバーでメンテナンスを開始する前に、タイムアウトが構成されたカスタム・アクションを待機することになります。メンテナンス実行は、カスタム・アクションを待機している間、タイムアウトの前に再開されることもあります。
          • カスタム・アクション・タイムアウト(分): DBサーバーでメンテナンスを開始する前に、カスタム・アクションを実行できるタイムアウト。
            ノート

            カスタム・アクションのタイムアウトは、DBサーバーにのみ適用されます。お客様は、DBサーバーのパッチ適用が開始される前に、最低15分および最大120分のカスタム・アクションのタイムアウトを指定できます。この時間内に、計画したアクションを実行できます。カスタム・アクションを拡張する場合は、「メンテナンス・ウィンドウの編集」オプションに移動して、同じ操作を拡張できます。カスタム・アクションが進行中の場合、顧客は2つのオプション(カスタム・アクション・タイムアウトの延長またはメンテナンス・ウィンドウの再開)を取得します。

            デフォルト: 15分

            最大: 120分

        • 拡張オプションの表示:
          • 月次セキュリティ・インフラストラクチャ・メンテナンスの有効化: 月次セキュリティ・インフラストラクチャ・メンテナンスを実行するには、このチェック・ボックスを選択します。
      • メンテナンス・スケジュール:スケジューリング・ポリシーのメンテナンス・ウィンドウのプリファレンスを使用

        インフラストラクチャのプロビジョニング中に、スケジューリング・ポリシーを選択した後、Oracleは、インフラストラクチャ内のすべてのコンポーネントに更新を適用するための推奨メンテナンス・スケジューリング・プランを生成します。推奨計画では、期間に基づいてポリシーからメンテナンス・ウィンドウにすべてのDBサーバー、ストレージ・サーバーの順にスケジュールします。インフラストラクチャのプロビジョニング後、「メンテナンス・スケジューリング計画」リソースを編集してスケジューリング計画を更新し、スケジュール・ポリシーの異なるウィンドウに合せて特定のコンポーネントに更新をカスタマイズできます。

  11. 「メンテナンス詳細の指定」で、最大10件の一意のメンテナンス連絡先の電子メール・アドレスを指定します「連絡先の追加」をクリックします。
    「連絡先の電子メール」フィールドに、連絡先の電子メールIDを入力します。
    ノート

    少なくとも1人の連絡先が必要です。

    「連絡先の追加」をクリックして、別の連絡先を追加します。

  12. 「拡張オプションの表示」をクリックし、初期データベースの拡張オプションを指定します。

    「タグ」タブでは、データベースにタグを追加できます。定義済タグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用する必要があるかどうかがわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。

  13. 「Exadata Infrastructureの作成」をクリックします。クラウドExadataインフラストラクチャが「プロビジョニング中」ステータスで「Exadataインフラストラクチャ」リストに表示されます。インフラストラクチャのアイコンが黄色から緑(エラーを示す場合は赤)に変わります。

次の処理

クラウドExadataインフラストラクチャ・リソースが正常にプロビジョニングされ、「使用可能」ステータスになったら、クラウドVMクラスタ・リソースを作成するにはの説明に従って、インフラストラクチャにクラウドVMクラスタを作成できます。新しいExadata Cloud Infrastructureインスタンスに最初のデータベースを作成する前に、インフラストラクチャ・リソースとVMクラスタの両方をプロビジョニングする必要があります。

Exadata Cloud InfrastructureインスタンスにVMクラスタを作成します。

ノート

Exadata Cloud InfrastructureインスタンスにクラウドVMクラスタを作成するには、まずクラウドExadataインフラストラクチャ・リソースを作成しておく必要があります。

ノート

マルチVM対応インフラストラクチャでは、複数のVMクラスタの作成がサポートされます。Exadataシステムごとの複数の仮想マシン(MultiVM)の作成および管理とVMクラスタ・ノードのサブセット化の機能がリリースされる前に作成されたインフラストラクチャでは、単一のクラウドVMクラスタの作成のみがサポートされます。
  1. ナビゲーション・メニューを開きます。「Oracle Database」をクリックし、「Oracle Exadata Database Service on Dedicated Infrastructure」をクリックします
  2. 「Oracle Exadata Database Service on Dedicated Infrastructure」で、「Exadata VMクラスタ」をクリックします。
    ノート

    複数のVMクラスタは、マルチVM対応インフラストラクチャでのみ作成できます。
  3. 「Exadata VMクラスタの作成」をクリックします。

    「Exadata VMクラスタの作成」ページが表示されます。VMクラスタを構成するために必要な情報を指定します。

  4. コンパートメント: VMクラスタ・リソースのコンパートメントを選択します。
  5. 表示名: VMクラスタのユーザー・フレンドリな表示名を入力します。この名前は一意である必要はありません。Oracle Cloud Identifier (OCID)はDBシステムを一意に識別します。機密情報を入力しないでください。
  6. Exadataインフラストラクチャの選択: VMクラスタを含むインフラストラクチャ・リソースを選択します。新しいVMクラスタを作成するための十分なリソースがあるインフラストラクチャ・リソースを選択する必要があります。「コンパートメントの変更」をクリックし、作業中のコンパートメントとは別のコンパートメントを選択して、他のコンパートメントのインフラストラクチャ・リソースを表示します。
    ノート

    複数のVMクラスタは、マルチVM対応インフラストラクチャでのみ作成できます
  7. Oracle Grid Infrastructureバージョンの選択:リストから、VMクラスタにインストールするOracle Grid Infrastructureリリース(19cおよび23ai)を選択します。

    Oracle Grid Infrastructureリリースにより、VMクラスタでサポートできるOracle Databaseリリースが決まります。Oracle Grid Infrastructureソフトウェア・リリースより後のOracle Databaseリリースは実行できません。

    ノート

    Grid Infrastructure 23aiでVMクラスタをプロビジョニングするための最小要件:
    • Exadata System Software 23.1.8を実行しているExadataゲストVM
    • Exadataシステム・ソフトウェア23.1.xを実行しているExadataインフラストラクチャ
  8. Exadataイメージ・バージョンの選択:
    • Oracle Linux 7およびExadataイメージ・バージョン22.1.10.0.0.230422のExadataインフラストラクチャ:
      • 「イメージの変更」ボタンは有効になっていません。
      • Oracle Grid Infrastructureのバージョンは、デフォルトで19.0.0.0.0です。
      • Exadataゲスト・バージョンは、ホストOSのバージョンと同じです。
    • Oracle Linux 8およびExadataイメージ・バージョン23.1.3.0.0.230613のExadataインフラストラクチャ:
      • Exadataゲスト・バージョンのデフォルトは最新(23.1.3.0)です。
      • Oracle Grid Infrastructureのバージョンは、デフォルトで19.0.0.0.0になります。
      • 「イメージの変更」ボタンが有効になります。
      • 「イメージの変更」をクリックします

        結果の「変更」イメージ・パネルには、使用可能なExadataイメージのメジャー・バージョン(23.1.3.0および22.1.3.0)のリストが表示されます。

        各メジャー・バージョンの最新リリースは「(最新)」で示されます。

      • 「使用可能なすべてのバージョンの表示」をスライドします。

        Exadataイメージの最新バージョン23.1.3.0および22.1.3.0を含む6つの過去のバージョンが表示されます。

      • バージョンの選択
      • 「変更の保存」をクリックします。
  9. VMクラスタの構成: 新しいVMクラスタに使用するDBサーバーを指定します(デフォルトでは、すべてのDBサーバーが選択されています)。「DBサーバーの変更」をクリックして、使用可能なDBサーバーから選択します。「VM当たりのリソース割当て」ペインで:
    • 各VMクラスタの仮想マシン・コンピュート・ノードに割り当てるOCPU/ECPUの数を指定します。X11Mに作成されたVMクラスタの場合は、ExadataインフラストラクチャにECPUを指定します。X10M以前のExadataインフラストラクチャで作成されたVMクラスタの場合は、OCPUを指定します。最小値は、X10M以前のインフラストラクチャではVM当たり2 OCPU、X11M Exadataインフラストラクチャで作成されたVMクラスタではVM当たり8 ECPUです。読取り専用「Exadata VMクラスタに対してリクエストされたOCPU数」フィールドには、割り当てるOCPUまたはECPUコアの合計数が表示されます。
    • 各VMに割り当てるVM当たりのメモリーを指定します。VM当たりの最小値は30GBです。
    • 各VMにローカル・ストレージを割り当てるためのVM当たりのローカル・ストレージを指定します。VM当たりの最小値は60GBです。

      新しいVMクラスタを作成するたびに、使用可能な合計領域のうち残りの領域が新しいVMクラスタに使用されます。

      /u02に加えて、追加のローカル・ファイル・システムのサイズを指定できます。

      個々のVMごとのサイズを指定する方法の詳細および手順は、スケール・アップまたはスケール・ダウン操作の概要を参照してください。

      • 「追加ローカル・ファイル・システム構成オプションの表示」をクリックします。
      • 必要に応じて、//u01/tmp/var/var/log/var/log/auditおよび/homeファイル・システムのサイズを指定します。
        ノート

        • これらのファイル・システムは拡張のみ可能で、拡張後にサイズを減らすことはできません。
        • バックアップ・パーティションおよびミラー化により、/および/varファイル・システムは、割り当てられた領域の2倍を消費します。これは、読取り専用ミラー化による/(GB)の割当て済ストレージの合計およびミラー化による/tmp (GB)の割当て済ストレージの合計フィールドに示されます。
      • VMクラスタの作成後、「Exadataインフラストラクチャの詳細」ページの「Exadataリソース」セクションをチェックして、ローカル・ストレージ(/u02)およびローカル・ストレージ(追加のファイル・システム)に割り当てられたファイル・サイズを確認します。
  10. Exadataストレージの構成: 次を指定します:
    • 使用可能なExadataストレージ(TB)の指定。ストレージを1TBの倍数で指定します。最小値: 2TB
    • Exadataスパース・スナップショットのストレージの割当て: VMクラスタ内でスナップショット機能を使用する場合は、この構成オプションを選択します。このオプションを選択すると、SPARSEディスク・グループが作成され、PDBスパース・クローニングにVMクラスタ・スナップショット機能を使用できるようになります。このオプションを選択しなかった場合、SPARSEディスク・グループは作成されず、環境に作成されたデータベース・デプロイメントでスナップショット機能を使用できません。
      ノート

      スパース・スナップショットのストレージ構成オプションは、VMクラスタの作成後に変更できません。
    • ローカル・バックアップのストレージの割当て: Exadata Cloud Infrastructureインスタンス内でローカルExadataストレージへのデータベースのバックアップを実行する場合は、このオプションを選択します。このオプションを選択すると、Exadataストレージにバックアップを保存するために使用されるRECOディスク・グループに、より多くの領域が割り当てられます。このオプションを選択しない場合、より多くの領域がDATAディスク・グループに割り当てられ、データベースに多くの情報を保存できるようになります。
      ノート

      ローカル・バックアップのストレージ構成オプションは、VMクラスタの作成後に変更できません。
  11. SSHキーの追加: DBシステムへのSSHアクセスに使用する各キー・ペアの公開キー部分を追加します:
    • SSHキー・ペアの生成: (デフォルト・オプション) SSHキー・ペアを生成するには、このラジオ・ボタンを選択します。次のダイアログで、「秘密キーの保存」をクリックしてキーをダウンロードし、オプションで「公開キーの保存」をクリックしてキーをダウンロードします。
    • SSHキー・ファイルのアップロード: このラジオ・ボタンを選択して、.pubファイルを参照またはドラッグ・アンド・ドロップします。
    • SSHキーの貼付け: 個々の公開キーを貼り付けるには、このラジオ・ボタンをクリックします。複数のキーを張り付けるには、「+ 別のSSHキー」をクリックして、エントリごとに1つのキーを指定します。
  12. ネットワーク設定の構成: 次を指定します:
    ノート

    IPアドレス(100.64.0.0/10)は、Exadata Cloud Infrastructure X8Mインターコネクトに使用されます。

    両方の構成が存在する場合、IPv4 (シングル・スタック)とIPv4/IPv6 (デュアル・スタック)から選択するオプションはありません。詳細は、VCNおよびサブネットの管理を参照してください。

    • 仮想クラウド・ネットワーク: VMクラスタを作成するVCN。別のコンパートメント内のVCNを選択するには、「コンパートメントの変更」をクリックします。
    • クライアント・サブネット: VMクラスタがアタッチされるサブネット。別のコンパートメントにあるサブネットを選択するには、「コンパートメントの変更」をクリックします。

      192.168.16.16/28と重複するサブネットは使用しないでください。これはデータベース・インスタンス上のOracle Clusterwareプライベート・インターコネクトによって使用されています。重複するサブネットを指定すると、プライベート・インターコネクトが正しく機能しません。

    • バックアップ・サブネット: バックアップ・ネットワークに使用するサブネット。通常は、バックアップ保存先との間のバックアップ情報の転送およびData Guardレプリケーションに使用されます。必要に応じて、「コンパートメントの変更」をクリックして、別のコンパートメント内のサブネットを選択します。

      192.168.128.0/20と重複するサブネットは使用しないでください。この制限は、クライアント・サブネットとバックアップ・サブネットの両方に適用されます。

      データベースをオブジェクト・ストレージまたは自律型リカバリ・サービスにバックアップする場合は、Exadata Databaseバックアップの管理のネットワークの前提条件を参照してください。

      ノート

      Autonomous Recovery Serviceを使用する場合は、新しい専用サブネットを強くお薦めします。Oracle Cloudデータベースをリカバリ・サービスにバックアップするために必要なネットワーク要件および構成を確認します。リカバリ・サービスのネットワーク・リソースの構成を参照してください。
    • ネットワーク・セキュリティ・グループ: クライアント・ネットワークとバックアップ・ネットワークの両方に1つ以上のネットワーク・セキュリティ・グループ(NSG)をオプションで指定できます。NSGは仮想ファイアウォールとして機能し、イングレスおよびエグレス・セキュリティ・ルールのセットをExadata Cloud Infrastructure VMクラスタに適用できます。NSGは5つまで指定できます。詳細は、ネットワーク・セキュリティ・グループおよびExadata Cloud Infrastructureインスタンスのネットワーク設定を参照してください。

      セキュリティ・リストのあるサブネットを選択する場合、VMクラスタのセキュリティ・ルールは、セキュリティ・リストおよびNSG内のルールの論理和になります。

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

      • 「トラフィックを制御するためのネットワーク・セキュリティ・グループの使用」チェック・ボックスを選択します。このボックスは、クライアント・サブネットとバックアップ・サブネットの両方のセレクタの下に表示されます。NSGは、クライアント・ネットワークまたはバックアップ・ネットワーク、あるいはその両方に適用できます。ネットワークにNSGを割り当てるには、仮想クラウド・ネットワークを選択する必要があります。
      • ネットワークで使用するNSGを指定します。複数のNSGを使用する必要がある場合があります。不明な場合は、ネットワーク管理者に問い合せてください。
      • 追加のNSGをネットワークで使用するには、「+; 別のネットワーク・セキュリティ・グループ」をクリックします。
      ノート

      クラウドVMクラスタ・リソースに追加のセキュリティを提供するために、Oracle Cloud Infrastructureゼロ・トラスト・パケット・ルーティングを使用して、セキュリティ属性で識別されたリソースのみがリソースにアクセスするためのネットワーク権限を持っていることを確認できます。Oracleには、一般的なデータベース・セキュリティ・ユース・ケースのポリシーの作成に役立つデータベース・ポリシー・テンプレートが用意されています。今すぐ構成するには、Oracle Cloud Infrastructureゼロ・トラスト・パケット・ルーティングでセキュリティ属性がすでに作成されている必要があります。この手順の最後にある「拡張オプションの表示」をクリックします。

      クラスタのセキュリティ属性を指定する場合、クラスタが適用されるとすぐに、すべてのリソースがクラスタにアクセスするためにゼロ・トラスト・パケット・ポリシーを必要とすることに注意してください。エンドポイントにセキュリティ属性がある場合は、ネットワーク・セキュリティ・グループ(NSG)とOracle Cloud Infrastructureゼロ・トラスト・パケット・ルーティング・ポリシー(OCI ZPR)の両方のルールを満たす必要があります。

    • プライベートDNSサービスを使用するには
      ノート

      プライベートDNSは、選択する前に構成する必要があります。「プライベートDNSの構成」を参照してください
      • 「プライベートDNSサービスの使用」チェック・ボックスを選択します。
      • プライベート・ビューを選択します。別のコンパートメントにあるプライベート・ビューを選択するには、「コンパートメントの変更」をクリックします。
      • プライベート・ゾーンを選択します。別のコンパートメントにあるプライベート・ゾーンを選択するには、「コンパートメントの変更」をクリックします。
    • ホスト名接頭辞: Exadata DBシステムのホスト名の選択。ホスト名はアルファベットで始まり、英数字およびハイフン(-)のみを含めることができます。Exadata DBシステムには、最大12文字まで指定できます。

      注意:

      ホスト名はサブネット内で一意である必要があります。一意でない場合、VMクラスタはプロビジョニングに失敗します。
    • ホスト・ドメイン名: VMクラスタのドメイン名。選択したサブネットが、DNS名解決にOracle提供のInternet and VCN Resolverを使用する場合は、このフィールドにサブネットのドメイン名が表示され、変更できません。または、ドメイン名を選択できます。ハイフン(-)は使用できません。

      データベース・バックアップをオブジェクト・ストレージまたは自律型リカバリ・サービスに格納する予定の場合、Oracleでは、バックアップに使用されるSwiftエンドポイントが自動的に解決されるため、クライアント・サブネットのDNS名解決にVCN Resolverを使用することをお薦めします。

    • ホストおよびドメインURL: この読取り専用フィールドは、ホスト名とドメイン名を結合して、データベースの完全修飾ドメイン名(FQDN)を表示します。最大長は63文字です。
  13. ライセンス・タイプの選択: VMクラスタに使用するライセンスのタイプ。選択内容は従量制の請求に影響します。
    • 「ライセンス込み」は、クラウド・サービスのコストにデータベース・サービスのライセンスが含まれていることを意味します。
    • 「ライセンス持込み(BYOL)」は、無制限ライセンス契約または使用制限付きライセンス契約を契約されているOracle Databaseの顧客が、このライセンスでOracle Cloud Infrastructureを使用することを意味します。これにより、オンプレミス・ライセンスおよびクラウド・ライセンスを別々に契約する必要がなくなります。
  14. 診断収集: 診断収集および通知を有効にすることで、Oracle Cloud Operationsと顧客は、ゲストVMの問題をすばやく効率的に特定、調査、追跡および解決できます。イベントをサブスクライブして、リソース状態の変更に関する通知を受けます。
    ノート

    前述のイベント(またはメトリック、ログ・ファイル)のリストが将来変更される可能性があることを理解した上でオプト・インします。この機能はいつでもオプト・アウトできます。
    • 診断イベントの有効化: Oracleがクリティカル・イベント、警告イベント、エラー・イベントおよび情報イベントを収集および公開することを許可します。
    • ヘルス・モニタリングの有効化: OracleがOracle Databaseの起動/停止、ディスク領域の使用量などのヘルス・メトリック/イベントを収集し、Oracle Cloud operationsと共有することを許可します。一部のイベントの通知も受信します。
    • インシデント・ログおよびトレース収集の有効化: 障害診断および問題解決を可能にするためにOracleがインシデント・ログおよびトレースを収集できるようにします。
    ノート

    前述のイベント(またはメトリック、ログ・ファイル)のリストが将来変更される可能性があることを理解した上でオプト・インします。この機能はいつでもオプトアウトできます。
    デフォルトでは、3つのチェック・ボックスがすべて選択されています。デフォルト設定をそのままにすることも、必要に応じてチェックボックスを選択解除することもできます。診断収集の設定は、「VMクラスタの詳細」ページの「一般情報」>>「診断収集」の下に表示されます。
    • 有効: 診断、ヘルス・メトリック、インシデント・ログとトレース・ファイル(3つのオプションすべて)の収集を選択した場合。
    • 無効: 診断、ヘルス・メトリック、インシデント・ログとトレース・ファイル(3つのオプションすべて)を収集しないことを選択した場合。
    • 一部有効: 診断、ヘルス・メトリック、インシデント・ログとトレース・ファイル(1つまたは2つのオプション)の収集を選択した場合。
  15. 「拡張オプションの表示」をクリックし、VMクラスタの拡張オプションを指定します:
    • タイム・ゾーン: このオプションは、「管理」タブにあります。DBシステムのデフォルトのタイム・ゾーンはUTCですが、別のタイム・ゾーンを指定できます。タイム・ゾーン・オプションは、Java.util.TimeZoneクラスとOracle Linuxオペレーティング・システムの両方でサポートされています。詳細は、DBシステムのタイム・ゾーン を参照してください。

      ノート

      UTCまたはブラウザが検出したタイム・ゾーン以外のタイムゾーンを設定する場合に、目的のタイム・ゾーンが表示されない場合は、「別のタイム・ゾーンの選択」を選択し、「地域または国」リストで「その他」を選択して、追加のタイム・ゾーンの選択肢を検索してみてください。

    • SCANリスナー・ポート: このオプションは、「ネットワーク」タブにあります。SCANリスナー・ポート(TCP/IP)は、1024から8999の範囲で割り当てることができます。デフォルトは1521です
      ノート

      バックエンド・ソフトウェアを使用したプロビジョニング後にVMクラスタのSCANリスナー・ポートを手動で変更することはサポートされていません。この変更により、Data Guardのプロビジョニングが失敗する可能性があります。
      .
    • Zero Trust Packet Routing (ZPR): このオプションは、「セキュリティ属性」タブにあります。ネームスペースを選択し、セキュリティ属性のキーと値を指定します。構成中にこのステップを完了するには、Oracle Cloud Infrastructureゼロ・トラスト・パケット・ルーティングでセキュリティ属性をすでに設定している必要があります。構成後にセキュリティ属性を追加し、後で追加することもできます。Oracle Exadata Database Service on Dedicated Infrastructure固有のポリシーの追加の詳細は、ポリシー・テンプレート・ビルダーを参照してください。
    • クラウド自動化の更新: Oracleは、クラウドのツールと自動化に必要なデータベース・ツールとエージェント・ソフトウェアに更新を定期的に適用します。VMクラスタに適用するこれらの更新の優先時間ウィンドウを構成できます。

      クラウド自動化の更新の開始時間を設定します。

      ノート

      Oracleは、構成された時間枠の間にVM Cloud Automationの最新の更新を毎日チェックし、該当する場合は更新を適用します。基礎となる長時間実行プロセスのために、構成された時間枠内で自動化による更新の適用を開始できない場合、Oracleは、構成された時間枠の翌日を自動的にチェックして、VMクラスタへのクラウド自動化更新の適用を開始します。

      クラウド・ツール更新の早期アクセスの有効化:早期アクセス用に指定されたVMクラスタは、他のシステムで使用可能になる1-2週間前に更新を受け取ります。このVMクラスタを早期に導入する場合は、このチェック・ボックスを選択します。

      クラウド自動化の更新の凍結期間: Oracleは、クラウドのツールおよび自動化に必要なデータベース・ツールおよびエージェント・ソフトウェアに更新を定期的に適用します。凍結期間を有効にして、Oracle自動化がクラウド更新を適用しない期間を定義します。

      スライダを移動してフリーズ期間を設定します。

      ノート

      • 凍結期間は、開始日から最大45日間延長できます。
      • Oracle自動化では、構成された凍結期間中でも、重要なセキュリティ修正(CVSS >= 9)を使用して更新が自動的に適用されます。
    • タグ: リソースを作成する権限がある場合、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済タグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
  16. 「作成」をクリックします。

次の処理

VMクラスタが正常に作成され、「使用可能」状態で、
  • 「VMクラスタ詳細」ページを表示するには、クラスタのリストでVMクラスタの名前をクリックします。「VMクラスタ詳細」ページで、「データベースの作成」をクリックしてクラスタ内に最初のデータベースを作成できます
  • VMクラスタの詳細ページの「ネットワーク」セクションの「SCAN IPアドレス(IPv4)」および「SCAN IPアドレス(IPv6)」フィールドに、デュアル・スタックIPアドレスの詳細が表示されます。
  • VMクラスタの詳細ページの「バージョン」セクションの「クラウド自動化の更新」フィールドに、設定した凍結期間が表示されます。

クラウド自動化更新の管理

  1. 「Exadata VMクラスタの詳細」ページで、「その他のアクション」「クラウド自動化の更新の管理」の順に選択します。
  2. 結果の「クラウド自動化更新の管理」ページで、「凍結期間の構成」スライダを移動して無効にします。
  3. 「保存」をクリックします。
  4. 「凍結期間の取消」ダイアログで、「凍結期間の取消」をクリックして確認します

    Oracle自動化では、新しい凍結期間を構成する前に、保留中の更新を適用するために7日以上が必要です。前の凍結期間の取消日から7日から始まる新しい凍結期間を設定できます。

    クラウド自動化の更新は、構成済期間中(使用可能な場合)に適用されます。

  1. 「データVMクラスタの詳細」ページで、「その他のアクション」「クラウド自動化の更新の管理」の順に選択します。

    (または)

    「バージョン」セクションのクラウド自動化更新の「編集」リンクをクリックします。

  2. 結果の「クラウド自動化更新の管理」ページで、「凍結期間の構成」スライダを移動して有効にします。
    ノート

    凍結期間の期限が切れる(終了日に達した)か、凍結期間が取り消されると、Oracle自動化では、凍結期間がクラスタで再度有効化される前に、保留中の更新を7日間適用する必要があります。
  3. 「保存」をクリックします。

凍結期間をいつでも更新して、凍結期間開始日から最大45日まで延長できます。

  1. 「Exadata VMクラスタの詳細」ページで、「その他のアクション」「クラウド自動化の更新の管理」の順に選択します。
  2. 結果の「クラウド自動化更新の管理」ページで、「凍結期間スライダの構成」を移動して有効にします。
    ノート

    凍結期間は、凍結期間開始日から最大45日間延長できます。
  3. 「保存」をクリックします。

リカバリ・サービスのネットワーク・リソースの構成

リカバリ・サービス操作には、データベースVCN内の既存のIP4のみのサブネットを使用します。データベースとリカバリ・サービス間のバックアップ・トラフィックを制御するセキュリティ・ルールを定義します。最後に、プライベート・サブネットをリカバリ・サービス・サブネットとして登録します。

リカバリ・サービスのプライベート・サブネットの使用について

リカバリ・サービスは、データベースが存在する仮想クラウド・ネットワーク(VCN)内のプライベート・サブネットを使用します。プライベート・サブネットは、データベースとリカバリ・サービス間のバックアップのネットワーク・パスを定義します。

Oracleでは、データベースVCNに、リカバリ・サービスへのバックアップ専用の単一のプライベート・サブネットが必要です。Oracle Cloudデータベースは、Recovery Serviceによって使用されるのと同じプライベート・サブネット、または同じVCN内の別のサブネットに配置できます。

プライベート・サブネットを作成することも、データベースVCN内の既存のサブネットを使用することもできます。Oracleでは、/24 (256 IPアドレス)のサブネット・サイズを使用することをお薦めします。

ノート

データベースVCNのリカバリ・サービス用のIPv4専用サブネットを選択します。リカバリ・サービスではIPv6対応サブネットの使用がサポートされていないため、IPv6対応サブネットを選択しないでください。詳細は、サブネットの作成を参照してください。

データベースVCNでは、データベースとリカバリ・サービス間のバックアップ・トラフィックを許可するセキュリティ・ルールが必要です。セキュリティ・ルールには、宛先ポート8005および2484を許可するステートフル・イングレス・ルールを含める必要があります。次のネットワーキング・サービス機能を使用して、セキュリティ・ルールを実装できます:

  • セキュリティ・リスト

    セキュリティ・リストを使用すると、サブネット・レベルでセキュリティ・ルールを追加できます。データベースVCNで、リカバリ・サービス・サブネットに使用されるセキュリティ・リストを選択し、宛先ポート8005および2484を許可するイングレス・ルールを追加します。

  • ネットワーク・セキュリティ・グループ(NSG)ネットワーク・セキュリティ・グループ(NSG)を使用すると、VCN内の個々のVNICに適用されるセキュリティ・ルールをきめ細かく制御できます。リカバリ・サービスでは、NSGを使用してセキュリティ・ルールを構成する次のオプションがサポートされています:
    • ネットワーク分離を実装するには、データベースVNICにNSGを1つ(ポート2484および8005を許可するエグレス・ルールを追加)作成し、リカバリ・サービスには別のNSGを作成します(ポート2484および8005を許可するイングレス・ルールを追加します)。
    • データベースVNICおよびリカバリ・サービスに対して単一のNSG (エグレスおよびイングレス・ルールを含む)を作成および使用します。
ノート

データベースVCN内にセキュリティ・リストおよびNSGを構成した場合、NSGで定義されたルールはセキュリティ・リストで定義されたルールよりも優先されます。

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

データベースVCNでプライベート・サブネットを作成した後、セキュリティ・ルールを割り当て、そのサブネットをリカバリ・サービスでリカバリ・サービス・サブネットとして登録します。セキュリティ・ルールを実装するためにNSGを作成した場合は、リカバリ・サービスNSGをリカバリ・サービス・サブネットに関連付けることも確認する必要があります。

ノート

Oracleでは、バックアップにプライベート・サブネットを使用することをお薦めします。ただし、パブリック・サブネットを使用することは可能です。

サブネットを構成するためのネットワーキング・サービス権限の確認

データベースVCNにサブネットを作成し、リカバリ・サービスのセキュリティ・ルールを割り当てるには、次のネットワーキング・サービス権限が必要です。

表4-6プライベート・サブネットの作成およびリカバリ・サービスのセキュリティ・ルールの構成に必要なネットワーキング・サービス権限

操作 必要なIAMポリシー

データベースVCN内のプライベート・サブネットの構成

  • VCNが存在するコンパートメントに対するuse vcns
  • VCNが存在するコンパートメントに対するuse subnets
  • VCNが存在するコンパートメントに対するmanage private-ips
  • VCNが存在するコンパートメントに対するmanage vnics
  • データベースがプロビジョニングされているかプロビジョニングされる予定のコンパートメントに対するmanage vnics

または、ネットワーク・コンポーネントへのより広範なアクセスを持つ指定されたグループを許可するポリシーを作成できます。

たとえば、このポリシーを使用して、NetworkAdminグループがテナンシ内の任意のコンパートメント内のすべてのネットワークを管理できるようにします。

例4-1ネットワーク管理者のポリシー

Allow group NetworkAdmin to manage virtual-network-family in tenancy

リカバリ・サービス・サブネットのサブネット・サイズ要件およびセキュリティ・ルールの確認

セキュリティ・ルールは、データベースとリカバリ・サービス間のバックアップ・トラフィックを許可するために必要です。

ノート

データベースVCNのリカバリ・サービス用のIPv4専用サブネットを選択します。リカバリ・サービスではIPv6対応サブネットの使用がサポートされていないため、IPv6対応サブネットを選択しないでください。詳細は、サブネットの作成を参照してください。

表4-7リカバリ・サービスで使用されるプライベート・サブネットのサブネット・サイズ要件およびイングレス・ルール

項目 要件

サブネットの最小サイズ

/24 (256 IPアドレス)

一般イングレス・ルール1: すべての場所からのHTTPSトラフィックの許可

このルールでは、Oracle Cloud Infrastructure DatabaseからRecovery Serviceへのバックアップ・トラフィックが許可されます。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: データベースが存在するVCNのCIDR
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 8005

一般イングレス・ルール2: SQLNetの任意の場所からのトラフィックを許可する

このルールでは、リカバリ・カタログ接続およびOracle Cloud Infrastructure Databaseからリカバリ・サービスへのリアルタイム・データ保護が許可されます。

  • ステートレス: いいえ(すべてのルールはステートフルである必要があります)
  • ソース・タイプ: CIDR
  • ソースCIDR: データベースが存在するVCNのCIDR
  • IPプロトコル: TCP
  • ソース・ポート範囲: すべて
  • 宛先ポート範囲: 2484
ノート

ネットワーク・セキュリティ・グループ(NSG)を使用してセキュリティ・ルールを実装する場合、またはデータベースVCNがサブネット間のネットワーク・トラフィックを制限する場合は、データベースNSGまたはサブネットから作成したリカバリ・サービスNSGまたはサブネットにポート2484および8005のエグレス・ルールを必ず追加してください。

OCIコンソールを使用して、データベース仮想クラウド・ネットワーク(VCN)のリカバリ・サービスのプライベート・サブネットを構成します。

  1. ナビゲーション・メニューで、「ネットワーキング」「仮想クラウド・ネットワーク」の順に選択して、「Virtual Cloud Networks」ページを表示します。
  2. データベースが存在するVCNを選択します。
  3. セキュリティ・リストを含むリカバリ・サービス・サブネットを作成するには、次のステップを使用します。ネットワーク・セキュリティ・グループの使用を選択した場合は、ステップ4に進みます。
    1. 「リソース」で、「セキュリティ・リスト」を選択します。
    2. VCN.Youに使用するセキュリティ・リストを選択し、宛先ポート8005および2484を許可するために2つのイングレス・ルールを追加する必要があります。
    3. 「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのHTTPSトラフィックを許可するステートフル・イングレス・ルールを設定します:
      • コード・タイプ: CIDR
      • ソースCIDR: データベースが存在するVCNのCIDRを指定します。
      • IPプロトコル: TCP
      • ソース・ポート範囲: すべて
      • 宛先ポート範囲: 8005
      • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
    4. 「イングレス・ルールの追加」をクリックし、次の詳細を追加して、任意の場所からのSQLNetトラフィックを許可するステートフル・イングレス・ルールを設定します:
      • コード・タイプ: CIDR
      • ソースCIDR: データベースが存在するVCNのCIDRを指定します。
      • IPプロトコル: TCP
      • ソース・ポート範囲: すべて
      • 宛先ポート範囲: 2484
      • 説明: セキュリティ・ルールの管理に役立つイングレス・ルールの説明(オプション)を指定します。
      ノート

      データベースVCNのリカバリ・サービスのIPv4のみのサブネットを選択します。リカバリ・サービスではIPv6対応サブネットの使用がサポートされていないため、IPv6対応サブネットを選択しないでください。詳細は、「サブネットの作成」を参照して、more.See: リカバリ・サービス・サブネットのサブネット・サイズ要件およびセキュリティ・ルールの確認を参照してください。

    5. 「Virtual Cloud Networksの詳細」ページで、「サブネットの作成」をクリックします。
    6. プライベート・サブネットを作成するか、データベースVCNにすでに存在するプライベート・サブネットを選択します。Oracleでは、プライベート・サブネットのサブネット・サイズ/24 (256 IPアドレス)をお薦めします。
    7. 「サブネットの詳細」ページの「リソース」で、「セキュリティ・リスト」を選択します。宛先ポート8005および2484を許可するイングレス・ルールを含むセキュリティ・リストを追加します。

      ノート

      データベースVCNがサブネット間のネットワーク・トラフィックを制限する場合は、データベース・サブネットから作成したリカバリ・サービス・サブネットにポート2484および8005のエグレス・ルールを追加してください。
  4. 次のステップを使用して、ネットワーク・セキュリティ・グループ(NSG)を含むリカバリ・サービス・サブネットを作成します。
    1. 「リソース」で、「ネットワーク・セキュリティ・グループ」を選択します。
    2. 「ネットワーク・セキュリティ・グループの作成」をクリックします。NSGを使用してセキュリティ・ルールを構成するには、次のサポートされている方法のいずれかを使用します:
      • ネットワーク分離を実装するには、データベースVNICにNSGを1つ(ポート2484および8005を許可するエグレス・ルールを追加)作成し、リカバリ・サービスには別のNSGを作成します(ポート2484および8005を許可するイングレス・ルールを追加します)。
      • データベースVNICおよびリカバリ・サービスに対して単一のNSG (エグレスおよびイングレス・ルールを含む)を作成および使用します。
      「ネットワーク・セキュリティ・グループ」ページには、作成するNSGがリストされます。
    ノート

    追加の構成の詳細は、関連するOCI Database Serviceのドキュメントを参照してください。
  5. データベースVCNにリカバリ・サービス・サブネットを作成した後、そのサブネットをリカバリ・サービス・サブネットとして登録します。Oracleでは、NSGを使用してセキュリティ・ルールを実装したVCN.Ifごとに1つのリカバリ・サービス・サブネットを登録してから、リカバリ・サービスNSGをリカバリ・サービス・サブネットに追加することも確認する必要があります。
リカバリ・サービス・サブネットの登録

データベースVCNでリカバリ・サービスのプライベート・サブネットを作成した後、この手順を使用して、サブネットをリカバリ・サービスに登録します。

複数の保護されたデータベースで、同じリカバリ・サービス・サブネットを使用できます。リカバリ・サービス・プライベート・エンドポイントをサポートするために必要な数のIPアドレスが使用可能であることを確認するために、複数の保護されたデータベースで使用されるリカバリ・サービス・サブネットに複数のサブネットを割り当てることができます。

ノート

データベースVCNのリカバリ・サービス用のIPv4専用サブネットを選択します。リカバリ・サービスでは、次の前提条件の構成タスクを完了したIPv6対応のsubnet.Ensureの使用がサポートされていないため、IPv6対応サブネットを選択しないでください。
  1. OCIテナンシにログインします。
  2. ナビゲーション・メニューで、「Oracle Database」をクリックし、「データベース・バックアップ」を選択して「データベース・バックアップ」ページを表示します。
  3. 「リカバリ・サービス・サブネット」をクリックします。
  4. 「コンパートメント」フィールドで、リカバリ・サービス・サブネットを作成するコンパートメントを選択します。
  5. 「リカバリ・サービス・サブネットの登録」をクリックし、詳細を指定します。
  6. 「名前」フィールドで、リカバリ・サービス・サブネットの名前を入力します。
  7. 「コンパートメント」フィールドで、リカバリ・サービス・サブネットを作成するコンパートメントを選択します。
  8. 「仮想クラウド・ネットワーク」フィールドで、データベースVCN.Click「コンパートメントの変更」を選択して、別のコンパートメントに属するVCNを選択します。
  9. 「サブネット」フィールドで、データベースのリカバリ・サービス操作用に構成したプライベート・サブネットVCN.Click 「コンパートメントの変更」を選択して、別のコンパートメントからプライベート・サブネットを選択します。
  10. (オプション)+Anotherサブネットをクリックして、リカバリ・サービスsubnet.Ifに追加のサブネットを割り当てます。単一のサブネットには、リカバリ・サービスのプライベート・エンドポイントをサポートするための十分なIPアドレスが含まれていないため、複数のサブネットを割り当てることができます。
  11. これらの追加機能を構成するには、「拡張オプションの表示」をクリックします。
    • ネットワーク・セキュリティ・グループ
    • タグ

    ネットワーク・セキュリティ・グループ(NSG)を使用してデータベースVCNのリカバリ・サービスのセキュリティ・ルールを実装した場合は、リカバリ・サービスNSGをリカバリ・サービス・サブネットに追加する必要があります。リカバリ・サービスNSGは、同じコンパートメントまたは別のコンパートメントに配置できます。ただし、NSGは、指定されたサブネットが属する同じVCNに属している必要があります。

    1. 「ネットワーク・セキュリティ・グループ」セクションで、「ネットワーク・セキュリティ・グループを使用してトラフィックを制御」を選択します。
    2. データベースVCNに作成したリカバリ・サービスNSGを選択します。
    3. +Anotherネットワーク・セキュリティ・グループをクリックして、複数のNSGを関連付けます(最大5つ)。
    (オプション)「タグ・ネームスペース」フィールドでは、タグ・ネームスペースの追加または既存のタグ・ネームスペースによるコントロールのタグ付けを検討します。
  12. 「登録」をクリックします。

    サブネットを置き換えるか、サブネットをさらに追加して、必要な数のプライベート・エンドポイントをサポートできます。

  13. 既存のリカバリ・サービス・サブネットを更新するには、次のステップを使用します:
    1. リカバリ・サービス・サブネットの詳細ページの「リソース」で、「サブネット」をクリックします。
    2. 「サブネットの追加」をクリックして、追加するサブネットを選択します。
    3. 既存のサブネットを置き換えるには、「アクション」メニューをクリックし、「サブネットの削除」を選択します。その後、別のサブネットを追加できます。
    ノート

    リカバリ・サービス・サブネットは、データベースVCNに属する少なくとも1つのサブネットに関連付けられている必要があります。
  14. 既存のリカバリ・サービス・サブネットのネットワーク・セキュリティ・グループ(NSG)を管理するには、次のステップを使用します:
    1. 「ネットワーク・セキュリティ・グループ」セクションで、「ネットワーク・セキュリティ・グループの追加」をクリックします。
    2. リカバリ・サービスのネットワーク・セキュリティ・グループを選択して追加します(最大5つ)。
    3. NSGを削除するには、リソースを選択して「削除」をクリックします。

Autonomous Recovery Serviceのチェックリスト

リカバリ・サービス・サブネットがOracle Servicesと通信できることの確認

登録したリカバリ・サービス・サブネットは、リカバリ・サービスと通信する必要があります。

サービスにアクセスするには、プライベート・サブネットのルーティング表に「Oracle Services NetworkのすべてのIADサービス」を含める必要があります。

詳細は、Oracle Servicesへのプライベート・アクセスを参照してください。

データベースにTDEが完全に構成されていることの確認

Autonomous Recovery Serviceを使用する場合、データベースを完全にTDE暗号化する必要があります。

クラウドに生まれた新しいデータベースの場合、これはすでに完了している必要があります。ただし、OCIでスタブ・データベースを作成し、オンプレミスまたは他の場所からOracle Database Serviceにデータベースを移行する場合、すべての基準を満たすとはかぎりません。これらのデータベースでは、リカバリ・サービスへのバックアップの前提条件を満たしていることを確認する必要があります。

次の3つの基準を満たす必要があります。
  • データベースでWALLET_ROOTを構成する必要があります。まだsqlnet.oraを使用している場合は、dbaascliを使用して、リカバリ・サービスを使用するすべてのデータベースにWALLET_ROOTを正しく設定する必要があります。
    既存のデータベースのwallet_root SPFILEパラメータを有効にするには、次を実行します。
    dbaascli tde enableWalletRoot

    詳細は、dbaascli tde enableWalletRootを参照してください。

    ノート

    sqlnet.oraでのENCRYPTION_WALLET_LOCATIONの設定はサポートされていないため、非推奨になります。
  • CDBおよびデータベース内のすべてのPDBに暗号化キーを設定する必要があります。
  • 最初のバックアップを実行する前に、すべての表領域をTDE暗号化する必要があります。
手動操作バックアップをオフにする

場合によっては、OCIユーザーが手動の操作バックアップを実行します。これらのバックアップは、標準ツールの外部で実行され、Point-in-Timeリカバリ(非KEEPバックアップ)をサポートします。

これらのタイプの操作バックアップを実行している場合は、この時点でオフにすることが重要です。2つの異なる場所に操作バックアップを実行すると、両方のバックアップで問題が発生する可能性があります。

ノート

オブジェクト・ストレージのバックアップにツールを使用していて、リカバリ・サービスに切り替えると、ツールによってスイッチオーバーが自動化され、以前のすべてのバックアップが使用可能なままになります。