If we do decide to do this, it would be better to base the work on relp than tcp
(if the purpose is reliable delivery under failure conditions)
The thing is that failover and load balancing can be a rather complex problem
with many different solutions (different ones are better in different
conditions). Trying to implement the best options of everything inside rsyslog
is a lot of work, and I'd prefer the time being spent on improving the things
that can't be done with exiting tools :-)
Rsyslog already has better support for load balancing than logstash and nxlog (I
haven't looked at syslog-ng)
One question, if an action is configured to go to a name, when it reconnects
does it do another name lookup? or is it cached?
On Thu, 4 Jun 2015, singh.janmejay wrote:
Yes L4 load-balancing will work to significant scale. L7
load-balancing will do even better in terms of even load, but not sure
if syslog protocol is widely supported in load-balancers.
The syslog protocol is not supported by load balancers at L7.
However, this is still one of the places where existing load balancing solutions
would do better than your proposed solution. Having each client connect randomly
would result in more even load balancing only if they are all generating the
same amount of traffic. Since they aren't, it's going to be uneven, and the
clients cannot know what the right thing to do is.
Doing L2 load balancing at the destination, the load balancer can see all the
traffic and make descisions on it.
DNS scaling and propagation delay are sometimes not acceptable, but
BGP anycast is something that'd work at data-center scale with very
large PODs.
DNS and BGP failovers within your own network are as fast as you configure them
to be :-). I'm not even saying BGP anycast, just normal BGP failover for when a
set of IPs becomes unavailable, route them to a different destination.
This is an alternative to that. It has fewer moving parts (just
producer and consumer), no LB and it doesn't require the complexity of
anycast.
on the other hand, it requires much more complex configuration on every client.
Every time there is a change on the number of systems in the cluster, every
single client must be updated, or they will only deliver to a subset of the
available systems. From a sysadmin point of view, this is a horrible thing to
maintain. It's possible if you have a centralized config management system, but
that's a lot more complexity.
It trades-off engineering complexity of load-balancer and anycast with
smarter-clients and servers (increasing the complexity of clients and
servers a little, but also simplifying the deployment topology
significantly).
I see this as being a significantly more complex deployment topology :-)
I think all three are valid approaches and choice of one over the
other(best fit) will vary across deployments.
The question I have is if the value of adding this option in rsyslog is greater
than the features that would be added instead.
David Lang
_______________________________________________
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.
