Multipath I/O stats

Allen, Jack Jack.Allen at mckesson.com
Mon May 24 18:56:09 UTC 2010


 

-----Original Message-----
From: Yong Huang [mailto:yong321 at yahoo.com] 
Sent: Saturday, May 22, 2010 1:28 PM
To: redhat-list at redhat.com
Cc: Allen, Jack
Subject: RE: Multipath I/O stats

While we're on this topic, here's some not very technical thought 
on load balancing of multipath. When we talk about "load balance", 
we always tend to associate it with overall performance improvement 
(overall means scalability or throughput of multiple "clients", not 
latency of a single "client"). For example, an Oracle cluster 
database (called RAC by Oracle) allows more clients to connect to 
the database without degraded response time. But here we're dealing 
with multipath I/O. It's different in that the work done underneath 
is on one single piece of storage hardware, a hard disk (or a 
virtual one provided by some storage technology). Because read speed 
on the storage itself is always much slower than any of the multi-
paths which is usually fiber channel, whether you have a single or 
multiple paths to access the single slow disk will not provide 
performance improvement. Am I missing anything obvious?

No doubt multipath provides failover capability or failure 
resilience. Even with that one advantage, it's worth it.

Yong Huang
=========

	This was sort of my reason for the question I ask in the first
place. I agree that multipath provides multiple paths to a single
resource (Physical or Virtual disk). On some SAN implementations there
can only be an Active and standby path, others can have active/active
paths. This helps performance some if both paths can be accessed at the
same time as you point out and maybe the Virtual disk is made up of
multiple Physical disk. If both request are for different areas of the
Virtual disk, that is different Physical disk, the SAN can process both
request at the same time, basically as if they were total unrelated
storage. Most SANs that have multiple controllers generally have LUNs
assigned to them as the primary controller. The other controller can
access the same area if needed, but some have poorer performance when
this is done. Then there can be an imbalance on the amount of request a
given controller has to process as compared to the other controller so
it can become saturated causing poor performance for those systems
accessing the storage through that controller. This is generally due to
heavy I/O systems all having the same primary controller for the LUNs
assigned to them.

	Some vendors like EMC have their on implementation called
Powerpath. they claim does true load balancing. Basically when a request
is made it decides which path to which controller is less busy based on
current queue length and response times and will route the I/O request
to that controller.

	With Multipath round-robin and I have found out that rr_min_io
controls the number of I/O that are sent down one path before switching
to the next path. It does not analyze anything else related to the paths
other than are they available.

	We have a database application that some of our IT staff want
Powerpath to be used when we install it at a customer location. I want
to use Multipath because each time the kernel is updated it does not
break or have to be reinstalled like Powerpath does. Then there has been
times when Red Hat has had a point release update, and Powerpath could
not be reinstalled because it checked /etc/redhat-release and stated it
was not supported.

	So my question about how to tell if multiple paths were really
being used and by how much was to determine if the load balancing of
Powerpath really made that big of a difference and that all paths were
truly being utilized.

	I know there is more to it than are all the paths being used.
The underlying FC interface has to be able to send multiple I/O request
to the SAN and the SAN has to be able to accept them and process them in
the best order. If multiple I/O request can not be sent at once, that is
having several outstanding I/Os in progress at the same time, then it
does no good because the OS will have to wait for each I/O to complete
before it can send another.

	I am glad to see my question has caused others to think about
what Multipath ready does and how.

-----
Jack Allen


      




More information about the redhat-list mailing list