Designing SAP Global transport directory using ANF in Azure

Azure NetApp Files (aka ANF) is a first party service offering from Microsoft. ANF provides enterprise grade storage capabilities for performance centric business applications like SAP. ANF is a Platform As A Service (PaaS) offering that simplifies the deployment of a shared file system.  You can read more about ANF here:  https://azure.microsoft.com/en-us/services/netapp/.       

With respect to SAP, ANF can be used for both HANA database, and for the SAP application layer. For the SAP application layer, the most common use case is to use as shared file system for /sapmnt in a cluster, and for the SAP global transport directory.

This article focuses on the ANF use case and possible architecture options for the SAP Global Transport directory in Azure.

The SAP global transport directory (/usr/sap/trans) is a shared location residing on the global domain controller of SAP transport management system (TMS). Depending on the customers requirement, you may have one global transport directory or multiple transport directories. You may also have SAP systems deployed in one region or in multiple regions in Azure. So, how do you plan for ANF for global transport directory?

Please note, as of this article’s publication (Jul 2021), ANF only support VNET peering within same Azure region, Global VNET peering is not supported for ANF.

Here are a few possible deployment scenarios.

For the illustration, we will assume you have three system landscape (Development, Quality, and Production) of S/4HANA systems running in Azure. However, you can extend this to other scenarios like 4 or 5 system landscape, or N+1 (Production and Project systems) landscape.

Scenario 1:  All your S/4HANA systems are in same Azure region and in same VNET.

In this scenario, you can create an Azure NetApp Files account, a capacity pool, and then a volume for the Global transport directory. All systems – Dev, QA, and Production – will access the same transport directory.

Scenario 2:  All your S/4HANA systems are in same Azure region but in different VNETs.

In this scenario, you have a separate VNET for non-production and for a production system. You maintain two separate transport directories and transport files (data and co-files) are forwarded via SAP TMS configuration using SAP Domain Link.

You create an Azure NetApp Files account, a capacity pool, and then two volumes for transport directory (one in each delegated subnet of VNETs).

Note: In this scenario, you can also use single global transport directory like below.  You create an Azure NetApp Files account, a capacity pool, and then the volume for the Global transport directory.

Scenario 3:  A few of your S/4HANA systems are in one Azure region and other S/4HANA systems are in a second Azure region.

In the case, where you have SAP S/4HANA systems deployed at two different Azure regions, the following use cases could arise.

• Scenario 3.1: Hub and Spoke VNETs across regions

In this design, you have a hub VNET and then your VNETs on both the regions are connected to hub VNET. You will use UDR (User Defined Routing) to enable the transient routing between the VNETs over the hub VNET. You configure SAP Domain link in SAP transport management system (TMS) to route your transport files (data/co-files).

You create an Azure NetApp Files account, a capacity pool, and then the volumes for transport directory in each region separately.

• Scenario 3.2: Global VNETs peering across regions

In this scenario, you can peer the VNETs using Global peering and have either rsync copy the transport files (data/co-files) or let SAP Domain Link forward the transport files from source to target system configured in the SAP Transport Management System (TMS).

You create an Azure NetApp Files account, a capacity pool, and then the volumes for transport directory in each region separately.

Hope it helps you to design global transport directory for SAP in Azure using ANF.