

# 14 – Select the optimal storage solution
<a name="design-principle-14"></a>

 **How do you select the optimal storage solutions for your SAP workloads?** How you configure this storage will impact the performance of your system. AWS offers a wide range of services, including block, file, and object storage, to meet the storage needs of your SAP databases, applications, and backups. We recommend following the guidelines that have been benchmarked and certified by SAP. For SAP HANA, there are very specific guidelines. Other databases will require more analysis to match your workload. 

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-14.html)

# Best Practice 14.1 – Create mount points and volume associations to align with function
<a name="best-practice-14-1"></a>

 SAP filesystems have unique performance and sharing requirements. For example, the performance profile of the database may require the data filesystem to support a high number of read I/O operations, while the log filesystem is more likely to be constrained by throughput. Filesystems such as `sapmnt` and `trans` need to be shared so that all application servers can access logs and transport files. Recognizing these differences, consider the mapping of filesystems to volumes to ensure there are no performance bottlenecks and that access requirements are met. 

 **Suggestion 14.1.1 – Identify the SAP filesystems and directory requirements for each System** 

 SAP filesystems include system directories (root, boot), executables, page or swap, and application-specific requirements. Each of these should be analyzed to consider: 
+ The impact when a file system is at capacity (100% used), particularly for the root directory
+ Consistency of build, including whether it is included in an AMI, or deployment patterns
+ Resilience requirements
+ Sharing requirements
+ Performance profile

The core SAP filesystem requirements are listed in the SAP documentation. Use these as a baseline and include other requirements specific to your organization.
+ SAP Documentation: [SAP Required Filesystems and Directories](https://help.sap.com/docs/SLTOOLSET/910828cec5d14d6685da380aec1dc4ae/de6cad1446a743d3853dbcae48bddfba.html?version=CURRENT_VERSION)

 **Suggestion 14.1.2 – Map the appropriate AWS storage service to match with filesystem function** 

A filesystem can either be local or shared (NFS / SMB). For shared filesystems consider using AWS services, such as Amazon EFS and Amazon FSx, which provide reliability and availability benefits when compared with a hosted NFS server.

Amazon EC2 instance store is another filesystem option which provides temporary block-level storage for your instance. We do not recommend its use due to lack of persistence, availability across instance types, and because it prevents the use of instance recovery.

 **Suggestion 14.1.3 – Use supported filesystem types** 

 The SAP-supported Linux distributions recommend a number of different file system types. Later versions are standardizing on XFS, but support should be reviewed to ensure there is no performance or functionality impact for your operating system and database version. 
+  SAP Note: [405827 - Linux: Recommended file systems](https://launchpad.support.sap.com/#/notes/405827) [Requires SAP Portal Access] 
+  SAP Note: [2972496 - SAP HANA Filesystem Types](https://launchpad.support.sap.com/#/notes/2972496) [Requires SAP Portal Access] 

# Best Practice 14.2 – Select and configure EBS types aligned with performance requirements
<a name="best-practice-14-2"></a>

For each filesystem function and storage service, evaluate storage layout guidelines and tuning options to ensure that IOPS and throughput performance are optimized.

 **Suggestion 14.2.1 – Evaluate storage characteristics and options for EBS volume types** 

AWS has a range of volume types with unique characteristics to suit different performance requirements of SAP workloads. Use historical data, or sizing to evaluate the IOPS and throughput requirements. Select your volume type by considering performance, durability, flexibility, and cost.

 IOPS and throughput of the `gp3` , `io1`, and `io2` Block Express volume types are independent of the volume size. 

 IOPS and throughput of the `gp2` volume type is aligned to the volume size. Oversizing the volume may be required to ensure the required IOPS and throughput is available. 

If choosing Amazon EBS io2 Block Express, ensure that it is available for the selected instance types.
+  AWS documentation: [Amazon EBS volume types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) 

 **Suggestion 14.2.2 – Scale linearly using LVM striping mechanisms** 

When the performance requirement cannot be met by a single EBS volume, consider striping using Logical Volume Management (LVM). For example, if a single volume has 250 MiB/s throughput capacity, having a stripe set across four volumes can deliver 1000 MiB/s throughput.

Volumes should be of the same size and performance characteristics.

In SAP HANA benchmark testing, the best performance has been achieved using a 256 KB stripe size for data volumes and a 64 KB stripe size for log volumes.

 Be aware of instance limits for throughput, I/O, and number of attached volumes. 
+  AWS Documentation: [Create an LVM Logical Volume on an EBS Volume](https://aws.amazon.com/premiumsupport/knowledge-center/create-lv-on-ebs-volume/) 
+  SAP Note: [2931808 - Usage of Logical Volume Manager (LVM) with SAP HANA](https://launchpad.support.sap.com/#/notes/2931808) [Requires SAP Portal Access] 
+  AWS Documentation: [Operating System and Storage Configuration - SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/operating-system-and-storage-configuration.html#:~:text=Configure%20Storage%20for%20SAP%20HANA) 

 **Suggestion 14.2.3 – To ensure SAP HANA performance, follow AWS provided storage guidelines** 

 AWS works with SAP to certify storage for SAP HANA workloads according to defined performance benchmarks. The configuration provided by AWS balances performance, cost, and durability within the framework of the SAP TDI 5 Storage KPIs. A compliant storage layout is detailed in the documentation and used in Launch Wizard and quick start deployments. 
+  AWS Documentation: [Storage Configuration for SAP HANA - SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/hana-ops-storage-config.html) 

 If you deviate from the AWS configuration, it is recommended that you run the SAP HANA Hardware and Cloud Measurement Tools.
+ SAP Note: [2493172 - SAP HANA Hardware and Cloud Measurement Tools](https://launchpad.support.sap.com/#/notes/2493172) [Requires SAP Portal Access]

 

When deciding between general purpose and Provisioned IOPS EBS types, it should be noted that general purpose types meet the SAP HANA Storage KPIs. An in-memory database, such as SAP HANA, has to load data from disk to memory upon database startup. Using Provisioned IOPS EBS types can significantly improve startup times and also speed up tasks such as backups and restores, which are dependent on storage performance.

 ** Suggestion 14.2.4 – For performant local backups at a low cost, use `st1` storage ** 

 When SAP solutions need local storage for storing backups, consider using a `st1` volume type for its low cost and high throughput. `st1` is a low-cost block storage type designed for frequently accessed, throughput-intensive workloads. 

For SAP HANA, consider using AWS Backint Agent for SAP HANA to avoid the performance and cost impact of a two-stage backup.

# Best Practice 14.3 - Evaluate Amazon EFS and Amazon FSx performance suitability for your SAP use case
<a name="best-practice-14-3"></a>

Amazon EFS (Linux) and Amazon FSx (Windows) provide highly durable and available file systems that can span multiple Availability Zones. Both solutions are designed to deliver high performance, however, when choosing to use network file systems consider the access patterns. For example, many small files, highly parallel writes or high write/read ratios might not be suitable. For SAP workloads, this might apply to SAP HANA XSA, Java executables, or large numbers of job and spool logs.

Amazon FSx for NetApp ONTAP is also a SAP-certified storage type for workloads including S/4HANA, Business Suite on HANA, BW/4HANA, Business Warehouse on HANA, and Data Mart Solutions on HANA. FSx for ONTAP allows you to easily create application-consistent snapshots, space-efficient database clones in seconds and automatic replication of your database across AWS Regions.

 **Suggestion 14.3.1 – Evaluate scale and performance options** 

 Amazon EFS has two modes for performance (general purpose and max I/O) and two different performance modes (bursting mode and provisioned). For SAP applications, general purpose performance mode usually provides sufficient I/O. There may be scenarios in which provisioned throughput should be considered, such as when the amount of data in your file system is low relative to throughput demands. 
+  AWS Documentation: [Amazon Elastic File System (EFS) \$1 FAQs - Scale and Performance](https://aws.amazon.com/efs/faq/#Scale_and_performance) 
+  AWS Documentation: [Amazon FSx for Windows File Server Features \$1 Scale and Performance](https://aws.amazon.com/fsx/windows/features/#Performance_and_scale) 
+  AWS Documentation: [SAP HANA on AWS with Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-amazon-fsx.html) 

 **Suggestion 14.3.2 - Consider temporary provisioning for short-term requirements** 

Use cases related to migrations or one-off activities might benefit from a temporary file system where performance characteristics can be adjusted for the duration of the event.

# Best Practice 14.4 – Consider memory as an alternative to storage
<a name="best-practice-14-4"></a>

Consider the performance advantages of using memory for supported scenarios in the database or application layer. SAP HANA uses memory by default, but might benefit from options to optimize load or offload static data. Relational databases should take advantage of caching, and application servers should consider if swap is a requirement.

 **Suggestion 14.4.1 – Optimize memory usage for SAP HANA** 

 Seek to understand the correlation between SAP HANA memory requirements and operating system memory indicators to help ensure that memory bottlenecks do not impact performance. 
+  SAP Documentation: [SAP HANA Memory Usage and the Operating System](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/ca10596b37f04909a96614553cb8ab1d.html#:~:text=Virtual%2C%20Physical%2C%20and%20Resident%20Memory&text=On%20most%20SAP%20HANA%20hosts,operational%20use%20by%20a%20process.) 
+  SAP Note: [1999997 - FAQ: SAP HANA Memory](https://launchpad.support.sap.com/#/notes/1999997) [Requires SAP Portal Access] 

 To improve database startup performance in scenarios that do not involve a host restart, consider the use of the SAP HANA Fast Restart option. The SAP HANA Fast Restart option dedicates a portion of RAM as a temporary file system (`tempfs`), which is treated by the operating system as persistent memory (until operating system restart) and allows placement of column store main portion in that `tempfs`, which remains there through an index server restart or crash. Thus, no reloading from storage (using I/O) is necessary. 
+  SAP Documentation: [HANA fast restart documentation](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/ce158d28135147f099b761f8b1ee43fc.html) 

 **Suggestion 14.4.2 – Use database caching for relational databases** 

For a relational database with high read IOPS requirements, database caching allows you to significantly increase throughput and lower the data retrieval latency. The cache acts as an adjacent data access layer to your database, to improve read performance.

 The following documentation provides information about caching use-cases, but as most of this detail is relevant to AWS databases, consult SAP Notes for information specific to your relational database configuration. 
+  AWS Documentation: [Caching](https://aws.amazon.com/caching/) (including [database caching](https://aws.amazon.com/caching/database-caching/) ) 

 **Suggestion 14.4.3 – Evaluate swap space requirements for SAP applications** 

When physical memory resources are exhausted, SAP uses swap to move inactive pages to a dedicated disk-based storage area. Although having swap can prevent the application from crashing due to memory insufficient memory, we recommend applying configuration parameters and memory sizing so that swap is used infrequently.

 If swap usage is expected, evaluate the characteristics of the allocated volume to avoid further performance issues. Swap can prevent out of memory situations for SAP applications, when the host runs out of physical memory. 
+  SAP Note: [153641 - Swap space requirement for R/3 64-bit kernel](https://launchpad.support.sap.com/#/notes/153641) [Requires SAP Portal Access] 
+  SAP Note: [2999334 - SWAP Utilization](https://launchpad.support.sap.com/#/notes/2999334) (HANA related) [Requires SAP Portal Access] 
+  SAP Note: [2488097 - FAQ: Memory usage for the ABAP Server on Windows](https://launchpad.support.sap.com/#/notes/2488097) [Requires SAP Portal Access] 

# Best Practice 14.5 – Choose appropriate backup solutions and schedule
<a name="best-practice-14-5"></a>

Depending on the backup method, there is the potential to dramatically increase both read and write operations on your storage, which can negatively impact the performance of your application. This is particularly true for database level backups which might be large in volume and lengthy in duration.

 **Suggestion 14.5.1 – Determine a suitable backup window** 

Define what is the most appropriate window for the running of backup operations aligned to your business requirements. Consider key dependencies such as the overnight batch schedule and the acceptable runtime.

 **Suggestion 14.5.2 – Consider options to minimize the performance impact of backups** 

 Analyze any storage or network constraints and evaluate options to minimize the impact of the backup. This may include reducing the duration by using delta change backups either at a database or storage level. Refer to the Reliability Pillar to ensure this does not negatively impact the consistency of backups or the overall restoration time. 
+  SAP Lens [Reliability]: [Best Practice 12.1 - Establish a method for consistent recovery of business data](best-practice-12-1.md) 