My suggestion is to use something like corosync to provide a vitual IP for your
two systems (this can either be in pure failover mode where one gets all the
load unless it's down or in loadbalanced mode where the load is spread across
them roughly equally), and then configure the clients to send to the VIP.
Depending on the failure mode, failover can be very fast (telco implementations
have been sub-second, I was happy with 10-20 seconds)
It's going to be impossible for anything that's purely client-side to failover
that fast. If the server just stops responding, the TCP specs don't let you
decide that the server is dead that fast.
David Lang
On Fri, 18 Mar 2016, David Goudet wrote:
Date: Fri, 18 Mar 2016 18:48:43 +0100 (CET)
From: David Goudet <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: [email protected]
Subject: [rsyslog] TCP failover configuration on rsyslog 7.4 (Centos 7)
Hi,
I'm trying improve my TCP failover configuration on rsyslog clients.
My log architecture is:
Clients -> logrelay0{1,2}.xxxx -> Central log storage
Hereafter my clients configuration:
*.* @@logrelay01.xxx:xxx
$ActionExecOnlyWhenPreviousIsSuspended on
& @@logrelay02.xxx:xxx
$ActionExecOnlyWhenPreviousIsSuspended off
I prefer configuring failover on clients side (and not doing failover on
centralized element between clients and logrelay).
This configuration is not enough for me, when logrelay01 (primary) is
overloaded (but reply partially to TCP) some clients are very impacted. Some
clients (physical and virtual) generate many logs per seconds and the failover
from logrelay01 (primary) to logrelay02 (slave) is done too late. Logs are
bufferized on clients up to clients become unreachable (i think CPU load
average or RAM full).
I think this situation will occurs too if logrelay01 is off (incident or for
maintenance), clients does not reach the logrelay01 and failover will be done
too late.
I need to prevent these situations.
To reproduce this case, from logrelay01 i had DROP packet from one client and
seen that client failover is done about ~2 minutes after.
I reproduce the same test with REJECT from logrelay01 too and seen that
failover is done immediately.
I reproduced my previous problems with in DROP rule.
In this thread someone
http://www.gossamer-threads.com/lists/rsyslog/users/14681 got close issue.
I think there is several solution to prevent my problem:
- Here
http://blog.gerhards.net/2011/03/using-failover-and-asynchornous-actions.html
and here http://lists.adiscon.net/pipermail/rsyslog/2015-March/040189.html you
talk about synchronous or asynchronous queue.
- KeepAlive features has been implemented
After some configuration tests with KeepAlive, RELP, synchronous Queue, it seem
that my version does not support those features.
Is it possible to configure fast failover (in less than 30 secondes) on client
side with Centos 7 rsyslog version (rsyslog-7.4.7-12.el7.x86_64), what is the
best solution for you?
As i am in degreded state in failover (primary server to secondary server) case
i can loose some logs.
I am available if you need more informations
Thank you for you help
David
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
