2 Setting Up Secure or Non-Secure Deployments

Adding deployments is the first task in the process of setting up a data extraction and replication platform. Deployments are managed from the Service Manager.

After completing the Oracle GoldenGate MA installation, you can add an initial and subsequent deployments using the Configuration Assistant (OGGCA) wizard.

You can use the Configuration Assistant wizard to add multiple deployments to a Service Manager, which enables you to upgrade the same Service Manager with new releases or patches. The source and target deployments serve as endpoints for setting up the distribution path for data replication. A target deployment is added the same way as the source deployment but for a different database user or a different database.

1. From the OGG_HOME directory, run the $OGG_HOME/bin/oggca.sh program on UNIX or Linux.

   The Oracle GoldenGate Configuration Assistant (oggca) is started. Run this program, each time you want to add a deployment.

2. In the Select Service Manager Options step:

   1. Select whether you want to use an existing Service Manager or a new one. Only one Service Manager per host is supported.

   2. Enter or browse to the directory that you want to use for your deployment. Oracle recommends that you do not use your Oracle GoldenGate installation directory.

   3. Enter the hostname or IP Address of the server.

   4. Enter a unique port number that you want to contact your Service Manager on or use the default, which is used in the URL to connect to it. Ensure that the port is unreserved and unrestricted. Each service must use a different port number.

   5. (Optional) You can register the Service Manager to run as a service so as to avoid manually starting and stopping it.

      You can choose to run one Service Manager as a service (daemon). If there is an existing Service Manager registered as a service and you select a new Service Manager to register as a service, an alert is displayed indicating that you cannot register the new one as a service. All other Service Managers are started and stopped using scripts installed in the bin directory of the deployment. You cannot register an existing Service Manager as a service.

   6. (Optional) You can choose to integrate your deployment with an Oracle Grid Infrastructure for Oracle Database by selecting the option “Integrate with XAG”. This option cannot be used when running your Service Manager as a service.

3. In the Configuration Options step, you can add or remove deployments.

   Select the appropriate option.

4. In the Deployment Details step:

   1. Enter the deployment name using these conventions:

      • Must begin with a letter.

      • Can be a standard ASCII alphanumeric string not exceeding 32 characters.

      • Cannot include extended ASCII characters.

      • Special characters that are allowed include underscore (‘_’), hyphen (‘/’), dash (‘-’), period (‘.’).

      • Cannot be “ServiceManager”.

   2. Select Enable Sharding to use the database sharding feature in your deployment. The schema must be ggadmin.

   3. Enter or select the Oracle GoldenGate installation (home) directory. If you have set the $OGG_HOME environment variable, the directory is automatically populated. Otherwise, the parent directory of the oggca.sh script is used.

   4. Click Next.

5. On the Select Deployment Directories page:

   1. Enter or select a deployment directory where you want to store the deployment registry and configuration files. When you enter the deployment directory name, it is created if it doesn’t exist. Oracle recommends that you do not locate your deployment directory inside your $OGG_HOME and that you a separate directory for easier upgrades. The additional fields are automatically populated based on the specified deployment directory.

   2. You can customize the deployment directories so that they are named and located differently from the default.

   3. Enter or select different directories for the various deployment elements.

   4. Click Next.

6. On the Environment Variables page:

   Enter the requested values for the environment variables. Double-click in the field to edit it. You can copy and paste values in the environment variable fields. Make sure that you tab or click outside of the field after entering each value, otherwise it’s not saved. If you have set any of these environment variables, the directory is automatically populated.

   ORACLE_HOME

   The directory where you installed your database.

   LD_LIBRARY_PATH

   The library directories to your $OGG_HOME, OUI, database installation, and database network (TNS_ADMIN).

   TNS_ADMIN

   The directory that contains the Oracle Net Services configuration. The default is $ORACLE_HOME/rdbms/admin.

   ORACLE_SID

   The Oracle system identifier (SID) is a unique identifier that is used to distinguish this instance from other Oracle Database instances that you may create later and run concurrently on your system.

   STREAMS_POOL_SIZE

   This appears only if you enabled sharding or are using Integrated Extract or Replicat. Use the default or set your pool size value that is at least 1200MB.

   You can add additional environment variables to customize your deployment or remove variables. For instance, you can enter the following variable to default to another international charset: ENV_LC_ALL=zh_CN.UTF-8

   Click Next.

7. On the Administrator Account page:

   1. Enter a user name and password that you want to use to sign in to the Oracle GoldenGate MA Service Manager and the other servers. This user is the security user for this deployment. For details on the different types of users, see How to Add Users. If you are using an existing Service Manager, you must enter the same log in credentials that were used when adding the first deployment.

   2. Click Next.

8. On the Security Options page:

   1. You can choose whether or not you want to secure your deployment. Oracle recommends that you enable SSL/TLS security. If you do not want to use security for your deployment, deselect the check box. This operation exposes the check box "This non-secure deployment will be used to send trail data to a secure deployment." Check this box if the non-secure target deployment is meant to communicate with a secure source deployment.

      However, you must enable security if configuring for Oracle GoldenGate sharding support.

   2. (Optional) You can specify a client wallet location so that you can send trail data to a secure deployment. This option is useful when Distribution Server from the source deployment is unsecured whereas the Receiver Server on the target deployment is secured. In this case, the sender may be configured for public access whereas the Receiver Server requires authentication and authorization, which is established using PKI before the incoming data is applied. For more information, see Creating Self-Signed Root Certificate,

      and Creating a Distribution Server User Certificate.

   3. For your Server, select one of the options, and then provide the required file locations. When using an existing wallet, it must have the appropriate certificates already imported into it. If you choose to use a certificate, enter the corresponding pass phrase. When using a self-signed certificate, a new Oracle Wallet is created in the new deployment and these certificates are imported into it. For certificates, enter the location of the private key file and the pass phrase.

   4. For your Client, select one of the options, and then provide the required information as you did for your server.

   5. Click Next.

9. (If Security is enabled) On the Advanced Security Settings page:

   The set of cryptographic algorithms used for secure communication with the Oracle GoldenGate services display. The default cipher suites are:

   • TLS_RSA_WITH_AES_256_CBC_SHA

   • TLS_RSA_WITH_AES_128_CBC_SHA

   • SSL_RSA_WITH_RC4_128_SHA

   • SSL_RSA_WITH_RC4_128_MD5

   • SSL_RSA_WITH_3DES_EDE_CBC_SHA

   Note:

   The cipher suites that are grey in color and italicized are not supported by your current JRE environment.

   1. Use the arrows to add or remove cipher suites.

   2. Use Up and Down to reorder how the cipher suites are applied

   3. Click Next.

      Note:

      For more information on TCP/IP encryption options with RMTHOST, see RMTHOST in Reference for Oracle GoldenGate

10. (If Sharding is enabled) On the Sharding Options page:

    1. Locate and import your Oracle GoldenGate Sharding Certificate. Enter the distinguished name from the certificate that will be used by the database sharding code to identify itself when making REST API calls to the Oracle GoldenGate MA services.

    2. Enter a unique name for the certificate.

    3. Click Next.

11. On the Port Settings page:

    1. Enter the Administration Server port number, and then when you leave the field the other port numbers are populated in ascending numbers. Optionally, you can enter unique ports for each of the servers.

    2. Select Enable Monitoring to use the Performance Metrics Server.

    3. Click inside the Performance Metrics Server port fields to populate or enter the ports you want to use.

       Note:

       Ensure that you choose available ports for TCP and UDP for performance monitoring. After the deployment is done, you can change the TCP port from the Service Manager console. For more information on PMSRVR, see ENABLEMONITORING

    4. For BDB informtion, see Oracle Berkeley DB 12c Release 1 For LMDB information, see http://www.lmdb.tech/doc/.

    5. Select the location of your datastore. BDB and LMDB are in-memory and disk-resident databases. The Performance Metrics server uses the datastore to store all performance metrics information.

    6. Click Next.

    Note:

    The oggca utility does not validate whether or not the port you entered is currently in use or not, so you must manually ensure that the ports are free and will not be reassigned to other processes.

12. In the Replication Settings step:

    1. Enter the Oracle GoldenGate default schema you want to use to perform the replication settings. For example, ggadmin.

    2. Click Next.

13. On the Summary page:

    1. Review the detailed configuration settings of the deployment before you continue.

    2. (Optional) You can save the configuration information to a response file. You can run the installer from the command line using this file as an input to duplicate the results of a successful configuration on other systems. You can edit this file or a new one from the provided template.

       Note:

       When saving to a response file, the administrator password is not saved for security reasons. You must edit the response file and enter the password if you want to reuse the response file for use on other systems.

    3. Click Finish to the deployment.

    4. Click Next.

14. On the Configure Deployment page:

    Displays the progress of the deployment creation and configuration.

    1. If the Service Manager is being registered as a service, a pop-up appears that directs you how to run the script to register the service. The Configuration Assistant verifies that these scripts have been run. If you did not run them, you are queried if you want to continue. When you click Yes, the configuration completes successfully. When you click No, a temporary failed status is set and you click Retry to run the scripts.

       Click Ok after you run the script to continue.

    2. Click Next.

15. On the Finish page:

    Click Close to close the Configuration Assistant.

Each deployment has its own list of users, and when you add users, you add them to that deployment.

The only user that can manage the services in Service Manager is the user that was originally added as the security user when you initially add the deployment to the Service Manager. The other users are specific to the MA deployment and the security user needs to create users to every MA deployment individually.

You can create users for that deployment by performing the following steps:

1. Click the + sign.

2. Enter a unique user name.

3. Select one of these roles:

   User

    Can view resources hosted by the server.  This includes monitoring performance, requesting reports, and viewing resource configuration

   Operator

   Can create, update, destroy, start, pause, and stop server hosted resources in addition to User role rights

   Administrator

   Can manage and administer all services with the exception of security related configurations and profiles in addition to User and Operator role rights.

   Security

   Can administer security related objects and invoke security related service requests. This role has full rights.

4. Enter information that describes the user.

5. Enter the password twice to verify it. Passwords can contain the user name.

6. Click Submit.

   The user is registered

Users cannot be changed. You must delete a user, and then add it again.

In a secure mode, communication with Oracle GoldeGate SA including administrative calls and data transport is secured using SSL/TLS certificates, which you purchase or create your own for testing purposes.

1. Create a directory to store your wallets and certificates. For example, ~/wallet_directory.
2. Create an automatic login wallet. This example uses root_ca for the wallet name.

   orapki wallet create -wallet ~/wallet_directory/root_ca -auto_login -pwd welcome123
   

3. Create a new self-signed (root user) certificate and add it to the wallet.

   orapki wallet add -wallet ~/wallet_directory/root_ca -dn "CN=RootCA" -keysize 2048 -self_signed -validity 7300 -pwd welcome123
   

4. Export the certificate to a .pem file.

   orapki wallet export -wallet ~/wallet_directory/root_ca -dn "CN=RootCA" -cert ~/wallet_directory/rootCA_Cert.pem -pwd welcome123
   

You must make sure that your Oracle GoldenGate SA implementation has a clear guideline for security certificates, before you go into production. For testing purposes, however, you can generate server certificates.

1. Create a directory to store your wallets and certificates. For example, ~/wallet_directory.
2. Create an automatic login server wallet.

   orapki wallet create -wallet /wallet_directory/servername 
   

   Enter the password for the server when prompted.
3. Add a Certificate Signing Request (CSR) to the server’s wallet.

   orapki wallet add -wallet /wallet_directory/servername -dn "CN=servername" -keysize 2048 
   

4. Export the CSR to a .pem file.

   orapki wallet export -wallet /wallet_directory/servername -dn "CN=servername" -request /wallet_directory/servername_req.pem
   

5. Using the CSR, create a signed server or client certificate and sign it using the root certificate. Assign a unique serial number to each certificate.

   orapki cert create -wallet ~/wallet_directory/root_ca -request ~/wallet_directory/servername_req.pem -cert ~/wallet_directory/servername_Cert.pem -serial_num 20 -validity 375
   

6. Add the root certificate into the client’s or server’s wallet as a trusted certificate.

   orapki wallet add -wallet ~/wallet_directory/servername -trusted_cert -cert ~/wallet_directory/rootCA_Cert.pem 
   

7. Add the server or client certificate as a user certificate into the client’s or server’s wallet.

   orapki wallet add -wallet ~/wallet_directory/servername -user_cert -cert ~/wallet_directory/servername_Cert.pem  
   

To replicate data to an SSL/TLS secured target Oracle GoldenGate MAdeployment, you must create a wallet with a client certificate for the Distribution Server. This certificate is also signed by the root certificate. It provides a common trust point because the server considers any certificate signed by the same root certificate as the server's certificate authentication.

1. Create a directory to store your wallets and certificates. For example, ~/wallet_directory.
2. Create an automatic login client wallet. This example uses dist_client for the wallet name.

   orapki wallet create -wallet ~/wallet_directory/dist_client -auto_login -pwd welcome123
   

3. Add a CSR to the wallet.

   orapki wallet add -wallet ~/wallet_directory/dist_client -dn "CN=dist_client" -keysize 2048 -pwd welcome123
   

4. Export the CSR to a .pem file.

   orapki wallet export -wallet ~/wallet_directory/dist_client -dn "CN=dist_client" -request ~/wallet_directory/dist_client_req.pem -pwd welcome123
   

5. Using CSR, create a signed server or client certificate and sign it using the root certificate. Assign a unique serial number to each certificate.

   orapki cert create -wallet ~/wallet_directory/root_ca -request ~/wallet_directory/dist_client_req.pem -cert ~/wallet_directory/dist_client_Cert.pem -serial_num 30 -validity 375 -pwd welcome123
   

6. Add the root certificate as a trusted certificate into the client’s or server’s wallet.

   orapki wallet add -wallet ~/wallet_directory/dist_client -trusted_cert -cert ~/wallet_directory/rootCA_Cert.pem -pwd welcome123
   

7. Add the server or client certificate as a user certificate into the client’s or server’s wallet.

   orapki wallet add -wallet ~/wallet_directory/dist_client -user_cert -cert ~/wallet_directory/dist_client_Cert.pem -pwd welcome123