Hello, everyone.
This is Wilson Puvvula, and I'm a Solution Architect at AWS.
In this video, we will deploy SAP S/4HANA application
in a highly available cluster across AWS Availability Zones
using AWS Launch Wizard.
AWS Launch Wizard provides a wizard-based experience
to size, deploy, and configure HANA-based SAP workloads on AWS.
AWS Launch Wizard is available at no additional cost.
Post-deployment, we will test failover of SAP application
using third-party clustering software.
Before we initiate the deployment,
let's take a look at this slide to understand
how we will use AWS Availability Zones
to deploy this workload.
We will be deploying these workloads in two private subnets,
in availability Zone A and availability Zone B.
After the Launch Wizard deployment is finished,
we would see the S/4HANA application deployed, as shown here.
The ACS and ERS nodes will be deployed across availability zones,
and it will be clustered using a third-party software,
and the database is also deployed across availability zones
and clustered.
The route table is used for routing traffic to these subnets.
The sequence of steps for Launch Wizard are laid out here.
It starts with launching all the EC2 instances
and configuring the storage.
The installation of HANA database
is then followed by HANA database backup,
which is a prerequisite for HANA system replication setup.
Once that is done, cluster configuration of HANA is performed.
Then the applications are deployed, and finally,
the cluster configuration for application is carried out.
All of these steps are performed by Launch Wizard for SAP
in less than two hours.
Let's go to AWS console now and navigate to Launch Wizard.
Let's click on SAP and click create deployment.
This screen provides information about the IAM Role
that let's Launch Wizard create the resources on your behalf.
If you need more information, it's available here.
Let's click next.
To save time, I have already pre-populated all the fields
in another session.
So, let's switch to that screen and review the parameters.
I've named this deployment as Launch Wizard Demo 1,
and optionally, you can provide description
and any number of tags that you need, such as cost center information.
You can have unique configurations for your non-production
and production environments.
The configuration I selected populates all the network parameters,
such as VPC, subnets, and security groups.
You can also define encryption requirement
for all the block storage.
Once the parameters are reviewed, click next.
As we are deploying both application and database,
let's leave the selection here as NetWeaver stack on HANA,
provide a system ID and user ID for SAP S/4HANA,
and let's leave the EBS volume type as default.
If you already have a transport domain controller,
you can select it from the drop down.
Otherwise, leave the default option as Yes.
A unique system ID and system number are provided for the database,
and default EBS type GP2 will be used for this deployment.
Click next.
Since we are deploying a highly available S/4HANA solution,
we will select highly available deployment.
Then we provide the details for our ABAP central services.
I selected SuSE-Linux-15-For-SAP as the operating system.
If you want any other operating system,
you can select it from the drop down.
I have defined unique host names and instance numbers
and provided CPU and memory requirements.
As you can notice, Launch Wizard also estimates
the monthly on-demand cost for this deployment.
Follow the same steps for Enqueue Replication Server as well.
Then we move to the DB section
where we select the preferred operating system,
define hostname and site name for our primary and standby databases.
A unique overlay IP and the cluster pacemaker tag is provided.
This overlay IP will be used to send traffic
to the active primary instance.
Then the size of the HANA instance is selected from the drop down.
Now, we define our requirement for primary application server.
We have more options here to define additional application server
and pre- and post-deployment scripts, if required.
Let's click next.
Let's leave the selection for software installation as Yes.
We chose S/4HANA as our application and version as 2020.
All the software is already uploaded to S3 bucket,
and path is provided here.
A master password and system number for primary
application server are provided.
All virtual host names and overlay
IPs for ASCS and ERS are defined here,
and finally, the virtual host name for the database
and pacemaker tags for the application are provided.
If you need Backint Agent installed and configured for backing up
your HANA database to S3, then you can select the option here.
Now, let's hit next to review all the parameters
we provided to Launch Wizard.
If you need to make any changes, you can use the edit option here.
When you're ready, click deploy.
I paused the recording for the deployment to finish.
Now that the deployment is finished, let's take a look at the logs.
You can see the timelines here.
The deployment began at 6:26AM and finished 90 minutes later,
at 7:52, a little under two hours.
Let's now proceed with application failover testing.
Let me switch to a remote desktop here,
where I have set up the environment already.
Let's click on the deployment Launch Wizard Demo 1,
and I can navigate to the deployed resources from Launch Wizard console.
Let's take a look at the deployed resources here.
We have cluster nodes for ASCS and ERS running across availability
Zone A and B.
The databases are running across availability zones as well.
I've already created an entry for HANA database in my HANA studio.
Both my primary and standby databases are running,
and the replication is active.
The IP address of the database
matches with our Launch Wizard deployment.
I’ve also opened an SSH session to ASCS and ERS host,
and the IP addresses match the Launch Wizard deployment.
In this failover test,
I will simply enforce a migration of ACS process to ERS host,
while a user profile is being edited on SAP application server.
We will see how user log is preserved and session integrity
is maintained as the application server fails over.
The sessions here are displaying active processes in the cluster.
You can see the ASCS and ERS services are running across two hosts.
Now, let's open an SAP session
and go to transaction su01 to modify user profile.
Let me make a change here.
Now, let's go to SM12 Tcode
and confirm a lock is active on the table.
As you can see, a lock is active.
Now, let me simply shut down ASCS host
so that the ASCS processes failover to ERS host,
and let's start a stopwatch.
You will notice that the ACS service
will now move to the same host as ERS.
You can see the services are now moving over,
and they should become active in a moment.
The services are now active.
Now, let's stop the stopwatch,
and it only took about 42 seconds for the failover to finish.
Let's take a look at our session and see if a lock is still active.
You can see the lock is available.
Now, let's try to save our change in su01 and see what happens.
The user data is saved and committed.
To summarize, in this video, we've walked through
a Launch Wizard deployment of an S/4HANA application,
and then we failed over an ASCS host
while user information was being edited in su01.
The failover took less than a minute
and was fully orchestrated via a clustering software.
I hope this video was helpful in understanding
how the cluster environments behave on AWS
and how seamless it is to build highly available
application architectures using AWS Launch Wizard service.
Thank you.