Summary

This blog discusses the implementation of SAP BW Scale-Out with 15+1 nodes using Virtual Machines on the Azure Platform, marking one of the pioneering instances of such scale on any Hyperscale Cloud Provider or Public Cloud.

Additionally, it delves into the technical considerations and efforts undertaken by the Microsoft Customer & Partners team to assess the key performance characteristics of SAP BW on both On-Premises and the Azure cloud platform.

The underlying platform infrastructure featured memory-optimized Mv2-Series, providing exceptional computational performance to support large in-memory databases and workloads. Specifically, it comprised 16 x M416s_v2 (416 vCPU / 5.7GiB Memory) strategically architected across Database, (A)SCS nodes, and Application server nodes.

The customer, previously operating the SAP HANA database On-premises with 20 nodes [18+2 Scale-Out], decided to transition critical business systems, including SAP products, as part of the Data Center exit. This migration included core systems like SAP Warehouse Management and relevant systems such as SAP IQ [Near-Line Storage].

As part of the migration, the partner proposed the modernization of certain business processes to leverage Azure Cloud architecture components, enhancing the end-user experience:

1. Increase system availability: Deploying the SAP system across Azure zones within the region to enhance %Availability SLA.
2. Automated failover of access points: Utilizing Standard Load Balancer.
3. Optimization of Scale-out setup using Azure NetApp Files.

The move to the Azure Platform not only provided the customer with high availability but also improved methods for managing database connectivity without relying on DNS.

Implementing SAP BW Scale-Out for Very Large Databases (VLD) can be a time-consuming activity, especially with minimal experience in the market. The architecture necessitates a thorough review of critical design considerations, and the target design architecture underwent testing in a lower environment to ensure the success of all technical tests. Noteworthy insights were gained during the process, particularly regarding Load Balancer settings and the changes implemented to align with customer business expectations.

 

Source: On-premises AS-IS.

The On-premises SAP BW operated with 20 Nodes [18+2] to support the OLAP system.

When engaging in migration programs, it becomes crucial to comprehend the database growth pattern, providing insight into a 3–5-year growth plan. Unlike On-premises setups, Cloud environments eliminate the need to pre-allocate or design the target infrastructure for a specific growth trajectory. However, understanding the growth and resource usage patterns remains vital for crafting an appropriate solution design, preventing the need for subsequent minor or major projects to accommodate unforeseen growth.

For the average peak consumption, we assumed approximately 800,000 SAPS, while the overall measured peak reached around 993,480 SAPS.

Workspace emerges as a critical factor when projecting memory usage and growth for SAP systems. Typically, customers will estimate workspace at 50% or 70%.

Key AS-IS information

User load

Concurrent users must be taken into consideration, and any change that might be part of Roadmap with migration program. Additional resources must be considered in case of significant changes expected with the user load on the target platform.

The "User Activity" diagram below shows the user activity on the system over time.

- Total Users: Total users that logged on in one week.

- Active Users: Users who performed more than 400 transaction steps in one week.

 

System performance

Monitoring the size and growth of the HANA database is crucial for system stability and performance.

 

Log throughput requirement/usage on On-premises system.

One of the critical design considerations is performance of system on-premises as that will be the baseline to create/design target .

Target: 15+1 Scale-Out on Azure To-Be. 

• SAP BW Scale-Out 15+1 with M416s_v2 in Zone1 and 15+1 with M416s_v2 in Zone2.
• Zone Redundant Standard Load Balancer used to keep single point of access across the zones.
• Two Frontend IP addresses with two backend pools for Production & DR nodes respectively.

 

 

 

 

 

 

 

 

 

 

Key Target Design Consideration for Scale-out.

 

SAP mandate execution of HANA Cloud Measurement Tool [HCMT]

 

 

 

Compute – SAP On Azure Certification.

 

Microsoft Cloud multiple SKU that are certified by SAP to run SAP workload and HANA workload. The Certified and Supported SAP HANA® Hardware Directory maintains the list of Hardware SKU by all Hardware providers certified by SAP to run HANA Workload. HANA database as a In-Memory DB requires specific certification criterion to get supported by SAP. Microsoft Engineer team work closely to bring new SKU to be added to the list of Microsoft Cloud Hardware supported by SAP for HANA workload.

For HANA Workload, M-Series (Mv1 & Mv2) are preferred SKU’s but not limited as Microsoft also have E* Series & HLI [HANA Large Instances] that are supported by SAP for HANA workload.

 

Network consideration.

 

There are key differences between Scale-Up and Scale-out, one being the internode communication between scale-out nodes. In Scale-Up the whole database runs on a single VM/SKU, whereas with Scale-Out the database is split/distributed across multiple VMs/SKUs.

• The communication between VMs/SKUs with Scale-Out impact the database performance and so it is highly recommended to have a dedicated NIC (& Subnet) to host/support internode traffic.
• The other key consideration is the communication from Compute and Storage, to ensure a direct connectivity is establish for traffic originating from Compute for Storage – Host based routing is highly recommended and is one of the considerations to meet SAP HANA KPI as part of HCMT execution.
• The 3^rd type of connection is client connection/user traffic
• The 4^th type depends on the configuration, but can be merged with either Client or Internode based on the system requirement during the peak period and must be reviewed during performance & stress testing before Go-Live

 

Azure Standard Load Balancer with Scale-out design

One of the special/custom requirements from the customer was to manage the 3rd parties connections to the HANA database. To ensure seamless connectivity from 3rd party across zones, Azure Standard Load Balancer is configured at the front of Scale-Out nodes across zones. This LB handles not only the connections to the HANA database; it also handles the DR failover scenario.

 

 

 

 

Storage Consideration.

 

For Scale-out with Standby only Azure NetApp Files is the only supported storage as of June 2022. With Azure NetApp Files there are several advantages and features that must be reviewed and considered while designing target architecture.

ANF Storage Tier

Ultra/Premium:

ANF Features

Application Volume Group [AVG]: The Application volume group (AVG) for SAP HANA enables Customer/Partners to deploy all volumes required to install and operate an SAP HANA database according to best practices in a single one-step and optimized workflow. It includes the use of proximity placement group (PPG) with VMs to achieve automated, low-latency deployments.

Manual QoS: With manual QoS volumes, Customers/Partners don’t have to overprovision the volume quota to achieve a higher throughput because the throughput can be assigned to each volume independently. Total available throughput defined at the the capacity pool that depends on the size and type of storage.

Dynamic Tiering: Azure NetApp Files come with three performance tiers: Standard, Premium, and Ultra. Dynamic Tiering allows Customers/Partners to use a higher service level for better performance or a lower service level for cost optimization without waiting time.

ANF files backup: ANF Files backup feature allows Customers/Partners to offload Azure NetApp Files snapshots to Azure blob storage in a fast and cost-effective way, further protecting your data from accidental deletion.

 

 

Backup/Restore approach.

 

Backup/Restore runtime can be another critical showstopper if it is not within the expected Business RPO/RTO requirements.

With ANF, most of customers implement AzAcSnap tool to manage the snapshot of the HANA database followed by AzCopy to transfer the snapshot to blob storage for long term retention.

 

Run Operations/Monitoring.

 

Configuration of Monitoring and kdump is critical to ensure logs/dumps are available to investigate any unforeseen issues with the associated OS/SKU.