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 workloads on AWS platform.
AWS Launch Wizard is available at no additional cost,
and post-deployment, we will test failover of SAP HANA database
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 the workloads.
We will be deploying these instances
in two private subnets in availability zones A and B.
After Launch Wizard deployment is finished,
we would see the SAP S/4HANA application as shown here.
The ASCS and ERS 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 followed by HANA database backup,
which is a pre-requisite for HANA database replication setup.
Once that is done, cluster configuration of HANA is performed.
Then, the application is deployed,
and finally the cluster configuration of the 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 on create deployment.
This screen provides information about the IAM role
that lets 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've 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,
and optionally, you can provide a description
and any number of tags you need, such as cost center information.
You can have unique configurations for your production
and non-production environments.
The configuration I selected populates all the network parameters,
such as VPCs, subnets, and security groups.
You can also define encryption requirement
for all the block storage and select the appropriate options here.
Once the parameters are reviewed, click next.
As we're deploying both application and database,
let's leave the selection here as NetWeaver stack on HANA.
Provide a system ID and a user ID for SAP S/4HANA,
and the EBS volume type is selected from the drop down.
Let's leave this with default value.
If you already have a transport domain,
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 ABAP central service.
I selected SuSE-Linux-15-For-SAP as the operating system.
If you want another operating system, you can select it from the drop down.
I have defined the unique host names and instance numbers
and provided the CPU and memory requirements here.
As you can notice, Launch Wizard also estimates
the monthly on-demand cost for this deployment.
Just follow the same steps for Enqueue Replication Server as well.
Then, we move to the DB section,
where we select a preferred operating system
and define the host name and site name for our primary
and standby database.
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 HANA instance is selected from the drop down.
Now, we define our requirement for primary application server.
We have more options to define additional application servers
and pre- and post-deployment scripts if required.
Once done, click next.
Let's leave the selection for the software installation as yes.
We chose S/4HANA as our application and version as 2020.
All the software is uploaded into 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 tag 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 the Launch Wizard.
At this point, 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:26 AM and finished 90 minutes later,
at 7:52-- a little under two hours.
Let's now proceed to database failover test.
Let me switch to a remote desktop
where I've set up the environment already.
Let's click on the deployment, Launch Wizard demo1,
and I can navigate to the deployed resources
from the Launch Wizard console.
We have HANA database that's running across two Availability Zones
in the Oregon region, and we have the ASCS/ERS nodes
running across Availability Zones 2A and 2B.
I've listed the IP addresses and roles of each system
on my SSH session for quick reference.
Let's also take a look at the HANA database
replication status in the HANA Studio.
We're connected to host 10.0.4.4,
and this IP belongs to primary database.
The replication status looks active, and we're all set for failover test.
In the failover test, I will simply stop the primary database host
while a bad job is in motion at the application tier,
and we will see how quickly the database has failed over
and what impact it has on the bad job.
To measure the failover time, we will simply use a stopwatch.
We have an open SSH connection to the application server host,
and we're using an SAP command to establish connection to the database.
When the database is failing over across Availability Zones,
we will notice that the connection is briefly lost and re-established.
We have a second session to primary database
host displaying HANA processes.
We have another session here to monitor the cluster status.
The cluster status shows the number of online hosts,
all the cluster resources, and the primary and the standby nodes.
Now, let's create a bad job on the application.
For this test, I'm going to use SGEN TCode to trigger a bad job.
Now that the bad job is created, let's monitor the job status.
As you can see, the bad job is running.
Now, it's time to stop the primary database from AWS Console
and start my stopwatch.
My session to the primary database host is now terminated,
as we stopped the host, and this is an expected behavior.
My application connection to the database is now disconnected.
This connection should re-establish briefly.
In my cluster, one of the hosts is now offline,
and the resources are now failing over to secondary HANA host.
My application is now reconnected to the database,
so let me stop the clock here.
The secondary HANA host should now be promoted as the new primary.
So, the connection is re-established,
and the resources are failed over to healthy node.
It took less than 60 seconds for the failover to finish.
Now let's take a look at the bad job, and as you can notice,
the job is still running uninterrupted
while the database failed over across Availability Zones.
To summarize, in this test, we failed over a database
while a bad job was actively running.
The failover took less than a minute and was fully orchestrated
via a third-party clustering software.
The inflight batch operation did not fail,
and the user session was uninterrupted.
I hope this demo was helpful in understanding
how the clustered environments behave on AWS
and how seamless it is to build highly available
application architectures
using AWS Availability Zones, and AWS Launch Wizard tool.
If you're interested in watching a demo of application failover test,
you can find a link in the description of this video.
Thank you.