I would like to give credit to Andy Silvey for animating me to write this post and my colleague Vey Gereon who helped me with the content. Some parts of this document are taken from the new IBM Redbook: SAP In-Memory Computing on IBM eX5 Systems
There has been quite some announcements regarding SAP HANA Virtualized recently. IBM has taken some very important steps forward by providing now to all customer the possibility to use VMWare for Virtualizing non-Production Environments of SAP HANA. The advantages for the customer are multiple:
- better use of the SAP HANA Hardware (run virtualized non-production / Dev)
- being able to “reinstall” a HANA Instance for non-production using the VMWare Tools, thus gaining time and using less resources
- be able to partition a 512GB Machine into instances ranging from 64GB to 384GB
How does this all look like and what are the options?
The SAP HANA Platform Edition can be installed inside of a VMware virtual machine starting with Service Pack Stack (SPS) 05. The SAP HANA Virutalization FAQ states that SAP allows multiple virtual machines to be installed using a concept of slots.
Each slot is a virtual machine created with 10 virtual CPUs (vCPU) and 64 GB memory. The standard rules for operating system, SAP HANA Data and Log file system sizes are to be held. Due to resources taken by the VMware ESXi server itself, one slot is by SAP definition reserved as no CPU/Memory overcommitment is allowed in an SAP HANA virtual machine.
This defines a maximum number of 15 slots available on the IBM System x3950 X5 Workload Optimized system for SAP HANA appliance, and a maximum of 3 on the IBM System x3690 X5 Workload Optimized system for SAP HANA appliance.
Table 2 shows the configuration parameters for virtual machines from slot sizes 1 to 8. Sizes 7 and 8 are not supported by VMware due to the restriction of a maximum number of vCPUs per guest of 64 in their latest VMware ESX server software. You may install one or more virtual machines of slot sizes 1 to 6 on any IBM System x3950 X5 Workload Optimized solution for SAP HANA appliance. The maximum number of slots available per system are defined in Table 1.
It is important to consider the licensing of VMWare VSphere.
For the deployment of SAP HANA on VMware vSphere, the number of supported virtual CPUs (vCPU) per virtual machine (VM) is the most importand difference within the set of supported features:
- The Standard edition supports up to 8 vCPUs per VM, which is below the number of vCPUs of the smallest SAP HANA VM size. Therefore this edition cannot be used
- The Enterprise edition supports up to 32 vCPUs per VM, and can be used for SAP HANA VMs with up to 30 vCPUs and 192 GB virtual memory. This edition may be a cost-saving choice when deploying only smaller SAP HANA VMs, e.g. for training or test purposes.
- The Enterprise Plus edition supports up to 64 vCPUs per VM, and thus can be used for SAP HANA VMs with up to 60 vCPUs and 384 GB virtual memory, which currently is the maximum supported VM size. VMware vSphere is licensed on a per-processor basis. Each processore on a server has to have a valid license installed in order to be able to run vSphere.
As an example, if you want to deploy SAP HANA on an M (512GB) building block, you would need 4 licenses.
Further Considerations are to be made for
The sizing is the same for virtualized and non-virtualized SAP HANA deployments. While there will be a small performance impact due to the virtualization. The database size and therefore the required memory size is not affected.
As with any other deployment type of SAP HANA, customers are asked to open an SAP support ticket, leveraging the integrated support model Any non-SAP related issue will be routed to VMware first, before it eventually gets forwared to the hardware partner. In certain, but rare situations, SAP or its partners may require to reproduce the workload on bare metal.
Supporting non-production SAP HANA Environments with VMWare further lowers any possible entry barriers for HANA. Eventhough it is a general recommendation that the Production System and the QA system should be as similar as possible this solution will allow many customers to provide in an easy and cost effective way QA and Development environments.