1. Zero Downtime Migrationを使用したOracle Cloudへの移行
  2. 必要な接続の構成

3 必要な接続の構成

Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバー間に接続を設定する必要があります。

ノート:

ホスト・レベルの認証ユーザーに対するumask設定では、umaskを022に設定する必要があります。たとえば、zdmuserがソースまたはターゲットに対する認証ユーザーである場合は、zdmuserのumaskが022に設定されている必要があります。

3.1 SSHアクセスを使用しない論理移行

SSH資格証明を要求せずに、ターゲット・データベース・サーバー・ホストへの論理移行を実行できます。

  • ZDMは、ダンプのアップロードおよびダウンロードを処理するSSHアクセスを使用しないで論理ワークフローを実行します。
  • Zero Downtime Migrationによってリモートでクラウド移行前アドバイザ・ツール(CPAT)による検証が実行されるようにするには、レスポンス・ファイル・パラメータRUNCPATREMOTELY=TRUEを設定します。「RUNCPATREMOTELY」を参照してください。
  • ZDMでは、ソース・データベースまたはターゲット・データベースへのJDBC接続を介して、CPATをZDMノード(前述のZDMサービス・ホストと呼ばれます)からリモートで起動できます。

OSSへのダンプの転送を伴う移行の場合、ZDMはHTTPS経由でダンプを自動転送します。

このHTTPS接続を実現するには、ソース・データベース・ホストで次のステップを実行する必要があります:

  • HTTPSアクセス用にSSL_WALLETを設定します: 証明書を使用したSSL Walletの作成を参照してください。
  • DUMPTRANSFERDETAILS_SOURCE_OCIWALLETLOCパラメータを使用して、ZDMジョブへのこのウォレット・パスを指定します。
  • ネットワークACLの設定: エクスポートまたはインポートを実行するユーザーは、ソースおよびターゲット・データベース・ホストからネットワークにアクセスするために必要なネットワークACLを付与する必要があります。ネットワークACLの設定方法を参照してください

ソース・データベース・サーバーの場合:

次のパラメータは、ソース・ノードのSSLウォレット・パスを示します:

  • DUMPTRANSFERDETAILS_SOURCE_NOSSHUPLOADMETHOD
  • DUMPTRANSFERDETAILS_SOURCE_OCIWALLETLOC

ターゲット・データベース・サーバーの場合:

次のパラメータは、ターゲット・ノードのSSLウォレット・パスを示します:
  • DUMPTRANSFERDETAILS_TARGET_NOSSHUPLOADMETHOD
  • DUMPTRANSFERDETAILS_TARGET_OCIWALLETLOC

関連トピック

3.2 SSHアクセスを使用した物理移行および論理移行

databaseユーザーおよびsudo特権ユーザーによるSSHアクセスを使用して、物理移行および論理移行を実行し、データベースをソースからターゲットに移行できます。

関連トピック

3.2.1 データベース・ユーザー権限による移行

ソースおよびターゲット・データベース・ノードでoracleユーザーとして実行されるすべてのアクションにより、データベースをソースからターゲットに移行できます。アクションを実行するために特権ユーザー・アクセスは必要ありません。

dbuser認証プラグインの使用:

認証ユーザーと、指定したユーザーがソース・データベース・サーバーに接続して移行を実行するためのアイデンティティ・ファイルを指定できます。

ノート:

dbuserとしてデータベース・ユーザー・プラグインを使用して論理移行を実行するには、RUNCPATREMOTELYパラメータの値をTRUEに設定する必要があります。

次の引数が必要です:

  • user: Oracle db user - 移行アクションを実行できるOracle Databaseユーザー名を指定します。たとえば、user:oracleは、物理移行ワークフローの一部として必要なGrid Infrastructure (GI)アクションを実行できます。
  • identity_file: Oracle db user SSH private key file - 指定したソース・ノードまたはターゲット・ノードに対するSSH接続を可能にする、指定したOracle Databaseユーザー名の秘密キー・ファイルを指定します。たとえば、identity_file:/home/zdmnode/keys/source_ssh_private_key.fileです。
  1. 認証プラグイン-srcauthまたは-tgtauthをdbuserとして選択し、認証ユーザーを指定します。
  2. 指定したユーザーがソース・データベース・サーバーまたはターゲット・データベース・サーバーにそれぞれ接続し、移行を実行するためのファイルを特定します。
  3. migrateコマンドで次の引数を使用して、dbuser認証プラグインをサポートします:
    • ソース・ノード・アクセス: ZDMCLI migrateコマンドで次のパラメータを指定します:
      -srcauth dbuser 
    -srcarg1 user:username  
    -srcarg2 identity_file:Oracle user private_ssh_key.file
    • ターゲット・ノード・アクセス: ZDMCLI migrateコマンドで次のパラメータを指定します:
      -tgtauth dbuser 
    -tgtarg1 user:target_database_server_login_user_name  
    -tgtarg2 identity_file:Oracle user private_ssh_key.file

論理移行を実行するためのdbuserプラグインの使用

ZDMでは、ソースとターゲットの両方のノード・アクセスに対して権限のないユーザーがサポートされます。

ソースおよびターゲット・データベース・サーバーのホストで移行に必要なすべてのアクションを実行するには、認証に指定されたdbuserを許可する必要があります。

物理移行を実行するためのdbuserプラグインの使用

物理的移行の制限: 物理的移行は、ソース・データベース・サーバーへのアクセスと、ターゲット・ノードへの条件付きのアクセスがサポートされます。詳細は次のとおりです:
  • ソース・データベース・サーバー・ホストで移行に必要なすべてのアクションを実行するには、認証に指定されたdbuserを許可する必要があります。
  • OCIターゲット・データベース・サーバーの場合 - dbuser認証プラグインはサポートされていません。常に特権ユーザーが必要です。zdmauthを使用する必要があります。
  • 非クラウド・ターゲット・データベース・サーバーの場合、物理移行でターゲット・データベースにdbuserを使用するには、Oracle Grid Infrastructure (GI)とOracle Database (DB)が同じユーザーが所有する必要がある場合、ターゲット・データベースは、ロールが分かれていない必要があります。
  • ソース・データベース・サーバーの場合、Grid Infrastructureユーザーおよびデータベース・ユーザーにロール分離がない場合、次のいずれかのケースが適用可能であることを確認してください。dbuserとgrid userが同じで、Oracle DatabaseパスワードまたはTDEウォレットがASMにない場合、次のアクションは必要ありません:
    • Grid Infrastructureおよびデータベースがロール別になっていて、Oracle DatabaseパスワードまたはTDEウォレットがASM上にある場合は、パスワードまたはTDEウォレットをASMからdbuserアクセス用のセキュアなローカル・ファイル・システム・パスにコピーします。
    • コピーしたウォレットが保護され、dbuserのみにアクセスが制限されており、移行アクションの完了後にはウォレットが削除されるようにします。
    • TDEウォレットまたはOracle DatabaseをASMからローカル・ファイル・システムにコピーする場合は、SRC_DB_PASSWORDFILE_LOCSRC_DB_PASSWORDFILE_LOCおよびSRC_DB_TDE_WALLET_LOCSRC_DB_TDE_WALLET_LOCパラメータにそれぞれパスを指定します。

移行コマンドの例: 

$ZDM_HOME/bin/zdmcli migrate database -rsp file_name  -sourcesid source_oracle_sid
-sourcenode source_database_server_name 
  -srcauth dbuser
    -srcarg1 user:username
    -srcarg2 identity_file:ssh_key_path
-targetnode target_database_server_name
  -tgtauth dbuser
    -tgtarg1 user:target_database_server_login_user_name
    -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location

3.2.2 SUDOユーザー権限による移行

場合によっては、ソースおよびターゲットのデータベース・サーバーでsudoを使用して操作を実行するための権限を特定のユーザーに付与する必要があります。

SUPERUSER権限昇格なしでsudoユーザーとしてソースおよびターゲット・データベース・ノードでのアクションをすべて実行してデータベースをソースからターゲットに移行できます。認証引数user:<auth_user>で指定されたユーザーは、SSHを介してデータベース・ホストに接続するために使用されます。実行されるアクションでは、SU (スーパーユーザー)アクセス、またはデータベース・ユーザーを介した直接SSHは想定されていません。

ノート:

これはオプションの方法であり、ロール別のケースに適用される「SSHキー・ベースの認証の設定」に代わる方法として使用できます。

これらのステップは、ソースまたはターゲット(あるいはその両方)がSSHキー(共同管理データベース)を使用してアクセスされる物理移行および論理移行に適用できます。

これらのステップは、ターゲットがAutonomous Databaseである論理移行では適用できません。

ノート:

新しい認証プラグインsudoasuserは、論理移行の場合のみ使用できます。

ご使用の環境でデータベース・ユーザーへのSSHアクセスがロックされている場合やスーパーユーザーになるための権限がSudoユーザーに付与されていない場合が対象になります。

ソース・データベース・サーバーの場合:

  • ソース・データベース・サーバーにrootユーザーでアクセスする場合、sudo権限を構成する必要はありません。

  • ソース・データベース・サーバーにroot以外のユーザー、database以外のユーザーを介してアクセスする場合は、パスワードを要求されずにdatabaseユーザーとして移行アクションを実行できるように、sudo権限を構成します。

ターゲット・データベース・サーバーの場合:

  • ターゲット・データベース・サーバーがクラウド上にある場合、sudo権限はすでに構成されています。それ以外の場合は、データベース・インストール・ユーザーおよびrootユーザーのパスワードを要求されずに実行されるようにすべてのsudo権限を構成します。

    ターゲット・データベース・サーバーにroot以外のユーザー、database以外のユーザーを介してアクセスする場合は、パスワードを要求されずにdatabaseユーザーとして移行アクションを実行できるように、sudo権限を構成します。

論理移行の場合のsudoasuser認証プラグインの使用

SUPERUSER権限昇格なしでsudoユーザーとしてソースおよびターゲット・データベース・ノードでのアクションをすべて実行してデータベースをソースからターゲットに移行できます。認証引数user:<auth_user>で指定されたユーザーは、SSHを介してデータベース・ホストに接続するために使用されます。実行されるアクションでは、SU (スーパーユーザー)アクセス、またはデータベース・ユーザーを介した直接SSHは想定されていません。

認証プラグイン: 'sudoasuser'

このプラグインでは、指定したユーザーがソース・データベース・サーバーに接続しsudoを使用してデータベース・ユーザーになり移行アクションを実行できるようにするために、認証ユーザーasuserを指定する引数、およびアイデンティティ・ファイルを指定する引数が提供されます。

次に、必要な引数を示します

user:<auth_user>

この引数により、リモート・ソース・ノードへの接続に使用する認証ユーザー名を指定します。

'asuser:' <Sudoユーザー>

この引数では、sudoの実行によりOracle Databaseユーザーになり移行アクションを実行できるようにする、sudoユーザー名を指定します。たとえば、user:zdmuserはsudo oracleを実行できます(物理移行の場合はGridユーザーになります)。物理移行の場合、指定したユーザーは、sudoによってGIユーザーになり、移行ワークフローの一環で必要になるすべてのGrid Infrastructure (GI)アクションを実行できるようになります。

'identity_file:' <SudoユーザーのSSH秘密キー・ファイル>

この引数では、指定したソース・ノードに対するSSH接続を許可する指定した認証ユーザー名のための秘密キー・ファイルを指定します。たとえば、identity_file:/home/zdmnode/keys/source_ssh_private_key.fileです。

次に、migrateコマンドの例を示します:
zdmcli migrate database 
-sourcedb db_name 
-sourcenode source_host_name 
-srcauth sudoasuser
 -srcarg1 user:source_database_server_login_user_name 
-srcarg2 asuser:source_database_server_login_user_name  
-srcarg3 identity_file:ZDM_installed_user_private_key_file_location 
-srcarg4 sudo_location:/usr/bin/sudo 
-targetnode target_host_name
-backupuser Object_store_login_user_name 
-rsp response_file_location 
-tgtauth zdmauth 
-tgtarg1 user:target_database_server_login_user_name 
-tgtarg2 identity_file:ZDM_installed_user_private_key_file_location
-tgtarg3 sudo_location:/usr/bin/sudo -tdekeystorepasswd -tgttdekeystorepasswd

次の例に、認証プラグインを使用し、certsを介したホスト・アクセス用のサンプル・コマンドを示します。

ノート:

sudoアクセス権を持つユーザーには-srcauth zdmauthを使用し、sudo以外のユーザーには-tgtauth dbuserを使用します(またはその逆にします)。 
$ZDM_HOME/bin/zdmcli migrate database 
-sourcedb source_db_unique_name_value
-rsp response_file_location
  -sourcenode <nodename  e.g., dbserver or IP
      address>  
    -srcauth zdmauth 
    -srcarg1  user:username
    -srcarg2 identity_file:<user key path on
      zdm host e.g. /keys/id.rsa> 
    -srcarg3 sudo_location:/usr/bin/sudo  
   -targetnode target_database_server_name
    -tgtauth dbuser 
    -tgtarg1  user:target_database_server_login_user_name 
    -tgtarg2 identity_file:ZDM_installed_user_private_key_file_location

3.3 Zero Downtime Migrationのポートの要件

Zero Downtime Migrationサービス・ホスト、ソースおよびターゲットのデータベース・サーバー、Oracle Cloud Object Storeサービス間の通信に必要なポートは、次の表を参照してください。

表3-1 Zero Downtime Migrationの通信ポート

イニシエータ ターゲット プロトコル ポート 用途 説明
Zero Downtime Migrationサービス・ホスト ソースおよびターゲットのデータベース・サーバー TCP 22 SSH Zero Downtime Migrationの操作フェーズを実行する認証ベースの操作

ソースおよびターゲットのデータベース・サーバーでは、Zero Downtime Migrationサービス・ホストからの着信接続を受け入れる必要があります。

Autonomous Databaseターゲットには適用できません
Zero Downtime Migrationサービス・ホスト ソースおよびターゲットのデータベース・サーバー TCP 1521、2484またはデータベースSCANリスナー・ポート SQL*Net 論理移行用
Zero Downtime Migrationサービス・ホストまたはGoldenGateハブ ターゲットADB TCPS 1522、またはソースかターゲットでTCPSが有効になっている場合は、データベースSCANリスナー・セキュア・ポート SQL*Net ADB (サーバーレス)はポート1522を使用するため、ADBテナンシでGoldeGateまたはZDMからの着信接続を許可する必要があります。または、ソースが1522でリスニングしており転送メディアがTCPS経由のDBLINKである場合は、ターゲットからの着信接続を許可する必要があります。
Zero Downtime Migrationサービス・ホスト Oracle Cloud Interface RESTエンドポイント SSL 443 OCI RESTエンドポイント 論理移行のターゲット検出

ノート: 必要なすべてのプロキシの詳細情報を考慮し、ZDMレスポンス・ファイルに詳細情報を指定してください。

ソース・データベース・サーバー ターゲット・データベース・サーバー TCP 1521またはジョブに適用可能なデータベースSCANリスナー・ポート SQL*Net OracleのSQL*Netプロトコルを介したデータベースへのOracleクライアント接続を許可する必要があります。

データベース問合せ、Data Guard同期および構成を実行します。

ノート: デフォルト以外のポート番号(ポート1521以外のもの)をローカル・リスナー・アドレスに使用している場合、デフォルト以外のポートへの接続を許可する必要があります。

ターゲット・データベース・サーバー ソース・データベース・サーバー TCP 1521または適用可能なデータベースSCANリスナー・ポート SQL*Net OracleのSQL*Netプロトコルを介したデータベースへのOracleクライアント接続を許可する必要があります。

スイッチオーバー後にソース・データベースがOracle Cloudの新しいプライマリと同期している必要がある場合に、REDOログの送信を許可します。Oracle Cloudからソース・データベース・サーバーに通信できない場合、この通信を回避するために、レスポンス・ファイルでSKIP_FALLBACKをTRUEに設定します。

ノート: デフォルト以外のポート番号(ポート1521以外のもの)をローカル・リスナー・アドレスに使用している場合、デフォルト以外のポートへの接続を許可する必要があります。

ソース・データベース・サーバー Oracle Cloud Object Storeサービス SSL 443 データベース・バックアップ・ストア。 選択したバックアップ方法でOracle Cloud Object Storeサービスをバックアップ媒体として使用する場合、記載されたOracle Cloud Object Storeサービスが適合するポートにアクセスします。

ノート: 必要なすべてのプロキシの詳細情報を考慮し、ZDMレスポンス・ファイルに詳細情報を指定してください。

ターゲット・データベース・サーバー Oracle Cloud Object Storeサービス SSL 443 データベース・バックアップ・ストア。 選択したバックアップ方法でOracle Cloud Object Storeサービスをバックアップ媒体として使用する場合、記載されたOracle Cloud Object Storeサービスが適合するポートにアクセスします。

ノート: 必要なすべてのプロキシの詳細情報を考慮し、ZDMレスポンス・ファイルに詳細情報を指定してください。

ノート:

ソース・データベースへのSSHアクセスがない場合、Zero Downtime Migrationワークフローの一部として次のアクションがスキップされます。
  • Zero Downtime Migrationでは、データベース・ユーザーがソース・エクスポート・パスに対して書込み可能かどうかは検証されません。

ノート:

ルート資格証明を使用して移行を実行する場合(migrate database -scroot)、設定フェーズでは、エフェメラル範囲から選択した6つのポート、またはzdmbase/crsdata/zdm_service_host/rhp/conf/rhp.prefのTRANSFERPORT_RANGEに設定されたポート範囲からの6つのポートが、Zero Downtime Migrationによって使用されます。指定したポートは、ソースまたはターゲット・データベース・サーバーのZero Downtime Migrationサービス・ホストからの着信接続を受け入れできる必要があります。

3.4 オンライン物理移行のためのデータベース接続の構成

物理移行の場合、ソース・データベースとターゲット・データベースの間でSQL*Netを使用できる必要があります。ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続を構成するには、SCANを使用したSQL*Net接続とSSHの2つのオプションがあります。必要に応じて、ターゲット・データベースとソース・データベース間の接続を構成できます。

ノート:

ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続の構成は、オンラインの物理移行にのみ該当します。

3.4.1 SCANを使用したSQL*Net接続

  • このオプションを使用するには、ソースがターゲット・データベースのSCANを介してターゲットに接続できること、またはその逆であることを確認します。
  • ZDMCLI migrate databaseコマンドの-sourcenodeパラメータで指定したソース・データベース・サーバーを使用して、ターゲットSCAN経由でそれぞれのSCANポートを介してターゲット・データベース・インスタンスに接続します(その逆も同様です)。
  • 両側からのSCAN接続により、ソース・データベースとターゲット・データベースはどちらの方向からも同期できます。ソース・データベース・サーバーのSCANがターゲット・データベース・サーバーから解決できない場合は、レスポンス・ファイルでSKIP_FALLBACKパラメータをTRUEに設定する必要があり、スイッチオーバー後はターゲット・データベースとソース・データベース間で同期をとることができません。

接続のテスト

ソース環境からターゲット環境への接続をテストするには、データベース接続記述子にマップするtnsnames.oraファイルにTNS別名エントリを追加します。「tnsnames.oraファイル内のローカル・ネーミング・パラメータ」を参照してください。 

[oracle@sourcedb ~] tnsping tnsping <TNS_ALIAS>

ターゲット環境からソース環境への接続をテストするには、データベース接続記述子にマップするtnsnames.oraファイルにTNS別名エントリを追加します。 

[oracle@targetdb ~] tnsping tnsping <TNS_ALIAS>

ノート:

Zero Data Loss Recovery Applianceを使用してOracle Exadata Database Service on Cloud@Customerにデータベースを移行するには、ターゲット・データベース・サーバーからZDLRAへの必須のSQL*Net接続が必要です。

関連項目:

Zero Downtime Migrationのポートの要件