David and RB: I've learned something about DNS round-robin, in the past 24 hours: Apparently, everybody hates it!
Just kidding--I already knew that. It's very hate-able. Forgive me if it makes me chuckle that after I mentioned it, and three separate people in a row responded with some variation on "Ewww... DNS round robin is gross." In my initial response to David, I was a little ambigious as to what "central" log servers means: The hosts RECEIVING syslog messages are all on different subnets, at different sites. I quoted the word "central" because the logs are centralized, not the servers themselves. Ideally, the servers are dispersed far and wide, for better survivability. So ClusterIP might still play a role, but it wouldn't be a drop-in replacement for a round-robin. I'm not sure, yet, how much of the initial, shared-nothing design I want to compromise--it's going to be a judgement call. RB suggested LVS as another possible alternative. I actually have some firsthand experience with LVS, having built some WWW server farms on it, and I love it--truly a great piece of software. But in this situation, I wonder whether LVS really adds anything. I'd have to dedicate at least 2 extra machines to load-balancing duties, and the added complexity of the ipvsadm, CARP, etc. configs. The dedicated/clustered LBs would have to reside on a single subnet, though we could direct traffic to syslog receivers anywhere. The problem is, I feel like those dedicated LBs could create new problems: The LB mechanism is now both a potential bottleneck and a potential point of failure, neither of which existed before. Also, we'd have to route all of our traffic through the designated LBs, which would increase latency and load the network more than is strictly necessary. (I'm not sure if we really care about either of those issues, though--the effects probably won't be very big.) On the other hand, DNS round-robin has zero ability to control the traffic distribution, or to actively balance the load. I'd couldn't efficiently use differently-sized receiving servers. Plus, we really have to count the DNS as a potential point of failure, too. Hmmm... Decisions, decisions. -Ryan _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
