This document contains relevant information for running SAP applications on VMware Virtual SAN like support status and sizing information.
For any questions regarding the content of this document please send an e-mail via SCN or directly to erieger@vmware.com.
Important News and Updates!
The new VMware Virtual SAN for SAP Applications - Solution Overview paper is now available and ready for download
What is Virtual SAN?
VMware Virtual SAN™ is radically simple, enterprise-class storage for VMware Hyper-Converged Software solutions. Uniquely embedded in the hypervisor, Virtual SAN delivers enterprise-class storage services for virtualized production environments along with predictable scalability and all-flash performance for hyper-converged infrastructure. It leverages commodity x86 components and standard storage drives. Seamless integration with VMware vSphere® and the entire VMware stack makes it the simplest storage platform for virtual machines—whether running business-critical SAP applications, virtual desktops or remote IT applications.
Just like vSphere, Virtual SAN provides users the flexibility and control to choose from a wide range of hardware options and easily deploy and manage it for a variety of IT workloads and use cases. Virtual SAN can be configured as all-flash or hybrid storage.
Source web page: “http://www.vmware.com/products/virtual-san/” and “Virtual SAN Datasheet”
What’s New with VMware Virtual SAN 6.2? -> http://www.vmware.com/files/pdf/products/vsan/VMware_Virtual_SAN_Whats_New.pdf
Virtual SAN for SAP - Characteristics*:
*The shown characteristic figures are maximum values and depend on the actual used VSAN configuration and may change depending on the actual used components and configuration, like all flash or hybrid configurations. |
What is a Hyper Converged Infrastructure Solution?
It is the convergence of compute, networking and storage onto shared industry-standard x86 server systems, running all the datacenter functions as software on a hypervisor.
More details: VMware Hyper-Converged Infrastructure: What’s All the Fuss About?
Why Virtual SAN for SAP Environments?
Customers wanting to modernize their existing complex SAP environments can leverage Virtual SAN, running on both VMware and SAP certified x86 servers, to eliminate traditional IT silos of compute, storage, and networking. All intelligence and management moves into a single software stack, allowing a VM and application-centric policy-based control and automation. This brings better security, higher performance, operational simplicity, and cost-effectiveness into SAP application environments.
The figure shows how several SAP landscapes can get migrated from aged, bare metal configuration to a modern, dynamic and consolidated hyper-converged infrastructure based on VMware solutions like Virtual SAN and vSphere.
Is Virtual SAN Ready for SAP Environments?
A recent VMware internal customer survey found that more than 60% of VMware’s customers trust Virtual SAN with their Business Critical Applications (BCAs) today, making BCA the most common use case. VMware has done extensive technical validation and published a series of reference architecture papers about running Oracle, SQL Server, and Exchange on Virtual SAN and is currently working on releasing a SAP specific Virtual SAN paper. The tests done so far have shown that Virtual SAN easily delivers the performance required by an SAP workload that runs virtualized. Please read also following article about VSAN SAP specific tests and results: SAP on Virtual SAN - Virtual Blog
What about SAP HANA?
SAP does not support HANA on any HCI architecture and solutions. VMware is working with SAP to jointly determine the best approach to achieve SAP HANA support for Virtual SAN.
High Level Architecture
Virtual SAN clusters contain two or more physical hosts that contain either a combination of magnetic disks and flash devices (hybrid configuration) or all flash devices (all-flash configuration). All these nodes contribute cache and capacity to the Virtual SAN distributed/clustered datastore and are interconnected via a 10 GbE network. When used for SAP applications, minimal four nodes are recommended for easier maintenance and stretched cluster readiness.
The figure below shows the high level architecture of an SAP landscape running on a VMware based hyper-converged infrastructure (HCI).
This setup would allow to run any SAP VM with the needed performance, resource commitments, failure tolerance, quality of service in a completely policy driven dynamic environment. This is the first time the changing needs of an application can directly influence the underlying infrastructure and by changing the assigned storage policy the level of protection or possible IO limits can get changed without disturbing operation of a VM.
Storage Policies Instead of Fixed, Static Storage Configurations
Through Software-Defined Storage, the storage classes of service for VMs become logical entities controlled entirely by software and interpreted through policies. Designing and making adjustments to these policies enables automating the provisioning process at scale, while dynamically controlling individual service levels for SAP applications over individual virtual machines at any point in time.
This makes the Software-Defined Storage model able to more flexibly adapt to ongoing changes on specific application requirements. Policies become the control mechanism to automate the monitoring process and to ensure compliance of storage service levels throughout the life cycle of the application.
The software defined storage control plane is programmable via public APIs, used to consume and control policies via scripting and cloud automation tools, which in turn enable self-service consumption of storage to application tenants as well as a variety of external management frameworks.
The figure below shows examples of storage policies and how they can get used to increase the SLAs of SAP applications.
Virtual SAN Stretched Clusters and VMware Site Recovery Manager
For higher levels of SAP application availability across three sites, consider the use of a Virtual SAN stretched cluster with VMware Site Recovery Manager™.
For example,two SAP production locations 100 kilometers apart could each house one half of a stretched cluster to protect against the failure of either location. A third location farther away hosts a second Virtual SAN cluster to supply compute, storage, and network resources for recovered virtual machines, as well as, any workloads that run on a regular basis at the disaster recovery site.
A Virtual SAN Stretched Cluster requires a “witness”, which is vSphere running in a virtual machine. The witness serves as a tie-breaker in certain situations such as loss of network connectivity between the two locations that make up a stretched cluster. The witness cannot be located within the same site as the stretched cluster so the disaster recovery site is the natural place to host this virtual machine appliance. Other SAP workloads running at a disaster recovery site might include test and development, QE, reporting, and so on.
Since stretched clusters essentially utilize synchronous replication between the two locations, an RPO of zero would be possible”. That means no loss of data if one of the locations in the stretched cluster is offline. With VMware vSphere® Replication™ combined with virtual SAN, a RPO time of five minutes is possible. VMware vSphere High Availability automates the recovery of virtual machines affected by an outage at either location in the stretched cluster. Recovery time for these virtual machines is typically measured in minutes.
Replication from the stretched cluster to the disaster recovery site is facilitated by VMware vSphere® Replication™. Per-virtual machine asynchronous replication RPOs between two Virtual SAN clusters can be as low as five minutes. Site Recovery Manager automates the failover and fail-back processes between the stretched cluster and the disaster recovery site. The figure shows a Virtual SAN based Stretched Clusters with VMware Site Recovery Manager.
More details on VMware Site Recovery Manager: VMware Site Recovery Manager: IT Disaster Recovery Software and VMware vSphere Replication: asynchronous virtual machine replication.
Virtual SAN and other Storage Solutions
Virtual SAN co-exists and can get used with any other vSphere supported storage solution like NFS or Fibre Channel Connected NAS storage or with VVol ready storage. The vSphere administrator has the freedom of choice to place the VMDKs of a specific VM to the storage solution that fits best the VM and application need.
Exiting storage solutions like NFS of FC based NAS solutions can get leveraged just like in the past and can get mixed with the new VMware software defined storage solutions like Virtual SAN or enterprise arrays that support Virtual Volumes (VVols).
vSphere Virtual Volumes (VVol) is an integration and management framework for external storage that provides finer control at theVM - level, streamlines storage operation and offers flexibility of choice and can get used in parallel with Virtual SAN. vSphere Virtual Volumes are designed, just like Virtual SAN, to make storage more virtual machine aware and much simpler for virtualization administrators and storage. To use VVol storage, vSphere 6.0 or higher and certified array vendor Virtual Volumes software (VASA Provider) is required. Source: Virtual Volumes Storage in Virtual Environments
The figure below shows how Virtual SAN can co-exit and get managed just like traditional storage or VVols within vSphere. Only difference is that Virtual SAN and VVol enabled storage can leverage the Storage Policy-Based management. Depending on the use case and application, it is possible to leverage all solutions and migrate for instance a Virtual SAN based SAP VM to a NFS attached physical storage array by simply perform a storage vMotion of the VM to migrate.
Support Status and Prerequisites for SAP workloads on Virtual SAN: For the most current support status please check out SAP support note 2161991.
To escalate VMware Virtual SAN related issues please collect a VMware performance snapshot as described in SAP Note 1158363 and open a problem ticket directly with VMware. For all other SAP VMware related issues please open a ticket at SAP (BC-OP-NT-ESX or BC-OP-LNX-ESX). |
Virtual SAN Sizing for SAP workloads
As with any other storage configuration, a storage capacity and IOPS sizing has to get performed.
The easiest way starting the sizing is when the capacity and IOPS needs for a certain environment is already known, then the Virtual SAN configuration that is able to provide the needed capacity and IOPS should get selected.
If this information is not available, then use the SAP Quicksizer Tool from SAP to perform a SAP application a sizing. Please go to http://service.sap.com/quicksizer for details. Only the so-called needed SAPS and storage space capacity will get calculated. Nevertheless. the calculated SAPS figure can get used to
Some SAP storage gurus, see a published SAP sizing presentation from EMC, use for a OLTP workload 0.6 IOPS per SAPS and for OLAP 0.9 IOPS per SAPS. With these figures it is possible to set the SAPS figure in relation to IOPS. They use also the term “Front End IOPS”, as this is describing the IOs generated by an application, or in the SAP case the described SAP database system. If the database SAPS are not known, then for OLTP workloads at least 25% and for OLAP workloads at least 33% of the total SAPS can get used as an estimation for the database SAPS. Let’s make an example calculation, again using the SAP QuickSizer will provide provide better results as our estimations and will provide the needed storage capacity and DB SAPS figure, which we need to calculate the theoretical needed IOPS performance.
For an example calculation, we use the four E5 based 2 socket servers (E5-2670 2.3GHz, 12 core), we performed our SAP HCI cluster tests on. In a recent vSphere virtualized SAP SD benchmark, 2015054, we see a SAPS performance of over 82,600 SAPS with a 2 socket server using E5-2699 v3 CPUs (E5-2699 v3 CPUs, 2,3 GHz, 18 cores). Since the test servers only had a CPU with 12 cores, the calculated virtualized SAPS performance is around 55,000 (calculated result based on benchmark 2015054).
The described test environment above had four of these theoretical 55,000 virtualized SAPS server capacity systems. In sum the landscape would be able to provide 220,000 virtualized SAPS. To calculate the SAPS performance of this SAP HCI system it is necessary to reduce the virtualized SAPS capacity by the system resources consumed by VSAN. As a rule of thump and to be very conservative, reserve 10% compute performance for VSAN. This will provide a SAPS capacity for the described Virtual SAN HCI system of around 198,000 SAPS.
When no vSphere virtualized benchmark result is available then from the published SAPS number, also the needed vSphere resources have to get subtracted. Example: native SAPS 100,000 – 10% for VSAN – 10% for vSphere = 100,000 x 0.81 = 81,000 virtualized HCI SAPS. Attention, the 10% for VSAN and vSphere are a very conservative figure and may actually be lower.
IOPS example calculation based on following assumptions:
- Database SAPS for OLAP = min 33%, we use 40% and for OLTP = min 25%, we use 30% (conservative calculation)
- Front End OLAP IOPS = 0.9 x Database SAPS and for OLTP = 0.6 x Database SAPS
- Cost cost of VSAN = maximal 10%, cost of virtualization = 10% (needed when no virtualized SAPS figures are available)
Calculation:
- Published virtualized SAPS figure = 220,000 SAPS (4 x 55,000 SAPS)
- Maximal available virtualized SAPS of the HCI system minus VSAN cost = 198,000 SAPS (220,000 - 10%)
- OLTP Database SAPS = 198,000 SAPS x 30% = 59,400 SAPS
- IOPS for SAP OLTP like ERP system = 0.6 x 59,400 SAPS around 35,600 IOPS
- OLAP Database SAPS = 198,000 SAPS x 40% = 79,200 SAPS
- IOPS for SAP OLAP like BW system = 0.9 x 79,200 SAPS around 71,000 IOPS
In our example calculation, single or several SAP VMs, which are using all available system resources of the described HCI system, will be able to consume up to 198,000 SAPS, which may generate up to 71,000 IOPS when running an OLAP like workload or around 35,600 IOPS when used for OLTP. With these results, it is now possible to select the correct VSAN configuration by selecting a VSAN ready node or configuration able to provide this IOPS and storage capacity. Please refer to the Virtual SAN TCO and Sizing Calculator.
In our OLTP like tests with the described four all-flash VSAN nodes (2x Intel Xeon E5-2670 2.3GHz, 12 core processors, 256GB RAM, 10 internal SSDs per Host), which had in total 40 SSDs installed, we have seen IOPS rates of around 45,000 IOPS per node (tested with OLTP like workload: 70% read 30% write, 100% random 4k block size and with a more OLAP like 8k block size. In total this setup was able to provide between 155k IOPS (4k blocks) and 180k IOPS (8k blocks) and would be able to deliver the calculated IOPS performance up to 3-4 times. IO performance in such a virtual SAN environment is therefore a problem of the past. Even better, when more compute resources are needed, then an additional VSAN node can get added and will automatically provide additional storage and IO capacity for the SAP VMs running on the Virtual SAN cluster.
Which Hardware can get used with Virtual SAN?
When considering hardware configurations for a Virtual SAN cluster, the easiest approach in many cases is using Virtual SAN Ready Nodes. These servers are pre-configured and installed with vSphere and Virtual SAN to help ensure compatibility and faster implementation times.
Another option is to build a custom solution using jointly validated components from a number of OEM vendors. The Virtual SAN Hardware Quick Reference Guide provides some sample server configurations as directional guidance and all components should be validated using the VMware Compatibility Guide for Virtual SAN. In either way, it is necessary to ensure the servers used are SAP supported and if necessary SAP certified.
Further reading:
- SAP on Virtual SAN - Virtual Blog (VMware blog around VSAN for SAP and performance)
- Virtual SAN Software-Defined Shared Storage - Product page
- VSAN Ready Node
- VSAN Design and Sizing Guide
- What's New - VMware Virtual SAN 6.2
- Virtual SAN TCO and Sizing Calculator
- Virtual Volumes Storage in Virtual Environments
- SAP Managed Tags:
