Subscribe to the feed

It’s no secret that SAP systems are both complex and critically important, so their management can be challenging, especially when having to adapt to the short maintenance windows that lines of business can generally afford.

SAP automation

This complexity and constraint on time and resources puts pressure on the administrators, which might lead to errors that can be costly for the business. That is why automation plays a central role in the whole SAP life cycle. It speeds up the execution of tasks and reduces human error, because once all of the steps in a process have been identified, coded and tested successfully, the automation produces the same desired results over and over.

SAP automation use cases

A common activity that is particularly cumbersome in SAP administration is the SAP system refresh, where quality assurance, test or sandbox systems are refreshed with data from production so that the new developments have the latest set of data for testing. This procedure varies quite a lot between customers, depending on the applications that interact with SAP, which SAP products are installed and the configuration of the SAP ecosystem.

This involves a long list of tasks that need to be carried out before the data is copied, and another list of tasks to be done afterwards, such as renaming the target system (that otherwise will be the name of the source one) and adapting all the connections to other systems and applications.

Other long and challenging tasks are system copies, similar to the refreshes but the target system is new instead of already existing (this is done when new test, training, sandbox or development systems are needed) and system clones, where source and target systems are identical including SAP system identifier (SID), instance number and hostname. Clones are generally used to investigate data corruption and to test disaster recovery (DR) scenarios.

SAP automation with Red Hat Ansible Automation Platform

Automating system refreshes, copies and clones has been one of the main goals of SAP Basis administrators for many years, and today we have solutions to achieve this. The one that we are presenting here is a combination of three elements: SAP LaMa (Landscape Manager), NetApp Data Management and Red Hat Ansible Automation Platform.

SAP LaMa is an orchestration solution for SAP landscapes that can be used for provisioning new SAP instances, patching, stopping/starting them in the right order (as SAP environments normally have interdependencies), performing system refreshes, and making copies and clones, among other tasks.

Due to the time constraints that maintenance windows impose on these processes, every step that we can shorten is of great help. With NetApp Snapshot and NetApp FlexClone technologies, it is no longer necessary to restore a backup of the source system to the target, reducing the elapsed time to minutes instead of hours. In the case of system refreshes and copies where, as mentioned before, other tasks need to be done in addition to the actual copying of the database, the time spent on these can also be dramatically reduced by using workflows native to SAP LaMa and others created with Ansible Automation Platform. 

In this solution, it is Ansible Automation Platform that allows the connection between SAP LaMa and the NetApp storage, so LaMa can trigger the functions needed in the storage by calling Ansible Playbooks). It can be used by customers who have their SAP systems on-premises or on any type of cloud—private, public or hybrid.

Having a robust DR plan is also of utmost importance for SAP landscapes, and this needs to be thoroughly tested. As mentioned earlier, this is one of the use cases for cloning SAP systems.

In this scenario, NetApp SnapMirror can be used to create replicas at volume level. The replicas will be in different datacenters from the source system, and it can be updated synchronously or asynchronously. Testing the DR plan involves disconnecting the access to the primary datacenter and redirecting all connections to the datacenter(s) where the replicas have been created. This entire process can be orchestrated by SAP LaMa that will call the playbooks to trigger the corresponding actions in the NetApp volumes and will cause no interruption in the data replication.

SAP automation Figure 1. Disaster recovery testing

Figure 1. Disaster recovery testing

How the integration with Ansible Automation Platform works

Apart from having predefined workflows, SAP LaMa allows for creating custom workflows by using hooks that call other processes, in this case described in Ansible Playbooks. These playbooks will be stored in a dedicated Ansible host that can be either the upstream community version (Ansible Engine) or Ansible Automation Platform.

This provides an infrastructure as code (IaC) approach to a customer’s IT footprint with orchestration capabilities at all levels, robust security with role-based access control (RBAC), recommendations on the usage of automation based on analytics, Event-Driven Ansible, and access to certified and supported Ansible Role collections that can be found in Ansible automation hub.

In SAP LaMa we have to define where Ansible Automation Platform is running (an SAP Host Agent needs to be installed on it so that it can communicate with SAP LaMa) and then we will create the hooks in SAP LaMa Automation Studio for each of the storage operations (there is an Ansible Playbook for each). The Ansible Playbooks use the Ansible NetApp certified collection to perform the different tasks.

SAP automation Figure 2. Example workflow for an SAP system clone

Figure 2. Example workflow for an SAP system clone

This GitHub repository contains the Ansible Playbooks with the operations on NetApp that can be called from SAP LaMa (or from any other source). This is part of the SAP LinuxLab GitHub organization that aims to be the de facto repository for all of the community automation content for SAP written in Ansible Automation Platform. 

Conclusion

The combination of NetApp, SAP LaMa and Ansible Automation Platform provides a powerful solution that can help dramatically reduce the time and effort needed to fulfill the given SLAs for the most complex and time-consuming tasks related to SAP system administration, while also helping to avoid configuration drift between the systems that can originate because of human error. 

Since system refreshes, copies, clones and disaster recovery testing are very sensitive procedures, implementing such a solution can free up precious administration time. It can also reinforce the trust that the LOB has in the SAP system administrators, as they will see how much easier it is to copy systems for testing or other purposes, and how much time can be saved when troubleshooting problems that can occur during the process.

Learn more


About the author

Ricardo Garcia Cavero joined Red Hat in October 2019 as a Senior Architect focused on SAP. In this role, he developed solutions with Red Hat's portfolio to help customers in their SAP journey. Cavero now works for as a Principal Portfolio Architect for the Portfolio Architecture team. 

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Browse by channel

automation icon

Automation

The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon

Infrastructure

The latest on the world’s leading enterprise Linux platform

application development icon

Applications

Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech