Re: hello, I have two questions about keepalived, can somebody give me a reply?thank you

Well it can be shorter in VRRPv3
last I looked the patch for subsecond intervals in keepalived was
still being worked on,
IPv4 worked but the person who wrote it did not touch IPv6 which was a
blocker for acceptance into the main code base.
The matching IPv6 was still being worked on by developers who worked
for Brocade.
That said a couple of years ago I posted a hack patch as a proof of
concept that worked as fast as on interval of 0.01 seconds but ate an
entire CPU core on an 2.9GHz Xenon chip to do it, and was not a 100%
VRRPv3 compliant implementation. most of the overhead came from
calculations it did every interval which could have been done once and
the results reused but it was in a part of the code I never touched
for my proof of concept.
The fun part of the testing was unplugging a network cable and seeing
keepailved fail over significantly faster than it took the kernel
declared the link down.

In a practical implementation at my previous employer where I did use
the hack for a few years in a real time mission critical environment
at an interval of 0.2 seconds and it worked reliably. Probably could
have gotten away with 0.05 based on my tests but i did not attempt it
because I didn't want to risk a sudden unrelated CPU utilization spike
causing a fail over.


One thing to keep in mind is none of these patches work on the check
script interval.

As for your second question since your script is restarting keepalived
you will have to work that logic into your script. also keep in mind
the restart of keepalived will cause a fail over and fail back.

By the way protocol VRRP does not fail over on the first protocol
failure in the it retries a few times before an election is called. so
the result is roughly 3 times your interval. the actual equation to
get the precise time in ms is in the VRRP RFC's and is actually
effected by the priority but 3 times the interval is a fair estimate
regardless of your settings.





On Mon, Aug 10, 2015 at 2:13 AM, Ilya Voronin <[email protected]> wrote:
> 1. No, it can't be shorter than 1 second. This is a VRRP protocol
> limitation. Most enterprise-class VRRP implementation are using a BFD
> protocol to achieve sub-second fault detection time. I've created
> proof-of-concept BFD subsystem for keepalived some time ago -
> https://github.com/ivoronin/keepalived/tree/bfd . Unfortunately it is not
> well tested and not suitable for production use.
> 2. Have you checked "notify_master", "notify_backup", etc parameters?
>
> On Sat, Aug 8, 2015 at 7:10 AM, [email protected]
> <[email protected]> wrote:
>>
>> 1、              advert_int 1
>>
>> Did this must be a integer?When master is down, the time of switching
>> backup to master will be at least a second?Can this time be shorter?
>>
>>
>>
>>
>>
>>
>>
>> 2、vrrp_script chk_http_port {
>>
>>     script "/etc/keepalived/check.sh"
>>
>>     interval 1
>>
>>     weight -10
>>
>> }
>>
>>
>>
>> root@ubuntu1:/etc/keepalived# cat check.sh
>>
>> #!/bin/bash
>>
>> process_num=`ps aux |grep tgt |grep -v "grep" |wc -l`
>>
>> if [ $process_num -gt 0 ];then
>>
>> exit 0
>>
>> else
>>
>> service keepalived restart        --à If service tgt is stopped, this will
>> be excuted every one second, what should i do if i want it is excuted once
>> just like "weight -10"
>>
>>
>>
>> exit 1
>>
>> fi
>>
>>
>> -------------------------------------------------------------------------------------------------------------------------------------
>> 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出
>> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
>> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
>> 邮件！
>> This e-mail and its attachments contain confidential information from H3C,
>> which is
>> intended only for the person or entity whose address is listed above. Any
>> use of the
>> information contained herein in any way (including, but not limited to,
>> total or partial
>> disclosure, reproduction, or dissemination) by persons other than the
>> intended
>> recipient(s) is prohibited. If you receive this e-mail in error, please
>> notify the sender
>> by phone or email immediately and delete it!
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Keepalived-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>

------------------------------------------------------------------------------
_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel