The use of automation has become very relevant for SAP ecosystems in the last few years. Many companies use it to deploy new workloads or migrate their existing ones to new platforms, like the cloud, namely to hyperscalers as it is a big trend.
However the value of automation is much bigger than just for deployments because once the systems are up and running they need to be managed for their entire lifecycle and it is here that automation reveals its true potential.
Let us think of all the routinary tasks that are involved in SAP administration, tasks that tend to be complex and take quite a long time. They are also quite sensitive and we need to make sure they are executed correctly, for example a restart of a whole SAP system with its dependent applications that needs to follow a strict order for it to be successful and avoid issues.
Automation eliminates human error because once the steps of a task have been defined, tested correctly and an automation asset has been created to execute those steps there is no room for mistakes as it will be executed identically every time.
Automating system copies and system refreshes with SAP LaMa, NetApp and Ansible Automation Platform
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.
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.
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.
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.
Takeaways
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.
If you want to read more on automating Day 2 operations for SAP:
Smart Management for SAP
However the value of automation is much bigger than just for deployments because once the systems are up and running they need to be managed for their entire lifecycle and it is here that automation reveals its true potential.
Let us think of all the routinary tasks that are involved in SAP administration, tasks that tend to be complex and take quite a long time. They are also quite sensitive and we need to make sure they are executed correctly, for example a restart of a whole SAP system with its dependent applications that needs to follow a strict order for it to be successful and avoid issues.
Automation eliminates human error because once the steps of a task have been defined, tested correctly and an automation asset has been created to execute those steps there is no room for mistakes as it will be executed identically every time.
Automating system copies and system refreshes with SAP LaMa, NetApp and Ansible Automation Platform
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.
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.
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.
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.
Takeaways
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.
If you want to read more on automating Day 2 operations for SAP:
Smart Management for SAP
- SAP Managed Tags:
