SAP Deployment Automation Framework
SAP Deployment Automation Framework is an open-source orchestration tool that can deploy, install, and maintain SAP environments. You can deploy the systems on any of the SAP-supported operating system versions and into any Azure region. You can create infrastructure for SAP landscapes based on SAP HANA and NetWeaver with AnyDB by using Terraform. The environments can be configured using Ansible.
Terraform from Hashicorp is an open-source tool for provisioning and managing cloud infrastructure.
Ansible is an open-source platform by Red Hat that automates cloud provisioning, configuration management, and application deployments. When you use Ansible, you can automate deployment and configuration of resources in your environment.
The automation framework has two main components:
- Deployment infrastructure (control plane, typically deployed in the hub)
- SAP infrastructure (SAP workload zone, typically deployed in a spoke.)
The dependency between the control plane and the application plane is illustrated in the following diagram. In a typical deployment, a single control plane is used to manage multiple SAP deployments.
You use the control plane of SAP Deployment Automation Framework to deploy the SAP infrastructure and the SAP application. The deployment uses Terraform templates to create the infrastructure as a service (IaaS)-defined infrastructure to host the SAP applications.
Note
This automation framework is based on Microsoft best practices and principles for SAP on Azure. To understand how to use certified virtual machines (VMs) and storage solutions for stability, reliability, and performance, see Get started with SAP automation framework on Azure.
This automation framework also follows the Microsoft Cloud Adoption Framework for Azure.
You can use the automation framework to deploy the following SAP architectures:
- Standalone: For this architecture, all the SAP roles are installed on a single server.
- Distributed: With this architecture, you can separate the database server and the application tier. The application tier can further be separated in two by having SAP central services on a VM and one or more application servers.
- Distributed (highly available): This architecture is similar to the distributed architecture. In this deployment, the database and/or SAP central services can both be configured by using a highly available configuration that uses two VMs, each with Pacemaker clusters.
About the control plane
The control plane houses the deployment infrastructure from which other environments are deployed. After the control plane is deployed, it rarely needs to be redeployed, if ever.
The control plane provides the following services:
- Deployment agents for running:
- Terraform deployment
- Ansible configuration
- Persistent storage for the Terraform state files
- Persistent storage for the downloaded SAP software
- Azure Key Vault for secure storage for deployment credentials
- Private DNS zone (optional)
- A Web application for configuration management
The control plane is typically a regional resource deployed into the hub subscription in a hub-and-spoke architecture.
The following diagram shows the key components of the control plane and the workload zone.
The application configuration is performed from the deployment agents in the control plane by using a set of predefined playbooks. These playbooks will:
- Configure base operating system settings.
- Configure SAP-specific operating system settings.
- Make the installation media available in the system.
- Install the SAP system components.
- Install the SAP database (SAP HANA and AnyDB).
- Configure high availability by using Pacemaker.
- Configure high availability for your SAP database.
For more information about how to configure and deploy the control plane, see Configure the control plane and Deploy the control plane.
Deployer VMs
These VMs are used to run the orchestration scripts that deploy the Azure resources by using Terraform. They're also Ansible controllers and are used to execute the Ansible playbooks on all the managed nodes, that is, the VMs of an SAP deployment.
About the SAP workload zone
The workload zone allows for partitioning of the SAP systems deployments into different environments, such as development, test, and production. The workload zone provides the shared resources (networking and credentials management) that are used by the SAP systems.
You would typically create a workload zone for each unique Azure Virtual network (VNet) that you want to deploy the SAP systems into.
The SAP workload zone provides the following services to the SAP systems:
- Virtual network
- Azure Key Vault for system credentials (VMs and SAP accounts)
- Shared storage (optional)
It is recommended to deploy the workload zone into a spoke subscription in a hub-and-spoke architecture and use a dedicated deployment credential for each workload zone.
For more information about how to configure and deploy the SAP workload zone, see Configure the workload zone and Deploy the SAP workload zone.
About the SAP systems
Each SAP system is deployed into a dedicated resource group and they use the services from the workload zone.
The SAP system deployment consists of the VMs and the associated resources required to run the SAP application, including the web, app, and database tiers.
For more information about how to configure and deploy the SAP system, see Configure the SAP system and Deploy the SAP system.
Software acquisition process
The framework also provides an Ansible playbook that can be used to download the software from SAP and persist it in the storage accounts in the control plane's SAP library resource group.
The software acquisition is using an SAP application manifest file that contains the list of SAP software to be downloaded. The manifest file is a YAML file that contains the:
- List of files to be downloaded.
- List of the product IDs for the SAP application components.
- Set of template files used to provide the parameters for the unattended installation.
The SAP software download playbook processes the manifest file and the dependent manifest files and downloads the SAP software from SAP by using the specified SAP user account. The software is downloaded to the SAP library storage account and is available for the installation process.
As part of the download process, the application manifest and the supporting templates are also persisted in the storage account. The application manifest and the dependent manifests are aggregated into a single manifest file that is used by the installation process.
Glossary
The following terms are important concepts for understanding the automation framework.
SAP concepts
Term | Description |
---|---|
System | An instance of an SAP application that contains the resources the application needs to run. Defined by a unique three-letter identifier, the SID. |
Landscape | A collection of systems in different environments within an SAP application. For example, SAP ERP Central Component (ECC), SAP customer relationship management (CRM), and SAP Business Warehouse (BW). |
Workload zone | Partitions the SAP applications to environments, such as nonproduction and production environments or development, quality assurance, and production environments. Provides shared resources, such as virtual networks and key vaults, to all systems within. |
The following diagram shows the relationships between SAP systems, workload zones (environments), and landscapes. In this example setup, the customer has three SAP landscapes: ECC, CRM, and BW. Each landscape contains three workload zones: production, quality assurance, and development. Each workload zone contains one or more systems.
Deployment components
Term | Description | Scope |
---|---|---|
Deployer | A VM that can execute Terraform and Ansible commands. | Region |
Library | Provides storage for the Terraform state files and the SAP installation media. | Region |
Workload zone | Contains the virtual network for the SAP systems and a key vault that holds the system credentials. | Workload zone |
System | The deployment unit for the SAP application (SID). Contains all infrastructure assets. | Workload zone |