Skip to content

lpalovsky/ha-sap-terraform-deployments

 
 

Repository files navigation

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

Build Status🔗

Supported terraform version 1.1.X


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

Project Components

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:

Products

This repository supports deployment with following products:

Vendor Product
SUSE SUSE Linux Enterprise Server for SAP Applications 12 SP5
Certification: SLES for SAP🔗 and SAP Process Automation🔗
SUSE SUSE Linux Enterprise Server for SAP Applications 15 SP4 (or older)
Certification: SLES for SAP🔗 and SAP Process Automation🔗
SAP SAP HANA 2.0 with SPS >= 02
SAP SAP NETWEAVER 7.5 (and later)
SAP SAP S/4HANA 1610
SAP SAP S/4HANA 1709
SAP SAP S/4HANA 1809
SAP SAP S/4HANA 1909
SAP SAP S/4HANA 2020
SAP SAP S/4HANA 2021

Cloud Providers

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

Vendor Product Certification
Amazon Amazon Web Services (AWS) SAP Hardware Directory for AWS🔗
Microsoft Azure SAP Hardware Directory for Azure🔗
Google Google Cloud Platform (GCP) SAP Hardware Directory for GCP🔗
OpenInfra OpenStack Depends on deployed hardware,
get an overview in SAP's Hardware Directory🔗
libvirt.org Libvirt not certified

Features

The following features are implemented:

Feature AWS Azure GCP OpenStack Libvirt
SUSE saptune / SAP sapnotes
SUSE's saptune is applied with the correct solution template to configure the systems based on SAP sapnotes recommendations.
For additional information see Tuning Systems with saptune🔗.
HANA single node
Deployment of HANA on a single node.
For additional information see SAP Hardware Directory for AWS🔗
HANA Scale-Up - performance optimized
Deployment of HANA with system replication in a performance optimized setup.
For addition information see SAP HANA System Replication Scale-Up - Performance Optimized Scenario🔗.
HANA Scale-Up - cost optimized
Deployment of HANA with system replication in a cost optimized (additional tenant DB) setup.
For additional information see SAP HANA System Replication Scale-Up - Cost Optimized Scenario🔗.
HANA Scale-Out - performance optimized
Deployment of HANA Scale-Out (multi node) with system replication in a performance optimized setup.
For additional information see SAP HANA System Replication Scale-Out - Performance Optimized Scenario🔗 and SAP HANA System Replication Scale-Out High Availability in Amazon Web Services🔗.
HANA Scale-Out - with standby nodes (HANA Host-Auto-Failover)
Deployment of HANA Scale-Out (multi node) with system replication and Host-Auto-Failover via standby nodes.
For additional information see Setting Up Host Auto-Failover🔗 and Azure: Deploy a SAP HANA scale-out system with standby node on Azure VMs by using Azure NetApp Files on SUSE Linux Enterprise Server🔗.
🚫 🚫
SAP S/4HANA ENSA 1
Deployment of a SAP S/4HANA in Enqueue Replication (ENSA) 1 scenario.
For additional information see SAP NetWeaver Enqueue Replication 1 High Availability Cluster - Setup Guide for SAP NetWeaver 7.40 and 7.50 🔗.
SAP S/4HANA ENSA 2
Deployment of a S/4HANA in Enqueue Replication (ENSA) 2 scenario.
For additional information see SAP S/4HANA - Enqueue Replication 2 High Availability Cluster - Setup Guide 🔗.
SAP S/4HANA single PAS
Deployment of a single S/4HANA PAS (primary instance).
For additional information see SAP S/4HANA - Enqueue Replication 2 High Availability Cluster - Setup Guide 🔗.
SAP S/4HANA High Availability Cluster
Deployment of a full SAP S/4HANA stack including ASCS, ERS, PAS and AAS (multiple) instances.
For additional information see SAP S/4HANA - Enqueue Replication 2 High Availability Cluster - Setup Guide 🔗.
Deployment in different Availability Zones/Sets
Deployment of virtual instances in different Availability Zones/Sets for HA on hardware level.

Legend:

Symbol Explanation
feature implemented in this repository
not implemented in this repository
🚫 not recommended by vendor

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 generic_modules

./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:

Architecture

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

SUSE/SAP HA automation project

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:

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.

About

Automated SAP/HA Deployments in Public/Private Clouds

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • HCL 84.9%
  • SaltStack 12.3%
  • Shell 1.1%
  • Jinja 0.6%
  • Makefile 0.5%
  • XSLT 0.4%
  • Smarty 0.2%