Hundreds of companies have been running SAP infrastructure on-premises for decades as a key component of their business processes. Until recently, they’ve been reluctant to consider the public cloud as a viable option to run their SAP workloads…now, however, with the public cloud having transformed the way we run IT over the past few years, it has become harder for those companies to justify on-premises infrastructures for SAP. A lot of those companies are starting to migrate some or all of their SAP workloads to the public cloud, or develop new cloud-based workloads, alongside other use cases such as analytics of AI.
In this blog, we’ll discuss key considerations when migrating or deploying SAP applications in the public cloud, focusing on data migration, compute, storage and DR with Elastifile Cloud File System (ECFS). Elastifile’s solution offers the ideal enterprise-ready cloud file system environment for running SAP applications in Google Cloud…and without any refactoring of the SAP applications whatsoever.
While on-prem SAP hardware infrastructure is aging, companies are looking toward the public cloud to benefit from its agility, flexibility scalability to eliminate their CapEx commitments. In addition, they’re also often looking at upgrading their SAP infrastructure in the process (e.g. going from an on-prem ‘SQL Server’-based architecture to a Google Cloud HANA-based architecture). Modernizing their infrastructure in the process is a key factor when choosing to migrate to a cloud-based architecture. While discussing with customers, we’ve seen the following trends when it comes to SAP cloud use cases:
- Brand new SAP install – The entire SAP environment is deployed in GCP directly, from scratch
- Lift and shift – Migrating existing on-prem SAP applications to GCP
- Lift, shift, and upgrade – Move existing on-prem applications to GCP and upgrade some components of the SAP architecture while doing so (e.g. upgrade on premises DB to 4/HANA).
Companies are looking towards the public cloud to run SAP applications to improve IT agility, eliminate CapEx commitments and leverage the elasticity, compute power, and scalability of the public cloud.
So what are the key benefits that the public cloud offers for SAP (and beyond to any compute application running in the cloud)?
- Cost savings – Be done with large, on-premises CapEx and stop maintaining legacy hardware and DBs. Instead, upgrade to controlled OpEx in the cloud where you only pay for what you use and can quickly and easily scale up and down.
- Agility – With on-premises hardware you can only use what you have and deploy limited SAP workflows based on that hardware. SAP performance gets impacted whenever there is a growth in demand since the on-premises hardware is limited and quickly becomes a bottleneck. In the public cloud, there is no need to buy hardware, install and configure it: you can instantly provision as much compute power as required to adapt to change in SAP workload demand.
- Scalability – Unlike limited on-premises hardware, the public cloud gives you access to unlimited resources and allow you to scale your SAP workloads easily, on demand, and as large as needed, for compute power and storage.
- Adaptability – The public cloud lets you quickly adapt to surge compute power up and down. At any moment, you can add lots of compute resources for a limited time and shut it down later when the demand in compute power slows down.
- Resilience – The public cloud multi-zones and multi-regions offer the perfect environment to ensure disaster recovery, availability and business continuity. Storage providers like Elastifile leverage the cloud multi-zones and regions to ensure your SAP workloads are always up and running, all the time without any interruption.
Elastifile has been deployed in GCP for various SAP environments. We’ll take a closer look at one customer in the financial space who has deployed a new SAP environment in GCP, based on an ECFS storage cluster between multiple zones and regions. The following diagram depicts the architecture they put in place in GCP with Elastifile using two regions: US West-1 and US-Central-1.
Figure 1. Google Cloud & Elastifile financial customer – their architecture
The following workflows were key for that customer to deploy:
- The first SAP applications that are being deployed to GCP are : Bank Analyzer, ECC and the HANA Datalakes. To start with, not all SAP applications were migrated to GCP. It was important to start with some of them and be able to easily bring additional ones later on.
- All SAP applications are sharing the same Elastifile global NFS namespace.
- For Disaster Recovery (DR) considerations, the SAP HANA database is replicated between 2 zones of a region (using SAP HANA native sync replication feature) and the Elastifile storage cluster is replicated into a different region (using ECFS native async replication feature ). The SAP HANA database is also replicated into a different region (using SAP HANA native async replication feature),
- More SAP applications will be migrated to GCP with Elastifile as the storage backbone within the next two years,
- The same Elastifile NFS cluster is shared between SAP and non-SAP applications for consolidation considerations. They started with a SAP use case but will use the same ECFS cluster to deploy other use cases, again on the same NFS space.
While being used as the file system backbone for the SAP applications, it was crucial for that customer to ensure business continuity, to protect against the possibility of a component failure. Elastifile’s native support for multi-zone deployment on GCP (synchronous replication between Elastifile storage nodes in different zones) and cross-region asynchronous replication makes it a very robust architecture to ensure SAP application business continuity without any interruption. The following diagram depicts a two zone (US West-1 and US Central-1) where a production Elastifile storage cluster in the us-west-1 zone is fully replicated in the us-central-1 zone for DR purposes.
Figure 2. Elastifile multi-zone ASYNC DR architecture for SAP DR
With such a deployment and with SAP HANA and other applications also being replicated to a different region, they ensured full continuity in the event that their main production environment becomes unavailable. The use of GCP zones and regions, SAP HANA replication features and Elastifile multi-zone/region support and replication features makes this architecture a very robust environment to run SAP
Key storage considerations when moving SAP infrastructures to the public cloud:
- File Access Protocols – SAP applications require a file-based access method, typically based on the POSIX NFS or SMB protocols. Existing public cloud storage offerings are based on object storage that are accessed via object protocols (HTTP REST, S3). One must consider a cloud platform that natively supports POSIX file system protocols.
- Scalability – Similar to performance considerations, scalability and the ability to scale up/down on-demand are equally important to enable quick adaptation to changes in SAP workloads. One must consider a cloud platform that can be easily scaled up and down without interrupting ongoing SAP workloads.
- Multi-region and Multi-zone support – In order to ensure business continuity one must consider a storage solutions that can span multiple zones and regions, should a zone or region not be available for a period of time.
- Replication – In order to support multiple cloud regions and provide a robust DR scenario, one must consider a storage solution that can asynchronously replicate the SAP storage backbone between regions and can quickly re-start in the DR region would the main production not be available for a period of time.
Elastifile v3.0 addresses all of the above and more, and is available today in the GCP Marketplace for you to deploy to support your SAP use case.
Learn more about Elastifile for SAP
Learn more about Google for SAP