Home > Blogs > Virtualize Business Critical Applications > Monthly Archives: June 2012

Monthly Archives: June 2012

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.

 

Firing Speed with vFabric SQLFire

Several customers have asked what vFabric SQLFire can do for their applications and how they can modify the architecture of a custom Java application accordingly. These customers typically run custom Java applications against RDBMS that have reached the limits of scalability and response time with their current architecture. They want to make the change only if they are not too invasive.

To answer these questions fairly, we simulated a customer scenario with no specific assumptions about specialized tuning. First, we took Spring Travel with RDBMs as-is and ran a load test against it. Then we converted the Spring Travel schema to run against vFabric SQLFire, also without tuning, and plotted the results side by side. 

We also wanted to demonstrate how quickly we could make this change without assumptions about any code intrusion/change, so we simulated how a developer might download the Spring Travel application, run the DDlUtils conversion utility to generate the SQLFire schema and the data load file, then quickly test to see the performance improvements. We felt this would answer the customers’ questions without bias.

This post summarizes the results. The details of the conversion of the RDBMS schema and data can be found in the vFabric SQLFire POC Jumpstart Service Kit, or vFabric SQLFire Accelerator Service Kit. (Contact your local VMware account team for details on these service offerings.). The conversion process took one day, and the total process—downloading the Spring Travel application, installing vFabric SQLFire, running the schema and data conversion utility, and running the load test—took 3 days. We iterated the results for another week for verification.

NOTE: You can download Spring Travel from: http://www.springsource.org/download. Navigate to the download link under Spring Web Flow 2.3.0.  For vFabric SQLFire, see: http://www.vmware.com/products/application-platform/vfabric-sqlfire/overview.html

 

Figure 1. Spring Travel on Traditional Disk-Based RDBMS versus vFabric SQLFire 

Figure-1

 

Performance Results

The results are plotted in Table 1. The legend for the columns is as follows:

  • Threads: The number of concurrent Spring Travel application threads executed during the two load tests.
  • SQLF R/T (ms): The response time of Spring Travel application in milliseconds.
  • SQLF CPU %: The percentage of CPU utilization at peak for the SQLFire VMs.
  • RDBMS R/T (ms): The Spring Travel application response time in milliseconds when running against the traditional disk-based RDBMS.
  • RDBMS CPU %: The percentage of CPU utilization at peak on the RDBMS VM.

The results tested for a range of 18 to 7200 concurrent threads. ”Failed” indicates that Spring Travel running against the traditional disk-based RDBMS failed to respond. Since it was essentially frozen, we collected no data from it.

 Table 1. Spring Travel Results with RDBMS versus SQLFire

Table-1-1

Spring Travel Response Time versus Concurrent Threads Test Results

Figure 2 shows response time along the vertical axis and concurrent number of threads along the horizontal axis. The red line represents Spring Travel running against a traditional disk-based RDBMS, and the blue line represents Spring Travel running against SQLFire. The data shows that as the number of concurrent threads increases along the horizontal axis, the Spring Travel response time increases in a linear fashion when running against the disk-based RDBMS but remains constant, as indicated by a fairly low and flat blue line, when running against SQLFire.

 

Figure 2 – Spring Travel Response Time versus Concurrent Threads

Figure-2

Scalability Test Results

This test demonstrates the extent of scalability of both configurations. When Spring Travel ran against the RDBMS, after reaching 1850 concurrent threads and getting close to a response time of 172 milliseconds, the system stopped responding, indicating that it had reached the scalability limit. This is indicated by the red line on Figure 3. On the other hand, Spring Travel running against SQLFire continued to function to the limit of 7200 concurrent threads and a response time of 984 milliseconds. This is indicated by the blue line.

NOTE: At approximately 3600 concurrent threads, SQLFire started to overflow to disk, and the response time increased. In a normal situation, you can use appropriate sizing of available RAM to contain this kind of overflow. 

 

Figure 3. Spring Travel Response Time versus Concurrent Threads – Scalability Test

Figure-3

CPU versus Concurrent Threads Test Results

Figure 4 shows the CPU %, measured for the duration of the test, of the RDBMS VM in red and the SQLFire VMs in blue. Using the RDBMS, Spring Travel peaked at approximately 80% CPU and 1850 concurrent threads. At this point, it completely failed to respond. The SQLFire-based Spring Travel configuration, on the other hand, continued to 98% CPU utilization at 7200 concurrent threads and was still responsive – this is at approximately 984 milliseconds f Spring Travel application response time. The red and blue lines crossed over at approximately 1000 concurrent threads, indicating that Spring Travel with SQLFire handled much higher loads at a steadier CPU utilization increase.

 

Figure 4 – Spring Travel Application CPU versus Concurrent Threads

Figure-4

Summary of Findings

This simulation shows that:

  • Using the DDlUtils utility to convert the schema and data of the RDBMS associated with Spring Travel application was relatively straightforward.
  • The installation of vFabric SQLFire was also straightforward.
  • Spring Travel pointing to vFabric SQLFire scaled approximately 4x when compared to Spring Travel pointing to an RDBMS.
  • The response times of SQLFire were 5x to 30x faster with vFabric SQLFire. Further, the response times on SQLFire were more stable and constant with increased load.
  • The configuration of Spring Travel with an RDBMS has a response time that increases linearly with increased load.
  • The break point for Spring Travel against an RDBM was at 80% CPU utilization for about 1850 concurrent threads, after which Spring Travel stopped responding. The SQLFire version of Spring Travel continued to pace ahead at 98% CPU utilization and achieved 7200 concurrent threads.
  • NOTE: The assumption here in the test across the two configurations was that the total compute resource was the same, meaning a true apples-to-apples comparison.  The RDBMS VM was eight vCPU and 4GB of RAM, while the SQLFire VMs were of 2GB and two vCPU each.  In configuration cases VM memory reservation was set.

 

 Thank you for reading! Looking forward to seeing you at VMworld 2012, I will blog about my VMworld sessions shortly.

 

Emad Benjamin

Debunking the Myths of Virtualizing Your Business Critical Applications

by Mary Nakahara

They say fear is good.

Fear can be a healthy thing—it can keep you from getting in over your head, taking unnecessary risks, and it can even save your life. In IT, that fear—maybe better framed as 'caution'—has its place. It ensures that we consult with others, adhere to processes and standards, and balance risk with reward. Caution in IT ensures that business keeps moving forward—because if it doesn't, revenue is at risk (and necks are on the line). So, we proceed with caution.

In the world of virtualization, there is fear—but, for the most part, it's misplaced. Many companies that have fully embraced the benefits of virtualization are still missing the greatest value because they think it's too risky to virtualize business critical applications (BCAs). If some of the myths are holding you back, here's a little dose of reality:

Myth: Software vendors won't support BCAs once they are virtualized.
Reality: Chalk this up to FUD. Software vendors support VMware. For the one vendor who gives the most grief, check out this whitepaper on Oracle licensing and support.

Myth: BCAs aren't compatible with a virtualized platform.
Reality: This is a non-issue. As long as the OS is supported on vSphere and the BCA is supported on that OS, then the BCA is compatible with VMware.  Check out these resources, white papers, and FAQs for the various BCAs: SAP, Oracle Database, Microsoft Exchange, SQL and Sharepoint.

Myth: BCA performance and scalability will decline when virtualized.
Reality: Just because it’s on a virtual platform doesn’t mean performance and scalability take a hit. The CPU overhead is a myth. Just like a physical platform, it all depends on how you design and architect the application on the virtualized platform. It’s critical that you consider the performance, availability, and scalability requirements before you turn on the switch to make sure you meet your SLAs right out of the gate. And if you’re not sure—don’t guess. Bring in the experts to guide you, helping you to make smart choices and construct a design based on real world know-how. When it comes to business critical applications, don’t cut and paste—know what you need and why you need it. (The resources linked above address this topic, too.)

Myth: Virtual platforms are not as secure as physical platforms.
Reality: Security lapses don’t discriminate against one platform or another. Physical platforms can be insecure, as can virtual platforms. Vendors with robust and flexible solutions have the technology and expert-led services to not only secure your virtual environment, but augment your physical security, as well. Resources and white papers on securing your virtualized platform can be found here.

Now, is there risk? Sure. In IT, like everything else in life, it's impossible to completely eliminate risk. That’s why planning and having the in-depth expertise to design and build out your virtualized platform are key. The business benefits tip the scale in favor of virtualization for BCAs. Our customers are realizing that the traditional benefits of virtualization can help provide competitive advantage through speed to market, improved user experience, increased availability, and better allocation of resources. And more and more are choosing to virtualize their business critical applications with VMware:

BCA-diagram

If you're interested in digging deeper into why the myths aren't based in reality and how to go about virtualizing your business critical applications like Oracle, SAP, and Exchange, a good starting place is our free, self-paced course Virtualizing Business Critical Applications. It covers a lot of ground in two hours, including best practices, use cases, tips and tricks, and more.

 

This blog is part of a series on Virtualizing Your Business Critical Applications with VMware. To learn more, including how VMware customers have successfully virtualized SAP, Oracle, Exchange, SQL and more, visit vmware.com/go/virtualizeyourapps.