On Fri, 5 Jan 2001, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 4 Jan 2001, Wensong Zhang wrote:
>
> > Hi,
> >
> > >From the implementation viewpoint, Windows Load Balancing Service
> > implements a local filter between the NIC driver and the TCP/IP stack.
> > There is a filtering function, which can map incoming packets to the
> > cluster ndoe based on the source IP address and port number and only
> > pass the packets to the upper layer in one node. If some nodes fails or
> > new nodes are added, all the cluster nodes need neogociate a new
> > filtering function. I guess that each node may keep states of its
> > established connections, so that even under a new filtering function,
> > the packets destined for the local node can still be passed to the upper
> > layer, the new filtering function only works on new connections (SYN
> > packets). However, in persistent services, the new filtering function
> > will make all the persistence broken, no matter that they are connected
> > to the alive nodes or the failed nodes. It affects all the nodes. I see
> > that's the big shortcoming, but the distributed fileter architecture can
> > avoid the failure of dispatcher.
> >
> > It is simple to write a filter, but it must be complicated to write
> > convergence stuff (negociation for a new function).
> >
> > I see that maybe we can learn somethings from it, investigate some
> > mechanism to implement active-active load balancers.
>
> Hm, interesting reading. I'm thinking about the load
> percentages and whether the collisions or other factors lead to
> situations where two real servers can reply to same request.
>
> I'm looking in my stats for the banner servers that serve only
> static images, LVS/DR. Wow, I have the stats in packets/sec and not in
> bytes/sec. Can you believe, the input packets are 90% of the output
> packets. We don't talk for the bytes. So, if the web receives 90 packets
> and send 100 packets in LVS/DR and if the real servers are 10 each web
> in WIN2K/NLB mode will receive 90*10 packets and will send 100 packets,
> 9:1, a picture very different for the assumptions about the short
> web requests and the long answers. I'm not sure if the packet size makes
> any sense in the handling. IMO, we even don't waste CPU cycles in
> checksuming when forwarding the packets. In the real servers may be the
> cards with hardware checksuming help the WIN2K/NLB mode not to waste
> CPU cycles in checksuming the (N-1)/N of the incoming packets, i.e. the
> packets that will not be accepted locally.
>
Good point. Local filtering do some unnecessary checksuming the (N-1)/N
of huge incoming traffic. It will requires that real servers have good
hardware configuration. In the dispatcher method, we can optimize the
load balancer with good hardware, such as 2-way box with Gigabit cards,
and the real servers can still have common hardware.
Thanks,
Wensong
> OK, now I'm looking in the other my web servers that can connect
> to the databases. Can you believe, input packets are 98% of the output.
> Again, all hosts are in LVS/DR setup but this is not only a LVS/DR
> traffic to/from the clients.
>
> So, it seems all my real servers have equal number for in
> and out packets. If I have 32 real servers for each 32 packets
> I will send only one output packet in WIN2K/NLB mode. Oh, yes, there
> are full-duplex links too.
>
> Guys, what show your stats for the incoming and outgoing
> packets in your real servers? And only for LVS/DR traffic, i.e. static
> web for example or traffic that includes packets to and from the
> client only. Are my assumptions correct? May be for FTP the picture
> will be different, i.e. small request with long data. But there are
> acks too, not every packet contains data. But the incoming packets
> must be a small number compared to the output packets in long
> FTP downloads, you know, delayed acks, etc.
>
> > Cheers,
> >
> > Wensong
>
>
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|