Exadata Cloud Deployment and Considerations

I recently did a presentation and wipe-board session on Exadata Cloud deployment.  As part of that engagment, I did a small write-up on this topic.  This is a series of blogs that reflects the presentation:

Cloud Exadata Network and Platform Configuration

 Exadata DB Systems are offered in quarter rack, half rack or full rack configurations, and each configuration consists of compute nodes and storage servers. The compute nodes are each configured as a Virtual Machine (VM).

Key Operational characteristics of Exadata Cloud

  • Admins have root privileges for the compute node VMs. Thus 3rd party software can be installed, however, only supported Oracle DB versions and rpms should be implemented.

 

  • Admins do not have administrative access to the Exadata infrastructure components, including the physical compute node hardware, network switches, power distribution units (PDUs), integrated lights- out management (ILOM) interfaces, or the Exadata Storage Servers, which are all administered by Oracle.

 

  • Admins have full administrative privileges for your databases. However, application users should connect to databases via Oracle Net Services.

 

  • Admins are responsible for database administration tasks such as creating tablespaces and managing database users.

 

  • Admins should define how ssh keys will managed for users that will need compute node access.

 

 

 

 

 

 

 

 

 

 

 

Provisioning Exadata Pre-reqs

The following are network pre-reqs for provisioning Cloud Exadata DB Systems

Subnets

  • Require two separate VCN subnets: client subnet for user data traffic and backup subnet for backup traffic.
  • Define both the client subnet and the backup subnet as public subnets. Exadata requires a public subnet to support backup of the database to the Object Store.
  • Do not use a subnet that overlaps with 192.168.128.0/20. This restriction applies to both the client subnet and backup subnet.
  • Oracle requires that you use a VCN Resolver for DNS name resolution for the client subnet. It automatically resolves the Swift endpoints required for backing up databases, patching, and updating the cloud tooling on an Exadata DB System.

At the completion of the provisioning, you should have the following configured:

 

 

 

 

 

 

Security Lists and Routing

  • Each VCN subnet has a default security list that contains a rule to allow TCP traffic on destination port 22 (SSH) from source 0.0.0.0/0 and any source port. Properly configure the security list ingress and egress rules.
  • The OneCommand configuration enables TCP and ICMP traffic between all nodes and all ports in the respective subnet for client and backup subnets
  • Exadata DB System’s cloud network (VCN) must be configured with an internet gateway. Add a route table rule to open the access to the Object Storage Service Swift endpoint on CIDR 0.0.0.0/0.
  • Update the backup subnet’s security list to disallow any access from outside the subnet and allow egress traffic for TCP port 443 (https) on CIDR Ranges 129.146.0.0/16 (Phoenix region), 129.213.0.0/16 (Ashburn region)

Enable a route table with an entry that includes a Internet Gateway.  This will enable remote ssh access to the Exadata nodes

 

 

 

 

 

 

 

Provisioning Exadata

Service Console – Provision Exadata

Below are screenshot views that illustrate the provisioning of Exadata

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Cloud Exadata Storage Configuration

Exadata Storage Servers use the following ASM disk groups:

DATA diskgroup – for the storage of Oracle Data base datafiles.

RECO diskgroup – primarily used for storing files related to backup and recovery, such as RMAN backups and archived redo log files.  Depending how admins choose to provision for backups on Exadata storage

approximately 40% of the available storage space is allocated to the DATA disk group and approximately 60% is allocated to the RECO disk group.

Provision for backups on Exadata storage, approximately 80% of the available storage space is allocated to the DATA disk group and approximately 20% is allocated to the RECO disk group.

DBFS and ACFS diskgroups are system diskgroups that support various operational purposes. The DBFS disk group is primarily used to store the shared Clusterware files (Oracle Cluster Registry and voting disks), while the ACFS disk groups are primarily used to store Oracle Database binaries, staging directories and metadata.