VMware Cloud on AWS is not supported for SAP workloads at this time.  Please stay tuned to https://twitter.com/vmwarecloudaws .

In this article we show an example sizing of an SAP landscape on VMware Cloud on AWS. The SAP landscape refers to the multiple SAP systems from production to non-production required in the implementation of SAP business functionality. A  VMware Cloud on AWS Sizer Tool is available online that allows us to estimate the compute and storage resources required for a SDDC deployment on VMware Cloud on AWS.  Before we can use this online tool, we need to establish the SAP sizing requirements. Here are two SAP scenarios:

  • Greenfield installation – treat the cloud SDDC as an on-premise vSphere implementation. We can following standard SAP sizing methodology e.g. SAP Quick Sizer.
  • SAP installations already running on vSphere on-premise – VMware tools are available for measuring existing resource usage. This is part of a migration assessment and is covered in the PREPARING FOR VMWARE CLOUD ON AWS Planning Guide .

The example here is based on a sizing of an existing on-premise installation.  The scope is for a non-production SAP NetWeaver landscape where we are sizing for SAP systems deployed on non-HANA databases (e.g. Oracle, Microsoft SQL server, SAP Sybase, IBM DB2, etc.) and we are considering CPU and memory overcommitment.

Overcommit is defined as:

  • The number of vCPUs scheduled on an ESXi host is greater than the number of physical cores.
  • The sum of configured memory of all virtual machines on an ESXi host is greater than the physical memory of the host.
Read moreProtecting Virtual SAP Landscapes with VMware vShield App – Part 1 of 2

We have chosen non-production as resource overcommit is more viable in this environment. The workloads across the different non-production systems are expected to peak at different times. Also, non-production environments are likely to have systems running idle for some periods of time.

We will first describe the sizing of the SAP landscape and the resource requirements for different virtual machines (VMs).  We then use this data as input to the VMware Cloud on AWS Sizer Tool to determine the SDDC resources required for VMware Cloud on AWS.

Because this is a sample scenario, variations and alternatives with higher or lower degrees of overcommit are possible.

SAP Sizing Results / Output

Read moreSizing Virtual Machines for JVM Workloads – Part 2

The example here is based on a non-production  SAP NetWeaver landscape and is derived from an actual sizing with some changes (e.g. not all SAP systems are shown).  The methodology of a virtual SAP sizing to determine the VM vCPUs and vRAM is not covered here – for an example see this whitepaper.

The non-production environment can include many different systems with various functions such as: development of new SAP functionality; support for production code fixes; future upgrade testing; training. The following table describes the different systems in this example.

To quantitatively size for overcommit, an initial priority (high, medium, or low) is assigned to each non-production system. The priority determines the probability/prediction of how much of the configured vCPU and vRAM the VM is likely to use. The priority and sizing impact are defined in the Appendix below.

Final SAP Landscape Sizing

The spreadsheet below shows the final sizing with adjustments made for overcommit based on the priorities of the different SAP systems. This spreadsheet is an example of a working sheet used in a pre-sales sizing engagement and variations are expected.

SAP Sizing Spreadsheet – Example

The columns in the spreadsheet above are described as follows:

  • “SAP Product / Module” – in this example we are sizing for three SAP products each of which has its own database, application servers and Central Services (handles special SAP services) : ERP = SAP Enterprise Resource Planning software; BW = Business Warehouse; Portal = SAP’s Portal solution. There are multiple installations of each SAP product across the different non-production environments.
  • “DB vCPU”,” App vCPU”, “CS vCPU” – these are the estimated vCPU requirements for each architectural component. This value is an output of the SAP sizing project (the method by which this was derived is not part of scope for this article). These components can be: all installed in the same VM ; or distributed across separate VMs.
  • “Total vCPU” = “DB vCPU” +” App vCPU” + “CS vCPU”
  • “VM Memory” – this is the estimated memory requirement for all the architecture components of each SAP product. This value is an output of the SAP sizing exercise.
  • “Example Priority” – priority assigned to the SAP system based on its business impact.
  • “Resource Adjust Factor” – probability of resources being used. This is based on the priority setting (see Appendix)
  • “ESXi Host cores” = ESXi host cores required to support the vCPU sizing = “Total vCPU” x “Resource Adjustment Factor”.
  • “ESXi Host Memory” = ESXi host memory required to support the memory sizing = “VM Memory” x “Resource Adjustment Factor”.

The totals at the bottom of the spreadsheet above allows us to estimate that we can support 122 vCPUs of VMs and 1220GB of total configured memory on a set of ESXi hosts that total 100 cores and 1000GB of physical memory. The total number of VMs = 24.

In this overcommit scenario, if all virtual machines try to consume 100% of their configured CPU and memory simultaneously, a performance issue may occur. VMware Cloud on AWS can address this with Elastic DRS (eDRS) – this is a feature that uses the resource management features of vSphere to analyze the load running in your SDDC to scale your clusters up or down. Using this feature, you can enable VMware Cloud on AWS to manage your cluster sizes without manual intervention.

The priority settings and adjustment factors shown here are examples only. They must be re-evaluated for specific implementations. For example,  if you expect high levels of simultaneous Development, Testing, and Training activity by a large team of external consultants and/or system integrators, who cannot afford idle time due to performance bottlenecks, you can justify assigning a high priority to several non-production systems thus reducing the degree of overcommit.

 We will now use the output of the above sizing spreadsheet to input data into the online VMware Cloud on AWS Sizer Tool.

 VMware Cloud on AWS Sizer Tool

The online tool is available here – click on “Start as a Guest” to start the sizing.  We will input the data from the above SAP sizing spreadsheet. For SAP we will use the i3 instance type which is based on ESXi hosts with 36 cores and 512 GB RAM.  The input data values are shown in screenshots below.

The tool provides the following output/ recommendation.

The sizing results show that with HA requirements factored into the final solution the total number of required ESXi hosts is 4. This results in a cluster with total 4 x 36 = 144 cores and 4 x 512 = 2048 GB of RAM i.e. the number of cores and memory in the SDDC cluster is more than the SAP sizing requirements. This is expected and is the same case when sizing and designing high availability SAP cluster environments on-premise.  Acceptable overcommit in this example will occur in the case of a host failure which is only temporary until a new host is provisioned. The time to provision a new host after a failure is quick in VMware Cloud on AWS due to the  auto remediation feature.  To increase overcommit more VMs can be added to the 4-host cluster but this could lead to unacceptable resource constraints (albeit only temporarily) in the case of a host failure. Adding more sandbox VMs that have a low SLA and do not need to be immediately recovered after a host failure will help to increase overcommit ratios without impacting SLAs during a host failure. Generally mixing high priority SAP VMs with low priority VMs in the same cluster enables overcommit. Applying the same overcommit method to production landscapes can be challenging as typically all production VMs are considered high priority. Mixing production with low priority non-production systems can yield overcommit scenarios without impacting SLAs. Production / high priority VMs are protected with memory reservation settings.

Key Points

  • A VMware Cloud on AWS Sizer Tool is available online that allows us to estimate the compute and storage resources required for a SDDC deployment on VMware Cloud on AWS.
  • We showed an example greenfield sizing for an SAP landscape based on overcommit of CPU and memory. The SAP sizing model included a method to quantitatively size for CPU and memory overcommit for non-production. We chose non-production as this is where we typically see overcommit for SAP environments.
  • Mixing high priority SAP VMs with low priority VMs in the same ESXi cluster facilitates overcommit.
  • We used the output of the SAP sizing as input to the VMware Cloud on AWS Sizer Tool which generated a recommendation for deployment on VMware Cloud on AWS.
  • Generally sizing of SAP environments is conservative with minimal to no overcommit. As workloads of different SAP VMs peak at different times the resulting utilization of ESXi clusters can be low. Elastic DRS (eDRS) available in VMware Cloud on AWS can scale clusters up or down to meet the resource needs.
  • Auto-remediation in VMware Cloud on AWS enables faster recovery of a SDDC cluster after a host failure.

In conclusion the VMware Cloud on AWS Sizer Tool can help you quickly determine the host and storage requirements for a SDDC deployment  and facilitate the transition to cloud for your SAP environments.

Thanks to my colleagues for their inputs and feedback: Dan Florea; Bill Roth; Gary Hamilton.

Appendix

The following table shows the priorities assigned to the different non-production systems and the sizing impact.

  • The Priority in the second column corresponds to an assessment of 1) the importance of each environment from a business standpoint and 2) the likelihood of resources being used by users.
  • The ESXi host Resource Adjustment Factor in the fourth column is linked to the priority and corresponds to an estimate of the fraction of resources that will be consumed. For example, a value of 0.75 corresponds to a prediction or probability that 75% of configured CPU and memory resources will be used.
  • The ESXi Host Sizing numbers in the last column are the number of physical ESXi host cores and memory required to support the environment. These resources equal the total virtual resources of vCPU and memory adjusted by the Resource Adjustment Factor (defined by the priority setting).

Note: The resource adjustment factor values in the table are suggestions.

Similar Posts