Best practices in migrating SAP applications to Azure – part 1

23rd April 2019 Anthony Mashford 0 Comments

This is the first blog in a three-part blog post series on best practices for migrating SAP to Azure.

Designing a great SAP on Azure architecture

In this blog post we will touch upon the principles outlined in “Pillars of a great Azure architecture” as they pertain to building your SAP on Azure architecture in readiness for your migration.

A great SAP architecture on Azure starts with a solid foundation built on four pillars:

Security
Performance and scalability
Availability and recoverability
Efficiency and operations

Designing for security

Your SAP data is likely the treasure of your organization's technical footprint. Therefore, you need to focus on securing access to your SAP architecture by way of secure authentication, protecting your application and data from network vulnerabilities, and maintaining data integrity through encryption methods.

SAP on Azure is delivered in the Infrastructure-as-a-Service (IaaS) cloud model. This means security protections are built into the service by Microsoft at the physical datacenter, physical network, physical host level, and the hypervisor. Therefore, for those areas above the hypervisor (e.g. the guest operating system for SAP), you need to undertake a careful evaluation of the services and technologies you select to ensure you are providing the proper security controls for your architecture.

In terms of authentication, you can take advantage of Azure Active Directory (Azure AD) to enable single-sign-on (SSO) to your S/4HANA Fiori Launchpad. Azure AD can also be integrated with the SAP Cloud Platform (SCP) to provide single-sign-on to your SCP services which can also be run on Azure.

Network Security Groups (NSG) allow you to filter network traffic to and from resources in you virtual network. NSG rules can be defined to allow or deny access to your SAP services, for instance, allowing access to the SAP Application ports from on-premises IP addresses ranges and deny public Internet access.

With regards to data integrity, Azure Disk Encryption helps you encrypt your SAP virtual machine disks where both the operating system and data volumes can be encrypted at rest in storage. Azure Disk Encryption is integrated with Azure Key Vault which controls and manages your encryption keys. Many of our SAP customers choose Azure Disk Encryption for their operating system disks and transparent DBMS data encryption for their SAP database files. This approach secures the integrity of the operating system and ensures database backups are also encrypted.

To dig further into topics of interest in the security area, you can refer to our Azure Security documentation.

Designing for performance and scalability

Performance is a key driver for digitizing business processes, and having a performant SAP application is crucial for end users to work efficiently without frustration. Therefore, it is important to undertake a quality sizing exercise for your SAP deployment and to right-size your Azure components – compute, storage, and network.

SAP Note #1928533 details the SAPS value for Azure Virtual Machines supported to run SAP Applications, and within the links below you can attain the network and storage throughput per Azure VM type:

The agility of Azure allows you to scale your SAP system with ease, for example, increasing the compute capacity of the database server or horizontally scaling through the addition of application servers when demand arises. This includes temporarily beefing up the infrastructure to accelerate your SAP migration throughput and reduce the downtime.

We recommend you leverage virtual machine accelerators for your SAP application and database layers. Enable Accelerated Networking on your virtual machines to accelerate network performance. In scenarios where you will run your SAP database on M-Series virtual machines, consider enabling the Write Accelerator durable write cache on your database log volumes to improve write I/O latency. Write Accelerator is mandatory for productive SAP HANA workloads to ensure a low write latency (sub ms) to the /hana/log volume.

Use Premium Storage Managed Disks for the SAP database server to benefit from high-performance and low-latency I/O. Be mindful, that you may need build a RAID-0 stripe to aggregate IOPS and throughput to meet your application needs. In the case of SAP HANA workloads, we cover storage best practice within our documentation, “SAP HANA infrastructure configurations and operations on Azure.”

ExpressRoute or VPN facilitates connectivity for on-premises SAP end users and application interfaces connecting to your SAP applications in Azure. For production SAP applications in Azure, we recommend ExpressRoute for a private, dedicated connection which offers reliability, faster speed, lower latency, and tighter security. Be mindful of latency sensitive interfaces between SAP and non-SAP applications, you may need to define migration “move groups” where groups of SAP applications and non-SAP applications are landed on Azure together.

Designing for availability and recoverability

Operational stability and business continuity are crucial for mission critical, tier-1 SAP applications. Designing for availability ensures that SAP application uptime is secured in the event of localized software or hardware failures. In the case of productive SAP applications, we recommend the virtual machines which run the SAP single points of failure, such as the system central services A(SCS) and database are deployed in Availability Sets or Availability Zones, to protect against planned and unplanned maintenance events. This also applies to the SAP Application servers where a few smaller servers are recommended instead of one larger application server. Operating system cluster technologies such as Windows Failover cluster or Linux Pacemaker would be configured on the guest OS to ensure short failover times of the A(SCS) and DBMS. DBMS synchronous replication would be configured to ensure no loss of data.

Designing for recoverability means recovering from data loss, such as a logical error on the SAP database or from large scale disasters, or loss of a complete Azure region. When designing for recoverability, it is necessary to understand the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) of your SAP Application. Azure Regional Pairs are recommended for disaster recovery which offer isolation and availability to hedge against the risks of natural or man disasters impacting a single region.

On the DBMS layer, asynchronous replication can be used to replicate your production data from your primary region to your disaster recovery region. On the SAP application layer, Azure-to-Azure Site Recovery can be used as part of an efficient, cost-conscious disaster recovery solution.

It is essential to carefully consider both availability and recoverability within the design of the SAP deployment architecture. This will protect your business from financial losses resulting in downtime and data loss.

Designing operations and efficiency

Your move to Azure also presents an opportunity to undertake an SAP system rationalization assessment. Do you need to move all SAP systems or can you decommission those which are no longer used? For example, Microsoft-IT decommissioned approximately 60 virtual machines as part of our SAP migration to Azure.

In terms of efficiency, focus on eliminating waste within your SAP on Azure deployment. Post go-live, review the sizing. Can you reduce the size of your virtual machine based on utilization? Can you drop disks which are not being used?

De-allocating or “snoozing” of virtual machines can bring you tremendous cost savings. For example, running your SAP Sandbox systems 10 hours x 5 days, instead of 24 hours x 7 days would reduce your costs by approximately 70 percent in a pay-as-you-go model. Where your SAP application needs to run 24 x 7 opt for Azure Reserved Instances to drive down your costs.

Establishing infrastructure manually for each SAP deployment can be tedious and error prone, often costing hours or days if multiple SAP installation are required. Therefore, to improve efficiency it makes sense to automate your SAP infrastructure deployment and software installation as much as possible. Embrace the DevOps paradigm using infrastructure-as-code to build new SAP environments as needed, such as in SAP project landscapes. Below, some links to give you a head start on automation.

As you embark on your SAP to Azure journey, we recommend that you dive into our official documentation to deepen your understanding of using Azure for hosting and running your SAP workloads.

Use our SAP Workload on Azure Planning and Deployment Checklist as a compass to navigate through the various phases of your SAP migration project. Our checklist will steer you in the right direction for a quality SAP deployment on Azure.

We also recommend that you explore our whitepaper, “Migration Methodologies for SAP on Azure” where we dig into the various migration options to land your SAP estate on Azure. In scenarios where your SAP application has a giant database footprint we also have your covered. For more information refer to the blog post, “Very Large Database Migration to Azure.”

The next blog in our series will focus on the migration to Suite-on-HANA and S/4HANA on Azure.

Source: Azure Blog Feed

Mashford's Musings