Home > Blogs > Virtualize Business Critical Applications

Multiple production SAP HANA virtual machines on a single physical server on vSphere 6

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)
  • Over-subscription of CPU and RAM resources

 

SAP and NSX Micro-Segmentation Example & Demo

Many companies deploying SAP systems run business processes that incorporate credit card payment transactions. Credit cards are subject to strict security standards developed by the PCI Security Standards Council, which is a consortium of the largest international payment card issuers. These standards require security settings within the SAP application and in the case where SAP is deployed on the VMware SDDC, PCI standards affects the VMware layer with requirements such as “Install and maintain a firewall configuration to protect cardholder data”. This is addressed by micro-segmentation which makes the data center network more secure by isolating each related group of virtual machines onto a distinct logical network segment, allowing the administrator to firewall traffic traveling from one segment of the data center to another (east-west traffic). This limits attackers’ ability to move laterally in the data center.   Micro-segmentation is powered by the Distributed Firewall (DFW) – a component of NSX. DFW operates at the ESXi hypervisor kernel layer and offers control at the vNIC level, which is very close to a guest VM operating system without being in the operating system.

For SAP micro-segmentation means we can create flexible security policies that align to: the multi-tier architecture of an individual SAP system (presentation, application and database tiers); the landscape of the SAP environment (separate production from non-production). The diagram below shows a SAP micro segmentation example based on the Netweaver ABAP stack with a backend database. The different tiers/components of the SAP architecture are:

  • Presentation tier – in this example I am using the SAP client “SAPGUI” to access the application tier. (note: customer environments would include  browser based access, load balancers and a web tier)
  • Application tier – application servers based on the Netweaver ABAP stack
  • Central Services / Global Host – handles SAP locking services, messaging between the app servers and a NFS share required by all the application servers
  • Database tier – services are database dependent
  • The components are isolated into their own NSX security groups. A NSX security group, in this example (other classifications are possible), is a definition in NSX and corresponds to a logical grouping of VMs within which there is free communication flow. Communication flow in/out of a security group from/to another group depends on the firewall rules.

blog2_pic1

Security policies in the above design provide the following controls:

  • Controlled communication path limited to specific services and protocols between tiers
  • External access only permitted to the application tier via the SAP presentation service
  • Access between application and database VMs via specific database services
  • SAP services ports vary depending on the “Instance Number” assigned to the application servers and Central Services. Some values are shown here.
  • In this example I have included external access from a monitoring tool – vRealize Operations (vROps) with the  Blue Medora  SAP Management pack. This needs access to the application tier via certain ports.

The top right of the diagram above shows a NSX screenshot of the security group definition for the application tier – it shows how VM membership can be dynamically assigned to a security group, for example based on the VM naming convention. This way you can provision new application server VMs and the new VMs will automatically inherent the security policies of the application tier security group.

The following diagram shows the high level architecture that makes all this happen.

blog2_pic2

The following screenshot shows an example configuration of the NSX communication paths based on the micro-segmentation design shown above (note: actual implementations will differ based on customer security requirements).

blog2_pic3

You can see a recorded demo of the configuration at the URL below. The demo starts in vRealize Operations where the Blue Medora SAP Management Pack has been configured to monitor the SAP system. Data collection fails due to activation of the NSX firewall.  The NSX configuration is shown and tested and the services are configured to re-establish communication between vROps and the SAP system.

DEMO URL: https://www.youtube.com/watch?v=qdPhejVCG3s&t=82s&index=1&list=PLCED9FDF31C7C0562

bluedemobutton

New Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide, now available!

I am happy to announce that after a very long review and publication cycle the “Architecture Guidelines and Best Practices for Deployments of SAP HANA on VMware vSphere Guide” is now published.

The guide can be downloaded from our central VMware SAP page.

Direct link to the document: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/sap_hana_on_vmware_vsphere_best_practices_guide-white-paper.pdf

The chapter on sizing tackles the complex subject getting HANA VM’s sized properly, and provides incredible value to the reader as it provides guidance that explains how to size beyond physical to virtual so your organization can get it right the first time, every time.

Building a virtual SAP HANA VM requires to know not only the needed RAM, but also the number of needed CPUs to support this RAM. Without this information, it is not possible to create a VM.

The sizing guidelines published in this guide follow the SAP currently requested CPU socket / CPU core to RAM ratios or, when available describe how to perform a SAPS sizing. Using these guideless will provide you with SAP supported VM configurations.

I will provide some additional sizing examples that focus on SAPS and vCPU sizing, in addition to the already provided “NUMA” node based sizing example. Please remember, primary sizing figure for SAP HANA is memory and CPU is second and a SAP HANA configuration is optimized to optimal memory performance with lowest latency.

Oracle on VMware Collateral – One Stop Shop

Here is a one stop shop for all collateral related to Oracle on VMware SDDC  for easy and quick access.

 

One-Stop-Shop1

The links also contains offline demos/videos (no audio) which are currently in the process of being uploaded to VMware TV on YouTube which users can subscribe to.

I will updating this blog as and when we add more Oracle collateral to the kitty.

Continue reading

Oracle on VMware vSphere & vSAN – Dispelling the Licensing myths

Introduction to VMware vSphere & vSAN

Some key things to keep in mind when we talk about VMware vSphere Platform , ESXi hypervisor and vSAN:

  • VMware vSphere is a platform of virtualized hardware that creates a total abstraction layer between the O/S and the Hardware
  • ESXi, is a non-Para virtualized, Type1 hypervisor and therefore makes no changes to the kernel of the guest operating system
  • VMware vSAN , the industry-leading software powering Hyper-Converged Infrastructure solution,  in no  way changes the location of where compute runs, and hence does not directly impact the licensing impact of any CPU Core or Socket based licensing

Oracle Licensing Myths

There are myths floating around that

  • Oracle Licensing requires licensing every vSphere host attached to a given vCenter
  • Oracle licensing requires licensing every Site connected to the Primary site where the Oracle workloads primarily resides

These myths are perpetuated by overzealous licensing and sales teams which is in contrast of the reality of the actual Contractually Impactful documents.

Continue reading

Troubleshooting SAP Performance with VMware vRealize Operations

Over the years VMware support has investigated numerous performance escalations of  virtualized tier 1 applications. One of the more challenging aspects of this task is coordinating all the key performance monitoring metrics across the different technology layers from the application down to the hypervisor.  This is where VMware vRealize Operations (vROps) with the Blue Medora Management Packs can help to expedite the troubleshooting process. I will show an example here with a virtualized SAP on Oracle system.

The Blue Medora website has links to all the installation documentation for the different application management packs. Once the SAP and Oracle Management packs are installed and configured in vROps to connect to the individual SAP and Oracle systems, the adapters will discover and generate SAP and Oracle objects in vROps which can be accessed via menu  Home -> Environment ->  All Objects. The following screenshot shows the discovery of the SAP system.

blog_pic1

As shown above the different instances of the multi-tier SAP system have been discovered: two application servers; Central Services; database instance with system ID = “TST”.  You can then drill down into the SAP metrics for an application server.

This SAP system is running on an Oracle database. The Oracle management pack will discover the Oracle database as shown below.

blog_pic2

Now how do we troubleshoot this environment. Let’s show an example.

Performance Escalation Logged with the Helpdesk

SAP end users are complaining of slow response times on the SAP system. Some users are claiming its taking a long time to log into SAP.

Order of Analysis

Analysis will involve monitoring three technology layers. The analysis will start at the virtual layer, then move up to the database and finally to the SAP layer – this is described in the diagram below.

blog_pic3

You can access the different metrics in vROps via the menu:

“Home –> Environment –> All Objects –> <Select Adapter> –> <select adapter object> –> Troubleshooting –> All Metrics –> <select object> –> <select counter> …..”

Step 1 Virtual Metrics

We begin at the infrastructure layer. The following table shows some of the key virtual metrics for this example.

blog_pic4

From above we can see that there does not appear to be any major resource bottlenecks at the infrastructure layer . Next we move up to the database layer.

Step 2 Oracle Metrics

The following table shows two Oracle metrics for this example (note there are other Oracle metrics that would also need to be considered for an in-depth analysis).

blog_pic5

Oracle Logical Reads Per User Call corresponds to the average Oracle blocks read from the buffer cache (part of Oracle’s System Global Area) to service queries from the application server. If the block is not available in the cache it is serviced from disk. A large number of logical reads per user call may be due to expensive SQL statements. Expensive SQL statements can be addressed via SQL tuning. Threshold value and guidelines for the logical reads per user call counter  (and other key Oracle metrics ) are documented in the SAP Knowledgebase article 618868 – FAQ: Oracle performance  .

The Oracle database wait time ratio counter helps to determine if the database is currently experiencing a high percentage of waits/bottlenecks. A higher database wait time ratio indicates that system performance can be improved using “wait event tuning”. The latter requires more in-depth analysis of Oracle wait events – these wait event counters can be accessed within Oracle by the database administrator or can be available in vROps via the Blue Medora management pack for Oracle Enterprise Manager.

In this example both the logical reads per user call and database wait ratio have increased to levels that requires more in-depth analysis to determine if Oracle or bad SQL statements are the cause of the performance problem. However, it is possible that Oracle is performing as expected to process the SQL statements as submitted by the application server. We now need to move to the SAP layer as ultimately all workload originates from the application tier.

Step 3 SAP Metrics

In the final step we look at the SAP counters which can help explain the workload running on the application server. The following table shows some SAP metrics for this example (note there are other relevant metrics).

blog_pic6

The SAP dialog work process utilization shows the percentage of work processes allocated for online user activity that is currently being utilized on the SAP application server. In this example the increase in work process utilization is suspect and requires further inspection by the SAP administrator. So now at this point we would notify the SAP administrator to use SAP tools to troubleshoot further – in this example this step reveals the root cause behind the user complaints.

Root cause: in this performance troubleshooting example the root cause is at the SAP application layer where a batch job was scheduled on the application server competing with the online users. The batch job utilized many of the available work processes thus minimizing the number of free work processes available for the online users.

Potential resolution: reschedule batch job on other application servers or at different time; increase the number of work processes.

SUMMARY

I have shown a troubleshooting scenario of an SAP on Oracle system using vROps to analyze metrics from the vSphere, Oracle and SAP layers.  vROps with the Blue Medora Management Packs has enabled the required visibility across these layers to expedite root cause analysis. In this example I have accessed the required metrics directly via the menu “Home –> Environment –> All Objects –> <Select Adapter> –> etc”. Alternatively you can navigate to the relevant metrics via the out-of-the-box dashboards provided by the management packs – an example of this is described at http://www.bluemedora.com/blog/advanced-troubleshooting-of-virtualized-sap-environments-with-vrealize-operations/ .

Thanks to my colleagues for their guidance on vROps and Oracle: Cameron Jones; Jeff Godfrey; Ben Todd; John Dias; Sudhir Balasubramanian.

Announcing General Availability of VMware Adapter for SAP Landscape Management version 1.4!

****** THIS BLOG IS POSTED ON BEHALF OF THE AUTHOR NELSON YAN *******

At VMworld EMEA in October 2016, we announced the VMware private cloud solution for SAP and the upcoming release of our Adapter for SAP Landscape Management. To read more about the announcement by my colleague Alberto Farronato, check out his blog post here.

Our mission is simple – to provide best-in-class software-defined infrastructure solution that simplifies deployment and management of SAP landscapes so business can focus on innovation instead of “keeping the lights on”.

By virtualizing the SAP environment, the private cloud solution for SAP removes the pains and constraints of running SAP on hardware-defined infrastructure: lack of scalability, high TCO, low business continuity during maintenance, and many more. Furthermore, we can now drive more automation and intelligence in the software-defined infrastructure once SAP has been re-platformed VMware virtualized infrastructure.

With that said, I am excited to announce the general availability of VMware Adapter for SAP Landscape Management version 1.4! The Adapter will radically simplify how SAP basis admins manage and deploy SAP landscapes and more tightly integrates SAP Landscape Management with underlying VMware virtualized infrastructure.

The all new VMware Adapter for SAP Landscape Management

Our latest iteration brings new capability and support that help customers address the challenges around digital transformation for both SAP and VMware.

  • SA-API – give programmatic ability to provision SAP landscape and underlying VMware infrastructure
  • Integration with vRealize Automation – allow basis Admin to leverage SA-API to create templates that end users can consume and self-provision SAP landscapes

The new features augment the existing capabilities of the adapter, taking automation and self-service to the next level so SAP basis admin can focus on value-adding innovating tasks instead of “keeping the lights on” operations. However, let’s not forget the key existing capabilities of the adapter:

  • Provisioning – System Cloning, Copying, and System Refresh
    • Automate key SAP basis provisioning task such as system cloning, copying, and system refresh directly in vCenter with SAP Landscape Management.
  • Operations – SAP Hosts, Storage, and Network Migration
    • Migrate VM, switch its data set and network to stand up SAP hosts, move environments, and deploy disaster recovery solutions – all through the SAP Landscape Management interface.

For customers interested in deploying the Adapter in production SAP landscapes, we are also introducing the option to purchase Production-level support from VMware GSS.  Enterprises can now virtualize SAP with confidence, knowing that they have the backing of both SAP and VMware. Support is optional, and the free community edition of the Adapter continues to be available for non-production environments.

But there’s more… SAP Solution Guide!

In addition, we have also been putting together a comprehensive solution guide on how to install, deploy, and manage an SAP environment on top of VMware SDDC. The guide captures the essence of VMware private cloud solution for SAP, which defines the software stack to virtualize, secure and automate SAP environments leveraging VMware’s software-defined architecture. Key topics include:

  • Best practice for deploying SAP HANA on VMware vSphere
  • Implementing SAP Solutions on VMware products such as vSphere, vSAN, and NSX

The guide is an invaluable resource to help you take the first step in virtualization your SAP environment!

Interested to Learn More?

Visit the VMware Adapter for SAP Landscape Management Product Page

Read the SAP Solution Guide

SAP production support for vSphere 6.5

On behalf of the VMware Walldorf based SAP engineering and support team, I am happy to announce that since December 7, 2016, in addition to the already granted SAP HANA support, all other SAP applications and solutions, as of below SAP notes are supported in production on SAP and VMware supported server systems with vSphere 6.5

Please read SAP note “1409608 – Virtualization on Windows” and SAP note “1122387 – Linux: SAP Support in virtualized environments” for further details.

Follow SAP note “2161991 – VMware vSphere configuration guidelines”, when planning and installing a VMware virtualized SAP environment.

 

VMware vSphere 6.5 is certified for SAP HANA 1.0 and 2.0

Thanks to your performance engineering and SAP HANA certification team, SAP released support for vSphere 6.5 with SAP HANA SPS 12 or higher (incl. SAP HANA 2)!

SAP declares support for VMware vSphere 6.5 for virtual single-VM deployments in production scenarios of SAP HANA on either certified appliances or through SAP HANA tailored data center integration verified hardware configurations.

Currently we are limited to 4 TB vRAM, hosts are supported with up to 12 TB. Background is that we did not had a 6 TB system for our tests. RAM is ordered and once installed we will continue to work jointly with SAP on the 6 TB HANA vSphere 6.5 certification.

We also try hard to finish the certification for Multiple-SAP HANA VMs and Scale-Out configurations for production SAP HANA workloads with vSphere 6.0 and 6.5. So stay tuned for the next announcements!

For details please review SAP note “2393917 – Single SAP HANA VM on VMware vSphere 6.5 in production” or our SAP HANA on VMware vSphere WIKI page.

Game Changing: Day 2 Enterprise Data Management Tasks with VMware NSX and vRealize Operations

As a Staff Partner Architect at VMware, I tend to look at our platform and products through a slightly different lens than some of my colleagues. Rather than focusing solely on our feature rich product sets and platform, I take a top down approach and identify which of these features are most interesting for mission/business critical deployments in a Software-Defined Data Center (SDDC).

VMware NSX is one of those game changing technologies which should interest application owners, database architects, CIOs, and of course network IT professionals. You can think of NSX as a network hypervisor, as such NSX administrators now have the ability to abstract and reproduce a complete set of layer 2 to layer 7 networking services. The ability to abstract and reproduce layer 2 to layer 7 networking services is certainly meaningful to network operations but what does it mean to enterprise architects? Why should our customers care, and why should CIOs care?  The answer is hair-pinning. Continue reading