Michael K. Smith - Adhost wrote: >> - can your PF load balancers 'sense' when one of the Postfix/Dovecot >> units are down, or is this a manual change in config to prevent any >> time-out conditions? > > Not natively. When we initially implemented this setup, ifstated wasn't > up to snuff, so we wrote some PERL scripts that make connections to the > required ports and, if no connection is established, pull the server > from the table and send us an alarm. We also have scripts so that we > can pull servers out when we're doing maintenance.
Ok. I've done the above in similar situations numerous times, so that works. >> I like this load balancer idea. In my environment, it would be trivial >> to set up a couple of them, throw Quagga on them, and integrate them >> directly into our iBGP setup. On the other side, I could use VRRP or >> the >> like to ensure redundancy from front to back. > We use two PF boxes and CARP with PFSync for failover, so no dynamic > protocols are needed. I'll have to review this further. I'm not overly familiar with CARP (ie I've never used it), nor PFSync. My mentality for infrastructure gear (the balancers, not the servers) is always "make each device connect to two different switches/routers, and try to make it dynamic in a way that it fits into our OSPF/iBGP design, so if necessary, we can move the entire thing to a different network segment, and not have to renumber". I'm getting a mental picture how I can have load balancing & failover with the two devices, and network resiliency by having each balancer connected to different network segments (between buildings over fibre if I want). >> - do the Postfix/Dovecot servers communicate with each other, or are >> they simply stand-alone units that don't know/care that they have > other >> peers helping with the workload? >> > They are standalone. All of the user authentication is handled from a > centralized database, so there are no local credentials stored on the > server. Perfect...do your auth/acct db's generally reside on the same storage mechanism that the data does, in order to keep 'email related stuff' altogether? >> - are your filter servers in front of, or behind the load balancers >> (iow, is all of your inbound email passed through the balancers, and >> then filtered/processed/delivered in behind them)? >> > They are behind the PF boxes. We have other hooks in PF that we use to > block SPAM in PF, including Cloudmark and some custom stuff that looks > for multiple mails to non-existent addresses. We also use the overload > tables for abusive connections. Ok. We have a Barracuda cluster hanging off of one of our Internet facing edge routers, that filters then passes what it allows back into the network, and to the servers. The only reason I don't aggregate all of the mail systems together, is so that I can filter the spam as soon as possible upon ingress to our network, instead of having it traverse the core. >> - how do all of the pieces communicate with the NAS...NFS? > > Yes. Originally we used TCP but we found performance to be much better > with UDP. NFSv3 by the way. Ok. [ snip ] > If you have a particular scenario you're thinking about I could help you > with the rules to make it work. I do, and that would be fantastic! I'll draw up a diagram this afternoon of what I envision. Where I'll need a bit of advice will likely be in the details, as opposed to the design, especially if I migrate completely away from our existing mail platform(s). Cheers! Steve
Description: S/MIME Cryptographic Signature