Photo from @sqlrus
Tonight I was lucky enough to be able to present to my home SQL Server Users Group in Omaha, Nebraska. I gave my presentation ‘Squeezing Top Performance from your Virtualized SQL Servers’ to a packed house. I thoroughly enjoyed the session, and hope you did too!
To those who attended, the slides are now available for you to download here. Thanks for attending my session, and please let me know if you have any questions that I can answer!
Hello,
I just stumbled across your site today while researching vFRC. It is great to see a SQL guy focused virtualization. I’ve known many DBA’s in my past that sneer loudly at VM’s. We have virtualized all of our SQL servers on VMware 4.1 and are moving to new host hardware on 5.5. I’ve always tried to segregate SQL I/O types to their on VMDK’s at a bare minimum separate data and log drives. One thing I have not justified is creating back-end LUN’s for all of these on our Fast Cache enabled VNX (FiberChannel). We typically create 1T LUN’s and fill ’em up to 10% free space remaining with however many VM’s it takes. For several of our larger SQL VM’s a single LUN is dedicated to all its VMDK’s.
Have you done any performance testing on separate LUN’s vs all on the same LUN? I don’t have a lot of time to do performance testing as I’m cook, dishwasher and hostess round here.
Regards
Ron
Thanks for the great comments! I appreciate it!
I have done some testing against multiple LUNs vs. a single LUN. I’m quite partial to multiple LUNs, but it varies by workloads. If you find that you are getting I/O contention down a single path to a LUN, the hypervisor can do quite a good job of multipathing the I/O. You could move different virtual disks to different LUNs and spread out your heavy-hitting workloads accordingly. However, some environments are either lightweight in their I/O requirements, or the infrastructure is very robustly architected, and the bottlenecks in a round trip to the LUN and back could be hidden by other bottlenecks, and not evident. In this case, you might be good as-is.
Just check with your storage folks and see what sort of path utilization they see for your LUNs, and go from there. If you see high utilization, I’d start spreading out the workload to better balance the environment. If you have active multipathing going on, latency numbers across the board are low enough, and no imbalance in the pathing or LUN utilization are present, you are good to go! Just check in on it periodically, as workloads change over time. Thanks for the great question!