Upgrading SAP Finance in a virtual environment (RDM vs. VMFS)

As mentioned in an earlier post we have clients running SAP Finance applications. One of them is now going to upgrade to the latest version and because we host the application platform for them we will expand the infrastructure to hold the test environment and also upgrade from ESX3.5 to vSphere. As was the case last time we again have some anti-virtualization recommendations being done by the application consultants. As the solution is proven to work now for almost a year without fault (with an actual HA event no less) we fortunately have some leverage with regards to how we want to run the environment.

This time the discussion focuses on the use of RDM LUNs versus VMFS LUNs for hosting the SQL Server database files. Currently RDM’s are used mostly because earlier predictions were that the total DB size would near 1TB and we wanted to use SAN-based backup. In the mean time though there has been a switch to Veeam Backup & Replication for backup and DR purposes and that solution does not work with RDM LUNs. No problem as such but as we are preparing this upgrade/migration it is something to look at with regards to optimization. Also the size of the largest DB turned out to be about half the earlier prediction.

During my research on the subject I found it fortunate to have followed the VMware Design course recently as the subject of RDM vs. VMFS is a topic in the training. It was especially interesting to hear the differences on this topic related to what kind of SAN people were using/selling (NetApp, Equallogic, HP/Lefthand were mentioned most).

I also found some excellent papers and posts on the subject:

• http://vmetc.com/2009/04/13/use-rdms-for-practical-reasons-and-not-performance-reasons/
• http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf
• http://www.virtuallifestyle.nl/2010/01/recommended-detailed-material-on-rdms/

As soon as we have our final recommendation I’ll write another post explaining what we have chosen to recommend and why.

Running SAP BFC (Magnitude) 100% virtualized

Last year we got a request from a client who wanted an application environment for his SAP BusinessObjects Financial Consolidation (formerly Cartesis Magnitude) application. The new environment would be used for group consolidation for a number of companies with most of them located in EMEA. Because of the relative importance of the availability of this environment it was our goal to realize a 100% virtualized environment so we could use VMware HA, vMotion etc.

The reason for this blogpost is to explain that this can be done and that it does work and perform up to and above specification. This in contrast to popular belief among product specialists and third party consultants for the product itself who were trying to convince the client that this product would not run (perform) in an VM.

What we ended up doing was the following:

• Based on product usage characteristics and an existing design for the environment in physical servers we proposed an alternative in the form of a Virtual Infrastructure
• This VI (then based on VMware VI3.5 Enterprise) was housed in an external datacenter with the right facilities (connections, power, cooling, building design etc.) to guarantee sufficient uptime
• Use Veeam Backup&Replication to replicate the entire environment to a secondary location for DR purposes

The complete application environment uses Citrix XenApp and Citrix Access Gateway SSL VPN to deliver the application to the users. Apart from security appliances such as the Access Gateway and firewall devices only the Citrix servers are physical. This choice was made based on the expected high utilization of the Citrix servers and our choice to host only the application related servers in the VI. All other servers (file, web, application, SQL2005 database and analysis, domain controllers) are virtual machines.

To get the necessary storage performance for the SQL 2005 (64bit) database we created dedicated LUNs for the database logfiles and datastores on the FC SAN. VMware has published some excellent whitepapers on SQL Server and SAP sizing: http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf and http://www.vmware.com/files/pdf/SAP-Best-Practices-White-Paper-2009.pdf for example. The total size of the datastores is well over 500GB by the way.

The virtual machines are almost all SMP machines (either two or four-way SMP) because of peak performance caused in consolidation and reporting runs and this works well. To avoid performance issues we did adopt the rule that CPU overcommit would be held to a minimum, because we knew that come peak time several servers on the same host would be fighting for resources.

After implementation of the environment there was a performance and acceptance test and the whole environment performed as good or better than the environment where the application was migrated from. Plus we now have the added benefits of virtualization with regards to availability. Another benefit of having the whole environment fully virtualized is that with Veeam Backup and Replication we are now able to replicate the whole environment to a target host in a second datacenter and switch over to that environment should there be a problem in the primary location. I am not completely unbiased with Veeam but if you compare cost and value it keeps amazing me how much you can do with it for a relatively low investment compared with traditional backup software solutions.