On Sun, 2010-07-25 at 21:39 -0500, Mike Gerdts wrote:
> On Sun, Jul 25, 2010 at 8:50 PM, Garrett D'Amore <garr...@nexenta.com> wrote:
> > On Sun, 2010-07-25 at 17:53 -0400, Saxon, Will wrote:
> >>
> >> I think there may be very good reason to use iSCSI, if you're limited
> >> to gigabit but need to be able to handle higher throughput for a
> >> single client. I may be wrong, but I believe iSCSI to/from a single
> >> initiator can take advantage of multiple links in an active-active
> >> multipath scenario whereas NFS is only going to be able to take
> >> advantage of 1 link (at least until pNFS).
> >
> > There are other ways to get multiple paths. First off, there is IP
> > multipathing. which offers some of this at the IP layer. There is also
> > 802.3ad link aggregation (trunking). So you can still get high
> > performance beyond single link with NFS. (It works with iSCSI too,
> > btw.)
>
> With both IPMP and link aggregation, each TCP session will go over the
> same wire. There is no guarantee that load will be evenly balanced
> between links when there are multiple TCP sessions. As such, any
> scalability you get using these configurations will be dependent on
> having a complex enough workload, wise cconfiguration choices, and and
> a bit of luck.
If you're really that concerned, you could use UDP instead of TCP. But
that may have other detrimental performance impacts, I'm not sure how
bad they would be in a data center with generally lossless ethernet
links.
Btw, I am not certain that the multiple initiator support (mpxio) is
necessarily any better as far as guaranteed performance/balancing. (It
may be; I've not looked closely enough at it.)
I should look more closely at NFS as well -- if multiple applications on
the same client are access the same filesystem, do they use a single
common TCP session, or can they each have separate instances open?
Again, I'm not sure.
>
> Note that with Sun Trunking there was an option to load balance using
> a round robin hashing algorithm. When pushing high network loads this
> may cause performance problems with reassembly.
Yes. Reassembly is Evil for TCP performance.
Btw, the iSCSI balancing act that was described does seem a bit
contrived -- a single initiator and a COMSTAR server, both client *and
server* with multiple ethernet links instead of a single 10GbE link.
I'm not saying it doesn't happen, but I think it happens infrequently
enough that its reasonable that this scenario wasn't one that popped
immediately into my head. :-)
- Garrett
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
