SAP on Azure landing zone accelerator

Use the SAP on Azure landing zone accelerator to set up and operate workload landing zones inside your Cloud Adoption Framework enterprise-scale landing zone. The landing zone accelerator provides a specific architectural approach and reference implementation for your SAP systems on Azure.

Deploy the SAP on Azure landing zone accelerator after you successfully implement an enterprise-scale landing zone. Before you deploy the SAP on Azure landing zone accelerator, review the enterprise-scale overview and implementation guidance.

Adapt the accelerator to your architecture

The architecture of the SAP on Azure landing zone accelerator varies by organization. Technical considerations and design recommendations lead to configurations that are unique to your organization's specific scenario. The recommendations that this article describes can lead to an architecture that puts your organization on a path to sustainable scaling.

The SAP on Azure landing zone accelerator is modular. You can customize environment variables. The customizable approach to landing zones includes the following assets to support your planning and implementation:

• Design guidelines
• Architecture
• Implementation

Design guidelines

As you plan the implementation of your enterprise-scale landing zone, you need to make design decisions relating to several overall areas. These articles provide design guidelines and recommendations for each area:

• Identity and access management
• Network topology and connectivity
• Management and monitoring
• Business continuity and disaster recovery
• Security, governance, and compliance
• Platform automation and DevOps

Architecture

You need to understand and plan for all critical areas of your deployment architecture. This article describes the key components of the landing zone architecture in Azure and your SAP systems architecture.

Landing zone architecture

The following diagram is a conceptual reference architecture that shows the critical design areas in an SAP on Azure landing zone accelerator:

Download a Visio file of this architecture.

High-level SAP systems architecture

The following diagram is a reference architecture of an SAP systems landscape that includes production and non-production systems. This architecture is one of many options that you can use to deploy SAP systems on Azure. The implementation you choose depends on your requirements.

Use the reference architecture as a starting point. You can download the Visio file and modify it to fit your specific business and technical requirements when you plan your landing zone implementation.

Workflow

This article provides an example of a high-level, overall SAP architecture that's spread across different tiers.

The SAP systems example architecture describes an SAP systems landscape that has production and non-production systems. Both systems are deployed on virtual machines. You can change the sizes and numbers of virtual machines to accommodate your organization's needs.

This example architecture uses virtual machine scale sets to deploy SAP systems on Azure. The network layout in this example is simplified to demonstrate architectural principles and isn't intended to describe an entire enterprise network.

Recommendations

Your deployment might be different, depending on your business requirements. These recommendations provide a starting point.

Subscriptions

The example SAP systems architecture uses the following three subscriptions:

• An Azure virtual hub subscription that contains the hub virtual network for the primary and secondary regions.

• An Azure SAP production subscription, where the production and disaster recovery systems are configured.

• An Azure SAP non-production subscription, where a non-production system includes a sandbox or development, quality assurance, or pre-production systems. This configuration is optional. You can use a subscription for each workload zone.

Networking

The example SAP systems architecture uses a hub-spoke topology. The hub virtual network acts as a central point of connectivity to an on-premises network. The spokes are SAP virtual networks that are peered with the hub. You can use the spokes to isolate workloads.

The architecture uses one SAP virtual network per workload zone. It uses a different SAP virtual network for production, development, quality assurance, and the sandbox. In the architecture, the Azure hub virtual network is peered with the production, development, quality assurance, and sandbox virtual networks. Traffic flows between the on-premises datacenter and the hub through a gateway connection.

Subnets and network security groups

The architecture subdivides the virtual network address space into subnets. You can associate each subnet with a network security group that defines the access policies for the subnet. Place application servers on a separate subnet so that you can more easily provide security for them. You can manage the subnet security policies instead of managing individual servers. When you associate a network security group with a subnet, the network security group applies to all the servers in the subnet, and you have fine-grained control over the servers.

This architecture has three or four subnets, depending on the tier. For example, a production system might have the following four subnets.

• Azure NetApp Files: A delegated subnet for using Azure NetApp Files for different SAP on Azure scenarios.
• Azure Application Gateway: A subnet that handles traffic coming from the internet. For example, this subnet might handle Fiori apps.
• SAP applications: A subnet that contains SAP application servers, SAP Central Services, SAP enqueue replication services instances, and web dispatchers.
• Database: A subnet that contains only database virtual machines.

Virtual machine scale sets

For all pools and clusters (SAP Web Dispatcher, SAP application servers, SAP Central Services, and SAP HANA), group the virtual machines in separate virtual machine scale sets. There's no charge for creating a virtual machine scale set. You pay only for each virtual machine that you create.

Virtual machines and availability zones

An Azure availability zone is a unique physical location within a region. Each zone is made up of one or more datacenters that are equipped with independent power, cooling, and networking.

When you design for availability zones, check the latency between zones. Knowing the network latency between the zones of a region helps you choose availability zones that have the least network latency for cross-zone network traffic.

When you set up your availability zones, use zone-redundant services for your instances of ExpressRoute, Azure VPN Gateway, and Application Gateway.

For more information about the availability zone architecture for SAP on Azure, see SAP HA availability zones.

It is important to ensure all Azure resources used in your workload are set up with Zone-redundant or across availability zones for zonal components. In order to assist in the process assign Azure Policy Initiative for Zone Resilience to intermediate Management Group. This ensures “start resilient & stay resilient” approach. The Zone Resilient built-in policies aim to:

• Deliver clear and actionable information that assists in the design, planning, and automation of AZ-resilient deployments.
• Detect: Audit subscriptions for non-compliance of these policies.
• Prevent configurations using the Deny effect for resources that do not adhere to zone resiliency standards.

Compliance to this initiative can be checked at the end of the Implementation process. More information of the Azure Policy Initiative for Zone Resilience can be found here.

Azure NetApp Files and Azure Files

Azure NetApp Files and Azure Files with Network File System (NFS) and Server Message Block (SMB) provide high-availability file share requirements for SAP Central Services, a shared SAP mount, and a global transport directory.

To handle transport directory requirements, use the transport groups option as described in Azure Virtual Machines planning and implementation for SAP NetWeaver. Another way to handle the transport requirements is to make one of the SAP tiers the primary production system that provides the transport directory share to other systems in the landscape.

The high-availability requirements for SAP Central Services differ depending on the operating system. For example:

• For a Linux operating system, the shared file systems are typically placed on high-availability NFS storage or Azure NetApp Files instances to provide a high-availability NFS share. For more information, see NFS over Azure Files or Azure NetApp Files.

• For information about high availability on Windows, see Azure Files with SMB and Azure NetApp Files with SMB.

Azure NetApp Files shares can host SAP HANA data and log files. Use this configuration for a HANA scale-out deployment model with standby nodes. Azure NetApp Files supports HANA scale-up or HANA scale-out with standby nodes.

Azure Files provides two main types of endpoints for accessing Azure file shares:

• Public endpoints have a public IP address that can be accessed from anywhere in the world.

• Private endpoints are in a virtual network and have a private IP address within the address space of that virtual network.

The example SAP systems architecture uses private endpoints so that clients on a virtual network can access data over a private link, which improves security.

SAP BTP connectivity

Azure Private Link is now generally available. SAP Private Link Service currently supports connections from SAP BTP, the Cloud Foundry runtime, and other services on top of Private Link resources for the most common load balancer plus virtual machine scenarios. Example scenarios include SAP S/4HANA or SAP ERP running on the virtual machine and connecting to Azure native services like Azure Database for MariaDB or Azure Database for MySQL.

The example architecture shows an SAP Private Link Service connection to BTP environments. SAP Private Link Service establishes a private connection between specific SAP BTP services and specific services in your infrastructure as service provider accounts. If you reuse the private link functionality, BTP services can access your S/4 HANA environment through private network connections, which avoids data transfer over the public internet.

For more information about scenarios for connecting to BTP services, see the SAP Community blog post about the architecture effect of Private Link Service.

Considerations

Take into account the following considerations when you design your landing zone.

Landscape consolidation

Consider setting up landscape consolidation for non-production systems like sandbox and development environments. For example, consider different use cases:

• HANA database scenarios typically run an application and a database in separate virtual machines.

• AnyDB scenarios might have two-tier deployments in which the SAP application and database run on the same virtual machine.

The components are separate in the example SAP systems architecture to provide greater flexibility for maintenance, sizing, monitoring, and change control. Choose a design based on your requirements.

Component information

The example architecture has components that you can use for day-2 operations. These components include an Azure Recovery Services vault to back up SAP systems and others that help you extend and improve your SAP data platform with cloud-native Azure data services.

Services like Azure Synapse Analytics, Azure Data Factory, and Azure Data Lake Storage can help you unlock business insights by combining SAP data with non-SAP data and creating an analytics platform. To evaluate solution development environment design, review the best practices. You can use different instances of Data Factory and Data Lake Storage based on the SAP tier and best practices for your environment design.

The Azure integration runtime is the compute infrastructure that Data Factory and Azure Synapse pipelines use to provide data integration capabilities. Consider deploying runtime virtual machines for these services in each tier. For examples of how to connect with SAP systems and deploy the Azure integration runtime, see these articles:

• Set up a self-hosted integration runtime to use in the SAP CDC solution

• Copy data from SAP ECC

• Copy data from SAP HANA

• Copy data from an SAP table

• Copy data from SAP Business Warehouse via Open Hub

For more information about all architecture components, see SAP S/4HANA in Linux on Azure.

SAP landscape architecture example with three SAP products

The following reference architecture is an extension of the high-level architecture that appears earlier in this article. The diagram describes an example use case with three SAP products. It shows just one of the options you can use to deploy SAP systems to Azure by using virtual machine scale sets.

Use this architecture as a starting point. Download the Visio file and modify it to fit your specific business and technical requirements when you plan your landing zone implementation.

Example workflow

SAP customers run various SAP products based on their specific use cases. The architecture diagram shows an example use case with three common SAP products. It illustrates an example SAP architecture that's spread across different tiers.

In the workflow diagram, ERP represents a legacy SAP ECC system or a next-generation SAP S/4HANA system. BW is SAP Business Warehouse. PI/PO refers to process integration or process orchestration. Different colors represent various SAP products as they appear in the workflow.

Implementation

There are two implementation options.

Option 1

The SAP deployment automation framework on Azure is a collection of processes combined with a flexible workflow. The framework repository contains code to automatically deploy SAP landscapes on Azure. Templates are separated into the following categories.

• Terraform on Azure modules. Use Terraform modules to deploy infrastructure components on Azure, including:
  • Virtual machines
  • Network
  • Storage
• Ansible playbooks. Use Ansible playbooks to:
  • Set up and deploy virtual machines.
  • Install SAP HANA.
  • Install other required applications.

Deploy and install Ansible playbook components on your infrastructure by using Terraform on Azure modules.

Option 2

Azure Center for SAP solutions is a set of Azure services that provides a unified solution for deploying and managing SAP workloads by bringing services, tools, and frameworks together.

Virtual Instance for SAP solutions is the foundation of Azure Center for SAP solutions. You can use Virtual Instance for SAP solutions to create and manage SAP systems in a way that makes sense to you, at the SID level or at the individual component level.

You can use the Azure Center for SAP solutions to take the following steps:

1. Deploy. Choose how to deploy your SAP system on Azure.
2. Represent. Create a logical representation of each system as you deploy or register existing deployments.
3. Manage. Configure operations with management capabilities.

Azure Center for SAP solutions provides these capabilities:

Guided SAP deployment

Azure Center for SAP solutions automates the deployment of SAP S/4HANA systems on Azure. It provides a guided solution for deploying the infrastructure and automatically installs S/4HANA software.

You provide minimal input and can choose the right type of deployment. The deployments are based on the latest best practices and reference architectures. You can get sizing recommendations to deploy the SAP system based on SAPS and database memory requirements.

Registration of existing SAP systems

If you're already running SAP systems on Azure or are in the process of a migration, you can use Azure Center for SAP solutions to integrate your existing systems by using a simple registration process. This registration process is supported for SAP S/4HANA and NetWeaver ABAP systems that run on Linux and Windows.

Intelligent SAP management

Whether you're creating a new SAP system or registering an existing system, Azure Center for SAP solutions provides these benefits:

• Quality checks, integrated with Azure Advisor, so you know when infrastructure and operating system configurations deviate from documented best practices and standards. These checks can save time during troubleshooting and increase system quality by prompting you to act before the deviations cause problems.
• Ability to view SAP status and health across multiple SAP systems from a centralized tool. This capability enables you to quickly identify problems that affect SAP systems and their components.
• Ability to stop and start an SAP system directly from Azure.
• Ability to view post-deployment costs at the SAP SID level.
• Integration with Azure Monitor for SAP solutions. This integration provides technical monitoring and enables you to correlate the telemetry of the SAP system with the telemetry of the OS, DBMS, and underlying Azure infrastructure.
• Ability to search across your SAP systems based on an SID by using Azure Resource Graph. This capability makes it easier to discover which Azure resources are part of the SAP landscape. Resource Graph is an Azure service that provides efficient resource exploration by enabling you to query at scale across subscriptions.

Next steps

Review the following design areas for your SAP on Azure landing zone accelerator architecture:

• Enterprise enrollment
• Identity and access management
• Network topology and connectivity
• Resource organization
• Governance
• Operations baseline
• Business continuity and disaster recovery
• Deployment options