# Automated SAP installation Deploying an SAP system requires significant effort in building an infrastructure that conforms to SAP specifications. Installation, operating system configuration, and configuration of parameters based on the type of SAP workload must be repeated for the development, quality, and production landscape. You can automate this installation and configuration using AWS Systems Manager. Automating the installation and configuration of your SAP landscape helps your team stay compliant with auditable policies related to configuration as code. In addition, it turns the SAP installation into an easily repeatable process, which makes the quality of the outcome easier to improve because you can simulate it and run it multiple times using the same source of information. The solution described here uses Systems Manager documents to install a distributed SAP landscape that contains the following: + ABAP SAP Central Services (ASCS) + Database instance + Primary Application Server (PAS) + Additional Application Servers (AAS) # Automated SAP installation architecture The example architecture shown in the diagram below uses a centralized AWS account that stores the AWS Systems Manager document (SSM document). The document is shared with AWS accounts that host Amazon EC2 instances running SAP HANA workloads. ![\[The Systems Manager automation document connects to three child accounts.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/automation-installation-architecture.png) You can use multiple AWS accounts and AWS organizations to arrange the accounts into a hierarchy and group them into organizational units. These organizational units can be used for things such as consolidated billing, workload isolation, and administrative isolation. You can create separate AWS accounts for development, testing, staging, and production on a per-application basis as part of an organization. For more information, see the https://docs.aws.amazon.com/organizations/latest/userguide/orgs\$1introduction.html* AWS Organizations">User Guide*. Systems Manager automation provides multi-account and multi-AWS Region support that allows you to execute your own automation documents across multiple accounts from a central AWS account. You can centralize the SSM documents into a Shared Services account or use an automation account. The automation account can be the AWS account that runs SAP workloads or a dedicated account that only runs SSM documents. Using a centralized AWS for automation reduces administration overhead by maintaining the SSM document and its dependencies in a single account. For more information about Shared Services, see [Infrastructure OU - Shared Services account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/shared-services.html) in the * AWS Security Reference Architecture*. In order for Systems Manager to trigger automation documents from a centralized AWS account to the connected accounts, IAM permissions are required in the automation and child accounts. For more information, see [Running automations in multiple AWS Regions and accounts](https://docs.aws.amazon.com/systems-manager/latest/userguide/running-automations-multiple-accounts-regions.html) in the * AWS Systems Manager User Guide*. You can share SSM documents privately or publicly with accounts in the same Region. To privately share a document, modify the document permissions and allow specific individuals to access it based on their AWS account ID. For more information, see [Sharing SSM documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-sharing.html) in the * AWS Systems Manager User Guide*. ## Components The installation automation workflow includes automation runbooks and SSM command documents. **Automation runbook** An automation runbook defines the actions that Systems Manager performs on your managed instances and other AWS resources. A runbook contains one or more steps that run in sequential order. For more information, see the following documentation: + [What is an automation?](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html#what-is-an-automation) in the * AWS Systems Manager User Guide* + [Systems Manager Automation runbook reference](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html) **SSM command document** If a task must be repeated multiple times on multiple hosts, you can create it as an SSM command document. These documents are usable across multiple runbooks. For more information, see [Systems Manager Command document plugin reference](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html) in the * AWS Systems Manager User Guide*. You can make the SSM command document as granular as you need, based on factors such as: + Segregation of duties + Types of SAP systems that are being deployed + Complexity of SAP systems that are being deployed + Security **Workflow** As an example, each runbook can be made up of several SSM documents that perform a specific configuration. The following runbooks can be used, which are illustrated in the diagram below. + Bootstrap Amazon EC2 instances for SAP HANA database + Bootstrap Amazon EC2 instances for SAP application servers + Install SAP HANA database + Install ABAP SAP Central Services (ASCS) + Install a database instance + Install a primary application server + Install an additional application server ![\[Detailed flow chart of the SSM document.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/automation-flow.png) # Automated SAP NetWeaver on AWS installation prerequisites In addition to the prerequisites described in the [Automation prerequisites](sap-nw-automation.md#automation-prerequisites) section of this guide, verify the following prerequisites that are specific to automated SAP installation: + You must have an existing infrastructure deployed. The example described in this guide uses a SAP HANA database, an SAP Central Services (ASCS) instance, and a database instance. The * AWS for SAP* blog has a [Terraform your SAP Infrastructure on AWS](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/) example. + SAP media files must be available. You must provide the SAP installation media files, which are obtained from SAP, in an Amazon S3 bucket. For more information, see [Make SAP application software available for AWS Launch Wizard for SAP to deploy SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap-software-install-details.html) in the * AWS Launch Wizard User Guide*. If you use the sample code provided in this guide, the media files are copied to local Amazon Elastic Block Store volumes. **SAP Notes** Read the following SAP Note: + SAP Note: [2230669 - System Provisioning Using a Parameter Input File](https://me.sap.com/notes/2230669) **Additional references** Before you begin, you can also familiarize yourself with how SAP works on AWS by reading the following documentation: + [SAP on AWS Planning](https://docs.aws.amazon.com/sap/latest/general/overview-sap-planning.html) in the *General SAP Guides* + [Amazon EC2 instance types for SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/ec2-instance-types-sap.html) in the *General SAP Guides* + [SAP NetWeaver Environment Setup for Linux on AWS](https://docs.aws.amazon.com/sap/latest/sap-netweaver/std-sap-netweaver-environment-setup.html) in the *SAP NetWeaver Guides* # Configuring automated SAP installation The sections below contain detailed instructions on how to configure automated SAP NetWeaver on AWS installation. ## Customize the Systems Manager document This section shows you how to customize the AWS Systems Manager document (SSM document) for the automated SAP installation. For more information about SSM documents, see [AWS Systems Manager Documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html) in the * AWS Systems Manager User Guide*. This section details the content that goes into the SSM document. For information about how to create the document, see [Create an SSM document (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-ssm-console.html) in the * AWS Systems Manager User Guide*. As you create your SSM document, we recommend you do the following: + Use schema version 2.2. For more information, see [SSM document schema features and examples](https://docs.aws.amazon.com/systems-manager/latest/userguide/document-schemas-features.html) in the * AWS Systems Manager User Guide*. + Use Parameter Store to easily reference parameters that you use often. For more information, see [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) in the * AWS Systems Manager User Guide*. **Tip** You can find sample SSM documents and parameter files in the [aws-samples/terraform-aws-sap-netweaver-on-hana](https://github.com/aws-samples/terraform-aws-sap-netweaver-on-hana/tree/master/modules/sap-deploymentscripts/scripts/module-automations) GitHub repository. ### Bootstrap Amazon EC2 instances Bootstrapping in Amazon EC2 consists of adding commands or scripts to the user data section of the instance. These commands and scripts can be executed when the instance starts. This simplifies configuration tasks. For more information, see [Run commands on your Linux instance at launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) in the *Amazon Elastic Compute Cloud User Guide for Linux Instances*. For SAP installation, bootstrapping includes several tasks, such as setting the hostname, installing operating system packages, setting operating system parameters, installing AWS Data Provider for SAP, installing agents for monitoring, logging, and alerting, and mounting disks for the SAP HANA database instance and SAP application servers. The image below shows the steps required for the bootstrap instance SSM document. ![\[Detailed flow chart of the bootstrap instances SSM document.\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/automation-bootstrap.png) The SSM document accepts required and optional parameters. The code below is an example parameter section for bootstrapping an SAP HANA database instance or any SAP NetWeaver application server instance: ``` parameters: AutomationAssumeRole: type: String description: "(Optional) The ARN of the role that allows Automation to perform the actions on your behalf. " default: '' InstanceId: type: String description: "(Required) The instance ids to bootstrap before SAP HANA installation" default: '' HostnameTagKey: type: String description: "(Required) The tag key where the hostname is stored" default: 'Hostname' DnsPrivateZoneName: type: String description: "(Optional) DNS Zone name to specify FQDN in hosts" default: 'sapteam.net' EfsFileSystemId: type: String description: (Required) The EFS file system id for /sapmnt folder default: ‘fs-7df7edae’ MasterPassword: type: String description: '(Required) SAP NetWeaver Master Password' default: '' IniFile: type: String description: '(Required) Path to INI file' default: '/sapmnt/software/sapinstall.params' CloudWatchLogGroupName: type: String description: "(Required) Cloud Watch log group for the log output" default: '/customer/SAP/dev-setup-logs' ``` The next section of the SSM document is the `mainSteps` section. A composite SSM document is a custom document that performs a series of actions by running one or more secondary SSM documents. Composite documents promote infrastructure as code by allowing you to create a standard set of SSM documents for common tasks, such as bootstrapping software or domain-joining instances. For example, you can create a composite document with secondary SSM documents for each bootstrap item, as listed below: + Setting the hostname + Installing operating system packages for SAP HANA + Setting the operating system parameters for SAP HANA + Mounting disks for SAP HANA + Installing the AWS Data Provider agent for SAP Composite and secondary documents can be stored in Systems Manager, private and public GitHub repositories, or Amazon S3. They can be created in JSON or YAML. For more information, see [Creating composite documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/composite-docs.html) in the * AWS Systems Manager User Guide*. The code below shows the `mainSteps` section of the SSM document with the composite and secondary documents: ``` mainSteps: - name: Prepare_logs action: aws:runCommand inputs: DocumentName: d4h-prepare-sap-installation-logs InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Set_hostname action: aws:runCommand inputs: DocumentName: d4h-set-hostname InstanceIds: - '{{ InstanceId }}' Parameters: PrivateZone: '{{ DnsPrivateZoneName }}' Hostname: '{{ Get_hostname.Hostname }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Install_Packages action: aws:runCommand inputs: DocumentName: d4h-install-sap-packages InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Set_OS_Parameters action: aws:runCommand inputs: DocumentName: d4h-set-sap-hana-parameters InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Mount_Disks action: aws:runCommand inputs: DocumentName: d4h-mount-hana-disks InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True - name: Install_Aws_Sap_Data_Provider action: aws:runCommand isCritical: false inputs: DocumentName: d4h-install-sap-aws-data-provider InstanceIds: - '{{ InstanceId }}' CloudWatchOutputConfig: CloudWatchLogGroupName: '{{ CloudWatchLogGroupName }}' CloudWatchOutputEnabled: True ``` ### Install the SAP HANA database After you bootstrap the Amazon EC2 instances, you must install the SAP HANA database. For this installation, you can store the SAP HANA master password in the SSM document Parameter Store or use it as an input to the SSM document and reference it in the `passfile.xml` file. The code below is an example SSM document for an SAP HANA installation: ``` mainSteps: - action: "aws:runShellScript" name: "Run_installer" inputs: runCommand: - #!/bin/bash - HANA_MEDIA=`find /software/hana -name "DATA_UNITS"` - if [ -z "$HANA_MEDIA" ] - then - echo "Could not find the DATA_UNITS folder in /software/hana. Check if everything was downloaded successfully. Exiting..." | tee -a $SSM_LOG_FILE - exit 1 - fi - PASSFILE=$HANA_MEDIA/../passfile.xml - chmod +x $HANA_MEDIA/HDB_LCM_LINUX_X86_64/hdblcm - HOSTNAME=`(hostname)` - INSTANCE=`(instancenumber)` - SID=`echo "{{sid}}" | tr a-z A-Z` - echo "Executing installation from $HANA_MEDIA/HDB_LCM_LINUX_X86_64/hdblcm for SID $SID, instance $INSTANCE, hostname $HOSTNAME..." - cat $PASSFILE | $HANA_MEDIA/HDB_LCM_LINUX_X86_64/hdblcm --action=install --components=client,server --batch --autostart=1 -sid=$SID --hostname=$HOSTNAME --number=$INSTANCE --read_password_from_stdin=xml | tee -a $SSM_LOG_FILE - echo "`date` Installation finished. Please check logs..." | tee -a $SSM_LOG_FILE - rm $INIFILE ``` ### Install SAP Installing SAP includes ABAP SAP Central Services (ASCS), the database instance, and the primary and additional application server installation. First, you create a parameter file with the required parameters. Refer to the SAP installation guide for the parameters that are specific to your installation. The code below is an example parameter file: ``` mainSteps: - action: "aws:runShellScript" name: "Prepare_sapinstall_ini" inputs: runCommand: - #!/bin/bash - SAPINSTALL_INI_FILE={{ IniFile }} - SID=`echo "{{Sid}}" | tr a-z A-Z` - SAPSYSUID=`sapsysuid` - SIDADMUID=`sidadmuid` - SWTARGET=/sapmnt/software/ - DOMAINNAME={{ DnsPrivateZoneName }} - HOSTNAME=`hostname` - FQDN=${LHOSTNAME}.${DOMAINNAME} - sed -i "s|default_scsVirtualHostname|${HOSTNAME}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_scsInstanceNumber|00|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_ssmpass|{{ MasterPassword }}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_sid|${SID}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_fqdn|${DOMAINNAME}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_sapsysGID|${SAPSYSUID}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_AdmUID|${SIDADMUID}|g" ${SAPINSTALL_INI_FILE} - sed -i "s|default_downloadBasket|${SWTARGET}|g" ${SAPINSTALL_INI_FILE} - echo '`date` Prepared the Ini File:...' | tee -a $SSM_LOG_FILE ``` The next step is to start the installation using the SAP silent, or unattended, installation mode, referring to the parameter file as in the example code below: ``` mainSteps: - action: "aws:runShellScript" name: "Execute_installation" inputs: runCommand: - #!/bin/bash - echo '`date` Starting the Installation process...' | tee -a $ - SYSTEMNUMBER=`systemnumber` - SAPAliasName=`hostname` - SWPMFILE=`find /sapmnt/software/SWPM-SUM/ -name SWPM*SAR` - chmod 775 /sapmnt/software/utils/sapcar - /sapmnt/software/utils/sapcar -xvf $SWPMFILE -R /sapmnt/software/SWPM - chmod 755 /sapmnt/software/SWPM/sapinst - cd /sapmnt/software/SWPM - ./sapinst SAPINST_INPUT_PARAMETERS_URL=/sapmnt/software/sapinstall.params SAPINST_EXECUTE_PRODUCT_ID={{ProductId}} SAPINST_USE_HOSTNAME=${SAPAliasName} SAPINST_SKIP_DIALOGS="true" SAPINST_START_GUISERVER=false | tee -a $SSM_LOG_FILE ``` You can add additional sections in the SSM document to validate the SAP installation by checking the SAP process running on the host and sending the results to the SSM document log file. The following code is an example of how to do this: ``` - action: "aws:runShellScript" name: "Validate_Installation" inputs: runCommand: - #!/bin/bash - sid=`echo {{ Sid }} | tr '[:upper:]' '[:lower:]'}` - SID=`echo {{ Sid }} | tr '[:lower:]' '[:upper:]'}` - HOSTNAME=`hostname` - SIDADM=${sid}adm - su - $SIDADM -c "stopsap $HOSTNAME" | tee -a $SSM_LOG_FILE - su - $SIDADM -c "startsap $HOSTNAME" | tee -a $SSM_LOG_FILE - sleep 15 - _SAP_UP=$(netstat -an | grep 3200 | grep tcp | grep LISTEN | wc -l ) - echo "This is the value of SAP_UP - $_SAP_UP" | tee -a $SSM_LOG_FILE - if [ "$_SAP_UP" -eq 1 ] - then - echo "$(date) __ done installing ASCS." | tee -a $SSM_LOG_FILE - exit 0 - else - echo "$(date) __ ASCS could not be installed successfully. Fix the issue and rerun the automation" | tee -a $SSM_LOG_FILE - exit 1 - fi - action: "aws:runShellScript" name: "Save_services_file" inputs: runCommand: - #!/bin/bash - grep -i sap /etc/services > /sapmnt/services - if [ -s /sapmnt/services ] - then - echo "Services file copied to sapmnt" | tee -a $SSM_LOG_FILE - exit 0 - else - echo "Services file could not be copied" | tee -a $SSM_LOG_FILE - exit 1 - fi ``` ## Tag the Systems Manager document A tag is a label that you assign to an AWS resource. Each tag consists of a key and a value, both of which you define. For an overview of tagging Systems Manager resources, see [Tagging Systems Manager resources](https://docs.aws.amazon.com/systems-manager/latest/userguide/tagging-resources.html) in the * AWS Systems Manager User Guide*. For detailed instructions on how to tag SSM documents, see [Tagging Systems Manager documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/tagging-documents.html) in the * AWS Systems Manager User Guide*. **Example - tags and access management** You can use tagging for a variety of purposes. For example, if you’re using AWS Identity and Access Management (IAM), you can control which users in your account can create, edit, or delete tags, and you can implement attribute-based access control (ABAC). For more information, see [Grant permission to tag resources during creation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/supported-iam-actions-tagging.html) and [Control access to Amazon EC2 resources using resource tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/control-access-with-tags.html) in the *Amazon Elastic Compute Cloud User Guide for Linux Instances*. **Example - tags and billing** You can use tags to organize your AWS bill in a way that reflects your cost structure. To do this, sign up to get your AWS account bill with tag key values included. For more information about setting up a cost allocation report with tags, see [Monthly cost allocation report](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html) in the * AWS Billing User Guide*. To see the cost of your combined resources, you can organize your billing information based on resources that have the same tag key values. For example, you can tag several resources with a specific application name, and then organize your billing information to see the total cost of that application across several services. For more information, see [Using cost allocation tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) in the * AWS Billing User Guide*.