Plan your SAP infrastructure on Azure – Architecture & Documentations

In this article, we will cover the collective considerations for deploying SAP infrastructure on Azure.

Azure SAP Design Tips

1. Use certified Azure VM types
   • Database (Any DB), Application: DS11 v2-DS15 v2 VM, GS1-GS5 VM, E_v3, and M series
   • Database (HANA): GS5 VM, E_v3 series, and M series
2. ExpressRoute is recommended for stable network latency, bandwidth & performance
3. Set up high availability and disaster recovery solutions as needed
   • Database HA/DR: SQL Server AlwaysOn, HANA System Replication, Oracle Data Guard, etc
   • ASCS HA: Windows failover cluster with SIOS DataKeeper, Linux cluster, Windows 2016 failover cluster with SOFS (preliminary / DEV environment)
   • File DR: File replication tool
   • VM DR: Azure Site Recovery (Azure to Azure)
4. Use Premium Storage to VMs running Database
5. Consider additional storage space to store backup
   • Short-term: local storage (same storage as SAP database files)
   • Long-term: Cool storage, Azure Backup Vault

Basic Understanding of SAP Infrastructure on Azure

• SAP System: The combination of DBMS layer and application layer of, for example, an SAP ERP development system, SAP BW test system, SAP CRM production system, etc.. In Azure deployments, it is not supported to divide these two layers between on-premises and Azure. This means an SAP system is either deployed on-premises or it is deployed in Azure. However, you can implement the different systems of an SAP landscape into either Azure or on-premises. For example, you could deploy the SAP CRM development and test systems in Azure but the SAP CRM production system on-premises.
• Cloud-Only deployment: A deployment where the Azure subscription is not connected via a site-to-site or ExpressRoute connection to the on-premises network infrastructure. In common Azure documentation, these kinds of implementations are also described as “Cloud-Only” deployments. Virtual Machines deployed with this method are accessed through the internet and a public IP address and a public DNS name assigned to the VMs in Azure. For Microsoft Windows, the on-premises Active Directory (AD) and DNS is not stretched to Azure in these types of deployments. Hence the VMs are not part of the on-premises Active Directory. Same is also true for Linux implementations using, for example, OpenLDAP + Kerberos.
• Cross-premises: Describes a scenario where VMs are deployed to an Azure subscription that has site-to-site, multi-site, or ExpressRoute connectivity between the on-premises datacenter(s) and Azure. In the current As per Azure documentation, these kinds of deployments are also defined as cross-premises scenarios. The reason for the link is to extend on-premises domains, on-premises Active Directory/OpenLDAP, and on-premises DNS into Azure. The on-premises aspect is extended to the Azure assets of the subscription. Having this extension, the VMs can be part of the on-premises domain. Domain users of the on-premises domain can access the servers and can run services on those VMs (like DBMS services). Communication and name resolution between VMs deployed on-premises and Azure deployed VM is possible.

Architecture Recommendations

Planning

Possible system types for deploying SAP NetWeaver based applications within public cloud environments could be of the below scenarios:

1. Medium-sized production systems
2. Development systems
3. Testing systems
4. Prototype systems
5. Learning / Demonstration systems

As a first step, customers need to verify the following items:

• The SAP supported VM types of Azure
• The SAP supported products/releases on Azure
• The supported OS and DBMS releases for the specific SAP releases in Azure
• SAPS throughput provided by different Azure SKUs

As a second step, Azure resources and bandwidth limitations need to be compared to the original resource consumption of on-premises systems. Therefore, the customers need to be familiar with the various capabilities of the Azure types supported with SAP in the area of:

• CPU and memory resources of different VM types and
• IOPS bandwidth of different VM types and
• Network capabilities of different VM types.

Security Considerations

For infrastructure security, data is safeguarded in transit and at rest. To encrypt Windows and Linux IaaS virtual machine disks, you can use Azure Disk Encryption. Azure Disk Encryption uses the BitLocker feature of Windows and the DM-Crypt function of Linux to provide volume level encryption for the operating system and also the data disks. The solution also works with “Azure Key Vault” to help you constrain and manage the disk-encryption keys and secrets in your Key Vault subscription service. Data on the virtual machine disks are encrypted at rest in your Azure storage.

• Don’t use the HANA data-at-rest encryption with Azure disk encryption on the same server.
• For SAP HANA data-at-rest encryption, we recommend using the SAP HANA native encryption technology.
• Consider using network security groups (NSGs) to restrict traffic between the various subnets in the VNet.
• Use of secure protocols such as SSL/TLS for browser access or VPN-based connections for system access to the Azure services.
• Companies use VPN connection between the on-premises network and Azure differently, but it is suggested to be precise in which ports they need to allow or deny the communications.
• Typical SAP communication ports are listed below. Basically, it is sufficient to open the SAP gateway port.

*) nn = SAP Instance Number

**) sid = SAP-System-ID

Load Balancer

SAP has advocated single-stack application servers for years, so very few applications run on a dual-stack deployment model nowadays. The Azure load balancer implements the high availability cluster for the SAP Web Dispatcher. Load balancing of traffic to the application servers is handled within SAP. For traffic from SAP GUI clients connecting to a SAP server via DIAG and Remote Function Calls (RFC), the SCS message server balances the load by creating SAP App Server Logon Groups.

SMLG is an SAP ABAP transaction used to manage the logon load balancing capability of SAP Central Services.

The backend pool of the logon group has more than one ABAP application server. Clients accessing ASCS cluster services connect to the Azure load balancer through a front-end IP address.

The ASCS cluster virtual network name also has an IP address. This address can be associated with an additional IP address on the Azure load balancer so that the cluster can be managed remotely. SAP Web Dispatcher handles load balancing of HTTP(S) traffic to dual-stack servers (ABAP and Java).

NICs

Assign one administration NIC to a management subnet, and assign a data communication NIC to a separate subnet. For configuration details, see Create and manage a Windows virtual machine that has multiple NICs.

SAP landscape management functions require segregation of server traffic on different NICs. For example, business data should be separated from administrative traffic and backup traffic. Assigning multiple NICs to different subnets enables this data segregation. For more information, see “Network” in Building High Availability for SAP NetWeaver and SAP HANA.

Azure Storage

With all database server VMs, we recommend using Azure Premium Storage for consistent read/write latency. For SAP application servers, including the (A)SCS virtual machines, you can use Azure Standard Storage, because application execution takes place in memory and uses disks for logging only.

For best reliability, we recommend using Azure Managed Disks. Managed disks ensure that the disks for VMs within an availability set are isolated to avoid single points of failure.

To achieve high IOPS and disk bandwidth throughput, the standard practices in storage volume performance optimization apply to Azure storage layout. For example, striping multiple disks together to create a larger disk volume improves IO performance. Enabling the read cache on storage containers that changes infrequently enhances the speed of data retrieval. For details about performance requirements, see SAP note 1943937 – Hardware Configuration Check Tool.

Online Resource:

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/sap/

SAP HANA on Azure Large Instances Design Tips

1. Note backend ExpressRoute and NFS Storage are included in HANA Large Instances offering
2. Note the same ExpressRoute Gateway is used for connections to both users/on-prem and backend HANA
3. Use storage snapshot for HANA DB backup
4. Add one blade to have HANA System Replication for local HA
5. Add one blade (w storage) or just storage in DR site to have HANA Storage Replication for disaster recovery
6. Use HANA volume encryption as needed
7. Run reverse proxy in a VM (e.g., NGINX) if users need direct access to HANA Large Instances (e.g., HANA Studio)
8. Wait for HANA System Replication support for better RPO

Operating Systems and RDBMS Supported on Microsoft Azure

Operating Systems

• Microsoft Windows Server 2008 R2 and 2012 (R2)
• SUSE Linux Enterprise Server 12 (SLES12)
• SUSE SLES for SAP Applications (based on SLES12)
• Red Hat Enterprise Linux 7 (RHEL7)
• Red Hat RHEL for SAP (based on RHEL7)
• Red Hat RHEL for SAP HANA (based on RHEL7)

RDBMS supported on Windows:

• Microsoft SQL Server 2008 R2 or higher
• SAP ASE 16.0 PL02 or higher
• IBM DB2 for Linux, UNIX, and Windows 10.5 or higher
• Oracle Database 11g Release 2 Patchset 3 (11.2.0.4) or higher
• SAP MaxDB version 7.9
• SAP liveCache as part of SAP SCM 7.0 EhP2 (or higher): Minimal version for SAP liveCache: SAP LC/LCAPPS 10.0 SP 27 including liveCache 7.9.08.32 and LCA-Build 27, released for EHP 2 for SAP SCM 7.0 and higher.

RDBMS supported on Linux:

• SAP ASE 16.0 PL02 or higher
• IBM DB2 for Linux, UNIX, and Windows 10.5 or higher

Deployment Phase steps to follow before Large Instances deployment

1. Create Virtual Network in Azure VM
2. Establish a secure connection between Virtual Network and HANA Large Instances servers
3. Deploy a jump box with Linux console in Azure VM to access HANA servers
4. Deploy a Linux patching server in Azure VM to activate Linux OS licenses and patch in HANA servers
5. Setup NTP server for time synchronization
6. Install SAP HANA in HANA servers
7. Install SAP application software in Azure VM
8. Set up snapshot backup from SAP HANA Studio
9. Create Support Request (SR) from Azure Portal

References & Footnotes-

https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/sap/sap-netweaver

https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/planning-guide