This document covers several different areas to consider when deploying Oracle Database for SAP workload in the Amazon Web Service platform (AWS)
Since the recent announcements where Oracle 21c will not be supported by SAP and the new SAP note 3015613 describing the Oracle database support for BI on AWS, which includes Oracle RDS, motivates an update for the community and a wrap-up of the most used options we see in the market.
As SAP recognizes, the customer ecosystem is switching to the public cloud. It all started in mid-2011 when SAP allowed BusinessObjects to run on AWS.
While the US was taking the lead on AWS adoption, Amazon was certifying more and more SAP services (NetWeaver, HANA…), and the SAP to AWS boomed around 2016. At that time, SAP could run on Windows, Linux, and HANA flavors on AWS, and some months later, Azure was certified for almost the same combinations, which significantly helped customers to have a viable alternative. Customers were leveraging the platform to modernize the infrastructure layer and make it scalable (scale-up and as we saw during COVID, scale-down as well). Aligned to the raising cloud-first strategy from the corporations, looking for Agility, Cost Reduction, Performance increase, Global-scale Infrastructure, Maintenance standardization, Multitenancy, Improved Availability of world-class Security… to name a few.
Today, customers combining SAP, Oracle, and AWS are ruled by a Triumvirate. I will try to shed some light.
The following SAP Notes are related to SAP running Oracle on AWS. Make sure to click on “Mark as Favorite” to follow-up any update to the notes
|SAP NOTES RELEVANT FOR ORACLE, SAP, AND AWS|
|3015613||NEW NOTE Feb 2021; Oracle Database support for BI Platform on AWS|
|1656099||SAP Applications on AWS: Supported DB/OS and AWS EC2 products|
|1656250||SAP on AWS: Support prerequisites|
|2591601||SAP on AWS: Adaption of your SAP License|
|2358420||Oracle Database Support for Amazon Web Services EC2|
|1565179||SAP software and Oracle Linux|
|2606828||Oracle Database Roadmap for SAP NetWeaver|
Since Oracle 11g R2 (188.8.131.52), SAP applications are supported on AWS. This version is irrelevant since Oracle 11g is out of support. Any SAP application migrated to the cloud should benefit from an OS and DB re-platform, meaning that the migration process should bring the most modern combination for the x86 based OS (Windows or Linux) and Oracle DB. Long story short, given the current SAP regulations, the standard option should be Windows 2019 or Oracle 8 with Oracle 19c. Few exceptions should happen.
AWS provides a secure infrastructure to run an Oracle Database with an enterprise-class architecture, high availability, and support for small, medium, and large databases such as 64 TiB Oracle Database requiring 80k IOPS.
Windows and Oracle Linux are the only operating systems that Oracle and SAP support on AWS. Linux distributions Suse SLES and Red Hat RHEL aren’t supported for deploying Oracle components in AWS. Oracle components include the Oracle Database client, which SAP applications use to connect against the Oracle DBMS. Long story short, Netweaver Application Servers must be on Oracle Linux and the Database as well. Everything in Oracle Linux, except Business Objects that can run the BI components on Windows 2019, I will describe that later.
Oracle on AWS, options supported by SAP
For Amazon Web Services (AWS), Oracle offers support for Oracle Linux running on Amazon Elastic Compute Cloud (EC2) and Relational Database Service (RDS) only for SAP BO.
Oracle Running on an EC2 instance
The most adopted way (the only available until late 2020) is running a self-managed Oracle Database directly on Amazon Elastic Compute Cloud (Amazon EC2). This option gives full control over the setup of the infrastructure and database environment. Running the database on Amazon EC2 is very similar to running the database on any on-prem offering. A customer has full control of the database and operating system-level access, so any option for monitoring and management agents and any use of tools for data replication, backup, and restoration. Furthermore, there is the chance to use every optional module available in Oracle Database. However, this option requires setting up, configuring, managing, and tuning all the components, including Amazon EC2 instances, storage volumes, scalability, networking, and security, based on AWS architecture best practices.
For SAP, Oracle DB must run on an Oracle Linux OS running on Amazon EC2. Customers can obtain Oracle-provided Oracle Linux AMIs from the Amazon EC2 console by searching for the owner ID 131827586825 and deploying the Oracle Linux images on Amazon EC2. This article explains the steps to locate the Oracle-provided Oracle Linux AMIs and launch an Oracle Linux instance using the Amazon EC2 console.
Oracle Running on RDS
Amazon Relational Database Service (Amazon RDS) for Oracle Database is the easiest way to set up, operate, and scale a highly available Oracle Database in AWS. We can deploy multiple Oracle Database editions, including Enterprise Edition, Standard Edition, Standard Edition 1, and Standard Edition 2, with the Bring Your Own License (BYOL) model. Still, SAP only supports Oracle running on Enterprise Edition. Unfortunately, the “License Included” service model is solely provided for Standard Edition, so customers interested in this offering must bring the license themselves under the BYOL model. Unfortunately, Oracle RDS is only supported for SAP BusinessObjects, since late 2020.
Amazon RDS backs up the database automatically and also applies patches within the same patchset release. RDS is a managed database service that helps simplify the provisioning and management of Oracle databases. AWS makes it easy to set up, operate, and scale a relational database in the cloud by automating installation, disk provisioning, and management, patching, minor version upgrades, failed instance replacement, as well as backup and recovery tasks. The push-button scaling feature of Amazon RDS allows the easy-to-scale database instance up or down for better cost management and performance.
SAP Netweaver (7.0x to 7.5) products requiring Oracle Database 18c (min 18.5.0) or 19c (min 19.5.0) must run on Oracle Linux (OL) 6.4 or higher. This applies to both the Database and the Application Servers that require the Oracle Client.
- Oracle requires that the Amazon Machine Image (AMI) used for supported cloud instances be based on Oracle Linux 6.4 or later, 7.1 or later, and 8.2 or later.
- Only Unicode deployments of SAP NetWeaver Application Server ABAP/Java 7.x are certified on Oracle Database on Amazon EC2 instances.
- Oracle Database for SAP Netweaver is supported on Amazon EC2 only (not on Amazon RDS)
- Using Oracle Client Software for SAP NetWeaver Application Server ABAP/Java 7.x is only supported on Oracle Linux 6, 7, and 8.
- Exceptions from the above statement are SAP components that don’t use the Oracle Database client, like SAP’s stand-alone enqueue, message server, Enqueue replication services, WebDispatcher, and SAP Gateway can be installed on SUSE or RHEL and secured with a peacemaker cluster.
- Only single instance configurations of the Oracle Database and Oracle Automatic Storage Management (ASM) are supported on Amazon EC2.
- Oracle Real Application Clusters (RAC) is NOT supported on Amazon EC2.
- Oracle Database 21c, since it’s an innovation release, will NOT be certified by SAP (news January 2021). At the moment, Oracle Database 19c is the most current long-term support release term release.
EC2 Supported instance types for SAP on Oracle DB landscapes
|Instance Family||vCPU range||Memory Range||Recommended usage||Price|
|U (Metal)||448||6 -24 TB||X-LARGE||$$$$$$|
|M family||2-96||8-384 GiB||General Usage||$$|
|C family||2-96||4-192 GiB||Compute Optimized||$|
|R family (preferred)||2-96||16-768 GiB||Memory Optimized||$$$|
|I family*||2-96||16-768 GiB||Disk Optimized – Attached NVMe Storage||$$$$|
|X family||4-128||122-3904 GiB||Extreme Memory||$$$|
*I family can use Amazon EBS block storage like any other instance but in addition also provide local NVMe disks. All data stored on these local disks is ephemeral which means that all data on it is deleted when the instance is stopped. Both SAP and AWS don’t recommend running any kind of sensitive data on ephemeral disks.
Oracle Database uses disk storage heavily for read/write operations, so it’s highly recommended to use only instances optimized for Amazon Elastic Block Store (Amazon EBS). Amazon EBS-optimized instances deliver dedicated throughput between Amazon EC2 and Amazon EBS. Bandwidth and throughput to the storage subsystem are crucial for good database performance, not only the storage family. Instances with higher network performance provide better database performance.
A typical scenario would run M or R family for the application servers and the R or X family for the DB instance.
(*) Important: SAP BI versions 4.2 SP4 or higher and 4.3 or higher are supported with Oracle databases and Oracle client software.
- For BO on Oracle database running on AWS, the OS for the DB must be Oracle Linux. This is the only supported OS.
- SAP BO BI, versions 4.2 or 4.3 can run on Oracle Linux 7.2 or higher
- For CMS / Processing servers, Oracle client deployed on AWS is only supported on Windows 2019 server and Oracle Linux. Oracle client version 19c will be the minimum release for Windows Server 2019 support on AWS.
- SAP BusinessObjects software is supported on Oracle Databases on Amazon EC2 instances and on Amazon RDS Oracle database offering (announcement February 2021).
- When using Amazon managed RDS database, AWS will provide database level support and the customer needs to contact AWS directly for database related issues.
To meet the high I/O requirements of an SAP production system, it is recommended to use EBS Optimized EC2 instances for databases. To further increase the total number of IOPS that a file system can deliver, multiple EBS volumes can be striped into a single filesystem using software RAID such as a Logical Volume Manager. Each EBS volume is protected from physical drive failure utilizing mirroring in AWS’s underlying infrastructure. Using a software RAID level higher than RAID-0 is therefore not recommended. To further safeguard a database’s recoverability, its log files should be stored on different EBS volume(s) apart from the data files.
Amazon Web Services offers five types of storage (gp2, gp3, io1, io2, st1, sc1) that can be used for the operation of SAP systems: Amazon Elastic Block Store (EBS) EBS provides persistent, reliable storage volumes that can be attached to an Amazon EC2 instance and they are presented as a raw block device to the instance. All Solid State Drive (SSD) backed EBS volume types are supported for SAP workloads, although 90% of our choices should be the recently (Dec 2020) released GP3 storage type, leaving st1 for backups/archiving directories. Don’t even consider sc1.
With Oracle, there is one possible exception for selecting a different storage option to Amazon gp3 class EBS; The Online Redo Logs (RECO data disk group)
Redo is a natural bottleneck for high-update because Oracle Redo Disk must accept the sum of all disk update rates.
Not only REDO host performance-critical volumes, but it’s also the most crucial structure for recovery operations, which consists of two or more preallocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.
Before 2020, gp3 and io2 didn’t exist; REDO’s only options were to use gp2 or io1. Since gp2 does not have the chance to provision the IOPS, the rate was considered in combination with the volume size, the larger the volume was, the better performance it was provided, each 1-GiB gp2 volume delivers 3 IOPS until the máximum of 16000 IOPS. This plays against the RECO disks, which are particularly small but require the highest performance. To solve this, the natural option was to choose io1 disks and provide a minimum (but decent) 3000 IOPS per volume.
It all changed since the introduction of gp3, which has a minimum of 3000 IOPS no matter the volume’s size, but io2 introduces an interesting additional concept, the 99,999 durability, and an interesting CONS concept, its price.
EBS storage gp3 provides a 99.8 – 99.8% durability, which would mean that we would lose one out of every 1000 objects (volumes) every year.
On the contrary, io2 provides a 99,999 durability, 100 times improvement compared to the other options.
|Tier name||Throughput||IOPS||Size||Monthly Cost|
|gp3||1000 MBps||6000||1 GB||30 USD|
|io2||1000 MBps||6000||1 GB||390 USD||13 times more expensive|
The volume type st1 should only be used to store backups or SAP archiving data. All components of an SAP system should be running on SSD Backed EBS storage. EBS volumes function similarly to Storage Area Network (SAN) devices and all communication with the EBS volumes occurs via the storage network provided by AWS to the Amazon EC2 instance, so it’s crucial to select an EBS optimized instance family.
While it is ok to use Amazon Elastic File System (EFS) for sharing global file system directories (like /sapmnt or /usr/sap/trans), EFS must not be used for DB data files or log files due to serious throughput and latency constraints. For details, please see the SAP on AWS Implementation and Operations Guide.
The AWS Cloud infrastructure is global and built around Regions and Availability Zones.
Each Region includes multiple Availability Zones, which are isolated locations with one or more discrete data centers—each with redundant power, networking, and connectivity, housed in separate facilities. When running databases on AWS, users can benefit significantly from Availability Zones, because they are connected to one another with fast, private, fiber-optic networking, providing automatic failover without interruption.
Oracle Database high availability (HA) or Disaster Recovery on AWS relies on AWS Availability Zones and Regions respectively. The primary database and the standby database are placed in different Availability Zones, so if the primary database fails, the standby database can take over.
DR Scenario with CloudEndure Disaster Recovery
CloudEndure Disaster recovery became a preferred option for many when, in 2020, AWS announced an 80% price reduction, the current price is 0,028$ hourly rate for the protected machine. Let’s go through it and how we can take the benefit of SAP and Oracle.
Disaster Recovery tries to tackle IT disasters such as Regional natural disasters, Datacenter Breach, or scale cyber-attacks. CloudEndure Disaster Recovery provides block storage replication.
CloudEndure Disaster Recovery has been tested (and certified by Amazon) to protect the most critical databases, including Oracle, MySQL, SQL Server, as well as SAP.
CloudEndure Disaster Recovery continuously replicates virtual or physical machines (those who accept the agent installation, basically x86 Windows or Linux), including operating system, system state configuration, databases, applications, and files, into a low-cost staging area in the target AWS account and selected Region. In the case of a disaster, CloudEndure Disaster Recovery can automatically launch thousands of machines in their fully provisioned state in minutes.
One of the best benefits of CloudEndure Disaster Recovery is that allows to achieve business continuity for the most critical databases, including Oracle, MySQL, and SQL Server, as well as enterprise applications such as SAP without the need to purchase multiple application-specific replication tools because CloudEndure Disaster Recovery replicates all applications and databases that run on supported operating systems
Best of breed functionalities include
- Automated machine conversion and orchestration
- Point-in-time recovery
- Easy, non-disruptive drills
- Wide application and infrastructure support
HA and DR Scenarios with Oracle Data Guard on AWS
Oracle Data Guard is a feature of Oracle Database Enterprise Edition that provides a set of tools to manage one or more Oracle standby databases for both high availability and disaster recovery. To create an Oracle standby database, replicate the Oracle primary database to a secondary machine by applying its online or archived redo logs. When the standby database is set up, any changes to the primary database are replicated to the standby database, ensuring that the contents of the two databases are in sync.
The following table describes the replication methods associated with Oracle Data Guard protection modes.
|Maximum performance (default)||Asynchronous||Primary database performance is not affected by any delays writing redo data to the standby database.|
|Maximum availability (default)||Synchronous||Commit occurs when all redo data needed to recover transactions has been written to the online redo log and to at least one synchronized standby database. If Data Guard is not able to write to the standby database, behavior will be similar to the maximum performance protection mode.|
|Maximum protection (default)||Synchronous||Changes must be written to both the online redo log and to the standby database for every transaction. If Data Guard is unable to write the redo stream to at least one standby, it will shut down the primary instance. This is a dangerous method only recommended for exceptional situations.|
We can set up an Oracle primary and standby relationship between two EC2 instances in different Availability Zones in the same AWS Region for synchronous or asynchronous replication because they are connected with high-speed links. Alternatively, we can set up asynchronous replication between primary and standby databases in different AWS Regions.
Most Oracle Database users take regular hot and cold backups. Cold backups are taken while the database is shut down, whereas hot backups are taken while the database is active.
With AWS, snapshots refer to EBS volumes, whereas instance snapshots are called AMIs (Amazon Machine Image). While creating AMIs is a recommended approach, DB backups (due to the big size of the EBS volumes) can be an expensive option.
Amazon S3 is the recommended option to store hot and cold backups for high durability and cost-effectiveness.
The only tool certified by SAP, available on both AWS Marketplace and SAP Store is the Emory backing tool.
Emory enables backups to S3 from SAP HANA, Oracle, and ASE hosts. Emory will handle the communication and transportation of the backups to and from Amazon S3 and ensure its integrity and consistency, providing 8x faster recoveries and no need to provide an intermediate EBS volume.
Of course, any traditional backup vendor such as Veeam, Veritas, or Commvault provides server-based backups that can interact with Amazon S3 and many other storage options.
Generally speaking, I will introduce several topics around Oracle Licenses and SAP
Topic 1. The ASFU
SAP customers have two options when choosing an Oracle licensing approach;
- SAP sold Oracle license, called Application Specific Full Use (ASFU) license or also called Oracle runtime or OEM license. This license allows connecting only SAP software to the Oracle database
- This is completely independent of the hardware infrastructure (#Processors, #Users,etc.) the database runs on.
- The use of virtualization technologies is not relevant for the database pricing as well.
- Independently purchased Oracle License, also called Oracle Full Use.
- This license might limit and count the number of processors or users.
Topic 2. The Enterprise Edition
SAP products always require Oracle Enterprise Edition (EE); use with Oracle Standard Edition (SE) is not permitted.
Topic 3. The Core Factor Table
This has been around for many years, customers who decide to purchase an Oracle license through Oracle or a certified reseller, there is a core license factor table that will apply to the AWS infrastructure since all its certified instances run on Intel or AMD based chips.
Topic 4. The Authorized Cloud Environment
In combination with Topic 3, the Core Factor Table, Oracle launched a licensing topic in 2017 that established AWS and Azure as “Authorized Cloud Environment”
The table below shows the list price for an 8 core Intel Xeon server on different platforms as a result of the rules since AWS (and since 2018 with DV3 and Ev3 Azure) instances have the Hyperthreading enabled by default.
AWS, Microsoft, and Google use vCPU as compute performance unit. Each vCPU is defined as a hyperthread of an Intel Xeon or AMD EPYC core. A standard Intel processor core with hyperthreading enabled has 2 threads. One vCPU is equivalent to a single thread.
Oracle Cloud Infrastructure measure for compute. An OCPU is defined as the CPU capacity equivalent of one physical core of an Intel Xeon processor with hyperthreading enabled, or one physical core of an Oracle SPARC processor.
For the Intel Xeon processor each OCPU corresponds to two hardware execution threads, known as vCPUs. For some Oracle SPARC processors, one OCPU corresponds to eight hardware execution threads, also known as vCPUs that particularly favor SPARC over Intel.
The “Authorized Cloud Environment” particularly plays in the favor of Oracle Cloud and Google cloud, which isn’t classed as an authorized cloud provider and so is not subject to this core factor change.
One thing that will be an interesting challenge on AWS would be if we are running dedicated hosts. This is a feature of AWS where we can have a dedicated machine. If we licensed all physical intel CPUs on a dedicated host (https://aws.amazon.com/ec2/dedicated-hosts/), then we are licensing the physical CPUs instead of the vCPUs and using AWS as a hosting partner, not a cloud provider. Well explained on page 19 of this document
Topic 5. Oracle Linux Premier
SAP requires its customers to run under Oracle Linux Premier Support.
Oracle Linux Premier comes under two flavors, Limited and Unlimited.
Both are supported by SAP, but the difference (apart from the price) is that Oracle does not support the “Limited Premier” for instances above 8 vCPU
The below table shows an example of the required licenses to operate an Oracle Linux for SAP applications on the AWS cloud.
Oracle Running on an EC2 instance
Every customer running database workloads like Oracle requires high memory and excellent storage performance characteristics, such as IOPS and storage bandwidth.
Although the processor is the most common metric for licensing Oracle software products, we rarely see Oracle database workloads that are constrained by available CPU resources. Overprovisioning is never a good practice in the cloud, and instance monitoring using Cloudwatch is fundamental.
Also, the Optimize CPU feature provides customers with the ability to disable vCPUs on Amazon EC2 or RDS instances in order to tune the exact CPU allocation—and thus the licensing footprint—to their specific workload needs.
With Optimize CPU, customers can specify a custom number of vCPUs (up to the normal maximum for that particular instance type) when launching new Amazon EC2 or RDS instances in order to save on vCPU-based licensing costs.
We can also disable Intel Hyper-Threading Technology for workloads that perform well with single-threaded CPUs. While the disabling of vCPU resources does not provide any cost savings for Amazon EC2 or RDS instances, it can offer dramatic cost savings by reducing the licensing footprint for those instances hosting Oracle workloads.
Customers running EC2 Dedicated Hosts need to identify how many hosts they want to dedicate to running their Oracle workloads on AWS. This functions just like the Oracle on Amazon EC2, in that the dedicated hosts run workloads in EC2 instances. However, it offers more advantageous licensing options for AWS customers with sufficient Oracle workloads to justify using Dedicated Hosts.
The Dedicated Hosts option works best for customers with many Oracle workloads who want to experience the licensing advantages that come with using dedicated hardware and licensing by traditional processor metrics, rather than using Oracle’s cloud policy. Here the core factor table should not apply.
Also, there is the option to run Oracle on Amazon EC2 Bare Metal. This option provides customers utilizing hosted physical servers with the same scalability and support of AWS. It’s generally only useful with Oracle customers operating at an enormous scale. Like EC2 Dedicated Hosts, it may offer licensing advantages, as we use AWS as a hosting partner, not a cloud provider.
Oracle running on RDS. BYOL or ASFU models only for SAP
We can include the cost of the Oracle Database license in the hourly price of the Amazon RDS service if we use the License Included service model. In this case, we do not need to purchase Oracle licenses separately; AWS has licensed the Oracle Database software. Unfortunately, AWS provides a “License Included” option for Oracle SE, but not for Oracle EE, which is mandatory for SAP. The only option is to directly purchase the licenses to Oracle or operate the SAP BO platform under the SAP ASFU model.
License Included per-hour pricing includes software, underlying hardware resources, and Amazon RDS management capabilities. This service model optimizes license costs and gives flexibility when scaling Amazon RDS instances up or down. We can take advantage of hourly pricing with no upfront fees or long-term commitments. Also, we can purchase Amazon RDS Reserved Instances under one-year or three-year reservation terms. With Reserved Instances, we can make a low, one-time payment upfront for each database instance and then pay a significantly discounted hourly usage rate. Note: The hourly License for the License Included model in Amazon RDS is available only for Oracle Standard Edition One and Standard Edition Two. For other editions of Oracle Database on Amazon RDS and any Oracle Database edition on Amazon EC2, we need to use our own License (that is, acquire a license from Oracle).
This service model also gives the flexibility to resize the instance based on the needs in cases where the standard capacity requirements are much smaller than periodic, predictable spikes, and this service model allows to scale up to absorb the additional capacity needed and scale down to save on cost. For example, we might have databases that require the performance of a db.m5.large instance for most days of the month except for the last three days. During the last three days of the month, the database might be heavily used due to payroll processing and month-end closing. In this scenario, use Oracle Database on Amazon RDS based on the db.m5.large instance type throughout the month, scale up to db.m5.2xlarge for the last three days, and then scale down again. This could translate to 65% or more cost savings compared to using the db.m5.2xlarge instance for the whole month.
Oracle MOS Note 2174134.1