DEV Community: Sourabh Chordiya

SAP BTP, RISE and AWS network patterns

Sourabh Chordiya — Wed, 29 May 2024 00:45:06 +0000

SAP's BTP ( Business Technology Platform) is a SaaS offering where SAP is providing various integration and development services. The key focus of BTP is to keep the SAP ERP core cleaner, less customized in other words, and rely on these services to create integrations and deliver front-end services. While customers are in the process of determining use-cases to leverage this, they typically see that both BTP and AWS will be used. Typically, customers have their ERP systems in IaaS setup on AWS, and they leverage BTP on AWS as well. Let's first understand the scenarios that can exist and then cover how network design can be defined for these scenarios.

Customer is using their SAP systems in IaaS setup on AWS and are leveraging BTP services as well on AWS
Customer is using their SAP systems in IaaS setup on another cloud or on-premise and plans to deploy BTP services on AWS
Customer is using SAP under RISE with SAP on AWS setup and plans to leverage BTP on AWS

In each of the above cases, several AWS services can be used to minimize latency and keep traffic secure while configuring the interfaces.

SAP systems and BTP both on AWS - The communication in this case can be kept away from internet completely, reducing the surface area for attackers. The AWS PrivateLink for SAP (AWS PrivateLink and SAP on AWS Deployments - DZone) addresses this use-case. PrivateLink provides an endpoint on SAP owned AWS Account that runs BTP called Interface VPC Endpoint. This endpoint can be connected from any AWS service in AWS account owned by customer using the so-called AWS PrivateLink or SAP PrivateLink in the manner described in below image, which is further elaborated in referenced blog. (Image Ref - How to connect SAP BTP Services with AWS Services using SAP Private Link Service | AWS for SAP (amazon.com))

SAP on another cloud or on-premises while BTP services are on AWS - In this case, if there is an existing VPN or Direct Connect established between on-premises and AWS, the same can be leveraged to enhance security. PrivateLink cannot be used in these scenarios as the PrivateLink services are a native scenario exclusively available for connectivity between various services within AWS but on different accounts. In such multi-cloud scenarios, network traversal must be over internet, unless customer has private connectivity with each of the service provider that they wish to use BTP services and SAP Infrastructure services. There are 2 possible scenarios, either customer has these connectivity setups with both cloud providers from their own managed data centers or this setup can be performed via a Multi-Cloud Connectivity provider, for example F5.

RISE with SAP on AWS and BTP on AWS - RISE with SAP is an SAP construct in which the SAP support team manages AWS Accounts, Infrastructure and SAP Platform, which provides customer an "Enterprise Software as a Service" experience. The actual SAP systems run in IaaS manner from the SAP perspective, however customer does not need to worry about the IaaS as SAP manages it completely along with all Operational tasks. RISE with SAP on AWS provides BTP Platform Credits which further makes it easier for customers to start leveraging BTP. From an architectural perspective, this setup can be performed in same manner as above, however, SAP need to enable the Load Balancer and accept the BTP endpoint connectivity request in their VPC (to be further checked and image to be updated.
Network in AWS can lead to challenges related to latency that can impact the performance.

It is necessary that a consideration is made in terms of latency requirements and accordingly the right design is chosen. The key considerations are below -

Choosing the location of various components - The cloud deployments brings plenty of choices and with options discussed above, there is always a possibility of customer setting up a multi-cloud deployment. In such cases, its important that the end-user location, SAP systems deployment location, and the SAP BTP services deployment location are as close as possible, which will minimize latency. It should be noted that with global user base for large enterprises, this may not be possible in all cases.
Ensuring the routing is setup correctly - It is observed in many deployments that even when servers are setup closely, there are lot of hops for packets introduced due to routing issues. Always perform a trace route of the traffic to ensure that this problem is not increasing latency and keep the hops to minimal by changing routing. Route Manager, a part of AWS Network Manager, can help diagnose and correct such problems.
Data being transferred is chosen carefully - The BTP is a processing engine, whereas core ERP system is a data store. It might happen that lot of data is transferred over to BTP , which can eventually increase throughput and slow down the end-to-end flow processing. Always perform the selection within ERP and transfer the data chunks that are as small as possible, which can be transferred multiple times if required. SAP BTP and SAP on AWS can help customers transform their SAP business processes to ensure that the systems are ready for new-age integrations and the innovations. It is a necessity for any SAP customer now to consider these options carefully and decide their roadmap based on the available options and the customer's future roadmap for overall transformation and digitalization journey.

Image Ref - https://community.sap.com/t5/technology-blogs-by-sap/business-continuity-with-rise-and-btp-part-3-technical-building-blocks-in/ba-p/13574997

SAP on AWS - Disaster Recovery mechanism evaluation

Sourabh Chordiya — Sun, 30 Apr 2023 00:15:32 +0000

In my previous blog, I wrote about various cluster mechanism for high availability. While the High Availability mechanisms in the landscape are providing a very aggressive RTO and RPO and protects against single host and single zone failures, the disaster recover strategy provide protection against regional failures. This is important for the enterprises that run their business globally and will potentially need to operate business processes and run SAP workloads irrespective of single region being unavailable.
As more components get added to a customer's setup for HA and DR purpose, it becomes important to first evaluate the cost aspect and purpose of disaster recovery. Usually, the landscapes are a mix of critical business systems and non-critical supporting environments. A typical example is SAP Business Suite systems, ECC, CRM, SCM usually are critical ones, while Solution Manager, BW, Business Objects, Portal and other applications being non-critical in nature. As the probability of a whole region getting failed is very minimal, though still possible, critical applications shall be considered for a robust DR strategy, while non-critical applications can sustain with a backup/restore mechanism. Below are 3 key mechanisms by which Disaster Recovery can be achieved in AWS

Warm Disaster Recovery
Pilot Light Disaster Recovery
AWS DRS - Disaster Recovery as a Service - Storage level replication
Backup/Restore - Storing the native database backups as well as the EC2 instance backups across regions

Let us deep dive on each of them and understand the type of SAP systems for which these are good fits.

Warm Disaster Recovery

The term "warm" represents a database or a server that is pre-populated with data. Basically, in this design, the Disaster Recovery region (or zone in case of zonal DR) have a fully configured EC2 instance that is always receiving changes from primary EC2 instance in an asynchronous manner using the database replication mechanism. In case of SAP HANA, it will be the HANA System Replication (HSR) that will replicate the changes. Since the design includes a secondary EC2 instance that is of same size as primary EC2, the cost of this design is highest among the options available. The benefit is very short RTO and short RPO duration. For the SAP application servers and ASCS/ERS instances, as there are no data related changes, the design involves setting up EC2 instances that can run application servers and ASCS/ERS instances on-demand. These can be shut down to save some of the costs and they are started when a DR event or a DR testing happens.

Pilot Light Disaster Recovery

The term pilot light is derived from gas burner which has a smaller gas burner permanently alight to lighten up the larger burner, the smaller one is called pilot light. Using the same analogy, for a HANA database or any other support SAP database, in order to ensure replication happens a minimal sized EC2 instance is deployed in DR region. This instance is up to date with database changes, however cannot function without a reboot to resize the instance and bring it up to the same configuration as actual production instance. For SAP application servers, the design follows same strategy as a warm standby. In case further cost savings are required, for application layer, the storage costs can be further saved by only deploying application servers when a DR event or DR testing happens. In order to achieve this, either AWS DRS ( discussed further below) or AWS CloudFormation/Terraform/AWS Launch Wizard based scripts can be utilized.

AWS DRS

AWS Elastic Disaster Recovery as a Service (abbreviated as DRS) uses storage level replication for an EC2 instance and unlike previous 2 methods, does not rely on running applications or databases to perform the replication. The replication itself need not be managed and require no storage expertise, as this just need to be enabled from AWS console and rest is taken care behind the scenes automatically using AWS native technologies. There is no EC2 instance that is actively running in DR site until a DR event is initiated manually using AWS console either for testing or real DR purposes. This further save cost but also increases the time it takes to bring up the service as an instance need to be deployed using the replicated storage.

Backup/Restore

The backups can be performed for most of the databases with AWS backup, alternatively for unsupported databases, they can be backed up to a EBS based disk and then copied over to S3 bucket that is configured for cross-region replication (S3 CRR). These backups are available in secondary region with a latency of 15 minutes or more, hence this approach is suitable when DR RTO and RPO requirements are not stringent in nature. In SAP landscape, this applies to non-critical systems, usually this includes SAP Solution Manager, SAP LVM, SAP ATC. Depending on scenario, some of ERP systems also can be considered for this approach.

Below is a table that compares these options against several parameters

The right Disaster Recovery approach is usually a mix of all the mechanisms described above. Start with answering below questions for any customer scenario.

What is the SAP application type?
Are there specific RTO/RPO requirements available?
Evaluate RTO/RPO in terms of business impact
Evaluate cost implications

Another important aspect that shall be kept in mind is testing Disaster Recovery. All the approaches described above provides mechanism to perform Disaster Recovery tests. However, in SAP landscapes, it is important to note that most of such landscapes do not work in isolation and have dependency with plenty of other systems, for example, fileshare areas, integration engines like BizTalk, job schedulers like Control-M ,and many others. There are also key landing zone components including DNS, Active Directory among others that need to be functional in a DR region before DR can be validated and/or executed. Ensuring that these pre-requisites are addressed before DR for SAP landscapes are planned for implementation and DR tests will ensure that in a real DR scenario, the test results can be reliably used.

In the next article, we will understand how the above scenarios can be automatically deployed and tested in AWS with minimal manual intervention.

Automated SAP deployments on AWS

Sourabh Chordiya — Thu, 30 Mar 2023 00:27:17 +0000

The SAP products are used by almost every major enterprise irrespective of business they do. There are plenty of SAP products available, the key ERP product that is now S/4HANA and traditionally being SAP ECC. Alongside, SAP has plenty of solutions for Supply Chain, Customer Relationship Management, Analytics among others. With Digitalization being the part of every Organization's strategy, one of the key requirements that come in with deployment on AWS platform is to deploy quickly and prepare repeatable deployments. In this article, while we primarily focus on SAP, the concepts are re-usable for any other software stack as well. We will understand the various tools that can be used along with some sample scripts on how we can get started with such deployments. It is expected that the reader understands SAP and Infrastructure basics.
IaaC, abbreviation for Infrastructure as a Code is commonly used terminology in DevOps. Unlike traditional web software, SAP has a different design and usage pattern, and hence it's important to understand the cases in which IaaC becomes applicable before we understand the tools that can be used. SAP environments typically require ABAP application layer and database layer which can be on same or multiple different servers. There are also Java applications, Business Objects, and several other products that SAP supports. In addition, the SAP BTP platform is a combination of several services that SAP provides in PaaS model which covers integration scenarios and various latest technologies like AI/ML. All these products are available to be deployed on AWS as long as they support minimal version requirements as per the SAP and AWS documentation. (SAP Note 1656099 - https://launchpad.support.sap.com/#/notes/1656099 - login required) documents the version requirements.
For the infrastructure deployment on AWS, CloudFormation is a natively available framework from AWS, however, to remain cloud-agnostic, one can use Terraform, Chef, Puppet, which are popular products in the market for such use-cases. The next step is Configuration Management, or in simple words, configuring the deployed infrastructure, including operating systems, applications, databases and anything else that uses underlying infrastructure. Ansible is the most popular tool although Terraform, Chef, Puppet and other tools can do the same as well to some extent. For SAP administrators and architects, it is important to know basics of Github, its an open-source collaboration platform, used in DevOps projects primarily, but can also be used for any sort of code that need to be hosted and maintained in versions. There are many useful features and automation codes including SAP deployment automation use-cases, one of these covered in https://github.com/darpan92/SAPS-4HANA_Terraform_Ansible which is referred in the blog https://blogs.sap.com/2021/05/05/automated-vm-and-sap-systems-deployment-on-cloud-part-1/. Note that AWS already have an offering called AWS Launch Wizard that can automate S/4HANA deployments, it provides deployment mechanism using a UI driven approach with lesser customizations.

The key item to keep in mind with SAP automation is to break it down into different phases, which are as below.

1. SAP Sizing and Design - this can be partially automated. While the sizing topic on AWS is a detailed blog in itself, however the sizing is adjustable in AWS for a lot of aspects, which makes it easier for architects to start with smaller setups and ramp-up as needed. The automations can play an important role in ramping up automatically. In some cases, it might be required to deploy additional application servers, or restart database servers where a failover can simplify the capacity change plan

2. Infrastructure Deployment - AWS Infrastructure can be deployed via AWS Console, AWS CLI, APIs as well as automation tools discussed earlier. This step can be automated, but we have to keep in mind that writing scripts also requires a little bit of time and also expertise. If its a couple of servers, one could better go for manual approach, the automations come in handy when requirement spans across more than 10 servers that follow same pattern. With IaaC tools, a basic design pattern is automated. Lets understand with an example, for an SAP system, we will need an ASCS server, an application server, and a database server. For this case we will consider them to be on SUSE Linux, and then they will require some initial configurations like kernel, shared memory changes, a few additional packages to be installed, filesystem mount and swap creation among others. The list will be longer in case high availability setup is planned.

3. Operating System Configuration - The operating system need to be configured for various parameters, disks need to be partitioned and formatted, the shared filesystems will need to be created for sapmnt and trans directories before an SAP system can be installed. All these can be achieved using both Terraform and Ansible, however we will see this using Ansible. The process is pretty much same irrespective of tools being used, usually only syntax differs for simple tasks.

4. SAP system Installation - The process for installation of database and SAP systems remains pretty much how we would perform this manually, but instead of using GUI mechanism of SWPM and other installers, we will leverage the silent/unattended installation method. Almost every parameter can be passed through an input parameter file ( SAP note https://launchpad.support.sap.com/#/notes/2230669 - login required). By running SWPM once manually, the file can easily be generated and then customized. In most cases, except for SID and passwords, the inputs remain pretty much same across the landscape, which makes the silent installation a go-to option for automation

5. Post installation configurations - Most of the basic activities are covered in ABAP task-list SAP_BASIS_SETUP_INITIAL_CONFIG for ABAP systems (https://help.sap.com/docs/SLTOOLSET/e345db692e3c43928199d701df58c0d8/66e402a5545a4ccf95e3134bc4fa974f.html?version=CURRENT_VERSION) and the few other tasks like backup configuration using AWS Backup or backint integration can be scripted easily using a combination of terraform scripts to deploy resources and ansible scripts to perform configuration changes like parameter adjustments. Note that the post installation activities may involve items like updating a central inventory, making changes to SAP GUI logon pad entries, and similar steps that are usually outside of Basis team's control but can be managed in automated fashion depending on tools being used.

References -

https://bluelight.co/blog/best-infrastructure-as-code-tools
https://blogs.sap.com/2021/05/05/automated-vm-and-sap-systems-deployment-on-cloud-part-1/
Image by Gerd Altmann from Pixabay

OS Clusters in SAP on AWS landscapes

Sourabh Chordiya — Mon, 20 Mar 2023 07:28:38 +0000

Cluster software are designed to provide an automatic high availability and failover capability in an enterprise environment. This ensures that business can operate without disruptions. While the public cloud environments, including AWS, provides resiliency by virtualizing the infrastructure which makes the underlying physical infrastructure failures transparent for the application, the infrastructure is not the only layer that can fail, there is an Operating System, a kernel in-built in that OS that translates requests to underlying layers, the storage, network, and the application itself which can fail and cause disruptions for business processes. It is hence important to ensure design patterns that can tolerate such failures. The whole AWS zone can suffer a network issue or in worst case a natural calamity, which also can lead to a business outage for SAP usage. Let us understand how clusters use specific AWS services in SAP environments.

The standard SAP application for ABAP follows a design that has 2 single point of failures. The first one is named ABAP SAP Central Services (ASCS), which consists of a message server and an enqueue server process. While the message server does the task of receiving and dispatching requests to appropriate application server, the enqueue plays the role of managing locks to ensure that application-level consistency is guaranteed. The second component is Database, which is the heavy component in terms of size and is also key to performance.
To ensure SAP on AWS can continue to perform in a stable manner, there are several cluster designs possible, in this blog we will deep-dive on 2 of them, namely, Pacemaker and Windows Server Failover Cluster (WSFC).

Pacemaker is available for SUSE Linux and RedHat Linux operating systems at a small additional cost with Operating System licensing. Among the other third-party solutions, this offering is popular because of the low cost and low maintenance. In AWS, there are few key items that need to be considered for this.

1.STONITH -The STONITH is an abbreviation for a very interesting term, Shoot The Other Node In The Head, which in literal sense means the same. Its basically a device or a service that is managed as a part of cluster. In AWS, it is named external/ec2 and this is an I/O based fencing agent. I/O based fencing agents are designed to ensure that no I/O can happen from a faulty node and it is detected using Quorum policy.

2.Overlay IP Agent - Its a cluster resource that is just acting as a watchdog and is intended to avoid a split-brain situation when there is a 2-node cluster. This application is also capable of shutting down AWS EC2 instances and update route tables. We will deep-dive on this agent in another article, however for understanding, consider this as an external watchdog that ensures a split-brain situation in a cluster can be avoided.

3.Route Table - The Overlay IP has to be routed to the currently active cluster node (EC2 instance), and this is achieved using the entry in route table attached to the VPC. The route tables are updated by cluster when failover happens.

4.AWS Transit Gateway - A scalable cloud router that will allow traffic from on-premise networks and other VPCs to be routed to Overlay IP.

5.Network Load Balancer - An alternative to Transit Gateway, this mechanism is primarily intended to be used for TCP load balancing scenarios, however the same can be leveraged for routing as well.

6.*EFS / FSx for Lusture / FSx for Windows File Server * - The cluster setups require a shared filesystem between the participating servers which can provide consistent reads/write. In case of AWS, this is available via FSx for Lusture for Unix based operating systems, while for Windows FSx for Windows File Server solves the purpose. The services are completely managed by AWS, and are available across zones. Elastic File Systems, or EFS, provide file services as well which is basically a manager NAS

All these services work in combination as depicted below

The Pacemaker, developed by ClusterLabs (https://clusterlabs.org/pacemaker/) is a cluster resource manager that is capable of detecting and recovering in case of machine and application failures. The various features like quorum, restriction to run resource on same machine, dealing with quorum loss scenarios are designed to provide the resiliency intended for enterprise-scale applications. Pacemaker is developed for Unix based operating systems and is integrated to both Redhat and SUSE Linux, which makes it a default choice for SAP HANA database clusters. In addition, it can be used for scenarios where SAP central services use one of the 2 operating systems as well. On AWS, both OS are supported and available in subscription based as well as bring your own license model.

Windows Server Failover Cluster, a Microsoft cluster management software, that is available natively for Windows servers, is leveraged in SAP landscapes where application layer uses Windows OS based ASCS and ERS server. From an AWS perspective, the design principle is closely aligned to the Pacemaker setup. The Windows setups require an Active Directory integration to work seamlessly and hence this design pattern additionally requires Microsoft Active Directory in same VPC or a peered VPC.

In addition to above cluster solutions, there are also other partner products below that can be setup to provide cluster setups, I will cover a comparison with pros and cons in another blog post for these products.

Veritas Infoscale for SAP on AWS
SIOS DataKeeper Cluster for AWS
NEC ExpressCluster

References -
https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html
https://aws.amazon.com/blogs/awsforsap/how-to-setup-sap-netweaver-on-windows-mscs-for-sap-ascs-ers-on-aws-using-amazon-fsx/
https://docs.aws.amazon.com/sap/latest/sap-netweaver/net-win-high-availability-system-deployment.html