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 part 2 we looked at storage, network and security design for the proposed customer environment. In part 3 we looked at monitoring & management, backup/recovery and disaster recovery for SAP S4/HANA. In this final part we look at validating the design we built over the past three parts and conclude the four part blog series.
SAP S/4HANA Design Validation
Validation of an SAP design is often difficult because of the absence of publicly available validation and performance tools. This design utilizes best practices derived from vendor testing conducted in SAP labs. The SAP HANA database tier is critical to the infrastructure and must be validated. So as part of this SAP S/4HANA VVD solution, some SAP standard validation tools were used to exercise the designed infrastructure.
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 part 2 we looked at storage, network and security design for the proposed customer environment. In this part we will look at monitoring & management, backup/recovery and disaster recovery for SAP S4/HANA.
SAP S/4HANA Monitoring and Management
Nearly every component of the IT stack contributes to application performance, which can make it challenging to identify the cause of issues when they arise. For many organizations, a lack of visibility can lead to mean-time-to-innocence hunts that waste time and create alert storms that drain the productivity of business teams. With a complex application such as SAP S/4HANA, performance issues can be even more difficult to specify because the application requires resources from the virtual environment, the network, and databases. However, integrating monitoring into a single console—such as VMware vRealize Operations Manager can provide visibility into SAP workloads and other IT relationships to impact performance.
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)
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 →
Choosing the right availability configuration for your SQL Server on vSphere can be a bit confusing as there are more than a few options to choose from, questions such as: Should I use vSphere HA if i’m using AlwaysOn? What are the implications of running different availability configurations on vSphere, and what are the best practices?
This very popular guide called “Microsoft SQL Server on VMware vSphere Availability and Recovery Options” which outlines the availability options and best practices for SQL Server on vSphere and tries to answer these question, is now updated with the latest information.
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.
Microsoft SQL server is the most virtualized enterprise mission critical application today. In recent years it has become a mainstream effort among VMware customers to virtualize critical databases to allow better agility and scale while increasing availability and operational efficiency.
This guide, now named “Architecting Microsoft SQL Server on VMware vSphere – Best Practices Guide” to reflect its focus on architecture and configurations of vSphere as well as SQL server for maximizing the benefits of virtualizing SQL server, is aimed at providing VMware customers and partners guidance on how to achieve best performance and efficiency with the latest versions of Microsoft SQL server and VMware vSphere.
In this guide there are also references to other VMware and third-party documents which we encourage the reader to consult for better understanding of the topics discussed.