LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS Hierarchy: Load balancing multiple DR clusters via TUN.

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: LVS Hierarchy: Load balancing multiple DR clusters via TUN.
From: Wensong Zhang <wensong@xxxxxxxxxxxx>
Date: Tue, 16 Jan 2001 12:37:48 +0800 (CST)
Hi,

In the principle, the LVS/TUN director can tunnel packets to another
director (eithor LVS/DR or LVS/NAT) and the director can forward/mangle
the packets to the real servers. So, it is possible to have LVS
hierarchy.

However, in your clusters, you probably need to write more elegent
monitor. If it sees that the local bandwidth is saturated, adapt the
weights of local servers to some small values. Then, part of packets can
be tunneled to your remote cluster.

Regards,

Wensong

On Mon, 15 Jan 2001, Neil Davis wrote:

> Hello,
> 
> We have successfully gotten an LVS farm working using DR. Because we
> are using NT and it is not easily TUN'd, we decided to go this
> route. NT servers with a Linux box running LVS and DR'ing them.
> 
> Is it possible to load balance two of these clusters with a TUN
> balancer(as long as the "local" lvs balancers are set up for it on
> the external interface)?
> 
> The reason we need to do this is because we are saturating 100Mbps
> with < 7 servers. The application and databases are capable of 3200
> transactions per second or 354 Mbps in the current configuration. I
> want to be able to scale it using TUN since it the bandwidth
> limitations disappear with TUN balancing.
> 
> This would also allow us to scale as fast as revenue permits by
> adding 100Mbps connection|cluster combinations, then adding the new
> cluster to the TUN farm. Our app has very short sessions (245-800ms
> up to 2 seconds when saturated) which are done and gone within this
> time period. It is also very bandwidth hungry. We are redirecting
> banners back at the users.
> 
> Is it possible to have an LVS hierarchy (DR or NAT clusters balanced
> by TUN) such as this for geographic(or local for that matter)
> redundancy, and to escape the bandwidth limitations inherent with
> the DR approach? Session state is not an issue, domain/cookie
> relationships are.
> 
> thx,
> Neil
> 



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