EDUCAÇÃO E TECNOLOGIA 

Running SAP on Amazon FSx for NetApp ONTAP

lwrc

Ontap is NetApp’s flagship NFS technology for storage. In September 2021, Amazon released Amazon FSx for ONTAP. Later in May 2022, SAP certified this technology for its workloads running on AWS. Some essential benefits and limitations exist. Since it is super interesting, let’s explore it in this blog.

While other traditional NAS products such as Dell EMC PowerScale, Hitachi NAS, and IBM Spectrum Scale can migrate data to the public cloud, NetApp has gone more profound in its cloud integration. NetApp sells Cloud Volumes OnTap (CVO) and Cloud Volumes Service (CVS) through some public clouds. CVO is a virtual OnTap instance that runs in the cloud, while CVS is a file service that NetApp manages.

However, Amazon FSx represents the most profound integration for ONTAP with a public cloud because AWS sells FSx for NetApp OnTap as a fully managed service for file systems, featuring data management capabilities that support various use cases; FSx for Lustre is Linux-only and uses a performance-optimized Portable OS Interface file protocol. Windows uses the SMB protocol, OpenZFS uses NFS, and ONTAP supports NFS and SMB file protocols plus iSCSI for shared block storage.

FSx for ONTAP supports all the features NetApp delivers in its on-premises systems, so SAP on AWS users can also get features such as SnapMirror, SnapVault, and FlexCache, and this is the added value of this offering.

Since FSx for ONTAP has only been certified for HANA, I will only compare it with the other solutions available for HANA, excluding other Databases options.

SAP HANA’s peculiarity is that it stores and processes its data in memory; the attached disk protects against data loss by saving it in persistent storage locations. To achieve optimal performance, the attached storage solution used for SAP HANA DATA and LOG volumes must meet SAP’s storage KPI.

With SAP on AWS, we have two main storage options, Amazon EFS and EBS.  Elastic File System (EFS) is an OS-agnostic network file system based on NFS. SAP customers are quite familiar to the EFS NFS for shared filesystems, but it cant be used for large DATA and LOG volumes. EBS is Amazon Block-level Storage, attached to EC2 instances, suitable for DATA and LOG, but not recommended for the shared filesystems. FSx covers all filesystem usages.

  • Only suitable for HANA single node
    • This means no HANA Scale-out, distributed
    • This means no HANA Host Auto Failover
  • FSx must be in Single AZ Deployment type
    • No Multi AZ for FSx for ONTAP
    • /hana/data, /hana/log, /hana/shared, and /usr/sap must have their own volumes
  • List of HANA-supported instances in this link
  • Production HANA workloads must have a throughput capacity of at least 1,024 MB/s
  • Storage Efficiency is not supported for SAP HANA and must be disabled.
    • Deduplication benefit is lost
    • Compression Benefit is lost
  • Capacity Pool Tieringis not supported for SAP HANA and must be set to none.
    • 100% of data in SSD
  • Daily automatic backups must be disabled for HANA volumes. Backups and Replication can be done with SnapCenter
  • Snapshot policy to none; snapshots must be done with SnapCenter
  • NFS 4.1 is highly recommended

The following table lists the most common use cases for instances and file sharing solutions for SAP HANA landscapes on AWS and the solutions that support the use cases.

  EFS EBS FSx for Ontap
Storage type NFS v4

SSD gp2, gp3, io1, io2

 NFS v4, SMB/CIFS
Cost* $0.3 per GB/month and $6 per MB/month for provisioned throughput $0.125 – $.045per GB/month, depending on volume type $0.125 – $.055per GB-month, plus additional options
Availability and Accessibility

99.99% EFS Standard

Accessed by up to 1K instances from multiple AZ or Regions

99.99% to 99.999% durability

Accessed via a single EC2 instance

99.9% for Single AZ, 99.99 for Multi AZ, though not suitable for HANA on AWS

Accessed via single EC2 instance
Storage and File Limits

Unlimited storage size

47.9 TB file size

16 TB storage per volume with unlimited volumes

File size limited by volume size

 1TB to Unlimited storage
Disaster Recovery EFS replication DRS – aka CloudEndure, suitable for SAP systems on AWS Automated with Snapmirror
High Availability (for SAP) EFS Standard is Multi-AZ Multi-AZ with Cluster services like SLE HA and RHCS FSx for ONTAP can work in MultiAZ but it’s not certified for SAP
Snapshots N/A

AMI based. See SAP note 2039883 for limitations

Volume snapshot Disable. HANA application awareness. Recommended to disable by setting the policy to none.

This affects snapshot, snapmirror, flexclone
Backups EFS Backup

backint to S3 with several tools available

3rd party software

 Daily automatic backup disabled, backups and replication should be done with SnapCenter
Data Tiering N/A N/A Capacity Pool Tiering exists but not available for SAP HANA.
Migration Services AWS DataSync, excluding HANA files

HSR works on DB level. No storage replication for EBS

Migrate using AWS MGN for HANA, previously known as Cloudendure Migration

Migrate On-prem to cloud using SnapMirror replication
Performance

35kIOPS

500 MiBps throughput

check

Up to 256k IOPS

4k MiBps troughput

check

+100k Network IOPS

80k SSD IOPS

3k MiBps throughput
Suitable for SAP HANA

/usr/sap/trans

/sapmnt

HANA Shared and Backup

HANA volumes – DATA and LOG

/usr/sap/<SID>

/usr/sap/trans

/sapmnt

HANA volumes – DATA and LOG
AZ Failure Redundant, it survives an AZ failure Only through data replication or EBS snapshot Yes for FSx for ONTAP but not certified for HANA

SnapMirror. This replication technology is the alternative to HANA System Replication with the benefit of not having an EC2 instance attached. FSx for ONTAP cant be implemented in Multi-AZ so that SnapMirror could be used for DR purposes.

SnapVault. Disk-based storage backup. Snapvault is a technology that could be used in combination with SnapCenter.

FlexCache. It’s an inter-cluster caching for FSx and can work for Multi-region or from On-prem to AWS.

FlexClone. Cloning mechanism for volumes. FlexClone can be used for HANA refreshes.

Cloud Manager. A centralized user interface to manage, monitor, and automate ONTAP deployments in AWS. SnapMirror replication can be controlled from Cloud Manager.

Users are billed for file systems based on the following categories:

  • SSD storage capacity (per GB-month)
  • SSD IOPS over 3 IOPS/GB (per IOPS-month)
  • Throughput capacity (per megabytes per second [MBps]-month). 1024 MBps for SAP production needed
  • Capacity pool storage consumption (per GB-month)
  • Capacity pool requests (per read and write)
  • Backup storage consumption (per GB-month)

Price for Single AZ comparison of FSx for Ontap vs. EBS gp3

Assume we want to store 10 TB of data in the US East (N. Virginia) Region for a production SAP HANA DB where 100% of the data is stored in SSD, single Az.

By default, 3k SSD IOPS are included for every GB of SSD storage in FSx for Ontap and gp3.

Assume to provision 1024 MBps of throughput capacity and have no backup data during the month; we would use backint or SnapCenter.

gp3 volume throughput can not exceed 1000 MBps, so we would need to stripe at least two volumes of 512 MBps to meet 1024 MBps on DATA or LOG

  • Total gp3 cost 973 USD
  • Total FSx for Ontap cost 2017 USD
  • NetApp on-premises users can efficiently replicate HANA volumes to FSx for ONTAP to support disaster recovery without dedicated application servers.
    • NetApp cloning features can be used for DR testing without interruption to verify that the defined Recovery Point Objective (RPO) can be met.
    • Eliminates risks by performing efficient DR testing using native cloning technology without breaking the mirror.
    • Leverages DR replication image for additional development/test system copies
  • If appropriately configured, Application-consistent HANA backups leveraging snapshot copies create zero performance load.
  • Use FlexClone for quick snapshots and QA Refresh.

Using cluster technologies to achieve high availability are well documented in multiple SAP docs and 3rd party tools. An exciting technology for high availability, using N+M scale-out nodes, is provided natively by SAP’s ‘host auto-failover mechanism. An NFS filesystem, like NetApp ONTAP, with its sub-millisecond capability, allows an N+M architecture where an additional standby node can provide a failover for a host using a shared storage, all without the need to implement an OS cluster or data replication. Such technology offers excellent value for a HANA scale-out deployments. As soon as FSx for ONTAP gets certified to run on Multi-AZ for SAP HANA, this will be a perfect option for SAP on AWS users.

Nowadays, for Multi-region or hybrid deployments, by using Cloud Manager, we can simplify the data replication process by mirroring data between FSx for ONTAP file systems in different regions or replicating data from an on-prem ONTAP-based system to FSx for ONTAP using SnapMirror.

Links

https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-amazon-fsx.html

https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html

https://docs.netapp.com/us-en/ontap/pdfs/fullsite-sidebar/ONTAP_9_Documentation.pdf

https://fsxontap.calculator.aws/