On Mon, 30 Jan 2012, Radu Gheorghe wrote:
Hello,
I'm currently using rsyslog in the following setup:
- a bunch of clients send Syslog messages to a central rsyslog daemon via TCP
- right now, the central rsyslog daemon pipes the logs to both a plain
text file and an external program. But I guess that's not so relevant
Soon, this central rsyslog would be overwhelmed by the amount of
logging from the clients. And I'm looking for a solution to be able to
deploy new "central" rsyslog daemons.
I thought about using DNS round robin:
- configure clients to send logs to a single hostname
- once a new "central" rsyslog is added, add it to DNS
Disadvantages to this are specific to DNS round-robin:
- load is not balanced if "central" servers are not the same
- there is a lag due to DNS caching
And I guess another solution is to have a script to run after
deployment, which will change the rsyslog.conf on all the clients. But
that's doesn't seem to be a good idea, especially since there's no way
to actually balance load on the aggregators. Only to make some clients
to log to one, others to another, etc.
Do you have any thoughts on how to solve the problem?
what I do is use iptables CLUSTERIP feature on linux to setup one IP
address that gets shared across the cluster of systems. heartbeat (with
the pacemaker cluster management layer) can keep track of the cluster and
make sure that there is always a box handling the traffic
what this does is use a multicast MAC address to send the traffic to
multiple machines. The kernel then does a hash on (one or more of) source
IP, source port, destination IP, destination port. It then divides this
hash into buckets (I am machine 1 of 10) and if it falls into the bucket
for this machine, it then sends the packet on to the application,
otherwise the kernel drops the packet.
This has the advantage of not needing any other systems, it can be done
entirely on the receiving cluster.
Another option you could do with TCP traffic is to setup a LVS (Linux
Virtual Server) load balancer (or run it through any commercial load
balancer)
In any of these configurations, you will want to consider the
tcprebindinterval config option of rsyslog on the sending machines so that
they will periodically close and re-open their connection (so that the
source port changes), otherwise you can end up with the traffic being
unbalanced between your systems without any way to re-balance the load.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/