SAP on Azure NetApp Files Sizing Best Practices

This article provides guidelines for properly sizing SAP deployments on Azure NetApp Files (ANF) to achieve optimal performance and cost-effectiveness. It emphasizes the importance of accurate capacity and performance estimation to avoid overprovisioning or underutilization of resources. The article introduces the "SAP on Azure NetApp Files Sizing Estimator" tool, which automates the sizing process and helps customers and partners to make informed decisions. By following these sizing guidelines and leveraging the tool, customers and partners can optimize their SAP landscapes on ANF for improved efficiency, reliability, and cost-effectiveness.

Co-authors: Tobias Brandl, SAP Solutions Architect (NetApp)

Introduction

Overview of SAP deployments on Azure NetApp Files and its benefits

SAP deployments on Azure NetApp Files (ANF) offer a range of benefits that streamline operations, enhance performance and scalability, and provide robust data protection. In this section, the key advantages of utilizing Azure NetApp Files for SAP workloads are discussed.

Simplified Operations

One of the primary benefits of Azure NetApp Files is its native Azure experience, which simplifies deployment and scalability. Azure NetApp Files is a first-party Microsoft service of the Azure platform. With Azure NetApp Files, customers can provision and consume an entire file system rather than managing individual disks, offering a Platform-as-a-Service (PaaS) approach instead of Infrastructure-as-a-Service (IaaS). This streamlined management can be performed directly from the Azure portal, allowing for easy administration and control.

Furthermore, Azure NetApp Files provides built-in high availability, backed by a 99.99% service level agreement (SLA). This ensures that SAP deployments remain highly reliable, minimizing the risk of downtime and maximizing business continuity.

Performance and Scalability

Azure NetApp Files delivers enterprise-grade performance for SAP environments. With sub-millisecond latency, it enables fast and responsive interactions with SAP applications and databases. It is certified for SAP HANA deployments and also supported for SAP on AnyDB, including Oracle, DB2, and ASE. This flexibility allows to leverage Azure NetApp Files for a wide range of SAP landscapes.

Additionally, Azure NetApp Files provides on-demand scalability, allowing to adjust both performance and capacity as needed. Whether increased performance is required for high-demand periods or additional storage capacity for growing data volumes must be provided, Azure NetApp Files can dynamically scale to meet these requirements. Scaling down on both performance and capacity to save costs is also possible without any interruption of the application. This flexibility allows to optimize performance and cost-effectiveness of SAP workloads.

Built-in Technology for Enhanced Data Protection

Data protection is a critical aspect of SAP deployments, and Azure NetApp Files offers built-in technologies to ensure the safety and recoverability of SAP data. One such feature is snapshot backup and restore operations, which can be performed in seconds, even for very large databases. This rapid snapshot capability allows for efficient data protection in an application consistent manner and quick recovery in case of accidental deletions or corruptions.

Azure NetApp Files also provides vaulting snapshots to Azure storage (via ANF backup), enabling long-term retention and off-site backups. This feature further enhances data protection by leveraging Azure's durable and scalable storage capabilities.

For disaster recovery scenarios, Azure NetApp Files supports replication, including cross-zone and cross-region replication. This simplifies the implementation of robust disaster recovery strategies, ensuring business continuity in the event of a catastrophic failure.

Additionally, Azure NetApp Files integrates with application-aware orchestration tools, facilitating seamless backup and recovery operations specifically designed for SAP environments. This integration enables efficient system refreshes and cloning of SAP systems, or the deployment of entirely new systems in a very short amount of time.

In summary, SAP deployments on Azure NetApp Files offer a range of benefits, including simplified operations, high performance and scalability, and enhanced data protection. By leveraging these advantages, customers can optimize their SAP landscapes for improved efficiency, reliability, and agility.

Importance of proper sizing for optimal performance and cost-efficiency

Proper sizing is a key aspect for SAP deployments on Azure NetApp Files as it directly impacts the performance, cost-efficiency, and end-user experience. Achieving optimal performance is crucial in SAP environments to ensure that applications and databases operate smoothly and deliver a responsive user experience.

On the other hand, oversizing can lead to unnecessary costs and inefficient resource utilization. Oversized deployments consume more resources than necessary, resulting in increased cloud costs. By accurately sizing the infrastructure, customers can avoid overprovisioning and optimize their cloud spend. Azure NetApp Files provides the flexibility and elasticity required to scale resources up or down based on workload demands, allowing organizations to adjust performance and capacity dynamically to meet changing requirements.

SAP workloads often exhibit varying performance needs throughout the lifetime of a system. For example, during system startup, there may be increased demands to accelerate data load into memory for SAP HANA databases. Month-end close operations or peak season requirements might require additional compute and storage resources to handle high transaction volumes effectively. By considering these varying performance needs, customers can fine-tune their sizing decisions to align with specific workload characteristics and optimize the overall system performance.

Azure NetApp Files, with its on-demand scalability, enables customers to adapt to these changing performance requirements seamlessly. It provides the flexibility to scale both performance and capacity as needed, ensuring that SAP workloads can meet peak demands without sacrificing performance or incurring unnecessary costs during low-demand periods. By leveraging Azure NetApp Files' dynamic scaling capabilities, organizations can achieve the optimal balance between performance, cost, and agility in their SAP deployments.

In conclusion, proper sizing is essential for SAP deployments on Azure NetApp Files. It ensures optimal performance while avoiding unnecessary costs associated with oversizing. By considering the varying performance needs of SAP workloads and leveraging the flexibility and elasticity of cloud services, particularly Azure NetApp Files, customers can achieve an optimal sizing strategy that maximizes performance, cost-effectiveness, and scalability.

Objective of this article

The objective of this article is to provide guidelines for properly sizing Azure NetApp Files for SAP deployments with a clear focus on SAP HANA databases. An understanding of key features and capabilities of Azure NetApp Files that are relevant to SAP workloads is an important aspect of sizing exercises. By assessing the performance and capacity requirements of the SAP landscape, readers will be able to make informed decisions and apply sizing best practices.

To further support sizing efforts, this article will introduce the "SAP on Azure NetApp Files Sizing Estimator" tool. This tool provides a structured approach to help customers and partners to enter their SAP HANA workload requirements and generate recommended sizing configurations for Azure NetApp Files. By leveraging this tool, users can streamline their sizing process and ensure accurate and efficient resource allocation.

Understanding Azure NetApp Files

To properly size Azure NetApp Files for SAP environments, an understanding of the key features and capabilities relevant to sizing considerations is important.

ANF storage hierarchy and capacity pools

Azure NetApp Files deployments are structured by a specific storage hierarchy. Figure 1 shows that hierarchy. An ANF deployment always belongs to a specific Azure subscription, and it consists of one or more NetApp accounts. Each NetApp account is assigned to an Azure region.

That means if volumes for SAP systems need to be deployed in two regions to provide a cross-regional disaster recovery solution, a minimum of two NetApp accounts are required, one in each region. One NetApp account contains one or more capacity pools and each pool can host one or more ANF volumes. A capacity pool serves as a virtual bucket of capacity and performance from which volumes can be configured. A capacity pool defines the ANF service level (also called “tier”) and the ANF quality of service (QoS) type (more on that in the following section).

A capacity pool “spans” all Azure availability zones (AZ) in a region, i.e. there’s no need to have multiple capacity pools in a region to deploy SAP high-availability (HA) scenarios across multiple availability zones. And most importantly, the billing of ANF happens based on provisioned capacity pools – not on provisioned volumes. That means from a cost point of view it doesn’t matter if a single small volume is deployed in a pool, or tens or hundreds of larger volumes, as long as they fit into the configured pool. More information about the storage hierarchy can be found at Storage hierarchy of Azure NetApp Files.

Figure 1) ANF storage hierarchy

Apart from the storage hierarchy itself, a few other key features of ANF are relevant for a full SAP landscape sizing. These are mainly ANF snapshots which are used to provide a very efficient way to perform application consistent backups of SAP databases and other file systems, and ANF backup, a feature to replicate or offload ANF snapshots to a backup vault location to provide redundancy and a lower-cost storage option for mid- and long-term retention backups. In addition to that, ANF cross-region replication (CRR) is used to provide DR protection of SAP landscapes and in this case needs to be included in the sizing as well.

Understanding service levels and QoS settings

As mentioned, each ANF capacity pool has an assigned service level which defines the performance characteristics of its volumes. ANF currently offers three service levels: standard, premium, and ultra as also described here: Service levels for Azure NetApp Files. The service level defines the available throughput in the capacity pool based on the provisioned capacity. Each service level provides a certain throughput per provisioned TiB of capacity, which is:

Standard: 16 MiB/s per 1 TiB
Premium: 64 MiB/s per 1 TiB
Ultra: 128 MiB/s per 1 TiB

As an example, a 10 TiB capacity pool of service level standard would provide a total of 10 x 16 MiB/s = 160 MiB/s of throughput, whereas a 10 TiB ultra capacity pool would provide a total of 10 x 128 MiB/s = 1280 MiB/s. The QoS setting of the capacity pool then defines how that performance can be assigned to individual volumes within the capacity pool.

There are two QoS settings available: auto QoS and manual QoS.

With auto QoS the volume performance is automatically derived from the service level baseline performance and the provisioned capacity of the volume (sometimes also referred to as volume quota) – the bigger the provisioned volume size, the more performance the volume would get. As an example, a 2 TiB volume in a premium capacity pool would get a 2 x 64 MiB/s = 128 MiB/s throughput limit. A 100 GiB volume in that same premium capacity pool would get 0.09765625 TiB x 64 MiB/s = 6.25 MiB/s.
With manual QoS, the performance limits and the capacity of a volume can be assigned manually and independent of each other to a specific volume – as long as the assigned capacity and throughput is available in the hosting capacity pool. Assuming a 10 TiB Ultra capacity pool from the previous example, with manual QoS you could deploy a small SAP HANA log volume of 0.5 TiB and assign 250 MiB/s throughput to it. You could then have a SAP HANA data volume of 4 TiB and assign 700 MiB/s, a SAP HANA shared volume of 1 TiB and 50 MiB/s and a log backup volume of 4.5 TiB and assign the remaining 280 MiB/s from the pool. This provides much more flexibility and granularity compared to auto QoS and leads – especially in SAP environments – to a more cost-effective deployment by avoiding large amounts of capacity overprovisioning in order to get the right level of performance, especially for smaller volumes.

Manual QoS capacity pools have become the de-facto standard for SAP deployments, and the remainder of this article focuses on that QoS type. In addition, some advanced features of ANF, e.g. application volume group (AVG) for SAP HANA (Understand Azure NetApp Files application volume group for SAP HANA), require the usage of manual QoS pools.

For ANF sizings it is important to know that almost all settings and configurations of a volume can be changed at any point in time without any interruption to the application that is using the data. That means a volume can be assigned to a different capacity pool to change the service level, the volume size and throughput can be increased and decreased, and finally, the size of a capacity pool can be increased and decreased to provide additional total capacity and throughput or to downsize for cost-optimization.

Understanding Azure NetApp Files snapshots and backup

Since ANF can and should always be used to not only provide primary storage for SAP applications for reasons of performance and scalability alone, but also as a very modern and efficient way to implement a backup architecture, the relevant features (i.e. snapshots and ANF backup) are discussed here as well. A very good and comprehensive description of these features can be found here: How Azure NetApp Files snapshots work.

An ANF snapshot is a point-in-time image of the file system (volume). It’s ideal to serve as an online backup because it is created – and restored – in a matter of seconds. ANF snapshots are very space-efficient because based on the underlying technology, snapshot data is not written to a specific location but basically storage blocks are kept in place and are “frozen” and only new and modified blocks are stored separately. This avoids any IO overhead with snapshots and from a capacity point of view only changed data (to be precise: changed storage blocks) consumes additional space. Consequently, it is important to properly estimate the block-level change rate of a specific application or workload to estimate the required snapshot capacity in a volume. To simplify things, the change rate is typically estimated as “daily change rate” and as such it is provided as a percentage of the actual data in a volume. Multiplying the resulting amount of data that’s changed per day by the number of days snapshots would be kept on the ANF volume (i.e. the “snapshot retention”) gives an estimate of the total snapshot capacity that’s required on the volume in addition to the actual data.

ANF snapshots are stored together with the actual application data in the same ANF volume. If snapshots are kept for a longer period (the definition of “long” here depends on the daily change rate), most of the capacity consumed in that ANF volume is snapshot data. That can drive up the ANF cost and have an impact on the TCO. In addition, from a data-protection standpoint - following a standard 3-2-1 backup strategy - a second copy of the snapshot backups in a different location is required to avoid data loss in case the primary ANF volume is no longer accessible. With “ANF backup”, ANF offers a built-in functionality to efficiently replicate or “vault” snapshots into a ZRS-enabled (zone redundant storage) Azure storage, where available. Storing snapshot data on the ANF backup vault is much more cost-efficient and it serves as a second, independent copy of the backup data which can be accessed even if the primary ANF volume is no longer available. The amount of data stored on the ANF backup vault is also dependent on the daily change rate. During the initialization of ANF backup for a specific volume, the entire application data is replicated to the vault location – this is called the “baseline copy”. Afterwards only block-level changes (identical to the ANF snapshot mechanism) are replicated and stored. Therefore, the total amount of data stored on the ANF backup side can be estimated by the formula:

(o) Tip

ANF backup capacity = baseline copy + (actual data size * daily change rate * retention in days)

Understanding Azure NetApp Files cross-region replication

The Azure NetApp Files cross-region replication (CRR) functionality enables the replication of volumes between supported cross-region replication pairs. This functionality allows to replicate a volume from a source region to a volume on the destination region for disaster recovery (DR).

Instead of using HANA System Replication (HSR), cross-region replication can be used to protect a database without needing a HANA database server that runs all the time. To create a replication, a destination volume in a region supported for cross-region replication needs to be provisioned and then the replication can be established. The replication itself is based on the same technology that is used for the ANF backup functionality described in the previous section. From a sizing point of view, it’s therefore important again to understand the daily change rate of an application or workload. The destination volume not only contains the actual data, but also all snapshots that exist on the source volume are available on the target volume. Therefore, the target volume needs to be at least the size of the source volume.

Performance sizing for CRR target volumes is not of importance, until there is active workload. The replication speed between the source and the target volume does not depend on the (end user) performance settings of the target volume. The replication is always performed with maximum throughput regardless of the service level and the specific throughput configuration of the target volume. Only in case of a failover to the target region/volume, more performance is required to support active workloads. In this case, the performance of the target volumes should be increased as part of the failover workflow.

Sizing considerations for SAP deployments on Azure NetApp Files

To properly size and configure Azure NetApp Files, knowledge about both the performance and the capacity requirements and characteristics of the target workload is required. Getting exact performance requirements for SAP systems (aka SAP sizing) can be very complex, and especially for new systems the requirements can only be estimated. This article does not cover the details of SAP sizing, but rather gives some general guidelines and hints how to assess the requirements of SAP systems (focusing on SAP HANA) that are relevant to an ANF sizing.

Assessing workload performance requirements

Depending on whether the SAP landscape already exists or not, performance requirements can either be derived from existing systems (e.g. SAP monitoring transactions, SAP HANA performance statistics, Oracle EWR, etc.) or by estimating them based on size, system type or sizing input from SAP Quicksizer, etc. Especially for SAP HANA, the official SAP HANA KPIs (more details can be found here: SAP HANA Azure virtual machine storage configurations) can be used as a guideline for performance sizing. The highest KPIs are:

400 MB/s read for the data volume
250 MB/s write for the data and the log volume
<1 ms latency for 4k and 16k overwrite IOs on the log volume

It’s important to understand that the KPIs can only be a guideline for specific systems, since they don’t take into consideration the size of a system, the number of users, the type (production vs. non-production), the workload pattern (OLTP vs. OLAP), or the different stages of the lifetime of an SAP HANA database.

Furthermore, only production systems are subject to the SAP HANA KPIs. During the lifetime of a database, different I/O patterns play a role as described on the SAP Help Portal: I/O Related Root Causes and Solutions. For example, the highest SAP HANA read KPI for the data volume is 400 MB/s. However, high read throughput on the data volume is only required during the start/restart of the SAP HANA database when data needs to be loaded into the RAM of the virtual machine, or during stream-based backups when data is read and then written to the backup medium.

Typically restarting an SAP HANA database does not happen very often (hardly ever for production systems). Keeping the flexibility of ANF in mind to adjust performance in a very simple and automated way at any point in time, the performance of a data volume should not be sized for these seldom peak performance requirements but rather for the “steady state” requirements, as shown in Figure 2.

Figure 2) Typical SAP HANA IO pattern

On the other hand, the high read performance required during stream-based backups can completely be avoided by leveraging the efficient snapshot-based backup capabilities of ANF. In a similar fashion, the other performance requirements of SAP HANA systems and other databases and workloads should be analyzed and classified into sporadic peaks and the steady state. As a result, all steady state requirements in a subscription and a specific region should be summed up and noted as the total performance requirement. This is needed because the ANF capacity pool, which hosts all the volumes, needs to provide enough throughput in total.

Determining storage capacity requirements

The second dimension that needs to be looked at when doing SAP on ANF sizings are the capacity requirements. For SAP HANA databases, clear capacity sizing rules exist from SAP which are usually based on the memory (RAM) size of the database. For SAP HANA single host databases, the following capacities are required:

1 x RAM for the data volume
0.5 x RAM, but not more than 512 GB for the log volume
1 x RAM, but not more than 1024 GB for the shared volume

More details about the capacity requirements can be found in the SAP HANA Storage Whitepaper (attached to SAP note 1900823 - SAP HANA Storage Connector API). For other databases either data of existing systems can be used or the results from analysis tools like SAP Quicksizer. In addition to the databases, all other file shares, e.g. transport directories, application server file shares, interface volumes, etc. should be evaluated as well.

Just like with performance, the total capacity requirement must be calculated once all systems and file shares have been assessed individually to size the ANF capacity pool properly. Future data growth does not need to be factored into sizing because capacity can easily be adjusted online with ANF.

Evaluating backup and disaster recovery requirements

One of the benefits of ANF for SAP is the ability to perform very efficient snapshot-based backups. As discussed in section Understanding Azure NetApp Files snapshots and backup, the capacity requirements for snapshots and ANF backup depend on the block-level change rate, the retention on the primary ANF volumes and the retention on the ANF backup side. Therefore, it’s important to understand what the business requirements/SLAs with regards to backup are for the SAP systems.

Typically, 30 days of backups are required for most SAP production systems and customers. Non-production systems might have lower retention requirements (e.g. 5 days) and/or might not even need a second copy (via ANF backup) – this is very customer dependent and needs to be assessed individually. As mentioned before, especially for SAP HANA systems it’s not very cost effective to keep 30 days of snapshot backups on the primary ANF volumes. The amount of snapshots kept on ANF volumes should be sufficient to support day-to-day restore and recovery tasks for SAP system refresh operations, sandbox deployments, SAP repair system creation and emergency restores. It should be the absolute exception to have a backup restored from the ANF backup side because in this case the restore will take longer. Typical retention times for primary ANF snapshots are between 3 and 7 days.

The following picture shows a typical setup for SAP HANA systems with 5 days of snapshot retention and 30 days of ANF backup retention. To orchestrate the snapshot creation to get application consistent backups of the SAP HANA system a backup orchestration tool like Microsoft’s AzAcSnap or NetApp's BlueXP Backup and Recovery for Applications is required.

Figure 3) SAP HANA snapshot backup architecture

Unfortunately, block-level change rates for individual SAP HANA systems are very difficult to predict upfront. They can vary between less

than 10% and almost 100% change rate per days in extreme cases. Despite this variance for individual systems, due to the large amount of existing SAP HANA systems today, NetApp has a good understanding of the average change rate for different system types (prod, non-prod, etc.). These average change rates can be used as a starting point for the backup sizing with ANF:

Production systems: 30%-50% daily change rate
Pre-production and QAS systems: 20% - 30% daily change rate
Other non-production systems: 10% - 20%

The change rate for SAP shared files like the SAP HANA shared volume or application server filesystems is typically very low and can be estimated with 1% - %2 daily change rates. For traditional databases for SAP like Oracle or DB2 the change rates can be estimated at 2% - 3% per day.

If ANF cross-region replication is used for disaster recovery, then a separated ANF capacity in the target region must be planned. The capacity requirements can be derived from the primary storage capacity plus the capacity for snapshots that are created on the source volumes and hence will be replicated to the CRR side as well as discussed in section Understanding Azure NetApp Files replication. From a performance point of view the CRR target volumes can be sized at a minimum for normal operations (i.e. if the data is not actively used) since the replication speed does not depend on the performance assigned to the target volumes. During disaster recovery testing or a real failover, the performance can be adjusted instantaneously to meet production requirements.

All capacities derived from the backup and disaster recovery requirements assessment then need to be added to the total capacity requirements in each region.

Selecting the appropriate Azure NetApp Files service level

Once all capacity and performance requirements have been gathered, the appropriate capacity pools and service levels can be selected. It’s important to understand that basically all capacity and performance requirements can be fulfilled with each of the three service levels standard, premium, and ultra (within the total capacity limits of a single pool: Resource limits for Azure NetApp Files). However, having a total performance demand with low to medium capacity requirements would require massive capacity overprovisioning with for example service level standard to provide the required performance. On the other hand, if large capacities are required with only moderate performance requirements, the service level ultra will probably provide much more performance than required but also drive up the monthly cost. So, selecting the appropriate service level is primarily a cost-optimization activity rather than a technical decision. The appropriate service level can be selected by calculating the required capacity pool size for each service level based on the total capacity and performance requirements. Then the most cost-effective service level should be chosen.

Here's an example of a production SAP HANA system with 4 TB RAM. A relatively high daily change rate for snapshot backups of 50% is assumed, and it’s planned to keep snapshots for 5 days on the primary volume (the ANF backup part is ignored here since it is irrelevant for the capacity pool sizing).

Based on these input values and assumptions, the SAP HANA capacity sizing guidelines and the calculation of the required snapshot space lead to a total capacity requirement of 17.20 TiB. From a performance standpoint, throughput requirements are calculated based on the SAP HANA KPIs for production databases. This leads to a total of 1400 MiB/s for all volumes combined.

The following table summarizes the requirements and shows the required capacity pool size for each service level.

	Sizing requirements	Capacity pool standard	Capacity pool premium	Capacity pool ultra
Capacity (TiB)	17.2	88	22	18
Throughput (MiB/s)	1400	1408	1408	2304
Excess capacity (TiB)		70.8	4.8	0.8
Excess throughput (TiB)		8	8	904
Monthly cost (US $ in East US)		13,288	6,628	7,239

Table 1) Capacity pool sizing example.

It is obvious that all three service levels would work but choosing service level premium is the most cost-effective option. Service level premium requires a performance-driven sizing, i.e. slightly more capacity needs to be provisioned than what is required (22 TiB vs. 17.2 TiB) in order to meet the performance requirements (1400 MiB/s).

Since capacity pools can only be sized in 1 TiB increments, there’s not only some excess capacity of 4.8 TiB left in the pool but also a (negligible) amount of 8 MiB/s which are not assigned to volumes. This excess capacity and performance can be assigned freely to volumes without impacting the overall cost. As a comparison, choosing service level ultra would reduce the excess capacity to just 0.8 TiB stemming from the 1 TiB increments, but it would yield a significant amount of unassigned performance (904 MiB/s). The monthly cost for this option would be roughly $800 higher than the premium option and therefore not the most cost-effective selection.

Sizing best practices and cost optimization options

In this section, the most important best practices and guidelines for a cost-optimized SAP on ANF sizings are summarized.

Usage of manual QoS capacity pools.
As described in section “Understanding service levels and QoS settings” manual capacity pools provide more flexibility assigning the required capacity and throughput to individual volumes. By doing so, manual QoS sizings for SAP are typically 10%-20% less expensive than comparable auto QoS sizings. In addition, features like application volume group (AVG) require the usage of manual QoS. This article only describes manual QoS sizings for SAP.

Performing SAP landscape sizings and consolidation into as few capacity pools as possible.
In section “ANF storage hierarchy and capacity pools” details of the ANF storage hierarchy are provided and an explanation about how capacity pools are the relevant resources for the overall cost of ANF. As mentioned in the previous guideline, manual QoS capacity pools provide great flexibility to assign capacity and throughput from a single pool to individual volumes. The more systems and workloads are aggregated into a single pool, the better the TCO works with a mixture of small high-performance and large low-performance volumes (and anything in-between). There is no general requirement to distribute volumes into individual capacity pools, neither from a data security point of view, nor from a data distribution point of view across availability zones. The use of as few capacity pools as possible is highly recommended.

Consolidation of multiple file systems into single volumes.
The minimum volume size of ANF volumes is 100 GB. Many of the SAP file systems like /sapmnt, /usr/sap/<SID>, /usr/sap/trans, etc. usually require way less than 100 GB capacity. Provisioning individual volumes for each and every of those file systems does not make a lot of sense. Instead, consolidation of those file systems into a single ANF volume and then mounting sub-directories to the dedicated mount points on the VM should be preferred. This is an easy and safe way to consolidate those file systems because of the NFS protocol and the features available in ANF. More information about that topic can be found here: SAP Landscape sizing and volume consolidation with ANF.

Usage of ANF’s dynamic resizing capabilities and avoiding peak performance sizing.
Performance and capacity for volumes and capacity pools can be adjusted instantaneously with a single click in the Azure portal or a single API call as already discussed in previous sections. Therefore, it’s not recommended to provision a lot of overhead capacity in volumes and especially capacity pools. Rather than doing that, implementing automation tools like the ANFCapacityManager logic app that can help to automatically increase the capacity of volumes and pools based on configurable thresholds should be considered.

The same guideline applies to performance. Taking SAP HANA as an example, high read throughput on the SAP HANA data volume is only required during the start of the database, which usually happens very infrequently. It doesn’t make sense to constantly provision such high throughput on the data volume just to support the rarely executed startup operation. Instead, providing enough performance to support the “steady state” is recommended. Occasional peak performance requirements, especially if they are known upfront (e.g. start of the database, month-end close, etc.) can easily be handled by automatically increasing the performance during that timeframe and then reducing the performance back to the steady state.

Applying SAP HANA KPIs to all non-production or small SAP HANA system is not recommended.
The SAP HANA KPIs published by SAP only must be applied to production systems, but not to non-production systems. In addition, the SAP HANA KPIs do not reflect the size or the “user load” of a specific database, i.e. the real performance requirements might differ significantly from those KPIs. Usually non-production systems, but also smaller production systems (~ <= 1 TB RAM) don’t require the full KPIs. Downsizing performance for those systems to save costs can safely be done because if storage related performance issues are really observed, the throughput for those systems can be increased again instantaneously.

For TCO calculations backups should always be included.
Azure NetApp Files is a great storage option for SAP systems. But it is much more than that with all the data management and data protection capabilities. Usage of these functionalities to make the best out of any ANF deployments is important. Therefore, it’s highly recommended to always include at least snapshot-based backups into the picture. This will help to greatly improve the overall TCO of the solution.
Getting support from SAP on Azure and ANF experts
Last but not least, proper sizing of SAP on Azure NetApp Files requires some experience. If customers or partners don’t have that experience or if they want to get a second opinion/feedback to an existing sizing, they shouldn’t hesitate to reach out to an SAP on ANF experts. The responsible Microsoft or Azure NetApp Files account team for customers can help to make the connection to the right experts.

SAP on Azure NetApp Files sizing estimator

Sizing SAP on ANF environments correctly can be a complex task. The guidelines and explanations in the previous sections provide the necessary background information to perform this task. However, it can still be quite cumbersome to do a sizing manually. Therefore, an online tool has been developed and published, the SAP on Azure NetApp Files sizing estimator. This estimator automates most of the manual sizing tasks and calculations, and it helps applying best practices though pre-configured default settings.

(!) Important

It's important to note that this tool is not an officially supported tool but rather a community project. It is designed to estimate the infrastructure costs of an SAP (HANA) on ANF landscape. However, it is not meant to be a comprehensive tool and may not account for all possible factors that may impact the total cost.

Tool overview

Discover the game-changing Azure NetApp Files SAP Sizing Estimator in this video, uncovering how accurate sizing transforms SAP deployment in Azure, powered by Azure NetApp Files. Learn how optimal sizing enhances performance and drastically improves Total Cost of Ownership (TCO), enabling efficient resource allocation and cost savings and see how this tool accelerates cloud migration and gain insights from experts on its significance. Whether you're planning to migrate SAP workloads or optimize existing deployments, this video illustrates how precise sizing drives performance excellence and cost efficiency in Azure NetApp Files:

The tool can be accessed via this URL: SAP on Azure NetApp Files Sizing Estimator.

The following sections describe the tool and how to use it. The tool is structured into five sections:

Add Systems and Volumes
Estimated ANF Storage Costs
Estimated ANF Backup Costs
Capacity Pool Summary
Volume Summary

The first section is used to input the SAP landscape data, all other sections provide information about the sizing output.

Input SAP landscape data

The “Add Systems and Volumes” section of the estimator allows to input all relevant SAP landscape data, as well as configure parameters for the performance and backup calculations. It is divided into multiple subsections:

Add SAP HANA System
Add Single Volume
Capacity Pool Region
Performance Modifiers
Snapshots and Backups

There is currently a focus on sizing SAP HANA landscapes, but the tool can also be used to size non-database volumes and – with a little bit more manual work - also other databases. Some hints on sizing other databases will be provided in section “Perform “anyDB” sizing. For now, the focus is on SAP HANA deployments.

Add SAP HANA System

Figure 4) Add SAP HANA System form

To enter a new SAP HANA system, the form shown in Figure 4 needs to be filled. SID and Description are only used to identify systems easily later on.

The system type defines the performance modifiers used for this system; it can be one of PROD, PRE-PROD, QAS, DEV, TST, SBX, DR or OTHER. The performance modifiers for each system type are defined in the Performance Modifiers subsection which is explained later.

The RAM size refers to the required main memory size of the SAP HANA database, and it is used for the capacity calculations of the SAP HANA volumes. Ideally the real target RAM size of the database itself is entered, but if that’s not available, the RAM size of the target VM (which is equal to or greater than the database RAM size) can also be used.

The HA (HSR) flag defines whether a second set of ANF volumes should be calculated for an SAP HANA System Replication (HSR) high availability (HA) setup. These HA systems are either deployed in the same Azure availability zone or another availability zone in the same region. Regardless of where the HA system will be deployed in that region, the ANF volumes will always be deployed in the same capacity pool as the primary system as explained in section “ANF storage hierarchy and capacity pools”.

The HA secondary performance input allows downsizing the performance of the HA database. Usually, this value should be kept at the default of 100%, i.e. the HA database gets the same performance as the primary database. In some cases, it might be appropriate to provide lower performance to the secondary system, e.g. 50% of the performance of the primary system. In such a case the relative performance decrease (e.g. 50%) can be entered here.

The Host count input defines whether the SAP HANA system is a single host database (aka scale-up) or a multiple hosts database (aka scale-out). If a number larger than 1 is selected (currently up to 16 nodes are supported), then the required data and log volumes for all database nodes are added to the calculation.

The capacity pool field allows the selection of the target capacity pool for this SAP HANA system. Up to 9 different pools can be selected, but as mentioned in section “Sizing best practices and cost optimization options” as few pools as possible should be used. The selected capacity pool also defines the region, and since ANF can be priced slightly differently in different regions, this also influences the overall calculated cost. The region for each pool can be defined in the Capacity Pool Region section.

Add Single Volume

Individual volumes, typically non-database volumes like a global transport directory, a central log backup directory or a software share, can be added to the sizing via the Add Single Volume form.

Figure 5) Add Single Volume form

Even though most central shares do not have an assigned SID, the form still requires some input in this field. Just like the description, it is only informational data. So basically, anything can be provided here; a recommendation would be to either use a separate SID naming pattern to indicate file systems (e.g. FS1 – file system 1), or to use one of the SAP system SIDs to align the volume to this system (or the corresponding system landscape).

The Type for single volumes is also only informational and does not have any influence on the performance calculation. It can be used to indicate if the volume belongs to the PROD systems or any of the non-prod systems.

For single volumes the size and the throughput must be entered manually because they cannot be derived from fixed rules as it is the case for SAP HANA databases.

Also, the parameters for the snapshot-based backup capacity calculation must be entered individually per volume.

The daily change rate defines the ANF volume’s block-level change rate for the workload the volume is used for. Most general file shares have very low change rates in the range of 1% to 5% per day. Refer to section “Evaluating backup and disaster recovery requirements” for more details on the snapshot change rates.

The Snapshot retention then defines how long snapshots are kept on the primary ANF volumes and the Backup retention defines how long they are kept on the ANF backup side.

Finally, the target capacity pool can be selected again which defines the region and hence calculates the region-specific cost.

Capacity Pool Region

Figure 6) Capacity Pool Region form

The capacity pool region form defines the target region for each capacity pool. The dropdown list contains the list of Azure regions where Azure NetApp Files is available. The cost calculation for each capacity pool depends on the region selection, because Azure has slightly different price points for their services in different regions. The region assignment can be changed and updated at any point in time during the sizing workflow. As soon as the Update button is clicked, the sizing – especially the cost calculation – will reflect any changes made to the region settings.

Performance Modifiers

The performance modifiers form allows to fine-tune the performance characteristics of SAP HANA systems. As a starting point, all the default values should be kept unchanged. However, if more details about the specific target landscape are available and with some SAP on ANF sizing experience, these modifiers allow to fine-tune a specific sizing. Changes can be made at any point in time and will immediately be reflected in the sizing output once the Update button is clicked.

Figure 7) Performance Modifiers form

The form is divided into two sections, the Performance Baseline (i.e. the SAP HANA KPIs) and the Performance Factors for different system types. Since the SAP HANA KPIs for data and log are static and defined by SAP, there should hardly be any need to adjust the default values. There’s no official performance KPI for the shared volume, but roughly 50 MiB/s is common standard. There might be very specific / exceptional cases where a deviation from these default values is required. To support such cases, the values can be changed.

The idea of the Performance Factor section is to apply multipliers to the baseline KPIs for different SAP HANA system types. As discussed earlier, the SAP HANA KPIs only need to be reached for production systems. Non-production systems are not subject to the KPIs. The default values in this section represent typical values that are being used in sizings based on experience. For example, 50% performance factor for QAS (Quality Assurance) system means that if a SAP HANA database is entered and the system type QAS is selected, 50% of the KPIs will be planned for this system, i.e. the data volume will be sized with 400 MiB/s x 50% = 200 MiB/s. The log volume will be sized with 125 MiB/s and the shared volume with 25 MiB/s respectively. Values higher than 100% are also allowed. If for example all the production systems of a landscape are known to have very high performance requirements (often that’s the case for large systems greater than 6 TiB), then a performance factor of 150% for PROD might be appropriate. That would lead to 600 MiB/s for data, 375 MiB/s for log and 75 MiB/s for shared for those systems in the sizing.

The default value for DR systems is set to 1% (the minimum value – 0% is not allowed) because with ANF configurations, cross-region replication (CRR) should be considered for DR protection. With CRR, the target volumes do not need any performance during normal operation and therefore only a capacity-based sizing needs to be performed for those volumes. If CRR is not used in the DR architecture, but for example HSR, then this value needs to be set much higher, e.g. to a value between 25% and 50%.

All values, the baseline and the performance factors, can be changed at any point in time during the sizing. To make changes effective, the Update button needs to be clicked. The current sizing will then be immediately updated based on the new values. That’s a nice and easy way to compare different scenarios and their effect on the overall cost. Especially if a sizing is capacity-bound, then excess performance could by applied to systems/system types without increasing the total cost.

Snapshots and Backups

In Figure 8 ) Snapshots and Backup form the change rates and retention times for different SAP HANA system types can be configured. These values will be used to calculate the required additional capacity for snapshots on the primary volumes and the required total capacity for ANF backup as explained in section “Evaluating backup and disaster recovery requirements”.

Figure 8 ) Snapshots and Backup form

The first two columns define the assumed change rates for the data volume and the shared volume. The log volume is not listed because snapshot backups of the SAP HANA log volume do not make sense and should not be implemented. The default values represent a good starting point based on experience. They are on the higher-end of the typical change rates seen with SAP HANA systems, so adjustments made here should usually be a decrease of the assumed change rates.

The last two columns define the retention time for primary snapshots kept on the ANF volumes and the off-loaded/replicated backups kept on the ANF backup side. A value of 0 for snapshot retention means that no snapshot backups are planned and calculated at all for this system type (e.g. SBX – Sandbox systems), a value of 0 for the backup retention means that no snapshots are planned to be replicated/off-loaded via ANF backup (e.g. for the DEV and TST system type).

If ANF cross-region replication is used for DR protection, then the snapshot retention should match the configured retention of the primary system type, i.e. typically PROD, because CRR replicates all primary snapshots to the DR volume automatically.

As explained in the Performance Modifiers section, all values can be changed at any point in time and applied to the current sizing by clicking on the Update button.

Volume Summary

Whenever a new SAP HANA system or a new single volume is entered, it is added to the volume summary list at the bottom of the estimator page. This list helps to see which systems/volumes have already been entered and what the absolute performance and capacity numbers have been used for each volume based on the settings made in the Performance Modifiers and the Snapshots and Backup sections. Figure 9 shows an example of one SAP HANA production system using HSR to provide HA, and a single volume that serves as a central transport share.

Figure 9) Volume Summary example

For the SAP HANA system, a data volume, a log volume, and a shared volume has been added for the primary database node and one of each for the secondary (HA) node. The following table explains each column of the volume list.

	Explanation for SAP HANA	Explanation for single volume
SID	System ID as entered in the input form. If HSR (HA) was selected in the input form, then “-HA” is appended to the SID for the secondary node.	System ID as entered in the input form
Description	Description as entered in the input form
Environment	System type as selected in the input form
Capacity pool	Capacity pool as selected in the input form
Volume type	One of data, log, shared – the required volumes for SAP HANA systems.	<empty>
Host count	For single host systems, it’s always 1 for data and log. For multiple hosts systems, each data and log volume gets a node identifier between 1 and <host count> selected in the input form. The shared volume always gets n/a.	<empty>
Capacity (GiB)	Required capacity for data, log, and shared based on the SAP HANA capacity sizing rules and the RAM size entered in the input form, i.e. 1 x RAM for data, min(0.5 x RAM; 512 GiB) for log, min(1 x RAM; 1024 GiB) for shared)	Capacity entered in the input form
Required snapshot capacity (GiB)	data: 0.5 x [Capacity] x [daily change rate] x [snapshot retention] log: 0 shared: [Capacity] x [daily change rate] x [snapshot retention] change rate and snapshot retention taken from the snapshots and backup configuration based on the selected system type (environment)	[Capacity] x [daily change rate] x [snapshot retention] as entered in the input form
Assumed volume free space (GiB)	The data volume capacity is equal to the RAM size, but the actual max database size is only 50% of that according to SAP’s sizing rules. Therefore 50% free space is assumed here. No free space is assumed for log and shared.	0
Additional snapshot space (GiB)	For data, it’s [Required snapshot capacity] – [Assumed volume free space]. For log and shared it’s equal to [Required snapshot capacity]	Equal to [Required snapshot capacity]
Total required capacity (GiB)	The total required capacity for the volume including snapshots, i.e. [Capacity] + [Additional snapshot space]
Required performance (MiB/s)	Based on the selected system type (environment), it’s the configured base line performance for the volume type multiplied by the relevant performance factor from the settings.	Throughput entered in the input form
Daily change rate (%)	Daily change rate as configured in the snapshots and backup settings for data and shared based on the system type (environment). It’s always 0 for log since no snapshot backups should be used on the log volume.	Daily change rate entered in the input form
Snapshot retention (days)	Snapshot retention as configured in the snapshots and backup settings for data and shared based on the system type (environment). It’s always 0 for log since no snapshot backups should be used on the log volume.	Snapshot retention entered in the input form
ANF backup retention (days)	ANF backup retention as configured in the snapshots and backup settings for data and shared based on the system type (environment). It’s always n/a for log since no snapshot backups should be used on the log volume.	ANF backup retention entered in the input form
Trash bin	If x is clicked on any of the volumes of a system, the entire system (including HA partner if applicable) is removed from the sizing.	If x is clicked, the volume is removed from the sizing.

Table 2) Volume Summary columns

Perform “anyDB” sizing

The current version of the tool clearly focuses on SAP HANA based landscapes. Nevertheless, it is also possible to perform “anyDB” (i.e. traditional relational databases supported for SAP like Oracle or DB2) sizings with it. To enter the required information requires a little bit more manual effort than entering SAP HANA systems since there’s no input form available today for other databases. Hence all required volumes must be entered individually via the single volume input form. The volume list in Figure 10 shows a sample Oracle landscape with a large production and QAS system and a small development system. For the large Oracle databases, multiple data volumes have been used. For those systems there are also two redo log volumes (origlog and mirrlog) following SAP best practices for Oracle databases.

Figure 10) Oracle Volume Summary example

Understanding sizing output

Whenever a new SAP HANA system or a new single volume is added to the sizing, the sizing results are updated automatically to reflect the changes. The Capacity Pool Summary section sums up all volume requirements as listed in the volume summary section grouped by capacity pools as shown in the example in Figure 11.

Figure 11) Capacity Pool Summary example

The logical data (TiB) is the sum of all values of the Capacity (GiB) column in the volume list per capacity pool. The additional snapshot space (TiB) column shows the sum of all values of the Additional snapshot space (GiB) column, the Volume capacity (TiB) is the sum of Total required capacity (GiB), the Volume performance (MiB/s) is the sum of Required performance (MiB/s), and total snapshot space (TiB) is the sum of Required snapshot capacity (GiB). The values in this table are used for the capacity pool service level selection as shown in the example in Figure 12) Estimated ANF Storage Costs example.

Figure 12) Estimated ANF Storage Costs example

In this example, capacity pool P1 must provide 18.25 TiB capacity and a total of 1464 MiB/s. This requirement can be fulfilled with all three service levels standard, premium, and ultra. Using service level premium is the most cost-effective option based on the regional price for ANF in the configured region for P1 (East US). Using service level premium leads to a performance-based sizing: in order to fulfill the requirement of 1464 MiB/s, 23 TiB capacity (1464 MiB/s / 64 MiB/s per TiB) must be provisioned in the pool. Since capacity pools can only be sized in full 1 TiB increments, there’s a small excess of performance (8 MiB/s). The 4.75 TiB excess capacity results from the performance-based sizing. That means additional volumes with a total of 4.75 TiB capacity and 8 MiB/s performance could be added to the sizing without any change in the cost.

For capacity pool P2 – which is used to store the DR system in a different region (West US) via ANF CRR – only 6.6 TiB capacity and basically no (7 MiB/s) performance is required. Therefore, using service level Standard with a capacity-based sizing (7 TiB) is the most cost-effective choice here.

The table lists the total costs for the primary ANF volumes/capacity pools. The section Estimated ANF Backup Costs details the sizing and the additional cost for the ANF backup requirements. In the example in Figure 13 the total backup capacity is 68.3 TiB. It is calculated as the sum of the baseline capacity and the delta capacity.

Figure 13) Estimated ANF Backup Costs example

The baseline capacity is the initial capacity of each volume (without any snapshot calculation), except for the data volume where only 50% of the capacity is assumed for the baseline copy. The delta is calculated based on the daily change rate and the configured retention time for ANF backup for each volume.

Save and share sizing configurations

(x) Caution

The SAP on ANF sizing estimator is implemented as a single page application (SPA) with all code running on the client side (i.e. in the web browser). As a consequence, whenever the page is reloaded or closed in the browser, all input data is lost and the sizing is reset.

Users should keep this in mind.

To allow saving specific sizings to refer to them at a later point in time or to share the results with someone else, two options are available in the tool: import and export configs and sharing configs.

These options can be found in the top-right of the page:

Figure 14) Import, Export and Share Config

If Export Config is selected, users can specify a filename for the target json file that will be generated and stored locally on the user’s computer. The json file contains the entire input as provided via the SAP HANA and single volume input forms. It also contains all settings for the capacity pool regions, the performance modifiers and the snapshots and backup configurations. An example of such a json file is available in the appendix. These json files can later be imported back into the tool via the import config button. Once the json is loaded, the sizing shows the exact same state as it was saved, and the sizing can be continued. It is also possible to edit the json file directly to make changes without using the tool. This can be handy if a large number of systems should be added to the sizing via copy and paste, or if the input should be generated from another source. The latter approach can be used for example to generate an ANF sizing from an existing SAP on Azure sizing done via the Microsoft SAP on Azure Sizer.

To quickly share a specific sizing with someone else, the share config option can be used to generate an URL like the one for the examples used so far:

SAP HANA landscape - SAP on Azure NetApp Files Sizing Estimator
Oracle landscape - SAP on Azure NetApp Files Sizing Estimator

(i) Note

Changes made to the original sizing afterwards are not reflected in the shared config. Also, the original sizing is not changed if someone makes changes to the sizing opened after clicking the link.

It’s basically a point in time snapshot of the sizing when the URL was generated.

Sizing examples

Landscape overview and sizing assumptions

In this example an SAP HANA environment in West Europe consisting of two separate production systems and their corresponding non-production system is sized. Each SAP HANA landscape consists of a production system and a pre-production system which both are configured with HANA System Replication (HSR) to support high-availability (HA) scenarios. In addition, each landscape has a test, a development, and a sandbox system as shown in Figure 15.

Figure 15) Example: SAP HANA landscape overview

Three variants of this environment are calculated with different SAP HANA database sizes for prod, pre-prod, and test, ranging from 2TB per database up to 12TB. The following table shows the assumptions and input parameters for the sizing of each system.

				Backup requirements
Number of systems	System type	RAM size	Defined throughput per HANA system [% of KPIs]	Daily change rate	Local snapshot retention [days]	ANF backup retention [days]
2	Production (incl. HA)	2TB, 6TB, 12TB	100%	30%	5	30
2	Pre-production (incl. HA)	2TB, 6TB, 12TB	50%	10	5	30
2	Test	2TB, 6TB, 12TB	25%	10	5	30
2	Dev	512GB	25%	10	5	0
2	Sandbox	256GB	25%	10	0	0

Table 3) Example: SAP HANA landscape assumptions

To store the log backups of all SAP HANA databases, a common shared ANF volume is planned where the databases can write the log backup files to. To have a second copy of the log backups an Azure storage account (blob storage) is added into the calculation. AzCopy or BlueXP Copy & Sync can be used to replicate the log backup files from the ANF volume to the storage account. In alignment with the snapshot backups, 5 days retention of log backups on the ANF volume are planned and 30 days retention on the storage account. For the log backup change rate, 10% of the database size per day is assumed. Each of these three configurations is compared against an ANF sizing which is based on potential peak performance requirements similar to how Azure managed disks would sized, and which does not include any backup calculations.

Sizing results and cost comparison 2TB landscape

The sizing for the 2TB landscape can be found here: 2TB landscape example.

Figure 16 shows the best option is a 46TiB ultra capacity pool. Since this is a capacity-bound sizing, 388 MiB/s of excess performance is available in the pool which can and should be assigned to the volumes as needed. The monthly cost for this capacity pool is US $18,499.62. To store the ANF backups, a total capacity of 75.5TiB is required which adds US $5,025.28 to the monthly bill. The storage account to store the 30 days of log backups adds another US $168.98 (12TB) to that. The total monthly cost for this configuration is therefore US $23,693.88.

A common mistake when sizing ANF for SAP HANA is to simply take the SAP HANA Azure virtual machine storage Premium SSD storage configurations and apply them 1:1 to ANF and to also exclude the backup aspect completely. This would lead to a requirement of approximately 136TiB ultra and a total monthly cost of US $54.694,54. This is more than 250% of the monthly cost for the correct sizing described above.

With a correct sizing, the ANF solution for environments with mostly smaller SAP HANA systems is typically a little bit more expensive than a comparable solution on Azure disks when comparing only the infrastructure costs. However, as described in the introduction of this article, the ANF solution adds a lot of value to the overall solution – especially in the area of backup and recovery, but also in terms of operational benefits. In many cases, the ANF solution is the more attractive option even for smaller landscapes if the full TCO is considered including operational costs.

Figure 16) Example: Sizing results 2 TB landscape

Sizing results and cost comparison 6TB landscape

The sizing for the 6TB landscape can be found here: 6TB landscape example.

The best capacity pool option in this case is an 87TiB premium pool with a monthly cost of US $26,208.80.The ANF backup cost is US $12,721.28 for 191.13 TiB per month. The Azure storage account for the log backups adds another US $459.80 (34.2 TB) to the bill. That makes a total of US $39,389.88.

An incorrect sizing based on numbers taken from the Azure managed disks and without backup for this landscape would require approximately 162TiB of ultra capacity at a monthly cost of US $65.150,85 – which is 165% of the cost for the proper sizing.

Figure 17) Example: Sizing results 6TB landscape

Sizing results and cost comparison 12TB landscape

The sizing for the 12TB landscape can be found here: 12TB landscape example.

For the 12TB landscape, the premium service level is again the most cost-effective choice. A capacity pool of 154 TiB is required to fulfill the capacity requirements. With this capacity, there’s plenty of excess performance available (4356 MiB/s) without extra cost. That comes in handy with such large databases to accelerate the database startup or other high-load situations temporarily. Of course, the performance can also be assigned to volumes permanently. For example, increasing the performance factors in this sizing for PROD to 150%, for PRE-PROD to 100% and for QAS to 100% would not have any influence on the monthly cost. And there would still be 506 MiB/s unassigned which could be used to address temporary peak load situations. The updated sizing can be access here: updated 12TB landscape example.

Figure 18) Example: Sizing results 12TB landscape

The total monthly cost for this solution would be US $71,877.69, which can be broken down into US $46,392.59 for the primary ANF storage, US $24,577.28 for 369.25 TiB of ANF backup, and US $907.82 for 68.4TB Azure blob storage. For larger landscapes, the difference between an incorrect sizing and a proper sizing is not that significant any more since more performance is naturally available in the capacity pool due to the overall capacity requirements, but of course it’s still critical to perform an accurate sizing for ANF – and last but not least, include the backup and DR aspect into the overall solution to take advantage of the benefits of Azure NetApp Files.

Conclusion

In conclusion, SAP deployments on Azure NetApp Files offer several advantages, including simplified operations, high performance and scalability, and enhanced data protection. By leveraging Azure NetApp Files, customers can streamline deployment and scalability processes, simplify management through the Azure portal, and ensure high availability with built-in features. The low-latency access provided by Azure NetApp Files enables fast and responsive interactions with SAP applications and databases, while its on-demand scalability allows customers to adjust performance and capacity dynamically based on workload demands. The built-in snapshot backup and restore operations, along with snapshot copying to Azure Blob storage, ensure efficient data protection and long-term retention. Additionally, Azure NetApp Files supports replication for disaster recovery scenarios, simplifying the implementation of robust DR strategies.

Proper sizing is crucial for optimizing performance and cost-efficiency in SAP deployments on Azure NetApp Files. Over-sizing can lead to unnecessary costs and inefficient resource utilization, while under-sizing can result in performance bottlenecks. By accurately assessing workload performance requirements and capacity needs, customers can avoid overprovisioning and as a result optimize their cloud expenditure. Leveraging the flexibility and elasticity of Azure NetApp Files allows for dynamic scaling of resources to meet changing requirements. It is recommended to consider the varying performance needs of SAP workloads and fine-tune sizing decisions accordingly to achieve an optimal balance between performance, cost-effectiveness, and scalability.

To support proper sizing efforts, the SAP on Azure NetApp Files Sizing Estimator tool has been developed. This tool automates many of the manual sizing tasks and calculations, providing a structured approach to estimate storage capacity and performance levels needed for optimal performance and cost-effectiveness. By leveraging this tool, customers and partners can streamline their sizing process and ensure accurate and efficient resource allocation.

In summary, SAP deployments on Azure NetApp Files offer customers a robust and efficient solution for their SAP workloads. By properly sizing the infrastructure, customers can optimize performance, cost-effectiveness, and scalability, leading to improved efficiency, reliability, and agility in their SAP deployments on Azure NetApp Files.

Additional Information

To learn more about the information described in this article, refer to the following articles and/or websites:

Appendix – Config export JSON example

{

"input": [

{

"inputDescription": "S/4 HANA Production",

"inputEnv": "PROD",

"inputHA": "2",

"inputHostCount": "1",

"inputId": 0,

"inputPool": "P1",

"inputRamSize": "4096",

"inputSecondaryPerf": "100",

"inputSid": "P01",

"inputType": "system"

},

{

"inputBackupRetention": 10,

"inputDailyChangeRate": 1,

"inputDescription": "central transport share",

"inputId": 1,

"inputPool": "P1",

"inputSid": "FS1",

"inputSnapshotRetention": 5,

"inputThroughput": "64",

"inputType": "volume",

"inputVolSize": "1024",

"inputVolType": "PROD"

},

{

"inputDescription": "S/4 HANA Production DR",

"inputEnv": "DR",

"inputHA": "1",

"inputHostCount": "1",

"inputId": 2,

"inputPool": "P2",

"inputRamSize": "4096",

"inputSecondaryPerf": "100",

"inputSid": "R01",

"inputType": "system"

}

],

"settings": {

"dataProtectionSettings": {

"DEV": {

"backupRetention": "0",

"dataDailyChange": "10",

"sharedDailyChange": "1",

"snapRetention": "5"

},

"DR": {

"backupRetention": "0",

"dataDailyChange": "30",

"sharedDailyChange": "2",

"snapRetention": "5"

},

"OTHER": {

"backupRetention": "0",

"dataDailyChange": "10",

"sharedDailyChange": "2",

"snapRetention": "5"

},

"PRE-PROD": {

"backupRetention": "30",

"dataDailyChange": "30",

"sharedDailyChange": "2",

"snapRetention": "5"

},

"PROD": {

"backupRetention": "30",

"dataDailyChange": "50",

"sharedDailyChange": "2",

"snapRetention": "5"

},

"QAS": {

"backupRetention": "30",

"dataDailyChange": "20",

"sharedDailyChange": "2",

"snapRetention": "5"

},

"SBX": {

"backupRetention": "0",

"dataDailyChange": "10",

"sharedDailyChange": "1",

"snapRetention": "0"

},

"TST": {

"backupRetention": "0",

"dataDailyChange": "10",

"sharedDailyChange": "1",

"snapRetention": "5"

}

},

"kpiBaseline": {

"data": 400,

"log": 250,

"shared": 50

},

"kpiMultipliers": {

"devPerf": 0.25,

"drPerf": 0.01,

"otherPerf": 2,

"preProdPerf": 0.8,

"prodPerf": 1,

"qasPerf": 0.5,

"sbxPerf": 0.1,

"tstPerf": 0.25

},

"poolGroupRegions": {

"P1": "eastus",

"P2": "westus",

"P3": "eastus",

"P4": "eastus",

"P5": "eastus",

"P6": "eastus",

"P7": "eastus",

"P8": "eastus",

"P9": "eastus"

}

Sign In

SAP on Azure NetApp Files Sizing Best Practices

Recommended Posts

Guest GeertVanTeylingen

Join the conversation

Browse

Activity

Store

Support