At 06:10 PM 2/24/99 +0200, Constantine Gavrilov wrote:
>We have a new NFS server with two NICs (3c905B Cyclone).
>I would like to be able to utilize both NICS with some sort
>of load balancing algorithm (I mean to use the bandwidth of both
>ethernet cards). Right now, both NICS have IP numbers from the
>same net and there are two route entries for this net (one for eth0,
>the other for eth1):
>
>eth0: IP is 10.3.2.62
>eth1: IP is 10.3.2.63
>
>routing table:
>
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref Use Iface
>10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
>10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1
>127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
>0.0.0.0 10.0.4.1 0.0.0.0 UG 0 0 0 eth0
>
>(All my nfs clients are from net 10.0.0.0). I assumed that this
>should provide for some load balancing. Surprisingly, what
>I see is that all RX packets are distributed evenly between the two
>interfaces and all TX packets go through the eth0:
Interesting that the RX packets are going to both interfaces. Are the
clients directed to the NFS server via IP or via hostname? bind will
automaticly cycle over multiple IP's assigned to one name, so the clients
could be getting spread that way. NFS checks security via hostnames as well
I think, so it might be checking names regardless of you giving it a number.
As for the outgoing packets, the kernel with simply select the first
correct route, or the first/default of two identical routes when deciding
which interface to use, so all packets will go out on one interface.
As an idea (I've NOT tried this) you could do a psuedo subnetting with your
two interfaces, so you would get something like
10.0.0.0 0.0.0.0 255.128.0.0 U 0 0 0
eth0
10.128.0.0 0.0.0.0 255.128.0.0 U 0 0 0
eth1
this way, (I think!), everthing between 10.0.0.0 and 10.127.254.254 will go
through eth0, and everthing from 10.128.0.0 and 10.254.254.254 will go
through eth1. If you think of the IP's in binary it looks a little clearer :-)
Unfortunately this is a little crude if PC's in one half of the network use
significantly more bandwidth than the other.
Bind can be configured to return particular answers to particular networks,
so you could force all the 10.0.0.0+ machines to talk to eth0, and all the
10.128.0.0+ machines to talk to eth1. I forget how this is done tho. RTBM
>----------------------------------------------------------------------------
> ifconfig eth0
>eth0 Link encap:Ethernet HWaddr 00:50:04:00:AC:67
> inet addr:10.3.2.62 Bcast:10.255.255.255 Mask:255.0.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1443994 errors:0 dropped:0 overruns:0 frame:0
> TX packets:767705 errors:0 dropped:0 overruns:0 carrier:11
> collisions:89927 txqueuelen:100
> Interrupt:9 Base address:0xec00
>
>ifconfig eth1
>eth1 Link encap:Ethernet HWaddr 00:50:04:00:AC:04
> inet addr:10.3.2.63 Bcast:10.255.255.255 Mask:255.0.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1247296 errors:0 dropped:0 overruns:0 frame:0
> TX packets:311 errors:0 dropped:0 overruns:0 carrier:0
> collisions:4 txqueuelen:100
> Interrupt:11 Base address:0xe080
>-----------------------------------------------------------------------------
>
>That really surprises me. Doesn't TX stands for transmitted and RX for
>received? Should not such set-up at the very least provide for balancing
>of the transmitted packets? Also, having some clients to mount on
>10.3.2.63:/mount_path and some on 10.3.2.62:/mount_path does not change
>the picture.
Probably something to do with NFS doing reverse DNS lookups, but I'm
wild-guessing :-)
>1) Is there a way to do load balancing on several interfaces, utilizing
> their bandwidth?
See routing hack above.
>2) Is there a way to at least make the nfs server to utilize several
> network interfaces? I do not necessarily mean automatic bandwidth
> utilization (which would be the best of course), but maybe some
> configuration trick is possible, like different instances of nfs
> daemon running on different interfaces, or using virtual interfaces
> (ip aliasing and some NAT rules?).
I don't think it's necesarry to get this tricky :-)
Tristan
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]