Exadata Cloud@Customer (ExaCC) puts oracle exa cloud hardware in your own data center while Oracle manages it as a cloud service from Oracle Cloud Infrastructure (OCI). That is possible because ExaCC splits into two halves: a control plane that lives in OCI and a data plane that lives on your premises, joined by a pair of Control Plane Servers (CPS) inside the rack.
Many DBAs and architects meeting ExaCC for the first time ask the same questions. If the hardware is in my building, how does the OCI Console manage it? Does my data travel to Oracle's cloud? What happens if the internet link drops?
This article answers those questions by walking through each layer, how they talk to each other, and what that means for security, networking and day-to-day operations. It closes with best practices and common interview and exam questions.
Think of ExaCC as a brain in the cloud and muscles in your building. The control plane in OCI decides what should happen; the data plane in your data center does the work; the two Control Plane Servers carry instructions between them.
Read the diagram bottom up: the CPS dials out to OCI, automation comes back down that tunnel, and your applications reach the databases over your own network without touching OCI.
The control plane is the management software that decides what should happen to your ExaCC system. It runs in an OCI region, not in your data center. With Gen 2 ExaCC, Oracle moved the control plane into the public cloud, so there is no separate rack of management equipment on site.
When you work with ExaCC through the OCI Console, OCI CLI, SDKs, REST APIs or Terraform, you are talking to the control plane. It owns these jobs:
- Provisioning: creating Exadata infrastructure, VM cluster networks, VM clusters, Oracle homes and databases.
- Scaling: adding or removing OCPUs/ECPUs, memory and storage for VM clusters.
- Lifecycle and patching: infrastructure maintenance scheduling, Grid Infrastructure and database patching, Exadata OS image updates.
- Backups: configuring automatic backups to Object Storage, local storage, NFS or Zero Data Loss Recovery Appliance.
- Identity and governance: IAM policies, compartments, tags and audit logs for every API call.
- Monitoring and metering: metrics, events, notifications and billing based on what you consume.
The control plane also includes an Oracle service tenancy and an admin VCN that Oracle manages. Oracle's cloud operations staff reach your infrastructure through this admin VCN, never directly from the internet.
The data plane is where the actual work happens: your databases run, queries execute and data is stored. All of it sits in your own data center, inside the Exadata rack.
| Component | What it does | Who manages it |
|---|---|---|
| Database servers | Host the VM clusters (guest VMs) that run Grid Infrastructure, RAC and your databases | Oracle: physical server and hypervisor. You: guest VMs and databases |
| Exadata Storage Servers | Store data and run Smart Scan, Storage Indexes, Smart Flash Cache and HCC | Oracle |
| RoCE (or InfiniBand) network | Non-routable fabric for RAC interconnect and database-to-storage traffic | Oracle |
| Client network | Connects database servers to your corporate network; apps use SCAN and VIPs | You |
| Backup network | Separate interfaces for backups and bulk data transfers | You |
This split of responsibility is the heart of the service. Oracle owns the infrastructure below the VM: servers, storage, switches and power distribution units. You own everything inside the VM: operating system users, databases, schemas, application access and data.
Because application traffic flows over your client network to servers in your building, latency to your applications is the same as any on-premises database. Your data never has to cross the internet to be read or written.
Every ExaCC system ships with two Control Plane Servers in the rack, and they are the only path between the OCI control plane and the on-premises data plane. Two servers give redundancy: if one fails, the other keeps the link alive.
The CPS pair sits on three networks at once:
- Control plane network: a subnet on your corporate network that gives each CPS an IP address and an outbound route to the OCI region. You supply 2 IP addresses, one per CPS.
- Administration network: an internal network in the rack that connects the CPS to every database server, storage server, switch and ILOM port.
- RoCE / InfiniBand network: the rack's private fabric, which the CPS also joins.
What the CPS actually does
- Opens an outgoing, persistent, secure automation tunnel to the Oracle-managed admin VCN in your OCI region. Cloud automation commands for your VM clusters travel down this tunnel.
- Opens an outgoing, temporary, secure operator tunnel only when an Oracle operator needs SSH access for maintenance or troubleshooting. It closes when the work is done.
- Relays telemetry and logs (infrastructure health, metrics, diagnostic logs) to OCI Monitoring, Logging and Object Storage.
- Pulls software updates such as infrastructure patches and OS images from OCI Object Storage.
- Forwards DNS and NTP from your corporate network to the isolated administration network, so the rack can resolve names and keep time.
Why the tunnels are outbound
The CPS always initiates the connection, over TCP port 443. Oracle's documentation states that inbound 443 is not required and that blocking it may be desirable. Once the outbound session is up, traffic can flow both ways inside it.
This design means your firewall never has to accept an inbound connection from the internet to manage the Exadata. It is the same pattern a laptop VPN client uses: the client dials out, and the server talks back through that session.
A single OCPU scale-up shows how all three layers cooperate. Say a DBA wants to scale a VM cluster from 8 to 16 OCPUs before month-end batch jobs.
- The DBA submits the request in the OCI Console or with the OCI CLI. It goes over HTTPS to the ExaCC service endpoints in the OCI region.
- The control plane authenticates and authorizes the call against IAM policies, records it in the Audit service and validates capacity.
- The control plane queues a work request and hands the automation job to the admin VCN in the Oracle service tenancy.
- The job travels down the persistent automation tunnel that the CPS already holds open. No new inbound connection is created.
- The CPS receives the job and passes it over the administration network to the right database servers.
- The data plane executes the change: the hypervisor assigns more cores to each guest VM, and the cluster picks them up online.
- Status flows back through the CPS and tunnel to the control plane. The work request moves to Succeeded, and the Console shows 16 OCPUs.
At no point did database rows leave the rack. Only the instruction and its result crossed the tunnel. The same pattern applies to creating a database, applying a quarterly patch or configuring automatic backups: the control plane decides, the CPS delivers, and the data plane executes.
The control plane / data plane split is what lets ExaCC meet strict data residency rules while still being a managed cloud service. Customer data stays on premises; only management traffic goes to OCI.
| Crosses the CPS tunnel | Stays in your data center |
|---|---|
| Automation commands and status results | Database contents and query results |
| Infrastructure telemetry and metrics | Application traffic over SCAN/VIP |
| Diagnostic logs | Local backups to NFS or ZDLRA |
| Software updates (inbound) | Anything inside your guest VMs |
The one exception is a choice you make yourself, such as sending backups to OCI Object Storage over the backup network.
Controls that protect the separation
- Outbound-only connectivity: the CPS dials out on port 443; no inbound internet path into the rack is needed.
- Isolated internal networks: the administration network and RoCE fabric are non-routable and do not connect to your corporate network.
- Separation of duties: Oracle operators manage infrastructure but have no access to your guest VMs or databases.
- Temporary operator tunnel: Oracle staff SSH access goes through bastion and management servers and a short-lived tunnel.
- Operator Access Control (optional): every Oracle operator access request needs your approval, all commands are logged, and you can revoke access at any time.
- Customer-managed encryption keys: TDE keys can be held in your own Oracle Key Vault.
- Audit: every control plane API call is recorded in the OCI Audit service.
For regulated industries such as banking, government and healthcare, this is often the deciding factor: they get cloud-style automation without moving data out of their jurisdiction or data center.
Most ExaCC deployment delays come from the CPS network, so plan it early with your network and security teams.
| Requirement | Detail |
|---|---|
| IP addresses | 2 on your corporate network, one per CPS, plus netmask and gateway |
| Uplinks | 4 in total, 2 per CPS |
| Port | TCP 443 outbound only; inbound 443 not required |
| Bandwidth | Minimum 50 Mbps download / 10 Mbps upload to OCI |
| DNS and NTP | At least one reliable server each, reachable from the CPS (up to 3 can be registered) |
| Proxy | A passive HTTP open proxy is supported; reverse proxies, challenge proxies and traffic inspection are not |
| Firewall by IP | Allow all CIDR ranges for your OCI region from Oracle's public_ip_ranges.json |
Endpoints the CPS must reach
The CPS needs outbound 443 to a set of region-specific OCI endpoints. Replace the region placeholder with your own OCI region:
# Cloud automation tunnel https://wss.exacc.<oci_region>.oci.oraclecloud.com # Oracle operator access tunnel https://mgmthe1.exacc.<oci_region>.oci.oraclecloud.com https://mgmthe2.exacc.<oci_region>.oci.oraclecloud.com # Updates, monitoring and log collection https://objectstorage.<oci_region>.oraclecloud.com https://telemetry-ingestion.<oci_region>.oraclecloud.com # Identity https://identity.<oci_region>.oraclecloud.com https://auth.<oci_region>.oraclecloud.com
FastConnect option
By default the CPS connects over the internet using a TLS tunnel. If your security policy needs more isolation, you can route CPS traffic over OCI FastConnect with public or private peering. Oracle does not recommend a corporate HTTP proxy in front of FastConnect, since the circuit is already dedicated.
Avoid IP overlaps
The administration and RoCE networks use internal ranges you choose when creating the infrastructure. Because the CPS bridges these to your corporate network, those ranges must not exist anywhere else in your corporate network.
Your databases keep running. Because the data plane is entirely on premises, losing the connection to OCI does not stop the VMs, the databases or application traffic. What you lose is the management layer.
| Keeps working | Stops or pauses until the link returns |
|---|---|
| Running databases and RAC clusters | Console, CLI and API operations (scaling, create, delete) |
| Application connections over SCAN/VIP | Cloud-automated patching and maintenance |
| Local backups to NFS or ZDLRA | Backups to OCI Object Storage, if they depend on the same link |
| Logging in to your VMs over SSH | Infrastructure metrics, telemetry and log upload |
| Manual DBA work inside the VMs | Oracle's remote monitoring and operator access |
Troubleshooting a lost connection
- Check the infrastructure's connectivity status in the OCI Console.
- Enable and review the CPS Offline Diagnostic Report, which Oracle provides to diagnose connectivity issues between the CPS and OCI endpoints.
- Confirm outbound 443 is still open to every mandatory endpoint, and that no new proxy or inspection rule was added.
- Check DNS and NTP reachability from the CPS subnet; both are hard dependencies.
- Raise a Service Request with Oracle Support if the cause is not on your side.
- Plan the CPS network before the rack ships. Confirm the 2 IP addresses, 4 uplinks, firewall rules and DNS/NTP in advance.
- Give the CPS redundant paths. Use two uplinks per CPS on separate switches, and if possible two ISP paths or FastConnect.
- Allow endpoints by region CIDR, not single IPs. OCI addresses change; follow Oracle's public_ip_ranges.json.
- Do not inspect CPS traffic. SSL inspection breaks the tunnel and is unsupported.
- Choose admin and RoCE CIDRs carefully. They must not overlap with anything in your corporate network, now or later.
- Turn on the CPS Offline Diagnostic Report so you have data ready if connectivity fails.
- Enable Operator Access Control if compliance needs approval and logging of every Oracle operator action.
- Monitor the CPS link like a production service. Alert on loss of connectivity, not just on database health.
- Write least-privilege IAM policies. Separate who manages infrastructure from who manages VM clusters and databases.
- Keep backups independent of the tunnel. Keep at least one copy on local ZDLRA or NFS.
Where does the ExaCC control plane run?
In an OCI region. Gen 2 ExaCC has no on-site management rack; only the CPS pair sits in your data center.
What is a Control Plane Server, and how many does each system have?
A server in the ExaCC rack that connects the on-premises infrastructure to OCI. Each system has two, for redundancy.
Which port does the CPS need, and in which direction?
TCP 443 outbound. Inbound 443 is not required and can be blocked.
What are the two tunnels from the CPS?
A persistent automation tunnel for cloud automation commands, and a temporary operator tunnel used only when Oracle operators need SSH access.
Does customer data pass through the CPS tunnel?
No. Only commands, status, telemetry, logs and updates. Database data stays on your client and backup networks.
If internet connectivity to OCI fails, do the databases go down?
No. Databases keep running. Console/API operations, cloud patching, OCI-side monitoring and Object Storage backups are affected until the link is back.
Who manages what in ExaCC?
Oracle manages the physical infrastructure: servers, storage, network switches and hypervisor. The customer manages guest VMs, databases and data.
How can a customer control Oracle operator access?
With Oracle Operator Access Control, which requires customer approval for access and logs every operator command.
Why must the admin and RoCE ranges not exist elsewhere in the corporate network?
The CPS connects to both those internal networks and the corporate network, so overlapping ranges would cause routing conflicts.
Can the CPS connect to OCI without the public internet?
Yes. Besides the default internet TLS tunnel, it can use OCI FastConnect with public or private peering.
Exadata Cloud@Customer works because it separates deciding from doing. The control plane in OCI decides what should happen, the two Control Plane Servers carry those decisions over an outbound-only secure tunnel, and the data plane in your data center does the work with your data never leaving the building.
Once you see ExaCC this way, the rest falls into place: why port 443 outbound matters, why databases survive a lost internet link, why Oracle can patch infrastructure without seeing your data, and why the CPS network deserves the same care as any production system.
