We're also using Linux Virtual Server for this which processed close to a billion messages for us last year. Also sounds like you need the weighted round robin feature of lvs to weight different servers accordingly which is something we do as well.
On Jan 8, 2008 1:58 AM, Paolo Cravero <[EMAIL PROTECTED]> wrote: > Thomas Ledbetter wrote: > > First of all: we're running amavisd-new, not plain spamc/spamd anymore. > > We used to have N servers each running its own spamd deamons, so with > separate > Bayes/AWL DB. > > I have not understood how many machines run spamc and how many spamd. > > > With a rounb robin policy on a hardware load balancer, once the > > connection is routed to a specific 'worker bee', if that machine times > > out, the request will fail, and the mail wont get scanned. However, > > more intelligent hardware load balancing setups can monitor the work on > > each node, and take it out of service as necessary. > > A load balancer sets as offline non-responding nodes, according to a > different > level of checks (ICMP ping, TCP ping, service check, ...). But these > checks > are not in real-time, so if spamd dies during analysis the connection will > drop (or hang) and spamc will timeout. The load balancer won't restart the > connection to another node. At least not our HLB. Been there (with LDAP), > done > that! > > > Also, when running a round-robin based cluster, is there any problem > > having a mix of machines with different performance capacities? i.e. If > > I have a 10 node cluster, and 3 of the servers are much slower than the > > others, will it impact performance of the cluster as a whole? Even if I > > limit the number of spamd that run to a lower value than the higher > > performance machines? > > What do you consider as "performance"? I think the global average analysis > time (what I call "performance") will obviously be affected, to an amount > that > depends on load distribution. With a real load balancer you can use > different > priorities for each node, so to keep faster machines more busy than slower > ones. > > Anyway, I've seen spamd running on different hardware since 2004 and I > wouldn't say the analysis speed has been improved significantly. Just > don't > let spamd nodes swap memory to disk. > > Good luck with the high-load spam fight, > Paolo >