Edit

Share via

Run SAP BW/4HANA with Linux virtual machines on Azure

Azure Bastion
Azure Managed Disks
Azure Virtual Machines
Azure Virtual Network
SAP HANA on Azure Large Instances

The following example focuses specifically on the SAP BW/4HANA application tier. It's suitable for a small-scale production environment of SAP BW/4HANA on Azure, where high availability is a priority.

Architecture

Reference architecture shows a set of proven practices for running SAP HANA in a high-availability, scale-up environment that supports disaster recovery on Azure.

Download a Visio file of this architecture.

Components

This architecture makes use of the following technologies:

  • Azure Virtual Network (VNet) securely connects Azure resources to each other and to an on-premises environment. In this architecture, multiple VNets are peered together.

  • Linux virtual machines are used for the application tier, including:

    • The SAP BusinessObjects (BOBJ) server pool.
    • The SAP Web Dispatcher pool.
    • The application servers pool.
    • The SAP Central Services cluster.

  • Load balancers direct traffic to virtual machines in the application subnet. For high availability, this example uses SAP Web Dispatcher and Azure Standard Load Balancer. These two services also support capacity extension by scaling out, or you can use Azure Application Gateway or other partner products, depending on the traffic type and required functionality you need, such as Secure Sockets Layer (SSL) termination and forwarding.

  • Network security groups (NSGs) attach to a subnet or to the network interface cards (NICs) on a virtual machine. NSGs are used to restrict incoming, outgoing, and intra-subnet traffic in the virtual network.

  • Azure Bastion provides secure access through the Azure portal to virtual machines that run in Azure, without using a jumpbox and its associated public IP address. This mechanism limits internet-facing exposure.

  • Azure managed disks Premium or Ultra storage disks are recommended. These storage types provide data persistence for virtual machines with the SAP workload.

  • Azure NetApp Files supports shared storage when using a cluster. It also supports shared storage when you need high-performance storage that can host SAP HANA data and log files. Azure NetApp Files is fully managed and scalable enough to meet the demands of most applications. It gives bare-metal performance, submillisecond latency, and integrated data management for your complex enterprise workloads on:

    • SAP HANA.
    • High-performance computing.
    • LOB applications.
    • High-performance file shares.
    • Virtual desktop infrastructure.

  • Power BI enables users to access and visualize SAP BW/4HANA data from their Windows desktop. Installation requires the SAP BW Connector (implementation 2.0).

    Microsoft Power BI Desktop imports data from various SAP sources, such as SAP BW/4HANA, for analysis and visualization. Power BI also complements SAP BusinessObjects Universe by offering a business context or a semantics layer over the raw information.

  • Azure Backup is an SAP Backint-certified data protection solution for SAP HANA in single-instance and scale-up deployments. Azure Backup also protects Azure Virtual Machines with general workloads.

  • Azure Site Recovery is recommended as part of an automated disaster recovery solution for a multitier SAP NetWeaver application deployment. The support matrix details the capabilities and restrictions of this solution.

Alternatives

  • To help protect SAP global host files for SAP Central Services and the SAP transport directory, you can deploy Network File System (NFS) servers in a failover cluster configuration.

  • SIOS Protection Suite, available in Azure Marketplace, can be used to protect the global host files for Central Services instead of NFS or Azure NetApp Files.

  • Azure Application Gateway is a web traffic load balancer. In one service, it provides SSL termination, a Web Application Firewall (WAF) service, and other handy high-availability and scalability features. Some SAP deployments have used it as a gateway for the SAP Fiori front end in their production landscape.

Scenario details

SAP BW/4HANA is an enterprise data warehouse solution designed for the cloud and optimized for the SAP HANA platform. The following example focuses specifically on the SAP BW/4HANA application tier. It's suitable for a small-scale production environment of SAP BW/4HANA on Azure, where high availability is a priority.

This example workload also draws on the foundation of a pair of SAP on Azure reference architectures: SAP NetWeaver (Windows) for AnyDB on virtual machines and SAP S/4HANA for Linux virtual machines on Azure. A similar deployment approach is used for SAP BW/4HANA workloads. The application layer is deployed using virtual machines that can be changed in size to accommodate your organization's needs.

The network layout has been simplified to demonstrate recommended architectural principles for an Azure enterprise deployment based on a hub-spoke topology.

Note

Many deployment considerations apply when deploying SAP workloads on Azure. For more ideas and further information, see the SAP on Azure planning and deployment checklist.

For details about the data persistence layer, see:

Potential use cases

This scenario is relevant to the following use cases:

  • Deployment of the SAP application layer separate from the DBMS layer

  • Disaster recovery (DR) scenarios

  • Deployments of the SAP application tier

Recommendations

This architecture is designed for high availability, scalability, and resilience. For the best results on Azure, consider the recommendations in this section. Also, many of the recommendations for running SAP S/4HANA on Azure also apply to SAP BW/4HANA deployments. For details about SAP S/4HANA on Azure, see the reference architecture.

Virtual machines

For details about SAP support for Azure virtual machine types and throughput metrics (SAPS), see SAP Note 1928533, "SAP Applications on Azure: Supported Products and Azure Virtual Machine Types." (To access this and other SAP notes, an SAP Service Marketplace account is required.)

For information about whether a virtual machine type has been certified for scale-out deployments of SAP HANA, see the SAP HANA Hardware Directory.

Application servers pool

In application servers pool, you can adjust the number of virtual machines based on your requirements. Azure is certified to run SAP BW/4HANA on Red Hat Enterprise Linux and SUSE Linux Enterprise.

To manage logon groups for ABAP application servers, it's common to use the SMLG transaction to load-balance different groups, such as:

  • Logon users.
  • SM61 for batch server groups.
  • RZ12 for RFC groups.

These transactions use the load-balancing capability within the message server of Central Services to distribute incoming sessions or workload among SAP application servers pool for SAP GUIs and RFC traffic.

SAP Central Services cluster

This example shows a highly available cluster that uses Azure NetApp Files as a shared file storage solution. High availability for the Central Services cluster requires shared storage. Azure NetApp Files provides a simple highly available option so you don't have to deploy a Linux cluster infrastructure. An alternative is to set up a highly available NFS service.

You can also deploy Central Services to a single virtual machine with Premium-managed disks and get a 99.9-percent availability SLA.

The virtual machines used for the application servers support multiple IP addresses per NIC. This feature supports the SAP recommended practice of using virtual host names for installations as outlined in SAP Note 962955. Virtual host names decouple the SAP services from the physical host names and make it easier to migrate services from one physical host to another. This principle also applies to cloud virtual machines.

Application servers are connected to the highly available Central Services on Azure through the virtual host names of the Central Services or ERS services. These host names are assigned to the cluster front-end IP configuration of the load balancer. A load balancer supports many front-end IPs. Both the Central Services and ERS virtual IPs (VIPs) can be bound to one load balancer.

Multi-SID installation

Azure also supports high availability in a multi-SID installation of the Linux and Windows clusters that host Central Services (ASCS/SCS). For details about deploying to a Pacemaker cluster, see the Azure multi-SID documentation for:

Proximity placement groups

This example architecture also uses a proximity placement group to reduce network latency between virtual machines. This type of group places a location constraint on virtual machine deployments and minimizes the physical distance between them. The group's placement varies as follows:

  • In a single SID installation, you should place all Central Services and application servers in the proximity placement group anchored by the SAP HANA database.

  • In a multi-SID installation, you have the freedom to associate the Central Services and application servers with any single proximity placement group that's anchored by SAP HANA containers of different SIDs.

Database

SAP BW/4HANA is designed for the SAP HANA database platform. Azure provides three scalability and deployment options:

Storage

This example uses Premium managed disks for the non-shared storage of the application servers. It also uses Azure NetApp Files for cluster shared storage.

Azure Premium SSD v2 is designed for performance-critical workloads like SAP. See Deploy a Premium SSD v2 for information about the storage solution's benefits and current limitations.

Ultra Disk Storage significantly reduces disk latency. As a result, it benefits performance-critical applications like the SAP database servers. To compare block storage options in Azure, see Azure managed disk types.

Standard managed disks aren't supported, as stated in SAP Note 1928533. The use of standard storage isn't recommended for any SAP installations.

For the backup data store, we recommend using Azure cool and archive access tiers. These storage tiers are cost-effective ways to store long-lived data that is infrequently accessed.

Networking

Although not required, a hub-spoke topology is commonly deployed to provide logical isolation and security boundaries for an SAP landscape. For other networking details, see the SAP S/4HANA reference architecture.

The hub VNet acts as a central point of connectivity to an on-premises network. The spokes are VNets that peer with the hub, and they can be used to isolate workloads. Traffic flows between the on-premises datacenter and the hub through a gateway connection.

Most customer implementations include one or more ExpressRoute circuits connecting on-premises networks to Azure. For less network bandwidth demand, VPN is a lower-cost alternative.

Considerations

These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that can be used to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.

Performance efficiency

Performance efficiency is the ability of your workload to scale to meet the demands placed on it by users in an efficient manner. For more information, see Performance efficiency pillar overview.

SAP BW/4HANA is designed for real-time data warehousing tasks. SAP application servers carry on constant communications with the database servers, so minimizing latency from the application virtual machines to the database contributes to better application performance. Disk caching and server placement are two strategies that help reduce latency between these two components.

For performance-critical applications running on any database platforms, including SAP HANA, use Premium managed disks and enable Write Accelerator for the log volume. Write Accelerator is available for M-series virtual machines and improves write latency. However, when available, use Ultra managed disks in place of Premium disks without Write Accelerator. Ultra disk capabilities continue to evolve. To see if these disks meet your requirements, review the latest information about the service scope of ultra disks. Do this review especially if your implementation includes Azure resiliency features such as availability sets, Availability Zones, and cross-region replication.

To help performance by reducing the physical distance between the applications and database, use a proximity placement group, as mentioned earlier. Scripts and utilities are available on GitHub.

To optimize inter-server communications, use Accelerated Networking, which is available for supported virtual machines, including D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2, and Ms/Mms. In all SAP implementations, Accelerated Networking is required—especially when Azure NetApp Files is used.

To achieve high IO per second and disk bandwidth throughput, the common practices in storage volume performance optimization apply to Azure storage layout. For example, combining multiple disks together to create a striped disk volume improves IO performance. Enabling the read cache on storage content that changes infrequently enhances the speed of data retrieval.

Scalability

This example architecture describes a small, production-level deployment with the flexibility to scale based on your requirements.

At the SAP application layer, Azure offers a wide range of virtual machine sizes for scaling up and scaling out. For an inclusive list, see SAP Note 1928533. As we continue to certify more virtual machines types, you can scale up or down in the same cloud deployment.

Availability

Resource redundancy is the general theme in highly available infrastructure solutions. If your organization has a less stringent SLA, use single-instance virtual machines with Premium disks, which offer an uptime SLA.

To maximize application availability, you can deploy redundant resources in an availability set or across Availability Zones. For more information, see the SAP S/4HANA reference architecture.

This architecture places virtual machines that do the same role into an availability set. This configuration helps meet SLAs by guarding against downtime caused by Azure infrastructure maintenance and unplanned outages. Two or more virtual machines per availability set are required to get a higher SLA.

Azure Load Balancer

Azure Load Balancer is a network transmission layer service (layer 4). In cluster configurations, Azure Load Balancer directs traffic to the primary service instance or the healthy node if there's a fault. We recommend using Azure Standard Load Balancer for all SAP scenarios. It offers by-design security implementation and blocks outgoing traffic from the back-end pool unless you enable outbound connectivity to public endpoints. In addition, you can also use an Azure NAT Gateway to get outbound connectivity.

Also, if you decide to deploy SAP workloads in Azure Availability Zones, the Standard Load Balancer is zone-aware.

Web Dispatcher

In this sample design, the SAP Web Dispatcher is used simply as an HTTP(s) load-balancing mechanism, for SAP traffic among the SAP application servers. To achieve high availability for the Web Dispatcher component, Azure Load Balancer implements either the failover cluster or the parallel Web Dispatcher setup. See SAP Web Dispatcher in the SAP documentation.

As a software load balancer, Web Dispatcher offers extra layer services that can do SSL termination and other offloading functions. These layer services are known as layer 7 in the ISO networking model.

No other load balancer is needed for traffic from SAP GUI clients that connect an SAP server via DIAG protocol or Remote Function Calls (RFC). The Central Services message server balances the load through logon groups in the SAP application server.

The Web Dispatcher component is used as a load balancer for SAP traffic among the SAP application servers. To achieve high availability of the SAP Web Dispatcher, Azure Load Balancer implements either the failover cluster or the parallel Web Dispatcher setup.

For internet-facing communications, a stand-alone solution in DMZ would be the recommended architecture to satisfy security concerns.

Embedded Web Dispatcher on ASCS is a special option, and proper sizing because of extra workload on ASCS should be taken into account.

Central Services

To protect the availability of SAP Central Services (ASCS) on Azure Linux virtual machines, you must use the appropriate high availability extension (HAE) for your selected Linux distribution. HAE delivers Linux clustering software and OS-specific integration components for implementation.

To avoid a cluster split-brain problem, you can set up cluster node fencing using an iSCSI STONITH Block Device (SBD), as this example shows. Or you can instead use the Azure Fence Agent. The improved Azure Fence Agent provides much faster service failover compared to the previous version of the agent for Red Hat and SUSE environments.

Other application servers in the application servers tier

To achieve high availability for the SAP primary application servers and other application servers, load-balance traffic within the pool of application servers.

Disaster recovery

Azure supports various disaster recovery options depending on your requirements. SAP application servers don't contain business data, so you can create SAP application servers in a secondary region before shutting them down. SAP application server software updates and configuration changes should be replicated to the disaster recovery side either manually or on a schedule. You can build a virtual machine in the disaster recovery region to run the Central Services role, which also doesn't persist business data. For details, see the SAP S/4HANA reference architecture.

Monitoring

To maximize the availability and performance of applications and services, use Azure Monitor, which includes Azure Log Analytics and Azure Application Insights and provides sophisticated tools for collecting and analyzing telemetry. It can help you maximize the performance and availability of your cloud and on-premises resources and applications. You can use Azure Monitor to monitor infrastructure and application anomalies, send alerts to administrators, and automate reactions to predefined conditions.

For SAP applications that run on SAP HANA and other major database solutions, see Azure Monitor for SAP solutions to learn how Azure Monitor for SAP can help you manage the availability and performance of SAP services. Azure Monitor for SAP provides a comprehensive initial set of metrics and telemetry for monitoring. The metric definitions are stored as SQL queries in JSON and can be modified to meet your requirements. The starting set of metrics is available on GitHub here.

Backup

For the SAP ASCS and application servers, we recommend using Azure Backup to protect the virtual machine contents. Azure Backup provides independent, isolated backups to help guard against accidental destruction of original data. Backups are stored in a Recovery Services vault that offers built-in management of recovery points. Configuration and scalability are simple, backups are optimized, and you can easily restore as needed.

Backup of the database tier varies depending on whether SAP HANA is deployed on virtual machines or Azure Large Instances. See the management and operations considerations for SAP HANA on Linux virtual machines.

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.

SAP has its own User Management Engine (UME) to control role-based access and authorization within the SAP application and databases. For details, see the Security Guide SAP BW∕4HANA.

The SAP S/4HANA reference architecture provides other infrastructure security considerations that apply to SAP BW/4HANA.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal author:

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps

Learn more about the component technologies:

Explore related architectures: