Configuring Required Connections

Configuring Connectivity From the Zero Downtime Migration Service Host to the Source and Target Database Servers

Note:

These steps are applicable for physical migrations and logical migrations where both the source and target are accessed using SSH keys (co-managed databases).

These steps are not applicable for logical migration where the target is Autonomous Database.

Complete the following procedure to ensure the required connectivity between the Zero Downtime Migration service host and the source and target database servers.

On the Zero Downtime Migration service host, verify that the RSA authentication key pairs are available without a passphrase for the Zero Downtime Migration software installed user.
If a new key pair must be generated without the passphrase, then, as a Zero Downtime Migration software installed user, generate new key pairs as described in Generate SSH Keys Without a Passphrase.
Rename the private key file.
Rename the zdm_installed_user_home/.ssh/id_rsa file name to zdm_installed_user_home/.ssh/zdm_service_host.ppk.
Add the contents of the zdm_installed_user_home/.ssh/id_rsa.pub file to the opc_user_home/.ssh/authorized_keys file, with the following dependencies:
For the source database server:
- If the source database server is accessed with the root user, then no action is required.
- If the source database server is accessed through SSH, then add the contents of the zdm_installed_user_home/.ssh/id_rsa.pub file into the opc_user_home/.ssh/authorized_keys file on all of the source database servers.
For the target database server:
- Because the target database server is on cloud only and access is through SSH, add the contents of the zdm_installed_user_home/.ssh/id_rsa.pub file into the opc_user_home/.ssh/authorized_keys file on all of the target database servers.
Note that the opc user is a standard Oracle cloud user that is used to access database servers, but you can use any privileged user that has sudo privileges. You can also use different users for the source and target databases.
Make sure that the source and target database server names are resolvable from the Zero Downtime Migration service host through either resolving name servers or alternate ways approved by your IT infrastructure.
One method of resolving source and target database server names is to add the source and target database server names and IP address details to the Zero Downtime Migration service host /etc/hosts file.

In the following example, the IP address entries are shown as 192.x.x.x, but you must add your actual public IP addresses.
```
#OCI public IP two node RAC server details
192.0.2.1 ocidb1
192.0.2.2 ocidb2
#OCIC public IP two node RAC server details
192.0.2.3 ocicdb1
192.0.2.4 ocicdb2
```
Optionally, Zero Downtime Migration allows connectivity through bastion hosts for both logical and physical migrations.
Make certain that port 22 in the source and target database servers accept incoming connections from the Zero Downtime Migration service host.
Test the connectivity from the Zero Downtime Migration service host to all source and target database servers.
```
zdmuser> ssh -i zdm_service_host_private_key_file_location user@source/target_database_server_name
```
For example,
```
zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_host.ppk opc@ocidb1
zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_host.ppk opc@ocicdb1
```
Note:
SSH connectivity during Zero Downtime Migration operations requires direct, non-interactive access between the Zero Downtime Migration service host and the source and target database servers without the need to enter a passphrase.
Disable TTY and verify that it is disabled for the SSH privileged user.
TTY needs to be turned off so that Zero Downtime Migration can run commands on the remote hosts non-interactively.

Because there are many ways to set sudo privileges, there are many ways to disable TTY for the zdmuser. As an example, you could set the following default in /etc/sudoers file.
```
Defaults:zdmuser !requiretty
```
Run the following command to verify that TTY is disabled:
```
ssh -i zdm_service_host_private_key_file_location
 user@source_database/target_database_server_name
 "sudo_location_source/target_database /bin/sh -c date"
```
If TTY is disabled, the command above returns the date from the remote host without any errors.

If SSH is configured to require TTY, the output shows an error, such as the following:
```
[opc@zdm-server ~]$ ssh -i /home/zdmuser/.ssh/zdm_service_host.ppk opc@ocidb1
 "/usr/bin/sudo /bin/sh -c date"

sudo: sorry, you must have a tty to run sudo
```

Configuring SUDO Access

You may need to grant certain users authority to perform operations using sudo on the source and target database servers.

Note:

These steps are applicable for physical migrations and logical migrations where both the source and target are accessed using SSH keys (co-managed databases).

These steps are not applicable for logical migration where the target is Autonomous Database.

For source database servers:

If the source database server is accessed with the root user, then there is no need to configure Sudo operations.
If the source database server is accessed through SSH, then configure Sudo operations to run without prompting for a password for the database installed user and the root user.

For example, if database installed user is oracle, then run sudo su - oracle.

For the root user run sudo su -.

For target database servers:

Because the target database server is on the cloud only, any Sudo operations are configured already. Otherwise, configure all Sudo operations to run without prompting for a password for the database installed user and the root user.

For example, if database installed user is oracle, then run sudo su - oracle.

For the root user run sudo su -.

Note, for example, if the login user is opc, then you can enable Sudo operations for the opc user.

Configuring Connectivity Between the Source and Target Database Servers

You have two options for configuring connectivity between the source and target database servers: SQL*Net connectivity using SCAN or SSH.

Configure connectivity using one of the following options.

Option 1: SQL*Net Connectivity Using SCAN

To use this option, the SCAN of the target should be resolvable from the source database server, and the SCAN of the source should be resolvable from the target server.

The specified source database server in the ZDMCLI migrate database command -sourcenode parameter can connect to the target database instance over target SCAN through the respective SCAN port and vice versa.

With SCAN connectivity from both sides, the source database and target databases can synchronize from either direction. If the source database server SCAN cannot be resolved from the target database server, then the SKIP_FALLBACK parameter in the response file must be set to TRUE, and the target database and source database cannot synchronize after switchover.

Test Connectivity

To test connectivity from the source to the target environment, add the TNS entry of the target database to the source database server $ORACLE_HOME/network/admin/tnsnames.ora file.

[oracle@sourcedb ~] tnsping target-tns-string

To test connectivity from the target to the source environment, add the TNS entry of the source database to the target database server $ORACLE_HOME/network/admin/tnsnames.ora file

[oracle@targetdb ~] tnsping source-tns-string

Note:

Database migration to Exadata Cloud at Customer using the Zero Data Loss Recovery Appliance requires mandatory SQL*Net connectivity from the target database server to the source database server.

Option 2: Set up an SSH Tunnel

If connectivity using SCAN and the SCAN port is not possible between the source and target database servers, set up an SSH tunnel from the source database server to the target database server.

The following procedure sets up an SSH tunnel on the source database servers for the root user. Note that this procedure amounts to setting up what may be considered a temporary channel. Using this connectivity option, you will not be able to synchronize between the target database and source database after switchover, and with this configuration you cannot fall back to the original source database.

Note:

The following steps refer to Oracle Cloud Infrastructure, but are also applicable to Exadata Cloud at Customer and Exadata Cloud Service.

Generate an SSH key file without a passphrase for the opc user on the target Oracle Cloud Infrastructure server, using the information in Generate SSH Keys Without a Passphrase. If the target is an Oracle RAC database, then generate an SSH key file without a passphrase from the first Oracle RAC server.
Add the contents of the Oracle Cloud Infrastructure server opc_user_home/.ssh/id_rsa.pub file into the Oracle Cloud Infrastructure server opc_user_home/.ssh/authorized_keys file.
Copy the target Oracle Cloud Infrastructure server private SSH key file onto the source server in the /root/.ssh/ directory. If the source is an Oracle RAC database, copy the file into all of the source servers.
For better manageability, keep the private SSH key file name the same as the target server name, and keep the .ppk extension. For example, ocidb1.ppk (where ocidb1 is the target server name).
The file permissions should be similar to the following.
```
/root/.ssh>ls -l ocidb1.ppk
-rw------- 1 root root 1679 Oct 16 10:05 ocidb1.ppk
```
Put the following entries in the source server /root/.ssh/config file.
```
Host *
  ServerAliveInterval 10  
  ServerAliveCountMax 2

Host OCI_server_name   
  HostName OCI_server_IP_address
  IdentityFile Private_key_file_location 
  User OCI_user_login  
  ProxyCommand /usr/bin/nc -X connect -x proxy_name:proxy_port %h %p
```
Where
- OCI_server_name is the Oracle Cloud Infrastructure target database server name without the domain name. For an Oracle RAC database use the first Oracle RAC server name without the domain name.
- OCI_server_IP_address is the Oracle Cloud Infrastructure target database server IP address. For an Oracle RAC database use the first Oracle RAC server IP address.
- Private_key_file_location is the location of the private key file on the source database server, which you copied from the target database server in step 3 above.
- OCI_user_login is the OS user used to access the target database servers.
- proxy_name is the host name of the proxy server.
- proxy_port is the port of the proxy server.
Note that the proxy setup might not be required when you are not using a proxy server for connectivity. For example, when the source database server is on Oracle Cloud Infrastructure Classic, you can remove or comment the line starting with ProxyCommand.

For example, after specifying the relevant values, the /root/.ssh/config file should be similar to the following.
```
Host *
  ServerAliveInterval 10  
  ServerAliveCountMax 2

Host ocidb1
  HostName 192.0.2.1
  IdentityFile /root/.ssh/ocidb1.ppk
  User opc
  ProxyCommand /usr/bin/nc -X connect -x www-proxy.example.com:80 %h %p
```
The file permissions should be similar to the following.
```
/root/.ssh>ls -l config
-rw------- 1 root root 1679 Oct 16 10:05 config
```
In the above example, the Oracle Cloud Infrastructure server name is ocidb1, and the Oracle Cloud Infrastructure server public IP address is 192.0.2.1.

If the source is an Oracle Cloud Infrastructure Classic server, the proxy_name is not required, so you can remove or comment the line starting with ProxyCommand.

If the source is an Oracle RAC database, then copy the same /root/.ssh/config file onto all of the source Oracle RAC database servers. This file will have the Oracle Cloud Infrastructure server name, Oracle Cloud Infrastructure server public IP address, and private key file location of first Oracle Cloud Infrastructure Oracle RAC server information configured.
Make sure that you can SSH to the first target Oracle Cloud Infrastructure server from the source server before you enable the SSH tunnel.
For an Oracle RAC database, test the connection from all of the source servers to the first target Oracle Cloud Interface server.
Using the private key:
```
[root@ocicdb1 ~] ssh -i /root/.ssh/ocidb1.ppk opc@ocidb1
Last login: Fri Dec  7 14:53:09 2018 from 192.0.2.3

[opc@ocidb1 ~]$
```
Note:
SSH connectivity requires direct, non-interactive access between the source and target database servers, without the need to enter a passphrase.
Run the following command on the source server to enable the SSH tunnel.
```
ssh -f OCI_hostname_without_domain_name -L ssh_tunnel_port_number:OCI_server_IP_address:OCI_server_listener_port -N
```
Where
- OCI_hostname_without_domain_name is the Oracle Cloud Infrastructure target database server name without a domain name. For an Oracle RAC database use the first Oracle RAC server name without domain name.
- ssh_tunnel_port_number is any available ephemeral port in the range (1024-65545). Make sure that the SSH tunnel port is not used by any other process in the server before using it.
- OCI_server_listener_port is the target database listener port number. The listener port must be open between the source database servers and Oracle Cloud Infrastructure target servers.
- OCI_server_IP_address is the IP address of the target database server. For a single instance database, specify the Oracle Cloud Infrastructure server IP address. For an Oracle RAC database, specify the Oracle Cloud Infrastructure scan name with the domain name. If the scan name with domain name is not resolvable or not working, then specify the IP address obtained using the lsnrctl status command output. For example,
```
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.9)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.10)(PORT=1521)))
```
The following is an example of the command run to enable the SSH tunnel.
```
[root@ocicdb1~]ssh -f ocidb1 -L 9000:192.0.2.9:1521 -N
```
For an Oracle RAC database, this step must be repeated on all of the source servers.

Test the SSH tunnel.

Log in to source server, switch to the oracle user and source the database environment, and run the following command.

tnsping localhost:ssh_tunnel_port

For example,

[oracle@ocicdb1 ~] tnsping localhost:9000

The command output is similar to the following.

TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 22-JAN-2019 05:41:57
Copyright (c) 1997, 2014, Oracle.  All rights reserved.
Used parameter files:
Used HOSTNAME adapter to resolve the alias
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=9000)))
OK (50 msec)

If tnsping does not work, then the SSH tunnel is not enabled.

For Oracle RAC, this step must be repeated on all of the source servers.

Additional Connectivity Prerequisites for Oracle GoldenGate Hub

To perform online logical migrations with Oracle GoldenGate, in addition to the connectivity between the Zero Downtime Migration service host and the source and target database servers, you must also ensure connectivity between the Oracle GoldenGate hub and the source and target database servers.

Ensure that the OCI network security rules allow the following connections.

Table 3-1 Prerequisite Connections for Online Logical Migration

Initiator	Target	Protocol	Port	Purpose
GoldenGate hub	Source database	TCP TCPS	1521 User-defined	SQL*Net
GoldenGate hub	Target database	TCP TCPS	1521 1522 for ADB-Serverless, port 2484 for ADB-Dedicated, or user-defined for non-ADB	SQL*Net
ZDM server	GoldenGate hub	HTTPS	443	Oracle GoldenGate Microservice REST API calls

The Zero Downtime Migration server should be allowed to make HTTPS over port 443 calls to an OCI REST endpoint.

Validating Connections to and from the Oracle GoldenGate Marketplace Instance

From Zero Downtime Migration server to Oracle GoldenGate server.

On Zero Downtime Migration server, run
```
curl -v --insecure -u oggadmin_username https://ogg_instance_fqdn_or_ip/services/v2/deployments
```
Oracle GoldenGate server credentials can be found in /home/opc/ogg-credentials.json on the GoldenGate server.
From Oracle GoldenGate server to source database server.

Assuming that the source database listener is not TLS/SSL enabled, on the Oracle GoldenGate server, run
```
export ORACLE_HOME=/u01/app/client/oracle19
$ORACLE_HOME/bin/sqlplus username@'source_listener_hostname_or_ip:source_listener_port/source_db_service_name'
```
From Oracle GoldenGate server to target database server

If the target database is an Autonomous Database, refer to "Online Migration Additional Prerequisites" at Additional Logical Migration Prerequisites, and ensure that the Autonomous Database wallet containing certificates for TLS authentication exists in the correct location on the Oracle GoldenGate instance.

On Oracle GoldenGate server, run
```
export ORACLE_HOME=/u01/app/client/oracle19
$ORACLE_HOME/bin/sqlplus username@'tcps://abd_listener_hostname_or_ip:adb_listener_port/adb_service_name?wallet_location=dir_path&ssl_server_cert_dn=cert_dn'
```
Refer to Connect SQL*Plus with TLS Authentication for more details about connecting to an Autonomous Database using SQL*Plus.

If the target database is not an Autonomous Database and is not TLS/SSL enabled, on the Oracle GoldenGate server, run
```
export ORACLE_HOME=/u01/app/client/oracle19
$ORACLE_HOME/bin/sqlplus username@'target_listener_hostname_or_ip:target_listener_port/target_db_service_name'
```

Zero Downtime Migration Port Requirements

The ports required for communication between the Zero Downtime Migration service host, the source and target database servers, and Oracle Cloud Object Store Service are described in the following table.

Table 3-2 Zero Downtime Migration Communication Ports

Initiator	Target	Protocol	Port	Purpose	Description
Zero Downtime Migration service host	Source and target database servers	TCP	22	SSH	Authentication-based operations to run Zero Downtime Migration operational phases Source and target database servers should accept incoming connections from the Zero Downtime Migration service host. Not applicable to Autonomous Database targets
Zero Downtime Migration service host	Source and target database servers	TCP	1521, 2484, or a database SCAN Listener port applicable for job	SQL*Net	For logical migrations
Zero Downtime Migration service host or GoldenGate Hub	Target ADB	TCPS	1522, or a database SCAN Listener secure port applicable for job in case of TCPS enabled on source or target		ADB-S uses port 1522 so you should allow incoming connections on the ADB tenancy from GoldeGate or ZDM, or from the target if the source listens on 1522, and transfer medium is DBLINK over TCPS
Zero Downtime Migration service host	Oracle Cloud Interface REST endpoint	SSL	443	OCI REST endpoint	Target discovery for logical migrations
Source database servers	Target database servers	TCP	1521 or database SCAN Listener port applicable for the job	SQL*Net	Should allow Oracle client connections to the database over Oracle's SQL*Net protocol Perform database queries, Data Guard sync, and configuration Note: If you are using a non-default port number (that is, something other than port 1521) for the local listener address, then the non-default port should allow connections.
Target database servers	Source database servers	TCP	1521 or a database SCAN Listener port applicable	SQL*Net	Should allow Oracle client connections to the database over Oracle's SQL*Net protocol Allows redo log shipping if source database needs to be in sync with the new primary on Oracle Cloud after switchover. If there is no communication possible from Oracle Cloud to source database server then set `SKIP_FALLBACK` to `TRUE` in the response file to avoid this communication. Note: If you are using a non-default port number (that is, something other than port 1521) for the local listener address, then the non-default port should allow connections.
Source database servers	Oracle Cloud Object Store Service	SSL	443	Database backup store. Create a backup of the source database to the specified Oracle Cloud Object store container.	If the chosen backup method uses Oracle Cloud Object Store Service as the backup medium, then access ports as documented Oracle Cloud Object Store Service applies.
Target database servers	Oracle Cloud Object Store Service	SSL	443	Database backup store. Restore backup of the source database from the specified Oracle Cloud Object store container to the target database.	If the chosen backup method uses Oracle Cloud Object Store Service as the backup medium, then access ports as documented Oracle Cloud Object Store Service applies.

Note:

If there is no SSH access to the source database, the following actions are skipped as part of the Zero Downtime Migration work flow.

Dumps will not be uploaded or transferred from source node to Object Store or to the target server
Zero Downtime Migration will not validate the source export path, if it is writable for the database user
Zero Downtime Migration will not validate whether the source database server can successfully access the Oracle Cloud Object Store

Note:

When performing a migration with root credentials (migrate database -scroot), during the setup phase, Zero Downtime Migration uses six ports chosen from the ephemeral range, or six ports from the range of ports set in TRANSFERPORT_RANGE in zdmbase/crsdata/zdm_service_host/rhp/conf/rhp.pref. The specified ports must be allowed to accept incoming connections from the Zero Downtime Migration service host on the source or target database server.

Generate SSH Keys Without a Passphrase

You can generate a new SSH key without a passphrase if on the Zero Downtime Migration service host the authentication key pairs are not available without a passphrase for the Zero Downtime Migration software installed user.

Note:

Currently, only the RSA key format is supported for configuring SSH connectivity, so use the ssh-keygen command, which generates both of the authentication key pairs (public and private).

The following example shows you how to generate an SSH key pair for the Zero Downtime Migration software installed user. You can also use this command to generate the SSH key pair for the opc user.

Run the following command on the Zero Downtime Migration service host.

zdmuser> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/zdmuser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zdmuser/.ssh/id_rsa.
Your public key has been saved in /home/zdmuser/.ssh/id_rsa.pub.
The key fingerprint is:
c7:ed:fa:2c:5b:bb:91:4b:73:93:c1:33:3f:23:3b:30 zdmuser@zdm_service_host
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|         . . .   |
|        S o . =  |
|         . E . * |
|            X.+o.|
|          .= Bo.o|
|          o+*o.  |
+-----------------+

This command generates the id_rsa and id_rsa.pub files in the zdmuser home, for example, /home/zdmuser/.ssh.