|
On Thu, Dec 04, 2008 at 02:41:53PM -0800, Robinson, Eric wrote:
> > I just played with this and observed the same behavior,
> > and I think I can summarize it as:
>
> > Don't do both.
>
> I think I would summarize it as *DO* both. The behavior seems to be
> exactly what I want. When I change the weight manually, I want it to
> stay that way until I change it back again manually. I have observed
> that when I do this, existing connections are honored but new
> connections are rejected, which is perfect. It allows me to put servers
> (especially Windows terminal servers) in "drain mode" so I can
> gracefully wait for the user count to drop to zero, and which point a
> script e-mails me an alert that says, "Server X is available for
> maintenance."
>
> Are we sure this behavior isn't by design? If not, I hope it never
> changes.
>
> Like I said originally, my only problem is being able to tell the
> difference between the ones that I manually weighted from the ones that
> were changed by ldirectord. Now that I understand (a little) better, I
> can work around this problem. My first thought is to write a simple
> front-end script for ipvsadm that writes to a file. If a particular RS
> exists in the file, it was changed manually.
Hi,
this email will mostly re-iterate Graeme Fowler post with regards to this,
but Joe Mack asked me as the maintainer of ldirectord to say a few things
about this.
LVS runs inside the kernel and is configured from user-space.
The ipvsadm command line is a tool to do this and ldirectord
uses also tool. LVS does not (at this time) offer a way for user-space
programmes to see updates that have been made by third parties (though
now I think of this, the netlink interface that was added in 2.6.28
could likely be extended to do this). So if a user uses ipvsadm
to change something, ldirectord doesn't know about it.
ldirectord could poll the LVS setup and reset things that don't match its
view of the world, but it doesn't. Or more to the point it only does that
at the following times:
* when it starts
* when it is restarted
* when it rereads the configuration file
Other than the times listed above - which all run through the startup code -
ldirectord only alters the LVS configuration when the state of a
real-server changes, from up to down or drom down to up.
So if you alter the state of a real server (or any other part of the LVS
configuration) using ipvsadm then that change will remain until one of
the three events listed above occurs or the state of the modified
real-server changes.
Personally, I would be a lot more comfortable in altering LVS's setup
by modifying ldirectord.cf as needed. As you never know when an event
that triggers ldirectord to do something might occur. But you may be
comfortable with this behaviour - its up to you.
As for if/when this behaviour might change. Its not really an intentional
part of the design - more a side effect of LVS historically not providing
notifications of configuration changes to user-space. And I really do
think that managing the system through ldirectord.cf is a better way to go.
But there was a proposal made to me once that ldirectord should actually
take notice of third-party changes and incorporate that into its
configuration file. So I guess that if/when ldirectord was to take
notice of third-party changes, then the availability of three modes might
make sense:
1. Ignore them (until a change event occurs) - the current behaviour
2. Reverse them - the behaviour you were originally expecting
3. Incorporate them into the configuration
Graeme Fowler also mentioned keepalived. I imagine that it behaves
in a similar way to ldirectord, but I have not examined the code recently,
so I am just guessing.
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
