Validated May 25, 2021
Oracle Services may require a proxy to reach data sources for various reasons including security, routing and privacy. For use cases requiring sophisticated functionality, Oracle's Connection Manager provides database transparency, high-availability, protocol conversion and enhanced security, scalability and performance.
This post is a step-by-step guide for deploying Connection Manager on Linux with a simple starter configuration.
Refer to Understanding Oracle Connection Manager Architecture for details on the architecture shown below.
The primary uses of Connection Manager for Oracle Services are private egress, transparency, and protocol conversion.
Private Egress provides access to private databases.
Transparency hides the details of connecting to unsupported databases or those with complex connection criteria. It allows users to think that they are connecting to a single-instance Oracle database using just a host, port, and service name. Connection Manager stores the connection complexities for all users and applications. When it receives a request, it connects to the target database for session creation. The database receives the actual user, application and network address for its session details.
Protocol Conversion converts TCP traffic to TCPS used by Autonomous Databases (ADB). This feature along with transparency further simplifies the user experience by hiding the need for Secure Socket Layer wallets and associated networking parameters. Connection Manager stores complex TCPS wallet placement and handshake parameters for all users and applications. When it receives a request, it forwards it on to the SSL-protected database for session creation.
Additional uses of Connection Manager are access control and anonymity.
Access Control provides solutions for database access when a database subnet allows ingress only from designated application subnets. A Connection Manager instance in such a subnet receives connection requests and connects to the databases on the application's behalf.
Anonymity builds on transparency by hiding the application from the database. The database only receives Connection Manager's proxy user and network address for its session details.
May 25, 2021 with GoldenGate 21.1
February 2, 2021 with FAW 5.8 and OAC 5.9
Before You Begin
Deploying Required Components
Installing Connection Manager
Configuring Connection Manager
Validating Connection Manager
|FAW||Fusion Applications Warehouse|
|OAC||Oracle Analytics Cloud|
|OCI||Oracle Cloud Infrastructure|
|FQDN||Fully Qualified Domain Name|
|PAC||Private Access Channel|
|OSN||Oracle Services Network|
A user account in an OCI tenancy for managing compute and networking components.
The following components must exist before installing and validating CMAN.
|VCN||Hosts the CMAN subnet||Link|
|COMPUTE INSTANCE||Hosts the CMAN application||Link|
|ACCESS RULES||Facilitates network traffic between Services and CMAN||Link|
Create a new VCN using the OCI networking QuickStart wizard.
Create or use an existing public subnet in the VCN chosen above. This post uses a subnet named APP-Subnet in its examples.
Create a small Linux instance to initially host CMAN in the APP-Subnet.
On your client prepare an SSH alias. Windows users may either install SSH or use PuTTY.
Define ingress rules for network traffic between clients and CMAN.
|VCN1-APP-SL||INGRESS||CLIENT||TCP||1521||Ingress to CMAN Listener|
|VCN1-APP-SL||INGRESS||CLIENT||TCP||22||SSH Ingress from Client|
Download the appropriate CMAN software from here e.g. LINUX.X64_193000_client.zip. Copy the file to the compute instance if necessary.
Note: This package also creates an oracle user.
Create a response file e.g. cman.rsp to be used with silent installation mode.
This section configures a starter CMAN instance. Refer here for complete documentation.
The CMAN configuration file cman.ora format is based on an Oracle Database Listener configuration file listener.ora format with additional options. Each CMAN instance defined in the file includes the following components:
Access Rule List
The minimum required components are an instance, listening endpoint and an access rule. The parameter list is omitted here as the defaults are sufficient to start with. The access rule is set to allow all traffic. Modify this if necessary after a successful installation.
Validating the introductory deployment of CMAN involves starting it and successfully connecting to it using SQL*Plus. Start CMAN using the Connection Manager Control Utility.
Use a dummy username, password and service name. We are only testing if CMAN is listening.
If CMAN is listening you see:
ORA-12514: TNS:listener does not currently know of service requested in connect
If CMAN is not listening you see:
ORA-12541: TNS:no listener
This post provided a step-by-step guide for deploying Oracle Connection Manager on Linux with a simple starter configuration. You are now ready to create a connection to a private data source using Connection Manager.
For other posts relating to analytics and data integration visit http://www.ateam-oracle.com/dayne-carley