This is the final blog in our four-part series on Designing A Great SAP on Azure Architecture.
Within this blog we will a cover a range of Azure services and a new GitHub repository which can support operational efficiencies for your SAP applications running on Azure.
Let’s get started.
Simplifying SAP Shared Storage architecture with Azure NetApp Files
Azure NetApp Files (ANF) can be used to simplify your SAP on Azure deployment architecture, providing an excellent use case for high availability (HA) of your SAP shared files based on Enterprise NFS.
SAP Shared Files are critical for SAP systems with high availability requirements and more than one application server. Additionally, SAP HANA scale-out systems also require a common set of shared files i.e.
- /sapmnt which stores SAP kernel files, profiles and job logs.
- /hana/shared, which houses binaries, configuration files and traces for SAP HANA scale-out.
Prior to Azure NetApp Files, SAP on Azure customers running Linux with high availability requirements had to protect the SAP Shared Files using Pacemaker clusters and block replication devices. These setups were complex to manage and required a high degree of technical skills to administer. With the introduction of Azure NetApp Files, a Pacemaker cluster can be removed from the architecture which reduces landscape sprawl and maintenance efforts. Moreover, there is no longer a need to stripe disks nor configure block replication technologies for the SAP Shared Files. Rather, Azure NetApp Files volumes can be configured using Azure Portal, Azure CLI or PowerShell and mounted to the SAP Central Services clusters. Azure NetApp Files volumes can also be resized on the fly and protected by way of storage snapshots.
To simplify your SAP on Azure deployment architecture, we have published two scenarios for high availability of your SAP System Central Services and SAP shared files based on Azure NetApp Files with NFS.
Optimizing Dev, Test and Sandbox deployments with Azure Connector for SAP LaMa
Within a typical SAP estate, several application landscapes are often deployed i.e. ERP, SCM, BW etc. and there is an ongoing need to perform SAP system copies and SAP system refreshes, i.e. creating new SAP projects systems for technical/application releases or periodically refreshing QA systems from Production copies. The end-to-end process for SAP system copies and refreshes can be both time-consuming and labor intensive.
SAP LaMa Enterprise Edition can support operational efficiencies in this area where several steps involved in the SAP system copy or refresh can be automated. Our Azure Connector for LaMa enables copying, deletion and relocation of Azure Managed Disks to help your SAP operations team perform SAP system copies and system refreshes rapidly reducing manual efforts.
In terms of virtual machines (VMs) operations, the Azure Connector for LaMa can be used to reduce the run costs for your SAP estate on Azure. You can stop (deallocate) and start your SAP virtual machines which enables you to run certain workloads with a reduced utilization profile i.e. though the LaMa interface scheduling your SAP S/4HANA sandbox virtual machine to be online from 08:00-18:00, 10 hours per day instead of running 24 hours. Furthermore, the Azure Connector for LaMa also allows you to resize your virtual machine when performance demands arise directly from within LaMa.
Save Time and Reduce Errors by Automating SAP Deployments
The manual deployment of your SAP infrastructure and software installation can be time consuming, tedious and error prone. One of the major benefits of Azure is the ability to automate your SAP infrastructure deployment i.e. virtual machines, storage and the installation of your SAP software. Automation reduces errors and deviation and facilitates programmatic and accelerated SAP deployments. As a customer, you have a wide range of automation tools available natively on Azure such as Azure Resource Manager templates and you can also create deployment scripts via both PowerShell and Azure CLI. Moreover, you also have the option to leverage your favorite configuration management tools.
We have included some links below as a kick-starter around Azure automation for your SAP deployment.
Get a Holistic View with Azure Monitor for SAP Solutions
SAP on Azure customers can now benefit from having a central location to monitor infrastructure telemetry as well as database metrics. We have enhanced our Azure Monitor functionality to include SAP Solutions monitoring. This enhancement on Azure Monitor covers both SAP on Azure virtual machines (VMs) and our bare-metal HANA Large Instances (HLI) offering. Azure Monitor for SAP Solution capabilities include:
- Monitoring the health & utilization of infrastructure
- Correlation of data between infrastructure and the SAP database for troubleshooting
- Trending data to identify patterns enabling proactive remediation
Azure Monitor for SAP Solutions does not run an agent on the SAP HANA VM or HLI. Instead, it deploys a managed resource group within your customer subscription which contains resources to collects telemetry from the SAP HANA server and in-turn ingest the data into Azure’s Log Analytics.
Some of the components deployed in managed resource group are:
- Azure Key Vault – used to store customer secrets such as database credentials
- User-Assigned Identity – assigned to Key Vault as access policy
- Log Analytics – workspace to collect and analyze monitoring telemetry
- Collector Virtual Machine– runs the logic to collect telemetry from the SAP HANA database server
Our vision here is to enable a single point of monitoring and analysis where your infrastructure and SAP telemetries coincide to ease issue identification and implement remediations before any fatal outage occurs. A simple example is where the memory utilization trajectory is going critical and SAP HANA starts experiencing column unload., When this happens, an alert is triggered to inform the administrators before the issue exacerbates.
At October 2019, Azure Monitor for SAP is able to collect statistics from SAP HANA and is currently in Private Preview, therefore, please reach out to your Microsoft Account team should you have interest in this service.
Additional resources for optimizing your SAP deployments
The AzureCAT SAP Deployment Engineering team provides deep engagement on customer projects where we help our customers successfully deploy their SAP applications on Azure with quality. Throughout the project lifecycle, there can be times where remediation or optimizations of a customer’s SAP deployment architecture is required. For example:
- Lifting the Resilience of the SAP Deployment Architecture:
A scenario can arise where a customer may have deployed their SAP system in single instance virtual machines (SLA 99.9 percent) rather than a high availability configuration via Azure Availability Sets (SLA 99.95 percent). Now the customer has a need to move to an Availability Set configuration while retaining their existing network (IP, vNIC) and data disks.
- Performance Optimization:
An SAP on Azure customer is already running in Production and would now like to benefit from Proximity Placement Groups to optimize the network performance between their SAP Application and Database virtual machines.
- Availability Zones Selection:
A customer requires guidance to select the optimum Azure Availability Zones to minimize network Round-Trip-Time and facilitate a recovery point objective of zero (sync) for their SAP database.
To address the above topics (and more), we have created a new GitHub repository. This repository will be enduring, and our customers and partners can expect new scripts to land on an ongoing basis to support operational efficiencies of SAP deployments on Azure.
This blog closes out our series on Designing a Great SAP on Azure Architecture. We hope you’ve enjoyed our latest offerings to efficiently operate your SAP assets on Azure and as always, change is the only constant in the world of clouds and we are here to accommodate the change and make it simpler.
As a next step, we recommend you check-out our SAP on Azure Getting Started page.
For the previous blogs in the series you can refer to the links below: