[OpenIndiana-discuss] VMware
Jim Klimov
jimklimov at cos.ru
Sun Aug 11 19:59:39 UTC 2013
On 2013-08-11 19:57, James Relph wrote:
>> If I recall correctly, you can set LACP parameters that determine how
>> fast the switch-over occurs between ports, the interval at which the
> I'll have to have a look, but the thing is that we were seeing these datastore drops while at the same time we were running pings showing no dropped packets and no significant network latency. If it was an LACP issue (ports dropping etc.) causing iSCSI issues, wouldn't we see dropped packets at the same time?
I think it may depend on the hashing type you use in the LACP trunk.
Basically, in LACP, every logical connection uses one of the offered
links and maxes out at its link speed. When you have many connections
they can, on average, cover all links more or less equally, and sum
up to a larger bandwidth than one link. Selection of a link for a
particular connection can depend on several factors - for example,
L2-hashing like "sum up MAC addresses of DST and SRC, divide by the
number of links, use the remainder as the link number to use". Other
algorithms may bring IP addresses and port numbers into the mix, so
that, in particular, if there are only two hosts communicating over
a direct link, they still have chances to utilize all links.
So it is possible that in your case ICMP went over a working link
and data failed over a flaky link, for example. My gut-feeling in
this area would be that one of the links does not perform well, but
is not kicked out of the team (at least for a while), so connections
scheduled onto it are lost or at least lag. One idea is to verify
that LACP does not cause more trouble than benefit (perhaps by
leaving only one physical link active and trying to reproduce the
problem); a recent discussion on this subject suggested that maybe
independent (non-trunked) links and application-layer MPxIO to the
targets might be better than generic network-level aggregation.
HTH,
//Jim
More information about the OpenIndiana-discuss
mailing list