Category Archives: SAP

New Updated Oracle Databases on VMware Best Practices Guide

Business Critical Applications (BCA) are at the heart of an organization; their performance, availability and reliability are vital to the success of the business. Significant advances in hardware are far outpacing the performance requirements of even the most intensive business-critical applications, including Oracle Database.

VMware has kept pace with these hardware improvements by engineering significant performance advances in vSphere 6.0. Best Practices are key in ensuring that business SLA’s, uptime, QoS are met with when deploying Oracle on VMware vsphere.

Successful virtualization of any Business Critical Application (BCA) required best practices inculcated in every layer of the stack.

We are pleased to announce the updated version of the “Oracle Databases on VMware Best Practices Guide” which can be found in the below URL. Thanks to everyone who participated in this exercise

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.

Click here to download the guide.

VMware at SAPPHIRE NOW 2016 Recap

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

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 does not describe how to perform the actual SAP HANA system RAM sizing. For this please refer to the SAP documentation. A good start is to 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.

In the soon to get published new “Architecture Guidelines and Best Practices for Deployments of SAP® HANA® on VMware vSphere®” document, which will be available on, I have detailed sizing formulas specified, which I have defined jointly with SAP. The formula respects hyperthreading with a performance gain of 15% and the used CPU type (amount of available cores), virtualization memory costs and can get used also to calculate the needed vCPUs to support a certain amount of HANA RAM.

Instead of using these sizing formulas, I will explain a simplified way how to size production level ready SAP HANA VMs.

Since we want to leverage hyperthreading, it is required to enable it on the host and that the VMs get configured with the parameter Numa.PreferHT=1. Using this parameter ensures NUMA node locality and forces the ESXi scheduler to use hyperthreads instead of potentially idle cores on other NUMA nodes.

More detailed explanations will be available in the referred VMware SAP HANA guide. As well as storage and network sizing and configuration information.

VMware vSphere SAP HANA relevant Sizing figures

Before we start to size SAP HANA VMs, we have to discuss the current vSphere compute resource maximal sizes and define the current sizing limitation for memory. This limitation is important to understand when sizing a BWoH system on vSphere, as the CPU VM limitation of vSphere 6 of 128 vCPUs will not allow to utilize the theoretical maximum of 4080 GB per VM. Reason is that SAP has defined specific CPU socket to RAM ratios, which are more demanding for an analytical workload like BW. For OLTP like applications like SoH this ratio is higher and here we could size larger memory sizes as even vSphere supports (see below table)!

The table enumerates the current maximal sizing figures for virtualized SAP HANA systems on vSphere. Please note that these figures represent the theoretical sizing maximal sizes and should get aligned after some time to the real live SAP HANA configuration, as you may have less CPU resource need and would therefore be able to increase the memory beyond this theoretical sizing figures. If more VMs get installed on a server or when a single VM will consume the complete available RAM, then also RAM for vSphere has to get reserved. We calculate 1 percent up to 3 percent for vSphere. This depends on the actual VM configuration.

CPU Scale-Up Workload SPS version vSphere Version Maximal “theoretical sizing” RAM size1 Maximal VM size
Haswell Intel Xeon E7-v3 SoH SPS >= 10 5.5 2374.49 GB 64 vCPUs, 1024 GB vRAM
SoH SPS >= 10 6.0 4748.99 GB 128 vCPUs, 4080 GB vRAM
BWoH SPS >= 10 5.5 1582,99 GB 64 vCPUs, 1024 GB vRAM
BWoH SPS <= 10 6.0 3165,99 GB 128 vCPUs, 3072 GB vRAM
BWoH SPS >= 11 6.0 3165,99 GB 128 vCPUs, 3166 GB vRAM

1This is a theoretical sizing maximal figure and got calculated with the referenced sizing formula as documented in the “Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere” document, which will available on www.vmware/go/sap-hana.

The figures in above table are relevant when for instance an 8-socket server should get used for a maximal sized virtualized SAP HANA BW system. The RAM sizing limitation should get seen as the first start to size the VM and the RAM may get aligned, after consulting SAP HANA support and sizing teams, to the actual server usage and CPU utilization.

Continue reading

Top Ten things to consider when moving Business Critical Applications (BCA) to the Cloud (Part 3 of 3)

In the first part we looked at public, private and Hybrid Cloud and their characteristics. In this part we will look at the common characteristics of business critical applications. In the second part , we looked at how some of these characteristics relate to the different types of Cloud infrastructure. In this final part we will look at he lifecycle of a business critical application in the cloud and the conclusion. Continue reading

Top Ten things to consider when moving Business Critical Applications (BCA) to the Cloud (Part 2 of 3)

In the first part we looked at public, private and Hybrid Cloud and their characteristics. In this part we will look at the common characteristics of business critical applications. We will also look at how some of these characteristics relate to the different types of Cloud infrastructure.

Common Characteristics of Business Critical Applications (BCA):

Business critical applications typically have very stringent SLAs and have a direct impact on the business. These are the crown jewels of the business that need to be managed with utmost care to avoid loss of productivity, data and potential revenue. These are the major factors can have a direct impact on these applications such as the following:

Continue reading

Top Ten things to consider when moving Business Critical Applications (BCA) to the Cloud (Part 1 of 3)

The cloud transformation is now for real. Customers have a stated long-term goal of running a majority of their applications in the cloud. Gartner predicts that public cloud services to grow by 16.5% in 2016. The highest growth area is cloud infrastructure, which is projected to grow at 38.4% in 2016. Today’s CIOs understand that a clear cloud strategy is a critical component of managing their information technology needs.

While developers have adapted to the cloud and its benefits, traditional enterprise business critical applications are not very prevalent in the cloud. Until recently most of these applications had not even been virtualized. Just in the past two to three years a majority of these enterprise applications have been virtualized. What are the unique characteristics of these applications that need to be considered for cloudification? In this three part blog series, we will analyze the top ten BCA requirements and how different types of cloud infrastructures satisfy them. In part 1 we will look at the different types of cloud infrastructures and their characteristics. Continue reading

Updated for vSphere 6 – SAP on VMware Best Practices guide

SAP production support for vSphere 6 was available from the latter half of last year – see . The best practices guide has been updated with the latest vSphere 6 information to help you with virtualizing SAP. Some of the new content includes:

  • Estimating SAPS of virtual machines and how this is aligned with ESXi scheduling behavior.
  • Updated analysis of high availability options for SAP in the virtual environment. This includes the use of VMware Fault Tolerance for SAP Central Services installed in a multi-vCPU virtual machine.
  • A section where all the best practices are summarized and categorized by different topics (CPU, memory, high availability etc.). For those already familiar with the vSphere concepts and use cases just skip to this section.

Certain topics like HANA and Business Objects have separate papers dedicated to them – these are referenced and the content is not repeated in this document.

The paper is available for download here.

Harnessing the Power of Storage Virtualization and Site Recovery Manager to Provide HA and DR Capabilities to Business Critical Databases – VAPP4634

Harnessing the Power of Storage Virtualization and Site Recovery Manager to Provide HA and DR Capabilities to Business Critical Databases – VAPP4634

How do you simplify and improve availability of your Extended distance Oracle Real Application Cluster using vSphere Metro Storage Cluster (vMSC) ?

Storage Virtualization, both host based and appliance based, can pave the way for increased ease of configuration and improved availability of your cluster based applications. vMSC features including vMotion, HA, DRS and FT as well as extended distance Oracle Real Application Clusters (RAC) are greatly simplified, and in some cases, made possible through the use of storage virtualization technologies such as EMC VPLEX, Netapp Metro Cluster, IBM SVC, HP 3PAR Peer Persistence , VMware vSAN or Oracle Automatic Storage Management (ASM) disk groups.

Site Recovery Manager with Oracle Data Guard can provide the much needed Disaster Recovery component thereby providing a complete HA and DR solution to Business Critical Databases

See where and how virtualized storage provided by above storage virtualization vendors and ASM are most effectively used to help protect your business critical applications virtualized on vSphere.

See how one Global 1000 company used storage virtualization to achieve 0 second RPO and 5 second RTO.

Details on the solution will be discussed in detail at VMworld 2015 Barcelona in session VAPP4634:

Harnessing the Power of Storage Virtualization and Site Recovery Manager to Provide HA and DR Capabilities to Business Critical Databases (VAPP4634)
Thursday, Oct 15, 12:00 PM – 1:00 PM – Hall 8.0, Room 38

Sudhir Balasubramanian – Senior Solution Architect – Data Platforms, VMware
Marlin McNeil – VMWare Partner, Yucca Group

Virtual Volumes: A game changer for operations of virtualized business critical databases

This is first of a series of posts on deploying vSphere Virtual Volumes for Tier 1 Business Critical Databases. Although this article is written with a focus on Oracle databases, much of this discussion holds good for any Mission critical application.

Business critical databases are among the last workloads virtualized in enterprises, primarily because of the challenges that they pose with growth and scale. Typically the low hanging fruits are virtualizing the Development, Testing/QA, Staging databases after running a successful POC and then moving on the big guy’s i.e. the Production databases.

There are many common concerns about virtualizing business critical databases that inhibit and delay virtualization of these workloads:

  • Business critical virtualized databases need to meet strict SLAs for performance and storage has traditionally been the slowest component
  • Databases grow quickly, while at the same time there is a need to reduce backup windows and their impact on system performance.
  • There is a regular need to clone and refresh databases from production to QA and other environments. However, the size of the modern databases make it harder to clone and refresh data from production to other environments
  • Databases of different levels of criticality need different storage performance characteristics and capabilities.
  • There is a never-ending debate between DBAs and Systems administrators regarding filesystems VS raw devices and VMFS VS RDM. These are primarily due to some of the deficiencies that existed in the past with virtualization.

Continue reading