Automating SAP deployments in Microsoft Azure using Terraform and Ansible

Deploying complex SAP landscapes into a public cloud is not an easy task. While SAP basis teams tend to be very familiar with the traditional tasks of installing and configuring SAP systems on-premise, additional domain knowledge is often required to design, build, and test cloud deployments.

There are several options to take the guesswork out of tedious and error-prone SAP deployment projects into a public cloud:

◈ One way to get started is the SAP Cloud Appliance Library (CAL), a repository of numerous SAP solutions that can be directly deployed into a public cloud. However, apart from its cost, CAL only contains pre-configured virtual machine (VM) images, so configuration changes are hard or impossible.
◈ A free alternative has been to use SAP Quickstart Templates offered by most public cloud providers. Typically written in a shell script or a proprietary language, these templates offer some customization options for pre-defined SAP scenarios. For example, Azure’s ARM templates offer one-click deployments of SAP HANA and other solutions directly in Azure Portal.)
While both solutions are great starting points, they usually lack configuration options and flexibility required to build up an actual, production-ready SAP landscape.

Based on feedback from actual customers who move their SAP landscapes into the cloud, the truth is that existing Quickstart Templates rarely go beyond “playground” systems or proof-of-concepts; they are too rigid and offer too little flexibility to map real-life business and technical requirements.

This is why we, the SAP on Microsoft Azure Engineering team, decided to go into the opposite direction: Instead of offering “one-size-fits-all” templates for limited SAP scenarios that can hardly be adapted (let alone extended), we broke down SAP deployments in Azure to the most granular level and offer “building blocks” for a truly customizable, yet easy-to-use experience.

A new approach to automating SAP deployments in the cloud

In this new, modular approach to automating even more complex SAP deployments in Azure, we developed a coherent collection of:

◈ Terraform modules which deploy the infrastructure components (such as VMs, network, storage) in Azure and then call the:
◈ Ansible playbook which call different:
◈ Ansible roles to install and configure OS and SAP applications on the deployed infrastructure in Azure.

Flow diagram of Terraform/Ansible SAP automation templates.

An important design consideration was to keep all components as open and flexible as possible; although nearly every parameter on both Azure and SAP side can be customized, most are optional. In other words, you can be spinning up your first SAP deployment in Azure within 10 minutes by using one of our boilerplate configuration templates – but you can also use our modules and roles to build up a much more complex landscape.

A sample deployment of HANA high-availability pair.

For your convenience, Terraform and Ansible are pre-installed in your Azure Cloud Shell, so the templates can be run directly from there with minimal configuration. Alternatively, you can, of course, use them from your local machine or any VM as well.

While the repository is published and maintained by Microsoft Azure, the project is community-driven and we welcome any contributions and feedback.

Starting with SAP HANA, but a lot more to come

When we started building our Terraform and Ansible templates a few months ago, we decided to start out our engineering process with HANA. SAP’s flagship in-memory database is the underlying platform and de-facto standard of most modern SAP enterprise applications, including S/4HANA and BW/4HANA. If you’ve ever built an SAP HANA high-availability cluster from scratch, you’ll appreciate that we’ve taken the guesswork out of this complex task and aligned our templates to the public cloud reference architectures certified by SAP.

Currently, our Terraform/Ansible templates support the following two options (more application-specific scenarios are currently being worked on):

HANA single-node instance

◈ Single-node HANA instance.

HANA high-availability pair

◈ Single-node HANA instance, two-tier replication (primary/secondary) via HSR.

◈ Pacemaker high-availability cluster, fully configured with SBD and SAP/Azure resource agents.

Since our key focus was to offer the greatest amount of flexibility possible, virtually every aspect of the SAP HANA landscape can be customized, including:

◈ Sizing (choose any supported Azure VM SKU).

◈ High-availability (in the high-availability pair scenario, choose to use availability sets or availability zones).

◈ Bastion host (optionally, choose from a Windows and/or Linux “jump box” including HANA Studio).

◈ Version (currently, HANA 1.0 SPS12 and HANA 2.0 SPS2 or higher are supported).

◈ XSA applications (optionally, enable XSA application server and choose from a set of supported applications like HANA Cockpit or SHINE).

XSA SHINE demo content for HANA.

It’s worth noting that all scenarios come with “fill-in-the-blanks” boilerplate configuration templates and step-by-step instructions to help you get started.