remember that CLUSTERIP is a load balancing mechinism, it doesn't do failover.

you can configure a VIP on one of the boxes by just defining a static address on eth0:0

where you need a HA application is to detect that one of the boxes has died and therefor the other box should take over the VIP

With CLUSTERIP, if you configure both systems with the same IP as box 1/1, then both will get the traffic if it's UDP (if it's TCP you will have the same effect as a dup IP, and will probably have nothing get through). This can be a _very_ useful feature as it allows the log message to be sent once and received by multiple boxes, but I don't think it's what you were after.

David Lang

On Thu, 19 Apr 2012, Martinez, Carlos R wrote:

Thanks David... it is looking like to reliably do this I'm going to have to leverage an HA application with static VIP but I still wonder if I can get away with iptables CLUSTERIP option.

We have our own HA application tool that we use and will need to pursue using 
it...


-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of [email protected]
Sent: Thursday, April 19, 2012 12:18 PM
To: rsyslog-users
Subject: Re: [rsyslog] rsyslog | VIP

You can use heartbeat (http://linux-ha.org) running on your rsyslog servers to 
manage a VIP on the servers themselves (no need for an external load balancer 
device)

The hard part of the question comes when you need to determine under what 
conditions you want to declare a box dead to force a failover.

From a practical point of view, rsyslog is pretty darn reliable, so if you just 
run rsyslog on both systems and only configure heartbeat to failover if a box 
is completely dead you will be in pretty good shape.

Hoever, this would not work in the case where rsyslog stops on a box that is 
otherwise healthy. How much checking you want to do to decide if rsyslog is 
healthy can be complex, various tests can include:

1. is rsyslog running (simple ps |grep check)

2. is rsyslog listening to a port (lsof check, netstat check, or probing a
port)

3. is rsyslog processing the message (sec watching for a message from rsyslog 
on a file or named pipe)

4. internal status checking in rsyslog

There are also other subtle prroblems that a box can have that will make a box 
still think it's healthy, but not be working properly for your logging

For example:

Routing problems could cause a box to still be up, but be unable to talk to 
boxes on other networks

Disk I/O problems could cause the box to be unable to write logs, even though 
it can still receive them (or if the box is a relay, a downstream box could be 
not responding so it can't forward the log messages)

If a box runs out of memory, various things on the box will get killed, which 
may leave a box not working the way it should

I have had about a hundred pairs of boxes running heartbeat for the last decade 
(more at some points than at others, but averaging around a hundred
pairs) and I've only had about a dozen or so problems stranger than what the 
simplist heartbeat configuration detects (full box down issues) during that 
time, which is why I say that as a practical matter, you are probably just fine 
with the simplest configuration, without trying to monitor rsyslog explicitly.

David Lang



On Thu, 19 Apr 2012, Martinez, Carlos R wrote:

Date: Thu, 19 Apr 2012 13:47:39 +0000
From: "Martinez, Carlos R" <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [rsyslog] rsyslog | VIP

I'm looking for the best way to put my rsyslog servers behind a VIP for TCP & 
UDP traffic.

It appears that the best solution thus far at least for TCP is fault tolerant 
setup with port probing.  I have tried a VIP load balance/round-robin 
configuration but it takes a while for the syslog/rsyslog client to start 
logging to the surviving rsyslog server when I bring one down.  As for UDP I'm 
not having good results at all and I'm starting to wonder if the best solution 
would be to have a static VIP IP where I use CLUSTERIP configuration on my 
systems where the failover occurs over the virtual network interface.

Any suggestions is appreciated.


Here is my configuration:


syslog/rsyslog client ->->->-> VIP ->->->-> rsyslog_server1,
rsyslog_server2

VIP options:  1) fault tolerant w/port probing 2) load balance/round robin 3) 
static IP (multicast) utilizing CLUSTERIP option.

I prefer the load balance configuration for data center HA.
_______________________________________________
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

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

_______________________________________________
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

Reply via email to