OAC Private Access Channel Enables Consolidated Analytics with Data Sources in Different Networks

A recently released feature of Oracle Analytics Cloud (OAC) is Private Access Channel (PAC). PAC allows us to connect OAC to private data sources. This means it allows us to connect OAC to databases hosted in private networks, such as on-premises within a corporate network, or on other Clouds, both Oracle and non-Oracle. PAC connects OAC to the private data source via an Oracle Cloud Virtual Cloud Network (VCN). Therefore, any supported data source that the OCI VCN has access to, may be configured with PAC for reporting from within OAC.

This link provides a list of OAC supported data sources with PAC. The same page designates whether a data source supports connectivity with Private Access Channel (PAC), Remote Data Connectivity (which is through Remote Data Gateway), or both. While Remote Data Gateway has been available for a while now for use with OAC, it follows a different architecture and communication mechanism than PAC. Since some data sources are supported with PAC while others with RDG, you may find that you need both to be configured for the same OAC instance, and that is possible.

The complexity of configuring PAC for OAC varies depending on the data source scenarios you want to enable for connectivity from OAC. Ensuring correct networking setup may also require setting up temporary machines in the different subnets involved, in order to verify appropriate routing from OAC to the data sources. The scenarios vary based on a number of factors including:

• Whether your OAC is publicly accessible (public endpoint) or has a private endpoint.
• The location of the data source whether it’s in the same OAC VCN, anther OCI VCN, another OCI region or tenancy, a non-Oracle Cloud, or an organization’s own network (on-premises).
• Whether DNS resolution for data source endpoints is handled by an OCI DNS resolver or a non-OCI DNS Server, such as an organization’s own data center.
• Whether traffic between OAC and the data sources needs to be routed privately (as opposed to over the public internet)
  • Data source network outside the OAC’s region (including on-premises networks or non-Oracle Clouds). In this case a Dynamic Routing Gateway (DRG) is needed to be setup with OCI VPN or OCI Fast Connect between the OAC VCN and the other network.
  • Data source OCI VCN is in the same region as the OAC VCN, whether using the same tenancy or not: In this case a Local Peering Gateway (LPG) is needed between the two OCI VCNs.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Note that PAC may be configured in both scenarios: OAC with public endpoint (OAC accessible from public internet), and OAC with private endpoint (OAC accessible through private network with VPN). Private endpoint OAC instances already have their VCN and Subnet assigned, so there is no need to create new ones. One creates the PAC for the private endpoint OAC within the same subnet that hosts the OAC instance. For public endpoint OAC instances, we need to have the following OCI components in place, if not already available for other purposes.

Private Data Sources within the OAC PAC VCN

In order to configure OAC PAC to connect to a data source that is hosted within the same VCN, the following high-level steps may be followed:

• OCI VCN: An OCI VCN is needed in the same region as OAC. This VCN needs to use DNS hostnames in order for PAC to work.
• Subnet: A Subnet within the aforementioned VCN to host PAC. Again here the subnet needs to use DNS hostnames.
• PAC: For the OAC instance, add and configure a PAC within the above subnet.
• PAC Private Source configuration with DNS Zone: In order to connect OAC to a data source accessible from the aforementioned VCN, we need to first create a Private Source in the PAC. Once the Private Source is added to the PAC, OAC users may then connect to it in a self-service manner. To create a Private Source in the PAC, we can’t use the IP address but have to use Fully Qualified Domain Name (FQDN) of the data source. While adding the DNS Zone for the PAC, we have the option of either adding a specific data source FQDN, for a specific database for example, or the parent DNS of the data source subnet which enables connecting to any data source hosted within that subnet.
• Access Control:
  • On the Security List attached to the OAC PAC subnet, create an Egress Rule to the data source subnet on the port that the data source is listening on.
  • On the Security List attached to the data source subnet, create an Ingress Rule from the OAC PAC subnet on the port that the data source is listening on.
• OAC Self-Service Connection (Also referred to as a Data Visualization Connection): With the PAC created as above, we can now connect OAC to any of the PAC supported data sources that are hosted within the above VCN, without the need for Networking Gateways. When creating a connection in OAC, we need to use the data source’s FQDN, rather than its IP address. (Remote Data Connectivity option needs to be unchecked since this is reserved for RDG type of connections and not PAC connections.)
• OAC Data Model Connection (From RPD): If needed, the connection pool of the data model repository (RPD) can now also be connected to the data source configured in PAC using the data source’s FQDN. The connection details in the connection pool depend on the type of data source and therefore follow the typical setting of connecting to that type of data source.

Private Data Sources outside the PAC VCN:

If we want to make OAC connect to a private data sources hosted outside the PAC VCN, we will additionally need to deploy a few more OCI networking components to be able to route the connection from the PAC VCN to the target network hosting the data source.

• OCI Private DNS Components necessary to resolve OAC’s data source FQDNs: This involves a more complex networking setup which entails analyzing the different data source DNS scenarios and deploying any necessary DHCP resolver, access rules, subnets and private end points.
• Network Gateways: This involves setting up different networking components depending on the scenarios being deployed. These components may include one or more of: Dynamic Routing Gateways, On-premises VPN, Remote Peering, Local Peering, Routing Rules, NAT gateways, Internet Gateways and Load Balancers.