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 and is 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 the SAP on Azure reference architectures for 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 in that 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 principals for an Azure enterprise deployment based on a hub-spoke topology.
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:
Relevant 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
This architecture makes use of the following components:
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, and the SAP Central Services cluster.
Availability Zones improve workload availability by distributing its servers across more than one datacenter within an Azure region.
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 and 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 running in Azure without the use of a jumpbox and its associated public IP address, thereby limiting 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 or when you need high-performance storage capable of hosting SAP HANA data and log files.
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.
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.
To help protect SAP global host files for SAP Central Services and the SAP transport directory, you can deploy Network File Shares (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 that provides SSL termination, a Web Application Firewall (WAF) service, and other handy high-availability and scalability features—all in one service. Some SAP deployments have used it as a gateway for the SAP Fiori front end in their production landscape.
This architecture is designed for high availability, scalability, and resilience. For the best results on Azure, consider the recommendations in this section. In addition, 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.
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 “Scale-out” column in 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 logon users, SM61 for batch server groups, RZ12 for RFC groups, and more. 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 depicts 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, and NetApp Files provides a simple option so you don’t have to deploy the 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 principal 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 multiple front-end IPs, so both the Central Services and ERS virtual IPs (VIPs) can be bound to one load balancer.
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 Windows, Red Hat Linux, or SUSE Linux.
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 proximity placement group (but just one) that is anchored by SAP HANA containers of different SIDs.
SAP BW/4HANA is designed for the SAP HANA database platform. Azure provides three scalability and deployment options:
In a scale-up SAP HANA deployment, the database tier uses two or more Linux virtual machines in a cluster to achieve high availability.
A scale-out deployment of SAP HANA is supported for some virtual machine types.
Azure Large Instances for SAP HANA, Revision 4, are special-purpose physical servers, certified to meet SAP HANA Tailored Datacenter Integration (TDI) standards, and located in a Microsoft Azure datacenter.
Standard managed disks are not supported, as stated in SAP Note 1928533. The use of standard storage is not 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.
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, refer to 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.
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, 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.
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.
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.
This architecture places virtual machines that perform 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) and is used in cluster setups to direct traffic to the primary service instance or the healthy node in case of a fault. We recommend using Azure Standard Load Balancer for all SAP scenarios because it offers by-design security implementation and blocks outgoing traffic from the back-end pool unless you enable outbound connectivity to public endpoints.
Also, if you elect to deploy SAP workloads in Azure Availability Zones, the Standard Load Balancer is zone-aware.
This sample design shows the use of the SAP Web Dispatcher 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 application layer services (referred to as layer 7 in the ISO networking model) capable of SSL termination and other offloading functions.
For traffic from SAP GUI clients connecting an SAP server via DIAG protocol or Remote Function Calls (RFC), the Central Services message server balances the load through SAP application server logon groups. No additional load balancer is needed.
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 the Azure Fence Agent. The improved Azure Fence Agent provides significantly 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
For the SAP primary application servers and any additional application servers, high availability is achieved by load balancing traffic within the pool of application servers.
Azure supports a variety of disaster recovery options depending on your requirements. SAP application servers do not contain business data, so a simple strategy is to create SAP application servers in a secondary region and then shut 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 does not persist business data. For details, refer to the SAP S/4HANA reference architecture.
To maximize the availability and performance of applications and services, use Azure Monitor, a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments.
To provide SAP-based monitoring of resources and service performance of the SAP infrastructure, use the Azure SAP Enhanced Monitoring extension. For details, see SAP Note 2191498, “SAP on Linux with Azure: Enhanced Monitoring.”
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.
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 additional infrastructure security considerations that apply to SAP BW/4HANA.