VMware Communities > Blogs > Manual Automation > 2008 > November > 12

Blog Posts

Manual Automation

Previous Next
4

To give you a little background, I now have 6 ESX hosts with 58 VMs. Each host has dual-iSCSI HBAs with 1GbE connections. All Exchange 2007 roles have been virtualized, however we currently only have 1 out of 5 mailbox servers running as a virtual machine. We have a number of other workload types virtualized including file, print, SQL, web servers, etc.

Management has decided to stop virtualizing Exchange servers. Why? Fear generated by the FUD that surrounds the performance characteristics of various storage transports - in this case iSCSI via GbE. The only way to fight FUD is with facts. Towards this effort I have performed some calculations in an attempt to answer 2 questions:

1. How well is our storage transport performing given current virtualized workloads?

2. How much "performance capacity" do we have remaining?


I added up the average bandwidth utilization of all 6 of my ESX hosts which totaled 11008KBps. This converts to 0.09Gbps out of 2Gbps or 4.5% bandwidth utilization. I then added up the maximum utilization of all 6 ESX hosts. This would be the high-point of the peaks or bursts in utilization. The result was 0.48Gbps.


Assuming we can get 800Mbs of actual bandwidth per connection we have 1.6Gbps useable bandwidth remaining. Note that based on VMware's testing we should be able to reach near wire-speed (2Gbps) if the environment is configured correctly making 1.6Gbps a conservative assumption.


So even if I use the maximum bandwidth measurement of 0.48Gbps, that leaves 1.1Gbs useable. Another way to state it is that my environment is reaching a max of 30% bandwidth utilization.


The results seemed unbelievable to me at first so I digged a little deeper:


  1. I found this in a EqualLogic presentation from 2005: "With 2 iSCSI connections and free NIC teaming, payload equals approx. 234 MB/s (1.96Gb/s) or 823GB/Hour. We found 2Gb FC delivers 196 MB/s which equals approx. 689GB/Hour payload." http://communities.vmware.com/servlet/JiveServlet/downloadBody/1806-102-1-1554/VMUG.ppt
  2. I found this in an iSCSI Virtualization whitepaper from 2007: "For high-performance, mission-critical servers, the cost of Fibre Channel is often justified, because Fibre Channel provides higher bandwidth (4 Gbps vs. 1 Gbps) and lower latency than IP networks. However, many environments are over-served by 4Gbps Fibre Channel links. This is particularly true for hosts running applications characterized by random traffic, such as database applications and Exchange."
    http://www.dell.com/downloads/global/products/pvaul/en/iscsi_virtualization.pdf
  3. And here's one from Netapp: "...based on deployments, Netapp has proven over the past 3 years that a scalable, simple to use array with enterprise class reliability can safely be the iSCSI platform for mission-critical applications. Exchange is a perfect
    example of a mission critical application that is routinely deployed over iSCSI these days."
    http://storagefoo.blogspot.com/2006/05/iscsi-performance-and-deployment.html
  4. Finally, VMware's own testing of storage protocols and their corresponding physical medium from this year: "This paper demonstrates that the four network storage connection options available to ESX Server are all capable of reaching a level of performance limited only by the media and storage devices."
    http://www.vmware.com/files/pdf/storage_protocol_perf.pdf
It's important to note that I'm leaving 2 things out of this consideration:
1. I typically read how FC has lower latency than IP. My somewhat empirical belief is that IP's additional latency will not be a big factor when added to the equation.
2. I've read different sources that state disk IOPS are more important with regards to system performance than storage transport bandwidth utilization.
I'm still looking for a way to quantify these factors to better predict the performance characteristics of our IP storage implementation. This is the first part of what I'm sure will be an on-going investigation. It sure would be nice to have a tool that did all of this for me! I have yet to find something that's comprehensive enough on any given storage platform I've managed (IBM DS, EMC Celerra, et al).

Also note that I've been monitoring my bandwidth utilization more closely using Vkernel's Capacity Analyzer and can safely say that 11008KBps is high. It's dropped 30-40% over the last two months for various reasons.


Next month I hope to enable jumbo frames in this environment and expect to see some additional performance gain at some level. I'm considering capturing before/after snapshots of various performance metrics and posting the results in a future blog.


In conclusion, this analysis makes me even more confident about the performance of our ESX hosts and virtual infrastructure backend storage transport even if/when I get to virtualize the remaining Exchange mailbox servers.



Add a comment Leave a comment on this blog post.
Nov 18, 2008 6:48 PM Reply Andrew Cooke

I have just quickly read your blog post.

IOPS absolutely are the key things to consider when you have exchange on a SAN. This is true of the physical world and virtual.
Latency is unlikely or secondary.

There are some excellent docs on the Internet from the likes of EMC and others. A good start is from MS
http://technet.microsoft.com/de-de/exchange/bb412165.aspx

My company has been to see many customers who sometimes fall into this problem. I would offer the following as a place to start

1. Figure out what IOPS you would plan for assuming a green field
2. Monitor the transfers/sec over a period of time to establish what you are really using
3. Consider all of the factors that reduce IOPs available for use namely.
- SAN replication
- Small SAN cache/wrong size matched to workload type 4Kb for ex2003 and 8Kb for 2007
- NTFS format mis-alignment
4. Is your SAN virtaulized (ie mixed server workload)

Other environmental questions for you
1. Do you have dedicated network switch fabric or shared?
2. What make/model?
3. Do you use bonding/etherchannel at the ESX end?

Nov 19, 2008 10:35 AM Reply Anthony James in response to: Andrew Cooke

In the past, I had run into some similar issues as you. After a lot of digging I came across some good information that made a lot of sense. 1. iSCSI is not a good technology to use in certain area's. Using iSCSI for you virtual exchange servers is a risky thing. Even though on paper many "better grade" iSCSI storage platforms have pretty good throughput numbers (I consider anything above 350 Megabytes pretty good). They typically are not able to sustain those numbers. From my experience they any time you try to send large packets they either choke, or the latency goes way up slowing down the whole transfer of packets. This is due to iSCSI utilizing the TCP/IP transport protocol. TCP/IP needs an average of somewhere in the vicinity of 30 to 40 percent of the line's bandwidth for its overhead. It is also plagued by the technology originally being developed to work on the old 10 BaseT copper lines. It was designed to break packets down to fit through a much smaller pipe. It has been updated since those days, but it still seems to break packets down further than needed. This causes slow downs!

My suggestion to you would be to look at what companies are using for high definition video and or video rendering. These are probably the most difficult things to store. They need huge bandwidth to transfer the data efficiently. For this reason they typically use technology that works on the UDP/IP protocol instead of TCP/IP. UDP does not have nearly the overhead of TCP. In fact UDP is capable of utilizing about 90 to 95 percent of the lines total bandwidth. However, you will need to make sure the technology you use has some kind of error checking. TCP has it built in (which is one of the biggest reasons its overhead is so large). So if a storage product/technology works for HD video/rendering, then it should be more than adequate for virtual exchange servers. The one we use in our data center for our virtual machines, and our IP surveillance (we don't use the highest HD available, but higher than most companies would probably use, we use 1080) is a Z-SAN unit. They are relatively cheap (we spent $6000.00 for two model 410's with 4 Terabytes of disk in each unit) and the performance is unbelievable (from what we have seen thus far, and what others have told us). It has been able to take everything we have been able to through at it and not even hiccup a bit! They work on UDP and have error checking built into the software itself. So my opinion is it would be a great fit for you. I don't remember the website off hand, but if you Google Z-SAN, you should be able to find some info on it. I believe the company we purchase through is called MarketStor. But don't quote me on that, because I'm not 100% sure.

Nov 21, 2008 8:03 AM Reply Virtual_JTW in response to: Andrew Cooke

To answer your questions:
My storage networking is not dedicated, but it shares few ports with other hosts. I'm assured by my network team that the dual 3750(?) switches can more than handle the traffice these systems are genterating.
I'm running a Celerra NS350 with 2x1GbE connections dedicated to iSCSI.
We're bonding NICs on the ESX hosts.

I breifly reviewed the Microsoft/EMC doc - very interesting. Thanks for the link. I'm told there are others in Powerlink, I just need to spend some time finding/reading them.

Nov 21, 2008 8:10 AM Reply Virtual_JTW in response to: Anthony James

I read about Z-SAN a year or two ago. Interesting technology but not exactly a tier 1 (or even 2?) vendor.
The other thing I would say is that in general the solution should be design around the problem, in this case, workload. Exchange's workload is not like a streaming media application but is more like a database server. Our current SAN can handle that fine.
I do like the fact that they keep the storage transport on IP/ethernet, I think it's the general direction the industry is going.
For future SAN purchases I'm recommending staying on ethernet via 10GbE iSCSI or FCoE.