Amazon EC2 R5b Instances now certified for demanding SAP workloads

At AWS, most of the offerings we build are the direct result of customer feedback. One of the things our SAP customers have been telling us is that they are looking for even higher levels of throughput and IOPS and a reduction in the latency of their storage on AWS. Working directly with our customers on these requirements, we are pleased to announce that SAP NetWeaver and SAP HANA have been certified for our latest Amazon EC2 r5b instance type.  R5b instances support storage bandwidth up to 60Gbps and EBS performance of 260K IOPS, providing 3x higher EBS-Optimized performance compared to R5 instances. This allows customers to exceed even extreme storage performance demands of SAP HANA systems and other IOPS-heavy workloads. For example, with r5b’s enhanced storage capabilities, customers can:

· Load SAP HANA tables back into memory faster after a system start or on an on-demand basis

· Reduce data load times even when there are very high I/O demands

· Backup and restore drastically faster than previously possible

Let’s discuss the data reload performance use case first.

Re-loading SAP HANA Tables

SAP HANA customers are used to having data in-memory and ready for processing on-demand. However, before data can be loaded into memory, it must be read and loaded from the storage layer. If the storage layer is not able to satisfy the demands of SAP HANA as quickly as possible, a user can be left waiting for their in-memory system to finish processing a request. The effect of a performance delay might be small if you only need to load 1 table into memory (this “lazy loading feature” is the de facto way SAP HANA loads data into memory) but loading a big table or reloading data after a HANA restart can severely effect your system’s performance. For some SAP HANA users, slow storage sub-system performance effects can range from a poor user experience to even in some cases, lost revenue (e.g. an order entry system that doesn’t process requests quickly enough may lose that customer).

To provide an example of the speed of data reloading capabilities of r5b, we loaded up an SAP HANA database with 418GB of data then simply restarted it to see how fast this data could be loaded and available to SAP HANA again. Here’s an excerpt from the HANA log showing the data reloading times:

On the r5b.24xlarge instance we were able reload all data in just 76 seconds. This comes out to about 5.5GB/s or 44Gbps of throughput when reading data from EBS and including subsequent processing by HANA. Let’s take a closer look at the HANA log.

At 04:52:27, we can see data reload starting with this message: 

Now reloading 31820 tables (loading up to 5 tables in parallel). 

And at 04:53:43 we can see the data reload complete with this message: 

Pre-/Re-Loading of column store tables finished.

We are then able to query HANA to see how much data was reloaded in that 76 seconds:

In addition to raw data reload performance, SAP on AWS customers can also compare published SAP benchmarks to understand the performance characteristics of our EC2 instances. If you do this comparison, you will notice that with r5b, you can also reduce data load times, even in cases where I/O demands are extremely high. Let’s dig into that.

Reducing data load times for I/O-intensive SAP workloads

As part of our testing, we run SAP benchmarks which leverage a SAP BW/4HANA application workload to stress test the performance of the compute, memory, storage and networking capabilities. One portion (phase 1) of the SAP BW edition for SAP HANA Standard Application Benchmark Version 3 loads data into the BW/4HANA system. We can easily compare the different capabilities of EC2 instances when vCPU, RAM, and the number of records used in the benchmark are the same. This happens to be the case with our r5.metal and r5b.24xlarge instance types. The major differences between these 2 instance types is the r5.metal is a bare metal nitro instance (has no hypervisor) while the r5b.24xlarge instance has the same vCPU and memory configuration but also has increased I/O and storage performance. Looking at the results of our published r5.metal benchmark, phase 1 results completed in 21,091 seconds (a lower number is better here). Comparing the difference between the phase 1 data load times on r5.metal vs r5b.24xlarge, we can see that the r5b.24xlarge performs almost 25% faster.

Backing up SAP HANA

We also tested backup/restore scenarios, which customers have often told us they want to be able to complete as quick as possible. To do this we leveraged AWS Backint Agent for SAP HANA. This agent allows you to backup or restore your SAP HANA database directly to Amazon S3 using SAP management tools, such as the SAP HANA Cockpit, the SAP HANA Studio, or SQL commands. It supports full, incremental, differential, and log backup of SAP HANA databases and catalogs to Amazon S3. There is no cost to use AWS Backint Agent and you only pay for the underlying AWS services you use (e.g. Amazon S3 consumed by the backups). As you can see below, we were able to back up a 544 GB HANA database in less than 5 minutes.

Having the ability to back up your most important data in such a small timeframe means that you one less thing to worry about when running your mission critical SAP systems on AWS.

We are excited to share these new SAP on AWS capabilities with you and look forward to hearing from you. You can deploy R5b instances with our automated deployment tools including SAP HANA Quick Starts. If you have questions or would like to understand the options for your SAP systems, please contact us or visit aws.com/sap to learn more.

Start building on AWS today and have fun!