Autoscaling Exadata Cloud at Customer / Exadata Cloud Service

This post is specifically about leveraging schedule-based autoscaling to scale up and scale down of Exadata Cloud at Customer and Exadata Cloud Service. For a general understanding of what are the possibilities and a primer, check the link below.

Some Context

The solution is applicable to

Gen 2.0 Exadata Cloud at Customer
Exadata Cloud Service.

What makes this approach special?

#1 Vertical Scaling
ExaCC - Exadata Cloud at Customer
ExaCS - Exadata Cloud Service
ExaCC & ExaCS support Vertical Scaling without downtime

#2 Hybrid Cloud
Exadata Cloud at Customer is deployed behind the customer's firewall at the customer's data-center.

The Architecture

The Gen 2.0 Architecture allows one to use a fully modern fabric to optimize Exadata Cloud at Customer.

Gen 2.0 Exadata Cloud at Customer

The Pattern

The pattern is very similar to what I advocated earlier in this post. It builds on what a modern cloud infrastructure and platform provides.

Fundamental Principles

1. Every infrastructure component is an API
2. Every interaction with infrastructure is a CRUD action
3. Every CRUD Action is logged.
4. Every Create, Update or Delete Action emits a lifecycle event.
5. Every lifecycle event provides resource contextual information.
6. This event can be processed to take further action
Schedule based Autoscaling as a Trigger
Events Service as a Router & Feedback loop for closed loop benefits
Functions as an Actuator

Tags for Passing Data & Attributes for Filtering

Tags can be used (both freeform and defined tags ) along with resource attributes to decide which ExaCC and by how much should the scaling happens. This removes the need to write multiple functions to do the same scaling action.

The Why

Assume you have an ExaCS Half Rack / ExaCC Half Rack of the total capacity of 200 Cores.

( Mon- Friday 6 AM - 10 PM )
Exa Database CPU Requirement - 100 Cores
( Mon - Friday 10 PM - 6 AM )
Exa Database CPU Requirement - 40 Cores
Fri - Mon ( 6 AM - 6 PM )
Exa Database CPU Requirement - 60 Cores
Fri - Mon ( 6 PM - 6 AM )
Exa Database CPU Requirement - 20 Cores


A yearly savings potential of 109K USD for every 100 Cores of Database footprint you have on Exadata. While the savings potential may change from use case to use case, the cost of turning this lever to save costs is quite literally “0”

| Comments | Full Capacity | Demand Curve | Cost Savings |
| Month | 24001 $ | 14865 $ | 9136$ |
| Yearly | 288017 $ | 178384 $ | 109,632$ |

The Details

Understanding how components are organized inside Exadata Cloud Service Exadata Cloud@Customer

An Example ExaCC/ExaCS
1) 3 VM Clusters
2) VM Cluster-1 has 16 OCPUs/Cores allocated to it.
VM Cluster - 1
Before Scale Up : 16 OCPUs
Minimum Scale up OCPU Count = Number of VMs
Scaling action is always for a given VM Cluster. If there are 4 VMs in a VM-Cluster , then the scaling is done in Multiples of 4
After Scale Up : 20 OCPUs
Scaling Action Example

I hope this helps. Leave your thoughts below.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store