Good morning, good afternoon, good evening everyone and welcome to our SAP on Azure session on how to properly size and optimize the TCO with Azure Netup files. I'm Toby Brundle, SAP solution architect at Netup and together with my partner in crime, Ralph Cla, principal architect at Microsoft, we are walking you through this quick 15-minute technical highlight session. Before we jump into the session, please take a moment to review the confidentiality notice. Thank you. Okay, let me start by setting the stage. Properly sizing SAP deployments on Azure files is crucial for two main reasons. one to ensure optimal performance and two to avoid unnecessary costs associated with oversizing.The flexibility of Azure netup files allows customers to address both topics and therefore helps to optimize the TCO of their SAP deployments on Azure.netup files is a great fit for SAP deployments. Since Azure Netup files is a native Azure platform service, it very much simplifies the operation of the file systems on the Azure platform. It allows for easy provisioning and consumption without the need to deal with lower level storage tasks. This can be completely done via the Azure portal or via APIs or the Azure CLI for further automation. And especially important for SAP deployments, it provides the highest SLA of 99.99% of 99.99% of 99.99% out of the box for each and every volume or share that's provisioned. Furthermore, ANF provides the enterprisegrade performance. This made it possible to very early on certify it for all SAP HANA workloads. In addition, it's fully supported for SAP on any DB deployments such as Oracle DB2 assemb. One of the great features of Azure files in this context is that both performance and capacity can be adjusted on the fly without any application downtime and it works in both directions. Increasing and decreasing performance and capacity is easily possible. Therefore, there's no need to size for occasional peak performance requirements such as SEP HANA database startups. They can easily be addressed by providing extreme performance on demand. And last but not least, the built-in technology for enhanced data protection allows to back up even the largest databases in a matter of seconds. Those snapshots backups can then also be used for very fast and efficient SAP system copy and refresh operations and they can be replicated via ANF cross region replication to another azure region for simplified recovery scenarios. That means ANF is not only another storage option but it also provides a complete backup and DR architecture. All these features improve the overall quality and SLA of the SAP landscape and help to reduce the TCO to size ANF properly for SAP deployments. It's also important to look at the entire landscape including all production and non-production systems. Unlike with Azure managed discs where you size each system individually and independent of all the other systems with the Azure netup files capacity pool concept you have to look at the aggregated capacity and performance requirements of all systems.In addition all backup and the R requirements have to be part of the sizing exercise as well. Only by doing that the most optimal sizing can be generated.Let's summarize the guidelines for sizing optimization. ANF capacity pools can be configured in two ways with autoQS which provides a direct correlation between volume quota and performance and manual QS which decouples capacity settings from performance settings for each volume. Manual QS is more flexible and provides better usage of the overall capacity pool performance and capacity for SAP landscapes. That's why manual QS is highly recommended. As explained on the previous slide, SAP sizing should be done per landscape and not per individual systems. This helps to drive down the overall cost with the capacity pool concept. Leveraging the dynamic resizing capabilities of Azure files is another important guideline. Thanks to these features, a sizing for peak performance, which would leave the ANF volumes oversized for most of the time, is not required. Aim for the steadystate requirements for SAP systems instead. And keep in mind, non-production sub HANA systems do not need to fulfill the SAP HANA KPIs, and they typically don't really need that much performance either. And last, but not least, we don't want to put pressure on you to become an ANF sizing guru. Involve SAP on Azure Netup files expert to help you with that. We'd be happy to support you in your design and sizing efforts. Now, let's take a look at the real world example to make this a bit more tangible. The sample landscape consists of two SAP applications, an S4 HANA system and ABW on HANA system. Both landscapes require a highly available production and pre-production system and a few single systems for test development and as a sandbox. We have used this landscape with different Sapana database sizes ranging from 2 TBTE for production up to 12 TBTE to compare the sizing with an Azure manage disk based solution. We will take a look at the sizing results in a moment.But before we do that, I'd like to quickly introduce our new SAP on ANF sizing estimator that helps to hugely minimize the efforts for SAP on ANF sizings. Along with the tool itself, we have published a sizing best practices blog post on the Microsoft tech community that provides more details about the topic. Okay, so now on to the tool.When you open the estimator, you first get a welcome screen with some quick tips and links to further guidelines on how to use it. The tool is divided into several sections. The first section lets you enter SAP HANA systems and generic volumes to the sizing and adjust and configure the settings like target region performance modifiers and snapshot and backup parameters. At the bottom of the page, you find the summary of all systems and volumes that have been entered already. I have preloaded the sizer with the 6 TB landscape that we've just talked about. So you see the production system, the pre-production system and all the non-product systems along with all the settings that have been used for this particular sizing. The capacity pool summary section shows the aggregated capacity and performance requirements for all these systems. In this sizing, a total of 86 tab capacity and 5,500 megabytes per second throughput are required. As we discussed earlier, these aggregated requirements are the basis for the capacity pool sizing in the ANF storage cost section. You then find the sizing results. The tool shows that the requirements can be fulfilled with capacity pools in all three service levels. However, choosing the premium service level is the most costefficient option. In this case, the sizing is a capacity bound sizing. That means no extra capacity in the pool needs to be provided to fulfill the performance requirements. During a sizing, you can always go back to the settings and adjust values as needed. The results will be reflected in the sizing immediately. For example, if we increase the snapshot backup change rate for pre-pro systems, you see that the capacity requirements increase. If we increase the performance requirements for the prepro systems, the sizing changes from a capacity bound to a performancebound sizing. That means slightly more capacity needs to be provisioned in the pool to fulfill the performance requirements. We have used this tool to size all the sample landscape variants from 2 TB up to 12 tab. Now let's look at the results. We often hear from customers and partners that while ANF has interesting features for SAP, it is way too expensive compared to an architecture based on Azure managed discs. And indeed, if we compare the infrastructure cost of the primary storage using ANF with the cost for Azure managed discs for the sample landscape on the left side, it appears to be more than three times more expensive for the two TB variant. So what's wrong here? Well, this ANF sizing was done based on the rare peak performance requirements matching the performance of the manage disk configuration and not taking into account that performance with Azure files can easily be adjusted on the fly. A peak performance sizing is not required. Okay, so we fixed that and have based the sizing on the official SAP HANA KPIs for production systems in the middle. But still the ANF cost appears to be between 1.5x and 2.3x of the Azure manage disc cost. The important thing missing here is that both these sizings do not include the backup cost for the SAP landscape. But as I have explained in the beginning, ANF is much more than just primary storage with the snapshot and ANF backup features. It provides a full backup solution for SAP landscapes. Therefore, a valid comp cost comparison should always include the backup architecture. When we now look at the comparison, the picture changes completely. The 2 TB landscape cost is now pretty much on par with the Azure manage disk based solution. With larger landscapes, you can see that the infrastructure cost of Azure files is actually lower than the manage disk based solution. That means customers can actually save money while getting all the great benefits of Azure net files for data management and data protection of SCP landscapes. Wow, that are really interesting results, right? Okay, let's recap what we've discussed in this session. You should have learned the key guidelines for SAP on ANF sizings to ensure you get an optimal and cost optimized ANF deployment. To help you with such sizings, we have introduced our new SAP on ANF sizing estimator tool. Take a look at the blog post about it to get more details. And we have looked at a real world SAP landscape example that showed that you can even save money with SAP on ANF compared to other architectures.To close this off, please also consider these related sessions, specifically 11:25, how ANF powers Oracle at Azure and 1182 with an overview of our solutions for SAP HANA on premises. If you have further questions or you want to stay connected, you can reach us via email or LinkedIn. Thank you and enjoy the rest of the inside event.