Home > Blogs > Virtualize Business Critical Applications > Monthly Archives: October 2017

Monthly Archives: October 2017

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.

The Art of P2V and Oracle ASM

“Come with me if you want to live” – famous words from the Terminator series.

It’s also the very reason IT companies are adopting the ‘Virtualize First’ policy to reap all of the benefits of virtualization and move away from the soon to be legacy bare metal architecture world and ‘save a bunch of money’ , just as the Gecko said.

As part of the Virtualization journey, one of the tools VMware Professional Services (PSO), Partners and Customers use to migrate applications from physical x86 servers (Windows & Linux) to VMware Virtual Machine (VM) is using the VMware Convertor tool, the process known as P2V (Physical to Virtual). It transforms the Windows- and Linux-based physical machines and third-party image formats to VMware virtual machines.

One of the most common question I get talking the VMware field, Partners & Customers as part of my role is ‘Can I use VMware Convertor to migrate Oracle databases from physical x86 running  Linux / Oracle OVM running Linux to VMware vSphere platform ?’ , the answer, famous 2 words , ‘it depends !!’ .

Let me explain why I said that.

 

Database Re-Platforming

Oracle databases, being the sophisticated ‘beasts of burden’, there are many key factors to be kept in mind when we embark on an Oracle database re-platforming exercise, either between same / different system architectures, bare metal to bare metal / physical to virtual architecture, some of them include:

  • source and destination system architecture
    • are we moving between like architectures (x86 to x86)
    • are we moving between from a big endian system to a little endian system (Solaris / AIX / HP-UX to x86)
  • size and operating nature of the database (terabytes / production, pre-prod, dev, test etc)
  • database storage (File system / Oracle ASM)

More information on Handiness can be found in the link below
https://en.wikipedia.org/wiki/Endianness

So, if your use case is moving Oracle databases from a big endian system to a little endian system (Solaris / AIX / HP-UX to x86), Stop Right here, you cannot use the VMware Convertor tool to migrate databases between RISC Unix and Linux x86. You need an Oracle Plan and Design exercise to migrate Oracle databases between these 2 systems.

Keep reading if you are replatforming Oracle database between x86 platforms i.e. Physical server / Virtual machine (VMware vSphere / Oracle OVM) to VMware Virtual Machine (VMware).

Continue reading