Scalability and Elasticity in Oracle Cloud Infrastructure

Scalability and elasticity are fundamental elements of cloud computing. They enable to allocate as many resources as needed for the system to fulfill the workload requirements. An essential benefit of the cloud is the ability to scale up and down on demand immediately while using a pay-per-use model and get the best performance at the most cost-effective rate.

There are many differences in the definition of these two non-functional architectural characteristics:

Scalability

• Increase of system resources to meet the future increasing workload demands.
• Adapting to increased workload by adding more resources to the current infrastructure (scale-up, vertical scaling) or by expanding the infrastructure by adding more elements (scale-out, horizontal scaling).
• Strategic resource allocation operation to meet expected long-term demands.

Elasticity

• Increasing or decreasing of system resources to meet the current workload demands.
• Adapting to workload changes by dynamic variation in the use of resources. Increasing resources by scaling up/out or decreasing resources by scaling down/in.
• Tactical resource allocation operation to meet unexpected short-term changes.

In this blog post we will see how Oracle Cloud Infrastructure provides scalability and elasticity capabilities for different services to adapt to workload changes, ensure performance and high availability, and benefit from the pay-per-use model.

General overview of the topics we’ll discuss:

• Extending and changing performance of Block Storage to meet data growth, variation in IOPS, and throughput requirements.
• Changing the shape of compute instances
• Using Load Balancer to implement scalability and high availability.
• Using Instance Pools to automatically adjust the number of application servers based on performance metrics or a schedule.
• Scale CPU cores or change the shape of Database Cloud Service systems
• Autonomous Database storage and CPU (Auto) Scaling

Storage Scaling for Compute Instances

Scale up: increase the size of the block volume without detaching the volume from an instance. The elastic performance feature of the block volume service allows you to dynamically change the volume performance to adjust IOPS and throughput of the disk. From the Block Volume Details page, click on "Edit Size or Performance". At OS level, extend the partition and the file system.

Scale down: it is not possible to resize the block volume to a smaller size. Create a new block volume with smaller size and migrate the data to it.

Scale out/in: add more block volumes to a compute instance to increase the totals amount of available storage. From the menu, navigate to "Block Storage", "Block Volumes", and click on "Create Block Volume". Delete the block volumes no longer needed to save cost. First, detach the volume and then terminate it. You can add or remove block volumes while the compute instance still online and available.

As the block volumes are added to the same compute instance, this is a scale up/down regarding the compute instance itself.

CPU Scaling for Compute Instances

Oracle Cloud Infrastructure provides different shapes for compute machines with different number of CPUs, amount of memory, and other resources.

Compute Virtual Machines

Scale up: increasing the number of CPUs for a VM requires changing the shape to one with a higher number of CPUs to get more performance on the same machine. From the Instance Details page, click on "Edit", choose the new shape, and click "Save Changes". This operation might take about 10 to 15 minutes to complete. The compute VM is not available during that time.

Scale down: change the shape to one with less number of CPUs to save cost.

Scale out/in: handle more workload by adding more compute VMs to your architecture and distribute the traffic among them.

Use a Load Balancer to provide one entry point to your application, improve resource utilization, facilitate scaling, and ensure high availability.

To manually scale out/in, add/remove a new compute VM to/from the Backend Set of the load balancer. To add more instances, from the Load Balancer Details page, click on "Backend Sets". Select a Backend Set and click on "Backends", then on "Add Backends". To remove an instance, select the same from the backend's list, click on "Actions", then on "Delete".

Use Instance Pools and Autoscaling Configurations to automatically adjust the number of instances available for your workload based on performance metrics or a schedule. Associate a load balancer with the instance pool to add the new compute instances automatically to the backend set. Create this configuration as follows:

1. Create a compute instance.
2. Install your application software on the compute instance.
3. Create a custom image from that instance.
4. Create a new compute instance using the custom image.
5. Create an Instance Configuration from the new compute instance. From the Instance Details page, click on "More Actions", then on "Create Instance Configuration". After creating the instance configuration, you can terminate the compute instances created in steps 1 and 4.
6. Create an Instance Pool. From the menu, navigate to "Compute", "Instance Pools", and click on "Create Instance Pool".
7. Attach a load balancer to the instance pool. From the Instance Pool Details page click on "Load Balancers" and "Attach a Load Balancer"
8. Create an Autoscaling Configuration. From the Instance Pool Details page click on "More Actions", then on "Create Autoscaling Configuration". The autoscaling policy can be based on metrics or a schedule.

Compute Bare Metal Machines

Scale up/down: A bare metal compute instance is a dedicated physical server providing strong isolation and high performance. Bare Metal shapes provide a fix number of CPUs (from 36 to 128). Migrate to another shape to scale up or down.

Scale out/in: Add/remove more bare metal instances to your architecture to handle very large workload. The same rules applies as for virtual machines.

Storage Scaling for Database Cloud Systems

The Database Cloud Service on OCI provides Oracle database deployments on Virtual Machines, Dedicated Bare Metal machines, and on Exadata.

DBCS Virtual Machines

Virtual machine DB system databases use Oracle Cloud Infrastructure block storage.

Scale up: add more storage to the system without service interruption. From the DBCS Details page, click on "Scale Storage Up", select the storage size, and click "Update".

Scale down: migrate the database to another system with less storage allcated.

DBCS Bare Metal Machines

Bare Metal DB systems consist of a single bare metal server with locally attached NVMe storage. The shape you choose for a bare metal DB system determines its total raw storage.

Scale up/down: the amount of storage is fixed per shape. Migrate the database to another DB system with a different shape if needed.

Database availability depends on the migration method.

Exadata Cloud Service

Exadata DB systems allow you to leverage the power of Exadata within OCI.

Scale up/down: each storage server on the Exadata machine has a fix amount of storage.

Scale out/in: Migrate the database to another DB system with a different Exadata shape if needed, for example, from a quarter rack to a half rack to get more storage servers.

Database availability depends on the migration method.

CPU Scaling for Database Cloud Systems

DBCS Virtual Machines

Scale up: increasing the number of CPUs for a DBCS VM requires changing the shape to one with a higher number of CPUs to get more performance on the same machine. From the DBCS Details page, click on "Change Shape". This operation might take about 10 to 15 minutes to complete. The database system is not available during that time.

Scale down: change the shape to one with less number of CPUs to save cost.

Scale out/in: scaling out and in of database instances is done by using Real Application Clusters (RAC). RAC is available on VM DB systems with two nodes. You could stop one of the nodes to scale in, and start it again to scale out. The database remain online and accessible from one of the nodes.

DBCS Bare Metal Machines

Scale up/down: to increase or decrease the processing power to a bare metal DB system, change the number of enabled CPU cores in the system without impacting the availability of that system.

Scale out/in: RAC is not available for bare metal DB systems at the moment. Use Exadata Cloud Service for RAC on dedicated high performance hardware.

Exadata Cloud Service

Scale up: to add more compute node processing power to an Exadata DB system, scale up the number of enabled CPU cores symmetrically across all the nodes in the system, e.g. for a base system or a quarter rack, you can scale in multiples of 2 across the 2 database compute nodes. For a half rack, you can scale in multiples of 4 across the 4 database compute nodes. For a full rack, you can scale in multiples of 8 across the 8 database compute nodes.

Scale down: you can scale the DB system down to zero cores. With zero cores, you are billed only for the infrastructure until you scale up the system. Oracle recommends that if you are not scaling down to a stopped system (0 cores), that you scale to at least 3 cores per node.

Scale out/in: Migrate the database to another DB system with a different Exadata shape if needed, for example, from a quarter rack to a half rack to get more compute nodes. Database availability depends on the migration method.

Storage Scaling for Autonomous Database

Scale up/down: you can increase or decrease the amount of storage at any time online without any service interruption.

Scale out/in: Autonomous database is based on Exadata Infrastructure. Additional storage servers will be used if needed transparently to the user.

CPU Scaling for Autonomous Database

Scale up/down: you can increase or decrease the number of CPUs at any time online without any service interruption. Using the Auto Scaling feature, it is possible to scale up to 3x of the CPU count configured automatically and scale down automatically again when the resources are not needed anymore without any human intervention.

Scale out/in: Autonomous database is based on RAC and Exadata Infrastructure. Additional compute nodes will be used if needed transparently to the user.

Conclusion

Scaling capabilities in Oracle Cloud Infrastructure allows you to add and remove resources as needed, manually or automatically, to different services like storage, compute, and databases. The following table provides an overview of the available options (green=online, yellow=offline, gray=migration):

If you have any questions or comments on this article, please feel free to ping me on LinkedIn.