Exadata Cloud Service Networking

Networking decisions on Exadata Cloud Service are hard to change after go live, because the VM cluster binds to the subnets you choose at provisioning time. Get the layout right at the start and the estate runs cleanly for years. Get it wrong and you are looking at a rebuild. This guide covers the subnet model, the connectivity options and a reference layout you can adapt before you provision anything.

The platform fundamentals are in the complete guide to Exadata Cloud Service. Here we go deep on the network, because it is where the most expensive early mistakes are made.

The two subnet model

An Exadata VM cluster attaches to two subnets, and understanding their roles is the foundation of everything else.

Both subnets should be private. The client subnet must have enough addresses for the cluster nodes, their virtual IPs and the SCAN addresses, and you should size it with headroom because you cannot easily resize it later. Place the subnets in a virtual cloud network whose address space does not overlap with your on premises network or any other cloud you might peer with, because overlapping ranges block connectivity and are painful to unwind.

SCAN listeners and how clients connect

Exadata uses Single Client Access Name listeners, so applications connect to a single SCAN name that resolves to several addresses and load balances across the cluster nodes. Your application connection strings reference the SCAN name, not individual nodes, which is what lets the cluster lose a node without the application needing to know. Make sure DNS resolution for the SCAN name works from the application tier, because a SCAN that does not resolve is the single most common day one connectivity failure.

Connectivity options into the cluster

Because the cluster lives on private subnets, you need a deliberate path in. The right choice depends on where the clients are.

Security lists and network security groups

Network rules are how you enforce least exposure. Scope ingress on the client subnet to the exact source ranges of your application tier and the listener ports only. The backup subnet should permit egress to the object storage service gateway and the redo transport ports for Data Guard, and little else. Network security groups let you attach rules to specific resources rather than the whole subnet, which is cleaner when different databases on the cluster have different access needs. This is the network half of the controls covered in ExaCS security.

A reference network layout

Cross region considerations for Data Guard

If you run a standby in a second region, the redo transport crosses regions and needs remote peering or a backbone path with enough bandwidth to keep up with redo generation at peak. Undersize that link and the standby falls behind, which quietly erodes your recovery point. Size the transport path against peak redo, not average, and monitor transport lag as a first class metric. The protection mode you choose interacts directly with this, as covered in Data Guard on Exadata Cloud.

Getting it right before you provision

Because the network binds at provisioning time, the cheapest moment to fix a network design is before the cluster exists. We see estates that have to be rebuilt because the subnets overlapped with an on premises range, were sized too small for growth, or exposed the database more widely than intended. A short design review before provisioning is far cheaper than a migration to fix it later. It is also the right time to plan the cutover network path covered in migrating to Exadata Cloud Service.

The Exadata Cloud Service practice designs the network layout as part of every implementation, and reviews existing estates where the layout is already causing pain.