|
> 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
problems.
> 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.
Agreed.
> > 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
them!'
> > Which is basically what the wrr and wlc stuff does. You can give your
two
> > 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.
-Jacob
|
