I get a lot of questions from our field on how the Cloud Architecture and Engineering (CAE) team Oracle SMEs are bringing over so many Oracle workloads to run in Azure so successfully. One of the biggest hurdles to bringing Oracle workloads into a 3rd party cloud isn’t technology, but licensing hurdles.
Oracle doesn’t appear to make it easy, penalizing hypervisor virtualized CPUs. The reason this doesn’t faze us in the internal team is that we KNOW how on-premises database hosts are sized out for capacity planning. It is common for multiple reasons for these hosts to be considerably over-provisioned vs. what they require to run the workloads. Most often its due to:
Considering the above list, we’re now aware that around 85% of Oracle workloads assessed will require a fraction of the CPU that exists on the on-premises systems. The Automatic Workload Repository (AWR) is very good at identifying a solid workload and with a worksheet that can adjust for averages and aggregate values, will provide solid estimates to size out the workload for the cloud.
*Note- We're not “boiling the ocean” here. The goal is to identify if 4, 8, 16, 32…. vCPU is needed. For that vCPU allocation, does the memory fall into the correct size needed to run the peak workload and can it handle the peak IO generated?
Now, you don’t have to believe me, but one of the account teams were curious if this was true and I was able to bring up their customer he asked about to demonstrate it and since I took the time to write it all out, I wanted to make the most of this content and share it with others to help understand how this works.
The use case is an Exadata end-of-life migration. All databases are moving from the Exadata and into Azure. These are RAC databases that we will be sizing down to single instances from the AWR workloads. The workloads have been collected from peak times and are for one week.
Using one of their customer workloads, (but hiding all customer pertinent information for database, RAC nodes and host names) as an example- I won’t go into all the details, but I use the AWR to size out the workload and you will notice, for all the RAC nodes, the total of cores they are licensed for, (at a high level, if they have virtualized, etc., this may be different than my simple calculations from what Oracle says they are using):
Per this data, they should be licensed for 590 core licenses on the Exadata machine.
The worksheet breaks down all data and for the workload and calculations to deal with averages, aggregations, single instance from RAC, etc., we note that at estimated peak, they require a 1/4th of that:
Throughput, (MBPs) is our real constraint when sizing these and the ending VM skus and sizing resulted in core licensing of 120 vCPU total.
I’m going to repeat that: With the current workloads, they need 58 vCPU and if I double this to meet the peak workload the customer sees during the busiest times of year. 120 vCPU is required, and they are licensed for 590 core licenses from Oracle.
If we create a Data Guard secondary for each production database, that will be 240 vCPU each, (if we create DR THE same size as production.)
With that, I hope this example demonstrates how we size out Oracle workloads and why the 2:1 penalty isn’t an issue for migrating Oracle to the Azure cloud.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.