LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: ldirector and heartbeat

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: ldirector and heartbeat
From: John Gray <gray@xxxxxxxxxxxxx>
Date: Wed, 28 Jun 2006 08:05:05 -0400
Jason Downing wrote:
>> No but that does sound like a good idea. If I prepare a patch are
>> you able to test it to see if it helps your problem?
>
I could test it too.

John

> I would be happy to test such a patch. I think I will want it too.
>
>
> ----- Original Message ----- From: "Horms" <horms@xxxxxxxxxxxx>
> To: "LinuxVirtualServer.org users mailing list."
> <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Wednesday, June 28, 2006 1:50 PM
> Subject: Re: ldirector and heartbeat
>
>
>> In article <449DA02F.8090608@xxxxxxxxxxxxx> you wrote:
>>> I see that ldirector docs recommend starting it by heartbeat.
>>>
>>> I run two LVS boxes, in active-passive mode that serve as a
>>> load-balancer.  I've been running ldirectord on both boxes all the time
>>> instead of starting it with heartbeat because it take about 2 minutes
>>> for ldirector to test all my services and come to a fully functional
>>> state.  So it does failover much faster if the secondary box already
>>> has
>>> ldirectord running.
>>>
>>> It was a way to start ldirectord  where it assumes the services are
>>> good
>>> until  they are tested?  That would reduce the failover time if
>>> ldriectord is started it on failover.  And the services all almost
>>> alway
>>> there anyway.
>>
>> No but that does sound like a good idea. If I prepare a patch are
>> you able to test it to see if it helps your problem?
>>
>>> Is there a compelling reason for not running ldirector on both the LVS
>>> boxes all the time?  I realize I have all those extra service checks
>>> happening, but that seems worth it for the fast cut-over times.
>>
>> For simple setups, the answer is usually that it saves network traffic
>> and load on the real servers. My personal oppinion is if that
>> ldirectord's checks are loading your network and real-servers, then
>> you have big problems, but hey.
>>
>> For more complex setups, by which I am refering to ones where
>> real-servers and linux-directors are the same machines, then I'm
>> pretty sure you need to have heartbeat manage ldirectord or the whole
>> thing will fall over in a bit mess.
>>
>> In short, if your linux-directors and real-servers are separate
>> machines, and you want to run ldirectord on both of them from boot,
>> then you are likely (unless I've forgotten something) to resolve
>> your problem.
>>
>>> I'm trying to have heartbeat handle as little as possible to keep the
>>> cut-over time as short as possible.  So I run all the services I can on
>>> the secondary, so I don't have to wait for them to start.  Is there a
>>> good argument for not doing this?
>>
>> There are arguments, on a case by case basis, but in general I agree
>> with your point there. Its just easier to document that you should
>> have heartbeat manage resources, as that always works.
>>
>>> The truth of the matter is it only cuts over when I'm testing it any
>>> way, but I'm sure the day will come...
>>
>> Probably at a very invonvenient moment...
>>
>> -- 
>> Horms
>> H: http://www.vergenet.net/~horms/          W:
>> http://www.valinux.co.jp/en/
>>
>> _______________________________________________
>> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>> or go to http://www.in-addr.de/mailman/listinfo/lvs-users 
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users


-- 
John Gray                           gray@xxxxxxxxxxxxx
AgoraNet, Inc.                      (302) 224-2475
314 E. Main Street, Suite 1         (302) 224-2552 (fax)
Newark, De 19711                    http://www.agora-net.com


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