Home > Blogs > Virtualize Business Critical Applications
Featured post

Disabling TPS in vSphere – Impact on Critical Applications

Starting with update releases in December, 2014, VMware vSphere will default to a new configuration for the Transparent Page Sharing (TPS) feature. Unlike in prior versions of vSphere up to that point, TPS will be DISABLED by default. TPS will continued to be disabled for all future versions of vSphere.

In the interim, VMware has released a Patch for vSphere 5.5 which changes the behavior of (and provides additional configuration options for) TPS. Similar patches will also be released for prior versions at a later date.

Why are we doing this?

In a nutshell, independent research indicates that TPS can be abused to gain unauthorized access to data under certain highly controlled conditions. In line with its “secure by default” security posture, VMware has opted to change the default behavior of TPS and provide customers with a configurable option for selectively and more securely enabling TPS in their environment. Please read “Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing (2080735)” for more detailed discussion of the security issues and VMware’s response.

What does this mean for your Business Critical Applications?

One of our standard recommendations for optimizing a vSphere infrastructure for a critical workload is to leave TPS enabled in the infrastructure. One other recommendation is that customers should not over-subscribe the physical resources in a vSphere cluster supporting business critical applications. Where over-commitment of resources is unavoidable, we have prescribed that the resources allocated to the VMs hosting the critical, IO-intensive workloads should be reserved at all times to avoid contentions.

Another common prescriptive guidance for critical applications workloads is the use of large pages. Most modern operating systems and enterprise applications support large pages, and we recommend enabling it for critical applications.

In a vSphere cluster free of resource over-commitment and contentions, the TPS feature is not used. It should also be noted that, on modern hardware (with hardware assisted memory virtualization capabilities), the virtualized workloads will leverage the efficiency of large pages before vSphere utilizes the TPS feature. In short, in a vSphere environment built to prescription, the TPS feature is unlikely to be actively in use (or used to any significant degree) for a business critical applications workload.

Nevertheless, the planned change in TPS behavior should be of interest and we are providing the following guidance to help our customers understand the implications and steps that could be taken to avoid any negative impact from the change.

  • Starting with the Patch mentioned above, customers will be able to disable TPS on their ESXi hosts and selectively enable TPS for one or more VMs.
  • Starting with the Update, TPS will be disabled on ESXi hosts by default. Customers will be able to selectively enable TPS for one or more VMs.

What if you want to disable TPS now – before the Patch or Update?

Although VMware believes that the reported possible information disclosure in TPS can only be abused in very limited configuration scenarios, VMware advices customers who are sufficiently concerned about this possibility to proactively disable TPS on their ESXi hosts. Customers do not have to wait for the either the Patch or the Update releases to do this.

To do this for ESXi 5.x, perform the following steps:

  1. Log in to ESX\ESXi or vCenter Server using the vSphere Client.
  2. If connected to vCenter Server, select the relevant ESX\ESXi host.
  3. In the Configuration tab, click Advanced Settings under the software section.
  4. In the Advanced Settings window, click Mem.
  5. Look for Mem.ShareScanGHz and set the value to 0.
  6. Click OK.

Perform one of the following to make the TPS changes effective immediately:

  • Migrate all the virtual machines to other host in cluster and back to original host.
  • Shutdown and power-on the virtual machines.

NOTE: If you use this option to disable TPS, you MUST manually reconfigure this option (by Mem.ShareScanGHz to “4″) after applying the Patch or Update before you can enable salting on the ESXi host.

What if you want to continue using TPS after the Patch/Update?

A couple of new Advanced Configuration options are introduced by the Patch (and these will be preserved by the Update as well):

  • Mem.ShareForceSalting: This is a host-level configuration option. This is what disables/enables TPS on an ESXi host. If this is set to “0″, it means that TPS is STILL enabled on the host. If set to “1″, it means that TPS has been disabled on the Host, and salting is required in order for TPS to work on any VM located on that host.
  • sched.mem.pshare.salt: This value enables customers to selectively enable page sharing between/among speficic VMs. When ShareForceSalting is set to “1″ on an ESXi host, the only way for two or more VMs to share a page is for both their salt and the content of the page to be same. The salt is the value specified by customers for this per-VM Advanced Configuration option. This value must be identical on all the VMs that you intend to enable page sharing for.

IF ShareForceSalting is set to “1″ and the sched.mem.pshare.salt is not set on a VM, the VM’s vc.uuid will be substituted for the salt value instead. Because the vc.uuid is unique to a VM, that VM will only be able to share page with itself – effectively, no sharing for this VM.

What should you watch out for?

If you are currently over-provisioning resources in your business critical applications cluster, you should review and re-evaluate your usage and consider adding resources to the vSphere Cluster or re-sizing your VMs. Because TPS is largely about memory, adding more memory to the ESXi hosts, or reducing memory allocated to the VMs, will be sufficient remediation.

Without adequate re-sizing or additional resources, the immediate side effect of this change will be an increase in memory contention and performance degradation which will, consequently, be accompanied by swapping and ballooning.

If you are not over-committing resources, or if you are reserving memory for your critical applications workloads as recommended, your workloads will not be negatively impacted by this change in TPS behavior.

Featured post

Just Published – Virtualizing Active Directory Domain Services On VMware vSphere®

Announcing the latest addition to our series of prescriptive guidance for virtualizing Business Critical Applications on the VMware vSphere platform.

Microsoft Windows Active Directory Domain Services (AD DS) is one of the most pervasive Directory Services platforms in the market today. Because of the importance of AD DS to the operation and availability of other critical services, applications and processes, the stability and availability of AD DS itself is usually very important to most organizations.

Although the “Virtualization First” concept is becoming a widely-accepted operational practice in the enterprise, many IT shops are still reluctant to completely virtualize Domain Controllers. The most conservative organizations have an absolute aversion to domain controller virtualization while the more conservative organizations choose to virtualize a portion of the AD DS environment and retain a portion on physical hardware. Empirical data indicate that the cause of this opposition to domain controller virtualization is a combination of historical artifacts, misinformation, lack of experience in virtualization, or fear of the unknown.

The new Guide – Virtualizing Active Directory Domain Services On VMware vSphere® – is intended to help the reader overcome this inhibition by clearly addressing both the legacy artifacts and the new advancements in Microsoft Windows that help ameliorate the past deficiencies and make AD DS more virtualization-friendly – and safer.

With the release of Windows Server 2012, new features alleviate many of the legitimate concerns that administrators have about virtualizing AD DS. These new features, the latest versions of VMware® vSphere®, and recommended practices help achieve 100 percent virtualization of AD DS.

The Guide includes a number of best practice guidelines for administrators to help them optimally and safely deploy AD DS on VMware vSphere.

The recommendations in this guide are not specific to a particular set of hardware or to the size and scope of a specific AD DS implementation. The examples and considerations in this document provide guidance, but do not represent strict design requirements.

Similar to other “Best Practices” releases from VMware, this Guide is intended to serve as your companion and primary reference guidepost if you have any responsibility planning, designing, implementing and operating a virtualized Active Directory Domain Services instance in a VMware vSphere infrastructure.

This guide assumes a basic knowledge and understanding of vSphere and AD DS.
Architectural staff can use this document to understand the design considerations for deploying a virtualized AD DS environment on vSphere.
Engineers and administrators can use this document as a catalog of technical capabilities.
Management staff and process owners can use this document to help model business processes that take advantage of the savings and operational efficiencies achieved with virtualization.

You can download Virtualizing Active Directory Domain Services On VMware vSphere® here.

Featured post

Which vSphere Operation Impacts Windows VM-Generation ID?

In Windows Server 2012 VM-Generation ID Support in vSphere, we introduced you to VMware’s support for the new Microsoft’s Windows VM-Generation ID features, discussing how they help address some of the challenges facing Active Directory administrators looking to virtualize domain controllers.

One of the common requests from customers in response to the referenced article is a list of events and conditions under which an administrator can expect the VM-Generation ID of a virtual machine to change in a VMware vSphere infrastructure. The table below presents this list. This table will be included in an upcoming Active Directory on VMware vSphere Best Practices Guide.

Scenario VM-Generation ID Change
VMware vSphere vMotion®/VMware vSphere Storage vMotion No
Virtual machine pause/resume No
Virtual machine reboot No
HA restart No
FT failover No
vSphere host reboot No
Import virtual machine Yes
Cold clone Yes
Hot clone
Note
Hot cloning of virtual domain controllers is not supported by either Microsoft or VMware. Do not attempt hot cloning under any circumstances.
Yes
New virtual machine from VMware Virtual Disk Development Kit (VMDK) copy Yes
Cold snapshot revert (while powered off or while running and not taking a memory snapshot) Yes
Hot snapshot revert (while powered on with a memory snapshot) Yes
Restore from virtual machine level backup Yes
Virtual machine replication (using both host-based and array-level replication) Yes

If you have a specific operation or task that is not included in the table above, please be sure to ask in the comments section.

Thank you.

Disaster Recovery for Virtualized Business Critical Applications (Part 3 of 3)

Planned Migration:

One of the relatively newer use cases for SRM is planned migration. With this use case, customers can migrate their business critical workloads to the recovery or cloud provider sites in a planned manner. This could be in planning for an upcoming threat such as a hurricane or other disaster or an actual datacenter migration to a different location or cloud provider.

Continue reading

Disaster Recovery for Virtualized Business Critical Applications (Part 2 of 3)

Protection Groups:

A protection group is a group of virtual machines that fail over together to the recovery site. Protection groups contain virtual machines whose data has been replicated by array-based replication or by VR. Typically contains virtual machines that are related in some way such as:

  • A three-tier application (application server, database server, Web server)
  • Virtual machines whose virtual machine disk files are part of the same datastore group.

Continue reading

Disaster Recovery for Virtualized Business Critical Applications (Part 1 of 3)

The purpose of the exercise was to demonstrate use cases for disaster recovery of  real business critical applications (BCA) leveraging VMware solutions such as VMWare Site Recovery Manager (SRM). Techniques to protect  against disaster for common business critical applications such as Microsoft Exchange, Microsoft SQL Server, SAP and Oracle Databases are discussed.

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.

We configured the following setup.

ascs_blog_1

We have two virtual machines: a SAP dialog instance (processes OLTP requests)  and  database instance in one; and  Central Services in the second. The objective was to focus on performance of the standalone Central Services virtual machine that was servicing an ABAP based workload. For the ABAP stack Central Services is officially referred to as ABAP SAP Central Services (ASCS).  The goal of the test was to scale up to 1000 OLTP users running transactions in the SAP Sales and Distribution module.  The following metrics were measured (via vCenter): the maximum CPU usage of the ASCS virtual machine during the workload run; the maximum network usage of the ASCS virtual machine during the workload run. The following graph shows the results.

ascs_blog_2

Summarizing the results:

  • At 1000 users the maximum CPU utilization of the ASCS virtual machine was 29%. This is a comfortable utilization to run in production. The number of SAP lock requests (referred to by SAP as enqueues and dequeues) was over 10000 per minute during one point in the run (eyeballed via SAP transaction SM12).
  • We can see a fairly linear relationship between CPU usage and the number of users.
  • Lock requests generate network traffic between the SAP dialog instance and the ASCS service – we see that the network usage is fairly linear as users are scaled up. Note: there are no lock requests between the SAP database and Central Services.

It is recommended to validate SAP workloads in a pre-production performance test before go-live. Customer tests/workloads will show different results to those shown above as the frequency of SAP lock requests depends on the transaction think times and customer specific business processes (the transaction think times used in this test were < 20 seconds).  Customer environments should also consider batch jobs running at the same time as OLTP activity that by design are generating a lot of locks e.g. mass update of business documents – this would create additional load on Central Services.

OLTP performance on Virtualized SQL 2014 with All Flash Arrays


TPC-C Benchmark is an on-line transaction processing (OLTP). (TPCC Main site) TPC-C uses a mix of five concurrent transactions of different types and complexity. The database is comprised of nine types of tables with a wide range of record and population sizes. TPC-C is measured as transactions per minute (TPM).

The goal of this exercise was to see if 1 million TPM can be achieved on virtualized SQL 2014 backed by an all Flash storage array for a TPC-C like test.  The TPC-C testing would be compared between two VM sizes (Within NUMA & Exceeding NUMA boundaries)

Continue reading

Effect of VAAI on cloning with All Flash Arrays:

Cloning virtual machines is an area where VAAI can provide many advantages. Flash storage arrays provide excellent IO performance. We wanted to see what difference VAAI makes in virtual machine cloning operations for “All Flash Arrays”.

The following components were used for testing VAAI performance on an all Flash storage array:

  1. Dell R910 server with 40 cores and 256 GB RAM
  2. Pure FA-400 Flash Array with two shelves that included 44 238 GB Flash drives and 8.2 TB usable capacity.
  3. Centos Linux Virtual Machine with 4 vCPU, 8 GB RAM,  16 GB OS/Boot Disk & 500 GB Data Disk all on the Pure Storage Array
  4. SW ISCSI on dedicated 10GBPS ports.

Test Virtual Machine:

The virtual machine used for testing was a generic Centos Linux based system with a second virtual data disk with 500GB Capacity.  To make the cloning process be truly exercised, we want this data disk to be filled with random data. Making the data random ensures that the data being copied is not repetitive in any way and is not easily compressed or de-duplicated.

 Preparing the Data Disk:

The following command was used to create a large 460 GB file with random data with “dd” command on Linux.

dd if=/dev/urandom of=/thinprov/500gb_file bs=1M count=4600000

The disk space used in the data disk is shown below and it contains only the random data file generated with dd command.

root@linux01 thinprov]# df

Filesystem           1K-blocks      Used Available Use% Mounted on

/dev/mapper/VolGroup00-LogVol00 10220744   2710700   6982480  28% /

/dev/sda1               101086     20195     75672  22% /boot

tmpfs                         4087224         0   4087224   0% /dev/shm

/dev/sdb1            516054864 469853428  19987376  96% /thinprov

 Tuning for VAAI and best performance:

VAAI can be enabled or disabled using the following settings: (1 enables, 0 Disables)

esxcli system settings advanced set –int-value 1 –o /DataMover/HardwareAcceleratedMove

esxcli system settings advanced set –int-value 1 -o /DataMover/HardwareAcceleratedInit

esxcli system settings advanced set –int-value 1 -o /VMFS3/HardwareAcceleratedLocking

esxcli system settings advanced set –int-value 1 -o /VMFS3/EnableBlockDelete

Adjust Maximum HW Transfer size for better copy performance:

esxcli system settings advanced set –int-value 16384 –option /DataMover/ 
MaxHWTransferSize

For larger I/O sizes its found in experiments that settings IOPS to 1 have a positive effect on latency

esxcli storage nmp psp roundrobin deviceconfig set –d <device> -I 1 -t iops

On ESXi 5.5, DSNRO can be set on a per LUN basis!

esxcli storage core device set -d <device> -O 256

Set Disk SchedQuantum to maximum (64)

esxcli system settings advanced set –int-value 64 –o /Disk/SchedQuantum

Phase 1: Cloning with VAAI disabled:

For the first phase of the study VAAI was turned off and the settings validated. The cloning process was initiated for the Linux virtual machine and some of the key metrics were observed and captured at the storage array and in vCenter performance charts.

The cloning process was carefully monitored and the time for the cloning operation was observed to be 63 minutes.

VAAI1

 

The time in the chart between 2:06 and 3:09 PM represents the cloning operation shown as the blue area. There is a spike in latency (>2ms), IOPS (5000) and Bandwidth utilization around 420 MBPS during this cloning operation.

VAAI2

Phase 2: Cloning with VAAI Enabled:

For the second phase of the study VAAI was turned on and the settings validated. The cloning process was initiated for the Linux virtual machine and some of the key metrics were observed and captured at the storage array and in vCenter performance charts.

The cloning process was carefully monitored and the time for the cloning operation was observed to be 19 minutes.

VAAI3

 

The time in the chart between 3:54 and 4:13 PM represents the cloning operation shown as the blue area. There is a minimal spike in latency (0.5ms), IOPS (3000) and Bandwidth utilization around 10 MBPS during this cloning operation.

VAAI4

The performance chart for network usage does not correlate with the 10 MBPS average utilization during the cloning operation. The network utilization at the vSphere host level during the operation shows no increase in network utilization as was seen with the Non VAAI operation. This clearly shows that all the network activity occurs within the storage array with no impact the vSphere host.

Effect of VAAI on the cloning operation:

The observations highlight the huge impact that VAAI has on a large copy operation represented by a VM clone. A clone of a VM with 500 GB of random data benefits significantly through the use the use VAAI compliant storage as shown in the following table.

VAAI5

 

Arrays that are VAAI capable such as the Pure Storage array used in this study dramatically improves write intensive operations such as cloning by reducing time of impact, latency, IOPS and bandwidth consumed. This study shows that even all flash arrays that have fast disks with huge IOPS can significantly benefit from VAAI for cloning

 

 

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

Availability:

Availability of the applications is one of the important requirements for business critical applications. The vSphere platform provides capabilities to protect against hardware and software failures  to meet the stringent SLA requirements of business critical applications.

Virtualized applications can avail of features such as vSphere HA protects from HW failures by restarting virtual machines on surviving hosts if a physical host were to fail. vSphere FT  (Fault Tolerance) protects critical servers such as load balancers and other central servers with a small footprint (1vCPU) with zero downtime in the event of HW failures.

vSphere App HA for Application level protection for supported applications. Third party solutions that leverage vSphere Application Awareness API such as Symantec Application HA , NEVERFAIL, etc. layer on top of VMware HA and provide monitoring and availability  for most of the common business critical applications.

HA_Picture1

 

Traditional availability clusters like MSCS and Linux based clusters can be layered on top of vSphere HA, but quite often create restrictions relating to vMotion and other functionality in VMware environments. Currently the only use case that these solutions provide not provided by the Application HA solutions available on VMware is the ability to have reduced downtime during patch related activity requiring system reboot. If there is allowance for downtime for patch maintenance using traditional clusters can be avoided.

Manageability:

The ability to proactively manage business critical applications is a very important requirement. Virtualized business critical applications can leverage the vCenter Operations (VCOPS) suites of solutions to effectively manage their environment. VCOPS provides tactical (Right Now) and Strategic (Future Focused) capabilities to monitor performance and manage the capacity of the environment proactively.

VCOPS provides tactical monitoring and strategic planning

 

vCOPS1VCOPS also provides ability to perform root cause analysis on problems in the environment in a time efficient manner to reduce impact on business critical applications.

VCOPS smart alerts

 

 

vCOPS2Changes made to the environment can be correlated to the health, while also helping to diagnose the impact of the change on an application or environment.

Correlate events with changes made to environment

 

vCOPS3Supportability:

All major x86 applications are supported on VMware and actively being deployed by our customer.

Supportability

Agility:

Most application owners and DBAs virtualize Oracle or SAP for cloning. Creating application instances and refresh of data across environments such as production, development, test and QA is very time consuming and resource intensive.

With vSphere, any application can be templatized and easily cloned to be rolled out into these environments with minimal effort.  This agility provides application owners improved time to market of their solutions and increased productivity.

Easy cloning between production and other environments

 

AgilityDisaster Recovery:

One of the critical requirements for business critical applications is the need for disaster recovery with minimum possible downtime (Recovery Time Objective) and minimum loss of data (Recovery Point Objective).

Traditional disaster recovery for business critical applications with physical servers has many limitations such as the need for identical hardware in recovery site and downtime for production during testing. In a virtual environment, every virtual machine is encapsulated in a series of files that can be easily moved and instantiated in the recovery locations.

VMware Site Recovery Manager (SRM) provides a strong workflow engine that provides automation through centralized recovery plans, automated failover and failback and planned migration capabilities. SRM provides the ability to perform non-disruptive testing and leverages vSphere and Array based replication to replicate the data to the disaster recovery site.

Majority of the customers virtualizing business critical applications leverage SRM for their Disaster Recovery needs. SRM drastically reduces the RPO and RTO and helps them meet stringent business availability requirements.

SRM provides automated disaster recovery capabilities

 

SRM1Conclusion:

The critical concerns of business critical application owners are adequately addressed by VMware’s suite of products and solutions. There is no reason not to virtualize your business critical applications. The trends shown below clearly attest to these capabilities.

Strong growth in Adoption of BCA virtualization

 

BCA_trendsPart 1 of series can be found at “Critical Factors to consider when virtualizing Business Critical Applications: (Part 1 of 2)

 

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.

Dedicated Database Cluster for SAP

Dedicated Database Cluster for SAP

 


 

 

 

 

 

 

When there are no restrictions with licensing,  the typical cluster design methodology in vSphere environments espouses having an N+2 cluster.  An N+2 cluster would provide headroom for doing maintenance (One host at a time) and high availability (One host failure). These additional hosts can be costly for the database cluster due to the need to license all hosts.  In this situation the applications run in their own cluster, which typically is N+2.

SAP Applications in their own cluster

Dedicated APP Cluster for SAP

APP_Cluster

 

 

 

 

 

 

 

 

Most database vendors allow for a non licensed DB host, if the only purpose of these hosts is to function as a standby in the event of a failure. There are many conditions such as the number of actual days the standby takes over per year and other requirements that need to be met. vSphere clusters have a setting called dedicated failover host, which can be leveraged in database clusters to match the requirements of standby hosts.  One can potentially meet these conditions for standby node, by running all workloads in normal circumstances on licensed nodes with the dedicated failover node minimally being used only during actual failure or maintenance.

Scenario 2:  Database licensed through SAP along with SAP software:

When databases are licensed through SAP, there is no impact of database placement on licensing. This is akin to “named user” based licensing. There is a lot more flexibility to locate the database servers anywhere in the environment. Customers typically collocate the database servers along with the application servers for proximity and ease of management. The commonly used N+2 clusters can be leveraged in this scenario to allow for HA capacity even during maintenance.  All nodes can be fully utilized to run workloads.

SAP Applications and Databases in the same cluster

Hybrid_Cluster

 

 

 

 

 

 

 

 

Conclusion:

Cluster design in SAP environments can be impacted by the type of database licensing. Creating a dedicated database cluster for certain situation, can help meet many of the stringent licensing requirements, while still providing for consolidation and optimized utilization.

 

 

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.

CIOs and IT operations want to virtualize more because of the following advantages of virtualization:

  1. Infrastructure efficiency
  2. Simpler management
  3. Built-in availability
  4. Greater agility
  5. Simplified DR

But Application owners are usually reluctant because:

  1. Will my Application perform well? (Performance)
  2. Will it Scale? (Scalability)
  3. Can I meet my application SLAs? (Availability )
  4. Can I manage it effectively? (Manageability)
  5. Will my ISV support me? (Supportability)
  6. What’s in it for me? Will my application run better? (Agility & Time to Market)

Performance:

Virtual performance is about 5-6% of physical for most business critical application workloads. The benefits of virtualization and productivity improvements overshadow the small overhead it introduces.

SAP Performance within 6% of Native:

SAP Performance on vSphere vs Physical

 

BCA1Exchange Server Performance:

Exchange Virtualization study discussed in Running Microsoft Apps on FlexPod for VMware  shows only a 5% performance difference between virtual and physical.

Exchange performance on vSphere

 

BCA2

Database Performance:

SQL and Oracle performance close to Native as seen in the test results below.

SQL Throughput on vSphere vs Native
BCA3

Oracle RAC performance vs Native on vSphere

BCA4

It is proven that the performance of the common business critical applications are very close to their physical counterparts and performance should never be a concern for virtualizing them.  During virtualization there is usually a hardware refresh to the latest and greatest hardware with superior performance to existing systems. The small overhead of virtualization is easily offset while moving to this newer hardware as part of the virtualization migration.

Scalability:

With the vSphere 5.x platform, almost all workloads are amenable to virtualization.  VMware capabilities, such as vNUMA allows for NUMA aware operating systems and applications to run optimally even in virtual environments.

Scalability of vSphere

 

BCA5Workloads can scale up dynamically as demand increases with hot add capabilities for CPU, memory and storage resources as and when needed.  One can scale up or scale out based on the application requirements.

“Scale up” versus “Scale out”

BCA6

These hot add capabilities are available only in virtualized environments and help right size environments and grow them dynamically, when needed without user downtime and loss of productivity. The following graphic shows the effect of increasing CPU on an Oracle DB server by 2 vCPU demonstrating the dynamic scale up capabilities of the vSphere platform.

Oracle Hot Add CPU Illustration

BCA7

 

Part 2 of series can be found at  ”Critical Factors to consider when virtualizing Business Critical Applications: (Part 2 of 2)