From May 17th to May 19th, SAP welcomed around 30,000 attendees to Orange County Convention Center in Orlando, Florida to its SAPPHIRE NOW conference and provided an overview on what’s new as well as what’s upcoming from SAP in 2016. As Bill McDermott, SAP CEO states during his keynote: “Run Live, Run Simple”!
Freely adapted from this motto, I am going to provide you an overview on what’s new form VMware in the SAP area to help SAP and it customers to make this motto real and what we have prepared and presented on our booth. Continue reading →
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.