LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] How to Tell If an RS Is Really Up

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] How to Tell If an RS Is Really Up
From: "Robinson, Eric" <eric.robinson@xxxxxxxxx>
Date: Fri, 5 Dec 2008 10:46:11 -0800
I can give that a try. In the past when I tried editing the
ldirectord.cf file to drain servers, I recall that LVS stopped
forwarding packets to them completely. Users with existing sessions
experienced "freezes". 

--
Eric Robinson


-----Original Message-----
From: lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jason
Ledford
Sent: Friday, December 05, 2008 9:47 AM
To: LinuxVirtualServer.org users mailing list.
Subject: Re: [lvs-users] How to Tell If an RS Is Really Up

I use the command (already posted) to drain the server using ldirectord
config file:
/bin/sed 's/       real=10.37.2.9:25 masq 1/       real=10.37.2.9:25
masq 0/g' $

I put that in a script and can run it when needed to drain my servers.
I also have the reverse in a script so I can bring it back when I need.
I back it up first in case of a mistake.  I take it a step further and
run these scripts from Webmin so there is no need to even login to the
server.

-----Original Message-----
From: lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Robinson,
Eric
Sent: Friday, December 05, 2008 11:57 AM
To: LinuxVirtualServer.org users mailing list.
Subject: Re: [lvs-users] How to Tell If an RS Is Really Up

That solidifies what was taking shape in my mind. Thanks for the
clarification.

It seems this is a very timely discussion.

> three modes might make sense:
>
>  1. Ignore them (until a change event occurs) - the current behavior  
> 2. Reverse them - the behavior you were originally expecting  3. 
> Incorporate them into the configuration

This makes a great deal of sense to me. I can see where all three
options could be useful, but I really don't want to be without option 1.
It is what makes what I call "drain mode" possible, which is a
wonderfully graceful way to maintain servers. I set the weight to 0 then
I go away. Existing sessions continue uninterrupted, but new ones to
that RS are not possible. The user count gradually drops to zero, at
which time I am free to power off the server or whatever. No advance
notification to users is required. No staying up late to catch the
server when nobody is on it. I just put it in drain mode during normal
production hours. The next day when all the users are off of it, I can
maintain it at my convenience. When I'm done, I issue an ipvsadm command
to put the server in "fill mode" and it starts servicing clients. I've
been using this approach for a year and it has saved enormous amounts of
time and energy.

> 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.

For that very reason, the current behavior seems perfect to me. When I
place a server in "administratively down" mode, I *want* LVS to ignore
commands that may be triggered by ldirectord's health checks. That way I
can maintain the services on the RS (stop and start tomcat, for
instance) and not worry about the server suddenly becoming available to
users.

I also like being able to manipulate this behavior from the command
line. No need to edit a config file (or worry about remembering to
un-edit it). I can even schedule drain/fill changes with the at command.
It just feels right to me.

Of course, I know you must keep the big picture in mind. I hope whatever
you eventually do, the current behavior remains doable somehow.

--
Eric Robinson




Disclaimer - December 5, 2008
This email and any files transmitted with it are confidential and
intended solely for LinuxVirtualServer.org users mailing list.. If you
are not the named addressee you should not disseminate, distribute, copy
or alter this email. Any views or opinions presented in this email are
solely those of the author and might not represent those of . Warning:
Although  has taken reasonable precautions to ensure no viruses are
present in this email, the company cannot accept responsibility for any
loss or damage arising from the use of this email or attachments.
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

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