LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: eliminating single point of failure in lvs

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: eliminating single point of failure in lvs
From: Lars Marowsky-Bree <lmb@xxxxxxx>
Date: Sun, 17 Aug 2003 20:12:27 +0200
On 2003-08-16T03:31:15,
   sushant paithane <spaithane@xxxxxxxxx> said:

> as far as lvs is concerned, it involves director
> machines in lvs based clusters

Yes.

> in a system with single director machine,it is "the"
> single point of failure

It can also be replicated to provide redundancy.

> 1> this method ensures proper load-balancing
> because instead of slicing the client address space
> between cluster nodes, the requests are shared.

The load balancing is also less well balanced, because it can only
happen statically. Solutions like weighted-least-connection or online
reweighting based on server load are much more complex.

It is not true that the requests are shared, that would lead to chaos;
the algorithm ensures that only one node replies to any given request.

> 2> single point of failure is eliminated(since no
> redirector machine)

The hashing algorithm and the reassignment of slices to the remaining
real servers in case of failures is the matter of concern then. This
becomes more complex and requires a cluster resource manager capable of
dealing with the number of nodes you have.

(The whackamole thingy I read about recently may be interesting.)

> 3>additionally scalability,ha are also maintained

This is also not quite true. The algorithm ultimately does not scale as
well as the LVS model with a centralized director.

This may seem surprising at first, but consider the following grossly
simplified model.

1. LVS case.

The LVS needs an overhead N for each connection it schedules. Thus, the
load on the director is O(N); no additional load besides the one request
is incurred on the real servers.

2. distributed cluster IP

A given node needs an overhead N to filter the traffic and figure out
which requests to handle. The total overhead for M nodes in the cluster
thus is N*M, which will be higher.


Now, I don't want to imply the method described by Fabio isn't good - in
fact, it is. I just wanted to add the other side of the coin to the
discussion.

I expect it will be quite valuable for <=8 node clusters which can live
with static load balancing; consider the case of the two LVS directories
themselves, two firewalls or simple webservers.

> can this be a modification to current lvs
> architechture?

I really doubt it. LVS is centralized, the former is distributed. LVS
runs on the directors, the cluster alias system runs on the client
nodes.

We are currently implementing the scheme described by Fabio.


Sincerely,
    Lars Marowsky-Brée <lmb@xxxxxxx>

-- 
SuSE Labs - Research & Development, SuSE Linux AG
 
High Availabilty, n.: Patching up complex systems with even more complexity.

Attachment: pgpCYrc8n1R7x.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>