This post outlines how to automate SAP System Refreshes on Amazon Web Services (AWS) with the help of Libelle’s System Refresh Automation tool (Libelle SystemCopy).
SAP system copies are a defined sequence of steps that to refresh SAP production-support systems with fresh production data. Refreshes are typically done on a quarterly basis for each SAP landscape and each lower-tier system: Quality Assurance (QAS), Sandbox, Projects-, N+1, or Development Systems. Derivates of the process include Client Copies and System Clones.
Compared to other applications, where QAS systems are often a simple copy of Production, SAP architecture requires maintaining a tightly integrated, delicate, and complex relationship between production and non-production systems. This integrated SAP architecture allows for a rigorous but extremely well-functioning application lifecycle of developing, testing, and rolling out of new features.
Due to this complexity, SAP Basis Administrators often execute up to 200 manual or semi-automated steps to execute each refresh, and the process usually takes days, even for fairly SAP small landscapes. Multiplied with the number of SAP production systems, multiplied with each non-production system, and multiplied for each refresh - one can see where throwing lower-cost offshore labor at the problem simply won’t work. Besides – manual processes are prone to error, and quality issues persist when things are done by hand.
Automate Everything
As organizations are running SAP or moving SAP workloads to AWS, they will sooner or later increase the pace of automation adoption. Even (or especially) for SAP. Several events can trigger the adoption: migrating to HANA or S/4 HANA, expanding the AWS footprint for AWS, or other digital transformation trends generate necessary momentum for the automation Initiative.
All of that gets us to Automated System Copies. Refreshes are complicated and manualand the perfect use-case for automation. System Refreshes are easily automatable with the right experience and the right tool. Libelle developed its first version of the SAP system refresh automation solution back in 2011 and has been diligently expanding it based on monthly new release cycles.
A Blueprint for System Refresh Automation
Libelle SystemCopy (LSC) is a third-party software tool to automate refreshes running on the EC2 system’s O/S. Connections to SAP are made using SAP’s SDK. This makes it perfectly scalable and provides the flexibility to run alongside the SAP installations. LSC supports SAP System Refreshes for NetWeaver-based systems including S/4 HANA, ECC, CRM, SCM, BI, GRC, and most all SAP implementations. LSC works for all SAP-supported databases on AWS Windows and AWS Linux platforms. Once installed, a pre-defined workflow will export configuration settings before facilitating a database copy and takes care of all relevant post-processing steps.
For Libelle’s standard AWS deployment model, we are running the orchestrator on an EC2 instance with a standard EBS file system. The complete installation runs inside customers’ VPC. If you share an S3 filesystem across non-production systems, you would consolidate all the R3trans export files that occur during refreshes.
Taking Refreshes on AWS to the Next Level
Once the core workflow has been implemented, the standard refresh process is fully or almost fully automated. From now on, customers expect a 50% reduction in execution time and 70%-90% reduction in manual labor for the system administrators. The reduction is the result of automation and acceleration. All wait or idle periods are eliminated, and steps are executed one after the other sequentially and partially in parallel. At that point, customers should feel comfortable about the refresh process as it is stable, fast, and extremely predictable. Most of the regular SAP Basis Tasks are covered including export and management of 50+ T-Codes such as BD54, DB13, DB59, RZ04, RZ10, RZ20, RZ70, SCC4, SCC7, SCC8, SE03, SE06, SE38, SE61, SE80, SECSTORE, SM02, SM14, SM28, SM 37, SM 38, SM51, SM58, SM59, SM61, SM65, SM69, SMMLG, SMQR, SMQS, SMT1, SMWO, SNC, SP12, SR13, SS02, ST03, STMS, STRUST, WE20, and more. Other Pre-Processing tasks include HANA User export/import, and tasks related to SLT, RSA1, PI, CRM, and an inventory of pending transports so that they can be re-applied in post-processing. While this could be enough for many organizations, a stack of exciting AWS services opens opportunities for taking refreshes to the next level.
Utilize EFS for Database Backup/Restore
During system refreshes, a time-intensive task is facilitating a full database copy to the QAS system from the Production Database. This can be achieved with either a database backup and restore, restore from an existing backup, or with EBS snapshots. While snapshots may provide a database copy quickly, a well-designed database backup- and restore process can be very fast as well – especially with SAP HANA where a 2TB can often be restored in less than an hour.
By default, customers are using S3 Storage to manage backup and restores during the database copy phase. An existing backup can be used, and either we trigger a backup during the copy phase, or an existing backup ID is provided at the beginning of the refresh. Some customers may want to significantly accelerate this process by considering Amazon EFS. This provides a simple, scalable, elastic file system for Linux-based workloads for use with AWS Cloud services and on-premises resources. One of the amazing features of EFS is the extreme I/O Performance, which accelerates database restores dramatically thus significantly shorten the end-to-end refresh execution time.
Burst Refreshes
AWS Elasticity facilitates a simple concept of performing the Compute- and Disk-intensive refresh on larger systems instead of the actual QAS system. The QAS system is temporarily moved to one of the extra-large AWS compute instances with the best I/O possible available on an hourly basis. There, the refresh is executed before scaling back down to the Business-as-Usual QAS system. A significant additional reduction in refresh time can be achieved, and since the Burst Landscape is used only temporarily on an hourly basis, costs are kept to a minimum.
Standby Refreshes
A standby refresh is a concept of refreshing a second, independent QAS system while the actual QAS system is still being used. Once that QAS clone is refreshed, the actual QAS system and QAS clone are flipped. While it adds a bit of complexity to the process, since everything is orchestrated, it is perfectly doable, as outlined in the flowchart below.
Summary
AWS changed how IT operates more dramatically and fundamentally than many of us realize. The key to the tremendous AWS success is the laser-sharp focus on standardization, automation and orchestration. There is hardly anything done manually on any level of the AWS cloud stack. Everything follows a process and each process is standardized, and then either automated or at least easily automatable if desired.
Libelle does for System Refreshes what AWS does on a large scale: Standardize, orchestrate, and automate. Then repeat over and over. Automated refreshes Running SAP on AWS opens opportunities to aggressively increase operational efficiency of IT operation and help transitioning IT to becoming a service broker. It is a paradigm shift of how we manage processes which – once initiated – keeps moving. Libelle’s customers fundamentally changed their perspective on system refreshes from people-centered to software centered. The refresh automation project on AWS often serves as a lead initiative for getting other projects more software-centered.
Learn More
More information about Libelle SystemCopy (LSC) on AWS is available on https://libelle.us/aws. LSC is available as AMI on the AWS market place with a BYOL model.
Recommended articles
November 30, 2022The 12 Factor App Part 3: (Disposability, Dev/prod parity, Logs, Admin processes)
