SAP deployment on Azure using an Oracle database

SAP systems are used to run mission-critical business applications. Any outage disrupts key processes and can cause increased expenses or lost revenue. Avoiding these outcomes requires an SAP infrastructure that is highly available and resilient to failures.

Building a highly available SAP environment requires eliminating single points of failures in your system architecture and processes. Single points of failure can be caused by site failures, errors in system components, or even human error.

This example scenario demonstrates an SAP deployment on Windows or Linux virtual machines (VMs) on Azure, along with a High Availability (HA) Oracle database. For your SAP deployment, you can use VMs of different sizes based on your requirements.

Potential use cases

Other relevant use cases include:

• Mission-critical workloads running on SAP.
• Non-critical SAP workloads.
• Test environments for SAP that simulate a high-availability environment.

Architecture

This example includes a high availability configuration for an Oracle database, SAP central services, and multiple SAP application servers running on different virtual machines. The Azure network uses a hub-and-spoke topology for security purposes. The data flows through the solution as follows:

1. Users access the SAP system via the SAP user interface, a web browser, or other client tools like Microsoft Excel. An ExpressRoute connection provides access from the organization's on-premises network to resources running in Azure.
2. The ExpressRoute terminates in Azure at the ExpressRoute virtual network (VNet) gateway. Network traffic is routed to a gateway subnet through the ExpressRoute gateway created in the hub VNet.
3. The hub VNet is peered to a spoke VNet. The application tier subnet hosts the virtual machines running SAP in an availability set.
4. The identity management servers provide authentication services for the solution.
5. The jump box is used by system administrators to securely manage resources deployed in Azure.

Components

• Virtual Networks are used in this scenario to create a virtual hub-and-spoke topology in Azure.
• Virtual Machines provide the compute resources for each tier of the solution. Each cluster of virtual machines is configured as an availability set.
• ExpressRoute extends your on-premises network into the Microsoft cloud through a private connection established by a connectivity provider.
• Network security groups limit network access to the resources in a virtual network. A network security group contains a list of security rules that allow or deny network traffic based on source or destination IP address, port, and protocol.
• Resource groups act as logical containers for Azure resources.
• Storage Azure Premium Managed Disks or Azure NetApp Files (for Oracle 19C) provide the recommended storage for the SAP executables and the Oracle database.

Alternatives

SAP provides flexible options for different combinations of operating system, database management system, and VM types in an Azure environment. For more information, see SAP note 1928533, “SAP Applications on Azure: Supported Products and Azure VM Types”.

Considerations

Pricing

To help you explore the cost of running this scenario, all of the services are pre-configured in the cost calculator examples below. To see how the pricing would change for your particular use case, change the appropriate variables to match your expected traffic.

We have provided four sample cost profiles based on amount of traffic you expect to receive:

Size	SAPs	DB VM Type	DB Storage	(A)SCS VM	(A)SCS Storage	App VM Type	App Storage	Azure Pricing Calculator
Small	30000	DS13_v2	4xP20, 1xP20	DS11_v2	1x P10	DS13_v2	1x P10	Small
Medium	70000	DS14_v2	6xP20, 1xP20	DS11_v2	1x P10	4x DS13_v2	1x P10	Medium
Large	180000	E32s_v3	5xP30, 1xP20	DS11_v2	1x P10	6x DS14_v2	1x P10	Large
Extra Large	250000	M64s	6xP30, 1xP30	DS11_v2	1x P10	10x DS14_v2	1x P10	Extra Large

• Small: A small system consists of VM type DS13_v2 for the database server with 8x vCPUs, 56-GB RAM, and 112 GB of temporary storage, along with five 512-GB premium storage disks; an SAP Central Instance server using a DS11_v2 VM types with 2x vCPUs, 14-GB RAM, and 28 GB of temporary storage; and a single VM type DS13_v2 for the SAP application server with 8x vCPUs, 56-GB RAM, and 400 GB of temporary storage, along with one 128-GB premium storage disk.
• Medium: A medium system consists of VM type DS14_v2 for the database server with 16x vCPUs, 112 GB RAM, and 800 GB of temporary storage, along with seven 512-GB premium storage disks; an SAP Central Instance server using a DS11_v2 VM types with 2x vCPUs 14-GB RAM and 28 GB of temporary storage; four VM type DS13_v2 for the SAP application server with 8x vCPUs, 56-GB RAM, and 400 GB of temporary storage, along with one 128-GB premium storage disk.
• Large: A large system consists of VM type E32s_v3 for the database server with 32x vCPUs, 256-GB RAM, and 800 GB of temporary storage, along with three 512 GB and one 128-GB premium storage disk; an SAP Central Instance server using a DS11_v2 VM types with 2x vCPUs, 14-GB RAM, and 28 GB of temporary storage; six VM type DS14_v2 for the SAP application servers with 16x vCPUs, 112 GB RAM, and 224 GB temporary storage, along with six 128-GB premium storage disks.
• Extra Large: An extra-large system consists of the M64s VM type for the database server with 64x vCPUs, 1024 GB RAM, and 2000 GB of temporary storage, along with seven 1024-GB premium storage disks; an SAP Central Instance server using a DS11_v2 VM types with 2x vCPUs 14-GB RAM and 28 GB of temporary storage; ten VM type DS14_v2 for the SAP application servers with 16x vCPUs, 112 GB RAM, and 224 GB of temporary storage, along with ten 128-GB premium storage disks.

Deploy this scenario

Click the link below to deploy the solution.

Next steps

For other information about running SAP production workloads in Azure, review the following reference architectures: