Sizing for SAP HANA
Introductory video of SAP HANA in the sizer (non-ST VPN connection required).
Note:
- Only use for SAP HANA based applications, not legacy SAP applications which make use of MSSQL, Oracle etc.
- Multi-node SAP scale-out is not supported (used for larger SAP BW instances)
- This sizing process does not vary for scale-up between AHV & VMware implementations
- No spinning disks are used within a Nutanix cluster being used for SAP HANA
- Any questions, support, or areas not covered – please use the SAP Slack channel
Supported Platforms:
- Only Dell, HPE, Fujitsu and Lenovo are supported for SAP HANA, not NX.
- If another OEM is selected, SAP HANA will not be shown as an available workload
Defaults
- RF2 is used (RF3 is under testing, so not selectable in Sizer)
- Compression is disabled, and not typically of value for SAP HANA
- Higher default CVM resource is reserved
HANA Inputs
- NVMe can be added for higher IO loads, such as a high usage SAP S4/HANA
- Cost/Performance largely drives cpu choice. Ideally an implementation’s potential compute load in SAPS would be known. Please reach out for support in estimating and reviewing such information.
Environments
There would typically be two environments within a Nutanix cluster where production and non-production are mixed. Production rules should be applied both to all production instances, and any other instances that should be treated as production. This might apply to a QAS/Test environment and will typically apply to any DR cluster.
Production:
- For most SAP applications (e.g., production S4) there is an SAP HANA database, and one or more application server instances. Some uses of SAP HANA do not use an application server, in which case just use a small one in the sizing exercise.
- In addition to the Application Server instances, and the SAP HANA database, a small VM called the ASCS is often called for. This ASCS would be around 2c/24GB RAM/100GB disk.
- Generally, production has two or more application server instances. Typically, 2 – 6 cores, with around 24GB/core. Multiple instances for larger loads. Small storage space requirement for os & application image.
- For a downtime requirement of less than 20 minutes, a pair of SAP HANA instances should be sized.
- There is no over commit of cpu or memory
- Servers must have all memory channels filled and balanced, so 6 or 12 DIMMs per cpu. – Sizer auto recommendation enforces this consideration
- L suffix cpus are required for largest memory instances
- Available storage for SAP HANA should be around 2.5x to 3x memory (3x is used in Sizer)
- Production rules – SAP HANA instances are on whole dedicated cpus and so cannot be allocated to the CVM cpu
- HANA System Relication(HSR) – is exactly a copy of the HANA VM. In Sizer, add another HANA VM if implementing the HSR.
Non Production:
- QAS/Test landscape tends to match nonPRD for size of instance
- If an operating system HA cluster is used in production, there is typically at least one such cluster outside of production also – used as a testbed.
- Each SAP solution would normally have two or three non-production landscapes
- Solution Manager (SolMan) is often overlooked, and not asked for. It is a required instance in the overall deployment and would be sized in PRD with one SAP HANA instance and an application server instance. Another such pair for QAS/test. No HA clustering would be required.
- DEV, SBX etc. are usually subsets in memory size.
Feb 8, 2021
First release of SAP HANA in the sizer:
- Tendency to move to four socket servers when two socket my suffice.
- You may observer this , however, this would largely be because of the DIMMs cost considerations between a 24x64GB and 48x32GB
- Please review all sizings with an SAP specialist. More details here : https://confluence.eng.nutanix.com:8443/pages/viewpage.action?pageId=35204585