Hello and welcome to this short introduction video on the new Azure NetUP files feature application volume group for SAP HANA. You might have seen that the feature is now in general availability and is planned to be the standard provisioning method for ANF volumes used for SAP HANA. We have put together a series of short videos to explain the application volume group feature and the usage for the different SAP HANA deployments. This video explains why this feature is crucial for SAP HANA workloads and also provides some technical background about the provisioning workflow. We will also cover the prerequisites for application volume group and the HANA deployment types supported by the feature. The volume provisioning for these different HANA deployment types are then covered in the other videos of the series. Let's get started with an overview on application volume group for SAP HANA. And let me explain why this feature is crucial for SAP HANA using Azure NetUP files. As you know, SAP HANA applications are performance demanding and require submilliseconds latency and high throughput numbers. The placement of the ANF volumes used for SAP HANA is critical to fulfill these requirements. With the standard ANF volume provisioning workflow, the required latency and the performance can't be guaranteed and often manual interaction with the Azure team was required with application volume group. An application specific provisioning workflow has been developed which covers three main areas. It guarantees lowest latency and best performance. It highly simplifies the volume provisioning by configuring all required HANA volumes in a single step and by preconfiguring the volume capacity and throughput numbers using best practices and it supports the main SAP HANA configuration options including high availability and disaster recovery configurations.Okay, with that let me provide some background around the architectural requirements to achieve lowest latency and best performance. Compute as well as ANF hardware is organized in clusters which are connected to network switches. In order to ensure lowest latency, the compute hardware hosting the HANA VM as well as the ANF hardware hosting the HANA volumes must be in close proximity to each other. Technically, they must be connected to the same network spine. In addition to the proximity of the HANA VM and the ANF volumes, the application volume group logic places data and lock volumes of a HANA system on different ANF hardware. These storage endpoints are configured with individual IP addresses to ensure direct access in the ANF cluster with lowest latency. Using different IP addresses for the HANA data and lock volume is also crucial for the NFS client performance on a Linux host. The Linux NFS client manages an individual IO queue for each individual IP address. Having a dedicated queue for data and lock ensures best latency and performance on the Linux host. Lastly, the application volume group workflow also provisions a lock and a data backup volume. These volumes are provisioned separated of the data and lock volume outside of the proximity group.This example shows the provisioning workflow for SEP HANA singlehost system. First, the user has to provide a couple of input values that describe the HANA system as well as the ANF environment. In addition, the proximity placement group that should be used must be provided based on the RAM size of the HANA system. Capacity and throughput numbers will be calculated and proposed for the volumes to be provisioned. In total, five volumes will be provisioned. HANA data lock and shared volume will be provisioned within the proximity placement group. A naming con convention including the SID of the HANA system will be used for the volume names. Data and lock backup volumes will be provisioned outside of the proximity placement group and three different IP addresses will be used for the provisioned volumes. There are a couple of prerequisites and preparations that need to be done before using AVG.for SAP HANA is leveraging Azure proximity placement group functionality to ensure that the ANF volumes are placed close to the HANA VM to provide lowest latency. A reset pinning is used to create a permanent anchor to the Azure compute cluster and the associated network spine. Before requesting the pinning request using a request form, a proximity placement group and an empty availability set must be created. The pinning request form also asks for information about Azure VM type and ANF capacity plan for the HANA system. Based on this information, the Microsoft Azure team is defining the compute cluster with the corresponding ANF hardware close by. When using the pinning request form, the Microsoft Azure team can check upfront if compute and ANF hardware is available and it is therefore guaranteed that the AVG provisioning workflow will be successful.The pinning request process has to be initiated for each HANA system. A HANA system can either be a single or a multiple host system. The HANA pinning request form is available online. The main input parameter cover AV set and VM type information as well as information about the ANF environment. Before the AVG provisioning workflow can be used, a proper ANF configuration must be available. AVG requires a capacity pool with manual quality of service. Capacity pools with quality of service type auto are not supported. A delegated subnet for ANF must be available within the VNET. It is recommended to use a class C delegated subnet for ANF since the set of volumes provisioned with AVG require more IP addresses compared to normal provisioned volumes. As already briefly touched, AVG can be used to provision the ANF volumes for the most common HANA system layouts. This includes single host as well as multiple host systems. For single and a multiple host systems, secondary system volumes can be provisioned either in a HANA system replication setup or for disaster recovery using ANF cross region replication.Depending on the HANA system type and the configuration of high availability with HANA system replication or DR with ANF cross region replication, the AVG deployment process is either a single step or a multiplestep configuration. Any configuration always starts with the volume provisioning for a HANA single host system. A single host system can then be extended in a second step to a multiple host system, a HANA system replication setup or a DR solution using ANF cross region replication. Additional configuration steps need to be done if a multiple host system should be configured with HSR or ENFRR. For all these configuration options, we provide recorded demos which show and explain the workflows using AVG. The demo part one also explains the used lab setup and the prerequisites for using AVG. So, if you plan to watch the demos, you should start with demo part one. With that, thanks a lot for watching the video. Take care and bye-bye.