Home > Blogs > Virtualize Business Critical Applications


Performance of SAP Central Services with VMware Fault Tolerance

Many SAP customers in their virtualization journey are considering the option to protect SAP Central Services with VMware Fault Tolerance (FT). 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. It is a strong candidate for VMware FT and we have conducted a 1000-user test in vSphere 6.X which is documented in Section 4  of the SAP VMware Best Practice Guide .

The VMware vSphere 6 Fault Tolerance whitepaper mentions “One of the most common performance observations of virtual machines under FT protection is a variable increase in the network latency of the virtual machine”. Given this how does Central Services and VMware FT impact the performance of the SAP application as experienced by the SAP business user – I will demonstrate a basic example here.

A  potential validation at the infrastructure level could be to run the network “ping” command and SAP utility “niping”. “niping” is a SAP network utility used to help analyze network performance.  When I ran these commands at the OS command line to test network performance between an SAP application server and Central Services in two separate VMs, results showed an increase in latency from about 0.3 to 1.8 ms when VMware FT was turned on for the Central Services VM . This is expected behavior and does not reflect the performance experience that a SAP business user will see with VMware FT.

My next test was to construct a basic SAP application level test.  This test is a custom SAP program (written in ABAP), that automates the change of a sales order document and once executed will update around 50 sales orders automatically in series. For each sales order that is changed a lock is created and managed by Central Services. The program uses standard SAP techniques based on SAP “BDC” for mass input of data by simulating user inputs in screens of transactions. The SAP transaction being called is the Change Sales Order transaction (“VA02”). The program is executed in online mode/foreground via the SAP client SAPGUI.  After each online interaction SAPGUI records the response time at the bottom right in milliseconds – this was used as the performance metric.

The following diagram shows the test environment.

The following tables shows the results.

The difference in average online response time between VMware FT off and on is around 2%. The tests simulate a single user executing the change sales order transaction multiple times very quickly. This is a basic validation which should be followed by a multi-user test with actual users or business workloads simulated in a software testing tool. Note that other tests will show different results than shown here and mileage is expected to vary. In this example the simulated user is making many document changes in a short period of time with no think time. In reality an online business user will spend more time processing data within a transaction which is activity that does not require Central Services but resources on the application server hence the frequency of lock requests generated by a single user would be less than in this example.

This entry was posted in ESXi, SAP, vSphere on by .

About Vas Mitra

Vas is a SAP Solutions Architect who has worked on SAP + business critical apps related initiatives at VMware over the past 5+ yrs. Activities include SAP on VMware training/workshops, POCs, pre-sales support and development of SAP on VMware whitepapers and best practice guides. Prior to VMware Vas’ roles and experiences include: SAP Basis Administrator; SAP ABAP developer; SAP Solutions Engineer. These roles have been with a large Systems Integrator, server vendor and SAP IT operations in pharmaceutical/chemical companies.

Leave a Reply

Your email address will not be published. Required fields are marked *

*