|
Hello Ratz,
On Mon, 7 Jul 2003, Roberto Nibali wrote:
> > 2) add the failover server into each virtual service entry. When there
> > is no server available, send the request to the failover server.
> > The failover server can be run at the director machine, or the
> > remote machine.
>
> This is good. A RIP or a group of RIPs which act like a cold standby pool for
> session overload. The schedulers would not select a member of the pool
> (flagged
> with IP_VS_OVERFLOW_SERVER or something similar) unless all members of a VIP
> will have the IP_VS_DEST_F_OVERLOAD flag set. Then schedulers will start
> using
> the IP_VS_OVERFLOW_SERVER pool.
>
Yes, this is the way to go. :)
> My 3) would be something like that, I've done a proof-of-concept scheduler
> for
> 2.2.x (customer requirements) called hprio which only takes the servers with
> highest weight. As my "per RS threshold limitation" implementation will
> quiesce
> overloaded servers (2.2.x kernels) you can simply add an overload pool with
> weights := weights_of_RIPs - 1.
>
> I ripped the code from your rr and wrr schedulers, I hope you don't mind :)
> It's
> for 2.2.x and it works pretty well (let it run over the weekend and it didn't
> crash). Attached is the hprio scheduler.
>
> Now I have following snapshot for example:
>
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> u_thresh l_thresh
> TCP 172.27.100.100:80 hprio
> -> 172.27.232.12:80 Route 2 0 40 55
> 40
> -> 127.0.0.1:80 Local 1 0 19 0
> 0
> -> 172.27.232.4:80 Route 0 0 55 55
> 40
>
> 172.27.232.{4,12} are RIPs with weight 2, 127.0.0.1 is the session overflow
> page
> with weight 1, it will only be selected when it remains to be the highest
> weight
> (both other RIPs are quiesced).
>
I see your method in 2.2.x, but it is not good to change weight directly
inside the kernel. ;)
Cheers,
Wensong
|
