This blog post series is based on a proof of concept to demonstrate how easy it is to connect SAP Application Servers to a Network Load Balancer, which also has a connection to an AWS AutoScaling Group to use the elastic feature of the cloud. With the help of this architecture, it is possible to scale in and out based on scaling policies in multiple availability zones (AZ). In this first part we set up the SAP landscape in AWS.
Figure 1: High Level Architecture Design
We need two main providers for this proof of concept, namely SAP and AWS. Luckily, the mentioned two providers already have more than 12 years of partnership and more than 5,000 customers worldwide, who are running SAP workloads in the cloud (source: https://aws.amazon.com/sap/). Let’s utilize the best from both worlds, the ERP system management capabilities of SAP and the scalability of AWS.
And more luckily, you only need one online repository of latest, pre-configured SAP solutions that can be instantly consumed in the cloud tool to set up the SAP landscape, the SAP Cloud Appliance Library (CAL). With it we will also allocate the necessary infrastructure running on AWS. Have you ever heard about SAP CAL? It is worth to have a try. It is free of charge (you only pay for the AWS resources). SAP CAL allows you to try out SAP landscapes for business validation, test and demo, development, proof of concept, training and evaluation as well as production deployment. You can find more information about it in the general FAQ section of SAP CAL. It supports all the three big cloud providers, however, in this post the focus will be on Amazon Web Services.
In the first part of the series, the goal is to set up the SAP landscape with the help of SAP Cloud Appliance Library. The following architecture shows, how the the setup will look like at the end of the first part.
Figure 2: Add AWS Account to SAP Cloud Appliance Library
After registering to SAP CAL, an AWS account’s details have to be provided. This contains the IAM users’ access key and secret access key in the target AWS account. For more information about how to create the necessary keys for an IAM user, please refer to the official AWS documentation. Important is to mention that the following IAM Policies are needed to be attached to the IAM user:
In case the policies are missing, the deployment will fail. You can find more details about that in the official FAQ document.
Figure 3: AWS Account in Active Status
If everything went well, the following entry should be under Accounts:
Figure 4: SAP NetWeaver AS ABAP 7.51 SP02 on HANA
As next step, we choose the target SAP solution. In our case it is SAP NetWeaver AS ABAP 7.51 SP02 on HANA:
Figure 5: Cost Calculator
Clicking on Calculate Cost you’ll receive an information about the cost of your solution.
This demo contains the following cost elements:
Figure 6: Activated SAP Solution
The only limitation in this case is the region. The solution can only be deployed in Northern Virgina (us-east-1). As figure 5 shows this solution contains two EC2 instances, one for the SAP frontend (this contains a pre-installed and pre-configured SAP GUI) and a high performance r4 instance for the SAP backend (SAP Application Server on SAP HANA Database).
The following components will be installed on the virtual machines:
More details about the landscape in the official Getting Started document.
After it has been decided that the SAP solution fits to our needs, start the deployment by clicking on the Create Instance button in the right upper corner. SAP shows the terms and conditions before the deployment starts. As usual you can accept it by clicking on the I accept button. Furthermore we have to choose an existing AWS account (which has been registered before) . SAP CAL as well asks about the name of the stack, region (only us-east-1 for SAP NetWeaver AS ABAP 7.51 SP02 on HANA, Developer Edition) and a password. The password will be used for:
After clicking on Create, the stack with a Windows 2012 R2 Server instance for SAP Frontend and a SUSE Linux Enterprise Server 12 SP 3 instance for SAP Backend will be created. That’s all, if we choose basic mode. Creation can can take up to 30 minutes.
For sure, it is possible to optimize the stack using advanced mode, like deploying to an existing Virtual Private Cloud (VPC) and subnet within AWS. It is also possible to select different EC2 instance types and change the storage sizes of the Elastic Block Storage (EBS) volumes. SAP as well gives you the opportunity to change the inbound rules of the security groups used by the instances.
After a successful deployment, the status changes to Active. This means, your SAP landscape is ready to be used.
Figure 7: AWS EC2 console
Let’s control that at the AWS Management Console. Our EC2 Dashboard should contain two new virtual machines. Et voilà:
With SAP Cloud Appliance Library (CAL) you can suspend the landscape anytime, if you don’t need it at the moment. In the SAP CAL console, by clicking on Suspend, both instances will be stopped (not terminated). With this, it is possible to save money, if the trial is not in use. Costs don’t go to zero – as you can see in the cost example above also suspended instances will lead to costs. If the landscape is not used for days, it is worth to terminate it, so that even costs during suspend status are also eliminated. The SAP solution can be deployed again any time.
“And next week you’ll see ...” – just like in some TV series, this concluding section is about to provide a short introduction about what will happen in part 2. In our second part we will give our SAP landscape a better enterprise fit by preparing it for being part of an autoscaling group. A custom shell script will be created, which will do the trick, magic will happen.
