[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keepalived-devel
Subject:    [Keepalived-devel] Fwd: Weight vs. Priority - what's the relationship?
From:       Paul Robert Marino <prmarino1 () gmail ! com>
Date:       2012-02-24 21:39:02
Message-ID: CAPJdpdBiT9JjDGTYhNxsj0KtUUPg3Wm9bcSB6fnXiR9XbUc8vw () mail ! gmail ! com
[Download RAW message or body]

---------- Forwarded message ----------
From: Paul Robert Marino <prmarino1@gmail.com>
Date: Fri, Feb 24, 2012 at 4:38 PM
Subject: Re: [Keepalived-devel] Weight vs. Priority - what's the relationsh=
ip?
To: Kian Mohageri <kian.mohageri@gmail.com>


On Fri, Feb 24, 2012 at 4:09 PM, Kian Mohageri <kian.mohageri@gmail.com> wr=
ote:
> On Fri, Feb 24, 2012 at 12:52 PM, Paul Robert Marino
> <prmarino1@gmail.com> wrote:
>> The answer is unless you always want the master to preempt the back up
>> even if nopreempt is specified (always fail back after a failover once
>> the primary has recovered) your weights on the two nodes shouldn't be
>> that far apart
>> eg.
>> node 1 priority 10
>> node 2 priority 11.
>>
>> a difference of 50 between the priorities will trigger a failover.
>>
>
> Is that to say, there will be no failover when nginx dies, if I use
> "priority 10", "priority 11" and "weight 2" ?
>
> I thought the machine with higher priority will always preempt (unless
> I specify nopreempt)?

You are correct that whichever one has the higher priority even by 1
will become the master unless nopreempt is specified, however a
difference of 50 will always trigger a failover even with nopreempt
specified.
In other words a difference of 50 is a absolute failure regardless of
your other settings.

>
>>
>> On a side note im also not wild about the idea of setting an explicit
>> master and backup ive found its usualy a much better practice to set
>> both as backup and utilize the priory with the preempt_delay or no
>> preempt to prevent flip flopping in the case of an intermittent issue.
>>
>>
>
> Not a bad suggestion, I'll look into this.
>
>> here is section 2.1 of the keepalived.conf.SYNOPSYS file included with
>> the source which explains it fully
>>
>> "
>> =A0 =A0 =A0 =A02.1. VRRP scripts
>>
>> =A0 =A0 =A0 =A0The configuration block looks like :
>>
>> vrrp_script <STRING> { =A0 =A0 =A0 =A0 =A0# VRRP script declaration
>> =A0 =A0script <QUOTED_STRING> =A0 =A0 =A0# script to run periodically
>> =A0 =A0interval <INTEGER> =A0 =A0 =A0 =A0 =A0# run the script this every=
 seconds
>> =A0 =A0weight <INTEGER:-254..254> =A0# adjust priority by this weight
>> =A0 =A0fall <INTEGER> =A0 =A0 =A0 =A0 =A0 =A0 =A0# required number of fa=
ilures for KO switch
>> =A0 =A0rise <INTEGER> =A0 =A0 =A0 =A0 =A0 =A0 =A0# required number of su=
ccesses for OK switch
>> }
>>
>> The script will be executed periodically, every <interval> seconds. Its =
exit
>> code will be recorded for all VRRP instances which will want to monitor =
it.
>> Note that the script will only be executed if at least one VRRP instance
>> monitors it with a non-zero weight. Thus, any number of scripts may be
>> declared without taking the system down.
>>
>> If unspecified, the weight equals 2, which means that a success will add=
 +2
>> to the priority of all VRRP instances which monitor it. On the opposite,=
 a
>> negative weight will be subtracted from the initial priority in case of
>> failure.
>>
>> "
>>
>>
>> On Fri, Feb 24, 2012 at 2:55 PM, Kian Mohageri <kian.mohageri@gmail.com>=
 wrote:
>>> Hi all,
>>>
>>> Most of the example configurations I find do not specify a "weight"
>>> for vrrp_script or track_script, and it sounds like the default weight
>>> is "2".
>>>
>>> At the same time, the same example configurations specify a priority
>>> of "150" for the MASTER, and "100" for the BACKUP.
>>>
>>> My question is: =A0if the track_script fails, and the weight is "2", how
>>> does the BACKUP take over the VIPs? =A0The priorities differ by 50, but
>>> the weight is only 2.
>>>
>>>
>>> The reason I ask is that I'm facing a problem with failover, in which
>>> the MASTER retains the VIPs, but traffic is being directed toward the
>>> BACKUP (which should now be the MASTER) -- sort of a split-brain
>>> problem.
>>>
>>> My configuration files are below. =A0I'm running Debian w/ keepalived 1=
:1.1.20-1.
>>>
>>> Thanks!
>>>
>>> ---------------------- lb1 ----------------------
>>>
>>> vrrp_script check_nginx {
>>> =A0 =A0script "/usr/bin/killall -0 nginx"
>>> =A0 =A0interval 2
>>> =A0 =A0#weight 2
>>> }
>>>
>>> vrrp_instance VI_1 {
>>> =A0 =A0interface eth1
>>> =A0 =A0state MASTER
>>> =A0 =A0virtual_router_id 51
>>> =A0 =A0priority 150
>>>
>>> =A0 =A0authentication {
>>> =A0 =A0 =A0 =A0auth_type PASS
>>> =A0 =A0 =A0 =A0auth_pass foobar
>>> =A0 =A0}
>>>
>>> =A0 =A0track_script {
>>> =A0 =A0 =A0 =A0check_nginx
>>> =A0 =A0}
>>>
>>> =A0 =A0virtual_ipaddress {
>>> =A0 =A0 =A0 =A0192.168.1.210 dev eth1
>>> =A0 =A0 =A0 =A0192.168.1.211 dev eth1
>>> =A0 =A0}
>>> }
>>>
>>> ---------------------- lb2 ----------------------
>>>
>>> vrrp_script check_nginx {
>>> =A0 =A0script "/usr/bin/killall -0 nginx"
>>> =A0 =A0interval 2
>>> =A0 =A0#weight 2
>>> }
>>>
>>> vrrp_instance VI_1 {
>>> =A0 =A0interface eth1
>>> =A0 =A0state BACKUP
>>> =A0 =A0virtual_router_id 51
>>> =A0 =A0priority 100
>>>
>>> =A0 =A0authentication {
>>> =A0 =A0 =A0 =A0auth_type PASS
>>> =A0 =A0 =A0 =A0auth_pass foobar
>>> =A0 =A0}
>>>
>>> =A0 =A0track_script {
>>> =A0 =A0 =A0 =A0check_nginx
>>> =A0 =A0}
>>>
>>> =A0 =A0virtual_ipaddress {
>>> =A0 =A0 =A0 =A0192.168.1.210 dev eth1
>>> =A0 =A0 =A0 =A0192.168.1.211 dev eth1
>>> =A0 =A0}
>>> }
>>>
>>> -----------------------------------------------------------------------=
-------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> Keepalived-devel mailing list
>>> Keepalived-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel

---------------------------------------------------------------------------=
---
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing =

also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Keepalived-devel mailing list
Keepalived-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
[prev in list] [next in list] [prev in thread] [next in thread]