Home > Blogs > Virtualize Business Critical Applications

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.

The major VMware announcement during SAPPHIRE NOW 2016? That would be our vSphere 6 – 4 TB SAP HANA support statement, which got released by SAP on May 17th! Check out SAP Note 2315348 for details.


With these announcements, customers can now instantly take advantage the larger VM sizes vSphere 6 provides (128 vCPUs and 4 TB of vRAM). Now, the majority of all SAP HANA customers can virtualize SAP HANA and use the same IT processes and datacenter standards they have developed during the last years when started their SAP application virtualization journey.

But was this all what VMware had to show and announce? Definitely not! Let’s do a walkthrough of the VMware booth and learn everything else we have prepared and presented during SAPPHIRE NOW.


The first demo station I want to talk about is our Virtual SAN demo station. Here, we have prepared a real live demo of 4 hyper-converged SAP systems running on vSphere, Virtual SAN and a very dense HCI system from Dell.


The system shown in the picture had four 2-socket server systems with internal storage devices configured as an All-Flash Virtual SAN, from which we have run a IO load demo of several SAP database servers. Some benefits running SAP applications on such an environment are for instance following:

  • Radically simple and cost efficient storage
  • Storage polices instead of fixed storage configurations
  • High performant and scalable storage that grows when new server systems get added to a Virtual SAN cluster.

Currently, Virtual SAN can get used for all classic SAP applications. As of today, SAP HANA is not supported, even if we would meet the performance storage KPIs demanded by SAP for SAP HANA TDI storage configurations.

This picture of a Virtual SAN presentation summarizes how Virtual SAN will change managing storage…


For more information on virtual SAN please refer to following SAP SCN blog, VMware blog or solution overview paper.

The next station is our “Automation” station. Here, we are demonstrating so-called “Day Zero, One and Two” scenarios to reduce TCO and to improve your IT agility to enable SAP’s vision “Run Live, Run Simple” as stated by Bill McDermott.


Beyond our vRealize Automation (vRA) workflows, we also showcased our SAP Landscape Virtualization Manager (SAP LVM) integration that allows life cycle management of a complete virtualized SAP landscape, including SAP HANA.

The picture blow shows a SAP LVM based copy operation fully leveraging a VM based E2E copy process.


The vRA workflows we demoed included a full automated SAP HANA database and S4/HANA installation from scratch and workflows to migrate a SAP HANA Scale-Up configuration automated to a Scale-Out configuration and to upgrade an existing SAP HANA instance to a new SAP HANA release.

The figure shows the vRealize Automation Services Catalog we have build as demo workflows for SAP HANA. Workflows for any other SAP based application and solution would be possible.


The next figure shows the steps needed for an automated SAP S4/HANA installation workflow.


Last, but not least, we presented our Enterprise Secure Mobility Platform and Content management solution AirWatch and how we have integrated SAP SuccessFactors Solutions into an AirWatch managed secure environment.

IMG_5627 IMG_5628

White board sessions that covered different aspects of SAP HANA on vSphere sizing or comparison of different flash devices got also done beside well received booth theater presentations from our partners, like shown in the picture below, from SUSE.

IMG_5641  IMG_5626

With this, I want to finish this short summary of our SAPPHIRE 2016 presence and hope you got a good impression what we have presented and that VMware is more then virtualizing compute. It’s all about software and digitalizing all aspects of a datacenter and beyond. From SAP Client over the Datacenter to the Cloud, as below picture illustrates.


…and as the sticker below suggests, ask as about SAP HANA on vSphere!


Below is a short video I have done during the show to give you a better impression of your booth and what we have presented. I hope you have fun watching it and that you follow me through our booth!

Additionally, we also took some other videos at the VMware booth during the conference!

The video below showcases a customer speaker at the VMware booth at SAPPHIRE NOW 2016 – here, Frank Olszewski of HD Supply talks about virtualizing SAP landscapes from a customer perspective.

In this next video, Tom Herrmann, VP of Strategic Alliance Division at VMware, overviews the VMware SDDC strategy, the Partner Ecosystem, as well as the SAP relationship with VMware.

For more blogs around SAP HANA and SAP on VMware:

http://scn.sap.com/docs/DOC-27384, http://scn.sap.com/docs/DOC-70528, http://scn.sap.com/docs/DOC-60470, https://blogs.vmware.com/apps/author/erik_rieger

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.

Since SAP HANA requires a specific sizing method, and as of today not all deployment options are yet available for vSphere 6 deployed SAP HANA systems, I will provide a series of blogs to provide some details to allow you a smooth start with SAP HANA on vSphere. This is the first blog of this series.

This blog contains information on:

  • What’s supported
  • Which deployment options can get used with which vSphere version
  • A summary of the best practices, like minimal vCPU count for non-prod SAP HANA VMs

In other blogs you will read about:

  • VMware SAP HANA virtualized sizing
  • Guidelines on how to migrate form vSphere 5.5 to vSphere 6 and interoperability of vSphere 5.5 and 6 host systems for SAP HANA.
  • SAP HANA on non-production environments
  • Business Case for virtualizing SAP HANA

Stay also tuned for the soon available 100+ page “Architecture Guidelines and Best Practices for Deployments of SAP® HANA® on VMware vSphere®”, which will available on www.vmware.com/go/sap-hana

Continue reading

Updated – Microsoft SQL Server on VMware vSphere Availability and Recovery Options

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.

Download the guide here

As always, any feedback is welcome,


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 www.vmware.com/go/sap-hana, 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

vRealize Automation 7 converged blueprints

vRealize Automation 7 feature a new Blueprint format. A converged blueprint can have one to many components including:

  • Machines : vCenter, vCloud Air, vCloud Director, Amazon, KVM, Openstack, Citrix Xen, HyperV, SCVMM
  • Network & Security: Security Group, Load balancer, NAT, Routed networks.
  • Software (Install, configure, start, uninstall) : Scripts to setup the OS or to install and configure applications
  • XaaS : Workflows (I.E virtual machine customization, guest operations)

Combining these allow designing complex applications.

For example using the vRealize Automation design canvas you can put together a multiple instance machine to deploy cluster nodes with an XaaS components to create shared disks and software components to install and configure the Operating System, and application layers.

vRAblueprintClustered application in vRealize Automation 7 design canvas

All these components are bound together via data bindings that will determine the parameters flow and deployment order.

While you can design your application from scratch being able to leverage community blueprint will save you a lot of time learning from other community members designs, and application scripts.

VMware Sample Exchange is a VMware and community content repository. From this site you can download sample code, automation scripts, Orchestration workflows and also vRealize Automation 7 application Blueprints. You can also create your own content and upload it to sample exchange to share it with the community.

At the moment there are about a dozen application blueprints available with new ones uploaded in a regular basis.

A blueprint is a YAML formatted file packaged within a zip file that can be downloaded with your browser. For importing it in vRealize Automation VMware provides a command line tool called vRealize CloudClient.

There is also a more convenient way to import Sample Exchange blueprints directly from the vRealize Automation service catalog with using a workflow I have released on the vRealize Orchestrator community.

importFromSampleExchangeRequesting to import a blueprint from Sample Exchange

With all these new capabilities integrated in vRealize Automation 7 you have the ability to design, publish and exchange advanced application blueprints.

To know more about designing a vRealize 7 application blueprint you can check this video.

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

Demo – Dynamically Enforcing Security on a Hot Cloned SQL Server with VMware NSX

VMware NSX is a software defined solution that brings the power of virtualization to network and security.VMware NSX

There are many great papers about NSX in general: for example here & here and many others, the purpose of this demo is not to dive into everything that NSX does, Instead I have focused on one capability in particular and that is the intelligent grouping of NSX Service Composer with the Distributed Firewall (DFW) and how to utilize it to make life easier for SQL DBAs and security admins, its doesn’t have to be only SQL Server, it can be any other database or application for that matter but for this demo I am focusing on SQL Server.

First, a bit of background: The NSX Service Composer allows us to create groups called “Security groups”. These Security groups can have a dynamic membership criteria that can be based on multiple factors: It can be part of the computer name of a VM, its guest OS name, the VM name, AD membership or a tag (tags are especially cool as they can be set automatically by 3rd party tools like antivirus and IPSs, but that is for a different demo)

These Security groups are than placed inside the Distributed Firewall (DFW) rules which allows us to manage thousands of entities with just a few rules and without the need to add these entities to the Security Group manually.

In the demo I have created an environment that is set with 0 trust policy, that means that everything is secured and every packet between the VMs is inspected, the inspection is done on the VMs vNIC level in an east-west micro segmentation way. That means that if a certain traffic is not defined in the DFW it is not allowed to go through.

This is something that wasn’t really possible to do before NSX

Our production app database is an SQL database and in the demo the DBA wants to hot-clone it aside for testing purposes, but obviously the cloned SQL Server needs to have some network traffic allowed to pass to it, yet it needs to be secured from everything else.

Instead of having the traditional testing FW zone with its own physical servers, I created the rules that apply to a test DBs in the DFW, created a dynamic membership Security Group, and nested that group in the rules. Now, any database server that I will clone which corresponds to the criteria will be automatically placed in the rules.  What’s really nice about this is that no traffic is going northbound to the perimeter FW because the packet inspection is done on the vNIC of the VMs (and only relevant rules to it are set on it) , no additional calls to security admins to configure the FW are needed after the first configuration has been made. This is a huge time saver , much more efficient in terms of resources (physical servers are now shared between zones) and a much more secure environment than having only a perimeter FW.

As usual any comment or feedback is welcome




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: Microsoft SQL Server on vSphere Best Practices Guide

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.

Click here to download the guide.