Tag Archives: SAP HANA

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 2/4)

In part 1 we introduced the concept of SAP HANA Application Workload guidance and using example business requirements to come up with a workload and vSphere cluster design for the SAP environment. In the second part we will look at storage, network and security design for the proposed customer environment.Availability Design

The availability design depends on the single point of failure (SPOF) analysis of components. There are components in the SAP infrastructure that are one of a kind and are potential SPOFs; other components are capable of having multiple instances for load balancing and availability.

Continue reading

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 1/4)

SAP Business Suite 4 SAP HANA (or SAP S/4HANA) is the SAP Business Suite that is built on SAP’s in memory columnar database platform SAP HANA. SAP HANA®, the in-memory real-time platform, was initially introduced as a physical appliance and has steadily evolved to include support for virtualization with VMware vSphere® and SAP HANA tailored data center integration (TDI). Virtualized SAP HANA is now supported in scale-up and scale-out configurations in VMware® environments. Running SAP HANA on vSphere offers customers agility, resource optimization, and ease of provisioning. This solution enables SAP customers to provision instances of SAP HANA more quickly and effectively by using vSphere virtual machines (VM). Using the SAP HANA platform with the vSphere virtualization infrastructure constitutes an optimized environment for achieving a unique, cost-effective solution. VMware capabilities such as VMware vSphere vMotion®, VMware vSphere Distributed Resource Scheduler™ (vSphere DRS), and VMware vSphere High Availability (vSphere HA) are inherent components of the virtualized SAP HANA platform.

The need exists for a comprehensive, “end-to-end” solution that describes the implementation of a virtual SAP HANA deployment. VMware Solutions Labs was chosen to first develop a robust validated end to end solution. This is the first solution that takes the VMware Validated Design concept and then uses its components to run an Enterprise application like SAP on top of it. This prescriptive approach called Application Workload Guidance Design applies the VMware Validated Design (VVD) to SAP S/4HANA on the vSphere platform.

Continue reading

SAP HANA on VMware vSphere, Multi-VM Support Status as of May 2017

Since my last SAP HANA blog in February, our SAP HANA validation and engineering team was busy performing the remaining validation test on the Intel Broadwell platform.

Because of the positive results, SAP granted us Multi-SAP HANA VM and NUMA node sharing support for vSphere 6.0 and 6.5 on the 4 socket Intel Broadwell platform up to 4 TB VM sizes.

By now we have five SAP support notes that describe the support status of SAP HANA on VMware vSphere. This blog concentrates on Multi-VM configurations. For a complete overview of what is SAP supported please visit the SAP HANA on VMware vSphere Wiki pages on wiki.scn.sap.com.

The first table in this blog shows the SAP HANA Multi-VM configuration status and what is supported in production. The 2nd table shows what is VMware platform supported, but was not explicitly validated for SAP HANA workloads.

Continue reading

VMware Adapter for SAP Landscape Management 1.4.1 – Automate and manage your VMware virtualized SAP Landscape

On behalf of David Gallant, ISBU, Product Management and the Integrated Systems Business Unit, we are very pleased to announce the General Availability of VMware Adapter for SAP Landscape Management 1.4.1.

VMware Adapter for SAP Landscape Management integrates SAP Landscape Management (LaMa) with VMware Software-Defined Data Center (SDDC) technologies, allowing SAP BASIS administrators, VMware administrators, SAP project and business stakeholders to automate provisioning and management of SAP landscapes running on VMware’s SDDC. The adapter is a key component of VMware private cloud solution for SAP, which defines the software stack to virtualize, secure and automate SAP environments leveraging VMware’s software-defined architecture. At its core, it includes VMware vSphere, VMware NSX, vRealize Automation and the VMware Adapter for SAP Landscape Management and will help to bring SAP Consumers closer to IT Providers, by leveraging for instance an optional service portal to perform SAP system deployments and management tasks instead of using administrator and system tools.

Below figure shows how providers and consumers can leverage the VMware Adapter for SAP Landscape Management.

VMware Adapter

This release of the adapter is a very important maintenance release. With this release, we continue to enhance support for vRealize Automation and the system automation application interface (SA-API).  These enhancements pave the way for additional customers to adopt SAP LaMa, and VMware’s SDDC.

Continue reading

Multiple production SAP HANA virtual machines on a single physical server on vSphere 6

Last week we finished the Multi SAP HANA VM and NUMA Node Sharing (CPU socket sharing) tests with vSphere 6. Due to the good results, SAP granted full production level support for multiple SAP HANA systems deployed on a single SAP HANA certified server virtualized with vSphere 6.

With this, customers can get now better TCO results by SAP HANA system consolidation and better utilizing their hardware assets.

For details please review SAP note 2315348 – SAP HANA on VMware vSphere 6 in production.

What is allowed by now with vSphere 6?

  • Consolidation of multiple SAP HANA production level VMs on a single SAP HANA certified server based on Intel Xeon E7-v3 (Haswell).
  • Possibility to share a NUMA node with two production level SAP HANA VMs. Example: 4 socket Haswell server is now able to support up to 8 SAP HANA VMs, and an 8 socket Haswell based server supports up to 16 SAP HANA VMs in production.
  • SAP HANA sizing rules must get applied and followed.
  • When sharing a NUMA node minimal 8 CPU cores (16 threads) must get assigned to the VMs, RAM must get assigned accordingly the latest SAP HANA sizing rules.
  • Enough network and storage IO capacity must be available for all running production SAP HANA VMs (SAP HANA TDI storage KPIs).
  • Enable VMware HA to protect the consolidated SAP HANA workload and ensure that enough failover capacity is available in the vSphere cluster.

What is not allowed as of today with vSphere 6?

  • No Intel E7-v4 (Broadwell) based system and vSphere 6.5 support. Validation and tests are ongoing but not finished.
  • Running more than two SAP HANA VMs on a single NUMA node (CPU socket)
  • Over-subscription of CPU and RAM resources

 

New Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide, now available!

I am happy to announce that after a very long review and publication cycle the “Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide” is now published.

The guide can be downloaded from our central VMware SAP page.

Direct link to the document: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/sap_hana_on_vmware_vsphere_best_practices_guide-white-paper.pdf

The chapter on sizing tackles the complex subject getting HANA VM’s sized properly, and provides incredible value to the reader as it provides guidance that explains how to size beyond physical to virtual so your organization can get it right the first time, every time.

Building a virtual SAP HANA VM requires to know not only the needed RAM, but also the number of needed CPUs to support this RAM. Without this information, it is not possible to create a VM.

The sizing guidelines published in this guide follow the SAP currently requested CPU socket / CPU core to RAM ratios or, when available describe how to perform a SAPS sizing. Using these guideless will provide you with SAP supported VM configurations.

I will provide some additional sizing examples that focus on SAPS and vCPU sizing, in addition to the already provided “NUMA” node based sizing example. Please remember, primary sizing figure for SAP HANA is memory and CPU is second and a SAP HANA configuration is optimized to optimal memory performance with lowest latency.

SAP HANA on vSphere 6.x on Intel Xeon Broadwell – now supported!

Just on time for SAP TechED 2016 in Barcelona, I am happy to announce that we have finished the vSphere 6.x SAP HANA on Intel Xeon Broadwell CPU certification!

With this all SAP supported or certified SAP HANA Intel Xeon Broadwell based systems can get virtualized and can run SAP HANA VMs with up to 4 TB of vRAM.

For details please review SAP note “2315348 – Single SAP HANA VM on VMware vSphere 6 in production” and 2393917 – Single SAP HANA VM on VMware vSphere 6.5 in production or our SAP HANA on VMware vSphere WIKI page. Continue reading

SAP HANA on vSphere – Support Status and Best Practices Summary

Since SAPHIRE 2016, SAP supports now also SAP HANA on vSphere 6 deployments for production workloads, see SAP Note 2315348 for details.

The support for vSphere 6 allows customers to increase the RAM to up to 4 TB (4080 GB) of existing virtual SAP HANA systems when migrated to vSphere 6 and allows to react on increased memory needs due to data growth or newly deployed SAP HANA scenarios and solutions.

Beside increased RAM sizes vSphere 6 supports also more vCPUs. Up to 128 vCPUs can now get configured and used by a single SAP HANA VM.

Supporting more physical compute resources inside a VM ultimately provides more “power” to a virtualized SAP HANA system – this alone is worth upgrading from a vSphere 5.5 to a vSphere 6.0 based SAP HANA environment. Beside this, all vSphere 6.0 features can get used as before with vSphere version 5.5. Continue reading

SAP HANA on VMware vSphere – Sizing (Compute)

This is the second blog of my SAP HANA on vSphere blog series and will provide information on SAP HANA on VMware vSphere compute resource sizing. This blog got updated on November 23rd 2016 to include the Intel Xeon Ex-v4 CPUs (Broadwell), which are now supported.

Sizing SAP HANA database starts with the determination of the database size. This can get done either by using the SAP HANA Quick Sizer application (new system), or by running a specific SAP HANA sizing report (existing systems), as documented in SAP note 1872170 (S4/HANA) and SAP note 2296290 (BW).

Beside determining the database size of HANA that will get operated in RAM, it is also necessary to size the needed resources for the application server stack. This can get done by using he SAP HANA Quick Sizer as this tool will provide the necessary system configuration required for the application part of a SAP HANA based business application.

This blog does not describe how to perform the actual SAP HANA system RAM sizing, for this use above tools and methodes. For details read the sizing SAP HANA Sizing Approaches presentation, which describes the SAP HANA QuickSizer and ABAP SAP HANA sizing reports available for sizing SAP HANA systems. Also a good start is the Sizing Approaches for SAP HANA document. (Attention you may require a SAP SDN account to access the SAP HANA sizing documents).

CPU and RAM Sizing SAP HANA on VMware vSphere

Sizing SAP HANA is different from sizing a classical SAP application. Instead focusing on CPU resources, for SAP HANA memory is the focus and how many CPU resources are required to support a specific amount of RAM. Beside this, we have to consider the different CPU and RAM maximums of vSphere 5.5 and 6, as it defines the maximal size of a virtual SAP HANA VM. To make it even more complex, we have to take into account which workload (SoH or BWoH) will run on the selected SAP HANA system, which CPU and which HANA SPS version will get used, as different CPU socket to RAM ratios exist for all of these combinations.

Continue reading