Skip to content
Branch: master
Find file History
pabowers upgrading to Terraform 0.12 (#161)
* upgrading to Terraform 0.12

* Updating the README

* Adding upper bound on Terraform version lock
Latest commit a5921b1 Jun 19, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information. Fixed bastion flag documentation (#142) Feb 20, 2019 upgrading to Terraform 0.12 (#161) Jun 19, 2019 upgrading to Terraform 0.12 (#161) Jun 19, 2019
terraform.tfvars.template fixing template for tfvars (#136) Feb 5, 2019

HANA high-availability pair

This scenario deploys a single-node HANA instance in two sites (primary and secondary), replicated on database level via HANA System Replication (HSR). This scenario is known as "high-availability pair" or "HA pair."

Landscape Diagram

Table of contents


  • This scenario already configures all resources required for the Pacemaker HA cluster, including:
    • STONITH by device (SBD), via iSCSI target server
    • SAPHanaSR and SAPHanaTopology Pacemaker resource agents (to facilitate HSR failover)
    • azure-events Pacemaker resource agent (to anticipate scheduled maintenance events and trigger graceful failover)
  • In this design, the SBD device uses a iSCSI target server on an additional VM; while this is optional, it allows for faster failover. For more details, please refer to the reference architecture of high-availability VM landscapes using Pacemaker on SuSE Linux Enterprise Server (SLES).
  • At present, this HANA high-availability scenario is only supported for Azure VM deployments using SuSE Linux Enterprise Server (SLES) 12.3 or higher.
  • For additional details on the underlying implementation, please see the documentation of the reference architecture.
  • If you don't have a high-availability requirement, you can just deploy the HANA single-node scenario.


The following options can be customized in the single-node scenario:

Option Description Template parameter
HANA version Which version of HDB Server to install
HANA 1.0 SPS12 (PL13 or higher) useHana2 = false
HANA 2.0 SPS2 or higher useHana2 = true
Database containers * Whether to install HDB with single or multiple database containers (tenants)
Single container (HANA 1.0 only) hdb_mdc = false
Multi-database containers (MDC) hdb_mdc = true
Bastion host * Whether to deploy a bastion host ("jump box") through which the HANA VM can be accessed
No bastion host windows_bastion = false
linux_bastion = false
Windows bastion host (incl. HANA Studio) windows_bastion = true
Linux bastion host (incl. HANA Studio) linux_bastion = true
SAP Applications Which SAP applications to install on top of HANA (if any)
XSA install_xsa = true
SAP HANA Cockpit (requires XSA) install_cockpit = true
SHINE Demo Content (requires XSA) install_shine = true
WebIDE (requires XSA) install_webide = true

(Note: Features marked with an * are work in progress and not fully available yet.)


  1. If you haven't already done so, please make sure you prepare your Azure Cloud Shell.

  2. Next, download the required SAP packages and make them accessible.

(Note: Please review the list of SAP downloads; depending on which features and applications you would like to include in your HANA installation, you may need additional packages.)

  1. In your Azure Cloud Shell, change into the directory for the HANA high-availability pair:

    cd sap-hana/deploy/vm/modules/ha_pair/
  2. Create a terraform.tfvars file for your deployment. You can use the provided Boilerplate template for high-availability pair scenarios as a starting point and adjust the variables according to your requirements.

(Note: You need to rename the boilerplate template from terraform.tfvars.template to terraform.tfvars before you can use it.)

  1. Now, run the deployment of your HANA high-availability pair instance. You can verify the installation afterwards.

  2. Should you wish to delete your HANA high-availability pair at a later point, you can simply follow the general instructions on the overview page.

You can’t perform that action at this time.