Automated SAP/HA Deployments in Public and Private Clouds with Terraform

Supported terraform version 1.1.X

• About
• Overview
  • Components Details
  • Products
  • Cloud Providers
  • Features
• Project Structure
• Getting started
• Troubleshooting

About

This Project provides a high configurable way to deploy SAP HANA database and SAP S/4HANA (or SAP NetWeaver) on various cloud platforms.

Both public cloud and private cloud scenarios are possible. The major cloud providers Google Cloud Platform (GCP), Microsoft Azure, and Amazon Web Services (AWS) are supported. Furthermore OpenStack and libvirt/KVM can be used.

It shall give an improved user experience for our SAP customers and partners. and deployment will takes minutes/hours instead of days. You can use it for POC or production deploymentes

Everything is powered by SUSE Linux Enterprise Server for SAP Applications.

Overview

The diagram above shows components for an example setup. Several features can be enabled or disabled through configuration options to control the behavior of the HA Cluster, the SAP HANA and SAP S/4HANA or SAP NetWeaver. The setup is also dependent on the cloud provider which is used.

Components Details

• SAP HANA Database: HANA might be deployed as a single SAP HANA database instance, or as a two-node configuration with system replication. Even HANA Scale-Out scenarios can be deployed, depending on the cloud provider (see Features section). In addition a SUSE HA cluster can be set on top of that. Please also have a look at Preparing SAP software

• SAP S/4 HANA (or NetWeaver): S/4HANA can be deployed with a single PAS instance or as a full stack including ASCS, ERS, PAS and AAS (multiple) instances. In the latter sce case, a SUSE HA cluster is set on top of ASCS/ERS. For more information see S/4HANA and NetWeaver and Preparing SAP software.

• ISCSI server: This provides Stonith Block Devices used by the sbd fencing mechanism. Also see Fencing mechanism Native fencing mechanisms are available for some cloud environments (see Features section).

• Monitoring server: The monitoring solution is based on prometheus🔗 and grafana🔗. It provides informative and customizable dashboards to users and administrators. Every node has prometheus exporters installed which are used to collect the needed metrics. For more information see Monitoring of cluster.

• DRBD cluster: It is used to provide a highly available NFS server for cloud providers that lack a native solution. It will be used to mount SAP NetWeaver shared files. For more information see DRBD. Some cloud providers have native solutions for high available NFS (see Features section), which should be preferred over the DRBD solution.

• Bastion server: A bastion server is used to have a single internet-facing entry point (ssh) for the administrator and the provisioning process. Security-wise, it is a best practice to access you machines this way. The availability of this solution depends again on the used cloud provider (see Features section).

For more on various topics have a look on the following documentation:

• SUSE saptune

Products

This repository supports deployment with following products:

Cloud Providers

This repository supports deployment on the following SAP certified providers cloud providers:

Features

The following features are implemented:

Legend:

Project Structure

This project heavily uses terraform🔗 and salt🔗 for configuration and deployment.

Terraform is used to create the required infrastructure in the specified cloud.

The code is divided into sub directories for each terraform provider and split into different terraform modules. There are also some abstracted _genericmodules

./ha-sap-terraform-deployments
├── aws
│    └── modules
├── azure
│    └── modules
├── generic_modules
│    └── ...
├── gcp
│    └── modules
├── libvirt
│    └── modules
├── openstack
│    └── modules
…

This makes the code modular and more maintainable.

Salt configures all virtual machine instances that are provisioned by terraform. This includes configuring the operating system, mounting filesystems, installing SAP software, installing HA components. It does so by using pillars and grains which are injected by terraform in a flexible and customizable way.

./ha-sap-terraform-deployments
├── pillar_examples
│    └── automatic
│        └── drbd
│        └── hana
│        └── netweaver
├── salt
│    └── bastion
│    └── cluster_node
│    └── ...
…

Terraform will first build up the infrastructure/machines and salt will do the actual provisioning.

Under the hood, shaptools🔗 and salt-shaptools🔗 are used, to have a stable API to access SAP HANA and Netweaver functionalities.

The whole architecture stack can be seen here:

This repository is intended to be configured and run from a local workstation, but should also be runnable from your cloud provider's cloud shell.

Each provider folder has it own provider relevant documentation, modules and example configuration. Be sure to get familiar with these before trying this out.

Getting started

The SAP software media has to be available and prepared according to Preparing SAP software.

After you prepared the SAP software, make sure to have terraform and salt installed. Clone this repository and follow the quickstart guides of the favored provider. They can be found in ./<provider>/README.md or linked below:

• Amazon Web Services (AWS) (pdf guide SUSE SAP automation guide AWS🔗)
• Microsoft Azure (pdf guide SUSE SAP automation guide Azure🔗)
• Google Cloud Platform (GCP) (pdf guide SUSE SAP automation guide GCP🔗)
• OpenStack
• libvirt/KVM

The SUSE SAP automation guides contain a lot more detailed explanations than the short quick start guides.

Each provider folder contains a minimal working configuration example terraform.tfvars.example.

Please be careful which instance type you will use! The selection of systems certified by SAP could lead to expensive unexpected costs.

Troubleshooting

In case you have some issue, take a look at this troubleshooting guide.