SAP on Azure: General Update – January 2018
SAP and Microsoft are continuously adding new features and functionalities to the Azure cloud platform. This blog includes updates, fixes, enhancements and best practice recommendations collated over recent months.
1. M-Series, Dv3 & Ev3-Series VMs Now Certified for NetWeaver
Three new VM types are certified and supported by SAP for NetWeaver AnyDB workloads. AnyDB refers to NetWeaver applications running on SQL Server, Oracle, DB2, Sybase or MaxDB.
A subset of these VMs is currently being certified for Hana.
Dv3 VM type has 4GB of RAM per cpu and is suitable for SAP application servers or small DBMS servers
Ev3 VM type has 8GB of RAM per cpu for E2v3 – E32v3. The E64v3 has 432GB. This VM type is suitable for large DBMS servers
M VM type has up to 3.8TB and 128cpu and is suitable for very large DBMS workloads
All three of these new VM types has many new features, in particular greatly improved networking performance. More information on Dv3/Ev3 Azure Service Availability site details the release status of each VM type per datacenter, however Ev3/Dv3 should generally be available everywhere
New VM Types and SAPS values:
|VM Type||CPU & RAM||SAPS|
|D2s_v3||2 CPU, 8 GB||2,178|
|D4s_v3||4 CPU, 16 GB||4,355|
|D8s_v3||8 CPU, 32 GB||8,710|
|D16s_v3||16 CPU, 64 GB||17,420|
|D32s_v3||32 CPU, 128 GB||34,840|
|D64s_v3||64 CPU, 256 GB||69,680|
|E2s_v3||2 CPU, 16 GB||2,178|
|E4s_v3||4 CPU, 32 GB||4,355|
|E8s_v3||8 CPU, 64 GB||8,710|
|E16s_v3||16 CPU, 128 GB||17,420|
|E32s_v3||32 CPU, 256 GB||34,840|
|E64s_v3||64 CPU, 432 GB||70,050|
|M64s||64 CPU, 1000 GB||67,315|
|M64ms||64 CPU, 1792 GB||68,930|
|M128s||128 CPU, 2000 GB||134,630|
The official list of VM types certified for SAP NetWeaver applications can be found in SAP Note 1928533 - SAP Applications on Azure: Supported Products and Azure VM types
SAP cloud benchmarks are listed here:
E64v3 Benchmark can be found here
D64v3 Benchmark can be found here
m128 Benchmark can be found here
m128 BW Hana Benchmark can be found here
2. SAP Business One (B1) on Hana & SQL Server Now Certified on Azure
SAP Business One is a common SMB ERP solution. Many SAP B1 customers run on SQL Server today. SAP B1 on SQL Server is now Generally Available for Azure VMs
SAP has also ported SAP B1 to Hana. SAP B1 on Hana is now certified on Azure DS14v2 for approximately 40 users
Customers planning to run SAP B1 on Azure may be able to lower costs by using the B1 Browser Access feature available in more modern versions of SAP B1. Browser Access in some cases eliminates the need to install the B1 client on Terminal Server VMs on Azure.
These SAP Notes may be useful:
2442627 - Troubleshooting Browser Access in SAP Business One 2194215 - Limitations in SAP Business One Browser Access 2194233 - Behavior changes in Browser Access mode of SAP Business One as compared to Windows desktop mode
SAP on Azure certification information can be found here:
3. Managed Disks Recommended for SAP on Azure
Managed Disks are generally recommended for all new deployments.
Managed Disks reduce complexity and improve availability by automatically distributing storage for VM in an availability set onto different storage nodes so that the failure of a single storage node will not cause an outage on two or more VMs in an Availability Set
1. Managed Standard disks are not supported for SAP NetWeaver application server or DBMS server. The Azure host monitoring agent does not support Managed Standard disks.
2. In general it is recommended to deploy SAP application servers without additional data disk and install the /usr/sap/<SID> on the boot disk. The boot disk can be up to 1TB in size, however SAP application servers do not require this much storage space and do not require high IOPS under normal circumstances
3. It is not possible to add both managed and unmanaged disks to a VM that is in an availability set
4. SQL Server VMs running with datafiles directly on blob cannot leverage or utilize the features of Managed Disks
5. In general it is recommended to use Managed Premium disks for SAP application servers so that these VMs are guaranteed the financially backed Azure Single VM SLA of 99.9% (Note: the actual achieved SLA is typically much higher than 99.9%)
6. In general it is recommended to use Managed Premium disks for SAP DBMS servers as detailed in SAP Note 2367194 - Use of Azure Premium SSD Storage for SAP DBMS Instance
A good overview of managed disks is available here:
A deep dive on managed disks is available here:
Pricing and performance details for the various Azure Disks can be found here:
A very good Frequently Asked Questions is here
4. Sybase ASE 16.3 PL2 "Always-on" on Azure
Sybase ASE 16 SP2 and higher is supported on Windows and Linux on Azure as documented in SAP Note 1928533 - SAP Applications on Azure: Supported Products and Azure VM types
Sybase ASE includes a HA/DR solution called "Always-on". The features and functions of this Sybase solution is very different than SQL Server AlwaysOn. This HA solution does not require shared disks.
For information about Sybase ASE release schedule review
The central Sybase HA documentation can be found here:
SAP support multiple replica databases according to SAP Note 2410733 - Always-On (HADR) support for 1-to-many replication - SAP ASE 16.0 SP02 PL05
Sybase "Always-on" does not require an Azure ILB and the installation on Azure is relatively transparent. There is no requirement to configure an Internal Load Balancer in typical configurations. Sybase 16 SP3 PL2 is meant to offer several new features for SAP customers.
If there are questions about the setup of Sybase on Azure or inconsistencies in the documentation, please open an OSS message to BC-DB-SYB.
5. Resource Groups, Tags, Role Based Access Control, Billing, VNet, NSG, UDR and Resource Locking
Before starting an Azure deployment it is very important to design the core "Foundation Services" and structures that will support the IaaS and PaaS resources running on Azure.
To document the recommendations to design and configure all these elements would be a multi-part blog itself. This topic provides a starting point for customers planning their Azure deployment for SAP landscapes and the kinds of questions that commonly asked by SAP customers
1. Resource Groups provide a way monitor, control access, provision and manage billing for collections of Azure objects. Often SAP customers deploy a Resource Group per environment, such as Sandbox, Dev, QAS and Production. This allows for a simple billing breakdown per environment. If a business unit wants a clone of production for testing new business processes, built in Azure functionality can be used to clone production and copy this into a new Resource Group called "Project". The monthly cost can be monitored and charged back to the business unit that requested this system
2. Azure Tags are used by some SAP customers to provide additional attributes about a particular VM or other Azure object. For example a VM could be tagged as "ECC 6.0" or "NetWeaver Application Server". Azure tags allow for more precise billing and security control with Role Based Access Control. It is possible to query tags and for example determine which VMs are SAP or non-SAP VMs, which VMs are application servers or DBMS servers
3. Role Based Access Control allows a customer to segregate duties, delegate limited administrative rights to teams such as the SAP Basis Team and create a fine-grained security model. It is common to delegate significant Azure IaaS rights to the Basis Team. Basis should be allowed to create and change many Azure resources such as VMs. Typically Basis would not be able to create or change VNet or network level resources
4. Billing allows greater cost transparency than on-premises solutions. Azure Resource Groups and Tags should be designed so that it is very clear which SAP system or environment corresponds to line items on Azure monthly bills. Ideally additional project systems or systems requested by individual business units should be able to be charged back.
5. Azure VNet, NSG and UDR design is normally handled by a network expert and not the SAP Basis Team. There are some factors that must be considered when designed the VNet topology and the NSG and UDR:
a. Communication between the SAP application servers and DBMS servers must not be routed or inspected by virtual appliances. SAP is very sensitive to latency between application server and DBMS server. "Hub & Spoke" network topologies are one solution that allows security and inspection of client traffic while avoiding inspection of SAP traffic
b. Often the DBMS servers and Application servers are placed in separate subnets on the same VNet. Different NSGs are then applied to SAP application servers and DBMS servers
c. UDR should not route traffic unnecessarily back to the on-premises proxy server – common mistakes seen include: SQL Server with datafiles on blob are accessed via the on-premises proxy server! (leading to very poor performance) or http(s) communication between SAP applications is routed back to on-premises proxies
It is now popular to deploy a "Hub and spoke" network topology.
A very good blog https://blogs.msdn.microsoft.com/igorpag/2016/05/14/azure-network-security-groups-nsg-best-practices-and-lessons-learned/ https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview 6. Azure Resource Locking prevents accidental deletion of Azure objects such as VMs and storage by preventing deletion. It is recommended to create the required Azure resources at the start of a project. When most add/move/changes are finished and the Azure deployment is stabilized all the resources can be locked. Only a super administrator can then unlock a resource and allow the resource (such as a VM) to be deleted.
It is considerably easier to implement these best practices before a system is live. It is possible to move Azure objects such as VMs between subscriptions or resources groups as illustrated below (full support for Managed Disk environments due early 2018. In the interim it is possible to download VHD files for a Managed Disk VM using the "Export" button in Azure portal).
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/move-vm https://docs.microsoft.com/en-gb/azure/azure-resource-manager/resource-group-move-resources (pls refer Virtual machines limitations section)
6. AzCopy for Linux Released
AzCopy is a popular utility for copying blob objects within Azure or for uploading or downloading objects from on-premises to Azure. An example could include uploading R3load dump file from on-premises to Azure while migrating from UNIX/Oracle to Win/SQL on Azure.
AzCopy is now available for Linux platforms. This utility requires the .Net framework 2.0 for Linux to be installed
AzCopy for Windows is available here. To improve AzCopy throughput the /NC:<xx> parameter can be specified. Depending on the bandwidth and latency of a connection values between 16-32 could significantly improve throughput. Values too much higher than 32 may saturate most internet links
An alternative to AzCopy is Blobxfer
7. Read Only Domain Controllers – RODC: Is a RODC More Secure on Azure Than a DC?
Read Only Domain Controllers is a feature that has been available for many years. This feature is documented here:
The differences between a Read Only Domain Controller and a writeable domain controller are explained here:
Recently multiple customers have proposed to put RODC in Azure stating that they believe this to be "more secure".
The security profile of a RODC and a writeable domain controller on Azure with an ExpressRoute connection back to on-premises Domain controllers is very similar. The only exception is the "Filtered Attribute Set" – some AD attributes may not be replicated to a RODC (but almost all attributes are replicated)
There are some recommendations for securing Domain Controllers on Azure and in general:
1. Intruders can query Active Directory RODC or Writeable DC equally – so called "surveying" trying to find vulnerable, weak or unsecured user accounts. IDS and IPS solutions should be deployed both on Azure and on-premises to detect surveying
2. One of the single biggest security enhancements possible is to implement Multi-factor authentication – Azure has built in services for Multi-factor authentication
3. It is recommended to use Azure Disk Encryption on the boot disk and the disks containing the DS database, logs and SYSVOL. This prevents cloning the entire VM, then downloading the VHD files and starting up the RODC or writeable DC. Debugging tools can then be used to try to compromise the AD database
Summary: deploying a RODC instead of a writeable Domain Controller does not significantly change the security profile of a Active Directory solution on Azure deployments with ExpressRoute connections back to on-premises AD infrastructure. Instead use IDS, multi-factor authentication and Azure Disk Encryption in conjunction with other security measures to build a highly secure AD environment. Do not rely on the simple fact that a Domain Controller is read only as the sole security mechanism
8. Azure Site Recovery: Update on Support Status
Azure Site Recovery is a powerful platform feature that allows customers to achieve best-in-class Disaster Recovery capabilities at a fraction of the cost of competitive solutions.
A blog and a whitepaper has been released detailing how to deploy Azure Site Recovery for SAP applications https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-sap http://aka.ms/asr-sap
There are several new features and capabilities that will be added to the Azure Site Recovery feature and some features that are already available:
1. Azure Disk Encryption is a feature that scrambles the contents of Azure boot and/or data disks. Support for this feature will be in preview soon. If this feature is required please contact Microsoft
2. Support for Storage Spaces and SIOS is Generally Available
3. Support for VMs with Managed Disks will be released soon
4. Cross subscription replication will be added in early 2018
5. Support for Suse 12.x will be added in 2018
More information on ASR and ADE
https://azure.microsoft.com/en-us/blog/tag/azure-site-recovery/ https://azure.microsoft.com/en-us/services/site-recovery/ https://docs.microsoft.com/en-us/azure/security/azure-security-disk-encryption-faq
9. Non-Production Hana Systems
It is supported to run Hana DBMS servers on non-Hana certified hardware and cloud platforms. This is documented in SAP Note 2271345 - Cost-Optimized SAP HANA Hardware for Non-Production Usage
It is recommended to review the PowerPoint and Word document attached to this SAP Note. The note states that the "whitebox" type servers typically used for Hyperscale cloud can be used for non-production systems and that virtualized solutions are also possible.
Therefore, it is completely possible to run non-production Hana systems on Azure VMs.
In general Disaster Recovery systems are considered to be Production as they could run production workloads.
10. Oracle Linux 7.x Certified on Azure for Oracle 11g & 12c
The Azure platform gives customers the widest choice of operating system and database support. Recently SAP has supported Oracle DBMS running on Linux VMs.
The full list of operating systems and database combinations supported on Azure is officially listed in SAP Note 1928533 - SAP Applications on Azure: Supported Products and Azure VM types
1. SAP + Oracle + Linux + Azure = Fully supported and Generally Available
2. Oracle DBMS must be installed on Oracle Linux 7.x
3. Oracle Linux 7.x or Windows can be used for SAP application servers and standalone engines (see PAM for details)
4. It is strongly recommended to install the latest updates for Oracle Linux before starting SWPM
5. The Linux host monitoring agent must be installed as detailed in SAP Note 2015553 - SAP on Microsoft Azure: Support prerequisites
6. Customers wishing to use Accelerated Networking with Oracle Linux should contact Microsoft
7. It is not supported to run Oracle DBMS on Suse or RHEL
Important SAP Notes and information:
https://wiki.scn.sap.com/wiki/display/ORA/Oracle 2039619 - SAP Applications on Microsoft Azure using the Oracle Database: Supported Products and Versions 2069760 - Oracle Linux 7.x SAP Installation and Upgrade 405827 - Linux: Recommended file systems 2171857 - Oracle Database 12c - file system support on Linux 2369910 - SAP Software on Linux: General information 1565179 - This note concerns SAP software and Oracle Linux
Note: SAP + Oracle + Windows + Azure = Fully supported and Generally Available (supported since a long time, many multi-terabyte customers live on Azure)
11. Oracle 12c Release 2 is Certified by SAP and Released on Windows 2016. ASM Support on Azure in Planning
SAP has certified Oracle 12c Release 2 for SAP NetWeaver applications as documented in SAP Note 2133079 - Oracle Database 12c: Integration in SAP environment
Oracle 12c Release 2 is supported on Windows 2016 in addition to certified Linux distributions.
Oracle Database version 220.127.116.11 (incl. RDBMS 18.104.22.168, Grid Infrastructure 22.214.171.124 and Oracle RAC 126.96.36.199) is certified for SAP NetWeaver based SAP products starting December 18th, 2017. The minimum initial RDBMS 188.8.131.52 SAP Bundle Patch (SBP) is SAP12201P_1711 (Unix) or PATCHBUNDLE12201_1711 (Windows).
At least SAP Kernel version 7.21_EXT is required for Oracle 184.108.40.206
SAP note 2470660 provides important technical information about using Oracle 220.127.116.11 in a SAP environment, like database installation/upgrade guidelines, software download, patches, feature support, OS prerequisites, etc.
The Oracle features supported in Oracle version 12.1 (like Oracle In-Memory, Oracle Multitenant, Oracle Database Vault and Oracle ILM/ADO) are supported for version 18.104.22.168 as well.
Microsoft are working to obtain certification of Oracle ASM on Azure. The first combination planned is Oracle Linux 7.4 and Oracle 12c R1/R2. This blogsite will be updated with more information later
998004 - Update the Oracle Instant Client on Windows
12. Accelerated Networking Recommended for Medium & Large SAP Systems
Accelerated Networking drastically reduces the latency and significantly increases the bandwidth between two Azure VMs
Accelerated Networking is Generally Available for Windows & Linux VMs
It is generally recommended to deploy Accelerated Networking for all new medium and large SAP projects
Additional points to note about Accelerated Networking:
1. It is not possible to switch on Accelerated Networking for existing VMs. Accelerated Networking must be enabled when a VM is created. It is possible to delete a VM (by default the boot and data disks are kept) and create the VM again using the same disks
2. Accelerated Networking is available for most new VM types such as Ev3, Dv3, M, Dv2 with 4 physical cpu or more (as at December 2017 – note E8v3 is 4 physical CPU with 8 hyperthreads)
3. Accelerated Networking is not available on G-series VM types
4. SQL Server running with datafiles stored directly on blob storage are likely to greatly benefit from Accelerated Networking
5. Suse 12 Service Pack 3 (Suse 12.3) is strongly recommended (Hana certification is still in progress as at December 2017). RHEL 7.4 recommended. Contact Microsoft for Oracle Linux.
6. It is possible to have one or more Accelerated Network NICs and a traditional non-accelerated network card on the same VM
7. Azure vNet UDR and/or other security and inspection devices should not sit between the SAP application servers and database server. This connection needs to be as high performance as possible
8. SAP application server to database server latency can be tested with ABAP report /SSA/CAT -> ABAPMeter
9. Inefficient "chatty" ABAP code or particularly intensive operations such as large Payroll jobs or IS-Utilities Billing jobs have shown very significant improvement after enabling Accelerated Networking
Additional useful information about Azure Networking can be found here:
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-create-vm-accelerated-networking https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-optimize-network-bandwidth https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-bandwidth-testing https://blogs.msdn.microsoft.com/igorpag/2017/04/06/my-personal-azure-faq-on-azure-networking-v3/ https://blogs.msdn.microsoft.com/saponsqlserver/2016/11/21/moving-from-sap-2-tier-to-3-tier-configuration-and-performance-seems-worse/
Below is an example of very inefficient ABAP code that will thrash the network. Placing a SELECT statement inside a LOOP is very poor coding standards. Accelerated Networking will improve the performance of poorly coded ABAP, but it is generally recommended to avoid a SELECT statement inside a LOOP. This code is totally non-scalable and as the number of iterations increase the performance will degrade severely.
13. New Azure Features
The Azure platform has many new features and enhancements added continuously.
A good summary of many of the new features can be found here:
Several new interesting features for SAP customers include:
1. Two different datacenters can communicate over a vNet-to-vNet Gateway connection. An alternative currently in preview is Global Peering
2. SoftNAS for storing files, DIR_TRANS and interfaces. Support NFS and SMB protocols
3. Azure Data Box is useful for data center migration scenarios
4. CIS images – these are hardened Windows images. These have not been fully tested with all SAP applications. These images should work for SAPWebDispatcher, SAP Router etc
5. SAP LaMa now has a connector for Azure 2343511 - Microsoft Azure connector for SAP Landscape Management (LaMa)
7. Azure Service Endpoints remove some public endpoints and move the service to an Azure vNet
Other useful links below
SAP on Windows & Oracle presentation covering Oracle features for Windows http://www.oracle.com/technetwork/topics/dotnet/tech-info/oow2016-whatsnew-db-windows-3628748.pdf
A new and interesting feature for UNIX/Oracle customers wishing to terminate UNIX platforms and move to Intel commodity servers is Oracle Cross Platform Transportable Tablespaces
The diagram shows the process for creating a backup that can be taken on a UNIX Big Endian system and successfully restored onto an Intel Little End system (Windows or Linux).
Additional information is in SAP Note 552464 - What is Big Endian / Little Endian? What Endian do I have?
A similar question is sometimes received from customers that have installed SAP Hana on IBM Power servers. These customers either want to move away from Hana on Power (a rather niche solution) or they wish to run DR on public cloud. SAP Note 1642148 - FAQ: SAP HANA Database Backup & Recovery states that Hana 2.0 backups can be restored from IBM Power (Little Endian) onto Intel based systems
Content from third party websites, SAP and other sources reproduced in accordance with Fair Use criticism, comment, news reporting, teaching, scholarship, and research