Re: [Keepalived-devel] Consolidated config file

To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Keepalived-devel] Consolidated config file
From: "Jacob Coby" <jcoby@xxxxxxxxxxxxxxx>
Date: Wed, 29 Jan 2003 13:35:31 -0500
> A server knows its current state better than any other system.  A daemon
> running on a server can be checking CPU load, Disk, network I/O. Service
> availability, logs etc and can tell the director if/when it wants more
> traffic.  Setting up different weights for different services/servers is
> nice but it isn't dynamic.

It could be made dynamic though with a little work.

> Having the server announce its availability is great because when I want
> to take a service up and down for testing I currently have to go into
> the directory, modify the keepalived.conf file, reload it.  Then I need
> to get into the real server and play with the services.   If I could
> just get into the real server and tell the daemon to stop accepting mail
> traffic until I'm done it would be easier.

I could see that being useful.  I would think that a better interface
besides .conf files or the command line would alleviate most of your

> Making it completely dynamic would allow me to build stuff on the fly.
> The real servers could have IP's distributed via DHCP, netbooting etc.

I can see how that would be a major advantage.  Software for the agile
business and all that.

> The current way keepalived works is pretty good, I use it and I don't
> find myself modifying the config all that often.  I would like an easier
> way of disabling a service from the LVS as I test out new features.

How about a nice web interface? :)

> If I manually delete the LVS entry or set its weight to 0. Then shut
> down the service, make changes and restart it.  Keepalived will see the
> service go away and when it is restart it add it to the LVS table
> again.  This is not what I want.  I want to be able to disable the
> service until I say it is ok to re-enable them.  Currently the only way
> to do that is to edit the keepalived.conf file and reload it.  I really
> should do it on both master and backup directors.  As I'm cycling
> through my 4 mail servers it becomes tedious to get into the 2
> directors, disable, restart ....

Hmm, maybe lvs and/or keepalived needs the ability to mark a service as
sleeping?  Automatic replication across directors would solve the problem of
having to futz with both directors and make administration generally easier.

> If I could tell a local daemon on each server to stop the service it
> would save some time and confusion.


> > In this situation, you could announce to the director 'hey, i'm getting
> > killed here, bring up more servers to handle this service, if you got
> > Which is basically what the wrr and wlc stuff does.  You can give your
> > primary mail servers a [much] higher priority than the webservers.  Only
> > when the load gets high does the webserver start to take over.
> Yeah but the real server has the best picture of its actual load, more
> than just # of connections.

True, maybe a better test is needed instead of the standard ping, accept
connection on port n within x seconds?

> Yeah the security would have to be pretty clean to make sure servers
> don't start announcing stuff you don't want..

You'd probably want to handle it like DHCP and control it via ip and/or host
masks along with ports.

> I like this idea,  You'll have to handle the iptables, tc stuff as
> well.  With my config I use iptables to fwmark packets going to a Class
> C on port 80 & 443. I then have some ip policies to handle the marked
> packets as local.  I have LVS handle the marked packets to my web
> servers.  The Class C is not configured on any interfaces in my
> director.  I also planning on using tc to apply QoS to the number of SYN
> packets my mail server can receive from the Internet over a period of
> time to help limit SPAM from using up all my inbound mail connections
> (100 per machine, 400 for the director total).

Well, that all would have to wait until version 1.1 ;-)

> I'll help test ;)

Always good to have testers on a project.


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