A colleague of mine dropped by my desk on Friday to talk about storage best practices for virtualized databases (SQL Server in this case). He observed a VMware deployment where the data and log files for a SQL Server virtual machine were consolidated on a single VMFS volume backed by a RAID 5 LUN. “Is this a VMware best practice?” he asked. “Should you not put the redo logs on a RAID 10 LUN?” The answers are ‘no’ and ‘yes’, respectively. And with the solid state disk (SSD) auto-tiering from EMC (FAST) the second answer is an emphatic “YES!”
Scott Drummonds on Virtualization
Do you have any running instances of ESX 3.5 or older? Are those instances running on processors that are no more than a couple of years old? If so, I have a tip for you: update your hosts to ESX 4.0. Seriously, upgrade to vSphere already. It’s been out for a year!
Fixed recommendations for consolidation ratios are cancerous. Whether we are talking about vCPUs per core, virtual machines per host, or VMDKs per LUN, there is no single number the represents the “right” ratio. Accurate guidance requires workload characterization and fine tuning using vSphere’s performance counters. Today I want to highlight one experiment that shows application choice impacting VMDK-to-LUN consolidation. The inescapable conclusion is that sequential access data must be separated from random access files!
A few days ago someone forwarded me a blog article with an interesting claim about KVM performance:
Testing results from internal and customers showed SAP workloads: 85-95, Oracle OLTP: 80-92% bare metal. LAMP stack showed better than bare metal performance. Whitepapers will be published in how this was achieved. Java achieved up to 94% bare metal.
Frankly, I was surprised to hear this. KVM is a hosted virtualization platform, equivalent to the free VMware Server, which runs on top of a host operating system. VMware server is fine for a virtual machine or two, but you would not want it hosting your critical business applications. The above KVM claim suggests that KVM possesses hypervisor-like performance. So we ran a test with a few virtual machines to see what we could learn. These tests confirmed my suspicions: KVM is a very long way from enterprise-class virtualization performance.
[This is an update to one of my favorite articles, which details my on-site investigation of SQL Server performance problems.]
Back in July I had the privilege of riding along with VMware’s Professional Services Organization as they piloted a possible performance offering. We are considering two possible services: one for performance troubleshooting and another for infrastructure optimization. During this trip we piloted the troubleshooting service, focusing on the customer’s disappointing experience with SQL Server’s performance on vSphere.
[New content has been added to this is an update to an old article from the performance community.]
Newer processors are much more important to virtualized environments than the non-virtualized counterpart. Generational improvements have not just increased the raw compute power, they have also reduced virtualization overheads. This blog entry will describe three key changes that have particularly impacted virtual performance.
[First re-post of an old favorite. This document is my most popular blog entry from the communities.]
Microsoft SQL Server runs at better than 80% of native on VI3 in most benchmarked environments. In production environments, and under loads that model those conditions, SQL Server runs at 90-95% of native on ESX 3.5. I can say this with confidence despite a large amount of the industry’s skepticism because I’ve spent so much time on SQL Server in the past half year. I’d like to share some of my research on the subject and observations with you.