Autoscaling Exadata Cloud at Customer / Exadata Cloud Service

The Recipe — Events, Functions, Schedule based Autoscaling

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.

Use schedule-based autoscaling to do everything except autoscaling

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

Comparison

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.