Home > Blogs > Virtualize Business Critical Applications > Category Archives: SAP

Virtualize Business Critical Applications

For Applications owners, database admins, Exchange admins, vSphere admins and application architects.

Category Archives: SAP

CenturyLink Transforms SAP Deployment Model with VMware Virtualization

We recently worked with CenturyLink, one of the largest telecommunications companies in the United States, to optimize their virtual SAP HANA solutions. The outcome is below referenced success story, where CenturyLink describes how they use the VMware platform, to provide a customized private cloud for SAP applications, including SAP HANA in less than 28 days, with no compromise on performance.

A SAP infrastructure project duration of 28 days may not sound so fast, but remember, this is a for a completely customized SAP private cloud solution and not just some standard, simple SAP HANA instances running somewhere in the public cloud, as a test or development system. Regarding CenturyLink, customers can deploy new SAP workloads up to four times faster, compared to in-house implementations, where these deployments typically take over 100 days!

Deploying a complete SAP landscape includes several systems like SAP Solution Manger, SAP Gateways, load balancers, several applications servers and finally the SAP HANA database. All these systems need to get configured, patched up to the latest software release level and connected by maintaining highest security standards. All this will get done, if wished, by CenturyLink.

Beside faster time to market, CenturyLink can utilize templates and repeatable processes, which helps it easily standardize and scale its offering while managing costs, complexity, and risks. This all leads to CapEx savings of up to 60 percent and OpEx savings in a similar range for CenturyLink customers. For instance, as an SAP HEC partner, CenturyLink had to deploy without SAP HANA VMware vSphere virtualization, 20 physical server systems to support 20 independent SAP HANA systems in the past. Now they deploy a VMware cluster of 8 hosts to support these 20 SAP HANA instances, including HA, which is a HW reduction by 12 hosts or 60 percent. 60 percent less power and cooling costs, rack space savings and reduced HW maintenance costs are only the more comprehensible cost savings realized. Additionally, to this the easier operation of a virtual, software defined environment, are major, long-term, cost saving factors.

These are the reasons why CenturyLink wants to go one step further towards a fully software defined data-center and plans to implement a VMware Virtual SAN™ based hyper-converged infrastructure ready to run even the more demanding SAP workloads.

For more information please review the success story posted here:

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 4/4)

Leave a reply

In part 1 we introduced the concept of SAP HANA Application Workload guidance and using example business requirements to come up with a workload and vSphere cluster design for the SAP environment. In part 2 we looked at storage, network and security design for the proposed customer environment. In part 3 we looked at monitoring & management, backup/recovery and disaster recovery for SAP S4/HANA. In this final part we look at validating the design we built over the past three parts and conclude the four part blog series.

SAP S/4HANA Design Validation

Validation of an SAP design is often difficult because of the absence of publicly available validation and performance tools. This design utilizes best practices derived from vendor testing conducted in SAP labs. The SAP HANA database tier is critical to the infrastructure and must be validated. So as part of this SAP S/4HANA VVD solution, some SAP standard validation tools were used to exercise the designed infrastructure.

Continue reading →

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 3/4)

Leave a reply

In part 1 we introduced the concept of SAP HANA Application Workload guidance and using example business requirements to come up with a workload and vSphere cluster design for the SAP environment. In part 2 we looked at storage, network and security design for the proposed customer environment. In this part we will look at monitoring & management, backup/recovery and disaster recovery for SAP S4/HANA.

SAP S/4HANA Monitoring and Management

Nearly every component of the IT stack contributes to application performance, which can make it challenging to identify the cause of issues when they arise. For many organizations, a lack of visibility can lead to mean-time-to-innocence hunts that waste time and create alert storms that drain the productivity of business teams. With a complex application such as SAP S/4HANA, performance issues can be even more difficult to specify because the application requires resources from the virtual environment, the network, and databases. However, integrating monitoring into a single console—such as VMware vRealize Operations Manager can provide visibility into SAP workloads and other IT relationships to impact performance.

Continue reading →

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 2/4)

3 Replies

The availability design depends on the single point of failure (SPOF) analysis of components. There are components in the SAP infrastructure that are one of a kind and are potential SPOFs; other components are capable of having multiple instances for load balancing and availability.

Continue reading →

Application Workload Guidance and Design for Virtualized SAP S/4HANA® on vSphere (Part 1/4)

2 Replies

SAP Business Suite 4 SAP HANA (or SAP S/4HANA) is the SAP Business Suite that is built on SAP’s in memory columnar database platform SAP HANA. SAP HANA^®, the in-memory real-time platform, was initially introduced as a physical appliance and has steadily evolved to include support for virtualization with VMware vSphere^® and SAP HANA tailored data center integration (TDI). Virtualized SAP HANA is now supported in scale-up and scale-out configurations in VMware^® environments. Running SAP HANA on vSphere offers customers agility, resource optimization, and ease of provisioning. This solution enables SAP customers to provision instances of SAP HANA more quickly and effectively by using vSphere virtual machines (VM). Using the SAP HANA platform with the vSphere virtualization infrastructure constitutes an optimized environment for achieving a unique, cost-effective solution. VMware capabilities such as VMware vSphere vMotion^®, VMware vSphere Distributed Resource Scheduler™ (vSphere DRS), and VMware vSphere High Availability (vSphere HA) are inherent components of the virtualized SAP HANA platform.

The need exists for a comprehensive, “end-to-end” solution that describes the implementation of a virtual SAP HANA deployment. VMware Solutions Labs was chosen to first develop a robust validated end to end solution. This is the first solution that takes the VMware Validated Design concept and then uses its components to run an Enterprise application like SAP on top of it. This prescriptive approach called Application Workload Guidance Design applies the VMware Validated Design (VVD) to SAP S/4HANA on the vSphere platform.

Continue reading →

SAP HANA on VMware vSphere, Multi-VM Support Status as of May 2017

2 Replies

Since my last SAP HANA blog in February, our SAP HANA validation and engineering team was busy performing the remaining validation test on the Intel Broadwell platform.

Because of the positive results, SAP granted us Multi-SAP HANA VM and NUMA node sharing support for vSphere 6.0 and 6.5 on the 4 socket Intel Broadwell platform up to 4 TB VM sizes.

By now we have five SAP support notes that describe the support status of SAP HANA on VMware vSphere. This blog concentrates on Multi-VM configurations. For a complete overview of what is SAP supported please visit the SAP HANA on VMware vSphere Wiki pages on wiki.scn.sap.com.

The first table in this blog shows the SAP HANA Multi-VM configuration status and what is supported in production. The 2nd table shows what is VMware platform supported, but was not explicitly validated for SAP HANA workloads.

Continue reading →

VMware Adapter for SAP Landscape Management – Connector for vRealize Automation 1.1

Leave a reply

The VMware Adapter for SAP Landscape Management just got better and provides now a connector for vRealize Automation 1.1!

Our Integrated Systems Business Unit, just released the VMware Adapter for SAP Landscape Management – Connector for vRealize Automation 1.1.

Why is this important?

The vLA Connector for vRealize Automation feature allows SAP and VMware admins to publish SAP systems to vRealize Automation so that SAP Users can consume these contents themselves directly from vRealize Automation.

The new connector augments the automation power of VMware Adapter for SAP Landscape Management 1.4.1, which leverages capabilities of SAP Landscape Management (LaMa) and VMware SDDC, and empowers SAP customers to provision and manage SAP application seamlessly.

Continue reading →

VMware Adapter for SAP Landscape Management 1.4.1 – Automate and manage your VMware virtualized SAP Landscape

2 Replies

On behalf of David Gallant, ISBU, Product Management and the Integrated Systems Business Unit, we are very pleased to announce the General Availability of VMware Adapter for SAP Landscape Management 1.4.1.

VMware Adapter for SAP Landscape Management integrates SAP Landscape Management (LaMa) with VMware Software-Defined Data Center (SDDC) technologies, allowing SAP BASIS administrators, VMware administrators, SAP project and business stakeholders to automate provisioning and management of SAP landscapes running on VMware’s SDDC. The adapter is a key component 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. At its core, it includes VMware vSphere, VMware NSX, vRealize Automation and the VMware Adapter for SAP Landscape Management and will help to bring SAP Consumers closer to IT Providers, by leveraging for instance an optional service portal to perform SAP system deployments and management tasks instead of using administrator and system tools.

Below figure shows how providers and consumers can leverage the VMware Adapter for SAP Landscape Management.

This release of the adapter is a very important maintenance release. With this release, we continue to enhance support for vRealize Automation and the system automation application interface (SA-API). These enhancements pave the way for additional customers to adopt SAP LaMa, and VMware’s SDDC.

Continue reading →

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

7 Replies

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

2 Replies

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.

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.

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).

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