VMware Cloud on AWS enables you to extend your on-premise data center to the cloud and easily live migrate / vMotion targeted application workloads to VMware Cloud on AWS without conversions. This hybrid cloud setup provides the flexibility of distributing your SAP landscape between on-premise and the cloud as capacity demands. In this blog we show how some example SAP workloads can be easily moved without downtime, errors or timeouts.
VMware Cloud on AWS is not supported for SAP workloads at this time. Please stay tuned to https://twitter.com/vmwarecloudaws .
In a previous blog we explained the pre-requisites for vMotion to VMware Cloud on AWS which include AWS Direct Connect, Layer 2 stretch network, and Hybrid Linked Mode. A demo showing execution of a cross-cloud vMotion using the vSphere web client is available here. The following diagram shows the logical architecture of our lab setup (diagram borrowed from a hybrid cloud vMotion performance blog).
Tests were conducted on two separate systems: 3-tier SAP system; 2-tier SAP system. The following diagram shows the architecture differences between a 3-tier and 2-tier system.
For larger SAP systems we would scale out the app servers across multiple virtual machines – this is a 3-tier setup. For a smaller SAP system sizing may allow for both the application and database server to be installed in the same virtual machine – this is a 2-tier setup.
The following test was conducted: live migrate a 3-tier and 2-tier SAP system from on-premise to VMware Cloud on AWS while running an SAP batch workload.
The SAP workload used in the tests was a batch job referred to as “SGEN”. SGEN is a utility that SAP administrators run after a fresh installation or upgrade to compile ABAP code. It generates a batch job that runs in multiple work processes in parallel on the application server. The job runtime architecture is very similar to how other business batch jobs are run.
Live Migration to Cloud – Results
The following diagram shows the results of the SAP batch workload while the SAP system was being live migrated from on-premise to VMware Cloud on AWS.
During migration (which lasted around 20 to 30 minutes) the batch job was executed multiple times in succession – the value shown is the average of multiple runs during the migration. Some observations from the live migration results:
- There were no disconnections between the application and database server during migration and the batch job successfully completed.
- The 3-tier system experienced worse performance because the application server completed migration before the database server (latter comprised of more virtual disks and hence took longer to migrate) at which point network latency between the application server and database contributed to the longer duration.
- The 2-tier system experienced minimal performance degradation during the migration. The batch job completed successfully multiple times in succession during the migration.
- Once the SAP systems had completed migration performance of the batch job was better (shorter duration) than when run on-premise – one contributing factor to this is the hosts in VMware Cloud on AWS had later chip versions than the hosts in the on-premise lab.
Summary
We tested an SAP batch work load on a 2-tier and 3-tier system during live migration from on-premise to VMware Cloud on AWS. Results and conclusions are:
- Workloads were successfully live migrated from on-premise to VMware Cloud on AWS with no application errors. Impact to performance was more noticeable for a 3-tier system where the application and database servers were deployed in separate virtual machines and due to different sizes of the virtual machines – ended up split between the two environments for part of the time. A 2-tier system with the application and database server deployed in the same virtual machine, exhibited minimal performance degradation during migration.
- One of the benefits of VMware Cloud on AWS is hybrid mobility – ability to move SAP workloads with zero downtime between on-premise and cloud. During these migrations performance may be temporarily impacted, the extent of which depends on the workload and how the different services of the SAP system are distributed across virtual machines.
- Customers should test with their own workloads as mileage is expected to vary based on customer specific setups and workloads.
Thanks to my colleague Todd Muirhead for his reviews and edits.
