AWS

A complete SAP Hybris system to support ecommerce is a robust yet complex set of systems comprising of a storefront and back office, media catalog and caching. This is a complex system with several steps that need to be taken with significant effort and time spent to deploy on premises. On AWS Cloud with the free service of AWS CloudFormation it is possible to do so in a few mouse clicks. This is part of CREATE BOOT aspect of Sonata’s Digital Platform Operation Model.

On cloud it is possible to create the entire environment as Infrastructure as Code by leveraging AWS CloudFormation. A user can create a template that describes the AWS resources they want, such as Amazon EC2 instances or Amazon RDS DB instances. CloudFormation will take care of provisioning and configuring the resources for you. This takes away the pain of needing to individually create and configure the resources or figure out what is dependent on what because the CloudFormation will take care of it all. The entire environment is described in a JSON text file called as a CloudFormation Template. This defines what AWS resources or non-AWS resources are required to run the specific application. The CloudFormation service uses the template file to creates the resources in the account and builds a running environment based on the template.

The infrastructure deployed would comprise of VPCs, subnets, security groups, internet gateways, EC2 instances and other infrastructure elements.

Our SAP Hybris customers deploy several fixes and customizations that need to be tested prior to deployment in production. In order to test this on premise would require costly hardware set aside for the sole purpose of running test environments. In AWS Cloud, with the help of Jenkins, Packer and CloudFormation a Hybris immutable deployment infrastructure is set up within a couple of hours and torn down quickly at the end of the test period with only an hourly price to pay for the consumption thus saving costs locked into hardware investments.

In order to stand up a staging or test environment, the CloudFormation template is initiated, the required application code packages are pulled from AWS CodeCommit, BitBucket or other code repositories, built with Maven on Jenkins and then deployed on the instances. After running the required tests, the user then navigates to the CloudFormation section on the AWS console and clicks the delete stack button, bringing down the entire environment in a couple of minutes. This could also be done from the command line leveraging the AWS API. This is unheard of in an on-premise environment.

The below represents the architecture design to launch SAP HANA instances from CloudFormation when needed as part of DR for the SAP HANA portion of the customer infrastructure

In order to ensure recovery of SAP HANA database one can use SAP HSR (SAP HANA System replication) or cluster options. There is a cost associated with this approach of maintaining a copy of the DB with an identical size either on premise or in cloud.

With a focus on low costs we would recommend one to go for a cloud native solution leveraging EC2 Auto Scaling and AWS EBS snapshots which would not be possible on premise. Cost Optimized approach is part of Sonata’s CREATE-BOOT aspect of the Digital Platform Operation Model.

The restore process leveraging auto scaling and EBS snapshots would work across availability zones in a region. Snapshots provide a fast backup process, independent of the database size. They are stored in Amazon S3 and replicated across Availability Zones automatically, meaning we can create a new volume out of a snapshot in another Availability Zone. In addition, Amazon EBS snapshots are incremental by default. Only the delta changes are stored since the last snapshot. To create a resilient high available architecture, automation is key. All steps to recover the database must be automated in case something fails.

EBS Snapshots

Prior to enabling EBS snapshots we must ensure the destination of log backups are written to an EFS folder which is available across availability zones.

We create a script for taking an EBS snapshot. In the script prior to the command to be executed for an EBS snapshot by using the system username and password we make an entry into the HANA backup catalog to ensure that the database is aware of the snapshot backup. We use the snapshot feature to take a point In time and crash consistent snapshot across multiple EBS volumes without a manual I/O freeze. It is recommended to take the snapshot every 8-12 hours.

Now the log backups are stored in EFS and full backups as EBS snapshots in S3 and both sets are available across AZs. Both storage locations can be accessed across AZs in a region and are independent of an AZ.

EC2 Auto Scaling

Next we create an auto scaling group with a minimum and maximum of one instance. In case of an issue with the instance, the auto scaling group will create an alternative instance out of the same AMI as the original instance.

We first create a golden AMI for the auto scaling group. The AMI is used in a launch configuration with the desired instance type. With a shell script in the user data, upon launch of the instance, new volumes are created out of the latest EBS snapshot and attached to the instance. We can use the EBS Fast snapshot restore feature to reduce the initialization time of the newly created volumes.

If the database was started now it would have a crash consistent state. In order to restore it to the latest state we can leverage the log backup stored in EFS which is automatically mounted by the AMI.

Care will need to be taken that the SAP application server is aware of the new IP of the restored SAP HANA database server.

Traditional on premises SAP environments require a long and arduous process of purchasing hardware, rack and stack, powering it u and then installing the required software, going through the configuration steps.

On AWS with Infrastructure as a Code approach, this is reduced and deploying it is reduced to a few clicks. This would not be possible in an on premise data center environment.

Sonata Software recommends that enterprises leverage infrastructure as a code approach. This is part of the Next Gen Cloud Managed Services of Sonata which is part of the CREATE BOOT aspect of Sonata’s Digital Platform Operation Model.

Below diagram is a representation of the setup of leveraging Terraform based automation for deploying SAP Hybris nodes for one of our large customers in the travel industry.

Terraform Users

First, a user role needs to be created in AWS Identity and Access Management, which will be leveraged by Terraform. This user should have access to manage EC2 instances, S3 storage buckets, IAM users and policies, EFS.

Terraform Configuration

The terraform configuration should create the infrastructure needed for the installation of an SAP cluster in System Replication mode, combined with the high-availability capabilities provided by the SUSE Linux Enterprise Server for SAP Applications in AWS.

The infrastructure deployed includes:

• A Virtual Private Cloud
• A local subnet within the VPC
• A security group with rules for access to the instances created in the subnet. Only allowed external network traffic is for the protocols: SSH, HTTP, HTTPS, and for the HAWK service. Internally to the subnet, all traffic is allowed.
• An Internet gateway
• A route table with its corresponding associations.
• EC2 instances.

Different configurations can be provided through Terraform variables. If already existing resources are to be used, this could also be achieved through Terraform variables. Usage of base AMIs such as a custom image can be achieved after uploading or creating the base image on AWS and then making it the golden AMI.

With Terraform one can deploy and configure the next components (they can be enabled/disabled through configuration options):

• SAP HANA environment: The HANA deployment is configurable. It might be deployed as a single HANA database, a dual configuration with system replication, and a HA cluster can be set in top of that.
• ISCSI server: The ISCSI server provides a network-based storage mostly used by sbd fencing mechanism.
• Monitoring services server: The monitoring solution is based in Prometheus and Grafana and it provides informative and customizable dashboards to the users and administrators.
• DRBD cluster: The DRBD cluster is used to mount a HA NFS server in top of it to mount NETWEAVER shared files.
• SAP NETWEAVER environment: An SAP NETWEAVER environment with ASCS, ERS, PAS and AAS instances can be deployed using HANA database as storage

The recent outbreak of Covid-19 leading to lockdowns in cities across the world has impacted all. Apart from companies dealing with physical goods, technology companies too are impacted with their facilities shut down and workforce directed to work from home.

In this scenario, tech startups are more agile than large enterprises. Tech startups depend less upon on premise data centres and can easily get their staff to connect from their homes and continue working.

So what are the options available to enterprise companies and their employees? Employees within a project need a common digital platform to work on wherever they are.

With AWS Cloud one is well aware that servers can be easily spun up and applications installed. In the case of firms in highly regulated verticals or with legacy workloads on legacy hardware running on premises, it may not be possible to do so.

There is also the fear related to potential malware and exploits running on unsecured home laptops and desktops.

The below factors which need to be taken into consideration can be factored in by using the various AWS services available-

• Consistency- Can a same platform be made available to employees working across a wide variety of devices and Operating Systems.
• Availability- With a huge load of all employees, can the system be available all the time.
• Performance- What will be the impact on the performance of the on premise firewall and internal systems
• Security- How can it be ensured that no malware or exploits is opened up. How will the client data be secured from being exported locally.
• Scalability- Can the platform be scaled appropriately to handle more or less users.

Based on the needs of the project and the role of the employee, users can be provisioned with an on cloud VDI or a remote desktop which in turn can be connected to the on premises systems.

The hardware requirements for end user devices to connect to such VDI options is minimal with a netbook on lease can be sufficient for temporary use.

Common Setup

The first step is to create a VPC and sub nets with CIDR block which will not conflict with the on premise network. A site to site VPN can be set up after obtaining the Public IP of the Customer Gateway (CGW) which is at the on-premise network.

AD Connector needs to be setup and used so that your on premise Active Directory can be used as a source of trust to authenticate your employees to provide access to applications and servers in AWS.

Then the recently launched Transit Gateway can be leveraged to establish connectivity between the VPC and the Site to Site VPN. Charges incurred for data transferred through it, are lower than charges for data transferred over the internet such as through a client to site VPN. AWS Client VPN can also be used to terminate VPN connections from multiple employees working remotely and getting connected to an  AWS VPC and who through a bastion host can then access other instances and on premise servers.

SAP GUI on AWS

A large manufacturing customer of Sonata due to lockdown faced a challenge for their end users who needed to access the SAP GUI. While their SAP environment was on AWS and on-premises, many of their users still needed access to it through SAP GUI on local computers and local networks, which created a few challenges.

Users connecting remotely to their office, were running SAP GUI on their local desktops in their office and moving large amounts of data to and from the SAP environment on AWS were experiencing higher latency and a slow application experience. At the same time, SAP administrators still had to manage SAP GUI on-premises on each user’s computer to make sure everything is up-to-date with the latest security patches. So, while the SAP environment benefited from running on AWS, there were ways to further improve the users’ experience by running SAP GUI on AWS. This was done by leveraging the End User Computing options that AWS has available. SAP GUI was centrally managed and deployed as part of a common image across Amazon WorkSpaces and Amazon AppStream.

Because SAP GUI runs on AWS next to their SAP environment, the customer’s users didn’t need to upload or download data from AWS, and the application feels more responsive. At the same time, AppStream 2.0 makes it easier for the customer to manage SAP GUI for their users. With AppStream 2.0 there is central management of one version of SAP GUI and stream that exact version to every user. Users only access up-to-date versions of SAP GUI, and there is no need to deploy updates to every user’s computer. And, the applications run on AWS next to their data so nothing is stored on their users’ computers. Access restrictions were achieved, and user access management was done with existing Microsoft AD credentials. Finally, AppStream 2.0 is fully managed on AWS. This means AppStream 2.0 manages the AWS resources required to host and run the SAP GUI and related applications, scales automatically, and delivers the applications to the end users on-demand with simple pay-as-you-go pricing.

Amazon WorkSpaces

This service is used to provision workstations in AWS Cloud which can be securely accessed by using the Amazon WorkSpaces Client software which can be installed on a wide variety of Operating Systems. As only the display is delivered to the client and the compute is handled on AWS, there is reduced bandwidth requirements and latency. Also security is in built and a variety of controls can be leveraged to ensure there is no way for sensitive data and files to be exported from the WorkSpace to the end user system. WorkDocs is an add on that can be used to share folders and files among a set of employees internally without allowing malicious users access to the same. Common Workspace bundles can be used to provide a consistent setup for the employees. With Always On functionality which works out cheaper than other cloud providers, the availability and performance of a WorkSpace is not an issue and scalability can be handled both vertically and horizontally.

Amazon AppStream

This service can be leveraged to package only specific applications that are required to be accessed by the employees while working from home. These applications are then securely streamed through the browser to the end user device. Underlying infrastructure consists of fleets of instances. Consistency, Availability, Performance, Security and Scalability of these applications is not a challenge.

Amazon WorkLink

This service can be leveraged to provide secure mobile access to internal corporate websites and apps without the overhead of a VPN. The apps contents will get rendered as vector graphics securely in a container within AWS. Thus protection of highly regulated data can be ensured and also access to internal tools such as Jira and Confluence can be achieved.

Another VDI Option

In addition to this for those employees with desktops running within the enterprise and who only require access to them, a set of t2.micro instances running Windows can be spun up in the VPC and configured with SSH and RDP tunneled through SSH. These instances will act as bastion hosts. The users can then SSH and RDP to these bastion hosts. As Site to Site VPN from AWS to the on premise network has been setup and the Transit Gateway is attached to both the VPC and the VPN connection, once the on premise network administrator permits access to the specific VLAN, the user can then run an RDP session from the bastion host to his on premise desktop. Through Group Policies the controls required can be applied to the RDP session.

Thus Consistency, Availability, Performance, Security and Scalability is taken care of in all these solution options. With Wavelength coming up this could be integrated to further reduce the latency for employees who access VDI from a 5G connection.

About Sonata

Sonata Software Limited follows the Cloud Platformation™ Approach encompassing Consistency, Availability, Performance, Security, Scalability to bring about a digital transformation for its customers across the globe. This is backed by its teams comprising of several skilled and certified architects and engineers providing solutions and support to customers on AWS Cloud.