AWS for SAP

Automating SAP HANA Installations on AWS with DevOps

Introduction

In our first blog, Terraform your SAP Infrastructure on AWS, we began the SAP on AWS DevOps journey by defining the SAP infrastructure as code (IaC) .

By doing this, we demonstrated with our Terraform modules here on GitHub and here on the Terraform Registry, by defining SAP as code, infrastructure and servers can quickly be deployed using standardized patterns, updated with the latest patches/versions, and duplicated in repeatable ways to overcome some of the initial learning curve hurdles.

Another option to deploy is AWS Launch Wizard. Customer teams can build SAP systems that align with AWS best practices rapidly from the AWS Console following a guided experience designed for SAP administrators.

In the pursuit of lowering cost and increasing deployment efficiency, customers are looking to automate as many processes as they can. Customers want to further expand their capabilities by layering on the necessary software needed to run SAP on the previously defined infrastructure.

Following SAP installation logic, HANA is the next installation step that we would want to automate enabling a seamless deployment of the underlying infrastructure as well as the automation of the HANA installation.

To help customers on this journey, we are open sourcing the capability to build and configure SAP HANA here. Allowing customers to define their infrastructure using Terraform by following our above blog, you can layer on this new capability and automate the deployment of SAP HANA on AWS end-to-end all using DevOps tools and methodologies.

Applying this crawl, walk, run approach, enables customers to gain the skills they need and at the same time, we are accelerating it with the resources covered in this blog to deliver an SAP on AWS solution using DevOps tools and methodologies.

 

Using Terraform to deploy your automation tools

As with any EC2 or server-based application, you are going to want to adjust and tweak a few things at the operating system level not only to prepare it for your application or database but also to go a step further and automate the actual installation of SAP HANA. This element of DevOps is called Configuration Management or what is sometimes abbreviated as CM.

To tie back to what we discussed in our first blog, IaC or Infrastructure as Code is an approach where we used Terraform as a declarative language to define our infrastructure. Once done, we need a way to control mutable elements like an operating system or say a Linux kernel parameter especially for a monolithic application like SAP that doesn’t follow the immutable infrastructure model.

For more information on this topic see this article called What is Mutable vs. Immutable Infrastructure? SAP resources fall into the “We’re going to mutate it, modify it in place, to get into this new configuration.” area of discussion.

Making these types of changes is something that IaC tools are capable of but typically only do at resource instantiation. Often they aren’t the best tools to manage resources over their lifetime. That’s where CM comes in and why we chose to deploy our CM configuration using Terraform. IaC and CM have similar goals but differ in their approach. In the end, they pair nicely when deploying SAP on AWS.

With IaC owning the infrastructure deployment and Configuration Management installing the SAP components, CM is in a better position to pick up where IaC leaves off. Let’s move onto how we use CM to prepare and install.

Configuration Management for our SAP HANA installation delivers value by allowing developers and administrators to control settings and values within resources over the lifetime of their operation. CM in this case enables us to prepare our OS, install our database, and run any other commands that may be needed. We will document how to use AWS Systems Manager as a CM tool to install SAP HANA.

Leveraging SSM to install SAP HANA

An AWS Systems Manager document defines the actions performed on your managed instances. Systems Manager includes more than 100 pre-configured documents that you can use by specifying parameters at runtime. Documents use JavaScript Object Notation (JSON) or YAML, and they include steps and parameters that you specify.

In this blog, we deliver documents that allow us to define and code the exact steps needed to prepare a HANA EC2 instance, install HANA, and run any post configuration needed.

And before you think, “Oh, another tool I have to learn”, our approach to deploying these automations doesn’t change once we move into the Configuration Management layer of automation. We automate the automations .

We package our HANA automated install AWS Systems Manager documents in Terraform so we can leverage predefined parameters used by your previous infrastructure deployment and have the AWS Systems Manager documents inherit these definitions and logic. No need to reinvent the wheel.

We continue to automate within the previous automation lowering your development effort and mitigating incorrect settings. Terraform not only takes care of your parameters for you going forward with your installs, but it also deploys these documents to your AWS account seamlessly. For instance, the SID you set with Terraform cascades to all your installations and scripts that you need to run with SSM. Set it and forget it.

Now let’s dive into how AWS Systems Manager installs HANA.

AWS Systems Manager documents are defined in Terraform as resources and are deployed to AWS Systems Manager fully customized to your solution.

This solution deploys one master AWS Systems Manager document that contains child documents with dependencies baked in making it easier to maintain and deploy while following SAP standards. These documents then follow the below high-level sequence:

  • Set parameters
    • Sets OS parameters, roles, passwords, media location, SID, etc.
  • Mount disks
    • Mount, stripe, format, and prepare `/hana/data`, `/hana/log`, `/hana/shared`, `/usr/sap`, `/backup/`, and swap.
  • Download software
    • Copy media from S3 to the HANA EC2 and prepares it for installation
  • Execute install
    • Pass all parameters to `hdblcm` and execute the HANA install
  • Finalize installation
    • Setting basepath directories, adjusting `global.ini` and `daemon.ini` settings, and adjusting `hdbnsutil`.

By taking a modular approach, users can automate the trigger of the document executions or run them via the console while still adhering to the constructs of CI/CD and the DevOps methodology. This also gives Basis admins a tangible method to run these automations in the console. If executions fail or need to be adjusted, simply re-run the failed child document after deploying the necessary fixes and continue your deployment where you left off.

By packaging the documents in Terraform and executing the install with AWS Systems Manager, we enable IaC to control and deploy the correct documents while CM gives users a repeatable and consistent way to install. The best of both worlds.

Next steps

Applying a crawl, walk, run approach, has enabled us to gain the skills needed to not only deploy SAP infrastructure but also automate the installation of HANA.

Ready to get started? Find everything we mentioned above here in our Github repo.

Feel free to fork the repo and adapt our AWS System Manager documents for Chef, Puppet, Ansible, etc.

We would love to see all the ways you can use Configuration Management to automation your HANA installs. Maybe even go further and adopt this approach for your application servers, web dispatchers, central services, and so on!

If you are looking for expert guidance and project support as you move your SAP systems to a DevOps model, the AWS Professional Services Global SAP Specialty Practice can help. Increasingly, SAP on AWS customers—including CHS and Phillips 66—are investing in engagements with our team to accelerate their SAP transformation. If you are interested in learning more about how we may be able to help, please contact us here.