David - I agree that RELP would be the right place for it. For TCP load balancing with rsyslog currently, I find using an external load balancer such as haproxy works nicely.
Brian On Thu, Jun 4, 2015 at 1:40 PM, David Lang <da...@lang.hm> wrote: > 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. > _______________________________________________ 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.
