Tag Archives: sap

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

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)

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

The Case for SAP Central Services and VMware Fault Tolerance

What’s the CPU Utilization Of Standalone SAP Central Services in a Virtual Machine?

Since VMware came out with VMware Fault Tolerance (FT) we have considered the deployment option of installing SAP Central Services in a 1 x vCPU virtual machine protected by VMware FT. FT creates a live shadow instance of a virtual machine that is always up-to-date with the primary virtual machine. In the event of a hardware outage, VMware FT automatically triggers failover—ensuring zero downtime and preventing data loss. Central Services is a single-point-of-failure in the SAP architecture that manages transaction locking and messaging across the SAP system and failure of this service results in downtime for the whole system. Hence Central Services is a strong candidate for FT but FT currently only supports 1 x vCPU (vSphere 5.x), so some guidance is required on how many users we can support in this configuration. VMware has given technical previews of multi-vCPU virtual machines protected by FT at VMworld 2013/2014, but now, better late than never, here are the results of a lab test demonstrating the performance of standalone Central Services in a 1 x vCPU virtual machine. Continue reading

Impact of database licensing on Cluster Design for Production SAP virtualization

Type of Database licensing for SAP:

The type of licensing impacts the cluster design for SAP virtualization. SAP is supported on most common database platforms such as SQL, Oracle, DB2 and SYBASE. When customers procure SAP, they can choose to buy the database licensing through SAP or purchase it directly from the database vendor. This decision impacts the cluster design for virtualized SAP environments.

Let us look at these two scenarios and their impact on the design.

Scenario 1: Database License procured from the DB vendor for SAP:

Database vendors have differing but usually very restrictive policies regarding virtual machines running databases. The cost of licensing databases in the extreme case could force a customer to license for the entire cluster, even though  the database could be using only a small subset of the resources. Due to the uncertainty and the risk involved with DB licensing in this situation, it might be prudent to separate the entire database workload into its own cluster. By separating the entire database workload, the physical hardware used for databases can be isolated and licensed fully. Since only database workloads exist in this cluster one can achieve consolidation and efficiency for databases. The main disadvantage is the added overhead of having a separate cluster for databases. Since SAP landscapes have many modules with each module having its own individual database, creating a separate DB cluster with a good number of  hosts is  worthwhile and justified. Continue reading

Critical Factors to consider when virtualizing Business Critical Applications: (Part 1 of 2)

Over the past few years, there has been significant acceleration in adoption of the VMware platform for virtualization of business critical applications. When vSphere 5 was introduced with its initial support for up to 32 vCPU many of the vertical scalability concerns that existed earlier were addressed. This has been increased to 64 processors with the later vSphere 5.x releases ensuring that more than 99% of all workloads will fit vertically.

Having personally worked in IT infrastructure for more than 20 years with a strong focus on implementing and managing business critical applications, I see a general reluctance from application owners to virtualize business critical applications. When virtualizing business applications there are many critical factors one should consider.  I seek to address the typical concerns of application owners about Virtualization with this multipart series on Virtualizing BCA. Continue reading

SAP on VMware Sizing & Design Example

Recently in partner workshops I have come across some interesting discussions about the impact of hyper-threading and NUMA in sizing business critical applications on VMware. So here is an SAP example based on SAP’s sizing metric “SAPS” (a hardware-independent unit of measurement that equates to SAP OLTP throughput of Sales and Distribution users).  The examples here refer to vSphere scheduling concepts in this useful whitepaper The CPU Scheduler in VMware vSphere 5.1 .

SAP sizing requires the SAPS rating of the hardware which for estimation purposes can be obtained from certified SAP benchmarks published at http://www.sap.com/solutions/benchmark/sd2tier.epx . Let’s use certification 2011027  and assume that we plan to deploy on similar hardware as used in this benchmark. This is a virtual benchmark on vSphere 5 with the following result: 25120 SAPS (at ~100% CPU) for 24 vCPUs running on a server with 2 processors, 6 cores per processor and 24 logical CPUs as hyper-threading was enabled. This is a NUMA system where each processor is referred to as a NUMA node.  (Note cert 2011027 is an older benchmark, the SAPS values for vSphere on newer servers with faster processors would be different/higher, hence work with the server vendors to utilize the most recent and accurate SAPS ratings). Continue reading

Virtualizing SAP—it’s a risk not to

by Elliot Fliesler, Director, SAP Alliance, VMware

There are business-critical applications—and then there’s SAP.  If you’re an IT manager in an SAP-based organization, you know first-hand the importance of this market-leading BCA system to every aspect of your operations.  Many large enterprises cannot run their businesses without SAP—it’s not just critical, it’s indispensable.

Is Virtualizing SAP Risky?

In years past, some IT managers were reluctant to virtualize SAP, and for good reasons.  The story is very different today, in part because of the increased emphasis on IT as a strategic function. A case in point is Hoya Corporation, a Tokyo-based manufacturer of optical products. Needing to respond more quickly to changes in the global marketplace, Hoya decided to become more agile in every aspect of its operations, including its SAP environment.  Therefore, in November 2010, the company migrated its entire production SAP environment[1] to a private cloud based on VMware vSphere.

Hoya has been reaping the benefits ever since.  SAP operating costs have been cut by 75 percent.  Peak workloads—for example, running consolidated financial reports—are handled much more effectively, thanks to streamlined provisioning.  The increased flexibility has allow the company to integrate several acquisitions with minimal disruption to ongoing operations.  And Hoya is leveraging its virtualized SAP environment to add additional capabilities in the near future: enhanced disaster recovery/business continuity and a chargeback system for cost transparency.

Organizations Benefit from Virtualizing SAP

The pressure to ensure high availability is intense for SAP managers—even a few minutes of downtime can unleash a barrage of angry phone calls from frustrated users.  VMware virtualization takes advantage of SAP’s high-availability features to ensure that the software stays running—and the phones stay quiet.

Upgrades are a fact of life for every SAP landscape and they can be complex and time-consuming. Often they take hours or days in a non-virtualized platform—if you have the hardware available. In a virtual environment, new virtual machines can be provisioned in minutes, and then deprovisioned rapidly, recovering the resources.    

As IT budgets continue to shrink, the imperative to lower operating costs gets more urgent—and virtualization can make a real difference.  Server consolidation translates directly into lower costs for power, cooling, and space—and boosts the organizations “green” profile in the bargain.

Timing the Move

Let’s say that you’ve decided to virtualize your SAP environment—now the question is timing.  In the course of helping literally thousands of customers make the transition from physical to virtual VMware has identified some opportune times to move.

A planned SAP upgrade can be a good time.  For example, Mazda took advantage of a planned move to SAP NetWeaver Process Integration to virtualize their entire SAP production environment[2]—and cut in half their capital expenses.

When approaching a hardware refresh, many customers take advantage of the changeover to consider a migration to virtualization at the same time.  Many system integrators know how to integrate the refresh and virtualization projects to minimize disruptions and combine staff training for new hardware and software.

New compliance and security imperatives often require substantial infrastructure changes, which can highlight the inherent inflexibility of the existing platform and persuade top management to invest in infrastructure.  In the wake of a natural or man-made disaster that impacts operations, top executives often order a review of the company’s disaster recovery/business continuity plans, exposing vulnerabilities that can be best addressed with virtualization.